多 Agent 协作最近在 AI 应用圈里热度非常高。很多开发者已经发现单智能体的能力边界越来越明显——让它写一段文案还行但如果让它完成一个需要“查资料 → 做分析 → 出报告 → 校对格式”的完整任务它很容易在中途丢失上下文或者把不同环节的信息混在一起。你问它第二件事的时候它可能还沉浸在第一件事的角色设定里。Coze 给出的答案是多 Agent 协作。这个方案不是简单地在平台上创建好几个机器人而是把复杂任务拆解成多个环节由不同的 Agent 分别负责再通过合理的调度机制把它们组织成一个“AI 团队”。从 Coze 近期的版本更新来看多 Agent 的设计正在从“概念演示”走向“工程落地”其中主从模式成为主流而 subagent 在底层实现上更像是一种另类的 tool 调用。这个认知很关键它决定了你设计多 Agent 工作流时的整体思路。这篇文章会从实际项目出发聊清楚三件事多 Agent 到底解决了什么问题Coze 项目空间里的 Agent 之间是如何分工调度的以及一个完整的案例应该怎么一步步落地。无论你是刚开始接触 Coze还是已经在单 Agent 应用上踩过坑这篇文章都会给你一个可以直接参考的实践路径。1. 这篇文章真正要解决的问题先说结论多 Agent 协作解决的不是“能不能用 AI”的问题而是“AI 在复杂任务里如何保持稳定和可控”的问题。单 Agent 的局限用过的人都深有体会。一个典型的例子是你让 AI 帮你写一份市场分析报告。它需要做的事情包括查找行业数据、分析竞品、梳理用户画像、撰写结论。这些子任务性质差异很大但对同一个 Agent 来说它只能在一个上下文窗口里顺序处理。结果就是Agent 在处理后半段任务时往往已经忘了前半段的核心信息或者把不同来源的信息混为一谈。更麻烦的是提示词膨胀。为了让一个 Agent 完成所有事情你得在系统提示词里塞进大量的背景说明、角色设定、输出格式要求、边界约束。当提示词超过一定长度后模型对指令的遵循度会明显下降而且每次调用都要消耗更多的 token成本也随之上升。多 Agent 协作的核心思路是把一个大任务拆成多个子任务每个子任务交给一个专门的 Agent 处理。这样做有几个直接收益第一每个 Agent 的提示词更短、更聚焦模型遵循指令的能力更强。第二上下文隔离Agent A 处理完的信息只把关键结论传递给 Agent B不会污染 Agent B 的上下文。第三并行能力如果几个子任务之间没有依赖关系可以同时执行整体耗时显著下降。但多 Agent 并不是银弹。它引入的新问题是Agent 之间如何通信调度逻辑由谁负责子 Agent 的输出质量如何控制失败如何重试这些问题的答案恰恰是 Coze 平台正在逐步完善的部分。从材料中可以看到一个非常重要的设计思路最新的多 Agent 设计里主从模式本质上将 subagent 视作另类的 tool 进行调用。这个说法很精准。在多 Agent 协作中主 Agent 并不真正“理解”子 Agent 的内部逻辑它只是按照预设的规则决定在什么条件下调用哪个子 Agent然后把子 Agent 的输出拼接回自己的上下文。这种设计与函数调用function calling的底层逻辑是一致的。所以你在设计多 Agent 应用时与其把子 Agent 当作一个“有独立人格的 AI 同事”不如把它当作一个“功能强大的工具”只是这个工具的输出不是 JSON而是自然语言文本。这个认知转换会直接影响你的调度设计和排错方式。2. 多 Agent 的核心概念与适用场景2.1 什么是主从模式主从模式Supervisor Mode是目前 Coze 多 Agent 协作里最常见的架构。结构上非常清晰一个主 AgentSupervisor负责接收用户请求、理解任务意图、制定执行计划然后把不同的子任务分发给对应的子 AgentSubagent。子 Agent 执行完毕后把结果返回给主 Agent由主 Agent 汇总、校验、补全最终输出给用户。这种模式的优点是控制力强。你可以在主 Agent 的提示词中明确定义任务分发的规则什么类型的问题必须交给哪个子 Agent 处理什么情况下需要多个子 Agent 配合子 Agent 返回结果后需要做什么校验。由于所有决策都集中在主 Agent 这里整个系统像一个“中枢调度 专业执行”的团队行为可预期性更高。缺点也很明显主 Agent 承担了全部的调度压力如果主 Agent 的模型能力不够强或者提示词设计得不够清晰很容易出现“错误分发”“不知道把任务交给谁”“在多个子 Agent 之间反复横跳”等情况。因此主 Agent 通常需要使用更强的模型并在提示词里给出足够明确的判断条件。2.2 subagent 本质上是一种 tool这是一个很重要的认知升级。很多人在设计多 Agent 时会把子 Agent 想象成一个“独立团队里的同事”期待它能够主动理解任务、自发协作、互相讨论。但在 Coze 当前的工程实现里子 Agent 更像是一个被封装的工具。主 Agent 不关心子 Agent 的内部推理过程它只关心两个问题输入什么参数返回什么结果。子 Agent 有自己独立的提示词、知识库和工具配置但从主 Agent 的视角看它就是“一个可以完成某项特定任务的函数”。这个设计带来的好处是解耦。你可以单独维护和优化每个子 Agent 的提示词而不需要担心它影响其他部分。你可以给不同的子 Agent 配置不同的模型比如文本处理用性价比高的模型复杂推理用更强但更贵的模型。你还可以复用同一个子 Agent让它在多个主 Agent 下工作只要协议一致即可。同时它也提醒你子 Agent 的输出结果要尽量结构化、规范化。因为主 Agent 后续要“消费”这个结果如果子 Agent 返回的是冗长的、逻辑混乱的文本主 Agent 的处理成本就会上升甚至出现理解偏差。这是多 Agent 应用中非常隐蔽但非常常见的问题。2.3 适用场景判断什么情况下才需要多 Agent不是所有项目都需要多 Agent。判断标准可以看三点任务是否需要多种专业技能。如果一个任务内部包含明显不同性质的子任务比如信息收集、数据分析、文档撰写、图片生成那么多 Agent 是合适的。如果任务本身很简单比如“把这段文本翻译成英文”单 Agent 就够了。任务是否需要长链路状态管理。如果子任务之间存在依赖关系且中间状态需要保留多 Agent 可以帮你把状态切分成多个环节降低单次推理的复杂度。但如果任务链路很短多 Agent 反而增加延迟。任务是否需要多人协作模拟。如果你要构建一个“虚拟团队”产品比如 AI 编程团队、AI 营销团队那么多 Agent 是天然的产品形态。从工程成本来看多 Agent 引入了额外的延迟、token 消耗和排错复杂度。如果一个单 Agent 能够稳定完成任务不要为了炫技而引入多 Agent。更稳妥的判断是先用单 Agent 跑通流程发现确实存在上下文混乱、指令遵循不足、角色冲突等问题时再考虑拆分为多 Agent。2.4 与 Coze 工作流的关系Coze 里除了多 Agent 模式还有工作流Workflow模式。很多新手会混淆两者。简单来说工作流是“流程驱动”适合步骤固定、逻辑明确的批处理任务比如写一个自动汇总数据的流程多 Agent 是“意图驱动”适合任务边界模糊、需要动态判断的复杂场景。但两者不是对立的。在实际项目中你可以在一个多 Agent 应用里让某个子 Agent 内部再挂载一个工作流。比如信息收集子 Agent 收到任务后运行一个包含“搜索 → 筛选 → 摘要”的工作流最终把摘要结果返回给主 Agent。这种“多 Agent 工作流”的混合架构在真实项目中非常常见。3. 环境准备与前置条件3.1 Coze 平台账号与入口开始之前你需要一个 Coze 平台账号。打开 Coze 官网使用手机号或邮箱完成注册。平台界面会不时更新但核心功能区域基本稳定左侧是项目空间和资源管理顶部是运行和发布入口中间是编排画布。注意Coze 平台分为国内版和国际版两者在模型接入、插件生态和发布渠道上有差异。文章演示以通用思路为主具体界面名称以你实际使用的版本为准。3.2 项目空间的概念Coze 的项目空间Project Space是组织和管理多个 Agent 的容器。一个项目空间下可以创建多个 Agent、多个知识库、多个工作流、多个数据库表以及多个变量。这些资源在空间内是共享的。多 Agent 协作时项目空间配置的重要性容易被低估。很多人在一个空间里把所有 Agent、知识库、数据库全堆在一起结果 Agent 之间互相干扰知识库内容也能被所有 Agent 不加区分地检索。比较规范的做法是为项目建一个独立空间在空间内按模块创建 Agent并明确每个 Agent 能访问的知识库和工具。从入口上看一般是在 Coze 控制台点击“创建项目”或“项目空间”填写名称和描述后即可进入。项目空间内可以添加成员、配置共享资源、管理 API 密钥和发布信息。3.3 模型配置在编排 Agent 时需要为每个 Agent 选择大模型。Coze 平台通常会提供多个模型选项按推理能力、速度和成本有所区分。多 Agent 项目里的模型选型策略是主 Agent 选择推理能力更强的模型因为它负责意图理解和任务分发子 Agent 按任务复杂度选择简单任务用经济型模型复杂推理任务用强模型。这里的版本信息请以实际平台展示为准。平台模型列表会随合作方和版本迭代调整不建议在项目里写死某一个模型 ID而是通过配置项管理。3.4 准备素材与工具如果你要在案例中使用知识库需要提前准备文档资料。Coze 支持上传 PDF、Word、TXT、Markdown 等格式平台会自动完成文本切片和向量化。如果你要使用搜索插件需要确认你的账号有可用额度。4. 项目空间配置多 Agent 协作的基础设施4.1 创建项目空间登录 Coze 平台后在控制台找到项目空间管理页面创建一个新空间。空间命名建议直接使用项目名比如“市场分析助手”。描述里简要说明这个空间是做什么的便于团队协作时识别。创建完成后进入空间详情页面你会看到四个核心模块Agent、工作流、知识库、数据库。这是多 Agent 项目里最常用的资源类型。4.2 在空间内创建多个 Agent在项目空间内点击“创建 Agent”分别创建以下角色主控 Agent负责接收用户问题识别意图调度子 Agent。信息收集 Agent负责搜索和整理背景资料。数据分析 Agent负责处理数据表格输出统计结论。文案生成 Agent负责根据分析结果撰写结构化报告。每个 Agent 创建时都需要填写名称、设定提示词、选择模型。注意 Agent 的名称不要随意起因为主 Agent 在调度时需要通过名称来理解每个子 Agent 的职责。名称应该直接反映功能比如“data_analyst_agent”或者“信息收集员”。4.3 配置知识库与工具共享策略项目空间里的知识库是共享资源。在多 Agent 项目里你需要决定哪些知识库对哪个 Agent 可见。这里有一个常见的坑如果把所有知识库都挂在每个 Agent 上子 Agent 检索时可能命中与自己任务无关的内容导致输出偏差。推荐做法是主 Agent 不挂知识库只依赖提示词和子 Agent 返回的结果做判断。信息收集 Agent 挂行业资料库和搜索插件。数据分析 Agent 挂数据字典和统计方法说明。文案生成 Agent 挂写作规范和模板库。这种“按角色分配知识”的做法能够显著提升子 Agent 输出的相关性。4.4 配置数据库与变量如果项目需要状态存储比如记录每次任务的执行结果、中间参数传递可以在空间内创建数据库表。Coze 的数据库支持简单的表结构定义你可以在工作流中执行插入和查询操作。变量则适合存储一些运行时数据比如会话 ID、用户 ID、任务状态。变量的作用域需要根据是“仅某个 Agent 使用”还是“空间内共享”来区分避免多个 Agent 读写同一个变量造成冲突。4.5 项目空间配置示例下面是一个通用的项目空间配置参考实际字段以平台界面为准# 项目空间配置文件示例概念参考非实际导入格式 project_space: name: market_analysis_team description: 市场分析多Agent协作空间 agents: - name: supervisor role: 主控调度 model: gpt-4o # 或平台当前推荐的强模型 knowledge: null tools: [supervisor_dispatch] - name: info_collector role: 信息收集 model: gpt-4o-mini knowledge: [industry_reports, market_news] tools: [web_search, website_reader] - name: data_analyst role: 数据分析 model: gpt-4o knowledge: [data_dictionary, analysis_templates] tools: [code_interpreter] - name: report_writer role: 文案撰写 model: gpt-4o-mini knowledge: [writing_style_guide] tools: []这个示例表达了核心思想每个 Agent 需要根据自己的职责选择模型、知识库和工具而不是一刀切地全部给足。这样做既节省成本也减少干扰。5. 核心流程拆解分工调度是怎么运作的多看几个多 Agent 案例之后你会发现它们的调度逻辑大同小异核心就是三个阶段意图识别、任务分发、结果聚合。5.1 意图识别当用户向主 Agent 发送一个问题时主 Agent 要做的第一件事不是回答而是判断这个问题应该由谁来回答。比如用户问“帮我分析一下新能源汽车市场的最新动态评估头部玩家的竞争格局然后生成一份简短报告。”这是一个复合任务涉及信息收集、数据分析和文案生成三个阶段。主 Agent 需要识别出这个意图结构然后规划一个执行路径。意图识别主要靠主 Agent 的提示词设计。你需要在提示词里告诉它你有哪些子 Agent、每个子 Agent 擅长什么、在什么情况下调用。可以这样写你是主控 Agent负责调度团队完成任务。 团队中有以下成员 - 信息收集员负责搜索最新资讯、行业报告、市场新闻。当任务需要外部信息时使用。 - 数据分析员负责基于已有数据做统计分析、趋势判断。当任务涉及数据计算时使用。 - 报告写手负责将分析结果整合成结构清晰的中文报告。当任务需要成文输出时使用。 调度规则 1. 如果任务包含资料查询需求先调用信息收集员。 2. 如果任务包含数据分析需求调用数据分析员。 3. 在最终输出前调用报告写手生成结构化内容。 不要尝试自己完成所有任务必须分发给合适的成员。这段提示词虽然简单但已经把“有哪些成员、什么时候用、出什么问题找谁”讲清楚了。更复杂的项目还可以在提示词里加入条件判断比如“当用户要求图表时调用图表生成 Agent”。5.2 任务分发与 subagent 调用主 Agent 在意图识别后需要将子任务分发给对应的子 Agent。在 Coze 的编排界面里你需要在主 Agent 节点上手动添加可用的子 Agent。这个操作在界面上通常是“添加工具”或“添加子 Agent”其实就是把子 Agent 注册为主 Agent 的可调用对象。分发环节的细节很重要。主 Agent 并不直接把用户原始问题原封不动地发给子 Agent而是需要在提示词里要求主 Agent 对子 Agent 的输入进行“信息封装”。比如用户问的是“分析新能源汽车市场”主 Agent 给信息收集员的输入应该是请收集以下内容 1. 2025 年新能源汽车市场整体规模数据。 2. 头部企业的市场份额和近期动态。 3. 行业最新政策变化。 以上信息请以条理清晰的摘要形式返回。这样做有两个好处一是规范子 Agent 的输入格式提高输出质量二是切断了用户原始请求里的干扰信息比如用户附带的一个无关案例可能就会影响子 Agent 的判断。5.3 结果聚合子 Agent 执行完毕后会把结果返回给主 Agent。主 Agent 需要做的是检查结果是否完整、是否符合要求、是否需要重新请求重试如果多个子 Agent 的结果之间存在矛盾需要判断如何处理。这里的难点在于主 Agent 要处理的是自然语言而不是结构化字段。所以你会经常遇到一种情况子 Agent 的输出质量不稳定。有时候它返回一段非常完整的分析有时候只返回几句话有时候夹杂了不必要的解释。应对方式有两个方向。其一在子 Agent 的提示词里规定输出格式比如要求“只输出最终结论不使用 Markdown 标题不超过 300 字”。其二主 Agent 在收到结果后增加一个“结果校验”步骤判断内容是否满足要求不满足就退回重试。实际上这就是把主 Agent 当作一个“管理者”它不是在生成内容而是在做质量控制和资源调度。理解这一点对设计多 Agent 应用非常重要。5.4 分支、循环与并行在更复杂的场景里主 Agent 可能需要同时调用多个子 Agent或者根据上一轮结果决定下一步动作。Coze 的编排能力支持在节点之间建立分支关系和循环逻辑。举个例子用户要求分析“多个城市的餐饮市场”。主 Agent 可以先把城市列表拆开分别调用信息收集 Agent 去收集每个城市的数据然后等所有结果返回后再进行统一比较。这个过程如果串行执行会比较慢但在设计中可以考虑并行分发缩短整体时间。不过并行执行也带来了新问题子 Agent 返回结果的时间不同谁先回来谁后回来会影响到主 Agent 的处理顺序。在教程阶段建议先用串行方案跑通再逐步优化为并行调度。6. 完整案例搭建一个“市场分析报告生成团队”这一节我们用一个真实场景的简化版案列手把手演示如何在 Coze 中搭建一个多 Agent 应用。案例的目标是用户输入一个行业和产品名称系统自动生成一份包含市场背景、竞争格局、SWOT 分析和行动建议的简短报告。6.1 定义团队角色在项目空间里创建三个子 Agent 和一个主 Agent。子 Agent 1信息收集员职责收集行业背景、市场规模、主要玩家动态。工具网络搜索插件。知识库可挂载行业报告资料。输出格式要求输出结构化摘要包含“行业现状”“市场规模”“主要参与者”三个小节。子 Agent 2竞争分析员职责基于信息收集员返回的资料分析竞争格局输出头部企业的优劣势对比。工具无特殊工具主要依赖提示词推理能力。输出格式要求输出表格化对比包含“企业名称”“核心优势”“主要劣势”“潜在机会”。子 Agent 3报告撰写员职责将前两个 Agent 的结果整合为一份完整报告。工具无。输出格式要求输出包含标题、分节内容、要点化结论的正式报告。主 Agent项目主管职责接收用户需求依次调用子 Agent汇总产物。模型选较强模型。6.2 配置子 Agent 的提示词每个子 Agent 的提示词要尽量聚焦。以信息收集员为例你是资深行业信息收集员。你的任务是针对用户指定的行业和产品收集以下信息 1. 行业现状该行业当前的整体发展状态包括技术成熟度、市场阶段。 2. 市场规模最新的市场规模数据尽量给出具体数值和来源。 3. 主要参与者市场上主要的公司或品牌简述它们的市场角色。 要求 - 优先使用你掌握的工具检索最新信息。 - 不要编造数据如果无法获取精确数据请标注“数据待确认”。 - 输出必须使用以下结构 行业现状... 市场规模... 主要参与者... - 全文不超过 500 字。这段提示词里最关键是最后一条明确输出结构。因为主 Agent 需要“消费”这个结果结构化的文本能让主 Agent 更容易提取关键信息。其他子 Agent 的提示词思路一致只是任务目标不同。竞争分析员的输出要求是“对比表格形式”报告撰写员的输出要求是“完整可读、有标题层级”。6.3 在主 Agent 中挂载子 Agent进入主 Agent 的编排界面在工具列表中添加三个子 Agent。添加完成后通常在编排画布上会看到类似下面的结构用户请求 │ ▼ [主 Agent 节点] │ ├── 调用 信息收集员 │ │ │ ▼ │ [信息收集结果] │ ├── 调用 竞争分析员输入信息收集员结果 │ │ │ ▼ │ [竞争分析结果] │ ├── 调用 报告撰写员输入前两者结果 │ │ │ ▼ │ [最终报告] │ ▼ 输出给用户在编排界面上这些节点之间的关系可以通过连线来配置。如果你使用的版本支持“自动编排”主 Agent 会自动根据提示词决定调用顺序如果你是手动编排则要明确设置节点之间的输入输出。6.4 设置跳转条件与失败处理多 Agent 项目里失败处理经常被忽略。实际运行时子 Agent 调用可能出现超时、内容为空、格式错误等情况。建议在编排中增加条件分支如果信息收集员返回内容为空则重试一次。如果竞争分析员的结果明显不完整比如缺失对比项则要求主 Agent 再次整理后重新发送。如果报告撰写员输出失败降级方案是直接返回前两个环节的摘要不让用户空等。Coze 平台在节点配置中一般支持设置失败重试次数和错误消息。从工程角度哪怕是原型 demo也应该加一个简单的错误回退。6.5 完整配置示例以下是一个更接近配置内容的示例展示主 Agent 提示词里如何描述调度流程。这个示例可以直接复制到“系统提示词”框中使用也可以作为理解逻辑的参考你是“市场分析团队”的主控 Agent。你的职责是根据用户需求调度子 Agent 完成任务而不是自己直接撰写报告。 团队成员如下 1. info_collector信息收集员负责收集行业背景、市场规模、主要参与者信息。 2. competitor_analyst竞争分析员负责分析竞争格局输出头部企业优劣势对比。 3. report_writer报告撰写员负责将分析结果整合为正式报告。 执行流程 步骤一如果用户请求涉及市场背景或行业信息调用 info_collector。 步骤二将 info_collector 的输出作为输入调用 competitor_analyst 进行竞争分析。 步骤三将前两步的结果汇总调用 report_writer 撰写最终报告。 步骤四检查 report_writer 的输出确保结构完整然后输出给用户。 注意 - 如果某一步返回空内容重新调用一次。 - 如果用户只要求简短回答可以忽略 report_writer直接基于前两步结果生成概要。 - 不要向用户透露你内部有多个 Agent 的事你以团队身份统一对外输出。6.6 运行与验证完成配置后点击“预览”或“测试”按钮在对话框中输入测试内容。以一个具体产品为例请分析一下智能家居行业产品方向是智能门锁。预期执行流程主 Agent 识别这是一个“行业分析 竞争分析 报告生成”任务。调用信息收集员返回智能家居行业背景、市场数据、主要品牌。调用竞争分析员基于收集到的品牌信息输出几家头部企业的对比。调用报告撰写员整合生成一份四段式报告。主 Agent 检查输出返回给用户。如果运行过程中某个子 Agent 没有正确返回可以通过平台的日志面板查看该子 Agent 的执行记录、输入和输出。这一步非常重要因为多 Agent 应用排错的核心是看清每个节点收发了什么。7. 常见问题与排查思路多 Agent 应用的排错思路和单 Agent 有很大区别。单 Agent 出错基本就是提示词或模型问题多 Agent 出错问题可能出现在调度逻辑、节点配置、输入输出格式等多个层面。下面整理几个高频问题。问题现象可能原因排查方式解决方案主 Agent 不调用任何子 Agent自己直接回答提示词中未明确调度规则或子 Agent 名称与提示词不匹配检查主 Agent 提示词是否描述清楚“必须调用子 Agent”查看子 Agent 的 ID 和名称在提示词中增加强约束语句“不要直接回答请调用对应子 Agent”子 Agent 调用成功但输出为空子 Agent 提示词与任务不匹配或上下文输入过长导致截断打开子 Agent 的独立测试窗口单独输入任务验证精简子 Agent 提示词调整输入参数长度增加失败重试子 Agent 返回了内容但主 Agent 整合时丢失关键信息子 Agent 输出格式过于发散主 Agent 难以提取检查子 Agent 输出是否按约定结构返回检查主 Agent 收到的输入前后文在子 Agent 提示词中强制输出结构要求“只输出关键结论”多个子 Agent 之间出现“串话”项目空间内知识库和变量共享范围过大检查各 Agent 挂载的知识库和变量访问范围按 4.3 节方式重新设计资源分配实施最小权限原则系统执行超时调用链路过长或子 Agent 并行度不足查看执行日志中每个节点的耗时减少不必要的串行调用能并行的环节尽量并行运行结果不稳定同一问题多次答案差异大模型温度设置过高或提示词约束不够检查 Agent 参数设置和提示词的具体程度降低温度增加输出格式强制要求提供 Few-Shot 示例用户输入的任务过于宽泛主 Agent 无法判断分给谁主 Agent 的意图识别规则过于简单查看主 Agent 日志中意图识别结果在提示词中增加更细的指令映射表比如“提到数据→数据分析员”另外有一个很隐蔽的问题当主 Agent 使用弱模型时它可能无法正确“理解”子 Agent 返回的长篇文本。因为主模型需要从多个子 Agent 的输出中提取关键信息来生成最终答案如果模型上下文处理能力不足结果会很散乱。这时候不要急着加更多提示词更有效的办法是把主 Agent 替换成更强型号的模型。还有一种情况经常出现在新手项目里某个子 Agent 的提示词里写了“如果需要资料可以自行搜索”但它并没有绑定搜索工具于是子 Agent 就开始胡编数据。排查的时候要注意“提示词里要求的能力”和“实际配置的工具”是否匹配。8. 最佳实践与工程建议8.1 用最小可行架构启动第一次做多 Agent 项目时不要一上来就设计五六个角色。建议先做一个“主 Agent 两个子 Agent”的最小架构跑通完整链路后再逐步增加角色。这样排查问题难度会小很多。比如先只做“信息收集 报告撰写”两个环节确认数据流的连续性然后再加入竞争分析。8.2 主 Agent 提示词是重中之重主 Agent 是整个系统的“管理者”它的提示词质量决定了调度质量。一个合格的调度提示词应该包含四部分团队角色清单、每个角色的职责说明、任务分发规则、输出要求。调度规则要尽量具体最好给出条件判断示例。不要只是说“根据用户问题智能分发”而要写清楚“当用户提到 XX 话题时调用 XX”。8.3 每个子 Agent 只做一件事子 Agent 的定位应该足够窄。与其创建一个“全能助手”子 Agent不如创建“信息搜索专家”“数据整理专家”“文案润色专家”三个子 Agent。职责越单一提示词越容易设计输出质量越容易控制。这个思路对应到产品上就是“高内聚、低耦合”。8.4 输入输出规范化对子 Agent 的输出去做“格式约束”这是一个性价比极高的操作。你可以在提示词中规定输出长度上限比如“不超过 300 字”。段落结构比如“第一部分写背景第二部分写趋势”。禁止行为比如“不要输出与分析无关的内容”。8.5 知识库和工具的最小权限在多 Agent 项目里每个 Agent 能访问的知识库和工具应该遵循“按需分配”的原则。一个只负责写文案的 Agent不需要访问外部搜索工具一个只负责数据分析的 Agent也不应该看到所有行业文档。最小权限不仅让输出更聚焦还能在一定程度上避免 Agent 做出超出职责范围的行为降低安全风险。8.6 重视日志与链路追踪多 Agent 应用是黑盒嵌套黑盒如果没有日志记录出了问题根本无从排查。在 Coze 平台的测试环境中要养成查看每次执行的日志和链路详情。重点关注三个节点主 Agent 收到的初始输入、主 Agent 发给每个子 Agent 的具体指令、每个子 Agent 返回的原始输出。这三个节点对齐了问题基本就定位到了。8.7 成本控制多 Agent 的 token 消耗是单 Agent 的数倍。每个子任务都会产生独立的上下文开销主 Agent 还会把所有结果再聚合一次。在实际项目中建议给每个 Agent 设置合理的最大 token 约束并选择适合任务复杂度的模型。简单任务不要挂强模型否则成本会显得非常夸张。8.8 生产发布前的测试清单如果是正式发布建议至少完成以下测试输入不同的用户请求覆盖“单一任务”“复合任务”“边界请求”三类。构造一个会导致子 Agent 返回空结果的场景验证失败处理是否生效。验证不同子 Agent 返回结果拼接到主 Agent 后最终输出格式是否正确。设置一个超时场景确认系统提示信息对用户友好。9. 总结与后续学习方向多 Agent 协作不是一个“加几个 Agent 就自动变强”的功能而是一套工程实践。它的核心价值不在于让 AI 看起来更聪明而是让复杂任务能够通过拆分、调度和聚合被更稳定、更可控地完成。在 Coze 平台上这个实践的落地方式就是项目空间配置、Agent 角色划分、主从模式调度和输入输出规范。如果你准备在自己的项目里使用多 Agent我建议从一句判断开始这个任务真的需要多个 Agent 协作吗如果答案是肯定的再按照文章里的思路先梳理角色分工再配置项目空间然后用最小架构跑通链路最后逐步完善调度逻辑和失败处理。接下来值得深入学习的方向有三个一是 Coze 工作流与多 Agent 的组合用法很多复杂的业务逻辑需要靠工作流来固化二是子 Agent 作为“工具”的抽象设计想想如何让子 Agent 的输出更接近标准化的 API 响应三是多 Agent 应用的评测方法如何在不同模型、不同提示词下评估整体效果而不只是看单次输出是否漂亮。多 Agent 协作正处于从“能演示”到“能落地”的关键阶段现在开始动手搭建要比等生态完全成熟更容易积累经验。 Coze多Agent协作实战：从主从模式到subagent调度全解析
多 Agent 协作最近在 AI 应用圈里热度非常高。很多开发者已经发现单智能体的能力边界越来越明显——让它写一段文案还行但如果让它完成一个需要“查资料 → 做分析 → 出报告 → 校对格式”的完整任务它很容易在中途丢失上下文或者把不同环节的信息混在一起。你问它第二件事的时候它可能还沉浸在第一件事的角色设定里。Coze 给出的答案是多 Agent 协作。这个方案不是简单地在平台上创建好几个机器人而是把复杂任务拆解成多个环节由不同的 Agent 分别负责再通过合理的调度机制把它们组织成一个“AI 团队”。从 Coze 近期的版本更新来看多 Agent 的设计正在从“概念演示”走向“工程落地”其中主从模式成为主流而 subagent 在底层实现上更像是一种另类的 tool 调用。这个认知很关键它决定了你设计多 Agent 工作流时的整体思路。这篇文章会从实际项目出发聊清楚三件事多 Agent 到底解决了什么问题Coze 项目空间里的 Agent 之间是如何分工调度的以及一个完整的案例应该怎么一步步落地。无论你是刚开始接触 Coze还是已经在单 Agent 应用上踩过坑这篇文章都会给你一个可以直接参考的实践路径。1. 这篇文章真正要解决的问题先说结论多 Agent 协作解决的不是“能不能用 AI”的问题而是“AI 在复杂任务里如何保持稳定和可控”的问题。单 Agent 的局限用过的人都深有体会。一个典型的例子是你让 AI 帮你写一份市场分析报告。它需要做的事情包括查找行业数据、分析竞品、梳理用户画像、撰写结论。这些子任务性质差异很大但对同一个 Agent 来说它只能在一个上下文窗口里顺序处理。结果就是Agent 在处理后半段任务时往往已经忘了前半段的核心信息或者把不同来源的信息混为一谈。更麻烦的是提示词膨胀。为了让一个 Agent 完成所有事情你得在系统提示词里塞进大量的背景说明、角色设定、输出格式要求、边界约束。当提示词超过一定长度后模型对指令的遵循度会明显下降而且每次调用都要消耗更多的 token成本也随之上升。多 Agent 协作的核心思路是把一个大任务拆成多个子任务每个子任务交给一个专门的 Agent 处理。这样做有几个直接收益第一每个 Agent 的提示词更短、更聚焦模型遵循指令的能力更强。第二上下文隔离Agent A 处理完的信息只把关键结论传递给 Agent B不会污染 Agent B 的上下文。第三并行能力如果几个子任务之间没有依赖关系可以同时执行整体耗时显著下降。但多 Agent 并不是银弹。它引入的新问题是Agent 之间如何通信调度逻辑由谁负责子 Agent 的输出质量如何控制失败如何重试这些问题的答案恰恰是 Coze 平台正在逐步完善的部分。从材料中可以看到一个非常重要的设计思路最新的多 Agent 设计里主从模式本质上将 subagent 视作另类的 tool 进行调用。这个说法很精准。在多 Agent 协作中主 Agent 并不真正“理解”子 Agent 的内部逻辑它只是按照预设的规则决定在什么条件下调用哪个子 Agent然后把子 Agent 的输出拼接回自己的上下文。这种设计与函数调用function calling的底层逻辑是一致的。所以你在设计多 Agent 应用时与其把子 Agent 当作一个“有独立人格的 AI 同事”不如把它当作一个“功能强大的工具”只是这个工具的输出不是 JSON而是自然语言文本。这个认知转换会直接影响你的调度设计和排错方式。2. 多 Agent 的核心概念与适用场景2.1 什么是主从模式主从模式Supervisor Mode是目前 Coze 多 Agent 协作里最常见的架构。结构上非常清晰一个主 AgentSupervisor负责接收用户请求、理解任务意图、制定执行计划然后把不同的子任务分发给对应的子 AgentSubagent。子 Agent 执行完毕后把结果返回给主 Agent由主 Agent 汇总、校验、补全最终输出给用户。这种模式的优点是控制力强。你可以在主 Agent 的提示词中明确定义任务分发的规则什么类型的问题必须交给哪个子 Agent 处理什么情况下需要多个子 Agent 配合子 Agent 返回结果后需要做什么校验。由于所有决策都集中在主 Agent 这里整个系统像一个“中枢调度 专业执行”的团队行为可预期性更高。缺点也很明显主 Agent 承担了全部的调度压力如果主 Agent 的模型能力不够强或者提示词设计得不够清晰很容易出现“错误分发”“不知道把任务交给谁”“在多个子 Agent 之间反复横跳”等情况。因此主 Agent 通常需要使用更强的模型并在提示词里给出足够明确的判断条件。2.2 subagent 本质上是一种 tool这是一个很重要的认知升级。很多人在设计多 Agent 时会把子 Agent 想象成一个“独立团队里的同事”期待它能够主动理解任务、自发协作、互相讨论。但在 Coze 当前的工程实现里子 Agent 更像是一个被封装的工具。主 Agent 不关心子 Agent 的内部推理过程它只关心两个问题输入什么参数返回什么结果。子 Agent 有自己独立的提示词、知识库和工具配置但从主 Agent 的视角看它就是“一个可以完成某项特定任务的函数”。这个设计带来的好处是解耦。你可以单独维护和优化每个子 Agent 的提示词而不需要担心它影响其他部分。你可以给不同的子 Agent 配置不同的模型比如文本处理用性价比高的模型复杂推理用更强但更贵的模型。你还可以复用同一个子 Agent让它在多个主 Agent 下工作只要协议一致即可。同时它也提醒你子 Agent 的输出结果要尽量结构化、规范化。因为主 Agent 后续要“消费”这个结果如果子 Agent 返回的是冗长的、逻辑混乱的文本主 Agent 的处理成本就会上升甚至出现理解偏差。这是多 Agent 应用中非常隐蔽但非常常见的问题。2.3 适用场景判断什么情况下才需要多 Agent不是所有项目都需要多 Agent。判断标准可以看三点任务是否需要多种专业技能。如果一个任务内部包含明显不同性质的子任务比如信息收集、数据分析、文档撰写、图片生成那么多 Agent 是合适的。如果任务本身很简单比如“把这段文本翻译成英文”单 Agent 就够了。任务是否需要长链路状态管理。如果子任务之间存在依赖关系且中间状态需要保留多 Agent 可以帮你把状态切分成多个环节降低单次推理的复杂度。但如果任务链路很短多 Agent 反而增加延迟。任务是否需要多人协作模拟。如果你要构建一个“虚拟团队”产品比如 AI 编程团队、AI 营销团队那么多 Agent 是天然的产品形态。从工程成本来看多 Agent 引入了额外的延迟、token 消耗和排错复杂度。如果一个单 Agent 能够稳定完成任务不要为了炫技而引入多 Agent。更稳妥的判断是先用单 Agent 跑通流程发现确实存在上下文混乱、指令遵循不足、角色冲突等问题时再考虑拆分为多 Agent。2.4 与 Coze 工作流的关系Coze 里除了多 Agent 模式还有工作流Workflow模式。很多新手会混淆两者。简单来说工作流是“流程驱动”适合步骤固定、逻辑明确的批处理任务比如写一个自动汇总数据的流程多 Agent 是“意图驱动”适合任务边界模糊、需要动态判断的复杂场景。但两者不是对立的。在实际项目中你可以在一个多 Agent 应用里让某个子 Agent 内部再挂载一个工作流。比如信息收集子 Agent 收到任务后运行一个包含“搜索 → 筛选 → 摘要”的工作流最终把摘要结果返回给主 Agent。这种“多 Agent 工作流”的混合架构在真实项目中非常常见。3. 环境准备与前置条件3.1 Coze 平台账号与入口开始之前你需要一个 Coze 平台账号。打开 Coze 官网使用手机号或邮箱完成注册。平台界面会不时更新但核心功能区域基本稳定左侧是项目空间和资源管理顶部是运行和发布入口中间是编排画布。注意Coze 平台分为国内版和国际版两者在模型接入、插件生态和发布渠道上有差异。文章演示以通用思路为主具体界面名称以你实际使用的版本为准。3.2 项目空间的概念Coze 的项目空间Project Space是组织和管理多个 Agent 的容器。一个项目空间下可以创建多个 Agent、多个知识库、多个工作流、多个数据库表以及多个变量。这些资源在空间内是共享的。多 Agent 协作时项目空间配置的重要性容易被低估。很多人在一个空间里把所有 Agent、知识库、数据库全堆在一起结果 Agent 之间互相干扰知识库内容也能被所有 Agent 不加区分地检索。比较规范的做法是为项目建一个独立空间在空间内按模块创建 Agent并明确每个 Agent 能访问的知识库和工具。从入口上看一般是在 Coze 控制台点击“创建项目”或“项目空间”填写名称和描述后即可进入。项目空间内可以添加成员、配置共享资源、管理 API 密钥和发布信息。3.3 模型配置在编排 Agent 时需要为每个 Agent 选择大模型。Coze 平台通常会提供多个模型选项按推理能力、速度和成本有所区分。多 Agent 项目里的模型选型策略是主 Agent 选择推理能力更强的模型因为它负责意图理解和任务分发子 Agent 按任务复杂度选择简单任务用经济型模型复杂推理任务用强模型。这里的版本信息请以实际平台展示为准。平台模型列表会随合作方和版本迭代调整不建议在项目里写死某一个模型 ID而是通过配置项管理。3.4 准备素材与工具如果你要在案例中使用知识库需要提前准备文档资料。Coze 支持上传 PDF、Word、TXT、Markdown 等格式平台会自动完成文本切片和向量化。如果你要使用搜索插件需要确认你的账号有可用额度。4. 项目空间配置多 Agent 协作的基础设施4.1 创建项目空间登录 Coze 平台后在控制台找到项目空间管理页面创建一个新空间。空间命名建议直接使用项目名比如“市场分析助手”。描述里简要说明这个空间是做什么的便于团队协作时识别。创建完成后进入空间详情页面你会看到四个核心模块Agent、工作流、知识库、数据库。这是多 Agent 项目里最常用的资源类型。4.2 在空间内创建多个 Agent在项目空间内点击“创建 Agent”分别创建以下角色主控 Agent负责接收用户问题识别意图调度子 Agent。信息收集 Agent负责搜索和整理背景资料。数据分析 Agent负责处理数据表格输出统计结论。文案生成 Agent负责根据分析结果撰写结构化报告。每个 Agent 创建时都需要填写名称、设定提示词、选择模型。注意 Agent 的名称不要随意起因为主 Agent 在调度时需要通过名称来理解每个子 Agent 的职责。名称应该直接反映功能比如“data_analyst_agent”或者“信息收集员”。4.3 配置知识库与工具共享策略项目空间里的知识库是共享资源。在多 Agent 项目里你需要决定哪些知识库对哪个 Agent 可见。这里有一个常见的坑如果把所有知识库都挂在每个 Agent 上子 Agent 检索时可能命中与自己任务无关的内容导致输出偏差。推荐做法是主 Agent 不挂知识库只依赖提示词和子 Agent 返回的结果做判断。信息收集 Agent 挂行业资料库和搜索插件。数据分析 Agent 挂数据字典和统计方法说明。文案生成 Agent 挂写作规范和模板库。这种“按角色分配知识”的做法能够显著提升子 Agent 输出的相关性。4.4 配置数据库与变量如果项目需要状态存储比如记录每次任务的执行结果、中间参数传递可以在空间内创建数据库表。Coze 的数据库支持简单的表结构定义你可以在工作流中执行插入和查询操作。变量则适合存储一些运行时数据比如会话 ID、用户 ID、任务状态。变量的作用域需要根据是“仅某个 Agent 使用”还是“空间内共享”来区分避免多个 Agent 读写同一个变量造成冲突。4.5 项目空间配置示例下面是一个通用的项目空间配置参考实际字段以平台界面为准# 项目空间配置文件示例概念参考非实际导入格式 project_space: name: market_analysis_team description: 市场分析多Agent协作空间 agents: - name: supervisor role: 主控调度 model: gpt-4o # 或平台当前推荐的强模型 knowledge: null tools: [supervisor_dispatch] - name: info_collector role: 信息收集 model: gpt-4o-mini knowledge: [industry_reports, market_news] tools: [web_search, website_reader] - name: data_analyst role: 数据分析 model: gpt-4o knowledge: [data_dictionary, analysis_templates] tools: [code_interpreter] - name: report_writer role: 文案撰写 model: gpt-4o-mini knowledge: [writing_style_guide] tools: []这个示例表达了核心思想每个 Agent 需要根据自己的职责选择模型、知识库和工具而不是一刀切地全部给足。这样做既节省成本也减少干扰。5. 核心流程拆解分工调度是怎么运作的多看几个多 Agent 案例之后你会发现它们的调度逻辑大同小异核心就是三个阶段意图识别、任务分发、结果聚合。5.1 意图识别当用户向主 Agent 发送一个问题时主 Agent 要做的第一件事不是回答而是判断这个问题应该由谁来回答。比如用户问“帮我分析一下新能源汽车市场的最新动态评估头部玩家的竞争格局然后生成一份简短报告。”这是一个复合任务涉及信息收集、数据分析和文案生成三个阶段。主 Agent 需要识别出这个意图结构然后规划一个执行路径。意图识别主要靠主 Agent 的提示词设计。你需要在提示词里告诉它你有哪些子 Agent、每个子 Agent 擅长什么、在什么情况下调用。可以这样写你是主控 Agent负责调度团队完成任务。 团队中有以下成员 - 信息收集员负责搜索最新资讯、行业报告、市场新闻。当任务需要外部信息时使用。 - 数据分析员负责基于已有数据做统计分析、趋势判断。当任务涉及数据计算时使用。 - 报告写手负责将分析结果整合成结构清晰的中文报告。当任务需要成文输出时使用。 调度规则 1. 如果任务包含资料查询需求先调用信息收集员。 2. 如果任务包含数据分析需求调用数据分析员。 3. 在最终输出前调用报告写手生成结构化内容。 不要尝试自己完成所有任务必须分发给合适的成员。这段提示词虽然简单但已经把“有哪些成员、什么时候用、出什么问题找谁”讲清楚了。更复杂的项目还可以在提示词里加入条件判断比如“当用户要求图表时调用图表生成 Agent”。5.2 任务分发与 subagent 调用主 Agent 在意图识别后需要将子任务分发给对应的子 Agent。在 Coze 的编排界面里你需要在主 Agent 节点上手动添加可用的子 Agent。这个操作在界面上通常是“添加工具”或“添加子 Agent”其实就是把子 Agent 注册为主 Agent 的可调用对象。分发环节的细节很重要。主 Agent 并不直接把用户原始问题原封不动地发给子 Agent而是需要在提示词里要求主 Agent 对子 Agent 的输入进行“信息封装”。比如用户问的是“分析新能源汽车市场”主 Agent 给信息收集员的输入应该是请收集以下内容 1. 2025 年新能源汽车市场整体规模数据。 2. 头部企业的市场份额和近期动态。 3. 行业最新政策变化。 以上信息请以条理清晰的摘要形式返回。这样做有两个好处一是规范子 Agent 的输入格式提高输出质量二是切断了用户原始请求里的干扰信息比如用户附带的一个无关案例可能就会影响子 Agent 的判断。5.3 结果聚合子 Agent 执行完毕后会把结果返回给主 Agent。主 Agent 需要做的是检查结果是否完整、是否符合要求、是否需要重新请求重试如果多个子 Agent 的结果之间存在矛盾需要判断如何处理。这里的难点在于主 Agent 要处理的是自然语言而不是结构化字段。所以你会经常遇到一种情况子 Agent 的输出质量不稳定。有时候它返回一段非常完整的分析有时候只返回几句话有时候夹杂了不必要的解释。应对方式有两个方向。其一在子 Agent 的提示词里规定输出格式比如要求“只输出最终结论不使用 Markdown 标题不超过 300 字”。其二主 Agent 在收到结果后增加一个“结果校验”步骤判断内容是否满足要求不满足就退回重试。实际上这就是把主 Agent 当作一个“管理者”它不是在生成内容而是在做质量控制和资源调度。理解这一点对设计多 Agent 应用非常重要。5.4 分支、循环与并行在更复杂的场景里主 Agent 可能需要同时调用多个子 Agent或者根据上一轮结果决定下一步动作。Coze 的编排能力支持在节点之间建立分支关系和循环逻辑。举个例子用户要求分析“多个城市的餐饮市场”。主 Agent 可以先把城市列表拆开分别调用信息收集 Agent 去收集每个城市的数据然后等所有结果返回后再进行统一比较。这个过程如果串行执行会比较慢但在设计中可以考虑并行分发缩短整体时间。不过并行执行也带来了新问题子 Agent 返回结果的时间不同谁先回来谁后回来会影响到主 Agent 的处理顺序。在教程阶段建议先用串行方案跑通再逐步优化为并行调度。6. 完整案例搭建一个“市场分析报告生成团队”这一节我们用一个真实场景的简化版案列手把手演示如何在 Coze 中搭建一个多 Agent 应用。案例的目标是用户输入一个行业和产品名称系统自动生成一份包含市场背景、竞争格局、SWOT 分析和行动建议的简短报告。6.1 定义团队角色在项目空间里创建三个子 Agent 和一个主 Agent。子 Agent 1信息收集员职责收集行业背景、市场规模、主要玩家动态。工具网络搜索插件。知识库可挂载行业报告资料。输出格式要求输出结构化摘要包含“行业现状”“市场规模”“主要参与者”三个小节。子 Agent 2竞争分析员职责基于信息收集员返回的资料分析竞争格局输出头部企业的优劣势对比。工具无特殊工具主要依赖提示词推理能力。输出格式要求输出表格化对比包含“企业名称”“核心优势”“主要劣势”“潜在机会”。子 Agent 3报告撰写员职责将前两个 Agent 的结果整合为一份完整报告。工具无。输出格式要求输出包含标题、分节内容、要点化结论的正式报告。主 Agent项目主管职责接收用户需求依次调用子 Agent汇总产物。模型选较强模型。6.2 配置子 Agent 的提示词每个子 Agent 的提示词要尽量聚焦。以信息收集员为例你是资深行业信息收集员。你的任务是针对用户指定的行业和产品收集以下信息 1. 行业现状该行业当前的整体发展状态包括技术成熟度、市场阶段。 2. 市场规模最新的市场规模数据尽量给出具体数值和来源。 3. 主要参与者市场上主要的公司或品牌简述它们的市场角色。 要求 - 优先使用你掌握的工具检索最新信息。 - 不要编造数据如果无法获取精确数据请标注“数据待确认”。 - 输出必须使用以下结构 行业现状... 市场规模... 主要参与者... - 全文不超过 500 字。这段提示词里最关键是最后一条明确输出结构。因为主 Agent 需要“消费”这个结果结构化的文本能让主 Agent 更容易提取关键信息。其他子 Agent 的提示词思路一致只是任务目标不同。竞争分析员的输出要求是“对比表格形式”报告撰写员的输出要求是“完整可读、有标题层级”。6.3 在主 Agent 中挂载子 Agent进入主 Agent 的编排界面在工具列表中添加三个子 Agent。添加完成后通常在编排画布上会看到类似下面的结构用户请求 │ ▼ [主 Agent 节点] │ ├── 调用 信息收集员 │ │ │ ▼ │ [信息收集结果] │ ├── 调用 竞争分析员输入信息收集员结果 │ │ │ ▼ │ [竞争分析结果] │ ├── 调用 报告撰写员输入前两者结果 │ │ │ ▼ │ [最终报告] │ ▼ 输出给用户在编排界面上这些节点之间的关系可以通过连线来配置。如果你使用的版本支持“自动编排”主 Agent 会自动根据提示词决定调用顺序如果你是手动编排则要明确设置节点之间的输入输出。6.4 设置跳转条件与失败处理多 Agent 项目里失败处理经常被忽略。实际运行时子 Agent 调用可能出现超时、内容为空、格式错误等情况。建议在编排中增加条件分支如果信息收集员返回内容为空则重试一次。如果竞争分析员的结果明显不完整比如缺失对比项则要求主 Agent 再次整理后重新发送。如果报告撰写员输出失败降级方案是直接返回前两个环节的摘要不让用户空等。Coze 平台在节点配置中一般支持设置失败重试次数和错误消息。从工程角度哪怕是原型 demo也应该加一个简单的错误回退。6.5 完整配置示例以下是一个更接近配置内容的示例展示主 Agent 提示词里如何描述调度流程。这个示例可以直接复制到“系统提示词”框中使用也可以作为理解逻辑的参考你是“市场分析团队”的主控 Agent。你的职责是根据用户需求调度子 Agent 完成任务而不是自己直接撰写报告。 团队成员如下 1. info_collector信息收集员负责收集行业背景、市场规模、主要参与者信息。 2. competitor_analyst竞争分析员负责分析竞争格局输出头部企业优劣势对比。 3. report_writer报告撰写员负责将分析结果整合为正式报告。 执行流程 步骤一如果用户请求涉及市场背景或行业信息调用 info_collector。 步骤二将 info_collector 的输出作为输入调用 competitor_analyst 进行竞争分析。 步骤三将前两步的结果汇总调用 report_writer 撰写最终报告。 步骤四检查 report_writer 的输出确保结构完整然后输出给用户。 注意 - 如果某一步返回空内容重新调用一次。 - 如果用户只要求简短回答可以忽略 report_writer直接基于前两步结果生成概要。 - 不要向用户透露你内部有多个 Agent 的事你以团队身份统一对外输出。6.6 运行与验证完成配置后点击“预览”或“测试”按钮在对话框中输入测试内容。以一个具体产品为例请分析一下智能家居行业产品方向是智能门锁。预期执行流程主 Agent 识别这是一个“行业分析 竞争分析 报告生成”任务。调用信息收集员返回智能家居行业背景、市场数据、主要品牌。调用竞争分析员基于收集到的品牌信息输出几家头部企业的对比。调用报告撰写员整合生成一份四段式报告。主 Agent 检查输出返回给用户。如果运行过程中某个子 Agent 没有正确返回可以通过平台的日志面板查看该子 Agent 的执行记录、输入和输出。这一步非常重要因为多 Agent 应用排错的核心是看清每个节点收发了什么。7. 常见问题与排查思路多 Agent 应用的排错思路和单 Agent 有很大区别。单 Agent 出错基本就是提示词或模型问题多 Agent 出错问题可能出现在调度逻辑、节点配置、输入输出格式等多个层面。下面整理几个高频问题。问题现象可能原因排查方式解决方案主 Agent 不调用任何子 Agent自己直接回答提示词中未明确调度规则或子 Agent 名称与提示词不匹配检查主 Agent 提示词是否描述清楚“必须调用子 Agent”查看子 Agent 的 ID 和名称在提示词中增加强约束语句“不要直接回答请调用对应子 Agent”子 Agent 调用成功但输出为空子 Agent 提示词与任务不匹配或上下文输入过长导致截断打开子 Agent 的独立测试窗口单独输入任务验证精简子 Agent 提示词调整输入参数长度增加失败重试子 Agent 返回了内容但主 Agent 整合时丢失关键信息子 Agent 输出格式过于发散主 Agent 难以提取检查子 Agent 输出是否按约定结构返回检查主 Agent 收到的输入前后文在子 Agent 提示词中强制输出结构要求“只输出关键结论”多个子 Agent 之间出现“串话”项目空间内知识库和变量共享范围过大检查各 Agent 挂载的知识库和变量访问范围按 4.3 节方式重新设计资源分配实施最小权限原则系统执行超时调用链路过长或子 Agent 并行度不足查看执行日志中每个节点的耗时减少不必要的串行调用能并行的环节尽量并行运行结果不稳定同一问题多次答案差异大模型温度设置过高或提示词约束不够检查 Agent 参数设置和提示词的具体程度降低温度增加输出格式强制要求提供 Few-Shot 示例用户输入的任务过于宽泛主 Agent 无法判断分给谁主 Agent 的意图识别规则过于简单查看主 Agent 日志中意图识别结果在提示词中增加更细的指令映射表比如“提到数据→数据分析员”另外有一个很隐蔽的问题当主 Agent 使用弱模型时它可能无法正确“理解”子 Agent 返回的长篇文本。因为主模型需要从多个子 Agent 的输出中提取关键信息来生成最终答案如果模型上下文处理能力不足结果会很散乱。这时候不要急着加更多提示词更有效的办法是把主 Agent 替换成更强型号的模型。还有一种情况经常出现在新手项目里某个子 Agent 的提示词里写了“如果需要资料可以自行搜索”但它并没有绑定搜索工具于是子 Agent 就开始胡编数据。排查的时候要注意“提示词里要求的能力”和“实际配置的工具”是否匹配。8. 最佳实践与工程建议8.1 用最小可行架构启动第一次做多 Agent 项目时不要一上来就设计五六个角色。建议先做一个“主 Agent 两个子 Agent”的最小架构跑通完整链路后再逐步增加角色。这样排查问题难度会小很多。比如先只做“信息收集 报告撰写”两个环节确认数据流的连续性然后再加入竞争分析。8.2 主 Agent 提示词是重中之重主 Agent 是整个系统的“管理者”它的提示词质量决定了调度质量。一个合格的调度提示词应该包含四部分团队角色清单、每个角色的职责说明、任务分发规则、输出要求。调度规则要尽量具体最好给出条件判断示例。不要只是说“根据用户问题智能分发”而要写清楚“当用户提到 XX 话题时调用 XX”。8.3 每个子 Agent 只做一件事子 Agent 的定位应该足够窄。与其创建一个“全能助手”子 Agent不如创建“信息搜索专家”“数据整理专家”“文案润色专家”三个子 Agent。职责越单一提示词越容易设计输出质量越容易控制。这个思路对应到产品上就是“高内聚、低耦合”。8.4 输入输出规范化对子 Agent 的输出去做“格式约束”这是一个性价比极高的操作。你可以在提示词中规定输出长度上限比如“不超过 300 字”。段落结构比如“第一部分写背景第二部分写趋势”。禁止行为比如“不要输出与分析无关的内容”。8.5 知识库和工具的最小权限在多 Agent 项目里每个 Agent 能访问的知识库和工具应该遵循“按需分配”的原则。一个只负责写文案的 Agent不需要访问外部搜索工具一个只负责数据分析的 Agent也不应该看到所有行业文档。最小权限不仅让输出更聚焦还能在一定程度上避免 Agent 做出超出职责范围的行为降低安全风险。8.6 重视日志与链路追踪多 Agent 应用是黑盒嵌套黑盒如果没有日志记录出了问题根本无从排查。在 Coze 平台的测试环境中要养成查看每次执行的日志和链路详情。重点关注三个节点主 Agent 收到的初始输入、主 Agent 发给每个子 Agent 的具体指令、每个子 Agent 返回的原始输出。这三个节点对齐了问题基本就定位到了。8.7 成本控制多 Agent 的 token 消耗是单 Agent 的数倍。每个子任务都会产生独立的上下文开销主 Agent 还会把所有结果再聚合一次。在实际项目中建议给每个 Agent 设置合理的最大 token 约束并选择适合任务复杂度的模型。简单任务不要挂强模型否则成本会显得非常夸张。8.8 生产发布前的测试清单如果是正式发布建议至少完成以下测试输入不同的用户请求覆盖“单一任务”“复合任务”“边界请求”三类。构造一个会导致子 Agent 返回空结果的场景验证失败处理是否生效。验证不同子 Agent 返回结果拼接到主 Agent 后最终输出格式是否正确。设置一个超时场景确认系统提示信息对用户友好。9. 总结与后续学习方向多 Agent 协作不是一个“加几个 Agent 就自动变强”的功能而是一套工程实践。它的核心价值不在于让 AI 看起来更聪明而是让复杂任务能够通过拆分、调度和聚合被更稳定、更可控地完成。在 Coze 平台上这个实践的落地方式就是项目空间配置、Agent 角色划分、主从模式调度和输入输出规范。如果你准备在自己的项目里使用多 Agent我建议从一句判断开始这个任务真的需要多个 Agent 协作吗如果答案是肯定的再按照文章里的思路先梳理角色分工再配置项目空间然后用最小架构跑通链路最后逐步完善调度逻辑和失败处理。接下来值得深入学习的方向有三个一是 Coze 工作流与多 Agent 的组合用法很多复杂的业务逻辑需要靠工作流来固化二是子 Agent 作为“工具”的抽象设计想想如何让子 Agent 的输出更接近标准化的 API 响应三是多 Agent 应用的评测方法如何在不同模型、不同提示词下评估整体效果而不只是看单次输出是否漂亮。多 Agent 协作正处于从“能演示”到“能落地”的关键阶段现在开始动手搭建要比等生态完全成熟更容易积累经验。