---
title: "提示、上下文、作業框架、代理式、迴圈工程的差異與設計法"
locale: zh-hant
category: comparison
category_name: "比較分析"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/prompt-context-harness-agentic-loop-engineering
published_at: 2026-07-16T17:00:54+09:00
---

# 提示、上下文、作業框架、代理式、迴圈工程的差異與設計法

> 提示、上下文、作業框架、代理式、迴圈工程分別處理指示、資訊、作業環境、自主執行與反覆改善。本文從實務角度說明這五種方式的界線與結合結構、適用順序、驗證指標與防止失敗的方法。

## Key Points

- 提示工程是讓目標、限制、範例、輸出契約與成功標準變得明確的工作。
- 上下文工程管理AI在當前判斷中所使用資訊的相關性、即時性、來源與權杖效率。
- 作業框架工程透過工具、權限、沙盒、文件結構、驗證器與日誌，打造讓AI能穩定工作的環境。
- 代理式工程是在受限範圍內，將達成目標所需的下一步行動與工具選擇委託給AI。
- 迴圈工程連結生成、驗證、原因分析、修正、重新執行與結束條件，使結果收斂。

若把提升生成式 AI 品質的工作都概括為「把提示詞寫好」，就很難準確診斷失敗原因。提示詞、脈絡、Harness、代理式、迴圈工程並不是彼此替代的流行語，而是處理**請求表達、資訊選擇、執行環境、自主決策、反覆改善**這些不同控制面的互補性設計方式。

## 五個概念的核心定義

| 區分 | 核心問題 | 主要設計對象 | 代表產出物 | 代表成功標準 |
|---|---|---|---|---|
| 提示詞工程 | 要如何指示 AI 做事？ | 指示語、限制、範例、輸出格式 | 提示詞範本、範例輸入·輸出 | 指示遵循率、格式準確度、第一版結果品質 |
| 脈絡工程 | 現在要讓 AI 看到什麼？ | 系統指引、搜尋文件、對話狀態、記憶、工具結果 | 脈絡組裝規則、搜尋·摘要政策 | 相關性、時效性、有根據性、權杖效率 |
| Harness 工程 | 要建立什麼樣的工作環境，讓 AI 不容易犯錯？ | 工具、權限、沙盒、儲存庫結構、驗證器、日誌 | 工作規則、工具介面、測試·CI、執行手冊 | 可重現性、安全性、可驗證性、可復原性 |
| 代理式工程 | 下一步行動由誰、在什麼範圍內決定？ | 目標、計畫、工具選擇、狀態轉移、委派 | 代理程式迴圈、編排、核准節點 | 任務完成率、適當的工具選擇、人類介入率 |
| 迴圈工程 | 第一個結果錯了時，要如何收斂？ | 生成、評估、原因分類、修改、重新執行、終止條件 | 評估器、迴歸測試、重試政策、失敗分類 | 第一版通過率、復原率、反覆次數、最終通過率 |

把五個概念連成一句話如下。

**表達請求 → 顯示必要資訊 → 提供安全的工作環境 → 讓 AI 選擇下一步行動 → 驗證並改善，直到結果通過標準。**

### 解讀術語時的注意事項

提示詞工程和代理程式是相對廣泛使用的術語，但 Harness 工程目前的使用範圍仍會因脈絡而異。有些文章把模型以外幾乎所有執行層都稱為 Harness，有些文章則把它縮小解釋為編碼代理程式使用者在儲存庫外部建立的規則·驗證·回饋結構。「迴圈工程」也與其說是由單一標準固定下來的正式分類，不如理解為把生成與驗證設計成封閉式回饋流程的實務名稱會更準確。([OpenAI][1])

## 1. 提示詞工程：設計指示的品質

提示詞工程是讓傳達給模型的指示變得明確且可驗證的工作。它通常在一次請求與回應中產生最明顯的效果，但也適用於系統訊息或多輪對話規則。

好的提示詞通常會分離以下要素。

