很多团队开始做 Agent 评测时,最先想到的往往是黑盒方式:

  • 给一个输入
  • 看最后输出
  • 打个分

这件事当然有价值。

但一旦你的 Agent 开始具备:

  • 多步推理
  • 多次工具调用
  • handoff
  • guardrail
  • 长链路 workflow

你很快就会发现一个问题:

只看最后答案,根本看不出它到底哪里做对、哪里做错。

这也是为什么我越来越觉得,Trace Grading 不是“高级玩法”,而是 Agent 系统进入工程优化阶段之后非常关键的一步。

如果只压成一句话:

黑盒评测只能告诉你“结果好不好”,Trace Grading 才更接近告诉你“过程哪里坏了”。

一、OpenAI 官方现在到底怎么定义 Trace Grading

截至 2026-04-18,OpenAI 的官方表述已经很明确。

在 OpenAI 的 Trace grading 文档里,定义是:

  • 给一个 agent trace 赋予结构化分数或标签
  • 评估 correctness、quality、adherence to expectations
  • 帮助识别 agent 做得好或做错的地方

更关键的一句是:

  • Unlike black-box evaluations, trace evals provide more data to better understand why an agent succeeds or fails.

这句话其实已经把本文标题回答完了。

因为它点出了一个根本差别:

  • 黑盒 eval 看“成败”
  • trace eval 看“成败是怎么发生的”

二、为什么黑盒评测到了 Agent 场景会越来越不够

黑盒评测最适合什么?

  • 单轮问答
  • 简单结构化输出
  • 明确输入和明确最终答案

但 Agent 系统的真正复杂度,不在最后一句回答,而在中间链路。

比如一个任务可能经历:

  1. 先规划
  2. 再搜索
  3. 再读文件
  4. 再调用工具
  5. 再 handoff 给别的 agent
  6. 最后才输出

如果最终答案错了,黑盒评测通常只能告诉你:

  • 这个任务失败了

但它回答不了这些更关键的问题:

  • 是规划阶段错了
  • 还是工具调用错了
  • 是检索召回有问题
  • 还是 handoff 丢了上下文
  • 是 guardrail 过严
  • 还是最后生成阶段改坏了

这就是为什么 Agent 不能只靠黑盒指标活着。

三、Trace 为什么是这件事的前提

Trace Grading 之所以成立,前提是你先有 trace。

OpenAI Agents SDK 的 tracing 文档里已经说明:

  • tracing 默认开启
  • SDK 会记录:
    • agent run
    • generation
    • function tool calls
    • guardrails
    • handoffs
    • custom events

这意味着一条 trace 不只是“有输入和输出”,而是包含了:

  • 一次 end-to-end workflow
  • workflow 里的关键 span
  • span 之间的顺序和层级

有了这个基础,你才有可能给“过程”打分。

四、为什么说 Trace Grading 是从“结果评测”走向“过程评测”

如果把两种方式画成图,会更好理解。

黑盒评测

输入

Agent 系统

最终输出

打分

这种方法的问题是:

  • 中间过程全黑
  • 你不知道错在链路哪一层

Trace Grading

输入

规划

工具调用

Handoff / Guardrail

最终输出

Trace

按步骤评分 / 标注 / 聚合分析

这时,评估对象就不只是结果本身,而是整条执行链。

五、Trace Grading 真正有价值的 4 个地方

1. 它能帮你定位错误来源

黑盒评测只能告诉你:

  • 输出错了

Trace Grading 则更有机会告诉你:

  • 搜索步骤找错了信息
  • 某个 tool call 参数不对
  • handoff 断了上下文
  • guardrail 拦截策略不合理

这就从“知道错了”升级成“知道错在哪”。

2. 它更适合做 Agent 编排优化

很多 Agent 的问题,不是模型本身不够聪明,而是 orchestration 出了问题。

比如:

  • 该先检索,结果先生成了
  • 该调用 A 工具,结果调了 B 工具
  • 该 handoff,结果没有 handoff

这些问题如果只看最终结果,很难稳定发现。

但 trace grading 很适合给这类中间行为贴标签。

3. 它更适合做回归分析

当你改了:

  • prompt
  • tool schema
  • handoff policy
  • guardrail rule

你不只是想知道最终成功率变没变,还想知道:

  • 工具误调用是不是少了
  • 检索错误是不是降了
  • guardrail 误伤是不是少了

Trace grading 在这里会比黑盒分数更有解释力。

4. 它更适合规模化优化

OpenAI 官方文档里直接提到:

  • Trace grading 对 error identification at scale 很有价值

