Semble：让 AI Agent 搜代码的 Token 消耗直降 98%，怎么做到的

AI Agent 读代码库有一个很实际的问题：太费 Token。

一个典型的工作流是先 grep 找到关键词，再 cat 读取整个文件。一次查询下来，几万 Token 就没了。如果是大型代码库，Agent 反复搜索、反复读取，Token 消耗和 API 成本蹭蹭往上涨。

最近在 Hacker News 上火了一个项目叫 Semble，核心卖点就一句话：Token 消耗比传统 grep+read 方式减少 98%。

HN 帖子 70 多条评论，有人质疑"98% 是不是吹的"，也有人实测后说"甩开我自己搭的方案 20%"。我扒了一下项目源码和相关讨论，来聊聊它到底做了什么。

本文提纲

1. 98% 到底怎么算出来的
2. 技术架构：BM25 + 静态 Embedding 的混合检索
3. 一套精心设计的重排序信号
4. 不只是搜索：digest、deps、impact 等实用命令
5. Rust 移植版 semble_rs
6. HN 上的争议和实测结果
7. 快速上手

98% 到底怎么算出来的

先说清楚一个容易误解的点——98% 不是比 grep 本身省 98%。

grep 本身不用 Token，它是本地命令。但 Agent 的工作流不是 grep 就完事了，而是：

grep 关键词 → 找到一堆文件 → cat 每个文件 → 把整个文件内容塞进上下文

这才是 Token 消耗的大头。一个 500 行的文件，全读进去就是几千 Token。Agent 可能要读 5-10 个文件才能找到真正需要的代码段。

Semble 的做法是不让 Agent 读整个文件，而是先做精准的代码级检索，只返回最相关的代码片段。通过 --outline 模式只返回函数签名，进一步压缩到原来的 2%。

HN 上有人问"grep 又不花 Token，98% 是比什么？"项目作者 Stéphan Tulkens 直接回答：比的是 Agent 在 grep 之后接着 read 整个文件的完整循环。

技术架构：BM25 + 静态 Embedding 的混合检索

Semble 的检索引擎用了一个很经典的混合方案：BM25 + Model2Vec 静态 Embedding，再用 Reciprocal Rank Fusion (RRF) 融合结果。

关键设计决策：

为什么用静态 Embedding 而不是 Transformer？

因为速度。Semble 用的嵌入模型是 minishlab/potion-code-16M，只有 60MB。推理过程是纯查表操作——词表嵌入 → 均值池化 → SIF 加权 → L2 归一化。不需要 GPU，不需要 API Key，CPU 上毫秒级完成。

代价是精度比大模型低一点。但 Semble 的基准测试显示 NDCG@10 达到 0.854，是最佳 Transformer 方案的 99%。对于 Agent 的代码检索场景，这个精度够用。

为什么混合而不是只用 Embedding？

因为纯语义检索在代码场景里有明显的短板。搜 parse_config 这种精确符号名时，BM25 的词频匹配比语义匹配准得多。而搜 "how does authentication work" 这种自然语言描述时，Embedding 又比 BM25 强。

Semble 的解决方案是两个都跑，然后用 RRF 融合。还有一个自适应权重机制——检测到符号查询时自动增加 BM25 权重。

代码分块策略

用 Tree-sitter 在函数、类、模块边界处切分，而不是按固定行数切。这保证了每个 chunk 是一个完整的语义单元。支持 Rust、Python、JavaScript/TypeScript、Go、Java、C/C++、Kotlin、Ruby、PHP、Swift 的完整 AST 解析。

一套精心设计的重排序信号

检索完之后，Semble 有一套多层重排序逻辑，这是我觉得最有意思的部分：

这六层信号叠加在一起，把一个简单的检索引擎变成了对代码语义有理解的搜索工具。

特别是"依赖图提权"这个设计——当你搜到一个处理用户认证的核心函数时，它 import 的 auth_middleware.py 也会被提权。这在 Agent 理解代码架构时非常有用。

不只是搜索：digest、deps、impact 等实用命令

Semble 不只是个搜索引擎，它提供了一套面向 Agent 的代码理解工具链：

semble digest：把 CI/Build 日志压缩到原来的 1-2%。3.3MB 的 GitHub Actions 日志压缩成 35KB，耗时 20ms。自动识别 cargo、pnpm、pytest、go test、gradle、ruff、mypy 等构建工具的输出格式。

semble deps 和 semble impact：依赖图分析和影响分析。改了这个文件会影响哪些文件？支持 --tree（ASCII 树形）和 --dot（Graphviz）输出。

semble tree：替代 ls -R 的代码库地图。Token 消耗降低 4x-747x。

semble find-related：从某个文件的具体行出发，找语义相关的代码。做代码修改时特别有用。

semble plan：Token 高效的规划命令。输入你的需求，它不直接执行，而是建议你接下来应该跑哪些 semble 命令。这本身就很省 Token。

Rust 移植版 semble_rs

原始版本是 Python 写的（来自 MinishLab，作者 Stéphan Tulkens 和 Thomas van Dongen）。HN 上有人吐槽"CLI 工具为什么用 Python"，于是社区开发者 johunsang 做了 Rust 移植版 semble_rs。

semble_rs 是原版的超集，增加了 digest、deps、impact、find-related、plan、find-pattern（ast-grep 封装）等命令。当前版本 v0.9.1，91 Star。

基准数据：100 个查询，Recall@1 70%，Recall@5 90%，Recall@10 95%，MRR 0.78。索引 1600 个文件约 10 秒。

HN 上的争议和实测结果

70 多条评论里，最有意思的是争议和实测。

争议一：模型不信任新工具

有用户报告说，模型（尤其是 Opus 4.7）被 RL 训练得"太信任 grep 了"，拿到 semble 的结果还是会再跑一遍 ripgrep 验证。作者承认 "Sonnet 4.6 似乎更信任 semble 的结果"。

这是一个很有意思的问题——工具好不好是一回事，模型愿不愿意用是另一回事。

争议二：实测数据参差不齐

用户 aadishv 做了对比测试：

第一个测试 Semble 反而贵了一点，第二个测试 Semble 明显胜出。作者承认端到端的 Agent 级基准测试还在路上。

正面评价：

用户 cormacrelf 测试了 Semble 和竞品 ck：索引 rust-lang/rust 这种巨型仓库，ck "可能要 3 天"，semble 26 秒。加了缓存和 watchman 后进一步优化到 1.4 秒。

快速上手

Python 版安装：

# 作为 MCP Server 安装（推荐，适配 Claude Code / Cursor / Codex）
claude mcp add semble -s user -- uvx --from "semble[mcp]" semble

# 或直接 CLI
pip install semble

Rust 版安装：

cargo install semble_rs

零配置，无 API Key，无 GPU，完全本地运行。

项目地址：

• Python 版：github.com/MinishLab/semble
• Rust 版：github.com/johunsang/semble_rs

Semble 解决的问题很聚焦——Agent 搜代码时 Token 消耗太高。方案不花哨但扎实：混合检索 + 多层重排序 + 静态嵌入。不需要 GPU，不需要 API Key，本地跑毫秒级响应。

对于每天用 AI Agent 写代码的人来说，这类工具的价值不在 98% 这个数字，在于让 Agent 的搜索从"粗暴地 grep+cat"进化成"精准地理解+定位"。成本下降是副产品，效率提升才是核心。

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。