MCP vs CLI 不是对立问题：真正缺的是调用层

最近刷到几篇关于 MCP 和 CLI 关系的文章。
看完后的感觉是：把这两个东西放在“二选一”的框架里讨论，本身就是个错位。MCP 和 CLI 根本不在一个层面上。

MCP（Model Context Protocol）解决的是能力如何标准化暴露。
CLI 解决的是能力如何被调用。

一个是能力面。
一个是调用面。

现在的问题不是 MCP 能力暴露这层出了问题，而是它的调用机制上，一次性把所有工具塞进上下文的机制上出了问题。

1. 上下文预算很快被工具 schema 吃掉。
2. 调用结果直接回填上下文，缺少中间处理层，没有组合性。

于是有人得出结论：CLI 比 MCP 好。

但这其实是一个假象。真正的问题是——能力面（API）和调用面（Agent）之间，需要一个调用层把二者解耦，渐进式披露能力，并且提供可组合性。

最近做 uxc，我反而更确定了这点。

uxc 支持任何带 schema 的接口（MCP / OpenAPI / JSON-RPC），核心不是“换协议”，而是把接口变成一个可渐进披露的 CLI：

uxc -h
uxc -h
uxc key=value
uxc '{...}'

能力发现不再是“一次性注入”，而是按需展开。

在这套映射里，MCP 目前仍然是最适合 Agent 的能力暴露协议：

1. schema 暴露是协议强制的，发现路径稳定。
2. description 通常更完整，语义密度更高，模型更容易对齐。

大家经常拿 gh 和 GitHub MCP 比，我自己也比过。
但这个对比其实不太公平。gh 存在时间长，有语料优势，模型天然会用。

你做一个新的服务+ CLI，有这种语料红利吗？
如果没有一个通用调用层，你最后还是会回到老问题：

1. 每个服务维护一套自己的 CLI。
2. 接口一变就要发版迁移。
3. 用户安装和管理成本持续上升。

这和 Agent 时代想要的“能力可组合”是反方向的。

所以我不觉得“CLI 胜出”意味着“MCP 失效”。

更合理的分工是：

MCP 负责标准化能力暴露
CLI 负责调用调度
SKILL 负责任务流程

各层负责各层的事情，互相配合。

uxc 0.5.x 这次发布，我主要补了两件基础能力：

1. API key 管理接入 1Password。
2. daemon 模式自动维持 MCP 长连接和 stdio 进程，长期不用自动清理。

然后给了一个 playwright-mcp-cli 的 SKILL 示例（uxc/skills/playwright-mcp-skill）。

这个例子刚好能把三层关系讲清楚：

1. MCP 暴露 Playwright 的能力 schema。
2. uxc 把 endpoint 固化成稳定命令入口，渐进式披露。
3. SKILL 把工具说明和任务流程补齐。

如果要做技术决策，可以简单这么想：

1. 有远程服务想让 Agent 用，需要标准化 API → MCP 是很自然的选项。
2. 有本地程序需要持续交互状态 → MCP stdio 比 daemon+CLI 更干净。
3. 纯一次性命令、不需要状态 → 直接 CLI 就够。

先想清楚三层，再选协议。

去年大家一窝风吹 MCP，我说有点过了。 现在一窝风踩，我又觉得踩过了。

AI 对工具的调用体系，不会靠一个协议就能解决的，需要时间来拼装演化。

1. 从 MCP 到 SKILL：关于 Agent 扩展机制的思考 http://t.cn/AXcWwxfo
2. 从 MCP 到 SKILL（II）：把调用层补齐
http://t.cn/AXcWwRfw