国顺数字团队协作技能
数字团队协作 Skill — 江苏国顺智能科技有限公司专用
功能概述
为 OpenClaw 提供多智能体（Multi-Agent）协作能力，模拟真实数字团队的分工与讨论机制。适用于复杂任务拆解、技术方案评审、代码审查等场景。
三大核心模块：
| 模块 | 功能 | 触发关键词 |
|---|---|---|
| 🏛️ 角色池 | 预设数字团队角色（架构师/程序员/测试/产品经理） | "数字团队"、"角色分工"、"多人协作" |
| ⚖️ 辩论机制 | 多个 Agent 就问题正反方辩论，主 Agent 裁判总结 | "辩论一下"、"讨论"、"评审方案" |
| 📋 任务分发 | 主 Agent 分解任务，并行分派给多个子 Agent 执行 | "分配任务"、"并行处理"、"多人做" |
使用方式
方式一：关键词触发（推荐）
直接描述需求，Skill 会自动选择合适的模式：
帮我用数字团队评审这个技术方案...
组织一场辩论：要不要用微服务架构？
让数字团队分工完成这个项目...
方式二：显式调用子技能
/skill debate <topic> # 发起辩论
/skill roles <task> # 角色池分工
/skill assign <task> # 任务分发
模块一：角色池（Role Pool）
预设角色
| 角色 | 特点 | 擅长领域 |
|---|---|---|
| 架构师 | 全局视角，关注可扩展性、技术债 | 系统设计、技术选型、性能优化 |
| 程序员 | 务实实现，关注可行性、代码质量 | 前端/后端开发、Bug修复 |
| 测试工程师 | 质量把关，关注边界case、风险点 | 自动化测试、回归测试、压力测试 |
| 产品经理 | 用户视角，关注需求合理性、业务价值 | 需求分析、优先级排序、用户体验 |
| 项目经理 | 统筹协调，关注进度、风险、交付 | 任务拆解、资源调度、项目排期 |
| 安全专家 | 风险识别，关注漏洞、合规、权限 | 安全审计、渗透测试、权限设计 |
角色池使用示例
发起角色池协作：
数字团队评审：要不要把无人机平台从单体架构改成微服务？
执行流程：
- 主 Agent 分析任务，确定需要哪些角色
- spawn 各个子 Agent，每个赋予角色 prompt
- 各角色独立思考，输出各自观点
- 主 Agent 汇总各方观点，给出综合建议
模块二：辩论机制（Debate）
辩论流程
┌─────────────────────────────────────────┐
│ 辩论主持人（主 Agent） │
├─────────────────────────────────────────┤
│ 1. 宣布辩题，设置规则 │
│ 2. 分配正方 Agent A │
│ 3. 分配反方 Agent B │
│ 4. 收集 A 立论 → 收集 B 立论 │
│ 5. 收集 A 反驳 → 收集 B 反驳 │
│ 6. 多轮交替（默认3轮） │
│ 7. 主 Agent 总结双方观点，给出裁判 │
└─────────────────────────────────────────┘
辩论配置参数
| 参数 | 默认值 | 说明 |
|---|---|---|
| 轮次 | 3 | 双方交替发言的次数 |
| 每轮超时 | 60秒 | 子 Agent 单轮思考超时 |
| 辩题 | 用户提供 | 需要辩论的问题 |
| 角色数量 | 2 | 可扩展到多方辩论 |
辩论示例
辩题：无人机平台要不要上 K8s
辩题：无人机平台要不要上 K8s
【正方 - 架构师视角】
优势：
- 容器编排能力强大，适合多机场、多任务调度
- 弹性伸缩，当前 4 核服务器跑 12 个容器勉强
劣势：
- 学习成本高，团队没有 K8s 经验
- 部署复杂度增加，CI/CD 流程需要重构
结论：短期先用 Docker Compose，6个月后再考虑 K8s
【反方 - DevOps视角】
优势：
- K8s 现在是行业标准，招聘市场更好招人
- 自愈能力、滚动更新让运维更省心
劣势：
- 4 核机器跑 K8s 太勉强，最少需要 8 核
- 公司没有专职 SRE，K8s 维护成本高
结论：先用 K3s 过渡，保留 K8s 选项
【主 Agent 裁判】
综合评估：双方都认为当前服务器配置不适合直接上 K8s
建议：先用 Docker Compose + 监控，等业务量上来再迁移 K8s
模块三：任务分发（Task Distribution）
分发流程
┌─────────────────────────────────────────┐
│ 项目经理 Agent（主 Agent） │
├─────────────────────────────────────────┤
│ 1. 分析任务，拆解成独立子任务 │
│ 2. 确定子任务之间的依赖关系 │
│ 3. 并行分派无依赖的子任务给子 Agent │
│ 4. 收集各子 Agent 结果 │
│ 5. 合并结果，处理依赖顺序 │
│ 6. 输出最终交付物 │
└─────────────────────────────────────────┘
任务分发示例
任务：为无人机平台新增飞行记录统计功能
任务拆解：
├─ 子任务A：后端API开发（负责人：程序员）
│ ├─ 创建飞行记录数据模型
│ ├─ 实现统计查询接口 /api/flights/stats
│ └─ 编写单元测试
│
├─ 子任务B：前端页面开发（负责人：前端工程师）
│ ├─ 统计页面 UI 设计
│ ├─ 对接后端统计接口
│ └─ 响应式适配
│
├─ 子任务C：数据库优化（负责人：DBA/架构师）
│ ├─ 为飞行记录表加索引
│ ├─ 优化统计查询 SQL
│ └─ 添加数据聚合表
│
└─ 子任务D：测试验收（负责人：测试工程师）
├─ 编写自动化测试用例
└─ 性能测试（大数据量统计）
执行顺序：
- 阶段1（并行）：A、B、C 同时开始
- 阶段2：A、B 完成后，前端开始对接
- 阶段3：A、C、D 完成，测试工程师介入
- 阶段4：汇总，输出测试报告
团队协作配置
团队规模预设
| 规模 | 适用场景 | Agent 数量 |
|---|---|---|
| 小队（2-3人） | 简单任务、快速评审 | 1-2个子Agent |
| 中队（4-6人） | 中等复杂度、方案评审 | 3-4个子Agent |
| 大队（6+人） | 复杂项目、系统设计 | 5+个子Agent |
并行度配置
{
"max_parallel_agents": 5,
"max_rounds": 3,
"timeout_per_task": 120,
"summarize_results": true
}
注意事项
- Token 消耗：多 Agent 并行会消耗更多 token，建议复杂任务才用数字团队
- 子 Agent 超时：每个子 Agent 默认 60 秒超时，超时自动结束
- 结果汇总：主 Agent 负责最终汇总，子 Agent 只输出各自结果
- 辩论顺序：正方先立论 → 反方立论 → 交替反驳 → 主 Agent 总结
更新日志
- v1.0.0（2026-04-06）初始版本，包含三大核心模块