一、争论从哪来

过去几周，X 上的开发者圈子分成了几个阵营：

• API/CLI 派：官方 API 才是真理之源，厂商维护得好，CLI 易于安装、检查、调试。让每家公司再维护一个 MCP server 是重复劳动，而且现在很多 MCP server 又臃肿又难用。
• MCP 派：当 API 表面是带类型、带命名、自描述的，Agent 表现明显更好——尤其是模型没有任何训练先验的内部企业 API。MCP 还把认证标准化了，不用每个 Agent 都去搞自己的凭据管道。
• Harness 派：MCP 难用其实是 harness（执行环境）的问题，不是 MCP 本身的问题。

Smithery 指出，这场争论的根本问题在于把三个本应分开讨论的问题混为一谈：

1. Agent 如何发现和使用能力（AX，Agent Experience）
2. 安装和使用 MCP/CLI 的用户体验（UX）
3. 认证、审批、治理如何运作（标准化）

大多数人只在其中一个维度上比较，却宣称在所有维度上都赢了。

为了把问题收敛，Smithery 把核心命题缩减成一句话：如果固定后端和任务，哪种接口形态今天能给 Agent 最大的成功概率？

二、实验是怎么设计的

为了不只是"凭感觉"，Smithery 设计了一组对照实验，固定后端服务和任务，只改变 Agent 看到的接口形态，测量成功率和 token 效率。

规模：756 次独立运行，跨 8 个实验族，每次运行都在干净的容器里，且只能访问一个 API。

模型与 harness：

• Claude Haiku 4.5（Claude Code）
• GPT 5.4（Codex CLI，默认 thinking level）
• Claude Sonnet 4.6（用于 826 工具的大目录实验，默认开启 MCP tool search）

测试 API，故意覆盖不同的"模型熟悉度"：

• GitHub REST：两个变体，24 个精选操作和完整的 826 工具 MCP 目录。流行 API，训练数据中代表性强。
• Linear GraphQL：真实只读工作区，2026 年 3 月 15 日重跑过。流行，但 GraphQL 引入查询构造复杂性。
• Singapore Bus REST：8 个操作，故意选了一个区域性、训练数据中罕见的 API。

任务结构：所有任务都需要至少两次依赖性 API 调用——比如先搜索某个仓库，提取 ID，再用这个 ID 获取 README。这种"链式调用"才能真正考验 Agent 的上下文管理能力。

衡量标准：

• 成功率：Agent 是否完成了完整的、带正确参数的工具调用链，且数据在步骤间正确传递
• 效率：成功运行的总计费 token 成本

三、关键数据

实验 1：盲调 API（不给文档不给 schema）

只给 Agent 一个 curl 和本地认证端点，让它猜 API 的形状。

GitHub 在训练数据中代表性强，靠先验就能撑住；Linear 因 GraphQL 查询形状不熟悉而崩盘；Singapore Bus 则是因为训练数据中很少出现。

结论：模型先验有用，但对训练里没怎么见过的东西不可靠。

实验 2：提供 API Spec

给 Agent OpenAPI/GraphQL introspection spec：

结论：Spec 买的是正确性，但模型读文档本身也要花 token。

实验 3：CLI 设计优化（826 工具 GitHub 全目录）

测试三种 CLI 布局：

光有树状层次但没描述，跟扁平列表没区别——模型在分支间瞎转悠。加上描述和别名后，成功率从 46% 飙到 79%。

再加上 search 原语：

结论：描述比层次结构更重要。规模大时，描述和搜索一起用比单纯的结构更关键。

实验 4：CLI vs 原生 MCP 正面对决

这是文章的核心数据。在 GitHub、Linear、Singapore Bus 三个小套件上：

CLI 成功的运行用了 2.9 倍的 token、2.4 倍的时间。

成本差距并非来自 payload 大小，而是来自交互开销：CLI 上 Agent 通常要先 list 或 describe 浏览，解析 JSON，再把参数序列化回 shell，最后才能调用操作。原生 MCP 把这些折叠成更少的结构化交互。

在 826 工具的全目录上，差距进一步拉大：

值得一提：在纯 token 成本上，Codex 的 CLI+search 反而比原生 MCP 便宜（64,916 vs 94,823）。原生工具集成不是在每个指标、每个模型上都赢，但它在任务成功率上赢。

实验 5：GraphQL 的反直觉结果

GraphQL 理论上让你精确指定需要的字段、一次请求解析嵌套关系——理论上更省上下文。

