Oak：当 AI Agent 开始自己写代码，Git 还够用吗？

昨天刷 Hacker News 的时候，看到一个帖子冲到了首页——Oak，一个专门为 AI Agent 设计的版本控制系统，125 分，126 条评论。点进去一看，这帮人的思路确实跟我想的不一样。

Oak 的口号是 "version control at the speed of agents"——以 Agent 的速度做版本控制。这句话听着有点玄，但看完文档之后觉得还挺贴切的。

说实话，之前用 Claude Code 和 Codex 的时候，我一直在用 Git，也没觉得有什么大问题。但看到 Oak 的设计理念之后，突然意识到：Git 的那些设计——commit message、merge conflict、full clone——其实都是围绕"人"设计的。AI Agent 的工作方式跟人完全不同，硬套 Git 确实有点别扭。

今天就来聊聊这个 Oak 到底是什么，它解决了什么问题，以及它是不是真的能替代 Git。

先说结论：Oak 短期内不会替代 Git，但它的设计思路值得每个用 AI Agent 写代码的人关注。如果你每天都在用 Claude Code、Codex 或者 Cursor 这些工具，Oak 描述的那个未来可能比你想象的更近。

Git 在 AI Agent 场景下到底有什么问题？

先说说我自己的痛点。用 Claude Code 写代码的时候，经常遇到这种情况：

• 一个 Agent session 里改了十几个文件，commit 的时候发现 message 不知道写啥（Agent 改的东西，你让我总结？）
• 多个 Agent 同时干活，互相踩脚，merge 的时候一堆冲突
• 大仓库 clone 太慢，Agent 等半天才能开始干活
• 每次 commit 都要写 message，但 Agent 的工作方式其实是"一个任务一个分支"，不是"一个改动一个 commit"

这些问题单独看都不大，但加在一起就很烦。

我来举个具体的例子。上周我让 Claude Code 帮我重构一个项目的身份认证模块。它在 20 分钟内改了 15 个文件，做了 8 个 commit。每个 commit 的 message 都是 Agent 自己生成的，写得倒是挺规范的，什么 "refactor: extract auth middleware"、"fix: handle edge case in token refresh"，看着没问题。

但问题是：我回头看这些 commit 的时候，完全不知道它为什么要这么改。commit message 说的是"做了什么"，但没有说"为什么这么做"。Agent 的推理过程全在 context window 里，commit 完就丢了。

更离谱的是，我同时跑了一个 Codex 在改另一个功能，两个 Agent 不知道怎么搞的，改了同一个配置文件。Git 的 merge conflict 检测倒是报了，但 conflict 的内容我看不懂——两边都是 Agent 生成的代码，我怎么知道哪个是对的？

尤其是 commit message 这个事情——Git 的设计假设每次 commit 都有一个人类在旁边写描述，但 AI Agent 的场景下，这个假设不成立了。

Oak 的做法很有意思：直接取消了 commit message。没错，你没看错——Oak 的 feature branch 上的 commit 没有 message。取而代之的是 branch description（分支描述）。你在一个分支上干的所有事情，用一个总的描述来概括，而不是每个 commit 都写一句话。

这其实更符合 Agent 的工作方式：一个 Agent session 完成一个任务，用一个分支来隔离，最后用一个描述来总结这个任务做了什么。

Oak 的核心设计理念

Oak 的定位很明确——它是 AI Agent 的代码基础设施（agentic substrate），不是另一个 GitHub。它不跑 Agent，不管 CI/CD，只做一件事：让 Agent 更方便地读写代码。

几个关键设计：

1. 分支即工作单元

Oak 里，工作单元是 branch，不是 commit。oak init 和 oak clone 都会自动创建一个个人 feature branch，你永远不会直接在 main 上工作。

这跟 Git 的区别在哪里？Git 里你可以随时在 main 上 commit，分支是可选的。Oak 里分支是强制的，每个 Agent session 一个分支，干完活 merge 到 main，不满意的直接丢掉。

