Q96 · 当前 AI Agent 有哪些主流的评价指标？

客服 Agent 回答“已经为您创建售后单”，用户看见的文字很顺畅；但后台没有售后单。只评“回答是否像客服”会给它高分，只看“有没有调用建单工具”也可能漏掉工具返回失败。评价 Agent 要同时看任务最终状态、过程动作、答案证据、安全边界和完成代价，再用真实用户反馈校准。所谓“主流指标”是这些常见的评价维度，并没有一个适用于所有业务的统一总分公式。Anthropic 的 Agent 评测实践把执行记录与环境中的最终结果分开评价；OpenAI 的 Agent 评测文档也强调用执行轨迹定位工具选择、交接和策略遵守问题。

下图的四张检查板围绕同一批客服任务：不要用“任务成功率 90%”一项遮住越权操作、错误引用或过高延迟。“答案与安全”可再拆开分别计数，“效率与体验”也各有不同的分母。

术语、符号与固定任务集

词或符号	在本文中的含义
Agent	根据用户目标选择工具、读取结果并决定下一步的应用；本文是能查订单、查政策和创建售后单的客服系统。
评测任务 / 样本	一条带输入、模拟环境与预期结果的测试题，例如“用户 U7 为本人订单 O37 创建售后单”。
一次运行 / trial	Agent 对某条任务执行一次。模型可能每次做出不同选择，所以同一任务可重复运行多次；本文示例先固定每题运行一次。
评测集	一组事先定好的任务。本文用 100 条虚构客服任务；所有百分比都要说明从其中哪些任务或运行计算。
评分器 / 判定条件	判断一次运行是否满足某个目标的程序规则、模型评价或人工复核。最终数据库状态可用程序查；礼貌与清晰度可用人工或经过校准的模型评价。
轨迹 / trace	一次运行中的步骤记录，包括模型回复、工具调用、工具结果、交接与最终答复。记录需遵守隐私与脱敏要求。
最终状态 / outcome	执行完后环境里真实留下的结果，例如售后单是否存在、关联了哪个订单，而不是 Agent 说它做了什么。
分母	一个比例里“总共有多少次应被评价的机会”。若只统计成功返回的请求而丢掉超时，成功率会被抬高。
适用样本	某指标真正相关的任务。例如“越权写操作率”只在需要写操作的任务里有直观意义，同时还应监控全部请求中的异常写调用。
引用 / 证据支持	答复中的关键事实是否能对应到有效政策条款或真实订单字段；有链接不等于链接支持这句话。
时延 / Token / 成本	时延是用户从发问到收到可用结果的等待时间；Token 是模型计费的文本单位；成本包含模型与工具等实际运行费用。
p50 / p95	时延分位数：把所有运行时长排序，p50 约是中位数，p95 反映较慢的一端，不能仅靠平均值替代。
满意度 / CSAT	用户对服务是否满意的反馈比例。CSAT 是 Customer Satisfaction 的缩写；只回复问卷的用户可能与未回复者不同。

任务集假设：100 条案例来自同一个虚构客服业务版本，其中 40 条查订单状态、30 条解释退款资格、20 条在授权后创建售后单、10 条因规则冲突而正确转人工。50 条“退款资格 + 建单”任务要求引用当前政策；20 条建单任务涉及写操作。所有任务有明确的用户身份、订单权限、政策版本和预期状态，彼此的测试环境会重置。下面所有数字只是同一次示例运行的教学数据，不是任何产品的实测成绩，也不能直接与别人的评测集比较。

先定“完成”，再算成功率

端到端任务成功率是最先要看的指标：成功的完整任务数 ÷ 所有应完成的任务数。在这 100 条任务中，假设 76 条符合各自的完成标准，便是 76/100 = 76%。四种任务的标准不同：查订单要给出与订单记录一致的状态；解释退款资格要正确应用政策；建单要在数据库里真实存在归属于正确用户和订单的售后单；冲突案例要在不乱承诺的前提下成功转人工。超时、工具报错和模型中途退出仍在这 100 条分母内。对于本来要求转人工的 10 条，正确转人工算成功；对可以自动完成的建单任务，随意转人工不能算自动任务成功。

