OpenClaw Agent Team：多 Agent 分工的判断、组织与验收方法

当任务变复杂时，单个 Agent 往往不是“不够聪明”，而是缺少清晰的分工、独立的校验视角，以及一个真正负责最终判断的角色。

这件事不只发生在代码、研究或内容创作里。一个养殖户想判断今年要不要扩大龙虾塘，一个创业者想判断要不要做新产品，一个内容团队想判断视频脚本值不值得拍，都会遇到同一个问题：信息很多、风险很多、每个人只看到一部分。

OpenClaw 是 DeepCarry 正在探索的 Agent 协作系统之一。OpenClaw Agent Team 要解决的，正是这种复杂任务的组织问题：让主 Agent 像项目负责人一样拆任务、设标准、收结果、做判断；让多个子 Agent 在明确边界内完成独立工作单元。

一句话定义：

主 Agent 是负责人，子 Agent 是独立专家；主 Agent 拆任务、设标准、收结果、做判断，子 Agent 在明确边界内完成专项工作。

更直白地说：不要只让一个 AI 一口气回答所有问题，而是让几个 AI 分别从不同角度看同一个问题，最后再由一个 AI 负责综合判断。

Agent Team 的目标不是制造更多回答，而是在复杂任务中提高判断质量、执行速度、盲点覆盖和可验证性。

为什么需要 Agent Team

单 Agent 很适合短任务、快速判断和单线执行。但当任务变成内容策划、产品评估、代码审查、竞品调研、投资研究，甚至是一次真实的经营决策时，单线程处理会遇到几个明显瓶颈：

1. 信息源变多，单个 Agent 串行处理会很慢。
2. 视角容易单一，可能漏掉用户、传播、技术、商业、风险等维度。
3. 长任务容易把调研、分析、执行、复盘混在一起，导致结果变散。
4. 重要任务需要第二视角，降低单一判断的主观偏差。

Agent Team 的价值，是把复杂任务拆成多个独立、可验证、可并行的工作单元，再由主 Agent 做最终综合。

这不是“多开几个 Agent 就会更好”，而是让复杂任务变得可组织、可检查、可复盘。

当前实践阶段

如果用能力成熟度来描述，OpenClaw Agent Team 已经不只是一次性实验，而是进入了稳定可用的小队协作阶段。

这个阶段已经可以稳定完成：

• 根据任务结构拆分子任务。
• 定义不同子 Agent 的角色和输入范围。
• 并行启动多个子 Agent。
• 要求子 Agent 输出结构化结果。
• 等待多份结果返回。
• 交叉验证、去重、提炼主决策。
• 将过程和结论沉淀为可复用的方法。

下一阶段的重点不是继续增加 Agent 数量，而是提升验收标准：

• 在任务开始前预设更清晰的通过 / 不通过标准。
• 覆盖更多真实任务类型：研究型、代码型、数据型、竞品型、执行型。
• 用真实指标证明 Agent Team 带来的收益，例如节省时间、发现遗漏、减少返工、提升最终决策质量。

主 Agent 与子 Agent 的职责边界

Agent Team 最重要的原则是：主 Agent 不能把最终判断外包给子 Agent。

子 Agent 可以提供证据、视角、审查和建议，但最终决策必须由主 Agent 完成。

可以把它理解成一个现实团队：

• 主 Agent 像负责人，决定问题怎么拆、听谁的、最后怎么做。
• 子 Agent 像专项顾问，只负责自己那一块，比如市场、成本、风险、技术或执行。
• 测试验收 Agent 像质检或验收负责人，专门检查最终结果是否符合一开始的目标和标准。
• 最终交付不是把几个人的话粘在一起，而是形成一个明确判断。

这里还有一条非常重要：测试验收不能只交给子 Agent。 测试验收 Agent 可以帮助发现问题、指出不符合目标的地方，但主 Agent 仍然要对最终结果负责。它就像一个部门 leader，不能因为有质检同事，就不对交付质量负责。

主 Agent 负责什么

主 Agent 是总负责人，负责：

