ARTICLE · 1161577
你的 AI 编程助手,可能有一半预算花在＂找文件＂上
我拿 grep 和一次搜索做过对比：同一个问题，一个读了 40 个文件还在找，一个直接给出了那一行。
上周我让编码助手确认"退款失败后还会不会重试"。它开始 grep "retry"，命中两百多处，然后一个文件一个文件地读，读到第 40 个还没定论。不是模型不行，是它手里只有一把锤子。
一、它不是笨，它是没有地图
编码助手在陌生仓库里的默认动作只有一个：grep 关键词，把命中的文件整篇读进来，再看下一个。文件读进来就是上下文长度，上下文长度就是钱。
问题在信息结构上。grep 按字面找东西，只回答"这几个字母出现在哪些行"；但"退款为什么不再重试"是个语义问题，它只能靠猜关键词。猜错再猜一次，这就是那 40 个文件。加拿大开发者 Ted Haley 把这件事做成了产品，叫 Pensieve，本地代码搜索加 MCP 上下文，MIT 协议免费开源，主力面向 mac。主张一句话：一次搜索，把该看的几段话交给 agent，别让它把整块盘读一遍。它不写代码，只负责在合适的时刻把上下文递过去。
二、它让 agent 少读 43% 的文件
先看索引这一层，这是全部能力的地基。
文本用 Qwen3-Embedding-0.6B 在本地转成向量，存进 SQLite，另建一个 trigram 全文索引专门处理精确匹配，向量检索交给 turbovec。
索引、搜索、模型全部跑在本地，数据落在
~/.pensieve，没有账号、没有云端服务。监听文件变化用 FSEvents，一次改动在最后一次保存后约 0.5 秒进索引；正在写入的 agent 会话每 30 秒刷新一次，另有 5 分钟一次的全量扫描兜底。
搜索延迟 0.1~0.2 秒，即便仓库有三万五千个文件也不掉速，因为检索一发起，索引任务会先让一下。
连接方式是 MCP（Model Context Protocol，模型上下文协议）——给 agent 定的一套标准插座，插上就能用外部工具，不用每个客户端单独适配。它能自动接入 Claude Code、Codex、Cursor、Gemini CLI、Qwen Code、Windsurf、Claude Desktop 和 VS Code。
装起来就一条命令。前提是 Apple Silicon 的 Mac，不需要 git，也不需要 Xcode 命令行工具：
curl-fsSL https://tedhaley.ca/pensieve/install.sh | sh
pensieve integrate recommended
第二条命令做三件事：给每个 agent 写上 MCP 服务器配置、往指令文件里插一段"先搜索再 grep"（比如 ~/.claude/CLAUDE.md）、给 Claude Code 加一个搜索技能和两个钩子。
这一步看着不起眼，其实是整件事的关键。
Agent 会习惯性 grep，哪怕索引就在手边。你不改它的指令，它照样去读整个仓库。 作者自己承认，加上这段指令块之后，144 次基准测试里 agent 每次都用了 Pensieve；没有它，很多次它压根想不起来。
还有两个细节值得记一下。一是权限收口：每个 agent 默认只能看到它当时所在的仓库、该仓库的 worktree，以及它自己的历史会话；想要更大范围就命名一个 scope，比如把两个仓库加一份规格文档拼成 payments 域再交给它。
二是工具集克制。默认只给模型看十个查询类工具（search、read、who_knows、knowledge_gaps 这些），改配置、加目录、重建索引那一堆默认藏起来。
三、省了多少，作者把账本摊开了
想复现很便宜。Pensieve 版本 0.5.6，题目从代码里自动生成，答案是"文件有没有被找到"。在 504、1783、2383、34847 个文件的四个真实仓库上，同一批 72 道留出题、两种配置各跑两遍：
| 指标 | 只有 grep / glob / read | 加上 Pensieve |
|---|---|---|
| 任务成功率 | 123 / 144（85%） | 131 / 144（91%） |
| 每次查找工具调用 | 3.44 次 | 1.97 次（−43%） |
| 每次查找成本 | $0.050 | $0.041（−18%） |
| 每次查找 token | 67k | 57k（−16%） |
| 每次查找耗时 | 10.9 秒 | 8.6 秒（−21%） |
看绝对值更清楚：一次查找省不到一美分，144 次也就几块钱。但在三万五千文件的那个巨型仓库里，成本降了 28%，工具调用少了 47%。
钱对个人不算什么，省下的等待时间才是真的。每次查找快 2.3 秒，一天几十次就是十来分钟的决策延迟。
还有一组更值得看的数字，是"首次结果就对"的比例：
| 查询类型 | 单次 grep | Pensieve 首次命中 |
|---|---|---|
| 精确名称 | 54% | 94% |
| 报错字符串 | 92% | 88% |
| 名称加描述混合 | 0% | 74% |
| 纯自然语言描述 | 0% | 58% |
这张表的读法比数字本身重要。
grep 在错误信息这类精确字符串上依然赢，那本来就是字符串匹配的地盘。一旦你只能说出"我想要那种处理降级的逻辑"，grep 的胜率是零，语义检索是 58%。
所以这不是替代关系，作者的页面里写的也是"先搜索，再 grep"。
最后还有一个我觉得最实用的部分：它读 git blame，告诉你每个代码区域是谁写的、谁还在维护、哪些地方已经没人懂了。那些"大部分代码出自已离职的人之手"的模块会被标出来，连同还懂它的人数和名单，再喂给 agent 补文档。人员流动留下的知识空洞，通常要等一次线上故障才会被发现。
四、它省下的 token，会被工具本身吃掉一部分
一个代价是它自己也占上下文。 README 里写着：那组工具描述每一轮都会发给模型，是常驻开销，用没用到都在付费。
这不是 Pensieve 的缺陷，是所有 MCP 工具的共同代价。但它把一件常被忽视的事摆上台面：
上下文窗口不是"你能塞多少"的问题，而是"什么有资格长期待在里面"的问题。
按这个标准看，一轮对话里常驻的东西其实不少：系统提示词、工具描述、记忆文件、技能说明，以及随时可能被压缩掉的对话历史。它们按轮次重复计费，越到后面越贵。所以"工具装得越多越好"是个坏直觉。每个新 MCP 服务器都在给每一轮对话加固定税，哪怕一次都没被调用。
Pensieve 在这一层上很克制：默认只暴露十个工具，管理类藏起来，搜索结果给的是"几段话加行号"而不是整个文件。它优化的是每轮对话里一直在场的负担。
这就叫上下文工程。
五、先说清楚它救不了什么
作者对成本口径很克制，有一句提醒值得照抄：这些数字取决于当时 Claude 的提示缓存暖不暖，只能在同一批次内比较，跨批次比没有意义。
而且这套数据来自一种模型、四个仓库、同一台机器，换模型换仓库，数字会变。
还有几条现实的约束：
硬件门槛。 macOS 应用只支持 Apple Silicon，Linux 和 Intel Mac 只能装后端加浏览器里的地图视图，没有那个快捷搜索面板。首次运行要拉一个约 1.2GB 的嵌入模型，索引一个三万五千文件的仓库要一个多小时。
没签名。 应用目前没做公证，macOS 会拦一次，得去系统设置里的隐私与安全性点"仍要打开"。
它不管会话历史。 它索引文件和 agent 会话记录，不负责压缩你的对话上下文。你的对话涨到三十万 token 的时候，它一点忙都帮不上。
范围限制不等于安全隔离。 scope 限制的是 agent 能看到哪部分索引，不是沙箱，也不拦它在文件系统上做别的动作。这两件事经常被混为一谈。
AI 摘要默认用本地模型，也可以关掉。 开着的话，Apple Silicon 加 16GB 内存是前提，内置的 Qwen 3.5 9B 首次使用要再下约 5GB。
六、我的判断
有意思的点是：收益不落在"省钱"上。
省 18% 的 API 成本，对个人大概是一个月几十块；对团队来说，值钱的是 agent 少做十几次无效读取之后你少等的那几分钟。
它真正解决的是一个更基础的问题：agent 理解代码库的方式基本上是"把文件读一遍再说"，又慢又贵又容易走偏。 建一个可检索的索引，是补它天生缺的那块。
但我不建议所有人都上。先做一件更便宜的事：翻一下最近一次 agent 的会话记录，看看有多少次工具调用是在读那些读完没用上的文件。比例不高就别折腾；过半了，那才轮到考虑要不要装。
参考资料
Ted Haley，2026-10-11 发布（Pensieve 产品页）：https://tedhaley.ca/pensieve/
TedHaley/pensieve 仓库首页与 README，2026-10-08 最后更新：https://github.com/tedhaley/pensieve
Hacker News 讨论帖《Local Indexing to reduce tool calling and token usage》，2026-10-11：https://news.ycombinator.com/item?id=50049508
配图说明：头图为项目方官方卡片图，来源见参考资料；事实取自下列源文，中文为原创改写。