首页龙虾技能列表 › Adaptive Team Research — 自适应多智能体团队评审

Adaptive Team Research — 自适应多智能体团队评审

v1.3.1

自适应多智能体团队用于软件项目评审。自动选择协作模式(集中调度/领域主导/对等协作),通过三轮结构化工作流(事实收集→交叉辩论→共识收敛)产出含成本估算的可执行行动计划。

0· 113·0 当前·0 累计
by @joe-rq (Joe-rq)·MIT-0
下载技能包
License
MIT-0
最后更新
2026/3/18
安全扫描
VirusTotal
无害
查看报告
OpenClaw
安全
high confidence
该技能的指令、文件资产和所需能力与其声明的用途(多智能体项目评审)一致;它不请求凭据或外部安装,但会读取您的项目文件并将评审文件写入 reviews/{project}-review.md,因此请考虑仓库内容的隐私性。
评估建议
该技能在编排多智能体项目评审方面似乎内部一致。在安装或运行之前:(1) 请注意它会读取您的仓库文件并在输出中包含文件路径和行号——删除或编辑任何敏感信息,或在清理后的副本上运行;(2) 它将在项目中创建/写入 reviews/{project-name}-review.md——确保您希望写入该文件并有备份,或在沙箱中运行;(3) 由于它会生成多个智能体角色(并行轮次),请注意计算资源使用情况,如果您的环境对智能体运行计费;(4) 技能本身不请求外部网络端点或凭据,但请确认您的智能体运行时不会自动将仓库数据传输到其他地方。如需更强保证,请在受控环境中对清理后的仓库副本运行此技能。...
详细分析 ▾
用途与能力
名称/描述描述了一个多智能体软件评审的编排器,SKILL.md + 参考文件正好实现了这一点:角色提示词、模式选择、轮次协议和画布模板。未请求任何无关的凭据、二进制文件或安装。
指令范围
运行时指令要求智能体读取项目目录(带有 file:path:line 引用的文件)、汇总发现,并在 reviews/{project-name}-review.md 创建/写入画布文件。此行为与声明的用途一致,但意味着智能体将访问任意仓库文件并在输出中嵌入文件路径/行号——如果存在,可能会暴露敏感信息。
安装机制
除指令/资产 markdown 外没有安装规范或代码文件;风险最低(安装程序不会下载或写入任何内容)。
凭证需求
该技能不请求任何环境变量、凭据或配置路径。所有请求的访问(读取仓库文件、写入评审文件)与代码/项目评审技能相称。
持久化与权限
always:false 和正常的自主调用设置。唯一描述的持久影响是将评审文件写入项目的 reviews/ 目录(预期)。该技能不请求系统级配置更改或其他技能的凭据。
安全有层次,运行前请审查代码。

License

MIT-0

可自由使用、修改和再分发,无需署名。

运行时依赖

无特殊依赖

版本

latestv1.3.12026/3/18

- 澄清了协作模式(集中调度、领域主导、对等协作)之间的差异,包括具体的智能体数量、提示词和工作流路径。 - 添加了模式选择后的强制用户确认检查点——执行暂停直到用户批准所选模式。 - 加强了 Round 1 事实收集的指令,明确了禁用词和错误处理。 - 指定了创建和存储评审画布文件作为独立工件的步骤和约束。 - 增强了共识构建阶段、成本估算和责任分配的指南。 - 扩展了故障排除部分,详细说明了常见误用和系统保护措施。

● 无害

安装命令 点击复制

官方npx clawhub@latest install adaptive-team-research
镜像加速npx clawhub@latest install adaptive-team-research --registry https://cn.clawhub-mirror.com

技能文档

概述

编排自适应多智能体研究团队,根据任务特征选择最优协作模式,通过三轮结构化工作流(事实收集 → 交叉辩论 → 共识收敛)产出可操作的洞察和行动计划。

三种模式不是文字标签,而是在 agent 数量、prompt 内容、画布结构上有实质差异的执行路径。

适用场景

  • 项目设计评审、架构评估
  • 产品策略分析(需要多方博弈视角)
  • 代码质量审计(需要跨职能交叉验证)
  • 用户明确要求多角度或团队协作式分析的软件项目评审任务

