Rekal：让 AI 编码决策随 Git 一起被团队记住
AI 编程工具最容易丢掉的，往往不是代码，而是把代码带到当前形态的判断过程。某个方案为什么被否决、一个边界条件为什么不能简化、一次重构到底解决了什么，通常都消失在已经关闭的对话里。后来的人——包括下一次打开的 agent——只能从 diff 猜答案，然后把已经讨论过的岔路再走一遍。
今天看的是 rekal-dev/rekal-cli，简称 Rekal。它把这个问题放回开发者已经拥有的基础设施里：在 Git commit 时捕获 AI coding session，经 secret redaction 和 home-path anonymization 后保存为仓库中的 .rekal/ 数据；当工作合入默认分支后，团队记忆经 Git push/fetch 在专用 orphan branch 上传播。检索和 embedding 都在本机完成，不要求额外的 memory SaaS、vector database 或账号。
按 GitHub repository page、README、LICENSE、默认分支 commit feed 和 release page 在 2026-09-09 18:15 Asia/Shanghai 可核验的信息，rekal-dev/rekal-cli 当前有 186 stars、2 forks。主要语言是 Go，license 是 Apache-2.0。仓库创建于 2026-02-24 23:20:14 UTC，latest push 是 2026-08-04 09:23:27 UTC。最新提交为 aace7a2，时间 2026-08-04 09:23:27 UTC，信息为 docs: changelog and pin for 1.0.2 (#87)。最新 GitHub Release 是 v1.0.2，发布时间 2026-08-04 09:36:00 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | rekal-dev/rekal-cli |
| 定位 | 将 AI coding session 的决策作为 Git 可同步团队记忆 |
| Stars | 186 |
| Forks | 2 |
| 主要语言 | Go |
| 许可证 | Apache-2.0 |
| 创建时间 | 2026-02-24 23:20:14 UTC |
| Latest push | 2026-08-04 09:23:27 UTC |
| 最新提交 | aace7a2，2026-08-04 09:23:27 UTC |
| 最新 Release | v1.0.2，2026-08-04 09:36:00 UTC |
| 安装方式 | installer 或 Releases 中的单文件 binary |
| 关键词 | Git、agent memory、CLI、local-first、semantic search |
它保存的是“为什么”，不是又一份代码索引
Rekal 的切入点和常见的 repository RAG 不同。后者回答的是代码现在长什么样；Rekal 尝试保留的是会话中为什么选择 A、为什么拒绝 B。README 的例子很贴近日常：后来 session 在考虑 webhook retry 时，可以直接查询此前关于 fixed delay 会造成恢复期拥塞、应使用 exponential backoff with jitter 的结论，而不必只从提交信息里倒推。
数据有两个层次。原始、append-only 的 session ledger 是长期来源；用于 full-text、semantic 和 graph retrieval 的 index.db 是可丢弃的派生索引。这样的分层有一个很实用的结果：重建索引不会篡改已记录的对话，较重的 embedding 工作也可以留在后台，而不让普通 commit 等待。
它并不试图把全部历史硬塞给 agent。一次查询默认给出简短 verdict、候选 session 和可继续展开的 turn；agent 再按需要 drill into 完整推理。对于 context window 很宝贵的 coding workflow，这比把一份越来越长的 MEMORY.md 盲目注入更像一个可控的检索接口。
用 Git 传播，只让已合入工作成为团队上下文
rekal init 会在目标仓库建立 .rekal/、post-commit/pre-push hooks、对应 agent 的 skill/rules marker，以及以 rekal/<email> 命名的 orphan transport branch。这个分支和项目代码没有共同祖先，因此不会混进正常的 history、merge 或 working tree。团队成员执行 rekal sync 后，可把远程的 Rekal branches 折叠进自己的本地索引。
这里最值得注意的约束是“只同步已合入默认分支的工作”。本机可以保留 feature branch 的完整 session，但没有合入的 spike、半成品实验不会自动传播给同事。对团队而言，这在“丢失上下文”和“把所有未定论聊天同步出去”之间给了一个清晰边界；对 review 过的决策，Git 本身就是既有的分发和权限通道。
本地优先，也把隐私边界写进工作流
README 声明 transcript 在写入数据库前会经过 pattern 与 entropy 检测的 secret redaction，以及 home path 匿名化；embedding 和查询默认在机器上完成。它仍然只是 best-effort redaction，不是把敏感会话丢进仓库前就万无一失的安全证明——团队仍应检查自己允许被提交和同步的内容。
但这个方向有现实价值：不需要再为“让 agent 记住上下文”运行一套 hosted memory service；团队也不必把全部 session 发送给第三方 API。对于已有 Git 托管和访问控制、又希望工具在断网时仍能 recall 的项目，这是比新建向量库更轻的起点。
安装与第一步
项目提供 installer，也可以从 Releases 下载对应平台 binary。README 的最短路径是：
curl -fsSL https://raw.githubusercontent.com/rekal-dev/rekal-cli/main/scripts/install.sh | bash
cd your-project
rekal init
git commit -m "…"
rekal "为什么放弃了 batching？"更稳妥的做法是先下载 installer 阅读，再执行；Release 附带 checksums.txt，可以用 shasum -a 256 -c checksums.txt 验证。初始化会修改 hooks 和检测到的 agent instruction 文件，所以也适合先在一个小仓库试跑并审查 diff。
适合谁，以及不要忽略的代价
如果团队已经频繁使用 Codex、Claude Code、Cursor、Copilot、Gemini、Kiro 或 OpenCode，且痛点是同一套架构讨论在不同 session 反复出现，Rekal 很值得尝试。特别是跨时区协作、长生命周期仓库、或有很多“看 diff 看不出原因”的决策时，它把上下文变成可查询的项目资产，而不是依赖某个人记忆。
代价也很具体。当前 README 将支持范围列为 Apple Silicon macOS 和 Linux x86-64/arm64；单个 binary 约 170 MB 下载、约 200 MB 磁盘占用，因为 embedding model、inference engine、database 和 full-text extension 都被打包进去。项目虽已进入 1.0，stars 和 forks 仍少，最好先用非关键仓库验证 hooks、存储大小、redaction 规则与团队的 Git 流程是否匹配。
总结
Rekal 有意思的地方不是宣称“agent 有长期记忆”，而是把记忆的归属、传播与退出机制都放在团队熟悉的 Git 工作流中：会话在 commit 时被保存，只有合入的工作被分享，索引可再建，原始记录可追溯。若你需要减少 agent 和人类重复讨论旧决定，又不想为此引入一个新的云端上下文平台，它是一个足够具体、也值得拿小项目实测的方案。