2026 年初，AI 圈出现了一次很有意思的“风向急转弯”：不少人开始公开唱衰 MCP（Model Context Protocol），甚至有点像在年会上把 PPT 的目录页撕掉——不是“我们要优化”，而是“我们不玩了”。

更戏剧的是，这种转向不是某个小团队的口嗨，而是从 基础设施、开发者工具链、到 企业协作产品一起发生。

本文想针对这些变化聊一聊：

• 为什么 2026 年初 MCP 突然“失宠”？
• MCP 被批评的 三大致命缺陷到底致命在哪？
• 为什么 CLI 反而像是 AI Agent 的“母语”？
• 如果你在做 Agent 平台/工具链，这波趋势对你意味着什么？

一、背景：2026 年初，AI 圈风向突变

如果你把 2025 年的 AI 工具生态比作“协议大炼钢”，那 2026 年初就是“钢厂突然停炉，大家回去打铁”。

看几个标志性事件，把这股风向转变钉得很死：

• Perplexity CTO Denis Yarats 公开宣布：从 MCP 转向 API/CLI。
• Y Combinator（YC）掌门人 Garry Tan 直接炮轰 MCP，态度非常不“中立”。
• 企业协作体系里，飞书/钉钉等一线产品“全面转向 CLI 思路”。
• 新一代 Coding Agent / 工具框架，比如 Claude Code、OpenClaw 等，开始走 CLI-first 路线（先把 CLI 打通，把 Agent 当“会用终端的人”来设计）。

你会发现：这里面既有创业公司、也有 YC 这种“投资风向标”，还有大厂产品体系。它不像一次技术口水战，更像一个生态集体对“工程现实”的投票。

一句话概括这种现实： 当 Agent 真开始干活、开始接入几十个工具、开始跑在真实成本和真实运维里时，“重协议”最先暴露的不是美学问题，而是账单问题、调试问题、和组合能力问题。

二、MCP 的三大致命缺陷：问题不在“能不能用”，而在“越用越痛”

首先强调一点：批评 MCP 并不等于说它完全没价值。MCP 在一些“工具数量有限、环境相对可控、希望强类型约束”的场景里，确实能带来确定性。

但当你把 MCP 当成“通用工具连接层”，准备让它承载一线开发者和真实 Agent 工作流时，它会出现三类结构性问题。

缺陷 1：Token 通货膨胀与成本黑洞

MCP 的核心设计之一，是把工具的能力用结构化方式（通常是 schema）描述清楚，然后把这些描述交给模型。

听起来没问题，对吧？

问题是：它太“中心化”了。

当你的工具数量从 3 个变成 30 个、50 个、100 个时，MCP 的使用方式往往会变成：

1. 启动时把一堆工具的 Schema 统统塞进上下文
2. 模型在巨量 Schema 中“找工具、选工具、再调用”

于是你会得到一种非常熟悉的灾难：

• Schema 本身就很长
• 工具越多，Schema 越多
• Schema 越多，Token 越贵
• Token 越贵，还会挤占模型的“思考空间”

当工具很多（比如 50 个）时，光加载 Schema 就可能消耗 数万 Token。这不是危言耸听，我们可以用一个非常保守的算术直觉来感受：

• 假设一个工具的 Schema + 描述 + 示例 = 500~1000 Token（这已经算克制）
• 50 个工具：
  • 500 × 50 = 25,000 Token
  • 1000 × 50 = 50,000 Token

也就是说你还没开始干活，你已经先“买了”一车 Token。更尴尬的是，这些 Token 不是“有效推理”，而是“开机自检”。

就像你想拧一颗螺丝，结果工具箱要求你先背完《世界五金标准手册》才允许拿起螺丝刀。这就是所谓的 Token 通货膨胀：

• Token 越来越像“印钞”
• 工程成本像“通胀”一样飙升
• 最后你会发现：你不是在做 Agent，你是在做 Token 财务管理

缺陷 2：认证与鉴权碎片化

第二个问题更工程、更痛：认证与鉴权。

MCP 的链路通常是“模型 ↔ MCP 服务 ↔ 各个工具/服务”。当你接入多个外部系统时，你需要为每个系统处理：

• OAuth / Token / Refresh Token
• API Key 的分发与轮换
• 租户、权限、角色体系映射
• 本地/线上环境的隔离
• 密钥泄漏与审计

MCP 往往需要为每个服务重新搭一遍认证；而 CLI 可以直接复用系统级成熟认证（SSH、环境变量、本地 Config）。MCP 等于把几十年的 OS 级基建扔掉了，纯属重复造轮子。

CLI 世界里，认证/鉴权早就有一套成熟到“几乎没人愿意再发明一次”的机制：

• SSH：公钥/私钥、agent、跳板机
• 环境变量：AWS_ACCESS_KEY_ID、GITHUB_TOKEN 这种模式几乎成了事实标准
• 本地配置文件：~/.ssh/config、~/.gitconfig、~/.aws/credentials
• 系统权限模型：文件权限、用户组、sudo

