最近大半年我陆续接触了不少跑在生产环境里的 AI Agent 项目大家遇到的情况出奇一致Demo 阶段一切正常一旦放量接入真实业务账单和延迟一起往上飙架构师开始挠头运维开始甩锅。有人把锅扣在模型 API 太贵有人怪提示词写得太啰嗦但真正的问题往往在更底层——传统云架构那套为 Web 请求设计的家底压根就不是为 Agent 这种长会话、高状态、强突发的工作负载准备的。这个现象背后有个很值得聊的方向Agent 编排方式正在被重新定义。标题里提到的 Google AX我把它理解为 Google 在 Agent 基础设施层面一系列思路的浓缩代号它想解决的核心矛盾就是把编排的重心从“资源调度”挪到“上下文调度”上。这篇文章我会从传统云架构为什么撑不住讲起拆解 Agent 场景下真正需要被治理的几个对象再把可落地的编排迁移路径和排查经验一并整理出来。适合正在做 Agent 应用、或者准备把 Agent 接入生产环境的后端、架构和平台 team 同学参考。1. 先看清问题Agent 的工作负载为什么让传统云架构难受1.1 一个 Agent 会话本质上是一条“长周期状态机”先做一个简单的对比。传统 Web 请求的生命周期通常是几百毫秒到几秒请求进来业务逻辑跑完响应返回连接关闭一切干净利落。即便遇到复杂一点的业务比如报表导出、批量任务提交也可以通过异步消息队列把任务拆开让不同 worker 各领一块各跑各的互不打扰。Agent 不一样。一次用户提问Agent 可能要经历“理解意图 → 规划步骤 → 调用工具 → 读取结果 → 修正计划 → 再调下一个工具”的循环这个循环里面每一轮都要和 LLM 做一次推理交互而每一轮推理又依赖前面所有轮次产生的中间结果。换句话说Agent 会话是一个有状态、长周期、前后强依赖的执行链路而且它的状态不是固定几个字段是一大坨不断增长的对话历史和工具调用记录。我见过最典型的案例是一个做企业知识库问答的 Agent用户问一句“帮我分析一下上季度华东区销售数据异常的原因”Agent 一口气调用了 BI 查询、数据权限核验、异常检测、报告生成四个工具整个链路跑了 6 分多钟。这期间传统网关早就把请求超时掐断了要不是他们提前改成了异步任务模式这个会话根本跑不完。这就是第一个冲突点传统架构的服务粒度是“一次请求”Agent 的服务粒度是“一段会话”。1.2 云原生的弹性是为无状态服务设计的很多团队听到 Agent 要规模化第一反应是“那就多开几个 Pod 嘛反正云原生能扩”。这个思路在普通微服务场景是对的但放到 Agent 场景就有问题了——无状态服务可以随便扩缩因为任何实例都能处理任何请求Agent 却不行同一个会话的上下文如果散落在不同实例上这个 Agent 就“失忆”了。你可能会说把上下文放到 Redis 里每个实例从 Redis 读不就一致了吗理论上没错但实际操作里你会发现两个麻烦一是每次工具调用都要把历史上下文搬进搬出几千 token 甚至上万 token 的序列化和反序列化开销在高并发下非常可观二是 Agent 内部的一些运行时状态比如当前执行到哪一个规划步骤、已经重试了几次、哪几个候选分支还挂着没跑完这些东西全部外置后协调复杂度会爆炸。说白了传统云架构的弹性假设是“实例等于无状态的执行单元”而 Agent 场景里真正的工作单元是“带有连续记忆的会话”。基础设施要支撑的不应该是单纯加实例而是如何让一段会话在整个生命周期里稳定地跑完同时还能在需要时灵活调度。1.3 突发性和不可预测性把资源规划打回原形Web 服务的流量特征虽然也有高峰低谷但整体是可以通过压测和容量规划预估的。Agent 的负载特征却没有这么温顺——同一个入口进来的请求有的只是简单问答几十毫秒推理就结束了有的却要连环调用十几个工具负载比前者高几个数量级。这种差异不是两倍三倍而是五十倍一百倍。更麻烦的是Agent 在运行过程中会动态决定调用哪些工具、执行哪些代码这意味着你在请求进来之前根本不知道它会消耗多少算力、多少 token、多少时间。传统架构里常用的资源池化、预置实例、静态配额在这种负载模型面前基本失效因为没有哪个团队能提前给“未知的未知”预留容量。这就像开饭店菜单上每道菜的下锅时间差异极大有的菜 2 分钟出锅有的菜要炖 3 小时而且顾客点什么菜是无法预测的。传统云架构是按“平均出餐时间”备料的Agent 一来后厨直接被打崩。2. 撑不住的三个根因无状态、请求-响应、粗粒度资源2.1 无状态假设水平扩展的前提失效了传统微服务之所以能轻松水平扩展核心设计原则是“无状态”——所有会话状态放到外部存储服务实例本身只承载计算。这套设计的隐含假设是状态与计算是低耦合的实例可以随时创建和销毁会话可以随时在不同实例间迁移。到了 Agent 场景这个假设发生了两个层面的松动。第一状态本身变得“厚重”了。一个跑了十几个步骤的 Agent 会话它的上下文可能包含上万 token 的对话历史、多个工具的返回结果、内部决策树的分支记录这些不再适合全部塞进 Redis 里当一个 string 字段管理状态的生命周期已经超出了简单缓存的能力范围。第二状态变更频率极高。每做一次推理、每调一次工具、每产生一个中间结论会话状态都在变化这意味着状态存储的写入吞吐会随着 Agent 的推理步数线性增长而读写一致性要求也会从“最终一致”被迫提升到“严格一致”。这时候再拿“无状态 外部缓存”这套思路去套 Agent你会发现不是不能跑而是跑得非常别扭——所有的复杂度都被压到了状态管理层而这个层原本只是设计用来存短生命周期数据的。2.2 请求-响应模型长任务在网关层就被掐死了传统 API 设计几乎都被“请求-响应”这个范式统治着。客户端发一个 HTTP 请求服务端处理完返回结果这个模型从诞生起就没考虑过“处理过程超过 30 秒”这件事。主流网关和服务框架的超时时间默认都在 30 秒到 60 秒之间而 Agent 的一次完整任务几分钟甚至几十分钟是常事。有人会问那把网关超时调到 10 分钟不就行了表面看解决了超时报错但实际埋了更大的雷长连接占用、负载均衡连接数上限、客户端等待超时、中间链路重试风暴。网关连接数不是无限制的所有请求都占着连接等 Agent 慢慢算稍微来点并发连接池直接打满后面的正常请求全部排队整条链路雪崩。所以你会发现所有成功的 Agent 生产化方案最终都要走向异步化——请求先入队立即返回一个任务 IDAgent 跑完后通过回调或者轮询把结果交给客户端。这已经是脱离传统请求-响应模型的第一步了而这一步恰恰是很多老架构里没有的基建。2.3 资源调度粒度按容器调度还是按任务调度传统云原生体系里的调度单位是“容器”Kubernetes 管的是“有多少个实例在跑、资源有没有超分、节点是否健康”它不关心这个容器里跑的是不是一个逻辑完整的长任务。Agent 规模化之后你真正需要调度的是“会话任务”——一段代码执行逻辑从开始到结束的完整生命周期。举个实际例子一个客服 Agent 集群白天有 20 个实例在跑晚上流量低了缩到 5 个。但问题在于缩容的时候那些正在执行的会话怎么办如果直接杀掉 Pod等于杀了所有挂在上面的 Agent 会话。Kubernetes 的 preStop hook 最多给你几秒钟清理时间而一个 Agent 会话可能还剩 3 分钟的任务没跑完。这就是调度粒度错配——底层基础设施只认“实例”这个维度业务侧却需要“会话”维度的感知。这个错配带来的后果是要么你牺牲可靠性缩容时强行断会话要么你牺牲弹性永远保持峰值容量。前者体验崩后者成本崩都不是好选择。3. Agent 编排到底在编排什么3.1 第一优先级的对象上下文状态说了这么多传统架构的槽点该正面回答一个问题了Agent 编排编排的到底是什么我的答案是三样东西上下文、工具、资源而其中上下文是第一位的。上下文可以拆成几层来看。第一层是会话级上下文包含用户和 Agent 的全部对话历史这是 Agent 理解当前问题的根基第二层是任务级上下文包含当前正在执行的规划步骤、已完成步骤的中间结果、待执行分支的参数第三层是环境级上下文包含用户身份、权限范围、当前业务实体的关联信息。传统架构里这些信息散落在数据库、Redis、日志和业务代码的局部变量里而在 Agent 编排体系里它们需要被统一建模、统一读取、统一定期持久化。为什么上下文要单独拎出来做成一个被编排的对象因为 Agent 的每一步推理都依赖上下文上下文一旦丢失或错乱轻则答非所问重则执行出完全错误的操作。我见过一个自动化运维 Agent 因为上下文丢了一段把“重启测试环境”执行成了“重启生产环境”还好当时有操作审批兜底不然事故就大了。所以任何想把 Agent 规模化的团队第一件该做好的事就是把上下文管起来包括它的存储、隔离、快照和恢复。3.2 第二优先级工具调用链的有序治理Agent 的能力边界由它能调用的工具集合决定而 Agent 的风险边界同样如此。没有编排层的时候Agent 的每个实例都自己直接调用工具 API权限配置、流量控制、失败重试全部堆在代码里。一旦 Agent 数量上来这种“野路子”必然出事——要么某个 Agent 的工具调用把下游系统打爆要么权限配置不统一产生越权风险。编排层在这里要做的是工具网关化。所有 Agent 对外部的调用统一经过一个网关网关负责四件事认证鉴权、配额控制、熔断降级、结果回传。比如某个数据分析工具只允许特定角色通过 Agent 访问网关可以在工具调用前统一校验某个第三方 API 每分钟只允许 100 次调用网关可以按 Agent 维度分配配额。这里我有一个比较深的体会工具网关最好设计成异步回调模式而不是同步阻塞。Agent 调一个外部工具这个工具可能要跑几十秒如果同步等待Agent 的推理循环就被卡住了。异步模式下网关收到工具调用的结果后回调 Agent 的执行引擎Agent 的“头脑”可以先处理其他可以并行的事情。这个设计对整体吞吐的提升是非常明显的。3.3 第三优先级模型算力和 Token 预算的分配第三个被编排的对象是算力和成本。很多人对 Agent 的成本没概念我算一笔账假设一个 Agent 完成一次用户请求平均需要 5 次 LLM 调用每次调用消耗 2000 token那么一次请求大约消耗 1 万 token。按主流模型价格折算一次请求的成本可能是几毛钱到几块钱而这还只是一个会话里单轮问答的成本。如果一天跑 10 万个会话成本规模一下就上来了。编排层需要对 token 消耗做两件事。一是额度控制给不同业务线、不同 Agent、甚至不同用户设置 token 预算超了自动降级比如从大模型降级到小模型、从精确检索降级到模糊检索二是成本核算把每次推理的 token 消耗、模型单价、工具调用费用全部打上标签分摊到具体业务和具体会话上。做不到这两件事Agent 规模化就是给公司开了一张没有上限的信用卡。4. Google AX 的新思路上下文优先与会话级调度4.1 AX 的思路本质把“会话”提升为一等公民聊完编排对象的拆解再回头看 Google AX 这类新方案脉络就清晰了。它的核心思路可以概括成一句话把调度粒度从“实例”切换成“会话”让基础设施直接感知对话上下文、执行状态和工具依赖关系。传统 PaaS 平台管理的是应用的部署和扩容看到的是一堆没有业务含义的容器而 AX 这类 Agent 编排平台管理的是一个个有身份的会话它知道每一个会话当前处在什么阶段、还需要调用哪些工具、已经积累了多少上下文、离模型窗口上限还有多远。有了这层感知调度器才能做真正合理的决策哪些会话可以合并共享上下文缓存哪些会话需要迁移到负载更低的节点哪些会话应该被紧急扩容出来的专用资源接管。有人可能会觉得这只是概念包装把“进程”叫成“会话”而已。但注意两者的语义完全不同进程是资源视角会话是业务视角。编排层用业务视角来管资源才能让资源的分配紧贴业务的实际需求而不是像传统架构那样盲目扩容器、再靠业务代码去猜哪个容器负载高。4.2 上下文亲和性调度让会话稳定跑在“熟悉”的地方AX 方案里一个非常关键的调度策略是上下文亲和性。简单说就是让同一个会话的执行尽量落在同一个 Agent 实例或者至少落在能够快速访问该会话上下文快照的节点上。这个设计的原因很朴素一个已经连续推理了 20 轮的 Agent 会话它的上下文如果要从外部存储加载到另一个新实例这个加载过程不仅耗时而且可能涉及到缓存重建、工具连接重拨等一系列额外开销。频繁迁移会话就像你在写代码的时候不停换 IDE每次都要重新加载工程索引、重新打开上下文窗口效率一定大打折扣。更重要的是某些 Agent 在运行过程中可能会持有临时性、易变的状态这些状态只存在于内存中还没来得及持久化。传统调度器的无状态迁移策略在这种情况下会直接丢弃这些状态导致会话逻辑断裂。上下文亲和性调度从设计上就规避了这个问题它把“会话跟实例绑定”作为默认前提只在特殊场景下比如实例故障、资源抢占才触发迁移且迁移前会先做状态完整落盘。4.3 推理缓存复用编排层顺手解决的最大成本难题编排层还有一个很容易被忽略但收益巨大的能力推理结果缓存。Agent 会话之间往往存在大量重复的推理前缀比如同一个领域的用户问题前面几轮的理解和规划逻辑可能高度相似再比如企业内部多个 Agent 共享同一个知识库检索相似内容时生成的中间结果也常常一样。AX 这类方案通常会在编排层引入分布式推理缓存对 prompt 前缀做哈希命中缓存时直接复用推理结果省掉的是一次甚至多次完整的 LLM 调用。这个设计对成本的影响是决定性的——我见过一个实际案例引入推理缓存后某个高频问答 Agent 的 API 成本直接降了 40% 以上而延迟也肉眼可见地变低了。当然缓存不是万能的它适合那些前缀稳定、输出可复用的场景比如知识库问答、标准流程咨询不适合高度个性化、每一步都依赖实时数据的场景。但这个优化点一旦纳入编排层就不再依赖各个 Agent 自己实现缓存逻辑而是全平台统一收益这个脚手架价值非常值得重视。4.4 更细的可观测性按会话维度追踪每一笔 token 和每一次失败传统云架构的可观测性是围绕“请求”和“服务”两个维度打的请求追踪、服务指标、错误日志这些在定位 Web 服务故障时很够用。可到了 Agent 场景一个会话内部有多次模型推理、多次工具调用、多次规划决策传统的 trace 只能看到“这个请求最终成功了没有”中间那十几步谁成功了、谁失败了、哪一步消耗了最多的 token全是一片黑盒。AX 这类编排思路在可观测性上的贡献是把 trace 的粒度下沉到 Agent 运行的每一步。它会给每个会话生成一个全局唯一的 trace ID然后把模型推理、工具调用、上下文读写、状态持久化这些子操作全部挂在这个 trace 下面每一步都记录耗时、token 消耗、成功失败状态。排查问题的时候直接从会话维度切入几分钟就能定位到是哪一次工具调用超时、哪一轮推理出现了 token 溢出而不是像以前那样对着海量日志大海捞针。5. 在自己的云环境里落地迁移到 Agent 编排的实操路径5.1 第一步把会话状态从业务代码里剥离出来不管你最后选用什么编排平台迁移的第一件事永远是状态外置。先把所有 Agent 实例里散落的对话历史、执行状态、中间结果集中到一个统一的状态存储里我建议用 Redis 加数据库的双层结构——Redis 存热状态保证读写速度数据库存冷快照保证可恢复。状态存储的结构设计里有几个字段是必须的session_id 作为唯一标识context_data 存序列化后的上下文state_machine 记录当前执行到哪个阶段expire_at 控制会话有效期。这里有一个特别容易踩的坑——上下文数据不要直接存原始对话文本一定要做摘要和裁剪把过期的工具结果、已经不需要的中间推理给剔除掉否则状态存储的膨胀速度会远超你的预期。我见过一个团队因为不做裁剪会话跑了 10 轮之后上下文都快有 5 万 token 了存存储的时间和 token 费用都非常夸张。5.2 第二步给 Agent 套一个独立的运行引擎状态剥离开之后下一步是调整 Agent 的运行模式。不要继续让每个 Agent 实例自己裸跑完整循环而是引入一个独立的执行引擎由它统一负责推理调度、工具调用和状态更新。这个引擎可以是现成的框架比如 LangGraph 这类带状态图能力的框架也可以是基于事件队列自研的一套轻量调度器。运行引擎里最核心的组件是事件循环Agent 每完成一步推理就往事件队列里推一个事件事件里带上当前的会话 ID、步骤类型、关联的工具调用标识引擎消费事件后决定下一步是继续推理、调用工具、还是等待外部回调。这个模型的好处是Agent 的执行流程从“一个线程里从头跑到尾”变成了“一组可中断、可恢复的事件序列”这样任何一个步骤都可以安全地暂停和重启长任务不再依赖常驻进程故障恢复也不再依赖内存里的临时状态。如果是 Java 技术栈这里可以把 Spring AI 当作模型调用和工具抽象的底座它的 ToolCalling 机制和结构化输出接口能在不侵入业务代码的前提下帮你把模型交互统一收敛起来。5.3 第三步网关分层把“用户流量”和“Agent 对外的工具流量”分开传统网关管的是南北向流量——用户的请求怎么进入你的系统。Agent 编排还需要一层“Agent 网关”管的是东西向流量——Agent 实例怎么调用模型、怎么调用工具、怎么访问企业内部数据。这层网关要解决的问题和 API 网关很像但对象不同。首先是协议标准化所有 Agent 调外部工具都走同一个接口规范不管后端是 HTTP、gRPC、还是数据库连接其次是权限收敛每个 Agent 的身份和可见范围在网关里统一配置不允许 Agent 在执行中绕过网关直连后端系统再次是配额控制按 Agent 维度限制单位时间内的工具调用次数和 token 消耗上限。迁移的时候我建议先把工具调用收敛到网关再慢慢推广到模型路由。工具调用是风险最高的部分先管住工具风险面就砍掉了一大半。5.4 第四步容量估算从“每秒请求数”改成“并发会话数”传统容量规划看 QPS、TPSAgent 场景看这两个指标会严重失真。一个 Agent 会话可能持续几分钟期间消耗的资源远超十几个普通请求。我建议把容量模型切换成“并发会话数 × 单会话平均推理次数 × 单次推理平均 token 数”的组合。举个例子假设你的业务目标是同时支撑 200 个活跃 Agent 会话每个会话平均需要 8 次 LLM 调用每次消耗 2500 token那么全平台每秒需要处理的 token 吞吐是 200×8×2500÷平均会话时长。如果平均会话时长是 240 秒每秒就大约有 1.7 万 token 的吞吐需求按主流模型 API 的处理速度换算成推理并发大概需要 10-20 个并发推理通道。这个口径比单纯看 QPS 要准确得多也能直接对你的预算做出更精准的预判。容量估算这块没有完美公式关键是换一个正确的思考框架。你宁可高估并发会话数做冗余也不要低估——Agent 会话的突发性远超 Web 请求一旦并发上来后端的模型调用、数据库读写、工具连接是同时打进来的。5.5 迁移节奏先小范围试点再逐步放量最后强调一下迁移的节奏。不要试图一次性把所有的 Agent 应用都搬上编排平台我的建议是分三步走。第一步先选一个业务逻辑相对简单、会话特征明显的 Agent比如客服问答把它完整搬到编排引擎上跑一个月验证状态管理、工具网关、成本核算这些基础能力是否稳定。第二步在这个基础上接入两三个新的 Agent验证多 Agent 共存时的隔离性和资源竞争策略。第三步再考虑把编排层的能力开放给业务团队作为统一的 Agent 开发平台来推广。每一步都要建立明确的回滚机制。编排层本身也会出问题比如调度器异常挂了、状态存储性能衰减这些时候如果底层业务逻辑还是能独立运行的回滚就会非常从容。设计上一定要保证编排层和具体 Agent 应用的松耦合不要编排层一挂所有业务全军覆没。6. 常见问题与排查技巧实录6.1 会话上下文漂移导致“答非所问”现象Agent 在会话初期表现正常对话进行到中后期开始答非所问甚至重复调用已经执行过的工具。排查下来大部分情况是上下文在实例迁移或者状态恢复时发生了丢帧——中间某几轮的历史记录没有正确持久化导致恢复后的上下文不完整。排查手段是给每一个 Agent 会话建立“上下文审计日志”每往状态存储写入一次修改就记录一个带版本号的上下文快照摘要。出问题时对比不同版本摘要之间的差异很快就能定位是丢失了哪一段。经验做法是不要频繁全量存上下文而是增量记录每一步的变更恢复时按版本号重放这样既能控制存储成本又能保证上下文连续性。6.2 长任务老是超时客户端等不起现象Agent 执行一个稍微复杂的任务比如多步骤数据分析和报告生成运行时间往往超过 3 分钟客户端等不及直接断连或者网关层直接报超时。解决办法只有一条路全面异步化。用户请求进来后立刻返回一个任务 IDAgent 后台执行执行完成后通过 webhook 或者轮询接口把结果交付给客户端。为了用户体验你还可以做状态轮询接口查询任务进度百分比不过度设计等 Agent 真正跑完再返回完整结果。这里有一个必须注意的细节异步化之后客户端的断连不应该影响任务的继续执行。你仍然要保证即使客户端已经关掉了页面Agent 任务也能完整跑完并把结果保存下来否则用户的请求就白白消耗了算力和 token。6.3 成本突然飙升没有任何预警现象某天早上收到云账单发现模型 API 费用比前一天涨了好几倍排查后发现是某个 Agent 突然进入了死循环反复调用同一个工具每一轮都消耗完整 token。这是 Agent 规模化之后最高频的事故之一。你的防护手段有三层第一层是在编排引擎里设置单会话最大推理轮次上限比如 30 轮超过直接终止并告警第二层是给每个会话设置 token 预算消耗超过阈值自动降级到成本更低的处理路径第三层是在编排层做异常行为检测比如同一工具连续调用超过 N 次自动介入熔断。坦率地说前两层是必须的第三层能救命的还是前两层。成本失控大多数时候就是没有一个强制性的预算上限兜底不要高估 Agent 的“自我纠错”能力它就是概率模型跑偏了不能指望自己拉回来。6.4 工具调用在下游引发“重试风暴”现象Agent 调用的某个下游接口出现暂时性故障Agent 自动重试机制触发短时间内同一个下游 API 收到几十次相同请求直接把这个接口打挂了。这个问题单看 Agent 代码很难发现因为每个 Agent 的失败重试策略看起来都“合理”比如最多重试 3 次、指数退避。但当几十个 Agent 同时遇到同一个故障时重试请求会在下游形成叠加效应这就是典型的故障放大。解法是把重试策略统一收敛到工具网关做全局治理。网关对每个下游目标做熔断器一旦发现下游错误率达到阈值直接短时间内拒绝所有到该目标的调用而不是让每个 Agent 各自重试。同时网关同步返回一个“当前不可用稍后重试”的语义错误引导 Agent 切换备用工具或等待一段时间。6.5 索引和追踪混乱排查效率极低现象Agent 出现问题后你面对的是分散在多处的模型调用日志、工具日志、业务日志无法快速串联出一个完整的会话链路。那就从第一天开始就强制要求每个 Agent 会话分配一个全局唯一的 trace ID所有模型调用、工具调用、状态读写都带上这个 trace ID 写入日志。排查问题时直接靠 trace ID 把所有相关日志捞出来一条链路从头看到尾。这个做法听起来简单但在实际项目中坚持做下来的人不多往往是出了问题才开始补日志效率非常低。我的习惯是编排引擎在启动每个会话时自动注入 trace ID所有下游调用无论 HTTP 还是消息队列都强制透传。宁可前期多花点时间完善日志规范也不要等到事故复盘时靠肉眼去翻不同系统的日志推测调用顺序。写在最后我自己在实操中的体会是Agent 规模化这件事难点从来不在于单个 Agent 的推理效果而在于你愿不愿意为它专门改造一套运行时基础设施。传统云架构的积累不能浪费容器、网关、监控体系都有价值但你需要在这套体系之上补一层“懂会话、懂上下文、懂工具依赖”的编排大脑。不要一上来就追求大而全的平台先把状态外置、工具网关、异步化这三件事做扎实你会明显感受到生产环境的稳定性和成本可控性上了一个台阶。如果后面还有余力再去研究推理缓存、上下文亲和调度这些更能提升上限的能力——这个演进路径是目前我能找到最不容易走弯路的路线。 云架构撑不住AI Agent？编排需从资源调度转向上下文调度
最近大半年我陆续接触了不少跑在生产环境里的 AI Agent 项目大家遇到的情况出奇一致Demo 阶段一切正常一旦放量接入真实业务账单和延迟一起往上飙架构师开始挠头运维开始甩锅。有人把锅扣在模型 API 太贵有人怪提示词写得太啰嗦但真正的问题往往在更底层——传统云架构那套为 Web 请求设计的家底压根就不是为 Agent 这种长会话、高状态、强突发的工作负载准备的。这个现象背后有个很值得聊的方向Agent 编排方式正在被重新定义。标题里提到的 Google AX我把它理解为 Google 在 Agent 基础设施层面一系列思路的浓缩代号它想解决的核心矛盾就是把编排的重心从“资源调度”挪到“上下文调度”上。这篇文章我会从传统云架构为什么撑不住讲起拆解 Agent 场景下真正需要被治理的几个对象再把可落地的编排迁移路径和排查经验一并整理出来。适合正在做 Agent 应用、或者准备把 Agent 接入生产环境的后端、架构和平台 team 同学参考。1. 先看清问题Agent 的工作负载为什么让传统云架构难受1.1 一个 Agent 会话本质上是一条“长周期状态机”先做一个简单的对比。传统 Web 请求的生命周期通常是几百毫秒到几秒请求进来业务逻辑跑完响应返回连接关闭一切干净利落。即便遇到复杂一点的业务比如报表导出、批量任务提交也可以通过异步消息队列把任务拆开让不同 worker 各领一块各跑各的互不打扰。Agent 不一样。一次用户提问Agent 可能要经历“理解意图 → 规划步骤 → 调用工具 → 读取结果 → 修正计划 → 再调下一个工具”的循环这个循环里面每一轮都要和 LLM 做一次推理交互而每一轮推理又依赖前面所有轮次产生的中间结果。换句话说Agent 会话是一个有状态、长周期、前后强依赖的执行链路而且它的状态不是固定几个字段是一大坨不断增长的对话历史和工具调用记录。我见过最典型的案例是一个做企业知识库问答的 Agent用户问一句“帮我分析一下上季度华东区销售数据异常的原因”Agent 一口气调用了 BI 查询、数据权限核验、异常检测、报告生成四个工具整个链路跑了 6 分多钟。这期间传统网关早就把请求超时掐断了要不是他们提前改成了异步任务模式这个会话根本跑不完。这就是第一个冲突点传统架构的服务粒度是“一次请求”Agent 的服务粒度是“一段会话”。1.2 云原生的弹性是为无状态服务设计的很多团队听到 Agent 要规模化第一反应是“那就多开几个 Pod 嘛反正云原生能扩”。这个思路在普通微服务场景是对的但放到 Agent 场景就有问题了——无状态服务可以随便扩缩因为任何实例都能处理任何请求Agent 却不行同一个会话的上下文如果散落在不同实例上这个 Agent 就“失忆”了。你可能会说把上下文放到 Redis 里每个实例从 Redis 读不就一致了吗理论上没错但实际操作里你会发现两个麻烦一是每次工具调用都要把历史上下文搬进搬出几千 token 甚至上万 token 的序列化和反序列化开销在高并发下非常可观二是 Agent 内部的一些运行时状态比如当前执行到哪一个规划步骤、已经重试了几次、哪几个候选分支还挂着没跑完这些东西全部外置后协调复杂度会爆炸。说白了传统云架构的弹性假设是“实例等于无状态的执行单元”而 Agent 场景里真正的工作单元是“带有连续记忆的会话”。基础设施要支撑的不应该是单纯加实例而是如何让一段会话在整个生命周期里稳定地跑完同时还能在需要时灵活调度。1.3 突发性和不可预测性把资源规划打回原形Web 服务的流量特征虽然也有高峰低谷但整体是可以通过压测和容量规划预估的。Agent 的负载特征却没有这么温顺——同一个入口进来的请求有的只是简单问答几十毫秒推理就结束了有的却要连环调用十几个工具负载比前者高几个数量级。这种差异不是两倍三倍而是五十倍一百倍。更麻烦的是Agent 在运行过程中会动态决定调用哪些工具、执行哪些代码这意味着你在请求进来之前根本不知道它会消耗多少算力、多少 token、多少时间。传统架构里常用的资源池化、预置实例、静态配额在这种负载模型面前基本失效因为没有哪个团队能提前给“未知的未知”预留容量。这就像开饭店菜单上每道菜的下锅时间差异极大有的菜 2 分钟出锅有的菜要炖 3 小时而且顾客点什么菜是无法预测的。传统云架构是按“平均出餐时间”备料的Agent 一来后厨直接被打崩。2. 撑不住的三个根因无状态、请求-响应、粗粒度资源2.1 无状态假设水平扩展的前提失效了传统微服务之所以能轻松水平扩展核心设计原则是“无状态”——所有会话状态放到外部存储服务实例本身只承载计算。这套设计的隐含假设是状态与计算是低耦合的实例可以随时创建和销毁会话可以随时在不同实例间迁移。到了 Agent 场景这个假设发生了两个层面的松动。第一状态本身变得“厚重”了。一个跑了十几个步骤的 Agent 会话它的上下文可能包含上万 token 的对话历史、多个工具的返回结果、内部决策树的分支记录这些不再适合全部塞进 Redis 里当一个 string 字段管理状态的生命周期已经超出了简单缓存的能力范围。第二状态变更频率极高。每做一次推理、每调一次工具、每产生一个中间结论会话状态都在变化这意味着状态存储的写入吞吐会随着 Agent 的推理步数线性增长而读写一致性要求也会从“最终一致”被迫提升到“严格一致”。这时候再拿“无状态 外部缓存”这套思路去套 Agent你会发现不是不能跑而是跑得非常别扭——所有的复杂度都被压到了状态管理层而这个层原本只是设计用来存短生命周期数据的。2.2 请求-响应模型长任务在网关层就被掐死了传统 API 设计几乎都被“请求-响应”这个范式统治着。客户端发一个 HTTP 请求服务端处理完返回结果这个模型从诞生起就没考虑过“处理过程超过 30 秒”这件事。主流网关和服务框架的超时时间默认都在 30 秒到 60 秒之间而 Agent 的一次完整任务几分钟甚至几十分钟是常事。有人会问那把网关超时调到 10 分钟不就行了表面看解决了超时报错但实际埋了更大的雷长连接占用、负载均衡连接数上限、客户端等待超时、中间链路重试风暴。网关连接数不是无限制的所有请求都占着连接等 Agent 慢慢算稍微来点并发连接池直接打满后面的正常请求全部排队整条链路雪崩。所以你会发现所有成功的 Agent 生产化方案最终都要走向异步化——请求先入队立即返回一个任务 IDAgent 跑完后通过回调或者轮询把结果交给客户端。这已经是脱离传统请求-响应模型的第一步了而这一步恰恰是很多老架构里没有的基建。2.3 资源调度粒度按容器调度还是按任务调度传统云原生体系里的调度单位是“容器”Kubernetes 管的是“有多少个实例在跑、资源有没有超分、节点是否健康”它不关心这个容器里跑的是不是一个逻辑完整的长任务。Agent 规模化之后你真正需要调度的是“会话任务”——一段代码执行逻辑从开始到结束的完整生命周期。举个实际例子一个客服 Agent 集群白天有 20 个实例在跑晚上流量低了缩到 5 个。但问题在于缩容的时候那些正在执行的会话怎么办如果直接杀掉 Pod等于杀了所有挂在上面的 Agent 会话。Kubernetes 的 preStop hook 最多给你几秒钟清理时间而一个 Agent 会话可能还剩 3 分钟的任务没跑完。这就是调度粒度错配——底层基础设施只认“实例”这个维度业务侧却需要“会话”维度的感知。这个错配带来的后果是要么你牺牲可靠性缩容时强行断会话要么你牺牲弹性永远保持峰值容量。前者体验崩后者成本崩都不是好选择。3. Agent 编排到底在编排什么3.1 第一优先级的对象上下文状态说了这么多传统架构的槽点该正面回答一个问题了Agent 编排编排的到底是什么我的答案是三样东西上下文、工具、资源而其中上下文是第一位的。上下文可以拆成几层来看。第一层是会话级上下文包含用户和 Agent 的全部对话历史这是 Agent 理解当前问题的根基第二层是任务级上下文包含当前正在执行的规划步骤、已完成步骤的中间结果、待执行分支的参数第三层是环境级上下文包含用户身份、权限范围、当前业务实体的关联信息。传统架构里这些信息散落在数据库、Redis、日志和业务代码的局部变量里而在 Agent 编排体系里它们需要被统一建模、统一读取、统一定期持久化。为什么上下文要单独拎出来做成一个被编排的对象因为 Agent 的每一步推理都依赖上下文上下文一旦丢失或错乱轻则答非所问重则执行出完全错误的操作。我见过一个自动化运维 Agent 因为上下文丢了一段把“重启测试环境”执行成了“重启生产环境”还好当时有操作审批兜底不然事故就大了。所以任何想把 Agent 规模化的团队第一件该做好的事就是把上下文管起来包括它的存储、隔离、快照和恢复。3.2 第二优先级工具调用链的有序治理Agent 的能力边界由它能调用的工具集合决定而 Agent 的风险边界同样如此。没有编排层的时候Agent 的每个实例都自己直接调用工具 API权限配置、流量控制、失败重试全部堆在代码里。一旦 Agent 数量上来这种“野路子”必然出事——要么某个 Agent 的工具调用把下游系统打爆要么权限配置不统一产生越权风险。编排层在这里要做的是工具网关化。所有 Agent 对外部的调用统一经过一个网关网关负责四件事认证鉴权、配额控制、熔断降级、结果回传。比如某个数据分析工具只允许特定角色通过 Agent 访问网关可以在工具调用前统一校验某个第三方 API 每分钟只允许 100 次调用网关可以按 Agent 维度分配配额。这里我有一个比较深的体会工具网关最好设计成异步回调模式而不是同步阻塞。Agent 调一个外部工具这个工具可能要跑几十秒如果同步等待Agent 的推理循环就被卡住了。异步模式下网关收到工具调用的结果后回调 Agent 的执行引擎Agent 的“头脑”可以先处理其他可以并行的事情。这个设计对整体吞吐的提升是非常明显的。3.3 第三优先级模型算力和 Token 预算的分配第三个被编排的对象是算力和成本。很多人对 Agent 的成本没概念我算一笔账假设一个 Agent 完成一次用户请求平均需要 5 次 LLM 调用每次调用消耗 2000 token那么一次请求大约消耗 1 万 token。按主流模型价格折算一次请求的成本可能是几毛钱到几块钱而这还只是一个会话里单轮问答的成本。如果一天跑 10 万个会话成本规模一下就上来了。编排层需要对 token 消耗做两件事。一是额度控制给不同业务线、不同 Agent、甚至不同用户设置 token 预算超了自动降级比如从大模型降级到小模型、从精确检索降级到模糊检索二是成本核算把每次推理的 token 消耗、模型单价、工具调用费用全部打上标签分摊到具体业务和具体会话上。做不到这两件事Agent 规模化就是给公司开了一张没有上限的信用卡。4. Google AX 的新思路上下文优先与会话级调度4.1 AX 的思路本质把“会话”提升为一等公民聊完编排对象的拆解再回头看 Google AX 这类新方案脉络就清晰了。它的核心思路可以概括成一句话把调度粒度从“实例”切换成“会话”让基础设施直接感知对话上下文、执行状态和工具依赖关系。传统 PaaS 平台管理的是应用的部署和扩容看到的是一堆没有业务含义的容器而 AX 这类 Agent 编排平台管理的是一个个有身份的会话它知道每一个会话当前处在什么阶段、还需要调用哪些工具、已经积累了多少上下文、离模型窗口上限还有多远。有了这层感知调度器才能做真正合理的决策哪些会话可以合并共享上下文缓存哪些会话需要迁移到负载更低的节点哪些会话应该被紧急扩容出来的专用资源接管。有人可能会觉得这只是概念包装把“进程”叫成“会话”而已。但注意两者的语义完全不同进程是资源视角会话是业务视角。编排层用业务视角来管资源才能让资源的分配紧贴业务的实际需求而不是像传统架构那样盲目扩容器、再靠业务代码去猜哪个容器负载高。4.2 上下文亲和性调度让会话稳定跑在“熟悉”的地方AX 方案里一个非常关键的调度策略是上下文亲和性。简单说就是让同一个会话的执行尽量落在同一个 Agent 实例或者至少落在能够快速访问该会话上下文快照的节点上。这个设计的原因很朴素一个已经连续推理了 20 轮的 Agent 会话它的上下文如果要从外部存储加载到另一个新实例这个加载过程不仅耗时而且可能涉及到缓存重建、工具连接重拨等一系列额外开销。频繁迁移会话就像你在写代码的时候不停换 IDE每次都要重新加载工程索引、重新打开上下文窗口效率一定大打折扣。更重要的是某些 Agent 在运行过程中可能会持有临时性、易变的状态这些状态只存在于内存中还没来得及持久化。传统调度器的无状态迁移策略在这种情况下会直接丢弃这些状态导致会话逻辑断裂。上下文亲和性调度从设计上就规避了这个问题它把“会话跟实例绑定”作为默认前提只在特殊场景下比如实例故障、资源抢占才触发迁移且迁移前会先做状态完整落盘。4.3 推理缓存复用编排层顺手解决的最大成本难题编排层还有一个很容易被忽略但收益巨大的能力推理结果缓存。Agent 会话之间往往存在大量重复的推理前缀比如同一个领域的用户问题前面几轮的理解和规划逻辑可能高度相似再比如企业内部多个 Agent 共享同一个知识库检索相似内容时生成的中间结果也常常一样。AX 这类方案通常会在编排层引入分布式推理缓存对 prompt 前缀做哈希命中缓存时直接复用推理结果省掉的是一次甚至多次完整的 LLM 调用。这个设计对成本的影响是决定性的——我见过一个实际案例引入推理缓存后某个高频问答 Agent 的 API 成本直接降了 40% 以上而延迟也肉眼可见地变低了。当然缓存不是万能的它适合那些前缀稳定、输出可复用的场景比如知识库问答、标准流程咨询不适合高度个性化、每一步都依赖实时数据的场景。但这个优化点一旦纳入编排层就不再依赖各个 Agent 自己实现缓存逻辑而是全平台统一收益这个脚手架价值非常值得重视。4.4 更细的可观测性按会话维度追踪每一笔 token 和每一次失败传统云架构的可观测性是围绕“请求”和“服务”两个维度打的请求追踪、服务指标、错误日志这些在定位 Web 服务故障时很够用。可到了 Agent 场景一个会话内部有多次模型推理、多次工具调用、多次规划决策传统的 trace 只能看到“这个请求最终成功了没有”中间那十几步谁成功了、谁失败了、哪一步消耗了最多的 token全是一片黑盒。AX 这类编排思路在可观测性上的贡献是把 trace 的粒度下沉到 Agent 运行的每一步。它会给每个会话生成一个全局唯一的 trace ID然后把模型推理、工具调用、上下文读写、状态持久化这些子操作全部挂在这个 trace 下面每一步都记录耗时、token 消耗、成功失败状态。排查问题的时候直接从会话维度切入几分钟就能定位到是哪一次工具调用超时、哪一轮推理出现了 token 溢出而不是像以前那样对着海量日志大海捞针。5. 在自己的云环境里落地迁移到 Agent 编排的实操路径5.1 第一步把会话状态从业务代码里剥离出来不管你最后选用什么编排平台迁移的第一件事永远是状态外置。先把所有 Agent 实例里散落的对话历史、执行状态、中间结果集中到一个统一的状态存储里我建议用 Redis 加数据库的双层结构——Redis 存热状态保证读写速度数据库存冷快照保证可恢复。状态存储的结构设计里有几个字段是必须的session_id 作为唯一标识context_data 存序列化后的上下文state_machine 记录当前执行到哪个阶段expire_at 控制会话有效期。这里有一个特别容易踩的坑——上下文数据不要直接存原始对话文本一定要做摘要和裁剪把过期的工具结果、已经不需要的中间推理给剔除掉否则状态存储的膨胀速度会远超你的预期。我见过一个团队因为不做裁剪会话跑了 10 轮之后上下文都快有 5 万 token 了存存储的时间和 token 费用都非常夸张。5.2 第二步给 Agent 套一个独立的运行引擎状态剥离开之后下一步是调整 Agent 的运行模式。不要继续让每个 Agent 实例自己裸跑完整循环而是引入一个独立的执行引擎由它统一负责推理调度、工具调用和状态更新。这个引擎可以是现成的框架比如 LangGraph 这类带状态图能力的框架也可以是基于事件队列自研的一套轻量调度器。运行引擎里最核心的组件是事件循环Agent 每完成一步推理就往事件队列里推一个事件事件里带上当前的会话 ID、步骤类型、关联的工具调用标识引擎消费事件后决定下一步是继续推理、调用工具、还是等待外部回调。这个模型的好处是Agent 的执行流程从“一个线程里从头跑到尾”变成了“一组可中断、可恢复的事件序列”这样任何一个步骤都可以安全地暂停和重启长任务不再依赖常驻进程故障恢复也不再依赖内存里的临时状态。如果是 Java 技术栈这里可以把 Spring AI 当作模型调用和工具抽象的底座它的 ToolCalling 机制和结构化输出接口能在不侵入业务代码的前提下帮你把模型交互统一收敛起来。5.3 第三步网关分层把“用户流量”和“Agent 对外的工具流量”分开传统网关管的是南北向流量——用户的请求怎么进入你的系统。Agent 编排还需要一层“Agent 网关”管的是东西向流量——Agent 实例怎么调用模型、怎么调用工具、怎么访问企业内部数据。这层网关要解决的问题和 API 网关很像但对象不同。首先是协议标准化所有 Agent 调外部工具都走同一个接口规范不管后端是 HTTP、gRPC、还是数据库连接其次是权限收敛每个 Agent 的身份和可见范围在网关里统一配置不允许 Agent 在执行中绕过网关直连后端系统再次是配额控制按 Agent 维度限制单位时间内的工具调用次数和 token 消耗上限。迁移的时候我建议先把工具调用收敛到网关再慢慢推广到模型路由。工具调用是风险最高的部分先管住工具风险面就砍掉了一大半。5.4 第四步容量估算从“每秒请求数”改成“并发会话数”传统容量规划看 QPS、TPSAgent 场景看这两个指标会严重失真。一个 Agent 会话可能持续几分钟期间消耗的资源远超十几个普通请求。我建议把容量模型切换成“并发会话数 × 单会话平均推理次数 × 单次推理平均 token 数”的组合。举个例子假设你的业务目标是同时支撑 200 个活跃 Agent 会话每个会话平均需要 8 次 LLM 调用每次消耗 2500 token那么全平台每秒需要处理的 token 吞吐是 200×8×2500÷平均会话时长。如果平均会话时长是 240 秒每秒就大约有 1.7 万 token 的吞吐需求按主流模型 API 的处理速度换算成推理并发大概需要 10-20 个并发推理通道。这个口径比单纯看 QPS 要准确得多也能直接对你的预算做出更精准的预判。容量估算这块没有完美公式关键是换一个正确的思考框架。你宁可高估并发会话数做冗余也不要低估——Agent 会话的突发性远超 Web 请求一旦并发上来后端的模型调用、数据库读写、工具连接是同时打进来的。5.5 迁移节奏先小范围试点再逐步放量最后强调一下迁移的节奏。不要试图一次性把所有的 Agent 应用都搬上编排平台我的建议是分三步走。第一步先选一个业务逻辑相对简单、会话特征明显的 Agent比如客服问答把它完整搬到编排引擎上跑一个月验证状态管理、工具网关、成本核算这些基础能力是否稳定。第二步在这个基础上接入两三个新的 Agent验证多 Agent 共存时的隔离性和资源竞争策略。第三步再考虑把编排层的能力开放给业务团队作为统一的 Agent 开发平台来推广。每一步都要建立明确的回滚机制。编排层本身也会出问题比如调度器异常挂了、状态存储性能衰减这些时候如果底层业务逻辑还是能独立运行的回滚就会非常从容。设计上一定要保证编排层和具体 Agent 应用的松耦合不要编排层一挂所有业务全军覆没。6. 常见问题与排查技巧实录6.1 会话上下文漂移导致“答非所问”现象Agent 在会话初期表现正常对话进行到中后期开始答非所问甚至重复调用已经执行过的工具。排查下来大部分情况是上下文在实例迁移或者状态恢复时发生了丢帧——中间某几轮的历史记录没有正确持久化导致恢复后的上下文不完整。排查手段是给每一个 Agent 会话建立“上下文审计日志”每往状态存储写入一次修改就记录一个带版本号的上下文快照摘要。出问题时对比不同版本摘要之间的差异很快就能定位是丢失了哪一段。经验做法是不要频繁全量存上下文而是增量记录每一步的变更恢复时按版本号重放这样既能控制存储成本又能保证上下文连续性。6.2 长任务老是超时客户端等不起现象Agent 执行一个稍微复杂的任务比如多步骤数据分析和报告生成运行时间往往超过 3 分钟客户端等不及直接断连或者网关层直接报超时。解决办法只有一条路全面异步化。用户请求进来后立刻返回一个任务 IDAgent 后台执行执行完成后通过 webhook 或者轮询接口把结果交付给客户端。为了用户体验你还可以做状态轮询接口查询任务进度百分比不过度设计等 Agent 真正跑完再返回完整结果。这里有一个必须注意的细节异步化之后客户端的断连不应该影响任务的继续执行。你仍然要保证即使客户端已经关掉了页面Agent 任务也能完整跑完并把结果保存下来否则用户的请求就白白消耗了算力和 token。6.3 成本突然飙升没有任何预警现象某天早上收到云账单发现模型 API 费用比前一天涨了好几倍排查后发现是某个 Agent 突然进入了死循环反复调用同一个工具每一轮都消耗完整 token。这是 Agent 规模化之后最高频的事故之一。你的防护手段有三层第一层是在编排引擎里设置单会话最大推理轮次上限比如 30 轮超过直接终止并告警第二层是给每个会话设置 token 预算消耗超过阈值自动降级到成本更低的处理路径第三层是在编排层做异常行为检测比如同一工具连续调用超过 N 次自动介入熔断。坦率地说前两层是必须的第三层能救命的还是前两层。成本失控大多数时候就是没有一个强制性的预算上限兜底不要高估 Agent 的“自我纠错”能力它就是概率模型跑偏了不能指望自己拉回来。6.4 工具调用在下游引发“重试风暴”现象Agent 调用的某个下游接口出现暂时性故障Agent 自动重试机制触发短时间内同一个下游 API 收到几十次相同请求直接把这个接口打挂了。这个问题单看 Agent 代码很难发现因为每个 Agent 的失败重试策略看起来都“合理”比如最多重试 3 次、指数退避。但当几十个 Agent 同时遇到同一个故障时重试请求会在下游形成叠加效应这就是典型的故障放大。解法是把重试策略统一收敛到工具网关做全局治理。网关对每个下游目标做熔断器一旦发现下游错误率达到阈值直接短时间内拒绝所有到该目标的调用而不是让每个 Agent 各自重试。同时网关同步返回一个“当前不可用稍后重试”的语义错误引导 Agent 切换备用工具或等待一段时间。6.5 索引和追踪混乱排查效率极低现象Agent 出现问题后你面对的是分散在多处的模型调用日志、工具日志、业务日志无法快速串联出一个完整的会话链路。那就从第一天开始就强制要求每个 Agent 会话分配一个全局唯一的 trace ID所有模型调用、工具调用、状态读写都带上这个 trace ID 写入日志。排查问题时直接靠 trace ID 把所有相关日志捞出来一条链路从头看到尾。这个做法听起来简单但在实际项目中坚持做下来的人不多往往是出了问题才开始补日志效率非常低。我的习惯是编排引擎在启动每个会话时自动注入 trace ID所有下游调用无论 HTTP 还是消息队列都强制透传。宁可前期多花点时间完善日志规范也不要等到事故复盘时靠肉眼去翻不同系统的日志推测调用顺序。写在最后我自己在实操中的体会是Agent 规模化这件事难点从来不在于单个 Agent 的推理效果而在于你愿不愿意为它专门改造一套运行时基础设施。传统云架构的积累不能浪费容器、网关、监控体系都有价值但你需要在这套体系之上补一层“懂会话、懂上下文、懂工具依赖”的编排大脑。不要一上来就追求大而全的平台先把状态外置、工具网关、异步化这三件事做扎实你会明显感受到生产环境的稳定性和成本可控性上了一个台阶。如果后面还有余力再去研究推理缓存、上下文亲和调度这些更能提升上限的能力——这个演进路径是目前我能找到最不容易走弯路的路线。