AI AGENT 工程范式进化史 • 第五站 • LOOP ENGINEERING
校验器只说"错了"，它就把同一个答案又交了一遍。
12 号桌的番茄炒蛋已经重新进了后厨。第四站搭好的 Harness 做得很稳：原备注没有丢，免单有回执，重做单也准确发到了热菜档。
可新菜到了传菜口，复核员还是看见了葱花。系统把结果标成"不合格"，又让后厨重做一次。几分钟后，第三盘几乎一模一样。
工具没坏，权限没错，流程也真的跑了两遍。问题在于：校验器只说了错了 ，却没告诉下一轮哪里错、为什么错、应该改什么。
01 / 接住第四站
Harness 让结果可见，Loop 让结果改变下一轮。
Harness 解决的是执行现场：Agent 用什么工具、拥有什么权限、动作是否留下回执、失败后能否恢复。它能告诉我们，新菜的确重做了，也的确没有通过复核。
Loop 再往前一步：读取这一轮结果，形成有效反馈，修改下一次行动，并判断什么时候继续、什么时候停。
一句话区分：
Harness 让系统知道"刚才发生了什么"；Loop 让这些结果真正改变"接下来做什么"。
02 / 先拆掉一个误会
Loop 不是把同一个按钮多按几次。
2026 年 6 月 7 日，Addy Osmani 在《Loop Engineering》中把 Loop 描述为一种系统设计：系统自己发现任务、分配工作、检查结果、记录状态，再决定下一步，而不是每一轮都等人重新提示。
这并不意味着"循环越长越好"。只要反馈没有新增信息，第二轮就只是第一轮的复制；如果错误会累积，系统甚至可能越跑越偏、越跑越贵。
对这家餐馆来说，一个能改进的循环至少需要：清楚目标、一次尝试、可观察结果、能指导动作的反馈、跨轮状态，以及循环外面的停止规则。少了其中任何一个，圆圈画得再漂亮也只是重试。
03 / 反馈要有分辨率
"不合格"是结果，不是下一步。
低分辨率反馈只能判断输赢，例如"不合格""得分 62""顾客不满意"。这些信息可以触发重试，却不足以指导修正。
可执行反馈至少回答四个问题：目标是什么、实际观察到了什么、差距在哪里、下一轮建议改哪个动作。比如：盘面左上和中心检测到 3 处葱花；原备注要求完全不放葱；KDS 备注没有丢失；下一步应检查装饰料来源，而不是继续重复打印同一张单。
反馈的价值不在于批评得多严厉，而在于它有没有提供新的、可行动的信息。
04 / 谁来判断这一轮
能用尺子量的，别全交给模型猜。
餐馆里的验收并不只有一种。出餐时长、菜品温度、字段是否缺失，可以由确定性规则检查；表达是否得体、处理方案是否完整，可能需要模型评审；口味、过敏风险和顾客是否接受，则常常需要人来确认。
Anthropic 在 Evaluator--Optimizer 模式中强调：只有当评价标准足够清楚，而且反馈确实能让结果变好时，循环式优化才适合。执行者和评估者也最好分开，避免同一个角色既做菜又给自己打满分。
| 反馈来源 | 适合检查 | 不应假装能判断 |
|---|---|---|
| 确定性规则 | 时间、温度、字段、状态 | 口味与顾客感受 |
| 模型评审 | 文本质量、方案完整性 | 不可直接验证的真实世界状态 |
| 人或顾客 | 主观体验、高风险决定 | 不必人工盯住每个低风险步骤 |
05 / 让每一轮留下差异
没有跨轮状态，系统会不断重新发明旧错误。
有效循环不能只保存最终答案，还要记住：这一轮改了什么、检查得到什么、哪些约束已经通过、哪些问题仍然存在。否则下一轮只看到一句"再试一次"，很容易走回原路。
状态也不等于把全部历史对话重新塞回 Context。更有用的是一张结构化差异表：已尝试动作、结果指标、失败原因、下一步假设。这样既节省上下文，也能避免重复无效尝试。
06 / 别被单一分数带偏
修好了葱花，可能又把菜拖凉了。
循环最容易出现的副作用，是为了一个指标不断局部优化。系统终于做到盘面没有葱花，却因为重做三次多等了 18 分钟，新菜送到桌边已经凉了。
所以每一轮不能只检查刚才失败的那一项，还要回归验证所有硬约束：原备注、出餐温度、等待时间、成本和食品安全。否则 Loop 会在指标之间来回摆动，甚至用一个新错误盖住旧错误。
Loop 优化的不是某个孤立分数，而是在全部关键约束下完成目标。
07 / 循环必须有刹车
不停下来，不叫坚持，叫失控。
Anthropic 对 Agent 循环的建议包括明确停止条件，例如任务完成或达到最大迭代次数。真实系统还需要更多出口：连续几轮没有进展、成本或时间触顶、状态不确定、风险升高，都应该停止自动尝试。
停止后不是只返回"失败"。系统应该把目标、尝试历史、已确认结果、当前阻塞和建议动作一起交给人。这样经理接手时，不需要从聊天记录里重新猜现场发生了什么。
08 / 回到 12 号桌
第二轮真正变好的原因，是反馈改变了动作。
- 热菜档按照原备注重做番茄炒蛋；
- 传菜口复核发现盘面仍有 3 处葱花；
- 系统核对 KDS，确认"不放葱"备注已经正确送达；
- 反馈不再要求原样重做，而是指出问题可能来自共享装饰料勺；
- 后厨隔离装饰料，重新制作并再次复核；
- 0 处葱花、温度达标，新菜才送往 12 号桌，循环停止。
这里最重要的并不是做了三轮，而是每轮都有新证据：第二轮排除了"备注丢失"，第三轮修正了真正的动作来源。次数只是成本，信息增量才是循环前进的动力。
09 / 这一站的边界
一道菜能回炉，整间后厨却开始出现很多条回路。
Loop 让单个任务具备了自我检查和修正能力。但晚餐高峰时，热菜在返工、凉菜在复核、顾客等待确认、经理处理中断；这些循环还会争用灶台、传菜口和审批时间。
当分支、返工、人审、恢复和多个 Agent 同时出现，问题就不再只是"这一轮怎样改"，而是"整张执行网络怎样调度"。这正是下一站 Graph 要接住的部分。
第五站只带走一句 ：
没有可执行反馈、跨轮状态和停止规则的 Loop，只是让同一种错误自动发生更多次。
下一站预告不是所有 Workflow，
都值得升级成 Graph
多个循环开始互相影响时，我们再看整张执行网络。
【进入第六站 ·不是所有 Workflow，都值得升级成 Graph →】
关于这个系列
《AI Agent 工程范式进化史》------跟着同一家餐馆连续升级，一站一站讲透 AI Agent 工程的演进：
Prompt → Chain → Context → Harness → Loop → Graph → 还会有的...
参考来源 ：
1 Addy Osmani, Loop Engineering, 2026-06-07。正文用它说明由系统发现任务、检查结果、记录状态并决定下一步的 Loop Engineering 表述，以及循环需要成本约束和人工判断。
2 Anthropic, Building Effective Agents, 2024-12-19。正文用它说明 Evaluator--Optimizer 模式、环境反馈、停止条件，以及 Agent 循环可能增加成本并累积错误。
口径说明 ：
两篇来源主要讨论编程或通用 Agent。本文把相关原则映射到餐馆传菜口复核与回炉流程，是原创教学案例，不代表行业存在统一的 Loop Engineering 标准。12 号桌、38 元、3 处葱花、18 分钟和各轮状态均为示意，不是公开实验或真实门店数据；正文没有引用效果提升比例。