GraphQL 仅 16.7% 成功率，token 消耗是 MCP 的 5 倍。模型能发现根类型和字段，但合成不出 Linear 特有的查询形状（搜索是 searchIssues 不是 search，issue 查询用 issue(id: ...)，等等）。

结论：表达力不等于 Agent 友好。一个能做任何事的通用 GraphQL 工具，不如十个各做一件事的具体工具。Agent 的瓶颈在选对操作和参数，不在查询表达力。

四、结论与判断

为什么 MCP vs CLI 是错误的战场

它们解决的是不同问题：

• 本地工具（git、docker、ffmpeg）：CLI 是天然界面，MCP 没必要替代。
• 远程服务、大型内部 API、安全敏感工作流：类型化的 Agent 契约胜过让模型啃原始 shell 语法。

如果你在用 Agent：本地工具用 CLI，远程服务/内部 API/安全敏感工作流用 MCP。 如果你在为 Agent 设计：先做好 API，然后在上面套一层简单的 MCP 适配器，剩下的交给 harness。

MCP 的价值是社会性大于技术性

MCP 最值钱的属性是生态协调。协议对 harness 应该接受什么、远程集成的认证如何工作有立场。标准强制收敛，这是"一堆好想法"做不到的。

最清晰的例子是认证。MCP 给 HTTP 传输方式提供了围绕 OAuth 的标准化契约，包括对 CIMD（Client ID Metadata Documents）的支持——一种客户端无需预注册就能证明身份的方式。安全、访问控制、审计可追溯——组织变大后这些都是刚需。

你可以用原始 API + Skills + 提示模型读文档 + CLI 自带认证层来 DIY，但这不可移植。如果你为 CLI 实现了完整的 CIMD，你已经重新发明了 MCP 认证层的大部分。

Harness 应该拥有 Context Engineering

2025 年初，MCP 作者们手工调优 server 来弥补弱模型——自定义工具、精雕输出、堆砌描述。这些技巧大多被模型和 harness 的进步碾平了。

如果我们假设 harness 厂商（Claude 由 Anthropic、Codex 由 OpenAI）最了解如何把 MCP 工具暴露给自己的模型，那么用它们的原生界面就是合理默认。

Harness 应该拥有 context engineering，因为它最了解自己的模型。Server 的工作是暴露带类型 schema 和有用描述的清晰操作。

最近流行的"Agent-first CLI"有重蹈覆辙的风险——一旦你开始为当前模型行为定制 CLI、自定义 shell 搜索、调优输出格式，你就在过拟合今天的弱点。苦涩的教训在两边都一样：不要过度优化界面。

Skills、Codemode 各自的位置

• Skills 是用户定制行为：把可复用指令和领域专属行为注入模型或子 Agent。私有 = Skill，公共 = MCP。 团队内部定制的工作流用 Skill，由厂商维护、对所有人通用的能力用 MCP。
• Codemode 介于 harness 和 server 之间：在工具调用周围加一层可编程层，通常通过沙箱里跑代码并通过运行时分发工具。当 harness 没有原生代码执行时有用，但一旦 harness 已经有 bash 或代码执行加自己的上下文管理循环，单独的 executor 就不一定需要。

真正的基础是高质量 API

读到这里你可能想动手做更好的 MCP，但真正的关键不是 MCP 还是 CLI，而是底层 API 本身要够好。

这难，因为做好 API 涉及决定你卖的是什么产品表面、什么是正确抽象、如何让人和机器都觉得直观。Stripe 把"API 即产品"做成了一家公司的根基。设计工作做到位，MCP 层就只是包装。

协议最好的归宿不是被聚焦，而是变得无聊、被遗忘——就像 HTTP 在背景里默默运行整个互联网。

五、为什么我们仍然需要 MCP

因为原始 API 和 shell 命令留下太多未指定的东西。Smithery 的基准展示了一个清晰的阶梯：可发现的 #API 文档、schema 和搜索能改善 CLI 表现，但最终是 #MCP 让 #harness 能提供最优化的 Agent 体验。

MCP 远非完美。用户体验比 #CLI 粗糙，协议对简单用例显得臃肿。这些批评都成立，但标准胜出不是因为优雅而是因为被采纳。Dvorak 键盘大概比 QWERTY 高效，但赢不了。

MCP 有价值，不是因为它有魔法，而是因为它把负担从模型循环里移出来，放进 harness 可以围绕它优化的、可复用的契约里。它把认证标准化，让组织成长时能跟着扩展。

Smithery 的完整代码和数据见：smithery-ai/mcp-vs-cli-bench。所有数据来自 2026 年 3 月 15-16 日的基准运行。 #Smithery