- **目標：** 必須完成什麼
- **輸入：** 分析對象和輸入邊界到哪裡為止
- **限制：** 不該做的事、允許範圍、長度與格式
- **輸出契約：** JSON、表格、程式碼修補等結果結構
- **成功標準：** 滿足什麼條件才可視為正解
- **不確定性處理：** 資訊不足或互相衝突時要如何處理
- **範例：** 展示預期行為的代表性輸入·輸出

實務範本可以像下面這樣簡單開始。

```text
目標：
輸入：
限制：
輸出格式：
成功標準：
驗證方法：
不確定時的處理：
代表範例：
```

重要的是，在打磨提示詞之前，必須先定義成功標準和經驗性測試方法。並非所有失敗都能透過修改提示詞解決，成本、延遲時間、工具錯誤、錯誤的資料選擇都可能是其他層級的問題。([Claude Platform Docs][2])

### 提示詞工程善於解決的問題

- 結果格式經常破壞的問題
- 指示優先順序模糊的問題
- 分類、擷取、轉換、摘要等輸入與輸出相對明確的問題
- 提供代表範例後效能會穩定的問題

### 只靠提示詞難以解決的問題

- 必要事實或檔案不在輸入中的情況
- 混入過時或互相衝突的文件時
- 必須安全地查詢·修改外部系統時
- 需要多個步驟的執行狀態與失敗復原時
- 沒有客觀方法檢查結果是否正確時

## 2. 脈絡工程：設計 AI 看到的資訊

脈絡工程是在模型生成答案的瞬間，選擇、排序、壓縮、更新可使用資訊整體的工作。脈絡不只包含提示詞，也可能包含系統指引、使用者請求、對話歷史、搜尋文件、記憶、工具說明、工具執行結果、目前時間、權限狀態與工作進度狀態。

脈絡視窗是有限的，因此目標不是「放很多」，而是**在適當時機放入必要資訊**。Anthropic 將脈絡說明為代理程式重要但有限的資源，並建議在長時間互動中採用最小工具集合、代表範例、執行時搜尋、壓縮與記憶等策略。([Anthropic][3])

### 核心設計原則

1. **相關性優先：** 只放入目前階段所需的資訊。
2. **來源與時效性：** 一併管理文件的撰寫時間、版本、擁有者、可信度。
3. **即時搜尋：** 與其預先注入所有資料，不如在需要時從檔案·DB·搜尋系統取得。
4. **資訊分層：** 區分固定規則、目前任務、參考資料、工具結果。
5. **衝突處理：** 多份資料不同時，明示優先順序與基準來源。
6. **壓縮與狀態保存：** 摘要舊對話，但不要丟失決策、未解決問題、依據連結。
7. **指示與資料分離：** 設定邊界，避免把網頁或文件中的句子當成系統命令處理。

### 範例

當客戶支援 AI 回答退款政策時，即使只強化「請準確回答」這個提示詞也有其限制。正確的脈絡工程會在必要瞬間查詢並一併提供客戶的國家、購買日、商品類型、目前政策版本、例外條款、訂單狀態，並讓回答中使用的政策條款可被追蹤。

## 3. Harness 工程：設計 AI 工作的環境

Harness 是把模型智慧連接到實際業務的執行骨架。Harness 工程是透過文件、工具、權限、結構、自動驗證與回饋，設計工作環境，以預防 AI 經常犯的錯誤或及早發現錯誤。

### Harness 的主要組成要素

| 組成要素 | 角色 | 範例 |
|---|---|---|
| 工作指引 | 明示重複業務的程序與禁止事項 | `AGENTS.md`、執行手冊、檢查清單 |
| 知識結構 | 讓 AI 容易找到所需資料 | 儲存庫地圖、ADR、術語表、範例集合 |
| 工具介面 | 明確限制行動的輸入·輸出 | 檔案搜尋、DB 查詢、程式碼執行、部署 API |
| 執行環境 | 隔離失敗並提高可重現性 | 沙盒、容器、固定相依性 |
| 驗證器 | 自動確認結果是否滿足標準 | 結構描述檢查、單元測試、linter、政策檢查 |
| 權限·核准 | 限制危險行動 | 最小權限、讀取/寫入分離、人類核准 |
| 可觀測性 | 記錄看到了什麼、做了什麼行動 | 追蹤、日誌、工具呼叫記錄、成本 |
| 復原結構 | 失敗後安全回復並重新開始 | 檢查點、回滾、重試預算 |

