MCP vs CLIAI Agent 的协议之辩2026年2月底到3月AI 开发者社区爆发了一场关于 AI Agent 工具调用方式的激烈争论。一方说MCP 已死CLI 万岁另一方说MCP 没死我们只是太早了。而飞书、钉钉、企业微信在同一周内开源各自的 CLI用实际行动给出了第三种答案。一、争论的起点一句MCP 是个错误2026年1月OpenClaw 创始人 Peter Steinberger 在 X 上发了一条推文mcp were a mistake. bash is better.这条推文在 AI 开发者社区埋下了一颗种子。一个月后Eric Holmes 发布博文《MCP is dead. Long live the CLI》从六个维度系统论证 CLI 优于 MCP引发了广泛讨论。随后 Jannik Reinhard 发布实测数据Matt Hall 发布反驳文章中文社区的掘金、头条上也出现了大量分析——这场争论在钉钉、飞书开源 CLI 时达到高潮。二、唱衰 MCP 的三个核心论点2.1 Token 吞噬上下文效率的致命差距Jannik Reinhard 用实测数据揭示了 MCP 最尖锐的问题——上下文吞噬。一个 GitHub MCP Server 需要将 93 个工具的完整 Schema 注入模型上下文总计约55,000 tokens——还没问任何问题上下文就没了将近一半。多个 MCP Server 叠加轻松突破15 万 tokens。他在 Intune 设备合规检查任务上做了并行对比指标MCP 方案CLI 方案差距Schema 注入~28,000 tokens0 tokens—推理 调用~3,200 tokens~800 tokens4x50 台设备处理总消耗~145,000 tokens~4,150 tokens35 倍CLI 方案的 Agent 有 95% 的上下文窗口留给实际推理而 MCP 方案的 Agent 大量精力花在解析 Schema 上。为什么 CLI 更省因为 AI 模型在数十亿行终端交互上训练过——Stack Overflow 答案、GitHub 仓库、man page。当你说gh pr view 123模型天然理解。而 MCP Schema 是模型运行时第一次见到的自定义抽象需要额外的认知开销去理解。社区基准测试也证实了这一点CLI 的任务完成率高出 MCP 约 28%Token 效率得分高出 33%。2.2 调试地狱看不见的工具Eric Holmes 指出了 MCP 的可调试性问题CLI 对人类可见而 MCP 工具只存在于 LLM 对话内部。# CLI出问题了我自己跑一遍就知道 $ gh pr view 123 # 看到和 Agent 一样的输出 # MCP出问题了你得翻 JSON 传输日志 # 工具调用隐藏在 LLM 对话流里 # 没有 自己跑一遍 的选项这个痛点很真实。MCP 把工具调用封装在协议层后面人类开发者失去了复现 Agent 行为的能力。2.3 工程摩擦部署之痛初始化不稳定MCP Server 启动失败、Claude Code 里冒出 100 僵尸 Node 进程认证繁琐每个 MCP Server 单独认证没有 SSO权限粗暴all-or-nothing无法区分查看和删除的风险等级协议动荡从 STDIO → SSE → Streamable HTTP兼容性混乱三、为 MCP 辩护我们只是太早了Matt Hall 的反驳文章《MCP Isnt Dead. Were Just Early.》代表了另一派观点。3.1 CLI 自身的问题被低估了输出不稳定CLI 输出格式随意、版本间无警告就变更Agent 误读时没有契约可验证管道的脆弱性grep | jq | awk对人类来说灵活但无类型管道容易静默失败Agent 链式调用时边缘情况频发认证无法延伸gh auth login对单个开发者够用但无法支持多 Agent 协作、权限委派、Token 撤销3.2 MCP 的价值在于结构化契约Matt Hall 的核心论点是MCP 的价值不是传输层而是契约层。类比 OpenAPI 对 REST 的作用在 OpenAPI 之前一千个 API 有一千种风格OpenAPI 给了 REST 一个标准契约让工具链、文档、测试都变得可用。MCP 在做同样的事——给 Agent-工具交互一个机器可验证的结构化契约。当 MCP Server 暴露一个接口时Agent 能获得可用操作列表、参数结构、返回值类型。这比读一段文档然后猜要可靠得多。3.3 从本地守护进程到托管基础设施Matt Hall 还指出了 MCP 的演进方向Streamable HTTP OAuth 2.0。早期 MCP 的问题是 Server 跑在本地——需要安装、管理、排障。但当 MCP Server 变成托管服务像 Linear、Granola 已经在做的用户不需要安装任何东西指向一个 URL 完成 OAuth 就连上了。维护负担消失了。这就像 REST API 早期也被吐槽太多开销但最终证明底层抽象值得标准化。四、实践中的答案MCP 是协议CLI 是实现如果只看社区争论你会觉得这是非此即彼的选择。但飞书、钉钉、企业微信的 CLI 开源给出了一个更务实的答案——MCP 和 CLI 不在同一层它们是协议与实现的关系。4.1 重新理解分层MCP 负责 integration集成层标准化暴露能力、治理权限、工具发现CLI 负责 execution执行层面向用户和 Agent 的命令行壳、结构化输出、本地脚本4.2 三家平台的实际架构印证了这一点钉钉 dwsCLI 外壳下是完整的 MCP Client。它从 MCP 市场拉取服务注册表通过 MCPinitializetools/list握手发现能力再通过 MCP JSON-RPC 执行调用。CLI 只是把 MCP 的能力翻译成了dws calendar event list这样的命令行格式。企业微信 wecom-cli同样是一个 MCP Client 的 CLI 壳。Rust 核心通过 JSON-RPC 与服务端通信npm 层做跨平台分发。飞书 larksuite/cli虽然没用 MCP 协议名但做的事情等价——从 OpenAPI 元数据构建命令树服务端定义能力CLI 透传调用。本质上也是协议层 实现层的分层。4.3 回看社区争论两边都没错但都只说了一半论点CLI 派说得对的部分MCP 派说得对的部分Token 效率✅ CLI 不注入 Schema上下文更轻⚠️ 但如果 CLI 文档不好Agent 会猜错可调试性✅ CLI 对人类可见可复现⚠️ MCP 的结构化契约让错误可验证可组合性✅ 管道是 Linux 五十年的积累⚠️ 无类型管道对 Agent 容易静默失败认证✅ CLI 的 auth 已经很成熟⚠️ 无法延伸到多 Agent、多租户场景部署复杂度✅ 本地 MCP Server 确实不稳定⚠️ 托管 MCP 会消除这个问题两边说的都是真实的痛点但解决方案不是二选一——而是分层组合。五、Token 效率这场争论中最硬的数据Token 效率是整个争论中最有说服力的维度。ScaleKit 的 benchmark 数据给出了量化的结论指标CLIMCP差距Token 消耗基准9-32 倍MCP 多出一个数量级成本基准17 倍MCP 贵得多失败率0%有明确失败率MCP 更不可靠这个差距的根本原因是CLI 把知识放在了模型的训练数据里数十亿行终端交互而MCP 把知识放在了运行时的上下文窗口里每个 Server 的 Schema 定义。前者是一次性成本训练时已经付了后者是每次调用都要付的持续成本。六、Trevin Chow 的七个原则Agent 友好的 CLI 长什么样这场争论催生了一个建设性的产出——Trevin Chow 在构建多个为 Agent 优化的 CLI 后总结了七个设计原则默认非交互不要弹交互式提示Agent 无法处理结构化可解析输出--format json是标配不要只给人类可读的表格快速失败 错误可操作报错要告诉 Agent 怎么修而不是只说失败了安全重试 明确变更边界幂等操作、dry-run 预览渐进式帮助发现--help和子命令帮助让 Agent 按需获取信息可组合 可预测结构输出格式一致可被管道串联有界 高信噪比响应限制输出量不要把整个数据库 dump 出来这些原则的核心洞察是每一条同时让 CLI 对人类更好——结构化输出、操作错误、有界响应不是对 Agent 的妥协而是一直应该做的设计。七、结论不是二选一而是分层回到最开始的问题MCP 和 CLI 到底谁赢了答案是都不完全对。正确的理解是MCP 不会死但会退到它该在的位置——作为集成层的标准化协议负责能力暴露、权限治理、工具发现CLI 不是万能的但它是面向 Agent 和人类的最佳执行入口——轻量、可调试、Token 高效最优架构是两者组合MCP 负责 integrationCLI 负责 execution飞书、钉钉、企业微信已经在实践这个分层了。它们的 CLI 外壳下面跑的都是 MCP 协议或等价的 OpenAPI 元数据驱动只是把 MCP 的能力翻译成了更友好的命令行格式。社区争论了一个月最后发现大厂早就想清楚了——协议和实现从来就不是对立的。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。