1. 项目背景与整体设计思路1.1 为什么用“模型驱动多Agent”来做企业应用开发先说结论做企业应用开发最难的不是写代码而是“把需求说清楚”。业务方拿过来的需求十个里有八个是零散的某张报表要加字段、某个流程审批节点要调整、某个老系统的数据要迁出来。这些需求翻译成技术方案要过一道手翻译成代码又过一道手每过一道手都会损耗一部分信息。传统开发模式下这三道手靠的是“人肉传导”——产品经理写PRD、开发看PRD写代码、测试对着需求文档点页面。人一多理解偏差就来了返工自然也跟着来。今年我在做内部系统重构的时候开始尝试用“模型驱动多Agent”的方式把这套流程跑起来效果比预想中好不少。先说清楚这里的“模型驱动”是什么不是一个模型在聊天框里回答你“帮我写个登录页面”而是让模型直接驱动整个开发流程中的多个角色——它既是需求分析师也是架构设计者还是写代码的工程师。要实现这种角色切换光靠单个Prompt是不够的需要把不同的系统提示词、上下文窗口、工具调用权限拆成多个独立运行的Agent实例这就是标题里说的“五大SubAgent”。这五大Agent分别负责需求分析、架构设计、编码实现、测试验证、部署运维。拆成五个而不是一个或十个是因为企业应用开发的完整链路恰好就是这么五段每个Agent都有自己的上下文边界和输出规范模型在切换角色时不用背着上一段的大量对话历史跑精确度和稳定性都会好很多。1.2 五大SubAgent的职责边界与协作关系这五个Agent不是各干各的它们的协作关系是典型的“流水线反馈环”。好处在于如果有一步产出不达标可以立刻回流到上游重新生成而不是一头扎进细节里越走越偏。Agent核心职责输出物下游消费方需求分析Agent拆解业务需求补全边界条件结构化PRD架构Agent架构Agent选定技术栈设计表结构和接口技术方案文档编码Agent编码Agent按模块生成业务代码可运行的代码提交测试Agent测试Agent生成测试用例、执行回归测试报告编码Agent回流部署Agent容器化、发布、监控检查部署记录运维人员其中测试Agent和编码Agent之间是回流关系测试跑挂了把报错信息带回给编码Agent重新修这个反馈环是整个体系能跑通的关键。需求Agent和架构Agent之间则是单向传递PRD定稿后不再频繁改动否则后面所有环节都不稳定。我自己粗算过一笔账一个中等复杂度的业务模块比如订单审批流调整加导出过去从需求澄清到联调完成大概要4到6天人肉沟通时间占了大半。换成这套流程后模型把PRD到代码的中间环节压缩到了几小时人工介入点主要是需求确认、架构评审和代码抽检三处。时间节省大概是六成左右这个数据在我的实际项目里是成立了的。2. 五大SubAgent的配置解析与Prompt设计要点2.1 需求分析Agent怎么把模糊需求变成结构化PRD这个Agent是整套流程的地基。需求分析做不好后面架构和编码全跟着歪。企业业务的真实需求往往带着强烈的口语化特征——“咱们那个客户列表能不能加个筛选”“导出的时候要按部门权限来”——这两句话如果直接甩给模型它能给你生成代码但大概率是错的因为需求本身缺了字段定义、缺了权限层级、缺了交互逻辑。需求分析Agent的Prompt核心要让模型干三件事第一把零散描述转成“用户故事验收标准”的格式。我会在系统提示里显式要求输出包含“角色-操作-预期结果”三个要素的表格比如“作为销售经理我可以在客户列表中按行业筛选预期结果是仅显示所选行业的客户数据且筛选条件可组合”。第二补全缺失的边界条件。企业系统最怕的是“未定义行为”像分页方式、排序规则、导入模板哪几列必填、去重逻辑是什么业务方默认你都知道但AI不知道。所以我在Prompt里会加一条对每个功能点列出一个“未定义项检查清单”逐项说明缺失的信息。这一步在实践中验证效果很好等于让模型替你去问业务方问题。第三标记非功能需求。权限、性能、审计日志这些不做不会立刻报错但上线后迟早出事。我见过不止一次AI生成的代码功能没问题但没写操作日志最后审计过不了。所以需求分析Agent的Prompt里明确要求对每个用户故事标注涉及哪些角色权限、需要写哪些审计日志、性能预期是什么。实际操作中需求Agent的输出一般还要人工做一轮裁剪——生成的PRD经常过于啰嗦粒度细到页面按钮级别反而拖慢后续架构设计。我习惯把PRD里触发流程性的内容留给架构Agent页面级细节先砍掉。2.2 架构Agent从PRD到技术方案如何约束模型不乱选型架构Agent的输入是需求Agent的PRD输出是技术方案。这个环节最容易翻车的地方在于模型会根据训练数据里的“主流方案”来选型但企业系统往往受制于现有技术栈。比如你公司里全是Spring Boot的传统服务AI生成的方案可能是Node.js Serverless方案本身没错但落不了地。所以架构Agent的Prompt里必须带上“约束条件”这个明确段落我通常包含这几类强制技术栈后端必须用Java 17 Spring Boot 3.x数据库必须用MySQL 8禁止引入新的消息中间件模块边界明确哪些是已有模块复用哪些是新建模块新建模块不能反向依赖老模块的内部类数据规范主键策略、时间字段统一用datetime、软删除标记、逻辑外键还是物理外键把这些约束喂给架构Agent后它输出的技术方案内容会务实很多表结构设计、接口路径与出入参定义、服务分层的类职责划分。另外我会在Prompt里强制要求“每个设计决策列出一个备选方案和一个选择理由”这样代码评审时有个依据也防止模型拍脑袋乱选。这里还有一个细节值得分享架构Agent的输出最好限定为“文档建表SQL接口JSON示例”三件套而不是让它直接写业务代码。一旦让它在方案阶段就深入代码容易出现“方案写一套、代码跑另一套”的割裂。我的做法是方案定稿后编码Agent再接手二者上下文是隔离的。2.3 编码Agent多模块并行生成与上下文管理编码Agent是整个体系里参数量消耗最大的角色也是最容易出现上下文爆炸的地方。企业应用的单个模块动辄几百行代码如果让一个编码Agent从头到尾扛一个完整服务它会越写越乱——开头定义的工具类到后面忘掉了重新定义一遍前面做了的参数校验后面调用的地方跳过了校验。我的解法是按“模块”而不是按“项目”来实例化编码Agent。比如订单模块建一个编码Agent实例用户模块建另一个两个实例共享同一份架构方案上下文但各自只关心自己的代码范围。每个Agent内部的语境分成四块系统提示角色定义与代码规范、架构摘要表结构、接口定义、模块边界、当前任务描述、最近一次的运行反馈。这样单个Agent的上下文窗口压力小了很多实测上下文溢出报错率降低了至少一半。编码Agent的Prompt里还应该包含“代码产出规范”这些是我踩过坑后确定的硬性要求每个类必须写类注释说明职责、输入输出、依赖的Service公共方法必须做参数校验非法入参抛BizException而不是裸的NullPointerException禁止在Controller里写业务逻辑只做参数绑定和调用转发所有外部IO数据库、Redis、HTTP调用必须捕获可预期异常并打日志这些规范直接写进Agent的系统提示词里模型输出时会稳定遵守。但它也偶发“漏掉异常处理”的情况所以不能完全依赖提示词后面还要靠测试Agent兜底。2.4 测试Agent不只是生成用例更是开发的另一半我最初觉得测试Agent就是“AI写单测、人来看报告”实际用下来发现它的价值远超这个定位。它最大的作用有两个一个是在编码Agent交代码后做冒烟检查另一个是在重构时做回归保护。测试Agent的Prompt侧重于“业务覆盖”而非“代码覆盖率”——模型自己生成的测试用例天然会往“代码覆盖率好看”的方向走比如测一堆getter/setter但对业务路径的覆盖不足。所以我在提示词里明确要求针对PRD里的每个验收标准至少生成一条对应测试用例并在报告中标注覆盖到的是哪个验收点。这样一来测试报告的可读性高很多业务方也能看懂“哪块功能被验证过了”。具体的做法是测试Agent读取PRD和编码Agent的代码变更列表然后在测试环境里跑两类动作接口级测试调用后端API断言返回结构和关键字段值场景级测试模拟用户在页面上的一连串操作流程登录→进入订单列表→筛选→导出一页它的输出是测试报告有用例说明、有执行结果截图、有失败时候的调用链日志。如果遇到失败这份报告会直接回流给编码Agent编码Agent根据日志修代码修完再回到测试Agent验证。这个循环通常需要跑两三轮才能全绿但每一轮修复的速度都比人肉排查快得多。2.5 部署Agent容器镜像、环境差异与发布回滚部署Agent是我后期加进来的起因是一次“本地跑得好好的一上测试环境就白屏”的惨剧。排查了大半天发现是服务发现配置里写死了localhost。人肉部署流程里这种环境差异问题最难抓所以我把部署也交给Agent去管。部署Agent的核心能力是“环境感知”——它的Prompt里包含各个环境的差异清单数据库地址、Redis地址、文件存储路径、日志级别配置在打镜像、启动容器前它会自动替换配置模板中的占位符避免环境串配置。企业应用的发布流程我这边是标准化成了五步构建镜像编码Agent提交代码后触发Maven打包、Docker构建、推送私有仓库检查就绪启动容器后做健康检查调用health接口确认服务注册成功灰度发布先在预发环境发布跑一轮部署Agent自带的冒烟用例正式发布预发验证通过后切生产生产实例按批滚动更新回滚预案如果发布后监控指标异常自动执行回滚到上一版本镜像这个流程跑顺之后发布新版本的时间从原来的人工半小时缩短到十几分钟而且操作记录全程可审计出问题能直接定位是哪一步造成的。部署Agent目前还做不到全无人值守——生产环境的变更审批依然走人工流程——但重复性的构建发布动作已经完全可以自动化了。3. 实操过程全记录一次订单审批流改造怎么跑通全部五个Agent3.1 阶段一PRD生成与人工确认我用一个真实项目来说明整套流程怎么串起来的。需求是“改造采购订单审批流支持按金额分档审批且二档以上审批需要抄送财务”。先把需求原文丢给需求分析Agent它自动补全的PRD里除了常规的用户故事还额外列了几个我之前没注意到的边界同一订单被驳回重新提交后审批档位是按提交时金额计算还是按首次提交时金额计算金额正好卡在边界值15000元时归入上一档还是下一档审批抄送人是否包含发起人本人这三个问题提得非常到位前两个是真实的业务决策点需要业务方拍板。我拿着PRD找业务方确认了五分钟就定了规则后续开发完全没返工。3.2 阶段二架构方案评审与表结构落地架构Agent拿到定稿的PRD后输出的方案里包含了三块内容审批流表新增字段的设计current_amount、approval_tier、cc_user_ids、状态机流转图提交→金额判断→一级审批→二级审批/直接通过、接口定义submitOrderApproval、approveOrder、rejectOrder、queryApprovalDetail。这个方案整体方向是对的但我在评审时发现它漏了一个关键点审批人变更操作没有对应的处理流程。我补充了一条“审批中订单被改派审批人后原有待办任务要置为已转办”。改完方案后架构Agent同步更新了表结构和接口定义再交给编码Agent。这一步我用了市面上可用的AI编程插件辅助做接口联调文档——编码Agent生成好Controller和Service后插件可以直接识别路径并生成OpenAPI格式的调试页面省掉了手动写文档的环节。后续测试Agent用的接口信息也直接来自这个文件三方对接口定义完全一致不会出现“开发以为参数叫amount、测试以为叫totalAmount”的接线事故。3.3 阶段三编码Agent并行开发与测试回流编码阶段我是按模块拆给两个编码Agent并行跑的一个负责审批流状态机与数据库操作一个负责审批页面接口与待办列表。两个Agent共用同一份架构方案和表结构但上下文互不干扰。第一个Agent生成的审批状态机代码质量不错状态枚举、流转表、异常分支都覆盖到了。但第二个Agent的代码出现了问题它把审批记录的查询SQL写成了不带分页的全量查询数据量一上来必然撑不住。这个是在测试Agent跑“待办列表加载”场景时暴露出来的接口返回提示有性能风险测试报告直接带着调用链日志回了编码Agent。编码Agent拿到失败日志后自己做了修正——加上了分页参数和索引建议。修完再回测试Agent跑了一遍这次就全绿了。3.4 阶段四部署发布与线上检查代码全部合入主干后部署Agent接管发布流程。镜像构建、预发部署、冒烟测试都是自动的。预发冒烟测试包含一条完整的端到端用例创建订单草稿→提交审批→断言按金额跳到对应审批档位→模拟驳回→再次提交→确认抄送人包含财务角色。这条用例跑通后部署Agent才放行到生产环境。生产发布的过程我全程没有登录服务器只看了部署Agent输出的发布记录。历史经验里发布环节最爱出问题的是数据库变更这次架构Agent生成的表结构变更SQL被人工审核了一遍确认兼容存量数据后由DBA执行然后发布的代码正好接上。整体流程跑得比较顺从需求发起到生产上线一共用了一天半。4. 常见问题与排查建议4.1 上下文窗口管理从源头避免“AI失忆”多Agent协作最常见的问题不是模型能力不够而是上下文管不住。编码Agent写长代码写到后面会出现前面定义过的常量重新定义一遍、或者后面调用的方法签名对不上前面的情况本质是上下文窗口被大量对话历史占满早期关键信息被挤出去了。我的处理策略有三层第一层每个Agent的上下文只保留“必要的最小集”。比如编码Agent不需要读完整的PRD原文只需要读架构Agent提取出来的“表结构接口定义业务规则”部署Agent不需要读代码逻辑只需要读构建脚本和环境配置。第二层定期清理Agent会话中的中间过程对话。我把每个Agent的核心输出都做成了结构化的“当前状态”存储新任务启动时只加载当前状态而不是让模型重新“回忆”之前的对话。这相当于给Agent做了“状态持久化”不会因为对话长了就丢信息。第三层大任务拆成小步骤一件件走。编码Agent不要求一次生成完整模块而是按“实体类→Mapper→Service→Controller”分步生成每步单独对话。虽然调用次数变多了但每一步的上下文窗口都很小输出质量比一股脑生成的稳得多。4.2 幻觉代码与验证体系的兜底这是“AI生成代码”绕不开的问题模型遇到不知道的技术细节会一本正经地编一个不存在的API。常见的幻觉包括不存在的方法名、想当然的配置项、过时的依赖版本号。我的应对思路是“不阻止幻觉但让它无处遁形”。测试Agent是幻觉的捕手它跑真实接口、断言真实返回结构如果Agent解读接口时编了一个不存在的返回字段测试用例会直接断言失败。另一个有效手段是禁止编码Agent使用模型训练时段的旧版本依赖——我在编码规范里写死了依赖版本号并且构建时会做校验版本号不匹配直接失败从根上杜绝了“懒得查版本就编一个”的情况。这种痛点如果完全人肉去查每个模块要多花不少时间而测试Agent的反馈机制基本能拦截九成以上的幻觉代码。4.3 企业安全合规的底线怎么守企业应用不同于个人项目“能跑就行”的标准远远不够。我在多Agent流程里设了几条硬性安全红线所有Agent的提示词里都有任何涉及数据导出的功能必须走权限校验不允许悄悄绕过鉴权修改或删除数据的接口必须在审计日志中记录操作人、操作时间和变更内容数据库操作必须使用预编译参数严禁字符串拼接敏感字段手机号、身份证号、银行卡在日志中必须脱敏这些红线靠提示词约束靠测试Agent验证。测试Agent生成用例时会专门覆盖“无权限用户访问敏感数据”的场景保证权限控制不是停留在纸面上。如果Agent为了“方便演示”把鉴权逻辑跳过了测试用例会直接报失败。4.4 人工介入的三个关键控制点多Agent流程不是扔给AI就跑而是需要人在关键节点做决策。根据我这段时间的实操经验下面三个节点不建议省第一个是需求分析Agent的PRD定稿。AI补全的需求边界一定要业务方过目确认“AI认为合理”不等于业务认可。第二个是架构Agent的技术方案评审。技术选型、表结构设计这些影响深远的东西不能只看“能用”要确认它和存量系统适配、不会引入维护成本。第三个是编码Agent提交代码后的抽检。我会随机挑20%的类做一次Code Review重点看不变量逻辑和权限校验部分。AI生成的代码整体可靠性是高的但它的“最优解”往往不是你的“业务最理解”人肉抽检能弥补这个问题。5. 一些实操后的个人体会练了几个月之后我对“模型驱动多Agent”跑企业应用开发的真实感受是它的价值不在于“取代人”而在于“让人只做重要的判断”。以前开发流程里大量时间花在了低价值的翻译工作——把业务话术翻译成PRD、把PRD翻译成接口、把接口翻译成代码。这些事AI做得又快又稳真正核心竞争力还是人对业务的理解和对系统边界的把控。现在每接到一个新需求我会下意识去想需求清楚吗边界条件是什么哪些地方需要业务方拍板想完这些问题后把答案扔给Agent跑起来一天后就能看到可以评审的东西。这套流程对中小型团队特别有用不要求改变现有的技术栈也不要求团队人人会写复杂的提示词只要按我刚才说的五个Agent模板配一遍就能直接跑起来。最后提一个实在的建议如果准备尝试不要上来就奢望“五个Agent从需求到上线一条龙全自动”。更好的切入路径是从需求分析Agent或测试Agent单一环节开始——这两个角色风险低、见效快等团队跑顺了再逐步把编码、部署Agent加进来整个链路自然就通了。这条路我走了一遍效果值得。