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 量小靠人快速建立什么是好的直觉。给后面的自动化评估打标准答案标注金标准数据集。建议固定一批典型 case30~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这几篇配合评估一起用效果更好。