agent-team

# 智能体团队协作框架

## 任务目标
- 本Skill用于：统一管理和灵活组合多个智能体角色，组建任务导向的智能体团队
- 能力包含：智能体注册、动态组队、协作流程、角色扩展、共享记忆、实时沟通
- 触发条件：当需要多个智能体协同完成任务时，或需要管理特定场景的智能体组合时

## 核心概念：忙碌的AI团队公司

### 智能体即角色

每个智能体是一个独立的角色，具备：
- **角色定位**：明确的职责和专业领域
- **能力特征**：专业知识和性格特点
- **协作接口**：与其他智能体协作的方式
- **输出规范**：标准化的输出格式

### 智能体团队：一个忙碌的一人AI团队公司

团队由多个智能体组成，就像一个真实的工作团队：

#### 角色分工明确

**干活的智能体**（执行层）：
- 自动化工程智能体：实现技术方案、生成代码、部署系统
- 前端/后端工程师：编写代码、实现功能
- 数据分析师：处理数据、生成报告
- 运营专家：执行运营策略、优化流程

**指挥的智能体**（管理层）：
- 主持人：引导讨论流程、控制节奏
- 项目经理：制定计划、分配任务、跟踪进度
- 战略分析智能体：制定战略、规划方向
- 产品经理：定义产品、规划路线图

**挑毛病的智能体**（评审层）：
- 评审员：评估质量、发现问题、提供建议
- 技术架构师：评审架构、指出风险
- 市场分析师：评审方案、指出市场问题
- 财务顾问：评审成本、指出财务风险

#### 实时沟通可见

智能体之间的讨论过程完全可见：
- ✅ 实时显示发言过程
- ✅ 记录每个智能体的观点
- ✅ 展示辩论和争论
- ✅ 显示共识和分歧
- ✅ 记录决策过程

就像在一个真实的会议室，你能看到每个人发言、讨论、辩论的全过程。

#### 共享数据库记忆

所有智能体共享同一个数据库记忆：
- ✅ 统一的上下文信息
- ✅ 共享的项目状态
- ✅ 一致的决策历史
- ✅ 统一的知识库
- ✅ 不会前言不搭后语

确保智能体之间的信息一致，避免上下文混乱。

### 团队特点

- **动态组合**：根据任务需求选择合适的智能体
- **灵活协作**：智能体之间可以相互调用和补充
- **可扩展**：随时添加新的智能体角色
- **场景化**：常见场景有预设团队配置
- **实时沟通**：完整展示智能体之间的讨论过程
- **共享记忆**：统一的数据库记忆，确保上下文一致

## 智能体分类

### 1. 会议决策类智能体
适用于需要多角度分析、辩论和决策的场景。

**核心角色**：
- 技术架构师：系统架构、技术选型
- DevOps工程师：部署运维、稳定性
- 前端/后端工程师：用户体验/业务逻辑
- 产品经理：产品规划、用户需求
- 市场分析师：市场调研、竞品分析
- 财务顾问：成本控制、财务分析
- 项目经理：进度管理、资源协调

详见：[references/meeting-agents.md](references/meeting-agents.md)

### 2. OPC系统构建类智能体
适用于一人公司从"做事→做产品→做系统"的完整流程。

**核心角色**：
- 战略分析智能体：市场扫描、需求分析、机会识别
- 产品架构智能体：产品设计、模块化封装、技术选型
- 自动化工程智能体：流程设计、技术实现、系统集成

详见：[references/opc-agents.md](references/opc-agents.md)

### 3. 通用协作智能体
适用于跨场景的通用协作需求。

**核心角色**：
- 主持人：引导讨论流程、总结共识
- 记录员：整理讨论内容、生成会议记录
- 评审员：评估方案质量、提供改进建议
- 协调员：解决冲突、促进协作

详见：[references/general-agents.md](references/general-agents.md)

## 快速启动

### 方式一：使用预设团队配置

根据常见任务场景，选择合适的预设团队：

**场景1：技术架构决策会议**
```
推荐团队：
- 指挥的：主持人、项目经理
- 挑毛病的：技术架构师、DevOps工程师、评审员
- 干活的：前端工程师、后端工程师

调用方式："请用技术决策团队评估[某技术方案]"
实时沟通：你会看到主持人引导讨论，各智能体发言、辩论、形成共识的全过程
```

