Co-Design Bench 实测：26.4% 全对率，编码智能体还差多少

一句话结论：在 273 个真实用户改稿任务上，最强的十个编码智能体里只有 GPT-6 Astra 平均能通过 69.9% 的验收标准，而能让每一条标准全部通过的完整交付率只有 26.4%——换句话说，四分之三的活儿还得人接手收尾。这份由阿里巴巴 Token Hub、复旦大学等团队在 2026 年 10 月发布的 Co-Design Bench 基准，第一次把「编码智能体到底能不能把活干完」这件事摆到了可复算的位置上。

如果你一直在看 SWE-bench 这类榜单，会形成一个相当牢固的印象：现在的编码智能体已经接近满分了。论文作者在开篇就点破了这件事的荒谬。当模型学会自己运行、自己检查、自己修代码之后，传统的软件工程基准上分数普遍超过 99%，模型之间的差异几乎无法度量。于是团队把整套评测逻辑推翻重做，从 26314 场真实编码会话里捞出需求，做成了一个更贴近日常工作的基准。

Co-Design Bench 到底测的是什么

它的出发点是一个很具体的场景。真实的用户不会给智能体一个从零开始的仓库，然后说「帮我实现这个功能」。用户做的事是：先看一个已经能跑的应用，然后提一条修改意见——可能还附一段录屏、一张截图、一份文档——然后看改完的结果满不满意，接着提下一条。

这个循环里的每一轮都对智能体提出了复合要求。请求里可能同时包含视觉线索、时长限制、时间轴对齐、状态回写，需要智能体把多模态证据和跨组件的依赖修改连起来。论文里举的一个例子是运动片段剪辑器的需求，同时约束片段数量、单段时长、缩放下的时间轴对齐，还要在删除后正确重置状态让插入按钮重新可用。

基于这种真实需求，团队把任务拆成两条赛道。

任务还按三个能力维度打了标签：扎根理解（Grounded Understanding，92 个任务）、界面转换（UI Transformation，55 个）、功能实现（Functional Implementation，126 个）。多标签体系一共产出 1172 条任务-能力关联，273 个任务里有 265 个（97.1%）带多重标签，174 个（63.7%）跨越一个以上的高层维度。也就是说，没有哪类任务是「纯改样式」这种容易拿分的。

验收标准是怎么写的：不看标准答案，看证据

Co-Design Bench 最特别的一点是它自称 reference-free——不需要标准代码，也不需要目标截图。这跟绝大多数视觉前端基准的做法完全相反，那些基准都给一份「标准答案」让模型去还原。

它的做法是把验收标准写成隐藏的、专家撰写的条目，并且明确允许任何合法实现。每个任务由三部分组成：一份可运行的改动前应用及其容器化环境、一条规范化的用户请求（可带附件与会话历史）、以及智能体执行期间完全看不到的隐藏验收标准。

标准的挑选过程本身也有筛选逻辑。团队从 39325 条生产环境查询出发，用精确哈希和近重复检测（token Jaccard 大于 0.8）去掉冗余，剩下 37463 条唯一请求；再经过六道硬过滤，把环境阻塞、不可执行、无边界、非编辑类请求全部剔除；然后按难度（0 到 5）、可验证性（0 到 3）、历史失败信号（0 到 2）排序打分，最后每个会话最多取三条合并成一个有边界的任务，由专家精修请求并撰写隐藏标准。

关键在于「可运行起点」这道门槛。每个起始应用必须能构建、能启动、能渲染，否则会被丢弃。论文描述的修复循环是：装依赖、构建、容器启动、Playwright 渲染，失败则诊断、修复、复查，实在救不回来的服务直接剪掉。最终每个任务包长这样：

task/ ├── baseline/ ├── env.manifest ├── request + media/ └── validation.log

怎么读这张榜：三个数字缺一不可

Co-Design Bench 用同一套智能体执行框架（agentic harness）跑了十个模型端点。这个榜最容易被误读的地方在于它给了三个不同口径的分数，含义完全不同。

严格完成度与全对率之间的差值，就是那些「大部分做对了但还差一处收尾」的任务贡献出来的信用。这个 26.4% 的数字，才是「这份活儿能不能直接交出去」的答案。

十个端点的完整排名如下：

首尾的严格完成度差距是 18.8 个百分点，但全对率差距被放大到接近四倍，26.4% 对 6.6%。越弱的模型在「最后一点收尾」上崩得越厉害。

换赛道就换排名：小模型也能登顶