OpenAI 的 Harness 工程案例把工程師的角色說明為不只是寫程式碼，而是設計環境、意圖、儲存庫知識、測試·驗證·審查·復原迴圈。核心不是重新請求 AI「再努力一點」，而是把不足的能力與訊號明確加入環境中。([OpenAI][1])

### 資料結構範例

```text
/ai
  /instructions   # 共通規則與各角色指引
  /skills         # 重複工作程序
  /examples       # 好結果與壞結果
  /evals          # 評估資料與評分規則
  /policies       # 權限、安全、核准政策
  /runbooks       # 障礙·例外應對
```

這個結構本身並不是正解。重要的是資料是否維持最新狀態、重複·衝突是否少、AI 是否能在需要時找到，以及規則是否能連到自動檢查。

## 4. 代理式工程：給予目標與工具，委派下一步行動

代理式工程是把目標、工具、工作狀態與邊界條件交給 AI，並讓它在一定範圍內自行選擇為達成目標所需下一步的設計。

Anthropic 將**工作流程**區分為以預先決定的程式碼路徑協調 LLM 與工具的系統，將**代理程式**區分為模型動態決定自身流程與工具使用的系統。OpenAI 也將代理程式說明為由 LLM 管理工作流程執行，並動態選擇與外部系統互動工具的系統。([Anthropic][4])

### 基本代理程式迴圈

1. 觀察目前目標與狀態。
2. 規劃下一個子目標或行動。
3. 選擇工具並執行。
4. 確認結果與環境變化。
5. 在完成、修改、重試、轉交人類之中決定一項。

### 適合使用代理程式的情況

- 工作順序會因輸入而異的情況
- 必須解讀自然語言、文件、程式碼等非結構化資訊的情況
- 必須選擇性使用多個工具的情況
- 需要根據中間結果改變計畫的情況
- 失敗原因多樣且可進行一定程度復原的情況

### 代理程式過度的情況

- 規則與順序固定的簡單自動化
- 可用單一 API 呼叫或 SQL 明確解決的業務
- 沒有驗證手段且錯誤成本非常高的業務
- 未經核准就執行付款、刪除、部署等難以回復行動的結構
- 單一代理程式已足夠，卻只是增加角色的多代理程式結構

自主性不是二分法。可以分為只做推薦的輔助型、只允許有限讀取·寫入的執行型、每個主要階段都取得核准的監督型、在低風險範圍內長時間運作的高自主型。必須配合業務風險與驗證能力，分階段擴大。

## 5. 迴圈工程：設計可驗證的改善過程

迴圈工程不是單純的重試。它是把**生成 → 驗證 → 失敗原因分析 → 修改策略選擇 → 重新執行 → 終止判斷**做成明確的封閉式回饋系統。

### 正確迴圈的構成

1. **候選生成：** 產生草稿、程式碼、計畫、資料轉換結果。
2. **驗證：** 執行測試、結構描述、參考資料、政策、依據檢查。
3. **原因分類：** 區分指示錯誤、脈絡遺漏、工具失敗、實作缺陷、評估器缺陷。
4. **修改：** 套用符合失敗原因的最小變更。
5. **重新執行：** 不要從頭重複整體，而是從必要階段重新執行。
6. **終止：** 在通過、最大反覆次數、成本上限、時間上限、不確定性臨界值之中任一條件下停止。
7. **迴歸保護：** 確認新的修改沒有破壞既有成功案例。

