上周，完成了一次公司历史上最大、最具风险的工程变更：834 个文件修改、生产数据变更、数据库 schema 更新、31 个 PR，从周五启动到周一结束，零生产事故。
这一切不是靠一个超级强大的单代理“一次性搞定”，而是靠一个 Fable 父 orchestrator 会话 + 约 40 个 DevinAI 子会话的严格编排完成的。
父会话从不写代码，它只负责全局规划、派生子会话、审查输出、阶段排序，并在真正需要人类决策时把问题升级给我。所有实际编码、审计、回归、数据变更都由专注的子会话完成。
我起初也以为，只要模型够强、上下文够长，把大项目直接扔给一个代理就能跑通。后来看到这个案例才明白：长周期 AI 项目最大的敌人是context collapse—— 执行者逐渐忘记整体目标和边界，开始自行发挥或遗漏关键约束。
把 parent 设计成纯 orchestrator，把 worker 设计成上下文极度干净的执行者，正是解决这个问题的核心。
为什么必须先做全面审计并冻结成单一 manifest
项目第一阶段（Phase 0）启动了 11 个并行审计子会话，分别覆盖路由、API、定时任务、数据库 schema、共享库、脚本和文档。
审计结果被合成并提交为唯一权威的 manifest 文件，每个代码单元都被标记了判决（改/不改）和 wave 编号。
两条铁律让它生效：
- 任何执行子会话都不得重新审议范围，manifest 就是唯一真相来源；
- 审计未覆盖的部分必须明确标记 UNKNOWN，并强制要求“不要猜测，直接升级人类裁决”。
没有这两条，后续 40 个子会话会各自脑补范围，互相冲突。
按风险而非便利性排序 waves
他们把工作拆成多个 wave，从最安全到最不可逆排序：
生产数据变更（Wave 5）必须在 schema 变更（Wave 6）之前完成，而这两者又必须等到所有触碰相关表的代码路径都已被验证修改之后。
这避免了“先改 schema 导致旧代码瞬间失效”的灾难性顺序。
文件边界严格 disjoint 才能真正并行
同一个 wave 内多个子会话可以并行工作，但每个 prompt 都必须显式声明文件边界，且边界完全不重叠。
没有这个纪律，就会出现两个代理同时编辑同一文件、产生合并冲突、互相踩踏的情况。代理不像人类工程师那样天然会“协调”，必须把边界写死在 prompt 里。
在 waves 之间设置真实的安全 gates
没有一个 wave 能直接进入下一个，必须通过 gate 子会话验证：
- 核心用户流程的端到端回归测试（浏览器驱动，在隔离数据库分支上跑）；
- 生产数据变更前，先审计备份库存并做新鲜的 point-in-time snapshot；
- 数据变更本身先 dry-run，产出行数清单，人类批准具体列表后再执行；
- 每次变更都打 git tag 作为回滚点。
Gate 失败时会自动派生 scoped fix 子会话，把潜在 bug 变成当天修复，而不是等到用户报障。
人类只批准，代理只提议
我全程没有写一行代码、没有执行一次迁移脚本。但所有不可逆操作（合并 main、生产数据变更、schema 迁移、UNKNOWN 范围裁决）都必须得到我的明确批准。
模式是：代理先产出精确的“将要修改的清单”，人类批准这份清单，代理再严格按清单执行。不是批准“想法”，而是批准“具体列表”。
为意外准备明确的 escalation 协议
子会话被提前告知：当现实与 manifest 冲突时，立即停止、报告给 parent，不要自行 improvising。
真实案例：
- 一个审计标记为安全的模块后来发现还有外部依赖 → 子会话上报，parent 把该单元降级到更晚的 wave 并记录纠缠关系；
- 第二轮审计推翻了第一轮对五个区域的判决 → 这些推翻被直接写进 manifest 作为 override，而不是让某个子会话临时处理。
parent 负责吸收所有 surprises，worker 从不做范围决策。
离开时把营地打扫得更干净
Wave 7 是最被低估的一步：变更上线后，专门的子会话重新编写了 AGENTS.md、repo skills 和 agent 知识库，把新架构真实情况记录下来。
未来任何代理启动时，都从最新真相开始，而不是陈旧指令。这对 agent-driven 的工程团队来说，文档就是基础设施。
成本拆解与真实感
整个项目（1 个 parent + 39 个 child）总成本约 1000 美元：
- 11 个并行审计阶段只花了不到 90 美元（最划算的保险）；
- 最贵的反而是纠缠手术（299 美元）和回归 gates（245 美元）——这些正是把风险工程化出去的关键投入；
- 最高风险的生产数据变更阶段只花了 15 美元，因为前面所有风险都已经被 gates 消化掉了。
把程序管理本身委托给 orchestrator
这个案例的真正意义不是“AI 写了大量代码”（这已经变成 baseline），而是程序管理本身被代理化了：分解、排序、并行化、门控、升级路径，全都跑在父 orchestrator 内部。
人类角色被压缩到只处理真正需要 owner 的决策：范围裁决和不可逆步骤的 go/no-go。
可直接偷走的 7 个模式
- 先全面审计，把发现冻结成单一 manifest，禁止 worker 重新审议范围；
- 按风险而非便利排序 waves，最不可逆的操作放最后；
- 并行 worker 必须有显式、互不重叠的文件边界；
- 每个 wave 之间必须有真实回归套件 + 备份作为 gate；
- 破坏性变更必须先产出精确清单，人类批准列表而非意图；
- 提前定义 escalation 路径，surprises 必须上报而非现场决策；
- 项目结束时同步更新所有 agent 文档和知识库。
这些模式不依赖具体工具（Fable + Devin），任何想用多代理做大型变更的团队都能直接应用。
大型工程变更的可靠性，从来不是靠“模型更聪明”，而是靠把人类在传统项目管理中积累的纪律，用 prompt 和会话架构显式地固化下来。
当你下次面对一次涉及数百文件、数据变更、schema 更新的迁移时，不妨先问自己：我是否已经设计好了 manifest、waves、gates 和 escalation 协议？
欢迎在评论区分享你目前用 AI 做大型重构时遇到的最大痛点，或者你已经实践过的类似编排模式。我们一起把这些“程序管理代理化”的实践继续打磨得更硬核。
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
