如何使用 Fable 编排包含 40 个子 Agent 的大型项目

上周在 @HelloUntangle，我们完成了公司历史上规模最大、风险最高的工程计划。

• 834 个文件
• 生产数据变更
• 数据库 schema 更新
• 31 个 PR
• 从周五开始 -> 周一完成
• 零生产事故

所有这一切，仅靠一个 Fable 主编排器会话完成。

一个 @DevinAI 主会话负责规划工作，生成了四十个子会话执行任务，在阶段之间强制执行回归检查与备份验证，并且只将真正需要负责人决策的问题上报：范围裁定以及不可逆步骤的继续/终止决策。

这套方案之所以成功，关键在于一套项目管理模式，任何大型迁移项目都能从中受益。

以下是我们的具体做法……

架构：一个编排器，多个执行器

• 一个主会话 全权负责整个计划。它的唯一任务是规划、生成子会话、审查子会话输出、安排阶段顺序，并在需要人工决策时上报给我。它没有编写任何代码。
• 约 40 个子会话 负责所有实际工作：第 0 阶段的 11 个并行审计会话、每个阶段的执行会话，以及专门负责运行回归测试的独立门控会话。

这种分工之所以重要，是因为长期项目（无论是 AI 还是人类）的失败模式通常是上下文崩塌：执行工作的主体会逐渐丧失对整体计划的把握。

让主会话保持纯粹的编排角色，可以确保其上下文的清晰性；它掌握着计划、范围决策以及每个阶段的状态。每个子会话则获得一个全新且聚焦的上下文，只负责一项任务。

七个关键模式

1. 先审计，并将结果固化在单一清单中

第 0 阶段包含 11 个并行的审计会话，每个会话覆盖代码库的一个切片：应用路由、API 路由和定时任务、数据库 schema、共享库和工作流、脚本和文档。它们的发现被整合到一个文件中，并提交到代码仓库。

该清单为每个代码单元分配了判定结果和阶段编号。两个规则使其强大：

• 执行者不得重新讨论范围。 每个执行提示都明确说明：清单是唯一的事实来源。如果没有这一点，40 个会话都会自行推导出各自的范围意见——结果必然不一致。
• UNKNOWN 意味着停下来询问。* 审计未涉及的任何内容都被明确标记为未知，并附带指令：不要猜测；获取裁定。* 负责人的裁定直接记录到清单中，以便后续会话继承。

2. 按风险排序，而非按便利性

各阶段按照从最安全到最不可逆的顺序排列。

阶段

内容

风险

0

审计 + 清单 + 恢复点 git 标签

无

1

已验证无实时依赖的变更

接近零

2

共享基础设施的依赖关系调整

中等

3–4

大部分代码变更

中等

5

生产数据变更（含预演清单 + 快照）

高

6

Schema 迁移

高

7

依赖清理、agents.md 重写、Agent 知识库审计

低

生产数据变更（阶段 5）在 schema 变更（阶段 6）之前进行，而这两者都只有在所有涉及受影响表的代码路径都经过可验证的更新之后才会执行。到迁移运行时，已经没有代码再依赖旧状态了。

3. 文件不重叠的边界确保并行安全

在同一个阶段内，子会话并行运行——其中一个阶段有四个会话同时处理代码树的不同部分。规则是：每个提示都包含明确的文件边界，且这些边界互不重叠。没有合并冲突，没有两个 Agent 编辑同一个文件，子会话之间完全不需要协调。

这是经典的任务分解——与将工作分配给不同工程师的做法相同——但 Agent 需要在每次提示中明确声明这一点。

4. 阶段之间的安全门控

每个阶段必须在前一阶段通过门控后才能启动。门控本身也是子会话：

• 一套基于浏览器的端到端回归测试，覆盖平台的核心客户工作流，在阶段 2 之后以及阶段 3–4 之后各运行一次，使用一个全新的独立数据库分支。
• 在进行任何生产数据变更之前：一个专门的会话审计了我们的数据库备份清单（数量、日期范围、保留策略），并创建了一个新的时间点快照。
• 生产步骤本身先执行预演，生成行数供负责人批准，并在执行后重新验证行数。
• 每个变更行的恢复点都通过 git 标签标记。

