从 MCP 到 SKILL（II）：把调用层补齐

我在《从 MCP 到 SKILL：关于 Agent 扩展机制的思考》里提过一个很直觉的分工：

• MCP 更像“标准插头”，解决连接标准化
• SKILL 更像“操作手册 + 工作流”，解决编排、状态与闭环

当时我以为，这两者拼起来就会很自然。

但真把它落到工程里，很快会发现：缺的不是理念，而是最后那一段“可执行、可迁移、对 Agent 友好”的、适合写进 SKILL 的通用调用入口。

为什么需要通用调用入口

首先没有一个通用的、SKILL 友好的 MCP CLI。理论上可以用 curl 调 MCP HTTP，但对 Agent 来说参数、认证、错误处理都太复杂，稳定性差。于是很多服务放弃了 MCP，直接退化成“纯 REST 接口”。

SKILL 里用 curl 来演示当然能跑通，但这种方式可维护性差：接口变化 AI 无法感知，接口数量多了也很难展示与发现。

所以问题变成了：SKILL 和 CLI 配合得很好，但不可能每个服务都自己带一个高质量 CLI。那能不能有一个通用 CLI？

MCP 的 schema 本身已经足够标准了，如果我们把“CLI 的渐进式披露”复刻出来，这个通用 CLI 就能成立。

于是就有了 uxc。

uxc 补的是哪一层

uxc 的定位是“统一协议调用 CLI”（Universal X-Protocol CLI），通过渐进式披露，把 schema 接口变成可交互的 CLI。

MCP 以及其它协议的 schema 往往很大。如果你把它一次性塞进 Agent 的工具上下文，很容易撞上上下文预算。而 uxc 的模式是：

uxc <host> -h
uxc <host> <operation_id> -h
uxc <host> <operation_id> key=value
uxc <host> <operation_id> '{...}'

这让能力发现变成按需加载：只有在需要的时候才展开某个 tool 的输入输出。

为了方便 AI 使用，还可以通过 uxc link 把 endpoint 固化成稳定的命令名。

比如：

uxc link notion-mcp-cli https://mcp.notion.com/mcp
notion-mcp-cli -h

于是后续 SKILL 里就可以像调用专用 CLI 一样调用：

notion-mcp-cli notion-search query=ai

另外 uxc 默认输出结构化的 JSON envelope，成功 / 失败的 shape 相对固定，Agent 更容易做自动化判断。认证上，uxc 用 credential + binding 把 endpoint 与凭证的匹配规则外部化，这些细节不必散落在提示词里。

现在我更倾向的三层分工

我目前更倾向的分层是：

• MCP：标准化能力描述和服务
• uxc：统一的调用层
• SKILL：把调用嵌入可闭环的工作流

这三层都齐了，MCP 和 SKILL 就可以真的“拼起来”，并且拼出来的东西是可迁移、可维护的。