循环工程：为什么你的 AI Agent 循环会"刷分"，以及怎么让它真正收敛

[Q00]

这是一篇写给中文读者的设计说明，讲 Ouroboros 最近合并的 RFC #1917 解决的两个问题。仓库的中文文档在 README.zh-CN.md，这个 RFC 的中文设计文档在 docs/hidden-checklist-convergence/README.zh-CN.md。

给 AI coding agent 套一个循环，是这两年几乎所有人都会想到的一步：跑一次不行就再跑一次，加个评估器打分，分数不够就重试。

但真正把这套东西跑到生产里的人，大概都撞过同两堵墙：

1. 分数上去了，东西还是错的。 Agent 学会了讨好评估器，而不是完成任务。
2. 失败之后就没有之后了。 循环的每个零件都写好了，但失败的那一次并没有真正流进下一次。

这两个都是环境设计的问题，不是模型的问题，也不会随着模型变强而消失。模型越强，找到抄近路的速度反而越快。

下面用一个开源项目 Ouroboros 最近合并的 RFC（#1917，实现在 #1916）当具体例子，因为它把这两个问题的修法都写在了代码里，可以直接对着读。

---

一、第一堵墙：你把答案抄给了考生

大多数 agent 框架在给 worker 下达任务时，会把验收标准原样贴进 prompt 里，包括用来判分的那条命令和那个断言。动机很朴素：让 agent 知道自己会被怎么检查，它才好对齐。

Ouroboros 早期版本也是这么干的，在 _build_success_contract_block 里把 verify_command 和 Expected output: <assertion> 一起渲染给了 worker。还有第二条泄露路径更隐蔽：重试的时候，失败原因里带着断言的 repr()，顺着 result.error 的尾巴又流回了下一轮 prompt。

问题在于，一旦 agent 看得见断言字符串，满足断言就永远比满足需求便宜。

RFC 里直接点了名：一个卡住的 worker 最省力的路径，就是去糊弄那个断言字符串，而不是去实现验收标准本身（项目里留了一份 seed_2be2907edc07 的复盘）。这就是典型的 reward hacking。你以为你在测能力，其实你在测抄答案的能力。

修法：无条件隐藏，而不是"可配置隐藏"

第一，两条泄露路径都得堵。 只堵正向那条没用：

• 正向：_build_success_contract_block 现在只渲染验收标准的描述和 expected_artifacts，验证由 harness 独立执行，worker 看不到判分逻辑。
• 反向：verify gate 的失败原因不再内嵌断言的 repr()；重试提示改由一个专门的、断言安全的 hint builder（orchestrator/retry_hints.py）生成，它会从每一个片段里把断言字符串过滤掉，包括那段 2000 字符的命令输出尾巴。

那个 2000 字符的尾巴值得单独抄走。堵住了主路径、忘了日志尾巴，泄露口还是开着的。

第二，没有开关。 RFC 明确写了：不提供任何"披露级别"的配置项，这个提案被显式否决了。

做框架的人本能反应是"给个 flag 让用户自己选"。但信息屏障一旦可以关掉，它就会在某个赶进度的下午被关掉，而且没人会发现，因为分数看起来更好了。

那 agent 失败了怎么办？给提示，不给答案

隐藏答案之后，worker 卡住了什么信息都没有，确实会原地打转。所以 RFC 用提示循环补上这一环：下一轮的指令不是从断言里抄的，而是从这次会话实际做了什么里重建的，包括工具调用轨迹、证据清单（只读复用 deliver_gate.load_ac_evidence_manifest）、验证器的结论。

	公开答案	轨迹提示
agent 看到	"断言要求输出等于 X"	"你调用了 A、B，产物里缺 C，验证在第 3 步失败"
最省力路径	伪造出 X	去把 C 做出来
分数上升是否代表能力上升	否	是

这就是信息不对称在起作用，和人类考试的安排一样：考官知道答案，考生只知道自己错在哪。

