多智慧體團隊協作 Skill

---
name: agent-team
description: 統一管理多智慧體角色的團隊協作框架，支援智慧體動態組合、靈活協作和擴充套件新角色。智慧體本質上是"角色定義"，可以根據任務需求靈活組建團隊，實現從會議決策到系統構建的完整能力。智慧體角色明確分工：有幹活的、有指揮的、有挑毛病的，能實時看到溝透過程，共享資料庫記憶，確保上下文一致。
---

# 智慧體團隊協作框架

## 任務目標
- 本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/collaboration-templates.md](references/collaboration-templates.md)
  - 常見場景的預設團隊配置
  - 協作流程設計模板
  - 何時讀取：需要快速啟動協作場景時

### 智慧體模板
- [assets/agent-templates/new-agent-template.md](assets/agent-templates/new-agent-template.md)
  - 新增新智慧體的標準模板
  - 何時使用：需要擴充套件新的智慧體角色時

## 操作步驟

### 標準流程

1. **任務分析**
   - 明確任務目標和約束條件
   - 識別任務所需的專業領域和視角
   - 評估任務的複雜度和階段劃分

2. **團隊組建**
   - 查閱 [references/agent-registry.md](references/agent-registry.md)
   - 選擇合適的智慧體角色（3-6個為宜）
   - 或使用預設團隊配置

3. **協作設計**
   - 定義智慧體之間的協作模式（序列/並行/迴圈/混合）
   - 設計協作流程和輸出格式
   - 確定共識收斂方式

4. **任務執行**
   - 智慧體按協作流程協同完成任務
   - 記錄中間輸出和討論過程
   - 支援迭代和調整

5. **結果輸出**
   - 彙總各智慧體的輸出
   - 生成統一的任務結果
   - 記錄協作過程和關鍵決策

### 可選分支

- **當任務簡單**：直接使用單個智慧體完成任務
- **當時間緊急**：使用預設團隊配置，快速啟動
- **當需要深入討論**：採用迴圈協作模式，多輪迭代
- **當智慧體失效**：使用降級方案，或替換為備用智慧體

## 使用範例

### 範例1：完整OPC系統構建

**任務**："我想在AI短影音領域構建一個OPC系統"

**團隊配置**：戰略分析智慧體 + 產品架構智慧體 + 自動化工程智慧體

**協作流程**：
```
1. 戰略分析智慧體
   - 分析AI短影音領域
   - 輸出：TOP3產品化機會

2. 產品架構智慧體（基於戰略分析的輸出）
   - 針對優先順序最高的機會設計產品架構
   - 輸出：模組化產品藍圖

3. 自動化工程智慧體（基於產品架構的輸出）
   - 實現核心模組
   - 輸出：可執行程式碼和部署指南
```

**最終交付**：完整的技術方案和MVP程式碼

### 範例2：技術架構決策會議

**任務**："評估是否採用微服務架構"

**團隊配置**：技術架構師 + DevOps工程師 + 前端工程師 + 後端工程師 + CTO

**協作流程**：
```
1. 開場發言：各智慧體從各自專業角度陳述觀點
2. 自由討論：智慧體相互質疑、補充、辯論
3. 深入辯論：針對爭議焦點展開針對性討論
4. 共識收斂：總結各方觀點，探索折中方案
5. 決策生成：綜合各方意見形成決策結論
```

**最終交付**：包含技術論辯、成本分析、風險評估的完整會議記錄

### 範例3：混合協作場景

**任務**："評估AI短影音腳本生成系統的可行性"

**團隊配置**：戰略分析智慧體 + 技術架構師 + 產品經理 + 市場分析師

**協作流程**：
```
1. 並行分析（戰略分析智慧體 + 市場分析師）
   - 戰略分析：識別市場機會
   - 市場分析：競品和使用者需求

2. 彙總輸入（產品經理）
   - 整合市場分析結果
   - 定義產品需求

3. 技術評估（技術架構師）
   - 評估技術可行性
   - 輸出技術方案

4. 迴圈討論（所有智慧體）
   - 技術架構師質疑市場需求的合理性
   - 產品經理補充產品細節
   - 市場分析師回饋使用者預期
   - 收斂到共識
```

**最終交付**：包含市場分析、產品設計、技術方案的完整可行性報告

## 注意事項

- **智慧體數量適中**：3-6個智慧體為宜，過多會導致協作複雜
- **角色邊界清晰**：每個智慧體明確自己的職責，避免職責重疊
- **輸出格式統一**：智慧體之間使用統一的資料格式，便於資訊傳遞
- **支援降級處理**：當某個智慧體失效時，有備用方案保證任務繼續
- **迭代最佳化**：根據協作效果，不斷最佳化智慧體定義和協作流程
- **充分利用智慧體能力**：智慧體具備分析、創作、推理能力，無需為簡單任務編寫腳本

## 適用場景

**最適合**：
- 需要多專業領域協作的複雜任務
- 需要多角度分析和決策的場景
- 需要系統化構建OPC場景
- 需要靈活組建團隊應對不同任務

**不太適合**：
- 簡單單一智慧體可完成的任務
- 需要實時互動和即時響應的場景
- 完全依賴人工判斷的非結構化任務