不同 Code Agent 在文档、功能开发和缺陷修复任务中的表现是否一致？

作者：袖梨 2026-09-19

不同 Code Agent 在文档、功能开发和缺陷修复任务中的表现并不一致。把所有任务混在一起计算一个总成功率，很容易把“这个工具接到了更容易的任务”误判为“这个工具能力更强”。一项针对 7156 个真实拉取请求的观察研究表明，任务类型带来的差距往往大于多数代理之间的差距：文档任务的合并率明显高于新功能任务，而在缺陷修复等核心开发任务上，代理之间又出现了更容易被统计检出的差异。因此，团队不该只问哪个 Agent 总榜第一，而应问它在自己的任务结构、仓库约束和审查标准下是否更合适。

为什么总成功率不能直接回答选型问题

评估 Code Agent 时，一个常见做法是统计它提交了多少拉取请求，其中多少最终被合并。这个指标直观，也贴近真实工作流，但它同时受到代理能力和任务分布影响。假设代理甲的大部分工作是改 README、补注释和调整配置，代理乙的大部分工作是跨模块开发新功能，即使两者能力相近，甲也可能得到更高的总体合并率。

研究使用 AIDev 数据集中的真实 GitHub 拉取请求，先从 33596 条原始记录中筛选出 7156 条：只保留已关闭、来自采用宽松许可证且拥有一定关注度的仓库，并要求拉取请求关闭前至少收到一位非创建者的审查或评论。研究覆盖 OpenAI Codex、GitHub Copilot、Devin、Cursor 和 Claude Code 五种代理。这里的“接受”被定义为拉取请求已合并，并不是对生成代码做了统一测试后的质量判定。

在筛选后的样本中，各代理承担的任务比例并不相同。例如，有的代理更集中于缺陷修复，有的代理超过一半的样本是功能开发。若直接比较总体合并率，任务难度和仓库工作流就会混入代理差异。研究因此按任务类型分层，在文档、功能、修复、重构、测试、构建、持续集成和日常维护等类别内分别比较。

文档、功能开发和缺陷修复的结果确实不同

文档任务整体更容易被接受

文档任务在全部样本中的合并率为 82.1%，新功能任务为 66.1%，两者相差 16 个百分点。若观察所有任务类别，最高的日常维护类为 84.0%，最低的性能类为 55.4%，跨度达到 29 个百分点。这个跨度说明任务类型本身是重要变量，也解释了为什么不同产品公开的总成功率很难横向比较。

文档任务通常边界清楚、变更局部、验证成本较低，审查者也更容易判断内容是否改善。但研究只证明了统计关联，不能据此断言文档任务的高合并率完全来自任务更简单。不同仓库可能对文档变更采用更宽松的审查规则，提交者也可能事先选择了风险更低的文档工作。

功能开发更考验上下文与系统约束

新功能通常需要理解现有架构、接口契约、兼容性要求和隐含产品规则。研究中没有任何代理在全部任务类别都领先，但在功能类别里，不同代理仍呈现不同结果。Claude Code 在该样本中的功能任务合并率为 72.6%，处于领先位置；不过其总样本只有 139 个拉取请求，远少于样本量超过两千的若干代理，因此不能把这一数字当作稳定的产品排名。

任务分层后的两两检验也显示，显著差异并非遍布所有组合。在执行的 64 组代理与任务比较中，经过多重比较校正后只有 6 组达到显著标准，其中 1 组来自功能任务。这意味着“某代理更擅长功能开发”必须同时查看样本量、效应大小和仓库背景，不能只看某个百分比最高。

缺陷修复最容易拉开代理差距

显著比较中的另外 5 组都来自缺陷修复，表明修复任务可能比文档任务更能暴露代理差异。缺陷修复不仅要求生成合理补丁，还要求定位根因、识别回归范围、理解测试失败与业务行为之间的关系。研究报告的分层结果中，OpenAI Codex 在修复任务上的合并率为 83.0%，Cursor 为 80.4%，而 Devin 为 45.6%。部分两两差异在严格校正后仍达到统计显著。

这些数字适合说明“任务类型会改变相对表现”，却不适合直接承诺某个代理在任何团队里都能复现相同结果。样本中的仓库、使用者、提示方式、代理版本和观察周期并未完全一致，仓库级聚类也没有在主要检验中显式建模。同一个仓库若天然更愿意合并自动生成的拉取请求，会同时抬高某一代理的多条记录。

为什么 ReAct 循环相似，实际效果仍会分化

许多 Code Agent 都可以被概括为“读取状态、规划动作、调用工具、观察结果、继续迭代”的循环，但产品差异并不只存在于循环名称。真正影响结果的是循环中的信息质量、动作边界和纠错机制。

