用 pass^k 指标衡量 Agent 真实可靠性

# 上线前将你的 Agent 跑 8 次

# 我发现自己那个"准确率 90%"的 Agent 实际只有 30% 左右。以下是揭露这一问题的指标。

> 简而言之：你 Agent 的成功率是个谎言，因为你只测量了一次。τ-bench 的 pass^k 指标衡量的是它在全部 k 次尝试中是否每次都成功，而这个数字的下跌触目惊心。GPT-4o：单次尝试 61%，八次全部通过则不到 25%。我在自己的 Agent 上跑了同样的测试，结果改变了我的上线决策。工具和命令在文末。

我有一个支持分类 Agent，我一直把它的准确率说成 90%。四十二张测试工单，三十八张处理正确。我把这个数字写进了 PPT，还在会议上大声念了出来。

后来我读了 τ-bench 的论文，重写了那份 PPT。

让我触动最深的是这个：τ-bench 引入了一个叫做 pass^k 的指标。注意，不是 pass@k——大多数代码基准测试用的那个，问的是"在 k 次尝试中至少成功一次了吗？"那是一个乐观的指标，非常适合代码生成，因为你可以跑测试、挑选结果。

pass^k 问的是反向问题：它是否在 k 次尝试中每一次都成功了？

对于任何涉及客户或数据库的场景，这才是唯一重要的问题。你没机会把退款流程跑八遍，然后只保留成功的那次。

原论文的数据如下：

模型 pass^1（零售） pass^8（零售）     GPT-4o 61% 不到 25%   Claude 3.5 Sonnet（2024 年 10 月） 69.2% —   GPT-4o（航空） 42.0% —

