LongHarness：用状态化证据管理推进亿级 Token 语料上的智能体推理

方法详解

总览：证据与结论作为耦合的持久状态

LongHarness 是一个与模型无关的运行时框架。它不训练新的策略，而是把“证据库”和“结论状态”作为跨回合持久的运行时状态，并让两者在同一个动作空间里协同演化。证据库保存从已读段落中抽取、并带有来源引用的陈述；结论状态则记录智能体对这些证据的当前解释，包括已确立的论断、有支撑的假设，以及尚未解决的缺口。把两者分开的意义在于：证据是文档“说了什么”的记录，结论是把证据转成决策的推断，两者用显式引用相连，而不是混为一谈。

每个未解决缺口都对应“要确立、限定或推翻当前结论所缺的信息”。这样，结论就不是一段静态文本，而是一张带缺口清单的工作台：缺口告诉系统下一步该去语料里找什么，证据回来后再决定结论是否要改。论文用一张总览图说明单个智能体如何在证据库、结论状态和外部文档之间来回，见下图。

图 2：LongHarness 总览。单个智能体同时维护证据库与结论状态，并与外部文档交互；证据—结论共演化用未解决的结论引导探索，用被接纳的证据修订结论，证据生命周期管理则决定哪些陈述仍然有效，并保留其来源引用。

核心机制一：证据—结论共演化

论文把证据与推断的分离落到两个算子上。在一个推理循环里，先由当前结论状态去控制探索，并把取回并接纳的新陈述写入证据库： $$E^{+}=\mathcal{A}_{\theta}(q,D,E,C),$$ 再由证据库里的活动证据去更新结论： $$C^{+}=\mathcal{R}_{\theta}(q,E^{+},C).$$ 前者把“该找什么”变成可执行的检索与阅读，后者把“找到了什么”变成对结论的强化、限定或改写。两条方程规定了依赖方向，但并不限制一次要执行多少步，因此探索和修订可以随着情况自适应地交错。

在“结论引导的探索”这一侧，结论状态直接决定下一步搜什么、读哪一段。对每一条论断，智能体会先想清楚哪些观察能够确立、限定或反驳它，再用这些要求去构造查询、选择阅读范围。相互竞争的几个假设会驱动能够区分它们的检索；未解决的缺口会把注意力拉向缺失的前提。如果某次观察没有把缺口补上，智能体可以改写查询或扩大阅读范围，但探索始终拴在“推进结论所需的信息”上，而不是漫无目的地扩大历史。

在“证据驱动修订”这一侧，智能体观察到证据库更新的结果之后，会重新评估结论状态里的各条论断，判断它们是否仍被活动证据支持，是否需要加上限定条件，或者必须修订。它会同步更新受影响的论断、证据引用和未解决缺口，使结论状态与当前证据保持一致。在提交最终答案之前，智能体还要把尚未反映进结论的相关证据并进去，并检查剩余缺口是否可能改变所求的决策。这一步直接针对证据状态漂移：更正一旦被接纳，就有机会在最终计算里生效。

为了把这条闭环画清楚，下图的流程完全取自论文的动作空间：结论缺口驱动 search 与 read，读取注册来源引用后被 upsert 接纳为证据，观察更新结果后再用 revise 修正或撤回，最后据此修订结论；当缺口闭合，才进入 compute 与 final。

flowchart TD
    Q["问题 q 与外部文档集合 D"] --> S["持久状态 S_t"]
    S --> G{"结论状态是否有未解决缺口"}
    G -->|有缺口| SR["search 定位候选文档"]
    SR --> RD["read 有界读取并注册来源引用"]
    RD --> EB["EvidenceBank upsert 接纳来源链接陈述"]
    EB --> OBS["观察更新结果"]
    OBS --> REV["EvidenceBank revise 修正或撤回证据"]
    REV --> CO["结论修订 更新 claims 与 gaps"]
    CO --> G
    G -->|缺口闭合| CP["compute 按证据 id 计算"]
    CP --> F["final 提交答案与有效证据引用"]
  

