3月17日到3月27日，整整10天。
钉钉「悟空」Agent平台发布，宣布完成全面CLI化改造；10天后，相关代码以Apache-2.0协议开源，首批开放10项核心产品能力，原生支持Claude Code、Cursor等主流AI编程环境。
同月28日，飞书跟上，lark-cli落地GitHub，MIT协议，Go语言实现，200+条命令覆盖消息、文档、多维表格、日历、邮箱、会议等核心业务域，配套19个AI Agent Skills，开箱即用。
从发布到开源只用10天，这是一个团队对某个判断高度确信时才会有的节奏。
两家的判断方向相同：放弃MCP，选择CLI。
消息一出，开发者社区的情绪点燃了。Perplexity CTO Denis Yarats在同月的Ask 2026大会上宣布放弃MCP，理由直接：token消耗太高，认证流程太繁琐。YC总裁Garry Tan更早开炮，说"MCP说实话很糟糕"，然后自己去写了个CLI工具。各种声音汇聚成一句口号在开发者圈里广泛流传：MCP已死，CLI当立。
这句话对吗？
王吉伟频道的判断是：对了一半，错了一半，因为这个问题本身就带着一个错误的预设。
把MCP和CLI放在同一个赛场里比胜负，就像拿螺丝刀和扳手比哪个更好用。它们设计目标不同，适用场景不同，在某些地方可以互相替代，在另一些地方根本不在同一个维度。搞清楚这一点，比跟风喊"XX已死"有用得多。
本文就跟大家聊聊，MCP、Agent Skill、CLI、GUI这四个概念分别是什么、解决什么问题、有什么代价，再给出2026年Agent接入层的真实场景适配方案。
概念校准：四个词不在同一个层面
很多热议之所以越争越乱，是因为讨论双方对核心词的理解压根不在同一层面。我们先来做一次校准，后面才能正常聊。
CLI：最老的基础设施，最新的复兴
CLI（Command Line Interface，命令行界面）是比绝大多数程序员年龄都大的技术，上世纪七八十年代就普及了。在终端里敲 git log --oneline -20，就是在用CLI。一条命令进去，结果出来，没有多余的渲染，没有等待界面加载，没有服务进程，没有协议握手，几乎零额外开销。
AI Agent为什么会重新爱上CLI？逻辑极其简单：Agent本质上是在生成文本、执行指令，CLI是用文本操作系统最直接的方式。不需要截图，不需要识别UI元素，一行命令完成一个操作，上下文开销接近于零。
钉钉CTO朱鸿那句话，把CLI化的核心理由说得很到位："我们希望每一个AI Agent，都能像调用系统命令一样自然地调用钉钉。"
MCP：给Agent世界造了一个标准插头
MCP（Model Context Protocol，模型上下文协议）是Anthropic在2024年11月发布的开放协议，目标是给AI模型和外部工具、数据源的通信制定统一标准。如果各家工具API是世界各地不同规格的电源插座，MCP就是那个万能转换插头。
它的设计宏大：统一工具调用接口、支持安全认证、支持有状态连接、支持复杂工具链调度。截至2026年初，每月超9700万次SDK下载，超1万个活跃服务器，OpenAI、Google、Microsoft全部跟进。
2025年12月，Anthropic把MCP捐给Linux基金会旗下的Agentic AI Foundation（AAIF），由Anthropic、Block、OpenAI联合维护，正式升格为行业标准。
但这个设计的代价同样显著：需要常驻服务进程，有网络握手开销，上下文占用大，启动延迟高。这些代价，是"MCP已死"论的真实依据。
Agent Skill：给能力加一张说明书
Skill（技能）是相对较新的概念。2025年10月Anthropic发布，12月18日正式成为开放标准（agentskills.io），Canva、Notion、Figma、Atlassian等企业提供预构建技能包。
Skill的逻辑极其简洁：一份 SKILL.md 文件，用自然语言告诉Agent这个工具能做什么、怎么用、什么时候用。Agent读完即知，用完即走，不占上下文，不需要常驻服务。
它本身不是传输机制，而是能力的描述和封装层。CLI提供执行能力，Skill文档提供认知框架，两者组合成Agent可以直接取用的技能包，这个组合的轻盈程度，是目前Agent工程实践里的天花板。
GUI：不是消亡，而是在变形
GUI（Graphical User Interface，图形用户界面）是为人设计的。窗口、按钮、菜单，都是人类视觉认知的映射。
Agent不需要这些。当目标工具有API、有CLI、有MCP时，Agent直接调用，不需要"看到"一个按钮。只有当所有程序化手段都失效时，Agent才会退化到Browser Use（浏览器自动化）或Computer Use（截图加坐标点击），用大量token和高延迟模拟人类的视觉操作。
从这个意义上说，GUI作为Agent的操作对象确实在快速边缘化。但GUI作为人类监督Agent的界面，不但没死，反而在进化出全新形态。这个话题后面单独展开。
把四个概念放在一起，层次关系就清楚了：Skill是能力的描述层，CLI和MCP是传输通道，GUI是最后的兜底手段。它们不在同一个维度，把它们放在同一个赛场里比谁生谁死，本来就是个伪问题。
MCP的成本账，比你想象的难看
先把那些真实的数字摆出来。
MCP有一个结构性缺陷，叫"工具定义开销"。每次会话启动，系统需要把所有可用工具的JSON Schema定义全部塞进上下文，让模型知道有哪些工具可调用、每个工具的参数是什么。这个开销是固定的，无论这次会话实际用到几个工具，它都在那里占着位置。
Apideck记录了一个真实案例：一个团队连接几个MCP服务器后，工具定义直接吃掉了20万可用token里的14.3万，占比72%。模型还没开始干活，上下文窗口就有七成用来读工具说明书了。
Scalekit的基准测试更系统：75次同等条件对比（相同模型Claude Sonnet 4、相同任务、相同提示词），MCP比CLI消耗4到32倍的token。最极端案例是检查仓库语言这个最简单的任务，CLI消耗1365个token，MCP消耗44026个，差了整整32倍。GitHub MCP服务器单独一个，就跨93个工具定义消耗55000个token。
Cloudflare给出了另一个佐证：他们的MCP服务器用两个工具、约1000个token覆盖了2500个API端点；如果把相同端点用原生MCP逐一实现，需要约24.4万个token，超过大多数模型的整个上下文窗口。
mmntm.net估算：1000名开发者、每人每天跑5次会话的企业，每年仅浪费在"未使用工具定义"上的成本接近400万美元。5人DevOps团队每月多出375美元的账单，换来的是零额外功能。
除了token，还有两个问题让工程师头疼。一是认证复杂，连接多个服务时每个都要单独处理OAuth和令牌管理，工程量不小。二是工具污染，多个MCP服务器同时运行时工具描述互相混叠，模型选错工具的概率上升。
技术上有补救方案：Speakeasy的动态工具集按需加载而非全量加载，将输入token使用量降低96%；Anthropic在2026年1月推出MCP Tool Search解决同样的问题。补救方案的出现，同时也证明了设计本身的结构性缺陷。这些数据是MCP已死论的技术依据，客观存在，不是偏见。
三、CLI+Skill：轻量主义的集体胜利
理解了MCP的成本，开发者集体倒向CLI+Skill就顺理成章了。
核心优势可以从四个方向来看。
零额外开销。 CLI工具大多本来就存在，git、kubectl、gh，这些几十年前就是CLI形态，不需要额外部署服务，不需要维护进程，不需要处理网络连接问题。"CLI本来就有，不需要额外Server"，这才是很多开发者喊出MCP已死的真实底气，他们根本不需要MCP解决的那个问题。
上下文干净。 CLI调用的开销极小，输入命令，拿到输出，结束。在长任务、多步骤的Agent执行流里，这个差别非常显著。
执行速度快。 本地命令执行，没有网络往返，没有服务器启动延迟。实测对比显示，相同数据查询任务下，CLI调用比MCP调用快3到10倍，高并发场景下差距进一步放大。
心智模型契合。 开发者本来就用CLI工作，把现有工具包装成Skill，学习成本接近于零。
这套逻辑下，2026年开发者圈里的优先级共识已经相当清晰：Skill + CLI > Skill + MCP > Skill + API > Browser / Computer Use。 能用CLI的不用MCP，能用MCP的不用Browser / ComputerUse。
钉钉和飞书的选择，是行业里最有分量的一次集体验证。两家覆盖数亿企业用户的协作平台，在同一个月做了同一个判断。平台上跑的任务大多是边界清晰的工作流，CLI够用，引入MCP的复杂性没有必要。
四、CLI+Skill的三个天花板
说完优点，必须聊聊边界。一些说"万物 CLI 化"的，有意无意绕开了这部分。
第一个天花板：遗留系统的墙
CLI化的前提，是目标系统提供了CLI接口。但大量企业的核心系统是SAP、Oracle ERP、AS/400（现称IBM iSeries或IBM i平台），没有现代CLI，很多连REST API都没有，只有几十年前的客户端软件和字符终端界面。
面对这些系统，既无API可调，也无CLI可执行，唯一能连接它们的方式仍然是RPA类工具，通过GUI自动化驱动这些老古董继续运转。
可以这样说：只要遗留系统还在，API解决不了接入问题，就还得靠RPA这样的工具。CLI+Skill在这里帮不上什么忙。开发者社区里很多人的日常是做API集成、云原生应用，在这个生态里CLI确实无所不能，但进入传统企业数字化改造的场景，那是一个完全不同的世界。
把开发者生态的最优解当成普世真理，是认知偏差，不是技术洞见。这部分市场在中大型企业里的占比，远比开发者社区讨论的要高。
第二个天花板：复杂跨系统业务流程的编排
CLI可以解决原子操作，但无法管理一条跨系统、跨部门的完整业务流程。从ERP到CRM，从财务系统到审批平台，一个完整流程可能涉及十个系统、多角色、多条件分支、人工审批节点。把这条链路串起来、处理异常、管理状态、保证事务一致性，需要一套编排框架，而不是一堆CLI命令。MCP的统一工具调用接口和状态管理机制，反而在这类场景里具有结构性优势。
第三个天花板：安全性，被低估的代价
这里有个值得认真讲的悖论。飞书OpenClaw插件的官方GitHub上写了这样一段警告：此插件存在模型幻觉、不可预测执行和提示词注入等固有风险；授权后将以用户身份行动，可能导致敏感数据泄露或未经授权操作。
这个警告揭示的工程现实是：CLI的简洁，部分来自于绕过了很多安全检查机制。如果认真处理安全，就需要加上OAuth授权、动态客户端注册、敏感操作审批、服务端鉴权，这些都加完，你会发现自己基本上重新实现了MCP的核心安全机制。
安全和简洁往往相互抵触。在个人开发者的脚本里，省掉安全层无妨。在处理企业敏感数据的生产环境里，那是另一个量级的风险。
五、MCP没死，只是找到了自己的主场
"MCP已死"把一个场景适配问题包装成了生死问题。技术圈这种叙事不少见，新东西出现，旧的就死了。但工程师不能被这种叙事带着走。
MCP从来没声称自己是轻量级本地工具协议。它的设计目标是解决AI系统如何安全、稳定、可扩展地连接企业内部工具和数据源，这个问题在企业场景里真实存在，而且目前没有比MCP更成熟的替代方案。
CData报告预测，MCP市场2025年将达到18亿美元，医疗、金融、制造业是主要需求方。这三个行业恰恰是对安全合规要求最高、遗留系统最多、最需要稳定认证机制的领域。在这些场景里，速度不是第一优先级，"对"和"安全"才是。
飞书自己的做法就是最好的说明：他们同时维护lark-cli和lark-openapi-mcp两套方案，前者给开发者用，后者给需要通过AI助手调用飞书API的企业集成场景用。两套方案并行，不是决策混乱，而是面向不同的用户群体。一家公司在生产级产品上做这种选择，本身就是有效信息。
MCP的演进方向是通过动态工具加载来解决上下文臃肿问题，而不是退场。Speakeasy已经证明动态工具集可以把token消耗降低约90%，Anthropic的MCP Tool Search在做同样的事情。方向是存在的，需要时间落地而已。
MCP和CLI不是谁杀死谁的关系。MCP是企业级标准方案，CLI是轻量首选，它们面向不同的需求，服务不同的场景，走向的是不同的山顶。
六、"万物CLI化"是伪命题
在开发者可控环境里，CLI化是正确方向；在企业全量场景里，"万物CLI化"站不住脚。
钉钉和飞书能做到全面CLI化，是因为这两家企业对自己的产品拥有完整控制权，可以从底层改造。大多数企业没有这个条件。企业的数字化基础设施通常是由数十家供应商的系统拼接而成的异构环境，既不可能要求每家供应商都提供CLI接口，短期内也看不到这个目标实现的路径。
开发者社区里每天讨论的"可CLI化"场景，是GitHub、Notion、Linear这类现代SaaS，它们本来就有API、CLI、SDK，接入成本低。但这只是企业数字化资产里更小的那部分。
SAP、Oracle ERP、20年前上线的自研财务系统，这些才是企业里真正跑核心业务的东西，它们等待全面CLI化的时间，远超任何人愿意等待的程度。
"万物CLI化"作为一个技术方向值得追求，作为现状描述是失真的，作为行动纲领是激进的。对那些还没有CLI接口的系统，RPA不是"技术落后"，是"别无选择"。CLI+Skill再轻量，在AS/400面前也是无能为力的。
七、GUI没死，它在变形：从界面到Agent UI
"GUI已死"这个论断，比"MCP已死"更加草率。
准确的说法是：GUI作为"Agent的操作对象"正在被边缘化，但GUI作为"人类监督Agent的界面"，不但没死，反而在进化出全新形态。
这里有个逻辑很关键：Human in the Loop本质上需要一个界面来承载。发出指令的是人，验收结果的是人，在Agent做出错误决策时踩刹车的也是人。无论Agent能力有多强，只要人类仍然需要监督和干预，就需要一个可感知、可交互的层。一个对使用者完全黑盒的Agent工作流，运行得越强大越让人不安。
这个需求驱动了一种新的界面形态：Agent UI，具体体现在两个正在快速普及的协议上。
AG-UI协议（事件驱动架构，GitHub项目：ag-ui-protocol/ag-ui）：Agent在执行过程中不断触发事件，前端框架订阅这些事件并实时更新显示。用户看到的不是静态页面，而是Agent工作过程的流式呈现，思考、工具调用、结果返回，每一步可见、可追溯、可审计。这让监督Agent变成了一件技术上可行的事情。
A2UI协议（声明式UI，Google创建，Apache 2.0开源，CopilotKit等社区参与贡献，2025年12月15日发布）：传统GUI是工程师预先设计好的固定界面，用户只能在框架内操作。
A2UI允许Agent根据任务上下文动态生成界面，比如在需要确认时间时自动弹出日期选择器，而不是让用户在对话框里打字描述。这不是"没有GUI"，而是"按需生成、用完即走的智能GUI"，千人千面，由Agent实时生成。
两个协议的组合，正在将传统GUI演化为全新形态：它不再服务于人操控机器，而是服务于人监督Agent"和"人与Agent协作。形态变了，背后的核心需求没变，因为人类永远需要这个窗口。
钉钉完成全面CLI化之后，仍然有"悟空"这样的界面给用户用，就是最好的例证。CLI化是Agent层的基础设施重构，用户侧的交互界面照样存在，只是背后的驱动逻辑从"人点按钮"变成了"Agent调命令，人看结果、人做决策"。
八、2026年场景适配：一张决策地图
说了这么多理念，来点实际的。不同场景该选什么，下面这张表给出了2026年的实践共识：
这张表背后，王吉频道有几个推论，值得说清楚。
推论一：所有方案里都有Skill。 Skill已经成为横切层，不管下层用CLI还是MCP，能力的封装和描述都不可缺少。这是2025年12月Skills成为开放标准之后最深远的影响，它不替代任何传输机制，但覆盖了所有传输机制之上的那一层。
推论二：MCP和CLI可以同时存在于同一个工具链。 很多MCP Server的内部实现，调用的就是CLI工具。MCP是协议层，CLI是执行层，把它们对立起来是对架构层次的误解。
推论三：Computer Use和Browser Use不是同一个方案。 Computer Use是全桌面控制，能力覆盖范围更广，代价也更大；Browser Use只操控浏览器，边界更清晰，成本相对更低。商业化部署里，成本是真实的约束条件。
推论四：RPA没有死，只是不在主流讨论里了。 大量讨论MCP vs CLI的文章里，RPA这个词几乎完全缺席，好像企业所有系统都已经API化了。这是严重的幸存者偏差。制造业、金融业、政府机构的大量核心系统，仍然运行在没有开放接口的老旧软件上，RPA是连接它们的重要可行方案。
九、给不同角色的实践参考
说了这么多分析，来点对不同角色有直接参考价值的建议。
对于开发工程师： 新建工具优先考虑CLI+Skill，成本最低，Agent友好度最高。需要安全认证、状态管理、多工具协调的内部系统，用MCP包装是更可维护的选择，不要因为"MCP已死"的声音就放弃这个方向。遗留系统对接别排斥RPA，它是工具，不是落后的象征。
对于产品经理： 在为Agent设计交互时，不要只关注Agent怎么执行，要同等重视用户怎么监督。"Agent执行更快"不会自动解决"用户信任Agent决策"的问题。关键操作需要审批，执行过程需要可见，结果需要可解释的展示界面。AG-UI和A2UI协议已经给出了实现路径，把这两个协议纳入产品设计的讨论范围。
对于企业架构师： 不要被"MCP已死"影响企业级架构决策。开发者工具生态用CLI+Skill没问题，企业集成层用MCP是更稳健的选择，遗留系统用RPA是现实答案，三套方案各得其所，互不冲突。同时，持续关注MCP动态工具加载方案的成熟度，Speakeasy和Anthropic都在推进这件事，未来12个月内应该会有更完整的落地方案出现。
对于AI Agent产品创业者： 接入层的技术选型会直接影响LLM成本结构。轻量场景用CLI，能省很多token费用。但如果目标用户是大型企业，MCP的安全合规能力才是客户真正在意的，别为了追求轻量而失去这部分市场。
结语：没有"已死"的技术，只有用错场景的工具
"MCP已死，CLI当立"是一句有传播力但缺精确度的判断。它捕捉了一个真实的趋势，却遮蔽了更复杂的图景。
CLI+Skill是2026年最受开发者欢迎的轻量范式，这是真的。钉钉和飞书用行动验证了这个判断，也是真的。但MCP在企业场景里没有退场，RPA在遗留系统里没有退场，GUI在进化成Agent-UI之后同样没有退场。
技术世界里很少有真正意义上的全面替代，更多的是场景分化和功能再分配。MCP、CLI、Skill、GUI看起来是四个变量，但真实的Agent工程环境里还涉及API、Browser Use、Computer Use、桌面Agent、RPA、数据层、安全合规，每个变量都有它存在的理由，也都有它解决不了的问题。
技术的价值，永远是相对于场景来定义的。在开发者的命令行环境里，CLI是最好的答案。在需要认证合规的企业系统里，MCP才是。在跑着AS/400的工厂车间里，RPA才是。没有脱离场景的最优方案，只有脱离场景的懒惰判断。
接下来，王吉伟频道会持续关注Skill标准化的进展、AG-UI与A2UI协议的实际落地情况、MCP动态工具加载方案的成熟度，以及RPA与Agent融合的新形态。这几个方向的演进，将在很大程度上决定2026-2027年Agent工程生态的真实格局。
