178
0📝 本期播客简介
本期我们克隆了：AI Engineer · How to Know If Your AI Agent Is Any Good: Evals With Phoenix & Claude — Laurie Voss, Arize AI
原内容更新时间：2026-10-17
一份特斯拉报告把分析师建议的比例加出了 116%，还信心满满地写进结论。怎样才能不靠“看着不错”就把 AI Agent 上线？Laurie Voss 用一个金融分析 Agent 示范：追踪它每一步做了什么，再用代码评估、大模型裁判和人工检查找出问题。
这一集从错误分析一路讲到自定义评估、验证裁判、对照实验和 CI。改了 Prompt，结果可操作性评估从 16 份里 5 份通过，升到 48 份全部通过；但忠实度仍然很差。换成 Haiku 5.5 后，忠实度提高了 3 倍多，成本却变成 4 倍，而且模型几乎每次都建议持有。分数变好，真的代表 Agent 变可靠吗？
👤 本期嘉宾
Laurie Voss 是 Arize AI 的开发者关系负责人，也是 npm 联合创始人。他早年从事 JavaScript，如今主要研究 AI 应用如何可靠运行。本集他用 Claude Agent SDK 和 Phoenix 搭建金融分析 Agent，并以开发者关系负责人的实践经验，演示如何追踪 Agent、设计评估，并把检查接入 CI。
⏱️ 时间戳
准备环境与评估缘起
02:00 从“看着不错”上线，到改 Prompt 后担心回归
02:38 这套流程要把评估接进 npm test 和 CI
追踪与评估的基本思路
03:42 Trace 是日志，eval 是对运行记录做测试
05:53 新模型几周就来一次，没评估就难判断能否升级
Agent错误与追踪实践
09:20 Agent 最棘手的错误之一：错得很自信
20:25 一次运行要上网搜索、推理，再生成报告
从追踪中发现问题
28:33 写评估之前，先从头读十几条追踪记录
33:03 特斯拉报告里的分析师建议比例加起来是 116%
代码评估与内置裁判
38:21 股票代码对不对，几毫秒就能用代码查
选择并编写有效评估
45:52 16 份报告全被正确性裁判判错，问题出在它无法核实最新数据
52:58 选对评估，比调好评估更重要
验证裁判并用实验改进
1:04:25 裁判也是分类器，得拿人工判断来核对
1:20:47 可操作性评估从 5/16 提升到 48/48，忠实度却没跟上
模型升级与CI落地
1:23:03 Haiku 5.5 忠实度提高 3 倍多，花费却是 4 倍
1:25:11 把股票代码和可操作性检查放进 npm test
🌟 精彩内容
💡 116% 的分析师建议，Agent 也能写得理直气壮
特斯拉报告把两次网页搜索中、并非来自同一数据集的比例拼在一起，算出分析师建议比例合计 116%。问题不是搜索结果有误，而是 Agent 没有正确推理；不看追踪记录，很难知道错在哪一步。
"有 116% 的分析师持某些观点。"
💡 改好一项，不代表整体可靠
改进 Prompt 后，可操作性评估从 16 份里 5 份通过，升到 48 份全部通过；但忠实度只从 16 份里 2 份通过变成 48 份里 3 份通过。要求 Agent 给出明确建议，修好了一个问题，却没解决它编造数据的问题。
"只改了 prompt 里的 1 行，就解决了我们衡量的那个问题，但没解决 agent 瞎编的问题。"
💡 新模型更稳定，也可能只是更保守
Haiku 5.5 的忠实度是 Haiku 4.5 的 3 倍多，但成本变成 4 倍。它几乎每次都建议持有：建议一致了，却未必更有用。
"做到这一点的办法就是每次都选同一个答案。"
💡 全部评估都塞进一个裁判，反而难定位问题
一个“上帝评估器”同时检查准确性、语气、完整性、格式和规则，失败时却说不清是哪一项出了问题。Laurie 建议按维度拆开评估，再区分哪些是发布底线、哪些只是改进目标。
"你要测试多少个维度，就拆成多少个评估器。"
💡 评估标准要能被人核对
大模型裁判不是天然可信：Laurie 用人工标注的黄金数据集和裁判对照，还发现自己有时没按亲手写下的标准判断。评估结果要能解释哪里错了，修改也要用相同数据和指标做实验验证。
"你要的是一个比另一个人来当裁判表现更好的模型。"
🌐 播客信息补充
本播客采用原有人声声线进行播客音频制作，也可能会有一些地方听起来怪怪的
使用 AI 进行翻译，因此可能会有一些地方不通顺
如果有后续想要听中文版的其他外文播客，也欢迎联系微信：iEvenight
