Qoder Cloud Agents 手脑分离实践：RocketMQ LiteTopic 如何支撑规模化长程 Agent 任务

Qoder Cloud Agents（简称 QCA）是 Serverless 模式的云端 Agent 托管与执行服务。Qoder Cloud Agents 在 9 月 16 日正式发布 1.0 版本，月调用量超千万。业务应用通过 Agents API 提交目标和上下文，QCA 组织模型推理与工具执行，保存任务进展，再将过程事件和任务结果返回应用。

当 Agent 从个人电脑上的单机实践走向承接生产业务的云端服务，核心问题随之转变为：如何让任务持续运行，并将执行资源用于真正需要计算的步骤？

一个完整的 Agent 任务可能经历模型推理、工具调用和人工确认等环节。完成当前环节后，任务有时需要等待外部结果或用户补充信息；等待期间，当前执行实例可能不再进行计算，但任务状态仍需保留，以便条件满足后继续执行。

本文将介绍 QCA 基于 RocketMQ LiteTopic 的手脑分离架构实践：把模型推理和工具执行拆开，通过事件交接，让执行资源按需工作。

Qoder Cloud Agents

长程任务的规模化运行挑战

Cloud Native

▍1. 三类业务场景，共同的持续运行需求

QCA 面向三类典型业务场景：

Agent 助手：由用户需求触发，通过多步查询和分析交付结构化结果，例如投研助手、个人助手；
高并发长程任务：由业务记录持续驱动，识别问题后交给团队复核，例如客服质检、告警运营；
专业方法服务化：把专家的方法整理成 Skill，让团队按照共同标准调用与验收。

这些任务的触发方式和执行形态不同，但随着任务规模扩大，都要求平台可靠地承接持续运行的任务。

▍2. 任务时长、在途并发与事件速率

评估 Agent 规模化运行的压力，需要同时关注三种不同的容量口径：任务时长、在途并发和事件速率。任务时长指一次任务从开始到完成需要多久；在途并发指同一时间有多少会话尚未结束；事件速率指单位时间内产生的请求或事件数量。

当任务持续时间较长且任务持续进入时，入口 QPS 与平台实际承载的压力会出现差异。即使瞬时新请求不多，尚未完成的任务也可能逐渐累积，形成大量在途会话。这些会话有的正在计算，有的在等待工具结果或人工输入；任务推进过程中，还会继续产生模型命令、工具结果和进度通知。入口请求结束并不意味着任务已经完成，后续工作仍会继续。

因此，平台不能只根据入口 QPS 估算容量，还需要综合考虑任务时长、在途会话数量和任务内部产生的事件。平台既要用有限的执行容量处理当前计算步骤，也要持续保存大量在途任务的状态。

▍3. 会话状态与计算资源解耦

面对大量处于不同阶段的在途会话，关键不是让同一个执行实例始终绑定同一任务，而是将任务生命周期与计算生命周期分开：

会话承载需要持续保留的上下文和任务进度；
执行实例负责完成当前这一段计算。

如果会话始终绑定同一执行实例，即使当前步骤已经完成、只是在等待用户确认，该实例仍无法承接其他任务。按步骤接手时，平台只在需要计算时分配执行容量；任务进入等待后，保留任务进度并释放执行容量；新的输入或外部结果到来后，再形成新的执行轮次，由可用实例接手后续步骤。

等待本身仍然有成本，会话状态、保留文件和平台基础资源都会产生开销。将状态保存与计算占用分别管理，可以在保留任务等待状态的同时，把释放出来的执行容量用于其他工作。

QCA 基于 RocketMQ

LiteTopic 的手脑分离架构

Cloud Native

完成任务生命周期与计算生命周期的分离后，下一步是解决模型步骤和工具步骤如何有序交接，并让不同执行资源按需接手。

QCA 使用 RocketMQ LiteTopic 组织任务通道，把模型推理与工具执行拆开，通过事件交接，让执行资源按需工作。

▍1. Agent Runtime 协调，模型与工具分池执行

在这套手脑分离架构中，各部分承担不同职责：

Agent Runtime：任务推进的协调者。负责根据“当前有哪些结果，哪些依赖已经满足”，判断下一步该调用模型，还是派发工具。
模型执行池：承担当前模型步骤。模型命令经由消息交给可用实例，推理完成后返回模型结果，其中可能包含一个或多个工具请求。
工具执行端：承担当前工具步骤。它按需调用远程 API、Model Context Protocol（MCP）服务或 Sandbox，并将工具结果直接返回 Runtime。
共享持久状态：保存历史、进度与结果。即使单次计算结束，任务事实仍可保留，后继实例也能据此继续执行。
RocketMQ：负责模型命令、模型结果和工具指令的异步交接。工具结果直接返回 Runtime，由 Runtime 负责归并结果、检查依赖，并决定后续动作。

职责拆分后，工程难点集中在三项：

状态可续：换一个实例接手时，必须能重建当前步骤需要的上下文；
有序交接：独立分支可以并行，但共享结果要按依赖关系归并；
运行可控：配额暂时不足时可以等待，发生异常时也能定位至具体步骤。

分布式设计改变的是资源占用和任务交接方式，并不自动缩短单次模型推理或工具调用。独立执行池可以分别管理容量，但状态恢复、依赖归并和运行策略也会增加复杂度。

▍2. LiteTopic 的细粒度业务通道机制

RocketMQ LiteTopic 是一种用于承载细粒度业务消息的轻量通道机制。Parent Topic 预先配置，统一管理一类工作；应用根据业务规则设置 LiteTopic 通道。通道内的消息有序处理，不同通道之间可以并行，也无需为每个短期任务单独维护普通 Topic。

