在 AI 代理人邁向自主執行的浪潮中，Harness Engineering（挽具工程）已成為決定系統能否在生產環境中穩定運行的核心關鍵。 許多工程師在開發 AI Agent 時常面臨巨大困惑：為什麼換上最強的旗艦模型、改了上百版提示詞、微調了各種參數，進入真實業務場景後任務成功率依然徘徊在 70% 以下？隨著 Anthropic、OpenAI 以及 SWE-bench 開源社群對「Harness Engineering」的深入探討，軟體架構迎來了根本性的典範轉移：模型只是負責推理的大腦，而圍繞在模型外圍的狀態管理、邊界裁剪、感知校驗與故障恢復機制（Harness），才是決定系統能否達到 95% 以上高可靠度的決定性骨骼。本文將以深度懶人包形式，為你完整拆解 AI 工程的三次演進浪潮、成熟 Harness 的六層架構體系，以及頂級 AI 實驗室的真實實務應用實踐。
1. AI 工程的三次重心遷移：從 Prompt、Context 到 Harness
回顧過去兩年生成式 AI 的發展歷程，AI 工程經歷了三次極為明確的重心遷移。這是一段層層遞進的工程演化歷程，具體解決了 AI 系統在不同發展階段的核心瓶頸：
AI 工程演進三部曲：
第一階段：Prompt Engineering ──► 解決「表達問題」：模型有沒有聽懂你在說什麼？
第二階段：Context Engineering ──► 解決「資訊問題」：模型有沒有拿到足夠且正確的資訊？
第三階段：Harness Engineering ──► 解決「執行問題」：模型在真實執行中能否持續做對？
第一階段：Prompt Engineering（提示詞工程）
在大模型普及初期，大家發現同一個模型換一種說法，輸出品質天差地別。開發者開始瘋狂研究角色設定、風格約束、Few-shot 範例、思維鏈（CoT）引導與輸出格式。提示詞工程的本質在於「語言的設計」，透過塑造一個局部的機率空間，激發模型的既有知識與推理能力。
然而，提示詞工程很快就遇到了天花板。面對企業內部私有資料、即時產品配置、超長程式碼規範或多工具協同任務時，提示詞寫得再精緻，也無法憑空創造模型未曾見過的事實，更無法管理長鏈路任務的執行狀態。
第二階段：Context Engineering（上下文工程）
當系統從簡單的「聊天對話」進階到「自主 Agent」時，模型必須調用瀏覽器、執行終端指令、查詢資料庫，並在多步驟之間傳遞中間產物。系統的核心挑戰轉變為：如何在合適的時機，將正確且高相關度的資訊精準送入上下文窗口。
以檢索增強生成（RAG）與近期廣受關注的 Agent Skills 為例，成熟的上下文工程採用了「漸進式揭露」（Progressive Disclosure）原則：系統絕不在啟動時將所有工具定義與冗長說明一股腦塞入模型，因為過載的資訊會導致注意力渙散；相反地，系統只在初始階段提供輕量級的能力索引，當模型明確觸發特定意圖時，才動態載入對應的標準作業流程（SOP）、參數規範與執行腳本。
第三階段：Harness Engineering（挽具工程）
然而，即使給對了資訊，模型在真實執行中依然可能跑偏：它可能訂出完美的計畫卻在執行時產生幻覺、誤解工具的報錯返回，或在長達十幾步的操作後逐漸偏離初始目標。
提示詞與上下文工程主要優化的是「輸入側」的意圖表達與資訊供給；而 Harness Engineering 聚焦的則是「執行側」的駕馭、監督、約束與自我修復。
通俗比喻：派新人進行重要客戶拜訪
- Prompt Engineering ──► 把話講清楚：交代見面先寒暄、再介紹方案、確認下一步需求。
- Context Engineering ──► 把資料備齊：提供客戶背景、過往會議紀錄、產品報價與競品分析。
- Harness Engineering ──► 帶 Checklist 檢查清單、關鍵節點即時回報、會後核對錄音、發現偏差立即糾正、依明確標準驗收成果。
業界公認的架構公式為：
$$\text{Autonomous Agent} = \text{Reasoning Model (大腦)} + \text{Agent Harness (控制面與身體)}$$
在一個企業級 Agent 系統中，除了模型本身以外，所有負責支撐任務穩定交付的軟體工程外殼，統稱為 Harness。
2. 社群論戰焦點：為什麼展示影片中完美的 AI Agent 一上線就報廢？
在 Reddit 的 r/LocalLLaMA、r/AI_Agents 與 Hacker News 上，關於「為什麼展示影片中完美的 AI Agent 一上線就報廢」的討論始終居高不下。社群工程師與技術先鋒的討論揭示了三個關鍵痛點：
痛點一：自然語言不是安全防護欄
許多團隊試圖在系統提示詞中寫入「嚴禁刪除資料庫」、「如果失敗請重試三次」等規則。然而在長上下文推理時，模型對自然語言的遵循度會隨著對話輪次增加而顯著衰減。社群直言：「試圖用提示詞防止 Agent 破壞系統，就像試圖用禮貌的請求防止 SQL 注入一樣脆弱。」唯有在 Harness 層進行代碼層面的權限隔離與沙盒限制，才能提供確定性保證。
痛點二：上下文焦慮與注意力稀釋
當 Agent 連續執行超過十步時，工具的原始返回日誌會迅速佔滿上下文窗口。未經 Harness 裁剪的系統會讓模型在充斥著報錯與無關數據的歷史中迷航，陷入重複呼叫無效工具的死循環。
痛點三：自評失真（Self-Evaluation Distortion）
讓同一個模型既當「執行者」又當「評審員」，往往會出現嚴重的過度樂觀現象。模型會下意識地為自己的瑕疵產出背書，認為任務已完美達成。生產級架構必須在 Harness 層將「生產」與「驗收」嚴格物理隔離。
| 比較維度 | 提示詞中心架構（Prompt-Dominant） | 挽具工程架構（Harness-First） | 生產環境穩定性衝擊 |
|---|---|---|---|
| 控制機制 | 自然語言系統提示詞與少樣本示範 | 確定性狀態機、代碼沙盒與權限閘道 | 徹底杜絕越權操作與指令漂移 |
| 錯誤處理 | 依賴模型自行察覺錯誤並重試 | 外部感知器攔截異常並組裝修復提示 | 任務成功率從 70% 提升至 95% 以上 |
| 狀態管理 | 將全部歷史日誌堆疊進上下文窗口 | 模組化狀態機、KV 儲存與動態剪枝 | 大幅降低 Token 消耗並杜絕注意力渙散 |
| 評估機制 | 模型自我審查或主觀人工抽檢 | 獨立 Evaluator、AST 解析與自動化單元測試 | 具備客觀可重複驗證與回歸測試能力 |
3. 成熟 Harness Engineering 的六層架構體系
一個具備高韌性的企業級 Agent Harness，由六個相互緊密協同的架構層級組成：
┌─────────────────────────────────────────┐
│ 第一層：資訊邊界與裁剪 │
│ (Role Definition & Context Budgeting) │
└────────────────────┬────────────────────┘
│
┌────────────────────▼────────────────────┐
│ 第二層：工具調用與 I/O 閘門 │
│ (Tool Overload Protection & Sandboxing)│
└────────────────────┬────────────────────┘
│
┌────────────────────▼────────────────────┐
│ 第三層：執行編排與軌道控制 │
│ (FSM/DAG Orchestration & Review Rails) │
└────────────────────┬────────────────────┘
│
┌────────────────────▼────────────────────┐
│ 第四層：記憶與多級狀態管理 │
│ (Task State, Artifacts & User Profiles) │
└────────────────────┬────────────────────┘
│
┌────────────────────▼────────────────────┐
│ 第五層：評估、觀測與環境驗證 │
│ (Sensors, Evaluators & Telemetry Logs) │
└────────────────────┬────────────────────┘
│
┌────────────────────▼────────────────────┐
│ 第六層：約束、校驗、失敗與恢復 │
│ (Hard Gates, Circuit Breakers & Rollback)│
└─────────────────────────────────────────┘
第一層：資訊邊界與裁剪（Information Boundary & Pruning）
確保模型在正確且純淨的資訊邊界內思考。包含嚴格的角色目標定義、依據 Token 預算進行的上下文動態裁剪，以及將「固定系統規則」、「當前任務目標」、「運行時狀態」與「外部檢索證據」進行結構化分層隔離，防止不同資料互相污染。
第二層：工具系統（Tool Invocation & Sandboxing）
解決工具過載（Tool Overload）問題。Harness 根據當前狀態動態提供最小可用工具清單，並對所有工具輸入進行嚴格的 Schema 驗證；對工具返回的原始資料進行提煉與過濾，僅將高價值摘要重新注入模型。
第三層：執行編排（Execution Orchestration）
為 Agent 建立清晰的有限狀態機（FSM）或有向無環圖（DAG）執行軌道：理解目標 $\rightarrow$ 評估資訊充分度 $\rightarrow$ 補充檢索 $\rightarrow$ 生成產物 $\rightarrow$ 觸發驗證 $\rightarrow$ 修正重試。
第四層：記憶與狀態管理（Memory & State Scaffolding）
嚴格區分三類狀態生命週期： 1. 當前子任務狀態：僅在單步推理生命週期記憶體活。 2. 對話中間產物：以結構化 Key-Value 或檔案快照形式保存在外部儲存。 3. 長期記憶與偏好：沈澱為跨任務的向量知識與持久化規則庫。
第五層：評估與觀測（Evaluation & Observability）
擺脫「生成即結束」的盲目模式。包含產物客觀驗收標準、自動化單元測試套件、即時 Token/延遲日誌監控與失敗歸因分析，確保系統具備執行能力，同時能確知自己是否做對。
第六層：約束、校驗、失敗與恢復（Constraints & Fault Recovery）
真實環境中，網路超時、格式錯誤與工具報錯是常態。Harness 必須配置硬性權限清單、輸出前與輸出後的多階段校驗閘門，以及具備自動重試、降級切換路徑與狀態回滾（Rollback）的熔斷機制。
4. 頂級 AI 實驗室的真實實踐：Anthropic 與 OpenAI 的工程化解法
在探索長程自主任務的過程中，一線 AI 實驗室總結出了極具啟發性的工程範式：
Anthropic 的兩大核心解法
- 解決「上下文焦慮」（Context Anxiety）$\rightarrow$ Context Refresh（上下文移交／實例重啟）： 當 Agent 執行複雜長程任務時，隨著上下文視窗逐漸填滿，模型會出現注意力衰減、遺忘初期細節，甚至急於結束任務草率收尾的現象。Anthropic 的做法並非無止境地壓縮歷史，而是採取類似操作系統實例重啟的 Context Refresh 機制：將目前已確認的關鍵狀態、中間產物與下一步待辦事項提煉為結構化清單，直接交接給一個全新的、乾淨的 Agent 實例繼續執行，從根本上消除上下文疲勞。
- 解決「自評失真」$\rightarrow$ 生產與驗收分離（Planner-Generator-Evaluator）： Anthropic 在內部構建自主編程與瀏覽器操作系統時，嚴格將「產出模型」與「評估模型」分開。Evaluator 甚至配備了真實的無頭瀏覽器環境，像獨立 QA 工程師一樣親自點擊頁面、檢查 DOM 結構、截圖分析渲染效果，確保交付品質符合客觀標準。
OpenAI 的工程師職責典範轉移
在 OpenAI 的實踐中，軟體工程師的角色正經歷深刻轉型：工程師不再逐行撰寫業務邏輯代碼，而是轉向擔任「運行環境設計師」（Environment Designer）： - 任務解構：將複雜業務目標拆解為 Agent 能精準理解並依序執行的子任務圖譜。 - 缺失能力補位：當 Agent 在特定步驟失敗時，工程師的核心工作在於定位出「當前環境缺少了什麼工具、腳本或規範」，並將其補足。 - 文檔索引化架構：放棄將數千行的龐大規範直接丟給 Agent，而是將其拆解為模組化的目錄索引，引導 Agent 按需動態讀取相關技術規格。 - 獨立沙盒自驗證：建立隔離的端到端測試沙盒，賦予 Agent 自行讀取編譯日誌、截圖並自動修正代碼的能力。 - 規範固化為攔截規則：將資深架構師的審查標準固化為靜態分析器（Linter）與正則過濾器，並在攔截錯誤時直接輸出結構化的修復建議路徑。
5. 開發者實戰懶人包：Harness Engineering 七大架構鐵律
對於正在構建自定義 AI 代理人的架構師與工程師，以下是開源社群實務總結出的七大黃金鐵律：
- 鐵律一：永遠不要用自然語言實作安全防護。所有涉及檔案刪除、資料庫修改與外部支付的操作，必須以代碼層面的許可清單（Allowlist）進行硬性隔離。
- 鐵律二：全面採用結構化 Schema 輸出。強制要求模型透過 JSON Schema 或 Pydantic 定義輸出，並在 Harness 層配置自動格式驗證與修復重試邏輯。
- 鐵律三：以客觀二元斷言取代主觀評判。優先使用編譯器回傳碼、單元測試通過率、正則表達式等確定性工具作為驗收標準。
- 鐵律四：設計明確的逆向回退路徑。在編排圖中構建雙向反饋通道，賦予審查模組將瑕疵產出退回上游節點重做的權力。
- 鐵律五：嚴格執行上下文預算硬上限。單一步驟歷史對話不超過窗口的 30%，保留足夠空間給推理思考（Reasoning Tokens）與精確工具返回。
- 鐵律六：設置自動熔斷機制（Circuit Breakers）。當 Agent 在同一子任務連續失敗三次時，強制中斷執行並呼叫人工介入，防止陷入死循環耗盡 Token 預算。
- 鐵律七：錯誤修正必須沈澱為持久化規則。當人工介入糾正了 Agent 的錯誤時，應將錯誤特徵與解決方案寫入長期規則庫，實現系統能力的持續複利。
6. 常見問題（FAQ）
Q1：Harness Engineering 與 LangChain 或 AutoGen 這類框架有何不同？
LangChain 或 AutoGen 主要提供基礎的 API 連接器與組件封裝；而 Harness Engineering 是一種全面的系統架構方法論，強調控制面、確定性防護網、客觀評估感知器與狀態機工程。你可以使用 LangGraph 作為底層編排庫來實作一套 Harness，但 Harness 本身的核心在於代碼優先的邊界防護與自我修復體系。
Q2：為什麼單純升級到更強大的模型（如 GPT-5 或 Claude Opus）無法取代 Harness？
更強大的模型提升的是單步推理與代碼生成的深度，但依然無法解決網路超時重試、狀態回滾、外部工具權限隔離與不可逆操作的人類授權等系統工程問題。大腦再聰明，若缺乏完善的神經系統與肌肉骨骼保護，在複雜現實環境中依然會遭遇意外。
Q3：如何在現有 Agent 專案中快速導入 Harness 架構？
建議從最關鍵的三個模組著手：第一，為所有工具調用加入輸入驗證與唯讀沙盒；第二，在執行後引入靜態語法檢查或單元測試作為反饋感知器；第三，加入單次任務花費上限與三次重試失敗的自動熔斷機制。
Q4：什麼是 Context Refresh（上下文移交），它如何解決長任務失敗問題？
Context Refresh 是 Anthropic 等頂尖團隊用來解決長程任務「上下文焦慮」的技術。當任務鏈路過長時，系統不繼續在膨脹的歷史對話中追加資訊，而是將當前關鍵狀態、中間產物與待辦清單提煉出來，交接給一個全新的 Agent 實例繼續執行，從根本上避免了模型注意力衰減與遺忘細節的問題。
權威引用
- Anthropic — Building Effective Agents and Deterministic Workflows
- Martin Fowler — Software Architecture Patterns for Autonomous AI Systems
- SWE-bench — Benchmarking Large Language Models on Software Engineering Tasks
- OpenAI — Agents SDK and Evaluation Harness Frameworks
- LangChain — LangGraph: Building Controllable Multi-Agent Systems
Author Insight
回顧軟體工程的發展史，決定一項新技術能否從實驗室原型走向商業化應用的關鍵，從來都在於上層的控制、容錯與防護架構，而非單純仰賴底層運算單元的爆發。大語言模型賦予了系統強大的推理靈活性，但商業生產環境需要的是絕對的確定性與可靠度。將研發重心從玄學般的「提示詞微調」轉向工程化的「Harness 挽具設計」，是每一位 AI 架構師從玩具邁向生產級系統的必經之路。
我們團隊持續協助跨國企業與科技先鋒設計高可靠度的 AI Agent 架構、自動化 Harness 控制層與企業級代碼沙盒。如果你正在評估自主代理人系統的實務部署架構，歡迎與 Tenten 團隊預約諮詢。
