CLI 与 MCP：为什么懒加载工具定义能显著降低 Token 成本
当你把 Agent 接到越来越多外部工具时，成本通常不是先爆在推理，而是爆在“工具说明书”。
这篇文章最有价值的点，不是 MCP 与 CLI 谁“先进”，而是它把一个常被忽略的问题量化了：工具定义何时被注入上下文，直接决定了长期运行成本。
作者给出的实测模型是：6 个服务、每个服务 14 个工具（共 84 个工具）。
- MCP 方案：会在会话开始时把大量 JSON Schema 直接注入上下文
- CLI 方案：会话开始只注入轻量级“工具目录”，具体参数在真正调用前按需发现
在这个设定下，作者统计的总体结果是：CLI 方案大约可减少 94% 的 token 消耗。
本质是“预加载”与“按需加载”的差异。
MCP 的优势是规范化与可组合性：工具定义、参数约束、调用方式都统一。但代价是，如果把完整 Schema 一次性塞进上下文，初始 token 就会很重。
优点：
- 调用阶段开销低
- 参数约束清晰，模型更不容易乱传参
代价：
- 会话启动成本高
- 工具越多，固定成本越线性增长
CLI 方案把“工具存在性”与“工具细节”拆开：
- 先告诉模型有哪些命令可用
- 真正要用时再通过
--help或子命令文档拉取细节
优点：
- 启动成本极低
- 对大量“可能用但大概率不用”的工具更友好
代价：
- 首次发现命令有额外开销
- 如果工具切换频繁，发现成本会累计
文章还提到 Anthropic 的 Tool Search：它同样采用“先索引、后拉取”思路，能显著减少初始注入成本，但按需拉取时仍会引入额外 token。
这说明一件事：方向已经明确，行业正在从“全量注入”转向“检索 + 按需展开”。差别主要在于展开粒度与生态兼容性。
如果你已经有一批 MCP Server，不必做二选一，推荐按下面的增量路径推进。
把以下指标单独打点，否则很难判断优化是否有效：
- 会话启动 token
- 每次工具调用前后 token
- 每个工具的调用频次与复用率
把工具分成三类：
- 高频核心工具：可保留预加载
- 中频工具：用摘要定义 + 按需展开
- 低频长尾工具：仅保留名称与入口，调用前再发现
不要一次拉全量 schema，优先拉：
- 命令名与一句话描述
- 必填参数
- 常见可选参数
其余复杂参数（例如深层嵌套结构）只在模型明确需要时再展开。
同一会话内对同一工具的帮助文档做缓存，避免重复消耗。跨会话也可以做短期缓存，但要考虑工具版本变化后的失效策略。
如果你的场景具备以下特征，收益可能没有想象中大：
- 可用工具数量很少
- 会话很短，几轮就结束
- 对调用成功率的要求远高于成本敏感度
这种情况下，保持简单、稳定、可维护，通常优先级更高。
不要把问题变成“CLI vs MCP”的站队题。真正要优化的是：在不牺牲可靠性的前提下，最小化工具信息进入上下文的体积与时机。
从工程实践看，谁能把“工具发现、展开、缓存、失效”这一层做扎实，谁就能在成本和效果之间拿到更好的平衡。