AI Agent 评估：怎么判断你的智能体到底好不好用？
很多人做 Agent，流程是这样的：写 prompt → 接工具 → 跑通一个 demo → 上线。然后呢？然后就开始凭感觉了。今天觉得"好像挺聪明"，明天遇到一个奇怪的 case 又觉得"怎么这么蠢"。改了一版 prompt，到底是变好了还是变坏了？说不清楚。
这就是缺了**评估（Evaluation）**这一环。这篇文章聊聊：为什么 Agent 评估这么难，到底该评估什么，以及怎么搭一套最小可用的评估流程。
一、最容易被跳过、却最致命的一环
传统软件你写完一个函数，会写单元测试：输入 2，断言输出 4。确定性的，对就是对，错就是错。
Agent 不一样。同样一个问题问两次，措辞可能完全不同；同样一段代码，它可能用三种思路解决。你没法简单地assert output == expected。
于是很多团队干脆不评估了，全靠人肉体验。结果就是：
- 改了 prompt 不知道是不是真的更好，只能反复"我觉得"。
- 换了模型/换了工具，不知道有没有引入退化（regression）。
- 线上出问题了，复现不了、定位不到、也没法验证修复有没有效。
没有评估的 Agent，迭代就是开盲盒。评估不是上线后才考虑的事，它应该和写 prompt 同步进行。
二、为什么 Agent 评估比传统软件测试难
| 难点 | 说明 |
|---|---|
| 输出不确定 | 同样输入，多次运行结果不同，没有唯一正确答案 |
| 多步骤、长链路 | Agent 要规划、调工具、反思、重试，错误会在中间某一步发生 |
| 过程比结果重要 | 答案对了但中间瞎调了 10 次工具，这其实是个坏 case |
| 评判标准主观 | "回答得好不好"很多时候没有客观标尺 |
| 成本高 | 跑一遍要烧 token、调真实 API，没法像单测那样秒级跑几千遍 |
所以 Agent 评估不是"对/错"的二元判断，而是一套多维度、带容忍度的度量体系。
三、到底要评估什么：四个维度
不要只盯着"答案对不对"。一个真正可用的 Agent，至少要从四个维度看：
1. 任务完成度（Task Completion）
最核心的指标：它到底有没有把用户要的事办成？
- 端到端成功率：100 个任务，完整做对了几个。
- 部分完成度：复杂任务可以拆成子目标，看完成了几个子目标。
2. 过程质量（Trajectory Quality）
看它"怎么做到的"，而不只是"做没做到"：
- 工具调用是否合理（该调的调了，不该调的别瞎调）。
- 有没有无意义的循环、反复重试。
- 步数/耗时/token 消耗是否在合理范围。
3. 输出质量（Output Quality）
- 准确性：有没有事实错误、有没有幻觉。
- 相关性：答到点子上没有，还是答非所问。
- 完整性 & 格式：该给的信息给全没有，格式符不符合要求。
4. 安全与稳健（Safety & Robustness）
- 面对模糊/恶意输入会不会失控。
- 会不会执行危险操作（删库、乱发请求）。
- 出错时能不能优雅降级，而不是直接崩。
四、怎么评估：三种主流方法
方法一：人工评估（Human Eval）
最准，但最贵、最慢。适合：
- 项目早期，case 量小，靠人快速建立"什么是好"的直觉。
- 给后面的自动化评估打"标准答案"（标注金标准数据集）。
建议：固定一批典型 case（30~50 个就够起步），每次迭代都让同一批人按同一套标准打分，保证可比性。
方法二：LLM-as-a-Judge（用模型当裁判）
让一个能力强的模型来给 Agent 的输出打分。这是目前性价比最高的方案。
关键点：
- 给裁判明确的评分标准（rubric），别只说"打个分"，要说"从准确性/相关性/完整性三方面，各 1-5 分"。
- 让它先说理由再给分，理由能帮你发现裁判本身的偏差。
- 警惕偏见：LLM 裁判会偏好更长的回答、偏好自己风格的输出。必要时做位置随机化、对比评估。
- 用人工标注的小集合校准裁判，确认它的打分和人类判断一致，再放心用它批量跑。
方法三：自动化指标（Programmatic Checks）
能用代码判断的，就别用模型：
- 结果里必须包含某个关键字段 → 字符串/正则匹配。
- 返回的是合法 JSON → schema 校验。
- 调用了正确的工具、参数对不对 → 直接断言工具调用日志。
- 数值类答案 → 直接比对。
优先级建议：能用自动化指标就用它（快、便宜、稳定），需要主观判断的交给 LLM-as-a-Judge，最关键的少量 case 留给人工兜底。
五、搭一套最小可用的评估流程（6 步）
不用一上来就上复杂平台，从这个最小闭环开始：
- 攒数据集：收集 30~50 个真实/典型任务，覆盖常见场景 + 已知的坑。每个 case 记清楚输入和"期望达成的目标"。
- 定指标：从上面四个维度里挑 2~3 个当前最关心的，定义清楚怎么算分。
- 写裁判：能自动判的写断言，要主观判的写好 rubric 交给 LLM-as-a-Judge。
- 跑基线：先把当前版本完整跑一遍，记录分数。这就是你的 baseline。
- 改一版、跑一遍、对比：每次只改一个变量（prompt / 模型 / 工具），重新跑同一个集合，看分数是涨是跌。
- 盯回归：把跑挂过的 case 沉淀成固定回归集，每次迭代都跑，防止"修好一个、弄坏三个"。
跑顺了之后，再考虑接入 LangSmith、Langfuse、Promptfoo 这类工具做可视化和自动化，但核心方法论就是上面这套。
六、6 个常见的坑
| 坑 | 后果 | 怎么避 |
|---|---|---|
| 只看最终答案，不看过程 | 答案蒙对了，过程一塌糊涂还以为没问题 | 一定要评 trajectory |
| 评估集太小/不真实 | 分数好看，线上翻车 | 用真实数据，持续扩充 |
| 每次改一堆东西再评估 | 分数变了不知道是谁的功劳 | 一次只改一个变量 |
| 无脑信任 LLM 裁判 | 裁判自己有偏见，分数失真 | 用人工标注校准裁判 |
| 没有回归集 | 反复修反复坏 | 失败 case 沉淀成固定回归集 |
| 评估和开发脱节 | 上线后才发现没法衡量好坏 | 写 prompt 时就同步建评估 |
七、总结
一句话：评估决定了你的 Agent 能不能持续变好。
- Agent 评估难在输出不确定、过程比结果重要、标准主观。
- 至少从任务完成度、过程质量、输出质量、安全稳健四个维度看。
- 方法上：能自动化就自动化，主观判断交给 LLM-as-a-Judge，关键 case 人工兜底。
- 落地从最小闭环开始：攒数据集 → 定指标 → 写裁判 → 跑基线 → 改一版对比 → 盯回归。
别再凭感觉迭代 Agent 了。建一套评估，哪怕只有 30 个 case，你对它的认知都会清晰一个量级。
相关阅读：如果你在搭 Agent，可以一起看看 Agent 学习路线、大模型幻觉问题、以及上下文工程（Context Engineering）这几篇，配合评估一起用效果更好。
