1. 多 Agent 并行编程为什么总在互相踩脚如果你同时开过两个 AI 编程助手改同一个仓库大概率见过这种场面Agent A 刚把utils.py重构成异步Agent B 还在按旧签名调用它两边提交一合并测试全红。问题不在模型能力而在工作区没有隔离。多个 Agent 共享一个工作目录、一份暂存区、一条分支本质上就是让几个人在同一张纸上同时写字。SwarmForge 这个框架的思路很直接给每个 AI 智能体分配独立的 git worktree 和独立的 tmux session让它们在物理层面互不干扰再通过一套持久化的交接协议交换已提交的工作。你可以把它理解成一个工地每个工人有自己的工位worktree、自己的对讲机频道tmux session干完一段活就通过标准流程把成果交到下一道工序而不是所有人挤在一个台面上抢工具。这套机制解决的核心痛点有三个。第一是并行度单 Agent 工具一次只能推进一条任务线而真实项目里写实现补测试重构审架构可以同时进行。第二是可追溯每次交接都有审计日志谁在什么时候把哪个 commit 交给了谁一清二楚。第三是人工监督操作员通过本地仪表板随时审批、澄清、中止而不是等 Agent 跑完才发现方向错了。适合谁用如果你已经在用 Claude Code、Codex 这类单 Agent 工具但遇到任务一多就排队的瓶颈或者你在做多 Agent 协作的研究与实验SwarmForge 值得跑一遍。它不替代你的编辑器而是编排多个 Agent 的工作流。下面我从环境准备讲到验证隔离每一步都能直接复制执行。2. 前置准备git worktree 与 tmux 的协作底座在装 SwarmForge 之前得先理解它依赖的两个底座否则后面排查问题会一头雾水。git worktree 是什么一个仓库可以挂多个工作目录每个目录检出不同分支但共享同一个.git对象库。这意味着你不需要 clone 三份代码就能让三个 Agent 各自在一个独立目录里改代码、各自提交互不覆盖。创建命令是git worktree add ../proj-coder -b feat/coder之后../proj-coder就是一个独立工作区。tmux 是什么终端复用器一个窗口能切成多个 pane每个 pane 跑一个独立进程还能 detach 后继续在后台运行。SwarmForge 用它给每个 Agent 开一个会话这样你关掉终端Agent 照样干活重新 attach 就能看到实时输出。SwarmForge 的运行时架构大致是这样swarmforge.sh解析配置、创建 worktree、拉起 Agentswarm_handoff.*负责交接的创建、接收、合并与审计handoffd.*做投递排队和通知pack_board.*把卡片、审批、澄清渲染到本地仪表板。理解这条链路后面看日志就知道卡在哪一环。环境要求清单如下缺一个都会在启动时报错依赖作用检查命令zsh脚本运行 shellzsh --versiongitworktree 隔离git --versiontmux会话编排tmux -VBabashka (bb)运行 .bb 脚本bb --versionAgent 后端至少一个claude/codex/grok/copilotBabashka 是最容易被忽略的一个它是 Clojure 的轻量运行时SwarmForge 的部分逻辑用.bb写。装好后先跑bb --version确认能输出。关于 Agent 后端SwarmForge 支持混合使用比如 coder 角色用 Claude、cleaner 角色用 Codex。这里就涉及到一个实际工程问题多个 Agent 要调用模型 API如果每个都单独配 key、单独管额度运维会很乱。我自己的做法是统一走一个兼容 Anthropic 与 OpenAI 协议的接入层把 Base URL、Key、Model ID 三件套集中管理这样切换后端只改配置不改脚本。如果你也想用这种方式统一管理多 Agent 的模型调用可以先去 TaoToken 的 API Keys 页面 生成一个 key再对照 接入文档 把 Base URL 填进各 Agent 的配置。这样六个 Agent 并行时额度、日志、模型切换都在一处排查某个 Agent 没响应会快很多。3. 可复制配置worktree 初始化脚本与 tmux 分屏这一节给你能直接落地的配置。先装 Helper它是官方推荐的入口因为要从多个分支组合文件mkdir -p ~/cmds curl -L -o ~/cmds/get-swarm-forge \ https://raw.githubusercontent.com/unclebob/swarm-forge/main/get-swarm-forge chmod x ~/cmds/get-swarm-forge export PATH$HOME/cmds:$PATH把export PATH那行写进~/.zshrc否则新开终端就找不到命令。装好后在现有项目里安装 six-packcd /path/to/your/project get-swarm-forge six-pack ./swarm./swarm启动后会自动创建 worktree、拉起 tmux 会话、打开本地仪表板。如果你想手动控制 worktree 的创建可以用下面这个初始化脚本它把每个 Agent 的工作区、分支、tmux 会话一次性建好#!/usr/bin/env zsh # init-swarm-worktrees.sh set -euo pipefail REPO_ROOT$(git rev-parse --show-toplevel) SWARM_DIR${REPO_ROOT}/../swarm-workspaces mkdir -p $SWARM_DIR # 角色 - 分支 映射 typeset -A ROLES ROLES( spec swarm/spec impl swarm/impl cleanup swarm/cleanup arch swarm/arch hardening swarm/hardening qa swarm/qa ) for role branch in ${(kv)ROLES}; do wt${SWARM_DIR}/${role} if [ ! -d $wt ]; then git worktree add -b $branch $wt main echo [worktree] created $role - $branch else echo [worktree] exists $role fi # 每个角色一个 tmux 会话detach 后继续运行 if ! tmux has-session -t swarm-${role} 2/dev/null; then tmux new-session -d -s swarm-${role} -c $wt echo [tmux] session swarm-${role} started fi done git worktree list执行chmod x init-swarm-worktrees.sh ./init-swarm-worktrees.sh你会看到六个 worktree 和六个 tmux 会话被创建。git worktree list的输出能确认每个目录挂在哪个分支上。接下来是swarmforge.conf它定义每个窗口跑哪个 Agent、什么角色、什么任务模式# swarmforge.conf window coder claude master task forward-only window cleaner codex cleaner task forward-only window architect claude architect batch back-all这段配置的意思是coder 窗口用 Claude 后端、角色 master、任务模式 forward-onlycleaner 用 Codex、角色 cleanerarchitect 用 Claude、batch 模式处理 back-all 任务。如果你把后端换成走统一接入层就在各 Agent 的环境变量里设置三件套export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的key export ANTHROPIC_MODELclaude-sonnet-4-5Base URL 用https://taotoken.net/api不要带查询参数。Model ID 按你实际订阅的模型填别照抄。三个变量配齐Agent 才能正常发起请求缺任何一个都会在启动阶段报认证错误。4. 验证请求确认工作区互不干扰且合并可追溯配置写完必须验证否则你只是以为隔离生效了。验证分三层worktree 是否真隔离、tmux 会话是否独立、交接是否可追溯。第一层验证 worktree 隔离。在两个不同 worktree 里改同一个文件看是否互相影响# 在 impl 工作区改文件 cd ../swarm-workspaces/impl echo impl change README.md git status --short # 切到 qa 工作区看同一文件 cd ../swarm-workspaces/qa git status --short预期结果impl 里README.md显示 modifiedqa 里工作区干净。如果 qa 也显示 modified说明两个 Agent 其实共享了目录隔离失败回去检查 worktree 路径是否重复。第二层验证 tmux 会话独立。列出所有会话并 attach 其中一个tmux ls # 输出应包含 swarm-spec / swarm-impl / swarm-cleanup ... tmux attach -t swarm-impl在swarm-impl里跑pwd应该输出 impl 的 worktree 路径。按Ctrl-b ddetach再 attachswarm-qapwd应输出 qa 路径。两个会话的工作目录不同说明编排正确。第三层验证交接可追溯。SwarmForge 的交接通过swarm_handoff.sh发送、ready_for_next.sh接收、done_with_current.sh完成。跑一次完整交接cd ../swarm-workspaces/impl git add -A git commit -m feat: impl task done ./swarm_handoff.sh --to cleanup --message impl 完成待清理然后查看审计日志cat .swarm/handoff.log日志里应记录时间戳、来源角色、目标角色、commit hash、消息。这条记录就是合并可追溯的证据——任何一次工作交接都能回溯到具体 commit。验证模型请求是否通。在任意 Agent 会话里发一条最小请求确认能拿到响应。如果你用统一接入层可以先在 模型对话页面 手动测一次同样的 Model ID确认模型可用再回到 Agent 里跑。这样能把模型不可用和Agent 配置错两类问题分开。成功的结果长这样仪表板里六个 Agent 卡片各自显示状态交接卡片出现在审批队列git worktree list显示六条独立分支tmux ls显示六个会话handoff.log有完整记录。四样都对说明整套并行协作跑通了。5. 常见报错排查401、local proxy failed 与 reading choices多 Agent 并行时报错往往集中在认证和网络层。下面按真实遇到的错误逐条拆。401 Unauthorized。最常见几乎都是 Key 或 Base URL 配错。检查顺序先确认ANTHROPIC_API_KEY没有多余空格和换行再确认ANTHROPIC_BASE_URL是https://taotoken.net/api而不是带/v1或查询参数的地址。如果六个 Agent 里只有某一个报 401说明那个会话的环境变量没继承检查 tmux 启动时是否-c到了正确目录、是否 source 了配置文件。修完后tmux kill-session -t swarm-xxx再重建环境变量才会重新加载。local proxy failed / connection refused。这个报错通常不是模型侧问题而是本地网络出口或代理配置残留。先env | grep -i proxy看有没有遗留的HTTP_PROXY/HTTPS_PROXY有就 unset 掉。再确认 DNS 能解析、端口没被防火墙拦。如果你在容器里跑检查容器网络是否能出网。这类错误和模型无关别去改 Model ID。reading choices of undefined。这是 OpenAI 兼容协议里典型的响应解析错误意思是客户端期望拿到choices数组但实际响应结构不对。原因通常是 Base URL 指向了不兼容的端点或者 Model ID 填成了另一个协议体系的模型名。解决方法是核对三件套Base URL 必须是兼容端点Key 必须对该端点有效Model ID 必须是该端点支持的模型。三者协议要对齐混用就会解析失败。OAuth 相关报错。某些 Agent 后端走 OAuth 登录而非 API Key如果同时配了 Key 和 OAuth可能冲突。检查该后端的配置文件确认认证方式唯一。用统一接入层时建议全部走 Key 认证避免 OAuth 令牌过期导致某个 Agent 半夜掉线。worktree 报 already checked out。说明同一分支被两个 worktree 占用。git worktree list找到冲突项git worktree remove path移除多余的再重建。每个角色必须对应唯一分支这是隔离的前提。tmux 会话 attach 后无输出。Agent 可能已经退出。tmux attach -t swarm-xxx后看最后几行如果是认证错误就回到 401 排查如果是脚本报错检查bb是否在 PATH 里。Babashka 缺失时.bb脚本会静默失败表现就是会话空转。排查时记住一个原则先分层再定位。认证层Key/Base URL/Model ID、网络层代理/DNS/端口、编排层worktree/tmux、协议层choices 解析四层分开测每层用最小命令验证比盯着一个报错瞎改快得多。如果你在认证层反复卡住直接去 接入文档 对照三件套的填写格式多数 401 都是格式问题。6. 长期跑多 Agent把 Coding Plan 与交接协议用起来跑通一次 demo 和长期稳定运行是两回事。六个 Agent 并行token 消耗是单 Agent 的数倍如果按量计费账单会很难看。我实测下来长期做多 Agent 协作更适合用包月式的 Coding Plan把额度固定下来再按角色分配预算。具体做法是把 spec、impl、cleanup 这类高频角色放在额度充足的通道arch、hardening、qa 这类低频但重要的角色按需调用。SwarmForge 的swarmforge.conf支持每个窗口独立配置后端你可以让高频角色走一个后端、低频角色走另一个成本结构立刻清晰。想了解额度方案可以看 Coding Plan 页面按你的 Agent 数量估算一下。交接协议是长期运行的另一个关键。swarm_handoff.sh发送、ready_for_next.sh接收、done_with_current.sh完成这三步必须严格走不能图省事直接git merge。因为交接日志是审计的唯一来源跳过它出问题就无法回溯是哪个 Agent 在哪个 commit 引入了 bug。我的习惯是每天收工前cat .swarm/handoff.log | tail -50看一遍当天的交接链异常早发现。还有一个容易忽略的点worktree 会随分支增多而膨胀。定期git worktree prune清理已删除分支的残留git worktree list确认没有孤儿目录。tmux 会话也一样跑完的会话用tmux kill-session关掉避免几十个会话堆着占资源。如果你要把这套流程接到 CI 或自动化脚本里建议把 Agent 的调用统一走 API 层用 API Keys 页面 管理凭证脚本里只读环境变量不硬编码 key。这样换 key、加 Agent、调模型都只改一处。最后说个真实经验多 Agent 并行最容易翻车的不是技术而是任务边界没划清。两个 Agent 被分到有依赖关系的任务交接就会死锁。启动前用 spec 角色先把任务拆成无依赖的原子项再分发给 impl、cleanup、qa整个 swarm 才能顺畅流动。SwarmForge 给了你隔离和交接的工具但任务怎么切还是得人来想清楚。 
长河君 · 2026/10/17 2:06:24 · 阅读 1.2k SwarmForge 多 Agent 并行协作：用 git worktree 与 tmux 隔离工作区实战
1. 多 Agent 并行编程为什么总在互相踩脚如果你同时开过两个 AI 编程助手改同一个仓库大概率见过这种场面Agent A 刚把utils.py重构成异步Agent B 还在按旧签名调用它两边提交一合并测试全红。问题不在模型能力而在工作区没有隔离。多个 Agent 共享一个工作目录、一份暂存区、一条分支本质上就是让几个人在同一张纸上同时写字。SwarmForge 这个框架的思路很直接给每个 AI 智能体分配独立的 git worktree 和独立的 tmux session让它们在物理层面互不干扰再通过一套持久化的交接协议交换已提交的工作。你可以把它理解成一个工地每个工人有自己的工位worktree、自己的对讲机频道tmux session干完一段活就通过标准流程把成果交到下一道工序而不是所有人挤在一个台面上抢工具。这套机制解决的核心痛点有三个。第一是并行度单 Agent 工具一次只能推进一条任务线而真实项目里写实现补测试重构审架构可以同时进行。第二是可追溯每次交接都有审计日志谁在什么时候把哪个 commit 交给了谁一清二楚。第三是人工监督操作员通过本地仪表板随时审批、澄清、中止而不是等 Agent 跑完才发现方向错了。适合谁用如果你已经在用 Claude Code、Codex 这类单 Agent 工具但遇到任务一多就排队的瓶颈或者你在做多 Agent 协作的研究与实验SwarmForge 值得跑一遍。它不替代你的编辑器而是编排多个 Agent 的工作流。下面我从环境准备讲到验证隔离每一步都能直接复制执行。2. 前置准备git worktree 与 tmux 的协作底座在装 SwarmForge 之前得先理解它依赖的两个底座否则后面排查问题会一头雾水。git worktree 是什么一个仓库可以挂多个工作目录每个目录检出不同分支但共享同一个.git对象库。这意味着你不需要 clone 三份代码就能让三个 Agent 各自在一个独立目录里改代码、各自提交互不覆盖。创建命令是git worktree add ../proj-coder -b feat/coder之后../proj-coder就是一个独立工作区。tmux 是什么终端复用器一个窗口能切成多个 pane每个 pane 跑一个独立进程还能 detach 后继续在后台运行。SwarmForge 用它给每个 Agent 开一个会话这样你关掉终端Agent 照样干活重新 attach 就能看到实时输出。SwarmForge 的运行时架构大致是这样swarmforge.sh解析配置、创建 worktree、拉起 Agentswarm_handoff.*负责交接的创建、接收、合并与审计handoffd.*做投递排队和通知pack_board.*把卡片、审批、澄清渲染到本地仪表板。理解这条链路后面看日志就知道卡在哪一环。环境要求清单如下缺一个都会在启动时报错依赖作用检查命令zsh脚本运行 shellzsh --versiongitworktree 隔离git --versiontmux会话编排tmux -VBabashka (bb)运行 .bb 脚本bb --versionAgent 后端至少一个claude/codex/grok/copilotBabashka 是最容易被忽略的一个它是 Clojure 的轻量运行时SwarmForge 的部分逻辑用.bb写。装好后先跑bb --version确认能输出。关于 Agent 后端SwarmForge 支持混合使用比如 coder 角色用 Claude、cleaner 角色用 Codex。这里就涉及到一个实际工程问题多个 Agent 要调用模型 API如果每个都单独配 key、单独管额度运维会很乱。我自己的做法是统一走一个兼容 Anthropic 与 OpenAI 协议的接入层把 Base URL、Key、Model ID 三件套集中管理这样切换后端只改配置不改脚本。如果你也想用这种方式统一管理多 Agent 的模型调用可以先去 TaoToken 的 API Keys 页面 生成一个 key再对照 接入文档 把 Base URL 填进各 Agent 的配置。这样六个 Agent 并行时额度、日志、模型切换都在一处排查某个 Agent 没响应会快很多。3. 可复制配置worktree 初始化脚本与 tmux 分屏这一节给你能直接落地的配置。先装 Helper它是官方推荐的入口因为要从多个分支组合文件mkdir -p ~/cmds curl -L -o ~/cmds/get-swarm-forge \ https://raw.githubusercontent.com/unclebob/swarm-forge/main/get-swarm-forge chmod x ~/cmds/get-swarm-forge export PATH$HOME/cmds:$PATH把export PATH那行写进~/.zshrc否则新开终端就找不到命令。装好后在现有项目里安装 six-packcd /path/to/your/project get-swarm-forge six-pack ./swarm./swarm启动后会自动创建 worktree、拉起 tmux 会话、打开本地仪表板。如果你想手动控制 worktree 的创建可以用下面这个初始化脚本它把每个 Agent 的工作区、分支、tmux 会话一次性建好#!/usr/bin/env zsh # init-swarm-worktrees.sh set -euo pipefail REPO_ROOT$(git rev-parse --show-toplevel) SWARM_DIR${REPO_ROOT}/../swarm-workspaces mkdir -p $SWARM_DIR # 角色 - 分支 映射 typeset -A ROLES ROLES( spec swarm/spec impl swarm/impl cleanup swarm/cleanup arch swarm/arch hardening swarm/hardening qa swarm/qa ) for role branch in ${(kv)ROLES}; do wt${SWARM_DIR}/${role} if [ ! -d $wt ]; then git worktree add -b $branch $wt main echo [worktree] created $role - $branch else echo [worktree] exists $role fi # 每个角色一个 tmux 会话detach 后继续运行 if ! tmux has-session -t swarm-${role} 2/dev/null; then tmux new-session -d -s swarm-${role} -c $wt echo [tmux] session swarm-${role} started fi done git worktree list执行chmod x init-swarm-worktrees.sh ./init-swarm-worktrees.sh你会看到六个 worktree 和六个 tmux 会话被创建。git worktree list的输出能确认每个目录挂在哪个分支上。接下来是swarmforge.conf它定义每个窗口跑哪个 Agent、什么角色、什么任务模式# swarmforge.conf window coder claude master task forward-only window cleaner codex cleaner task forward-only window architect claude architect batch back-all这段配置的意思是coder 窗口用 Claude 后端、角色 master、任务模式 forward-onlycleaner 用 Codex、角色 cleanerarchitect 用 Claude、batch 模式处理 back-all 任务。如果你把后端换成走统一接入层就在各 Agent 的环境变量里设置三件套export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的key export ANTHROPIC_MODELclaude-sonnet-4-5Base URL 用https://taotoken.net/api不要带查询参数。Model ID 按你实际订阅的模型填别照抄。三个变量配齐Agent 才能正常发起请求缺任何一个都会在启动阶段报认证错误。4. 验证请求确认工作区互不干扰且合并可追溯配置写完必须验证否则你只是以为隔离生效了。验证分三层worktree 是否真隔离、tmux 会话是否独立、交接是否可追溯。第一层验证 worktree 隔离。在两个不同 worktree 里改同一个文件看是否互相影响# 在 impl 工作区改文件 cd ../swarm-workspaces/impl echo impl change README.md git status --short # 切到 qa 工作区看同一文件 cd ../swarm-workspaces/qa git status --short预期结果impl 里README.md显示 modifiedqa 里工作区干净。如果 qa 也显示 modified说明两个 Agent 其实共享了目录隔离失败回去检查 worktree 路径是否重复。第二层验证 tmux 会话独立。列出所有会话并 attach 其中一个tmux ls # 输出应包含 swarm-spec / swarm-impl / swarm-cleanup ... tmux attach -t swarm-impl在swarm-impl里跑pwd应该输出 impl 的 worktree 路径。按Ctrl-b ddetach再 attachswarm-qapwd应输出 qa 路径。两个会话的工作目录不同说明编排正确。第三层验证交接可追溯。SwarmForge 的交接通过swarm_handoff.sh发送、ready_for_next.sh接收、done_with_current.sh完成。跑一次完整交接cd ../swarm-workspaces/impl git add -A git commit -m feat: impl task done ./swarm_handoff.sh --to cleanup --message impl 完成待清理然后查看审计日志cat .swarm/handoff.log日志里应记录时间戳、来源角色、目标角色、commit hash、消息。这条记录就是合并可追溯的证据——任何一次工作交接都能回溯到具体 commit。验证模型请求是否通。在任意 Agent 会话里发一条最小请求确认能拿到响应。如果你用统一接入层可以先在 模型对话页面 手动测一次同样的 Model ID确认模型可用再回到 Agent 里跑。这样能把模型不可用和Agent 配置错两类问题分开。成功的结果长这样仪表板里六个 Agent 卡片各自显示状态交接卡片出现在审批队列git worktree list显示六条独立分支tmux ls显示六个会话handoff.log有完整记录。四样都对说明整套并行协作跑通了。5. 常见报错排查401、local proxy failed 与 reading choices多 Agent 并行时报错往往集中在认证和网络层。下面按真实遇到的错误逐条拆。401 Unauthorized。最常见几乎都是 Key 或 Base URL 配错。检查顺序先确认ANTHROPIC_API_KEY没有多余空格和换行再确认ANTHROPIC_BASE_URL是https://taotoken.net/api而不是带/v1或查询参数的地址。如果六个 Agent 里只有某一个报 401说明那个会话的环境变量没继承检查 tmux 启动时是否-c到了正确目录、是否 source 了配置文件。修完后tmux kill-session -t swarm-xxx再重建环境变量才会重新加载。local proxy failed / connection refused。这个报错通常不是模型侧问题而是本地网络出口或代理配置残留。先env | grep -i proxy看有没有遗留的HTTP_PROXY/HTTPS_PROXY有就 unset 掉。再确认 DNS 能解析、端口没被防火墙拦。如果你在容器里跑检查容器网络是否能出网。这类错误和模型无关别去改 Model ID。reading choices of undefined。这是 OpenAI 兼容协议里典型的响应解析错误意思是客户端期望拿到choices数组但实际响应结构不对。原因通常是 Base URL 指向了不兼容的端点或者 Model ID 填成了另一个协议体系的模型名。解决方法是核对三件套Base URL 必须是兼容端点Key 必须对该端点有效Model ID 必须是该端点支持的模型。三者协议要对齐混用就会解析失败。OAuth 相关报错。某些 Agent 后端走 OAuth 登录而非 API Key如果同时配了 Key 和 OAuth可能冲突。检查该后端的配置文件确认认证方式唯一。用统一接入层时建议全部走 Key 认证避免 OAuth 令牌过期导致某个 Agent 半夜掉线。worktree 报 already checked out。说明同一分支被两个 worktree 占用。git worktree list找到冲突项git worktree remove path移除多余的再重建。每个角色必须对应唯一分支这是隔离的前提。tmux 会话 attach 后无输出。Agent 可能已经退出。tmux attach -t swarm-xxx后看最后几行如果是认证错误就回到 401 排查如果是脚本报错检查bb是否在 PATH 里。Babashka 缺失时.bb脚本会静默失败表现就是会话空转。排查时记住一个原则先分层再定位。认证层Key/Base URL/Model ID、网络层代理/DNS/端口、编排层worktree/tmux、协议层choices 解析四层分开测每层用最小命令验证比盯着一个报错瞎改快得多。如果你在认证层反复卡住直接去 接入文档 对照三件套的填写格式多数 401 都是格式问题。6. 长期跑多 Agent把 Coding Plan 与交接协议用起来跑通一次 demo 和长期稳定运行是两回事。六个 Agent 并行token 消耗是单 Agent 的数倍如果按量计费账单会很难看。我实测下来长期做多 Agent 协作更适合用包月式的 Coding Plan把额度固定下来再按角色分配预算。具体做法是把 spec、impl、cleanup 这类高频角色放在额度充足的通道arch、hardening、qa 这类低频但重要的角色按需调用。SwarmForge 的swarmforge.conf支持每个窗口独立配置后端你可以让高频角色走一个后端、低频角色走另一个成本结构立刻清晰。想了解额度方案可以看 Coding Plan 页面按你的 Agent 数量估算一下。交接协议是长期运行的另一个关键。swarm_handoff.sh发送、ready_for_next.sh接收、done_with_current.sh完成这三步必须严格走不能图省事直接git merge。因为交接日志是审计的唯一来源跳过它出问题就无法回溯是哪个 Agent 在哪个 commit 引入了 bug。我的习惯是每天收工前cat .swarm/handoff.log | tail -50看一遍当天的交接链异常早发现。还有一个容易忽略的点worktree 会随分支增多而膨胀。定期git worktree prune清理已删除分支的残留git worktree list确认没有孤儿目录。tmux 会话也一样跑完的会话用tmux kill-session关掉避免几十个会话堆着占资源。如果你要把这套流程接到 CI 或自动化脚本里建议把 Agent 的调用统一走 API 层用 API Keys 页面 管理凭证脚本里只读环境变量不硬编码 key。这样换 key、加 Agent、调模型都只改一处。最后说个真实经验多 Agent 并行最容易翻车的不是技术而是任务边界没划清。两个 Agent 被分到有依赖关系的任务交接就会死锁。启动前用 spec 角色先把任务拆成无依赖的原子项再分发给 impl、cleanup、qa整个 swarm 才能顺畅流动。SwarmForge 给了你隔离和交接的工具但任务怎么切还是得人来想清楚。