MCP 落伍了？CLI + Skill 才是 Agent 工具链的未来

上周有一天，我的 Agent 工具链在同一个工作日里三次栽在 MCP 上，三次都被同一个东西救回来：一段普通脚本 + 一个普通 CLI + 一份 Markdown 编排文件。也是在今年 3 月，Perplexity CTO Denis Yarats 在内部宣布弃用 MCP 回归 API 和 CLI，YC 总裁 Garry Tan 直接发帖说 “MCP sucks honestly”。「MCP 落伍了吗」这个问题，硅谷在吵，中文社区也在吵，但绝大多数文章都是转述别人的推文。这篇不一样——我的整套生产系统就是 CLI + Skill 重度实践（27 个基于 lark-cli 的飞书 Skill，零 MCP 常驻），我把第一手的踩坑实录、账单数字和迁移决策框架都放在这里。先亮立场：Agent 工具链正在分层收敛，Skill（SOP 层）+ CLI（执行层）成为主干，MCP 退守「动态发现」生态位。不是 MCP 已死，是它从默认选项降级为特定场景选项。

一天三次 MCP 掉链子：我的踩坑实录

先讲故事，因为这三个故事比任何论证都有说服力——它们的失败模式完全不同，但结局一模一样。

第一次：连不上我自己浏览器的浏览器 MCP。 那天我想抓这个博客的 Google Search Console 数据。GSC 我在 Chrome 里天天登着，看起来最顺手的方案是 chrome-devtools MCP——它把导航、点击、抓网络请求都封装成了工具。结果 MCP server 起的是一个全新 profile 的隔离 Chrome 实例：没有 cookie，没有登录态。我想那就登录一次呗，Google 的自动化检测直接把登录流程拦了。改成 attach 到我真实的浏览器，tab 定位又失灵，点击落在错误的页面上。跟这层抽象搏斗了四十分钟之后，我删掉 MCP 配置，用 puppeteer-core 写了 60 行左右的脚本，直连我已登录 Chrome 的调试端口——就是我在 Chrome DevTools MCP 配置教程里写过的 9222 端口那套。一次跑通。复盘时我意识到问题的本质：MCP 层不是没帮上忙，而是主动在我和一个我本来就拥有的资源之间插了一道隔离墙。

第二次：直接消失的 MCP server。 我的博客封面图生成，原来走的是 Rube——一个托管 MCP 聚合服务，代理 Gemini 的生图 API。Rube 停服了。不是变慢，不是降级，是没了。所有路由经过它的工作流当场全灭。修复花了一个下午：写了一个一百行出头的 Python 脚本直连 Gemini API，先按 4K 出图再降采样成 1200×630 的 WebP。比走 MCP 时更快、更稳，还支持了代理层从来没暴露过的高分辨率。这个脚本现在已经活得比它替代的那层「基础设施」久了，而且我很确定它会继续活下去——因为脚本的依赖是 python + 一个 API key，而托管 MCP server 的依赖清单里包含别人家公司的商业模式。

第三次：想明白浏览器从头到尾就不该出场。 第一次失败之后我退一步问自己：我为什么要驱动浏览器？GSC 和 GA 都有官方 API，都支持服务账号认证。最终方案是：个人服务账号 + 官方 API 脚本，headless 跑，cron 每周自动执行，数据落成本地文件让 Agent 直接读。没有 MCP，没有浏览器，没有会过期的登录态。这个教训可以推广：相当一部分 MCP server 包装的东西，往下挖一层本来就有可脚本化的接口。

三次失败，一个共同点：MCP 层要么是故障点（隔离实例、点击失灵），要么是会消失的依赖（停服的托管服务），而它下面那层——CLI、脚本、官方 API——永远可用。开源项目 CompanyOS 的构建者把这个性质说得很直白：MCP 断开时，Skill 里的流程知识依然有效，无非从自动执行降级为手动操作。这句话我以前是点头赞同，现在是亲身验证——一天验证了三遍。

