生产级Agent调优实战：性能、成本与稳定性全攻略

2. 生产级Agent调优，先承认三件事：快、省、稳，一个都不能少

先泼一盆冷水：你本地跑得飞起的Agent Demo，扔到生产环境大概率会变成又慢又贵又不听话的定时炸弹。我见过太多团队死在从原型到上生产的最后一公里，问题从来不是模型不够聪明，而是工程上没把Agent当成一套有外部依赖的业务系统来对待。

这一课的标题已经说得很明白：调优的核心战场是性能、成本、稳定性。对应到实际工作中，就是三个你躲不开的问题：用户的请求能不能在可接受的延迟内得到响应？每一轮对话的钱烧得值不值？系统在连续运行一周后会不会因为一个小工具的偶发超时而全线崩溃？

本课面向的人群很具体：已经掌握Agent基础搭建、正在把自己的项目推向真实用户的技术同学。在这节课里，我会把生产级调优拆成六个可落地的部分——先讲清楚诊断思路，再分别攻坚性能、成本、稳定性，最后做综合取舍和问题排查。全套方法都已经在我负责的若干个实际项目中跑过一遍，不是理论推导。

先说一个核心观点：生产级调优的本质不是“优化”，而是“约束”。模型本身的能力已经足够，你要做的是用缓存、路由、超时、重试、观测这些工程手段，把它的行为约束在一个可预测、可度量、可接受的边界内。这个思路贯穿整篇文章。

3. 先搞清楚你的Agent到底卡在哪

3.1 三条时间账：模型推理、工具往返、上下文膨胀

我接手过的每一套Agent系统，性能问题几乎都出在同一个地方：没有人系统地算过时间账。生产环境里，一次看似简单的用户请求，实际上要经过一个完整的链路：接收请求、构造系统提示词、检索外部数据、调用模型生成、执行工具调用、再次生成最终回复。这个链路里，每一环都在消耗时间。

如果把平均响应时间200毫秒以内的API延迟加总，一个典型的Agent任务总延迟在3到15秒之间是非常正常的。但这3到15秒怎么分配，决定了你的优化空间在哪。

我把链路拆成三笔账：

第一笔是模型推理延迟，也就是模型从接收完整输入到生成第一个token的时间，专业叫法TTFT。这个时间主要由模型参数量、输入长度和部署端的推理优化程度决定。API调用模式下你没法直接优化，但可以通过减少输入长度来间接降低它。

第二笔是工具往返延迟，也就是Agent为了完成一个任务，调了几次外部API。每次工具调用的网络往返就是几百毫秒到几秒，如果你的Agent为了查一个订单要连续调三次API，光这笔账就够你看的了。

第三笔是上下文膨胀延迟。这是最隐蔽的一笔。Agent每多执行一步工具调用，工具返回的结构化结果都会追加进对话历史。几个回合下来，输入长度可能从最初的2000 tokens膨胀到8000以上。输入变长，模型计算量变大，TTFT变慢，这一环直接拖慢整条链路。

所以，任何一个性能优化动作开始前，先在日志里给每轮完整请求打上时间戳，拆出模型耗时、工具耗时、上下文构建耗时。没有数据支撑的调优，全是瞎调。

3.2 量化指标和调优目标表

性能、成本、稳定性这三个词，在工程上必须有明确数字定义。

生产环境我建议至少盯五个指标：

拿P95而不是P50当主要指标，是因为用户体验的感知来自最差的请求，而不是平均请求。一个P50只有2秒的系统，如果P95要30秒，用户感受是你这产品一半时间都在转圈。

定完指标后，再排出优先级。我个人的习惯是：功能上线第一周盯稳定性，第二周盯成本，第三周才开始做性能压测。先不能挂，再谈快和省。你如果一上来就追求极致性能，大概率会在稳定性上翻车。

4. 性能攻坚：让响应从"蜗牛爬"变成"小跑"

4.1 Prompt瘦身：上下文精简的工程化做法

大量性能问题，根子在Prompt太臃肿。你会发现写Prompt时很容易犯一种“什么都想交代”的病：系统提示词三四百字，示例恨不得给十个，历史对话一股脑全塞进去。

