# 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 驗收後才正式回報

如果照這份草案走，後續實作時就不會再回到那種多層朝廷式、難控、容易失聯的狀態。