核心机制二：证据生命周期管理

第二条机制管的是“证据从哪来、怎么留下、什么时候退出”。证据生命周期管理治理来源链接陈述如何进入、停留和被移出活动证据状态。一条陈述最初是从已读段落中抽取的候选，被接纳后成为活动证据，之后可能随新证据被修订或退役。这个生命周期需要满足三件事：可追溯到已观察到的来源段落、跨交互持续可用、以及在支撑证据变化时能被显式更新。

证据库用三套做法同时满足这三点。为了可追溯，每条候选陈述都必须引用此前 read 动作注册过的来源引用，控制器负责校验引用有效性，由智能体判断陈述是否忠实于其来源。为了持久，被接纳的陈述在后续交互里一直可用，智能体不必从早先的观察里重新拼回证据。为了显式修订，更正后的陈述会作为新的活动条目被接纳，旧条目被标记为“被取代”；若要撤回，则让旧条目离开活动状态而不提供替代。智能体先观察证据库的更新，再去修订受影响的结论，最终引用会解析到活动陈述及其底层来源段落。

这套设计在实现上只有两个显式操作：upsert 接纳一批来源链接陈述，revise 用一个替代陈述替换某条活动条目，或者用一个空替代把它撤回。每条提案独立校验来源引用是否由先前的 read 注册，所以一批里可能只接纳一部分。被接纳的条目保留不可变标识，更正通过 revise 记录，而不是原地改写。被取代或被撤回的条目仍留在修订记录里，但不能在 compute 或 final 请求中被引用。论文特别提醒：当证据失效时，迁移日志会标记受影响的结论引用，但运行时不自动删除或重写那些论断——这也是后文局限里的一条。

智能体与环境的交互接口

整套方法共用一套动作接口，使策略能在同一个回合序列里交错进行证据获取、维护和使用。search 定位与某个信息需求相关的文档或段落，返回候选位置与导航片段；read 在受限范围内查看指定位置，返回源文本并注册来源引用；EvidenceBank 提交或修订来源链接陈述；compute 在证据值上计算确定性数值表达式，并校验声明的证据引用；final 提交带支撑引用的答案。接口刻意把“候选发现”和“来源查看”分开：搜索片段只是导航辅助，只有 read 返回的引用才有资格支撑证据库陈述。

策略每回合只选一个操作，控制器在执行前校验它的结构、来源引用和资源需求，非法动作返回错误观察且不改动持久状态。证据库的变更会把结论更新推迟到智能体观察到结果之后，策略再通过可选的部分更新修订受影响的论断与引用，未提交的字段保持不变。论文强调了资源边界：最多 200 个回合、最多 60 次 search 调用、累计读取预算 100 万个 Token、单次 read 最多 16,384 个 Token。历史观察被完整保留，不用摘要或占位符替换；也正因如此，一次超出端点上下文的请求失败会终止该回合。

把接口和状态放在一起看，LongHarness 的做法其实很克制：它没有新增一个庞大的多智能体系统，也没有改动模型本体，只是在运行时增加两张结构化状态和一组受控操作。真正起作用的是“把决定下一步搜什么、最终答什么的那部分信息显式化”，并让它在每次证据变化后得到维护。这一点从下面的消融里能看得很清楚——把所有持久状态都拿掉，只剩交互历史，准确率会立刻掉下来。

实验结果

评测设置

论文在四个设置上评估：OfficeQA Pro V1 与 V2、AA-LCR-1.1，以及 LongBench v2 的 Long 子集，覆盖外部语料检索与给定上下文推理两类场景。OfficeQA Pro V1 有 133 个问题、697 份文档，约一亿 Token；V2 扩到 90 个问题、1,435 份文档，并强调需要跨序列、版本或文档拼接数值的复合问题。AA-LCR-1.1 有 100 个问题、30 个文档组共 234 份文档，每组平均约 99,325 个 Token，题目需要综合、时间推理、条件逻辑或跨文档数值计算。LongBench v2 Long 子集有 108 个问题，上下文从约 13.2 万词到 138 万词，中位数约 20.4 万词。

