在接手 Agent 相关项目之前我一直把 Agent 当成一个函数在调输入一段 prompt等一个最终输出完事。直到流量真正起来以后才发现这个想法错得离谱。一个 Agent 任务可能运行几十秒甚至几分钟中间要规划、要调工具、要读记忆、要等大模型流式返回它不是函数它是一段有生命周期、有状态、有外部依赖的负载。如果不把 Agent 当集群负载去设计并发一上来整个系统会非常难看。最近我集中研究了 Google AX 和 Substrate 这两套东西越看越觉得它们是在回答同一个问题当 Agent 变成高并发任务时到底应该怎么调度、怎么排队、怎么保证不把自己拖垮。这篇文章就结合我的实际工程经验把这三件事放一起拆开聊为什么 Agent 适合当集群负载、Google AX 的调度设计好在哪、Substrate 的编排基座怎么配合使用以及真正落地时会遇到哪些坑。1. 先想清楚Agent 是负载不是服务如果你只是在本地脚本里跑一两个 Agent把 main 函数里 new 一个实例然后 run 一下完全没有问题。但一旦你要把 Agent 能力开放给业务方、要支撑多个用户同时提问、要接多个渠道就必须换一个视角。Agent 的并发模型和普通接口请求完全不同这一点不先想明白后面所有方案都会别扭。1.1 Agent 的运行特征长耗时、多阶段、有状态普通 HTTP 请求一般几百毫秒内就能返回而一次 Agent 任务尤其是带 ReAct 循环那种经常是几十秒起步。这个差异直接影响并发估算假设你的服务 QPS 是 100普通请求平均耗时 0.2 秒那在线并发大约只有 20 个但如果换成一个平均耗时 40 秒的 Agent 任务同样 100 QPS在线并发会变成 4000 个。100 个请求/秒的流量不算高可一旦换成 Agent瞬间就是一个中型集群的压力。Agent 还特别能吃资源。它内部不是一次大模型调用而是多轮调用。每一轮还需要处理中间状态当前计划、已观察到的结果、记忆里的历史信息、工具返回的结构化数据。这些状态如果只放在进程内存里worker 一重启任务就断了。我见过不少项目Agent 跑一半崩溃重启后之前的上下文全没了只能重新开始用户体验非常差。另外Agent 的失败模式也比普通服务复杂。它要同时依赖大模型接口、工具 API、内部知识库、可能还有外部搜索。任何一个环节变慢整个 Agent 任务都会被拖住。普通服务超时了可以快速返回错误Agent 超时了你还要决定是重试、回退还是降级处理逻辑复杂得多。1.2 负载化的含义从常驻实例变成可调度任务把 Agent 当集群负载核心是改变看待它的方式。不要把 Agent 想成一个常驻服务实例而要把它想成一个“任务单”每一个用户请求、每一个会话、每一个待执行的子任务都生成一张任务单放进队列。集群里的 worker 从队列里取任务执行完后标记完成。这一层抽象看起来简单但收益很大。首先是并发可控。你可以精确限制任何时刻有多少个 Agent 在真正运行而不是让用户请求直接打到 Agent 实例上导致线程池瞬间被打爆。其次是扩缩容容易。任务都在队列里worker 是无状态的流量大了加 worker流量小了减 worker不需要迁移任何运行中的状态。最后是故障隔离。某个任务写得再烂最多影响它所在的 worker队列会把新任务派发给其他健康 worker不会造成全局雪崩。我在实际项目中见过一个特别典型的反面案例初期没有任务队列每个请求直接起一个线程去跑 Agent。上线第三天流量翻倍线程数直接破千大模型接口还没来得及限流整个 Java 进程先被 OOM 打挂了。后来改成队列加 worker 池同样是翻倍流量系统稳如泰山只是队列长度变长了一点用户体验反而更可控。这就是“负载”和“实例”的区别。2. 拆解 Google AXAgent 执行引擎的并发模型Google AX 这个名字我理解它代表 Agent Execution 这一层抽象。它不关心你写的是什么样的 prompt也不负责管理你的业务知识库它只关心一件事怎么把一个 Agent 任务高效、稳定、可观测地执行完。这套设计里最值得学习的是它对任务阶段的拆分和并发控制。2.1 AX 的核心抽象把一次运行切成阶段AX 把 Agent 的一次运行拆成了多个阶段输入组装、规划、工具调用、状态读写、模型推理、结果输出。每个阶段都有明确的输入输出边界有独立的超时预算也有独立的错误统计。这个设计看起来有点“重”但对排障非常有价值。举个例子。你有一个 Agent 在用户问“帮我查一下天气并设置提醒”时卡住了。在没有阶段划分的架构里你只能看到一个黑盒整个任务超时。但用 AX 的阶段模型你会看到工具调用阶段花了 25 秒其中天气 API 那一环就用掉了 20 秒而模型推理只用了 2 秒。问题定位几乎瞬间完成。阶段拆分对负载调度的意义更大。因为每个阶段的资源消耗和耗时特征不一样你可以针对不同阶段配置不同的并发策略。比如大模型推理阶段最容易触发上游限流那么这里可以单独加令牌桶工具调用阶段可能依赖外部系统则要设置更短的超时避免一个慢 API 拖死整个任务。2.2 队列、最大并行数和背压机制AX 在并发控制上采用了非常经典的 worker 拉模型内部维护一个任务队列一组固定数量的 worker 从这个队列里消费任务。每个 worker 同一时间只处理一个 Agent 任务通过参数 max_inflight 控制整个执行引擎同时运行的任务数。我不确定 AX 内部是否真的叫这个名字但这类设计几乎是 Agent 执行引擎的标配。拉模型的好处是天然具备背压能力。如果上游把任务推给执行引擎引擎处理不过来时只能把请求缓存起来或者直接拒绝还得自己实现一套限流逻辑。而拉模型下worker 处理完一个任务才会去取下一个队列就是天然的缓冲区。队列积压只是说明系统繁忙不会导致进程崩溃。自己在做 Agent 平台时这个设计完全可以照搬。不过要注意队列长度是有限度的。如果任务堆积太多说明消费者能力跟不上了。这时候继续往队列里塞任务并不会解决问题只会让用户等待时间越来越长。AX 的做法是设定队列阈值超过阈值就从入口直接返回“当前繁忙请稍后重试”而不是傻傻地排队。这其实是保护整个集群不回退雪崩的关键。2.3 从 AX 学到的超时、重试与状态管理AX 对超时的处理也很细致。它不是给整个 Agent 任务一个总超时而是每个阶段分别设置 deadline。总超时是 60 秒可能规划阶段 10 秒模型推理 20 秒工具调用 15 秒其他操作 15 秒。阶段级超时能避免一种非常常见的“卡死”Agent 在某个工具调用上阻塞了但任务总超时还没到整个系统被无效占用。重试策略同样分阶段。工具调用因为网络抖动失败可以快速重试两次每次退避 1 秒模型推理因为上游限流失败则不再重试直接进入降级分支状态写入失败则要检查幂等性不能盲目重试。这些策略看似繁琐但都是真实运行中最值得花时间打磨的细节。我见过太多项目把 Agent 重试做成“失败就整体重来”结果不仅浪费了大量大模型调用还把状态写重了。还有一个值得关注的点AX 的推荐做法是让状态外置。执行引擎本身不保存 Agent 的会话状态而是通过 state_ref 指向外部的存储。每个阶段完成时把当前上下文快照写回存储。这样即使 worker 崩溃新的 worker 可以从最近一次快照恢复而不是从头再来。这个思路我会在第 4 节详细展开。3. 拆解 SubstrateAgent 编排基座的插件化思路如果说 Google AX 是一台“能跑 Agent 的发动机”那 Substrate这里说的是 Agent 圈子里那套编底层不是区块链领域同名的那个更像是一套“接口约定”。它不直接给你一个完整调度器而是把 Agent 运行过程中需要的公共能力事件钩子、记忆接口、工具注册、生命周期管理都定义成标准组件让上层业务可以把任意 Agent 接进来。3.1 Substrate 的核心组成Hook、Memory、Tool RegistrySubstrate 这一类 Agent 编排基座最常见的抽象包括三块。第一是 Hook也就是生命周期回调。Agent 在开始、结束、工具调用前、工具调用后、模型调用等关键节点都会触发相应的钩子函数。第二是 Memory它把记忆存储抽象成统一接口底层可以用向量数据库、Redis、普通数据库上层一致通过接口访问。第三是 Tool Registry所有 Agent 可调用的工具都要注册到这里调度层可以统一做权限校验、限流、审计。Hook 是对负载化最重要的一个设计。因为它给了我们在不改 Agent 内部代码的前提下把任务接入队列、设置追踪、上报指标的能力。比如我想知道每个 Agent 任务在队列里等了多久只需要在 Agent 开始执行的钩子里记录入队时间在结束的钩子里计算差值不需要侵入业务代码。我之前做的一套监控系统就是靠这类钩子把数十个不同团队开发的 Agent 全部纳管了没有让团队成员改一行 Agent 核心代码。Memory 接口的外置也很关键。它强制要求 Agent 不要依赖进程内的全局变量保存上下文而是通过统一的 Memory API 读写。这一点对集群负载特别重要因为只有把上下文从“内存”搬到“可寻址的存储”任务才可能被调度到任意一个 worker 上执行而不至于出现“这个任务只能由原来那台机器处理”的尴尬。3.2 在 Substrate 上实现 worker 池和队列消费有些朋友会误以为用了 Substrate 就不需要队列了其实不是。Substrate 提供的是执行层和能力层队列和 worker 池还是要在上层自己组装。做法也很直观外部请求到来时生成一个 AgentTask 对象推到消息队列worker 进程从队列里拉取任务在 Substrate 的运行时里创建 Agent 实例执行任务。关键在于worker 进程完全不感知业务逻辑它只做四件事从队列取任务、给任务分配一个运行时上下文、执行并等待结果、把结果写回。所有 Agent 内部的工具调用、模型调用、记忆读写都通过 Substrate 的 Hook 上报给上层。这样你的整个 Agent 集群就成了一个标准的“任务生产者—队列—任务消费者”模型任何一个环节都可以独立扩展。我建议在接入 Substrate 时把“任务入队”“任务开始”“任务结束”“任务失败”这四个 hook 点第一时间接上。入队时生成唯一的 trace_id任务开始时记录 worker 信息和开始时间任务结束时记录耗时和 token 消耗任务失败时记录错误类型和堆栈。这四类数据是整个 Agent 集群可观测性的地基后面无论做监控、做限流还是做容量规划都从这里取数。3.3 对比执行引擎与编排基座的互补关系经常有人问Google AX 和 Substrate 是不是二选一。从我的经验看它们根本不是同一个层次的东西更适合组合使用。AX 偏重“单个任务怎么跑得又快又稳”解决的是执行层的并发、超时和阶段化问题Substrate 偏重“Agent 怎么构建和组织”解决的是组件解耦、记忆管理和扩展性问题。在实践中你可以用 Substrate 的规范把 Agent 的各个零件拼起来然后在最外层用 AX 风格的执行引擎作为 worker 运行时控制实际并发和任务生命周期。换句话说Substrate 定义 Agent 长什么样AX 决定 Agent 怎么被调度和执行。两者结合正好构成一套完整的“把 Agent 当集群负载”的落地框架。4. 落地实战把 Agent 变成集群负载的完整方案聊完了理念和框架下面给出一套可以直接参考落地的方案。这里不绑定任何具体云厂商也不依赖特定框架核心是用消息队列加无状态 worker把 Agent 任务变成标准负载。整个方案分四步走。4.1 定义统一的任务格式所有 Agent 任务的入参先统一成一个 Task 对象。我在项目里最常用的一种定义是这样的dataclass class AgentTask: task_id: str # 全局唯一任务ID agent_type: str # 指定用哪个 Agent 处理 payload: dict # 业务传入的参数 max_duration: int 60 # 任务总超时秒 priority: int 0 # 优先级越大越先处理 idempotent_key: str # 幂等键防止重复执行 state_ref: str # 状态存储引用例如 redis keytask_id 和 idempotent_key 是两个很容易被混淆的字段。task_id 是任务的唯一标识每次生成一个新的用于追踪日志、关联 traceidempotent_key 则用于幂等判断它往往来自业务侧比如“用户ID会话ID”。同一个幂等键如果已经存在执行记录新的任务会被丢弃或合并而不是重复执行。这个字段对解“重复消费”问题特别关键。state_ref 是状态外置的关键。它不是一个具体的上下文对象而是一个“引用”比如 Redis 里的一个 key或者对象存储里的一个文件路径。worker 拿到任务后先从 state_ref 读取已有的上下文执行过程中定期写回结束后再写一次。这样任务本身只携带很轻量的元数据真正的状态都存放在集群外部。4.2 用消息队列承载 Agent 任务队列选型方面不需要一上来就上重型的分布式消息平台。如果团队规模不大Redis Stream 或者 RabbitMQ 完全够用。如果已经是微服务架构可能会优先考虑 Kafka但要注意 Kafka 的消费模型更适合高吞吐日志类数据用在 Agent 任务上需要额外处理死信和回滚。就我的经验RabbitMQ 的 basic_qos 设置非常匹配 Agent 场景。关键配置有三个。一是消费者 prefetch 设置为 1确保每个 worker 同一时间只处理一个 Agent 任务。Agent 任务不像普通消息那样毫秒级处理完prefetch 太高会导致消息分派不均一个 worker 手里囤一堆任务其他 worker 空闲。二是为每个 agent_type 建立独立队列避免一个慢 Agent 阻塞其他类型的 Agent。三是单独设置死信队列凡是重试多次仍然失败的任务统一进入死信队列由人工或补偿脚本处理。下面是一份简化的队列配置参考我实际项目里基本就是这样跑的queue: agent_tasks: durable: true max_length: 10000 overflow_policy: reject_publish # 队列满了直接拒绝防止无界积压 consumer: prefetch: 1 max_retries: 3 backoff: exponential # 1s, 2s, 4s dead_letter: queue: agent_tasks_dlq注意 overflow_policy 要配成 reject_publish。这样队列满了以后新任务会在入口被拒掉由调用方决定是降级还是稍后重试而不是把所有任务都堆在一个无限长的队列里导致用户等待时间变得不可控。这跟 Google AX 的背压思路是一致的。4.3 状态外置把记忆和上下文搬出进程Agent 的上下文应该放哪里是集群负载方案里最容易被低估的问题。我先说结论不要放在 worker 的内存里。原因很简单worker 是随时可能被杀、被重启、被替换的只要上下文在内存里这个任务就“绑架”了 worker根本没法做故障转移和弹性伸缩。我的做法是每个任务在执行前从 state_ref 指向的存储里加载上下文。执行过程中每完成一个关键阶段比如一次模型调用结束、一次工具调用结束向上回写一次上下文。执行完成后写入最终结果并把任务状态置为 done。存储可以用 Redis数据结构上直接存 JSON 字符串简单可靠如果上下文很大可以把这部分放到对象存储Redis 里只存一个指向对象存储的引用。这个设计带来的最大收益是 worker 可以随时被替换。比如某台机器的内存报警运维可以直接杀掉这个 worker 进程把 queue 里的消息重新投递给其他 worker。新的 worker 从 state_ref 加载最近的上下文继续执行用户只会感觉稍微慢了一点但不会从零开始。这在单体 Agent 架构里是做不到的。4.4 扩缩容、优雅下线与健康检查当所有 worker 都是无状态消费队列时扩缩容就变成了一个很纯粹的容量问题。流量高峰期在 worker 池里增加节点每个新节点启动后自动订阅队列开始消费流量降下来销毁多余节点。这里要注意一个细节销毁 worker 不能直接 kill 进程。一个 Agent 任务可能正在调用外部工具直接被 kill 会导致任务处于不确定状态。我建议的优雅下线流程是这样的先向 worker 发送一个停止信号worker 收到后把自己的消费状态标记为“不再拉取新任务”然后等待当前正在执行的任务完成。为了不让等待时间无限长我们通常会设置一个宽限期比如 30 秒。宽限期内任务还没结束worker 就把任务标记为可重投递让其他 worker 继续处理。注意“可重投递”和“重试失败”是两件事前者是因为 worker 要下线了任务本身没有错所以投递后要正常执行而不是进死信。健康检查同样重要。每个 worker 要定期上报心跳报告自己正在处理的任务数、内存占用、最近一次模型调用的延迟。调度中心看到某个 worker 心跳超时会把它从消费组里踢掉并把它的未完成任务重新投递。这一套做完Agent 集群才真正具备了基本的自愈能力。5. 常见问题与排查技巧实录方案说完了接下来这部分是我踩过最多的坑。说实话Agent 集群负载方案最大的难点从来不是“把 Agent 塞进队列”而是跑起来之后遇到的各种诡异问题。我把常遇到的几类问题列一个速查清单希望对你有参考价值。5.1 Agent 静默卡死没有任何报错日志这是 Agent 项目最让人头疼的问题。任务既不失败也不结束日志里最后一条记录停在“正在调用天气接口”然后就再也没有然后了。排查的时候你去看天气接口发现它其实早就返回了只是 Agent 的 HTTP 客户端一直挂在连接等待上。根因大多是客户端超时没设置。Python 里 requests 默认没有超时OpenAI SDK 如果没配 timeout 参数某些网络环境下也会长时间阻塞。解决方法是给所有外部调用统一设置连接超时和读超时更激进一点可以在 Hook 层用一个统一的装饰器包裹所有工具调用强制加 context deadline。别忘了大模型调用也要设置超时不要以为 SDK 内部已经处理好了。我后来做了一道硬性规定任何工具调用必须有 timeout否则代码评审不通过。这个规则很粗暴但是有效。5.2 并发一高上游限流报警一片明明队列和 worker 都做了大模型接口还是狂报 429。原因很简单你虽然限制了 worker 数量但每个 Agent 内部有多轮模型调用一个 worker 可能在跑一个 Agent 的间隙其他 Agent 的模型调用并发仍然会叠加。也就是说worker 池限制的是 Agent 任务数不是大模型 API 调用数。这时候要把限流点放在队列层而不是 Agent 内部。我常用的办法是在 worker 里设置一个全局令牌桶预取任务时先检查令牌令牌不够就稍等一下再取。令牌桶的速率按大模型接口的配额来定比如每分钟 600 次那令牌就是每分钟 600 个。另外一个技巧是按模型维度分流不同模型走不同的队列和 worker别让一个重型模型的限流把轻量 Agent 的任务也堵死。5.3 Agent 任务被重复执行数据写了两遍队列系统的“at least once”投递语义是出了名的也就是说正常情况下也存在消息被重复消费的可能。worker 在处理任务时崩溃消息可能被重新投递给另一个 worker另一个 worker 又把工具调用执行了一遍。对于可重复的工具还好如果工具是“创建订单”“发送短信”这就是事故。解决思路就靠幂等。核心实现是在执行真实动作前先检查 idempotent_key 是否已经处于 running 或 done 状态。如果已经 running直接放弃本次执行如果已经 done直接返回之前的执行结果。状态检查要和“写入状态”做成原子操作这样才能避免两个 worker 同时拿到同一个任务同时认为自己是第一次执行。实际项目里用 Redis 的 SETNX 或数据库唯一约束都能解决关键是不要漏掉这个设计。5.4 一个任务把整个 worker 拖死有些 Agent 任务特别能吃内存比如它往上下文里塞了大量搜索结果或者模型返回了很长的中间推理过程。如果不做限制一个异常任务很可能把进程内存撑爆。传统线程池根本没太关注这个但在 Agent 集群里一个 worker 挂了还算小事如果它是一个进程里跑多个 worker 的模式就可能影响其他任务。最简单的控制手段是给 worker 设置资源上限。容器环境里直接限制内存和 CPU进程模式里可以用每个 worker 一个进程的方式隔离。不要在一个进程里开几十个线程跑 Agent 任务我个人的经验是线程模式排查问题时非常痛苦一个死循环线程导致 CPU 高居不下但你不知道是谁。进程隔离虽然重一点但问题定位路径清晰很多。5.5 怎么快速定位 Agent 集群瓶颈如果整个集群性能下降不用猜直接用数据说话。我通常会把一次 Agent 任务的耗时拆成四段排队耗时、模型调用耗时、工具调用耗时、其他处理耗时。这四段分别有对应的埋点。耗时阶段来源对应排查方向排队耗时入队时间到 worker 取到任务队列积压、worker 数量模型调用耗时每次 LLM 请求的开始/结束API 限流、模型选择、上下文长度工具调用耗时每次工具请求的开始/结束外部 API 稳定性、超时配置其他耗时任务执行 Hook 间隔序列化、内存读写、业务代码只要这四段数据齐了大部分瓶颈一眼就能看出来。排队耗时高就扩 worker模型调用耗时长就查上游配额和 prompt 大小工具调用耗时长就重点治理外部依赖。没有这些埋点排查 Agent 问题基本就是靠猜效率非常低。6. 写到最后的一点体会这套“把 Agent 当集群负载”的方案我前后大概迭代了三个版本。第一版只是简单加了队列第二版补上了状态外置和优雅下线第三版才真正把阶段耗时、幂等、背压这些细节补齐。回过头看早期我最大的认知误区就是以为 Agent 平台的核心是模型选型和 prompt 工程实际上当业务量上来以后真正决定系统能不能活下去的是调度和负载治理的基本功。如果你的 Agent 项目现在还很初级我建议先别急着追求特别复杂的框架按 4.3 节的状态外置、一个消息队列、一组无状态 worker这三件事做起来就已经能解决 80% 的并发稳定性问题。等真的需要更强调度能力时再往谷歌 AX 那种阶段化执行器、Substrate 那种完整编排基座靠拢也不迟。毕竟方案是为业务服务的不是业务为方案服务。