306 lines
6.8 KiB
Markdown
306 lines
6.8 KiB
Markdown
# OpenClaw 多代理 Config 草案（2026-04-07）
|
||
|
||
本文件是把前面確認過的流程設計，轉成可實際落地的 OpenClaw 設定草案。
|
||
|
||
目標不是立刻套用，而是先把：
|
||
- agent 名單
|
||
- workspace 規劃
|
||
- 權限邊界
|
||
- agent-to-agent 允許圖
|
||
- session 可見性
|
||
- 模型配置
|
||
|
||
整理成一份可審、可再修的正式草案。
|
||
|
||
---
|
||
|
||
## 1. 設計原則
|
||
|
||
### 1.1 唯一入口
|
||
- Eric 總管只對 **Eve / coder 主會話** 下旨
|
||
- 不直接與下游功能型 agent 對話
|
||
|
||
### 1.2 下游只對 Eve 回報
|
||
- `prompt-optimizer`
|
||
- `reviewer`
|
||
- `research`
|
||
- `engineering`
|
||
- `ops`
|
||
|
||
以上 5 個 agent 都只接受 Eve 派工，並只向 Eve 回報。
|
||
|
||
### 1.3 不做過重 routing
|
||
第一版不做複雜朝廷式多層 routing，也不讓 Telegram 直接綁到其他 agent。
|
||
|
||
### 1.4 強調防失聯
|
||
- 任務可失敗，但不可失聯
|
||
- 任務可中斷，但不可無聲中斷
|
||
- Eve 必須是持續追蹤與回報者
|
||
|
||
---
|
||
|
||
## 2. Agent 清單草案
|
||
|
||
建議第一版 agent list：
|
||
|
||
1. `coder`（Eve 主會話）
|
||
2. `prompt-optimizer`
|
||
3. `reviewer`
|
||
4. `research`
|
||
5. `engineering`
|
||
6. `ops`
|
||
|
||
### 2.1 各 agent 定位
|
||
- `coder`：Eve，本體／總調度
|
||
- `prompt-optimizer`：整理執行版任務單
|
||
- `reviewer`：驗收與複核
|
||
- `research`：查找、比較、整理研究資訊
|
||
- `engineering`：程式、除錯、測試、技術實作
|
||
- `ops`：部署、設定、服務、容器、log、系統診斷
|
||
|
||
---
|
||
|
||
## 3. Workspace 規劃
|
||
|
||
建議在 `~/.openclaw/` 下建立獨立工作區：
|
||
|
||
- `/home/alice/.openclaw/workspace` → `coder`（Eve，沿用現有主工作區）
|
||
- `/home/alice/.openclaw/workspace-prompt-optimizer`
|
||
- `/home/alice/.openclaw/workspace-reviewer`
|
||
- `/home/alice/.openclaw/workspace-research`
|
||
- `/home/alice/.openclaw/workspace-engineering`
|
||
- `/home/alice/.openclaw/workspace-ops`
|
||
|
||
### 3.1 工作區原則
|
||
- Eve 使用主工作區
|
||
- 每個功能型 agent **必須擁有自己獨立的 workspace**
|
||
- **禁止多個 agent 共用同一個工作目錄**
|
||
- 獨立工作區的目的，是避免互相污染上下文、memory、tasks、logs 與操作痕跡
|
||
- 若需要共享規格文件，可用明確同步方式，不靠隱晦 prompt 假設
|
||
- config 草案中應盡量為每個 agent 明確寫出 `workspace`，不要依賴共享 default workspace
|
||
|
||
---
|
||
|
||
## 4. Session / Tool 邊界建議
|
||
|
||
### 4.1 `tools.sessions.visibility`
|
||
建議值：`agent` 或 `all`
|
||
|
||
#### 選項比較
|
||
- `self`：太窄，不利 Eve 跨 agent 協調
|
||
- `agent`：只看同 agent id，不夠用
|
||
- `all`：最符合 Eve 做中樞調度
|
||
|
||
### 建議
|
||
**第一版建議用 `all`**，但搭配嚴格 agent-to-agent allowlist。
|
||
原因：
|
||
- Eve 需要查其他 agent session / history / send
|
||
- 只靠 `self` 或 `agent` 不足以完成多 agent 調度
|
||
|
||
---
|
||
|
||
## 5. Agent-to-Agent 草案
|
||
|
||
### 5.1 是否啟用
|
||
建議：`enabled: true`
|
||
|
||
因為如果 Eve 要穩定派工與收件，多代理之間需要正式的 agent-to-agent 能力。
|
||
|
||
### 5.2 Allowlist 設計
|
||
第一版建議 allowlist 只放：
|
||
- `coder`
|
||
- `prompt-optimizer`
|
||
- `reviewer`
|
||
- `research`
|
||
- `engineering`
|
||
- `ops`
|
||
|
||
### 5.3 關係規則
|
||
雖然 allowlist 會包含全部 6 個 agent，但實際制度規則應限定為：
|
||
|
||
- `coder` 可派給全部其他 agent
|
||
- `prompt-optimizer` 只回 Eve，不再往下派
|
||
- `reviewer` 只回 Eve，不再往下派
|
||
- `research` 原則上只回 Eve
|
||
- `engineering` 原則上只回 Eve
|
||
- `ops` 原則上只回 Eve
|
||
|
||
### 注意
|
||
OpenClaw schema 對 `tools.agentToAgent.allow` 目前只能做「名單放行」，無法細緻表達「誰可以找誰」。
|
||
所以真正的單向制度，必須再由 prompt 規則約束。
|
||
|
||
---
|
||
|
||
## 6. 模型配置建議
|
||
|
||
### 6.1 Eve / coder
|
||
建議沿用：
|
||
- `cowbay/gpt-5.4`
|
||
|
||
理由：
|
||
- 要做總調度、驗收、判斷、整合
|
||
- 需要較穩定的理解與管理能力
|
||
|
||
### 6.2 prompt-optimizer
|
||
建議：
|
||
- `cowbay/gpt-5.4`
|
||
或較便宜但仍穩的型號
|
||
|
||
理由：
|
||
- 需要理解模糊需求與整理結構
|
||
- 若品質差，後面整條鏈都會歪
|
||
|
||
### 6.3 reviewer
|
||
建議：
|
||
- `cowbay/gpt-5.4`
|
||
|
||
理由：
|
||
- reviewer 的價值在嚴格判斷，不宜太弱
|
||
|
||
### 6.4 research / engineering / ops
|
||
可先統一：
|
||
- `cowbay/gpt-5.4`
|
||
|
||
之後再視成本與品質，分別調整。
|
||
|
||
### 第一版建議
|
||
**先全部用同一個穩定主模型，確認流程正確後再分模型。**
|
||
|
||
---
|
||
|
||
## 7. Agent 草案結構（概念）
|
||
|
||
每個 agent 至少要定義：
|
||
- `id`
|
||
- `name`
|
||
- `workspace`
|
||
- `model`
|
||
|
||
### 概念草案
|
||
|
||
```json
|
||
{
|
||
"agents": {
|
||
"defaults": {
|
||
"model": {
|
||
"primary": "cowbay/gpt-5.4"
|
||
}
|
||
},
|
||
"list": [
|
||
{
|
||
"id": "coder",
|
||
"name": "Eve"
|
||
},
|
||
{
|
||
"id": "prompt-optimizer",
|
||
"name": "Prompt Optimizer",
|
||
"workspace": "/home/alice/.openclaw/workspace-prompt-optimizer"
|
||
},
|
||
{
|
||
"id": "reviewer",
|
||
"name": "Reviewer",
|
||
"workspace": "/home/alice/.openclaw/workspace-reviewer"
|
||
},
|
||
{
|
||
"id": "research",
|
||
"name": "Research",
|
||
"workspace": "/home/alice/.openclaw/workspace-research"
|
||
},
|
||
{
|
||
"id": "engineering",
|
||
"name": "Engineering",
|
||
"workspace": "/home/alice/.openclaw/workspace-engineering"
|
||
},
|
||
{
|
||
"id": "ops",
|
||
"name": "Ops",
|
||
"workspace": "/home/alice/.openclaw/workspace-ops"
|
||
}
|
||
]
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 8. 權限與制度邊界
|
||
|
||
### 8.1 Eve 的權限定位
|
||
- 可接旨
|
||
- 可派工
|
||
- 可追蹤
|
||
- 可驗收
|
||
- 可整合回報
|
||
|
||
### 8.2 子代理共通限制
|
||
- 不直接對總管發話
|
||
- 不自行宣告正式完成
|
||
- 高風險動作未授權前不可自行執行
|
||
- 必須如實回報卡點、錯誤與風險
|
||
|
||
### 8.3 Reviewer 特別定位
|
||
- 不是對上窗口
|
||
- 不是第二個 Eve
|
||
- 是 Eve 的驗收輔助與嚴格審查者
|
||
|
||
---
|
||
|
||
## 9. 第一版最小可行配置建議
|
||
|
||
若要先求穩，不必一次裝滿全部能力。
|
||
|
||
### Phase 1
|
||
先開：
|
||
- `coder`
|
||
- `prompt-optimizer`
|
||
- `reviewer`
|
||
- `engineering`
|
||
|
||
用這組先驗證：
|
||
- 接旨
|
||
- prompt 優化
|
||
- 單線技術任務
|
||
- 驗收／退件
|
||
- 正式回報
|
||
|
||
### Phase 2
|
||
再加：
|
||
- `research`
|
||
- `ops`
|
||
|
||
驗證：
|
||
- 研究支線
|
||
- 運維支線
|
||
- 並行任務
|
||
|
||
這樣比一次全開更穩。
|
||
|
||
---
|
||
|
||
## 10. 建議下一步
|
||
|
||
下一步應做兩件事：
|
||
|
||
### A. 產出真正可套用的 config JSON patch 草案
|
||
也就是把上面概念轉成準備套用的 `config.patch` / `config.apply` 內容。
|
||
|
||
### B. 先建立各 agent 工作區與 prompt 檔案布局草案
|
||
例如：
|
||
- `SOUL.md`
|
||
- `AGENTS.md`
|
||
- 是否共用某些規格文件
|
||
|
||
---
|
||
|
||
## 11. 結論
|
||
|
||
這份 config 草案的核心不是「多加幾個 agent」，而是把制度落地成一個穩定的中樞模式：
|
||
|
||
- 總管只對 Eve 下旨
|
||
- Eve 再決定是否走 optimizer
|
||
- Eve 派給對應功能 agent
|
||
- 所有結果先回 Eve
|
||
- Eve 驗收後才正式回報
|
||
|
||
如果照這份草案走，後續實作時就不會再回到那種多層朝廷式、難控、容易失聯的狀態。
|