演进动态与选型建议

2025-06-18，MCP 规范发布稳定版，并进入独立仓库做版本化管理；此后协议与生态仍快速演进。作为收尾章，本章梳理值得关注的动态，回答"我的项目到底要不要上 MCP"，并给出架构分层与学习路线。

规范与生态动态

稳定版之后，MCP 转入 modelcontextprotocol 独立仓库，以"规范版本号"方式迭代，客户端/服务器按 spec 版本对齐行为。值得关注的几个方向（均处于演进中，细节以官方文档为准）：

1. 版本化规范：协议改动可追踪，SDK 随之跟进，升级前先看对应版本的变更说明；
2. 服务器注册表（registry）探索：官方在探索服务器的发现与分发机制，试图让"找服务器"像装包一样简单，目前仍在草案/实验阶段；
3. 扩展点原语：sampling（服务器请求模型补全上下文）、roots（客户端向服务器声明可用根路径）等原语为复杂场景预留，多数入门项目用不到。 生态侧：官方参考服务器仓库持续扩充，云厂商与主流 IDE/Agent 框架陆续原生支持 MCP。对使用者，追踪 modelcontextprotocol.io 官方规范与 SDK changelog 就够，不必追逐碎片信息。

何时值得引入 MCP

• 同一组工具要给多个宿主/多个模型应用共用（写一次、处处配）；
• 工具数量多、要按"能力单元"独立开发与部署，或需要团队各自维护再统一接入；
• 需要把"工具 + 资源 + 提示词"一起暴露给智能体，而不只是函数调用；
• 希望享受生态：直接接入官方/社区现成服务器（见第 16 章）。

何时不必引入

• 单应用内部两三个函数：直接 function calling 更简单，没有跨进程、跨宿主的诉求；
• 工具只在一个代码库里、没有复用需求：多一层 MCP server 进程只会增加调试与部署成本；
• 需要强类型、紧耦合的内部调用链：协议边界不适合你时，别为了"时髦"而用。 判断标准一句话：有"多处要同一种能力"才有协议的价值，否则裸函数调用即可。

架构建议：能力分层

MCP 只是其中一层，成熟的智能体应用可按下述四层组织：

层次	职责	对应技术
模型层	推理、生成、工具调用意图	各类大模型
应用编排层	agent 循环、记忆、任务规划	自研或 agent 框架
MCP 接入层	把工具/数据/资源统一暴露与接入	MCP server + client
互操作层	智能体之间的协作与委派	A2A（按需引入）
层与层之间用协议解耦：模型可换、工具可增、上层可对接其他智能体，改动都被限制在单层内。

落地顺序建议

1. 先本机 stdio 打通（第 14 章），验证工具质量与对话效果；
2. 再上 HTTP + 鉴权（第 15 章），服务化之后团队共享；
3. 容器化并补监控：日志、链路追踪（第 18 章）；
4. 最后按需加 A2A 互操作层（第 19 章），先小范围试点再推广。 每步都小步验证，避免一次性引入过多新链路导致问题难定位。

应对快速演进

• 锁定 SDK 版本，升级前读 changelog 与对应规范版本变更说明；
• 生产环境的服务器用独立账号、最小权限并保留审计日志；
• 订阅 modelcontextprotocol.io 官方规范与示例仓库的更新；
• 别把某篇第三方教程的写法当标准，遇到分歧回到官方文档验证。

给读者的下一步路线图

1. 回看 16 章建立概念（原语、生命周期、传输），再用 710 章写自己的第一个 server；
2. 用 1113 章让客户端与宿主真正用起来，1415 章完成文件系统与 HTTP 两个实战；
3. 带着第 16~18 章的生态、安全与调试意识接入真实服务器；
4. 动手做端到端小项目：一个 FastMCP server + 一个宿主配置 + 一次远程部署；
5. 持续跟进 modelcontextprotocol.io 官方规范与 SDK 文档，对照本章决策表判断新需求该不该上 MCP。 小结：MCP 于 2025-06-18 进入稳定、版本化演进，registry 与扩展原语仍在路上；"多处复用同一种能力"才值得引入，单应用简单工具直接用 function calling；架构上把模型、编排、MCP 接入、A2A 互操作分层，就能在协议快速演进中保持项目稳定。