1. 先把问题拆开云端智能体基础设施到底在跑什么“云端智能体”这个词过去一年我至少听了一百遍。模型能力一上来各家都开始写Agent代码生成、客服、数据分析、流程自动化Demo跑得飞起。可真正把它放到云端当在线服务来用完全是另一回事。我最近半年主要做智能体平台的基础设施建设最大的感受是当前阶段真正卡住扩展的不是模型本身而是基础设施层。这个问题具体暴露在几个地方会话变长后内存和上下文撑不住工具链条一复杂就超时丢步并发一高模型网关和任务队列先垮出了问题还没法快速回放。这篇文章想跟你聊的就是我眼里“云端智能体需要怎样的基础设施”以及我们踩过的坑、沉淀下来的方案。适合正在做Agent平台、或者打算把智能体接入生产环境的后端和基础设施工程师参考也能帮你更准确地预判下一个扩展瓶颈到底长什么样。1.1 传统后端思维为什么在这里失效做惯了传统后端的人第一次接触云端智能体会下意识沿用老办法无状态服务、水平扩Pod、QPS监控、基于CPU和内存做弹性伸缩。这套体系在普通Web服务里没什么问题但放到Agent场景里很多假设都不成立了。传统请求是“输入-处理-响应”的同步模型服务端不关心上一个请求发生了什么。智能体则完全不同用户发一句话进来它可能要经历“理解意图—规划步骤—调用工具—观察结果—再推理—再调用工具”的多轮循环整个流程可能持续几十秒甚至几分钟。这个循环里每一轮推理都要依赖之前所有轮次的状态系统一旦把状态丢掉整个任务就断在半路。我见过很多团队犯同一个错误用普通API网关的思想去托管AgentAgent跑在无状态容器里会话上下文存在Redis里看起来没问题。但一旦Agent在某个工具调用上卡住或者worker被重新调度上下文就找不到了。用户收到的是“抱歉我刚才说到哪了”这在C端产品里基本等于事故。所以做智能体基础设施首先得接受一个转变你维护的是一批有状态的长事务而不是一串短小的请求。扩展和容灾都要围绕“状态不丢、流程可恢复”来设计而不是简单地加机器。1.2 一次真实Agent调用的生命周期我在监控里统计过一批线上Agent运行轨迹发现它的访问模式跟普通API服务差异非常大。一个典型的云端智能体任务平均会触发8到15次大模型调用多的能到三十多次。这些调用不是均匀分布的而是会基于工具返回结果不断分叉有时一个步骤里要并发调多个工具有时一条链路失败后还会重试。我把一次调用拆开看用户消息进来后Agent会先做意图识别然后根据任务复杂程度决定直接回答还是调用工具。一旦需要调用工具就会进入“推理-执行-观察”的循环。每个循环都会把本轮结果追加进上下文也就是说下一次调用携带的历史会越来越长。工具执行本身还会涉及外部API、数据库、内部服务这些外部依赖一旦变慢或者报错Agent不会自动知道应该放弃反而可能重新规划、换个工具再试一次。这种模式带来的直接后果是单次用户请求的峰值延迟不是几百毫秒而是分钟级系统负载尖刺不是由QPS决定而是由LLM调用频率和工具执行时长共同决定。你用“每秒请求数”去预估容量几乎一定会算错。我习惯用一个对比表格来说明这个差异维度传统后端服务云端智能体基础设施请求模型同步请求-响应多轮、异步、长事务状态要求无状态随便扩缩容必须保存会话上下文和执行轨迹容量估算按QPS即可按LLM调用次数、工具耗时、Token量估算失败处理重试请求即可需要状态回放、断点续跑监控对象延迟、错误率、吞吐轨迹、Token消耗、成本、决策质量这个表是我做架构评审时最常用的开场。很多同事一开始看不懂等线上出了几次问题再回头看这张表基本都能理解。1.3 设计智能体基础设施的底层假设我总结下来做这块基础设施时必须默认三件事都是不可靠的大模型推理会出错工具调用会超时网络会抖动。所有设计都得围绕“快速失败、可恢复、可重放”来展开。大模型不可靠意味着同一个请求可能返回不同答案所以需要评估和校验。工具不可靠意味着调用链路上必须有超时、重试和幂等机制不能因为一次工具返回慢就把整个Agent实例拖死。网络不可靠意味着你依赖的模型供应商、MCP服务器、内部服务随时可能抖动基础设施要能自动切换或降级。想清楚这三点再看“云端智能体需要怎样的基础设施”这个问题思路就清晰了。它需要的不只是GPU或大模型API而是一套能管理状态、调度执行、隔离故障、观测行为、控制成本的基础设施。接下来我一个个展开。2. 基础设施层四大扩展瓶颈拆解在真正动手搭建之前我建议你先对照下面这四类问题自查因为它们的表现差异很大但根因往往交织在一起。我也按照实际踩坑的深度把它们列出来。2.1 Token膨胀与上下文状态管理第一个瓶颈是Token而且是最容易被低估的一个。很多人觉得Token成本是模型提供商的事基础设施不用管。等你把Agent放到线上就发现Token消耗会以远超预期的速度膨胀。原因很简单Agent每执行一次工具调用就会把当前结果追加到上下文里。十轮工具调用之后系统提示词、工具定义、历史对话、中间观察结果全部堆在一起单轮推理的输入可能超过两万Token。如果一次任务要触发十五次模型调用基本Token就是十五倍地在叠加这还没算输出Token。我画过一个粗略的估算假设系统提示词和工具定义固定占用4000 Token每轮对话新增历史1000 Token平均每轮输出800 Token。一个十五步的Agent任务总消耗大约是十五乘以“4000加上递增的历史”算下来差不多十几万Token。这个量级放到每天几千个任务里成本非常惊人。基础设施层面能做的第一件事是别把历史记录一股脑全塞给模型。要对上下文做分层管理短期记忆保留原始对话中期记忆做关键信息抽取长期记忆落到向量库或结构化存储。每次送入模型的内容只组装当前这步真正需要的信息而不是无脑拼整个history数组。第二件事是充分利用模型提供商的Prompt Caching。把系统提示词、工具定义这些相对固定的内容放在前缀位置让缓存命中率提高。我实测下来稳定的前缀配合缓存能力能省掉相当比例的输入Token成本而且还能降低首字延迟。如果你们的模型网关不支持前缀缓存策略建议尽早规划这属于投入少见效快的基础设施优化。2.2 模型网关调度、限流与重试第二个瓶颈在模型网关。Agent平台所有流量都要经过模型网关它一旦成为瓶颈所有租户一起遭殃。模型网关的职责不是简单地转发请求至少要包含四件事统一的限流配额、模型路由、失败重试、成本计量。很多团队一开始图省事直接让每个Agent服务自己去调模型API结果某个租户的并发一上来很快把模型供应商的配额打满其他租户的请求全部失败。这类故障特别难排查因为业务日志里看到的全是模型限流错误但真实根因是多个Agent共享同一个配额池谁也没做全局管控。我建议网关至少做到租户级限流和模型级限流两级。租户级限流保证单个用户或单个业务方无法挤占公共资源模型级限流保证某一型号的模型配额不会被某个高峰期任务耗尽。路由规则上最好能根据任务类型分配不同模型比如简单意图识别用轻量模型复杂推理用强模型这既是成本策略也是容量策略。重试策略也要专门设计。Agent场景下的模型调用往往是链式调用一步失败就可能触发整条链路重放。如果网关在模型供应商返回超时后立刻重试并且重试三次实际上是把外部故障放大了三倍。更稳妥的做法是区分“可重试错误”和“不可重试错误”对超时类错误采用指数退避加抖动对上下文过长、内容审核等错误直接返回不重试。2.3 工具调用链与外部依赖的不可控性第三个瓶颈是工具调用链。云端智能体之所以叫智能体就是因为它能操作外部系统查数据库、发邮件、调订单接口、操作浏览器。这些工具调用一旦引入基础设施的故障域就被拉大了几十倍。我在线上见过最典型的问题Agent需要调用一个外部API这个API的P99延迟是8秒但我们给工具调用设置的超时只有2秒。结果Agent每次走到这一步都会超时然后它不会放弃而是重新规划尝试换一个工具再执行最后还是回到同一个接口。最终用户看到的是一个任务反复“重试-失败-重试”底层的外部系统被打进雪崩。处理这类问题基础设施就必须为工具链加几道保险。第一任何工具调用都要有独立的超时控制和熔断机制不能因为单个工具拖慢整个Agent实例。第二长耗时工具要支持异步化先返回“任务已受理”后台任务完成后再通过事件回调或轮询推进Agent状态。第三所有工具调用必须带上幂等键尤其是邮件、支付、下单这类不允许重复执行的工具。没有幂等键一次客户端重试就可能造成重复扣款这已经不是技术事故而是资损事故了。现在不少团队开始引入MCP标准来统一工具接入思路是对的。但MCP服务器本身也是服务也需要连接池、健康检查、超时控制。把MCP当成普通HTTP服务来治理比当成“Agent专用魔法接口”要可靠得多。2.4 可观测性与成本控制缺口第四个瓶颈是可观测性它最容易被拖到最后才做但它恰恰是判断扩展问题最关键的依据。没有可观测性你连“瓶颈在哪”都不知道后面的排查只能是盲猜。传统监控看CPU、内存、QPS、P95延迟这些指标对Agent场景远远不够。Agent平台需要的是“轨迹级可观测”每一次任务从开始到结束的完整步骤每一步的输入输出、模型调用、工具调用、Token消耗、成本都要能回溯。你可以把它理解成给每个Agent任务装了黑匣子飞行记录仪。成本控制也一样要放进基础设施。Agent的运营成本主要由Token成本、工具执行成本、重试放大成本构成。每个Agent任务最好都有成本上限超过预算就主动终止或降级。租户之间要做成本配额隔离否则某个业务方的异常任务会让全平台的成本报表失控。我们后来建了一套“单任务成本预算租户月配额实时账单事件”的机制才把成本问题从“事后惊吓”变成“事前卡控”。3. 实操落地一套最小可用的智能体基础设施说完了瓶颈接下来聊我们实际搭建的方案。它不是最复杂的架构但每一条都是线上事故换来的参考价值比较高。3.1 核心模块与选型思路我倾向把云端智能体基础设施分成五个核心模块模型网关、状态存储、任务队列、可观测链路、预算控制。选择时不要迷信高大全先满足“能跑、能扛、能查、能断”这四个要求。模块我的选型为什么这么选模型网关自建轻量网关底座用Nginx Redis 自制转发层需要精细控制限流、路由、重试语义闭源网关很难改状态存储PostgreSQL RedisPG存会话和事件主数据Redis做短生命周期锁和热数据缓存任务队列Redis Streams 或云厂商队列长任务异步化支持消息重放和延迟消息可观测链路OpenTelemetry 自建事件表Agent特有属性需要自定义span attribute通用平台扩展起来麻烦预算控制Redis计数器 定时落表实时扣减成本配额最终账单由离线任务对账这套组合的好处是组件少、运维简单把复杂度集中在模型网关和状态存储这两块。如果一上来就上K8s、服务网格、专用Agent编排引擎光排查问题就够你忙几个月的。3.2 状态与事件表设计状态存储是整个Agent基础设施的“底盘”。我推荐采用事件溯源思路而不是改一条运行记录字段。简单来说Agent的每一步都会产生不可变事件包括模型推理完成事件、工具调用开始事件、工具调用结束事件、错误事件、最终答案事件。所有事件追加写入数据库当前状态则通过读取这些事件流来重建。我用的表结构大概是这样CREATE TABLE agent_events ( run_id TEXT NOT NULL, session_id TEXT NOT NULL, step_id TEXT NOT NULL, parent_step_id TEXT, event_type TEXT NOT NULL, -- model_call_started/tool_call_started/error payload JSONB NOT NULL, -- 请求参数、响应摘要、Token、成本 created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_agent_events_run_id ON agent_events(run_id);每条事件都带run_id和step_id这样既能按任务维度完整回放也能按步骤维度单独定位。payload里我习惯存“摘要”不存全量大模型输出避免单行数据过大。全量输出可以放到对象存储里事件表只保留引用和关键字段否则PG很快会被撑爆。这里有个很关键的设计不要把Agent的当前状态只存在某个worker的内存里。状态要能从事件表恢复这样任何一个worker都可以接着跑同一个任务。每次调度时worker从队列中取出待处理的事件ID去状态存储里重建上下文然后继续执行。这一步做对了Agent实例的伸缩才能真正无状态化。3.3 核心调度流程我们现在的流程可以概括为接入即入队、每步留痕、失败可重放。用户请求到达网关后网关先创建run_id和session_id然后把首条消息写入事件表最后把任务放入队列。Worker从队列中取出任务根据run_id加载事件流恢复出当前上下文调用模型网关做推理。推理结果如果是工具调用worker执行工具记录工具事件然后继续新的推理循环如果结果是最终答案worker把答案写入结果表并清理临时锁。每个关键节点都要带上锁防止同一个run_id被两个worker同时处理。我习惯用Redis做分布式锁锁的key是run_id过期时间根据任务复杂度设置。如果worker在处理过程中宕机Redis锁过期后另一个worker可以从最后一条事件继续执行。因为有事件溯源它不需要知道之前的worker到底跑到了哪一步只要重新读事件流就能定位。这套流程看起来简单但它解决了一个核心扩展问题Agent任务不再绑死在某个进程上。你想水平扩展worker只要队列支持并发消费就行你想做灰度发布只要让新版本worker只消费新run_id就行。所有运维操作都变得可控。3.4 伸缩与多租户隔离机器层面的伸缩要围绕队列长度来做而不是围绕CPU和内存。Agent worker的CPU和内存使用率通常很低因为大头都在等待模型响应和外部工具调用。真正需要扩容的信号是队列积压量、模型网关的排队时延、工具调用的等待时长。我们后来把队列积压深度作为HPA的自定义指标效果比CPU指标灵敏很多。多租户隔离在Agent场景下比传统服务更复杂。因为一个租户的任务可能产生大量模型调用如果不做隔离一个租户跑数据清洗任务能把整个平台的模型费用全部烧完。我建议至少做三件事租户维度的事件表分区、租户维度的网关限流、租户维度的成本配额。隔离不等于物理隔离逻辑隔离配合严格配额在起步阶段性价比最高。4. 常见问题与排查技巧实录这一节是实打实的排障记录。如果你正在做Agent基础设施下面这些问题大概率会遇到建议先收藏一下。4.1 Agent层常见故障速查表现象可能原因排查方向解决方案Agent在工具调用后卡住工具超时设置过短Agent不断重试查事件表里工具事件是否长期处于进行中工具超时分层设置长任务改异步并发上升后错误率激增模型网关配额被某个租户打满查网关限流日志和租户配额用量增加租户级限流设置模型级配额响应很慢但服务器资源很低等待模型API或外部工具CPU没有占用用Trace看时间消耗在哪个Span优化Prompt缓存缩短工具等待成本监控异常飙升重试放大、历史无限增长、任务失控循环查单任务Token消耗和重试计数加任务级成本上限和最大步骤数状态丢失或重复执行锁失效、worker被重复调度查Redis锁和worker消费逻辑使用幂等键和分布式锁锁过期时间合理同一工具被重复调用客户端重试未带幂等键查工具请求Id和响应码所有工具调用强制带幂等键这张表是我在实际工作中迭代出来的。每次线上出问题我都会把现象、根因、解法更新进去慢慢它就成了团队排查Agent问题的第一入口。4.2 三个真实翻车案例第一个案例是重试放大。我们接了一个外部的汇率接口平均响应500毫秒但偶尔会到5秒。我们最初给工具设置的超时是3秒失败重试3次。结果某个下午汇率数据源抖动Agent每走到这个工具就三次超时然后重新规划过一会儿又回来再调三次。最终外部接口被我们自己的流量打得完全不可用。后来我们把工具超时调到8秒重试策略改成指数退避加随机抖动并且限制单个Agent任务对同一工具最多调用两次问题才算压住。第二个案例是Agent死循环。某次我们测试一个“自动整理CRM数据并发送报表”的任务Agent在发现数据格式不匹配后不断尝试生成新的查询条件一轮接一轮地调模型。因为没有设置最大步骤数这个单任务跑了两个多小时产生了大量Token消耗。后来我们在基础设施层加了三道保险单任务最大步数默认50步、单任务成本上限默认10美元、连续N步无有效进展自动熔断。这三道保险上线后再也没有出现过“僵尸Agent”烧钱的情况。第三个案例是重复执行。我们接了一个内部工单系统Agent通过API创建工单时不带幂等键。某次消息队列重试导致同一个指令被消费了两次结果一个工单被创建了两遍。这在工单场景还好如果是支付、审批、消息通知类工具性质就严重了。我后来把幂等键规范写进了工具接入协议任何有副作用的外部操作都必须从run_id和step_id派生出幂等键。这条规则任何Agent都不能绕过。4.3 排查Agent问题的基础设施搭建排查Agent问题建议至少把三样东西做扎实全链路Trace、事件回放、自动化评估。全链路Trace用OpenTelemetry就能搭但要注意给Span加Agent语义字段。每个模型调用Span都带上session_id、step_id、模型名、输入Token数、输出Token数、成本估算每个工具调用Span都带上工具名、目标服务、超时配置、重试次数。没有这些自定义属性Trace只能告诉你“慢了”不能告诉你“是Agent哪一步决策慢了”。事件回放依赖前面说的事件表。线上出现一个坏Case我会先把run_id找出来按时间顺序把agent_events拉出来重放这个Agent当时的推理、工具调用、模型输出一步不落地看。很多问题只看日志是看不出来的但回放能看到Agent在某一步做出了错误决策能看到工具返回了异常数据能看到哪一步开始上下文开始失控。自动化评估则是把线上行为沉淀下来。每次修完一个Bug我都建议把对应的坏Case加进评估集以后每次基础设施变更都跑一遍回归。Agent基础设施的变更影响面比普通服务大一个网关策略调整就可能改变几百个任务的行为。没有自动评估你根本不敢动线上网关。5. 我个人沉淀的几条体会踩过这么多坑之后我最大的体会是云端智能体基础设施的扩展瓶颈永远不会只是“机器不够”这么单纯。当你加机器也解决不了问题的时候就要往状态管理、工具链稳定性、可观测性和成本控制这几个方向去查大概率能挖到真问题。如果让我给一个“从零搭建”的优先级排序我会建议这么来先做状态存储和事件表再做模型网关然后接任务队列接着补齐可观测性最后落地成本和配额控制。状态存储决定你能不能恢复模型网关决定你能不能并发任务队列决定你能不能异步化可观测性决定你能不能迭代成本控制决定你能不能长期跑。这个顺序基本上是按故障严重程度排的每完成一步系统的健壮性都会上一个台阶。还有一点经验是别一上来就搞重框架。现在Agent编排框架、工作流引擎、智能体平台特别多都很诱人。但如果你还在探索阶段业务逻辑和基础设施需求都没定型重框架会把所有问题都包在里面出问题后反而更难排查。先用手动事件表加轻量网关跑起来等业务形态稳定了再抽象成平台能力。这个“先摩擦后抽象”的思路帮我避过了很多无意义的返工。最后再分享一个小技巧给线上Agent任务加一个“最大允许时间”会非常有用。因为Agent任务的延迟天然是分钟级很多用户会中途离开长时间运行的任务容易变成僵尸任务。我们后来在基础设施层给每个任务设了最长存续时间超时自动归档并通知用户。这个机制上线后僵尸任务大幅减少基础设施的资源利用率也明显提升。云端智能体的下一步扩展拼的不会是模型得分而是谁能把状态、调度、工具、观测、成本这几件事做得更稳。基础设施虽然不直接出现在用户对话里但它决定了智能体能不能从“能跑Demo”走到“能可靠上线”。希望这篇分享能帮你在做架构决策的时候少走几步弯路。