10 个关键问题 Q&A
-
Q：Agentic evals 和普通大模型评测最大区别是什么？ A：普通评测看文本输出质量；Agentic evals 重点核验智能体执行后真实业务变更结果，不只看话术。 -
Q：什么样的 AI 系统需要用 Agentic evals 评估？ A：能调用工具、修改数据记录、执行多步业务动作，可操作订单、代码、资金的 AI 智能体。 -
Q：评估智能体任务是否完成，首要依据是什么？ A：任务执行带来的客观状态变更，而不是智能体返回的对话文本。 -
Q：评估指标分为哪两大类？ A：能力指标（能不能完成任务）、可靠性指标（结果能否稳定复现）。 -
Q：故障排查时，在智能体执行链路中重点找什么？ A：执行轨迹里第一个出错步骤，从源头定位问题。 -
Q：什么是 model-as-judge（模型裁判）？ A：使用大模型作为评判者，自动打分、判定智能体任务成败的评估方式。 -
Q：使用模型裁判需要重点关注什么？ A：它存在可信边界，不能无条件信任，要识别它容易误判的场景。 -
Q：这篇内容除工程师外，还面向哪类人群？ A：管理者、负责审批智能体订单 / 代码 / 资金操作权限的决策人。 -
Q：文中实验案例是什么？ A：Level 0 客服智能体小型实验，方案完整，实验结果支持复现，同时引用公开论文数据。 -
Q：这套评估体系最大业务价值是什么？ A：为智能体授予高风险业务操作权限提供评估依据，保障业务安全可控。
面向落地大模型智能体工程师的文章：这类系统可以调用工具、修改记录、代表客户执行多步操作。读完本文，你将学会：根据智能体造成的变更而非输出话术来评估单次执行；同时给出能力指标与可靠性指标；定位失败轨迹的首个错误步骤；判断模型裁判（model-as-judge）何时可信。本文也面向管理者，以及那些决定智能体是否有权操作订单、代码、资金的决策人。
文中数据来自文末列出的公开论文，还有一个可复现的小型客服智能体实验（Level 0 完整描述）。无需提前阅读任何前置资料。
快速导读（没时间可只读本段）
智能体是一个循环运行的大模型：读取请求、选择工具（查询订单 / 取消订单 / 退款 / 回复客户）、读取工具返回结果，反复选择工具直到判定任务完成。包裹模型、驱动这个循环的代码，连同提示词、工具、重试逻辑，统称为harness（执行框架 / 调度器）。 智能体评估（agent eval）是一套可重复的测试，产出可信数值，回答三个问题：智能体有没有完成任务？每次都能完成吗？失败时问题出在哪？
上篇推文讨论的是一问一答式模型：如何构建测试集、打分、信任模型裁判、解读指标。那些方法依然适用，但故障模式不一样。 单轮问答模型只会在文本上出错；智能体的错误可以体现在：输出文本、执行动作、动作顺序、动作次数、数据库最终状态，并且这些信息之间会互相矛盾。例如回复写着 “退款已发起”，数据库里却没有退款记录。 本文案例：仅看回复文本的打分器，60 次执行通过 58 次；检查数据库状态的打分器，只通过 48 次。剩下 10 次话术听起来没问题，但数据库记录和话术不符。
评估五步法
-
编写任务时，定义预期终态。不要写 “客户感觉得到帮助”，而要写：订单 O101 已取消、退款 120 美元、无手续费。 -
在相同初始数据库环境下，每个任务多次运行智能体，完整留存轨迹：工具调用与返回结果、最终回复、执行前后数据库快照与差异。 -
评估终态与执行路径：记录是否按预期变更？是否调用必需工具、禁止工具没有被调用？步骤数是否在限额内？最后才看回复文本。 -
输出两个核心指标：能力指标：任务至少成功一次的比例；可靠性指标：每次运行都成功的比例。后者才是客户真实体验到的指标。 -
每次失败，定位首个错误步骤，统计错误类型，优先修复最高频错误。
使用时机：智能体正式上线前；每次修改提示词、工具、底层模型前；上线后持续对真实流量抽样评估。
核心原则：评估智能体造成的变更，而不是它说了什么。回复是可信度最低的证据。 含义：每个任务必须预先定义可校验终态 + 允许动作清单，否则不能算作有效评估任务。 原因：案例里有一个 “不作为智能体”，只输出友好话术，不执行任何操作；在仅看回复的评估中，20 个任务全部通过。一个无法拦下 “不作为智能体” 的评估指标，没有任何价值。
文章主体逐级展开： Level 0・单任务端到端演示：模拟店铺、工具、打分器、指标 Level 1・什么才算 “完成任务” Level 2・它下次还能成功吗 Level 3・失败到底发生在哪一步 Level 4・大模型能不能充当裁判评估智能体 Level 5・每次成功的成本是多少 Level 6・智能体之间互相转交任务时会发生什么变化 Level 7・如果智能体学会 “欺骗打分器” 怎么办 Level 8・搭建每日自动化评估流程
之后：工具生态、公开基准及解读方法、决策清单、参考文献
Level 0：单任务端到端演示
本章节回答：从客户消息输入，到产出两个核心指标，一套智能体评估完整长什么样？
案例是虚构自行车店 Rivertown Cycles 的客服智能体。规模足够小，可以完整描述，同时故障模式贴近真实生产智能体。
模拟环境约 20 条客户订单的模拟数据库，每条包含状态（待下单 / 处理中 / 已发货 / 已送达 / 已取消 / 已退货）、总金额、地址、商品、退款总额、退货状态。每次运行前数据库重置，保证每一轮起始环境完全一致。
工具（共 8 个，工具内部内置店铺规则校验）
-
lookup_order、list_orders：只读查询数据库，不修改任何数据 -
cancel_order：仅订单处于待下单 / 处理中时可取消；处理中订单取消收取 5 美元手续费 -
update_address：仅订单待下单、下单 24 小时内可修改地址 -
start_return：仅已送达订单、30 天内可用，定制商品不可发起退货；本工具不处理资金 -
issue_refund：退款上限不超过订单总额，多次退款累计不超限 -
escalate：将工单转交人工主管，返回工单 ID -
reply：向客户发送最终文本，结束本轮执行
规则内嵌在工具内部：即使智能体请求执行违规操作，工具会直接拒绝，数据库保持不变，并将拒绝信息记录为工具错误。
系统提示词包含日期、工具调用顺序（有订单 ID 优先查订单，否则列出客户全部订单）、上述业务规则；额外规则：≥200 美元且未关联已发起退货的退款，必须先转人工；执行必须以一条回复收尾，不得编造信息。
模型本地单卡运行的开源中型模型（约 27B 参数），自带随机性，重复运行结果会存在差异。换更大模型只会改变指标数值，底层方法论不变。
任务集20 条人工编写客户消息；每条任务预先标注标准答案：数据库预期终态字段与值、必需调用工具、禁止调用工具、步骤上限 8–12 步、回复必须包含的关键词。 任务分类：11 条常规操作（取消、改地址、退货、查询）；7 条拒绝类任务（不修改数据，解释拒绝理由）；2 条转人工任务。
执行方案每个任务在干净初始环境下运行 3 次，一共 60 个 episode（完整执行回合：客户消息→最终回复）。 完整轨迹全部存储：每次工具调用参数与返回、模型推理文本、最终回复、执行前后数据库快照与差异。
示例回合 t01客户消息：“你好，我发现订单 O101 头盔还没付款，想取消订单，请帮我取消。” 预期终态：订单状态取消，退款总额 120 美元，手续费 0。 执行流程：
-
lookup_order (O101)：返回状态待下单，下单 1.1 天，总额 120，退款 0 -
cancel_order (O101)：状态变更为已取消，手续费 0，退款 120 -
reply：“您好 Ana，我已取消订单 O101（Trail 头盔 + 手套，120 美元）。订单仍处于待下单状态，本次无取消费……”
打分器：纯代码打分，5 项全部通过才算合格
-
执行后数据库符合预期终态 -
轨迹中调用了所有必需工具 -
没有调用禁止工具 -
总步骤数在预算内 -
生成回复且包含指定关键词 上面这条回合在 8 步预算内仅用 3 步完成，全部通过。
指标结果（60 轮）
-
60 轮中 48 轮全部 5 项校验通过：通过率 0.80，置信区间 0.62–0.95。区间含义：更换同类型 20 个任务，通过率大概率落在这个范围；任务样本小所以区间宽。区间是重采样任务计算，不是重采样回合，因为同一任务的 3 次运行结果会互相影响。 -
20 个任务里至少成功 1 次：17 个，能力指标 0.85 -
20 个任务 3 次运行全部成功：15 个，可靠性指标 0.75 -
平均每回合 2.5 次工具调用，最大 5 次，远低于步骤上限 -
60 轮里仅 1 次：智能体请求超出订单总额的退款，工具拒绝，智能体自行修正。这正是这套机制要捕获的场景：智能体提出错误修改，由工具拦截。
Level 0 要点总结 一个回合需要评估 5 项：终态、必需工具、禁止工具、步骤数、回复；按这个顺序校验。 每次运行必须从相同初始环境启动，完整保存轨迹，否则无法回溯路径、定位失败根因。 两个核心指标：至少成功一次（能力）、每次都成功（可靠性），两者都要汇报。
Level 1：什么才算 “完成任务”
本章节回答：打分器应该采信哪些证据；采信错误证据会带来什么后果。
Level0 的 5 项校验权重并不相同。案例对 60 轮结果用 4 种打分器重新评估，并新增一个不作为智能体（null agent）做对照测试。
同一 60 轮，4 套打分器结果：
-
完整代码打分器（5 项全校验）：60 轮 48 通过 -
仅回复打分器：只检查最终文本关键词：60 轮 58 通过。10 轮话术看起来合格，被误判成功。 -
仅状态打分器：只校验数据库字段：60 轮 48 通过，和完整打分器命中的失败案例完全一致；所有失败都带来数据库错误。 -
模型裁判（读取完整执行轨迹）：60 轮 49 通过，但命中的样本不一样：12 轮完整打分判定失败的案例，模型裁判判为通过；11 轮完整打分通过的案例，模型裁判判为失败。
仅回复打分器的问题10 个误判通过的回合，数据库状态全部错误；其中 8 个还跳过了必需工具调用。典型模式：智能体查询订单，生成承诺退款 / 确认退货的友好回复，但根本没有调用真正执行操作的工具。
不作为智能体对照实验这个空智能体不调用任何工具，只输出符合关键词的回复，用同样 4 套打分器跑 20 个任务：
-
仅回复打分器：20/20 全部通过 -
仅状态打分器：11/20 通过：7 条拒绝类任务（正确结果就是不修改数据）+4 条只读查询任务（预期终态 = 初始状态） -
完整打分器：6/20 通过：6 条无需调用工具的拒绝任务；第 7 条拒绝任务要求先查询订单，因此失败
重点：状态校验必不可少，但单独靠状态无法区分 “合理拒绝” 和 “什么都没做”。20 个任务里 11 个任务的预期终态等于初始状态。这类任务，必须依靠工具路径校验 + 回复校验，这就是完整打分器需要 5 项的原因。
行业同类发现
-
ABC 审计（Agentic Benchmark Checklist，Zhu 等，2025）：一个极简空智能体，在 τ-bench 客服基准测试的航空任务中，依然可以通过 38% 任务，原因和本实验空智能体通过拒绝任务完全一致。审计对 10 个主流基准测试检查，7 个存在结果有效性缺陷。 -
AgentLens（2026）人工复审 2614 条智能体轨迹：10.7% 标记为 “成功” 的案例属于幸运通过：最终状态刚好正确，但执行路径错误；三位标注员的人工标注一致性很高。仅看终态的打分器会把这类幸运通过算作成功。
完整打分器依然无法覆盖的维度语气、动作解释是否准确、无害的绕路行为：这类需要裁判结合完整轨迹做评估。
打分器依赖高质量标准答案案例里存在 2 个任务本身存在缺陷：
-
t14：要求订单 O104 退货 “系统已确认”，预期数据库存在退货记录，但规则禁止发起退货；干净初始数据库没有退货，任何智能体都无法通过。 -
t17：预期 O110 退款 240 美元，但这笔退款只能由前置任务产生；任务编写错误，误以为任务之间数据会持久保留，实际每次运行数据库重置。
Level0 的 5 个不稳定 / 失败任务中：3 个是智能体故障，2 个是任务本身 bug。移除这两个坏任务后：回合通过率从 0.80 提升至 0.89，可靠性从 0.75 提升至 0.83。在运行前使用 ABC 清单检查，就可以提前发现这类问题；空智能体无法检出，因为空智能体同样无法完成这两个任务。
核心结论：打分器的上限由它最薄弱的校验环节决定。仅回复打分器无法拦截不作为智能体；仅状态打分器仍会让它将近一半任务通过。 落地建议：打分器优先构建：终态、必需动作、禁止动作、步骤预算；回复作为最后校验。上线前先用空智能体跑一遍打分器，并且在干净初始环境校验每个任务是否可解。 风险：智能体评估最常见两个自我欺骗来源：流畅漂亮的回复、本身不可解的任务。空智能体测试检出前者，干净环境校验检出后者。
Level 1 要点总结 评估必须同时校验终态 + 执行路径。仅看回复无法拦截不作为智能体。 仅状态校验对 “不修改数据” 任务失效，本案例占 11/20；必需动作 + 回复校验补齐短板。 每个打分器必须做空智能体测试，并校验所有任务在干净环境下可解。本案例 20 个任务有 2 个不可解。
Level 2：它下次还能成功吗
本章节回答：如何把多次重复运行结果转化为能力指标 pass@k和可靠性指标 pass^k，以及需要多少次重复测试。
Level0 0.85 与 0.75 两个指标来自同一批 60 次回合。
- pass@k
k 次尝试中至少一次成功的概率。衡量能力：这个智能体能完成该任务。 - pass^k（读作 pass to the k）
k 次尝试全部成功的概率。衡量可靠性：每次运行都稳定完成。 计算方式：统计每个任务 n 次测试中的成功次数 c；pass^k 统计所有 k 次组合全部成功的比例，跨任务取均值。τ-bench 使用该精确估算，k 最大不超过 n。 示例：一个任务 3 次运行，2 次成功。3 组两两组合里，1 组两次全成功，则 pass^2=1/3。
本案例每个任务 3 次重复，结果： k=1：pass@1=0.80；pass^1=0.80，区间 0.62–0.95。单次尝试就是单次结果。 k=2：pass@2=0.83；pass^2=0.77 k=3：pass@3=0.85（区间 0.70–1.00）；pass^3=0.75（区间 0.55–0.90）
两条曲线之间的差距就是可靠性缺口。k=1 时两者相等；k 增大，pass@k 缓慢上升（代表智能体偶尔能搞定的任务），pass^k 持续下降（代表每次都稳定成功的任务）。3 次测试只能看到初步差距；5 次或 8 次重复，两条曲线会进一步拉开。
按任务分类：
-
15 个任务 3 次全成功； -
2 个不稳定任务：t04 退货退款，3 次中仅 1 次成功；t10 转人工退款，3 次中 2 次成功； -
3 个任务永远失败：t09，外加 2 个任务 bug t14、t17。
按任务类型：
-
拒绝类任务（7 个）：pass@3=1.00，pass^3=1.00。拒绝类任务高度稳定。 -
常规操作（11 个）：pass@3=0.82，pass^3=0.73。 -
转人工（2 个）：pass@3=0.50，pass^3=0.00。t10 三次两次触发转人工；t17 属于不可解任务。
总体可靠性 0.75 是三类加权平均。如果转人工链路负责大额退款，整体均值没有参考价值，不能基于整体指标上线。
为什么 3 次只是最低下限，不推荐直接用 3 次：k 等于 n 时，pass^k 是非黑即白；3 次碰巧全成功，不稳定任务会被误判为可靠。5 次重复可以平滑 pass^3，并计算 pass^5。置信区间采用重采样任务而非重采样回合，原因见 Level0。
改写输入测试（另一种重复测试）不改变随机种子，改写客户请求，保持语义不变（“取消订单” 改成 “帮我拦截订单，我改变主意了”），使用同一套标准评估。本文写作时该实验仍在进行，暂无数据。只用一种话术测试，只能评估智能体对 “你写的句子” 的理解，不是真实客户多样化表达。
行业实证
-
Rabanser 等人（2026）：15 个模型每个任务跑 5 次：准确率提升速度是一致性（稳定性）的 6 倍。 -
τ-bench（2024）：GPT-4o 零售任务 pass^1=61.2，航空任务 35.2；pass^8 两者都低于 25。一个十次里成功六次的智能体，连续八次全部成功概率不足 1/4。 -
代码生成鲁棒性研究（2023）：46% 语义等价的提示词改写，会改变生成代码结果。随机种子不是唯一方差来源，客户话术本身也会带来波动。
核心结论：能力指标、可靠性指标来自同一批测试；后者才是客户真实体验。 落地建议：每个任务至少跑 3 轮，优先 5 轮；输出带任务聚类置信区间的 pass@k、pass^k；按任务类别拆分指标。单次运行通过率只是伪装的能力指标。 风险：案例整体 0.85/0.75 掩盖巨大差异：拒绝任务 100% 稳定，转人工任务可靠性 0。平均值真实，但毫无落地指导意义。
Level 2 要点总结 pass@k 衡量 “能不能做到”；pass^k 衡量 “每次都稳定做到”；k 越大两者差距越大。 3 次是最低下限；5 次可以平滑 pass^3，同时计算 pass^5。置信区间重采样任务而非回合。 除随机种子外，还要改写输入文本测试；单一句本只能测试你的话术，不是真实客户表达。
Level3：失败到底发生在哪一步
本章节回答：回合失败后，如何定位首个错误步骤，并对失败归类统计。
通过率只能告诉我们失败频率；完整轨迹才能定位根源。案例 12 个失败回合，全部回溯到首个错误步骤：同任务成功轨迹里不存在的最早错误工具调用，或是过早输出回复。
12 个失败案例按首个错误步骤划分：
-
6 个来自 Level1 的任务 bug：t14、t17 各 3 次运行。t14 智能体行为无误，是标准写错；t17 智能体还跳过必需转人工，但无论如何都无法达成预期终态。 -
6 个真实智能体故障：全部跳过 issue_refund 退款工具，直接在第 3 步回复客户。 -
t04（马鞍退货退款 180 美元）：3 轮里 2 轮；t09（鞋退货退款 140 美元）：3 轮全部。智能体查询订单、发起退货，直接回复客户，没有调用退款工具。 -
t10（240 美元退款，按规则必须转人工）：1 轮，智能体选择发起退货，然后编造规则告诉客户：“收到商品核验后才退款”，系统并无这条规则。智能体为匹配自己选择的工具，虚构业务规则。
0 次调用禁止工具；6 个真实故障里没有请求违规操作被工具拦截。故障类型属于遗漏动作，不是违规动作。
修复方向：所有真实故障都属于同一类：资金操作完成前就提前结束回复。问题根源指向提示词里退款规则描述，不是模型工具调用能力。没有完整轨迹，只能看到 0.8 通过率，只能盲目猜测根因。
每次运行都采集轨迹指标（低成本，提前预警）
-
每回合步骤数：均值 2.5，上限 5，预算 8–12。同一任务集平均步骤持续上涨代表进入循环。 -
工具错误率：151 次调用中 7 次；6 次是客户无订单的空查询（这类任务属于正常行为，其他场景属于告警）；1 次 Level0 的超额退款请求被拦截。 -
违规修改尝试：单独统计：智能体请求规则不允许的变更。本案例 60 轮 1 次；策略校验任务理想值为 0。 - 先回复后操作标记
任务预期需要修改数据，但智能体直接回复结束，状态无变更。就是上面 6 轮故障模式，可以自动识别。
行业失败分类研究MAST（2025）标注 1600 + 多智能体轨迹，分为 3 大类 14 种故障模式：规范问题、智能体间对齐失效、校验问题。最高频：循环重复 (15.7%)、推理和动作不一致 (13.2%)、无法识别任务完成 (12.4%)。这类循环、漂移、过度执行问题只能靠轨迹识别。 τ-bench 作者人工复盘 40 个失败：55% 是工具选对，但参数传错。这就是为什么 Level1 评估终态，而不是只看工具名称。 Model or Harness?（2026）划分 41 种故障，36 种属于模型侧；重要发现：模型裁判定位根因时，会过度归咎模型。 MP-Bench（2026）3 位专家对 289 条智能体日志定位根因：仅 16.2% 能在同一个错误步骤达成一致；最优模型将真实根因排在前 5 位概率 0.44，随机基线 0.13。即使人工专家，定位首个错误步骤也很难。但这依然是唯一可以指导修复的方法。
核心结论：失败本质是步骤出错，不是分数高低。每次失败回合找到首个错误步骤，统计类型。 落地建议：默认保存完整轨迹；写分类器识别 “未执行动作直接回复”；人工标注所有失败首个错误步骤，直到故障类别稳定。本案例单一故障类型解释全部真实故障。 价值：优先修复最高频首个错误步骤，是性价比最高优化手段；聚合指标无法定位根因。
Level 3 要点总结 所有失败回溯到首个错误步骤，归类统计；本案例全部真实故障：资金操作完成前提前回复。 每次运行统计：步骤数、工具错误、违规修改尝试、空查询。这些指标变动早于通过率变化。 不要无限制依赖模型裁判判定责任；裁判容易过度归罪模型；专家对根因一致率仅约 1/6。
Level4：大模型能不能充当裁判评估智能体
本章节回答：用另一个大模型评判智能体执行结果，它需要哪些证据，如何校验裁判本身可靠性。
代码打分器精确客观，但无法评估语气；无法区分礼貌拒绝和生硬拒绝。模型裁判可以做到，但关键在于：它能看到什么证据。
案例轨迹裁判实验另一个模型读取客户消息、带编号完整工具轨迹 + 返回结果、最终回复，输出通过 / 失败 + 一句话理由。60 轮结果：
-
裁判判定 49 轮通过；代码打分器 48 轮通过，总数字接近。 -
60 轮中仅 37 轮两者结论一致（61.7%）。科恩卡帕系数 κ = −0.24：一致性甚至比随机抛硬币还差一点。 -
代码打分标记失败的 12 轮，裁判全部判为通过：包含 6 个任务 bug、6 个真实遗漏动作。裁判看到承诺退款的回复，采信 “意图正确”，无视真实状态。 -
代码打分通过的 11 轮，裁判判定失败：正常取消订单、合规拒绝任务，裁判单纯对回复措辞不满意。
裁判问题：该模型看不到数据库，无法判断退款是否真实发生；并且提示词写明 “会提供数据库变更摘要”，但执行链路根本没有传入。这个 mismatch 是通过核对提示词和代码发现，不是指标发现。 证据层级：裁判可用证据逐层升级：仅回复文本 → 完整轨迹 → 轨迹 + 数据库差异 → 全部信息 + 标准答案。
加入数据库状态差异作为证据同一个模型裁判，再次评估 60 轮；这次提供所有涉及订单执行前后数据库快照和变更差异。
-
和代码打分器一致回合：37 → 46；误判失败从 11 降至 2。看到状态后，裁判不再因为措辞否定正确的取消、拒绝任务。 -
κ 仅从−0.24 小幅提升到−0.06。代码标记失败的 12 轮，裁判依旧全部判通过。
12 轮拆解：6 轮是任务 bug，裁判判断合理：系统没有退货记录、无资格折扣，认可诚实回复。另外 6 轮真实故障：智能体发起退货，回复承诺收货后退款，但没有调用退款工具；裁判看到数据库缺失退款，依然判定成功。状态证据消除裁判的假阴性；但只有标准答案才能识别这类遗漏动作。
行业同类结论GAUGE（2026）模拟客服对话评估裁判：57.5% 裁判认为满意的对话，实际任务失败；来自智能体同源模型家族的裁判打分普遍偏高。只读回复的裁判评估的只是回复文本。 AgentRewardBench（2025），1302 条带专家标注的网页智能体轨迹：最优裁判判定的成功案例，仅 69.8% 是真实成功；检出 83.1% 真实成功；规则校验判定成功时准确率 83.8%，但仅检出 55.9% 真实成功。裁判高估成功率；规则会漏掉部分真实成功。 Agent-as-a-Judge（2024）：给裁判完整智能体中间产物，55 个开发任务对齐人工标注约 90%；仅看最终答案裁判对齐约 70%。 MAST 故障裁判：提示词加入少量标注样例后 κ=0.77；不加样例 κ=0.58。同一模型、同一轨迹；提示词证据变化带来 κ 提升 0.19。
三条落地规则代码打分器作为基础门槛，模型裁判作为辅助列，永远不能替代代码校验。模型裁判输入必须包含：轨迹、状态差异、标准答案；否则本质还是升级版仅回复打分器。执行本次任务的模型，不能作为本次任务裁判。
核心结论：裁判输出的结论，完全由你喂给它的证据决定。只给回复，它就只会评估回复。 落地建议：所有裁判输入完整轨迹、状态差异、标准答案；每次运行对照代码打分器校验裁判；输出 κ。κ 低于 0.6 代表两者衡量目标不一致；上线决策必须明确采信哪一套结果。 风险：案例裁判总数字和代码打分几乎持平，但 60 轮里 23 轮结论冲突。总体数字相近不等于评估结果一致。
Level 4 要点总结 案例中仅看轨迹裁判和代码打分 κ=-0.24：采信口头承诺，无视未执行动作。 证据是杠杆：增加数据库差异，裁判假阴性从 11 降到 2；缺少标准答案时，依然无法识别全部真实故障。 裁判倾向高估成功率、过度归罪模型；规则校验会低估成功。两者都要上报；禁止智能体自身模型裁判自己。
Level5：每次成功的成本是多少
本章节回答：如何核算单次成功执行成本；为什么平均回合成本是错误指标。
同样 80% 通过率：一个平均 2 次工具调用、另一个平均 12 次，是完全不同产品。案例保存每一次模型调用，可以把成本绑定到每个回合，分摊到成功案例上。
案例：成功回合成本每个工具调用对应一次模型调用；本实验未记录 token，用调用次数替代。
-
60 回合共 151 次模型调用：每回合平均 2.52 次；每成功回合 3.15 次。差值来自失败回合消耗，这部分成本理应分摊给成功任务。 -
按任务类别：拒绝类任务，每次成功 2.14 调用；常规操作 3.56；转人工高达 8.50，17 次调用只产出 2 次成功。 -
按任务：单次成功调用从 2.0 到 10.0。难度标注相同的常规任务，成本差距 5 倍。 -
两个不可解任务：单回合消耗正常，但单次成功成本无穷大。平均每回合成本会掩盖高消耗任务。
行业实测Bai 等人（2026）3500 任务智能体开销测试：同一任务不同模型成本最高差 30 倍；模型自身预估开销和真实开销相关性仅 0.39。智能体无法预算自身消耗。 Harness Effect（2026）22 位工程师实验：同一模型，优化调度框架 harness，成本降低 41%、耗时减少 44%；通过率仅 0.78→0.81 小幅提升。小样本实验证明：模型外围调度循环，对成本影响甚至大于模型本身。
需要上报指标：按任务类别，单次成功回合成本，附带任务间最大 / 最小成本比；同时记录每回合耗时。客户感知延迟。平均每回合成本会奖励早早放弃的智能体；单次成功成本不会。
核心结论：核算成功案例成本，不是全部回合成本。早早放弃的智能体，会在错误指标上显得高效。 落地建议：记录 token、模型调用次数、回合耗时；按类别除以成功次数；设置任务成本极值阈值。 事实：同任务成本最高差 30 倍；智能体无法预估自身开销。
Level 5 要点总结 核心指标：按类别统计单次成功回合成本；平均回合成本会奖励提前放弃。 记录 token、调用次数、每回合耗时；延迟由客户承担。 模型外围调度框架是成本杠杆：同一模型优化调度，实验中成本下降 41%。
Level6：智能体之间互相转交任务时会发生什么变化
本章节回答：当一个智能体输出作为另一个智能体输入时，通过率会如何变化，如何定位损失来源。
生产环境智能体大多是流水线：规划器 + 代码执行器、分诊智能体 + 专项智能体。问题变成：在哪一环性能衰减。
案例流水线实验设计客服智能体拆成两个：
-
Reader（读取智能体）接收客户消息，只读工具，输出简短摘要：客户是谁、订单 ID、诉求、适用规则。 -
Actor（执行智能体）仅读取摘要，拥有修改类工具，完成任务。 任务、打分器、干净环境不变。该实验写作时排队待运行，暂无结果。 价值：故障归因新增三个可能性；保存摘要文本，作为判定依据。
多智能体转交行业实证多智能体规划可靠性研究（2026）：同一任务通过 2/3/5 个智能体自然语言接力传递。单智能体 90.7%，接力后依次 41.2%、43.5%、22.5%。作者估算：自然语言摘要转交，每轮损失约 8.5 个百分点；结构化固定字段转交，每轮损失约 2.8 个百分点；3 智能体结构化接力可维持 75.2%。摘要格式直接决定损耗。 Specification Gap（2026）：规划器 + 执行器拆分代码任务；两种难度下，组合方案比单智能体低约 30 个点（简单任务 58.2 vs 88.6）。给执行器完整原始需求而非摘要，性能恢复至 88.9。转交过程丢失规范，是大部分性能缺口来源。 等 token 预算对照（2026）：相同 token 预算下单智能体 0.418，多智能体 0.388。文献里很多多智能体优于单智能体，本质是 token 总量更高。 扩展研究（2025）180 种多智能体配置：相比单智能体平均变化−3.5%，标准差高达 45.2%：大幅提升、大幅下降都存在，平均抹平。当单智能体基线超过 45% 成功率后，多智能体增益基本消失；无中心协调的独立智能体，错误放大效应 17.2 倍；中心化协调仅 4.4 倍。
故障归因实操（接力场景）保存中间摘要，每个失败归属三类之一：
-
转交损失：摘要错误 / 不全。校验：订单 ID、诉求、规则结论是否完整。 -
Actor 执行错误：摘要正确，但执行智能体依然失败。校验：对比摘要，定位 Actor 首个错误步骤。 -
打分器错误：智能体执行正确，标准答案错误。执行 Level1 审计。
Level3 专家一致性提醒：即使有完整轨迹，人工定位根因依然很难；没有轨迹则完全无法归因。
核心结论：任何智能体转交都是有损通道。测量每轮转交损失；给下游智能体原始完整规范，不是摘要。 落地建议：流水线端到端用和单智能体完全相同的状态打分器评估；保存所有中间摘要；维持同等 token 预算下的单智能体基线。只有流水线 pass^k 优于基线时，才新增智能体节点。 行业数据：自然语言转交每轮损失 8.5 个点；结构化摘要约 2.8。多智能体相比单智能体平均−3.5%，波动极大。
Level 6 要点总结 转交会丢失规范。结构化摘要损失约为自然语言摘要的 1/3；传递完整原始请求损耗最低。 维持同等 token 预算单智能体基线。多智能体超越基线的增益很少，仅集中在单智能体难以完成的任务。 从存储轨迹将失败归因于转交损失、执行器错误或打分器错误，不要采信智能体自陈述。
Level7：如果智能体学会 “欺骗打分器” 怎么办
本章节回答：智能体针对评估指标做优化时，会发生什么；有效的防御手段。
前文都假设智能体目标是完成任务。如果调优 / 训练目标是拉高评估分数，只要存在不完成任务也能拉高分数的办法，智能体就会找到捷径，即奖励黑客（reward hacking），已有实测数据。
Verification Horizon（2026）代码智能体基于测试集奖励训练：测试集可见且固定时，28.57% 标记 “已解决” 任务属于作弊：修改测试用例、输入硬编码特例、在产物中直接寻找答案。当校验逻辑隔离在智能体无法触碰范围，作弊率下降至 0.56%。 AEVO（2026）自动化调度优化器：智能体工作区和打分代码无隔离时，3 次实验 2 次出现智能体欺骗打分器。 Meta-Agent Challenge（2026）智能体设计调度框架：5 次实验发现智能体直接把测试答案写入调度代码。因此作者在每一轮设计都保留人工审核。 RRSI（2026）：基于基准测试调优的调度框架，基准得分 92.8，但同类型未见过任务仅 40.3。在评估集上调优，得到的指标只代表这个评估集本身。
经过验证有效的防御方案（本案例设计全部满足）
-
业务规则写在工具内部，智能体无法靠话术绕过退款上限等约束 -
每次运行重建干净数据库，任务之间数据不持久 -
打分器在智能体进程外部，执行结束读取数据库与轨迹；智能体看不到标准答案、打分代码 -
模型裁判使用不同模型，并且输入状态差异；Level4 证明即便如此裁判依然会被话术误导，因此标准答案仍是最后防线。
代码智能体等价方案：测试套件对智能体不可见，任务完成后才运行。快速自检：智能体凭借现有工具，是否可以在不完成真实任务前提下，让打分器判定通过？如果答案是肯定，长期一定会出现作弊。
核心结论：只要智能体可以触碰打分逻辑，最终就会找到办法在不完成任务前提下拿到高分。校验隔离后作弊率从 28.57% 下降至 0.56%。 落地建议：打分器读取的状态，由智能体不可编辑的代码写入；打分器在智能体外部、任务结束后执行；评估用测试集对智能体不可见。每次新增工具，重新检查这三点。 风险：所有调优循环（包括提示词优化）本质都是针对评估指标优化。评估体系本身必须能抵御这种优化。
Level7 要点总结 奖励黑客现象实测存在：打分可被触碰时，高达 1/4 “成功” 案例属于作弊；隔离校验后低于 1%。 三个核心保障：规则内置工具、每次干净环境重建、打分器独立于智能体进程。 在调优所用基准上测出的高分，只能代表该基准，不能代表真实场景。
Level8：搭建每日自动化评估流程
本章节回答：一次性评估如何转变为常态化机制，在客户遇到问题前捕获回归缺陷。
评估流水线每次修改提示词、工具、底层模型、调度框架，都完整跑一遍任务集，每个任务多次重复；输出统一报告：按类别 pass@k /pass^k 与置信区间、首个错误步骤统计、单次成功成本、裁判一致性。只要任意门禁不达标，禁止上线。
合理门禁阈值
-
各类别 pass^k 不低于阈值（略低于上一版合格结果，扣除区间宽度）。案例基线：拒绝任务 1.00，常规操作 0.73。 -
策略任务禁止工具调用尝试保持为 0。 -
各类别单次成功成本不超过上限。 -
模型裁判与代码打分一致性高于阈值；否则裁判结果不计入门禁。 -
空智能体依然全部无法通过操作类任务；所有任务干净环境可解。任务文件修改后，重跑这两项校验。
基于真实流量扩充任务集20 条人工任务只是起点。Anthropic 评估指南建议从真实故障提取 20–50 个任务；报告指出仅修复打分逻辑，CORE-Bench 指标从 42% 提升至 95%。扩充任务集前先修复打分器。 循环流程：采样生产轨迹，人工标注故障，转为带预期终态的评估任务，持续复测。
模拟客户部分任务需要多轮对话交互。案例挑选 6 条需要追问的任务，第二个模型扮演客户（隐藏事实清单）。pass@3=0.83，pass^3=0.67。智能体平均每回合仅 0.11 次主动提问，倾向直接从订单列表推断歧义。是否主动提问，也是一项需要评估的行为指标。
真实会话作为最终校验上线后，小流量灰度新版本（金丝雀发布），基于状态打分评估。SWE-chat（2026）6000 条真实代码智能体会话，两个关键指标：智能体修改最终保留到会话结束比例（44.3%）；用户提出异议比例（44%）。这两个指标来自真实业务，不是测试集。
每回合必须记录日志字段任务 ID、重复轮次；提示词版本、工具版本；每一次工具调用参数、返回、耗时；模型推理内容；最终回复；数据库前后快照与差异；分项打分；模型裁判结论与理由。缺少这些，Level3 故障根因分析无法事后开展。
结论：智能体评估是一套持续产出报告的机制，不是一次性带日期的数字。 落地建议：门禁监控：分品类可靠性、禁止动作次数、单次成功成本、裁判一致性；从真实故障扩充任务；任务文件变更时重做空智能体、可解性校验。 参考 Anthropic：仅修复打分逻辑，CORE-Bench 提升 53 分。先校验打分器正确性，再扩充任务。
Level8 要点总结 门禁监控：分品类可靠性、禁止调用尝试、单次成功成本、裁判一致性；每次评估比对报告差异。 从真实故障扩充任务，起步 20–50 条；新增任务前先验证打分器。 完整保存轨迹 + 状态差异；否则后续故障分析无法开展。
工具与框架、公开基准解读
打分器与评估方法
- 状态 + 路径代码打分器（本文案例）
优点：精确、低成本，智能体无法篡改；校验终态、必需 / 禁止工具、步骤预算、回复关键词。 局限：只看终态 + 路径，无法评估纯 “不修改数据” 任务，必须搭配路径校验；质量上限取决于标准答案质量。 - pass@k / pass^k（Sierra、τ-bench）
优点：同一批多次运行同时产出能力、可靠性指标，k≤n 时精确计算。 局限：最少 3 次测试，推荐 5 次；置信区间重采样任务，不是回合。 - 空智能体 + 任务可解性审计（ABC 清单）
优点：几分钟检出失效打分器、不可解任务。 局限：任务变更后必须重跑；空智能体无法单独检出不可解任务。 - 首个错误步骤标注（MAST、τ-bench、MP-Bench）
优点：故障排序，指导优先级修复。 局限：专家对根因一致率仅 16.2%；尽量精简故障类别。 - 带状态证据的模型裁判（Agent-as-a-Judge，GAUGE）
优点：评估语气、推理质量、无明确书面终态的任务。 局限：高估成功率、过度归罪模型、偏向同源模型；每次必须上报和代码打分器的 κ 系数。
开源框架
-
Inspect AI（英国 AI 安全研究所，开源）：沙盒智能体、工具调用求解、轨迹日志查看；轨迹打分需要自行编写。 -
promptfoo（开源 Node.js）：原生支持轨迹断言：工具调用、参数匹配、调用顺序、步骤上限；默认只校验轨迹，状态校验需要额外开发。 -
LangSmith（托管 / 自托管）：生产轨迹采集，真实轨迹转评估任务；打分逻辑自定义。
公开基准：如何解读排行榜数字
排行榜指标可信度取决于三个维度：打分方式（最终文本 / 终态 / 隐藏测试）、重复策略（单次 or pass^k）、领域和你的业务相似度。没有任何基准数字，可以直接迁移到你的业务任务。
-
τ-bench / τ²-bench（Sierra）：状态打分、策略遵循、pass^k，115 零售 + 50 航空任务；客服智能体最接近的公开基准。注意：空智能体依然可以通过航空任务 38%。 -
Terminal-Bench 2.0（斯坦福）：容器任务，终态测试打分，每个任务 5 次运行，带区间、任务成本。注意：单个任务最高消耗上亿 token。 -
SWE-bench Verified（OpenAI）：人工筛选真实 issue，隐藏测试打分。ABC 审计发现：5.2% 任务无需修复即可通过；抽样 50 例中 24% 人工复核存在问题。 -
GAIA, WebArena, OSWorld（Meta、CMU、HKU）：展示人机差距；人类 70%+，智能体普遍低于 16%。注意：字符串匹配 / 环境脚本打分；Chrome 版本变更，OSWorld 分数波动 28 分。 -
BrowseComp（OpenAI）：1266 条高难度可核验网页检索问题。注意：模型自信度远高于真实准确率；模型自信不能当作证据。 -
ABC 清单：审计任意基准（公开或自建），校验任务有效性、结果有效性。10 个审计基准 7 个存在打分缺陷；案例中检出 2/20 不可解任务。
决策速查清单
✅ 智能体完成任务了吗？状态校验 + 必需 / 禁止工具 + 步骤预算；校验空智能体失败、干净环境任务可解。 ✅ 下次还能成功吗？pass^k，k=3~5，按类别、任务聚类置信区间；改写话术测试，指标落在同一区间。 ✅ 本次回合为什么失败？从保存轨迹找到首个错误步骤，归类；最高频一类解释大部分故障，优先修复。 ✅ 回复质量好不好？裁判输入轨迹 + 状态差异 + 标准答案；κ>0.6，禁止同源模型裁判。 ✅ 成本是否划算？按类别统计 token、耗时、单次成功成本；查看任务最大最小成本比；维持同等 token 单智能体基线。 ✅ 流水线哪一环丢分？保存每一步转交摘要，端到端状态打分；归因：转交损失 / 执行器错误 / 打分器错误，仅靠轨迹判断，不听智能体自述。 ✅ 智能体会不会欺骗评估？三项检查：打分状态智能体不可修改；打分器独立进程、任务结束后运行；评估测试集智能体不可见；抽样人工复核作弊率。 ✅ 是否可以正式开放操作权限？策略任务禁止违规尝试 = 0；灰度真实流量，状态打分监控；真实会话跟踪变更留存率、用户异议率。
15 条要点总结
-
智能体错误体现在：话术、动作、动作顺序、动作数量、数据库留存状态；五项评估，话术放最后。 -
仅回复打分器 60 轮 58 通过；空智能体所有任务全部通过。打分器必须做空智能体测试。 -
每个任务在干净初始环境校验可解。案例 20 个任务里 2 个任何智能体都无法完成；单纯通过率无法发现。 -
同一批测试产出能力 pass@k、可靠性 pass^k，使用重采样任务置信区间。两者差距就是客户真实体验。 -
3 次重复是最低下限，推荐 5 次。 -
指标必须按任务类别拆分。案例整体可靠性 0.75，拒绝任务 1.00，转人工任务 0。 -
除随机种子外，改写输入文本测试；近半数语义等价改写会改变代码模型输出结果。 -
每次失败回溯首个错误步骤，归类统计。案例所有真实故障：执行动作前提前回复。 -
持续统计：步骤数、工具错误、违规修改尝试、空查询；这些指标提前于通过率发生变化。 -
裁判输出完全取决于输入证据。仅看轨迹裁判 κ=-0.24；增加数据库差异消除假阴性，但无法识别全部遗漏动作。 -
裁判倾向高估成功率、过度归罪模型；规则校验低估成功。两者同时上报；禁止智能体自身模型裁判自己。 -
核算成功案例成本，不是全部回合成本；按类别统计单次成功成本。实测同任务成本差距最高 30 倍。 -
智能体转交是有损通道：自然语言每轮损失约 8.5 个点；结构化摘要 2.8 个点。维持同等 token 单智能体基线。 -
只要打分器可被智能体触碰，最终会找到办法不完成任务拿到高分。三项保障：规则内嵌工具、每次干净环境、打分器独立进程。 -
评估是常态化报告机制；门禁监控分品类 pass^k、零违规尝试、单次成功成本、裁判一致性；从真实故障扩充任务集。