这几天如果只盯着 Claude Opus 5、GPT-5.6、Kimi K3 这些模型新闻，很容易漏掉 Anthropic 另一件更底层的事。
MCP 协议迎来了一次大改。
社区里有人把它称为 MCP 史上最大更新。这个说法不算夸张。因为这次改的不是某个 SDK 的小功能，也不是多接了几个工具，而是在动 MCP 的底层交互方式：Session 被移除，initialize 握手被废弃，核心协议走向无状态，Extensions 机制变得更成熟，MCP Apps 也开始从概念走向应用形态。
换句话说，Anthropic 正在把 AI Agent 和外部工具之间的“插座标准”重新改一遍。
这件事短期看是协议更新，长期看可能是 AI Agent 生态里更重要的基础设施变化。
一个强模型会被下一个强模型追上。
但一个被广泛采用的连接标准，一旦进入 Claude、Cursor、Dify、n8n、企业内部工具、云服务和各种 MCP Server，就会变成一种复利式壁垒：后来者想绕开它，就必须在每一个工具接入点重新适配。
这也是为什么今天值得单独写 MCP。
它不是一个冷冰冰的协议名。它更像 AI Agent 时代的 USB-C。
一、先说人话：MCP 到底解决了什么问题？
过去做 AI Agent，最麻烦的不是让模型回答问题，而是让模型安全、稳定、可控地调用外部工具。
比如你想让 Agent 帮你完成一个真实任务：
- 读 GitHub 仓库；
- 查 Notion 文档；
- 拉取数据库里的订单数据；
- 调用浏览器验证页面；
- 创建工单；
- 读取本地文件；
- 查询 CRM；
- 生成报告并发给团队。
如果没有统一协议，每接一个工具，就要单独写一套适配逻辑。
GitHub 一套，Notion 一套，数据库一套，浏览器一套，内部 API 又一套。不同工具的鉴权方式、请求格式、返回格式、错误处理、权限边界都不一样。
这就导致一个很现实的问题：模型本身可以替换，但工具层越接越乱。
MCP 要解决的，就是这件事。
它把模型和工具之间的连接抽象成一套标准：工具暴露能力，Agent 按协议发现能力、调用能力、读取结果。这样，模型不需要理解每个工具背后的复杂实现，只需要按照 MCP 的方式和工具沟通。
你可以把 MCP 理解成三层：
| 层级 | 它负责什么 | 对开发者的意义 |
|---|---|---|
| MCP Host | Claude Desktop、Claude Code、IDE、Agent 平台 | 负责承载用户与 Agent 的交互 |
| MCP Client | Host 内部与工具通信的客户端 | 负责连接不同 MCP Server |
| MCP Server | GitHub、数据库、文件系统、浏览器等工具能力 | 把外部工具包装成 Agent 能调用的能力 |
这也是 MCP 的真正价值：它不是让某一个工具更好用，而是让工具接入变成可复用的标准件。
二、这次最大的变化：MCP 从“会话式连接”走向“无状态连接”
这次更新最值得关注的关键词，是 stateless，也就是无状态。
以前很多人理解 MCP，会把它想成一段持续会话：
Agent 连上某个 MCP Server，双方建立 Session，完成 initialize 握手，然后在这段连接关系里持续交互。
这种模式在本地桌面环境里很好理解。比如 Claude Desktop 连本地文件系统、连本地工具，状态挂在本机进程里，问题不大。
但一旦 MCP 走向云端、多用户、企业部署、网关化和平台化，会话状态就会变得很麻烦。
举个简单例子。
如果一个企业有 500 个员工都在用 Agent，每个人都可能连接 GitHub、数据库、文档系统、工单系统。后端不可能永远把某个用户的会话绑死在某一台服务器上。
你需要负载均衡。
你需要横向扩展。
你需要失败重试。
你需要把请求分发到不同实例。
你还需要在中间加鉴权、日志、限额、审计和安全策略。
这时候，如果协议强依赖 Session，就会让架构变重。服务要记住太多上下文，网关要处理太多状态，扩容和容灾都会变复杂。
无状态的思路更接近现代 API：
每次请求都尽量自带足够的信息，服务端不必长期记住“你之前是谁、刚刚做了什么、当前会话走到哪一步”。需要状态的部分，可以放到明确的上层机制里管理，而不是塞在底层协议连接里。
人话翻译一下：
以前更像“你先和工具建立一段长期聊天关系”。
现在更像“每次调用工具，都把身份、权限、上下文和目标说清楚”。
后者更适合云端架构，也更适合企业管理。
三、为什么移除 Session 和 initialize 很重要？
很多人看到“移除 Session”“废弃 initialize 握手”，第一反应可能是：这不就是协议细节吗？
不是。
这背后是 MCP 从“本地工具连接协议”向“云端 Agent 工具协议”演进。
Session 的问题在于，它天然会制造状态依赖。
在小规模、本地化场景里，状态依赖很好处理。一个用户、一台机器、几个工具，Session 在内存里就能跑。
但在企业和平台场景里，状态依赖会带来四个麻烦：
-
服务扩容困难
如果用户会话绑在某个实例上，横向扩展时就要处理粘性会话、状态同步和故障恢复。 -
中间网关难做
企业通常希望在模型和工具之间加一层网关，统一处理鉴权、日志、限额和审计。底层协议越依赖会话，网关越难保持透明。 -
失败恢复复杂
如果中间某一步断了，要恢复的不只是一次请求，而是一整段会话状态。 -
多租户管理变重
企业要区分不同用户、团队、项目、权限范围。会话状态一多，权限判断和追踪也会变复杂。
所以 MCP 无状态化的意义，不只是“代码更优雅”。
它让 MCP 更像一套能跑在生产环境里的基础协议。
这也是为什么 GitHub MCP Server、Claude 侧适配、MCP SDK 下载量这些生态信号会被反复提到。协议只有在真实工具、真实平台、真实用户里跑起来，才会从“标准文档”变成“生态事实”。
四、Extensions：MCP 开始给生态留下“插件位”
这次更新里另一个关键点，是 Extensions。
如果说无状态解决的是“底层怎么连”，Extensions 解决的是“未来怎么扩”。
任何协议都会遇到一个问题：核心标准不能无限膨胀，但生态需求会不断增加。
今天有人想加更细的权限声明。
明天有人想加更复杂的 UI 能力。
后天有人想让工具返回更丰富的任务状态、进度、审批动作、文件产物。
如果所有能力都硬塞进核心协议，MCP 会越来越臃肿。不同实现方也会因为支持程度不同，互相兼容变差。
Extensions 的价值就在这里：把核心协议保持得足够稳定，把不同生态方的扩展需求放进可声明、可协商、可逐步采用的机制里。
这对开发者很重要。
因为以后你写 MCP Server，可能不只是暴露几个工具函数，而是要声明：
- 我支持哪些扩展能力；
- 我能返回哪些资源类型；
- 我是否支持任务进度；
- 我是否支持某种 UI 呈现；
- 我是否需要额外授权；
- 我是否能被某类 Host 直接嵌入使用。
这会让 MCP Server 从“工具接口”变成更完整的“Agent 能力模块”。
五、MCP Apps：AI 应用可能不再只是网页和 App
MCP Apps 是这次变化里最容易被低估的一块。
过去我们说 AI 应用，通常想到的是：
- 一个网页；
- 一个聊天框；
- 一个插件；
- 一个浏览器扩展；
- 一个桌面客户端；
- 一个工作流工具。
但如果 MCP Apps 走成熟，AI 应用的形态会变得更像“可被 Agent 调用、组合、嵌入和复用的能力包”。
比如一个财务分析应用，不一定要先做完整 SaaS 页面。它可以先变成一组 MCP 能力：
- 读取表格；
- 识别异常数据；
- 生成分析口径；
- 输出摘要；
- 生成报表；
- 交给用户确认；
- 再写回指定系统。
一个内容运营应用也类似：
- 抓取选题；
- 提取参考资料；
- 生成大纲；
- 输出公众号版；
- 输出官网版；
- 生成配图提示词；
- 归档素材；
- 记录关键词。
这些能力如果都能通过 MCP 暴露出来，Agent 就不只是“访问一个工具”，而是在组合不同应用能力。
这也是 MCP 最有想象力的地方。
网页和 App 是给人用的。
MCP Apps 更像是给 Agent 用的应用。
六、对开发者有什么影响？
如果你只是普通 Claude 用户，这次更新短期内可能感知不强。你打开 Claude，连接工具，继续使用。
但如果你在做 Claude Code、Dify、n8n、自建 Agent、内部工具接入、MCP Server 或企业网关，这次变化就值得认真看。
1. 旧 MCP Server 要关注兼容性
如果你的 Server 强依赖 Session、initialize 阶段传递配置，或者把用户状态放在连接上下文里，后续可能要改。
更稳的做法是把状态管理上移：
- 用户身份放到明确授权机制里；
- 工具权限放到配置层；
- 任务进度放到任务系统；
- 调用日志放到网关或观测系统；
- 临时上下文放到请求或可追踪的状态存储中。
不要再默认“连接还在，所以状态就安全”。
2. 鉴权和权限边界会更重要
无状态不是“不要安全”，恰恰相反，它要求每次调用都更清楚地说明权限。
企业接 MCP 时，至少要回答这些问题：
- 谁在调用这个工具？
- 这个用户属于哪个团队？
- 这个 Agent 现在执行的是哪个项目？
- 它能读哪些数据？
- 它能不能写入？
- 它能不能发起外部请求？
- 它能不能调用高风险工具？
- 每次调用是否有日志？
这也是为什么 Agent 工具调用不能只靠模型自觉。
协议越标准化，企业越要把权限、日志、限额和审计补齐。
3. 工具层会变得比模型层更稳定
模型会不断换。
今天 Claude，明天 GPT，后天 Kimi，再后天 Gemini。
但企业真正不想反复重写的，是工具接入层。
如果你的 GitHub、数据库、文档系统、工单系统、文件系统都已经通过 MCP 暴露成稳定能力，那么模型可以替换，工具层不用跟着大改。
这就是 MCP 的长期价值。
它把“模型选择”和“工具连接”拆开了。
七、对企业 AI 架构有什么启发？
很多企业现在接 AI，第一步还是问：
用哪个模型？
Claude 还是 GPT？
Opus 还是 Sonnet？
国内怎么接？
成本怎么算？
这些问题都重要，但不够完整。
如果企业真的想让 AI Agent 进入生产流程，架构上至少要拆成三层：
第一层是模型接入层。
它负责模型选择、Key 管理、Base URL、调用日志、余额、成本、并发、故障切换。apito.ai 适合放在这一层，帮助团队把 Claude 等模型接入统一管理起来。
第二层是工具连接层。
这里就是 MCP 的位置。它负责把 GitHub、数据库、浏览器、文件系统、内部 API、知识库等工具能力包装成 Agent 能调用的标准接口。
第三层是业务工作流层。
也就是你真正要跑的任务：写代码、查资料、生成报告、处理工单、分析数据、做内容生产、自动化测试。
这三层不能混在一起。
模型接入层解决“调用谁、怎么计费、怎么稳定访问”。
工具连接层解决“Agent 能用什么工具、怎么调用、权限怎么管”。
业务工作流层解决“到底让 Agent 做什么、做到什么程度、哪里必须人工确认”。
很多团队的问题，恰恰是把这三件事混成了一团。
模型一换，工具全改。
工具一多，权限失控。
任务一复杂，成本看不清。
MCP 这次无状态化，本质上是在提醒大家：AI Agent 的工程化，不是堆 Prompt，而是把连接、权限、状态和任务拆清楚。
八、现在要不要立刻迁移？
不用慌。
如果你只是使用 Claude Desktop、Claude Code 或现成工具，通常不需要马上做什么，跟随工具侧升级即可。
但如果你有自建 MCP Server，或者准备把 MCP 接进企业内部系统，我建议现在就做一次检查：
| 检查项 | 要看什么 |
|---|---|
| 是否强依赖 Session | 用户状态、任务状态、权限信息是否绑定在连接里 |
| 是否依赖 initialize 传递关键配置 | 如果握手阶段变化，Server 是否还能正常工作 |
| 权限是否逐次校验 | 不要只在连接时验证一次 |
| 日志是否完整 | 每次工具调用、参数、结果、错误都要可追踪 |
| 是否支持多租户 | 不同用户、团队、项目能否隔离 |
| 是否容易横向扩展 | Server 是否能在多实例环境下运行 |
| 高风险工具是否有确认机制 | 写入、删除、部署、付款、发消息都应有人工确认 |
这张表比“今天立刻改代码”更重要。
因为 MCP 的方向已经很清楚：它正在从本地工具协议，变成 Agent 生态的连接底座。
越早把工具层标准化，后面越不容易被模型和工具更新牵着跑。
九、apito.ai 应该放在这套架构里的哪里？
这里要说清楚：apito.ai 不是 MCP Server，也不需要把自己包装成 MCP 协议本身。
更准确的位置是模型接入层。
如果你已经在用 Claude Code、Cursor、Dify、n8n、Open WebUI 或自建 Agent 工作流，apito.ai 可以承担模型调用入口：
- 统一管理 API Key；
- 使用兼容接口接入 Claude 等模型；
- 查看调用和成本；
- 控制不同团队或工具的使用方式；
- 在工具迁移时减少重复配置。
而 MCP 更适合放在工具连接层：
- 连接 GitHub；
- 连接数据库；
- 连接文件；
- 连接内部系统；
- 连接浏览器自动化；
- 连接知识库。
一个更健康的 Agent 架构，不是把所有东西都塞进模型，也不是让每个工具各自直连模型，而是：
模型接入交给统一入口，工具调用交给标准协议，业务任务交给工作流编排。
这样模型可以换，工具可以扩，成本和权限也能看得见。
如果你之前已经配置过 ClaudeAPI 相关工具，后续迁移到 apito.ai 时，一般只需要把请求地址从 claudeapi.com 改成 apito.ai 对应地址，Key、模型名和请求参数是否需要调整，以控制台实际说明为准。
十、这次 MCP 更新真正改变的是什么？
它改变的不是“Claude 多了一个工具功能”。
它改变的是 AI Agent 生态的默认假设。
以前大家默认：Agent 接工具，是每个平台自己的能力。
Claude 有 Claude 的工具。
Cursor 有 Cursor 的工具。
Dify 有 Dify 的工具。
n8n 有 n8n 的节点。
企业内部再写一堆自定义接口。
但 MCP 想推动的是另一个方向：工具能力应该变成可被不同 Agent 理解、调用、组合的标准资源。
这会带来一个很现实的结果：
谁掌握了工具连接标准，谁就不只是掌握模型入口，而是在影响 Agent 应用生态的形态。
模型强弱当然重要。
但 Agent 时代更长期的竞争，可能不只发生在模型榜单上，也发生在协议、工具、连接器、权限系统和企业工作流里。
这就是 MCP 这次更新最值得关注的地方。
它让 Claude 不只是一个模型产品，而是继续往 Agent 基础设施方向走了一步。
FAQ
1. MCP 是 Anthropic 独有的吗？
MCP 最早由 Anthropic 推动，但已经进入更开放的生态发展阶段。现在很多工具、SDK、开发者和平台都在围绕 MCP 做适配。实际使用时，不应把 MCP 理解成某一家产品的私有插件，而更接近一种 Agent 工具连接标准。
2. MCP 无状态化后，原来的 MCP Server 会失效吗？
不一定。具体要看你的 Server 是否依赖旧版 Session、initialize 握手和连接内状态。如果只是普通工具调用，可能只需要跟随 SDK 更新；如果把用户状态、权限或任务上下文绑在连接里，就需要重新检查。
3. MCP 和 API 网关有什么区别？
MCP 更偏工具连接协议，解决 Agent 如何发现和调用工具。API 网关更偏模型调用、鉴权、限额、日志、路由和成本管理。企业里两者最好配合使用：模型接入层用网关，工具连接层用 MCP。
4. apito.ai 和 MCP 是替代关系吗？
不是。apito.ai 更适合做模型接入和调用管理，MCP 更适合做工具连接和能力暴露。一个负责“调用模型”，一个负责“连接工具”，放在一起才更接近完整的 Agent 工程架构。
5. 企业现在接 MCP 最应该先做什么？
先不要急着堆 Server。建议先做一张工具权限表：哪些工具可读、哪些可写、哪些必须人工确认、哪些只能测试环境使用、哪些需要完整日志。MCP 让工具连接更标准，但权限边界仍然要企业自己设计。
参考资料
- Model Context Protocol 官方博客：2026-07-28 protocol revision release candidate
https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ - Model Context Protocol 官方文档
https://modelcontextprotocol.io/ - Anthropic MCP 文档
https://docs.anthropic.com/en/docs/mcp - GitHub MCP Server
https://github.com/github/github-mcp-server - MCP Specification
https://spec.modelcontextprotocol.io/
如果你正在把 Claude Code、Cursor、Dify、n8n 或自建 Agent 工作流接入生产环境，可以先从模型接入层开始规范化。通过 apito.ai 统一管理模型调用、Key、成本和日志，再把工具能力逐步迁移到 MCP 这类标准连接层，会比每个工具单独接模型更稳。
