Humanize：让 Agent 真正做完

上一章的 KDA 案例讲清了一条完整的 kernel 开发流水线：任务定义、draft、plan、候选实现、benchmark 与记录。在 KDA 的术语里，写代码的一方叫 Coder，判定的一方叫 Verifier；本章按 Humanize 的叫法称它们为 builder 与 reviewer。KDA 留下了一个更尖锐的问题：当 builder 说“做完了”，这个“完成”由谁认定？如果认定者就是写代码的人，流程再完整也可能在最后一米失真。本章拆解 Humanize 对这个问题的回答，并把它落到可执行的协议上。

学习目标

读完本章，你应当能够：

解释为什么 Agent 的自评会系统性失真，并能复述 KDA 中“把自己第一版当 baseline”的案例；
用写/判分离、跨厂商 reviewer 与错误率模型说明“判断工程”的设计动机；
描述 RLCR 的完整环节：计划合同、builder、reviewer、72 道机械检查、进展判定与结束方式；
读懂 DSA indexer 消融中 3.71×、6.14×、8.58× 三个数字各自说明了什么；
区分 Humanize 1 的插件式协议与 Humanize 2 的 flow 运行时，理解 Flame Chase 的交替与隔离。

一次可疑的“完成”

Humanize 团队在 KDA 项目中记录过一个很有代表性的失败。Claude 写完第一版 kernel 后，把它当成了 baseline；后续版本只要比这个“自己的第一版”快，就被宣布为完成。与此同时，官方 baseline 根本没有被认真比较。代码能跑、测试也过了，但任务真正要求的“相对官方实现更快”并没有被验证。

这个案例的问题不在某一行代码，而在判断结构：

参照系漂移：baseline 被悄悄替换成更容易超过的对象，而不是任务规定的实现。
证据不完整：只报告了有利的测试，没有覆盖边界 shape、dtype 或最终状态。
自我确认：builder 在自己的上下文里解释自己的产物，容易把“我这样写是有道理的”当成“这样写是对的”。

这不是模型能力不足的偶发事件，而是角色冲突的必然结果。写代码的人同时对代码下结论，等于让考生自己批卷。Humanize 的核心主张因此不是“让 Agent 更聪明”，而是把判断从 builder 手里拿走，做成一套独立、可执行、可追责的流程。

判断工程：把“信”变成“验”

Humanize 把这类工作称为 Judgement Engineering（判断工程）：不指望通过一句“请仔细检查”提升可靠性，而是设计谁来判、看什么证据、在什么条件下必须停。论文从一个很值得记住的前提出发：不要自动化一个人无法判断的计划（do not automate a plan the human cannot judge）。由此展开四条原则：先判计划再写代码；写与判分离；把“完成”拆成对齐审查与代码审查；用证据而不是轮数衡量进展。落到工程上，它至少包含三层分离：

结构分离：builder 与 reviewer 使用不同的会话。reviewer 不继承 builder 的对话，只读取计划、代码、测试与 profiling 证据。
模型分离：默认让 Claude Code 写、Codex 判，尽量选择不同厂商的模型。同一个模型容易写错的地方，往往也正是它自己看不出来的地方，这就是“同源盲区”。
机械强制：用 hook、脚本与文件检查强制执行关键步骤，而不是在 prompt 里请求模型“记得检查”。

错误率模型

可以把一次循环中的缺陷存活概率写成一个乘法链。设 builder 单轮引入或遗留缺陷的概率为 b，独立 reviewer 的漏检率为 m_R，再叠加一层外部 oracle（人工复核、隐藏测试或更强验证）的漏检率 m_O：

只有 builder 自评：缺陷存活概率约为 b；
加上独立 reviewer：约为 b · m_R；
再加一层 oracle：约为 b · m_R · m_O。

