这是我现在的终端界面。
13 个 Claude Code agent，每个都在自己的 tmux 面板中运行，协作于同一个代码库。不是实验，也不是炫技。这就是我每天交付软件的方式。
这个项目是 Beadbox，一个用于实时监控 AI 编码 agent 的仪表盘。它由它所监控的 agent 团队亲手构建。agent 编写代码、测试、审查、打包、发布。我负责协调。
如果你正在运行两三个以上的 agent，想知道怎么追踪它们的进度，这就是我经过数月迭代最终得出的方案。
团队阵容
每个 agent 都有一个 CLAUDE.md 文件，定义了它的身份、职责范围、职责边界，以及与其他 agent 的通信方式。这些不是万能的通用助手。每一个都有明确的工作范围和清晰的边界。
| 分组 | Agent | 负责领域 |
|---|---|---|
| 协调层 | super, pm, owner | 工作调度、产品规格、业务优先级 |
| 工程层 | eng1, eng2, arch | 功能实现、系统设计、测试套件 |
| 质量层 | qa1, qa2 | 独立验证、发布门禁 |
| 运维层 | ops, shipper | 平台测试、构建、发布执行 |
| 增长层 | growth, pmm, pmm2 | 数据分析、市场定位、公开内容 |
关键词是边界。eng2 不能关闭 issue。qa1 不写代码。pmm 永远不碰应用源码。Super 调度工作但不参与实现。这些边界之所以存在，是因为没有边界的话，agent 会跑偏。它们会"好心"去重构不需要重构的代码，或者关闭未经验证的 issue，或者做出超出它们能力范围的架构决策。
每个 CLAUDE.md 都以身份描述段落和边界部分开头。下面是 eng2 的简化版本：
## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests.
You own implementation quality: the code you write is correct, tested,
and matches the spec.
## Boundary with QA
QA validates your work independently. You provide QA with executable
verification steps. If your DONE comment doesn't let QA verify without
reading source code, it's incomplete.
这个模式可以扩展。当我只有 3 个 agent 时，它们可以共用一个简单的 prompt。到了 13 个，明确的角色和协议是协调与混乱之间的分界线。
协调层
三个工具把整个团队凝聚在一起。
beads 是一个开源的、Git 原生的 issue 追踪器，专为这种工作流设计。每个任务是一个 "bead"，带有状态、优先级、依赖关系和评论线程。agent 通过名为 bd 的 CLI 读写同一个本地数据库。
bd update bb-viet --claim --actor eng2 # eng2 认领一个 bug
bd show bb-viet # 查看完整规格和评论
bd comments add bb-viet --author eng2 "PLAN: ..." # eng2 发布实施计划
gn / gp / ga 是 tmux 消息工具。gn 向另一个 agent 的面板发送消息。gp 查看另一个 agent 的最近输出（不会打断对方）。ga 排队发送一条非紧急消息。
gn -c -w eng2 "[from super] You have work: bb-viet. P2." # 派发任务
gp eng2 -n 40 # 查看进度
ga -w super "[from eng2] bb-viet complete. Pushed abc123." # 汇报完成
CLAUDE.md 协议定义了升级路径、通信格式和完成标准。每个 agent 都知道：认领 bead、编码前发布计划、推送前跑测试、附带验证步骤标记完成、标记等待 QA、向 super 汇报。
Super 每 5-10 分钟执行一次巡检循环：查看每个活跃 agent 的输出、检查 bead 状态、确认流水线没有停滞。就像生产环境的值班轮换，只不过服务对象是 AI agent，"事故"是"eng2 已经安静了 20 分钟，有点可疑"。
真实的一天
下面是 2026 年 2 月下旬某个周三实际发生的事情。
上午 9:14 - 一位名为 ericinfins 的 GitHub 用户提交了 Issue #2：他们无法将 Beadbox 连接到远程 Dolt 服务器。应用只支持本地连接。Owner 看到后标记给 super。
上午 9:30 - Super 分配任务。Arch 设计连接认证流程（TLS 开关、用户名/密码字段、环境变量传递）。PM 编写带有验收标准的规格。Eng 接手开始实现。
同一时间，并行进行：
PM 提交了两个在发布测试中发现的 bug。一个是外观问题：header 标签在最终构建中显示 "v0.10.0-rc.7" 而不是 "v0.10.0"。另一个是平台相关的：截图自动化工具在 ARM64 Mac 上返回空白条带，因为 Apple Silicon 通过 Metal 合成渲染 Tauri 的 WebView，底层缓冲区为空。
Ops 定位了截图 bug 的根本原因。修复方案很优雅：截图后检查图片高度是否异常小（对于应该是 800px 高的窗口，小于 50px），如果是则回退到基于坐标的屏幕截图。
Growth 拉取 PostHog 数据并进行 IP 关联分析。结论是：Reddit 广告产生了 96 次点击，但没有任何可归因的留存用户。GitHub README 流量的转化率是 15.8%。你正在读的这篇文章就是因为这个分析结果而写的。
Eng1 在 arch 完成 Activity Dashboard 设计后解除阻塞，开始构建跨过滤器状态管理和工具函数。687 个测试通过。
QA1 验证 header 标签修复：启动测试服务器，使用浏览器自动化验证标签渲染正确，确认 665 个单元测试通过，标记 PASS。
下午 2:45 - Shipper 合并发布候选 PR，推送 v0.10.0 标签，触发升级工作流。CI 为全部 5 个平台构建产物（macOS ARM、macOS Intel、Linux AppImage、Linux .deb、Windows .exe）。Shipper 验证每个产物，更新两个仓库的发布说明，重新部署网站，更新 Homebrew cask。
下午 3:12 - Owner 在 GitHub Issue #2 上回复：
Good news: v0.10.0 just shipped with full Dolt server auth support. Update and you should be unblocked.
早上报告的 bug，下午就修复发布了。与此同时，下一个功能已经在设计中，另一个 bug 正在定位根因，分析数据在进行中，QA 在独立验证另一个修复。
这不是因为 13 个 agent 速度快。而是因为 13 个 agent 在并行工作。
会出什么问题
这是大多数"看我的 AI 配置"文章省略的部分。
高并发下会触发速率限制。 13 个 agent 在同一个 API 账号上运行时，token 消耗非常快。这一天，super、eng1 和 eng2 同时触碰到了速率上限。所有人停工。只能等。这就像是办公室里所有人同时要用打印机，只不过打印机按页收费，而且有每分钟页数上限。
QA 会打回工作。 这是设计使然，但它增加了周期。QA 拒绝了一个构建，因为工程师的 "DONE" 评论没有包含验证步骤。修复本身是有效的，但 QA 无法在不看源码的情况下确认。返回给 eng，重写完成评论，再交给 QA，重新验证。本该五分钟的事花了二十分钟。协议确实带来了摩擦，但这种摩擦是承重的。每次我试图跳过 QA，生产环境就出问题。
上下文窗口会填满。 Agent 在一次会话中会积累上下文。Super 有一个协议，在上下文用量达到 65% 时发送"保存工作"指令。如果错过这个窗口，agent 就会忘记它在做什么。
Agent 会卡住。 有时候 agent 会陷入错误循环，反复重试同一个失败的命令。Super 的巡检循环能捕捉到这种情况，但前提是你检查得足够频繁。我曾经因为一个在悄悄失败的 agent 浪费了 30 分钟。
协调开销是真实存在的。 CLAUDE.md 文件、调度协议、巡检循环、bead 评论、完成报告。对于两个 agent 的设置来说，这些都是过度设计。对于 13 个 agent，这是最低可行的结构。大约在 5 个 agent 时会有一个交叉点，非正式的协调方式开始失效，你需要明确的协议，否则就会失去对全局的掌控。
我学到了什么
专业化胜过通用化。 13 个专注的 agent 比 3 个"全栈"agent 表现更好。当 qa1 只做验证不写代码时，它每次都能抓到 eng 遗漏的问题。当 arch 只做设计不做实现时，设计更干净，因为没有为了方便实现而走捷径的诱惑。
独立 QA 是不可妥协的。 QA 有自己的仓库克隆。它测试的是推送后的代码，而不是工作目录。它不信任工程师的自我报告。这听起来很慢。但它在每次发布中都能捕捉到 bug。
你需要可见性，否则团队会偏离方向。 在 5 个以上 agent 的情况下，你无法通过在 tmux 面板间切换然后在脑子里跑 bd list 来跟踪状态。你需要一个仪表盘，展示依赖树、哪个 agent 在做什么、哪些 bead 被阻塞了。这就是我构建 Beadbox 要解决的问题。
递归循环很重要。 Agent 构建 Beadbox。Beadbox 监控 agent。当 agent 在 Beadbox 中产生 bug 时，团队通过同样的 QA 流程捕捉到它。工具在进化，因为使用它最多的团队就是构建它的团队。我知道这要么是天才之举，要么是有史以来最精心设计的 Rube Goldberg 机器。已交付的功能指向前者。我的 token 账单指向后者。
技术栈
如果你想自己尝试，以下是你需要的：
- beads：开源的 Git 原生 issue 追踪器。这是协调的基础。每个 agent 都对它进行读写。
- Claude Code：agent 运行时。每个 agent 是一个在 tmux 面板中的 Claude Code 会话，带有自己的 CLAUDE.md 身份文件。
- tmux + gn/gp/ga：终端复用器，用于并排运行 agent。消息工具让 agent 无需共享内存即可通信。
- Beadbox：实时可视化仪表盘，展示整个团队的工作状态。这就是你正在阅读的内容。
你不需要一开始就用 13 个 agent。两个工程师 agent 加一个 QA agent，通过 beads 协调，就会改变你对一个开发者能交付多少东西的认知。
接下来做什么
当前 setup 最大的空白是无法一眼回答三个问题：哪些 agent 是活跃的、空闲的还是卡住的？工作在 pipeline 的哪个环节堆积？以及刚刚发生了什么，按我关心的 agent 或 pipeline 阶段过滤？
目前这需要一个巡逻循环和大量 gp 命令。所以我们正在 Beadbox 中直接构建一个协调仪表盘：顶部的 agent 状态条、显示 beads 在哪里堆积的 pipeline 流程图、以及一个交叉过滤的事件流，点击某个 agent 或 pipeline 阶段就能过滤其他所有内容。三个层共享同一个实时数据源。三个层都实时更新。
13 个 agent 正在构建它。发布后我会写相关文章。