看一条正常运行：任务 T37 要为已验证身份的 U7 的订单 O37 创建售后单。Agent 查到订单属于 U7，读取当前政策，取得用户确认，调用建单工具，收到单号 S37，最终数据库里也能查到 S37 关联 O37。最终答复说明已建单并给出单号。这条任务在最终结果上通过。

再看失败任务 T88：Agent 写“已为您创建售后单”，轨迹中也出现建单工具调用，但工具返回超时，数据库里没有对应单。若只看最终话术或是否调用过工具，它会被误判；查环境最终状态则应判失败。Anthropic 在 Agent 评测定义中明确区分完整执行记录与最终环境状态，并举过“声称已订票但数据库没有预订”的同类情形。来源

端到端成功率也可以按任务类别分别报。例如总数 76/100 并不告诉我们失败是否集中在 20 条建单上。若建单只有 10/20 成功，而查订单 38/40 成功，工程优先级就很清楚；不能用容易的查询题淹没高风险写操作。上线评测时保留任务类别、难度、政策版本，并将旧版与新版在相同评测集和环境下比较。

过程、答案与安全分别看什么

工具轨迹合规率问的是：Agent 是否做了必要动作、避开禁止动作、正确处理工具失败。对这组任务，假设 85/100 条满足各自的关键过程约束，于是合规率是 85%。建单题的必要动作是身份与订单归属检查、用户确认、建单结果核验；禁忌动作包括未经授权直接退款。订单查询题不要求建单。这个指标不是“与一条标准工具调用顺序完全相同”的比例：不同的合法查询顺序可能得到一样正确的结果，评分器不该惩罚合理路径。Anthropic 的评测经验也提醒不要把唯一工具顺序写成过于僵硬的标准，优先检查实际结果与关键约束。来源

答案正确性检查最终话语中的订单事实、政策条件与结论是否相符；证据支持率专看需要资料支撑的关键说法。假设 50 条政策相关任务中有 45 条的所有关键政策结论都能由当前有效条款支持，按“每条任务全部关键政策结论均受支持才算通过”的口径是 45/50 = 90%。其余 50 条无需政策引用，不能混进这个分母把 90% 稀释或抬高。引用了正确标题但正文不支持结论，也不算通过。无须让每一句寒暄都带引用，重点是影响用户决定的实质性说法。答案清晰、礼貌、覆盖问题可以另外打分，但不应代替事实核对。

安全与权限指标要单列，不能用高任务成功率抵消。假设 20 条写操作任务中，19 条没有未经授权的写操作尝试，1 条尝试跳过审批发起退款但被后端拦下；“无违规尝试率”是 19/20 = 95%，同时报告“违规尝试 1 次，实际越权写入 0 次”。后端成功拦住意味着状态未被改坏，却不能把 Agent 的不安全决策记为安全。还要检查有没有泄露别的用户订单、把工具结果中的恶意文本当指令、绕过转人工规则等，按各自可触发的样本与严重程度报告。高严重度事件通常应有硬门槛，例如“实际越权写入必须为 0”，而非与礼貌分数做加权平均。

一组指标可以按下表汇报。各行不能相加、不能互作分母；它们描述同一批运行的不同侧面。

指标	本例口径与分母	示例读数	容易误读之处
端到端任务成功率	全部 100 次运行；按各题的最终状态判定	76/100 = 76%	话术好或调用过工具不等于任务完成。
关键轨迹合规率	全部 100 次；各题检查必要与禁止动作	85/100 = 85%	不要求每次执行完全同一条路径。
政策结论证据支持率	50 条需要政策结论的运行	45/50 = 90%	引用存在不等于支持了结论。
写操作无违规尝试率	20 条涉及写操作的运行	19/20 = 95%	被后端拦截的危险尝试仍要计入。
实际越权写入次数	全部 100 次运行中检查环境副作用	0 次	零实际损害不等于 Agent 决策安全。

时延、成本与用户体验不能漏

效率也要在同一批 100 次运行上测，包含失败与超时。假设端到端时延 p50 = 4 秒、p95 = 13 秒：前者说明典型等待，后者暴露慢尾；还可记录模型调用数、工具调用数、重试数、Token 总量和每题费用。假设这 100 次共花了 4 美元的模型与工具费用，则平均每次任务成本是 4/100 = 0.04 美元，按本次 76 条成功任务摊算是 4/76 ≈ 0.053 美元/成功任务。后一个数把失败运行的成本也计入，但并不表示每条成功任务实际只花这么多。具体价格随所用模型、工具和时间变化，这里只是算术例子。

