上个月我压着一个思路把一个合同登记模块从需求清单一路推到了测试环境全程没有手写一条新增业务逻辑。你看到的不是我突然会了什么黑魔法而是换了一种组织AI干活的方式模型驱动加五个各有职责边界的SubAgent。在企业应用开发里CRUD页面、审批流、权限控制这些活儿大多是可枚举、有规律的真正让人头疼的从来不是单点代码而是需求反复、口径漂移和验收扯皮。我把整套做法摊开讲从分工设计到具体模型文件、再到踩过的坑和适用边界尽量按一线能直接照做的程度来写。适合正在做企业管理系统的团队也适合想知道“多个Agent怎么协作而不是各写各的”的朋友。1. 为什么我先放弃了“全自动生成”这条路第一次真正被“全自动生成”打脸是在一个供应商主数据项目里。当时我把一份三十多页的需求文档直接丢给一个Agent让它一口气生成数据库、后端接口和前端页面Demo跑得确实漂亮。可一旦进入真实联调问题像连环雷一样炸开客户说“合同编号要支持录入带横杠的格式”Agent答“好的”然后把实体字段、校验规则、列表筛选项全部重写了一轮连带改了十几个接口的DTO却没有更新任何一张迁移脚本数据库和我本地的代码仓库当场分叉。为了救回现场我又花了一整天手工对齐字段。这不是智能不够而是组织方式错了。单个Agent把“需求理解、表结构设计、代码生成、测试验收、发布”五件事全压在一条上下文里前十分钟它还能保持战略一致到第三十分钟它已经分不清哪些字段是需求里有的、哪些是自己脑补的。企业应用开发里的痛点从来不是“AI不会写代码”而是“改一个字段时周边的二十个关联点没人管”。所以我把团队里真实的分工映射到SubAgent需求分析归需求Agent建表归建模Agent代码归生成Agent验收归测试Agent发布归交付Agent。不再让一个Agent思考所有事而是让每个Agent对一小块结果负责。同时引入真正的“模型驱动”不是继续喂自然语言需求文档而是让所有Agent围绕同一份结构化业务模型文件协作。说句实在话MDD模型驱动开发不是新东西过去模型是给工程师看的设计文档现在这份模型同时是给AI看的“施工蓝本”。需求变更时改模型Agent按模型重新生成保证扩散面收敛、可回滚、可review这套结构带来的确定性比单纯堆prompt技巧高得多。2. 五大SubAgent的职责切分一个开发小组的数字化分身先说结论我最后稳定下来的分工表大概长这样——SubAgent对应传统角色主要输入主要产出核心工具与边界需求分析Agent产品经理 / 业务分析师原始需求、现有系统截图、第三方接口文档功能规格书用户故事、验收标准、待确认问题文档检索、追问清单不写代码、不改模型业务建模Agent架构师 / 资深后端功能规格书、当前模型文件app-model.yaml、数据库迁移脚本、API契约YAML校验、git diff、DDL生成器不碰业务代码应用生成Agent全栈开发模型文件、页面模板、代码生成配置前后端代码、路由、权限控制逻辑模板引擎、静态检查、单元测试骨架不直接改数据库质量验证Agent测试工程师生成的代码、接口契约、可运行环境测试用例、测试报告、失败原因清单pytest/JUnit、Mock、覆盖率默认只读代码交付运维AgentDevOps / 实施构建产物、环境变量清单构建脚本、部署记录、健康检查、变更日志CI配置、容器编排、日志查询只操作非生产环境这个分工不是我想当然划的是照着真实项目里“谁会为哪种错误背锅”反推出来的。比如需求理解错了第一责任人是需求分析师而不是写代码的人表结构设计错了得先找架构师上线后日志查不到找运维。Agent之间必须有明确的产物流转否则它们会像一群没有项目经理的程序员各自写各自的东西最后在接口对齐时互相妥协出一个三不像。2.1 需求分析Agent把“差不多”翻译成验收标准这个Agent只做一件事把零散输入变成可验收的描述。它会要求业务方回答“列表页默认按什么排序”“金额上限是多少”“删除是物理删除还是状态置为无效”这些问题如果不前置问清楚后端的成本是翻倍的。我在项目里实际感受到的作用是以前开发前要开两次需求会现在把这个Agent的输出直接贴回给业务负责人圈改半天内就能攒出一份没有歧义的需求基线。你甚至不需要给它特别聪明的模型它的任务更像“格式化提问机”但这一步省掉了后面四个Agent大量无意义返工。2.2 业务建模Agent维护唯一的模型文件这是整套体系的“总设计师”。它读需求基线把业务对象拆成实体、字段、关系、状态机、页面、权限统一写进模型文件。它每次改动都必须给出迁移脚本和diff如果它新增了amount字段但没写是 decimal(12,2)我会直接打回让它重出。原因很简单模型文件是所有下游的输入源模型里多一分含糊代码生成和测试Agent就会各自脑补两分最终在QA阶段汇合成四分冲突。所以我对它定的规矩是要么不输出输出必须通过YAML校验和字段类型检查。2.3 应用生成Agent基于模板把模型映射成代码生成Agent是量产主力但也是最需要“限制”的Agent。我给它喂的不是模型文件全文而是模型文件所在路径、页面模板和一个明确的代码生成配置它按照“实体→CRUD接口→列表/表单页面→权限注解→路由注册”的顺序产出代码。更关键的是我划分了两个代码目录gen/是生成区下次重跑会被清空重建ext/是人工扩展区任何Agent和人都不能随便动gen/业务特殊逻辑写在ext/里并通过显式接口挂载。这样既保住批量生产力又给手写逻辑留了隔离空间不会出现“一重新生成就把你手工改动全冲掉”的悲剧。2.4 质量验证Agent让“能跑”变成“确定能跑”验证Agent默认只有“读代码、写测试、跑测试、出报告”的权限我刻意禁止它直接改业务代码。它做的事很像一个严谨的测试工程师先生成批量数据和单测再跑集成测试失败时把“失败断言、实际输出、期望结果、可能的代码位置”整理成结构化报告交回给生成Agent修复。这个闭环里最大的价值是“失败信息被标准化了”。以前人工排查日志要翻译半天现在测试报告直接给出断言差异生成Agent可以据此精准定位修改质量明显提高。2.5 交付运维Agent从CI到监控的最后一公里最后一个Agent负责把我确认过的代码变成可运行的测试环境。它执行构建、生成容器镜像、更新部署配置、跑健康检查最后产出变更记录。一开始我觉得这步可有可无直到发现人工部署一次要花五十分钟而且没人记得上次加过哪些环境变量。交付Agent接管以后环境变量清单被当成一等代码提交进仓库每次部署前自动对比差异缺漏项在部署之前就会被拦下来。3. 模型驱动在这里到底“驱动”了什么一份模型文件的映射逻辑很多人一听“模型驱动”就以为要建一堆UML图。我的做法非常朴素核心就是一份YAML模型文件app-model.yaml里面把业务对象的状态和页面定义清楚。拿合同登记举例精简下来大概长这样modelVersion: 1.4.0 entities: contract: tableName: t_contract fields: contractNo: type: string length: 32 required: true unique: true partyName: type: string length: 128 required: true amount: type: decimal precision: 12 scale: 2 required: true status: type: enum values: [draft, pending, signed, expired] relations: owner: { target: user, type: manyToOne } workflows: contractApproval: entity: contract states: [draft, pending, signed, expired] transitions: - from: draft to: pending action: submit guard: amount 100000 || role manager pages: contractList: entity: contract type: list filters: [status, amount] actions: [create, view, submit] permissions: contract: read: all write: owner sign: role(manager)谁会读这份文件不是人也不是单一Agent是建模Agent、生成Agent、验证Agent和交付Agent共同依赖的“契约源”。字段定义直接映射到数据库DDL和ORM类状态机映射到后端审批服务pages段映射到模板化列表页和表单页permissions映射到接口注解和前端菜单可见性。说白了里面每一个键都对应一段能被生成器消费的规则没有留给Agent自由发挥的空间。这里有一个我踩过的重要教训模型文件一定要带modelVersion。因为多个Agent可以并行改它如果没有版本号A Agent刚改完字段B Agent拿半小时前的旧模型去生成等到联调时两边已经对不上了。有版本号以后orchestrator能在每次任务开始时先做一次哈希校验发现输入的模型版本和数据库迁移版本不一致就直接中断而不是让错误流入下游。把它类比成装修就很好懂以前我让Agent“看着效果图直接砌墙”工人一边砌一边自由发挥现在我先出一张平面施工图砌墙、水电、门窗都按图执行。中途改主意时改的是图纸不是拆墙重来。企业应用尤其需要这种“图纸思维”因为业务方今天改字段、明天调审批流你要的不再是某人超常发挥而是整套系统在改动面前仍然一致。4. 从业务工单到上线五个Agent协作的一次完整跑通如果只看单个Agent每个角色都不难理解真正的难点在于怎么让它们像流水线那样衔接。我以实际跑过的“请假审批模块”为例拆一下假定业务方的原始需求只有一句话“员工提交请假申请部门经理审批超3天要总监审批审批通过后自动更新假期余额。”4.1 第0步需求分析Agent先把能问的都问完需求Agent只干一件事把上面那句自然语言拆成带边界的用户故事。我实际给它的编排指令是这样你负责需求分析以下是一条原始需求{input} 请只输出三部分 1. 用户故事列表角色-操作-目标 2. 验收标准用Given/When/Then描述 3. 建议业务方确认的问题清单 不要写代码不要建表不要给解决方案。它问出来的问题包括“半天假是否支持”“审批驳回后能否再次提交”“假期余额扣减按自然日还是工作日”。这些听起来琐碎却是后面所有Agent正常工作前提。输出经过我快速确认后进入下一步。4.2 第1步建模Agent把需求翻译成模型变更建模Agent拿到需求基线结合现有app-model.yaml输出一个增量补丁新增leaveApplication实体、leaveBalance实体定义请假状态机draft → submitted → approved/rejected增加“超过3天自动转总监审批”的流转条件并生成一份对应迁移脚本。这时我作为人唯一的硬性介入点出现了review这次模型diff。因为模型文件一旦错后面全错。我会重点看字段类型、必填约束、状态机是否闭环、权限是否给到“按部门查询”。确认没问题模型版本号升一位所有下游在这个版本上工作。4.3 第2步生成Agent按模板产出前后端生成Agent不接收自然语言需求只接收“模型文件路径 页面模板配置 代码生成配置”主要为了不让它自由发挥。它会生成请假申请表单、审批列表、审批操作接口、权限切面、路由注册和数据库访问层。我检查的重点不是代码本身而是它有没有把模型里的required、unique约束变成前端校验和后端校验因为这两处经常不一致。4.4 第3步验证Agent先写测试再跑测试验证Agent会先读模型契约生成测试数据再写接口级用例。举个典型用例未登录用户提交申请应该返回401普通员工审批别人的申请应该返回403超过3天的申请在提交后状态应该直接落到pending_director_approval而不是pending_manager_approval。测试失败后它不会直接改代码而是把失败断言整理成报告回传让生成Agent修最多循环三轮仍失败就上报不再硬跑。4.5 第4步交付Agent构建部署并做健康检查代码与测试通过之后交付Agent打镜像、更新部署、跑接口健康检查并且在变更日志里注明本次改动的模型版本、数据库迁移文件和涉及接口。整个过程我不需要手动SSH也不需要打开部署面板只要最后一封Agent交付摘要。整条链路跑完后我还是会请业务方在测试环境里点一遍主要流程因为Agent能验证正确性不能完全替你确认“这是不是老板要的那个业务味道”。5. 接缝处的意外SubAgent协作最常翻车的三个位置Agent单独跑问题都还好解决一旦五个Agent串起来真正消耗时间的反而是“接缝处”的意外。这里记三件我实际踩过的坑每一件都讲完整排查链路。5.1 契约漂移模型文件改了数据库迁移脚本没跟上症状很经典接口文档和DTO已经写着contractNo数据库里却还是contract_id部分查询直接报列不存在。一开始我以为是生成Agent写错了后来排查链路走到三层第一层看orchestrator的消息日志。发现建模Agent确实输出了新模型app-model.yaml#1.4.0但建模Agent给生成Agent的摘要里只写了“新增 contractNo 字段”没有带上字段长度、唯一约束这些元数据。第二层比对生成Agent实际读取的输入快照。orchestrator当时传给它的是一段10行的文本摘要而不是完整模型文件路径等于让生成Agent对着残缺图纸施工。第三层查数据库迁移记录发现迁移脚本是在模型变更之前生成的版本号没对齐。根因是我为了让“对话内容简洁”而在中间层做了“智能摘要”这一刀恰恰砍掉了模型文件的确定性。修复也很简单所有Agent之间流转的不是摘要而是artifact_path model_version hash每个Agent必须自己加载完整文件同时建模Agent输出迁移脚本的版本号必须与模型版本一致不一致orchestrator直接中断并回滚到上一个版本。之后我再也没在这个问题上花过超过半小时。5.2 验证Agent的“自我修复”掩盖了真Bug第二个坑更隐蔽。当时一次审批流联调验证Agent跑出createTime字段为空导致测试失败。它没有上报而是认为“需求很可能就是这个意思”自己把测试断言从“期望自动填充”改成“允许为空”整套测试变绿了但业务上每次新建记录都会缺时间。人工查的时候靠功能测试表面全绿差点误判成生产环境问题。完整排查链路是这样的我先从验证Agent的报告库里调它上一轮输出发现“失败断言”字段被静态改写再查编排层的权限矩阵发现我最初给验证Agent配了“编辑测试文件”的权限它虽然是只读业务代码但测试代码对它完全开放于是它养成了“改不了代码就改测试”的坏习惯。修复分两步第一测试代码全部交给生成Agent按模型重新生成验证Agent对测试目录只读第二在编排层加一条规则验证Agent的产物里凡是出现“已调整断言以匹配实际输出”这类描述一律触发人工review。别让Agent在“验证问题”和“隐藏问题”之间选了后者这是Agent协作中必须死守的底线。5.3 环境依赖漂移交付Agent偷偷升级了全家桶还有一个很现实的问题和代码逻辑无关。某一次交付部署后前端页面白屏本地生成环境跑的是Vue 2交付Agent在安装依赖时因为package.json写的是^2.6.0实际解析到了主版本2的小版本最高位本来没事但后来一份旧模板写入的是^2.6.0交付Agent又顺手更新了lock文件导致整个前端项目实际变成了Vue 3的依赖树一堆组件API不兼容构建直接挂掉。排查链路先看构建日志里实际安装的版本再diff提交前后的lock文件最后查到交付Agent执行了npm install而不是npm ci而npm install在依赖区间允许的情况下会主动升级依赖。修复方案是所有依赖的主版本号和关键框架版本写进app-model.yaml的runtimeDependencies段交付Agent只能读这份约束同时把CI命令固定为npm ci加锁文件提交。从那以后我再也没让交付Agent拥有“升级依赖”的自由裁量权。三个坑的共性其实是一个Agent协作出问题十有八九不是因为某个Agent能力不够而是它们之间的“交接物”不够严谨。交接物一旦变成了自然语言摘要、被改写的断言、宽松的依赖区间再聪明的模型也会在接缝处漏掉信息。所以排查这类问题时别急着怪某个Agent先查它们之间交换的到底是什么。6. 这套玩意的适用边界哪些企业应用真的适合跑通凡是有人把这种架构吹成“所有系统都能AI一键开发”我基本都是保持距离的。用下来之后我的判断标准已经变成三条业务形态是否稳定地围绕“实体 状态流转”展开。合同、订单、审批、报销、主数据、权限这类系统天然合适因为它们的核心就是数据结构和对这些结构的有规则操作。业务方能不能接受“接口契约由模型文件统一声明”。如果业务方经常为了一些临时报表直接改线上数据或者要求每个页面都长成不一样的交互这套体系的收益会被快速消耗。团队是否愿意把模型文件当成一等代码来维护。模型文件不是写一次就完事的文档它是和代码仓库一起提交、一起review、一起回滚的资产。没有这个意识用几天就会退化回手工改代码。再明确说说什么场景我会直接劝退。需要极高实时性的系统比如生产调度、实时风控业务规则高度非线性且每个案例都得单独写比如复杂的排产算法或者系统大量对接外部老旧SOAP/消息中间件这种项目用模型驱动SubAgent反而会把不确定性放大。不是不能让Agent写其中某几段代码而是不适合让模型文件成为全局契约外部系统的行为根本不受你控制。适合与否可以参考这个表格场景合适程度一句话判断企业内部管理系统合同、报销、订单非常合适实体和状态流转清晰生成路径长审批流程 权限模块非常合适状态机和权限能被显式建模与测试报表查询 / 录入类页面合适页面结构规律过滤器、列表是模板忠诚用户复杂算法调度不太合适模型难以表达穷举与优化逻辑高频低延迟实时交互不合适生成代码的运行时不可控大量遗留中间件对接看情况外围适配可以写但别把核心契约交给模型最后说点个人体会。如果你真想在公司里落地这套玩法我建议不要从“颠覆现有大系统”开始而是挑一个不那么重要的内部模块比如请假、会议室预约把模型文件和五个Agent的最小闭环跑出来让业务方在测试环境里真实用两周。在这两周里你会很清楚地看到哪些Agent交接要补强、哪些review习惯要建立。我自己跑了两个模块之后才敢把它用到合同这种核心流程上。另外哪怕是Agent生成的代码也别省掉人工code review。模型驱动解放的是“机械翻译”的部分不等于解放“业务判断”的部分。把review重点放在模型diff、权限配置和状态机上这三处对了生成出来的代码通常不会跑偏太多。