评估一个模型：给输入，比对输出，算分。评估一个 agent：上面每一步都不成立。四个差异，每一个都独立地增加了难度：
① 没有唯一正确的过程。同一个任务，agent 可以先查 A 再查 B，也可以反过来，两条路都对。评估不能比对固定答案，必须能容纳多种合理路径。
② 状态会被改变。agent 会调用工具，工具会写数据、发消息、改状态。这意味着评估不可重复——第二次跑的初始状态已经不同了。必须构造可重置的沙箱环境，而这本身就是不小的工程量。
③ 部分正确很常见。「完成了 8 步中的 6 步」该算多少分？二元的成功/失败会丢掉大量信息，而设计部分分数又极易主观。
④ 随机性被链条放大。这是最要命的一条。模型本身的输出就有随机性，而 agent 要连续做十几个决策——同一个任务跑两次，可能一次成功一次失败。跑一遍得到的分数几乎没有意义。
第④条有一个直接后果，值得单独强调：用「跑一次的成功率」评估 agent，会系统性地高估它的可靠性。
假设某任务 agent 有 70% 的概率成功。跑一次，你有 70% 的概率看到成功，于是记录「这个任务通过了」。但对用户来说，真实体验是每三次就有一次失败——而这在你的评估报告里完全看不见。
为什么一致性比平均成功率更重要？因为用户不会平均地体验你的系统。一个「大部分时候能用，偶尔莫名其妙失败」的 agent，在用户心中的评价接近于「不可靠」，而不是「70 分」。尤其当 agent 被嵌入自动化流程时，不一致意味着无法信任、必须人工复核，那么自动化的价值就所剩无几了。
轨迹评估里最有信息量的几个自动化指标（不需要人工标注就能算）：步数分布（比最优路径多走了几步）、工具调用失败率（按工具分开统计，能直接定位是哪个 schema 有问题）、重复动作率（检测绕圈）、触发终止条件的比例（撞上最大轮数说明任务超出能力）。这几个数几乎零成本，却能覆盖大部分诊断需求。
Yao、Shinn 等人构建的 τ-bench 模拟了真实业务场景中的三方交互：一个用户（由语言模型模拟）、一个配备领域 API 工具的 agent、以及一套必须遵守的领域政策规则。这个设定比传统的静态问答基准更接近生产环境——agent 不仅要完成任务，还要在与用户的多轮交互中遵守业务规则。
论文的核心贡献之一是提出了 passk 指标：评估 agent 行为在多次试验中的可靠性。测量结果相当清醒：
pass8 低于 25% 意味着什么：即使任务本身的单次成功率还过得去，让 agent 把同一件事连做 8 次都做对，成功概率不足四分之一。对于任何要放进自动化流程的应用，这个数字比「单次成功率」更能说明它能不能用。
这项工作对工程实践的三条启示：
① 评估 agent 必须重复多次跑同一个任务，报告一致性而非单次结果。只跑一遍的评估报告应当被视为不完整。
② 规则遵循是一个独立的失败维度。agent 可能「完成了任务但违反了政策」——比如成功改了订单，却跳过了必需的身份验证步骤。这在只看任务完成率的评估里是隐形的，必须单独设指标。
③ 用户交互本身是评估的一部分。真实场景中用户不会一次说清需求，agent 需要追问、澄清、处理反悔。用「一句话完整需求」构造的评估集会大幅高估真实表现。
条件：上述数字为该论文发布时（2024）对当时模型的测量，具体数值必然随模型演进而变化。可迁移的不是数字，是 passk 这个衡量方式——以及「先进模型在真实业务任务上的一致性，远低于单次基准分数所暗示的水平」这一判断。
阶段一 · 人工体验（前 3 个月）。团队靠手动试用判断质量：改完 prompt，试十几个问题，感觉变好了就发布。问题很快暴露——改动 A 修好了一类问题却弄坏了另一类，而没人发现，因为没人会去重试那些「本来就好的」用例。回归退化完全不可见。
阶段二 · 固定用例集（第 4–6 个月）。整理出约 80 个任务用例，每次发布前跑一遍，人工看结果。改善明显，但暴露了两个新问题：① 同一个用例两次跑的结果可能不同，人工判断「这算通过吗」摇摆不定，评估结论不稳定；② 知道「第 37 号用例失败了」，但不知道为什么失败——是工具选错、参数错、还是最后总结时出的问题？每次排查都要人工翻日志。
阶段三 · 分层 + 重复（第 7 个月起）。三项改造把评估变成了可自动化的门禁：
最有价值的一项改造是「可重置的沙箱」——它看起来只是基础设施，实际上是整个体系的前提：没有它，就无法重复执行；无法重复执行，就测不出一致性；测不出一致性，passk 无从谈起。团队一开始把它排在优先级末尾，事后看这是最该先做的一件事。
第二有价值的是失败自动归类。四类失败对应四种完全不同的修复动作：工具选择错 → 改 schema 描述（4.1）；参数错 → 改成枚举或加约束；执行错 → 工具本身或外部系统的问题；总结错 → 改最后一步的 prompt。有了归类，优化不再靠猜；而归类本身可以从轨迹日志自动算出来，几乎零成本。
结果：评估从「发布前一天的人工体验」变成了「每次提交自动运行的门禁」，并且当指标下降时能直接指出是哪一类退化。回过头看，前两个阶段并不是浪费——没有阶段二积累的用例，阶段三无从谈起。但如果重来一次，团队会把沙箱建设提前到第一个月。
公开基准：τ-bench / τ²-bench（工具-用户-政策交互）、SWE-bench（真实代码仓库上的问题修复）、WebArena（网页环境操作）等。它们适合横向比较模型的 agent 能力，但对你自己的系统调优参考有限——你的工具集、领域和约束都不同。公开基准选模型，自建用例集调系统。
可观测性平台：LangSmith、Langfuse、Braintrust、Arize Phoenix 等提供轨迹记录、回放与评估编排。核心价值是把轨迹结构化存下来——这是所有轨迹分析的前提。自建也不难，关键是从第一天就记全（4.2）。
沙箱环境是最该自建的部分：把 agent 用到的工具接上可重置的模拟实现（内存数据库、mock 的外部 API），保证每次执行从相同初始状态开始。这决定了你能否重复执行，进而决定能否测一致性，几乎没有现成方案可用，但投入回报极高。
LLM-as-judge 要慎用于轨迹：让模型判断「这个轨迹合理吗」比判断「这个答案对吗」更不可靠——轨迹更长、评判标准更主观。优先使用可程序化判定的指标（步数、工具失败率、重复动作、终止原因），把 LLM 评委留给确实需要语义判断的少数环节，并且必须与人工标注校准（6.4）。
问题一：不可逆操作缺少人工确认。「发退款」和「发通知邮件」都是不可撤销且面向真实用户的动作。让 agent 自主决定执行，意味着一次误判就会造成真实的资金损失或错误通知。修法：不可逆操作必须与只读操作分离——agent 可以自由调用查询类工具，但涉及资金和对外通信的动作应产出一个待确认的操作提案，由人工或强规则校验后执行（4.1 的信任边界）。
问题二：终止条件是「agent 认为完成」。这不是终止条件，这是没有终止条件。缺少最大轮数、死循环检测、预算上限（4.2）。生产环境中这会表现为个别请求消耗掉不成比例的资源，或反复调用同一个工具。修法：补齐四道闸门，并在触发时给出「做到哪一步、卡在哪里」的结构化报告。
问题三：评估方式完全不足。这一项有多重缺陷——① 只看结果不看轨迹，失败了不知道是选错工具还是参数错；② 每次跑一遍，测不出一致性，而 τ-bench 一类工作表明 agent 的不一致性正是主要风险；③ 每周抽样意味着一次退化最多可能上线七天；④ 抽样样本每周变化，跨版本不可比；⑤ 人工打分无一致性校验。修法：建固定用例集 + 可重置沙箱 + 每个用例重复执行报告 passk + 失败自动归类 + 接入发布门禁。
问题四（加分项）：「自主规划」用错了地方。订单处理的流程其实是相对确定的——查订单、判断是否符合退款条件、改地址或退款、通知。这更适合用代码编排，只在需要判断的环节调用模型（4.2）。让 agent 每次重新规划一个已知流程，是用不确定性替换确定性，同时放大了前三个问题。
问题五（加分项）：缺少规则遵循的独立评估。业务上很可能存在「退款前必须核验身份」「超过某金额必须走审批」这类政策。agent 可能完成了任务但违反了政策，而任务完成率指标看不见这一点——需要单独的合规检查项。
当前 pass10 = 0.8510 ≈ 0.197，即约 20%——十次连做全对的概率只有五分之一。
目标所需：p10 ≥ 0.9 ⟹ p ≥ 0.90.1 ≈ 98.95%。
从 85% 提到 99% 是极其困难的——这通常不是调调 prompt 能达到的量级，而且越接近 100% 边际成本越高。所以这道题的正确答案不是「去提高成功率」，而是质疑需求本身：
① 真的需要连续 10 次全对吗？如果每次任务是独立的，用户关心的是单次体验，那么 85% 的单次成功率配合良好的失败处理（明确告知失败、保留现场、一键转人工）可能完全可接受。「连续 10 次」这个指标要成立，通常意味着这些任务在业务上是链式依赖的。
② 如果确实是链式依赖，正确做法是打断链条：在关键节点插入校验与人工确认，把「10 步全自动」改成「10 步中有 2 个确认点」。每个确认点都把失败概率的连乘重置了一次，这比提升单步成功率有效得多。
③ 或者让失败可检测、可重试：若单步失败能被自动检测并重试，有效成功率从 0.85 升到 1−0.152 ≈ 0.978，pass10 随之升到约 80%。前提是失败必须可检测——这再次说明工具应返回可校验的结构化结果。
本题的核心判断：面对 pn 的乘法困境，「缩短链条」和「加入检验点」几乎总是优于「提升单步质量」——与 4.2 的估算题是同一个结论。
四个结构性差异，逐条说清即可：
① 过程不唯一。模型评估比对固定答案；agent 完成同一任务可以有多条合理路径，无法用唯一标准答案判定。
② 有状态且不可重复。agent 调用工具会改变外部状态，第二次执行的初始条件已经不同。必须构建可重置的沙箱环境才能重复评估——这是一项常被低估的基础设施投入。
③ 随机性被链条放大。模型单次输出的随机性，经过十几步决策会被显著放大，导致同一任务多次执行结果不同。因此单次成功率会系统性高估可靠性，需要用 passk 这类一致性指标。
④ 失败需要归因。模型答错就是答错；agent 失败可能出在工具选择、参数构造、工具执行、结果理解、最终总结等任何环节，每个环节的修复手段完全不同。只有结果指标是不可行动的，必须配合轨迹评估。
加分：主动提到还有一个正交维度——规则遵循。agent 可能成功完成任务却违反了业务政策（跳过身份验证、超额未审批），这在任务完成率里是隐形的，需要独立指标。以及给出务实的落地方案：结果评估全量自动化作为门禁，轨迹评估抽样做诊断，失败按类型自动归类。