这个 Skill 能做什么，适合哪些场景？
ClawTeam 是 HKUDS 开源的框架无关 CLI 工具，用于将多个 AI 代理（如 Claude Code、Codex）编排为一个有 leader 和 worker 的团队。它通过 `clawteam` 命令提供团队与任务管理、代理间收件箱消息、git worktree 隔离、运行时配置（profile/preset）、git 上下文注入、快照恢复和终端看板监控。数据以 JSON 文件形式存在 `~/.clawteam/`，无需数据库或服务器。该技能是一个 SKILL.md 指南，教代理何时以及如何调用这些 CLI 命令来完成多代理协作。
- 创建团队并 spawn worker 代理，每个 worker 自动获得独立 git worktree、tmux 窗口和身份
- 维护共享看板任务（pending/in_progress/completed/blocked），支持依赖链与优先级，任务完成自动解锁下游任务
- 通过文件收件箱实现代理间点对点消息、广播与非破坏性 peek 读取
- 通过 preset/profile 配置非默认模型提供商，并可用
profile test/profile doctor做预检 - 提供
board show/live/attach/serve看板、git 冲突检查（context conflicts）、快照与恢复（team snapshot/restore） - 所有命令支持
--机器可读输出，写入使用原子 tmp+rename 防止数据损坏
- 使用 Claude Code 的开发者接到全栈应用等大型任务，希望代理自动拆分子任务并 spawn 多个 worker 并行实现
- 研究者在多 GPU 机器上想让 leader 代理为每张卡分配研究方向、跨代理汇总最优实验结果（如 README 中的 8×H100 自动化实验案例）
- 需要重构整个代码库的工程师，希望各代理在独立 worktree 中工作，通过 `context conflicts` 检查合并冲突后由 leader 汇总合并
- 想用非默认提供商（如 Moonshot Kimi、MiniMax）运行 worker 的用户，先用 preset 生成 profile 再以 `--profile` spawn
- 想要一次性启动预定义团队（如 7 代理对冲基金分析团队）的用户，通过 TOML 模板 `clawteam launch` 完成
- 没有 tmux、git 仓库或任一受支持 CLI 代理的环境——这些是该技能的硬性前置条件
- 只想单个代理完成小任务的用户——对可由单代理高效处理的简单工作，引入多代理编排是过度设计
- Windows 原生环境使用者——默认后端依赖 tmux，源材料未提供 Windows 原生支持说明
如何安装这个 Skill？
- spawn 默认开启 skip-permissions，即子代理默认跳过权限确认，建议始终使用 --no-skip-permissions 或配置 skip_permissions=false 并在可信环境运行。
- inbox receive 为销毁式读取，误用会丢失消息，脚本中优先使用 inbox peek。
- 技能文档版本号（0.3.1）与包元数据（0.3.0）不一致，安装前核对实际发布版本。
- 静态审查未执行任何命令，可靠性/有效性结论基于文档与测试代码推断，使用前请自行小规模验证。
- 依赖外部 CLI agent（claude/codex 等）与 tmux，环境中缺任一前提技能将无法工作。
- Shell / 命令行
- 本地文件系统
clawteam CLI (pip install, Python 3.10+)tmuxa CLI coding agent such as claude/codex/gemini/kimi/nanobot/openclawa git repository
先确认 CLI 是否已可用，缺失时通过 pip 安装：
clawteam --version
pip install clawteam如需 P2P（ZeroMQ）传输：
pip install "clawteam[p2p]"Claude Code：将本技能安装到 ~/.claude/skills/clawteam（仓库安装脚本会为检测到的客户端自动安装捆绑技能）。
Codex：将技能安装到 $CODEX_HOME/skills/clawteam（通常为 ~/.codex/skills/clawteam）。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 构建一个带认证、数据库和 React 前端的全栈待办应用，用 clawteam 把工作拆给多个代理并行完成
- 用 clawteam 重构整个代码库，每个模块分配一个 worker 在独立 worktree 中进行
- 创建一个团队，spawn 三个代理分别实现功能、写测试、跑 lint，并实时展示看板进度
- 检查 my-team 的任务状态和收件箱，把阻塞的任务重新分配给空闲的代理
技能由触发词激活：当你要求"创建团队"、"spawn 代理"、"分配任务"、"协调多个代理"、"查看看板"，或任务复杂到需要拆分给多代理（如"构建全栈应用"、"重构整个代码库"）时使用。典型流程：设置身份环境变量 → 创建团队与任务 → spawn workers → 监控看板 → task wait 等待完成。示例：
export CLAWTEAM_AGENT_ID="leader-001"
export CLAWTEAM_AGENT_NAME="leader"
export CLAWTEAM_AGENT_TYPE="leader"
clawteam team spawn-team my-team -d "Project team" -n leader
clawteam task create my-team "Implement feature" -o worker1
clawteam spawn --team my-team --agent-name worker1 --task "Implement the auth module"
clawteam board live my-team --interval 3
clawteam task wait my-team --timeout 300非默认提供商应通过 profile 配置：
clawteam preset generate-profile moonshot-cn claude --name claude-kimi
clawteam spawn tmux --profile claude-kimi --team my-team --agent-name worker5 --task "Build API endpoints"Worker 遵循轮询循环：检查任务 → 处理 → 检查收件箱 → 空闲时上报 lifecycle idle，直到 leader 显式关闭。
这个 Skill 有哪些优点和局限？
- 框架无关：任何能执行 shell 命令的 CLI 代理都可参与，无需 SDK 或框架锁定
- 零基础设施：状态存于 ~/.clawteam/ 的 JSON 文件，仅需文件系统和 tmux，无数据库/服务器/云依赖
- 内建依赖链自动解锁、git worktree 隔离、原子写入与快照恢复，工程细节完善
- 代理自组织：spawn 时自动注入协调提示词，worker 自主汇报状态与结果
- 前置条件较重：需要 Python 3.10+、tmux、git 仓库和至少一个可独立运行的 CLI 代理
- 默认 spawn 跳过权限确认（skip-permissions），在信任敏感环境中需谨慎并用 --no-skip-permissions 关闭
- Cursor 集成为实验性状态；技能本身仅是 CLI 使用指南，实际编排能力依赖 clawteam CLI 的成熟度
- `inbox receive` 是破坏性读取，误用会丢失消息，需配合 peek 使用
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| ClawTeam 多智能体协作技能 本页 | 54 · 谨慎使用 | ★ 5.5k | 5 个月前 | MIT |
| ClawTeam 多智能体协作 | 51 · 谨慎使用 | ★ 1.5k | 3 个月前 | MIT |
| ClawTeam 多智能体群集协作 | 49 · 谨慎使用 | ★ 1.5k | 3 个月前 | MIT |
| ClawTeam 多智能体蜂群协调技能（Hermes 适配版） | 48 · 谨慎使用 | ★ 1.5k | 3 个月前 | MIT |
| do — 功能开发编排器 | 47 · 谨慎使用 | ★ 2.8k | 5 个月前 | AGPL-3.0 |
README 将 ClawTeam 与其他多代理框架对比：后者通常由人类编写编排代码、依赖 Docker/Redis/消息队列且仅支持特定框架，而 ClawTeam 的编排者是 AI 代理本身，基础设施仅需文件系统与 tmux，隔离使用真实 git worktree，支持任意 CLI 代理。同仓库还提到其姊妹项目 CLI-Anything（让软件 agent 原生化），但本技能仅覆盖 ClawTeam 多代理协调。
FollowSkills 如何评估这个 Skill？
文档披露了数据目录、快照/恢复、原子写入与 --no-skip-permissions 覆盖项，风险可见；但 spawn 默认开启 skip-permissions（自动跳过权限确认）、默认销毁式 inbox receive、自动生成 git worktree 并注入上下文，最小权限与用户确认机制不完整，扣分。
SKILL.md、CLI 参考与 workflows 三份文档相互一致，命令、选项、数据模型对齐，仓库含 CI 与针对 spawn 适配器的测试；但静态审查无法执行复现关键路径，错误处理与失败反馈证据不足，按静态上限计 10。
触发条件描述具体（spawn agent、任务板、多代理协调等），适用/不适用边界、依赖前提（tmux、git、CLI agent）清晰，含 moonshot-cn/minimax-cn 等中国可用预设与中文文档入口，环境适配证据较好，接近满分但缺实测验证。
分层文档（SKILL.md→references）、MIT 许可、版本号、已知限制与注意事项较完整，维护归属 HKUDS 可见；但 SKILL.md 标 0.3.1 而 pyproject 为 0.3.0，版本不一致，changelog/更新路径未随技能文档给出，扣分。
README 展示了多场景用例与命令式结果描述，多代理编排价值主张明确；但无静态可验证的实际输出物（无提交的结果文件、用例输出仅为叙述性截图/动图链接），静态上限 7 以下，扣分。
仓库含 GitHub Actions CI（多 OS/多 Python 版本）与覆盖 spawn 适配器、skip-permissions 映射的提交测试套件，属可审计一手材料；但测试未覆盖技能文档宣传的关键路径全貌（任务板、inbox、profile 等），静态上限 5。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →