<技能概述> 当面临3个以上独立故障时，每个问题域派出一名代理同时进行调查；首先验证独立性，在单个消息中分派所有代理，等待所有代理，检查冲突，验证集成。 <刚性级别> 中等自由 - 严格遵循 6 步骤流程（识别、创建任务、调度、监控、审查、验证）。必须进行独立性验证。需要在单个消息中并行调度。使代理提示内容适应问题域。 <快速参考> 步骤|行动|关键规则 ---|---|--- 1\.识别域 |测试独立性（修复 A 不影响 B）|需要3个以上独立域 2\.创建代理任务 |编写重点提示（范围、目标、约束、输出）|每个域一个提示 3\.派遣代理|在一条消息中启动所有代理 |并行调用多个 Task() 4\.监控进度 |跟踪完成情况，在全部完成之前不要集成 |等待所有代理 5\.审核结果 |阅读摘要，检查冲突 |手动解决冲突 6\.验证集成 |运行完整的测试套件 |使用完成前验证 **为什么是 3+？** 如果只有 2 次失败，协调开销通常会超过顺序时间。 **关键：** 通过多个 Task() 调用在单个消息中调度所有代理，或者它们按顺序运行。在以下情况下使用： * 3 个以上的测试文件因不同的根本原因而失败 * 多个子系统独立损坏 * 每个问题无需其他人的上下文即可理解 * 调查之间没有共享状态 * 您已经验证故障是真正独立的 * 每个域都有明确的边界（不同的文件、模块、功能）不要在以下情况下使用： * 故障是相关的（修复一个可能会修复其他故障） * 需要首先了解完整的系统状态 * 代理会干扰（编辑相同的文件） * 尚未验证独立性（探索阶段） * 失败的根本原因相同（一个错误，多种症状） * 需要保留调查顺序（级联故障） * 只有 2 次失败（开销超过收益） <进程> ## 步骤 1：识别独立域 **宣布：**“我正在使用 hyperpowers:dispatching-parallel-agents 来同时调查这些独立的故障。” **创建 TodoWrite 跟踪器：** - 识别独立域（已识别 3 个以上域） - 创建代理任务（起草每个域一个提示） - 并行调度代理（所有代理在单个消息中启动） - 监控代理进度（跟踪完成情况） - 审查结果（阅读摘要、检查冲突） - 验证集成（完整测试套件绿色） **独立性测试：** 1. **问：**“如果我修复故障A，是否会影响故障B？” * 如果否 → 独立 * 如果是 → 相关，一起调查 2. **检查：**“故障是否涉及相同的代码/文件？” * 如果否 → 可能独立 * 如果是 → 检查是否有不同的功能/区域 3. **验证：**“故障是否共享错误模式？” * 如果否 → 独立 * 如果是 → 可能是相同的根本原因 **独立性检查示例：** 失败 1：身份验证测试失败 (auth.test.ts) 失败 2：数据库查询测试失败 (db.test.ts) 失败 3：API 端点测试失败 (api.test.ts) 检查：修复身份验证是否会影响数据库查询？否检查：修复数据库是否会影响API？是 - API 使用数据库结果：2个独立域：域 1：身份验证 (auth.test.ts) 领域 2：数据库 + API（db.test.ts + api.test.ts 在一起） **按损坏的内容对失败进行分组：** * 文件A测试：工具审批流程 * 文件B测试：批量完成行为 * 文件 C 测试：中止功能 ** ** ## 步骤 2：创建有针对性的代理任务每个代理提示必须包含： 1. **具体范围：** 一个测试文件或子系统 2. **明确的目标：** 让这些测试通过 3. **约束：** 不要更改其他代码 4. **预期输出：** 您发现并修复的内容的摘要 **好的代理提示示例：** 修复 src/agents/agent-tool-abort.test.ts 中的 3 个失败测试： 1.“应该通过部分输出捕获中止工具”- 期望消息中出现“中断于” 2.“应该处理混合完成和中止的工具”-快速工具中止而不是完成 3.“应该正确跟踪pendingToolCount” - 期望 3 个结果，但得到 0 这些是时序/竞争条件问题。你的任务： 1.阅读测试文件并了解每个测试验证的内容 2. 确定根本原因 - 时间问题还是实际错误？ 3. 修复方法： - 用基于事件的等待替换任意超时 - 修复中止实施中发现的错误 - 如果测试改变了行为，则调整测试期望永远不要只是增加超时 - 找到真正的问题。返回：您发现的内容和修复的内容的摘要。 **这有什么好处：** * 列出了具体的测试失败 * 提供上下文（计时/竞争条件） * 清晰的方法论（阅读、识别、修复） * 约束（不仅仅是增加超时） * 输出格式（摘要） **常见错误：** ❌ **太宽泛：**“修复所有测试”- 代理丢失 ✅ **具体：**“修复 agent-tool-abort.test.ts”- 重点范围 ❌ **没有上下文：** “修复竞争条件” - 代理不知道在哪里 ✅ **上下文：** 粘贴错误消息和测试名称 ❌ **无约束：** 代理可能会重构所有内容 ✅ **约束：** “不要更改生产代码”或“仅修复测试” ❌ **模糊的输出：**“修复它” - 你不知道发生了什么变化 ✅ **具体：**“返回根本原因和更改的摘要” ** ** ## 步骤 3：并行调度所有代理 **关键：** 您必须通过多个 Task() 调用在一条消息中分派所有代理。 // ✅ 正确 - 具有多个并行任务的单个消息任务（“修复agent-tool-abort.test.ts失败”，提示1）任务（“修复批处理完成行为.test.ts 失败”，提示2）任务（“修复工具批准竞争条件.test.ts 失败”，提示3） // 三者同时运行 // ❌ 错误 - 顺序消息任务（“修复agent-tool-abort.test.ts失败”，提示1） // 等待响应任务（“修复批处理完成行为.test.ts 失败”，提示2） // 这是顺序的，而不是并行的！ **发货后：** * 在 TodoWrite 中将“并行调度代理”标记为已完成 * 将“监控代理进度”标记为 in_progress * 等待所有代理完成后再集成 ** ** ## 步骤 4：监控进度作为代理工作： * 注意哪些代理已完成 * 注意哪些仍在运行 * 在所有代理完成之前不要开始集成 **如果代理陷入困境（>5 分钟）：** 1.检查AgentOutput看看它在做什么 2. 如果卡在错误的路径上：取消并重试，提示更清晰 3. 如果需要来自其他域的上下文：等待其他代理，然后使用上下文重新启动 4. 如果遇到真正的拦截器：自行调查拦截器，然后重试 ** ** ## 步骤 5：查看结果并检查冲突 **当所有特工返回时：** 1. **仔细阅读每个摘要** *根本原因是什么？ * 代理改变了什么？ * 是否存在任何不确定因素？ 2. **检查冲突** * 多个代理是否编辑了相同的文件？ * 代理人是否做出了相互矛盾的假设？ * 域之间是否存在集成点？ 3. **整合策略：** * 如果没有冲突：应用所有更改 * 如有冲突：申请前手动解决 * 如果假设冲突：与用户验证 4. **记录发生的事情** * 哪些代理修复了哪些内容 * 发现任何冲突 * 做出整合决策 ** ** ## 步骤 6：验证集成 **运行完整的测试套件：** * 不仅仅是固定测试 * 验证其他领域没有回归 * 使用超能力：完成前验证技能 **完成之前：** # 运行所有测试 npm test # 或货物测试、pytest 等。 # 验证输出 # 如果全部通过 → 标记“验证集成”完成 # 如果失败 → 确定哪个代理的更改导致了回归 # 派遣第一个代理任务（“修复agent-tool-abort.test.ts失败”，提示1） # 等待代理 1 的响应 # 然后派遣第二个代理任务（“修复批处理完成行为.test.ts 失败”，提示2） # 等待代理 2 的响应 # 然后派遣第三个代理任务（“修复工具批准竞争条件.test.ts 失败”，提示3） # 总时间：所有三个代理的总时间（顺序） <为什么失败> * 代理按顺序运行，而不是并行运行 * 并行化不会节省时间 * 每个代理等待前一个代理完成 * 违背了并行调度的全部目的 * 与序贯调查结果相同 * 浪费了创建单独代理的开销 // 具有多个 Task() 调用的单个消息任务（“修复agent-tool-abort.test.ts失败”，` 修复 src/agents/agent-tool-abort.test.ts 中的 3 个失败测试：【提示1内容】 `) 任务（“修复批处理完成行为.test.ts 失败”，` 修复 src/agents/batch-completion-behavior.test.ts 中的 2 个失败测试：【提示2内容】 `) 任务（“修复工具批准竞争条件.test.ts 失败”，` 修复 src/agents/tool-approval-race-conditions.test.ts 中 1 个失败的测试：【提示3内容】 `) // 所有三个同时运行 - 这是关键 **发生了什么：** * 所有三个代理同时启动 * 各自独立调查 * 全部并行完成 * 总时间：Max(agent1,agent2,agent3)而不是Sum **您将获得什么：** * 真正的并行化 - 同时解决 3 个问题 * 节省时间：1 次调查 3 次 * 每个代理都专注于狭窄的范围 * 无需等待顺序完成 * 正确使用并行调度模式 # 认为：“不同的子系统，一定是独立的” # 立即派遣 3 名特工，不检查独立性 # 代理 1 发现：API 因数据库架构更改而失败 # 代理2发现：数据库查询需要迁移 # 代理 3 发现：基于旧模式的缓存键 # 所有三个失败都是由相同的根本原因引起的：架构更改 # 代理根据不同的假设进行相互冲突的修复 # 集成失败，因为修复相互矛盾 <为什么失败> * 跳过独立性验证（步骤1） * 基于表面外观的假设独立性 * 所有失败实际上都有共同的根本原因（架构更改） * 特工孤立工作，看不到联系 * 每个代理对正确的模式做出了不同的假设 * 冲突的修复无法集成 * 在本应统一的并行工作上浪费了时间 * 必须放弃代理工作并重新开始检查：修复API是否会影响数据库查询？ - API使用数据库 - 如果数据库架构发生变化，API 就会中断 - 是的 - 这些是相关的检查：修复数据库是否影响缓存？ - 缓存存储数据库结果 - 如果数据库架构发生更改，缓存键就会损坏 - 是的 - 这些是相关的检查：失败是否共享错误模式？ - 所有提及“未找到列：user_email” - 一切都在架构迁移后开始 - 是 - 共同的根本原因结果：不独立这些是一个问题（架构更改），表现在 3 个地方 **正确做法：** 单一代理调查：“架构迁移破坏了 3 个子系统” 代理提示： “我们有 3 个测试失败，全部与架构更改相关： 1. API端点：未找到列 2.数据库查询：未找到列 3. 缓存失效：旧密钥调查导致此问题的架构迁移。通过一致更新所有 3 个子系统来修复。返回：模式发生了什么变化，你如何修复每个子系统。” # 一名特工看到全貌 # 在所有 3 个区域进行一致的修复 # 没有冲突，适当的整合 **您将获得什么：** * 在浪费时间之前找出共同的根本原因 * 一名代理可以看到完整的上下文 * 对所有受影响区域进行一致修复 * 没有冲突的假设 * 无集成冲突 * 比 3 个代理执行交叉任务的速度更快 * 并行调度前正确的问题诊断代理 1：“通过将等待时间增加到 5000 毫秒来修复超时问题” 代理 2：“通过添加互斥锁来修复竞争条件” 代理 3：“通过将等待时间减少到 1000 毫秒来修复计时问题” # 开发者认为：“所有代理都成功了，发货” # 应用所有更改而不检查冲突 # 结果： # \- 特工 1 和特工 3 编辑了同一个文件 # \- 代理 1 增加超时，代理 3 减少超时 # \- 最终代码的超时不一致 # \- Agent 2 的互斥量与 Agent 3 减少的超时交互不良 # \- 集成后测试仍然失败 <为什么失败> * 跳过冲突检查（步骤 5） * 没有仔细阅读每个agent改变了什么 * 代理人做出了相互矛盾的决定 * 代理 1 和代理 3 对时间有不同的假设 * Agent 2 的锁定与时间变化相互作用 * 盲目应用所有修复会导致状态不一致 *“成功”集成后测试失败 * 必须手动解决冲突的更改 ## 代理摘要审查代理 1：通过将等待时间增加到 5000 毫秒来修复超时问题 - 文件：src/agents/tool-executor.ts - 更改：DEFAULT_TIMEOUT = 5000 代理 2：通过添加互斥锁修复竞争条件 - 文件：src/agents/tool-executor.ts - 更改：在工具执行周围添加了互斥锁代理 3：通过将等待时间减少到 1000 毫秒来修复计时问题 - 文件：src/agents/tool-executor.ts - 更改：DEFAULT_TIMEOUT = 1000 ## 冲突分析 **检测到冲突：** - 代理 1 和 3 编辑了同一文件 (tool-executor.ts) - 代理 1 和 3 更改了相同的常量 (DEFAULT_TIMEOUT) - 代理1：增加到5000ms - Agent 3：减少到1000ms - 关于正确时间的矛盾假设 **为什么发生冲突：** - 域实际上并不独立（相同的超时常数） - 两个代理都在本地进行了测试，没有看到交互 - 不同的问题空间导致不同的时间需求 ## 分辨率 **选项1：**不同的操作有不同的超时时间 ``打字稿 const TOOL_EXECUTION_TIMEOUT = 5000 // 代理 1 的需求 const TOOL_APPROVAL_TIMEOUT = 1000 // 代理 3 的需求 **选项 2：** 调查时间变化的原因 * 也许 Agent 1 的测试实际上很慢（修复缓慢问题） * 也许Agent 3的测试是正确的（到处都使用1000ms） **调查后选择选项2：** * 由于不相关的问题，Agent 1 的测试速度很慢 * 修复缓慢问题，各处使用 1000ms 超时 * Agent 2的互斥体兼容1000ms **整合步骤：** 1.应用Agent 2的互斥体（无冲突） 2.应用Agent 3的1000ms超时 3.修复Agent 1测试缓慢的问题（根本原因） 4. 不要应用代理 1 的超时增加（症状修复） **运行完整的测试套件：** ````bash npm测试 # 所有测试均通过 ✅ **您将获得什么：** * 在破坏整合之前发现矛盾 * 了解代理商为何做出不同决定 * 深思熟虑地解决冲突，而不是武断地解决 *修复了根本原因（测试缓慢）而不是症状（长时间超时） * 验证集成工作正常 * 避免运送不一致的代码 * 专业的冲突解决流程 <故障模式> ## 代理陷入困境 **症状：** 5 分钟以上没有进展 **原因：** * 提示过于模糊，agent漫无目的地探索 * 域实际上并不独立，需要来自其他代理的上下文 * 代理遇到了拦截器（丢失文件、不清楚的错误） **恢复：** 1.使用AgentOutput工具检查它在做什么 2. 如果卡在错误的路径上：取消并重试，提示更清晰 3. 如果需要来自其他域的上下文：等待其他代理，然后使用上下文重新启动 4. 如果遇到真正的拦截器：自行调查拦截器，然后重试 ** ** ## 代理返回冲突修复 **症状：** 特工以不同的方式编辑相同的代码，或做出矛盾的假设 **原因：** * 域实际上并不独立 * 域之间共享代码 * 特工对正确行为做出了不同的假设 **恢复：** 1. 不要自动应用任一修复程序 2. 仔细阅读这两个修复 3. 找出冲突点 4. 根据哪个假设是正确的手动解决 5. 考虑是否应该合并域名 ** ** ## 集成破坏了其他测试 **症状：** 固定测试通过，但其他测试现在失败 **原因：** * 代理更改了共享代码 * 代理的修复范围太广 * 代理误解了要求 **恢复：** 1. 确定哪个代理的更改导致了回归 2. 阅读代理的摘要 - 他们是否提到了此更改？ 3. 评估更改是否正确但测试需要更新 4. 或者，如果更改破坏了某些内容，则需要完善修复 5.使用超能力：完成前验证技能进行最终检查 ** ** ## 虚假的独立 **症状：** 修复一个域后发现它影响了另一个域 **恢复：** 1. 合并域 2. 让一名特工一起调查两者 3.学习：预先需要更好的独立性测试 <关键规则> ## 没有例外的规则 1. **先验证独立性** → 发货前带问题测试 2. **需要 3 个以上的域** → 2 次失败：开销超过收益，按顺序执行 3. **单条消息调度** → 通过多个 Task() 调用将所有代理包含在一条消息中 4. **等待所有代理** → 全部完成之前不要集成 5. **手动检查冲突** → 阅读摘要，验证没有矛盾 6. **验证集成** → 自己运行全套套件，不要信任代理 7. **TodoWrite 跟踪** → 明确跟踪代理进度 ## 常见借口所有这些都意味着：**停止。遵循流程。** * “只有 2 次失败，仍然可以并行化”（开销超过收益，按顺序执行） *“可能独立，将派遣并查看”（首先验证独立性） *“可以按顺序分派以保存语法”（错误 - 必须在单个消息中分派） *“特工失败，但其他人成功 - 发货”（所有特工必须成功或重新调查） *“冲突很小，可以忽略”（明确解决所有冲突） *“Don't need TodoWrite for just Tracking Agents”（使用 TodoWrite，正确跟踪） *“可以跳过验证，代理运行测试”（代理可能会犯错误，您需要验证）在完成并行代理工作之前： * 通过 3 个问题验证独立性（修复 A 影响 B？相同的代码？相同的错误模式？） * 识别出 3 个以上独立域（不是 2 个或更少） * 创建有针对性的代理提示（范围、目标、约束、输出） * 在单个消息中调度所有代理（多个 Task() 调用） * 等待所有代理完成（没有提前集成） * 仔细阅读所有代理摘要 * 检查冲突（相同的文件，矛盾的假设） * 在集成之前手动解决所有冲突 *运行完整的测试套件（不仅仅是固定测试） * 使用完成前验证技巧 * 记录哪些代理修复了哪些内容 **无法选中所有复选框？** 返回流程并完成缺失的步骤。 **相关技能：** * 超级能力：使用工具进行调试（如何调查个别故障） * 超能力：修复错误（完整的错误工作流程） * 超级能力：完成前验证（验证集成） * hyperpowers:test-runner（在没有上下文污染的情况下运行测试） **该技能使用：** * 任务工具（调度并行代理） * AgentOutput工具（监控卡住的代理） * TodoWrite（跟踪代理进度） **工作流程集成：** 多次独立故障 ↓ 验证独立性（步骤 1） ↓ 创建代理任务（步骤 2） ↓ 并行调度（步骤 3） ↓ 监控进度（第 4 步） ↓ 审查 + 检查冲突（步骤 5） ↓ 验证集成（步骤 6） ↓ 超能力：完成前验证 **会议（2025-10-03）的真实示例：** * 3 个文件中有 6 次失败 * 3名代理并行出动 * 所有调查同时完成 * 所有修复已成功集成 * 代理变更之间零冲突 * 节省时间：并行解决 3 个问题与顺序解决 **卡住时：** * Agent 没有取得进展 → 检查 AgentOutput，重试并显示更清晰的提示 * 调度后冲突 → 域不独立，合并并重试 * 集成测试失败 → 识别导致回归的代理 * 不清楚是否独立 → 用 3 个问题进行测试（影响？相同的代码？相同的错误？）

调度并行代理

包含技能