Fable 出方案、Opus 执行、Advisor 验收的省钱闭环

最近摸索了一种新的节约 Token 但是效果不错的模式（都是被逼的，Token 太贵）： Fable 写设计方案 -> （Loop 开始） Opus 执行 -> Advisor（Fable） 验收 （Loop 结束） 步骤是这样的： 1. 先 Claude 里面设置一下 advisor 为 Fable > /advisor fable 这样在使用 Opus，Sonnet 模型的时候，遇事不决它会请教 Fable，可能会有无谓的 Fable 消耗，但还是可以接受也值得 就好比请了个高级工程师当顾问 2. 复杂一点的问题先让 Fable 出方案，最大化利用 Fable 的能力。 就好比你让一个高级工程师写一个技术方案，让普通工程师去执行 3. 方案写好了确认了，让 Opus 去执行，但是执行的时候，加一句提示词： > 完成后让你的 advisor 验收一下，如果验收有问题就按 advisor 的反馈修复，修复完成后再让 advisor 验收，直到通过 advisor 的验收为止 可以配合 /goal 使用效果更佳 这样 Opus 在实施完成后就会找 Advisor 验收，通过 Advisor 就会给出反馈，然后 Opus 继续修改。 这样的好处就是整个过程你不需要人工去用 Fable 确认—— 以前我就是这么干的，Opus 执行完，我得回到之前 Fable 的会话去让它验收，或者新开一个会话，把文档发给 Fable 验收。 现在 Agent 自己就能形成闭环，不用你自己参与。 就好比你请了个高级顾问，复杂问题找顾问出方案，执行让你的工程师去按照方案执行，每次工程师做完自己去找顾问验收，顾问不仅验收还会告诉工程师哪里不对，然后工程师自己改，不用说每次做完找你，你再找顾问。

现在我很多复杂一点的任务都是 Fable 5 写方案，Codex 去执行，Fable 5 验收，相对来说可以做出比较靠谱的方案，以及兼顾性价比。具体是这么做的： 1. Fable 5 的产出是技术方案文档（图1） 一方面文档方便批注修改，另一方面文档方便其他 Agent 快速上手 2. 文档确认后在当前先 /compact 一次 这一步不是必要的，但是有好处，因为后续还要在同一会话去验证，/compact 压缩后，节约后续的上下文空间，之所以讨论方案就马上发送 /compact，因为这时候 Prompt Caching 还在，成本低，后面缓存过期了 compact 要贵一点。 3. 把文档交给 Codex （GPT-5.6 Sol xhigh）去执行（图2） 如果任务明显比较复杂，我一般会加上 /goal，这样中间就不需要反复去 continue，一次性把任务完成 4. Codex 完成后让 Fable 验证（图3） 直接告诉 Fable 其他 Agent 已经实施了，让它确认有没有遗漏，或者方向有无偏离。 如果有些遗漏之类的，把 Fable 的反馈发回给 Codex（图4），不需要新开会话，在同一个 Codex 会话，Codex 会根据反馈继续完善。 --- 如果用 Opus 5 替代 GPT 5.6 也可以，做法上可以跟上面一样新开会话，用文档传递上下文。 也可以直接让 Fable 5 开 SubAgent 并指定用 Opus 5 模型，并且要求在 SubAgent 完成任务后验证。 但是我执行下来 Opus 5 不如 GPT 5.6 Sol 稳定，也不如 GPT 5.6 Token 耐用，所以宁愿麻烦一点。