运行多个代理

一个代理执行一份计划是默认方式，它覆盖了大部分工作。但有些工作超出了一个会话的范围：跨越多个仓库的变更、必须按顺序落地的发布，或者需要一个代理花上好几天的待办积压。DWP 无需改变其契约就能扩展到这类工作。计划仍是事实来源，每项任务仍以自己的验证关卡收尾，而额外的代理是由一个主导者（lead）协调的通道（lane）。

本章描述这一模型。它用到三个可选附加组件——用于窗格与对等方的 Herdr、用于账户的 agentkit，以及用于容器的 devcontainer——单代理计划不需要其中任何一个。

主导者与其通道

主导者拥有父计划。它决定通道、为每条通道分配范围、收集里程碑，并下达允许某条通道合并或发布的指令。它不编写其他通道的代码。

一条通道是一个代理配一个范围——通常是一个仓库。它读取该仓库的 AGENTS.md，运行该仓库的验证关卡，并在仓库内保存自己的计划。在编排枢纽中，父计划位于枢纽的 .dwp/plans/，附带一张子计划追踪表；每条通道的计划则位于各自的仓库中，使用该仓库的计划 ID 与验证关卡。

通道运行在哪里

通道是终端窗格中的一个代理，而窗格可以位于多个地方。Herdr 把每个代理放进一个窗格，并通过 SSH 连接其他机器，因此主导者能在同一个侧边栏中看到所有通道。

• 在主机上。每条通道一个窗格，与主导者并排。设置最快，适用于开发者本就在其中工作的仓库。
• 在容器中。devcontainer-kit 容器在 dck up 时加入 Herdr 网格：其中的代理可以连到主机和其他容器，主机也能连到它们。容器本身就是沙箱，因此其中的代理可以自主运行。
• 在另一台机器上。Herdr 通过 SSH 能连到的任何机器都能以同样方式承载通道，前提是那里也安装了 herdr-peers。

位置改变的是隔离方式，而不是协议：容器中的通道与主机上的通道以相同方式与主导者协调。

按余量选择账户与厂商

多个代理消耗配额很快。每条通道运行在自己的账户上——即 coding-agents-kit 中的一个 CLI 加一个配置档——这样各通道不会耗尽同一个窗口，某个账户触及限额时只会停下一条通道，而不是全部。

• ak usage 显示每个账户和配置档剩余的配额，每个批次查看一次。
• ak pick <kind> --count N 返回余量最多的 N 个账户，按优劣排序；--exclude 排除一个忙碌的账户，--model 计算单个模型的窗口，--need 在余量不足时拒绝启动。
• ak <kind> @<profile> 在通道的窗格中，以该账户启动通道的代理。

厂商也可以同样混用。Claude 通道负责编写时，Codex 通道可以负责审查，各自使用 ak pick 为其类型选出的账户。容器中的通道可以使用主机的账户：在开发者的 devcontainer-kit 主机配置中开启 host_profiles 后，容器会获得仓库所安装 CLI 的主机配置档——Claude 通过每个配置档一个长期令牌，Codex 通过其认证文件——无需自行登录。只使用你自己的账户，并遵守每个厂商的条款：把工作分摊到各账户上，绝不轮换账户来绕过限额。

无人值守地启动并解除通道阻塞

主导者可以在无人操作键盘的情况下启动通道并让它们持续推进。一旦开发者授予了无人值守运行权限——一条长期指令或计划的预先授权——每次启动都无需再获批准。主导者使用 Herdr 自身的命令；工具包代码不发送任何按键。该流程有固定顺序：先一次性准备，再避免提示，然后检测停顿，只在一种情况下发送按键，其余一律上报。

1. 一次性准备，由开发者完成。Claude Code 会针对每个配置档询问一次，要求确认其绕过权限（bypass-permissions）模式。这一确认是开发者本人的步骤，在创建配置档时完成；在 devcontainer-kit 容器中，工具包只会把它写入容器自己的 home 目录。任何代理都绝不为它发送按键。
2. 避免。ak pick <kind> 选出余量最多的账户，herdr pane run <pane> 'ak <kind> @<profile> --trust-cwd' 在通道自己的文件夹中启动它。--trust-cwd（或 AGENTKIT_TRUST_CWD=1）预先信任该文件夹，因此 Claude 与 Codex 无需任何按键即可跳过文件夹信任界面。
3. 检测。herdr-peers lanes（或 herdr agent list）显示每条通道处于工作中、空闲、阻塞或完成状态。对于阻塞、或空闲且无输出的通道，herdr-peers status <pane> 对它所停留的界面进行分类——文件夹信任、绕过权限确认、登录、权限请求或未知——并给出文档记载的下一步，herdr pane read <pane> 则显示该界面。
4. 一种按键，一种情况。主导者唯一可以发送的按键，是对文件夹信任界面的应答，且仅限于它自己启动的窗格、在 --trust-cwd 不可用的情况下。它在发送按键前先读取界面，发送应答所需的最少按键，然后再次读取。
5. 其余一律读取、记录并上报。Claude 的绕过权限确认、登录与凭据提示、逐项操作的权限请求、破坏性确认、付款或套餐提示、未知界面，以及不是主导者创建的窗格，都作为阻塞里程碑交给开发者，绝不以按键应对。
6. 退出选项优先。设置 AGENTKIT_PERMISSIONS=ask 时，通道在行动前先询问，主导者绝不绕过该退出选项带来的任何提示。
7. 重新启动。如果代理退出，主导者在同一账户上重新启动它，或另选一个账户。登录失效属于凭据提示：需要上报。