1. 定义任务目标。
2. 判断是否需要 Agent Team。
3. 决定创建几个子 Agent。
4. 拆分子任务。
5. 设定输入范围。
6. 设定输出格式。
7. 设定验收标准。
8. 回收结果。
9. 去重、交叉验证、识别冲突。
10. 组织测试验收，检查结果是否符合目标、约束和预期。
11. 形成最终决策和交付。
12. 将可复用经验沉淀到项目记忆、系统记忆或团队文档中。

子 Agent 负责什么

子 Agent 是独立工作单元，适合做窄范围、明确边界、可验证的任务。

子 Agent 负责：

1. 阅读指定输入。
2. 从指定视角分析问题。
3. 输出结构化结论。
4. 提供证据和依据。
5. 不主动扩展任务边界。
6. 不承担最终决策。

其中有一种子 Agent 特别重要：测试验收 Agent。

测试验收 Agent 不负责产出主方案，而是负责检查：

1. 最终结果是否回答了最初的问题。
2. 是否满足任务开始前定义的成功标准。
3. 是否遗漏了关键约束、风险或边界条件。
4. 方案中的证据是否足够支撑结论。
5. 输出是否可以被执行、发布、交付或复盘。

如果 Agent Team 要产出真正可靠的结果，而不只是看起来很完整的结果，就必须有测试验收意识。复杂任务里，至少应该让一个子 Agent 承担验收视角；更重要的是，主 Agent 必须基于验收反馈做最终把关。

只有这个边界清楚，Agent Team 才不会变成多个回答的简单拼接。

如何决定创建几个子 Agent

Agent 数量由任务结构决定，不是越多越好。

0 个：简单任务

适用场景：

• 改一句话。
• 总结一小段内容。
• 查一个明确文件。
• 做一个单点判断。

这种任务主 Agent 直接完成即可，避免制造额外管理成本。

1 个：独立审查或第二视角

适用场景：

• 审一个方案有没有漏洞。
• 通读一个项目文件夹。
• 查一个竞品核心信息。
• 对主 Agent 初稿做独立批判。

典型结构是：主 Agent 先形成方案，子 Agent 找漏洞，主 Agent 再修订交付。

2-3 个：多维度复杂任务

这是最稳的 Agent Team 配置。

适用场景：

• 内容方案审查。
• 产品方案评估。
• 商业策略判断。
• 项目复盘。
• 风险评估。

例如内容方案可以拆成：

• 传播审查 Agent：看平台传播、标题、开场、分发策略。
• 用户视角 Agent：看用户是否愿意点开、看完、照做。
• 执行制片 Agent：看录制、剪辑、发布是否可落地。

例如产品方案可以拆成：

• 用户价值 Agent：看痛点、场景、使用频率。
• 技术可行性 Agent：看实现路径、依赖、风险。
• 商业化 Agent：看定价、转化、ROI、竞争格局。
• 测试验收 Agent：看最终方案是否符合目标、是否可执行、是否遗漏关键风险。

如果任务最终要交付一个明确结果，例如一份文章、一个产品方案、一段代码、一个研究结论或一次经营决策，建议默认加入测试验收 Agent。它不一定参与前期创作，但应该在主 Agent 综合前或综合后做一次独立检查。

3-5 个：多来源调研

适用场景：

• 竞品研究。
• 行业趋势分析。
• 多平台内容研究。
• 技术选型调研。

这类任务更适合按信息源拆分：

• 官网 / 文档 Agent。
• GitHub / 技术 Agent。
• X / 社区 Agent。
• YouTube / B站 / 小红书 Agent。
• 竞品对比 Agent。

5 个以上：大型明确并行任务

只有当任务边界非常清楚时，才适合启动 5 个以上子 Agent。例如：

• 多个竞品同时拆解。
• 多个平台独立调研。
• 大代码库多模块扫描。
• 多市场、多语言、多地区分析。

这里的风险是整合成本会快速上升。没有清晰结构时，不建议一开始创建太多 Agent。

