ARTICLE · 1087591
AI Agent 到底靠不靠谱:从成功率、自动评分到失败复盘
让 Agent 把一张图片里的开销录入记账软件。它打开图库、找到图片、填写金额、点击保存，最后回复：“已完成。”
如果只看操作是否报错，这次任务似乎很顺利。但打开账本，里面的金额和图片根本对不上。
李博杰《AI Agents in Depth》的第七章记录了这样一条 AndroidWorld 实验轨迹：Agent 执行了 32 步，没有工具报错，却填入了自己编造的开销。回看记录才能发现，它在开始填数之前就已经出了问题。
Agent 可以调用工具、使用软件，也可以连续工作很久。接下来，开发者需要回答更具体的问题：换一个模型有没有用？多加一段提示词有没有帮助？任务失败，是模型判断错了，还是系统没有把必要信息交给它？
这一章讨论的评估，就是为这些选择提供证据。我们沿着一条任务的生命周期，把成功标准、运行环境、评分、失败复盘和后续改进连起来。
一、从一条任务开始：什么才算做成了
客服说“修好了”，还需要检查什么？
先看原章拆解的 τ²-bench 电信客服任务。用户人在国外，手机无法上网。运营商后台已经开通漫游，但用户手机仍开着飞行模式，设备上的数据漫游也没打开。
Agent 能查运营商后台，却不能替用户按手机上的开关。它需要询问情况，引导用户检查设置，等用户操作完，再确认网络是否恢复。
这里有两套操作权限：Agent 管运营商侧，用户管设备侧。τ²-bench 把这种双方都能改变环境的设计称为“双控环境”。模拟用户也有工具，可以查状态、关飞行模式、跑测速；它的回答要依据工具结果。τ²-bench 论文
这样，“用户说好了”才有实际状态作为依据。如果模拟用户只负责顺着 Agent 的话往下聊，两个模型很容易互相确认成功，手机实际上还不能上网。
结果、过程、告知，是不同的检查项
这条任务至少有几种值得检查的事实：网络是否恢复、必要的设备操作是否发生、Agent 有没有违反业务规则，以及最后告诉用户的话是否准确。
它们不一定同时进入总分。原章那条成功轨迹的奖励主要由环境终态决定；虽然网络恢复了，轨迹中仍出现了不符合该任务工具调用规则的行为。
分数的含义取决于验证器检查了什么。
把它换成记账任务就更直观：保存按钮点成功，是动作执行成功；账本里有记录，是写入成功；金额、币种和项目都对应原图，才是数据正确。最后的“已完成”还得与实际完成范围一致。
因此，一条评估用例通常要写清四件事：给 Agent 什么请求，任务从什么状态开始，交互对象知道什么，以及怎样判定成功。题目文本只占其中一部分。
二、成功率：做对一次，与反复做对
Pass@k：给几次机会，至少成功一次
假设某个任务允许尝试五次，只要其中一次通过就算成功，这就是 Pass@5。一般写作 Pass@k，k 是尝试次数。
它适合衡量探索能力。例如生成几个候选程序，再用测试挑出能运行的那个。只要可以可靠地识别成功结果，多尝试几次就可能有价值。
但这个指标本身没有回答：失败的尝试花了多少钱，正确结果怎样被挑出来，以及挑选过程会不会出错。公开评估可以用已知答案验收，真实产品未必拥有同样强的验证条件。
Pass^k：几次尝试全部成功
τ-bench 提出的 Pass^k 关注重复运行的一致性：同一任务运行 k 次，要求每次都成功。τ-bench 论文
用一个纯数学假设来看区别。设单次成功概率为 80%，每次运行互相独立，成功概率保持不变，那么：
五次里至少成功一次： 1 − (1 − 0.8)^5 = 99.968%。五次全部成功： 0.8^5 = 32.768%。
同一个系统，换一个问题，数字会差很多。前者支持“给足机会能做成”，后者更接近“重复交付是否可靠”。
这些公式描述的是同一任务、独立同分布尝试的理想情况。真实任务有难有易，也可能共享故障；把整套题的平均成功率直接取五次方，通常得不到整套题的 Pass^5。
评估时更直接的做法，是逐题重复运行，再按既定规则汇总。会改变数据库、扣减余额或发送通知的任务，还需要在每次试验前恢复初始状态，否则第二次已经不是同一道题。
三、评估环境：让两次运行可以比较
一套环境怎样组成
原章把评估环境拆成五部分：任务数据集、环境状态、工具接口、评分标准和执行协议。
仍以电信客服为例。数据集给出用户问题；环境状态保存账户配置和设备开关；工具提供查询与修改操作；评分标准检查网络状态等结果；执行协议规定什么时候轮到谁说话、最多运行多少轮，以及何时结束。
如果要比较两个模型，它们就需要从相同状态开始。模型 A 开始时飞行模式是开的，模型 B 接手时却已经关了，后面的成功率没有可比性。
执行预算同样属于实验条件。给一个模型十轮、另一个模型一百轮，得到的结果同时包含了模型差异和预算差异。
有些任务需要用户，有些只需要工具
客服任务要考查澄清需求和引导用户，所以需要模拟用户。代码修复则可以从一个固定版本的仓库开始，让 Agent 修改文件，再运行测试。
模拟用户会增加一层不确定性：它是否提前透露答案，是否误读工具结果，是否接受了没有证据的完成声明。用户模拟器本身也需要抽查。
工具的粒度还会改变题目的难度。若只提供“查询账户”“检查设备”这样的操作，Agent 需要自己排查；若提供一个“自动解决上网问题”的工具，许多推理工作已经由工具完成了。
所以，评估测到的是模型与运行系统的组合。这里的运行系统常被称为 Harness，包括提示词、上下文组织、工具、调度和反馈机制。它决定模型能看到什么、能做什么，以及做完后收到什么结果。
四、评估集：题目从哪里来，答案怎样验
公开基准提供不同的检查方式
SWE-bench 把真实代码仓库的问题交给模型，通过执行测试评估补丁。AndroidWorld 在 Android 环境中操作应用，并检查任务完成后的状态。这些基准的价值，也在于展示“做成了”怎样落到可检查的事实。SWE-bench 说明；AndroidWorld 项目
代码修复通常需要两组测试：原本失败的测试现在通过，说明目标问题得到修复；原本通过的测试仍然通过，用来检查已有功能是否退化。测试覆盖以外的错误，仍可能漏掉。
同样，记账任务不能只检查“多了一条记录”，还要检查内容。验证器若只核对数量，填入任意金额也可能拿到分数。这类“提高分数却没有完成目标”的行为，就是奖励作弊可能利用的空隙。
自建业务集与线上失败各有用途
公开基准可以帮助粗筛模型，但你的用户可能天天修改表格，很少修复 Python 项目。真正决定上线效果的，还是业务中的任务分布。
自建评估集可以从高频请求开始，再加入容易弄错的情况。例如记账除了单张清晰票据，还可以包含多币种、重复项目、模糊图片和信息缺失。难度标签最好对应具体能力，方便看出问题集中在哪里。
上线以后，用户纠正、负面反馈和事后验收发现的失败，可以继续变成回归用例。不过，专门收集失败会让题目越来越难，因此“历史问题集”和“代表日常流量的业务集”最好分别报告。前者看老问题有没有复发，后者估计日常表现。
题目也会过时。应用升级、网页变化、验证脚本失效，都可能造成分数下降。参数化生成姓名、金额或目标对象，可以增加变化；保留未用于调试的测试集，可以减少对熟题的过度优化。两者都不能保证训练数据绝不泄漏，但能让评估更有区分度。
五、自动评分：程序能查的查事实，开放问题再请模型评审
Rubric 把“好不好”写成具体标准
文件是否存在、金额是否一致，可以交给程序。客服解释是否清楚、报告有没有漏掉重要条件，则往往需要结合语义判断。
LLM-as-a-Judge 就是让另一个模型担任评审。它需要一份 Rubric，也就是明确的评分标准，以及任务要求、实际输出和相关证据。
例如下面这份为记账示例设计的简化标准：
前两项中可以结构化比较的部分继续由程序检查；说明是否清楚、声明是否超出证据，再交给评审模型。虚构数据可以被设为否决项，不能靠“表达流畅”补回分数。
评审模型也会有偏好
模型可能偏爱长答案，也可能偏向排在前面的候选。关于 MT-Bench 和 Chatbot Arena 的研究专门分析过长度、位置等评判偏差。LLM-as-a-Judge 研究
常见处理方式是匿名展示候选、交换前后顺序再评，并要求评审引用具体证据。再拿一批人工判断过的样本做校准，检查它在哪些错误上经常漏判。
多个模型交叉评审能提供不同视角，但它们仍可能共享盲点。把几个分数取平均，不会自动变成正确答案。
同一方法还可以用于多模态内容：听语音的停顿和读音，看截图里的文字溢出，检查剪辑片段。前提是评审拿到了相应模态的证据。只给语音转写文本，就无法判断音色和韵律；只给“页面已生成”的描述，也无法检查实际布局。
失败归因：沿轨迹找出第一处偏离
评分以后，还要知道怎么改。这时需要回看轨迹：Agent 收到了哪些信息，调用了什么工具，工具返回什么，它随后怎样行动。
回到开头的记账案例。根据原章保存的运行记录，第 8 步时，Agent 已经表示自己看不到图片里的具体内容；到第 11 步，未经观察的开销数据却出现在了记录中。后面的输入和保存都能正常执行，但数据来源已经错了。
更具体的原因是，这个 T3A Agent 接收的是界面元素树，没有图像像素。打开图片并不意味着图像内容进入了模型的观察。下一步可修复的地方，是补充图像或 OCR 通道，并在缺少数据时停止猜填；单纯更换一个“更会识图”的模型，未必能改变它实际收到的输入。
这是原书对已有轨迹的分析，本文没有重新运行该实验。
归因记录最好能指向步骤和证据：“第 8 步缺少图片内容，随后仍继续填数”，比“模型不够聪明”更便于复测。不过，最早出现的异常也不必然是唯一根因；还需要检查它怎样影响后续决策，以及中途是否存在恢复机会。
精确编辑失败也适合这样查。工具说原文匹配不上，问题可能来自空格、转义、序列化或模型复制。沿着“文件内容 → 工具返回 → 模型上下文 → 调用参数 → 实际匹配”比较，才能知道首个差异出现在哪层。
两种回归：测完整任务，也测出错前那一步
修复以后，端到端回归会从最初请求重跑整个任务，检查最终结果。它覆盖完整流程，但运行成本可能很高。
轨迹前缀回归则把环境和上下文恢复到出错之前，只测试接下来的一步或几步。
对记账案例，可以固定“图片已经打开，但尚无可读取内容”的状态，检查 Agent 是否尝试获取图像、请求补充材料，或如实说明无法继续；直接编造金额属于禁止行为。通过局部检查后，再重跑完整录入流程。
这种方法也能检查文档编辑的作用域：用户要求调整中文引号时，正文可以修改，代码字符串和 JSON 语法仍需保持有效。局部决策测清楚了，再确认整篇文档没有被破坏。
配对比较：两个版本，谁更合适？
开放式任务有时很难给绝对分数，却容易判断两个结果中哪个更好。可以把同一个任务的 A、B 输出匿名交给评审，记录胜、负或平局。
Elo 和 Bradley–Terry 等方法可以把大量两两比较汇总成相对排名。但排名仍然取决于比较了哪些任务：编程题多，擅长编程的模型就可能更占优势。它适合回答给定任务分布中的相对偏好，不能替代具体业务的验收标准。
六、模型选型：把质量、时间和成本放在一起
首字快，整件事未必快
模型开始处理输入时，会读取上下文，这一阶段通常称为 Prefill；随后逐步生成输出，称为 Decode。
首个 token 的延迟会受排队、输入长度、缓存命中等因素影响。对推理模型来说，首个面向用户的可见内容，还可能要等内部推理完成。开始输出之后，工具调用和多轮执行又会继续增加等待时间。
因此，选择 Agent 模型时可以分别记录首个有效响应、整项任务完成时间，以及 p95 延迟。p95 表示约 95% 的观测耗时不超过这个值，比单看平均数更容易发现一部分用户遇到的长时间等待。
同样的模型，在不同预算下也可能表现不同。给两分钟和给半小时，能完成的任务范围未必相同。实际比较可以固定几个时间或 token 预算点，观察增加预算后，成功率是否还在上升。
每 token 便宜，未必每次交付便宜
Agent 的成本包含多轮模型调用、工具服务和运行环境。历史对话会再次进入后续请求，长工具结果也会继续占用输入；缓存和压缩会改变这部分费用。
一个便于业务比较的口径是：全部尝试的总成本 ÷ 成功交付数。失败消耗也包含在分子里，评估窗口和“成功”的定义保持一致。
假设 A 跑 100 项任务花 100 元，完成 80 项；B 花 60 元，完成 40 项。两者每次成功交付对应的成本分别是 1.25 元和 1.50 元。这只是算术示例，没有包含人工接管费用，也不是任何模型的实测价格。
模型默认的行动习惯也值得观察。有的先读较多资料，有的尽早操作、再根据反馈修正。读取次数少并不自动意味着高效，还得一起看是否漏掉需求、是否反复返工，以及最终结果。
路由到不同模型、压缩历史、启用缓存，都可以成为候选方案。它们合用的效果需要重新评估：压缩可能省下输入，也可能缩短可复用的缓存前缀，两项单独测出的节省比例不能直接相加。
七、分数涨了一点，怎样知道是不是波动
假设旧版本在 100 道题上做对 70 道，新版本做对 73 道。只看汇总表，新版本提高了三个百分点。
但这三个百分点还不够解释差异。是旧版本失败的题里修好了三道，其余完全相同？还是修好了二十道，又弄坏了十七道？两种情况的总分相同，影响面却很不一样。
因此，同一批题比较两个版本时，可以逐题记录四种结果：都成功、都失败、只有 A 成功、只有 B 成功。McNemar 检验关注两边不一致的题目；配对 bootstrap 则通过重复抽取任务对，估计差值的不确定范围。
原章给了一个粗略尺度：100 个独立样本、观测成功率 70%，正态近似下的 95% 置信区间约为 70% 上下九个百分点。这个区间针对单组比例；比较两个版本是否有差异，仍应使用逐题配对结果。
模型输出本身也会波动，所以每题可以重复运行。若同一道题的多次运行相关，统计时仍要保留任务这一层，不能把它们全部视为互不相关的新题。
对于涨幅很小的改动，扩大样本、独立复跑和保留未参与调试的测试集，比反复挑最好的一轮更能帮助决策。
八、可观测性：留下足够的信息，才能复盘
前面的分析都依赖运行记录。只保存用户问题和最终回复，很难知道图片有没有进入上下文，也看不到哪次工具调用返回了错误号码。
一次完整任务可以记为一条 Trace；其中的模型调用、检索、工具执行各自记为 Span。Span 保存起止时间、状态和关联信息，父子关系把它们连成一棵执行树。这是 OpenTelemetry 追踪模型中的基本组织方式。OpenTelemetry Traces
在 Agent 里，还可以关联模型版本、提示词版本、工具输入输出、token 用量以及最终验收结果。这样看到“任务慢”，才能继续分辨是模型生成慢、工具等待久，还是相同查询执行了太多次。
可观测性不要求取得模型未公开的内部思考。观察输入、可见输出和实际动作，已经能够定位许多问题。
运行记录也不等于所有内容都适合永久保存。用户文本、凭证和文件内容需要按用途筛选与脱敏，控制访问和保留期限。转成评估用例时，可以用合成身份替换个人信息，同时保留导致错误的关系与条件。
九、从报告到改进：一轮只验证一个解释
原章给出的 AndroidWorld Wi-Fi 调优案例，把评估怎样影响工程选择讲得很具体。实验只针对四项 Wi-Fi 设置任务，每轮做一次配对对照。
最初，Agent 经常在设置页面来回导航。第一种解释是“它不知道入口”，于是实验组增加导航提示。结果仍是四项里完成一项，提示词没有解决这个子集上的成功率问题。
接着检查输入，发现当前界面信息通道存在兼容问题。换成 UIAutomator 元素树后，四项全部完成，但 token 用量达到对照组的约 2.50 倍。
第三轮只精简元素树，去掉没有文字、不可操作且不可见的容器节点。四项仍全部完成，token 用量降到上一方案的约 0.506 倍。
这组结果支持一个有限但有用的判断：修复观察通道值得继续测试，精简输入可能减少开销。它没有证明整个 AndroidWorld 已经达到 100% 成功率。原章也把更大范围、多个随机种子的完整复测列为后续工作。
诊断时还需要先看评估环境是否正常。模拟器资源不足、网站不可用、验收脚本出错，都可能表现为失败。把这些故障单独记录，才能避免拿失真的分数去调 Agent。
十、把实验能力做进产品
模型替换、消融和 A/B 分别回答什么
固定 Harness，只换模型，可以观察结果对模型的敏感程度。固定模型，关闭记忆、压缩或某个检索组件，则是在做消融，检查这个组件在当前组合里有什么贡献。
更强模型没有提分，是继续调查 Harness 和任务条件的线索，不能仅凭这一点断言模型一定不是瓶颈。一个组件关掉后没有降分，也可能因为它的效果被其他组件替代了。
A/B 测试更接近线上：将可比较的用户或会话随机分到不同版本，观察实际完成率、接管率和等待时间。涉及跨会话记忆时，按用户保持分组通常更容易避免两个版本相互影响。
实验还要分清改了什么、真正想改善什么。比如缩短计划文本，直接改变的是计划长度，目标可能是降低整项任务的成本。如果计划变短，却增加了返工，总成本仍可能上升。任务成功率等不能恶化的指标，也应与成本一起观察。
开关和版本，让结果可以追溯
特性开关让功能能够独立启停，也便于逐步放量和回滚。编译期开关可以让相关代码不进入构建产物；运行期开关则在运行时选择路径。无论采用哪种方式，实验记录里都要能还原当时生效的组合。
提示词也属于这个版本组合。只保存模板不够：工具说明、记忆和条件分支展开之后，模型收到的最终文本可能不同。记录渲染结果或可复原的版本信息，才能把行为变化对应到具体改动。
这些工程能力让一次改动可以经历同一套流程：先通过相关回归，再扩大评估范围，进入小流量实验，最后决定是否推广。遇到退化，也能回到已知版本继续比较。
十一、评估环境怎样接到模型训练
任务能重置、动作能执行、结果能评分之后，环境也就具备了让 Agent 反复练习的条件。
如果验证器能检查程序是否通过测试，或目标状态是否达成，它的结果可以转换成训练奖励。开放式任务的 Rubric 和模型评审也能提供反馈，但其中的主观性和误判会随之进入训练信号。
训练需要比评估更高的运行吞吐、更可靠的重置，还要有足够多的任务变化。否则模型可能记住特定姓名、固定界面位置或验证器漏洞，分数提高了，换个场景又失效。
在数字环境中，可以变化输入数据、工具延迟和故障条件；在机器人仿真中，可以变化物体位置、光照和物理参数。变化范围需要贴近目标任务，并保留独立评估集，检查训练后的收益能否迁移。
再回到那张开销图片。一套有用的评估系统，会查出账本金额不对，沿轨迹发现模型没有拿到图片内容，把这个状态保存成回归用例。观察通道修好后，它还会检查完整录入流程是否成功，以及别的任务有没有退化。
到这时，“已完成”后面才有一条可以复查的证据链。
引用
李博杰：《AI Agents in Depth》第七章，Agent 的评估 Sierra：τ²-bench，双控环境中的对话 Agent 评估 Sierra：τ-bench，工具、Agent 与用户交互评估及 Pass^k SWE-bench：基准与执行评估说明 Google Research：AndroidWorld 项目 Zheng 等：Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena OpenTelemetry：Traces