用途
该技能用于把可独立处理的任务并行分派给多个专门的智能体（Agent）。它解决的核心问题是：当出现多个互不相关的失败（例如不同的测试文件、不同的子系统、不同的缺陷）时，逐个顺序排查会浪费时间；由于每项排查相互独立，因此可以并行进行。
核心原则：每个独立的问题域分派一个智能体，让它们并发工作。
何时使用
适用情形：
- 3 个以上测试文件因不同根因失败
- 多个子系统各自独立地损坏
- 每个问题无需其他人的上下文即可被理解
- 各次排查之间没有共享状态
不适用情形：
- 失败相互关联（修好一个可能连带修好其他）
- 需要理解完整的系统状态
- 智能体之间会互相干扰
主要能力
- 并行化：多个排查同时进行
- 专注：每个智能体范围窄，需要跟踪的上下文更少
- 独立性：智能体之间互不干扰
- 速度：以处理 1 个问题的时间解决 3 个问题
工作方式上，每个智能体被授予隔离的上下文。通过精确构造其指令与上下文，确保它们保持专注并完成任务；它们不应继承当前会话的上下文或历史——需要为其构造恰好所需的内容，这同时也能为协调工作保留自身的上下文。
使用方式
1. 识别独立的问题域
按“损坏了什么”对失败进行分组，例如：
- 文件 A 测试：工具审批流程
- 文件 B 测试：批次完成行为
- 文件 C 测试：中止功能
每个问题域相互独立——修复工具审批不会影响中止测试。
2. 创建聚焦的智能体任务
每个智能体获得：
- 明确范围：一个测试文件或子系统
- 清晰目标：让这些测试通过
- 约束条件：不要改动其他代码
- 预期输出：所发现与所修复内容的总结
3. 并行分派
在 Claude Code / AI 环境中示例：
Task("Fix agent-tool-abort.test.ts failures")
Task("Fix batch-completion-behavior.test.ts failures")
Task("Fix tool-approval-race-conditions.test.ts failures")
// All three run concurrently
4. 审查与整合
当智能体返回后：
- 阅读每份总结
- 验证各修复之间不冲突
- 运行完整测试套件
- 整合所有改动
智能体提示词结构
好的智能体提示词应当是：
- 聚焦——一个清晰的问题域
- 自包含——包含理解问题所需的全部上下文
- 对输出有明确要求——智能体应当返回什么？
示例提示词：
Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
1. "should abort tool with partial output capture" - expects 'interrupted at' in message
2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
3. "should properly track pendingToolCount" - expects 3 results but gets 0
These are timing/race condition issues. Your task:
1. Read the test file and understand what each test verifies
2. Identify root cause - timing issues or actual bugs?
3. Fix by:
- Replacing arbitrary timeouts with event-based waiting
- Fixing bugs in abort implementation if found
- Adjusting test expectations if testing changed behavior
Do NOT just increase timeouts - find the real issue.
Return: Summary of what you found and what you fixed.
常见错误
- 过于宽泛：“修复所有测试”——智能体会迷失方向 正确做法：具体化：“修复 agent-tool-abort.test.ts”——范围聚焦
- 缺少上下文：“修复竞态条件”——智能体不知道该从哪里下手 正确做法：提供上下文：粘贴错误信息和测试名称
- 没有约束：智能体可能重构一切 正确做法：给出约束：“不要改动生产代码”或“只修复测试”
- 输出含糊：“修好它”——你不知道改了什么 正确做法：明确要求：“返回根因与改动的总结”
何时不要使用
- 相互关联的失败：修好一个可能修好其他——应先一起排查
- 需要完整上下文：理解问题需要看到整个系统
- 探索性调试：你尚不知道哪里坏了
- 共享状态：智能体之间会互相干扰（编辑同一文件、使用同一资源）
适用场景与实例
某次会话中的真实场景：在一次重大重构之后出现 6 个测试失败，分布在 3 个文件中。
失败情况：
- agent-tool-abort.test.ts：3 个失败（时序问题）
- batch-completion-behavior.test.ts：2 个失败（工具未执行）
- tool-approval-race-conditions.test.ts：1 个失败（执行计数 = 0）
决策：属于独立问题域——中止逻辑、批次完成、竞态条件彼此分离。
分派：
- 智能体 1 → 修复 agent-tool-abort.test.ts
- 智能体 2 → 修复 batch-completion-behavior.test.ts
- 智能体 3 → 修复 tool-approval-race-conditions.test.ts
结果：
- 智能体 1：用基于事件的等待替换超时
- 智能体 2：修复事件结构缺陷（threadId 放错位置）
- 智能体 3：增加对异步工具执行完成的等待
整合：所有修复相互独立、无冲突，完整测试套件通过。节省时间：3 个问题并行解决，而非顺序解决。
另一实例（2025-10-03 的调试会话）：3 个文件中共 6 个失败，并行分派 3 个智能体，所有排查并发完成，所有修复成功整合，智能体改动之间零冲突。
验证
智能体返回之后：
- 审查每份总结——理解改动了什么
- 检查冲突——智能体是否编辑了同一段代码？
- 运行完整套件——验证所有修复能协同工作
- 抽查——智能体可能犯系统性错误
限制
上述资料的“何时不要使用”部分明确列出了不适用范围：失败相互关联、需要完整系统状态、探索性调试、以及存在共享状态导致智能体互相干扰的情况。除这些条件之外，关于收费、价格、平台与具体效果的更多信息暂未提供。