企业官网建设流程全解析

如果你混过几个 AI 开发相关的技术群，应该能感受到一个非常明显的反差：一方面大家讨论 Agent、工作流、模型能力时热火朝天，另一方面，把 AI 真正用在一个企业内部系统的开发上，却很少有人能说清到底怎么落地。我自己从去年开始一直在做企业应用开发，陆续把几套内部系统从传统写代码迁移到“模型驱动 + 多 SubAgent 协作”的模式上来，踩了不少坑，也沉淀了一套很稳定的打法。

这篇就专门讲这套打法。我会从单个 Agent 为什么撑不住企业级业务讲起，然后拆解五个 SubAgent 各自负责什么、相互之间怎么交接，再用一个真实系统的完整例子把需求到上线的链路一步步跑给你看，最后分享几个我实战中反复踩到的坑和应对方法。适合正在用 AI 辅助开发、但被需求漂移、代码不可控、测试无效这些问题困扰的团队参考，也适合刚接触 SubAgent 想找一个落地入口的开发者。

1. 为什么一个超级 Agent 跑不动企业应用

1.1 单 Agent 模式在企业项目里的三个断层

最早我做 AI 辅助开发的时候，思路简单粗暴：把需求文档丢给一个能力很强的大模型，让它直接生成后端工程，再让它自己补测试、补部署脚本。跑几个小型 Demo 的时候确实爽，尤其是 CRUD 类的接口生成，速度比手写快一个量级。但一旦把真实的业务约束加进来，问题就接二连三地冒出来。

第一个断层是上下文断层。企业应用和玩具项目最大的区别，在于业务规则的数量级完全不同。一个中等规模的报修系统，会有几十张业务表、几十个接口、复杂的角色权限关系、状态机流转、并发控制、消息通知。单个 Agent 的上下文窗口再大，也不可能把完整的业务规则始终装在脑子里。它写着写着就开始“漂移”，一开始还记得“工单按优先级排序”，写到第五个接口就把排序逻辑扔了，甚至为了凑接口把原本的业务约束悄悄改掉。这种漂移在小项目里不明显，项目越复杂越致命。

第二个断层是验证断层。代码生成出来，谁来确认它是对的？让同一个 Agent 自己生成代码、自己写测试，本质上就是考生自己批自己的卷子。它经常因为测试代码写得太“配合”而发现不了真实业务逻辑的问题，尤其是异常路径、并发冲突、跨服务调用这些场景，几乎等于裸奔。

第三个断层是角色断层。企业应用开发从来不只等于“写代码”。需求的澄清、架构的决策、质量的把控、发布运维的准备，每一件事都需要不同的专业视角。单 Agent 看起来什么都会，实际上每个环节都只做到“差不多”，尤其是让它在“业务分析”和“代码实现”之间来回切换的时候，经常给出自相矛盾的结论。我遇到过一次，它在前一轮分析里说“员工提交报修后不可撤回”，后一轮写代码时却又默认“员工可以随时撤回”，而且没有任何解释。

1.2 把大模型当编排中枢，而不是万能引擎

后面我换了一套设计哲学：不要再让一个大模型包打天下，而是把它当作一个“编排中枢”，由它来调度若干专门的 SubAgent，每个 SubAgent 只负责某一个开发环节。这就是“模型驱动 + SubAgent”的核心思路。

那它和普通的“多 Agent 互相聊天”有什么区别？我的理解是：多 Agent 协作往往强调多个模型平级对话，互相提问、互相补充；而模型驱动的关键在“统一调度”。核心模型负责把整个开发任务拆解成阶段性的子任务，分派给对应的 SubAgent，然后逐一校验产出、汇总结论。SubAgent 不是平等的聊天对象，而是有明确职责边界、被统一管理的工作单元。打个比方，这不是一群同事开无休止的会议，而是 CEO 定方向、分任务，各职能部门在自己的边界内执行，再向 CEO 汇报结果。

这样设计带来三个立竿见影的好处：

