三台服务器轮流接单，MCP为什么不会失忆？ 新版 MCP 删除握手和协议级 Session 后，复杂任务怎么继续？用“三次状态搬家”讲清请求自包含、显式句柄和 MRTR。 #MCP #AI产品经理 #人工智能 #Agent #大模型

三台服务器接力任务会断吗？每次调用都带上材料、业务进度，能按编号找回，就不会给AI提供工具和数据的服务。就MCP server调用它的AI应用到客户端，MCP全程是Model Context Protocol，中文叫模型上下文协议。工具调用落到A，用户确认落到B，真正执行落到C，随后重启任务也没断。这里的状态就是后一步还要用的前情，客户端这次交来的材料会叫请求版本和客户端能力，随请求走，业务状态按编号查找。中途追问改成客户端重发请求，先把状态说成人话：你去办一项。 三、步步批。第一位柜员把材料放在自己桌上，下次你还得找他，换个人对方就不知道你办到哪一步了。这就是有状态，后一步依赖某个位置留下的记忆。另一种办事方式完全不同，每次你都带着申请单和业务编号，上面还写着当前步骤，任何柜员拿到材料都知道接下来做什么，完整记录仍然在后台系统里，只是流程不再靠某个柜员的记忆维持，这就是无状态。 所以判断无状态，别问系统有没有数据库，也别问连接能不能保持很久，每问一件事：服务器能不能独立处理当前请求？如果它必须先想起你刚来过，那就还在依赖隐式状态。 旧版MCP为什么会被会话拴住？2025年11月25日版规范要求工作前先握手，客户端先发initialized，再发notifications.initialized，双方借此交换版本、能力和实现信息。MCP的HTTP传输支持流式返回，这种传输叫streamable HTTP，服务器还能发会话编号Vp Session ID，像酒店房卡，先登记后续服务，围绕这次入住。麻烦出现在服务器开始扩容以后，如果会话只在A的内存里，下一次请求就不能随手交给B节点。通常有两种办法：要么做粘性路由，让同一会话一直回到A；另一个办法是建共享存储，让A、B、C去找同一份会话。粘性路由会限制调度和故障切换，共享存储又会带来性能、可用性和安全问题。但会话编号本来就是可选的，旧规范没有强制绑定单机。真正的成本在于实现依赖协议及会话，后续请求就得找回前情。 2026年7月28日版规范重新划分了状态责任，可以继承三次搬家：第一次，握手信息搬进每次请求；第二次，跨请求状态搬进服务器签发的状态编号handle；第三次，中途追问搬进新一轮请求。第一次搬家删掉了initialize notifications，就not initialized和协议及会话编号、握手谈好的信息，改由每次请求声明版本和客户端能力，放进请求体的附加信息区域。MCP客户端信息也建议随请求带上，服务器还能提前亮出能力。Server Discover就是能力清单，但客户端不一定非得先调用它，请求头就是随请求附带的说明版本，叫MCP Protovention方法头，叫MCP Method，工具或资源名放进MCP Name。网关是请求入口和转发层，能直接读取这些标签。这里最容易讲错：不是所有信息都塞进HTTP请求头，客户端能力主要在请求体的MCP里，OS管授权是访问凭证，他们另走认证授权，前面的MCP头只管版本和分发。 第二次搬家是让业务状态可以被找到。无状态协议当然允许业务有状态，审批订单、合成任务仍要保存，可以放进数据库、Redis做任务系统，但不能只藏在某条链接里，也不能只藏在某台进程的内存里。客户端下次要带上业务ID或任务ID，还可以在服务器签发的状态编号handle，健康实例拿到编号就能查到同一笔业务，网站一直这么做。HTTP不记购物车，浏览器带上cookie或token，后台再去找，协议保持无状态，购物车照样连续请求，带的是钥匙，不用把整座仓库搬过来。 第三次搬家处理的是中途确认：工具执行到一半，需要用户点头，用模型可以保持一条双向通道。服务器发现信息不够，就主动回头问客户端。新规范改用MTR，也就是多轮往返请求：客户端先发起工具调用，信息不够时，服务器返回inputRequired，它放在result type字段里，客户端去收集用户确认答案，写进input responses，然后重新发起原来的请求，服务器独立处理这次重试，再返回最终结果。服务器还能签发request state，是不透明状态标记，客户端只负责原样带回，服务器要检查它有没有被篡改，还要检查是否过期。旧标记被再次使用，就叫重放。MTR没有删掉多步交互会话，只改了谁来发起下一轮，每一轮都由客户端发请求，客户端拿起材料再请求一次，服务器不靠上一轮留在连接里的隐式记忆。连接依然可以长时间保持，有无状态看的是处理依据，不是连接时长。 JSON RPC就是用JSON写方法和参数，工具调用名是字段，一次请求要让服务器看懂四件事：第一件是版本和客户端能力，第二件是工具名和参数，说明这次要做什么，第三件是权限，OS token用来查权限，第四件是状态编号，用来找回前情。这四件事仍然沿着三次搬家来理解：版本和能力属于第一次搬家，状态编号属于第二次搬家，工具参数和权限是每次请求都要带齐的执行条件，要追问时再进入第三次搬家。 客户端会自报名称和版本字段，叫client info，相当于名片，用于展示、日志和调试，它不是身份证，服务器不能拿它做安全判断。请求自包含，不是把聊天记录全塞进去，也不用把数据库搬过来，自包含的是处理依据，只看这次请求就知道版本和操作，也知道状态标识，大块数据仍然放在外部系统里。这种设计最大的好处是实例可以替换，同一个客户端的两次请求，可以落到不同实例。某台机器重启，下一次请求就交给另一台，流量上涨时加实例，下降时再缩回去，它可以跑在容器或边缘节点里，还支持按需启动，也就是Serverless标准，网关也更容易接入。无状态化不会自动带来安全和可靠，过去会话顺手记住的东西，现在都要显式设计：业务状态存在哪里？handle怎么生成、过期和撤销？谁来负责审计？旧客户端和新服务器怎么兼容？这些问题一个也没消失。 删除订单的调用遇到网络中断重试时，系统不能删两遍，同一请求重复执行，观察效果应当相同，这叫幂等性。状态回传也不能只靠信任，这次回执可能被改，比如把驳回改成通过，服务器要校验完整性、身份和有效期，还要核对原始请求，高风险操作要明确确认评审。 MCP Server可以直接问三个问题：第一，任意请求能否落到任意健康实例？第二，跨请求状态有没有明确编号？第三，重复请求和状态回传安全吗？这三问对应三类风险：一起绑死前情丢失、状态被重用或篡改。换句话说，这三问也在回看三次搬家：第一问，检查请求是否真能自包含；第二问，检查状态能不能按编号找回；第三问，检查重发和状态回传能不能安全成立。 MCP无状态化只认一条规则：不再替应用偷偷记住前情，要延续的东西，要么随请求声明，要么按编号查找。用