把三层写成链式就是 b → b · m_R → b · m_R · m_O。论文用「两块 Gibbs 采样器」来解释这个交替：builder 与 reviewer 各自提供不同的条件分布，因此每一步都被两个模型塑形，而循环只能在 reviewer 认可的状态停下。这个模型的价值不在于精确预测，而在于指出两个设计杠杆：降低 m_R（换模型、换上下文、给证据）和增加独立层数（oracle）。它也提醒我们，乘法链成立依赖“错误不相关”的假设。如果 reviewer 与 builder 共享同样的知识盲区，或者 reviewer 只看 builder 整理过的摘要，那么实际漏检率会远高于乘积。跨厂商只能降低相关性，不能消除它；人工抽查仍然不可替代。论文明确指出外部 oracle（如证明检查器或测试 harness）会引入第三个漏检因子 m_O；把三层连写成 b → b · m_R → b · m_R · m_O 是便于记忆的表述，不是论文给出的精确预测公式。

RLCR：一条可执行的循环

RLCR 是 Ralph-Loop with Codex Review 的缩写。Ralph Loop 指让 Agent 在同一任务上反复迭代，RLCR 在每轮之间插入一个全新的 Codex reviewer，并把关键动作固化成协议。它大致包含以下环节。

写计划并签合同。builder 先产出 plan，说明要改什么、为什么、如何验证。计划合同固定四样东西：目标、验收标准（含正向与反向测试）、路径边界，以及任务分工（Claude 负责编码、Codex 负责分析）。注意计划合同与 KDA 的任务合同不是一回事：任务合同先定义「做什么、怎样算过」，计划合同在此基础上把「怎么做、分几步、谁负责」写成可执行承诺。开工前流程先做一次 plan-compliance 检查，拒绝与任务无关的计划和会破坏轮次记账的「切换分支」指令；再用两道选择题帮助人确认自己是否真的看懂了 plan 的机制与架构。这两道题是建议性的理解度检查，不替代人对计划的判断；人确认合同之后，builder 才能开工。
builder 实施。默认由 Claude Code 承担，读代码、改 kernel、编译、跑正确性与性能测试，并留下可复核的产物。
新上下文 review。Codex 在全新会话中读取任务、计划、diff、测试日志与 profiling 结果，不读取 builder 的自我辩解。它要回答的是“证据是否支持完成”，而不是“代码看起来是否合理”。
机械检查与 Stop hook。在 builder 试图结束会话时，Stop hook 触发 72 道机械检查中的 32 道（全套覆盖状态、计划、隔离、git、review、会话、产物、经验、环境与完成条件等类别）。缺文件、缺记录、隔离被破坏等硬性问题会直接阻止结束。
reviewer 判定进展。reviewer 把问题分为主线缺口（mainline gaps）、阻塞性支线问题（blocking side issues）与可排队支线问题（queued side issues），并报告主线是推进、停滞还是回退；论文强调用证据衡量进展，而不是用轮数。连续两轮停滞会触发漂移恢复提示，每第五轮是一次 Full Alignment Review，审计全部验收标准，循环的停止邀请也只发生在这种审查上。
按协议结束。结束不是一个模糊的“差不多了”，而是有限状态机中的一种明确状态。

72 道检查听起来很多，但它们的定位不是给代码质量打分，而是防止“口头完成”：该跑的命令跑了吗，baseline 是否被替换，测试是否被改松，reviewer 是否真的用了新会话，产物是否齐全。机械检查只能保证形式，语义判断仍由 reviewer 承担。两者缺一不可：只有 reviewer 容易漏，只有 gates 容易形式化。上述数量与类别来自 Humanize 论文（arXiv:2610.08900，2026-10），具体实现以仓库为准。

论文把 72 道 gate 按类别归档：其中 29 道住在工具调用与 prompt 校验器里（只有 Claude Code 插件会安装它们），32 道跑在 Stop hook 上，其余 11 道分布在状态文件、计划副本与轮次隔离等位置。论文也诚实记录了一处**失效即放行（fail open）**的缺口：状态文件损坏时，工具调用校验器以退出码 1 结束，而 Claude Code 把它当作非阻塞错误，调用照常继续。这类「形式完备但实现有洞」的细节，是判断工程本身也需要被复盘的原因。

结束方式	含义	是否算成功
complete	reviewer 接受，且证据满足计划与验收标准	是
stop	reviewer 判定停止，或连续三轮停滞/回退	不一定
maxiter	达到实现阶段的轮数上限（默认 42 轮），循环被截断	否，通常应视为未完成
cancel	需要用户请求才能触发的取消	否
unexpected	状态文件损坏等异常导致的退出	否，需要复盘