这点非常关键。

因为一两个失败案例,你可以手工看。

但每天几千次 workflow 时,你需要的是:

  • 系统化打标签
  • 聚合分析
  • 找共性模式

Trace grading 恰恰就是往这个方向走。

六、举个很典型的例子:黑盒结果一样,问题完全不同

假设有两个 Agent 任务,最终都失败了。

任务 A

  • 最终输出错了
  • 原因是 web search 抓到了过时信息

任务 B

  • 最终输出也错了
  • 原因是 handoff 时没把客户编号传过去

如果你只做黑盒评测,这两个任务可能都只是:

  • failed

但从工程角度看,它们需要完全不同的修法。

这就是为什么只靠最终分数很容易误导优化方向。

七、最小代码示意:先有 trace,再谈 grading

OpenAI Agents SDK 的 tracing 文档里给了一个很典型的模式:

from agents import Agent, Runner, flush_traces, trace

support_agent = Agent(
    name="Support agent",
    instructions="Help users troubleshoot product issues."
)

def run_ticket(prompt: str) -> str:
    try:
        with trace("support_ticket_workflow"):
            result = Runner.run_sync(support_agent, prompt)
        return result.final_output
    finally:
        flush_traces()

这段代码的关键不是 Python 语法,而是它明确把一次任务包进了一条 trace。

有了这个前提,后面你才能去做:

  • trace inspection
  • trace grading
  • grouped analysis

如果没有 trace,grading 连抓手都没有。

八、从工程角度看,Trace Grading 最像什么

如果你熟悉传统软件工程,我会把它类比成:

  • 单元测试结果 = 黑盒评测
  • 带详细调用链和断点的失败分析 = Trace Grading

当然,这个类比不完全等价,但足够帮助理解:

  • 黑盒评测给你概览
  • Trace grading 给你诊断深度

最好的系统不是二选一,而是两者一起用。

OpenAI 文档的意思其实也很类似:

  • 用 traces 去 inspect workflow
  • 用 graders 给 traces 打标签
  • 再把这些结果拿去做 runs / evaluations

九、为什么它会变成 Agent 团队的日常工具,而不是研究玩具

我觉得未来做 Agent 的团队,迟早会经历这个阶段:

阶段 1

先看最终答案对不对。

阶段 2

开始发现:

  • 某些任务经常错,但错法不一样
  • 某些工具经常被调错
  • 某些 handoff 经常断

阶段 3

意识到:

不能只看结果,得看链路。

到了这个阶段,Trace Grading 就会自然进入工具箱。

因为它解决的是非常务实的问题:

  • 怎么在规模上发现共性错误
  • 怎么把错误归因到链路节点
  • 怎么知道改动到底改善了哪一层

十、截至 2026-04-18,我认为可以下的判断

基于 OpenAI 官方 tracing 和 trace grading 文档,我觉得下面几条已经很稳:

1. 黑盒评测对 Agent 仍然重要,但已经不够

它适合看总体结果,不适合深度诊断。

2. Trace Grading 的核心价值在于“过程可解释”

它让你更容易知道失败发生在 workflow 的哪一层。

3. 没有 tracing,就谈不上真正的 trace grading

因为 grading 的对象本来就是 trace。

4. Trace Grading 会越来越像 Agent 工程体系里的基础动作

尤其当团队开始做:

  • 回归评估
  • 编排优化
  • 错误归因
  • 规模化问题定位

十一、我的结论

所以,回到标题:

为什么黑盒评测救不了 Agent?

因为 Agent 真正复杂的,不只是最后一句输出,而是它中间那条经常很长、很脆、很容易出错的执行链。

黑盒评测可以告诉你:

  • 结果有没有过线

但 Trace Grading 更接近告诉你:

  • 哪一步把系统带偏了
  • 哪类错误在反复出现
  • 该优先修哪一层

如果让我用一句话概括:

黑盒评测是在看“考了多少分”,Trace Grading 更像是在看“到底是哪道题、哪一步推理出了问题”。

而对真正想把 Agent 做进生产的人来说,后者迟早会变得不可替代。

参考资料

  • OpenAI API Docs, Trace grading
    https://developers.openai.com/api/docs/guides/trace-grading
  • OpenAI Agents SDK (Python), Tracing
    https://openai.github.io/openai-agents-python/tracing/
  • OpenAI, New tools for building agents, 2025-03-11
    https://openai.com/index/new-tools-for-building-agents/
Logo

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容,并连接云服务、办公空间等稀缺资源,助你专注创造,无忧运营。

更多推荐