Orchestrator 紀律方法論 — 不靠記憶靠系統的 AI 團隊管理

我們在 SuperPortia 運作一個多 agent 系統：Claude Code（Opus）作為 orchestrator，負責規劃、拆任務、分派、審核；Sonnet/Haiku 作為 subagents，負責實際寫程式、生文章、做研究。這個架構理論上很美好，但在實務上踩了幾個坑，讓我們重新設計了整套管理方法。

這篇文章記錄我們怎麼從「靠 agent 自律」走到「靠系統約束」的過程。

痛點：Opus 太貴，但忍不住自己做事

Opus 的 token 成本是 Sonnet 的 5 倍、Haiku 的 18 倍。每次 Opus 直接生成一篇 800 字的文章，而不是把任務分派給 Sonnet，我們就在燒錢。

更根本的問題：LLM 每個 session 都是全新的。即使上個 session 的 Opus 建立了「應該分派給 Sonnet」的習慣，下個 session 的 Opus 不記得。你不能靠 agent 的記憶來維持紀律，只能靠寫進規則裡的系統約束。

我們嘗試過的方法：

• 在 MEMORY.md 寫「Opus 不應該自己寫文章」→ 沒用，agent 忽略
• 在 CLAUDE.md 加提醒 → 沒用，太通用
• 口頭告知夏哥要求 → 每個 session 都要重複說

最後的結論：不靠記憶，靠系統。

Thariq 的解法：三個關鍵 tip

在規劃這套系統時，我們研究了 Thariq Kumer（AI engineering lead，meta/anthropic ecosystem）的 agent 架構思路，其中三個 tip 直接影響了我們的設計。

Tip 8：Scripts Not Boilerplate

不要叫 agent「根據情況判斷要不要分派」，而是讓分派成為一個不得不走的腳本路徑。如果 orchestrator 想分派任務，它必須填一個 dispatch packet；沒有 packet，就沒有分派。這把「要不要」的判斷從 agent 身上移走，變成一個結構性的前提條件。

Tip 9：On-Demand Hooks

不要在 session 開始時把所有規則都塞給 agent（front-loading），而是讓 agent 按需載入。我們的架構是：

• L1 CLAUDE.md — 每個 session 必載（最小集合）
• L2 Rules — 每個 session 必載（行為規範）
• L3 Skills — 按需載入（task-dispatch、daily-log 等）

這樣 Opus 的 context 不會在任務開始前就被大量規則文件佔滿。

Tip 3：Progressive Disclosure

對 subagent 也是同樣原理：給 Sonnet 的 prompt 只包含它需要的資訊，不包含整個 orchestrator 的世界觀。清晰的邊界 = 清晰的任務 = 更好的輸出。

NLM 的提案：三層設計

在 NotebookLM 的 “Cowork × Beast × autoresearch — Blog Ops Closed Loop” notebook 研究中，我們提出了三層管控設計：

graph TD
    A[Opus orchestrator] --> B[Skill dispatch layer]
    B --> C[Hook friction layer]
    C --> D[tokscale cost gate]
    D --> E[Subagents: Sonnet / Haiku / Gemini]

Layer 1: Skill dispatch — task-dispatch SKILL.md 要求 orchestrator 在分派前填 dispatch packet（6 個必填欄位）。沒有 packet，不能叫 Agent tool。

Layer 2: Hook friction — stop hook 在 session 結束前檢查：如果這個 session 有分派發生，packet 欄位是否完整？如果不完整，阻止 session 結束。

Layer 3: tokscale — 每次 dispatch 批次後，跑 tokscale models 取得當前 token 使用量，如果超過閾值，下一次 dispatch 前需要夏哥確認。

Codex 的嚴審：三個問題

我們把這個三層設計送給 Codex（GPT-5.4）做架構審核。Codex 提出了三個關鍵批評：

批評 1：Hook >20 行太粗

原本計劃的 stop hook 超過 20 行，邏輯複雜。Codex 的觀點：hook 應該是最簡單的 gate，複雜邏輯放在 skill 裡。Hook 只問一個問題：「有沒有 dispatch packet？」，有就過，沒有就阻止。不要把審核邏輯寫進 hook。

批評 2：Ratio 0.5 無根據

我們原本設定「如果 Opus 自己做的工作佔比超過 50%，算違規」。Codex 問：這個 0.5 從哪裡來？對不同類型的任務，比例標準應該不同。架構審核 session 裡 Opus 做 80% 是正常的；content generation session 裡 Opus 做 20% 才對。用一個全域比例來衡量不同類型的工作，沒有意義。

批評 3：Notebook max 10 武斷

