这是我现在的终端界面。
13 个 Claude Code agent，每个都在自己的 tmux 面板中运行，协作于同一个代码库。不是实验，也不是炫技。这就是我每天交付软件的方式。
这个项目是 Beadbox，一个用于实时监控 AI 编码 agent 的仪表盘。它由它所监控的 agent 团队亲手构建。agent 编写代码、测试、审查、打包、发布。我负责协调。
如果你正在运行两三个以上的 agent，想知道怎么追踪它们的进度，这就是我经过数月迭代最终得出的方案。 一个 bug 在早上 9 点被报告，下午 3 点修复就上线了，同时还有四条工作流在并行推进。并非总是一帆风顺，但吞吐量是真实的。
团队阵容
每个 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 汇报。
这是实际操作中的样子。这是今天的一个真实 bead：super 分配任务，eng2 评论一个编号计划，eng2 评论 DONE 并附上 QA 验证步骤和已勾选的验收标准，super 将其转交给 QA。
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 在并行工作。
