很多人看到 HumanLayer 发布的这期软件工厂设计模式播客第一反应可能是设计模式不是早就聊烂了吗软件工厂又是什么新概念我个人的理解是这期内容并没有停留在传统设计模式那套“类怎么组织”的讨论上而是把“工厂”这个隐喻放进了 AI Agent 协作场景里。你真正要处理的不是某个类该怎么写而是一组 Agent 怎么分工、怎么传料、怎么避免互相干扰、怎么在单个环节出错时不拖垮整条产线。这个问题如果只靠直觉去搭很容易搭出一个“看着能跑、一加批量就崩”的系统。先给结论软件工厂设计模式最适配的场景是多个智能体协同完成一条任务流水线典型任务包括批量内容生产、代码自动修复、数据分析、客服工单处理。它的核心价值不取决于某一个 Agent 有多聪明而是整个流程的稳定性、可追溯性和失败兜底能够被预先设计出来。下面按“概念澄清、协作模式、环境准备、参数标准、排查链路、落地建议”的顺序拆一遍尽量让读完的人能照着搭一个最小可运行的工厂式 Agent 系统。1. 先分清软件工厂设计模式和传统设计模式不是一回事传统设计模式里的 Factory Pattern解决的是“创建对象”的问题Singleton 解决对象唯一性Observer 解决通知解耦策略模式解决算法替换。它们的粒度在类和方法这一层讨论的是开发者写代码时怎么组织结构。软件工厂设计模式把粒度上升到了“任务流水线”这一层。工厂隐喻里几个关键部件在 Agent 系统里都有对应流水线对应任务的阶段拆分。内容生产可以拆成选题、写作、校对、排版四个阶段。工位对应每个 Agent 的角色。一个工位只做一件事只拿到自己需要的输入。制品对应阶段之间的产物。选题阶段的输出是选题卡写作阶段的输入就是这张选题卡。质检对应阶段结束时的检查点。格式、内容完整性、关键词密度、引用来源都能做成质检规则。线长对应调度者或 Orchestrator。它不亲自干活但负责分配任务、收回结果、决定是否返工。1.1 传统模式解决代码结构工厂模式解决任务编排传统设计模式解决的是“代码怎么写才不容易烂”软件工厂设计模式解决的是“任务怎么编排、制品怎么流转、失败怎么兜底”。这两者的关注点完全不同。打个比方。传统工厂模式是帮你把“创建一个 Excel 报告对象”的代码封装好软件工厂设计模式则是帮你回答哪个 Agent 负责采集数据哪个 Agent 负责生成图表哪个 Agent 负责写结论图表生成失败时是整体重跑还是只重跑图表工位。这两层的最大差别在于前者是人写代码代码出错有堆栈你可以单步调试后者是 Agent 干活Agent 的输出天然带有不确定性和格式漂移。你不能靠堆栈快速定位“为什么这一步的 Markdown 表格突然变成了普通文本”只能靠输入输出契约、任务日志和制品快照来排查。所以软件工厂设计模式里第一优先级不是模型多强而是流程可观测。1.2 为什么“工厂”比喻能讲清楚多 Agent 协作多 Agent 协同最常见的失败方式不是单个 Agent 能力不够而是角色边界模糊、产物格式不统一、返工没有规则。工厂比喻的价值在于它逼着你把这些问题显性化产线有几道工位每道工位是谁任务书长什么样。上一道工位交出来的制品下一道工位必须能直接消费。质检不合格的制品是退回上一工位返工还是直接打回重来。整条产线什么时候算完工验收标准是什么。这些在单 Agent 场景里基本不需要考虑一旦把 Agent 数量升到三个以上就变成每天都会撞上的问题。关于多 Agent 系统设计的讨论里反复出现的一个观点我很认同多 Agent 系统的复杂度主要不在模型调用而在编排层。你把编排层当软件工程来做问题就能被拆解、测试、改进你把它当“多开几个对话窗口”来做最后只会得到一堆不可复现的手工操作。2. 这期内容值得拆解的三种 Agent 协作模式从公开讨论和最近的智能体设计趋势来看软件工厂设计模式里有三种协作模式出现频率最高主从模式、Subagent 作为 Tool 调用模式、流水线模式。这三种不是互斥关系实际项目里经常混用。2.1 主从模式一个调度者多个执行者主从模式也叫 Orchestrator-Worker。核心结构是一个调度者负责拆解任务、分配任务、汇总结果多个执行者只负责执行自己分到的子任务并返回结果。这个模式适合任务层级清晰、子任务可以并行处理的场景。比如市场调研主 Agent 先拆出“竞品信息”“用户评价”“定价策略”三个子任务分配给三个 Worker 并行执行最后主 Agent 汇总输出报告。落地时要注意几个点主 Agent 不要自己做具体工作它的职责是分配和汇总。一旦主 Agent 开始写具体内容就容易出现任务和产出错位。Worker 之间不要直接通信所有信息通过结果返给主 Agent 流转。否则协作关系会变成网状日志和排查都会失控。主 Agent 要约束 Worker 的输出格式最好要求返回结构化结果而不是自由文本。2.2 把 Subagent 当 Tool 调用接口化而不是聊天式协作最近智能体设计讨论里有个说法很精辟本质上可以把 Subagent 视作一种另类的 Tool 进行调用。这个视角我觉得价值很大。传统上 Tool 是函数输入 JSON输出 JSON有超时有异常有重试。如果你把 Subagent 也当成一个“由大语言模型驱动的 Tool”设计逻辑就变得清楚了每个 Subagent 必须声明输入参数、输出格式、超时时间、失败时的行为。它不需要像聊天伙伴一样“理解”你的完整意图只需要像函数一样接收任务书、返回结果。这种模式的好处是大幅降低系统耦合度。主流程不关心 Subagent 内部用了什么提示词、哪个模型只关心它的输入输出契约是否满足。伪代码示意def call_subagent(task_spec: dict) - dict: 把 subagent 当作一个函数调用 入参是有明确结构的任务书返回值是有明确结构的制品。 # 1. 校验入参 validate(task_spec, schematask_v1) # 2. 调用 subagent设置超时和重试 result run_with_retry(task_spec, timeout60, retries2) # 3. 校验返回值格式不满足直接抛出 validate(result, schemaartifact_v1) return result上面这段不是某个项目的正式代码只是表达“接口化”这个设计思路。关键点在于调用 Subagent 之前校验入参返回之后校验出参中间设置超时和重试。这样 Subagent 内部崩溃也好、输出漂移也好都不会静默污染下游。2.3 流水线模式前一个工位的输出是后一个工位的输入流水线模式是最符合“工厂”直觉的模式。任务被拆成固定顺序的多个阶段每个阶段由一个或一组 Agent 完成前一阶段的输出制品直接成为后一阶段的输入。比如一个典型的内容生产流水线选题工位产出选题卡标题方向、目标读者、核心论点、参考资料清单。写作工位根据选题卡产出初稿。校对工位检查事实错误、格式问题、版权风险输出修订建议或修订稿。排版工位把定稿转换为目标平台格式。流水线模式的关键是制品规范。每个阶段输出的制品必须有稳定的 schema比如选题卡必须包含标题、目标读者、核心论点这三个字段。如果某个阶段输出缺字段下游必须能立刻发现而不是进入让大模型“尽量理解一下”的模式。三种模式各有适用场景我整理了一个粗略对比模式适合场景核心优点主要风险主从模式任务可拆解、子任务可并行并行度高调度清晰主 Agent 容易成为瓶颈汇总可能遗漏Subagent 即 Tool子系统边界清晰、需要接口化耦合低可测试可替换需要严格定义契约前期成本高流水线模式阶段强依赖、顺序固定的任务流程稳定制品可追溯单个阶段失败会阻塞整条产线实际项目很少只用一种。常见做法是外层用主从模式拆任务中间某几个子任务内部再套流水线个别能力复用度高的小任务直接按 Tool 方式调用。3. 从零搭一个最小软件工厂环境、规格与审批这一节进入实操。先说明下面给的是通用做法不绑定具体厂商或框架。你用什么模型、什么编排框架结论都适用。3.1 环境与依赖搭建最小系统通常需要这几类东西编程环境Python 3.10 或更高版本就可以Windows、macOS、Linux 都行。大模型接口需要一个能通过 API 调用的大模型配置好 API Key 和基础调用地址。编排框架可以用市场常见的 Agent 编排框架也可以不用框架直接自己写编排逻辑。第一版尽量用框架因为状态管理、断点续跑这些功能自己写很容易漏。存储至少需要一个目录或一个轻量数据库用来放任务状态、制品和日志。文件目录在早期够用。必须提醒的是原始材料没有给明确版本落地时先确认你自己的运行环境里相关依赖版本是兼容的尤其是 Python 版本和框架版本的组合。3.2 任务规格书比代码更重要的输入工厂式系统里Agent 之间传递的不是“自然语言段落”而是有结构的任务规格书。下面是一个简化示例{ task_id: article-20250101-001, workflow: content_factory_v1, current_station: writer, input_artifact: { type: topic_card, title: 软件工厂设计模式入门, target_audience: 具备基础编程经验的开发者, core_points: [多智能体编排, 主从模式, 流水线模式], reference_links: [官方文档, 内部知识库] }, output_schema: { type: draft_article, required_fields: [title, sections, word_count] }, quality_gate: { min_words: 3000, must_include: [主从模式] } }这个 JSON 的作用是让每个工位都知道我当前在哪个环节、我要消费什么输入、我要产出什么结构、我的质检要求是什么。比提示词里写一大堆“你要写一篇高质量文章”有用得多。我一般建议先做小事选一个真实任务手工写好任务规格书再让 Agent 跑。跑通之后再考虑要不要加字段、加质检规则。任务规格书要稳定不要每个任务临时改 schema。3.3 人工审批环节怎么嵌入人机协作类产品的核心能力之一是“人在回路”也就是在 Agent 执行关键动作之前插入人工审批。这在软件工厂里就是一个质检工位Agent 完成某个高风险动作前先生成审批请求等待人确认后才继续。实际嵌入方式有两种阻塞式审批Agent 执行到审批点就停下来等人工批准或拒绝后才继续。适合高成本、高风险动作比如向外部发送邮件、执行数据库写操作、支付相关操作。异步审批Agent 先继续推进不影响的环节审批结果回来后再合并。适合耗时较长但风险不高的环节。第一版建议全部用阻塞式审批。原因很简单异步审批要处理的状态更多一旦你处理不好“审批没回来但 Agent 已经跑到下一步”的状态就会产出一堆半成品。先把审批链路跑稳再考虑优化等待时间。4. 关键参数和判断标准不要只盯着“能不能跑”很多人在搭完多 Agent 系统后只关心“能不能跑通”。能不能跑通当然重要但它只是最基础的一条。真正决定这个系统能不能长期用的是下面这些参数和判断标准。4.1 调度参数主从模式和流水线模式都要关注调度参数。下表是几个通用参数参数含义新手建议生产建议并发数同时执行子任务的数量1 到 2先验证稳定性按任务类型和模型限流逐步上调超时时间单个子任务最长执行时间60 到 120 秒按实际任务历史耗时设置留 2 倍余量重试次数子任务失败后自动重试次数1 到 23 次以内重试前要检查失败原因最大返工次数质检不合格时退回重做的上限12超过上限应该转人工处理这里有一个容易忽视的点重试次数不是越大越好。如果失败原因是“模型输出格式不合法”直接重试大概率还会失败因为触发条件没变。更合理的做法是先记录失败样本检查输出格式校验逻辑是否有问题再决定要不要重试。4.2 主从模式下角色边界怎么约束主从模式最常见的翻车现场是两个 Worker 的职责边界模糊导致同一个信息被多个 Agent 反复处理最终汇总时内容冲突。约束角色边界的方式有两个层面系统提示词层面每个 Agent 的系统提示词必须明确“你只负责 X不要做 Y”并且不要共享同一个提示词模板。很多人图省事给所有 Worker 用同一套提示词只改角色名这恰恰是角色混乱的根源。数据结构层面任务规格书里明确给出每个 Worker 只能读哪些字段、只能写哪些字段。没有写权限的字段在处理阶段直接过滤掉。数据结构层面的约束比提示词可靠得多。提示词可以绕过表格结构更容易被遵守。所以我在实际项目里更依赖数据层面的权限控制。4.3 批量任务要看什么指标能跑通一条任务不代表能跑通一百条。批量任务至少要盯这四个指标成功率完成且通过质检的任务数占总任务数的比例。第一次跑如果低于 70%不要急着加并发先查原因。吞吐单位时间完成的任务数。它由单任务耗时和并发数共同决定只调并发不一定线性提升。产出一致性同类任务的输出格式是否稳定字段是否齐全。不稳定说明 schema 校验或提示词还有问题。人工介入率需要人工审批或人工修复的任务比例。这个比例过高说明自动化流程还不成熟。我一般会先用 5 条小样本任务验证流程再扩到 20 条最后才上完整批量。不要一上来就跑全量。小样本能让你更快发现格式、命名、存储这类基础问题。5. 常见问题排查链路卡住、乱输出、批量失败多 Agent 系统的错误很多时候不是“代码崩溃”式的而是“看起来正常运行但结果不对”。下面给一套我自己常用的排查顺序。5.1 任务卡住先看队列、审批和接口限流现象是任务跑着跑着就不动了日志也没有明显报错。这时候按顺序检查先看任务是否在等待人工审批。很多卡住其实是审批没通过人工不知道有审批请求。再看队列状态。如果某个 Worker 还在跑主 Agent 又在等它的结果就是正常的等待不是卡死。再看接口调用是否被限流。模型接口在并发升高时会返回限流状态如果重试逻辑没写好任务就会一直处于等待中。最后看是否存在死循环。比如返工次数判断条件写错导致同一个子任务被无限次退回重做。排查时先看两个东西任务状态表和各阶段耗时日志。没有状态和日志所有排查都只能靠猜。5.2 输出混乱先看输入契约和提示词边界现象是任务跑完了但输出缺字段、格式不对、内容张冠李戴。这类问题别急着去调模型的参数先检查两件事输入给 Agent 的任务规格书是否完整。字段缺失、JSON 被截断、Markdown 格式污染都会导致 Agent 输出混乱。每个 Agent 的提示词是否严格限制了输出范围。如果同一个 Agent 既负责写作又负责校对很可能产出既不是初稿也不是修订稿的混杂物。我的经验是先检查“Agent 拿到的输入是什么”再检查“Agent 被要求输出什么”。这两个检查好了剩下再怀疑模型能力。十次里有七次问题出在输入或格式契约上而不是模型不行。5.3 批量任务失败先看制品传递和输出命名批量任务失败的典型场景是跑第 30 条时突然报错前面 29 条都正常。这种问题往往和单条数据本身有关比如某条输入里包含特殊字符、超长文本、空字段。排查顺序定位失败任务 ID找到它的输入制品和输出目录。对比失败任务和成功任务的输入差异重点看长度、编码、特殊字符。检查输出文件命名是否冲突。多个任务并发写入同一个文件名会导致文件被覆盖看起来像丢数据。检查是否设置了断点续跑。批量任务中断后要从上次完成的位置继续而不是从头重跑更不是无脑跳过失败任务。批量场景下我强烈建议给每个任务单独建目录目录名用任务 ID任务内部的所有制品、日志、中间结果都放在这个目录里。这样排查任何一条失败任务都能快速找到现场而不是在几十个文件里翻找。6. 落地建议先跑通最小工厂再谈扩展最后聊几点我自己的落地建议。如果你正准备按软件工厂设计模式搭一套多 Agent 系统下面这些边界可以先记在心里。6.1 从单条任务到批量分三步走第一步手工调用一个 Agent确认它的输入输出契约能正常工作。第二步把两三个 Agent 接到流水线里跑通一条完整任务重点看制品流转和质检逻辑。第三步再加批量调度、并发、重试和人工审批。每一步都要留下日志和样例。不要一步到位。我见过很多项目一次把所有 Agent 都接好结果出错时根本不知道问题出在哪一环。6.2 低配置环境也能试但要降低规模预期如果你的机器是普通办公电脑没有高性能显卡也能跑这类系统但要注意本地大模型推理在资源受限时单任务耗时和稳定性都会变差。建议用云端模型接口完成第一版验证本地模型放在后续做优化时再试。如果你的场景是学习用默认配置跑通最小示例就够了如果是要长期生产使用就要把任务队列、日志、输出目录、失败重试、人工审批这些基础设施提前整理好。这两件事难度差很多别用学习的标准去衡量生产场景。6.3 真正该长期盯住的事情把这套系统跑起来之后我建议每周复盘几个数字批量任务成功率、平均单任务耗时、人工介入率、失败任务的失败原因分布。这些数字比“某个模型又有了新版本”更能反映你的编排层到底健康不健康。踩过几次坑之后我的体会是很多问题看起来像模型能力不够实际是编排层没把输入输出契约、角色边界、失败兜底设计好。软件工厂设计模式提供的就是这么一套“把 Agent 协作当工业流程管理”的思路。先跑通最小工厂再谈扩大产能这条路径比一上来就追求大而全要稳得多。