这与长程 Agent 的工作负载特征相匹配。任务的执行路径会在运行过程中不断展开，模型可能产生新的工具请求、派生独立分支，或者等待运行前无法预知的外部事件。如果所有任务共享少量通道，同一通道中的某个长步骤或容量等待可能影响其他任务；如果为每个短期任务分别维护普通 Topic，又会增加管理成本。

在这套架构中，LiteTopic 用于承载任务步骤之间的细粒度业务交接。共享执行池根据可用容量接手计算步骤，通道数量不需要与执行实例数量一一对应；模型和工具也可以按职责使用不同的执行池。

应用定义通道边界，LiteTopic 负责通道内消息的有序交接，执行池负责运行计算步骤。例如，多分支场景可以按分支设置通道；Webhook 回调可以按 Endpoint 设置通道，使同一接收端有序处理、不同接收端并行。

▍3. 共享消息正文与轻量消费索引

LiteTopic 的每个细粒度通道并不对应一份独立的消息正文副本。同一条消息即使对应多个目标 LiteTopic，正文也只写入 CommitLog 一次；Multi-Dispatch 为各目标 LiteTopic 建立消费索引，无需复制正文。

普通消费队列按照 Topic 和 Queue 定位消息，LiteTopic 则使用基于 RocksDB 的 KV 索引组织消费位置。由此形成双层模型：父 Topic 预先配置，LiteTopic 按需建立消费索引，消息正文保持共享，通道的过期与回收通过配置管理。

相较于为每个短期任务维护普通 Topic，这种方式降低了细粒度业务通道的管理成本，更适合任务持续产生的场景。

▍4. Suspend 暂缓相应通道的本次消费

有了 LiteTopic，消费端还需要控制何时接手。消费端收到消息后先检查容量：配额不足时返回 Suspend，暂缓相应通道的本次消费，并在后续投递时重试；容量满足时执行当前步骤、产出该步骤的完整结果，并确认消费成功。

Suspend 仅暂停相应通道的本次消费，其他独立通道仍可并行处理。待处理消息保留在消息系统中，消费实例可以继续服务当前能够执行的任务。

配额设置、任务优先级和重试时机仍由应用策略决定。消息系统提供交接和消费控制，运行策略需要结合业务约束制定。

QCA 复杂任务的异步运行流程

Cloud Native

▍1. 模型与工具的消息接力流程

在一轮完整执行中：

运行时先发布模型命令，经由 RocketMQ 交给模型执行池；
模型完成当前步骤，返回的结果中可能包含一个或多个工具请求，模型结果经由 RocketMQ 交接回到运行时；
运行时归并模型结果、登记依赖，再发布工具指令，经由 RocketMQ 交给工具执行端；
工具执行结束，结果直接回传运行时；
依赖齐备后，运行时生成下一条模型命令，带着工具结果继续推理。

整个过程采用接力式执行：任务进度持续保存，执行资源仅负责当前步骤，后继步骤由运行时调度。

▍2. 复杂场景如何推进

复杂场景也沿用同一套交接方式：计算步骤可以更换执行实例，任务的关联关系和进度由持久状态保持。

多分支协作：各分支的模型命令由模型执行池独立消费、并行执行，结果返回 Runtime，由 Runtime 按会话归并；依赖齐备以后，再继续推进后续步骤。
协作与取消：协作消息进入持久化的 Mailbox，到任务允许接收新消息的边界时再处理；取消操作通过独立控制通知下发，先更新取消状态，再中止相关执行。
Webhook 回调：按接收端 Endpoint 建立 LiteTopic，让同一接收端有序处理、不同接收端并行，同时约束超时和重试预算。
挂起与恢复：任务等待用户、工具或子 Agent 时，运行时先保存进度，并在相关事件返回后派发后继步骤。

▍3. Sandbox 按需运行与任务进度持久化

模型推理与工具执行分离后，Sandbox 也可以按需使用：纯模型推理由模型执行池承接；远程 API 和 MCP 调用由工具执行端发起、对应的远端服务执行；只有需要隔离代码或文件工具时，才准备 Sandbox。

预热、复用、回收以及暂停后的恢复程度，取决于策略和后端能力。文件得到保留并不意味着原进程能够原样恢复。按需使用 Sandbox 的核心价值，是减少无须占用 Sandbox 的等待时间，而不是保证执行现场无损恢复。

从完整架构看，任务事实由持久存储承载：数据库保存会话与任务状态，对象存储保存文件和产物；取消等瞬时控制信号和过程预览用于控制与观测，不能作为任务事实的主存。入口、协调、交接、执行和持久状态各有职责，共同构成运行底座。

是否采用这类拆分，应综合评估任务时长、等待占比、状态恢复要求、顺序边界能否按业务单元划分，以及容量隔离收益能否覆盖分布式复杂度。

结语：让任务持续，让计算按需

Cloud Native

QCA × RocketMQ LiteTopic 的这套实践，并不试图缩短单次模型推理或工具调用，而是解决长程任务如何持续推进：任务事实得到保存，模型与工具步骤能够交接，独立分支可以并行，容量不足时只暂缓相关通道；RocketMQ 承接了云端Agent有状态部分，让 Agent 计算集群可以无状态快速横向扩缩容，支撑更大规模的并发与容量。

这套实践通过持久状态、异步交接和细粒度消费控制，使等待中的任务能够保留进度，也让可用实例继续承接真正需要计算的步骤。

如果你正在建设类似的长程 Agent 运行架构，欢迎进一步交流 LiteTopic 的实践方式与适用边界。

钉钉群号：206725000392

📖 点击「阅读原文」了解 RocketMQ for AI 完整方案。