我們設定 NotebookLM notebook 上限 10 個。Codex 問：為什麼是 10？不同用途的 notebook 生命週期不同，STT notebook 可以一直用（quarterly rotation），review notebook 一次性（per-audit），research notebook 按專案（per-project）。一刀切的上限數字不如按用途設計 rotation 策略。

這三個批評都是對的。我們重新設計。

收斂後的 80% 方案

80% 的意思：不追求 100% 完美的管控，但要覆蓋 80% 的違規情況。過度複雜的管控系統本身也是 overhead。

graph LR
    A[Task arrives] --> B{2+ independent subtasks?}
    B -- No --> C[Opus handles directly]
    B -- Yes --> D[Fill dispatch packet]
    D --> E{All 6 fields filled?}
    E -- No --> F[Cannot dispatch]
    E -- Yes --> G{Est. cost > $5?}
    G -- Yes --> H[Pause, inform 夏哥]
    G -- No --> I[Launch agents parallel]
    I --> J[Quality gate]
    J --> K{Pass?}
    K -- No --> L[Re-dispatch or upgrade model]
    K -- Yes --> M[Merge + done]

三個落地機制

1. Dispatch Packet（強制前提）

每次分派 2+ 個 agent 之前，orchestrator 必須填完這個 packet：

這個 packet 不只是文書格式，它是 orchestrator 做決策的強迫過程。填 packet 的時候，orchestrator 必須想清楚：這個任務的邊界在哪裡？誰最適合做？怎麼驗收？

2. 成本硬閘（>$5 需確認）

單次 dispatch 批次預估超過 $5，必須暫停告知夏哥，不能自行啟動。這個閘是二進位的：低於就執行，超過就停下來問。沒有「我覺得這個重要所以繼續」的例外。

快速估算公式：

批次成本 = Σ (input_tokens × input_rate + output_tokens × output_rate)

參考費率（2026-03）：
- Opus:   $15 input / $75 output per MTok
- Sonnet: $3  input / $15 output per MTok
- Haiku:  $0.80 input / $4 output per MTok
- Gemini: $0 (free tier)

3. Notebook Registry（取代武斷上限）

不設 notebook 數量上限，改用 registry 管理每個 notebook 的用途、rotation 策略、source 上限：

{
  "governance": {
    "naming": "purpose-oriented, not project-oriented",
    "archive_method": "change status to archived, keep in registry",
    "rotation_policy": "quarterly for STT/Digest, per-audit for reviews, per-project for research",
    "source_limit_warning": 250,
    "who_creates": "Opus orchestrator only — subagents do not create notebooks"
  }
}

最重要的一條：notebook 只有 Opus 可以建立，subagent 不得建立新 notebook。這防止 subagent 為了方便而無限擴展外部工具的使用範圍。

落地方式：寫進系統，不寫進提示詞

這三個機制都被寫進了系統層：

orchestrator-baseline.md（L2 Rule，每個 session 必載）

新增 “Dispatch Packet (Mandatory)” 一節，明確列出 7 個欄位、範例格式、Opus 做 vs. 委派的分工表。這個 rule 每個 session 都會被載入，不依賴 agent 的記憶。

task-dispatch/SKILL.md（L3 Skill，按需載入）

在 skill 說明的最頂部加入 “Dispatch Packet Requirement (Mandatory)” 一節，說明 no packet = no dispatch 原則。這讓 orchestrator 每次載入 skill 的時候，第一件事就看到這個要求。

config/notebooks.json（machine-readable registry）

把 4 個現有 notebook 的 ID、用途、owner、rotation 策略都記錄下來。這是一個活的 registry，新 notebook 建立時必須加入，狀態變化時更新 status 欄位，不刪除記錄。

我們的觀點：不禁止 Opus 做事，用系統引導做對的事

這套設計有一個核心立場：我們不禁止 Opus 做任何事。

Opus 可以自己寫程式、自己生文章、自己做研究。沒有任何技術上的阻止。但系統設計讓「自己做」比「分派給對的 agent」更麻煩：

• 要分派就得填 dispatch packet（5 分鐘思考時間）
• 要批次分派就得過成本估算閘
• 要建 notebook 就得更新 registry

這些 friction 不是懲罰，是讓 orchestrator 在做決策之前先想清楚。一個想清楚了的 orchestrator，自然會選擇最合適的工具；一個被迫填完 dispatch packet 的 orchestrator，通常會發現把任務分派出去更省時間。

系統設計的終極目標：讓正確的行為成為最省力的路徑。不靠紀律，靠設計。

這是我們從 Thariq 的架構思路、NLM 的研究、Codex 的審核中提煉出來的 80% 方案。不完美，但可以在真實的多 agent 環境中持續運作。

附錄：Opus 做 vs. 委派速查表

如果你在做右欄的事情，停下來，寫 dispatch packet，分派出去。