热闹而昂贵的一次技术秀：数百个AI代理上阵，七天，生成了超过100万行代码、1000个文件，投入估算达300万—500万美元，结果却是浏览器“跑不起来”、组件烂尾、错误与警告满天飞。
目标看似简单：让代理们从零实现HTML解析器、CSS解析器和渲染引擎。最初策略是完全自治并行：每个代理自由抢活，期望“人多活快”。现实证明，AI的并行不是人的并行。
现场暴露的矛盾很直接：文件锁冲突导致频繁阻塞，多个代理反复改同一份代码；任务拆分不清产生大量重复劳动；复杂或模糊的任务被回避，关键模块无人收尾，系统始终缺乏全局一致性。
为此团队引入分层任务管理：计划者拆解并派工，工作者执行，评审者打分验收。这一变阵减少了部分冗余，但无法消灭架构上的分裂与接口不兼容，代码体量虽大，质量仍然不达标。
进一步核验发现，所谓“从零实现”带有明显的拼装痕迹：项目大量依赖现有开源库（如Servo、QuickJS），真正的原创核心极少。更糟的是，代理在粘合与适配环节同样频繁出错。
归纳失败原因，可归为三道硬墙：协作硬墙——锁与版本冲突；任务硬墙——没有统一蓝图与边界；质量硬墙——缺乏系统级架构与接口契约，局部能跑，系统不可用。
展开剩余45%成本与规模的教训更刺眼：几百万美元换来的是代码量爆炸而非功能达标。当参与者规模放大，错误、不一致与技术债呈指数增长，算力并不能替代工程设计。
这件事与你有关。给团队、开发者和学生三条提醒：别把代码行数当KPI；AI不是自动驾驶的工程师，缺少总体设计的多人代理更易失效；遇到“从零”“军团”宣传，先问接口、标准与集成方案。
可行路径很明确：把AI当助手而非军团。让AI承担脚手架生成、单元测试补全、代码审查初筛和文档同步等“小而精”任务；同时实行单一代码所有权、严格合并队列与持续集成红线，由资深架构师掌舵全局。
技术上要迈出的下一步包括：真正可用的协作协议（共识与锁管理）、持久化的共享记忆与工件驱动接力，以及把自动化验收测试写进评审机制，让“能跑”与“合规”同时成为可量化的门槛。
结语设问：若有一位总导演负责蓝图与边界，这个浏览器会不会跑起来？答案并非技术的简单重启，而是工程治理的重构。下一篇我们将把一个小型真实项目交给少量受限代理，看看实战能走多远。
