我是安徽最忧郁程序员无隅前言一个 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 评测与调优第三板斧》节选整理三份材料任务及示意数值用于解释评测方法不代表真实系统的实测结果。
我是安徽最忧郁程序员无隅前言一个 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 评测与调优第三板斧》节选整理三份材料任务及示意数值用于解释评测方法不代表真实系统的实测结果。
