无状态 MCP 与有状态 Agent 工作流：Android 手机任务状态架构指南

MCP 2026-07-28 改了什么

MCP 2026-07-28 最重要的变化，可以用一句话概括：协议核心走向无状态，每个请求携带所需元数据，服务器实例无需保留长期传输会话中的前序协商状态。Model Context Protocol 2026-07-28 规范发布说明把这次更新描述为最终发布，包含无状态协议核心、MRTR、header 路由、可缓存列表、授权强化和扩展框架，并把 Tasks 作为正式扩展。

从我们构建 FoneClaw 的经验看，这个变化解决的是协议部署层的摩擦。自描述请求可以被负载均衡器路由到任意兼容实例，服务端重启更容易恢复，Serverless 和横向扩容都更自然。SEP-2575：Make MCP Stateless进一步说明了移除强制初始化握手、用每次请求的元数据替代会话协商假设的动机。

无状态协议核心和有状态 Agent 工作流可以同时成立。协议层减少隐藏会话，应用层用明确的任务句柄、幂等键、审批记录、授权上下文和审计日志保存该保存的状态。对 Android 手机 Agent 来说，这个区分尤其重要：手机任务会跨屏幕、跨权限、跨用户确认和跨设备状态变化，任务状态需要在 Agent 主机层被清楚管理。资源发现和授权入口的可信关系，可以参考 Agentic Resource Discovery 智能体资源发现：ai-catalog.json、可信目录与手机授权边界。

无状态 MCP 请求生命周期如何工作

无状态 MCP 请求的基本思路，是把每次调用需要的身份、能力、协议版本、上下文引用和路由信息放到请求里。服务器实例收到请求后，可以基于这些元数据处理调用，长期传输会话中的协商记忆不再承担核心语义。对基础设施来说，这意味着请求更容易被缓存、分流、重试和观察。

服务发现也会变得更显式。客户端可以发现服务器能力、可用工具、资源和扩展，再用每次请求携带的元数据表达自己要调用什么。列表类能力可以被缓存，header 路由可以把请求送到合适后端。SEP-2567：Sessionless MCP via Explicit State Handles说明了用服务器生成的显式状态句柄替代隐式协议会话状态的思路。

显式句柄适合引用某个长期任务、导出结果或工作上下文，但它只是一个引用。真正的应用状态仍要在合适的地方保存：谁发起了任务、用户确认过什么、设备当时是什么状态、重试是否安全、结果是否已经生效。对手机 Agent 来说，请求生命周期可以无状态，任务生命周期需要有状态。我们在设计 FoneClaw 时，会把协议调用、Android 权限、用户审批和设备结果分成不同账本，让每一类状态都有明确归属。

手机 Agent 必须拥有的六类状态

可靠的手机 Agent 至少需要六类状态账本。它们可以由同一个主机管理，也可以分布在不同服务里，但所有引用和责任都要清楚。下面这张表是我们做 FoneClaw Android 任务时使用的思路。

审批和授权要分开看。授权说明系统允许某类访问，审批说明用户同意本次具体动作。设备状态也要重读，因为 Android 界面、默认应用、权限弹窗和网络状态都会变化。更深入的身份、权限和审计设计，可以阅读 AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent。

MCP Tasks、MRTR、澄清交互和审批如何协作

MCP 2026-07-28 把 Tasks 放进扩展框架，这给长时间运行的工作提供了更清楚的引用方式。一个任务可以返回句柄，后续请求用句柄查询进度、取消、继续或取回结果。MRTR 则让模型和工具在需要时进行多轮工具响应和澄清，适合“还缺哪个参数”“是否需要用户输入”“下一步是否继续”等交互。

在手机 Agent 场景里，Tasks 和审批各司其职。Task handle 标记的是一项工作或结果引用，审批记录标记的是用户对某个具体动作的确认。比如“发送短信给张三”这一步，需要收件人、正文、默认短信应用和发送控件都被核对，还需要用户对发送动作的确认。任务句柄帮助恢复流程，审批记录决定这一步是否可以产生外部影响。

澄清交互同样重要。用户可能说“给客户发一下”，Agent 需要追问客户是谁、正文是什么、是否马上发送。等用户补全后，任务状态继续推进。审批过期、设备状态变化、用户取消或权限撤销时，任务回到等待或恢复状态。MCP 提供更清晰的协议和扩展能力，手机 Agent 主机负责把它们接到 Android 的权限、审批和结果验证上。

