基于轨迹而非答案评估 Agent

评分缺口

大多数 agent 基准仍然像选择题考试一样评分：运行 agent，把它的最终答案与参考答案比对，给出分数。这把一整条多步轨迹压缩成了一个比特。两个 agent 都可以得 1.0 分，而其中一个执行了干净、可逆的操作，另一个删除了生产表、重试了四次、然后碰巧得到了正确答案。如果基准看不到这个差别，交付 agent 的团队也看不到。

这不是理论上的担忧。Agent 框架越来越多地被用于有真实副作用的任务：写入数据库、调用支付 API、修改基础设施、发送消息。在这些场景中，路径不是实现细节。它是产品的一部分。忽略它的基准是在为错误的目标做优化。

为什么最终答案评分会失效

最终答案评分假设答案就是任务。对于问答，这大致成立。对于 agentic 工作，则不然。设想一个研究 agent 被要求核对两个数据集。一条轨迹读取两个文件，计算差异，写出摘要。另一条读取文件，把中间文件写到错误的目录，用修正后的路径重试，读取了一份过期的缓存副本，最后产出了相同的摘要。输出相同。可靠性不同，成本不同，影响范围不同。

在生产中至关重要的三个属性，对仅输出评分是不可见的：

成本。 Token 用量、工具调用次数和实际耗时延迟。一个工具调用就解决任务的 agent，和九次调用才解决的 agent，不是等价的产品，即使答案一致。
副作用。 每一个被触及的外部系统，以及它们最终的终态。不记录这些的基准无法区分一个只读 agent 和一个修改了状态然后清理掉的 agent。
可复现性。 同一个 agent 在同一个任务上跨种子是否产生相同的轨迹。一次成功的运行是轶事，不是测量。

应该记录什么

评估的单位应该是轨迹，而不是答案。这意味着要对 agent 进行插桩，使其输出结构化的动作轨迹。至少，每一步应该记录：

工具名称及其完整参数，而不只是名称。write_file 没有信息量；write_file(path="/etc/hosts", mode="append") 才有。
工具返回的观察结果，包括错误载荷。
每一步的时间戳和 token 计数。
本次运行触及的每个外部系统的终态：创建或修改的文件、插入的行、发送的消息、预置的资源。

一个最小的轨迹 schema 可能如下所示：

Fiber optic cables patch panel

{
  "run_id": "...",
  "task_id": "...",
  "seed": 7,
  "steps": [
    {
      "index": 0,
      "tool": "read_file",
      "args": {"path": "data/input.csv"},
      "observation": {"status": "ok", "bytes": 4096},
      "tokens_in": 812,
      "tokens_out": 44
    },
    {
      "index": 1,
      "tool": "write_file",
      "args": {"path": "out/summary.md", "mode": "create"},
      "observation": {"status": "ok"},
      "tokens_in": 921,
      "tokens_out": 130
    }
  ],
  "terminal_state": {
    "files_created": ["out/summary.md"],
    "files_modified": [],
    "external_calls": []
  },
  "retries": 0,
  "backtracks": 0
}

确切的 schema 不如纪律重要：参数、观察结果和终态。没有参数，你无法审计意图。没有终态，你无法审计后果。

重试和回溯次数是衡量脆弱性的有用代理指标。一个在三次重试后得到正确答案的 agent，比一个直接得到答案的 agent 更脆弱，也更容易在分布偏移下失败。这些计数应该与结果一起报告，而不是隐藏在结果内部。

对轨迹评分

一旦记录了轨迹，评分就变成一个向量而不是标量。四个维度覆盖了大多数生产关注点：

结果。 Agent 是否达成了任务的成败条件？这是熟悉的二元或分级分数。
路径有效性。 轨迹是否遵守了任务的约束？使用的工具是否恰当，参数是否格式良好，中间步骤是否连贯？
副作用卫生。 非预期的外部系统是否未被触及？预期的变更是否恰好应用一次、幂等地、以正确的顺序？
成本。 Token、延迟和工具调用，相对于参考轨迹或预算进行归一化。

报告向量比报告标量信息量更大，但它让排行榜变得复杂。一个诚实的权衡：向量分数更难排名。关心副作用的团队和关心延迟的团队会对各维度赋予不同的权重。基准应该暴露各个分量，让使用者自行聚合，而不是内置一个假装普适的单一权重。

第二个权衡：轨迹评分需要插桩环境。你无法在不沙箱化或不构建适配器的情况下，为任意外部系统记录终态。这是真实的工程成本，也是许多基准回避它的原因。

留出环境与方差

轨迹评分只有在 agent 无法记住测试夹具时才有效。留出环境就是机制。基准应该生成或保留 agent 从未见过的任务实例，最好带有随机化参数：文件名、目录布局、API 响应和初始状态。如果 agent 在训练或调优期间见过该夹具，高分衡量的是记忆，而不是能力。

方差报告同样重要。单次运行不是测量。Agent 是随机系统：采样温度、工具调用顺序和环境时序都会引入方差。基准应该在多个种子上运行每个任务，并报告分数的分布，而不只是均值。高均值伴随长尾失败，与略低均值伴随紧密方差，是不同的产品。

Fiber optic cables

基准生态正在朝这个方向成熟。对新的评估工作的报道，例如 Vals 在 AI 基准方面的工作，反映了一个更广泛的共识：评估 agent 不等于评估模型。仅输出排行榜正在被过程感知的评估所补充，而且理由充分。

一个具体机制：沙箱化回放测试台

实现轨迹评分的一种实用方式是沙箱化回放测试台。测试台为每次运行预置一个全新环境：一个带有文件系统的容器、一个 mock API 服务器，以及一个阻止或记录出站调用的网络策略。Agent 在其中运行。完成后，测试台对环境做快照，与初始状态做差异比较，并同时输出动作轨迹和终态差异。

由于环境是临时的，副作用是可观察且受控的。由于 API 服务器是 mock 的，响应可以按种子随机化。由于网络策略是显式的，非预期的外部调用会被记录，而不是被静默允许。然后测试台按上述向量对运行评分。

这比让 agent 对照静态答案键运行要费事。它也是让关于 agent 可靠性的主张经得起生产检验的最低要求。

应该报告什么

一份轨迹感知的基准报告应该按任务包含：

结果分数，并明确陈述成败条件。
路径有效性标记，并列举具体的违规项。
副作用差异，汇总为创建、修改和删除资源的计数。
成本，按 token 和工具调用细分。
重试和回溯次数。
跨种子的方差，以分布而非单一数字报告。

跨任务聚合后，这给出的是一个画像而不是排名。画像更难做营销。它们对于判断一个 agent 是否安全可部署也更有用。

结论

只对最终输出打分的基准，会系统性地奖励那些通过不安全或不可复现路径得到正确答案的 agent。修复方法不是更好的答案键。而是不同的分析单位：轨迹，包含参数、观察结果、终态和成本。按向量评分。使用留出环境。报告方差。把单次运行当作轶事。

权衡是真实的：轨迹评分构建成本更高，也更难总结。但替代方案是一个无法区分谨慎 agent 和幸运 agent 的排行榜，以及基于错误信号做出的部署决策。

基于轨迹而非答案评估 Agent：一份基准设计说明