论文链接：Staying on Task: Testing the Foundations of Long-Horizon Agent Reliability（arXiv:2609.38712，2026 年 9 月 30 日） 发表 venue：NeurIPS 2026 第二届 “Agentic AI Benchmarks and Applications for Enterprise Tasks” workshop 机构：NVIDIA（Jeffrey Willette、Krishna C. Puvvada、Boris Ginsburg） 领域标签：cs.AI，长时程智能体可靠性 / 长上下文与长生成评估

一、论文背景：长时程工作流的「读得下」与「做得完」是两回事

1.1 从一张两万行的发票对账单说起

论文开篇给了一个非常具体的企业场景：一个应付账款（accounts-payable）智能体要对账一份 20,000 行的发票导出与采购订单。对每一行，它必须检索正确的供应商条款、计算调整额、更新匹配的账本条目。

现在假设最终账本出错了。请问是哪一步出的错？

• 检索错了供应商条款？
• 算错了调整额？
• 漏掉了某一行的处理？
• 还是在某一步上发生了错位，之后所有决策都落到了错误的记录上？

这个问题在现有评估体系下无法回答。任务级评分（task-level score）只告诉你「账本错了」，至于错在哪一环、从哪一行开始错、是能力问题还是簿记问题——一概不知。

1.2 「持续性执行失败」：一种被现有基准集体放过的失败模式

论文把这类失败命名为持续性执行失败（sustained-execution failure）：模型能接受整个长上下文，但随着生成的进行，会「失去位置」（lose its place）或不再一致地施加操作。

注意这和「上下文不够长」是两码事。128K 的模型窗口放得下 65K 的输入——「读得下」没有问题；问题在于输出是一条长达 61K token 的有状态轨迹（stateful trajectory），模型要在这条轨迹上反复执行「读状态 → 改状态 → 追加输出」的循环，几千次不出错。「做得完」考验的是另一种能力：长生成期间的簿记（bookkeeping）与细节注意力。

这正是当前智能体落地最痛的一类场景：批量数据处理、文档流水线、长时程工具调用。而如前所述，现有两类基准恰好都测不到它。

1.3 为什么现在需要这个诊断

2026 年的长时程智能体生态已经响起了密集的警报，只是信号都混在一起：

• METR 的任务时长视界测量显示，agent 在人类专家 90 分钟至 3 小时的任务上，即便视界达标，也是约三分之一的任务每次都成、三分之一每次都败、剩下三分之一时成时败——一致性问题先于能力问题暴露；
• Long-Horizon-Terminal-Bench（arXiv:2607.08964）发现超过 50 步的终端任务上最强 agent 解决率跌破 30%，而短任务超过 60%——失败集中在阶段切换与状态对账的节点上；
• 「Beyond pass@1」可靠性框架（arXiv:2603.29231）则从统计上证明 pass@1 能力排名与长时程可靠性排名系统性背离。

这些工作都指向同一件事：长时程失败有自己的结构，需要被单独测量，而不是被「任务太难」的叙事吞掉。Long-Transduction 是这条脉络里最「受控」的一次尝试——它不追求真实，追求的是把失败模式隔离到可以逐条计分的程度。

二、论文定位与关联工作：两类基准之间的盲区

Long-Transduction 的定位是互补而非替代。论文用一张（概念上的）坐标系说明：现有基准要么测「任务整体成败」，要么测「短答案的长上下文理解」，中间空着一块「长输出的持续执行」。

2.1 智能体任务基准：测整体成败，无法隔离持续性失败

GAIA（Mialon et al., 2024）、WebArena（Zhou et al., 2024）、WorkArena（Drouin et al., 2024）、SWE-bench（Jimenez et al., 2024）、τ-bench（Yao et al., 2024）、Browsecomp（Wei et al., 2025）——这些基准度量「整体任务是否成功」。

它们的问题不是不好，而是粒度不对：一个 0/1 的任务分数把检索错误、计算错误、遗漏、错位级联全部压缩成一个比特。当账本出错时，你无法区分失败来源；更无法观察失败「在生成过程的哪个位置」开始发生。

论文的推论也很直接：无法在重复执行基本操作时保持对齐的模型，不能指望它在 Browsecomp 这类更复杂的长时程动作中坚守任务。

2.2 长上下文基准：答案太短，测不出长生成的簿记

另一类基准测试长上下文的检索与理解：LongBench（Bai et al., 2024）、RULER（Hsieh et al., 2024）、HELMET（Yen et al., 2025）。

