Fable 回归了，这是我在 Cursor 中使用它的方法

Fable 已经在 Cursor 中回归，下面是我正在探索的一种模式，以及我从这个模型中获取最大收益的其他一些方法。

Fable 作为编排器，Composer 作为工作者

把所有任务都丢给一个智能模型很容易。但大部分 agent 的运行过程都是读取文件、写入补丁和运行检查，这些并不需要 Fable 的开销。相反，让 Fable 决定子任务、执行顺序以及结果是否完成。Composer 2.5 处理那些范围明确的部分，更便宜、更快，并且可以并行运行。我的大多数聊天都是简短的 Composer 运行。Fable 出现得较少，但每次运行的时间会更长。

你可以将路由规则放入 AGENTS.md 或 .cursor/rules 文件中，这样编排器 agent 就能使用它。

用 Fable 来进行规划和协调。对于任何可以限定为清晰子任务的事情，启动一个 Composer 2.5 子 agent。

给每个子 agent 一个明确的目标、相关的上下文以及需要带回的内容。不要让它们自己发明计划。并行运行相互独立的子任务。

当它们返回时，在合并任何内容之前先审查结果。如果有什么不对的地方，重写指令并重新启动一个子 agent，不要自己默默地修补，除非问题很小。

一个好的指令应该包含：

• 一个关注点

• 足够的上下文，使工作者无需重新探索整个仓库

• 一个它可以自行检查的完成定义

• 一份简短的报告，以便编排器快速做出决策

当判断本身才是核心工作时，单独使用 Fable 仍然有意义——无论是困难的设计决策、需要连贯思路的棘手 bug，还是必须保持耦合的计划。如果你无法命名子任务，那就保持一个 agent 执行！

长期运行的云端 agent

我最常使用的场景是在云端 Agent 上执行超长期的任务。一个大型重构、一个涉及多个界面且有明确完成定义的功能、或者跨越大型代码库的调查。我会把它交给 Fable，给它一个可以自行验证的标准，然后让它运行。我会从 iOS 应用中查看状态，看看它在做什么，如果偏离方向就稍微提醒一下。

跟上前沿

如果你只运行一个模型，你很容易将其习惯误认为是 agent 能力的上限。此外，前沿技术每几周就会更新一次。轮换使用不同模型是我保持对“什么才叫好”有现实认知的方式——基于真实工作，而不是基准测试。