代理程式評估比只看輸入與輸出的單回合評估更複雜。代理程式會多次呼叫工具並改變環境狀態，因此不只最終結果，也必須一併檢查流程與環境變化。自動評估的核心是給予輸入，並將評分邏輯套用到輸出或改變後的狀態。([Anthropic][5])

### 驗證器的優先順序

- **決定性驗證：** 編譯、單元測試、結構描述、數學限制、權限檢查
- **參考式驗證：** 基準資料、原文引用、資料庫對照
- **規則式驗證：** 禁用詞、必填欄位、政策條件
- **模型式評估：** 文體、語意保留、綜合品質等難以規則化的項目
- **人類評估：** 高風險判斷、目標本身的妥當性、例外核准

可以的話先使用決定性驗證，不要只用模型評估讓模型為自己的結果評分。使用模型評估時，應同時設置評估標準、範例、偏誤檢查、樣本人類審查。

## 五種方式是層級，不是替代品

在實際系統中，五種方式會一起運作。

- 提示詞建立**目前行動的契約**。
- 脈絡提供**判斷所需的狀態與依據**。
- Harness 提供**可行動的環境與安全裝置**。
- 代理式設計分配**下一步行動的選擇權**。
- 迴圈設計**發現錯誤並收斂品質**。

因此，像是「脈絡工程已取代提示詞工程」或「用了代理程式就不需要工作流程」這類理解並不準確。更寬的層級只是包含或運用較窄的層級，而對於簡單問題，簡單設計可能更穩定。

## 實務範例：修正 bug 的 AI 編碼系統

假設 AI 要修正「登入後只有特定使用者發生 500 錯誤」這個 bug。

### 提示詞工程

- 確認錯誤重現條件。
- 不要變更公開 API。
- 以最小修改解決。
- 修改後回報測試結果與剩餘風險。

### 脈絡工程

- 議題說明與錯誤日誌
- 相關請求追蹤 ID
- 與認證·使用者模型相關的檔案
- 最近變更紀錄
- 架構規則與編碼標準
- 失敗的測試與執行環境資訊

### Harness 工程

- 儲存庫搜尋、檔案讀取·編輯、測試執行工具
- 隔離的分支與沙盒
- formatter、linter、單元·整合測試
- 禁止變更區域與權限政策
- 所有命令與檔案變更的日誌
- 失敗時的回滾與檢查點

### 代理式工程

AI 會依情況選擇重現、建立假設、探索相關程式碼、修補、測試、摘要結果的順序。不過部署或資料變更需要人類核准。

### 迴圈工程

測試失敗時，不是重複相同命令，而是分類失敗類型。如果是重現失敗，就補強脈絡收集；如果是迴歸失敗，就縮小修補；如果是環境錯誤，就復原相依性與設定。當所有必要測試通過且留下變更依據時即終止。

## 依問題症狀找出需要哪種工程的方法

| 症狀 | 優先檢查的領域 |
|---|---|
| 輸出格式或文體經常偏離 | 提示詞 |
| 回答缺少必要事實·檔案 | 脈絡 |
| 選錯工具或執行危險命令 | Harness 與權限設計 |
| 有許多難以用固定順序處理的變形 | 代理式設計 |
| 第一個結果經常錯，但可自動判定 | 迴圈與評估器 |
| 無法得知失敗原因且難以重現 | Harness 的可觀測性 |
| 越反覆成本越增加，但品質沒有改善 | 原因分類、驗證訊號、終止條件 |
| 資料越多，答案反而越差 | 脈絡整理與搜尋政策 |

## 建議建置順序

### 第 1 階段：先建立成功標準與評估集

收集代表業務、困難案例、禁止案例，並定義如何判定結果。若沒有正解資料，至少要建立結構描述、必要依據、政策遵循、人類評估標準。

### 第 2 階段：建立單次呼叫基準線

用最簡單的提示詞與必要的最小脈絡，測量效能、成本、延遲時間。若沒有基準線就導入代理程式，會很難區分複雜性帶來的效果。