硅谷也在退：从 Perplexity 到 YC 的集体转向

如果只有我一个人踩坑，那可能是我的问题。但 2026 年第一季度发生的事情说明这是系统性的。3 月，Perplexity CTO Denis Yarats 宣布内部弃用 MCP、回归 API 和 CLI，同期上线的 Agent API 把「API 是基座、MCP 是可选层」写进了产品架构。Garry Tan 的原帖骂得更具体：MCP 吃上下文窗口、要手动开关、认证体验糟糕，他受不了基于 MCP 的浏览器集成，花 30 分钟给 Playwright 撸了个 CLI wrapper——发完帖才被团队告知 Vercel 早就做了一个。这也呼应了 Vercel CEO rauchg 那句被广泛引用的定调：“CLIs are the de-facto MCPs for agents”。（顺带做个事实核查：中文社区流传的「100 行代码、效果好 100 倍」这个细节，Garry Tan 的原帖里并没有，只有「30 分钟」是他自己说的，引用时注意别放大。）

这波转向真正扎心的地方在于是谁在退。Sentry 的 David Cramer 亲手搭过 Sentry 自己的 MCP server，然后公开写下「许多 MCP server 根本没有存在的必要」——要么是糟糕的 API 封装，要么一个 Skill 文件就能替代。连 Anthropic 自己——MCP 的发明者——都发了一篇工程博客承认把全量工具定义灌进上下文撑不住规模，建议让 Agent 写代码去调 MCP 工具而不是直接调。协议作者本人建议在模型和协议之间垫一层代码，这个信号怎么解读都不算乐观。

国内的动向和硅谷是同频的。飞书在 3 月底开源了 lark-cli——注意，是 CLI，不是又一个 MCP server——覆盖 11 个业务域、200 多条命令，还官方配套了 Agent Skill。我当时写过完整评测，现在它是我整套自动化的地基。当国内头部协作平台选择用 CLI + Skill 的形态对接 Agent 生态时，这已经不是社区偏好，是厂商用真金白银的研发资源投的票。

CLI 是模型的母语，账单不会说谎

为什么 CLI 赢？最底层的原因不是工程上的，是语言学上的：大模型的训练语料里装着几十亿行 shell 命令和对应输出——Stack Overflow、GitHub Issues、CI 日志、教程文档，连报错信息和人类怎么排错都见过无数遍。Agent 跑 gh pr list --state open 时，它在做一件母语级的事；调一个 MCP 工具时，它在照着 30 秒前才塞进上下文的说明书干活。一个是肌肉记忆，一个是现场看手册。这就是为什么「直接让它用 CLI」反复打败精心设计的工具定义：你不是在教模型新技能，你是在给它已有的技能让路。

然后是账单，这部分有可验证的数字。《Markdown is the New API》记录了那个经典案例：GitHub 官方 MCP server 光工具描述就要吃掉约 5 万 token 上下文（后来砍到约 2.3 万），而一份写着「用 gh 命令行操作，示例如下」的 SKILL.md 只要约 200 token 就达到同样效果——广为流传的「250 倍」就是从这组数字算出来的。这笔钱是在任务开始前、每个会话都要交的，不管这次任务碰不碰 GitHub。至于中文社区流传更广的另一组数据——「MCP 调用成本 10-32 倍、任务可靠率 72%」——我没能找到可复现的 benchmark 出处，姑且当作社区流传的对比看待，别拿去做严肃决策。但你也不需要那组数字：GitHub 这一个案例的 token 账就足够定性了。