论文还基于 108 天、118 份公开复盘（postmortem）总结失败模式。这些复盘来自公开 issue 里的方法论报告：仓库共 150 条 issue、52 位作者，其中 118 条是真实循环的复盘。这个数字的意义在于：判断工程不是一次性 prompt 技巧，而是需要长期运营的流程；失败案例本身也是资产，可以用来更新 gates、reviewer 提示与任务模板。

论文同时报告了两组值得警惕的数据：在记录了轮次数的 93 份复盘里，循环轮数中位数为 10 轮、最长 87 轮；而在区分阶段的 27 份复盘里，541 轮中有 364 轮（67.3%）发生在实现已被接受之后的 code review 阶段——作者据此指出，停止机制仍然是这套体系的薄弱环节。换句话说，reviewer 很会挑错，但「什么时候该停」依然难。这也是为什么Agent 与 harness要把预算与停止条件写进 harness：什么时候停，不能由 agent 自己判断。

把流程串起来

Humanize 的 RLCR 闭环：builder 与 reviewer 写判分离，reviewer 在新上下文中对照计划合同与机械 gates 作出判定。

上图把计划合同、理解度检查、builder、独立 reviewer、72 道 gates 与结束判定串成一条闭环。读图时注意三个位置：reviewer 使用的是新上下文，而不是 builder 会话的延续；其中 32 道 gates 在 Stop 时触发，属于强制层；只有 reviewer 能给出 complete，builder 的自述不构成完成信号。图中的回路表示“未通过就继续”，但继续的前提是拿到新证据，而不是单纯再跑一轮。

证据：消融与真实结果

Humanize 论文转述了一组很能说明问题的消融（论文措辞为团队报告的 ablation）：在 DSA indexer 任务、48 小时预算下，相对同一 baseline，仅使用 RLCR 达到 3.71×，加入 KernelWiki 后达到 6.14×，再加入 profiling skill 后达到 8.58×；同一设置下，论文对比的另一个 kernel 生成系统 K-Search 为 1.37×。

配置	报告结果	说明了什么
仅 RLCR	3.71×	写/判分离与循环本身就能显著改善，但仍受限于领域知识
RLCR + KernelWiki	6.14×	可检索的算子与迁移知识减少了盲目搜索，方向更准
RLCR + KernelWiki + profiling skill	8.58×	把“猜瓶颈”变成“读证据”，优化动作更有针对性

来源：Humanize 论文（2026-10）转述的团队报告，任务为 DSA indexer，预算 48 小时；同文给出 K-Search 基线为 1.37×。这三档是同一任务上的逐步叠加，不能拆开当作独立结论外推。还要注意任务边界：这里的 DSA indexer 与 KDA 案例里 v0.5 的 DSA Attention 是两个不同的 kernel，3.71×/6.14×/8.58× 不能和 1.408× 直接比较。

这三个数字不应被读成“加一个 skill 就自动乘 1.6”。它们对应同一任务、同一预算下的逐步叠加，说明的是信息质量对 Agent 行为的放大作用：reviewer 降低了错误结论的存活率，KernelWiki 提供了正确候选，profiling skill 让候选优化命中真实瓶颈。换任务、换硬件、换预算，数值都会变化。

论文的应用章节还报告了以下结果（主要来自 Humanize 论文的应用报告，2026-10；这些是公开材料中的最好结果，不代表普遍保证）：

场景	报告结果	来源与时间
MLSys 2026 FlashInfer Full-Agent 赛道	MoE 第一、DSA 第二、GDN 第三	Humanize 论文及中文解读，2026-10
PutnamBench	672/672	Humanize 论文，2026-10
Lean-Eval legacy 榜单	251/303，排名第一	Humanize 论文，2026-10
Loom 搜索（放置与布线）	180 秒预算下，探索的候选提案数从 97,138 提升到 227,777，约 2.34×	Humanize 论文，2026-10
gem5 构建系统迁移	567 个文件、133 个 commit，把 SCons 换成 CMake 与 Ninja	Humanize 论文，2026-10
HOA（Humanize Olympiad Agents）竞赛	IOI 2026、IMO 2026、IPhO 2026、IBO 2024 报告满分；IChO 2026 得 418.5/437（金牌）	Humanize 论文，2026-10

