编程 Agent 达标近七成，全部完成仅两成六

编码 agent 能满足约七成验收条件，却只能完整交付约四分之一的任务。这两个数字并不矛盾：一个功能可能页面改了、接口接了，最后仍有一条关键要求没有落地。

Co-Design Bench 把这种「大部分做完了」与「真正交付了」的差距量化出来。对前端和全栈开发者，它最有用的启发是：怎样拆需求、写验收条件，以及证明功能真的能用。

七成达标，为什么只有四分之一能交付

据原文转述，Co-Design Bench 来自 Alibaba Token Hub 与复旦、浙大、港中文、上海交大、NTU 的研究人员，论文于 10 月 26 日提交 arXiv。

研究从 26,314 次真实用户编码会话、37,463 条去重查询中，整理出 273 个任务，并由专家编写 2,331 条隐藏验收条件。每个任务都有从会话日志恢复并验证可运行的 Web 应用，以及规范化后的用户请求，agent 在此基础上修改。

十个模型端点中，The Decoder 将最佳端点识别为 GPT-6 Astra。它平均通过每个任务 69.9% 的验收条件，完整通过率却只有 26.4%。也就是说，同一批运行中，73.6% 的任务至少留下一条未满足要求。

验收条件通过七成，不等于项目离交付只差三成。

剩下的可能恰好是依赖链末端的连接工作：按钮能否触发接口、状态能否同步、偏好能否持久化。前面的代码写得再多，也不能替这些条件交差。

两个赛道的差距更明显：

• Multimodal Editing 面向局部修改，可附带图片、音频、视频或文档，领先端点的条件覆盖率为 75.4%，完整通过率为 41.0%。
• Repository Editing 要协调组件、路由、状态和数据流，两个数字分别降到 66.7% 和 17.9%。

但这批任务经过刻意筛选：研究者偏向结构复杂、容易验证，以及用户曾多次改写请求或回滚的案例。它是来自真实工作的困难集，不能把 26.4% 直接解释成日常编码任务的成功率，也不能据此推算人工收尾成本。

验收不能停在「代码里有这个函数」

这项评测采用先判定、再反驳的流程。

第一位评审结合源码和浏览器证据，逐条判断是否满足要求。第二个 LLM 验证器专门挑战通过结论，寻找空实现、硬编码输出、无法到达的入口和需求偏差。

视觉要求必须有成功渲染和截图；交互要求必须有浏览器操作记录。缺少证据会中止评估。

这套规则解决的是一个常见误判：源码里存在处理函数，只能证明代码写在那里，不能证明用户能从页面找到入口并完成操作。

原文用下面的探针检查设置页的导出按钮是否真的产生下载：

// acceptance probe: does the feature exist, or does it just read like it does
await page.goto("http://localhost:3000/settings");
await page.click("text=Export");
const download = await page.waitForEvent("download"); // times out if the button is decorative

需要留意最后一行的事件等待顺序：示例先点击、后监听下载，实际使用时可能漏掉快速触发的事件，应在点击前建立等待。它表达的验收方向是对的，但代码本身仍需审查。

对 agent 工作流来说，读 diff 和操作页面回答的是不同问题。前者帮助检查实现，后者验证用户路径是否闭合。

任务越宽，越容易卡在最后一环

原文报告，全部十个端点都出现了同一种趋势：Repository Editing 涉及三至四类改动时，验收条件完成情况比只涉及一至两类更差。

例如，把税费总额移到汇总卡片、同步逐项明细、持久化币种偏好，虽然能写成一句需求，却横跨展示、状态同步和存储。任意一处没有接好，最终行为就不完整。

因此，作者建议按一至两类改动拆任务，按顺序执行，每一步分别验收。这有评测趋势作为依据，但原文没有给出「拆分前后成功率」的对照实验，不能把建议当成已经量化验证的收益。

运行环境同样影响成绩。所有端点统一使用 Claude Code，每个任务最多三小时、120 轮，研究仍报告了运行框架（harness）敏感性。这里的框架可以理解为模型使用工具、接收反馈并持续执行任务的整套环境。

原文援引 The Decoder：Qwen3.8-27B 在较大规模改造中，随环境不同得分为 75 或 56，但没有交代这两个数的量纲。另一项 Hugging Face OpenEnv 测量中，相同模型权重在两种框架下分别得到 62% 和 33%。

所以，比较编码能力时，模型和执行框架应当一起报告。单列模型名，信息并不完整。

我的判断

我认可这篇文章对验收的要求：agent 声称完成，最好能对应到可重复观察的行为。尤其是跨组件、跨路由的修改，最需要检查连接处，不能只确认文件都改到了。

它也有明确边界。每个任务只有一次固定请求，没有追问和中途纠正，与真实结对开发不同。评审主要由 LLM 完成，虽然两名前端专家抽查了 200 份任务输出，换用其他评审模型后，Qwen3.8-27B 的仓库赛道分数变化最多约 0.04，但这些检查仍不能替代全部人工验证。

论文还是未经同行评审的预印本；Alibaba 既开发 Qwen，又参与测试 Qwen，也需要读者保留审视。公开部分只有 Multimodal Editing 的 96 个任务、521 条条件，Repository Editing 尚未公开，外部复现存在限制。

相较于一次性让 agent 完成整包需求，拆任务、增加浏览器验收是合理取舍，不过会增加执行和维护成本。原文没有测量这些成本，也没有证明所有任务都该拆到相同粒度。

最值得采用的是它的验收方法，最不该照搬的是把困难集成绩当成团队生产率。

能拿来做什么

• 给 agent 的前端任务附上简短、明确的验收条件，写出入口、操作和预期结果。例如「设置页点击 Export 后产生下载」，比「完成导出功能」更容易执行和检查。
• 为新增交互保留一条浏览器验证路径，实际加载页面、点击入口并观察结果；涉及下载等事件时，先建立监听，再触发操作。
• 遇到同时修改组件、路由、状态和持久化的请求，先按依赖顺序拆分，并在每步结束后验证已有行为是否仍然成立。
• 比较团队使用的编码 agent 时，同时记录模型、运行框架和执行限制，并分别统计条件覆盖率与完整任务通过率，避免把两种指标混为一谈。