---
title: "依序理解 AI 代理的執行框架、迴圈與圖工程"
locale: zh-hant
category: knowledge_base
category_name: "知識庫"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-agent-harness-loop-graph-engineering
published_at: 2026-08-16T00:45:12+09:00
---

# 依序理解 AI 代理的執行框架、迴圈與圖工程

> 執行框架設計代理的工作環境與控制機制，迴圈設計重複與終止規則，圖則設計允許的狀態與轉移路徑。這三個術語並非公認的標準分類，更準確的理解是：它們是處理 AI 代理自主性與風險的實務觀點。

## Key Points

- 執行框架工程是將模型之外的情境、工具、權限、驗證、日誌與核准程序設計為一套完整的執行環境。
- 迴圈工程定義代理反覆進行規劃、執行、驗證與修正的條件、預算及終止標準。
- 圖工程利用狀態與轉移規則，明確限制或調整代理可選擇的路徑。
- 對多數組織而言，相較於複雜的多代理圖，優先改善單一代理的執行框架與評估體系更有效率。
- 僅核准 AI 產生的摘要報告，對高風險程式碼並不足夠；還必須一併驗證測試、變更範圍、安全邊界與原始產出。

隨著 AI 代理開始承擔長期任務，僅靠寫好提示詞已難以獲得穩定的結果。因為還必須設計代理要查看哪些資訊、使用哪些工具、何時重複、沿著哪條路徑移動，以及在哪裡必須取得人員核准。

說明這個問題時，經常出現的說法是 **Harness 工程**、**迴圈工程**、**圖工程**。它們不是國際標準或經過嚴格共識形成的學術分類。彼此之間有所重疊，其含義也可能因產品與開發團隊而異。因此，與其把它們當作各年度的流行語來背誦，不如依照各自試圖回答的控制問題加以區分。

## 三個概念一覽比較

| 概念 | 核心問題 | 主要設計對象 | 代表性的故障防範機制 |
|---|---|---|---|
| Harness 工程 | 代理在什麼環境與規則內工作？ | 上下文、工具、權限、沙箱、Hook、日誌、核准、評估 | 最小權限、危險命令核准、執行測試、篩選上下文 |
| 迴圈工程 | 要重複什麼，何時停止？ | 規劃·執行·驗證週期、事件處理、重試、預算、終止條件 | 最大重複次數、時間·Token 限制、進展判定、失敗時移交 |
| 圖工程 | 允許哪些狀態與路徑？ | 節點、狀態、轉移、分支、平行處理、檢查點 | 禁止轉移、狀態驗證、核准節點、復原路徑 |

簡單來說，**Harness 是環境與邊界**，**迴圈是重複規則**，**圖是可能路徑的結構**。在實際系統中，迴圈可以位於圖的某個節點內，而整張圖也可以在一個 Harness 內執行。

## 代理控制方式如何演變

### 早期代理：預先定義的工作流程補足了自主性

早期的生成式 AI 代理在長期任務中，經常忘記目標、重複錯誤的工具呼叫，或產生缺乏依據的結果。為此，開發者將大型任務拆分為較小的步驟，並固定各步驟的輸入與輸出。

在這種方式中，由人員將整體程序撰寫成鏈、流程圖或狀態機，而 LLM 則負責分類、擷取、摘要、撰寫草稿等受限任務。LangGraph 等框架可在維持狀態的同時，用來表達分支、循環、檢查點與人員介入。

不過，以圖為基礎的協調並不是在某個特定年份結束的過時方式。即使在目前，對於可稽核性、可重現性、法規遵循或精確復原程序相當重要的業務，明確的圖仍然適合。

### 模型效能提升：從固定路徑轉向動態使用工具

隨著工具使用與推理能力改善，單一代理已能依情況選擇搜尋、編輯程式碼、測試、讀取檔案等行動。ReAct 類方法是交替執行推理、行動與觀察的代表性結構。

這項變化減輕了人員必須預先編寫所有分支的負擔。另一方面，管理代理讀取的資訊、擁有的權限、執行成本與錯誤復原方式，變得更加重要。此時，上下文工程與 Harness 工程開始進入實務核心。

### 長期任務與多代理：迴圈與圖的重新結合

在長期任務中，反覆進行規劃、執行與驗證，比單次模型呼叫更重要。當多個代理參與時，也必須明確指定角色、產出格式、權限與終止條件。同時，若完全放任自主迴圈，可能發生成本暴增、無限重試、獎勵駭取與錯誤目標最佳化。

因此，現代代理系統的設計方向不是消除自主性，而是**結合允許自主性的區段與採取確定性控制的區段**。這不是單純回歸過去的固定鏈，而是以狀態、轉移與政策包圍彈性執行。

這些變化與其說是精確的時間表，不如說是設計重點的轉變。圖、迴圈與 Harness 從一開始便共存，現在也仍然搭配使用。

