# 策展 · X (Twitter) 🔥🔥

> 作者：TRAE (@Trae_ai) · 平台：X (Twitter) · 日期：2026-04-24

> 原始來源：https://x.com/trae_ai/status/2047145274200768969

## 中文摘要

# Harness Engineering 權威指南

> Harness Engineering 是一種更具啟發性、更直觀的方式，用來系統化地總結並命名這些現有的 AI 實踐。

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

# 1. 什麼是 Harness Engineering？

2026 年標誌著軟體工程領域一個新支柱的崛起：Harness Engineering。繼 Prompt Engineering 和 Context Engineering 之後，這個名稱由 HashiCorp 共同創辦人 Mitchell Hashimoto 提出，並在 OpenAI 的一份關鍵報告後獲得廣泛關注。

其核心在於「馬與韁繩」的隱喻。將 AI Agent 或任何複雜的軟體系統想像成一匹強大但沒有方向的「野馬」。而「Harness」代表用來約束、引導並修正其行為的韁繩，確保它能穩定且可靠地保持在正確軌道上。

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

用一個簡單的公式來表示：

> AI Agent = SOTA 模型（野馬） + Harness（控制系統） = 頂尖執行者

AI Agent 是一匹潛力無限的「野馬」，而 Harness Engineering 就是馴服它的完整系統。你並不是在改變馬的 DNA（模型本身），而是在設計讓它為你工作的專業裝備與訓練規範。

> 💬 Harness 本質上是除了 LLM 之外，所有能讓 Agent 真正產出成果的基礎設施。它談的不是「更好的 Prompt」或「能力更強的模型」，而是優化模型運作的環境與機制。這是一種旨在將原始 AI 智慧轉化為可靠、可控且可擴展生產力的工程哲學與框架。

說清楚一點：Harness Engineering 並不是什麼用來緩解你 FOMO（錯失恐懼症）的新玩具。它更像是一個 AI 工程的調度框架，旨在解決一個核心問題。

它解決的核心問題很簡單：既然 AI 已經加入了你的工作流程，我們該如何真正管理這個「超級實習生」？

# 2. 為什麼我們需要 Harness Engineering？

隨著 AI 從單純的「問答機」演變為能夠規劃並執行複雜任務的自主 Agent，工程師的角色正在經歷根本性的典範轉移。

Harness Engineering 的出現，正是為了應對這種演變所帶來的新挑戰。

## 2.1 構建更可靠的 Agent 系統

要讓 Agent 超越玩具階段，進入生產級工程領域，它們必須錨定四個核心目標：R.E.S.T 框架。

2.1.1 Reliability (可靠性)

定義

系統在面對預期或非預期的輸入、環境變動以及內部故障時，提供穩定、持續服務並完成指定任務的能力。

關鍵要求

- 故障恢復：任務中斷後能從檢查點自動恢復的能力。

- 操作冪等性：確保關鍵寫入操作可以在不破壞系統狀態的情況下安全重試。

- 行為一致性：確保在相同輸入集下，行為保持可預測。

2.1.2 Efficiency (效率)

定義

在滿足功能與可靠性需求的同時，有效利用運算、儲存與網路資源。這直接影響服務成本與可擴展性。

關鍵要求

- 資源控制：對 token 消耗、API 呼叫與運算時間進行精確的預算管理。

- 低延遲回應：在互動場景中快速提供有意義的回饋。

- 高吞吐量：在批次處理場景中，單位時間內處理更多任務的能力。

2.1.3 Security (安全性)

定義

保護系統及其資料免受未經授權的存取、使用或破壞。對於自主 Agent 而言，安全性是一條不可逾越的紅線。

關鍵要求

- 最小權限：僅授予完成特定子任務所需的最低權限。

- 沙盒執行：在嚴格隔離的沙盒環境中執行所有不受信任的程式碼或指令。

- I/O 過濾：防止 Prompt 注入、敏感資料外洩以及有害內容的生成。

2.1.4 Traceability (可追溯性)

定義

提供足夠的資料（日誌、指標與追蹤），讓開發者與營運人員能夠理解 Agent 的內部狀態、決策過程與行為歷史。

關鍵要求

- End-to-End (端到端) 追蹤：維持從初始請求到最終結果，每一步清晰可追溯的呼叫鏈。

