MinishLab 开源了 Semble。它表面是代码搜索库，实际盯着 AI 编程代理最浪费的一步：为了找几行关键代码，先 grep，再 read，最后把一堆无关文件塞进上下文。

项目方给出的数字很扎眼：平均 repo 索引约 263ms，查询 p50 约 1.5ms，NDCG@10 为 0.854；相比 grep+read，宣称平均少用约 98% token。

这个 98% 不能当成真实任务的固定省钱比例。它的基线是 grep 命中后读取匹配文件全文。但方向没错。很多 coding agent 的问题不是不会写代码，而是还没开始写，就已经在代码库里绕丢了。

Semble 做的是 agent 的代码导航层

Semble 可以通过 MCP server 接入 Claude Code、Cursor、Codex、OpenCode 等工具。也可以走 CLI，或把调用方式写进 AGENTS.md / CLAUDE.md。

它让 agent 不只搜关键词，而是用更接近任务意图的方式找代码。比如问 authentication flow 在哪，返回相关代码片段，而不是把整份文件塞给模型慢慢筛。

项目方披露的核心对比如下：

项目项目方测试或宣称更现实的理解
索引速度平均 repo 约 263ms适合临时接入仓库，不必等重型索引
查询速度p50 约 1.5ms，CPU 运行工具调用成本低，agent 才可能多查几次
检索质量NDCG@10 为 0.854接近 CodeRankEmbed Hybrid 的 0.862，不是全面碾压
token 节省相比 grep+read 少约 98%主要省掉“读整文件”的浪费
对比对象grep+read、ripgrep、BM25、CodeRankEmbed Hybrid它对比的是 agent 探索流程，不是所有代码理解能力

技术路线也不神秘：代码感知切块，Model2Vec 静态 embedding 做语义召回，BM25 处理符号、API、标识符匹配。两路结果用 RRF 融合，再用代码规则重排，比如定义优先、文件相关性、测试和 legacy 降权。

这里要分清边界。Semble 不理解整个项目，不负责规划修复，也不会自动改代码。它只做一件事：把更可能相关的代码片段递给 agent。

受影响最大的不是普通用户，而是两类人。

一类是重度使用 Claude Code、Cursor、Codex 的开发者，尤其是面对中大型仓库的人。你们可以先把 Semble 当成 agent 的检索前置层，而不是立刻替掉 grep。

另一类是 agent 工具链开发者。过去大家争模型、争上下文窗口、争 IDE 入口。接下来，检索、索引、重排这些小零件会越来越像水电煤。看着不起眼，坏了才知道贵。

真正省下来的，是无效上下文

AI 编程这两年有个尴尬现实：模型越来越强，喂上下文的方式却常常很粗。

大窗口当然有用。但能读 100k token，不等于应该读 100k token。上下文窗口变大以后，很多工具反而更懒了：搜到什么读什么，读不准就多读，反正模型自己会捞。

这不是免费的。成本会涨，延迟会涨，噪音也会涨。更麻烦的是，模型在无关上下文里做判断，容易把“看过”误当成“理解了”。

Semble 的价值就在这里。它不是替代 grep。grep 在精确字符串、快速确认、穷举匹配上仍然很好用。

它替代的是 agent 的低效探索流程：猜关键词，扫一堆文件，读入全文，再让模型从噪音里找针。

“工欲善其事，必先利其器。”放到 agent 编程里，这个“器”不是又一个聊天框，而是检索、索引、工具调用策略。它们不性感，但决定一次任务是三步到现场，还是在仓库里空转半小时。

如果团队已经把 AI 编程代理接入日常开发，我会建议做一个很小的验证：挑 20 到 50 个真实任务，记录工具调用次数、读入 token、首个有效文件命中率、最终修改是否命中正确模块。

别只看 demo。看任务账单。

适合优先试的场景很明确：仓库大、模块多、命名不统一、agent 经常读错文件。收益可能来自少读、少绕、少把模型注意力浪费在噪声里。

不适合急着迁移的场景也很明确：小仓库、强约定、文件结构清楚、开发者本来就知道入口在哪里。这里 grep 和 IDE 搜索已经够快，接入新工具可能只是多一层复杂度。

漂亮基准之后，要看三个现实变量

冷水必须泼。Semble 的 benchmark 来自项目方，不是独立第三方结论。

测试覆盖约 1,250 个查询、63 个仓库、19 种语言，比很多玩具 demo 扎实。但真实代码库更脏：历史包袱、生成代码、内部框架、跨服务调用、命名混乱，都会拖累检索质量。

我更关心三个变量。

变量为什么关键该怎么观察
真实仓库表现benchmark 仓库未必等于公司内部仓库看首屏结果是否命中真正修改点
agent 调用习惯工具有了，不代表模型会少读文件看 grep/read 调用是否实际下降
复杂任务链路检索命中只是第一步，不等于修对代码看最终 patch 是否减少返工

这里有个老问题。铁路刚出现时，真正改变商业的不是车头本身，而是轨道、调度、站点和标准。今天的 coding agent 也类似。模型像车头，检索层像轨道。车头再猛，轨道乱铺，照样跑不稳。

这个类比不完全一样。软件开发不是运输业，代码语义也比货物复杂。但重复的是同一种权力结构：谁控制路径，谁就控制效率。

Semble 至少说明一件事：AI 编程代理正在从“蛮力堆上下文”，转向“先把路找准”。模型能力还重要，但检索层会成为大型代码库里的分水岭。

接下来别盯着 98% 这个数吵。更该看它能不能让 agent 少读错文件、少发无效工具调用、少在上下文里制造幻觉。

如果这三件事成立，Semble 这类工具就不是锦上添花。它会变成 agent 编程的地基。反过来，如果 agent 仍然习惯性 grep、read、塞满上下文，再好的检索库也只是摆设。