### 第 3 階段：量測脈絡供應

記錄哪些文件與工具結果被放入、它們有多舊、是否實際用於回答。區分搜尋失敗與過度脈絡。

### 第 4 階段：建立最小 Harness

減少工具數量，並明確化名稱與輸入。優先處理沙盒、最小權限、自動測試、日誌、檢查點。

### 第 5 階段：賦予有限自主性

讓單一代理程式先從以讀取為主的低風險業務開始執行。明示終止條件與轉交人類條件，寫入·刪除·付款·部署權限則另行核准。

### 第 6 階段：閉合驗證·復原迴圈

連接失敗分類、修改策略、最大反覆次數、成本上限、迴歸測試。只有在成功率穩定後，才擴大工具與自主範圍。

## 營運指標

沒有普遍適用的目標數值，因此必須配合業務風險與成本制定標準。

| 指標 | 意義 |
|---|---|
| 任務完成率 | 滿足最終成功標準的比例 |
| 第一版通過率 | 不需反覆修改、一開始就通過的比例 |
| 復原率 | 第一次失敗後透過迴圈成功的比例 |
| 平均反覆次數 | 到成功或中止為止所需的循環數 |
| 工具選擇錯誤率 | 不適當或不必要的工具呼叫比例 |
| 依據完整性 | 核心主張具有可追蹤來源的比例 |
| 人類介入率 | 需要核准、修改、重新指示的比例 |
| 單位成功成本·延遲 | 完成一個成功任務所耗費的資源 |
| 安全事件數 | 權限違反、錯誤寫入、不可逆行動發生數 |
| 迴歸失敗率 | 新變更破壞既有成功案例的比例 |

## 常見設計錯誤

| 領域 | 錯誤 | 改善方法 |
|---|---|---|
| 提示詞 | 把所有例外累積在一句話中 | 結構化規則，並分離代表範例與評估 |
| 提示詞 | 沒有成功標準，只指示「好好撰寫」 | 明示格式、必要內容、禁止事項、判定標準 |
| 脈絡 | 把不相關文件全部放入 | 使用執行時搜尋與分階段脈絡 |
| 脈絡 | 同時提供舊政策與最新政策 | 管理版本·有效日·基準來源 |
| Harness | 提供許多功能重疊的工具 | 設計最小工具集合與明確參數 |
| Harness | 沒有寫入權限與回復功能 | 設置最小權限、沙盒、檢查點 |
| 代理式 | 一開始就建立多代理程式 | 先從單一代理程式與決定性工作流程開始驗證 |
| 代理式 | 讓它在沒有完成條件下持續執行 | 設置明確終止·預算·轉交條件 |
| 迴圈 | 原樣重複相同請求 | 分類失敗原因並改變修改位置 |
| 迴圈 | 用一個生成模型自我評估所有結果 | 結合決定性檢查、參考對照、人類樣本審查 |

## 實作檢查清單

- [ ] 成功條件不只以句子描述，也能在可行範圍內由機器檢查嗎？
- [ ] 提示詞、參考資料、工具結果的優先順序是否已分離？
- [ ] 是否能追蹤文件的來源、版本、有效日與擁有者？
- [ ] 工具名稱與參數是否不互相重疊且明確？
- [ ] 讀取、寫入、刪除、付款、部署權限是否依風險程度分離？
- [ ] 是否有隔離失敗的沙盒與回復手段？
- [ ] 是否以可重現的形式記錄所有重要行動與工具呼叫？
- [ ] 是否有測試、結構描述、政策檢查等外部驗證器？
- [ ] 最大反覆次數、成本、時間、人類轉交條件是否已定義？
- [ ] 是否有不讓新改善破壞既有案例的迴歸評估？

## 結論

好的 AI 系統不是擁有最長提示詞的系統。它是能分辨失敗發生在**指示**、**資訊**、**環境**、**決策**、**驗證·復原**之中的哪一處，並在該層級配置最簡單解決方案的系統。先建立成功標準與單次呼叫基準線，只在必要程度補強脈絡與 Harness，接著在可驗證的範圍內擴大自主性與反覆迴圈，才是穩定的方法。

