AI用法进阶了！谷歌大佬说别再手写提示词了，Loop Engineering让它自己跑

AI Agent 越来越强，自己规划、自己完成的任务越来越多。

谷歌工程师 Addy Osmani 发了一条帖子：别再手动给 AI 写提示词了，去设计让 AI 自己跑起来的循环系统。

这就是 Loop Engineering，它不是又一个炒作概念，而是一场正在发生的真实转向，从你追着 AI 喂指令，到 AI 自己找活干、自己检查、自己推进。

Claude Code 之父也曾表达过类似亲身体验：“我现在不再给 Claude 写 prompt 了，我有一堆 loop 在跑。我的工作是写 loop。”。

Loop Engineering 的核心框架、关键组件、实际运作方式是怎样的，以及它目前有哪些绕不过去的代价呢？

从握着方向盘到设计自动驾驶

过去两年，用 AI 写代码的体验像打乒乓球，你发一条指令，等回复，读完再发下一条，你的注意力就是那台发动机，你离开键盘，Agent 就停了。

Loop Engineering 要做的，是让你不再当那台发动机。你写一个小系统，让它去找活、分活、检查、记录、决定下一步，让这个系统去戳 Agent，而不是你自己戳。

Peter Steinberger 在2026年6月8日发帖说，你不应该再手动给编码 Agent 写提示词了，你应该去设计让 Agent 自己跑的循环。

两天后，Anthropic 的 Claude Code 负责人 Boris Cherny 在台上说得更直白：我不再手动提示 Claude 了，我有循环在跑，它们负责提示 Claude、搞清楚该干什么，我的工作是写循环。

Addy Osmani 把这三层关系梳理得很清楚。

最底层是 Prompt Engineering，你优化的是单条指令的措辞。中间层是 Context Engineering，你优化的是模型看到的文档、历史和工具定义。最上层是 Loop Engineering，你优化的是一个自动运转的系统，它决定什么时候提示、提示什么、结果合不合格。

每一层都包裹下面一层，每一层都把杠杆点往外推了一步。

Osmani 还提到了一个更早的概念，Agent Harness Engineering，负责设计单个 Agent 运行的环境。

Loop Engineering 坐在 Harness 上面一层，Harness 跑在定时器上，派生出小帮手，自己给自己喂活。

有意思的是，一年前你要搞循环，得自己写一堆 Bash 脚本，然后永远维护那堆脚本，只有你自己看得懂。到2026年中，这些组件已经内置在产品里了。

Steinberger 列出的循环必备项，跟 OpenAI Codex 应用的功能几乎一一对应，跟 Claude Code 也几乎一样。

当你发现不同工具的形状是相同的，你就不再争论哪个工具更好，而是去设计一个无论坐在哪个工具里都能跑的循环。

判断你的任务到底适不适合做成循环。

三个条件：重复性，这件事你经常做，设计系统的成本能赚回来；可审查性，完成能被 Agent 或审查子 Agent 实际检查，你定义不了通过标准，循环就不知道什么时候停；价值性，产出值得花那些 Token。

三条都满足，适合做循环，缺一条，手动提示或写个普通脚本更划算。

五块积木加一本记忆

一个循环需要五样东西，再加一个记事本。Osmani 列出了清单，然后把它映射到了 Codex 和 Claude Code 两款产品上。

名字略有差异，能力是同一套。

Automations 是心跳。没有它，循环就只是一次性运行。Codex 里你在 Automations 标签页创建一个，选项目、提示词、频率和运行环境，跑出结果进 Triage 收件箱，没发现问题的自动归档。

OpenAI 内部就拿它做枯燥的事，每天分流 issue、总结 CI 失败、写 commit 简报、查上周引入的 bug。

Automation 还能调用 Skill，你写 $skill-name 就行，不用把一大坨指令贴到没人会去更新的定时任务里。

Claude Code 走的是另一条路到同一个地方，定时任务、hooks、/loop 按节奏重跑提示词，/goal 持续运行直到你写的条件真正满足，每轮结束后由一个独立的小模型判断是否完成，写代码的 Agent 不是给自己打分的那个人。

Codex 也有同样的 /goal，带暂停、恢复和清除。

Worktrees 解决并行冲突。两个 Agent 同时写同一个文件，跟两个工程师改同一行代码一样头疼。Git worktree 是一个独立的工作目录，在自己的分支上，共享同一个仓库历史，一个 Agent 的编辑不会碰到另一个 Agent 的检出。

Osmani 之前写过一篇关于"编排税"的分析，worktree 解决了机械层面的碰撞，但你的审查带宽才是决定你能同时跑多少个 Agent 的天花板，不是工具。

Skills 让你不再每次都重新解释项目。两个工具用同样的格式，一个文件夹里放 SKILL.md，包含指令和元数据，再加可选的脚本、引用和资源。Agent 每次启动都是冷的，你项目里的任何意图空白，它都会用自信的猜测来填补。