• RULER 把大海捞针（needle-in-a-haystack）扩展到多键、多值、变量追踪、聚合、QA，共 13 种任务，并提出「有效上下文长度」的概念——模型分数跌破 Llama2-7B 在 4K 处的 85.6% 基线的那个长度。它揭示了很多模型「标称 128K、有效 32K」的真相，贡献很大。
• HELMET（ICLR 2025，Princeton + Intel）进一步覆盖七个应用向类别（RAG、带引用生成、重排、many-shot ICL、长文档 QA、摘要、合成召回），并证明 NIAH 类合成任务与下游表现相关性很低，倡导全面评估。

但它们共享一个结构性盲区：产出答案相对输入上下文很短。RULER 的变量追踪要你输出链条终点的值，HELMET 的 RAG 要你输出一小段答案——输入 128K，输出几十 token。而长时程「检索+变换」工作流的输出本身是一条长且有状态的轨迹，需要对每条记录做精细簿记。短答案基准对「生成第 8000 条记录时是否还记得第 7999 条做了什么」完全沉默。

2.3 盲区总结

一句话：RULER 告诉你模型「能读多长」，Long-Transduction 告诉你模型「能在多长的输出里持续做对事」。两者正交，合起来才是长时程智能体可靠性的完整地基。

三、问题定义：把对账式工作流抽象为 read-mutate-output 循环

3.1 被隔离的那个共性结构

论文的抽象层次选得很巧：不模拟完整智能体（那会引入工具调用、规划、恢复等混杂因素），而是提取转导任务与智能体工作流共有的读取–变更–输出（read-mutate-output）循环：

1. 从（不断增长的）上下文中读取相关状态；
2. 施加有意义的变更（计算、排序、查找、置换）；
3. 把结果追加到输出流。

每循环一次，上下文变长一点，输出流变长一点。基准要测的就是：模型能否在这个循环重复成千上万次的过程中，始终保持「读对位置、算对结果、写对地方」。

3.2 三个独立的失败轴

论文的核心洞察是：长时程失败不是一维的，而是（至少）三维的。每个轴都可能独立地触发失败：

• 上下文长度轴：循环次数多了，累积的注意力负担；
• 输入格式轴：输入是否有稳定编号（ID）、是否有序——决定「找回位置」的难度；
• 局部复杂度轴：每条记录本身要做多少工作。

只有让三个轴独立变化，才能把失败分别归因到每一轴，而不是得到一个笼统的「长任务做不好」。这是「受控诊断（controlled diagnostic）」一词的方法论来源。

3.3 一个关键设计选择：输出与输入近似 1:1

与短答案基准不同，Long-Transduction 的输出与输入近乎等长（最大档平均 65,374 输入 token + 61,240 必需输出 token）。这个选择直接决定了它测的是「长生成 + 长上下文」的耦合能力——也正是智能体工作流的真实形态：你处理 2 万行账本，就要产出 2 万行结果。

四、问题解法：原子任务 + 三轴网格 + 逐记录计分

4.1 四个原子任务族

所有任务都满足两个条件：（1）操作本身是「原子简单」的——加法、排序、查表、置换，没有任何推理难度；（2）输出是逐记录的，每条都可以独立精确验证。

表格转换含三种操作：同构单元格（4 位整数）行/列置换、异构单元格（1-36 位十六进制片段）行/列置换、KV 解析（a0+n0 → quick fox，保持 CSV 结构逐格替换）。

「原子简单」是特性而非缺陷：任务本身没有任何可输的难度，任何失败都只能归咎于「执行维持」——你要是说模型连 5+6=11 都不会，那没人信；说它在第 3000 条时把 5+6 算到了别人的头上，那才是有用的诊断信息。

4.2 三种输入格式：专门打击「位置追踪」

前三个任务族各有三种格式变体，这是全文最精彩的设计之一：

1. Ordered + IDs（有序+编号）：每行带整数编号，提供稳定查找键。这是最「友好」的格式。
2. Shuffled + IDs（打乱+编号）：输入行打乱，但要求输出按 ID 单调递增。加入了全局重排序要求，但每行的局部任务不变，且 ID 仍然是可靠的锚点。
3. Ordered, no IDs（有序无编号）：去掉编号，结构最少。模型必须仅凭当前输出位置和上下文内容动态追踪「我做到哪了」——一次遗漏会使所有后续位置错位，导致连环失败。

（表格任务因 CSV 无天然行索引，通过指令构造三种类似变体。）

