8月18日，企业微信5.0.10上线，一次性向AI Agent开放了十项办公能力——消息、邮件、文档、在线表格、智能表格、智能文档、待办、日程、会议、通讯录。

不限企业规模，不需要特殊资质。WorkBuddy、Codex、DeepSeek Harness、千问办公，主流Agent都能直接接入。

但真正值得注意的不是"开放了什么"，而是一个工程决策：企微同时开放了CLI和MCP两条通道。

不是只开一条，是两条都开。为什么？

因为这两条路解决的根本不是同一个问题。

一、两条路，两种哲学

先说结论：CLI是"操作方式"，MCP是"能力接口标准"。它们不在同一个层面。

MCP（Model Context Protocol）是Anthropic推的开放协议，目标是给AI模型和外部工具之间建一套统一接口。架构上分三层：Host（AI应用本身）、Client（每个Client维护与一个Server的连接）、Server（提供上下文和能力的程序）。

这套设计直接借鉴了LSP（Language Server Protocol）的思路。LSP标准化了编程语言支持在编辑器中的集成方式，MCP则想标准化工具在AI应用中的集成方式。

说白了，MCP想做AI工具集成的USB-C接口。一个Server实现一次，所有支持MCP的Agent都能用。

CLI则是另一条路。Agent生成一条shell命令，系统执行后返回文本结果。没有JSON-RPC，没有能力协商，没有Schema定义。

git log --oneline -5，执行完返回五行提交记录。就这么简单。

这种"简单"不是偶然的。CLI是Unix哲学的产物：每个工具做一件事，通过文本流串联。当Agent成为调用者时，这套设计意外地契合——LLM天然擅长生成和理解文本。

MCP选了"重协议"路线，CLI选了"轻接口"路线。

两条路都能让Agent调用企微的十大能力，但走到目的地的代价完全不同。

二、32倍：上下文窗口的争夺战

Token开销是CLI和MCP之争中最有数据支撑的部分。

MCP的设计要求Server在初始化时，把所有工具的完整Schema（名称、描述、参数定义）加载到Agent的上下文中。当工具数量增长时，这部分开销会迅速膨胀。

Firecrawl团队实测过：完成相同的浏览器自动化任务，MCP方案消耗约44,026个token，CLI方案只消耗约1,365个token。差距32倍。

另一个团队报告了更极端的情况——三个MCP Server的工具定义总共吃掉了143,000个token，而可用的上下文窗口总共只有200,000个token。工具定义就占了71%，留给实际工作的只剩29%。

Vensas的独立测试验证了这个结论：MCP全量Schema加载需要55K-150K token的前置开销，CLI渐进式发现每次只需900-3K token。一个具体实验中，CLI方案节省了92-94%的token。

为什么差这么多？

MCP是"全量加载"模式。连接建立时，Agent需要一次性获取所有工具的完整描述。企微开放了十项能力，每项能力下面可能有多个子操作——发消息、读消息、创建文档、编辑表格、发起会议……如果全部走MCP，所有工具的Schema在初始化时就得塞进上下文窗口。

CLI是"渐进发现"模式。Agent不需要一开始就知道所有工具。它可以先用--help获取顶层命令列表，大约消耗50-200个token。需要调用某个具体子命令时，再查subcommand --help获取详细参数。

按需加载，不是一次性全量。

Token不只是成本问题，更是能力问题。上下文窗口是有限的，工具定义占的空间越多，留给任务本身——用户输入、对话历史、中间推理——的空间就越少。

当三个MCP Server吃掉143K token后，200K窗口只剩57K给实际工作。简单任务可能够用，但在需要长对话、多步推理或处理大文档的场景下，窗口会被迅速耗尽。系统不得不截断历史或丢弃上下文，直接影响Agent的推理质量。

企微开放十项能力，如果Agent同时调用五项以上做复杂任务编排，MCP的token开销就会成为实实在在的瓶颈。

这就是企微同时开两条通道的第一个原因。

三、97.1%：工具描述的质量黑洞

Token多花了，效果还不一定好。

