MCP 正在从“连接工具”变成“定义 Agent 应用边界”的协议

MCP 最早被很多人理解成“让大模型连接外部工具的协议”。这个理解没错，但已经不够了。最近 MCP 社区围绕 skills、apps、transport、conformance tests 的讨论，说明它正在变成更底层的东西：Agent 应用的边界定义方式。

这对开发者有实际意义。因为 Agent 应用一旦从玩具 demo 走向真实工作流，最大的问题不是“能不能接一个工具”，而是工具能力如何被发现、如何被描述、如何被审计、如何在不同宿主之间迁移。

为什么 Skills over MCP 值得看

Skills 的核心不是再发明一个插件市场，而是让能力描述更标准。一个 Agent 如果要调用某个能力，不能只知道“这里有一个函数”，还需要知道它适合什么场景、需要什么输入、会产生什么副作用，以及应该怎样更新。

这件事看起来偏协议，但它决定了未来开发者能不能复用能力。今天很多 Agent 项目最大的问题是强绑定：某个工具只适合某个客户端，某段提示词只适合某个模型，换个环境就散架。协议层如果能把能力发现和能力描述稳定下来，小团队会少造很多轮子。

MCP Apps 试图解决的是另一个问题：工具返回文本和结构化数据还不够，很多任务需要交互式 UI，比如图表、表单、设计画布、视频播放器。也就是说，Agent 不只是调用后端函数，还可能把一个可交互界面带进对话上下文。

这对个人开发者很有机会。过去做一个开发者工具，要自己解决认证、前端、分发、用户入口。未来如果 Agent 宿主成为新的入口，一个小工具只要能通过标准协议暴露能力和界面，就可能嵌入多个工作流里。

我的判断是：MCP 值得中度到重度关注，但不建议把生产系统完全押在尚未稳定的草案能力上。更务实的方式，是把 MCP 当成接口边界来设计：核心业务逻辑保持独立，MCP server 只是暴露能力的一层适配器。

如果你是独立开发者，最适合切入的不是做一个“万能 MCP 平台”，而是做垂直场景的小 server：代码仓库分析、财务表格处理、客服知识库、设计资产读取、日志诊断。越贴近真实工作流，越有价值。

MCP 的长期价值不在于它今天有多热，而在于它可能把 Agent 能力从单个应用里拆出来，变成可组合、可迁移、可审计的基础设施。这件事值得认真看，但不要用追热点的方式看。

参考：modelcontextprotocol GitHub discussions、modelcontextprotocol/ext-apps。