# 智能体调度技能

## 执行步骤

### 步骤1：读取相关常识知识
使用 `read_knowledge` 读取以下常识知识，了解领域规范和标准：
- 使用 `read_knowledge knowledge_name='agent_collaboration_standards'`

### 步骤2：读取工作提示词
使用 `read_work` 读取以下工作提示词，按规范流程执行：
- 使用 `read_work work_name='dispatch_agent'`
- 使用 `read_work work_name='dispatch_task'`

### 步骤3：读做事提示词
使用 `read_work` 工具，参数 `work_name='dispatch_agent'`。

### 步骤2：分析任务需求
使用 `read_text` 读取任务文档，明确以下要素：
- **任务类型**：开发/检测/审查/创作/管理/咨询等
- **所需能力**：具体需要的技能和工具
- **任务数量**：单个任务还是多个独立子任务
- **紧急程度**：高/中/低
- **任务间依赖关系**：是否互不依赖可并行执行

### 步骤3：查询可用智能体
使用 `get_agent_list` 获取所有智能体，再用 `get_agent_detail` 了解每个智能体的技能和工具。

> **关键判断**：遇到"检测/检查/审查/评估/测试"类任务，优先找对应领域的专业智能体。例如：
> - 技能检测 → `skill_teacher`（拥有 `skill_prompt_checker`、`work_prompt_checker`、`knowledge_prompt_checker` 等专业检测工具）
> - 代码审查 → 对应的开发智能体
> - 质量验收 → `quality_acceptance` 相关智能体
> 
> 专业智能体拥有专用检测工具，比通用智能体手动检查更高效准确。

### 步骤4：`call_agents` 使用决策指南

在决定使用 `call_agents`（并行呼叫多个智能体）还是 `call_agent`（串行呼叫单个智能体）之前，先按以下指南做决策。

---

#### ① 什么时候该用 `call_agents`
以下场景优先使用 `call_agents` 并行执行：

| 场景 | 示例 |
|:-----|:-----|
| **多个独立检测/检查任务** | 同时检测技能+work+knowledge（可并行呼叫 skill_teacher） |
| **多个独立报告生成任务** | 同时让不同智能体出各自的统计报告 |
| **多个互不依赖的开发任务** | 同时让前端开发页面A、后端开发接口B |
| **批量查询/统计任务** | 同时查询多个智能体的状态信息 |

#### ② 什么时候不该用 `call_agents`（该用 `call_agent`）

| 场景 | 原因 | 示例 |
|:-----|:-----|:-----|
| **有依赖链的任务** | 前序任务产出是后续任务的输入 | 先PRD→再规划→再开发（必须串行） |
| **需要沟通协调的任务** | 需要来回沟通确认，并行会混乱 | 前后端联调对接 |
| **修复+验证** | 先修复完才能验证，不能并行 | 修复bug → 验证修复结果 |
| **单一任务** | 就一个任务，没必要并行 | 单个查询或单个操作 |

#### ③ 量化建议

| 任务数量 | 推荐方式 | 说明 |
|:-------:|:--------:|:-----|
| **1个任务** | `call_agent` | 单一任务，串行执行即可 |
| **2个及以上独立任务** | 优先 `call_agents` | 并行提升效率 |
| **同一智能体被多次呼叫** | 评估负载后决定 | 同一智能体并行处理多个大任务可能吃不消，需评估其负载情况 |

> **注意**：`call_agents` 适合任务多但每个任务工作量不大的场景。如果单个任务工作量极大，即使有多个任务也要考虑智能体负载，必要时分批次并行或改用串行。

#### ④ 决策流程

```
收到多个任务
    ↓
任务间有依赖关系？ ──是──→ call_agent 串行执行
    ↓ 否
任务类型适合并行？ ──否──→ call_agent 串行执行
    ↓ 是
目标智能体负载OK？ ──否──→ 分批次并行或改用串行
    ↓ 是
──→ call_agents 并行执行
```

---

### 步骤5：负载分析
评估每个候选智能体的当前负载情况，负载超过80%的智能体暂不参与分配。如果使用 `call_agents`，需评估每个目标智能体的负载是否都能承受并行任务。

### 步骤6：匹配评分
按以下维度综合评分，选择最优智能体：

| 维度 | 权重 | 说明 |
|:----|:----:|:-----|
| 技能匹配度 | 50% | 智能体技能与任务需求的匹配比例 |
| 工具匹配度 | 20% | 智能体工具与任务所需工具的匹配比例 |
| 负载状态 | 30% | 空闲100分，适中递减，过载不参与 |

### 步骤7：分配任务
根据步骤4的决策结果执行：
- **并行任务**：使用 `call_agents` 工具，一次性呼叫多个智能体并行执行
- **串行任务**：使用 `call_agent` 工具，逐个分配任务

### 步骤8：记录与追踪
使用 `write_text` 记录分配信息，包括任务ID、分配对象、时间、并行/串行策略等。

### 步骤9：验收结果
委托修复任务时，要求对方修复完成后使用检测工具**重新验证**，并反馈验证结果，确保修复有效。

## 输出成果
1. 任务分配记录（含并行/串行策略说明）
2. 任务执行结果汇总

## 失败回退
- **查询失败**：尝试使用 `get_agent_list` 重新获取智能体列表
- **分配失败**：检查智能体是否存在，重新选择候选智能体
- **并行执行部分失败**：记录失败任务，重新分配给其他可用智能体
- **验证不通过**：将验证报告反馈给执行智能体，要求其重新修复

## 禁止行为
- ❌ 禁止不先读做事提示词就调度
- ❌ 禁止将任务分配给不具备相关能力的智能体
- ❌ 禁止将独立任务串行执行（应使用 `call_agents` 并行）
- ❌ 禁止在任务有依赖关系时使用 `call_agents` 并行执行
- ❌ 禁止检测/检查类任务不找专业智能体（他们有专业工具）
- ❌ 禁止修复后不验证就交付