多智能体 vs 工作流：AI 架构选型指南与工程实践

1. 被多智能体三个字带偏的选型现场过去大半年我在不同团队里反复看到同一个画面需求评审刚结束有人张口就是这个场景得上多智能体让几个 Agent 互相协作、互相评审仿佛只要把 Agent 数量堆上去系统就自动变聪明了。结果呢一个本来用工作流两三天就能跑通的简历筛选流程硬生生被拆成简历解析 Agent 打分 Agent 复核 Agent 汇总 Agent四个角色互相传话调试两周还没稳定最后又灰溜溜退回单链路工作流。这不是个例。多智能体和工作流这两个词在当下的讨论里被严重对立化了前者被贴上高级、前沿、智能的标签后者被默认为老土、死板、低端。但真正在一线搭过系统的人都清楚这个对立本身就是伪命题。多智能体不是工作流的升级版它们是两种解决不同问题的范式绝大多数业务场景里工作流不仅够用而且更稳、更便宜、更好维护。这篇内容我想把这件事讲透。核心围绕三个问题多智能体到底强在哪、工作流的边界在哪、什么信号出现时才真的该上多智能体。关键词会自然串起Agent、协作机制、流程图、轻量级工作流、agent 框架这些概念但重点不是名词解释而是给你一套能直接拿去做技术选型的判断标准。适合正在纠结架构选型的开发者、被多智能体话术忽悠过的产品同学以及想搞清楚这两者本质区别的技术负责人。先说结论免得你看到一半才发现方向不对如果你的任务能被画成一张流程图那它就该用工作流而不是多智能体。这句话是我踩了足够多坑之后总结出来的后面会展开为什么。2. 多智能体真正解决的问题其实窄得超出你想象2.1 协作机制的本质是信息不对称下的博弈很多人对多智能体的理解停留在多个 Agent 分工干活这只是表象。多智能体系统的核心价值在于它处理的是单个执行者无法独立完成的、需要多方视角博弈或信息互补的任务。举个能说明问题的例子。多智能体协同的电网可靠运行这类场景为什么天然适合多智能体因为电网里有发电侧、输电侧、配电侧、负荷侧每一方掌握的信息都不完整且各自的目标函数不完全一致——发电想多出力负荷想省成本调度想保稳定。这种目标冲突 信息分散的结构才是多智能体协作机制真正发光的地方。每个 Agent 代表一方利益通过协商、竞价、投票等机制达成全局较优解。反过来看简历筛选。简历解析、关键词匹配、打分排序这三步之间有没有目标冲突没有。有没有信息不对称没有每一步的输入输出都是确定的。那它凭什么需要多智能体它需要的只是一条清晰的工作流。判断的第一把尺子任务里是否存在多个主体目标不一致、需要协商的结构。有才考虑多智能体没有工作流就是正解。2.2 Agent 框架的智能大多花在了不该花的地方现在主流的 agent 框架比如各种 ReAct 风格的实现核心能力是让模型自己决定下一步调用什么工具。听起来很美好但落到生产环境这个自主决策往往变成不稳定因素。我实测过一个用 agent 框架做的数据清洗任务给模型一个目标清洗这份 CSV 并输出规范格式然后让它自己选工具。结果同一个输入跑十次有三次它选择先做去重、五次先做格式转换、两次直接跳过空值处理。每次结果都对但路径不可复现。对于需要审计、需要回归测试的业务这是灾难。而工作流把下一步做什么写死在流程图里模型只在每个节点内部做它擅长的事——理解语义、生成文本、抽取字段。决策权归人执行权归模型这个分工才是工程上稳的。2.3 多智能体的成本结构很多人算错了大家算多智能体成本时通常只算 token。但真正的成本大头在三个地方通信开销Agent 之间每传一次话就是一次完整的上下文拼接和模型调用。四个 Agent 互相评审调用次数是单链路的数倍。调试成本多智能体是分布式系统出问题时你面对的是到底是哪个 Agent 的哪次输出带偏了全局排查链路极长。一致性成本多个 Agent 的输出需要收敛收敛逻辑本身又是一套需要维护的代码。我见过一个团队为了显得先进把客服工单分类做成了三个 Agent 投票。上线后发现三个 Agent 意见不一致时还得加一个仲裁 Agent仲裁 Agent 又需要 prompt 调优最后整个系统的维护成本是单模型分类的五六倍准确率只高了不到两个百分点。这笔账怎么算都不划算。3. 工作流的边界它能覆盖的场景比你以为的宽得多3.1 流程图能画出来的工作流基本都能做工作流的天花板在哪一句话只要你的业务逻辑能用流程图包括带条件分支、循环、并行网关的 BPMN 流程图表达清楚工作流就能实现它。想想你日常处理的绝大多数 AI 任务文档问答检索 → 重排 → 生成三步固定。内容审核敏感词过滤 → 模型判断 → 人工复核分支条件明确。数据抽取读取 → 分块 → 逐块抽取 → 合并校验链路清晰。毛坯房拍照生成效果图这种创意任务上传 → 风格选择 → 图像生成 → 后处理也是标准流水线。这些任务的共同点是步骤可枚举、分支条件可定义、每步的输入输出可预期。这正是工作流的主场。你用 coze 工作流、dify 工作流还是自己写代码编排本质都一样——把确定性的骨架交给流程引擎把不确定性的语义理解交给模型节点。3.2 轻量级工作流被低估了工作流这个词容易让人联想到笨重的 BPM 系统、复杂的 XML 配置。但现在的轻量级工作流完全是另一回事。一个几十行的编排脚本加上几个模型调用节点就能撑起一个日处理上万条的业务。我自己的经验是一个中等复杂度的内容处理流水线用轻量级工作流实现核心代码往往不超过三百行而且每一行你都能说清楚它在干嘛。相比之下同样功能的 agent 框架实现光是 prompt 模板和工具描述就上千行还说不清模型下一步会干嘛。轻量级工作流的另一个优势是可观测。每个节点的输入输出都能打日志出问题一眼定位到具体环节。多智能体系统里你看到的是一堆 Agent 的对话记录想还原为什么最终输出错了得像侦探一样顺着对话链往回扒。3.3 工作流 单 Agent 节点是被忽视的黄金组合这里要澄清一个常见误解用工作流不等于不用 Agent。恰恰相反最实用的架构是工作流做骨架Agent 做节点。具体说工作流负责编排什么时候检索、什么时候调用模型、什么时候走人工分支。而在需要自主决策的节点上放一个具备工具调用能力的 Agent。比如一个客服工作流前面几步是固定的意图识别和知识检索到了需要查订单状态这一步放一个能调用订单查询接口的 Agent让它自己决定查哪个字段、要不要追问用户。这样既拿到了工作流的稳定性和可观测性又在真正需要灵活性的局部用上了 Agent 的自主能力。该确定的地方确定该灵活的地方灵活这才是工程上的最优解。很多团队一上来就全盘多智能体恰恰是把这两者的优点都丢了。4. 什么时候才真的该上多智能体三个硬信号4.1 信号一任务存在真实的目标冲突第一个信号最硬系统里存在多个主体它们的目标函数不一致且必须通过协商才能达成全局可接受的解。典型场景是资源调度、多方谈判模拟、对抗性任务。比如一个自动议价系统买方 Agent 想压价卖方 Agent 想抬价中间需要一个撮合机制。这种博弈结构工作流表达不了因为工作流没有两个主体各自优化自己目标的概念。如果你的任务里所有步骤都朝着同一个目标、没有内部冲突那多智能体就是杀鸡用牛刀。4.2 信号二单次决策需要多视角交叉验证第二个信号任务的正确性依赖于多个独立视角的交叉验证且这些视角之间需要动态交互。注意关键词是动态交互。如果只是三个模型各跑一遍然后投票那用工作流的并行分支就能做不需要多智能体。真正需要多智能体的是A 的判断结果会影响 B 的判断依据B 的反馈又会修正 A 的结论这种来回迭代的过程。比如复杂代码审查一个 Agent 负责找逻辑漏洞一个负责查安全风险一个负责看性能。它们不是各查各的然后汇总而是安全 Agent 发现某个可疑调用后会触发逻辑 Agent 重新审视相关代码路径。这种交互式验证工作流的单向流程确实吃力。4.3 信号三任务边界本身是模糊的、需要探索的第三个信号你事先根本不知道任务需要几步、需要哪些工具必须让系统在运行中自己探索。这是 agent 框架最原始的设计初衷。比如帮我调研一下某个技术方案的可行性需要查资料、做对比、可能还要跑个 demo 验证步骤完全取决于中间发现什么。这种开放式探索任务工作流画不出来因为流程图的前提是你能预知所有分支。但要注意这类任务在生产系统里占比极低。绝大多数业务需求在需求评审阶段就能把步骤列清楚。真正需要开放式探索的往往是研发辅助、研究分析这类场景而不是面向用户的稳定业务。把这三个信号做成一张对照表选型时直接对号入座判断维度倾向工作流倾向多智能体目标一致性所有步骤目标一致存在多方目标冲突步骤可预知性步骤可枚举、分支可定义步骤需运行时探索验证方式单向流水线校验多视角动态交叉验证可复现要求高需审计回归低接受路径差异维护成本敏感度高低只要前两行落在左列基本可以判定工作流就够了。5. 一个真实选型复盘简历筛选为什么不该上多智能体5.1 需求拆解它到底是不是协作问题拿简历筛选这个高频场景来完整走一遍选型逻辑。需求是收到一批简历按岗位要求打分排序输出进入面试的名单。先问第一个问题这里有目标冲突吗没有。HR 的目标就是找到匹配的人所有环节都服务于这一个目标。第二个问题步骤可预知吗完全可以。解析简历 → 提取关键字段 → 与岗位要求比对 → 打分 → 排序 → 输出。第三个问题需要多视角动态验证吗不需要打分标准是事先定好的。三个信号全部落在工作流一侧。结论很清楚简历筛选是一个标准的工作流问题不是多智能体问题。5.2 工作流实现一条清晰的流水线用工作流实现链路是这样的简历解析节点把 PDF/Word 简历转成结构化文本抽取姓名、学历、工作经历、技能等字段。岗位匹配节点把结构化字段与岗位 JD 做语义比对这一步用模型做语义理解。打分节点按预设权重学历 20%、经验 40%、技能 40% 之类计算综合分。排序与阈值节点排序按分数线切分输出通过名单。人工复核分支分数处于临界区间的走人工确认。每一步的输入输出都是确定的整条链路可以画成一张干净的流程图。出问题时你打开日志就知道是解析错了、匹配偏了还是权重设得不对。想调整策略改一个节点的配置就行不影响其他环节。5.3 多智能体实现多出来的复杂度都是自找的如果硬要用多智能体做会变成什么样通常是这样解析 Agent、匹配 Agent、打分 Agent、复核 Agent 四个角色通过消息传递协作。多出来的复杂度包括Agent 之间的消息格式要统一、某个 Agent 输出格式跑偏要加校验、四个 Agent 的 prompt 都要单独调优、出现分歧时要设计仲裁逻辑、整体延迟因为多次串行调用而上升、token 成本翻几倍。而换来的收益是什么几乎没有——因为任务本身没有需要协作机制解决的冲突。我见过最离谱的版本是给打分 Agent 配了一个质疑 Agent专门挑打分的毛病。结果质疑 Agent 经常提出一些无关痛痒的质疑打分 Agent 又得重新解释一遍来回几轮分数还是那个分数只是多烧了一堆 token。这就是典型的为了多智能体而多智能体。6. 落地时的工程细节工作流怎么搭才不翻车6.1 节点粒度别把工作流做成面条代码工作流最容易踩的坑是节点切得太碎或太粗。切太碎节点之间传参爆炸维护起来像一团乱麻切太粗一个节点里塞了太多逻辑出问题定位不到。我的经验法则是一个节点只做一件能用一句话说清楚的事。比如抽取简历中的工作经历是一个节点把工作经历与岗位要求比对是另一个节点。这样每个节点的职责单一日志清晰替换或升级某个节点时影响面可控。另外节点之间的数据契约要定死。输入什么字段、输出什么字段、字段类型是什么最好用 schema 约束住。我吃过亏上游节点某次输出把工作年限从数字变成了字符串三年下游打分节点直接算错排查了半天才发现是格式问题。后来所有节点都加了输出校验这类问题基本绝迹。6.2 上下文管理长上下文是工作流的隐形杀手工作流跑长文档时上下文超长是绕不开的问题。一份几十页的简历或合同全塞进一个节点模型要么截断要么变慢。处理办法是分块 局部处理 汇总。把长文档切成有语义边界的块按章节、按段落每个块单独处理最后用一个汇总节点合并结果。这样每个节点的上下文都可控也方便并行加速。注意分块时一定要保留块与块之间的关联信息比如块序号、所属章节否则汇总节点会丢失上下文拼出来的结果前言不搭后语。6.3 错误处理与重试工作流的稳定性靠这个工作流比多智能体稳很大程度是因为它的错误处理是显式的。每个节点都可以配置失败重试几次、重试间隔多久、重试仍失败走哪个兜底分支。我的实践是给每个模型调用节点都配三层保护格式校验输出不符合 schema 就重试、超时控制单节点超过 N 秒就中断、降级分支连续失败就返回默认值或转人工。这三层加上去整条工作流的可用性会明显提升。多智能体系统里做同样的事要难得多因为错误可能在 Agent 之间的传递中被放大或掩盖你很难在某个明确的点上做拦截。7. 那些看起来该用多智能体其实不用的情况7.1 并行处理不等于多智能体很多人一看到多个任务同时进行就想到多智能体。但并行处理用工作流的并行网关就能做把一份文档拆成十块十个分支同时处理最后合并。这里面没有 Agent 之间的交互只是单纯的任务并行工作流原生支持。7.2 多模型投票不等于多智能体让三个模型分别判断取多数结果——这是集成学习思路用工作流的并行分支 汇总节点就能实现。它不需要 Agent 之间有协作机制因为三个模型之间根本不通信只是各自输出后被汇总。把它包装成多智能体投票纯属概念滥用。7.3 带工具调用的单 Agent 不等于多智能体一个 Agent 能调用搜索、计算器、数据库等多个工具这叫单 Agent 多工具不叫多智能体。多智能体的定义是多个具备自主性的 Agent 之间存在交互。一个 Agent 自己调十个工具它还是单智能体。这个概念混淆特别常见很多号称多智能体的系统拆开一看就是一个 Agent 在调工具。7.4 流程图本身就是最好的设计文档还有个被忽视的好处工作流的流程图本身就是最好的设计文档和沟通工具。产品、开发、测试看同一张图对流程的理解不会跑偏。而多智能体系统的设计往往是一堆 prompt 和角色描述很难画成一张让所有人都看懂的图沟通成本高得多。8. 我的选型心法先画流程图画不出来再考虑多智能体聊了这么多最后落到一个可操作的心法上。每次遇到新需求我的第一步永远是试着把它画成一张流程图。如果我能顺畅地画出开始、各个处理步骤、条件分支、结束那这个需求就是工作流的菜直接上工作流别犹豫。画的过程中如果发现某个节点需要自主决策就在那个节点放一个 Agent其余保持工作流。如果我画到一半发现某些步骤根本没法预先确定或者流程里存在两个主体互相博弈的结构那才轮到多智能体登场。而且即便登场也往往是工作流 局部多智能体的混合架构而不是全盘多智能体。这个心法帮我省下了大量返工。我见过太多团队跳过画流程图这一步直接冲进多智能体结果做到一半发现流程其实是确定的只是被自己复杂化了回头重构的成本极高。一句话记住流程图能表达的工作流来实现流程图表达不了的博弈与探索才交给多智能体。技术选型最怕的不是选错工具而是被高级感绑架。多智能体确实是个强大的范式但它的强大有明确的适用边界。在边界之外用它得到的不是智能而是复杂度。大多数业务场景一条清晰、稳定、可观测的工作流才是那个真正把事办成的方案。