扔掉向量库，让 Agent 直接 grep 语料 —

一句话抓住重点

论文提出 DCI（直接语料交互）：Agent 不用任何 embedding 模型、向量索引、检索 API，直接用 grep/find/bash 在原始语料上翻找。同样的 Claude Sonnet 4.6 底座，把 Qwen3-Embedding-8B 检索器换成 DCI，BrowseComp-Plus 准确率从 69% → 80%，成本反而降了 29%。结论很反直觉：检索的瓶颈不在"模型有多强"，而在"接口分辨率有多高"。

+11.0pp

BrowseComp-Plus 准确率
(69%→80%，同底座换接口)

−29.4%

API 成本
($1440→$1016)

+30.7

多跳 QA 平均分
碾压最强检索 Agent

+21.5

IR 排序 NDCG@10
超过最强重排基线

01 · 谜题

语义检索哪里不行了？瓶颈是"接口"，不是"模型"

传统 RAG 的逻辑是：把语料切块 → 算 embedding → 建索引 → 查询时返回 top-k。这个"固定相似度接口"把整个语料压缩成了一次 top-k 检索，在 Agent 推理开始前就把信息流截断了。

问题在于：现代 Agent 想做的事，恰恰是这个接口做不了的——

🔤

精确词法约束

"必须同时出现 foo 和 bar"——embedding 的语义相似度做不到精确合取

🧩

稀疏线索拼接

把多个弱信号组合定位，需要 grep 'A' | grep 'B' 这种管道

🔍

局部上下文核查

找到一处后要读它周围几行验证假设，top-k 片段给不了

🔄

多步假设修正

看到部分证据后改搜索计划——被早期过滤掉的证据再也捞不回

⚡ 关键洞察

被 top-k 提前过滤掉的证据，再强的下游推理也救不回来。所以瓶颈不只在"检索后的推理"，而在"检索接口本身"——它只暴露语料的一个 top-k 切片。

02 · 两种范式

检索器中介 vs. 直接翻语料

论文把语料访问方式分成两派。左派是经典 RAG：Agent → 查检索器 → 拿 top-k 片段 → 推理。右派是 DCI：Agent 绕过一切预处理，直接拿 bash/grep/glob 在原始文件上搜，语义理解全部下放给 LLM 自己。

Figure 2 两种检索接口对比 — **图 2：**左 = 检索器中介（需离线建索引，Agent 只能看检索器愿意暴露的 top-k 片段）；右 = 直接语料交互（无需索引，Agent 用 grep/glob/bash + 轻量脚本直接在原始语料上做细粒度匹配和精确定位）。

# DCI 的核心操作，全是上古 Unix 命令，可任意管道组合：
grep 'foo' file | grep 'bar' # ① 强制词法合取
find . | grep 'report' | grep '2024' # ② 组合弱线索
grep -n 'keyword' file | head # ③ 定位后看局部上下文验证

💡 我的看法

这篇论文最聪明的地方是问题重构：它没有再去卷"更好的 retriever"，而是把检索从"retriever-design 问题"重新定义成"interface-design 问题"——你给 Agent 的接口分辨率（能看到比文档/段落更小的单元吗？），决定了它能观察、验证、行动的边界。这跟"与其优化搜索引擎，不如给人一个能自己写 SQL 的数据库"是同一种降维思路。

03 · 实测数据

三条战线全面碾压，还更便宜

论文在三类任务上把 DCI 和最强基线正面硬刚。先看最直观的 Pareto 前沿——同样底座下，DCI 把准确率和成本同时拉到更优。

Figure 1 Pareto 前沿 — **图 1：**BrowseComp-Plus 上"性能 vs 成本"的 Pareto 前沿。灰方块是各种检索范式（含 GPT-5.2、o3、Kimi K2 + Qwen3-Embed-8B）；红星 DCI-Agent-CC 用 80% 准确率 + 更低成本占据右上角，绿星 DCI-Agent-Lite 用 \$93 的极低成本钉在"最佳效率区"。

① 多跳 QA：平均分高出最强检索 Agent 30.7 分

方法	HotpotQA	2Wiki	MuSiQue	平均	Δ
ASearcher-Local-14B (最强检索 Agent 基线)	58	56	24	52.3	—
DCI-Agent-Lite (GPT-5.4 nano)	72	68	40	68.0	↑15.7
DCI-Agent-CC (Sonnet 4.6)	88	82	74	83.0	↑30.7

在 MuSiQue 这种最难的多跳上，DCI-CC 直接从 24 分拉到 74 分（+50）。

② IR 排序：六个数据集全部第一

方法	BRIGHT·Bio	BRIGHT·Robotics	BEIR·ArguAna	平均	Δ
BM25	18.9	13.6	31.5	20.3	↓26.7
OpenAI text-emb-3-large	23.3	12.8	58.1	33.1	↓13.9
ReasonRank-32B (最强检索基线)	58.2	33.9	28.7	47.0	—
DCI-Agent-CC (Sonnet 4.6)	77.1	56.8	85.3	68.5	↑21.5

❌ 一个常见误解

