{"content_id":"tx8xp2gpig","slug":"ai-agent-harness-loop-graph-engineering","locale":"zh-hant","schema_type":"TechArticle","category":"knowledge_base","category_name":"知識庫","title":"依序理解 AI 代理的執行框架、迴圈與圖工程","summary":"執行框架設計代理的工作環境與控制機制，迴圈設計重複與終止規則，圖則設計允許的狀態與轉移路徑。這三個術語並非公認的標準分類，更準確的理解是：它們是處理 AI 代理自主性與風險的實務觀點。","sponsorship_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["執行框架工程是將模型之外的情境、工具、權限、驗證、日誌與核准程序設計為一套完整的執行環境。","迴圈工程定義代理反覆進行規劃、執行、驗證與修正的條件、預算及終止標準。","圖工程利用狀態與轉移規則，明確限制或調整代理可選擇的路徑。","對多數組織而言，相較於複雜的多代理圖，優先改善單一代理的執行框架與評估體系更有效率。","僅核准 AI 產生的摘要報告，對高風險程式碼並不足夠；還必須一併驗證測試、變更範圍、安全邊界與原始產出。"],"content_markdown":"隨著 AI 代理開始承擔長期任務，僅靠寫好提示詞已難以獲得穩定的結果。因為還必須設計代理要查看哪些資訊、使用哪些工具、何時重複、沿著哪條路徑移動，以及在哪裡必須取得人員核准。\n\n說明這個問題時，經常出現的說法是 **Harness 工程**、**迴圈工程**、**圖工程**。它們不是國際標準或經過嚴格共識形成的學術分類。彼此之間有所重疊，其含義也可能因產品與開發團隊而異。因此，與其把它們當作各年度的流行語來背誦，不如依照各自試圖回答的控制問題加以區分。\n\n## 三個概念一覽比較\n\n| 概念 | 核心問題 | 主要設計對象 | 代表性的故障防範機制 |\n|---|---|---|---|\n| Harness 工程 | 代理在什麼環境與規則內工作？ | 上下文、工具、權限、沙箱、Hook、日誌、核准、評估 | 最小權限、危險命令核准、執行測試、篩選上下文 |\n| 迴圈工程 | 要重複什麼，何時停止？ | 規劃·執行·驗證週期、事件處理、重試、預算、終止條件 | 最大重複次數、時間·Token 限制、進展判定、失敗時移交 |\n| 圖工程 | 允許哪些狀態與路徑？ | 節點、狀態、轉移、分支、平行處理、檢查點 | 禁止轉移、狀態驗證、核准節點、復原路徑 |\n\n簡單來說，**Harness 是環境與邊界**，**迴圈是重複規則**，**圖是可能路徑的結構**。在實際系統中，迴圈可以位於圖的某個節點內，而整張圖也可以在一個 Harness 內執行。\n\n## 代理控制方式如何演變\n\n### 早期代理：預先定義的工作流程補足了自主性\n\n早期的生成式 AI 代理在長期任務中，經常忘記目標、重複錯誤的工具呼叫，或產生缺乏依據的結果。為此，開發者將大型任務拆分為較小的步驟，並固定各步驟的輸入與輸出。\n\n在這種方式中，由人員將整體程序撰寫成鏈、流程圖或狀態機，而 LLM 則負責分類、擷取、摘要、撰寫草稿等受限任務。LangGraph 等框架可在維持狀態的同時，用來表達分支、循環、檢查點與人員介入。\n\n不過，以圖為基礎的協調並不是在某個特定年份結束的過時方式。即使在目前，對於可稽核性、可重現性、法規遵循或精確復原程序相當重要的業務，明確的圖仍然適合。\n\n### 模型效能提升：從固定路徑轉向動態使用工具\n\n隨著工具使用與推理能力改善，單一代理已能依情況選擇搜尋、編輯程式碼、測試、讀取檔案等行動。ReAct 類方法是交替執行推理、行動與觀察的代表性結構。\n\n這項變化減輕了人員必須預先編寫所有分支的負擔。另一方面，管理代理讀取的資訊、擁有的權限、執行成本與錯誤復原方式，變得更加重要。此時，上下文工程與 Harness 工程開始進入實務核心。\n\n### 長期任務與多代理：迴圈與圖的重新結合\n\n在長期任務中，反覆進行規劃、執行與驗證，比單次模型呼叫更重要。當多個代理參與時，也必須明確指定角色、產出格式、權限與終止條件。同時，若完全放任自主迴圈，可能發生成本暴增、無限重試、獎勵駭取與錯誤目標最佳化。\n\n因此，現代代理系統的設計方向不是消除自主性，而是**結合允許自主性的區段與採取確定性控制的區段**。這不是單純回歸過去的固定鏈，而是以狀態、轉移與政策包圍彈性執行。\n\n這些變化與其說是精確的時間表，不如說是設計重點的轉變。圖、迴圈與 Harness 從一開始便共存，現在也仍然搭配使用。\n\n## Harness 工程處理的內容\n\nHarness 不是基礎模型本身，而是**圍繞模型、使其得以執行實際業務的運行體系**。即使使用相同模型，成功率、成本、安全性與可重現性也可能因 Harness 而有很大差異。\n\n### Harness 的主要構成要素\n\n1. **指示體系**：系統指示、儲存庫規則、程式碼標準、優先順序與禁止行為\n2. **上下文供應**：搜尋、檔案選擇、摘要、記憶，以及在需要時注入文件\n3. **工具介面**：檔案編輯、終端機、瀏覽器、資料庫、外部 API\n4. **權限與隔離**：讀寫範圍、機密資訊存取、網路限制、沙箱\n5. **驗證機制**：測試、Linter、型別檢查、Schema 驗證、事實查核\n6. **人員核准**：對部署、付款、刪除、外部傳輸等難以復原的行為進行核准\n7. **可觀察性**：呼叫紀錄、成本、延遲時間、錯誤、變更內容、決策依據\n8. **復原政策**：重試、還原先前狀態、中止任務、移交負責人\n\nClaude Code 的專案指示檔案或 Hook，可視為 Harness 構成要素的案例。然而，某項特定產品功能並不代表整個 Harness。\n\n### 與上下文工程的差異\n\n上下文工程會最佳化要在目前的模型呼叫中放入哪些資訊與指示。這包括透過搜尋只取得相關文件、摘要舊對話、將任務狀態儲存到外部檔案，以及依子任務分離上下文等。\n\nHarness 工程的範圍更廣。除了上下文，也處理工具權限、執行環境、核准、驗證、日誌紀錄與成本限制。因此，上下文工程雖是 Harness 的核心部分，但將兩者完全視為同義並不精確。\n\n## 迴圈工程的核心是終止條件\n\n迴圈讓代理在產生結果後進行檢查，若有所不足便再次嘗試。重要的不是重複本身，而是**進展的定義與中止條件**。\n\n### 代表性的迴圈類型\n\n- **驗證迴圈**：產生草稿後，以測試或評估標準檢查，並修正未通過的項目。\n- **事件驅動迴圈**：在電子郵件、通知、程式碼變更、感測器資料等外部事件發生時開始任務。\n- **探索迴圈**：調查多個假設或資料來源，並在證據足夠前持續調整探索範圍。\n- **改善迴圈**：根據先前結果與評估值選擇下一個策略。若只最佳化單一分數，可能發生獎勵駭取，因此需要多項評估標準與人員審查。\n- **復原迴圈**：分類錯誤原因，在允許範圍內重試，若仍無法解決便交由人員處理。\n\n### 安全迴圈所需的契約\n\n代理之間的契約不是法律契約，而是明確規定輸入、輸出與責任的執行規格。建議包含下列項目。\n\n| 契約項目 | 應明確指定的內容 |\n|---|---|\n| 目標 | 必須完成的結果與排除範圍 |\n| 輸入 | 可使用的資料、時效性、可信度 |\n| 輸出 | JSON Schema、文件格式、必要依據與測試結果 |\n| 權限 | 允許的工具、檔案範圍、外部傳輸與變更權限 |\n| 驗證 | 必須通過的測試與評估標準 |\n| 預算 | Token、時間、呼叫次數、平行任務數量 |\n| 終止 | 成功、無進展、預算耗盡、偵測到風險的條件 |\n| 移交 | 失敗時由哪位人員或哪個代理接手 |\n\n如果完成條件模糊，代理可能只是改寫句子或重複相同搜尋，卻仍判斷任務正在取得進展。與其只設定最大重複次數，不如同時觀察結果品質、新資訊的增加量、錯誤變化與成本。\n\n## 圖工程將自主性的邊界結構化\n\n圖會以節點與連線表示任務。節點可以是模型呼叫、工具執行、人員核准或驗證流程，而連線則表示依狀態決定的下一項行動。\n\n### 鏈與圖的差異\n\n- **鏈**適合從 A 到 B、再從 B 到 C 的線性程序。\n- **圖**適合需要條件分支、重複、平行執行、失敗復原與中途儲存的任務。\n- **動態圖**由模型在執行期間提出下一個子任務或路徑。\n- **受限圖**即使由模型選擇，也只能在允許的節點與轉移範圍內移動。\n\n現代圖設計的目的，不是讓人員預先決定所有行為，而是將**必須遵守的不變條件**放入結構中，例如在刪除資料前必須經過核准節點，或在測試失敗狀態下不得轉移到部署狀態。\n\n### 需要圖的訊號\n\n若符合下列多項條件，就值得考慮採用明確的圖。\n\n- 失敗後應返回的復原點很明確。\n- 存在必須取得人員核准的步驟。\n- 必須平行執行多項任務後合併結果。\n- 可用的工具或權限會依狀態而異。\n- 必須稽核或重現完整執行路徑。\n- 單一代理迴圈重複相同失敗。\n\n若連單純的文件摘要或單次資料轉換都製作成圖，可能只會增加複雜性。\n\n## 實務套用順序：從 Harness 開始，依需要擴充\n\n對大多數團隊而言，以下順序較為實際。\n\n1. **確定單一任務與成功標準。** 先蒐集輸入、預期輸出與失敗案例。\n2. **建立最小 Harness。** 只提供必要的上下文與工具，並設定權限、測試、日誌與成本上限。\n3. **建立評估集。** 除了正常案例，也應包含模糊要求、錯誤文件、工具錯誤與超越權限的嘗試。\n4. **將需要重複的部分做成迴圈。** 只在驗證與修正確實能提升品質的區段允許重試。\n5. **在分支與復原變得複雜時升級為圖。** 明確指定狀態與轉移，並在危險行為前設置核准節點。\n6. **僅在工作拆分確實有益時使用多代理。** 若不需要平行探索或不同專業角色，單一代理可能更簡單且更便宜。\n\n## 程式設計與研究中的套用差異\n\n| 項目 | 程式設計任務 | 研究任務 |\n|---|---|---|\n| 可驗證性 | 測試、建置、型別檢查等自動驗證相對容易 | 必須綜合判斷來源品質、遺漏與相互矛盾的證據 |\n| 動態探索的價值 | 若變更範圍明確，價值可能有限 | 在多種搜尋路徑與假設比較中價值較大 |\n| 主要風險 | 錯誤變更、安全漏洞、只為通過測試而寫的程式碼 | 缺乏來源的主張、重複資料、確認偏誤 |\n| 適合的控制 | 限制儲存庫範圍、測試、diff 審查、部署核准 | 來源紀錄、獨立搜尋、尋找反面證據、引用驗證 |\n\n不能斷言動態工作流程在程式設計中總是缺乏效率，而在研究中總是有利。可進行測試的大規模遷移可能適合自主代理，而答案明確的事實查詢，採用固定研究程序可能更有效率。關鍵變數不是領域，而是**目標的明確程度、自動驗證的可能性、探索空間與錯誤成本**。\n\n## 程式碼審查不會消失，而是審查單位改變\n\n當代理撰寫程式碼時，開發者不再需要直接輸入每一行，而會更多地負責監督需求、設計、測試結果、變更範圍與風險。Pull Request 摘要與代理報告可以提升審查速度。\n\n然而，只閱讀摘要便核准的方式並不是安全的預設選項。代理遺漏的變更或錯誤理解的邏輯，也可能不會出現在摘要中。在下列情況下，必須直接審查原始 diff 與相關程式碼。\n\n- 驗證、付款、個人資料、加密、存取控制變更\n- 資料庫 Schema 變更或不可逆的遷移\n- 對效能與並行處理敏感的程式碼\n- 超出測試範圍的大規模重構\n- 外部相依項目、部署設定、機密資訊處理變更\n- 代理的說明與實際 diff 不一致時\n\nHuman-in-the-loop 並不是由人員形式化地按下按鈕。它還包括提供變更證據、測試結果、失敗可能性與復原程序，讓人員能夠做出判斷。\n\n## 常見陷阱\n\n### 沒有目的的多代理\n\n增加代理會產生角色協調、重複呼叫、上下文傳遞與結果合併的成本。如果不需要從不同觀點進行平行探索，也沒有必須分離上下文的理由，單一代理會更好。\n\n### 無限制的動態工作流程\n\n若允許代理持續建立子任務，Token 與工具呼叫成本會迅速增加。成本大致由各步驟的輸入·輸出 Token 成本、工具成本、平行代理數量與重複次數的總和決定。必須分別限制呼叫次數、同時執行數量、總預算與最長執行時間。\n\n### 只最佳化一項評估指標\n\n若只將測試通過率設為目標，可能出現削弱測試或隱藏例外處理等錯誤最佳化。應同時使用品質、安全性、變更規模、成本、延遲時間與人員評估。\n\n### 將文件注入與微調混為一談\n\n透過文件搜尋或專案指示，可以持續改變結果，但模型權重並不會改變。廣義而言，這可以解釋為系統的學習效果；但嚴格來說，這是利用外部記憶與上下文進行調適。必須保存文件或搜尋索引，才能在下次執行時繼續維持變化。\n\n## 營運階段容易忽略的評估、安全性與經濟性\n\n代理設計不會止於架構圖。在實際營運中，比起**允許了什麼，更重要的是建立衡量實際發生了什麼的體系**。\n\n### 最低營運指標\n\n- 任務成功率與人員修改率\n- 每項任務的模型·工具成本與總執行時間\n- 重複次數與未取得進展便消耗的呼叫比例\n- 核准請求、拒絕、超越權限嘗試的次數\n- 錯誤工具呼叫與復原成功率\n- 未提供來源或測試便提交的結果比例\n- 相同輸入下結果產生差異的程度\n\n### 安全上所需的不變條件\n\n- 外部文件中的指示不得擁有高於系統政策的優先順序。\n- 不應在模型輸入與日誌中不必要地暴露機密資訊。\n- 將讀取權限與寫入·刪除·部署權限分開。\n- 對外部傳輸與不可逆行為設置額外核准或政策檢查。\n- 不允許代理任意修改自身的評估標準、測試或稽核日誌。\n\n相較於提示詞中的一句話，透過沙箱、存取控制、圖轉移與獨立驗證器強制執行這些不變條件會更安全。生成式 AI 風險管理不僅應涵蓋模型準確度，也必須包含營運環境、人員監督與事故應變。\n\n## 應該先學習哪個概念\n\n目前在實務上最先應掌握的是 Harness 工程。具備精確的上下文、最小權限、自動驗證、日誌、核准與成本上限，就能減少單一代理的許多失敗。\n\n接著，在重複有助於提升品質的任務中加入具有終止條件的迴圈。當分支、平行處理、復原與核准程序變得複雜時，再以圖明確表示。相較於採用複雜術語，更應優先將代理的目標、權限、證據、成本與中止條件轉換為可衡量的形式。","content_html":"\u003cp\u003e隨著 AI 代理開始承擔長期任務，僅靠寫好提示詞已難以獲得穩定的結果。因為還必須設計代理要查看哪些資訊、使用哪些工具、何時重複、沿著哪條路徑移動，以及在哪裡必須取得人員核准。\u003c/p\u003e\n\u003cp\u003e說明這個問題時，經常出現的說法是 \u003cstrong\u003eHarness 工程\u003c/strong\u003e、\u003cstrong\u003e迴圈工程\u003c/strong\u003e、\u003cstrong\u003e圖工程\u003c/strong\u003e。它們不是國際標準或經過嚴格共識形成的學術分類。彼此之間有所重疊，其含義也可能因產品與開發團隊而異。因此，與其把它們當作各年度的流行語來背誦，不如依照各自試圖回答的控制問題加以區分。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%B8%89%E5%80%8B%E6%A6%82%E5%BF%B5%E4%B8%80%E8%A6%BD%E6%AF%94%E8%BC%83\" class=\"anchor\" id=\"三個概念一覽比較\"\u003e\u003c/a\u003e三個概念一覽比較\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e概念\u003c/th\u003e\n\u003cth\u003e核心問題\u003c/th\u003e\n\u003cth\u003e主要設計對象\u003c/th\u003e\n\u003cth\u003e代表性的故障防範機制\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"概念\"\u003eHarness 工程\u003c/td\u003e\n\u003ctd data-label=\"核心問題\"\u003e代理在什麼環境與規則內工作？\u003c/td\u003e\n\u003ctd data-label=\"主要設計對象\"\u003e上下文、工具、權限、沙箱、Hook、日誌、核准、評估\u003c/td\u003e\n\u003ctd data-label=\"代表性的故障防範機制\"\u003e最小權限、危險命令核准、執行測試、篩選上下文\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"概念\"\u003e迴圈工程\u003c/td\u003e\n\u003ctd data-label=\"核心問題\"\u003e要重複什麼，何時停止？\u003c/td\u003e\n\u003ctd data-label=\"主要設計對象\"\u003e規劃·執行·驗證週期、事件處理、重試、預算、終止條件\u003c/td\u003e\n\u003ctd data-label=\"代表性的故障防範機制\"\u003e最大重複次數、時間·Token 限制、進展判定、失敗時移交\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"概念\"\u003e圖工程\u003c/td\u003e\n\u003ctd data-label=\"核心問題\"\u003e允許哪些狀態與路徑？\u003c/td\u003e\n\u003ctd data-label=\"主要設計對象\"\u003e節點、狀態、轉移、分支、平行處理、檢查點\u003c/td\u003e\n\u003ctd data-label=\"代表性的故障防範機制\"\u003e禁止轉移、狀態驗證、核准節點、復原路徑\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e簡單來說，\u003cstrong\u003eHarness 是環境與邊界\u003c/strong\u003e，\u003cstrong\u003e迴圈是重複規則\u003c/strong\u003e，\u003cstrong\u003e圖是可能路徑的結構\u003c/strong\u003e。在實際系統中，迴圈可以位於圖的某個節點內，而整張圖也可以在一個 Harness 內執行。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%BB%A3%E7%90%86%E6%8E%A7%E5%88%B6%E6%96%B9%E5%BC%8F%E5%A6%82%E4%BD%95%E6%BC%94%E8%AE%8A\" class=\"anchor\" id=\"代理控制方式如何演變\"\u003e\u003c/a\u003e代理控制方式如何演變\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%97%A9%E6%9C%9F%E4%BB%A3%E7%90%86%E9%A0%90%E5%85%88%E5%AE%9A%E7%BE%A9%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B%E8%A3%9C%E8%B6%B3%E4%BA%86%E8%87%AA%E4%B8%BB%E6%80%A7\" class=\"anchor\" id=\"早期代理預先定義的工作流程補足了自主性\"\u003e\u003c/a\u003e早期代理：預先定義的工作流程補足了自主性\u003c/h3\u003e\n\u003cp\u003e早期的生成式 AI 代理在長期任務中，經常忘記目標、重複錯誤的工具呼叫，或產生缺乏依據的結果。為此，開發者將大型任務拆分為較小的步驟，並固定各步驟的輸入與輸出。\u003c/p\u003e\n\u003cp\u003e在這種方式中，由人員將整體程序撰寫成鏈、流程圖或狀態機，而 LLM 則負責分類、擷取、摘要、撰寫草稿等受限任務。LangGraph 等框架可在維持狀態的同時，用來表達分支、循環、檢查點與人員介入。\u003c/p\u003e\n\u003cp\u003e不過，以圖為基礎的協調並不是在某個特定年份結束的過時方式。即使在目前，對於可稽核性、可重現性、法規遵循或精確復原程序相當重要的業務，明確的圖仍然適合。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%A8%A1%E5%9E%8B%E6%95%88%E8%83%BD%E6%8F%90%E5%8D%87%E5%BE%9E%E5%9B%BA%E5%AE%9A%E8%B7%AF%E5%BE%91%E8%BD%89%E5%90%91%E5%8B%95%E6%85%8B%E4%BD%BF%E7%94%A8%E5%B7%A5%E5%85%B7\" class=\"anchor\" id=\"模型效能提升從固定路徑轉向動態使用工具\"\u003e\u003c/a\u003e模型效能提升：從固定路徑轉向動態使用工具\u003c/h3\u003e\n\u003cp\u003e隨著工具使用與推理能力改善，單一代理已能依情況選擇搜尋、編輯程式碼、測試、讀取檔案等行動。ReAct 類方法是交替執行推理、行動與觀察的代表性結構。\u003c/p\u003e\n\u003cp\u003e這項變化減輕了人員必須預先編寫所有分支的負擔。另一方面，管理代理讀取的資訊、擁有的權限、執行成本與錯誤復原方式，變得更加重要。此時，上下文工程與 Harness 工程開始進入實務核心。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%95%B7%E6%9C%9F%E4%BB%BB%E5%8B%99%E8%88%87%E5%A4%9A%E4%BB%A3%E7%90%86%E8%BF%B4%E5%9C%88%E8%88%87%E5%9C%96%E7%9A%84%E9%87%8D%E6%96%B0%E7%B5%90%E5%90%88\" class=\"anchor\" id=\"長期任務與多代理迴圈與圖的重新結合\"\u003e\u003c/a\u003e長期任務與多代理：迴圈與圖的重新結合\u003c/h3\u003e\n\u003cp\u003e在長期任務中，反覆進行規劃、執行與驗證，比單次模型呼叫更重要。當多個代理參與時，也必須明確指定角色、產出格式、權限與終止條件。同時，若完全放任自主迴圈，可能發生成本暴增、無限重試、獎勵駭取與錯誤目標最佳化。\u003c/p\u003e\n\u003cp\u003e因此，現代代理系統的設計方向不是消除自主性，而是\u003cstrong\u003e結合允許自主性的區段與採取確定性控制的區段\u003c/strong\u003e。這不是單純回歸過去的固定鏈，而是以狀態、轉移與政策包圍彈性執行。\u003c/p\u003e\n\u003cp\u003e這些變化與其說是精確的時間表，不如說是設計重點的轉變。圖、迴圈與 Harness 從一開始便共存，現在也仍然搭配使用。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#harness-%E5%B7%A5%E7%A8%8B%E8%99%95%E7%90%86%E7%9A%84%E5%85%A7%E5%AE%B9\" class=\"anchor\" id=\"harness-工程處理的內容\"\u003e\u003c/a\u003eHarness 工程處理的內容\u003c/h2\u003e\n\u003cp\u003eHarness 不是基礎模型本身，而是\u003cstrong\u003e圍繞模型、使其得以執行實際業務的運行體系\u003c/strong\u003e。即使使用相同模型，成功率、成本、安全性與可重現性也可能因 Harness 而有很大差異。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#harness-%E7%9A%84%E4%B8%BB%E8%A6%81%E6%A7%8B%E6%88%90%E8%A6%81%E7%B4%A0\" class=\"anchor\" id=\"harness-的主要構成要素\"\u003e\u003c/a\u003eHarness 的主要構成要素\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003e指示體系\u003c/strong\u003e：系統指示、儲存庫規則、程式碼標準、優先順序與禁止行為\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e上下文供應\u003c/strong\u003e：搜尋、檔案選擇、摘要、記憶，以及在需要時注入文件\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e工具介面\u003c/strong\u003e：檔案編輯、終端機、瀏覽器、資料庫、外部 API\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e權限與隔離\u003c/strong\u003e：讀寫範圍、機密資訊存取、網路限制、沙箱\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e驗證機制\u003c/strong\u003e：測試、Linter、型別檢查、Schema 驗證、事實查核\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e人員核准\u003c/strong\u003e：對部署、付款、刪除、外部傳輸等難以復原的行為進行核准\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e可觀察性\u003c/strong\u003e：呼叫紀錄、成本、延遲時間、錯誤、變更內容、決策依據\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e復原政策\u003c/strong\u003e：重試、還原先前狀態、中止任務、移交負責人\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eClaude Code 的專案指示檔案或 Hook，可視為 Harness 構成要素的案例。然而，某項特定產品功能並不代表整個 Harness。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E8%88%87%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B%E7%9A%84%E5%B7%AE%E7%95%B0\" class=\"anchor\" id=\"與上下文工程的差異\"\u003e\u003c/a\u003e與上下文工程的差異\u003c/h3\u003e\n\u003cp\u003e上下文工程會最佳化要在目前的模型呼叫中放入哪些資訊與指示。這包括透過搜尋只取得相關文件、摘要舊對話、將任務狀態儲存到外部檔案，以及依子任務分離上下文等。\u003c/p\u003e\n\u003cp\u003eHarness 工程的範圍更廣。除了上下文，也處理工具權限、執行環境、核准、驗證、日誌紀錄與成本限制。因此，上下文工程雖是 Harness 的核心部分，但將兩者完全視為同義並不精確。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%BF%B4%E5%9C%88%E5%B7%A5%E7%A8%8B%E7%9A%84%E6%A0%B8%E5%BF%83%E6%98%AF%E7%B5%82%E6%AD%A2%E6%A2%9D%E4%BB%B6\" class=\"anchor\" id=\"迴圈工程的核心是終止條件\"\u003e\u003c/a\u003e迴圈工程的核心是終止條件\u003c/h2\u003e\n\u003cp\u003e迴圈讓代理在產生結果後進行檢查，若有所不足便再次嘗試。重要的不是重複本身，而是\u003cstrong\u003e進展的定義與中止條件\u003c/strong\u003e。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E4%BB%A3%E8%A1%A8%E6%80%A7%E7%9A%84%E8%BF%B4%E5%9C%88%E9%A1%9E%E5%9E%8B\" class=\"anchor\" id=\"代表性的迴圈類型\"\u003e\u003c/a\u003e代表性的迴圈類型\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003e驗證迴圈\u003c/strong\u003e：產生草稿後，以測試或評估標準檢查，並修正未通過的項目。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e事件驅動迴圈\u003c/strong\u003e：在電子郵件、通知、程式碼變更、感測器資料等外部事件發生時開始任務。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e探索迴圈\u003c/strong\u003e：調查多個假設或資料來源，並在證據足夠前持續調整探索範圍。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e改善迴圈\u003c/strong\u003e：根據先前結果與評估值選擇下一個策略。若只最佳化單一分數，可能發生獎勵駭取，因此需要多項評估標準與人員審查。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e復原迴圈\u003c/strong\u003e：分類錯誤原因，在允許範圍內重試，若仍無法解決便交由人員處理。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%AE%89%E5%85%A8%E8%BF%B4%E5%9C%88%E6%89%80%E9%9C%80%E7%9A%84%E5%A5%91%E7%B4%84\" class=\"anchor\" id=\"安全迴圈所需的契約\"\u003e\u003c/a\u003e安全迴圈所需的契約\u003c/h3\u003e\n\u003cp\u003e代理之間的契約不是法律契約，而是明確規定輸入、輸出與責任的執行規格。建議包含下列項目。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e契約項目\u003c/th\u003e\n\u003cth\u003e應明確指定的內容\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e目標\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e必須完成的結果與排除範圍\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e輸入\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e可使用的資料、時效性、可信度\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e輸出\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003eJSON Schema、文件格式、必要依據與測試結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e權限\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e允許的工具、檔案範圍、外部傳輸與變更權限\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e驗證\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e必須通過的測試與評估標準\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e預算\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003eToken、時間、呼叫次數、平行任務數量\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e終止\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e成功、無進展、預算耗盡、偵測到風險的條件\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"契約項目\"\u003e移交\u003c/td\u003e\n\u003ctd data-label=\"應明確指定的內容\"\u003e失敗時由哪位人員或哪個代理接手\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e如果完成條件模糊，代理可能只是改寫句子或重複相同搜尋，卻仍判斷任務正在取得進展。與其只設定最大重複次數，不如同時觀察結果品質、新資訊的增加量、錯誤變化與成本。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%9C%96%E5%B7%A5%E7%A8%8B%E5%B0%87%E8%87%AA%E4%B8%BB%E6%80%A7%E7%9A%84%E9%82%8A%E7%95%8C%E7%B5%90%E6%A7%8B%E5%8C%96\" class=\"anchor\" id=\"圖工程將自主性的邊界結構化\"\u003e\u003c/a\u003e圖工程將自主性的邊界結構化\u003c/h2\u003e\n\u003cp\u003e圖會以節點與連線表示任務。節點可以是模型呼叫、工具執行、人員核准或驗證流程，而連線則表示依狀態決定的下一項行動。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%8F%88%E8%88%87%E5%9C%96%E7%9A%84%E5%B7%AE%E7%95%B0\" class=\"anchor\" id=\"鏈與圖的差異\"\u003e\u003c/a\u003e鏈與圖的差異\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003e鏈\u003c/strong\u003e適合從 A 到 B、再從 B 到 C 的線性程序。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e圖\u003c/strong\u003e適合需要條件分支、重複、平行執行、失敗復原與中途儲存的任務。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e動態圖\u003c/strong\u003e由模型在執行期間提出下一個子任務或路徑。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e受限圖\u003c/strong\u003e即使由模型選擇，也只能在允許的節點與轉移範圍內移動。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e現代圖設計的目的，不是讓人員預先決定所有行為，而是將\u003cstrong\u003e必須遵守的不變條件\u003c/strong\u003e放入結構中，例如在刪除資料前必須經過核准節點，或在測試失敗狀態下不得轉移到部署狀態。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%9C%80%E8%A6%81%E5%9C%96%E7%9A%84%E8%A8%8A%E8%99%9F\" class=\"anchor\" id=\"需要圖的訊號\"\u003e\u003c/a\u003e需要圖的訊號\u003c/h3\u003e\n\u003cp\u003e若符合下列多項條件，就值得考慮採用明確的圖。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e失敗後應返回的復原點很明確。\u003c/li\u003e\n\u003cli\u003e存在必須取得人員核准的步驟。\u003c/li\u003e\n\u003cli\u003e必須平行執行多項任務後合併結果。\u003c/li\u003e\n\u003cli\u003e可用的工具或權限會依狀態而異。\u003c/li\u003e\n\u003cli\u003e必須稽核或重現完整執行路徑。\u003c/li\u003e\n\u003cli\u003e單一代理迴圈重複相同失敗。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e若連單純的文件摘要或單次資料轉換都製作成圖，可能只會增加複雜性。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%AF%A6%E5%8B%99%E5%A5%97%E7%94%A8%E9%A0%86%E5%BA%8F%E5%BE%9E-harness-%E9%96%8B%E5%A7%8B%E4%BE%9D%E9%9C%80%E8%A6%81%E6%93%B4%E5%85%85\" class=\"anchor\" id=\"實務套用順序從-harness-開始依需要擴充\"\u003e\u003c/a\u003e實務套用順序：從 Harness 開始，依需要擴充\u003c/h2\u003e\n\u003cp\u003e對大多數團隊而言，以下順序較為實際。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003e確定單一任務與成功標準。\u003c/strong\u003e 先蒐集輸入、預期輸出與失敗案例。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e建立最小 Harness。\u003c/strong\u003e 只提供必要的上下文與工具，並設定權限、測試、日誌與成本上限。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e建立評估集。\u003c/strong\u003e 除了正常案例，也應包含模糊要求、錯誤文件、工具錯誤與超越權限的嘗試。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e將需要重複的部分做成迴圈。\u003c/strong\u003e 只在驗證與修正確實能提升品質的區段允許重試。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e在分支與復原變得複雜時升級為圖。\u003c/strong\u003e 明確指定狀態與轉移，並在危險行為前設置核准節點。\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003e僅在工作拆分確實有益時使用多代理。\u003c/strong\u003e 若不需要平行探索或不同專業角色，單一代理可能更簡單且更便宜。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%A8%8B%E5%BC%8F%E8%A8%AD%E8%A8%88%E8%88%87%E7%A0%94%E7%A9%B6%E4%B8%AD%E7%9A%84%E5%A5%97%E7%94%A8%E5%B7%AE%E7%95%B0\" class=\"anchor\" id=\"程式設計與研究中的套用差異\"\u003e\u003c/a\u003e程式設計與研究中的套用差異\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e項目\u003c/th\u003e\n\u003cth\u003e程式設計任務\u003c/th\u003e\n\u003cth\u003e研究任務\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e可驗證性\u003c/td\u003e\n\u003ctd data-label=\"程式設計任務\"\u003e測試、建置、型別檢查等自動驗證相對容易\u003c/td\u003e\n\u003ctd data-label=\"研究任務\"\u003e必須綜合判斷來源品質、遺漏與相互矛盾的證據\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e動態探索的價值\u003c/td\u003e\n\u003ctd data-label=\"程式設計任務\"\u003e若變更範圍明確，價值可能有限\u003c/td\u003e\n\u003ctd data-label=\"研究任務\"\u003e在多種搜尋路徑與假設比較中價值較大\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e主要風險\u003c/td\u003e\n\u003ctd data-label=\"程式設計任務\"\u003e錯誤變更、安全漏洞、只為通過測試而寫的程式碼\u003c/td\u003e\n\u003ctd data-label=\"研究任務\"\u003e缺乏來源的主張、重複資料、確認偏誤\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e適合的控制\u003c/td\u003e\n\u003ctd data-label=\"程式設計任務\"\u003e限制儲存庫範圍、測試、diff 審查、部署核准\u003c/td\u003e\n\u003ctd data-label=\"研究任務\"\u003e來源紀錄、獨立搜尋、尋找反面證據、引用驗證\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e不能斷言動態工作流程在程式設計中總是缺乏效率，而在研究中總是有利。可進行測試的大規模遷移可能適合自主代理，而答案明確的事實查詢，採用固定研究程序可能更有效率。關鍵變數不是領域，而是\u003cstrong\u003e目標的明確程度、自動驗證的可能性、探索空間與錯誤成本\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%A8%8B%E5%BC%8F%E7%A2%BC%E5%AF%A9%E6%9F%A5%E4%B8%8D%E6%9C%83%E6%B6%88%E5%A4%B1%E8%80%8C%E6%98%AF%E5%AF%A9%E6%9F%A5%E5%96%AE%E4%BD%8D%E6%94%B9%E8%AE%8A\" class=\"anchor\" id=\"程式碼審查不會消失而是審查單位改變\"\u003e\u003c/a\u003e程式碼審查不會消失，而是審查單位改變\u003c/h2\u003e\n\u003cp\u003e當代理撰寫程式碼時，開發者不再需要直接輸入每一行，而會更多地負責監督需求、設計、測試結果、變更範圍與風險。Pull Request 摘要與代理報告可以提升審查速度。\u003c/p\u003e\n\u003cp\u003e然而，只閱讀摘要便核准的方式並不是安全的預設選項。代理遺漏的變更或錯誤理解的邏輯，也可能不會出現在摘要中。在下列情況下，必須直接審查原始 diff 與相關程式碼。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e驗證、付款、個人資料、加密、存取控制變更\u003c/li\u003e\n\u003cli\u003e資料庫 Schema 變更或不可逆的遷移\u003c/li\u003e\n\u003cli\u003e對效能與並行處理敏感的程式碼\u003c/li\u003e\n\u003cli\u003e超出測試範圍的大規模重構\u003c/li\u003e\n\u003cli\u003e外部相依項目、部署設定、機密資訊處理變更\u003c/li\u003e\n\u003cli\u003e代理的說明與實際 diff 不一致時\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHuman-in-the-loop 並不是由人員形式化地按下按鈕。它還包括提供變更證據、測試結果、失敗可能性與復原程序，讓人員能夠做出判斷。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%B8%B8%E8%A6%8B%E9%99%B7%E9%98%B1\" class=\"anchor\" id=\"常見陷阱\"\u003e\u003c/a\u003e常見陷阱\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%B2%92%E6%9C%89%E7%9B%AE%E7%9A%84%E7%9A%84%E5%A4%9A%E4%BB%A3%E7%90%86\" class=\"anchor\" id=\"沒有目的的多代理\"\u003e\u003c/a\u003e沒有目的的多代理\u003c/h3\u003e\n\u003cp\u003e增加代理會產生角色協調、重複呼叫、上下文傳遞與結果合併的成本。如果不需要從不同觀點進行平行探索，也沒有必須分離上下文的理由，單一代理會更好。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%84%A1%E9%99%90%E5%88%B6%E7%9A%84%E5%8B%95%E6%85%8B%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B\" class=\"anchor\" id=\"無限制的動態工作流程\"\u003e\u003c/a\u003e無限制的動態工作流程\u003c/h3\u003e\n\u003cp\u003e若允許代理持續建立子任務，Token 與工具呼叫成本會迅速增加。成本大致由各步驟的輸入·輸出 Token 成本、工具成本、平行代理數量與重複次數的總和決定。必須分別限制呼叫次數、同時執行數量、總預算與最長執行時間。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%8F%AA%E6%9C%80%E4%BD%B3%E5%8C%96%E4%B8%80%E9%A0%85%E8%A9%95%E4%BC%B0%E6%8C%87%E6%A8%99\" class=\"anchor\" id=\"只最佳化一項評估指標\"\u003e\u003c/a\u003e只最佳化一項評估指標\u003c/h3\u003e\n\u003cp\u003e若只將測試通過率設為目標，可能出現削弱測試或隱藏例外處理等錯誤最佳化。應同時使用品質、安全性、變更規模、成本、延遲時間與人員評估。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%B0%87%E6%96%87%E4%BB%B6%E6%B3%A8%E5%85%A5%E8%88%87%E5%BE%AE%E8%AA%BF%E6%B7%B7%E7%82%BA%E4%B8%80%E8%AB%87\" class=\"anchor\" id=\"將文件注入與微調混為一談\"\u003e\u003c/a\u003e將文件注入與微調混為一談\u003c/h3\u003e\n\u003cp\u003e透過文件搜尋或專案指示，可以持續改變結果，但模型權重並不會改變。廣義而言，這可以解釋為系統的學習效果；但嚴格來說，這是利用外部記憶與上下文進行調適。必須保存文件或搜尋索引，才能在下次執行時繼續維持變化。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%87%9F%E9%81%8B%E9%9A%8E%E6%AE%B5%E5%AE%B9%E6%98%93%E5%BF%BD%E7%95%A5%E7%9A%84%E8%A9%95%E4%BC%B0%E5%AE%89%E5%85%A8%E6%80%A7%E8%88%87%E7%B6%93%E6%BF%9F%E6%80%A7\" class=\"anchor\" id=\"營運階段容易忽略的評估安全性與經濟性\"\u003e\u003c/a\u003e營運階段容易忽略的評估、安全性與經濟性\u003c/h2\u003e\n\u003cp\u003e代理設計不會止於架構圖。在實際營運中，比起\u003cstrong\u003e允許了什麼，更重要的是建立衡量實際發生了什麼的體系\u003c/strong\u003e。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%9C%80%E4%BD%8E%E7%87%9F%E9%81%8B%E6%8C%87%E6%A8%99\" class=\"anchor\" id=\"最低營運指標\"\u003e\u003c/a\u003e最低營運指標\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e任務成功率與人員修改率\u003c/li\u003e\n\u003cli\u003e每項任務的模型·工具成本與總執行時間\u003c/li\u003e\n\u003cli\u003e重複次數與未取得進展便消耗的呼叫比例\u003c/li\u003e\n\u003cli\u003e核准請求、拒絕、超越權限嘗試的次數\u003c/li\u003e\n\u003cli\u003e錯誤工具呼叫與復原成功率\u003c/li\u003e\n\u003cli\u003e未提供來源或測試便提交的結果比例\u003c/li\u003e\n\u003cli\u003e相同輸入下結果產生差異的程度\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%AE%89%E5%85%A8%E4%B8%8A%E6%89%80%E9%9C%80%E7%9A%84%E4%B8%8D%E8%AE%8A%E6%A2%9D%E4%BB%B6\" class=\"anchor\" id=\"安全上所需的不變條件\"\u003e\u003c/a\u003e安全上所需的不變條件\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e外部文件中的指示不得擁有高於系統政策的優先順序。\u003c/li\u003e\n\u003cli\u003e不應在模型輸入與日誌中不必要地暴露機密資訊。\u003c/li\u003e\n\u003cli\u003e將讀取權限與寫入·刪除·部署權限分開。\u003c/li\u003e\n\u003cli\u003e對外部傳輸與不可逆行為設置額外核准或政策檢查。\u003c/li\u003e\n\u003cli\u003e不允許代理任意修改自身的評估標準、測試或稽核日誌。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e相較於提示詞中的一句話，透過沙箱、存取控制、圖轉移與獨立驗證器強制執行這些不變條件會更安全。生成式 AI 風險管理不僅應涵蓋模型準確度，也必須包含營運環境、人員監督與事故應變。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E6%87%89%E8%A9%B2%E5%85%88%E5%AD%B8%E7%BF%92%E5%93%AA%E5%80%8B%E6%A6%82%E5%BF%B5\" class=\"anchor\" id=\"應該先學習哪個概念\"\u003e\u003c/a\u003e應該先學習哪個概念\u003c/h2\u003e\n\u003cp\u003e目前在實務上最先應掌握的是 Harness 工程。具備精確的上下文、最小權限、自動驗證、日誌、核准與成本上限，就能減少單一代理的許多失敗。\u003c/p\u003e\n\u003cp\u003e接著，在重複有助於提升品質的任務中加入具有終止條件的迴圈。當分支、平行處理、復原與核准程序變得複雜時，再以圖明確表示。相較於採用複雜術語，更應優先將代理的目標、權限、證據、成本與中止條件轉換為可衡量的形式。\u003c/p\u003e\n","tags":["上下文工程","測試框架工程","AI 代理人","Claude Code","AI 開發","程式設計代理"],"faqs":[{"question":"Harness 工程與提示工程有何不同？","answer":"提示工程主要處理要傳達給模型的指示與表達方式。Harness 工程則是更廣泛的執行環境設計，除了提示之外，還包括上下文搜尋、工具、權限、沙箱、測試、日誌、人工核准與錯誤復原。"},{"question":"上下文工程與 Harness 工程是相同的意思嗎？","answer":"並不相同。上下文工程著重於選擇、搜尋、摘要及配置模型當下需要知道的資訊。Harness 工程除了上下文管理之外，還一併處理權限、工具、驗證、成本限制與營運政策。"},{"question":"迴圈與圖最重要的差異是什麼？","answer":"迴圈定義要重複執行哪些事項，以及何時停止，例如規劃、執行、驗證與修正。圖則定義存在哪些狀態，以及可從一個狀態轉移到哪些其他狀態。一個圖中可以包含一個以上的迴圈。"},{"question":"所有 AI 代理都需要 LangGraph 這類圖框架嗎？","answer":"不需要。單純且簡短的工作，使用單一代理與最精簡的 Harness 便可能已經足夠。當需要條件分支、平行處理、中途儲存、失敗復原、人工核准或稽核執行路徑時，圖的價值就會提高。"},{"question":"多代理的效能總是比單一代理好嗎？","answer":"不是。需要平行調查、不同的專業角色及上下文隔離時，多代理會很有用。若角色重疊或目標模糊，則可能只會增加重複工作、交接錯誤、延遲與成本。"},{"question":"如何防止代理迴圈無限重複？","answer":"除了最大重複次數外，還應設定時間、權杖、工具呼叫及成本預算。必須將沒有新資訊或錯誤未減少的狀態判定為沒有進展，並設計成達到一定標準時便停止或轉交給人工處理。"},{"question":"只審查 AI 所撰寫程式碼的 Pull Request 摘要就可以嗎？","answer":"摘要只是輔助資料，不能取代原始變更。對於驗證、付款、個人資料、資料遷移及部署設定等高風險變更，必須直接審查實際的 diff、測試範圍、相依性及復原程序。"},{"question":"持續注入公司文件，就表示模型已經學習了嗎？","answer":"結果可能會持續改變，但模型權重並未更新。這是透過保留外部文件、搜尋索引、記憶與指示，並在下次執行時再次提供的系統層級調適，必須與嚴格意義上的微調加以區分。"},{"question":"圖工程是回到早期的固定工作流程嗎？","answer":"不一定如此。現代圖較接近混合式控制：在允許代理於部分區段自主規劃並選擇工具的同時，也明確限制高風險的狀態轉移及必要的核准節點。"},{"question":"設計 Harness 時，最先要決定的是什麼？","answer":"應先確定工作的成功標準與失敗成本。接著最好只提供必要的上下文與工具，並設定最小權限、自動驗證、執行日誌、成本上限及停止條件。"}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic — 建構有效的代理","type":"source"},{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"Anthropic — AI 代理的有效情境工程","type":"source"},{"url":"https://www.anthropic.com/engineering/multi-agent-research-system","title":"Anthropic — 我們如何建構多代理研究系統","type":"source"},{"url":"https://docs.langchain.com/oss/python/langgraph/overview","title":"LangGraph 概覽","type":"source"},{"url":"https://arxiv.org/abs/2210.03629","title":"ReAct：在語言模型中協同推理與行動","type":"source"},{"url":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","title":"NIST AI 600-1 — 人工智慧風險管理框架：生成式人工智慧概況","type":"source"}],"images":[{"id":662,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI0NSwicHVyIjoiYmxvYl9pZCJ9fQ==--3a03e254c3d24990df4c3fc46145a5db24e457ba/ai-eb0e40fe.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"중앙 AI 시스템을 순환 화살표와 성공·실패 노드 그래프가 둘러싼 다이어그램","caption":"AI 에이전트의 실행 루프와 보안 검증, 분기 경로를 시각화한 구성도다.","description":null},"en":{"alt":"Central AI system surrounded by loop arrows and a graph of success and failure nodes","caption":"The diagram visualizes an AI agent’s execution loop, security checks, and branching paths.","description":null},"ja":{"alt":"中央のAIシステムを循環矢印と成功・失敗ノードのグラフが囲む図","caption":"AIエージェントの実行ループ、セキュリティ検証、分岐経路を可視化している。","description":null},"es":{"alt":"Sistema de IA central rodeado de flechas cíclicas y una red de nodos de éxito y error","caption":"El diagrama representa el bucle de ejecución, las verificaciones y las rutas de un agente de IA.","description":null},"id":{"alt":"Sistem AI pusat dikelilingi panah berulang dan graf simpul keberhasilan serta kegagalan","caption":"Diagram ini memvisualkan loop eksekusi, pemeriksaan keamanan, dan jalur bercabang agen AI.","description":null},"pt":{"alt":"Sistema central de IA cercado por setas cíclicas e uma rede de nós de sucesso e falha","caption":"O diagrama mostra o ciclo de execução, as verificações de segurança e as rotas de um agente de IA.","description":null},"zh-hant":{"alt":"中央 AI 系統周圍環繞循環箭頭與成功、失敗節點組成的路徑圖","caption":"此圖呈現 AI 代理的執行迴圈、安全檢查與分支路徑。","description":null},"de":{"alt":"Zentrales KI-System, umgeben von Kreispfeilen und einem Netz aus Erfolgs- und Fehlerknoten","caption":"Das Diagramm zeigt Ausführungsschleife, Sicherheitsprüfungen und verzweigte Pfade eines KI-Agenten.","description":null}}},{"id":663,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI1MSwicHVyIjoiYmxvYl9pZCJ9fQ==--cea797c99aabaa4b8f760264327fe2ee8b34b423/ai-23d7d97a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 하네스 속 AI 로봇이 도구 루프와 분기 그래프를 거쳐 검증 및 경고 단계로 이동하는 흐름","caption":"AI 에이전트가 보호된 환경에서 반복 작업과 그래프 분기를 거쳐 사람의 검증을 받는 과정을 보여준다.","description":null},"en":{"alt":"AI robot moves from a secure harness through a tool loop and branching graph to validation and a warning gate","caption":"The diagram shows an AI agent progressing through protected execution, iterative tools, graph branches, and human validation.","description":null},"ja":{"alt":"保護されたAIロボットがツールのループと分岐グラフを経て検証と警告ゲートへ進む流れ","caption":"AIエージェントが保護環境から反復処理、グラフ分岐、人による検証へ進む工程を示している。","description":null},"es":{"alt":"Un robot de IA pasa de un entorno seguro a un bucle de herramientas, un grafo ramificado y una puerta de alerta","caption":"El diagrama muestra a un agente de IA avanzando por ejecución protegida, iteraciones, ramas y validación humana.","description":null},"id":{"alt":"Robot AI bergerak dari lingkungan aman melalui loop alat dan graf bercabang menuju validasi serta gerbang peringatan","caption":"Diagram ini menunjukkan agen AI melalui eksekusi terlindungi, proses berulang, cabang graf, dan validasi manusia.","description":null},"pt":{"alt":"Robô de IA passa de um ambiente seguro por um ciclo de ferramentas e grafo ramificado até validação e alerta","caption":"O diagrama mostra um agente de IA avançando por execução protegida, iterações, ramificações e validação humana.","description":null},"zh-hant":{"alt":"AI 機器人從安全框架經過工具迴圈與分支圖，走向人工驗證及警示閘門","caption":"此圖呈現 AI 代理從受保護執行、反覆工具操作和圖形分支走向人工驗證的流程。","description":null},"de":{"alt":"KI-Roboter durchläuft eine sichere Umgebung, eine Werkzeugschleife und einen verzweigten Graphen bis zur Warnschranke","caption":"Die Grafik zeigt einen KI-Agenten bei geschützter Ausführung, iterativen Abläufen, Graphverzweigungen und menschlicher Prüfung.","description":null}}}],"published_at":"2026-08-16T00:45:12+09:00","updated_at":"2026-08-16T00:45:12+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-agent-harness-loop-graph-engineering"}