如果你混过几个 AI 开发相关的技术群应该能感受到一个非常明显的反差一方面大家讨论 Agent、工作流、模型能力时热火朝天另一方面把 AI 真正用在一个企业内部系统的开发上却很少有人能说清到底怎么落地。我自己从去年开始一直在做企业应用开发陆续把几套内部系统从传统写代码迁移到“模型驱动 多 SubAgent 协作”的模式上来踩了不少坑也沉淀了一套很稳定的打法。这篇就专门讲这套打法。我会从单个 Agent 为什么撑不住企业级业务讲起然后拆解五个 SubAgent 各自负责什么、相互之间怎么交接再用一个真实系统的完整例子把需求到上线的链路一步步跑给你看最后分享几个我实战中反复踩到的坑和应对方法。适合正在用 AI 辅助开发、但被需求漂移、代码不可控、测试无效这些问题困扰的团队参考也适合刚接触 SubAgent 想找一个落地入口的开发者。1. 为什么一个超级 Agent 跑不动企业应用1.1 单 Agent 模式在企业项目里的三个断层最早我做 AI 辅助开发的时候思路简单粗暴把需求文档丢给一个能力很强的大模型让它直接生成后端工程再让它自己补测试、补部署脚本。跑几个小型 Demo 的时候确实爽尤其是 CRUD 类的接口生成速度比手写快一个量级。但一旦把真实的业务约束加进来问题就接二连三地冒出来。第一个断层是上下文断层。企业应用和玩具项目最大的区别在于业务规则的数量级完全不同。一个中等规模的报修系统会有几十张业务表、几十个接口、复杂的角色权限关系、状态机流转、并发控制、消息通知。单个 Agent 的上下文窗口再大也不可能把完整的业务规则始终装在脑子里。它写着写着就开始“漂移”一开始还记得“工单按优先级排序”写到第五个接口就把排序逻辑扔了甚至为了凑接口把原本的业务约束悄悄改掉。这种漂移在小项目里不明显项目越复杂越致命。第二个断层是验证断层。代码生成出来谁来确认它是对的让同一个 Agent 自己生成代码、自己写测试本质上就是考生自己批自己的卷子。它经常因为测试代码写得太“配合”而发现不了真实业务逻辑的问题尤其是异常路径、并发冲突、跨服务调用这些场景几乎等于裸奔。第三个断层是角色断层。企业应用开发从来不只等于“写代码”。需求的澄清、架构的决策、质量的把控、发布运维的准备每一件事都需要不同的专业视角。单 Agent 看起来什么都会实际上每个环节都只做到“差不多”尤其是让它在“业务分析”和“代码实现”之间来回切换的时候经常给出自相矛盾的结论。我遇到过一次它在前一轮分析里说“员工提交报修后不可撤回”后一轮写代码时却又默认“员工可以随时撤回”而且没有任何解释。1.2 把大模型当编排中枢而不是万能引擎后面我换了一套设计哲学不要再让一个大模型包打天下而是把它当作一个“编排中枢”由它来调度若干专门的 SubAgent每个 SubAgent 只负责某一个开发环节。这就是“模型驱动 SubAgent”的核心思路。那它和普通的“多 Agent 互相聊天”有什么区别我的理解是多 Agent 协作往往强调多个模型平级对话互相提问、互相补充而模型驱动的关键在“统一调度”。核心模型负责把整个开发任务拆解成阶段性的子任务分派给对应的 SubAgent然后逐一校验产出、汇总结论。SubAgent 不是平等的聊天对象而是有明确职责边界、被统一管理的工作单元。打个比方这不是一群同事开无休止的会议而是 CEO 定方向、分任务各职能部门在自己的边界内执行再向 CEO 汇报结果。这样设计带来三个立竿见影的好处每个 SubAgent 的提示词和技能可以做得非常聚焦不用在“需求分析”和“写代码”之间横跳输出质量明显更稳定上下文可以分段管理每个 SubAgent 只接收与自己相关的信息从根本上缓解上下文漂移任何一个环节出错可以单独重跑、单独替换不需要把整条流水线推倒重来。2. 五大 SubAgent 的分工边界与协作协议2.1 五个角色各自负责什么、产出什么我在这套体系里把企业应用开发拆成五个 SubAgent对应成熟研发团队里需求、架构、开发、测试、运维五个岗位。他们共享一个模型底座但各自的提示词、输入输出格式完全独立。SubAgent核心职责关键产出物需求分析 SubAgent把模糊业务诉求转为结构化需求拆用户故事定义验收标准提出待确认问题需求规格说明书、用户故事清单、验收标准、待确认问题列表架构设计 SubAgent确定技术选型、模块划分、数据表设计、API 契约输出系统设计决策及理由架构说明文档、ER 数据模型、API 端点契约、关键技术决策记录代码实现 SubAgent按架构与契约生成后端、前端代码落地业务规则补齐数据库脚本可运行的工程代码、数据库迁移脚本、环境配置样例质量测试 SubAgent按验收标准反向推导测试用例覆盖正向与负向场景输出风险清单测试用例集、测试执行报告、未覆盖风险清单交付运维 SubAgent生成部署配置与发布检查项核对依赖版本与环境变量输出上线清单Dockerfile、docker-compose 配置、部署文档、上线检查清单这里尤其要说一下需求分析 SubAgent 的价值。大多数人在搭建 Agent 开发流程时会忽略它觉得直接从写代码开始更快。但恰恰是它帮我挡掉了大量“写完后返工”的悲剧。它会把“我们要做个报修系统”这种模糊的话拆成角色、流程、规则、验收标准四个维度的结构把需求真正变成后续环节能执行的东西。2.2 SubAgent 之间的“交接语言”结构化产物很多人搭建 SubAgent 失败不是单个 Agent 能力不够而是代理与代理之间的交接环节信息丢失、格式混乱。你想如果 A 代理输出的是长篇大论的自然语言B 代理在理解时必然会漏掉细节如果更糟的是 A 代理输出的是口头约定B 代理可能还要反过来再猜一遍。所以我给每个 SubAgent 定义了严格的“输入-输出契约IO 契约”。所有关键交接物都必须是结构化文档而不是自由文本。比如需求分析 SubAgent 的输出必须包含编号、用户角色、业务规则、验收标准四个字段其中核心业务规则单独提炼排在文档开头架构设计 SubAgent 的输出必须包含模块清单、数据表清单、API 端点清单三大部分每个 API 端点必须标注请求结构、响应结构和权限要求代码实现 SubAgent 只读取架构设计输出和需求规格禁止自己重新推断业务规则遇到规则模糊必须向上游报错而不是猜测试 SubAgent 的输入是代码产物加上需求验收标准生成用例时必须逐条标注对应的验收标准编号保证“每条标准都有用例跟踪”运维 SubAgent 的输入是最终代码和架构设计中的部署约束输出部署检查和上线清单要求逐项可核对。这套 IO 契约设计好之后SubAgent 之间就不再是“自由聊天”的关系而是“流水线上下游交接工件”的关系。每个工件有固定格式字段清晰便于校验也便于出问题时定位到具体环节。这是整套方案里最值得抄作业的部分。2.3 为什么五个而不是三个或七个也有人问我为什么要设五个 SubAgent不能少一点吗我的答案很简单这五个环节刚好对应软件交付中无法合并且容易被验证的五个决策点。需求分析如果不独立出来它会被后续的代码实现吞掉导致业务规则被“顺着代码逻辑悄悄改写”架构设计如果不独立出来代码实现就会自由发挥技术栈和模块边界必然失控测试如果不独立代码 Agent 的自测永远是“自己人查自己人”查不出问题。把五个环节拆开本质上是把软件开发这个大问题分解成五个可以分别监督、分别验证的小问题。而超过五个也不是不行我只是不建议一开始就把链路设计的过于复杂。以企业应用的复杂度五个 SubAgent 已经能把端到端链路覆盖完整且每个环节的产出物都足够聚焦。等团队跑顺了再拆出更细的专项 Agent 也不迟。3. 完整案例从“一句话需求”到“可部署系统”3.1 需求分析把含糊的一句话拆成可以验收的规格光讲架构太抽象我拿一个真实跑过的案例来演示开发一个“员工自助报修平台”。业务不复杂但足够完整员工登录后提交报修单填设备信息和故障描述管理员在后台看到所有报修单认领并处理更新状态系统要发通知给相关人可以用站内信加邮件。扔给需求分析 SubAgent 的原始输入就是一句原生态的话“我们要做一个报修系统员工报修管理员处理得有个通知功能最好能记录处理流程。” 就这么点信息。需求分析 SubAgent 拿到后的第一件事是拆解用户故事第二件事是对模糊的地方生成问题清单。它列出的问题包括员工提交报修单后是否可以撤回如果可以在什么状态之前可以撤回员工需要看到处理进度吗是只看到状态字段还是能看到处理过程的详细记录管理员按什么维度筛选报修单优先级由谁定义通知是实时触达还是按天汇总我把这些问题根据真实业务逐条回答然后它输出了一份结构化需求规格核心部分长这样编号用户角色业务规则验收标准REQ-001员工员工登录后可提交报修单需填写设备名称、故障描述、紧急程度提交成功后系统返回单号并在员工端列表可见REQ-002员工管理员未接单前员工可撤回管理员接单后不可撤回已接单状态下单的撤回按钮不可见后端接口返回业务异常REQ-003管理员管理员可按状态、紧急程度筛选报修单可将单据状态从待处理改为处理中、已完成状态流转序列非法时被拦截并返回明确提示REQ-004员工员工只能查看自己提交的报修单及其处理日志使用两个不同账号互相不可见彼此单据REQ-005系统提交报修后系统需即时发送站内信管理员可在后台消息中心查看提交后 30 秒内生成站内信记录这一步是整套链路的地基。需求规格一旦完整后面所有环节都围绕着它展开任何偏离都可以追溯到具体某一条规则而不是一笔糊涂账。3.2 架构设计把业务规则翻译成系统和数据模型架构设计 SubAgent 拿到规格后第一件要做的事是确认技术栈。这一步我不会让它完全自由发挥而是给定一个约束范围后端用 Java Spring Boot数据库用 MySQL前端用 Vue 3部署用 Docker Compose。这个约束是出于现有团队维护能力的考虑避免它选一个所有人都不会维护的新框架。在技术约束明确后它输出的关键产物包括模块划分用户模块、报修单模块、通知模块、后台管理模块数据表员工表、管理员表、报修单表、状态流转记录表、通知记录表核心接口POST /api/repair/orders 提交报修单、POST /api/repair/orders/{id}/cancel 撤回、GET /api/repair/admin/orders 管理员查询列表、PATCH /api/repair/orders/{id}/status 状态流转。架构设计的价值在这时体现得最明显。比如“员工只能查看自己的单据”这条需求架构层面对应的决策是“所有查询接口必须从当前登录上下文获取用户身份并在 SQL 查询条件中强制带上”“接单后不可撤回”对应的是“状态机在待处理状态才允许 cancel 操作”。业务规则一旦落到架构决策层面就变成代码实现可以直接执行的指令不再依赖写代码的 Agent 自己去理解。3.3 代码实现在清晰契约下把逻辑翻译成工程代码实现 SubAgent 的输入非常干净需求规格 架构文档 API 契约。它不需要猜任何业务规则只需要把已经定好的逻辑翻译成可运行代码。以报修单状态流转为例它会严格按照“待处理 → 处理中 → 已完成”的状态链条实现同时加上校验如果尝试从“已完成”流转到“处理中”直接抛出业务异常并返回错误信息。对于撤回逻辑会先判断单据当前是否处于“待处理”如果不是则拒绝操作。除了业务代码它还会顺手补齐两类容易被忽略的东西数据库初始化脚本和管理员种子数据。我建议在架构设计阶段就要考虑这两个产物的归属把它们写进代码实现 SubAgent 的职责里否则很容易出现在测试阶段发现表结构对不上、没有内置账号可用的情况。这里有个值得说的观察当架构契约足够清晰时代码生成的成功率和正确率会明显上升。以前单 Agent 写代码“不可控”核心原因不是模型不会写而是没人告诉它边界在哪里。一旦边界清楚所谓代码不可控的问题能缓解一大半。3.4 质量测试按验收标准反向推导用例代码实现跑通后测试 SubAgent 登场。它的输入是需求规格里的验收标准加实际代码产物输出是测试用例集。这里我特别强调“反向推导”这个词测试用例的源头是验收标准而不是代码实现里的分支。用前者测试才有业务意义用后者就是给代码“背书”测了等于没测。它生成的用例覆盖这几类场景角色隔离用两个不同员工账号分别创建报修单互相验证看不到对方的单据状态机合法性非法流转序列比如从已完成直接改回处理中验证被拦截通知即时性提交报修后检查通知记录表和站内信接收列表确认 30 秒内生成通知记录并发边界模拟两个管理员同时处理同一张单据验证状态更新是否出现相互覆盖。实测下来这些用例确实抓到了几类真实问题其中最有价值的是“员工查询接口没有加用户过滤条件导致能看到全部单据”以及“状态更新没有加乐观锁并发处理时会相互覆盖”。这两个问题如果靠单 Agent 自测基本抓不出来。3.5 交付运维把代码变成一键可部署的服务最后一步是交付。运维 SubAgent 拿到最终代码和架构设计里的部署约束生成 Dockerfile、docker-compose.yml、数据库初始化脚本和部署说明。它还会做一次上线前自检逐项核对依赖是否完整、版本是否对齐、环境变量是否配置、端口是否冲突、密钥是否泄露在代码仓库里。这个环节特别适合用模型来做因为部署检查大多是机械性的核对项模型比人更有耐心逐项过一遍而且容易在第一时间暴露版本不匹配的问题。自检通过后一条 docker compose up -d 命令就能把整套服务拉起来。到这里一套从“一句话需求”到“可运行部署”的完整链路就彻底跑通了。4. 一线踩坑实录这几个环节最容易翻车跑通一次 Demo 是一回事在真实项目里反复用它又是另一回事。下面这几个坑基本是我用真金白银换回来的经验每一个都值得你在搭建时提前避开。4.1 上下文交接丢信息SubAgent 之间最隐蔽的翻车点我最初跑这套链路时犯过一个很低级的错误需求分析 SubAgent 输出的内容非常长架构设计 SubAgent 在读取时只读取了前面的一部分。结果文档后段的几条核心业务规则完全没被架构覆盖代码实现自然也漏了。这种问题在流程里根本不会报错直到功能测试时才发现规则缺失排查链路非常长。后来我在协作协议里加了一个要求需求分析输出时必须把最核心的十条业务规则单独提炼成“关键规则摘要”放到文档最前面。架构设计 Agent 无论如何都能读到这部分再也不会出现读漏的情况。这个改动看着简单但实际效果极其明显强烈建议抄走。4.2 需求被“幻觉”补全最危险的自动化第二个大坑是模型在信息不足时脑补需求。还拿报修平台举例需求分析 SubAgent 曾经默认“员工可以随时撤回自己提交的报修单”但真实业务规定是“管理员未接单前可撤回接单后不可撤回”。如果我没有设置确认节点这个错误规则就会一路传导到架构、代码、测试等发现时已经浪费了一整轮生成。所以我把“人工确认卡点”当成了铁律凡是设计业务规则、权限范围、状态流转这类关键决策需求分析 SubAgent 必须把问题列成清单让我确认不许自作主张。宁可多一轮人机交互也不让错误规则悄然溜进下游。这个卡点不只是为了正确性它其实还让需求环节的整理成本大幅降低因为决策都是当前这轮做出的而不是事后修补。4.3 测试代理“测了但没测对”测试 SubAgent 最容易出现的问题不是测试太少而是测试太配合。它在生成用例时往往盯着代码实现里已有的分支去写覆盖率看着很高但真正要命的业务缺陷测不出来。比如“员工只能看自己的单据”这条标准它可能就只写了“员工 A 能查到自己的单据”却完全没有写“员工 A 访问员工 B 的单据必须 403”。前者确实能通过但后者才是真正的保障。后来我把“按验收标准反向推导用例”写死了并且强制要求它生成负面用例非法参数、越权操作、状态乱序、重复提交这些正是企业应用里真正容易出事故的场景。4.4 技术栈幻觉与版本漂移代码实现 SubAgent 生成前端工程时特别喜欢用最新版本框架和依赖但企业环境里依赖版本通常是受控的。我踩过一次比较惨的坑它生成的 Vue 项目引入了一个较新的组件库版本和现有企业组件库产生严重兼容冲突CI 构建直接挂掉排查了整整一个下午。现在我把依赖版本约束写进架构设计阶段的硬性约束里代码生成之前会先核对依赖版本清单并且要求运维 SubAgent 在自检时再次核对一遍锁文件。这个双保险思路可以确保不因为模型“知识截止时间”和“版本幻觉”而导致交付失败。4.5 成本失控五倍 token 消耗怎么管跑多个 SubAgent 的一个现实问题是成本。五个环节完整跑一次token 消耗大约是单 Agent 的三到五倍。一开始我没有做任何管控一个中等项目跑一轮账单数字非常感人。我的对策是“分段缓存 定向重跑”。需求规格和架构设计是相对稳定的阶段结果缓存下来如果只是改了前端样式或者某个接口实现只重跑代码实现和测试环节需求和架构不动。这样一来绝大部分迭代都只需要两三个环节重跑成本一下子回到可控范围。5. 从跑通 Demo 到真正进生产还差什么5.1 人机审核卡点怎么设计我前面反复提到人工确认卡点这里集中说清楚。我的经验是最少设置三个需求规则确认点、架构方案评审点、发布前人工审核点。前两个是为了在成本最低的阶段拦住错误决策第三个是为了保证没有任何 AI 生成的代码可以未经人工检查直接进生产。这不是不信任模型而是工程纪律。哪怕是亚毫秒级的小改动也至少要有一个懂业务的人过目确认改动符合预期。5.2 哪些环节可以完全自动化哪些不能跑顺之后你自然会想问哪些环节可以全自动哪些必须留人我的判断是机械性、可枚举的检查项可以全自动比如依赖核对、字段完整性检查、接口契约校验、部署脚本验证。带业务决策属性的环节必须留人比如业务规则的最终解释、技术栈的变更、对外合同或审计类功能的设计。需求分析这个环节看起来最像“可自动化”实际却是最需要人深度介入的因为它是所有下游环节的信息源头一旦源头偏了整条链路的产出都白费。5.3 这套方法适合什么、不适合什么最后想聊边界。模型驱动 五大 SubAgent 这套打法最适合的是业务规则明确、模块边界清晰、交付物可以结构化验收的典型企业应用管理后台、审批流、报表系统、工单系统等等。这类系统的共同特点是流程固定、角色清楚、验收维度可量化非常适合流水线式生成。不太适合的是创新探索型项目。产品方向没定、需求天天变、代码改了又改的原型阶段让 AI 去拆需求反而会浪费大量 token人工确认成本也高。那种场景更适合轻量对话式辅助而不是完整走一套五代理流水线。工具是死的怎么用才是活的有意识地判断场景比盲目套用流程更重要。最后说点实在的。我自己在整套流程中最大的体会是模型驱动开发能不能在企业落地关键不在于单个模型有多聪明而在于你愿不愿意把开发流程拆清楚。五大 SubAgent 分工协作本质上就是把“一个什么都会的工程师”拆成“一支有明确分工的团队”让模型在它最擅长的地方干活让人在关键的节点把关。如果你准备动手尝试建议先拿一个简单业务场景完整跑一遍把 IO 契约和确认卡点调顺手再逐步上复杂项目。这套方法的收益不是“一次生成全对”而是“随时出错随时能修”并且每一处修改都能被定位到具体环节。这个特性在企业开发里比一次生成全对重要得多。