当检索不再是终点，而是 Agent 手里的一把铲子：DR-DCI 把"工作区"做活了

上个月在帮一个团队调 agentic search 的时候，碰到一个特别拧巴的现象。

我们给 agent 接了一套 BM25 检索接口，让它去一个几百万文档的语料里找答案。单纯的"问一个问题、返回 top-k"这种它做得挺好。可一旦遇到需要跨文档比对、需要排除假阳性、需要顺着一个桥接实体往下挖的复杂问题，它就开始抓瞎——因为检索器只把证据当成"排好序的结果列表"丢给它，agent 没法重新组织材料，也没法在多个文档之间做约束验证。

后来有人说，那干脆别用检索器了，直接让 agent 在语料库上敲 grep、rg、find 不就行了？这思路其实就是所谓的 DCI（Direct Corpus Interaction，直接语料交互）。听起来很美——agent 像个老练的工程师在终端里翻文件。但真上规模你就知道有多疼：语料一大，全语料的终端命令慢得离谱，动不动就触发工具超时，宽泛搜索返回一堆垃圾，狭窄搜索又漏证据。

这篇 arXiv 上的新论文（arXiv ID：2606.14885）恰好就盯着这个矛盾下手。它给出的方案我看完之后觉得挺漂亮的——不是二选一，而是把检索器变成 agent 手里的一把"铲子"。

核心摘要

大规模语料上的 agentic search，长期卡在一个两难里：用检索器（BM25 / ColBERT）扩展性好但 agent 只能看到排好序的结果，没法灵活重组和验证证据；让 agent 直接在终端里操作语料（DCI）灵活精确，但语料一大就慢到崩、超时频发。

DR-DCI 的思路是把这两者缝合起来：把检索做成一个 agent 可以主动调用的动作 pull，用它把相关文档动态地"拉"进一个本地工作区，然后 agent 在这个小工作区里照样用 rg、grep、read 这些 DCI 工具精细操作。检索负责"可扩展地把范围缩小"，DCI 负责"在缩小后的范围里精确求证"。

效果很能打：在 BrowseComp-Plus 上准确率 71.2%，比裸 DCI 高 8.3 个点，同时工具调用、墙钟时间、成本全都降了——墙钟从 3139 秒掉到 146 秒，成本从 88 美元降到 35 美元。加上一个"保留工作区的上下文重置"技巧后进一步到 73.3%。语料从 10 万扩到 1000 万文档，DR-DCI 依然稳，而裸 DCI 直接失控、BM25 明显落后。

说实话，这篇论文最值钱的地方不在某个单点技术，而在它对"检索器该扮演什么角色"这个问题的重新定位。我们下面慢慢聊。

论文信息

• 标题：DR-DCI: Scaling Direct Corpus Interaction via Dynamic Workspace Expansion
• 作者：Yi Lu, Zhuofeng Li, Ping Nie, Haoxiang Zhang, Yuyu Zhang, Kai Zou, Wenhu Chen, Jimmy Lin, Dongfu Jiang, Yu Zhang
• arXiv：2606.14885（提交于 2026/06/12）
• 链接：https://arxiv.org/abs/2606.14885

作者阵容里有 Jimmy Lin 和 Wenhu Chen 这种在 IR 和检索增强领域很有分量的名字，所以这篇在检索这块的判断我倾向于先信几分，再用实验去验。

先把问题讲透：检索器和终端，到底各自烂在哪

要理解 DR-DCI 为什么这么设计，得先搞清楚它针对的两条现有路线各自的死穴。

第一条路：检索器中介的接口（BM25、ColBERT 这类）。它的好处毋庸置疑——索引建好之后，候选发现是可扩展的，几百万文档也能秒级返回 top-k。但问题在于，它把证据"封装"成了排好序的结果或者有边界的文档视图。agent 看到的永远是检索器替它"消化"过的东西。它没法说"把这 200 篇文档里所有提到 X 但不提到 Y 的找出来"，也没法在文档之间做横向比对。证据的组织权不在 agent 手里。