用户体验可看用户满意度、再次来问的比例、人工接管质量与投诉。假设 100 次服务中仅 20 人回复满意度问卷，其中 14 人给好评：回复者好评率为 14/20 = 70%，问卷回复率为 20/100 = 20%。不能把 70% 说成“70% 的全部用户满意”，因为未回复者的意见未知，也可能有选择偏差。离线评测中的 100 条模拟任务不能产生真实 CSAT；上面两个数若使用，必须来自对应版本上线后的真实问卷，并标明采样期、受访人群和样本量。本文把它放在同一业务示例下，是为了说明离线质量和线上体验要并列看，不能假装它们来自同一套模拟数据。

一个改版可能把成功率从 76% 提到 81%，同时让 p95 从 13 秒升到 40 秒、每题费用翻倍，或多出一次危险工具调用。是否值得发布取决于业务的时效、安全和成本要求。应预先约定目标与红线，分别呈现指标，再做取舍；单个“综合分 92”会隐藏这种代价。OpenAI 的评测文档把轨迹评分用于定位工具、交接和策略问题，正因为只看最终答复难以说明为什么某次运行失败。来源

怎么把这些数字测得可信

先为每条任务写清初始状态、允许的工具、预期最终状态和关键禁令。评测环境在每次运行前复位，避免上一次运行留下的售后单让下一次“碰巧成功”。确定性内容如“数据库有没有单”“订单是否归属用户”“调用是否越权”尽量由程序判；政策解释与语言质量可交给有评分规则的模型评价，并抽样由人工复核。模型裁判也会误判，尤其是政策边界与复杂上下文，不能把它的分数当成真值。Anthropic 建议结合程序、模型和人工评分，并检查完整轨迹，发现评分器误杀合法解法时修正评价规则。来源

由于模型输出有随机性，只做一轮可能碰巧好或坏。对重要任务重复运行、固定环境与版本，并报告运行次数和波动。上线后继续监控真实错误、延迟、人工接管与反馈，再把新的失败案例加入评测集。离线集若全是老题，即使接近满分也不表示新问题能解决；高风险样本尤其要持续补充。评测轨迹可能含订单信息，采集和人工复核时应做访问控制与脱敏。测试用的危险写操作必须接在可复位的模拟环境，不能为了测评分而触碰真实用户订单。

面试时怎么回答

我会把 Agent 指标分成四组，并在每项旁写清分母。第一组是端到端任务成功率：看真实环境中的订单状态、售后单或转人工结果，而不只看最终话术。第二组是过程轨迹：必要工具是否调用、权限与审批是否遵守、工具失败有没有正确处理；不把合法的不同路径误判为错误。第三组是答案质量、证据支持和安全：政策结论要被当前有效条款支持，越权写入等高严重度事件单独设红线。第四组是效率与体验：看时延分位数、Token 和每成功任务成本，以及标明样本量和回复率的用户满意度。比如 100 条客服任务里 76 条最终完成，就报 76/100；50 条要求政策依据的题有 45 条获支持，就报 45/50，不能混成一个好看的百分比。上线前用可复位环境、程序判定、模型评价和人工抽检；上线后用真实故障和反馈持续补充评测集。

如果追问“工具轨迹错了，但最终结果对了怎么算”，可以分开报告：最终任务成功可能通过，过程合规可能失败；若过程触犯了权限红线，不能用最后结果正确来抵消。若追问“什么时候用模型当评分器”，答：事实状态、权限和精确计算先用程序；需要判断解释是否切题、表达是否清楚时才考虑模型评分，并用人工样本校准。两种追问都说明：评价 Agent 是一组可解释的证据，不是一个万能分数。

资料依据

• Anthropic：Demystifying evals for AI agents：任务、运行、轨迹、最终状态、评分器、环境复位与多层评测的定义和实践。
• OpenAI：Evaluate agent workflows：用轨迹与评分器分析工具选择、交接和策略遵守。