首先是上下文构建。代理是否能准确找到入口文件、调用链、测试约定和仓库级说明，决定了它看到的是问题的局部还是完整约束。文档修改可能只需检索少量文件，而跨模块功能与缺陷修复更依赖稳定的代码索引、语义检索和依赖追踪。

其次是工具执行与反馈。能否可靠运行测试、解析失败日志、区分环境故障与代码故障，会直接改变迭代质量。两个代理即使使用相同模型，一个只把终端末尾几行返回给模型，另一个能保留结构化诊断和相关上下文，后者通常更容易做出正确修复。

再次是修改策略。优秀的代理会控制变更范围，在提交前检查差异、补充针对性测试，并在证据不足时停止或请求澄清。功能开发需要拆解需求和维护接口一致性；缺陷修复需要先构造可复现条件，再验证补丁没有掩盖症状；文档任务则强调事实与当前代码一致。不同任务需要的工作编排不是伪需求，但编排是否带来价值必须由结果验证，而不能由流程步骤的多少来证明。

最后是产品层的治理能力，包括权限隔离、命令审批、缓存策略、失败恢复、审计记录和与代码审查平台的衔接。这些能力未必提高一次补丁的模型得分，却决定代理能否安全地进入团队生产流程。因此，核心循环相似并不等于端到端系统同质化。

研究结果应该怎样解读

合并率是工作流结果，不等同于代码质量

拉取请求被合并，说明它通过了特定仓库在特定时间的接受流程，但不能证明它没有缺陷、没有增加复杂度或长期维护成本更低。审查严格程度、仓库活跃度、维护者偏好和提交者是否继续修改，都可能影响最终状态。团队应把合并率与测试通过率、审查返工次数、线上缺陷、回滚率、静态分析告警和后续维护成本一起使用。

这是观察研究，不是随机对照实验

研究记录了公开仓库中已经发生的行为，没有把相同任务随机分配给不同代理。作者明确不主张因果关系。代理表现随时间变化，也可能来自模型升级、用户熟练度提升或任务分布变化。研究发现 Devin 在 32 个活跃周内呈现每周增加 0.77 个百分点的趋势，但周间波动仍然较大，不能简单解释为单一产品改进造成。

样本量与观察窗口并不均衡

五种代理的样本从 139 个到 2252 个拉取请求不等，活跃观察期从 11 周到 32 周不等。研究用共同的 11 周窗口做了敏感性分析，整体排序仍较稳定，但这只能缓解时间窗口问题，不能消除仓库、用户和任务选择偏差。尤其是小样本类别，即使合并率看起来很高，也可能因少量记录变化而明显波动。

团队如何建立自己的分任务评估

实际选型可以采用小规模、可重复的内部基准，而不是照搬公开总榜。第一步是从近期工单中抽取具有代表性的任务，并按文档、缺陷修复、功能开发、测试、重构和工程配置分类。每类任务应覆盖简单、中等和复杂样本，同时排除包含未授权敏感数据或无法复现的工单。

第二步是统一约束。不同代理应获得相同的初始仓库状态、任务描述、权限范围、时间预算和可调用工具。若一个代理允许联网、另一个代理只能读取本地代码，结果反映的就不仅是代理差异。测试环境和依赖缓存也应固定，避免安装波动污染结论。

第三步是记录分层指标。可以为每次执行保存是否完成、自动测试结果、人工审查结论、修改文件数、无关改动数、交互次数和总耗时。最终报告必须按任务类型展示成功率和样本数，再给出总体结果。一个简化的数据结构可以是：

{
  "agent": "agent-a",
  "task_type": "bug_fix",
  "task_id": "internal-042",
  "tests_passed": true,
  "review_accepted": true,
  "unrelated_changes": 0,
  "elapsed_minutes": 18
}

第四步是进行盲审。审查者尽量不要看到代理名称，先根据正确性、变更范围、可维护性和测试充分性打分，再揭示工具身份。这样可以减少品牌预期对人工判断的影响。对于缺陷修复，应要求先通过能暴露原问题的测试，再通过完整回归测试；对于功能开发，还应验证边界条件、兼容性和文档同步；对于文档任务，则检查描述能否从当前代码与配置中得到证实。

第五步是计算不确定性。每类只有两三个样本时，不应输出精确到小数点的胜率，更不应宣布永久赢家。可以报告成功数与总数，随着样本积累再计算置信区间。代理或底层模型升级后，应保留版本信息并重新跑一组固定任务，因为旧版本结论未必继续成立。