# 收尾税：自主智能体交付率塌方实测 ## 概述 2026 年中，自主智能体在公开榜单上已经"打满"：SWE-bench Verified 头部方案解出率逼近 85%–95%，OpenAI 甚至宣布不再用该基准评测前沿模型，理由是它"已无法反映有意义的能力提升"。但 METR 在 2026 年 3 月发布的一份实证研究撕开了这层乐观——他们请 4 位活跃维护者评审了 296 个 AI 生成的 PR，发现维护者真实合并率比自动评分器给出的分数平均低 **24 个百分点**，而且提升速度每年还慢 **9.6 个百分点**。换句话说，智能体"能跑通测试"和"能被合并进主干"之间，横亘着一条巨大的收尾鸿沟。本文以"交付率"而非"解出率"为标尺，拆解自主智能体在长程任务最后一公里的塌方机理、补位工具栈与变现逻辑，给出分场景的收尾工程方案。 ## 自主智能体交付力对比 | 自主智能体栈 | 定位 | SWE-bench Verified 解出率(2026) | 维护者合并率(估*) | 时间地平线 | 收尾机制 | 上手难度 | 变现潜力 | |---|---|---|---|---|---|---|---| | **OpenHands** | 开源全栈 SWE Agent | ~55%–72% | ~30%–45% | 中 | 内置审查/可挂 CI | 中低 | 高 | | **SWE-agent** (Princeton) | 研究型 ACI 交互 | ~50% | ~25%–30% | 中 | 轻量自纠 | 中 | 中 | | **Claude Code** | 人机协同终端 Agent | 头部(>85%) | 待评审 | 高 | 自审+工具调用 | 低 | 高 | | **Cursor / Cline** | IDE 内人机回路 | 非全自主 | 高(人在环补位) | 高 | 实时人审 | 低 | 高 | | **Manus** | 通用自主(网页/数据) | N/A(非代码) | — | 中 | 多步自检+产物归档 | 低 | 中 | | **Devin** (Cognition) | 商业端到端 SWE | 头部宣传值 | — | 中 | 端到端+协作 | 低 | 中高 | > *合并率为按 METR 的 ~24pp 收尾税对解出率折算的估计值，仅用于横向感知差距，非官方数据。 ## 深度分析 ### 一、基准饱和的错觉：SWE-bench Verified 从信号变噪声 2026 年 5 月的公开榜单显示，头部模型在 SWE-bench Verified 上已站上 85%–95% 区间（如 marc0.dev 5 月榜记录 GPT-5.5 达 88.7%，llm-stats 列出的部分方案逼近 0.95）。OpenAI 随即宣布不再用 SWE-bench Verified 评测前沿模型，理由直白：分数的边际提升已无法对应真实工程能力的边际提升。问题不在于模型退化了，而在于这个基准本身已经"测到顶"——它是 500 个人工筛选过、平均人类工程师约 20 分钟可解、且有确定测试用例的任务子集。 当一个基准被刷到接近天花板，它就从"能力信号"退化成"噪声地板"。更危险的是，饱和会制造一种集体错觉：榜单 90% ≈ 交付 90%。但 90% 的"测试通过"完全不等同于 90% 的"可合并、可上线、可维护"。这正是收尾税的第一个来源——**基准把最难的最后一公里剔除了**，而那一公里恰恰是真实交付的全部重量。 ### 二、24 个百分点的收尾税：METR 维护者评审实证 METR 2026 年 3 月的研究是目前对"收尾塌方"最硬的量化证据。方法很朴素也很扎实：招募 scikit-learn（2 位）、Sphinx、pytest 共 4 位活跃维护者，对 5 个模型（Claude 3.5/3.7/4 Opus/4.5 Sonnet、GPT-5）生成的、且已通过自动评分器的 296 个 PR 做盲评——维护者并不知道哪个是人写的、哪个是 AI 写的。同时用 47 个真实合并的"金标补丁"校准评审噪声，金标基线为 68%。 核心结论：**维护者真实合并率平均比自动评分器低约 24 个百分点，且提升速度每年慢 9.6 个百分点**。也就是说，模型在榜单上越跑越快，但在"能否被合并"这条更接近真实的赛道上，进步明显滞后。被要求修改的三类主因是：核心功能失败、破坏其他代码、代码质量问题。这是一个比"幻觉""工具调用"更隐蔽的失败模式——**代码能跑、测试能过，但过不了同行评审**。它说明自主智能体的瓶颈已经从"会不会做"转移到了"做得规不规范、值不值得收"。 ### 三、时间地平线：20 分钟任务与整天自主的鸿沟 METR 的另一条研究线——时间地平线（time horizon）——从尺度上解释了收尾为什么难。他们发现 2019 到 2025 年间，前沿智能体"50% 任务时间地平线"（即能以 50% 成功率独立完成的任务长度）大约**每 7 个月翻一倍**。这个翻倍节奏很惊人，但绝对值仍然克制：SWE-bench Verified 对应的是人类约 20 分钟的任务，而"独立跑满一个工作日、跨多文件、跨多轮重构"的整段自主，仍远在当前地平线之外。 这构成了收尾税的物理根源：**交付需要的是长程连贯性，而基准奖励的是短程单点命中**。一个 20 分钟级别的任务里，"不破坏既有代码""遵循仓库规范""保持向后兼容"这些要求要么被测试覆盖、要么被省略；可一旦任务尺度拉长到小时乃至天级，这些被省略的约束会像复利一样累积成收尾时的债务。智能体在前 95% 的步骤上表现越好，最后 5% 的"收口"反而越显突兀——因为前面越顺，对结尾的期望越高，落差越大。 ### 四、τ-bench 与多轮可靠性：交付不是写对一次 SWE-bench 测的是"一次性写出能过测试的补丁"，真实交付测的是"在多轮交互、多次返工、环境漂移中持续靠谱"。这正是 τ-bench（Tau-bench）这类多轮基准的价值所在：它把智能体放进多轮、带反馈、带约束的业务流程里，衡量的是**可靠性而非峰值能力**。在单轮榜单上接近满分的栈，到了 τ-bench 这类多轮场景常常出现明显滑坡，因为多轮会放大任何一次"收尾不干净"的后果——一个遗留的脏状态会污染后续所有轮次。 这也解释了为什么 IDE 内的人机回路栈（Cursor、Cline）在"实际交付"维度反而口碑最好：它们并不追求全自主，而是把收尾的关键决策点交还给人。它们的高交付率不是因为智能体更强，而是因为**收尾税被人在环显式吸收了**。对自主智能体而言，向 τ-bench 这类多轮可靠性的迁移，本质上是把"收尾"从一次性事件重新定义为贯穿全程的状态卫生。 ### 五、收尾失败解剖：从"能跑"到"能合并" 把 24pp 的塌方拆开看，失败集中在三个收尾点： 1. **核心功能失败**——测试覆盖之外的边界场景仍出错，自动评分器通过的路径只是真值集的一个子集。 2. **破坏其他代码**——长程任务中为了局部目标改动共享模块，引入回归；这在"20 分钟任务"里几乎不会出现，在多文件长程任务里却是常态。 3. **代码质量**——不符合仓库既有风格、命名、抽象层次、测试惯例，维护者出于长期维护成本而拒绝合并。 一个能体现收尾思维的工程闭环，是用一个"合并就绪检查"门把住出口，而不是把所有希望寄托在模型本身的克制力上： ```python def merge_readiness_gate(patch, repo): review = reviewer_agent.critique(patch, repo_standards=repo.conventions) regress = ci.run(repo.apply(patch), full_suite=True) # 全量回归而非仅任务测试 scope = analyze_blame(patch) # 是否动到无关共享模块 return { "mergeable": review.score > 0.8 and regress.passed and not scope.risky, "blockers": review.blockers + regress.failures + scope.violations, } ``` 这段伪代码的关键不是某个 API，而是**把"可合并性"显式建模成一个独立于"测试通过"的目标**，并用维护者视角、全量回归、变更范围分析三道闸门去逼近 METR 那个 24pp 的缺口。 ### 六、补位工具栈：谁在认真补收尾能力 真正面向交付而非刷榜的工具栈，差异化的正是收尾机制。**OpenHands** 把审查、回滚、可挂 CI 的执行循环做进默认流程，让"边做边自审"成为常态；**SWE-agent** 用精简的 Agent-Computer Interface 降低交互噪声，但收尾仍偏轻。**Claude Code** 这类终端 Agent 靠强工具调用与自审能力把单点交付质量拉高，但长程收尾仍依赖人盯。IDE 内的 **Cursor/Cline** 走另一条路——不假装全自主，而是在每个收尾点把人请回来，用"人在环"直接抹掉收尾税。 值得注意的是一类新出现的"**评审智能体**"：它们不写代码，专门模拟维护者视角对产物做合并前评审，本质上是把 METR 研究里的"盲评维护者"工程化成一个常驻组件。这与本系列反复出现的工具描述工程、护栏等思路同源——**把模型不可靠的判断外包给一个显式的、可审计的工程结构**。选型时，比起问"解出率多少"，更该问"它有没有一个独立的收尾子系统"。 ### 七、变现与训练营：交付率才是真正的卖点 收尾税的发现直接改写了变现叙事。训练营和产品如果仍以"我们的 Agent 能解 X% 的 SWE-bench"为卖点，在 2026 年已经几乎没有差异化空间——榜单都打满了。真正的溢价点变成了"交付率"：你的方案在维护者评审、在真实工单、在多轮返工里，能把多少百分比的产物真正落到主干/上线。这是一个远比解出率诚实、也远更难造假的指标。 对训练营而言，这意味着课程重心应从"如何让 Agent 跑起来"转向"如何让 Agent 收得住尾"——评审闭环、回归门、变更范围控制、多轮可靠性。对企业产品而言，KPI 应从"任务完成数"转向"可合并/可上线交付率"，并接受一个事实：在当前时间地平线下，追求 100% 全自主交付是反工程的，**显式标注"人在环收尾点"反而是更成熟的产品形态**。 ### 八、收尾工程的三条操作红线 把上述实证收口为可落地的工程纪律： - **第一，把基准分数当上限而非承诺。** 任何对外宣称的解出率，内部都应按 ~24pp 折算成合并率预期，并用维护者盲评做周期性校准。 - **第二，为长程任务引入显式收尾子系统。** 全量回归、变更范围分析、维护者视角评审三道门缺一不可；收尾不是模型能力问题，是工程结构问题。 - **第三，按任务尺度匹配自主度。** 20 分钟级任务可放手全自主；跨小时、跨文件的长程任务，必须在关键收尾点保留人在环，这是用当前时间地平线换来的最划算保险。 ## 收尾漏斗：从解出到交付的逐级塌方 ```mermaid flowchart TD A["基准任务集
(人类≈20分钟)"] --> B["自动评分器通过
≈ 榜单解出率 85%–95%"] B --> C["维护者盲评可合并
≈ 解出率 −24pp"] C --> D["全量回归无破坏
再衰减(长程任务更陡)"] D --> E["生产可上线交付
真实交付率"] B -.- X["收尾税
核心功能失败 / 破坏他码 / 代码质量"] C -.- X D -.- X style X fill:#fde2e2,stroke:#c0392b,stroke-width:2px style E fill:#e8f5e9,stroke:#2e7d32 ``` 漏斗的每一级都在泄漏，而泄漏集中在最后三级——这正是榜单看不见、却决定真实价值的部分。 ## 推荐方案 - **个人开发者 / 小团队**：用 Claude Code 或 OpenHands 做主体执行，但在每个 PR 前强制跑一遍"合并就绪检查"门（自审 + 全量回归 + 变更范围）。投入小，能直接吃掉大部分 24pp 缺口。 - **研究型 / 刷榜场景**：把 τ-bench、METR 时间地平线这类多轮可靠性指标纳入主评测，别再单押 SWE-bench Verified；用维护者盲评定期校准榜单分数的真实含义。 - **企业生产 / 工单系统**：以"可合并/可上线交付率"为北极星 KPI，长程任务保留显式人在环收尾点；优先选有独立收尾子系统（审查、回滚、CI 集成）的栈，而非解出率最高的栈。 - **训练营 / 产品包装**：卖点从"解出率"切换到"交付率与收尾工程"，用维护者评审数据做差异化证据，这在榜单饱和的 2026 是少数还能讲出壁垒的角度。 - **通用原则**：当前时间地平线下，"会做"已不是瓶颈，"会收尾"才是。任何自主智能体方案，若没有一个独立于生成过程的收尾子系统，它的真实交付率都应被默认打一个 24pp 的折扣。 ## 参考来源 1. [Many SWE-bench-Passing PRs Would Not Be Merged into Main — METR](https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/) — 维护者盲评 296 个 AI PR，合并率比自动评分器低约 24pp，提升速度每年慢 9.6pp 2. [Measuring AI Ability to Complete Long Tasks — arXiv 2503.14499](https://arxiv.org/abs/2503.14499) — METR 时间地平线研究，50% 任务地平线约每 7 个月翻倍 3. [Beyond SWE-bench: METR's Long-Horizon Benchmark Reveals the Real Reliability Gap — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/08/metr-long-horizon-autonomy-evaluation-multi-day-agent-tasks) — SWE-bench Verified 仅对应人类约 20 分钟任务，与整天自主能力的鸿沟 4. [Why We No Longer Evaluate SWE-bench Verified — OpenAI](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) — 基准已饱和，分数提升不再反映有意义的能力提升 5. [SWE-Bench Live Leaderboard Q2 2026 Analysis — DigitalApplied](https://www.digitalapplied.com/blog/swe-bench-live-leaderboard-q2-2026-analysis) — 2026 年榜单头部解出率逼近 85%–95% 区间及分数实际预测力分析 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。