第 14 章：Agent 轨迹级评测方法论
第 14 章：Agent 轨迹级评测方法论
14.1 最终成功不等于过程可靠
一个代码 Agent 最终修复了 Bug，测试也通过了。但评测人员回放轨迹后发现，它在过程中删除了一个失败测试，又修改了无关配置文件，最后靠绕过检查得到了“成功”结果。
一个客服 Agent 最终告诉用户退款进度，但过程中调用了一个不该访问的内部工具，查询到了超出当前用户权限的数据。
如果评测只看最终结果，这两个任务都会被判为成功。但从企业级质量视角看，它们都存在严重风险。
Agent 与普通 LLM 应用最大的不同，是它会在环境中执行多步动作。它不仅生成答案，还会规划、调用工具、读写状态、处理异常、改变外部系统。最终结果只是高度压缩的信号，过程才决定系统是否安全、稳定、可调试、可进化。
因此，Agent 评测必须把 Trace 作为一等对象。
14.2 什么是 Agent Trace
Agent Trace 是一次 Agent 执行任务的结构化过程记录。
它至少要回答：
- Agent 接收到什么目标。
- 初始环境和状态是什么。
- 每一步做了什么决策。
- 调用了什么工具，参数是什么。
- 工具返回了什么。
- 状态如何变化。
- 是否发生错误、重试、循环或人工接管。
- 最终结果和终态是什么。
- 过程消耗了多少时间、Token 和外部资源。
一个最小 Trace 可以表示为：
图 14-1 Agent Trace 记录流程图
flowchart TD
START["接收任务目标与初始状态"] --> PLAN["任务规划"]
PLAN --> DECIDE{"决策下一步动作"}
DECIDE -->|tool_call| CALL["调用工具"]
CALL --> OBSERVE["获取工具返回/环境反馈"]
OBSERVE --> UPDATE["更新状态"]
DECIDE -->|response| RESP["生成回复"]
UPDATE --> RECORD["记录Step: action/observation/state_change"]
RESP --> RECORD
RECORD --> CHECK{"任务完成或终止?"}
CHECK -->|否| DECIDE
CHECK -->|是| FINAL["记录最终状态与成本/延迟"]
trace_id: trace_refund_001
case_id: agent_refund_status_001
goal: "查询退款进度并解释未到账原因"
initial_state:
user_authenticated: true
order_id: "ORDER_123"
steps:
- step_id: 1
action_type: tool_call
tool_name: refund_status_lookup
arguments:
order_id: "ORDER_123"
observation:
refund_status: "processing"
estimated_arrival_days: 2
state_change:
refund_status_known: true
- step_id: 2
action_type: final_response
content: "你的退款正在处理中，预计 2 个工作日内到账。"
final_state:
task_completed: true
privacy_violation: false
metrics:
latency_ms: 1800
token_cost: 1200
真正的生产 Trace 会更复杂，但核心思想不变：把 Agent 的过程从黑盒变成可回放、可评分、可归因的数据结构。
14.3 Trace Schema 的核心字段
| 字段 | 说明 |
|---|---|
| trace_id | 轨迹唯一标识 |
| case_id | 对应 Eval Case |
| goal | 用户目标或任务目标 |
| initial_state | 初始状态 |
| environment | 工具、权限、知识库、沙箱配置 |
| steps | 决策和动作序列 |
| action | 每一步动作 |
| observation | 工具、环境或用户返回的信息 |
| state_change | 状态变化 |
| error | 异常、失败、超时 |
| final_response | 最终回答 |
| final_state | 最终业务状态 |
| cost | Token、工具、沙箱资源成本 |
| latency | 总耗时和步骤耗时 |
每一步 Step 也应结构化：
| Step 字段 | 说明 |
|---|---|
| step_id | 步骤编号 |
| timestamp | 时间 |
| thought_summary | 可选的决策摘要，不要求保存完整思维链 |
| action_type | 回复、工具调用、状态更新、转人工等 |
| tool_name | 工具名称 |
| arguments | 工具参数 |
| observation | 工具返回或环境反馈 |
| state_before | 动作前状态 |
| state_after | 动作后状态 |
| evaluator_notes | 步骤级评分或诊断 |
这里需要注意：企业评测并不一定需要保存完整模型思维链。很多情况下，保存可解释的决策摘要、工具调用、输入输出和状态变化已经足够。Trace 的目标是支持评测、回放和归因，而不是无限制记录敏感内部信息。
14.3.1 Trace 采集的最小必要原则
Trace 越完整，越有利于归因；但 Trace 也会带来隐私、存储和安全风险。企业系统应采用最小必要原则。
至少应保存：
| 信息 | 原因 |
|---|---|
| 工具名称和参数 | 判断工具选择和参数是否正确 |
| 工具返回摘要 | 判断 Agent 是否正确使用结果 |
| 状态变化 | 判断多轮状态和业务终态 |
| 错误和重试 | 判断异常恢复 |
| 成本和延迟 | 判断效率和循环 |
| 版本信息 | 支持复现 |
不应无控制保存：
- 用户完整隐私信息。
- 不必要的敏感业务数据。
- 未脱敏的地址、手机号、证件号。
- 与评测无关的完整内部推理文本。
例如，客服 Agent 的 Trace 可以保存“用户已完成身份核验”和“工具返回退款状态为处理中”，不必保存完整身份证号或收货地址。Trace 是评测证据，不是数据泄露的新入口。
14.4 结果评测和过程评测的差异
结果评测回答：“任务最终成了吗？”
过程评测回答：“任务是如何完成的，这个过程是否可靠、安全、可复现？”
| 维度 | 结果评测 | 过程评测 |
|---|---|---|
| 评测对象 | 最终回答或最终状态 | 步骤、工具、状态、异常、成本 |
| 主要问题 | 答案是否正确，任务是否完成 | 路径是否合理，是否有风险动作 |
| 优势 | 简洁，贴近用户感知 | 可归因，可调试，可发现隐藏风险 |
| 局限 | 无法解释失败原因 | 采集和评分成本更高 |
Agent 场景中，两者必须结合。只看结果会漏掉危险过程，只看过程可能忽视最终用户体验。
14.5 轨迹评分维度
Agent Trace 可以从八个维度评分。
14.5.1 规划合理性
Agent 是否把任务拆成合理步骤，是否先做必要确认，再执行高风险动作。
客服退款场景中，合理规划应该是：识别意图、校验身份、查询订单、判断资格、解释结果或提交申请。跳过身份校验直接执行退款，就是规划失败。
14.5.2 步骤必要性
每一步是否必要。无意义的重复查询、反复询问用户已提供的信息、过度调用工具，都会增加成本和失败概率。
14.5.3 工具选择
是否选择了正确工具。比如退款进度问题应调用 refund_status_lookup，而不是直接调用 refund_submit。
14.5.4 参数准确性
工具选对不代表参数正确。订单号、用户 ID、退款原因、金额、时间范围都可能出错。
14.5.5 结果利用
Agent 是否正确使用工具返回结果。常见问题是工具返回“不可退款”，但 Agent 仍然承诺可以退款。
14.5.6 状态一致性
多轮对话中，Agent 是否正确维护身份、订单、用户目标和任务进度。
14.5.7 异常恢复
工具超时、返回空结果、权限不足时，Agent 是否能重试、降级、解释或转人工。
14.5.8 安全和副作用
Agent 是否越权访问、泄露隐私、执行不可逆动作，或在缺少确认时改变外部状态。
14.6 轨迹级评分 Rubric
可以用如下 Rubric 评估 Agent Trace：
| 维度 | 通过标准 | 失败信号 |
|---|---|---|
| 规划合理性 | 步骤顺序符合任务和业务约束 | 跳过必要确认、顺序错误 |
| 工具选择 | 每次工具调用都有明确必要性 | 工具错用、过度调用 |
| 参数准确性 | 参数来自可信上下文且字段正确 | 错订单、错用户、错金额 |
| 状态一致性 | 多轮状态前后一致 | 忘记已验证身份、丢失订单 |
| 结果利用 | 正确解释和使用 observation | 忽略工具返回、与返回冲突 |
| 异常恢复 | 能处理失败、超时和空结果 | 卡死、循环、错误承诺 |
| 安全边界 | 不越权、不泄露、不危险执行 | 未授权调用、高危副作用 |
| 成本效率 | 步骤数和资源消耗可接受 | 无效循环、重复调用 |
高风险维度不能被总分抵消。只要发生隐私泄露、越权工具调用或危险副作用，Trace 应直接失败。
14.6.1 步骤级评分示例
以会员部分退款为例，Trace 可以逐步评分：
| 步骤 | 实际动作 | 评分维度 | 结果 |
|---|---|---|---|
| 1 | 识别用户询问部分退款和积分 | 意图理解 | 通过 |
| 2 | 检索通用退款政策 | RAG 证据 | 部分通过，缺少会员积分规则 |
| 3 | 未调用退款规则工具 | 工具选择 | 失败 |
| 4 | 直接承诺积分不会扣回 | 安全边界 / 证据忠实 | 失败 |
| 5 | 未提示转人工 | 异常兜底 | 失败 |
最终回答失败不是唯一结论。更重要的是，Trace 说明错误发生在步骤 2-4：证据不足、工具策略缺失、生成阶段无依据承诺。这会直接指向第 21 章的分层归因。
14.6.2 首个关键失败步骤
Trace 评分不应只给出一串通过和失败标签。归因时最重要的是找到首个关键失败步骤。
首个关键失败步骤，是指如果该步骤正确执行，后续错误大概率不会发生的步骤。它不一定是最终显性失败的位置。
例如，客服 Agent 最终错误承诺“积分不会扣回”，显性失败出现在最终回答。但首个关键失败可能更早：
- Query 改写阶段丢失“会员积分”。
- 检索阶段没有召回积分规则。
- Agent 计划阶段没有调用退款规则工具。
- 生成阶段在证据不足时仍做确定承诺。
如果首个关键失败在第 2 步，修复方向应优先看 RAG；如果在第 3 步，应优先看工具策略和编排；如果前面证据和工具都正确，仍在第 4 步失败，才更可能是 Prompt 或模型忠实性问题。
因此，Trace 回放报告应同时记录：
| 项目 | 作用 |
|---|---|
| first_critical_failure_step | 定位首个关键失败 |
| downstream_failures | 记录后续连锁错误 |
| root_cause_hypothesis | 形成根因假设 |
| counterfactual_check | 验证如果修正该步骤，结果是否改善 |
这能避免团队只修最终回答，而忽略真正导致失败的中间链路。
14.7 沙箱与动态环境
Agent 评测不能只在静态文本上完成。凡是涉及工具、代码、浏览器、数据库、文件或业务系统状态变化的任务，都需要动态环境。
沙箱要提供：
- 初始状态：订单、账户、文件、数据库、网页等。
- 可用工具：工具 Schema、权限、返回模拟。
- 状态变化：工具调用后环境如何改变。
- 终态检查：任务是否真的完成。
- 隔离机制：避免评测影响真实生产系统。
- 日志和 Trace：记录每一步动作。
客服 Agent 沙箱可以模拟订单、退款状态、用户身份、工具返回和权限规则。代码 Agent 沙箱可以包含仓库、测试、依赖、文件系统和命令执行权限。
沙箱最大的问题是保真度。环境过于简化，Agent 在评测中表现很好，生产中仍会失败。环境过于复杂，又会导致成本和维护压力过高。评测团队需要明确：哪些环境细节必须真实，哪些可以模拟。
14.7.1 沙箱中的副作用隔离
动态评测必须处理副作用隔离。Agent 如果能提交退款、修改账户、发送通知或创建工单，评测环境必须保证这些动作不会影响真实用户和生产数据。
副作用隔离至少包括：
| 隔离项 | 要求 |
|---|---|
| 数据隔离 | 使用沙箱订单、沙箱用户和沙箱权益 |
| 工具隔离 | 提交类工具指向模拟服务或预提交接口 |
| 状态回滚 | 每个 Case 运行后能恢复初始状态 |
| 幂等控制 | 重复调用不会造成重复业务动作 |
| 审计标记 | 所有评测动作都带有 eval_run_id |
| 权限限制 | 评测账号不能访问生产敏感数据 |
没有副作用隔离，Agent 评测会变成生产风险；隔离过度简化，又会让评测失真。出版级的轨迹评测必须同时说明这两个边界：既要安全隔离，也要保留足够真实的业务状态和错误模式。
14.8 沙箱保真度检查清单
| 检查项 | 问题 |
|---|---|
| 工具行为 | 工具返回是否接近真实系统 |
| 错误模式 | 是否模拟超时、空结果、权限失败 |
| 状态变化 | 工具调用后状态是否真实改变 |
| 权限边界 | 是否模拟不同用户和角色权限 |
| 数据分布 | 测试数据是否覆盖真实业务状态 |
| 并发和时序 | 是否考虑重复提交、状态延迟 |
| 审计日志 | 是否保留可回放记录 |
| 成本约束 | 沙箱资源是否能支撑规模化评测 |
沙箱不是越真实越好，而是要对评测目标足够真实。
14.8.1 沙箱保真度分级
沙箱可以按保真度分级，避免所有任务都使用最高成本环境。
| 等级 | 特征 | 适用场景 |
|---|---|---|
| L1 静态模拟 | 固定输入和固定工具返回 | Smoke、格式和简单工具选择 |
| L2 状态模拟 | 工具调用会改变状态 | 退款进度、订单状态、多轮流程 |
| L3 异常模拟 | 包含超时、空值、权限失败 | 异常恢复、重试、转人工 |
| L4 生产近似 | 接近真实权限、数据分布和延迟 | 发布前高风险回归 |
| L5 受控线上 | 小流量灰度和真实监控 | 最终真实分布验证 |
客服 Agent 的普通政策问答可以用 L1 或 L2；退款工具和身份校验应至少用 L3；涉及提交类工具的发布前评测，应接近 L4。这样可以在成本和保真度之间平衡。
14.9 长程任务评测
长程 Agent 任务的难点是错误会累积。早期一个小错误，可能在后续多步中被放大。
长程任务评测要关注：
- 分阶段成功率。
- 中间状态正确性。
- 关键步骤通过率。
- 错误恢复能力。
- 循环和卡死检测。
- 成本随步骤增长的放大。
代码 Agent 修复真实 Issue 时，不能只看最终测试是否通过，还要看：
- 是否理解 Issue。
- 是否定位到正确文件。
- 是否修改最小必要代码。
- 是否运行相关测试。
- 是否避免无关修改。
- 是否保留原有行为。
长程任务可以拆成里程碑评分。每个关键状态都要可检查，而不是只等最后结果。
14.9.1 长程任务切片
长程任务不应只形成一个大 Case。更好的方式是切成可评测片段。
| 切片 | 评测目标 |
|---|---|
| 目标理解切片 | 是否正确理解用户最终目标 |
| 计划切片 | 是否拆成合理步骤 |
| 工具切片 | 每个关键工具调用是否正确 |
| 状态切片 | 中间状态是否符合预期 |
| 异常切片 | 工具失败后是否合理恢复 |
| 终态切片 | 最终业务状态是否完成 |
代码 Agent 修复 Bug 可以切成“定位文件”“提出修复假设”“修改代码”“运行测试”“解释变更”。客服 Agent 退款流程可以切成“身份核验”“订单查询”“规则判断”“工具执行”“结果解释”。切片后，评测结果更容易归因，也更适合构建 Regression Set。
14.10 多 Agent 协作评测
多 Agent 系统增加了新的失败模式：
- 角色边界不清。
- 信息传递丢失。
- 多个 Agent 相互强化幻觉。
- 循环讨论。
- 决策责任不明确。
- 工具权限分配混乱。
多 Agent 评测需要额外关注：
| 维度 | 评测问题 |
|---|---|
| 角色分工 | 每个 Agent 是否承担清晰职责 |
| 信息传递 | 关键信息是否准确传递 |
| 决策收敛 | 是否能形成最终行动 |
| 幻觉传播 | 错误信息是否被其他 Agent 接受 |
| 协作效率 | 是否出现无意义反复 |
| 权限隔离 | 是否越权调用其他角色工具 |
多 Agent 不是本书主线，但这些原则可以复用到复杂企业 Agent 系统。
14.11 Trace 回放与归因
Trace 的价值不只是评分，更重要的是归因。
当客服 Agent 错误承诺退款时，Trace 回放可以帮助团队判断：
- 是否召回了正确政策。
- 是否调用了退款资格校验工具。
- 工具返回是否正确。
- Agent 是否忽略了工具结果。
- 是否跳过了身份校验。
- 错误发生在哪一步。
没有 Trace，团队只能看最终回答猜原因。有 Trace，团队可以把错误定位到具体步骤。
Trace 还支持消融实验：
- 固定检索结果，看模型是否仍答错。
- 固定工具返回，看编排是否仍失败。
- 替换 Prompt，看规划是否改善。
- 替换模型，看工具调用是否改善。
这些实验能把“Agent 表现不好”拆成可修复的工程问题。
14.11.1 Trace 回放报告
Trace 回放应输出一份简短诊断报告，而不只是展示日志。
报告至少包含：
| 字段 | 说明 |
|---|---|
| case_id | 对应 Case |
| failure_step | 首个关键失败步骤 |
| affected_layers | 涉及模型、Prompt、RAG、Tool、Agent 或业务规则 |
| evidence | 支撑判断的 Trace 片段 |
| counterfactual | 对照实验结果 |
| suggested_fix | 修复方向 |
| regression_asset | 是否进入回归集 |
退款误答的回放报告可以指出：首个关键失败步骤是检索没有召回会员积分规则；次要失败步骤是 Agent 没有调用退款规则工具；注入正确证据后模型可正确回答，说明主修复方向是 RAG Query 和工具策略，而不是直接微调模型。
14.12 交付物一：Agent Trace Schema
| 字段 | 类型 | 说明 |
|---|---|---|
| trace_id | string | 轨迹唯一标识 |
| case_id | string | 对应 Eval Case |
| goal | string | 任务目标 |
| initial_state | object | 初始状态 |
| environment | object | 工具、权限、知识库、沙箱 |
| steps | list | 步骤序列 |
| final_response | string | 最终回答 |
| final_state | object | 终态 |
| metrics | object | 成本、延迟、步骤数等 |
| evaluation | object | 轨迹评分和失败标签 |
Step Schema：
| 字段 | 类型 | 说明 |
|---|---|---|
| step_id | number | 步骤编号 |
| action_type | enum | response / tool_call / state_update / handoff |
| tool_name | string | 工具名 |
| arguments | object | 工具参数 |
| observation | object | 返回结果 |
| state_before | object | 动作前状态 |
| state_after | object | 动作后状态 |
| error | object | 错误信息 |
| latency_ms | number | 步骤耗时 |
| cost | object | 资源消耗 |
14.13 交付物二：轨迹级评分 Rubric
| 评分维度 | 评分方式 | 门禁建议 |
|---|---|---|
| 任务规划 | 1-5 分 | 低于 3 进入人工复核 |
| 工具选择 | pass / fail | 核心工具错误可阻断 |
| 参数准确性 | 字段级准确率 | 高风险参数错误阻断 |
| 状态一致性 | pass / fail | 身份和权限状态错误阻断 |
| 异常恢复 | 1-5 分 | 连续失败无恢复进入回归 |
| 安全边界 | pass / fail | 越权、泄露、危险操作一票否决 |
| 成本效率 | 数值指标 | 超阈值进入软门禁 |
14.14 交付物三：沙箱保真度检查清单
| 类别 | 检查问题 |
|---|---|
| 初始数据 | 是否覆盖真实业务状态 |
| 工具模拟 | 工具返回是否包含成功、失败和异常 |
| 权限系统 | 是否模拟不同角色和身份状态 |
| 状态变化 | 操作后状态是否真实改变 |
| 终态校验 | 是否能判断任务是否真正完成 |
| 安全隔离 | 是否避免影响生产系统 |
| 可观测性 | 是否记录完整 Trace |
| 可扩展性 | 是否能批量运行 |
14.15 本章小结
Agent 评测不能只看最终答案。过程、状态、工具、副作用和环境同样重要。
Trace 让 Agent 从黑盒变成可回放系统。它支撑三类能力：
- 过程评分：判断路径是否合理、安全、高效。
- 失败归因：定位错误发生在哪一步。
- 优化闭环：把问题转化为 Prompt、RAG、工具、编排或数据改进。
有了完整的评测方案，下一章我们要回答一个关键问题——评测结果本身可信吗？统计方法和 Meta-Eval 如何帮我们避免被分数误导。