假设你让一个 Agent 汇总一份表格中的销售额它返回了正确数字。只看答案这次任务应该得满分。但如果查看执行记录可能会发现另一幅图景它读错了数据版本几次查询都失败了最后从一段旧对话里碰巧找到了同一个数字或者它虽然生成了正确文件却覆盖了另一列公式又或者它在发送结果时重复提交了两次。答案可以是对的过程仍然可能不安全、不稳定也无法复现。评价一个会行动的 Agent核心不再只是“它说对了吗”而是它是否在允许的范围内以可以复查的证据和可接受的成本稳定地完成了目标。从回答模型到行动系统普通问答的主要产物是一段文本评价自然集中在正确性、相关性和表达质量上。Agent 不同它可能读取文件、调用数据库、运行程序、修改状态、创建工单或向外部系统发送信息。这时最终回答只是系统行为的一部分。一次任务至少包含下面这条链用户目标任务与权限契约模型选择动作工具实际执行环境状态变化产生证据与产物验证目标与副作用最终回答只检查最后一个节点相当于验收装修时只看一张客厅照片却不检查水电、承重墙和施工记录。评价 Agent 的六个维度维度要回答的问题可观察证据任务结果用户真正要求的目标是否实现验收规则、最终产物、目标系统回读动作合规是否只使用允许的工具、对象和操作工具调用、参数、权限范围、拒绝记录状态与副作用环境发生了哪些预期或非预期变化文件差异、数据库状态、消息回执、审计日志证据充分性最终结论能否回到数据和验证结果来源、查询、时间范围、校验器输出、产物哈希成本与效率在多少时间、调用和资源预算内完成工具调用数、耗时、读取量、token 或费用恢复与稳定性失败后能否正确恢复重复执行是否一致错误记录、替代路径、回滚结果、多次运行结果这六个维度不是要求所有任务都记录同样多的信息。查询天气和修改生产数据库的风险不同轨迹粒度当然也不同。原则是风险越高、动作越不可逆越需要完整的状态、证据和回读。轨迹不是私有思维链一提到“看过程”很容易把它理解成要求模型公开全部内部推理。其实Agent 评测需要的主要是可观察执行轨迹而不是私有思维链。可观察轨迹包括Agent 收到了什么任务约束调用了什么工具参数是什么工具返回了什么环境状态怎样变化产生了哪些文件或记录验证器是否通过以及遇到错误后采取了什么恢复动作。这些信息能够被系统记录、重放或独立检查。至于模型内部如何逐字思考既不一定可获得也不是判断“文件是否真的写入”“消息是否重复发送”的必要条件。换句话说我们要审计的是行动和证据不是索取一篇看似合理的自我解释。三种常见的“幸运成功”1. 用错证据碰巧得到正确答案用户要求统计最新数据Agent 却读取了上月快照。因为目标数字刚好没有变化最终答案仍然正确。如果只看答案这次错误的数据绑定会被隐藏一旦数字变化同一流程就会失败。2. 主产物正确同时破坏了别处Agent 按要求更新了配置项目标功能也能运行但它重写整个文件时删除了用户尚未提交的其他修改。主任务“成功”副作用却不可接受。3. 第一次成功第二次重复执行Agent 创建工单后没有读取系统回执于是把网络延迟当成失败再次提交。两次请求内容都正确外部系统中却出现了重复记录。这三种情况说明最终答案正确只能证明“这一次输出看起来对”不能自动证明方法正确、操作安全或系统稳定。先设门禁再谈效率Agent 评测最容易犯的另一个错误是把所有指标直接加权成一个总分。例如答案正确率、速度、成本和工具调用数各占一部分。这样可能出现一种荒谬结果一个越权读取数据但速度很快的 Agent靠效率分抵消了安全问题。更稳妥的方法是先设门禁再在合格运行之间比较效率否是否是否是一次 Agent 运行任务结果通过?记录失败类型权限与副作用通过?判为不合格成功证据与状态可复查?判为不可验证成功进入合格运行集合比较成本、速度与稳定性正确性、安全性和证据充分性属于资格条件成本和速度属于合格之后的优化指标。两者不能互相抵消。不要把失败简单压成一个 0对 Agent 来说失败方式本身就是重要信息。最终答案轨迹与门禁更准确的判断正确通过稳定成功仍需多次运行确认复现性正确未通过幸运成功或不合格成功不能直接上线错误通过安全失败适合定位能力缺口和改进恢复策略错误未通过错误成功声明、越界或不可诊断失败优先修系统护栏一个能在权限不足时明确停止并报告 blocker 的 Agent可能比“想办法给出答案”却越权行动的 Agent 更值得信任。评测设计如果只奖励有答案就会反向鼓励系统隐藏不确定性和失败。一个最小轨迹记录模板对于会调用工具的任务可以从下面这组字段开始不必记录冗长对话run:task_id:可复现的任务标识input_snapshot:使用的数据或文件版本allowed_scope:允许的对象、动作和预算execution:tool_calls:工具、参数、结果和错误state_changes:修改前后状态与外部回执artifacts:文件、查询结果或报告位置verification:result_check:目标是否实现safety_check:是否越权或产生非预期副作用evidence_links:结论对应的来源与验证器结果recovery:失败原因、修复动作与最终状态模板的价值不在字段数量而在于让最终声明可以回到实际发生的动作。需要公开展示时还应脱敏凭证、个人信息和业务数据可审计不等于把敏感日志全部暴露。评价 Agent 前的 30 秒检查最终答案对应的真实目标是什么怎样独立验收Agent 使用了哪些工具、数据版本和权限范围目标系统的状态是否真的改变是否完成回读有没有修改无关文件、重复发送或越权访问等副作用每项关键结论能否绑定到来源、查询或验证结果失败时Agent 是正确停止、有效恢复还是静默换了一条不可靠路径多次运行能否稳定成功还是只有一次碰巧通过正确性和安全门禁通过后成本与速度是否可接受评测 Agent 不是为了收集越多日志越好而是为了区分四件事它说了什么、它做了什么、环境发生了什么以及这些变化能否被证据验证。当 AI 只生成文字时答案是主要产物当 AI 开始行动时轨迹、状态和副作用也成为产物的一部分。
与 AI 一起工作 | 8. 为什么评价 Agent 不能只看最终答案
假设你让一个 Agent 汇总一份表格中的销售额它返回了正确数字。只看答案这次任务应该得满分。但如果查看执行记录可能会发现另一幅图景它读错了数据版本几次查询都失败了最后从一段旧对话里碰巧找到了同一个数字或者它虽然生成了正确文件却覆盖了另一列公式又或者它在发送结果时重复提交了两次。答案可以是对的过程仍然可能不安全、不稳定也无法复现。评价一个会行动的 Agent核心不再只是“它说对了吗”而是它是否在允许的范围内以可以复查的证据和可接受的成本稳定地完成了目标。从回答模型到行动系统普通问答的主要产物是一段文本评价自然集中在正确性、相关性和表达质量上。Agent 不同它可能读取文件、调用数据库、运行程序、修改状态、创建工单或向外部系统发送信息。这时最终回答只是系统行为的一部分。一次任务至少包含下面这条链用户目标任务与权限契约模型选择动作工具实际执行环境状态变化产生证据与产物验证目标与副作用最终回答只检查最后一个节点相当于验收装修时只看一张客厅照片却不检查水电、承重墙和施工记录。评价 Agent 的六个维度维度要回答的问题可观察证据任务结果用户真正要求的目标是否实现验收规则、最终产物、目标系统回读动作合规是否只使用允许的工具、对象和操作工具调用、参数、权限范围、拒绝记录状态与副作用环境发生了哪些预期或非预期变化文件差异、数据库状态、消息回执、审计日志证据充分性最终结论能否回到数据和验证结果来源、查询、时间范围、校验器输出、产物哈希成本与效率在多少时间、调用和资源预算内完成工具调用数、耗时、读取量、token 或费用恢复与稳定性失败后能否正确恢复重复执行是否一致错误记录、替代路径、回滚结果、多次运行结果这六个维度不是要求所有任务都记录同样多的信息。查询天气和修改生产数据库的风险不同轨迹粒度当然也不同。原则是风险越高、动作越不可逆越需要完整的状态、证据和回读。轨迹不是私有思维链一提到“看过程”很容易把它理解成要求模型公开全部内部推理。其实Agent 评测需要的主要是可观察执行轨迹而不是私有思维链。可观察轨迹包括Agent 收到了什么任务约束调用了什么工具参数是什么工具返回了什么环境状态怎样变化产生了哪些文件或记录验证器是否通过以及遇到错误后采取了什么恢复动作。这些信息能够被系统记录、重放或独立检查。至于模型内部如何逐字思考既不一定可获得也不是判断“文件是否真的写入”“消息是否重复发送”的必要条件。换句话说我们要审计的是行动和证据不是索取一篇看似合理的自我解释。三种常见的“幸运成功”1. 用错证据碰巧得到正确答案用户要求统计最新数据Agent 却读取了上月快照。因为目标数字刚好没有变化最终答案仍然正确。如果只看答案这次错误的数据绑定会被隐藏一旦数字变化同一流程就会失败。2. 主产物正确同时破坏了别处Agent 按要求更新了配置项目标功能也能运行但它重写整个文件时删除了用户尚未提交的其他修改。主任务“成功”副作用却不可接受。3. 第一次成功第二次重复执行Agent 创建工单后没有读取系统回执于是把网络延迟当成失败再次提交。两次请求内容都正确外部系统中却出现了重复记录。这三种情况说明最终答案正确只能证明“这一次输出看起来对”不能自动证明方法正确、操作安全或系统稳定。先设门禁再谈效率Agent 评测最容易犯的另一个错误是把所有指标直接加权成一个总分。例如答案正确率、速度、成本和工具调用数各占一部分。这样可能出现一种荒谬结果一个越权读取数据但速度很快的 Agent靠效率分抵消了安全问题。更稳妥的方法是先设门禁再在合格运行之间比较效率否是否是否是一次 Agent 运行任务结果通过?记录失败类型权限与副作用通过?判为不合格成功证据与状态可复查?判为不可验证成功进入合格运行集合比较成本、速度与稳定性正确性、安全性和证据充分性属于资格条件成本和速度属于合格之后的优化指标。两者不能互相抵消。不要把失败简单压成一个 0对 Agent 来说失败方式本身就是重要信息。最终答案轨迹与门禁更准确的判断正确通过稳定成功仍需多次运行确认复现性正确未通过幸运成功或不合格成功不能直接上线错误通过安全失败适合定位能力缺口和改进恢复策略错误未通过错误成功声明、越界或不可诊断失败优先修系统护栏一个能在权限不足时明确停止并报告 blocker 的 Agent可能比“想办法给出答案”却越权行动的 Agent 更值得信任。评测设计如果只奖励有答案就会反向鼓励系统隐藏不确定性和失败。一个最小轨迹记录模板对于会调用工具的任务可以从下面这组字段开始不必记录冗长对话run:task_id:可复现的任务标识input_snapshot:使用的数据或文件版本allowed_scope:允许的对象、动作和预算execution:tool_calls:工具、参数、结果和错误state_changes:修改前后状态与外部回执artifacts:文件、查询结果或报告位置verification:result_check:目标是否实现safety_check:是否越权或产生非预期副作用evidence_links:结论对应的来源与验证器结果recovery:失败原因、修复动作与最终状态模板的价值不在字段数量而在于让最终声明可以回到实际发生的动作。需要公开展示时还应脱敏凭证、个人信息和业务数据可审计不等于把敏感日志全部暴露。评价 Agent 前的 30 秒检查最终答案对应的真实目标是什么怎样独立验收Agent 使用了哪些工具、数据版本和权限范围目标系统的状态是否真的改变是否完成回读有没有修改无关文件、重复发送或越权访问等副作用每项关键结论能否绑定到来源、查询或验证结果失败时Agent 是正确停止、有效恢复还是静默换了一条不可靠路径多次运行能否稳定成功还是只有一次碰巧通过正确性和安全门禁通过后成本与速度是否可接受评测 Agent 不是为了收集越多日志越好而是为了区分四件事它说了什么、它做了什么、环境发生了什么以及这些变化能否被证据验证。当 AI 只生成文字时答案是主要产物当 AI 开始行动时轨迹、状态和副作用也成为产物的一部分。
