现在做一个 Agent 有多容易？
Claude Code、Codex、WorkBuddy 这些产品，很多人要么用过，要么天天在用。加上 AI 辅助编程，我们甚至可以让 Codex 帮忙做出一个类似 Codex 的东西。开发门槛降得飞快，一个能跑的 Agent，很快就能拼出来。
但开发不难了，难的是另一个问题，怎么判断这个 Agent 到底做得好不好。
任务真的完成了吗？模型升级、提示词调整、知识库更新之后，它是真的变好了，还是只是看起来更聪明了？
这些问题，只靠产品和测试自己想几个案例跑一跑，凭感觉说一句「看起来可以了」，Agent 是很难稳定用在生产环境的。
所以想要系统地学会判断 Agent，得给它配一套完整的评测体系。这套体系长什么样，我直接把目录贴出来，一共 14 篇，前面讲方法，评测维度、测评集建设、评分器、工具链怎么选，中间是工具实操，Promptfoo、DeepEval、Langfuse 逐个上手，最后落到 RAG 和 Agent 两个综合实战项目。
详细的AI 大模型测评体系教程，已经发布到 AI 进化社了，想系统学的可以联系我。
今天这篇，先聊一聊 Agent 评测的维度、打分方法和落地流程。（本文为精简版）
Agent 评测，到底测的是什么
先说定义。Agent 评测，是用一组有代表性的任务，在尽量固定的环境里运行 Agent，从结果、过程、效率和安全这些角度，判断它有没有达到产品目标。
定义里藏着三个关键词。
有代表性的任务，选的必须是能代表 Agent 真实用法的任务，主流程和容易出事的边界都得盖住，随手想几个凑数是不行的。
尽量固定的环境，每次评测的环境要尽量一样，不然这次跑得好、下次跑得差，你分不清是 Agent 的问题还是环境的问题。
多维度判断，不止看结果对不对，还要看过程、效率和风险。
整个事情像考驾照。考场是固定的，科目是规定好的，考官不光看你最后有没有停进车位，还看你转向灯打没打、方向是怎么打的，危险动作直接挂科。
还有一点容易被忽略。一套 Agent 系统里，模型只是发动机，外面还包着一整辆车，提示词、上下文、工具、知识库、运行环境，加上多轮决策逻辑，合起来才是被测对象。你测的从来不是模型一个人，是模型加上这整套系统。
落到实操上，一次完整的 Agent 评测，至少要回答四个问题。
- 结果对不对。 让 Agent 出一份经营周报，交上来的数字准不准、结构合不合要求，这是最基本的一层
- 过程合不合理。 查一个订单状态，明明有现成的查询接口，它绕去爬网页，结果碰巧是对的，过程已经出问题了
- 代价能不能接受。 一个很简单的任务跑了十几分钟、烧了几块钱，结果全对也很难放进生产环境
- 行为安不安全。 客服 Agent 为了回答问题，把 A 用户的订单信息发给了 B 用户，这就是安全事故
传统问答评测主要关心答案对不对，Agent 评测还要关心它是怎么把事情办成的。
传统测试那套照搬过来，会卡在五件事上
很多测试同学的第一反应是，不都是测试吗，写用例、跑用例、做断言，把传统那一套搬过来就行。
能搬的部分确实不少，但有五件事，传统方法处理不了。
传统软件有明确的输入、处理逻辑和预期输出，给定一个输入，跑多少次结果都一样，所以能用布尔断言直接判，对得上就过，对不上就挂，非黑即白。到了 Agent 这边，这套逻辑失灵了。
正确答案可能不唯一。
「已为您办理退货」和「退款申请已提交，预计一到三天到账」，说的都是同一件事，都算对。只做字符串精确匹配，会把这些正确答案误判成错误，断言从「必须一模一样」变成了「怎样才算对」，判定逻辑整套都要换。
结果正确，不代表过程正确。
Agent 可能碰巧得到正确结果，但中间调错了工具、用了高风险参数，或者做了十几次无意义重试。查个账户余额，它绕路调了转账接口又自己撤销，最后报出来的数字是对的，可这样的过程放进生产环境就是隐患。
评判标准往往是多维的。
准确性、完整性、格式、延迟、成本、安全性，这些维度要综合权衡，有的还要一票否决。一份周报内容全对、格式漂亮，但把别的用户的订单号写了进去，其它方面分数再高，这条用例也不能过。
打分的评委自己也会错。
给 Agent 答案打分的，很多时候是另一个大模型，也就是 LLM-as-a-Judge。评委自己也是概率性的，评分提示词换个措辞、评委模型换个版本，分数就可能漂移。所以评测器自己也需要版本管理和人工校准，不能默认评委说的就是对的。
结果带随机性。
同一个用例跑两次，一次过一次挂，在 Agent 身上很正常。单次结果说明不了问题，高价值用例得重复运行，看平均分、通过率和波动范围，拿一条分布说话。
补一句，传统测试并没有作废。工具、权限、接口和脚本，这些依然可以用确定性方法验证，该写自动化写自动化，该做断言做断言。地基用老办法，楼层用新办法，两套东西叠着用，谁也替代不了谁。
多跑几次，为什么还不够
看到这你可能会想，那手动多跑几次，总能看出来吧。
也不行。除了上面说的随机性，还有几个常见坑在等着。
行为依赖环境。
网页内容、知识库和接口都可能变化，工具返回的数据还可能缺失。上周还好好的 Agent，这周突然挂了，排查半天发现是目标网页改了版，这种事在 Agent 身上是家常便饭。只看最终答案，你分不清是 Agent 本身退化了，还是环境变了。
一次升级会同时改动多个变量。
换模型、调提示词、增删工具，往往一起来。改完随手跑一下，感觉变好了，可这是换模型的功劳，还是提示词调对了？说不清。要回答这个问题，需要一套固定的数据集和一份基线报告，基线就是上一版在这批用例上的成绩单。缺了这两样，团队对每次升级的判断，只能停在感觉层面。
Agent 会真实地动你的业务数据。
发消息、写文件、改数据库，发出去的消息收不回来，写错的脏数据要人工一条条清。执行类 Agent 的操作对象、参数、顺序错一个，就可能造成真实损失。这种风险靠上线之后用户帮你发现，代价就太大了，必须在上线前拦住。
Agent 评测这件事，不该只出现在上线前，它应该贯穿需求设计、开发调试、上线验收和持续迭代，每个阶段都有各自要回答的问题。
评测要从写 PRD 的时候就开始
那从哪个阶段切入最合适？答案有点反直觉，评测要从 PRD 阶段就开始，和需求定义同步进行，别等 Agent 开发完了再补。
这个答案是踩坑踩出来的。我早先做 Agent，就是等开发完了才开始考虑测试，产品、开发、测试各自跑跑自己准备的案例，结论是「还可以，感觉差不多」，直接上线。上线之后问题一个接一个，才发现这套流程一样都不能省。
后来换了做法，写 PRD 的时候就同步定义评测口径，把每一个核心功能点，写成可以观察、可以验收的检查项。
区别看个例子就明白。PRD 里写「Agent 能根据企业知识回答员工问题」，这句话是没法验收的，要把它拆成这样的检查项。
- 回答必须引用哪些资料，来源要标清楚
- 资料里没有答案时，不得编造，要明确告知不知道
- P95 响应时间不超过多少秒
- 哪些敏感内容不得输出
- 知识检索失败时，应该怎么应对
拆完之后，「回答得好不好」从一句主观评价，变成一组可以逐条打勾的检查项。再配一批典型用例，写明问题、期望答案和资料来源，首批测试集就有了。数量不用追求多，几十条有代表性的，比上千条凑数的管用。
顺手把上线门禁也定了，比如核心用例必须 100% 通过、整体通过率不低于 90%，才允许发版。到这里，评测的地基就打好了。
动手之前，先分清任务类型
用例怎么设计？第一步先想清楚，你要测的 Agent 属于哪一类任务，分类依据是它要交付什么。
| 类型 | 典型场景 | 合格标准 |
|---|---|---|
| 查询类 | 查天气、查订单、检索业务数据 | 数据准、新、全 |
| 知识问答类 | 企业制度问答、客服答疑 | 有资料依据，答不上来能明说 |
| 内容生成类 | 调研报告、会议纪要、写代码 | 一份内容和格式都达标的成品 |
| 执行类 | 发消息、写文件、改业务数据 | 目标系统里一次准确、合规的真实改动 |
先问一个高频问题，编程属于哪类？按交付物算，编程归内容生成类。
Claude Code、Codex 这类编程 Agent，最终交出来的是一份代码，本质上和交一份报告一样。只不过代码的验收方式特殊一点，编译要能过，测试要能跑通，反而是四类里最好验的，能用确定性评分的就用确定性评分。
但编程 Agent 干活的过程里要改文件、跑命令、提交代码，这些动作又是执行类的活，它是个典型的跨界选手。一个 Agent 横跨多种类型很常见，先查询订单，再生成回复，最后发送给客户，一个任务就包含查询、生成、执行三个阶段。设计用例时按阶段拆开，各测各的，同时保留一组端到端用例，检查各阶段能不能衔接上。
还有一条底线，无论哪类任务，测试集都要覆盖正常流程、边界条件和失败场景。知识问答要加入资料缺失、超出知识范围的问题，执行任务要覆盖参数缺失、权限不足、接口超时。只测正常流程的测试集，跑起来一片绿，上了线照样翻车。
从哪些维度看它做得好不好
任务类型定了用例的骨架，评测维度描述这个 Agent 做得怎么样。这套维度一共六个，可以分成三组来看。
看结果的，有两个。
任务完成度排在第一位，事情没办成，回复写得再专业也是零分。查订单的漏了关键数据、写报告的缺了核心内容、执行任务的产生额外副作用，都算没完成。
答案质量看准确性、完整性、事实依据和表达。知识问答要特别盯资料忠实度，看回答里有没有夹带资料之外的私货；报告类任务还要检查结构和关键信息齐不齐。
看过程的，有三个。
工具调用质量，工具选没选对、参数和上下文意图对不对、失败后有没有合理重试或降级。用户问的是 A 订单，它别去查 B 订单；客服 Agent 只被允许查订单，就不能碰退款接口。
Skill 使用质量，Skill 把一套稳定流程固化成指令交给 Agent，就看它有没有严格照着办，场景选没选对，有没有跳步或私自简化。
执行过程质量，盯的是无意义重复调用、空转轮次、错误后能不能恢复、有没有绕远路。这些缺陷不影响这次结果对不对，但决定它长期跑起来稳不稳。
看代价的，有一个。
非功能质量，延迟、Token 成本、稳定性、安全隐私。单条任务的 Token 钱看着不多，全量回归跑几百条，账单就来了。安全这条在很多场景里是一票否决，它不影响「对不对」，但直接决定这个 Agent 能不能放进生产环境长期跑。
分数从哪来
维度回答「看什么」，方法回答「怎么打分」。打分的手段有四种。
- 确定性评分，精确匹配、正则、JSON Schema、字段断言，由代码执行，快、便宜、结果稳定
- 轨迹评分，评估执行路径，必需用的工具有没有用、参数对不对、有没有重复调用和空转，适合工具型和执行型 Agent
- LLM-as-a-Judge，让另一个大模型按明确的评分细则，判准确性、完整性这类语义维度，适合开放式答案，坑是评委自己也会漂移
- 人工评审，负责高风险样本、主观体验和抽样质检，人主要负责校准机器评分，不用承担全部回归
优先级很明确，能写成规则的优先交给代码，规则写不了的交给 LLM，争议样本和高风险结果留给人工。
跑的方式也有三种。重复运行做统计，同一用例跑多次，看均值、通过率和波动；对比评测，新版本和固定基线比，看哪些用例变好了、哪些退化了，成本和延迟变了多少；线上评测，对真实请求做脱敏抽样，结合用户反馈发现问题，再把典型失败加回离线数据集。
一套完整流程，六个环节
最后把方法组织成能跑起来的流程，六个环节一个扣一个。
建数据集。
用例按准确性、幻觉、性能、安全这些目标分类，分成三个子集。开发集是平时刷题的本子，随便折腾；回归集是错题本，专门验证修过的问题有没有复发；保留集留一小批 Agent 没见过的任务，防止你照着旧题反复调优，把它调成「只会做这几道题」。数据集要做版本管理，正式评测只认已发布的固定版本，几周后回看报告，还能确认当时跑的是哪批用例。
配评分器。
每条用例绑定打分方式，规则、模型、人工按前面说的优先级组合。有两个设计要点。一票否决要独立于权重，安全、权限和关键业务结果设成强制门禁，任意一项失败，这条用例就不能通过；评分器自己也要版本管理，换了评分提示词，前后两次分数就失去可比性了。
设执行环境。
两件事。记录完整快照，数据集版本、提示词版本、模型参数、工具和评分器版本，缺了这些，今天和上周的分数差五个点，你可能永远查不出是哪项配置悄悄变了。控制外部副作用，评测不能每轮都真发消息真写库，工具可以禁用、Mock、记录回放或者受控执行。再给每个任务设预算上限，单用例超时、总 Token、总成本，预算耗尽及时停，别让一条失控的用例烧掉整轮评测。
执行并记录。
评测直接复用 Agent 运行时的可观测性数据，工具调用、模型输出、耗时和 Token 消耗，和真实运行是同一套记录，轨迹评分要的证据就从这里取。高价值用例重复跑多次，报告除了平均分和通过率，还要展示波动情况。
分析失败。
没过的用例进问题中心，由人来处理。手里要有四样东西，目标 Agent 的执行轨迹、评分 Agent 的轨迹、失败类型、评分理由，然后按六个怀疑对象排查，问题出在提示词、模型、知识库、工具、环境，还是评分器自己。注意最后一个，有些「失败」其实是评分器误判，别急着改 Agent。
持续回归。
开发中发现的失败、人工评审的争议、线上暴露的典型问题，脱敏之后都加进回归集，评分器拿人工样本持续校准。回归可以定时跑，也可以接进 CI，每次变更自动触发。
写在最后
方法讲完了，说句实在话。
评测这件事，光看懂方法论远远不够，经验是在一次次跑用例、看失败、调评分器的过程里攒出来的。第一批用例真正跑通的时候，冒出来的小问题多半比预想的多，前期只能一个个看、一个个改，改着改着，整个流程就顺了，用例怎么写，心里也都有谱了。
所以别等完全想清楚再动手。按这篇的框架先搭一个最小的评测集，哪怕只有十几条用例，跑起来、失败几个，你对 Agent 评测的理解，就会超过大部分只看教程不动手的人。
更细的实操，数据集怎么建、评分器怎么配、评测平台怎么搭，AI进化社 有完整的零基础保姆级实操教程，跟着做，多动手，一个月就能掌握。
我是狂师，公众号长期分享 AI 提效实战与测试开发技术干货。
最近，我创建了一个「AI测开进化圈」知识星球，聚焦 AI 测试方向，年订阅，交付的是能直接用的AI提效工具包、AI 面试刷题、路线带学和全年答疑，目标是让你把手里的活干快。
想踏实学 AI 测试、不靠东拼西凑浪费时间的话，相信我，直接冲。