企业官网建设流程全解析

软件工厂设计模式不是指某个具体框架或代码库，而是一套把软件开发当成“装配线”来组织的思路。它的关键词落在“可组合部件”：需求、代码模板、测试用例、部署脚本、甚至智能体协作节点，都被拆成独立单元，通过标准接口拼装起来，形成一条可以重复运行的交付流水线。

这个概念最近重新受到关注，很大程度上是因为多 agent 应用开始流行。最新的讨论里经常提到主从模式，核心观点是：subagent 本质上可以当作另一种 tool 来调用。主 agent 先拆任务，再按需拉起子 agent，子 agent 把结构化结果返回给主流程。这套逻辑和软件工厂的可组合部件如出一辙——把不是硬编码功能的东西，统一当成可插拔部件。

这篇文章适合软件架构师、工程效能负责人、AI 应用开发者和正在搭建自动化交付链路的团队阅读。我会按实际落地顺序拆解：先讲清楚这个模式解决什么问题，再讲部件的边界和契约，然后说它和 agent 编排的关系，接着给出一条最小可运行流水线，最后补上验证方法和生产环境的坑点。

1. 软件工厂设计模式到底解决什么问题

1.1 工厂思维不是把代码堆在一起，而是把交付拆成工序

传统开发里，“模块化”通常只停留在代码层面。一个 service 拆分几个类，各模块通过接口通信，就已经被认为做得很好了。但到了交付层面，问题立刻变得混乱：需求分析是一拨人，代码生成是另一拨人，测试手工执行，部署脚本散落在不同机器上，文档靠人肉更新。每个新需求进来，都要重新走一遍“找上下文、建环境、改代码、跑测试、打包上线”的步骤。这个过程本质上和手工作坊没有区别。

软件工厂设计模式要解决的核心问题，就是把“交付”这件事也变成流水线。它借鉴制造业装配线的思路：原材料按序进入工位，每个工位只负责一道工序，输出标准化半成品，流转到下一个工位。映射到软件领域，原材料是需求描述、领域知识、接口定义、数据样例；工位是分析模块、生成模块、检查模块、构建模块、测试模块；半成品是需求文档、接口规范、源代码、测试报告、安装包。

做到这一步之后，你得到的不是一段更好看的代码，而是一条可以重复使用的交付路径。任何新需求只要原料合规，都能在这条路径上跑一遍，而不是让工程师重新手工拼装。

1.2 为什么今天又要重提软件工厂

有经验的开发者可能会觉得这个想法不新鲜。确实，20 多年前 Greenfield 等人提“软件工厂”时，核心就是架构模式、领域特定语言和装配线。微软也曾经推出过软件工厂相关实践。但那时候落地阻力很大，一个重要原因是：装配线中“把需求变成代码”这一步，没有足够便宜的执行单元。

当时的做法是大量使用代码模板、代码生成器和后期绑定，本质上需要团队先投入巨大精力去构建设计资产。对大多数中小团队来说，投入产出比并不划算。

现在的关键变化是：LLM 和多 agent 编排让“需求到半成品”的转换成本大幅下降。你不再需要为每个领域编写一整套代码生成器，而是可以用一个可配置的智能体部件，把自然语言需求转成结构化产物。这让软件工厂的“可组合部件”第一次有了通用化、低成本的实现方式。

今天的软件工厂，更像是在说：把传统设计模式中的“职责边界、接口约定、依赖注入、模板方法”这些思想，迁移到由人、代码、LLM、agent 共同组成的混合流水线上。这是它在 2025 年后重新热门起来的真正原因。

注意：这个模式适合的是“同一类任务反复出现、需要稳定交付”的场景。如果你的每个项目都是全新探索型、几乎没有重复工序，那先不要急着建工厂，否则你只是在为抽象写抽象。

2. 可组合部件：边界、契约与上下文

2.1 部件边界：输入、输出、副作用

真正能放进装配线的部件，必须具备三个可判断的特征：明确的输入、明确的输出、可控的副作用。

输入不能是“放一段文本进去就行”。一个合格部件需要说明数据格式、字段含义、必填项和可选项。比如“需求分析部件”的输入应该是{ "task_id": "T-2024-001", "requirement": "用户可以在个人中心修改头像", "context": "项目使用 React + Spring Boot" }，而不是一段语焉不详的对话。

