昨天把 Multi-Agent 的角色拆好了。

今天開始真的讓它們接力。

任務先保持很小：

確認 devbench 的主力模型與 Ollama 端點怎麼設定，整理成一段開發筆記，保留變數、預設值、環境變數與來源。

沒有一開始就要求寫完整技術報告。

因為任務越大，出錯時越難判斷到底是哪一層出了問題：

Research 找錯資料？

Writer 交接時漏掉資訊？

Reviewer 判斷錯誤？

還是 Supervisor 流程有問題？

所以今天先拿一個可以人工核對的小題目，建立 Multi-Agent 的第一條基準線。

一、交接的是證據，不是「我覺得對」

今天的流程還是昨天那三個角色：

Research
↓
Writer
↓
Reviewer

但真正重要的是它們之間傳什麼。

Research 會使用 Day 19 留下來的唯讀 MCP Server，真的讀取專案檔案。

Supervisor 不只保存 Research 最後那段文字，還會保留實際的 Tool Observation。

也就是 Writer 拿到的不是：

Research 說：
「主力模型應該設定在 config.py」

而是：

來源檔案
+
實際讀到的內容
+
Research 整理出的重點

這個差別很重要。

如果後面 Writer 寫錯了，我們還能回頭對照原始 Evidence，而不是只能相信上一個 Agent 的摘要。

所以今天的共享資料比較接近：

Task
↓
Evidence
↓
Source
↓
Draft
↓
Review

而不是三個 Agent 互相傳一整段聊天紀錄。

二、Reviewer 也要輸出結構化結果

Writer 完成草稿後，Reviewer 同時拿到：

Evidence
Draft

再判斷兩邊是否一致。

Reviewer 的輸出不用自由文字，而是固定成：

class Review(BaseModel):
    passed: bool
    issues: list[str]

例如：

{
  "passed": false,
  "issues": [
    "草稿沒有說明 OLLAMA_HOST 的預設值",
    "模型名稱缺少來源檔案"
  ]
}

這樣 Supervisor 不需要再猜：

Reviewer 這段話到底算通過還是不通過？

可以直接根據：

review.passed

決定下一步。

不過這裡也要分清楚：

格式合法，不代表審查內容一定正確。

Pydantic 能保證：

passed 是布林值
issues 是字串陣列

但它不能保證 Reviewer 的批評真的有證據。

今天實測就剛好碰到這件事。

三、最多只讓 Writer 修改一次

如果第一次 Reviewer 沒通過，Supervisor 會把：

原本草稿
+
Reviewer issues

再交回 Writer。

Writer 根據具體問題修一次。

流程變成：

Research
↓
Writer
↓
Reviewer
↓
通過 → 完成

沒通過
↓
Writer 修訂一次
↓
Reviewer 再檢查
↓
通過 → 完成

還是失敗
↓
交回人工

不會無限重試。

因為如果寫成：

while reviewer.passed == false:
    rewrite()

只要 Reviewer 一直挑問題，GPU 就可以一直跑。

所以修訂次數一樣由 Supervisor 控制。

這跟前面的：

max_steps
tool_budget
re-plan 次數

是同一個原則。

所有可以自動重試的流程，都要有明確上限。

四、真正跑一次 Supervisor

今天的入口很短：

import asyncio
import json

from ironman.supervisor import run_supervisor


async def main() -> None:
    result = await run_supervisor()

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

    assert (
        result["status"] == "completed"
    ), "審查未通過，交回人工檢查"


if __name__ == "__main__":
    asyncio.run(main())

真正的流程都收進：

run_supervisor()

裡面。

最後結果會保留：

Research Evidence
Writer Draft
Reviewer Result
修訂次數
模型呼叫次數
整體狀態

所以不是只有最後那一段文章。

這次三個角色依序使用同一台本機 GPU。

不是：

三個模型服務同時跑

也不是：

三張 GPU 同時工作

只是流程上有三個不同角色，依序呼叫同一個模型。

所以測到的時間也是這一次實際流程的結果。

