就在一周多前,模型上下文协议发布了 2025-11-25 规范,庆祝其首个周年纪念日 [1]。这一宣布理所当然地充满胜利——MCP 已从一个实验性开源项目发展成为由 GitHub、OpenAI、Microsoft 和 Block 支持的基础标准,拥有数千个活跃的生产服务器 [1]。
\n\n但在庆祝的背后隐藏着一个更有趣的故事:这个规范版本不仅仅是一次演进;它是朝着企业就绪性的战略转变。在过去的一年里,MCP 作为开发工具取得了成功——一种在实验过程中将 AI 模型连接到数据和能力的便捷方式。2025-11-25 规范则不同。它引入了专门设计用于解决运营、安全和治理挑战的功能,这些挑战阻止了组织在企业规模上部署智能体-工具生态系统。
\n\n本文探讨新规范中的三个关键特性,并分析它们如何弥合我所说的\"生产差距\"——实验性智能体原型与企业级智能体基础设施之间的距离。
\n\n在深入技术特性之前,我们需要理解它们所解决的问题。数月来,组织一直在实验 MCP 驱动的智能体,通常在受控环境中取得了令人印象深刻的结果。然而,这些项目中的大多数仍然困在试点困境中,无法进展到生产部署。这些障碍不是技术上的突发奇想;它们是基本的运营要求:
\n\n| 要求 | \n为什么重要 | \n缺少什么 | \n
|---|---|---|
| 异步操作 | \n现实世界的任务,如报告生成、数据分析和工作流自动化,可能需要几分钟或几小时,而不是毫秒。 | \nMCP 连接是同步的。长时间运行的任务迫使客户端保持连接打开或构建自定义轮询系统。 | \n
| 企业身份验证 | \n组织需要集中控制哪些用户、智能体和服务可以访问敏感工具和数据。 | \n原始 OAuth 流程假设消费者应用模型。它缺乏对机器对机器身份验证的支持,也没有与企业身份提供商集成。 | \n
| 可扩展性 | \n不同的行业和用例需要自定义能力,而不会分裂核心协议。 | \n没有正式的机制来标准化扩展,导致专有的、不兼容的实现。 | \n
这些不是边缘情况;它们是生产系统的准入门槛。2025-11-25 规范直接解决了每一个问题。
\n\n也许最具变革性的新增功能是新的 Tasks 原语 [2]。虽然仍标记为实验性,但它从根本上改变了智能体与 MCP 服务器进行长时间运行操作的交互方式。
传统的 MCP 遵循经典的 RPC 模式:客户端发送请求,服务器处理它,服务器返回响应——所有这些都在单个连接内完成。这对于快速操作(如读取数据库行或检查天气 API)非常有效。但对于现实的企业工作流,它就崩溃了:
\n\n组织被迫构建自定义解决方案:作业队列、轮询系统、回调 webhook——所有这些都是非标准的,都增加了复杂性并降低了互操作性。
\n\n新的 Tasks 特性引入了标准的\"立即调用,稍后获取\"模式:
task 提示的请求。taskId。working、completed、failed)。taskId 检索最终结果。这不仅仅是语法糖。它为整个 MCP 生态系统提供了异步工作的统一抽象。智能体框架不需要知道它是在调用数据管道、部署系统还是文档处理器——异步模式都是相同的。
\n\n在生产环境中,这改变了一切。编排复杂工作流的 AI 助手可以:
\n\n这就是真正的自主智能体的运作方式。Tasks 原语使其在标准的、可互操作的协议内成为可能。
原始 MCP 规范包含 OAuth 2.0 支持,但它是基于消费者应用模式建模的(想想\"使用 GitHub 登录\")。该模型不适用于企业用例,在这些用例中,组织需要集中的身份管理、审计跟踪和基于策略的访问控制。2025-11-25 规范引入了两个关键更新来弥合这一差距。
\n\n第一个变化是用客户端 ID 元数据文档(CIMD) [3] 替换动态客户端注册(DCR)。在旧模型中,每个 MCP 客户端都必须向它想要使用的每个授权服务器注册——这在联合企业环境中是一个可扩展性噩梦。
\n\n使用 CIMD,client_id 现在是客户端控制的 URL(例如,https://agents.mycompany.com/sales-assistant)。当授权服务器需要关于此客户端的信息时,它从该 URL 获取 JSON 元数据文档。该文档包括:
这种方法创建了一个锚定在 DNS 和 HTTPS 中的去中心化信任模型。授权服务器不需要与客户端预先存在关系;它信任在 URL 上发布的元数据。对于拥有数十个智能体应用程序和多个 MCP 提供商的大型组织来说,这大大减少了运营开销。
\n\n第二个关键增加是通过 M2M OAuth 扩展支持 OAuth 2.0 client_credentials 流程。这使得机器对机器身份验证成为可能——允许智能体和服务直接与 MCP 服务器进行身份验证,而无需人工用户参与。
为什么这很重要?考虑这些企业场景:
\n\n这些都不涉及交互式用户。它们是需要持久、安全凭据来代表组织访问工具的自主服务。client_credentials 流程正是用于此用例的标准 OAuth 机制,它在 MCP 中的包含使无头智能体系统成为可行的。
对于大型企业来说,也许最具战略意义的特性是跨应用访问(XAA)扩展。这解决了困扰企业 AI 消费化的治理问题:不受控制的工具蔓延。
\n\n在标准 OAuth 流程中,用户直接向 AI 应用程序授予访问工具的同意。企业身份提供商(IdP)只能看到\"Alice 登录到 AI 应用\",而看不到\"Alice 的 AI 智能体现在正在访问工资系统\"。这创造了一个治理黑洞。
\n\nXAA 改变了授权流程,将企业 IdP 作为中央策略执行点插入。现在,当智能体尝试访问 MCP 服务器时:
\n\n这提供了对整个智能体-工具生态系统的集中可见性和控制。安全团队可以监控哪些智能体正在访问哪些工具,设置组织范围的策略(例如,\"未经人工审查,智能体不能访问 PII\"),并审计所有委托访问。它消除了影子 AI,并提供了受监管行业所需的合规性说明。
\n\n这些 OAuth 增强功能共同将 MCP 从开发便利工具转变为受治理的、可审计的集成层。组织可以:
\n\n第三个主要新增功能是引入正式扩展框架 [3]。这是协议本身的治理机制,允许社区在不分裂生态系统的情况下开发新能力。
\n\n每个成功的协议都面临这个困境:足够快地实现创新以跟上不断发展的用例,但足够谨慎地标准化以维持互操作性。移动太慢,社区就会构建分裂生态系统的专有扩展。移动太快,核心协议就会充满大多数实现不需要的小众功能。
\n\nMCP 的解决方案是一个结构化的扩展过程。新能力作为规范增强提案(SEP)提出,经过社区审查,可以逐步采用。扩展是有命名空间的并且清楚地标记,因此实现可以有选择地支持它们,而不会破坏兼容性。
\n\n对于企业来说,这至关重要。不同的行业有独特的要求:
\n\n正式扩展框架允许组织将这些能力开发为标准的、可互操作的扩展,而不是专有分支。这保留了 MCP 的核心价值主张——智能体-工具通信的通用协议——同时实现了生产使用所需的定制。
\n\n还有一个特性值得一提:带工具的采样 [3]。这允许 MCP 服务器本身充当智能体系统,能够进行多步推理和工具使用。服务器现在可以请求客户端代表它调用 LLM,从而实现服务器端智能体。
\n\n为什么这很强大?它实现了组合式智能体架构。高级智能体可以委托给专门的 MCP 服务器,这些服务器本身使用智能体推理来完成复杂的请求。例如:
\n\n这种嵌套的、分层的方法是真正的自主系统将如何扩展的方式。通过使其成为标准协议特性而不是自定义实现,MCP 为丰富的专业化、可组合智能体生态系统提供了基础。
\n\n2025-11-25 MCP 规范不是激进的重新设计;它是一组有针对性的增强功能,直接解决了阻止企业采用的障碍。通过引入:
\n\n该规范弥合了生产差距——实验性原型与可扩展、安全、企业级系统之间的距离。
\n\n这是 MCP 从一个有前途的开发工具转变为企业基础设施基础部分的时刻。一直在等待\"生产就绪\"信号的组织现在有了这些信号。功能已经具备。治理机制已经具备。安全模型已经具备。
\n\n智能体 AI 的下一阶段将不是由华而不实的演示来定义,而是由深度集成到企业工作流中的自主系统的安静、可靠、大规模运营来定义。2025-11-25 MCP 规范是使这一未来成为可能的技术基础。
\n\n对于评估是否投资基于 MCP 的基础设施的技术领导者来说,计算已经改变。这不再是一个实验性协议;它是一个生产标准。现在采用它、在其上构建智能体生态系统并为其持续演进做出贡献的组织将定义未来十年的企业 AI。
\n\n参考文献:
\n\n\n\n[2] Model Context Protocol. (2025, November 25). Tasks. Model Context Protocol Specification.
\n\n\n\n\n\n", "source_hash": "sha256:ea07631d24ec71a2eeb27320d3216318879d24370148bc466f28b99355798962", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T02:04:31.825358+00:00" }