1. 先拆清楚智能体的“扩容”到底在扩什么1.1 智能体与普通服务差在哪做云原生和AI基建这几年我越来越确定一件事云端智能体的扩展瓶颈已经从模型智商转移到了基础设施的工程化水位上。上个月跟一个做企业客服智能体的团队聊他们从内部Demo走向生产服务几十家客户的时候一切还算顺但客户数翻到三位数之后各种怪问题接踵而至——同样的请求响应时间从2秒变成8秒甚至更久账单金额每个月涨得离谱更头疼的是用户投诉智能体给错了退款金额事后排查了半天根本不知道那个Agent当时为什么那么判断日志里只留了一句“已调用退款接口”。这不是模型不够聪明而是整个系统的底座没有跟上。传统Web服务是“请求-响应”模式一次请求进来算完返回就结束了状态顶多存个session在Redis里。智能体不是这样——一次用户请求可能触发多次LLM调用、多次工具调用、多次知识库检索。一个客服Agent处理“改地址”这件事可能要走CRM查订单、查配送状态、更新地址、发通知、生成确认话术整条链路里每一步都在消耗token、消耗时间也在积累出错概率。所以给智能体扩容本质上不是“加几台GPU”这么简单。你要回答的问题变成了状态存在哪、任务怎么恢复、出错怎么查、权限怎么控。这四件事比单个模型跑多快重要得多。1.2 从三个层面理解基础设施我做架构拆分时习惯把智能体的基础设施分成三层计算层LLM推理资源包括GPU集群、推理引擎、缓存、限流器。这一层解决的是“算得动、算得便宜”。状态层会话状态、任务状态、长期记忆。这一层解决的是“记得住、断得了、恢复得起来”。治理层工具权限、安全沙箱、可观测性、评估体系。这一层解决的是“信得过、查得清、改得动”。三层之间不是独立的。计算层省下来的成本可能因为状态层设计不好又烧回去治理层如果缺位一次错误的工具调用就可能造成比算力贵得多的损失。我见过不少团队把90%的精力花在优化推理成本上结果一次Agent幻觉调错接口赔掉的金额顶得上几个月省下的token钱。还有第四个隐藏瓶颈调试与评估的成本。传统服务出Bug靠日志和堆栈就能定位。Agent出问题你得知道它当时接收了什么指令、想到了哪些候选方案、为什么选了那个工具、工具返回了什么——这些信息缺一环整个排查就卡住。而这种排查成本是随用户规模非线性上涨的用户越多出错样本越多你越需要一个系统化的可观测和评估体系而不是靠人肉看对话记录。2. 算力层的真实账本token经济决定你的商业模型能跑多远2.1 上下文越长钱烧得越快先算一笔具体的账。假设你做一个企业客服Agent每个会话平均要携带2万token的上下文包含历史对话、系统提示、工具定义每次生成约800token的回复。按主流大模型API的公开计价粗略估算输入侧每百万token约5美元、输出侧每百万token约15美元那单次交互的成本大约是输入20000 / 1000000 × 5 0.1美元输出800 / 1000000 × 15 0.012美元单次合计约0.112美元如果每天有10万次交互一个月就是30万美元级别的支出。这时候你会发现模型能力再强商业模型也扛不住这个成本结构。更麻烦的是上下文膨胀——Agent在工具调用循环里每次工具返回结果都会重新拼进上下文导致后一轮请求的输入越来越长。我见过一个只有5个工具调用的简单任务硬是烧掉了十几万token就是因为每次把工具完整返回结果原样塞回去没有做任何裁剪。这里有两个必须接受的现实第一Agent的token消耗和任务复杂度强相关不是你控制提示词就能完全压住的第二上下文越长不仅贵延迟也高因为prefill阶段要对所有历史token做注意力计算。所以算力层的第一个优化方向不是换更贵的模型而是把token预算变成一种需要主动管理的资源。2.2 我见过最有效的三个省钱手段第一个是前缀缓存。系统提示、工具定义、 few-shot示例这些内容在每次请求之间是高度重复的主流API都提供了prompt caching能力命中缓存后输入成本能降到原来的四分之一甚至更低。你别小看这个大部分Agent请求的输入里固定前缀可能占了70%以上。接入缓存之后我见过不少项目的成本直接砍掉四成。第二个是模型路由。不是所有请求都值得用最强模型。一个客服系统里“查订单状态”“改地址”这类意图明确的任务用中等模型完全够只有遇到复杂推理、多步规划时才升级到旗舰模型。你可以用一个小模型做意图分类再决定路由到哪个模型这一步能省下的钱非常可观。第三个是蒸馏和微调。针对你的业务数据微调一个专用小模型在特定任务上的表现可能直逼大模型但成本只有十分之一。这条路前期投入比较大适合用户量已经上来、任务模式相对固定的场景。如果还在早期先用缓存和路由就够了。2.3 灵活调度比堆硬件重要算力层还有一个常被忽略的点GPU资源的弹性调度。Agent流量有明显的波峰波谷早上和下午是咨询高峰深夜可能没几个请求。如果按峰值容量常驻GPU成本可想而知。现在通用的做法是Kubernetes加GPU调度器配合推理引擎的按需扩容。但有个坑——GPU冷启动可能要几分钟如果扩容策略太激进用户会直接感受到“卡顿”太保守又浪费算力。我比较推荐的做法是维护一个热池保留少量常驻实例兜底再根据队列长度动态扩容。同时给每个租户设置token预算上限超过阈值自动降级到缓存命中率更高的模型或者排队防止个别异常会话把整个集群的资源吃光。这类预算机制看起来不够“智能”但生产环境里最管用的往往就是这些朴素的护栏。3. 状态与记忆云端智能体最难跨过去的一道坎3.1 三类状态三类存储方案智能体的“状态”比普通应用复杂得多我习惯把它拆成三类来设计会话状态一次对话内的短期上下文比如用户刚说了什么、Agent上一步回复了什么。适合放Redis这类热存储读写快过期自动清理。任务状态一个多步任务执行到哪一步了比如“退款流程已经走到财务审批等待回调”。这类状态必须持久化最好用事件溯源的方式落盘否则任务执行到一半系统重启整个流程就断了。长期记忆用户的偏好、历史订单、常见问题沉淀。这类数据需要长期保留通常是向量库加结构化数据库混合存储向量库负责语义召回关系库负责精确查询和事实校验。很多人把这三类混在一起存结果就是要么Redis里堆了一堆本该持久化的任务数据要么把长期记忆塞进会话缓存导致成本失控。状态分类这件事在架构设计阶段定清楚后面能省掉大量返工。3.2 向量数据库不是万能钥匙长期记忆这块不少团队一上来就上向量库然后发现效果并不理想。向量检索本身是一个近似匹配过程top-k结果里经常混入不相关内容用户画像这类数据更新频繁向量索引的更新成本比一般业务数据高得多而且存储成本随数据量线性增长量大了之后检索延迟也会上去。我现在的习惯是语义召回定候选再用规则或结构化查询做二次确认。比如Agent要回答“用户上次投诉过什么”先向量召回相关对话片段再结合用户ID去关系库确认这些对话确实属于该用户、确实属于投诉类型最后才把结果交给LLM组织语言。多这一步准确率提升很明显成本增加却很有限。3.3 故障恢复会破坏Agent的“思路连续性”生产环境里pod崩溃、网络抖动、第三方API超时都是常态。如果状态都存在进程内存里Pod一重建Agent对当前任务的理解就全丢了。我们之前在Kubernetes里跑Agent就踩过这个坑一个订单处理任务执行到一半Pod被重新调度重启后Agent完全不记得之前查到的订单号和审批结果直接给用户回复了一句“我没有找到您的订单”体验非常糟糕。解决这个问题最有效的模式是事件溯源。把Agent的每次决策、每次工具调用入参和返回、每次收到的新消息都按顺序追加写入一个持久化的事件流里。任务恢复时从事件流里重放整个决策过程Agent就能“接续记忆”继续往下执行。这本质上跟分布式系统里的redo log是同一个套路只不过日志记录的不只是数据变更还有智能体的思维步骤。4. 工具调用规模化的安全护栏一个烂工具定义就能毁掉整个Agent4.1 工具注册与权限收敛Agent的能力边界由工具定义决定而很多团队给Agent接工具的时候远没有接一个内部API那么谨慎。工具函数的描述写得很随意、参数没有schema校验、版本更新直接换函数名导致Agent经常把参数传错或者调用已经废弃的接口。正规做法是搞一个工具注册中心。每个工具都要有完整的OpenAPI或JSON Schema描述包括参数类型、必填项、枚举范围、接口幂等性说明。Agent只能调用注册中心里存在且被授权的工具。权限上要做到工具级收敛——不是所有Agent都能调所有工具按租户、按用户、按Agent角色分别授权。尤其要注意普通用户的对话里是可以诱导Agent调接口的prompt injection不是理论风险是每天都在发生的事。4.2 高危操作必须有人工确认回路把工具按危害程度分级是最简单也最有效的安全设计只读类查订单、查天气可以Agent自主执行写入类改地址、发通知需要二次确认高危类退款、删除数据、转账必须插入人工审批节点。这个人工确认回路应该是基础设施的一部分而不是业务逻辑里的“待办事项”。我们在一个金融场景里就吃过亏Agent因为工具描述写得不够严格把一个删除接口当成了更新接口调用了。好在数据库层有软删除保护数据没真丢但这个教训让我们把“所有非只读操作默认进确认队列”写成了平台级规则任何人不能绕过。成本是多了一次人工点击但跟一次误操作的风险比起来这笔钱花得太值了。4.3 防止工具调用的“多米诺骨牌”Agent在工具调用循环里可能陷入死循环或级联错误。一个失败的调用可能触发重试重试又触发另一个工具最后形成调用风暴。我们遇到过Agent反复调用一个限流接口把对方的配额打满导致所有租户的请求都堵住。防护措施有几个每次任务设置工具调用次数上限超过就强制终止并转人工单次工具调用设置超时时间对外部依赖做熔断连续失败N次就中断任务所有工具的调用和返回写入审计日志。这些规矩看起来繁琐但规模化之后它们就是Agent不跑偏的底线。顺带说一句审核日志非常重要——谁在什么时间、通过哪个Agent、调用了什么工具、传了什么参数、返回了什么结果这些信息在出事的时候就是唯一的真相来源。5. 可观测性Agent全线并发时你先得回答“它为什么这么做”5.1 给智能体做一次完整链路追踪传统可观测性关注的是接口延迟、错误率、饱和度这些对Agent远远不够。你需要记录的是“推理过程”而不只是调用结果。我们的做法是基于OpenTelemetry扩展一套Agent追踪体系用统一的trace_id把一次用户请求涉及的所有环节串起来LLM调用、知识库检索、工具调用、中间决策节点。每个span里记录详细字段包括发给模型的完整prompt、模型返回的原始响应、选用了哪个工具、工具输入输出、token用量、延迟、成本、模型名称。这些数据的存储量很大但有价值的调试信息恰恰都在里面。生产排查问题时如果没有这些数据你连Agent为什么选错工具都无从判断。5.2 回放、评估与回归测试有了完整的事件流你就能做Agent轨迹回放。把一次有问题的会话逐帧还原看清每一步的输入输出定位是哪一步的上下文把Agent带偏了。我们内部管这个叫“Agent回放调试”它比看日志高效得多。回放只是第一步更重要的配套是评估集。维护一批有代表性的用户问题每个问题标注期望行为比如“应该调用查订单工具不应该调用退款工具”对模型或规则变更做回归测试。这个思路跟传统软件工程的单元测试一模一样只不过断言的不再是函数返回值而是Agent的决策路径。每次升级系统提示词、换模型版本、增删工具都先跑一遍评估集再上线。没有这套东西迭代基本等于赌博。还有一个小技巧在Agent内部埋决策日志。每个推理步记录当前的候选工具列表、每个候选的置信度、最终选择、选择理由。这些信息能让你快速判断是检索问题、提示词问题还是工具定义问题而不是对着黑盒瞎猜。5.3 成本可视化按租户、按任务拉平可观测性不只用于排查错误也用于管钱。按租户维度统计每个客户的token消耗、按任务类型统计单次成本是优化成本结构的基础。你只有知道哪类任务在烧钱、哪个租户成本异常才能有针对性地做预算、做路由策略、做缓存优化。很多Agent项目“账单爆炸”本质上不是用量涨了而是没有成本指标问题被掩盖到月底才暴露。把成本埋点做成基础设施的一部分从第一天就接入比事后补救简单太多。6. 基础设施层的下一步标准化协议与平台化竞争6.1 MCP把工具接入从“私有适配”变成“公共插拔”当前Agent工具接入最大的痛点是碎片化。每个Agent框架、每个云平台都有自己的工具接入格式换一套框架就要重写一遍工具适配层。MCPModel Context Protocol这类标准化协议的意义在于它把工具、资源、提示词模板统一成一套公共格式Agent与工具之间通过协议解耦。你写好一个MCP服务理论上可以被任何支持该协议的Agent调用不再需要为每个模型、每个框架单独适配。这对基础设施的生态影响是深远的。工具会像数据库驱动一样可以即插即用Agent平台的竞争焦点从“能接多少工具”转向“接得稳不稳、跑得便宜不便宜、管得安不安全”。对于业务团队标准化的直接好处是新工具接入的成本从一个星期缩短到几小时同时可观测性和权限控制可以复用平台能力。6.2 云平台上的Agent基础设施正在成型云厂商过去解决的是Web服务的弹性、存储、网络现在开始把目光投向Agent所需的完整技术栈模型网关统一管理多个LLM API、推理缓存降低成本、向量数据库作为托管服务、Agent的可观测性和评估体系做成一站式平台。这意味着跑一个生产级Agent的门槛正在快速下降不用再自己运维一堆组件。但平台化也带来一个风险容易被单一厂商绑定。我的建议是在架构设计上尽量使用标准化接口模型接入走统一的兼容层工具定义按MCP标准写状态存储选Postgres、Redis这些通用组件可观测数据按OpenTelemetry格式输出。这样未来无论是自建还是换平台你的核心资产——工具定义、状态数据、评估集——都能平滑迁移。还有一件事容易被当成纯技术问题忽略人机协作机制。高危操作的人工确认、任务转人工处理、Agent自我评估失败后的人机交接这些流程设计其实也是基础设施的一部分。它直接影响你能否在真实业务里安全地规模化使用Agent。平台化竞争到后面拼的往往不是模型多强而是这些“无聊但必要”的工程能力。做了几年Agent基建我最大的体会是不要等用户量上来了才补课。状态存储、成本预算、可观测性这三件事最好在第一个生产版本就做进去。开始可能觉得“不过是个Demo而已”但Demo和生产的距离就是这些基础设施的距离。如果你的智能体还在早期哪怕不换架构至少先做两件事——把每次LLM调用的token和成本记下来把Agent的决策过程以事件流方式落盘。这两件事成本极低等真出问题时它们就是你的救命稻草。