你的编程智能体在读提示词之前就烧掉 26,000 个 token：MCP 与 CLI 对比

HN AI Best Practices 2026-08-26T23:59:27.211476

AI 编程的采用率已经达到历史最高点。Keyhole Software 的 2026 年行业盘点显示，92% 的美国开发者现在每天都在使用 AI 编程工具，但只有 29% 的人信任这些工具生成的代码。GitHub 则表示，其平台上 46% 的提交代码是由 AI 生成的。不管你喜欢与否，数据不会说谎：上线的代码中，由模型写出的占比越来越大——而模型能用来思考的空间是有限的。

这意味着一件事：模型的上下文窗口本身成了一种构建资源，而且是这份预算中最大的一项开销；至于工具层，往往是搭好一次就再也没人回头看过。

因此，今天比以往任何时候都更需要找到既经济又高效的构建工具，于是那个老生常谈（好吧，可能才争了一年半）的问题又冒了出来：MCP 还是 CLI？

MCP vs. CLI：引发争论的那个数字

把一个标准的 GitHub MCP 服务器接到编程智能体上，它会暴露约 90 个工具，每个都带有完整的输入/输出结构定义（schema）。Manveer Chawla——Confluence 和 Facebook 的工程师出身，也是 Zenith AI 的联合创始人——估算初始化成本约为 55,000 个 token，按 Sonnet 的定价算「每次会话约 0.16 美元」；如果每天跑 10,000 个自动化会话，那就是「每天 1,600 美元」，而这一切都发生在智能体解决任何问题之前。

Perplexity 的 CTO Denis Yarats 在实际使用中遇到的状况更糟。Tyk.io 的记录显示，MCP 工具描述「在智能体执行任何实际工作之前，就消耗了可用上下文窗口的 72%」。同一页面还引用了 Scalekit 的基准测试：MCP 每次调用消耗的 token 是 CLI 方案的 4 到 32 倍；该文还指出，如果有「30 个工具，光是读描述就要烧掉 15,000 到 20,000 个 token，而智能体此时还没读到任何一条用户消息。」

CircleCI 对这件事的总结是我见过最精炼的一句话：「花在 MCP schema 上的每个 token，都是助手无法用来推理实际代码的 token。」他们还引用了一个浏览器自动化的基准测试：CLI 方案「以 33% 的 token 效率优势完成任务，任务完成得分 77 比 60」。在多步骤调试场景中差距最大——上下文预算在任务进行到一半时就耗尽了。

相比之下，CLI 这边就难堪多了。Chawla 给出的实例是：智能体先运行 gh issue create --help，拿到约 200 token 的精简帮助输出，然后真正执行命令。“总成本不到 500 token，几乎可以忽略不计。”模型之所以知道 gh 这个命令，是因为它已经在训练数据中反复见过。

那么文章标题里的 26,000 又是从哪来的？当我按照 Chawla 的做法做同样的对比时，我把 GitHub MCP 服务器接入编码智能体并启用了全部工具集，结果在智能体读到我的提示词之前，schema 转储就已经超过了 26,000 token（完整方法和数据见下方基准测试表）。和 Chawla 测得的 55,000 token 相比，这些服务器显然已经精简过了，但对一个还没干任何活的智能体来说，这仍是一笔惊人的开销。

如果你只读到这里，结论似乎显而易见……但那是错的。

让步：一个残酷的事实

残酷的事实是：26,000 token 这个数字指向的是一个设计糟糕的服务器，而不是协议本身。运行着 120 多个工具的 MCP 服务器实践者反馈说，分层式服务器能保持初始化的轻量——只需在前端暴露一个简短的概览，再让模型按需请求工具细节。CLI 集成之所以便宜，靠的也正是这种按需模式。