判断是否启用 Agent Team 的五个变量

每次任务开始时，主 Agent 可以检查五个变量：

1. 可拆分性：任务是否能拆成互不重叠的部分？
2. 独立性：每个部分是否有独立输入和输出？
3. 并行价值：并行是否能节省时间或提高覆盖面？
4. 盲点价值：独立视角是否能降低偏差？
5. 整合能力：主 Agent 是否能综合结果并做最终判断？

如果第 1、2、5 不成立，应少开或不开子 Agent。

对普通用户来说，也可以不用记这五个变量，只问自己三个问题：

1. 这个问题是不是有多个角度要看？
2. 我是不是担心自己漏掉风险？
3. 最后是不是需要一个明确决策，而不只是更多资料？

如果三个答案都是“是”，就适合用 Agent Team。

标准工作流

普通用户可以先记住一个最简单的版本：

1. 把问题说清楚。
2. 让 AI 分成 2-3 个角色。
3. 给每个角色指定它只看什么、只判断什么。
4. 让每个角色给出证据、风险和建议。
5. 安排一个测试验收视角，检查结果是否符合目标。
6. 让主 Agent 综合成一个最终决策，并对结果负责。

下面是更完整的工作流。

Step 1：任务分类

先判断任务类型：

• 简单执行。
• 独立审查。
• 多维度方案。
• 多来源调研。
• 大型执行。

任务类型决定是否需要 Agent Team，也决定应该按角色拆，还是按信息源拆。

Step 2：定义验收标准

在启动子 Agent 之前，先定义：

• 成功标准。
• 失败标准。
• 必须返回的字段。
• 时间预算。
• 证据要求。

例如：

本次测试通过标准：3 个子 Agent 均返回；每个结果包含评分、风险、改进建议；主 Agent 能形成至少 1 个被多个视角共同支持的主决策。

没有验收标准，Agent Team 就很容易变成“看起来很热闹，但不知道有没有用”。

Step 3：拆分角色

角色应互补，避免重复。

好角色包括：

• 用户价值。
• 技术可行性。
• 商业化。
• 风险合规。
• 内容传播。
• 执行落地。
• 竞品来源。
• 社区反馈。

不好的角色包括：

• 泛泛分析 Agent。
• 全面研究 Agent。
• 随便看看 Agent。
• 帮我想想 Agent。

角色越具体，输出越可用。

Step 4：限制输入范围

每个子 Agent 都应该知道自己能看什么。

好的输入范围：

• 指定 2-5 个文件。
• 指定几个 URL。
• 指定某个目录或模块。
• 指定某个平台或数据源。

差的输入范围：

• “把整个项目都看一下”。
• “研究所有资料”。
• “全面分析这个行业”。

输入边界越清楚，子 Agent 越容易输出可验证的结论。

Step 5：规定输出格式

子 Agent 输出必须短、硬、可比较。

推荐结构：

• 最重要结论。
• 最大风险。
• 3 条改进建议。
• 评分。
• 证据引用。
• 下一步建议。

结构化输出的意义，是让主 Agent 能快速比较不同视角，而不是被多份长回答淹没。

Step 6：主 Agent 综合

子 Agent 返回后，主 Agent 要做综合，而不是简单拼接。

综合时重点看四件事：

1. 共识：多个 Agent 都提到的问题，优先级最高。
2. 冲突：不同 Agent 意见相反时，看证据强弱。
3. 缺口：有没有关键问题无人覆盖。
4. 行动：最终改什么、先做什么、如何验证。

主 Agent 最重要的工作，是把多个子 Agent 的输出变成一个清晰判断。

Step 7：测试验收

在最终交付前，Agent Team 必须做一次测试验收。

测试验收要回答五个问题：

1. 结果有没有回答最初的问题？
2. 结果有没有满足成功标准？
3. 是否遗漏了关键约束或风险？
4. 证据是否足够支撑结论？
5. 下一步动作是否清楚、可执行？

