Uncle Bob 如何用 tmux 和 git worktrees 组织神经网络

Uncle Bob（Robert Martin），敏捷宣言的发起人以及《代码整洁之道》系列书籍的作者，在 GitHub 上发布了一个名为 SwarmForge 的新项目。在 README 的最顶部，一个红色大写字母的提示要求读者不要购买 SWARM 加密货币代币，作者声明与其没有任何关联。在这个古怪的横幅背后，隐藏着一个有趣的想法：一个由 Unix 工具、zsh 脚本和 git worktrees 构建的多代理系统。

当大多数 AI 框架作者将他们的解决方案塞满繁重的 Python 库时，SwarmForge 在本地以务实的方式解决了问题。

为什么同时运行多个代理

当你给一个基于 Claude 或 Copilot 的程序员一个复杂任务时，它很快就会触及上下文限制。要么如此，要么它悄悄地破坏了相邻的代码。在现实生活中，程序员通过分工解决这个问题。一个人编写规范，另一个人通过 TDD 编写代码，第三个检查架构并进行重构。

SwarmForge 将这种实践带到了神经网络。该工具启动 tmux 会话，为每个代理分配角色和独立的 git worktree，然后在它们之间组织任务交换。因此，代理可以同时在同一个仓库上工作，但在物理上不会相互干扰或覆盖彼此的文件。

现成的角色集

无需冗长的配置，作者提供了从不同仓库分支下载现成场景的选项：

• two-pack 分支。小任务的快速开发：程序员通过 TDD 实现行为，清理者移除重复代码并修复架构缺陷。
• four-pack 分支。标准循环，包含 Gherkin 规范编写者、程序员、重构者和架构师。
• six-pack 分支。完整链条，包含独立的变异强化步骤和 QA 代理。
• 自定义构建。你自己从任意角色集构建的变体，在文本配置中描述。

你可以为每个角色分配一个独立的 CLI 客户端。没有什么能阻止你让 Claude 担任架构师角色，把日常任务交给 Codex 或 Copilot。

代理之间的任务传递

多代理系统的主要问题是代理喜欢互相发送大量消息并丢失上下文。SwarmForge 中神经网络之间没有直接聊天。

SwarmForge 不是直接调用命令，而是在 Babashka（Clojure 脚本解释器）上运行一个后台守护进程。该守护进程监视文件系统中的 outbox 和 inbox 目录 .swarmforge/handoffs/。

当一个代理完成一个阶段时，它调用一个本地脚本 swarm_handoff.sh。该脚本检查交接并创建一个任务文件。如果要传递代码，代理必须指定精确的 10 字符提交哈希。守护进程拾取文件，验证提交，然后将其移动到下一个代理的 inbox 文件夹。

这种方法防止了幻觉。如果神经网络没有将其更改提交到 git worktree，它就无法将工作进一步传递下去。

配置和启动

所有设置都存储在一个简单的文本文件 swarmforge/swarmforge.conf 中。每一行描述一个窗口，并设置其角色、提供者、worktree 名称和附加的 CLI 参数：

在现有项目中启动系统只需几个终端命令。选择一个分支，下载压缩包，然后运行入口脚本：

脚本 ./swarm 检查工具，从 main 分支下载共享脚本，为每个角色初始化 git worktree，并打开 tmux 会话。在 macOS 上它自动拉起 Terminal.app 或 Ghostty，在 Windows 上——来自 WSL 的 Windows Terminal。

启动时，SwarmForge 尝试通过 caffeinate（macOS）或 systemd-inhibit（Linux）阻止操作系统休眠模式，这样代理就不会在工作过程中睡着。

谁将从 SwarmForge 中受益

这个项目留下了有趣的印象。一方面，你可以看到 Uncle Bob 的典型风格：强调 TDD、代码质量指标、Gherkin 规范以及整洁架构的严格规则。另一方面，对 Babashka、tmux 和特定 CLI 工具的依赖使入门门槛显而易见。

如果整洁代码的理念与你产生共鸣，并且你想尝试自主开发而不使用 AutoGen 或 CrewAI 等笨重的框架，SwarmForge 值得一试。它是一个很好的例子，展示了基本的 Unix 工具和正确的 Git 工作流如何帮助协调复杂的 AI 系统。