- 可解釋的決策：確保每個關鍵決策都有明確的歸因紀錄。

- 可審計的狀態：確保系統在歷史上任何時間點的完整狀態都可以被查詢與審計。

## 2.2 Agent 優先時代的工程必要性

2.2.1 工程複雜度達到新高度

隨著 AI 能力的擴展，我們對能構建什麼的期望也隨之提高。我們已經遠遠超越了「Vibe Coding」（快速展示貪食蛇或俄羅斯方塊的複製版），轉向了嚴肅的生產級工程領域。

2.2.2 從「執行者」到「架構師」

隨著 AI 接手了編寫特定程式碼行的繁重工作，人類工程師的核心價值向上移動到了系統設計。我們不再是逐行砌磚的勞工，我們是繪製藍圖、定義規則並簽署最終輸出的架構師：這就是我們所稱的 Spec Coding。

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

這種實踐是一個強有力的概念驗證：當 AI 成為生產力的主要引擎時，傳統的工程管理模式就不再適用。透過 Prompt 指導 AI 是一種「軟約束」，這根本不足以保證品質、可靠性或可維護性。

我們需要一套「硬約束」，一個強大的工程框架來錨定 Agent 的表現。這正是 Harness Engineering 的用武之地。

Harness Engineering 的核心哲學是：當模型遇到瓶頸時，我們實施一種工程機制，確保同類型的故障永遠不會再發生。

這是一個活的系統。隨著模型持續迭代，許多基礎能力最終會被模型本身內化，從而讓某些 Harness 實踐退役。同時，隨著新的應用場景出現，它們必然會催生新的 Harness 創新。

接下來，讓我們深入了解 Harness Engineering 實際的樣子。

# 3. 解構 Harness Engineering

在現有的 Transformer 架構與自回歸 LLM 架構下，原始輸出本質上是隨機且無序的。

Harness Engineering 是一種對這些原始運算施加確定性約束的實踐，旨在實現複雜的工程工作流程。

要理解「是什麼」，我們必須看看 Agent 實際上是如何運作的。一個生產級的 Agent 運作在一個持續的四階段循環中：感知 (Perception)、規劃 (Planning)、行動 (Action) 與回饋/反思 (Feedback/Reflection)，簡稱 PPAF。

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

我們將 Agent 堆疊解構為四個核心維度，每個維度都直接對應 PPAF 循環。將這些視為「harness」——引導、約束並釋放模型真正潛力所需的結構。

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

為了映射不同 Agent 的能力邊界與工程障礙，我們使用了一個基於「認知循環」與「上下文效率」的二維矩陣。

橫軸：AI 認知循環 (AI Cognitive Loop)

- React (被動回應)：行為由單一外部觸發器驅動。Agent 執行預定義、確定性的任務，但缺乏自主規劃或反思。

- Proactive Plan & Reflect (主動規劃與反思)：Agent 追求長期目標，自主管理多步驟規劃、執行，並根據結果進行動態調整。

縱軸：上下文效率 (Context Efficiency)

- Inefficient (手動/點對點輸入)：大多數上下文由人類手動提供，或透過有限、低效率的介面提取。

- Efficient (沙盒/自動注入)：Agent 在高度整合的環境中運作，上下文透過檔案系統、API 閘道或狀態引擎等系統級介面自動擷取並注入。

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

這個矩陣揭示了 Harness Engineering 的核心價值：你的 harness 成熟度直接決定了 Agent 能否從低效率、被動的下象限，躍升至高效率、主動的上層級。

# 4. Harness 系統的架構

框架建立後，是時候從概念轉向行動了。讓我們逐層拆解如何構建一個具備韌性的 Harness 系統。

## 4.1 高階抽象：作為託管 REPL 容器的 Harness

在架構層面，Harness 本質上是一個配備了邊界控制、工具路由與確定性回饋的 REPL (Read-Eval-Print Loop) 容器。

將其想像成一個包裹著 LLM 非確定性「大腦」的確定性 Shell。它的工作是管理從感知到行動再到反思的整個生命週期，有效地將 LLM 的推理能力接入可預測的軟體工程世界。

> 💬 REPL Harness 的核心邏輯

