1. 为什么是“模型驱动 五大SubAgent”而不是一个“超级Agent”1.1 企业应用开发的真实痛点先说个我在交付项目时反复遇到的场景业务方提了一堆需求产品经理整理成几十页文档开发团队排期两到三周测试再压一周最后上线还要走变更流程。整个链路里真正“写代码”的时间可能只占三成剩下七成都在做需求澄清、方案评审、联调排错、文档对齐。LLM出现之后很多团队第一反应是“能不能让模型把整个项目干了”于是去做一个超级Agent什么都能干结果往往是对话到第五轮就开始上下文混乱生成的东西看着像样一编译全是错最后还不如人工来得快。我后来换了个思路不追求单个超级Agent完成所有事而是把企业应用开发拆成需求、架构、编码、测试、交付五个环节每个环节配一个专门的SubAgent用一个模型驱动的编排层把它们串起来。模型驱动不是说让大模型从头到尾自主决策而是让模型在每个环节里做“最擅长的事”——理解意图、生成方案、写代码、写测试、写文档——同时把工具调用、人工审批、质量门禁这些确定性逻辑放在Agent外部。跑通之后效果比单Agent模式稳定得多。1.2 五大职责切分背后的逻辑五个SubAgent的职责边界我是按一条软件开发流水线来拆的需求Agent负责把业务语言转成结构化的需求规格和验收标准架构Agent负责把需求转成技术方案、数据模型和接口定义开发Agent负责按模块生成可编译的代码测试Agent负责生成测试用例、执行测试并定位回归交付Agent负责构建脚本、部署配置和上线文档。为什么拆成这五个核心原因是每个环节对模型的输入输出要求差异太大。需求环节需要的是长文本理解、信息抽取和歧义澄清输出是结构化文档架构环节需要的是系统设计能力和约束感知输出是方案和图表编码环节需要的是代码生成和自检输出是diff和变更说明测试环节需要的是覆盖性思维和缺陷分析输出是测试报告交付环节需要的是命令编排和文档组织输出是可执行脚本和使用手册。把五个角色的System Prompt、工具集、上下文窗口、模型档位分开配置每个Agent都能在自己的领域里做到足够专注出问题时也能单独调试、单独回滚排查效率高很多。1.3 模型驱动在这个框架里的准确含义很多人听到“模型驱动”会以为是让模型自动决策一切实际上在企业落地中完全走不通。我理解的模型驱动是把模型作为分工协作中的决策引擎而不是全部流程的替代者。具体来说有三层第一层模型理解需求并产出结构化中间产物这是它最擅长也最稳定的能力第二层模型调用外部工具完成验证类工作比如让开发Agent生成代码后立刻调用编译器和静态检查工具而不是凭空自信第三层模型无法确定的地方主动抛出问题交给人工审批而不是猜测后继续往下走。打个比方这五个SubAgent像是一个施工队里的不同工种模型驱动就是工地上的调度系统每个工种都有自己的工具包和验收标准调度系统负责把上一道工序的产出传给下一道并设置质量检查点。真正决定项目能不能跑通的往往不是单个Agent的能力而是编排层的设计是否合理、每个Agent的产出是否符合下游要求、以及哪些节点必须卡人。2. 五大SubAgent的角色定义与Prompt设计要点2.1 需求Agent把业务诉求变成机器可执行的需求规格需求Agent是一切的起点。它的输入很杂可能是几句零散语音、一封邮件、一段会议纪要也可能是一个页面的截图描述。我给它设计了三个输出物需求说明、验收标准、边界假设。这个Agent的System Prompt里最关键的约束是“不要跳步骤不要替用户做决定”。它内部有一个澄清机制当原始需求里出现“快速”“好用”“智能化”这类模糊描述时会自动生成追问清单。比如对方说“要一个用户管理页面”Agent会追问“用户类型有哪些维度是否需要批量导入是否涉及审批流”这些追问不是模型凭空想的而是我在Prompt里内置了一个企业应用常见需求维度的检查列表。实测下来这个追问机制能把需求返工率降低一半以上。需求Agent的另一个特点是输出格式严格绑定JSON Schema。我要求它输出以下结构需求编号、需求描述、优先级、涉及角色、依赖系统、验收标准列表。每个验收标准必须写明“前置条件 操作步骤 预期结果”这样的结构直接喂给架构Agent时可以大幅减少后续的歧义解析成本。2.2 架构Agent在需求和技术实现之间架桥架构Agent拿到需求Agent的结构化输出后要做四件事选择技术栈、设计数据模型、定义接口契约、划分模块边界。这个Agent是需要挂工具的至少挂上依赖检索工具和代码仓库索引工具。为什么因为模型对依赖版本、库函数签名、当前仓库代码结构的记忆是不可靠的必须实时检索。我踩过一个大坑架构Agent在一版方案里设计了某个开源库的高级功能但那个库的版本在企业私有源里根本不存在。后来我给它在Prompt里加了一条硬规定“所有引用的依赖和框架版本必须先用工具查询确认存在性未确认的不得写入方案”。加了这条之后下游开发Agent的报错率明显下降。架构Agent的设计要点还包括上下文注入。企业应用开发离不开内部规范比如统一的返回结构、日志格式、权限模型。需要把这些规范以“架构约束”的形式注入Prompt。我给架构Agent设计了一个约束优先级原则安全约束 合规约束 性能约束 代码风格约束遇到冲突时按这个顺序取舍避免它在方案里自相矛盾。2.3 开发Agent从方案到可运行代码的转换器开发Agent的核心任务不是“写代码”而是“按架构方案写代码”。它接收架构Agent输出的模块列表和接口定义然后按模块逐个生成代码。我为它配置了独立的编码规范Prompt里面包含命名规范、注释要求、错误处理模式、日志埋点规范这些内容全部来自企业现有代码库的编码规约。实际运行中最有价值的改进是给它接了一个编译门禁。开发Agent每生成一个文件会先自动调用编译器或静态检查工具做一次自检自检不过就自己修修三轮还不过就上报人工。这个设计避免了“生成一大片代码但全是语法错误”的尴尬局面。我能给的建议是开发Agent的输出不要直接进主干先落到一个临时分支每个模块生成完都附上“变更说明 影响范围”这样人工review时不用从头读代码只看变更说明就能定位风险点。另外不要指望开发Agent一次生成完整业务逻辑反而让它在遇到跨模块依赖时先生成“接口桩 TODO标记”再逐个实现。模块间按依赖拓扑排序生成先底层后上层这个顺序能减少大量返工。2.4 测试Agent不止是生成用例还要会定位问题测试Agent在很多人的设计里只是“写单测”但我在实践中把它扩展成了“测试执行与缺陷定位”的角色。它要做三件事根据需求验收标准生成测试用例集执行测试并收集失败信息对失败用例做初步排查日志分析、堆栈分析、数据比对把排查结论附在缺陷报告里。测试Agent的Prompt里我会强调“用例覆盖需求而不是覆盖代码”。按代码覆盖率生成用例的坏处是模型容易写出一堆没实际断言的“假测试”。我要求它每个用例都必须对应一个或多个验收标准条目并给出“该用例验证的是哪条验收标准”的映射关系这样测试结果可以直接追溯回需求管理层看报告时非常直观。执行环节我用了一个轻量级的策略先是单测和静态检查通过后再拉起集成测试环境跑接口自动化。测试Agent发现失败后会自己去捞对应服务的日志把异常栈和请求参数一并带回缺陷报告。这一步设计看起来很重实际做下来省了大量的人工排查时间。2.5 交付Agent让成果真正可上线、可移交交付Agent在整个流程里的价值是最容易被低估的但它恰恰是“跑通”两个字的最后一道保障。它的职责包括生成Dockerfile或部署脚本、编写数据库变更脚本、生成配置说明、编写README和上线检查单。它读的是测试通过后的代码库以及架构Agent输出的部署拓扑。交付Agent的Prompt里要特别强调“环境差异”。同一个服务在测试环境和生产环境的配置项往往不同我要求它在生成部署配置时把所有环境相关的变量抽成占位符并提供.env.example模板同时在文档里专门开一节写“变更前必读”。这个Agent还要检查一个关键项数据库变更脚本是否有回滚方案。没有回滚方案的变更脚本我直接在编排层把它卡住不允许进入发布流程。五个Agent单看都不复杂但最关键的是它们之间的协议要定义得足够清楚。我建议把每个Agent输出的首行设计为“数据版本号”下游Agent先校验版本再消费数据这个机制能避免很多因数据格式漂移导致的“能用但不对”问题。3. 编排机制与完整实操流程3.1 编排层设计状态机 人工审批节点五个SubAgent是零部件编排层才是把它们组装起来的发动机。我在项目里用的是自研的轻量级状态机没有引入太重的工作流引擎核心原因是团队需要快速调试点位和自定义卡控逻辑。状态机的流转节点包括需求澄清 → 方案设计 → 模块开发 → 测试执行 → 交付构建每个节点都有三种终态通过、驳回、需人工干预。人工审批节点我设置了四个需求规格确认、架构方案评审、测试报告审核、上线变更审批。为什么是这四个因为它们在传统开发流程里就是必须由人拍板的地方。需求错了后面全白做架构错了返工成本极高测试报告决定了质量是否能放行上线变更涉及生产稳定。其他环节比如代码生成、单测执行可以由流程自动流转。3.2 一次典型跑通的完整链路拿我之前做过的一个“供应商对账系统”来举例。需求Agent先收到业务方一段语音会议纪要经过追问清单补全后输出了一份包含12条验收标准的需求规格。我给它的边界假设是“只做T1日对账不做实时”这个假设在人工审批节点被业务方确认。随后架构Agent基于需求规格输出了一个Spring Boot MySQL的方案数据模型包含对账任务表、差异明细表、处理记录表接口设计囊括了任务触发、结果查询、差异确认三个模块。这个方案里有一条依赖是“使用某国产数据库的分区特性”架构Agent查询了企业依赖源后主动替换成了普通索引方案理由是依赖源里没有对应版本。开发Agent按“基础服务 → 任务调度 → 对账引擎 → API层”的顺序生成代码其中对账引擎模块因为涉及复杂的金额匹配逻辑第一次生成的实现和架构方案里的算法不一致。在编译门禁阶段没报错但在测试Agent的集成测试里暴露了问题——差异金额分位数对不上。测试Agent把异常日志和出入参差异汇总成缺陷单编排层自动打回给开发Agent修复。修复后测试Agent重新执行这次关联到了映射用的验收标准并标记为通过。交付Agent在测试全绿后生成了部署脚本和上线检查单数据库变更脚本里写明了回滚SQL。人工审批时运维提了一个意见要求增加“对账任务执行超时熔断”配置。开发Agent补了配置项和对应的说明文档整个流程从开始到可上线一共用了三个半天。这个例子想说明的是五个Agent之间的配合不是“一个人连续干了五件事”而是每个Agent都在前一个Agent的产出之上继续工作并且有明确的校验节点模型的错误会在小范围内被隔离和修复。3.3 模型选型与上下文控制策略同一套流程里五个Agent对模型能力的要求是不一样的不需要全部用最强模型。我的经验是架构Agent和需求Agent用推理能力最强的模型因为这两个环节的输出质量决定了整个链路上限开发Agent用中等偏上模型重点看代码生成质量和长上下文保持能力测试Agent和交付Agent可以用性价比更高的模型因为它们的任务模式更固定且大量工作其实是工具执行模型只负责生成脚本和文本。上下文控制是非常容易被忽视的坑。企业应用的需求文档动辄几十页全部塞进Prompt会让模型在长文本里“迷失重点”。我的做法是分层压缩先把原始材料交给需求Agent做结构化摘要生成一份“需求线索树”再让下游每个Agent只读取自己需要的分支而不是把整个项目背景都灌进去。实测下来这个方法不仅省token而且输出一致性明显提升。3.4 结构化输出稳定性JSON Schema 双重校验五个Agent之间传输的数据全部走JSON结构化格式因此每一步都必须做校验。我在编排层封装了一个通用的“输出校验器”它做两层检查第一层是语法校验检查JSON是否完整、是否满足Schema定义第二层是语义校验比如必填字段是否为空、枚举值是否超出范围、引用ID是否指向已存在对象。这两层校验不通过时不会直接把数据传到下游而是生成一个“修复请求”返回到原Agent并附带校验器给出的具体错误原因。Model在收到修复请求后根据错误信息调整输出。实测中经过两个版本的重试结构化输出的成功率可以达到95%以上。如果重试两轮仍然失败编排层自动转人工处理避免无限循环消耗。4. 实操中踩过的坑与排查技巧实录4.1 架构Agent幻觉不存在的依赖被写进方案这个坑前面提过再展开说下解决过程。出现幻觉的根源是模型的知识库里依赖信息不完整它可能真的见过某个库的某个版本但那个版本从未引入企业私有源。我的排查思路是先把开发阶段报错的所有“找不到依赖”汇总反向核查架构方案里每条依赖的来源。解决方案分两步走第一步给架构Agent挂上依赖检索工具并要求它在写方案前查询确认第二步在编排层加一个“依赖存在性扫描”的自动检查点即使架构Agent漏检了这个扫描也会把问题拦在开发之前。这里有一条实际经验不要相信模型对版本号的记忆不要相信模型对API兼容性的判断工具能查的绝不靠模型猜。4.2 上下文窗口溢出长需求文档导致中间内容被忽略有段时间我直接把一份60页的SOW文档喂给架构Agent结果它输出的方案里遗漏了文档中间部分几条关于权限控制的要求。原因是模型在长上下文里对开头和结尾的内容保持得比较好但中间部分的细节容易丢失。排查后我做了两个改动一是需求Agent先对长文档做分层摘要把关键要求、约束、非功能性需求分别抽取出来形成需求线索树二是架构Agent在生成方案前必须输出“需求摘要复核”字段把从输入里理解到的重要约束逐条列出来与需求Agent的验收标准做一次交叉比对。这个“复核”步骤相当于强制模型把关注点拉回到关键信息上漏项问题解决了大半。4.3 开发Agent“自嗨”生成代码看起来对但编译不过开发Agent比测试Agent更容易出现“自信的错”——代码结构完整、注释清晰但一编译就报错。原因多是对类型定义、方法签名、框架用法的记忆偏差。我的做法是把编译门禁前置开发Agent每生成完一个模块的代码包编排层立即拉一个隔离容器执行编译和静态检查。还有一个细节是编译日志要给模型回传。我原来的设计是只告诉它“编译失败”模型经常瞎猜原因。后来改成把编译器的完整错误输出和对应代码片段一起打包回传模型基于实际的报错信息修复成功率提升非常明显。如果你要用这套流程建议在开发Agent的Prompt里写清楚“你有权使用编译器反馈迭代代码直到编译通过。编译失败不是失败无法修复才是失败。”4.4 测试Agent的误报与漏报测试Agent最典型的两个问题误报是生成了大量没有断言的“假测试”跑出来绿油油一片但没有验证任何真实逻辑漏报是测试用例没有覆盖到核心业务规则集成测试接口测了但关键的数据校验分支没测到。我针对这两个问题的排查方法分别不同。误报靠“用例-验收标准映射”来拦截没有映射关系的测试用例直接丢弃漏报靠变异测试思路来解决我让测试Agent对核心业务方法做几个“故意改错”的变异体看现有用例能不能把它们检测出来。如果某个变异体没被杀掉说明测试覆盖有漏洞自动补充用例。这个设计一开始看起来工程量不小但实际复用之后质量和稳定性收益远超成本。4.5 常见问题速查表问题现象常见原因排查方向快速止血方案下游Agent拿到数据后报解析错误上游输出的JSON结构变了检查最近的Agent Prompt或Schema改动开启输出校验器的Schema版本比对开发Agent反复改但编译不过模型缺少编译错误上下文确认是否回传了完整编译器日志手动回传日志并触发一次修复架构方案里出现不存在的依赖模型依赖记忆不准确检查依赖扫描记录启用依赖检索工具并重新生成方案测试用例全绿但需求有问题用例断言之力或覆盖偏差检查用例与验收标准映射执行变异检测补漏流程在某个节点长时间卡住模型重试次数耗尽或人工审批未处理查看编排层状态机日志转人工接管并保留中间产物需求Agent漏掉关键约束长上下文丢中间信息检查需求线索树是否覆盖原文档用分层摘要重新抽取交付脚本在某些环境直接失败忽略了环境变量差异检查配置项是否都被抽成占位符补充.env.example并重新生成5. 企业落地要额外考虑的四件事5.1 人工审批节点不应该省我在框架里保留的四个审批节点每一个都是基于“模型没那么可靠”的认知来设的。在这个领域里最大的风险不是流程跑得慢而是流程跑得很快但方向是错的。需求规格确认是业务方必须看的架构方案评审是团队技术负责人必须把关的测试报告审核是质量负责人签字放行的上线变更审批是运维和执行人确认的。如果你压缩掉这些节点短期看效率高了很多但一旦出了问题追责和返工的成本远高于省下来的那点时间。我见过不止一个团队把Agent自动化率当作目标结果上线事故频发最后还是把审批节点加回来了。5.2 可观测性比自动化率更重要五个SubAgent协同跑下来会产生大量中间产物需求分析、架构方案、代码包、测试报告、部署脚本。我要求每个环节的产物都落盘保存并且记录对应的输入数据版本和模型版本。这样做的好处是当下游发现问题时可以像回溯代码提交一样回溯整个决策链。具体记录哪些信息我建议至少包括原始需求文本或摘录、需求Agent的追问记录、架构方案的推理过程摘要、开发Agent每次编译失败的日志、测试Agent的输入输出、人工审批的操作记录。这些数据除了定位问题还能用来持续优化Prompt。比如我发现某个环节的修复率长期偏高就会去翻历史记录找出模型在哪个环节、哪种输入模式下最不稳定然后针对性地补约束。5.3 知识库与企业上下文注入纯靠Prompt模板撑不起企业应用开发。企业内部的接口规范、安全红线、编码约定、历史架构决策、已有系统清单都是模型不知道但必须遵守的信息。我把这些信息整理成三类知识库静态规范库编码规范、接口规范、动态索引库公司内部依赖、现有服务列表、历史决策库架构评审记录、常见方案权衡。根据Agent的角色不同在启动时注入对应的知识子集而不是全部塞进去。模型驱动的另外一个关键点是私有化部署。企业应用开发里的代码和文档数据很多都涉及内部业务逻辑不能随意传到外部模型服务。我建议这部分走私有化部署或者专用API通道确保数据不出内网的同时还能在推理链路里挂载上述知识库。这一块不这么做后续上线审计环节一定会出问题。5.4 渐进式替换先做辅助再做自动化最后说一下落地节奏。不要一上来就追求“全流程无人工自动化”那样既不可控也难培训。我推荐分三步走第一步每个Agent作为独立辅助工具上线比如先让测试Agent帮忙生成测试用例人工审核后使用这时候收益是最直接的第二步打通两个相邻Agent的链路比如需求到架构在这个范围内跑协同第三步补齐测试和交付节点整个流程再尝试自动化流转。实际项目里第一步跑一到两个迭代第二步跑三四个迭代第三步再逐步放开。这样团队对每个环节的信任度是逐步建立的一旦某个节点效果不好回退范围也有限。“跑通”这两个字的含义不是“一次成功”而是“能稳定复现、能持续改进”。在我个人实际操作中最大的体会是这套框架的价值不在“Agent”本身而在你如何定义每个Agent的边界、如何设置它们之间的校验点、以及什么时候坚决拉人进来。模型驱动的Agent流程不像自动驾驶更像辅助驾驶——方向、路线、异常处置都还在人手里模型帮人把最花时间的路段跑完。如果你想在企业里搞Agent应用开发先别急着追大模型的热点把自己团队的开发流程拆解清楚再考虑让模型切入哪一层这样反而更容易见效。