开场：同一周，两种选择
2026年3月，本该是 Agent 协议统一元年。
MCP（Model Context Protocol）已经在线上生产环境跑了一年多，开发者社区的主流叙事很清楚：Agent 需要一个标准化的接口层，一个在 AI 模型和它调用的工具之间的通用翻译层。MCP 被定位成这个 layer——干净、传输无关、为 AI 原生时代设计。
然后，同一周，飞书和钉钉这两家中国最大的企业协同平台，发布了各自的 Agent CLI 工具包。不是 MCP Server，不是协议绑定，是 CLI 工具。协议社区的愿景和市场实际买单之间的距离，从来没有这么清晰过。
飞书的 CLI 提供了 2500+ API 端点，覆盖 11 个业务域，还绑定了 19 个 AI Agent Skills。发布后 72 小时内全量开源到 GitHub。钉钉的 CLI 覆盖了 10 个核心平台能力——但选择了闭源。开发者在社区问为什么，评论区有人说了一句大实话："钉钉的 API 封装做得那么平庸，还好意思闭源？思路本身就有问题。"
这不是 MCP 失败的故事。MCP 在很多平台正在获得采用。这说的是一个更朴素的故事：诞生于 1970 年代的命令行界面 CLI，是如何在当下这场 Agent 基础设施竞赛中，靠"能跑"打败了"标准"的。
市场已经投票：CLI 先行，MCP 以后再说
飞书和钉钉同时发布 CLI 的模式，说了一个很一致的故事：企业平台在 Agent 工具策略上的优先级是什么。
飞书的 CLI 是个大家伙。2500+ APIs，覆盖 11 个业务域——日历、文档、消息、搜索、审批流、任务管理、联系人、邮件、数据分析、集成管道、开发者工具。在这之上，飞书绑定了 19 个 AI Agent Skills：离散的、可组合的能力单元，Agent 可以调用它们完成具体任务。整个项目是开源的，社区可以审计、扩展、二次分发，不用担心平台锁定。飞书的赌注很清楚：先给 Agent 最大化的能力接入，协议层的事以后再谈。
钉钉的 CLI 覆盖了 10 个核心能力——比飞书的覆盖面少了一个数量级，而且还闭源。比较的不只是范围，是理念。飞书把 Agent 生态当成平台来玩，借社区的风；钉钉看起来把 CLI 当成自己的私有差异化能力。开发者反馈很冷淡。有个叫陈明的开发者在对比了两家工具包之后评论："钉钉这个 CLI 没什么开源价值，因为 API 封装设计得太差了——但他们选择闭源这件事本身，才说明了他们对 Agent 生态的理解有多落后。"
关键观察是：两家公司在首批 Agent 发布中，都没有优先做 MCP Server。两家后来都宣布了 MCP 兼容路线图，但发布顺序很说明问题。市场需求的是 Agent 能立即用起来的工具。协议标准化是其次的。
这个现象不是中国平台独有。GitHub 把 Copilot 的 Agent 能力集成到 workspace 时，第一代集成是 CLI 驱动的。Replit 部署 Agent 处理部署流水线时，Agent 说 shell。Google Workspace 的 Agent 集成也是以 gws CLI 为核心。模式在各个地区和各种使用场景里高度一致：CLI 是第一波接口，协议是市场验证之后的整合手段。
CLI 为什么更适合 Agent：四个技术原因
今天的 Agent 平台不是跑在浏览器沙盒里的 Web 原生应用。它们跑在终端会话、CI/CD 流水线、容器环境里。Claude Code 跑在 shell 里。Cursor 的 Agent 模式跑在本地进程里。OpenAI 的 Codex 跑在云端 shell 里。Agent 住在开发者住的地方——命令行——而 CLI 就是它们的母语。
具体说，CLI 对 Agent 开发者提供了四点实质性优势：
零摩擦接口发现。 跑 lark-cli --help，你得到的是完整命令列表、参数说明、使用模式。这不是会过期的文档，这就是接口本身。当 Agent 需要了解一个工具能做什么，它跑 --help。当开发者需要审计 Agent 的能力访问范围，他们读同样的 help 输出。接口和文档是同一个东西。对比 MCP：能力发现需要先理解协议 schema、传输配置、Server 初始化序列，在能调用第一个工具之前就要做一堆功课。
无状态执行模型。 一个 CLI 命令跑完、出结果、退出。没有持久连接要维护，没有会话状态要管理，没有传输层要保活。对于需要在一个任务里编排几十个工具调用的 Agent，CLI 的操作简洁性是实打实的优势。每次调用相互独立、可重试、可观测。MCP 的传输层带来了状态性，在规模化时成了故障点。
Shell 集成是通用的。 跑在 bash、zsh、fish 或 PowerShell 里的 Agent，不需要任何特殊适配代码就能调用 CLI 命令。Shell 就是集成层。不需要装 SDK，不需要协调包管理器，不需要维护版本兼容矩阵。一个跑 curl 的 Agent 能访问任何 HTTP API。一个跑 lark-cli 的 Agent 能访问飞书平台。Shell 的抽象层级足够低，低到普遍兼容；又足够高，高到能表达复杂操作。
调试直接。 CLI 命令失败时，错误输出直接告诉你哪里出了问题。MCP 工具调用失败时，你可能要在协议握手、传输错误、schema 校验、服务端异常日志之间追踪半天才能定位根因。对于构建和调试 Agent 系统的开发者来说，这个调试差距不是小事。Agent 开发里有大量时间花在理解"为什么这个工具调用产生了意外结果"上。CLI 的调试模型就是更快。
实操结果是：CLI 先行的平台，Agent 采用速度更快。开发者可以先在 shell 脚本里原型验证一个 Agent 的工具使用，再决定要不要做完整的协议集成。这个迭代速度优势会随时间放大。
代码示例：飞书 CLI 实操
Agent 集成飞书 CLI 的实际样子是这样的——一个管理日历事件的 Agent 直接在 shell 里调用命令：
# List upcoming calendar events for the next 7 days
lark-cli calendar event list \
--start-time "$(date -v+1d +%Y-%m-%d)" \
--end-time "$(date -v+7d +%Y-%m-%d)" \
--fields "summary,start_time,attendees"
# Create a meeting with attendees
lark-cli calendar event create \
--calendar-id "primary" \
--summary "Q2 Planning Review" \
--start-time "2026-03-15T14:00:00+08:00" \
--end-time "2026-03-15T15:00:00+08:00" \
--attendees "[email protected],[email protected]" \
--description "Quarterly planning session"
# Search documents across the workspace
lark-cli docs search \
--query "infrastructure architecture" \
--types "doc,spreadsheet" \
--workspace "engineering"
Agent 直接拿到结构化输出——没有协议握手，没有会话协商，只有命令执行和它的结果。飞书 CLI 覆盖 11 个业务域，19 个离散 AI Agent Skills，每个都遵循同样的 shell 驱动模式，可组合。
代码对比：MCP Server 配置 vs CLI 命令
对比等效的 MCP Server 配置和工具调用：
// MCP server configuration (package.json equivalent)
{
"mcpServers": {
"feishu-calendar": {
"transport": "stdio",
"command": "npx",
"args": ["@feishu/mcp-server", "--auth-token", "ENV_FS_TOKEN"],
"env": {
"FS_TOKEN": "${FS_ACCESS_TOKEN}"
}
}
}
}
# MCP tool invocation (agent code)
def list_calendar_events(start_time: str, end_time: str) -> list[Event]:
"""
MCP tool call requires:
1. Server initialization handshake
2. Tool schema transmission (overhead ~200 tokens)
3. Result wrapping in MCP response format (~50 tokens)
"""
result = mcp.call_tool(
"feishu_calendar_list",
arguments={
"start_time": start_time,
"end_time": end_time,
"fields": ["summary", "start_time", "attendees"]
}
)
return parse_mcp_response(result)
# vs CLI equivalent:
def list_calendar_events(start_time: str, end_time: str) -> list[Event]:
"""
CLI tool call requires:
1. Command string construction (~20 tokens)
2. Shell execution
3. Output parsing (~30 tokens)
Total overhead: ~50 tokens vs ~250 tokens for MCP
"""
output = subprocess.run(
f"lark-cli calendar event list --start-time {start_time} "
f"--end-time {end_time} --fields summary,start_time,attendees",
shell=True,
capture_output=True,
text=True
)
return parse_json_output(output.stdout)
Token 开销差不是理论数字。在一个生产 Agent 处理 500 次日历操作的会话里，CLI 节省大约 100,000 tokens——这些 tokens 本来可以用于实际任务内容，而不是协议元数据。
MCP 的碎片化问题：协议标准化的历史在重演
MCP 社区把协议类比成 AI 工具的 USB——一个通用连接标准，让任何 AI 模型能连接任何工具。这个类比很有说服力猛一看也合理。USB 在 1990 年代解决的就是这个问题。但这个类比在仔细审视 MCP 生态实际发生的事情时，站不住脚了。
MCP 正在沿着和 1990-2000 年代 SQL 碎片化同样的路线分裂。SQL 是一个标准。每个主流数据库厂商都声称 SQL 兼容。但 PostgreSQL SQL 不是 Oracle SQL 不是 MySQL SQL 不是 SQL Server SQL。标准存在；实现却不可互换。把一个 SQL 应用从一个数据库迁移到另一个，是一项大工程，通常需要大量查询重写和 schema 调整。标准提供了通用语言，但没有带来真正的互操作性。应用开发者吃足了苦头才学到：write once，debug extensively for the target database。
MCP 正在展现同样的碎片化模式，只是时间线压缩了。
OpenAI Apps SDK 的变通方案。 OpenAI 的 Agent 框架在工具调用里加了一个 _meta 参数，专门用于解决上下文窗口限制。当 Agent 的 prompt 太大放不进上下文窗口时，SDK 发送一个最小的占位符而不是完整的工具结果。这是应对真实约束的务实工程方案，但意味着来自 OpenAI Agent 的 MCP 工具调用，携带的信息密度可能和其他提供商不同。一个针对 OpenAI 的 _meta 优化设计的 Agent，移植到不同 MCP 提供商时行为可能不同。碎片化是行为层面的：协议标准支持完整工具结果，但生产实现会在优化标志的使用上分化。
SSE 传输废弃。 Server-Sent Events（SSE）是 MCP 通信最初的传输选项之一，现在已经废弃，改用更健壮的替代方案。这个废弃不是假设性的——影响的是基于 SSE 构建并现在需要迁移的生产部署。协议还年轻，破环式变更可以预期，但它们积累起来。每次迁移都对针对特定传输假设构建集成的 Agent 开发者施加了成本。讽刺的是，废弃是由对可靠性的合理担忧驱动的，但市场后果是跑着不同传输栈的生产环境碎片化。
OAuth 2.1 安全漏洞。 OAuth 2.1 规范引入了更严格的 PKCE 要求，并移除了隐式授权流。MCP Server 实现在这些变更相关的安全漏洞上已经踩坑。MCP 相关 OAuth 错误配置的生产环境 CVE 已经出现，涉及 Server 操作者未充分验证 token 端点合规性的情况。在为 Agent 工具访问设计的协议中出现安全碎片化尤其值得担忧，因为使用受损 OAuth 流的 Agent 可能被操纵访问未授权资源。攻击面不是假设的：一个被操纵 OAuth 流的 Agent 可能被骗去代表未授权用户读取或写入数据。
Schema 协商不一致。 多家厂商的 MCP Server 在工具 schema 的具体定义上存在差异，导致某些客户端实现无法正确解析。这种"标准说了一套，实现做了另一套"的情况，正在真实发生。
MCP 生态正在重演 SQL 的故事：标准存在，实现分裂，开发者承担兼容性成本。
Token 消耗的隐藏成本
MCP 有个代价，很少出现在协议的宣传材料里：上下文窗口消耗。每个 MCP 工具调用都涉及一次往返，协议层往上下文里加元数据。工具 schema 必须传输，传输头必须解析，会话状态必须维护。这些在 LLM 定价按 tokens 计费的环境里，都不是免费的。
CLI 正相反，是一次性的 shell 执行。Agent 发一个命令字符串给 shell，shell 执行底层 API 调用或系统操作，返回输出。没有持久协议会话，每次调用不叠加元数据开销。CLI 调用的 token 成本就是命令字符串加输出，仅此而已。
对于每会话要做几十上百次工具调用的 Agent，这个差距是复利的。一个通过 CLI 管理飞书日历的 Agent，每次 API 调用消耗约 50 tokens。同样的 Agent 通过 MCP 调用，每次消耗约 120 tokens（包含协议开销：schema 传输、会话协商、响应封装）。一个 Agent 会话里跑 500 次日历操作，就多消耗 35,000 tokens。按现在的 LLM 定价，这是真金白银。规模化后——数千个 Agent 跑在生产环境里——是一笔不小的成本项。
Token 成本不只是财务问题。在固定上下文模型里，协议开销挤占的是实际任务内容。一个 Agent 的上下文窗口 30% 是协议元数据，就只有 70% 的空间留给真正要干的话。对于在大型数据集上做复杂推理的 Agent，这个挤占不是小效率问题，是能力天花板。
国内的情况： 飞书和钉钉的 CLI 发布后，社区里有人在实际压测 Token 消耗差异。有人估算，用 MCP 封装钉钉 API，单次工具调用额外消耗约 150-200 tokens（包含 schema 传输和响应封装）。"看起来不多，但一个复杂 Agent 一天跑几千次调用，月底账单就很好看了。"一位开发者在 V2EX 上写道，"协议费比 API 调用费还贵，这事就离谱了。"
国内企业 IM 平台 Agent 策略对比
飞书和钉钉之外，还有企业微信。这三家代表了三种不同的 Agent 工具策略，理解它们的差异对判断中国市场很有意义。
飞书（lark）：开放+社区路线。CLI 全量开源，2500+ API 全面开放，19 个 Agent Skills 打包提供。飞书的逻辑是：先把能力放出去，让开发者和生态用起来，形成事实标准，再去谈协议层。GitHub Stars 是验证逻辑，截至 2026 年 3 月底，飞书 CLI 项目在 GitHub 上的 star 增速是中国企业 IM 工具里 Agent 相关开源项目最快的。这个策略的好处是：飞书不需要自己教育市场，社区会替它做。
钉钉：封闭+保守路线。CLI 闭源，API 覆盖只有飞书的十分之一，文档质量也明显落后一个档次。钉钉的逻辑似乎是：先把能力收着，等市场验证了再考虑开放。但这个思路在 Agent 时代可能有问题——Agent 需要的是接入透明度，而不是功能数量。钉钉的 API 封装设计被社区吐槽"十年没进步"，在 Agent 时代这个问题只会更突出。企业微信团队有人在内部说过："钉钉的 API 设计思路还停留在移动互联网早期，根本没考虑过 programmatic access 的场景。"
企业微信：静默观望路线。截至 2026 年 Q1，企业微信没有发布任何面向 Agent 的官方工具。它的 API 能力其实不弱（继承了微信生态的很多能力），但官方没有 CLI，也没有 MCP Server。有人在即刻上猜测，企业微信在等"市场明确方向再入场"。这个策略的风险是：当飞书和钉钉已经开始积累 Agent 开发者社区和使用案例时，企业微信在错过时间窗口。
有意思的是，三家都没有在第一波优先发布 MCP Server。这说明国内平台也认同：协议是结果，不是前提。先让 Agent 能跑起来，有了生产级使用数据，再去谈协议标准化。
Google Workspace 的混合策略：最成熟的参考
Google Workspace 的 Agent 工具策略值得单独说，因为它代表了 CLI+MCP 混合模式最成熟的企业级实现。
googleworkspace/cli 包提供对 Gmail、Calendar、Drive、Docs、Meet 功能的直接命令行访问。Agent 通过 shell 执行直接调用这些命令。每次操作的 token 成本低，因为 Agent 和 API 调用之间没有协议层。一个 Agent 每天处理 1000 封邮件提取待办事项，CLI 是让它从"可行概念"变成"划算产品"的关键。
但 Google 同时维护着官方 Workspace MCP Server。MCP Server 提供结构化工具发现、类型化 schema 定义和标准化接口，能与任何 MCP 兼容客户端配合。对于工具发现和类型安全优先于 token 效率的场景——早期原型、Agent 评估框架、多平台聚合器——MCP Server 是正确选择。发现价值是真实的：当 Agent 在探索一个新 workspace 能做什么时，MCP Server 的结构化 schema 比跑 CLI 的 --help 更有用。
Google 自己的指导隐含承认了这个权衡结构：CLI 用于生产级 Agent 操作（每次 token 都算数），MCP 用于开发和发现工作流（人体工程学比边际成本更重要）。这不是矛盾立场——这是诚实地承认 Agent 开发生命周期的不同阶段有不同需求。原型阶段偏向可发现性，生产阶段偏向效率。
这是正在企业级平台间形成的混合模式：飞书开源 CLI 打底，MCP Server 在路线图上还没发布。钉钉 CLI 是私有的，MCP Server 有没有取决于竞争态势和开发者需求。Klarna 的 Agent 基础设施——从 1200 个 SaaS 应用简化为生成式核心——用 CLI 作为主要接口，因为 CLI 是每个 Agent 运行时都能调用而不需要平台特定适配器的最低通用抽象。Klarna 的案例特别有参考价值，因为它经历了完整的 MCP 评估流程，最终结论是 CLI 是其生产 Agent 工作负载的务实选择。
CLI 优先不是反标准化。是务实的标准采用：发一个每个 Agent 今天就能用的工具，等实现稳定了再给生态贡献 MCP Server。顺序很重要，因为实现经验会反过来指导协议设计。飞书的开源 CLI 会产生生产使用模式，这些数据会指导它最终 MCP Server 的实现。先发 MCP Server 意味着在缺乏真实生产反馈的情况下去设计协议。
对 Agent 基础设施的意义
市场发出的信号对协议倡导者不太舒服：标准化正在被即时能力交付所取代。Agent 今天就要解决问题。问题不是 MCP 最终会不会达到 USB 那样的普遍采用。问题是 2026 年的碎片化最终会合并还是会加深。
有谨慎乐观的理由。SQL 最终稳定了。REST 尽管早期碎片化，最终围绕 OpenAPI 合并了。MCP 工作组有主流平台厂商的积极参与，协议设计吸收了早期标准化努力的很多教训。现在看到的碎片化可能是一个必要的早期阶段——实现者们在确定共同模式之前先探索设计空间——而不是终态。
但也有理由担忧。Token 消耗问题是协议工具访问的结构性代价。随着 Agent 每会话运行更多操作而上下文窗口仍然有限，CLI 和 MCP 之间的效率差距会越来越明显。这会催生对混合架构的压力——热路径用 CLI，发现用 MCP——这比任何单一方案都复杂。在同一个 Agent 代码库里维护两个集成范式增加了维护负担，也提高了集成 bug 的概率。
更深的含义是关于 Agent 和接口的关系。Agent 不是 Web 应用。它们不需要为人类注意力和浏览器渲染设计的 Web 原生接口。它们需要的是为程序化调用设计的接口——shell 命令、函数调用、消息传递原语。CLI 是程序化调用最古老、最经实战检验的接口范式。CLI 获胜的原因不是怀旧。是 CLI 和 Agent 的实际工作方式天然契合。
杨政武（化名）是追踪企业 Agent 部署的独立分析师，他在分析飞书和钉钉发布时写道："2026 年押注 CLI 是正确的赌注。Agent 需要交付的是能力，不是规格说明书。协议会在实现稳定之后跟上来。所有想用协议领先的，最后都做出了一套漂亮的规格说明书但没人用。"
这是 Agent 基础设施社区正在形成的务实共识：让 CLI 承载第一波 Agent 部署，让 MCP 通过生产经验成熟，构建同时获得两者优势的混合架构。协议没有死。只是不是第一招。
FAQ
MCP 和 CLI 有什么区别？
MCP（Model Context Protocol）是一种传输无关的协议，旨在提供 AI Agent 与所用工具之间的标准化接口。它定义了工具 schema 如何通信、工具调用如何路由、结果如何返回给 Agent。CLI（命令行接口）是传统接口范式，Agent 用参数调用命令行程序并接收文本输出。MCP 是协议定义的，设计为跨平台互操作；CLI 是执行定义的，让 Agent 直接绑定到 shell 执行。MCP 每次调用增加元数据开销；CLI 不增加。
为什么 CLI 在 Agent 部署中更受欢迎？
CLI 受欢迎是因为它提供了零摩擦接口发现（--help 就是文档）、无状态执行（无持久会话状态）、通用 shell 集成（任何 shell 环境都能用）、以及直接的调试体验。对于跑在终端会话和 CI/CD 流水线里的 Agent，CLI 是原生接口。飞书和钉钉优先发布 CLI 工具，因为 CLI 让 Agent 能立即接入能力，无需协议开销。飞书开源 CLI 在发布两周内达到 5000 GitHub Stars——比同平台任何 MCP Server 实现都快。
MCP 和 CLI 能共存吗？
能，而且这种混合模式正在成为成熟 Agent 部署的主流。Google Workspace 就是例子：Agent 用 gws CLI 命令处理生产规模操作（token 效率敏感），用官方 MCP Server 做开发和发现工作流（类型化 schema 定义和结构化工具发现更有价值）。模式是 CLI 用于热路径（高频、效率敏感的操作），MCP 用于冷路径（发现、原型、跨平台聚合）。飞书和钉钉都宣布了 MCP 兼容路线图，暗示它们的 CLI 工具会和 MCP Server 共存而非被取代。这个共存不是理论——这是主流平台厂商正在收敛的生产架构。
CLI 和 MCP 的安全性对比？
两种范式有截然不同的安全考量。MCP 的 OAuth 2.1 实现出现过与 token 端点合规相关的 CVE，协议级安全依赖正确的 Server 配置。CLI 安全依赖底层命令执行环境的安全——如果 Agent prompt 在构造 shell 命令前没有正确清理，shell 注入漏洞可能很严重。CLI 的优势是透明：CLI 命令及其参数在进程列表里可见，审计更直接。MCP 的优势是标准化认证流程，更复杂但对企业安全需求功能更完整。两种范式没有天然的安全性高下；安全态势取决于实现质量和运营纪律。需要记住的是：协议标准化不等于自动带来安全——每个实现都需要单独审计。
开发者现在应该怎么选？
开发者应该优先交付能力，而不是协议合规。先发 CLI 工具让 Agent 能立即调用，测量生产中的 token 消耗和运营成本，等 CLI 工具稳定了再添加 MCP Server 实现。务实路径是：CLI 先行实现 Agent 即时赋能，MCP Server 等有了实现经验再贡献给生态，需要同时兼顾发现体验和执行效率的生产系统走混合架构。Agent 基础设施社区的共识是：让 Agent 部署并跑起来，比把协议做完美更有价值。协议成熟度会跟着生产经验走，而不是走在前面。Klarna 的经验——用 CLI 作为主要接口，把 1200 个 SaaS 应用简化成生成式核心——就是这个优先级的参考实现。
结论：CLI 先行，协议后至
2026 年 3 月飞书和钉钉同期发布 CLI，不是对协议标准化的拒绝，而是关于发布顺序的市场信号。市场要的是 Agent 今天就能调用的工具。协议标准化是合理目标——但它是能力交付之后的目标，不是前置条件。
CLI 在获胜，因为它和 Agent 的实际工作方式天然契合：无状态 shell 执行、通用 shell 环境、直接的调试体验。MCP 提供真实价值——标准化接口、结构化发现、传输抽象——但这些价值在开发和发现工作流中最明显，不在生产热路径上。MCP 生态正在发生的碎片化提醒我们：标准体比市场走得慢，务实的实现者会在委员会起草规格说明书时发出可用的工具。
从 Google Workspace 和飞书/钉钉路线图正在形成的混合模式说明了一个未来：CLI 和 MCP 在同一个基础设施栈里共存。CLI 承载第一波 Agent 部署（效率重要）。MCP 通过生产经验成熟，最终提供企业平台需要的互操作性。协议没有死。只是不是第一招。
对于今天构建 Agent 基础设施的开发者，教训很清楚：先发 CLI，贡献协议在后，为混合未来做规划。Agent 不能等规格说明书完美。它们需要能力，现在就需要。
（全文完）