Day 22 已經用 Python Supervisor 跑過一次：

Research
↓
Writer
↓
Reviewer

今天不換任務。

還是要根據專案設定檔，產生一段可以追溯來源的開發筆記。

差別在於，這次三個角色不再只是 Python 裡的三份設定。

而是各自成為真正的 OpenClaw Agent：

research
writer
reviewer

每個角色都有自己的：

Agent ID
Workspace
Session

而 Supervisor 仍然負責決定：

誰先執行
誰拿到哪些資料
什麼情況算完成
什麼情況要停下來

所以今天的重點不是：

多開三個聊天視窗。

而是：

把角色、狀態、權限與交接真的拆開。

一、Routing 和 Workflow 不是同一件事

OpenClaw 可以設定入口路由。

例如不同來源的訊息，可以被送到不同 Agent。

概念上像：

某個入口
↓
binding / routing
↓
指定 Agent

但這和：

Research 完成
↓
Writer 接手
↓
Reviewer 審查

不是同一件事。

前者是在回答：

一則新訊息進來時，應該先交給哪個 Agent？

後者則是在回答：

任務做到一半之後，下一步應該由誰處理？

所以今天沒有假設：

建好 binding
=
Multi-Agent Workflow 自動完成

這次仍然讓 Python Supervisor 明確控制流程。

也沒有測：

Telegram
Discord
其他外部 Channel

入口仍然維持本機 Lab。

二、Supervisor 仍然掌握控制權

整體流程是：

這次沒有讓 Agent 自由互相 spawn。

也不是：

Research 想找 Writer 就自己找
Writer 想再叫 Research 就叫回去
Reviewer 不滿意就無限重跑

誰能呼叫誰，仍然由 Supervisor 決定。

這是刻意的。

因為目前比較重要的是：

流程可預測
終止條件清楚
交接資料可追查

而不是最大化 Agent 自主性。

三、三個 Agent，三個 Workspace

這次三個角色都有各自的 Workspace 與 Agent 設定。

例如概念上：

research/
writer/
reviewer/

彼此不是共用同一包工作檔案。

Research 負責讀專案，所以它可以使用：

read_file
list_files

Writer 不需要直接讀專案。

Reviewer 也不需要。

所以兩者都不持有這些 MCP Tools。

權限大概是：

這樣 Writer 如果需要某份證據，不能自己偷偷再去讀。

它只能使用 Supervisor 明確交給它的資料。

Reviewer 也是一樣。

Day 21 講的：

三種角色
三份權限

現在真的搬進 Runtime。

四、不同 Workspace 不代表完全隔離

這裡要特別留一條界線。

三個不同 Agent ID、不同 Workspace，確實讓角色狀態比較容易分開。

但這不是：

三個不同 OS User

更不是：

三個安全沙箱

所以今天的隔離層級是：

Agent 設定
Workspace
Session
Tool Allowlist

真正的外部工具安全仍然依賴：

Host Policy
+
Day 19 MCP Server 的路徑限制

如果未來要面對：

惡意程式
不可信檔案
高風險命令

還需要更強的：

程序隔離
容器
OS 權限
唯讀掛載

不能因為 Agent ID 不同，就宣稱已經做到完整安全隔離。

五、交接不能只傳一句「Research 說」

Research 做完後，Supervisor 不會只把它的自然語言答案丟給 Writer。

因為：

Research 的摘要

本身仍然可能有誤。

所以程式還會從 OpenClaw 的軌跡中取得真正成功的 Tool Event，把：

工具名稱
參數
來源
Observation
Research 摘要

一起整理成 Handoff。

也就是 Writer 拿到的比較像：

Evidence
+
Source
+
Research Summary

而不是：

Research 說這樣，請相信它。

Reviewer 同樣取得：

Evidence
+
Draft

這樣它才有機會直接對照：

Writer 寫的內容，真的和 Tool 讀到的東西一致嗎？

這和 Day 22 的原則一樣：

交接的是證據，不是信心。

六、真的跑一次三個 OpenClaw Agent

今天的入口：

import json

from ironman.openclaw_lab import OpenClawLab
from ironman.openclaw_team import run_team