2. 分支描述替代 commit message

前面说了，Oak 的 feature branch 上的 commit 没有 message。取而代之的是 oak desc "..." 来设置分支描述。

当你 merge 分支到 main 的时候，Oak 会做一个 squash commit，message 就是分支描述。原始的 commit 历史还是保留的（通过指针），但 main 上只有一条干净的 squash commit。

这个设计的好处是：你不用纠结每个 commit 写什么了。一个任务做了 20 个 commit，最后只需要一个描述："实现了用户登录功能，包括 JWT 认证和 session 管理"。

而且这个描述可以由 Agent 来写。你可以让 Agent 在完成任务后，用 oak desc 写一段人类可读的描述，总结它做了什么、为什么这么做、有什么注意事项。这比每个 commit 写一句 "refactor: extract function" 有用多了。

Oak 的 merge 流程也很有特色：合并分支到 main 的时候，生成的是一个 squash commit，message 就是分支描述。原始的 commit 历史通过指针保留，但 main 的历史干净得一批——每个 commit 对应一个完整的任务，而不是一堆零碎的改动。

3. Lazy Mount（懒加载挂载）

这个是 Oak 最酷的功能之一。传统的 Git clone 会把整个仓库下载下来，大仓库可能要等好几分钟。Oak 的 oak mount 做法不一样——它创建一个虚拟文件系统，文件按需下载。

你 oak mount org/repo 之后，目录结构立刻出现，但文件内容是空壳。你编辑哪个文件，Oak 就从远程拉哪个文件。这对于 Agent 来说特别有用——Agent 可能只需要改几个文件，没必要把整个仓库都 clone 下来。

Mount 运行在后台 daemon 里，oak mount 命令立刻返回。支持 macOS（Apple 的 FSKit）和 Linux（FUSE）。

这个功能对大仓库特别有用。我之前有个项目，仓库有 2GB 多（里面有很多资源文件），Git clone 要等好几分钟。Agent 的场景下更惨——每次开一个新的 Agent session，都要重新 clone 一遍，光等就要等半天。

用 Oak 的 mount，目录结构秒出，文件按需加载。Agent 只需要改 5 个文件？那就只下载这 5 个文件，其他的一概不管。省下来的时间可以干更多活。

Mount 的底层技术很有意思。macOS 上用的是 Apple 的 FSKit（macOS 26 以上），Linux 上用 FUSE。Oak 的团队做了一个叫 OakFS 的文件系统扩展，把远程仓库的内容按需映射到本地目录。编辑操作先存在本地的 mount cache 里，push 的时候才上传。

# Mount 一个仓库

oak mount my-org/large-repo

# 目录立刻出现，文件按需加载

# 查看当前的 mount

oak mount list

# 用完之后卸载

oak mount end

需要注意的是，mount 功能需要一些前置配置。Linux 上要装 FUSE：

sudo apt install fuse3

macOS 上更麻烦一点，需要安装 Oak Mount app，然后在系统设置里启用文件系统扩展。不过只需要配一次，之后就不用管了。

4. Agent Spaces

Agent Space 是一个工作目录，里面可以 mount 多个仓库。比如你的 Agent 需要同时改前端和后端两个仓库，就可以创建一个 space，把两个仓库都 mount 进去，每个有自己的虚拟分支。

这比 Git 的 worktree 更轻量——不需要 full clone，mount 是按需加载的。

HN 社区的反应

Oak 在 Hacker News 上有 125 分，评论区的讨论挺有意思的。有人觉得这是"Git 的下一代"，也有人觉得"Git 够用了，没必要换"。

几个有意思的评论：

有人说："Oak 解决的是一个真实的问题——Agent 不需要 commit message，但 Git 强制你写。" 这个观点我认同。Git 的 commit message 对人来说是有意义的，但对 Agent 来说是纯粹的 overhead。

