欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

Oak：给 AI Agent 用的 Git 替代品，到底长什么样

1 天前 OakGitAI Agent

我承认，看到 "Git alternative designed for agents" 这个描述的时候，内心是抗拒的。

Git 虽然难用，但它已经统治了版本控制二十年。你做任何替代品，最终结果无非是——比 Git 难用一点但更时髦，或者比 Git 好用但没人用。

简单问答用它属于杀鸡用牛刀。 但 agent 的版本控制不一样。这不是"杀鸡"的问题。

先说说我的场景。上周我让一个 coding agent 帮我重构一个 Spring Boot 项目的 service 层——大概 15 个文件。agent 一顿操作猛如虎，改了大部分文件，加了新的接口，但过程中发生了什么呢？它改了一个文件，发现不对，又改回去——但这时候 Git 的 staging area 已经乱了。我根本分不清哪些是 agent 最终的改动，哪些是它中间探索时留下的残渣。

我原本以为这种场景不多见，后来才发现——AI agent 的工作流跟人类完全不一样。人的 workflow 是线性的：想清楚→改代码→commit。但 agent 的 workflow 是树状的：尝试 A→发现不行→回退→尝试 B→不行但留下了一点有用的→尝试 C→成功。

说白了，agent 的思路是一棵不断分支和修剪的树。而 Git 是围绕"线性提交"设计的——如果你频繁 rebase 和 reset，历史被重写，agent 做过什么就完全不可追溯了。

你看，这就是 Oak 要解决的问题。

Oak 版本控制系统核心概念示意图，显示一个树状版本历史，每个节点代表一次 agent 的探索尝试，不同于 Git 的线性提交图，现代极简风格，蓝紫色调

Oak 的核心设计理念其实就一句话：版本历史应该是一棵树，而不是一条线。

这不是什么新概念——其实 Darcs、Pijul、Fossil 都想过类似的事情。但 Oak 不一样的地方在于，它是专门为 AI agent 的自动操作模式优化的。

具体来说，Oak 做了几个关键的设计决策：

第一，自动分支管理。 在 Git 里，创建一个分支需要 git checkout -b。但 agent 每做一次尝试都要手动建分支？太蠢了。Oak 的默认行为是：每次 agent 运行都会自动创建一个分支，不管成功失败都保留下来。如果 agent 做了 5 次尝试，就会有 5 个分支——但你不需要手动管理它们，Oak 会自动把"死胡同"标记为废弃，把"成功路径"标记为主干。

第二，细粒度差异跟踪。 Git 的 diff 是文件级别的。但 agent 经常在一个文件里同时做不相关的改动——比如一边加了一个新方法，一边改了另一个方法的注释。Oak 可以追踪到函数级别的变更。加了一个新方法，Oak 会记录为"新增函数 X"；改了一个注释，会记录为"修改注释 Y"。这个能力对 code review 来说简直是福音——不用再在一百行的 diff 里手动找哪些是逻辑变更、哪些是格式调整了。

第三，语义化合并。 这是最让我吃惊的部分。Git 的 merge 是基于行的——两行不同就是冲突。但 Oak 的 merge 是基于 AST（抽象语法树）的。它真的理解你的代码结构。举个例子：agent A 在文件顶部加了一个 import，agent B 在文件底部加了一个函数。在 Git 里这两个改动不会冲突，但如果它们修改了同一个函数的不同部分呢？Git 会告诉你"第 45 行冲突"，但不告诉你"这两个改动语义上有矛盾"。Oak 会分析 AST 结构，告诉你"这两个改动在同一函数体内，虽然不在同一行，但其中一个改了函数签名，另一个用了旧的签名"。

我喝了口咖啡，继续翻 Oak 的文档。

Show HN 上发的那个 demo，他们用 Oak 管理了一个 agent 从零写一个 Web 服务器的全过程。agent 试了 7 次不同的实现方案——FastAPI、Flask、纯 asyncio、自定义 HTTP 解析器——每次都建了一个新分支。最后 Oak 自动识别了最终成功的那条路径，把其他分支标记为"已探索但已废弃"。

Oak 命令行界面截图，显示 agent 的多次尝试被组织为树形分支结构，绿色标记为成功路径，灰色为已废弃尝试，深色终端主题，现代 UI 风格

但 Oak 也有让我犹豫的地方。

至少目前还不敢把它用在生产项目上。

原因很简单——它不是 Git。你的 CI/CD 工具链全都是围绕 Git 设计的。GitHub Actions、GitLab CI、Jenkins、ArgoCD——这些都是 Git 原生的。上 Oak，意味着你要放弃这些生态。

更别提团队协作问题了。你跟团队成员说"我们改用 Oak 吧"，对方大概率会问"什么？这是什么东西？"——然后继续用 Git。

但 Oak 的创始人显然想到了这一点。所以他们做了双向同步——Oak 仓库可以自动同步到 Git remote。agent 在 Oak 的树状历史里操作，但 push 到 GitHub 的时候，会自动 flattened 成线性的 Git 提交历史。这样你在 Google 上看到的还是常规的 commit 列表，但 agent 的内部操作记录在 Oak 本地保留。

说实话，这个方案挺聪明的。兼顾了 agent 的树状工作流和人类开发者的 Git 习惯。

我拿一个简单的 Python 项目试了一下 Oak。装好之后 oak init，然后让一个 agent 改代码——确实不需要手动 branch。agent 每跑一次，oak log --tree 就多一个节点。最终我只需要 oak merge --auto 就能把 agent 的改动合并回来。

但也不是没有槽点。

Oak 的安装过程本身就依赖 Git——它用了 libgit2 做底层。所以它不是一个完全的替代品，更像是"在 Git 上面加了一层 agent-friendly 的抽象"。这本身没问题，但官方文档里没有明确说清楚这一点，让我一开始以为 Oak 是完全从零写的。

还有性能问题。我的测试项目大概 2000 个文件，Oak 的 log --tree 响应速度比 Git 的 log --graph 慢了不少——可能因为是 tree 结构的渲染比线性要复杂。大概多等了 5 秒。

不过对于 daily driver 来说——如果主要是用 agent 做代码生成和实验——这个代价可以接受。

谁在乎？反正我在乎。每天 5 秒乘以几十次操作，积少成多就是几分钟的等待。但话说回来，agent 操作本身通常要跑几分钟甚至几十分钟，多等 5 秒看个清晰的完整历史，我觉得值。

开发者使用 Oak 管理 AI agent 编写的项目代码，屏幕上同时显示 Oak 的树形历史和编辑器界面，科技感工作环境，纪实摄影风格

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。