arXiv上的一项研究（MCP Tool Descriptions Are Smelly）分析了大量MCP Server的工具描述质量，结论令人担忧：97.1%的工具描述存在"气味"（smell），56%缺乏清晰的目的说明。

这意味着Agent花大量token加载的工具描述，可能并没有帮助LLM正确理解工具用途。更糟糕的是，当描述质量低时，工具增强的成功率只提升了5.85%，但执行步骤数增加了67.46%。

Agent在反复尝试错误的参数组合，每试一次就多消耗一轮token。

CLI模式下这个问题天然较轻。--help的输出由工具本身生成（通常是argparse或cobra等框架自动生成的），格式统一，信息密度高。LLM对--help格式的理解能力也更好，因为这种格式在训练数据中大量出现。

回到企微的场景。十项办公能力，如果每项都有三五个子操作，就是三五十个工具定义。如果走MCP，这三五十个工具的描述质量参差不齐，Agent可能在"创建日程"和"发起会议"之间反复试探，消耗大量token却进展缓慢。

走CLI，Agent先看wecom --help，知道有什么命令；再用wecom meeting --help，知道会议命令怎么传参。一步步来，每步只花几百token。

企微同时开两条通道的第二个原因在这里：不是所有Agent都需要MCP的结构化能力，很多场景CLI更高效。

四、门禁卡和告示牌：安全模型的根本差异

安全是比Token更重要的考量维度。

CLI有一个经常被忽略的安全优势：命令本身就是边界。

git status只能查看仓库状态，不能推代码。docker ps只能列出容器，不能删镜像。每条命令的权限范围在二进制层面就确定了，不依赖LLM对prompt指令的遵守。

MCP的安全控制主要通过prompt层面的指令和annotation来实现。规范明确要求"用户必须显式同意工具调用"，但工具本身能做什么取决于Server的实现。规范中也坦承，工具行为描述应当被视为不可信的——除非来自受信任的Server。

用一个不太恰当的类比：CLI的安全像门禁卡，每扇门对应一张卡，物理上就进不去不该进的房间。MCP的安全更像门口贴了一张告示"请自觉只去你该去的房间"，实际执行依赖LLM的理解能力和Server的实现质量。

对于企微这种企业级场景，这个差异至关重要。

想象一个Agent接入了企微的十大能力。通过CLI，Agent发消息就是wecom message send，创建文档就是wecom doc create。每条命令的权限边界清晰，审计日志也清晰——执行了什么命令、传了什么参数，一目了然。

通过MCP，Agent调用的是经过能力协商后的Tool。Tool的行为由Server实现决定，而Server的实现对Agent来说是不透明的黑盒。如果Server实现有漏洞，或者Agent对工具描述的理解有偏差，可能执行了预期之外的操作。

企微面向的是企业，企业对安全的底线要求是"可审计、可追溯、可控制"。CLI在这三个维度上天然比MCP更确定。

这不是说MCP不安全，而是说两者的安全模型设计哲学不同。MCP的安全靠协议规范和实现质量，CLI的安全靠命令边界的物理约束。在安全敏感的企业场景，后者更让人放心。

五、为什么要两条都开：不是二选一，是场景适配

理解了Token和安全两个维度的差异，企微"双通道"的工程逻辑就清楚了。

不同Agent，不同需求。

WorkBuddy、千问办公这类办公Agent，主要做信息检索、文档生成、日程管理。任务集中在少量工具上，高频调用，对Token效率敏感。走CLI更合适。

Codex、DeepSeek Harness这类编码Agent，本身就有成熟的CLI生态，跟企微交互只是附带功能。走CLI不增加学习成本。

企业自研的多租户Agent，可能需要面向不同部门、不同权限的用户提供服务。需要能力协商、权限控制、动态工具发现。走MCP更合适。

跨Agent协作场景，多个Agent通过标准化协议共享企微能力。MCP的标准化接口让Agent之间的集成成本更低。

Firecrawl、CircleCI等团队的实践已经验证了这个判断：内循环用CLI，外循环用MCP。

开发者日常高频使用的工具用CLI减少Token开销。面向用户或跨团队的服务型Agent用MCP利用其标准化集成。安全关键操作用CLI确保行为边界，信息获取类操作可以用MCP利用其Resources原语。

