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 <host> -h
uxc <host> <operation_id> -h
uxc <host> <operation_id> key=value
uxc <host> <operation_id> '{...}'

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

在这套映射里，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 对工具的调用体系，不会靠一个协议就能解决的，需要时间来拼装演化。