第 9 章 · Harness 與多代理：模型外那層「執行環境」

你可能有個疑問：Claude Code、Cursor 用的模型，跟你在網頁版聊天用的是同一個模型，為什麼它們能做到「自己讀檔、改 code、跑測試」這麼多事？答案是——強的不只是模型，是模型外面那層「執行環境」，也就是 harness。 這一章講清楚 harness 是什麼，以及讓多個 agent 一起合作的「多代理」。

💡 這一章你會懂：harness 到底包了什麼、為什麼它是 agent 產品的真正競爭力、以及什麼時候該讓「一群 agent」合作。

什麼是 Harness？

**Harness（挽具／執行框架）**就是包在模型外面、讓那個「感知→推理→行動→觀察」迴圈（第 7 章）能真正跑起來的整套基礎設施。模型是引擎，harness 是引擎外的整台車。

一個成熟的 harness 通常包含：

💡 重點洞察：同樣的模型，配上好 harness 和爛 harness，能力天差地遠。所以 Claude Code 之於一般聊天，差別八成在 harness——這也是為什麼第 11 章「打造你自己的 agent」，一大半其實是在打造 harness。

用 Claude Code 當例子

Claude Code 本質上就是一個「裝了強力 harness 的 coding agent」。當你叫它「修好這個 bug」，harness 在背後做的事：

1. 驅動代理迴圈，讓模型一步步推理；
2. 提供工具：read（讀檔）、edit（改檔）、bash（跑指令）、grep（搜尋）……；
3. 權限把關：要跑會改動系統的指令前，先問你同意；
4. 沙箱隔離：在受控環境執行，降低搞砸的風險；
5. context 自動壓縮：對話太長時，自動摘要舊內容、騰出空間；
6. 需要時派**子代理（subagent）**去平行處理——這就接到下一段。

沙箱與安全：讓它「能動手」但「弄不壞」

Agent 一旦能跑指令、改檔案，風險就真實存在。沙箱（sandbox）是關鍵防線：把 agent 的執行限制在一個隔離、受控的環境（容器、虛擬機、受限帳號），這樣即使它做錯，也炸不到你的正式系統與重要資料。

配套的安全原則：最小權限（只給任務需要的權限）、危險動作要審批、記錄每個動作（出事能回溯）。

⚠️ 回顧第 4 章那條主線：模型只會「請求」動作，真正的把關永遠在 harness 這一層。你設計 harness 時，安全不是可選項。

多代理（Multi-Agent）：一群 agent 分工合作

當任務很大、或需要不同專長時，可以讓多個 agent 協作，最常見的是**主管–工人（Orchestrator–Worker）**模式（呼應第 5 章）：

flowchart TB
    O[主代理 Orchestrator<br/>拆解任務、彙整結果] --> W1[子代理 1<br/>讀前端程式碼]
    O --> W2[子代理 2<br/>讀後端程式碼]
    O --> W3[子代理 3<br/>查測試]
    W1 --> O
    W2 --> O
    W3 --> O

• 主代理負責規劃、拆解、最後彙整。
• 子代理（subagent）各自負責一塊，可以平行進行（快很多），也可以各有專長（一個擅長寫測試、一個擅長查資料）。
• 每個子代理有自己乾淨的 context，不會被彼此的雜訊干擾——這其實也是一種 context 管理技巧（第 3 章）。

但先等等：多代理不是萬靈丹

多代理很酷，但它更難除錯、更貴、更容易出協調問題。務實原則：

💡 跟第 5 章「先 workflow 再 agent」同一個哲學：先單代理，真的有需要再多代理。 複雜度是有代價的。

重點回顧

• Harness = 模型外那層執行環境：代理迴圈 + 工具 + 權限 + 沙箱 + context 管理。同樣的模型，harness 決定它有多強。
• Claude Code 的強大，八成來自 harness——第 11 章你會發現，做 agent 一大半是在做 harness。
• 沙箱 + 最小權限 + 審批 + 記錄 是 agent 能「動手卻弄不壞」的關鍵。
• 多代理（主管–工人、子代理平行）適合大型、可平行、需分工的任務。
• 原則不變：先單代理，不夠再多代理；複雜度有代價。

到這裡，agent 的「腦、手、身體」都齊了。但——你怎麼知道你做的這一切到底有沒有用、會不會出包？下一章講整門課最被忽略、卻最重要的能力：評估、可觀測性與安全。