• 每个 SubAgent 的提示词和技能可以做得非常聚焦，不用在“需求分析”和“写代码”之间横跳，输出质量明显更稳定；
• 上下文可以分段管理，每个 SubAgent 只接收与自己相关的信息，从根本上缓解上下文漂移；
• 任何一个环节出错，可以单独重跑、单独替换，不需要把整条流水线推倒重来。

2. 五大 SubAgent 的分工边界与协作协议

2.1 五个角色各自负责什么、产出什么

我在这套体系里，把企业应用开发拆成五个 SubAgent，对应成熟研发团队里需求、架构、开发、测试、运维五个岗位。他们共享一个模型底座，但各自的提示词、输入输出格式完全独立。

这里尤其要说一下需求分析 SubAgent 的价值。大多数人在搭建 Agent 开发流程时会忽略它，觉得直接从写代码开始更快。但恰恰是它帮我挡掉了大量“写完后返工”的悲剧。它会把“我们要做个报修系统”这种模糊的话，拆成角色、流程、规则、验收标准四个维度的结构，把需求真正变成后续环节能执行的东西。

2.2 SubAgent 之间的“交接语言”：结构化产物

很多人搭建 SubAgent 失败，不是单个 Agent 能力不够，而是代理与代理之间的交接环节信息丢失、格式混乱。你想，如果 A 代理输出的是长篇大论的自然语言，B 代理在理解时必然会漏掉细节；如果更糟的是 A 代理输出的是口头约定，B 代理可能还要反过来再猜一遍。

所以我给每个 SubAgent 定义了严格的“输入-输出契约（IO 契约）”。所有关键交接物都必须是结构化文档，而不是自由文本。比如：

• 需求分析 SubAgent 的输出必须包含编号、用户角色、业务规则、验收标准四个字段，其中核心业务规则单独提炼，排在文档开头；
• 架构设计 SubAgent 的输出必须包含模块清单、数据表清单、API 端点清单三大部分，每个 API 端点必须标注请求结构、响应结构和权限要求；
• 代码实现 SubAgent 只读取架构设计输出和需求规格，禁止自己重新推断业务规则，遇到规则模糊必须向上游报错而不是猜；
• 测试 SubAgent 的输入是代码产物加上需求验收标准，生成用例时必须逐条标注对应的验收标准编号，保证“每条标准都有用例跟踪”；
• 运维 SubAgent 的输入是最终代码和架构设计中的部署约束，输出部署检查和上线清单，要求逐项可核对。

这套 IO 契约设计好之后，SubAgent 之间就不再是“自由聊天”的关系，而是“流水线上下游交接工件”的关系。每个工件有固定格式，字段清晰，便于校验，也便于出问题时定位到具体环节。这是整套方案里最值得抄作业的部分。

2.3 为什么五个而不是三个或七个

也有人问我，为什么要设五个 SubAgent，不能少一点吗？我的答案很简单：这五个环节刚好对应软件交付中无法合并且容易被验证的五个决策点。

需求分析如果不独立出来，它会被后续的代码实现吞掉，导致业务规则被“顺着代码逻辑悄悄改写”；架构设计如果不独立出来，代码实现就会自由发挥，技术栈和模块边界必然失控；测试如果不独立，代码 Agent 的自测永远是“自己人查自己人”，查不出问题。把五个环节拆开，本质上是把软件开发这个大问题分解成五个可以分别监督、分别验证的小问题。

而超过五个也不是不行，我只是不建议一开始就把链路设计的过于复杂。以企业应用的复杂度，五个 SubAgent 已经能把端到端链路覆盖完整，且每个环节的产出物都足够聚焦。等团队跑顺了，再拆出更细的专项 Agent 也不迟。

3. 完整案例：从“一句话需求”到“可部署系统”

3.1 需求分析：把含糊的一句话拆成可以验收的规格