第二条路：DCI，直接语料交互。这条路把语料库当成一个文件系统，让 agent 用 rg、grep、find、read、cat 这些终端命令直接操作。它给了 agent 对证据的细粒度控制：任意粒度搜索、组合词法约束、跟踪桥接实体、比较文档、验证精确证据片段。这种灵活性是检索器接口给不了的。

但这条路有个致命的扩展性问题。论文里有句话我觉得点得特别准：DCI 的瓶颈不是局部精度，而是缺乏可扩展的、聚焦式的语料级探索机制。当语料涨到几百万文档，全语料的终端命令开始疯狂触发 30 秒工具超时，宽泛搜索返回海量无关匹配把上下文撑爆，狭窄搜索在没有全局指引的情况下又会漏掉证据。它不是"算错了"，是"根本跑不动"。

你看，一个有扩展性没控制力，一个有控制力没扩展性。DR-DCI 的核心问题就变成了：能不能让 agent 既享受检索器的召回扩展性，又保留 DCI 的局部操作精度？

方法核心：把检索变成一个动作

DR-DCI 的答案，一张图就能讲明白。

图1：DR-DCI 整体框架。检索被暴露成一个 agent 可调用的动作，用来扩展本地工作区。Agent 动态地把排好序的文档 pull 进这个不断演化的工作区，然后用 DCI 工具去调查、验证这些已经"物化"到本地的证据。整个循环里，Dynamic Pull 负责从海量语料里捞东西进来，DCI 负责在工作区里精细操作，两者在 Agentic Reasoning Loop 里交替进行。

我第一次看到这张图的时候，最打动我的是中间那个 Materialized Workspace（物化工作区）。这是整个设计的支点。

传统做法里，检索结果是"看一眼就过"的——agent 拿到 top-k 片段，读完就没了。DR-DCI 不一样：它把检索到的文档真的"落地"成本地工作区里的文件。agent 不再是在全语料上瞎敲命令，而是在这个几百到一千多篇文档的小工作区里操作。范围小了，rg、grep 就快了，也不会超时了。

具体怎么运转？论文把它形式化成一个循环。固定一个隐藏语料 \(\mathcal{C} = \{d_1, ..., d_N\}\)，给定问题 \(q\)，agent 维护一个查询专属的工作区 \(\mathcal{W}_t \subseteq \mathcal{C}\)。每一轮 agent 可以三选一：

1. 扩展工作区 —— 调用 pull，把新文档拉进来；
2. 调查文档 —— 用终端式 DCI 工具检查已经物化的文档；
3. 收尾 —— 一旦证据够了、验证过了，就给出答案。

pull：agent 唯一需要关心的检索接口

pull 的接口极简：pull(query, topK)。agent 只需要指定"我想搜什么"和"想要多少篇"，剩下的访问隐藏语料、去重、把文档物化到工作区，全由 harness 在底层处理。

形式化地说，第 \(t\) 轮给定查询 \(r_t\) 和检索预算 \(k_t\)：

工具返回三样东西：新增的文档 \(\Delta\mathcal{W}_t\)（构造上保证跟已有工作区不重复）、一个紧凑的排序预览 \(\mathcal{P}_t\)、以及工作区统计 \(\mathcal{S}_t\)。

这里有个细节我觉得很关键：排序预览只是个导航信号，它不替代证据检查。换句话说，agent 不能光看预览就拍板答案，必须老老实实在工作区里用 DCI 工具搜索、阅读、验证。这个设计约束后面消融实验会证明它的价值。

工作区里的两种 DCI

文档拉进来之后，agent 在工作区里干两类活：

• 跨文档 DCI（Inter-document）：用 rg、grep、find、ls 在多篇文档间搜索、比对，做横向探索、组合约束、跟踪桥接实体、排除假阳性。
• 文档内 DCI（Intra-document）：用 read 配合行偏移、字符窗口或单文件搜索，钻进单篇文档定位精确的证据片段。

