在企业应用开发这个圈子里泡了十年我越来越确定一件事真正拖慢进度的往往不是编码而是需求、设计、测试、联调之间的反复拉扯。最近半年我尝试用“模型驱动五大SubAgent”的组合把一个订单审批类系统从零跑通到模拟上线整个过程让我对AI辅助企业应用开发有了完全不同的理解。这篇文章想把这些经验拆开来讲包括五个SubAgent各自该干什么、提示词怎么设计、模型驱动具体驱动的是什么以及那些不跑一遍根本发现不了的坑。无论你是想用AI加速交付的研发负责人还是正在摸索Agent落地方式的架构师这套思路都能给你一个可以直接复制的起点。1. 模型驱动到底在驱动什么1.1 先分清模型驱动和低代码的区别很多人一听到“模型驱动”第一反应是低代码平台里的可视化字段拖拽。实际上两者底层逻辑完全不同。低代码平台的核心是表单、流程、权限的堆叠开发者在平台规则内“拼积木”而模型驱动的核心是领域模型本身也就是业务里的实体、关系、状态、规则。模型一旦建立后续的数据结构、接口定义、界面字段、测试数据都可以从模型推导出来。用一个生活化的例子低代码像装修公司给的套餐选好风格和家具就能入住模型驱动像先画一套完整的建筑图纸墙体、管线、门窗都由图纸定义施工队按图干活。企业应用的难点恰恰在于业务规则复杂、字段关系多、状态流转容易遗漏这些光靠低代码的表单配置很难表达清楚。模型驱动的好处是让AI能把“业务语言”翻译成“技术语言”SubAgent之间的协作也有了一个统一的“图纸”可以参考。1.2 五个SubAgent怎么分工才不打架我这次用的五大SubAgent分别是需求分析、架构设计、代码生成、测试验证、部署文档。一开始我也想过把每个环节都塞进一个Agent里让它们“自由讨论”结果输出混乱到完全没法用。后来才明白SubAgent不是越多越好而是要建立清晰的上下游关系。我这边的分工逻辑是流水线式的但每个Agent的输入输出都共用同一个领域模型文件。需求分析Agent负责从用户原话里提取实体、属性、关系、状态机架构设计Agent拿到这个模型后确定服务边界、数据库表设计、接口契约代码生成Agent只负责按模型和接口定义产出代码测试验证Agent反向从模型生成测试用例再根据代码执行结果回写问题部署文档Agent最后把整个过程的成果整理成可操作的手册和变更清单。这里面最关键的一点模型是唯一的“真源”。所有SubAgent都不许自己发明字段凡是出现模型里没有的业务概念必须挂起让人工确认。这样做看起来死板但能杜绝Agent胡编乱造也让整体质量可控。2. 五大SubAgent的角色拆解与提示词设计要点2.1 需求分析SubAgent把模糊需求变成模型需求分析是我认为最值得投入精力优化的Agent因为后面所有环节都依赖它的产出。这个Agent的输入是业务方的原始描述可能是会议纪要、微信聊天记录、或者一句“我们要做一个审批系统”。输出应该是一份结构化文档包含实体清单、字段表、关系说明、状态机、业务规则。提示词设计上不能只写“你是出色的需求分析师”。我用了三段式第一段告诉它业务背景和企业应用的特点比如多租户、审批流、权限控制第二段给出模型输出的格式模板包括实体名、字段类型、是否必填、枚举值、关系类型第三段给出反例和修正规则比如“不要臆造手机号字段除非原话里明确提到”。实操下来效果最好的做法是让需求分析Agent先输出一版模型再让它自己扮演业务方和开发方进行“追问”。比如我可以要求它列出至少十个可能导致需求模糊的问题再根据这些问题补全模型。这种方式能大幅减少后续返工。要特别注意需求分析Agent最容易犯的错是把操作按钮当字段比如把“提交”“驳回”写进实体属性实际上这些应该是状态机里的动作。2.2 架构设计SubAgent生成可落地的技术方案架构设计SubAgent的输入是需求分析Agent生成的模型文档输出应该是数据库建表语句、接口定义、模块划分、技术选型建议。这个环节的提示词关键点是约束技术栈最好直接把公司现有的约定告诉它比如“后端用Java Spring Boot数据库用MySQL接口风格走RESTful”。如果不做约束架构设计Agent会给你整出一堆网红组件看起来华丽落地全是坑。我在提示词里明确要求它遵守三条原则优先公司标准库、避免引入新中间件、所有设计必须能对应到模型中的字段。每次输出后我会手动检查一点点确认数据库字段和模型字段一一对应。这里最容易翻车的点是代理主键和外键命名不规范比如有的表用id有的表用order_id后面代码生成Agent就会拿着这些字段乱猜关系。2.3 代码生成SubAgent围绕模型产出业务代码代码生成SubAgent是大家最先想到的也是最容易让人失望的。很多团队直接让它“给我生成一个订单模块”结果代码生成得挺热闹真正用到生产里全是编译错误和逻辑漏洞。我尝试下来的正确姿势是先把接口契约喂给它再让它按照“模型层→服务层→控制器层”的顺序逐段生成而不是一次性生成一整个模块。提示词里要明确告诉它代码风格。比如领域对象命名要跟模型文档一致、数据库操作用MyBatis还是JPA、错误码返回格式是什么。还可以给它一个“已完成示例”作为风格锚点让它模仿你的编码习惯这比在提示词里写一百句“保持代码整洁”都管用。另外代码生成Agent跑完并不等于完事。我会把生成的代码放进项目里编译再把编译错误收集起来反馈给它让它自己修改。这一步我做成一个循环最多循环四次。超过四次还报错基本可以判断是架构设计阶段出了问题不是代码生成Agent能力不够。记住这个判断逻辑能帮你省很多排查时间。2.4 测试验证SubAgent从模型反推测试用例测试验证SubAgent的输入是领域模型和接口定义输出是测试用例表和自动化测试脚本。它的核心价值不在于写得多么花哨而在于能按照模型的边界条件来设计用例。比如模型里“审批金额超过一万要走总经理审批”那测试用例就必须覆盖一万整、一万零一分、九千九百九十九三种情况。这个Agent的提示词重点是让输出结构化。我让它返回一棵测试用例树包含用例编号、前置条件、入参、预期结果、对应接口。然后我再让代码生成Agent把接口桩代码和测试用例放一起跑一遍这样就能把“逻辑缺失”和“代码出bug”区分开。我在实际使用中最大的体会是测试Agent必须放在代码Agent之后串行执行并行反而会因为上下文太乱导致测试用例跟接口对不上。2.5 部署文档SubAgent收尾的最后一公里部署文档SubAgent容易被忽略但它决定整个项目能不能被别人接手。这个Agent的输入是架构设计文档、数据库脚本、环境变量清单和代码库说明输出是部署手册、配置检查清单、回滚方案和上线变更说明。提示词设计的技巧是要求它“假设读者是一个刚入职的运维工程师”每一步都要给出具体命令和预期输出。比如初始化数据库之后要查表数量启动服务之后要调用健康检查接口。如果一个部署步骤里没有“预期结果”就让它重写。这个约束能避免文档变成空话合集。3. 实操过程从零到一跑通一个订单审批应用3.1 定义领域模型我到底让需求Agent干了什么我为了验证这套体系选了一个常见的业务场景企业内部采购订单审批。原始需求只有一句话“业务员提交采购订单金额超过一万需要部门经理和财务经理先后审批通过后自动生成采购单编号并通知申请人。”我把这句话原封不动扔给需求分析SubAgent。它输出的模型经过我整理后大概是这样的订单主表包含订单编号、申请人、申请部门、总金额、状态、创建时间订单明细表包含商品名称、数量、单价、小计状态机的状态有草稿、待部门审批、待财务审批、已通过、已驳回动作有提交、部门通过、部门驳回、财务通过、财务驳回。这里有一个我必须强调的细节第一次跑出来的模型把“审批意见”写成了订单表的一个字段这是错的。正确的做法是单独建一张审批记录表关联订单ID、审批人、审批层级、意见、时间。如果不把审批履历独立出来后续做审计追溯根本没法查。这个坑靠Agent自己是发现不了的需要人工基于业务常识去修正。我自己手动调整后把修正流程也写回了需求Agent的提示词里让它下次先判断“这个业务概念应该独立成实体还是作为属性”。3.2 配置五大SubAgent的协作流我用的方式不是让五个Agent直接互相聊天而是搭了一个简单的状态机来控制流转。每个Agent执行完后会把结果写入一个共享的工作目录同时更新一个进度清单。比如需求Agent完成后会生成domain_model.json和requirements.md架构Agent在检测到domain_model.json更新后自动启动生成schema.sql和api_contract.yaml。这里要注意的一个细节是上下文管理。五个Agent如果共享同一个超长对话很快就会被无关信息淹没。所以我为每个Agent单独设立了上下文窗口只在需要传递模型文件时读取文件内容而不是把整个需求分析过程都塞给后续Agent。这样的效果是每个Agent都专注自己的任务不会因为前面Agent说了什么闲话而跑偏。配置协作流时我特别设置了一条人工介入规则当架构Agent生成的数据库字段与领域模型不一致时流程暂停不自动修正而是输出差异报告。这是为了保留人的判断权防止Agent互相“圆谎”。3.3 生成结果与人工校对的关键节点整套流程跑完之后我得到了一整套可运行的东西数据库建表脚本、Spring Boot后端代码、接口测试脚本、部署文档。但这不意味着可以直接交付人工校对依然很关键。我总结出的三个必查节点第一个节点是数据库表关系图。把Agent生成的表关系列出来人工扫一眼基本能发现有没有一对多关系搞反、外键方向搞错的情况。第二个节点是权限相关代码。企业应用绕不开权限。比如采购订单模块必须只允许本部门业务员查看自己的单据但Agent常常在生成通用CRUD时把查询接口写成全员可见。这个不是提示词能解决的最好是人工抽查权限判断逻辑。第三个节点是状态机流转代码。重点看“驳回后重新提交”的状态路径是否完整。很多Agent会把状态机画得很完整但到了代码实现里却少了某个状态转换的接口。人工抽查时要特别关注这些“非主路径”流程。4. 常见问题与排查技巧实录4.1 最容易踩的四个坑第一个坑是SubAgent之间上下文不一致。我遇到过需求Agent定义的枚举值是“PENDING_APPROVAL”代码Agent却用了“PENDING”两个Agent各自为政编译能过但运行时报错。解决方式是把枚举定义单独抽成一个共享文件所有Agent读写同一个文件并且要求代码Agent订正为“以共享文件为准”。第二个坑是过度设计。架构Agent很容易引入缓存、消息队列、分布式事务对于一个订单审批场景根本不必要。我的约束是必须写明引入理由并且只有在性能测试数据支持的情况下才能保留。第三个坑是测试用例与真实业务不匹配。测试Agent生成的用例偏单元测试缺少端到端流程测试。比如只测了“提交订单”接口能通但没有跑通“提交→审批→驳回→重新提交→通过”的完整链路。后来我在提示词里明确要求它至少生成五条跨接口的端到端用例情况好很多。第四个坑是部署文档和代码不同步。因为部署Agent读取的是架构文档如果架构文档没有及时更新部署Agent就会按照旧方案写文档。我每次代码完成之后会强制把数据库变更和接口变更回写到架构文档再触发部署Agent。4.2 遇到问题怎么快速定位我整理了一个简单的排查顺序建议按这个来先看共享模型文件是否变更确认Agent之间是不是基于同一版本工作看数据库脚本与模型字段是否一一对应多一个少一个都说明架构Agent有问题看错误日志是发生在编译期还是运行期。编译期错误大概率是代码生成问题运行期错误重点查状态机和权限判断最后才是看提示词是否不够具体。实际上改提示词是最容易做的事情也最容易掩盖真实问题我建议把它放到最后再改。另外我想推荐一个技巧给每个Agent的输出加上版本号并且每次重跑后做diff。不用复杂工具用简单脚本把前后两次json做对比能让你一眼看清哪一步出了问题。4.3 两条我反复用到的保命经验经验一模型文件必须由人来批准。我现在的流程是需求Agent输出模型后我不是直接把它交给架构Agent而是先打开模型json看一眼确认主要字段和状态机没问题再放行。这个过程只需要五分钟但能避免绝大多数严重bug。经验二给Agent设置“不知道就说不知道”的约束。在提示词里明确写“如果需求描述里没有提供的信息不要猜测请标记为待确认”。这个约束看起来不起眼但效果很显著它可以防止Agent自嗨式补全需求后续的返工也会少很多。5. 用好这套组合的边界与后续扩展5.1 什么样的项目适合这套方案我跑完这个订单审批应用后又试了几个不同类型的小项目总结出适用边界。模型驱动SubAgent最适合的就是业务规则清晰、实体关系明确、流程固定的企业应用比如审批系统、工单系统、进销存、报表后台。这类系统的共性是可建模性强而Agent的幻觉风险相对可控。不太适合的是两类场景一类是交互体验要求极高的C端应用另一类是核心算法高度复杂的系统。前者的设计细节难以用模型表达后者的关键逻辑必须靠资深工程师精雕细琢硬套这套方案只会增加沟通成本。我个人的建议是开始一个项目之前先花半天时间把核心实体和状态机画出来如果画不出来说明项目不适合不要强推。5.2 如何把五大SubAgent扩展成更多Agent这套架构的扩展性其实很好。当项目复杂度上升时可以在现有流水线里切出更细的Agent比如把测试Agent拆成“单元测试Agent”和“端到端测试Agent”把代码Agent按模块拆成“用户模块Agent”“订单模块Agent”。拆分的标准是看单个Agent的输出是否稳定如果某个Agent总是出低级错误可以先改进提示词和示例而不是急于拆分。扩展时还有一个原则不要增加需要互相讨论的Agent而是增加可以串行处理、输入输出明确的Agent。我试过让多个Agent开“圆桌会议”结论是效率低、结果不可控。企业应用开发要的是确定性而不是创意发散Agent之间最好是流水线而不是头脑风暴。5.3 一些真实的使用体会跑完这套流程后我最大的感受是模型驱动的核心是启发人把业务想清楚。以前做项目经常是边写边想需求变导致数据库改数据库改导致代码重写。现在我先逼自己把模型定义清楚后续AI生成的代码自然就稳了。五个SubAgent的价值不是替我做决策而是把我的决策翻译成代码和文档再帮我检查遗漏。如果说有什么要提醒的那就是不要盲目追求全自动。我最后保留的人工节点有三个模型审批、权限抽查、上线前状态机走查。这三个节点加起来花的时间不到一小时但能省掉后面好几天调试时间。AI可以帮你把重复劳动吃掉但业务正确性这件事最终还是得由人来兜底。