也有人质疑："Oak 的远程仓库在 oak.space 上，这不就是另一个 GitHub lock-in 吗？" 这也是个问题。Git 的优势之一是分布式的，你可以推到任何远程。Oak 目前只能推到 oak.space，虽然代码是开源的，但自托管还不成熟。

还有人提到了 Git 的 worktree 和 sparse checkout："这些功能已经部分解决了 Oak 想解决的问题。" 确实，Git 不是没有按需加载的能力，只是做得不够彻底。Oak 的 lazy mount 在体验上比 Git 的 sparse checkout 好很多，但 Git 也在往这个方向走。

总的来说，社区对 Oak 的态度是"方向对了，但太早了"。我觉得这个评价很中肯。

Oak 的技术细节

Oak 是用 Rust 写的，开源的，代码在 GitHub 上（oakvcs/oak）。

Oak 是用 Rust 写的，开源的，代码在 GitHub 上（oakvcs/oak）。底层用 BLAKE3 做内容哈希，用 content-defined chunking 做分块。

几个技术亮点：

• 内容寻址：跟 Git 类似，用内容的哈希值作为标识。但 Oak 的 chunking 策略更适合大文件和二进制文件。
• 存储后端：本地用 SQLite，远程有自己的协议。也支持只读的 Git 后端。
• CLI 设计：命令跟 Git 很像（oak clone、oak commit、oak push、oak pull），上手成本不高。

安装也很简单：

curl -fsSL oak.space/install | sh

oak login

目前支持 macOS (Apple Silicon) 和 Linux (x86_64)。Windows 也有实验性支持，用 ProjFS 做 mount。

Oak 的存储设计挺有意思的。本地用 SQLite 存储仓库的元数据，远程有自己的协议。它用 BLAKE3（一个比 SHA-256 快很多的哈希算法）做内容寻址，用 content-defined chunking 做文件分块。

什么是 content-defined chunking？简单说就是：不是按固定大小把文件切成块，而是根据文件内容的特征来决定切哪里。这样做的好处是，文件的局部修改只会影响少数几个 chunk，其他的 chunk 不变，可以复用。Git 里类似的概念是 packfile 的 delta encoding，但 Oak 的做法更适合大文件和二进制文件。

Oak 还有一个很有意思的设计：它不会把所有历史都存在本地。Git 会把整个仓库的历史都 clone 下来（包括你永远不看的 10 年前的 commit），Oak 只存你需要的部分。这也是它比 Git 快的原因之一。

工作流对比：Git vs Oak

为了更直观地理解两者的区别，我来对比一下同一个任务在 Git 和 Oak 下的工作流。

假设你要让 Agent 实现一个用户注册功能：

Git 的工作流：

1. git clone 整个仓库（等 30 秒到几分钟）
2. git checkout -b feature/user-registration 创建分支
3. Agent 开始改代码，每改一段就 git commit -m "xxx"
4. 改完了，推送到远程：git push origin feature/user-registration
5. 在 GitHub 上创建 PR，等 review
6. 合并 PR

Oak 的工作流：

1. oak clone org/repo 或 oak mount org/repo（秒开）
2. 自动在 feature branch 上，不需要手动创建
3. Agent 改代码，oak commit 检查点（不用写 message）
4. 改完了，oak desc "实现用户注册功能：包含表单验证、邮箱确认和密码加密" 然后 oak push
5. Review diff，oak merge 合并到 main

最大的区别：

• Oak 省去了 clone 的等待时间（mount 场景下）
• Oak 省去了写 commit message 的步骤
• Oak 的分支是自动创建的，不需要手动操作
• Oak 的 merge 生成的是 squash commit，main 历史更干净

当然，Git 也有 Oak 没有的东西：PR review 流程、CI/CD 集成、branch protection rules... 这些在 Oak 里要么没有，要么很简陋。所以 Oak 更适合 Agent 主导、人来 review 的场景，不太适合需要复杂协作流程的大团队。

跟 Git 比，Oak 到底强在哪？

说"强"可能不太准确，更准确的说法是"更适合 Agent 场景"。

Git 的优势：

