前篇討論了 Harness 的運作概念。今天要深入討論：當 harness 裡面不只有一個模型、不只有一個工具、不只有一個 agent 的時候，要怎麼調度（orchestrate）。

MCP：harness 的工具層

agent 怎麼跟外部溝通？

一個 agent 如果只能「回答問題」，它能做的事非常有限。真正有用的 agent 需要能讀檔、搜尋 repo、查資料庫、開 pull request、觸發 CI⋯⋯而每個任務都需要對應的工具。

問題是，若遇到一個新任務就要重新定義工具串接，整個系統會過度耦合。以專案維護的角度來說，換一個服務、換一個模型，就要改寫——想到就頭痛對吧？

關於 MCP 的詳細解說，可以參考這篇文章。

Agent 不需要知道 GitHub API 怎麼運作。它只需要知道有一個工具叫 open_pull_request，其餘的由 MCP Server 處理。

這和之前提過的 subagent boundary 是相同邏輯——讓呼叫工具的過程更有指向性。

工具的存取權限在 harness 層管理，不是模型自己決定的。一個負責 UI 設計的 agent 可以 read_file、search_repo，但不能 delete_file、不能 deploy。我們必須人為地將界線畫好。

MCP 解決了「工具怎麼接」的問題。但工具接好了，還有另一個問題沒解決：誰來決定哪個 agent 用哪個工具、在什麼時間點出手？

Orchestra

想像一個沒有 PM 的開發團隊：每個工程師都很強，但沒有人統籌。任務交疊、方向各異，最後沒人知道現在的結果算不算完成。

如果只是單純把模型堆起來就是這種感覺：

Main Agent（PM）擁有任務的完整狀態，負責分派、整合、以及決策。Specialist agent 只執行自己被分配的任務內容，不能也不應該越界。

誰來決定誰做什麼？

PM 會知道各個開發人員的專長，並把相關任務指派給對應人員，負責「判斷」。Main Agent 也是，但這邊有兩層判斷。

第一層：harness 事前定義好的規則

• UI 相關任務 →Frontend Agent
• 程式實作 →Coding Agent
• 機敏變更 →最強的 Reviewer Model
• 簡單摘要 →最便宜的模型

大部分的情況這樣就夠了。

第二層：Main Agent reasoning

當任務不明確、需要跨邊界協作、遇到衝突時，main agent 會自己分析、拆解、然後執行「判斷」。

重點來了：main agent 不是選「最會寫程式的模型」，而是選「最會判斷、規劃、解決衝突的模型」。一個只擅長寫函式的模型，不見得能判斷這份實作是否符合產品目標、安全政策、或可維護性要求。Main agent 需要的是工程 lead 的能力，不是工程師的能力。

考量因素：

• 任務類型（UI、後端、基礎設施、文件、安全）
• 風險等級（改一個 variable name vs 改 auth 邏輯）
• 成本（這件事值得呼叫最強的模型嗎？）
• 工具需求（這個 agent 需要 Figma 存取權嗎？）

實際案例

用實際使用過的定義來做說明：

// 模型職責邊界定義
Claude 負責所有視覺判斷
Codex  負責所有整合判斷

Claude does not own API wiring.
Codex does not own visual design.

## Model Roles

### Claude Sonnet 4.6 — Visual/UI Lead

Claude owns:
- Design-system port from `Demo-kit.jsx` (Angular translation — NOT a JSX import)
- Component structure, spacing, typography, tokens, iconography
- Screenshot comparison against `Demo.html`
- UI polish for Home, Profile, Settings and empty states
- Template rewrite for admin pages

Claude does not own:
- API wiring
- Auth/session logic
- Role-source discovery
- Backend behavior
- Database/schema changes
- Endpoint invention
- Route guards or canActivate logic

### Codex / GPT-5.4 — Integration/Repo Lead

Codex owns:
- Routing and app shell integration
- Existing API wiring
- Existing auth/session preservation
- Existing role/permission source preservation
- Route guard verification for audit/admin routes (PR 5)
- Debugging, test running, diff review, and PR hygiene
- Handling mismatched data shapes by stopping and asking

Codex does not own:
- Reinterpreting the visual design
- Changing the design language
- Inventing new product IA
- Replacing source-of-truth components/tokens
- Writing Angular templates​

每個 subagent 執行自己的任務之後將結果回傳 Main Agent，由 Main Agent 整合、決定下一步。上面的案例因為過程需要確認樣式和 User Flow，所以就由 User（我）作為 Main Agent 的角色。