1. 问题与动机

百万 token 级长文本理解（LTU）面临作者称为"LTU 三难困境"的张力：极致可扩展性、高保真信息保留与推理效率三者难以同时实现。前沿长上下文模型如 Gemini-3-Pro、GPT-5.1 端到端处理百万 token 时遭遇注意力稀释和计算量二次增长，token 成本随上下文长度呈数量级上升；而 GraphReader、ReadAgent、MemAgent 等专用长文本智能体则通过任务无关的预索引（图构建、记忆压缩）牺牲了保真度，在结构构建过程中丢失答案关键细节；传统 RAG 的 chunking 策略破坏全局连贯与长程依赖。

作者提出关键洞察：对给定 query，回答所需信息通常是文档中一个稀疏的「query-sufficient subset」。因此高效系统不应被动地处理整个上下文，而应主动「觅食」该最小子集。这一信息稀疏假设直接挑战了"上下文越长越好"的工业默认范式，并为 LTU 提供了新设计原则。

2. 方法详解

SCOUT 的核心架构创新是「状态解耦」：把 ReAct 风格的交互历史拆为两部分：

Procedural Trace ℋₜ：记录 Agent 在哪里探索（动作序列）。
Epistemic State ℰₜ：仅维护已被确立为 query 相关的知识。

硬性约束（公式 4）：最终答案的生成只能访问 ℰₜ，而不能访问完整的交互历史 ℋₜ。这一设计阻止了探索噪音污染推理过程，也使最终回答的「证据集」是审计闭包。

Epistemic State 表示：ℰₜ = {e₁, …, eₘₜ}，每个元素 eⱼ 是二元组 ⟨cⱼ, αⱼ⟩。cⱼ 是蒸馏后的原子陈述，αⱼ 是溯源锚点（指向文档具体位置）。这种 provenance-anchored 设计保证了任何用于推理的陈述都能追溯到源文本。

动作空间分为两类：

• 觅食动作 𝒜forage：Grep/Scan（词法级粗定位）、Read（局部精读，支持预算）。
• 状态管理动作 𝒜state：Update（提交 provenance-anchored 单元）、Evaluate（执行状态级 gap 诊断）、View（查看当前 ℰₜ）。

Gap Diagnosis 机制是 SCOUT 的"灵魂"：Evaluate 不是简单的"是否终止"启发式，而是在状态层面分析「为可靠回答 q 还缺什么」，输出明确的下一轮觅食目标。这驱动了迭代式的 diagnose-acquire-commit 循环直至 query 满足。

算法 1 推理流程：(a) 初始化空 ℋ 和 ℰ；(b) 在步数预算内：从策略 πθ(a|q, ℋₜ, ℰₜ) 采样动作；若是觅食动作则在文档上执行，ℰₜ 不变；若是状态管理动作则更新 ℰ 或诊断 gap；将动作及结果追加到 ℋ；(c) 当 gap 关闭或步数耗尽，仅基于 ℰₜ 生成答案。

训练设置：开源权重实验在 Qwen2.5-72B-Instruct 上做 60M optimization tokens 预算的 SFT，并对比 DAPO（policy gradient）变体；统一评估时所有对比方法（包括前沿大模型与现有 LTU agent）都用 Claude-Sonnet-4.5 作为统一 backbone 以保证公平。

3. 核心技术贡献

(1) 状态解耦的 LTU 范式：把"探索轨迹"与"已确认知识"显式分离，是首次把 LTU 形式化为「带可读 epistemic state 的 POMDP」式问题。比单纯的 ReAct（动作历史不区分价值）更结构化，比 GraphRAG（先建索引再查）更动态。机制本质：阻断噪声反向通道，让最终生成只面对一个干净、紧凑、可审计的证据集。

(2) Provenance-Anchored 知识单元：每个 epistemic 单元都带溯源锚 αⱼ，使下游推理具备可解释性与可校验性，是工业可部署的关键 — 在线诊断时可直接定位"哪个片段支撑了这个回答"。

(3) State-Level Gap Diagnosis：把"下一步去哪儿觅食"从动作级（动作选择即决策）抽离到状态级（先诊断缺什么、再决定如何获取），相比 ReAct 的隐式 reasoning，更易做离线 reward 设计与监督蒸馏。

(4) 训练-时-架构协同：开源 SFT 大幅超过 LLM-only SFT（LooGLE-v2 上 +27.1% vs +1.2%），表明 LTU 瓶颈不是参数化知识而是长程交互与状态控制能力，这是 RL/SFT 时代的新发现。

4. 实验结果分析

主表 1（LooGLE-v2 + ∞Bench）：