• 生态成熟，工具链完整（GitHub、GitLab、Bitbucket...）
• 社区大，文档多，遇到问题好查
• 人用起来很顺手，commit message 是有意义的

Oak 的优势：

• 分支强制隔离，Agent 之间不会互相踩脚
• Lazy mount 大仓库秒开，不用等 clone
• 分支描述的设计更符合 Agent 的工作方式
• Agent Space 支持多仓库并行工作

Git 没解决、Oak 解决了的问题：

• Agent 不需要写 commit message
• 大仓库的 clone 速度问题
• 多 Agent 并行工作的隔离问题

说实话，如果你只是一个人写代码，Git 完全够用。但如果你在用多个 AI Agent 并行干活，Oak 的设计确实更合理。

实际上手体验

我在自己的 Linux 机器上试了一下 Oak。安装过程很顺利，curl 一行搞定。

curl -fsSL oak.space/install | sh

oak login

登录的时候会在浏览器里打开一个认证页面，授权之后就可以用了。

# 创建一个新仓库

oak init my-agent-project

cd my-agent-project

# 做一些修改

echo "hello oak" > README.md

# 查看状态

oak status

# 提交

oak commit

# 设置分支描述

oak desc "Initial commit: add README"

# 推送

oak push

整体感觉跟 Git 很像，但有几个地方不一样：

1. oak init 之后自动在一个 feature branch 上，不在 main 上。分支名是自动生成的，类似于 zdgeier-abc123 这种格式
2. commit 不需要 message（但可以加 desc）。直接 oak commit 就行，不用绞尽脑汁想 commit message
3. push 的时候会在远程自动创建仓库，不需要提前在网页上创建

我还试了几个其他的命令：

# 查看当前分支和状态

oak status

# 查看改动

oak diff

# 查看 commit 历史

oak log

# 切换到新分支

oak switch -c new-feature

# 设置分支描述

oak desc "这个分支做了 XXX"

# 合并分支到 main

oak merge

命令设计得很简洁，基本上 Git 能做的事情 Oak 都有对应的命令，只是细节上有些不同。比如 oak switch 对应 git checkout，oak desc 是 Oak 独有的。

有一点让我印象深刻：Oak 的 merge 是 squash merge，main 上只有一条 commit。这跟 Git 的默认行为不同——Git 默认是 fast-forward 或者 three-way merge，会保留所有的 commit 历史。Oak 的做法让 main 的历史特别干净，每个 commit 都是一个完整的任务。

我还试了 mount 功能：

我还试了 mount 功能：

oak mount my-org/my-repo

确实秒开，目录结构立刻出现。不过 mount 功能需要 FUSE 支持，Linux 上要先装 fuse3：

sudo apt install fuse3

Oak 的局限性

说了这么多好的，也说说不足：

1. 生态太新：Oak 刚发布没多久（v0.99.0），工具链和社区都不成熟。没有 GitHub 那样的 PR review 流程，没有 CI/CD 集成。
2. 需要迁移成本：现有的 Git 仓库不能直接用 Oak，需要导入。而且团队里其他人可能还在用 Git，你不能只自己用 Oak。
3. Agent 工具链不完善：目前 Claude Code、Codex 这些 Agent 还没有原生的 Oak 支持，需要手动配置。
4. 远程服务依赖：Oak 的远程仓库在 oak.space 上，不是自托管的。对于企业用户来说，这可能是个问题。
5. Windows 支持是实验性的：mount 功能在 Windows 上用 ProjFS，还不太稳定。

适合什么场景？

从我的理解来看，Oak 适合这些场景：

• 多 Agent 并行开发：如果你同时跑 3-5 个 Agent 改不同的功能，Oak 的分支隔离和 Agent Space 很有用。
• 大仓库 + Agent：如果仓库很大（几 GB），传统 Git clone 太慢，Oak 的 lazy mount 可以省很多时间。
• Agent 生成代码的版本管理：如果你主要让 Agent 写代码，人的角色是 review 和 merge，Oak 的设计更匹配这个工作流。

