智能体编程（Agentic coding）降低了代码生成的成本，但实现可靠、准确的代码补全依然困难：负责编写代码的智能体，往往难以准确判断自身是否已真正完成任务。这是论文开篇的核心论断，也点出了当前智能体编码领域最隐蔽的痛点。
智能体编码让代码生成变得廉价，但可靠的完成度判断始终是难题。现有设计大多将完成度决策权交给执行任务的智能体——自精炼循环、Ralph 循环等模式本质上都是自我验收，模型的系统性盲区永远无法被自身发现。
Humanize 提出了一套以判断工程为核心的多智能体编排工作流，在规划、实现、评审、学习的边界上设置明确的机械执行决策点。人类审批计划契约，构建智能体分轮实现，另一评审智能体独立决定是否完成，确定性钩子负责工作流路由，72 道机械门控强制约束边界。
这套体系在真实场景中展现出了极强的落地能力：
- 108 天迭代 68 个版本，收获 1468 个 GitHub 星；
- 完成 567 个文件的 gem5 构建系统迁移；
- 在 MLSys 2026 FlashInfer 竞赛三个赛道全部进入前三；
- 拿下 IOI、IMO、IPhO 等多项奥赛满分与金牌；
- PutnamBench 取得 672/672 的满分成绩，登顶 Lean-Eval 排行榜。
本文将深入拆解 Humanize 的设计哲学、技术实现与落地经验，探讨判断工程如何成为智能体编码的下一个核心方向。
一、AI 编码的核心困境：生成很便宜，验收很昂贵
过去两年，智能体编码工具的爆发把写代码的边际成本打到了近乎为零。Claude Code、Codex CLI 这类工具不再是一次性 prompt 生成代码片段，反倒通过规划、实现、评审、修订的完整循环，朝着一个目标持续迭代。
但成本曲线的下降只停留在"生成"环节。随着代码量持续膨胀，错误会不断累积，更致命的问题在于：写出代码的智能体，本身就是一个不合格的验收者。语言模型很难在没有外部反馈的情况下纠正自身的推理，会天然偏向自己的输出，甚至会通过修改测试用例来达成"奖励作弊"。于是整个领域的核心挑战，从"怎么写出代码"，转向了"怎么验证代码是正确的、符合目标的、真正完成的"。
现有设计几乎都把完成度判断权交给了执行任务的智能体。自精炼循环让模型修订自己的输出，任务验证本身就是多智能体系统的主要失败类别；Ralph 循环反复给同一个编码智能体输入相同的 prompt，直到它自己宣布任务完成。这种"自我验收"的模式天生存在盲区——模型系统性判断错误的内容，它自身也系统性无法识别。
可靠的完成度判断，必须把规划、构建声明、评审、终止这几个决策点拆开，交给不同的角色，并且用机械规则强制执行，不能依赖模型的自觉。这正是 Humanize 这篇工作最核心的出发点。
二、判断工程：把验收权从构建者手里独立出来
Humanize 的整个设计始于一个最朴素的前提：不要去自动化一个人类都没法判断的计划。如果一个智能体在一次对话里同时完成规划、修改代码、宣布完成，人类就得从长长的对话记录或者 diff 里重建目标、变更和支撑证据，等验证做完，实现和评审的上下文都已经严重膨胀。
判断工程的核心，就是在规划、实现、评审、学习这几个阶段的边界上，放置明确的、由机械逻辑强制执行的决策点，而非交给模型自由发挥。整个设计遵循四条基本原则。
| 原则 |
说明 |
| 先判计划，再写代码 |
计划契约在执行前就固定目标、验收标准、范围和任务，给评审者提供稳定的判断基准。 |
| 构建与评审分离 |
1. 构建者每轮结束后输出摘要，将自身声明与证据对应，说明未完成项；2. 由另一个不同厂商的模型判断声明是否成立，并且只有它能宣布任务完成。 |
| 拆解完成度决策 |
1. 对齐评审检查声明是否符合计划，区分阻塞性问题和可延后的次要问题；2. 代码评审检查 diff 中的缺陷。一次变更可能符合计划但存在代码缺陷，也可能局部正确但偏离整体目标。 |
| 用证据衡量进度，而非轮次 |
1. 卡住的循环应该重新审视范围、升级处理或者终止；2. 完成的循环应该沉淀经验供后续任务复用。 |
这四条原则将 evaluator-optimizer 模式从单次响应扩展到了完整工作会话，并且整个编排逻辑通过确定性代码实现，而非写在 prompt 中。
图 1：三种模式的本质差异。(a) 单会话模式下，智能体自己宣布完成；(b) Ralph 循环加了停止钩子，但还是同一个智能体判断自己的工作；(c) Humanize 则把完成权完全交给了独立的评审者，并且每一轮都有机械门控做校验。底部的项目数据也直观展示了这套设计的落地成果：108 天 68 个版本，1468 个 GitHub 星，覆盖从构建迁移到奥赛竞赛的多元场景。
总之，判断工程的核心，在于对智能体的权力做拆分：构建权和验收权分离，规划权和执行权分离，并且用刚性的机械规则把边界焊死，不让任何一个角色越界。
三、系统实现：72 道机械门控下的 RLCR 循环
Humanize 以 Claude Code 插件的形式落地了这套工作流，核心循环叫做 RLCR——带 Codex 评审的 Ralph 循环。整个系统提供 5 个斜杠命令、4 个子智能体、6 项技能，并且对接了 Claude Code 的 4 类事件钩子。最终支撑这套体系的是 72 道由代码强制执行的机械门。
图 3：整个系统的核心骨架。所有状态流转都由钩子代码控制，而非由模型决定。模型只能输出工作结果和评审意见，能否进入下一阶段、是否终止，都由机械规则判断。(a) 规划阶段链路，横向划分人类、Claude、Codex 三类角色，依次覆盖创意生成、方案起草、方案精炼三步可选流程。过程中嵌入合规性校验、架构问答测试两道关卡，经过最多三轮交叉评审后，未决问题提交人类决策，最终输出具备契约效力的结构化计划。(b) RLCR 循环的状态机示意图，分为实现与评审两大阶段。实现阶段由 Claude Code 作为构建者迭代执行，默认 42 轮上限，连续停滞触发终止；评审阶段由 Codex 独立校验，通过停止钩子门控流转状态，支持修复循环、最终定稿、强制终止等多条出口。
3.1 规划即契约
规划阶段分为两个核心步骤。
- gen-idea 将粗糙的想法扩展为草稿，通过并行的只读子智能体探索不同方向；
- gen-plan 把草稿转化为结构化计划，生成计划的过程中禁止编写代码。
Claude 和 Codex 用最多三轮来起草和批判计划，无法达成共识的点最终交给人类决策。
计划的定位是契约，而非一次性 prompt。它明确定义了目标、带正反测试用例的验收标准、路径边界、分配给 Claude 的编码任务和分配给 Codex 的分析任务。
执行前还会执行两道前置检查：
- 一道是计划合规性检查，拒绝不相关计划和会破坏循环统计的分支切换指令；
- 另一道是问答测试，向人类提出两个关于计划机制和架构的选择题，通过增加少量摩擦，避免人类未充分理解就批准计划。
3.2 轮次协议：每一轮都是证据化交付
构建者在单个 Claude Code 会话中工作，每一轮的定义是"智能体认为整个计划已经完成"。Stop 钩子作为中介，负责每一次与评审者的交互，向评审侧提供计划、目标追踪器和上一轮的评审发现。目标追踪器中的不可变部分，永久保存目标和验收标准。
构建者每轮输出三类产物：提交记录、本轮契约（命名一个主线目标）、变更摘要及支撑证据、未完成工作清单。契约机制将次要问题排队处理，避免次要事项占用主线轮次。
图 4：Humanize Stop 钩子驱动的单轮交互完整流程。左侧 Claude Code 构建者完成一轮开发后，提交代码、本轮契约、声明摘要与证据材料；Stop 钩子先通过机械门控校验产物完整性，通过后调用全新上下文的 Codex 评审者，对照计划、历史记录与代码输出分级评审结论；最后钩子解析评审结果，自动触发下一轮开发、代码修复或循环终止。
当构建者试图停止时，钩子会先校验所有产物是否完整，再启动一个全新的 Codex 进程执行评审。评审者读取计划、近几轮记录、代码、构建者的声明与证据，将发现分为主线差距、阻塞性次要问题、排队次要问题三类，同时报告主线状态是推进、停滞还是倒退。返回 COMPLETE 状态要求计划全部完成，延后任务也算作未完成。
钩子负责解析评审结果，将发现转化为下一轮的 prompt。连续两轮停滞会触发漂移恢复提示。每五轮执行一次完整对齐评审，全面审计所有验收标准，只有此时才可以提议终止循环。
评审者验收实现后，循环进入代码评审阶段。Codex 对照基础提交检查 diff，输出带严重级别的发现。任何级别发现都会触发一轮修复；只有干净的评审结果才能进入最终的简化整理阶段。这个阶段不设置轮次上限。
整个循环定义了五个明确的终止状态：完成、评审判定停止/连续三轮停滞或倒退、达到实现阶段轮次上限（默认 42 轮）、用户取消、状态文件损坏。完成、达到上限或者评审要求停止后，分析智能体会将记录的轮次整理为方法论报告，用户两次确认后可作为 issue 提交。
3.3 72 道机械门：规则写进代码，而非写进 prompt
Humanize 不依赖 prompt 约束智能体行为，而是通过代码中的门控强制执行规则。72 道机械门按功能分为 10 大类，占比最高的三类分别是状态完整性、计划与范围保护、轮次隔离。
表 1：最大的门控类别保护状态、计划与轮次隔离。表格按类别分组了 Humanize 全部 72 道机械门，并列出了每类强制执行的约束。状态完整性的 12 道门确保构建者无法修改循环状态文件，每一次停止都校验格式和分支，状态损坏直接终止循环；轮次隔离的 10 道门确保摘要和契约仅针对当前轮次编写，无法读取其他轮次的文件——这一设计保证了评审者的上下文干净，不会被构建者之前的推理带偏。
整套系统中只有一道门是失效开放的：状态文件格式错误时，工具调用验证器会退出并返回错误码 1，而 Claude Code 会将其识别为非阻塞错误，调用继续执行。这也是整个系统为数不多的单点风险。
Humanize 的系统设计核心可以总结为一句话：所有流程边界用代码硬编码，所有角色权力靠门控做隔离。模型只负责产出内容和判断内容，不负责决定流程怎么走。
四、联合采样的数学本质：双模型马尔可夫链
为什么两个模型交替工作，就比一个模型自循环更可靠？Humanize 用马尔可夫链的视角给出了清晰的数学解释：编码会话本质上是代码仓库状态上的一条马尔可夫链，每一步的状态转移都由模型采样决定。
4.1 单个智能体
单个智能体的场景下，每一步状态都从同一个模型采样，即 $s_{t+1} \sim M(s_t)$，并且当同一个模型接受自己的状态时，循环就停止。此时提案和验收共享同一套盲区——凡是模型系统性判断错误的内容，它也系统性地无法识别。缺陷存活的概率就是 $b$，即构建者引入缺陷并且自身未检出的概率。
4.2 双模型交替模式
Humanize 采用双模型交替模式。构建者 $B$ 根据评审者的上一次发现提出下一个状态，即 $s_{t+1} \sim B(s_t, f_t)$；来自另一个厂商的评审者 $R$ 在全新上下文里返回发现，即 $f_{t+1} \sim R(s_{t+1})$，结果要么接受当前状态，要么给出下一次提案的约束条件。
这种模式类似双块吉布斯采样器，链条在两个条件分布之间交替，由两个不同的模型分别提供分布，因此每一步状态都受两个模型共同影响，并且链条只有在 $R$ 接受的状态下才能停止。
缺陷在单模型循环中存活的概率为 $b$，在交替循环中则为 $b \cdot m_R$，其中 $m_R$ 代表评审者在构建者未检出缺陷的前提下，同样未检出的概率。如果引入外部预言机（比如证明检查器、测试框架），还会增加第三个因子 $m_O$，即预言机的漏检率。最终缺陷被接受的概率为：
$$\Pr[\text{defect accepted}] = b \cdot m_R \cdot m_O$$
只要两个模型的盲区存在差异，$m_R$ 就会小于 1，联合链条接受的缺陷状态就会更少。这也是 Humanize 默认采用 Claude Code 作为构建者、Codex 作为评审者的原因——两个不同厂商的模型，盲区重叠度最低。
4.3 强外部预言机
如果存在强外部预言机，例如测试用例、形式化证明检查器，相当于第三道关卡。当 $m_O$ 趋近于 0 时，即便使用同一个模型兼任构建和评审，也能得到可靠结果。比如 PutnamBench 和 IMO 使用 Lean 证明内核作为预言机，IOI 使用在线评测系统作为预言机，这类场景下单模型双角色的配置也足够支撑。
图 2：单模型自循环、双模型交替采样、缺陷存活路径三种场景，与公式 $\Pr[\text{defect accepted}] = b \cdot m_R \cdot m_O$ 形成一一对应。单模式下，缺陷只要逃过自身检查就可以过关；双模式下，需要连续通过两道关卡。外部预言机相当于第三关，关卡越多，漏检概率越低。当然这种设计也有代价：评审者的误报同样会进入链条，转化为额外的迭代轮次，增加时间和计算成本，这也是后续复盘里"评审长尾"问题的根源。
双模型交替的本质，在于用两个不同分布的采样器做联合采样，通过盲区的差异对冲单模型的系统性偏差。外部预言机越强，对第二模型的依赖就越弱。
五、落地验证：从奥赛金牌到大型工程迁移
理论上成立的设计，还要经过真实场景的检验。Humanize 的验证覆盖了从形式化证明、算法竞赛到大型工程迁移的多个场景，既有可量化的基准测试，也有工业级真实项目。
5.1 基准与竞赛：满分背后的可信度差异
在纯技术基准上，Humanize 交出了非常亮眼的成绩单。PutnamBench 测试中取得 672/672 的满分成绩，在 Lean-Eval 排行榜上位列第一，超过 AxiomProver、Aleph Prover 等多个专业证明团队。
奥赛场景下，Humanize Olympiad Agents（HOA）同样表现突出：IOI 2026 六项任务全部获得满分；IMO 2026 六道题全部完成形式化证明；IPhO 2026 理论部分取得 30/30；IChO 2026 获得 418.5/437 的理论分，拿到金牌；IBO 2024 全部 100 道题与官方答案完全匹配。
不同场景的结果可信度存在差异，核心差异在于独立判断的来源。
- 存在完整外部预言机的场景，比如在线评测系统、形式化证明检查器，结果可信度最高；
- 仅有部分外部检查的场景，需要搭配另一个厂商的模型补充判断；
- 完全没有外部检查的场景，结果可信度最低。
5.2 工业级项目：567 个文件的构建系统迁移
gem5 构建系统迁移是最具代表性的工业级案例。项目目标是将 gem5 的 SCons 构建系统替换为 CMake+Ninja，并增加 Bazel 覆盖层，总共涉及 567 个文件，产生 133 次提交。整个过程由 Claude 负责构建，Codex 负责评审。第一作者通过完整构建、单元测试、仿真产物交叉比对验证了结果正确性。目前该 PR 已经向上游提交，正在等待维护者评审。
这个案例清晰地展示了智能体循环的能力边界：智能体可以产出这种规模的代码变更，但最终的验收权始终需要人类兜底。
5.3 内核设计智能体 KDA：MLSys 竞赛的前三
Kernel Design Agents（KDA）在 Humanize 循环的基础上，扩展了领域知识库和性能剖析反馈。
- KernelWiki 是一个检索库，包含生产内核 PR、竞赛提交和相关文档，构建者在设计和优化内核时可以查询；
- ncu-report-skill 将 Nsight Compute 的剖析结果转化为结构化证据，供构建者执行优化、供评审者校验验收标准。
每个内核的开发都经过三轮规划：正确内核实现、剖析引导优化、形状感知调度，每一轮规划都对应一个 RLCR 循环执行。
在 MLSys 2026 FlashInfer 竞赛 Full-Agent 组中，KDA 取得 MoE 赛道第一、DSA 赛道第二、GDN 赛道第三的成绩。其中 DSA 索引器相对官方基线的平均加速比达到 19.08 倍。
图 5：左图为单内核工作流：在 Humanize 基础循环之上，新增 KernelWiki 领域知识库供构建者检索参考，ncu-report-skill 将性能剖析转化为结构化证据，评审者结合官方 FlashInfer 测试基准做验收，分三个阶段逐步提升优化目标。右图消融实验显示，基础循环、知识库、剖析技能依次叠加，加速比从 3.71× 逐步提升至 8.58×。
消融实验清晰量化了每个组件的增益。基础 Humanize 循环带来 3.71 倍加速，叠加 KernelWiki 后提升到 6.14 倍，再加上剖析技能最终达到 8.58 倍。这说明判断工程的框架是基础底座，领域知识和专业工具可以在之上持续叠加，不断放大效果。
图 6：左图以评审者独立性为横轴、外部预言机强度为纵轴，将所有应用场景与基线方案定位在二维坐标系中：右上角如 IOI、PutnamBench 等具备强外部评测或形式化验证的场景可信度最高；gem5、KDA 等具备部分外部检查的场景居中；左下角单会话、Ralph 循环等自判自验的场景完全缺乏独立校验。右图对应缺陷存活概率公式，直观呈现构建者漏检、评审者漏检、预言机漏检三层递进过滤效应。
总之，Humanize 的能力边界非常清晰：外部预言机越强，结果越可靠；没有外部预言机的场景，独立评审能大幅降低缺陷率，但无法保证绝对正确。大型工程的最终验收，始终需要人类兜底。
六、118 份真实复盘：五个落地设计教训
比亮眼成绩更有价值的，是真实运行中暴露的问题。研究团队分析了 118 份公开的循环事后复盘报告，总结出五个关于智能体编排的核心教训。这些教训来自真实运行的踩坑经验。
对 118 份复盘的编码统计显示，工件状态、评审长尾、范围与计划、收敛、证据是出现频率最高的五类压力，其中评审长尾和收敛问题也是最常见的首要压力。
表 2：评审长尾与收敛是最常见的首要压力。统计覆盖 118 份复盘。"出现"允许每份报告有多个压力；"首要"为每份报告分配一个压力。评审长尾是头号问题，80% 的复盘都有出现，36% 的复盘将其作为首要压力。收敛问题位列第二，占 27% 的首要压力。反而很多人关注的"生成质量差、过度声明"只排在第六位，仅占 8% 的首要压力。这说明进入真实工程场景后，核心矛盾已经从"生成不对"转向"收不了尾"。
6.1 五个核心设计教训
基于这些数据，研究团队总结出五个核心设计教训：
| 教训 |
核心内容 |
| 独立评审靠谱但昂贵 |
45 份复盘提到构建者夸大完成度，评审结论整体可信度高，但逐点反馈的节奏会造成长尾评审；应批量分组相关发现，给评审者补充历史上下文 |
| 迭代不保证收敛 |
三分之二的轮次发生在验收后的代码评审阶段，无上限的评审会造成无效循环；每个阶段都需要设置终止边界，停止规则应匹配工作状态 |
| 计划与范围是判断边界 |
大计划和模糊标准会带来模糊的停止条件，构建与评审双方对契约的理解必须一致；阻塞、排队、修订三类问题要分开路由处理 |
| 证据环境决定终止 |
很多循环卡住源于无法收集一致证据，而非实现本身错误；验证是判断设计的一部分，强预言机可以替代第二模型的角色 |
| 循环自身也需被判断 |
自生成的复盘报告数量多但落地转化率低，具体 bug 修复远快于方法论建议；判断代码的系统也需要判断自身的流程 |
这五个教训共同指向一个方向：智能体编码的下一个主战场，在工程化判断能力。评审效率、终止合理性、计划清晰度、证据可靠性、系统自我迭代能力，这些才是真正需要突破的硬骨头。
七、总结与展望
Humanize 这篇工作最核心的价值，在于把"判断"这件事单独拎出来，作为智能体编码的核心设计问题。它没有追求更大的智能体组织、更炫的自主能力，而是做了非常克制但扎实的设计：两个模型角色，加上人类参与，用确定性钩子做路由，用机械门控做边界。
这项工作的核心贡献可以归纳为四个方面。
| 内容 |
说明 |
| 提出了判断工程的设计范式 |
将规划、构建、评审、终止的决策权拆分，用机械规则强制执行边界 |
| 用联合采样的数学框架解释了双模型交替的可靠性来源 |
给出了缺陷存活概率的量化公式 |
| 落地了完整的 RLCR 循环与 72 道机械门控 |
在从奥赛到工业迁移的多个场景验证了效果 |
| 通过 118 份真实复盘总结了落地中的核心教训 |
为整个领域指出了下一步方向 |
同时这项工作也存在明显的局限性。
- 系统深度依赖其他厂商的命令行工具，后续 Codex CLI 的版本更新破坏了插件的部分功能。
- 终止规则还比较粗糙，仅实现阶段有轮次上限，评审阶段没有约束，停止提议每五轮才触发一次。
- 门控仅检查产物的存在和格式，不校验内容，虚假摘要仍然需要评审者识别。
- 代码评审只看当前 diff，没有之前轮次的记忆。目前所有证据都来自观察性数据，还没有严格的受控对比实验。
下一代 Humanize 已经在开发中，核心方向是将循环从宿主 CLI 的钩子中迁移到独立运行时，摆脱对特定工具的依赖。除此之外，更智能的终止策略、给评审者增加历史记忆、闭环的自我改进机制，都是未来重要的优化方向。
智能体编码的前半场，比拼的是谁生成得更快、更多、更像人类。后半场，比拼的是谁能更可靠地交付、更清晰地验收、更可控地终止。判断工程的出现，标志着智能体编码开始从玩具走向工具，从炫技走向工程化。这只是一个开始，但方向已经非常清晰。如果你对多智能体系统和大模型实战感兴趣，欢迎来云栈社区与更多开发者交流探讨。
发表于 2 小时前
|
查看: 6|
回复: 0
