为节省 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 、大脑的关键裁决、大致消耗量级。
1
Select Language