我怎么同时管十几个 AI agent

我同时推进八个项目，高峰时有 17 个 agent 在运行。

我用 Herdr 管理它们。Herdr 是面向编程 agent 的终端工作区：每个 agent 占一个窗格，Herdr 能识别它处于工作、阻塞、完成还是空闲状态；agent 之间也可以读取彼此的输出、互发消息。

但工具只解决了可见性。真正的瓶颈是我的注意力：逐个窗格切换，每次都要重建这个项目的上下文。agent 越多，我越会成为整个系统里最慢的一环。

我的做法是两层结构，再加一个专门替我巡检的 agent。

和主 agent 深谈，对所有 agent 浅读

同时存在两种对话：

• 我和主 agent：深度对话。 每个项目有一个主 agent，掌握该项目的完整上下文。设计、计划和待决事项，我直接和它对齐。
• 编排 agent 和所有 agent：浅层读取。 编排 agent 不负责任何项目。它每 5 分钟读取所有 agent 的最新输出，只把需要我处理的事报告给我。

这样我不必逐个切换项目也能掌握全局；需要深入时，只进入一个项目，只和一个主 agent 对话。

结构只有两层。 主 agent 可以启动子 agent，例如评审、某个 PR 的实现者，或几个并行的小组；子 agent 不再启动下一层。这样每个 agent 与掌握上下文的主 agent 最多相隔一层，产出由主 agent 验收。层级再深，责任边界会变得模糊，上下文也会逐层流失。

四种角色

• 我： 和各主 agent 确定方向；处理需要我决策的问题、审批对话框，以及只能由我在网页上完成的操作。写云资源、改基础设施这类高风险操作，由我亲自确认。
• 主 agent： 对一个项目负责：上下文、计划、PR，以及一份记录当前状态的文件。自己开的 PR 负责到合并为止，包括 CI、评审意见和冲突。可以启动子 agent，并验收其产出。
• 子 agent： 为主 agent 完成一项边界明确的任务，例如实现一个 PR、评审一份设计、做一轮清理。向主 agent 汇报，完成后关闭。
• 编排 agent： 不负责任何项目或 PR。每 5 分钟巡检所有 agent，报告需要我处理的事，通知工作重叠的双方，并把我的答复原样转达。

每 5 分钟：先查重叠，再查待处理

编排 agent 每一轮都按固定顺序执行：重叠检查、待处理检查、报告。

这两项检查是整套做法的核心。agent 多了以后，常见的问题往往不是某个 agent 做错了，而是两个 agent 各自都对、合在一起却冲突；或者某个 agent 已经阻塞在等我，而我并不知道。

重叠检查：同一区域，只有一个方向

主 agent 之间看不到彼此的上下文。

重叠指两个 agent 都在修改或决策的同一区域：一个模块、一份文档或设计决策记录（ADR）、一个接口约定、一个 PR、一次部署。编排 agent 按语义而不只是按路径匹配，比如 services/foo 和 docs/spec/foo 属于同一区域。

发现重叠后，编排 agent 同时通知双方。任何一方再次修改这个区域之前，双方都必须了解对方的计划并达成一致。

以下情况不算重叠：

• 主 agent 和它自己的子 agent，它们共享同一份任务说明；
• 只读或只做评审的 agent；
• 一方的改动已经合并。

24 小时内已经通知过、之后又没有新改动的组合，不再重复通知。

示例：两个前端 PR 改了同样的文件

项目 B 和项目 E 在同一个前端仓库里开发各自的应用。

• 前一天，编排 agent 首次通知双方仓库里的共享部分（组件库、模拟后端、接口约定），双方约定了各自可以修改哪些共享文件。
• 10:11，项目 E 的一个 PR 修改了开发指南和 lock 文件，排在下一个合并；项目 B 新开的骨架 PR 也改了这两个文件。编排 agent 的判断是：方向一致（是不同的应用），但后合并的一方会冲突。它通知了双方，并记录下这一组合。
• 10:12，两个 agent 直接沟通，约定 E 先合并、B 随后 rebase，并各自写入状态文件。
• 10:16，E 的 PR 合并，部署到开发环境。
• 10:36，B 完成 rebase：开发指南保留了双方的改动，lock 文件没有变化，类型检查、lint、测试和构建全部通过。

