现在大家应该已经很熟悉 Agent 了，Codex、WorkBuddy 等这种现象级的产品，很多人应该都体验过了。现在开发一个 Agent 好像变得一点都不难了，尤其再有了 AI 辅助编程，我们甚至可以让 Codex 帮忙开发一个类似 Codex 出来。
现在比较难的是怎么判断这个 Agent 到底做得好不好，任务是否完成？效果达到预期了吗？模型升级、提示词调整或知识库更新以后，Agent 的表现真的变好了，还是看起来更聪明？
这些问题我们如果只能靠产品经理和测试人员自己想出来的几个案例，最后凭感觉说，看起来可以了，Agent 就很难稳定地用于生产环境。
所以，我们得给 Agent 配一个评测平台。
评测要把感觉还行变成一套可以反复运行、版本对比和发现问题的机制。这样每次优化都能看出有没有进步，上线也就能做到心里有底。
Agent评测是什么？
Agent 评测是用一组具有代表性的任务，在尽可能固定的环境中运行 Agent，并从结果、过程、效率和安全等维度判断它是否达到产品目标。
评测需要判断 Agent 能否稳定、可靠地完成工作。Agent 系统通常包含模型、提示词、上下文、工具、知识库、记忆、Skills、运行环境以及多轮决策逻辑，任何一个环节发生变化，都可能改变最终结果。
一次完整的 Agent 评测需要回答下面这些问题。
- 结果是否正确，事实，结论、格式、交付物是否满足需求
- 过程是否合理，有没有选对工具，工具参数是否正确，是否出现重复调用，空转或者错误后无法修复
- 运行是否可接受，延迟，Token成本，执行是否稳定
- 行为是否安全，有没有越权、泄露敏感信息或执行不该发生的外部动作
简单来说，传统问答主要关心答案对不对，Agent 评测还要关心它怎样把事情办成的。
Agent为什么必须评测
大模型的输出具有概率性，同一个输入多跑几次，可能得到不同的表达，甚至出现不同的结论。
我们手动测试Agent执行一次，二次都成功了，这个只能说明这个Agent做这个事情大概率可以成功，无法说明它可以稳定成功。
Agent 的行为相当依赖环境。网页内容、知识库和接口都可能会发生变化，工具返回的数据还可能缺失。只看最终答案，很难判断问题究竟出在哪里。
升级一次 Agent 往往会改动多个变量，比如更换模型、调整提示词、增删 Skill 或修改工具描述。每一项都可能影响执行效果，修复旧问题时也可能引入新问题。缺少固定的数据集和基线报告，团队很难客观判断一次改动的收益和代价。
Agent 会真实操作业务数据。它会发消息、写文件和修改数据。对于执行类 Agent，操作对象、参数、顺序和权限都必须正确。
Agent 评测应该贯穿需求设计、开发调试、上线验收和持续迭代。
Agent评测和传统软件测试有什么不同
传统软件通常有明确的输入、处理逻辑和预期输出。对于给定输入，程序多次运行应该返回相同结果，测试往往可以用布尔断言直接判定。
Agent 测试要处理更多不确定性。
正确答案可能不唯一，一份报告可以有多种合理结构，一段客服回复也可能有很多种合格表达。如果只做字符串精确匹配，往往会把正确答案误判为错误。
最终答案正确，不代表执行过程正确。Agent 可能碰巧得到正确结果，但中间调用了错误工具、使用了高风险参数，或者进行了十几次无意义重试。这样的系统仍然不适合上线。
评测标准往往是多维的，准确性、完整性、依据充分程度、格式、语气、延迟、成本、安全性之间需要综合权衡，有些维度还需要一票否决。
评测器本身也可能出错，尤其使用 LLM 作为裁判时，评分提示词、模型版本和评分协议都会影响结果，因此评测器也需要版本管理、结构化输出校验和人工校准。
Agent 需要统计意义上的稳定性验证。对于高价值用例，不能只跑一次，而要重复运行，观察平均分、通过率和波动范围。
传统测试在 Agent 评测中仍然必要。工具、权限、接口和脚本可以用确定性方法验证。先保证这些基础能力稳定，上层 Agent 才有稳定运行的条件。
Agent评测应该从什么时候开始
我们可能是最开始做Agent的那一批人，刚开始都是在Agent开发完成后，才开始考虑测试的问题，产品、开发、测试根据Agent的功能，跑一跑自己准备的案例，跑完之后的结论，还可以，感觉差不多，最后直接先上线看看效果！
后面感觉这个太不靠谱，还是要有测试，上线流程这些。
后续我们在PRD的时候，就开始同步定义评测口径，每一个核心功能点都应该写成可以观察，可以执行的验收。
例如，PRD 不能只写 Agent 能根据企业知识回答员工问题。还要明确回答必须引用哪些资料，资料中没有答案时不得编造，P95 响应时间上限是多少，哪些敏感内容不得输出，知识检索失败时应该怎样处理。随后再补充典型用例，写明问题、期望答案和资料来源。
在 PRD 评审阶段，产品、研发和测试可以先完成下面这些工作。
- 定义任务边界，Agent应该做什么，不做什么
- 定义成功的标准，正确性，完整性，格式，过程，延时，成本和安全阈值
- 建立典型的用例，覆盖主流程、边界条件、异常输入和高风险操作
- 约定上线门禁，哪些核心用例必须全部通过，整体通过率和成本上限是多少。
同时需要定义首批测试集，这里不必追求数量多少，但必须具有代表性。产品和业务人员负责提供真实场景，研发补充技术边界与失败路径，测试人员在此基础上持续扩充、去重和维护回归集。线上发现的新问题，也应脱敏后加入到测试集中。
按任务类型划分评测
从 Agent 的主要任务目标来看，常见任务可以粗略分为四类。我们这里的分类依据是 Agent 要交付什么结果。
| 类型 | 典型场景 | 预期交付 |
|---|---|---|
| 查询类 | 查天气、查订单、检索网页、查询业务数据 | 一组来自指定数据源、满足查询条件的最新结果 |
| 知识问答类 | 企业制度问答、产品咨询、客服答疑 | 一份有资料依据、能处理未知问题的回答 |
| 内容生成类 | 调研报告、经营分析、会议纪要、方案生成 | 一份满足内容和格式要求的文档 |
| 执行类 | 发消息、写文件、创建日程、修改业务数据 | 目标系统中一次准确、合规且可确认的状态变化 |
一个 Agent 可以横跨多种类型。比如先查询订单，再生成回复，最后把回复发送给客户，这个任务就包含查询、生成和执行三个阶段。设计用例时应按阶段拆开，同时保留一组端到端用例检查各阶段能否衔接。
无论属于哪一类，测试集都要覆盖正常流程、边界条件和失败场景。知识问答要加入资料缺失、资料冲突和超出知识范围的问题。执行任务则要覆盖参数缺失、权限不足、接口超时、中途报错及失败后的处理。
评测维度
任务类型确定评测对象，评测维度用来描述这个对象做得怎么样。不同类型可以使用同一组维度，只是权重和门禁不同。例如执行类任务更看重工具、权限和最终状态，内容生成类任务更看重事实、结构和完整性。
任务完成度
任务完成度，主要看 Agent 是否真正实现了用户目标，而非仅输出一段看似专业的文本，四类任务的完成标志并不完全相同。
| 类型 | 完成标志 |
|---|---|
| 查询类 | 使用了正确的数据源和查询条件，结果准确、及时且没有遗漏关键数据 |
| 知识问答类 | 回答有指定资料支撑，覆盖问题要点，资料不足时能说明无法回答的部分 |
| 内容生成类 | 成品覆盖要求的内容，事实和论证可靠，结构与格式符合交付要求 |
| 执行类 | 目标系统中的操作对象、参数和最终状态正确，没有产生额外副作用 |
答案质量
检查准确性、相关性、完整性、事实依据、格式规范和表达清晰度。具体指标要跟着任务变化，知识问答需要关注资料忠实度，报告类任务还要检查结构、论证和关键信息是否齐全。
工具调用质量
Agent中的工具调用，是非常重要的一换，毕竟Agent要干活，必然要使用工具，做测评的时候，我们需要做一下检查
- 是否调用正确的工具，是否规避了禁止调用的工具
- 参数传递是否与上下文意图一致
- 对返回结果是否正确解析并用于后续推理
- 调用失败时，是否执行了合理的重试或降级策略。
Skill 使用质量
Skill也一样是Agent执行中非常重要的一换，它把稳定的工作流指令告诉了Agent，希望Agent严格按照指令来完成任务，这里要检查以下内容。
- 场景是否适合，skill的选择是否正确
- 是否遵循 Skill 规定的步骤，有没有跳步或私自简化
- 是否正确调用配置的套脚，并遵守输出约束
执行过程质量
最终答案正确时，过程缺陷仍会带来成本与风险。这里要监控以下内容。
- 是否存在对同一工具的无意义重复调用
- 是否存在无任务推进的空转轮次（如循环推理、无效自我修正）
- 错误发生后是否能有效恢复，是否绕行明显过长的路径。
非功能质量
这一维度主要涉及延迟、Token 消耗、成本、稳定性、安全性及隐私保护。
评分与验证方法
Agent评测，实践中我们通常组合使用下面几种方法。
- 确定性评分 使用精确匹配、包含、正则、JSON Schema 和字段断言。这个靠规则匹配，代码来验证，它的速度快、成本低、结果稳定。
- 轨迹评分 评估Agent执行的路径，检查必需使用或禁止使用的工具是否参与执行、工具参数对不对、是否重复调用、空转、错误恢复和步骤数量，适合工具型与执行型 Agent。
- LLM-as-a-Judge 按照明确的 Rubric 评价准确性、完整性和逻辑等语义维度，适合开放式答案。
- 人工评审 用于高风险样本、主观体验、抽样质检。人工主要负责校准机器评分，无须承担全部回归工作。
- 重复运行与统计评测 让同一用例运行多次，通过计算均值、方差和通过率，识别偶发成功与不稳定行为。
- 对比评测 把新版本与固定基线得分比较，同时哪些用例得分变低或者变高，成本变化和延迟变化。
- 线上评测 对真实请求数据做脱敏抽样，结合用户反馈和安全监控发现问题，再把典型失败加入离线数据集。
如何做评测
下面结合我们当前项目中的评测平台，讲一下这套流程具体怎样落地。
建立数据集
评测从数据集开始。我们按准确性、幻觉、性能和安全等目标管理数据集，同时把数据分成开发集、回归集和保留集。开发集用于日常调试，回归集验证已知问题有没有重新出现，保留集尽量少参与提示词调试，用来检查 Agent 对未见任务的表现。
数据集需要版本管理。修改中的用例可以继续编辑，正式评测使用已经发布的固定版本。这样几周以后重新查看报告时，仍然能确认当时跑的是哪一批用例。
每条用例至少包含问题、上下文、参考答案或期望结果、评分标准、标签和优先级。
复杂任务还可以加入多轮消息、结构化期望输出、断言、评分器绑定。
评分器的设计
用例数据集建立以后，要选择合适的评分器，并把评分器版本、权重和通过条件绑定到用例。能够写成确定性规则的要求优先交给程序判断，开放式内容交给 LLM，争议样本和高风险结果由人工复核。
下面是我们的评分器设计。
当前项目主要使用四类评分器。
- 执行过程评分关注工具选择、执行路径和错误恢复
- 模型评分根据 Rubric 判断最终答案
- 人工审核处理高风险样本和机器评分争议
- 执行过程指标统计重试、空转、错误和工具调用次数
每条用例可以绑定不同的评分器。知识问答可以同时检查引用和内容质量，执行任务则可以组合工具轨迹、最终状态、延迟和成本。评分器也要保留版本，否则更换评分提示词以后，前后两次分数就失去了可比性。
多个评分器可以按权重分配比例来计算总分。安全、权限和关键业务结果可以设置为强制门禁，其中任意一项失败，用例就不能通过。LLM 评分器返回结构化的维度分和理由，总分由服务端重新计算。
规则评分可以直接在用例中配置。
这里的评分类型支持精确匹配、包含、正则、JSON Schema、延迟和成本等确定性判断。这些都是可以通过程序得到确定性的分数，这些规则每一个用例的设置都可能不同，需要把它们放在具体用例里，维护时更容易明白这条用例究竟的要求是什么。
执行环境设计
运行评测时需要记录完整快照，包括数据集版本、Agent 提示词版本、模型与参数、工具、Skills、MCP、知识库配置、评分器版本和评测协议。缺少这些信息，今天与上周的分数变化可能来自某项未记录的配置变化。
执行任务还要控制外部副作用。当前项目提供禁用、Mock、记录、回放和受控执行等工具模式。
每个评测任务还可以限制单用例超时、总 Token、总成本和总运行时间。预算耗尽后及时停止，如果后续发现这些设置限制了运行，也可以修改配置，继续之前未完成的用例继续运行。
执行并记录完整 Run
Agent 平时运行时已经会记录完整过程，评测可以复用同一套 Agent Runtime 和可观察性数据。这样评测得到的工具调用、模型输出、耗时和 Token 消耗，与真实运行采用同一种记录方式。轨迹评分和 LLM 评分也能从 Run 中取得所需证据。
高价值用例可以重复执行多次。报告除了平均分和通过率，还要展示波动情况。新版本测试的时候也可以绑定以前测试的结果，跑完之后根据结果比较可以直接查看哪些用例进步了，哪些用例退化了，以及成本和延迟发生了什么变化。
分析失败
测评未通过的用例会进入问题中心，这些够需要人工来处理，需要结合目标 Agent 的 执行轨迹、评分Agent的执行轨迹、失败类型和评分理由，判断问题出在提示词、模型、知识库、工具、环境还是评分器。
同时可以记录严重程度、负责人和修复版本。修复完成后，可以从原问题发起复测，复测失败后就会重新进入问题中心。
持续回归
数据集不会一次建完。开发中发现的失败、人工评分出现的争议、线上请求暴露出的典型问题，都可以脱敏后加入回归集。新增用例需要去重和评审，评分器也要通过人工样本持续校准。
回归可以按计划定时运行，也可以接入 CI 来执行。
结语
其实我们在搞这个Agent测评平台时候，就是一路踩坑一路填。每做一个功能，都得拿真实例子去跑一跑，等第一批用例真能在平台上跑通了，好家伙，冒出来的小问题比我们想的要多得多。那也没办法，只能一个个看，一个个改，改着改着，整个测评流程就比较清楚了，各种用例怎么写，心里都有谱了。
现在想想，好多东西还真得靠折腾，有空就多捣鼓捣鼓，折腾完了才真能摸着门道。
本文由作者@叶小钗，授权发布于平台，未经许可禁止转载。