国顺数字团队协作

提供多智能体协作能力，模拟数字团队分工、辩论和任务分发，支持技术评审、代码审查和复杂项目管理。

Security Scan

技能声明的功能（模拟多智能体团队协作、辩论、任务分发）与随附的说明文档和脚本基本一致，未请求额外凭据、安装包或网络外联，整体内部一致性良好。

Purpose & Capability

技能名、描述、SKILL.md 和脚本都聚焦于“多智能体/数字团队”模拟与协作场景。没有要求与描述不相关的 binaries、凭据或配置路径，所需资源与声明目的匹配。

Instruction Scope

SKILL.md 描述会“spawn 各个子 Agent”并执行并行子 Agent 协作；随附脚本 (scripts/digital_team.sh) 实际上是一个本地 Bash 模板，用于打印角色提示与模拟对话流程，而不会主动读取敏感文件或发送网络请求。存在小的不一致：文档暗示可并行启动子 Agent（可能依赖平台能力），但脚本只做本地文本输出与示例流程，用户应确认在其运行环境中是否会以真实多代理方式调用外部模型/服务。

Install Mechanism

无安装规范（instruction-only 附带脚本），没有从网络下载或解压执行任意二进制的行为。脚本为纯 Bash 文本，不会在安装阶段写入额外代码或拉取外部资源。

Credentials

技能未声明也未使用任何环境变量、密钥或外部凭据。SKILL.md 提醒 token 消耗（通用提示），但没有向用户索要 API_KEY/TOKEN 等凭证，所需权限与功能复杂度相称。

Persistence & Privilege

flag: always 为 false，技能默认可被用户调用且允许模型自主调用（平台默认），但未请求长期驻留或修改其他技能/系统配置。无迹象显示技能会写入系统范围配置或持久保存凭据。

Assessment

该技能是一个以文本/脚本模拟多智能体团队协作的工具包： - 优点：描述、SKILL.md 与脚本在功能上基本一致，未请求凭据或联网安装，代码可读性高。 - 在使用前请注意：技能会以多 Agent 模式并行产生更多 token 消耗，避免在包含敏感或私有代码/数据的提示中直接启动多代理评审； - 验证运行方式：该仓内脚本仅在本地打印角色提示并模拟流程；如果将技能集成到能真正“spawn 子 Agent”的平台上，确认该平台是否会将数据/代码发送到外部模型或第三方服务； - 建议先在非敏感示例上测试（例如公开主题），确认没有意外的网络请求或外部调用，再用于真实项目或包含敏感信息的评审。

国顺数字团队协作技能

数字团队协作 Skill — 江苏国顺智能科技有限公司专用

功能概述

为 OpenClaw 提供多智能体（Multi-Agent）协作能力，模拟真实数字团队的分工与讨论机制。适用于复杂任务拆解、技术方案评审、代码审查等场景。

三大核心模块：

模块	功能	触发关键词
🏛️ 角色池	预设数字团队角色（架构师/程序员/测试/产品经理）	"数字团队"、"角色分工"、"多人协作"
⚖️ 辩论机制	多个 Agent 就问题正反方辩论，主 Agent 裁判总结	"辩论一下"、"讨论"、"评审方案"
📋 任务分发	主 Agent 分解任务，并行分派给多个子 Agent 执行	"分配任务"、"并行处理"、"多人做"

---

使用方式

方式一：关键词触发（推荐）

直接描述需求，Skill 会自动选择合适的模式：

帮我用数字团队评审这个技术方案...
组织一场辩论：要不要用微服务架构？
让数字团队分工完成这个项目...

方式二：显式调用子技能

/skill debate <topic>          # 发起辩论
/skill roles <task>           # 角色池分工
/skill assign <task>          # 任务分发

---

模块一：角色池（Role Pool）

预设角色

角色	特点	擅长领域
架构师	全局视角，关注可扩展性、技术债	系统设计、技术选型、性能优化
程序员	务实实现，关注可行性、代码质量	前端/后端开发、Bug修复
测试工程师	质量把关，关注边界case、风险点	自动化测试、回归测试、压力测试
产品经理	用户视角，关注需求合理性、业务价值	需求分析、优先级排序、用户体验
项目经理	统筹协调，关注进度、风险、交付	任务拆解、资源调度、项目排期
安全专家	风险识别，关注漏洞、合规、权限	安全审计、渗透测试、权限设计

角色池使用示例

发起角色池协作：

数字团队评审：要不要把无人机平台从单体架构改成微服务？

执行流程：

1. 主 Agent 分析任务，确定需要哪些角色
2. spawn 各个子 Agent，每个赋予角色 prompt
3. 各角色独立思考，输出各自观点
4. 主 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
}

---

注意事项

1. Token 消耗：多 Agent 并行会消耗更多 token，建议复杂任务才用数字团队
2. 子 Agent 超时：每个子 Agent 默认 60 秒超时，超时自动结束
3. 结果汇总：主 Agent 负责最终汇总，子 Agent 只输出各自结果
4. 辩论顺序：正方先立论 → 反方立论 → 交替反驳 → 主 Agent 总结

---

更新日志

• v1.0.0（2026-04-06）初始版本，包含三大核心模块