阿里云提出以 RocketMQ LiteTopic 为每个 MCP（模型上下文协议） 任务保存状态，开源 mcp-tasks-rocketmq 实现
阿里云技术博客介绍一种为 MCP（模型上下文协议）异步任务保存状态的方案：每个任务分配一个 RocketMQ LiteTopic 通道，任务生命周期消息即状态账本，使无状态的 MCP 服务副本可重启和扩容而不依赖单副本内存。
实现已开源在 Apache RocketMQ 的 AI（人工智能） 仓库，文章未给出大规模生产环境实测数据。
文章署名为 Jingquan，发布于阿里云官方博客。 文中称 MCP（模型上下文协议） 的 Tasks 扩展（SEP-2663，已定稿）定义异步任务机制：服务端对长任务先返回任务 ID（taskId），客户端可通过轮询 tasks/get 或订阅 notifications/tasks 获取结果；
但协议未规定任务状态存在哪里，并引用 SEP-2575“Make MCP Stateless”要求服务端无状态。 文章指出把状态放在单副本内存会导致换副本查不到任务、副本故障丢状态、客户端无法区分任务不存在与请求打错副本三类问题。
其方案 Task as LiteTopic 为每个任务建一个轻量通道，提交时写入 working 状态并持久化后才返回句柄，执行池写回终态，任一副本查询时读取通道消息序列。 文章称写入顺序即读取顺序，最后一条消息即当前状态； 并称需工具幂等才能安全重投，转账、发邮件等外部副作用需应用自行保证幂等。
实现位于 apache/rocketmq-ai 的 mcp-tasks-rocketmq/ 目录（Python），examples/ 下有端到端示例； LiteTopic 已合入 Apache RocketMQ 主分支。
这条报道把 Agent（智能体）工具调用的可靠性问题具体化为工程问题：协议层只定义任务句柄与查询方式，状态持久化留给实现者。 以消息队列充当状态账本，理论上同时解决副本切换、故障恢复与横向扩容，但代价是把幂等责任推给工具实现方——对有外部副作用的工具，这仍是生产部署硬门槛。 文章未披露延迟、吞吐或故障注入测试结果，因此“不丢任务”目前属设计主张而非实测结论。
后续观察信号
- MCP（模型上下文协议） Tasks 扩展的正式规范文本与 SDK（软件开发工具包） 支持情况
- RocketMQ LiteTopic 的容量上限与回收机制细节
- 有外部副作用的工具在至少一次投递下的幂等实践