光讲架构太抽象，我拿一个真实跑过的案例来演示：开发一个“员工自助报修平台”。业务不复杂但足够完整：员工登录后提交报修单，填设备信息和故障描述；管理员在后台看到所有报修单，认领并处理，更新状态；系统要发通知给相关人，可以用站内信加邮件。

扔给需求分析 SubAgent 的原始输入就是一句原生态的话：“我们要做一个报修系统，员工报修，管理员处理，得有个通知功能，最好能记录处理流程。” 就这么点信息。

需求分析 SubAgent 拿到后的第一件事是拆解用户故事，第二件事是对模糊的地方生成问题清单。它列出的问题包括：

• 员工提交报修单后，是否可以撤回？如果可以，在什么状态之前可以撤回？
• 员工需要看到处理进度吗？是只看到状态字段，还是能看到处理过程的详细记录？
• 管理员按什么维度筛选报修单？优先级由谁定义？
• 通知是实时触达，还是按天汇总？

我把这些问题根据真实业务逐条回答，然后它输出了一份结构化需求规格，核心部分长这样：

这一步是整套链路的地基。需求规格一旦完整，后面所有环节都围绕着它展开，任何偏离都可以追溯到具体某一条规则，而不是一笔糊涂账。

3.2 架构设计：把业务规则翻译成系统和数据模型

架构设计 SubAgent 拿到规格后，第一件要做的事是确认技术栈。这一步我不会让它完全自由发挥，而是给定一个约束范围：后端用 Java + Spring Boot，数据库用 MySQL，前端用 Vue 3，部署用 Docker Compose。这个约束是出于现有团队维护能力的考虑，避免它选一个所有人都不会维护的新框架。

在技术约束明确后，它输出的关键产物包括：

• 模块划分：用户模块、报修单模块、通知模块、后台管理模块；
• 数据表：员工表、管理员表、报修单表、状态流转记录表、通知记录表；
• 核心接口：POST /api/repair/orders 提交报修单、POST /api/repair/orders/{id}/cancel 撤回、GET /api/repair/admin/orders 管理员查询列表、PATCH /api/repair/orders/{id}/status 状态流转。

架构设计的价值，在这时体现得最明显。比如“员工只能查看自己的单据”这条需求，架构层面对应的决策是“所有查询接口必须从当前登录上下文获取用户身份，并在 SQL 查询条件中强制带上”；“接单后不可撤回”对应的是“状态机在待处理状态才允许 cancel 操作”。业务规则一旦落到架构决策层面，就变成代码实现可以直接执行的指令，不再依赖写代码的 Agent 自己去理解。

3.3 代码实现：在清晰契约下把逻辑翻译成工程

代码实现 SubAgent 的输入非常干净：需求规格 + 架构文档 + API 契约。它不需要猜任何业务规则，只需要把已经定好的逻辑翻译成可运行代码。

以报修单状态流转为例，它会严格按照“待处理 → 处理中 → 已完成”的状态链条实现，同时加上校验：如果尝试从“已完成”流转到“处理中”，直接抛出业务异常并返回错误信息。对于撤回逻辑，会先判断单据当前是否处于“待处理”，如果不是则拒绝操作。

除了业务代码，它还会顺手补齐两类容易被忽略的东西：数据库初始化脚本和管理员种子数据。我建议在架构设计阶段就要考虑这两个产物的归属，把它们写进代码实现 SubAgent 的职责里，否则很容易出现在测试阶段发现表结构对不上、没有内置账号可用的情况。

这里有个值得说的观察：当架构契约足够清晰时，代码生成的成功率和正确率会明显上升。以前单 Agent 写代码“不可控”，核心原因不是模型不会写，而是没人告诉它边界在哪里。一旦边界清楚，所谓代码不可控的问题能缓解一大半。

3.4 质量测试：按验收标准反向推导用例

代码实现跑通后，测试 SubAgent 登场。它的输入是需求规格里的验收标准加实际代码产物，输出是测试用例集。这里我特别强调“反向推导”这个词：测试用例的源头是验收标准，而不是代码实现里的分支。用前者，测试才有业务意义；用后者，就是给代码“背书”，测了等于没测。

