agent-cli-mcp-">企业 Agent 工具调用演进：CLI 与 MCP 的协同与取舍

一、问题的起点：不是“转向”，而是接口暴露方式的再选择

近期业界有一种说法，认为某类协同办公平台“正在转向 CLI 模式”。这个表述其实值得推敲。更准确的理解是：这些平台并没有放弃图形界面，而是在原有 GUI 之外，额外把自身能力以命令行接口的形式暴露出来，供 Agent 调用。所谓“转向”，本质上是能力暴露渠道的扩展，而不是产品形态的更替。

要看清这件事，需要回到一个更基础的问题：Agent 到底通过什么方式使用外部能力？

答案并不神秘。无论是 CLI、HTTP 接口，还是基于标准化协议的工具调用，底层都指向同一件事——API。区别只在于：这些 API 以什么协议、什么封装、什么粒度暴露给模型。以 HTTP 协议暴露，可以接入标准化的工具调用协议；以命令行形式暴露，可以接入技能（Skill）体系。对 Agent 来说，两者都能用，差别在于接入成本、上下文开销和调度灵活性。

因此，真正值得讨论的不是“CLI 是不是终局”，而是：CLI 与标准化工具调用协议（如 MCP）各自的边界在哪里，企业 Agent 该如何取舍与组合。

二、为什么国内软件长期“接口贫瘠”

一个客观事实是：国内大量企业软件长期以 GUI 为核心交付形态，API 开放程度参差不齐。很多系统只提供少量接口，甚至只提供页面操作，没有完整的开放能力。

这在“人操作软件”的时代问题不大——人可以通过界面完成工作。但当 Agent 需要自主调用能力时，矛盾就暴露了：Agent 没有眼睛和鼠标，它需要的是结构化的、可编程的调用入口。

于是出现了一种“被倒逼补课”的现象：Agent 的落地需求，反过来推动软件补齐接口层。这不是某一家的问题，而是整个企业软件生态在从“面向人”向“面向人与 Agent 双主体”演进时的必经阶段。

在这个背景下，CLI 之所以被频繁提及，是因为它天然具备几个对 Agent 友好的特性：

• 结构清晰：命令、子命令、参数、标准输出/错误输出，边界明确；
• 易于组合：可以通过管道、脚本串联多个步骤；
• 文本友好：输出通常是文本，便于模型解析；
• 无需额外协议层：Agent 只要能执行命令，就能使用能力。

但 CLI 也有明显短板：它本质仍是“按约定调用”，缺乏统一的描述规范，模型需要预先知道命令怎么用，工具发现与自描述能力较弱。

三、MCP 的本质：工具调用，以及它的上下文代价

MCP（Model Context Protocol）这类标准化工具调用协议，本质上就是 tool call 的规范化封装。它试图解决的是：如何让模型以统一方式发现工具、理解工具、调用工具。

理想很美好，但现实有一个硬约束：上下文窗口是有限资源。

当前主流的工具调用实现，普遍需要把工具的 JSON Schema 定义注入到上下文里。问题在于：

1. Schema 本身 token 开销高。JSON 结构冗长，字段名、类型、描述、枚举值叠加起来，很容易占用大量 token。
2. 占用即挤压。上下文窗口被工具定义占掉的部分，就无法再用于对话历史、任务状态和推理过程，直接影响 Agent 的长期任务能力。
3. 工具越多，开销越大。当可用工具达到几十上百个时，仅工具定义就可能吃掉可观的上下文预算。

一个直观的对比如下：

{
  "name": "query_order",
  "description": "根据订单号查询订单详情，支持按状态过滤",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "订单唯一标识" },
      "status": { "type": "string", "enum": ["paid", "shipped", "closed"] }
    },
    "required": ["order_id"]
  }
}

这段 Schema 在自然语言里可能只需要一句话，但结构化后 token 消耗显著上升。工具数量一多，累积成本不可忽视。

四、更棘手的问题：工具的动态启停与路由缺失

除了上下文开销，MCP 还有两个常被忽视的难点。

