抛弃 GitHub，去中心化的 Agent 代码管理

GitHub 最近是真不让人省心。10 月 30 日，一天之内连续出现多起故障，Actions、Pages、Webhooks 接连受到影响，代码搜索和实时状态更新也出了问题。10 月 29 日也发生过类似的事，GitHub Actions、Pages 和 Webhooks 同时受到影响。到了 11 月 2 日，Copilot 使用的部分 AI 模型服务又出现了错误。

以前 GitHub 出故障，最多就是代码暂时推不上去，PR 没法合并，CI 跑不起来。现在麻烦大了，因为写代码的已经不只有人，还有一大群 24 小时工作的 Agent。

我现在有个越来越强烈的需求，想把 GitHub 从日常 Agent 开发的核心链路里移出去。不是彻底不用 GitHub，而是让它只负责最后的代码发布、备份和开源协作。平时写代码、同步文件、运行测试，全部在自己的机器之间完成。

Agent 时代，GitHub 这套流程有点跟不上了

以前一个人写代码，一台电脑，一个 Git 仓库，写完提交推到 GitHub，基本没什么问题。现在 Mac mini 上跑着 Claude Code，Linux 服务器上跑着 Codex，VPS 上可能还有几个 Agent 同时处理任务。一个负责写前端，一个负责后端，还有一个负责测试。

这些 Agent 可能同时修改同一个项目，几分钟就产生几十次文件变化。如果还按照以前的流程，每个 Agent 都要先 Commit、Push，其他机器再 Pull。不仅麻烦，还会产生一堆没有实际版本价值的中间提交。最头疼的是，很多修改根本还没达到可以提交的程度，比如 Agent 刚改完一个接口，另一台机器就需要拿到代码运行测试。

Agent 之间真正需要的，是工作文件能够及时到达其他机器。Git 负责版本历史，实时同步应该交给另一套工具。

最近我翻出了一个老牌开源项目 Mutagen（github.com/mutagen-io/mutagen）。这个项目已经存在很多年了，主要解决不同机器之间的实时文件同步问题。它支持文件系统变化监控、增量传输、双向同步、冲突检测和断线重连，通过 SSH 直接连接远程设备，还会自动部署自己的轻量 Agent，不需要提前在远程 Linux 上部署完整服务。

安装一条命令。Mac 上通过 Homebrew 安装 mutagen-io/mutagen/mutagen，然后建立同步任务，两台机器就建立了一个持续同步的工作目录。默认的 two-way-safe 模式会检测无法安全自动处理的冲突，不会随意用一边的修改覆盖另一边。

假设有三台机器：Mac mini 负责日常开发和任务调度，Linux 服务器负责运行测试和编译大型项目，VPS 负责部署和对外提供服务。三台机器各自运行 Agent，各自拥有独立的工作环境。Mac mini 上的 Agent 修改一个功能后，通过 Mutagen 把代码同步到 Linux，Linux 上的 Agent 立即开始执行测试，测试结果和错误日志再通过同步目录传回来供分析。整个过程不用 GitHub，也不需要不断 Push 和 Pull。

甚至可以让不同地区的机器协作，只要它们之间有可用的 SSH 连接。

需要注意的是，Mutagen 本身只能同步文件，不能自动管理 Agent 的任务，也不会帮你解决多个 Agent 同时修改代码产生的逻辑冲突。如果让三个 Agent 同时修改同一个文件，照样可能打架。所以还需要 Git Worktree：给每个 Agent 分配独立的工作目录和分支，让它们分别开发，等完成任务再通过 Git 合并代码。

另外，.git、密钥、依赖目录和临时文件都应该配置同步排除规则，避免无关数据在机器之间扩散。

如果要去中心化，GitHub 也可以换掉

Mutagen 解决的是文件传输，没有提供仓库权限管理、版本审核和协作平台。这部分可以直接使用 Git 本身，Git 就是分布式版本控制系统，每台机器都能拥有完整的提交历史。如果需要一个自己的代码中心，可以部署 Gitea，一台普通 VPS 就能运行。

整个开发流程就变成了：Git Worktree 隔离任务，Mutagen 同步工作文件，Git 管理版本，Gitea 承担内部协作，GitHub 负责对外发布。GitHub 就算出现故障，本地开发、远程测试和内部代码合并仍然可以继续。

Gitea 如果只部署在一台 VPS 上，这台 VPS 仍然可能成为内部服务的单点故障。真正需要高可用时，还得考虑仓库镜像、备份和故障切换。但至少，我们已经把日常开发从 GitHub 的可用性中解耦出来了。

Agent 时代，机器越来越多，任务越来越碎，代码修改也越来越频繁。代码应该能在自己的设备之间自由流动。GitHub 可以继续用，但不应该成为所有机器协作时都必须经过的地方。Mutagen 这个老项目，值得重新翻出来研究。

文中涉及的 GitHub 故障已经按官方记录核实，日期分别对应 2026 年 8 月 17 日、10 月 29 日和 10 月 30 日。Mutagen 的双向同步、冲突处理和增量传输机制也有官方文档支持。文章保留了一个技术边界：Mutagen 能减少对中心服务的文件传输依赖，但多 Agent 并发写入时仍需要工作目录隔离、Git 合并和冲突处理。