Anthropic 和 Cloudflare 这样的机构已经开始着手构建解决方案。Anthropic 将自己的代码执行重写方案与朴素方案对比，把 token 数从 150,000 降到 2,000，减少了 98.7%。Cloudflare 的 Code Mode 则号称达到 99.9%，用大约 1,000 token 表达了拥有 2,500 个端点的 API。这些数字固然亮眼，但都来自构建者自己，难免让人怀疑其中存在偏向，还需要额外的基准测试来证实。

不管怎样，正如 Chawla 指出的，“一个 55,000 token 的 schema 转储今天要花 0.16 美元，18 个月后可能只需 0.01 美元”，所以 token 膨胀这个论点是有保质期的。

肯尼斯·辛德（Kenneth Sinder）参与构建了 Notion 托管的 MCP 服务器，但他反驳得更不留情面——尽管这并不符合他自己的利益。「好的 CLI 就是多绕几步的 MCP。要让命令行在 agent 手里用得好，你最终得手工重造 MCP 免费送给你的大部分东西：渐进式披露（用名词/动词层级代替一堵扁平的参数墙，比如 Stripe CLI）、一致的认证方式、省 token 的输入输出，以及一层 skills 把所有东西串起来、告诉模型怎么驱动它。」

他还写下了关于「这件事为什么重要」的最精辟的一句话，哪怕在百万 token 的上下文窗口下依然成立：> 低信号上下文会稀释输出质量、拖慢推理、增加成本，还会压缩你留给模型的最佳输出空间——而最佳输出往往出现在前 ~100k token 左右。

真正的轴不是 MCP vs. CLI

尽管争论不休，真正的轴不是 MCP 与 CLI 之争，而是急切式与惰性式之争。

所有认真讨论这一现象的文章，最后都会从不同路径汇聚到同一个结论：协议只是拼图的一块，其重要性不如一个精心设计的架构。

一个臃肿的 MCP 服务器和一个 --help 树杂乱无章的 CLI，会以完全相同的方式失败。一个精简的 MCP 服务器和一个配了上好 skill 文件的 CLI，也会以完全相同的方式成功。真正起作用的不是协议本身。

这并不是说协议永远无关紧要：有两个领域里，MCP 与 CLI 的对比才是真正的问题所在——可组合性和凭证托管。

可组合性

在可组合性上，MCP 比 CLI 要弱。Unix shell 几十年来都有标准的工具链式调用方式：一个命令的输出成为下一个命令的输入。MCP 没有同等成熟、通用的替代方案，所以模型往往得自己去编排每个工具调用、在它们之间转换输出，这增加了更多出错的可能。CLI 管道还受益于几十年的约定和海量的训练数据，而 MCP 的链式调用模式仍然新颖且不统一。Chawla 认为，在这一点被验证之前，试图靠这种模式来证明工具调用和输出路由，就像「押注在一个 v0.1 的管道框架上，而不是 v50 的框架上。」

凭据托管

MCP 同样解决不了提示注入（prompt injection）问题，恶意内容依然能操纵模型。但它确实改变了凭据暴露的方式：正如 Sinder 所说，“模型手里根本没有密钥，自然也就泄露不了密钥。”

给几十个智能体直接开 CLI 权限，往往意味着每个会话都要分发一份凭据；而 MCP 可以把凭据收拢在一个可控、可审计的界面后面。不过这样做的代价通常是覆盖范围：MCP 服务器往往只是现有 API 的不完整包装，智能体可能会碰到服务器根本不支持的操作。

在实践中，CLI 在开发者快速灵活的内循环（inner loop）中表现最强——借用 CircleCI 的说法；而 MCP 在外循环（outer loop）里更有用，这时智能体要跨越系统边界，访问权限也需要受到管控。

Blocks.ai 对 MCP 与 CLI 之争的回答

在我写这篇文章时，Blocks.ai 这款产品问世才大约六周。上面争论到的所有层面它都涵盖了——这也是我在这里能说出点有用东西的唯一原因：我能在同一个任务上，拿它们彼此对比实测。