我的建议是给Prompt做瘦身，规则极简且可执行：

• 系统提示词控制在150个汉字以内，只保留角色定位、任务边界、输出格式三件事
• Few-shot示例最多保留2个，并且每个示例都必须是真实任务的高质量样本
• 对话历史做滚动窗口，只保留最近3轮，更早的内容全部摘要成一句话

举个例子，我之前处理过一个客服Agent，系统提示词写了400多字，前前后后铺垫了很多业务背景。结果就是每次请求的输入长度稳定在5000 tokens以上，首token延迟接近4秒。我把提示词压缩到120字，业务规则全部移到后台的检索内容里，输入长度直接降到2500以内，首token延迟掉到了1.1秒。

你可能会担心：提示词短了，Agent会不会变笨？实测下来完全不会。模型的核心能力本来就在，Prompt的作用是设定边界，不是车轱辘话。真正影响效果的，是你能不能在检索内容里把业务上下文给准。

4.2 RAG检索加速：索引、并行和缓存的组合拳

大部分生产级Agent都会接RAG，检索这块的调优空间相当大。市面上很多Agent的痛点都出在检索环节：向量库检索快则50毫秒，慢则800毫秒，如果再串上重排序，整个检索链路就可能干到2秒以上。

两个直接的优化手段：

第一，向量索引类型要选对。使用HNSW算法替代暴力扫描，1024维向量、10万条数据规模下，单个查询的召回时间能从300毫秒以上压到30-50毫秒。代价是构建索引的时间变长、内存占用稍大，但在生产环境完全值得。

第二，和主流程无关的检索请求并行处理。比如一个Agent任务里既要查资料又要查用户画像，这两次检索之间没有依赖关系，那就用并发去跑，不要串行。实际代码里用简单的asyncio.gather就能把两轮串行检索的总耗时砍掉近一半。

缓存也不可或缺。针对高频问题，做一个简单的内容寻址缓存：对查询文本做哈希，命中缓存就直接返回，完全不进向量库。在真实客服场景里，高频问题大概占全部请求的30%-40%，命中缓存后这部分请求的检索环节用时直接归零。

4.3 并发设计：连接池和请求合并

很多团队在Agent性能优化上花了大把时间调Prompt，却忽略了一个更基础的设施问题：和模型API之间的网络连接管理。

如果每次请求都新建一个HTTP连接，握手和TLS的消耗就得几百毫秒；如果全部请求挤在一个连接上，又会出现排队堵塞。正确做法是维护一个连接池，让连接可以被复用。

另一个实用技巧是请求合并。当Agent需要在一次任务里连续调用多次相似工具时，考虑把多次调用合并成一次批量调用。比如很多业务场景需要批量查多个ID的信息，与其循环五次查询，不如一次请求把五个ID都带上。这部分优化往往能直接砍掉2-3秒的响应时间。

我踩过的坑是：一开始很迷信单点性能优化，四处给Agent加样本示例、调模型参数，结果收效甚微。后来把同样功夫花在并发和连接池上，整体吞吐直接翻了一倍。先查架构，再抠细节，这个顺序非常关键。

5. 成本攻坚：让每一分Token都花在刀刃上

5.1 算清楚账：成本到底烧在哪

做生产级Agent，你不会希望月底看到账单时才发现钱没了。成本问题必须前置，从设计阶段就算清楚。

一个Agent任务的成本主要由三块构成：

第一块是模型调用费，这个很好理解，贵的模型每百万token价格可能是便宜模型的几十倍。

第二块是上下文重复费，这是最容易被忽视的。你的系统提示词如果每次请求都重复发送，加上不断累积的历史对话，这部分费用甚至会超过最终生成回复的费用。举个例子，一次任务里如果累计输入了10000 tokens的上下文，最终输出只有300 tokens，那么成本大头其实是输入，不是输出。

第三块是重试和折腾费。Agent每一步出错会重新调用模型，每一步都算钱。如果因为提示词写得不清楚导致工具返回格式反复不对，你可能多付了三四次模型调用的钱。

