抛弃 MCP，拥抱 CLI？
AC Rocky约 10 分钟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 的使用方式往往会变成：
启动时把一堆工具的 Schema 统统塞进上下文 模型在巨量 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： --jsonYAML： --yaml表格： --format table
例如：
# 让工具输出 JSON，再用 jq 做二次加工
some_tool list --json | jq '.items[] | {name, status}'
对于 Agent 来说，这种输出有几个特别现实的好处：
可读：即使不严格结构化，模型也能理解 可拼接：管道可以直接串 可审计：人类也能复核 可调试：exit code + stderr 体系成熟
所以 CLI 的“组合性”是杀手锏：CLI 不只是一个输入方式，更是一套可组合的信息流系统。
四、对比总结：MCP 像“重协议”，CLI 像“轻武器”
把上面的点收束一下，你会得到一个很清晰的对比表（偏工程视角）：
--help/man/README，Token 开销低 | ||
如果你愿意带点幽默，那可以这么理解：
MCP 的愿景像是：把世界写成一份“标准接口说明书”，然后让模型按规程办事 CLI 的现实像是：模型是个聪明的实习生，你给它一台装了工具的电脑，它会自己翻说明书、自己试命令、自己串流程
当模型能力上来后，“过度封装”的副作用会越来越明显。
有时候封装不是为了减少复杂度，而是为了把复杂度搬家：复杂度从“用户操作”搬到了“协议设计、Schema 管理、上下文账单、鉴权集成和调试链路”。
搬完之后发现：复杂度没少，成本反而更高。
五、终局思考：AI 时代，连接大于协议
AI 时代，连接大于协议。MCP 是大厂企图建立壁垒的“重”协议，而简单粗暴的 CLI 才是真正在一线干活的开发者最爱的“轻”武器。
这里的“重”和“轻”，不是道德判断，而是工程取舍：
重协议倾向于：统一、规范、强约束、平台化、可治理 轻武器倾向于：能用就行、组合第一、调试友好、边界清晰
在 2026 年初这波转向里，很多人其实是在做一个很朴素的选择：
与其让 Agent 学会一个“专门为它设计的协议世界” 不如让 Agent 直接进入一个“人类已经使用了几十年的工具世界”
这也是 CLI-first 的底层哲学：
世界已经有接口（命令行就是接口） 世界已经有认证（OS/SSH/env/config） 世界已经有组合方式（管道、脚本） 世界已经有调试方式（日志、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 扔进工地，并告诉它：工具都在这，说明书在那，干活吧。
-- END --
推荐阅读