企微同时开两条通道，本质上是把选择权交给了Agent开发者和企业。你的上下文窗口值多少钱，你的安全要求有多高，你来决定走哪条路。

六、不限规模：中小企业的Agent入场券

这次开放还有一个容易被忽略的细节：不限企业规模。

过去，企业想把AI接入办公系统，要经历漫长的开发周期：写接口、做适配、调试权限。这套流程对大企业来说只是时间成本，对中小企业来说可能是入场门槛。

企微5.0.10把门槛压到了最低。企业只需把一条提示词给智能体：

npx skills add WecomTeam/wecom-unified -y -g

然后创建智能机器人，就完成了安装。Agent自动获取上下文、调用工具、完成任务闭环。

从"需要你告诉它一切"进化到"它能自己去找、去做"。

对政企客户来说，这个变化的意义不止于效率。当Agent能直接读取企微消息、邮件、文档、会议记录，企业内部的审批流、汇报流、协作流就有了被Agent自动化的基础。

拿一个具体场景说：项目周报。

以前，项目经理要从企微群聊里翻聊天记录，从文档里找进度更新，从日程里确认会议纪要，然后手动拼成周报。

现在，Agent直接调用企微的消息接口拉取群聊内容，调用文档接口读取进度表，调用日程接口获取会议记录，自动生成周报草稿。整个过程不需要人工搬运信息。

从"人操作界面"到"AI直接调用底层基础设施"，这是一个范式转换。

七、三层开放：SaaS在AI时代的站位

把企微这次开放放到更大的行业背景里看，会看到一条清晰的演进路线。

网易有一篇分析文章把AI产品化分成四层台阶：API、CLI/MCP、Agent、A2A。

第一层是API，企业提供接口，开发者自己写代码调用。这是最传统的集成方式，灵活但开发量大。

第二层是CLI/MCP，企业开放标准化接口，Agent可以直接调用。这是企微现在站的位置。

第三层是Agent，企业自己提供AI Agent，用户直接跟Agent对话。钉钉的AI助理、飞书的智能伙伴都在这一层。

第四层是A2A（Agent to Agent），不同企业的Agent之间直接通信协作。这是终极形态，目前还在早期。

企微选择站在第二层，不是因为它做不到第三层，而是因为第二层的战略价值最大。

站在第三层，企业提供的Agent能力受限于自身模型和产品设计。站在第二层，企业把基础设施开放出来，让所有Agent都能调用——无论它用的是DeepSeek、千问还是Claude。

你不是在选一个AI助手，你是在选一个AI助手的工作平台。

这跟微软的策略如出一辙。Microsoft 365 Copilot不断深化与Windows及Office底层API的连接，本质也是把办公基础设施向AI开放。

千问办公同一天接入企微，实现了钉钉、飞书、企微三大平台全覆盖。这不是巧合，而是说明三大办公平台都在加速Agent化布局。区别在于开放策略：钉钉和飞书更多在自己生态内做Agent集成，企微则选择了更底层的双通道开放。

收尾：你的上下文窗口值多少钱

回到开头的问题：企微为什么要同时开CLI和MCP两条通道？

因为它们解决的是不同层面的问题。MCP花了更多Token换来标准化和结构化，CLI省下的Token换来更多推理空间。MCP的安全靠协议规范，CLI的安全靠命令边界。MCP适合多租户和跨Agent协作，CLI适合高频调用和安全敏感操作。

企微把它们都开放了，等于把工程决策权交给了你。

你需要在标准化和效率之间权衡，在灵活性和安全性之间取舍，在开发成本和运行成本之间算账。

这不是一个有标准答案的选择。但你必须理解这两条路的差异，才能做出正确的决策。

核心问题永远是：你的上下文窗口值多少钱。

在Agent时代，上下文窗口就是最稀缺的资源。谁能在有限的窗口里完成更多有效推理，谁就赢了。MCP和CLI的之争，表面是协议之争，底层是资源效率之争。

企微开放十大能力是新闻，同时开两条通道是工程判断。前者告诉你"能做什么"，后者决定了"做这件事的代价"。

搞清楚代价，比知道能做什么重要得多。