Harness Engineering 是什麼？從 Karpathy 舊影片被重新包裝，看懂 AI Agent 真正的工程重點

Harness Engineering 是設計 AI Agent 執行環境的方法。它把模型接上工具、工作狀態、權限與驗收機制，讓 Agent 不只會回答，還能在可控制、可驗證的條件下完成任務。

最近一則 X 貼文宣稱，Andrej Karpathy 用 2 小時講完「Agents → Loops → Graphs → Self-Improving Systems」，還把它形容成勝過多數付費 AI 工程課程的新內容。

影片是真的，講者也是 Karpathy，但包裝方式並不準確。這段約 2 小時的影片，其實是從他在 2025 年 2 月發布、全長約 3.5 小時的《Deep Dive into LLMs like ChatGPT》截取而來。原課程談的是大型語言模型如何訓練、為什麼會產生幻覺、如何使用工具，以及強化學習等主題，不是 2026 年新發布的 Graph Engineering 課程。

不過，貼文引用的長文仍碰到一個真正重要的趨勢：當 AI Agent 開始操作檔案、瀏覽器、程式碼與公司系統，可靠度不能只靠 Prompt（提示詞，也就是給模型的指令）。模型外面的執行環境，也就是 Harness，正成為 AI 產品能否落地的關鍵。

我的判斷是，Harness Engineering 值得產品與工程團隊現在就理解，但不需要一開始就做成複雜的多 Agent Graph。最實際的路線，是先讓一個 Agent 在有限工具、清楚驗收與可回復環境中完成任務，再根據真實失敗逐步加上記憶、評測與分工。

這則 X 貼文說了什麼？哪裡不精確？

這則貼文把三種不同來源混在一起：Karpathy 的舊影片、@0xwhrrari 撰寫的 Harness Engineering 長文，以及貼文作者自己的宣傳式結論。拆開後，讀者才不會把二手整理誤認為講者原話。

這不代表 Karpathy 的原課程不值得看。相反地，它仍是理解 LLM（Large Language Model，大型語言模型）很完整的入門材料。問題在於，想學 Agent 架構的人若只看這段重新上傳的影片，會以為自己正在學一套從 Loop 升級到 Graph 的新方法，實際內容卻不是如此。

Harness Engineering 是什麼？

AI Agent 是能替使用者分解任務、選擇工具並執行多個步驟的 AI 系統。LLM 負責理解與判斷，Harness 則是包在模型外面的執行層，決定它能看到什麼、可以做什麼、如何保存進度，以及怎樣才算完成。

如果把模型想成駕駛，Harness 就是車輛、儀表板、道路規則與煞車系統。只換一位更會開車的駕駛，不能解決煞車失靈、路標消失或油量無法讀取的問題。

一套可用於正式工作的 Harness，通常包含以下能力：

• 任務合約：把目標、輸入、限制與完成條件說清楚。
• 工具與權限：提供搜尋、讀檔、改檔或呼叫服務的能力，同時限制高風險操作。
• 狀態與記憶：把進度、決策與產物存到對話以外，避免換一個工作階段就失憶。
• 隔離環境：使用 Sandbox，也就是可限制影響範圍的測試空間，避免錯誤直接碰到正式資料。
• 驗證與評測：用測試、規則或人工關卡判斷結果是否真的正確。
• 追蹤與回復：記錄每一步做了什麼，失敗後能從最近的安全狀態繼續。

OpenAI 的 Harness Engineering 案例很能說明這個差別。團隊讓 Codex 產生程式碼時，初期速度慢的主因不是模型不會寫，而是工作環境缺少清楚的工具、結構與可驗證規則。後來他們把文件做成可搜尋的知識地圖，讓 Agent 能直接讀取介面、紀錄與指標，再用自動測試維持架構邊界。

這個案例的重點不是「AI 寫了多少行程式碼」，而是人類工作的重心改變了。工程師不再只交代一句任務，而是設計一個讓 Agent 看得懂、做得到，也能被驗證的工作環境。

Prompt、Context 與 Harness 有什麼差別？

這三個詞常被混在一起，但它們解決的問題不同。

Prompt 仍然重要，只是它變成整套系統中的一個元件。當 Agent 只要整理一份文件時，清楚的 Prompt 可能已經足夠；當它要連續工作 6 小時、修改數十個檔案並開啟 Pull Request（程式碼合併請求）時，只有 Prompt 就不夠了。

Agent、Loop、Graph 不是一條固定的升級路線