第一，工具难以按需启停。 理想情况下，Agent 应该根据当前任务动态决定加载哪些工具、卸载哪些工具。但主流 Agent 框架中，工具集往往是静态注入的，缺乏“AI 自行决定开启关闭”的机制。结果是：不需要的工具也一直占着上下文。

第二，缺乏统一的工具路由层。 当工具种类繁多时，应该有一个路由机制，先判断“这类任务该用哪一类工具”，再加载对应工具集。但现实中，多数实现是“一次性全量暴露”，由模型自己在海量工具中挑选。这不仅浪费上下文，也增加了模型选错的概率。

第三，缓存命中率不理想。 按理想设计，工具定义这类相对稳定的内容应该高度缓存复用，甚至冷启动时就应命中缓存，避免重复计算。但实际工程中，由于工具集动态变化、Schema 拼接方式不统一等原因，缓存效果往往达不到预期。此前有技术方案针对工具调用做过压缩优化，但后续关注度并不高，这个问题至今仍缺乏系统性解法。

五、CLI 与 MCP：不是替代，而是分层协作

回到最初的问题：CLI 是企业 Agent 的终局吗？

更合理的判断是：CLI 与标准化工具调用协议不是替代关系，而是不同层次的协作关系。

维度	CLI 形态	标准化工具调用协议
能力暴露	命令 + 参数 + 文本输出	Schema 描述 + 结构化调用
上下文开销	较低，按需查阅帮助	较高，Schema 常驻注入
工具发现	较弱，依赖文档	较强，可自描述
动态启停	天然按需执行	需额外路由机制
组合能力	强，可脚本串联	中等，依赖编排层
适用场景	确定性任务、批量操作	复杂决策、多工具协同

可以看到，两者各有优势。一个务实的企业 Agent 架构，通常是这样的分层：

1. 能力层：底层系统提供 API，这是根本；
2. 封装层：将 API 封装为 CLI 或标准化工具，按场景选择；
3. 路由层：根据任务类型，动态决定加载哪些工具；
4. 执行层：Agent 调用具体工具，完成操作；
5. 缓存层：对稳定的工具定义与调用结果做缓存复用。

在这个架构中，CLI 更适合作为“底层执行入口”，标准化协议更适合作为“上层发现与编排入口”。二者结合，才能兼顾上下文效率与调度灵活性。

六、工程实践建议

如果你正在为企业构建 Agent 工具链，以下几点值得参考：

1. 按需加载，而非全量注入。 根据任务意图先做工具筛选，只把相关工具注入上下文。可以先用轻量级分类或检索，缩小候选工具集。

2. 建立工具路由层。 不要让模型在海量工具中盲选，而是先路由到工具类别，再加载具体工具。这能显著降低上下文压力。

3. 压缩工具描述。 在保证模型可理解的前提下，精简 Schema 字段与描述，去掉冗余枚举和示例。必要时用更紧凑的表示方式。

4. 提高缓存命中率。 对工具定义、常用查询结果做缓存，冷启动阶段也尽量复用。缓存键的设计要稳定，避免因微小变动导致整体失效。

5. CLI 与协议并用。 对确定性高、步骤固定的任务，优先用 CLI；对需要动态决策、多工具协同的任务，用标准化协议。不要强行统一。

6. 关注上下文预算。 把上下文当作稀缺资源来管理，工具定义、历史对话、任务状态之间要有明确的预算分配。

七、结语

“转向 CLI”这个说法，容易让人误以为是一种非此即彼的选择。但从技术本质看，CLI 和标准化工具调用协议都只是能力暴露的不同形式，底层都依赖 API。企业 Agent 的真正挑战，不在于选哪种形式，而在于：

• 如何用更低的上下文成本暴露能力；
• 如何让工具按需启停、动态路由；
• 如何让缓存真正发挥作用。

把这些工程问题解决好，CLI 也好，标准化协议也好，都会成为企业 Agent 工具箱中合适的选项。终局不是某一种形态，而是一套可组合、可调度、可缓存的工具调用体系。