中文资料里几乎唯一把「loop 层评测」讲清楚的一篇。当 Agent 从「跑一次」进化到「自己驱动自己」（定时跑、自我重试、派生子 agent），评测对象就变了——这篇给出外层循环的完整评测项清单，现有藏书无一覆盖。
先修：a19（Harness 拆解）。正在做定时任务 Agent、多 Agent 系统、自我迭代工作流的团队必读。读完后用那张「设计 → 评测项」对照表，给你的外层循环逐项立项。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
内层（ReAct 的 Thought→Action→Observation）属 harness，管「一次跑好」；外层（定时重跑、自我喂给、派生子 agent）属 loop engineering，管「自己驱动自己」。评测单位分别是「这一次跑得对吗」和「整个过程健康吗」。
无限重试（对永远失败的任务反复重试）、自我说服式漂移（跨轮把错误越强化越深）、成本雪球（子 agent 无限派生）——单看任何一次运行都「正常」。
先怀疑轮次之间 / 子 agent 之间的状态没隔离干净（残留缓存、污染上下文），而不是 agent 不稳定——每轮迭代都该从干净、可复位的环境起步。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲我们讲了 harness——单个 agent 跑一次的环境：它怎么拿指令、取上下文、调工具、处理错误、走审批、记日志。但真正强大的 agent，往往不是"跑一次就完事"，而是自己驱动自己反复地跑：一轮不行再来一轮、把上一轮的教训喂给下一轮、必要时还派出几个"小弟"分头干活。管这一层的，就是最近很火的 Loop Engineering（循环工程）。
先把这一讲最重要的认知给你，因为它很容易被搞反：
Loop Engineering 不在 harness 里面，而在 harness 之上。harness 管"一个 agent 怎么跑好一次"；loop 管"怎么让这个 agent（和它派生的子 agent）自己一轮轮地跑下去"。
这一讲我们讲清这一层到底是什么，以及——它给评测带来了一类全新的对象。
"循环"这个词被用滥了，先拆成两层，你就不会晕：
一句话记牢：内层循环让一次运行转起来（harness 的事）；外层循环让整个 agent 自己驱动自己（loop 的事）。这一讲讲外层。
| 内层循环（属 harness，第 2 讲） | 外层循环（loop engineering，本讲） | |
|---|---|---|
| 范围 | 一次 agent 运行内部 | 跨多次运行 / 多个 agent |
| 典型形态 | ReAct 的 Thought→Action→Observation | 定时重跑、自我重试、派生子 agent |
| 谁在驱动 | 推进这一次任务 | agent 自己驱动自己、长时程自主 |
| 评测单位 | "这一次跑得对吗" | "自我驱动的整个过程健康吗" |
把"我们这几年到底在工程化什么"排成一条线，你能一眼看清 loop engineering 的位置——注意它在最上面：
关键性质：这四层是"堆叠"，不是"替代"。你得先有好的 prompt，才谈得上好的 context；先有一个靠谱的 harness（一次能跑好），才谈得上在它之上做好的 loop（反复跑、自驱）。地基没打好，上面堆的循环只会更快地把错误放大。
这也解释了为什么"harness engineering 会成为像 prompt engineering 一样的常识词"——因为大家逐渐意识到：决定 agent 上限的，早已不只是那句 prompt，而是它外面这几层系统。而评测，就是从下往上、一层层去验证这几层搭得好不好。
（顺便纠正一个流传的说法：有些资料把 loop 画在 harness 之前，那其实是把"内层 ReAct 循环"和"外层自驱循环"混为一谈了。按更主流、也更清晰的划分——harness 是"一个 agent 的环境"，loop 在其之上"驱动这个 agent"。本专栏采用后者。）
外层循环不是一个抽象概念，它有三种很具体的典型形态：
一、按节奏运行（cadence）。不是等用户来一次点一次，而是让 agent 定时或按事件反复地跑。比如"每天凌晨扫一遍所有待处理工单，逐个处理"，或"一有新告警就触发一次排查"。这让 agent 从"被动应答"变成"主动值守"。评测该盯：该触发时触发了吗、不该触发时有没有空转乱跑、每个周期是否在规定时间/预算内收工。
二、自我喂给 / 自我改进（self-feeding）。把上一轮的产出、失败、笔记，喂回给下一轮，让 agent 在迭代中自己变好。这有点像 Reflexion（让 agent 自我反思、把教训存进记忆再重试），但这里发生在外层——不是一次运行内部的反思，而是"这一整次跑完，带着教训再跑一整次"。评测该盯：迭代是不是真的在收敛（一轮比一轮好），还是在原地打转、甚至把错误越强化越深（自我说服）。
三、派生与编排子 agent（spawn & orchestrate）。一个主循环把大任务拆开，派生多个子 agent 分头去干（每个子 agent 自己有一套 harness），再把结果汇总。这就进入了多智能体的地界。评测该盯：任务拆分合不合理、子 agent 之间交接有没有丢信息、汇总对不对、会不会失控地无限派生。
三种形态都指向同一件事：agent 不再是"你叫它才动"，而是"自己知道什么时候动、动多久、动完再怎么动"。这份自主，正是威力所在，也是新风险所在——所以每一种形态，都对应一类新的评测。
把这三种能力堆叠起来，你就能造出能长时间自主运行、自我纠正、还会调兵遣将的 agent。这就是 loopcraft。
这才是我们最关心的：多了外层循环，评测的"单位"就变了。
第 2 讲你评的是"一次 harness 运行成没成"。而有了 loop engineering，你还得评"整个自驱循环"在长时程里健不健康。这是一组全新的问题：
| 外层循环的设计（怎么设计） | 对应的评测项（怎么验证） |
|---|---|
| 长时程目标与终止 | 整个循环知道何时算完、何时该停吗？会不会自驱到停不下来（外层无限循环）？ |
| 跨轮自我改进 | 一轮轮反馈自己，是真在收敛变好，还是原地打转、甚至越跑越偏（自我说服）？ |
| 子 agent 编排 | 派生、交接、汇总对不对？子 agent 之间会不会互相拖累？ |
| 累积成本 / 资源 | 外层跑很多轮，成本会不会滚雪球失控？ |
| 长时程上下文 / 记忆 | 跨轮次的信息保持得住吗？会不会腐烂（context rot）？ |
注意，这些和第 2 讲的评测项不重复、而是叠加：harness 层保证"每一次跑得对"，loop 层保证"反复跑、自己驱动的整个过程也是对的、收敛的、不失控的"。
这几类失败，单看任何一次运行都很正常，只有站在外层循环才看得见。举三个真实的例子：
这三种，正是外层循环评测要专门盯的东西——它们在第 2 讲的单次评测里，一个都照不出来。
Harness / Loop Engineering 管"怎么设计"，Agent Evaluation 管"怎么验证它设计得好不好"——一体两面。只不过这一讲，我们把镜头从"一次运行"拉到了"整个自驱循环"。
用退款 Agent 体会这个层级差别，最直观：
注意里面的 run_harness(...) 就是第 2 讲那一层——外层循环只是反复调用它、并决定何时重试、何时升级、何时停。
评这套"自驱循环"，你要看的就不再只是"单个退款对不对"了，而是：重试逻辑合不合理（会不会对一个永远失败的单无限重试）？该升级给人的有没有升级？跨一整天的累积成本有没有失控？整批的处理健康度如何？这些，都是单次 harness 评测照不到、必须在 loop 层才能评的东西。
最后一个实务点，它把这一讲和评测的可复现性连了起来。
外层循环反复地跑、还派生子 agent，如果轮次之间、子 agent 之间共享了脏状态（残留缓存、没清理的中间文件、被污染的上下文），你就会遇到和第 2 讲一样的麻烦——评测信号被污染：同一批任务今天跑通、明天没通过，你以为是 agent 不稳定，其实是上一轮的垃圾污染了这一轮。
所以那条老铁律，在 loop 层同样成立、而且更重要：每一次外层迭代、每一个派生出的子 agent，都该从一个干净、可复位的环境起步。一个无状态泄漏的自驱循环，天然就是一个容易被可靠评测的循环。反过来，如果你发现外层循环的评测结果总是飘忽不定、复现不了，第一个该怀疑的往往不是 agent，而是轮次之间/子 agent 之间的状态没隔离干净。
最后一句忠告：别一上来就追求酷炫的自驱循环。记住四层是"堆叠不替代"——如果你的 agent 连"跑好一次"（harness 层）都不稳，就急着让它"自己反复跑、还派小弟"，只会让错误以更快的速度、更大的规模爆发。
打个比方：外层循环是个放大器。harness 好，它放大你的产能；harness 不好，它放大你的事故。一个单次成功率只有 70% 的退款 agent，你让它每天自动跑几千单，等于每天制造上千个错误退款。
所以评测上也有个次序：先把 harness 层的评测做扎实、确认单次运行足够可靠，再上外层循环的评测。大多数团队现阶段其实还在"把一次跑好"这一层——这不丢人，反而是对的。把地基打牢，比堆花哨的循环重要得多。