注意第三种格式的评分设计：非空输出行按序数（ordinal）匹配预期——漏一行，后面全部错位。这不是评分的缺陷，而是有意为之：它度量的是「格式脆弱性」，即在没有外部锚点时模型维持对齐的原始能力。

4.3 冻结基准网格

三轴正交展开：4 任务 × 3 格式 × 4 难度 × 6 个视界档（4K/8K/16K/32K/64K/128K，指 input+output 名义总量）× 5 个文档样本 = 每模型 1,440 个文档，单个文档内含数百到数千条独立计分项。7 个模型跑满全网格（Olmo 因上下文限制止步 32K），闭源模型因试跑中频繁拒答、提前终止或要求澄清而被排除在定量比较之外。

实验控制也做得很干净：贪心采样（零温度）、prompt 明确写 “Do not think”、能关思考的模型全关（DeepSeek 用最低思考档）、所有记录的 reasoning token 均为 0——测的是裸转导能力，不掺推理预算的水。

4.4 评分体系（附录 B）

• 条目准确率（item accuracy）：文档内必需输出记录「完全精确正确」的比例；先文档内平均，再对任务-难度单元等权宏平均（防止记录数多的设置主导）。
• 编号流的匹配：用输出的数字 ID 匹配预期记录——缺失 ID 只造成局部零分，不会错位传染。
• 精确完成率（exact document completion）：文档内每条必需记录全对才计 1。对穷尽式工作流而言，这就是「无需返工的文档比例」。
• 位置解析评分（position-resolved scoring）：把预期记录索引映射到 20 个归一化位置桶，观察失败在生成过程中「何时」发生。
• 自洽性（self-consistency）：答案不对，但输出是否仍是格式合规的（如排序任务输出的仍是「某个正确排序的列表」）——用于区分「不会做」与「读错题」。

五、评估指标与实验证据：三轴全景下降

5.1 视界轴：62.8% 的平均相对下降

从 4K 到 128K，全模型平均条目准确率相对下降 62.8%。具体到模型（图 2a）：

几个值得咀嚼的细节：

• DeepSeek V4 Flash 全程领先，但 128K 时也只剩 0.554——平均每两条记录就错一条；
• Nemotron 3 Super 从 0.711 跌到 0.138，参数规模（120B）没有换来可靠性；
• Qwen 122B 在 128K 时只比 Qwen-35B 高 0.030——同系列规模拉大，长时程优势几乎抹平。

结论：支持的上下文长度与模型规模都不能保证可靠的穷尽执行。RULER 式的「有效长度」在这里会有更残酷的答案——按条目准确率算，多数模型的「有效执行长度」远低于标称值。

5.2 格式轴：无 ID 的惩罚高达 64.3% / 66.4%

输入格式变化在全模型平均口径下造成 36.5% 的下降。分任务看（图 3）：

• 算术任务：Ordered+IDs → Ordered, no IDs 下降 16.2%（相对温和）；
• UUID 排序：无 ID 变体下降 64.3%；
• 变量查找：无 ID 变体下降 66.4%。

更反直觉的发现：有序无 ID 比打乱+编号得分更差。直觉上「打乱」应该更难，但打乱输入保留了 ID 这个稳定锚点，模型可以按 ID 检索；而无 ID 输入把唯一的查找键抽走了，模型只能靠「数位置」对齐——这恰是最脆弱的模式。

论文由此给出一个重要判断：「追踪上下文中内容位置」的能力不是任务不变量（not invariant to the current task）——同一个模型在算术上还能靠内容线索撑住，换到排序/查找上就全线崩溃。

5.3 复杂度轴：39.9% 的单调下降

增加局部复杂度（更多操作数、更多排序项、更高置换比例、更大字典池），每个非退化模型都单调下降，全模型平均下降 39.9%（图 4/图 6）。注意这仍然是在「每条记录的难度」维度上——哪怕单条任务变难一点点，长时程叠加后就是显著滑坡。附录图 6 把边际展开成 128K 下全部 12 条任务-格式曲线，无一幸免。

5.4 单任务可靠性：算术 0.96 vs 表格 0.26

128K 档分任务看（图 2b）：DeepSeek 算术 0.961、表格转换仅 0.262；Qwen-122B 算术 0.952、UUID 排序 0.233、表格 0.170。「会做加法」与「能在长流里持续做对表格变换」之间隔着鸿沟——再次说明单条能力与持续执行是两种能力。

5.5 精确完成率：最好的模型也只有 17.1%

128K 档 240 个文档的精确完成率（表 2）：

