背景#

2026 年 9 月上旬两周之内有两条消息：JetBrains 公开了 Context 这条语义检索流水线的工程细节，AST 切块加 binary quantization；Databricks 发了个能自己决定搜几轮的检索模型。两家都在往「检索」这一层加东西。

2025 年最流行的结论正好相反。Claude Code 不给代码库建任何索引，Cline 那边把 RAG 叙事直接叫 “a mind virus”。

这两件事看上去对不上。把公开资料按时间排开之后，它们落在同一条线上。2024 年被撤掉的是 RAG 那种索引：推理之前检索一次，把 top-k 塞进 prompt，定终局。2025 年底加回来的索引挂在 agentic search 的循环里，也就是模型自己反复调工具去找东西的那种跑法，想调就调一下，不够再来一轮。同一个词底下换了角色。

下面先把时间点排出来，再看这三段各自在解什么问题，最后回到自己的仓库该不该建索引。DCI 那篇论文的机制在另一篇笔记里拆过，这里只当时间线上的一个点。

时间线：2023-02 到 2026-09#

时间 发生了什么 出处
2023-02 GitHub 上线 Blackbird 代码搜索，用的是 n-gram 倒排索引，不做向量检索：45M 仓库、115TB 代码，单 shard p99 约 100ms GitHub Blog
2023-10 Aider 用 tree-sitter 抽函数和类的签名做 repo map，只给模型看骨架，不算 embedding aider.chat
2023 Cursor 和 Cody 都把「给代码库建向量索引」当默认做法。Cursor 用 Merkle tree 比对哪些文件变了，只重算变过的部分（这份说明是 2026-01 补写的） Cursor Blog
2024-02 Sourcegraph 在 Cody Enterprise GA 时撤掉 embeddings，换成自家的 Sourcegraph Search，原文写的是 “we’re leaving them behind (for now)” Sourcegraph Blog
2025-02 Claude Code 以 research preview 形态发布 Anthropic
2025-05 Boris Cherny 说早期 Claude Code 用过 RAG 加本地向量库，后来发现 “agentic search generally works better” 转引
2025-05 Cline 的 Nik Pash 发文，把「拿 RAG 当默认答案」称作 “a mind virus” pashpashpash
2025-10 Cognition 发 SWE-grep 和 SWE-grep-mini，用 RL 专门训的检索模型，工具只有 grep/read/glob Cognition
2025-11 Cursor 发《Improving agent with semantic search》，自训 embedding 模型，问答准确率平均 +12.5% Cursor Blog
2025-11 Cursor 2.1 上线 Instant Grep，agent 跑的 grep 变成即时返回；changelog 没写实现 Cursor 更新日志
2026-01 Databricks 发 Instructed Retriever，自测称在复杂 benchmark 上比传统 RAG 高 70% 以上 Databricks
2026-05 CoREB 代码检索 benchmark 开源，发现短关键词 query 下几乎所有 embedding 模型都排不出相关文件 arXiv:2605.04615
2026-05 DCI 论文发布，主张把语料当文件系统，让 agent 用终端工具直接搜 arXiv:2605.05242
2026-07 JetBrains Context 公开预览，把语义索引做成独立一层，通过 MCP 给 Claude Code、Codex CLI、Junie CLI 用 JetBrains Blog
2026-08 zg（zvec-grep）开源，本地跑向量检索、BM25 和 ripgrep，用 RRF 融合结果，以 MCP 挂给 agent zvec.org
2026-09 JetBrains 公开 Context 的实现细节：AST 切块、binary quantization 把向量压到每维 1 bit、用 Hamming 距离比对 JetBrains Blog
2026-09 Databricks 发 Adaptive Instructed-Retriever，由模型自己决定这次要搜几轮 SiliconANGLE

表里有一个容易混的地方：GitHub 的 Blackbird 和 Sourcegraph 的 Zoekt 都是 n-gram 或 trigram 倒排索引，做的是精确匹配加速，跟 embedding 没关系。akshansh 那篇把 Copilot 划进「RAG 阵营」时，举的论据是 Blackbird 的索引规模。Copilot 确实另有服务端的语义索引，但 Blackbird 本身是 lexical 的，拿它的规模当向量检索的证据就把两种索引混成了一种。下面说「撤掉索引」时，撤的都是向量索引那一类。

2024 到 2025：向量索引被撤掉的四个理由#

这一段的主角是 Sourcegraph、Anthropic 和 Cline，三家给的理由能拼成一条链。

索引跟不上代码（staleness）。 代码每天在变，索引要跟着重建。Sourcegraph 2024-02-16 那篇给的三条理由里，有一条就是维护 embedding 的新鲜度会给管理员添一摊活。Cursor 那套 Merkle tree 正是冲着这个问题去的，用哈希比对只重算变过的文件，但它的存在本身也说明问题有多难绕开。Boris Cherny 把 staleness 和 security、privacy、reliability 并列，当成 agentic search 更简单的原因。

