一句话：把「该不该算完成」的判断权，从模型挪到机械闸门
2026 年 10 月 8 日挂出的论文 Humanize（arXiv 2610.08900）盯着 agentic coding 一个老毛病：代码是 agent 写的，完没完成却由同一个 agent 自己判断，结果往往不可靠。它的解法叫「判断工程」——在规划、实现、评审、学习四个边界上，用确定性钩子强制做明确、可机械执行的裁决，而不是让模型自己拍板。论文里这套流程共设了 72 道机械关卡，把「完成」的定义焊进了流程本身。
机制拆解：四角色加确定性钩子，reviewer 刻意换厂商
Humanize 的工作流分三个角色：人先批准一份计划契约，框定需求与约束；builder 智能体分多轮实现，逐步推进；reviewer 智能体负责判定任务完成。关键点有两个。其一，路由工作的不是模型，而是确定性钩子，它们在角色之间搬运状态并强制 72 道关卡，避免模型偷懒跳过检查；其二，reviewer 特意来自另一家厂商，目的是切断「写代码的 agent 自己判完成」这种自验证偏差——自己写的、自己最弱裁判的闭环被强行打破。
为什么值得注意：可靠性竞争从模型强转向判断外置
今年编码智能体的可靠性讨论很多，但多数集中在评测或后训练层面：有的用过程级评测看轨迹偏差，有的用失败数据集训练。Humanize 的切入点更底层——它不假设模型更聪明，而是把「判断」这件事从模型内部抽出来，变成由流程强制、可复算的闸门。这与把感知能力加进编码 agent、或用后训练造专家、或让 agent 可改装的思路都不在一个层面：它关心的是「谁来判定完成」，而不是「写得多快」。
辩证看：仍是研究阶段，跨厂商评审有代价
需要说明，Humanize 目前仍是研究阶段，尚不对外公开可用，数字与结论都来自论文自述，缺少独立复现。它的局限也直接：请另一家厂商的 reviewer 必然增加延迟与成本；72 道关卡是否过重、会不会拖慢正常开发，仍需在真实工程里验证；此外，确定性钩子能拦住的是流程内的越界，拦不住目标本身设错。关于开源与可用时间，作者及行业暂未披露更多细节。
行业含义：编码 agent 的护城河在「可被强制的约束」
把 Humanize 放进今年的编码智能体演进里，趋势很清楚：可靠性的竞争正从「模型更强」转向「判断外置、机械强制」。谁能把完成判定、权限检查、回滚条件做成默认且不可绕过的约束，谁就更可能把编码 agent 送进生产。反之，凡是把「完没完成」交给模型自己良心的方案，都会反复踩同一个坑。
结语
Humanize 用判断工程与跨厂商 reviewer，把 agentic coding 的完成判定焊成 72 道机械关卡。它的价值不在又多一个评测分数，而在于把最不可靠的「自我裁判」从闭环里剔除。至于这 72 道关卡能否在工程实践里跑通，仍要看后续开源与独立验证。