主对比把主干模型固定为 GLM-5.3-Flash 和 Qwen3.8-Flash，对照 Codex CLI 0.135.0、Claude Code 2.1.216 与 RLM。所有 harness 收到相同的问题与文档语料，且看不到参考答案或金标来源标注。Codex 与 Claude Code 各允许 200 个模型回合并各 200 次工具调用，RLM 允许 30 次迭代，LongHarness 允许多达 200 步，但受累计读取 100 万 Token 和 60 次搜索的约束。一个重要的诚实说明是：受算力限制，主对比每个 harness、每个设置只跑一次；三重复实验放在附录里，只覆盖 GLM-5.3-Flash。

主结果：语料级检索上拉开差距

直接推理基线即使拿到用 BM25 检索进 256K 窗口的相关段落，在 OfficeQA Pro V1 上精确匹配最高也只有 23.2%，在 V2 上最高只有 5.6%。论文的解释是：在语料规模下，固定窗口装不下全部可能相关的证据，而在推理开始前选定的段落可能刚好漏掉解决中间结论所需的信息。LongHarness 用结论去引导后续检索、跨交互累积证据，把 GLM-5.3-Flash 的精确匹配从 V1 的 15.8% 提到 60.2%，从 V2 的 4.4% 提到 61.1%。

和最强的竞争 harness 相比，LongHarness 在 V1 上高 12.0 个百分点，在 V2 上高 18.9 个百分点。V2 上更大的优势被认为与一个重要事实相符：当更多分散的数值需要被定位、调和并组合时，跨交互保持证据的价值更高。换到 Qwen3.8-Flash，LongHarness 依旧在两个版本上都领先，V1 达 61.7%、V2 达 51.1%；它对最强竞争 harness 的优势在 V1 上是 8.3 个百分点，但在 V2 上收窄到对 Codex 的 1.1 个百分点。论文没有回避这一点，明确说明增益大小会随主干和设置变化。AA-LCR 上它得到 84.0% 和 87.0%，LongBench v2 Long 上得到 75.9% 和 76.9%，四个设置的平均 Exact 分别达到 70.3% 和 69.2%。

表 1：四个基准上的主结果。OfficeQA Pro 同时报告精确匹配与 5% 相对误差内准确率，AA-LCR 与 LongBench v2 报告 Exact 准确率；此处摘录 Exact 列与平均值，数值取自论文 Table 1。

消融：两条机制各自都在起作用

论文用五个消融回答一个核心问题：证据—结论共演化和证据生命周期管理到底是不是关键。它们分别是：去掉全部持久状态（保留交互历史）、去掉证据—结论共演化（保留证据库但移除结论状态与检索反馈）、朴素证据累积（保留结论反馈但只允许追加式更新）、去掉显式的结论引导探索（两个状态都在但不指示用缺口引导检索）、以及通用工作笔记（用可编辑的自由文本笔记替换结构化结论）。结果如下表，可见把结构化结论换成自由文本笔记损失最大，V1 掉 6.8 个百分点、V2 掉 7.8 个百分点；只允许追加证据的朴素累积在 V2 上掉 10.0 个百分点，说明修订和退役证据确有价值。

表 2：GLM-5.3-Flash 在 OfficeQA Pro 上的消融，Ex. 为精确匹配率（%），下降值为相对完整 LongHarness 的百分点差（舍入前计算），数值取自论文 Table 2。所有消融在 V2 上的损失都更大，印证了当问题需要跨来源组合数值时，维护与调和证据更重要。

