# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Matt Abrams (@zuchka_) · 平台：X (Twitter) · 日期：2026-04-10

> 原始來源：https://x.com/zuchka_/status/2042666023405699113

## 中文摘要

# 什麼是 Agent Harness？我該如何選擇最適合的？

原始模型（Raw model）本質上是一個無狀態的文字預測器。它接收文字、產生文字，隨後便會遺忘一切。選擇正確的模型已耗費了工程界巨大的注意力。GPT-4 與 Claude 的對決、基準測試、API 成本、延遲……

但模型選擇一直以來都是較簡單的問題。更困難的問題在於如何封裝模型：這就是所謂的 **harness**。

Anthropic、LangChain、OpenAI 和 Salesforce 目前都在向這個術語靠攏。這種趨勢值得關注。框架時代（LangChain、CrewAI、AutoGPT）確立了如何建構 Agent。而 harness 時代的重點在於如何讓它們在真實團隊中可靠地、大規模地運作。

本文將定義什麼是 Agent harness，它與框架（frameworks）和執行環境（runtimes）有何不同，它的功能為何，以及當您是為了生產環境而非僅僅為了展示（demo）進行開發時，該如何思考 harness 的設計。

> Builder.io 是專為團隊打造的視覺化 Agent harness。它使用與 Claude Code 和 Codex 相同的模型——超過 20 個 Agent 並行運作，並配備了整個團隊都能使用的視覺化介面，而不僅僅是編寫編排程式碼的工程師。如果您想直接進入實作階段，請免費試用 Builder.io。

## 什麼是 Agent harness？

Agent harness 是指所有封裝 AI 模型並將其轉化為可運作 Agent 的程式碼、配置和執行邏輯。模型提供智慧，而 harness 提供狀態管理、工具執行、記憶、編排以及可強制執行的約束。原始模型是一個無狀態的文字預測器，而 harness 則是讓它成為 Agent 的關鍵。

LangChain 的 Vivek Trivedy 給出了一個定義：Agent = 模型 + Harness。其推論同樣簡潔：如果你不是模型，那你就是 harness。系統提示詞（System prompts）、工具架構（tool schemas）、檔案系統存取、維持對話進行的 while 迴圈，這一切都是 harness 的一部分。

即使是最基礎的聊天機器人也證明了這一點。當你將模型放入一個迴圈中以追蹤先前的訊息並附加新的使用者輸入時，你就已經建構了一個原始的 harness。while 迴圈負責維護狀態，因為模型本身無法維護狀態。這就是 harness 工程，即使以前沒人這樣稱呼它。

具體來說，harness 包含：

- 系統提示詞：在任何使用者訊息到達之前，塑造行為的常駐指令。
- 工具與 MCP：模型用於採取行動的架構、描述和執行邏輯。
- 捆綁基礎設施：檔案系統、瀏覽器、bash、沙盒。
- 編排邏輯：子 Agent 產生（subagent spawning）、模型路由、Agent 間的交接。
- 掛鉤（Hooks）與中間件：壓縮觸發器、確認閘道、確定性強制執行。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775856284302-iaHFj7BESbQAAm3ZOjpg.jpg)

模型在不同的 Agent 部署中是常數，而 harness 則是變數。這就是為什麼同一個模型在一個 harness 下可以在基準測試中排名前 5，而在另一個 harness 下卻跌出前 30 名的原因。

## 框架 vs. 執行環境 vs. harness：有什麼區別？

框架（如 LangChain）提供了建構 Agent 的抽象層。執行環境（如 LangGraph）管理執行狀態和持久化的任務流程。而 harness 則是具備特定觀點、功能完備的層級，它將上述兩者與針對特定使用情境量身打造的領域配置、約束和基礎設施結合在一起。用 Node.js 的類比可以清楚說明：Node 是執行環境，Express 是框架，而 Next.js 則是 harness。

