Loop Engineering 是 2026 年 6 月突然火起来的概念。说「突然」也不准确——它背后是过去一年半 Prompt Engineering → Context Engineering → Harness Engineering 这条技术路线的自然延伸。简单讲：别再手动给 AI 编程 agent 发指令了，设计一个系统替你做这件事。
谁提的
2026 年 6 月 7 日，Google 工程师 Addy Osmani 发了一篇博客，标题就叫《Loop Engineering》。文章中引了两段话，后来被反复转发：
Peter Steinberger 说的：「你不应该再手动给 coding agent 写 prompt 了。你应该设计循环（loop）来替你 prompt 它们。」
Anthropic Claude Code 负责人 Boris Cherny 说的：「我不再手动 prompt Claude 了。我有一堆循环在跑，它们替我 prompt Claude，自己决定下一步做什么。我的工作变成写循环了。」
这两句话基本说清了 Loop Engineering 的定位——它不是什么新框架新工具，而是一种工作方式的转变。这个说法随后在 Twitter 上迅速传播，形成了「Developers Shift to Loop Engineering for AI Coding Agents」的热门话题。到 6 月 9 日，Lushbinary 等团队已经出了完整的实战指南。
理解三层递进
要理解 Loop Engineering，先看它之前的两层：
| 层次 |
你在优化什么 |
工作单元 |
| Prompt Engineering |
怎么写好一条指令 |
你手动敲的一次对话 |
| Context Engineering |
上下文里放什么：文档、历史、工具定义 |
一次回答的前置条件 |
| Harness Engineering |
单个 Agent 的运行环境 |
一次完整的 Agent 会话 |
| Loop Engineering |
谁来决定 prompt 什么、何时 prompt、结果要不要 |
一个自运行的循环，跨多次会话 |
Prompt Engineering 不会消失——循环里塞的终究还是 prompt，写不好的 prompt 进了循环只会更快产出垃圾。Context Engineering 也不会消失——循环在每个回合仍然需要把正确的文件、历史、工具定义放到模型面前。Harness Engineering 也不冲突——回路（Loop）跑在 harness 的上一层，harness 管单个 Agent 跑得安稳，loop 管这些事情在无人值守时持续运转。Loop Engineering 加的是「自动化控制结构」。
一个循环需要的六个零件
Addy Osmani 和 Steinberger 都列了差不多的清单。零件名字在各个工具上略有不同，但能力是一致的：
-
定时任务（Automations）
——按计划触发，自动发现和分类待办事项。它是循环的心跳，没有定时触发，循环就是个一次性的东西。
-
工作树（Worktrees）
——多个 Agent 并行工作时文件不打架。一个 Agent 改一个目录，互不干扰。
-
技能（Skills）
——把项目知识写下来，Agent 不用每次从头猜。约定、构建步骤、踩过的坑，全写进 SKILL.md。
-
插件和连接器（Plugins/Connectors）
——让 Agent 能碰你真实用的工具：Issue 跟踪器、数据库、Slack、CI 系统。基于 MCP 协议。
-
子 Agent（Sub-agents）
——写代码的和检查代码的不是同一个 Agent。一个写，一个审，避免自欺欺人。
-
持久记忆（Memory）
——存盘的状态文件。模型每次运行完就忘，所以状态不能放上下文里，要放磁盘上。Agent 忘了，仓库不会忘。
这六个东西加起来，才构成一个完整的自运行循环。
做循环的人和做 prompt 的人有什么区别
传统方式：你对着 Agent 打字 -> 它回复 -> 你再打字 -> 它再回复。你是那个一直握着工具的人。
Loop 方式：你设计一个小系统 -> 这个系统自己发现活儿 -> 自己分给 Agent -> 自己检查结果 -> 自己记录进度 -> 自己决定下一步 -> 然后继续循环。
你设计一次，它跑很多天。
这句话听起来简单，但它改变了一个本质问题：杠杆从 prompt 的质量，转移到了系统设计的质量。 写一条好 prompt 不难，设计一个能在你没盯着的时候还能持续产出、且不犯大错的系统，难度高了一个数量级。
Boris Cherny 的原话更直白：这不是 coding 变容易了，而是最高价值的事情从写 prompt 变成了设计循环。一个设计好的循环能把一个好工程师放大 N 倍。一个设计烂的循环，犯错的速度也同样放大 N 倍——而且你在旁边看着的机会更少了。
工具现状：Codex 和 Claude Code 都已经内置
去年你想要一个循环，得自己写一堆 bash 脚本维护。2026 年 6 月的状态是：这些零件直接装在产品里。
| 零件 |
在 Codex 里叫什么 |
在 Claude Code 里叫什么 |
| 定时任务 |
Automations 标签页（选项目 + prompt + 频率） |
/loop 命令、hooks、GitHub Actions |
| 长期目标 |
/goal（0.128.0 之后） |
/goal（内置验证器，独立模型判断是否完成） |
| 工作树 |
每个线程自带工作树 |
git worktree、–worktree、isolation: worktree |
| 技能 |
Agent Skills（SKILL.md） |
Agent Skills（SKILL.md） |
| 连接器 |
MCP Connectors + Plugins |
MCP servers + Plugins |
| 子 Agent |
.codex/agents/ 下 TOML 文件 |
.claude/agents/ + agent teams |
| 持久状态 |
Markdown 文件或 Linear |
Markdown（AGENTS.md）或 Linear via MCP |
关键结论：这两款工具的零件形状基本一样。 一旦你意识到这一点，就不会纠结用哪款工具了——你设计一个循环，它在两头都能跑。
/goal 是 2026 年最受关注的 Agent 原语
2026 年上半年，/goal 成为最受关注的 Agent 原语。原因很直接：它让循环自己判断什么时候算完成。
# Claude Code: 每天早 9 点跑一遍 triage
/loop "读昨天的 CI 失败和 Open Issue，写到 TODO.md，
修复标了 quick-win 的问题" --schedule "0 9 * * 1-5"
# Claude Code: 一直跑直到条件满足
/goal "test/auth 下全部测试通过，lint 干净"
# OpenAI Codex: 持久化目标
codex /goal "把计费模块迁移到新 pricing API，保持所有已有测试绿"
/goal 的巧妙之处在于，判断「完成」的不是写代码的那个模型，是一个独立的、更小的模型。 这叫 maker-checker split（制作-检查拆分），写代码的 Agent 给自己打分通常太宽松了。
一个端到端的循环长什么样
把它串起来看，一个完整循环是这样的：
定时任务（每个工作日早上触发）
│
▼
调用 Triage Skill（读 CI 失败、Open Issue、最近提交）
│
▼
写进度到 TODO.md（持久记忆）
│
▼
对每个值得做的发现：
├─ 开一个独立工作树
├─ Maker Sub-agent 写代码
└─ Checker Sub-agent 审代码
│
▼
Connectors 打开 PR + 更新 Issue
│
▼
明天早上再来一遍
状态文件（TODO.md / AGENTS.md / 某个 Issue Board）是这个循环的脊梁。它记住什么试过了、什么通过了、什么还在等着，明天早上的触发接着今天的进度跑。
头一次尝试的话，千万别上来就搞自动合代码。先搭一个最简单的：每天早上跑一遍，把 CI 失败整理成一条消息发给你。看几天循环表现，再决定让它帮你开 PR。
循环不解决的三个问题
循环改变了工作方式，但不代表你人就可以消失了。有三个问题随着循环变好反而变得更尖锐：
1. 验证责任依然在你
一个无人值守的循环，也是一个无人值守犯错的循环。你之所以要把 Checker 和 Maker 分开，就是要让循环说的「做完了」有点分量。即便如此，「做完了」是个声明，不是个证明。最终合进去的代码还是要人看。
2. 代码理解债增长更快
循环产代码的速度远快于你读代码的速度。一个顺畅的循环只是让这个差距拉大得更快——除非你坚持读它产出的每段代码。这和 AI 辅助编程一直以来的理解债问题一样，只是被加速了。
3. 认知放弃是最舒服的失败方式
循环自己跑得很顺的时候，你很容易就不带脑子了——它返回什么你就接受什么。「设计循环」本身是中性的：带判断力去设计，它是加速器；为了不动脑子而设计，它就是温水煮青蛙。两个人可以搭一模一样的一个循环，结果截然相反——一个在自己深入了解的工作上跑得更快，另一个干脆不了解了。循环不知道区别，但你知道。
现在上车的建议
Loop Engineering 还很早期，手动 prompt Agent 仍然有效。平衡方案在这：
- 对 重复的、可验证的 工作——搭循环
- 对 需要判断力的、一次性的 工作——保持手动
起步方案：一个定时任务每天早上 triage CI 失败，结果写到 Markdown 文件，发给你看。仅此而已。等你看懂了循环的脾气，再慢慢加子 Agent、加自动 PR。
另外注意 token 费用。一个定时循环每次触发都可能跑大量 token，带验证器的消耗更大。Boris Cherny 的原话是「Token 消耗差异极大，看你 Token 充裕还是紧张」。慢速起步，盯几天账单，再放大。
参考来源
本文由云栈社区编译，更多 AI 开发前沿内容欢迎访问 云栈社区。
发表于 1 小时前
|
查看: 5|
回复: 0
