MCP的无状态核心与托管授权对集成团队意味着什么
Linux基金会的管理机制、无状态HTTP传输以及由身份提供方管理的授权功能，使得MCP能够用于企业集成。以下是具体变化之处。
模型上下文协议规范了人工智能代理如何接入周围系统，其作用类似于API曾经规范应用程序之间相互连接的方式。对于负责集成与IT运维的人员而言，两年来他们一直以旁观者的身份关注这一技术：它前景广阔、发展势头强劲，但目前仍更像是开发者工具，而非能获得架构审查委员会认可的正式技术标准。不过这种距离正在缩小。仅八个月时间，MCP就已跨越了三个关键节点，这些进展让人联想到2010年左右API管理的早期阶段，仿佛人工智能代理领域的类似发展正在重演。
八个月内的三大变化
中立的管理机制。2025年12月，Anthropic将MCP移交给了Agentic AI基金会。该基金会是Linux基金会旗下的专项基金，由Anthropic、Block和OpenAI发起，并得到谷歌、微软、AWS、Cloudflare以及彭博社的支持。这样一来，MCP不再受制于单一供应商的规划，而是处于类似Kubernetes和Node.js所依赖的那种公正的管理体系之下。
集中式授权机制。2026年6月18日，企业级管理授权（EMA）功能正式稳定上线。它用由身份提供商驱动的模型取代了传统的每台服务器单独授权界面，Anthropic、微软和Okta是首批采用该功能的机构。
无状态核心。2026年7月28日的版本是该协议诞生以来最大的规格修订，它用基于普通HTTP的无状态设计取代了原有依赖会话的状态型设计。
这些改动并非表面上的调整。每一项都消除了MCP未能被广泛用于实际生产环境的一个特定原因，对于那些以连接系统为职业而非开发AI演示的人而言，这些改动尤为重要。
简要定义
MCP是一种开放标准，规定了AI应用（例如基于大语言模型的智能体）如何查找并调用外部工具、读取外部资源以及与模型之外的系统交换上下文。它通过统一的接口替代了针对每个数据源的定制化集成方式。
简单对比一下：MCP在AI与系统之间的连接中扮演的角色，就如同REST和OpenAPI在应用程序之间的作用。集成系统本身保持不变，标准化的是AI客户端与MCP服务器所代表的服务之间的接口，这些服务可以是工单系统、CMDB、监控平台或内部数据库。
变化1：不再需要会话
在最初的两年里，基于HTTP的MCP表现得像许多实时协议一样。客户端连接后完成初始化握手，随后会收到一个会话ID，后续的所有请求都必须包含该ID。该会话将客户端绑定到创建它的那个服务器实例上。任何在负载均衡器后部署WebSocket服务的人都知道这带来的问题——要实现扩展，就需要使用粘性路由、共享会话存储，或者通过网关分析流量来找到负责处理该连接的单一实例。
2026-07-28版本的规范消除了所有这些内容。不再有初始化和已初始化的握手流程，也没有Mcp-Session-Id头部字段。相反，每个请求都会携带自身的协议版本、客户端身份信息及功能参数。因此任何服务器实例都能响应任意请求，粘性会话和共享会话存储也就不再是该协议所要求的。无服务器架构、多实例集群以及边缘路由的功能实现方式与普通HTTP API相同，因为从结构上来看，MCP已然变成了这样的形式。
没有协议会话，并不意味着应用程序就无状态了。当服务器确实需要在多次调用之间记住某些信息，比如正在进行的导出操作或耗时的修复任务时，它会遵循传统的REST做法：创建一个明确的标识符，然后由客户端在下次调用时将其作为普通参数传回。熟悉分页和任务状态端点的工程师能够识别这种做法，这是一种经过深思熟虑的选择，更适合用于负载均衡器，而非临时修补方案。
同一版本还加强了针对新功能的安全措施。客户端必须在授权响应中验证发件人身份，从而防止在多服务器环境中通过重定向进行会话劫持。此外，客户端还需指定令牌对应的服务器，从而堵住安全团队在多租户部署中指出的一个重大安全隐患。MCP现在首次有了正式的废弃政策，因此功能变更会遵循规范的生命周期，而非随意被移除。
变化2：由身份提供方管理访问权限
第二项变化与其说是与传输相关，不如说关乎在公司内部部署代理时所面临的日常繁琐问题。在第一代授权方式下，每位员工都必须为他们的AI客户端使用的每一台MCP服务器单独完成OAuth同意流程。当员工人数达到百人且内部工具有六七种时，这种入职流程便无法再扩展。安全团队也无法全面掌握谁连接了哪些系统，而且当有人调岗或离职时，也没有简便的方法来终止其访问权限。
EMA将授权决策交由公司的身份提供商处理。管理员可在身份提供商中一次性决定某组员工可以使用哪些MCP服务器。之后，当有人首次通过支持的客户端登录时，系统会自动授予访问权限，无需再出现同意提示，也无需进行额外设置。
Okta是首批支持该功能的身份提供商，它以自身的Cross App Access产品作为基础。该扩展基于开放标准的IETF规范Identity Assertion JWT Authorization Grant构建，并非Anthropic的专有技术。Anthropic通过共享的MCP层将此功能集成到Claude、Claude Code和Cowork中，而微软则直接在Visual Studio Code中实现了对该功能的支持。目前已支持该功能的服务器包括Asana、Atlassian、Canva、Figma、Granola、Linear和Supabase，而且这一列表还在不断扩展。
身份提供方在发出授权许可后便完成其职责。这一过程并不出现在工具调用本身之中，这一特点在安全审查中非常重要：身份提供方不会代理所有从人工智能系统流向其他系统的数据流，仅负责决定谁可以获得访问凭证。由于访问控制是集中式的，撤销权限也是如此。关闭某位离职人员的账户即可同时切断其与所有EMA连接的服务器，无需手动逐一撤销七项独立的集成权限。
企业SaaS平台的单点登录机制也是基于相同原理，因此会让人感觉十分熟悉，而这正是有意为之。安全团队无需为这些代理程序设计新的管理模型，只需沿用现有的管理方式即可。
这对使用自定义集成组件的团队意味着什么
许多集成与平台团队并未等待MCP成熟。当需要让内部AI助手读取Jira数据、在Slack上发帖或查询监控工具时，由于没有现成的标准方案，他们便自行编写了连接代码：为每个API定制封装层、设计专用的认证流程，并手动处理会话管理。虽然这样能实现功能，但每新增一个工具就需要重复开发类似的代码，每个系统都要重新设计认证机制，一旦有其他团队也需要相同功能，这种模式就会彻底崩溃。
新获得的成熟度反而带来了三方面的问题：
- 每个集成所需的自定义代码减少。基于普通HTTP的稳定、无状态传输方式使得团队无需再自行编写连接管理代码，可以像处理API网关后的REST API一样来操作MCP服务器。
集成工作本身并不会消失。无论使用何种协议传输请求，要在工单架构与监控架构之间转换数据、进行字段级处理、去重以及实现跨系统的业务逻辑，依然需要真正的工程能力。减少的是与之相关的辅助环节：数据传输、会话管理以及认证流程。这些措施虽能大幅减少大量重复性的工作，但无法完全取代集成工作。
换了个名称的旧话题
暂且不谈人工智能框架，这种情况其实很常见。大约二十年来，企业一直在构建或购买集成平台，以解决 API 之间连接时的各种问题：标准化的认证机制、集中式的数据映射与转换功能、无需为每对新系统编写定制代码就能应对不断增长的业务量，以及让安全团队能够统一查看和控制所有连接状态。
MCP在实现AI智能体连接方面似乎也在遵循相同的规范，只不过进展更快。基于普通HTTP的无状态核心架构使得MCP服务器能够像任何后端服务一样进行部署与扩展。由身份提供商驱动的授权机制，让授予和审计AI工具访问权限成为企业日常的访问控制工作。而Linux基金会提供的中立治理框架，使得采用该协议更像是选择Kubernetes，而非遵循某一家公司的路线图。
对于集成团队而言，这并不意味着智能体需要全新的操作指南。目前用于实现系统之间可靠、安全且大规模连接的那些方法，现在同样可以直接应用于智能体。协议层正在融入人们已经熟悉的基础设施体系中，而区分不同团队的关键则在于数据映射、治理执行以及两端系统之间的变更管理，这些一直都是最困难的部分。