钉钉与飞书突然开源CLI工具的举动，揭示了AI Agent时代的接口协议之争已上升至战略层面。当MCP协议因32倍的token消耗差异暴露致命缺陷，CLI的懒加载机制正在重构Agent操作系统的经济模型。本文通过ScaleKit基准测试与Perplexity数据，拆解接口选型背后隐藏的上下文经济学，以及SaaS产品在Agent时代必须面对的生存法则。
2026年3月，钉钉和飞书在十天内先后开源了各自的CLI工具，且不约而同绕开了Anthropic主推的MCP协议。这不是一次偶然的技术选型趋同，而是一个信号——当AI Agent从概念验证走向生产部署，“Agent用什么方式操作软件”这个问题，已经从工程细节升格为平台战略。
核心命题很直接：Agent 调用外部服务时，上下文窗口的每一个 token 都是成本。选 MCP 还是 CLI，本质上是在回答一个问题——你愿意为「接口协议的优雅」付出多少倍的推理成本？
ScaleKit 的基准测试给出了冷酷的数字：在 GitHub 场景下，同样查一个仓库的语言构成，CLI 消耗 1,365 tokens，MCP 消耗 44,026 tokens，相差 32 倍。五项任务综合下来，MCP 的月均成本是 CLI 的 17 倍，且附带 28% 的失败率。
这组数据足以让任何一个做过 Agent 成本核算的产品经理警觉。
MCP 的效率瓶颈根源不在网络延迟，而在 schema 注入机制。以 GitHub MCP Server 为例，它携带 43 个工具定义，每次对话必须将全部工具的完整描述注入上下文。你只是想查一个 PR 状态，模型却要先「阅读」43 份工具说明书——其中单个工具定义就占 4,000+ tokens。
这是 MCP 架构的结构性问题，不是优化能解决的。协议的核心假设是：Agent 需要在每次交互中「看见」所有可用能力，才能做出正确的工具选择。这个假设在工具数量少于 10 个时尚可接受，但当钉钉暴露 12 个服务模块、飞书覆盖 2,500+ API 端点时，schema 膨胀就成了不可承受之重。
反观 CLI 的信息获取方式：Agent 先跑 –help 拿到顶层命令列表，再按需深入某个子命令查看参数说明。这是一种懒加载的上下文策略——只在需要时才消耗 token，而不是预先把整本字典塞进工作记忆。
从Scaling Laws的角度来看，这件事还有更深一层的含义。当前大模型的推理成本与输入token数直接挂钩，上下文窗口虽然在扩大（Claude已达到20万），但窗口大小的增长远追不上SaaS工具API数量的膨胀速度。MCP的schema注入模式，本质上是在用最昂贵的资源（LLM推理算力）去承载最廉价的信息（工具元数据）。这在经济上不成立。
Perplexity 首席技术官披露的数据更加直白：MCP 占用了 72% 的上下文窗口。这意味着留给真正任务推理的空间，只剩不到三成。
从产品视角看，钉钉和飞书的 CLI 化有一个容易被忽略的深层逻辑：GUI 本质上是一个翻译层，是为人类视觉系统设计的中间件。 按钮、菜单、拖拽——这些交互范式解决的是「人类手指和眼睛如何高效操作计算机」的问题。Agent 不需要这个翻译层。
飞书的三层架构设计值得拆解。Shortcuts 层（前缀命令）做了大量参数简化，替代了复杂的 JSON body 拼接；API Commands 层一一对应平台 API；Raw API 层则是万能逃生舱，确保 Agent 在边缘场景不被卡住。这种「从易用到万能」的递进设计，本质上是在为不同能力等级的 Agent 提供不同粒度的接口。
钉钉的设计哲学不同，但同样务实。–yes 跳过确认、–mock 模拟数据、–dry-run 预览执行——这三个参数不是功能点，而是 Agent 可靠性工程的基础设施。做过 Agent 开发的人都清楚，一个交互式确认弹窗就能让整个自动化链路崩溃。
两家的差异也暴露了各自的产品基因：钉钉覆盖了 OA 审批、考勤打卡、DING 消息这些强管控场景，像是给企业行政部门配的数字员工；飞书覆盖了邮件、文档 Markdown 互转、知识库管理，更像研发团队的效率放大器。这种差异不是技术选型的问题，是客群定位的必然结果。
至于 Okta 副总裁提出的安全质疑——CLI 绕过了 MCP 的协议握手，安全怎么办？这个论证在开放生态场景下成立，但在企业内网场景下是伪命题。企业内部的 Agent 身份已知、权限预设、操作沙箱化、日志全链路可追溯。钉钉的批量熔断和飞书的按域权限申请，已经在 CLI 层面实现了等效的安全管控。没必要为了协议的「形式完整性」支付 17 倍的成本。
第一，CLI 将成为 SaaS 产品的标配交付件。 正如移动时代每个产品必须有 App，Agent 时代每个 SaaS 必须暴露 CLI。企业微信、Notion、Slack 都会跟进，这不是选择题，是生存题。谁先出 CLI，谁先拿到 Agent 生态的接入权。
第二，MCP 不会消亡，但会退守到开放生态的「护照层」。 当 Agent 跨越组织边界、调用陌生服务时，MCP 的身份协商和权限握手仍有价值。但在企业内部、在已知信任域内，CLI 将是默认选择。MCP 的定位会类似 SOAP——技术上没死，但大多数开发者已经忘了它。
第三，「上下文经济学」将成为 Agent 架构设计的第一原则。 随着 Agent 任务复杂度上升，上下文窗口的分配将成为核心瓶颈。任何在接口层浪费 token 的设计，都会在规模化部署时被淘汰。CLI 的懒加载模式只是起点，未来可能出现更激进的上下文压缩方案。
当你设计 Agent 架构时，不要问「协议是否优雅」，要问「每个 token 是否都在为任务推理服务」。在推理成本归零之前，上下文窗口里的每一个字节都是战略资源。
本文由 @苏苏肌肉大 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。