这段时间我一直在折腾 Coze 多智能体协作开发从最初拿单 Agent 搭个聊天机器人到后来尝试在一个项目里让多个智能体分工配合整个过程踩了不少坑也积累了一些特别值得记录的实操经验。很多人看到“零代码”“多智能体”这两个词第一反应是觉得门槛很低但真正上手之后才发现平台把底层工程难度降下来了可你要是不理解多智能体协作的设计逻辑做出来的东西很容易“四不像”。这篇我就拿一个实际案例为主线把 Coze 上搭建多智能体协作系统的完整流程、关键配置、避坑点一次讲透。我做的案例是一个“内容创作智能体团队”核心任务很简单你给我一个选题方向系统自动完成资料搜集、大纲规划、正文撰写、校对润色、多平台格式适配最后直接输出一篇可发布的成品文章。这个项目非常适合用来理解多智能体协作因为它天然需要不同角色分工有人找资料、有人写内容、有人检查质量。如果你正在做智能客服、行业调研报告生成、营销文案生产这类需求或者单纯想搞明白 Coze 的多 Agent 模式到底怎么玩这篇内容应该能帮你省下不少摸索时间。1. 整体设计与思路拆解1.1 为什么单智能体不够用多智能体协作解决的真实痛点很多人最开始习惯把所有需求塞给一个智能体提示词写得特别长恨不得把各行各业的专家知识都写在里面。我也这么干过结果很快就发现单 Agent 有几个非常头疼的问题第一提示词越长模型越容易“注意力涣散”开头让它查资料、中间让它写文章、结尾让它校对它往往做着做着就忘了前面说的要求第二一个角色的知识边界很难兼顾多个专业方向既当行业分析师又当文案编辑最后产出的内容通常平庸得让人抓狂第三没法做质量闭环写出来的东西对不对、好不好没有人把关全靠模型自觉。多智能体协作解决的就是这些痛点。它的本质是把一个复杂任务拆成多个专业子任务每个智能体只负责一个明确的小目标像真实公司的项目组一样配合。用生活化的例子来理解你一个人要开一家餐厅既当采购又当厨师还当前台肯定忙不过来但如果你雇了采购员、厨师、服务员每个人都只做自己最擅长的事整体效率和质量都会上去。Coze 的多 Agent 模式就是帮你把这支“团队”组建起来的管理系统。1.2 为什么选 Coze 做多智能体落地平台能力盘点市面上支持多智能体的平台现在不少比如 Dify、AgentScope、AutoGen 这些它们各有特色但要么需要写不少代码要么部署环境折腾人。我最终把主力放在 Coze 上核心原因是零代码门槛和平台的一体化能力。Coze 本身提供了非常完整的智能体开发闭环多 Agent 模式帮你管理多个智能体之间的协作关系工作流模块让你用拖拽节点的方式编排复杂流程知识库接入了 RAG 能力可以上传文档做私有知识问答插件生态覆盖了搜索、图片生成、文档解析、语音合成等高频场景还有变量和数据库用于跨轮次记忆。最关键是发布渠道很友好一键可以发布到飞书、微信公众号、网页应用等平台方便真实业务落地。对大部分人来说不需要自己折腾向量数据库不需要编写 Agent 调度代码把思考重心放在“如何设计好每个智能体的分工”这才是多智能体项目成败的关键。1.3 案例总览内容创作智能体团队的三层架构我设计的这套系统不是简单地把几个 Bot 塞在一起而是参考了真实编辑部的工作流分了四层主智能体主编负责接收用户需求、拆解任务、分发任务、汇总结果。子智能体研究员负责搜索资料、整理事实、提炼素材是对抗“内容空洞”的关键角色。子智能体文案撰写负责根据大纲和素材撰写正文专注文字表达。子智能体校对优化负责检查错别字、逻辑漏洞、语气风格一致性并对内容进行最后打磨。主智能体不直接写文章它只做调度研究员、文案、校对各管一段。这样的设计有一个非常大的好处每个智能体的提示词可以写得更专注、更极致而不需要在一个超长提示词里塞下所有角色指令。后面我会详细拆解每个角色的提示词怎么写以及它们之间怎么互相传递数据。2. 核心细节解析与实操要点2.1 主智能体的系统设定说什么、不说什么主智能体是全系统的入口也是最重要的“调度中枢”。我把它的人设设定成“主编”系统提示词里只写清楚三件事你是谁、你负责做什么、你如何分配任务。这里有一个非常关键的实操经验主智能体的提示词不应该包含“如何写文章”“如何搜索资料”这样的执行细节因为那是子智能体的职责。主智能体只需要像一个项目经理一样理解用户需求、判断该调用哪个子智能体、传递必要的参数、最后把成品汇总给用户。我最终用的主智能体提示词大概是这样的结构你是一位资深内容主编负责管理一个内容创作团队。团队成员包括 1. 研究员负责搜集资料、整理事实依据 2. 文案撰写负责根据选题和素材撰写文章 3. 校对优化负责检查文章质量、修改润色 你的工作流程 - 接收用户的选题需求判断需要哪些成员参与 - 先让研究员搜集资料再让文案撰写根据资料写初稿最后让校对优化审校 - 如果用户只要求修改已有文章可以跳过研究员 - 始终用中文回复用户汇总团队成员的工作结果并输出之所以强调主智能体“说什么不说什么”是因为我实测过把执行细节全部灌给主智能体之后它不仅在调度时拖沓甚至会在子智能体还没干活的时候自己先脑补出一篇文章来。这个现象在 Coze 多 Agent 模式下非常常见说白了就是主智能体的“表现欲”太强我们需要通过提示词明确告诉它你是管理者不是执行者。2.2 子智能体的分工设计每位“员工”的职责边界子智能体的提示词设计原则和主智能体正好相反不需要关注全局只需要把自己的那部分做到极致。我分别说一下三个子 Agent 的配置研究员智能体。它的职责是围绕用户给的选题搜索尽量多的背景资料、案例和数据。我给它的提示词里要求输出格式固定为“选题概述 / 关键人物与事件 / 核心数据与事实 / 可引用的案例 / 素材来源清单”。为什么要求结构化输出因为后面文案撰写智能体接收到这些内容时如果是一大段口语化文字效果会大打折扣结构化的素材卡片可以让下游智能体快速提取信息。文案撰写智能体。它拿到的是“选题素材”要产出一篇完整的文章。我给它的提示词里做了几个硬性要求引入要能抓人、段落和段落之间要有过渡、必须引用研究员提供的具体数据、结尾要有明确观点。文案智能体最容易犯的毛病是“发挥过头”编造研究员没有提供的数据所以我专门加了一句“只能使用素材中出现的事实不得自行编造数据”。校对优化智能体。它的职责是站在读者角度审视全文。我在提示词里要求它重点检查三件事事实错误、逻辑漏洞、表达啰嗦。它输出的内容就是最终的成品。这一步让文章质量有了明显的托底也大幅减少了我人工审稿的时间。子智能体的模型参数设置也有讲究。比如研究员我倾向于选择推理能力强一点的模型温度参数可以适当调低让输出更稳定文案撰写则可以选择表达更丰富、风格更灵活的模型温度稍微调高一点让文字有惊喜感校对优化同样是推理优先温度调低。Coze 里这些参数都是可视化调节的不需要写代码但对产出的影响很大。2.3 知识库、插件与记忆在协作中的嵌入方式多智能体协作并不只是“提示词管理”知识库、插件、记忆这些能力同样影响着系统的上限。我在这个项目里接了三类能力第一是知识库用来解决“私有知识”的问题。比如团队的往期文章风格、产品资料、品牌规范我都传到知识库里。任何子智能体在回答时都可以引用知识库内容这样协作产出的内容不会跑偏。知识库上传时我一般建议用 markdown 或 Word 格式分段清晰检索命中率更高。第二是插件用来补足模型的能力盲区。研究员需要联网搜索我给它配置了搜索插件文案需要配图我接入了图片生成插件最终输出可能需要 markdown 转 word 的场景靠文档处理插件一键完成。在 Coze 里插件不仅主智能体可以用子智能体也可以独立配置这一点非常实用。第三是记忆能力用于解决多轮协作中的上下文丢失问题。Coze 提供了变量、数据库和对话记忆。我在主智能体上开启了“长期记忆”选项用户的历史偏好会被记录。子智能体之间的信息传递则通过工作流中的参数来流转不依赖模糊的“记住刚才聊了什么”因为多智能体环境下记忆很容易串线。3. 实操过程与核心环节实现3.1 在 Coze 中创建多智能体对话逐步配置法接下来是完整实操环节我按我实际操作的路径一步步讲。第一步登录 Coze 平台创建一个新的智能体项目名字我起的是“内容创作助手”。在智能体编排页面你会看到“单 Agent”和“多 Agent”两个模式选项这里必须选择多 Agent 模式。这个选择决定了你能否添加多个子智能体并定义它们之间的协作关系。第二步添加子智能体。在“多 Agent 模式”下界面会显示一个主智能体节点和若干可添加的子智能体节点。点击添加分别创建“研究员”“文案撰写”“校对优化”三个子 Agent。每个子 Agent 需要单独填写名称、人设与回复逻辑。注意填写的时候尽量专注单一职责不要交叉职责。第三步配置协作方式。Coze 的多 Agent 模式提供了两种基本协作方式一个是“自动路由”主智能体根据用户输入自动决定调用谁另一个是“工作流编排”通过工作流节点显式地串起调用顺序。我的项目用的是后者因为内容创作流程相对固定用工作流可以保证顺序先研究、再撰写、最后校对不会乱。第四步在子 Agent 上绑定插件和知识库资源。研究员绑定搜索插件和资料类知识库文案撰写绑定品牌风格知识库校对优化只绑定通用知识库。这样每个子 Agent 拥有的“工具权限”也不一样主智能体调度时会产生明显的“专业感”。3.2 用工作流编排“接力式”协作路径如果只靠多 Agent 的自动路由任务的执行顺序往往不可控。所以我强烈建议把核心流程用 Coze 的工作流模块固定下来。这个环节是多智能体项目能不能真正落地的一个分水岭。我的工作流节点设计如下开始节点接收用户输入的选题关键词和目标要求。调用研究员子 Agent 节点把“选题关键词”作为输入参数传入输出“素材卡片”。调用文案撰写子 Agent 节点把“选题关键词素材卡片”作为输入参数传入输出“文章初稿”。调用校对优化子 Agent 节点把“文章初稿”作为输入输出“最终成稿”。结束节点把“最终成稿”返回给主智能体。每个节点需要配置输入输出参数。比如“调用研究员子 Agent”这个节点它的输入是用户选题输出是研究员的回复内容。我在输出变量里命名为research_result然后在下一个节点里用{{research_result}}引用它。这里的概念很像编程里的函数调用但完全不用写代码界面都是拖拽和填表。有一点需要特别提醒子 Agent 节点的输出格式一定要清晰。Coze 的 LLM 输出有时会包含一些“思考过程”或“附加说明”如果这些杂质被传递到下游下游智能体可能分不清哪部分是任务描述、哪部分是素材内容。我的解决方法是在每个子 Agent 的提示词末尾加一句“只输出任务结果不要输出任何解释说明”这样可以极大减少参数传递里的脏数据。3.3 文件上传与知识库预处理让系统读懂你的资料这套内容创作系统里文件上传和知识库是一个很重要的进阶能力。比如用户直接上传一篇旧稿让智能体模仿风格改写或者上传产品手册让文案撰写在写文章时引用里面的参数。Coze 的文件上传入口在 Bot 的“知识库”模块中支持 PDF、Word、Markdown、TXT 等格式。上传文件之后一定要做预处理。我的经验是第一大文件不要直接整篇丢进去建议按章节或段落分成 500 字以内的片段Coze 有自动分段功能但我手动分段的命中率明显更高第二如果文档是扫描件 PDF平台可能无法直接提取文字需要先用 OCR 工具转成可编辑文本再上传第三给知识库命名要带业务含义因为工作流节点里选择知识库时靠名字来做匹配的。文件上传的质量直接影响最终内容的准确性。我见过不少同学图省事直接把一份 100 页的 PDF 扔进知识库结果智能体回答问题时总是“答非所问”。从原理上讲RAG 的效果取决于分段质量和检索命中率而不只是“有没有上传文档”所以预处理这步千万别跳。3.4 发布与调试技巧让系统进入真实可用状态开发完成后我们可以在 Coze 的测试面板里先跑几轮。调试多智能体系统比单 Agent 要花更多耐心我建议按这个顺序做第一步先单独测试每个子 Agent比如直接给研究员发“帮我搜一下某行业最新数据”看它的输出是否满足格式要求第二步再测试完整的协作流程从主智能体入口发一个用户的真实需求观察每一步是否被正确调度第三步检查中间变量的赋值情况如果某一步结果是空的回看提示词里有没有要求子 Agent“只输出结果”。发布时我选了“网页应用”渠道生成一个链接任何人都可以通过浏览器使用。发布前建议把主智能体的开场白设置得清晰一点直接告诉用户“我可以帮你完成从选题到成稿的完整内容创作流程请告诉我你的选题方向”。好的开场白能在很大程度上减少用户的使用困惑。4. 常见问题与排查技巧实录4.1 子智能体互相“抢活”或全部沉默怎么办这是多 Agent 项目里最常遇到的问题。我在第一版测试时把主智能体提示词里的“团队成员”描述写得太模糊结果主智能体自己直接把文章写完了研究员和文案两个子 Agent 全程没被调用。反过来还有一种情况主智能体把子 Agent 全部调用了一遍但没人真正输出有效内容看起来像集体罢工。排查思路很简单先看测试面板里的调用记录确认主智能体每一步选择了谁。如果是主智能体“抢活”检查提示词里是否明确写了“你不要直接撰写内容你负责调度团队成员”如果是子 Agent 沉默检查子 Agent 的提示词里是否给了足够的输入信息很多时候是上游传过来的参数为空或者格式不对导致子 Agent 不知道该干什么。4.2 协作过程中内容不连贯、角色状态丢失另一个高频问题是文案撰写智能体接收研究员素材之后写出来的内容和素材对不上或者前半段一个风格、后半段又换了口吻。这通常是“上下文窗口”导致的。Coze 的多 Agent 协作中每个子 Agent 只看到它拿到的输入参数和它自己的对话记录它并不知道上一个智能体的完整思考过程所以如果输入参数里没有包含足够的背景就会产生信息断层。我的解法是在传给文案撰写智能体的输入参数里不仅传“素材卡片”还把用户原始的选题诉求原样拼接进去形成“用户需求 素材卡片”的组合包。这样文案智能体既能理解用户想要什么又有足够的素材可用产出的内容连贯性明显提升。4.3 文件上传解析失败、知识库回答不准文件上传解析失败是一个很常见的“劝退”点。旧版 doc 格式经常解析出错建议先另存为 docx 或 markdownPDF 如果包含复杂表格解析后很可能乱掉需要先转成文本再上传。知识库回答不准的排查重点在于“分段”和“检索阈值”我建议把知识库的“匹配阈值”稍微调高一些宁可不回答也不要乱回答实测准确率会提升不少。4.4 运行速度慢、token 消耗高怎么取舍多智能体协作本质上是用多个模型会话完成任务速度和 token 消耗都会比单 Agent 高不少。我实测一个完整流程跑下来大概需要 60 到 90 秒消耗的 token 视文章长度而定。如果你要做成线上高频服务建议第一减少不必要的子 Agent 调用比如不是所有文风都需要调研第二为每个子 Agent 选择不同规格的模型简单的校对任务没必要用最贵的模型第三充分使用工作流里的“条件分支”节点让系统根据意图跳过不必要环节。我个人在实践中体会最深的一点是多智能体系统不怕“设计得复杂”怕的是“职责不清晰”。你给每个智能体划的边界越清楚它们协作起来越顺畅反而是那种希望一个智能体“什么都能干”的思路会让整个系统迅速走向失控。如果你也想做一个属于自己的多智能体项目我建议先从一个 3 个角色的最小闭环开始跑通之后再逐步增加子智能体。等你做到五六个角色协作的时候回头再看最初的单 Agent 应用你会明显感觉到两个时代的东西。