kscz0000 Subagent Orchestrator
配额感知的并行子智能体协调技能，专为 Antigravity 2.0 设计。将一个大任务拆分为一组隔离、高效的智能体任务——不会耗尽你的每周配额。
何时使用此技能
- 任务涉及 3 个以上文件或组件
- 你需要多个智能体同时工作
- 之前在任务中途遇到过配额问题
- 任务既包含规划又包含构建
- 你需要浏览器智能体 + 代码智能体 + 终端智能体同时运行
何时不使用此技能
- 只编辑单个文件或修复一个 bug
- 写一个不到 50 行的快速脚本
- 只是提问或生成一个方案
阶段 1 — 分解（在任何智能体运行之前）
在生成任何子智能体之前，协调器必须产出一份任务简报。先声明：
"正在运行 subagent-orchestrator 技能。将任务分解为隔离的任务。"
然后按以下格式输出任务简报：
MISSION BRIEF
─────────────────────────────────────────
Goal: [一句话，完成后的样子]
Total Agents: [N]
Quota Strategy: [FLASH / SONNET / MIXED]
Expected Token Cost: [LOW / MEDIUM / HIGH]
AGENTS:
[1] ID: agent-001
Role: [例如 Planner / Builder / Tester / Browser]
Scope: [此智能体涉及的确切文件或 URL]
Model: [Gemini Flash / Claude Sonnet]
Input: [它接收什么]
Output: [它产出什么]
Depends on: [none / agent-001]
[2] ...
─────────────────────────────────────────
等待用户批准任务简报后再继续。 如果用户修改了简报，更新并重新确认。永远不要跳过这一步。
阶段 2 — 配额路由
在分配模型之前，应用此决策树：
任务是否超过 20 个文件或 500 行新代码？
是 → 所有智能体使用 Gemini Flash。仅将 Sonnet 保留给最终审查。
否 → 任务是否为创意 UI / 复杂逻辑 / API 设计？
是 → 构建智能体使用 Sonnet，其他全部使用 Flash。
否 → 全部使用 Gemini Flash。
模型成本规则（永远不要违反）：
- Claude Opus → 永远不要在子智能体中使用。太贵了。
- Claude Sonnet → 每次任务最多 1 个子智能体。
- Gemini Flash → 所有子智能体的默认选择。快速、便宜、独立配额池。
- 浏览器子智能体 → 始终在独立配额池上运行。谨慎使用（每次任务最多 1 个）。
阶段 3 — 上下文隔离
每个子智能体获得一个限定范围的上下文包。永远不要给所有智能体完整的代码库。
为每个智能体准备：
AGENT CONTEXT PACKET — agent-[ID]
Files to read: [仅列出此智能体需要的文件]
Files to write: [仅列出此智能体将创建/编辑的文件]
Do NOT read: [明确排除不相关文件]
Knowledge: [仅粘贴 GEMINI.md 中的相关部分]
规则：如果智能体不需要 node_modules、package-lock.json、.next/ 或 dist/——在智能体运行前将它们添加到 .antigravityignore。
阶段 4 — 并行执行
按依赖顺序生成智能体：
第 1 轮（无依赖）：并行运行智能体
第 2 轮（依赖第 1 轮）：等待第 1 轮全部输出后运行
第 3 轮（最终）：集成 + 验证
在轮次之间，协调器必须：
- 收集每个智能体的输出产物
- 运行 3 点抽查：
- 智能体是否留在了其指定范围内？
- 是否存在与其他智能体输出的 import/export 冲突？
- 是否有智能体产生了占位符（"TODO"、"implement later"）？
- 如果任何检查失败 → 用修正后的上下文重新运行该智能体。不要继续。
阶段 5 — 错误恢复
如果子智能体失败或产出有问题的输出：
RECOVERY PROTOCOL
─────────────────────────────────────────
1. 不要重新运行整个任务。
2. 定位确切的故障点。
3. 生成一个单独的修复智能体：
- 范围仅限于有问题的文件
- 以错误消息作为上下文
- 模型：Gemini Flash（修复最便宜）
4. 在继续之前验证修复。
─────────────────────────────────────────
永远不要将有问题的输出传递给下一个智能体。一定要先修复再前进。
阶段 6 — 集成检查
所有智能体完成后，运行最终集成扫描：
- 所有 import 都能正确解析
- 跨文件没有重复的函数/变量名
- 没有应该是环境变量的硬编码值
- 生产文件中没有遗留的
console.log - 组件间类型一致（TypeScript）
- 构建能够成功（
npm run build心理验证）
如果任何检查失败，生成一个限定在确切问题范围内的最终修复智能体。
配额监控规则
在整个任务过程中跟踪预估用量：
| 事件 | 配额影响 |
|---|---|
| 生成智能体 | LOW（设置） |
| 文件索引（每个） | LOW |
| 工具调用（文件读写） | MEDIUM |
| 终端命令 | MEDIUM |
| 浏览器子智能体激活 | HIGH |
| 思考模式启用 | VERY HIGH |
如果任务中途预估用量超过冲刺配额的 60%：
- 暂停并报告："配额检查点：已使用约 60% 冲刺配额。继续还是推迟剩余智能体？"
- 将剩余智能体切换为 Gemini Flash
- 如果浏览器子智能体尚未启动则禁用
通信规则
- 始终声明正在运行哪个智能体
- 在轮次之间显示简洁的进度条：
Mission Progress: ████████░░ 4/5 agents complete Quota Status: ▓▓▓▓░░░░░░ ~40% sprint used - 永远不要沉默超过一个智能体轮次
- 如果被阻塞，明确说明原因——不要直接停下来
示例
参见 examples/ 文件夹：
nextjs-feature.md— 使用 3 个并行智能体构建完整的 Next.js 功能api-plus-frontend.md— 后端 API 智能体 + 前端 UI 智能体并行运行debug-mission.md— 使用最少配额修复构建故障的修复任务
限制
- 此技能协调智能体规划；不提供运行时调度器，也不自动执行配额限制。
- 并行智能体仍需父智能体显式限定范围、审查和集成。
- 当单次聚焦编辑或直接回答更快更清晰时，不要使用此技能。