做 Agent 评估最容易犯的错误是把“换模型”当成“换 API 地址”。这次从 sonnet 切到 deepseek v4 flash我真正花时间的不是修改接入代码而是把评估集、评估指标和跑批流程重新对齐了一遍。这篇文章适合正在做 Agent 选型、模型切换、质量评估的开发者和算法同学。最值得关注的不是某个模型更强而是怎么在统一口径下判断它到底能不能进入生产环境。一个 Agent 项目里模型替换牵扯的东西比普通模型评测要多得多。你要保证工具调用能被解析、多轮任务能走完、结构化输出能落到下游代码里、延迟和成本还在预算内。下面按我实际操作的顺序拆开讲。1. 给 Agent 做模型切换评估先拆清楚“评估什么”1.1 Agent 评估和普通模型评测不是一回事普通模型评测通常是给一个输入让模型直接输出答案然后用准确率、BLEU、Rouge 这些指标打分。到了 Agent 场景这套方法就不够用了。Agent 不是只回答一次。它要先理解任务再决定调用哪些工具工具返回之后还要继续分析可能再调用下一轮最后才给出结果。整个链路里任一步出错任务就失败。哪怕模型“说话”很流畅只要工具调用参数写错或者两步之间逻辑接不上最后的结果依然不可用。所以给 Agent 做模型切换评估核心不是测“谁的回答更像人”而是测“谁能在同一套工具和提示词下面稳定地把任务跑完”。这个差异很关键。之前我好几次看到有人直接拿通用评测集的题目去测 Agent测出来分数差不多但一旦接上真实工具差异马上拉开。1.2 从 sonnet 切到 deepseek v4 flash对比的指标要有侧重点在这次的切换中我建了一张指标表一开始就定了对比维度。不然跑完一轮数据很多但你根本不知道应该看什么。指标怎么判断为什么关键任务完成率每条任务是否走到预期结束状态最直接的 Agent 能力体现工具调用成功率模型返回的工具名和参数能否被正确解析执行Agent 和普通问答的核心区别结构化输出合格率输出 JSON、字段、类型是否能直接消费决定下游代码要不要加大量兜底延迟单条任务从发起到结束的时间影响用户体验和队列占用token 成本一条任务平均消耗的输入/输出 token决定切换后预算是否可控异常率超时、死循环、重复调用、截断等生产可用性的底线这些指标不能只看平均数还要看分布。尤其是工具调用成功率和异常率如果一批任务里反复出现同一种异常就要先排查不能被整体平均分掩盖。我还会加一个“后处理修正率”作为参考模型第一次输出不合法需要程序修正后才能继续执行的占比。这个指标高说明当前模型并不真正适配你的 Agent 结构只是被代码兜住了。2. 评估集和评估脚本没有统一入口就是白测2.1 评估集要从真实业务里长出来第一个建议是不要自己去编一堆“有挑战性”的任务。容易编偏。更可靠的做法是从线上日志里抽真实用户问题先做脱敏再按业务类型分类。比如我们这个项目里有几类普通信息查询需要调用内部工具查询数据需要连续调用多个工具完成链路用户输入模糊需要主动澄清输入明显有误需要拒绝或校验每类至少准备 5 到 10 条总共 50 到 100 条比较合适。不要一上来就准备 1000 条。Agent 评估的标注成本比普通模型高很多。每条任务都要写“预期动作”和“预期结果”还要人工核对模型走的过程。50 到 100 条已经能看出大部分方向性问题。如果评估集不方便从日志截取可以先从团队成员日常维护的测试用例里挑。但一定要尽量贴近线上真实输入。否则结果只能说明模型在“你给的任务”上表现好不能说明它在业务里表现好。如果你的 Agent 主要依赖 RAG也可以参考 ragas 这类开源评估工具的思路先评估检索质量。但完整 Agent 的评估不能停留在检索必须落到任务执行链路。2.2 统一输入输出两个模型必须跑同一套通道切换评估最忌讳的就是模型 A 用一套 prompt模型 B 用另一套。这样拿到结果根本没有可比性。我在这次评估里不管底层接的是 sonnet 还是 deepseek v4 flash都走同一个 Agent Runner 入口。系统提示词、工具描述、任务输入、超时策略都保持一致。唯一变的只是模型配置。输出也要统一成一种记录格式把每个任务的关键信息全部落下来{ task_id: T001, model: deepseek-v4-flash, prompt_version: v2.3, tool_calls: [ {name: query_sales, arguments: {date: 2025-06-01}} ], final_answer: 当日销售额为 ..., input_tokens: 1280, output_tokens: 610, latency_ms: 3820, error: null }这样后面无论是算平均指标还是定位某条失败任务都能直接查原始记录。2.3 用一套轻量 harness 跑批而不是每次手点Agent 评估的关键是“可重复”。所以我建议把跑批脚本沉淀成一个小工具而不是每次手点。早期没有统一脚本时问题特别多不同人跑出来的结果不是同一批 prompt、输出没有存原始日志、失败之后重试规则不一致。后来我写了一个很轻量的评估 runner逻辑不复杂def run_agent_eval(tasks, model_config, max_rounds5): records [] for task in tasks: record run_single_task(task, model_config, max_rounds) records.append(record) save(record) return records核心不是代码复杂度而是以下几点失败任务不能跳过要记录 error 信息每条任务限制最大轮数防止死循环结果写入本地文件或数据库方便后续分组统计跑批前记录评估集 hash 和 prompt 版本保证可回溯注意跑批前先确认评估集 hash 和 prompt 版本都固定了否则结果不可比。跑批时我不建议一开始就开高并发。先用单线程跑一遍确认输出和日志都正常再考虑并发。并发一开日志顺序会很乱后面排查会很痛苦。3. 单任务先跑通再跑批量从 sonnet 切到 deepseek v4 flash 的最小验证路径3.1 先拿单任务验证连通性切换模型前不要直接跑 100 条。先从一条最简单的任务开始比如调用一个返回固定信息的工具。这一步的目的是把“接口能不能通”这个基础问题确认掉。常见注意点model 名称要准确。不同 API 网关对模型标识的要求不一样接入 deepseek v4 flash 时要以你拿到的配置为准。鉴权 header 不要写死到业务代码里最好通过环境变量或配置中心下发。超时参数要合理。Agent 任务多轮调用单次请求超时和整条任务超时要分开设置。如果连单条任务都一直报错不要怀疑模型能力先看报错信息里的状态码和原始响应体。很多问题其实只是参数名没对上。我一般会用一条“当前时间查询”或“固定结果查询”来验证。它不涉及复杂链路能最快暴露接口层问题。3.2 用 30 条小样本做冒烟测试连通之后我会先跑 30 条左右的小样本而不是立刻全量跑批。小样本的目的不是得出最终结论而是快速判断方向。跑完后不要只看通过率。要一条一条翻原始输出。我一般会重点看三类失败工具调用返回了但参数解析失败模型一路用自然语言解释但没有真正执行工具任务进入循环反复调用同一个工具拿不到结果这三类问题如果在小样本阶段出现超过几次就不是偶发应该先处理 prompt、工具描述或者模型参数而不是继续跑全量。小样本冒烟只用来判断方向不要拿它当最终结论。3.3 全量跑批生成本次切换评估报告小样本身边看边改改到没有明显方向性问题后再固定评估集和 prompt 版本跑全量。全量跑批时要注意两个模型最好在同一个时间段内跑避免线上工具返回结果变化影响对比跑批时把 temperature 调成同一个值建议从 0 或低温度开始记录开始时间、结束时间、评估集 hash、prompt 版本跑完直接生成一个对比报告把每个任务两个模型的结果放在一起看生成对比报告时我会先看“两个模型都不对”和“只有一个模型对”的任务。前者可能是任务本身标注有问题后者才是模型差异的体现。如果两个模型在同一批任务上错得都一样先检查任务本身的预期结果是不是写错了。4. 从结果数据判断“能不能切”完成率、成本、延迟怎么取舍4.1 先看工具调用和结构化输出Agent 场景里模型返回的如果是一段漂亮的自然语言但没有可执行的结构化动作这个结果对系统来说几乎没用。所以我评估时会单独算两个比例工具调用解析率结构化输出合格率工具调用解析可以用一个很朴素的函数来校验def is_valid_tool_call(raw): if not isinstance(raw, dict): return False if not isinstance(raw.get(name), str): return False args raw.get(arguments) if not isinstance(args, dict): return False return True只要程序没能解析出合法的 tool_call就会计入失败。如果 deepseek v4 flash 在这个指标上明显低于 sonnet别急着下结论。先看它是在哪一类任务上失分。有时是工具描述写得不够清楚有时是参数 schema 太复杂。换一个更清晰的描述结果可能就明显改善。4.2 成本不是只算单次请求很多模型切换评估把成本算得太简单只看一次请求的 token 价格。到了 Agent 场景这个算法很容易失真。Agent 任务通常要多个回合。一个简单查询可能只要 2 轮复杂任务可能要到 5 到 8 轮。实际成本应该是单任务成本 每轮输入 token 之和 × 输入单价 每轮输出 token 之和 × 输出单价评估时我会在记录里保存每个任务的总 token 和总轮次最后分别求平均。对比表格可以这样列模型任务完成率平均轮次平均输入 token平均输出 token平均单任务延迟估算成本sonnet本次实测值本次实测值本次实测值本次实测值本次实测值按实际单价算deepseek v4 flash本次实测值本次实测值本次实测值本次实测值本次实测值按实际单价算不要直接抄我这张表里的结论因为模型价格和评估任务差异太大但可以按这个结构去统计。除了平均成本还要关注异常成本。比如某个任务因为模型死循环连续调了 20 次工具token 消耗可能是一个正常任务的 5 倍以上。这种异常任务会直接影响月末账单。4.3 给“可以切换”定一个自己的阈值评估完成后真正难的是拍板。我的习惯是先定底线再看分数任务完成率不能比原模型低超过 3 到 5 个百分点工具调用解析失败率不能超过 1% 到 2%单任务 P95 延迟不能超过线上可接受上限成本即使上升也要在预算范围内异常率越低越好一旦有循环或者超时必须能兜底这些阈值是参考。不同业务差异很大客服场景更看重延迟后台自动化任务更看重成本和稳定性。定阈值有个好处不会因为某个模型在某条任务上表现特别好就忽略整体风险。如果一个模型完成率只低 1 个点但异常率明显更低我会更倾向选择它。因为生产环境里稳定兜底比偶发的“超水平发挥”更值钱。5. 常见坑与排查链路输出解析、超时、上下文、并发5.1 模型回复了但 Agent 没有执行这是切换模型后最常见的现象。表面上看两个模型都“回答”了。但 Agent 执行起来一个正常执行另一个根本没走到工具调用。问题往往出在工具调用的返回结构上。不同模型 API 的返回字段可能有差异有的把工具调用放在顶层字段有的嵌套在其他结构里。排查顺序建议先看原始返回体确认 tool_calls 是否存在再看自己解析逻辑用的字段名和返回体结构是否一致再看工具描述是否有特殊字符或 schema 与模型不兼容最后看执行器日志确认工具调用有没有真正触发不要一开始就改系统提示词。很多“解析失败”不是模型不会而是代码只兼容了原来模型的返回结构。5.2 同一条任务多次结果不一致这个问题很容易让人误判成“新模型不稳定”。需要先确认一个参数temperature。如果两个模型默认值不一样结果差异会很大。评估时最好把 temperature 固定成同一个值想做严格对比时可以先设 0。如果温度已经固定多次结果仍然不稳定那就要看任务本身。比如用户输入本身有歧义或者工具返回内容不完整。这种情况下两条不同结果可能都有一定合理性不能简单说谁对谁错。评估记录里最好把模型原始回复都保留。这样出现不一致时可以对比具体是哪一步开始分叉。5.3 上下文太长被截断关键信息后段丢失Agent 多轮任务很容易把上下文撑大。尤其是一些工具返回内容很多的场景比如查询大列表、读取长文档、拉取报表数据。模型上下文有上限。一旦超过可能有几种表现直接报错、截断前文、只保留最后的对话但是丢失早期工具结果、输出质量突然下降。排查时先看请求里实际发送的 token 数。很多日志系统只记录了用户输入长度没有记录工具返回拼接后的长度。Agent 场景里工具返回往往是上下文膨胀的主因。处理思路一般有几种对大的工具返回做摘要而不是全量塞进上下文清理无用的历史轮次只保留关键结果扩大模型上下文窗口但要注意成本会上升把长内容落到外部存储只传引用信息给模型这类问题在 sonnet 上可能不明显换成 deepseek v4 flash 后突然变多不一定是模型理解能力变差很可能是两个模型对超长上下文的处理策略不同。5.4 批量跑批出现超时、限流、OOM全量跑批时最容易踩的是资源问题。先看单请求耗时。如果单请求已经要 10 秒并发开到 10资源消耗就会急剧上升。Agent 一个任务可能调用多个工具也就是多次请求所以真正要关注的是“单任务耗时”而不是“单次请求耗时”。遇到限流或 5xx先做退避重试不要继续加并发。遇到限流先退避重试不要继续加并发。如果本地跑批内存占用高常见原因是把每个任务的完整日志都堆在内存里再统一写入。更好的做法是每跑完一条任务就立即写入文件或数据库只保留最近几条在内存里。超时还需要区分“单次模型请求超时”和“整条任务超时”。我一般会给单次请求设置一个较长的超时给整条任务设置最大轮数和总时长上限避免一个失败任务挂住整个队列。如果任务日志里出现了类似agent execution terminated due to error的结束原因先看是不是最大轮数触顶再继续追具体在哪一步报错。6. 切到生产环境的几步灰度、监控、回滚6.1 灰度先让一小部分流量替大家踩坑评估结果再好看也不能直接全量切。更稳妥的做法是先把新模型挂在灰度开关后面。比如只对内部测试账号开放或者只放 5% 的流量。灰度期间不要同时改其他东西。如果同一时间既换了模型又改了工具描述又改了流程脚本后面出了问题根本说不清是谁引起的。灰度期间不要同时改其他东西。灰度范围可以慢慢放大5% → 20% → 50% → 100%。每一步都观察一段时间不要只跑半小时就放大。如果项目有平台层配置建议把模型名、temperature、max_rounds 这些都做成可动态配置的项。这样灰度时只需要改配置不需要重新发布代码。6.2 监控Agent 层和生产层指标要分开看常规 API 监控只能看到请求状态码和延迟看不到 Agent 是否真的把任务完成了。所以最好在建监控时加几类 Agent 层指标整体完成率平均轮次工具调用失败率异常结束原因分布超时、循环、解析失败、用户取消等每类任务的完成率变化日志里一定要带 model 标识。没有模型标识线上对比就无从谈起。同一个任务 ID 的全过程日志也要能串联起来方便从用户请求追到每一步工具调用。6.3 回滚先把服务恢复再追原因最后一个建议是回滚动作要足够快。我见过不少团队在灰度发现问题时第一反应是打开日志分析原因结果用户持续受影响。更合理的顺序是先切回旧模型等服务恢复再回头从日志和评估数据里找问题。回滚开关最好提前放到配置中心避免临时改代码发布。切回旧模型后再把新旧两个模型这段时间的日志拉到一起对比确认是不是新模型导致的问题。如果确认不是可以再进入下一轮灰度。切模型不是换一行配置更像是给 Agent 做一次体检。真正要盯的不是单条回答有多好而是任务链路能不能稳定走完。先积累评估集和跑批工具以后换任何模型都能少踩一半坑。