你看图1左下角那个紫色终端框里的命令，就是这套操作的真实样子：rg "keyword" workspace/、grep -R "entity"、read file.txt --offset 120。这跟一个真人工程师在本地代码库里查东西的姿势一模一样，只不过对象换成了检索拉进来的文档。

工作区保留式上下文重置：一个挺聪明的补丁

论文还提了一个我觉得很务实的技巧。长轨迹里经常出现这种情况：工作区里其实已经有了有用的证据，但 agent 的推理上下文已经被早期的错误线索、过度承诺的假设带跑偏了，最后给出一个"我证据不足、弃答"的结论。

DR-DCI 的处理是把检索状态和推理上下文解耦。当轨迹落入预定义的高风险条件时，系统保留工作区 \(\mathcal{W}_t\)，但丢掉推理历史 \(h_t\)，然后实例化一个全新的 raw DCI agent，在保留下来的工作区上重新推导答案：

触发条件设得很保守——在 BrowseComp-Plus 上，只有当原轨迹置信度 ≤ 70 且最终响应明确表示弃答或证据缺失时才触发。这个保守设计是有意为之，避免它退化成一个"反正答错就重试"的通用作弊机制。

说实话这个补丁我挺喜欢的，因为它承认了一个现实：好东西已经捞到工作区里了，错的只是脑子。那就保留干活的成果，重置脑子。这个区分很本质。

实验：数字确实漂亮，但我们逐项看

主结果：71.2% 与降本增效

在完整的 830 条 query 的 BrowseComp-Plus 上：

这个表我看了好几遍。准确率涨 8.3 个点是一回事，真正让我觉得"对，就该这样"的是后面那几列——墙钟时间从 3139 秒掉到 146 秒，差了 20 多倍；成本从 88 美元降到 35 美元。这不是"用更多算力换更高分"的常见套路，而是又快又便宜还更准。原因也很直白：裸 DCI 在全语料上敲命令，单条 query 平均工具时间高达 1754 秒，单个工具调用最大耗时甚至到了 24418 秒（这数字有点离谱，应该是某些命令彻底卡死了）；而 DR-DCI 在小工作区里操作，自然快得多。

加上下文重置后到 73.25%。论文 Appendix 里给了它的成本账：触发桶里有 49 个案例，重置前正确数是 0/49（全都弃答了），但这些案例的工作区 Gold Recall 有 52.3%——也就是说证据其实在工作区里躺着呢。上下文隔离重置硬是从这 49 个里救回了 17 个正确答案，把全集从 591/830 推到 608/830，额外总成本只花了 4.44 美元。这笔买卖划算。

图2：在完整 BrowseComp-Plus 上的准确率与估计总成本（成本用对数刻度）。"CR"表示上下文重置。外部模型结果作为参考点标出。可以看到 DR-DCI 在成本-准确率的权衡曲线上明显占优——既比 Raw-DCI 准，成本还低了一大截。

语料扩展：这才是真正的考验

主结果好看，但 agentic search 真正的命门在于"语料一大还撑不撑得住"。论文做了一组很硬核的受控扩展实验：从 BrowseComp-Plus 的 10 万文档语料起步，往里灌随机采样的 FineWeb 网页当干扰文档，问题和黄金证据保持不变，看三种接口随语料增大的表现。

图3：在 BCP-100 上对比 DR-DCI、Raw-DCI 和 BM25 基线随语料规模变化的准确率、工具超时率、总成本和墙钟时间。Raw-DCI 超出可测量范围的部分用外推线表示其趋势——因为它后面根本跑不完。

数字摆出来就很说明问题了（节选自 Table 12）：

裸 DCI 的崩溃方式特别典型：200K 时工具错误率就飙到 35.9%，400K 直接腰斩到 32 分，再往上完整评估就跑不完了。论文说得很准——它的失败是操作性的，而非推理性的。不是脑子不行，是命令在全语料上根本执行不下去。