在无状态 MCP 上运行有状态 Android 工作流

用一个短信任务可以看清结构。用户从悬浮助手说：“给李经理准备短信，说我十分钟后到，发送前确认。”FoneClaw 主机先生成任务状态：目标是短信，收件人是李经理，正文是“我十分钟后到”，外部影响动作是发送。主机为这条任务创建 taskId、correlationId 和幂等键，并记录当前入口与用户意图。

下一步，主机读取设备状态：默认短信应用是否可用，联系人是否明确，当前屏幕是否需要附加，Android 权限是否具备。涉及当前屏幕和悬浮助手连续性时，可以参考 Android 悬浮 AI 助手与当前屏幕：从提问到可控操作的完整指南。如果未来用 MCP 连接某个短信准备工具，请求本身可以是自描述的：包含工具名、任务引用、幂等键、收件人引用、正文和期望结果。

工具返回草稿准备结果后，FoneClaw 主机进入审批阶段：展示收件人、正文、发送应用和影响。用户确认后，主机再执行发送。执行前还要重读设备状态，因为默认短信应用、双卡提示、焦点控件或界面可能已经变化。发送后，主机验证结果：消息是否显示已发送，是否停在草稿，是否需要用户接手。失败时，任务记录原因并给出恢复路径。

电话任务也适合这个模型。MCP 电话工具和 Android 拨号器之间的选择，需要根据是否要拨号准备、是否要用户确认、是否要交给系统拨号器来判断。更具体的电话场景可以阅读 AI 智能体打电话：MCP 电话工具和 FoneClaw Android 拨号器流程怎么选。FoneClaw 当前产品通过受治理工具处理支持范围内的 Android 工作流，读者可在 FoneClaw 功能介绍查看当前能力范围。

扩展无状态 MCP 服务器，同时保持手机任务可靠

无状态 MCP 服务器的优势很直接：实例可以横向扩容，请求可以在多个实例之间分流，服务重启和部署更轻，Serverless 场景也更自然。MCP Go SDK v1.7.0 发布说明提供了一个官方 SDK 例子，说明新生命周期里的每请求元数据、服务器发现，以及对旧协议版本的兼容路径。

手机任务的可靠性来自另一套工程纪律。第一，外部影响动作必须有幂等键，避免网络重试造成重复发送、重复创建或重复修改。第二，重试要分类：读取状态和列出资源通常更安全，发送消息、拨号、改设置、删除内容需要去重、复核或人工确认。第三，每次执行前要重新检查设备状态，避免按旧屏幕继续动作。

第四，所有请求需要 correlationId，把对话、任务、工具调用、审批、设备结果和恢复记录串起来。第五，补偿动作要明确：能撤销的动作给撤销路径，适合重试的动作给重试路径，需要用户接手的动作停在可见界面。会议录音转成手机操作也是同样逻辑，相关流程可以看 AI 录音机 MCP：会议纪要如何变成经确认的手机操作。

安全边界和迁移检查清单

安全上，认证、授权、审批和审计要分层。认证回答“调用者是谁”，授权回答“它拥有哪些能力范围”，审批回答“用户是否确认本次具体动作”，审计回答“之后如何回看和追责”。MCP 2026-07-28 包含授权强化，但手机 Agent 仍要把 Android 权限、服务令牌、工具范围和用户审批分别记录。

迁移时，先确认客户端和服务器支持哪个 MCP 版本，再设计兼容路径。Go SDK v1.7.0 的发布说明显示了新协议生命周期和旧版本兼容的实现方向；实际部署中，还要检查其他语言 SDK、网关、缓存、负载均衡器和工具服务是否支持所需元数据。对已有工具，第一步是把隐式会话假设转成显式请求字段、state handle、幂等键和审计关联。

我们的迁移清单是：一，列出所有隐藏会话依赖；二，把身份、能力和协议版本放进每次请求；三，把长期任务改成显式句柄；四，为外部影响动作加幂等键；五，把审批绑定到动作、对象和有效期；六，执行前重读 Android 设备状态；七，结果验证和恢复路径写入任务账本；八，用日志串起请求、审批和结果。截至目前的最新信息，FoneClaw 已经提供悬浮助手任务连续性、权限恢复和快速动作，版本入口可见于 FoneClaw 下载页面。这些手机端状态能力，是我们评估任何未来连接器设计时的基础要求。