上下文成本还有一层比账单更疼的二阶伤害：它让模型变笨。每一千 token 的 schema，就是模型少一千 token 思考你真正问题的空间，工具列表越长、选错工具的概率越高。我在上下文工程那篇里展开过这个机制——注意力是稀缺资源，而 MCP 的设计把它花在了管道上。CLI 在结构上有三个 MCP 给不了的东西：管道预过滤（| jq '.data | length'，数据没进上下文之前先精简）、报错即重跑（错误是模型见过的纯文本）、调试即复现（把命令原样粘到你自己的终端就行）。MCP 出问题时你在看别人 server 的日志，CLI 出问题时命令本身就是复现步骤——这条差异在我迁移之后的日常里，比省下的 token 更值钱。

真正替代 MCP 的是 Skill 这一层：27 个飞书 Skill 的生产实践

这里有个多数「CLI vs MCP」文章都漏掉的关键：光有 CLI 并没有掀翻 MCP，掀翻它的是 CLI + 一层知识文件。Skill 就是这层知识——一份 SKILL.md，写清楚跑哪些命令、什么顺序、边界情况怎么处理、什么时候该停下来问人。它是写给模型看的 SOP。我在 Agent Skills：用大白话写程序的时代来了里论证过这是一种真正的编程范式，半年之后我想把结论磨得更尖锐一点：Skill 接管了 MCP 的「编排」价值，CLI 接管了它的「执行」价值，两头一夹，常规场景下 MCP 就没剩下什么了。

我自己就在生产环境里跑这套架构，不是玩具。我的日常主力是 27 个封装 lark-cli 的飞书 Skill——lark-im 发消息、lark-doc 编辑文档、lark-base 操作多维表格、lark-calendar 排日程、lark-approval 处理审批、lark-vc 查会议纪要……每一个都是一份 SKILL.md：写明用哪些子命令、给出标准调用示例、标注身份和权限的坑。常驻 MCP server 数量：零。当我对 Agent 说「把昨天的会议纪要拉出来，摘要发给团队群」，它读两份 Markdown（各几百 token，触发时才加载），跑四条 CLI 命令，结束。同样的拓扑换成 MCP，是两个常驻 server、几万 token 的 schema，外加两个随时可能挂掉的进程。这个博客本身也是同一套打法——前面第二个故事里那个封面图 Skill，现在就是一份 SKILL.md 编排一个直连 API 的 Python 脚本。

外部最有分量的佐证来自 CompanyOS，它有意思恰恰因为它没有抛弃 MCP：系统连着 8 个 MCP server 对接 Gmail、Linear、Help Scout，但构建者明说系统的灵魂是 12 个 Skill 文件、约 2000 行 Markdown——工作流、护栏规则、语气校准、决策逻辑全在里面，MCP server 只是水管。改行为等于改 Markdown 提交 git，反馈回路以分钟计，团队里不会写代码的人也能 review。智能在 Markdown 里、传输层随便换——这才是终局形态，而它把 MCP 从「集成本身」降级成了「几根可互换水管中的一根」。

必须诚实交代 Skill 的代价，这也是我踩出来的：文字 SOP 不是代码，做不到 100% 确定性执行。模型会读漏一步、跳过一条护栏、在你要求照章办事的地方自作主张。我的解法是一条硬规矩：凡是必须精确的步骤，写成脚本让 Skill 去调用；SKILL.md 的文字只负责需要判断力的部分。判断归 Skill，精确归脚本。 如果一个流程零容忍偏差且不需要任何判断，那它根本不该是 Skill——该是 cron 任务，我的 GSC 数据管线最后就落在了那里。

