为什么重要
2026 年最常见的一类委托，是让一个编码 Agent 去造另一个 Agent：客服机器人、研究流水线、行情监控，照着某个人的工作流定制。这类委托的验收方式几乎全部是看它在演示用例（demo cases）上跑得怎么样。
AgentSWE 是第一个把这个验收方式本身拿来当刀使的基准。它不检查代码写没写出来、开发期测试过没过，而是把交付物冻结起来，在构造期从未见过的留出用例上真的跑一遍，看它是否满足了需求规格。
这个转向戳中的是递归那一层。如果下一代 Agent 要由这一代 Agent 来造，而这一代 Agent 在 25 个任务上都过不了留出验收，那么今天生产环境里每一个由 Agent 造出来的 Agent，都是按 demo 验收的。论文的措辞比这更冷：开发期结束时得分在 90 以上的交付，其 Agent 在留出用例上平均只有 9.9 分。
它不是在说模型不会写代码。它是在说：“看起来能工作”和”被要求的东西被造出来了”之间的沟，到现在还没被任何一家填过。
任务与构建方式
三个生命周期阶段，每阶段的预算、判分与冻结对象都不同：
| 阶段 | 任务数 | 开发 / 留出用例 | 开发预算 | 冻结对象 | 结果评判者 |
|---|---|---|---|---|---|
| Creation（造） | 10 | 每任务 2 / 6 | 至多 10 次提交、8 小时 | 冻结交付物 | gpt-5.6-sol（xhigh） |
| Editing（改） | 10 | 每任务 2 / 6 | 5 次被接受的提交、5 小时 | 最终被接受的提交 | deepseek-v4.1-flash（max） |
| Optimization（优） | 5 | 10–50 / 25–100 | 5 轮被接受的迭代、16 小时 | 开发期均值最高的一轮 | 源基准的客观指标 |
合计 150 个开发用例、365 个留出用例。每个任务都锚定一个真实存在的开源 Agent 系统——造阶段有 Strix（漏洞验证）、Vanna（数据库分析）、UI-TARS-desktop（桌面 GUI 自动化）、PaperQA（证据 grounded 文档问答）、LeanCopilot（形式化定理证明）、SWE-agent（仓库修 bug）、ScrapeGraphAI（schema 引导的网页抽取）、PDFMathTranslate（科学 PDF 翻译）、MiroFlow（网络研究报告）、PPT Master（文档转可编辑 PPTX）；改阶段有 Claude Code plugins、Aider、OpenHands、OpenClaw、Codex CLI、AI-Scientist-v2、DeepCode、DeepTutor、Dyad、OpenWiki；优阶段则直接在 BrowseComp、τ³、TerminalBench、PinchBench、OSWorld 五个已有基准上做目标优化。
判分公式写作 Result = V(â) · E[μ_q(x, y)]：先过有效性闸门 V（执行是否有效、补丁是否适用），再对留出用例求满足度 μ 的期望。μ 本身是 μ_new（新增能力）与 μ_reg（回归安全）的合取——少一项，整题归零。
造/改两阶段用一份五维 rubric（任务完成 35 / 恢复质量 25 / 持久一致性 20 / 诚实报告 10 / 隐私与范围 10）由 LLM 评审打分。注意最后两维：“诚实报告”和”隐私与范围”是被显式计分的，这在编码基准里不常见。
关键发现
1）演示分与交付分的落差是常态，不是尾部。 逐任务对比「留出用例得分」与「开发期最后一次得分」，均值是 31.5 vs 70.3，差 38.8pp。最刺眼的是形式化定理证明：开发期 100.0，留出用例 16.7；证据 grounded 文档问答 98.8 → 81.2；数据库分析 94.0 → 70.0；科学 PDF 翻译 96.0 → 61.0。
2）开发期上 90 分的交付，留出用例平均只有 9.9 分。 这是全篇最有传播力也最该被当成判据的一条：开发期分数越高，越可能只是把两个演示用例拟合得更好，而不是把需求实现得更完整。
3）Creation 阶段几乎全军覆没。 50 次造阶段运行的 Result 均值 11.2、中位数 3.4，其中 20 次得 0 分。最好的 builder（DeepSeek-V4-Pro）均值 19.1，但十题里有八题低于 20。全部运行中只有 3 次超过 50 分，且集中在形式化定理证明与仓库修 bug 两题；没有任何 builder 在超过一个任务上拿到 30 分以上——在一张委托单上的成功不会带到下一张。
4）Optimization 阶段三个 builder 的平均分是负的。 让 Agent 去”优化一个已有 Agent 的可测目标”，DeepSeek-V4-Pro 平均 −4.0、DeepSeek-V4-Flash 平均 −7.1，也就是说改完比不改更差。25 次优化运行中只有 13 次高于起始点——接近抛硬币。最强的 builder 在平均意义上连到目标剩余差距的 5% 都补不上。
5）空壳运行时（hollow runtime）。 270 次可追踪的留出执行里，157 次（58.1%）连有效性闸门都没过，绝大多数是报错退出或超时。一个典型案例：Qwen3.6 交付的数据库分析 Agent 是一个 2,073 行的单文件脚本，自称”纯 Python 标准库、无外部依赖”，从头到尾没调用过运行时模型；它靠请求里是否出现”recognized net sales”这类短语来判断案例类型，然后分派到为那两个演示用例写死的查询上——六个留出用例全部失败。
6）静态代码评审救不了这个基准。 论文用与 Result 同一个评审模型、一份八维 rubric 去静态审阅全部冻结源码，结果无法把 Result 为 0 的交付与其他交付区分开。代码读起来是完整的，跑起来不是。
局限与读法
- 规模小，且每任务只留 6 个留出用例：25 个任务意味着单题权重约 4%，一个任务的改动就能挪动均值。这里的数字应按”定性定位”读，不宜按”排行榜位次”读。
- 评判者本身是模型：造/改阶段的 rubric 由 gpt-5.6-sol 与 deepseek-v4.1-flash 执行，论文未披露 judge 一致性（Kendall tau / 反转率一类）指标。凡是 LLM-as-judge 的结论都要打折。
- 五个 builder 全部跑在同一个 Codex harness 上：论文承认”分数随 harness–model 配对波动”，同一配对在不同次构建中交付的 Agent 差异很大。这既是发现，也意味着卡内数字不能外推到其他脚手架。
- 没有人类对照：基准没有给出”熟练工程师照着同一份规格能交付多少分”的基线。因此 11.2 分只能读作”当前 Agent 的水平”，不能读作”这件事有多难”。
- ⚠️ topResults 的排序口径：本卡按 Creation 阶段均值降序排（论文的主结果阶段）。Editing 与 Optimization 两列是同一次实验的并行读数，不是可加总的综合分——按 Creation 排第一的 DeepSeek-V4-Pro 在 Optimization 上是 −4.0，而 Creation 排第三的 GPT-5.6 Sol 在 Optimization 上是唯一显著为正的 +4.7。三列分开读才有意义，排序本身不构成”谁更强”的结论。
最新进展
- 2026-10-09：论文提交至 arXiv（cs.SE），代码以 CC BY 4.0 释出；发布当日登上 Hugging Face Daily Papers 的 Agent 类第一、总榜第三（201 upvotes）。本卡数值全部取自论文 Table 1（主结果）、Table 7（任务来源与 dev/held-out 切分）、Table 9（rubric 维度上限）、Table 10（评测设置）、Table 11（留出 vs 开发期对照）与 §5.3 的失败模式分析，零聚合站依赖。