输出也要稳定。每一次运行，输出的结构都应该一致，这样下一个部件才能不加判断地消费。如果输出完全自由，那每个下游部件都得先做“结果猜测”，装配线就断了。

副作用最容易被忽略。这里的副作用指：部件是否改写了外部文件、是否调用了数据库、是否发起网络请求、是否消耗了 API 配额。在工厂装配线上，部件应该默认无状态，尽量把中间结果写到约定目录，不跨步骤修改他人数据。如果必须有副作用，必须在配置里显式声明。

2.2 契约一致是组合能够成立的前提

部件之间的连接，靠的不是“双方约定好名字”，而是显式契约。我在实际项目中一般会先用一个 schema 文件约定所有产物的格式，再让每个部件按照 schema 输出。常用做法包括：

• 需求解析结果统一写成 Markdown 文件，前三行是标题、优先级、验收标准。
• 接口设计统一输出 JSON，至少包含endpoint、method、request_schema、response_schema。
• 代码生成结果统一放在src/{module}/下，并在artifacts/generated_files.json里登记生成文件列表。

为什么要这么在意契约？因为在装配线上，任何一个部件格式变了一点，下游项目可能不再报错，但会产生脏数据。你花在排查“为什么接口文档少了字段”上的时间，往往比写代码的时间还多。显式契约加上 schema 校验，可以把这类问题在进入下一步之前拦截住。

2.3 上下文传递和状态所有权

工厂流水线里，一个常见混淆点是“上下文”。需求信息、项目背景、代码风格、约束条件，这些信息从一个部件传到下一个部件，很容易变成重复堆叠。今天我见过的最典型做法，就是在每个环节的 prompt 里都塞入整份项目说明。这样会导致两个问题：token 成本大幅上升；下游模型容易被不相干信息干扰。

更稳妥的做法是，把上下文分为两层。全局上下文只在流水线启动时加载一次，包含项目路径、命名规范、技术栈、统一约束。步骤上下文则由当前产物提供，每个部件只管自己需要的那一部分。还要明确状态所有权：一个文件一旦被某个部件标记为已完成，其他部件原则上不能顺手改写；如果确实需要变更，要走版本化流程，生成v1、v2，而不是原地覆盖。

这个原则放到多 agent 协作里同样成立。subagent 执行完子任务，返回的应该是完成结果和引用地址，而不是整个项目快照。主 agent 只负责调度和汇总，不重复执行已完成的工作。

下表列出不同类型部件的组合方式和适用场景，方便新手判断自己手里应该用哪种：

3. 从传统流水线到代理协作：主从模式为什么值得重提

3.1 主从模式，本质上是把 subagent 当作工具调用

多 agent 设计中的主从模式，常见疑问是：subagent 到底是一个独立的“智能体”，还是一个“工具”？不同团队有不同叫法，但就工程实现来看，更准确的判断是：subagent 是绑定到主流程上的特殊工具。

为什么这样说？因为一个普通工具函数，接收参数、返回结果，调用方根据结果继续运行。subagent 在主从模式下也是这样。主 agent 收到用户任务后，做任务规划，决定调用哪个 subagent，给它传 prompt 和上下文，subagent 执行自己的工具链，最后返回结构化结果。这个过程和“调用一个代码生成函数”在控制流上几乎一致。

区别在于，subagent 内部可以有自己的推理和多次工具调用，它的“入参”和“出参”通常更接近自然语言，也更灵活。但从主流程视角看，它就是一个函数：输入任务描述，输出任务结果。

这个理解非常重要。一旦你接受这个设定，你不需要为 agent 单独设计一套编排系统，直接把 subagent 放进流水线节点的抽象里就可以。每个节点可以是脚本、可以是 API 调用、也可以是 subagent。统一由调度器处理输入输出、失败重试、结果记录。

3.2 代理协作和经典流水线适用同一个建模思路

经典流水线，比如 Jenkins pipeline 或 GitHub Actions，描述的是串行或并行的任务序列，每个任务使用特定工具，产物在任务之间传递。这种建模方式稳定、可观测、可回滚。

