最近在帮一个团队梳理他们的多agent系统时发现一个很有意思的现象大家不自觉地开始讨论“主从模式”“subagent当tool调用”“可组合部件”这类词。这让我想起一个更底层但也更容易被忽略的概念——软件工厂设计模式。软件工厂并不是新词它至少可以追溯到几十年前的软件工程方法论但在LLM驱动的今天被频繁重提时它的含义已经发生了根本变化。真正值得关注的不是“用机器替代人写代码”这个表面结果而是它正在把构建软件的方式从一次性的“定制开发”变成可重复的“部件组装”。这个判断如果放到多agent架构里看会更加清晰。过去我们聊设计模式聊的是类、对象、接口之间的关系今天聊设计模式更多是在聊一个主agent如何编排多个subagent一个tool如何被复用一条处理流水线如何从零散脚本变成稳定的生产流程。软件工厂设计模式的核心不是某个具体框架而是一种构建思路把复杂系统拆成边界清晰的部件用明确的契约连接它们再由一个调度层统一编排。这套思路恰恰是现在多agent开发中最需要补齐的一块。1. 为什么“软件工厂”这个老概念会重新流行1.1 软件工厂从来不是新词但每次流行都有不同载体软件工厂的概念早在1968年的NATO软件工程会议上就已经出现。当时人们设想软件生产可以像工业生产线一样通过标准化流程、标准化组件和流水线分工把“手工作坊式”的开发变成“工厂式”的生产。这个设想后来催生了CASE工具、MDA模型驱动架构、低代码平台甚至今天各种脚手架工具本质上都是“软件工厂”的变体。但过去很多尝试并没有真正取代手工开发。原因是软件需求高度多变领域差异极大试图用一套标准化生产线去覆盖所有场景往往会发现“定制成本”比“手工开发成本”还高。低代码平台之所以只能覆盖特定业务场景也是因为这个边界问题。可以说软件工厂的老故事一直是“如何把软件生产标准化”。这个目标的难点不在自动化工具本身而在需求规格的标准化。需求都还没有被结构化描述清楚生产线自然无从谈起。1.2 LLM时代生产对象变了软件工厂才真正有了新土壤到了LLM时代情况不一样了。我们面对的不再是“把一套业务需求翻译成CRUD页面”这类高度依赖领域建模的任务而是“把一段自然语言任务拆解成多个可执行子任务再调用工具完成”的流程编排任务。这正好落在软件工厂的强项上。一个主agent可以看作流水线的调度中心一个subagent可以看作一个加工单元一个tool可以看作一台标准机床而任务描述、上下文传递、结果验证则构成了连续的生产节拍。多agent系统里最火的“主从模式”本质就是把subagent当作一种另类的tool来调用。传统tool是单步函数调用而subagent是具备内部推理能力的“多步骤tool”。从调度角度来说它们对上层暴露的都是同一个东西输入、输出、错误、副作用。所以软件工厂在这个时代重新流行不是因为“生成代码”这个动作有了新的实现而是因为LLM让“需求描述”第一次变成了可解析、可拆解的输入。整个生产链条终于可以围绕语言这个统一接口来运转。1.3 一个主判断可组合部件才是软件工厂设计模式的灵魂现在很多项目都在做多agent但问题恰恰出在“组合”上。很多团队的agent系统看起来有主agent、有subagent、有tool实际却是一堆脚本用硬编码方式串在一起。今天给主agent加一个新场景要去改subagent的prompt明天调一个tool的返回格式又要连带改好几个解析逻辑。软件工厂设计模式要解决的核心问题不是“怎么让多个agent对话”而是“怎么让多个部件可以被可靠组合”。可组合部件有几个关键特性对外暴露清晰的输入输出契约不关心内部实现。内部状态尽量隔离上下文通过参数显式传递。错误行为可预期调用方能够捕获并处理失败。每个部件独立可测可以单独验证再接入系统。这个思路放到传统设计模式里其实就是通过接口、组合、代理、门面等模式解决的问题。只不过过去组合的是类和对象现在组合的是agent、tool和prompt流程。2. 可组合部件从传统设计模式到多agent设计模式2.1 传统设计模式的本质是封装变化点传统设计模式里有一个核心思想找出系统中可能变化的点把变化封装起来减少变化对整体结构的影响。创建型模式封装“对象怎么创建”结构型模式封装“对象如何组合”行为型模式封装“职责如何协作”。软件工厂设计模式本身就是创建型模式的一个例子。它通过定义一个公共接口让使用者不直接关心具体生产过程而是通过工厂方法获得成品。这个思想在现代面向对象设计里被反复使用但很多人只把它当作“减少new”的技巧忽略了背后的“依赖抽象而不是依赖具体实现”这个原则。到了多agent场景这个原则变得更加重要。如果一个主agent直接依赖一个特定subagent的具体prompt那么这个组合就非常脆弱。prompt一改主agent的任务编排逻辑可能全断。反之如果主agent只依赖一个工具接口比如process(task_description) - result那么底层无论是调用一个subagent、一个外部API还是一个传统脚本对上层来说都是一样的。这就是可组合部件的入口。2.2 多agent设计中的主从模式subagent是另一种tool最近多agent设计里很流行主从模式讨论度很高。这种模式的核心结构并不复杂一个主agent负责接收用户请求、拆解任务、决定调用顺序多个subagent分别处理特定类型的问题。值得注意的一个观点是在多agent设计里主从模式本质上就是把subagent当作另类的tool进行调用。为什么要这样看因为从调用方视角来看tool和subagent都是在完成一件事tool输入参数执行一个明确定义的操作返回结构化结果。subagent输入一个子任务描述可能还附加上下文通过内部多轮推理完成分析返回结果。两者之间的差异只是复杂度和内部推理能力不同。如果我们把subagent设计得像tool一样“可被调用”那么主agent的编排逻辑会变得非常简洁。它不需要理解subagent的内部prompt细节只需要知道这个部件的入口是什么、出口是什么、失败时会抛什么错。这其实就是软件工厂里的“标准接口”思想。机床不需要知道每一个加工件内部的材料结构只需要按照夹具标准去装夹就行了。subagent作为tool调用意味着我们必须为它定义好“夹具标准”——也就是输入输出契约、超时策略、错误码、日志规范。2.3 部件化设计的三要素契约、状态、可观测要让一个agent系统真正变成“可组合部件”的集合而不是一堆prompt的拼接至少需要关注三件事。第一是契约。每个部件必须有明确的输入输出schema。这里的输入不一定只是字符串而是对象化的参数。比如一个“文档总结”subagent它的输入可能是{document_id: xxx, summary_length: medium}输出可能是{summary: ...}。只有定义了schema主agent才知道该传什么参数上游系统才知道如何解析结果。没有契约的组合等于没有接口的模块化只是一堆互相猜测的数据交换。第二是状态。可组合部件应该尽量无状态或者状态要显式传递。在多agent场景里最常见的问题就是“把上下文悄悄放在共享变量里”。当一个subagent修改了某个全局状态另一个subagent可能读到被污染的数据。正确的做法是把这次任务需要的上下文打包成参数传入任务完成后不再保留可变状态。第三是可观测。组合越复杂越需要日志和追踪。每个subagent被调用时应该记录它的输入摘要、输出摘要、耗时、错误信息。这样才能在异常发生时快速定位到具体是哪一层出了问题。软件工厂里这对应的是生产线的质量检测工位。3. 用软件工厂思路搭建一个可组合多agent系统3.1 先明确边界不是所有任务都适合拆成subagent软件工厂思路虽好但不等于所有任务都应该拆成多个agent。这是我见过最多人踩的坑任务本身只有一个简单判断却硬要设计一个主agent加三个subagent结果反复传递上下文速度慢还容易出错。比较适合拆分的任务通常有这些特征任务边界清晰可以拆成几个相对独立的子任务。每个子任务需要不同的知识领域比如一个负责代码分析一个负责文档生成。子任务的结果可以被独立验证不需要在过程里来回修改。单个子任务的复杂度足够高值得单独用一个agent去处理。如果不满足这些特征直接用一次prompt调用就能完成的任务就不要强行拆开。软件工厂的核心优势是“复用”和“并行”但代价是“调度开销”和“上下文传递成本”。简单任务拆得越碎反而越像在一条流水线上只生产一个螺丝。3.2 最小可运行流程先把subagent封装成tool这里给一个比较通用的最小流程适合从零开始搭建一个可组合的多agent系统。假设我们想做一个代码评审助手主agent负责整体评审一个subagent负责检查安全风险另一个负责检查性能问题最后主agent汇总。第一步定义tool契约。我们要先定义好每个subagent的输入输出格式。常见做法是用JSON Schema来定义。下面是安全风险检查这个subagent的契约示例{ name: security_review, description: 对一段代码执行安全风险检查返回风险列表, parameters: { type: object, properties: { code: { type: string, description: 需要检查的代码片段 }, language: { type: string, description: 代码语言如python、java等 } }, required: [code, language] } }第二步把subagent封装成tool。这里的核心逻辑是subagent内部可以是任意复杂的prompt和多步推理但对主agent来说它只暴露为一个函数调用。下面这段伪代码示意了封装方式def security_review_tool(code: str, language: str) - dict: security_prompt f 你是一名安全工程师请检查以下{language}代码的安全风险。 输出格式应为JSON列表每个元素包含 - risk_level: high/medium/low - risk_type: 风险类型 - description: 风险描述 - suggestion: 修复建议 代码: {code} result subagent_run(security_prompt, system_prompt你是一名严谨的安全评审专家) return { security_findings: result }第三步在主agent里注册这个tool。主agent只看到security_review_tool这个入口它不理解内部prompt也不需要理解。它只需要知道传入代码和语言返回风险列表。第四步主agent编排流程。主agent在收到“请评审这段代码”的任务后会先自己分析决定需要哪些评审维度然后分别调用security_review_tool和performance_review_tool最后汇总两个子结果形成最终评审报告。这套流程看起来简单但已经具备了软件工厂设计模式的雏形每个subagent是独立部件通过tool接口接入系统主agent是编排层负责调度和汇总最终报告是交付物。3.3 关键参数和配置别一上来就调满在配置多agent系统时有几个参数值得特别关注。第一是模型参数。每个subagent的temperature最好按任务类型设置。代码分析、安全检查这类精确任务temperature可以设置得较低比如0到0.2减少随机性。而文档生成、创意分析这类任务可以适当调高到0.7到0.8但也不要过高否则不可控。第二是超时和重试。subagent被当作tool调用后调用方必须考虑超时问题。一个subagent内部可能有多轮模型调用耗时可能比普通API长很多。常见做法是先设置一个相对宽松的超时时间比如120秒再为重试次数设置上限。重试时还要注意任务是否幂等如果输入输出是纯函数式处理重试是安全的如果subagent内部有写入数据库或发送邮件等副作用重试就会重复触发。第三是上下文长度控制。主agent传给subagent的上下文必须按需裁剪。很多人喜欢把完整的对话历史一股脑传给每个subagent导致上下文很快被占满。更合理的做法是按照契约只传必要字段。比如代码审查场景主agent只需要传代码片段和语言类型不需要传用户和它之间聊过的所有历史。第四是结果校验。每个subagent返回后主agent不应该盲目信任结果。至少要做三件事检查返回格式是否符合预期检查返回内容是否为空检查返回结果是否包含明显错误标记。这一层校验对应软件工厂里的质检环节。3.4 从单任务到批量任务先跑通再扩展单个评审任务跑通之后下一个问题通常是“能不能一次批量评审很多文件”。这个阶段最忌讳的做法是直接在主流程外面套一个大循环把所有文件并发丢给agent系统。因为agent系统的延迟远高于普通API批量任务一旦出现错误排查成本会成倍上升。更稳妥的路径是分三步走第一步单条任务跑通确认日志、输出、错误提示都正常。第二步用少量数据做小规模验证比如5到10个文件观察并发上限和失败率。第三步再逐步扩展到完整批量任务并引入任务队列、结果落盘、失败重试和人工审查入口。批量场景下还要额外考虑“幂等键”的问题。假设一个任务在网络波动时被重发如果系统无法识别这是同一次任务就可能重复执行。简单做法是每次任务生成一个task_id在日志和结果表里都存储这个ID重试时先查这个ID是否已有结果。另外批量任务的每个结果都应该单独落盘不要只存在内存列表里。一旦主进程崩溃内存里的结果就全部丢失。最好的做法是按任务ID分文件或分记录保存这样即使有部分任务失败后期也可以只重跑失败部分。4. 落地时最容易踩的坑与排查链路4.1 四个典型问题上下文丢失、错误传播、状态隔离、重复执行多agent系统的坑集中在四个地方。上下文丢失是最常见的现象。主agent调用subagent时如果只传了一个简单的子任务描述没有附带必要的背景信息subagent就会在信息不完整的情况下开始“自由发挥”。很多团队排查后发现subagent并没有做错只是它根本不知道前置条件。错误传播是第二个高频坑。subagent是一个独立推理单元它的模型调用可能是部分成功部分失败的。比如一次分析生成了五个结论但第五个结论的格式不符合解析要求如果解析逻辑直接抛异常整个任务就失败了但如果吞掉异常又可能会得到一个不完整的结果。这里需要设计一个明确的错误策略哪些错误可以静默降级哪些错误必须终止任务。状态隔离是更隐蔽的问题。多个subagent并发执行时如果它们共享了一个全局变量或同一个文件句柄就会出现串扰。一个agent写入了临时状态另一个agent读到的是被污染的数据。这个问题的排查往往耗时最长因为错误现象不稳定时好时坏。重复执行则和重试机制相关。一个subagent调用外部API时超时了主agent自动重试了一次结果第一次其实已经执行成功了只是响应超时最终系统产生了两条重复记录。如果没有幂等设计重试就会变成灾难。4.2 排查顺序现象 - 输入 - 契约 - 日志 - 参数 - 工具边界遇到多agent问题不要一开始就怀疑模型能力或框架缺陷而是要按确认过的顺序逐层排查。第一步看现象。问题到底是报错、卡住、无输出、输出异常、速度慢还是结果不稳定现象描述不同排查路径完全不同。第二步看输入。主agent传给subagent的输入是否是完整的prompt是否被截断字段是否正确很多时候问题就出在参数漏传。第三步看契约。输入输出schema是否匹配subagent返回的结果是否被正确解析返回字段名和解析逻辑是否一致第四步看日志。每个subagent的调用日志里有没有记录输入摘要和输出摘要如果日志缺失这个系统就不具备快速排查的条件。第五步看参数。超时时间、重试次数、温度、并发数这些参数是不是设置得过于激进比如把并发数拉满导致限流或者把重试次数设得过高导致重复执行。第六步看工具边界。模型本身是否有输入长度限制外部API是否有频率限制subagent内部是否依赖了不稳定服务如果只是工具边界问题改参数和prompt都没用。下面是一个简单的排查对照表现象优先排查常见原因subagent返回结果为空输入、prompt、解析逻辑输入不完整或者模型没有按格式返回主agent调度顺序混乱主agent的system prompt、工具描述工具描述不够清晰主agent误解了任务任务重复执行重试逻辑、幂等键没有设计幂等重试产生副作用结果不稳定模型参数、上下文长度temperature过高或上下文被截断运行速度慢并发设置、外部依赖串行调用太多或每个subagent内部轮数过长4.3 适用边界什么场景适合什么场景慎用软件工厂设计模式以及多agent的主从架构并不是银弹。它更适合下面这些场景有明确的子任务边界复用价值高。需要多个不同专业领域的能力协同。团队有日志、监控和错误处理的基础设施。任务允许一定的延迟不是毫秒级交互。反过来下面这些场景要慎用简单任务一次模型调用就能完成。延迟敏感的在线交互比如实时问答、实时搜索补全。任务之间需要频繁共享大量中间状态拆分后协同步骤太多。团队还没有日志意识出了问题只能靠肉眼盯prompt。还有一个前置条件容易被忽略模型本身的能力要足够。如果基础模型连单次任务都经常理解错误拆分成多个subagent只会让错误被放大而不是分散。多agent编排不会凭空提升模型能力它只是把已经很强的模型能力用更结构化、更可组合的方式组织起来。5. 把软件工厂设计模式沉淀成团队可复用的框架5.1 一个可复用的三层框架部件层、连接层、流程层如果非要把这套经验沉淀成一个框架我会分成三层来看。第一层是部件层。这一层包括tool、subagent、模型调用单元、外部API等一切可被调用的能力。每个部件只做一件事并且对上层暴露明确的输入输出。比如一个“代码格式化”部件一个“安全审计”subagent一个“文档生成”agent都属于部件层。第二层是连接层。这一层负责解决部件之间怎么连接的问题。包括契约定义、上下文传递、错误处理、重试机制、超时控制。连接层是软件工厂里最容易被忽略的地方。很多系统看起来有很多agent实际上没有明确的连接标准全靠主agent在prompt里即兴发挥这种组合方式是不可维护的。第三层是流程层。这一层解决的是“按什么顺序调用哪些部件”的问题包括任务拆解策略、调度策略、并行策略、结果汇总策略和人工复核入口。流程层有点像工厂里的生产计划部门它不直接加工零件但是决定整条产线怎么运转。用三层模型看问题时可以很快定位问题出在哪一层。比如结果不稳定可能是部件层参数问题也可能是连接层契约不清晰还可能是流程层并行调度产生了冲突。明确了层次排查思路就清楚了。5.2 从学习到生产的演进路径四个阶段要真正把软件工厂设计模式用起来不建议直接搭建一个庞大系统。更稳妥的路径是分四个阶段推进。第一阶段单agent跑通。先不拆subagent用一次模型调用完成最小闭环确认模型能力、prompt格式、输出解析都正常。这个阶段的价值是建立基线。第二阶段主从模式试运行。把单个任务拆成一个主agent加两个subagentsubagent作为tool注册。先写完一条调用链不要急着做并行和批量。第三阶段引入可组合部件库。把多个subagent抽象成可复用部件沉淀统一的输入输出契约和错误处理策略。这个阶段开始体现软件工厂的价值新的场景可以复用旧部件而不是重新写prompt。第四阶段工程化。加入日志、监控、任务队列、结果落盘、幂等控制和权限管理。这之后系统才具备长期稳定运行的基础。这四个阶段不必一步到位。很多团队失败是因为一开始就想做第四阶段结果连第一阶段的最小闭环都没跑通。5.3 长期价值软件工厂真正改变的是人机协作方式软件工厂设计模式的长期价值不在于又多了一种技术方案而在于它重新定义了开发者和AI之间的协作方式。过去我们和LLM协作是一次性的写一段prompt获得一段输出用完就丢。这种方式效率不稳定经验也无法沉淀。每个prompt都像一次手工作坊里的临时制作做完了就结束下次从头再来。软件工厂的思维方式是把一次性的临时尝试变成可复用的生产线。我们关注的不是单个prompt写得多好而是整条流水线的部件是否稳定、契约是否清晰、流程是否可维护。在这个前提下AI能力的使用方式会发生变化开发者不再是每次都要“教”模型怎么做事而是先定义好流程和部件再让模型在部件内部发挥作用。这套思路一旦跑通沉淀下来的不只是代码和prompt而是一套可复用的生产体系。它可以让一个团队在未来接到新需求时不是从零开始设计prompt而是先看已经有哪些部件可以直接接入哪些流程可以复用哪些环节需要替换。这才是软件工厂设计模式真正的价值。落到你的实际项目里不用急着把所有任务都agent化。先从一个小而有代表性的任务开始定义好一个tool契约把一个subagent封装进去让主agent调度一次试试。这条最小链路一旦跑通你会对“可组合部件”这几个字有完全不同的体感。