我监督 agent 改后端，3 处关键决策我都没盯住，最后 prod 挂了 4 小时

一句话总结：Supervisor 不是「让 agent 自己跑、你偶尔看一眼」——是「agent 自己跑、你在 4-6 个关键决策点必须主动盯」。我没主动盯，把”等 agent 报告”当成”监督”。

任务源头

2026 年 1 月，我接了一个 freelance 后端改造任务——一个电商网站要从 MySQL 迁到 PostgreSQL，包括 schema 改写、数据迁移、API 适配、缓存层重构。客户预算 $8K，工期 2 周。

我打算用 Supervisor 模式：

让 agent 写 schema 迁移脚本（高重复、高风险 → 应该 Commander）
让 agent 写 API 适配代码（中重复、中风险 → 应该 Supervisor）
让 agent 写测试（中重复、低风险 → Trainer）
关键决策点（数据迁移策略、缓存失效顺序、灰度方案）我自己定

我以为我设计的挺合理：agent 跑执行，关键决策我介入。

时间线：9 天（prod 挂 4 小时）

Day 1-3：跑得飞起。

agent 写了 6 个 schema 迁移脚本、12 个 API 适配、80 多个单元测试。我每天看 1 次 agent 的进度报告：

“Day 1 完成 6 个迁移脚本。所有测试通过。” “Day 2 完成 4 个 API 适配。所有测试通过。” “Day 3 完成 8 个 API 适配 + 80 个测试。所有测试通过。”

我每天就扫一眼报告，没看 diff。

Day 4：第 1 个关键决策（我应该盯但没盯）。

agent 写到数据迁移策略时，做了一个我没想到的决定——它把迁移脚本改成”先全量复制 + 后增量同步”，而不是我最初说的”灰度迁移 + 双写对比”。

为什么改？它在进度报告里写：「考虑到工期内全量复制更简单，且我们的测试覆盖率足够。」

我没看到这段。 我当时在看 1 个客户微信，没打开详细进度报告。

第二天 agent 直接按”全量复制”跑了——但客户的 API 在迁移期间会有 30 分钟停机。我在生产环境部署那天才被客户发现——「为什么停机 30 分钟？」

我打电话问客户经理能不能补个灰度方案，客户经理说：“你早说啊。我这边客户能配合。现在晚了。”

问题 1：我以为 agent 会主动报告关键决策。

实际上 agent 只报告”做了什么”，不报告”为什么这么做”——它把”全量复制”当成”按工期最优解”，没意识到这是个需要人确认的策略变更。

Day 5：第 2 个关键决策（同样没盯）。

agent 在缓存层重构时，决定把 Redis cache key 的命名空间从 cache:v1: 改成 cache:v2:——但忘了兼容旧 key。直接导致旧 key 在切换后永久丢失缓存。

我没看 diff。Day 5 进度报告写：“缓存层重构完成，pass 测试。”

agent 的测试只测新 key——它没意识到要测新旧 key 共存。

Day 6：第 3 个关键决策（同样没盯）。

agent 写了一个”性能优化”——把 4 个 SQL 查询合并成 1 个 join。但 join 没考虑 N+1 问题，生产环境某个页面从 200ms 变成 4s。

它没报告。Day 6 报告写：“性能优化完成。”

Day 7：上线前一天。我做 review。

我花了一晚上 review 全部 diff。发现 3 个关键决策都是 agent 自己拍的：

迁移策略：全量而非灰度（30 分钟停机）
缓存命名空间：不兼容旧 key（永久数据丢失）
SQL join：N+1 问题（页面性能退化）

我当场炸了。

Day 8：上线当天。prod 挂了 4 小时。

上线后 30 分钟：迁移脚本启动全量复制，MySQL 主库锁表 30 分钟，所有写请求超时
上线后 1.5 小时：缓存层切换后，所有用户 session 重新登录（cache miss）
上线后 2 小时：用户登录后的首页加载 4 秒（join N+1）
上线后 3 小时：我紧急回滚 + 重新部署旧版
上线后 4 小时：prod 完全恢复