> Read (讀取)：Harness 使用上下文管理器將外部世界（如使用者輸入或 API 狀態）與內部記憶轉化為 LLM 真正能消化的結構化 Prompt。這就是我們如何將工程嚴謹性帶入「感知」階段。

> Eval (評估)：當 LLM 生成計畫（例如 Function Call）時，呼叫攔截器會捕捉該意圖並將其路由至適當的工具執行器。每次執行都會受到嚴格監控，包括逾時、資源配額與錯誤處理。

> Print (列印)：工具的輸出（無論是成功的資料還是例外狀況）會被回饋組裝器捕捉。隨後將其重新封裝為結構化的「觀察結果」，並重新注入上下文，為 LLM 的下一輪反思與規劃提供原始素材。

> Loop (循環)：這個「讀取-評估-列印」循環會持續重複，直到 Agent 達成目標或觸發終止條件。這個循環是驅動 PPAF 過程的基本引擎。

## 4.2 底層轉換機制：橋接無限狀態與有限 token

Agent 的湧現智慧依賴於其消化大量狀態資訊的能力。然而，底層的 Transformer 架構運作在一個本質上有限且線性的 token 序列上。

因此，Harness 的一個核心挑戰是在外部世界的「無限」狀態與 LLM 的「有限」token 上下文之間，建立高效、可靠的雙向映射。

4.2.1 上下文管理：從「無限狀態」到「有限 token」

Agent 的上下文是其感知的真實來源，涵蓋了從任務目標、互動歷史到工具定義與即時狀態的所有內容。將這些海量資料流提煉到有限的 token 視窗中，是規劃品質的最終瓶頸。

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

> 💬 工程決策：縮減規則與注入邊界

> 核心上，上下文管理是一組縮減規則 (Reduction Rules)。

> Harness 必須定義明確的規則，以決定在 token 預算緊張時，哪些資訊優先保留，哪些資訊剔除。此外，注入邊界 (Injection Boundary) 至關重要。它精確規定了外部資料（如 RAG 結果）在 Prompt 中的插入位置，以最大化效能並避免「Lost in the Middle (中間遺失)」現象。

4.2.2 Function Calling：從「文字預測」到「物理執行」

Function Calling (FC) 作為 LLM 規劃與現實世界行動之間的橋樑。雖然看起來很簡單，但它涉及一個嚴謹且通常脆弱的生命週期循環：

- Schema 序列化：Harness 將可用工具及其參數 (JSON Schema) 序列化為特定的文字格式，並注入 Prompt。這是 LLM 理解其「能力邊界」的唯一方式。

- 觸發生成：透過在其龐大參數空間中的模式匹配，當 LLM 判斷計畫需要工具時，它會生成符合特定語法（包括工具名稱與參數值）的文字。

- 確定性反序列化：Harness 攔截此文字並嘗試將其反序列化為結構化請求。這是最脆弱的階段，因為 LLM 的輸出可能會違反語法規則，例如格式錯誤的 JSON 或型別不匹配。

- 觀察注入：Harness 執行呼叫並將結果（成功或失敗）封裝成「觀察結果」文字區塊，重新注入 Prompt 以閉合循環。

a) 故障表面與回退路徑

鑑於 LLM 輸出的非確定性，Function Calling 的每一步都是潛在的故障點。一個具備韌性的 Harness 必須實施強大的回退路徑：

反序列化失敗

- 重試：向 LLM 提供具體錯誤（例如「無效的 JSON 格式」）以觸發重新生成。

- 回退至文字：請求自然語言指令以供傳統解析器處理。

執行失敗

- 互動澄清：直接向使用者請求缺失的參數。

- 反思與重新規劃：將詳細的錯誤日誌注入上下文，引導 Agent 在下一輪中走向替代路徑。

b) 核心架構決策：狀態分離原則

- 你必須嚴格將 LLM 視為無狀態的運算單元（一個「CPU」）。所有需要跨輪次一致性的狀態（如使用者工作階段或任務進度）都必須卸載到由 Harness 控制的外部上下文狀態管理器或持久化引擎（記憶體/磁碟）中。

- 反模式：試圖透過 Prompt Engineering 強迫 LLM 維持複雜狀態，會導致混亂、不可預測且無法追蹤的系統行為。

4.2.3 核心約束與設計原則

