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 TruthHarness 只能给你一个“看起来还行”的主观印象有了 Ground TruthHarness 才能变成一把真正可复用的尺子。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 跟着业务一起长。 
长河君 · 2026/10/16 8:30:48 · 阅读 1.2k Agent评测为何绕不开Ground Truth？Harness三种验证机制与设计实践
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 TruthHarness 只能给你一个“看起来还行”的主观印象有了 Ground TruthHarness 才能变成一把真正可复用的尺子。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 跟着业务一起长。