AI Agent最容易翻车的不是模型，而是你没做这套 Evals

Laurie Voss 在这场演讲里抛出一个让很多工程师不舒服的事实：真正决定 AI Agent 能不能上线的，从来不是模型有多强，而是你有没有一套“能发现失败”的评估体系。这不是学术 talk，而是一条从 demo 到 production 的血路。

最反直觉的一点：Eval 不是为了证明你做对了

演讲一开始，Laurie Voss 就把很多人的认知拧了个 180 度。她说，Eval 并不是用来“证明模型很强”，而是用来“尽早发现它会怎么失败”。

很多团队在做 Agent 时，默认逻辑是：先把能力堆上去，再看看效果。Eval 被当成最后一道形式化流程，甚至是写给老板看的 KPI。但在真实系统里，Eval 的真正作用恰恰相反——它是用来不断暴露问题的。

她在定义 Eval 时非常克制：不是火箭科学，也不是复杂统计，本质上就是“你能不能系统性地判断一次输出是好还是坏”。一旦你接受这个定义，Eval 就从“学术包袱”变成了“工程必需品”。

能力评测、回归测试、人类判断，其实缺一不可

Laurie 把 Eval 明确拆成几类：能力型 Eval、回归型 Eval，以及人类参与的评估。很多团队只做其中一种，结果系统一上线就开始漂。

能力 Eval 解决的是“它现在能不能做这件事”；回归 Eval 解决的是“我改了代码，它有没有悄悄变差”；而人类评注解决的是“那些模型自己永远解释不清的灰色地带”。

她强调，一个“真的能用”的 Eval 套件，一定是三者同时存在的。更关键的一句话是：任何使用 LLM 的应用，最终都会走到这一步。你今天觉得是大厂才需要的复杂流程，明天就会成为你系统稳定性的底线。

Agent 的 Eval，比普通 LLM 应用难一个数量级

当话题进入 AI Agent，难度立刻上升。Laurie 用了一个非常形象的说法：你以为在 eval 一个模型，其实是“LLM 一层套一层”。

Agent 有规划、有工具调用、有中间推理步骤，每一步都可能成功，但最终结果依然是错的。这意味着你不能只看最终输出，而必须看 trace，看每一次决策是怎么发生的。

她现场展示了在 Phoenix Cloud 里捕获 agent trace 的过程：每一个调用、每一次中间结果，都会成为之后写 Eval 的素材。Eval 不再是单点判断，而是一层层叠加的判断体系——就像她说的，stacking your eval layers。

没有数据怎么办？合成数据不是权宜之计，而是策略

一个特别“接地气”的问题被点出来：在你还没上线、还没用户的时候，Eval 用什么数据？

Laurie 的答案非常直接：先看你现有的 trace，没有就用合成数据。她并没有把 synthetic data 描绘成完美方案，而是明确说——这是 next best bet。

关键不在于数据是否“真实”，而在于你是否能通过这些数据，持续构建失败案例。她有一句非常值得反复咀嚼的话：今天生产环境里的失败，会变成明天的测试用例。这意味着 Eval 体系是会随着系统一起“学习”的。

真正的完整闭环：不是写完 Eval 就结束

在演讲最后，Laurie 把整个流程压缩成一个闭环：instrument、trace、eval、human annotate。

很多团队卡在“写完 Eval 就算完成”，但她反复强调，人类标注并不是落后的做法，而是 Agent 时代不可替代的一环。Eval 本身也在进化，而你只能通过持续的人类反馈，让系统知道什么是真正的失败。

她给出的最终建议也非常工程化：从小开始。不要一上来就试图覆盖所有场景，先让你的 Eval 能真实反映一个问题，然后再扩展。

总结

这场演讲最重要的启发是：AI Agent 的竞争力，正在从“谁的模型更强”转向“谁更早、更系统地发现失败”。Eval 不再是锦上添花，而是能不能上线、敢不敢迭代的基础设施。如果你正在做 Agent，今天就该问自己三个问题：我现在能看到多少失败？这些失败会不会变成测试？下一个版本会不会悄悄变差？真正成熟的团队，答案都写在 Eval 里。

关键词： AI Agent， LLM Eval， Agent评估， Phoenix， 大语言模型

事实核查备注： 需要核查：演讲者姓名拼写（Laurie Voss）、使用的工具名称是否为 Arize Phoenix / Phoenix Cloud、视频发布时间（2026-05-14）、演讲中对 Eval 分类的原始表述。