Pure OpenClaw architecture for 15-17 agent team covering quant research, marketing, content, and engineering. Includes org structure, role definitions, collaboration patterns, scheduling, memory architecture, Discord integration, rollout plan, and JSON schemas. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
204 lines
6.1 KiB
Markdown
204 lines
6.1 KiB
Markdown
# KingClawArmy - 第四部分:協作模式
|
||
|
||
---
|
||
|
||
## 4.1 三種協作模式
|
||
|
||
| 模式 | 實現方式 | 適用場景 |
|
||
|---|---|---|
|
||
| **Orchestrator(協調者)** | Paperclip 任務系統 | 大部分日常任務 |
|
||
| **Peer-to-Peer(點對點)** | Discord Thread 討論 | 辯論、腦力激盪、跨團隊對齊 |
|
||
| **Hierarchical(階層式)** | Paperclip Org Chart | 任務分派、升級、審批 |
|
||
|
||
### 4.1.1 Orchestrator 模式(日常 80%)
|
||
|
||
```
|
||
董事長下達指令
|
||
↓
|
||
CEO/COO 拆任務 → 建立 Paperclip Issue
|
||
↓
|
||
分派給對應 agent(指定 assignee)
|
||
↓
|
||
Agent 在 heartbeat 時接到任務
|
||
↓
|
||
OpenClaw 執行任務
|
||
↓
|
||
產出 JSON → 寫回 Paperclip Issue
|
||
↓
|
||
下一個 agent 接手(或送審)
|
||
```
|
||
|
||
### 4.1.2 Peer-to-Peer 模式(討論 15%)
|
||
|
||
```
|
||
CEO 或任一 agent 發起討論
|
||
↓
|
||
建立 Discord Thread
|
||
↓
|
||
@mention 相關 agent 加入
|
||
↓
|
||
多 agent 在 thread 中來回討論(最多 10 人、2-50 輪)
|
||
↓
|
||
達成結論或主持人收斂
|
||
↓
|
||
秘書摘要 → 寫入 Mem0 + 回寫 Paperclip Issue
|
||
```
|
||
|
||
### 4.1.3 Hierarchical 模式(升級/審批 5%)
|
||
|
||
```
|
||
Agent 遇到超出權限的問題
|
||
↓
|
||
設定 Issue 狀態為 blocked + 留言說明
|
||
↓
|
||
CEO/COO 看到 → 決定:
|
||
├── 轉派給其他 agent
|
||
├── 發起討論
|
||
└── 上報董事長(HITL)
|
||
```
|
||
|
||
---
|
||
|
||
## 4.2 什麼時候走任務交接 vs 開會議
|
||
|
||
| 情境 | 用哪種 | 理由 |
|
||
|---|---|---|
|
||
| 一個 agent 做完交給下一個 | 任務交接 | 線性流程,不需要討論 |
|
||
| 需要多方觀點碰撞 | 會議 | 例如多空辯論 |
|
||
| 審查 pass/revise 來回 | 任務交接 | 非同步 review 即可 |
|
||
| 審查 revise 超過 3 輪 | 會議 | 非同步效率太低,需要面對面對齊 |
|
||
| 跨團隊依賴 | 會議 | 需要共同理解 |
|
||
| 新 campaign 啟動 | 會議 | 需要多部門對齊方向 |
|
||
| 日常 KPI 報告 | 任務交接 | 固定格式,不需討論 |
|
||
| 回測結果異常 | 會議 | 需要多方分析原因 |
|
||
|
||
---
|
||
|
||
## 4.3 預定義會議類型
|
||
|
||
### 4.3.1 量化研究辯論
|
||
|
||
| 項目 | 內容 |
|
||
|---|---|
|
||
| **會議 ID** | `meeting_quant_debate` |
|
||
| **觸發條件** | 多方/空方報告完成後,量化策略研究員覺得需要辯論 |
|
||
| **參與者** | 多方研究員、空方研究員、量化策略研究員 |
|
||
| **主持人** | 量化策略研究員 |
|
||
| **前置輸入** | Finance_Research_Brief + Market_Structure_Report + 雙方初步報告 |
|
||
| **發言規則** | LLM 動態選人,不允許連續發言 |
|
||
| **最大輪數** | 10 |
|
||
| **結束條件** | 出現 "CONSENSUS" 或達到最大輪數 |
|
||
| **輸出** | Meeting_Conclusion.json → 量化策略研究員據此產出 Quant_Strategy_Spec |
|
||
|
||
### 4.3.2 策略審查會議
|
||
|
||
| 項目 | 內容 |
|
||
|---|---|
|
||
| **會議 ID** | `meeting_strategy_review` |
|
||
| **觸發條件** | 審查員 revise 超過 3 輪,或高風險產出 |
|
||
| **參與者** | 審查員 + 被審的 agent + CEO/COO |
|
||
| **主持人** | CEO/COO |
|
||
| **前置輸入** | 被審產出 + Review_Report(含 revise 歷史) |
|
||
| **發言規則** | 輪流發言 |
|
||
| **最大輪數** | 6 |
|
||
| **結束條件** | 審查員判定 PASS 或 BLOCK |
|
||
| **輸出** | Meeting_Conclusion.json + 更新後的 Review_Report |
|
||
|
||
### 4.3.3 跨部門對齊會議
|
||
|
||
| 項目 | 內容 |
|
||
|---|---|
|
||
| **會議 ID** | `meeting_cross_team_sync` |
|
||
| **觸發條件** | CEO/COO 判斷需要跨團隊協調,或董事長要求 |
|
||
| **參與者** | CEO/COO + 相關團隊的 lead agent |
|
||
| **主持人** | CEO/COO |
|
||
| **前置輸入** | 各團隊最新產出摘要 |
|
||
| **發言規則** | LLM 動態選人 |
|
||
| **最大輪數** | 8 |
|
||
| **結束條件** | CEO/COO 宣布 "ALIGNED" |
|
||
| **輸出** | Meeting_Conclusion.json + 更新的 Task_Spec |
|
||
|
||
### 4.3.4 盤前研究會議(每日)
|
||
|
||
| 項目 | 內容 |
|
||
|---|---|
|
||
| **會議 ID** | `meeting_daily_premarket` |
|
||
| **觸發條件** | 每日定時(盤前),財經情報 + 市場結構報告完成後 |
|
||
| **參與者** | 財經情報研究員、市場結構研究員、多方研究員、空方研究員 |
|
||
| **主持人** | CEO/COO |
|
||
| **前置輸入** | 當日 Finance_Research_Brief + Market_Structure_Report |
|
||
| **發言規則** | 輪流發言 |
|
||
| **最大輪數** | 6 |
|
||
| **結束條件** | 各方表述完畢,CEO 摘要 |
|
||
| **輸出** | Meeting_Conclusion.json → 決定是否進入量化策略流程 |
|
||
|
||
---
|
||
|
||
## 4.4 會議流程標準化
|
||
|
||
所有會議遵循以下流程:
|
||
|
||
```
|
||
1. 觸發
|
||
├── 自動觸發(排程/事件)
|
||
└── 手動觸發(CEO 或董事長建立 meeting issue)
|
||
|
||
2. 準備
|
||
├── 蒐集前置資料(各參與者的最新產出)
|
||
├── 載入會議模板(參與者、規則、最大輪數)
|
||
└── 在 Discord 建立 Thread
|
||
|
||
3. 討論
|
||
├── 主持人開場(說明議題 + 目標)
|
||
├── 各 agent 依發言規則輪流發言
|
||
├── 允許追問、反駁、補充
|
||
└── 主持人在適當時機收斂
|
||
|
||
4. 結論
|
||
├── 主持人宣布結論
|
||
├── 秘書產出 Meeting_Summary
|
||
└── 結論寫入 Mem0 + Paperclip Issue
|
||
|
||
5. 後續
|
||
├── 根據結論建立後續任務
|
||
└── 分派給對應 agent
|
||
```
|
||
|
||
---
|
||
|
||
## 4.5 Review Gate(審查關卡)
|
||
|
||
### 必審節點
|
||
|
||
| 節點 | 觸發條件 | 審查者 |
|
||
|---|---|---|
|
||
| 量化策略提交 | Quant_Strategy_Spec 完成 | 審查員 |
|
||
| 回測結果提交 | Backtest_Delivery 完成 | 審查員 |
|
||
| 工程交付 | Frontend/Backend Delivery 完成 | 審查員 |
|
||
| 文案/素材對外 | Copywriting_Pack / Creative Brief 完成 | 審查員 |
|
||
| 跨部門整合完成 | Final_Decision_Packet 組裝完成 | 審查員 |
|
||
|
||
### HITL 節點(需要你親自批准)
|
||
|
||
| 節點 | 原因 |
|
||
|---|---|
|
||
| 正式環境部署前 | 高風險 |
|
||
| 資料庫 schema 變更前 | 高風險 |
|
||
| 廣告正式發布前 | 涉及預算與品牌 |
|
||
| 對外正式訊息發送前 | 涉及品牌與客戶 |
|
||
| 涉及金流操作前 | 高風險 |
|
||
| 量化策略正式自動執行前 | 高風險 |
|
||
| 月預算超額 | 成本控制 |
|
||
|
||
HITL 流程:
|
||
```
|
||
Agent 完成任務 → 審查員 pass → 系統偵測到 HITL 節點
|
||
↓
|
||
Discord #approvals 發送通知
|
||
↓
|
||
你看到通知 → /clip approve <id> 或 /clip reject <id>
|
||
↓
|
||
approve → 繼續執行
|
||
reject → 退回修改,附上你的意見
|
||
```
|