Files
reporting-governance-plugin/docs/plans/2026-04-07-openclaw-config-draft.md

6.8 KiB
Raw Blame History

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. coderEve 主會話)
  2. prompt-optimizer
  3. reviewer
  4. research
  5. engineering
  6. ops

2.1 各 agent 定位

  • coderEve本體總調度
  • prompt-optimizer:整理執行版任務單
  • reviewer:驗收與複核
  • research:查找、比較、整理研究資訊
  • engineering:程式、除錯、測試、技術實作
  • ops部署、設定、服務、容器、log、系統診斷

3. Workspace 規劃

建議在 ~/.openclaw/ 下建立獨立工作區:

  • /home/alice/.openclaw/workspacecoderEve沿用現有主工作區
  • /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

建議值:agentall

選項比較

  • self:太窄,不利 Eve 跨 agent 協調
  • agent:只看同 agent id不夠用
  • all:最符合 Eve 做中樞調度

建議

第一版建議用 all,但搭配嚴格 agent-to-agent allowlist。 原因:

  • Eve 需要查其他 agent session / history / send
  • 只靠 selfagent 不足以完成多 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

概念草案

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

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