一个 Agent 给出了完整答案，接口也没有报错，能算“做得好”吗？
还不够。它可能用了过期资料，查错了日期，也可能只是说“已完成”，实际没有更新任何记录。换个问法、再跑一次，结果还可能变。
这些问题属于 Agent 测评的范围。对产品经理和项目负责人来说，理解它，才能把“感觉还不错”变成有依据的质量判断。
本文参考美团技术团队《Agent 评测漫谈》，结合相关公开资料，重新梳理测评对象、指标、数据和方法。文中的小例子用于解释概念，不代表实际项目结果。
01｜Agent 测评，究竟在测什么
先说 Agent。这里把它理解为：围绕一个目标，能够调用工具、读取中间结果，再决定下一步的 AI 系统。比如查资料后写报告，查询订单后处理售后，修改代码后运行测试。
模型负责理解和生成，工具帮助它获取信息、执行动作，外层程序负责权限、状态和流程。因此，测一个 Agent，通常是在测这些部分一起工作时的表现。
测评就是给它安排一组任务，提前说清什么算成功，再检查执行情况：事情有没有做成，交付物是否可用，过程是否合理，消耗与风险能否接受。
一场测评至少有五样东西：
- 任务：让它做什么，以及有哪些限制。
- 标准：成功、失败和部分完成怎样区分。
- 运行记录：这次用了什么信息，调用了什么工具。
- 实际结果：交付物或业务系统最终变成了什么样。
- 判断依据：为什么通过，为什么没有通过。
“回复”和“实际结果”尤其容易混淆。Agent 说“预约成功”，是一次回复；预约系统中存在正确的预约记录，才是需要核验的结果。Anthropic 的评测文章也专门区分了这两件事。[1]
如果任务本身就是写摘要，摘要当然是交付物；如果任务要求执行操作，便不能只检查文字。成功标准要跟着任务走。
再区分两个词：观测和测评。观测是把发生的事情记录下来，测评是拿记录与标准比较，判断好不好。没有记录，出了问题很难定位；有了记录，也不会自动得到正确判断。
02｜它和传统测试有什么区别
这里需要分开说：传统软件测试，以及传统模型评测。
软件测试检查程序是否符合要求，例如金额算得对不对，权限控制是否生效，服务能否承受高并发。模型评测更关注模型自身的能力，例如识别、回答、推理或代码生成。
Agent 测评把视野扩展到整个任务系统：模型能力够用，工具接错了，任务照样失败；接口都正常，Agent 调用了错误参数，结果也会出错。
这不是说软件测试只看结果。它同样检查复杂流程、性能与安全，也可以使用统计方法。Agent 测评的特殊性，主要来自以下几件事。
第一，同样的任务，执行表现可能变化。同一个问题跑两次，可能选择不同工具、生成不同内容。一次通过可以说明它有机会做对，却不足以说明它能稳定做对。
第二，正确答案和正确路径可能不止一条。写一份市场分析，章节顺序可以不同；完成一次查询，也可能有多种合理方法。逐字匹配答案、逐步匹配操作，容易把有效方案误判为失败。
第三，中间动作会改变后面的条件。查到什么资料、写入了什么文件、保留了什么上下文，都会影响下一步。一个小错误可能沿着多步执行继续传播。
第四，失败不一定发生在模型里。资料过期、接口超时、权限不足、测试环境不完整，都可能造成任务失败。只看最后一句回复，无法分清这些原因。
所以，Agent 仍然需要接口测试、单元测试和性能测试；同时还要回答一个更完整的问题：在约定条件下，它能否可靠完成用户任务？
03｜六个方向，看懂主要指标
指标不用一次铺满。先知道每类指标回答什么，再挑与产品风险相关的部分。下面六个方向是一种整理方式，不是统一的行业清单。
任务完成：事情做成了吗
常见指标是任务完成率：达到成功标准的运行次数，占有效测评运行次数的比例。哪些运行计入分母，要提前约定；无法判断的运行单独统计，并报告其占全部运行的比例。
分母必须说明白：只测简单任务，还是包含异常任务？允许重试几次？人工接手后算不算成功？这些条件不同，两个“90%”就不能直接比较。
也要区分完整交付和部分完成。报告写完但无法打开，不能算可用交付；正确完成一半，也不应在问题分析中被当成“什么都没做”。可以保留阶段结果，但别用部分得分替代完整任务通过。
结果质量：做成之后，能用吗
这里关注事实、完整性、相关性和可用性。数字是否准确，引用是否支持结论，内容有没有回应用户需求，文件格式是否符合约定。
“内容有用”太宽泛。可以拆成：是否覆盖指定问题，关键结论是否有证据，是否说明资料限制。标准越具体，评判越容易对齐。
查资料类任务，还可以分别检查“需要的资料有没有找到”和“最终回答有没有正确使用资料”。两者失败时，需要修的位置不同。
执行过程：做法是否合理
关注工具选择、参数、步骤关系、异常处理，以及是否无意义重复。工具返回成功，只能说明调用在某个层面成功，不代表查的是正确对象。
例如用户要求本月数据，Agent 传入了上月日期。接口没有报错，调用仍然不符合任务要求。
过程评价应检查必要条件和禁止动作，而不是要求每次走同一条路。不同路径只要满足目标、约束和预算，就可能都合理。
稳定性：同类任务，能持续做对吗
挑出关键任务重复运行，观察通过比例和失败模式。有时每次都在同一步失败，有时同一版本表现忽好忽坏，处理方法并不一样。
还要分清“多试几次，总有一次成功”和“每次都成功”。假设单次成功概率是 75%，且每次概率相同、相互独立，那么三次至少成功一次的概率约为 98%，三次全部成功则约为 42%。[1]
前一种更像寻找一个可用候选，后一种更接近用户对可靠服务的期待。现实任务未必符合独立假设，这组数字只是帮助理解，不能拿来预测项目表现。
效率成本：完成这件事，花了多少
可以看总耗时、工具调用次数、重试次数、模型费用，以及人工处理时间。实时问答与后台报告，时间要求显然不同。
模型用量常用 Token 计量，可以粗略理解为模型处理文字等内容的计费单位，并不等于字数。费用核算要使用适用的用量与价格；平台推算值也要与实际账单区分。[2]
成本最好连着成功结果看。例如同一批运行的总费用，除以成功完成的次数，可以得到这批测评中平均每个成功任务的费用。范围内的失败与重试应计入，也要说明是否包括工具费和人工成本。
看耗时也别只看平均数。多数任务很快、少数任务特别慢，平均值可能掩盖用户的等待体验。可以同时看最慢的那一部分任务。
安全边界：有没有做不该做的事
关注越权访问、错误修改、敏感信息泄露，以及该确认时是否取得确认。低频不代表低风险，偶发误操作也可能造成较大损失。
关键禁止动作应单独判断。不能因为表达、效率都很高，就把越权操作平均成一个“总体不错”的分数。对越权率等比例，还要说明分母是运行次数、操作次数，还是包含权限边界的测试次数。
这些指标帮助解释系统表现，业务价值仍需另外验证：是否减少了人工时间，返工有没有增加，用户是否愿意继续使用。离线得分上涨，不能直接证明业务收益上涨。
04｜要算这些指标，得先有什么信息
指标是汇总后的判断，字段是每次运行留下的一项项信息，评分规则则说明怎样从信息得出判断。
比如任务完成率是指标，预约编号与最终状态是信息，“系统中存在符合要求的有效预约”是规则。把三者混在一起，就容易出现一堆分数，却没有核验依据。
信息可以分为六组。下面用中文列用途，各平台字段名可能不同。
第一组：任务要求
记录原始输入、任务类型、成功条件和限制。需要哪些内容，允许操作什么，时间与成本预算是多少，都属于这里。
用户没有指定保存位置，却在测评时因位置不同判失败，是标准本身出了问题。被检查的关键要求，应当提前对 Agent 可见。
第二组：初始条件
记录必要的历史对话、输入资料及版本、可用工具、权限范围，还有相关业务对象的初始状态。
同样一句“继续处理”，在不同历史对话下含义不同。只留下最后一句输入，可能根本无法判断当时该做什么。
第三组：被测版本
记录模型、提示要求、工具配置和应用程序的版本。提示要求，就是告诉模型怎样工作的指令；不必为了理解它再记一串英文。
某个可复用操作指南被修改，也要能追溯到版本。否则换了模型又换了规则，分数提高了，却无法知道哪项变化起作用。
第四组：执行步骤
记录各步的输入、输出、工具名称、调用参数、返回结果、错误信息和发生时间。
还要有能把信息串起来的编号：属于哪个任务、哪次尝试、哪个步骤，前后是什么关系。否则并发运行时，几次尝试的日志可能混在一起。
这类关联后的执行记录，常被称为 Trace。记住“能还原这次执行的记录”即可。它能显示可见动作和数据，不等于模型完整的内部思考。
第五组：资源消耗
记录开始与结束时间、各步耗时、用量、费用、重试，以及人工是否介入。多步骤并行时，各步耗时相加不一定等于用户等待的总时长。
如果模型接口没有返回完整用量，就要说明统计缺口。不能把“没有采到”当成“没有消耗”。
第六组：真实结果与评判
记录交付物、业务系统最终状态，以及每项检查的结论、理由、证据和评分标准版本。人工判断还应知道由谁评判；AI 判断要能追溯所用模型与规则。
证据不足时，保留“无法判断”。这和任务失败不是一回事。把无法判断的样本排除时，应同时报告它们占多少；直接删除，会让整体表现看起来过于乐观。
这些信息不必全靠手工填表。重要的是能找到、能关联，并且知道哪里缺失。
05｜信息从哪里来
可以把信息获取分成四条路径：运行程序记录事实，业务系统核对结果，人工或AI提供判断，真实用户补充体验。
运行程序与接口，提供执行记录。 开发者在关键位置增加记录功能，也就是埋点；或接入现成的采集工具。SDK 可以理解为接入工具包，帮助采集调用、耗时、输入输出等信息。
例如 Langfuse 可以组织关联的执行记录，OpenTelemetry 则提供通用的采集与关联方式。接入范围不同，自动采到的信息也不同；业务含义、权限和成功标准，通常还需要应用补充。[3][4]
产品负责人可以直接问开发同事：一次任务能否串起所有关键步骤？工具参数和错误是否保留？有没有办法比较修改前后？这些问题比“平台能不能画流程图”更接近测评需要。
业务系统和交付物，提供实际结果。 查询订单、审批、预约等记录，或检查生成文件能否打开、内容是否符合要求。这些证据能核对“声称完成”和“实际完成”。
对于需要一段时间才生效的操作，要约定何时核验。刚提交就查询不到，不一定意味着失败；无限等待同样没有意义。等待期限和超时处理都应事先说明。
人工与AI评委，提供质量判断。 对一份报告是否有用、解释是否充分这类问题，需要评价标准和业务判断。AI 可以辅助批量检查，但要给它任务要求、相关证据和明确规则，而非只给最终回复。[5]
运行平台能展示完整记录，不代表某个自动评委默认拿得到所有步骤。要核对它实际收到什么，必要时补上上下文，否则评价可能建立在缺失信息上。
用户反馈，提供真实使用线索。 点赞、投诉、重新提问、人工接手，都能帮助发现问题。没有投诉不等于没有失败：用户可能放弃了，也可能自己补救了。
发现异常反馈后，要关联对应运行，再还原原因。不能把“用户没满意”直接翻译成“模型能力差”。
任务越长，越要保留关键状态变化，例如文件版本、已完成动作、上下文保留或压缩情况、中断与恢复位置。记录不等于一定能重放；重放还需要相应资料、权限和可恢复的环境。
采集也不是越多越好。保留判断所需信息即可，敏感内容应脱敏或受控保存，避免为了测评把凭证和无关隐私复制进日志。
06｜怎样让测评结果可信
数据齐了，还需要组织好测评方法。可以按下面这条路径起步。
先把“好”写成可以检查的要求
“回答准确、专业、有帮助”很难执行。可以改成：“关键事实有来源”“结论回应指定问题”“资料不足时说明限制”。
能明确判定的要求，尽量拆小，给出通过、不通过、无法判断的例子。有程度差异的质量，也可以分级；没有必要强迫所有问题都只有是和否。
业务专家、产品和测试人员先独立判断同一批材料，再比较分歧。如果大家对标准理解不同，机器评判也很难可靠。需要有人维护规则，但规则是否合理，仍要由实际任务和用户需求检验。
用一组有代表性的任务，而非只挑成功演示
任务应覆盖日常高频、历史失败、边界与异常情况。哪些场景适合自动处理，哪些应该澄清、拒绝或交给人工，都要测。
例如测工具使用，既要包含“应该调用”的任务，也要包含“不应该调用”的任务。不然可能把 Agent 优化成凡事都调用工具。
AI 可以帮助扩充样本，但生成材料要由人核验。保留一部分没有用于调优的任务，有助于检查效果是否只对熟悉题目成立。不同难度、风险和用户类别，也应分开看。
按问题选择规则、人工或AI
格式、必填项、参数范围、真实记录等明确条件，优先用程序检查。开放质量和复杂业务判断，可以由人或经过校准的AI评价。
人工负责定义标准、处理分歧和抽查；AI协助扩大检查范围。让它说明结论对应哪条标准、依据是什么，证据不足就暂不判定。
校准时，比较人工与AI对同一批样本的判断，尤其查看AI把失败误判为成功的情况。总体一致率很高，也可能因为样本大多容易通过。一致不等于正确，高风险失败需要单独检查。
在可比较的条件下运行
比较两个版本时，尽量使用同一批任务、同样的初始条件、同一套评分标准。关键任务重复运行，并清理前一次运行留下的文件或状态，避免后一轮占了便宜。[1]
若外部数据、接口或测试环境发生变化，记录下来。任务失败时，区分 Agent 的问题与环境的问题；对用户来说任务可能都未完成，对修复来说原因却不同。
允许重试、人工接手和最大预算也要统一。只报告结果更好的那一次，测到的很可能是选样能力。
把离线结果接回真实使用
离线测评是用准备好的任务和约定条件比较方案，既可用于上线前验收，也可用于上线后的回归与迭代；线上评价是在真实使用中发现新问题。两者相互补充，不能互相替代。
修改模型、提示要求或操作指南后，重新检查过去能做对的任务，这就是回归测试。某份操作指南单独通过，也要检查接入整个 Agent 后的表现。
想判断是否带来业务收益，还需要用户研究、线上数据，或合理设计的对照实验。把新发现的失败补进测试集，再检查修复有没有影响其他能力。
通过门槛要由场景风险决定。生成可编辑草稿与执行不可逆操作，要求不同。小样本中没有越权，也不能推出上线后风险为零。
07｜避开误区，也检查自己是否理解
只盯总分，容易丢掉问题所在。结果、效率、风险最好能分开看，再按任务类别定位。评分规则改变后，分数也要注明版本，不能把尺度变化当成能力提升。
只盯执行步骤，容易把不同解法当错误。应限制危险行为、检查关键条件，保留合理的替代路径。
只盯工具平台，容易忽略最重要的准备工作：任务是否清楚，证据是否完整，标准是否可信。工具能帮助记录和统计，不能替业务团队决定什么叫成功。
最后用四个问题自检：
- Agent 说“已处理”，为什么可能还没完成？因为文字需要与交付物或业务状态核对。
- 两个版本完成率都是90%，为什么不能直接说一样好？因为任务、重试、人工介入、成本和风险可能不同。
- 有完整日志，为什么仍可能无法评分？因为可能缺成功标准、初始条件或真实结果证据。
- AI评委和人高度一致，为什么还要抽查？因为双方可能共同漏掉问题，样本也可能没有覆盖高风险情况。
如果能用自己的话解释这四点，就能开始判断一套测评是否站得住脚。下一步不必先收集几十个指标，可以先选最重要的一类任务，写清成功标准，确认需要的证据能被拿到。
参考资料
- 美团技术团队：《Agent评测漫谈——由浅入深讲解Agent评测》，2026-08-06。原文。本文的基础来源。
- [1] Anthropic：Demystifying evals for AI agents，2026-01-09。
- [2] Langfuse：Model Usage & Cost Tracking。
- [3] Langfuse：Observability Data Model。
- [4] OpenTelemetry：GenAI semantic conventions 官方仓库。
- [5] Langfuse：LLM-as-a-Judge。
公开资料核对日期：2026-10-07。指标分类、信息清单及图解为本文的教学整理；具体字段与产品能力以所用工具版本为准。