当最强Agent也只能做对45%的任务：CocoaBench揭开统一数字智能体的真实水平
你有没有碰到过这种情况：给AI Agent一个看起来不那么复杂的任务——比如"帮我找到Costco上某款商品的当前价格，再跟另一个网站做个比价"——结果Agent要么在浏览器里迷路，要么代码写了一半开始幻觉，要么干脆忘了你要什么？单个能力测试的时候成绩都挺好看，一旦需要把视觉、搜索、编码串起来，就原形毕露。
这正是CocoaBench这篇论文要揭示的问题。
核心摘要
现有Agent评测大多只测单一能力——要么纯写代码，要么纯操作GUI，要么纯回答问题。CocoaBench构建了153个人工设计的长时域任务，强制要求Agent灵活组合视觉、搜索、编码三大能力。评测结果令人清醒：最强系统仅45.1%成功率，开源模型最高11.8%。错误分析揭示54%的失败源于推理规划缺陷，29%源于视觉定位不准，17%源于工具执行问题。一个意外的发现是，编码导向的脚手架（Codex、Claude Code）在综合任务上的泛化性远超预期，甚至比通用脚手架表现更好。这篇论文给统一数字智能体泼了一盆冷水，但也指出了最清晰的改进路径。
论文信息
- 标题：CocoaBench: Evaluating Unified Digital Agents in the Wild
- 作者：Shibo Hao, Zhining Zhang, Zhiqi Liang, Tianyang Liu, Yuheng Zha, Qiyue Gao 等31位作者（CocoaBench Team）
- 机构：UC San Diego, MBZUAI IFM 等
- 日期：2026年4月13日
- 链接：https://arxiv.org/abs/2604.11201
- 项目主页：https://cocoabench.github.io/
为什么需要CocoaBench
先看看现有的Agent基准测试都在干什么。
SWE-bench测的是纯编码——给定一个GitHub issue，让Agent修bug。WebArena测的是纯网页操作——在电商网站上买东西、在论坛上发帖。OSWorld测的是桌面GUI操作——打开应用、拖拽文件。它们有一个共同特点：能力边界清晰，任务基本只需要一种核心能力。
但真实的数字工作哪有这么干净？
你让我查一篇论文的引用量，我得先搜索找到论文页面（搜索），再从页面上读取Google Scholar的截图或引用计数（视觉），再把结果整理成结构化格式（编码）。三个能力缺一个就做不了。更复杂的任务——比如"找某个运动员本赛季的得分数据，做一张对比图"——需要的能力组合更密集。
这就是CocoaBench的出发点：在需要能力组合的真实场景里，现有Agent到底行不行？
论文列了一组对比数据，很能说明问题：
| 基准测试 | 主要能力 | 能力组合 | 基础设施耦合 | 自动验证 |
|---|---|---|---|---|
| SWE-bench | Coding | 否 | 高（Git环境） | 是 |
| WebArena | Vision+Search | 部分 | 高（固定网站） | 是 |
| OSWorld | Vision | 否 | 高（桌面环境） | 部分 |
| GAIA | 搜索+推理 | 部分 | 低 | 否（LLM裁判） |
| CocoaBench | V+S+C | 98%任务需组合 | 低 | 是（函数验证） |
说实话，CocoaBench在基础设施解耦这件事上做得挺漂亮。每个任务只定义一条指令和一个评估函数，不绑定任何特定运行时或工具生态——你用OpenClaw跑、用Codex跑、还是用自己的脚手架跑，都行。评估只看最终输出对不对，不关心你中间怎么做的。
CocoaBench怎么设计的
三大核心能力
CocoaBench定义了数字智能体必须具备的三种核心能力：
- 编码：写代码解题、定量分析、调用结构化工具和API
- 搜索：从互联网获取、导航和综合信息
- 视觉：解读视觉输入，与GUI交互
关键数字：98%的任务需要多种能力组合，56.2%的任务需要编码能力。
Figure 2: CocoaBench的统计概览——9个任务域、153个任务、多种资源类型
Figure 3: 三大能力的共现矩阵——Vision+Search、Vision+Coding、Search+Coding以及三者同时需要的任务均有覆盖
153个任务长什么样
9个大域覆盖了商业分析、文化、教育、生活、逻辑谜题、科学、体育、技术、旅行。资源类型也很杂——网页、视频、图片、CSV/PDF文档，甚至还有17个自建网站、Weights & Biases日志、ChatGPT对话记录、Costco购物收据这些"野生"数据源。
一个典型的任务：给定一个购物场景，Agent需要浏览多个电商网站对比价格、从截图中读取商品细节、用代码计算折扣和税费、最终输出一个结构化的价格比较结果。这种任务对人来说可能15分钟搞定，但对Agent来说是全方位的压力测试。
最小化任务定义
这个设计思路我觉得很对。每个任务只有两个东西：
- 一条自然语言指令
- 一个自动评估函数
评估函数不依赖LLM裁判，不用人打分。对于动作导向型任务，设计了基于结果的代理验证器——正确的结果强烈暗示正确的执行过程。比如购物任务，你只需要验证最终价格对不对，不用一步步检查Agent点了哪个按钮。
这套设计的好处是可扩展、可复现——任何Agent都能直接接入评测，不需要适配特定的运行时环境。
Cocoa-Agent：一个受控的对比脚手架
为了公平比较不同模型骨干，论文设计了Cocoa-Agent——一个轻量级、模块化的统一Agent脚手架。
底层跑在AIO Sandbox上，这是一个集成了浏览器、Shell、文件系统的单一Docker容器。Agent采用经典的ReAct模式，配备了39个工具，分5大类：
| 能力类别 | 工具数 | 核心工具 |
|---|---|---|
| Vision | 11 | browser_click, browser_type, browser_screenshot, image_read 等 |
| Search | 11 | browser_navigate, dom_get_text, dom_query_selector, dom_click 等 |
| Coding | 5 | code_execute, shell_execute, file_read, file_write |
| File | 9 | 文件操作相关 |
| Control | 1 | task_complete |
Vision和Search的工具设计有个巧妙的区分：Vision工具是像素级的GUI操作（点击坐标、截图），Search工具是DOM级的内容访问（CSS选择器查询、文本提取）。这两种粒度给了Agent灵活的选择——你可以像人一样"看"网页然后点击，也可以像程序员一样直接解析DOM结构。
实验结果：45.1%的天花板
主实验
所有Agent统一跑30分钟预算、最多50轮交互。结果如下：
| 排名 | 系统 | 骨干模型 | 成功率 |
|---|---|---|---|
| 1 | Codex | GPT-5.4 | 45.1% |
| 2 | OpenClaw | GPT-5.4 | 45.1% |
| 3 | Cocoa-Agent | GPT-5.4 | 36.6% |
| 4 | OpenClaw | Claude Sonnet 4.6 | 34.0% |
| 5 | Cocoa-Agent | Gemini-3.1-Pro | 26.1% |
| 6 | Claude Code | Claude Sonnet 4.6 | 25.5% |
| 7 | Cocoa-Agent | Claude Sonnet 4.6 | 15.7% |
| 8 | Cocoa-Agent | Kimi-k2.5 | 11.8% |
| 9 | Cocoa-Agent | Qwen3.5-397B-A13B | 9.8% |
Figure 4: 各Agent系统在CocoaBench上的整体性能表现
几个值得关注的点：
45.1%就是目前的天花板。GPT-5.4加上专用的Codex或OpenClaw脚手架，也不到一半。对于"统一数字智能体"这个愿景来说，这个数字相当寒酸。
同模型不同脚手架差距巨大。同样用GPT-5.4，Codex拿到45.1%，Cocoa-Agent只有36.6%，差了8.5个点。同样用Claude Sonnet 4.6，OpenClaw 34.0%，Cocoa-Agent 15.7%，差距更夸张——18.3个点。脚手架的设计对性能影响可能比模型本身还大。
开源模型惨不忍睹。Kimi-k2.5（1T参数MoE，32B激活）只有11.8%，Qwen3.5-397B更只有9.8%。跟闭源顶尖模型之间的鸿沟，在Agent场景下被放大了。
成本与性能的权衡
Figure 5: 准确率-成本和准确率-时间的权衡关系
| 智能体 | 成本/任务 | 准确率 |
|---|---|---|
| Codex (GPT-5.4) | $0.75 | 45.1% |
| OpenClaw (GPT-5.4) | $1.09 | 45.1% |
| Cocoa-Agent (GPT-5.4) | $2.31 | 36.6% |
Codex站在帕累托前沿——最便宜，最快，还最准。Cocoa-Agent用同样的GPT-5.4骨干，花了3倍的钱，结果还差了8.5个点。更高的成本并不等于更好的性能，脚手架效率是决定性因素。
工具使用揭示了什么
这个分析是全文最有洞察力的部分。
Figure 6: 最频繁使用的10个工具，按总调用次数排序
Figure 7: 各模型在三大能力类别上的工具调用分配
| 模型 | Coding占比 | Vision占比 | 成功率 |
|---|---|---|---|
| GPT-5.4 | 64.0% | — | 36.6% |
| Gemini-3.1-Pro | 63.2% | — | 26.1% |
| Kimi-k2.5 | 26.4% | 51.7% | 11.8% |
| Qwen3.5-397B | 31.3% | — | 9.8% |
规律非常清楚：Coding工具使用率跟成功率强正相关。
强模型（GPT-5.4、Gemini-3.1-Pro）的策略是"信息获取+代码处理"——用浏览器搜索信息，然后切到代码环境做分析、计算、格式化。弱模型则一直泡在浏览器里，试图通过GUI操作完成所有步骤，效率低且容易出错。
编码在CocoaBench中发挥了双重作用：一是作为高效动作空间，一行代码能替代十次浏览器点击；二是作为分析工具，处理收集到的复杂信息并生成结构化输出。
这个发现对Agent设计有直接的指导意义：别让Agent在浏览器里打持久战，教会它用代码解决问题。
错误分析：54%的失败是因为"想错了"
论文对712条失败轨迹做了详细标注，按三大维度9个子类型分类：
Figure 8: 失败原因的三维分类——推理规划54%、视觉定位29%、工具执行17%
E1：推理与规划（54%）
这是最大的瓶颈。又分三个子类型：
- 错误推理（E1.1）：最常见。Agent要么目标偏移——解决了简化版的问题就以为完成了任务；要么策略根本就不对——理解了目标但用了有缺陷的方法。
- 不精确（E1.2）：大方向对，但返回值有精度偏差。浮点累积误差、数据边界搞错——比如统计引用时忘了排除附录里的。
- 格式错误（E1.3）：答案其实算对了，但输出格式不符合要求。答案埋在散文里缺少必需标签，或者多部分输出只提交了一部分。
说实话，E1.2和E1.3这两种失败让人有点窝火——推理是对的，就是收尾一步掉链子。这也说明当前Agent在"最后一公里"的严谨性上还有很大提升空间。
E2：工具与执行（17%）
- 无限循环（E2.1）：Agent卡住了，要么盲目重复相同动作，要么无休止调整低级参数没意识到整体策略失败。
- 反爬障碍（E2.2）：被网站安全机制拦截，把验证页面当成了目标内容，然后一本正经地编造答案。
- 工具结果幻觉（E2.3）：调用不存在的工具或捏造工具返回值继续执行。上下文截断也是这类问题——历史太长导致早期指令丢失。
E2.2这个反爬问题挺现实的。Agent在"野生"环境下碰到验证码、Cloudflare拦截都是常事，怎么识别和处理这些障碍，是走向真实部署必须解决的问题。
E3：视觉定位（29%）
- 视觉细节（E3.1）：看懂了大致布局但错过了细节——小目标检测遗漏、文本识别错误、细线感知偏差。
- 视觉知识（E3.2）：视觉表征形成了，但缺少把特征映射到概念的先验知识——比如颜色命名搞错、方向惯例弄反。
- 缺失视觉感知（E3.3）：Agent只通过DOM查询读取页面内容，完全忽略了只能从渲染后的像素缓冲区看到的信息（Canvas、SVG渲染结果等）。
E3.3这个发现很有意思。它说明很多Agent根本没有"看"网页——它们只是解析了HTML文本。但在真实场景中，大量关键信息只存在于渲染后的视觉输出中。
编码脚手架的意外泛化性
这个发现让我印象最深。
Codex原本是做编码的，Claude Code也是编码工具。但它们在CocoaBench这种需要视觉+搜索+编码综合能力的任务上，泛化性出奇地好：
| 对比组 | 编码脚手架 | 通用脚手架 | 差距 |
|---|---|---|---|
| GPT-5.4 | Codex 45.1% | Cocoa-Agent 36.6% | +8.5% |
| Claude Sonnet 4.6 | OpenClaw 34.0% | Cocoa-Agent 15.7% | +18.3% |
为什么编码脚手架能泛化？论文没给很深入的解释，但我觉得可以从工具使用分析中找到线索：强模型本身就会把大部分工具调用分配给编码。编码脚手架的设计逻辑天然契合了"信息获取+代码处理"这种高效策略。
反过来说，Cocoa-Agent这种"通用"脚手架，可能因为工具太多、选择空间太大，反而让模型在工具选择上犯了更多错。
这是一个值得深挖的方向：少即是多——给Agent更少但更精的工具，可能比给它一堆工具更有效。
我的判断
CocoaBench做了一件该有人做的事。在Agent评测领域，大部分基准测试都在"各自为政"——SWE-bench管代码，WebArena管网页，OSWorld管桌面。CocoaBench把它们放到了同一个起跑线上，强制Agent展示跨能力组合的真实水平。45.1%的成绩就是最好的证明——在单一能力测试中看起来已经"及格"的Agent，一旦需要综合运用，就露馅了。
几个我觉得特别有价值的设计决策：
评估函数替代LLM裁判。GAIA等基准依赖LLM打分，引入了额外的噪声和不确定性。CocoaBench每个任务配一个确定性评估函数，结果可复现、无争议。
基础设施无关性。不绑定特定运行时，任何Agent框架都能直接接入。这让评测结果的可比性大大增强。
人为构建的长时域任务。153个任务都是人工设计的，覆盖了9个领域、多种资源类型。这不是从数据集自动采样的短任务，而是真正模拟了人在数字世界中遇到的复杂工作流。
但我也有些疑虑：
153个任务的规模偏小。对于一个覆盖9个域的基准来说，平均每个域不到17个任务。统计波动可能比较大，尤其是在做细粒度分析（比如按域分解）的时候。
时间稳定性问题。论文承认任务的"搜索"部分依赖互联网资源，虽然选择了相对稳定的网站，但互联网说到底是不稳定的。半年后某些网站改版，任务就可能失效。这跟SWE-bench的代码仓库一样，面临数据集老化的挑战。
脚手架差异的混淆因素。Codex和OpenClaw的脚手架都是商业产品，内部实现细节不透明。当我们说"Codex比Cocoa-Agent高8.5个点"时，很难完全归因于脚手架设计——可能跟提示工程、工具定义方式、甚至API参数调优都有关系。Cocoa-Agent作为开源脚手架提供了公平的基线，但商业产品的内部优势很难完全复现。
不过话说回来，作为该领域的早期基准，CocoaBench的设计理念是扎实的。它提出了正确的问题——统一数字智能体到底能不能把多种能力组合起来解决真实任务？答案很清楚：目前还不行，但改进路径也很明确——推理规划、视觉定位、工具执行，这三个方向都有巨大的提升空间。
对工程实践的启发：
- 如果你正在做Agent产品，别只看单一能力测试的成绩。CocoaBench的数据告诉你，组合能力的衰减可能远超你的预期。
- 编码是统一Agent的核心引擎。与其让Agent在浏览器里慢慢操作，不如教它"搜完就写代码分析"。
- 视觉定位是个被低估的短板。如果你的Agent需要处理复杂网页，别只依赖DOM解析，确保它真的能"看见"渲染后的内容。
- 脚手架设计可能比模型选择更重要。同一模型在不同脚手架下的性能差距，比不同模型在同一脚手架下的差距还大。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我