Agent 已经无处不在：银行、工程、医疗……哪儿都有。但评测 Agent 可靠性和性能的方法，却几乎还停留在"聊天机器人 + RAG"的时代没怎么动过。
本文作者 Ben Hylak（Raindrop 创始人）合作对象包括 Framer、Clay、Vercel、GC.AI 等世界一流的 AI 公司。他想说的是：评测 Agent 这件事其实没那么复杂，但大多数团队用错了框架。
先搞清楚：你要的是冲榜，还是筑底？
在想评测方案之前，必须先想清楚一个问题：你到底在追求哪种进步？
对大多数产品来说，这就是两条路的选择：冲榜，或者筑底。大多数团队从来不明确做这个选择，他们借来实验室的评测语言，照着 benchmark 的形状依葫芦画瓢，最后追着一个根本不是为他们设计的目标跑。
举个例子：一个理财 Agent，能交叉对比所有账户、预测消费、自动取消订阅，当然很好。但如果它连"我卡里现在有多少钱"这个基础问题都偶尔答不对，用户就会彻底失去信任。
所以大多数产品团队应该以筑底为思路：在真正重要的地方做到可靠——用户实际在跑的流程里、出错代价高昂的时刻里、那些让你根本不敢上线的极端情况里。
筑底本质上是错误分析
筑底看起来不像是设计 benchmark，更像是在做错误分析。你不是从一套抽象的测试用例出发，而是在做侦探工作——找到系统会弯折的地方，给它们分类，决定哪些值得花工程资源去搞定。
流程很简单，但不轻松：翻看用户消息、Agent 回复，以及 Agent 走到那个答案经历的完整轨迹。尽量多用 AI 来扩大能看的 trace 数量：过滤、聚类、汇总。要问的问题始终一致：
- 最后一个成功的步骤在哪里？
- 第一个真正的失败点在哪里？
- 是检索出了问题？
- Agent 忽略了上下文？
- 工具调用出错了？
- 最终答案夸大了系统实际知道的东西？
然后修复这个模式，而不只是修这一个事故。有时候需要更好的检索，有时候需要约束 Agent 的行为，有时候是改一个工具、加一个护栏，或者教系统在不确定时说"我不知道"。
做完这些，再加评测用例。而且加的时候是有针对性的——不是在测试想象中的覆盖面，而是在把从真实失败中学到的教训锁住。一套筑底的评测集，本质上是一份你拒绝重蹈覆辙的 bug 记录。
这也是为什么海量评测集往往是干扰项。真正伤害你的，通常不是某个 prompt 的第一千个合成变体，而是退款政策的幻觉、无限循环、三次工具调用之后悄悄丢失的上下文。筑底，就是找到这些失败，理解它们，让下一版 Agent 更难被打脸。
一个判断标准：如果可以选择 90% 通过率或 99% 通过率上线，你会怎么选？如果本能反应是"99% 当然"，你还在用冲榜的思维。如果第一个问题是"哪 1% 在失败？"，你才是在筑底。
关于"不知道"的勇气
筑底里最容易做但用户最容易不爽的一个技巧，就是教 Agent 拒绝回答。置信度低于阈值时说"我不知道"，查询超出能力范围时说"我不知道"，检索到的上下文不够用时说"我不知道"。
冲榜派痛恨这个，它会拉低通过率。但筑底派清楚：一个自信的错误答案，比一个诚实的"我不知道"危害大得多。对于要替代人类的产品来说，信任比能力展示重要得多。
上线前先摸清楚自己的 Agent
在把 Agent 放到生产环境之前，得先和它混熟：它能干净处理什么，在哪里容易懵，哪些失败真的会出大事。
黄金用例
挑 5 到 10 个代表核心路径的用例，写下来，放在某个地方。不需要什么文件格式，也不需要什么测试框架。从最简单的版本开始：一个用户最常问、Agent 应该始终能正确处理的普通问题。先跑一遍。后续可以越做越复杂，但从这里起步。如果 Agent 开始在黄金用例上翻车，就不要上线。
在本地摸透你的 Agent
对于黄金用例，不要只看最终输出，要看完整轨迹：用户消息、工具调用、检索到的上下文、推理链。路径和答案同样重要。可以在本地捕捉真实的 Agent trace，检查每一个工具调用，在进生产之前重放场景。
一个冷门技巧：直接问你的 Agent
深度检查 Agent 最好的办法之一，是直接向它提问。这个方法很少有人提到。
这里说的不是让"某个" Agent 去分析 trace 然后猜原因，而是跟你自己的 Agent 对话。把当时传给 Agent 的完整运行上下文，连同最新的响应，原样重构出来，然后直接问它发生了什么。
这很重要，因为推理 trace 往往是加密的，无法直接读懂思维链。把 trace 传回同一个模型，是最接近"询问 Agent 到底发生了什么"的方式，因为它可以用现有的 trace、上下文和历史消息作为证据来回答。
这个方法经常能帮助发现 Agent 在哪里误解了、或者过度执行了提示词的某个部分。可以问类似这样的问题："你答错了，正确答案是 X。我需要改什么你才能答对？"当然，Agent 的回答不一定是真相，把它当线索用就好。
离线评测
必须用代码感知型评测。 单独测提示词没有意义，一旦 Agent 和代码、工具、检索、权限、产品状态纠缠在一起，单测提示词就失去了意义。行为存在于整个系统里，不在某一个提示词字符串里。
所以离线评测看起来不像是给提示词打分，更像是普通的软件测试——想想 Vitest、pytest 或 jest。一个好的离线评测，接受一个输入，跑真实的 Agent 路径，然后断言结果：输出、工具调用、文件变更、结构化数据或最终状态。
Sentry 把这叫做"基于测试框架的评测"，他们的 vitest-evals 示例用的是 describeEval(...)，一个应用本地的 harness，显式的 run(...)，普通的 expect(...) 断言，加上工具调用检查。
OpenAI 在他们的 agentic systems cookbook 里把同样的思路叫"macro evals"：用代表性输入驱动真实的 Agent 循环，对完整轨迹打分，包括工具调用、中间状态和最终答案。
叫什么不重要，重要的是在评测 Agent，而不是在评测某个 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'])
})
})
强烈不建议用托管的评测仪表盘来跑 Agent 评测。报告 UI 是最容易做的部分，同时也是应该和产品最紧密耦合的部分。建议先在本地搭一个简单的 HTML 查看器来看评测结果就够了。
从生产环境里学
Agent 一旦进入真实世界，工作就变了。上线前，你是在猜它可能在哪里出问题。上线后，用户会直接告诉你产品在哪里令人困惑、脆弱或定义不清。
从原始日志开始
先把原始交互读一遍：用户消息、Agent 响应、工具调用，以及那些用户期待一件事但 Agent 做了另一件事的时刻。一直读到饱和——直到同样的模式反复出现。
"错误分析是 AI 开发中最有价值的单项活动，也是持续 ROI 最高的活动。"
这是枯燥的工作，但也是建立对系统真实认知的唯一途径。跳过这一步，后面自动化的指标就会跑偏。
用多少手段，取决于量级
这套流程应该随着流量扩展。每天 10 次 Agent 运行，可以看所有的。每天一万次，就需要系统来告诉你哪些值得关注。错误在于：还没搞清楚在找什么，就急着上大规模的工具链。
- 1–100 次/天 → 寻找"磕绊"：把原始日志当作信息流，找困惑、挫败、差点出错、反复提问、"你用错了"的时刻。这个阶段的目标是建立直觉和分类体系。
- 100–1000 次/天 → 整理成问题（Issue）：当同一个磕绊反复出现，把它变成一个 Issue：团队可以讨论、复现、决定是否修复的具体问题。
- 1000+ 次/天 → 跟踪信号（Signal）：用 Signal 来监控那些需要长期观察的行为：审美投诉、拒绝质量、被忽略的工具错误、上下文丢失、用户挫败感。
- 5000+ 次/天 → 跑实验（Experiment）：一旦理解了问题，把修复放到 feature flag 后面上线，对比相关 Issue 和 Signal 的变化。生产环境会告诉你改动有没有帮上忙。
让 Agent 自我诊断
Raindrop 支持让 Agent 主动上报自身问题。底层实现是在 Agent 运行中注入一个隐藏工具。当 Agent 认为自己缺少上下文、遇到能力盲区、碰到工具失效或者根本无法完成任务时，可以调用这个工具，上报记录为同一事件的一个信号。
这个隐藏工具在概念上大概长这样：
__raindrop_report({
category: 'missing_context',
summary: 'I could not find the refund policy for enterprise plans.',
severity: 'medium',
})
实际用下来，这个功能没有最初看起来那么神。把自我诊断当作磕绊信息流来对待就好——大量杂乱的随机信息里，偶尔能挑出点有意思的东西。要让它成为真正有用的通用信号，需要大量调校。
发现问题，然后修它
找到问题了。接下来怎么修，取决于是什么类型的问题。
有些问题，直接改就好
有些修复是显而易见的：工具调用坏了、系统提示词里少了一条指令、检索查询返回了过期数据。改掉，上线，继续往前。
关键是要判断：这次修复是真的解决了问题，还是只是打了个补丁？治标不治本的快速修复，以后只会冒出更奇怪的 bug。如果发现自己在给特定的用户措辞添加特殊处理逻辑，那多半是在治症状。
先复现，再修
对于不那么简单的问题，第一步永远是复现。能让这个失败再次发生吗？如果不能，说明还没真正理解它。回去看 trace，再读一遍，再找一个例子。
一旦能复现，在修复之前先把它加到黄金用例里。这样能保证不会倒退。流程是：在生产里发现 → 在本地复现 → 加入评测 → 修复 → 验证评测通过 → 上线。
加评测用例这件事，边际收益递减很快
这里有个陷阱：每次发现 bug，都把它加进评测集。六个月后，500 个用例，其中 400 个是生产里几乎不会出现的奇葩边缘情况。CI 跑 20 分钟。团队开始忽略评测失败，因为"总是这些破事"。
不是每个 bug 都值得一个评测用例。问问自己：这是核心路径吗？它会倒退吗？它代表的是一类失败，还是真正的孤立事件？要狠心修剪评测集。20 个高价值用例，胜过 200 个低价值的。
一个实用经验：如果一个评测用例三个月都没有失败过，要么它测的东西不重要，要么 Agent 已经真的改善了。不管哪种情况，都值得重新审视它是否还有必要存在。
很多时候：在生产里做实验
很多改动，唯一能知道它有没有用的方式，就是用真实用户来测试。对比模型，对比提示词，对比工具配置。在真实流量上跑 A/B 测试，衡量真实结果。
A/B 测试：GPT-5.3 vs Claude 4.5 Sonnet
实验组：任务完成率 88%（提升 12%）
对照组：任务完成率 76%
统计显著性：p<0.001
将实验组推广至全部流量
这时候，生产监控就变得不可或缺。需要知道：新模型减少幻觉了吗？新提示词提升用户满意度了吗？这些问题离线回答不了。评测集能告诉你没有破坏黄金用例，生产环境才能告诉你是否真的有帮助。
循环往复
这就是完整的闭环：上线，观察发生了什么，理解失败，修复重要的问题，把有价值的教训保留为回归测试。
每一轮迭代，都应该让 Agent 少一点让人尴尬的地方，让评测集多一点植根于现实的东西。不是要在一开始就把所有可能的测试用例全部预设好，而是建立一个能从生产经验中持续学习、同时不忘过去教训的系统。
评测是持续进行的工作，不是一次性能打勾的事项。如果这个循环停了，测试集就会过期，信心就会变成表演。
一个承诺：计划把 10% 到 20% 的 Agent 开发时间花在评测和监控上。不只是写评测用例，还包括读 trace、调信号、调查问题。这是构建可靠 AI 系统的必要成本。想跳过这步的团队，最终会在生产事故里付出代价。
往后看：Harness 的消亡
"调用模型的 Agent SDK"这套当前模型，裂缝已经开始出现。随着模型能力越来越强、越来越 Agentic，"模型"和"Agent"之间的界限正在模糊。Claude Code、Cursor CLI、以及正在出现的 Cursor Agent SDK，都是佐证。
当 Agent 只是一个提示词加一个模型，评测该怎么做？当没有框架代码可以插桩、没有显式工具循环可以追踪，那包裹在 Agent 外面的 harness 和脚手架，就会塌缩进模型本身。
这会改变监控的方式。现在我们追踪工具调用，是因为必须这么做。未来，也许只需要记录输入/输出对，然后让模型解释它做了什么。中间步骤会变得不透明，就像问一个人他在想什么——你能得到一个答案，但验证会变得更难。
这意味着：端到端评测会变得更加重要。如果无法检查内部状态，就只能信任（并验证）输出。黄金用例和生产监控，本来就是最核心的建议，到那时会成为唯一的选择。
不会变的那些东西
不管外部环境怎么变，有些事情始终成立：
- 必须接触真实用户行为。合成评测会偏离现实。
- 轨迹很重要。不管是显式的（工具调用）还是隐式的（推理过程），Agent 怎么走到那里，本身就是诊断信息。
- 黄金用例有效。少而精的高价值测试，胜过多而杂的低价值测试。
- 生产监控不可或缺。无法提前预判所有失败模式。
- 评测是持续性工作，不是一次性配置。
工具会变，框架会变，模型会变。核心挑战——验证一个自主系统是否在做你想要它做的事——不会变。
一句话版本
- 选对框架：冲榜适合辅助专家，筑底适合替代人类。
- 筑底就是错误分析：读真实交互，找真正重要的模式，修系统背后的根因。
- 用代码感知型离线评测：测运行中的真实 Agent 路径——工具、状态、文件、结构化输出和副作用。
- 按量级扩展生产审查：从磕绊开始，让反复出现的问题变成 Issue，长期跟踪 Signal，用实验验证修复效果。
- 保持循环紧凑：真实失败变成有针对性的回归测试，而不是一个越堆越大的推测性评测集。