社群貼文常把「Agent → Loop → Graph」畫成能力階梯，好像架構越複雜就越先進。這個理解容易讓團隊在需求還沒驗證前，先投入大量時間做多 Agent 平台。

Agent 是會根據目前狀態選擇下一步的執行者。Loop 是讓它重複「判斷 → 使用工具 → 讀取結果 → 再判斷」的運作方式，直到任務完成、發生錯誤或達到次數上限。Graph 則是用節點與連線表示分支、平行工作與交接關係的編排方式。

三者不是互相取代。單一 Agent 本來就需要 Loop；多 Agent 可以畫成 Graph，但固定流程也能畫成 Graph。對只有一條清楚路徑的任務來說，普通程式流程往往更便宜、更容易維護。

Anthropic 的 Agent 設計原則也是從最簡單的可行方案開始。工作步驟固定時，用預先定義的 Workflow 比讓模型自由決定更穩定；只有當步驟無法預測、又需要模型根據現場資訊調整時，才值得提高 Agent 的自主程度。

我的立場很明確：Graph 是編排工具，不是成熟度勳章。若單一 Agent 加一組清楚工具就能完成任務，加入五個角色只會增加延遲、費用與除錯難度。

AI Agent 為什麼會「做了很多，卻沒有完成」？

長時間任務最常見的問題，不是 Agent 完全不動，而是它做出看似合理的過程，最後卻沒有留下可用結果。

Anthropic 在長時間 Agent 實驗中發現，Agent 可能一次做太多事情，直到內容空間耗盡才停下；下一個工作階段不知道前面做了什麼，只能重新猜測。另一種情況是專案只完成一部分，Agent 看到已有成果後就過早宣告完成。

這裡的「內容空間」指 Context Window，也就是模型在一次工作中能直接讀取的資訊範圍。擴大它能延後失憶，卻不能保證 Agent 正確交接，更不能代替完成條件。

Anthropic 的處理方式很樸素：先建立功能清單與進度檔，每次只推進一小段，工作結束前留下結構化紀錄，下一個工作階段先讀取紀錄並跑基本測試。這些做法沒有讓模型本身變聰明，卻讓工作可以跨越多次 Context 重整而不斷線。

真正重要的判斷是：對話紀錄不能當成唯一的系統紀錄。產品規格、完成狀態、測試結果與風險，應存成可讀、可比對、可回復的資料。

自我改善不是讓 Agent 一直重試

只要 Agent 會讀取錯誤訊息再試一次，就稱為「Self-Improving」，這個說法太寬鬆。

真正的改善至少需要四個條件。系統要先定義可衡量的成功標準，再保存每次嘗試的結果。新方法必須與舊方法比較，通過驗證後才能成為新的預設。如果沒有改善，系統要能回復，而不是把錯誤永久寫進記憶。

Anthropic 對 Agent 評測的說明特別區分「Agent 說自己完成」與「環境中真的出現正確結果」。例如訂位 Agent 回覆「已完成預約」不算成功，資料庫中真的存在預約紀錄才算。Eval 就是用來測量這類結果的評測方法。

因此，可靠的 Loop 需要明確的停止條件、重試上限、成本預算與升級處理方式。沒有外部證據的無限重試，只是把同一種錯誤放大。

產品團隊如何做最小可行的 Agent Harness？

如果目標是快速完成 MVP，不需要先做一套通用平台。先挑一個步驟不固定、但成功結果可驗證的任務，建立最小閉環即可。

1. 把需求改寫成任務合約

任務合約至少要有輸入、輸出、限制與完成條件。不要只寫「整理客戶回饋」，而要說明資料來源、分類欄位、不可更動的內容，以及什麼結果才算完成。

2. 只開放完成任務所需的工具

讀取工具與寫入工具應分開。刪除資料、付款、發布內容或傳送訊息等難以回復的操作，不應只靠模型自己判斷是否執行。先讓 Agent 提出操作，再由規則或人工批准，通常是更安全的 MVP。

3. 把工作狀態放到對話以外

保存任務清單、已完成項目、輸出檔案與失敗原因。Session 是一次工作的完整事件紀錄，應能在 Agent 或執行環境重啟後繼續使用，而不是只留下最後一句回答。

4. 先有驗收，再增加自主程度

能用程式驗證的項目，優先使用測試、資料庫查詢、格式檢查或畫面比對。涉及語氣與商業判斷時，再加入人工關卡或另一個評估角色。驗收標準若不清楚，多一個 Agent 也只是多一個不確定來源。

5. 限制每次 Loop 的成本與風險

