最近一周我连着跟几个正在做Agent产品或者正准备转Agent方向的团队聊了同一个问题“你们的基础设施真的扛得住吗”得到的回答惊人地一致Demo阶段万物美好一进生产环境就露怯。有人是账单先爆了有人是并发一高推理服务就开始排队有人是线上任务三天两头卡在某个工具调用上。表面症状各不相同根子却都在同一个地方AI Agent对基础设施的要求跟传统LLM应用完全不是一个量级。这篇文章不聊Agent能做什么专门聊它背后真正要付出的三个代价Token成本、上下文与状态、工具链可靠性。读完你至少能算清楚自己的系统哪里有裂缝、下一步该补哪块。1. 先算一笔账Token成本如何从加法变成乘法1.1 一次最简单的Agent任务背后藏着多少次推理很多人对Agent成本的误解来自把Agent任务当成一次普通对话。传统Chatbot场景很简单用户输入一个问题模型输出一个回答计费等于输入Token加输出Token一次请求一锤子买卖上下文基本固定成本几乎可以线性预测。Agent完全不是这个逻辑。我拿一个最基础的场景举例用户让Agent查一下某城市未来三天的天气再根据天气情况判断适不适合安排户外跑步。整个任务大致会有这么几步第一步用户问题进入系统模型要进行规划判断自己该调用哪个工具。假设系统提示加用户问题一共约800 Token模型输出一段执行计划约200 Token。第二步系统按计划调用天气查询工具拿到一份结构化天气数据假设这份数据有1500 Token。第三步把这些内容拼回上下文再次请求模型让它判断这些数据够不够、要不要继续查空气质量、还是直接生成最终答案。注意此时输入已经不是800 Token了而是800加200加1500约2500 Token模型最终输出约500 Token的建议。两轮下来一次完整任务的实际消耗大约是五千多Token。你可能觉得这也没多少但请注意这只是一个工具调用一次的“最简单任务”。如果换成“帮我比价并下单一个商品”这种真实场景中间会包含搜索、打开商品页、读取评价、对比参数、确认库存、提交订单、确认结果少说七八次工具调用。每一次调用前面所有步骤产生的历史消息都会重新进入输入上下文。可以说Agent任务执行多久成本账单的闸门就开多久。1.2 为什么多轮决策会把成本推到10倍以上这里的关键机制在于现代Agent几乎都会把完整历史消息原封不动地塞回模型上下文让模型“记住”自己之前做了什么。工程上这样实现最省事但成本账非常难看。用一个近似公式感受一下假设一个Agent任务需要执行N次模型推理第i次推理的输入长度为L_i Token那么累计输入消耗等于所有L_i的总和。而L_i会随着历史累积不断变大。假设初始上下文有1万Token每执行一步工具返回平均3000 Token模型输出平均500 Token。到第10步时单次推理的输入已经膨胀到1万加9乘以3500约41500 Token。十步下来总输入Token不是4.15万而是所有步骤输入量的累加大约23万Token。对比传统Chatbot用户连续问10个问题每个问题输入1万Token总计就是10万Token且问题之间互不牵连每次计费干净利落。Agent同样是10步总消耗却是23万Token这里面还没算输出端的开销。我习惯把这种差别叫“加法变乘法”传统对话是问题数量乘以单次成本Agent是你每多走一步都要为之前所有步骤重新付一次费步骤越多放大效应越夸张。我在一个实际项目里测过同一类用户需求做成传统问答式应用单次请求平均消耗约1800 Token改成Agent形态后单次完整任务平均消耗超过18000 Token整整10倍的差距。这不是翻倍的问题是数量级的差异。很多团队在原型阶段用的是免费额度或者测试密钥完全没感觉一上生产所有请求按真实价格计费第一个月账单就能把人看懵。1.3 成本控制的第一板斧不是降模型而是砍上下文既然问题出在“历史重复计费”那么成本控制的核心方向就很明确让每一轮推理携带的上下文尽量短而不是盲目去换更便宜的模型。第一级手段是上下文摘要压缩。当对话历史超过某个阈值时把前面的内容用模型压缩成一段摘要每轮只带摘要加上最近的几步。代价是Agent可能丢失长程细节比如用户三小时前提过一个约束压缩之后就忘了。所以压缩策略要配合“关键信息显式提取”把用户约束、已完成步骤、当前结论单独拿出来作为结构化状态保存不能完全依赖模型从历史里找答案。第二级手段是语义缓存。传统缓存在Agent场景照样能用只是缓存粒度要从“最终答案”变成“子任务结果”。比如Agent经常查同一城市的天气五分钟内数据没变这个工具返回结果就可以直接命中缓存省掉一次真实调用。缓存省下的不只是工具调用费用更重要的是省掉后续推理把大量工具返回塞进上下文的开销。我在天气、汇率、库存这类更新频率不高的工具调用上做过统计缓存命中率能到20%到30%对整体成本的改善非常明显。第三级手段才是模型分级。简单任务用轻量模型跑复杂任务才派重量模型。很多团队一上来就全局用最强模型文档检索和资产分析都是同一个模型在处理非常浪费。Agent编排层应该支持按任务复杂度路由一步能搞定的查询走轻量模型需要工具编排和深度推理的才走重量模型。提示不要一上来就迷信“超长上下文”方案。几十万Token的上下文窗口会显著抬高单次推理成本并且让KV Cache的显存占用肉眼可见地飙升。超长上下文是少数特殊场景的备选工具不是用来解决Agent通用成本问题的万能药。2. 上下文与状态内存和存储被低估的账2.1 KV Cache的数学题一个8K上下文的请求吃掉多少显存第二个容易被忽视的代价是推理时的显存与内存压力。很多团队评估推理服务能不能扛住并发时只算了模型参数本身的显存占用完全漏掉了KV Cache。大模型在推理时每生成一个Token都要参考前面所有Token的Key和Value向量推理框架通常会把它们缓存起来避免重复计算这就是KV Cache。它的大小跟模型结构强相关跟序列长度基本呈线性关系。我这里给一个可以直接套用的估算公式KV Cache显存(字节) 约等于 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数前面的2对应Key和Value两组向量。假如你部署一个常见的7B参数量开源模型假设层数32注意力头数32每个注意力头维度128使用fp16精度也就是每个参数占2字节。当某个请求的上下文长度来到8192时seq_len 8192 layers 32 heads 32 head_dim 128 bytes_per_param 2 # fp16 kv_cache_bytes 2 * layers * heads * head_dim * seq_len * bytes_per_param print(f单请求KV Cache占用约: {kv_cache_bytes / 1024**3:.1f} GB) # 输出结果约 4.0 GB算下来一个请求还没开始生成输出就要为KV Cache预留约4GB显存。如果同一个推理服务上挂着32个并发任务且每个任务上下文都接近8KKV Cache总占用就超过128GB。再加上模型参数本身约14GB的显存一张80GB显存的卡实际能同时服务的Agent任务数远比想象中要低。Agent场景对KV Cache尤其不友好因为它的上下文只增不减任务执行期间KV Cache一直霸占着显存。传统Chatbot还能做成无状态用完就释放Agent任务一旦开始你就得为它的整个生命周期持续预付这部分显存成本。2.2 从无状态到有状态Agent服务架构的隐性转向KV Cache是显存层面的压力状态存储是架构层面的压力。传统LLM应用可以设计成无状态请求进来、模型算完、返回结果、一切清空。Agent应用做不到一个任务从开始到结束中间有海量需要跨步骤保留的状态。这些状态包括任务执行到第几步、已经完成哪些工具调用、工具返回的中间结果放在哪、当前处于规划阶段还是执行阶段、用户最初的需求和约束是什么。如果任务被调度到另一台实例上继续执行状态必须能够跨实例访问。很多团队第一次做Agent时很自然地用进程内变量把任务状态存了下来。原型阶段没问题一旦部署成多实例或者进程被滚动重启所有正在跑的任务会静默丢失。我听说过一个真实的线上事故某Agent平台发版时重启了服务所有用户的进行中任务全部清零用户以为自己的申请已经提交成功实际上后端什么都没发生。这就是典型的把无状态思维硬套在有状态系统上。正确做法是引入持久化任务存储比如把任务状态快照写入数据库或KV存储每次状态变更都落一次盘任务任何时候都可以从最近快照恢复。这个改造不复杂但它决定了你的Agent系统配不配得上“生产可用”这四个字。2.3 崩溃恢复不是重跑一遍这么简单Agent与传统批处理任务还有一个关键差异它的每一步动作都可能产生外部副作用。某一步调用了外部系统的“提交申请”接口然后进程在确认结果之前崩溃了。任务恢复时你没法简单地从上一步重跑因为外部系统那边可能已经真的提交了一份申请。这时候你必须先判断清楚那次提交到底有没有生效。这就是幂等和查询式恢复的课题。最稳妥的做法是Agent每一次调用外部工具都带上全局唯一的执行ID外部系统配合做幂等同时提供查询接口Agent恢复时可以查询“以ID为X的那次操作是否已经生效”。听上去像在做分布式事务本质上确实是。如果外部系统不配合幂等备选方案是“执行前确认加执行后对账”。执行前明确告诉外部系统这是一个Agent自动操作执行后主动查询结果来消除不确定性。这套机制在涉及支付、订单、消息发送这类场景时尤其重要。很多团队等到重复下单了才回头想这个问题不如架构设计阶段就定好规则。3. 工具调用链越长成功率跌落越快3.1 99%的接口成功率放在Agent场景里根本不够第三个代价关乎稳定性。传统应用里99%的接口成功率已经是非常优秀的成绩但放到Agent场景里这个数字根本不够看。原因很简单一个Agent任务往往要串行调用多个工具。如果每个工具的成功率都是99%一个需要10次工具调用的任务整体成功率只有0.99的10次方约90.4%。这意味着每10个任务就有1个失败对生产系统来说已经很糟糕了。更现实的是工具调用之前还有模型推理这一步而模型本身也会犯错输出格式非法、幻觉参数、选错工具。把模型这环的成功率也按95%估算10步任务的整体成功率就是0.95的10次方只有约60%。60%的成功率意味着什么用户每发起两次任务差不多就有一次不能顺利完成。这种体验积累起来用户很快就会判定“这个AI根本不可用”。我见过不少团队在Demo阶段只演示成功路径对失败路径毫无感知一进生产环境失败率立刻暴露技术团队被迫长期救火一边是用户投诉一边是日志里各种奇怪的半途失败。3.2 模型与工具故障交织最难排查的一类问题传统服务的报错链路是清晰的调用支付网关返回500那就是网关挂了查网关日志就行。Agent的报错链路是模糊的用户说“帮我处理一下报销申请”Agent查询审批系统系统返回“状态未知”模型把这个结果理解成“需要重新提交”于是真的调用了提交接口最后用户看到的是两份重复的报销单。这类问题的根因不在任何一次单独的工具调用而在于模型误读了工具返回。你查工具服务日志会发现它一切正常查模型推理日志会发现模型也“严格按照指令执行了”。每一步单独看都没毛病拼在一起就出错。排查这种问题必须看完整的决策轨迹模型每一步看到了什么、怎么想的、为什么选这个动作、工具返回了什么、模型又是怎么理解这个返回的。所以Agent对日志格式的要求比传统应用高得多。普通错误日志只在失败时打印Agent场景需要的是成功时也打印完整轨迹并且所有步骤都带上同一个任务ID。没有这个基础遇到这类问题基本只能靠猜排查效率极低。3.3 可观测性从链路追踪到决策路径溯源既然决策轨迹这么重要落地时该看哪些指标我这里列一张表基本覆盖了Agent生产环境最该盯住的六个核心指标指标说明关注点任务成功率完整Agent任务中成功完成的比例低于90%就要查工具配置或模型选型平均完成步数单个任务的平均推理加工具调用次数波动过大通常说明模型在绕圈每任务Token消耗单个任务的平均成本消耗观察趋势涨得最快的环节优先优化工具调用失败率各外部工具独立统计的失败率快速识别最脆弱的下游依赖思考-行动循环次数模型重复规划某个目标的次数出现峰值时可能是在死循环烧钱恢复重试次数任务从检查点恢复的频率太高说明上游基础设施不稳定落地时不需要一上来就搞花哨的可视化大屏。先把日志规范性做好每次模型调用记录输入摘要、输出摘要、Token数、耗时、任务ID每次工具调用记录请求参数、响应摘要、错误码、耗时、任务ID。有了这些基础数据后面无论做问题排查还是成本分析都有据可查。没有这些数据再炫酷的监控面板也只是空架子。4. 对自己基础设施的三项拷问4.1 你的压测模型是按“对话”做的还是按“任务”做的大部分团队给Agent应用做性能测试时依然沿用传统API的做法准备一个接口用压测工具并发发请求看吞吐量和延迟。这在Agent场景里有一个致命缺陷每个内部步骤的“重量”差异极大。同样是用户请求有的任务一步就完成了有的任务要跑十几步每一步消耗的Token不同工具调用的延迟差异也很大。如果压测时没有按真实任务分布去构造流量测出来的数据基本没有参考价值。正确做法是准备一组模拟任务集比如“轻量查询类”占30%、“工具调用类”占40%、“长链路处理类”占30%按真实用户比例混合后再并发压测。压测时要重点关注三类指标推理服务的KV Cache显存峰值、任务状态存储的读写瓶颈、外部工具在不同并发下的响应延迟。我特别想提醒一点Agent对下游工具的调用是突发且带毛刺的整体QPS看着不高但某个瞬间可能几十个任务同时打同一个接口。如果下游服务没有预留这个缓冲一次流量高峰就能把它打挂。4.2 成本曲线原型阶段就开始记账成本问题最可怕的地方在于它不是突然暴露的而是温水煮青蛙。很多团队原型阶段用的是个人额度根本不会去看账单。等上生产后第一个月账单出来才发现每个Agent任务的实际成本是预估的好几倍。我建议从第一天就养成记账习惯每次任务结束把任务ID、模型调用次数、总Token数、平均步数、工具调用次数落库。每周拉一张成本曲线跟业务量放在一起看趋势。这样做有两个好处一是成本异动很快就能定位到具体环节二是当你要向团队解释“为什么Agent产品目前毛利为负”时手里有真实数据支撑。拿我自己的经验来说某个项目在优化之前单个任务平均消耗约28万Token优化三周之后降到了9万。如果没有早期记账根本不知道优化起了多大作用也说不清楚钱到底花在了哪里。4.3 权限沙箱被忽略的第四个代价题目说三个代价但作为一个过来人我还是想多说一个隐藏代价权限与安全。Agent是有行动能力的这意味着它不再只是“能读什么、能写什么”的被动组件而是一个能替用户执行操作的活动体。权限模型必须从“给用户开权限”扩展到“约束Agent的行动边界”。至少在基础设施层面做好三件事第一每个Agent运行时使用独立凭证避免Agent直接持有用户的全局权限第二所有工具调用通过统一网关网关里做黑白名单和速率限制对删除、批量写、付款这类高风险动作单独设置二次确认或拦截规则第三审计日志必须完整能还原出“谁在什么时间让Agent做了什么”。这个代价不像成本那样显性但一旦出了事故比如Agent误删了客户数据或者重复扣款损失会远超前三个代价的总和。5. 我在真实项目里的优化顺序和体会5.1 先保成功率再谈省钱经常有人问我能不能直接上一套复杂的成本优化方案把账单压下来我的建议很明确如果你的完整任务成功率还不到80%先别管成本把成功率提上去再说。原因非常现实成本优化手段比如上下文压缩、模型降级、缓存命中策略调整通常都会在某种程度上牺牲回答质量和推理余量。在链路本身不稳定的时候引入这些折损问题会变得更加复杂——一次失败到底是模型原因还是上下文压缩导致丢信息你根本分不清。先把重试机制、超时控制、幂等设计、任务轨迹日志这四件事做扎实等成功率稳定在90%以上再开始碰成本优化。5.2 一套从零搭建的基础设施改造顺序如果让我重新搭一套能扛住Agent生产级需求的基础设施我会严格按这个顺序走第一步任务编排与状态持久化。引入能暂停、恢复、重试的工作流能力让Agent任务可以被可靠调度。这是整个系统稳定性的地基。第二步统一工具网关。所有外部工具调用都走同一个网关由网关统一处理超时、限流、幂等、重试。这一步能极大降低外部依赖碎片化带来的混乱。第三步全链路观测。用task_id贯穿推理日志与工具调用日志每步记录Token数和耗时。有了数据后面所有优化才有依据。第四步成本与安全双控。给任务设Token预算上限超了触发降级或人工介入给工具调用设权限沙箱高危动作二次确认。第五步缓存与模型分级。等真实流量和成本数据都拿到之后再针对性地做这些优化而不是凭感觉提前铺开。提示如果现在的Agent还在PPT或者Demo阶段别急着把上面五步全做完。先把第二步和第三步行出来已经可以避开绝大多数生产事故。等业务量真正上来了再补齐剩下的部分。我做过几个Agent项目的体会是所谓“扛住”从来不是某一个组件单独扛而是成本、资源、可靠性三个维度同时设计的结果。没有捷径但有清晰顺序先让任务稳定跑完再让成本降下来最后让整个系统在压力下也不变形。每一步回头看看自己的基础设施处在哪一层自然就知道下一个该补什么了。 
长河君 · 2026/10/22 18:15:12 · 阅读 1.2k AI Agent生产环境三大代价：Token成本、上下文状态与工具链可靠性
最近一周我连着跟几个正在做Agent产品或者正准备转Agent方向的团队聊了同一个问题“你们的基础设施真的扛得住吗”得到的回答惊人地一致Demo阶段万物美好一进生产环境就露怯。有人是账单先爆了有人是并发一高推理服务就开始排队有人是线上任务三天两头卡在某个工具调用上。表面症状各不相同根子却都在同一个地方AI Agent对基础设施的要求跟传统LLM应用完全不是一个量级。这篇文章不聊Agent能做什么专门聊它背后真正要付出的三个代价Token成本、上下文与状态、工具链可靠性。读完你至少能算清楚自己的系统哪里有裂缝、下一步该补哪块。1. 先算一笔账Token成本如何从加法变成乘法1.1 一次最简单的Agent任务背后藏着多少次推理很多人对Agent成本的误解来自把Agent任务当成一次普通对话。传统Chatbot场景很简单用户输入一个问题模型输出一个回答计费等于输入Token加输出Token一次请求一锤子买卖上下文基本固定成本几乎可以线性预测。Agent完全不是这个逻辑。我拿一个最基础的场景举例用户让Agent查一下某城市未来三天的天气再根据天气情况判断适不适合安排户外跑步。整个任务大致会有这么几步第一步用户问题进入系统模型要进行规划判断自己该调用哪个工具。假设系统提示加用户问题一共约800 Token模型输出一段执行计划约200 Token。第二步系统按计划调用天气查询工具拿到一份结构化天气数据假设这份数据有1500 Token。第三步把这些内容拼回上下文再次请求模型让它判断这些数据够不够、要不要继续查空气质量、还是直接生成最终答案。注意此时输入已经不是800 Token了而是800加200加1500约2500 Token模型最终输出约500 Token的建议。两轮下来一次完整任务的实际消耗大约是五千多Token。你可能觉得这也没多少但请注意这只是一个工具调用一次的“最简单任务”。如果换成“帮我比价并下单一个商品”这种真实场景中间会包含搜索、打开商品页、读取评价、对比参数、确认库存、提交订单、确认结果少说七八次工具调用。每一次调用前面所有步骤产生的历史消息都会重新进入输入上下文。可以说Agent任务执行多久成本账单的闸门就开多久。1.2 为什么多轮决策会把成本推到10倍以上这里的关键机制在于现代Agent几乎都会把完整历史消息原封不动地塞回模型上下文让模型“记住”自己之前做了什么。工程上这样实现最省事但成本账非常难看。用一个近似公式感受一下假设一个Agent任务需要执行N次模型推理第i次推理的输入长度为L_i Token那么累计输入消耗等于所有L_i的总和。而L_i会随着历史累积不断变大。假设初始上下文有1万Token每执行一步工具返回平均3000 Token模型输出平均500 Token。到第10步时单次推理的输入已经膨胀到1万加9乘以3500约41500 Token。十步下来总输入Token不是4.15万而是所有步骤输入量的累加大约23万Token。对比传统Chatbot用户连续问10个问题每个问题输入1万Token总计就是10万Token且问题之间互不牵连每次计费干净利落。Agent同样是10步总消耗却是23万Token这里面还没算输出端的开销。我习惯把这种差别叫“加法变乘法”传统对话是问题数量乘以单次成本Agent是你每多走一步都要为之前所有步骤重新付一次费步骤越多放大效应越夸张。我在一个实际项目里测过同一类用户需求做成传统问答式应用单次请求平均消耗约1800 Token改成Agent形态后单次完整任务平均消耗超过18000 Token整整10倍的差距。这不是翻倍的问题是数量级的差异。很多团队在原型阶段用的是免费额度或者测试密钥完全没感觉一上生产所有请求按真实价格计费第一个月账单就能把人看懵。1.3 成本控制的第一板斧不是降模型而是砍上下文既然问题出在“历史重复计费”那么成本控制的核心方向就很明确让每一轮推理携带的上下文尽量短而不是盲目去换更便宜的模型。第一级手段是上下文摘要压缩。当对话历史超过某个阈值时把前面的内容用模型压缩成一段摘要每轮只带摘要加上最近的几步。代价是Agent可能丢失长程细节比如用户三小时前提过一个约束压缩之后就忘了。所以压缩策略要配合“关键信息显式提取”把用户约束、已完成步骤、当前结论单独拿出来作为结构化状态保存不能完全依赖模型从历史里找答案。第二级手段是语义缓存。传统缓存在Agent场景照样能用只是缓存粒度要从“最终答案”变成“子任务结果”。比如Agent经常查同一城市的天气五分钟内数据没变这个工具返回结果就可以直接命中缓存省掉一次真实调用。缓存省下的不只是工具调用费用更重要的是省掉后续推理把大量工具返回塞进上下文的开销。我在天气、汇率、库存这类更新频率不高的工具调用上做过统计缓存命中率能到20%到30%对整体成本的改善非常明显。第三级手段才是模型分级。简单任务用轻量模型跑复杂任务才派重量模型。很多团队一上来就全局用最强模型文档检索和资产分析都是同一个模型在处理非常浪费。Agent编排层应该支持按任务复杂度路由一步能搞定的查询走轻量模型需要工具编排和深度推理的才走重量模型。提示不要一上来就迷信“超长上下文”方案。几十万Token的上下文窗口会显著抬高单次推理成本并且让KV Cache的显存占用肉眼可见地飙升。超长上下文是少数特殊场景的备选工具不是用来解决Agent通用成本问题的万能药。2. 上下文与状态内存和存储被低估的账2.1 KV Cache的数学题一个8K上下文的请求吃掉多少显存第二个容易被忽视的代价是推理时的显存与内存压力。很多团队评估推理服务能不能扛住并发时只算了模型参数本身的显存占用完全漏掉了KV Cache。大模型在推理时每生成一个Token都要参考前面所有Token的Key和Value向量推理框架通常会把它们缓存起来避免重复计算这就是KV Cache。它的大小跟模型结构强相关跟序列长度基本呈线性关系。我这里给一个可以直接套用的估算公式KV Cache显存(字节) 约等于 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数前面的2对应Key和Value两组向量。假如你部署一个常见的7B参数量开源模型假设层数32注意力头数32每个注意力头维度128使用fp16精度也就是每个参数占2字节。当某个请求的上下文长度来到8192时seq_len 8192 layers 32 heads 32 head_dim 128 bytes_per_param 2 # fp16 kv_cache_bytes 2 * layers * heads * head_dim * seq_len * bytes_per_param print(f单请求KV Cache占用约: {kv_cache_bytes / 1024**3:.1f} GB) # 输出结果约 4.0 GB算下来一个请求还没开始生成输出就要为KV Cache预留约4GB显存。如果同一个推理服务上挂着32个并发任务且每个任务上下文都接近8KKV Cache总占用就超过128GB。再加上模型参数本身约14GB的显存一张80GB显存的卡实际能同时服务的Agent任务数远比想象中要低。Agent场景对KV Cache尤其不友好因为它的上下文只增不减任务执行期间KV Cache一直霸占着显存。传统Chatbot还能做成无状态用完就释放Agent任务一旦开始你就得为它的整个生命周期持续预付这部分显存成本。2.2 从无状态到有状态Agent服务架构的隐性转向KV Cache是显存层面的压力状态存储是架构层面的压力。传统LLM应用可以设计成无状态请求进来、模型算完、返回结果、一切清空。Agent应用做不到一个任务从开始到结束中间有海量需要跨步骤保留的状态。这些状态包括任务执行到第几步、已经完成哪些工具调用、工具返回的中间结果放在哪、当前处于规划阶段还是执行阶段、用户最初的需求和约束是什么。如果任务被调度到另一台实例上继续执行状态必须能够跨实例访问。很多团队第一次做Agent时很自然地用进程内变量把任务状态存了下来。原型阶段没问题一旦部署成多实例或者进程被滚动重启所有正在跑的任务会静默丢失。我听说过一个真实的线上事故某Agent平台发版时重启了服务所有用户的进行中任务全部清零用户以为自己的申请已经提交成功实际上后端什么都没发生。这就是典型的把无状态思维硬套在有状态系统上。正确做法是引入持久化任务存储比如把任务状态快照写入数据库或KV存储每次状态变更都落一次盘任务任何时候都可以从最近快照恢复。这个改造不复杂但它决定了你的Agent系统配不配得上“生产可用”这四个字。2.3 崩溃恢复不是重跑一遍这么简单Agent与传统批处理任务还有一个关键差异它的每一步动作都可能产生外部副作用。某一步调用了外部系统的“提交申请”接口然后进程在确认结果之前崩溃了。任务恢复时你没法简单地从上一步重跑因为外部系统那边可能已经真的提交了一份申请。这时候你必须先判断清楚那次提交到底有没有生效。这就是幂等和查询式恢复的课题。最稳妥的做法是Agent每一次调用外部工具都带上全局唯一的执行ID外部系统配合做幂等同时提供查询接口Agent恢复时可以查询“以ID为X的那次操作是否已经生效”。听上去像在做分布式事务本质上确实是。如果外部系统不配合幂等备选方案是“执行前确认加执行后对账”。执行前明确告诉外部系统这是一个Agent自动操作执行后主动查询结果来消除不确定性。这套机制在涉及支付、订单、消息发送这类场景时尤其重要。很多团队等到重复下单了才回头想这个问题不如架构设计阶段就定好规则。3. 工具调用链越长成功率跌落越快3.1 99%的接口成功率放在Agent场景里根本不够第三个代价关乎稳定性。传统应用里99%的接口成功率已经是非常优秀的成绩但放到Agent场景里这个数字根本不够看。原因很简单一个Agent任务往往要串行调用多个工具。如果每个工具的成功率都是99%一个需要10次工具调用的任务整体成功率只有0.99的10次方约90.4%。这意味着每10个任务就有1个失败对生产系统来说已经很糟糕了。更现实的是工具调用之前还有模型推理这一步而模型本身也会犯错输出格式非法、幻觉参数、选错工具。把模型这环的成功率也按95%估算10步任务的整体成功率就是0.95的10次方只有约60%。60%的成功率意味着什么用户每发起两次任务差不多就有一次不能顺利完成。这种体验积累起来用户很快就会判定“这个AI根本不可用”。我见过不少团队在Demo阶段只演示成功路径对失败路径毫无感知一进生产环境失败率立刻暴露技术团队被迫长期救火一边是用户投诉一边是日志里各种奇怪的半途失败。3.2 模型与工具故障交织最难排查的一类问题传统服务的报错链路是清晰的调用支付网关返回500那就是网关挂了查网关日志就行。Agent的报错链路是模糊的用户说“帮我处理一下报销申请”Agent查询审批系统系统返回“状态未知”模型把这个结果理解成“需要重新提交”于是真的调用了提交接口最后用户看到的是两份重复的报销单。这类问题的根因不在任何一次单独的工具调用而在于模型误读了工具返回。你查工具服务日志会发现它一切正常查模型推理日志会发现模型也“严格按照指令执行了”。每一步单独看都没毛病拼在一起就出错。排查这种问题必须看完整的决策轨迹模型每一步看到了什么、怎么想的、为什么选这个动作、工具返回了什么、模型又是怎么理解这个返回的。所以Agent对日志格式的要求比传统应用高得多。普通错误日志只在失败时打印Agent场景需要的是成功时也打印完整轨迹并且所有步骤都带上同一个任务ID。没有这个基础遇到这类问题基本只能靠猜排查效率极低。3.3 可观测性从链路追踪到决策路径溯源既然决策轨迹这么重要落地时该看哪些指标我这里列一张表基本覆盖了Agent生产环境最该盯住的六个核心指标指标说明关注点任务成功率完整Agent任务中成功完成的比例低于90%就要查工具配置或模型选型平均完成步数单个任务的平均推理加工具调用次数波动过大通常说明模型在绕圈每任务Token消耗单个任务的平均成本消耗观察趋势涨得最快的环节优先优化工具调用失败率各外部工具独立统计的失败率快速识别最脆弱的下游依赖思考-行动循环次数模型重复规划某个目标的次数出现峰值时可能是在死循环烧钱恢复重试次数任务从检查点恢复的频率太高说明上游基础设施不稳定落地时不需要一上来就搞花哨的可视化大屏。先把日志规范性做好每次模型调用记录输入摘要、输出摘要、Token数、耗时、任务ID每次工具调用记录请求参数、响应摘要、错误码、耗时、任务ID。有了这些基础数据后面无论做问题排查还是成本分析都有据可查。没有这些数据再炫酷的监控面板也只是空架子。4. 对自己基础设施的三项拷问4.1 你的压测模型是按“对话”做的还是按“任务”做的大部分团队给Agent应用做性能测试时依然沿用传统API的做法准备一个接口用压测工具并发发请求看吞吐量和延迟。这在Agent场景里有一个致命缺陷每个内部步骤的“重量”差异极大。同样是用户请求有的任务一步就完成了有的任务要跑十几步每一步消耗的Token不同工具调用的延迟差异也很大。如果压测时没有按真实任务分布去构造流量测出来的数据基本没有参考价值。正确做法是准备一组模拟任务集比如“轻量查询类”占30%、“工具调用类”占40%、“长链路处理类”占30%按真实用户比例混合后再并发压测。压测时要重点关注三类指标推理服务的KV Cache显存峰值、任务状态存储的读写瓶颈、外部工具在不同并发下的响应延迟。我特别想提醒一点Agent对下游工具的调用是突发且带毛刺的整体QPS看着不高但某个瞬间可能几十个任务同时打同一个接口。如果下游服务没有预留这个缓冲一次流量高峰就能把它打挂。4.2 成本曲线原型阶段就开始记账成本问题最可怕的地方在于它不是突然暴露的而是温水煮青蛙。很多团队原型阶段用的是个人额度根本不会去看账单。等上生产后第一个月账单出来才发现每个Agent任务的实际成本是预估的好几倍。我建议从第一天就养成记账习惯每次任务结束把任务ID、模型调用次数、总Token数、平均步数、工具调用次数落库。每周拉一张成本曲线跟业务量放在一起看趋势。这样做有两个好处一是成本异动很快就能定位到具体环节二是当你要向团队解释“为什么Agent产品目前毛利为负”时手里有真实数据支撑。拿我自己的经验来说某个项目在优化之前单个任务平均消耗约28万Token优化三周之后降到了9万。如果没有早期记账根本不知道优化起了多大作用也说不清楚钱到底花在了哪里。4.3 权限沙箱被忽略的第四个代价题目说三个代价但作为一个过来人我还是想多说一个隐藏代价权限与安全。Agent是有行动能力的这意味着它不再只是“能读什么、能写什么”的被动组件而是一个能替用户执行操作的活动体。权限模型必须从“给用户开权限”扩展到“约束Agent的行动边界”。至少在基础设施层面做好三件事第一每个Agent运行时使用独立凭证避免Agent直接持有用户的全局权限第二所有工具调用通过统一网关网关里做黑白名单和速率限制对删除、批量写、付款这类高风险动作单独设置二次确认或拦截规则第三审计日志必须完整能还原出“谁在什么时间让Agent做了什么”。这个代价不像成本那样显性但一旦出了事故比如Agent误删了客户数据或者重复扣款损失会远超前三个代价的总和。5. 我在真实项目里的优化顺序和体会5.1 先保成功率再谈省钱经常有人问我能不能直接上一套复杂的成本优化方案把账单压下来我的建议很明确如果你的完整任务成功率还不到80%先别管成本把成功率提上去再说。原因非常现实成本优化手段比如上下文压缩、模型降级、缓存命中策略调整通常都会在某种程度上牺牲回答质量和推理余量。在链路本身不稳定的时候引入这些折损问题会变得更加复杂——一次失败到底是模型原因还是上下文压缩导致丢信息你根本分不清。先把重试机制、超时控制、幂等设计、任务轨迹日志这四件事做扎实等成功率稳定在90%以上再开始碰成本优化。5.2 一套从零搭建的基础设施改造顺序如果让我重新搭一套能扛住Agent生产级需求的基础设施我会严格按这个顺序走第一步任务编排与状态持久化。引入能暂停、恢复、重试的工作流能力让Agent任务可以被可靠调度。这是整个系统稳定性的地基。第二步统一工具网关。所有外部工具调用都走同一个网关由网关统一处理超时、限流、幂等、重试。这一步能极大降低外部依赖碎片化带来的混乱。第三步全链路观测。用task_id贯穿推理日志与工具调用日志每步记录Token数和耗时。有了数据后面所有优化才有依据。第四步成本与安全双控。给任务设Token预算上限超了触发降级或人工介入给工具调用设权限沙箱高危动作二次确认。第五步缓存与模型分级。等真实流量和成本数据都拿到之后再针对性地做这些优化而不是凭感觉提前铺开。提示如果现在的Agent还在PPT或者Demo阶段别急着把上面五步全做完。先把第二步和第三步行出来已经可以避开绝大多数生产事故。等业务量真正上来了再补齐剩下的部分。我做过几个Agent项目的体会是所谓“扛住”从来不是某一个组件单独扛而是成本、资源、可靠性三个维度同时设计的结果。没有捷径但有清晰顺序先让任务稳定跑完再让成本降下来最后让整个系统在压力下也不变形。每一步回头看看自己的基础设施处在哪一层自然就知道下一个该补什么了。