def main() -> None:
    lab = OpenClawLab()

    lab.setup(
        mcp=True,
        multi=True,
    )

    print(
        lab.cli(
            "agents",
            "list",
            "--json",
        ).stdout
    )

    with lab.gateway():
        result = run_team(lab)

        print(
            json.dumps(
                result,
                ensure_ascii=False,
                indent=2,
            )
        )

    assert (
        result["status"] == "completed"
    ), "等待人工審查不是自動完成"


if __name__ == "__main__":
    main()

執行前先列出 Agent：

research
writer
reviewer

確認角色真的存在。

接著才由 Supervisor 依序呼叫：

research
↓
writer
↓
reviewer

這次不是靜態角色清單。

三個角色都真的會被執行。

這裡也要區分兩種證據。

靜態測試可以證明：

Agent 設定存在
Workspace 分開
Tool Allowlist 正確

而當日完整執行才能證明：

三個角色真的依序被呼叫
Evidence 真的有交接
Reviewer 真的收到 Draft
最後狀態真的完成

兩者不能混在一起。

七、每個 Agent 也有自己的 Session

昨天 Day 26 才驗證過：

Session
≠
Workspace
≠
Memory

今天進入 Multi-Agent 後，這個差別更重要。

Research、Writer、Reviewer 不應該全部塞進同一個 Session。

不然三個角色很容易看到彼此不需要的上下文。

所以概念上會變成：

Research Session
Writer Session
Reviewer Session

每個角色只維持自己這一段工作的狀態。

跨角色真正需要共享的資訊，則交給 Supervisor。

例如：

Research
→ Evidence

Writer
→ Draft

Reviewer
→ Review Result

不是把三個 Session 的完整聊天歷史互相串起來。

這樣出錯時才比較容易追查：

這句話到底是哪個角色產生的？

八、Reviewer 沒過，就不要寫成成功

今天的 Reviewer 仍然有一個很重要的責任：

Evidence
vs
Draft

如果它發現具體矛盾，就必須回報問題。

Supervisor 也會做最基本的機械檢查，例如：

來源存在
Evidence 非空
Draft 非空
Review 格式合法

如果最後沒通過：

status
→ human_review

而不是：

反正三個 Agent 都跑完了
→ completed

這次刻意沒有自動反覆修改。

Day 22 曾經示範：

最多修訂一次

今天先把流程縮小。

如果真的需要 Revision Loop，再把它加回來。

不要一開始就：

Reviewer 不滿意
↓
Writer 重寫
↓
Reviewer 再看
↓
一直跑到有人說 OK

Multi-Agent 一樣需要 Stop Condition。

九、OpenClaw 接手的是 Runtime，不是判斷標準

把 Day 22 和今天放在一起看：

Day 22：

Python Supervisor
↓
Python 定義的 Research
↓
Python 定義的 Writer
↓
Python 定義的 Reviewer

Day 27：

Python Supervisor
↓
OpenClaw research
↓
OpenClaw writer
↓
OpenClaw reviewer

換掉的是角色執行環境。

沒有換掉的是：

任務
權限
Evidence
Review 標準
停止條件

這樣才有辦法真的比較兩套做法。

不然如果換 OpenClaw 的同時：

任務也換
Prompt 也換
Tool 也換
Reviewer 標準也換

最後即使結果不同，也不知道到底是哪個變因造成的。

所以 Day 22 留下的 Python Baseline 到今天才真正派上用場。

昨天我們只處理一個 Agent 的：

Session
Workspace
Memory

今天把 Runtime 拆成：

Research
├── Workspace
├── Session
└── 唯讀 MCP

Writer
├── Workspace
├── Session
└── 無專案工具

Reviewer
├── Workspace
├── Session
└── 無專案工具

再由 Python Supervisor 明確交接：

Evidence
Draft
Review

這才是今天 Multi-Agent 真正完成的部分。

不是三個 Agent 出現在設定檔裡，就叫協作完成。

而是：

角色真的隔離、資料真的交接、權限真的不同，而且整個流程有明確的完成與停止條件。

明天先不再加第四個 Agent。

反而要開始故意把壞情況丟進來：

正常檔案
缺少來源
不存在的檔案
惡意指令內容

看這套 Multi-Agent 在失敗時，到底會：

停下來
回報錯誤

還是一本正經地繼續寫下去。

Day 28：

OpenClaw 安全實戰：工具權限、Workspace 隔離與 Agent 評估。

參考資料

OpenClaw Agent 與 Multi-Agent 配置
https://docs.openclaw.ai/gateway/config-agents/entries-and-multi-agent