---

二、第二堵墙：失败是死路

RFC 里的原话是：每一个零件都存在，包括 verify gate、run→eval 链、evolve_step、Ralph driver、focus.select_evolution_focus，但没有任何东西把它们连起来。

结果就是：

• 跑失败的 run 根本不会进入正式评估。失败被当成终点，直接报 BLOCKED。
• 被评估拒绝的结果也不会进入演化。拒绝同样是终点。

于是循环名义上存在，实际上是三段互不相连的直线。失败没有被消化，只是被上报了。

修法：run → eval → evolve 接成一条链

改动本身不复杂，但有几个约束很关键：

1. 失败的 run 也要进评估。 _run_succeeded 的门槛放宽，只要产生了 session，就把它接进正式评估。同时保持 fail-open：入队失败绝不反过来改写 run 的结论。

2. 被拒绝的评估触发有预算的演化循环。 这里没有重新实现一个收敛循环，而是委派给已有的演化机制：评估的终态路径在 final_approved is False 时入队 ouroboros_start_ralph。

真正新写的那块叫 Gen1 bridge：把这次 run 的 seed 和评估产出的多 AC 清单投影成谱系事件，让 evolve_step 把这次普通的 run 当作第 1 代回放，然后从第 2 代开始带着焦点继续。

3. 只有失败的验收标准进入下一代，通过的冻结。 这条的性价比最高。

为了让 focus.select_evolution_focus 能正确冻结已通过的 AC，新写的 checklist→ACResult 转换器（mcp/tools/evaluate_ralph_chain.py）必须满足相当严格的要求：完整的索引覆盖、逐字一致的 ac_content、semantic_ac_key 同一性。

严到这个程度是有原因的：不冻结通过项的循环，会反复把已经做对的东西重做一遍，不但烧钱，还会把已经正确的实现改坏，最后表现为分数在两代之间来回震荡。

---

三、循环必须能停下来

套循环最危险的地方在于，它不会自己停。

Ouroboros 这里没有发明新的停止条件，直接复用了 Ralph 已有的那套：QA 通过、收敛、震荡检测、等级回退、墙钟超时。默认 execution.auto_evolve_max_generations = 3，取值范围钳制在 1..10。只有在预算耗尽之后才会真正报 BLOCKED。

其中震荡检测和等级回退是专门用来防假收敛的：分数在 A→B→A→B 之间来回跳，或者新一代比上一代更差，都要能被识别出来并叫停，而不是继续烧 token。

还有一个小修复。RFC 里提到 evolution/loop.py 有一个裸 except，三条路径都会静默地把 evaluation_summary 变成 None。修法不是加个日志，而是记录一份带失败原因的 rejected summary，保持 fail-closed 的焦点语义，同时让这次失败变成持久化的事实。

单次执行里吞掉一个异常，最多错一次；循环里吞掉一个异常，错误会被放大 N 代，而你在日志里什么都看不到。

---

四、便宜的关卡放在贵的前面

同样的思路贯穿了设计的其他部分。

Ouroboros 的评估是分层的：Mechanical（免费、确定性检查）→ Semantic → Multi-Model Consensus。能在第一层否掉的，绝不送去烧 LLM 判分。

访谈阶段用的是一个数，而不是分层。模糊度被量化为加权清晰度的反值：

Ambiguity = 1 - Σ(clarity_i × weight_i)

README 里那个 greenfield 的例子：

Goal:       0.9 * 0.4  = 0.36
Constraint: 0.8 * 0.3  = 0.24
Success:    0.7 * 0.3  = 0.21
                        ------
Clarity                = 0.81
Ambiguity = 1 - 0.81   = 0.19   <= 0.2 -> 可以进入 Seed

演化那头则要等本体相似度 ≥ 0.95 才算收敛。两道数学关卡，README 里把背后的想法写成一句话：没想清楚之前不要写，没稳定之前不要停。

