MCP 发布一周年回顾：从 17 个 SEP 看 MCP 协议如何重塑 AI Agent 生态

MCP（Model Context Protocol，模型上下文协议）1.0 版本规范预计于 2025 年 11 月 25 日正式发布，刚好一周年。过去一年中，MCP 从 Anthropic 发布的一项实验性规范，逐步发展为连接 AI Agent 与外部系统的标准协议。本文深入分析 1.0 版本中的 17 个 SEP，探讨其在 MCP 架构、安全、能力、传输、治理等方面的技术设计逻辑及生态影响，也算是回应了我在四月份的文章 《MCP 的应用场景，其实是一个巨大的赚钱机会》中提出的关于持久连接与状态管理、安全性以及工具对上下文资源过度占用等问题。

欢迎订阅合集 AI 冷思考：个人在 AI 狂欢下的冷思考，聚焦 AI 工程化、Agent Infra 产品、效率型 AI 工具和人机协作话题，寻找可持续的产业价值。

SEP （Specification Enhancement Proposal，规范增强提案）是 MCP 社区的一种设计文档机制，用于提出、讨论和记录对 MCP 协议或其流程的重大新特性或变更建议。

治理层面

在过去的一年里，MCP 的发展主要由核心维护者（主要是 Anthropic）驱动，这种中心化的模式在初期效率很高，但随着生态的爆发，瓶颈也随之而来，这次更新，首先解决的时治理结构去中心化的问题。

治理结构的去中心化（SEP-1302 和 SEP-1630）

通过 SEP-1302 ，MCP 确立了工作组和兴趣组的机制，这不仅仅是个管理形式的变更，更意味着技术规范的产出从官方发布变成了社区集思广益。比如后面会提到的工具命名规范（SEP-986），就是经历了激烈的社区讨论后达成的共识，这种机制吸纳了来自各个领域的安全研究员和开源大佬的智慧，确保了协议不再是某一家公司的后花园。

配合 SEP-1630 的 SDK 分级系统，社区开发者有了更清晰的指引，无论是选择技术栈，还是贡献代码，都有了明确的标准。

安全问题

随着企业开始在内网甚至公网部署 MCP Server，安全问题成了悬在头顶的达摩克利斯之剑，这次 SEP 中考虑了多个方面的安全问题。

解决 N x M 的信任黑洞（SEP-991）

当你有 N 个模型客户端和 M 个数据源时，传统的做法是两两配置信任关系，这在数学上是指数级灾难，SEP-991 引入了 Client ID Metadata Documents (CIMD)。

简单来说，这套机制利用了现有的 DNS 和 HTTPS 信任体系，客户端不再需要手动去每个服务器注册，而是扔出一个 HTTPS URL 作为身份证，只要服务器信任 claude.ai 这个域名，它就能自动信任该域名下挂载的元数据，这意味着，企业可以通过白名单机制，自动放行来自特定域名的所有客户端，极大地降低了运维成本。

最小特权与渐进式授权（SEP-835）

以前的 Agent 启动时，往往一次性要求所有权限：我要读文件、要联网、要执行代码。用户要么闭眼选择全授权通过，要么直接拒绝导致任务失败。

SEP-835 引入了渐进式授权（Progressive Authorization），现在的流程变成了：Agent 先以最低权限启动（比如只能聊天），当它发现需要读某个文件时，Server 会拦截请求并返回 401，告诉客户端「我需要文件读取权限」，这时候客户端再弹窗询问用户，这种模式既符合最小特权原则，又避免了用户面对一堆权限申请时的心理压力。

防御「工具命名」攻击（SEP-986）

安全研究员 Xiangfan Wu 发现，如果工具名包含特殊字符，可能会诱导 LLM 生成恶意代码，甚至搞垮解析器，下面是常见的攻击向量：

• 解析器漏洞： LLM 通常会生成结构化的输出（如 JSON 或 YAML）来调用工具。如果解析器在处理包含特殊字符的工具名称时存在漏洞，恶意输入可能导致缓冲区溢出、代码注入，甚至拒绝服务 (DoS) 攻击。

• LLM 幻觉与代码注入： 特殊字符和特定格式的组合可能会诱导 LLM 偏离预期的输出格式，生成意想不到的、恶意的代码片段，这些片段可能会在下游系统中被执行。

• 跨站脚本 (XSS) 和其他注入： 如果工具名称被用于生成 HTML 报告或日志记录，未经净化的特殊字符可能导致 XSS 攻击或其他形式的注入。

SEP-986 强制规定工具名长度限制为 64 字符，且只允许字母数字，这种在协议层面的输入验证（Input Validation）和清洗（Input Sanitization），是最有效的防御策略之一，它直接从根源上消除了大多数可能的攻击载荷， 强制使用简单的字母数字字符集，使得解析过程变得简单且鲁棒，大大降低了引入解析器漏洞的风险。

物理隔离的信任边界（SEP-1036）

在银行转账、企业 SSO 登录等高敏感场景，我们甚至不能信任 Agent 客户端本身，SEP-1036 引入了 URL 模式，允许 Server 指示用户在系统默认浏览器中打开一个受信任的 URL 来完成交互， 这实际上是将敏感的凭据交换（比如输入密码、2FA）移出了 Agent 的控制范围，利用浏览器成熟的沙箱机制来保障安全。

企业 IdP 的兼容性（SEP-985）

在实际的企业环境中，不同的身份提供商（IdP）可能对 OAuth 规范的支持程度不一，SEP-985 引入一个元数据回退机制，确保即使在某些 IdP 未能完全遵循最新或特定 RFC 标准的情况下，MCP 协议依然能可靠地解析受保护资源的元数据，这大大降低了企业部署的门槛，使得模型能够更顺畅地访问现有的企业基础设施。