Claude Code 是一個 harness。Codex 是一個 harness。Cursor 也是一個 harness。如果你每天都在使用這些工具，那麼你已經在別人的 harness 設計中運作了。每個工具底層都執行 Claude 或 GPT-4，但 harness 決定了 Agent 能做什麼、它對你的專案了解多少，以及它在長達數小時的任務中表現如何。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775856284295-iaHFj7OVEakAExnNIjpg.jpg)

Terminal Bench 2.0 的結果具體說明了這一點：僅僅更換 harness，就讓模型從 30 名開外躍升至前 5 名。模型權重沒有改變，改變的是 harness。

## Agent harness 實際上做什麼？

harness 提供了原始模型所缺乏的六項基礎能力：持久化儲存（檔案系統和 git）、程式碼執行（bash 和沙盒）、記憶與上下文注入、編排邏輯（子 Agent 產生與交接）、上下文管理（壓縮與工具卸載），以及用於強制執行確定性行為的掛鉤。這些功能將模型的智慧轉化為可靠的自主行動。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775856284173-iaHFj7UYlakAAQXPBjpg.jpg)

## 用於持久化儲存的檔案系統與 git

模型只能在它們的 context window 內的資料上運作。檔案系統解決了這個問題。Agent 獲得了一個工作區來讀取資料、程式碼和文件。工作內容可以被逐步添加和卸載，而不是全部保留在上下文中。中間輸出結果可以在會話之間持久保存。

Git 將檔案系統擴展為協作介面。多個 Agent 和人類透過共享檔案進行協調。當一個 Agent 將任務交接給另一個 Agent 時，是透過檔案系統，而不是共享的 context window。這就是 Agent 團隊架構在實踐中的運作方式。請參閱 Builder.io 如何實作 Claude Agent Teams 以獲取具體範例。

## Bash 與程式碼執行

預先配置的工具涵蓋了 harness 設計者預期的情況。而 Bash 則涵蓋了其他所有情況。當模型能夠編寫並執行程式碼時，它就能即時設計自己的工具，而不是被限制在固定的工具集中。

這就是 harness 層級上的 Agent 工作流：Agent 接收任務，識別出缺失的能力，編寫腳本來填補空白，執行它，然後繼續工作。harness 決定了該執行是在本地、Docker 容器中，還是在雲端沙盒中進行。

## 用於安全執行的沙盒

在本地執行 Agent 產生的程式碼存在安全風險。單一的本地環境無法擴展以應對並行的 Agent 工作負載。沙盒解決了這兩個問題：隔離的執行環境，具有允許清單（allow-listed）指令、預先安裝的工具、用於驗證輸出的瀏覽器存取權，以及用於自我檢查的測試執行器。

harness 配置了沙盒的預設值。模型不會自行配置其執行環境。

## 用於連續性的記憶與搜尋

像 AGENTS.md 這樣的記憶檔案會在 Agent 啟動時注入到上下文中。隨著 Agent 更新此檔案，harness 會載入更新後的版本。這是一種持久化的記憶，其壽命超過了任何單一的 context window。

網路搜尋和 MCP 工具（如 Context7）解決了知識截止日期（knowledge cutoffs）的問題。harness 處理檢索。模型請求資訊，而 harness 負責獲取。

## 對抗上下文衰退（Context Rot）的上下文管理

上下文衰退描述了當 context window 被填滿時，模型效能如何下降。壓縮（Compaction）是 harness 層級的回應：在接近限制時智慧地卸載上下文，而不是讓 API 報錯或默默丟棄訊息。

工具呼叫卸載（Tool call offloading）可以防止大量的工具輸出淹沒 context window。harness 可以在工具結果到達模型之前對其進行總結、截斷或快取。技能和漸進式揭露（progressive disclosure）讓 harness 僅注入與當前任務相關的上下文。

## 編排與掛鉤

從社群建構生產級 Agent 的經驗中，從業人員在 harness 層級需要的七種行為：

