评估编程智能体，先按任务拆分指标

AI 编程助手的 PR 接受率高，不等于它适合你们团队的所有任务。原文引用一项覆盖 7,156 个 PR 的 2026 年研究，提出一个更实用的评估办法：先按任务类型拆开，再比较接受率和交付成本。

这篇值得读的地方，是提醒团队别被一个总分带偏。文档改得好，不能直接证明功能开发也可靠；PR 最后被接受，也不能说明它节省了多少人工。真正该评估的是：哪类工作交给哪个 Agent，连同审核和返工一起算，是否划算。

为什么任务类型比总接受率更有参考价值

原文引用的研究名为 Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance，比较了五种 coding agent、九类任务，并追踪了 32 周的接受率。

这里的「接受率」只有一个明确含义：提交的 PR 是否被接受。它不能单独代表代码质量、安全性、可维护性，也不能直接代表开发者生产力。

研究中，文档任务的接受率是 82.1%，新功能任务为 66.1%，相差约 16 个百分点。这个差距，比许多任务类别内不同 Agent 之间的典型差距还大。

原因不难理解。文档修改的范围通常更窄，审核标准也更容易看见。功能开发则同时涉及需求理解、依赖选择、测试和协作。代码看着合理，只要对预期行为理解错了，仍然可能被拒绝。

评估 Agent 时，先问它在做什么，再问它是谁。

但这不等于文档任务天然简单。原文给出的是数据集中的总体结果，没有继续区分文档规模、功能复杂度或仓库差异。

这些数据能用来选 Agent 吗

可以作为试用线索，不能直接当采购排名。

Claude Code 在文档类别中以 92.3% 的接受率领先，报告中的功能任务表现也最好。功能任务整体接受率较低，与某个 Agent 在该类别领先并不矛盾：前者描述任务难度，后者描述类别内部的比较。

OpenAI Codex 在全部九类任务中表现持续较强，接受率范围为 59.6% 至 88.6%。论文还报告，它在若干类别上相对其他 Agent 具有统计显著优势。不过，原文没有展开这些类别、差值和统计方法，不能据此补出更细的排名。

Cursor 则在修复类别领先，接受率为 80.4%。类别冠军会变化，这正是不能只看综合成绩的原因。

时间维度也有差别。Devin 是 32 周观察期内唯一呈现持续正向接受趋势的 Agent，原文将增幅写为每周 0.77%，其他 Agent 大体稳定。这里没有进一步解释 0.77% 的计算口径，不能擅自改成「每周提高 0.77 个百分点」，更不能向未来无限外推。

这些都是特定数据集和时间窗口内的历史结果。原文没有列出具体 Agent 版本，因此无法确认今天使用的版本是否对应研究中的对象。

团队自己的评测，要把审核成本算进去

原文建议的任务分层基准（task-stratified benchmark），就是把不同类型的工作分开记账。

先从真实待办里选任务，例如文档、缺陷修复、功能开发、重构和测试。研究覆盖九类任务，你们不必照抄九类；评测应该对应团队真正准备交出去的工作。

接着，在任务开始前写清验收条件：目标是什么、允许改到哪里、涉及哪些文件或服务、预期行为是什么，以及必须提供哪些验证。否则，Agent 做完以后，人再临时决定「这个不算」，结果很难比较。

记录时，按类别分别计算接受率。同时补上审核耗时、返工、上线后才发现的缺陷、测试失败，以及人工编辑量。后面这些是作者建议增加的指标，不是该研究已经证明的结果。

例如，同样是一个最终被接受的 Node 缺陷修复，一个只需检查测试证据，另一个需要人工重写关键逻辑，它们对团队的价值显然不同。

真正要比较的是让变更达到可接受状态的完整成本。

这也要求输出进入正常交付流程：需求关联实现，实现关联审核和测试证据，最后记录结果。风险较高的功能任务，要明确谁负责审核、哪些检查必须通过。被拒绝时，留下拒绝原因和修改步骤，避免下一轮重新拼凑上下文。

评测还要定期重复，并记录 Agent 版本、任务类别、仓库环境和验收条件。模型、提示词、仓库约定和审核习惯都可能变化，一次成绩不足以长期定论。

我的判断

我赞同按任务分层。它比只看演示效果或综合接受率更接近团队的真实决策：是让 Agent 写文档、修缺陷，还是参与功能开发，应该分别回答。

但接受率仍然受审核标准和任务分配影响。如果不同 Agent 接到的任务难度不同，或者审核者尺度不同，数字就不能直接横向比较。原文给出的信息不足以判断研究如何控制这些因素，也没有提供足够细节让读者独立核验。

作者提出的追踪流程、审核归属和额外成本指标，在工程上有道理；原文却没有给出采用这些措施前后的对照数据。它们属于实践建议，不能写成已验证的提效结论。

与直接套用排行榜相比，自建基准更贴近仓库和业务，但也需要投入。一般团队可以先从常见任务开始，保持同类任务的验收标准一致，再逐步补齐记录。

能拿来做什么

• 给前端或 Node 的 Agent 试用记录增加「任务类型」字段，把文档、缺陷修复、功能开发、重构和测试分别统计，避免总接受率掩盖某一类的短板。
• 在任务描述中提前写明修改边界、预期行为和必需验证，并要求 PR 对应这些条件提供实现说明与测试证据。
• 除了是否接受，再记录审核时间、修改轮次和人工编辑量；拒绝的 PR 也要计入成本，并保留拒绝原因。
• 每次复评都记录 Agent 版本与仓库环境，用同类任务、相同验收标准比较结果，再决定扩大哪些任务的使用范围。