**场景2：OPC系统构建**
```
推荐团队：
- 指挥的：战略分析智能体（战略）、产品架构智能体（设计）
- 干活的：自动化工程智能体（实现）
- 挑毛病的：评审员（评估）

调用方式："请用OPC团队构建[某领域]的系统"
实时沟通：你会看到三步流程中的每个环节，各智能体的输出和反馈
```

**场景3：产品定价策略会议**
```
推荐团队：
- 指挥的：主持人、产品经理
- 挑毛病的：市场分析师、财务顾问、评审员
- 干活的：销售总监（市场执行）

调用方式："请用产品团队制定[某产品]的定价策略"
实时沟通：你会看到市场分析、成本核算、定价讨论的全过程
```

**场景4：完整项目执行**
```
推荐团队：
- 指挥的：项目经理、战略分析智能体
- 挑毛病的：技术架构师、市场分析师、财务顾问、评审员
- 干活的：自动化工程智能体、前端工程师、后端工程师

调用方式："请执行[某项目]的完整流程"
实时沟通：你会看到从需求分析到技术实现的全过程，所有智能体的沟通和协作
```

详见：[references/collaboration-templates.md](references/collaboration-templates.md)

### 方式二：自定义团队组合

根据具体任务，手动选择需要的智能体，就像组建一个真实的项目团队：

1. **查看可用智能体**：使用 [references/agent-registry.md](references/agent-registry.md) 浏览所有智能体
2. **选择智能体**：根据任务需求选择智能体
   - 指挥的：选择1-2个管理型智能体
   - 挑毛病的：选择1-3个评审型智能体
   - 干活的：选择1-3个执行型智能体
3. **定义协作流程**：明确智能体之间的协作顺序和方式
4. **执行任务**：智能体按协作流程协同完成任务
5. **实时观察**：查看智能体之间的实时沟通过程

### 方式三：实时沟通模式

启用实时沟通模式，完整展示智能体之间的讨论过程：

```
【实时沟通模式】

> 主持人：各位，我们今天讨论的主题是"评估微服务架构的可行性"。请技术架构师先从技术角度发表观点。

> 技术架构师：从架构角度看，微服务架构可以提升系统的可扩展性和可维护性。但是也存在一些问题，比如分布式事务处理、服务间通信复杂度增加。我的建议是先评估业务是否真的需要这种架构。

> DevOps工程师：从运维角度，我担心的是部署复杂度和运维成本。每个服务都需要独立部署和监控，管理成本会显著增加。建议采用容器化部署来降低复杂度。

> 前端工程师：从用户体验角度，微服务架构对前端影响不大。但是要注意API的接口一致性，避免不同服务返回格式不统一的问题。

> 主持人：技术架构师提到了"先评估业务需求"，能否具体说明评估标准？

> 技术架构师：评估标准包括：1）业务规模是否需要横向扩展；2）团队规模是否能支撑多个服务的开发；3）是否有足够的运维能力。

> 评审员：基于以上讨论，我评估这个方案的可行性。技术上可行，但运维成本较高。建议先在小范围试点，验证可行性后再推广。

> 主持人：经过讨论，我们达成了以下共识：1）采用微服务架构；2）先试点核心服务；3）使用容器化部署；4）小范围验证后再推广。

> 记录员：我已记录下完整的讨论过程和决策内容。
```

开启实时沟通模式，你会看到完整的讨论过程，就像在真实的会议室！

## 智能体协作流程

### 标准协作模式

**串行协作**：智能体按顺序依次处理
```
智能体A → 输出 → 智能体B → 输出 → 智能体C → 最终结果
```
适用于：OPC系统构建、分阶段决策

**并行协作**：多个智能体同时处理，然后汇总
```
智能体A ──┐
           ├→ 汇总整合 → 最终结果
智能体B ──┘
```
适用于：多角度分析、竞品对比

**循环协作**：智能体之间反复讨论和迭代
```
智能体A ⟷ 智能体B ⟷ 智能体C
        ↓
   收敛到共识
```
适用于：会议决策、方案优化

