本文来自微信公众号： AIGC从0到1 ，作者：王零壹
7月28日，Model Context Protocol发布2026-07-28版规范。最显眼的一项变化，是MCP的核心协议改成了无状态。
把新版规范从头看下来，会发现它实际上在回答一个更棘手的问题：当Agent不只是帮人找答案，而是开始替人查系统、发消息、改记录、提交任务时，原来藏在一段连接里的东西，谁来负责？
过去，MCP可以靠一段持续的session把许多事情先挂在那里。客户端和服务端彼此认识，服务端也知道自己正在和谁说话、这件事已经走到哪一步。现在，这条线被拿掉了。
这不是Agent忘了，也不是企业终于可以把状态扔掉。恰好相反：状态、权限、审批、任务进度和执行结果，不能再默认躲在一条连接后面。它们得被命名、传递、保存，也得在出了问题时被找回来。
这是MCP这次更新真正值得写的一层含义。
Agent协议正在离开“怎样把模型接到工具上”的早期阶段，开始面对一个更像组织管理的问题：一个会说话、会规划、还会行动的系统，到底能替谁做什么；它做过什么；谁要为那次行动负责。
一、一个被取消的session，为什么成了MCP的分水岭
MCP刚出现时，最受欢迎的原因很直接：它给模型接工具提供了一种共同语言。
过去，每个产品都要自己定义函数、参数、认证、返回格式。一个模型能不能调用数据库、读取Notion、改一条工单，靠的是一堆互不相认的API封装。MCP把这件事往前推了一步：工具可以用统一方式描述自己，Agent Host可以用统一方式发现、调用和管理它们。
这解决了“接上去”的问题。
但工具一旦从本地脚本走到远程服务，另一套老问题就浮出来了。早期的MCP依赖初始化握手和连接级session。简单说，客户端先和服务端打个招呼，之后双方在一条持续的关系里沟通。对于本地工具，这很自然；对于要跑在云上、面对大量并发请求的服务，它开始碍事。
因为你不得不记住：这个用户此前连到了哪一台机器；那台机器还活着吗；如果流量突然增加，新的请求能不能分到另一台机器；一旦机器挂了，正在进行中的交互怎么办。
新版MCP的做法很干脆：取消`initialize/initialized`握手，也取消`Mcp-Session-Id`。每一个请求都自行带上协议版本、客户端身份和能力信息。只要配置正确，任何一台服务实例都可以接住它。
这就是无状态化的工程含义。它让MCP Server更像我们今天熟悉的Web服务：可以挂在普通负载均衡器后面，可以横向扩容，可以被网关统一观察、限流和控制。
还有两个细节很能说明问题。
一是工具名和方法名被放进了请求头。网关不必先拆开JSON正文，才知道这次调用的是“创建项目”还是“删除数据”。它可以更早决定这条请求该走哪条链路、收多少额度、有没有必要拦下来。
二是工具和资源目录开始带缓存提示，列表结果也要求稳定排序。看起来只是性能优化，背后却是一个更务实的目标：Agent Host不该每一轮都重新询问“你会什么”，也不该因为工具目录顺序变化，反复浪费上下文和prompt cache。
这也是为什么，把这次更新说成“MCP变成HTTP”并不准确。
MCP没有取代HTTP，它仍然是建立在既有传输方式之上的协议，stdio也依然存在。更准确的说法是：MCP的远程调用变得更接近标准Web工作负载。它开始借用互联网几十年积累下来的扩容、路由、缓存和网关能力。
这是一件基础设施层面的好事。但这件好事马上带来一个副作用：那张原本由session隐约兜住的“状态账”，现在得重新摊开算。
二、无状态不是失忆，状态只是从连接里搬了出来
很多人看到“无状态”会本能地问：那Agent怎么记住上下文？
答案是，它本来就不该主要靠协议连接来记住。
一段连接能保存的，是临时、隐形、脆弱的状态。只要连接不断，服务端可以假装记得一切：你刚才传了什么、这个操作进行到第几步、某项授权是否还有效。可这类记忆并不适合真实业务。它无法被另一个服务实例直接接手，也不容易被审计，更谈不上跨系统复用。
新版规范给出的思路是把状态显式化。
如果某个工具需要跨调用保存信息，它可以生成一个handle。它可能是一份合同草稿的ID，一个正在执行的任务号，或一个中间产物的地址。下次调用时，模型或Host需要把它作为参数带回来。状态不再默默留在连接里，而是有了可以传递的引用。
这点听起来很小，实际上很像软件工程里一次责任边界的调整。
假设一个Agent正在帮公司做采购：它先查库存，再向几个供应商询价，发现价格超过了预算，需要负责人确认。旧式思路里，服务端可以把这次调用一直挂着，等负责人回来点一下“同意”。
新版MCP里，服务端会明确告诉客户端：我还缺一项输入。客户端把确认请求交给人，拿到结果后，再携带答案重试原来的调用。这个机制叫Multi Round-Trip Requests，简称MRTR。
人看到的只是一个确认框。系统完成的是另一件事：一次中途审批，被变成了一段可描述、可传递的请求链。
这里必须分清两件事。
MRTR解决的是：一次工具调用进行到一半，发现还需要人补充信息时，怎么继续。
它没有解决的是：一项跑了两天的任务如何恢复；供应商接口超时后如何避免重复下单；审批人换岗之后，任务该由谁接手；已经生成的中间结果保存在哪里；用户把浏览器关掉后，这个任务还有没有继续执行的资格。
这些事都需要额外的系统。任务系统、数据库、工作流引擎、对象存储、审批流和审计日志，都会重新出现。MCP的Tasks扩展开始覆盖其中一部分，但它并不会变成企业里所有长流程的替代品。
真正值得注意的是，MCP把“状态究竟在哪里”从一个默认答案，变成了一道必须回答的架构题。
一个可用的Agent，至少同时有几本账。
第一本是对话账。用户说过什么，模型如何理解，哪些上下文需要进入下一轮。它通常属于Agent Runtime或Host。
第二本是业务账。合同是草稿、已审批还是已签署；一笔采购是待确认、已付款还是已取消。它应该属于CRM、ERP、支付系统或垂直业务系统。
第三本是执行账。任务跑到哪一步，失败后能否重试，产物在哪里，是否已通知用户。这部分可能由Tasks、工作流引擎和可观测性系统共同承担。
最后一本是授权账。谁允许了这次动作，额度是多少，权限到何时失效，调用发生时使用的是谁的身份。这本账是Agent真正进入企业后最难补的一本。
过去的Demo往往只需要第一本账。一段对话、一个临时token，足够把故事讲圆。可一旦Agent要连续工作几天，触碰客户数据或花公司的钱，少掉任何一本，事情都会变得很难看。
新版规范还有一个不太起眼的规定：如果响应流断了，客户端要把未完成的请求当作一次新请求重新发起。协议不会替你把“断在半路的那件事”接起来。
这就把一个很传统、但在Agent时代更危险的问题推到台前：幂等性。
如果Agent已经向供应商发出订单，但返回结果的流断了，重试会不会再下一单？如果它已经创建了工单，下一次请求应该返回原工单，还是再创建一个？如果任务在审批后被重复执行，谁能看出来？
这些都不是模型推理能力能够替代的细节。它们是系统对“我到底做没做过这件事”的记忆。
无状态端点会让部署更轻。可对业务而言，状态从来没有轻过。它只是从一条连接里，搬进了更明确、也更需要被管理的对象里。
三、MCP正在把自己收窄，外围却会越来越热闹
从这次更新还能读到另一个信号：MCP不再试图把完整的Agent Runtime都装进自己的核心里。
新版把实验性的Tasks移到官方扩展；Sampling、Roots、Logging被标记为弃用；老的HTTP+SSE传输也进入退出期。它们放在一起，代表的是MCP开始划一条更清楚的线：哪些能力值得所有实现共享，哪些能力应该留给Host、扩展和上层框架自己解决。
这是一种“窄腰”思路。
MCP Core负责最基础的几件事：发现一个服务，读取资源，调用工具，带上基本的上下文和授权。它像是Agent到外部系统之间的一条通用插口。
模型记忆怎么做，任务如何规划，多个Agent怎样分工，企业怎么配置审批层级，界面怎样让人接手，这些都不该由一份通用协议替所有人决定。
Core变薄，外围自然会变厚。
这也是今天Agent协议突然变多的原因。它并不是大家突然喜欢造名词，而是不同的问题开始显出自己的边界。
MCP更适合描述“一个Agent如何调用某项能力”。比如查数据库、创建日历、读取文档、提交一段代码。调用方不需要知道服务内部怎么实现，只要知道它能做什么、需要什么参数、会返回什么结果。
A2A更像“一个Agent如何把一项工作交给另一个Agent”。A2A的目标是让不同公司、不同框架、不同服务器上的Agent发现彼此能力，协商交互方式，并合作完成长任务。它强调的是把外部Agent当作相对独立的工作单元，而不是一把等待调用的扳手。
这两个协议可以放在一套系统里。一个研究Agent对内通过MCP查企业知识库、调用数据工具；当它需要另一家专业服务商完成一份复杂的税务判断时，再通过A2A发出委派。
但不要过早相信“分工已经定型”。
MCP也出现了任务对象，A2A也有技能描述、发现机制和任务生命周期。随着双方都往上生长，任务、身份、发现和用户交互会出现重叠。短期里，更可能看到的是桥接和包装：把MCP Server包成A2A Agent；或者一个A2A Agent在内部调度多个MCP工具。
浏览器和界面层也在加入。
WebMCP想让网页直接把自身功能暴露为结构化工具。这样，Agent不必像人一样模拟点击、猜按钮位置，而可以知道“这里能够查询订单”“这里可以提交表单”。这个方向很重要，因为浏览器是大量线上工作真正发生的地方。
但它现在仍是W3C Community Group的报告，不是W3C标准，也没有进入标准轨道。把它看作浏览器向Agent开放能力的一次试探比较合适，别急着把它写成终局。
AG-UI、A2UI等协议关注的则是另一件事：Agent正在运行时，人怎么知道它在干什么；它调用工具、等待确认、生成结果时，前端怎样把这些过程清楚地交给用户。对普通用户来说，这层甚至比协议本身更直观。一个Agent再会干活，用户看不见它的判断，也无法中途接手，信任就很难建立。
再往上，是商业与支付协议。它们开始描述商品、订单、支付授权、收据和履约，而不是单纯的函数调用。
把这些放在一起看，Agent世界更可能长成一套协议栈，而不是等来一个吞掉所有能力的超级协议。调用、协作、界面、身份、支付和行业语义，都会有各自的实现和争夺。
谁都想多占一点边界。谁也很难独吞全部。
四、Tool Call容易，代理权才是硬骨头
让Agent调一次天气接口，风险很低。让它读一份公开文档，问题也不大。
难的是，当Agent开始替人做不可逆的动作。
它代表谁？
它能在什么范围内行动？
它在这个时刻拿到的权限，是不是仍然有效？
它执行之后，系统能不能证明这次行动确实经过了有效授权？
这几件事，才会决定Agent能不能进入核心业务。
MCP的新版授权机制在做一些很具体的收口：客户端申请token时，要声明目标资源；服务端要校验token的受众是否真的是自己；凭证不能被随意拿去另一个授权服务器复用。它们听起来像OAuth的边角料，实际上是在防一件很危险的事：一个拥有权限的代理，被误导去替不该服务的对象行使权限。
安全领域把它叫作confused deputy。想象一下，一个拥有财务系统权限的员工，突然被不可信的外部邮件诱导去执行了别人指定的操作。Agent的版本更麻烦，因为诱导它的内容可能藏在网页、文档、邮件、搜索结果，甚至工具返回的文本里。
模型会读这些内容。模型也可能把其中的恶意指令当成任务的一部分。
于是，OAuth解决“谁登录了”远远不够。它不能自动解决“为什么这个Agent此刻要删数据”，也不能保证模型不会被提示注入影响。
协议层能做的是缩小爆炸半径：把权限拆细，要求每次请求带上目标资源，给工具加scope，在高风险节点插入确认，留下完整调用记录。模型层要做上下文隔离和攻击识别；业务层要决定哪些动作无论如何都必须让人点头。
没有一层可以单独兜底。
支付把这件事照得最清楚。
“帮我买一台显示器”是一个自然语言意图。可它还缺太多东西：预算多少，能买哪些品牌，价格变化时要不要重新确认，是否允许自动付款，退货由谁处理。
如果最终真的要完成交易，系统必须把这些模糊意图翻译成更硬的结构。UCP一类商业协议开始描述商品、购物车、结账和订单；AP2一类支付协议则尝试把可购买范围、金额上限、有效期、具体支付和结果收据拆开记录。
它们现在都谈不上已经统一市场，但有一点已经没有悬念：Agent的商业化不可能只靠一句“帮你下单”。要让它下单，系统得先回答它有没有资格下单，以及下完之后谁认这笔账。
自然语言适合协商和探索。进入付款、签署、删除、发布这些动作之前，Agent需要进入一个结构化、可授权、可验证、可审计的世界。
这才是协议层会越来越有价值的原因。
五、Registry不只是目录，它会慢慢变成闸门
当MCP Server的数量开始增长，另一个问题马上出现：Agent应该从哪里找到正确的工具？
官方MCP Registry现在还在预览期。它首先是一个集中式元数据仓库：开发者可以发布Server的名称、位置、安装方式、版本和能力描述；客户端与聚合器可以据此发现公开可访问的服务。
它现在更像一份电话簿，不是一座App Store。
但电话簿一旦开始回答更多问题，性质就会变。
发布者的身份是否经过验证？
这个Server的依赖有没有被篡改？
它最近的调用成功率怎样？
企业是否批准它访问代码、客户数据或财务系统？
同一类能力里，哪个结果更可靠，哪个成本更低？
发生事故之后，能否追溯一条完整的调用链？
这些问题带来的，不只是搜索体验，而是信任与治理。官方Registry文档也很直白地把策展、评分、排序等事情留给下游聚合器和Marketplace。因为真正值钱的部分，从来不是“列出一千个工具”，而是帮助用户和企业决定“这一千个里，哪一个能碰我的数据”。
这里会形成Agent时代新的控制平面。
开放协议降低的是接入门槛，并不会自动让分发去中心化。用户入口仍可能在Host手里，调度权可能在模型平台手里，默认推荐与安全政策可能在浏览器、IDE、办公套件或企业网关手里。
对做Skills、MCP Server和垂直Agent的团队来说，这是一件需要尽早想清楚的事：接入标准会让你更容易被发现，也会让别人更容易把你替换掉。
当调用接口变得可互换，真正留得住用户的东西会回到业务本身。你是否掌握独有的数据；是否维护了无法轻易迁移的业务状态；是否能稳定交付、解释和审计结果；用户是否愿意长期把授权与反馈留在你这里。
一个报销审核工具，如果只把PDF识别和规则判断接成MCP，很快会遇到同类竞争者。它若沉淀了企业自己的费用政策、历史纠错、异常处置和审核责任链，情况就不同了。前者是一个接口，后者才开始像一项业务基础设施。
协议越开放，产品越要知道自己的资产放在哪里。
六、国内接下来的难题，是这四件事
国内对MCP的热情来得很快。云厂商、模型平台、开发者社区和企业Agent产品都在接入、展示或分发MCP Server。它们把散落在脚本、SaaS API和内部系统里的能力，拉进了Agent可调用的范围。
这是必要的一步，但它离形成真正的Agent生态还很远。
工具数量越多，企业越需要知道谁能对工具负责。一个销售Agent同时接CRM、企业通讯、合同和财务审批，难点从来不是“能否连接四个接口”。难点是：一个员工离职后权限怎么回收；一个任务从销售流到法务再流到财务时，授权如何随之收缩或升级；模型读到外部材料后，哪一步必须停下来让人确认；发生错误时，日志能不能把责任还原出来。
这些问题在国内尤其现实，因为组织软件和业务流程往往高度碎片化。身份体系不同，审批链不同，数据边界也不同。一份通用schema能解决字段如何传递，却不能替企业决定什么叫“有权审批”，什么叫“适当授权”。
未来一段时间，更值得观察的是谁能在真实行业里把四件事做顺：跨系统确认身份，按具体动作拆分权限，让长任务可恢复，让异常有明确的人类接管点。
医疗、金融、零售、制造都会有不同答案。通用协议负责把底层接口接起来，行业系统还要把责任写进自己的流程里。
这会是国内Agent产品从“演示能力”走向“承接工作”的一道分水岭。
七、协议战争最后争的，是谁拥有这条责任链
MCP的无状态化没有让Agent突然变聪明，也没有替企业解决安全问题。
它做的是一件更基础的事：把一条隐藏在连接里的关系拆开，让调用更容易扩展，也让状态和授权更难继续含糊下去。
这件事会逼着整个生态往前走。
MCP要回答工具和资源如何被调用；A2A要回答不同Agent如何协作；WebMCP要探索网页如何向Agent暴露能力；界面协议要解决人如何看见并接手Agent；商业协议要让交易意图变成可结算、可追溯的结果。
它们会重叠，也会彼此争夺边界。没有必要急着宣布谁会成为统一标准。
真正需要盯住的，是哪一层会变成所有参与者都绕不过去的协调点。
可能是默认入口，可能是可信目录，可能是企业身份网关，可能是支付与结算网络，也可能是某个行业不得不接受的业务Schema。开放规范本身未必能捕获最多价值，价值往往会沉到能提供信任、治理、分发和责任承接的地方。
对开发者来说，MCP的变化意味着Server更容易部署、更多Host可以调用它。对创业者来说，接口可移植性提高后，不能再把“接上MCP”当成产品壁垒。对企业来说，最该建设的也不是一个Agent工具展厅，而是一套让Agent能被发现、被限制、被授权、被观察、被撤销和被追责的机制。
未来的Agent会像员工一样穿行在多个系统之间，只是它不会自己知道什么是边界，也不会自己承担后果。
所以，Agent时代真正需要被标准化的，不只是调用方式。
还包括一条谁都能看清、出了问题也找得到人的责任链。
---
*注：本文基于截至2026年7月30日的MCP 2026-07-28规范、A2A、WebMCP、UCP/AP2等公开资料撰写。WebMCP仍处于W3C Community Group报告阶段，MCP Registry仍为预览版；关于协议最终格局、商业化控制点及中国市场节奏的部分，为基于公开进展的分析判断。