Harness Engineering：駕馭AI的框架工程

作者/陳冠豪


【內容摘要】 當企業 AI 應用從單一動作的 Agent Skills，走向跨部門、多系統與長時間運行的複雜流程時，開發團隊將面臨狀態中斷、資源衝突與系統失控的嚴峻挑戰。本文深入剖析 AI 應用開發的第三階段核心——「Harness Engineering（駕馭工程）」。透過 Agent = Model + Harness 的架構思維，詳解如何建立持久化的任務狀態管理、獨立於模型外的工具權限隔離、多 Agent 協作的資源鎖定（Resource Locking）機制，以及防範無限迴圈與 Prompt Injection 的系統級護欄。駕馭工程的核心不在於期待 AI 永遠不犯錯，而是打造一套高可靠性的基礎設施，確保 AI 在犯錯或異常發生時，風險依然被嚴格控制在企業可承受的邊界之內。 【TAG 關鍵字】#Harness_Engineering #駕馭工程 #AI_Agent #狀態管理 #多Agent協作 #工具執行控制 #權限隔離 #系統防護 #非紅供應鏈 #企業AI架構

作者簡介

作者目前擔任凌羣電腦資通技術處經理，現專職AI解決方案規劃與領導AI專案開發，並規劃凌羣AI開發團隊之研究方向。

從Agent Skills到Harness Engineering：企業AI開發的下一道難題

