我是安徽最忧郁程序员无隅
前言
一个 Agent 写出的分析条理清楚、措辞笃定，就能直接交付吗？如果它漏读了材料、误用工具，或者在没有授权时访问了数据，只看最终回答很难发现。本文用"阅读三份材料并撰写分析"的假设任务，讲清如何检查执行过程、建立可回归的评测、让失败回到正确的改进环节，并把资源预算纳入交付标准。
一、为什么评测 Agent 要看 Trace
假设用户让研究 Agent 比较三份材料中的产品定位，并要求每个关键结论都附上来源。Agent 最后交出一份完整报告，看上去满足要求。但执行记录显示：第三份材料的读取工具返回"无权限"，Agent 仍然写出了"三份材料一致认为......"的结论。
此时只读报告，可能会给它高分；把过程打开，问题立即变清楚：**结果没有满足任务范围，结论缺少证据，但拒绝越权读取这件事本身是正确的。**同一次执行可以在不同维度上得出不同判断，这正是 Agent 评测必须查看 Trace 的原因。
这里的 Trace 指一次任务中可核查的执行记录，例如任务约束、工具调用与返回状态、引用的材料位置、关键决策、重试和停止原因。它不要求保存模型的私有思维链，也不意味着把敏感资料原文全部记进日志。评测需要的是足以还原"做过什么、依据什么交付"的证据，并对日志中的隐私信息做必要保护。
用五类 Eval 拆开"好不好"
下面这张图把评测分成五个观察面。前四类主要判断交付质量，Cost 判断资源是否处在约定预算内。它们并行检查同一条执行记录，不能让一个总分掩盖某项硬性失败。
| 维度 | 要回答的问题 | 三份材料任务中的检查依据 |
|---|---|---|
| Outcome（结果） | 用户要的任务完成了吗？约束和交付格式满足了吗？ | 是否比较了三份材料，是否交付可用报告 |
| Trajectory（过程） | 路径、工具调用和中间决策合理吗？ | 读取失败后是否调整计划，是否无意义重试 |
| Evidence（证据） | 关键结论能回到材料或工具结果吗？ | 每个判断对应哪份材料的哪段内容 |
| Safety（安全） | 是否守住权限、隐私和危险动作边界？ | 读取被拒后是否停止访问、是否泄露内容 |
| Cost（成本） | Token、工具次数、重试和延迟是否超预算？ | 为得到这份报告实际消耗了多少资源 |
对开头那次失败，可以逐项判定：Outcome 不通过，因为只核查了两份材料；Evidence 不通过，因为涉及第三份材料的结论没有出处；Trajectory 不通过，因为工具拒绝后仍宣称完成；如果 Agent 没有绕过权限，Safety 反而可以通过。Cost 还要看实际消耗和约定预算。不能用某几项的高分抵消关键证据缺失。
课程材料还把质量细查落到七项：用户要求满足度、事实可靠性、证据充分性、逻辑闭合、工具使用合理性、安全与权限、交付格式。它们不是与五类 Eval 平行的新体系，而是更具体的检查问题：例如"事实可靠性"和"证据充分性"属于 Evidence，"逻辑闭合"和"工具使用合理性"属于 Trajectory，"交付格式"属于 Outcome。Cost 单独检查资源预算，不必硬塞进七项里。
尤其要区分事实看似正确 和证据足以支持。即便报告对某个产品的描述恰好正确，只要它声称比较了无法读取的第三份材料，这个结论仍不能按当前任务交付。评测判断的是这次执行是否可靠，而不是让评审者凭自己的常识替 Agent 补证据。
二、如何把评测做成可回归的工程流程
偶尔找几个人试用，只能发现眼前的问题；想知道一次 Prompt、工具或编排改动是否真的改善了系统，需要固定输入、判定标准和比较对象。可以从一小组真实任务开始，把每个用例写成"输入与约束---期望行为---禁止行为---判定证据"。这组用例通常称为 Golden Cases，并随着线上失败持续补充。
例如，三份材料任务至少值得保留以下几类用例：
| 用例 | 期望行为 | 典型失败信号 |
|---|---|---|
| 材料齐全，观点一致 | 比较三份材料，并让结论指向对应出处 | 只有概括，没有可追溯来源 |
| 第三份材料无权限 | 说明无法完成完整比较，报告已核查范围 | 编造第三份材料的观点，或绕过权限 |
| 两份材料互相矛盾 | 展示冲突、依据与不确定性 | 选一边当成确定事实 |
| 工具临时失败 | 在预算内重试或停止，并保留失败状态 | 无限重试或把失败当成功 |
用例不是只存一份"标准答案"。同一个任务可能有多种合格表述，但"不得声称读过无权限材料"是稳定的行为约束。这样写，评分器才知道该检查什么。
三类评分器各做擅长的事
确定性检查适合明确可计算的条件：必须包含的字段是否存在、工具是否返回成功、引用标识能否解析、是否调用了受限工具、Token 或轮次是否超过上限。这类检查可重复，但它不能单独判断一段分析有没有误解原文。
LLM-as-a-judge 适合需要理解语义的判断，例如结论是否被引用段落支持、是否遗漏了用户约束、冲突是否解释清楚。要给评审模型明确的评分规则、可核查材料和 Trace，并要求它指出问题对应的证据；否则"写得像样"容易被误判成"确有依据"。
人工复核用于高风险、争议较大或评分器分歧的样例。人工不必看每一次运行，但应定期检查评审标准有没有漂移，以及自动评分是否把合理答案误杀。三类评分器可以配合：机器先筛出硬性失败和可疑样例，人工处理边界案例，并把确认过的失败沉淀回用例集。
基线、稳定性与 CI 要连起来
改动前后要用同一批用例、同一套规则和尽量可比的材料快照。否则，分数变化可能来自外部资料更新或评分规则变动，而非 Agent 真的变好。记录版本、用例、评分器、Trace 和结果，才能回答"这次改动改善了哪些任务，又让哪些任务退步"。
单次通过仍可能靠运气。pass^k 关注同一用例重复运行 k 次是否都通过。例如示意性地让 10 个用例各运行 3 次，只有 7 个用例的三次运行全部通过，那么这批用例的 pass^3 是 70%。它提醒我们：一次成功不等于稳定成功。实际报告还应说明样本数、运行条件和各维度失败原因，避免只展示一个百分比。
把用例和评分接进 CI 后，每次重要改动都可以先跑固定回归集；耗时较长的重复运行可以安排在发布前或定期执行。CI 的价值不是替代人工判断，而是让"已知会坏的场景"不会在改动后悄悄回来。
三、一次失败该怎样定位和改进
评测的结果如果只是"65 分，请再生成一次"，对工程改进帮助很小。真正有效的闭环是：定位失效环节 → 修改对应机制 → 用同一个失败用例复测 → 与基线比较。图中的蓝色回路表示复测会重新进入执行和评分，而不是把旧结果再润色一遍。
回到第三份材料无权限的例子。审计者先把用户原始要求、允许访问的材料、工具返回、最终报告放在一起，指出："报告声称比较三份材料；Trace 仅显示两份读取成功；第三份返回无权限。"这是一条可复现的失败证据，而不是泛泛地说"答案不够严谨"。
随后按原因回流：
| 发现的问题 | 应回到的环节 | 可验证的改动 |
|---|---|---|
| 必需材料没有提供，或工具权限未配置 | 场景材料与外部能力 | 补齐合法输入，或把无权限状态交给用户处理 |
| 工具失败后仍继续声称任务完成 | 能力编排与停止规则 | 增加失败分支，要求报告已核查范围与缺口 |
| 有出处却没有把结论与出处对应起来 | 引用与证据组织 | 让关键结论携带可核查的材料位置 |
| 合格答案被评分器判错 | 评测规则和用例 | 修正判定标准，再检查旧基线是否可比 |
| 用户界面把"部分完成"显示为"已完成" | 产品交付状态 | 区分完成、部分完成与需授权等状态 |
这里的"回流"不等于每次都改 Prompt。缺材料就补材料或如实停止；权限问题由权限流程解决；评分规则错了就修评分器。只有定位准确，复测才有意义。
审计 Agent 应该输出什么
可以让独立的审计 Agent、Critic 或 Reviewer 挑战执行结果，但它不应替原 Agent 重做用户任务。审计输入至少包括：原始任务和约束、最终产物、可查看的材料与 Trace、明确的评测标准。审计输出应指出失败维度、具体证据、影响、建议回流的环节；证据不足时说明无法判定。
审计本身也要接受评测。若它凭空指出"第三份材料有相反意见"，却没有读到第三份材料，那么它和被审计者犯了同类错误。审计意见应能指向可检查记录，且重试次数要受预算约束。把失败样例加入 Golden Cases 后，下一次改动才能证明同类错误是否真的减少。
四、如何把成本纳入交付标准
质量合格但每次都反复检索、重复调用工具，也可能无法在真实场景持续使用。Cost Eval 因而要记录至少四类数据：输入与输出 Token、工具调用次数、失败后的重试次数、端到端延迟。预算应针对任务类型设定；简单问答与多材料分析不适合用同一上限。
成本审计必须与质量门槛一起看。若为了省 Token 删掉关键证据，表面成本下降，Evidence 却失败；若为了追求"绝对正确"无限增加审计轮次，成本和延迟又可能失控。更稳妥的顺序是：先明确不可牺牲的约束，例如权限和关键结论可追溯；再定位浪费发生在哪一轮，比如重复读取同一材料、无效重试、把全文反复送入评审；最后修改流程并重新跑质量与成本评测。
仍以三份材料任务为例：如果报告缺证据，先补可追溯引用；如果引用已经齐全但每轮都把三份全文重新送给模型，可以改为传递必要片段和引用位置。后一种优化是否成立，要用原来的 Golden Cases 复测：质量不下降，同时资源消耗确实减少，才算有效改进。
Agent 的交付标准不是"回答看起来不错"。它应满足任务、过程合理、证据可追溯、权限安全，并处在可接受的资源预算内。评测把这些要求变成可检查的门槛；回流让每一次失败指向具体改动；复测则验证改动是否真的解决了问题。
**素材说明：**本文依据所给课程材料《Agent 评测与调优（第三板斧）》节选整理；三份材料任务及示意数值用于解释评测方法，不代表真实系统的实测结果。