不太适合的场景：

• 小团队日常开发：Git 的工具链和社区支持更完善，没必要换。如果你只是一个人写代码，偶尔用用 Agent，Git 的那些"问题"对你来说根本不是问题。
• 需要完整 Git 功能：Oak 的功能是 Git 的子集，没有 stash、cherry-pick、bisect 这些高级操作。如果你的工作流依赖这些功能，Oak 还替代不了 Git。
• 企业级部署：Oak 还没有自托管方案，安全性、权限管理等方面也不完善。企业用户对代码安全很敏感，把代码存在第三方服务上，很多公司不会接受。
• 开源社区协作：目前 Oak 的协作功能很弱，没有 PR review、没有 branch protection rules、没有 CI/CD 集成。开源项目需要的那些协作工具，Oak 都没有。

说白了，Oak 现在就是一个"Agent 专用的轻量级 Git"。它的价值在于解决 Agent 场景下的特定痛点，而不是全面替代 Git。

Agent 版本控制的未来

Oak 的出现让我想到了一个更大的问题：AI Agent 写代码的比例越来越高，我们的开发工具需要怎么适配？

现在大部分开发者用的工具链——Git、GitHub、VS Code、CI/CD——都是围绕"人写代码"设计的。但 Agent 写代码的方式跟人完全不同：

• Agent 不需要语法高亮和自动补全（它直接输出代码）
• Agent 不需要 commit message（它的工作粒度是一个任务，不是一个改动）
• Agent 不需要 GUI（它用 CLI 和 API）
• Agent 可以同时在多个地方干活（并行 session）
• Agent 的产出是"一批文件的改动"，不是"一个文件的编辑"

这些差异意味着，围绕"人"设计的工具链可能不是最优的。Oak 是第一个明确说"我们要为 Agent 设计版本控制"的项目，但我猜不会是最后一个。

想象一下，未来的开发工具可能是这样的：

• 版本控制系统专门为 Agent 优化（Oak 已经在做了）
• 代码 review 工具能理解 Agent 的推理过程（不只是看 diff）
• CI/CD 系统能自动验证 Agent 生成的代码（不只是跑测试）
• 项目管理工具能直接给 Agent 下任务（不只是给人分配 issue）

这些听起来很远，但其实已经在发生了。Claude Code 的 hooks、Codex 的 sandbox、各种 MCP server——这些都是在往"Agent 原生"的开发工具方向走。

我的看法

Oak 的方向是对的。随着 AI Agent 写代码的比例越来越高，版本控制确实需要围绕 Agent 的工作方式来重新设计。Git 的那些假设——人类写 commit message、人类决定什么时候 commit、人类处理 merge conflict——在 Agent 场景下确实不太合适。

但 Oak 现在还太早了。v0.99.0，功能还在快速迭代，生态基本为零。短期内 Git 还是主流，Oak 更像是一个前瞻性的探索。

不过有一点很有意思：Oak 的设计思路可能会被 Git 吸收。比如 Git 的 worktree 和 sparse checkout 其实已经在往"按需加载"的方向走了，只是做得还不够彻底。如果 Git 以后加上类似 lazy mount 的功能，Oak 的优势就没那么明显了。

我觉得最值得关注的是 Oak 的"分支描述替代 commit message"这个设计。这个思路很简单，但很实用。即使不用 Oak，在 Git 里也可以借鉴——让 Agent 用一个总的描述来总结一个分支的所有改动，而不是纠结每个 commit 的 message。

说一个我自己的实践：自从看了 Oak 的设计之后，我用 Git 的方式也变了。现在让 Agent 干活的时候，我会先创建一个专门的分支，让 Agent 随便 commit（message 写什么都行），最后让 Agent 用一段话总结整个分支做了什么。然后我在 merge 的时候用 squash commit，message 就用 Agent 的总结。

效果还不错。main 的历史变得很干净，每个 commit 都是一段完整的任务描述，而不是一堆 "fix typo"、"wip"、"refactor xxx" 这样的碎片。

