Loop Engineering：别再手动 prompt 了，给 Agent 写个会自己干活的循环
- Loop engineering = 从‘手动给 Agent 写提示’升级到‘写程序/循环来驱动 Agent’：触发器 + 动作 + 反馈 + 停止条件 + 上下文锚点。
- 一句话本质：Agent 就是‘在循环里调用工具去达成目标’，真正的技能在于设计这个循环和它的反馈。
- 成败手在‘闭环’——必须有个能对 Agent 说‘不行，重做’的东西(测试/类型检查/评审)，否则就是 Agent 自己同意自己。
- 它不是 AutoGPT 的翻版炒作：缺的拼图(会推理的模型 + 反馈纪律 + 训练进 harness 的模型)到 2026 才凑齐。
先抛一句让我愣了一下的话。Claude Code 的作者 Boris Cherny 说，他现在基本不亲手给 Claude 写提示了——‘我有一堆 loop 在跑，是它们在 prompt Claude。’他报告自己一个月里 259 个 PR 几乎全是 Claude 通过这些循环写的，期间他没怎么打开过 IDE。
这就是 2026 年最火的工程实践：loop engineering(循环工程)。如果你最近老看到这个词、又没太搞懂它和‘写提示’‘搭 Agent’有啥区别，这篇给你讲透。
三级跳：prompt → context → loop
把这几年人和大模型协作方式的演化串起来看，是一条很清晰的升级路线：
- 2023 年是 prompt engineering：核心技能是‘把一句话写好’，对着对话框反复调措辞。
- 2024–2025 年是 context engineering：大家意识到模型表现不只取决于那句提示，而取决于喂给它的整个上下文——系统指令、检索到的知识、工具定义、对话摘要、任务元数据。技能从‘写好一句话’变成‘组织好一整个上下文窗口’，讲究 token 预算、来源标注、可观测、上下文回归测试。
- 2026 年轮到 loop engineering：你连‘每一轮喂什么’都不手动管了，而是写一个程序——一个带反馈、带护栏、能自我迭代的循环——让 Agent 在里面自动地一轮轮干下去。技能从‘组织上下文’变成‘设计循环’。
每一级都没有取代上一级，而是把它包进了更外层的自动化里。prompt 还在(每一轮循环里仍要给模型一段指令)，context 还在(每一轮的上下文仍要精心组织)，但人的注意力，从‘喂’这个动作，上移到了‘设计喂的机制’。
到底什么是 loop engineering
有个流传很广的极简定义：一个 Agent，就是‘在一个循环里调用工具，去达成一个目标’。注意这句话里其实有两个可设计的对象——工具，和循环。过去两年大家主要在卷工具(给模型接上搜索、代码执行、浏览器、MCP)，而 loop engineering 把焦点搬到了那个常被忽略的‘循环’本身。
再精炼一点：循环 = 定时器 + 一个决策器。和传统的 cron 脚本不同的是，每一拍(tick)该干什么，不是写死的 if-else 分支，而是让模型现场决定下一步动作。这就是它和普通自动化脚本的根本区别——决策是‘软’的、由模型即时生成的；而外层的调度、反馈、护栏，是‘硬’的、由你这个工程师写死的。软硬结合，才是 loop engineering 的精髓。
┌──────────────── 触发器(cron / 事件 / 定时)
▼
┌─────────────┐
│ 组织上下文 │ ◄─── 锚点文件(VISION.md / CLAUDE.md / 上一轮交接)
└─────┬───────┘
▼
┌─────────────┐
│ 模型决策 │ 这一拍干什么？(软：模型现场决定)
└─────┬───────┘
▼
调用工具(改代码 / 跑命令 / 读文件 / 搜索)
▼
┌─────────────┐
│ 反馈 / 验证 │ 测试过了吗？类型对吗？评审通过吗？(能说‘不’)
└─────┬───────┘
▼
停止条件？(完成 / 达上限 / 没进展 / 超预算)
├── 否 ──► 回到顶部，带着结果进下一拍
└── 是 ──► 退出 / 交接 / 通知人
一个设计良好的循环，通常包含这么几个零件，缺一个都会出问题：触发器(什么时候跑)、作用域(对哪些仓库/PR/文件跑)、动作(这一拍要它做什么)、反馈(怎么判断成没成)、停止条件(什么时候收手)、以及上下文锚点(把‘我们到底要干嘛’持久化下来，免得每一拍都重新猜)。
一个好用的心智模型：Agent 循环就是新的操作系统
我见过对 loop engineering 最妙的一个类比:把这个 Agent 循环当成一台操作系统来看。一旦这么想，很多设计决策就自然了:
操作系统 Agent 循环
──────────── ──────────────────────────────
CPU / 推理 ← LLM(负责思考和决策)
RAM(内存) ← 上下文窗口(工作记忆，而且有限！)
系统调用 syscall ← 工具调用(读写文件、跑命令、查库)
内核 kernel ← MCP / harness(中介，管控对外部系统的访问)
进程调度 ← 你的循环(决定每一拍跑什么、何时停)
第一性原理:上下文窗口 = RAM，而 RAM 是有限的。
‘上下文窗口是有限的 RAM’这一条，是整个 loop engineering 的物理约束。模型每一拍能‘看见’的东西就那么多，循环跑得越久，塞进来的历史、工具输出、错误信息就越多，迟早撑爆或被噪声淹没。所以循环工程里一大半的功夫，本质上是在做‘内存管理’——决定什么留、什么扔、什么换出到磁盘(锚点文件)、什么时候清空重来。
最难也最关键的一半:那个‘能说不’的东西
有句话我想加粗:loop engineering 的一半是设计循环，另一半是设计一个能对 Agent 说‘不行，重做’的东西。一个没有任何东西能 push back 的循环，等于让 Agent 自己批改自己的卷子——它会非常自信地宣布‘搞定了’，哪怕代码根本跑不起来。这是开环(open-loop)，在生产里是致命的。
闭环(closed-loop)就是给循环装上一个客观的、不会和稀泥的反馈源:单元测试、类型检查、编译、lint、端到端跑一遍、甚至一个独立的评审 Agent。它的作用不是‘帮忙’，是‘卡关’——只有它点头，循环才前进。下面是个最朴素的‘Ralph 模式’循环骨架(2025 年开始流行的写法)，你能直观看到反馈和护栏长在哪:
# 一个带反馈和护栏的最小 loop（示意）
max_iters=15
fails=0
for i in $(seq 1 $max_iters); do
# 1) 动作：用固定的提示文件 + 持久化的上下文喂给 agent
agent run --prompt PROMPT.md --context VISION.md CLAUDE.md
# 2) 反馈：那个‘能说不’的东西
if npm test && npm run typecheck; then
echo "✅ 第 $i 拍：绿了"
git commit -am "loop: iteration $i (green)"
# 3) 停止条件：任务完成就退出
task_done && break
fails=0
else
echo "❌ 第 $i 拍：没过"
fails=$((fails+1))
# 护栏：连续两次同样的失败 = 原地打转，停！
[ $fails -ge 2 ] && { echo "无进展，停手交给人"; break; }
fi
done
# 还有一道护栏没画出来：token/美元预算上限，到顶就睡觉
三道护栏几乎是标配，因为它们对应 loop 最常见的三种翻车:① 最大迭代数(防无限循环空转)；② 无进展检测——同一个错误重复出现就停(防它原地鬼打墙)；③ 预算上限(防 token 和 API 账单失控，loop 跑飞了能烧掉真金白银)。
上下文管理:为什么‘重置 + 交接’常常比‘压缩’更好
回到那条 RAM 约束。循环跑长了上下文会爆，传统做法是 compaction——把前面的对话原地压缩成摘要。但 Anthropic 的工程团队给了个反直觉的建议:很多时候，与其‘原地压缩’，不如‘清空重来’。具体做法是:让当前这一段 Agent 把工作状态写成一份结构化的交接文档(handoff artifact)，然后开一个全新的、干净的上下文窗口，把交接文档喂给新的一段继续干。
为什么?因为他们观察到一个现象叫‘上下文焦虑’(context anxiety):当上下文被一堆历史塞得很满、又被压缩得模模糊糊时，模型会倾向于‘赶紧收尾’，草草了事。给它一张干净的桌子 + 一份清晰的交接，反而能让它踏实地把活干完。代价是编排复杂度上升(你得管理这些交接和重启)——这恰恰又是 loop engineering 要解决的事。
别让 Agent 自己改自己的卷子:做事的和判事的要分开
当循环复杂到一定程度，单个 Agent 就扛不住了，多 Agent 编排成了主流。一个被反复验证有效的结构是三角色分工:Planner(把高层需求拆成详细规格)、Generator(一轮轮实现)、Evaluator(拿明确标准去检验)。
这里最重要的一条经验，呼应了上面‘能说不’的原则:把‘做事的 Agent’和‘判事的 Agent’分开，是个极强的杠杆。原因很硬核——模型对自己的产出几乎没有客观的自我评估能力，你让它评价自己的活，它会信心满满地夸自己，哪怕质量明显很烂。所以评审者必须是‘外部的、挑剔的’，而且最好让它去和真实运行的系统交互(比如用 Playwright MCP 真的点开页面看效果)，而不是对着静态输出空想。一个会怀疑的 evaluator，价值只在任务难度恰好卡在模型能力边缘时才最大;太简单或太难，它都帮不上忙——这本身也是个要权衡的工程判断。
这条路是怎么一步步走到今天的
如果你读过我之前写智能体的那几篇，会发现 loop engineering 不是凭空冒出来的，它是一条憋了四年的线终于通了:
- 2022 ReAct:论文层面第一次把‘推理 + 行动’的 while 循环形式化——Agent 循环的学术原型。
- 2023 AutoGPT:第一次productized的‘自主循环’，火爆但臭名昭著地空转。它喊对了需求(让 AI 自己拆任务循环干完)，但身体没长好——模型长程推理不可靠、没有像样的反馈纪律。
- 2024 o1:推理模型出现，给了循环一个能稳定走几十步、会自我纠错的‘大脑’——这是 AutoGPT 当年最缺的那块拼图。
- 2025 Ralph 模式:有纪律的 bash 循环 + 锚点文件 + 测试卡关，把‘自主循环’从玩具做成了能干活的东西。
- 2026 productized + 编排:Claude Code 的 /loop、/goal 这类命令把循环做成了一行能启动的产品；多 Agent 编排、并行子 Agent、靠 git 状态做崩溃恢复成了新前沿。
还有一个容易被忽略、但我觉得至关重要的变化:2025–2026 的 harness(Claude Code、Codex、Cursor 这些)，是和它们要驱动的模型‘一起训练’出来的——模型从第一天起就是‘在循环里’被训练的，agentic 的行为不是事后硬接上去的补丁，而是长在模型骨子里的。这就是为什么今天的循环比 2023 年的 AutoGPT 稳太多:不只是外层脚手架变好了，连里面那颗大脑都为‘在循环里干活’重新长过了。
那么，这又是一次炒作吗
我的判断:不是。但它也绝不是‘写个循环就躺着收 PR’的魔法。2023 年 AutoGPT 退烧时我写过一句话——它是个早产儿，喊对了需求，只是身体还没长好。2026 年，身体长好了:会推理的模型、闭环反馈的纪律、训练进 harness 的 agentic 能力，这三块缺了四年的拼图凑齐了。loop engineering 是 AutoGPT 那个梦想，第一次变得真正可兑现。
但要兑现，靠的恰恰是那些‘不性感’的工程纪律,而非循环本身:你的反馈源够不够客观(能不能真的说‘不’)、你的护栏够不够严(会不会烧光预算、会不会空转)、你的上下文管理够不够干净(会不会让模型焦虑摆烂)、你的 doer 和 judge 分没分开。换句话说，loop engineering 把工程师的核心技能，从‘会和模型对话’，彻底搬到了‘会设计一个让不可靠的智能体可靠地产出’的系统。这是从‘提示词艺术家’到‘自主系统工程师’的身份转变。
循环负责让 Agent 不停地动；反馈负责让它动对方向。前者是发动机，后者是方向盘——只给油门不给方向盘的车，跑得越快越危险。
最后说个有点元的事:你正在读的这篇文章，本身就是我在一个类似的循环里、让 AI 帮我查资料、起草、然后写进 Notion 完成的——我写一次想法，它在循环里把活干完。从这个角度说，loop engineering 不只是程序员的玩具，它正在变成所有‘和 AI 协作产出’的人的默认工作方式。会写提示是 2023 年的技能;会设计循环，是 2026 年的。