五个模型精确完成率为零。即使条目准确率 0.554 的 DeepSeek，也只能把 17.1% 的文档一遍做对——5 个文档里 4 个需要返工。条目准确率与精确完成率之间的巨大落差本身就是诊断信息：错误是分散的、随机的，而不是集中在一两处。

5.6 「理解任务但迷失」：自洽性 vs 准确率的解耦

图 5 是全文最有洞察力的一张图：在 Ordered-no-IDs 的 UUID 排序任务上，把每条记录的得分按输出位置画成曲线，分别画「答案正确率」和「自洽性」（输出的仍是一个合规的排好序的列表吗？）。

结果：自洽性曲线始终显著高于准确率曲线。模型到很靠后的位置仍在输出格式正确、排序正确的「某个列表」——它完全理解任务；错的是列表里的内容：它从上下文里读错了该排的题。

这个发现把失败精确定位到了 read-mutate-output 循环的读取环节：不是不会算、不会排，而是「从上下文读取正确的题」这一步在长生成中退化了。这直接排除了「任务太难」的解释——回到第四节的设计哲学，原子简单性在这里兑现了归因能力。

5.7 热图：失败不是均匀分布的

附录图 8 的 128K 热图（8 模型 × 12 任务变体）显示：Lookup ordered+IDs 上 Qwen-122B 达 0.99、Qwen-35B 0.89、DeepSeek 0.63；而 UUID no-ID 一列几乎全军归零（最高 DeepSeek 0.07）；Kimi Linear 全线 0.00。失败高度集中在「无 ID + 需要位置追踪」的格子——三轴设计让失败有了坐标。

六、效果优势的根源解释：为什么这套设计能「隔离」失败

6.1 任务级评分无法区分错误来源

一个 0/1 的任务分数把四种失败压成一个比特（检索错 / 算错 / 漏项 / 错位级联）。Long-Transduction 的原子任务让每条输出记录都可独立精确计分，编号流匹配保证单点错误不传染，位置解析评分进一步回答「失败发生在生成的哪个阶段」。这是「归因能力」的来源：同样的 62.8% 下降，任务级基准只能给你一个「成功率降低了」，这里能告诉你降在哪、怎么降的。

6.2 长上下文基准的输出过短

RULER/HELMET 的答案长度以十 token 计，「生成第 N 条记录时的状态保持」这个维度在其设计里根本不存在。Long-Transduction 用 1:1 的输入输出比把长生成期间的簿记单独拉出来测试——最大档 6.5 万输入 + 6.1 万输出，输出本身就是一条需要持续对齐的长轨迹。两者测的是正交的维度，这就是「互补」的技术内容。

6.3 位置分辨计分揭示：失败在读取，不在执行

自洽性恒高于准确率（5.6 节），意味着执行逻辑（排序规则、格式约定）始终保持正确，退化的是「从上下文读取正确内容」的能力。如果没有逐位置计分 + 自洽性这对指标，这个结论无法得出——你只会看到「分数低」，不知道低在哪个环节。这是整套方法论里最值得学习的一手：用一个可判定的「格式合规」谓词，把「不会做」和「读错题」分开。

6.4 三轴独立变化把「长任务做不好」拆成三个可归因的系数

62.8%（长度）、36.5%（格式）、39.9%（复杂度）——三个数字各自对应一个可控变量，而不是一个混杂的总体印象。对照第五节的数据可以读出交互效应：无 ID 格式的伤害（64.3%/66.4%）远大于打乱+编号，说明「稳定查找键的缺失」是比「无序」更根本的风险因子；而复杂度轴的单调下降说明任何单点难度增量都会被长度放大。

6.5 简单性是特性

再强调一次：如果任务是「重构一个代码库」，失败可能来自推理、工具、规划等任何环节，归因不可能干净。任务是 5+6 和「给 UUID 排序」时，任何失败都无法推给任务难度，只能落在「执行维持」上。这是受控诊断相对于真实基准不可替代的价值——牺牲表面效度，换取归因效度。

七、必要知识反推：读懂本文你需要哪些前置概念