当门控失败时，会生成一个范围明确的修复会话。例如，回归测试发现一个客户面向的流程因一次过于激进的变更而中断；一个修复会话在数小时内恢复了它。这正是系统在发挥作用——门控将原本可能由客户报告的 bug 转化为当日修复。

5. 人类批准；Agent 提议

在这个项目中，我从未编写代码、运行迁移或执行生产脚本。但每一个不可逆的步骤都需要我明确批准：每次合并到主分支、生产数据变更、schema 迁移，以及每个 UNKNOWN 范围项的裁定。

破坏性工作的模式是：Agent 提出清单，人类批准清单，然后 Agent 精确执行该清单。 生产会话在接触任何数据之前，生成了它将影响的精确行列表。我批准的是一个具体的列表，而非一个模糊的意图。

6. 应对意外的升级协议

子会话被告知，当实际情况与清单不符时该怎么做：停止、向主会话报告、不要自行发挥。实际案例：

• 一个审计认为安全的模块，实际上在其他地方有实时依赖 → 子会话标记了它，该单元被降级到后续阶段，并记录了依赖关系。
• 第二轮审计推翻了第一轮对五个完整区域的判定 → 这些推翻被明确写入清单作为覆盖，而不是由遇到它们的会话临时解决。

主会话将这些意外情况吸收到计划中。单个执行者从不做范围决策。

7. 让营地更整洁：教会系统发生了什么变化

阶段 7 可能是最被低估的阶段。变更上线后，会话重写了我们的 AGENTS.md、仓库技能和 Agent 知识库，以描述新架构——这样未来的每个 Agent 会话都从真实情况出发，而不是基于过时的指令。如果你的工程是 Agent 驱动的，那么你的文档就是承载关键任务的基础设施。

成本是多少

计划中的每个会话都打了标签，因此账目是完整的：一个主会话和三十九个从会话，全部在 Devin 的 Ultra Agent 上运行，从周五下午到周一上午。以下是我们使用仪表盘中的实际计量成本。

阶段

会话数

成本

主编排器（多天）

1

$115.26

第 0 阶段审计（两轮）+ 清单整合

12

$85.56

阶段 1

4

$37.55

阶段 2（依赖关系调整）

4

$299.34

阶段 2–4 回归门控 + 修复

4

$244.69

阶段 3–4

5

$130.84

阶段 5（生产）+ 备份审计

2

$15.20

阶段 6（Schema 迁移）

3

$118.83

阶段 7（依赖、文档、知识）+ 最终门控

4

$96.64

基础设施修复

1

$11.47

总计

40

$1,155.38

成本分解中有三点值得注意。

1. 整个 12 个会话的审计阶段（产出清单）成本不到 90 美元——这是我们买过的最便宜的保险。
2. 最昂贵的项目正好出现在需要深度思考的地方：依赖关系调整（$299）和确保一切正确的回归门控（$245）。
3. 风险最高的步骤——生产数据变更——成本仅为 15 美元，因为到它运行时，所有风险都已经被设计消除了。

注意：如果 Devin 允许我为子 Agent 选择不同的模型，整个项目本可以便宜得多。大部分编码工作使用 gpt 5.5 或 opus 4.8 就能成功完成。指示 Fable 根据子 Agent 任务选择合适的模型是很容易的。

即使没有这一点：对于我们完成的工作来说，1000 美元已经便宜得令人难以置信——而且完成和验证的速度——哇。

https://x.com/ryancarson/status/2072694425365426344

要点

重点不在于 AI 编写了大量代码——Agent 执行明确指定的变更现在已是基本要求。

重点在于：项目管理本身也被委派了：分解、排序、并行化、门控和升级都在编排器内部运行，人类的角色被压缩到恰好需要负责人的决策。

如果你想尝试这种方法，请借鉴这些模式，而不是工具：

1. 先审计；将结果冻结在清单中，任何执行者不得重新讨论。
2. 按风险排序阶段；不可逆的步骤放在最后。
3. 为并行执行者提供明确不重叠的文件边界。
4. 用真正的回归测试和真正的备份为每个阶段设置门控。
5. 在破坏性变更之前要求提出清单；批准列表，而非想法。
6. 在意外出现之前定义好升级路径。
7. 将更新文档和 Agent 知识作为项目的一部分，而非事后工作。

祝编排愉快！:)