Anthropic官方最新发布的一篇【Demystifying evals for AI agents】，系统阐述了如何给当下的AI智能体做评估
这套评估体系是其内部经验，在多种智能体架构和真实用例中验证过
评估是对AI系统的测试，给AI一个输入，然后用评分逻辑衡量其输出是否达标，该体系主打一个无需真实用户在开发阶段运行的自动化评估
单轮评估简单直接，一个提示、一个响应、一个评分逻辑，早期LLM主要使用这种非智能体评估
智能体评估更复杂，AI智能体越来越像个‘人’，会自己翻工具、改状态、多轮思考，那么传统‘一问一答’的打分方式就不太够用了，得重新设计一套多轮、自动化、可量化的评估体系，否则团队永远只能在出事后打补丁
如果不评估，只在生产环境中发现问题匆忙修复的，结果往往是按下葫芦起了瓢
好比你手里没有考勤表，只能等客户投诉才知道谁今天没来上班
Claude Code最初只靠内外部反馈快速迭代，后来逐步加入评估，先测简洁性、文件编辑，再测复杂行为如过度工程，评估可以帮助定位问题、指导改进，成为产品与研究团队间最高带宽的沟通通道
具体解法一句话总结，把“用户体验”拆成几百个可自动判卷的“多轮小考”，提前跑、随时跑、每次commit都跑，让问题在真用户碰到之前就变成可追踪的数字
把AI智能体难以量化的黑箱问题变成可自动化、可回归、可对比的单元测试问题
首先构建结构化的评估框架
1、标准化术语，把“任务”、“试运行”、“评分器”、“评估框架”等核心概念定义明确，让团队沟通和实践统一语言
任务，具有明确输入和成功标准的单个测试
试运行，对同一任务的一次尝试，因模型输出有随机性，通常运行多次以获得稳定结果
评分器，对智能体某个性能表现评分的逻辑，一个任务可有多个评分器
运行记录，完整试验记录，包括输出、工具调用、推理、中间结果等
结果，试运行结束时环境的最终状态，比如说订票智能体说“已订完”只是 transcript，真正的outcome是SQL数据库里是否存在对应预订
评估框架，端到端运行评估的基础设施，负责提供指令与工具、并发执行任务、记录步骤、评分并汇总结果
智能体框架，让模型成为智能体的系统，处理输入、编排工具调用并返回结果，在评估“智能体”时，其实是在评估框架与模型的协同
评估套件，围绕同一目标设计的任务集合，比如客服套件可测试退款、取消、升级等场景
2、评分器类型分类
常见智能体类型有编程的、研究的、计算机使用的、对话的，评估技巧可互相借鉴
代码型评分器：用于客观、确定性任务
模型型评分器：利用LLM评估开放式、主观性输出
人工评分器：作为黄金标准，根据任务特性进行组合使用
3、区分了评估类型，能力评估用于探索代理极限和新能力，回归评估用于确保产品稳定性，防止新改动引入问题
4、引入非确定性指标，提出了pass@k（看能力，多次尝试中至少一次成功），pass^k（看可靠性，每次尝试都成功）来应对AI智能体的非确定性行为
从0到1的评估路线图
1、尽早开始，20–50个真实失败案例就足够起步，小样本也能在早期检测到明显效应
2、从手动测试里找任务，把发布前手动验证的点、用户工单、Bug报告转成测试用例，确保紧贴实际
3、任务无歧义且带参考解，两位专家应能独立得出相同判分，0%pass@100常是任务或评分器坏了，提供参考解可验证任务可解且评分器配置正确
4、正负样本平衡，只测“该搜索”会养出搜索狂魔，也要测“不该搜索”的情况，避免类别失衡
5、隔离稳定环境，每次trial用干净容器，禁共享状态，防止“看git历史作弊”或资源耗尽导致相关失败
6、精心设计评分器
优先用确定型，必要时用LLM，少量人工校准
评结果而非路径，允许多部分得分
LLM评委加“未知”逃生通道，按维度独立打分，减少幻觉
防绕过，任务与评分器应让“真解题”才能过，而非钻空子
7、人工看transcript，失败必须“看着公平”，transcript能揭示是智能体错还是评分器错，是调优的关键素材
8、警惕评估饱和，通过率100%只防回归，不再提供进步信号，应及时升级题目或加入更难任务，避免“高分低能”假象
9、设专门eval团队管基础设施，业务专家负责写任务并运行，把写eval当作写单元测试一样常规。推行“eval-driven development”，先写考卷再写功能，新模型一到就跑，快速验证哪些bets兑现
自动化eval只是其中一块，还需与其他方法协同形成全景视图
生产监控，看真实分布，补eval盲区，但比较被动
A/B测试，用真实流量验证业务指标，就是慢
用户反馈，稀缺、偏负面，可以发现未知问题
人工审transcript，质高但慢，可用于校准
系统人工研究，贵，可做黄金标准
多层方法叠加，漏网问题可以被下一层捕获
博客：http://t.cn/AXbEQstf
#AIagent评估##AI应用评估#
