Loop Engineering 如何使用AI编程智能体：构建可循环系统

Addy Osmani（Google Chrome 工程负责人）写了一篇关于构建可循环系统的帖子，内容正是我感兴趣：怎么让 AI 自动运转起来，而工程师负责设计这套能够自我循环的系统。

今天就来分享他的具体做法。

有意思的是，谷歌的工程师分享的做法中用到的编程工具居然是 Codex 和 Claude Codex，而不是自家的 Antigravity 。

循环工程是把自己从"提示 Agent 的人"变成"设计提示系统的人"。

工程师构建一个小型自动化系统：它自己发现任务、分配工作、检查结果、记录进度，然后决定下一步。

这个系统替你去驱动Agent，而不是你亲自上。

这个循环系统由五个构建模块 + 一个记忆层组成，Claude Code 和 Codex 现在都具备全部六个。

⚠️ Osmani（作者）表示：这还很早期，他持怀疑态度。 Token 成本可能很高，质量控制仍然是挑战，"slop"（AI 输出的低质量内容）的担忧是合理的。

怎么做

从"手动提示"到"循环系统"

咱们使用 AI 编码智能体的方式是：写一个好的提示词、提供足够的上下文、大模型输出内容、你读回复、再输入下一个提示词。

Agent 是工具，你不停的使用它，一轮接一轮。

现在你构建一个小型自循环系统：它发现任务、分发工作、检查结果、写下已完成的内容，然后决定下一步。

你让这个系统代替你去驱动智能体。

这和 Osmani 之前的"Agent Harness Engineering"（Agent 脚手架工程）是相同的设计理念：脚手架是单个 Agent 运行的环境。

关于 Harness 可以看之前的介绍文章：万字深研 ｜Harness 工程实践：指令遵从率 20%，Hook 执行率 100%

循环工程在脚手架的上一层：脚手架加上定时器、能生成小助手、能自我喂养。

一年前如果想做一个循环，得写一大堆 bash 脚本，自己开发、维护这些脚本。

而现在，这些循环系统所需要的组件直接内置于产品中。

而且这个自循环模式在 Codex 和 Claude Code 中是一样的，只设计一个系统，就能在任何工具中都能运行的循环。

五个构建模块 + 记忆层

① 自动化（Automations）—— 循环的心跳

自动化让循环成为真正的循环，而不是一次性操作。

• • Codex： 在 Automations 标签页创建，选择项目、提示词、频率、运行位置（本地或后台 worktree）。
• 发现任务的运行进入 Triage 收件箱，没有发现的自动归档。
• OpenAI 内部用它做日常 issue 分诊、CI 失败总结、commit 简报、bug 搜索。
• • Claude Code： 通过 /loop 按间隔运行提示或命令，通过 cron 调度任务，通过 hooks 在 Agent 生命周期的特定节点触发 shell 命令，或推到 GitHub Actions 让它在关掉笔记本后还能继续运行。

让循环能运行的关键点： 持续运行直到你写的条件为真。

每轮结束后由一个独立的小模型判断是否完成，必须写代码验证而不是让大模型打分。

比如你给它的目标是："test/auth 全部通过且 lint 干净"，然后让它自己运行起来。

② Worktrees —— 让并行不变成混乱

一旦运行多个 Agent（在后面会提到，自动化必须有子 Agent），文件就会冲突。

两个 Agent 写同一个文件，就像两个工程师同时提交同一行代码却没互相沟通。

• • Codex： 内置 worktree 支持，多个线程同时操作同一仓库互不干扰。
• • Claude Code：git worktree 隔离，--worktree 标志在独立 checkout 中打开会话，isolation: worktree 设置让每个子 Agent 获得独立的 checkout 并在完成后自动清理。

worktree 只消除了机械碰撞。 你（人）仍然是天花板——你的审查带宽决定了你实际能运行多少个 Agent，而不是工具。

③ Skills —— 不再每次重新解释你的项目

Skill 是可以避免每个会话重新解释同一个项目上下文的方式。

两者使用相同格式：一个文件夹里有 SKILL.md（指令和元数据），可选的脚本、参考资料、资源文件。

Skill 也是"意图"不再反复消耗你的地方。

Osmani 在"Intent Debt"（意图债）中论证过：Agent 每次会话都是冷启动的，它会用自信的猜测填补你意图中的任何空白。

Skill 就是把意图写在外面：约定、构建步骤、"我们不这样做是因为那次事故"，写一次，Agent 每次运行都读取。

没有 Skill，循环每个周期都从零开始推导你的整个项目；有了 Skill，因为项目不断迭代，它会复利增长。

Skill 是创作格式，Plugin 是分发方式。

当你想跨仓库共享 Skill 或打包多个 Skill 时，可以把它们封装为 Plugin。

④ Plugins 和 Connectors —— 循环连接你的真实工具

只能看到文件系统的循环是一个很小的循环，对于自动化能真正的进行工作，这远远不够。

Connectors 基于 MCP 构建，让 Agent 能读取你的 issue 跟踪器、查询数据库、调用 staging API、在 Slack 发消息。

Codex 和 Claude Code 都支持 MCP，所以为一个写的 Connector 通常在另一个中也能用。

这就是，你对 AI 说"这里是修复"，和构建一个循环，“AI自己打开 PR、关联 Linear ticket、CI 通过后，通知频道"之间的区别。

⑤ 子 Agents —— 把"制造者"和"检查者"分开