## Harness 工程處理的內容

Harness 不是基礎模型本身，而是**圍繞模型、使其得以執行實際業務的運行體系**。即使使用相同模型，成功率、成本、安全性與可重現性也可能因 Harness 而有很大差異。

### Harness 的主要構成要素

1. **指示體系**：系統指示、儲存庫規則、程式碼標準、優先順序與禁止行為
2. **上下文供應**：搜尋、檔案選擇、摘要、記憶，以及在需要時注入文件
3. **工具介面**：檔案編輯、終端機、瀏覽器、資料庫、外部 API
4. **權限與隔離**：讀寫範圍、機密資訊存取、網路限制、沙箱
5. **驗證機制**：測試、Linter、型別檢查、Schema 驗證、事實查核
6. **人員核准**：對部署、付款、刪除、外部傳輸等難以復原的行為進行核准
7. **可觀察性**：呼叫紀錄、成本、延遲時間、錯誤、變更內容、決策依據
8. **復原政策**：重試、還原先前狀態、中止任務、移交負責人

Claude Code 的專案指示檔案或 Hook，可視為 Harness 構成要素的案例。然而，某項特定產品功能並不代表整個 Harness。

### 與上下文工程的差異

上下文工程會最佳化要在目前的模型呼叫中放入哪些資訊與指示。這包括透過搜尋只取得相關文件、摘要舊對話、將任務狀態儲存到外部檔案，以及依子任務分離上下文等。

Harness 工程的範圍更廣。除了上下文，也處理工具權限、執行環境、核准、驗證、日誌紀錄與成本限制。因此，上下文工程雖是 Harness 的核心部分，但將兩者完全視為同義並不精確。

## 迴圈工程的核心是終止條件

迴圈讓代理在產生結果後進行檢查，若有所不足便再次嘗試。重要的不是重複本身，而是**進展的定義與中止條件**。

### 代表性的迴圈類型

- **驗證迴圈**：產生草稿後，以測試或評估標準檢查，並修正未通過的項目。
- **事件驅動迴圈**：在電子郵件、通知、程式碼變更、感測器資料等外部事件發生時開始任務。
- **探索迴圈**：調查多個假設或資料來源，並在證據足夠前持續調整探索範圍。
- **改善迴圈**：根據先前結果與評估值選擇下一個策略。若只最佳化單一分數，可能發生獎勵駭取，因此需要多項評估標準與人員審查。
- **復原迴圈**：分類錯誤原因，在允許範圍內重試，若仍無法解決便交由人員處理。

### 安全迴圈所需的契約

代理之間的契約不是法律契約，而是明確規定輸入、輸出與責任的執行規格。建議包含下列項目。

| 契約項目 | 應明確指定的內容 |
|---|---|
| 目標 | 必須完成的結果與排除範圍 |
| 輸入 | 可使用的資料、時效性、可信度 |
| 輸出 | JSON Schema、文件格式、必要依據與測試結果 |
| 權限 | 允許的工具、檔案範圍、外部傳輸與變更權限 |
| 驗證 | 必須通過的測試與評估標準 |
| 預算 | Token、時間、呼叫次數、平行任務數量 |
| 終止 | 成功、無進展、預算耗盡、偵測到風險的條件 |
| 移交 | 失敗時由哪位人員或哪個代理接手 |

如果完成條件模糊，代理可能只是改寫句子或重複相同搜尋，卻仍判斷任務正在取得進展。與其只設定最大重複次數，不如同時觀察結果品質、新資訊的增加量、錯誤變化與成本。

## 圖工程將自主性的邊界結構化

圖會以節點與連線表示任務。節點可以是模型呼叫、工具執行、人員核准或驗證流程，而連線則表示依狀態決定的下一項行動。

### 鏈與圖的差異

- **鏈**適合從 A 到 B、再從 B 到 C 的線性程序。
- **圖**適合需要條件分支、重複、平行執行、失敗復原與中途儲存的任務。
- **動態圖**由模型在執行期間提出下一個子任務或路徑。
- **受限圖**即使由模型選擇，也只能在允許的節點與轉移範圍內移動。

現代圖設計的目的，不是讓人員預先決定所有行為，而是將**必須遵守的不變條件**放入結構中，例如在刪除資料前必須經過核准節點，或在測試失敗狀態下不得轉移到部署狀態。

### 需要圖的訊號

若符合下列多項條件，就值得考慮採用明確的圖。

- 失敗後應返回的復原點很明確。
- 存在必須取得人員核准的步驟。
- 必須平行執行多項任務後合併結果。
- 可用的工具或權限會依狀態而異。
- 必須稽核或重現完整執行路徑。
- 單一代理迴圈重複相同失敗。

