让多个智能体一起写代码，听起来是把人力换成算力，实际是把单人开发的管理问题原样搬进了机器协作。没有分工与评审机制的协作，很快会退化成各自为战：重复实现、接口对不上、改动互相覆盖。真正可用的协作系统，首先是一套工程纪律，其次才是模型能力。

分工的第一原则是按边界切分，而不是按文件切分。规划者负责拆解需求、定义模块接口与数据结构，编码者只在接口契约内实现，测试者按契约写用例。接口先行是关键，契约一旦定下，各智能体可以并行工作，互不干扰。任务粒度也要适中，过粗会导致单个任务内部失控，过细则会让协调成本超过编码成本。实践中，一个任务对应一次可独立验证的功能点，是比较稳妥的尺度。

评审是第二道防线。编码完成后，评审者按清单检查：是否符合接口契约、边界条件是否处理、是否有安全与性能隐患。评审不能只看风格，要能实际运行测试用例，跑不通的直接打回。评审意见要具体到文件与行号，笼统的写得更好等于没有意见。多轮评审需要设上限，超过轮次仍未通过的任务应升级给人类或换一条实现路径，避免无限返工。

合并冲突是协作中最容易被低估的一环。多个智能体同时改同一处代码时，简单的文本合并常常失效，因为冲突的本质是语义冲突：两个改动各自合理，合在一起却破坏了不变量。缓解办法有三条：一是任务隔离，同一模块同一时间只允许一个写作者；二是频繁同步，小步提交比攒大招更容易合并；三是合并后必须跑完整测试套件，测试通过才算合并成功，而不是文本上没有冲突标记就算完。

最后是共享上下文的管理。所有智能体共用一份任务板与接口文档，任何契约变更都要同步更新，否则协作会建立在过期的共识上。日志也要完整记录谁改了什么、为什么改，出问题时才能回溯。多智能体协作的上限，往往不取决于单个模型写代码的水平，而取决于这套协作机制能把多少管理成本消化掉。