循环中最有价值的结构：把写代码的和检查代码的分开。

写代码的模型给自己执行的结果打分总是倾向给予较高的评价。

第二个 Agent 用不同的指令（有时不同的模型）往往能找出第一个 Agent 没有注意到的地方。

• • Codex： 按需生成子 Agent，并行运行后合并结果。用 .codex/agents/ 中的 TOML 文件定义自定义 Agent（名称、描述、指令、模型、推理强度）。
• • Claude Code：.claude/agents/ 中的子 Agent 和 Agent 团队互相传递工作。

典型分工：一个 Agent 探索，一个实现，一个对照规范验证。

子 Agent 会消耗更多 Token（每个都有自己的模型和工具调用），所以把它们花在"值得付费"的地方。

⑥ 记忆层

一个 Markdown 文件、一个 Linear 看板——任何存在于单次对话之外、记录"什么完成了、什么接下来"的东西。

每个长时间运行的 Agent 都依赖同样的技巧：模型在两次运行之间会遗忘一切，所以记忆必须在磁盘上，而不是在上下文中。

Agent 会遗忘，仓库不会。

说完了上面五个必须的功能和记忆层的需求，我们看到：Codex 和 Claude Code 具有满足构建一个循环系统的全部功能。

Image

一个循环长什么样

作者文字中提到：每天早上一个自动化在仓库上运行。

它的提示调用一个分诊 Skill，读取昨天的 CI 失败、未关闭的 issues、最近的 commits，把发现写入 Markdown 文件或 Linear 看板。

对每个值得做的发现，线程打开一个隔离的 worktree，派一个子 Agent 起草修复，第二个子 Agent 对照项目 Skill 和现有测试审查这个草稿。

Connectors 让循环自己开 PR、更新 ticket。

循环处理不了的进入你的 Triage 收件箱。

状态文件是整个系统的记忆层：它记住什么被尝试了、什么通过了、什么还开着，所以明天早上的运行从今天停下的地方继续。

你只进行了一次设计了，构建了自动化的循环，再也不需要回到之前写提示词的模式。

循环还不能替你做的

循环改变了工作，但你还不能离开工作流。

你仍然需要处理好三个问题，它们随着循环变好反而更尖锐：

1. 1. 验证仍然是你的责任。
2. 无人值守运行的循环也是无人值守犯错的循环。
3. 拆分验证子 Agent 就是为了让循环的"完成了"有意义，但即使如此，"完成"是一个声明而不是证明。
4. 你的工作是发布你确认能用的代码。
6. 2. 你的理解仍然会腐烂。
7. 循环越快地发布你没写过的代码，存在什么和你实际理解什么之间的差距就越大。
8. 这是"理解债"（comprehension debt），顺畅的循环只会让它增长更快，除非你读循环产出的东西。
10. 3. 舒适的姿态可能就是危险的姿态。
11. 当循环自己运行时，很容易停止有自己的意见，照单全收。
12. Osmani 称之为"认知投降"（cognitive surrender）。
13. 设计循环是解药，当你带着判断去做时；设计循环也是加速剂，当你用它来逃避思考时。
14. 同样的动作，相反的结果。

实践启示

现在就可以开始做的事

1. 1. 用 替代手动循环。 给 Agent 一个可验证的停止条件（如"所有测试通过且 lint 干净"），让它自己跑到完成。
3. 2. 为项目创建 Skill。 把构建步骤、代码约定、历史教训写成 SKILL.md，让 Agent 每次运行都读取，而不是从零推导。
5. 3. 用 Worktree 隔离并行任务。 多个 Agent 同时工作时必须隔离，否则文件冲突不可避免。
7. 4. 拆分"制造者"和"检查者"。 用子 Agent 做代码审查，不要让写代码的自己审查自己。
9. 5. 建立记忆层。 用 Markdown 文件或看板记录循环的状态——什么做了、什么通过了、什么还开着。

需要关注的问题

• • Token 成本可能失控。 多个子 Agent 并行 + 循环反复运行 = Token 消耗可能远超预期。
• • 不要"认知投降"。 循环替你做了很多，但你仍然需要理解它产出的东西。否则"理解债"会累积。
• • 质量不会自动保证。 循环犯错也是自动化的——没有可靠的验证机制，循环可能悄悄地把事情搞砸。
• • 直接提示仍然有效。 不是所有任务都需要循环。简单任务直接提示更快、更便宜。

原文链接： https://x.com/addyosmani/status/2064127981161959567

看文章之前，我试过用 Codex 的 /goal 命令：/goal 命令让大模型持续工作直到目标实现，但是效果不好，因为目标不明确。

简单的任务可能会比较合适使用 /goal，因为规范要求和需要实现的目标清晰，而我当时试图让它跑通有16个业务领域的复杂大型系统。

其次，我之前一直困惑或者说因为无法设定一个检验标准，导致我不得不一次次的检查AI编程智能体的输出，再根据情况给出下一步指令。

即使是先让AI先给出规划任务，再按任务执行，也会遇到需要审核，再推进的模式。

所以作者的做法就很合理：每轮结束让独立的小模型判断是否完成。

第三、我判断这个循环还不太能够在较复杂的工程项目上使用。

例如从头开发一个有复杂业务的大型系统，而是对已经运转良好的项目，进行日常维护的自动化。

所以，欢迎有类似的想法或者实践的朋友，在评论区留言。