代码要出本地。 Sourcegraph 当时用的是 OpenAI 的 text-embedding-ada-002，所以那三条理由的第一条是代码得送到第三方去算向量，「not everyone wants their code to be relayed in this way」。第三条是规模：超过 10 万个仓库时向量库本身就变得复杂且吃资源，把他们做跨仓库 context 这件事卡住了。JetBrains 到 2026 年做这件事时，专门把这一条当成设计约束：索引里只存 chunk 的坐标（文件路径、类型、起止 offset 这些），不存代码本身，embedding 全在自家 GPU 上跑。

chunk 把代码的逻辑切碎。 Nik Pash 的论点是，人读代码不是读孤立片段：资深工程师进一个大 monorepo，先扫目录结构、翻文件、看 imports，再顺着读更多文件。他还引了 Sourcegraph CEO Quinn Slack 一句更扎的：「99% of RAG implementations never did any chunking or never measured in a rigorous way.」

context window 变大之后，瓶颈换了位置。 Pash 的说法是，从 Claude Sonnet 3.5 到 4.0，瓶颈已经从 context 的大小挪到了 context 的质量上。MindStudio 那篇给的量级是中型代码库大概 5 万到 15 万 token，200K 的窗口已经能装下相当一部分。既然能直接读，就没必要先压缩成 top-k。

这四条合起来，2025 年的主流叙事就成了「coding agent 不需要索引」。Claude Code 的工具设计是这个叙事最干净的样本：Glob 找路径几乎不花 token，Grep 返回命中行，Read 才把整个文件塞进 context（工具清单）。大范围探索还可以交给独立 context 的 Explore 子 agent，不占主对话的预算。按 2026-09 的文档，macOS、Linux、WSL 上 Glob 和 Grep 已经不在默认工具集里，改走 Bash 里的 find 和 grep，路子没变。

2025 年底：叫不出名字的那类问题把 embedding 拉了回来#

grep 有个前提条件：要先知道搜的那串字符。Zach Nussbaum 在 2025 年 11 月那篇里把这条边界划得很清楚，grep 适合「已经知道、或者很容易推出来」的关键词，而 embedding 的场合是叫不出变量名或某个环节的名字、但能说出它某个侧面。

Cursor 同月发的数据，是这篇引到的材料里最接近线上 A/B 的一组：接上自训的 embedding 模型之后，agent 回答问题的准确率平均高 12.5%，按模型分布在 6.5% 到 23.5%；代码留存率整体只涨 0.3%，但在 1000 文件以上的仓库涨到 2.6%；关掉语义检索时，用户表达不满的追问多了 2.2%。他们训这个 embedding 模型的方法也值得记一笔：拿 agent 真实会话里的检索轨迹，让 LLM 给「这个文件有没有用」打分，再让 embedding 的相似度去对齐这个排序。训练目标从「代码相似」换成了「对 agent 有用」。

Cursor 自己的结论没有站到 grep 的对面：「Our agent makes heavy use of grep as well as semantic search, and the combination of these two leads to the best outcomes.」

反方向的证据同样存在。2026 年 5 月的 CoREB benchmark 测了 11 个 embedding 模型和 5 个 reranker，发现短关键词 query 这种最接近开发者实际输入的形态，能把几乎所有模型的 nDCG@10 打到接近 0。nDCG@10 看的是返回的前 10 条：每条按相关程度记分，排得越靠后权重打得越低，再除以「相关的全排在最前面」那个理想排序能拿到的分，满分是 1。接近 0 就是说前 10 条里基本没有该找的文件。而 agent 发出来的 query 恰恰大量是短关键词这个形态。Nussbaum 提到的另一个做法是反过来补：先让 LLM 生成关键词再去 grep，效果比纯关键词 grep 好了近 10 倍。

两边都在补对方的短板，这就是 2026 年收敛的起点。

2026 年的收敛：索引挂进了 agent 的循环里#

2026 年这批东西有个共同的结构变化。索引没有回到「推理之前跑一次，返回 top-k」的位置，它被包成一个工具，由模型决定什么时候调、调几次、调完还要不要再调。

flowchart LR A[agent 推理循环] -->|要精确字符串| B[regex 索引
n-gram / trigram] A -->|说不出关键词| C[语义索引
embedding + BM25] A -->|要看上下文| D[直接读文件
Read] B --> E[结果融合
RRF 或模型自己取舍] C --> E D --> E E -->|不够就再来一轮| A

几个落在这个结构上的例子：

Cursor 2.1 把 agent 跑的 grep 变成即时返回，changelog 只写了结果，o-mega 那篇把它归因为本地 n-gram 索引。这一步冲着延迟去：agent 一个任务要搜 5 到 20 次，每次慢一点，模型就倾向于问更宽、更不精确的问题。

Cognition 的 SWE-grep 更进一步，专门训一个小模型去做检索这一步，工具还是 grep、read、glob，但一轮能发 8 个并行调用，最多 4 轮，目标是把这一段压在 5 秒的 flow window 里。他们给的背景数字是 agent 在大代码库上，第一轮里 60% 以上花在搜索这件事上。

