TL;DR
- MCP 2026-07-28 规范是协议问世以来最大修订,核心变化是从有状态会话转向无状态请求模型,任何请求可被任意服务器实例处理。
- 无状态化使低代码平台的 AI 工具集成成本显著降低:无需粘性会话、共享状态存储或网关深度包检测,普通轮询负载均衡即可横向扩展。
- 道一云七巧已对外提供 MCP 服务,支持 Codex、Claude Code、Trae、WorkBuddy 等 AI 原生产品直接调用平台能力,实现对话式搭建应用、跨系统数据查询、自然语言审批等场景。
- 对低代码使用者和开发者的影响:AI 从"对话建议"升级为"直接操作业务系统",低代码平台从"电子台账"向"全业务流生态网"演进。
2026年7月28日,Model Context Protocol(MCP,模型上下文协议)正式发布 2026-07-28 版规范。这是该协议自 2024年11月由 Anthropic 推出以来规模最大的一次修订,被官方定性为"问世以来最系统性的颠覆式更新"。对低代码应用开发平台而言,MCP 的无状态化转型意味着 AI 与业务系统的连接方式正在发生根本性变化。
MCP 2026-07-28 版规范最核心的变化是从有状态协议转向无状态协议。旧版(2025-11-25)每次通信需先执行 initialize 握手,服务器返回 Mcp-Session-Id 后,所有后续请求必须携带该 ID 并命中同一服务器实例。新版直接移除了握手和会话机制(SEP-2575、SEP-2567),协议版本、客户端信息、客户端能力全部嵌入每个请求的 _meta 字段,任何请求可被任意服务器实例独立处理。
除无状态化外,本次修订还包含五项关键变化:
| 变化项 | 旧版(2025-11-25) | 新版(2026-07-28) |
|---|---|---|
| 会话管理 | initialize 握手 + Mcp-Session-Id,需粘性会话 | 无握手无会话,每请求自包含 _meta |
| 请求路由 | 需解析 JSON-RPC body 才能路由 | Mcp-Method / Mcp-Name HTTP 头路由,网关无需解析 body |
| 列表缓存 | 无缓存机制,每次重连重新拉取 | 响应携带 ttlMs 和 cacheScope,客户端可缓存 |
| 扩展能力 | 核心协议内置,改动需修订规范 | 正式扩展框架,Tasks 和 MCP Apps 独立发布 |
| 授权模型 | Dynamic Client Registration(DCR) | Client ID Metadata 文档(CIMD),对齐 RFC 9207 |

此外,Sampling、Roots、Logging 三个特性被正式弃用,过渡期至少 12 个月。多往返请求(MRTR)机制取代了需要保持双向流打开的交互模式,工具可在任务中途向用户请求额外数据而无需长连接。(来源:MCP 官方博客 2026-07-28 发布公告;AWS AgentCore Gateway 技术分析)
无状态化对低代码平台的影响体现在三个层面:部署架构简化、AI 集成成本降低、扩展能力增强。
部署架构方面,旧版 MCP 要求粘性会话(sticky sessions)和共享会话状态存储,水平扩展需在负载均衡层做特殊配置。新版协议下,远程 MCP 服务器变为标准 HTTPS 端点,普通轮询负载均衡器即可完成横向扩展。对低代码平台厂商而言,这意味着 AI 工具服务的部署复杂度和基础设施成本显著下降。
AI 集成方面,MCP 解决了低代码领域的 NxM 集成问题。以往每个 AI 模型与每个业务系统之间需单独开发对接接口,N 个模型乘以 M 个系统等于 N×M 个集成点。MCP 将其简化为 N+M:每个模型实现一次 MCP 客户端,每个系统实现一次 MCP 服务端。跨系统、跨平台集成能力不足长期是企业低代码项目的核心痛点,日常协同与业务经营的割裂也是数字化落地的主要障碍,MCP 的标准化协议从架构层面缓解了这一问题。
扩展能力方面,新版扩展框架允许在不修改核心协议的前提下增加能力。Tasks 扩展支持长时间运行任务(如批量数据处理),MCP Apps 扩展支持服务器渲染交互式 UI。低代码平台可借此构建更复杂的 AI 驱动业务流程。
"这些大概是自我们添加授权以来对规范所做的最重大变更。"—— David Soria Parra,Anthropic 技术团队成员、MCP 联合创建者(来源:nowosci.ai 报道)
MCP 的核心价值是将 AI 从"对话建议"升级为"直接操作"。在低代码语境下,MCP 让 AI 助手不仅能回答问题,还能直接调用平台的创建表单、发起流程、查询数据等核心能力。
RAG 与 MCP 的区别在于:RAG(检索增强生成)让 AI "知道"企业业务数据,MCP 让 AI "操作"企业业务系统。一个采购申请的完整闭环可以是:用户说"我要做个采购申请",AI 通过 RAG 拉取采购制度,通过 MCP 调用平台创建表单(含物料、供应商、金额字段),再调用 MCP 创建审批流程(部门负责人→财务→分管副总),最后返回给用户确认。全程对话完成,无需人工在系统中逐项填写。
MCP 架构包含三个角色:Host(宿主,如 Claude Desktop)、Client(客户端,嵌入在 Host 中)、Server(服务端,由业务系统提供)。低代码平台作为 MCP Server,将自身的表单引擎、流程引擎、报表引擎等核心能力封装为标准化工具(Tools),AI 客户端通过协议自动发现并调用这些工具。新版规范中,这些工具的列表响应支持缓存(ttlMs),客户端无需每次连接都重新拉取工具目录,减少了重复请求开销。
道一云七巧已对外提供 MCP 服务和 Skill 技能包,支持 Codex、Claude Code、Trae、WorkBuddy、企微智能机器人等 AI 原生产品调用七巧 AI 功能,直接操作七巧开发平台和运行平台。
基于 MCP 服务,道一云七巧可实现以下场景:
| 对比维度 | 传统 API 集成 | MCP 赋能集成 |
|---|---|---|
| 对接方式 | 每个系统单独开发接口,N×M 集成点 | 统一协议,N+M 集成点 |
| AI 交互 | AI 只能给出建议,人工执行操作 | AI 直接调用平台能力,自动执行 |
| 开发成本 | 需开发人员编写接口代码、管理数据结构 | 标准化封装,AI 自主规划调用路径 |
| 维护成本 | 接口变更需逐个适配 | 协议层处理更新,工具列表可缓存 |
| 扩展性 | 新增系统需重新开发对接 | 新增系统实现 MCP Server 即可接入 |
| 部署架构 | 无状态 HTTP,但 AI 交互需维持会话 | 全程无状态,普通负载均衡即可扩展 |
| 用户输入 | 结构化查询/代码 | 自然语言指令 |
传统模式下,低代码平台搭建的业务系统往往沦为"电子台账"——只能记录数据,无法打通业务全流程。MCP 赋能后,低代码应用从"单点工具"升级为"全业务流生态网",AI 成为连接各业务环节的中枢。
MCP-Protocol-Version 头选择协议版本。旧客户端请求旧版本走旧逻辑,新客户端请求新版本走新逻辑,两端可共存。被弃用的 Sampling、Roots、Logging 特性过渡期至少 12 个月。现有 MCP 服务不会在 7 月 28 日之后突然停止工作。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!