不能拿單次執行時間直接當成：

Multi-Agent 效能排行榜。

五、第一次失敗，問題竟然在 Reviewer

第一次實際執行時，Research 和 Writer 都正常完成。

結果 Reviewer 提出了一個：

原始 Evidence 根本沒有支持的批評

Writer 又照著這個錯誤意見修改。

最後第二次審查還是沒有通過。

這次沒有把：

status = failed

偷偷改成：

status = completed

原始失敗結果保留在：

outputs/day22_initial_failure.txt

接著重新看問題。

發現 Reviewer 的任務範圍太寬，開始要求和今天題目無關的效能描述。

所以後來把審查標準縮小成：

只核對這次要求的兩個設定
只接受 Evidence 能支持的問題
不額外要求無關內容

這才讓 Reviewer 的工作範圍跟 Task 對齊。

這次踩坑其實很有意思：

多一個 Reviewer，不代表多一個真相來源。

Reviewer 本身也是模型。

它一樣可能：

誤讀證據
提出不存在的要求
把自己的推論當成事實

所以 Reviewer 的輸出也需要被限制在 Evidence 上。

六、同一個模型審自己，真的有用嗎？

今天的 Research、Writer、Reviewer 使用的是同一套本機模型。

只是 Prompt、責任和工具權限不同。

所以 Reviewer 並不是完全獨立的第二意見。

它仍然可能和 Writer 有相似偏誤。

但拆角色還是有一個很實際的價值：

Writer 的任務：
把 Evidence 寫成內容

Reviewer 的任務：
找 Evidence 與 Draft 的不一致

至少兩次模型呼叫看到的是不同任務。

這會比：

寫完後自己說「我確認過了」

更容易留下可以檢查的紀錄。

但不能因為加了一個 Reviewer，就直接宣稱：

正確率提高

那還需要真正的評估資料。

七、評估先從機械條件開始

目前先做幾個最基本的檢查。

例如：

答案不能是空的
來源必須存在
流程不能越權
Reviewer 必須回傳合法格式
狀態必須真的 completed

這些都可以由程式直接檢查。

但它們只能證明：

Workflow 有正常執行

不能證明：

文章每一句都正確

真正的語意正確性，還是需要對照：

實際 Tool Observation
原始程式碼
人工標註答案
固定測試題

之後如果要認真比較不同架構，可以建立一組固定題庫：

Task
Expected Evidence
Required Fields
Forbidden Claims

然後每次都跑同樣的任務。

這樣才有辦法比較：

成功率
引用正確率
Reviewer 抓錯率
平均修訂次數
模型呼叫次數
執行時間

而不是只看某一次 Demo 有沒有成功。

八、今天建立的是 Baseline

Day 21 我們只有角色定義：

Research
Writer
Reviewer
Supervisor

今天終於真的跑成：

Task
↓
Research
↓
Evidence
↓
Writer
↓
Draft
↓
Reviewer
↓
Review
↓
最多修訂一次
↓
Completed / Human Review

而且共享狀態不是靠三個 Agent 自己聊天維持。

而是由 Supervisor 明確保存：

Evidence
Sources
Draft
Review
Revision Count
Status

這就是之後很重要的對照組。

因為明天開始會進入 OpenClaw。

到時候如果架構改成：

Gateway
Session
Workspace
Agent Routing

我們才有東西可以比較：

換了框架之後，到底是程式碼比較好管理，還是任務本身真的變得更可靠？

不是看到新 Gateway 就直接假設品質提升。

今天完成的是第一個真正跑起來的 Multi-Agent Baseline：

Research
↓
Writer
↓
Reviewer
↓
Supervisor 控制交接與停止

角色拆開之後，也更容易看到：

誰有 Tool
誰沒有 Tool
證據在哪裡
錯誤發生在哪一段
什麼時候該交回人工

接下來七天開始進入 OpenClaw。

但今天這套 Python Supervisor 不會丟掉。

它會留著當基準。

Day 23：

OpenClaw 是什麼？從單一 Agent 到本機 AI Gateway。