在前面兩期專欄中，我們探討了AI Agent的崛起：第8篇(九月號第347期【AI Agent：從「對話」進化到「行動」】）談到透過CLI與MCP賦予AI執行的能力，讓它能操作系統；第9篇(十月號第348期【讓 AI 照著 SOP 走：Agent Skills 的設計與企業 AI 治理】)，則說明了如何透過六步風險管理與撰寫Skill說明檔，為AI的每一個動作套上SOP檢核點；很多開發團隊做到這一步，看著AI能安分地執行單一退款或查詢動作，就以為大功告成了，然而，當企業準備將十幾個不同的Agent投入到複雜的跨部門流程時，真正的困難階段才正要開始。 因為要讓AI執行一個動作，與讓AI長時間保持運行、安全與穩定的完成企業任務，則是完全不同層次的問題，我們試想一下，當企業內部的AI應用開始處理跨部門工單、非同步任務、多系統整合與高風險操作時，我們必須面對一個現實：模型可能判斷錯誤，工具可能執行失敗，網路可能中斷，任務可能重複執行，甚至整個系統可能在執行到一半時突然停止；相信講到這裡，大家就可以知道這些問題，並不是再多寫幾行提示詞或Skill規則就能解決的。 如果說LLM是一匹具有強大能力、卻無法完全預測他行徑方向的野馬，那麼Agent Skills則像是教它如何完成特定工作的訓練規範，再到Harness Engineering則是建立一整套能夠控制行動、管理狀態、處理故障並確保安全的駕馭系統。 這就是我們今天要探討的AI應用開發的第三階段核心：Harness Engineering也稱為駕馭工程，它不只是讓AI能夠執行任務，而是讓整個系統在AI可能犯錯、工具可能失敗、流程可能中斷的情況下，仍然能夠安全、可控且可恢復地運作；相信這點也是現在每個AI開發團隊花最多時間在琢磨的技術；在正式進入今天的主題之前，筆者先將過去兩篇的彙整如下表，供讀者們更容易理解近期專欄之關聯性與實作時的順序：

Agent = Model + Harness：駕馭工程的版圖

在目前的AI應用開發業界中最廣泛且又經典的「架構公式」：Agent = Model + Harness，請注意這裡是用架構公式，這個公式並不是嚴格統一的業界標準定義，而是一種方便理解Agent系統的簡化方式。 先以比較容易理解的方式來比喻，如果說LLM是強大的「引擎」，那麼Harness就是包裹著引擎的車體結構，包含了方向盤、煞車系統與安全氣囊等各項確保車輛能持續運作的機制；再回到AI的部份，模型負責理解問題、產生判斷與規劃行動；而Harness的概念則是負責將這些判斷轉化為受控的執行流程，並確保每個動作都符合企業執行的條件。 對應到我們之前談過的AI七層架構：
  • L3資料檢索層-知識工程：解決模型背景知識、能否取得正確資料，以及如何降低錯誤資訊的問題。
  • L4指令控制層-提示工程：解決模型扮演什麼角色的問題，以及如何依照指令產生回應的問題。
  • L5與L6工具執行與邏輯編排層-駕馭工程：解決模型如何思考、如何安全調用工具、遇到錯誤如何復原，以及如何確保整個系統安全運作的問題。
需要特別說明的是，Harness並不只涵蓋L5與L6，我們從廣義的工程實務來看，它也同時涉及到指令管理、資料存取、權限控制、監控與評估等其他層次。 而我們上一期精心設計的Agent Skills，則是Harness可以運用的一種任務規範與能力封裝方式，讓AI在執行特定工作時，有明確的操作指引與檢核條件；也因此一個完整的Harness框架，絕不只是工具控制模組，它還必須具備狀態管理、工具執行控制、錯誤處理與權限隔離等核心能力。

記憶與狀態管理：讓 AI 記得任務進度，更知道事情做到哪裡

在企業流程中，一項任務往往不是一次請求就能完成，而是包含多輪對話、長時間等待與跨系統協作的非同步任務，例如，主Agent派出子Agent查核客戶信用，子Agent可能需要十分鐘才回傳結果，那在這段時間內，主Agent依舊要保留原本的任務目標、已完成的步驟，以及接下來需要執行的工作，不過要求還只是最基本的。 筆者認為在AI應用開發中真正困難的是…如果系統在等待過程中突然中斷，重新啟動後，則Harness就是必須知道哪些工作已經完成、哪些工作仍在執行，以及哪些工作需要重新確認。 因此，Harness不能只依賴模型的上下文視窗來保存資訊，而必須建立可靠的狀態管理機制，在實作的設計上，這通常包含兩個層次：
  • 第一層是上下文管理：保存模型當下需要的對話內容、任務摘要與相關資料，避免上下文過長或重要資訊遺失。
  • 第二層是持久化的任務狀態：將任務進度、執行結果、操作紀錄與待處理事項寫入外部儲存系統，讓任務在模型重啟、服務中斷或工作人員交接後，仍然能夠接續任務的執行。
在這裡還需要引入資訊系統維運的工作流程狀態的概念，例如以資訊維運的Agent為例，一個任務通常會被拆解成： 事件接收 → 蒐集診斷資料 → 分析原因 → 規劃修復計畫 → 等待授權 → 執行修復 → 驗證結果 → 結案。 相信這流程對資訊業的人來說並不陌生，而且每個階段都必須有明確的狀態、輸入、輸出、轉移條件與日誌記錄，也就是系統不能只因為AI回覆「修復完成」，就將工單標記為結案；而是必須確認服務實際恢復正常，才能進入下一個狀態。 這就是狀態管理的真正價值：讓系統記錄的是已經發生且經過驗證的事實，而不只是AI認為自己完成了什麼。
《圖說》圖片來源：AI生成示意圖-Nano Banana Pro

工具執行控制：不只讓AI能呼叫工具，更要確保工具使用安全

Agent Skills的SOP主要是規範特定任務的執行方式，而到了Harness則必須進一步控制工具的使用條件、權限與執行結果；例如，AI想要重啟資料庫時，Harness不能只確認這個工具是否存在，而是必須確認：
  • 呼叫者是否具有執行權限？
  • 目標伺服器是否屬於使用者被授權之範圍？
  • 目前是否有備份或其他重要作業正在進行？
  • 這項操作是否需要人工授權？
  • 操作完成後，系統的驗證方式？
這些檢查應由模型之外的系統機制負責，而不是單純依賴Prompt告訴AI「請勿執行危險操作」。 Harness還需要考慮工具執行環境的隔離；例如，Agent可以查詢所有伺服器，但只能修改指定的測試環境；即使模型產生了錯誤的工具參數，系統也必須在真正執行之前攔截，這種工具執行控制之設計目的，就是要讓AI即使判斷錯誤，也無法輕易突破企業設定的安全邊界。 筆者的團隊，在這個項目的設計中，也只能先做個通用型，通常多數的設定都需到了客戶端，要落實時再進行客製化的調整，畢竟每間企業的流程與規範都是不同的。
《圖說》圖片來源：AI生成示意圖-Nano Banana Pro

多Agent協作：當十幾個Agent同時工作

當企業開始部署多個Agent，並讓它們分別負責不同系統或部門的工作時，問題就不再只是單一Agent的執行正確性，而是整個系統的協作與資源管理，我們假設企業部署了三個系統的維運Agent：
  • Agent A負責CRM連線異常。
  • Agent B負責資料庫效能監控。
  • Agent C負責備份作業。
當資料庫負載率突然升高，三個Agent可能同時發現異常，並各自提出修復計畫。 如果沒有統一的協調機制，就可能發生重複修復、互搶資源，甚至在備份期間重啟資料庫，因此，在Harness中必須建立多Agent的協作與控制機制：
  • 首先是任務協調：由主控系統負責分派任務、追蹤子Agent的執行狀態，並整合各個子Agent的結果。
  • 其次是資源控制：確保多個Agent不會同時對同一個關鍵資源執行互相衝突的操作；例如，透過資源鎖定、併發控制或操作請求，限制同一台資料庫在特定時間內只能執行一項具高風險的維運操作，或同時接收多少請求量。
  • 最終是結果驗證：主Agent不能因為子Agent回報成功，就直接認定任務已經完成，而是必須透過可信任的系統狀態或通過驗證流程來確認執行結果。
務必切記，多Agent並不代表多個模型各自工作就能自然形成高效率的團隊，真正的協作能力，來自任務分工、資源協調、狀態共享與結果驗證的整體設計，其實這裡的整體設計概念就如同資訊業infrastructure的維運框架而已。 由於多數企業還是想要有自己的封閉式AI系統，因此在實作中，筆者的團隊認為最難突破的就是在協調、控制與驗證中使用不同模型時的角色規劃，畢竟模型眾多，且各模型依其訓練集的權重而有不同的特性，同時還要符合非紅供應鏈的趨勢。

系統防護觀念：不是期待AI永遠不犯錯，而是要控制錯誤的影響

在傳統應用程式中，Timeout、重試與錯誤處理是基本的系統設計流程。 但在AI Agent的執行環境中，模型可能自行決定工具調用順序、重複嘗試或改變原定計畫，因此系統除了需要傳統的可靠性機制，更必須具備任務狀態追蹤、行為約束與執行結果驗證能力，例如，如果API發生異常，AI可能因為過度執著於完成任務，而陷入無限重試的迴圈，短時間內大量呼叫API，導致伺服器負載升高，甚至造成服務中斷；所以Harness必須設定最大重試次數、Timeout、呼叫頻率限制、資源限制與強制中斷等機制。 而在企業環境中，還必須考慮Prompt Injection攻擊，如果Agent讀取的工單中藏有惡意指令，可能誘導它洩漏資料或呼叫未授權工具，因此外部文件與工具回傳內容不能直接被視為可信任的指令或內容。 Harness必須透過獨立的政策檢查、權限隔離與安全執行環境，確保模型即使判斷錯誤，也無法跨越系統設定的安全邊界，而在資訊業的管理中，筆者始終謹記：「即使是99%的可控性與準確性，對企業來說仍舊有1%的不可控風險」，因此系統防護觀念所需建立的核心應為：不是期待AI永遠不犯錯，而是確保它犯錯時，錯誤仍然在可控制的範圍內。

讓AI能夠執行任務，只是企業駕馭工程的開始

從CLI、MCP到Agent Skills，我們逐步賦予AI理解問題、呼叫工具與依照規範執行任務的能力，而當AI開始處理長時間、多步驟、跨系統的企業流程時，真正的難題就不再只是模型能不能完成工作，而是整個系統能不能在各種不確定性下持續運作。 Harness Engineering的價值，正是透過狀態管理、工具控制、權限隔離與多 Agent協作，讓AI的行動不再只是模型的一次輸出，而是能夠被追蹤、控制與驗證的系統流程。 然而，即使我們已經為 AI 建立了完整的執行框架，仍然有一個問題很難避免，那就是如果AI已經成功呼叫工具，但系統卻無法確認操作是否完成時，我們該如何確保整個流程不會因為重複執行、狀態錯亂或錯誤復原而造成更大的問題，筆者認為這是在設計Harness Engineering中最難的挑戰，特別是在團隊與企業端使用者進行需求訪談時，多數的使用者都迫不急待地要將一切交給AI去執行，甚至連最終的審核也要交給AI，這對我們在進行AI應用的開發而言，是一件極其困擾的情況，畢竟企業需要治理與可靠的執行，絕不可能完全放任AI自主執行與決策，這也是下一篇專欄要進一步探討的主題：從故障復原、可靠性驗證到企業治理，如何讓AI Agent真正具備進入正式營運環境的能力「當AI開始自主執行：Harness Engineering的可靠性與企業治理」。