把 AI 记忆变成可 grep 的文件：DaiDocs 的本地优先实践
很多 AI Agent 的“记忆”都藏在服务商的数据库里：能不能导出、换模型后是否还能读取，往往要看产品接口。DaiDocs 走的是另一条路线：把对话历史和代码上下文保存为本地纯文本文件，让记忆可以被编辑器、grep、git 和不同模型共同读取。
这不是又一个只会保存聊天记录的向量库。DaiDocs 5.1.1 将记忆拆成两个互补层：.dai 用于文档与会话历史，.cai 用于代码图。前者记录事实、决定和偏好，后者保存调用者、被调用者、导入关系与依赖影响范围；路由器再根据问题选择合适的一层。
为什么纯文本值得认真考虑
本地文件的优势不在于“看起来简单”，而在于生命周期可控。你可以直接打开一个 .dai 文件检查 Agent 为什么得到某个结论，也可以把它提交到私有 Git 仓库，或者用普通命令搜索，而不用先学习某个厂商的 SDK。
.dai 文件由 YAML 头部、JSON 代码块和正文组成；格式是公开的，README 还提供了规范与校验清单。.cai 则由 tree-sitter 确定性构建，不需要模型参与分析。这样，模型负责解释内容，代码图负责回答结构问题，两者的行为边界比较清楚。
这对长期维护尤其重要：换回答模型不会自动丢掉已有记忆，代码变更后也可以通过钩子刷新代码图。需要注意的是，本地优先不等于自动安全——.dai 可能包含敏感对话，仍应放在合适的磁盘权限和私有仓库中。
安装与最小配置
DaiDocs 的文档记忆层需要 Node 18 或更高版本，最短安装路径是：
npx daidocs setup
安装器会检测 Claude Desktop、Claude Code、Cursor、Windsurf、Codex、Cline、Continue 和 Zed，并为检测到的工具配置会话钩子与读取协议。它会备份自己修改的文件；如果希望先查看状态，可以运行：
node setup.js --status node setup.js --ask
如果主要需求是让 Agent 理解代码结构，可以单独安装代码层：
pip install kerneta-cai kerneta doctor kerneta setup ./my-project --corpus ./my-project
.cai 的命令行还包括 build、update、watch、query、ask、history 和 doctor。其中 setup 会为项目配置技能和 PostToolUse 钩子，使代码图可以在编辑后自动刷新。团队不一定要同时安装两层：只用 .dai 可以获得文档与历史记忆，只用 .cai 也能获得代码图。
一个更可靠的 Agent 工作流
可以把它理解成“观察者”和“回答者”分工。观察者在会话结束或过程中把事实、决策和偏好写入本地记忆；回答者只读取与当前问题相关的片段。对于代码问题，路由器优先查询代码图，再根据需要关联解释这些代码的历史文档。
例如，面对“修改这个函数会影响哪些调用方？”这样的任务，Agent 不必把整个仓库塞进上下文，而是查询 .cai 的调用关系。面对“我们为什么选择这个接口？”的问题，它则应该读取 .dai 中的决策记录。两种问题都交给同一套本地文件管理，既减少上下文噪声，也方便人工复核。
DaiDocs README 给出的基准结果也体现了这种取舍：其代码图示例中，httpx 导入关系的检索使用 22 个 token，而 Graphify 示例使用 4,696 个 token；同一项目还公开了 LongMemEval-S 的复现实验、逐题判断和 SHA-256 清单。数字来自项目自己的材料，不能直接当作所有仓库和所有模型的普遍结论，但“为问题提供小片段，而不是整份历史”是值得借鉴的设计原则。
使用时的三个边界
第一，先审计再自动化。记忆文件是可读的，应该定期清理过期事实、密钥和个人信息；不要因为文件是纯文本，就默认它适合公开提交。
第二，区分事实与推断。把“用户明确决定的方案”和“模型猜测的偏好”放在不同记录中，并保留来源，才能避免旧结论持续污染新任务。
第三，验证钩子是否真的生效。安装完成后，修改一个小函数，再执行 kerneta query 或 kerneta ask，确认代码图能够反映新关系；同时检查 .dai 文件是否能被普通编辑器打开。可观察性比“安装命令成功返回”更重要。
DaiDocs 最有价值的地方，不是把记忆包装成更复杂的服务，而是把它降回一种可以检查、迁移和版本控制的文件格式。对于需要在 Claude Code、Cursor、Codex 与本地模型之间切换的开发者，这种可见性可能比又一个封闭的记忆 API 更实用。