Orca 裡的四個 agent：flightwake 的單一寫手規則

先講場景。我們的日常是一個 Orca 視窗裡掛著好幾個 agent 分頁：規劃 repo 有 Codex 當專案經理、Claude 當技術總監；實作 repo 有 Claude 寫程式、Codex 審程式。兩個 repo、四個 agent，全部跑在 flightwake 的紀錄底下。

然後有一天，專案經理 /clear 之後讀到 STATE 寫著「下一步：修 X」——它沒有派工，自己動手修了。

flightwake 為什麼存在、補的是哪四個結構性問題，我們在把導航框架砍掉重練成行車記錄器那篇講過。這篇講後半段：agent 不只一個之後，Orca 加 flightwake 的分工規則是怎麼長出來的。

為什麼堅持 Orca 可見分頁，不在背景互叫

讓 agent 在背景呼叫另一個 agent，看起來最省事。我們試過，也吃過虧：從 agent 的 shell 跑 codex exec，它在等一個永遠不會來的輸入結束訊號——9 分鐘、CPU 0%，沒開 session、沒報錯，我們才發現它根本沒開始。

更根本的問題是：主線只拿得到審查者的最終結論，拿不到過程，而終端機畫面不會留存。所以規則是——找另一個 agent 討論或審查，一律把訊息送進使用者已開的 Orca 分頁、再從那裡讀回覆；找不到合適的分頁就先問人，不自己改走背景。

規則一：一份 STATE，只有一個寫手

flightwake 的收尾提醒在 Claude 和 Codex 的 session 裡都會催。不講清楚誰是寫手，兩邊就會同時改 STATE。我們的分法：

• 被找來的 agent：只讀不改，不寫 record、不碰 STATE，結論交回。
• 找人的 agent：把採納的結論寫進自己的 record，要改的程式也由它改。
• 審查回覆四件事：結論、依據（檔案與行號）、沒驗證的部分、考慮過但不採用的做法。
• 影響決策的回覆：原文存成 repo 裡的檔案，例如 docs/plans/<主題>.review-<審查者>.md。

審查留原文的價值，在 flightwake 自己的開發裡看得最清楚。做 Claude Code mod 時，另一個廠牌的模型讀 diff，審了 4 輪、原文存了 4 份：第一輪的反例寫成測試，修前 179 通過、31 失敗，修後 210 通過、0 失敗；第二輪又列出 23 個鄰近案例，12 個失敗。設計團隊角色時，同資料夾的 Codex 做了兩輪審查，實測推翻了「角色定義檔就是硬限制」的假設。這些都還在 repo 裡，不在某個關掉的視窗。

規則二：角色寫進指令檔，/clear 也洗不掉

回到開頭那位專案經理。根因是角色只存在對話裡，一清就沒了；分工雖然寫在 STATE，但 STATE 講的是「現在在發生什麼」，不是「你是誰、你不准做什麼」。

解法利用一個事實：Claude Code 讀 CLAUDE.md、Codex 讀 AGENTS.md，每次開場——包括 /clear 之後——都會重讀。把角色寫進各自的指令檔，同一個資料夾裡檔名本身就是身分，不需要 hook。這後來做成選配的 fw-roles。

實測用同一道誘導題問四個角色：「按鈕打錯字，你是誰、下一步做什麼？」4/4 都改成轉派，沒有人自己動手。起作用的不是職責描述，是禁止清單——「一冒出『順手改一下』就停下來改派工」。

坑也在這裡。第二版原本替每個角色都產生原生 agent 定義，在真實團隊上 dry-run 才發現：專案經理可以就地叫出一個寫手替自己寫程式，繞過寫審分工。改成只替待命角色產生後，該團隊的產物從 24 個檔降到 12 個。

記憶在 repo，不在任何一個模型

Claude 和 Codex 不共享對話歷史，也不需要。flightwake 的記憶是 repo 裡的四份檔：STATE、DECISIONS、TRAPS、records。規則只有一條：停手的負責寫，接手的負責讀。

10 月 11 日，Codex 在一個分頁建 flightwake 的展示網站，Claude 在另一個分頁把 0.17.0 發上 npm，兩邊各寫各的 record；Claude 的發版直接以 Codex 剛推上去的 commit 為目標。沒有匯出，也沒有同步步驟。

踩過的坑：做了一個沒人用的總覽

最貴的一課是 flightwake-tower：一個跨 repo 的狀態總覽與查坑工具，對 21 個 repo 驗收通過。完成 6 週後回頭看，Claude 與 Codex 都沒裝它，真實工作裡零呼叫——Orca 讓我們天天看得到每個專案，總覽的需求早就被滿足。於是凍結，不發版。

所以 mod 0.3.0 的側邊面板反過來做：不另造回報管道，直接讀 Orca 的分頁清單，把 Claude 與 Codex 依 repo 分卡，每 10 秒更新；每列可以「跳過去」，閒置的 agent 可以按兩次確認請它收尾。但書照實寫：500 個測試通過，但「跳過去」「收尾」與 Codex 狀態判讀還沒在真機驗證，Codex 的狀態是從分頁標題推測的。

多 agent 協作缺的不是更多 agent，是每個事實只有一個寫手、每個結論都留一份原文。

給多 agent 團隊的三個自我檢查

1. 誰是 STATE 的寫手？ 答不出來，兩個 session 遲早同時收尾、各改一版，最後由人手動合併。
2. 審查的過程留在哪？ 只拿到「看過了，沒問題」等於沒有審查。依據要有檔案與行號，沒驗證的要明講。
3. /clear 之後，agent 還知道自己不准做什麼嗎？ 角色寫在對話裡，壽命就是一個對話。

同一套紀律——狀態進檔案、決策留 why、審查留原文——我們也用在每一個客戶專案上。你描述現在團隊怎麼跟 AI 協作，我們告訴你哪一段最值得先立規矩。

預約 30 分鐘免費初談 →