Agent评估实战：从Sonnet切换至DeepSeek，成本降10倍

引言：一次能省下十倍成本的模型切换

在生产环境中运行的AI Agent，往往默认使用最强、最贵的模型。但这真的必要吗？在LLM评估系列的第三期实战中，UP主聚焦于一个核心问题：能否将一个已投产的Agent从昂贵的Claude Sonnet降级到更便宜的DeepSeek，同时不损失任务质量？

结论令人振奋——通过系统化的评估流程，最终成功切换到DeepSeek V4 Flash正式版（0731），在绝大多数场景中与原本的Sonnet 5表现相当，仅在极少数场景略有逊色，却带来了十倍以上的成本下降。这不仅是一次模型替换，更展示了「评估」这一工程方向所蕴含的巨大成本节约潜力。

本文将拆解这次评估的完整方法论，涵盖业务场景、五件套框架、环境设计的关键抉择，以及分层打分器的精细设计。

业务场景：确定性的CI根因分析Agent

本次评估的对象是一个投产的Agent，其任务是分析代码仓库CI任务失败的根因，并决策是否需要重试。这是一个典型的确定性任务——虽然Agent通常具备通用性，但在这个场景中，我们只需要它做好一件事。

两个典型使用场景很好地说明了它的职责：

• 无需重试的场景：Agent在CI日志中发现Jest测试框架的快照（snapshot）不匹配导致失败。由于代码和快照未变化，重试仍会失败，因此不应触发重试。
• 需要重试的场景：Agent发现日志中出现拉取远端镜像时的connection reset网络错误，判断根因为网络抖动，此时应触发一次重试。

这样的Agent能显著提升研发效率——研发人员无需自己翻阅错误日志，而是直接看到归因结果，且可重试的场景大概率已被自动处理。

Agent评估与Prompt评估的根本差异：Side Effects

本期与第二期「评估Prompt」的核心区别在于副作用（Side Effects）。评估单次Prompt时，输出本质是文本，即使是工具调用，只要不真正执行，就不会与外界交互。而Agent在多轮执行中会真实产生工具调用，进而对外界产生变更。

在本场景中，Side Effects主要有两类：

1. CI的Job是否被重试；
2. 是否在GitLab上对Merge Request发表了评论。

这些变更通常不是幂等的，因此如何观察这些变更、重置实验环境，成为Agent评估独有的挑战。

副作用（Side Effects）的管理在软件工程中本已是经典难题，在AI Agent评估中则更为棘手。传统单元测试的核心原则之一是「隔离性」——每次测试应在干净的初始状态下运行，测试结束后不留痕迹。对于纯文本输出的LLM调用，这一点天然满足；而对于会真实调用外部API的Agent，每次评估运行都可能在GitLab上留下真实评论、触发真实的CI重试任务，这些操作往往无法自动撤销。

这意味着评估工程师需要额外设计「环境重置」机制：要么在每次测试后清理产生的副作用（如删除评论、取消Job），要么采用隔离的测试环境使副作用不影响生产数据。这也是本文后续「从录制回放切换到真实GitLab实例」这一设计决策的核心动因——只有在可控的真实实例中，副作用才能被安全地产生、观察和重置。

评估五件套：数据集、打分器与环境设计

延续系列一贯的「五件套」框架，本次重点关注三个部分：数据集、打分器，以及Agent独有的环境设计。

数据集：从真实Session中提炼场景矩阵

真实数据的价值远大于合成数据。本次数据集来源于团队开源的NAP（Neutrae Agent Platform）项目，每一次Agent调用都会产生对应的Session数据，天然构成真实数据集。

从2893个原始会话中，团队用Agent筛选出72个有效日志，最终组合出四组场景：

• TA - 基础决策：约20条基础决策数据；
• TB - 抑制重复：同一错误因新代码推送反复出现时，Agent应识别到已评论过且错误未变化，避免重复评论；
• TC - 真实异常分析：确实存在需重试的错误，需向用户分析清楚；
• TD - 快速跳出：如Patch仍处于草稿阶段尚未准备好，即使失败也无需分析。

最终构建出38个精细的场景矩阵，其中不乏高难度case：例如Job已被手动重试、日志超过4MB导致GitLab API无法完整返回（需截断查询）、超过100条评论需合理分页获取上下文等。

值得强调的是，这些筛选与构建工作大量借助Agent完成。作者反复强调一个观点：当你开始做评估后，对Agent的使用应更进一步，因为纯人工处理效率实在太低。

环境设计：从「录制回放」到「真实实例」的转向

环境设计是Agent评估的重中之重，决定了Agent究竟在什么样的环境里运作。本场景中，GitLab API是最大的依赖——Agent需要通过它查询CI失败原因、日志、当前Patch状态等。

如何提供这些API是关键问题。团队做了两个方案：

1. 录制与回放（Record & Replay）：成本低，将真实API交互录制下来供回放；
2. 真实GitLab实例：成本高得多，但最终团队从方案一切换到了方案二。

