该干的活儿干完了、Demo也跑通了Agent 看起来什么都会可一旦丢到生产环境里问题就像雨后春笋一样往外冒反应慢、账单飞涨、时不时还卡死报错。很多人把这归咎于“模型不行”但实际上大部分生产事故和巨额成本都是调优环节欠了债。这篇是 Agent 进阶实战系列的第九课我结合自己带模拟项目 X 的经验把性能、成本、稳定性这三座大山怎么一个一个啃下来的过程完整拆开讲一遍。这篇文章适合谁看自己搭过 Agent 原型、准备上生产或者上线后发现性能和成本失控的同学。我会把延迟时间线的拆解方法、账单的构成逻辑、超时重试熔断降级这一整套稳定性手段以及实际调优前后的数据对比全部掏出来尽量少讲虚的多给可以直接抄作业的方案。1. 从Demo到生产Agent为什么突然“不会干活”了很多 Agent 项目死在从原型到生产的这一步不是功能没做出来而是到了生产环境突然变得又慢又贵又不稳。我见过不止一个团队在测试环境里对着 Agent 猛夸“真聪明”结果一接真实流量就露馅了。这个阶段暴露的问题往往不是模型本身的能力问题而是整个系统设计根本没有为生产环境做过准备。1.1 原型阶段和生产阶段的本质差异原型阶段里Agent 面对的是少量请求、干净的输入、充足的超时容忍度你甚至可以接受它思考 20 秒再回答。模型偶尔抽风你点一下重跑就完事了反正也没人投诉。但生产环境完全是另一套逻辑并发一上来每个请求都要求秒级响应输入五花八门用户可能随时打断、重复提交、提一些你没预料到的需求链路中任何一环抖动都会顺着 Agent 的多轮调用链成倍放大。我自己在模拟项目 X 里第一次压测时场景是这样的50 个并发请求每个请求要完成意图识别、工具查询、结果归纳三个大步骤平均一个请求要触发 4 到 6 次模型调用。压测一跑平均响应时间直接飙到 18 秒最差请求到了 40 多秒而且失败率接近 7%。当时第一反应是“模型太慢了”但后来一拆解发现模型推理只占了不到一半时间剩下的都消耗在工具调用等待、上下文重复处理和重试放大上。这就是生产级调优要解决的核心问题——把时间线和调用链拆到每一环找到真正的瓶颈而不是笼统地甩锅给模型。1.2 调优的三个核心指标性能、成本、稳定性如何互相牵制性能、成本、稳定性这三件事表面上各自独立实际上强耦合。你想让响应变快最简单的办法是缩短生成长度、减小上下文但上下文一减Agent 可能因为信息不足而频繁重试稳定性反而变差成本也未必降下来。你想省钱把所有请求都切到小模型结果复杂任务小模型理解不了返工率飙升最终成本和延迟双双上涨。你想稳那就疯狂重试、每个请求都走最贵最全的链路结果账单根本兜不住。所以生产级调优的本质不是做一个单项最优而是找到三者的平衡点。我的做法是先给每个指标定一个可量化的红线性能上P95 响应时间不超过 5 秒成本上单次会话的平均模型调用成本控制在某个固定值以内稳定性上月度成功率不低于 99%。有了红线再逐项调优每动一个参数都要同时观察三个指标避免“头痛医头脚痛医脚”。2. 性能攻坚延迟都花在哪了性能调优的第一步永远是拆时间线而不是盲目换模型。一次完整的 Agent 请求从用户按下发送键到看到回复中间包含网络传输、模型推理、工具调用、上下文处理、结果解析等多个环节。只有把每个环节的真实耗时拿到手才知道该往哪儿使劲。2.1 一次Agent请求的完整时间线拆解我在模拟项目 X 中给 Agent 接入了全链路追踪为每个请求生成一个 trace ID每一轮模型调用、每一次工具请求都打上时间戳。拆解典型请求后发现总耗时 8.2 秒分布大概是——意图识别模型调用 1.8 秒工具查询查库存、查价格耗时 1.5 秒第二轮模型调用基于工具结果生成回复耗时 2.6 秒上下文序列化和传输以及网络开销约 1.3 秒其余 1 秒分散在排队、解析、日志等环节。这里有个特别值得注意的现象第二轮模型调用比第一轮慢很多。原因很简单第二轮要把第一轮的对话历史、工具返回结果全部拼进上下文输入 Token 数暴涨首 Token 延迟和生成时间都跟着涨。这几乎是所有 Agent 性能问题的典型病灶——上下文越滚越大模型处理越慢成本越高。针对这个时间线性价比最高的优化动作有两个第一是用更轻量的小模型去做意图识别把大模型的资源留给真正需要复杂推理的环节第二是严格控制进入上下文的工具结果只保留摘要化的关键字段而不是把整个 JSON 原封不动塞进去。2.2 推理层的取舍模型规模和结构化输出模型选择是性能优化的重头戏。原型的做法往往是一个大模型通吃所有环节好处是省事坏处是贵且慢。生产级调优要做的第一件事就是把 Agent 里不同类型的任务拆出来分别匹配不同规模的模型。以我的经验Agent 链路里的任务大致可以分成三类意图识别和信息抽取这类任务逻辑简单但频率极高适合用小模型复杂推理和最终答案生成需要强理解能力必须上大模型介于两者之间的比如多步规划、工具选择可以根据业务复杂度选择中档模型。我在模拟项目 X 里做了一次切换实验把意图识别从大模型切到小模型后单轮调用成本下降约 70%延迟下降 40%准确率几乎没有变化因为意图识别的本质是分类任务并不需要太强的生成能力。除了模型大小输出格式约束也很关键。很多 Agent 慢是因为模型生成了一堆废话或者格式不规范的 JSON导致下游解析重试。用结构化输出能力把模型的输出限制成严格的 JSON Schema看起来只是“规范了格式”实际上它同时减少了生成 Token 数、降低了解析失败率是性能和稳定性一箭双雕的手段。2.3 工具调用环节的常见性能陷阱工具调用是 Agent 生产化中最容易被低估的性能黑洞。表面上看一次 HTTP 请求就是几十毫秒的事但在 Agent 链路里工具调用的耗时往往会被放大好几倍。第一个陷阱是我前面提到的重复调用Agent 在上下文丢失或规划出错时会对同一个工具发起多次相同请求每次都带着完整的往返延迟。我在实际项目中踩过一个很典型的坑某查询工具对相同的关键词返回结果基本不变但 Agent 因为上下文太长导致语义漂移在一个会话里查了 5 次库存接口白白多花了 1.2 秒和相应 Token 成本。解决这个问题需要引入对工具调用的去重和缓存——相同的工具和参数组合在有效期内直接返回缓存结果同时通过 Prompt 明确告知 Agent“这个信息你已经查过了不要重复查”。第二个陷阱是串行调用。有些 Agent 框架默认会按顺序执行多个工具调用即使这些调用之间完全没有依赖关系。比如既要查用户信息又要查商品库存这两件事完全可以并行但默认实现是排队执行的延迟直接翻倍。正确的做法是在调用层做并发调度把没有依赖关系的工具调用用并发方式发出去整体耗时能砍掉将近一半。2.4 上下文压缩与记忆管理对响应速度的影响上下文管理是 Agent 性能和后续成本之间的最大公约数。对话轮次一多上下文里塞满了几百轮的历史消息、工具调用记录、中间推理过程每次模型调用都要重新处理这一大坨 Token延迟和成本都线性上涨。我见过最极端的案例一个长会话的中期请求光输入 Token 就接近 3 万首 Token 延迟超过 6 秒。生产级方案一般分三层。第一层是硬截断超过窗口上限的策略可以是“丢最旧的消息”但这个粗暴策略容易把关键信息丢掉第二层是摘要压缩用一次小模型调用把中间过程压缩成摘要保留任务目标和最新状态第三层是关键信息抽取把用户偏好、业务约束、工具返回的有效数据抽出来放进固定结构的记忆区块长期驻留上下文。我在实践中倾向于摘要加抽键信息的组合既保留语义连贯性又控制 Token 总量。这里分享一个实操技巧压缩动作不要放在每次请求前做而是放在上一轮响应结束时做。也就是说每次 Agent 生成完回复顺手判断上下文是否超过阈值如果超过就立刻压缩而不是等到下一次请求来的时候再临时处理。这样可以避免压缩本身变成请求响应时间的一部分让延迟曲线更稳定。3. 成本治理别让账单吃掉收益Agent 的成本问题比普通 API 调用要隐蔽得多。普通应用调一次接口就一次钱Agent 一次用户请求可能触发模型多次调用每次调用还带着越来越大的上下文。很多人只盯着单次调用的单价却没算清楚一次完整会话到底消耗了多少 Token这才是账单失控的根本原因。3.1 成本结构拆解Token消耗的大头在哪我把模拟项目 X 的单次完整会话成本拆开分析发现一个扎心的事实输入 Token 占了总消耗的 70% 以上而输出 Token 只占 20% 多还有少量是各种重试带来的额外消耗。这个结构说明单纯限制模型输出长度只能解决一小部分成本问题真正的大头是喂给模型的输入。输入 Token 的构成也很清晰每次模型调用都会带上系统 Prompt、历史对话、工具返回结果。其中系统 Prompt 虽然是必要开销但长期不维护的话会越写越长历史对话和工具结果则是大头只增不减。我给模拟项目 X 做成本治理时第一步就是把所有环节的 Token 消耗按来源打点统计一周后拉出账单按输入 Token 量排序当场就知道该从哪个环节动刀了。用表格说明治理前后的 Token 构成变化会更直观环节治理前占比治理后占比治理手段系统 Prompt12%8%精简指令、合并重复规则历史对话38%18%摘要压缩、窗口截断工具返回结果30%12%字段白名单、结果摘要输出生成20%25%结构化输出限制长度重试损耗5%3%超时优化、熔断降级3.2 Prompt瘦身与信息检索策略Prompt 瘦身是成本治理里收益最快的一项但也是最容易被忽略的。很多系统的系统 Prompt 在迭代过程中不断追加规则从最初的 500 字膨胀到 2000 字里面还夹杂着大量自相矛盾的旧规则。实际上大模型对重复、冲突的指令并不会更听话反而会因为上下文被占满而牺牲有效信息。我做过一个实验把模拟项目 X 的系统 Prompt 从 1800 字精简到 900 字意图识别准确率反而提升了 0.8 个百分点。原因是压缩掉了大量重复强调和可被拆解的冗余背景模型更专注于核心指令。所以成本治理的第一板斧就是给 Prompt 做一次“断舍离”能删的删、能合并的合并、能用结构化字段表达的不要用长句描述。另一块大头是工具结果的投喂策略。早期实现里为了让 Agent “理解得更全面”我们把工具返回的完整 JSON 直接塞进上下文结果一次查询可能带进来几百行无关字段。优化方案是给每个工具定义结果摘要器只保留模型决策需要的字段。比如查库存的工具返回结果里只有商品 ID、可用数量、预计补货时间这三个字段需要进入上下文其余的高维字段一律丢弃。3.3 缓存设计从结果缓存到语义缓存缓存是成本治理的核心手段但需要分层设计。我在工作中把缓存分成两层结果缓存和语义缓存。结果缓存的思路很简单对于相同输入的模型调用在 TTL 时间内直接返回上次的结果不再发起真实模型请求。这适合那种用户反复查询同一问题的场景。我在模拟项目 X 里给“常见问题解答”类对话加了一层 TTL 为 30 分钟的结果缓存这部分对话的模型调用量直接下降 40%。语义缓存比结果缓存高级一些适合用户用不同说法问同一个问题的场景。它会先对用户输入做 embedding 向量化然后在缓存里做相似度匹配相似度超过阈值就直接用缓存结果。语义缓存的难点在于阈值的把握阈值设得太高命中率低设得太低缓存结果可能答非所问引发正确性风险。我的经验是先从相似度 0.92 起步根据线上反馈逐步下调同时限定只对“事实型问答”启用语义缓存对需要个性化或时效性强的请求一律绕过缓存。3.4 模型分层路由把贵模型用在刀刃上全链路用同一个模型是成本失控的另一个常见原因。模型分层路由的核心思想是让请求在进入模型前先被分类不同分类分配到不同规格的模型上。这个分类可以靠规则完成也可以靠一个小模型完成。我在模拟项目 X 里采用的方案是先定义一个“路由小模型”它的任务只是判断当前请求的复杂度等级——简单、中等、困难。然后分别映射到不同模型简单请求走轻量模型中等请求走标准模型只有困难请求多步推理、长文档理解才走最强模型。实测下来大约 60% 的请求被划分为简单或中等这部分请求的成本仅为原来大模型方案的 30% 左右而 P95 延迟也显著下降。至于“为什么敢用小模型做路由”因为路由判断本身是一个分类任务它不需要生成复杂内容只需要给请求打一个标签。这种任务甚至可以被规则初步替代如果请求长度短、关键词明确直接判为简单。但规则覆盖不了灵活表达所以保留小模型兜底整体性价比最高。4. 稳定性攻坚生产环境最怕什么稳定性是 Agent 生产级调优里难度最高的一环。传统服务出故障通常是确定性的报错信息能指出具体位置Agent 出故障往往是概率性的——模型偶尔抽风、工具偶尔超时、上下文偶尔冲突每个“偶尔”单独看都能接受但叠加在每周几万次请求上就是实打实的线上事故。4.1 超时与重试你的Agent为什么卡死Agent 卡死最常见的原因是超时设置不合理。我给模拟项目 X 做过一次故障排查某个请求耗时超过 60 秒整个用户体验就是“转圈圈”。查下来发现问题出在工具调用超时设成了 30 秒而工具访问的数据库服务在极端情况下响应要 40 秒。模型调用那边超时设得更大两次重试叠加总耗时直接爆炸。这里的关键教训有三个。第一链路里的每个节点都要设置独立的超时时间不能只设总超时。模型调用、工具调用、内部处理分别设置上限任何一个节点超时都立刻终止不要傻等。第二超时时间的取值要基于真实 P99 数据加合理冗余而不是拍脑袋。我用每个节点的 P99 延迟作为基准再上浮 50% 作为超时阈值既保证正常情况不会被误杀又能兜住异常抖动。第三重试不是无限重试必须严格控制总次数和总耗时预算。我给模拟项目 X 的模型调用设定了最多 2 次重试、每次重试使用指数退避加随机抖动整个链路的整体超时预算控制在 8 秒以内。4.2 降级策略模型不可用时的兜底方案降级策略是 Agent 稳定性的最后一道防线。很多人忽视这层总觉得“模型服务很稳定不会出问题”但实际上模型服务商也会限流、也会故障而且一旦出问题影响是全局性的。我在实际项目中遇到过模型服务连续抖动半小时的情况如果当时没有降级方案那半小时里的所有用户请求都会失败。降级方案要分场景设计。第一级降级是模型层面的兜底当主模型服务不可用或响应超时时自动把请求切到备用的模型服务。这里有个容易被忽略的点备用模型不一定要和主模型同规格因为在故障场景下用户的诉求是“有响应”而不是“完美答案”。所以我设置了“降到低规格模型 简化任务”的组合方案比如把多步推理改成单步问答至少能保持基础服务可用。第二级降级是业务层面的兜底当所有模型服务都不可用时直接用规则引擎或预设模板回复。比如客服 Agent 在极端场景下就直接回复“系统维护中请稍后再试”同时在后台记录工单等系统恢复后再处理。这种方案虽然生硬但保证了用户的每一次请求都有明确反馈不会出现无限等待或静默失败。4.3 幂等性与并发控制防止重复执行事故Agent 和普通 API 最大的不同在于它有“行动能力”——会真实地调用工具去完成业务操作。这就带来一个严肃问题如果用户的请求因为超时被重试Agent 会不会把同一笔转账转两次把同一个工单建两遍幂等性是解决这个问题的核心。我在模拟项目 X 里给所有写操作工具都加了幂等键每个请求在进入 Agent 时生成一个全局唯一的 request ID这个 ID 会透传到所有工具调用。工具执行前先检查这个 request ID 是否已经处理过处理过的直接返回上次结果不再重复执行。这个方案看起来简单但落地时有个细节必须注意幂等键的检查必须是原子的不能两个并发请求同时通过检查然后都执行写操作。实际的实现是先在存储里抢占幂等键记录抢到才执行抢不到就直接返回等待或之前的结果。并发控制是另一个容易翻车的地方。Agent 应用经常出现短时间大量请求涌入如果不控制并发所有请求同时打到模型服务后果要么是被限流要么是核心资源被冲垮。我用信号量做了一层并发上限比如模型并发调用数不超过 5工具并发调用数不超过 10超出的请求进入队列等待。这层控制让系统在流量突刺时依然能保持稳定的吞吐而不是彻底瘫掉。4.4 可观测性日志、追踪与告警的落地可观测性贯穿了性能、成本、稳定性三项调优的始终。没有可观测性你只能靠用户投诉被动发现问题有了可观测性你可以在问题影响用户之前就把它拦住。Agent 应用的可观测性比普通 Web 服务要复杂因为一次请求里涉及多次模型调用、多个工具调用、内部状态变化必须引入 trace 的概念才能看清链路全貌。我的落地经验是三层结构。第一层是结构化日志每个环节都输出包含 trace ID、耗时、Token 数、模型名、调用的工具名等字段的 JSON 日志。第二层是全链路追踪用 trace 把所有模型调用和工具调用串起来在可视化界面里能看到每一步的时间线和上下游关系。第三层是核心指标监控包括响应时间P50/P95/P99、成功率、Token 消耗速率、单次会话成本、工具调用失败率。基本的告警规则是P95 延迟超过阈值触发警告成功率低于 99% 触发紧急告警单次会话语义缓存未命中率异常也记录下来。这里有个经验之谈告警别贪多宁少勿滥。一开始我恨不得每个指标都设一条告警结果告警风暴一来真正的故障信息被淹没在大量无效告警中。后来收敛到五条核心告警P95 延迟、成功率、模型调用超时率、工具调用失败率、每分钟 Token 消耗异常增长。规则简单但每条都能击中要害。5. 一次真实调优案例的完整复盘理论讲再多不如看一次完整实战。这个案例来自模拟项目 X是一个企业内部知识问答 Agent前期功能开发完成后一进生产环境就问题爆发。我用这个案例把前面所有方法串一遍也让读者看看调优顺序和优先级到底该怎么排。5.1 模拟项目X的初始表现延迟8秒、成本超标、偶发失败项目 X 的 POC 版本表现良好因为测试数据干净、并发低、上下文短。一上生产真实流量带来的脏数据、长对话、高并发把问题全部暴露出来。上线第一周的监控数据是P95 延迟 8.2 秒远高于 5 秒目标单次会话平均模型成本比预估高 2.3 倍成功率 98.2%看似不低但那个 1.8% 的失败集中在真实用户的高价值操作上每周都要处理好几起投诉。针对这三个数据我们先判断优先级稳定性问题虽然只影响 1.8% 的请求但是一旦涉及工具写操作失败会造成严重的用户信任问题所以第一优先级是解决成功率和失败超时其次是性能因为 8 秒的延迟已经让用户明显感知到“卡”最后是成本因为项目还在验证期成本超支会直接威胁项目存续。5.2 逐项优化的顺序与方法我们按照“先止血、再提速、后减肥”的顺序逐项处理。止血阶段只做三件事。第一给所有外部调用设置独立超时和严格重试预算消除了请求卡死问题。第二给所有写操作工具加上幂等键消除了重复执行风险。第三建立降级通道模型服务异常时自动切备用模型并简化任务。这三件事做完成功率从 98.2% 提升到 99.5%耗时一周。提速阶段做两件事。第一把意图识别和复杂度路由从大模型切到小模型消除了大部分低频任务的延迟。第二对工具结果做字段白名单和摘要化处理大幅压缩第二轮模型调用输入 TokenP95 延迟从 8.2 秒降到 4.1 秒直接达成 5 秒目标。减肥阶段做两件事。第一引入语义缓存层拦截高频重复问题。第二对长会话上下文做“对话摘要 关键信息持久化”的压缩单次会话成本从超预算 2.3 倍降到预算内的 85%。三周调优结束后三项核心指标全部达标且没有出现新的副作用。5.3 调优后的收益数据与遗留问题调优后的完整数据对比是这样的指标调优前调优后P95 响应时间8.2 秒3.6 秒成功率98.2%99.6%单次会话平均成本预算的 230%预算的 85%模型调用次数/会话5.2 次3.4 次语义缓存命中率无缓存31%数据很好看但调优并没有“完全结束”。遗留问题包括语义缓存对某些相似表达会误命中偶尔出现回答不够精准的情况我们通过定期核对缓存命中内容的正确率来控制小模型路由在大促期间出现过分类漂移后来用规则和临时降级兜住了。这也印证了一个观点调优不是一次性的它是随着线上数据持续修正的迭代过程。6. 持续调优机制好的Agent是“养”出来的很多团队把调优当成上线前的一次性动作上线后就不管了这是大忌。Agent 系统的特殊性在于它会随着用户交互不断积累新的输入模式、新的工具使用场景甚至模型本身也在不断更新。一个上线时调到最优的 Agent三个月后可能因为用户使用习惯的变化而重新变差。6.1 基于线上日志的回归测试持续调优的第一件事是建立基于线上日志的回归测试机制。每次改动 Prompt、调整模型参数或修改工具逻辑之前先跑一遍回归测试。方法是从线上日志里定期抽取一批有代表性的历史请求把它们作为固定测试集。每次改动后用改动后的 Agent 跑一遍这批请求记录关键指标成功率、正确性、延迟是否出现回退。这个机制看起来简单但能挡住大量隐性回归。我在某次优化中把工具结果的截断策略改动了一下单看指标全都符合预期结果回归测试发现某些复杂查询的正确率下滑了两个百分点顺着这个线索排查才发现截断策略把一些多值字段切坏了。6.2 评估集建设与线上反馈闭环回归测试的效果取决于测试集质量所以评估集建设也必须是持续行为。我习惯把评估集分成两类通用基础集和线上反馈集。通用基础集覆盖各业务方向的典型场景保持稳定用于横向对比每次改动的效果线上反馈集则每周更新从真实用户反馈中挑选那些“Agent 答错了但用户没投诉”或者“用户明显表达了不满”的会话补充到评估集里。把用户不满的会话中做得不好的请求持续全量评估可以帮助追踪 Agent 能力的真实边际。反馈闭环的另一层是要在线上系统里埋一个“用户反馈”入口比如让用户在回答下方点“有用/没用”。这些标签要和 trace ID 绑定这样每次用户点“没用”时你都能拉出这次回答涉及的完整链路定位问题发生的具体环节而不是笼统地认为“模型不行”。6.3 灰度发布与配置化开关持续调优的最后一个保障是灰度发布机制。Agent 系统改动不直接全量上线先把改动部署在一小部分流量上观察数据再逐步放大比例。我在实践中把 Agent 的可调参数模型选择、Prompt 模板、缓存 TTL、超时阈值全部做成配置中心里的可动态变更项每次改动都通过配置发布而不是重新发版。这让灰度发布变成了一个纯配置操作先在 5% 流量上启用新配置观察 30 分钟到 1 小时成功率和延迟没有异常再逐步提升到 50%、100%。如果指标异常随时一键回滚秒级生效。灰度发布也有个容易被忽略的点不仅是新功能的改动要灰度Prompt 的微调也需要。不少人觉得“改两个字没事吧”结果就因为改了 Prompt 里的一处措辞导致模型输出风格大变。在我的团队里任何对 Prompt、模型参数、工具逻辑的改动都要走灰度流程这是保证生产系统稳定性的底线。最后聊一点个人体会——Agent 生产级调优和传统后端调优最大的不同在于它面对的是一个概率系统而不是确定性系统。传统系统调优讲究“找到问题、修复问题、问题消失”Agent 调优更像是“寻找最坏情况、降低最坏情况的概率、给最坏情况准备预案”。性能、成本、稳定性三者的平衡没有一劳永逸的配置只有持续观察、持续调整、对线上数据保持敬畏的日常功夫。希望这篇文章能把你在生产环境里踩过的坑和即将踩的坑都提前摆到桌面上来。
该干的活儿干完了、Demo也跑通了Agent 看起来什么都会可一旦丢到生产环境里问题就像雨后春笋一样往外冒反应慢、账单飞涨、时不时还卡死报错。很多人把这归咎于“模型不行”但实际上大部分生产事故和巨额成本都是调优环节欠了债。这篇是 Agent 进阶实战系列的第九课我结合自己带模拟项目 X 的经验把性能、成本、稳定性这三座大山怎么一个一个啃下来的过程完整拆开讲一遍。这篇文章适合谁看自己搭过 Agent 原型、准备上生产或者上线后发现性能和成本失控的同学。我会把延迟时间线的拆解方法、账单的构成逻辑、超时重试熔断降级这一整套稳定性手段以及实际调优前后的数据对比全部掏出来尽量少讲虚的多给可以直接抄作业的方案。1. 从Demo到生产Agent为什么突然“不会干活”了很多 Agent 项目死在从原型到生产的这一步不是功能没做出来而是到了生产环境突然变得又慢又贵又不稳。我见过不止一个团队在测试环境里对着 Agent 猛夸“真聪明”结果一接真实流量就露馅了。这个阶段暴露的问题往往不是模型本身的能力问题而是整个系统设计根本没有为生产环境做过准备。1.1 原型阶段和生产阶段的本质差异原型阶段里Agent 面对的是少量请求、干净的输入、充足的超时容忍度你甚至可以接受它思考 20 秒再回答。模型偶尔抽风你点一下重跑就完事了反正也没人投诉。但生产环境完全是另一套逻辑并发一上来每个请求都要求秒级响应输入五花八门用户可能随时打断、重复提交、提一些你没预料到的需求链路中任何一环抖动都会顺着 Agent 的多轮调用链成倍放大。我自己在模拟项目 X 里第一次压测时场景是这样的50 个并发请求每个请求要完成意图识别、工具查询、结果归纳三个大步骤平均一个请求要触发 4 到 6 次模型调用。压测一跑平均响应时间直接飙到 18 秒最差请求到了 40 多秒而且失败率接近 7%。当时第一反应是“模型太慢了”但后来一拆解发现模型推理只占了不到一半时间剩下的都消耗在工具调用等待、上下文重复处理和重试放大上。这就是生产级调优要解决的核心问题——把时间线和调用链拆到每一环找到真正的瓶颈而不是笼统地甩锅给模型。1.2 调优的三个核心指标性能、成本、稳定性如何互相牵制性能、成本、稳定性这三件事表面上各自独立实际上强耦合。你想让响应变快最简单的办法是缩短生成长度、减小上下文但上下文一减Agent 可能因为信息不足而频繁重试稳定性反而变差成本也未必降下来。你想省钱把所有请求都切到小模型结果复杂任务小模型理解不了返工率飙升最终成本和延迟双双上涨。你想稳那就疯狂重试、每个请求都走最贵最全的链路结果账单根本兜不住。所以生产级调优的本质不是做一个单项最优而是找到三者的平衡点。我的做法是先给每个指标定一个可量化的红线性能上P95 响应时间不超过 5 秒成本上单次会话的平均模型调用成本控制在某个固定值以内稳定性上月度成功率不低于 99%。有了红线再逐项调优每动一个参数都要同时观察三个指标避免“头痛医头脚痛医脚”。2. 性能攻坚延迟都花在哪了性能调优的第一步永远是拆时间线而不是盲目换模型。一次完整的 Agent 请求从用户按下发送键到看到回复中间包含网络传输、模型推理、工具调用、上下文处理、结果解析等多个环节。只有把每个环节的真实耗时拿到手才知道该往哪儿使劲。2.1 一次Agent请求的完整时间线拆解我在模拟项目 X 中给 Agent 接入了全链路追踪为每个请求生成一个 trace ID每一轮模型调用、每一次工具请求都打上时间戳。拆解典型请求后发现总耗时 8.2 秒分布大概是——意图识别模型调用 1.8 秒工具查询查库存、查价格耗时 1.5 秒第二轮模型调用基于工具结果生成回复耗时 2.6 秒上下文序列化和传输以及网络开销约 1.3 秒其余 1 秒分散在排队、解析、日志等环节。这里有个特别值得注意的现象第二轮模型调用比第一轮慢很多。原因很简单第二轮要把第一轮的对话历史、工具返回结果全部拼进上下文输入 Token 数暴涨首 Token 延迟和生成时间都跟着涨。这几乎是所有 Agent 性能问题的典型病灶——上下文越滚越大模型处理越慢成本越高。针对这个时间线性价比最高的优化动作有两个第一是用更轻量的小模型去做意图识别把大模型的资源留给真正需要复杂推理的环节第二是严格控制进入上下文的工具结果只保留摘要化的关键字段而不是把整个 JSON 原封不动塞进去。2.2 推理层的取舍模型规模和结构化输出模型选择是性能优化的重头戏。原型的做法往往是一个大模型通吃所有环节好处是省事坏处是贵且慢。生产级调优要做的第一件事就是把 Agent 里不同类型的任务拆出来分别匹配不同规模的模型。以我的经验Agent 链路里的任务大致可以分成三类意图识别和信息抽取这类任务逻辑简单但频率极高适合用小模型复杂推理和最终答案生成需要强理解能力必须上大模型介于两者之间的比如多步规划、工具选择可以根据业务复杂度选择中档模型。我在模拟项目 X 里做了一次切换实验把意图识别从大模型切到小模型后单轮调用成本下降约 70%延迟下降 40%准确率几乎没有变化因为意图识别的本质是分类任务并不需要太强的生成能力。除了模型大小输出格式约束也很关键。很多 Agent 慢是因为模型生成了一堆废话或者格式不规范的 JSON导致下游解析重试。用结构化输出能力把模型的输出限制成严格的 JSON Schema看起来只是“规范了格式”实际上它同时减少了生成 Token 数、降低了解析失败率是性能和稳定性一箭双雕的手段。2.3 工具调用环节的常见性能陷阱工具调用是 Agent 生产化中最容易被低估的性能黑洞。表面上看一次 HTTP 请求就是几十毫秒的事但在 Agent 链路里工具调用的耗时往往会被放大好几倍。第一个陷阱是我前面提到的重复调用Agent 在上下文丢失或规划出错时会对同一个工具发起多次相同请求每次都带着完整的往返延迟。我在实际项目中踩过一个很典型的坑某查询工具对相同的关键词返回结果基本不变但 Agent 因为上下文太长导致语义漂移在一个会话里查了 5 次库存接口白白多花了 1.2 秒和相应 Token 成本。解决这个问题需要引入对工具调用的去重和缓存——相同的工具和参数组合在有效期内直接返回缓存结果同时通过 Prompt 明确告知 Agent“这个信息你已经查过了不要重复查”。第二个陷阱是串行调用。有些 Agent 框架默认会按顺序执行多个工具调用即使这些调用之间完全没有依赖关系。比如既要查用户信息又要查商品库存这两件事完全可以并行但默认实现是排队执行的延迟直接翻倍。正确的做法是在调用层做并发调度把没有依赖关系的工具调用用并发方式发出去整体耗时能砍掉将近一半。2.4 上下文压缩与记忆管理对响应速度的影响上下文管理是 Agent 性能和后续成本之间的最大公约数。对话轮次一多上下文里塞满了几百轮的历史消息、工具调用记录、中间推理过程每次模型调用都要重新处理这一大坨 Token延迟和成本都线性上涨。我见过最极端的案例一个长会话的中期请求光输入 Token 就接近 3 万首 Token 延迟超过 6 秒。生产级方案一般分三层。第一层是硬截断超过窗口上限的策略可以是“丢最旧的消息”但这个粗暴策略容易把关键信息丢掉第二层是摘要压缩用一次小模型调用把中间过程压缩成摘要保留任务目标和最新状态第三层是关键信息抽取把用户偏好、业务约束、工具返回的有效数据抽出来放进固定结构的记忆区块长期驻留上下文。我在实践中倾向于摘要加抽键信息的组合既保留语义连贯性又控制 Token 总量。这里分享一个实操技巧压缩动作不要放在每次请求前做而是放在上一轮响应结束时做。也就是说每次 Agent 生成完回复顺手判断上下文是否超过阈值如果超过就立刻压缩而不是等到下一次请求来的时候再临时处理。这样可以避免压缩本身变成请求响应时间的一部分让延迟曲线更稳定。3. 成本治理别让账单吃掉收益Agent 的成本问题比普通 API 调用要隐蔽得多。普通应用调一次接口就一次钱Agent 一次用户请求可能触发模型多次调用每次调用还带着越来越大的上下文。很多人只盯着单次调用的单价却没算清楚一次完整会话到底消耗了多少 Token这才是账单失控的根本原因。3.1 成本结构拆解Token消耗的大头在哪我把模拟项目 X 的单次完整会话成本拆开分析发现一个扎心的事实输入 Token 占了总消耗的 70% 以上而输出 Token 只占 20% 多还有少量是各种重试带来的额外消耗。这个结构说明单纯限制模型输出长度只能解决一小部分成本问题真正的大头是喂给模型的输入。输入 Token 的构成也很清晰每次模型调用都会带上系统 Prompt、历史对话、工具返回结果。其中系统 Prompt 虽然是必要开销但长期不维护的话会越写越长历史对话和工具结果则是大头只增不减。我给模拟项目 X 做成本治理时第一步就是把所有环节的 Token 消耗按来源打点统计一周后拉出账单按输入 Token 量排序当场就知道该从哪个环节动刀了。用表格说明治理前后的 Token 构成变化会更直观环节治理前占比治理后占比治理手段系统 Prompt12%8%精简指令、合并重复规则历史对话38%18%摘要压缩、窗口截断工具返回结果30%12%字段白名单、结果摘要输出生成20%25%结构化输出限制长度重试损耗5%3%超时优化、熔断降级3.2 Prompt瘦身与信息检索策略Prompt 瘦身是成本治理里收益最快的一项但也是最容易被忽略的。很多系统的系统 Prompt 在迭代过程中不断追加规则从最初的 500 字膨胀到 2000 字里面还夹杂着大量自相矛盾的旧规则。实际上大模型对重复、冲突的指令并不会更听话反而会因为上下文被占满而牺牲有效信息。我做过一个实验把模拟项目 X 的系统 Prompt 从 1800 字精简到 900 字意图识别准确率反而提升了 0.8 个百分点。原因是压缩掉了大量重复强调和可被拆解的冗余背景模型更专注于核心指令。所以成本治理的第一板斧就是给 Prompt 做一次“断舍离”能删的删、能合并的合并、能用结构化字段表达的不要用长句描述。另一块大头是工具结果的投喂策略。早期实现里为了让 Agent “理解得更全面”我们把工具返回的完整 JSON 直接塞进上下文结果一次查询可能带进来几百行无关字段。优化方案是给每个工具定义结果摘要器只保留模型决策需要的字段。比如查库存的工具返回结果里只有商品 ID、可用数量、预计补货时间这三个字段需要进入上下文其余的高维字段一律丢弃。3.3 缓存设计从结果缓存到语义缓存缓存是成本治理的核心手段但需要分层设计。我在工作中把缓存分成两层结果缓存和语义缓存。结果缓存的思路很简单对于相同输入的模型调用在 TTL 时间内直接返回上次的结果不再发起真实模型请求。这适合那种用户反复查询同一问题的场景。我在模拟项目 X 里给“常见问题解答”类对话加了一层 TTL 为 30 分钟的结果缓存这部分对话的模型调用量直接下降 40%。语义缓存比结果缓存高级一些适合用户用不同说法问同一个问题的场景。它会先对用户输入做 embedding 向量化然后在缓存里做相似度匹配相似度超过阈值就直接用缓存结果。语义缓存的难点在于阈值的把握阈值设得太高命中率低设得太低缓存结果可能答非所问引发正确性风险。我的经验是先从相似度 0.92 起步根据线上反馈逐步下调同时限定只对“事实型问答”启用语义缓存对需要个性化或时效性强的请求一律绕过缓存。3.4 模型分层路由把贵模型用在刀刃上全链路用同一个模型是成本失控的另一个常见原因。模型分层路由的核心思想是让请求在进入模型前先被分类不同分类分配到不同规格的模型上。这个分类可以靠规则完成也可以靠一个小模型完成。我在模拟项目 X 里采用的方案是先定义一个“路由小模型”它的任务只是判断当前请求的复杂度等级——简单、中等、困难。然后分别映射到不同模型简单请求走轻量模型中等请求走标准模型只有困难请求多步推理、长文档理解才走最强模型。实测下来大约 60% 的请求被划分为简单或中等这部分请求的成本仅为原来大模型方案的 30% 左右而 P95 延迟也显著下降。至于“为什么敢用小模型做路由”因为路由判断本身是一个分类任务它不需要生成复杂内容只需要给请求打一个标签。这种任务甚至可以被规则初步替代如果请求长度短、关键词明确直接判为简单。但规则覆盖不了灵活表达所以保留小模型兜底整体性价比最高。4. 稳定性攻坚生产环境最怕什么稳定性是 Agent 生产级调优里难度最高的一环。传统服务出故障通常是确定性的报错信息能指出具体位置Agent 出故障往往是概率性的——模型偶尔抽风、工具偶尔超时、上下文偶尔冲突每个“偶尔”单独看都能接受但叠加在每周几万次请求上就是实打实的线上事故。4.1 超时与重试你的Agent为什么卡死Agent 卡死最常见的原因是超时设置不合理。我给模拟项目 X 做过一次故障排查某个请求耗时超过 60 秒整个用户体验就是“转圈圈”。查下来发现问题出在工具调用超时设成了 30 秒而工具访问的数据库服务在极端情况下响应要 40 秒。模型调用那边超时设得更大两次重试叠加总耗时直接爆炸。这里的关键教训有三个。第一链路里的每个节点都要设置独立的超时时间不能只设总超时。模型调用、工具调用、内部处理分别设置上限任何一个节点超时都立刻终止不要傻等。第二超时时间的取值要基于真实 P99 数据加合理冗余而不是拍脑袋。我用每个节点的 P99 延迟作为基准再上浮 50% 作为超时阈值既保证正常情况不会被误杀又能兜住异常抖动。第三重试不是无限重试必须严格控制总次数和总耗时预算。我给模拟项目 X 的模型调用设定了最多 2 次重试、每次重试使用指数退避加随机抖动整个链路的整体超时预算控制在 8 秒以内。4.2 降级策略模型不可用时的兜底方案降级策略是 Agent 稳定性的最后一道防线。很多人忽视这层总觉得“模型服务很稳定不会出问题”但实际上模型服务商也会限流、也会故障而且一旦出问题影响是全局性的。我在实际项目中遇到过模型服务连续抖动半小时的情况如果当时没有降级方案那半小时里的所有用户请求都会失败。降级方案要分场景设计。第一级降级是模型层面的兜底当主模型服务不可用或响应超时时自动把请求切到备用的模型服务。这里有个容易被忽略的点备用模型不一定要和主模型同规格因为在故障场景下用户的诉求是“有响应”而不是“完美答案”。所以我设置了“降到低规格模型 简化任务”的组合方案比如把多步推理改成单步问答至少能保持基础服务可用。第二级降级是业务层面的兜底当所有模型服务都不可用时直接用规则引擎或预设模板回复。比如客服 Agent 在极端场景下就直接回复“系统维护中请稍后再试”同时在后台记录工单等系统恢复后再处理。这种方案虽然生硬但保证了用户的每一次请求都有明确反馈不会出现无限等待或静默失败。4.3 幂等性与并发控制防止重复执行事故Agent 和普通 API 最大的不同在于它有“行动能力”——会真实地调用工具去完成业务操作。这就带来一个严肃问题如果用户的请求因为超时被重试Agent 会不会把同一笔转账转两次把同一个工单建两遍幂等性是解决这个问题的核心。我在模拟项目 X 里给所有写操作工具都加了幂等键每个请求在进入 Agent 时生成一个全局唯一的 request ID这个 ID 会透传到所有工具调用。工具执行前先检查这个 request ID 是否已经处理过处理过的直接返回上次结果不再重复执行。这个方案看起来简单但落地时有个细节必须注意幂等键的检查必须是原子的不能两个并发请求同时通过检查然后都执行写操作。实际的实现是先在存储里抢占幂等键记录抢到才执行抢不到就直接返回等待或之前的结果。并发控制是另一个容易翻车的地方。Agent 应用经常出现短时间大量请求涌入如果不控制并发所有请求同时打到模型服务后果要么是被限流要么是核心资源被冲垮。我用信号量做了一层并发上限比如模型并发调用数不超过 5工具并发调用数不超过 10超出的请求进入队列等待。这层控制让系统在流量突刺时依然能保持稳定的吞吐而不是彻底瘫掉。4.4 可观测性日志、追踪与告警的落地可观测性贯穿了性能、成本、稳定性三项调优的始终。没有可观测性你只能靠用户投诉被动发现问题有了可观测性你可以在问题影响用户之前就把它拦住。Agent 应用的可观测性比普通 Web 服务要复杂因为一次请求里涉及多次模型调用、多个工具调用、内部状态变化必须引入 trace 的概念才能看清链路全貌。我的落地经验是三层结构。第一层是结构化日志每个环节都输出包含 trace ID、耗时、Token 数、模型名、调用的工具名等字段的 JSON 日志。第二层是全链路追踪用 trace 把所有模型调用和工具调用串起来在可视化界面里能看到每一步的时间线和上下游关系。第三层是核心指标监控包括响应时间P50/P95/P99、成功率、Token 消耗速率、单次会话成本、工具调用失败率。基本的告警规则是P95 延迟超过阈值触发警告成功率低于 99% 触发紧急告警单次会话语义缓存未命中率异常也记录下来。这里有个经验之谈告警别贪多宁少勿滥。一开始我恨不得每个指标都设一条告警结果告警风暴一来真正的故障信息被淹没在大量无效告警中。后来收敛到五条核心告警P95 延迟、成功率、模型调用超时率、工具调用失败率、每分钟 Token 消耗异常增长。规则简单但每条都能击中要害。5. 一次真实调优案例的完整复盘理论讲再多不如看一次完整实战。这个案例来自模拟项目 X是一个企业内部知识问答 Agent前期功能开发完成后一进生产环境就问题爆发。我用这个案例把前面所有方法串一遍也让读者看看调优顺序和优先级到底该怎么排。5.1 模拟项目X的初始表现延迟8秒、成本超标、偶发失败项目 X 的 POC 版本表现良好因为测试数据干净、并发低、上下文短。一上生产真实流量带来的脏数据、长对话、高并发把问题全部暴露出来。上线第一周的监控数据是P95 延迟 8.2 秒远高于 5 秒目标单次会话平均模型成本比预估高 2.3 倍成功率 98.2%看似不低但那个 1.8% 的失败集中在真实用户的高价值操作上每周都要处理好几起投诉。针对这三个数据我们先判断优先级稳定性问题虽然只影响 1.8% 的请求但是一旦涉及工具写操作失败会造成严重的用户信任问题所以第一优先级是解决成功率和失败超时其次是性能因为 8 秒的延迟已经让用户明显感知到“卡”最后是成本因为项目还在验证期成本超支会直接威胁项目存续。5.2 逐项优化的顺序与方法我们按照“先止血、再提速、后减肥”的顺序逐项处理。止血阶段只做三件事。第一给所有外部调用设置独立超时和严格重试预算消除了请求卡死问题。第二给所有写操作工具加上幂等键消除了重复执行风险。第三建立降级通道模型服务异常时自动切备用模型并简化任务。这三件事做完成功率从 98.2% 提升到 99.5%耗时一周。提速阶段做两件事。第一把意图识别和复杂度路由从大模型切到小模型消除了大部分低频任务的延迟。第二对工具结果做字段白名单和摘要化处理大幅压缩第二轮模型调用输入 TokenP95 延迟从 8.2 秒降到 4.1 秒直接达成 5 秒目标。减肥阶段做两件事。第一引入语义缓存层拦截高频重复问题。第二对长会话上下文做“对话摘要 关键信息持久化”的压缩单次会话成本从超预算 2.3 倍降到预算内的 85%。三周调优结束后三项核心指标全部达标且没有出现新的副作用。5.3 调优后的收益数据与遗留问题调优后的完整数据对比是这样的指标调优前调优后P95 响应时间8.2 秒3.6 秒成功率98.2%99.6%单次会话平均成本预算的 230%预算的 85%模型调用次数/会话5.2 次3.4 次语义缓存命中率无缓存31%数据很好看但调优并没有“完全结束”。遗留问题包括语义缓存对某些相似表达会误命中偶尔出现回答不够精准的情况我们通过定期核对缓存命中内容的正确率来控制小模型路由在大促期间出现过分类漂移后来用规则和临时降级兜住了。这也印证了一个观点调优不是一次性的它是随着线上数据持续修正的迭代过程。6. 持续调优机制好的Agent是“养”出来的很多团队把调优当成上线前的一次性动作上线后就不管了这是大忌。Agent 系统的特殊性在于它会随着用户交互不断积累新的输入模式、新的工具使用场景甚至模型本身也在不断更新。一个上线时调到最优的 Agent三个月后可能因为用户使用习惯的变化而重新变差。6.1 基于线上日志的回归测试持续调优的第一件事是建立基于线上日志的回归测试机制。每次改动 Prompt、调整模型参数或修改工具逻辑之前先跑一遍回归测试。方法是从线上日志里定期抽取一批有代表性的历史请求把它们作为固定测试集。每次改动后用改动后的 Agent 跑一遍这批请求记录关键指标成功率、正确性、延迟是否出现回退。这个机制看起来简单但能挡住大量隐性回归。我在某次优化中把工具结果的截断策略改动了一下单看指标全都符合预期结果回归测试发现某些复杂查询的正确率下滑了两个百分点顺着这个线索排查才发现截断策略把一些多值字段切坏了。6.2 评估集建设与线上反馈闭环回归测试的效果取决于测试集质量所以评估集建设也必须是持续行为。我习惯把评估集分成两类通用基础集和线上反馈集。通用基础集覆盖各业务方向的典型场景保持稳定用于横向对比每次改动的效果线上反馈集则每周更新从真实用户反馈中挑选那些“Agent 答错了但用户没投诉”或者“用户明显表达了不满”的会话补充到评估集里。把用户不满的会话中做得不好的请求持续全量评估可以帮助追踪 Agent 能力的真实边际。反馈闭环的另一层是要在线上系统里埋一个“用户反馈”入口比如让用户在回答下方点“有用/没用”。这些标签要和 trace ID 绑定这样每次用户点“没用”时你都能拉出这次回答涉及的完整链路定位问题发生的具体环节而不是笼统地认为“模型不行”。6.3 灰度发布与配置化开关持续调优的最后一个保障是灰度发布机制。Agent 系统改动不直接全量上线先把改动部署在一小部分流量上观察数据再逐步放大比例。我在实践中把 Agent 的可调参数模型选择、Prompt 模板、缓存 TTL、超时阈值全部做成配置中心里的可动态变更项每次改动都通过配置发布而不是重新发版。这让灰度发布变成了一个纯配置操作先在 5% 流量上启用新配置观察 30 分钟到 1 小时成功率和延迟没有异常再逐步提升到 50%、100%。如果指标异常随时一键回滚秒级生效。灰度发布也有个容易被忽略的点不仅是新功能的改动要灰度Prompt 的微调也需要。不少人觉得“改两个字没事吧”结果就因为改了 Prompt 里的一处措辞导致模型输出风格大变。在我的团队里任何对 Prompt、模型参数、工具逻辑的改动都要走灰度流程这是保证生产系统稳定性的底线。最后聊一点个人体会——Agent 生产级调优和传统后端调优最大的不同在于它面对的是一个概率系统而不是确定性系统。传统系统调优讲究“找到问题、修复问题、问题消失”Agent 调优更像是“寻找最坏情况、降低最坏情况的概率、给最坏情况准备预案”。性能、成本、稳定性三者的平衡没有一劳永逸的配置只有持续观察、持续调整、对线上数据保持敬畏的日常功夫。希望这篇文章能把你在生产环境里踩过的坑和即将踩的坑都提前摆到桌面上来。
