写代码的人大概都经历过这种事：让 AI 智能体改一个文件，它改完了，但你想看看它到底动了什么、为什么这么改、能不能回退——然后你在 git 的提交记录里翻半天，找不到一个清晰的入口。提交是逐次的、线性的，而 AI 的工作方式是分支的、会话级的。这两套逻辑根本对不上。Oak 版本控制就是为解决这个错位而生的工具，它不打算做 git 的替代品，而是完全绕开 git 三十年的设计包袱，从零开始为 AI 智能体的编码工作流重建一套版本控制逻辑。
一个反 git 而生的版本控制工具
Oak 的设计者显然研究透了 git 的历史包袱。git 当年是为 Linux 内核那种大规模人工协作设计的，它的每一次提交都假设背后有一个知道自己在干什么的开发者。但 AI 智能体不是这样工作的——它在一个会话里可能生成十几个文件改动，然后又把它们全部丢弃，重新来一遍。用 git 去记录这种行为，就像用记账本去录一场乒乓球赛：每一下挥拍都记了，但完全看不出比赛节奏。
分支就是会话，不是一组提交
Oak 最核心的模型转换是：把分支当作会话的容器，而不是提交的集合。在 Oak 里，你创建一个分支，就是开启了一段与 AI 智能体的对话；智能体在这个会话里改的每一个文件、做的每一次实验，都挂在这个分支下。当你满意了，合并；不满意，扔掉分支重来。这跟 git 那种「先一次次 commit，最后再合并分支」的工作流正好反过来。
对智能体而言，这种模型天然贴合。Claude Code、Cursor、Codex 这类工具本来就是在会话里运行的，它们不需要一个线性历史，只需要一个稳定的、可回滚的沙盒。Oak 的分支直接承载这个沙盒角色，智能体随时可以创建分支实验，随时可以丢弃，仓库本身不会因为这些试探性操作变得臃肿。
内容寻址的懒加载
git 用 SHA-1 做内容哈希，Oak 用的是 BLAKE3——速度更快、抗碰撞性更强。但真正的杀手锏是分块策略：Oak 不是把整个文件作为哈希单元，而是把文件内容切成块，每一块独立寻址。重复内容只存一份，改动只更新变动的块。
这意味着什么？智能体在大型代码库里只需要编辑一个文件，Oak 不必克隆整个仓库历史，懒加载机制让它只拉取和写入真正变动的部分。结果就是：编辑任意规模仓库只需数秒。这个数字不是营销话术，而是 BLAKE3 哈希速度加上内容定义分块共同挤出来的实际性能。
数据模型：四层结构，干净利落
Oak 的底层数据模型只有四个层级：Blob、Manifest、Commit、Tree。Blob 存内容，Manifest 记录分块信息，Tree 描述目录结构，Commit 指向某个 Tree 的快照。每一层都是内容寻址的，引用靠哈希而不是路径。
Blob 与 Manifest：分块存储的最小单元
Blob 是原始内容块，一个文件可能被切成几十个 Blob。Manifest 把这些 Blob 组装回完整的文件，并记录分块边界和哈希。这套机制的直接好处是去重——两个相似文件共享的公共部分只存一次。在 AI 编码场景下，这个特性极其实用：智能体经常基于现有文件做小幅修改，Oak 能识别出公共块，只存储差异部分。
反过来，这也让仓库的「体积」失去了传统意义。一个看起来很大的 monorepo，在 Oak 里的实际存储量可能小得多，因为重复模板、相似组件、测试 fixture 都被去重了。
Commit 与 Tree：分支会话的骨架
Commit 在 Oak 里不再是一堆文件改动的日志，而是一个指向 Tree 的指针，加上元数据。Tree 描述的是某个时刻的完整目录状态。智能体的每一次会话结束时，那个分支指向一个新的 Commit，而 Commit 背后的 Tree 快照就是这次会话的成果。
对比 git 那种「commit 是 diff 的累积」的设计，Oak 走的是「commit 是状态的快照」的路子。两者各有适用场景，但对于 AI 智能体这种「频繁创建、频繁丢弃」的工作模式，快照模型显然更轻量、更直观。
后端可选：SQLite 还是 git
Oak 提供了两种后端存储：原生 SQLite 和 git 兼容层。这个设计选择很务实——对于新项目，直接用 SQLite 后端，享受完整的 Oak 体验；对于已有 git 仓库的项目，git 后端让你无缝接入，渐进式迁移。
SQLite 后端：完整的 Oak 体验
SQLite 后端是 Oak 的主战场，所有特性——分块存储、懒加载、分支会话模型——都完整支持。对于从零开始的新项目，或者愿意把版本控制逻辑彻底交给 Oak 的团队，这个后端是首选。本地一个文件，零配置，速度拉满。
git 后端：渐进迁移的安全网
git 后端的存在说明 Oak 的设计者没有宗教情怀。已有大量 git 提交历史的项目不需要一夜之间迁移到 Oak，git 后端让 Oak 读取和写入 git 仓库，逐步验证新工作流的可行性。等到团队适应了分支-会话模型，再切到 SQLite 后端也不迟。
速度碾压：这不是夸张，是设计必然
Oak 团队宣称「速度远超 git」，这话听起来像营销话术，但拆开看其实有扎实的技术根据。git 的速度瓶颈在哪？每次 checkout 要遍历大量对象、每次 diff 要做行级比较、每次 status 要扫描整个工作区。这些操作在 AI 智能体高频次、小颗粒度的调用模式下被放大了。
哈希算法代差
BLAKE3 相比 SHA-1 是碾压级别的存在——更快、更安全、并行度更高。在内容寻址系统里，哈希计算是高频操作，算法本身的提速直接转化为全链路的提速。这不是软件优化的层级，而是底层密码学原语换代带来的红利。
懒加载改变工作流
传统 git 的工作流是「先克隆完整仓库，再开始工作」。Oak 的懒加载让智能体可以直接进入工作状态，需要什么拉什么。对于 AI 智能体这种「接到任务→定位文件→编辑→验证」的模式，懒加载把准备工作压缩到了几乎为零。
安装与生态：门槛几乎为零
Oak v0.99.0 已经发布公开测试版，支持 macOS（Apple Silicon）、Linux（x86_64）、Windows 三大平台。安装方式极简：一条 curl 命令，或者通过 cargo 装。Apache-2.0 开源协议，没有使用限制。
这意味着任何正在用 Claude Code、Cursor、Codex 做 AI 辅助编码的团队，今天就可以把 Oak 拉下来试。不需要复杂的环境配置，不需要迁移现有仓库（用 git 后端即可），不需要说服整个团队——单个开发者就能先跑起来体验。
对于那些已经对 git 的提交噪音感到疲惫的 AI 智能体用户来说，Oak 提供了一种回归直觉的工作方式：分支就是会话，改动随时可丢弃，仓库不会因为智能体的试探性操作变得难以管理。这不一定是版本控制的终局形态，但它是目前最贴合 AI 编码实际工作流的方案之一。v0.99.0 的公开测试版邀请所有用 agent 写代码的开发者亲自验证：当你和 AI 协作时，版本控制本该是这个样子。
