尧图网页设计 
各位做 AI 应用开发的朋友应该都有同感单智能体跑 Demo 很容易一旦扔进真实业务很快就撞到天花板。不是模型不够强而是“一个 Agent 什么都干”这件事本身就不符合复杂任务的拆解逻辑。本文以 Coze 为例完整拆解多 Agent 协作方案。内容包括多 Agent 的分工调度逻辑、项目空间配置、主从模式理解、SubAgent 的定位与工具挂载然后通过一个“AI 软件测试工作台”实战案例把多 Agent 团队从零搭起来。1. 为什么说“单智能体”正在成为项目落地的瓶颈1.1 单智能体解决不了的问题先看一个常见的业务场景你想做一个自动生成测试报告的功能于是创建了一个 Bot塞给它一大堆工具和知识库让它既能写测试用例、又能分析缺陷、还要生成 Markdown 报告。表面上这个 Bot 很全能实际跑两轮就发现问题上下文被稀释。各种测试规范、项目背景、产品需求、历史缺陷全部挤在同一个上下文窗口里真正关键的指令被淹没。工具调用冲突。一个 Agent 同时挂接数据库查询、文档生成、接口测试等多个工具时模型经常陷入“反复尝试错误工具”的循环。角色定位模糊。同一个 Agent 既要用产品思维设计用例又要用测试思维判断缺陷等级还要用开发思维定位问题输出风格和思考路径难以稳定。问题根因无法归责。一旦输出结果不理想你很难判断是哪个提示词、哪个工具、哪段逻辑出了问题。这些问题的本质是“一个人干三个岗位的活”。真实软件团队里产品、开发、测试是三个角色有各自的职责边界、评审流程和产出物。把三个角色揉进一个 Agent违背了复杂任务应该被拆分处理的基本规律。1.2 多 Agent 协作的典型应用场景多 Agent 模式解决的就是这类问题。近几年主流 Agent 平台都在迭代多 Agent 能力。Coze 作为国内使用门槛较低、工具链比较完善的智能体开发平台在多 Agent 协作方面提供了比较完整的产品化方案。多 Agent 适合解决以下几类任务跨岗位协作型任务。比如“生成需求文档 → 输出技术方案 → 编写测试用例 → 执行测试分析”每一步由不同角色的 Agent 完成。需要专业领域隔离的任务。比如法律咨询、医疗问答、金融分析每个 Agent 只挂载自己领域的知识库和工具避免知识串味。需要多源信息汇总的任务。比如“同时搜索产品信息、竞品信息、用户评价再汇总成分析报告”不同 Agent 负责不同数据源最后主 Agent 统一汇总。长流程、多分支的自动化任务。比如工作流里不同节点调用不同 Agent按条件分支选择执行路径。如果你现在还在用一个巨型 Bot 硬撑所有业务那么本文的多 Agent 思路应该能给你一些启发。2. 认识 Coze 多 Agent 能力2.1 Coze 平台是什么Coze 是一个 AI Bot 开发平台用户可以在平台上通过配置的方式创建智能体不需要从零训练模型。平台提供了Bot 编排定义人设、系统提示词、开场白和推荐问题。插件与工具通过插件调用外部 API比如搜索、图片处理、代码执行、文档处理等。知识库上传文档让 Bot 基于私有知识回答。工作流通过可视化的节点编排实现复杂的流程逻辑。发布渠道可以发布到网页、小程序、企业微信等渠道也可以通过开放 API 对接自有系统。Coze 分为国内版和国际版国内版是 coze.cn国际版是 coze.com。本文的配置思路在两个版本中基本通用但具体入口名称和按钮位置可能略有差异建议以实际控制台为准。2.2 多 Agent 模式的协作机制主从模式与 SubAgentCoze 的多 Agent 功能核心是“一个主 Agent 多个 SubAgent子智能体”的协作结构。主 Agent 不直接处理所有细节任务而是扮演“项目经理”的角色。当用户输入请求后主 Agent 会根据任务内容判断应该调用哪个 SubAgent再把任务分发下去最后汇总 SubAgent 的结果并回复用户。SubAgent 是独立的智能体可以配置自己的人设与系统提示词工具和插件知识库技能工作流在主从模式中主 Agent 的职责是理解用户意图 → 拆解任务 → 调度 SubAgent → 汇总输出。这里有一个很重要的设计思想也是当前多 Agent 社区讨论比较多的一个观点SubAgent 本质上可以看作是一种另类的工具调用。传统工具调用中模型调用的是一个函数传入参数拿到返回值。多 Agent 模式下模型调用的是一个“拥有独立思考和工具能力”的 SubAgent传入的是任务描述拿到的是 SubAgent 的处理结果。把 SubAgent 当作“另类 Tool”来理解有几个实际好处在设计主 Agent 时你不需要关心 SubAgent 内部是如何实现的只需要关心它的输入和输出。你需要给每个 SubAgent 一个清晰的功能描述方便主 Agent 判断“什么时候调用谁”。你可以像管理工具列表一样管理 SubAgent 列表随时替换内部实现而不需要改动主 Agent。2.3 关键概念对照工作流、SubAgent、插件与 Tool在进入实战之前我们先理清几个容易混淆的概念概念作用与多 Agent 的关系工作流 Workflow可视化编排多步骤流程节点包括大模型、代码、插件、知识库、条件分支等可以作为 SubAgent 的技能也可以在主 Agent 中单独调用SubAgent独立的、可被主 Agent 调度的子智能体拥有自己的提示词、工具和知识库多 Agent 协作的基本执行单元插件 Plugin封装了外部 API 的能力模块挂载在 Agent 上让 Agent 拥有外部工具能力Tool广义上的工具集合包括插件、工作流、代码节点等在主从模式下SubAgent 可以被当作一种特殊 Tool 来管理简单来说工作流适合“流程确定、节点固定”的任务多 Agent 适合“需要角色分工、动态判断、灵活调度”的任务。两者并不冲突反而经常组合使用。3. 环境准备与平台入口3.1 开发平台入口与账号准备第一步是注册并登录 Coze 开发平台。国内用户访问 coze.cn使用手机号即可注册。国际版需要支持对应地区的访问方式为避免不必要的麻烦本文以国内版为例。登录后你会看到智能体平台的控制台在那里可以创建 Bot、管理知识库、编排工作流、查看发布记录。版本提示Coze 平台迭代速度比较快本文写作时对应的界面是 Coze 近期的多 Agent 能力版本。如果你看到的界面不同优先查看平台官方帮助文档注意功能名称的变化即可底层思路完全通用。3.2 项目空间配置在开始搭建多 Agent 之前建议先创建项目空间。项目空间解决的是资源组织问题。一个完整的项目往往包含多个 Bot、多个工作流、多个知识库和多个插件。如果没有项目空间这些资源会散落在个人账号下项目成员协作时也容易混乱。进入控制台后找到“项目空间”或“项目管理”入口创建项目。建议配置以下信息项目名称建议使用业务名称或项目代号例如“AI测试工作台”。项目描述写清楚项目职责方便后续维护。成员权限如果多人协作添加成员并设置角色管理员、开发者、访客等。在项目空间内部再依次创建主 Agent例如“测试团队管理者”SubAgent例如“用例设计专员”“缺陷分析专员”“报告生成专员”工作流例如“测试流程编排”知识库例如“测试规范库”这样做的好处是所有资源归属清晰权限可控后续发布和管理都有边界。项目空间配置其实是很多新手容易忽略的一步做多 Agent 项目时建议认真对待。3.3 关于版本与界面差异的提醒Coze 的功能迭代非常快经常有新版本发布。如果你搜索相关资料会看到“coze 旧版本”“coze 新版本”等话题。这类话题主要指的是界面布局和功能名称的变化。比如早期版本中Bot 的配置项叫“技能”新版本可能直接叫“工作流”或“插件”。多 Agent 入口可能在不同版本中位置不同有的在 Bot 编排页面里有的在“高级设置”里。遇到这种情况不用纠结。抓住一个核心思路找“多 Agent”或“SubAgent”相关配置入口而不是死记按钮位置。4. 实战案例搭建一个 AI 软件测试工作台下面进入本文的核心环节。我们用 Coze 搭建一个“AI 软件测试工作台”完整演示多 Agent 的分工与调度。4.1 案例需求与角色分工业务背景是这样的测试人员收到一个功能需求需要输出测试方案、测试用例和测试报告。整个流程涉及需求理解、用例设计、缺陷分析和报告生成。如果用一个单 Agent 来做容易发生前文提到的“角色串味”。所以我们把流程拆成 4 个角色Agent 名称角色定位核心职责主 Agent测试团队管理者理解用户需求拆解任务分发到对应 SubAgent汇总结果用例设计专员 SubAgent测试设计角色根据需求设计测试用例输出用例表格缺陷分析专员 SubAgent测试分析角色根据测试结果分析问题原因给出风险建议报告生成专员 SubAgent文档输出角色汇总内容生成规范化的测试报告Markdown这个结构的特点是每个 SubAgent 只关注一个环节主 Agent 负责调度和汇总。4.2 项目空间与角色配置打开项目空间先创建“AI测试工作台”项目。然后在项目中创建 4 个智能体。主 Agent 的名称可以叫“测试团队管理者”其余三个分别叫“用例设计专员”“缺陷分析专员”“报告生成专员”。创建 SubAgent 时在 Agent 类型中选择“子智能体SubAgent”或类似选项。部分版本的 Coze 支持在主 Agent 的编排页面中直接添加 SubAgent操作路径可能不同但最终形成的结构一致。提示如果创建的是独立 Bot需要在主 Agent 配置里把它添加为 SubAgent如果平台支持直接创建子智能体则省去这一步。以实际界面支持为准。4.3 编写各个 SubAgent 的系统提示词多 Agent 协作效果好不好系统提示词占比很重。下面给出每个 Agent 的提示词示例你可以直接复制到对应 Agent 的系统提示词中。主 Agent测试团队管理者你是“测试团队管理者”负责管理一个软件测试团队。 团队中有以下成员 1. 用例设计专员负责将需求拆解成可执行的测试用例。 2. 缺陷分析专员负责分析测试结果中的缺陷原因和风险。 3. 报告生成专员负责汇总所有信息输出规范化测试报告。 你的工作流程如下 1. 用户提出测试需求后先理解需求判断需要哪些团队成员参与。 2. 将任务分发给对应专员说明任务背景、输出格式和完成标准。 3. 收集所有专员的输出检查内容是否完整。 4. 汇总成最终回复呈现给用户。 注意 - 不要替代专员完成细节工作。 - 如果任务比较复杂先拆解成子任务再逐个分发。 - 最终回复要条理清晰包括需求概述、执行过程、产出结果。用例设计专员SubAgent你是“用例设计专员”负责根据需求编写软件测试用例。 你的工作步骤 1. 阅读需求描述提取功能点、边界条件、异常场景。 2. 按功能模块组织测试用例。 3. 每条用例包含用例编号、用例名称、前置条件、测试步骤、预期结果、优先级。 4. 输出格式为 Markdown 表格。 质量要求 - 覆盖正常流程和异常流程。 - 对边界值专门设计用例。 - 用例步骤要清晰任何人都能照着执行。缺陷分析专员SubAgent你是“缺陷分析专员”负责对测试结果或用户反馈进行问题分析。 你的工作步骤 1. 阅读输入的问题描述或测试结果。 2. 判断问题属于功能缺陷、性能问题、兼容性问题还是需求理解偏差。 3. 分析可能的原因按概率排序。 4. 给出风险等级和建议处理方式。 输出格式 - 问题概述 - 问题分类 - 可能原因 - 风险等级 - 处理建议报告生成专员SubAgent你是“报告生成专员”负责将测试过程和结果整理成规范的测试报告。 你的工作步骤 1. 收集用例设计结果、缺陷分析结果、测试结论。 2. 按报告结构整理内容包括测试概述、测试范围、用例执行情况、缺陷统计、风险分析、测试结论。 3. 输出为 Markdown 格式结构清晰数据用表格呈现。 质量要求 - 报告语言正式、准确、无歧义。 - 所有数据必须来自输入内容不要编造。 - 结论部分要明确给出是否通过测试的建议。这几个提示词的核心思路是每个 Agent 的人设、输入、输出格式、质量要求都写清楚方便主 Agent 调度也方便模型稳定输出。4.4 主 Agent 的编排逻辑如果平台支持在主 Agent 中编排 SubAgent 调度逻辑你需要把每个 SubAgent 的“功能描述”写清楚。这个描述会作为主 Agent 判断“什么时候调用谁”的依据。例如用例设计专员调用它之前请提供需求描述。它会返回一份 Markdown 格式的测试用例表格。 缺陷分析专员调用它之前请提供测试结果或缺陷现象。它会返回问题分类、可能原因、风险等级和处理建议。 报告生成专员调用它之前请提供测试用例、缺陷分析和测试结论。它会返回规范化的测试报告。主 Agent 的调度逻辑可以理解为一段伪代码收到用户需求 if 需要设计测试用例: 调用【用例设计专员】 if 需要分析缺陷或测试结果: 调用【缺陷分析专员】 if 需要生成报告: 调用【报告生成专员】 收集所有返回结果 汇总输出在实际平台上这个流程可以配置为“自动调度”即让大模型自行判断调用哪些 SubAgent也可以配置为“工作流调度”用工作流把 SubAgent 调用节点按顺序串起来。两种方式的取舍自动调度灵活度高主 Agent 根据对话内容动态决定调用谁适合需求变化较多的场景。工作流调度流程固定可控性强适合流程稳定的业务。对“AI 软件测试工作台”这个案例建议先用自动调度跑通整个链路如果发现某一步经常调度错误再把该环节改成工作流节点固定执行。4.5 给 Agent 挂载工具与知识库多 Agent 配合工具才能发挥真正价值。这个案例中可以为不同 SubAgent 配置不同的工具和知识库。知识库设计创建一个“测试规范库”上传公司内部的测试流程规范、用例编写标准、缺陷等级定义等文档挂载到“用例设计专员”和“缺陷分析专员”上。创建一个“产品需求文档库”上传当前项目的需求文档方便多个 Agent 共享查询。工具/插件设计如果是测试在线系统可以给缺陷分析专员挂一个查询接口的插件传入任务 ID返回系统日志。如果需要生成 Markdown 文件并下载可以给报告生成专员配置一个文档处理插件。如果有“Markdown 转 Word”的需求可以单独创建一个工作流节点调用文档转换工具把报告生成专员的 Markdown 输出转成 Word 格式。关于工具挂载有一个重要的原则不要把所有工具都挂给所有 Agent。工具挂载越多模型选择越容易出错。谁用得上就给谁挂这个原则在多 Agent 项目中特别重要。Coze 也支持在工作流中编写代码节点如果你需要更灵活的处理逻辑可以在工作流里使用代码节点编写 Python 或 JavaScript 脚本对 SubAgent 的输出做二次加工。比如从测试用例表格中提取统计数据、计算用例通过率等。5. 运行调试与结果验证5.1 单 Agent 调试在完成配置后先不要急着跑完整的多 Agent 流程。建议先逐个调试 SubAgent打开“用例设计专员”单独输入一条测试需求看输出的用例表格是否合理。打开“缺陷分析专员”输入一个缺陷现象看问题分类是否准确。打开“报告生成专员”手动提供一份用例和缺陷数据看报告格式是否规范。单 Agent 调试的目的是确保每个执行单元本身是可靠的。如果 SubAgent 自己输出都不稳定主 Agent 调度的结果必然不稳定。5.2 多 Agent 联调单 Agent 验证通过后进入主 Agent 进行联调。在主 Agent 对话框中输入现在我们有一个新功能用户登录时需要增加验证码校验。请帮我完成测试方案、测试用例设计和测试报告。观察主 Agent 的行为是否成功把任务拆分成多个子任务是否调用到了正确的 SubAgent调用顺序是否符合预期最终汇总结果是否完整如果主 Agent 没有调用任何 SubAgent而是自己直接回答需要检查 SubAgent 的功能描述是否清晰、是否在主 Agent 配置中正确添加。如果主 Agent 调用了但结果不对比如把用例设计任务发给了报告生成专员可以优化 SubAgent 的“功能描述”让主 Agent 更容易理解各个 SubAgent 的职责边界。5.3 效果观察与输出验证以“用户登录增加验证码校验”为例完整的输出应该包含测试方案概览测试范围、测试环境、测试策略。测试用例表格正常登录、验证码正确、验证码过期、验证码错误、验证码为空、连续输错多次等场景。缺陷分析例如验证码不区分大小写是否算缺陷、验证码有效期过长的风险等级等。测试报告汇总执行结果、风险、结论。验证时重点关注输出内容是否达到“可用于真实测试”的质量而不是只看格式是否漂亮。如果发现某些用例缺失边界场景说明“用例设计专员”的提示词还需要补充要求。6. 常见问题与排查思路多 Agent 在 Coze 上落地最常见的问题集中在调度、上下文和工具调用三个方面。下面用表格汇总常见问题及排查思路。问题现象常见原因解决思路主 Agent 不调用 SubAgent自己直接回答SubAgent 未正确添加或功能描述不清检查主 Agent 配置确认 SubAgent 已关联重写功能描述说明输入输出调用了错误的 SubAgent各 SubAgent 职责边界模糊或名称相近修改 SubAgent 名称和描述使用更明确的职责关键词必要时用工作流固定调用关系SubAgent 输出与要求格式不一致系统提示词中格式要求不够具体在提示词中给出输出模板或示例明确要求 Markdown 表格格式多 Agent 串联后内容丢失上下文传递配置不完整某些 SubAgent 的输入字段为空检查主 Agent 与 SubAgent 之间的变量映射确保上传字段完整工具调用失败工具未授权、参数错误、插件版本升级在单 Agent 调试中单独验证工具可用性查看平台运行日志中的工具调用报错信息知识库内容不被 SubAgent 引用知识库未挂载到对应 SubAgent或文档解析质量差确认知识库关联用知识库测试功能先验证检索效果检查文档格式是否被平台支持运行速度慢SubAgent 数量多、上下文过长、外部 API 响应慢精简任务链路减少不必要的 Agent 调用缩短 SubAgent 上下文缓存常用查询结果输出包含编造的数据Agent 被要求生成无法获取的数据在提示词中强调“只能使用输入数据不得编造”增加人工校验节点排查多 Agent 问题时建议养成一个习惯每一步都单独验证。先验证知识库检索再验证工具调用再验证单 Agent 输出最后验证多 Agent 协同。这样可以快速定位是哪一层出了问题。7. 最佳实践与工程建议7.1 先画流程再配 Agent不要一开始就创建一堆 SubAgent。建议先在纸上或者白板上画出业务流程图明确用户输入是什么。需要拆成几个环节。每个环节由谁负责。环节之间的数据流是什么。最终输出是什么。画完图之后再根据流程图去创建 Agent。很多人做多 Agent 效果不好不是配置能力不行而是连流程都没想清楚就动手了。7.2 SubAgent 的角色边界要清晰每个 SubAgent 只做一件事这是多 Agent 设计中最重要的一条原则。比如用例设计专员只负责设计用例不要让它同时负责执行测试缺陷分析专员只负责分析不要让它自己去生成报告。角色边界越清晰主 Agent 的调度就越准确模型的输出也越稳定。如果一个 SubAgent 的提示词需要写很长的“如果……那么……”来判断要不要接手任务说明它的职责范围太宽了应该再拆分。7.3 把 SubAgent 当作一种 Tool 来管理在多 Agent 设计里主从模式本质上是将 SubAgent 视为一种另类的 Tool 进行调用。这意味着你在设计主 Agent 时可以考虑用管理工具列表的方式来管理 SubAgent 列表每个 SubAgent 有明确的名字。每个 SubAgent 有清晰的“输入说明”和“输出说明”。每个 SubAgent 有使用场景描述方便主 Agent 匹配。你可以把平台提供的插件、工作流和行为 API 的能力封装到 SubAgent 里而不是全部堆在主 Agent 身上。7.4 项目空间与权限管理多 Agent 项目通常需要多人协作建议从一开始就规范项目空间管理所有资源统一放在项目空间下不要散落在个人资源列表。按角色分配权限管理员写配置成员只读或只有调试权限。发布记录保留在项目中方便回滚。如果团队成员较多可以在 SubAgent 命名时增加前缀例如“测试-用例设计”“测试-缺陷分析”方便在大列表中快速检索。7.5 性能、成本与稳定性考量多 Agent 虽然能力更强但也会带来额外的性能和成本消耗。每个 SubAgent 调用都会产生一次模型推理主 Agent 还要额外进行调度推理。如果任务链路长消耗会成倍增长。实际项目中可以从这几方面做优化能不用 Agent 就不用。如果某个环节可以用工作流固定实现就不要让 Agent 动态判断。比如“Markdown 转 Word”这个动作用插件或接口处理更稳定没必要让 Agent 去理解。控制 SubAgent 数量。一个主 Agent 挂 3 到 5 个 SubAgent 通常是比较合理的范围。超过 10 个调度准确率会明显下降可以考虑改成“二级主从”结构。精简上下文。每次调用 SubAgent 时只传必要的信息不要把主 Agent 的全部历史对话都带上。加缓存和人工审核。高频、稳定输出的环节可以缓存结果关键业务环节建议保留人工审核节点避免自动化链路出错。8. 写在最后从小团队开始Coze 的多 Agent 能力本质上是从“一个人干所有事”升级为“一个团队分工协作”。它更适合真实业务流程但同时也对你的提示词设计、流程拆解和配置管理能力提出了更高要求。学习建议如下先从一个主 Agent 两个 SubAgent 的小团队开始跑通一个真实的业务闭环。确认稳定之后再逐步增加 SubAgent扩展业务范围。每一次改动都记录调整前后的效果对比形成自己的多 Agent 配置经验库。如果你准备在项目中落地多 Agent本文提到的“测试工作台”是一个比较容易上手的模板。把角色换成“文案策划 设计助理 排版专员”就变成内容生产团队换成“需求分析 代码实现 审核专家”就变成一个小型研发团队。从我自己的经验来看多 Agent 调试最花时间的往往不是 Agent 能力本身而是“哪个 Agent 应该负责什么”的边界设计。把这件事想清楚Coze 多 Agent 项目就成功了一大半。 Coze多Agent协作实战：从单智能体到AI测试工作台
各位做 AI 应用开发的朋友应该都有同感单智能体跑 Demo 很容易一旦扔进真实业务很快就撞到天花板。不是模型不够强而是“一个 Agent 什么都干”这件事本身就不符合复杂任务的拆解逻辑。本文以 Coze 为例完整拆解多 Agent 协作方案。内容包括多 Agent 的分工调度逻辑、项目空间配置、主从模式理解、SubAgent 的定位与工具挂载然后通过一个“AI 软件测试工作台”实战案例把多 Agent 团队从零搭起来。1. 为什么说“单智能体”正在成为项目落地的瓶颈1.1 单智能体解决不了的问题先看一个常见的业务场景你想做一个自动生成测试报告的功能于是创建了一个 Bot塞给它一大堆工具和知识库让它既能写测试用例、又能分析缺陷、还要生成 Markdown 报告。表面上这个 Bot 很全能实际跑两轮就发现问题上下文被稀释。各种测试规范、项目背景、产品需求、历史缺陷全部挤在同一个上下文窗口里真正关键的指令被淹没。工具调用冲突。一个 Agent 同时挂接数据库查询、文档生成、接口测试等多个工具时模型经常陷入“反复尝试错误工具”的循环。角色定位模糊。同一个 Agent 既要用产品思维设计用例又要用测试思维判断缺陷等级还要用开发思维定位问题输出风格和思考路径难以稳定。问题根因无法归责。一旦输出结果不理想你很难判断是哪个提示词、哪个工具、哪段逻辑出了问题。这些问题的本质是“一个人干三个岗位的活”。真实软件团队里产品、开发、测试是三个角色有各自的职责边界、评审流程和产出物。把三个角色揉进一个 Agent违背了复杂任务应该被拆分处理的基本规律。1.2 多 Agent 协作的典型应用场景多 Agent 模式解决的就是这类问题。近几年主流 Agent 平台都在迭代多 Agent 能力。Coze 作为国内使用门槛较低、工具链比较完善的智能体开发平台在多 Agent 协作方面提供了比较完整的产品化方案。多 Agent 适合解决以下几类任务跨岗位协作型任务。比如“生成需求文档 → 输出技术方案 → 编写测试用例 → 执行测试分析”每一步由不同角色的 Agent 完成。需要专业领域隔离的任务。比如法律咨询、医疗问答、金融分析每个 Agent 只挂载自己领域的知识库和工具避免知识串味。需要多源信息汇总的任务。比如“同时搜索产品信息、竞品信息、用户评价再汇总成分析报告”不同 Agent 负责不同数据源最后主 Agent 统一汇总。长流程、多分支的自动化任务。比如工作流里不同节点调用不同 Agent按条件分支选择执行路径。如果你现在还在用一个巨型 Bot 硬撑所有业务那么本文的多 Agent 思路应该能给你一些启发。2. 认识 Coze 多 Agent 能力2.1 Coze 平台是什么Coze 是一个 AI Bot 开发平台用户可以在平台上通过配置的方式创建智能体不需要从零训练模型。平台提供了Bot 编排定义人设、系统提示词、开场白和推荐问题。插件与工具通过插件调用外部 API比如搜索、图片处理、代码执行、文档处理等。知识库上传文档让 Bot 基于私有知识回答。工作流通过可视化的节点编排实现复杂的流程逻辑。发布渠道可以发布到网页、小程序、企业微信等渠道也可以通过开放 API 对接自有系统。Coze 分为国内版和国际版国内版是 coze.cn国际版是 coze.com。本文的配置思路在两个版本中基本通用但具体入口名称和按钮位置可能略有差异建议以实际控制台为准。2.2 多 Agent 模式的协作机制主从模式与 SubAgentCoze 的多 Agent 功能核心是“一个主 Agent 多个 SubAgent子智能体”的协作结构。主 Agent 不直接处理所有细节任务而是扮演“项目经理”的角色。当用户输入请求后主 Agent 会根据任务内容判断应该调用哪个 SubAgent再把任务分发下去最后汇总 SubAgent 的结果并回复用户。SubAgent 是独立的智能体可以配置自己的人设与系统提示词工具和插件知识库技能工作流在主从模式中主 Agent 的职责是理解用户意图 → 拆解任务 → 调度 SubAgent → 汇总输出。这里有一个很重要的设计思想也是当前多 Agent 社区讨论比较多的一个观点SubAgent 本质上可以看作是一种另类的工具调用。传统工具调用中模型调用的是一个函数传入参数拿到返回值。多 Agent 模式下模型调用的是一个“拥有独立思考和工具能力”的 SubAgent传入的是任务描述拿到的是 SubAgent 的处理结果。把 SubAgent 当作“另类 Tool”来理解有几个实际好处在设计主 Agent 时你不需要关心 SubAgent 内部是如何实现的只需要关心它的输入和输出。你需要给每个 SubAgent 一个清晰的功能描述方便主 Agent 判断“什么时候调用谁”。你可以像管理工具列表一样管理 SubAgent 列表随时替换内部实现而不需要改动主 Agent。2.3 关键概念对照工作流、SubAgent、插件与 Tool在进入实战之前我们先理清几个容易混淆的概念概念作用与多 Agent 的关系工作流 Workflow可视化编排多步骤流程节点包括大模型、代码、插件、知识库、条件分支等可以作为 SubAgent 的技能也可以在主 Agent 中单独调用SubAgent独立的、可被主 Agent 调度的子智能体拥有自己的提示词、工具和知识库多 Agent 协作的基本执行单元插件 Plugin封装了外部 API 的能力模块挂载在 Agent 上让 Agent 拥有外部工具能力Tool广义上的工具集合包括插件、工作流、代码节点等在主从模式下SubAgent 可以被当作一种特殊 Tool 来管理简单来说工作流适合“流程确定、节点固定”的任务多 Agent 适合“需要角色分工、动态判断、灵活调度”的任务。两者并不冲突反而经常组合使用。3. 环境准备与平台入口3.1 开发平台入口与账号准备第一步是注册并登录 Coze 开发平台。国内用户访问 coze.cn使用手机号即可注册。国际版需要支持对应地区的访问方式为避免不必要的麻烦本文以国内版为例。登录后你会看到智能体平台的控制台在那里可以创建 Bot、管理知识库、编排工作流、查看发布记录。版本提示Coze 平台迭代速度比较快本文写作时对应的界面是 Coze 近期的多 Agent 能力版本。如果你看到的界面不同优先查看平台官方帮助文档注意功能名称的变化即可底层思路完全通用。3.2 项目空间配置在开始搭建多 Agent 之前建议先创建项目空间。项目空间解决的是资源组织问题。一个完整的项目往往包含多个 Bot、多个工作流、多个知识库和多个插件。如果没有项目空间这些资源会散落在个人账号下项目成员协作时也容易混乱。进入控制台后找到“项目空间”或“项目管理”入口创建项目。建议配置以下信息项目名称建议使用业务名称或项目代号例如“AI测试工作台”。项目描述写清楚项目职责方便后续维护。成员权限如果多人协作添加成员并设置角色管理员、开发者、访客等。在项目空间内部再依次创建主 Agent例如“测试团队管理者”SubAgent例如“用例设计专员”“缺陷分析专员”“报告生成专员”工作流例如“测试流程编排”知识库例如“测试规范库”这样做的好处是所有资源归属清晰权限可控后续发布和管理都有边界。项目空间配置其实是很多新手容易忽略的一步做多 Agent 项目时建议认真对待。3.3 关于版本与界面差异的提醒Coze 的功能迭代非常快经常有新版本发布。如果你搜索相关资料会看到“coze 旧版本”“coze 新版本”等话题。这类话题主要指的是界面布局和功能名称的变化。比如早期版本中Bot 的配置项叫“技能”新版本可能直接叫“工作流”或“插件”。多 Agent 入口可能在不同版本中位置不同有的在 Bot 编排页面里有的在“高级设置”里。遇到这种情况不用纠结。抓住一个核心思路找“多 Agent”或“SubAgent”相关配置入口而不是死记按钮位置。4. 实战案例搭建一个 AI 软件测试工作台下面进入本文的核心环节。我们用 Coze 搭建一个“AI 软件测试工作台”完整演示多 Agent 的分工与调度。4.1 案例需求与角色分工业务背景是这样的测试人员收到一个功能需求需要输出测试方案、测试用例和测试报告。整个流程涉及需求理解、用例设计、缺陷分析和报告生成。如果用一个单 Agent 来做容易发生前文提到的“角色串味”。所以我们把流程拆成 4 个角色Agent 名称角色定位核心职责主 Agent测试团队管理者理解用户需求拆解任务分发到对应 SubAgent汇总结果用例设计专员 SubAgent测试设计角色根据需求设计测试用例输出用例表格缺陷分析专员 SubAgent测试分析角色根据测试结果分析问题原因给出风险建议报告生成专员 SubAgent文档输出角色汇总内容生成规范化的测试报告Markdown这个结构的特点是每个 SubAgent 只关注一个环节主 Agent 负责调度和汇总。4.2 项目空间与角色配置打开项目空间先创建“AI测试工作台”项目。然后在项目中创建 4 个智能体。主 Agent 的名称可以叫“测试团队管理者”其余三个分别叫“用例设计专员”“缺陷分析专员”“报告生成专员”。创建 SubAgent 时在 Agent 类型中选择“子智能体SubAgent”或类似选项。部分版本的 Coze 支持在主 Agent 的编排页面中直接添加 SubAgent操作路径可能不同但最终形成的结构一致。提示如果创建的是独立 Bot需要在主 Agent 配置里把它添加为 SubAgent如果平台支持直接创建子智能体则省去这一步。以实际界面支持为准。4.3 编写各个 SubAgent 的系统提示词多 Agent 协作效果好不好系统提示词占比很重。下面给出每个 Agent 的提示词示例你可以直接复制到对应 Agent 的系统提示词中。主 Agent测试团队管理者你是“测试团队管理者”负责管理一个软件测试团队。 团队中有以下成员 1. 用例设计专员负责将需求拆解成可执行的测试用例。 2. 缺陷分析专员负责分析测试结果中的缺陷原因和风险。 3. 报告生成专员负责汇总所有信息输出规范化测试报告。 你的工作流程如下 1. 用户提出测试需求后先理解需求判断需要哪些团队成员参与。 2. 将任务分发给对应专员说明任务背景、输出格式和完成标准。 3. 收集所有专员的输出检查内容是否完整。 4. 汇总成最终回复呈现给用户。 注意 - 不要替代专员完成细节工作。 - 如果任务比较复杂先拆解成子任务再逐个分发。 - 最终回复要条理清晰包括需求概述、执行过程、产出结果。用例设计专员SubAgent你是“用例设计专员”负责根据需求编写软件测试用例。 你的工作步骤 1. 阅读需求描述提取功能点、边界条件、异常场景。 2. 按功能模块组织测试用例。 3. 每条用例包含用例编号、用例名称、前置条件、测试步骤、预期结果、优先级。 4. 输出格式为 Markdown 表格。 质量要求 - 覆盖正常流程和异常流程。 - 对边界值专门设计用例。 - 用例步骤要清晰任何人都能照着执行。缺陷分析专员SubAgent你是“缺陷分析专员”负责对测试结果或用户反馈进行问题分析。 你的工作步骤 1. 阅读输入的问题描述或测试结果。 2. 判断问题属于功能缺陷、性能问题、兼容性问题还是需求理解偏差。 3. 分析可能的原因按概率排序。 4. 给出风险等级和建议处理方式。 输出格式 - 问题概述 - 问题分类 - 可能原因 - 风险等级 - 处理建议报告生成专员SubAgent你是“报告生成专员”负责将测试过程和结果整理成规范的测试报告。 你的工作步骤 1. 收集用例设计结果、缺陷分析结果、测试结论。 2. 按报告结构整理内容包括测试概述、测试范围、用例执行情况、缺陷统计、风险分析、测试结论。 3. 输出为 Markdown 格式结构清晰数据用表格呈现。 质量要求 - 报告语言正式、准确、无歧义。 - 所有数据必须来自输入内容不要编造。 - 结论部分要明确给出是否通过测试的建议。这几个提示词的核心思路是每个 Agent 的人设、输入、输出格式、质量要求都写清楚方便主 Agent 调度也方便模型稳定输出。4.4 主 Agent 的编排逻辑如果平台支持在主 Agent 中编排 SubAgent 调度逻辑你需要把每个 SubAgent 的“功能描述”写清楚。这个描述会作为主 Agent 判断“什么时候调用谁”的依据。例如用例设计专员调用它之前请提供需求描述。它会返回一份 Markdown 格式的测试用例表格。 缺陷分析专员调用它之前请提供测试结果或缺陷现象。它会返回问题分类、可能原因、风险等级和处理建议。 报告生成专员调用它之前请提供测试用例、缺陷分析和测试结论。它会返回规范化的测试报告。主 Agent 的调度逻辑可以理解为一段伪代码收到用户需求 if 需要设计测试用例: 调用【用例设计专员】 if 需要分析缺陷或测试结果: 调用【缺陷分析专员】 if 需要生成报告: 调用【报告生成专员】 收集所有返回结果 汇总输出在实际平台上这个流程可以配置为“自动调度”即让大模型自行判断调用哪些 SubAgent也可以配置为“工作流调度”用工作流把 SubAgent 调用节点按顺序串起来。两种方式的取舍自动调度灵活度高主 Agent 根据对话内容动态决定调用谁适合需求变化较多的场景。工作流调度流程固定可控性强适合流程稳定的业务。对“AI 软件测试工作台”这个案例建议先用自动调度跑通整个链路如果发现某一步经常调度错误再把该环节改成工作流节点固定执行。4.5 给 Agent 挂载工具与知识库多 Agent 配合工具才能发挥真正价值。这个案例中可以为不同 SubAgent 配置不同的工具和知识库。知识库设计创建一个“测试规范库”上传公司内部的测试流程规范、用例编写标准、缺陷等级定义等文档挂载到“用例设计专员”和“缺陷分析专员”上。创建一个“产品需求文档库”上传当前项目的需求文档方便多个 Agent 共享查询。工具/插件设计如果是测试在线系统可以给缺陷分析专员挂一个查询接口的插件传入任务 ID返回系统日志。如果需要生成 Markdown 文件并下载可以给报告生成专员配置一个文档处理插件。如果有“Markdown 转 Word”的需求可以单独创建一个工作流节点调用文档转换工具把报告生成专员的 Markdown 输出转成 Word 格式。关于工具挂载有一个重要的原则不要把所有工具都挂给所有 Agent。工具挂载越多模型选择越容易出错。谁用得上就给谁挂这个原则在多 Agent 项目中特别重要。Coze 也支持在工作流中编写代码节点如果你需要更灵活的处理逻辑可以在工作流里使用代码节点编写 Python 或 JavaScript 脚本对 SubAgent 的输出做二次加工。比如从测试用例表格中提取统计数据、计算用例通过率等。5. 运行调试与结果验证5.1 单 Agent 调试在完成配置后先不要急着跑完整的多 Agent 流程。建议先逐个调试 SubAgent打开“用例设计专员”单独输入一条测试需求看输出的用例表格是否合理。打开“缺陷分析专员”输入一个缺陷现象看问题分类是否准确。打开“报告生成专员”手动提供一份用例和缺陷数据看报告格式是否规范。单 Agent 调试的目的是确保每个执行单元本身是可靠的。如果 SubAgent 自己输出都不稳定主 Agent 调度的结果必然不稳定。5.2 多 Agent 联调单 Agent 验证通过后进入主 Agent 进行联调。在主 Agent 对话框中输入现在我们有一个新功能用户登录时需要增加验证码校验。请帮我完成测试方案、测试用例设计和测试报告。观察主 Agent 的行为是否成功把任务拆分成多个子任务是否调用到了正确的 SubAgent调用顺序是否符合预期最终汇总结果是否完整如果主 Agent 没有调用任何 SubAgent而是自己直接回答需要检查 SubAgent 的功能描述是否清晰、是否在主 Agent 配置中正确添加。如果主 Agent 调用了但结果不对比如把用例设计任务发给了报告生成专员可以优化 SubAgent 的“功能描述”让主 Agent 更容易理解各个 SubAgent 的职责边界。5.3 效果观察与输出验证以“用户登录增加验证码校验”为例完整的输出应该包含测试方案概览测试范围、测试环境、测试策略。测试用例表格正常登录、验证码正确、验证码过期、验证码错误、验证码为空、连续输错多次等场景。缺陷分析例如验证码不区分大小写是否算缺陷、验证码有效期过长的风险等级等。测试报告汇总执行结果、风险、结论。验证时重点关注输出内容是否达到“可用于真实测试”的质量而不是只看格式是否漂亮。如果发现某些用例缺失边界场景说明“用例设计专员”的提示词还需要补充要求。6. 常见问题与排查思路多 Agent 在 Coze 上落地最常见的问题集中在调度、上下文和工具调用三个方面。下面用表格汇总常见问题及排查思路。问题现象常见原因解决思路主 Agent 不调用 SubAgent自己直接回答SubAgent 未正确添加或功能描述不清检查主 Agent 配置确认 SubAgent 已关联重写功能描述说明输入输出调用了错误的 SubAgent各 SubAgent 职责边界模糊或名称相近修改 SubAgent 名称和描述使用更明确的职责关键词必要时用工作流固定调用关系SubAgent 输出与要求格式不一致系统提示词中格式要求不够具体在提示词中给出输出模板或示例明确要求 Markdown 表格格式多 Agent 串联后内容丢失上下文传递配置不完整某些 SubAgent 的输入字段为空检查主 Agent 与 SubAgent 之间的变量映射确保上传字段完整工具调用失败工具未授权、参数错误、插件版本升级在单 Agent 调试中单独验证工具可用性查看平台运行日志中的工具调用报错信息知识库内容不被 SubAgent 引用知识库未挂载到对应 SubAgent或文档解析质量差确认知识库关联用知识库测试功能先验证检索效果检查文档格式是否被平台支持运行速度慢SubAgent 数量多、上下文过长、外部 API 响应慢精简任务链路减少不必要的 Agent 调用缩短 SubAgent 上下文缓存常用查询结果输出包含编造的数据Agent 被要求生成无法获取的数据在提示词中强调“只能使用输入数据不得编造”增加人工校验节点排查多 Agent 问题时建议养成一个习惯每一步都单独验证。先验证知识库检索再验证工具调用再验证单 Agent 输出最后验证多 Agent 协同。这样可以快速定位是哪一层出了问题。7. 最佳实践与工程建议7.1 先画流程再配 Agent不要一开始就创建一堆 SubAgent。建议先在纸上或者白板上画出业务流程图明确用户输入是什么。需要拆成几个环节。每个环节由谁负责。环节之间的数据流是什么。最终输出是什么。画完图之后再根据流程图去创建 Agent。很多人做多 Agent 效果不好不是配置能力不行而是连流程都没想清楚就动手了。7.2 SubAgent 的角色边界要清晰每个 SubAgent 只做一件事这是多 Agent 设计中最重要的一条原则。比如用例设计专员只负责设计用例不要让它同时负责执行测试缺陷分析专员只负责分析不要让它自己去生成报告。角色边界越清晰主 Agent 的调度就越准确模型的输出也越稳定。如果一个 SubAgent 的提示词需要写很长的“如果……那么……”来判断要不要接手任务说明它的职责范围太宽了应该再拆分。7.3 把 SubAgent 当作一种 Tool 来管理在多 Agent 设计里主从模式本质上是将 SubAgent 视为一种另类的 Tool 进行调用。这意味着你在设计主 Agent 时可以考虑用管理工具列表的方式来管理 SubAgent 列表每个 SubAgent 有明确的名字。每个 SubAgent 有清晰的“输入说明”和“输出说明”。每个 SubAgent 有使用场景描述方便主 Agent 匹配。你可以把平台提供的插件、工作流和行为 API 的能力封装到 SubAgent 里而不是全部堆在主 Agent 身上。7.4 项目空间与权限管理多 Agent 项目通常需要多人协作建议从一开始就规范项目空间管理所有资源统一放在项目空间下不要散落在个人资源列表。按角色分配权限管理员写配置成员只读或只有调试权限。发布记录保留在项目中方便回滚。如果团队成员较多可以在 SubAgent 命名时增加前缀例如“测试-用例设计”“测试-缺陷分析”方便在大列表中快速检索。7.5 性能、成本与稳定性考量多 Agent 虽然能力更强但也会带来额外的性能和成本消耗。每个 SubAgent 调用都会产生一次模型推理主 Agent 还要额外进行调度推理。如果任务链路长消耗会成倍增长。实际项目中可以从这几方面做优化能不用 Agent 就不用。如果某个环节可以用工作流固定实现就不要让 Agent 动态判断。比如“Markdown 转 Word”这个动作用插件或接口处理更稳定没必要让 Agent 去理解。控制 SubAgent 数量。一个主 Agent 挂 3 到 5 个 SubAgent 通常是比较合理的范围。超过 10 个调度准确率会明显下降可以考虑改成“二级主从”结构。精简上下文。每次调用 SubAgent 时只传必要的信息不要把主 Agent 的全部历史对话都带上。加缓存和人工审核。高频、稳定输出的环节可以缓存结果关键业务环节建议保留人工审核节点避免自动化链路出错。8. 写在最后从小团队开始Coze 的多 Agent 能力本质上是从“一个人干所有事”升级为“一个团队分工协作”。它更适合真实业务流程但同时也对你的提示词设计、流程拆解和配置管理能力提出了更高要求。学习建议如下先从一个主 Agent 两个 SubAgent 的小团队开始跑通一个真实的业务闭环。确认稳定之后再逐步增加 SubAgent扩展业务范围。每一次改动都记录调整前后的效果对比形成自己的多 Agent 配置经验库。如果你准备在项目中落地多 Agent本文提到的“测试工作台”是一个比较容易上手的模板。把角色换成“文案策划 设计助理 排版专员”就变成内容生产团队换成“需求分析 代码实现 审核专家”就变成一个小型研发团队。从我自己的经验来看多 Agent 调试最花时间的往往不是 Agent 能力本身而是“哪个 Agent 应该负责什么”的边界设计。把这件事想清楚Coze 多 Agent 项目就成功了一大半。