構建 Harness 時，我們必須面對三個基本約束，並透過六個核心設計原則來解決它們。

三個核心約束

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

六個設計原則

1. 為故障而設計：將例外與故障視為常態，而非異常。每個組件都必須支援容錯、重試與優雅降級。

1. 合約優先：透過明確、機器可讀的合約（Schemas、API、事件）定義所有互動。這是模組化與系統演進的基礎。

1. 預設安全：安全性不是外掛功能，它應該是起點。我們遵循最小權限、零信任與縱深防禦原則。

1. 關注點分離（決策 vs. 執行）：在邏輯與物理上將「決定做什麼」（規劃）與「如何做」（執行）解耦，以提高系統靈活性。

1. 一切皆可衡量：每個行為、決策與使用的資源都必須可量化。沒有衡量，就沒有優化路徑。

1. 資料驅動演進：將每一次 Agent 執行都視為學習機會。構建資料收集、標註與回饋的閉環，是實現長期智慧成長的唯一途徑。

4.2.4 關鍵工程地標

為了驅動 REPL 循環並落實這些設計原則，Harness 需要在架構中部署幾個關鍵組件或「工程地標」。

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

Harness Engineering 只是我們編排 LLM 方式的統稱。無論是 SDK、Agent 還是自訂 plugin，使命始終如一：阻止模型犯下同樣的錯誤兩次。

這些「harness」並非靜態的。隨著模型演進，今天的外部護欄最終將直接內建於模型本身。

# 5. 實施 Harness Engineering

概念框架是一個很好的起點，但對於構建平台與基礎設施的工程師來說，Harness 必須被視為一個活的、可運作的系統。要真正理解它是如何運作的，我們需要透過四個關鍵視角來檢視：架構分層、核心機制、營運治理與資料驅動演進。

## 5.1 架構概覽：控制平面與資料平面

生產級的 Harness 通常被解耦為控制平面 (Control Plane) 與資料平面 (Data Plane)：

- 控制平面（「做什麼」）：管理高階邏輯，包括任務排程、資源配額、行為規劃與政策執行。

- 資料平面（「如何做」）：處理繁重工作，例如實際的 Agent 執行階段實例、狀態與記憶儲存，以及沙盒執行環境。

我們進一步將其抽象為四個功能層：

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

在實踐中，將 Harness 視為「智慧膠水」。它位於模型 API 閘道與你的服務之間，利用工程嚴謹性將分散的基礎設施縫合成一個有凝聚力的系統。

## 5.2 核心機制：循環、記憶與 token 管線

5.2.1 Agent 核心循環

我們將 Agent 行為抽象為持續的「觀察 → 思考 → 行動」循環：

- 觀察：感知世界的當前狀態，包括使用者輸入、工具輸出、互動歷史與任務進度。

- 思考：利用該感知來更新目標、分解任務並決定下一步行動。

- 行動：執行操作，無論是內部（更新記憶）還是外部（呼叫工具或回覆），其結果會回饋到下一次觀察中。

> 💬 工程筆記：這不是一個簡單的 while (true) 循環

> 在生產環境中，此循環必須與工作流程引擎或狀態機框架整合。它需要支援暫停/恢復功能、冪等重試以及並發事件處理，以解決長執行任務中的「上下文焦慮」。

5.2.2 分層記憶與 token 管線

為了將最大訊號塞入有限的上下文視窗，大多數 Agent 依賴外部記憶。

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

在此之上，Harness 執行一個 token 轉換管線，在每次呼叫前將多來源資訊提煉為受控的 Prompt：

1. 收集：聚合使用者請求、短期記憶與長期知識檢索。

1. 排序：根據時效性與語意相關性對資訊進行評分。

1. 壓縮：總結或結構化精煉高容量、低密度的內容。

1. 預算分配：為不同資訊類別分配 token 限制。

1. 組裝：使用結構化模板（例如明確的 [user_request] 或 [tool_output] 區塊）拼湊出最終的 Prompt。

> 💬 總結：將注意力管理卸載給工程

> 與其希望模型「自己找出」該關注什麼，不如使用 token 轉換管線主動構建上下文。將寶貴的視窗留給真正重要的資訊。

5.2.3 規劃模型與執行策略