这个步骤可以由测试验收 Agent 先做独立检查，但主 Agent 必须再做最终把关。因为主 Agent 是整个 Agent Team 的负责人，不能只负责分工，不负责结果。

Step 8：记录复盘

每次 Agent Team 任务结束后，至少记录三件事：

1. 这次用了几个 Agent，为什么。
2. 哪个 Agent 贡献最大。
3. 下次要怎么拆得更好。

这一步会让 Agent Team 从一次性技巧变成长期能力。

可直接复用的子 Agent Prompt 模板

你是独立 <角色> 子 Agent。

只阅读以下输入：
1. <文件 / URL / 数据源>
2. <文件 / URL / 数据源>

目标：<一句话说明这个子 Agent 要解决的问题>

输出最多 <N> 条，必须包含：
1. <关键结论>
2. <最大风险>
3. <3 条改进建议>
4. <评分或是否通过>
5. <具体证据>

要求：
- 引用具体文件、页面、代码、片段或数据作为依据。
- 输出可执行建议。
- 聚焦你的角色视角。
- 不主动扩展到输入范围之外。
- 不输出长篇背景。

标准综合报告模板

# <任务名> 多 Agent 分工报告

## 任务目标

## 子 Agent 设置

| Agent | 角色 | 输入 | 输出要求 |
|---|---|---|---|

## 子 Agent 结果摘要

### Agent 1

- 评分：
- 关键结论：
- 风险：
- 建议：

### Agent 2

- 评分：
- 关键结论：
- 风险：
- 建议：

## 主 Agent 综合判断

## 测试验收结论

## 交叉验证结论

## 冲突与不确定性

## 最终决策

## 下一步

## 复盘

- 做得好：
- 问题：
- 下次改进：

一个普通业务例子：判断今年要不要扩大龙虾养殖规模

为了让这个方法更容易理解，我们先看一个非技术例子。

假设你是一个养龙虾的用户，今年想判断：

今年要不要把龙虾塘从 30 亩扩大到 60 亩？

如果只问一个 AI，它可能会给你一份很长的建议，里面同时包含市场、成本、天气、病害、销售、资金周转。内容看起来全面，但你很难判断哪些最重要，也不知道有没有漏掉关键风险。

这时就适合用 Agent Team。

主任务

请帮我判断今年是否应该把龙虾塘从 30 亩扩大到 60 亩。

请组织 3 个子 Agent 分别从市场、成本、风险角度分析。

每个子 Agent 都要给出：
1. 关键结论
2. 最大风险
3. 需要我补充的数据
4. 是否建议扩大
5. 理由

最后由主 Agent 综合成一个决策：扩大、谨慎扩大、暂缓。

综合后，请再用测试验收视角检查：
1. 是否回答了“要不要扩大到 60 亩”这个问题
2. 是否说明了关键风险
3. 是否给出了可以执行的下一步

Agent A：市场 Agent

市场 Agent 只看需求和销售问题，例如：

• 今年本地龙虾价格趋势怎么样？
• 餐饮、批发、社区团购等渠道需求是否稳定？
• 扩大产量后，是否有足够销售渠道接住？
• 如果集中上市，价格会不会被压低？

它的任务不是算成本，也不是看病害，而是回答：

多养出来的龙虾，能不能卖出去，并且卖到合理价格？

Agent B：成本 Agent

成本 Agent 只看投入和现金流，例如：

• 新增塘租或改造费用。
• 虾苗、饲料、人工、电费、水质维护成本。
• 增加 30 亩后，现金周转压力会不会明显变大。
• 价格下跌时，是否还能保本。

它的任务是回答：

扩大规模以后，账算不算得过来？

Agent C：风险 Agent

风险 Agent 只看不确定性，例如：

• 天气异常。
• 病害风险。
• 水质管理能力。
• 人手是否够。
• 销售渠道是否太集中。
• 如果亏损，最多能承受多少损失。

它的任务是回答：

最坏情况会发生什么？你扛不扛得住？

主 Agent 综合

三个子 Agent 返回后，主 Agent 不应该简单复制三份回答，而是要做最终判断。