---

五、可以拿去检查自己项目的三条

1. 别把判分标准给考生看。 检查你的框架有没有把 assert 字符串顺着错误信息、日志尾巴、重试 prompt 漏回去。正向路径和反向路径要一起堵，而且不要做成可配置项。
2. 失败必须有下一步。 失败的 run 要能进评估，被拒的评估要能进演化，通过的部分要冻结。零件齐全不等于循环成立。
3. 循环必须能停，还要能识破假收敛。 震荡检测、等级回退、墙钟、代数预算，一个都不能少。

RFC 全文在 Q00/ouroboros#1917，实现在 #1916，设计文档在仓库的 docs/hidden-checklist-convergence/ 下面（requirements / architecture / implementation 三份）。项目地址：github.com/Q00/ouroboros，中文 README 是 README.zh-CN.md。

有在生产里跑多代 agent 循环的朋友，你们是怎么处理假收敛的？这部分我见到的好答案最少。

[hardness1020]

隐藏断言这条修得挺干净，尤其是把 error 尾巴那 2000 字符也一起过滤掉，多数人只堵正向那条路就收工了。不过 hint builder 本身还是模型写的，它从工具轨迹里重建提示，重建得太具体一样会把答案漏回去，这块可能还得给断言字符串加一道出口检查。另外验收从 worker 手里拿走之后，判分那一侧就成了单点，checker 和 worker 同一个基座模型的话，独立性其实没那么强，换一份上下文只解决了一半。

agent loop 和验证循环这块我用 Python 拆成了教程，GitHub 上 500+ 星，仓库有中文 README：https://github.com/hardness1020/awesome-agent-architecture/tree/main/sections/21-loop-engineering

[Q00]

谢谢，这条读得很细，2000 字符那个尾巴确实是我们补的第二刀（orchestrator/parallel_executor.py:1745）。两个问题我都去对了代码，一个你说对了结论但机制不是那个，另一个我们做了一半，剩下一半你指得准。

1. hint builder：机制不同，但你的结论成立

hint builder 不是模型写的。build_assertion_safe_retry_hint（orchestrator/retry_hints.py:76）是确定性字符串拼接，整个模块没有任何模型调用；它从证据清单里取的事实也只有 args_preview 和 tool_name 两个字段（retry_hints.py:40-54），也就是 worker 自己的工具参数。worker 从头到尾没见过断言，它的工具轨迹重建不出一个它不知道的字符串。

但你说的"会把答案漏回去"是真的，只是入口更机械：断言是被 harness 自己的 verify_command 重新打印出来的，而脱敏是逐字的。hidden_contract_variants（orchestrator/contract_redaction.py:10）只枚举五种编码 —— 原文、repr、shlex.quote、json.dumps、以及去掉引号的 JSON —— 然后按长度倒序做字面 str.replace（:42）。

verify_command 的输出是任意程序输出，下面这些日常变形都能让逐字匹配失效，而字符串对模型仍然完全可读：

• 终端按 80 列折行
• diff 的行前缀（+ / - / > ）
• pytest --color=yes 在字符串中间插 ANSI 色码
• pytest 的断言重写加续行缩进
• 日志格式化做的大小写或空白归一

举个具体的：output_assertion = "MIGRATION_COMPLETE_v2"，失败输出在 pty 里折行，尾巴里就是 MIGRATION_COMPLETE_\nv2。五种变体一个都不匹配，原样进 ### Harness verification output (tail)。

第二道 redact_and_truncate_text（orchestrator/decomposition_policy.py:690）救不了，它只管 bearer token 和 secret 形态的键值对，不做任何归一化。

所以你说的"给断言字符串加一道出口检查"就是对的方向，而且不能靠继续加编码 —— 变形空间是开放的。已经开了 #2020，方向是归一化后按 span 脱敏（先剥 ANSI、折叠空白、去行前缀，再把偏移映射回原文），上面再叠一个相似度闸：任意窗口对断言超过阈值就整段抹掉。对输出尾巴这一段 fail closed，因为它风险最高、对重试质量的贡献最小。里面也写了你这条的机制归属，免得后来人去改错模块。