它生成的用例覆盖这几类场景：

• 角色隔离：用两个不同员工账号分别创建报修单，互相验证看不到对方的单据；
• 状态机合法性：非法流转序列，比如从已完成直接改回处理中，验证被拦截；
• 通知即时性：提交报修后检查通知记录表和站内信接收列表，确认 30 秒内生成通知记录；
• 并发边界：模拟两个管理员同时处理同一张单据，验证状态更新是否出现相互覆盖。

实测下来这些用例确实抓到了几类真实问题，其中最有价值的是“员工查询接口没有加用户过滤条件，导致能看到全部单据”，以及“状态更新没有加乐观锁，并发处理时会相互覆盖”。这两个问题如果靠单 Agent 自测，基本抓不出来。

3.5 交付运维：把代码变成一键可部署的服务

最后一步是交付。运维 SubAgent 拿到最终代码和架构设计里的部署约束，生成 Dockerfile、docker-compose.yml、数据库初始化脚本和部署说明。它还会做一次上线前自检，逐项核对依赖是否完整、版本是否对齐、环境变量是否配置、端口是否冲突、密钥是否泄露在代码仓库里。

这个环节特别适合用模型来做，因为部署检查大多是机械性的核对项，模型比人更有耐心逐项过一遍，而且容易在第一时间暴露版本不匹配的问题。自检通过后，一条 docker compose up -d 命令就能把整套服务拉起来。到这里，一套从“一句话需求”到“可运行部署”的完整链路就彻底跑通了。

4. 一线踩坑实录：这几个环节最容易翻车

跑通一次 Demo 是一回事，在真实项目里反复用它又是另一回事。下面这几个坑，基本是我用真金白银换回来的经验，每一个都值得你在搭建时提前避开。

4.1 上下文交接丢信息：SubAgent 之间最隐蔽的翻车点

我最初跑这套链路时犯过一个很低级的错误：需求分析 SubAgent 输出的内容非常长，架构设计 SubAgent 在读取时只读取了前面的一部分。结果文档后段的几条核心业务规则完全没被架构覆盖，代码实现自然也漏了。这种问题在流程里根本不会报错，直到功能测试时才发现规则缺失，排查链路非常长。

后来我在协作协议里加了一个要求：需求分析输出时，必须把最核心的十条业务规则单独提炼成“关键规则摘要”，放到文档最前面。架构设计 Agent 无论如何都能读到这部分，再也不会出现读漏的情况。这个改动看着简单，但实际效果极其明显，强烈建议抄走。

4.2 需求被“幻觉”补全：最危险的自动化

第二个大坑，是模型在信息不足时脑补需求。还拿报修平台举例，需求分析 SubAgent 曾经默认“员工可以随时撤回自己提交的报修单”，但真实业务规定是“管理员未接单前可撤回，接单后不可撤回”。如果我没有设置确认节点，这个错误规则就会一路传导到架构、代码、测试，等发现时已经浪费了一整轮生成。

所以我把“人工确认卡点”当成了铁律：凡是设计业务规则、权限范围、状态流转这类关键决策，需求分析 SubAgent 必须把问题列成清单让我确认，不许自作主张。宁可多一轮人机交互，也不让错误规则悄然溜进下游。这个卡点不只是为了正确性，它其实还让需求环节的整理成本大幅降低，因为决策都是当前这轮做出的，而不是事后修补。

4.3 测试代理“测了但没测对”

测试 SubAgent 最容易出现的问题不是测试太少，而是测试太配合。它在生成用例时往往盯着代码实现里已有的分支去写，覆盖率看着很高，但真正要命的业务缺陷测不出来。比如“员工只能看自己的单据”这条标准，它可能就只写了“员工 A 能查到自己的单据”，却完全没有写“员工 A 访问员工 B 的单据必须 403”。前者确实能通过，但后者才是真正的保障。