另外，Oak 的 lazy mount 思路也可以用在 Git 上。Git 的 sparse checkout 和 partial clone 已经部分实现了按需加载，只是体验没有 Oak 那么丝滑。如果你的仓库很大，可以试试：

# Git 的 partial clone，只下载需要的对象

git clone --filter=blob:none https://github.com/org/repo

# Git 的 sparse checkout，只检出部分目录

git sparse-checkout init --cone

git sparse-checkout set src/ docs/

这两个功能加在一起，效果跟 Oak 的 lazy mount 差不多，只是配置麻烦一点。

怎么试？

如果你想试试 Oak：

1. 安装：curl -fsSL oak.space/install | sh
2. 登录：oak login
3. 创建仓库：oak init my-project
4. 像用 Git 一样用它（但不用写 commit message）

目前 Oak 是免费的，在 public beta 阶段。文档在 oak.space/docs，代码在 GitHub（oakvcs/oak）。

常见问题

在研究 Oak 的过程中，我整理了几个大家可能会问的问题。

Oak 跟 GitHub 是什么关系？

Oak 是版本控制系统（相当于 Git），GitHub 是代码托管平台（在 Git 之上加了 PR、Issue、CI/CD 等功能）。Oak 有自己的远程仓库服务 oak.space，但它不是 GitHub 的替代品——它连 PR review 流程都没有。

你可以把 Oak 理解为"专门为 Agent 优化的 Git"。至于代码托管和协作，Oak 目前还很简陋。

现有的 Git 仓库能迁移到 Oak 吗？

Oak 支持只读的 Git 后端，也就是说你可以把 Git 仓库的内容导入到 Oak 里。但迁移之后的协作流程会变——你的团队成员都需要用 Oak 的 CLI，不能再用 Git 的命令了。

对于已经在用 Git 的团队来说，迁移成本不低。Oak 更适合新项目，或者 Agent 主导的项目。

Oak 的安全性怎么样？

Oak 的代码是开源的，可以审计。远程仓库在 oak.space 上，Oak 声称不会用你的代码来训练模型。但跟所有云服务一样，你需要信任他们的基础设施。

如果你对代码安全性要求很高（比如企业内部项目），Oak 目前还不支持自托管，这是个硬伤。

Oak 和 Git 能共存吗？

目前不太行。Oak 有自己的数据格式和协议，跟 Git 不兼容。你不能把 Oak 的仓库推到 GitHub，也不能把 Git 的仓库直接用 Oak 的命令操作。

不过 Oak 的底层库 oakvcs-core 是独立的，理论上可以开发一个 Git-Oak 的桥接工具。但目前还没有人做。

我应该现在就切换到 Oak 吗？

大概率不需要。除非你同时在跑多个 AI Agent，且遇到了 Git 的痛点（clone 慢、commit message 烦、分支管理混乱），否则 Git 完全够用。

Oak 现在还是 beta，功能不完善，工具链也还没跟上。把它当作一个有意思的新方向来看看就好，没必要现在就迁移。

延伸阅读

如果你对 Agent 版本控制这个话题感兴趣，可以看看这些：

• Oak 的官方文档：oak.space/docs
• Oak 的 GitHub 仓库：github.com/oakvcs/oak
• HN 上的讨论帖：搜 "Oak Git alternative agents"
• 我之前写的 Context Engineering 文章，聊了 Agent 的上下文管理问题
• 我之前写的 Agentic Coding 文章，聊了 Agent 写代码的工作方式

后面打算拿 Oak 来跑几个 Agent 任务，看看实际效果怎么样。特别是想试试多个 Agent 并行干活的场景——这才是 Oak 真正发力的地方。到时候再写一篇详细的使用体验。

另外，Oak 的 lazy mount 功能我也想深入测一下。我有个 2GB 的项目，用 Git clone 要 3 分钟，看看 Oak mount 能快多少。有啥问题评论区聊。