这是这份基准最有实操价值的一个发现。把 100 个 ME 任务和 173 个 RE 任务分开看，排名会变。

ME 赛道（前六）：gpt-6-astra 严格完成度 0.754、全对率 41.0%；opus-5 是 0.695 / 30.0%；qwen3.8-max-0902 是 0.667 / 31.0%；kimi-k3 是 0.662 / 26.0%；qwen3.8-27b 是 0.642 / 23.0%；opus-4-8 是 0.593 / 16.0%。

RE 赛道则完全换了一副面孔：gpt-6-astra 0.667 / 17.9% 仍然第一，但 qwen3.8-27b 上升到第二位（0.645 / 10.4%），qwen3.8-max-0902 第三（0.644 / 8.1%），opus-5 掉到第四（0.642 / 11.6%），kimi-k3 掉到第六（0.610 / 9.8%）。

两条赛道的排名 Spearman 相关系数是 0.818，看起来相关性不错，但 ME 与 RE 的端点分差分别是 28.7 和 13.0 个百分点。论文的结论很直接：合并成一个总排名会掩盖设置相关的强弱项。Qwen3.8-27B 这个参数量小得多的模型，在大型改造类任务上爬到第二，但作者并没有从中推导出模型的一般性优势——因为这个名次只在特定设置下成立。

换 harness 之后排名还会再变。论文用 kimi-k3 和 Qwen3.8-27B 测了 codex 0.142.0、opencode 1.18.13、qwen-code 0.21.11 三套执行框架，ME 赛道上 harness 排名在两个模型间完全倒转（Spearman 负 1.00）。同一个模型换个壳，成绩在 ME 上可以差 7.9 个百分点，在 RE 上可以差 18.9 个百分点。

改得越多，做得越差

RE 赛道按编辑类型数量分组后，差距非常明显。

跨越 3 到 4 种编辑类型的任务比只改 1 到 2 种的任务严格完成度低 6.3 个百分点，零通过率更是从 0.9% 跳到 5.8%，涨了六倍多。做一次局部改动和做一次牵一发动全身的重构，对智能体来说完全是两种难度量级。

附件模态的分组数据同样反直觉。纯文本任务的合并严格分最高（0.637），全对率也最高（37.0%）；文档任务严格分最高（0.652），但全对率只有 18.2%。也就是说，标准覆盖度高的任务不等于容易完整交付的任务，两者给出的是完全不同的难度视图。

按模态分，Qwen3.8-27B 领跑纯文本任务（0.779），opus-5 领跑图片任务（0.891），GPT-6 Astra 拿下视频、音频和文档三项第一。

钱花得更多不等于活干得更好

排行榜里还有一个容易被忽略的维度：投入。论文把轮次、输出长度、总 token 流量和工具调用占比都记了下来。

glm-5.2 用 69 轮、729 万 token 换到 57.2% 的 ME 严格完成度，GPT-6 Astra 用 32 轮、124 万 token 换到 75.4%。反过来在 RE 赛道，qwen3.8-27b 花了 57 轮和 672 万 token 拿到 64.5%，而 gpt-6-astra 只花 48 轮和 233 万 token 就拿到 66.7%。努力程度与完成度之间没有正相关。

工具调用结构本身也在说话。图片检查平均每次运行 ME 上有 14.47 次、RE 上只有 2.78 次，而编辑写入类调用占比从 7.3% 升到 27.6%。ME 视频任务的中位轮次是 44，纯文本任务只有 27。智能体在处理视频时会自己装工具：68.5% 的视频轨迹调用了 OpenCV，31.5% 调用 ffmpeg，音频轨迹里 25.0% 用 ffmpeg、4.4% 用 faster-whisper，还有些直接跑预训练感知模型（AST、CLAP、Whisper、Qwen2-Audio、CLIP、DINOv2、OWLv2）来给媒体内容打标。

验收机制：先判通过，再推翻

Co-Design Bench 的判定流程叫 judge-then-refute。第一步由一个裁判模型基于源码和浏览器实际执行证据给每条标准打 PASS / PARTIAL / FAIL；第二步另起一个独立的 LLM 验证器，专门去挑战那些被判 PASS 的判定，专门找假界面和硬编码结果；第三步审计视觉与交互类声明。论文提到，有专门针对功能实现类的 45 条标准被抽取出来做人工复核，标注一致性也做了统计。