在規劃器層面，我們通常根據任務複雜度對模式進行分類：

> 💬 建議

> 預設使用「規劃並執行 (Plan-and-Execute)」，僅在需要時才疊加重新規劃或多 Agent 編排。

> 對於大多數企業場景，結構化計畫搭配「例外觸發的重新規劃」已足夠強大。

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

5.2.4 執行階段與治理：沙盒、安全性與成本

沙盒執行框架

為了讓 Agent 在不破壞系統的情況下「完成任務」，你必須提供一個安全、隔離的執行階段。

- Level 1：處理程序級隔離：使用 chroot、Linux namespaces 或 seccomp-bpf。速度快但共享核心；最適合受信任的內部工具。

- Level 2：容器隔離：Docker 或 containerd。這是大多數工具執行成熟的工業標準選擇。

- Level 3：MicroVMs：Firecracker。提供獨立的虛擬核心，使其成為多租戶環境或執行不受信任程式碼的理想選擇。

- Level 4：完整 VM：KVM/QEMU。最高成本下的最高安全性；保留給最敏感的任務。

> 💬 策略

> 預設使用 Level 2（容器）搭配強化核心與唯讀根檔案系統。引入 Level 3（MicroVMs）作為不受信任程式碼或高敏感資料的加強版沙盒。

資源管理與韌性

控制成本並確保穩定性需要幾個關鍵的工程護欄：

- 預算與配額：為平台、租戶或個別任務設定 token、API 呼叫與 CPU 時間限制。

- 逾時控制：對所有網路請求與工具執行強制執行嚴格的逾時，防止掛起的下游服務拖垮整個 Agent。

- 重試策略：對暫時性、可恢復的錯誤使用帶有退避機制的重試，但對永久性錯誤快速失敗。

- 斷路器：如果依賴項重複失敗，則暫時跳脫電路以防止連鎖故障。

- 優雅降級：如果關鍵能力離線，自動降級至「弱但安全」的模式（例如從「可執行程式碼」轉為「唯讀建議」）。

安全性與合規性：政策閘道

除了沙盒之外，你還需要在規劃器與執行層之間設置一個政策閘道 (Policy Gateway) 來驗證每個動作：

- 權限：RBAC/ABAC 檢查以驗證 Agent 是否獲授權存取特定資源。

- 資料過濾：針對輸入參數與回傳值進行 PII 與機密檢測。

- 注入防禦：在惡意 Prompt 模式或指令拼接到達執行層之前進行識別。

- 審計日誌：記錄「誰在什麼時候做了什麼，以及結果如何」，以供事後分析與合規審計。

指標與演進：透過資料成長

最後，你需要一套強大的評估套件來確保你的 Agent 系統保持在正確軌道上：

- 任務有效性：成功率、指令遵循率與工具使用效能。

- 服務品質 (QoS)：End-to-End (端到端) 延遲、首次行動時間與整體錯誤率。

- 資源效率：平均 token 消耗與平均工具呼叫次數。

- 安全性與合規性：政策拒絕率與安全事件數量。

這些指標不僅僅是虛榮指標或儀表板填充物；它們是推動 Harness 演進的回饋循環。當成功率達到上限時，這是一個重新審視規劃器或上下文策略的訊號。如果錯誤率或成本飆升，你可能需要排查沙盒、資源配額或斷路器邏輯。

# 6. 結語

Harness Engineering 並不是什麼可以被供奉起來的「銀彈」。它是一種在現實世界中鍛造並為現實世界而建的工程哲學。

儘管業界過度關注生成式 AI 對開發者的「顛覆」與「取代」，但這種方法論作為一個紮實的提醒：工程師的角色並未消失。它正在演變。我們正從程式碼的創造者轉變為創造過程的守護者。

構建一個可靠的 Harness 最終是一場平衡混亂與秩序的練習。我們不期望 AI 完美，就像我們不期望人類不會犯錯一樣。真正的工程智慧在於構建能夠從失敗中學習並以韌性駕馭不確定性的系統。

這些「韁繩」的最終目標從來不是限制，而是為了實現更安全、更完整的潛力釋放。也許在不久的將來，模型將開始完全超越這些基礎約束。

## 標籤

Harness, 產業趨勢, 教學資源, Harness Engineering