老實說：我寫這篇文章，是因為我已經厭倦了不斷解釋這件事，而且似乎沒有一份「資源」能好好說明 harness 到底是甚麼。
讀完這篇文章後，你應該會掌握關於 harness 是甚麼、以及它們如何運作的所有必要知識。
人類使用介面
一般來說，人類並不是靠寫程式碼來使用電腦的。我們會透過某種形式的介面，例如終端機、網站或應用程式。
理論上，人類可以為每一個想完成的任務都寫一段獨立的 Python 或 JS 程式碼。但我們不會叫他們這樣做，而是透過按鈕、快捷鍵、指令等方式，讓他們可以使用這些程式碼。
介面的例子：Chrome、Claude Code、ChatGPT App（前身為 Codex）
另外值得一提的是，人類通常……看不到背後的程式碼。人類只會看到介面。
LLM 使用 harness
預設情況下，LLM 唯一能做的就是生成文字。要讓語言模型做到更多事情，它就需要工具。現時大部分 LLM 都經過訓練，懂得使用諸如 "read_file"（用來存取你電腦上的檔案）、"edit_file"（用來修改那些檔案）、"bash"（用來執行指令）和 "search"（用來在網上尋找資料）等工具。
不過，LLM 發出的依然只是文字！它無法像人類一樣點擊按鈕。因此，我們需要一種自訂的文字格式供 LLM 使用，用來表示「你應該執行一些程式碼」。假設我們給 LLM 一個呼叫工具的格式，例如：
<read_file name="README.md">
現在 LLM 就知道可以用這種格式回應。但這仍然只是文字，本身不會產生任何作用！就像在電腦關機時敲鍵盤或移動滑鼠一樣。
必須要有東西去解讀這些回應，然後根據 LLM 的回應內容執行正確的程式碼。
要讓 LLM 真正做事，它需要：
- 能夠執行操作的工具（read_file、edit_file、bash、search 等）
- 一套透過文字呼叫這些工具的特定語法
- 一個能解析訊息、識別該語法並執行程式碼的系統
- 一種將工具的回應傳回給 LLM 的方法
- 一份可用工具清單，並附上使用方式的說明
這就是 harness。
「Claude Code 不就是 harness 嗎？」
算是吧。
Claude Code 由兩部分組成：介面和 harness。
當你在終端機執行 "claude" 時，會開啟 Claude TUI。當你在 Claude 桌面應用程式切換到 "code" 分頁時，會開啟 Claude Code GUI。這兩者都不是 harness。
在底層，Claude Code 使用 Anthropic Agent SDK 與 agent 互動。ChatGPT 也是一樣，ChatGPT／Codex 應用程式會與 Codex App Server（內建於 CLI 中）進行互動。
我明白大家為甚麼會混淆：因為 Claude Code 和 Codex 都把 harness 直接整合進自己的應用程式裡。
但你也可以把同一個 harness 整合到其他應用程式中！以下是一些例子：
- Grok Bot 使用了 Cursor 的 harness
- T3 Code 使用了 Anthropic Agents SDK 和 Codex App Server
- OpenClaw 使用了 Pi
Harness 是一個獨立的組件，幾乎從不會暴露給使用這些應用程式的人類。
誰擁有這些工具？
試着把 harness 想像成一個廚房。
廚房裡有很多不同的工具：鍋、平底鍋、刀、鍋鏟、攪拌機等等。
沒有任何一個廚房能備齊每位廚師所需的一切。
優秀的 harness 正是基於這個前提而設計，允許用戶帶入自己的工具。
要說清楚一點：大部分重要的工具都是由 harness 直接提供的。Codex 和 Claude Code 都內建了大量工具，而其他像 Pi 這樣的 harness 則精簡得多。
這裡開始變得有點複雜，讓我再畫一張圖表。
橙色方塊代表「由 Claude Code 包含的東西」（明確地說，就是 agents sdk）。
你可以加入很多自訂工具，例如 TypeScript 插件，讓你的 LLM 擁有一些檢查程式碼的工具；或者 CUA 插件，讓 agent 可以控制你的電腦。
請注意「工具層」與人類／LLM 層之間的那條線。無論是人類還是 LLM，都無法看到或觸及這些工具。我們根本無從得知它們是否存在。是 harness 把它們暴露出來，既暴露給 LLM，也暴露給介面（這正是我們能看到它們的方式）。
MCP 讓事情變得更複雜一點
MCP（Model Context Protocol）是一項標準，目的是讓 harness 更容易存取外部事物。簡單來說：工具是「在這裡執行程式碼來完成某件事」，而 MCP 則是「向其他地方發出 API 請求來完成某件事」。
工具直接提供程式碼。MCP 則讓程式碼存放在別處，但 LLM 仍然可以透過 MCP 發出請求來做事。
MCP 最常見的用途，是把資料開放給你的 LLM。想讓 ChatGPT 查看你的電郵？用 MCP。想讓 Claude 分析你網站的數據？也是用 MCP。
Chrome 擴充功能有點像工具。它們可以改變網站的運作方式，而方法是透過在你的電腦上、在 Chrome 內執行程式碼。
MCP 則更像網站。你不需要安裝任何東西，只需要知道 URL。有了 URL，你（應該）就能取得使用它所需的全部資訊 :)
把所有東西拼在一起，大概會是這樣：
……等等，T3 Code 在那裡做甚麼？讓我解釋一下。
T3 Code 會向 LLM 開放自訂功能，讓它們做到 harness 本身做不到的事。舉例來說，我們允許使用 Claude Code 的對話串在 Codex 中生成子 agent。其他工具也能做到這一點，例如 Herdr、Orca 和 Superset。
那麼，為甚麼要以 MCP 的形式開放呢？這是不是為了逃避自建 harness 而耍的小把戲？
回想一下前面這段話：
工具直接提供程式碼。MCP 則讓程式碼存放在別處，但 LLM 仍然可以透過 MCP 發出請求來做事。
T3 Code 有大量程式碼，用來實現跨 harness 子 agent 等酷炫功能。嚴格來說，我們本可以把 T3 Code 所有最酷的功能重新打造成一套插件，分別給 Claude Code、Codex、Antigravity、Pi、Cursor、Muse 使用……
又或者，我們可以把所有程式碼保留在 T3 Code 本身，只對外提供一個簡單的 MCP 伺服器供 LLM 使用 :)
回到廚房的比喻，MCP 幾乎就像是食譜。它們是完成某件事的方法，但本身並不是那件事。
T3 Code 是在向廚房提供一本食譜。它完全不會改變廚房的運作方式。如果廚師決定想看我們的食譜，太好了！他們也可以完全不理會，一切照舊。
……那麼 agent 又是甚麼？
你知道我有多自豪嗎？我一路寫到這裡，都沒有反覆提到「agent」卻又不定義它。這可不容易，哈哈。
簡單總結：當你結合 harness 和 LLM，就會產生 agent。
LLM 只會生成文字，本身不會做任何事。Harness 只是廚房，本身煮不出任何東西。LLM 加上 harness 的組合，才構成一個「agent」。
不同的「agent」往往只是不同的 harness 配置，例如自訂工具、指令、MCP 伺服器等。
T3 Code 是 harness 嗎？
不是。如果你不帶一個 harness 過來，T3 Code 就無法運作。
再次回到廚房的比喻：
- 廚師 = LLM
- 廚房 = harness
- T3 Code = 餐廳
T3 Code 是一家餐廳，讓你隨心帶任何廚房過來。我們有自己喜歡的食譜，也會把這本食譜提供給每個廚房，但除非你吩咐，否則廚師是不會翻開它的 :)
給想深入研究的人……
如果你喜歡這類由上而下、全面剖析的解說，就叫你老闆付錢買我下週推出的 Mega.dev 課程吧。我會在那裡更深入地講解以上所有內容 :)
