核心思想
评估 AI 智能体没那么复杂：先想清楚你要的是”刷榜”（增强专家）还是”抬高下限”（取代人类）。对多数产品而言答案是后者——而抬高下限的本质就是错误分析：读真实轨迹、找出会要命的失败模式、修掉背后的系统问题，再用代码感知的离线评估锁住教训、用生产监控验证修复。一小撮高信号的黄金用例，胜过一大套空想的评估集。
前言
一年前，智能体还几乎不存在。如今它们无处不在：银行、工程、医疗，处处都有它们的身影。
有那么一阵子，我特别讨厌「智能体（agent）」这个词。不就是一次 LLM 调用吗？干嘛非要造个新词？但很快，我和所有人都意识到：这个新词确实有它存在的必要。
智能体是一种实体，几乎带着某种自我意识，在它所处的环境中穿行。它调用手头的各种工具，为创造者们做梦也想不到的问题找出富有创意的解法。
有时候，这些创意般的解法帮了大忙；有时候，它们造成了实打实的伤害。但有一点是确定的：我们已经远远走出了「预测下一个 token」的时代。
有意思的是，评估智能体可靠性与性能的方法，自上一个「聊天机器人」和 RAG 时代以来，基本上没怎么变过。
那些靠「评估智能体（也就是做 evals）」吃饭的公司，常常端出越来越荒诞、越来越过度复杂的方案。他们兜售的工具，与真正在优秀公司里行之有效的做法之间的鸿沟，从未如此之大。
我写这篇文章就是想说一句：评估这件事，其实没那么复杂。我之所以有底气，是因为我就在一家做智能体的公司工作。而我们，又服务于全世界最顶尖的一批 AI 公司：Framer、Clay、Vercel、GC.AI 等等。
这份指南力求中立。当然，我会聊到我创办的那家评估公司 Raindrop，因为我认为它是本文所述实践理念最好的具象化。即便它现在还不是，我们也会朝这个方向把它做成。我还会提到 Raindrop Workshop——一个免费、完全开源的本地测试工具。
读者请注意：这份指南讲的是智能体。评估分类器（classifier）、RAG 流水线以及许多其他 AI 系统的方式是不一样的——比如在那些场景下，采样多个结果、再用 Opus 来评判，往往要有用得多。但这些不是本文要讨论的内容。
你是「刷榜派」还是「抬高下限派」？
在动手做评估之前，你得先想清楚：你想取得的，究竟是哪一种进步？
对大多数产品来说，这归结为两个选择：你可以去刷榜（benchmark maxx），也可以去抬高下限。大多数团队从来没有明确地做过这个选择。他们照搬实验室那套评估话术，复制各种榜单的形态，最后追着一个根本不是为他们而设的目标跑。
来做个小测验吧。
第 1 题 / 共 7 题
你的智能体犯下的最严重错误，有没有可能上新闻？
想象一个理财智能体。如果它能交叉核对你所有的账户、预测你的开销、自动取消订阅，那当然很棒。但要是它有时连「我银行账户里还有多少钱？」这种最基础的问题都答不上来，你就会不再信任它了。
正因如此，大多数产品团队都应该从抬高下限的角度去思考：让智能体在「可靠性真正重要」的地方变得可靠——在用户真实会跑的工作流里，在错误代价高昂的关键时刻，在那些会让你「不敢上线」的场景里。
抬高下限，本质就是错误分析
这就是为什么抬高下限看起来不太像设计榜单，反倒更像错误分析（error analysis）——套用 Hamel Husain 的说法。你不是从一套抽象的测试集开始的，你做的是侦探工作：找出系统会「弯折」的那些地方，给它们分门别类，再判断哪些值得投入工程精力去修。
这个流程很简单，但并不轻松。逐一审查用户消息、智能体回复，以及它得出答案所走过的整条轨迹（trajectory）。尽可能用 AI 来放大你能查看的轨迹数量：过滤、聚类、归纳。但要问的问题始终如一：最后一步成功的操作是什么？第一处真正的失败又出现在哪里？检索是不是漏了？智能体是不是忽略了上下文？某次工具调用（tool call）是不是出了岔子？最终答案是不是夸大了系统其实掌握的信息？
然后，你要修的是这一类模式，而不仅仅是这一次个案。有时这意味着改进检索；有时意味着给智能体加上约束；有时意味着换掉某个工具、加一道护栏，或者教会系统在适当时候停下来，说一句「我不知道」。
到了这一步，你才开始添加评估。而且一旦动手，它们都是有的放矢的。你不是在测试想象出来的覆盖率，你是在把从真实失败里学到的教训固化下来。一套「抬高下限」式的评估集，本质上是一份「拒绝重蹈覆辙的 Bug 记忆库」。
这也是为什么动辄海量的评估集往往只是一种干扰。真正能伤到你的，通常不是某条提示词的第一千个合成变体，而是退款政策上的幻觉（hallucination）、那个停不下来的死循环、三次工具调用之后那段不易察觉的上下文丢失。抬高下限，就是你发现这些失败、理解它们，并让下一版智能体更难出丑的途径。
把这些产品放到「刷榜 ↔ 抬高下限」这条轴上
自动补全（Autocomplete） · Cursor · Claude Code · 客服聊天机器人（Support chatbot） · 银行智能体（Banking agent） · Devin · AI 医生（AI Doctor）
← 刷榜（Benchmark maxx） 抬高下限（Floor raise）→
如果上线时你可以选 90% 的通过率，也可以选 99% 的通过率，你会选哪个？如果你的本能反应是「那还用问，99% 啊」，那你还在用刷榜者的思路想问题。如果你脱口而出的第一个问题是「失败的那 1% 是哪些情况？」，那你才是在用抬高下限的思路在思考。
抬高下限里最唾手可得的技巧之一，恰恰也是最让用户抓狂的一招：教你的智能体学会拒答。置信度低于阈值，就说「我不知道」；问题超出你的领域范围，就说「我不知道」；检索到的上下文不足以支撑回答，就说「我不知道」。
刷榜派痛恨这一招，因为它会拉低通过率。但抬高下限派明白：一个自信满满的错误答案，比一句诚实的「我不知道」更糟糕。对于那些要去取代人类的产品而言，信任比「秀肌肉」式的能力展示重要得多。
上线之前，先摸透你的智能体
在你放心地把一个智能体推上生产环境之前，你得先跟它「混熟」：搞清楚它能干净利落地搞定什么、在哪里会犯迷糊，以及哪些失败是真正要命的。
黄金用例
挑出 5 到 10 个能代表你关键路径的用例，把它们记在某个地方。它们不需要什么文件格式，也不需要 harness。从最简单的版本开始：一个常见的、你的智能体理应永远答对的用户问题。试一下。日后你可以把它逐步做得更复杂，但起步就从这里开始。一旦你的智能体开始在黄金用例上翻车，那就别上线。
在本地摸透你的智能体
对于你的黄金用例，别只盯着最终输出看。要把整条轨迹都检视一遍：用户消息、工具调用、检索到的上下文、推理链条。路径和答案同样重要。Raindrop Workshop 在这里很有用：它能让你在本地捕获真实的智能体轨迹、检视每一次工具调用，并在这些场景冲进生产环境之前先回放（replay）一遍。
专业提示：直接问你的智能体
深入剖析智能体的最佳方式之一，就是直接向它提问。奇怪的是，我还没听过有谁谈起这一点。
把话说清楚：我说的不是让随便一个智能体去看那些轨迹、然后猜测原因。我说的是去跟你自己的那个智能体对话。把那一次运行原样复现出来——就像当初传给智能体的那样——连同它最近给出的回复一起喂回去，然后直接问它到底发生了什么。
这一点之所以重要，是因为推理轨迹往往是加密的，你未必能自己读懂那段思维链。把轨迹原样回传给同一个模型，是你能做到的、最接近「直接问智能体究竟发生了什么」的办法——因为它可以把手头可用的轨迹、上下文和先前的消息当作证据来支撑它的回答。
这往往能帮你发现：你的智能体究竟在哪里误读了、或者过度执着于你提示词里的某个特定部分。可以这样问它：「你答错了。正确答案是 X。我当初需要改动什么，你才能答对这道题？」当然，智能体给你的回答未必就是真相，把它当成一条线索来用就好。
离线评估
你需要的是「代码感知（code-aware）」的评估。一旦智能体与代码、工具、检索、权限、产品状态纠缠在一起，单独去测提示词就毫无意义了。行为是活在整个系统里的，而不是活在那串提示词字符串里。
正因如此，离线评估（offline evals）看起来不太像「给提示词打分」，反倒更像普通的软件测试。想想 Vitest、pytest 或者 jest。一个好的离线评估，是接收一个输入、跑通真实的智能体路径，然后对结果做断言：输出、工具调用、被改动的文件、结构化数据，或是最终状态。
Sentry 把这种做法称为「harness 支撑式（harness-backed）」，他们的 vitest-evals 示例用到了 describeEval(...)、一个应用本地（app-local）的 harness、一个显式的 run(...)、常规的 expect(...) 断言，以及对工具调用的检查。
OpenAI 在他们的智能体系统手册（agentic systems cookbook）里把同一个理念叫作「宏观评估（macro evals）」：在有代表性的输入上驱动真实的智能体循环，并对整条轨迹打分——包括工具调用、中间状态和最终答案。
叫它什么我都不在乎。重要的是：你评估的是智能体，而不是一次 LLM 调用。
// evals/refund_agent.eval.ts
import { expect } from 'vitest'
import { describeEval, toolCalls } from 'vitest-evals'
import { refundAgentHarness } from '../harness'
describeEval('refund agent', { harness: refundAgentHarness() }, (it) => {
it('approves refundable invoice', async ({ run }) => {
const result = await run('Refund invoice inv_123')
expect(result.output.status).toBe('approved')
expect(toolCalls(result.session).map((c) => c.name)).toEqual(['lookupInvoice', 'createRefund'])
})
})Raindrop Workshop 让创建代码感知评估变得非常简单：你可以保存轨迹，Codex / Claude 还能给运行结果做批注，告诉你它们是通过还是失败（并附上更具体的点评）。
你完全可以把评估直接存在一个 Markdown 文件里，然后让 Codex 跑一遍就行。
我真心不建议你去用某个托管的评估仪表盘来跑智能体评估。Raindrop 之所以不提供这种东西是有原因的，而且原因绝不是「它很难做」（其实做起来非常简单）。
原因在于：报告 UI 恰恰是最容易做的那部分，同时也是本应与你的产品耦合得最紧密的那部分。要是我来做，我会先快速起一个本地的 HTML 查看器来看评估的通过 / 失败状态。
从生产环境中学习
智能体一旦走向真实世界，工作的性质就变了。上线之前，你是在猜它可能会在哪里出问题；上线之后，是用户在向你展示：产品究竟在哪里让人困惑、哪里脆弱、哪里语焉不详。
从原始日志开始
先去读那些原始的交互记录：用户消息、智能体回复、工具调用，以及那些「用户期待的是一回事、智能体却做了另一回事」的瞬间。一直读，读到饱和为止——读到同样的模式开始一遍又一遍地反复出现。
Quote
「错误分析是 AI 开发中唯一最有价值的活动，而且始终是投资回报率（ROI）最高的活动。」
这是一项枯燥乏味的工作，但它也是你为系统建立起真实心智模型的唯一途径。跳过它，你最终就会去自动化一堆错误的指标。
你需要什么，取决于你的体量
工作流应当随着你的流量一起扩展。每天 10 次智能体运行时，你能把每一条都读完；到了每天一万次，你就需要系统主动告诉你哪些值得关注了。常见的错误是：在你还没积累足够多的原始素材、还没搞清楚自己到底要找什么之前，就急着去上那套高流量的机器。
每天 1–100 次运行 — 磕绊（Stumbles）
把原始日志当作「消防水龙带」一样的信息洪流。从中寻找困惑、挫败、险些出错（near-miss）、反复发出的提示，以及那些「是你拿反了（you’re holding it wrong）」式的时刻。在这个阶段，目标是培养品味（taste）和建立分类法（taxonomy）。
每天 100–1,000 次运行 — 问题（Issues）
当同一个磕绊反复出现时，把它升格为一个 Issue：一个正在浮现的问题，团队可以围绕它讨论、复现，并决定要不要修。
每天 1,000+ 次运行 — 信号（Signals）
用 Signals 来追踪那些你想在长周期内持续监控的行为：审美方面的抱怨、拒答质量、被忽略的工具报错、上下文丢失、用户挫败感。
每天 5,000+ 次运行 — 实验（Experiments）
当你彻底搞懂某个 Issue 之后，把修复方案藏在功能开关（feature flag）后面发布出去，再对比相关的 Issues 和 Signals。该不该上这个改动，应该由生产环境来告诉你。
自我诊断
Raindrop 还能让智能体上报它自己的问题。其底层原理，是往智能体的运行过程里注入一个隐藏工具。当智能体觉得自己缺少上下文、撞上了某项能力的天花板、正在跟一个坏掉的工具较劲，或者干脆把任务彻底搞砸了的时候，它就可以调用这个工具，而 Raindrop 会把这份报告作为一条信号记录在同一个事件上。在 AI SDK 的集成里，这基本上就是包装器上的一行代码：
const { generateText } = raindrop.wrap(ai, { selfDiagnostics: { enabled: true } })从概念上讲，那个隐藏工具大致长这样：
__raindrop_report({
category: 'missing_context',
summary: 'I could not find the refund policy for enterprise plans.',
severity: 'medium',
})但在实践中，我们发现它远没有表面上看起来那么有用。把自我诊断当成「磕绊」来对待就好：它是一股充满随机内容的信息洪流，你或许能从里头挑出一两件有意思的东西。要把它的灵敏度调校到位、让它成为一个真正通用且有用的信号，是需要下一番真功夫的。措辞上的细微差别，就足以左右智能体到底要不要上报。说到底，这是一个二分类（binary-classification）问题。
做修复、做改动
你发现了一个问题，现在得去修它。具体怎么修，取决于它是哪一类问题。
有时候，直接修就行
有些修复显而易见、立等可取：一次坏掉的工具调用、系统提示词里漏掉的一条指令、一个返回了陈旧数据的检索查询。修掉、上线、翻篇。
关键在于分清：这个修复到底是「真·直接修复」，还是只是糊在更深层问题上的一块创可贴。一个只治标、不治本的快速修复，日后只会冒出一个更诡异的 Bug。如果你发现自己开始针对特定的用户措辞去加各种特例处理，那你多半是在治标不治本。
先复现，再修复
对于那些没那么简单的问题，第一步永远是复现。你能不能让这次失败再次发生？如果不能，那说明你还没真正搞懂它。回到那条轨迹，再读一遍，再找一个例子。
一旦能稳定复现，就先把它添加为一个黄金用例，然后再动手修。这能保证你不会发生回归（regression）。这个套路是：在生产环境中发现 → 在本地复现 → 添加到评估里 → 修复 → 验证评估通过 → 上线。
「把每个 Bug 都加成评估用例」往往边际收益递减
这里有个陷阱：每发现一个 Bug，你就把它加进评估集。半年之后，你攒下了 500 个用例，其中 400 个都是生产环境里压根不会出现的诡异边缘情况。你的 CI 要跑 20 分钟。你的团队开始对评估失败视而不见，因为「反正它总归会挂个什么」。
不是每个 Bug 都配拥有一个评估用例。要问自己：这是不是关键路径？它会不会回归？它究竟是某一类失败的代表，还是真的只是个一次性的孤例？对你的评估集要狠下心来剪枝。20 个高信号用例，胜过 200 个低信号用例。
一条好用的经验法则：如果一个评估用例 3 个月都没失败过，那它要么根本没在测什么重要的东西，要么就是你的智能体确实进步了。无论是哪种，都该掂量掂量它还有没有留在那儿的必要。
更多时候：在生产环境里做实验
对于很多改动来说，唯一能确认它们是否有效的办法，就是拿真实用户来测。对比模型、对比提示词、对比工具配置。在真实流量上跑 A/B 测试，度量真实的结果。
这正是生产环境监控（production monitoring）变得不可或缺的地方。你需要知道：新模型有没有减少幻觉？新提示词有没有提升用户满意度？这些问题你在离线状态下是答不出来的。评估集只会告诉你「黄金用例没被搞坏」，而生产环境才会告诉你「它到底有没有真的带来帮助」。
// A/B 测试：GPT-5.3 vs Claude 4.5 Sonnet
实验组（Treatment）：88% 任务完成率（提升 12%）
对照组（Control）： 76% 任务完成率
统计显著性：p < 0.001
将实验组提升至 100% 流量周而复始，循环往复
这就是整个循环：上线、观察发生了什么、理解那些失败、修掉重要的那些，再把有用的教训作为回归测试（regression test）保留下来。
每一轮迭代，都应该让智能体出丑的概率小一点点，也让评估集更贴近现实一分。你的目标，不是把所有可能的测试用例一股脑全在前期堆出来，而是去构建一个能从生产环境中学习、同时又不会忘掉所学的系统。
评估工作是持续进行的，不是打个勾就完事的一锤子买卖。一旦这个循环停转，评估集就会过期失效，所谓的「信心」也会沦为一场表演。
请打算把智能体开发时间的 10% 到 20% 投入到评估和监控上。这不仅仅是写评估用例，还包括读轨迹、调信号、查问题。这就是构建可靠 AI 系统所要付出的成本。那些想跳过这一步的团队，最终都会在生产事故里加倍偿还。
展望未来
评估的格局正在飞速变化。以下是我们正在密切关注的几件事。
harness 的坍缩
当下「由智能体 SDK 去调用模型」这套模式，已经开始显露裂痕。随着模型变得愈发强大、愈发具备智能体特质，「模型」与「智能体」之间的界限正在变得模糊。我们已经在 Claude Code、Cursor CLI，以及正在崛起的 Cursor Agent SDK 身上看到了这种趋势。
当智能体仅仅就是「一段提示词加一个模型」时，评估会变成什么样？当根本没有框架代码可供插桩（instrument）、没有显式的工具循环可供追踪时，又会怎样？那个环绕在智能体周围的 harness、那套脚手架，会坍缩、融进模型本身。
这会改变监控的方式。今天我们追踪工具调用，是因为不得不这么做；而到了明天，我们或许只需记录「输入 / 输出」对，然后请模型自己解释它都干了些什么。中间步骤会变得不透明——就像去问一个人「你当时在想什么」一样。你能得到一个答案，但验证会变得更难。
由此推导出的结论是：端到端（end-to-end）评估会变得愈发重要。如果你无法检视内部，你就只能去信任（并验证）输出。黄金用例和生产环境监控——这两样本就是我们的建议——会成为唯一可玩的牌局。
从「应用」到「MCP」
敬请期待。
哪些东西始终不变
历经所有这些变化，有几件事依然成立：
- 你需要与真实的用户行为保持接触。合成评估（synthetic evals）终会与现实渐行渐远。
- 轨迹很重要。无论它是显式的（工具调用）还是隐式的（推理），智能体「如何走到那一步」，本身就极具诊断价值。
- 黄金用例确实管用。一小撮高信号的测试，胜过一大堆低信号的测试。
- 生产环境监控不可或缺。你不可能预先料到所有的失败模式。
- 评估是一项持续进行的工作，而不是一次性搭好就完事的设置。
工具会变，框架会变，模型也会变。但那个最根本的挑战——验证一个自主系统确实在做你想让它做的事——始终如一。
浓缩版
如果别的你都记不住，那就记住这些：
- 选对框架。 刷榜，是为了增强专家的能力；抬高下限，是为了那些取代人类、被放到一线去用的智能体。
- 抬高下限的本质就是错误分析。 去读真实的交互记录，找出那些真正重要的模式，再去修掉它们背后的系统问题。
- 使用代码感知的离线评估。 测试正在运行的智能体路径：工具、状态、文件、结构化输出，以及各种副作用。
- 让生产环境的审查随体量一起扩展。 从「磕绊」起步，让反复出现的模式升格为「问题」，长期追踪「信号」，再用「实验」去验证你的修复。
- 把循环保持得紧凑。 让真实的失败变成有的放矢的回归测试，而不是一套庞大而空想的评估集。
准备好认真评估你的智能体了吗？
Raindrop Workshop 为你提供本地轨迹捕获、轨迹检视和回放，专为智能体评估而生。从这里起步。等你准备好上生产环境监控时，Raindrop 会陪你一起扩展、一同成长。
相关笔记
- 生产环境中的 AI 智能体监控 —— 与离线评估互补：智能体上线后如何持续监控
- 解剖智能体Harness —— 呼应本文”harness 坍缩”一节：harness 究竟由哪些组件构成
- Claude 提示工程最佳实践 —— 评估往往与提示词迭代相互印证