来源：τ-bench，Yao 等人。原始排行榜冻结于 2024 年末的模型；最新进展在 tau2-bench 上。(https://arxiv.org/pdf/2406.12045) (https://github.com/sierra-research/tau2-bench)

一个看上去三次中能成功两次的模型，当你要求它保持一致性时，通过率会跌破四分之一。而且不只是客服场景。CORE-Bench 发现他们的 Agent 在困难任务上 pass^1 为 22.2%，到 pass^3 时已跌至 8.9%。到处都是这种形态。

> 没有谁的 Agent 和演示一样好。不是因为他们在撒谎，而是因为他们只跑了一次。

## 于是我把自己的 Agent 跑了八次

还是同样的四十二张工单，每张跑八次。然后我只统计全部八次都处理正确的工单。

<!-- REPLACE THESE WITH YOUR OWN RUN — do not publish my numbers -->    指标 结果     pass^1（我一直在汇报的数字） 90%   pass^3 61%   pass^8 33%

百分之三十三。这才是真实的数字。

而且衰减的形态比数值本身告诉了我更多。失败并不是均匀分布在四十二张工单上的，而是集中在一起：十一张工单几乎每次都失败，其余的则基本稳定。这与"模型不稳定"是完全不同的工程问题，而从单次运行中我根本看不出这一点。

如果你只能带走一件事，我最想强调这一点：读曲线，不要只看数值。如果你的 pass^k 缓慢衰减，说明你有一个全局性的一致性问题，修复方向可能是调整 temperature、提示词或模型选择。如果它骤然下跌，说明你有一个特定子集的任务以某种特定方式出了问题，修复方向在你的代码里。

我的情况是骤然下跌。

## 骤跌里藏着什么

三个原因，每一个都有现成的研究成果，能比我解释得更清楚。

上下文腐化造成了大部分损失

失败的工单都是那些较长的工单——多轮对话中 Agent 积累了大量历史记录的那种。

Chroma的Context Rot研究测试了18个前沿模型——GPT-4.1、Claude 4、Gemini 2.5、Qwen3——保持任务难度不变，仅改变输入长度。每一个模型都出现了性能下降。全部十八个。而且这一现象在你接近上下文窗口限制之前就已经开始了，这彻底颠覆了我原有的认知模型。百万token的上下文窗口，并不意味着有百万个可用token。（https://www.trychroma.com/research/context-rot）

有两个发现正好击中了我的具体场景：

1. 干扰项在长上下文中的危害会大幅加剧。相似但错误的信息，比随机噪音的破坏力要强得多。我在每轮对话中都会检索五张最相似的历史工单。相似的工单，从定义上说，就是理想的干扰项。我是在亲手制造自己的失败模式。

1. 连贯文档的表现比打乱顺序的文档更差。所有模型，无一例外，结果一致。目前没有人能完全解释原因。我之所以提到这一点，是因为它应该让你对自己关于"干净上下文"长什么样的直觉保持警惕。

修复方案：将工具输出上限设为1500个token，将检索文档数从五份降至两份，每六轮用一个更廉价的模型对历史记录进行压缩，并将原始任务描述硬固定，使其永远不会在压缩过程中被清除。

仅凭这一项改动，pass^8就从33%提升到了五十多的高位。

这个智能体的权限比我还高

这是我偶然发现的，也是我现在在跑基准测试之前必先进行权限审计的原因。

Simon Willison将其称为"致命三元组"：特权访问、不可信输入，以及一个出站通道。任何同时具备这三者的系统，仅凭文本就能被反过来对付自身。

我的智能体持有数据库凭证，它读取陌生人编写的工单，它能将内容回复到对话线程中。三项全占。

UpGuard记录了六个案例，模式完全一致。Invariant Labs展示了这样一个案例：一个从免费账户提交的单个恶意GitHub Issue，将开发者机器上的私有仓库内容全部拖走。一个在Cursor上使用Supabase service_role凭证的团队——这个选择是为了开发速度，我们都做过——收到了一张包含指令的支持工单，结果他们的智能体查询了集成令牌表，并将结果回帖到了线程里。（https://www.upguard.com/blog/mcp-security-incidents）

修复方案不是让模型变得更能抵抗攻击，而是剥夺它可能被操纵去利用的能力。如果它需要读取不可信输入，就不能有出站通道；如果确实需要出站通道，则必须由人工审批该载荷。数据库权限从对整个schema的SELECT缩减到了四个指定列。

OWASP的《智能体应用Top 10》将此列为ASI01，即智能体目标劫持，位居榜首。全文需要九十分钟读完，而这是目前最值得花的九十分钟。（https://blog.cyberdesserts.com/ai-agent-security-risks/）

运行八次让我花了真金白银

事后看来显而易见。在42张工单上跑八次，意味着336次智能体执行；而智能体在每个步骤都会重新发送其累积的全部上下文，所以到第20步时，你已经为第一轮对话付了二十遍的费用。

Gartner 2026年的数据显示：智能体完成每项任务消耗的token是聊天机器人的5到30倍。Splunk的拆解报告中有一个真正触动我的数据——EY追踪到一次客服交互的成本，在三年间从0.04美元涨到了1.20美元，贵了三十倍，而这期间每token的价格其实在下降。（https://www.splunk.com/en_us/blog/observability/why-most-projects-still-die-before-production.html）

Uber的CTO在四月表示，他们在四个月内就烧完了公司全年的AI编程预算。

因此：先在子集上跑你的pass^k。十项任务，八次试验。先掌握规律，再扩大规模。另外，要对每项任务的成本设置告警，而不是对总支出告警——总支出是滞后指标，而每任务成本能在失控循环第一次发生时就将其捕获。

## 我现在实际在用的五款工具

| 工具 | 用途 | 适用场景 |
|---|---|---|
| tau2-bench | 带模拟用户与策略评分的 pass^k 测试框架 | 构建你自己的领域评估 |
| Langfuse | 开源追踪，支持自托管 | 不想依赖供应商但需要追踪 |
| Braintrust | 集成到 CI 的评估，每次 PR 生成评论 | 希望在合并前捕捉回归问题 |
| Arize Phoenix | OpenTelemetry/OpenInference 追踪 | 已经在使用 OTel |
| E2B / Modal | 沙盒执行，每次运行独立隔离 | 你的 Agent 会编写并运行代码 |

(https://github.com/sierra-research/tau2-bench) (https://langfuse.com/) (https://braintrust.dev/) (https://phoenix.arize.com/) (https://e2b.dev/) (https://modal.com/)

关于测试框架的说明：τ-bench 的评分结果出了名地对配置敏感。该仓库在 2026 年 7 月发布了 v1.0.1 评分修复，重新对银行领域进行了评分，此前的结果与之不可比较。不同的用户模拟器和工具 schema 会在同一个模型上产生不同的数字。这没关系——你的目标不是在排行榜上取胜，而是衡量你自己的 Agent 随时间的纵向变化。(https://github.com/sierra-research/tau2-bench)

自己动手做，大约只需一个下午

1. 挑选 20 个真实的生产输入。不要用合成数据。其中十个应该是之前失败过的案例。

1. 每个运行 8 次。尽量固定随机种子，使用相同的模型版本和相同的工具。

1. 只统计全部 8 次都通过的。那就是你的 pass^8。在查看结果之前先把预期写下来，这样你就无法事后给自己一个更好的解释框架。

1. 绘制衰减曲线：pass^1、pass^3、pass^8。是悬崖式骤降还是平缓下滑？

1. 对失败案例进行聚类。如果一小部分任务反复失败，逐行阅读那些追踪记录。你的 bug 就藏在里面。

1. 只改一件事，然后重新运行。只能改一件。你无法将性能变化归因于同时进行的两处修改。

二十个案例就够了。我曾浪费数周时间规划一个两百个案例的评估套件，最终根本没有建成。二十个不完美的评估，胜过零个美好的意图。

## 我最终的结论

Pulumi 有一项针对 510 名工程师的调查：81% 的人让 Agent 接触了生产环境，但只有 19% 的人允许它自主完成。其余所有人都设置了人工审核关卡。(https://www.pulumi.com/state-of-agentic-infrastructure/)

我以前会把这个数据解读为行业交付不足的表现。现在我认为，这不过是诚实交付的本来面貌——那些声称做得更好的人，只是还没有测量过 pass^8。

我的 Agent 依然在运行。pass^8 是 71%。它无法在未经审批的情况下写入线程，它看到的是四列数据而不是完整的 schema，它的步骤上限由运行时强制执行，而不是通过 prompt 客气地"请求"遵守。

它不如我演示的那个版本令人印象深刻。

但它是第一个我愿意署上自己名字的版本。

如果你也对你的 Agent 运行了 pass^k，我想看看你的曲线。尤其是如果它是悬崖式骤降的话。