AI Agent评估：每步95%准确率在20步任务中仅36%成功

引言：你的 Agent 跑通了——然后呢

你的 Agent 能正常工作。你跑了十五次，看它选对了工具，它也确实把事做成了。于是你把它发版上线。

三周后，它在相当一部分真实请求上悄无声息地失败了，而没有人能告诉你是哪次变更导致的——因为你的测试套件里从来就没有测过那个会崩的东西。

我也经历过这种事。我曾经搭过一个混合检索系统，关键词检索融合向量检索，我有测试，全部飘绿。但那些测试实际只断言了"检索返回了结果"，而不是"正确的结果排在了最前面"。所以当一个评分 bug 颠倒了排序，把较弱的匹配放到了较强的前面时，所有测试依然绿着。它上线了，在生产环境里躺了三周，直到我肉眼才发现问题。

那不是测试失败，是评估失败。我的测试证明了代码在跑，但没有任何东西证明输出有任何价值。

关键在于：这个差距在系统从一个 prompt 变成一个 Agent 时会急剧恶化。一个 prompt eval 评测的是一个输入对应一个输出。而一个 Agent 产生的是一条轨迹——模型轮次、工具调用、结果、对世界的变更——最终落脚在一个被修改过的环境，而不是一个字符串。你在 prompt eval 上建立的那套直觉，几乎没有几条能在这次转变后存活下来。

下面来拆解：什么变了，以及应该改测什么。

95% 单步准确率为何是不及格的分数

从第一性原理出发。如果一个 Agent 的每步成功独立概率为 p，那么完成一个 N 步任务意味着每一步都要做对：p^N。

这个指数是无情的。

看 95% 那行。五步是 77%。二十步，36%。五十步，7.7%。一个在 prompt eval 仪表盘上看起来很漂亮的数字，生产出来的系统失败率是三分之二。

现在把问题反过来看，因为这个版本会改变你构建系统的方式。要达到 90% 的端到端成功率，每步可靠性需要多少？10 步需要 98.95%。100 步需要 99.89%。

100 步是真实的吗？OSWorld 2.0，2026 年 6 月发布，构建了 108 个长时域 computer-use 工作流，人类完成的中位时间约 1.6 小时。其任务平均 318 次工具调用。在 500 步预算下，排行榜上最好的系统端到端完成任务的比例是 20.6%，部分完成得分 54.8%。

诚实面对局限：这是一个直觉泵，不是精确测量。真实步骤不独立，失败是相关的，因为一个糟糕的规划会毁掉之后的一切，而且 Agent 也会重试和自我修正，这使得真实表现会高于 p^N。

但方向是对的，方向才是关键：长时域可靠性不能从单步准确率外推，必须端到端测量。

评测结果，而非故事

那么你应该断言什么？

大多数工程师的本能——我也有过——是检查 Agent 是否按正确的顺序走了正确的步骤。Anthropic 的工程团队在《Demystifying evals for AI agents》中直接反驳了这一点：

"我们发现这种方法过于僵化，会导致测试过度脆弱，因为 Agent 经常会发现 eval 设计者未曾预料到的有效方法。为了不错罚创意，评测 Agent 的产出而非其走过的路径往往更好。"

他们关于机票预订的例子是我见过的对这个原则最清晰的阐述：Agent 可能在转录文本末尾写"您的机票已预订"，但结果是数据库环境里是否真的存在这条预订记录。

这不是假设。τ-bench 正是基于这个理念构建的——它"将对话结束时的数据库状态与标注的目标状态进行比较"。而 2026 年的一篇论文《From Confident Closing to Silent Failure》给出了具体数字，说明为何不能信任转录文本：在单控制 τ²-bench 领域中，Agent 声称成功而环境表示并非如此的失败占 45-48%，在 AppWorld 的自我评估 coding-agent 轨迹中占 75.8%。

