AI 把三个分析师比例加出 116%，格式还漂亮得像模像样。Arize 的 Laurie Voss 说，这种错只能靠 trace 抓，光看输出永远看不出来。他还发现模型升级后忠实度涨了三倍，代价是 45 次里 41 次建议持有。 https://x.com/i/article/2115018455380590592

【X 长文】npm 创始人 Laurie Voss：如何判断你的 AI 智能体是否足够优秀

一份 AI 写的特斯拉研报里，分析师共识长这样：50% 建议买入，52.6% 建议持有，13.1% 建议卖出。三个数加起来 116%。

写这份报告的 agent 一点没觉得有问题，格式漂亮，语气专业，该有的段落一段不少。它把两次不同网页搜索的结果拼在一起加总。

这期是 AI Engineer 纽约场的 workshop，讲的人叫 Laurie Voss，npm 的联合创始人，现在在 Arize AI 管开发者关系。一个半小时他只讲一件事：你怎么知道 agent 行不行，改完又怎么证明它变好了。

先读十几条记录，再写第一个评估

他把两个词分得很清楚。trace 就是日志，eval 就是测试，eval 是对 trace 跑测试。差别在 trace 记得有多细：每一轮模型调用、每一次工具调用、输入输出、耗时、token。

大多数 AI 功能上线完全不是这样。做出来，自己试三次，看着不错，发了。他说试三次不算一套测试。单元测试行不行？不行，同一个 prompt 每次跑出来的文字都不一样，两个完全不同的回答可以都对，一千个不同回答也能全对，没有哪个预期字符串能拿来断言。于是所有人退回人眼看，人眼没法放进 CI，那里没人盯着。

所以他每次都从同一个地方开始：先读记录，从头到尾读十几条，看输入、输出，哪一步不对。没搞明白 agent 会怎么出错就去做自动化，最后只会衡量那些好衡量的东西。

读法有讲究。先开放式编码，用大白话写看到的情况，好在哪要说清原因，坏在哪也要说清原因；再主轴编码，把笔记归堆。他读不动，就把活交给 Claude Code，agent 九分钟读完所有记录，还自己造了个类别名叫 harness 泄露，说的是 agent 老来问它没权限做的事。

错得很自信，或者比你的规则更聪明

116% 那份的错法值得拆开看。agent 做了两次搜索，一次搜到 50% 的人持某个观点，一次搜到 13% 的人持另一个观点，它把两批不同数据集里的数字直接加总，然后写进结论。两次搜索各自都对，错在推理。只有看记录才知道错在哪一步。

反方向也有。Anthropic 内部跑过一个模拟客服对话的基准，任务是帮用户改航班。按设定这个任务应该失败，因为用户坐的是经济舱，经济舱不许换座位。结果模型发现可以先升到头等舱，头等舱能换座位，换完再降回经济舱，用户的诉求就这样办成了。测试判它不通过，因为它本来不该做到这件事。

所以他对写评估提了个硬要求：评结果，别评步骤。别去检查 agent 有没有先调搜索再调另一个工具，那样太死板，你会把一个比你会想办法的系统按住。

免费的代码评估，和一上来全错的正确性裁判

代码评估最省事，没有模型没有 API 调用，一个函数对字符串做断言，几毫秒跑完，不花钱。第一个检查土到不行：报告里到底有没有提到我问的那只股票。有 2 份没过，一份特斯拉报告没提特斯拉，一份亚马逊报告没提亚马逊。问的是 AWS 盈利能力，agent 就只写 AWS，把亚马逊这家电商公司丢了。

再往上得请大模型当裁判。他从 Phoenix 内置的正确性评估开始，16 份报告全被判成不正确，一个不剩。裁判拿自己的知识判断对不对，而它知识截止在大概 1 月，agent 写的是 10 月的股价，在它看来这是未来的事，那一定是幻觉。16 条解释里有 7 条在抱怨自己没法核实最新数据。