flowchart TB
    subgraph SKILL["Skill 层 —— SOP（做什么、何时做）"]
        S1["SKILL.md 文件
流程步骤、护栏规则、边界情况
约 200 token，按需加载，git 版本化"]
    end
    subgraph EXEC["执行层 —— 手脚（怎么做）"]
        C1["CLI 工具
gh、lark-cli、aws..."]
        C2["脚本
直连 API、cron 定时任务"]
    end
    subgraph MCPN["MCP 层 —— 退守的生态位"]
        M1["动态工具发现
C 端产品、高频变化的工具池"]
        M2["OAuth 托管远程服务
本地不落凭证"]
        M3["无 shell 沙箱
网页版 Agent"]
    end
    S1 -->|"编排"| C1
    S1 -->|"精确步骤交给"| C2
    S1 -.->|"仅当 CLI/API 路径不存在"| M1
    S1 -.-> M2
    S1 -.-> M3
    style SKILL fill:#1a5276,stroke:#5dade2,color:#eaf2f8
    style EXEC fill:#145a32,stroke:#58d68d,color:#eafaf1
    style MCPN fill:#6e2c00,stroke:#eb984e,color:#fdf2e9

说句公道话：MCP 仍然赢的场景，和 CLI + Skill 的真实代价

「MCP 已死」的文章大多败在从不给对方摆事实，我不想犯同样的错——何况我自己现在还在跑几个 MCP server，理由是结构性的，不是怀旧。

没有 shell，CLI 论就不成立。 上面所有论证都有一个隐藏前提：你的 Agent 摸得到 shell。网页版 Agent、移动端助手、锁死的企业沙箱，很多根本没有。对它们来说「直接跑 gh 就行」是一句没有意义的话，而 MCP 的 HTTP 传输恰恰能进这些环境。这不是小众市场——大部分 C 端 AI 产品都在这个范畴里。

工具池真的高频变化时，动态发现是真价值。 我的飞书 Skill 能跑得稳，是因为 lark-cli 的命令面稳定。一个面向开放生态的 C 端 Agent——用户在运行时接入自己的第三方服务——真的需要运行时发现，这时带 schema 的协议就是比一个文件夹的 Markdown 强。2025 年的错误不是造了 MCP，而是把动态发现协议当成了静态工具集的默认方案，为没人用到的灵活性付了全额账单。

托管授权和审计边界。 我的 puppeteer 脚本连上已登录 Chrome 时，继承的是我的完整会话——方便，但也正是让安全团队睡不着的那种全量授权。远程 MCP server 配托管 OAuth，给企业的是一个卡口：细粒度 token、可撤销、每次调用留痕。而且要对 CLI 路线的另一面诚实：给 Agent 一个 shell，等于给它任意命令执行的能力。我在 MCP 安全指南里写过这个张力——当威胁模型里有提示词注入时，受限的协议面反而是优点。跨平台也是同理：我的 Skill 默默假设了 macOS，搬去 Windows 得返工，协议 schema 则不挑操作系统。

注意这些 MCP 赢面的共性：全是环境约束——没 shell、工具不稳定、凭证不能落地。没有一条是「在 CLI 存在且能用的前提下，MCP 集成得更好」。这就是我说「降级而非死亡」的准确含义：MCP 守住的是由约束定义的领土，在开发者有得选的地方全线撤退。

不是葬礼，是分层收敛：微软给出的终局预览

那收敛到哪里？目前最可信的预览来自微软。他们的 .NET Skills Executor 是个混合体：从目录里发现 SKILL.md 文件驱动 Agent 主循环，MCP server 沉到下面做众多执行后端之一，Skill 的某一步需要时才在后台静默调用。智能住在 Markdown 里，协议被降级为由 Skill 作者按步骤挑选的水管。微软同时还在维护官方 Skill 仓库。当最擅长把标准落地成企业产品的公司把 Skill 放上层、MCP 压下层时，未来工具栈的组织架构图已经画出来了：Skill 当 SOP 层，CLI/脚本当默认执行层，MCP 当前两层够不到时的兜底传输。

这也解开了「MCP 是否已死」的伪二元对立。问题从来不是「要不要协议」，而是知识住在哪一层。2025 年我们试图把流程知识塞进工具 schema——那些 5 万 token 的定义，本质上就是压缩得很烂的 SOP——失败是因为 schema 是承载判断力的糟糕介质。知识搬进 Markdown 之后，便宜、可版本化、人和模型都能读；一旦知识层独立出来，下面的传输层就沦为大宗商品，而大宗商品按成本竞争。CLI 是世界上最便宜的传输，因为模型本来就会说它。我在一月份的 Skill 与 MCP 的区别里把两者当互补的平级来写；跑了半年生产之后我要修正结论：互补没错，平级不再——一个是主干，一个是支线。

迁移决策框架：什么信号出现就该动手

理论说完，给可以直接抄的作业。这是我迁移自己工具链时实际用的判断流程，浓缩成五个信号，逐个核对你在跑的每个 MCP server：

1. 官方 CLI 或可脚本化 API 已存在（gh、aws、kubectl、lark-cli、带 token 认证的 REST API）——这个 MCP server 只是在你的 Agent 和它本可直达的东西之间做翻译。
2. Agent 有 shell——有，CLI 论全额适用。
3. 流程可重复——你翻来覆去调的就是那 3-5 个工具、相似的顺序，却在为静态例行公事支付动态发现的价格。
4. schema 成本远超使用率——server 加载几千上万 token 的定义，你只用其中五分之一的工具。翻一下会话日志，这条是可测量的。
5. server 需要人伺候——认证反复重配、常驻进程要管、动不动「关了再开试试」。Garry Tan 骂的全套。

命中三条以上：写 SKILL.md、指向 CLI、断开 server、对比迁移前后每任务 token。SKILL.md 只需要四段——用哪个工具、带真实输出的标准命令示例、失败模式和兜底、模型不许越过的硬边界。我自己的平均不到一百行。

flowchart TD
    A["审计你在跑的某个 MCP server"] --> B{"存在官方 CLI
或可脚本化 API？"}
    B -->|"否"| K1["保留 MCP
它本身就是集成"]
    B -->|"是"| C{"Agent 有 shell 吗？"}
    C -->|"否"| K2["保留 MCP
无 shell 沙箱生态位"]
    C -->|"是"| D{"流程可重复？
同样的工具、相似的顺序"}
    D -->|"否 —— 开放工具池"| K3["保留 MCP
动态发现值回票价"]
    D -->|"是"| E{"需要托管 OAuth
或协议级审计留痕？"}
    E -->|"是"| H["混合式：SKILL.md 在上
MCP 做后台静默后端
（微软 Executor 模式）"]
    E -->|"否"| M["迁移：SKILL.md + CLI
断开 server
对比每任务 token"]
    style M fill:#145a32,stroke:#58d68d,color:#eafaf1
    style H fill:#1a5276,stroke:#5dade2,color:#eaf2f8
    style K1 fill:#6e2c00,stroke:#eb984e,color:#fdf2e9
    style K2 fill:#6e2c00,stroke:#eb984e,color:#fdf2e9
    style K3 fill:#6e2c00,stroke:#eb984e,color:#fdf2e9

最后一条来自我自己迁移的提醒：别省掉「测量」这步。token 下降是标题党数字，真正改变我行为的是故障恢复时间——puppeteer 脚本坏了，我把命令一粘就看到报错；MCP 路径坏的那次，我在翻别人 server 的日志。可调试性才是复利，而它从来不体现在 token 账单上。

把我的立场写成一句可以被证伪的话：到 2026 年底，「怎么把 Agent 接到 X」的默认答案会变成「X 有 CLI 吗」，只有这个问题答「没有」时，MCP 才出场。今天新起 Agent 项目，从 Skill + CLI 开始；撞上前面四种环境约束的那天，再加 MCP server——别提前。

Related Reading

• Skill 与 MCP 的区别：两种扩展 AI 能力的方式
• MCP vs Skills vs Hooks：Claude Code 三种扩展怎么选
• Agent Skills：用大白话写程序的时代来了
• Lark CLI 完全指南：用命令行和 AI Agent 操控飞书
• Chrome DevTools MCP 配置教程：9222 端口连接已登录浏览器
• MCP 协议全面解析：AI 连接万物的通用标准
• Context Engineering for Coding Agents 2026: What Works