读这张表时有三个细节值得注意。第一，Loom 的 2.34× 是吞吐结果，论文明确说明它不代表映射质量更好——四个更快的候选因为破坏了与参考映射的逐层决策轨迹等价性（trace equivalence）而被回退。第二，gem5 迁移虽然由 agent 完成，论文成稿时仍处在上游 review 中（under upstream review），最终是否接收由人决定。第三，这些数字覆盖 kernel、形式化证明、竞赛题与大型构建迁移，说明“判断工程”并不绑定 GPU；但论文也自陈这是应用报告而非受控对比，论文展示的是成功案例，失败与成本细节需要回到原始材料核对。引用这些数字时，至少同时写出任务、预算与时间。

Humanize 2：从插件到 flow 运行时

Humanize 1 以 Claude Code 插件的形态存在，KDA 把它作为可选的规划与迭代工具安装；它依靠 hook 把 RLCR 协议嵌进会话：论文描述插件提供五个斜杠命令、四个 subagent、六个 skill，以及覆盖四个 Claude Code 事件的 hook；RLCR 本身分两个阶段，Implementation 阶段由 Claude 产出、Codex 复核摘要，Code Review 阶段由 Codex 对 diff 出带严重级别的结论并驱动修复轮。Humanize 2（仓库中的 hmz）把编排搬到独立运行时：一个 flow 就是一段 Python async 函数，两轮之间可以运行任意代码，因而可以插入检查、分支、预算控制与自定义工具。

截至 2026-10-29，公开材料显示它具备这些特征（项目仍在演进，具体能力以官方文档为准）：

CLI 可组合：官方文档写的是 13 个 coding agent（包括 Claude Code、Codex 等），另加任何支持 ACP 协议的 agent；builder 与 reviewer 可以是其中任意一个，而不是固定绑定两家。CLI 侧不同后端需要各自的可选依赖包，例如 DeepSeek Harness 对应 hmz[dsh]、Kimi 对应 hmz[kimi]、直连模型 API 的路径对应 hmz[litellm]。
预算可编排：可以按时间、token 或美元封顶，让“继续跑”变成一个有成本的决策；官方文档的措辞是预算用完即停，而不是事后统计。
运行可后台化：一次运行可以在后台继续（本机或自有服务器），中断后能从上次的位置接着跑。
flow 可复用：Humanize 1 的 RLCR 被拆成三个 flow 放到 humanize1-flow：gen-idea 生成想法、gen-plan 生成计划、RLCR 执行带 review 的构建循环；社区 flow 汇总在 flowverse，其 flows/ 目录当前可见 aot、flame_chasoid、humanize1、recursive_lean_prover 等条目。

维度	Humanize 1	Humanize 2
形态	Claude Code 插件与 hook 协议	独立运行时（`hmz`），flow 为 async 函数
组合	默认 Claude Code + Codex	13 个 coding agent 中任选，另支持 ACP
控制	72 道机械检查（32 道在 Stop hook）	代码级编排、时间/token/美元预算
典型 flow	RLCR	Flame Chase、ralph_loop 等

Flame Chase：只共享工作目录

Flame Chase 的会话模型：两个 agent 交替，每轮开新 session；对话不共享，唯一的共享状态是工作目录。

Flame Chase 把“写/判分离”推进到更彻底的形式：两个 Agent 轮流处理同一任务，每一轮都开新 session，彼此看不到对方的对话，唯一传递的是共享工作目录。上图的两个角色交替出现，中间的箭头不是聊天记录，而是目录中的代码、计划、日志与提交。

这种设计把状态外置到文件系统：上一轮为什么这样改、哪些假设已验证、哪些路走不通，必须写进工作目录，下一轮才能接上。它带来两个好处：上下文不会被上一轮的自我叙事污染；每个 Agent 都被迫产出可交接的证据。代价是交接成本高，读目录、重建上下文都要花 token；任务越需要紧密协作，这种隔离越可能拖慢进度。它更适合长周期、可分解、验证明确的任务，而不是需要两个人实时讨论的探索。

