Fable 出方案、Opus 执行、Advisor 验收：一套省 Token 的 Agent 闭环流程

Token 越来越贵，最近被成本逼着试出了一套新流程：既能把花费压下来，效果又没打折。

流程的骨架很短：

Fable 出设计方案 → （进入循环） Opus 负责执行 → Advisor（Fable）负责验收 （循环结束）

第一步：先把 advisor 指定为 Fable

在 Claude 里执行：

/advisor fable

设好之后，用 Opus 或 Sonnet 干活时，一旦遇到拿不准的地方，它们会主动去问 Fable。代价是可能产生一些没必要的 Fable 调用，但这点开销可以接受，也划得来。

相当于给团队请了一位高级工程师当顾问。

第二步：难题先交给 Fable 出方案

问题一旦复杂，先让 Fable 把方案写出来，把它的能力用足。

思路和现实中的分工一样：技术方案由高级工程师来写，具体落地交给普通工程师。

第三步：方案确认后交由 Opus 执行

执行时补上一句提示词：

完成后让你的 advisor 验收一下，如果验收有问题就按 advisor 的反馈修复，修复完成后再让 advisor 验收，直到通过 advisor 的验收为止

搭配 /goal 一起用，效果会更好。

这样一来，Opus 干完活会自己去找 Advisor 验收；Advisor 如果发现问题会给出反馈，Opus 再接着改。

这套流程省掉的是什么

最大的变化是不再需要人工介入 Fable 的确认环节。以前的做法是：Opus 执行完毕，我得回到早先那个 Fable 会话里让它验收，或者干脆新开一个会话，把文档发过去。

现在 Agent 之间自己就形成了闭环，人不必参与其中。

换个说法：请一位高级顾问，复杂问题由顾问出方案，执行交给工程师按方案落实；工程师每次做完自己去请顾问验收，顾问不光验收，还会指出哪里不对，工程师再自行修正——不用每做完一次都先找你，再由你转给顾问。