不适用场景

  • 单一维度的快速代码审查(直接用 architect-reviewer agent 更高效)
  • 非软件项目的分析任务(本 skill 的角色和 prompt 面向软件项目设计)
  • 需要实际执行代码修改的任务(本 skill 只产出分析报告和行动计划)
  • 简单问题的快速问答(多 agent 编排的启动成本远大于收益)

三种模式的实质差异

维度集中调度领域主导对等协作
Round 1 agent 数3(并行)3(Lead 加深,其余精简)3(并行,对等)
Round 2 agent 数1(仅 Critic)2(Lead 交叉 + Critic)4(3 交叉 + Critic)
Round 2 交叉评审Team Lead 自行完成Lead 评审全部,其余不参与三方互评
Round 3 决策方式Team Lead 直接裁决Lead 综合裁决投票矩阵 + 共识收敛
适用场景时间紧、产品决策、不确定选哪个模式某领域需要特别深入跨职能复杂权衡

工作流

Phase 0:模式选择

分析任务特征,选择协作模式。详见 references/mode-selection.md

集中调度模式(默认,推荐用于产品决策、时间紧迫、不确定选哪个模式)

  • Team Lead 协调并行研究,自行完成交叉验证和裁决
  • 最快收敛,最高输出完整度
  • Round 2 仅启动 Critic,交叉评审由 Team Lead 自行完成

领域主导模式(推荐用于某个维度需要特别深入的场景)

  • 领域专家(PM/Designer/Engineer)主导,其余辅助
  • Round 1 Lead 角色使用加深版 prompt,其余使用精简版
  • Round 2 仅 Lead 进行交叉评审 + Critic

对等协作模式(推荐用于跨职能复杂权衡场景)

  • 所有角色对等,结构化辩论
  • Round 2 三方互评 + Critic,最大化交叉碰撞
  • Round 3 使用完整投票矩阵

【强制门禁】用户确认点: 模式选定后,必须停下来向用户展示所选模式、选择理由和备选模式,然后等待用户确认。在用户明确确认之前,禁止启动 Round 1 的任何 agent。 如果用户不同意,根据反馈重新选择。

Phase 1:Round 1 — 事实收集(并行)

启动三个 Explore agent 并行执行,角色 prompt 从 references/role-prompts-r1.md 加载。

按模式区分:

模式PM agentDesigner agentEngineer agent
集中调度标准 prompt标准 prompt标准 prompt
领域主导Lead 加深版 / 精简版Lead 加深版 / 精简版Lead 加深版 / 精简版
对等协作标准 prompt标准 prompt标准 prompt
关键约束: 只写事实,不做评价,不给建议。禁用词:"好"、"差"、"应该"、"建议"、"改进"。

完成后 Team Lead 动作:

  • 收集三份事实清单
  • 【必须执行】assets/canvas-template.md 复制画布模板到项目的 reviews/ 目录(不存在则先创建目录),文件命名为 reviews/{project-name}-review.md不要将画布内容嵌入其他输出文件,必须创建独立的画布文件。
  • 替换模板变量:{{PROJECT_NAME}}{{DATE}}{{REVIEW_TARGET}}{{MODE}}
  • 提炼关键事实写入画布 Round 1 区域

Phase 2:Round 2 — 交叉辩论(按模式执行)

所有 agent 读取共享画布。角色 prompt 从 references/role-prompts-r2.md 加载。

模式启动 agent核心行为
集中调度Critic × 1Team Lead 自行交叉验证 + Critic 质询
领域主导Lead 交叉 + Critic × 2Lead 评审全部 + Critic 质询
对等协作3 交叉 + Critic × 4三方互评 + Critic 质询
完成后 Team Lead 构建投票矩阵、提取独到发现,写入画布 Round 2 区域。

详细协议(agent 类型、并行策略、输出格式)见 references/round-protocols.md Round 2 部分。

Phase 3:Round 3 — 共识收敛(Team Lead 执行)

由 Team Lead 直接执行,不委派给子 agent。