JetBrains Context 把语义索引做成了跟 IDE 解耦的一层，通过 MCP 挂给 Claude Code、Codex CLI 这些本来不建索引的 agent。厂商自测的口径是 2333 个任务上最多减少 68% 的 agent 轮次、59% 的延迟、48% 的成本。

开源的 zg 把三条路直接并在一个工具里：本地向量检索、BM25、ripgrep，用 RRF 把三路结果融合成一个排序列表，再以 MCP server 的形态给 Claude Code、Codex、Cursor、OpenCode 用。它报的数字是 SWE-QA-Bench 上工具调用减半、输入 token 少近一半；Django 那种 3457 个文件的仓库，在 M4 Pro 上建索引不到 30 秒。

Databricks 那条线走的是检索器侧的自适应：Adaptive Instructed-Retriever 自己判断这次要搜几轮，找够证据就停。

DCI 那篇论文（arXiv:2605.05242）从另一头得到同样的结构：干脆不建索引，让 agent 在类终端环境里反复 grep。它和上面这些做法共享同一个前提，检索是 agent 循环里可以反复调用、随时改主意的动作。机制和 benchmark 在那篇笔记里拆过。

这些数字里哪些能当选型依据#

上面引的数字来源不同，可信度差别很大，值得单独摆一摆。

拿 SWE-bench Verified 的分数比检索架构，这个推理站不住。akshansh 那篇把「Claude Code 80.8%、OpenAI Codex 72.8%」当成 agentic search 胜过 RAG 的证据，但这个分数是模型、harness、prompt、工具集合起来的结果，换个模型排名就能翻。

小样本的工具横评同理。jiangren 那篇引的第三方测评（2026-01）给出 Cursor 平均 11000 token / 90 秒 / 60% 一次成功率，Claude Code 2000 token / 180 秒 / 75%，来源写了链接，但底下是 5 个 refactoring 任务。方向可以参考，绝对值不宜往别的场景上套。

厂商自测的相对值要看口径。JetBrains 那组 68% / 59% / 48% 前面带着 “up to”，测的是加不加自家 Context 的对比，任务集也是自己挑的。Databricks 的 70% 同理。

相对可信的是两类：一类是线上 A/B，比如 Cursor 那组 12.5%，样本是真实用户会话，缺点是绑死在自家 agent 和自训模型上；另一类是第三方公开 benchmark，比如 CoREB 那个「短关键词 query 把 nDCG@10 打到接近 0」，它测的是能复现的机制。

这些数字比较适合用来确认方向，不适合直接当选型依据。

判断该不该建索引的四个维度#

把上面这条线折回到具体场景，大致有四个维度。

query 能不能写成关键词。 错误码、函数名、配置项、文件路径这些，grep 一步到位，加索引是白花钱。说不出确切名字的那类（「支付超时之后重试的逻辑在哪」），grep 只能靠猜关键词，这时候语义检索的收益才出得来。

仓库有多大。 Cursor 的数据是 1000 文件以上语义检索的增量才明显；o-mega 那篇引的 Augment Code 的观察是小仓库且标识符有辨识度时，grep 本身就够，加 embedding 检索没有提升。两边合起来的含义是，文件数在千级以下、标识符又有辨识度的仓库，grep 这条路已经够用，索引那笔前置成本不一定收得回来。

索引谁维护、代码出不出本地。 这条决定的是能不能用现成 SaaS。要是代码不能出去，能选的就剩本地方案（zg 这类，或者自建），维护成本要算进去。

预算和延迟。 让 agent 反复 grep 意味着每多翻一层就多一次模型调用。索引把这部分前置成一次性成本，换来查询时的低延迟。任务重复度高的场景，前置这笔账划算；一次性的排查，直接 grep 更省事。

四条合起来指向的分工大致是：代码这一侧，中小仓库交给 agent 自带的 grep 就够；文档、题库这类没有确切标识符可搜的语料，向量库仍然是主场（这类做法可以参考用 pgvector 给题库做 RAG那篇）。要跨多个仓库找东西时，JetBrains Context、zg 这种挂在 MCP 上的索引层是成本较低的一条路，它不要求换掉现在用的 agent。

小结#

从 2023 年到现在，向量索引在 coding agent 里的位置动过两次。第一次是被撤掉，理由是索引跟不上代码、隐私、chunk 切碎逻辑，以及 context window 变大之后直接读文件更划算。第二次是被加回来，但位置变了：它从「推理之前跑一次的检索终点」变成了「agent 循环里随时可调的一个工具」，跟 grep、读文件并列，由模型决定调不调。

这条线上最值得记住的是那条边界：grep 要求 query 里已经有能搜的字符串，语义检索接的是叫不出确切名字的那类问题。CoREB 那个「短关键词把 embedding 模型打到接近 0」和 Cursor 那个「grep 加语义检索一起最好」说的是同一件事的两面。

截至 2026-09，能查到的公开资料里还没有哪一方在公开 benchmark 上证明纯索引路线或纯 grep 路线单边更优。2026 年发出来的东西，从 Cursor 2.1 到 zg 到 JetBrains Context，都在往混合走。

参考资料#