这套体系的优势不在“优雅”，而在“真能跑”：

• 跑了几十年
• 经历过海量事故
• 有标准化工具链（审计、轮换、权限管理）

如果 MCP 让你对每个系统都重新做一遍认证，它不只是“麻烦”，它是把你从“使用成熟基建”，拉回到“每接一个系统就重新修一条路”。

在 Agent 时代，这种重复劳动会被放大：Agent 不是接 2 个系统，它往往要接 一整个企业或开发环境的工具集合。

缺陷 3：黑盒运行与丧失组合性

第三个问题，是很多一线开发者会直接“生理不适”的点：

• MCP 通常是 双进程
• 通过 JSON-RPC 通信

这带来两个后果：

3.1 调试体验：从“看日志”变成“看一坨 JSON”

当东西出问题时，你看到的可能不是：

• 某个命令失败
• 某行输出异常
• 某个 exit code 非 0

而是：

• 一大段嵌套 JSON
• 一堆 request/response 的结构
• 一堆你需要在脑内还原的状态机

对于“平台工程师”来说，这可能还算可接受；但对于一线干活的开发者，尤其是 C 端业务开发者，这意味着：你让他们用 Agent，结果他们要先学会当“协议抓包工程师”。

3.2 更致命：失去 Unix 哲学的“管道（Piping）”与链式组合

Unix 世界最迷人的地方，不是命令多，而是 组合：

• 一个命令做好一件事
• 用管道把输出喂给下一个命令
• 最后拼出一个你自己都没想到的工作流

比如：

# 从 git 日志里找某类提交，再统计作者分布
git log --pretty=oneline | grep "hotfix" | awk '{print $2}' | sort | uniq -c | sort -nr

CLI 的输出是文本（或可文本化的结构数据），所以“管道”成立。

但 MCP 的典型交互是：

• 模型发一个 JSON-RPC 请求
• 工具回一个 JSON-RPC 响应
• 再由模型决定下一步

这会让组合变得非常“粘稠”：

• 你不再是把工具组合起来，而是把协议流粘起来
• 组合点不是“stdout → stdin”，而是“某个 JSON 字段 → 某个 JSON 字段”
• 每次组合都像在写胶水代码

MCP 让系统变黑盒，也让工具丧失了可组合性。 而可组合性，恰恰是 Agent 时代最值钱的能力之一：

• Agent 需要把很多小能力串起来
• 串起来的方式必须低摩擦
• 低摩擦的本质就是：输出能自然成为输入

三、CLI 为什么是 Agent 的“母语”：不是复古，而是“最适合干活”

如果 MCP 的问题是“太重”，那 CLI 的优势就是“太轻”。但这里的“轻”不是功能少，而是工程摩擦少。

CLI 更像是 Agent 的母语。因为 Agent 已经足够聪明，不需要你把世界用 Schema 重新写一遍。 这其实包含三个层面的逻辑。

3.1 Agent 已经会看说明书：man、--help、README 就够了

过去我们喜欢 Schema，有一个潜台词：

• 模型很“笨”
• 不知道工具怎么用
• 所以我们要把工具能力写成一份“标准答案”塞给它

但到了 2026，这个前提正在变化。

更强的 Agent 能力意味着：

• 它可以自己读 --help
• 它可以自己读 man page
• 它可以自己读项目 README
• 它甚至可以通过试错理解输出结构

换句话说：你不再需要把工具“翻译”为死板的 JSON Schema；你只需要给它一个可探索的入口。

CLI 就是这种入口：

• tool --help 是天然的“即时文档”
• man tool 是更完整的“本地知识库”

Agent 读文档的成本，是 Token；

但它读的是用得上的那一段，而不是启动时把所有工具手册背一遍。

3.2 按需加载、用完即走：Token 额外开销极低

这点直接对冲 MCP 的“Schema 通胀”。

CLI-first 的思路往往是：

• 需要用工具时，再去看 --help 或 README
• 不需要用工具时，别把它塞进上下文

你可以把它理解为：

• MCP 倾向于“开机加载全家桶”
• CLI 倾向于“现用现装（更准确是现查现用）”

在 Token 成本越来越敏感、上下文窗口越来越宝贵的时代，这种模式会非常有优势。

3.3 输出是纯文本（或结构化文本），天然适配 LLM 的理解方式

一个经常被忽略的事实：

• LLM 本质上就是处理文本

CLI 的世界里，信息以文本形式存在：

• 日志是文本
• 错误信息是文本
• 代码 diff 是文本
• 配置文件是文本

甚至很多 CLI 已经天然提供结构化文本输出：

• JSON：--json
• YAML：--yaml
• 表格：--format table

例如：

# 让工具输出 JSON，再用 jq 做二次加工
some_tool list --json | jq '.items[] | {name, status}'