每一次干预——界面显示了什么、发送了哪些按键、随后发生了什么——都记录在父计划中。

通过 herdr-peers 协调

通道与主导者通过 herdr-peers 通信：一次询问（ask）携带一个戳记，恰好授权一次回复（reply），每次交互都会被记录。主导者让协议保持精简：

• 里程碑向上汇报。每条通道在固定节点汇报——计划就绪、拉取请求已开启、受阻、完成——两次汇报之间继续工作，不等待回答。
• 问题以询问提出。需要决策的通道向主导者发起询问；主导者以一次回复作答。
• 深度为一。回复永远不会再被回复，通道也不会继续向下委派。每个调用方的扇出有上限，默认四个对等方。
• 是数据，而非指令。回复不会授予接收方原本没有的任何权限。通道声称其验证关卡已通过，要通过实际运行该关卡来核实。
• 记录谁做了什么。每条委派记录都写明通道的账户和厂商，因此父计划能显示哪个账户承担了哪项工作。
• Codex 通道要指明自己的窗格。 Codex 通过同一账户所有会话共享的后台服务器运行通道的命令，因此它继承的窗格 id 可能属于另一个通道。Codex 通道在每个 herdr-peers 命令（ask, reply, notify, check, wait, lanes, cancel）上用 --pane <pane> 传入主导者任务说明中给出的自身窗格。

主导者可以一次看到整个编排：herdr-peers lanes 列出每条通道及其状态，DeepWorkPlan Vim 则在编排计划旁边显示其各条通道（:DwpLanes）。

每个仓库一个分支、一次发布

让多条通道保持可审查的规则很简单：每个仓库一条通道，在其基础检出上工作，整个变更只有一个分支、一个拉取请求和一次发布。通道不会把工作拆分到多个分支或 worktree 中。worktree 只用于两个写入者必须共享同一个仓库的情形：每人各用一个，使每条路径只有一个写入者。

拉取请求保持开启、检查通过并带有审查标签，直到主导者下达 GO。随后通道合并并打标签，再把标签汇报回来。

发布顺序

仓库之间相互依赖，因此按依赖顺序发布：先是工具，然后是固定这些工具版本的仓库，再是描述结果的文档，最后是采用它的使用方。主导者掌握顺序，并一次向一个仓库下达 GO。固定另一个仓库发布版本的通道，要等到该标签存在后才写入固定版本，因此任何固定版本都不会指向一个不存在的发布。

检查点

父计划依据证据收尾，而不是依据汇报：

1. 按通道。每条通道的验证关卡在其自身分支上通过，其拉取请求的审查没有问题。审查本身也可以是一条独立的通道：AI Diff Reviewer 审查每条通道的拉取请求，借助 Dailybot 附加组件，每条通道还会向团队汇报自己的进展。
2. 按发布。每个标签都存在，并固定了下一个仓库所需的版本。
3. 集成。最后一次发布之后，一个检查点在已发布版本上运行使用方，并把结论记录到父计划的 analysis_results/ 中。
4. 最终审查。在父计划完成之前，一轮安全检查覆盖所有跨越边界的内容——尤其是共享进容器的账户、令牌和文件。

安全

• 绝不在询问、提示或日志中放入密钥、令牌或机密；按名称引用变量。
• 共享资源要加锁：通道在执行容器构建等重型步骤之前获取锁，完成后释放。
• 权限退出选项一旦设置，对每条通道及通道启动的每个代理都优先生效。
• 无法继续的通道以阻塞里程碑说明情况并停止；由主导者决定下一步。

当账户或主导者耗尽时

一次长时间的运行会比任何单个账户都持久。自 coding-agents-kit (v0.7.1) 和 herdr-peers (v0.3.2) 起，通道在每个任务边界检查自己的容量，并在账户耗尽之前通过交接包把工作交出去；主导者会移交主导权，或由其副手接替；只有关键事项才会交给开发者。集群自主描述了这一循环、交接包、继任以及上报类别。