整个过程没有找我。我的报告里只多了一行：“已通知……方向一致”。

发给项目 B 的通知大致如下，项目 E 收到的是立场对调的版本：

重叠检查（来自编排 agent）：你和项目 E 都在修改前端仓库的共享文件：开发指南和 lock 文件。
- 你：骨架 PR 修改了这两个文件。
- 对方：一个 PR 也修改了这两个文件，即将合并。
- 判断：方向一致（不同的应用），但后合并的 PR 会冲突。
再次修改之前，先用一条消息说明你的计划，读对方的回复，约定由谁 rebase，并把约定写入状态文件。
如果无法达成一致，或者这个选择应该由人来做，就停止修改这些文件，并在回复里说明。

最后一句是关键：谈不拢的冲突，或者本该由我做的决定，不会被两个 agent 私下处理。相关工作会暂停，作为“需要你处理的冲突”进入我的报告。

待处理检查：什么算“需要我”

重叠检查之后，编排 agent 逐一判断每个 agent 是否在等我。关键在于把“需要我”定义清楚：定义太宽，报告充满噪音，我很快就会忽略它；定义太窄，真正阻塞的 agent 会被漏掉。

需要我：

• 阻塞在审批或提问对话框上。报告会引用对话框原文。
• 最后一条回复要求我决策、选择或执行某个操作，且尚未得到答复。被权限检查拒绝的操作也算。
• 报告了自己无法修复的失败。
• 主机异常：磁盘剩余不足 30 GiB，或 Docker 无响应。所有 agent 的构建和端到端测试都依赖它们。
• 负责交接的监视进程超过 10 分钟没有轮询。

不需要我：

• 在等同事审批或等 CI，归入“等待中”。
• agent 输入框里的文字。那是我还没发送的输入或建议，不是提问。
• 已经通过转达的答复解决了的问题。

不需要我的 agent，各自只出现在一行里：工作中、等待中或空闲。空闲的 agent 会注明最近的工作领域，方便我决定是分配新任务还是关闭它。

报告

报告的结构是固定的：先是重叠，然后是需要我的事，最后工作中、等待中、空闲各一行。下面是某天上午的一份，名称已经替换：

重叠：没有需要你处理的冲突。已通知：前端仓库的开发指南和 lock 文件（项目 B ↔ 项目 E，方向一致）。

需要你：
1. 项目 B（新应用骨架）：为前端仓库开通一个内部 npm 包的读取权限。
2. 项目 A（性能）：将一个服务降到 1 vCPU 的基础设施变更，保留还是关闭？

工作中：项目 B 的实现 agent（应用骨架）；项目 C 的小组 c（16 个端到端场景）
等待中：项目 C 的小组 a（审批 1/2）；项目 D（审批 1/2）
空闲：  杂务（Docker 和磁盘清理）；一次测试覆盖审查
主机：  剩余 313 GiB，Docker 正常

几秒钟就能读完，然后我回到自己的工作。

当天上午的三次提醒

• 09:45 Docker 停止运行，项目 C 的小组 c 无法执行 16 个端到端场景，主 agent 弹出对话框询问。我选择“启动 Docker”，编排 agent 启动后回复了对话框。场景执行完毕，小组 c 提交了 PR。
• 09:53 项目 B 需要一个只能由我在 GitHub 网页上完成的操作：为前端仓库开通一个内部包的读取权限。完成后，编排 agent 转达“已完成”，项目 B 随即开始第一个前端 PR。
• 09:53 项目 A 测完早上启动时的突发负载，询问一个将服务降到 1 vCPU 的基础设施变更是保留还是关闭。我回复“保留并开始”，几分钟后它提交了 PR，Terraform plan 里只有预期的变更。

如果没有编排 agent，Docker 停止运行这件事，要等我想起去看项目 C 时才会发现。

注意力只留给决策

这套做法的重点不在 agent 的数量，而在注意力的分配：

• 方向和取舍只有我能定，所以我和主 agent 深度对话；
• “谁在等我”“谁和谁冲突”可以明确定义、定期检查，所以交给编排 agent；
• 两层结构保证每个 agent 的产出都有掌握上下文的主 agent 验收。

agent 可以并行运行很多个，做决策的人只有一个。把这个人的注意力留给决策，其余的交给流程。