1. 工具輸出協定：一個輸出，多種渲染方式。相同的工具結果在 UI 和模型上下文中格式不同。
2. 對話狀態：可查詢的視圖，涵蓋失敗次數、已嘗試過的內容以及迴圈檢測。
3. 系統提醒：三個層級（系統訊息中的種子、附加到使用者訊息、綁定到特定工具）。
4. 停止條件：與對話狀態整合，而非孤立的標記。
5. 工具強制執行：排序規則、確認閘道、速率限制、自動操作。
6. 注入佇列：用於上下文注入的優先級、批次處理和去重。
7. 掛鉤：在每個階段自定義執行過程。

框架將這七點全部留給你處理。而 harness 正是這些決策所在的地方。

## 為什麼僅有 Agentic AI 框架是不夠的？

Agentic AI 框架提供了建構模組：工具抽象、記憶介面和編排模式。它們刻意將控制權留給你。諸如「這個 Agent 何時應該停止？」、「我該如何強制執行工具順序？」以及「我該如何防止在長達數小時的任務中出現上下文衰退？」等問題，都是 harness 層級的決策，而非框架的預設行為。

框架是有意不預設立場（unopinionated）的。LangChain 為你提供了 ReAct 迴圈和工具呼叫。它不會決定當你的 Agent 連續失敗三次時該怎麼辦，也不會決定在 60 步任務的第 47 步時，當 context window 已經滿了 90% 時該如何處理。

生產環境中的失敗模式通常是 harness 的失敗：

- 存在 `maxSteps` 但與對話狀態脫節。Agent 陷入迴圈，因為 harness 沒有與實際行為掛鉤的停止條件。
- 在複雜任務進行 30 分鐘後出現上下文衰退。框架並未導致此問題，但 harness 未能預防它。
- 大檔案讀取淹沒了 context window。框架正確執行了工具，但 harness 未能過濾輸出。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775856284064-iaHFj7f37akAAxOAVjpg.jpg)

2025-2026 年的變化在於，harness 開始與從第一天起就在迴圈中訓練的模型一同發布。Claude Code、Codex 和 Cursor 都是與它們所執行的模型一同訓練的 harness。這些產品實作的 Agent 設計模式並非事後才補上的，它們是 harness 設計的一部分。

模型是常數，harness 是變數。

## 如何建構或選擇 Agent harness

建構生產級 harness 意味著圍繞六個決策進行設計：Agent 在哪裡執行、它能存取哪些工具、它如何在會話之間管理狀態、它如何處理跨越 context window 的長週期任務、它使用什麼驗證迴圈，以及團隊中誰可以觀察並介入。這六點全都是 harness 層級的選擇。

1. **執行環境**：本地執行快速且便宜。Docker 提供了隔離性，且沒有雲端開銷。雲端沙盒可擴展至並行工作負載，並具備每個 Agent 的隔離性。選擇決定了你的安全態勢和擴展上限。
2. **工具表面積**：從一個小型、經過充分測試的工具集開始，然後將 bash 作為通用的逃生艙（escape hatch）。每個預先配置的工具都是你需要維護的表面。帶有程式碼執行的 Bash 涵蓋了長尾需求。
3. **狀態與記憶策略**：檔案系統是 Agent 擁有的最持久的狀態儲存。將其作為單一事實來源（source of truth）。使用 AGENTS.md 進行持久化記憶。使用 Git 進行版本控制和回滾。如果兩個 Agent 需要協調，它們透過檔案進行協調。
4. **長週期連續性**：在長達數小時的任務上工作的 Agent 將會遇到上下文限制。Ralph Loop（由 Geoffrey Huntley 提出）是一種模式，Agent 將每個任務視為一個重複的迴圈：在每次會話開始時編寫一個規劃檔案，執行一個任務，解決任何失敗，並在上下文重置之前更新檔案。跨上下文重置的 AI Agent 編排需要明確的 harness 設計。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1775856284055-iaHFj7pHIakAAnzsVjpg.jpg)