CLI：@blocks-network/cli，用于构建和发布你自己的智能体，包含 blocks init、blocks register、blocks run、blocks publish 等命令。
MCP 服务器：@blocks-network/mcp-server，用于在编辑器里调用已经存在的智能体。它提供 15 个工具，只需一行命令就能装进 Claude Code 或 Cursor。
技能文件：config.blocks.ai/SKILL.md，用来教你的编码智能体理解这两者背后的约定。

Blocks.ai 的 MCP 服务器工具与具体智能体无关。调用时你按名字指定目标智能体，配置阶段并不记录它们。这意味着 Blocks MCP 非常轻量：它只暴露一组固定的小工具集（15 个），不管智能体目录里是 100 个还是 10 万个智能体，都保持这样。相比之下，Chawla 的 Jira 示例中，原始服务器暴露了“400 多个端点”，用技能包装后的版本大约要消耗 300 个 token；而 Blocks MCP 服务器在结构上就属于节省型，原因出在设计，而不是协议。

对 Blocks.ai 工具链的基准测试

我测量了在代理执行任何操作之前，每种接入方式在上下文中占用的成本。以下每个数字都来自 Anthropic 自家的 count_tokens 端点（基于 claude-sonnet-4）：通过 stdio 连接每个服务器，列出其工具，然后将附带工具与不带工具的相同请求做差分。结果是确定性的——我跑了两遍，数字完全一致，所以你可以在大约一分钟内自己复现整列数据。

Path                                               Tools   Schema tokens at init   Tokens per tool
Blocks CLI, no skill file                              -                       0                 -
Filesystem MCP server (lean third-party control)      14                   2,614               187
Blocks MCP server                                     15                   3,185               212
Blocks SKILL.md                                        -                  12,755                 -
GitHub MCP server, default toolsets                   44                  14,243               324
GitHub MCP server, all toolsets enabled               85                  26,644               313

结果说明 Blocks CLI 最便宜，因为使用 CLI 时不会向模型上下文添加任何内容。技能文件（Skills）会为引导增加少量开销，而设计良好的 MCP 服务器可以保持相对精简，但 MCP 仍然比 CLI 更贵，因为工具发现和调用需要额外的上下文和又一次往返。

我的实际建议

同时使用 MCP 和 CLI，按具体集成场景而不是按系统来选择，以保持精简高效。对 Blocks.ai 代理来说，分工很明确：

构建和发布代理：用 CLI。 开发循环紧凑，在本地机器上运行，凭证也已经在你的环境里。
调用别人的代理：用 MCP 服务器。 你预先不知道那些代理的名字，而且无论目录有多大，那 15 个通用工具的成本都一样。

教你的编码 agent：技能文件。正如一篇分析文章所说，“知识层和行动层是两个不同的问题”——那些会在生产环境坑你的命名规则（例如全网唯一名称）属于知识，而不是行动。

选哪种工具传输方式，本来二十分钟就能拍板，却被大家搞得像个人信仰一样。说到底，这只取决于单个 agent 的路线选择，远不如架在两者之上的治理层重要。

Try Blocks

Blocks.ai 给 agent 一个公共身份：一个别人可以发现、调用、并（可选）付费的名字。注册免费，默认不公开，之后你可以自己决定是否挂出来，或者按任务计费。

用 CLI 几分钟就能构建并发布自己的 agent：

npx @blocks-network/cli init my_agent
cd my_agent && npx @blocks-network/cli login --write-env
npx @blocks-network/cli register

blocks register 会把 agent 以私有、免费的方式放到网络上，这是最稳妥的第一步。blocks publish 是另一个独立的命令，负责将 agent 公开或设置价格。所以，在你明确表态之前，任何东西都不会上线，也不会开始计费。

想调用已经存在的 agent，把 @blocks-network/mcp-server 装进 Claude Code 或 Cursor 即可。十五个工具，一行配置。无论目录有多大，工具数量始终保持在十五个。

从这里开始：