1. 单体对话模型撑不住的场景才需要多智能体协作先说个我自己的判断很多人一看到多智能体协作系统就以为是在赶时髦把几个prompt拼在一起美其名曰智能体A负责调研智能体B负责总结。这种思路做出来的东西叫多段提示词流水线哪怕跑通了也只是一条固定路径的脚本。真正的多智能体协作系统解决的是单一模型无法在同一个上下文中完成全部决策的问题。比如你要做一个对话式AI用户说帮我筛选这批简历里适合做海外运营的人。单体模型可能要一次性读完几十份简历然后在你给定的上下文中来回翻找只要简历数量一多、评判维度一复杂它就开始丢信息、混淆候选人甚至自己编造工作经历。这时候你会意识到问题不在于模型不够聪明而在于任务的复杂度超过了一轮对话完成所有事的边界。我实际落地的一个项目就是这种情况核心需求是在线部署一套多智能体协作系统来管理复杂工作流最终呈现为一个对话式AI。用户通过对话提需求系统把它拆成任务派发给不同角色的智能体每个智能体有独立的上下文、独立的工具权限、独立的评判标准最后有一个调度层统一汇总、冲突仲裁把结果组装成自然语言回复。这个架构跑起来之后最直观的变化是同样一份简历筛选需求单体模型可能做到第5份就开始胡言乱语但多智能体系统能把每份简历都过一遍专业评估之后再做横向对比回答的稳定性和可解释性完全是两个量级。这篇文章我会从架构设计、工作流编排、部署实施、踩坑优化四个维度把我从0到1搭建这套系统的过程完整写出来。不是纸上谈兵的架构图是真实上线过、压测过、也翻过车的那种经验。如果你正在考虑引入多智能体架构或者已经在用coze、dify这类工作流平台想往自建方向走这篇应该能帮你少走不少弯路。1.1 一个让我决定自建系统的场景简历筛选工作流具体聊一下触发点。当时我们接了一个需求要给合作企业做一个内部的招聘助理对话AI。用户上传一批简历PDF然后提一句我需要一个擅长东南亚市场、有内容运营经验、薪资预期不超过20K的人系统要返回推荐排序和理由。我第一版用的是单体模型方案思路上很简单把简历文本全部塞进上下文让模型自己读自己挑。测试的时候简历只有3份效果还行到第10份模型开始把候选人A的运营经历安到候选人B头上到20份我已经无法判断它给出来的推荐理由是真实存在还是幻觉了。这不是prompt没写好而是上下文的注意力机制决定了它根本不可能在这个长文本里做精细化的一对一比对。后来我切到了多智能体方案。系统里有5类智能体简历解析智能体负责把PDF转结构化数据评估智能体按不同维度逐份打分对比智能体做横向排名质检验智能体负责检查评估智能体的打分是否合理、有没有漏看关键字段最后由汇总智能体生成给用户的回复。整个流程被串成一条工作流调度中心负责派发任务和管理状态。这套东西跑通之后20份简历的处理结果稳定了很多我抽查了几十个case再没出现过信息串人。1.2 多智能体协作的本质把一个大任务拆成流水线这给我一个很深刻的体会所谓多智能体协作本质上跟一条工厂流水线一样。单体模型相当于一个老师傅一个人干完全部工序在总量小的时候效率没问题但规模一上来粗心、遗忘、偏执这些问题会严重拉低质量。多智能体系统则是把工序拆开每个工序有专人负责有明确的质检节点还有工位之间的转运机制。这个类比在工程上非常准确。每个智能体就是一个工位它有自己的一段上下文、一套工具调用能力、一组输入输出规范。调度中心是产线管理员负责决定当前哪份活该送到哪个工位哪个工位做完了可以往下流。工作流引擎是传送带它不关心具体content是什么只关心节点状态、流转条件、超时重试、异常分支。理解了这层管理复杂工作流这个标题里的管理就不是一句空话了它体现在三个具体动作上任务分解把用户一句话拆成可被智能体执行的原子任务。状态编排跟踪每个任务的执行进度决定下一个动作是继续、并行、还是回退。异常处理某一步失败时是重试、更换智能体、还是降级返回部分结果。后面我文章里讲的所有东西都是围绕这几件事展开的。2. 系统架构怎么搭编排层、智能体层与工作流引擎确定要自建整套系统之后我第一件事不是写代码而是画出一张清晰的三层结构图最上面是编排层中间是智能体层最下面是工作流引擎。这三层不是概念上的好玩而是直接决定了你后续能不能把系统做复杂、能不能排错、能不能扩展。编排层承担两个职责。第一个是理解用户意图把对话原文转成结构化任务单。第二个是作为对外统一入口用户只会跟这个对话式AI交流不会直接感知到背后有多个智能体。我用的方案是让编排层里的一个路由模块先做意图识别根据意图选择加载哪一套工作流模板。比如用户说帮我筛选简历路由就把简历筛选工作流整套拉起来。智能体层就是所有可调用的智能体集合。每个智能体必须满足三个硬性条件独立的system prompt、独立的工具集、独立的输入输出结构。我一开始犯过一个错误想着省事让所有智能体共用一套工具列表结果评估智能体有时候会自己调用发送邮件工具差点在测试环境里把邮件发出去。从那以后每个智能体的工具集都是锁死的只能在定义时配置运行时不可变更。工作流引擎是承载所有流转逻辑的基础设施。这里的引擎不一定要用Camunda、Flowable那种重量级BPM框架其实你自己实现一个基于状态机的调度器也可以。重要的是它能把节点状态持久化下来任务执行中哪一步卡住了、重试了几次、最后有没有成功全部可以在线看到。这个可观测能力在系统上线初期几乎决定了你的排错效率。2.1 三个核心组件的职责边界职责边界这个事看着简单实际拆的时候特别容易出问题。我建议把这三句话当作原则写进团队文档里编排层只负责决策不负责执行。它决定下一个该让谁干活但自己不碰任何业务逻辑。智能体层只负责执行不负责调度。它收到任务就做做完返回结果不关心这个任务是谁派来的、下一步去哪。工作流引擎只负责流转不负责业务。它记录状态、触发下一步动作但是完全不知道这个任务在业务上是什么意思。这套边界的好处是任何一个智能体挂了调度中心能感知可以跳过它走降级逻辑任何一条链路出了问题你顺着工作流日志能清楚看到是在哪个节点、什么原因导致的。拿简历筛选场景说简历解析智能体返回的是结构化JSON评估智能体接收的是JSON里的关键字段两者之间不共享上下文。如果解析智能体抽错了字段评估智能体拿到的就是错误数据但质检智能体在横向复核时能发现异常——它对比多个评估结果后发现同一个人的评分方差过大就把这个case标记为需要人工复核整个系统不会因为一个环节的数据错误直接给出错误结论。像这样的容错机制在单体模型架构里很难实现。2.2 为什么我选服务端编排而不是智能体互调市面上做多智能体的技术路线大致分两种。一种是让智能体之间互相能沟通Agent A发现缺数据可以直接调用Agent B另一种是全部走服务端编排所有智能体只跟调度中心通信。我最终选了服务端编排理由是它会让你在调试的时候少掉一半头发。智能体互调的场景看起来很灵活但一旦链路深了整个执行过程会变成一个不可预测的图Agent A调了Agent BAgent B又回头调Agent A两边各说各话谁也不肯先结束。有一次我测试一个购物推荐场景两个智能体互相等待对方先给结论日志里出现了7层递归嵌套最后直接把token预算烧光了。从那以后我规定任何智能体之间的通信一律通过调度中心中转禁止直接调用。通信方式统一了排查链路就变成线性的哪一步出问题一目了然。配套的还有消息协议的统一。我给每个智能体的输出定义了一层统一的执行结果结构包含status、data、latency三个字段status表示成功、失败还是部分成功data是业务数据latency记录这个环节的耗时方便成本分析有了这套规范编排层做兜底逻辑就很简单了看到status为failed直接触发重试规则看到超时就跳过该智能体不给用户空等。2.3 工作流引擎如何承载对话状态对话式AI的特殊之处在于用户不是一次性把需求说完的。他可能先说筛选简历然后补充偏海外市场经验又问之前那些结果里薪资超过25万的剔除掉。这意味着你的工作流引擎不能像处理单次请求那样执行一次就结束它必须能记住当前对话的关键状态。我用的是一个对话状态工作流状态双轨机制。对话状态记录用户意图、已确认参数、待补充字段工作流状态记录当前执行到了哪个节点。每次用户的新消息进来编排层会先更新对话状态然后决定是继续执行当前工作流、跳转到某个分支节点、还是重新拉起一条新的工作流。举个例子。用户第一次说筛选简历我拉起简历筛选工作流执行到评估节点时发现缺少候选人地区偏好这个参数于是工作流暂停编排层向用户反问你倾向于哪个区域。用户回复东南亚后编排层没有重新执行解析节点而是从暂停的节点继续往下走。这个暂停-恢复机制如果不放在工作流引擎层实现靠模型自己记状态的话几乎不可能稳定复现。3. 工作流设计与智能体分工的实战拆解架构定好之后最核心的工作就是设计每一条工作流的具体流转逻辑。我的经验是工作流设计不能太粗也不能太细。太粗了一个节点里塞了太多逻辑出了问题很难定位太细了节点之间的通信开销会大到你怀疑人生。以我做得最完整的简历筛选工作流为例。全流程11个节点其中5个是智能体执行节点4个是规则判断节点2个是状态存储节点。整体设计流程用一个词形容就是留痕——每一步都留下状态记录任何时间点重新拉起这个流程都知道它之前干到什么阶段了。3.1 一条完整工作流的实际流转过程我按实际流转顺序拆给你看每个节点做什么、产生什么数据、传给谁都有明确约定意图识别节点接收用户消息判断是否命中简历筛选意图。这里我用的是意图分类模型不是让编排智能体自己猜因为模型自己猜很容易把相似意图搞混。参数收集节点检查任务单里是否有评估维度、岗位要求、薪资区间、区域偏好等字段。缺哪个就主动向用户提问一次问一个不一次性轰炸式地问一堆。简历解析节点调用解析智能体把PDF转成结构化JSON。这步做过格式归一化不同来源的简历统一成一样的字段结构。数据校验节点规则判断检查解析出来的结构化数据是否完整。比如某份简历没有工作经历就标记为数据缺失不进入评估环节。逐份评估节点调用评估智能体对每份简历独立打分。这个节点是并发执行的每份简历单独成任务互不干扰。这也是多智能体架构的红利之一评估A简历和评估B简历完全可以是两条并行线程。横向对比节点调用对比智能体生成综合排名。它只接收评估结果JSON不读原始简历这样能让它专注在比较这件事上不会被原始文本干扰。质检节点调用质检智能体抽查前N名的评估结果。它会对照原始简历关键字段看评分是否有依据比如候选人在简历里根本没有任何海外经历却被评了高分那这个case就会被标记异常。结果汇总节点调用汇总智能体组装回答。把推荐名单、推荐理由、风险提示统一转成一段面向用户的语言。输出节点返回结果给用户同时把整条工作流的状态标记为completed。这个流程走下来有个细节值得注意评估和质检是分离的。评估智能体负责打主观分质检智能体负责做客观校验它们各有偏重不能在同一个模型里完成。如果合二为一模型容易产生自己给自己打分怎么都好的问题。3.2 智能体之间的消息传递与上下文管理多智能体系统设计里最容易被忽略的是智能体之间传递消息的格式。很多人直接传自然语言文本结果下游智能体每次都要做一遍语义理解既费token又容易出差错。我的方案是节点之间传结构化数据只有结果汇总阶段才转回自然语言。上游智能体必须返回JSON格式的数据下游智能体拿到JSON后按schema取字段。这样下游智能体的system prompt可以写成你接收的是MECE结构的评估结果只需对评估结果做汇总分析不需要自行理解简历原文模型任务的复杂度明显降低。上下文管理则是决定成本的关键。我的原则是每个智能体只看它需要的那部分信息。评估智能体不读原始简历全文只读结构化JSON里它要用的几个字段横向对比智能体看不到每份简历的详细数据只看到评估结果。这样做有三个好处token消耗小、上下文不容易被无关内容污染、各智能体之间数据隔离降低隐私风险。3.3 人工介入点与SLA超时兜底任何全自动的系统都需要留人工入口尤其是面向用户的对话式AI。我在工作流里埋了两个人机协作点第一个在数据校验节点后。如果系统发现用户上传的简历解析失败率高于50%就直接中止流程返回这些文件我无法解析建议换成PDF格式再试。这时候不强行让模型去猜内容。第二个在质检节点后。质检发现异常case数量超过阈值时会把这些case单独抽出来标记为待人工复核但不会中断整条流程只是推荐结果页面里多一个部分结果由人工复核的提示。SLA超时兜底是另一件重要的事。LLM的响应时间是不稳定的高峰期单次调用可能要10秒以上而一条工作流可能要串5个LLM节点最坏情况用户要等1分钟。我做了分级超时配置单个LLM节点超时设为30秒单条工作流总耗时上限设为90秒超过90秒直接走部分结果返回先把已完成节点的结果整理给用户并提示其余结果稍后继续生成这个兜底救过我好几次。有一回第三方模型服务抖动所有节点都在超时边缘如果没有总耗时上限用户会一直盯着加载转圈到无限期。设置上限后最差体验也就90秒返回一个部分结果比死等强得多。4. 在线部署的技术选型与实施步骤架构和工作流设计完之后真正进入部署环节。在线部署这个概念听起来高大上实际上就是把你折腾好的系统放到服务器上让人能通过公网访问。我按自己的落地过程把这部分拆成选型、准备、配置、验证四个阶段。4.1 部署形态对比自建编排框架还是低代码平台如果你在犹豫要不要从coze、dify这类平台迁移到自建方案我的建议是业务规模小、想快速验证想法用平台业务要定制化、要私有化部署、要做复杂权限管理自建。平台的好处是省事可视化拖拽确实方便但它们有几个硬伤跨平台可迁移性差、插件生态受制于人、复杂条件分支写起来别扭。我当时评估了一圈发现平台方案在管理复杂工作流这个核心诉求上是受限的自定义节点、自定义超时策略、细粒度可观测性都做不到于是决定自建。自建的架构选型我走的是轻量路线编排层用一个FastAPI服务承担HTTP入口、意图识别、状态管理工作流引擎用了临时自研的基于状态机的调度器没用Camunda和Flowable智能体层通过统一接口注册每个智能体是一个可独立部署的Python服务LLM服务统一走网关方便切换不同厂家的模型选型理由很简单项目初期需求变化快重量级BPM框架学习成本高、配置复杂对于以LLM调用为主的工作流来说有点大材小用。自研状态机调度器只需要一张节点配置表就能覆盖绝大多数流转逻辑。4.2 环境准备与依赖安装部署环境我用的是两台云服务器一台跑API与应用逻辑一台跑工作流引擎和数据库。具体配置如下组件配置建议说明API服务器CPU 4核、内存8G主要跑编排逻辑对GPU无要求工作流引擎服务器CPU 4核、内存16G会有并发任务处理内存给足数据库PostgreSQL 14用来存任务状态、工作流日志、用户会话缓存Redis 7管理并发锁和会话上下文依赖安装上Python环境我用了Poetry做依赖管理避免直接裸装一堆包把系统整脏。需要装的包大概有这些fastapi、uvicornAPI框架sqlalchemyORMredis-py连接Redisopenai、anthropic各家LLM的SDKpydantic数据结构校验celery如果你的并发任务量大可以用它做任务队列安装命令就不逐一贴出来了按照Poetry的常规做法执行就好。有一点提醒LLM的SDK版本锁定很重要。我遇到过openai包升级后接口签名变了之前的代码直接跑不起来。建议在pyproject.toml里锁死主版本号。4.3 核心配置与上线验证环境准备好之后核心配置集中在三块。第一块是LLM服务网关配置。我做了一个简单的配置文件各家模型的API Key、base_url、模型名称全部集中管理。网关层统一实现重试和熔断某个模型服务连续报错多少次就自动切换到备用模型这对在线服务稳定性非常关键。第二块是工作流定义配置。每条工作流在数据库里存一张配置表字段包括节点ID、节点类型、上游节点、超时时间、重试次数、对应智能体名称。用数据库存配置的好处是调整流程不需要改代码重新部署在线就能改配置尽管上线初期你没那么大胆量在生产环境乱调但至少这个灵活性是有的。第三块是Prompt模板管理。我建议所有智能体的system prompt从代码里抽出来放到模板文件里独立管理。我自己用了一套简单的模板引擎支持变量替换和条件判断这样微调prompt文案不需要重新发版。上线验证我分了三步先用一组测试任务跑通完整链路确认工作流能正常流转然后做并发压测同时发起20个不同场景的任务观察系统稳定性和响应时间最后开小流量灰度让真实用户试跑一周收集反馈再调整压测时重点关注两个指标任务成功率、P95响应时间。任务成功率低于95%就不要急着开放全量流量先排查是哪个节点拖后腿。5. 部署上线后的踩坑记录与效率优化系统上线后才是真正磨炼的开始。这套多智能体协作系统在线跑了大概一个多月我遇到了一堆只有真实流量才会暴露的问题。挑几个印象深刻的写出来这些坑你大概率也会踩到。5.1 并发超时问题LLM调用链路的超时传递第一个问题出现在高并发场景。同时来了好几个用户请求每个请求又拆成多个子任务LLM调用量突然暴增。然后我就发现一个诡异的现象不是调用本身失败了而是整个任务整体超时但日志里单独看每个节点都成功返回了。排查下来发现是超时配置没有做全链路传递。比如整个工作流上限是90秒但某个智能体内部有3次串行LLM调用单次都设了40秒超时直觉上应该没问题。但实际上第一次调用如果幸运地撑了39秒第二次再撑39秒第三次还没执行完全链路的90秒就被打爆了。解决方法是做超时的树形管理。不是只看单个节点和单条链路而是把每个节点的可支配超时算清楚。我的做法是工作流总时长根据节点拓扑预分配每个节点拿到一个截止时间戳执行前先检查剩余时间是否充足不够就直接走降级逻辑。这样就不会出现下游节点做完之后发现上游已经拖垮时间的情况了。5.2 提示词污染与工作流节点隔离第二个问题更隐蔽是关于提示词的。有一段时间我调高了某个评估智能体的严格程度让它打分更苛刻结果发现横向对比智能体的输出风格也跟着变了说话语气越来越严格推荐语里全是该候选人表现平平这种话。原因是我在prompt模板里用了同一个共享变量来定义评估尺度评估智能体和对比智能体都引用了这个变量。我改一处两个节点跟着变间接造成了下游节点的输出风格被上游影响。这不是偶然的在多智能体系统里如果prompt模板里有共享变量就等于给所有智能体加了暗连接任何一处改动都可能引发连锁反应。修复方案是每个智能体的prompt完全独立禁止引用任何共享的业务变量。共享信息只能通过结构化数据传递。这个过程我类比成电路隔离每个智能体跟其他智能体之间只能通过定义好的引脚连接不能走额外的暗线。5.3 可观测性把每条链路日志整理成时间线排掉问题的过程中我发现多智能体系统的调试和单体应用完全不是一个路子。单体应用你打开日志一顿搜关键词就能定位多智能体系统里一个问题会横跨多个服务、多个节点、多次LLM调用没有全链路追踪根本无从下手。我建议从上线第一天就给所有日志加上trace_id。每个用户请求进来就分配一个唯一ID之后的每一次智能体调用、每一个节点流转、每一个LLM响应都带着这个trace_id写日志。为了篇幅这里我就不贴日志规范了但记住标准是用trace_id能把一条用户请求的所有记录串起来并且每条记录都能还原出是在哪个节点、哪个智能体、哪次调用产生的。有了这个基础我把日志可视化做成了一个简单的工作流时间线视图横轴是时间纵轴是节点每个节点的执行、等待、重试都能看到。调试效率至少提升了一倍。5.4 成本控制经验最后聊一下钱的问题。多智能体系统的LLM成本非常恐怖比单体模型高出一个数量级不是开玩笑。我做过一次统计一条普通的简历筛选工作流平均触发4到5次LLM调用单用户单次请求的token成本是单体方案的8到12倍。如果不做成本控制账面上根本撑不住。钱主要花在四个地方每个智能体的system prompt各写各的加起来就是一大坨结构化数据虽然是JSON但JSON的标签本身也占token重试机制一次失败可能带来两到三次额外调用并发任务峰值时期同时打出去的token会让你肉疼我控制成本的手段一是所有智能体的system prompt精简再精简删掉所有修饰性废话只留指令、输入输出格式、例子。二是重试之前先判断这个重试有没有价值比如数据校验节点的规则判断失败了重试一百次也不会成功因为它是确定性逻辑不是LLM逻辑。三是引入模型分级简单的意图识别、关键词判断都用小模型只有真正需要复杂推理的节点才调用大模型整体成本能降不少。还有一招是缓存。同一个用户、同一类任务如果前序节点已经算过一遍结果且输入没变直接从Redis里读缓存返回不再重复调用LLM。在我的场景里重复查询历史筛选结果的命中率大概三成那就意味着一个月里省掉了三成的重复推理费用很可观。6. 写在最后做多智能体系统最该想清楚的一件事吐了这么多实操细节最后我想聊一个偏理念的东西。做多智能体协作系统很容易被智能体这个词诱惑觉得每一个节点都应该很聪明、很自主、能自己理解一切。但我的真实体会恰恰相反一个成熟的多智能体系统里大部分节点应该尽量简单、尽量确定只有真正需要语义理解的环节才使用LLM。你可以把这句话当成这条系统的设计哲学能用规则判断的不用模型能用小模型的不用大模型能在节点间传结构化数据的不传自然语言能让系统确定的地方绝不给模型自由发挥的空间。这套架构跑到现在稳定性已经比我预期的好很多。当然它还有优化空间比如把智能体回复做流式输出、进一步压榨并发执行的吞吐、把工作流配置做成可视化编辑器这些都是后续可以做的事。如果你正准备搭自己的多智能体系统我的建议是从一个足够具体的业务场景入手把工作流先跑通再考虑通用化。多智能体协作最难的部分不是技术本身而是你能不能把一个模糊的想法拆成一条条清晰的工序。拆清楚了系统就成功了一大半。