当 git 遇见 AI agent：Atlas 想给每一次代码变更装上黑匣子
你让 Claude Code 改了一个鉴权模块。它改完了，commit 写得规规矩矩。三个月后，线上出 bug 了——某个边缘场景下 token 刷新会死锁。你 git blame 过去，看到那行代码是 agent 写的，commit message 是 "fix: handle token refresh edge…
当 git 遇见 AI agent：Atlas 想给每一次代码变更装上黑匣子
原始仓库：pacifio/atlas · Rust · MIT · 2026-09-02 单日 +895 stars
一个让人后背发凉的问题
你让 Claude Code 改了一个鉴权模块。它改完了，commit 写得规规矩矩。三个月后，线上出 bug 了——某个边缘场景下 token 刷新会死锁。你 git blame 过去，看到那行代码是 agent 写的，commit message 是 "fix: handle token refresh edge case"。
然后呢？
然后你什么都查不到。agent 当时的推理过程、它读了哪些文件、它为什么选择这个方案而不是另一个——全部随着终端关闭蒸发了。git 记录了"改了什么"，但没记录"为什么改"。
pacifio/atlas 这个项目就是冲着这个空白来的。它的自我定位很直接：source control for agents——给 agent 写的代码做版本控制，但不止记录代码，还记录代码背后的整个思考过程。
checkpoint：给 commit 装一个黑匣子
Atlas 的核心概念叫 checkpoint。一个 checkpoint 不只是"哪个 session 产生了哪个 commit"，它把四样东西绑在一起：
1. prompt：你当时问了什么 2. tool calls：agent 调了哪些工具、传了什么参数 3. file changes：改了哪些文件、改了什么 4. reasoning：agent 的推理链路
这些全部存在项目 .atlas/ 目录下的 SQLite 数据库里。关键设计：secrets scrubbed on write——在落盘之前就脱敏，不是在上传之前。因为 Atlas 默认完全本地，不需要账号，不需要联网。
一个细节值得注意：checkpoint 的链接能 survive rebases and amends。Atlas 用 patch-id reconciliation 来追踪——当 git rebase 重写历史时，它通过 patch 内容的 hash 重新关联 commit 和 session。如果 squash 让链接真的无法唯一确定，它会选择 orphan 而不是猜。这比很多 git 工具的 rebase 处理都更严谨。
多 agent 并行：共享记忆，不共享上下文窗口
Atlas 的另一个核心能力是让多个 agent 在同一个代码库上并行工作。Claude Code、Codex、Atlas 自己的 agent（基于 Rust 的 Cersei 框架），以及 ACP registry 里的任何 agent（Cursor、OpenCode、Kilo Code 等），都能在同一个窗口里跑。
这里有个设计决策值得拆开看。Atlas 没有试图自己造一个"万能 agent"，而是做了一个 agent-agnostic 的上下文层。所有 agent 通过 ACP（Agent Client Protocol） 接入，走同一条 send path。在消息到达 agent 之前，Atlas 做了五层上下文注入：
| 注入内容 | 来源 | 时机 |
|---|---|---|
@ mentions | 本地 Rust 解析：文件、文件夹、符号、分支、commit、笔记、论文、历史 session | 每轮 |
| 共享 agent 记忆 | 任何 agent 写入的活跃计划、决策、文件变更、失败记录、架构笔记 | 每轮 |
| 语义匹配 | 你的消息在本地被 embedding，和项目记忆索引做 HNSW 搜索 | 每轮 |
| Session 交接 | 策展过的 fact pack + 上一个 session 的尾部，即使上一个 session 是另一个 agent 跑的 | 首条消息 |
| 已有文档 | CLAUDE.md、AGENTS.md、Claude Code 的 memory files、Codex 的 history，折叠进一个索引 | 持续 |
一个聪明的细节：@ 一个 5000 行的文件，Atlas 发给 agent 的是一个路径，不是文件内容。agent 需要时自己读。这样一次 @ mention 不会在后续整个 session 里占据上下文窗口。
为什么这东西在涨？
2026-09-02 单日 +895 stars，这个数字放在 GitHub Trending 里不是最高的，但考虑到这是一个 macOS 优先的桌面应用（Tauri 构建，Linux/Windows 同代码但未充分测试），能吸引到这个量级的关注，说明它踩中了一个真实的痛点。
痛点是什么？agent 写的代码越来越多，但可审计性几乎为零。
想象一个场景：你的团队有 5 个开发者，每人每天用 Claude Code 写 2000 行代码。一个月后，代码库里有 30 万行 agent 写的代码。出了 bug，你 git blame 看到的都是 "Claude Code" 的 commit。你不知道当时的 prompt 是什么，不知道 agent 读了哪些文件，不知道它为什么选了这个方案。
这不是假设——这是 2026 年很多团队的真实状态。Atlas 把这四样东西绑在一起，本质上是在给 agent 写的代码做可审计性基础设施。
和 git 的关系：不是替代，是增强
Atlas 不是另一个 git。它依赖 git，在 git 之上加了一层"reasoning metadata"。你用任何工具 commit——终端、另一个编辑器、甚至 Atlas 关着——它都能通过观察 git 历史把 commit 关联回 session。
这个设计选择很关键：Atlas 不拦截 commit，它观察 commit。这意味着你不需要改变任何现有工作流。Atlas 像一个被动的记录器，在旁边默默工作。
一个值得思考的架构选择
Atlas 把 session 数据存在 SQLite 里，而不是 markdown 或 JSON。README 里有一句解释："because it is queried, not read"——因为 session 数据是用来查询的，不是用来读的。
这是一个很工程化的判断。session 数据量大、结构复杂、查询模式多样（按时间、按文件、按 agent、按关键词），用 SQLite 比用一堆 markdown 文件高效得多。而 knowledge base（人类写的笔记）仍然是 markdown，因为那是"用来读的"。
存储介质匹配使用模式——这个原则看似简单，但很多工具做不到。Notion 把所有东西都存在一个数据库里，包括本该是 markdown 的笔记；很多 agent 框架把所有上下文都塞进 markdown 文件，包括本该是结构化数据的 session 记录。Atlas 在这一点上做了正确的分层。
限制和开放问题
- macOS 优先：Linux 和 Windows 从同一份 Tauri 代码构建，但"untested"。这限制了受众。
- ACP 依赖：agent 必须支持 ACP 才能被 Atlas 管理。目前 Claude Code 和 Codex 是"most-tested path"，registry 里的其他 agent "QA ongoing"。
- 本地优先的代价：团队协作需要 sign in 创建 organisation 才能同步。本地 SQLite 的冲突解决机制没有详细说明。
一句话总结
Atlas 给 agent 写的代码装上了黑匣子——不是替代 git，而是在 git 之上加了一层"谁在什么时候为什么做了这个改动"的可审计层。在 agent 写代码比例越来越高的 2026 年，这种基础设施迟早要有人做。Atlas 的 timing 不错。
GitHub: https://github.com/pacifio/atlas 文档: https://docs.tryatlas.cc/