读图后可以对照 Humanize 1：RLCR 是“同一任务、builder 与 reviewer 分工明确”的循环；Flame Chase 是“同一任务、两个执行者轮流接力”的循环。前者强调判定权，后者强调上下文隔离与状态外置。KDA 官方博客在介绍 v0.6 时明确写出，该版本换用了更强的 Humanize2 flows，其中包括 flame chase 以及带周期性工作区清理的迭代优化（KDA² 博客，2026-09-27）；具体版本与效果以官方发布为准。

如何借鉴与常见误区

即使不使用 Humanize 全套工具，也可以借用它的设计顺序：

先把任务写成可验收的合同：命令、baseline、容差、性能门槛、禁止事项。
把判断从执行会话中拿出来：新上下文、尽量不同模型、只给证据。
把关键动作机械化：缺产物就阻止结束，baseline 被改就报错。
给循环设预算：最大轮数、时间、花费，达到上限必须停下来复盘。
记录每次保留与放弃的理由，把失败沉淀成下一轮的检查项。

常见误区	后果	修正
只在 prompt 里写“请认真 review”	reviewer 倾向附和，漏检率高	新会话、独立模型、固定检查清单
reviewer 直接读 builder 的对话	被 builder 的叙事锚定	只给计划、diff、日志与指标
把 72 道 gates 当质量分	形式齐全但语义错误仍可通过	gates 管形式，reviewer 管语义
不设轮数与预算	循环空转，成本失控	明确 maxiter、时间与费用上限
直接套用论文倍数	换任务后预期失真	记录本地 baseline，按同条件复测

本章自检

我能用自己的话解释：为什么“写的人”不适合当最终的“判的人”。
我能画出 RLCR 的闭环，并指出 reviewer 的新上下文与 Stop hook 各自解决什么问题。
我能写出错误率模型 b → b · m_R → b · m_R · m_O，并说明它的独立性假设。
我能解释 3.71×、6.14×、8.58× 三个数字分别对应什么配置，并说明它们不能外推。
我能说出计划合同固定了哪四样东西，以及两道选择题的作用与局限。
我能区分任务合同与计划合同：前者定义「做什么、怎样算过」，后者定义「怎么做、分几步、谁负责」。
我能解释 72 道 gate 的分布（29 道在校验器、32 道在 Stop hook）以及一处 fail open 的含义。
我能区分 Humanize 1 的插件协议与 Humanize 2 的 flow 运行时。
我能说清 Flame Chase 中“只共享工作目录”的好处与代价。

练习

L3进阶45 分钟

为 kernel 任务设计一份 reviewer 检查清单

目标：把“请仔细检查”改写成一份 reviewer 可执行、builder 无法轻易绕过的检查清单。

任务：

选择一个你熟悉的小 kernel（如 softmax、layer norm 或向量加），写一段 10 行以内的任务说明，必须包含 baseline、正确性命令、性能命令与通过条件。
列出至少 8 条 reviewer 检查项，覆盖：baseline 是否被替换、测试是否被改松、shape 与 dtype 覆盖、是否正确处理边界、性能数据是否可复现、日志与产物是否齐全。
为每条检查项标注证据来源（diff、测试日志、benchmark 输出、profiling 文件），并写出“不通过时 reviewer 应说什么”。
额外设计 2 条机械检查，要求能由脚本自动判定，例如“baseline 字段是否与任务文件一致”。

验收标准：

每条检查都能指向一个具体文件或命令输出，而不是主观判断；
至少有一条检查专门针对“偷换 baseline”，一条针对“放宽容差”；
清单能让另一位同学在不询问你的情况下复现判定；
用一段话说明哪些检查必须由人判断，不能机械化。

提示

先从失败案例倒推：把你自己或 Agent 曾经“假装完成”的方式列出来，再为每种方式设计一条检查。机械检查优先检查“文件是否存在、字段是否一致、命令是否执行”，语义检查再判断“结果是否支持结论”。不要把检查项写成“代码质量要好”这类无法验证的句子。