别再手动给 AI Agent 写 Prompt 了：正在改变开发范式的 Loop Engineering
alitrack约 6 分钟别再手动给 AI Agent 写 Prompt 了：正在改变开发范式的 "Loop Engineering"
你一定有过这种体验：
上班前给 Claude Code 或 Codex 发了条任务。下班时它还在跑。你盯着终端，犹豫着要不要打断它重写一个 prompt。
这种"人握着 Agent 的手，一步一问"的模式，正在被彻底颠覆。
一群最前沿的 AI 工程实践者，包括 Google 首席工程师 Addy Osmani 和 Anthropic Claude Code 负责人 Boris Cherny，正在推广一种新的范式——Loop Engineering。
Boris Cherny 的原话是：
"我不再手动给 Claude 写 prompt 了。我有循环（loops）在运行，它们替我召唤 Claude。"
什么是 Loop Engineering？
传统开发模式是：你写 prompt → Agent 回复 → 你读 → 你写下一个 prompt → Agent 再回复。
Loop Engineering 完全相反：你设计一个循环系统，它自动召唤 Agent，检查 Agent 的输出，决定下一步做什么，然后更新状态。整个过程不需要你亲自在场。
用 Addy Osmani 的话说：
"Loop engineering 是用系统代替你，作为 prompt 的发出者。"
这不是一个新工具，而是一种思维模式的转移。它不是某个 IDE 的新功能，而是你可以用 Claude Code、Codex 或者任何主流 AI 编码工具就能实现的模式。
五个构件，一个记忆层
根据 Addy Osmani 的总结，一个完整的循环由五个构件加一个记忆层组成：
1. Automations（自动化）—— 循环的心跳
Automations 让循环真正"循环"起来，而不是只跑一次就跑完。
在 Codex 中，你可以创建一个 Automations 任务：指定项目、prompt、运行频率（如每天早上 8 点）。运行结果会自动进入 Triage 收件箱，那些什么都没发现的运行会自动归档。
在 Claude Code 中，/loop 按时间间隔重复执行，/goal 则一直运行直到你指定的停止条件达成——比如"所有 auth 测试通过且 lint 检查干净"。
这个模块的使命是发现工作——从昨天失败的 CI、积压的 issue、最近的 commit 中找出需要处理的事。
2. Worktrees（工作树）—— 并行不打架
同时让两个 Agent 改代码，最大的噩梦是文件碰撞。
git worktree 解决了这个问题——它为每个 Agent 提供一个独立的检出目录，共享同一个仓库历史，但彼此的编辑物理上不可能冲突。
Codex 内置了 worktree 支持。Claude Code 用 --worktree 参数实现相同效果，Sub-agent 也可以配置 isolation: worktree。
3. Skills（技能）—— 把项目知识写下来
每次新开的 session 都是"失忆"的。Agent 不知道你的项目约定、构建步骤、命名规范。
Skills 就是解决这个问题的。一个 Skill 是一个包含 SKILL.md 的文件夹，里面记录了项目知识。Agent 在每次循环中都读取它，不会每次都重新猜测。
好的 Skill 描述应该写"做什么"，而不是堆砌关键词。它让意图不再每次都通过 human prompt 传递。
4. Plugins / Connectors（插件与连接器）—— 连接真实世界
一个只能读写文件系统的循环，是"小循环"。通过 MCP（Model Context Protocol），Agent 可以访问你的 Issue 跟踪器、查询数据库、调用 API、发 Slack 消息。
Connectors 让循环从"这是修复方案"变成"已经开了 PR、关联了 ticket、在 CI 通过后@了你"。
5. Sub-agents（子代理）—— 写代码和检查代码的人分开
这是整个循环里最有价值的结构设计。
写代码的 Agent 不适合检查自己写的代码——人对自己写的东西天生不够挑剔。
方案是：让一个 Agent 写代码，另一个完全独立的 Agent 检查它。第二个 Agent 用不同的 prompt，甚至可以是不同的模型。
顶级用例：一个 Agent 做探索，一个做实现，一个按照规格检查。这是 Claude Code 的 /goal 做的工作——用独立的模型判断循环是否该结束，而不是让干活的 Agent 自己说"干完了"。
6. State / Memory（状态）—— 循环的脊椎
循环运行在后台，Agent 每次跑完都会忘记一切。所以状态必须存在磁盘上，而不是上下文里。
一个 Markdown 文件，或者一个 Linear board，记录着：什么已经试过了、什么通过了、什么还在进行。明天早上循环启动时，从今天停下的地方继续。
一个真实的循环长什么样
1每天早上 8:00，Automation 自动触发：
2
31. 调用一个 triage skill → 读取昨天的 CI 失败、未被处理的 issue、最近 commit
4 → 把发现写入一个 Markdown 状态文件
5
62. 对每个值得处理的"发现"：
7 - 打开独立的 worktree
8 - 派 Sub-agent A 起草修复方案
9 - Sub-agent B 参考项目 Skills 和已有测试进行审查
10 - MCP Connector 自动创建 PR + 更新 ticket
11
123. 无法自动处理的事 → 进入 Triage 收件箱，等开发者审批
13
144. 更新状态文件：记住今天做了什么、还有什么没做完
注意：你只设计了一次这个循环。你没有手动写任何一个 prompt。
哪些工具已经支持这六个构件？
令人惊讶的是，Claude Code 和 Codex 各自独立实现了完全相同的六个构件：
| 构件 | Codex 实现 | Claude Code 实现 |
|---|---|---|
| Automations | Automations 标签页 | /loop、/goal、定时任务、Hooks |
| Worktrees | 内置 per-thread worktree | --worktree、Sub-agent isolation |
| Skills | Agent Skills（SKILL.md） | Agent Skills（SKILL.md） |
| Plugins | MCP Connectors | MCP Servers |
| Sub-agents | .codex/agents/ TOML | .claude/agents/ 文件 |
| State | Markdown / Linear | AGENTS.md / Linear via MCP |
危险在哪里？
Addy Osmani 自己发出了警告，而且三个问题随着循环变得更好而变得更尖锐：
验证仍然是你的事。 无人值守的循环也是无人值守地犯错。把验证者和执行者分开是让"做完了"有点意义的方法，但"做完了"只是声称，不是证明。
理解力会衰退。 循环越快地输出你没写的代码，实际存在的代码和你真正理解的东西之间的差距就越大。这是"理解负债"（Comprehension Debt）。一个流畅的循环只会让这个缺口增长得更快——除非你认真阅读它产出的一切。
最舒服的姿态是最危险的。 当循环自己跑起来的时候，你很容易停止"有自己的判断"，只是接受它给的一切。Addy Osmani 把这叫做"认知投降"（Cognitive Surrender）——设计循环是解药，但当你用它来逃避思考时，它就变成了加速剂。
"两个构建完全相同的循环的人，可能得到完全相反的结果。一个人用它来在自己深入理解的工作上加速；另一个人用它来逃避理解工作本身。循环不知道两者的区别。你知道。"
什么时候该用？
用在工作你已经深度理解的领域。
如果你的项目架构你很熟悉，让它循环跑代码审查、跑回归测试、跑常规重构——这能释放你的时间做更有创造性的工作。
如果你对某个领域完全陌生，让循环去探索是危险的——它产生的代码看起来合理，但你对它质量没有判断力。
对国内开发者的启示
你不需要等一个新工具。
Claude Code 和 Codex 已经具备了所有六个构件。你只需要开始这样思考：
- 你今天手动给 Agent 写的 prompt，能不能固化成一个 Skill？
- 你隔三差五就要做的事，能不能变成一个 Automation？
- 你在多个 Agent 之间来回切换的上下文，能不能写进一个状态文件？
一旦你开始这样问自己，你就已经在实践 Loop Engineering 了。
本文参考了 Addy Osmani 的 "Loop Engineering"、Boris Cherny 和 Peter Steinberger 的相关讨论。