反观 DR-DCI，语料涨了 100 倍（100K → 10M），准确率只从 80 优雅退化到 70，工作区始终维持在大约 1K–1.4K 文档，工具错误率一直压在低位，成本稳稳地在 4–5 美元区间。这个稳定性是真的能打。

至于 BM25 search-only？它倒是不会出文件系统级的崩溃（毕竟有索引、返回有界片段），但分数明显低一档——100K 时只有 38/100，因为 agent 只能看到 top 片段，碰不到物化文档，也做不了局部 DCI 操作。这恰恰反向印证了"把文档真正落地到工作区"这件事的价值。

20M 规模的 Wiki-18 QA：跟训练过的搜索 agent 掰手腕

论文还把 DR-DCI 推到了一个 20M 文档、文件级（每个文档一个文件）的 Wiki-18 QA 设置，在六个 QA 基准上跟一票专门训练的搜索 agent 比：

平均 63.0，比最强的训练基线 ASearcher-Local-14B 高出 10 个点以上。我特别留意了 MuSiQue 那一列——这是公认最难的多跳组合数据集，几乎所有基线都在 4–32 分挣扎，DR-DCI 拿到 44。这其实暴露了 DR-DCI 的真实优势所在：越是需要跨文档拼线索的组合型问题，"把相关文档拉进工作区再横向比对"的玩法越吃香。

论文的检索行为统计也佐证了这一点（Table 7）：单跳/实体型数据集（NQ、TriviaQA）通常少于 2 次 pull，工作区约 570–650 文档；而组合多跳的 2Wiki、MuSiQue 会触发更多 pull，工作区扩到约 990–1100 文档。agent 是真的根据问题难度在动态调整拉取行为，不是死板地拉固定数量。

不过这里我得提个醒：DR-DCI 用的是 GPT-5.4 Nano 这种闭源强模型 + 无训练的 prompting 方案，而 R1-Searcher、Search-R1 这些是 7B/14B/32B 的开源训练模型。这个对比严格说不完全对等——一边是强基座 + 巧妙框架，一边是中等规模 + 端到端训练。DR-DCI 赢了，但赢的有多少来自框架设计、有多少来自基座本身的强，论文没有完全拆开。如果能补一个"同基座下 DR-DCI vs raw prompting"的对照会更有说服力。

消融：哪些设计是真有用的

这篇的消融做得相当扎实，我挑几个关键的说。

静态 vs 动态工作区（Table 3）。一个很自然的质疑是：你 DR-DCI 涨分会不会只是因为检索了更大的候选集？论文用 Single Pull（开局一次性拉 topK=500 冻住）对比 Dynamic Pull（推理过程中动态扩展）：

动态版本不仅准确率更高，工具调用、墙钟、成本还全面更低。论文的结论很到位：增益不是来自检索更大的候选集，而是来自把检索暴露成 agent 可调用的工作区扩展动作。这就把"靠堆候选集刷分"的质疑挡回去了。

跨文档 DCI（Table 5）。这个消融的结果最戏剧化：

把跨文档搜索一阻断，准确率从 82 直接砸到 40，腰斩还不止。而且 agent 开始拼命多拉文档（pull 从 3.49 次涨到 20.5 次）想要补偿，但补不回来。这条彻底排除了"DR-DCI 不过是个排序预览阅读器"的解释——它真正的价值在于让 agent 能在物化文档之间做横向操作。

排序预览（Table 4）。Ranked Top-20（82/100）> Shuffled Top-20（76/100）> Hidden Preview（72/100）。可见暴露候选有助于启动局部搜索，而可靠的排序进一步帮 agent 把注意力导向工作区里有希望的区域。打乱排序就掉 6 个点，说明排序信号本身是有用的。

工作区组织（Table 15），这个我觉得最反直觉，也最有嚼头。论文试了好几种工作区的组织方式：