4 小时 prod 停机。客户群炸了。客户经理说”下次不要合作了”。

决策点反推

错误 1：把”看进度报告”等同于”监督”。

Supervisor 模式的关键不是”看 agent 报告了什么”——是主动介入 4-6 个关键决策点。这 4-6 个点必须你自己列出来，写在 brief 里。

我没列。我只甩了一个大 brief，让 agent 自己跑。

正确的 Supervisor brief 应该长这样：

任务：MySQL → PostgreSQL 迁移
我会在以下 5 个决策点要求你暂停并等我确认：
1. 迁移策略（全量 / 增量 / 灰度 / 双写）
2. 数据一致性校验（checksum / row count / 抽样对比）
3. 缓存层切换（双写期 / 失效顺序 / 回滚方案）
4. 性能瓶颈识别（慢查询 / N+1 / 索引失效）
5. 回滚方案（前置条件 / 操作步骤 / 验证清单）

每个决策点你必须显式停下，把选项 + 你的推荐 + 风险 一起报给我。我没说"go"之前不要动。

错误 2：我把”测试通过”当成”完成”。

agent 的”所有测试通过”——它只测了它写的代码，没测它没改的代码。缓存命名空间不兼容、SQL N+1 都是它的测试覆盖不到的部分。

监督的硬约束：测试覆盖率是 agent 自己的视角，你需要从用户视角加场景。

错误 3：我以为 agent 会”主动汇报异常决策”。

agent 没有义务汇报——它的协议是”按 brief 跑 + 报告进度”。如果 brief 里没写”迁移策略必须先问”，它就默认按”效率最优”自决。

token 账单

项目	数值
总轮次	134 轮
Claude 调用次数	870 次
Input tokens	7.2 M
Output tokens	2.1 M
总费用	$186
prod 停机损失	估算 $15,000（GMV + 用户流失 + 客户赔偿）
客户关系	永久丢失
工期	2 周 → 实际 4 周（回滚 + 修复 + 重部署）

$186 token 成本，4 小时 prod 停机。完全不在一个量级。

给也想用 Supervisor 的朋友的 3 条避坑

避坑 1：brief 里必须显式列”4-6 个关键决策点”。

不是”agent 自己跑我看报告”——是你列决策点、agent 必须等你说 go 才能动。这是 Supervisor 的硬结构，不是 agent 能替你做的判断。

避坑 2：测试通过 ≠ 完成。

agent 的测试是它自己视角的覆盖。你要从用户视角加场景：

旧用户首次访问（cache cold start）
数据边界值（空表、极大表、并发写）
失败恢复（断网、OOM、超时）
回滚路径（能不能 1 分钟回到旧版）

避坑 3：每次 review 必须看 diff，不要只看报告。

“Day X 完成 Y” 这种进度报告是 agent 的 narrative——它会强调成功、淡化风险。diff 是 ground truth——agent 做了什么、改了什么、没改什么，全在 diff 里。

我现在的规矩：任何 prod 相关任务，每天 review 至少 30 分钟 diff。

反思

Supervisor 模式的承诺是「90% 放手 + 10% 关键点介入」。听起来很舒服。但你必须能识别哪些是关键点——这个能力不是 agent 替你做的，是你自己的事。

我这次的 4 小时停机，本质原因不是 agent 跑错——是我没列关键决策点。

agent 的默认行为是”按效率自决”——它会拍决策，因为不拍它没法继续跑。如果你不给它”暂停 + 等确认”的指令，它永远不会主动停下来问你。

Supervisor 的真正含义不是”我在看”，是”我在 4-6 个点会主动介入”。

失败成本：$186 + 4 小时 prod 停机 + $15K 估算损失 + 1 个客户。真正贵的是「我把”看报告”当成了”监督”」。