父 orchestrator + 40 子会话编排：零事故完成834文件生产级迁移的7个模式

上周完成了一次公司历史上最大、最具风险的工程变更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 负责吸收所有 surprisesworker 从不做范围决策。离开时把营地打扫得更干净Wave 7 是最被低估的一步变更上线后专门的子会话重新编写了 AGENTS.md、repo skills 和 agent 知识库把新架构真实情况记录下来。未来任何代理启动时都从最新真相开始而不是陈旧指令。这对 agent-driven 的工程团队来说文档就是基础设施。成本拆解与真实感整个项目1 个 parent 39 个 child总成本约 1000 美元11 个并行审计阶段只花了不到 90 美元最划算的保险最贵的反而是纠缠手术299 美元和回归 gates245 美元——这些正是把风险工程化出去的关键投入最高风险的生产数据变更阶段只花了 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和系统实验。感兴趣可以关注我们下期见。