到了多 agent 场景，很多团队一开始会脱离这套思维，把 agent 做成“自由行动”的形态：主 agent 任意调用工具，任意修改文件，中间过程不透明。这样demo 很好看，一旦要做批量任务或生产部署，问题立刻出现：任务跑了一半不知道黑盒里发生了什么，失败时难以定位，也无法稳定复现。

把 agent 编排建模成流水线，就能解决这些问题。你需要做的只有三件事：

1. 把任务显式拆成步骤，不依赖主 agent 随机发挥；
2. 每个步骤用 schema 约定输入和输出；
3. 每个步骤允许失败，失败后有明确重试或中止逻辑。

换句话说，在多 agent 设计里，subagent 被当作可组合部件看待。主 agent 是装配线管理员，subagent 是某个工位上的“柔性机器”。这样既保留了智力能力，又恢复了工程可测性。

我自己在团队落地时，会先把“主 agent 规划”的能力限制在步骤选择上，而不是让它可以任意写文件或访问数据库。一个步骤对应一个工具，要么是一个脚本，要么是一个 subagent，不能在中间随意换。这个约束会让配置看起来笨一点，但更容易做审计。

4. 落一条最小流水线：拆任务、定契约、看产物

4.1 先挑一条任务，拆成三类工序

动手搭建时，不要一开始就设计完整工厂。找一个真实存在、次数较多、单次需要 10 到 30 分钟手工完成的任务，把它拆成三类工序：

• 分析类：解析需求、整理接口、识别边界，输出文本或 JSON。
• 生成类：根据分析结果生成代码、文档、测试用例，输出到指定目录。
• 验证类：运行测试、检查语法、对比 schema，输出成功或失败报告。

以“为一个新接口模块生成代码”为例，可以拆成：

1. 解析需求描述，输出接口列表。
2. 根据接口列表生成 OpenAPI 规范。
3. 根据规范生成服务端代码骨架。
4. 生成对应测试用例。
5. 运行测试，输出测试报告。

这个拆法核心是每一步都有独立产物，且产物是下一步的输入。不要把一个步骤做得过大，也不要做成“一步生成全部”的黑盒。

4.2 定义工件格式和检查点

开工前，先创建目录结构。比如：

pipeline_demo/ ├── tasks/ │ └── T-2024-001.md ├── artifacts/ │ ├── 01_api_list.json │ ├── 02_openapi.yaml │ ├── 03_src/ │ ├── 04_tests/ │ └── 05_test_report.json ├── scripts/ │ ├── step1_parse.sh │ ├── step2_gen_spec.py │ └── step3_gen_code.py └── pipeline.json

每个产物文件都对应一个步骤。步骤运行后，除了产物本身，还要生成一份step_meta.json。这个文件至少包含：

• 步骤 ID 和版本
• 开始时间、结束时间、耗时
• 输入文件的哈希值
• 输出文件的哈希值
• 模型或工具版本
• 状态：成功、失败、跳过

这一步看起来繁琐，但它会让后续排查快很多。没有元数据时，你面对的问题常常是“这个文件是哪个步骤生成的？用的什么模型？为什么和我预期不一样？”有了元数据，就能直接回答。

4.3 最小执行循环（示例配置）

下面给一个示例pipeline.json，实际字段以你的环境为准，这里用来演示流水线调度的通用结构：

{ "pipeline": "module_gen", "working_dir": "pipeline_demo", "global_context": { "project": "shop", "language": "python", "framework": "fastapi", "style": "black" }, "steps": [ { "id": "parse_req", "type": "subagent", "agent": "req_analyzer", "input": "tasks/T-2024-001.md", "output": "artifacts/01_api_list.json", "retry": 1 }, { "id": "gen_spec", "type": "llm", "model": "gpt-4o-mini", "input": "artifacts/01_api_list.json", "output": "artifacts/02_openapi.yaml", "retry": 2 }, { "id": "gen_code", "type": "command", "cmd": "scripts/step3_gen_code.py --spec artifacts/02_openapi.yaml --out artifacts/03_src", "input": "artifacts/02_openapi.yaml", "output": "artifacts/03_src", "retry": 0 }, { "id": "run_tests", "type": "command", "cmd": "pytest artifacts/04_tests -q --junit-xml artifacts/05_test_report.xml", "input": "artifacts/03_src", "output": "artifacts/05_test_report.xml", "retry": 1 } ] }

