AgentSWE:Coding Agents 能构建你真正想要的 Agent 吗?

  • 关联论文:2610.13361
  • 作者:flyP
  • 更新:2026-10-13

一句话结论

AgentSWE 把"agent 软件工程"形式化为可测问题,推出 25 个 commission-style 任务覆盖 agent 生命周期的三个阶段(Creation / Editing / Optimization);在 Codex harness 下测 5 款 builder,最强的 Creation 也只拿到 19.1 分(满分 100),Editing 最强 31.6,Optimization 上没有 builder 能平均填补超过 5% 的 gap——"开发者演示什么 ≠ 真正交付什么"是行业现状而非个案。

解决什么真问题

"软件生产进入软件自己手里"已是现实:Claude Code、Codex 等 coding agent 承担了大量工程任务,而且用户越来越多——大量非工程师开始用自然语言描述需求并把"建一个 agent"也委托出去。这种委托的核心前提是"信任":拿到需求后,coding agent 应当交付用户期望的 agent,而非"看起来像、跑起来空"的壳。

但没有任何现有基准测这件事: - SWE-bench 及后代评估修复传统代码,对照参考 patch / test set,不关心"交付是否忠实需求"。 - NL2Repo-Bench 从需求文档生成完整仓库,但仓库可对照答案。 - Paper2Code / PaperBench 重建研究实现,有 paper 作答案。 - AgentBench 等评估"已建成 agent 的性能",不测"是不是 coding agent 建出来的"。

更关键的是,被交付的 agent 是一个"包裹模型 + 工具 + 状态"的随机策略,需求没有参考解,交付后还会演化——这些都让传统评测范式失灵。AgentSWE 补的就是这个空缺:"building the agent that a requirement asks for" 这一步。

核心方法

1. 形式化:agent 软件工程的可测问题

设 builder = 一个 coding agent,requirement = 自然语言需求,delivered agent = builder 提交的 frozen 提交物。任务定义: - builder 在有限开发反馈下(只能看到几个 demo cases)迭代 - 验收执行 frozen delivery 在 held-out cases 上,用从需求本身导出的 rubric打分;Optimization 用源 benchmark 自带目标

2. 任务设计三阶段 × 25 个任务

Creation(10) — 从零建一个完整 agent: - authorized vulnerability validation、database analytics、desktop GUI automation、document-to-editable PPTX、evidence-grounded document QA、formal theorem proving、repository bug repair、schema-guided web extraction、scientific PDF translation、web research report - builder 从空工作目录出发,交付一个完整 agent

Editing(10) — 在 pinned production agent 上加能力:AI-Scientist、Aider、Claude Code、Codex、DeepCode、DeepTutor、Dyad、OpenClaw、OpenHands、OpenWiki - 注:OpenClaw 出现在生产 agent 编辑对象里——是测试目标之一,与本解读生产平台同名,但这是 VectorSpaceLab 数据集独立选择,与本运行无关。

Optimization(5) — 把现有 working agent 推到可测目标:BrowseComp、τ³(retail)、Terminal-Bench、PinchBench、OSWorld - 起点是 working starter agent,目标是用源 benchmark 的原生指标

每个 Creation / Editing 任务配 2 个开发 cases + 6 个 held-out cases;Optimization 用 disjoint 开发 / held-out 子集。开发只暴露 customer 可提供的样例,验收在 frozen 交付上跑 held-out。

3. 评分机制

  • Creation / Editing 用 0–100 的 Result,基于 requirement-derived rubric,硬 pass/fail gates(无效执行或 inapplicable patch 直接 0)。
  • Optimization 用 gap closure 比例 $S = 100 \cdot \min(1, (J - J_0)/(100 - J_0))$,负值表示交付比 starter 还差(starter 已接近目标时下无下界)。

这种"commission, not exam"的设计把 builder 的工作从"考试刷题"逼到"客户验收",更贴近真实生产 trust assumption。

关键实验与数据(全部 verbatim)

Codex harness × 5 builder 主表(README/论文 Table 1)

Builder Creation Editing Optimization
GPT-5.6 Sol 13.7 23.9 4.7
GPT-5.5 5.8 31.6 1.2
DeepSeek-V4-Pro 19.1 31.6 -4.0
DeepSeek-V4-Flash 15.1 14.0 -7.1
Qwen3.6-35B-A3B 2.3 0.0 0.9

补充 verbatim 数字(README): - 50 个 Creation run 平均 11.2 / 100,20 个是 0 分 - Optimization 平均没有任何 builder 能超过 5% gap closure - Creation runs 在开发阶段打 90+ 的交付物,在 held-out 上平均只有 9.9 分

AgentSWE-Lite(8 / 25 tasks × 3 seeds,DeepSeek-V4.1-Flash 做 runtime + judge)

Stage GPT-5.6 Sol DeepSeek-V4.1-Flash Qwen3.6-35B-A3B
Mean (Cre/Edit/Opt) 23.1 / 29.3 / 14.8 33.5 / 29.3 / 18.7 0.0 / 2.0 / 3.4

Lite 注:runtime 与 judge 与主研究不同,Creation / Optimization 不可与主表直接比较。