这部分应该改变你的工具选择。同一篇论文测试了 LLM judge 在检测这些虚假成功上的表现。在 τ²-bench 上 judge 的 AUROC 从未超过 0.65，在 AppWorld 上更是只有 0.54。而一个简单的 TF-IDF 检测器分别达到了 0.83 和 0.95，延迟还低了 3300 倍。

在"Agent 实际上是否完成了"这个具体问题上，一个廉价的确定性检测器完胜了昂贵的语言模型。先用状态检查。

从实际角度出发，一个有用的 Agent 断言有五层：

def test_refund_task(agent, env, task):
    run = agent.run(task.instruction, tools=env.tools)

    # 1. OUTCOME - the environment must match the annotated goal state
    assert env.db_hash() == task.gold_db_hash

    # 2. REQUIRED ACTIONS - the side effect must actually have happened
    assert env.called("issue_refund", order_id="W123", amount=52.40)

    # 3. COMMUNICATION - required information reached the user
    assert "5 to 7 business days" in run.final_message

    # 4. FORBIDDEN ACTIONS - the negative case matters just as much
    assert not env.called("cancel_order")

    # 5. BUDGET - cost and latency are results, not footnotes
    assert run.n_turns <= 12
    assert run.cost_usd <= 0.35

第 4 条是人们最容易跳过的一条，也是我极力主张的一条。Anthropic 的指导很直接：测试"行为应该发生的情况和不应该发生的情况"，因为"单边评估造成单边优化"。一个从不拒绝任何事的 Agent 会在全由"应该做的事"组成的测试套件上拿满分。那不是有能力的 Agent，那是毫无防护的 Agent——而你构建的那个套件恰恰奖励了它。

几乎没人报告的可靠性指标

现在这个指标改变了我对发布 Agent 的看法。

大多数人都知道代码基准测试中的 pass@k：从 k 次尝试中，是否至少有一次成功？当你有一个人类在过滤输出时，比如给你审查建议的 coding 助手，这是正确的指标。

当 Agent 自主行动时，这恰恰是错误的指标。

τ-bench 为此引入了 pass^k：从 k 次尝试中，是否全部成功？这是你的 Agent 在同一个任务上每次客户问到时都能正确处理的概率。

差距是残酷的。以一个单次成功率为 70% 的 Agent 为例。跑三次：pass@3 约为 97%，而 pass^3 约为 34%。

发表的 τ-bench 数字在真实系统上呈现同样的形态。在零售领域，claude-3-5-sonnet 从 pass^1 的 0.692 跌到 pass^4 的 0.462。在航空领域，gpt-4o 从 0.420 跌到 0.200。论文摘要里说得很直白：最先进的函数调用 Agent"在不到 50% 的任务上成功，且相当不稳定（零售领域 pass^8 <25%）。"

有趣的是：实测的 pass^k 衰减比单纯将 pass^1 提升到 k 次方慢。以零售那行为例，0.692^4 应该是 0.229，但实测 pass^4 是 0.462——翻了一倍。这个差距意味着任务难度是异质的：有些任务 Agent 每次都能搞定，有些则永远搞不定。

这给了你一个免费的诊断工具。如果你的实测 pass^k 接近 (pass^1)^k，说明你的任务套件太均匀了，可能没有压力。

构建你的前 20 个任务

大多数团队没有 Agent eval，是因为他们想象的是一千个手工标注的案例，然后默默决定以后再做。所以让我用实际推荐的数字来打消这个顾虑。

Anthropic 的指导："从真实故障中抽取 20-50 个简单任务，是一个很好的起点。"

四条规则让这些任务值得拥有。

**1. 两位专家必须达成一致。**一个好的任务是两位领域专家会独立得出相同通过/失败判定的那种。如果你和同事可以争论某次运行是否通过，那这个任务就是定义不足的，会永远产生噪音。

**2. 不要先写评分标准。**这是反直觉的那条，来自 Shankar 等人的《Who Validates the Validators?》。他们命名了一种叫做标准漂移的现象："用户需要标准来评分输出，但评分输出有助于用户定义标准。"这是一个真正的鸡生蛋问题。有些标准只有在看到系统实际产出之前根本无法定义。所以先看真实的轨迹，再根据故障写评分标准。

