Coze 扣子多 Agent 模式正在成为 IT 人员快速落地大模型应用的主流方式之一。很多人已经用扣子搭建过单个 Bot但业务一旦复杂单 Bot 很难同时完成资料检索、内容整理、格式转换和信息校对。多 Agent 模式把一个大任务拆给多个智能体协作主 Agent 负责拆解和汇总子 Agent 负责调用插件、知识库和工作流最终给用户一个完整结果。这篇文章围绕一个可复现的实战项目——“技术文章资料整理助手”完整走一遍多 Agent 的搭建、配置、验证、排错和扩展。阅读后你可以做三件事第一在扣子上创建一个多 Agent 应用第二判断子 Agent 之间的数据传递和调用关系是否正确第三在设计工作流、本地化部署或者迁移到 Dify 时知道保留哪些核心设计。适合后端开发、运维、算法工程和提示词工程师阅读。1. 先搞清楚多 Agent 模式下扣子是怎么把任务拆给多个智能体的1.1 从“单 Bot 回答所有问题”到“多个 Agent 分工协作”单 Agent 的工作方式可以理解成一个全栈工程师从需求分析到编码、测试、部署都自己完成。遇到简单问题没问题但任务一旦包含“查资料、写文章、转格式”多个环节单个 Agent 的上下文窗口、工具选择能力和生成质量都会快速下降。它既要记住用户意图又要组织检索结果还要保证文章结构完整最后还要处理格式转换任何一个环节出错都会影响最终结果。多 Agent 的工作方式更像一个项目组。用户只跟主 Agent 对话主 Agent 相当于项目经理它不亲自写全文而是把任务拆成子任务分发给资料检索 Agent、内容整理 Agent、文档生成工作流等“执行者”。每个子 Agent 只需要做好一件事把结果返回给主 Agent由主 Agent 汇总后输出。在扣子中这个协作过程不是靠代码硬编码实现的而是由模型根据主 Agent 的人设、子 Agent 的描述、用户输入和上下文来自主判断。所以多 Agent 能不能跑得好很大程度取决于你给 Agent 的“分工说明”是否清晰。1.2 多 Agent 模式和工作流模式不是一回事扣子平台上有两种常见的编排思路工作流模式和多 Agent 模式。很多初学者会把它们混在一起实际它们解决的是不同类型的问题。工作流模式适合流程固定、节点边界清楚的场景。比如“接收 Markdown 内容 - 调用文档转换插件 - 返回 Word 文件”这种链路每一步都是确定的用工作流最合适。工作流里的节点先后顺序明确调试也直观但缺点是灵活性不够遇到“用户需求不断变化”的场景需要预先把所有分支写出来。多 Agent 模式适合任务边界相对开放、路由需要模型判断的场景。比如“根据用户输入的主题写一篇技术文章”用户可能想要教程、可能想要对比、也可能只想要提纲主 Agent 需要自己判断应该调用哪个子 Agent、调用几个子 Agent、按什么顺序调用。下面用一个表格整理两者差异。对比维度工作流模式多 Agent 模式编排方式节点之间通过连线固定编排主 Agent 根据输入动态决定调用关系执行顺序开发时已经确定运行时由模型决策具备不确定性适用场景流程稳定、规则明确、必须按顺序执行需求开放、需要理解意图、任务经常变化调试难度节点少容易定位问题调用链动态生成需要看完整日志可扩展性新增分支需要改流程新增子 Agent 后主 Agent 可能自动选用对提示词要求低主要配置节点参数高人设和描述直接影响路由质量实际项目中两者经常结合使用。工作流可以作为子 Agent 的工具被调用例如内容整理 Agent 处理完 Markdown 后可以调起“Markdown 转 Word”工作流生成文件并返回给用户。这也是多 Agent 项目中最常见的组合方式。1.3 核心对象插件、工作流、知识库、数据库、变量在扣子里搭建多 Agent还需要理解几个核心对象它们共同构成 Agent 的“手脚”和“记忆”。插件是 Agent 连接外部世界的能力封装。典型场景包括网页搜索、链接读取、文字识别、PDF 解析、发送 HTTP 请求等。子 Agent 本身不具备联网能力只有挂载插件后才能执行检索类任务。工作流是把多个节点串成固定流程的可执行单元。工作流不仅能独立运行也能作为一个“工具”挂载给 Agent。在多 Agent 项目里适合把“确定性强”的操作放进工作流例如文档格式转换、邮件发送、数据清洗。知识库用于给 Agent 提供私有数据。可以把产品文档、技术规范、历史文章等导入知识库Agent 在回答时会先检索相关知识再结合模型生成能力输出答案。这样能减少幻觉也能让 Agent 回答内部问题。数据库和变量用于处理状态。数据库适合保存结构化业务数据例如用户订单、文章记录变量适合保存会话中临时产生的数据例如检索结果、中间草稿、用户偏好。多 Agent 协作过程中子 Agent 的执行结果经常通过变量暂存再由主 Agent 传给下一个子 Agent。2. 搭建前的准备工作账号、模型、场景和检查清单2.1 从零规划一个多 Agent 项目技术文章资料整理助手本文实战项目是一个“技术文章资料整理助手”。它的价值在于用户只需要输入一个主题主 Agent 自动拆分任务先检索资料再根据资料生成一篇结构清晰的 Markdown 技术文章最后可选转换成 Word 文件。这个场景非常适合多 Agent 模式因为任务拆分清晰并且每个子任务都可以用不同工具完成。项目规划如下。主 Agent负责理解用户输入判断是否需要检索是否需要生成文章是否需要转换格式。资料检索 Agent负责调用网页搜索插件返回与主题相关的标题、链接和摘要。内容整理 Agent负责把检索结果整理成 Markdown 文章要求包含标题、章节、代码块和结论。Markdown 转 Word 工作流负责接收 Markdown 内容调用文档转换能力输出 Word 文件下载地址。这个设计意味着用户可能输入多种意图。例如“帮我了解 Coze 工作流怎么做”只需要检索和总结“写一篇完整的扣子多 Agent 教程”需要检索加生成“把这篇 Markdown 转成 Word”只需要工作流。多 Agent 模式能够让主 Agent 根据这些差异动态选择调用路径。2.2 账号、模型和 API Token 准备国内用户通常使用扣子平台coze.cn。注册并登录后控制台会提供创建 Bot、知识库、插件、工作流等入口。平台不同版本的控制台布局可能不同但核心概念一致项目空间里保存你的 Agent、工作流、知识库、插件和数据库。多 Agent 模式依赖大模型能力因此第一步是配置模型。扣子平台通常提供多个模型选择常见的有豆包系列和其他接入的模型服务。在实际项目中建议先选择一个响应稳定、上下文长度足够的模型作为主 Agent 的底座子 Agent 可以单独配置性价比更高的模型。模型选择没有绝对标准要看响应速度、中文理解能力、工具调用稳定性和费用。如果后续要通过 API 把多 Agent 应用集成到自己的系统里需要在个人设置中创建 Personal Access Token通常称为 PAT。调用时还需要 Bot ID、Space ID 等标识。不同版本的开放平台对接口字段有差异落地前以官方文档为准。2.3 搭建前的环境检查清单在开始创建前先走一遍检查清单避免做到一半才发现权限或配额不足。检查项检查内容处理建议账号权限是否能创建 Bot、工作流、知识库使用管理员账号或申请对应权限模型额度是否还有可用模型调用次数和费用预算查看控制台用量必要时充值或切换模型插件权限需要使用的搜索、文档转换插件是否已开通到插件市场确认并添加知识库配额是否需要上传私有文档配额是否足够确认上传大小和文档数量限制变量和数据库是否需要持久化用户数据按场景选择变量或数据库不要无脑建表日志能力是否可以看到 Agent 运行日志提前熟悉调试面板位置学习环境只需要能跑通即可生产环境还需要额外考虑限流、监控、用户隐私和 Token 安全。不要把 Personal Access Token 写在代码里更不要提交到 Git 仓库。3. 从零创建一个多 Agent 项目3.1 新建项目并选择多 Agent 模式登录扣子控制台后进入项目空间选择新建项目。在创建模式中选择“多 Agent”模式而不是“单 Agent”或“工作流”。如果选择错了后面无法直接使用主 Agent 调度子 Agent需要重建或切换。创建完成后控制台通常会生成一个默认的主 Agent。这个主 Agent 是整个项目的入口后面的所有子 Agent 和工作流都要挂载到它下面。建议先把项目命名为“技术文章资料整理助手”方便后续管理和调试。在搭建过程中要建立一种意识多 Agent 模式不是把一堆 Agent 堆在一起而是让主 Agent 负责“路由”子 Agent 负责“执行”。如果所有逻辑都写在主 Agent 里那还是单 Agent 的写法。3.2 定义主 Agent 的任务规划提示词主 Agent 的人设提示词需要明确写出任务边界、子 Agent 列表和调度规则。一个常见的写法如下。你是“技术文章资料整理助手”的主智能体。 你的工作流程是 1. 当用户给出技术主题或文章需求时先判断是否需要检索最新资料。 2. 如果需要检索调用“资料检索 Agent”获得结构化检索结果。 3. 如果需要生成文章调用“内容整理 Agent”让它在检索结果基础上生成 Markdown 正文。 4. 如果用户要求把 Markdown 转为 Word 文件调用“Markdown 转 Word 工作流”。 5. 最后把结果汇总成一段自然语言回复给用户。 约束 - 不要自己直接编写长篇文章。生成文章的工作交给内容整理 Agent。 - 不要自己直接调用搜索插件。搜索工作交给资料检索 Agent。 - 如果用户输入不明确先追问用户而不是盲目调用子 Agent。 - 如果子 Agent 返回结果异常明确告诉用户当前哪一步失败。这段提示词的关键在于“分工约束”。主 Agent 越清楚自己该做什么、不该做什么路由就越稳定。如果主 Agent 提示词写得太宽泛模型很可能越过子 Agent 直接回答最终结果就跟单 Agent 没有区别。3.3 创建子 Agent资料检索 Agent 和内容整理 Agent在项目空间中分别创建两个子 Agent。资料检索 Agent 的定位是“只检索不生成”。它需要挂载网页搜索插件并配置输入输出约定。人设可以这样写你是资料检索 Agent。你只负责检索与主题相关的信息不负责写文章。 输入技术主题、期望返回数量、时间范围。 输出严格返回 JSON 数组数组元素包含 title、url、summary 三个字段。 如果检索不到内容返回空数组不要编造链接。内容整理 Agent 的定位是“只生成不检索”。它不需要挂载搜索插件但需要接收资料并输出 Markdown 文章。人设可以这样写你是内容整理 Agent。你会收到一份检索结果 JSON以及用户对文章的要求。 你需要根据检索结果写一篇 Markdown 技术文章。 要求 - 文章必须基于给定资料不要补充没有来源的细节。 - 结构包含标题、引言、章节、代码示例、结论。 - 用中文写作语气专业。 - 如果资料不足以成文返回“资料不足请补充检索结果”。创建完子 Agent 后它们的名字和描述会出现在主 Agent 的工具列表中。描述是否准确会直接影响主 Agent 能否正确调用。3.4 挂载插件、知识库和 Markdown 转 Word 工作流资料检索 Agent 需要在“插件”中找到网页搜索插件并启用。搜索插件在部分环境下需要独立配置例如账号授权、地区限制、请求频率。如果插件没有正确授权即便子 Agent 被调用也会因为工具失败而中断。内容整理 Agent 可以挂载一个知识库例如历史技术文章库或产品说明文档库。知识库不是必须的但如果你想限制文章风格可以把几篇范文导入知识库并在人设中要求“风格参考知识库中的历史文章”。Markdown 转 Word 工作流需要单独创建。流程可以拆成三个节点。开始节点接收markdown_content参数。转换节点调用文档转换插件将 Markdown 内容转换为 Word 文件。结束节点返回file_url或文件 ID。工作流创建完成后把“Markdown 转 Word 工作流”挂载到主 Agent 的可调用工具列表中。这样主 Agent 就能在用户要求“转成 Word”时自动触发。3.5 连接子 Agent让主 Agent 学会调度子 Agent 和工作流都创建好后回到主 Agent 配置页检查“可调用工具”列表是否包含以下内容。可调用对象建议描述资料检索 Agent检索网络资料。输入主题、数量、时间范围输出 JSON 数组内容整理 Agent根据检索结果写 Markdown 技术文章。输入资料 JSON 和用户要求Markdown 转 Word 工作流把 Markdown 内容转为 Word 文件返回文件下载地址这里的“描述”是主 Agent 做路由决策的关键信息。描述不要写成“负责文章处理”这种模糊话术而要写清楚输入是什么、输出是什么、什么时候用。推荐格式是“动作 输入条件 输出结果”例如“当用户需要搜索资料时使用输入是主题输出是链接列表”。连接完成后可以先在调试面板发一条测试消息“写一篇关于扣子工作流的入门文章”。观察主 Agent 是否先调用资料检索 Agent再调用内容整理 Agent。如果两步都出现了说明基础链路已经打通。4. 关键参数、数据结构和调试方法4.1 输入输出协议子 Agent 之间靠结构化数据传值多 Agent 最常见的失败原因不是模型能力不够而是子 Agent 之间没有约定好数据格式。比如资料检索 Agent 输出的是“标题xxx链接xxx”这种自然语言内容整理 Agent 不一定能稳定解析。解决办法是提前定义结构化协议并在每个 Agent 的人设中重复强调。下面是一个 JSON 示例。{ status: success, count: 3, results: [ { title: Coze 工作流入门指南, url: https://example.com/coze-workflow-basics, summary: 介绍了 Coze 工作流的基本节点和运行方式。 }, { title: 多 Agent 模式的设计思路, url: https://example.com/multi-agent-design, summary: 讨论了多 Agent 路由、工具调用和上下文传递。 } ] }主 Agent 在把任务交给内容整理 Agent 时可以这样拼接上下文请根据以下资料生成 Markdown 技术文章。 资料 JSON {...} 用户要求 {...}结构化数据的好处是后续环节能稳定取到字段也方便调试时判断是哪一步丢了数据。这里要注意模型输出 JSON 时经常会在外面包一层 Markdown 代码块建议在子 Agent 人设中明确要求“只输出 JSON不要输出解释文字”。4.2 模型参数和记忆变量的调优多 Agent 模式下模型参数会影响路由稳定性和输出质量。以下参数需要重点关注。参数默认常见值调大的影响调小的影响建议场景温度0.3 - 0.7输出更多样但更容易跑偏输出更稳定但可能过于死板工具调用和路由选择建议偏低最大 Token1024 - 4096能输出更长文章但耗时增加输出容易被截断内容整理 Agent 需要调大知识库分块大小按平台默认每块信息更完整但检索可能不精准检索更精准但上下文缺失技术文档建议中等分块搜索数量3 - 10信息更全面但噪音更多内容更聚焦但可能漏掉关键信息资料检索 Agent 建议 5 条左右记忆和变量方面建议把“检索结果”保存到变量中。如果用户在多轮对话中要求“再改一下文章”主 Agent 可以直接从变量里读取之前的检索结果不用重新搜索。这样既节省 Token也避免结果不一致。4.3 使用调试面板看调用链扣子通常提供测试会话的调试面板。调试面板展示的不只是最终回复还包括主 Agent 的思考过程、调用了哪些工具、每个工具的参数和返回值。调试时要按这个顺序看。看主 Agent 是否理解了用户意图。如果主 Agent 判断错误问题在提示词而不是子 Agent。看主 Agent 选择了哪个子 Agent。如果选择错误检查子 Agent 的描述是否清晰。看子 Agent 返回了什么。如果返回空数组或格式异常问题在子 Agent 的工具配置或人设。看主 Agent 如何二次加工。如果子 Agent 结果正确但最终输出错误问题在主 Agent 的汇总提示词。调试面板里出现日志不代表链路就正确。要确认每个环节的输入输出是否符合预期尤其要关注子 Agent 是否真的执行了你认为它应该执行的操作。5. 运行验证怎么判断多 Agent 是不是真的跑通了5.1 设计一套有效的测试用例多 Agent 项目不能只测“能不能回复”要覆盖正常路径、分支路径和异常路径。推荐至少准备以下测试用例。用户输入预期路径预期结果写一篇关于 Coze 工作流的入门文章主 Agent 调资料检索 Agent再调内容整理 Agent输出一篇结构完整的 Markdown 文章帮我搜索 3 篇多 Agent 的文章只调资料检索 Agent返回 3 条带链接的结果把下面这段 Markdown 转成 Word调 Markdown 转 Word 工作流返回文档下载文件你是什么模型主 Agent 直接回答不调用任何子 Agent写一篇关于不存在领域的文章资料检索 Agent 返回空结果主 Agent 提示用户资料不足不硬写这些用例能帮助确认路由、工具调用、数据传递和兜底逻辑是否正常。5.2 预期运行路径和输出示例一次正常的文章生成请求预期日志会类似下面的路径。用户消息: 写一篇关于扣子工作流的入门文章 主 Agent: 判断需要检索资料调用资料检索 Agent 资料检索 Agent: 返回 5 条检索结果 主 Agent: 将检索结果转给内容整理 Agent 内容整理 Agent: 生成 Markdown 草稿 主 Agent: 汇总并输出最终文章最终输出示例# 扣子工作流入门 ## 1. 什么是工作流 工作流是扣子平台上用来组合多个步骤的编排方式。 ## 2. 核心节点 - 开始节点 - 插件节点 - 结束节点 ## 3. 一个最小示例 ...代码块...如果日志中省略了某个子 Agent或者输出内容没有对应检索结果就说明这段路径没有真正跑通。5.3 用四个指标判断协作质量验证多 Agent 项目时不要只看最终回答好不好还要关注以下四个指标。调用覆盖率针对一个复杂任务应该被调用的子 Agent 是否都被调用了。数据一致性子 Agent 返回的数据是否被后续环节完整使用有没有丢失字段。异常兜底率插件失败、搜索为空时主 Agent 是否能给出有效处理。响应效率整个协作链路的耗时是否在可接受范围内。如果每轮都超过 30 秒说明编排设计可能过于复杂。建议每次调整提示词后用同一套测试用例重新跑一遍记录前后差异。多 Agent 模型路由本身有一定随机性不要凭一两次成功判断项目已经稳定。6. 多 Agent 常见问题与排查链路6.1 主 Agent 不调用子 Agent自己把所有事情干了现象是用户发了一个复杂任务主 Agent 直接给出回答调试面板里没有任何子 Agent 调用记录。常见原因有三个主 Agent 人设没有明确“必须调用子 Agent”子 Agent 的描述太模糊主 Agent 不知道何时调用温度设置过高导致模型没有遵循调度规则。检查顺序是先看子 Agent 描述是否包含“什么时候用、输入是什么、输出是什么”再看主 Agent 提示词里是否明确禁止自己做执行工作最后把温度调低到 0.3 左右重试。推荐把子 Agent 描述写成“当用户需要搜索时使用不要自己搜索把主题传给它”。6.2 子 Agent 结果传不过去内容整理 Agent 拿到空数据现象是资料检索 Agent 明明返回了结果但内容整理 Agent 生成的还是幻觉内容。问题通常出在主 Agent 拼接上下文的环节它可能只把用户原话传给了内容整理 Agent没有把检索 JSON 拼进去。建议在主 Agent 提示词中增加一条“调用内容整理 Agent 时必须将资料检索 Agent 返回的 JSON 完整放在输入消息中并用‘资料 JSON’开头。”同时可以把检索结果写入变量在调用子 Agent 时引用变量减少拼接遗漏。6.3 搜索内容过时或模型幻觉现象是文章内容看起来合理但数据和链接是编造的。原因是资料检索 Agent 没有约束返回来源或内容整理 Agent 被允许自由发挥。解决方案是把边界写死。资料检索 Agent 必须返回真实链接没有结果时返回空数组内容整理 Agent 只能基于给定资料组织信息不能补充没有来源的细节。如果平台支持设置“回答必须包含引用来源”打开这个开关会明显改善。6.4 Agent 运行中断或工具限流现象是运行到一半日志出现类似“Agent terminated due to error”的提示或者插件返回 429 限流。这类问题通常不是提示词能解决的。首先检查是哪个节点中断。如果是插件节点报错重新授权或更换备用插件如果是模型服务超时缩短输入内容或换更快的模型如果是子 Agent 循环调用给子 Agent 增加“步骤上限”或“回答不了就返回错误”的约束。对于限流问题可以在工作流中增加重试和错误分支。比如搜索插件失败时降级到备用搜索源文档转换失败时返回“格式转换服务暂时不可用”的提示而不是让整个对话中断。问题现象常见原因检查方式处理建议主 Agent 不调用子 Agent描述不清或人设未约束检查子 Agent 描述和主 Agent 提示词补全触发条件和输出协议子 Agent 拿不到数据上下文拼接丢失查看日志中实际传给子 Agent 的内容使用变量并显式拼接 JSON内容出现幻觉约束太松检查内容 Agent 人设只允许基于给定资料生成运行中断工具异常或超时定位日志中断节点增加重试、降级和错误分支7. 从扣子到本地化部署Dify、Ollama 和扩展路线7.1 扣子、Dify、Workbuddy、OpenClaw 是什么关系多 Agent 概念火了之后市面上的工具名词越来越多。扣子Coze是云端托管的 Agent 构建平台适合快速验证和业务集成Dify 是开源的应用开发平台支持私有部署适合企业对数据安全要求较高的场景Workbuddy、OpenClaw 这类工具的定位和形态各不相同有的是专注于某个环节的框架有的偏向执行调度。它们不是同一类东西选择时更关键的是看团队到底需要“快速上线”还是“私有可控”。如果项目刚起步想验证业务效果用扣子最直接。如果要把 Agent 能力封装进内部系统并且数据必须留在内网建议考虑 Dify 加本地模型。迁移时不需要改动核心的 Agent 设计只需要把扣子中的子 Agent、工作流、知识库映射到新平台。7.2 把 Agent 搬回本地Ollama 加 Dify 的最小路线本地部署的核心诉求是数据不外传、成本可控、可自定义模型。一个最小路线是用 Ollama 跑开源模型再用 Dify 搭建 Agent 和工作流。安装 Ollama 后拉取一个适合中文任务的开源模型例如 Qwen 系列ollama pull qwen2.5:7b ollama run qwen2.5:7b在 Dify 的模型供应商中配置 Ollama可以参考下面这个示意配置model_provider: ollama api_base_url: http://localhost:11434/v1 model: qwen2.5:7b api_key: ollama配置完成后在 Dify 中创建一个 Agent 应用把工作流、知识库和工具挂载进去。这里的 Agent 设计方式与扣子多 Agent 类似主 Agent 负责人设和调度工作流负责稳定流程知识库负责私有数据。需要特别注意的是本地模型参数量越大推理延迟和显存占用越高不一定适合生产环境高频访问。初次实验建议先用 7B 到 14B 参数量的模型跑通后再评估是否升级。7.3 本地化部署需要补的运维能力本地化部署不是把模型下载下来就结束了。生产环境还需要考虑以下问题。运维项说明API Token 管理本地服务也要设置访问密钥不能裸奔日志脱敏用户输入和模型输出可能包含敏感信息日志要脱敏监控告警模型推理时间、请求量、错误率需要监控模型版本管理模型升级后要能做 A/B 对比数据备份知识库和业务数据需要定期备份权限控制不同用户、不同部门不能互相访问数据本地化部署并不自动等于安全。普通开发环境只需要能跑通生产环境则要补权限、日志、监控和回滚方案。8. 几个可以复用的清单和下一步练习建议8.1 多 Agent 设计复查清单设计阶段最容易犯的错是把多 Agent 当成装饰。使用下面这份清单对项目做一次自查。[ ] 任务是否真的需要拆分成多个 Agent还是单个 Agent 加工作流就能解决[ ] 每个子 Agent 是否有明确输入输出协议[ ] 子 Agent 之间的数据通过什么字段传递字段命名是否一致[ ] 主 Agent 是否知道自己不该做什么[ ] 子 Agent 描述是否足够清晰能让主 Agent 在正确场景下调用[ ] 是否有异常兜底逻辑例如检索为空、插件报错、格式转换失败[ ] 是否保留了关键变量避免多轮对话时重复搜索[ ] 是否存在循环调用风险子 Agent 之间是否可能互相调用如果某个子 Agent 只是把用户输入原样传给另一个子 Agent没有增加任何价值那就应该把它去掉。8.2 发布前检查清单项目上线前除了功能正常还要走一遍发布检查。[ ] 测试用例覆盖正常路径、分支路径和异常路径[ ] 模型参数已经针对多 Agent 场景调整过[ ] 所有插件都已经正确授权并在测试环境跑通过[ ] 主 Agent 的日志和调试信息能被定位到具体环节[ ] 用户敏感信息不会被写入变量或日志[ ] 通过 API 暴露给外部系统时Token 使用环境变量注入[ ] 限流和错误提示对用户是友好的不暴露内部错误详情8.3 下一步练习建议多 Agent 是一项需要反复实践的技能。建议按以下顺序继续深入。第一复刻一个简单的多 Agent 客户支持机器人。一个 Agent 负责查询订单一个 Agent 负责售后政策主 Agent 根据用户问题路由。第二把一个现有工作流接入多 Agent观察两者结合的调用路径。第三用 Ollama 加 Dify 跑通同一个最小用例对比云端平台和本地部署的开发效率与成本。第四主动制造错误例如禁用搜索插件、清空知识库观察主 Agent 的兜底行为是否合理。多 Agent 的核心不是模型数量多而是任务边界清楚、数据格式稳定、异常路径可见。把扣子上的这套设计想明白后续不管是迁移到 Dify、接入本地模型还是继续扩展子 Agent都能复用同一套思路。 Coze扣子多Agent模式实战：搭建技术文章资料整理助手
Coze 扣子多 Agent 模式正在成为 IT 人员快速落地大模型应用的主流方式之一。很多人已经用扣子搭建过单个 Bot但业务一旦复杂单 Bot 很难同时完成资料检索、内容整理、格式转换和信息校对。多 Agent 模式把一个大任务拆给多个智能体协作主 Agent 负责拆解和汇总子 Agent 负责调用插件、知识库和工作流最终给用户一个完整结果。这篇文章围绕一个可复现的实战项目——“技术文章资料整理助手”完整走一遍多 Agent 的搭建、配置、验证、排错和扩展。阅读后你可以做三件事第一在扣子上创建一个多 Agent 应用第二判断子 Agent 之间的数据传递和调用关系是否正确第三在设计工作流、本地化部署或者迁移到 Dify 时知道保留哪些核心设计。适合后端开发、运维、算法工程和提示词工程师阅读。1. 先搞清楚多 Agent 模式下扣子是怎么把任务拆给多个智能体的1.1 从“单 Bot 回答所有问题”到“多个 Agent 分工协作”单 Agent 的工作方式可以理解成一个全栈工程师从需求分析到编码、测试、部署都自己完成。遇到简单问题没问题但任务一旦包含“查资料、写文章、转格式”多个环节单个 Agent 的上下文窗口、工具选择能力和生成质量都会快速下降。它既要记住用户意图又要组织检索结果还要保证文章结构完整最后还要处理格式转换任何一个环节出错都会影响最终结果。多 Agent 的工作方式更像一个项目组。用户只跟主 Agent 对话主 Agent 相当于项目经理它不亲自写全文而是把任务拆成子任务分发给资料检索 Agent、内容整理 Agent、文档生成工作流等“执行者”。每个子 Agent 只需要做好一件事把结果返回给主 Agent由主 Agent 汇总后输出。在扣子中这个协作过程不是靠代码硬编码实现的而是由模型根据主 Agent 的人设、子 Agent 的描述、用户输入和上下文来自主判断。所以多 Agent 能不能跑得好很大程度取决于你给 Agent 的“分工说明”是否清晰。1.2 多 Agent 模式和工作流模式不是一回事扣子平台上有两种常见的编排思路工作流模式和多 Agent 模式。很多初学者会把它们混在一起实际它们解决的是不同类型的问题。工作流模式适合流程固定、节点边界清楚的场景。比如“接收 Markdown 内容 - 调用文档转换插件 - 返回 Word 文件”这种链路每一步都是确定的用工作流最合适。工作流里的节点先后顺序明确调试也直观但缺点是灵活性不够遇到“用户需求不断变化”的场景需要预先把所有分支写出来。多 Agent 模式适合任务边界相对开放、路由需要模型判断的场景。比如“根据用户输入的主题写一篇技术文章”用户可能想要教程、可能想要对比、也可能只想要提纲主 Agent 需要自己判断应该调用哪个子 Agent、调用几个子 Agent、按什么顺序调用。下面用一个表格整理两者差异。对比维度工作流模式多 Agent 模式编排方式节点之间通过连线固定编排主 Agent 根据输入动态决定调用关系执行顺序开发时已经确定运行时由模型决策具备不确定性适用场景流程稳定、规则明确、必须按顺序执行需求开放、需要理解意图、任务经常变化调试难度节点少容易定位问题调用链动态生成需要看完整日志可扩展性新增分支需要改流程新增子 Agent 后主 Agent 可能自动选用对提示词要求低主要配置节点参数高人设和描述直接影响路由质量实际项目中两者经常结合使用。工作流可以作为子 Agent 的工具被调用例如内容整理 Agent 处理完 Markdown 后可以调起“Markdown 转 Word”工作流生成文件并返回给用户。这也是多 Agent 项目中最常见的组合方式。1.3 核心对象插件、工作流、知识库、数据库、变量在扣子里搭建多 Agent还需要理解几个核心对象它们共同构成 Agent 的“手脚”和“记忆”。插件是 Agent 连接外部世界的能力封装。典型场景包括网页搜索、链接读取、文字识别、PDF 解析、发送 HTTP 请求等。子 Agent 本身不具备联网能力只有挂载插件后才能执行检索类任务。工作流是把多个节点串成固定流程的可执行单元。工作流不仅能独立运行也能作为一个“工具”挂载给 Agent。在多 Agent 项目里适合把“确定性强”的操作放进工作流例如文档格式转换、邮件发送、数据清洗。知识库用于给 Agent 提供私有数据。可以把产品文档、技术规范、历史文章等导入知识库Agent 在回答时会先检索相关知识再结合模型生成能力输出答案。这样能减少幻觉也能让 Agent 回答内部问题。数据库和变量用于处理状态。数据库适合保存结构化业务数据例如用户订单、文章记录变量适合保存会话中临时产生的数据例如检索结果、中间草稿、用户偏好。多 Agent 协作过程中子 Agent 的执行结果经常通过变量暂存再由主 Agent 传给下一个子 Agent。2. 搭建前的准备工作账号、模型、场景和检查清单2.1 从零规划一个多 Agent 项目技术文章资料整理助手本文实战项目是一个“技术文章资料整理助手”。它的价值在于用户只需要输入一个主题主 Agent 自动拆分任务先检索资料再根据资料生成一篇结构清晰的 Markdown 技术文章最后可选转换成 Word 文件。这个场景非常适合多 Agent 模式因为任务拆分清晰并且每个子任务都可以用不同工具完成。项目规划如下。主 Agent负责理解用户输入判断是否需要检索是否需要生成文章是否需要转换格式。资料检索 Agent负责调用网页搜索插件返回与主题相关的标题、链接和摘要。内容整理 Agent负责把检索结果整理成 Markdown 文章要求包含标题、章节、代码块和结论。Markdown 转 Word 工作流负责接收 Markdown 内容调用文档转换能力输出 Word 文件下载地址。这个设计意味着用户可能输入多种意图。例如“帮我了解 Coze 工作流怎么做”只需要检索和总结“写一篇完整的扣子多 Agent 教程”需要检索加生成“把这篇 Markdown 转成 Word”只需要工作流。多 Agent 模式能够让主 Agent 根据这些差异动态选择调用路径。2.2 账号、模型和 API Token 准备国内用户通常使用扣子平台coze.cn。注册并登录后控制台会提供创建 Bot、知识库、插件、工作流等入口。平台不同版本的控制台布局可能不同但核心概念一致项目空间里保存你的 Agent、工作流、知识库、插件和数据库。多 Agent 模式依赖大模型能力因此第一步是配置模型。扣子平台通常提供多个模型选择常见的有豆包系列和其他接入的模型服务。在实际项目中建议先选择一个响应稳定、上下文长度足够的模型作为主 Agent 的底座子 Agent 可以单独配置性价比更高的模型。模型选择没有绝对标准要看响应速度、中文理解能力、工具调用稳定性和费用。如果后续要通过 API 把多 Agent 应用集成到自己的系统里需要在个人设置中创建 Personal Access Token通常称为 PAT。调用时还需要 Bot ID、Space ID 等标识。不同版本的开放平台对接口字段有差异落地前以官方文档为准。2.3 搭建前的环境检查清单在开始创建前先走一遍检查清单避免做到一半才发现权限或配额不足。检查项检查内容处理建议账号权限是否能创建 Bot、工作流、知识库使用管理员账号或申请对应权限模型额度是否还有可用模型调用次数和费用预算查看控制台用量必要时充值或切换模型插件权限需要使用的搜索、文档转换插件是否已开通到插件市场确认并添加知识库配额是否需要上传私有文档配额是否足够确认上传大小和文档数量限制变量和数据库是否需要持久化用户数据按场景选择变量或数据库不要无脑建表日志能力是否可以看到 Agent 运行日志提前熟悉调试面板位置学习环境只需要能跑通即可生产环境还需要额外考虑限流、监控、用户隐私和 Token 安全。不要把 Personal Access Token 写在代码里更不要提交到 Git 仓库。3. 从零创建一个多 Agent 项目3.1 新建项目并选择多 Agent 模式登录扣子控制台后进入项目空间选择新建项目。在创建模式中选择“多 Agent”模式而不是“单 Agent”或“工作流”。如果选择错了后面无法直接使用主 Agent 调度子 Agent需要重建或切换。创建完成后控制台通常会生成一个默认的主 Agent。这个主 Agent 是整个项目的入口后面的所有子 Agent 和工作流都要挂载到它下面。建议先把项目命名为“技术文章资料整理助手”方便后续管理和调试。在搭建过程中要建立一种意识多 Agent 模式不是把一堆 Agent 堆在一起而是让主 Agent 负责“路由”子 Agent 负责“执行”。如果所有逻辑都写在主 Agent 里那还是单 Agent 的写法。3.2 定义主 Agent 的任务规划提示词主 Agent 的人设提示词需要明确写出任务边界、子 Agent 列表和调度规则。一个常见的写法如下。你是“技术文章资料整理助手”的主智能体。 你的工作流程是 1. 当用户给出技术主题或文章需求时先判断是否需要检索最新资料。 2. 如果需要检索调用“资料检索 Agent”获得结构化检索结果。 3. 如果需要生成文章调用“内容整理 Agent”让它在检索结果基础上生成 Markdown 正文。 4. 如果用户要求把 Markdown 转为 Word 文件调用“Markdown 转 Word 工作流”。 5. 最后把结果汇总成一段自然语言回复给用户。 约束 - 不要自己直接编写长篇文章。生成文章的工作交给内容整理 Agent。 - 不要自己直接调用搜索插件。搜索工作交给资料检索 Agent。 - 如果用户输入不明确先追问用户而不是盲目调用子 Agent。 - 如果子 Agent 返回结果异常明确告诉用户当前哪一步失败。这段提示词的关键在于“分工约束”。主 Agent 越清楚自己该做什么、不该做什么路由就越稳定。如果主 Agent 提示词写得太宽泛模型很可能越过子 Agent 直接回答最终结果就跟单 Agent 没有区别。3.3 创建子 Agent资料检索 Agent 和内容整理 Agent在项目空间中分别创建两个子 Agent。资料检索 Agent 的定位是“只检索不生成”。它需要挂载网页搜索插件并配置输入输出约定。人设可以这样写你是资料检索 Agent。你只负责检索与主题相关的信息不负责写文章。 输入技术主题、期望返回数量、时间范围。 输出严格返回 JSON 数组数组元素包含 title、url、summary 三个字段。 如果检索不到内容返回空数组不要编造链接。内容整理 Agent 的定位是“只生成不检索”。它不需要挂载搜索插件但需要接收资料并输出 Markdown 文章。人设可以这样写你是内容整理 Agent。你会收到一份检索结果 JSON以及用户对文章的要求。 你需要根据检索结果写一篇 Markdown 技术文章。 要求 - 文章必须基于给定资料不要补充没有来源的细节。 - 结构包含标题、引言、章节、代码示例、结论。 - 用中文写作语气专业。 - 如果资料不足以成文返回“资料不足请补充检索结果”。创建完子 Agent 后它们的名字和描述会出现在主 Agent 的工具列表中。描述是否准确会直接影响主 Agent 能否正确调用。3.4 挂载插件、知识库和 Markdown 转 Word 工作流资料检索 Agent 需要在“插件”中找到网页搜索插件并启用。搜索插件在部分环境下需要独立配置例如账号授权、地区限制、请求频率。如果插件没有正确授权即便子 Agent 被调用也会因为工具失败而中断。内容整理 Agent 可以挂载一个知识库例如历史技术文章库或产品说明文档库。知识库不是必须的但如果你想限制文章风格可以把几篇范文导入知识库并在人设中要求“风格参考知识库中的历史文章”。Markdown 转 Word 工作流需要单独创建。流程可以拆成三个节点。开始节点接收markdown_content参数。转换节点调用文档转换插件将 Markdown 内容转换为 Word 文件。结束节点返回file_url或文件 ID。工作流创建完成后把“Markdown 转 Word 工作流”挂载到主 Agent 的可调用工具列表中。这样主 Agent 就能在用户要求“转成 Word”时自动触发。3.5 连接子 Agent让主 Agent 学会调度子 Agent 和工作流都创建好后回到主 Agent 配置页检查“可调用工具”列表是否包含以下内容。可调用对象建议描述资料检索 Agent检索网络资料。输入主题、数量、时间范围输出 JSON 数组内容整理 Agent根据检索结果写 Markdown 技术文章。输入资料 JSON 和用户要求Markdown 转 Word 工作流把 Markdown 内容转为 Word 文件返回文件下载地址这里的“描述”是主 Agent 做路由决策的关键信息。描述不要写成“负责文章处理”这种模糊话术而要写清楚输入是什么、输出是什么、什么时候用。推荐格式是“动作 输入条件 输出结果”例如“当用户需要搜索资料时使用输入是主题输出是链接列表”。连接完成后可以先在调试面板发一条测试消息“写一篇关于扣子工作流的入门文章”。观察主 Agent 是否先调用资料检索 Agent再调用内容整理 Agent。如果两步都出现了说明基础链路已经打通。4. 关键参数、数据结构和调试方法4.1 输入输出协议子 Agent 之间靠结构化数据传值多 Agent 最常见的失败原因不是模型能力不够而是子 Agent 之间没有约定好数据格式。比如资料检索 Agent 输出的是“标题xxx链接xxx”这种自然语言内容整理 Agent 不一定能稳定解析。解决办法是提前定义结构化协议并在每个 Agent 的人设中重复强调。下面是一个 JSON 示例。{ status: success, count: 3, results: [ { title: Coze 工作流入门指南, url: https://example.com/coze-workflow-basics, summary: 介绍了 Coze 工作流的基本节点和运行方式。 }, { title: 多 Agent 模式的设计思路, url: https://example.com/multi-agent-design, summary: 讨论了多 Agent 路由、工具调用和上下文传递。 } ] }主 Agent 在把任务交给内容整理 Agent 时可以这样拼接上下文请根据以下资料生成 Markdown 技术文章。 资料 JSON {...} 用户要求 {...}结构化数据的好处是后续环节能稳定取到字段也方便调试时判断是哪一步丢了数据。这里要注意模型输出 JSON 时经常会在外面包一层 Markdown 代码块建议在子 Agent 人设中明确要求“只输出 JSON不要输出解释文字”。4.2 模型参数和记忆变量的调优多 Agent 模式下模型参数会影响路由稳定性和输出质量。以下参数需要重点关注。参数默认常见值调大的影响调小的影响建议场景温度0.3 - 0.7输出更多样但更容易跑偏输出更稳定但可能过于死板工具调用和路由选择建议偏低最大 Token1024 - 4096能输出更长文章但耗时增加输出容易被截断内容整理 Agent 需要调大知识库分块大小按平台默认每块信息更完整但检索可能不精准检索更精准但上下文缺失技术文档建议中等分块搜索数量3 - 10信息更全面但噪音更多内容更聚焦但可能漏掉关键信息资料检索 Agent 建议 5 条左右记忆和变量方面建议把“检索结果”保存到变量中。如果用户在多轮对话中要求“再改一下文章”主 Agent 可以直接从变量里读取之前的检索结果不用重新搜索。这样既节省 Token也避免结果不一致。4.3 使用调试面板看调用链扣子通常提供测试会话的调试面板。调试面板展示的不只是最终回复还包括主 Agent 的思考过程、调用了哪些工具、每个工具的参数和返回值。调试时要按这个顺序看。看主 Agent 是否理解了用户意图。如果主 Agent 判断错误问题在提示词而不是子 Agent。看主 Agent 选择了哪个子 Agent。如果选择错误检查子 Agent 的描述是否清晰。看子 Agent 返回了什么。如果返回空数组或格式异常问题在子 Agent 的工具配置或人设。看主 Agent 如何二次加工。如果子 Agent 结果正确但最终输出错误问题在主 Agent 的汇总提示词。调试面板里出现日志不代表链路就正确。要确认每个环节的输入输出是否符合预期尤其要关注子 Agent 是否真的执行了你认为它应该执行的操作。5. 运行验证怎么判断多 Agent 是不是真的跑通了5.1 设计一套有效的测试用例多 Agent 项目不能只测“能不能回复”要覆盖正常路径、分支路径和异常路径。推荐至少准备以下测试用例。用户输入预期路径预期结果写一篇关于 Coze 工作流的入门文章主 Agent 调资料检索 Agent再调内容整理 Agent输出一篇结构完整的 Markdown 文章帮我搜索 3 篇多 Agent 的文章只调资料检索 Agent返回 3 条带链接的结果把下面这段 Markdown 转成 Word调 Markdown 转 Word 工作流返回文档下载文件你是什么模型主 Agent 直接回答不调用任何子 Agent写一篇关于不存在领域的文章资料检索 Agent 返回空结果主 Agent 提示用户资料不足不硬写这些用例能帮助确认路由、工具调用、数据传递和兜底逻辑是否正常。5.2 预期运行路径和输出示例一次正常的文章生成请求预期日志会类似下面的路径。用户消息: 写一篇关于扣子工作流的入门文章 主 Agent: 判断需要检索资料调用资料检索 Agent 资料检索 Agent: 返回 5 条检索结果 主 Agent: 将检索结果转给内容整理 Agent 内容整理 Agent: 生成 Markdown 草稿 主 Agent: 汇总并输出最终文章最终输出示例# 扣子工作流入门 ## 1. 什么是工作流 工作流是扣子平台上用来组合多个步骤的编排方式。 ## 2. 核心节点 - 开始节点 - 插件节点 - 结束节点 ## 3. 一个最小示例 ...代码块...如果日志中省略了某个子 Agent或者输出内容没有对应检索结果就说明这段路径没有真正跑通。5.3 用四个指标判断协作质量验证多 Agent 项目时不要只看最终回答好不好还要关注以下四个指标。调用覆盖率针对一个复杂任务应该被调用的子 Agent 是否都被调用了。数据一致性子 Agent 返回的数据是否被后续环节完整使用有没有丢失字段。异常兜底率插件失败、搜索为空时主 Agent 是否能给出有效处理。响应效率整个协作链路的耗时是否在可接受范围内。如果每轮都超过 30 秒说明编排设计可能过于复杂。建议每次调整提示词后用同一套测试用例重新跑一遍记录前后差异。多 Agent 模型路由本身有一定随机性不要凭一两次成功判断项目已经稳定。6. 多 Agent 常见问题与排查链路6.1 主 Agent 不调用子 Agent自己把所有事情干了现象是用户发了一个复杂任务主 Agent 直接给出回答调试面板里没有任何子 Agent 调用记录。常见原因有三个主 Agent 人设没有明确“必须调用子 Agent”子 Agent 的描述太模糊主 Agent 不知道何时调用温度设置过高导致模型没有遵循调度规则。检查顺序是先看子 Agent 描述是否包含“什么时候用、输入是什么、输出是什么”再看主 Agent 提示词里是否明确禁止自己做执行工作最后把温度调低到 0.3 左右重试。推荐把子 Agent 描述写成“当用户需要搜索时使用不要自己搜索把主题传给它”。6.2 子 Agent 结果传不过去内容整理 Agent 拿到空数据现象是资料检索 Agent 明明返回了结果但内容整理 Agent 生成的还是幻觉内容。问题通常出在主 Agent 拼接上下文的环节它可能只把用户原话传给了内容整理 Agent没有把检索 JSON 拼进去。建议在主 Agent 提示词中增加一条“调用内容整理 Agent 时必须将资料检索 Agent 返回的 JSON 完整放在输入消息中并用‘资料 JSON’开头。”同时可以把检索结果写入变量在调用子 Agent 时引用变量减少拼接遗漏。6.3 搜索内容过时或模型幻觉现象是文章内容看起来合理但数据和链接是编造的。原因是资料检索 Agent 没有约束返回来源或内容整理 Agent 被允许自由发挥。解决方案是把边界写死。资料检索 Agent 必须返回真实链接没有结果时返回空数组内容整理 Agent 只能基于给定资料组织信息不能补充没有来源的细节。如果平台支持设置“回答必须包含引用来源”打开这个开关会明显改善。6.4 Agent 运行中断或工具限流现象是运行到一半日志出现类似“Agent terminated due to error”的提示或者插件返回 429 限流。这类问题通常不是提示词能解决的。首先检查是哪个节点中断。如果是插件节点报错重新授权或更换备用插件如果是模型服务超时缩短输入内容或换更快的模型如果是子 Agent 循环调用给子 Agent 增加“步骤上限”或“回答不了就返回错误”的约束。对于限流问题可以在工作流中增加重试和错误分支。比如搜索插件失败时降级到备用搜索源文档转换失败时返回“格式转换服务暂时不可用”的提示而不是让整个对话中断。问题现象常见原因检查方式处理建议主 Agent 不调用子 Agent描述不清或人设未约束检查子 Agent 描述和主 Agent 提示词补全触发条件和输出协议子 Agent 拿不到数据上下文拼接丢失查看日志中实际传给子 Agent 的内容使用变量并显式拼接 JSON内容出现幻觉约束太松检查内容 Agent 人设只允许基于给定资料生成运行中断工具异常或超时定位日志中断节点增加重试、降级和错误分支7. 从扣子到本地化部署Dify、Ollama 和扩展路线7.1 扣子、Dify、Workbuddy、OpenClaw 是什么关系多 Agent 概念火了之后市面上的工具名词越来越多。扣子Coze是云端托管的 Agent 构建平台适合快速验证和业务集成Dify 是开源的应用开发平台支持私有部署适合企业对数据安全要求较高的场景Workbuddy、OpenClaw 这类工具的定位和形态各不相同有的是专注于某个环节的框架有的偏向执行调度。它们不是同一类东西选择时更关键的是看团队到底需要“快速上线”还是“私有可控”。如果项目刚起步想验证业务效果用扣子最直接。如果要把 Agent 能力封装进内部系统并且数据必须留在内网建议考虑 Dify 加本地模型。迁移时不需要改动核心的 Agent 设计只需要把扣子中的子 Agent、工作流、知识库映射到新平台。7.2 把 Agent 搬回本地Ollama 加 Dify 的最小路线本地部署的核心诉求是数据不外传、成本可控、可自定义模型。一个最小路线是用 Ollama 跑开源模型再用 Dify 搭建 Agent 和工作流。安装 Ollama 后拉取一个适合中文任务的开源模型例如 Qwen 系列ollama pull qwen2.5:7b ollama run qwen2.5:7b在 Dify 的模型供应商中配置 Ollama可以参考下面这个示意配置model_provider: ollama api_base_url: http://localhost:11434/v1 model: qwen2.5:7b api_key: ollama配置完成后在 Dify 中创建一个 Agent 应用把工作流、知识库和工具挂载进去。这里的 Agent 设计方式与扣子多 Agent 类似主 Agent 负责人设和调度工作流负责稳定流程知识库负责私有数据。需要特别注意的是本地模型参数量越大推理延迟和显存占用越高不一定适合生产环境高频访问。初次实验建议先用 7B 到 14B 参数量的模型跑通后再评估是否升级。7.3 本地化部署需要补的运维能力本地化部署不是把模型下载下来就结束了。生产环境还需要考虑以下问题。运维项说明API Token 管理本地服务也要设置访问密钥不能裸奔日志脱敏用户输入和模型输出可能包含敏感信息日志要脱敏监控告警模型推理时间、请求量、错误率需要监控模型版本管理模型升级后要能做 A/B 对比数据备份知识库和业务数据需要定期备份权限控制不同用户、不同部门不能互相访问数据本地化部署并不自动等于安全。普通开发环境只需要能跑通生产环境则要补权限、日志、监控和回滚方案。8. 几个可以复用的清单和下一步练习建议8.1 多 Agent 设计复查清单设计阶段最容易犯的错是把多 Agent 当成装饰。使用下面这份清单对项目做一次自查。[ ] 任务是否真的需要拆分成多个 Agent还是单个 Agent 加工作流就能解决[ ] 每个子 Agent 是否有明确输入输出协议[ ] 子 Agent 之间的数据通过什么字段传递字段命名是否一致[ ] 主 Agent 是否知道自己不该做什么[ ] 子 Agent 描述是否足够清晰能让主 Agent 在正确场景下调用[ ] 是否有异常兜底逻辑例如检索为空、插件报错、格式转换失败[ ] 是否保留了关键变量避免多轮对话时重复搜索[ ] 是否存在循环调用风险子 Agent 之间是否可能互相调用如果某个子 Agent 只是把用户输入原样传给另一个子 Agent没有增加任何价值那就应该把它去掉。8.2 发布前检查清单项目上线前除了功能正常还要走一遍发布检查。[ ] 测试用例覆盖正常路径、分支路径和异常路径[ ] 模型参数已经针对多 Agent 场景调整过[ ] 所有插件都已经正确授权并在测试环境跑通过[ ] 主 Agent 的日志和调试信息能被定位到具体环节[ ] 用户敏感信息不会被写入变量或日志[ ] 通过 API 暴露给外部系统时Token 使用环境变量注入[ ] 限流和错误提示对用户是友好的不暴露内部错误详情8.3 下一步练习建议多 Agent 是一项需要反复实践的技能。建议按以下顺序继续深入。第一复刻一个简单的多 Agent 客户支持机器人。一个 Agent 负责查询订单一个 Agent 负责售后政策主 Agent 根据用户问题路由。第二把一个现有工作流接入多 Agent观察两者结合的调用路径。第三用 Ollama 加 Dify 跑通同一个最小用例对比云端平台和本地部署的开发效率与成本。第四主动制造错误例如禁用搜索插件、清空知识库观察主 Agent 的兜底行为是否合理。多 Agent 的核心不是模型数量多而是任务边界清楚、数据格式稳定、异常路径可见。把扣子上的这套设计想明白后续不管是迁移到 Dify、接入本地模型还是继续扩展子 Agent都能复用同一套思路。