用途
Agent Dispatch 是一个调度技能，帮助协调智能体（Coordinator）决定一项任务应当投入多少“机器”：是直接自己做，还是分发给 2-3 个独立工作单元并行处理。其核心判断是：稀缺资源不是智能体写出的代码行数，而是用户的注意力，以及只有用户才能确认的事实。额外的 Worker 只加速编码环节（依据一次 n=1 的实测 Run 推断），而集成、评审轮次、部署与状态报告会随 Worker 数量增加。因此默认采用最轻层级，仅在证据出现时升级，并用一行说明理由。
主要能力
- 按上下文拆分，而非按角色拆分：只有当某部分对其他部分的依赖很少时才交给另一个智能体，例如独立的研究路径、已有固定契约背后的组件、对已完成工作的黑盒检查。按角色或问题类型拆分会让每次交接都变成传话游戏。
- 写计划者执行计划：Coordinator 保留计划并完成自己能容纳在上下文中的工作；Worker 获得自包含的片段，而不是规划的一份子。每次交接都会损失细节，因此必须换来并行时间、干净上下文、另一产品能力或另一额度池之一。
- 分层卡片：
- L0 Direct：只读、复制、样式、静态资源或单文件、无行为变化，协调者直接完成，约 10 分钟。
- L1 Single：单模块内约 5 个文件以内的行为变更，或契约尚未决定的共享部分，由协调者自己做；仅在上下文拥挤、需要另一产品能力或额度池将尽时派一个 Worker，约 30-45 分钟。
- L2 Fan-out：相互需要上下文很少的部分（文件集不相交、无共享类型/模式/API/配置），最多 max_parallel_workers 个 Worker，各自一个 worktree，0 表示串行。
- L3 Arch：有用户给定范围的结构性问题，走架构加固循环。
- Research：无定论的产品、设计或 UX 方向，2-3 个独立研究者基于同一简报并行调研，协调者合并结果。
- Writing：文章、提案、周报、复盘，由协调者撰写，事实、数字、路径、命令逐项核对。
- Run Board：用于 L2、L3 与 Research，以及已派发 Worker 的 L1，作为里程碑报告，仅在里程碑时写入。
- 评审者选择：优先另一产品，其次同产品的新会话，再次是未编写该代码的协调者；作者永不评审自己的 diff，评审者尽量使用与作者不同的额度池。
- 回退：工具缺失时层级不变，只改变角色承担者，并在调度行或最终报告里说明采用了哪个回退。
使用方式
在会话开始时运行 python3 scripts/probe_agents.py 探测可用智能体，并阅读 references/accounts.md 理解字段含义；max_parallel_workers 决定 L2 上限，池来自探测而非账户名。行动前输出一行：Dispatch: L<n> — <决定性理由>; workers <n>; reviewer <who>; target <time>。当任务不跨产品、不跨额度池、用户也不需要 Board 与编号 Ask 时，应改用宿主原生的子智能体或 Agent Teams 机制。
适用场景
需要第二产品、第二额度池、希望由不同模型评审写作者，或用户明确要求 Board 的编码、评审、起草与设计调研任务。
限制与边界
单个协调会话负责派发、集成、决策与报告；集成不等于交付，只有仓库自身的 ship 流程或用户明确请求才可推送主分支或部署。破坏性、生产、计费、认证与对外消息动作仍需用户确认。每个提问都是带推荐、证据与阻塞项的编号 Ask。技能文档声明额外 Worker 的加速结论仅来自一次 n=1 的实测，更多度量见 references/measure.md 与 references/context-budget.md。