他换了个问法，问忠实度：根据你手上这份调研资料，报告说得通吗，结论有依据吗。这个问法裁判答得上来，搜索结果的原文和调研笔记都在记录里，喂进去它就能核对。16 份里 14 份被判不忠实，但解释有用多了：Azure 是第二大云厂商这说法没有上下文支持，2027 年的目标在所有搜索结果里都找不到。

同一批输出换一道题，一边全零，一边能用了。他的结论是，选对评估比调好评估重要得多。

裁判也得被测试

裁判本质上是机器学习里的分类器，得有人工标注的答案来对账。他按给裁判的同一套标准把 16 份报告逐条标了一遍，这叫黄金数据集。标到后面他发现自己作弊：评分标准明明写着报告必须列出具体风险，一份微软报告一个风险都没提，他还是标了能据此采取行动。裁判比他还严格。

给裁判看示例他也测了。带示例跑三轮，没有一轮全对，最好的是 16 份里 15 份跟他一致；去掉示例，两轮 16 份全一致，剩一轮差一份。去掉反而更准，是因为示例里写着必须列风险，裁判照示例执行，人却在偷懒。

也别指望裁判跟你百分之百一致。两个真人专家拿同样的输出和标准打分，科恩卡帕系数常常只有 0.2 到 0.3，比随机高不了多少。他要的裁判不必每次都一致，只要比另一个真人裁判更靠谱。

还有个自查：判不通过的结果，得能一眼看出 agent 错在哪。你看了说这没问题啊，那大概率是评估有问题。一个测 agent 能不能复现论文的基准里，Opus 4.5 最初只拿到 42%，后来有人翻实际交互，发现模型答对了，只是测试要六位精度，它给了四位。测试修好，分数变成 95%。

一行 prompt，把 5/16 变成 48/48，编数据一点没动

看完记录再改 prompt，就不是猜了。每处改动都对应一个发现的问题：裁判说没给建议，就要求给出买入、持有或卖出的明确结论；裁判说提了风险没证据，就要求提风险时给数据支持；记录里 agent 三番五次想把报告存成文件，那就告诉它直接回复内容。

结果可操作性从 16 份里 5 份通过，变成 48 份全过，三次运行各 16 份。听着漂亮，可同一批实验里忠实度从 2/16 变成 3/48。prompt 里明明加了只能用调研里出现过的数字，该编还是编。他的原话是，只改了一行，修好了我们衡量的那个问题，没解决 agent 瞎编的问题。

取舍他讲得很干脆，优先保召回率。一次误报的成本是你花一两分钟看一份其实没问题的报告，漏掉一个的成本是一份错的报告送到客户手里。

改进顺序他也排了：数据质量优先，数据烂后面怎么调都没用；然后改 prompt；然后换模型，通常更大更贵；温度这类超参数排最后，现在的 Claude 已经根本不让你传。

换模型之后，它学会了永远说持有

升级到 Haiku 5.5，忠实度涨了三倍多，还是很差，agent 照样编。但建议的一致性明显好了，每次结论都一样。他看了眼数字：45 次调用里 41 次建议持有。一致性变好的办法，就是每次都选同一个答案。成本翻了四倍，值不值他说得你自己判断。

这套东西最后落到 CI 里，才不会被下一次改动推翻。他们的 npm test 里放两个门槛，股票代码写对是底线，错了不许发；可操作性是目标，三次运行平均分要到 0.8。有一次构建失败，就是 Rivian 那份不具备可操作性，平均 0.75。

他还区分了两种评估。能力评估测的是 agent 现在还做不到的事，是一座要爬的山；等某项每次都能稳定通过，别把测试删掉，把它变成回归评估钉在 CI 里。看稳不稳得看 pass^k 而不是 pass@k。编程助手第二次才写对可以接受，金融分析师每五次错一次，那问题就大了。

他反复绕回一句朴素的话：没写清楚什么叫能用，你就不能说你的 agent 不能用。价值在那个循环里，不在某一次的分数上。

更多硬核播客内容：Podwise