过去几个月，我在团队里做了一件看似“倒退”的事——把一个智能体平台从MCP接入改成了CLI+API。
过程里遇到的坑多到可以写一本“工程悲喜剧”，但最让我确定方向的，是那种从系统边界、成本结构到团队协作方式的通盘清晰感：我们并不需要更多抽象层，我们需要的是能让人和机器一起把活干完的工具。
行业里也在同一条河流上。
Perplexity的联合创始人兼CTO在内部沟通中表示他们正转向API与CLI
YC的Garry Tan直言“MCP sucks”。
再看OpenClaw，压根没上MCP。不是态度问题，更像一笔精算后的选择。
为什么一套“更高抽象”的协议，反而拖了智能体的后腿
在真实项目里，MCP的硬伤不止一处，关键在于它把“工具目录”提前塞进了模型上下文，导致成本、可靠性和治理三重折损。
- 上下文预算被吃空。MCP的每个工具都带着名称、描述、参数Schema，连接10个服务、每个服务5个工具并不夸张。以我们团队的测算：单个工具Schema常在150–400个token区间，50个工具就可能吞掉8k–12k token。模型还没思考，预算先被结构化描述吃掉，带来直接的成本上浮和延迟抖动，更糟的是让模型在“工具噪声”里分心。
- 工程端经常掉链子。MCP client偶发冷启动失败、多个工具重复认证、权限模型只有“全开/全关”。这些在小demo里还好，放到多租户、合规压测的生产环境就变成事故隐患。权限收敛、审计闭环、灾备演练，个个都是协议层没设计好的“债”。
- 过早绑定带来的系统脆弱性。把完整工具集注入上下文是一种过早绑定：任务还未明确，选项已经全部展开。理想做法是“按需检索、延迟绑定”，把工具说明作为知识库条目，当模型判断需要时再取用一小段，而不是把全目录塞进对话。
把这些问题叠在一起看，就会得出一个朴素结论：这不是某个实现粗糙，而是协议假设与大模型的推理机制并不匹配。
为什么CLI在智能体时代“越用越顺手”
大模型已经在海量开源仓库、技术问答和文档中见过命令行的世界。这意味着我们拿起CLI，几乎在与模型的“母语”对话。更重要的是，它继承了几十年工具链演化的基本美德。
- 可组合，直接站在巨人肩膀上。管道、重定向、
jq、grep……把复杂任务拆成小步拼起来，既贴合人类工程师的思维，也贴合模型的分步推理。很多CLI天然支持--json输出，机器可读、日志可复现。 - 可调试，复现实验成本低。智能体干了件“怪事”？直接用同一条命令重放，stdout/stderr摆在那，定位问题像查一次流水账，不需要翻一堆冗长的JSON传输记录。
- 认证和权限体系现成可用。
aws、gh、kubectl这些工具背后的认证与RBAC成熟稳健，组织的SSO、短期凭据、审计策略全能复用。人和Agent共用一套门禁，更好管、更好查。
这不是怀旧，而是工程上“少一层即是美”。当API和CLI覆盖了80%+的链路，临时再叠一层协议，收益很难覆盖成本。
落地经验：让Agent安全、可控地使用CLI
不用MCP，不代表把安全和治理交给运气。这套组合，才是我们最终跑通生产所依赖的。
- 环境隔离：容器或微VM（如Firecracker）沙箱；只读根文件系统；网络egress白名单；磁盘与API密钥短期化（TTL）；命名空间级别的资源限额。
- 命令白名单与参数模板：限定可用命令集合；只允许
--json或结构化输出；用参数schema在执行层做校验，而不是把schema塞给模型。 - “按需检索”的工具索引：构建工具手册的知识库，把每条命令的用法切成小片段。模型决定要用某命令时，再检索出极短提示注入上下文，避免整库注入。
- 可观测与可回放：记录命令、参数、stdout/stderr、退出码、起止时间、关联工单/会话ID；支持“一键重放”。当出现误操作时，人类工程师可以即时复盘。
- 人机共治：对高风险命令配置“二次确认”或人审阈值；给Agent设定时间/费用预算，当超过边界时自动求助；偏离预期的diff必须解释原因。
这套做法的价值在实战中很直观：我们把上下文从动辄上万token压到几百，平均延迟下降明显，原因定位和回放的效率也提升一截。
是否“一刀切”否定MCP？也未必
作为产品经理，我更愿意给出一个“选择题框架”，而不是口号。
- 跨组织、跨平台的“远程托管能力”：当工具必须由第三方托管，且你需要稳定、版本化的结构化契约时，MCP式协议仍有价值，前提是上下文开销可控且权限模型细粒度。
- 强合规与审计场景：有些行业必须以标准化协议输出可核验日志，这类场景里，协议化“工具调用”可以简化认证与追责链路。
- 弱CLI生态或多语言互通：当目标平台缺乏成熟CLI，或必须在多语言运行时之间做严密隔离时，统一协议可降低集成碎片化。
但这些是“特定情境下的局部最优”，并不能反推“统一用MCP更好”。
决策三问：你到底该选哪条路
用这三个问题校准方向，团队会更少走弯路：
- 问题域是否已有成熟的CLI与API可复用？如果答案是“是”，那新协议的边际收益很可能不足以覆盖复杂度。
- 你的安全边界能否由容器/微VM/RBAC承担？如果可以，优先把预算花在隔离与审计，而不是抽象层。
- 你是否需要“强结构化”的输入输出？如果只有少量关键步骤需要结构化，采用“CLI —> JSON 输出 —> 解析”往往更轻。
趋势判断：抽象会留下，但形态会变
我并不认为“协议化工具调用”会永远消失，更可能的演化是：工具目录不再常驻上下文，而是作为知识库按需检索；权限与审计从协议里抽离，交给成熟的企业身份体系；执行层聚焦在沙箱、幂等和回放。换句话说，CLI与API做执行，检索与策略做治理，这套分工更贴合智能体的工作方式。
写在最后
回到开头的那个疑问：OpenClaw为什么不支持MCP？我的判断是，它并不需要。Agent可以直接调用CLI，借助Skills获得能力，用现成API连接外部世界；再叠一层协议，多数时候只是多了一层摩擦。
最好的工具，应该同样对人和机器友好。CLI这套“老兵”，在可组合、可调试、可治理上早已打磨到位。MCP试图构建更好的抽象层，但在当下，我们已经有一个足够好的了。把复杂留给基础设施，把注意力留给问题本身，这才是让智能体走进生产的靠谱路径。
也推荐一篇业内讨论的延伸阅读：MCP is dead. Long live the CLI。有不同看法也欢迎留言，我们一起把“该省的复杂”省掉，把“该花的精力”花在刀刃上。