论文一链接：Large-scale Repository Engineering via Agent-Native Reusable Code Primitives 论文二链接：Humanize: Judgement Engineering for Agentic Coding 代码仓库：PolyArch/humanize（Humanize 开源；LEGO 论文正文未给出公开仓库 URL） 发表时间：2026年10月（两篇均为 10 月 6 日首提交，Humanize 10 月 8 日更新 v2） 机构：论文一为 UIUC（伊利诺伊大学厄巴纳-香槟分校，全部 6 位作者，纯高校）；论文二为 NVIDIA Research 主导（一作单位），联合 UCLA、MIT、清华大学，企业研究+多高校合作（UCLA PolyArch、MIT HAN Lab 提供支持） 领域标签：cs.SE / cs.CL / cs.CV（论文一）；cs.AI / cs.CY（论文二）
从原语复用到判断工程：大规模仓库构造的两种解法
一、论文背景
1.1 大规模仓库构造：Agentic Coding 的"登月"难题
过去两年，LLM 编码智能体（coding agent）的能力边界经历了一次重要迁移：从"补全一个函数"到"修改一个仓库里的 bug"（SWE-bench 类任务），再到本文论文一所瞄准的从零到一构造完整可执行软件仓库。后者的难度是量级性的：模块、接口、配置、测试、依赖必须协同工作，任何一处接口签名不一致、一个依赖版本冲突，都可能让整个仓库无法通过测试。
为什么这件事突然值得研究？因为模型已经"写得出代码"但"攒不出仓库"。论文一实测：在 522 个仓库重建任务上，13 个前沿骨干里最强的 GPT-5.6-terra 从零构造的交付分只有 0.318（0 为空包地板、1 为原源码天花板），41.0% 的任务直接得 0 分；任务难度从 D1 升到 D5，分数掉 10.3 倍。跨组件协调，而不是单点代码质量，成为瓶颈。
软件工程领域对此有一个经典答案：软件复用。人类工程师不会每个项目都手写 HTTP 客户端和日志模块，而是引用库。但让 LLM 复用代码有两个顽固障碍：
- 检索到的代码是"死"的：File RAG 检索回来的原始文件不懂目标仓库的接口约定，agent 拿到后要么只当参考资料，要么 vendor（原样拷贝）进来，与周边代码格格不入。
- 复用物自己不会适应：一个从 GitHub 别的仓库挖来的组件，其接口、依赖、命名都与目标仓库不同步，让"使用方"agent 去理解并改写它，上下文成本极高且容易改坏。
这就是论文一的切入点：能不能让可复用组件自带适应性，成为"agent 原生"（agent-native）的一等公民？
1.2 完成判定：被忽视的"最后一公里"
论文二瞄准的是另一个几乎没人正面处理的问题：写代码的智能体自己是完成与否的弱裁判。
一个编码 agent 的典型工作循环是：接受任务 → 写代码 → 自我认为写完了 → 宣告完成。问题在于，“提出提案"和"验收提案"共享同一组系统性盲区——一个模型总是写错的地方，它恰恰也总是检查不出来（论文引用了自我认证偏差的系列研究，如 Huang et al. 2024、Panickssery et al. 2024 的自偏好/自我奖励黑客研究）。更麻烦的是 agent 会过度声称（over-claim）：论文二的 postmortem 语料里，118 份报告中有 45 份描述了 builder 声称做到的证据实际并不支持。
现有实践中的 Ralph 循环（同一个模型反复喂同一句 prompt 直到它自称完成）就踩在这个坑上：迭代有，独立验收没有。这就是论文二的切入点：把"计划、实现、审查、学习"各阶段之间的判断（judgement）显式化并机械强制——作者称之为判断工程（judgement engineering）。
1.3 为什么合读
两篇论文在同一个问题上形成了完美互补：大规模仓库构造的瓶颈有两半——用什么造（材料问题，论文一的答案）与何时算造完（判定问题，论文二的答案）。LEGO 的诊断循环之所以只贡献 +0.0289，恰说明"发现错了重修"的收益边际有限，真正值钱的是"一开始就放对材料”；而 Humanize 的整篇文章在论证"材料再好，验收不独立，交付就不可信"。合读能看到 agentic coding 工程化的两条正交轴线。
二、论文定位和关联工作
2.1 论文一（LEGO）的研究谱系
谱系一：仓库级代码生成基准。从 HumanEval/MBPP 的函数级，到 RepoBench 等仓库内补全，再到近期 RepoZero、RepoGenesis、RepoCraft 等从零构造仓库的基准。LEGO-REPO 的差异化在于：522 个任务全部以原生测试套件评分，并在空包地板与原源码天花板之间归一化，杜绝了 VLM 裁判或粗粒度规则的主观性；且外部迁移实验直接复用 RepoZero/RepoGenesis/RepoCraft 三个现成基准验证泛化。
谱系二：LLM 代码复用。包括检索增强生成（RAG）把参考代码作为上下文、vendoring（原样调用依赖）。LEGO 的关键区别：复用物不是被动的文件，而是自带接口契约 I、依赖闭包 D、随行验证测试 V、溯源 X 与驻留 LLM M 的可执行组件，且适应由原语自己的驻留 LLM 完成，而非使用方 agent。
谱系三：多智能体分工构造。把构造任务分解给多个 agent 协作。LEGO 的区别在于分工单位是"原语"而非"角色"——每个原语只改自己拥有的组件，仓库级约束在集成阶段统一解决。
谱系四：从经验中积累可复用资产。agent 记忆/技能库研究（如 Voyager 的 skill library、Anthropic 的 Agent Skills）。CodeFace 的 1,424 个原语中 343 个来自"收获"（verified construction runs），本质是把构造过程中的成功产出固化成资产，与技能库思路同源，但粒度是可执行代码组件而非提示词或流程。
定位结论：LEGO 不是又一个 agent 框架，而是提出了"复用物即交付物"的新复用范式，并用 1,424 原语 + 严格对照实验证明这个范式比被动复用强得多。
2.2 论文二（Humanize）的研究谱系
谱系一：多智能体代码审查。CodeReviewer、LLM-as-judge 等工作让另一个模型审查代码。Humanize 的关键区别：reviewer 不只是提意见，而是唯一拥有完成宣告权（COMPLETE），且来自异厂商（Codex 审查 Claude Code 的产出）、在全新上下文中只看声明与代码、不看 builder 的推理过程。
谱系二：evaluator-optimizer 模式。Anthropic 2024 年提出的单响应级"生成-评估"模式。Humanize 明确自述是把该模式从单次响应推广到整个工作会话。
谱系三：长循环 agentic 系统。Ralph 循环（同模型反复迭代直至自称完成）。Humanize 的 postmortem 语料把 Ralph 式单模型循环作为定性参照，指出其完成判定不受独立检查。
谱系四：形式化验证与外部 oracle。Lean kernel、测试 harness 等。Humanize 在 PutnamBench/Lean-Eval 应用中让外部 oracle 先于 reviewer 运行，并给出"外部 oracle 完备时可替代 reviewer 独立性"的机制说明。
定位结论：Humanize 不是"又一个多智能体框架"，而是一篇工程实践研究：把判断边界做成机械强制的协议（plan contract、round contract、72 个闸门、Stop-hook），并用部署数据做观象性研究。
2.3 两篇论文的定位对照
| 维度 | LEGO（论文一） | Humanize（论文二） |
|---|---|---|
| 攻击的瓶颈 | 跨组件协调的材料成本 | 完成判定的独立性 |
| 核心抽象 | 带驻留 LLM 的可复用原语 | 仓库状态马尔可夫链上的双模型联合采样 |
| 证据类型 | 受控对照实验 + 消融 | 观象性部署研究（作者明确声明无受控对照） |
| 机构背景 | UIUC 纯高校 | NVIDIA 企业主导 + 三所高校 |
| 可复用产物 | CodeFace 库 + LEGO-REPO 基准 | Humanize 插件 + postmortem 语料 + 分析方法论 |
三、问题定义
3.1 论文一：把"仓库构造"抽象为"带适应的复用搜索"
具体问题：给定一个仓库的公共接口描述，从零构造出能通过其原生测试套件的可执行实现。
核心洞察：仓库构造的失败主要不是"写不出好代码"，而是"跨组件约束的协调成本随规模爆炸"。如果大部分组件能以"高完成度 + 可适应"的形式从库里取出来，agent 的搜索空间就从"每一行代码"缩小到"少量任务特定胶水代码 + 各组件的适应参数"。
形式化：给定需求 r 与构造上下文 C，找到一组原语 {p_i} 及其适应后实现 {p_i’(r, C)}，加上任务特定代码，使交付仓库在原生测试套件上的归一化得分最大化。约束：每个原语只改自己拥有的组件；仓库级约束（跨组件需求 µ）在集成时传播解决；总构造预算有界（LEGO 主循环 b=5 轮）。
精妙之处：把"适应"这个动作从使用方移交给原语自身（驻留 LLM），使复用从"检索+理解+改写"的三步慢流程变成"激活+协商"的两步快流程；且随行测试 V 让每个原语自带质量闸门，失败可以定位到组件级。
3.2 论文二：把"编码会话"抽象为"仓库状态马尔可夫链"
具体问题：一个多阶段（计划-实现-审查-学习）的编码工作流，如何在各阶段边界上做出可靠的完成/继续/升级决策？
核心洞察：把编码会话视为仓库状态 s_t（仓库 + 计划 + 审查记录）的马尔可夫链。单智能体的每一步都从同一个分布采样 s_{t+1} ~ P_M(·|s_t)，且停在同一个模型自己接受的状态上——提案与验收共享盲区。这正对应深度学习里的"训练集上自评"困境：生成分布与评估分布同源，系统性错误不可见。
形式化：设 b 为 builder 引入缺陷且自身 overlook 的概率，m_R 为 reviewer 在 builder 已漏的前提下也漏掉的概率。缺陷在单模型循环中的存活概率为 b；在 builder-reviewer 交替中为 b·m_R。当两模型盲区不重叠（m_R → 0），链几乎不可能停在缺陷态。外部 oracle（证明检查器/测试 harness）再乘一个自己的漏检率 m_O。对照关系：
| 马尔可夫链概念 | 编码会话对应物 |
|---|---|
| 状态 s_t | 仓库 + 计划 + 审查记录 |
| 转移核 P_B(·|s_t, f_t) | builder 按上轮 findings 提案下一状态 |
| 转移核 P_R(·|s_{t+1}) | reviewer 在全新上下文出 findings 或接受 |
| 吸收态 | reviewer 宣告 COMPLETE 的状态 |
| 两块 Gibbs 采样 | 两个条件分布由两个不同厂商模型提供 |
精妙之处：这个抽象把"要不要独立审查"从经验争论变成乘法结构——只要 m_R < 1（reviewer 不是 builder 的复制品），交替严格优于单模型；同时也预言了代价：reviewer 的假阳性以额外轮次形式进入链（论文承认这是最大弱点）。
四、问题解法
4.1 论文一：Code Primitives + CodeFace + LEGO 三件套
组件一：Code Primitive（原语的定义）。一个 agent 原生的可复用可执行组件，五元组携带：
| 要素 | 内容 | 作用 |
|---|---|---|
| 接口契约 I | 自然语言 + 签名的接口说明 | 用自然语言接口做相关性评估 |
| 依赖闭包 D | 自带全部依赖 | 原语可独立执行、独立验证 |
| 随行验证测试 V | 平均 9 个验证测试 | 适应后立即自检，失败定位到组件 |
| 溯源 X | 来源仓库/许可证信息 | 合规与归因（80.7% 为 MIT/BSD/Apache 宽松许可） |
| 驻留 LLM M | 原语自带的适应模型 | 改写自身实现/接口/依赖以适配目标仓库 |
类比：传统库像"图书馆里的书"（内容固定，读者自己理解），Code Primitive 像"带随行工程师的预制建筑模块"——模块知道自己的图纸和验收标准，还能按你的户型改管线。
组件二：CodeFace 库。从真实 GitHub 仓库经六步"挖掘+验证"管线产出 1,424 个原语：871 挖掘 / 343 收获（来自验证过的构造运行）/ 210 网源。粒度由挖掘过程诱导而非人工设定：中位原语 214 行、跨 2 个文件、导出 4 个符号、带 9 个验证测试。库支持自然语言接口的可搜索检索。
组件三：LEGO 构造管线。四个阶段：
- 任务分解：把仓库需求拆成组件级需求；
- 检索激活：按需求从 CodeFace 激活所需原语；
- 适应性协作：原语间协商，跨组件需求 µ 在集成时传播，各原语的驻留 LLM 改写自己拥有的实现/接口/依赖，并与任务特定代码整合；
- 执行测试 + 诊断：跑原生测试，失败时诊断定位到具体组件，只重新激活失败组件（而非全量重造），最多 b=5 轮。
4.2 论文二：判断工程四原则 + RLCR + Stop-hook
判断工程四原则（落地为具体机制）：
| 原则 | 机制落地 |
|---|---|
| 计划先于实现，人批准计划 | plan contract（目标 + 正负验收标准） |
| 独立验收：builder 不判完成 | 异厂商 reviewer 唯一 COMPLETE 宣告权 |
| 分解决策 | 对齐审查（声明 vs 计划，区分阻塞项与可排队副作用）+ 代码审查（diff 缺陷）分离 |
| 以证据而非轮数度量进度 | 停滞循环须重审范围/升级/停止；结束须留经验教训 |
RLCR 核心循环（Ralph-Loop with Codex Review，Claude Code 插件）：
- 人批准 plan contract；
- builder（Claude Code）按轮实现，每轮提交"代码 + 轮契约 + 带证据的 claims"；
- Stop-hook 先跑 72 个机械闸门（检查 artifact 在场、格式合法、变更文件行数上限等——例如"无超 2,000 行的单文件变更"“无未关闭的主线任务"等完成纪律）；
- reviewer（Codex，异厂商、全新上下文、只见声明与代码不见 builder 推理）出 findings 或宣告 COMPLETE。
确定性路由：工作流路由与闸门强制由 2,221 行 Stop-hook 确定性代码承担（从初版 975 行增长而来），而非交给模型自觉。类比操作系统的"内核态/用户态"分界：判断边界的守卫必须是不可被 LLM 绕过的机械规则。
扩展应用：Kernel Design Agents（KDA）在循环上加内核知识库（KernelWiki）与 profiling 技能（ncu 报告）；Humanize Olympiad Agents（HOA）为每学科加完成检查并接 Codeforces judge/官方评分等外部 oracle。
五、评估指标与实验证据
5.1 论文一：LEGO-REPO 上的受控对照
基准：LEGO-REPO，522 个可执行重建任务（真实 GitHub Python 包按公共接口重建，跑原生测试套件），7 领域、22 能力轨、5 难度档 D1–D5；得分在空包地板（0）与原源码天花板（1）间归一化。这个设计保证"分数"就是"行为与原版测试的接近程度”，无主观裁判。
主指标：交付分（delivery score）。
| 配置 | 得分 | 说明 |
|---|---|---|
| GPT-5.6-terra 从零构造（最强骨干） | 0.3180 | 41.0% 任务 0 分，D1→D5 掉 10.3× |
| 13 骨干场均值 | 0.1926 | baseline 总体很弱 |
| LEGO + GPT-5.6-terra | 0.5134 | +61.4% |
| LEGO 对 13 骨干平均 | +0.1474（+76.5%） | 机制是管线的属性而非单模型 |
| DEAD@0（零分任务率） | 41.0% → 18.8% | 大量"完全失败"被救活 |
对照与消融（衡量"到底是什么在起作用"）：
| 对照 | 得分 | 与 LEGO 差距 |
|---|---|---|
| 同 harness Feedback 基线（–DV） | 0.3180 | +0.1954 |
| +诊断修订（–DV） | 0.3469 | 诊断贡献 +0.0289（14.8%） |
| +File RAG 编辑（FE_DV） | 0.3528 | 通用检索编辑仅 +0.0059（3.0%） |
| +构造原语（RE_DV） | 0.4093 | 原语构造 +0.0565（28.9%） |
| +原语适应（RADV，完整 LEGO） | 0.5134 | 原语适应 +0.1041（53.3%） |
| Context-only（只读契约与测试） | 0.3544 | 完整适应比它高 0.1590 |
| Import+Call（原样 vendor） | 0.3430 | D3–D5 反而低于无库参考 |
外部效度：外部系统对照（各自原生 harness 下 OpenHands 0.3263 / Claude Code 0.3170 / SWE-agent 0.2750 / Agentless 0.2181，LEGO 同款骨干胜 57.3%/56.2%）；外部基准迁移（RepoZero 53.8→62.9、RepoGenesis 41.0→48.2、RepoCraft 0.436→0.501）；语料不相交重挖库仍 +0.1348（排除"库里有目标仓库"的作弊嫌疑）；同库排除同仓库 donor 后仍 0.4743。成本：GPT-OSS-20B 承担适应+诊断保留 95.1% 分数且成本降 24.0%——便宜模型干适应，贵模型省下来。
5.2 论文二：观象性证据（证据等级：无受控对照）
必须先明确：作者在摘要与正文反复声明 “This evidence is observational, not a controlled comparison of workflows”。没有随机分组、没有同任务 A/B、没有显著性检验。它的证据是部署事实 + 语料分析。
部署事实（108 天）：68 个版本、1,468 stars / 130 forks、72 个机械闸门、Stop-hook 975→2,221 行。
postmortem 语料分析（150 个 issue 中 118 份真实循环的 postmortem，LLM 按书面 codebook 编码，盲审第二编码员 30 份，κ：轮数 0.82 / 出口 0.79 / 主压力 0.70+）：
| 观察量 | 数值 |
|---|---|
| 有轮数的 postmortem | 93 份，中位 10 轮，最长 87 轮（上限 42 的豁免跑飞） |
| 分阶段报告 | 27 份；364/541 轮（67.3%）发生在实现已被接受后的 code-review 阶段 |
| builder 过度声称 | 45/118 份 postmortem 描述 |
| 压力分类 top | review tail（80 份）、scope（79）、convergence（76）、evidence（58） |
应用成绩（作为观象性佐证而非对照实验）：
- gem5 构建系统迁移：567 文件 / 133 commits，PR 待审；
- MLSys 2026 FlashInfer Full-Agent 三赛道全部前三（DSA 索引均值加速 19.08×，两赛队自报；48h 消融：loop 3.71× → +KernelWiki 6.14× → +ncu 技能 8.58×，对照 K-Search 1.37×）；
- PutnamBench 672/672 榜首；Lean-Eval 第一（251/303）；IOI 2026 六题满分（Codeforces judge 判分）；IMO 2026 六题 Lean 证明（含 GPT-5.6 双角色与 Kimi+Codex 异厂商两种配置）；IPhO 30/30、IChO 418.5/437、IBO 2024 全对。
指标如何支撑主张：postmortem 中 45/118 过度声称 + reviewer 拦截事实支撑"独立验收必要"；67.3% 轮次耗在审查长尾支撑"stopping 是最大弱点"；PutnamBench 重跑 98 题中 86 题首轮通过（reviewer 边际未测）则诚实地标注了证据边界。
六、效果优势的根源解释
6.1 LEGO：增益来自"复用物作为交付物被适应"，不是检索也不是诊断
因果链（每步标注证据等级）：
- Baseline（从零构造）的根本局限：单轨迹内 agent 需要同时维持所有组件的接口约定一致性。上下文窗口内"全局一致性"随组件数增长而稀释——D1→D5 分数掉 10.3 倍、41.0% 零分，正是跨组件协调爆炸的直接观测。【论文实验已支持】
- 原语构造（+0.0565）改变了什么：把"从空文件写出 214 行正确组件"替换为"激活一个已通过 9 个验证测试的高完成度组件"。搜索空间的本质变化：每步生成的自由度从"任意代码"收缩为"对既有正确代码的增量修改"。【论文实验已支持】
- 原语适应（+0.1041，单项最大）改变了什么：驻留 LLM 在有界上下文内只面对"自己拥有的组件 + 目标契约"，改写后立即重跑随行测试。对比使用方 agent 改写（要同时理解原语与全局），信息流从"全局理解局部"变为"局部对齐契约"。Import+Call（vendor 原样调用）在 D3–D5 反而比无库参考低 0.013–0.075，反证"不适应的复用在大仓库上是有害的"。【论文实验已支持】
- 诊断为何只有 +0.0289：诊断是"错了再修"，而构造+适应是"一开始就放对"。当材料正确率高时，修复的边际收益自然小——这 3% 的收益结构恰是设计成功的旁证。【论文实验已支持】
- 规模为何放大收益（D1→D5 相对增益 +30.7%→+162.0%）：复用对冲的正是"跨组件协调"这一随规模爆炸的成本项，规模越大对冲越多。【论文实验已支持；“对冲"的机制表述含阅读者推测成分】
- 反事实验证：语料不相交重挖库仍 +0.1348（排除 donor 泄漏）；context-only 只有 0.3544（排除"只是多看范例"的解释）；模型替换九种配置方差仅 0.0309（排除"特定模型碰巧合适”）。【论文实验已支持】
6.2 Humanize：缺陷存活概率 b → b·m_R
因果链：
- Baseline（单模型循环/Ralph）的根本局限：提案分布与验收分布同源，系统性盲区在两处同时出现。这不是"没做审查"，而是"审查者与被审查者共享失败模式"——结构性不可修复。【论文理论论证 + postmortem 中 45/118 过度声称的观察支持】
- 异厂商 reviewer + 唯一完成权改变了什么：链的吸收态只能是 R 接受态。缺陷存活需连乘 b·m_R，盲区不重叠时接受更少缺陷态。45/118 过度声称被拦截是该机制的直接观测。【机制为论文理论论证；“拦截率"无受控量化，属观象性支持】
- 机械闸门改变了什么：把"artifact 在场、格式合法"这类可判定检查从模型判断降为确定性代码，reviewer 只判内容。相当于把"语法层验收"外包给零错误率的守卫。【论文设计自述 + 部署事实；闸门本身的边际贡献未单独消融】
- 外部 oracle 场景（m_O → 0）：Lean kernel/judge 完备的场合，单模型双角色也够用（IMO 双配置之一即 GPT-5.6 双角色跑通）——理论框架自我一致地划定了适用边界。【论文实验已支持】
- 弱点的机制解释：review 阶段无轮次上限 + findings 逐条到达的节奏 → 2/3 轮次耗在审查长尾，“迭代不保证收敛”（87 轮跑飞案例）。假阳性进入链的代价被理论预言、被数据证实。【论文实验已支持】
6.3 外部对照与综合判断
在本次检索范围内（提取清单内 7 篇同领域论文 + 两篇 PDF 的 Related Work），可作外部对照：
| 外部证据 | 与本文的关系 | 对根源解释的影响 |
|---|---|---|
| 《When Sub-Agents Work in Parallel》（2610.10263，南大等）：动态并发在 SWE-bench Verified 上使 Claude Code task pass 降 24.0 pp，共享状态与合并占失败 33.2% | 佐证 LEGO 的判断：多 agent 并行写码的核心成本在跨组件协调；LEGO 用"原语只改自己组件 + 集成时解 µ"正面处理同一问题 | 支持（不同方法、相近结论） |
| 同上文发现"实现规模越大并发收益越大”（LoopsBench +4.31 vs RepoZero -8.29） | 与 LEGO"D1→D5 增益 +30.7%→+162.0%“同构：仓库级方法的收益随规模放大 | 补充 |
| 《TestGRAD》（2610.10242）：差分损失挑选"能区分对错补丁"的测试，SWE-bench Verified +5.0 pp | 与 Humanize 的外部 oracle 思路互补：TestGRAD 造更好的 m_O，Humanize 造更独立的 m_R | 补充 |
| Anthropic evaluator-optimizer 模式（Humanize 自引） | Humanize 是其会话级推广，方向一致、粒度不同 | 支持（谱系内） |
| 自我奖励黑客/自偏好研究（Huang et al. 2024；Panickssery et al. 2024，Humanize 引） | 单模型自我认证系统性不可靠有多项独立研究支持 | 支持（结论相近） |
综合判断：
- 多项研究共同支持的机制：(1) 跨组件协调是仓库级构造的首先瓶颈（LEGO 消融 + 并发实证论文双重支持）；(2) 不适应的复用在规模上反而有害（LEGO 的 vendor 对照 D3–D5 为负）；(3) 同源验收不可靠（Humanize 理论 + 45/118 观察 + 独立的自偏好研究线）。
- 仍属推测或证据有限的机制：驻留 LLM 的"有界上下文局部对齐"解释——论文给出了消融数字，但"信息流为何更优"的细节属机制叙事；Humanize 的全部效果量（无对照，reviewer 边际、闸门边际均未单独量化）。
- 适用条件：LEGO 的收益条件是"任务与库中原语的组件能力有交集”（覆盖率为 0 时退化为从零构造），语料不相交时增益从 +0.1954 降到 +0.1348 也说明域匹配度影响收益；Humanize 的收益条件是"两厂商模型盲区确实不重叠"，若未来模型同质化（同一基座蒸馏系），m_R → 1，优势消失。
- 可能的失效条件：LEGO 在全新领域（库无覆盖）或任务本身是"单文件算法题"（无跨组件协调可对冲）时无优势；Humanize 在有完备外部 oracle 的场景（m_O→0） reviewer 独立性变得不必要，而在无客观验收标准的开放任务上，reviewer 假阳性会造成无法收敛的长尾。
七、必要知识反推
假设让一个没有相关知识的人重做这两项工作，最少必须掌握：
7.1 领域知识层
- 软件复用与构件化：库、依赖管理、vendoring、接口契约、许可合规——不知道这些就设计不出"五元组原语"，也不会想到把依赖闭包作为一等公民。
- 仓库级软件工程：模块耦合、构建系统（gem5 的 567 文件迁移需要懂构建系统迁移本身）、测试金字塔——LEGO-REPO 的归一化评分与 Humanize 的 evidence bar 都以此为前提。
- LLM 智能体工作流：SWE-bench 范式、agentic loop、上下文窗口约束、Claude Code/Codex 的插件与 hook 机制——Humanize 的 Stop-hook 是对宿主 hook 系统的深度利用。
7.2 方法论知识层
- 受控实验设计：同 harness 对照、消融分解（LEGO 的 Table 5 逐机制叠加）、语料不相交重挖——防作弊的实验卫生直接决定结论可信度。
- 马尔可夫链与 Gibbs 采样：把交替模型理解为两条件分布的联合采样、吸收态分析——Humanize 的全部理论论证建立于此。
- 测量学/编码可靠性：Cohen’s κ、盲审第二编码员、书面 codebook——postmortem 语料分析的方法学根基。
- 基准设计：地板/天花板归一化、难度分档（D1–D5 的多维系数）、防 VLM 裁判主观性——LEGO-REPO 的构造方法。
7.3 工程知识层
- 大规模挖掘管线：从 GitHub 六步挖掘+验证 1,424 原语，模块级可达性审计（22,985 目标模块中 14,106 有候选）。
- 确定性 hook 工程：2,221 行 Stop-hook 强制 72 闸门、路由决策代码化——“把判断写进不可绕过的代码"的工程能力。
- 成本工程：GPT-OSS-20B 替换适应/诊断保留 95.1% 分数降 24.0% 成本——模型分工的性能/成本权衡实操。
7.4 知识融合的关键节点
- 节点一（LEGO）：“软件复用的构件化思想” × “LLM agent 的上下文有界性” → 让复用物自带驻留 LLM 自适应。单独懂复用会停在静态库，单独懂 agent 会停在 RAG 检索，融合才得出"原语即交付物”。
- 节点二（Humanize）：“马尔可夫链的吸收态分析” × “多智能体工作流工程” → 把"完成判定权"变成链结构参数（谁能宣告吸收态），而非 prompt 里的恳求。
- 节点三（两者共通）：把经典软件工程/统计力学概念转译为 agent 时代的可执行机制——这是两篇论文共同的思维模式。
八、论文中可以提取的通用性灵感
灵感一：复用物应该是"活的"，自带适应能力
核心思想：可复用资产不应是静态物料，而应是携带自身描述、质量验证与适应机制的自治单元。
论文证据：LEGO 消融显示原样 vendor（Import+Call）在 D3–D5 反而低于无库参考，而完整适应比 context-only 高 0.1590——复用的价值几乎全部来自"能改"而非"有"。
推广场景：(1) 设计系统：组件库自带设计 token 协商能力，按品牌自动适配；(2) 数据工程：ETL 模板自带 schema 漂移自适应；(3) 法务：合同模板库自带条款与辖区的自动改写；(4) 教育：课件原语按学情自适应重组。
灵感二：把"验收权"从"生产者"手里拿走，是质量的最小充分干预
核心思想：无论人或 agent，产出者与验收者的独立性哪怕只前进一小步（乘一个 <1 的漏检系数），质量收益就是乘法级的。
论文证据：b → b·m_R 的乘法结构；45/118 postmortem 中的 builder 过度声称被异厂商 reviewer 拦截；反面是 reviewer 假阳性带来 2/3 轮次的审查长尾。
推广场景：(1) 内容生产：AI 写手与异厂商 AI 事实核查员分离；(2) 科研：方法学审查者不参与利益相关结论；(3) 安全审计：红队与开发方独立；(4) 任何"生成-验收"管线：把验收方换源（不同模型/不同人/确定性规则）比调 prompt 更有效。
灵感三：机械闸门优先于模型自觉
核心思想：凡是能用确定性规则判定的检查（在场性、格式、边界），都应写成不可绕过的代码，让模型只判断真正需要语义判断的部分。
论文证据：72 个机械闸门 + 2,221 行 Stop-hook 承担路由与强制，reviewer 只判内容；模型替换实验（九种配置方差 0.0127）同样表明"机制比模型重要"。
推广场景：(1) 数据入库：schema 与约束校验先于语义审核；(2) CI/CD：一切可静态判定的门禁代码化；(3) 金融风控：硬性限额规则与模型评分分层；(4) agent 产品：工具调用前的权限闸门。
灵感四：诊断的廉价，恰是设计正确的信号
核心思想：如果系统里"事后修复"环节的贡献极小，说明上游材料与流程已经把错误率压到低位——修复环节的边缘化是架构成功的证据。
论文证据：LEGO 的诊断仅贡献 +0.0289（14.8%），而构造+适应合计 82.2%。
推广场景：(1) 制造业：返工线占比是产线健康度的反指标；(2) 教育：答疑量低可能是教材自适应好的信号（需区分"没问题"与"不提问"）；(3) 软件团队：code review 中"发现设计错误"与"发现笔误"的比例反映前期设计质量。
灵感五：观象性证据也有价值，但要如实标注等级
核心思想：无法做受控实验时，部署事实 + 系统性语料分析 + 理论机制模型可以构成有价值的证据链，前提是诚实声明"这不是对照实验"。
论文证据：Humanize 通篇标注 observational，κ 一致性、87 轮跑飞、reviewer 边际未测等不利事实照报。
推广场景：(1) 生产系统 A/B 不可行时的变更评估；(2) 政策评估的准实验设计；(3) 医疗器械上市后监测；(4) 学术写作规范本身——反面教材远多于正面。
灵感六：企业主导与高校研究在同类问题上产出互补形态
核心思想：机构背景塑造研究形态——高校产出"新范式+严格基准"，企业产出"部署系统+实践证据"，两类证据互为补充而非替代。
论文证据：同为 agentic coding 构造问题，UIUC 纯高校的 LEGO 是受控实验范式，NVIDIA 主导的 Humanize 是部署观象范式，两篇的证据类型几乎不重叠。
推广场景：(1) 技术调研：读论文先看机构类型预判证据形态；(2) 产学研合作设计：让双方各做擅长的证据类型；(3) 个人研究选题：根据自身资源禀赋选择证据形态。
附录：两篇论文速览卡
| LEGO（2610.09079） | Humanize（2610.08900） | |
|---|---|---|
| 一句话 | 让可复用组件自带 LLM 自适应，仓库构造 13 骨干平均 +76.5% | 完成宣告权移交异厂商 reviewer + 72 机械闸门 |
| 核心数字 | 1,424 原语；增益 82.2% 来自构造+适应；诊断仅 +0.0289 | b·m_R 缺陷存活；45/118 过度声称；67.3% 轮次在审查长尾 |
| 证据等级 | 受控对照 + 消融 + 外部迁移 | 观象性（作者明示无对照） |
| 最大弱点 | 库覆盖率依赖（不相交库增益降为 +0.1348） | stopping 不收敛（87 轮跑飞；review 无上限） |
| 开源 | 未给出公开 URL | github.com/PolyArch/humanize（继任 humanfia/humanize） |