为什么给 AI Agent 做监控，老一套 Observability 几乎全失效了

如果你还在用传统的指标、日志、Trace 来监控 AI Agent，Phil Hetzel 的结论可能会让你后背一凉：不是你工具用得不够好，而是问题本身已经变了。这次分享直指一个残酷现实——Agent Observability 和传统 Observability，本质上不是同一类问题。

一个反直觉的判断：Agent 的问题，指标根本看不出来

Phil Hetzel 一上来就点破了行业里最容易被忽视的事实：传统 observability 成功的前提，是系统行为可预测。CPU、内存、延迟、错误率——它们都默认系统在重复做“同一件事”。

但 AI Agent 恰恰相反。它们每一次运行，路径都可能不同：不同的工具调用顺序、不同的推理步骤、不同的上下文理解方式。你即便看到了“成功率 99%”，也完全不知道那 1% 的失败是“轻微跑偏”还是“灾难性胡说”。

Phil 的一句话非常扎心：Agent 的失败往往不是性能问题，而是判断问题。而判断，是指标最不擅长表达的东西。

Trace 也救不了你：因为你根本不知道该“追踪”什么

很多工程师的直觉是：那我就多打点 Trace。Phil 直接泼了一盆冷水——这在 Agent 世界里依然不够。

传统 Trace 假设的是：请求 → 服务 A → 服务 B → 返回结果。但在 Agent 系统中，真正关键的不是“调用顺序”，而是：
- 它为什么选择这个工具？
- 它在当下的上下文里理解了什么？
- 它有没有忽略一个本该注意的信息？

这些问题，本质上是认知路径，而不是调用路径。Phil 强调，这是一个“定性问题远多于定量问题”的系统。你需要的不只是时间线，而是对决策合理性的判断。

Agent Observability 的核心，不是监控，而是评估

这也是 Phil 反复强调 Braintrust 选择的一条路：把 Agent observability 当成质量评估问题，而不是运维问题。

在 Agent 场景里，更重要的问题变成了：
- 这个回答“好不好”？
- 这个行为“合不合理”？
- 在相似任务下，它的表现是否一致？

这意味着，你需要引入人工或半自动的评估标准，甚至接受“没有绝对正确指标”的现实。Phil 直言，这比传统 observability 难得多，但也更真实。

为什么这条路这么难，但又绕不过去

在分享的后半段，Phil 总结了为什么 Agent Observability 是一个全新的难题：

第一，Agent 行为高度非确定性，复现问题本身就很难；
第二，问题往往不是“系统崩了”，而是“系统想歪了”；
第三，很多失败只有在业务语境下才算失败，机器很难自动判断。

也正因为如此，他对这个方向的判断很清晰：未来的 Agent 工程，会越来越像产品和研究的混合体，而不是纯工程问题。

总结

这场分享真正给从业者的提醒只有一个：别再指望用老工具解决新问题。如果你在做 AI Agent，真正该投入精力的不是多几个仪表盘，而是建立“什么才算好”的共识和评估机制。下一阶段拉开差距的，不是谁的模型更大，而是谁更早理解并解决了 Agent 的质量问题。一个值得你思考的问题是：如果你的 Agent 今天在“胡说八道”，你真的有办法第一时间发现吗？

关键词： AI Agent， Agent Observability， Observability， LLM 应用， Agent 评估

事实核查备注： 需要核查：1）演讲者姓名 Phil Hetzel 的拼写；2）Braintrust 的产品定位是否为 agent quality platform；3）视频发布时间为 2026-05-28；4）“traditional observability vs agent observability”的表述是否为原意概括而非逐字引用