OSWorld-MCP：计算机使用 agent 的 MCP 工具调用评测

OSWorld-MCP：计算机使用 agent 的 MCP 工具调用评测

一句话结论

OSWorld-MCP 把 computer-use agent 评测从“只看 GUI 点击/键盘操作”扩展为“GUI 操作 + MCP 工具调用 + 路线选择”的联合评测。它在 OSWorld 上加入 158 个经验证 MCP tools，覆盖 LibreOffice、VS Code、Chrome、VLC 与 OS utilities 等 7 类常见应用；其中 25 个是 distractor tools，250 个任务（69%）被标注为 tool-beneficial，153 个任务需要多轮 tool invocation。论文和 README 都显示：MCP 工具能提高准确率与效率，但最强模型的 Tool Invocation Rate 仍只有约 36.3%，说明瓶颈从“有没有工具”转向“何时识别工具适用性、如何在 GUI 与工具之间切换”。^[raw/articles/osworld-mcp-tool-invocation-computer-use-benchmark-2026-09-09.md]

本轮读取了 arXiv HTML、项目 README 与 GitHub 页面；GitHub API 对该 repo 的元数据读取成功，观测到 236 stars、25 forks、updated_at 2026-09-07T05:32:07Z。未本地复跑 OSWorld-MCP，因此保持 confidence: medium。

命中的知识点轴

• MCP Gateway / federation control plane：MCP server/tool 不再只是 registry 条目，而是 agent action space 的一部分，需要 tool inventory、schema、可用性、版本与调用证据。
• benchmark-evaluation：显式测量 tool-beneficial task、Tool Invocation Rate、GUI/tool route choice、distractor robustness、step budget 与成功率。
• harness-runtime：评测 harness 必须同时暴露 GUI action 与 MCP call，并记录 agent 每步选择的是界面操作还是工具调用。
• context management：158 个 tools 和 25 个 distractors 会改变 agent 的上下文/注意力负担，工具说明本身需要检索、筛选和压缩。
• sandbox-security：不是安全论文，但 distractor tools 与 MCP tool surface 提醒 benchmark 必须防止工具误用、越权和 route shortcut。

为什么对用户重要

用户关心 Hermes、coding agent、computer-use agent 和 MCP gateway 的真实可用性。OSWorld-MCP 的提醒是：把工具接进来并不等于 agent 会用；MCP Gateway 的下一层不是“更多 server”，而是 tool-route intelligence：当前任务是否适合调用工具、哪个工具真正有用、什么时候 GUI 更稳、工具调用失败后是否回退、调用痕迹是否能进入报告 receipt。

对 llm-wiki 雷达也有价值：以后看到 MCP/Gateway 项目，如果只有工具聚合，不够；如果提供“哪些任务因工具受益、agent 是否能识别、distractor 下是否稳定、工具调用如何计分”的证据，优先级应上调。

机制 / 一阶原理

1. Tool invocation 是决策能力，不是独立 API 能力

传统 tool-use benchmark 往往把工具调用当成结构化函数题；GUI benchmark 又把 agent 限制在鼠标键盘。OSWorld-MCP 的核心机制是在同一任务中同时允许 GUI 与 MCP tools，让模型每一步都要决定：继续看屏幕、点击界面，还是调用某个工具。这更接近真实 desktop/coding agent：工具不是答案，而是可选 action route。

2. 公平评测要标注 tool-beneficial task 与 distractor

如果任务本来就不需要工具，MCP tool surface 只会制造噪音；如果工具对任务有用但 agent 不知道，失败原因是 route selection。OSWorld-MCP 因此统计 250 个 tool-beneficial tasks，并加入 25 个 distractors 来测 agent 是否会被“看似可用但无关”的工具带偏。这个设计比单纯比较“开/关工具”更可解释。

3. MCP 工具会降低操作步数，但也扩大上下文和安全面

论文报告 MCP tools 一般提高成功率，例如 OpenAI o3 在 15-step 设置下从 8.3% 到 20.4%，Claude 4 Sonnet 在 50-step 设置下从 40.1% 到 43.3%；但最高 Tool Invocation Rate 仍低，说明许多模型没有充分利用工具。对 Context-Engineering 来说，158 个 tool schemas 不能无脑全部塞给模型；对 MCP-Gateway-Runtime 来说，gateway 需要记录 tool selection、call outcome、fallback 和 misuse evidence。

和已有 wiki 概念的关系

• 对 MCP-Gateway-Runtime：把 MCP 从“可治理资产”推进到“评测中的 action route”；gateway receipt 应增加 tool_beneficial_task、selected_tool、route_reason、fallback_path。
• 对 Agent-Benchmarks：补充 Tool Invocation Rate、distractor robustness、GUI/tool hybrid scoring，而不是只看 final success。
• 对 Harness-Engineering：harness 需要同时记录 GUI action trace、MCP JSON-RPC trace、step budget 和 environment state。
• 对 Context-Engineering：工具列表是高成本上下文，需要 retrieval/ranking，不宜一口气暴露全部工具说明。

对 Hermes / llm-wiki 的可执行启发

1. 给 MCP/Gateway 候选增加 tool-route receipt。 记录任务是否 tool-beneficial、暴露了哪些工具、agent 选择了哪个 route、是否有 distractor、失败后是否 GUI/tool fallback。
2. Hermes 工具面应按任务动态裁剪。 不要把所有 MCP tool schema 长期放进 prompt；用 registry + semantic selection + risk tier 生成最小工具包。
3. 评测 coding/computer-use agent 时同时算能力和效率。 成功率之外记录 step count、tool-call count、GUI-action count、重复调用和 context token。
4. 把工具误用当成失败类型。 若 agent 被 distractor tool 带偏，不能记成普通“模型答错”，应归类为 route-selection failure。

失败模式 / 边界条件

• 工具由 code generation + manual validation 得到，仍可能继承 OSWorld 任务分布偏差；真实企业工具更碎片化、权限更复杂。
• 高 TIR 不一定等于高质量：agent 可能为了调用而调用，增加风险和成本。
• MCP tools 带来的提升不应泛化到所有 computer-use 场景；只有 tool-beneficial task 才应比较。
• 本轮未复跑环境，论文数字只作为原文报告，不是本地验证结果。

候选评分

深度判断

晋升为正式 source page，因为它不是“又一个 OSWorld leaderboard”，而是把 MCP tool surface 作为 computer-use agent 的可测变量：工具是否存在、何时适用、agent 是否能识别、GUI/tool 如何切换、distractor 如何干扰、调用是否带来效率收益。这正好补上 Hermes/MCP Gateway 从“工具注册”到“工具路线治理”的缺口。

写入记录

• 2026-09-09 09:01 CST：新增 OSWorld-MCP 来源页，沉淀 MCP tool invocation、GUI/tool route choice、Tool Invocation Rate、distractor robustness 与 Hermes tool-route receipt 启发。