编码 agent 自己写的坑，下一阶段自己踩

现有编码基准都在考「一次请求改一个固定代码库」。可真实的软件是长出来的：新需求叠在旧代码上。10 月 27 日提交的 FeatureArc 专考这种接力题，结果发现 agent 会把上一阶段的坑原封不动带进下一阶段，而且几乎从不回头检查。

一、发生了什么

FeatureArc 从仓库历史里自动构建任务：一个功能拆成 2 到 10 个连续阶段，每阶段在前一阶段的产物上扩展，四门编程语言都覆盖。每个阶段配两类可执行检查：F2P 验证新行为先失败后通过，P2P 保证旧行为不被改坏，先在参考代码上验一遍再入库，共 73 个人工复核过的任务。评测条件相当严苛：10 个编码 agent，各自在一个持久会话和工作区里干到底，不给外部测试反馈，也不许回滚——等于没有代码评审、没有 CI 红灯，全靠 agent 自己把关。

结果：第一阶段合计成功率 62.7%，到最终代码上验收整个功能只剩 28.5%。轨迹分析给出了主因——继承缺陷，72.9% 的失败后期阶段里都有它的身影。更糟的是发现机制缺失：出错的后续阶段里，agent 约 95% 的情况没察觉早前埋下的错误，自测也极少回看前面的阶段。作者团队来自腾讯，这套流水线已用于内部评测，并指导混元系列模型的研发。

这个设定为什么重要？因为现行的主流编码基准大多一次请求改一个固定代码库，agent 不必为自己上一轮的产物负责。而真实开发是接力的：你今天写的接口，三个月后同事要在上面加需求。FeatureArc 把「对别人的代码负责」换成了「对自己的代码负责」，难度反而更高——没有代码评审兜底时，自己的坑自己最容易看不见。这是背景，不是论文结论。

二、跟你有什么关系

做编码 agent 的：单请求跑分高不等于能接力开发，先测「在自己代码上续写」这个设定。

做技术选型的：10 个 agent 的横向结果可以直接参考，选型别只看单点式榜单。

管研发流程的：阶段之间强制人工审查或自动回归，是目前数据支持的唯一止血手段。

三、怎么用

1. 给自己的 agent 流水线加阶段间验收：F2P 加 P2P 双检查，新旧行为都要过。
2. 要求 agent 每阶段开始前重跑历史测试，把「回看」写进工作流，而不是指望它自觉。
3. 评估供应商时直接问「接力场景成功率」，只报单点成绩的先打折听。

四、三个别信的说法

一次成功等于功能完成。 第一阶段六成多的成功率，到全功能验收只剩两成八，接力会放大一切早期失误。

agent 会自己发现旧错误。 约 95% 的失败阶段里旧错误被原样放过，自测覆盖基本不回看历史。

换个更强的模型就能解决。 10 个 agent 全线掉分，这是任务结构的挑战，不是能力参数问题。

五、一句话结论

让 agent 独立把功能从一版养到十版，现在还差一个「回头看」的习惯。

信息来源

• 论文摘要：编码 agent 演进式功能基准 FeatureArc（arXiv），2026 年 10 月 27 日提交

功能与价格以官方公告为准。本文写于 2026 年 10 月 29 日。