前阵子我用 Coze扣子搭一个稍微复杂的小应用用户提交需求系统自动生成一份简历再去匹配几个岗位方向。一开始我只做了一个智能体让它“从头管到尾”。结果不到三轮就出了问题——它要么忘了前面用户填过的信息要么把岗位匹配硬生生写成了职业建议。后来我把流程拆成三个 Agent各管一段问题一下清楚了。这件事让我想清楚了一个判断扣子上多 Agent 的真正价值不是把多个机器人堆在一起显得热闹而是把复杂任务拆成有边界的协作流程让每一步的输入、输出和失败点都变得可控。这篇文章我会按搭建顺序来讲先讲清楚概念再给一个能跑的最小案例最后把最容易踩的坑和排查路径一起说透。1. 先分清多 Agent 和单 Agent 到底差在哪里1.1 单 Agent 的“一口气跑完整件事”为什么不可靠很多人刚开始用大模型应用时习惯用一个 Agent 做所有事写提示词时把需求、背景、格式、工具、目标全部塞进去然后期望它一口气输出完整结果。小任务没问题。但任务一旦变复杂问题就来了。第一个问题是上下文会被拉长。Agent 在完成任务的过程中要一直记住用户最初的需求、中间过程、工具返回结果这些内容都会占用上下文窗口。上下文越长模型越容易忽略早期关键信息结果就是“前面说得清清楚楚后面还是自由发挥”。第二个问题是工具调用的不确定性。单 Agent 同时调用多个插件或接口时只要中间一个环节失败它可能不会停下来报错而是尝试“猜测”下一步。碰上模型比较聪明它可能自己绕过去碰上模型不够聪明就会产生一段看起来合理、实际上离题很远的输出。第三个问题是问题定位困难。环节一多你不知道结果是哪一步错的。是用户需求理解错了是检索插件没返回合适内容还是最后的生成格式没约束好单 Agent 把所有环节揉在一起调试时只能靠猜。1.2 多 Agent 的核心是“拆边界交结果”多 Agent 不是简单地把几个大模型实例串起来它的核心是职责拆分和结果交接。仍以简历匹配为例。我可以把流程拆成三个固定角色需求收集 Agent负责向用户提问整理出候选人的技能、年限、求职方向。岗位匹配 Agent接收上一步整理好的结构化信息调用招聘数据源返回匹配岗位列表。报告生成 Agent把匹配结果整理成一份书面报告控制语气和格式。这样的好处非常明显每个 Agent 只需要处理一小段任务上下文短输出结构更稳定如果结果不对可以快速判断是哪一环出了问题后续想替换模型或升级某个环节也不影响其他部分。更关键的是多 Agent 之间交换的不是自由文本而是结构化结果。理想状态下A Agent 的输出就是 B Agent 的输入类似工厂流水线每个工位只负责一个动作然后把半成品送到下一个工位。1.3 一个快速判断标准什么时候用单 Agent什么时候用多 Agent我一般看三个信号判断维度适合单 Agent适合多 Agent任务步骤3 步以内一次对话可完成超过 5 步且步骤之间有明显交接上下文要求必须记住整段对话的细节可以分段处理中间用字段传递失败后果输出偏差容易发现需要定位到具体环节维护成本低改一个提示词即可高需要维护多个提示词和流转逻辑一个简单原则如果任务里需要“先做 A再做 B再根据 B 的结果做 C”而且 A、B、C 都可能用到不同工具或不同上下文那就应该拆成多 Agent。如果任务只是“把一段话改得更专业”单 Agent 反而更高效。2. 从零搭建一个多 Agent 的 Coze 项目2.1 新建智能体时就要想好“最小分工”在扣子平台里新建智能体时第一件事不是急着写人设而是先画出任务链路。哪怕不画正式流程图也要在纸上写清楚用户进来先做什么第一步输出什么给第二步第二步需要调用什么工具最后一步如何把结果呈现给用户这一步看起来很基础但大多数多 Agent 项目失败不是输在技术而是输在分工不清。比如拆了三个 Agent但每个 Agent 都能做同样的事只是提示词顺序不同那等于没拆。更好用的做法是先写出“单 Agent 版”的完整流程找到最容易出错的两个节点再把它们拆开。不要为了拆而拆。2.2 用提示词把每个子 Agent 的职责焊死每个子 Agent 的提示词不需要很长但结构必须清晰。我在实践里会把提示词分成四个固定部分身份与职责边界你只负责什么不负责什么。输入约定你会收到什么格式的输入。处理规则面对输入时按什么规则处理。输出格式你最终必须输出什么结构。举一个需求收集 Agent 的提示词示例你是需求收集 Agent只负责收集用户的基本信息。 你会收到用户的一段自然语言描述。 请从中提取技能、工作年限、目标岗位、期望城市。 如果信息缺失最多追问一次。 最终必须输出 JSON {skills: [], years: null, target_role: , city: } 不要做岗位推荐不要写简历。这段提示词看起来简单但它把一个 Agent 的行为边界锁死了。你明确告诉它负责任什么、不负责什么、必须输出什么下游 Agent 才好接。2.3 接上模型、插件、知识库和变量在扣子平台里每个智能体或工作流节点都可以选择模型。多 Agent 场景下不同节点可以选择不同模型这是很值钱的能力。比如需求收集节点用响应更快的默认模型而报告生成节点用推理能力更强的模型成本也能更合理。插件方面常见的有搜索、网页读取、图片生成、文档解析等。多 Agent 里插件不能“谁都接”。最稳的做法是每个 Agent 只挂自己需要用到的插件否则它会尝试越权调用工具导致参数错误或资源浪费。知识库的价值也很容易被低估。如果你做的是一个垂类场景比如公司内部制度问答最好把知识库挂在检索相关的那一个 Agent 下面而不是挂在所有 Agent 里。不然每个 Agent 都可能去检索反而造成结果漂移。变量和数据库则用来保存跨节点状态。比如用户提出了多个条件需求收集 Agent 把条件写入变量后续节点读变量而不是靠“前面的 Agent 把条件夹在对话文本里传下来”。这一点后面会展开讲。2.4 编排多 Agent串行和并行两种基础形态多 Agent 在扣子里的落地方式通常是通过工作流节点连接。即便是不同入口底层逻辑也差不多每个节点是一个带提示词、模型、工具的执行单元节点之间通过参数传递数据。第一种是串行。A 的输出给 BB 的输出给 C。适合“需求 → 处理 → 输出”这类固定流程。第二种是并行拆分。把一个大任务拆成几个独立子任务同时让多个 Agent 并行处理最后汇总。比如做竞品分析可以同时让一个 Agent 查价格、一个 Agent 查功能、一个 Agent 查口碑最后统一汇总成报告。并行模式能明显降低整体用时但要注意几点子任务之间最好不要有依赖汇总节点必须能容错——哪怕有一两个子任务失败也不能让整个流程崩溃。通常我会给每个并行分支设置超时和默认兜底值。2.5 最小可运行示例需求分析-方案生成-代码审查为了让概念更落地下面给出一个最简单、也最容易复现的三 Agent 流程。Agent 1需求分析。输入用户描述输出结构化需求比如“功能清单”和“优先级”。Agent 2方案生成。接收 Agent 1 的结构化需求输出一份技术方案 Markdown。Agent 3代码审查。接收 Agent 1 的需求和 Agent 2 的方案输出“风险点清单”和“修改建议”。流程跑通后你会发现另一个收益你可以在不改动其他 Agent 的前提下单独调优 Agent 2 的模型或提示词。这种“可单独替换”的能力才是多 Agent 最有价值的地方。3. 多 Agent 的真正难点在通信和状态不在提示词3.1 节点间传递参数别靠“AI自动理解上下文”很多从单 Agent 转向多 Agent 的人会下意识地依赖“上下文”。他们会认为前一个 Agent 输出的文本后一个 Agent 应该能看懂。但在工程上这非常不可靠。文本是给模型看的字段才是给流程用的。我的建议是每个节点结束时把所有需要传给下游的数据都写成一个明确的字段。哪怕只有一个字段也要用 JSON 或固定格式输出。下游节点读取时也是读字段而不是从整段文本里猜。这样做的好处是鲁棒性更强。Agent 1 稍微改变措辞不会影响 Agent 2 的输入解析。调试时也能一眼看到数据在哪一步发生了改变。3.2 输出格式要结构化最好让 Agent 只负责填空在多 Agent 协作中最怕的是某个 Agent 输出一段散文下游还得用大模型去解析。我在设计输出格式时通常会提前定好一个 JSON Schema。例如{ candidate: { skills: [Python, LangChain], years: 5, target_role: 算法工程师 }, matched_jobs: [ { title: 大模型应用工程师, score: 85, reason: 3 年大模型应用开发经验匹配 } ] }然后在提示词里明确要求只输出 JSON不加解释。这样下游节点就不需要再承担“解析”任务直接读取字段大大降低出错率。如果担心模型输出不合法 JSON可以在下游加一个“格式清洗”节点做字符串截断、括号匹配或正则修复。但最好还是在提示词里把格式要求写死不要每次都靠补救。3.3 用变量和数据库保存跨轮状态多 Agent 的另一个坑是“跨轮记忆”。如果一个流程需要用户分多轮输入信息你不能默认所有 Agent 都知道上一轮发生了什么。正确做法是把用户在每一轮输入的关键信息写入变量或数据库。后续 Agent 从变量库读值而不是试图从聊天记录里推断。比如做一个“图书荐购智能体”第一轮用户说“我喜欢推理小说”第二轮说“预算 100 以内”第三轮说“要电子书”。如果只靠对话历史第三个 Agent 很可能只看到最后一轮的内容把前面的条件丢掉。但如果你每轮把偏好、预算、格式都写入变量最后一个推荐 Agent 读取的永远是一个完整条件集。这在扣子里属于常用能力做多 Agent 前最好先熟悉。3.4 给插件调用和模型输出留好重试与降级真实运行中插件返回超时、接口限流、模型响应异常都是常态。多 Agent 流程里任何一个节点失败都会中断整条链路。所以我在设计时会遵守一个原则每个关键节点都要有“失败出口”。具体来说插件调用失败时可以重试一次不要立刻失败。重试仍失败时返回一个默认值或让上层节点走替代分支。模型输出不符合格式要求时可以自动追加一次“修正提示”让它重新生成。如果某一路分支连续失败流程最好能够跳过该分支而不是整体崩溃。这个原则比写一个“完美流程”更重要。你搭建的不是一个 demo而是一条可能被用户反复使用的链路。3.5 每次联调都要看日志扣子平台的运行日志可能因版本不同而变化但一定要在调试阶段养成看日志的习惯。日志能告诉你的信息包括每个节点的输入是什么、调用模型用了多久、插件返回了什么、在哪一步发生了超时。很多看起来“玄学”的问题其实只要看了日志就能定位。我建议在跑多 Agent 流程时每完成一个节点都先单独验证一次输出再做节点间联调。不要等到全部接好才测试否则一旦报错你都不知道该改哪里。4. 工作流和多 Agent 是什么关系Coze 和 Dify 怎么选4.1 工作流是骨架Agent 是决策单元在多 Agent 场景里工作流和 Agent 常常被搞混。其实可以这样理解工作流是用来规定“先做什么、后做什么、失败怎么走”的骨架Agent 是骨架上的决策单元负责具体理解、判断和生成内容。工作流负责确定性Agent 负责非确定性。在扣子里你可以把多个 Agent 放在工作流节点中让它们按固定顺序执行也可以让一个 Agent 在运行时决定下一步调用哪个子流程。前者更像“编排”后者更像“自主决策”。多 Agent 项目通常两者结合外层用工作流保证稳定内层用 Agent 处理变化。4.2 固定流程用工作流动态决策用多 Agent如果你的业务场景是“用户点一个按钮系统做同样的事”那本质上是一个固定流程不一定需要多个 Agent。你可以用工作流把每一步固定下来中间放几个大模型节点效果已经很稳定。如果你做的是助手类产品用户目标千变万化系统需要自己判断该调哪个工具、该走哪条分支这时候更适合“一个主 Agent 多个子 Agent 或工具”的动态决策模式。多 Agent 不等于没有规则。恰恰相反它需要更明确的规则否则没有任何护栏。4.3 Coze 与 Dify 这类平台的定位差别热词里经常能看到 Coze 和 Dify 对比这里可以说一下我的体感。Coze扣子给我的感觉是“快速把想法变成可交互应用”它更擅长做内容生成类、工具编排类、社交或营销场景。Dify 更像一个“端到端大模型应用开发平台”它的工程化属性更强适合对数据集、日志、权限、API 管理要求更高的生产环境。但这两者不是替代关系。你完全可以先用扣子做原型验证再迁移到更工程化的平台也可以同时用两个平台服务不同项目。选择的关键不是哪个更“高级”而是你的团队更重视什么。如果目标是两天内上线一个可体验的 AI 应用扣子更省力如果目标是长期维护一个复杂的 To B 应用Dify 那样更完整的后端能力会更合适。4.4 别把“平台差异”当成“能力天花板”很多人在社区里争论“Coze 能不能做复杂系统”“Dify 比 Coze 强多少”其实大多是拿单个功能点做对比。我更建议先把流程想清楚。因为无论哪个平台底层都需要你处理好提示词、数据、工具调用、错误处理这些事。平台能提供多少便利决定了你从 0 到 1 有多快平台欠缺的工程能力决定了你从 1 到 10 要补多少课。多 Agent 项目最大的天花板不是工具而是你有没有把任务边界、数据流和失败处理定义清楚。5. 实战搭一个能跑的“图书荐购多 Agent 智能体”5.1 场景与分工从热词里看到很多人在搜“扣子如何搭建图书荐购智能体”这个场景很适合做多 Agent 教学。假设用户输入一句话“想找几本适合下班后读的推理小说预算 80 以内最好有电子书。”这个需求里有四个关键维度类型、场景、预算、格式。如果只用一个 Agent它可能理解成“随便推荐几本书”。但拆成多 Agent 后每个环节都会专门处理一个维度。我设计成三个 Agent用户需求理解 Agent从自然语言中提取类型、场景、预算、格式。图书检索 Agent使用图书数据库或搜索插件按条件过滤候选图书。推荐结果 Agent把候选图书整理成推荐清单包含书名、理由、价格、阅读场景。分工清楚后每个 Agent 的提示词都能写得很短。5.2 三个 Agent 的配置拆解Agent 1需求理解 Agent输入用户的一句话。输出JSON 字段。提示词要点只提取信息不推荐图书。你只做需求提取。 输出 JSON {genre: 推理, scene: 下班后, budget_max: 80, format: 电子书} 字段不确定就填空字符串。Agent 2图书检索 Agent输入Agent 1 输出的 JSON。能力调用图书搜索插件或本地知识库。提示词要点按字段过滤不要把条件丢了。这个节点非常容易出现“过度推荐”。要严格约束它只返回候选图书列表不要自己加书评。Agent 3推荐结果 Agent输入Agent 2 返回的图书列表。输出一段用户能直接阅读的推荐文案。提示词要点控制在 4 本书以内每本书给出推荐理由理由必须来自候选列表里的字段不要编造。5.3 联调与测试搭建完成后先用三种典型输入测试信息齐全的输入看三个 Agent 是否都能正常完成。只有部分信息的输入看 Agent 1 是否补问或者是否给默认值。模糊输入比如“我要买书”看是否会崩。我在测试时最常遇到的问题是 Agent 2 搜索不到结果。这时候先不要急着改提示词而是看是不是插件没配好或者预算字段没有传过来。如果结果是空的可以加一个兜底逻辑搜索不到时返回一个固定提示而不是让流程中断。5.4 扩展成其他场景这个案例的本质是“需求提取 → 数据检索 → 结果包装”换一下领域就能变成岗位推荐、电影推荐、课程推荐、软件工具推荐。你也可以继续拆在推荐结果之前加一个“人工审核 Agent”或加一个“对比表格生成 Agent”。每多一个环节流程的可控性都会提高但维护成本也会上升。所以扩展之前先问自己新增的 Agent 是不是真的承担了一个单独职责如果是就拆如果不是就继续留在原提示词里。6. 新手上路最容易踩的坑和排查链路6.1 六个高频坑第一个坑是“一个 Agent 里塞了全流程”。表现为提示词很长但仍会出现结果不稳定。第二个坑是“多个 Agent 职责重叠”。比如三个 Agent 都能调用搜索插件最终输出混乱不知道信谁的。第三个坑是“上下文传了但传的是散文”。下游 Agent 解析困难只能靠再跑一次大模型来提取信息成本和错误率都上去了。第四个坑是“插件错挂在每个 Agent 上”。既浪费调用次数又容易在不需要搜索的时候触发搜索导致远离主题。第五个坑是“不知道资源库为什么没生效”。很多人在扣子平台创建了知识库但智能体里看不到原因多半是知识库没有关联到当前项目或者访问权限没开。这通常不是 Bug而是关联步骤没完成。第六个坑是“没有日志意识”。报错或结果异常时直接在界面上反复试却不知道运行日志可以定位到具体节点。6.2 正确的排查顺序当多 Agent 流程出现问题时我会按固定顺序排查先看现象是完全没有输出还是输出但格式不对是单次失败还是每次都失败再看输入用户数据是否到达了预期节点字段有没有缺失再看环境模型是否有权限插件是否在线知识库是否关联再看参数超时时间、重试次数、并发数是不是不合理再看模型输出是否遵守了输出格式有没有把字段写错最后看平台限制免费版有哪些限额并发限制多少模型上下文是否够用这个顺序能覆盖掉 90% 以上的常见问题。怕的就是一上来就改提示词最后发现是插件 key 过期了。6.3 一个更稳妥的上手路径对于新手我强烈建议不要一上来就搭三个以上 Agent。先用一个最简单的单 Agent 跑通一个需求。然后把它拆成两个节点一个负责提取输入一个负责生成输出。跑通之后再逐步加第三个、第四个。每一步之间都要做“最小验证”。加上新 Agent 后先只测试它的独立输出再测试它和上一个 Agent 的联动。不要等到全部搭完再去处理一个离奇的大错误。“先跑通再优化”这句话在多 Agent 里尤其适用。你先把一条最小链路走通再考虑并行、重试、降级这些工程能力心智负担会小很多。7. 多 Agent 的适用边界别把简单任务也硬拆成 Agent7.1 适合什么不适合什么多 Agent 并不适合所有场景。我见过有人做一个“天气问答”也要拆三个 Agent成本高、延迟高最后效果还不如一个普通大模型节点。适合多 Agent 的场景通常有几个特征任务步骤多且步骤之间边界清晰。不同步骤需要不同工具或不同数据源。需要分角色审查比如“先生成再审核”。输出必须能追踪是哪一步产生的方便修正。不适合多 Agent 的场景也有几个典型简单问答一步就能完成拆了反而损失稳定性。对延迟极度敏感的场景多节点调用会增加明显耗时。完全没有评估标准的场景。多 Agent 拆得越细越容易在某个环节“一本正经地胡说八道”。预算有限且调用量大。多 Agent 意味着多次模型调用成本会成倍上升。7.2 选型清单在做多 Agent 项目前我一般会填一张很简单的清单问题判断方向这个任务有没有固定流程有优先工作流没有考虑主 Agent 分发每个子任务是不是需要独立记忆是拆成独立 Agent子任务之间传递的是字段还是长文本字段为主才适合多 Agent失败一个环节用户能接受吗接受度低就加降级和重试能不能用日志追踪到单个子任务不能先不要上多 Agent填完清单后你会发现很多项目其实并不需要多 Agent而是需要更好的单 Agent 提示词和编排。7.3 回到主判断我写这篇教程最想传达的一句话是多 Agent 解决的不是“模型不够聪明”的问题而是“流程不可控”的问题。在 Coze 扣子上做多 Agent重点不是把多个大模型叠在一起而是为每个节点定义好输入、输出和失败条件。你真正要学会的能力是如何把一个大任务拆成一段段可验证的小任务然后让它们像流水线一样协作。如果你现在正准备开始我建议你先不要急着把项目做复杂。从一个能跑通的最小双 Agent 流程开始记录每一步的输入输出看清日志再逐步扩展。等你能清楚说出“这个 Agent 负责什么、它的上游是谁、下游是谁、失败时怎么办”的时候你才算真正开始掌握多 Agent 实战。
Coze多Agent实战：从拆分流程到掌控复杂任务的完整指南
前阵子我用 Coze扣子搭一个稍微复杂的小应用用户提交需求系统自动生成一份简历再去匹配几个岗位方向。一开始我只做了一个智能体让它“从头管到尾”。结果不到三轮就出了问题——它要么忘了前面用户填过的信息要么把岗位匹配硬生生写成了职业建议。后来我把流程拆成三个 Agent各管一段问题一下清楚了。这件事让我想清楚了一个判断扣子上多 Agent 的真正价值不是把多个机器人堆在一起显得热闹而是把复杂任务拆成有边界的协作流程让每一步的输入、输出和失败点都变得可控。这篇文章我会按搭建顺序来讲先讲清楚概念再给一个能跑的最小案例最后把最容易踩的坑和排查路径一起说透。1. 先分清多 Agent 和单 Agent 到底差在哪里1.1 单 Agent 的“一口气跑完整件事”为什么不可靠很多人刚开始用大模型应用时习惯用一个 Agent 做所有事写提示词时把需求、背景、格式、工具、目标全部塞进去然后期望它一口气输出完整结果。小任务没问题。但任务一旦变复杂问题就来了。第一个问题是上下文会被拉长。Agent 在完成任务的过程中要一直记住用户最初的需求、中间过程、工具返回结果这些内容都会占用上下文窗口。上下文越长模型越容易忽略早期关键信息结果就是“前面说得清清楚楚后面还是自由发挥”。第二个问题是工具调用的不确定性。单 Agent 同时调用多个插件或接口时只要中间一个环节失败它可能不会停下来报错而是尝试“猜测”下一步。碰上模型比较聪明它可能自己绕过去碰上模型不够聪明就会产生一段看起来合理、实际上离题很远的输出。第三个问题是问题定位困难。环节一多你不知道结果是哪一步错的。是用户需求理解错了是检索插件没返回合适内容还是最后的生成格式没约束好单 Agent 把所有环节揉在一起调试时只能靠猜。1.2 多 Agent 的核心是“拆边界交结果”多 Agent 不是简单地把几个大模型实例串起来它的核心是职责拆分和结果交接。仍以简历匹配为例。我可以把流程拆成三个固定角色需求收集 Agent负责向用户提问整理出候选人的技能、年限、求职方向。岗位匹配 Agent接收上一步整理好的结构化信息调用招聘数据源返回匹配岗位列表。报告生成 Agent把匹配结果整理成一份书面报告控制语气和格式。这样的好处非常明显每个 Agent 只需要处理一小段任务上下文短输出结构更稳定如果结果不对可以快速判断是哪一环出了问题后续想替换模型或升级某个环节也不影响其他部分。更关键的是多 Agent 之间交换的不是自由文本而是结构化结果。理想状态下A Agent 的输出就是 B Agent 的输入类似工厂流水线每个工位只负责一个动作然后把半成品送到下一个工位。1.3 一个快速判断标准什么时候用单 Agent什么时候用多 Agent我一般看三个信号判断维度适合单 Agent适合多 Agent任务步骤3 步以内一次对话可完成超过 5 步且步骤之间有明显交接上下文要求必须记住整段对话的细节可以分段处理中间用字段传递失败后果输出偏差容易发现需要定位到具体环节维护成本低改一个提示词即可高需要维护多个提示词和流转逻辑一个简单原则如果任务里需要“先做 A再做 B再根据 B 的结果做 C”而且 A、B、C 都可能用到不同工具或不同上下文那就应该拆成多 Agent。如果任务只是“把一段话改得更专业”单 Agent 反而更高效。2. 从零搭建一个多 Agent 的 Coze 项目2.1 新建智能体时就要想好“最小分工”在扣子平台里新建智能体时第一件事不是急着写人设而是先画出任务链路。哪怕不画正式流程图也要在纸上写清楚用户进来先做什么第一步输出什么给第二步第二步需要调用什么工具最后一步如何把结果呈现给用户这一步看起来很基础但大多数多 Agent 项目失败不是输在技术而是输在分工不清。比如拆了三个 Agent但每个 Agent 都能做同样的事只是提示词顺序不同那等于没拆。更好用的做法是先写出“单 Agent 版”的完整流程找到最容易出错的两个节点再把它们拆开。不要为了拆而拆。2.2 用提示词把每个子 Agent 的职责焊死每个子 Agent 的提示词不需要很长但结构必须清晰。我在实践里会把提示词分成四个固定部分身份与职责边界你只负责什么不负责什么。输入约定你会收到什么格式的输入。处理规则面对输入时按什么规则处理。输出格式你最终必须输出什么结构。举一个需求收集 Agent 的提示词示例你是需求收集 Agent只负责收集用户的基本信息。 你会收到用户的一段自然语言描述。 请从中提取技能、工作年限、目标岗位、期望城市。 如果信息缺失最多追问一次。 最终必须输出 JSON {skills: [], years: null, target_role: , city: } 不要做岗位推荐不要写简历。这段提示词看起来简单但它把一个 Agent 的行为边界锁死了。你明确告诉它负责任什么、不负责什么、必须输出什么下游 Agent 才好接。2.3 接上模型、插件、知识库和变量在扣子平台里每个智能体或工作流节点都可以选择模型。多 Agent 场景下不同节点可以选择不同模型这是很值钱的能力。比如需求收集节点用响应更快的默认模型而报告生成节点用推理能力更强的模型成本也能更合理。插件方面常见的有搜索、网页读取、图片生成、文档解析等。多 Agent 里插件不能“谁都接”。最稳的做法是每个 Agent 只挂自己需要用到的插件否则它会尝试越权调用工具导致参数错误或资源浪费。知识库的价值也很容易被低估。如果你做的是一个垂类场景比如公司内部制度问答最好把知识库挂在检索相关的那一个 Agent 下面而不是挂在所有 Agent 里。不然每个 Agent 都可能去检索反而造成结果漂移。变量和数据库则用来保存跨节点状态。比如用户提出了多个条件需求收集 Agent 把条件写入变量后续节点读变量而不是靠“前面的 Agent 把条件夹在对话文本里传下来”。这一点后面会展开讲。2.4 编排多 Agent串行和并行两种基础形态多 Agent 在扣子里的落地方式通常是通过工作流节点连接。即便是不同入口底层逻辑也差不多每个节点是一个带提示词、模型、工具的执行单元节点之间通过参数传递数据。第一种是串行。A 的输出给 BB 的输出给 C。适合“需求 → 处理 → 输出”这类固定流程。第二种是并行拆分。把一个大任务拆成几个独立子任务同时让多个 Agent 并行处理最后汇总。比如做竞品分析可以同时让一个 Agent 查价格、一个 Agent 查功能、一个 Agent 查口碑最后统一汇总成报告。并行模式能明显降低整体用时但要注意几点子任务之间最好不要有依赖汇总节点必须能容错——哪怕有一两个子任务失败也不能让整个流程崩溃。通常我会给每个并行分支设置超时和默认兜底值。2.5 最小可运行示例需求分析-方案生成-代码审查为了让概念更落地下面给出一个最简单、也最容易复现的三 Agent 流程。Agent 1需求分析。输入用户描述输出结构化需求比如“功能清单”和“优先级”。Agent 2方案生成。接收 Agent 1 的结构化需求输出一份技术方案 Markdown。Agent 3代码审查。接收 Agent 1 的需求和 Agent 2 的方案输出“风险点清单”和“修改建议”。流程跑通后你会发现另一个收益你可以在不改动其他 Agent 的前提下单独调优 Agent 2 的模型或提示词。这种“可单独替换”的能力才是多 Agent 最有价值的地方。3. 多 Agent 的真正难点在通信和状态不在提示词3.1 节点间传递参数别靠“AI自动理解上下文”很多从单 Agent 转向多 Agent 的人会下意识地依赖“上下文”。他们会认为前一个 Agent 输出的文本后一个 Agent 应该能看懂。但在工程上这非常不可靠。文本是给模型看的字段才是给流程用的。我的建议是每个节点结束时把所有需要传给下游的数据都写成一个明确的字段。哪怕只有一个字段也要用 JSON 或固定格式输出。下游节点读取时也是读字段而不是从整段文本里猜。这样做的好处是鲁棒性更强。Agent 1 稍微改变措辞不会影响 Agent 2 的输入解析。调试时也能一眼看到数据在哪一步发生了改变。3.2 输出格式要结构化最好让 Agent 只负责填空在多 Agent 协作中最怕的是某个 Agent 输出一段散文下游还得用大模型去解析。我在设计输出格式时通常会提前定好一个 JSON Schema。例如{ candidate: { skills: [Python, LangChain], years: 5, target_role: 算法工程师 }, matched_jobs: [ { title: 大模型应用工程师, score: 85, reason: 3 年大模型应用开发经验匹配 } ] }然后在提示词里明确要求只输出 JSON不加解释。这样下游节点就不需要再承担“解析”任务直接读取字段大大降低出错率。如果担心模型输出不合法 JSON可以在下游加一个“格式清洗”节点做字符串截断、括号匹配或正则修复。但最好还是在提示词里把格式要求写死不要每次都靠补救。3.3 用变量和数据库保存跨轮状态多 Agent 的另一个坑是“跨轮记忆”。如果一个流程需要用户分多轮输入信息你不能默认所有 Agent 都知道上一轮发生了什么。正确做法是把用户在每一轮输入的关键信息写入变量或数据库。后续 Agent 从变量库读值而不是试图从聊天记录里推断。比如做一个“图书荐购智能体”第一轮用户说“我喜欢推理小说”第二轮说“预算 100 以内”第三轮说“要电子书”。如果只靠对话历史第三个 Agent 很可能只看到最后一轮的内容把前面的条件丢掉。但如果你每轮把偏好、预算、格式都写入变量最后一个推荐 Agent 读取的永远是一个完整条件集。这在扣子里属于常用能力做多 Agent 前最好先熟悉。3.4 给插件调用和模型输出留好重试与降级真实运行中插件返回超时、接口限流、模型响应异常都是常态。多 Agent 流程里任何一个节点失败都会中断整条链路。所以我在设计时会遵守一个原则每个关键节点都要有“失败出口”。具体来说插件调用失败时可以重试一次不要立刻失败。重试仍失败时返回一个默认值或让上层节点走替代分支。模型输出不符合格式要求时可以自动追加一次“修正提示”让它重新生成。如果某一路分支连续失败流程最好能够跳过该分支而不是整体崩溃。这个原则比写一个“完美流程”更重要。你搭建的不是一个 demo而是一条可能被用户反复使用的链路。3.5 每次联调都要看日志扣子平台的运行日志可能因版本不同而变化但一定要在调试阶段养成看日志的习惯。日志能告诉你的信息包括每个节点的输入是什么、调用模型用了多久、插件返回了什么、在哪一步发生了超时。很多看起来“玄学”的问题其实只要看了日志就能定位。我建议在跑多 Agent 流程时每完成一个节点都先单独验证一次输出再做节点间联调。不要等到全部接好才测试否则一旦报错你都不知道该改哪里。4. 工作流和多 Agent 是什么关系Coze 和 Dify 怎么选4.1 工作流是骨架Agent 是决策单元在多 Agent 场景里工作流和 Agent 常常被搞混。其实可以这样理解工作流是用来规定“先做什么、后做什么、失败怎么走”的骨架Agent 是骨架上的决策单元负责具体理解、判断和生成内容。工作流负责确定性Agent 负责非确定性。在扣子里你可以把多个 Agent 放在工作流节点中让它们按固定顺序执行也可以让一个 Agent 在运行时决定下一步调用哪个子流程。前者更像“编排”后者更像“自主决策”。多 Agent 项目通常两者结合外层用工作流保证稳定内层用 Agent 处理变化。4.2 固定流程用工作流动态决策用多 Agent如果你的业务场景是“用户点一个按钮系统做同样的事”那本质上是一个固定流程不一定需要多个 Agent。你可以用工作流把每一步固定下来中间放几个大模型节点效果已经很稳定。如果你做的是助手类产品用户目标千变万化系统需要自己判断该调哪个工具、该走哪条分支这时候更适合“一个主 Agent 多个子 Agent 或工具”的动态决策模式。多 Agent 不等于没有规则。恰恰相反它需要更明确的规则否则没有任何护栏。4.3 Coze 与 Dify 这类平台的定位差别热词里经常能看到 Coze 和 Dify 对比这里可以说一下我的体感。Coze扣子给我的感觉是“快速把想法变成可交互应用”它更擅长做内容生成类、工具编排类、社交或营销场景。Dify 更像一个“端到端大模型应用开发平台”它的工程化属性更强适合对数据集、日志、权限、API 管理要求更高的生产环境。但这两者不是替代关系。你完全可以先用扣子做原型验证再迁移到更工程化的平台也可以同时用两个平台服务不同项目。选择的关键不是哪个更“高级”而是你的团队更重视什么。如果目标是两天内上线一个可体验的 AI 应用扣子更省力如果目标是长期维护一个复杂的 To B 应用Dify 那样更完整的后端能力会更合适。4.4 别把“平台差异”当成“能力天花板”很多人在社区里争论“Coze 能不能做复杂系统”“Dify 比 Coze 强多少”其实大多是拿单个功能点做对比。我更建议先把流程想清楚。因为无论哪个平台底层都需要你处理好提示词、数据、工具调用、错误处理这些事。平台能提供多少便利决定了你从 0 到 1 有多快平台欠缺的工程能力决定了你从 1 到 10 要补多少课。多 Agent 项目最大的天花板不是工具而是你有没有把任务边界、数据流和失败处理定义清楚。5. 实战搭一个能跑的“图书荐购多 Agent 智能体”5.1 场景与分工从热词里看到很多人在搜“扣子如何搭建图书荐购智能体”这个场景很适合做多 Agent 教学。假设用户输入一句话“想找几本适合下班后读的推理小说预算 80 以内最好有电子书。”这个需求里有四个关键维度类型、场景、预算、格式。如果只用一个 Agent它可能理解成“随便推荐几本书”。但拆成多 Agent 后每个环节都会专门处理一个维度。我设计成三个 Agent用户需求理解 Agent从自然语言中提取类型、场景、预算、格式。图书检索 Agent使用图书数据库或搜索插件按条件过滤候选图书。推荐结果 Agent把候选图书整理成推荐清单包含书名、理由、价格、阅读场景。分工清楚后每个 Agent 的提示词都能写得很短。5.2 三个 Agent 的配置拆解Agent 1需求理解 Agent输入用户的一句话。输出JSON 字段。提示词要点只提取信息不推荐图书。你只做需求提取。 输出 JSON {genre: 推理, scene: 下班后, budget_max: 80, format: 电子书} 字段不确定就填空字符串。Agent 2图书检索 Agent输入Agent 1 输出的 JSON。能力调用图书搜索插件或本地知识库。提示词要点按字段过滤不要把条件丢了。这个节点非常容易出现“过度推荐”。要严格约束它只返回候选图书列表不要自己加书评。Agent 3推荐结果 Agent输入Agent 2 返回的图书列表。输出一段用户能直接阅读的推荐文案。提示词要点控制在 4 本书以内每本书给出推荐理由理由必须来自候选列表里的字段不要编造。5.3 联调与测试搭建完成后先用三种典型输入测试信息齐全的输入看三个 Agent 是否都能正常完成。只有部分信息的输入看 Agent 1 是否补问或者是否给默认值。模糊输入比如“我要买书”看是否会崩。我在测试时最常遇到的问题是 Agent 2 搜索不到结果。这时候先不要急着改提示词而是看是不是插件没配好或者预算字段没有传过来。如果结果是空的可以加一个兜底逻辑搜索不到时返回一个固定提示而不是让流程中断。5.4 扩展成其他场景这个案例的本质是“需求提取 → 数据检索 → 结果包装”换一下领域就能变成岗位推荐、电影推荐、课程推荐、软件工具推荐。你也可以继续拆在推荐结果之前加一个“人工审核 Agent”或加一个“对比表格生成 Agent”。每多一个环节流程的可控性都会提高但维护成本也会上升。所以扩展之前先问自己新增的 Agent 是不是真的承担了一个单独职责如果是就拆如果不是就继续留在原提示词里。6. 新手上路最容易踩的坑和排查链路6.1 六个高频坑第一个坑是“一个 Agent 里塞了全流程”。表现为提示词很长但仍会出现结果不稳定。第二个坑是“多个 Agent 职责重叠”。比如三个 Agent 都能调用搜索插件最终输出混乱不知道信谁的。第三个坑是“上下文传了但传的是散文”。下游 Agent 解析困难只能靠再跑一次大模型来提取信息成本和错误率都上去了。第四个坑是“插件错挂在每个 Agent 上”。既浪费调用次数又容易在不需要搜索的时候触发搜索导致远离主题。第五个坑是“不知道资源库为什么没生效”。很多人在扣子平台创建了知识库但智能体里看不到原因多半是知识库没有关联到当前项目或者访问权限没开。这通常不是 Bug而是关联步骤没完成。第六个坑是“没有日志意识”。报错或结果异常时直接在界面上反复试却不知道运行日志可以定位到具体节点。6.2 正确的排查顺序当多 Agent 流程出现问题时我会按固定顺序排查先看现象是完全没有输出还是输出但格式不对是单次失败还是每次都失败再看输入用户数据是否到达了预期节点字段有没有缺失再看环境模型是否有权限插件是否在线知识库是否关联再看参数超时时间、重试次数、并发数是不是不合理再看模型输出是否遵守了输出格式有没有把字段写错最后看平台限制免费版有哪些限额并发限制多少模型上下文是否够用这个顺序能覆盖掉 90% 以上的常见问题。怕的就是一上来就改提示词最后发现是插件 key 过期了。6.3 一个更稳妥的上手路径对于新手我强烈建议不要一上来就搭三个以上 Agent。先用一个最简单的单 Agent 跑通一个需求。然后把它拆成两个节点一个负责提取输入一个负责生成输出。跑通之后再逐步加第三个、第四个。每一步之间都要做“最小验证”。加上新 Agent 后先只测试它的独立输出再测试它和上一个 Agent 的联动。不要等到全部搭完再去处理一个离奇的大错误。“先跑通再优化”这句话在多 Agent 里尤其适用。你先把一条最小链路走通再考虑并行、重试、降级这些工程能力心智负担会小很多。7. 多 Agent 的适用边界别把简单任务也硬拆成 Agent7.1 适合什么不适合什么多 Agent 并不适合所有场景。我见过有人做一个“天气问答”也要拆三个 Agent成本高、延迟高最后效果还不如一个普通大模型节点。适合多 Agent 的场景通常有几个特征任务步骤多且步骤之间边界清晰。不同步骤需要不同工具或不同数据源。需要分角色审查比如“先生成再审核”。输出必须能追踪是哪一步产生的方便修正。不适合多 Agent 的场景也有几个典型简单问答一步就能完成拆了反而损失稳定性。对延迟极度敏感的场景多节点调用会增加明显耗时。完全没有评估标准的场景。多 Agent 拆得越细越容易在某个环节“一本正经地胡说八道”。预算有限且调用量大。多 Agent 意味着多次模型调用成本会成倍上升。7.2 选型清单在做多 Agent 项目前我一般会填一张很简单的清单问题判断方向这个任务有没有固定流程有优先工作流没有考虑主 Agent 分发每个子任务是不是需要独立记忆是拆成独立 Agent子任务之间传递的是字段还是长文本字段为主才适合多 Agent失败一个环节用户能接受吗接受度低就加降级和重试能不能用日志追踪到单个子任务不能先不要上多 Agent填完清单后你会发现很多项目其实并不需要多 Agent而是需要更好的单 Agent 提示词和编排。7.3 回到主判断我写这篇教程最想传达的一句话是多 Agent 解决的不是“模型不够聪明”的问题而是“流程不可控”的问题。在 Coze 扣子上做多 Agent重点不是把多个大模型叠在一起而是为每个节点定义好输入、输出和失败条件。你真正要学会的能力是如何把一个大任务拆成一段段可验证的小任务然后让它们像流水线一样协作。如果你现在正准备开始我建议你先不要急着把项目做复杂。从一个能跑通的最小双 Agent 流程开始记录每一步的输入输出看清日志再逐步扩展。等你能清楚说出“这个 Agent 负责什么、它的上游是谁、下游是谁、失败时怎么办”的时候你才算真正开始掌握多 Agent 实战。