轨迹评分（Trace Grading）
科普速读
- 它是什么： 轨迹评分按规则检查 Agent 运行中记录的操作和结果。
- 适合什么场景： 定位多步骤工作流和工具调用中的失败。
- 主要边界： 评分取决于评测规则和实际记录的事件。
概览
编码 Agent 可能调用测试工具、读取结果，再修改文件。轨迹可以显示系统记录到的这些事件，但不一定展示模型的私有推理。
核心定义
轨迹评分是按评分规则检查 Agent 运行记录的方法。轨迹可能包含请求、工具调用、返回结果、状态变化和时间信息。评分器只能评估系统实际记录的数据，分数本身不能证明最终回答正确。
背景与发展
最终回答可能无法说明多步骤任务在哪一步失败。因此团队会记录部分执行事件，用于调查错误、策略问题或重复操作。记录细节取决于埋点和系统设置。
工作机制（How It Works）
- 按需记录请求、工具调用、返回结果和耗时。
- 在系统支持时，用 trace 或 span 标识关联事件。
- 按评分规则检查可观察行为。
- 结合任务和策略复核被标记的事件。
- 条件相同时，比较不同版本的运行轨迹。
异常标记是调查线索，不是违规证明。
在软件测试与开发中的应用
可以用轨迹查找重复调用、失败命令或缺失结果，再对照最终代码差异和测试输出。
优势与局限
轨迹有助于定位失败，也能展示记录到的调用次数或延迟。事件记录不完整会隐藏重要步骤。过于僵化的规则可能拒绝有效的替代做法。轨迹也可能包含敏感数据。
与相近术语对比
日志通常以消息形式记录事件。Trace 会关联同一任务中的事件。轨迹评分按规则评估记录到的事件。结果评估则检查最终输出。
实施建议（Best Practices）
只记录评审所需数据。把事件关联到任务和代码版本。保护敏感信息。使用清晰的评分规则，并在判定失败前复核异常案例。
常见误区（Pitfalls）
不要声称轨迹展示了模型的私有推理。不要用分数代替对输出的检查。不要假设所有相关事件都已记录。
FAQ
轨迹评分能告诉团队什么？
它能帮助团队发现需要复核的已记录操作，但无法展示未记录的事件，也不能单独证明结果正确。