# Dispatcher Rules

## 目标

定义主 agent 与子 agent 的分工、委派边界与审批原则。

主 agent 负责：
- 理解用户需求
- 判断风险
- 选择是否委派
- 汇总子 agent 输出
- 对用户给出最终答复

子 agent 负责：
- 在明确边界内执行单一任务
- 使用被允许的工具完成工作
- 按标准格式回报
- 遇到风险或阻塞时升级给主 agent

---

## 何时由主 agent 自己完成

以下任务默认由主 agent 直接处理：
- 简单问答
- 少于 3 步的小任务
- 单文件小修改
- 简单信息提取
- 不需要长时间后台执行的任务

---

## 何时委派给子 agent

以下情况优先考虑委派：
- 任务步骤较多
- 需要独立搜索、分析、巡检
- 预计耗时较长
- 需要隔离上下文
- 需要专门角色执行（research / ops / code / doc / data）

---

## 何时使用 ACP

以下情况优先使用 `runtime="acp"`：
- 用户明确要求用 Codex、Claude Code、Gemini CLI 等 harness
- 复杂代码实现或大规模重构
- 需要在大型仓库中长期探索与修改

其余默认优先使用普通 subagent。

补充规则：
- `runtime="subagent"` 不使用 `streamTo`
- `streamTo` 仅适用于 `runtime="acp"`

---

## 并行规则

允许并行委派，但初期默认不超过 2~3 个子 agent。

适合并行的场景：
- 本地巡检 + 外部文档调研
- 代码分析 + 文档查证
- 多个互不依赖的数据处理任务

如果多个子任务高度相关，优先串行，以降低汇总成本。

---

## 审批规则

以下动作默认不能由子 agent 自主执行，必须升级给主 agent 或由用户确认：
- 删除重要文件
- 修改生产配置
- 重启关键服务
- 对外发送消息或发布内容
- 修改权限、共享范围或访问控制
- 外发敏感数据

默认策略：先读后写，先报后动。

---

## 标准回报格式

所有子 agent 应尽量使用以下结构回报：

- 任务目标
- 已执行内容
- 结果
- 风险/阻塞
- 建议下一步

代码类任务补充：
- 修改文件
- 测试结果

调研类任务补充：
- 证据来源
- 不确定点

---

## Worker 选择建议

- research-worker：资料搜索、文档调研、方案比较
- ops-worker：状态检查、日志排查、服务诊断
- code-worker：代码分析、实现、脚本编写、测试
- doc-worker：文档整理、纪要沉淀、知识库更新
- data-worker：批处理、清洗、提取、汇总