Lightweight Dispatch

触发

• 显式触发（用户主动要求）：用户说"并行查/同时搜/分别做/一起生成/批量处理/每人一个/各做各的/轻量级派发/简单并行/快速派发"；一次请求中描述了多项同类工作（如"帮我查 A、B、C 三人的信息，每人写一段简介"）。
• 隐式触发（agent 主动判断，满足全部条件）：任务可自然分割为 N 个同类子任务（N≥2）；子任务之间无依赖——每个可独立完成，不需要等待其他子任务的结果；每个子任务足够简单——单一目标，无需多步骤拆解，不需要接口合约；子任务之间修改的文件/资源不重叠（不会互相覆盖）。
• 不触发：单一原子操作 → 直接做；子任务之间存在强依赖（B 需要 A 的运行时输出）→ 升级「myworkflow:task-dispatch」；任务复杂，需要结构化拆解和接口合约 → 升级「myworkflow:task-dispatch」；子任务会修改相同的文件 → 不能并行，需串行或合并。
• 升级规则（第一步判断时发现任一信号 → 立即停止，升级到「myworkflow:task-dispatch」）：子任务之间存在"A 产出 → B 引用"的依赖关系；子任务需要修改同一批文件的不同部分（存在潜在的合并冲突）；任务的产出物需要精确定义的接口（下游模块依赖精确签名）；用户明确说"需要验收标准/需要接口合约"。
• 中间地带处理：2-3 个相互独立但每个有 2-3 步的中等复杂度任务（既不满足"一步到位"也不满足"需要合约"）→ 默认使用本 skill，但适当丰富子智能体的 prompt（增加步骤指引）。只有在子任务产生跨任务依赖时才升级到重量级。

与「myworkflow:task-dispatch」的边界

判断维度	轻量级派发（本 skill）	任务拆解与派发（重量级）
子任务关系	完全独立，无依赖	可能有分层依赖
拆解深度	不做拆解，直接平铺	拓扑排序 + 分层
接口定义	无需合约	YAML 合约 + 签名
子智能体协议	简化指令（本文档内置）	完整「myworkflow:subagent-protocol」5 阶段
验证	无需集成验证	需要「myworkflow:integration-verify」
元文件	无（不创建 .task-manifest/）	完整元文件体系
典型任务	"搜索 5 个人的 GitHub 主页"	"实现用户认证系统"
子任务上限	建议 <= 12	硬限制 2-12

前置强制步骤

1. 理解任务：确认用户需求确实可分解为 N 个同类独立子任务。
2. 轻量/重量判断：按上表判断——如果发现依赖/复杂度信号，立即升级到「myworkflow:task-dispatch」。
3. 收集上下文：读取每个子任务需要的输入文件/信息，确保子智能体有足够的上下文。

执行流程

第一步：判断与分类

分析用户任务，回答三个问题：

1. 是否可平铺：能否将任务直接拆成 N 个"做同一类事、但输入不同"的子任务？
2. 是否无依赖：每个子任务是否可以完全独立完成，不需要其他子任务的产出？
3. 是否足够简单：每个子任务是否是"单一目标、一步到位"的类型？

三个问题全部 YES → 进入第二步。任一 NO → 升级到「myworkflow:task-dispatch」。

第二步：生成子任务列表

为每个子任务赋一个编号（1..N），写一句话描述：

子任务 1：{一句话描述}
子任务 2：{一句话描述}
...
子任务 N：{一句话描述}

约束：N 建议不超过 12（超过 12 个时提示用户确认，避免管理成本超过并行收益）；每个子任务描述必须具体、可执行（子智能体看完就知道做什么）；如果某个子任务需要额外上下文（如特定文件内容），在这一步收集好，写入该子任务的 prompt。

第三步：生成简化 Prompt 并并行派发

核心原则：一个子任务 → 一个 Agent 调用 → 一个精简 prompt。

## 任务
{一句话描述}

## 上下文
{子智能体需要的项目背景、技术栈、相关文件路径}
{如果需要，粘贴关键输入内容——让子智能体不需要自己去猜}

## 产出要求
- {具体的产出物，如文件路径、文本内容、搜索结果}
- {格式要求，如 Markdown 表格、JSON、代码文件}

## 约束
- 只做本任务范围内的事，不要扩展范围
- {如果有不能修改的文件或不能做的事情，在这里写明}
- 完成后直接输出结果，不需要额外的声明/自检/完成报告文件

## timeout
timeout: 默认 300 秒。搜索类任务可设为 120 秒，代码生成类可设为 600 秒。主智能体可按任务类型调整。

## 输出格式
完成后请以以下格式输出：
### 结果：成功 → {具体产出内容}；失败 → 填写"失败原因: [具体原因]"，不填产出内容

派发方式：将所有 N 个 Agent 调用放在同一条消息中发送，它们会并行执行。不要在消息间串行发送。

与重量级 prompt 的区别：不引用「myworkflow:subagent-protocol」；不要求写 interface-declaration.md / self-check.md / completion.md；不要求读取 task-contract.yaml（因为根本不存在）；prompt 内置了简化的输出格式约定（"结果：成功/失败"）。

第四步：收集结果

等待所有子智能体返回。对每个子智能体的返回：

• 成功：提取产出内容
• 失败：记录失败原因（子智能体可能报告错误、超时、或找不到所需信息）
• 未返回：超时未响应也标记为失败

不需要走集成验证——各子任务独立，结果之间不互相依赖。

第五步：合并输出

将 N 个子任务的结果合并为统一的输出：

## 轻量级派发结果
| # | 子任务 | 状态 | 结果摘要 |
|---|--------|:----:|---------|
| 1 | {描述} | ✅ | {一句话摘要} |
| N | {描述} | ❌ | {失败原因} |

### 详细结果
#### ✅ 子任务 1：{描述}
{完整产出内容}
#### ❌ 子任务 N：{描述}
**失败原因**：{原因}

### 统计
- 成功：{X}/{N} / 失败：{Y}/{N}

失败处理决策：

失败率	建议动作
>50%	建议审视是否应升级到「myworkflow:task-dispatch」
≤50% 且 ≥2 项	重试失败项
仅 1 项	人工补做或重试
全部超时	检查超时设置是否合理，考虑增加 timeout 或拆分任务

• 失败项信息不重要（如"搜索某人信息未找到"且该信息不是核心需求）→ 标注后继续。
• 失败项影响整体结论（如"3 项失败导致无法做后续判断"）→ 在统计后添加"建议"段落，说明是否需要重试或人工介入。

失败处理

单个子任务失败

• 不阻塞、不重试其他子任务。
• 在合并输出中标记为 ❌ 并附失败原因。
• 如果用户对失败项有后续要求（如"重试子任务 3"），单独处理。

全部子任务失败

• 汇报所有失败原因，分析是否因为：任务描述不清 → 重新描述后重试；子智能体缺少必要上下文 → 补充上下文后重试；任务本质上不适合轻量级派发 → 升级到「myworkflow:task-dispatch」或自己直接做。

部分超时

• 超过 5 分钟未返回的子智能体标记为"超时"。
• 不影响已返回的结果——先合并已返回的结果，超时的单独标记。

完成标志

• 任务已判断为适合轻量级派发（三个问题全部 YES）
• N 个子任务列表已生成，每个描述具体可执行
• 每个子任务的简化 prompt 已准备好（含上下文和约束）
• 所有 Agent 调用在同一条消息中并行派发
• 所有子智能体已返回（或超时已标记）
• 合并输出已生成，包含成功/失败统计和详细结果
• 如有失败项，已给出失败原因和建议