多 Agent 协同是 Claw 模式的核心能力之一。用户可以在同一个应用中配置多个分工不同的子 Agent，由主 Agent 负责路由、调度和结果整合，共同完成单个 Agent 难以覆盖的复杂任务。
Claw 模式提供两种协同机制：
单向委派（默认机制）：主 Agent 将任务路由或拆分给子 Agent，子 Agent 独立执行并返回结果，最终由主 Agent 统一输出。适合意图分流、边界清晰的任务拆分和一次性并行处理。
团队协作（进阶能力，需手动开启）：在单向委派基础上，允许子 Agent 主动反馈，并允许团队成员按规则直接通信、共享任务进度和协同调整。适合需要质询、补充、返修、接力或动态协调的复杂任务。
说明：
“允许多 Agent 团队协作”是应用设置页中的开关名称。本文所说的“开启团队协作”均指打开该开关。
开启开关表示应用具备团队协作能力，不代表每次对话都会组队。运行时是否组队，由主 Agent 根据配置的团队协作规则和当前任务进行判断。
团队协作会产生额外的成员通信和协调调用，通常比单向委派消耗更多 Token。只在任务确实需要多角色互动时使用。
快速选择
一句话速判：
任务能被一个 Agent 稳定完成 → 单 Agent。
需要分工，但成员各自独立完成、无需互相通信 → 单向委派（默认机制）。
成员必须看到彼此的新增信息并据此质询、补证、返修或调整分工 → 团队协作。
单向委派机制
工作原理
单向委派是 Claw 模式默认的协同机制。主 Agent 作为调度中心，负责理解用户意图、决定由谁处理、拆分任务并整合结果；子 Agent 被动接收任务，完成后将结果返回主 Agent。
在单向委派模式下：
主 Agent 可以将不同子任务并行分发给多个子 Agent。
子 Agent 之间不能直接通信。
所有任务信息和执行结果都由主 Agent 中转。
最终回复由主 Agent 统一生成。
设置方式
第一步：配置主 Agent
主 Agent 是应用的调度和结果整合中心。
1. 配置名称：主 Agent 名称默认与应用名称保持一致。
2. 配置提示词：说明主 Agent 自身的职责、处理方式和输出要求，例如：
主 Agent 可以直接处理哪些任务。
如何根据用户意图选择合适的子 Agent，以及何时将不同子任务并行分发给多个子 Agent。
无法确定路由或子 Agent 执行失败时如何处理。
如何检查、整合并输出子 Agent 的结果。
3. 配置模型：建议选择规划、路由和综合能力较强的模型。
4. 配置 Skills、工具与连接器：按主 Agent 自身需要配置，可用于任务调度、结果整合或兜底处理。
第二步：添加子 Agent
1. 在左栏 子 Agent 区域，单击 添加子 Agent。
2. 填写子 Agent 基础配置：
配置项 | 说明 |
Agent 名称 | 使用简洁、明确的角色名称，例如“售前咨询 Agent”“独立审核员”。名称用于帮助主 Agent 快速识别角色。 |
Agent 描述 | 用简短文字说明该 Agent 何时应该被选择：擅长什么、适合处理什么、不处理什么。描述主要用于路由，不需要写完整执行步骤。支持使用 AI 一键优化，该操作会消耗 Agent 模型的 Token。 |
提示词 | 定义该 Agent 被选中后如何工作：身份、职责边界、执行步骤、工具使用方式、质量要求和返回格式。只描述该 Agent 自己的工作方法。 |
模型 | 选择适合该角色任务特性的模型，可以与主 Agent 不同。 |
Skills | 为该 Agent 添加专属技能。单 Agent 最多 80 个。 |
连接器与工具 | 为该 Agent 配置完成职责所需的能力。单 Agent 最多 1000 个工具（含连接器）。 |
3. 单击 保存。
注意：
单个应用的主 Agent 与子 Agent 合计最多 20 个，即最多配置 19 个子 Agent。
优先通过清晰的 Agent 名称和描述帮助主 Agent 判断路由；只有持续出现特定路由错误时，再在主 Agent 提示词中补充明确规则。
第三步：验证单向委派
在调试区域分别测试：
1. 输入每个子 Agent 职责范围内的典型问题，确认是否路由正确。
2. 输入可能同时匹配多个子 Agent 的边界问题，观察主 Agent 如何拆分和选择成员。
3. 输入不属于任何子 Agent 的问题，验证主 Agent 的兜底行为。
4. 输入可并行拆分的任务，确认各子 Agent 的任务没有重叠，最终结果能够正确汇总。
单向委派的调度方式
场景 | 调度方式 | 工作方式 |
仅 1 个子 Agent | 1 对 1 路由 | 主 Agent 判断是否将任务交给该子 Agent；未命中时由主 Agent 自行处理。 |
多个子 Agent | 单成员路由或多成员并行分发 | 主 Agent 可以将任务交给一个合适的子 Agent；也可以将不同且可独立执行的子任务并行分发给多个子 Agent，再统一整合结果。 |
开启团队协作
说明：
角色状态说明：在产品配置和未组队状态下，角色称为“主 Agent”和“子 Agent”；团队组建成功后，主 Agent 担任 Lead（队长），被选中加入团队的子 Agent 成为 Teammates（团队成员）。未被选中的子 Agent 不参与本次团队协作。本节在描述运行时行为时统一使用 Lead / Teammates。
工作原理
团队协作扩展了单向委派能力，支持成员主动反馈及按规则直接通信。团队组建后，Teammates 可以：
1. 主动向 Lead 反馈进展、阻塞和证据缺口。
2. 请求 Lead 或其他 Teammates 补充信息。
3. 按团队协作规则与其他 Teammates 直接通信。
4. 共享任务进度，进行质询、补充、返修或接力。
开启团队协作后，主 Agent 会结合当前任务和你配置的团队协作规则，判断是否需要组建团队。只有任务满足组队条件时才会创建团队；其他任务继续由主 Agent 直接处理或使用单向委派。主 Agent 主要判断：
是否需要组队。
需要哪些成员参与。
成员如何分工和通信。
何时停止协作并输出结果。
因此，团队协作效果取决于成员配置和团队协作规则是否清晰。
设置方式
第一步：开启团队协作
1. 在左栏底部的 高级设置 区域，找到并打开 允许多 Agent 团队协作 开关。
说明：
开关默认关闭。关闭后仍可使用单向委派。
开启前，请先创建 Claw 模式应用并至少配置一个子 Agent。
开启开关只是允许主 Agent 按团队协作规则判断是否组队，不会让所有任务强制组队。
团队协作复用现有子 Agent 的名称、描述、提示词、模型、Skills 和工具，无需重新创建成员。
第二步：配置团队协作规则
开启开关后会弹出 团队协作规则 界面。你也可以单击开关旁的设置图标重新编辑。
团队协作规则用于告诉主 Agent 什么时候组队，以及组队后如何调度成员。主 Agent 先判断当前任务是否满足组队条件；满足条件时创建团队并担任 Lead，被选中加入团队的子 Agent 成为 Teammates；不满足时，由主 Agent 直接处理或使用单向委派。
推荐包含以下内容：
1. 组队条件：主 Agent 在什么情况下创建团队；哪些任务不创建团队，继续按主 Agent 提示词处理。
2. 成员选择与分工：组队后，Lead 选择哪些 Teammates，如何拆解和分配任务，各任务是否存在先后依赖。
3. 协作方式：Teammates 何时直接通信、质询、补充或接力，哪些任务可以并行执行。
4. 异常处理：Teammate 失败、超时、结果冲突或信息不足时，Lead 如何重试、降级或转派。
5. 停止条件：最多协作几轮，满足什么条件后停止，以及 Lead 如何汇总最终结果。
说明：
第三步：调试团队协作
配置完成后，在调试预览区测试：
1. 组队判断：分别输入简单任务和复杂任务，检查主 Agent 是否按规则决定不组队或组队。
2. 成员选择：确认只激活完成任务真正需要的成员。
3. 协作链路：检查并行、接力、质询、补证和返修是否符合规则。
4. 异常处理：模拟成员失败、信息不足或结论冲突，检查 Lead 是否正确降级或处理。
5. 停止行为：检查团队是否能在达到完成条件或轮次上限后及时结束，不进行无目的讨论。
调试预览区会展示被激活的子 Agent、任务流转路径和执行状态，可据此优化团队规则、Agent 描述及提示词。
第四步：关闭团队协作
如果不再需要团队协作，可以在左栏底部的 高级设置 区域，关闭 允许多 Agent 团队协作 开关。
关闭操作会立即生效，平台不会弹出二次确认。关闭后：
应用不再创建团队；主 Agent 仍可直接处理任务，或通过单向委派调用一个或多个子 Agent。
主 Agent 和全部子 Agent 继续保留，可以正常进行单成员路由或多成员并行分发。
子 Agent 之间不再直接通信，也不再进行团队任务协作。
已填写的团队协作规则会继续保留，但在开关关闭期间不生效。
再次开启开关后，上次保存的团队协作规则会恢复生效，并可以继续编辑。
团队调度方式
团队组建后，Lead 可以根据团队协作规则，采用以下调度方式：
调度方式 | 工作方式 | 典型场景 |
Lead 与 Teammates 双向通信 | Teammates 可主动报告阻塞、请求补充或修正任务，Teammates 之间不直接交流。 | 多名成员执行中可能出现证据缺口，需要 Lead 动态补充或调整任务。 |
Teammates 直接通信 | 指定 Teammates 之间可以直接交换信息、质询或接力。 | 正反研究互相质疑、审核员定向要求作者返修。 |
两种调度方式可以在同一次团队协作中组合使用。例如，Teammates 先分别向 Lead 汇报，再由其中两名 Teammates 直接完成一轮质询。
各配置项的职责与边界
说明：
配置原则：Agent 名称与描述说明“什么时候选它”，Agent 提示词说明“它如何工作”，团队协作规则说明“什么时候组队、成员如何配合”。
配置位置 | 应填写的内容 | 示例 |
Agent 名称与描述 | 角色擅长什么、适合处理什么、不处理什么，用于帮助主 Agent 选择成员 | “事实研究员：负责检索和核验公开事实，不负责观点裁决” |
Agent 提示词 | 单个 Agent 的身份、职责、执行步骤、工具和 Skill 使用方式、质量要求及返回格式 | “优先使用官方来源；对关键数据进行交叉核验” |
团队协作规则 | 组队条件、成员选择与分工、通信或接力方式、异常处理和停止条件 | “需要正反论证时组队；两名研究员完成一轮交叉质询后停止” |
产物规范 Skill（可选） | 可复用的最终产物结构、字段、篇幅、格式和质量检查标准 | “报告包含摘要、证据、结论、局限及来源列表” |
判断一条要求写在哪里时，只需看它约束的对象：
约束一个 Agent 如何执行任务，写入该 Agent 提示词。
约束多个 Agent 如何共同完成任务，写入团队协作规则。
约束可复用的最终产物格式，内容简单时写入负责交付的主 Agent 提示词，内容复杂时封装为 Skill。
配置示例：深度研究团队
示例团队已配置事实研究员、反方研究员、分析研究员和独立审核员。以下仅展示部分提示词，用于说明不同配置项的职责边界。
主 Agent 提示词
你是深度研究团队的主 Agent，负责明确研究目标和范围、判断证据是否充分，并统一撰写最终报告；组建团队后担任 Lead。成稿时调用研究报告规范 Skill。简单事实问题直接回答，不自行包办全部检索任务。
这段内容定义主 Agent 自己的职责、工具使用，以及组队后担任 Lead 时的最终交付责任。
子 Agent 提示词
你是事实研究员，负责检索可验证事实、一手来源和关键数据。记录来源、日期、地区、定义和统计口径；不撰写最终报告。完成后返回证据卡和仍未解决的信息缺口。
这段内容只定义事实研究员自己的专业工作方式。
团队协作规则
需要多来源调查、争议分析或完整研究报告时，主 Agent 创建团队并担任 Lead；简单事实问答不创建团队，由主 Agent 直接处理。Lead 并行向事实研究员和反方研究员分配互补任务。首轮调查后，两名成员可以直接交换最多 3 条核心主张，完成一轮交叉质询。正反材料交给分析研究员统一口径。只有会影响核心结论的证据缺口才发起定向补证，最多一轮。最终报告由 Lead 统一撰写并交给独立审核员；审核最多一轮。达到上限仍未解决的问题写入研究局限。
这段内容只定义组队、分工、通信、补证、审校和停止方式，不重复研究员如何检索。
两种协同机制对比
能力 | 单向委派 | 团队协作 |
通信方向 | 主 Agent 向子 Agent 分发，子 Agent 返回结果 | Lead 与成员双向通信，成员之间可按规则直接通信 |
子 Agent 主动反馈 | 不支持 | 支持 |
子 Agent 直接通信 | 不支持 | 支持 |
共享任务进度和协同调整 | 不支持 | 支持 |
是否需要团队协作规则 | 否 | 是 |
配置复杂度 | 低 | 中 |
Token 消耗 | 较低 | 通常明显更高，实际消耗取决于成员数量、上下文长度和通信轮次 |
适用场景与选型建议
说明：
核心原则：不要只看任务是否复杂或是否包含多个角色，而要判断任务能否拆分，以及成员之间是否必须互动才能提高结果质量。
第一步：是否需要多个 Agent
先判断任务是否需要专业分工：
如果一个 Agent 可以稳定完成，使用单 Agent，例如简单问答、摘要、改写和单一工具调用。
如果任务包含多个专业领域、可以拆成多个独立子问题，或者需要独立角色降低单一视角偏差，再使用多 Agent。
不要仅为了展示多个角色而增加子 Agent；角色应具有清晰且不重复的职责。
第二步：子任务能否独立完成
如果子 Agent 接到任务后可以独立完成，只需将结果返回主 Agent，使用单向委派。
典型场景包括：
按领域路由：售前问题交给售前 Agent，售后问题交给售后 Agent。
一次性并行处理：分别调查多家供应商的价格、交期和服务，再由主 Agent 汇总。
独立多角度分析：用户、商业和技术专家分别评价同一方案，彼此不需要交换意见，由主 Agent 综合。
批量任务拆分：按地区、产品或文件拆分任务，各成员使用相同方法独立处理。
说明：
判断标准：删除子 Agent 之间的直接通信后，任务质量基本不受影响，就优先使用单向委派。
第三步：成员互动是否会实质改善结果
只有当成员需要根据其他成员的发现调整自己的工作，或者必须共同维护任务状态时，才开启团队协作。
典型场景包括：
交叉质询与补证：正反研究员交换核心主张，发现证据缺口后定向补充。
多维评审与挑战：风险挑战者针对其他评审员的关键假设提出质询，相关成员再回应。
审校与定向返修：审核员发现阻断问题后，将具体意见返回作者修改，而不是重新生成全部内容。
动态接力：前一成员的处理结果会决定下一成员的行动，需要主动反馈、确认或补充信息。
共享任务与自适应分工：执行过程中出现新问题，成员需要共享进度并调整任务负责人。
说明：
判断标准：如果成员必须看到其他成员的新增信息，并据此质询、补充、返修或调整分工，才需要团队协作。
选型速查表
任务特征 | 推荐方式 | 原因 |
简单问答、改写、摘要、单工具调用 | 单 Agent | 无需专业分工，调用链最短 |
按用户意图路由到不同专家 | 单向委派 | 每次通常只需要一个子 Agent |
多个独立子任务并行执行后统一汇总 | 单向委派 | 成员无需直接沟通 |
多个专家独立评价，最终由主 Agent 裁决 | 单向委派 | 独立性本身具有价值，避免相互影响 |
成员需要主动报告阻塞或请求补充 | 团队协作 | 需要主子双向通信 |
成员之间需要质询、补证或修正结论 | 团队协作 | 直接互动能改善结果质量 |
审核意见需要返回原负责人定向返修 | 团队协作 | 存在反馈闭环 |
执行中需要共享进度并动态调整分工 | 团队协作 | 计划无法在开始时完全确定 |
高频、低价值或成本高度敏感的任务 | 单 Agent 或单向委派 | 避免额外通信与 Token 消耗 |
容易误判的场景
1. 并行任务不一定需要团队协作
“多个 Agent 同时工作”不等于“团队协作”。如果成员分别完成独立任务，最后只需由主 Agent 汇总，单向委派通常更快、成本更低。
2. 顺序任务不一定适合团队协作
任务存在先后顺序，不代表成员必须组成团队。如果成员只需依次完成各自任务，不需要根据其他成员的反馈调整工作，优先使用单向委派；如果交接过程需要专业判断、主动反馈或定向返修，例如“撰稿 → 审核 → 返修”，才适合团队协作。
3. 多视角评审不一定需要成员直接通信
如果目标是获得彼此独立的意见，优先使用单向委派，避免成员相互影响。如果还需要挑战假设、回应质询和修正方案，再开启团队协作。
不建议使用团队协作的情况
成员职责高度重叠：多个成员执行相同任务，容易产生重复工作。
多人同时修改同一产物：容易覆盖内容或产生版本冲突。建议指定唯一成稿人，其他成员只提供材料或审核意见。
成员频繁等待但很少产生新信息：协调成本可能高于协作收益。
执行步骤固定且成员无需互动：优先使用单 Agent 或单向委派，避免不必要的团队通信。
低价值高频任务：团队通信产生的时间和 Token 成本可能超过任务价值。
控制团队协作成本与规模
团队协作会增加成员调用和通信，因此通常比单向委派消耗更多 Token。建议：
控制成员和协作轮次
1. 明确“不组队条件”，让简单任务由主 Agent 直接处理。
2. 只配置完成任务真正需要的成员。
3. 每个子任务只指定一名主要负责人。
4. 限制成员直接通信的对象、内容和轮次。
5. 只传递影响结论的新增信息，不重复完整任务背景。
6. 将大文件先结构化或摘要后再分发给成员。
7. 设置补证、质询和返修上限。
8. 达到上限后使用已有结果继续交付，并披露剩余局限。
9. 目前平台不会自动为单次团队协作任务设置 Token 消耗上限。建议开发者在团队协作规则中主动限制参与成员、通信轮次、补证次数和返修次数，并明确达到停止条件后的处理方式。
减少重复配置和上下文
说明：
配置原则：长期稳定且可复用的专业规范适合封装为 Skill，大篇幅参考资料适合放入知识库，确定性处理适合交给工具或 Skill；组队条件、成员选择、通信关系和停止条件仍应写入团队协作规则。
1. 将稳定、可复用的规范封装为 Skill：例如报告结构、引用格式、评分标准、证据卡、检查清单，以及日志解析、字段提取和脱敏等确定性处理方法。仅为实际需要的 Agent 配置和调用相应 Skill，避免在多个提示词中重复填写长篇规则。
2. 将大篇幅参考资料放入知识库：产品手册、行业资料和历史文档由 Agent 按需检索，不要完整复制到 Agent 提示词或团队协作规则中。
3. 将确定性处理交给工具或 Skill：原始日志切分、数据清洗、去重、格式转换和摘要等操作尽量只执行一次，后续成员复用处理结果，避免重复读取完整原始材料。
4. 让子 Agent 简洁返回结果：在子 Agent 提示词中明确返回内容，减少长篇复述。例如：
完成任务后，按照“结论、关键依据、来源、待确认问题”四个字段返回结果。补充或返修时只返回新增或修改的内容，不重复此前已经提交的信息。5. 让 Lead 按成员职责分配信息：在团队协作规则中要求 Lead 分配任务时只提供该成员需要的材料。例如：
Lead 分配任务时，应说明任务目标、输入材料和交付要求。团队共同目标和用户限制可同步给所有 Teammates；报价和预算信息只分配给成本评估员，系统架构资料只分配给技术评估员。不要在成员之间重复转发与其任务无关的完整材料。常见问题
1. 主 Agent 选择的成员不准确，如何优化？
先确认问题发生在哪个阶段，再修改对应配置。
1.1 未组队或使用单向委派时选择错误
例如，用户咨询价格，却被交给售后服务 Agent；或者一个任务应该并行交给多个子 Agent，却只调用了其中一个。
按以下顺序优化：
1. 优先修改 Agent 名称和描述，明确该 Agent 擅长什么、适合处理什么、不处理什么。
2. 如果多个 Agent 的职责边界仍容易混淆，再在主 Agent 提示词中增加选择规则。
3. 主 Agent 提示词示例：
用户咨询产品价格、报价和购买方式时，选择"售前咨询 Agent"。用户咨询故障、退换和售后服务时，选择"售后服务 Agent"。任务同时包含用户分析和渠道规划，且两个子任务可以独立完成时，并行分发给对应的两个子 Agent。
这类规则无论是否开启团队协作都可能使用，因此写在主 Agent 提示词中。
1.2 问题发生在团队协作时
如果出现以下情况，应修改团队协作规则：
实际问题 | 需要补充的规则 | 示例 |
简单任务也创建了团队 | 明确哪些任务不创建团队 | 简单事实查询不创建团队 |
需要成员互相质询，但没有创建团队 | 明确创建团队的触发条件 | 需要正反观点交叉质询时创建团队 |
已经创建团队，但选择了错误成员 | 明确任务与 Teammates 的对应关系 | 正反研究选择事实研究员和反方研究员 |
Teammates 被选中后不知道如何配合 | 明确通信对象、内容、轮次和停止条件 | 两名研究员交换核心主张，最多质询一轮 |
例如，可以在团队协作规则中写：
简单事实查询不创建团队，由主 Agent 按自身提示词处理。当研究任务需要正反观点交叉质询时，主 Agent 创建团队并担任 Lead，选择“事实研究员”和“反方研究员”作为 Teammates。两名 Teammates 完成首轮调查后，交换最多 3 条核心主张，进行一轮交叉质询。质询结束后将结果交给 Lead。
不要在主 Agent 提示词和团队协作规则中重复写同一条要求。如果两处指令冲突，可能导致成员选择和组队行为不稳定。
2. 团队协作规则和主 Agent 提示词是否都会影响调度？
会，但职责不同。判断方法：
即使不创建团队，这条规则仍然需要生效——写入主 Agent 提示词（例如主 Agent 自己负责什么、如何选择子 Agent、如何整合结果和兜底）。
只有创建团队时才需要这条规则——写入团队协作规则（例如组队条件、选择哪些 Teammates、成员如何通信、何时停止）。
3. 配置团队协作规则时有哪些常见错误？
3.1 在团队规则中复制每个 Agent 的完整提示词
问题：规则过长、职责重复，修改某个 Agent 时还需要同步维护团队规则。
改进：团队规则只引用已经配置好的 Teammate 名称，并描述成员之间的分工、通信和衔接关系。每个 Agent 的专业方法仍写在自己的提示词中。
3.2 只写“多个 Agent 互相协作完成任务”
问题：缺少组队条件、成员选择、通信对象和停止方式，容易出现不必要组队或无目的讨论。
改进：明确主 Agent 在什么情况下创建团队，以及组队后 Lead 选择哪些 Teammates、谁在什么条件下向谁发送什么信息。
3.3 让多个 Teammates 同时修改同一产物
问题：容易覆盖内容、产生版本冲突和重复返工。
改进：指定一名 Teammate 作为产物的唯一负责人；其他 Teammates 只提供材料、意见或审核结果，最终由 Lead 统一交付。
3.4 没有定义停止条件
问题：Teammates 可能反复质询、补充和返修，持续增加执行时间和 Token 消耗。
改进：设置最大通信轮次、补证次数、返修次数、超时或证据充分条件，并说明达到上限后的处理方式。
4. 开启团队协作后，需要重写原有子 Agent 提示词吗？
不需要重写。团队协作复用已有配置，但建议检查子 Agent 提示词是否明确：
自己负责和不负责什么。
接到任务后如何执行。
应向主 Agent（组队后为 Lead）返回什么信息。
遇到阻塞或证据不足时如何反馈。
跨成员通信关系和协作轮次应写入团队协作规则，而不是复制到每个子 Agent 提示词中。
5. 为什么打开开关后没有组建团队？
打开开关只表示允许团队协作，主 Agent 仍会依据团队协作规则和当前任务判断是否需要组队。请检查：
团队规则是否明确写出组队条件。
测试任务是否确实满足组队条件。
Agent 名称和描述是否足够清晰，使主 Agent 能选择正确成员。
是否同时存在“不要组队”等冲突指令。
6. 为什么简单任务也频繁组队？
通常是团队规则只写了“什么时候组队”，没有写“什么时候不组队”。建议补充：
简单事实问答、改写、摘要和单一工具调用不创建团队，由主 Agent 按自身提示词处理。成员之间无需互动的一次性并行任务不创建团队，由主 Agent 使用单向委派处理。
7. 如何查看团队成员之间的通信过程？
开启团队协作后，调试预览区会展示被激活的子 Agent、任务流转路径和执行状态。重点检查：
本次任务为什么组队。
是否激活了不需要的成员。
是否存在重复任务或无信息量消息。
成员是否按照规则直接通信。
达到完成条件后是否及时停止。