5. **驗證迴圈**：執行自己的測試套件、檢查日誌並觀察瀏覽器狀態的 Agent，在交接給人類之前能捕捉到更多錯誤。harness 決定了何時暫停以供人類審查，以及何時自主進行。
6. **團隊存取**：為單一開發者設計的 harness 是個人級的。面向團隊的 harness 需要一個協作層：誰可以觸發 Agent，誰可以看到它們在做什麼，以及誰可以介入。這就是 Agent 工具與 Agent 平台之間的區別。

## 視覺化 harness 層：Builder.io 的定位

大多數 harness 工具都是程式碼優先（code-first）的。harness 的決策（配置什麼工具、維護什麼狀態、執行什麼驗證迴圈）是由編寫編排程式碼的工程師做出的。當整個團隊需要配置、觸發和觀察 Agent 時，程式碼優先的 harness 會造成新的瓶頸。每一次 harness 的變更都必須經過那個理解程式碼的人。

Builder.io 在相同的模型和編排模式之上增加了一個視覺化、協作的層級。底層模型是 Claude、Gemini 和 GPT-4。頂層的 harness 處理本文涵蓋的決策：上下文管理、工具配置、執行環境、並行 Agent 協調和驗證迴圈。介面將這些 harness 決策暴露給整個團隊。

在實踐中，超過 20 個 Agent 並行運作，每個都在自己的雲端容器中，具有瀏覽器預覽和完整的檔案系統存取權。設計師可以觀察 Agent 正在建構什麼。專案經理（PM）可以從工單（ticket）觸發 Agent。內容團隊可以在變更發布前進行審核。harness 處理編排，而視覺化層處理協作。

相同的模型，更聰明的 harness。免費試用 Builder.io，看看並行 Agent 執行與你自己建構 harness 層相比如何。

## 常見問題：AI Agent Harnesses

**問：Agent harness 和 Agent 框架是一樣的嗎？**

框架提供了建構 Agent 的抽象層：工具介面、記憶模式和鏈式原語。harness 是頂層具備特定觀點、生產就緒的層級。它使用框架的工具，但增加了針對可靠執行而量身打造的特定配置、約束和基礎設施。LangChain 是框架，而 Claude Code 是一個可能在內部使用 LangChain 的 harness。

**問：什麼是 harness 工程？**

harness 工程是設計和優化 AI Agent 系統中非模型層級的實踐。它涵蓋了工具設計、上下文管理、執行環境、記憶架構和編排邏輯。Terminal Bench 2.0 的結果顯示，這是提升 Agent 效能的主要槓桿，通常比模型選擇更具影響力。

**問：簡單的 AI 聊天機器人需要 Agent harness 嗎？**

如果你的聊天機器人維護對話歷史，那個迴圈就已經是一個原始的 harness 了。追蹤先前訊息並附加新使用者輸入的 while 迴圈就是 harness 程式碼。一旦你添加了工具、記憶或多輪推理，明確的 harness 設計就變得重要。你已經擁有了一個 harness，請有意識地設計它。

**問：哪些 Agentic AI 框架可以與 harness 配合使用？**

LangChain、LangGraph、CrewAI、AutoGPT 和 OpenAI Agents SDK 都在框架或執行環境層級運作。像 Claude Code、DeepAgents 和 Builder.io 的 Agent 平台這樣的 harness 位於頂層，並針對特定使用情境配置這些框架。harness 負責選擇並配置底層的框架。

模型包含智慧。harness 則是讓這些智慧隨著時間推移變得可靠、具備狀態且可操作的關鍵。僅僅透過更換 harness，同一個模型就能從基準測試的 30 名開外躍升至前 5 名。框架的選擇遠不如 harness 的設計重要。

如果你的團隊正在使用 AI Agent 進行開發，並且需要的不僅僅是一個個人開發者級別的 harness，Builder.io 在相同的模型和編排模式之上增加了協作、視覺化的層級。工程工作依然真實存在，你只是不需要從零開始編寫它。查看 Builder.io 的 harness 實際運作情況。

## 標籤

Agent, 產業趨勢, Harness, Anthropic, OpenAI, LangChain