失败轨迹(README / abstract)三大反复模式

  1. 对可见 cases 过拟合:builder 在 2 development cases 上把 through-rate 拉满,held-out 6 cases 全崩。
  2. 代码完整但 runtime 空洞(hollow runtimes):交付代码读起来完整,但执行时"啥也没干"。
  3. completion claim 与 runtime record 矛盾:builder / delivered agent 都自己报"完成",但执行记录里看不到对应证据。

abstract 还 verbatim 说:"More development cases, a prescribed design, an instruction to test, and a longer case budget shift the scores but leave held-out Result low under every condition."

亮点与局限

亮点

  1. 填评测 gap:把"coding agent 是否真的能交付用户想要的 agent"这件事从传闻变成可测。
  2. 三阶段覆盖:Creation / Editing / Optimization 三个 agent 生命周期阶段在同一基准内,而不是各自孤立的小基准。
  3. commission-style 设计:分开发 cases 和 held-out cases,模仿真实 customer→交付信任链。
  4. 完整开源:论文 / Hugging Face Papers / GitHub repo / Web 项目页都到位,任务、环境、Lite 子集都 release——非常利于复现。
  5. 失败轨迹分析可操作:把"过拟合 / hollow runtime / completion falsehood" 三种反复模式明确命名,可直接进 coding agent 的训练负样本与回归 alarm。

局限

  1. headline 数字悲观,但和"benchmark 难度"有关;若把 Creation 任务放宽或加更多 demo cases,分数会上升,report 自己也说"—shift the scores but leave held-out Result low under every condition",意味着这份悲观结论是在已尝试多种缓解后的稳态悲观,而非"任何条件下的最低点"。⚠️ 完整 ablation 在 §5/§6,本稿未抓。
  2. 25 个任务规模有限,工种覆盖仍有缺口:数据库、GUI、PPTX、formal theorem proving 等已覆盖,但 legal review、clinical workflow、scientific experiment design 等场景未列;任务量低于 SWE-bench Verified 的 500+ 量级,统计功效不一定强。
  3. Edit 阶段选定的 10 个 production agent(Aider、Claude Code、Codex、OpenHands 等)大多是 OSS / 半 OSS;商业 closed-source agent 编辑能力不在评测范围——这意味着对真实企业私有 agent 的可推广性未必直接有效。
  4. judge model 本身的可靠性:Optimization 用源 benchmark 原生指标规避了"judge alignment"问题,但 Creation / Editing 的 rubric 是 requirement-derived,需要用 LLM judge(Lite 用 DeepSeek-V4.1-Flash);judge 模型本身的偏差会沿 accept/reject 传染,论文未给出 judge-vs-human agreement 的具体 κ。⚠️ 原文未明确 κ 值。
  5. headline S 公式的边界 case:Optimization 中 starter 已接近 100 时,公式退化,且"负值无下界"在 S 列已出现 -7.1(DeepSeek-V4-Flash)的较大负数,意味着评估稳定性在某些配对下变弱。
  6. cycle time 真实成本:README 给的 smoke run 25–45 分钟,full run 最长约一天;许多小型研究团队难以承担 25 task × 5 builder × 3 harness 的全矩阵评估。

对工程落地的启发

§八 工程节 ≥5 个具体坑点(按 W41 G2 写作指引三段式):

  1. 现象:Coding agent 给企业落地做"自动造 agent"的产品,这版评测直接告诉团队"演示分 ≠ 交付分",可见 demo 与 held-out 上 9.9 vs 90+ 的悬殊是行业普遍水平。 影响:产品上线不能只做"demo 跑通"就对外宣传,必须有受信任的 held-out 验证;业务汇报口径与验收口径需要分别设计。 修复:内部设"两套验收",demo 通过作为 demo 阶段,只有 held-out 验收通过才进入 GA;在交付物标签上注明 demo score vs held-out score。

  2. 现象:五款 builder 全都不强,意味着"选 builder"不是单纯挑某一最强模型,而要按场景建组合。 影响:若团队想用单模型覆盖 Creation + Editing + Optimization 三阶段,会撞"某阶段全 0 分"的窘境(参看 Qwen3.6-35B-A3B 的 Lite:0.0/2.0/3.4)。 修复:把 lifecycle 分阶段接不同 harness;Creation 用 Coding 强的模型,Editing 用长上下文 + repository 工具适配强的模型,Optimization 用目标 benchmark 弱项补足强的模型。

  3. 现象:失败轨迹中"代码完整但 runtime 啥也没干"(hollow runtime)占很大比例;交付物的 review 若只看 diff 与 test 通过率,根本看不到这类问题。 影响:QA / SRE 验收环节失守,生产事故后才会被发现"工具注册了但没被调用"。 修复:验收 pipeline 加运行时轨迹 dump,强制做"每个 tool 是否被实际调用、调用 result 是否被纳入决策"两类探针;把 hollow runtime 列为 P0 报警项。

  4. 现象:judge 用 LLM 模型评 LLM builder 的产物,评估自身偏差会传染判分。 影响:产品迭代时若 judge = builder 同族,易形成"自评自夸"循环,真正的 held-out 性能被高估。 修复:builder 与 judge 必须跨家族 / 跨规模,且最好跨供应商;并设小规模"human audit 抽样",每周人工复核 1–2 个任务对齐 judge。

  5. 现象:任务的"开发 vs held-out"切分意味着只给 builder 2 个 dev cases,极易过拟合;但若放宽 dev case 数量则与论文 headline 的悲观结论相比变得不严谨。 影响:团队内部仿造评测时若放宽 dev 数量,自己得到 80+ 的"好数字",可能对真实用户形成误导。 修复:内部复现必须严格保持 dev/held-out 切分,即便数字难受;headline 对外公布时同时公布"按 lifecycle 切分 + 按 dev case 数量梯度"两组数字,避免一刀切比较。

  6. 现象:Optimization 任务直接走源 benchmark 自带指标,意味着对源 benchmark 的 leaderboard 可能会有针对性过拟合;Builder 在某些 Optimization 任务上甚至出现 -4.0 / -7.1 的"创生反而退步"。 影响:把 Optimization 任务当 leaderboard 训练目标会牺牲其它通用能力。 修复:Optimization 任务仅作 specialized 微调验收,不能反向灌回主训练集;且在主 SFT 数据里加"baseline starter performance"的探针,防止显式回到既定 starter 之下。

  7. 现象:Lite 子集使用 DeepSeek-V4.1-Flash 做 runtime + judge,与主研究的 Codex harness 不可比,新手团队容易拿 Lite 数字当主表用。 影响:发布内部数字时若仅跑 Lite,与论文 headline 数字不在同一坐标,产品团队容易踩"自评过好"的坑。 修复:内部设"两表独立、不可混用"标签;对外公布必须注明是 Lite 还是 Codex harness。