所以成本调优的第一步，是在日志里给每一轮请求记录token数，区分输入和输出，再算一笔单请求成本。不看数据，你根本不知道钱花哪了。

5.2 Prompt缓存是隐藏的省钱大招

很多团队知道Prompt缓存存在，但没用对。理解这一点，对控制成本有立竿见影的效果。

Prompt缓存的核心逻辑是：相同前缀的输入可以被上游服务缓存，命中的部分按远低于正常价格计费，甚至不收费。这个机制非常简单，但要求你的输入具备稳定的前缀结构。

实操上要做两件事：把系统提示词、固定业务规则放到输入的最前面，且保证这些内容在多次请求之间完全一致。凡是会随用户变化的部分，比如用户ID、对话历史，统统放到输入末尾。这样缓存命中的概率会非常高。

我遇到过一个用户，他的Agent输入里每次都动态拼接当前时间戳到提示词开头，直接导致缓存永远无法命中。排查出来之后，把时间戳挪到请求末尾，缓存命中率一下从不到10%拉到了70%以上，月度成本直接掉了超过四成。这类细节，不算账是根本发现不了的。

5.3 模型路由：贵和便宜按需分配

生产级Agent不应该是所有请求都走同一个模型。一个完整任务链路里，不同环节对模型能力的需求不一样，可以搭配着来。

我目前惯用的路由策略是：

这套策略真实落地后，单请求成本能下降50%-70%，而用户感知到的生成质量几乎没有变化。

同时推荐给模型加上max_tokens上限。如果不是要生成报告，单轮回复的token上限设到500-800就够用了。别小看这个参数，它可以防止模型在个别场景下生成超长废话，直接烧钱烧时间。

6. 稳定性攻坚：让Agent成为值得信任的系统

6.1 错误分类与重试机制：不是所有失败都值得重试

稳定性，是生产级Agent最容易翻车的地方。很多同学的Agent在自己电脑上跑得很好，一上生产就反复出问题。因为真实环境里你会碰到各种偶发异常：上游API超时、网络抖动、工具返回格式突变、模型偶尔抽风。

重试机制的黄金原则只有一条：只重试值得重试的错误。

如果不分类，所有错误一律重试三次，那遇到工具参数错误的请求会白白重试三次，既浪费时间又浪费成本。

我的分类方法是：

重试次数建议控制在2次以内，每次重试间隔做指数退避，比如第一次等1秒，第二次等3秒。再多就是浪费了。现实中第3次重试还能成功的概率极低，纯属自己骗自己。

6.2 超时控制与降级方案：给整个Agent套上紧箍咒

Agent系统最可怕的事故形态是：整体卡死。一个工具请求挂在那边，不返回也不超时，导致用户请求一直排队。

这里提一个关键策略：所有环节都要有超时时间，而且整体请求还要有总超时时间。

各环节的建议超时值：

• 模型调用单次超时：60秒
• 工具调用单次超时：20秒
• 整个Agent任务总超时：90秒
• 闲置等待超时：30秒

如果超过总超时还没完成，直接返回兜底回复，比如“我暂时无法处理，请稍后再试”，并记录工单进入人工处理队列。对于大多数业务场景，一个有兜底的“暂时不行”远好过无休止的等待。

降级方案也要提前设计。当主模型因为限流不可用时，自动切换到备用轻量模型，哪怕回答质量略降，也要保证服务不中断。

这些机制听上去是常识，但真正在代码层面落地的团队并不多。大多数生产事故的根因，都是没有兜底策略。

6.3 观测和告警：日志里埋好三个探针

做Agent类应用，最痛苦的排查是：用户反馈说“回答很奇怪”，但你连同排查入口都找不到。所以观测系统不能等出事了再建，要在上线第一天就埋好。

我强烈建议至少加三个探针：

第一，全链路追踪ID。每次用户请求生成一个trace_id，贯穿所有日志。没有这个ID，你的排查就是在黑灯瞎火里乱摸。

第二，每步调用的耗时和Token记录。记录每一步LLM调用和工具调用的耗时、token数、结果状态，这样能精确复现一次完整请求中每一环发生了什么。

第三，关键事件日志。包括重试事件、超时事件、模型切换事件、超出预算告警事件。不是所有请求都记，只记异常事件，控制日志成本。