对于 Agent 来说，这种输出有几个特别现实的好处：

• 可读：即使不严格结构化，模型也能理解
• 可拼接：管道可以直接串
• 可审计：人类也能复核
• 可调试：exit code + stderr 体系成熟

所以 CLI 的“组合性”是杀手锏：CLI 不只是一个输入方式，更是一套可组合的信息流系统。

四、对比总结：MCP 像“重协议”，CLI 像“轻武器”

把上面的点收束一下，你会得到一个很清晰的对比表（偏工程视角）：

维度	MCP（常见实践）	CLI-first（常见实践）
上下文成本	启动时加载大量 Schema，Token 成本高	按需读取 --help/man/README，Token 开销低
工具规模扩展	工具越多，Schema 越重	工具越多越“自然”，因为接口统一（命令 + 输出）
认证/鉴权	每个服务都要重新做一遍集成	复用 OS/CLI 生态：SSH、env、config
调试体验	JSON-RPC 链路长，易黑盒	exit code + stderr + log，问题暴露直接
组合能力	组合点在协议层，粘稠	管道、重定向、脚本天然组合
适配对象	更偏平台化、规范化组织	更偏一线开发者、快速迭代、真实工作流

如果你愿意带点幽默，那可以这么理解：

• MCP 的愿景像是：把世界写成一份“标准接口说明书”，然后让模型按规程办事
• CLI 的现实像是：模型是个聪明的实习生，你给它一台装了工具的电脑，它会自己翻说明书、自己试命令、自己串流程

当模型能力上来后，“过度封装”的副作用会越来越明显。

有时候封装不是为了减少复杂度，而是为了把复杂度搬家：复杂度从“用户操作”搬到了“协议设计、Schema 管理、上下文账单、鉴权集成和调试链路”。

搬完之后发现：复杂度没少，成本反而更高。

五、终局思考：AI 时代，连接大于协议

**AI 时代，连接大于协议。**MCP 是大厂企图建立壁垒的“重”协议，而简单粗暴的 CLI 才是真正在一线干活的开发者最爱的“轻”武器。

这里的“重”和“轻”，不是道德判断，而是工程取舍：

• 重协议倾向于：统一、规范、强约束、平台化、可治理
• 轻武器倾向于：能用就行、组合第一、调试友好、边界清晰

在 2026 年初这波转向里，很多人其实是在做一个很朴素的选择：

• 与其让 Agent 学会一个“专门为它设计的协议世界”
• 不如让 Agent 直接进入一个“人类已经使用了几十年的工具世界”

这也是 CLI-first 的底层哲学：

1. 世界已经有接口（命令行就是接口）
2. 世界已经有认证（OS/SSH/env/config）
3. 世界已经有组合方式（管道、脚本）
4. 世界已经有调试方式（日志、stderr、exit code）

Agent 只需要学会“如何使用”，而不是让你再发明一套“如何描述”。

六、如果你正在做 Agent 工具链：一些更现实的建议

6.1 先问自己一句：你需要的是“协议”，还是“连接”？

• 如果你的问题是“治理”和“标准化”，协议可能有价值
• 如果你的问题是“能串起来干活”，连接比协议重要

6.2 不要把 Schema 当成默认方案

Schema 不是原罪，但把 Schema 当成默认启动项往往会带来 Token 成本灾难。

更好的策略可能是：

• 只在需要强约束时引入 schema
• 其他场景让 Agent 自己探索 CLI

6.3 把可组合性当成第一原则

当你设计工具接口时，优先考虑：

• 输出能否被下一个工具直接消费？
• 能否提供 --json 这类结构化输出？
• 是否能稳定输出（避免“为了好看加 emoji/颜色/动态进度条”导致解析困难）

6.4 把调试体验当成“产品功能”

工程世界里，80% 的时间在调试。

• CLI 的 stderr/exit code 体系是成熟的
• JSON-RPC 的链路调试则需要额外工具和心智

如果你的目标用户是“一线开发者”，调试体验会直接决定“用不用”。

结语：也许我们从一开始就误会了 Agent 需要什么

MCP 的出发点是好的：给模型一个规范的工具世界。

但当模型越来越强、上下文越来越贵、工具越来越多、工程系统越来越复杂时，规范可能不再是第一优先级。

真正的优先级变成了：

• 成本能不能扛住（Token 不要先烧掉一半）
• 权限能不能复用（别再造一遍 SSH/OAuth 轮子）
• 工作流能不能组合（管道与链式调用是生产力核心）
• 出问题能不能查（黑盒=慢死）

所以这波“从 MCP 回到 CLI”，看起来像复古，实际上可能是：

在 AI 时代重新发现了工程世界最朴素的真理：能连上、能跑、能调、能组合，才是硬道理。

如果你问我一句话总结：

MCP 像是在给 Agent 建一座豪华玻璃房；CLI 像是直接把 Agent 扔进工地，并告诉它：工具都在这，说明书在那，干活吧。