Swarmfile：面向多智能体时代的流式版本控制系统

TLDR 版本#

Swarmfile 是一个现代版本控制系统（VCS），旨在以几乎无限的规模容纳数百万个文件、数 PB 级内容，范围限定于桶存储，并支持 LAN+WAN 点对点共享和做种，从而在克隆仓库时实现最低延迟。

我们使用虚拟文件系统挂载将仓库暴露为本地驱动器——因此你可以拥有一个数 PB 级、由云支持（或 EC 分片）的驱动器，它能快速出现并可供使用，同时占用极少的本地磁盘空间。

我提到过我们支持大文件，也支持 git-LFS，但我们也支持代码等小文件。我们自己就是程序员，我们想构建一种感觉像 Git 的东西。许多概念仍然沿用（分支、合并、标签、发布等），但也有一些全新的概念，我们已尽力详细记录，以便让你在全新的 VCS 以及它在多智能体 AI 时代的相关性方面获得最佳起点。

我们的文档在这里，或者你可以把我们所有文档放入 LLM 并向它提问。

较长版本#

我们为什么构建这个？#

2025 年底，在运营另一家初创公司时，我和我的联合创始人（我们都叫 Matt）与一位潜在客户进行了交谈，他们迫切需要解决一个长期问题。

他们处理非常大的 PDF 文件，将其导出到 SharePoint（从美国），并依赖由印度一个大型团队驱动的手动工作流程。印度团队会下载、修改 PDF 文件，然后重新上传回 SharePoint，供我们的客户下载、复核、批注，然后再次上传以进行更多更改。

每次往返大约需要九个小时，在此期间，每个办公室的同事都必须减少带宽消耗。

如果我们拆解一下：

该组织正在为 SharePoint 存储付费。
两个办公室在传输窗口期间生产力都会下降。
对于整个文件传输，出口流量和带宽成本是实实在在的钱。
在许多情况下，只有几 MiB 的文件需要更改。
一些同事不得不下载与其他同事相同的文件——导致同一文件的带宽重复消耗。
此外，他们还要为 VPN 使用和出口/传输使用付费。

我做了一些研究，发现 iroh 生态系统可以解决其中许多问题。一个基于 Rust 的本地引擎可以在 LAN 和 WAN 规模上协调做种和共享，仅在需要时共享已更改的数据块。为了进一步扩展这个理论系统，我认为每个用户可以选择将部分工作卸载到带有 LRU 缓存的本地 NAS，甚至使用纠删码在 iroh 集群成员之间进行分片。

随着我们实现的推进，我们意识到企业需要安全控制（例如 OIDC SSO、SCIM 等），这促使我们构建了端到端加密层、VCS 等，这基本上就是我们今天所处的位置。

最初的用例（美国-印度那个）现在看起来像这样：

该组织正在为兼容 S3 API 的桶付费。
所有同事几乎立即看到文件更改，无论身处何地。
实际文件下载只下载应用程序所需的文件部分，因此感觉很快。
不需要 VPN，因为静态端到端加密和传输中加密满足了他们的需求。
相同的 ACL 权限集仍然应用于他们的文件。
没有人会等待九个小时，带宽争用已成为过去。

它很快，非常快，我们已经在数百万文件的规模上测试过它，涉及数十万文件的变更集和合并，文件夹深度达数千层。

为什么要使用这个？#

在前几段中，我其实只是非常简要地触及了许多用例和功能。但你可以这样理解 Swarmfile：

兼具 Dropbox 的便利性和 Git 的版本控制。它可以处理 PB 级存储和数百万个文件。它几乎不占用你机器上的空间。同事的更改会迅速同步过来。它是为多智能体协作而设计的。

以上涵盖了众多复杂用例，无法在此一一列举——但以下是 Swarmfile 独有的一些用例：

当用户正在上传文件时，你可以跳转到文件中你想查看的部分，即使上传仍在进行中。 —— 想象一下，你的同事正在上传一个大视频，通常你必须等到文件完全上传后才能观看文件的任意部分。使用 Swarmfile，你可以影响文件哪些块优先上传，从而更早看到有意义的部分。这适用于任何类型和任何大小的文件。
多个 AI 智能体可以在本地机器上处理同一份代码。 —— 想象一下，你启动了 7 个 Claude Code 实例，正在并行地疯狂开发多个新功能。突然，Claude 不得不停下来，因为它发现有多个重叠的智能体在编辑相同的文件。使用 Swarmfile，每个分支都可以挂载为独立的驱动器，这样智能体们可以互不干扰地工作，永远不必停下。或者，你可以多次挂载同一个分支，并依赖文件锁。
离线工作，即使是大文件也不例外 —— 当前大多数工作实践要求文件必须先回到云端（或某个中央存储），同事才能看到它。借助 Swarmfile 的局域网对等节点播种，我们可以使用纠删码将你的文件分散到网络中的对等节点上，这样文件和它们的变更无需接触云端即可传输。你可以把 Swarmfile 的云存储视为获取新数据块的后备手段，而不是每次克隆都必须经过的通道。在这些场景中，本地配备一个 NAS 作为对等节点进行热读取是合理的。
勒索软件已成为过去式 —— 目前勒索软件的工作原理是加密公司数据，然后要求赎金才肯解密。Swarmfile 内置了勒索软件检测功能，可以捕获大规模文件篡改并阻止它。即使我们漏掉了，每个文件和每次变更都有 Merkle-DAG 支持的修订历史，可用于回滚文件更改。
不要浪费算力等待“克隆” —— 目前，如果你从版本控制系统克隆、复刻或下载项目，你需要支付几种不同的代价——首先，你必须等待文件下载完成，而且（如果你运行的是云托管的智能体）在下载期间你还要为算力付费。使用 Swarmfile，这两种代价都不会全额支付，因为当挂载出现时所有文件几乎立即可用，文件只在被读取/需要时才会下载。