这一转向背后有深层原因，核心在于真实实例能更准确地反映生产环境中的复杂交互，避免录制方案在多轮动态调用中的失真。这也提醒我们，环境的保真度直接决定了评估结论的可信度。

录制与回放（Record & Replay）是API依赖测试中的常见技术，其原理是在真实环境中拦截并保存HTTP请求与响应，后续测试直接从录制文件中读取响应而不真正发出网络请求。Python生态中的vcrpy、JavaScript中的nock都是典型工具。这种方案的优势在于速度快、成本低、无网络依赖；但其局限性在于它是「静态快照」——录制时捕获的是固定的请求序列，一旦Agent在评估中选择了不同的调用路径（例如先查评论再查日志，而非录制时的顺序），回放就会失配，导致测试失败或返回错误数据。

对于Agent这类具有动态决策能力的系统，调用路径本身就是评估对象之一，因此录制回放的「路径绑定」特性会严重干扰评估的有效性。切换到真实GitLab实例虽然增加了维护成本，却保留了Agent在实际调用中的自由度，使评估结论真正反映生产行为。

分层打分器设计：代码断言到LLM金标准评审

本次打分器设计相当精细，分为三层，兼顾了确定性验证与自然语言质量评估。

L1：Side Effects断言（确定性代码判定）

最底层直接用代码判断：是否产生了评论、Job是否被重试。这些都是确定性的事实，代码完全可以判定，无需任何模型介入。

L2：根因分析质量（LLM-as-a-Judge + 金标准）

评论的内容是自然语言，其质量与对错无法用确定性代码衡量，因此需要借助模型作为评判者（LLM-as-a-Judge）。而模型评判需要一个参考答案与实际答案比对。

这里的关键在于金标准的构建：团队使用了当前最强模型之一（对标Claude Opus级别）为每个Session生成前沿模型的参考答案，再由人工审核这些答案，最终形成金标准。

这一步因人工介入而耗时，但金标准的准确性至关重要——一旦它不可靠，整个L2层的分析质量评估都失去保障。

LLM-as-a-Judge（以大模型作为评判者）是近年来评估开放式文本输出的主流方案，其核心思路是：当输出结果无法用规则精确衡量时，用一个足够强的模型来模拟人类评审员的判断。该方法已被多篇学术论文验证具有较高的与人类评分的相关性，但也存在已知缺陷，例如「位置偏差」（倾向于选择排在前面的答案）、「冗长偏差」（倾向于认为更长的答案更好）以及「自我偏袒」（模型倾向于给与自身风格相似的输出打高分）。

引入「金标准参考答案」并配合人工审核，正是针对上述偏差的工程对策：评判者不再凭空打分，而是将待评答案与经人工确认的标准答案进行比对，将主观的「好不好」转化为相对客观的「与金标准的差距有多大」。这使得评估结论更稳定、更可审计，也更容易在团队内部达成共识。

L3：用量统计（Token与耗时的量化分析）

本次新引入的一层，统计Agent运行的轮次、消耗的Context Token、总执行耗时。引入这一层的洞察非常深刻：

在Agent任务中，更贵的模型不代表性价比就差。强模型可能凭借更高的智力，用更少的Token、更短的路径完成任务；而弱模型虽然单价低，却可能因路径冗长、Token用量暴涨，最终总成本反而更高。

因此对Agent而言，评估的不仅是「对错」，还有「效率」。

实验结论：DeepSeek V4 Flash的性价比胜出

实验恰逢DeepSeek V4 Flash正式版（0731）发布，而Pro版当时仍为预览版；千问新的3.8系列尚未发布，故对比使用了千问3.6的27B和35B MoE作为备选。

最终测出了与DeepSeek官方接近的数据：在这个任务的部分维度上，DeepSeek V4 Flash正式版的性能优于Pro预览版，性价比自然更佳。相比原本的Sonnet 5，Flash仅在极少数场景略有逊色，但从整体任务表现来看带来了十倍以上甚至更多的成本下降。

模型演进的背景也值得记录：该Agent最初使用Sonnet 4.6，经过约一周基于人类反馈（主要是研发用户）的调试后达到满意状态；随后随Sonnet 5发布升级，实测无任何回退，且在措辞和精细判断上进一步提升。

总结：评估是成本优化的最大杠杆

这次实战给出的核心启示是：

• 确定性任务的Agent模型降级是可行的，但需要系统化的评估流程支撑；
• Side Effects和环境设计是Agent评估区别于Prompt评估的关键难点；
• 分层打分器（代码断言 + LLM金标准 + 用量统计）兼顾了正确性与效率评估；
• 真实数据 + Agent辅助构建是高效搭建评估集的最佳实践。

十倍的成本下降并非来自运气，而是来自一套可复用的评估方法论。对于任何在生产中运行昂贵模型的团队而言，这或许是最值得投入的工程方向之一。