例如它可能得出：

不建议直接从 30 亩扩大到 60 亩。更稳的方案是先扩大到 45 亩，并提前锁定至少 2 个稳定销售渠道。原因是市场 Agent 认为需求有机会，但成本 Agent 指出现金流压力会明显增加，风险 Agent 也提醒当前人手和水质管理能力还没有验证过 60 亩规模。

这个结论比“今年龙虾市场前景不错，可以考虑扩大”更有用。因为它不是泛泛建议，而是把市场、成本、风险放在一起，形成了一个可执行的决策。

但到这里还没有结束。主 Agent 还要做一次验收：

• 这个结论有没有回答“要不要扩大到 60 亩”？
• 是否解释了为什么不是 60 亩，而是先到 45 亩？
• 是否说明了扩大前必须锁定销售渠道？
• 是否提醒了现金流、人手和水质管理这些关键风险？

只有这些问题都过关，这个 Agent Team 的结果才算真正符合目标。

这就是 Agent Team 对普通用户的价值：它不是让 AI 说得更多，而是让 AI 帮你把复杂问题拆开、看全、再收回来。

一个真实样例：给视频脚本创建 3-Agent Team

在一次 DeepCarry 内容方案评估中，我们用 3 个子 Agent 分别从传播、用户、执行角度审查同一份视频脚本：

AI 帮你写邮件 / 改消息，真的能省多少脑力？

主任务是：

审查这篇视频脚本是否值得录制，并给出修改优先级。

Agent A：传播审查

你是内容传播审查子 Agent。

只审查这篇视频脚本和录制执行包。

目标：从 B站、YouTube、抖音、X 的传播角度审查。

输出最多 8 条，必须包含：
1. 当前最强传播点
2. 当前最大传播风险
3. 标题 / 开场的 3 条改进建议
4. 最适合首发的平台
5. 传播潜力 0-10 分评分

要求：引用具体脚本内容或分镜作为依据。

Agent B：用户审查

你是普通用户视角审查子 Agent。

只审查这篇视频脚本和录制执行包。

目标：从普通观众是否愿意点开、看完、照做的角度审查。

输出最多 8 条，必须包含：
1. 用户最容易被打动的地方
2. 用户最可能觉得无聊或太抽象的地方
3. 哪个 Demo 最有体感，哪个 Demo 最弱
4. 3 条让观众更容易照做的改进建议
5. 普通用户价值 0-10 分评分

要求：引用具体脚本内容或 Demo 作为依据。

Agent C：执行审查

你是执行制片审查子 Agent。

只审查这篇视频脚本和录制执行包。

目标：从实际录制、剪辑、发布执行角度审查。

输出最多 8 条，必须包含：
1. 当前是否真的可开录
2. 录制前还缺哪些素材或决策
3. 剪辑上最容易出问题的地方
4. 最小可行录制顺序
5. 执行成熟度 0-10 分评分

要求：引用具体分镜、清单或脚本内容作为依据。

主 Agent 如何综合

如果三个 Agent 都指向同一个问题，主 Agent 就应该把它升级为主决策。

在这个案例里，三个视角共同支持一个改动：

把“礼貌拒绝”Demo 前置为主钩子，并先剪 45-60 秒短视频测试反馈。

原因是：

• 传播角度：这个 Demo 最有情绪共鸣。
• 用户角度：这个 Demo 最有真实体感。
• 执行角度：这个 Demo 最适合先剪成短视频测试反馈。

这就是 Agent Team 的价值：多个独立视角共同支撑一个更稳的行动判断。

给新手的最小可行 Agent Team

第一次使用时，推荐直接套这个结构：

1. 批判 Agent：专门找问题。
2. 用户 Agent：专门看真实用户价值。
3. 执行 Agent：专门看能否低成本落地。
4. 测试验收 Agent：专门检查最终结果是否符合目标和预期。

这个配置适用于大多数方案评估、内容评估和产品评估。

最小可行提示词：

我有一个方案，请你帮我组织 3 个子 Agent 审查：

