并行调度多代理

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

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

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

何时使用

适用于：

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

不适用于：

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

模式

1. 划分独立域

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

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

每个代理应拿到：

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

3. 并行派发

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

4. 汇总与集成

代理返回后：

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

代理提示结构

好的提示应：

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

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

常见错误

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

何时不要用

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

代理完成后

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

收益

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