"BM25 这种词法检索早过时了，稠密向量才是未来。"——这篇论文的数据狠狠打脸：在 BRIGHT 这种推理密集型检索上，OpenAI 最强 embedding（33.1）只比 BM25（20.3）好一点点，两者都被会自己组合搜索的 Agent（68.5）甩开一大截。问题从来不是稀疏 vs 稠密，是"固定接口 vs 可编程接口"。

04 · 真凶

它为什么变强？不是找到更多证据，而是"看得更细"

最反直觉的发现来自轨迹分析（RQ2/RQ3）：DCI 赢，不是因为它召回了更多 gold 文档。论文提出两个过程级指标拆解——

$$ \text{coverage}_{\text{mean}}(q,\tau)=\frac{|M(q,\tau)|}{|D^*(q)|},\qquad \text{coverage}_{\text{any}}(q,\tau)=\mathbb{1}\big[|M(q,\tau)|\ge 1\big] $$

coverage = "够不够得着" gold 文档（广度召回）；localization = "够着之后能不能精确缩到一小段可用证据"（文档内定位）。$M(q,\tau)$ 是轨迹里实际浮现出的 gold 文档集合。

对比 DCI-Lite 和 Qwen3-Embedding-8B（同 GPT-5.4-nano 底座，n=100）：

指标	Qwen3-Embed-8B	DCI-Lite	解读
coverage·mean (召回)	56.7	28.0	DCI 召回更低
coverage·any (够着≥1篇)	74.0	70.0	差不多
localization (定位)	21.7	48.4	DCI 高出一倍多 ✓
准确率	45.0	73.0	+28 分

翻译成人话：BrowseComp-Plus 的题通常只有 1–4 篇 gold 文档。DCI 不去拼命把所有 gold 都捞全，而是一旦够着一篇有用的，立刻从"广撒网"切换到"显微镜级"的精读、提取实体、验证、再发起下一跳搜索。论文给这个起了个名字——retrieval interface resolution（检索接口分辨率）。

工具用得最多的是什么？

Bash（链式搜索/局部窥探/正则/定位）62.4%

Grep（CC 内置词法搜索）33.0%

整篇文档全读（占比很低）9.1%

Bash 内部又拆成：链式搜索 22.3%、局部上下文窥探 18.0%、正则匹配 17.0%、文件定位 14.0%。"整篇读"只占 9.1%——这正是"高分辨率"的体现：它在文档内部做手术，而不是把整篇塞进上下文。

05 · 别上头

DCI 也有死穴：语料一大就崩

论文很诚实地做了规模消融（RQ4）。grep 全靠"暴力扫"，语料一膨胀，定位第一个有用锚点的成本就爆炸式增长：

100K 文档

基准

38.5 次工具调用 / 题

→

200K 文档

明显吃力

86.9 次调用，延迟翻倍，准确率 −13.6 分

→

400K 文档

崩

122.4 次调用，准确率掉到 37.5%，20 题超预算

⚡ 工具消融的好消息（RQ6）

不用开放 shell 也行：只给 read + grep 两个工具，准确率就有 61%，已经比 Qwen3-Embed-8B 基线（45%）高 16 分；开放完整 bash 再加 12 分，但工具调用量和成本大涨。一小撮命令就解锁了大部分收益。

⚡ 上下文管理是非单调的（RQ5）

更激进的压缩 ≠ 更好。L3（截断+compaction）准确率最高（77），但"会选择性遗忘"的策略才利于多步假设修正——保留太多 verbatim 证据反而会让 Agent 跑偏。存在一个甜点区。

06 · 现实呼应

业界其实早就用脚投票了

🔥 联网补充：这不是纸上谈兵

这篇论文最值钱的，是给一个业界已经发生的事实补上了系统性证据。我查了一圈内部资料：Anthropic（Claude Code）、Cursor、Aider、Cline 用了两年半，收敛到了同一个答案——"用文件，不用向量库"。Claude Code 完全基于 Grep 实时查询上下文、做到"无状态"，官方明确拒绝向量索引；而 Cursor 保留向量索引是为了 IDE 里的大仓库场景。两边论据其实可以共存——它们解决的是不同规模的问题。

💡 我的看法：这篇论文的真正边界在哪

把它和 RQ4 的"400K 文档崩盘"对照看，结论就很清晰了：DCI 是"小语料 + 强 Agent"区间的最优解，不是 embedding 的全面替代品。Claude Code 的代码库通常几十到几百个文件，grep"扫标题+LLM 挑选"召回质量更高也更简单；但到了万级以上文档（企业知识库、全网检索），还是得回到 embedding + rerank 的老路。这篇论文真正的贡献不是"干掉向量库"，而是证明了"检索接口"是一个被长期忽视的、独立于 retriever 的设计维度——当 Agent 强到能像人类研究员一样搜索（提假设、测精确模式、读局部、改查询），压缩过的相似度索引就成了瓶颈。

💡 一个延伸思考

对你自己的框架/工作流也有启发：与其纠结"该上哪个 embedding 模型"，不如先问"我给 Agent 的语料接口分辨率够不够高"。很多 RAG 效果差，不是 retriever 弱，而是接口只给了 top-k 片段、Agent 想精读/验证/二次定位时无路可走。把原始语料以 grep 可达的方式暴露给 Agent，往往是更高 ROI 的改造。