调度器的执行逻辑很简单：按顺序遍历步骤，每次读取该步骤配置中的input文件，执行对应类型的处理器，把输出写到output位置。如果步骤失败，按retry次数重试；重试仍失败，则中止整条流水线，保留所有已生成产物。

这里不要急着做可视化编排、并行调度。先用顺序执行把链路跑通。

4.4 从单条任务到批量任务的两种路径

单条任务跑通后，再考虑批量。批量处理有两种常见路径。

第一种是循环式批量。外部脚本遍历任务目录下的所有需求文件，为每条任务调用一次流水线，每条任务独立生成一份产物。优点是实现简单，适合任务之间没有依赖的场景。缺点是多个流水线同时运行时，要小心共享资源，比如 API 配额、磁盘空间、同一个仓库目录。

第二种是队列式批量。把任务清单写成一个 CSV 或 JSON，后台消费者逐条消费。每个任务有独属 ID，输出目录按任务 ID 隔离。这种方式适合任务量大、需要长期运行的场景，也更容易做失败重试和断点续跑。

我建议先做循环式，把一个目录里 10 条任务全部跑通，再升级队列。因为队列式批量一旦引入，你实际上是在做一个小型任务系统，需要处理消息确认、日志持久化、并发控制，成本和收益要一起算。

5. 判断这个流水线跑得好不好：验证指标与日志

5.1 成功的标准不是“能跑”

我第一次搭这种流水线时，最大的误判是：跑通了就算成功。实际上，“能跑”和“能用”之间差着很多。你至少要回答这几个问题：

• 每一条任务是否稳定产出符合 schema 的产物？
• 产物的质量和人工完成的标准有多大差距？
• 连续跑 20 条任务，成功率是多少？失败集中在哪一步？
• 重试后结果一致吗？会不会出现同样输入但输出差异很大的情况？
• 全流程耗时是否可接受？资源占用是否稳定？

最好用表格记录第一次批量测试的指标。给一个参考模板：

这些指标没有统一标准，要结合你的任务复杂度、模型选择、质量要求来定基线。重点是，它必须是可量化的。不要用“效果还不错”这种描述。

5.2 输出命名、重试策略和现场日志

批量任务最容易踩坑的是输出覆盖。如果所有任务都输出到artifacts/generated_code/，第二条任务会把第一条的产物冲掉。这里没有技巧，必须强制使用任务 ID 隔离输出目录。

推荐的命名方式是：

artifacts/{pipeline_id}/{task_id}/{step_id}/{output_file}

这样每条任务、每个步骤的产物都在独立目录，即使任务失败，现场也保留着。现场比日志更重要。很多模型生成的代码看起来正常，但实际产物有问题；如果你不保留现场，重试时只能重新生成，成本更高。

日志方面，至少记录三件事：调度日志、步骤日志、错误摘要。调度日志记录“什么时间、由哪个调度器、启动了哪个任务”；步骤日志记录“每个步骤的输入输出路径、模型版本、结果哈希”；错误摘要记录“哪个任务在哪个步骤失败、失败原因、重试了几次”。

5.3 资源占用和速度怎么看

有很多团队在小规模测试时体验很好，一批到 100 条任务就崩了。这通常不是模型问题，而是资源管理问题。

如果使用 LLM API，要关注的是每分钟请求数、token 配额、连接池占用。并发拉满很容易触发限流，导致瞬间大量失败。低速开始，观察单任务耗时，再逐步提高并发，找到吞吐和稳定性都不错的平衡点。

如果使用本地模型，关注的是显存、内存和 CPU/GPU 占用。推理阶段显存涨上去后，GC 和模型切换会带来额外延迟。建议先跑一条任务，记录显存峰值，再跑两条，再跑四条。不要一上来就开最大并发。

磁盘空间也很容易被忽略。批量任务中间产物通常不会很小，尤其当你会生成代码、测试报告、原始日志时。建议每跑完一批任务做一次产物清理或归档，保留压缩后的摘要即可。