若連單純的文件摘要或單次資料轉換都製作成圖，可能只會增加複雜性。

## 實務套用順序：從 Harness 開始，依需要擴充

對大多數團隊而言，以下順序較為實際。

1. **確定單一任務與成功標準。** 先蒐集輸入、預期輸出與失敗案例。
2. **建立最小 Harness。** 只提供必要的上下文與工具，並設定權限、測試、日誌與成本上限。
3. **建立評估集。** 除了正常案例，也應包含模糊要求、錯誤文件、工具錯誤與超越權限的嘗試。
4. **將需要重複的部分做成迴圈。** 只在驗證與修正確實能提升品質的區段允許重試。
5. **在分支與復原變得複雜時升級為圖。** 明確指定狀態與轉移，並在危險行為前設置核准節點。
6. **僅在工作拆分確實有益時使用多代理。** 若不需要平行探索或不同專業角色，單一代理可能更簡單且更便宜。

## 程式設計與研究中的套用差異

| 項目 | 程式設計任務 | 研究任務 |
|---|---|---|
| 可驗證性 | 測試、建置、型別檢查等自動驗證相對容易 | 必須綜合判斷來源品質、遺漏與相互矛盾的證據 |
| 動態探索的價值 | 若變更範圍明確，價值可能有限 | 在多種搜尋路徑與假設比較中價值較大 |
| 主要風險 | 錯誤變更、安全漏洞、只為通過測試而寫的程式碼 | 缺乏來源的主張、重複資料、確認偏誤 |
| 適合的控制 | 限制儲存庫範圍、測試、diff 審查、部署核准 | 來源紀錄、獨立搜尋、尋找反面證據、引用驗證 |

不能斷言動態工作流程在程式設計中總是缺乏效率，而在研究中總是有利。可進行測試的大規模遷移可能適合自主代理，而答案明確的事實查詢，採用固定研究程序可能更有效率。關鍵變數不是領域，而是**目標的明確程度、自動驗證的可能性、探索空間與錯誤成本**。

## 程式碼審查不會消失，而是審查單位改變

當代理撰寫程式碼時，開發者不再需要直接輸入每一行，而會更多地負責監督需求、設計、測試結果、變更範圍與風險。Pull Request 摘要與代理報告可以提升審查速度。

然而，只閱讀摘要便核准的方式並不是安全的預設選項。代理遺漏的變更或錯誤理解的邏輯，也可能不會出現在摘要中。在下列情況下，必須直接審查原始 diff 與相關程式碼。

- 驗證、付款、個人資料、加密、存取控制變更
- 資料庫 Schema 變更或不可逆的遷移
- 對效能與並行處理敏感的程式碼
- 超出測試範圍的大規模重構
- 外部相依項目、部署設定、機密資訊處理變更
- 代理的說明與實際 diff 不一致時

Human-in-the-loop 並不是由人員形式化地按下按鈕。它還包括提供變更證據、測試結果、失敗可能性與復原程序，讓人員能夠做出判斷。

## 常見陷阱

### 沒有目的的多代理

增加代理會產生角色協調、重複呼叫、上下文傳遞與結果合併的成本。如果不需要從不同觀點進行平行探索，也沒有必須分離上下文的理由，單一代理會更好。

### 無限制的動態工作流程

若允許代理持續建立子任務，Token 與工具呼叫成本會迅速增加。成本大致由各步驟的輸入·輸出 Token 成本、工具成本、平行代理數量與重複次數的總和決定。必須分別限制呼叫次數、同時執行數量、總預算與最長執行時間。

### 只最佳化一項評估指標

若只將測試通過率設為目標，可能出現削弱測試或隱藏例外處理等錯誤最佳化。應同時使用品質、安全性、變更規模、成本、延遲時間與人員評估。

### 將文件注入與微調混為一談

透過文件搜尋或專案指示，可以持續改變結果，但模型權重並不會改變。廣義而言，這可以解釋為系統的學習效果；但嚴格來說，這是利用外部記憶與上下文進行調適。必須保存文件或搜尋索引，才能在下次執行時繼續維持變化。

## 營運階段容易忽略的評估、安全性與經濟性

代理設計不會止於架構圖。在實際營運中，比起**允許了什麼，更重要的是建立衡量實際發生了什麼的體系**。

### 最低營運指標

- 任務成功率與人員修改率
- 每項任務的模型·工具成本與總執行時間
- 重複次數與未取得進展便消耗的呼叫比例
- 核准請求、拒絕、超越權限嘗試的次數
- 錯誤工具呼叫與復原成功率
- 未提供來源或測試便提交的結果比例
- 相同輸入下結果產生差異的程度

### 安全上所需的不變條件

