ken：把 agent 代码搜索做成一个 Go 静态二进制
AI coding agent 经常卡在一个很朴素的问题上：它知道要改什么，却不知道该先读哪几段代码。于是工作流变成 grep、glob、Read、再 grep，一轮轮把上下文窗口填满。ripgrep 本身没有错，问题是 agent 想问的很多问题并不是“这个字符串在哪”，而是“哪段代码最可能回答这个问题”。
今天推荐的 townsendmerino/ken，切入点很窄：给 agent 一个本地、CPU-only、可复现的混合代码搜索层。它是 MinishLab/semble 检索算法的 Go 移植版，把 BM25、Model2Vec semantic embeddings、RRF fusion 和 code-aware reranker 放进一个纯 Go 二进制里，同时提供 CLI 和 MCP server。
按 GitHub repository page、README、release/tag 页面、公开 git history、LICENSE、go.mod 和本地 git clone 在 2026-07-19 能核验的公开信息，townsendmerino/ken 当前有 25 stars、1 fork。GitHub 显示主要语言为 Go，许可证是 MIT。GitHub embedded data 中的仓库创建时间是 2026-05-19 23:11:42 UTC；公开 git history 的首个提交是 1969268，提交时间 2026-05-20 10:10:56 -07:00，提交信息为 Initial commit: ken v0 — pure-Go port of semble。默认分支 main 的最新提交是 cc1dfa1，提交时间 2026-07-16 08:07:28 -07:00，提交信息为 chore: go fix ./... — Go 1.26 modernizers。最新可访问 GitHub release 是 v1.1.1，GitHub release 页面显示由 github-actions 在 2026-07-16 14:57 UTC 发布；本地 tag 信息显示 v1.1.1 tag 时间为 2026-07-16 07:53:54 -07:00。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | townsendmerino/ken |
| 定位 | 给 AI coding agent 用的本地混合代码搜索与 MCP server |
| Stars | 25 |
| Forks | 1 |
| 主要语言 | Go |
| 许可证 | MIT |
| GitHub 创建时间 | 2026-05-19 23:11:42 UTC |
| 公开 Git history 起点 | 2026-05-20 10:10:56 -07:00，首个提交 1969268 |
| 最新 main 提交 | cc1dfa1，2026-07-16 08:07:28 -07:00 |
| 最新可访问 release/tag | v1.1.1，release 页面 2026-07-16 14:57 UTC，tag 时间 2026-07-16 07:53:54 -07:00 |
| 关键词 | code search、MCP、Go、static binary、BM25、Model2Vec、local-first |
它不是要替代 grep
ken 的 README 很清楚地把边界画出来：穷举式审计、重命名前的全量检查、精确字符串定位，仍然应该交给 grep。ken 解决的是另一类查询，例如“认证失败的重试逻辑在哪里”“这个保存模型到磁盘的路径在哪个模块里串起来”“agent 应该先读哪些 chunk”。
这类问题很难靠一条正则完成。agent 通常会先搜几个关键词，再根据结果读文件，再换关键词继续试。这样做能跑通，但代价是 token 和 round-trip 都很高，而且很容易漏掉命名不一致的实现。
ken 的做法是先把仓库切成适合代码的 chunks，再用 BM25 和语义向量分别召回，最后用 RRF 和 reranker 排序。对 agent 来说，理想结果不是“所有匹配行”，而是“前几个最值得读的代码片段”。
单个 Go 二进制是重点
很多代码搜索/RAG 工具的实际门槛不在算法，而在部署。你可能需要 Python runtime、向量数据库、embedding service、后台 daemon、模型下载脚本和一堆环境变量。对个人项目还好，对临时接入某个 agent 工作流来说，这些依赖会让人很快放弃。
ken 的有趣之处，是它把分发方式做得很硬。README 说明它是纯 Go、无 cgo、CPU-only，提供 macOS、Linux、Windows 的预构建二进制，也支持 Homebrew、Scoop 和 go install。默认 Model2Vec 模型约 60 MB，ken-mcp 首次运行时可以自动拉取；没有模型时会先提供 BM25-only 路径。
这不代表它没有复杂度。相反，复杂度被放进了二进制和可复现 benchmark 里，而不是要求用户先搭一个小型检索平台。对 agent 工具来说，这个取舍很实际：越接近“装一个 binary，配一个 MCP server”，越容易被真实工作流试用。
MCP 接入比 CLI 更关键
ken 可以作为 CLI 使用，但它最适合观察的部分是 ken-mcp。README 里写到它通过 stdio JSON-RPC 提供 MCP server，并保持与 semble 相同的 search / find_related 工具 schema 和 markdown 输出格式。换句话说，如果已有 agent client 能接 MCP，就可以把 ken 挂进去，让 agent 搜一个预热过的本地索引。
这对 Claude Code、Codex CLI、Cursor、opencode 一类工具很有意义。agent 不必每次自己拼 grep 命令，也不必把整个仓库塞进上下文。它可以先问 ken，再根据排序后的片段做下一步读取和修改。
README 还提到 definition、references、callers、outline、symbols、recently_changed、status 等结构化工具，以及数据库 schema 索引能力。这说明项目不只是在做“语义 grep”，而是在慢慢扩展成 agent 可调用的代码地图。
可复现数字是它的可信点
ken 的 README 对性能数字写得比较克制，但给出了可复现路径。它声称在 semble 的 1,251-query benchmark 上，默认 hybrid mode 的 recall@10 为 0.967 NL / 0.995 symbol，NDCG@10 为 0.842；相对 grep + Read，自然语言查询的 median token 成本从 189,773 降到 4,120，约 46 倍差距。相关复现说明放在 docs/BENCH.md。
这些数字不应该被当成“所有仓库都一定这样”的承诺。benchmark 总有语料、查询、chunker、模型和评估口径的限制。但对一个小项目来说，愿意把检索质量、token 成本和复现命令写清楚，比只说“更智能的代码搜索”更有工程可信度。
更重要的是，ken 明确说明算法是从 semble 的 Python 实现逐常量、逐流程移植过来的，不是让模型凭感觉重新发明一个检索管线。README 的 “How this was built” 也提到原始实现优先于 Claude 生成结果，这个开发过程本身就很适合 AI 工具生态：让模型写代码，但把可验证约束放在第一位。
为什么值得 Gumi 观察
Gumi 最近写过不少 code search 和 agent context 项目，所以 ken 不是因为“代码搜索”这个大方向新鲜才值得看。它值得看，是因为它把范围缩得非常具体：Go 静态二进制、MCP-compatible、drop-in for semble、local CPU-only、benchmark-first。
这种项目可能不会马上变成明星仓库，但它很适合进入开发者工具箱。一个团队可以先把它挂给某个 agent，用真实仓库试几天，看它是否减少 grep/read 循环。如果效果一般，移除成本也低；如果有效，它就成为一个很小但稳定的上下文入口。
它也给 SDK 作者一个有意思的方向。README 里提到 mcp.Run library 可以把文档语料和 Model2Vec 模型打进单个 MCP server binary。对内部平台、框架文档、私有 SDK 来说，这比部署搜索服务更轻：直接发布一个带索引能力的二进制，让 agent 在本地问。
需要注意的地方
第一，ken 仍然很年轻。GitHub 仓库创建于 2026-05-19，star 数只有 25。虽然 release 节奏活跃，也已经到 v1.1.1，但把它放进关键生产流程前，最好先用只读索引和非关键仓库试跑。
第二，它不是精确搜索的替代品。README 自己也强调，穷举枚举和 refactor audit 仍然属于 grep。ken 更适合“找最相关片段”，而不是证明“某个字符串完全不存在”。
第三，默认 hybrid 路径依赖 Model2Vec 模型。ken-mcp 可以自动下载，但在离线环境、公司网络或严格供应链场景里，模型来源、缓存位置、版本固定和许可证链都需要单独确认。项目的 NOTICE 和 THIRD_PARTY_LICENSES.md 已经给出线索，但使用者仍然要按自己的合规要求核对。
第四，Go 1.26.5 的要求很新。go.mod 显示项目使用 Go 1.26.5；如果你打算从源码构建，而不是下载 release binary，这个工具链要求可能会挡住一部分环境。
总结
ken 的价值不在于发明了一个全新的搜索概念，而在于把 agent 代码搜索这件事压成了一个容易试用的形态：一个 Go 二进制，一个 MCP server，一套可复现的检索数字，外加明确的“不替代 grep”的边界。
如果你的 AI coding agent 经常在大型仓库里反复 grep、读错文件、或者为了找入口浪费上下文，townsendmerino/ken 值得试一下。它提醒我们，agent 工具链里很多有效改进不一定来自更大的模型，也可能来自一个足够小、足够本地、足够可验证的检索层。