6. 想上生产，先要处理哪些边界和坑

6.1 上下文窗口有限，不要硬塞整份图纸

很多 pipelines 在步骤之间传递完整项目代码。这样做非常不经济，而且可能让模型忽略关键细节。解决办法是“引用而不是复制”：步骤输出只包含关键字段和文件路径，下游步骤按需读取文件。

如果一个步骤确实需要读取大量文件，可以做一个简单的提取器，把相关的类签名、数据模型和 TODO 汇总成一个上下文文件。这个上下文文件应该控制在一定规模，比如 3000 到 6000 个 token 以内。超过这个量，就说明你的工序拆分得不够细。

6.2 版本漂移和依赖地狱

软件工厂里，“版本漂移”是一件非常隐蔽的坑。模型会更新，代码生成器会更新，模板库会更新，测试框架会更新。今天跑通的任务，下周可能因为依赖变化产出完全不同的结果。

解决办法是把运行环境固化成版本清单。至少包含：模型名称和版本、依赖库的requirements.txt或package.json、代码模板库的 commit hash、脚本版本。每条流水线运行时，把版本信息写入step_meta.json。这样当产品结果异常时，你能够判断是环境漂移导致，还是任务本身变化导致。

另一个容易踩的是：旧模板生成的新代码无法兼容新框架。比如你的代码模板还在用旧版 FastAPI 语法，但运行时依赖已经升级。解决方案是在流水线里加一个“版本检查”步骤，在生成代码前后都对比一遍模板版本、依赖版本和生成器版本，不匹配时直接中止。

6.3 自动化边界：哪些工序值得自动化，哪些不该

软件工厂不是把所有环节都自动化，而是把“适合自动化的部分”抽出来。判断标准有三个：

• 规则是否明确？
• 结果是否可以验证？
• 出错后是否可以回滚？

满足这三条的工序，比如生成 CRUD 代码、生成接口测试、格式检查、模板填充，适合放上流水线。不满足的工序，比如最终的用户验收、涉及合同条款的审查、高风险的架构决策，应该保留人工审批节点，流水线在推进到该节点时暂停。

我在多 agent 项目里见过一个常见错误：把“决策任务”也交给 subagent 自动完成。比如让 agent 决定“这个模块是否要引入 Redis”，然后直接写入代码。这类决策业务影响大、验收标准模糊，不应该全自动执行。更稳妥的做法是让 agent 生成“建议方案”和“备选方案”，由人来拍板，然后把人确认的结果作为下一步输入。

6.4 多人协作时，工厂模型需要组织配套

软件工厂能不能跑起来，一半靠技术，一半靠组织。

流水线一旦建立，所有成员都要尊重工件目录、命名规范、质量门禁。否则就出现“我本地改了文件，流水线不知道”“我加了新模型，没更新 schema”“我不跑测试就提交”的情况。团队里要有一个清晰的“工厂管理员”角色，负责维护流水线配置和模板版本，其他成员只负责提供任务和检查产物。

第一次落地，我建议按两周一个迭代来推进。第一周只跑一条任务，每天记录成功率和异常；第二周把任务量扩大到 20 条，再根据指标调整步骤。不要第一周就追求所有任务都能自动化，更不要一开始就搭可视化管理页面。先把最小闭环跑稳，这些后来都来得及补。

注意：如果某个步骤连续失败超过三次，不要急着加大重试次数。先看日志、看输入、看契约。很多问题是子任务上下文缺少必要信息，而不是模型能力不够。

最后想说的话

软件工厂设计模式真正落地时，最需要盯住的三件事是：部件契约、产物现场、观察指标。契约让装配线可以组合，现场让失败可以定位，指标让优化有依据。至于具体用哪个模型、哪个生成器、哪个 runner，都可以灵活替换。

我个人更建议先把单条任务跑稳，再考虑批量和代理协作。当一条流水线稳定处理 20 条同类任务后，你会更加清楚：哪些步骤应该做成独立服务，哪些步骤可以交给 subagent 动态规划，哪些步骤永远需要人来判断。到那时候，软件工厂才真正从一个概念变成你的工程能力。