什么是Loop Engineering？

在人工智能领域，近期一个热门新概念——Loop Engineering（循环工程）引发了广泛关注。该理念由Google Cloud AI总监Addy Osmani系统阐述，其核心思想是：不再手动为编程Agent编写提示词，而是设计一个自动运转的循环（Loop），让Agent自主决策下一步行动。

过去，开发者与Agent之间的交互模式类似于“一问一答”：编写提示词→按下回车→查看结果→再写下一条指令。而Loop Engineering的目标是将这一流程转化为自动化运行的控制面板，开发者只需搭建好流程框架，剩余工作由Agent全自动完成。

OpenClaw创始人Peter Steinberger指出：“你应当停止亲自为编程Agent编写提示词。你应该设计一个Loop，让Loop替你生成提示词。”Claude Code之父Boris Cherny的表达更为直接：“我已经不再为Claude编写提示词了，我有Loop在后台运行，它们自行决定该做什么，我的职责是编写Loop。”

一、Loop的六大核心组件

一个完整的Loop由五个基础模块与一层跨会话的记忆层构成。这些组件在当前成熟的Agent产品（如Codex、Claude Code）中已具备，开发者仅需将其组合拼接。

1. 自动化（心跳/定时任务）

自动化是Loop的启动器。它在预设的时间点或特定事件发生时自动触发，确保Loop真正实现“自动运转”。

• 在Claude Code中，可使用/loop执行定时任务。
• 利用cron进行调度。
• 通过hook在Agent生命周期关键节点触发。
• 推送至GitHub Actions，即使关闭电脑也能持续运行。

还有一个重要模式：/goal。它并非按时间触发，而是持续运行直至最初设定的标准完全满足。每完成一轮，独立的Agent会检查目标是否达成就，Claude Code和Codex均支持此功能。

小提示： 自动化并不等同于“完全放手”。务必在启动前确保目标定义足够清晰，否则Loop可能偏离方向。

2. 工作树（Worktree）

当同时运行多个Agent时，可能出现两个Agent同时修改同一文件的冲突问题。Git worktree的解决方案是在同一仓库历史中切出独立的工作目录，每个Agent的修改互不干扰，相当于为每个Agent配备了“独立工作台”。

常见问题：如何避免多个Agent之间的代码冲突？
答案：使用Git worktree。每个Agent在其独立工作目录内进行修改，合并时通过PR完成，不会直接冲突。

3. Skill（技能包）

Skill是将开发者对项目的代码风格、规范、架构设计以及历史避坑经验等要求打包提供给Agent。Agent每执行一轮都会读取这些技能，无需重复输入。

若没有Skill，Loop每一轮都要从零推导项目做法；有了Skill，每一轮都能吸收上一轮的经验教训。

小提示： Skill文件建议使用Markdown编写，存放于项目根目录的特定文件夹中（如.agent/skills/），方便Agent自动加载。

4. 插件和连接器（Plugins & Connectors）

这决定了Loop能否触及真实的外部工具。一个只能读取文件系统的Loop是“小Loop”，真正有效的Loop必须能操作工具执行实际工作。

连接器通常基于MCP协议，使Agent能够访问Issue Tracker、查询数据库、调用API等。

常见问题：Agent能操作哪些外部工具？
答案：通过MCP协议，Agent可以连接GitHub Issues、Jira、Slack、数据库、云服务等。具体取决于你安装的连接器插件。

5. 子Agent（Sub-Agent）

这是Loop中最关键的设计：将编写代码的Agent与检查代码的Agent拆分为两个独立角色。让同一个Agent既写代码又做检查，容易因为自我评判而放水。第二个独立的Agent配备不同的指令（甚至不同的模型），专门负责审查其他Agent的工作成果。

这也是/goal命令中常用的做法——由一个独立Agent判断目标是否达成。

小提示： 子Agent的指令应比主Agent更严格，且可使用不同模型（例如主Agent用Claude，检查Agent用GPT-4），以降低同质化错误。

6. 记忆层（Memory）

记忆层是“整条流水线的中枢”。它可以是一个Markdown文件、一个Linear看板，或任何独立于单个会话之外、记录已完成和待办事项的载体。

