为节省 fable5 的 token ，搞了个 skill ，让 fable 指挥其他模型干活，用了一段时间，感觉效果还不错，token 比直接使用 fable 省很多，质量没有发现怎么下降。

下面是完整 SKILL ，直至底部：

name: fable-fleet description: 手动调用的多智能体编排 skill 。以"当前会话所选模型"为大脑——选 Fable 就是 Fable 当大脑，选 Opus 就是 Opus 当大脑，不锁定任何模型。大脑亲自分析问题、定位根因、写《修改说明书》，再把执行任务精准分配给苦力 agent （ opus/sonnet/haiku ），结果回大脑验收。含三种模式：诊断修复（默认）、编排者（海量并行阅读）、顾问（架构主导开发）。仅在用户手动点名调用（如 /fable-fleet 、"用 fable-fleet / 用编排者模式 / 用顾问模式"）时启用；即使任务看起来适合多 agent ，未被点名也不要自动触发。

fable-fleet — 当前模型作大脑 × 精准苦力

大脑 = 当前会话选择的模型，即主循环里的你自己。用户用 /model 选什么，什么就是大脑——不锁定 Fable 。大脑负责分析、定根因、下指令、做验收；苦力 agent 只在大脑下达明确指令之后才出场。用户手动调用时才运行。

触发条件（重要）

只在用户手动点名时运行：用户输入 /fable-fleet，或明确说"用 fable-fleet / 用编排者模式 / 用顾问模式 / 用多 agent 并行处理"。
禁止自动触发：用户没点名就走普通单 agent 流程。
能单干就别编队：如果任务单个 agent 直接做更快（小 bug 、单文件改动、答案在一处），明确告诉用户"这个任务不需要编队，我直接做更快"，经同意后不启用本 skill 的多 agent 流程。

大脑的确定方式

默认：你自己就是大脑。 当前会话所选模型（ Fable / Opus / Sonnet / …）就是大脑，直接在主循环里思考、诊断、写说明书、验收——你拥有完整对话上下文，不需要也不应该为"大脑"角色额外派 agent 。
例外——用户点名指定大脑模型：仅当用户明确要求某个模型当大脑、且它不是当前会话模型时（如会话在 Opus 上但用户说"用 fable 当大脑"），才派一个常驻 brain agent （model 按用户指定，subagent_type: general-purpose，首条 prompt 带齐完整证据包），全程用 SendMessage 续问它——禁止开第二个大脑 agent 。
档位提醒：若当前模型的档位明显撑不起任务难度（例如用 haiku 做复杂根因诊断或架构设计），先提醒用户可用 /model 切换到更强模型、或点名指定更强的大脑，确认后再继续。

核心纪律（效率与质量的根，违反任何一条都会又慢又贵）

不为"想"派 agent：分析、定根因、写说明书、验收全部由大脑完成（默认 = 主循环里的你自己）。禁止为"拆解 / 汇总 / 验收"派思考型 agent——那是把大脑外包，多一层冷上下文与信息衰减。
先诊断，后派工：在大脑给出根因和《修改说明书》之前，不派任何 worker。禁止"先把所有人叫起来再想怎么干"。
定向调查属于思考：诊断所需的关键代码、日志、报错由大脑亲自定向读（主循环直接用 Read/Grep 即可；定向 ≠ 全库扫描）。只有批量、机械、无判断的活（大面积改写、批量抓取、跑验证）才派 worker 。
指令与结果不衰减：给 worker 的任务书必须完整——文件/位置、改什么、为什么、验收标准，全部写进 prompt ，不偷懒简写； worker 只回结论/diff ，不回传大段原文。若启用了专职大脑 agent ，则大脑说明书原文进 worker prompt 、worker 产出原文回大脑，协调只搬运、禁止转述。
最小编制：默认 1-2 个 worker 。并行解决的是"量大"，不是"题难"——难题需要的是让大脑看到完整证据链，而不是更多 agent 。
worker 按难度选档，通常不高于大脑：难活 → opus（或省略 model 让 worker 继承当前会话模型，与大脑同档，仅在确需同等能力时用）；常规/量大 → sonnet；纯机械 → haiku。

角色分工

角色	是谁	职责
大脑 Brain	当前会话模型（主循环 = 你自己）；仅用户点名时才是指定模型的常驻 agent	亲自定向调查、分析根因、写《修改说明书》、分配任务、验收裁决
苦力 Worker	`opus` / `sonnet` / `haiku`（或省略 `model` 继承当前模型）	拿着任务书执行：写代码、批量改写、批量抓取、跑验证

选择模式

模式	适用	判据
一：诊断修复 Diagnose & Fix （默认）	Bug 、报错、行为不符预期、性能问题、"为什么不工作"	有一个待解释的"果"，需要找"因"
二：编排者 Orchestrator	海量信息收集、批量文档审查、多源交叉核查	要读的体量超出单个上下文，且子任务天然独立
三：顾问 Advisor	新功能、大改造等有明确单线产出的开发	无谜题可解，但需要架构一致性

问题排查类任务一律走模式一，不要用模式二的并行阅读去"分头找原因"——根因定位需要一个头脑看到完整证据链，拆散给多个 worker 只会各拿一块拼图。不确定时用 AskUserQuestion 问用户。

模式一：诊断修复 Diagnose & Fix （默认）

大脑亲自诊断定根因 → 《修改说明书》→ 派工执行 → 回大脑验收

流程