希望我们在这里已经概述了足够的内容，既能引起你的好奇心，又能抓住你的注意力，但还有更多功能有待介绍，我们也计划在未来数月乃至数年内交付更多。

开源和供应商锁定方面呢？#

简而言之，开源已在路线图上，而供应商锁定是我们积极想要避免的。

关于开源这个话题，我们已经发布了一些代码，并且我们将在新的一年（2027年）发布更多内容。但我们知道，开源需要大量的基础工作和容量规划，而作为一家初创公司，我们目前还不具备这些条件。我们担心这会让我们不堪重负。

关于供应商锁定：

我们已经支持 git-LFS，就像许多其他提供商一样。
我们拥有 Git 原生接口，没有理由停止使用 Git 工具。
你的数据属于你自己，你可以随时提取。
你可以自带存储桶（兼容 S3 API）。
你可以将所有更改的运行副本保存在一个兼容 S3 API 的存储桶中，我们会持续更新它（作用域限定在某个分支）。
我们已经在开源我们的东西了。
CI 可以在我们的计算资源或你的计算资源上运行——托管 CI 开箱即用地运行你的任务，而自托管运行器加上 webhook 让你可以在自己的机器上运行工作，并将事件推送到你控制的端点。
今天开始使用没有任何特殊要求——我们不，也永远不会强制要求任何特定的生态系统（例如 Windows、Azure、AWS 等）。

关于 Swarmfile 上的开源，今天还有一个有趣的故事可以讲——我们从每个付费席位中每月捐出 0.50 美元的税款，捐给你选择的一个 Open Collective 项目，或者系统会随机为你选择一个。

每个付费席位都可以选择这 0.50 美元税款的去向，并且他们每个月都可以重新选择。

我们的愿望是成为 Open Collective 的财政托管方，这样选择在 Swarmfile 上开源的项目就能更容易地根据使用情况（例如来自克隆、复刻、发布下载）按比例（想想 Spotify）收取那 0.50 美元税款中的相应份额。

但这是一条漫长的路，需要 Merchant of Record 集成，而我们目前还不具备处理这些的能力。但与此同时，我们可以通过 Open Collective 捐款来提供透明度。

它熟悉吗？#

是的。它只是一个驱动器（或一个文件夹）——它也兼容 Git，所以没有理由停止使用 Git。

我们的 API、CLI 和适用于 Windows、Linux 和 macOS 的桌面应用在功能上也大致对等。

起点是“挂载”或（共享驱动器）。如果用户不想深入了解 Swarmfile 的任何技术细节，那么他们只需要知道自己的共享驱动器即可。他们可以从 S:\ 保存和读取文件，像平常一样进行日常工作，不会有任何问题。

如果你来自 Git，那么熟悉感会很重要——我们的大多数工具都使用与 Git 相似的措辞，并且在措辞不完全相同时会尝试为你指明正确的方向。此外，共享驱动器可能会感觉有点“诡异”，因为我们会立即“将项目挂载到卷中”（而不是“将仓库克隆到文件夹中”）。但如果你愿意，仍然可以使用 Git。

如果你今天打开我们的桌面应用，你会发现它大致具有 Dropbox Desktop 和 GitHub Desktop 的外观和感觉——我们希望这个界面对所有用户来说都是惯用且熟悉的，并且它支持适合各种技术水平的功能，包括用户可能认为只有 CLI 才有的更高级功能。

对于更高级的用户，我们提供了命令行界面（CLI），其功能比桌面应用略多，可用于为 CI 运行器、渲染农场等提供支持，并且我们提供了全面的文档来支持它。

总体而言，许多措辞和工具与 Git 类似，但有一些偏差。Swarmfile 存在于许多竞争领域，我们本可以从 SVN、Perforce、Mercurial、AccuRev 或其他工具借用术语，但 Git 对作者来说很熟悉，希望对我们许多用户也是如此。

我们是 Git 吗？#

不，但我们是 Git 原生的，我们的协作是 GitHub 形态的。这意味着我们有一个有主见的 Git 原生界面，作为易于采用的入口，尽管通过这种方式使用，你无法获得 Swarmfile 提供的所有优势。

作为一个流式、点对点的虚拟文件系统，我们与 Git 有很大不同，这让我们有自由去做 Git 无法做到的事情，同时提供 Git 所提供的保证。

数百万个文件——经过测试和验证。我们的限制不是空间，而是时间——文件越多意味着某些操作可能需要更多时间。
数千层深的文件夹——经过测试和验证。如果你需要两千层深的文件夹并应用 ACL 权限，我们可以做到。
大规模合并——已证明可处理数十万个文件，我们不推荐这样做，但如上所述，限制在于时间。
安全——细粒度权限意味着用户永远不会看到你不想让他们看到的文件。
原生二进制对象存储——我们最初就是为大型二进制大对象构建的。
原生 S3 兼容存储桶写入——任何 S3 API 兼容的都可以。
原生 ACL 权限集成——我们与 Windows 配合良好。
以及更多……

你今天就可以通过安装我们的工具，然后使用 git clone swarmfile://<org>/<project> 克隆项目，来将 Git 与 Swarmfile 一起使用。

我们刚刚开始#

2026 年 10 月是我们的上线期，我们刚刚开始，并打算继续前进。我们是一家自力更生的初创公司，希望我们给你留下了足够的印象，让你愿意尝试我们——作为回报，我们会让你了解最新动态，我们会不断改进，我们会奖励开源，我们会倾听你的需求。

希望能在 swarm 中见到你。

Matt。