• 转导（transduction）：从输入序列到输出序列的直接映射（区别于有显式中间推理态的智能体循环）。本文的 read-mutate-output 循环是转导的最小工作流化——理解这个术语就理解了标题里 Long-Transduction 的本意：长输出转导。
• 大海捞针（NIAH）与有效上下文长度：RULER 提出的核心概念——标称窗口 ≠ 可用窗口。本文把同样的「标称 vs 实际」思想搬到执行侧：能接受的上下文长度 ≠ 能持续做对的输出长度。
• 条目准确率 vs 精确完成率：前者是平均分（部分正确有分），后者是全对才计 1 的严格口径。两者的落差（0.554 vs 17.1%）是理解「分散型错误」的关键。
• 自洽性（self-consistency，本文口径）：注意与「多次采样投票」的 self-consistency 区分——本文指「输出是否仍满足任务的结构性约束」（如仍是排好序的列表），是一个可判定的格式谓词。
• 宏平均（macro-average）：先文档内平均、再对任务-难度单元等权平均，防止记录数多的设置主导总体分数。评分细节里的这个选择影响了所有头条数字的解读。
• 贪心解码 / 关闭思考：零温度 + 禁用 reasoning token，确保测的是「裸模型」的转导能力而非推理预算的补偿效果。

八、通用性灵感：给智能体工程团队的实操建议

8.1 结构化 ID 标注是最便宜的提升手段

格式轴的结论（无 ID 下降 64.3%/66.4%）翻译成工程语言：给每条待处理记录一个稳定 ID，是性价比最高的可靠性投资。它把模型从「靠数位置对齐」的脆弱模式切换到「靠键检索」的稳健模式。对账、批量改写、流水线处理——任何逐记录的工作流都应该先编号再处理。

8.2 输出按带 ID 的分块做检查点

论文结论明确建议 checkpoint chunks of outputs with IDs。结合精确完成率数据（最好 17.1%）看：长文档一遍做对是小概率事件，工程上必须假设会错。按 ID 分块输出 + 逐块校验 + 只重做出错的块，把「全文重跑」变成「局部返工」——这与外部社区从 Long-Horizon-Terminal-Bench 得出的「把状态写到上下文之外、按依赖线分段」的实践完全同频。

8.3 任务分段：避免「难任务 × 长上下文 × 乱格式」叠加

三轴独立恶化已分别达 62.8%/36.5%/39.9%，而真实工作流往往三轴同时拉满。论文建议把任务拆成更小、更简单的单元——先降局部复杂度，再谈长度。对应到 RAG 式智能体：不要让模型在一次超长生成里同时做「理解复杂指令 + 检索 + 变换」，拆成接力的小步。

8.4 「上下文规格 ≠ 完成质量」：给采购与选型的启示

这是本文对外行最有价值的一句话。模型卡上的 128K/1M 是容量规格，不是质量承诺：Nemotron 3 Super 标称长上下文，128K 条目准确率 0.138。选型时应要求供应商提供逐记录精确计分的长输出证据（或用本文方法自测），而非 NIAH 截图——HELMET 已证明 NIAH 与下游表现相关性很低，本文进一步证明它对执行侧什么都说不了。

8.5 逐项验收：把评分粒度对齐到失败粒度

错误是逐条分散的（0.554 的准确率 / 17.1% 的完成率），那么验收也必须逐条进行。任务级通过率会掩盖大量单点错误；LLM-as-judge 的整体打分同样太粗。用确定性的逐记录校验器（diff 每条 ID 对应的输出）做验收，是本文评分体系直接可移植的工程模式。

8.7 一份「失败模式 → 工程对策」速查表

把论文的实验发现与工程对策对应起来：

8.8 对基准设计者的启发

「原子简单 + 逐项计分 + 多轴独立变化」是一套可复用的诊断设计模式：先找到你要隔离的失败模式，把它抽象成最小可重复循环，然后让每个可疑变量单独变化。牺牲表面效度换来归因效度——在「诊断」场景下这笔交易永远划算。可以预期这条路线会向代码智能体（逐 hunk 计分）、多轮工具智能体（逐调用计分）迁移。

结语

Long-Transduction 用一组刻意简单的任务，量出了一个被两类基准长期遗漏的事实：模型「读得下」与「做得完」之间隔着 62.8% 的鸿沟，而失败的主要环节不是执行而是读取——模型理解任务，却在长生成中丢失了「从上下文读取正确内容」的能力。

对工程团队，行动项是明确的：编号、分块、拆小、逐项验收。对模型团队，论文的最后一句话更有分量：这些失败模式应当在训练时（train-time）缓解，而不是靠 harness 侧的工程补丁永远兜底。毕竟，智能体的可靠性地基不能永远建在「提示词里求模型别迷路」上。

一句话总结：把对账工作流抽象成 read-mutate-output 循环，用原子任务和逐记录计分隔离出长时程智能体的持续性执行失败——三轴独立下降 62.8%/36.5%/39.9%，最佳模型 128K 精确完成率仅 17.1%，失败定位在「读取」而非「执行」。