Menu
动态多Agent编排引擎。根据用户任务自动分析所需角色、拆解子任务、编排执行顺序和修正循环，生成主任务提示词并按参数执行（可等待用户确认）。当用户描述一个需要多步骤多角色协作的复杂任务时触发，如"开发一个XX系统"、"分析XX数据并生成报告"、"重构XX项目"等复杂工程任务。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | bole |
| description | 动态多Agent编排引擎。根据用户任务自动分析所需角色、拆解子任务、编排执行顺序和修正循环，生成主任务提示词并按参数执行（可等待用户确认）。当用户描述一个需要多步骤多角色协作的复杂任务时触发，如"开发一个XX系统"、"分析XX数据并生成报告"、"重构XX项目"等复杂工程任务。 |
| version | 1 |
| metadata | {"tags":["orchestration","multi-agent","dynamic","task-decomposition"],"category":"orchestration"} |
人与人沟通时，身份本身就是上下文 — "后端工程师"四个字就隐含了 RESTful、数据库、并发等专业知识。但 LLM 子Agent 没有"社会身份直觉"，只靠显式文本推理。因此，给子Agent 的角色描述必须包含充分的专业背景，否则它会在基础概念上反复确认或做出外行决策。
规则：每个子Agent 的启动提示词中，必须包含对应角色的专业背景卡（professional context card）。
用户给出任务 → 角色分析 → 任务拆解 → 生成编排提示词 → 执行或等待确认（由 auto_execute 控制）
根据任务内容，分析需要哪些角色。不要预设固定角色，而是根据任务特征动态决定。
| 维度 | 问题 | 对应角色倾向 |
|---|---|---|
| 任务类型 | 开发/分析/重构/测试/文档？ | 决定核心角色 |
| 技术栈 | 前端/后端/数据/DevOps？ | 决定专业角色 |
| 质量要求 | 需要测试/安全审查/性能优化？ | 决定验证角色 |
| 复杂度 | 模块数量、依赖关系 | 决定角色粒度 |
| 交付物 | 代码/报告/文档/配置？ | 决定产出角色 |
设计类：architect（架构师）、planner（规划师）、designer（设计师） 开发类：frontend-dev、backend-dev、fullstack-dev、data-engineer、devops 验证类：tester-functional、tester-performance、tester-security、reviewer 分析类：analyst（数据分析师）、researcher（研究员） 文档类：doc-writer、api-doc-generator
规则：
确定角色后，必须为每个角色生成一份专业背景卡，作为子Agent启动提示词的前置上下文。背景卡的作用是让 LLM 立刻”进入角色”，减少不必要的概念确认和方向偏移。
格式：
## 你的角色背景
你是一名{角色名称}，你具备以下专业背景：
- 核心技能：{3-5项关键技术能力}
- 工作原则：{2-3条该角色的职业行为准则}
- 产出标准：{该角色交付物的质量要求}
- 常见陷阱：{该角色容易犯的典型错误，提醒避免}
当前项目上下文：
- 技术栈：{根据任务推断}
- 项目目标：{任务概要}
- 你的职责范围：{本次任务中该角色负责的具体范围}
示例 — backend-dev 的背景卡：
## 你的角色背景
你是一名后端开发工程师（backend-dev），你具备以下专业背景：
- 核心技能：RESTful API 设计、关系型/NoSQL 数据库建模、并发处理、认证授权、错误处理
- 工作原则：接口先于实现设计；数据一致性优先于性能；安全是默认项不是可选项
- 产出标准：可运行的代码 + 接口文档 + 错误码定义；代码需通过 lint 检查
- 常见陷阱：忽略边界校验；硬编码配置；同步阻塞 IO；未处理异常扩散
当前项目上下文：
- 技术栈：FastAPI + PostgreSQL
- 项目目标：用户管理系统
- 你的职责范围：用户注册/登录 API、JWT 认证、用户信息 CRUD
在执行前检测任务依赖图的循环；若发现环，则标记为 invalid-dependencies 并自动提出拆分建议或请求用户确认如何解环（默认不盲目修改任务结构）。
对每个子任务生成以下信息：
子任务ID: T-{序号}
名称: {简短描述}
角色: {对应角色}
依赖: [T-{依赖的任务ID列表}]
输入: {需要的文件/数据/上下文}
输出: {产出物路径和格式}
验收标准: {PASS/FAIL 判定条件}
执行步骤:
1. {具体步骤}
2. {具体步骤}
...
将子任务按依赖关系分层，无依赖的并行执行：
Layer 0（可并行）: [T-1, T-2] ← 无依赖
Layer 1（可并行）: [T-3, T-4] ← 依赖 Layer 0
Layer 2: [T-5] ← 依赖 Layer 1
...
以 TASK.md 为模板框架，填入动态分析结果，生成完整的主任务提示词。
## 核心原则
（继承 TASK.md 核心原则，按需调整）
## 初始化
- 确认任务描述，记为 TASK_DESC
- 确认输出目录，记为 OUTPUT_DIR
- 确认批量大小，记为 BATCH_SIZE：每次并行启动的子任务数量（针对同一 Layer）。默认 1；若为 3，则同一 Layer 同时运行 3 个子任务。
- 创建日志文件 {OUTPUT_DIR}/main-log.md：在创建或写入失败时重试 2 次（间隔 5s）；若仍失败，则根据参数 `output_error_policy` 采取 'abort' 或 'use-temp'（切换到临时目录并通知用户）。
- 探测并缓存 Agent ID 路径：在 `{OUTPUT_DIR}/agents/` 下创建 JSON 索引文件 `agents-index.json`，条目格式 {"agent_id": "<id>", "role": "<role>", "path": "agents/<id>.json"}。写入失败时重试 3 次并记录错误。
## 角色定义
（Step 1 的角色分析结果，每个角色必须附带专业背景卡）
{角色1}: {subagent_type}
职责: {职责描述}
背景卡: {Professional Context Card，见 Step 1 格式}
{角色2}: {subagent_type}
职责: {职责描述}
背景卡: {...}
...
## 任务计划
（Step 2 的子任务列表和分层）
## Phase 1: {首个Phase名称}
启动 {角色} 子Agent...
先注入该角色的专业背景卡（Professional Context Card），再给出具体任务指令。
注入方式：将背景卡作为子Agent prompt 的开头部分，确保它在任何任务指令之前。
{具体指令}
## Phase 2: {主执行Phase}
### 批量开发/执行循环
对每一层任务：
Step 1: 批量执行（启动对应角色Agent）
Step 2: 批量验证（启动验证角色Agent）
Step 3: 修正循环（最多3轮）：对单个子任务的修正限制为最多 3 次重试；每个 Layer 的子任务各自独立计数。全局重试上限另设参数 `max_fix_rounds`。
- 收集 FAIL 报告
- resume 执行 Agent 修正
- resume 验证 Agent 重测
简要执行伪代码（按 Layer 进行）：
```pseudo
for each layer in layers:
for each task in layer:
attempts = 0
while attempts <= max_fix_rounds and not task.passed:
start task with up to BATCH_SIZE parallelism
validate task
if failed:
attempts += 1
apply fixes
else:
mark task passed
send layer completion summary
Step 4: 状态更新 + 反馈
统计、日志、报告
（继承 TASK.md 日志规范）
（继承 TASK.md 关键规则）
---
## Step 4：执行策略与确认
生成提示词后，按参数 `auto_execute` 决定是否自动启动：如果 `auto_execute=true` 则生成提示词后立即执行；如果 `auto_execute=false`（默认），则生成并向用户展示 TASK.md，等待用户发送确认命令 `CONFIRM_EXECUTE` 再行执行。始终在每个 Layer 完成时发送进度摘要。
### 执行时的优先级步骤
1. 验证阶段（Validation）：检查 `Agent ID` 可用性、`OUTPUT_DIR` 可写性、`requirements_file` 可读性等；验证失败按策略处理（参见参数 `error_policy` / `output_error_policy`）。
2. 执行阶段（Execution）：按 Layer 原子执行（每个 Layer 内子任务并行，Layer 之间顺序执行）。每个子任务有独立的修正重试计数（最多 `max_fix_rounds` 次）。
3. 出错与容错策略（On-agent-failure policy）：优先级顺序：重试 N 次 → 启动备用 Agent → 暂停该 Layer 并通知用户 → 根据 `fault_tolerance_policy` 决定跳过或回滚。若子Agent 在 `heartbeat_timeout` 秒内无响应，则标记为 `failed`；自动重试 `retry_count` 次；若仍失败，尝试备用 Agent 或上报并跳过，取决于 `fault_tolerance_policy`。
### 记忆与日志
- 每个子Agent的详细执行步骤写入记忆（memory 系统），用于审计与可重放。
- 主日志写入 `{OUTPUT_DIR}/main-log.md`（见日志写入错误处理策略）。
- 进度实时反馈给用户：在每个 Layer 完成时发送摘要（包含已完成任务列表、失败数、当前整体状态）到用户指定的通信渠道（参数：`status_channel`，可选：`console`, `email`, `webhook`），默认 `console`；默认每 5 分钟汇报一次，或在每个 Layer 完成时即时汇报。
---
## 动态调整机制
执行过程中根据实际情况动态调整：
| 情况 | 调整策略 |
|------|----------|
| 子任务实际比预期复杂 | 拆分为更细粒度的子任务 |
| 某角色瓶颈 | 增加该角色 Agent 数量（通过启动额外 Agent 并行处理相同角色任务），并遵循冗余与故障转移策略（见 On-agent-failure policy）。 |
| 验证发现新问题类型 | 增加对应验证角色 |
| 子Agent返回格式异常 | 暂停并报错，不继续循环 |
| 子Agent循环重复输出 | 立即终止，报错 |
| Agent ID 获取失败 | 重试 3 次（指数退避），若仍失败，切换到备用 ID 池或将任务退回到 `waiting_for_admin` 并通知用户，说明故障原因。 |
---
## 使用方式
用户直接描述任务即可触发，例如：
- "开发一个用户管理系统，需求文档在 /path/to/req.md"
- "分析这批交易数据，生成策略报告"
- "重构 XX 项目，提高测试覆盖率到80%"
- "用 Vue3+FastAPI 开发一个博客系统"
### 参数
- `task`: 任务描述（必填）
- `requirements_file`: 需求文档路径（可选）
- `output_dir`: 输出目录（默认：当前项目目录）
- `batch_size`: 批量大小（默认：1）
- `max_fix_rounds`: 修正循环最大轮数（默认：3）
新增/补充参数：
- `auto_execute`: 是否自动执行（布尔，默认：false）。如果为 `true`，则生成提示词后立即执行；如果为 `false`，生成 TASK.md 并等待用户发送 `CONFIRM_EXECUTE` 再执行。
- `status_channel`: 进度反馈渠道（可选）：`console`、`email`、`webhook`。默认 `console`。
- `output_error_policy`: 输出目录写入错误处理策略（可选）：`abort` | `use-temp`。默认 `abort`。
- `heartbeat_timeout`: 子Agent 心跳超时时间（秒），默认 300。
- `retry_count`: 子Agent 操作重试次数，默认 2（在 heartbeat 超时或临时错误时使用）。
- `fault_tolerance_policy`: 故障容忍策略（可选）：`abort` | `skip` | `escalate`（默认 `escalate`）。
- `error_policy`: 当 `requirements_file` 指定但不可读取时的处理策略：`abort` | `ask` | `proceed-with-heuristics`（默认 `ask`）。
行为说明：如果 `requirements_file` 指定但不可读取，系统将依据 `error_policy` 抉择：立即中止并报错（`abort`）；或向用户询问上传/修改（`ask`）；或根据启发式继续执行并记录不确定性（`proceed-with-heuristics`）。