2. 独立性：分两层，一层不是模型，一层我们只做到厂商级

AC 级验收门根本没有模型。 它跑 verify_command 子进程，然后做一次子串判断：

if spec.output_assertion and spec.output_assertion not in combined:

（orchestrator/parallel_executor.py:9864）。这一层的"判分方"是一个 worker 看不见的确定性进程，不存在同基座的问题。

模型进来的是 evaluate 阶段的语义层和 Stage 3 共识层，你这条打的就是这里。我们做了一个 evaluation/reviewer_independence.py：从执行方的 backend 推出厂商，把已知同厂商的投票模型踢出陪审团（filter_voter_models:148），并给整次共识打一个状态标签 —— independent / unverified / same_vendor / unavailable（:50-53），这个状态会写进共识结果（evaluation/consensus.py:388）。

诚实说它的边界在哪：

• 厂商级，不是基座级。 同厂商不同型号会被踢掉，但这个粒度粗于你说的"同一个基座模型"。
• 单厂商用户身上基本是空转。 只装了一个 backend 的人，过滤没有可换的对象，状态就落在 same_vendor。
• 陪审团可用性优先于独立性。 踢完不足 _MIN_VIABLE_VOTERS 就整体回滚原名单（:168-170），注释里写的是"一个能投票的陪审团胜过一个完美独立但投不了票的"。
• 厂商不明的模型一律不踢，因为证明不了同厂商就不该凭空丢掉一票。

所以你那句"换一份上下文只解决了一半"我认。我们没打算用换上下文解决它，我们的选择是：能做成确定性的那一层就别放模型进去，放了模型的那一层就把独立性标出来而不是假装有。单厂商用户拿到的标签就是 same_vendor，这个字段不藏。

真正没做的是基座级识别 —— 厂商映射是一张 _BACKEND_VENDOR 表加一串子串启发式（:58、:79），它认不出两个不同厂商 API 后面是同一个基座权重。这个我暂时没有干净的解法，只能说边界在这里。

3. 你那个仓库

看了 21-loop-engineering，Failure modes 里 "Self-grading" 和 "Rubber-stamp rubric" 两条正好是我们踩过的坑，Per system 那张表现在是三列。Ouroboros 在这个题目上有具体可引的实现（隐藏契约、确定性验收门、reviewer independence 的四态标签，包括上面这些边界），我提个 PR 把它加成第四列，格式照你现有的行走，你觉得不合适直接关掉就行。

[Q00]

补一句，上面说的第四列没做成，改了形状：hardness1020/awesome-agent-architecture#61。

原因是硬约束，不是偷懒。你 CONTRIBUTING 里那条 awk 'length($0)>180'，section 21 的表格现在每行已经 175 到 178 个字符了，加第四列必须把你现有的三个 cell 压缩一遍。第一次提 PR 就去重写维护者的正文，我觉得不合适，所以没动。

改成在 Failure modes 里加两条，正好接在你已有的 Self-grading 和 Rubber-stamp rubric 下面：

• 同厂商 checker：你那条的缓解写的是"独立的 checker agent"，但两边在同一个 provider 后面就不算独立。给了我们的做法和它的边界（单厂商时过滤是空转，真正有用的是把状态标出来）。
• 藏起来的 rubric 从失败输出漏回去：就是你这次指出来的那条。这半边更值得写进去，因为第一个修复看起来是完整的，其实不是。

Sources 加了一条，列了四个文件，格式照 Hermes Agent 那行走。三个 README 同一个 commit 都改了，加的行没有 em dash，也都在 180 以内。

第四列你要是想要，我另开一个 PR 来压缩 cell，你说一声就行。