BitFun 已在 GitHub 开源：https://github.com/GCWing/BitFunhttps://github.com/GCWing/BitFun欢迎大家体验、提 issue，也欢迎一起来参与共建。

（文章作者来自BitFun开源社区：wgqqqqq）

一次真实任务里的搜索瓶颈

现在，像 Claude Code、Codex、OpenCode 、BitFun这类Coding Agent工具，已经越来越多地进入日常开发流程。Agent 在读代码、找定义、追调用链、定位配置和报错时，会频繁调用搜索工具。

我们让 BitFun 和 Claude Code 在 Chromium 源码上跑了同一组代码搜索任务。很快发现，Claude Code 被反复搜索拖住了节奏，而 BitFun 几乎不受影响。

分析背后的数据，我们看到了问题的真正根源。在一次典型的分析链路中，传统的 Grep + Glob + Read 累计耗时约 145.9 秒，其中仅 Grep 就占了 137.2 秒。也就是说，绝大部分等待时间并不是花在代码阅读或分析上，而是花在反复搜索代码上——Claude Code 的分析能力再强，也得先等着搜索返回结果。

为了解决这个问题，我们在 BitFun 的检索链路中引入flashgrep来替代传统的grep和glob工具。替换之后，同一类任务的检索相关耗时可降到约 7.82 秒，减少约 138.1 秒，降幅约 94.6%。

---

为什么大仓库检索会慢

可以把一个超大代码仓库想象成一座巨大的图书馆。

传统搜索更像是每次都从头翻一遍书架，确认有没有目标内容。这个办法简单直接，但当图书馆越来越大、搜索次数越来越多时，等待就会越来越明显。

AI Agent 的问题更突出，因为它不是偶尔查一次，而是在一次任务里反复查很多次。搜索变慢之后，Agent 的阅读、分析和修改都会被连带拖慢。

在小仓库里，搜索通常很快。但当代码规模从几十万行增长到几千万行，搜索工具每次要面对的文件和代码都会明显增加。对 Coding Agent 来说，这种等待会在多轮工具调用中不断累积。

---

BitFun的解决思路：先缩小范围，再检索

BitFun 通过flashgrep，预先为代码仓库建立索引。搜索时，先用索引快速缩小范围，再只检查少量相关文件，让大量无关文件不再被反复扫描。

我们再以图书馆找书为例，flashgrep像是图书馆提前建好了一套目录索引，先查目录找到相关的几排书架，再去那几排书架里仔细查找需要的书。

不是每次重翻整座图书馆，而是先查目录，从而更快找到答案。

---

效果不止在一个任务里：平均加速36.1倍

在 chromium-src 中，我们选取了多组常见代码搜索任务，包括函数名、测试宏、配置字段、C++ 调用、正则模式和多分支查询。

结果显示，在 BitFun 内部，基于flashgrep的代码搜索，相比传统工具 ripgrep，平均加速约 36.1 倍。这意味着用户在 BitFun 里的每一次找代码、补上下文、定位线索，都能更快进入下一步，节奏不会轻易被搜索打断。

---

不是小 demo，而是真实超大仓库

chromium接近 6000 万行代码，Git 跟踪文件超过 4GB。

在这样的规模下，BitFun依赖的flashgrep完成一次基础索引构建约 79.0 秒，最终索引大小约 2.5GB，约为原仓库代码体积的 58%。

这说明 BitFun 的搜索加速方案具备真实大仓库落地的可行性。

BitFun 不只是能读代码，还要更快读懂代码

一个Coding Agent 能不能干好活，其实不只看它有多“聪明”，更看它能不能干得快。

BitFun做的事很简单：把总等待时间从分钟级降到秒级。Agent 不用每次搜索都“愣一下”，而是可以快速地往下分析、验证、修改，动作紧凑，思考连贯。

BitFun 在 Chromium 这种大库里跑得顺，不是因为比别的 Agent 推理速度更快，而是因为它不用老等着。搜索不拖后腿，思考才能连得上。

让 Agent 把时间花在想问题上，不是花在等搜索上——这才是BitFun带来的真正改变。