Show HN：Oak —— 为 agents 设计的 Git 替代方案

Oak 是什么及其核心理念

• 新一代版本控制系统，定位为 Git 替代方案，尤其面向 AI agents。
• 关键特性：通过 FUSE/FSKit 实现虚拟/网络挂载、对所有文件采用分块存储（无需单独的 LFS）、简化分支，以及集成式托管。
• 强调快速、并行的“每个任务一个分支”工作流，以及对 monorepo 友好的特性（例如：可将子树开源，同时保持其余部分私有）。

性能、挂载与 agent 工作流

• 支持者认为：挂载让 agents 无需完整 clone 即可工作，这对大型仓库、频繁任务和大量并行工作区很有帮助。
• 其宣称的收益包括：比 Git 更快的操作、通过结构化/JSON 输出减少 VCS 相关 token、以及云端 agent 更快的启动速度。
• 质疑者认为：对大多数 agent 工作流来说，VCS 延迟和 token 用量只占整体 LLM 成本和耗时的极小一部分；真正的瓶颈是人类的决策过程。

“面向 Agents” 的定位

• 支持者：Git 的 worktree 和重 clone 工作流，并不适合高并发 agent 场景；专门的默认设置和挂载方式在规模化时可能很重要。
• 批评者：模型本身已经非常熟悉 Git；任何新的 VCS 都要先付出学习成本，并需要技能/文档支持。很多人认为 Git + 少量 wrapper、hooks 或 harness 技巧就足够了。
• 尚不明确：如果对 Git 做精心封装和优化后，Oak 的收益是否仍然显著。

Git 的痛点与替代 VCS

• 常被提到的 Git 问题包括：大型二进制文件和 LFS、submodule、monorepo 扩展、笨拙的 worktree、历史重写，以及可用性问题。
• 不少人提到其他系统（Mercurial、Fossil、Jujutsu、Pijul、Sapling、Perforce、Epic 的 Lore、Google Piper/CitC、Meta 的 EdenFS）作为更好 UX 或虚拟化 checkout 的先例。
• 有人建议 Oak 本可以做成 Git 的 backend/wrapper；作者更倾向于从零开始设计，但也提到未来与 Git 互操作的可能性。

UX、信息传达与产品定位

• 多条评论指出：主页/博客让人困惑，过于自我宣传，且缺少具体对比和数据模型说明。
• 明确建议应先说明：Oak 相比 Git 好在哪里、为什么 agents 尤其受益，以及真实基准测试结果。
• 总体情绪：这个想法很有意思；但如果没有比性能和挂载更清晰的价值主张，采用起来会非常困难。