本地安全防御(SEP-1024)

随着 AI 应用本地化部署的增加，尤其是一键安装包的流行，供应链攻击的风险也随之升高。攻击者可能通过篡改安装包或利用安装过程中的漏洞来损害本地系统。SEP-1024 侧重于强化本地部署环境的安全态势，提出了一套标准化的安全防御措施和验证流程，要求在执行任何一键安装操作前，对所有组件进行严格的完整性验证和沙盒隔离，旨在从源头阻断潜在的供应链攻击，确保本地服务器环境的安全性。

让 Agent 更聪明

安全是地基，而能力类的 SEP 让 Agent 能干更复杂的活。

异步任务支持（SEP-1686）

目前的 LLM 都有上下文和推理时间的限制，工具调用通常要求秒级返回，但企业里很多任务长耗时的，比如视频渲染、大数据 ETL 或者跑一个复杂的编译。

SEP-1686 引入了 Task 资源，支持立即调用，稍后获取（Call-now, fetch-later）模式，客户端调用后拿到一个 Task ID，然后通过轮询或订阅来等结果，这一改动，让 MCP 为构建那种能跑好几天的长程 Agent 任务铺平了道路。

递归采样（SEP-1577）

这可能是最有趣的一个更新，SEP-1577 增强了采样（Sampling）功能，以前都是 Client 问 Server，Server 被动干活，现在 Server 也可以反过来请求 Client 调用 LLM。

比如一个代码审查 Server，它在读代码时发现一段逻辑看不懂，它可以主动向 Client 发起请求：「请解释这段代码，顺便帮你准备好了运行单元测试的工具」，模型在生成解释时，可以直接调用这个测试工具来验证自己的猜想，这种机制，让 Server 拥有了引导模型注意力的能力，整个系统的推理上限被大大拔高了。

改善人机交互流程（SEP-1330 和 SEP-1034）

Agent 的交互并不总是全自动的，很多时候需要人在中间确认， 以前为了在 UI 上显示好懂的中文名称（比如「开发环境」而不是 env_dev），MCP 使用了非标准的 enumNames 属性，SEP-1330 废弃了这种歪门邪道，转而使用标准的枚举 Schema（如 oneOf 结合 const 和 title ），这意味着未来任何支持标准 Schema 的前端库，都能自动渲染出漂亮的下拉菜单。

而 SEP-1034 允许自定义默认值，对于那些需要多步配置的复杂 Agent（比如数据库连接），这一特性极大地降低了用户的使用成本。

智能的错误处理机制（SEP-1303）

在模型执行任务时，常因提供的参数错误或格式不正确而导致任务失败，SEP-1303 引入了一种智能的错误处理机制，它建议将详细的、结构化的验证错误信息（而不仅仅是通用的失败消息）作为执行结果返回给模型本身，模型可以利用这些具体的错误反馈，识别错误的根源（例如，哪个参数缺失、哪个字段格式不正确），从而自动调整其参数或调用序列，进行自我修正并重新尝试执行任务，显著提高了任务的成功率和模型的自主纠错能力。

自定义图标标识（SEP‑973）

SEP‑973 允许 MCP 服务器在其元数据（如服务器、资源、工具）中定义 icons 字段，从而为这些服务提供自定义图标标识。该提案明确规定：

• HTTP 传输的 MCP 服务器必须将图标资源托管在与服务器相同的域或主机下。

• STDIO（本地进程）传输模式允许使用 file:/// URI 指向本地图像资源。

引入可选图标（非强制项）这一元素，帮助客户端更直观地展示服务器及其服务，从而改善工具整合与用户体验。

我认为的重要改进

适配 Serverless（SEP-1699）

MCP 推荐用 SSE（Server-Sent Events）做传输，这玩意儿在本地跑很爽，但在云上就是噩梦，AWS Lambda 或 Cloudflare Worker 这种 Serverless 平台最讨厌长连接，经常是一超时就给你掐断。

SEP-1699 专门为了解决这个问题，引入了基于轮询的 SSE 模式，并定义了服务器主动断开连接的协议流程。Server 可以在超时前通知 Client 断开，Client 收到后可以利用 Last-Event-ID 发起新连接继续请求，这意味着我们终于可以用极低的成本在 Lambda 上托管 MCP Server，享受自动扩缩容的红利，而不用担心连接中断导致的状态丢失。

规范 JSON Schema 标准（SEP-1613）

如果你同时写过 MCP 的 Python Server 和 Go Client，大概率被 JSON Schema 的验证问题折磨过，因为 JSON Schema 规范本身在不断更新（如 draft-07 之后有 2019-09 和 2020-12 等版本）。Pydantic V2 旨在支持更新、更现代的规范特性，这可能导致其生成的 schema 包含旧验证器无法识别的新关键字或结构，许多依赖 Pydantic 或使用其生成的 JSON Schema 的下游系统或工具可能只支持较旧的 draft-07 标准，当 Pydantic 生成的 schema 偏离此标准时，这些旧验证器就会失效， 导致同一个工具定义，在这里能跑，换个环境就报错。

SEP-1613 正式将 2020-12 版本确立为默认版本，它还引入了 unevaluatedProperties 等关键特性，让复杂的嵌套数据验证有了严谨性。从此以后，终于可以在代码运行前就通过静态分析捕获错误，而不是等到 Agent 运行时才发现参数传错了。

数据载荷的解耦（SEP-1319）

以前的 MCP 协议设计有点面向过程，请求的数据载荷（Payload）直接写死在 RPC 方法里。SEP-1319 提议将这些载荷提取为独立的类型定义，如果未来 MCP 要支持 gRPC 或者二进制流传输，这些独立的数据模型可以直接复用，不需要重写协议定义，这就是典型的「为变更而设计」。