Skill 把意图写在外面，约定、构建步骤、"我们不用那种写法是因为那次事故"，写一次，Agent 每次运行都能读到。没有 Skill，循环每个周期从零推导你的整个项目，有了 Skill，它像复利一样积累。

有一点要分清，Skill 是编写格式，Plugin（插件）是分发方式。你想跨仓库分享 Skill 或把几个打包，就做成 Plugin。Codex 和 Claude Code 都是这样。

Connectors 基于 MCP，让 Agent 读取 issue 跟踪器、查询数据库、访问 staging API、往 Slack 发消息。两个工具都支持 MCP，给一个写的连接器通常在另一个里也能用。这是 Agent 说"这是修复方案"和循环自己开 PR、关联 Linear 工单、CI 绿了之后 ping 频道的区别。连接器让循环能在真实环境里行动，而不是只告诉你如果它有手它会做什么。

Sub-agents 是循环里最有用的结构设计，把写代码的和检查代码的分开。

Codex 用 TOML 文件定义子 Agent，安全审查员可以是高推理强度的大模型，探索者可以是快速的只读小模型。Claude Code 用 .claude/agents/ 和 Agent 团队传递工作。两边通常的分工都是一个探索、一个实现、一个对照规格验证。子 Agent 也烧更多 Token，每一个都有自己的模型和工具调用开销，所以在第二个意见值得付费的地方才花。

状态文件是整件事的脊梁。模型在运行之间会忘掉一切，所以记忆必须在磁盘上而不在上下文里。Agent 会忘，仓库不会。

一个 Markdown 文件，或一个 Linear 面板，任何存在于单次对话之外、记录已完成和待办的东西，就是让长跑 Agent 能在明天接着今天干的关键。

Osmani 之前的 Self-Improving Agents 文章里详细写过 AGENTS.md 的用法，每次任务完成后追加关键发现，比如"这个代码库用 Library X 处理 Y，请遵循这个模式"，或者"每次更新用户模型时，也要更新审计日志"。时间长了，这就是一个宝库，引导 Agent 远离重复犯错。

把这些粘在一起，一个循环长这样：每天早上一个 Automation 在仓库上跑，它的提示词调用分流 Skill，读取昨天的 CI 失败、开放的 issue、最近的 commit，把发现写入 Markdown 文件或 Linear 面板。

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

连接器让循环开 PR、更新工单。循环处理不了的东西落进 Triage 收件箱等人来处理。

状态文件记住试过什么、通过什么、还开着什么，明天早上的运行从今天停下的地方继续。

你只设计了一次，没有手动提示其中任何一步。这就是 Steinberger 那句话落地的样子。

循环办不到的事

循环改变了工作方式，没有把你从工作中删掉。三个问题随着循环变强反而变得更尖锐。

验证仍然是你自己的事。把审查子 Agent 和制作者分开，是为了让循环说"完成了"的时候有点分量，但"完成"是一个主张，不是一个证明。

你的理解会腐烂。循环越快地交付你没写过的代码，仓库里存在的和你实际理解之间的差距就越大，Osmani 叫它 Comprehension Debt（理解债务）。顺畅的循环只会让这个债务增长更快，除非你真的去读了循环产出的东西。

舒服的姿势才是危险的。循环自己跑的时候，很容易不再有自己的判断，它给什么就接什么。Osmani 叫它 Cognitive Surrender（认知投降）。

设计循环，用判断力去做，是解药；用逃避思考去做，是加速剂，同一个动作，相反的结果。两个人可以搭建完全相同的循环，得到完全相反的结果，一个用它加速自己深入理解的工作，另一个用它逃避理解。

然后是 Token 成本。这是 Osmani 自己在文章开头就打了预防针的，用法模式可能波动剧烈，你不得不小心。

任何依赖循环行为或多 Agent 架构的配置，都非常吃 Token。子 Agent 每一个都有自己的模型和工具调用开销，/goal 每轮还要额外调一个审查模型判断是否完成，长跑循环日复一日地烧。

Osmani 明确说了，Token 成本可能波动剧烈，取决于你是 Token 富裕还是 Token 紧张。

一个每天运行的分流循环，加上两三个子 Agent 的审查和验证，Token 消耗可以轻松达到手动提示的5到10倍，这还是在循环顺利跑完不翻车的情况下。一旦循环陷入反复尝试的死循环，Token 烧起来没有上限。

Reddit 上也有开发者说得直白，这玩意就是个戴着帽子的 cron job（定时任务）。

话虽刻薄，也点出一个事实，循环本身不神秘，它是一组已有能力的组合方式。神秘的部分在于，你怎么让这个组合在无人看守时不翻车，怎么在成本和产出之间找到平衡。

Osmani 的结论不是"全面转向循环"，而是找到平衡。

手动提示你的 Agent 依然有效，循环设计比提示词工程更难，不是更容易。

建循环，但像打算继续当工程师一样去建，而不是像打算只当那个按启动键的人。

参考资料：

https://x.com/addyosmani/status/2064127981161959567