## FAQ

### 五種工程方式是否必須按順序導入？
它們不是固定的成熟度階段。不過，在建立成功標準與單次呼叫基準線後，整理提示詞與上下文，並在需要時加入工具框架、自主性與迭代迴圈，會更容易衡量複雜性所帶來的效果。

### 上下文工程會取代提示詞工程嗎？
不會取代。提示詞定義應執行的行為與輸出契約，而上下文則提供該行為所需的事實、狀態與依據。好的系統會將兩者一起設計。

### 上下文工程與工具框架工程有什麼差異？
上下文工程聚焦於模型在特定時刻所看到的資訊。工具框架工程則包含尋找該資訊、執行動作並檢查結果的工具、權限、執行環境、文件結構、日誌與復原機制。

### 代理程式與一般工作流程自動化有何不同？
一般工作流程會遵循預先定義的順序與分支，而代理程式會解讀當前狀態，動態選擇下一步行動與工具。對於規則穩定的工作，確定性的工作流程可能更便宜且更可預測。

### 迴圈工程與單純重試有什麼不同？
單純重試只是在相同條件下再次生成。迴圈工程則透過外部驗證訊號確認失敗並分類原因，接著修改提示詞、上下文、工具或實作中必要的部分，並套用終止條件與迴歸測試。

### 什麼時候應該使用多代理程式？
當各角色的工具與權限明顯不同，且單一代理程式的上下文或工具集合變得過於龐大，導致效能與評估惡化時，可以考慮使用。若只是為了簡單的角色分工而建立多個代理程式，可能會增加成本、延遲、錯誤傳播與除錯難度。

### 可以讓 AI 評估自己的結果嗎？
可以作為輔助訊號使用，但將其作為唯一驗證器是危險的。若可能，應先套用測試、結構描述、參考資料與政策規則，並以明確的評分規準與人工抽樣審查來補充模型評估。

### 工具框架文件中應放入哪些內容？
應放入重複性作業流程、儲存庫與系統結構、允許與禁止的行為、工具使用方法、良好與不良範例、測試命令、故障應對、核准政策與完成標準。文件應簡短、可搜尋，並納入版本管理。

### 將外部文件放入上下文時，最重要的安全原則是什麼？
外部文件應視為不可信資料，並與系統指示分離。應將工具權限最小化，以避免執行文件中的命令；對於重要的寫入、刪除、付款、部署行為，則應設置獨立的政策檢查與人工核准。

### 小型團隊最好從哪裡開始？
蒐集小型且具代表性的評估集與失敗案例，衡量單一模型呼叫的基準線。之後確認最大的失敗原因是在指示、資訊、工具環境、規劃或驗證中的哪一項，逐層改善會更有效率。

## Sources

- [提示詞工程概述 - Claude Platform Docs](https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview)
- [面向 AI 代理程式的有效上下文工程](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Harness 工程：在代理程式優先的世界中運用 Codex](https://openai.com/index/harness-engineering/)
- [建構有效的代理程式](https://www.anthropic.com/engineering/building-effective-agents)
- [建構代理程式的實用指南](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)
- [揭開 AI 代理程式評估的神秘面紗](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [面向編碼代理程式使用者的 Harness 工程](https://martinfowler.com/articles/harness-engineering.html)

## Images

![中央 AI 核心連接指令、情境、工具、自主執行與驗證迴圈模組的系統架構](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg0NywicHVyIjoiYmxvYl9pZCJ9fQ==--9f1b84d1d297642915a0d27477d3800017987668/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_12_32.webp)
![從指令設定、情境篩選與安全環境，到自主執行和反覆驗證的 AI 建置流程](https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg1NCwicHVyIjoiYmxvYl9pZCJ9fQ==--47acd549387f7a60f4c18de6ac673ca1b551dd36/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_36_26.webp)