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 协作里最常见的架构。结构上非常清晰：一个主 Agent（Supervisor）负责接收用户请求、理解任务意图、制定执行计划，然后把不同的子任务分发给对应的子 Agent（Subagent）。子 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 创建项目空间

创建完成后，进入空间详情页面，你会看到四个核心模块：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 协作正处于从“能演示”到“能落地”的关键阶段，现在开始动手搭建，要比等生态完全成熟更容易积累经验。