AI Agent Team Architecture: OGSM Framework + 3-Layer Skills + Multi-Model Routing
如何用 OGSM + 三層架構 + 多 AI 分工設計高效 Agent 團隊
What is the best architecture for AI agent teams? 結合 OGSM 目標框架、三層知識架構（CLAUDE.md / Memory / Skills）、以及按任務類型分派 AI model 的 routing 機制，就是我們實戰驗證過的答案。這套 ai agent team architecture 已經用在 19 個 agent 同時協作的 AIA 課程產出，以及 9-agent 的 Blog Writer Fleet。
大多數人用 AI 的方式像在跟實習生對話——每次都從頭教。如果你有 19 個 AI 實習生同時工作呢？沒有架構，你會花更多時間管理混亂，而不是產出成果。這篇文章分享我們從零開始設計 AI agent 團隊的完整方法論，從目標設定到多 model 分工，每一層都有實戰案例佐證。
第一層：三層架構讓設定變簡單
想像你經營一間公司，每個新進員工報到時需要什麼？
| 架構層 | 比喻 | 載入時機 | 用途 |
|---|---|---|---|
| CLAUDE.md | 員工手冊 | 每次對話自動載入 | 開發原則、Git 設定、角色定義 |
| Memory | 個人筆記本 | 每次對話自動載入 | 回饋記錄、偏好設定、專案狀態 |
| Skills | 專業工具包 | 需要時才載入 | 可重複使用的流程、參考文件、腳本 |
這就是 claude code skill architecture 的核心。員工手冊（CLAUDE.md）寫的是每個人都要遵守的規則——開發流程、溝通風格、意圖偵測表。筆記本（Memory）記的是從過去錯誤學到的教訓，像是「先理解再動手」、「美式大字 16-20px」。工具包（Skills）則是特定任務才打開的專業模組，例如 /aia-rewrite 課程重寫流程、/publish-article 文章發佈流程。
references/ 資料夾，需要時才載入，達到零 context 成本。
判斷資訊該放哪一層的快速測試：
- 每次對話都需要？ → CLAUDE.md
- 從過去錯誤學到的？ → Memory
- 其他專案也能用？ → Skill
想了解完整的三層架構設計細節，請參考我們的 Claude Code Memory & Skill Architecture 系列文章。
第二層：OGSM 讓 Agent 有目標地合作
三層架構解決了「知識怎麼存」的問題。但 19 個 agent 要怎麼對齊方向？這就是 OGSM framework ai agent planning 的價值所在。
OGSM 代表 Objective（最終目的）、Goals（階段目標）、Strategies（策略路徑）、Measures（驗證指標）。跟 OKR 不同，OGSM 是故事驅動、以受眾為中心的框架。
每一層怎麼對應到 Agent 定義
| OGSM 層 | Agent 定義中的角色 | 常見錯誤 |
|---|---|---|
| O | 整個團隊的最終目的。必須有情感、指定受眾、聚焦成果 | 太抽象（「成為最好的」） |
| G | 每個 agent 獨特貢獻的一句話目標 | 寫成任務清單 |
| S | 這個 agent 選擇的策略路徑，包含 Skill 和 Model 調用 | 用泛用方法 |
| M | 驗證 S 的資源是否真的被使用 | 只數交付物數量 |
黃金法則
每個 G 都應該讓讀者感受到目標受眾的存在。
- 錯誤的 G：「交付 5 個案例研究，每個有 3 個來源」
- 正確的 G：「建築師讀完後，能在專案會議中準確引用規範條文，不怕被糾正」
Direction Seed：派遣 Agent 的 9 欄位 briefing
當你用 Agent tool 派遣子 agent 時，它們跑在隔離的 context 中——看不到你的 CLAUDE.md、Memory、或當前對話。所以每次派遣都必須帶完整的 Direction Seed。
9 個欄位包括：課程/專案 ID、目標受眾 persona、完整 Objective、該 agent 的 G/S/M、Skill + Model 調用清單、硬限制、語氣要求、交付格式、以及至少 3 條 Anti-patterns。
Anti-patterns 為什麼重要？因為子 agent 會「善意但錯誤地」解讀 briefing。列出「不要做 X，改做 Y」的清單，就是在回答：「如果這個 agent 理解錯了，最可能怎麼錯？」
Pilot Dispatch 模式
每個 Wave 先派 1 個 agent（pilot），等結果，對照 O 做 sanity check，然後才平行派其他人。為什麼？大多數 briefing 問題是系統性的——來自設計者的假設，不是 agent 的問題。Pilot 出錯，修 briefing 只要 1 次。4 個 agent 同時出錯，要修 4 次。
完整的 OGSM agent 規格可以參考我們的 v5.2 機器人定義頁 和 v5.2-copilot 版本。
第三層：多 Model 各司其職
How to route tasks between Claude, Gemini, and Codex? 答案是按任務類型 routing，不是把一個 model 綁定給一個 agent。
這是我們跟 LangGraph、CrewAI 等框架最大的差異。他們的做法是 per-agent binding：Investigator 用 GPT-4，Writer 用 Claude。問題是 Investigator 用 GPT-4 做所有事——研究、寫筆記、格式化——即使另一個 model 更適合。
我們的 multi-model routing claude gemini codex 做法是 per-task-type routing：
| 任務類型 | 主要 Model | 為什麼 |
|---|---|---|
| research | Gemini 2.5 Pro | Google Search grounding，搜尋品質最好 |
| verify | Gemini 2.5 Flash | 網路查證快又便宜 |
| code / html-build | Codex | 結構化輸出最強 |
| writing / judgment | Claude | 創意寫作、情感弧線、中文品質 |
| seo | Gemini 2.5 Flash | Google 搜尋洞察 |
同一個 Investigator agent，研究用 Gemini，寫筆記用 Claude，格式化用 Codex。任務決定 model，不是 agent 身份決定 model。
Script-First 原則
能用腳本做的事，不要派 AI。AI 是拿來做判斷和創意的，不是跑機械化任務。
| 錯誤做法 | 正確做法 |
|---|---|
| 派 Codex 生成 HTML | 跑 md_to_blog.py |
| 派 Gemini 檢查 404 | 跑 check_links.py |
| 派 AI 驗證 schema | 跑 validate_schema.py |
我們的 scripts/ 資料夾裡有 setup_team.sh（scaffold 新團隊）、generate_permissions.py（產生權限白名單）等工具。規則很簡單：先檢查 scripts/ 有沒有現成工具，只有需要判斷力或創意時才路由給 AI model。
實戰案例
HSW-007 AIA 課程：19-Agent Fleet
我們的 HSW-007 Healthcare Door Hardware 課程 用 19 個 agent、分 3 個 Wave 產出：
- Wave 1（研究）：2 個 Investigator + 1 個 Fact Checker，用 Gemini 做 research 和 verify
- Wave 2（審查）：3 個 Persona Reviewer + 1 個 Source Reviewer + 1 個 Compliance Reviewer
- Wave 3（產出）：Writer + Copy Editor + Engineer + SEO Engineer + Bilingual Publisher
用 Background execution 平行跑，整個流程 15-20 分鐘完成，sequential 跑要 60-90 分鐘。
Blog Writer Fleet：9-Agent Fleet
Blog Writer Fleet 用 9 個 agent 寫出 3 篇文章。從 v5.1 升級到 v5.2 的改善數字：
- +30 data context：更多數據支撐論點
- +19 hooks：更多吸引讀者的鉤子
- +23 non-numeric claims：更多質性論述加強說服力
這些改善來自 OGSM 的 M（Measure）層——我們驗證的是「S 的資源有沒有被真正使用」，而不只是「交付物有沒有產出」。
與 LangGraph / CrewAI 的比較
| 面向 | LangGraph / CrewAI | 我們的架構 |
|---|---|---|
| Model 綁定 | Per-agent binding（一個 agent 綁一個 model） | Per-task-type routing（任務決定 model） |
| 目標對齊 | 各 agent 獨立定義 | OGSM 統一 Objective，每個 G 連回 O |
| 知識管理 | 自定義 | 三層架構（CLAUDE.md / Memory / Skills） |
| 成本 | 所有任務用同一個 model | 研究用 Gemini、code 用 Codex，省 40-60% |
| 派遣安全 | 無標準化 | Direction Seed 9 欄位 + Pilot Dispatch |
核心差異：我們的架構讓每個 agent 的每個子任務都用最適合的 model，而不是整個 agent 綁死一個 model。這在 agent 數量超過 10 個時，成本和品質差異會非常顯著。
FAQ
Q: What is the best architecture for AI agent teams?
A: 結合 OGSM 目標框架（確保 agent 對齊方向）、三層知識架構（管理持久化知識）、以及 per-task-type multi-model routing（每個任務用最適合的 AI），是我們實戰驗證最有效的架構。
Q: How to route tasks between Claude, Gemini, and Codex?
A: 按任務類型 routing：research 和 verify 給 Gemini（Google grounding）、code 和 html-build 給 Codex、writing 和 judgment 留給 Claude。不要把 model 綁定在 agent 上。
Q: OGSM 跟 OKR 有什麼不同？
A: OKR 是任務清單 + 檢查點。OGSM 是故事驅動、以受眾為中心的框架。每個 G 都要讓讀者感受到目標受眾的存在，不只是交付數量。
Q: claude code skill architecture tutorial 要怎麼開始？
A: 從三層架構開始：CLAUDE.md 放每次對話都需要的規則、Memory 放學習到的回饋和偏好、Skills 放可重複使用的流程和參考文件。詳細教學見 系列文章。
Q: 需要多少個 agent 才值得用這套架構？
A: 3 個以上就值得。核心價值不在 agent 數量，在於目標對齊（OGSM）和知識管理（三層架構）。即使只有 3 個 agent，沒有 Direction Seed 的派遣也會產出不一致的結果。
Q: Background execution 能省多少時間？
A: 在 12-agent 的課程重寫中，平行執行約 15-20 分鐘，sequential 跑要 60-90 分鐘。省 3-4 倍時間。
Q: Script-first 原則適用於所有任務嗎？
A: 適用於所有確定性任務。如果輸入相同、輸出也應該相同，就用腳本。只有需要判斷力、創意、或上下文推理的任務才路由給 AI model。
Q: 這套架構能用在非 Claude Code 的環境嗎？
A: OGSM 框架和 per-task-type routing 的概念是通用的。三層架構是 Claude Code 的特定實作，但同樣的分層邏輯（always-loaded / auto-loaded / on-demand）可以應用到任何 agent 框架。