轨迹分析：失败发生在哪一层

论文用 GPT-5.6-Luna 在温度 0 下审计错误回合，把失败拆成三层：检索是否找到必需证据、编辑是否在最终决策里保留并采用该证据、变换是否把采用的证据算成正确答案。设 $E_1$ 表示轨迹中出现必需证据，$E_2$ 表示它在最终决策中被保留和调和，$E_3$ 表示答案精确正确，则三层成功率定义为 $$r_1=P(E_1),\qquad r_2=P(E_2\mid E_1),\qquad r_3=P(E_3\mid E_1,E_2).$$ 其中编辑与变换率只在前一阶段通过的问题上计算。

LongHarness 在 V1 上的检索覆盖与 Claude Code 持平，但在条件证据采用率和答案转化率上更高。到 V2，它的检索、证据采用和答案转化率分别是 87.8%、87.3% 和 79.7%，两个条件成功率（87.3% 与 79.7%）和 V1 的 87.6% 与 80.8% 都很接近，说明证据使用的质量在两次设置间保持稳定。这恰好对上了“证据状态漂移”的诊断：漂移伤害的不是检索广度，而是检索到的东西能不能进入最终决策。

表 3：GLM-5.3-Flash 在 OfficeQA Pro 上的三层成功率（%），数值取自论文 Table 3。检索覆盖率越高说明越容易找到必需证据，条件编辑率与变换率越高说明找到的证据越容易被保留并转化为正确答案。

交互长度同样透露了信息。V1 到 V2，LongHarness 的中位回合数从 22 升到 30，Claude Code 从 21 升到 116，Codex 从 19 升到 43。Codex 在 V1 有 3.8%、在 V2 有 21.1% 的问题耗尽了记录到的模型回合预算，Claude Code 的分布在 V2 上明显向 200 回合聚集。论文给出的解释是：V2 语料更大、问题需要跨来源拼接，LongHarness 把未解决的信息需求记在结论状态里、把已获取的证据留在证据库中，于是后续检索能聚焦缺失部分、复用已确立的数值，避免了反复搜索或重建同一事实，因而回合数的增长小得多。

案例分析：一次没有被采纳的更正

论文用 Figure 4 给出一个很有说服力的案例：计算 80 个月度财政部支出的几何平均。Codex 在 22 次命令调用内就定位到相关表格，但把缺失值留成隐式状态，随后连续做了 103 次向后读取，属于典型的无界探索。它用错误的 1942 年 5 月值 4100 算出 4958.09；之后它确实看到了更正后的值 4400，却没有把这个更正带进最终计算，答案仍停在旧结果上。

图 4：GLM-5.3-Flash 在 OfficeQA Pro V1 上的证据生命周期对比。对 80 个月财政部支出的几何平均，Codex 持续搜索并忽略了已识别的更正；LongHarness 更新证据并返回参考答案 4962.46（百万美元）。圆圈标出 Codex 的错误输入、更正与最终答案。

把 4100 换成更正后的 4400，几何平均就变成参考答案 4962.46。Codex 的失败之所以典型，是因为它其实“看见”了更正，只是没有把它和最终计算连起来——这正是证据状态漂移的定义。LongHarness 因为在 10 个策略动作内把更正纳入证据并修订结论，最终返回了正确值。论文也诚实地指出，Codex 虽然没过精确匹配，却通过了 5% 容差，相对误差约 0.088%。这说明两层失败是分开的：检索和阅读可能都成功，失败只发生在“证据是否被采纳”这一层。

图 1：语料级长上下文推理中的证据生命周期管理。左图展示智能体丢失早先约束、继续搜索的情形，而 LongHarness 保留证据、用未解决的结论引导检索，并在新证据到来时修订决定；右图比较 GLM-5.3-Flash 下直接模型与各 harness 在 OfficeQA Pro V1 / V2 上的精确准确率。