后来我把“按验收标准反向推导用例”写死了，并且强制要求它生成负面用例：非法参数、越权操作、状态乱序、重复提交，这些正是企业应用里真正容易出事故的场景。

4.4 技术栈幻觉与版本漂移

代码实现 SubAgent 生成前端工程时特别喜欢用最新版本框架和依赖，但企业环境里依赖版本通常是受控的。我踩过一次比较惨的坑：它生成的 Vue 项目引入了一个较新的组件库版本，和现有企业组件库产生严重兼容冲突，CI 构建直接挂掉，排查了整整一个下午。

现在我把依赖版本约束写进架构设计阶段的硬性约束里，代码生成之前会先核对依赖版本清单，并且要求运维 SubAgent 在自检时再次核对一遍锁文件。这个双保险思路，可以确保不因为模型“知识截止时间”和“版本幻觉”而导致交付失败。

4.5 成本失控：五倍 token 消耗怎么管

跑多个 SubAgent 的一个现实问题是成本。五个环节完整跑一次，token 消耗大约是单 Agent 的三到五倍。一开始我没有做任何管控，一个中等项目跑一轮，账单数字非常感人。

我的对策是“分段缓存 + 定向重跑”。需求规格和架构设计是相对稳定的阶段，结果缓存下来；如果只是改了前端样式或者某个接口实现，只重跑代码实现和测试环节，需求和架构不动。这样一来，绝大部分迭代都只需要两三个环节重跑，成本一下子回到可控范围。

5. 从跑通 Demo 到真正进生产，还差什么

5.1 人机审核卡点怎么设计

我前面反复提到人工确认卡点，这里集中说清楚。我的经验是最少设置三个：需求规则确认点、架构方案评审点、发布前人工审核点。前两个是为了在成本最低的阶段拦住错误决策，第三个是为了保证没有任何 AI 生成的代码可以未经人工检查直接进生产。这不是不信任模型，而是工程纪律。哪怕是亚毫秒级的小改动，也至少要有一个懂业务的人过目，确认改动符合预期。

5.2 哪些环节可以完全自动化，哪些不能

跑顺之后，你自然会想问：哪些环节可以全自动，哪些必须留人？

我的判断是：机械性、可枚举的检查项可以全自动，比如依赖核对、字段完整性检查、接口契约校验、部署脚本验证。带业务决策属性的环节必须留人，比如业务规则的最终解释、技术栈的变更、对外合同或审计类功能的设计。需求分析这个环节看起来最像“可自动化”，实际却是最需要人深度介入的，因为它是所有下游环节的信息源头，一旦源头偏了，整条链路的产出都白费。

5.3 这套方法适合什么、不适合什么

最后想聊边界。模型驱动 + 五大 SubAgent 这套打法，最适合的是业务规则明确、模块边界清晰、交付物可以结构化验收的典型企业应用：管理后台、审批流、报表系统、工单系统，等等。这类系统的共同特点是流程固定、角色清楚、验收维度可量化，非常适合流水线式生成。

不太适合的是创新探索型项目。产品方向没定、需求天天变、代码改了又改的原型阶段，让 AI 去拆需求反而会浪费大量 token，人工确认成本也高。那种场景更适合轻量对话式辅助，而不是完整走一套五代理流水线。工具是死的，怎么用才是活的，有意识地判断场景比盲目套用流程更重要。

最后说点实在的。我自己在整套流程中最大的体会是：模型驱动开发能不能在企业落地，关键不在于单个模型有多聪明，而在于你愿不愿意把开发流程拆清楚。五大 SubAgent 分工协作，本质上就是把“一个什么都会的工程师”拆成“一支有明确分工的团队”，让模型在它最擅长的地方干活，让人在关键的节点把关。如果你准备动手尝试，建议先拿一个简单业务场景完整跑一遍，把 IO 契约和确认卡点调顺手，再逐步上复杂项目。这套方法的收益不是“一次生成全对”，而是“随时出错随时能修”，并且每一处修改都能被定位到具体环节。这个特性，在企业开发里比一次生成全对重要得多。