- 外部文件中的指示不得擁有高於系統政策的優先順序。
- 不應在模型輸入與日誌中不必要地暴露機密資訊。
- 將讀取權限與寫入·刪除·部署權限分開。
- 對外部傳輸與不可逆行為設置額外核准或政策檢查。
- 不允許代理任意修改自身的評估標準、測試或稽核日誌。

相較於提示詞中的一句話，透過沙箱、存取控制、圖轉移與獨立驗證器強制執行這些不變條件會更安全。生成式 AI 風險管理不僅應涵蓋模型準確度，也必須包含營運環境、人員監督與事故應變。

## 應該先學習哪個概念

目前在實務上最先應掌握的是 Harness 工程。具備精確的上下文、最小權限、自動驗證、日誌、核准與成本上限，就能減少單一代理的許多失敗。

接著，在重複有助於提升品質的任務中加入具有終止條件的迴圈。當分支、平行處理、復原與核准程序變得複雜時，再以圖明確表示。相較於採用複雜術語，更應優先將代理的目標、權限、證據、成本與中止條件轉換為可衡量的形式。

## FAQ

### Harness 工程與提示工程有何不同？
提示工程主要處理要傳達給模型的指示與表達方式。Harness 工程則是更廣泛的執行環境設計，除了提示之外，還包括上下文搜尋、工具、權限、沙箱、測試、日誌、人工核准與錯誤復原。

### 上下文工程與 Harness 工程是相同的意思嗎？
並不相同。上下文工程著重於選擇、搜尋、摘要及配置模型當下需要知道的資訊。Harness 工程除了上下文管理之外，還一併處理權限、工具、驗證、成本限制與營運政策。

### 迴圈與圖最重要的差異是什麼？
迴圈定義要重複執行哪些事項，以及何時停止，例如規劃、執行、驗證與修正。圖則定義存在哪些狀態，以及可從一個狀態轉移到哪些其他狀態。一個圖中可以包含一個以上的迴圈。

### 所有 AI 代理都需要 LangGraph 這類圖框架嗎？
不需要。單純且簡短的工作，使用單一代理與最精簡的 Harness 便可能已經足夠。當需要條件分支、平行處理、中途儲存、失敗復原、人工核准或稽核執行路徑時，圖的價值就會提高。

### 多代理的效能總是比單一代理好嗎？
不是。需要平行調查、不同的專業角色及上下文隔離時，多代理會很有用。若角色重疊或目標模糊，則可能只會增加重複工作、交接錯誤、延遲與成本。

### 如何防止代理迴圈無限重複？
除了最大重複次數外，還應設定時間、權杖、工具呼叫及成本預算。必須將沒有新資訊或錯誤未減少的狀態判定為沒有進展，並設計成達到一定標準時便停止或轉交給人工處理。

### 只審查 AI 所撰寫程式碼的 Pull Request 摘要就可以嗎？
摘要只是輔助資料，不能取代原始變更。對於驗證、付款、個人資料、資料遷移及部署設定等高風險變更，必須直接審查實際的 diff、測試範圍、相依性及復原程序。

### 持續注入公司文件，就表示模型已經學習了嗎？
結果可能會持續改變，但模型權重並未更新。這是透過保留外部文件、搜尋索引、記憶與指示，並在下次執行時再次提供的系統層級調適，必須與嚴格意義上的微調加以區分。

### 圖工程是回到早期的固定工作流程嗎？
不一定如此。現代圖較接近混合式控制：在允許代理於部分區段自主規劃並選擇工具的同時，也明確限制高風險的狀態轉移及必要的核准節點。

### 設計 Harness 時，最先要決定的是什麼？
應先確定工作的成功標準與失敗成本。接著最好只提供必要的上下文與工具，並設定最小權限、自動驗證、執行日誌、成本上限及停止條件。

## Sources

- [Anthropic — 建構有效的代理](https://www.anthropic.com/research/building-effective-agents)
- [Anthropic — AI 代理的有效情境工程](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Anthropic — 我們如何建構多代理研究系統](https://www.anthropic.com/engineering/multi-agent-research-system)
- [LangGraph 概覽](https://docs.langchain.com/oss/python/langgraph/overview)
- [ReAct：在語言模型中協同推理與行動](https://arxiv.org/abs/2210.03629)
- [NIST AI 600-1 — 人工智慧風險管理框架：生成式人工智慧概況](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)

## Images

![中央 AI 系統周圍環繞循環箭頭與成功、失敗節點組成的路徑圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI0NSwicHVyIjoiYmxvYl9pZCJ9fQ==--3a03e254c3d24990df4c3fc46145a5db24e457ba/ai-eb0e40fe.webp)
![AI 機器人從安全框架經過工具迴圈與分支圖，走向人工驗證及警示閘門](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI1MSwicHVyIjoiYmxvYl9pZCJ9fQ==--cea797c99aabaa4b8f760264327fe2ee8b34b423/ai-23d7d97a.webp)