做 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_rounds=5): 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 做一次体检。真正要盯的不是单条回答有多好，而是任务链路能不能稳定走完。先积累评估集和跑批工具，以后换任何模型，都能少踩一半坑。
