📌 项目地址：unclebob/swarm-forge | ⭐ 1,770 颗星 | 🔧 Clojure | 📜 未标注
多代理协作工具大多面临同一个问题：多个 AI 代理共享同一份代码，A 改了文件，B 不知道，然后就互相覆盖。SwarmForge 的解法是用 git worktree——每个代理有独立的工作副本。这个 Clojure 项目在 GitHub 上有 1770 个 star，出自 Bob Uncle 之手，是一个基于 tmux 的代理编排平台。
它不是 prompt 调度器，是套工程流程
很多 agent 工具做的事情是：你给一个任务，它拆解后分别发给不同模型，然后汇总结果。SwarmForge 不是这个思路。它把代理当成真实团队里的工程师，分配给每个人的是独立的 git worktree，通过 tmux 会话管理它们的运行状态，通过消息传递机制做交接。
这意味着每个代理看不到其他人没提交的改动，只能看到已经提交的部分。这从机制上杜绝了文件冲突，而机制约束比靠 prompt 告诉代理”不要动别人的文件”可靠得多。
main 分支是文档，可运行配置在别的分支
这个仓库的分支结构值得单独说。main 分支不承载任何可运行的工作流，它只做两件事：
- 存放共享操作脚本
- 存放默认宪法条款（constitution articles，即协作规则的纲领性文档）
真正可运行的配置在工作流分支上，比如 two-pack、four-pack、six-pack。每个工作流分支包含：
swarmforge/swarmforge.conf（分支专属配置）- 本地宪法条款
- 各角色的 system prompt
启动入口是根目录的 ./swarm 脚本。运行时会先检查共享脚本和共享宪法条款是否已存在，如果不存在就从 main 复制过来，然后启动当前分支的本地配置。
三种工作流，对应三种项目规模
two-pack：快速后端闭环
两个角色。coder 用 TDD 和单元测试实现功能；cleaner 接手 coder 的产出，做清理、CRAP 和 DRY 审查、架构审查、封装和关注点分离修复，还有语言突变（mutation）加固。流程是 coder -> cleaner -> coder 循环。适合不需要 Gherkin 规格和验收测试的小任务，但保留后端质量保障。
four-pack：紧凑规格工作流
四个角色。specifier 把人话需求转成精确的 Gherkin 验收规格，交接前要经过用户批准；coder 用 TDD 和单元测试实现已批准的行为切片，同时生成验收测试；refactorer 做保持行为的重构、覆盖率改进、CRAP/DRY 审查、突变位点扫描和属性测试支持；architect 管高层结构、依赖方向、突变加固，最后发完成通知。流程是 specifier -> coder -> refactorer -> architect -> specifier。中等项目适用，每个角色担一摊，但不至于像 six-pack 那样把每个质量门禁都单独拆人。
six-pack：完整工作流
README 原文到 “backend verificati” 就截断了，后面的内容在公开的 README 里看不到。能确定的是它面向需要完整规格、前期 QA 和后端验证的大型项目，角色划分比 four-pack 更细。想用这个分支得先去看对应分支的实际配置。
这套设计值钱在哪
我理解 SwarmForge 的价值在于它承认了一个事实：当前的大模型单次输出靠不住，但多代理协作的难点不在模型，在工程编排。
代理之间的信息传递、进度同步、交接时机，这些才是决定一个多代理系统能不能落地的东西。SwarmForge 用 tmux 把这些都变成可观察、可介入的会话结构——你可以随时 attach 进去看某个代理在干什么，而不是面对一个黑盒。
另一个值得说的点是它的分支设计。共享的脚本和宪法条款在 main，工作流配置在分支上，不同分支代表不同的协作纪律。这种把”工具”和”使用策略”分开的做法，让同一个项目里可以并行存在多种工作流，切换只是 git checkout 的事。
使用前需要知道的事
- README 开头有一句黑体警告：Do not spend any money on a bankrbot SWARM token。不要为与之同名的 SWARM 代币花钱，和这个项目本身没有关系。
- 需要熟悉 git worktree 和 tmux 的基本操作，否则遇到代理卡住、会话挂起时无从下手。
- 角色定义是固定的，你选择的是工作流分支，而不是自由定制合作模式。它适合接受纪律化流程的人，不适合只丢个 prompt 等结果的场景。
- six-pack 的文档不完整，README 在 “backend verificati” 处截断，使用前应直接查看该分支的目录和配置文件。
- 项目本身用 Clojure 编写，但使用层面主要操作的是 shell 脚本、tmux 和 git。
这套工具适合已经厌倦了 agent 互相搞破坏、想尝试用工程手段约束协作过程的人。它不是银弹，但它把多代理协作的工程底子打得很扎实。