AI Agent 在代码库里找一个函数，传统做法是这样的：
Agent 发一个请求："请读取 src/auth/login.py" → 你收到了整个文件，500 行 → Agent 说"不是这个，读 src/auth/handler.py" → 又收到 800 行 → 重复五六次之后，Agent 终于找到了它要的 3 行代码。
你为 5,000 行代码付了 token 钱，只用了 3 行。
这就是 Semble 要解决的问题。
Semble 的思路
Semble 的名字取自"semantic"（语义）+ "assemble"（组装）。它的核心逻辑是：不用整个文件喂给 Agent，而是先用语义索引找到相关代码片段，只返回 Agent 真正需要的部分。
具体怎么做？
混合搜索策略。 不是纯语义向量搜索，也不是纯关键词匹配，而是两者结合。先用关键词做粗筛，再用语义相似度做精排。这样既不会漏掉精确匹配的代码，又能理解"这个函数和那个函数的关系"这种语义层面的关联。
忽略文件机制。 和 .gitignore 一样，Semble 支持 .sembleignore，自动跳过 node_modules、vendor、dist 这些 Agent 根本不关心的目录。
Token 计数量化。 他们不只说"省 token"，还在 benchmarks 里跑了数据：不同代码库规模下，Semble 和 grep+read 的 token 消耗对比。858 星的项目敢把 benchmark 数据公开放在 README 里，说明数据是站得住的。
为什么这件事重要
你可能觉得 98% 是个营销数字。但它背后的趋势是真的。
AI 编码 Agent 最大的成本瓶颈不是推理速度，是上下文窗口。一个中等规模的代码库，Agent 读几个文件就可能吃掉几万个 token。GPT-4o 的输入 token 价格是 $2.50/百万 token，Claude Sonnet 是 $3/百万 token。一个复杂的多文件任务，光上下文读取就能烧掉几美元。
当 Agent 每天执行上千次任务时，这个成本是指数级的。
Semble 解决的正是这个"隐形的成本漏洞"。
和现有方案的对比
代码搜索这个领域不缺玩家：
- grep/ripgrep：快，但返回整个匹配行，上下文不精准
- Sourcegraph：企业级，强大但重
- GitHub Code Search：平台绑定
- 各种向量数据库方案：纯语义搜索，精确度有问题
Semble 的定位很明确：为 AI Agent 优化的轻量级代码搜索。它不是要替代 Sourcegraph，也不是要和 ripgrep 比速度。它的唯一目标是：让 Agent 用最低的 token 成本找到需要的代码。
值得留意的点
这个项目还年轻——76 次 commits，6 个 issues，最新提交是 8 小时前。但作者 stephantul 是个活跃的贡献者，更新频率高。
更值得关注的是它的 benchmark 目录：他们不仅做了 token 消耗对比，还做了不同代码库规模下的性能测试。这种"用数据说话"的做法在开源社区并不多见。
我的看法
Semble 代表了一个越来越清晰的趋势：AI Agent 的工具生态正在从"能用"走向"高效能用"。
早期的 Agent 工具只要能完成任务就行。现在大家都在优化：更少的 token、更低的延迟、更高的准确率。Semble 是这波优化浪潮中的一个典型案例。
如果你的团队在用 AI 编码 Agent 处理大型代码库，值得花 15 分钟试用 Semble。省下来的 token 钱，可能比你的直觉想象的多得多。
主要来源：
- MinishLab/semble on GitHub — 858 stars, 67 forks, 76 commits
- 项目 benchmarks 目录：token 效率对比数据
- Show HN 帖子：12 points, 12 comments