設定最大步數、最大重試次數、時間與費用上限。Agent 遇到缺少權限、資料衝突或連續失敗時，應停止並回報，而不是為了「完成」偷偷改變目標。

6. 為每次執行留下收據

Trace 是 Agent 每一步輸入、工具呼叫、結果與錯誤的完整軌跡。產品端不一定要把全部細節顯示給使用者，但至少要留下精簡收據：做了哪些變更、使用哪些來源、通過哪些檢查，以及還有哪些限制。

這六步已足以支撐多數第一版 Agent。當真實紀錄顯示單一 Agent 的工具太多、任務確實能平行拆分，或不同專業判斷互相干擾時，再升級到多 Agent 或 Graph，維護成本會低很多。

Harness Engineering 也可能做過頭

Harness 不是越厚越好。每增加一個 Planner、Evaluator、記憶層或回復機制，都會增加模型呼叫、等待時間與維護介面。

Anthropic 在 2026 年的長時間應用開發實驗中，比較過單一 Agent 與包含規劃、生成、評估三種角色的完整 Harness。後者產出品質較好，但成本超過前者 20 倍。這只是特定模型與任務的單次實驗，不代表所有 Agent 專案都有相同倍數。隨著新模型本身更能處理長任務，原本用來補強舊模型的 Context 重整機制也可能變成負擔。

這表示 Harness 是一組對模型弱點的工程假設，不是一次建好就永遠適用的基礎設施。團隊應定期移除不再有用的層，而不是讓架構只會增加、不會縮減。

如果一個任務成功率可以用更好的單一 Prompt 從 70% 提升到 95%，就先改 Prompt。如果錯誤來自資料不可見、工具回傳模糊、權限太大或沒有驗收，再投資 Harness。先找失敗原因，才知道該升級模型、資訊還是環境。

FAQ

Harness Engineering 會取代 Prompt Engineering 嗎？

不會。Prompt 仍負責說明任務與行為，Harness 則負責工具、狀態、權限與驗證。簡單任務可能只需要 Prompt，長時間或會影響真實系統的任務才需要更完整的 Harness。

做 AI Agent 一定要使用 Graph 嗎？

不一定。Graph 適合多分支、平行執行與角色交接；如果任務只有一個主要目標，單 Agent Loop 通常更容易開發、測試與維護。

多 Agent 一定比單 Agent 準確嗎？

不一定。多 Agent 能分工，也會增加資訊交接、成本與錯誤來源。只有當工具過多、專業範圍明確分離，或任務真的可以平行處理時，才值得增加角色。

AI Agent 可以自己變得更聰明嗎？

Agent 可以根據測試結果調整下一次行動，也能把成功方法存成規則或記憶。但這不等於模型自己完成全面升級。沒有比較基準、驗證與回復機制的「自我改善」，很可能只是把偶然結果寫成新的錯誤。

非工程團隊也需要理解 Harness 嗎？

需要理解產品層級的部分。PM 不必自己實作執行框架，但要定義完成條件、可用資料、操作權限、失敗處理與使用者可見的執行紀錄。這些決定直接影響 Agent 的 UX 與商業風險。

結語：真正的升級不是從 Prompt 換成 Graph

這則 X 貼文最有價值的地方，不是它提供了一堂新的 Karpathy 課程，而是讓更多人注意到模型外面的工程問題。只是如果把舊影片、二手文章與宣傳式結論混在一起，讀者很容易學到錯誤的技術演進圖。

AI Agent 的進步不是固定沿著「Prompt → Agent → Loop → Graph」往上爬。真正的差別在於，系統能不能看見正確資訊、使用合適工具、保留工作狀態、限制危險操作，並用外部證據確認完成。

對多數團隊來說，現在最值得做的不是先畫一張華麗的多 Agent Graph，而是挑一個真實任務，做出最小可驗證閉環。當每次失敗都能變成新的測試、規則或工具改善時，Agent 才不是一次性的 Demo，而是能持續維護的產品。

資料來源

• kaori 原始 X 貼文
• rari：Harness Engineering X Article
• Andrej Karpathy：《Deep Dive into LLMs like ChatGPT》原始影片
• OpenAI：Harness engineering: leveraging Codex in an agent-first world
• OpenAI：A practical guide to building agents
• Anthropic：Building effective agents
• Anthropic：Effective harnesses for long-running agents
• Anthropic：Harness design for long-running application development
• Anthropic：Demystifying evals for AI agents
• Anthropic：Scaling Managed Agents: Decoupling the brain from the hands