为节省 fable5 的 token，搞了个 skill，让 fable 指挥其他模型干活
wdzj: 为节省 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 流程。
## 大脑的确定方式
1. **默认：你自己就是大脑。** 当前会话所选模型（ Fable / Opus / Sonnet / …）就是大脑，直接在主循环里思考、诊断、写说明书、验收——你拥有完整对话上下文，**不需要也不应该**为"大脑"角色额外派 agent 。
2. **例外——用户点名指定大脑模型**：仅当用户明确要求某个模型当大脑、且它不是当前会话模型时（如会话在 Opus 上但用户说"用 fable 当大脑"），才派**一个常驻** brain agent （`model` 按用户指定，`subagent_type: general-purpose`，首条 prompt 带齐完整证据包），全程用 `SendMessage` 续问它——禁止开第二个大脑 agent 。
3. **档位提醒**：若当前模型的档位明显撑不起任务难度（例如用 haiku 做复杂根因诊断或架构设计），先提醒用户可用 `/model` 切换到更强模型、或点名指定更强的大脑，确认后再继续。
## 核心纪律（效率与质量的根，违反任何一条都会又慢又贵）
1. **不为"想"派 agent**：分析、定根因、写说明书、验收全部由大脑完成（默认 = 主循环里的你自己）。禁止为"拆解 / 汇总 / 验收"派思考型 agent——那是把大脑外包，多一层冷上下文与信息衰减。
2. **先诊断，后派工**：在大脑给出根因和《修改说明书》之前，**不派任何 worker**。禁止"先把所有人叫起来再想怎么干"。
3. **定向调查属于思考**：诊断所需的关键代码、日志、报错由大脑**亲自定向读**（主循环直接用 Read/Grep 即可；定向 ≠ 全库扫描）。只有**批量、机械、无判断**的活（大面积改写、批量抓取、跑验证）才派 worker 。
4. **指令与结果不衰减**：给 worker 的任务书必须完整——文件/位置、改什么、为什么、验收标准，全部写进 prompt ，不偷懒简写； worker 只回结论/diff ，不回传大段原文。若启用了专职大脑 agent ，则大脑说明书**原文**进 worker prompt 、worker 产出**原文**回大脑，协调只搬运、禁止转述。
5. **最小编制**：默认 1-2 个 worker 。并行解决的是"量大"，不是"题难"——难题需要的是让大脑看到完整证据链，而不是更多 agent 。
6. **worker 按难度选档，通常不高于大脑**：难活 → `opus`（或省略 `model` 让 worker 继承当前会话模型，与大脑同档，仅在确需同等能力时用）；常规/量大 → `sonnet`；纯机械 → `haiku` 。
## 角色分工
| 角色 | 是谁 | 职责 |
| --- | --- | --- |
| 大脑 Brain | **当前会话模型（主循环 = 你自己）**；仅用户点名时才是指定模型的常驻 agent | 亲自定向调查、分析根因、写《修改说明书》、分配任务、验收裁决 |
| 苦力 Worker | `opus` / `sonnet` / `haiku`（或省略 `model` 继承当前模型） | 拿着任务书执行：写代码、批量改写、批量抓取、跑验证 |
## 选择模式
| 模式 | 适用 | 判据 |
| --- | --- | --- |
| **一：诊断修复 Diagnose & Fix （默认）** | Bug 、报错、行为不符预期、性能问题、"为什么不工作" | 有一个待解释的"果"，需要找"因" |
| **二：编排者 Orchestrator** | 海量信息收集、批量文档审查、多源交叉核查 | 要读的体量超出单个上下文，且子任务天然独立 |
| **三：顾问 Advisor** | 新功能、大改造等有明确单线产出的开发 | 无谜题可解，但需要架构一致性 |
问题排查类任务一律走模式一，**不要**用模式二的并行阅读去"分头找原因"——根因定位需要一个头脑看到完整证据链，拆散给多个 worker 只会各拿一块拼图。不确定时用 `AskUserQuestion` 问用户。
---
## 模式一：诊断修复 Diagnose & Fix （默认）
> 大脑亲自诊断定根因 → 《修改说明书》→ 派工执行 → 回大脑验收
### 流程
1. **大脑亲自诊断** 收集证据（原始报错/异常栈、复现步骤、失败输出、近期改动、已排除假设），**自己定向读**相关代码/配置/日志，定位到**确定的根因**并说清因果链——不接受"可能是/大概是"。
2. **写《修改说明书》**
| 字段 | 内容 |
| --- | --- |
| 根因 | 一句话结论 + 因果链证据 |
| 修改项 | 每项：文件/位置 → 改什么 → 为什么这样改 |
| 验收标准 | 怎么验证改对了（命令、预期输出、行为） |
| 派工 | 每项派 `opus` 还是 `sonnet`；哪些可并行、哪些必须串行 |
|
3. **派工执行（ Worker ）** 按说明书派 worker （通常 1 个，最多 2-3 个），说明书对应部分**完整**放进 worker prompt ；只有互不接触的独立改动才并行。改动很小时大脑直接自己改，不派 worker 。
4. **大脑验收** 对照验收标准审查 worker 的 diff / 测试输出：
- 通过 → 收口交付；
- 不通过 → 写出修正指令，用 `SendMessage` **继续原 worker**（上下文还在，别新开）。
---
## 模式二：编排者 Orchestrator （仅限海量并行阅读）
> 大脑拆解 → 并行苦力只回结论 → 大脑汇总
仅当"要读的体量"超出单上下文、且子任务**天然独立**时使用。流程：
1. **大脑拆解**：把任务切成 N 个互不依赖的子任务，每个写明读什么、回答什么问题、产出格式，并按难度标注派 `opus` 还是 `sonnet` 。
2. **并行派遣**：同一条消息里并行发多个 `Agent` 调用（只读研究用 `Explore`）；每个 worker 只干一件事、**只返回结构化结论**。worker 间共用的背景（路径、约束、术语）由大脑准备一次、复制进每个 prompt ，不让各 worker 重复自行发现。
3. **大脑汇总**：收齐结论后做去重、交叉验证、裁决冲突、产出最终报告。
规模：并行 worker 4-12 个；更大规模或需循环/分批时用 `Workflow` 工具（本 skill 被手动调用即构成使用 Workflow 的明确授权）：
```javascript
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 （架构主导的开发）
> 大脑定架构 → 苦力实现 → 架构级难题回问大脑 → 大脑收口审查
1. **大脑定方向**：产出架构简报——关键决策、模块划分、接口契约、数据流、硬约束（哪些不能动）。
2. **苦力实现**：`opus`（难）/ `sonnet`（常规）按简报实现，架构简报相关部分**完整**放进 prompt ；多数串行，确有独立子模块才并行。
3. **回问**：worker 遇到**架构级/取舍级**难题时带着具体问题返回，大脑裁决后用 `SendMessage` 继续该 worker （上下文保留）；实现细节 worker 自己扛，别拿小事回问。
4. **收口**：实现完成后由大脑对照简报做一致性审查——不要为审查另派思考型 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 、大脑的关键裁决、大致消耗量级。
---
原文链接：[点击查看](https://www.v2ex.com/t/1230495)
下面是完整 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 流程。
## 大脑的确定方式
1. **默认：你自己就是大脑。** 当前会话所选模型（ Fable / Opus / Sonnet / …）就是大脑，直接在主循环里思考、诊断、写说明书、验收——你拥有完整对话上下文，**不需要也不应该**为"大脑"角色额外派 agent 。
2. **例外——用户点名指定大脑模型**：仅当用户明确要求某个模型当大脑、且它不是当前会话模型时（如会话在 Opus 上但用户说"用 fable 当大脑"），才派**一个常驻** brain agent （`model` 按用户指定，`subagent_type: general-purpose`，首条 prompt 带齐完整证据包），全程用 `SendMessage` 续问它——禁止开第二个大脑 agent 。
3. **档位提醒**：若当前模型的档位明显撑不起任务难度（例如用 haiku 做复杂根因诊断或架构设计），先提醒用户可用 `/model` 切换到更强模型、或点名指定更强的大脑，确认后再继续。
## 核心纪律（效率与质量的根，违反任何一条都会又慢又贵）
1. **不为"想"派 agent**：分析、定根因、写说明书、验收全部由大脑完成（默认 = 主循环里的你自己）。禁止为"拆解 / 汇总 / 验收"派思考型 agent——那是把大脑外包，多一层冷上下文与信息衰减。
2. **先诊断，后派工**：在大脑给出根因和《修改说明书》之前，**不派任何 worker**。禁止"先把所有人叫起来再想怎么干"。
3. **定向调查属于思考**：诊断所需的关键代码、日志、报错由大脑**亲自定向读**（主循环直接用 Read/Grep 即可；定向 ≠ 全库扫描）。只有**批量、机械、无判断**的活（大面积改写、批量抓取、跑验证）才派 worker 。
4. **指令与结果不衰减**：给 worker 的任务书必须完整——文件/位置、改什么、为什么、验收标准，全部写进 prompt ，不偷懒简写； worker 只回结论/diff ，不回传大段原文。若启用了专职大脑 agent ，则大脑说明书**原文**进 worker prompt 、worker 产出**原文**回大脑，协调只搬运、禁止转述。
5. **最小编制**：默认 1-2 个 worker 。并行解决的是"量大"，不是"题难"——难题需要的是让大脑看到完整证据链，而不是更多 agent 。
6. **worker 按难度选档，通常不高于大脑**：难活 → `opus`（或省略 `model` 让 worker 继承当前会话模型，与大脑同档，仅在确需同等能力时用）；常规/量大 → `sonnet`；纯机械 → `haiku` 。
## 角色分工
| 角色 | 是谁 | 职责 |
| --- | --- | --- |
| 大脑 Brain | **当前会话模型（主循环 = 你自己）**；仅用户点名时才是指定模型的常驻 agent | 亲自定向调查、分析根因、写《修改说明书》、分配任务、验收裁决 |
| 苦力 Worker | `opus` / `sonnet` / `haiku`（或省略 `model` 继承当前模型） | 拿着任务书执行：写代码、批量改写、批量抓取、跑验证 |
## 选择模式
| 模式 | 适用 | 判据 |
| --- | --- | --- |
| **一：诊断修复 Diagnose & Fix （默认）** | Bug 、报错、行为不符预期、性能问题、"为什么不工作" | 有一个待解释的"果"，需要找"因" |
| **二：编排者 Orchestrator** | 海量信息收集、批量文档审查、多源交叉核查 | 要读的体量超出单个上下文，且子任务天然独立 |
| **三：顾问 Advisor** | 新功能、大改造等有明确单线产出的开发 | 无谜题可解，但需要架构一致性 |
问题排查类任务一律走模式一，**不要**用模式二的并行阅读去"分头找原因"——根因定位需要一个头脑看到完整证据链，拆散给多个 worker 只会各拿一块拼图。不确定时用 `AskUserQuestion` 问用户。
---
## 模式一：诊断修复 Diagnose & Fix （默认）
> 大脑亲自诊断定根因 → 《修改说明书》→ 派工执行 → 回大脑验收
### 流程
1. **大脑亲自诊断** 收集证据（原始报错/异常栈、复现步骤、失败输出、近期改动、已排除假设），**自己定向读**相关代码/配置/日志，定位到**确定的根因**并说清因果链——不接受"可能是/大概是"。
2. **写《修改说明书》**
| 字段 | 内容 |
| --- | --- |
| 根因 | 一句话结论 + 因果链证据 |
| 修改项 | 每项：文件/位置 → 改什么 → 为什么这样改 |
| 验收标准 | 怎么验证改对了（命令、预期输出、行为） |
| 派工 | 每项派 `opus` 还是 `sonnet`；哪些可并行、哪些必须串行 |
|
3. **派工执行（ Worker ）** 按说明书派 worker （通常 1 个，最多 2-3 个），说明书对应部分**完整**放进 worker prompt ；只有互不接触的独立改动才并行。改动很小时大脑直接自己改，不派 worker 。
4. **大脑验收** 对照验收标准审查 worker 的 diff / 测试输出：
- 通过 → 收口交付；
- 不通过 → 写出修正指令，用 `SendMessage` **继续原 worker**（上下文还在，别新开）。
---
## 模式二：编排者 Orchestrator （仅限海量并行阅读）
> 大脑拆解 → 并行苦力只回结论 → 大脑汇总
仅当"要读的体量"超出单上下文、且子任务**天然独立**时使用。流程：
1. **大脑拆解**：把任务切成 N 个互不依赖的子任务，每个写明读什么、回答什么问题、产出格式，并按难度标注派 `opus` 还是 `sonnet` 。
2. **并行派遣**：同一条消息里并行发多个 `Agent` 调用（只读研究用 `Explore`）；每个 worker 只干一件事、**只返回结构化结论**。worker 间共用的背景（路径、约束、术语）由大脑准备一次、复制进每个 prompt ，不让各 worker 重复自行发现。
3. **大脑汇总**：收齐结论后做去重、交叉验证、裁决冲突、产出最终报告。
规模：并行 worker 4-12 个；更大规模或需循环/分批时用 `Workflow` 工具（本 skill 被手动调用即构成使用 Workflow 的明确授权）：
```javascript
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 （架构主导的开发）
> 大脑定架构 → 苦力实现 → 架构级难题回问大脑 → 大脑收口审查
1. **大脑定方向**：产出架构简报——关键决策、模块划分、接口契约、数据流、硬约束（哪些不能动）。
2. **苦力实现**：`opus`（难）/ `sonnet`（常规）按简报实现，架构简报相关部分**完整**放进 prompt ；多数串行，确有独立子模块才并行。
3. **回问**：worker 遇到**架构级/取舍级**难题时带着具体问题返回，大脑裁决后用 `SendMessage` 继续该 worker （上下文保留）；实现细节 worker 自己扛，别拿小事回问。
4. **收口**：实现完成后由大脑对照简报做一致性审查——不要为审查另派思考型 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 、大脑的关键裁决、大致消耗量级。
---
原文链接：[点击查看](https://www.v2ex.com/t/1230495)
· 0 个赞
· 0 个赞