一、三次合并冲突之后，我决定让Agent学会“排队”
上个月用 Grok 4.3 并行开发一个微服务项目，三个模块——用户中心、订单引擎、支付网关——同时开工。三个 Agent 各自写各自的代码，第一天效率确实猛，半天干完了以前三天的活。第二天合并代码时噩梦开始了：三个模块的接口定义不一致，两个 Agent 各自实现了一套工具函数，Git 冲突标记满屏都是。
问题不是 Agent 写得不对，是它们各写各的，没人协调。人类开发团队有技术负责人做这事——定义公共接口、审查代码冲突、合并时拍板。Agent 团队也需要一个“技术负责人”。
在 大模型（01gpt.cn） 上接好 Grok 4.3 之后，花了两周搭了一套子Agent调度系统。一个主Agent负责拆任务、派活、合并代码，多个子Agent只管写自己那摊代码。再跑同样的多模块项目，合并时从十几个冲突降到一两个，而且都是容易解决的格式冲突。
二、调度架构：主Agent不写代码，只管“管人”
核心设计原则只有一条——主Agent不写任何业务代码。它只做四件事：任务拆解与排序、子Agent调度与监控、公共契约维护、代码合并与冲突仲裁。
子Agent的职责也很明确——只写自己模块的代码，不关心其他模块在干什么，不修改公共契约，不直接和其他子Agent通信。所有协调通过主Agent中转头。
三、公共契约：并行开发的地基
多Agent并行的前提是公共部分先定好——接口定义、数据模型、依赖版本、公共工具函数。这些是所有Agent都会用到的基础设施。
具体做法：主Agent先生成公共契约文件，包含跨模块接口的完整签名、统一的数据模型定义、第三方依赖的精确版本号、公共工具函数的声明和约束。公共契约人工审核通过后冻结，所有子Agent启动时先读取这份契约，开发过程中只能读不能改。如果确实需要改接口，由开发者先更新公共契约，再通知所有子Agent同步。
四、任务分配与并行策略
主Agent按模块边界拆分任务，不按功能边界拆分。每个子Agent分配独立的模块目录，Agent之间不交叉修改对方的文件。
哪些任务可以并行、哪些必须串行，主Agent根据依赖关系自动判断。有数据依赖的模块串行执行——订单模块依赖用户模块的接口定义，必须等用户模块完成后再启动。无依赖的模块并行执行——用户模块和支付模块独立，可以同时开工。
五、代码合并：分阶段合并与冲突仲裁
代码合并是整套系统最核心的环节。主Agent采用分阶段合并策略。
开发阶段每完成一个子任务，子Agent提交代码变更并附带变更说明。主Agent实时检查是否与公共契约冲突，有冲突立即通知子Agent修正。集成阶段所有子任务完成后，主Agent按依赖顺序逐个合并模块代码。每合并一个模块跑一次冒烟测试，确认无回归再合并下一个。仲裁阶段主Agent检查代码重复、接口冲突、风格不一致，自动解决格式类冲突，逻辑类冲突标记出来交人工裁决。
冲突分级处理： 格式类冲突（缩进、命名风格、注释格式）主Agent自动解决。接口类冲突（两个Agent修改了同一个接口签名）主Agent回退后提交的修改，通知开发者更新公共契约后重新分配。逻辑类冲突（两个Agent实现了相同功能但逻辑不同）标记出来交人工裁决，主Agent只做检测不做决策。
六、一个实际案例的完整流转
以用户、订单、支付三个模块的并行开发为例。主Agent先生成公共契约——用户和订单的接口定义、数据模型、公共工具函数。冻结后启动三个子Agent并行开发。订单Agent实现过程中发现需要用户模块的扩展字段，向主Agent申请修改接口。主Agent检查后拒绝——公共契约已冻结，扩展字段放入二期迭代。各模块开发完成后主Agent按依赖顺序合并——先用户模块、再订单模块、最后支付模块。每合并一个跑测试验证。合并过程中检测到订单和支付模块各自实现了一个金额格式化函数，主Agent自动抽取到公共工具库，移除两个模块的重复代码。
数据： 三个模块约1200行代码，合并时产生2个冲突——1个格式冲突自动解决，1个接口冲突因订单Agent引用了旧版接口定义，主Agent检测到后回退并通知修正。总耗时约3.5小时，纯人工开发预估2天。
七、这套模式的三个关键价值
冲突前置发现。 传统开发是各自写完再合并，冲突在最后爆发。主Agent实时检查变更是否与公共契约冲突，冲突在开发阶段就被发现和修正，不会累积到最后。
合并成本大幅降低。 合并时主Agent已自动处理了格式类冲突，逻辑类冲突也提前标注了原因和影响范围。人工只需处理真正的逻辑决策，不用在大量格式冲突里找逻辑问题。
公共契约是唯一真相源。 所有Agent基于同一份契约开发，不会出现“我以为你用v1.0，其实你用了v2.0”这种版本错位。契约版本号统一管理，变更历史可追溯。
八、不适合这套模式的场景
简单项目单Agent全包更快。主Agent的调度和合并本身有额外开销，三个模块以下的项目这个开销占比太高。高时效性任务并行效率更高。如果每个模块都需要快速迭代，主Agent的串行合并流程可能成为瓶颈，需要引入更细粒度的合并策略。创意型项目规范约束可能限制灵活性。公共契约为了一致性牺牲了部分灵活性，如果项目需求频繁变化且不确定性高，单Agent全包加人工审查更灵活。
九、总结
多Agent并行开发的核心瓶颈不是单个Agent的能力，是Agent之间的协调。人类团队靠技术负责人和Code Review解决这个问题，Agent团队靠主Agent调度和公共契约。主Agent不写代码，只管“管人”——定规则、派活、查冲突、做合并。这套分工机制让子Agent的并行效率真正释放出来，合并时不会再有满屏的冲突标记。