注意看：Rank-aware folders（按排序建文件夹）的工作区召回率最高（Gold R@W 0.8541），但最终准确率反而最低（75/100）。最朴素的 root-flat（所有文档平铺在根目录，排序信息通过工具反馈而非文件路径暴露）反而拿了最高分。

更高的工作区召回，并不等于更高的最终准确率。 这就是关键。

原因是按排序建文件夹这种"聪明"的组织方式，让终端导航变脆了——agent 要在嵌套路径里来回切换，工具调用和轮次都涨了，反而干扰了它干正事。这个发现很值钱：在给 agent 设计工作环境时，可读性和可导航性可能比"信息组织得多精巧"更重要。简单平铺，把排序信息通过工具反馈给出去，反而是最优解。

工具行为的变化

图4：工具调用的百分比构成。上半部分是 bash、read、pull/filter 三类动作的高层占比；下半部分是 bash 调用内部的子类型分布。DR-DCI 把一部分"语料发现"工作从反复的 bash 搜索转移到了 pull，并在文档物化之后用了更多的本地 read。

这张图直观展示了 DR-DCI 改变了 agent 的行为模式。裸 DCI 和 Single Pull 都是 bash 主导（占比 89%–90%），疯狂敲搜索命令；DR-DCI 把 bash 占比降到 64.26%，read 提升到 23.29%，pull/filter 占 12.45%。说白话就是：以前是"反复在全语料里 grep 找东西"，现在变成"先 pull 一批进来，再安心读"。行为结构变健康了。

我的判断

聊完这些，说说我自己的看法。

这篇论文最值钱的，不是某个孤立的技术点，而是它对"检索器在 agentic search 里该扮演什么角色"的重新定位。过去我们要么把检索器当成最终的证据接口（agent 只能消费它的输出），要么干脆抛弃检索器让 agent 裸操作语料。DR-DCI 给了第三条路：检索器是 agent 的一个动作，是用来圈定操作范围的工具，而不是替 agent 做决定的黑箱。这个视角的转换，我觉得是会留下来的。

它的工程价值也很实在。墙钟降 20 倍、成本降 60%、还更准，这种"既要又要还要"在实践里很少见，通常是 trade-off 拉满。DR-DCI 能做到，本质上是因为它解决的是"操作性瓶颈"而非"智能瓶颈"——把 agent 从"在全语料上敲会超时的命令"解放到"在小工作区里敲秒回的命令"，省下来的全是纯收益。

那个工作区组织的反直觉发现（root-flat 最优），对任何在做"给 agent 设计工具环境"的人都有直接启发：别太"聪明"，agent 需要的是好导航的简单环境，不是组织精巧但路径复杂的迷宫。

但我也有几个保留意见。

一是前面提到的，跟训练过的搜索 agent 对比时基座不对等，强基座 + 巧框架的胜利里，框架本身的贡献占比没有被干净地分离出来。二是这套方案对底层检索器质量是有依赖的——Table 6 显示 Dense retriever（82/100）比 BM25（80/100）好，虽然差距不大，但如果检索器召回本身就差，pull 进来的都是噪声，后面的 DCI 操作再精细也是巧妇难为无米之炊。论文说框架不绑定单一后端，这是优点，但也意味着它的天花板部分取决于你接的检索器。三是上下文重置那个触发条件是针对 BrowseComp-Plus 手工调的（置信度 ≤ 70 + 弃答），换个数据集这个阈值要不要重调、鲁不鲁棒，论文没充分讨论。

总的来说，如果你在做大规模语料上的 agentic search、RAG、或者 deep research 类的产品，这篇论文里的核心思路——检索即动作、物化工作区、跨文档局部操作——非常值得抄进去试试。尤其是那个"工作区保留、上下文重置"的解耦技巧，实现成本不高，但对长轨迹的鲁棒性提升很实际。

回到开头那个让我们团队头疼的场景。DR-DCI 给的答案其实很朴素：别让 agent 在"只能看检索结果"和"在全语料里裸奔"之间二选一，给它一个自己能动态扩展、能精细操作的小天地。这个小天地，就是工作区。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我