直接说结论今天大部分团队做云端智能体卡住的已经不是模型能力而是基础设施的承载力。我自己带团队做Agent类产品这两年最深的体感是——Demo和生产的差距几乎全在基础设施。你可以在两天内用任意框架搭出一个惊艳的Demo但当你想把它推向几百上千的并发用户、接入几十个外部工具、让它在生产环境稳定跑上几个月时之前被忽略的那些问题会一个接一个地跳出来而且每一个都能让你的服务在凌晨三点挂掉。这个标题我琢磨了很久。“下一个扩展瓶颈”这个词很有意思——第一波瓶颈是模型本身的能力第二波是推理成本和延迟现在轮到基础设施了。这篇文章我会结合自己踩过的坑和拆过的架构聊聊云端智能体规模化扩展时真正会遇到什么瓶颈以及基础设施应该从哪些维度去构建。1. 智能体规模化的第一道坎不是算力不够是会话状态失控1.1 你以为是并发问题其实是状态问题先说我见过最多的一个场景。团队做了一个智能体服务单用户测得好好的一上线就崩。排查下来十万个请求里九成不是模型调用失败而是状态错乱——用户上下文串了、工具调用轮次对不上、对话历史丢了一半、恢复会话时直接死循环。这背后的本质是什么传统后端服务追求无状态你随时可以把请求切到任何一台机器上因为状态都在数据库和缓存里服务节点本身不记忆任何东西。但智能体的运行逻辑完全不是这样——你拿起手机问一句“刚才那个表格帮我调整一下”哪怕这句话本身语义不完整模型也能根据会话上下文推断出“刚才那个表格”是什么。这套“不把话说全”的协作方式靠的是一长段对话历史、工具调用记录、临时变量和中间计算结果共同构成的会话状态。这就带来一个根本性的矛盾如果这颗状态只存在于某一台机器的内存里那这台机器挂了会话就断了如果你想把它复制到别的机器上继续跑又得考虑一致性和实时同步。我在生产环境里见过最尴尬的案例用户的会话在两个节点之间来回漂移一会儿是A机器上的旧状态一会儿是B机器上的新状态最直观的表现就是用户明明刚说完一句话智能体却像失忆一样问“你好请问需要什么帮助”。1.2 会话状态里到底有什么拆开看一个智能体的会话状态至少包含四层而这四层的存储需求是完全不同的状态类型典型内容数据特征过期策略上下文窗口状态最近几轮对话、当前模型token窗口高频读写量小但极其敏感按轮次过期工作记忆状态用户意图、中间推理结果、待执行的工具参数短暂、易变、强时效性任务完成即清理长期记忆状态用户偏好、历史事实、过往对话摘要稳定、增长缓慢长期保留外部依赖状态第三方API的会话凭证、分页游标、回调地址不固定、牵连外部系统依赖外部生命周期这里每一类状态的处理方式都不同但几乎所有的早期架构都在干同一件事把它们一股脑塞进Redis。单线程读写快是快但一旦状态开始包含嵌套的JSON结构、需要按向量召回的历史记忆、需要版本回滚的快照Redis就变得很难受了。你不得不在代码里维护序列化和反序列化的逻辑而且只要客户端超时重试新旧状态一合并基本就乱套。我的实操建议是把“状态”当一等公民来设计而不是顺手塞缓存。至少要为智能体单独建一套“会话状态层”区分“热状态”当前正在跑的Agent循环和“冷状态”已归档的会话记录。热状态用内存态存储加定期快照冷状态落到持久化存储里同时保留一条从冷到热的恢复通道——用户随时说“继续上次的对话”系统要能快速把冷状态重新加载成热状态。1.3 状态恢复是一场重放而不是查一次库这里有个细节值得展开讲一下。智能体执行一个任务往往是多轮工具调用串起来的比如它先检索资料、再调用某服务、然后整理结果、再追问澄清。这整个链条如果中途断掉很多团队的做法是从数据库里读出最终结果硬塞给模型——这其实是错的因为模型的思维链断了。我个人的处理方式是**事件溯源Event Sourcing**的思路把Agent每一次决策、每一个工具调用的入参出参都记录下来恢复的时候不是直接恢复“最终对话”而是把关键事件重新加载进上下文让模型“接着之前的状态继续干”而不是“看着一个结果瞎猜”。这个思路前期会麻烦一些但一旦Agent的链路变长、多Agent之间开始转发任务这套事件日志会成为你调试和救命的唯一线索。2. 为什么云原生那套老办法在智能体场景下突然失灵2.1 请求-响应模型和Agent循环模型是两回事我接触过不少从传统微服务转过来的架构师他们一上来就习惯性地画K8s集群、画HPA自动扩缩容、画API网关——这套体系很成熟但用在智能体上有一个微妙的错位。传统服务的调用模式是请求-响应客户端发一个请求服务端算完返回连接可以断开服务节点不关心之前发生过什么。智能体的运行模式则是一个循环你发一句“帮我写个方案”Agent内部要经历大模型推理、调用检索工具、再推理、再调用工具、最终汇总回答——这个过程可能是几十秒甚至几分钟。而且这中间每个环节都依赖前一个环节的输出没法并行化也没法预先算好。最直接的后果是你没法用单纯的“QPS/延迟”来评估负载。两个用户、四个用户就能把这套链路跑满节点的CPU和内存指标看起来都没到瓶颈但Agent循环已经卡死在等待外部工具响应的状态里了。传统的水平扩容它的观测指标根本感知不到“这个节点上有多少个Agent循环正卡在半路”。2.2 长连接、流式输出与“无法预判的耗时”智能体用户体验上还有一个很折磨人的特性它必须流式输出。就像你和一个真人打字聊天你希望看到字一个个蹦出来而不是等十秒后一次性给你一堵墙。这就意味着从用户发出第一条消息到整个服务端完全处理完通道一直是保持的。这个“长连接”直接干翻了两种老设计一是无状态的HTTP网关模式网关很容易超时断开二是超时重试机制原来你调用一个接口超过3秒就重试现在一个Agent内部的一个工具调用都可能要5到10秒而且重试带来的副作用往往比超时本身更可怕——比如Agent调用的工具是“扣款”或者“提交订单”你重试一次就等于多生成一次扣款。所以智能体的基础设施里连接管理需要单独设计比如要支持双向的通道用户发指令、Agent回事件要允许一次任务中不断向用户推送中间状态要在网络抖动时保持会话而不是粗暴断链。这个通道本身才是智能体交互的真正载体HTTP轮询那套体验上基本过不了关。2.3 智能体的计算不再只发生在云端关于热搜词里提到的“边缘计算”和“所有计算都在云端完成延迟较高”这块我想多说两句。云端智能体的基础设施不能默认所有计算都放在云端数据中心。比如一些实时性要求高的场景——工业质检、车载语音、现场导览——你没法接受每一次交互都先走一遍云端往返延迟太高体验就会崩。一种可行的思路是分层推理云端放重模型做复杂推理边缘节点放轻量模型做意图预判和快速响应把跨网的调用尽量压缩。这次交互的大模型统一调度、小模型以及规则引擎的优先过滤、外部接口的提前握手这些动作全部由基础设施这一层来协调。坦白讲这套体系目前还在很早期的阶段但如果你做的智能体将来要在端侧和云侧之间切换你要在第一天就把基础设施设计成“计算位置可漂移”否则后面改架构的成本会让人崩溃。3. 编排运行时从单Agent跑通到万Agent调度之间缺的那层3.1 编排引擎才是真正的新基础设施很多人误以为模型 智能体实际上模型只是大脑编排引擎才是躯体。一个Agent任务跑起来要处理事件循环、工具调用的注册和分发、上下文的组装、中间结果的暂存、错误的重试和降级、多Agent之间的消息传递——这套东西目前还没有一个称得上“标准”的基础设施。市面上的低代码平台像Coze、Dify这类提供的是“编排的图形化界面”让你能拖拽出逻辑底层的任务调度、状态存储、工具注册其实都被封装掉了你只能在它给定的边界里跳舞。如果你自己用Python搭框架灵活度高但所有基础设施组件要自己拼装。这两条路线没有谁一定好但我观察到的是——平台的优势在于快速验证代码路线的优势在于可以真正构建自己的基础设施壁垒。3.2 编排引擎的核心职责把循环管好一个Agent的推理循环通常叫React模式Reasoning → Acting → Observation本质上是一个异步的、长期运行的事件循环。基础设施要为这个循环提供几个关键的底层服务第一步把“工具调用”变成和“模型调用”并列的一等实体。模型负责决定调哪个工具、传什么参数基础设施负责把工具真正执行起来、把结果返回给模型、处理工具本身抛出的异常。工具需要有统一的注册中心支持动态上线新工具、下线旧工具并且要有版本管理——不然你和第三方对接时它偷偷改了接口契约你的Agent在毫无预警的情况下就开始“说胡话”。第二步做好“暂停与恢复”。Agent循环天然是可以暂停的它在等一个外部工具返回结果时理论上可以把整个状态挂起、释放计算资源等结果回来再恢复执行。基础设施要支持这个语义否则一个Agent卡在一个慢工具上就会白白占住一整块GPU资源——这在规模化时是灾难性的成本浪费。第三步多Agent协作要有明确的消息拓扑。多Agent系统里Agent之间传递的不是单纯的文本而是带有上下文引用的任务对象。基础设施要提供共享黑板shared blackboard或者消息总线让AgentA可以把中间结果发布出去AgentB订阅并继续处理。没有这一层你只能靠丢到大模型的上下文里去“传话”那个上下文越长注意力越分散结果就越离谱。3.3 插件的装载模型从写死到动态装配还有一个基础设施的关键设计是插件的运行时隔离。工具调用链实际上是一个动态装配的过程不同用户、不同策略可能启用不同的工具集Agent要根据当前任务语义按需选择工具。这要求工具本身提供清晰的输入输出Schema并且基础设施要限制每个工具的权限边界比如只允许访问某些API域避免“一个工具调用把整个系统拖下水”。这里的安全性不能忽略。第三方工具的本质是不可信代码你要么让它在独立进程中跑、承载独立的凭证要么在基础设施层加一层请求转发和响应过滤。这个领域目前还没有太成熟的开源方案大多数时候要靠团队自己动手但它直接决定了你的智能体在生产环境敢不敢接入第三方服务。4. 记忆与存储智能体需要的是上下文仓库不是一个缓存4.1 为什么Redis和数据库都不够用我前面提到会话状态这里想把它展开成一个独立的话题。智能体的数据基础架构和传统应用有本质差异——传统应用存的是“业务数据”智能体存的是“上下文事实经验”的混合体。举一个具体的例子。用户问“老王的联系方式是什么”传统做法直接查数据库调出一条记录。智能体的做法完全不同它可能需要同时检索用户长期记忆库老王是谁、短期对话上下文今天上午是不是聊到过、公共知识库如果联系方式的格式需要额外说明然后把这些证据一起塞给模型做判断。所以说智能体的存储实际上是是一个可以支撑多路检索、多粒度层级的上下文仓库而不是一张二维表。这里有三类存储是必须分开设计、互相配合的短期窗口存储承载当前对话的原始上下文。通常用量不大但对延迟极其敏感任何一次模型的输入请求都要从这里组装上下文。适合用内存态服务加高速访问层。长期记忆存储承载跨会话的长期信息如用户偏好、历史要点、事实积累。特点是增长缓慢、需要按语义检索。向量数据库在这里是刚需但是要特别注意“记忆的写入策略”——不是什么对话都值得长期记住基础设施最好保留一道“值得一提才写入”的过滤器。会话快照与日志承载“可恢复性”。事件溯源的说一遍每次任务完成后把完整状态序列化存档出问题时可以回滚到任意时间点重新放。这个能力极大降低生产事故的爆炸半径——不是“整个服务不可用”而是“这个用户的会话回滚到了五分钟前”。4.2 向量检索不是万能药记忆需要分级关于向量库我提个反直觉的观点向量检索是记忆系统里最不重要的一环。重要的是怎么组织记忆的层次。比如一个知识助手类Agent你不可能把每一次对话内容都塞进一个embedding里然后丢向量库。你会很快发现用户问的问题五句里有三句是重复问过的。“调Fine-tuning”不是你要做的事情基础设施应该支持一个“摘要-压缩-沉淀”的机制把旧的对话片段定期浓缩成摘要把真正重要的结论和事实抽出来进长期库把日常寒暄和碎片信息丢弃。这个系统设计得很干净的话Agent能在几个月后仍然准确回应“你之前跟我说过你喜欢喝冰的手冲”而这个“记得”不是碰巧是基础设施里专门的记忆管理模块在起作用。4.3 上下文组装把对的信息放到对的回合最后一个存储相关的问题是上下文窗口是有限的哪怕百万token也有上限而且越长推理延迟越高、越容易丢失重点。基础设施需要有一套上下文组装策略从长期记忆里挑相关的、从近期对话里保留细节、从工具调用记录里复核参数最后打包成一个结构清晰的输入。这个组装过程值得做AB测试——同样一个用户问题不同的记忆排序方式模型回答质量差很远。经验是把离当前意图最近的、有明确指向性的记忆块放在上下文的头部比按时间顺序硬堆要有效得多。5. 工具调用链的可靠性智能体最容易翻车的地方不在模型在外部依赖5.1 超时、重试、幂等一个都不能少智能体要落地大概率要调用外部工具。而外部工具的最大的特性就是两个字不可靠。网络抖动、对方限流、数据格式变更、服务临时下线……每一条都会让Agent循环中端。最基础的三个工程手段必须做到首先是超时管理。工具调用的超时不能是全局默认值而应该是按工具的契约单独配置。有些工具本身就要跑20秒你设个5秒超时等于自废武功。同时超时后的降级策略也需要明确——是换一个替代工具还是把错误反馈给模型让模型决定下一步还是干脆向用户解释后终止。其次是重试策略。很多工程师习惯于“失败了就立刻重试”这在智能体链路里风险很高。推荐的做法是指数退避随机抖动重试次数严格控制每次重试之前记录当前状态是哪一个工具、跑了第几轮不然重试本身就会污染上下文的连贯性。最后是幂等设计。如果一次工具调用是“下单”、“发消息”、“转账”这类有副作用的操作基础设施必须要支持传入一个幂等键。你没法保证工具方一定支持幂等但你可以做到当不确定这次请求是否成功时不盲目重发而是先查“这次操作的结果是否已经发生过”。比起多调用一次带来的副作用宁可返回一个“我这边确认不了请您再试一次”的答案也绝不能让用户被扣了两次款。5.2 工具的契约管理从文档驱动到Schema驱动现代智能体框架都倾向于用JSON Schema来定义工具参数这是对的。但我想补充的是契约管理不能只停留在文档层面。当你的Agent要管理几十个工具时你会遇到几个实际问题工具的字段命名风格不一一会儿是user_id一会儿是userId新旧版本接口并存有些工具返回的是markdown、有些返回纯文本、还有返回图片的。基础设施要建立一个工具适配层把不同的外部接口规范化为内部统一的格式再让模型去理解。真的不要期待模型“足够聪明来搞定所有格式的差异”——哪怕它能也扛不住后续新增20个工具时的上下文混乱。另外一点工具调用的入参校验必须在基础设施层做不要等到外部接口返回错误才反应过来。模型生成的参数往往会有幻觉比如虚构了一个根本不存在的storeId。基础设施可以在模型层之后、执行层之前增加一道Schema校验长参数的类型、枚举值、必填项全部在这里拦一道不合格的直接让模型重新生成参数而不是傻傻地把错误请求发出去。5.3 沙箱与安全边界不信任是基础设施的第一步工具调用本质是把系统的控制权部分交给了模型但这必须在一个安全边界内。基础设施要为每个Agent实例创建独立的凭证和沙箱环境让Agent A拿到的工具凭证不能访问Agent B的数据。这具体做起来分为三层网络层限制出站IP和服务域数据层限制读取字段的范围操作层限制对敏感动作的授权。尤其要注意的是“工具叠加的越权”——单个工具各自看起来权限都有边界但当Agent分几步把工具A的输出当作工具B的输入时就可能拼出一条越权路径。基础设施要提供调用链审计把这层风险暴露出来。6. 可观测性、行为审计与成本治理规模化绕不开的第三座山6.1 Trace的粒度要到工具调用级不要只看API耗时传统APM工具观测的是接口响应时间这在智能体场景下远远不够。你真正需要的是按Agent会话维度的全程追踪用户说了什么、模型回什么、内部经过了几轮推理、每一轮调用了哪个工具、工具返回了什么、中间哪一步磨蹭最久。这里给你推荐一套标准的打点结构session_id贯穿始终每一轮工具调用记录parent_id极其清晰地画出整棵决策树。放在生产环境里当用户投诉“智能体回答奇怪”时你可以直接缩放找到其中最可疑的那次工具调用——什么输入导致模型做出了错误判断。没有这套打点排查Agent类问题基本就是大海捞针。6.2 行为审计是硬需求你到底能不能说清Agent干了什么热搜词里有个“智能体行为审计是什么意思”值得聊一下。简单说就是审计Agent每一步行为是否符合预期和规范。这在金融、医疗、法律这些高合规场景里几乎是强制要求——你不能一句话说“AI会自动审批贷款”就把责任推给系统。基础设施要为行为审计提供三件事完整的运行日志谁在什么时间以什么参数调用了什么工具、策略检查点关键决策前要触发规则引擎不符合条件的直接拦截、事后分析通道把日志导入离线分析平台定期跑合规报表。这套机制可能不会直接提升用户体验但它在关键时候可以帮你免掉巨大的合规麻烦。6.3 成本治理大模型账单是一笔一笔“推理token”算出来的智能体和传统服务最大的成本差异就是每一次运行都是用token付费换来的。一个复杂任务消耗上万token是很正常的事情而成本失控的根源往往不是单次调用太贵而是无谓的重复调用上下文里塞了一堆没用的历史导致token变长、相同的问题反复问大模型而不是走缓存、工具调用失败后重试时又把旧结果重新组装一遍。成本治理的基础设施可以分三层做缓存层相同或相似的问题命中最近的答案不进模型。信息密度高的知识问答场景下这层能省掉35%以上的调用支出我有实测经验。路由层把不同复杂度的问题分到不同规格的模型。判断“你好你是谁”这种简单意图用小模型足够别总让旗舰模型跑。预算层按会话或按用户设置token上限和消耗告警一旦超出系统自动降级比如改用更便宜的模型或者限制工具调用次数。没有这层约束规模化之后一个月账单出来你可能会怀疑财务是不是算错了。7. 落地路线图别想着一口吃成胖子最后聊聊落地顺序。基础设施这个事儿最忌讳的是“一开始就想建一套完美体系”那不是架构设计那是乌托邦。我的建议是分四个阶段迭代每个阶段聚焦解决一个核心问题。第一阶段解决“能稳定跑完一个会话”的问题。不管用什么框架先把会话状态的持久化、恢复、幂等重试做扎实。这一阶段的目标是单个Agent任务在生产环境下不会因为网络波动、程序重启而“失忆”。这是地基地基不牢后面全白搭。第二阶段解决“并发和调度”的问题。引入独立的编排引擎把Agent循环从业务代码里抽离出来支持多实例并行、挂起恢复和简单的多Agent消息传递。这一阶段的目标是从10个并发用户扩展到1000个并发用户时服务依然稳定。第三阶段解决“可观测与成本”的问题。把全链路打点做完整把成本统计和缓存策略接入进来。这一阶段要开始看数据了——你的Agent平均每单消耗多少token、哪类工具的调用最耗时、哪类问题可以走缓存。没有数据就没有优化这一阶段做完你会突然对“扩展”有了新的理解。第四阶段解决“安全与合规”的问题。引入行为审计、策略网关、沙箱隔离。走到这一步意味着你已经要从“能用”进化到“能被信任”至少让审计人员能看得懂你的Agent在干什么。我一直觉得云端智能体的终局不是靠某一个单体组件撑起来的而是一整套围绕“有状态、长循环、多依赖”这些特性重新设计的基础设施。它现在还很新没有标准答案但正因为如此越早动手搭的人越能在下一波竞争中占住身位。最后分享一点个人的习惯每次别人问我“智能体基础设施到底从哪开始”我给的答案永远是从“会话状态”开始。先把一个用户会话完整地、可靠地管好再谈并发再谈规模再谈优化。这就像盖房子地基决定了你最后能盖多少层。智能体的扩展瓶颈表面看是模型推理、并发能力和算力问题实际拆到底层全是状态、编排、契约、可观测性这些基础设施问题在隐隐作痛。希望这篇把痛点讲透的文章能让你在做技术选型时少走一些我走过的弯路。