**3. 审查足够多的轨迹以达到饱和。**Hamel Husain 的 evals FAQ 给出了一个干净的启发式方法："你应该以审查至少 100 条轨迹为目标"，"如果大约 20 条轨迹都没有发现新类别，就可以停了。"把发现的东西归类为几个命名的故障模式，然后数它们。数出来的数字告诉你该修什么，故障模式告诉你该测什么。

**4. 判定要是二元的。**不是 1-5 分。"二元评估强制更清晰的思考和更一致的标注。"1-5 量表会让标注者把所有东西都停在 3 分，没有人能告诉你 3 和 4 的区别是什么。

一个数字供参考投入程度：Husain 报告把 60-80% 的开发时间花在错误分析和评估上。这听起来很夸张，直到你记住替代方案是什么——就是我那个检索 bug 做的事：上线一个静默回归，三周后意外发现。

问自己：你愿意拿什么打赌

每个现在正在构建 Agent 的工程师都在做一个隐含的声明：看一个系统跑十几回就知道它在生产跑一千回会如何。复合数学说这个声明是错的，而且说得是定量的。

这件事值得投入的原因不是仪表盘。评估是唯一能把"我觉得它变好了"转换成"它变好了，而且有数字为证"的东西。非确定性软件不像编译器那样免费给你那个结论。你得自己造那个仪器。

所以这周就开始，从小处做起。从日志里拉二十个真实故障。为每个写出结果断言——端状态，不是转录文本。跑三次，看 pass^3，不是 pass@3。这是一个周末的工作量，但它告诉你的会比你跑过的每个 demo 都多。

第二部分涵盖代码断言够不到的地方：构建一个不会骗自己的 LLM judge、不靠盲调评估 RAG、2026 年哪些框架值得用，以及如何把它们接进 CI gate。详见：Building an Eval Stack That Catches Regressions (Part 2 of 2)。

评测结果，否则你只是在看 demo。

常见问题

我需要评估框架才能开始吗？

不需要，一开始就用框架往往是错误。你的第一个 Agent eval 可以是普通的 pytest，加上上面的五条断言。框架在你需要数据集管理、judge 对齐或共享仪表盘时才值得引入——第二部分会讲哪些值得用。

我可以直接用公共基准测试如 τ-bench 或 SWE-bench 吗？

用它们淘汰弱模型，而不是用来选择你的系统。公共基准测试已被污染且经常有 bug——2025 年对十个主要 Agent 基准测试的审计（ABC 检查表论文）发现了会使报告性能"相对变化高达 100%"的缺陷，包括 τ-bench 将空响应计为成功。你自己的 20 个任务比任何排行榜都有价值。

对真实系统跑 Agent eval 安全吗？

把 eval 环境当作一个行为不端的 Agent 会造成真实损害的地方，因为那正是你在测试的。用带有种子数据的沙盒副本跑，绝不用真实凭证或生产数据库。而且要包含正确结果是 Agent 拒绝并上报的任务——那是断言 4 的负面情况，能捕捉到一个愿意发出不该发的退款的 Agent。

我应该多久重做一次错误分析？

任何实质性变化发生时：模型升级、prompt 重写、新工具、事故或投诉飙升。在这些之间，每周过一遍 10-20 条轨迹能让你保持诚实，不会蚕食整个 sprint。

我的 Agent 所有测试都通过了。这很好吗？

这意味着你的套件太简单了。100% 通过率不携带任何关于系统脆弱点在哪里的信息。去找到二十个更难的故障，加上它们。

P.S. 如果你想要关于这个主题的最好的一手资料，阅读 Anthropic 的《Demystifying evals for AI agents》——这是该话题上最密集的实践指南。

最初发表于 blog.stratoslouvaris.gr。

我写关于在生产环境中构建有效的 AI Agent 以及沿途会坏掉的东西。欢迎订阅 newsletter 或在 LinkedIn 上找我。