你的 Agent 完美完成了任务,它下次还能做到吗?
英文标题:Your Agent Aced the Task. Will It Do It Again?
IBM Research 提出,传统 Mean@k 平均成功率会掩盖 Agent 在重复执行同一任务时的不稳定性:GPT-4.1 驱动的 ReAct Agent 在 AppWorld 上 Mean@5 为 77.4%,但全部 5 次都成功的 Pass^5 仅为 53.0%,存在 24.4 个百分点的一致性缺口。团队开发的 Consistency Analyzer 可基于单条已记录轨迹,对各决策步骤进行重采样,定位容易在重复运行时发生改变的“翻转风险”决策点,无需真值标签或重新执行端到端任务。基于诊断结果生成的 consistency guidelines 将 Pass^5 从 53.0% 提升至 69.0%,一致性缺口降至 12.0 个百分点,同时平均准确率提升至 81.0%。该方法表明,Agent 的能力与可靠性是两个独立维度,开发者应在 Mean@k 之外报告 Pass^k,并针对高不确定性决策进行诊断和修复。
3.6 KB
12.0 KB
10.1 KB
13.0 KB
137.2 KB
200.4 KB
151.7 KB
49.8 KB
中文
你的 Agent 在预演时运作正常,但在现场演示时却走了另一条路径,并在同一个任务上失败。
这在台上会很尴尬。在生产环境中,这属于可靠性问题:一个曾经成功的工作流,可能在用户再次发出相同请求时失败。对于核对金融交易、检查合同义务等关键任务而言,这可能是无法接受的阻碍。
大多数基准测试通过平均值掩盖了这种波动性。在 AppWorld 上,使用 GPT-4.1 的 ReAct Agent 在五次重复运行中的成功率为 77.4%。但在全部五次运行中均成功的任务仅占 53.0%,即存在 24.4 个百分点的一致性缺口。
大多数基准测试报告的是第一个数字。我们构建了一种方法来衡量第二个数字,并加以改善。
在此前的文章中,我们介绍了 ALTK-Evolve——一个将 Agent 自身过往轨迹转化为可复用指南的系统,这些指南会被自动提炼,并在推理时重新注入。它能够显著提升任务成功率,但这些结果同样只回答了平均情况下的问题。本文介绍 一致性指南(consistency guidelines):这是 altk-evolve 中新增的一类指南,建立在我们称为 Consistency Analyzer(一致性分析器) 的诊断工具之上,直接针对这一缺口。
TL;DR
- 准确率掩盖了不可靠性问题。 一个 ReAct Agent(在 AppWorld
test_normal上使用 GPT-4.1)平均有 77.4% 的成功率,但仅有 53.0% 的任务能在重复执行的 全部 5 次 中成功——存在 24.4 个百分点的一致性缺口。在困难任务上,这一缺口达到 30 个百分点。 - 我们为此构建了专门的诊断工具。 Consistency Analyzer 对 Agent 自身记录的轨迹进行重采样,以识别容易发生“翻转”的决策点——即模型只差一次 token 采样就可能作出不同选择的步骤。它只需一条轨迹而不需要真值标签;它不必端到端地重复执行任务,而是以一次请求获取 k 个补全结果(默认 k=5)的方式,对轨迹中的每个决策点进行重采样。
- 将该诊断结果转化为指南,可将缺口减半——从 24.4pp 降至 12.0pp(同任务 Pass^5 提升 +16.0pp,相似任务提升 +13.0pp),且平均准确率没有任何损失。
- 完整的方法论和评估结果见 arXiv 技术报告。
几乎无人报告的指标
标准 Agent 评估报告的是 Mean@k:运行一个基准测试 k 次,并计算平均通过率。通常 k =3,有时甚至仅为 1。这是每个排行榜上的数字,也是实践中“77% 准确率”的含义。
Mean@k 回答的是:“这个 Agent 平均来说有多好?”它无法回答真实用户所关心的问题:如果我再次提出完全相同的问题,它是否仍然表现良好? 为此,你需要 Pass^k:即 Agent 在 k 次运行中 全部 成功的任务占比。
⚠️ Pass^k 不是 Pass@k。 人们熟悉的 Pass@k 是 乐观的——它询问 k 次尝试中是否有至少一次成功;当你可以验证结果并重试时,这是正确的问题。Pass^k 则是它的悲观镜像:每一次尝试都必须成功。字母相同,问题相反。始终有 Pass^k ≤ Mean@k ≤ Pass@k。
由 GPT-4.1 支持的 ReAct Agent 达到了 77.4% 的 Mean@5——这确实很强。但其 Pass^5 只有 53.0%。近四分之一个基准测试由这样的任务构成:Agent 有时能解决,有时却不能,而两次运行之间任务本身没有任何变化。我们将这一差值——Mean@k 减去 Pass^k——称为 一致性缺口(consistency gap)。
这不是通过更大模型就能解决的能力问题,而是一个正交维度:一个 Agent 可以同时具备能力和不一致性。
Agent 为什么会“翻转”:尖锐决策与平坦决策
每当 LLM Agent 作出一个决策——调用哪个 API、传递什么参数、是否重试——这个决策都来自下一个 token 的概率分布。关键在于该分布的 形状。**尖锐(sharp)**分布将大部分概率质量集中于一个 token:其他候选项明显落后,因此每次运行都会产生相同选择。**平坦(flat)**分布则会将相近的概率质量分散到多个几乎并列的 token 上,最终哪个 token 胜出接近于抛硬币。
分布形状决定了改变结果需要多大的噪声。尖锐分布具有韧性——GPU 浮点运算的非结合性、请求批处理及其他平台侧影响会轻微扰动数值,但远不足以改变一个明显赢家的排序。平坦分布则恰恰容易受到这些扰动影响:接近并列的候选项可能在微小扰动下交换顺序。而一条轨迹串联了数十个决策,每一步发生翻转的小概率会不断累积,最终使 某一次 运行走上不同路径的概率大幅上升。这正是 24 个百分点缺口的来源。
这也是为什么问题不会因你的解码设置而消失。贪婪解码和固定随机种子控制的是 如何将一个分布转换成 token,而不是分布本身。在托管端点上,概率会随每次运行发生细微变化,因此,即便将相同 prompt 发给同一模型、温度设为零,今天接近并列的候选项可能朝一个方向决出胜负,明天则可能朝另一个方向。
**我们的设置:**ReAct Agent 的运行温度为 0.0,因此上述方差均非普通采样造成。
先诊断,再修复
这会将问题转化为一场搜索:给定轨迹中哪些步骤属于平坦决策?而一旦知道这些步骤,又该如何处理?
一致性指南来自一个两阶段流水线,它接入 ALTK-Evolve 现有的机制,但由一种新的源信号来驱动生成内容。
1. 检测——Consistency Analyzer。 给定一条已记录轨迹,分析器通过受控重采样来重放每一个决策步骤,衡量模型在该位置上的实际输出变化程度。具体而言,每个决策步骤只需额外进行一次模型调用,并且只在线下执行一次——请求时设置采样参数,以一次获得 k 个补全结果(默认 k=5)——重放时使用已记录的上下文,而不会发起新的工具调用、新的环境交互,也不会对任务进行第二次端到端 rollout。由此可得到每个决策步骤的一致性分数,并将其写入评分卡,精确指出哪些决策在下一次运行时可能发生翻转。检测过程完全是黑盒式的——无需 logits、无需模型内部信息,也无需在已有轨迹之外进行额外插桩。
2. 生成——定向指南。 每个被标记的步骤都会成为候选一致性指南,采用标准 ALTK-Evolve 格式,因此可接入现有的存储和检索流水线。以下是 GPT-4.1 根据 AppWorld 任务“根据我的 SimpleNote 笔记,我的愿望清单中已完成了多少项活动?”的一条轨迹生成的真实示例:
[指南 1] 在笔记内容中统计复选框式标记时,应使用以行为锚点的正则表达式匹配,而不是简单地统计子字符串出现次数——笔记标题常会在图例行中重复该标记符号。
[指南 2] 对笔记查询的搜索结果,务必检查是否存在多个匹配项,并在继续之前确认找到了正确的笔记。
这里没有任何任务特定的琐碎知识。字符串计数错误和未验证的搜索结果,都是在许多 AppWorld 任务中以高不确定性出现的决策点。这正是核心所在:分析器针对的是不稳定性,而不是失败,因此它能够捕捉到 Agent 这一次恰好做对、但下一次很容易做错的步骤。
观看 2 分钟演示——Agent 针对该任务的五次并行运行,因其对计数策略存在不确定性而呈现 3 比 2 的分歧;在将这些指南加入上下文后再次运行,五次结果全部一致。
结果:在不损失准确率的情况下缩小缺口
我们在 AppWorld test_normal(168 个任务)上进行了评估,使用运行于 GPT-4.1 的 ReAct Agent;针对每项任务,我们从单条基线轨迹生成一致性指南,并在 5 次新的运行中测试。
Mean@5(%),汇总结果——与上文 Pass^5 使用相同的量表。
一致性缺口大致减半。 汇总 Pass^5 从 53.0% 提升至 69.0%,Mean@5 从 77.4% 提升至 81.0%,使“看起来有能力”与“可以依赖”之间的缺口从 24.4pp 缩小至 12.0pp。此前不一致任务中,接近三分之一变成了 Agent 在 每一次运行 中都能通过的任务。
中等和困难层级的收益最大。 中等难度提升 +22.9pp(相对提升 +44%),困难难度提升 +14.3pp(相对提升 +45%)——两者相对收益基本持平,但中等难度的绝对提升更大。简单任务提升 +12.2pp,因为其原本的改进空间最小。这正是一致性指南的设计目标:识别并稳定那些 Agent 自身不确定性正在泄漏到最终结果中的特定决策点。
Mean@5 从未下降。 保持平均准确率是一项硬性要求,而非锦上添花:若一个系统以牺牲 Mean@5 为代价提升 Pass^5,只是在转移不可靠性,而非解决它。各个难度级别的平均准确率均保持不变或有所提升。
这些指南可以泛化——并非仅为某条轨迹打补丁
将指南应用于同一 AppWorld 场景中不同但相关的任务——即提取这些指南的场景的另一种变体——一致性指南仍能将 Pass^5 提升 +13.0pp,仅比同任务指标低 3 个百分点。由一次运行得出的指南并非只是在修补该次运行,而是在捕捉可迁移的规律。
来自较弱模型 gpt-oss-120b 的证据更为有力。同任务 Pass^5 从较低的基线提升 +6.0pp(10.1% → 16.1%);而有趣的是,相似任务的泛化提升(+8.7 pp)实际上 超过 了同任务收益,这表明这些指南捕捉到了真正可复用的失败模式,而非记忆某条轨迹的具体细节。
如果你正在交付 Agent
- 在 Mean@k 旁报告 Pass^k。 平均值无法区分可靠的 Agent 和幸运的 Agent;即便 k=3,也足以暴露你此前未曾发现的缺口。
- 预计缺口会随难度上升而扩大。 你的最高难度层级,正是单一平均数字最具误导性的地方。
- 不要先急于使用更大的模型。 一致性与能力正交。更强的模型会提高 Mean@k,但未必会缩小一致性缺口。
- 诊断不需要评分器,也不需要在线重放。 每个决策步骤额外进行一次 LLM 调用(默认采样 k=5 个补全结果)即可——无需真值标签,也无需针对环境重新运行任务。这使其适用于生产流量,因为你往往甚至无法对任务进行一次端到端重放。
试用
试用 ALTK-Evolve 工具包——该开源仓库现已包含本实验使用的 Consistency Analyzer 和一致性指南生成功能——或阅读 arXiv 技术报告,了解完整方法论。
如果那些无法在你自己的任务上复现的准确率数字令你感到熟悉,我们希望听到你的经历——你自己的 Agent 中出现的、易发生翻转行为的具体案例,正是塑造我们下一步开发方向的反馈。提交 issue 或发起讨论。
附录:理解这些指标
- Mean@k。 运行一个任务 k 次,报告平均通过率——这也是大多数基准测试所称的“准确率”。
- Pass^k。 Agent 在 k 次独立运行中全部成功的任务占比。始终 ≤ Mean@k。这对应用户连续两次运行相同查询时的体验。
- Pass@k:k 次运行中至少一次成功——这是乐观版本,在代码生成论文中较为常见。
- 一致性缺口(Consistency gap)。 Mean@k − Pass^k,以百分点表示。
关联产物 / 参考资料
English / 原文
Your agent works in rehearsal, but during the live demo, it takes a different path and fails the same task.
That is embarrassing onstage. In production, it is a reliability problem: a workflow that succeeded once may fail the next time a user makes the same request. For mission-critical work, such as reconciling a financial transaction or checking a contract for an obligation, that can be a showstopper.
Most benchmarks hide this variability behind an average. On AppWorld, a ReAct agent using GPT-4.1 succeeded on 77.4% of runs across five repetitions. But it succeeded in all five runs for only 53.0% of tasks — a 24.4-point consistency gap.
Most benchmarks report the first number. We built a way to measure the second — and improve it.
In an earlier post, we introduced ALTK-Evolve — a system that turns an agent's own past trajectories into reusable guidelines, distilled automatically and injected back at inference time. It measurably improves task success, but those results only asked the average-case question too. This post introduces consistency guidelines , a new guideline type in altk-evolve built on top of a diagnostic tool we call the Consistency Analyzer , that targets this gap directly.
TL;DR
- Accuracy hides an unreliability problem. A ReAct agent (GPT-4.1 on AppWorld
test_normal) that succeeds 77.4% of the time on average succeeds on all 5 repeated runs for only 53.0% of tasks — a 24.4-point consistency gap. On hard tasks it reaches 30 points. - We built a diagnostic for exactly this. The Consistency Analyzer resamples an agent's own recorded trajectory to find flip-prone decision points — steps where the model was one token-sample away from doing something different. It needs one trace and no ground truth — it resamples each decision point in that trace with a single call requesting k completions (k=5 by default), rather than re-running the task end-to-end.
- Turning that diagnosis into guidelines halves the gap — from 24.4pp to 12.0pp (same-task Pass⁵ +16.0pp, similar-task +13.0pp), without costing anything in average accuracy.
- Full methodology and evaluations are in the technical report on arXiv.
The Metric Almost Nobody Reports
Standard agent evaluation reports Mean@k : run a benchmark k times, average the pass rate. Often k =3, sometimes just 1. It's the number on every leaderboard, and it's what "77% accurate" means in practice.
Mean@k answers "how good is this agent, on average?" It does not answer the question a real user cares about: will it still be good if I ask this exact question again? For that you need Pass^k : the fraction of tasks where the agent succeeds on all k runs.
⚠️ Pass^k is not Pass@k. The familiar Pass@k is optimistic — it asks whether at least one of k attempts succeeded, the right question when you can verify and retry. Pass^k is its pessimistic mirror image: every attempt must succeed. Same letters, opposite question. Pass^k ≤ Mean@k ≤ Pass@k, always.
A ReAct agent backed by GPT-4.1 posts a Mean@5 of 77.4% — genuinely strong. But Pass^5 is only 53.0%. Nearly a quarter of the benchmark consists of tasks the agent can sometimes solve and sometimes can't, with nothing about the task changing between runs. We call this gap — Mean@k minus Pass^k — the consistency gap.
This isn't a capability problem you fix with a bigger model. It's an orthogonal axis: an agent can be capable and inconsistent at the same time.
Why Agents Flip: Sharp Decisions vs. Flat Ones
Every time an LLM agent decides something — which API to call, what argument to pass, whether to retry — that decision comes out of a probability distribution over next tokens. What matters is the shape of that distribution. A sharp one puts most of its mass on a single token: the runners-up are far behind, and the same choice comes out run after run. A flat one spreads comparable mass across several near-tied tokens, and which one wins is close to a coin flip.
The shape decides how much noise it takes to change the outcome. Sharp distributions are resilient — GPU floating-point non-associativity, request batching, and other platform-side effects nudge the numbers slightly, but nowhere near enough to reorder a clear winner. Flat distributions are vulnerable to exactly that nudge: near-ties may reorder under small perturbations. And because a trajectory chains dozens of decisions, a small per-step chance of flipping compounds into a large chance that some run goes differently. That's where a 24-point gap comes from.
This is also why the problem survives your decoding settings. Greedy decoding and a fixed seed both govern how a distribution gets turned into a token — they say nothing about the distribution itself. On a hosted endpoint the probabilities shift slightly from run to run, so the same prompt to the same model at temperature zero can still resolve a near-tie one way today and the other way tomorrow.
Our setup: the ReAct agent runs at temperature 0.0 , so none of the variance above is ordinary sampling.
Diagnose, Then Fix
Which turns the problem into a search: which steps in a given trajectory were the flat ones — and what do you do about them once you know?
Consistency guidelines come out of a two-stage pipeline that plugs into ALTK-Evolve's existing machinery — with a new source signal driving what gets written.
1. Detect — the Consistency Analyzer. Given one recorded trajectory, the analyzer replays each decision step through controlled resampling, measuring how much the model's output actually varies at that point. Concretely, that's one additional model call per decision step, done once offline — issued with the sampling parameter set to draw k completions at once (k=5 by default) — replayed against the already-recorded context, not new tool calls, not new environment interactions, and not a second end-to-end rollout of the task. This yields a consistency score per decision step that is written into a scorecard to pinpoint exactly which decisions are at risk of flipping on the next run. Detection is fully black-box — no logits, no model internals, no instrumentation beyond the trace you already have.
2. Generate — targeted guidelines. Every flagged step becomes a candidate consistency guideline in the standard ALTK-Evolve format, so it slots into the existing storage and retrieval pipeline. Here's a real example, generated by GPT-4.1 from a trajectory of the AppWorld task "How many activities are done in my bucket list as per my SimpleNote note?":
[Guideline 1] When counting checkbox-style markers in note content, use a line-anchored regex match rather than a plain substring count — note titles often repeat the marker symbol in a legend line.
[Guideline 2] Always verify search results for note queries by checking for multiple matches and confirming the correct note before proceeding.
Nothing here is task-specific trivia. String-counting bugs and unverified search results are decision points that show up with high uncertainty across many AppWorld tasks. That's the point: the analyzer targets instability, not failure — so it catches steps the agent happened to get right this time but could easily get wrong next time.
Watch the 2-minute demo — five parallel runs of the agent split 3-2 on this task because of agent uncertainty about the counting strategy, then run again after these guidelines in context: all five agree.
Results: Reducing the Gap Without Losing Accuracy
We evaluated on AppWorld test_normal (168 tasks) with a ReAct agent on GPT-4.1, generating consistency guidelines from a single baseline trajectory per task and testing them on 5 fresh runs.
Mean@5 (%), aggregate — same scale as Pass^5 above.
The consistency gap is cut roughly in half. Aggregate Pass^5 rises 53.0% → 69.0% while Mean@5 rises 77.4% → 81.0%, narrowing the gap between "looks capable" and "can be counted on" from 24.4pp to 12.0pp. Nearly a third of previously-inconsistent tasks become tasks the agent passes on every single run.
The middle and hard tiers gain most. Medium +22.9pp (+44% relative), Hard +14.3pp (+45% relative) — effectively tied in relative terms, with Medium ahead absolutely. Easy gains +12.2pp, having had the least room. This is consistency guidelines doing what they're designed to do: finding and stabilizing the specific decision points where an agent's own uncertainty was leaking into the outcome.
Mean@5 never drops. Preserving average accuracy was a hard requirement, not a nice-to-have: a system that boosts Pass^5 by trading away Mean@5 would just be shifting unreliability around, not fixing it. Mean accuracy holds or improves at every difficulty level.
The guidelines generalize — they aren't patching one trajectory
Applied to a different but related task in the same AppWorld scenario — another variant of the scenario the guidelines were mined from — consistency guidelines still lift Pass^5 by +13.0pp , only 3 points below the same-task number. A guideline derived from one run isn't just patching that run; it's capturing something that transfers.
The sharper evidence comes from a weaker model, gpt-oss-120b. Same-task Pass^5 rose +6.0pp from a much lower baseline (10.1% → 16.1%) — and, interestingly, the similar-task generalization number (+8.7 pp) actually exceeded the same-task gain, suggesting the guidelines were capturing genuinely reusable failure patterns rather than memorizing one trajectory's specifics.
If You're Shipping an Agent
- Report Pass^k next to Mean@k. Averages can't distinguish a reliable agent from a lucky one; even k=3 will surface a gap you didn't know you had.
- Expect the gap to widen with difficulty. Your hardest tier is where a single averaged number is most misleading.
- Don't reach for a bigger model first. Consistency is orthogonal to capability. A stronger model raises Mean@k; it doesn't necessarily reduce the consistency gap.
- Diagnosis needs no grader and no live replay. One extra LLM call per decision step (sampling k=5 completions by default) is enough — no ground truth, no re-running the task against the environment. That's what makes it usable on production traffic, where you often can't replay a task end-to-end even once.
Try It
Try theALTK-Evolve toolkit — the open-source repo now includes the Consistency Analyzer and consistency-guideline generation used in these experiments — or read thetechnical report on arXiv for the complete methodology.
If accuracy numbers you can't reproduce on your own tasks sound familiar, we'd like to hear about it — concrete examples of flip-prone behavior in your own agents are exactly the kind of feedback that shapes what we build next. Open an issue or a discussion.
Appendix: Understanding the Metrics
- Mean@k. Run a task k times, report the average pass rate — what most benchmarks call "accuracy."
- Pass^k. The fraction of tasks where the agent succeeds on all k independent runs. Always ≤ Mean@k. What a user experiences if they run the same query twice.
- Pass@k At least one of k runs succeeds — the optimistic counterpart, common in code-generation papers.
- Consistency gap. Mean@k − Pass^k, in percentage points.