| name | agent-task-dispatch |
| description | 标准化任务拆解与子 Agent 分发流程。将大任务拆解为独立子任务，控制每个子 Agent 的上下文预算，精简结果传递。触发：拆任务, 分配给 agent, subagent 编排, 多 agent 协作, task dispatch. 需要OpenClaw subagent support. 不适用于：单步任务（直接执行）、子 Agent 间需要共享可变状态的任务、不可并行的工作流。 |
Agent 任务拆解与分发
核心原则
- 任务拆小 — 每个 subagent 只做一件事
- 输入结构化 — 使用 Goal + Context + Constraints + Done 四要素模板
- 上下文预算 — 子任务描述控制在 500 token 以内
- 结果精简 — 子 agent 返回摘要，不回传原始大段内容
- 知识共享 — 关键发现写入共享文件，不锁在会话里
任务模板（必用）
## 任务：[简短标识]
### Goal
[一句话说清楚要做什么，产出什么]
### Context
- [关键背景信息，不超过5行]
- [相关文件路径/文档链接]
### Constraints
1. [硬性约束：不能做什么、必须遵守什么]
2. [上下文预算：简单 <300, 中等 300-500, 复杂 500-800]
### Done 标准
1. [具体可检查的完成条件]
2. [输出格式要求]
模板要点
- Goal 必须一句话：能复述 goal 的 subagent 才算理解了任务
- Context 只给必要信息：文件路径、关键背景、参考资料，不要塞整个项目上下文
- Constraints 最多 5 条：超过说明任务太模糊，需要先拆分
- Done 必须可检查：避免"完成所有功能"这类模糊描述，用"文件 X 新增 Y 行"、"接口返回 Z"等可验证条件
拆解流程
Step 1: 分析任务
- 任务总目标是什么？
- 可以拆成几个独立子任务？（无依赖可并行）
- 哪些子任务有依赖关系？（需串行）
Step 2: 分配 Agent
| 任务类型 | 推荐 Skill | 说明 |
|---|
| 写代码/修bug | coding-agent | 给完整上下文（文件路径、错误信息） |
| 代码审查 | 直接 subagent | 给代码片段 + 审查维度 |
| 技术调研 | 直接 subagent | 给关键词 + 期望输出格式 |
| 文档撰写 | feishu-create-doc | 给大纲 + 数据源 |
| 数据分析 | 直接 subagent | 给数据 + 分析维度 |
Step 3: 编写任务描述
用上面的四要素模板填充，确保：
- 每个 subagent 只有一个 Goal
- Context 中包含必要的文件路径
- Constraints 中声明上下文预算
Step 4: 执行分发
使用 subagent 派发（push-based），收到结果后自动回调。
Step 5: 结果汇聚
- 等待子 agent 完成（push-based，不要轮询）
- 收到结果后：
- 提取关键发现
- 写入共享文件（MEMORY.md / 对应项目文档）
- 通知用户
⚠️ 实战经验（2026-05-01 首次验证）
- 必须用绝对路径 — subagent workspace 与主会话不同，相对路径会找不到项目
mode=session 需要飞书/Discord等 channel 支持 thread=true，不支持时会静默失败- timeout 必须显式设置 — 简单600s，中等1200s，复杂1800s，不要依赖默认值
- git 操作在主会话完成 — 分支创建/reset/fetch 交给 subagent 会因路径问题失败
- 任务描述精简再精简 — 只给必要文件路径和需求，不要塞整个项目上下文
反模式（不要这样做）
❌ 自由格式派任务，不使用四要素模板
❌ 把整个项目上下文塞给子 agent
❌ 让子 agent 返回 10KB+ 的原始内容
❌ 轮询等待结果（push-based，不要 busy-poll）
❌ 一个子 agent 做多件独立的事
❌ Done 标准含糊（"完成开发"、"确保质量"）
❌ 用相对路径引用项目目录（subagent workspace 不同）
❌ 不设 timeout 就派复杂任务
❌ 让 subagent 处理 git 分支操作（路径不可靠）
