10 月 15 日，一篇题为 Librarian Agents 的论文挂上 arXiv（编号 2610.22273），六位作者是 Anikait Singh、Teresa Zhang、Yoonho Lee、Roshen Sanjay Nair、Aviral Kumar 与 Chelsea Finn。论文针对的是深研究智能体的老问题：语料越长、越散，检索就越像救火——问题到了才满世界找证据。作者的提议是换个时序：让一个 builder 智能体先把原始语料改造成一座分层工作区，再交给一个冻结不动的 answering 智能体应付后来的所有提问。论文把这称为「预期性定向整理」：在推理发生之前，就把无结构语料提前重组，去服务一族还没问出来的问题。
builder 与 answering：一个可训练，一个冻结
框架是双智能体结构。builder 读原始文档，产出由合成摘要文件、高层归并文件和指回原文的引用链接组成的分层文件系统——这套工作区不是通用索引，而是为下游答题智能体量身搭的。answering 智能体参数冻结、不参与训练，只在查询到来时遍历工作区、找证据、作答。训练的矛头只对准 builder：论文把「建工作区」形式化为马尔可夫决策过程，用强化学习优化 builder 策略，奖励直接接下游答题准确率——摘要写得好不好看不要紧，下游答得对不对才算数；部分配置里构建成本也进惩罚项。作者点出一个观察到的结构性不对称：现代智能体 harness（论文举了 Claude Code 为例）里的模型很会在现成文件系统里干活，却几乎没被训练过「为将来的使用搭建可复用工作区」。Librarian Agents 补的正是这一课。
数字：33 个点与 31 个点的来历
结果集中在两个长文档推理基准。BrowseComp-Plus（深研究网页任务集）上，训练后的 Librarian Agents 超出作者实验里表现好的检索与预计算基线 33 个百分点；BRIGHT（覆盖数学、生物等多领域）上，只用 BrowseComp-Plus 类数据训练出来的 builder 零样本迁移，平均准确率再抬约 31 个点。成本账要摊开算：BrowseComp-Plus 的几轮运行里，builder 为每个语料生成约 17.9 万 token 的合成内容——这笔钱在构建时一次性付出，靠后续反复提问摊销。论文与作者转述都把「摊销」当作方法成立的前提之一，而不是附注。
为什么这条路线值得单独看
把计算从推理时挪到构建时，今年在站内已经出现过两个变体，可以并排读。1949 的 Anchor Action Index 是动作层版本：跑成功的工作流固化成确定性代码，下次直接回放，成本降到零头；Librarian Agents 是语料层版本：读过的文档先归好类，证据检索从「现场救火」变成「按图查骥」。两者共用同一个经济学——一次性的推理成本沉淀成可复用资产。差异在沉淀的介质：动作层沉淀为代码，语料层沉淀为带引用链接的摘要层级。对反复追问同一批文档的场景（企业知识库、案件卷宗、长期课题），后者的摊销故事更顺；对一次性的深研究任务，反而要先亏一笔。
三盆该浇的冷水
论文与同行转述都留了余地，值得照抄。其一，评测全部是静态语料上的问答：文档频繁变动的场景里，工作区的维护与更新是新的工程题，「先建后用」可能变成「天天重建」。其二，预计算只在「同一批文档被反复问」时摊薄；一次性的深研究任务，17.9 万 token 的前置投入是净亏。其三，摘要天生可能吞掉稀有但关键的细节——工作区保留了指回原文的链接，answering 智能体可以顺链接回原文取证，但「何时该绕过摘要」这个问题论文没有回答。builder 自身要对大上下文推理，语料规模再上一个量级时的表现也是开放题。代码与项目网站已随论文发布，复现门槛不高。
站点这条线的旧账：1953 拆过 HTN-Orchestrate 的两层任务分解，1955 给智能体挂过活时钟，1969 的 TRACER 在压缩工具可见性。Librarian Agents 补的是同一张成本表上的另一格：当深研究的账单主要花在「反复读同一批文档」上时，提前整理可能是比「想得更快」更便宜的解法。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。