这套机制的作用是防止「看起来跑起来了但其实是糊的」。因为标准是隐藏的，智能体没法针对性优化，裁判又会被反查，所以分数比单轮裁判更可信。作者还做了裁判敏感性实验，换一个裁判模型后模型的相对排名与分数分布保持稳定。

为什么必须给智能体迭代的机会

论文里有一个对照实验特别值得看，因为它解释了这份基准为什么必须用智能体执行而不是单轮输出。在同样的 150 个 WebCompass-edit 任务上，把 qwen3.7-plus 从单轮执行改成智能体迭代执行，平均分级特性完成度从 73.6% 升到 95.1%，特征规则、裁判和渲染管线全程不变。在同一批任务上，opus-4-8 用智能体执行能到 99.4%。

21.5 个百分点的差距，全部来自「允许模型自己跑、自己看、自己改」这件事。所以任何拿单轮输出打的编码分数，跟这份基准是没法直接比的。

怎么用这张榜选型

把上面的数据翻译成实操的选择逻辑，大概是这样。

如果你做的是单页视觉改动或者小范围样式调整，ME 赛道更有参考价值，此时 Claude Opus 5 和 Qwen3.8-Max 跟 GPT-6 Astra 的差距在 6 到 9 个百分点内，性价比要看你的价格结构。如果你要动的是多文件仓库的协调改造，RE 才是该看的数，此时 Qwen3.8-27B 意外地紧贴头部，值得单独测一下你的实际仓库。

其次要记住 26.4% 这个数。用户对编码智能体的期待需要重设：目前它是「干完八成活」的工具，不是「交付可用成品」的工具。用它的时候，检查清单要由你来兜。

第三，别只盯全对率。按模态、按编辑类型数分组看，你的场景大概率更接近某个具体格子，而不是总体均值。文档类附件在 Co-Design Bench 里是「标准覆盖高但完整交付低」的典型，图片类任务反倒是 opus-5 的强项。

最后，harness 的影响可以和模型本身一样大。同一套模型换三套执行框架，成绩波动最高能到 18.9 个百分点。升级 CLI 工具、换 agent 运行时，值得当成一次独立的调优来做，而不是顺手的事。

常见问题

Co-Design Bench 和 SWE-bench 有什么区别？

SWE-bench 测的是从 GitHub issue 出发修 bug，Co-Design Bench 测的是从真实用户会话里捞出来的复合改稿请求，任务覆盖局部视觉编辑和跨组件协调修改。Co-Design Bench 额外支持图片、音频、视频、文档五种输入模态，并且不需要标准代码或目标截图。它一共有 273 个任务、2331 条隐藏验收标准，而 SWE-bench 是 issue 驱动的仓库级任务。

26.4% 的全对率是不是意味着编码智能体只有四分之一能用？

不是这个意思。26.4% 是任务级全对率，指十个模型端点里最强的那一个，在 273 个任务中有 26.4% 的任务做到了全部标准 PASS。其余 73.6% 的任务里，大部分要求都完成了，只是至少有一处细节没收尾。严格完成度 69.9% 反映的是前者。所以更准确的表述是：智能体基本能干完主体工作，但收尾仍需人工。

Co-Design Bench 的数据是公开的吗？可以自己复现吗？

论文在 arXiv 上以 CC BY-NC-SA 4.0 协议发布，项目站提供 Demo、排行榜、任务浏览、评测协议说明以及代码与评测实现，并同时放出 Hugging Face 数据入口。榜单在统一 harness 下跑全部 273 个任务，每条任务都能打开查看输入、模型输出与验收标准。

小结

Co-Design Bench 做的事情不复杂，但它把一个长期被榜单分数掩盖的事实摆到了明面上：编码智能体的能力增长是真实的，但距离「接过来就能交」还有距离。十个端点里最强的那个，平均每条任务能过七成验收标准，每四个任务里能完整交付一个。

这个 26.4% 会成为接下来一年里越来越常被引用的数字，因为它把交付责任划在了清楚的位置上。模型负责把活推到接近完成，人负责最后一公里，而基准要做的只是让这最后一公里的距离变得可测量、可比较、可复算。

相关阅读

• Anthropic 发布 Sonnet 5.5：编码基准 10.3% 升至 70.6%，成本降 30%
• 联想 TianxiCode 登顶 SWE-bench-Live：71% 问题解决率与代码智能体架构
• Endor Labs 智能体安全基准：功能正确率 87.2%，安全正确率仅 37.4%
• GPT-6 Astra 一周设计出硬件：BenchCAD 得分 0.594