1. 先想清楚一件事：Agent 评测为什么绕不开 Ground Truth
“Harness Evaluation”这个概念，我第一次看到时以为是又造出来的新词。但真正带着几个 Agent 项目上线走了一圈才发现，这四个字背后是所有做 Agent 的人迟早要撞上的墙：没有 Ground Truth，就没有可靠 Agent。这里的 Ground Truth，不是指一个标准答案字符串，而是指“在给定任务和环境下，用什么样的客观证据来判断 Agent 的表现是对的”。如果这件事不定下来，后面的评测、调优、上线全是在碰运气。
我见过最典型的翻车案例，是某团队做的客服工单自动处理 Agent。当时他们在测试环境里跑了十几轮对话，人工看一眼回复，觉得“嗯，挺靠谱的”，就直接上了生产。结果用户投诉率直线上升。后来排查发现，当 Agent 检索不到对应工单时，它并不会如实说“没找到”，而会一本正经地编造一个工单编号，语气还很笃定。为什么测试时没发现？因为测试时压根没有定义“查无此单时应该返回什么”，评测人员看到模型生成了一大段话就默认它正确。
这就是 Missing Ground Truth 的本质问题：评估体系如果不存在一个可确认的“对”的标准，那么 Agent 的任何输出都会在自洽性上显得合理，包括完全错误的推理链。人类连续看五个逻辑通顺但事实错误的回复，也会逐渐失去判断力。更麻烦的是，在没有 Ground Truth 的情况下，模型迭代的效果也无法衡量。你调了一圈 prompt，评测集的通过率从 73% 变成 75%，很可能只是模型嘴更甜了，而不是真的更可靠了。
所以做 Agent 评测，第一步不是选框架、不是写 prompt，而是老老实实回答三个问题：任务的目标是什么？成功的证据是什么？失败时我们应该怎么记录和归类？这三点就是 Harness 的核心骨架。简单说，Harness 就是一个夹在任务和模型之间的评测执行器：它负责准备输入、约束 Agent 的行动范围、收集执行过程、调用验证机制来判定结果、输出结构化报告。没有 Ground Truth，Harness 只能给你一个“看起来还行”的主观印象；有了 Ground Truth，Harness 才能变成一把真正可复用的尺子。
1.1 “看起来合理”是 Agent 评测里最危险的错觉
大语言模型有一个和人类很像的特性：输出流畅、逻辑自洽时，我们会天然倾向相信它。这种信任在闲聊场景没问题，但在自动化任务场景非常致命。Agent 的工作流是“规划—调用工具—观察结果—再规划”，每一步都可能出错：工具选错、参数拼错、返回结果理解歪了、多步之间逻辑断了。这一长串过程中，模型完全可以生成一段衔接顺畅的文本，把每一步都“演”得像是正确执行了。
我自己踩过的一个很典型的坑，是在做某内部数据查询 Agent 时，Agent 需要调用一个报表接口，传入日期参数。它有一轮把日期传成了三个月前，但结果恰好能返回数据，于是它顺着这个错误结果继续加工，最终输出了一份结论完整的周报。单看最终文本，没有任何破绽，格式好看、结论有数据支撑。直到我们用人工复核去查原始接口日志，才发现日期根本不对。这说明一个道理：在一个没有明确判定依据的评估环境里，流畅性会掩盖正确性。你问模型“你确定吗”，它永远回答“我确定”。
因此，Ground Truth 的作用不是用来束缚 Agent，而是给我们一个锚点。有了锚点，我们才能把“看起来合理”和“确实正确”区分开。哪怕锚点只是一个粗粒度的、包含多个合法答案的判定集合，也比没有强一万倍。评估的第一步，永远是建立这个锚点，这是 Harness 之所以存在的根本原因。
1.2 Harness 评价器：夹在 Agent 与任务之间的裁判
Harness 这个词直译是“马具”，意思是把动力装置和负载连接起来的那层结构。在 Agent 评测里，Harness 起的作用也一样：负责把任务定义、环境工具、模型行为、验证规则这几个部分连接起来，形成一套可重复执行的评测系统。它不是一个模型，不是一个应用，而是一个“带着规则的任务执行框架”。
一个完整的 Harness 至少要包含四层东西。第一层是任务装载器，负责把评测样本里的输入、工具配置、环境参数加载出来；第二层是代理执行器，它按照规定的协议驱动 Agent 做事，比如传入 user prompt、收集工具调用结果、管理回合数；第三层是验证器，这是最关键的一层，把 Agent 的最终答案、调用轨迹、中间产物送到验证机制里去打分数；第四层是报告器，把每个样本的结果、失败原因、耗时、Token 消耗汇总成一份可阅读的评估报告。
很多人误以为 Harness 只是一个自动化脚本，其实不止。脚本只管“跑”，Harness 要管“判”。判得准不准，决定这套评测体系有没有参考价值。而“判”的质量又取决于验证机制的选型。下面我把三种验证机制逐一拆开讲。
2. 三种验证机制：从结果校验到过程监督
验证机制是整个 Harness 的心脏。选错验证机制，要么是误杀率大到让开发团队失去信心，要么是漏网之鱼多到评测形同虚设。目前业界和开源社区里最常见的做法，我总结成三类：结果态校验、过程证据校验、一致性校验。它们不是互斥关系，一个成熟的 Harness 往往把三者组合使用，在不同环节各司其职。
2.1 机制一：结果态校验，用最硬的证据卡最终输出
结果态校验是思路最直观的一种：Agent 跑完整个任务后，我们拿它的最终输出和预期结果做比较。问题在于“比较”这件事的粒度怎么定。拿文本生成类的任务举例，如果你要求 Agent 输出一段固定格式的 JSON，那么校验规则可以是：先解析 JSON，再校验里面的关键字段是否符合预期。这属于结构化校验，成功率很稳定。如果任务是开放式问答，那么字符串完全一致就没意义，需要引入语义相似度或“断言集合”。
我推荐的做法是把结果校验分成四个层级，由硬到软：
- 精确匹配：适用于验证码、固定 ID、枚举值等场景，错了就是错了，没有任何商量余地。
- 结构化字段比对：解析 JSON/YAML，逐字段验证类型和取值范围，允许字段顺序不一致，允许额外补充信息。
- 断言式检查：把“应该满足什么条件”写成一段表达式或一个小函数，比如“返回的列表中必须包含状态为 closed 的工单”“金额字段必须大于零且小于总预算”。
- 语义或规则近似：通过关键词集合、正则、或者调用一个小模型做语义相似度判断，适用于答案措辞灵活但核心语义固定的任务。
第四层听起来最美好，但使用时要非常节制。我自己实践下来，基于规则的近似匹配（比如关键实体出现 + 否定词不出现）比直接上语义相似度更稳定。因为相似度分数本身是一个模糊值，你需要为它设阈值，而阈值的设定又会随样本集漂移。真要用语义相似度，建议只作为一个二轮确认条件，不作为过关的充分条件。
还有一类非常硬核的结果校验是执行式校验。比如让 Agent 写一段 SQL、一段 Python 代码或一个配置文件，校验方式就是真的去执行它，看它能不能跑通、结果是否符合预期。这种校验的价值在于，它把“语言上的合理性”替换成了“执行上的正确性”，是三种机制里面最不近人情、也最可靠的一种。只要场景允许执行，比如有隔离的沙箱环境，我都优先推荐用执行式校验作为结果最终判定的核心手段。
2.2 机制二：过程校验，顺着调用轨迹倒查 Agent 有没有跑偏
结果校验有一个盲区：它能确认“最后答对了”，却不能确认“Agent 是按合理路径到达答案的”。某些任务里，Agent 可能先做了一个错误决策，碰巧被后续的工具返回值纠正了，最终结果是对的。这种“歪打正着”在单次评测里问题不大，但一旦任务复杂度上升，错误的中间决策会在某些输入组合下炸掉。所以我们需要过程校验。
过程校验的核心素材是 Agent 的完整调用轨迹，也就是 trace。一份标准 trace 通常包含：模型在每个步骤的思考摘要、调用的工具名称、传入的参数、工具的原始返回、模型对返回结果的加工。我们要做的是在这个序列上设置检查点，常见做法有三种。
第一种是关键步骤锚定。先手动分析正确流程应该经过哪些节点，比如查天气任务，正确流程必须调用“城市编码解析”和“天气查询接口”这两个工具，且城市编码解析应该发生在天气查询之前。把它写成规则，比如“天气查询工具的参数中必须包含 city_id，而 city_id 必须来自前一步解析结果”。锚定越细，越能抓住跑偏，但也会增加编写成本，所以要挑关键节点锚定，不要每一步都卡。
第二种是错误模式匹配。与其描述什么是对的路径，不如直接拦截那些常见错误。比如“同一个工具被连续调用超过三次且参数没变化”，这通常意味着 Agent 陷入了死循环；“Agent 调用了一个工具，但把返回结果直接复制进最终回答，没有做格式化”，这也是一种可以正则匹配的错误模式。把历史失败样本里的共同特征抽象成规则，是一个非常高效的防回归手段。
第三种是人工抽检的延伸。让 Harness 把过程轨迹保存下来，评估者不需要在评测过程中逐一查看，而是只标注那些结果判定“通过但轨迹可疑”的样本。做法是给轨迹计算一个简单风险分，比如工具调用异常次数、重试次数、超时次数，超过预设阈值的样本不管结果是否通过，都进入人工复核队列。这种做法把“全量轨迹审计”降级为“定向轨迹审计”，成本低很多，效果却好很多。
过程和结果不是非此即彼。我的习惯是：结果校验作为主裁判，过程校验作为副裁判，只要有一位副裁判给出强信号，就把样本拉出来复审。在最终报告里区分“结果通过但过程存疑”和“结果通过且过程健康”，能显著减少后续调优时的误判。
2.3 机制三：一致性校验，没有唯一答案时用多个角度围剿错误
第三种机制解决的是“没有唯一标准答案”的难题。比如客服回复话术、内容摘要、方案建议这些任务，正确答案是一个“合理区间”，而不是一个点。在这种情况下，硬套 Ground Truth 会压制 Agent 的灵活性，但我们又不能直接放弃判据。一致性校验的思路是：不直接判定哪一个是正确答案，而是通过多种角度检验 Agent 自身输出的稳定性和内部逻辑一致性。
我用过比较有效的一致性校验有三种。
第一种是多次采样一致性。同一个任务，让 Agent 在温度参数调高的情况下跑 N 次，对比多次结果的语义相似度。如果 5 次结果高度一致，说明 Agent 对这个任务有自己的稳定理解；如果 5 次结果五花八门，说明任务描述里存在歧义，或者模型没有足够的信息来做出决策。这里要注意，一致性高不等于正确，但一致性低一定意味着评估不可靠，所以它适合做“置信度筛选”，不适合做直接判定。
第二种是交叉验证。同一个任务，用两套不同的任务表达方式去问，或者用两种不同的初始提示去驱动 Agent，然后比较结果的一致性。比如在客服场景里，一轮问“客户说商品没收到，请处理”，另一轮问“用户反馈物流显示签收但本人没有拿到，请给出应对方案”。如果 Agent 在这两种表达下给出的处理方式不一致，说明它更多是在追着字面跑，而不是真正理解任务内核。
第三种是自反验证。让 Agent 生成答案后，再用另一个独立检查步骤去验证答案内部是否自洽。典型做法是让模型把答案里的关键实体提取出来，和任务输入里的实体做比对，看有没有引入输入中不存在的实体；或者让它为答案里的每个结论列出依据，然后检查依据是否能在工具返回中找到。自反验证不需要额外 Ground Truth，只需要定义“哪些信息必须来源于输入或工具返回”这个边界。这条边界本身就是一种弱 Ground Truth。
三类机制各有利弊，我在实际项目里通常是这样分配的：能用执行式校验的任务，90% 用结果校验；链路复杂、有工具调用的任务，叠加过程校验；主观生成类任务，用一致性校验做辅助信号。评测设计不是越复杂越好，而是要让每一类校验都明确回答一个问题。
| 验证机制 | 适合场景 | 典型方法 | 主要风险 |
|---|---|---|---|
| 结果态校验 | 代码、SQL、JSON、固定格式输出 | 执行式校验、结构化比对、断言 | 对开放式任务过于死板 |
| 过程证据校验 | 多步工具调用、决策链路 | 关键节点锚定、错误模式匹配 | 规则维护成本偏高 |
| 一致性校验 | 话术生成、摘要、方案建议 | 多次采样、交叉验证、自反验证 | 不能单独作为充分判据 |
3. 四个关键设计决策：照着选，才不会在评测系统上反复返工
验证机制定下来以后，还要在设计层面对四个问题拍板。这四个决策如果拍错了，后面的评测结果可信度都会打折扣。我可以直接把我的经验方案摆出来，大家按自己的场景取舍。
3.1 决策一：评估粒度定在哪个层次，直接决定排障效率
评估粒度有三种常见选择：系统级、任务级、步骤级。系统级评估关注整个 Agent 应用在端到端流程上的表现，比如“客服 Agent 从收到用户消息到完成工单闭环，整体的成功率有多高”。任务级评估关注单次任务的完成质量，比如“这个 Agent 在面对退款类咨询时，是否找到了正确的退款单号”。步骤级评估关注单个环节的表现，比如“意图识别这一步的准确率”“检索模块是否召回了包含正确订单号的文档”。
我见过不少团队一上来就做系统级评估，觉得这样最真实。但现实是系统级指标一旦下跌，你根本定位不到是哪个环节出了问题。你只知道“退款流程成功率从 91% 降到了 84%”，但不知道是意图识别歪了、参数抽取错了、还是退款接口返回了模型无法理解的结构。所以我建议的顺序是：先做步骤级评估，做好以后用步骤指标推算任务级表现，最后再拿系统级端到端指标做整体兜底。这就像修车，你不能只报“车开不动了”，你得知道是点火系统、油路还是变速箱的问题。
步骤级评估要采集的数据比较细，包括每一步的输入输出快照、延迟、工具返回的原文。任务级评估就要把步骤数据汇总成一份执行摘要，方便从整体看问题。Harness 在实现上要有意识地保留多级记录：每一个步骤记录一份，整个任务记录一份汇总，这样任何一个指标出问题，都能快速下钻到具体步骤。粒度越细，调试越爽，但存储和标注成本也会上升。我的经验是需要做人工标注的样本，尽量把粒度限制在任务级和步骤级，不要让人去标系统级样本，因为系统级样本通常绑定了一长串上下文，标注人员很容易被细节带跑偏。
3.2 决策二：验证强度与误杀率要有一个明确阈值策略
验证机制设计得越严格，漏掉错误样本的比例就越低，但误杀率也会上升。误杀指的是：Agent 实际完成任务了，但因为验证规则太死板，把合法输出判成了不合法。最典型的就是结果校验里用了精确匹配，但 Agent 在输出里多了一个“您好”，或者把日期格式从 2025-01-01 写成了 2025/01/01。这种误杀在开发期会反复发生，容易让团队对评测系统失去信任——如果团队觉得“反正它也会瞎报错”，评测报告的作用就大打折扣。
我的解法是把验证强度做成两档可配置的阈值，而不是一刀切。第一档叫“硬门槛”，居多是安全相关或流程上绝对不能错的条件，比如“转账金额必须等于用户输入金额”“敏感操作必须经过二次确认”。硬门槛直接卡死，不通过就是失败。第二档叫“软提示”，居多是格式、冗余信息、表达习惯层面的约束，比如“回复里不能包含未经验证的外部链接”。软提示未通过时，样本进入待复核列表，由人在周度会议上做出裁决。
在阈值设定上有一个经验公式可以参考：先拿一批人工标注过的历史样本跑一遍验证器，统计误杀率和漏报率。如果误杀率高于 5%，就把规则放宽一点或降级成软提示；如果漏报率高于 5%，就要增加规则强度或补一层过程校验。不要把阈值调到零误杀，在大多数业务场景，零误杀意味着规则松到无法拦截真正的错误。保持一个“小但有意义”的误杀率，比追求绝对精确更能维持团队的警觉性。
3.3 决策三：失败必须分门别类，不能只给一个“通过/不通过”
第一版 Harness 往往只输出通过率和失败率，这会让开发团队陷入一种“我知道有问题但不知道哪有问题”的焦虑。正确的做法是把失败分类做进验证机制里，把每个不通过样本打上一个可归因的标签。我建议至少分五类：
- 任务理解失败：Agent 根本没有抓住用户的核心诉求，答非所问。
- 信息检索失败：在工具返回内容里找不到所需关键信息，比如没有检索到工单，但 Agent 自己编了一个。
- 工具调用失败：调用了错误的工具，或参数格式错误，导致工具返回异常。
- 推理链路失败：每一步单独看都对，但步骤之间的衔接逻辑断裂，比如先算税后金额再计算折扣，但顺序反了。
- 表达与合规失败：答案事实正确，但格式不符合要求、包含不安全内容等。
这五种分类要映射到 Harness 的判定逻辑里。比如结果校验不通过时，过程校验里的工具返回记录能告诉我们“信息检索失败”和“推理链路失败”的区别。一个样本可以在报告里携带多个失败标签，但主标签只能有一个，用于后续的统计和排优先级。
分类的价值不仅在于统计，还在于驱动后续优化资源的分配。假设一个评测周期里有 40% 的失败属于“工具调用失败”，那优化方向就是工具描述和参数约束，而不是去调 prompt 的语气。假设 50% 是“任务理解失败”，那就需要重新设计任务指令，或者增加一个意图确认步骤。没有分类的评测报告只能让团队凭感觉挑问题，有分类的报告能直接指导下周的工作排期。
3.4 决策四：样本集要分层管理，永远保留一块回归基线
评估样本集不是一次性建完就完了。Agent 在迭代过程中，很容易出现“踩了东墙补西墙”的情况：修复了 A 类问题，B 类问题反而变多了。如果没有回归基线，这种退化很难被及时察觉。所以样本集的管理要分层，我通常分成三层。
第一层叫冒烟集，规模很小，大概 10 到 30 条，覆盖每个主要功能的最小可用场景。冒烟集每次提交代码后必跑，用来快速发现大面积崩溃或不可用。第二层叫回归集，规模在百到千条级别，包含历史上所有修过的重要 bug 对应的样例。回归集每天或者每次大版本更新时跑，目的是确保旧问题不复发。第三层叫探索集，规模可以持续扩充，来自线上真实流量或用户反馈中出现的新问题形态。探索集不定时加入评测，用来发现新的长尾问题。
样本集的维护还有一个常被忽视的点：Ground Truth 本身也会过期。业务规则变了、页面结构变了、第三方接口的返回格式变了，原来标注的标准答案可能就不再是正确答案。所以每周或者每两周要做一次样本复审，把那些已经被业务变更推翻的 Ground Truth 找出来更新掉。否则评测系统会在你不知情的时候，变成一套“坚持错误标准”的机器，越跑越精确，越精确越误导。
4. 实操落地：给某客服工单自动化 Agent 搭一套 Harness
概念讲得再多，不如走一遍落地过程。我用一个脱敏后的模拟项目 X 来说明：某电商客服团队要做一套工单自动处理 Agent，它接收用户的售后咨询，需要调用查询订单接口和申请退款接口，最后输出一段客服话术给用户。这个任务看起来不复杂，但恰恰是评测体系容易失守的类型。
4.1 先定任务边界和 Ground Truth 清单
我们第一步做的事，是把任务进行了拆解和标准化。一个完整的工单处理任务被拆成四个步骤：意图理解（需要判断用户是要查物流、要退款还是要投诉）、订单号提取（必须从用户对话里找到合法订单号，找不到则必须追问）、退款信息确认（包括金额、原因、退款方式）、话术生成（按照客服规范输出最终回复）。
每个步骤都定义一个可验证的 Ground Truth 要求：意图理解的结果必须命中预设的意图标签；订单号提取必须符合订单号的格式规则，且必须来自用户输入文本；退款信息确认必须和查询订单接口返回的订单金额一致；话术生成不能出现虚构订单号、不能包含不安全的承诺。有了这份清单，后续验证规则怎么写就非常清晰了。
顺便说一句，这一步最容易被省略，但恰恰是最不能省的。拿着这份清单，我们才能在 Harness 里定义“Failure 到底长什么样”，而不是等模型输出以后拍脑袋判断。
4.2 搭建 Harness 的主流程和判定逻辑
在实际实现里，我们用的是 Python 写的一个轻量级 Harness。主流程大致如下：加载测试样本，把样本里的初始对话传给 Agent 执行器；Agent 内部会多次调用工具，执行器把这些调用过程记录下来；任务结束后，把结果交给验证器；验证器综合结果校验和过程校验的结果输出报告。
以下是验证器部分的一个简化示例，说明核心事件流，实际工程里会比这个更复杂：
def evaluate(sample, trace): verdicts = {} # 1. 结果态校验：话术里不得出现虚构订单号 final_answer = trace["final_answer"] order_ids = extract_order_ids(final_answer) real_order_id = sample["ground_truth_order_id"] if order_ids and real_order_id not in order_ids: verdicts["final"] = "fail" verdicts["fail_reason"] = "info_hallucination" else: # 退款金额必须与接口返回一致 amount_ok = check_refund_amount(final_answer, trace["refund_api_result"]) verdicts["final"] = "pass" if amount_ok else "fail" verdicts["fail_reason"] = "reasoning_failure" if not amount_ok else "" # 2. 过程校验：申请退款前必须查询过订单 tool_calls = [step["tool"] for step in trace["steps"]] if "query_order" not in tool_calls: verdicts["process"] = "warn" verdicts["process_detail"] = "query_order_not_called" elif tool_calls.index("refund_apply") < tool_calls.index("query_order"): verdicts["process"] = "fail" verdicts["process_detail"] = "refund_before_query" # 3. 一致性校验：多次采样时，关键实体是否稳定 if sample["enable_consistency_check"]: entities = extract_key_entities(final_answer) sample_entities = sample["required_entities"] if missing_entities(entities, sample_entities): verdicts["consistency"] = "warn" return verdicts这个例子想表达的是验证逻辑的松散组合：结果态校验管“最终输出对不对”，过程校验管“执行顺序和工具调用合不合理”，一致性校验管“关键实体有没有漏”。实际规则会沉淀在配置文件里，方便非工程背景的评测人员维护。
4.3 首批样本的评测结果长什么样
我们第一批选了 50 条真实历史工单作为评测集，人工标注好 Ground Truth，然后跑了一遍 Harness。结果很有代表性：整体通过率 68%，但拆开看之后，失败原因分布非常有意思。工具调用失败占 22%，主要原因是 Agent 在某些订单号格式下把查询参数拼错了；推理链路失败占 18%，集中在“先申请退款再查询订单”这种顺序颠倒；信息幻觉占 10%，集中表现为话术中出现历史记录里不存在的商品名称；其余是表达层面不符合客服规范的问题。
这个报告直接改变了团队的优化优先级。之前他们原本计划去优化话术模板的 prompt，但数据表明大头是工具调用参数的问题，于是把精力转向了工具描述和参数校验逻辑。两周后二次评测，工具调用失败从 22% 降到了 9%，整体的通过率升到了 81%。
这就是分类失败报告的价值：它不是告诉你“你不行”，而是告诉你“你哪里不行，先去修哪里”。
5. 常见问题与排查技巧实录
Harness 搭起来只是开始，真正要命的是后续跑评测时冒出来的各种幺蛾子。我把这段时间遇到的高频问题整理成速查表，每个都是亲测。
| 问题现象 | 可能原因 | 排查思路与处理建议 |
|---|---|---|
| 误杀率居高不下 | 验证规则写得太死，不允许任何格式偏差 | 把规则里的强校验降级为软提示，或引入结构化字段比对替代精确匹配 |
| 评测结果不稳定，同一批样本前后两次差异大 | 模型采样温度过高，或工具返回结果本身有随机性 | 将评测时模型温度设为固定低值，对非确定环节做多次采样取多数判定 |
| 线上问题复现不了，评测集里抓不到 | 评测集的样本分布和线上真实流量不一致 | 从线上日志里捡一批高频失败场景补充进探索集，持续扩大样本覆盖面 |
| 通过率很高，线上效果却不好 | Ground Truth 过时，或验证规则覆盖不到关键的事实错误 | 每周复审样本集，增加“关键事实必须能在工具返回里找到依据”的规则 |
| Agent 在评测里“作弊”，直接要答案 | 环境未隔离，Agent 通过调试接口拿到了不该有的信息 | 限制工具访问范围，在 Harness 里对工具返回值做脱敏处理 |
| 过程轨迹太大，存储压力高 | 每一步都完整保存了工具原始返回 | 只保存关键步骤的原始返回，非关键步骤保存摘要，减少存储量 |
除了这张表，还有两个我特别想拿出来说的经验。第一个是关于超时的。Agent 评测里如果某个工具调用超时，Agent 往往会根据超时前的部分信息继续推理，这类样本的失败原因经常被误分类为“推理链路失败”。我们在 Harness 里会把“工具异常退出”单独打一个标签，不参与推理链路统计。否则排查时你会一直以为模型逻辑有问题，实际是第三方接口不稳定。
第二个是关于并行评测的陷阱。为了加速评测，很多工程师会开多线程并发跑样本，但某些 Agent 框架本身有全局状态或共享缓存，并发一高就会出现串号：样本 A 的结果串到样本 B 的轨迹里。这种问题非常隐蔽，报告里的数据看起来也是完整的，直到你抽查样本级记录时才会发现工具返回内容和当前任务完全对不上。建议在小批量范围内强制开启串行模式，确认无状态污染后再切并发。
6. 让评测体系持续增值的最后几个建议
到这一步，Harness 已经能稳定地告诉我“Agent 这次改得好不好”了。但我逐渐意识到，评测体系真正的价值不在于跑出某个分数，而在于它能把每一次失败的细节沉淀成组织的长期资产。
我现在维护的评测集里，每条样本都带一份失败分类和一段人工备注。这些数据比任何 prompt 技巧文档都有用，因为它们是真实业务边界和真实模型缺陷的记录。新同学加入团队时，我让他们做的第一件事不是读文档，而是翻一遍评测集里的失败样本。看完一百个失败案例，基本就知道这个 Agent 的脾气了。
另外一个值得做的事，是让非技术角色也参与到 Ground Truth 的制定里来。客服团队的组长知道什么话术是安全的，运营同学知道哪些优惠规则不能乱承诺。Harness 的验证规则如果只有工程师写，很容易陷入“技术正确但业务错误”的坑。我们后来固定了一个节奏：每周业务方和工程团队一起过一遍新增的评测样本，业务方确认规则，工程师落实实现。这个改动对评测质量的影响比任何技术优化都明显。
如果你现在正准备给自己的 Agent 搭评测体系，我实在的建议是别一上来就追求大而全。先把三类验证机制里最适合当前任务的那一种做扎实，把失败分类跑通，把样本集分层管理起来，就已经超过了市面上多数“看感觉调 Agent”的团队。剩下的，就是靠持续跑、持续修、持续累积，让 Harness 跟着业务一起长。
