把Agent从Demo搬到生产环境是我见过翻车率最高的一步。功能明明早就跑通了演示时也足够惊艳结果一上真实流量要么回答变得又慢又呆要么账单一个月暴涨几十倍要么上线第二天就冒出一堆答非所问的事故。性能、成本、稳定性这三件事任何一个炸了Agent项目都会瞬间失去信任。这篇文章就把我在生产环境里做Agent生产级调优时踩过的坑和总结出的套路完整写一遍适合那些已经跑通Agent原型、准备推向生产或者正在被线上各种疑难杂症折磨的开发者参考。1. 为什么Demo跑得通一上生产就原形毕露——先弄明白调优到底在调什么很多人以为Agent调优就是改改Prompt、换换模型这是最大的误解。Demo阶段你面对的是自己精心设计的输入用户量是几个人模型调用失败了你手动重试一次就行延迟慢了你也不觉得有什么问题。可一旦进入生产环境这三件事会同时变质。1.1 链式调用里的概率乘法看起来很稳的系统其实很脆先算一笔账。假设你的Agent单次任务平均要调用4次模型接口单次调用的成功率是95%这个数值在真实环境下已经算不错了那整条链路的最终成功率是多少0.95的4次方约等于81.5%。也就是说大约五分之一的任务会以某种方式失败。而Demo阶段你根本感知不到这个问题因为你自己试的时候失败了重新跑一次就行用户可没有这个耐心。更要命的是错误放大效应。一次工具调用返回了非预期格式模型看到错乱数据后可能继续往下编编出来的答案又成了下一次调用的上下文。这种级联式的错误在每个环节都会被放大一点点最后呈现给用户的就是一个完全离谱的答案。生产环境里没有重试一次就好这种操作你必须假设每一环都可能出错并且提前想好出错后往哪里走。1.2 延迟与Token成本Demo里不被感知的东西生产环境全是钱还有一个容易被忽略的事实模型推理是按Token收费的而且输出Token的价格通常比输入Token更贵。在Demo阶段你调几次模型一个月也就几十块钱没人会心疼。可上线后一分钟几十个请求的QPS下Prompt里多写三百个字一个月可能就多烧掉一台服务器的钱。延迟也一样。本地调试时模型响应两秒钟你完全没感觉但用户侧加上网络传输、工具调用、渲染时间一个Agent任务跑到十秒以上流失率会成倍上升。我见过很多团队把Agent的Prompt调得花里胡哨把系统提示词写成了几千字的说明书结果线上日志里全是延迟告警因为每次调用都要把这几千字重新处理一遍。1.3 生产级调优的三个核心矛盾说了这么多其实生产级调优本质上是在处理三个矛盾。第一个是效果与成本的矛盾。模型越大效果通常越好但Token单价也越高如何在几乎不损失效果的前提下用更小的模型或更短的Prompt完成任务。第二个是延迟与质量的矛盾。串行调用多个工具会得到更完整的信息但时间会翻倍并行调用能缩短延迟但需要处理部分结果缺失的情况。第三个是个性化与稳定性的矛盾。为了让用户觉得这个Agent懂我你会让模型更自由地发挥但自由度越高输出格式和内容就越不可控。理解了这三个矛盾再看后面的优化方案就会清楚很多每一次调优其实都是在矛盾的某个平衡点上做取舍。下面我按性能、成本、稳定性三个维度分别展开。2. 性能攻坚把能用的Agent改造成好用的Agent性能调优不是简单换一台高配服务器就能解决的瓶颈往往出在调用的编排方式上。我自己在优化Agent的过程中最见效的动作几乎都集中在这一块。2.1 串行改并行能同时进行的调用绝不排队等待Agent的决策链路里很多模型调用和工具调用之间根本没有依赖关系但在最开始的实现里它们往往被写成了串行。举个例子一个购买咨询Agent收到我想买XX有货吗多少钱明天能送到吗这样一条请求需要同时查库存、查价格、查物流时效这三个查询之间没有任何依赖关系。如果串行执行假设每个工具耗时2秒完成需要累计6秒再去调一次模型做汇总又是2秒总共8秒。改成并行后三个查询2秒内全部返回加上模型汇总的2秒总共4秒。这一个改动就把延迟砍掉了一半。我最初接手某个项目的时候也是串行逻辑排查线上问题时发现模型一次决策里往往要连续调四到五次工具每一次都是老老实实等前一个返回再发起下一个。后来把无依赖的调用全部放进并发池平均延迟直接从十几秒降到了五秒以内。# 串行模式总耗时约等于所有子任务耗时之和 results [] for tool_fn in [get_user_profile, get_product_stock, get_current_price]: r tool_fn(user_id, product_id) results.append(r) # 并行模式总耗时约等于最慢的那个子任务 import asyncio async def fetch_all(): return await asyncio.gather( get_user_profile(user_id), get_product_stock(product_id), get_current_price(product_id) )不过并行也不是无脑开有两个坑要提醒一下。第一并发度别拉太高尤其是外部工具接口通常有QPS限制瞬时把所有请求打出去容易触发限流反而变成另一种延迟。第二并行会提升瞬时Token消耗因为多个模型调用是同时发出的如果你的账号有速率限制需要在并发池里加一个信号量做控制。2.2 结果缓存与语义缓存同样的请求不要反复让模型烧钱性能优化里最划算的事情就是让模型少干活。Agent的线上请求里有相当一部分是重复或高度相似的比如用户反复问同一个产品的价格、同一种业务的办理条件。这些请求完全没必要每次都重新走一遍模型调用。缓存分两个层级。第一层是精确缓存也就是完全相同的输入直接命中。这里有个关键细节不要拿完整的Prompt做缓存键而是要拿归一化后的用户意图做缓存键。比如把灯打开和帮我开一下灯字面不同但意图归一化之后都应该是同一个动作指令。用我的做法大概是这样def build_cache_key(user_query: str) - str: # 先剥离语气词、重复词做同义改写 normalized_query normalize(user_query) # 再用一个轻量意图分类器判断意图 intent lightweight_intent_classifier(normalized_query) # 关键信息抽出后拼成稳定键 return f{intent}:{extract_entities(normalized_query)}第二层是语义缓存适合那些表述千变万化但答案高度稳定的查询。实现思路是把用户Query向量化然后用余弦相似度去历史缓存里找最接近的一条相似度超过阈值就直接复用缓存结果。这里阈值很关键设得太高缓存命中率低设得太低会返回不相关的答案。我调过的经验值是0.92到0.95之间需要根据自己的业务数据反复试。还要强调一下缓存不是所有场景都适用。比如帮我写个方案这种开放式创作类请求语义缓存很可能给出陈旧答案用户会明显感觉到敷衍。这类请求要主动绕过缓存。2.3 模型分级与降级路径快慢模型切换的调度策略生产环境里所有的请求都塞给同一个大模型这是有钱任性的做法不是合理的架构。更好的设计是做一个模型路由层根据任务复杂度把请求分发到不同规格的模型上。我常用的分层是三层第一层是本地轻量规则处理完全确定性的任务第二层是响应快、价格低的模型处理意图识别、实体抽取、简单问答第三层才是旗舰大模型只处理复杂推理、多步规划、长文本生成等高难度请求。实际实现时路由判断本身也要花时间所以通常用一个又快又便宜的分类模型来承担这个职责。它会先判断任务类型然后决定走哪条路径def route_task(task_description: str): task_type quick_classifier(task_description) if task_type in RULE_COVERED_TASKS: # 本地规则能处理零成本 return run_local_rules(task_description) elif task_type in SIMPLE_INFERENCE_TASKS: # 快模型路径 return call_model(fast_cheap_model, task_description) else: # 旗舰模型路径 return call_model(top_performance_model, task_description)降级路径同样重要。线上调用旗舰模型如果超时或返回错误不能直接给用户报错而是应该立即切换到一个稍小但对当前任务仍然可用的模型给出一个能用但不完美的答案。我在实际项目中遇到过多次这种场景旗舰模型因为平台侧负载过高导致响应超时降级到快模型后虽然推理深度弱了一些但至少用户没有拿到系统错误。这条降级路径如果没做一次模型服务波动就是一次线上事故。2.4 结构化输出与显式Token预算模型的生成是逐Token产出的所以控制输出长度直接决定了生成时延。很多人只在Prompt里要求请简洁回答模型对这个词的理解非常弹性该啰嗦还是会啰嗦。更好的做法是给显式约束比如你的答案不超过200字只输出JSON格式不要任何解释性文字。这些显式约束对模型来说是硬指令能明显压缩输出Token数。结构化输出的要求也一样。让模型返回JSON时必须给出清晰的字段定义和取值范围而不是只说返回JSON。比如你需要一个工具调用的JSON应该定义好工具名、参数对象、以及参数的可选值。模型拿到精确的Schema定义后输出的规范性会大幅提升后续解析的稳定性也会好很多。做Agent时我还会额外让模型在拿不准参数时返回null而不是编造一个值这个细节让我少排查了好几次诡异的问题。3. 成本治理把Token花费压到合理线但不能牺牲效果成本治理和性能优化是相伴的很多性能手段做完了之后成本也会同步下降。但成本还有自己独立的优化维度尤其在生产环境中Token消耗是线性增长的东西不做治理绝对会失控。3.1 先搞清楚钱花在哪儿历史膨胀是一个容易被忽视的隐形杀手不少人以为Agent成本的主要花费是每次调用的Prompt其实对对话类Agent来说真正的大头是不断膨胀的历史上下文。每轮对话你都需要把之前的全部历史重新发给模型一次两次还好聊到二十轮的时候每次调用都背负着前面十九轮的Token成本。这个开销随对话次数呈近似平方级增长是典型的历史膨胀问题。我见过一个账单爆炸的真实案例某Agent上线后单日活跃用户只有几千账面成本却高得离谱。排查后发现根因就是历史消息全量回传加上有些环节还把大段工具返回原文塞进了上下文导致单次调用动不动就消耗几万Token。成本治理的第一步必须是给进上下文的内容做审计每一条数据问一句自己模型真的需要它吗这里给一个简单的成本测算模型供参考。假设你用的是按量计费的模型接口输入Token和输出Token单价不同那么单次调用的成本约等于输入Token数 × 输入单价 输出Token数 × 输出单价。如果平均每次调用消耗输入Token 3000、输出Token 500一个月调用10万次代入单价之后很容易算出这是一笔不可忽略的开支。把历史从全量保留改为压缩摘要之后输入Token经常能压缩掉60%-80%成本下降立竿见影。3.2 调用轮次上限防止Agent过度思考Agent和普通问答最大的区别在于它会自行决定调用工具的次数。设计Agent时如果你给它你可以反复调用工具直到完成任务这种自由度它在复杂任务中确实能体现出优势但也非常容易陷入过度思考一轮又一轮地调用工具确认信息迟迟不给结论。生产环境里必须给Agent的决策循环设置硬性上限。我的习惯是控制在3到5步达到上限后Agent会被强制停止新的工具调用并基于已获取的信息直接给出答案。这么做还有一个额外收益它逼着模型在有限步数内更高效地决策反而减少了无意义的验证动作。步数限制最好放在系统提示词里显式声明同时把剩余步数也动态注入到每一轮上下文里让模型感知到我再不收敛就没机会了。比如注入一句当前已执行4次工具调用最多还有1次操作机会请直接回答用户问题模型通常会立刻收敛。3.3 记忆压缩与上下文缩编把长对话改成摘要既然历史膨胀是成本大头那记忆压缩就必须做。我的做法是在对话管理模块里维护一个会话状态记录当对话历史超过一定阈值时触发一次摘要压缩——用一次额外的模型调用把历史对话浓缩成一段摘要并保留最近几轮对话原文。这个流程的平衡点在于压缩触发时机。压缩得太早摘要丢失细节影响用户感知压缩得太晚单次调用成本已经上去了。我的经验是历史Token总量接近上下文窗口的40%时就触发压缩这样压缩动作本身的开销不大同时为后面几轮对话留足了空间。压缩时有一个细节值得注意摘要不能把用户明确表露的偏好信息丢掉。比如用户说过我买东西只考虑顺丰配送这类指令性信息如果被压缩模糊了后续模型就可能在配送方式上犯糊涂。所以在摘要模板里我会专门留一个用户硬性偏好字段确保这类信息原样保留。3.4 Prompt瘦身与系统词精简每一个字都在花你的钱Prompt瘦身是我让所有开发团队都做的一件基础工作。系统提示词里的每个字、每个示例每次模型调用都会原封不动地处理一遍写得多花得多。但瘦身不是简单地删句子而是要区分必要指令和冗余描述。比如作为一个人工智能助手你应该表现得专业、友好、乐于助人这种描述对模型行为几乎没有实际的约束力删掉后效果基本不变却能省掉十几个Token。又比如一个任务只需要模型做分类你却在系统提示词里给了五个复杂的示例这通常可以压缩为一个示例甚至零示例。当然减少示例要谨慎特别是在低规格模型上Few-shot示例往往承担了关键的格式引导作用删过头了输出质量会明显下滑。我的做法是每次瘦身之后跑一遍回归集对比效果用数据说话而不是靠感觉。模型路由同样是成本优化的重要手段这部分我在前面性能章节讲的是延迟优化从成本角度看它省得更明显。一个复杂推理任务用旗舰模型可能花费普通模型几倍的单价而意图识别、文本分类这类简单任务用快模型也能达到同等效果所以在路由上多花的时间会在账单上成倍赚回来。4. 稳定性建设从能响应到一定正确响应稳定性的要求比性能和成本都高因为线上事故会造成信任崩塌。Agent的稳定性问题和其他后端服务不一样它多了模型输出不可控这个巨大的不确定性变量。所以稳定性的重点也和其他服务不同不是靠代码Review就能解决的而是要从模型输出的各个不可控点下手。4.1 拒绝裸JSON一切依赖字符串匹配的系统都在给自己埋雷模型输出格式不稳定是Agent开发里最让人头疼的问题之一。你要求它返回JSON它可能给你包一层Markdown代码块可能前面加一句好的以下是结果,还可能字段名从order_id变成orderId。如果你直接把模型的原始输出扔给json.loads()那生产环境每天都会收获大量解析异常。我处理模型JSON输出的标准做法是四步走。第一步从原始文本中剥离开头结尾的废话定位最外层花括号并截取第二步执行JSON解析第三步校验必填字段是否齐全缺失的用默认值填充或者直接判失败第四步校验不通过时触发一次有限重试重试仍失败就切换降级路径。整个过程封装成一个独立工具函数所有Agent共用。def robust_json_parse(raw_text: str): # 1. 定位最外层JSON块 start raw_text.find({) end raw_text.rfind(}) if start -1 or end -1: raise ParseError(no json block found) candidate raw_text[start:end 1] # 2. 标准解析 data json.loads(candidate) # 3. 字段校验与默认值填充 for field, default in REQUIRED_FIELDS.items(): if field not in data: data[field] default return data如果模型接口本身提供结构化输出能力比如约束模型只能按指定Schema生成的模式我会优先使用。它能把大部分解析问题消灭在源头。但要注意结构化生成在某些高阶推理场景下会缩小模型的有效输出空间导致逻辑能力下降所以我会只对工具调用、实体提取这类强格式任务开启开放式对话保持普通模式。4.2 超时与重试三击原则别在不可能成功的事情上浪费资源模型接口的延迟天然有波动性高峰期尤其明显。如果超时设置不合理系统会在原本就慢的接口上排队等待进一步拖垮整体吞吐。我的做法是按模型分档设置超时时间快模型超时时间短旗舰模型可以给更长一点同时设置快速失败策略一旦任务预计无法在阈值内完成就立刻降级而不是傻等。重试策略也要区分错误类型。限流类错误返回429、503适合指数退避重试间隔逐次拉长网络瞬时抖动可以立即重试一次而参数校验类错误返回400重试多少次都是白费直接走异常处理。给重试设置最大次数上限也很重要一般三次足够再多只会增加系统压力。def call_with_retry(func, max_retries3): for attempt in range(max_retries): try: return func() except RateLimitError as e: if attempt max_retries - 1: raise # 指数退避 随机抖动防止所有请求同时重试形成雪崩 delay 0.5 * (2 ** attempt) random.uniform(0, 0.2) time.sleep(delay) except NetworkTransientError: if attempt max_retries - 1: raise time.sleep(0.1)需要特别提醒的是重试风暴问题。当模型服务出现短暂故障时所有请求都会进入重试循环如果重试节奏一样会对下游形成一波波整齐的冲击。加上随机抖动让重试时间分散开来是我踩过坑之后才加上的保护。4.3 本地规则兜底模型不可用的时候服务不能挂模型服务再稳定也会有计划维护或未知故障的时候。生产级的Agent必须有一条完全不依赖外部模型的兜底链路保证极端情况下用户得到的不是系统错误而是可用的基础服务。这套兜底链路我会设计成一个独立的规则引擎层它能处理Agent场景中最高频出现的意图和问题。比如一个业务咨询Agent通过关键词匹配加模板回答至少能覆盖查营业时间查地址转人工这十几项高频诉求。覆盖率可能不高但足以在故障窗口期保住核心可用性。实测下来我做过的一个项目靠这套规则能在全模型故障时兜住约百分之六十的请求剩下百分之四十也会明确告知用户智能服务暂时不可用以上为预置信息而不是让用户面对一个冰冷的连接失败。4.4 追踪与评估没有观测就没有资格谈稳定稳定性建设最后也必须落回可观测性。很多Agent项目的排障过程异常痛苦原因就是整个调用链是一个黑盒用户问了一句话系统内部到底调了几次模型、调了哪些工具、哪一步产生了错误回答全都无迹可寻。生产级Agent必须从第一天就建立调用链追踪至少记录这些信息请求ID、命中的路由路径、调用的模型名称与版本、输入输出Token数、每步耗时、是否走了降级路径、最终是否正常收敛。有了追踪数据之后还要做评估集回归。我强烈建议每个Agent项目维护一份50到100条的固定评估集包含典型的用户问题、边界问题、风险问题。每次改Prompt、换模型、调路由逻辑之后都拿这份评估集跑一遍对比输出质量和耗时变化。评估维度大概包含这几项评估维度说明判断标准准确性答案是否贴合问题意图与标准答案语义一致完整性关键信息是否遗漏覆盖所有必答点合规性是否出现越权、误导性表述零容忍稳定性同一问题多次回答是否大相径庭语义波动小成本单题平均消耗Token不超预算阈值延迟单题平均响应时长不超体验阈值这个评估表我会放在CI流程里每次变更都触发跑一遍分数下降就不允许上线。这个习惯让我避开了好几次以为优化了实际改坏了的尴尬。5. 调优有优先级我的一次打满全场顺序安排最后把整个调优过程串起来说说动手的顺序。性能、成本、稳定性看起来是三条独立战线实际动手时如果抓不到重点很容易陷入改一步坏一步的循环。按照我自己的经验建议按下面这个顺序来。5.1 先保稳定性再谈性能和成本稳定性是地基地基不稳性能和成本优化都是空中楼阁。比如一个模型输出格式经常解析失败的系统你费劲去压缩Prompt成本结果该花的重试成本反而增加了。所以第一优先级永远是不管效果怎样系统不能出错。先把结构化输出、超时重试、本地兜底、追踪日志这些基础能力补齐确保出了任何幺蛾子都有预案。这一步做完系统才算有了生产级的资格。5.2 再做性能把用户体感拉到一个舒服区间稳定性兜住之后重点转向用户能直接感知的延迟。先做串改并、缓存、模型路由这三件事效果通常最显著。记住一个原则性能优化要瞄准最痛的那一个环节下手不要全面铺开。用追踪数据说话如果大部分请求的瓶颈都卡在模型调用上就先做模型分级如果瓶颈在工具调用上就先做并行化。我还没见过哪个项目的性能瓶颈是平均分布在各个模块里的。5.3 最后挤成本用评估集守护调优成果等稳定性和性能都达标再动手压成本。成本优化的每一步都可能轻微影响效果所以每完成一步都必须跑评估集验证质量没有下滑。在我的实践里模型路由和记忆压缩是省钱效果最明显的两个动作而Prompt瘦身则是性价比最高的收尾工作。做完全部优化后我通常会把评估集跑一遍确认各项指标都在可接受范围内然后把新的成本基线和延迟基线记录下来作为后续迭代的对照。调优做完并不是终点。Agent上线后每天都会产生新的真实对话数据我会定期抽一批差评或异常案例补充进评估集再跑回归看是否出现新的问题。生产级调优是个持续迭代的慢功夫但只要链路可观测、评估可量化、兜底够可靠这个系统就会越用越稳越用越省钱。
把Agent从Demo搬到生产环境是我见过翻车率最高的一步。功能明明早就跑通了演示时也足够惊艳结果一上真实流量要么回答变得又慢又呆要么账单一个月暴涨几十倍要么上线第二天就冒出一堆答非所问的事故。性能、成本、稳定性这三件事任何一个炸了Agent项目都会瞬间失去信任。这篇文章就把我在生产环境里做Agent生产级调优时踩过的坑和总结出的套路完整写一遍适合那些已经跑通Agent原型、准备推向生产或者正在被线上各种疑难杂症折磨的开发者参考。1. 为什么Demo跑得通一上生产就原形毕露——先弄明白调优到底在调什么很多人以为Agent调优就是改改Prompt、换换模型这是最大的误解。Demo阶段你面对的是自己精心设计的输入用户量是几个人模型调用失败了你手动重试一次就行延迟慢了你也不觉得有什么问题。可一旦进入生产环境这三件事会同时变质。1.1 链式调用里的概率乘法看起来很稳的系统其实很脆先算一笔账。假设你的Agent单次任务平均要调用4次模型接口单次调用的成功率是95%这个数值在真实环境下已经算不错了那整条链路的最终成功率是多少0.95的4次方约等于81.5%。也就是说大约五分之一的任务会以某种方式失败。而Demo阶段你根本感知不到这个问题因为你自己试的时候失败了重新跑一次就行用户可没有这个耐心。更要命的是错误放大效应。一次工具调用返回了非预期格式模型看到错乱数据后可能继续往下编编出来的答案又成了下一次调用的上下文。这种级联式的错误在每个环节都会被放大一点点最后呈现给用户的就是一个完全离谱的答案。生产环境里没有重试一次就好这种操作你必须假设每一环都可能出错并且提前想好出错后往哪里走。1.2 延迟与Token成本Demo里不被感知的东西生产环境全是钱还有一个容易被忽略的事实模型推理是按Token收费的而且输出Token的价格通常比输入Token更贵。在Demo阶段你调几次模型一个月也就几十块钱没人会心疼。可上线后一分钟几十个请求的QPS下Prompt里多写三百个字一个月可能就多烧掉一台服务器的钱。延迟也一样。本地调试时模型响应两秒钟你完全没感觉但用户侧加上网络传输、工具调用、渲染时间一个Agent任务跑到十秒以上流失率会成倍上升。我见过很多团队把Agent的Prompt调得花里胡哨把系统提示词写成了几千字的说明书结果线上日志里全是延迟告警因为每次调用都要把这几千字重新处理一遍。1.3 生产级调优的三个核心矛盾说了这么多其实生产级调优本质上是在处理三个矛盾。第一个是效果与成本的矛盾。模型越大效果通常越好但Token单价也越高如何在几乎不损失效果的前提下用更小的模型或更短的Prompt完成任务。第二个是延迟与质量的矛盾。串行调用多个工具会得到更完整的信息但时间会翻倍并行调用能缩短延迟但需要处理部分结果缺失的情况。第三个是个性化与稳定性的矛盾。为了让用户觉得这个Agent懂我你会让模型更自由地发挥但自由度越高输出格式和内容就越不可控。理解了这三个矛盾再看后面的优化方案就会清楚很多每一次调优其实都是在矛盾的某个平衡点上做取舍。下面我按性能、成本、稳定性三个维度分别展开。2. 性能攻坚把能用的Agent改造成好用的Agent性能调优不是简单换一台高配服务器就能解决的瓶颈往往出在调用的编排方式上。我自己在优化Agent的过程中最见效的动作几乎都集中在这一块。2.1 串行改并行能同时进行的调用绝不排队等待Agent的决策链路里很多模型调用和工具调用之间根本没有依赖关系但在最开始的实现里它们往往被写成了串行。举个例子一个购买咨询Agent收到我想买XX有货吗多少钱明天能送到吗这样一条请求需要同时查库存、查价格、查物流时效这三个查询之间没有任何依赖关系。如果串行执行假设每个工具耗时2秒完成需要累计6秒再去调一次模型做汇总又是2秒总共8秒。改成并行后三个查询2秒内全部返回加上模型汇总的2秒总共4秒。这一个改动就把延迟砍掉了一半。我最初接手某个项目的时候也是串行逻辑排查线上问题时发现模型一次决策里往往要连续调四到五次工具每一次都是老老实实等前一个返回再发起下一个。后来把无依赖的调用全部放进并发池平均延迟直接从十几秒降到了五秒以内。# 串行模式总耗时约等于所有子任务耗时之和 results [] for tool_fn in [get_user_profile, get_product_stock, get_current_price]: r tool_fn(user_id, product_id) results.append(r) # 并行模式总耗时约等于最慢的那个子任务 import asyncio async def fetch_all(): return await asyncio.gather( get_user_profile(user_id), get_product_stock(product_id), get_current_price(product_id) )不过并行也不是无脑开有两个坑要提醒一下。第一并发度别拉太高尤其是外部工具接口通常有QPS限制瞬时把所有请求打出去容易触发限流反而变成另一种延迟。第二并行会提升瞬时Token消耗因为多个模型调用是同时发出的如果你的账号有速率限制需要在并发池里加一个信号量做控制。2.2 结果缓存与语义缓存同样的请求不要反复让模型烧钱性能优化里最划算的事情就是让模型少干活。Agent的线上请求里有相当一部分是重复或高度相似的比如用户反复问同一个产品的价格、同一种业务的办理条件。这些请求完全没必要每次都重新走一遍模型调用。缓存分两个层级。第一层是精确缓存也就是完全相同的输入直接命中。这里有个关键细节不要拿完整的Prompt做缓存键而是要拿归一化后的用户意图做缓存键。比如把灯打开和帮我开一下灯字面不同但意图归一化之后都应该是同一个动作指令。用我的做法大概是这样def build_cache_key(user_query: str) - str: # 先剥离语气词、重复词做同义改写 normalized_query normalize(user_query) # 再用一个轻量意图分类器判断意图 intent lightweight_intent_classifier(normalized_query) # 关键信息抽出后拼成稳定键 return f{intent}:{extract_entities(normalized_query)}第二层是语义缓存适合那些表述千变万化但答案高度稳定的查询。实现思路是把用户Query向量化然后用余弦相似度去历史缓存里找最接近的一条相似度超过阈值就直接复用缓存结果。这里阈值很关键设得太高缓存命中率低设得太低会返回不相关的答案。我调过的经验值是0.92到0.95之间需要根据自己的业务数据反复试。还要强调一下缓存不是所有场景都适用。比如帮我写个方案这种开放式创作类请求语义缓存很可能给出陈旧答案用户会明显感觉到敷衍。这类请求要主动绕过缓存。2.3 模型分级与降级路径快慢模型切换的调度策略生产环境里所有的请求都塞给同一个大模型这是有钱任性的做法不是合理的架构。更好的设计是做一个模型路由层根据任务复杂度把请求分发到不同规格的模型上。我常用的分层是三层第一层是本地轻量规则处理完全确定性的任务第二层是响应快、价格低的模型处理意图识别、实体抽取、简单问答第三层才是旗舰大模型只处理复杂推理、多步规划、长文本生成等高难度请求。实际实现时路由判断本身也要花时间所以通常用一个又快又便宜的分类模型来承担这个职责。它会先判断任务类型然后决定走哪条路径def route_task(task_description: str): task_type quick_classifier(task_description) if task_type in RULE_COVERED_TASKS: # 本地规则能处理零成本 return run_local_rules(task_description) elif task_type in SIMPLE_INFERENCE_TASKS: # 快模型路径 return call_model(fast_cheap_model, task_description) else: # 旗舰模型路径 return call_model(top_performance_model, task_description)降级路径同样重要。线上调用旗舰模型如果超时或返回错误不能直接给用户报错而是应该立即切换到一个稍小但对当前任务仍然可用的模型给出一个能用但不完美的答案。我在实际项目中遇到过多次这种场景旗舰模型因为平台侧负载过高导致响应超时降级到快模型后虽然推理深度弱了一些但至少用户没有拿到系统错误。这条降级路径如果没做一次模型服务波动就是一次线上事故。2.4 结构化输出与显式Token预算模型的生成是逐Token产出的所以控制输出长度直接决定了生成时延。很多人只在Prompt里要求请简洁回答模型对这个词的理解非常弹性该啰嗦还是会啰嗦。更好的做法是给显式约束比如你的答案不超过200字只输出JSON格式不要任何解释性文字。这些显式约束对模型来说是硬指令能明显压缩输出Token数。结构化输出的要求也一样。让模型返回JSON时必须给出清晰的字段定义和取值范围而不是只说返回JSON。比如你需要一个工具调用的JSON应该定义好工具名、参数对象、以及参数的可选值。模型拿到精确的Schema定义后输出的规范性会大幅提升后续解析的稳定性也会好很多。做Agent时我还会额外让模型在拿不准参数时返回null而不是编造一个值这个细节让我少排查了好几次诡异的问题。3. 成本治理把Token花费压到合理线但不能牺牲效果成本治理和性能优化是相伴的很多性能手段做完了之后成本也会同步下降。但成本还有自己独立的优化维度尤其在生产环境中Token消耗是线性增长的东西不做治理绝对会失控。3.1 先搞清楚钱花在哪儿历史膨胀是一个容易被忽视的隐形杀手不少人以为Agent成本的主要花费是每次调用的Prompt其实对对话类Agent来说真正的大头是不断膨胀的历史上下文。每轮对话你都需要把之前的全部历史重新发给模型一次两次还好聊到二十轮的时候每次调用都背负着前面十九轮的Token成本。这个开销随对话次数呈近似平方级增长是典型的历史膨胀问题。我见过一个账单爆炸的真实案例某Agent上线后单日活跃用户只有几千账面成本却高得离谱。排查后发现根因就是历史消息全量回传加上有些环节还把大段工具返回原文塞进了上下文导致单次调用动不动就消耗几万Token。成本治理的第一步必须是给进上下文的内容做审计每一条数据问一句自己模型真的需要它吗这里给一个简单的成本测算模型供参考。假设你用的是按量计费的模型接口输入Token和输出Token单价不同那么单次调用的成本约等于输入Token数 × 输入单价 输出Token数 × 输出单价。如果平均每次调用消耗输入Token 3000、输出Token 500一个月调用10万次代入单价之后很容易算出这是一笔不可忽略的开支。把历史从全量保留改为压缩摘要之后输入Token经常能压缩掉60%-80%成本下降立竿见影。3.2 调用轮次上限防止Agent过度思考Agent和普通问答最大的区别在于它会自行决定调用工具的次数。设计Agent时如果你给它你可以反复调用工具直到完成任务这种自由度它在复杂任务中确实能体现出优势但也非常容易陷入过度思考一轮又一轮地调用工具确认信息迟迟不给结论。生产环境里必须给Agent的决策循环设置硬性上限。我的习惯是控制在3到5步达到上限后Agent会被强制停止新的工具调用并基于已获取的信息直接给出答案。这么做还有一个额外收益它逼着模型在有限步数内更高效地决策反而减少了无意义的验证动作。步数限制最好放在系统提示词里显式声明同时把剩余步数也动态注入到每一轮上下文里让模型感知到我再不收敛就没机会了。比如注入一句当前已执行4次工具调用最多还有1次操作机会请直接回答用户问题模型通常会立刻收敛。3.3 记忆压缩与上下文缩编把长对话改成摘要既然历史膨胀是成本大头那记忆压缩就必须做。我的做法是在对话管理模块里维护一个会话状态记录当对话历史超过一定阈值时触发一次摘要压缩——用一次额外的模型调用把历史对话浓缩成一段摘要并保留最近几轮对话原文。这个流程的平衡点在于压缩触发时机。压缩得太早摘要丢失细节影响用户感知压缩得太晚单次调用成本已经上去了。我的经验是历史Token总量接近上下文窗口的40%时就触发压缩这样压缩动作本身的开销不大同时为后面几轮对话留足了空间。压缩时有一个细节值得注意摘要不能把用户明确表露的偏好信息丢掉。比如用户说过我买东西只考虑顺丰配送这类指令性信息如果被压缩模糊了后续模型就可能在配送方式上犯糊涂。所以在摘要模板里我会专门留一个用户硬性偏好字段确保这类信息原样保留。3.4 Prompt瘦身与系统词精简每一个字都在花你的钱Prompt瘦身是我让所有开发团队都做的一件基础工作。系统提示词里的每个字、每个示例每次模型调用都会原封不动地处理一遍写得多花得多。但瘦身不是简单地删句子而是要区分必要指令和冗余描述。比如作为一个人工智能助手你应该表现得专业、友好、乐于助人这种描述对模型行为几乎没有实际的约束力删掉后效果基本不变却能省掉十几个Token。又比如一个任务只需要模型做分类你却在系统提示词里给了五个复杂的示例这通常可以压缩为一个示例甚至零示例。当然减少示例要谨慎特别是在低规格模型上Few-shot示例往往承担了关键的格式引导作用删过头了输出质量会明显下滑。我的做法是每次瘦身之后跑一遍回归集对比效果用数据说话而不是靠感觉。模型路由同样是成本优化的重要手段这部分我在前面性能章节讲的是延迟优化从成本角度看它省得更明显。一个复杂推理任务用旗舰模型可能花费普通模型几倍的单价而意图识别、文本分类这类简单任务用快模型也能达到同等效果所以在路由上多花的时间会在账单上成倍赚回来。4. 稳定性建设从能响应到一定正确响应稳定性的要求比性能和成本都高因为线上事故会造成信任崩塌。Agent的稳定性问题和其他后端服务不一样它多了模型输出不可控这个巨大的不确定性变量。所以稳定性的重点也和其他服务不同不是靠代码Review就能解决的而是要从模型输出的各个不可控点下手。4.1 拒绝裸JSON一切依赖字符串匹配的系统都在给自己埋雷模型输出格式不稳定是Agent开发里最让人头疼的问题之一。你要求它返回JSON它可能给你包一层Markdown代码块可能前面加一句好的以下是结果,还可能字段名从order_id变成orderId。如果你直接把模型的原始输出扔给json.loads()那生产环境每天都会收获大量解析异常。我处理模型JSON输出的标准做法是四步走。第一步从原始文本中剥离开头结尾的废话定位最外层花括号并截取第二步执行JSON解析第三步校验必填字段是否齐全缺失的用默认值填充或者直接判失败第四步校验不通过时触发一次有限重试重试仍失败就切换降级路径。整个过程封装成一个独立工具函数所有Agent共用。def robust_json_parse(raw_text: str): # 1. 定位最外层JSON块 start raw_text.find({) end raw_text.rfind(}) if start -1 or end -1: raise ParseError(no json block found) candidate raw_text[start:end 1] # 2. 标准解析 data json.loads(candidate) # 3. 字段校验与默认值填充 for field, default in REQUIRED_FIELDS.items(): if field not in data: data[field] default return data如果模型接口本身提供结构化输出能力比如约束模型只能按指定Schema生成的模式我会优先使用。它能把大部分解析问题消灭在源头。但要注意结构化生成在某些高阶推理场景下会缩小模型的有效输出空间导致逻辑能力下降所以我会只对工具调用、实体提取这类强格式任务开启开放式对话保持普通模式。4.2 超时与重试三击原则别在不可能成功的事情上浪费资源模型接口的延迟天然有波动性高峰期尤其明显。如果超时设置不合理系统会在原本就慢的接口上排队等待进一步拖垮整体吞吐。我的做法是按模型分档设置超时时间快模型超时时间短旗舰模型可以给更长一点同时设置快速失败策略一旦任务预计无法在阈值内完成就立刻降级而不是傻等。重试策略也要区分错误类型。限流类错误返回429、503适合指数退避重试间隔逐次拉长网络瞬时抖动可以立即重试一次而参数校验类错误返回400重试多少次都是白费直接走异常处理。给重试设置最大次数上限也很重要一般三次足够再多只会增加系统压力。def call_with_retry(func, max_retries3): for attempt in range(max_retries): try: return func() except RateLimitError as e: if attempt max_retries - 1: raise # 指数退避 随机抖动防止所有请求同时重试形成雪崩 delay 0.5 * (2 ** attempt) random.uniform(0, 0.2) time.sleep(delay) except NetworkTransientError: if attempt max_retries - 1: raise time.sleep(0.1)需要特别提醒的是重试风暴问题。当模型服务出现短暂故障时所有请求都会进入重试循环如果重试节奏一样会对下游形成一波波整齐的冲击。加上随机抖动让重试时间分散开来是我踩过坑之后才加上的保护。4.3 本地规则兜底模型不可用的时候服务不能挂模型服务再稳定也会有计划维护或未知故障的时候。生产级的Agent必须有一条完全不依赖外部模型的兜底链路保证极端情况下用户得到的不是系统错误而是可用的基础服务。这套兜底链路我会设计成一个独立的规则引擎层它能处理Agent场景中最高频出现的意图和问题。比如一个业务咨询Agent通过关键词匹配加模板回答至少能覆盖查营业时间查地址转人工这十几项高频诉求。覆盖率可能不高但足以在故障窗口期保住核心可用性。实测下来我做过的一个项目靠这套规则能在全模型故障时兜住约百分之六十的请求剩下百分之四十也会明确告知用户智能服务暂时不可用以上为预置信息而不是让用户面对一个冰冷的连接失败。4.4 追踪与评估没有观测就没有资格谈稳定稳定性建设最后也必须落回可观测性。很多Agent项目的排障过程异常痛苦原因就是整个调用链是一个黑盒用户问了一句话系统内部到底调了几次模型、调了哪些工具、哪一步产生了错误回答全都无迹可寻。生产级Agent必须从第一天就建立调用链追踪至少记录这些信息请求ID、命中的路由路径、调用的模型名称与版本、输入输出Token数、每步耗时、是否走了降级路径、最终是否正常收敛。有了追踪数据之后还要做评估集回归。我强烈建议每个Agent项目维护一份50到100条的固定评估集包含典型的用户问题、边界问题、风险问题。每次改Prompt、换模型、调路由逻辑之后都拿这份评估集跑一遍对比输出质量和耗时变化。评估维度大概包含这几项评估维度说明判断标准准确性答案是否贴合问题意图与标准答案语义一致完整性关键信息是否遗漏覆盖所有必答点合规性是否出现越权、误导性表述零容忍稳定性同一问题多次回答是否大相径庭语义波动小成本单题平均消耗Token不超预算阈值延迟单题平均响应时长不超体验阈值这个评估表我会放在CI流程里每次变更都触发跑一遍分数下降就不允许上线。这个习惯让我避开了好几次以为优化了实际改坏了的尴尬。5. 调优有优先级我的一次打满全场顺序安排最后把整个调优过程串起来说说动手的顺序。性能、成本、稳定性看起来是三条独立战线实际动手时如果抓不到重点很容易陷入改一步坏一步的循环。按照我自己的经验建议按下面这个顺序来。5.1 先保稳定性再谈性能和成本稳定性是地基地基不稳性能和成本优化都是空中楼阁。比如一个模型输出格式经常解析失败的系统你费劲去压缩Prompt成本结果该花的重试成本反而增加了。所以第一优先级永远是不管效果怎样系统不能出错。先把结构化输出、超时重试、本地兜底、追踪日志这些基础能力补齐确保出了任何幺蛾子都有预案。这一步做完系统才算有了生产级的资格。5.2 再做性能把用户体感拉到一个舒服区间稳定性兜住之后重点转向用户能直接感知的延迟。先做串改并、缓存、模型路由这三件事效果通常最显著。记住一个原则性能优化要瞄准最痛的那一个环节下手不要全面铺开。用追踪数据说话如果大部分请求的瓶颈都卡在模型调用上就先做模型分级如果瓶颈在工具调用上就先做并行化。我还没见过哪个项目的性能瓶颈是平均分布在各个模块里的。5.3 最后挤成本用评估集守护调优成果等稳定性和性能都达标再动手压成本。成本优化的每一步都可能轻微影响效果所以每完成一步都必须跑评估集验证质量没有下滑。在我的实践里模型路由和记忆压缩是省钱效果最明显的两个动作而Prompt瘦身则是性价比最高的收尾工作。做完全部优化后我通常会把评估集跑一遍确认各项指标都在可接受范围内然后把新的成本基线和延迟基线记录下来作为后续迭代的对照。调优做完并不是终点。Agent上线后每天都会产生新的真实对话数据我会定期抽一批差评或异常案例补充进评估集再跑回归看是否出现新的问题。生产级调优是个持续迭代的慢功夫但只要链路可观测、评估可量化、兜底够可靠这个系统就会越用越稳越用越省钱。