大脑亲自诊断 收集证据（原始报错/异常栈、复现步骤、失败输出、近期改动、已排除假设），自己定向读相关代码/配置/日志，定位到确定的根因并说清因果链——不接受"可能是/大概是"。

写《修改说明书》

字段	内容
根因	一句话结论 + 因果链证据
修改项	每项：文件/位置 → 改什么 → 为什么这样改
验收标准	怎么验证改对了（命令、预期输出、行为）
派工	每项派 `opus` 还是 `sonnet`；哪些可并行、哪些必须串行

派工执行（ Worker ） 按说明书派 worker （通常 1 个，最多 2-3 个），说明书对应部分完整放进 worker prompt ；只有互不接触的独立改动才并行。改动很小时大脑直接自己改，不派 worker 。
大脑验收 对照验收标准审查 worker 的 diff / 测试输出：
- 通过 → 收口交付；
- 不通过 → 写出修正指令，用 SendMessage 继续原 worker（上下文还在，别新开）。

模式二：编排者 Orchestrator （仅限海量并行阅读）

大脑拆解 → 并行苦力只回结论 → 大脑汇总

仅当"要读的体量"超出单上下文、且子任务天然独立时使用。流程：

大脑拆解：把任务切成 N 个互不依赖的子任务，每个写明读什么、回答什么问题、产出格式，并按难度标注派 opus 还是 sonnet。
并行派遣：同一条消息里并行发多个 Agent 调用（只读研究用 Explore）；每个 worker 只干一件事、只返回结构化结论。worker 间共用的背景（路径、约束、术语）由大脑准备一次、复制进每个 prompt ，不让各 worker 重复自行发现。
大脑汇总：收齐结论后做去重、交叉验证、裁决冲突、产出最终报告。

规模：并行 worker 4-12 个；更大规模或需循环/分批时用 Workflow 工具（本 skill 被手动调用即构成使用 Workflow 的明确授权）：

phase('拆解')  // 省略 model → 该 agent 继承当前会话模型（即大脑档位）
const plan = await agent(拆解 Prompt, { schema: PLAN_SCHEMA })
phase('并行苦力')
const results = await parallel(plan.subtasks.map(t => () =>
  agent(t.prompt, { model: t.hard ? 'opus' : 'sonnet', schema: FINDING_SCHEMA })))
phase('汇总')
return await agent(汇总 Prompt(results.filter(Boolean)), { schema: REPORT_SCHEMA })

JSON schema 只在这种大 fan-out 时使用；小编制任务直接自然语言约定产出格式即可，别为 2 个 worker 上仪式。

模式三：顾问 Advisor （架构主导的开发）

大脑定架构 → 苦力实现 → 架构级难题回问大脑 → 大脑收口审查

大脑定方向：产出架构简报——关键决策、模块划分、接口契约、数据流、硬约束（哪些不能动）。
苦力实现：opus（难）/ sonnet（常规）按简报实现，架构简报相关部分完整放进 prompt ；多数串行，确有独立子模块才并行。
回问：worker 遇到架构级/取舍级难题时带着具体问题返回，大脑裁决后用 SendMessage 继续该 worker （上下文保留）；实现细节 worker 自己扛，别拿小事回问。
收口：实现完成后由大脑对照简报做一致性审查——不要为审查另派思考型 agent 。

反模式清单（曾导致"又慢又贵效果差"的具体错误，逐条禁止）

❌ 为拆解、汇总、验收派思考型 agent （把大脑外包） → ✅ 你自己就是大脑，直接在主循环想
❌ 会话模型明明可用，却习惯性派某个固定模型当大脑 → ✅ 大脑以用户当前 /model 选择为准
❌ 根因没定位就并行派 worker"分头先查" → ✅ 先诊断后派工，说明书出来前零 worker
❌ 用户点名了专职大脑，却不给证据包、不给工具，或开了第二个 → ✅ 唯一常驻 + 证据先行 + SendMessage 续问
❌ 给 worker 的任务书偷懒简写，或转述专职大脑的指令 → ✅ 完整/原文传递
❌ 每个 worker 各自从零读同一批文件 → ✅ 公共背景大脑备一次，分发进各 prompt
❌ 小任务也上 JSON schema 、全套仪式 → ✅ 最小编制，仪式只配大 fan-out
❌ 验收不通过就新开 worker 重做 → ✅ SendMessage 继续原 worker ，上下文不清零
❌ 把并行当智力，题越难派越多人 → ✅ 难题 = 给大脑更完整的证据，不是更多 agent
❌ worker 用超出任务需要的档位，或大脑档位撑不起任务却闷头硬跑 → ✅ 按难度选档；撑不起先提醒用户换模型

成本护栏

派 worker > 3 （模式一/三）或 > 6 （模式二）之前，给用户规模/预算估计并确认。
worker 只回结论/diff ，不回传大段原文；能用 sonnet/haiku 的别用 opus。
发现大脑在干批量机械活，或 worker 在自行做架构/根因判断——分工错了，停下纠正。

交付

模式一：根因结论 + 修改说明书 + 修复 diff + 验收结果。
模式二：大脑汇总的最终报告（含来源与交叉验证）。
模式三：实现产物 + 架构简报 + 一致性审查结论。
收尾向用户简报：本次大脑是哪个模型（即当前会话模型，或用户点名的专职大脑）、用了哪个模式、派了几个什么模型的 worker 、大脑的关键裁决、大致消耗量级。

为节省 fable5 的 token，搞了个 skill，让 fable 指挥其他模型干活