**混合协作**：结合上述多种模式
```
[智能体A、B并行] → 汇总 → 智能C → 智体D循环讨论 → 最终结果
```
适用于：复杂任务、多阶段流程

### 协作原则

1. **清晰的角色边界**：每个智能体明确自己的职责范围
2. **标准化的输出格式**：智能体之间使用统一的数据格式
3. **明确的协作协议**：定义智能体如何调用和响应
4. **反馈循环机制**：支持智能体之间相互反馈和迭代
5. **降级处理方案**：当某个智能体失败时，有备用方案
6. **共享数据库记忆**：所有智能体共享同一个数据库，确保上下文一致

## 共享数据库记忆

### 记忆机制

所有智能体共享同一个数据库记忆，就像一个真实团队的共享知识库：

**统一上下文信息**：
```json
{
  "project_context": {
    "project_name": "AI脚本生成器",
    "current_stage": "技术架构设计",
    "participants": ["技术架构师", "DevOps工程师", "前端工程师"],
    "decisions_made": [
      "采用微服务架构",
      "使用Vue 3 + FastAPI技术栈"
    ]
  }
}
```

**共享知识库**：
```json
{
  "knowledge_base": {
    "technical_standards": {
      "api_format": "RESTful",
      "database": "PostgreSQL",
      "deployment": "Docker"
    },
    "business_goals": {
      "primary_goal": "1分钟生成3个脚本",
      "secondary_goals": ["支持多平台", "降低成本"]
    }
  }
}
```

**决策历史**：
```json
{
  "decision_history": [
    {
      "timestamp": "2024-01-01T10:00:00Z",
      "decision": "采用微服务架构",
      "reason": "提升可扩展性",
      "participants": ["技术架构师", "DevOps工程师"],
      "voting": {"support": 3, "oppose": 1, "abstain": 0}
    }
  ]
}
```

### 记忆的优势

1. **上下文一致**：所有智能体看到相同的信息，不会前言不搭后语
2. **避免重复**：已讨论过的内容不需要重复讨论
3. **便于追踪**：可以查看决策历史和讨论过程
4. **支持回溯**：可以随时查看之前的知识和决策
5. **团队协同**：所有智能体像在同一个办公室工作

### 记忆访问示例

智能体可以随时访问共享记忆，确保沟通连贯：

```
> 技术架构师：基于之前的讨论（访问共享记忆），我们已经决定采用微服务架构。现在我来详细设计服务拆分方案。

> 前端工程师：我记得之前的决策（访问共享记忆）是要使用Vue 3。那我来设计前端组件结构。

> 评审员：查看决策历史（访问共享记忆），之前的技术选型是否还有优化空间？

> 主持人：基于当前的项目状态（访问共享记忆），我们正在进行技术架构设计阶段，接下来进入产品架构设计阶段。
```

## 扩展新智能体

### 添加新角色的步骤

1. **定义角色**：明确智能体的定位、职责和能力
2. **编写模板**：使用 [assets/agent-templates/](assets/agent-templates/) 中的模板
3. **注册智能体**：在 [references/agent-registry.md](references/agent-registry.md) 中添加
4. **设计协作接口**：定义与其他智能体的协作方式
5. **测试验证**：验证智能体能否正常协作

详见：[assets/agent-templates/new-agent-template.md](assets/agent-templates/new-agent-template.md)

## 资源索引

### 智能体注册表
- [references/agent-registry.md](references/agent-registry.md)
  - 所有可用智能体的完整列表
  - 智能体的分类、定位和能力描述
  - 何时读取：需要选择智能体组建团队时

### 智能体详细定义
- [references/meeting-agents.md](references/meeting-agents.md)
  - 会议决策类智能体的详细定义
  - 何时读取：需要会议决策场景时

- [references/opc-agents.md](references/opc-agents.md)
  - OPC系统构建类智能体的详细定义
  - 何时读取：需要构建OPC系统时

- [references/general-agents.md](references/general-agents.md)
  - 通用协作类智能体的详细定义
  - 何时读取：需要通用协作能力时

### 协作模板
- [references/col