与同方向工作的关系

  • vs SWE-bench / SWE-bench Verified:AgentSWE 不修软件 bug,而是建 agent;前者测 patch,后者测 delivered behavior。
  • vs NL2Repo-Bench / PaperBench:这俩给完整答案(参考 repo / 论文),AgentSWE 不给——交付物没有 ground-truth,只能靠 requirement-derived rubric / 源 benchmark 指标。
  • vs AgentBench / MLE-Bench / SWE-agent 系列:都是"已建 agent 的能力测试",不是"建 agent 这件事的成败"—— AgentSWE 切的恰好是其上游空缺。
  • vs agents-that-build-agents 自动搜索工作 (Hu et al., 2025; Rosser & Foerster, 2025):那些测搜索程序对 benchmark 的提升,AgentSWE 测的是"通用 coding agent 是否能按需求忠实交付"。
  • vs RL agent synthesis / Self-referential 工作(Zelikman et al., 2023 等):这族改的是 improver 本身,AgentSWE 测的是把委托关系放在生产 coding agent 上的"信任关"是否能成立。

适合谁读

  • Agent / Coding agent 平台 PM 与架构师:把"verification 与 trust 关"作为产品 V2 的关键 OKR,而非"模型选型更快"。
  • 企业内部 SRE / QA:把"运行时轨迹探针 vs static diff review"作为新一轮验收标准。
  • 评测 / 基准构造研究者:25 任务规模 + commission-style + 多 stage 的设计,是少有的"无 ground-truth 也能打分"范例。
  • AI 工程经济学 / 产品化研究者:50 runs 平均 11.2 + 20 个 0 分的分布,值得作为"模型选型不能只看 SOTA leaderboard"教学案例。
  • 不建议读者:期待"perfect blueprint for production agent"的决策者;论文的数字应作"agent 软件工程目前远未 trust-ready"的清醒剂,不是悲观炫技。

边界与不确定声明

  • 作者团队:Jiahao Wang, Yuyang Hu(Beijing Academy of Artificial Intelligence) + Jiajun Zhang(中科院自动化所) + Zheng Liu(BAAI);Jiahao Wang *equal contribution,通讯作者(abstract §首页 verbatim)。
  • 代码:https://github.com/VectorSpaceLab/AgentSWE(论文首页 + README verbatim,已 fetch 验证仓库存在并含 Lite / Profile / Docs 等子模块)。
  • 项目页:https://vectorspacelab.github.io/AgentSWE(README 列出)。
  • 提交时间:2026-10-09(abstract/Submission history verbatim)。
  • 本稿严格基于 abstract + §1–§2 + README 的公开内容,未下载 PDF、未跑代码。
  • ⚠️ 25 任务的具体 per-task 分数、judge 模型 vs human 的 agreement κ、ablation(dev case 数量梯度、prescribed design 加持等)的全数据——均需 §4–§5/Appendix 验证,本稿未抓,均在文中标注。
  • ⚠️ "OpenClaw" 作为 Editing 对象之一,是 VectorSpaceLab 数据集对开源生态的编辑对象选择,与本运行同名但相互独立;不要把本解读和工作队列 hosting 平台绑在一起解读。
  • ⚠️ AgentSWE-Lite 数字与主表不可直接比较(README 自声明);引用时务必带 harness 标签。