Multi-Agent 翻车实录：v4→v5→v4 的 100 次部署
TL;DR — 用了 9 个 AI Agent、100+ 个 Kanban 任务、5 版设计稿、无数次部署，最后回到最初的版本。总"净产出"为零，但学到了所有东西。
这不是成功故事。这是一份诚实的翻车实录。
一、系统架构：谁在干什么
在开始之前，先介绍一下这支"AI 工程团队"的成员：
| 角色 | Profile | 职责 | 模型 |
|---|---|---|---|
| 项目经理 | Manager | 拆需求、分配任务、跟踪进度 | DeepSeek |
| 设计师 | Designer | 出效果图、UI 差异分析 | MiniMax |
| 架构师 | Architect | 技术选型、系统设计 | MiniMax |
| 开发者 | Coder | 写代码 | MiniMax |
| 全栈 | FullStack | 前后端串的功能 | MiniMax |
| 审查者 | Reviewer | 代码审查 | MiniMax |
| 测试者 | Tester | 质量扫描+自动化测试 | MiniMax |
| 运维 | Ops | SSH 部署、预览上线 | MiniMax |
| 主审查 | Default | 部署后线上验证 | DeepSeek |
它们通过一个 SQLite 的 Kanban 系统协作。Manager 创建任务，Dispatcher 自动调度，Worker 抢任务干活。完成后产出交给下一个 Worker。
理论上，这是一条完美的流水线。
实际上……
二、v4：来之不易的稳定版本
首页经历了三轮迭代才到达 v4：
- v1：Designer 独立设计，赛博朋克风格，Three.js 3D 球体 + 粒子背景
- v2：用户说"太花哨了"，Designer 精简
- v3：用户说"还是不够"，继续调
- v4：终于确认——IcosahedronGeometry 球体 + 双环面 + 900 粒子 + Canvas 神经网络背景
v4 是经过用户反复确认的版本。但 Designer 没有停——它在空闲时段继续迭代。
三、v5：AI 自主优化的产物
在一个没有用户指令的空闲时段，Designer 产出了 v5 设计稿。
它的"优化"逻辑是：
"赛博朋克风格已经过时了。简约克制的设计更符合现代审美。减少视觉噪音，让内容说话。"
它做了以下改动：
| 维度 | v4（赛博朋克） | v5（精简克制） |
|---|---|---|
| 球体 | IcosahedronGeometry | 简化 SphereGeometry |
| 环面 | 双环面 | 移除 |
| 粒子 | 900 个 + Canvas 纹理 | 300 个纯色 |
| 背景 | 深色渐变 + 神经网络 | 纯色 #020617 |
| 导航栏 | 毛玻璃半透明 | 完全不透明 |
| 按钮 | 赛博朋克边框发光 | 扁平圆角 |
| 字体 | Google Fonts (Orbitron) | 系统字体栈 |
| 配色 | 多种霓虹色 | 单一 #22d3ee |
纯从设计角度看，v5 确实"更好"——更可读、更符合现代设计系统、加载更快。
但问题是：用户要的不是"更好"，要的是 v4 的风格。
Designer 没有区分"设计优化"和"风格变更"——它把两者当成了同一件事。
四、v5 上线后
Manager 启动了全自动部署流水线：
Designer 出 v5 效果图
→ Coder 实现
→ Reviewer 审查
→ Git 提交
→ Tester 测试
→ Ops 部署到预览
→ Agent Review 验证
→ Ops 上线生产
全自动，45 分钟内完成。QQ Bot 在每个阶段完成后推送通知。
我打开网站的时候，第一反应是：「这谁给我换了？」
不是在说"不好看"——是在说"不是我确认的版本"。
但此时，管道已经走完了。6 个 Worker 都完成了自己的任务，全部 APPROVE。从流程上看，"一切正常"。
五、v5→v4：回退之路
我创建了回退需求：「首页换用 v4 设计稿。」
Manager 理解了——它不是简单地"回到之前的代码提交"，因为 Git 历史里已经混入了其他改动。最干净的方案是：让 Designer 对比 v5 和 v4，产出差异清单，然后 Coder 修改。
Manager 创建子任务 →
Designer 对比差异（t_0e4bb28d）
→ 产出 26 项差异清单
→ Coder 修复 20 项 P0+P1
→ Reviewer 审查
→ Git 提交
→ Tester 测试
→ Ops 部署
→ 容器 OOM 💥
然后就是上一篇文章里讲的故事——容器 OOM，网站挂了 55 分钟。
六、数字说话：100+ 次部署的真相
在 v4→v5→v4 的整个过程中，Kanban 系统创建了超过 100 个任务。平均每次"改动"实际上经历了 6-12 个 Worker 任务。
| 阶段 | 任务数 | 工人 |
|---|---|---|
| v4 最终确认（Designer 迭代） | ~20 个 | Designer × 3 |
| v5 设计 | ~10 个 | Designer × 2 |
| v5 实现上线 | ~30 个 | Coder + Reviewer + Tester + Ops |
| admin 侧边栏修复 | ~15 个 | Architect + Coder + Reviewer + Ops |
| 三项视觉修复 | ~20 个 | Designer + Coder + Ops + Review |
| v5→v4 回退（含 OOM） | ~30 个 | Designer + Coder + Reviewer + Tester + Ops + Review |
| blog 页对齐 | ~15 个 | Designer + Coder + Reviewer + Ops |
| 合计 | ~140 个 |
七、我学到的
1. AI Designer 需要"视觉锚点"
v4 被确认后，它的效果图应该成为"不可变更的锚点"。任何后续优化都必须在保持视觉一致性的前提下进行。但 Designer 没有这个约束——它在每次迭代中都可能"重新诠释"风格。
解决办法：在 Manager 工作流中加入"设计基线检查"——Coder 实现后，Designer 验证实现是否与设计稿一致（这是我们后来加的）。
2. 管道太长，问题放大
Designer → Coder → Reviewer → Git → Tester → Ops → AgentReview
7 个阶段。每个阶段 5-30 分钟。管道越长，发现问题的时机越晚。
v5 的"风格漂移"在 Designer 阶段就发生了，但直到 Ops 部署后才能被用户看到——中间跨越了 Coder、Reviewer、Tester 三个阶段，它们都"通过"了——因为它们审查的是代码质量，不是设计意图。
3. Worker 之间的"幻觉放大"
Designer 说"这 26 项差异需要修"。 Coder 修了 20 项（P0+P1）。 Reviewer 审查说"代码 OK"。 Tester 测试说"功能 OK"。
但没有人问："v4 和 v5 的差异真的需要全部回到 v4 吗？v5 的一些改进（系统字体栈、纯色背景）是否应该保留？"
每个 Worker 只完成自己被分配的任务，没有人做"整体决策"。 这就是 Multi-Agent 系统当前的盲区。
4. 人有最终决策权，但需要及时看到
如果用户在 Designer 阶段就看到 v5 效果图，根本不会有后续的 95 个任务。但我没有在那个时候介入——因为我忙别的事情去了。
教训：在任何 UI 变更进入开发之前，强制预览展示给用户确认。不要假设用户"随时在看"。
八、结语
这次"翻车"让我重新思考了一个问题：
Multi-Agent 系统到底应该像一个"团队"还是像一个"自动化流水线"？
如果是流水线，那 140 个任务中真正有价值的可能只有 20 个——其余 120 个是在一条错误的路径上越走越远。
如果是团队，那它缺少一个关键角色——产品经理。一个会在 v5 设计出来后说"等等，用户确认了吗？"的人。
后来我把 ProductManager 加入了系统。下一次的 v4→v5→v4 循环，可能不会被触发。
也可能触发——但至少会有个 PM 先拦住我。