关键原则：记忆文件必须存储在磁盘上，而不能仅存在于上下文窗口中。Agent会遗忘，但文件不会。

常见问题：记忆文件应该存放在哪里？
答案：建议放置在项目根目录的.agent/memory/下，或使用云存储（如GitHub Wiki、Notion API）实现跨设备同步。

二、搭建Loop的典型案例

作者展示了一个典型的Loop应用场景：

• 每天早晨，一个定时任务在代码仓库自动启动。
• 它调用一个分诊技能（类似急诊护士），查阅昨日的CI失败记录、待处理的Issue、最新提交记录，将发现录入Markdown文件或Linear看板。
• 对每个值得修复的问题，Loop自动创建独立工作区（worktree），并派遣一个子Agent起草修复方案。
• 再派遣第二个子Agent参照项目的技能文档和现有测试对方案进行审查。
• 审查通过后，连接器自动创建PR、更新工单；Loop无法处理的事项放入Triage收件箱等待人工处理。
• 整个流程由state file记录进度，第二天从停止处继续执行。

结果：设计出该Loop后，发现、分配、修复、审查、创建PR，整个过程无需手动输入任何指令。

三、搭建Loop时必须警惕的三个问题

Loop改变的是工作量，但并不意味着人可以脱离流程。以下三个问题若不注意，Loop很可能适得其反。

1. 验证仍是你的职责

开发者的核心工作是发布经过确认可正常运行的代码。将验证Agent与生产Agent分离，是为了提升Loop完成状态的可靠性，但“已完成”只是一个声明，并非最终证明。最终的检查必须由人工完成。

2. 理解债务会迅速累积

Loop产出速度越快，代码与人类能够真正理解的代码之间的差距就越大。这被称为“理解债务”。一个流畅高效的Loop会加速债务膨胀，除非开发者认真阅读并消化Loop产出的内容。

3. 最舒适的姿势往往最危险

当Loop自主高效运行时，开发者很容易被诱惑直接接受所有结果，而不再进行自主判断。作者将这种状态称为“认知投降”。设计Loop是解药还是毒药，取决于你是用它来辅助提效，还是用它来逃避主动思考。

常见问题（FAQ）

• Q：Loop Engineering适用于所有项目吗？
  A：更适合流程明确、重复性高的开发任务。对于探索性、高度创新的项目，仍建议手动编写提示词。
• Q：搭建Loop需要多少技术投入？
  A：需要熟悉Git、Agent CLI工具（如Claude Code、Codex），并能理解MCP协议。初学者可以从一个简单的定时检查CI的Loop入手。
• Q：如果多个Agent仍然冲突怎么办？
  A：检查工作树配置是否正确，确保每个Agent使用独立的worktree分支。同时，可在Skill中定义文件锁定规则（如每个模块只允许一个Agent同时修改）。
• Q：记忆文件会被Agent错误覆盖吗？
  A：存在风险。建议对记忆文件进行版本控制（如使用Git），或对子Agent设置只读权限，仅允许主Agent写入。

结语：保持独立思考，做一个清醒的搭建者

作者在文末写道：“搭建好你的Loop，但不要忘记，直接为Agent编写提示词仍然有效。关键是找到正确的平衡点。”

两个不同的人可以搭建完全相同的Loop，却得到截然相反的结果：一个人用它加速自己已经透彻理解的工作流程，另一个人则用它回避真正理解工作本身。Loop无法区分使用者，只有使用者自己需要保持清醒。

Loop替人类节省的不仅是繁琐的操作，还带走了参与感。当不再亲手输入提示词的那一刻，你也失去了亲自验证的机会。这正是作者在讲完五个基础模块后，用同样篇幅强调三个问题的原因：验证仍是你的职责、理解债务会滚雪球、最舒适的姿势最危险。他在提醒：Loop越强大，你就越需要保持警醒。

Boris Cherny说“我的工作是写Loop”，这句话并非说工作量减少了，而是工作难点的转移。搭建Loop是大势所趋，值得学习与实践，但要像依然专注于工程师本职的人一样去搭建Loop，而不是沦为只会点击“开始”按钮的操作者。