一、从“一个人扛”到“一个团队”
上个月给公司内部工具加一个用户积分兑换功能。需求很简单——用户能用积分兑换优惠券，但要考虑并发扣减、过期回收、兑换记录追溯。按以前的开发流程，我需要自己拆需求、写代码、写测试、做审查，一个人扛全流程，至少好几天。
这次换了个思路：用 ChatGPT5.5 模拟一个完整的开发团队——一个 Agent 当 PM 拆需求，一个 Agent 当 Dev 写代码，一个 Agent 当 QA 写测试和审查。我当技术经理，只负责拍板关键决策。结果一天半就交付了，代码质量反而比单 Agent 全包高出一截。在 大模型（01gpt.cn） 上反复调教这套多 Agent 协作框架之后，以下是完整的架构设计和落地经验。
二、为什么单 Agent 不够用
单 Agent 模式下，一个模型要同时扮演需求分析、代码生成、测试审查三个角色。问题不在于能力不够，而在于“注意力盲区”——同一个 Agent 写的代码，让它自己审查，它很难发现自己逻辑上的漏洞。就像一个人很难给自己的文章挑错别字一样。更致命的是，单 Agent 缺乏“质疑”机制。PM 拆出来的需求，Dev 应该能反问“这个边界条件你没考虑到”；QA 写的测试，Dev 应该能指出“这个测试覆盖不全”。这种建设性冲突是团队协作的核心价值，但单 Agent 模式下完全缺失。
三、整体架构：层级调度 + 角色隔离
多 Agent 系统采用层级调度模式：设一个主 Agent 作为单一调度入口，多个子 Agent 各司其职，子 Agent 之间不直接通信，所有信息通过主 Agent 的结构化消息体中转。
角色承担模型核心职责禁止行为
主调度 AgentChatGPT5.5需求拆解、任务分配、依赖排序、结果验收不写代码，不审代码
PM AgentChatGPT5.5需求结构化、边界澄清、验收标准定义不写代码
Dev AgentChatGPT5.5代码生成、Bug 修复不设计架构，不修改接口
QA AgentClaude 4.8安全审计、测试用例、代码审查不写代码，不修改代码
关键设计： PM Agent 产出的需求规格必须是结构化的——每个功能点附带验收标准、边界条件和异常场景。Dev Agent 只能基于这份规格写代码，不能擅自修改接口定义。QA Agent 的审查结果必须区分“阻塞项”和“建议项”，只有安全漏洞可以一票否决，风格问题只是建议。
四、协作流程：一个需求的完整流转
以用户积分兑换功能为例，整个流程自动拆解为四个阶段。
第一阶段：需求分析。 PM Agent 把一句话需求“用户能用积分兑换优惠券”拆成结构化任务单——积分扣减与并发控制、优惠券发放与库存管理、兑换记录与过期回收、失败回滚与幂等处理。每个子任务标注了优先级、依赖关系和验收标准。它还主动追问了两个边界问题：“积分不够时是提示用户还是自动按最大可兑换处理？”“同一张优惠券用户能否重复兑换？”这些追问在真实开发中往往是 PM 和 Dev 讨论后才会发现的。
第二阶段：代码生成。 主 Agent 按依赖关系把子任务分派给 Dev Agent。Dev Agent 逐个实现，每完成一个附带自测报告——包括正常路径、边界值、异常情况的测试结果。实现积分扣减逻辑时，Dev Agent 主动加了分布式锁和幂等校验，在代码注释里标注了“并发场景下需要 Redis 原子操作防止超兑”。这说明它理解了 PM 需求中的“并发控制”约束，而不是机械地写 CRUD。
第三阶段：测试与审查。 QA Agent（Claude 4.8）拿到 Dev Agent 的代码变更和自测报告，从三个维度做审查。安全审计方面发现了积分扣减的并发竞态窗口——check-then-act 模式在高并发下可能导致积分超扣，同时标注了 CWE 编号和修复建议。测试用例覆盖方面补充了两条边界测试——积分刚好为零、兑换数量超过库存——这些 Dev Agent 的自测报告里都没覆盖。代码风格方面标注了一处变量命名不规范。
第四阶段：修复与验收。 Dev Agent 根据 QA 审查报告修复了竞态窗口——改用 Redis 的 Lua 脚本实现原子扣减，补充了边界测试用例。修复后重新提交审查，QA 确认通过。主 Agent 汇总所有交付物——代码变更、测试报告、审查结论——提交给我验收。整个流程我只在架构方案确认和安全审计结论上做了最终拍板，其他环节全部自动流转。
五、Agent 间通信的三个硬约束
上下文最小化。 Dev Agent 只收到 PM 的结构化需求规格，不接触原始用户需求。QA Agent 只收到 Dev 的代码变更，不接触需求背景。每个 Agent 只在自己的专业领域内做判断，不被无关信息干扰。
门禁不可绕过。 QA Agent 的审查是合入前的硬门禁——只有安全漏洞可以一票否决。PM Agent 的需求规格必须先通过我的确认，Dev Agent 才能开始编码。主 Agent 不会因为“时间紧”跳过任何一步。
冲突仲裁机制。 当 Dev Agent 和 QA Agent 的结论冲突时——比如 Dev 认为某个并发场景在业务上不可能发生，但 QA 标记为风险——安全优先，QA 的结论优先采纳。当 PM Agent 和 Dev Agent 对需求理解不一致时——比如 PM 期望“全量回收过期积分”，但 Dev 发现历史积分数据格式不兼容——重新澄清需求，PM 更新规格后 Dev 重新实现。
六、单 Agent vs 多 Agent 的效果对比
维度单 Agent 全包多 Agent 协作
需求覆盖容易漏边界条件PM 结构化拆解 + 主动追问
代码质量能跑，但安全漏洞易漏Dev 写 + QA 审，安全漏洞接近零
测试完整性只覆盖正常路径QA 补充边界和异常场景
交付周期数天一天半
七、这套框架的适用边界
适合多 Agent 协作的场景： 复杂业务逻辑（涉及并发、事务、多状态流转）、安全敏感模块（支付、权限、认证）、跨模块重构（需要全局依赖分析）。这些场景下单 Agent 的盲区效应最明显。
不适合多 Agent 协作的场景： 简单 CRUD、独立工具脚本、原型验证——这些场景用单 Agent 全包更快更省。多 Agent 的额外调度成本在简单任务上不值得。
八、总结
ChatGPT5.5 模拟软件开发团队的核心不是“用更多 Agent 干活”，而是把真实团队的分工和审查机制复刻到 AI 协作中。PM 负责“想清楚做什么”，Dev 负责“做出来”，QA 负责“验证做得对不对”。三个角色互相制约、互相补充，覆盖了单 Agent 天然存在的注意力盲区。
这套框架不一定适合所有项目，但对于复杂度和风险都偏高的生产级需求，多 Agent 协作带来的质量增益远超额外的时间成本。知道什么任务该用多 Agent、什么任务该用单 Agent、门禁设在哪、冲突怎么仲裁——这才是 AI 时代技术管理者最核心的判断力。