1. 批判 Agent：找最大漏洞。
2. 用户 Agent：判断用户是否真的需要。
3. 执行 Agent：判断能否低成本落地。

每个 Agent 最多输出 5 条，必须给评分和证据。

最后请主 Agent 综合成一个决策：做、改后做、暂缓。

综合完成后，请再用测试验收 Agent 检查这个决策是否回答了原始问题、是否符合目标、是否遗漏关键风险。

如果你不是技术用户，也可以把它改成更生活化的版本：

我有一个经营决策，请你帮我从 3 个角度审查：

1. 赚钱机会：这件事有没有真实收益？
2. 成本压力：需要投入多少钱、人力和时间？
3. 最大风险：最坏情况是什么，我能不能承受？

每个角度最多输出 5 条，必须给理由。

最后请综合成一个决策：做、缩小规模试做、暂缓。

综合后请再做一次测试验收：检查这个决策是否符合我的目标、风险是否讲清楚、下一步是否能执行。

Agent Team 的常见风险

风险 1：任务拆得太散

Agent 太多会让整合成本上升。解决方法是先用 2-3 个 Agent 试跑，必要时再扩展。

风险 2：子 Agent 输出泛泛而谈

根因通常是 prompt 没有指定输入、输出和证据要求。解决方法是强制要求引用来源和具体建议。

风险 3：主 Agent 变成转述员

Agent Team 的价值在综合判断，不在并列展示多个结果。主 Agent 必须输出最终决策。

风险 4：没有验收标准

没有通过 / 不通过标准，就无法判断协作是否有效。每次测试都应该预设通过条件。

风险 5：只有分工，没有测试验收

Agent Team 可能把任务拆得很好，但最后没人检查结果是否符合目标。解决方法是默认设置测试验收 Agent，并要求主 Agent 在最终交付前亲自做一次验收判断。

风险 6：重复视角

如果多个子 Agent 都做类似分析，会制造噪音。角色必须互补。

后续升级路径

Agent Team 从稳定可用走向更高水平，需要继续补齐四件事：

1. 每次 Agent Team 任务前预设验收阈值。
2. 累计不同类型样本：研究型、代码型、数据型、竞品型、执行型。
3. 把测试验收 Agent 固化为高风险任务的默认角色。
4. 记录指标：节省时间、发现遗漏数、冲突观点数、最终被采纳建议数、返工减少情况。
5. 把高频任务模式沉淀成技能、模板或固定 playbook。

下一批值得测试的方向包括：

• 研究型 Agent Team：例如 AI 生活好物竞品内容研究，可拆成 B站 / YouTube / 小红书 / X / 工具官网。
• 产品型 Agent Team：例如 DeepCarry 产品方向优先级，可拆成用户痛点 / 技术可行性 / 商业化 / 竞争格局。
• 代码型 Agent Team：例如扫描一个项目的架构风险，可拆成前端 / 后端 / 测试 / 安全。
• 投资研究型 Agent Team：例如分析一个 Crypto 项目，可拆成基本面 / 代币经济 / 链上数据 / 社区情绪 / 风险。

最终原则

Agent Team 的核心不是“更多 Agent”，而是“更清晰的分工、更强的证据、更好的最终判断”。

其中测试验收是最后一道闸门。没有验收，Agent Team 只是分工；有了验收，Agent Team 才更接近一个能对结果负责的团队。

最稳的默认配置是：

• 简单任务：0 个。
• 独立审查：1 个。
• 复杂方案：2-3 个。
• 多来源调研：3-5 个。
• 大型任务：先 3 个以内试跑，再按信息质量扩展。

DeepCarry 接下来会继续把这类高频协作模式沉淀成 OpenClaw 的可复用工作流，让复杂任务从“单次对话”走向“可组织、可验收、可复盘”。

无论你是在写代码、做内容、研究项目，还是判断一门生意要不要扩大规模，Agent Team 的本质都一样：先把问题拆给不同视角，再把结果收回到一个清晰决策里。