模式决策方式Critic 关键质询处理
集中调度/领域主导裁决者直接裁决必须逐条回应,不充分则归入"待定"
对等协作投票矩阵 + 共识收敛三方未回应则自动归入"待定"
行动计划优先级: P0(立即执行)→ P1(本轮迭代)→ P2(下周期)→ 待定(需用户确认)。每项必须包含:Engineer 成本估算 + 负责角色(PM/Designer/Engineer)。

详细共识判定规则、投票矩阵格式见 references/round-protocols.md Round 3 部分。

Phase 4:交付

  • 将完整 Round 3 结果写入共享画布
  • 向用户呈现简明摘要:
- 使用的模式及选择理由 - 共识项和分歧项数量 - Top 3 P0 行动项(附成本) - Critic 的关键洞察
  • 指引用户查看完整画布文件

示例

集中调度模式 — 项目设计评审

用户输入:

帮我做一个多视角评审,目标是 my-web-app 这个项目

Phase 0 — 模式选择:

分析任务特征:用户未指定特定领域深入需求,任务为综合项目评审。
选定模式:集中调度(默认最佳平衡)。
理由:综合评审无明确主导领域,集中调度可快速收敛且输出完整度最高。
>
等待用户确认...

用户确认后 → 执行 Round 1~3:

  • Round 1:并行启动 PM / Designer / Engineer 三个 Explore agent 收集事实
  • Round 2:Team Lead 自行交叉验证 + 启动 Critic agent 质询
  • Round 3:Team Lead 直接裁决,输出行动计划

Phase 4 — 交付摘要:

使用模式: 集中调度
共识项: 5 项 | 分歧项: 2 项
Top 3 P0 行动:
1. 补充缺失的 API 输入验证(成本:4h)
2. 统一组件库替代散落的原生元素(成本:8h)
3. 添加 loading 骨架屏覆盖 3 个关键页面(成本:3h)
>
完整画布文件:reviews/my-web-app-review.md

核心设计原则

  • 模式决定执行路径 — 不同模式的 agent 数量、prompt 内容、画布结构有实质差异
  • 事实先于观点 — Round 1 纯事实收集,观点仅在 Round 2 引入
  • 对等尊重 — 无论哪种模式,Critic 对所有角色一视同仁
  • 结构化分歧 — 每个反驳必须附带理由,不接受无依据的意见
  • 强制收敛 — Round 3 必须产出共识和行动计划,不允许无限辩论
  • Critic 是催化剂 — Critic 不写自己的发现,只挑战他人的发现;不投票,但对关键质询有升级权
  • 成本感知 — Engineer 必须为每个改进建议估算实现成本

常见错误

错误解决
Round 1 agent 输出包含评价性词汇检查输出是否违反禁用词列表("好/差/应该/建议"),违反则要求重写
模式选定后未等用户确认就启动 Round 1Phase 0 是强制门禁——必须输出模式选择结果后停下等用户确认,禁止在同一轮中继续执行 Round 1
Critic 关键质询超过 3 条提醒 Critic 保持克制,标记上限为 3 条,滥用会稀释效力
对等协作模式 Round 3 未使用投票矩阵对等模式必须走完整投票流程,不可退化为裁决模式
行动计划缺少成本估算每个行动项必须包含 Engineer 的实现成本,缺失则补充
行动计划缺少负责角色每个行动项必须标注负责角色(PM/Designer/Engineer),缺失则补充
画布内容嵌入输出文件而未创建独立文件必须在 reviews/ 目录下创建独立画布文件,不要将画布内容写入其他文件

资源文件

  • references/role-prompts-r1.md — Round 1 各角色 prompt 模板(标准/加深/精简版)
  • references/role-prompts-r2.md — Round 2 交叉评论者 + Critic prompt 模板
  • references/mode-selection.md — 模式选择指南:决策树、混合模式、中途切换
  • references/round-protocols.md — 轮次协议详解:每轮按模式说明 agent 数量、类型、并行策略、完成标志
  • assets/canvas-template.md — 共享画布模板,复制到项目的 reviews/ 目录后替换变量使用
数据来源:ClawHub ↗ · 中文优化:龙虾技能库
OpenClaw 技能定制 / 插件定制 / 私有工作流定制

免费技能或插件可能存在安全风险,如需更匹配、更安全的方案,建议联系付费定制

了解定制服务