code-context：让 AI Agent 搜代码，而不是一页页读
AI coding agent 读代码时，有一个很常见的低效路径：先 ls，再 grep，再打开十几个文件，最后把大量并不相关的源码塞进上下文。这个流程对小项目还能忍，对真实业务 repo 就会变成 token 和 tool call 的黑洞。很多问题并不是“某个符号在哪里”，而是“哪些文件一起承担了这块逻辑”“这类代码主要分布在哪些模块”“有没有相似实现”。单纯逐文件读，很难优雅回答这些跨 repo 的问题。
今天看的是 infino-ai/code-context。它的方向很明确：给 AI coding agent 一个本地代码检索层，让 agent 通过 CLI 或 MCP server 查询 repo-local index，而不是每次从零 crawl 文件。这个 index 同时支持关键词检索、语义检索、hybrid ranking 和 SQL 聚合，并以普通文件形式放在项目里的 .infino/ 目录。它不是新的 agent IDE，也不是云端代码搜索服务，而是一个更窄的基础设施层：让 agent 先 search，再 read。
按 GitHub repository page、GitHub API、README、LICENSE、Releases、Tags、package.json 和最近 commit 在 2026-08-22 03:45 Asia/Shanghai 能核验的公开信息，infino-ai/code-context 当前有 25 stars、1 fork。仓库主语言是 TypeScript，许可证是 Apache-2.0。仓库创建于 2026-07-10 10:31:55 UTC，最近公开 push 是 2026-08-20 05:22:39 UTC，默认分支是 main。最新 GitHub Release 是 v0.3.0，发布时间 2026-08-19 11:49:55 UTC。最近 commit 是 69eebda，信息为 “build(deps): bump @infino-ai/infino from 0.5.1 to 0.5.2”，commit 时间 2026-08-19 11:50:01 UTC。npm package 名是 @infino-ai/code-context，当前 package version 是 0.3.0，要求 Node.js >= 20，暴露 code-context 和 cx 两个 CLI bin。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | infino-ai/code-context |
| 定位 | 给 AI coding agents 使用的本地代码检索层 |
| Stars | 25 |
| Forks | 1 |
| 主要语言 | TypeScript |
| 许可证 | Apache-2.0 |
| 创建时间 | 2026-07-10 10:31:55 UTC |
| 最新 push | 2026-08-20 05:22:39 UTC |
| 默认分支 | main |
| 最新 GitHub Release | v0.3.0，2026-08-19 11:49:55 UTC |
| 最近 commit | 69eebda，build(deps): bump @infino-ai/infino from 0.5.1 to 0.5.2 |
| 运行要求 | Node.js >= 20 |
| 关键词 | MCP、BM25、semantic search、hybrid search、SQL、local-first、CLI |
它把“读 repo”拆成可查询的索引
多数 coding agent 已经会使用 grep 和文件读取工具，但这两个工具的粒度都偏低。Grep 擅长找精确字符串，文件读取擅长看局部上下文；一旦问题跨模块，agent 就会开始发散。它可能先搜一个词，发现太多命中，再打开几个文件，接着换词重搜。最后回答看起来像理解了项目，实际上只是读到了一些碰巧相关的片段。
code-context 的做法是先为 repo 建一个本地 index。README 里强调了一个关键点：关键词索引会先可用，向量部分在后台补齐。也就是说，第一次使用时不必等所有 embedding 都完成；BM25 search 可以先工作，语义和 hybrid ranking 在向量准备好后再加入。这个 staged readiness 对开发工作流很重要，因为 agent 的工具如果启动慢，它就会回退到熟悉但低效的 grep 和 read。
它暴露的工具面也刻意很小：search、sql、reindex。search 负责把关键词和语义相似度融合排序，并返回带路径和行号的代码片段；sql 让 agent 对 index 做只读聚合查询；reindex 用来刷新增量索引。三种工具覆盖了找代码、数代码、更新索引三个动作。对 agent 来说，这比塞进一堆近似功能的 retrieval tools 更容易选择。
真正有区别的是 SQL。很多代码搜索工具只能返回 top hits，agent 还要自己读结果、归类、数文件。code-context 把 ranked search 做成可组合的数据关系，README 给出的例子是先搜索相关 chunk，再按 path 聚合行数和 chunk 数。这样 agent 可以问“哪些文件最集中处理某个主题”，而不是拿一屏搜索结果自己猜。这对架构理解、影响范围评估、重构前侦察都很有用。
和已有 code context 工具的差异
Gumi 之前写过 Argyph 和 GitHits，所以这个题材不能只停在“给 agent 提供代码上下文”。infino-ai/code-context 的差异在几个更具体的选择上。
第一，它把 index 放在 repo 本地的 .infino/ 目录，强调没有账号、没有 API key、没有外部 database server。对 private repo 来说，这个边界很清楚：代码和索引都留在机器上。README 还提到默认 embedding 使用本地小模型，下载一次后可以离线工作。这里的价值不是“更智能”，而是把上下文检索从 SaaS 依赖里拿出来，放回开发者自己的工作目录。
第二，它把 SQL 当成 agent 工具，而不是只做给人看的搜索 UI。很多时候，人类可以凭经验扫搜索结果，但 agent 更适合用结构化查询压缩信息。比如在改登录链路前，先找出 repo 里和 session、cookie、auth middleware 最相关的文件，再按路径聚合；或者在追一个缓存 bug 前，先看哪些模块集中出现 TTL、invalidate、refresh 相关 chunk。SQL 聚合会让“跨文件理解”更像一次查询，而不是一串碰运气的文件读取。
第三，它对工具选择问题有自觉。README 里反复解释为什么工具面保持在三个，以及在 Claude Code 里建议让这些工具 alwaysLoad。这个细节很工程化：agent 有太多工具时，会先花成本找工具，甚至错过合适工具。一个小而稳定的 MCP server，有时比一个功能庞大的平台更容易被 agent 用对。
可以怎么用
最直接的场景是让 agent 在动手改代码前先查 repo。比如你问“这个项目里 feature flag 是怎么流转的”，code-context 可以先从 index 里找相关片段，必要时再用 SQL 聚合出主要文件，然后 agent 再打开少数关键文件确认细节。相比从根目录开始探索，这个路径更像一个有索引的 codebase briefing。
第二个场景是做影响范围判断。改一个基础函数、删除一个配置项、升级一个 SDK 时，grep 往往只能找到直接字符串，找不到语义相近的使用方式。Hybrid search 可以把 exact term 和近义描述一起带入结果，SQL 再把命中按文件或目录聚合。Agent 至少能先得到一张“可能受影响区域”的地图。
第三个场景是重复理解大型 repo。README 提到它在自己的 benchmark 里对 tool calls、tokens 和 wall time 都有节省，尤其是 aggregation 类问题。具体数字需要在自己的 repo 上复测，但这个方向合理：如果问题本质上是检索和聚合，把它交给 index 会比让模型反复读文件更稳定。
安装路径也比较轻。Claude Code 可以通过 plugin marketplace 安装；其他 MCP client 可以用 npx -y @infino-ai/code-context mcp 注册；CLI 侧则有 cx。这让它适合先在一个非关键 repo 上试，而不是一开始就改团队基础设施。
Caveats
第一，项目还很年轻。仓库创建于 2026-07-10，目前 stars 只有 25，latest release 是 v0.3.0。这个阶段很适合观察和试用，但不适合默认假设 API、index 格式和 MCP tool 行为已经长期稳定。
第二，CI 覆盖范围需要注意。README 写明 CI-tested on Linux x64 glibc 和 macOS arm64，linux-arm64、musl、Windows via WSL 预期可用但没有同等 CI 覆盖。如果你的开发环境是 Alpine、Windows 或 ARM Linux，最好先在真实 repo 上跑一遍索引和查询。
第三，本地 embedding 不是零成本。README 强调 keyword index 可以先可用，vector backfill 后台完成，但第一次下载模型、建立向量索引、占用磁盘和 CPU 仍然是成本。大型 mono repo 需要关注 .infino/ 大小、索引刷新速度，以及是否要把它加入 .gitignore。
第四，索引只能帮助 agent 找到候选证据，不能替代阅读和验证。Search hit 带来的片段很有价值，但修改代码前仍然要打开关键文件、跑测试、确认调用链。更好的 retrieval 会减少盲读，不会自动保证理解正确。
总结
infino-ai/code-context 有意思的地方，是它没有把自己做成一个大而全的 agent 平台，而是盯住了一个很窄但真实的问题：coding agent 不应该每次都像第一次见到这个 repo 一样，从 ls 和 grep 开始摸索。
本地 index、BM25 + semantic hybrid search、SQL 聚合、MCP 和 CLI，这几个组件组合起来，让 agent 可以先问“代码在哪里、集中在哪、相似实现有哪些”，再决定读哪些文件。它还很早期，但方向清楚。对经常让 agent 处理中大型 repo 的开发者来说，这类小型检索层值得放进工具箱试一试。