SCOUT 同时取得最高准确率和最低 token 成本，在 LooGLE-v2 上 token 效率（Acc/Cost）2.63、∞Bench 上 4.01，分别是 Gemini-3-Pro 的约 8× 提升。

Scaling 鲁棒性（Figure 3）：把上下文从 64K 拉到 1M+，前沿单体模型在 256K 之后准确率骤降（"long-horizon breakdown"），token 成本指数级增长；SCOUT 的准确率与 token 成本几乎保持平稳。

消融（Table 2，LooGLE-v2）：

• 完整 SCOUT：78.2%
• 去 ℰₜ（退化为 ReAct-style）：70.5%（-7.7%）— 证明状态解耦本身的价值
• 去觅食动作（只剩 epistemic 操作）：17.7%（-60.5%）— 觅食是不可或缺的"输入"
• 去文件工具：74.2%（-4.0%）
• 去 grounding（去除 αⱼ）：75.5%（-2.7%）— 溯源带来稳定增益

最关键的消融是「去 ℰₜ」与「去 grounding」：它们共同证明 SCOUT 的两层设计（解耦状态 + 溯源锚）都是有贡献的，单独砍掉任一部分都会显著下降。

开源训练增益（Table 3）：在 Qwen2.5-72B-Instruct 上 60M token 预算下 SFT，LLM-only 几乎不动（LooGLE-v2 +1.2%、∞Bench -0.7%），而 SCOUT-SFT 分别 +27.1% / +25.1%。这是非常强的证据，说明同样训练预算下，SCOUT 提供的结构化交互范式才是开源模型 LTU 能力的关键瓶颈。

5. 局限与未来方向

作者明确承认三点：

(1) 单 query wall-clock latency 较高：SCOUT 多步交互比单次端到端推理在 wall-clock 上更慢（虽然 token cost 更低）；并行觅食优化是未来工作。这对线上低延迟场景（如社区搜索 P99 <500ms）是硬约束。

(2) 跨 query 复用缺失：每个 query 独立处理同一文档，没有摊销预处理。对于"同一长文档被多个 query 反复访问"的场景（如客服 FAQ、产品手册问答），SCOUT 不如索引式方法经济。

(3) 评测局限：仅在文本、信息稀疏的长文档上验证；信息密集（如代码评审、密集表格）和多模态长文档（图文交错）的场景未覆盖。

显见但未点出的局限：策略 πθ 在工业部署时仍依赖 SOTA 闭源大模型作 backbone，开源 72B 虽然能 SFT 到接近，但训练 60M token 的成本依然不低；线上"主动觅食"还可能因外部检索 API 延迟波动而方差较大。

6. 工业实践意义

对搜索/推荐 Agent 团队的具体启示：

(1) 长帖子/长问答 RAG 的范式重塑：社区平台普遍存在长帖、专栏、专业问答这类 5K-50K token 的内容。直接全文喂给 LLM 不仅贵且容易稀释。SCOUT 的「主动觅食 + epistemic state」范式可以直接照搬：让搜索 Agent 用 Grep/Read/Update/Evaluate 这套动作集围绕用户 query 在长帖中觅食，输出带溯源的精炼证据集。落地路径上，可从 Claude/Qwen 这类支持 tool-use 的模型起步，先用 prompt-engineering 实现 SCOUT 风格 ReAct 循环，验证后再做 SFT。

(2) Epistemic State 作为可审计原语：把"模型已知什么"显式化为带溯源的结构化状态，对线上诊断与 reward 设计是关键改进。建议搜索 Agent 在每步显式输出 ⟨陈述, 文档锚点⟩ 二元组，便于线下评估"哪个证据导致回答正确/错误"，也便于做 process reward。

(3) 不必用最大上下文模型：实验显示 SCOUT 在 Claude-Sonnet-4.5 上即可达成 SOTA，且 token 成本下降 8 倍。对于成本敏感的搜索场景（社区每日 query 数千万级），这个换算下来是巨大的推理预算节省。

(4) 对开源 backbone 的启示：72B 模型 LLM-only SFT 几乎没收益，而 SCOUT-SFT +27.1%。这意味着对于自研搜索 LLM 的团队，「先把 Agent 框架定好、再用 SFT/RL 让模型适应该框架」比「单纯增大数据量做指令微调」更有效。

(5) 部署考虑：多步交互意味着 P99 latency 高于单次推理，这对在线场景需要并行化（多步骤同时尝试不同动作）或离线预计算（针对热门长文档先 forage 出常见 query 的 ℰₜ）。后者实际上是把 SCOUT 与索引式方法结合的混合范式，可能是下一步工程价值最高的方向。