夜雨聆风AI资讯周一速递·2026年6月15日·整理自公开报道
本期内容5042字，建议收藏后慢慢读
AI 编程的协作方式，可能正在发生一次范式跃迁：从你一句一句地提示 agent，变成你设计一套系统，让系统自己去提示 agent。
2026 年 6 月，Google Cloud AI Director、前 Chrome 工程负责人 Addy Osmani 写了一篇关于 Loop Engineering 的长文。这篇文章在 X 上获得了 7300+点赞、180 万浏览，提出了一个很值得关注的判断：AI 编程正在从 Prompt Engineering 走向 Loop Engineering。
过去，我们和 coding agent 协作的方式，是写 prompt、补上下文、看结果、再追问下一轮。而现在，新的趋势是设计一套自动循环系统：它会自己发现任务、分发任务、调用 agent、检查结果、记录状态，并决定下一步该做什么。
这听起来像是“让 AI 自己干活”，但 Addy 的重点恰恰相反：Loop 不会取代工程师，它只会放大工程师。你理解得越深，它越能帮你加速；你越想用它逃避理解，它越可能把你带进更深的坑。Prompt Engineering 关注的是怎么问，而Loop Engineering 关注的是整套工作流怎么自己转起来。这可能是 AI 编程接下来的关键分水岭。
每周一，S.AI Lab 为你搬运AI领域最值得读的播客与长文。
一、Loop Engineering.
Loop engineering 正在把你从“亲自给agent写提示词的人”，变成“设计一套系统，让系统替你提示agent的人”。这里的 loop，可以理解成一种递归式目标：你定义一个目的，然后让 AI 不断迭代，直到任务完成。它大致由五个基础模块组成，而 Claude Code 和 Codex 现在都已经具备了这五个模块。
我认为，这可能会成为我们未来与coding agents协作的方式。不过，现在还很早，我也保持怀疑。而且你必须非常注意 token 成本，尤其是当你有很多或者很少token时，使用模式可能会差很多。同时，你仍然需要某种机制来确保质量不会下降；大家对“AI 垃圾产物”的担忧也是合理的。
Openclaw之父Peter Steinberger最近说过：“你不应该再亲自提示coding agents了，你应该设计那些会去提示智能体的loops。” 类似地，Anthropic Claude Code 负责人Boris Cherny也说过：“我现在已经不再提示 Claude了。我有一些loopds在运行，它们会去提示 Claude，并判断接下来该做什么。我的工作是写loops。”
在过去差不多两年里，如果你想让coding agent产出东西，你要做的是写一个好提示词，并提供足够多的上下文。你输入一句话，阅读它返回的结果，再输入下一句话。agent是一个工具，而你一直握着这个工具，一轮接一轮地推动它。这个阶段差不多要结束了，或者至少有些人认为它即将结束。
现在，你要构建的是一个小系统：它自己发现任务、分发任务、检查结果、记录已经完成的内容，然后决定下一步做什么。你让这个系统去触发智能体，而不是由你亲自触发。我以前写过一个相近的概念：agent harness engineering1 ，也就是为单个智能体设计运行环境；我也写过factory model 2，也就是构建软件的系统。Loop engineering则位于 harness 的上一层：它像是一个会按定时器运行的 harness，会生成一些小助手，并且能把结果反馈给自己继续运转。
让我意外的是，这现在已经不再只是“工具能力”的问题了。一年前，如果你想做一个 loop，你可能要写一堆 bash 脚本，然后长期维护那堆脚本；那是你自己的东西，也只有你自己能用。现在，这些模块已经直接内置在产品里了。Steinberger 列出的那套能力，几乎可以一一对应到 Codex app，也几乎同样对应到 Claude Code。一旦你发现它们的结构其实相同，你就不再纠结到底用哪个工具，而是开始设计一个无论在哪个工具里都能工作的 loop。
二、loop engineering的五个模块
一个 loop需要五样东西，外加一个用来记事的地方。我先列出来，再逐一解释。
1. Automations（自动化任务）：按计划运行，自动做发现和分诊。
2. Worktrees（工作树）：让多个 Agent 并行工作，彼此隔离，互不干扰。
3. Skills（技能）：把项目知识写下来，避免智能体每次都靠猜。
4. Plugins&connectors（插件和连接器）：把智能体接入你已经在用的工具。
5. Sub-agents（子agent）：让一个智能体提出方案，另一个智能体负责检查。
然后是第六样东西：记忆。它可以是一个 markdown 文件，也可以是 Linear 看板，或者任何存在于单次对话之外、能记录“已完成”和“下一步”的东西。听起来好像不重要，但这是所有长时间运行的智能体都依赖的同一个技巧。我在long-running agents 3里详细讲过：模型在不同运行之间会遗忘，所以记忆必须存在磁盘上，而不是只放在上下文里。智能体会忘，仓库不会。现在，Codex和Claude Code都已经具备了这五项能力。
三、自动化：这是 loop 的关键
自动化（Automations） 才是让一个loop真正成为“loop”的关键，而不是那种你手动跑一次的伪循环。在Codex应用里，你切换到 Automations 标签页，选一个项目，填上它要执行的提示词，设定执行频率，再决定是在你本地的代码副本上跑，还是扔到后台的工作树（worktree）里跑。跑出有结果的，会进一个 triage box；啥也没发现的，自动归档——这点很省心。OpenAI 内部就用它来处理各种枯燥琐事：每日 issue 分类、CI 失败摘要、提交简报撰写、抓上周谁偷偷埋的 bug。而且自动化可以调用技能（skill），这样你就不用把一大段指令糊进定时任务里然后永远没人维护——直接调用$skill-name，干净利落，后续也好更新。
Claude Code 也能实现同样的效果，但它是通过调度机制和钩子（hooks）来达成的。你可以用 /loop按间隔运行一个提示词或命令，可以设置 cron 任务，可以在智能体生命周期的特定节点触发 shell 命令，也可以把整套东西推到 GitHub Actions，这样即使你合上电脑，它也能继续运行。核心思路完全一样：定义一个自治任务，给它一个节奏，让它把发现结果带回来，而不是让你到处巡查。
还有一个在会话中直接可用的原语值得了解，而且它更接近这篇文章的核心主题。
/loop 是按固定节奏重复执行。/goal 则不同——它会持续运行，直到你写的某个条件真正成立；而且每轮结束后，会由一个独立的小模型来检查是否达标，写代码的 Agent 不负责给自己打分。你丢给它类似「test/auth 下的所有测试通过，且 lint 无报错」这样的目标，然后就可以走人了。Codex 也有同样的功能，同样叫 /goal，它会跨轮次持续工作，直到可验证的停止条件满足，支持暂停、恢复和状态查看。
四、Worktrees：
别让并行变成混乱
一旦你同时运行多个 Agent，文件冲突就成了头号问题。两个 Agent 同时写同一个文件，跟两个工程师没沟通就改到同一行代码，头疼程度一模一样。
Git worktree 能解决这个问题——它是一个独立的工作目录，挂在独立的分支上，但共享同一个仓库历史。这样一来，一个 Agent 的改动根本碰不到另一个 Agent 的代码副本。
Codex 把 worktree 支持直接内置了，多个线程可以同时操作同一个仓库，互不干扰。Claude Code 也提供了同样的隔离能力：用 git worktree 命令，或者用 --worktree 标志在一个独立的 checkout 上开启会话，还可以在子 Agent 上设置 isolation: worktree，让每个助手拿到一份干净的代码副本，用完自动清理。
关于这件事的人性化一面，我在the orchestration tax 4 那篇里写过——worktree 消除了机械层面的冲突，但天花板还是你。你的审查带宽决定了你实际能并行跑多少个，不是工具。
五、Skills：
别再每次都重新介绍你的项目
Skill 就是让你不用再每次开新会话都从头解释一遍项目背景的东西。Codex和Claude Code用的格式完全一样：一个文件夹，里面放一份 SKILL.md，写清楚指令和元数据，再按需配上脚本、参考资料、静态资源。Codex 里，你用 $ 或 /skills 调用skill，或者当你的任务描述匹配到 skill 的描述时，它会自动触发——所以 skill 的描述写得平实具体比写得花里胡哨更重要。Claude Code 也是同样的机制，我把这套模式写在了Agent Skills5 那篇里。
Skill 还是终结重复意图成本的地方。我在the intent debt 6 里论证过：Agent 每次开跑都是一张白纸，你意图里的任何模糊地带，它都会用自信的猜测来填补。Skill 就是把意图写在外部——代码规范、构建步骤、“我们之所以不这么干是因为上次出过事”——一次性写清楚，Agent 每次运行都会读。没有 skill，循环每次都要从零重新推导你的项目；有了 skill，它才能像复利一样越滚越顺。
有一件事要分清：skill 是创作格式，plugin 是分发方式。当你想跨仓库共享 skill，或者把几个 skill 打包在一起时，就封装成 plugin。Codex 是这样，Claude Code 也是这样。
六、Plugins and connectors：
让循环触达你的真实工具
一个只能看到文件系统的循环，格局太小了。连接器（基于 MCP 构建）让 Agent 能读取你的 issue 追踪器、查询数据库、调用 staging API、往 Slack 丢消息。Codex 和 Claude Code 都支持 MCP，所以给一个工具写的连接器，通常换个地方直接用。而插件把连接器和技能打包在一起，你的队友一键安装就能复用整套配置，不用凭记忆从头重建。
这就是“Agent 告诉你修好了”和“循环自己开 PR、关联 Linear 工单、等 CI 变绿后自动在频道里 @人”之间的差别。连接器让循环能在你的真实环境里动手做事，而不是只会说“如果我能做的话，我会这么做”。
七、子 Agent：
让答题者别自己改卷
循环里最有用的结构设计，毫无疑问是把写的人和查的人分开。写代码的模型给自己打分时，下手太软。换第二个 Agent，用不同的指令、有时甚至换不同的模型，才能抓住第一个 Agent 自己说服自己忽略的问题。
Codex 只在你要的时候产生子 Agent，让它们并行跑，最后把结果汇总成一份答案。你自己在 .codex/agents/ 里用 TOML 文件定义 Agent，每个配好名字、描述、指令，可选指定模型和推理强度——所以安全审查员可以是强模型+高投入，而探索型 Agent 用个只读的快模型就行。Claude Code 也一样，子 Agent 放在 .claude/agents/ 里，还能组 agent team 互相传递工作。两个工具通常的分工都是：一个探索，一个实现，一个对照 spec 验证。
这个论点我之前写过两次，一个在
the code agent orchestra 7，一个在
adversarial code review 8。它之所以在loop里格外重要，是因为loop跑的时候你不再盯着。一个你真正信得过的审查员，是你敢走开的唯一理由。
子 Agent 确实更耗 token，因为每个都要独立调用模型和工具。所以，只有在“第二意见”值得付费的时候，才值得把 token 花在它们身上。Claude Code 的 /goal 底层也是这个逻辑——用全新的模型判断循环是否完成，而不是让干活的那个自己说了算。制造者和检查者的分离，直接应用在了停止条件本身。
八、一个loop长什么样
把这些东西拼在一起，一条thread就会变成一个小型控制台。我自己经常用的一种形态是这样的：
每天早上，一个自动化任务会在代码仓库里运行。它的 prompt 会调用一个 triage skill，读取昨天的 CI 失败记录、仍未关闭的 issue、最近的 commit，然后把发现的问题写进一个 markdown 文件，或者写到 linear 看板里。对于每个值得处理的问题，这条thread会打开一个隔离的 worktree，派一个 sub-agent 去起草修复方案，再派第二个 sub-agent 根据项目 skills 和现有测试来审查这份草稿。
Connectors 会让这个 loop 能够自己打开 PR，并更新对应的 ticket。任何 loop 处理不了的事情，都会进入 triage inbox，留给我处理。状态文件是整套系统的脊梁：它会记住哪些方案试过了、哪些通过了、哪些仍然待处理。这样，第二天早上的运行就能接着今天停下的地方继续。
注意你实际上做了什么：你只设计了一次。你并没有亲自 prompt 上面每一个步骤。这就是 Steinberger 那个观点真正落地后的样子。而且无论是在 Codex 还是 Claude Code 里，这都是同一个 loop，因为组成它的模块本质上是同一批东西。
九、loop仍然不能替你做什么
loop 会改变你的工作方式，但不会把你从工作里删除。随着 loop 变得更强，有三个问题不会变轻，反而会变得更尖锐。
验证仍然是你的责任。一个无人值守运行的 loop，也可能是在无人值守地制造错误。你之所以要把负责验证的sub-agent 和负责实现的 maker 分开，就是为了让 loop 说出的“完成了”稍微有点分量。即便如此，“完成了”也只是一个判断，不是证明。我在code review in the age of AI 7里一直强调同一句话：你的职责是交付你确认能正常工作的代码。
如果你放任不管，你对系统的理解仍然会退化。loop 越快地交付那些不是你亲手写的代码，现实系统和你真实理解之间的差距就越大。这就是所谓的comprehension debt 9，也就是“理解债”。一个顺滑的 loop 只会让理解债增长得更快，除非你真的去读它产出的东西。
还有一点：最舒服的姿势，往往也是最危险的姿势。当 loop 开始自己运行时，人很容易停止形成自己的判断，只是照单全收它返回的结果。我把这叫作 cognitive surrender 10，也就是“认知投降”。带着判断力去设计 loop，它就是解药；为了逃避思考去设计 loop，它就是加速剂。同一个动作，可能导向完全相反的结果。
十、构建loop，
但以engineer的身份
我认为，这预示着我们的工作方式将会如何演进。话虽如此，如果我不亲自 review 代码，或者完全依赖自动化 loop 来修复问题，产品质量一定会受影响。我很可能会陷入一种下行螺旋，不断把自己挖进更深的坑里。
所以，当然可以去搭建你的 loops，但别忘了，直接 prompt 你的 agents 依然是有效的。关键是找到合适的平衡。
loop 的结果，也很大程度上取决于使用它的人。两个人可以搭建出完全相同的 loop，却得到完全相反的结果。一个人用它在自己深刻理解的工作上提速；另一个人用它逃避对工作的理解。loop 分不出这两者的区别，你分得出。
这就是为什么 loop design 比 prompt engineering 更难，而不是更简单。Cherny 的意思不是工作变容易了，而是杠杆点变了。
构建 loop。但要像一个仍然打算继续做工程师的人那样去构建它，而不是像一个只负责按下“开始”按钮的人。
作者：Addy Osmani
原文链接：https://x.com/addyosmani/status/2064127981161959567
1 https://addyosmani.com/blog/agent-harness-engineering/
2 https://addyosmani.com/blog/factory-model/
3 https://addyosmani.com/blog/long-running-agents/
4 https://addyosmani.com/blog/long-running-agents/
5 https://addyosmani.com/blog/agent-skills/
6 https://addyosmani.com/blog/intent-debt/
7 https://addyosmani.com/blog/intent-debt/
8 https://addyosmani.com/blog/adversarial-code-review/
9 https://addyosmani.com/blog/code-review-ai/
10 https://addyosmani.com/blog/comprehension-debt/
