Agent渐进式披露买的不是智能而是上下文：港大等首测揭示深度陷阱
Is Progressive Disclosure All You Need for Long-Context Agents?
在处理超长文档问答时，大模型开发者长期面临着两难抉择：要么赌上高昂的成本与“大海捞针”能力的衰减，把整本文档塞进上下文窗口；要么给系统外挂一套向量数据库，依赖预切分的文本块和检索重排流程。随着自主智能体（Agent）范式的演进，以 Claude Code 为代表的新一代开发工具开辟了一条折中道路：系统不再预设复杂的外部检索管道，而是直接把项目代码或文档路径交给 Agent，让模型自己决定何时翻阅目录、何时调用搜索、何时读取具体内容。
ArXiv URL：https://arxiv.org/abs/2607.17598v1
支撑这一范式的关键机制正是“渐进式披露”（Progressive Disclosure）。通过将领域知识或长文本打包为符合 Agent Skills 规范的目录与结构化标记（例如 SKILL.md），Agent 可以仅凭常驻上下文中的简短描述判断任务意图，在匹配后再按需展开详细索引并加载具体章节。尽管工程社区对这种做法报以极高的热情，甚至试图用它彻底替代传统 RAG，但此前从未有严格的受控实验验证过它的真实边界。
来自香港大学、加州大学戴维斯分校与浙江大学的研究团队在最新论文中给出了首个系统性解答。他们搭建了交互式基准测试环境 LoongDoc，在包含多款模型与 Agent 框架的严格对照下发现：渐进式披露并非通向更高智能的通用钥匙，它本质上是用路由流程换取上下文空间；在单篇文档场景中，它的增益完全取决于 Agent 原生导航能力的高低；更关键的是，递归嵌套的“多层深层路由”不仅没有带来任何收益，反而频繁导致路由上下文饱和、准确率骤降。这一发现为当下狂热的 Agent 架构设计泼了一盆清醒的冷水。
拆解三种路径：当长文档化身为 Agent 技能
要把一本数十万字的长篇书籍交给 Agent 解答，工程上有多种不同的组织形态。以往的经验分享往往将文件切分颗粒度、目录索引存放位置与递归深度混为一谈。为了做严格的变量隔离，研究团队在固定的分块集合（以书籍原生章节或 4000 词自然段切分并生成 LLM 摘要）之上，规范化梳理了 Agent 探索长文档的三种典型路径。
第一种是裸文档直接导航（raw）。Agent 面对的是沙盒环境中的原始完整文本，环境不提供任何辅助的技能包装。模型必须完全依赖自身的工具调用策略——例如先用命令行全局搜索特定实体，再定向读取匹配行上下文，或者直接尝试打开大段文本。这是衡量辅助架构是否有实际价值的原始基准线。
第二种是单层扁平式披露（flat）。整本书被封装为一个独立的 Agent Skill，入口为一个根目录下的 SKILL.md 文件。该文件包含两个层级的信息：处于头部的一小段全书描述常驻于 Agent 的上下文窗口中，负责在“发现”（Discovery）阶段让模型意识到本书与当前问题相关；正文部分则是一张详尽的章节索引表，记录着各个切片文件的路径与内容摘要。只有当模型在第一步决定激活该技能时，才会读取 SKILL.md 的正文表格，进而根据表格中的摘要定向打开具体的切片文件进行精读。
第三种是递归层级式披露（hierarchical）。这种设计将渐进式理念推向极致：每一个文本切片本身都被包装成一个独立的子技能，拥有自己的简短描述；在所有子技能之上，由一个顶层的元路由器（Meta-router）负责统筹调度。在发现阶段，元路由器的描述与所有子技能的描述同时常驻在 Agent 的上下文中。模型直接比对各个子技能描述并触发阅读，省去了读取扁平总表的中转步骤。
这两种披露方案在物理结构上共享同一套文本切片与摘要描述，核心分歧仅在于系统为“渐进”所支付的上下文代价：扁平模式把切片级别的索引推迟到技能激活之后按需加载；层级模式则试图通过常驻全部子技能摘要来减少阅读步数，却在未启动任务时就预先占用了注意力资源。
从静态基准到交互沙盒：LoongDoc 环境的设立
传统长文本评测基准通常是静态的：给模型输入提示词和拼接后的全文，要求输出答案字符串。这种黑盒评估无法观察 Agent 是如何阅读文档的，更无法模拟技能文件的发现、加载与交互过程。
为此，研究团队基于开源 Agent 评估体系 BenchFlow，将长文本评测集 $\infty$Bench 重构为支持 Agent 客户端协议（ACP）的交互式沙盒环境 LoongDoc。在 LoongDoc 中，每一个问答样本都变成了一个独立运行的文件系统任务。Agent 既可以使用 Codex、Pi 或 Claude-Code 等不同的底层调度框架，也可以自主执行读取、搜索、打开文件等系统调用。
这种设计使得整个评估不仅能记录模型最终回答的准确性，还能以轨迹日志的形式完整复现模型在阅读长文本时的每一步决策：它到底检索了哪些关键词？翻开了哪些文件？每一步消耗了多少 Token？通过这种细粒度的轨迹追踪，研究者得以穿透表面分数，解释不同架构之所以胜出或失败的内部机理。
单书问答评测：收益取决于 Agent 原生工具策略
在单本长篇书籍的问答任务中，包含英文多项选择题（En.MC）、英文自由问答（En.QA）以及中文自由问答（Zh.QA）的多组实验揭示出极具戏剧性的结果。渐进式披露到底能不能带来提升，并不取决于文档本身，而是高度取决于承载模型的 Agent 工具链。
在工具调用策略相对基础的框架（如 Pi 和 Claude-Code）下，单层扁平披露展现出了明确的优势。例如在搭载 gpt-5.4-mini 的 Pi 框架中，扁平披露将英文选择题准确率从裸文档导航的 $0.8851$ 提升到了 $0.9126$；在搭载 claude-haiku-4.5 的 Claude-Code 框架中，选择题表现更是从裸文档的 $0.7448$ 跃升至 $0.8667$。原因在于这些框架下的模型在面对几十万字的裸文档时，往往无法稳定构建多步骤检索链条，容易在盲目滚动或局部猜测中丢失线索，而扁平技能包提供的章节索引恰好充当了可靠的导航信标。
然而，当测试切换到以工程能力著称的 Codex 框架时，情况发生了逆转。无论使用裸文档还是单层扁平技能包，Codex 在 gpt-5.4-mini 驱动下的英文选择题得分均为 $0.89$ 左右，英文问答也稳定在 $0.74$ 至 $0.75$ 的狭窄区间，渐进式披露带来的性能增益几乎为零。
翻看 Codex 的交互轨迹日志后，这一现象得到了合理的解释：面对未做任何处理的纯文本文件，Codex 根本没有从头到尾线性阅读，而是自主分析提问中所包含的专有名词和实体关系，主动在沙盒终端内构造精准的 grep 命令搜索全文，并且只定向拉取匹配行周围的特定上下文。换句话说，一个足够成熟的 Agent 自身就具备按需检索、动态定位的能力，它在运行时现场重构了检索链路，因而预先固化在文件系统中的章节摘要表格自然无法提供额外的增量精度。
此外，与经典的外部检索增强（Hybrid-RAG）对比，结构化技能文件显现出了独特的组织优势。在多组测试中，传统的切块-检索-重排工作流得分普遍落后于扁平技能包与高效的裸文档导航。静态向量匹配容易割裂长文档的章节脉络，而在文件系统层面上保留目录树与章节语义摘要，更有助于模型结合宏观布局寻找证据。
深度陷阱：为什么深层递归路由会彻底溃败？
在 Agent 技能的设计哲学中，许多开发者直觉地认为：既然单层按需披露有效，那么将知识库进一步细化、构建成类似树状多叉目录的“递归子技能包”，理应能够让筛选更加精准。但实验数据给这一设想带来了近乎毁灭性的打击。
在单本书籍场景下，层级式披露（hierarchical）在绝大多数配置中均落后于单层扁平披露，甚至引发灾难性的性能暴跌。在 Pi 框架搭配 gpt-5.4-mini 的实验中，层级式披露让英文选择题准确率从扁平披露的 $0.9126$ 直线下滑到 $0.6398$，滑落幅度超过 27 个百分点；在搭配 qwen3.6-27b 的中文问答中，层级模式更是从 $0.7479$ 跌落至 $0.3890$。
导致这一崩溃的核心诱因在于注意力的上下文污染与决策过载。层级式披露虽然在形式上省去了打开总目录表格的动作，但为了让元路由器具备分支调度能力，它必须将底层数十个甚至上百个切片子技能的摘要描述全部一次性加载到常驻上下文（discovery）中。这不仅没有减轻长上下文的负担，反而把大量分散、相似度极高的局部切片描述塞满了模型的即时工作区。
当一个提问到来时，顶层的元路由器被迫在数十个高度重叠的子技能摘要中做概率选择。大量并存的碎片化描述相互干扰，导致模型在最初的路由分发阶段就高频误判，直接选错了子技能目录；一旦在顶层路由迷失方向，后续无论切片内容多么详尽，都再也无法找回正确的答案。相比之下，扁平披露在常驻上下文中仅保留一个整书层级的抽象介绍，路由逻辑极其单一，进入书籍后再在正文表格中逐行扫描候选章节，注意力分配反而更加聚焦与鲁棒。多层嵌套不仅增加了交互的脆弱性，还透支了模型的上下文带宽。
藏书馆扩展：从单篇长文走向海量全集
如果说在单文档场景下，强 Agent 凭借自主文本搜索尚能与渐进式披露打成平手，那么当语料规模进一步膨胀时，体系设计的优劣便迎来了分水岭。
研究团队通过向 LoongDoc 环境中不断注入更多书籍，将任务难度从 $K=1$ 逐步推进至 $K=5$、$K=10$ 乃至 $K=20$ 本书的“藏书馆规模”（Library Scale）。在这些测试中，提问往往只针对其中某一本书的具体细节展开，Agent 必须先在浩如烟海的磁盘文件中准确定位目标文档，进而才能展开精细阅读。
实验数据显示，随着书籍数量上升，所有方案的绝对准确率和阅读效率都不可避免地下滑，但裸文档直接导航崩溃的速度远超结构化披露方案。在 Codex 框架下，面对单本书时表现极其出色的裸文档导航，在扩展至 20 本书（$K=20$）的环境中全面失守，英文自由问答的准确率直接从原先的高位跳水至 $0.257$。面对包含上千个文件或数百万行字符的复杂目录体系，即使是擅长使用 grep 的成熟 Agent，也会在海量返回的实体匹配项中迷失，导致上下文被无关代码和文字刷屏，甚至耗尽交互步数配额。
此时，单层扁平式披露构筑起了关键的防线。同样是在 $K=20$ 的极限压力下，基于单层技能包的 Agent 能够将英文问答成绩稳定在 $0.462$。顶层精炼的技能描述使得 Agent 能够在极短的时间内完成跨书筛选，将无关书籍排除在后续行动之外，从而保护了核心推理区域免受海量噪声的冲击。
这也印证了研究的核心论断：渐进式披露的核心价值不在于向模型注入更强的逻辑推理或跨文档理解力，而在于充当一种高鲁棒性的上下文隔离机制。当信息总量超出单次搜索所能消化的临界点时，良好的渐进式包装为 Agent 保留了生存空间。
实践启示：长文档 Agent 的工程边界
这一系列受控对照实验推翻了许多流传于社区的直觉经验，也为后续开发面向长文档、技术文档库或复杂企业代码库的 Agent 系统确立了明确的技术边界。
首先，不要迷信复杂的深层树状技能结构。很多架构师热衷于设计“根技能—领域技能—子章节技能—段落技能”的多层递归目录，认为这种分形结构兼具优雅与效率。然而实测表明，在 Agent 处理文档理解时，单层索引是性价比最高、错误率最低的黄金分割点。增加路由层级只会成倍推高元决策失败的风险，除非单个扁平索引文件的大小已经突破了单次读取的物理上限，否则绝无必要引入第二层路由。
其次，架构设计必须审视底层 Agent 的固有能力。如果你的系统底层调用的是通用且原生指令跟随较弱的模型，或者 Agent 缺乏成熟的代码执行与正则搜索工具，那么为文档预制高质量的章节切片与摘要索引，能够带来立竿见影的收益；但如果你使用的是擅长自主拆解问题、能够编写精确脚本定向探索文件系统的顶级代码模型，那么在单文档任务上耗费大量算力去离线生成精细的技能包，很可能只是在重复建设。
最后，认清上下文管理的本质。将海量文档转化为 Agent 能够阅读的形式，并不等同于解决了长程推理难题。渐进式披露并没有改变底座模型的理解上限，它所做的只是在最前端压低噪声输入，用时间成本（多轮工具交互）换取空间成本（窗口 Token）。随着未来大模型上下文窗口的持续扩展和成本下探，寻找 Agent 自主导航、轻量级扁平披露与端到端注意力之间的动态平衡点，依然是长文本工程演进的核心命题。