告警规则不要贪多，三条足以覆盖大多数case：

• 任务成功率连续5分钟低于95%时触发
• P95响应时间连续5分钟超过15秒时触发
• 单请求成本连续5分钟超过预算阈值时触发

7. 综合取舍与实战案例：一次真实的调优全过程

7.1 性能、成本、稳定性之间的平衡

调优Agent时，三角指标之间没有免费的午餐。性能提升往往要付出成本，比如用更强模型来减少重试；成本控制可能带来延迟波动，比如缓存冷启动时需要去向量库现算；极端追求稳定性则可能牺牲响应速度，比如加了各种超时和降级机制后，一部分请求会被边界条件延后处理。

我建议用“成本带宽”的思路来选择方案：给单请求成本设定一个上限，在这个约束下追求最优的响应时间和成功率。不要追求全维度最优，那是浪费钱。

7.2 案例复盘：某客服Agent的调优全过程

这里记录一个内部项目的真实调优过程。初始状态：P95响应时间18秒，单请求成本1.9元，任务成功率91%。客户很不满意。

我按“先稳、后省、再快”的顺序执行：

第一步，稳定性。将所有外部调用的连接超时从60秒缩短到10秒，读超时从60秒缩短到30秒，同时加上两层重试机制：参数错误不重试，网络超时退避重试一次。任务成功率从91%升到了95.5%。

第二步，成本。给Prompt做了一次大瘦身，引入Prompt缓存，加上模型路由。单请求成本从1.9元降到了0.6元，成本降了一大半，响应速度也跟着变快了，因为输入长度变短了。

第三步，性能。配合连接池和并发检索，P95响应时间从18秒降到了7.5秒。

整个调优周期两周，最后的指标是：P95响应7.5秒，单请求成本0.6元，任务成功率96.5%。这个配置稳定运行了半年没有翻车。

这轮调优我最大的体感是：优先解决会引发线上事故的问题，再谈成本和性能。稳定性是地基，地基不稳，上面优化再多也白搭。

7.3 调优节奏建议

这里给出一个通用的节奏建议：

建议做成一个长期迭代的循环，而不是一次性项目。生产环境的流量会变、模型会变、业务会变，每季度至少回头做一次全量复盘。

8. 常见问题与排查技巧实录

8.1 高频问题速查表

我整理了这大半年排查Agent问题遇到的高频场景，做成一张速查表：

8.2 容易被忽略的三个坑

第一个坑是只看平均值。调优时如果只看P50，你会觉得一切正常，懒洋洋的。要盯P95，甚至P99，你才能看到真实体验的瓶颈。

第二个坑是全局变量污染。多轮对话环境里，如果某个历史消息里的错误信息一直被复制到后续上下文，Agent会越走越偏。建议在上下文构建时过滤掉工具调用失败的部分，或者用摘要替代原始历史。

第三个坑是把重试逻辑放在业务代码里写死。重试机制应该集中在中间件层统一管理，不要在每个工具内部各自实现，否则重试策略很容易失控，还容易造成重复写入之类的事故。

9. 关于Agent生产级调优的一点个人体会

做Agent调优这一路，最大的变化不是技术能力的提升，而是心态的转变。刚入门时总以为Agent的本事全靠模型选得好，后来才发现，模型只占最终效果一小半，剩下的大半都藏在工程细节里。

现在回头看，如果让我给做生产级Agent的同学一句最实在的建议，那就是：先把“不可能挂掉”做成底线，再追求“性能好一点”“成本省一点”。稳定性是1，性能和成本都是后面的0。

还有一个持续受益的习惯是，每次调完一个参数，都在本地留一份完整的调优记录，包括改动前后指标、原因和排查过程。Agent工程这个领域，经验会越来越值钱。你踩过的每一次坑，过了半年，都会变成别人付费也买不到的经验手册。

这一课的内容到这里就收尾了。下一次再遇到线上Agent系统出了状况，建议你先深呼吸，打开日志面板，按本课的框架逐项排查——性能看时间账，成本看token账，稳定性看错误分类账。账目清了，问题就藏不住了。