<!-- zh-only -->

# 并行调度多代理

把任务交给 **上下文隔离** 的专业代理；通过 **精确编写** 其指令与上下文，使其专注完成子任务。**不要** 让它们继承你会话的完整历史——只给 **必需信息**；这样也 **保留你自己的上下文** 做协调。

当存在 **多个互不相关** 的失败（不同测试文件、不同子系统、不同 Bug）时，串行排查浪费时间；每项调查彼此独立，可 **并行**。

**核心原则：** 每个 **独立问题域** 派一个代理；让它们 **同时** 工作。

## 何时使用

**适用于：**

- 3 个以上测试文件失败且根因不同  
- 多个子系统 **独立** 损坏  
- 理解任一问题 **不需要** 其他问题的上下文  
- 调查之间 **无共享可变状态**  

**不适用于：**

- 失败彼此相关（修一个可能带动其他）  
- 需要理解 **整体** 系统状态  
- 代理会 **互相干扰**（争用同一资源/文件）  

## 模式

### 1. 划分独立域

按「什么坏了」分组，例如：文件 A 测工具审批、文件 B 测批处理完成、文件 C 测中止——彼此独立。

### 2. 为每个代理写聚焦任务

每个代理应拿到：

- **明确范围**：一个测试文件或一个子系统  
- **清晰目标**：例如让这些测试通过  
- **约束**：如不要改无关代码  
- **期望输出**：发现了什么、改了什么（摘要）  

### 3. 并行派发

在支持 Task / 多代理的环境中，对多个独立任务 **同时** 发起调用。

### 4. 汇总与集成

代理返回后：

- 阅读各摘要  
- 检查改动是否冲突  
- 跑 **完整** 测试套件  
- 合并所有变更  

## 代理提示结构

好的提示应：

1. **聚焦** — 单一问题域  
2. **自洽** — 理解问题所需的上下文都在提示里  
3. **输出明确** — 要求返回什么（摘要、文件列表等）  

（示例略：可列出具体失败用例名、错误信息、禁止「只加大超时」等约束。）

## 常见错误

- **太宽**：「修所有测试」→ 代理迷失  
- **无上下文**：只写「修竞态」→ 不知道位置  
- **无约束**：可能大面积重构  
- **输出模糊**：「修好它」→ 无法核对  

## 何时不要用

**相关失败**、**需要全局上下文**、**探索性调试（尚不知坏在哪）**、**共享状态会冲突** 时，不要硬并行。

## 代理完成后

1. 对照摘要理解变更  
2. 查是否改到同一文件  
3. 跑全量测试  
4. 抽查（代理也可能犯系统性错误）  

## 收益

并行化、单代理上下文更窄、互不干扰、总耗时接近「最慢那一条」而非之和。