每次听到“用AI开发企业应用”我第一反应都是能跑通需求评审吗能处理脏数据吗能在等接口联调的时候自己填mock数据吗这个项目就是我在一线摸爬滚打大半年之后把“模型驱动五大SubAgent”这套思路完整跑通的一次记录准确说是把一个从供应商系统、审批流到数据看板的企业后台从零推到上线。它解决的是企业应用开发里最磨人的那部分需求不完整、沟通成本高、代码写完了才发现业务规则理解错了。如果你也想让大模型不只是“帮你补全函数”的插件而是真正变成一个能拆任务、能审代码、能追着测试跑的项目团队这篇文章应该能给你不少实际能抄作业的东西。1. 为什么我会选择模型驱动SubAgent这套路线1.1 从传统开发到“AI带团队”的思路转变之前做企业应用最累的不是写代码而是“把需求变成所有人理解一致的东西”。业务部门跟你说“搞一个审批流”等你做完了他说“审批流要支持会签、或签、转办、委派另外超时还要自动提醒”。你跟产品经理对需求、跟后端对接口、跟测试对用例一圈下来项目进度的瓶颈完全不在键盘上而在沟通链路上。模型驱动SubAgent解决的恰恰就是这个链路问题。大模型负责理解业务描述把它拆成可执行的任务SubAgent各自扮演固定角色把一个大目标分解成需求分析、架构设计、代码实现、代码审查、测试验证几个环节去执行。我选择的不是“让AI直接一次性生成整个系统”而是让AI扮演一个虚拟技术团队每个角色只管自己那一段再通过统一的上下文把结果串起来。这样做的好处很直接出问题的时候知道找谁改需求的时候不用整个推倒重来。1.2 五大SubAgent到底拆出了哪五种角色我觉得这套架构里最关键的决策就是把工作拆成五个可以相对独立运行、又必须按顺序交接的角色。第一个是需求解析Agent负责把业务方口语化的描述转成结构化需求包括功能清单、业务规则、输入输出、异常分支。第二个是架构设计Agent根据需求给出模块划分、数据库表设计、接口定义和技术选型建议。第三个是代码生成Agent按照架构设计产出可运行的代码细分到控制器、服务层、数据访问层。第四个是代码审查Agent对生成代码做静态检查、逻辑漏洞排查和规范校验发现问题就打回重写。第五个是测试验证Agent负责编写测试用例、执行自动化测试、把测试结论反馈给代码生成Agent。这套分工不是拍脑袋想的而是对照传统项目组的角色划分做的映射。企业应用开发最大的特点就是“链条长、协作多、变更频繁”如果只有一个Agent完成所有事情很容易出现上下文越滚越乱、改一处崩三处的情况。拆成五个角色之后每次交接都像是小团队内部的一次评审信息被反复确认错误被尽早拦截。2. 模型驱动怎么“驱动”核心机制与关键配置2.1 模型驱动不只是自动生成而是“规则上下文”很多人以为模型驱动就是把需求丢给大模型等它吐出一堆代码。实际跑下来会发现企业应用生成出来的代码经常是“看着对一跑就废”原因就在于缺少规则约束。我理解的模型驱动是两层东西叠加一层是业务领域的规则库比如审批流的状态机规则、权限模型、数据字典另一层是项目上下文包括数据库结构、已有接口协议、团队代码规范、部署环境配置。这两层信息都需要提前“喂”给SubAgent而且要持续更新。我踩过最深的坑就是把规则写在Prompt里就以为万事大吉结果需求一变某个Agent还在用旧规则生成代码。后来我做成一个独立的rules目录每个Agent开始执行前强制读取对应规则文件才算把这个问题解决掉。2.2 SubAgent之间的任务拆解与上下文传递SubAgent能不能高效协作核心看两件事任务拆得够不够细上下文传递得够不够准。任务拆解我采用的是“需求树”的方式。需求解析Agent产出的每个功能点对应一个叶子节点架构设计Agent再基于叶子节点产出模块级任务代码生成Agent进一步把模块任务拆成“控制器-服务-仓储”这类标准开发任务。这个过程很像瀑布流但和传统瀑布流不同的是每个环节都有自动化的可验证产物不是等全部做完才测试。上下文传递我是通过一份“项目黑板”来做的。所谓黑板其实就是一个持久化的上下文文件包含需求文档快照、架构决策记录、接口清单、测试结论。任何Agent在执行任务前都要读黑板执行完要把增量写回黑板。这样即使某个Agent因为模型上下文窗口限制丢掉了早期信息也能从黑板上恢复。2.3 一套可复用的Agent Prompt模板这里分享一个我调整了很多版本的Prompt结构Base Agent的基本骨架是这样你是[角色名称]负责[职责范围]。 项目背景[一句话描述项目目标] 当前迭代[本次要完成的目标] 输入依赖[需要读取的文档或数据] 输出产物[要有明确的结构和文件名] 约束规则 1. [业务规则编号]具体规则内容 2. [代码规范编号]具体规范内容 3. [禁止事项]不能做什么 完成标准[什么情况下算真正完成]这个模板看起来简单但每个字段都是必要的。角色和职责范围解决“你是谁、你管什么”的问题项目背景和当前迭代解决“为什么做”的问题输入依赖解决“你要看什么资料”的问题输出产物解决“交给下一个人什么”的问题。约束规则里最重要的就是禁止事项我写过“禁止修改数据库表结构除非在架构评审通过后”这一句就避免了很多次代码生成Agent自作主张加字段的乱子。3. 用这套方法跑通一个企业应用的完整实操3.1 企业应用场景与目标选型我实际跑的项目是一个内部供应商管理后台核心功能包括供应商准入、资质审核、样品送检、订单审批、月度对账、数据统计展示。这类系统很典型业务规则复杂、状态流转多、接口对接多、报表要求细。选它做实验就是因为它足够“企业级”能暴露各种协作问题。技术栈我选的是Java Spring Boot MyBatis Plus MySQL Vue3数据库表和接口文档我手动维护了第一版后面交给架构设计Agent去扩展。选择这个技术栈的原因很朴素社区成熟、招人好招、各类大模型训练语料里这类代码多生成质量明显比冷门框架高。3.2 从需求文档到任务拆解第一步我先把业务方给的Word版需求文档做了一次清洗去掉口语化描述和前后矛盾的部分整理成一份结构化的PRD给需求解析Agent。这一步非常关键模型再强也经不住原始需求里的“以后再说”“大概就这样”这类话。我把每一条需求拆成“编号、功能描述、业务规则、验收标准”四列这份表就是整个项目的需求基线。需求解析Agent拿到的任务是把这份PRD扩展成一份完整的功能清单比如“供应商准入”这一条它要拆成注册信息填写、证件上传、准入规则校验、线上初审、线下复审、准入结果通知、资质有效期提醒。同时它还要识别业务规则比如“注册资本不低于100万”“ISO证书必须在有效期内”这类约束单独写进规则文件。3.3 让五个Agent各自干活的协作流程我把整个协作流程设计成三个迭代循环。第一轮需求解析Agent产出功能清单和规则文件我逐条核对去掉两条模型自己脑补出来的反常识规则比如它把“月结供应商账期30天”理解成“每日自动扣款”这类错误如果不在第一轮拦下来后面代码生成、测试全都会错。第二轮架构设计Agent接收需求清单产出数据库表设计、接口定义、模块划分。它设计的表结构我重点检查索引和外键关联接口定义重点检查状态机流转是否覆盖所有分支。检查通过后这个设计文档进入代码生成Agent的执行队列。第三轮代码生成Agent按照模块逐个生成代码生成完立刻交给代码审查Agent审查Agent发现代码里漏了字段校验、没有处理事务回滚、接口返回格式不统一就标记为“需修复”把问题清单返回给代码生成Agent修改。修改通过后测试验证Agent编写测试用例并执行发现的缺陷再走一轮“测试Agent反馈-代码生成Agent修复-审查Agent复核-测试Agent回归”。整个流程中我并不是甩手掌柜我重点把守几个决策点需求规则去留、数据库结构变更、数据权限模型、部署方式。这几个点一旦出错后面返工成本极高我宁可在这些节点上多花时间也不让Agent自己拍板。3.4 人工干预点哪些地方坚决不能让Agent自己拍板跑了大半年我总结出几个“人工必看”的干预点。数据权限模型必须人工定。企业应用里的权限不是简单的“管理员/普通用户”就能覆盖的还有部门数据隔离、供应商只能看自己的订单、不同角色看到同一个报表的不同汇总口径。这些规则来自组织架构和业务约定模型很难凭空理解让代码生成Agent自由发挥的结果就是权限漏洞。外呼接口的失败处理必须人工确认。比如对账模块要调用财务系统接口接口超时、返回错误码、部分成功部分失败这些情况要怎么处理直接影响资金准确性。我给Agent的规则是“对账接口失败时不得自动重试超过两次失败记录转入人工处理队列”这种规则需要人来定不能让AI自己优化。凡是涉及金额、合同有效期、资质到期日期的计算逻辑Agent生成的代码我全部要求输出运算过程并人工复核。模型生成的计算逻辑经常在整数精度、小数位、时区转换上出问题这些在测试环境看不出来上线就炸。4. 常见问题与排查技巧实录4.1 Agent之间的上下文“丢记忆”怎么解决我在初期最头疼的问题就是代码生成Agent生成第三模块的时候已经忘了第一模块里定义过的公共字段命名规则。后来每次生成前都会读取黑板文件里的“接口规范”和“数据库设计”章节相当于每轮开工前开一次站会把关键约定重新拉齐。如果某个Agent处理的信息量太大我还是会把任务再拆分不让单个Agent一次性处理超过一个完整模块。4.2 生成代码符合结构但不符合业务怎么办这类问题最隐蔽因为代码结构没毛病接口也通了但跑出来的业务结果跟预期不一致。比如“审批通过后自动通知下一级审批人”生成代码确实调用了通知功能但通知内容里没有带上审批备注导致下一级审批人不知道上一级改了什么。排查这类问题我用了一个笨但有效的方法把每条业务规则编号直接写进代码注释比如“// BR-0021 审批通过后通知下一级审批人内容需包含审批备注”然后在测试阶段测试验证Agent会针对每个BR编号检查代码实现和测试结果是否一致。凡是注释和实现不一致的地方就是业务规则丢失的重灾区。4.3 测试Agent报错太多导致流程卡死测试验证Agent最容易在一个小问题上反复打回比如代码审查Agent认为“方法命名不合规范”算缺陷测试Agent认为“不影响功能运行”不该列缺陷两边吵个不停流程直接卡死。我给每个Agent定义了缺陷分级规则致命错误系统崩溃、数据错乱、严重错误业务主流程不通、一般错误边界条件未处理、建议优化代码风格、命名规范。只有致命和严重问题才阻塞流程一般问题和建议优化批量处理。这样调整之后流程顺畅了很多那些不痛不痒的问题也不会再打断代码生成Agent的连续工作节奏。4.4 企业安全合规限制下如何落地在企业内网环境落地这套方案最大的限制不是模型能力而是“能不能用外部模型API”。如果不能连接外部模型服务就需要部署本地模型。我的经验是本地模型的代码生成能力会弱一些但配合五个SubAgent的分工协作可以弥补单模型能力的不足。需求解析和测试用例生成这类对语言理解要求高、对代码执行要求低的任务本地模型完全够用代码生成和审查这类任务可以配合更高质量的模型来做。另外要注意的一点是不要让Agent把整个代码仓库的内容都作为上下文传给模型。我采用的策略是只传模块级文件清单、接口定义、关键配置项和规则文件而不是把公司核心代码全部暴露给模型处理。这样既控制了上下文长度也降低了代码外泄风险。4.5 常见问题速查表问题可能原因排查方向我试过有效的解法生成的代码引用了不存在的字段上下文中的数据库设计快照过期检查黑板文件里的表结构是否最新每次数据库变更后强制刷新设计文档并更新黑板接口联调时返回字段命名不一致不同模块分别生成时未使用同一接口规范检查接口定义文件和实际返回值让架构设计Agent统一维护接口契约代码生成必须按契约实现审批流状态错乱状态机规则描述不完整检查规则文件里的状态转移条件把状态流转写成显式的状态表并让测试Agent跑一遍全链路流转用例Agent连续修改后反而引入新问题修改范围失控检查审查Agent是否只打了目标问题限制单次修复范围一次只修一个问题修完立刻回归测试规则文件更新后部分Agent还在用旧规则上下文没有及时刷新检查Agent执行前的规则读取逻辑在Prompt模板里强制要求“执行前读取规则目录并记录规则版本号”5. 这套路线能走多远边界与扩展5.1 适用边界什么项目不适合不是所有企业应用都适合用这套模型驱动SubAgent路线。我做过横向对比只有一类场景效果最好需求相对稳定、业务规则可以被结构化描述、代码实现模式化程度高、测试标准清晰。典型的比如合同管理系统、审批流系统、报表看板后台、订单管理系统。有两类项目我建议不要硬套。一类是算法密集型的应用比如排产优化、风控模型、大规模并发调优这些领域的核心壁垒在算法和调参经验不在代码生成的量上SubAgent帮不上什么忙。另一类是需求极其模糊且高频变化的创新项目这时候连需求解析Agent都会崩溃因为它要花的绝大部分时间在跟需求方反复确认而不是生成代码。5.2 从五大SubAgent继续往上的演进方向这套架构跑通以后我的下一步方向不是“增加更多Agent”而是把每个Agent的执行结果做得更可度量。目前需求解析Agent产出的功能清单质量高低只能靠人来判断代码审查Agent的审查规则也主要靠静态规则匹配真正判断代码质量还是需要人来兜底。后续我想给每个Agent增加更明确的“产物验收指标”比如需求覆盖完整率、接口契约一致率、测试用例通过率、缺陷逃逸率让整套流程从“看起来在干活”进化为“干得好坏一目了然”。另一个方向是让五个SubAgent在同一个迭代里并行跑。目前的流程是串行的需求解析跑完才能架构设计代码生成完才能测试。但实际企业生命周期里多个需求模块之间是可以并行开发的。我准备在黑板机制上做一层版本控制让不同模块的不同Agent分支同时执行最后再合并冲突。5.3 踩过几次坑之后的稳健建议如果你也想把这套方案用到自己的项目里我给三个不算新颖但真的能救命的建议。第一不要一开始就追求全流程自动化。先让一个人看起来像是“人工在驱动五个Agent”把每个环节的输出拿过来人工验收一遍等确认某个环节的输出稳定可靠了再加自动执行。上来就跑全自动的后果就是错误在链条末端爆发找问题找了三天。第二规则文件比Prompt重要。Prompt是告诉Agent怎么干活规则文件是告诉它哪些东西不能碰。把企业业务里的硬约束、财务规则、安全红线都写进规则文件比在Prompt里反复强调有效得多。第三一定要保存每一轮迭代的产物流水。我在本地用Git管理每个Agent的输出包括需求清单改动、架构决策记录、代码版本、测试报告。这套流水在追问题的时候价值很大因为你能准确看到是哪个版本、哪个Agent、哪次改动引入的问题而不是对着最终代码瞎猜。跑完这大半年我最大的体会是模型驱动SubAgent这套组合拳真正改变的并不是写代码的速度而是企业应用开发里那些“看不见的损耗”。需求理解偏差、协作信息不同步、规则遗漏这些老问题开始变得可以被结构化地发现和处理。我甚至觉得把一套完整的企业应用开发拆成五类角色去驱动本质上才是这套方法论的核心——大模型只是执行体真正值钱的是你怎么划分这个“虚拟团队”的职责边界以及你在哪些节点上坚持了人的判断。后面我还会继续把这套流程往更多类型的企业应用上试验尤其是加进更多遗留系统改造的场景到时候有新的进展再来分享。