交互回合的分布也值得对照看图。下图的核密度曲线显示，LongHarness 在 V1 到 V2 之间的分布移动很小，而 Claude Code 与 Codex 在 V2 上明显右移。论文把这种稳定性归因于显式的结论缺口和证据复用：问题越需要跨来源核对，结构化状态带来的收益越大。

图 3：GLM-5.3-Flash 在 OfficeQA Pro V1 与 V2 上每题模型回合数的分布。每个子图比较同一个 harness 在两个版本上的曲线，曲线为核密度估计，圆圈为中位数。

局限性

第一处局限由作者在实验设置里主动说明：受算力资源限制，主对比每个 harness、每个评测设置只运行一次，只有附录 D 用 GLM-5.3-Flash 做了三次重复并报告均值、标准差与最大值。这意味着主表里的若干差距没有配对的方差估计。附录的三次重复部分缓解了这一点——LongHarness 在 OfficeQA Pro V1 上三次得分 60.15、60.15、59.40，标准差仅 0.43；在 V2 上 61.11、58.89、58.89，标准差 1.28——但重复实验并未覆盖 Qwen3.8-Flash 与全部基准。

第二处局限是增益本身并不均匀。换到 Qwen3.8-Flash 后，LongHarness 在 OfficeQA Pro V2 上只比 Codex 高 1.1 个百分点，明显小于 GLM-5.3-Flash 上的 18.9 个百分点。论文据此明确写出“增益大小随主干和评测设置变化”。对读者来说，这提醒我们不能把某个主干上的大幅领先直接外推到所有模型。

第三处局限来自运行时契约本身。论文在附录 B.3 说明：交互历史被完整保留，客户端不自动截断或压缩，一旦某个请求在重试后仍因超出上下文长度而失败，就记为 model_request_failed 并终止该回合，未提交答案的回合按错误计。也就是说，随着历史增长，系统对单次请求的上下文长度越来越敏感。论文还指出两处更细的验证缺口：运行时只校验证据 ID 是否已注册、是否活动，compute 并不确认字面操作数是否与所引用的来源值一致；当证据被取代或撤回时，迁移日志会标记受影响的结论引用，但运行时不自动重写这些论断，也不阻止后续搜索与阅读。最后，证据流程审计用的是 GPT-5.6-Luna 加条件成功率，而不是穷尽式的因果证明，因此轨迹分析给出的是一致性解释而非因果定论。

总结与展望

LongHarness 的贡献不在于发明更复杂的检索器，而在于重新描述“长上下文推理”这件事：它把支撑一个决策的证据的构建与持续精炼，看作推理的核心过程。在这个视角下，检索、编辑、变换不再是三个孤立环节，而是同一份证据在不同阶段扮演不同角色的过程。方法层面，它用证据—结论共演化把探索和结论修订耦合起来，用证据生命周期管理保证证据时刻可追溯、可更新；实现层面，它只需要两个状态和一组受控操作，就能挂在不同的主干模型上。

实验结果支持这套设计：在约一亿 Token 和翻倍语料上，GLM-5.3-Flash 的精确匹配分别提升到 60.2% 和 61.1%；消融显示持久状态、结论引导检索和证据修订各自都有贡献，且替换成自由文本笔记会明显退化；轨迹分析表明它的优势主要落在“证据被采用并转化为答案”这一层，而不是单纯找得更多。论文也把边界留得很清楚：单次运行的主对比、随主干变化的增益、未压缩历史带来的上下文风险，以及运行时不校验字面操作数的缺口。对后续工作来说，最直接的几个方向是补齐多种子与跨主干的重复实验、在保持来源可追溯的前提下对历史做压缩、以及把“结论对失效证据的依赖”纳入自动维护。

金句

长上下文推理的难点，不在于一次能读进多少材料，而在于系统能否始终记得：哪些材料已经被读到，它们现在是否还成立，以及它们究竟支持了哪个结论。