---
title: "迴圈工程的概念與必要組成要素"
locale: zh-hant
category: ai_data
category_name: "AI 資料"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/loop-engineering-concept-components
published_at: 2026-07-20T15:26:45+09:00
---

# 迴圈工程的概念與必要組成要素

> 迴圈工程是一種設計方式：由人類定義目標與限制條件後，讓 AI 代理反覆進行規劃、執行、測試、修正，以改善結果。核心組成要素可整理為自動化、工作樹、技能、外掛與連接器、子代理、記憶。

## Key Points

- 迴圈工程不是單純撰寫提示詞，而是設計能讓 AI 反覆執行直到達成目標的工作系統的方法。
- 如果框架工程是建立安全的工作環境與規則，迴圈工程則是在該環境中啟動反覆執行引擎。
- 安全的迴圈需要隔離的工作空間、明確的指示、工具連接、角色分工、狀態儲存與中斷條件。
- 在 AI 開發自動化中，迴圈會將程式碼撰寫、測試執行、錯誤分析、重試、請求檢閱串成一個封閉式回饋週期。
- 迴圈工程能提升生產力，但若缺乏權限管理、成本控管、品質驗證、避免無限迴圈的機制，就可能變得危險。

## 概要

迴圈工程是設計 AI 代理朝向單一目標**規劃、執行、檢查結果，並反映失敗原因後再次嘗試的反覆結構**的方法。尤其在軟體開發、資料處理、文件生成、測試自動化等可驗證結果的工作中，正變得越來越重要。

這個術語尚未在所有標準文件中被固定為學術用語。不過在實務上，可以說明為提示工程、脈絡工程、Harness 工程之後下一階段的概念。核心不是「給 AI 一次好的指示」，而是「建立一套讓 AI 能在安全環境中反覆執行直到達成目標的系統」。

## AI 工程的演進：從提示到迴圈

| 階段 | 核心問題 | 人類的角色 | AI 的角色 | 代表產出 |
|---|---|---|---|---|
| 提示工程 | 要如何提問 | 撰寫指示並確認結果 | 生成單次回應 | 回答、草稿、程式碼片段 |
| 脈絡工程 | 要提供哪些背景資訊 | 提供文件、範例、政策、資料 | 在給定脈絡中推理 | 更一致的回答、客製化結果 |
| Harness 工程 | 要讓它在什麼環境與規則中工作 | 設計權限、工具、流程、安全規則 | 在既定環境中使用工具 | 受控的代理工作流程 |
| 迴圈工程 | 要如何讓它反覆執行直到達成目標 | 設定目標、限制、評估標準、中止條件 | 反覆執行、驗證、修正、重試 | 自動改善的工作迴圈 |

### 提示工程

提示工程是為了從 AI 得到想要的結果，而精細撰寫問題、命令、範例、輸出格式的方式。這是最基本的互動，接近由人類每次改變指示並確認結果的結構。

### 脈絡工程

脈絡工程是同時提供模型可參考的文件、政策、程式碼庫資訊、使用者偏好、輸出風格、過去對話等，以取得更準確結果的方式。長脈絡視窗、檢索增強生成、檔案附加、程式碼庫索引等都與此階段相關。

### Harness 工程

Harness 工程是在 AI 使用工具並執行多個步驟時，設計它**應該在什麼流程與限制中行動**。例如將「修改程式碼前先讀取相關檔案」、「未通過測試就不要合併」、「不要瀏覽包含敏感資訊的檔案」等規則內建到環境中。

### 迴圈工程

迴圈工程是在 Harness 所建立的受控工作環境之上，加上**反覆執行引擎**的方式。AI 代理會朝向目標自行選擇下一步行動、使用工具、評估結果，若失敗則修正策略並再次執行。

## 迴圈工程的核心定義

迴圈工程可以定義為滿足下列條件的 AI 工作系統設計。

- 人類決定最終目標、允許範圍、評估標準、中止條件。
- AI 代理為了達成目標制定工作計畫。
- 代理使用程式碼執行、測試、搜尋、檔案修改、API 呼叫等必要工具。
- 執行結果失敗或不足時，分析失敗原因並生成下一次嘗試。
- 當目標達成、預算超支、反覆次數超過、出現危險訊號、需要人類批准等中止條件被滿足時，停止迴圈。

也就是說，迴圈工程的本質是**自動化的回饋週期**。

## 為什麼需要迴圈工程

在既有的 AI 使用方式中，人類很容易成為瓶頸。因為人類必須撰寫提示、確認結果、再次提出修改要求、執行測試、複製錯誤訊息後再輸入。

迴圈工程將這個反覆過程系統化。例如在開發工作中，AI 可以自動反覆執行下列流程。

1. 讀取需求並制定工作計畫。
2. 在獨立工作空間中修改程式碼。
3. 執行測試與 linter。
4. 分析錯誤日誌。
5. 自行建立修改提示或下一步行動。
6. 再次修改程式碼。
7. 滿足通過標準後整理結果並請求審查。

在這種結構中，人類不需要直接指示所有中間步驟。相反地，人類專注於目標設定、批准、例外處理、最終品質判斷。

## 迴圈工程的 6 個必要構成要素

### 1. 自動化：實際運轉迴圈的引擎

自動化是讓迴圈不需人的手動輸入即可執行的基礎。工作佇列、排程器、CI/CD 管線、代理執行環境、事件觸發器、重試政策等都包含在內。

自動化負責的功能如下。

- 偵測工作開始條件
- 執行代理
- 呼叫工具並收集結果
- 執行測試或驗證階段
- 失敗時重試
- 儲存日誌
- 轉換到人類批准階段
- 限制成本、時間、反覆次數

自動化不是單純的「自動執行」，而是管理迴圈生命週期的控制裝置。

### 2. 工作樹：安全的工作空間

工作樹是提供給 AI 的隔離工作空間，避免它直接破壞主要程式碼或實際營運資料。代表性的方式是像 Git 的 `worktree` 功能一樣，在同一個儲存庫中建立獨立工作目錄，並可獨立修改與測試。

工作樹重要的原因如下。

- 保護主分支或營運環境。
- 多個代理可以並行執行不同工作。
- 可以輕鬆丟棄失敗的嘗試。
- 可以用 diff 審查變更。
- 只將通過測試的變更作為合併對象。

在迴圈工程中，工作樹是 AI 的實驗空間。即使代理大膽修改，若要讓整個系統維持安全，就需要隔離工作空間。

### 3. 技能：成為工作標準的指南

技能是 AI 執行特定工作時應遵循的指引、流程、檢查清單、程式碼規則、設計原則、範例集合。就像人會提供入職文件給新進團隊成員一樣，代理也需要業務執行標準。

技能文件中可以包含下列資訊。

- 專案結構與核心模組說明
- 程式碼風格與命名規則
- 測試撰寫方式
- API 設計原則
- 安全禁止事項
- 部署前檢查清單
- 失敗時應確認的日誌位置
- 結果報告格式

如果沒有技能，代理每次都會依賴一般性的推理。相反地，撰寫良好的技能會以可重複使用的形式，將組織的工作方式傳達給 AI。

### 4. 外掛程式與連接器：存取必要工具

外掛程式與連接器讓 AI 能在工作中存取必要的工具與系統。例如程式碼儲存庫、議題追蹤器、搜尋系統、資料庫、文件儲存庫、測試執行器、瀏覽器、部署工具、通知系統等都可能成為連接對象。

需要工具連接的理由很明確。代理判斷「必須執行測試」卻沒有測試執行權限時，迴圈就會停止。代理判斷「必須確認相關文件」卻沒有文件存取路徑時，就很可能以猜測回答。

良好的連接器設計需要下列原則。

- 適用最小權限原則。
- 分離讀取權限與寫入權限。
- 對危險工作設置批准階段。
- 將所有工具呼叫留下日誌。
- 以獨立政策限制敏感資訊存取。
- 失敗的工具呼叫也記錄在迴圈狀態中。

### 5. 子代理：分工的 AI 工作者

子代理是不讓一個主要代理處理所有事情，而是讓依角色區分的代理協作的結構。可以像人的開發團隊一樣，分離設計、後端、前端、QA、安全審查、文件化角色。

| 角色 | 主要責任 | 輸出範例 |
|---|---|---|
| 規劃代理 | 需求分析、工作拆解、優先順序設定 | 實作計畫、工作清單 |
| 後端代理 | 實作 API、資料模型、伺服器邏輯 | 程式碼變更、測試 |
| 前端代理 | 改善 UI、狀態管理、可近用性 | 元件修改、畫面測試 |
| QA 代理 | 執行測試、重現 bug、回歸驗證 | 失敗日誌、重現流程 |
| 審查代理 | 檢查程式碼品質、安全、風格 | 審查意見、風險清單 |
| 文件代理 | 說明變更事項、撰寫使用方式 | 發行說明、使用指南 |

子代理結構的優點是可以分配專業性。不過也可能發生代理之間的衝突、重複工作、責任不明確，因此需要協調者角色與明確的工作契約。

### 6. 記憶：讓中斷與恢復成為可能的狀態儲存

記憶是儲存迴圈目前狀態、過去嘗試、失敗原因、決策理由、檔案變更、測試結果、下一步行動計畫的功能。迴圈越長，記憶就越接近必要。

記憶大致可分為兩種。

- 短期記憶：目前工作階段的計畫、日誌、工具呼叫結果、錯誤訊息
- 長期記憶：專案規則、過去解法、反覆出現的 bug 模式、使用者偏好、團隊標準

如果沒有記憶，代理可能重複相同錯誤，或從頭開始已在中途停止的工作。相反地，設計良好的記憶會穩定延續迴圈並降低成本。

## 迴圈工程的基本架構

迴圈工程系統通常具有如下結構。

1. 輸入目標：人類提供要解決的問題與完成標準。
2. 收集脈絡：讀取程式碼、文件、議題、日誌、政策。
3. 制定計畫：代理將工作拆成小步驟。
4. 執行：進行程式碼修改、檔案生成、資料處理、工具呼叫。
5. 驗證：執行測試、lint、型別檢查、政策檢查、審查。
6. 評估：判斷是否滿足目標標準。
7. 反覆：若失敗，分析原因並回到新計畫。
8. 結束：因成功、超過限制、偵測到危險、需要人類批准其中之一而停止。
9. 報告：摘要變更事項、驗證結果、剩餘風險、下一步建議措施。

這個流程的前提不是「只反覆思考的 AI」，而是「在實際環境中行動並驗證結果的 AI」。

## Harness 工程與迴圈工程的差異

| 區分 | Harness 工程 | 迴圈工程 |
|---|---|---|
| 目的 | 建立讓 AI 安全工作的環境 | 讓 AI 反覆執行直到達成目標 |
| 中心要素 | 規則、權限、工具、流程、限制 | 反覆執行、回饋、重試、狀態儲存 |
| 失敗應對 | 阻止危險行為或請求批准 | 反映失敗原因並生成下一次嘗試 |
| 人類介入 | 專注於政策與環境設計 | 專注於目標設定、例外處理、最終批准 |
| 比喻 | 工作場域與安全設備 | 持續運轉工作場域的生產線 |

如果沒有 Harness 就建立迴圈，代理可能以過高權限進行危險行為。如果沒有迴圈而只建立 Harness，雖然有安全環境，但生產力會受限。在實務中，兩種方法都需要一起使用。

## 應用範例：AI 編碼代理的迴圈

在軟體開發中，迴圈工程相對容易理解。假設給定「修正登入錯誤」這個目標。

### 輸入

- 目標：修正在特定條件下發生登入失敗的 bug
- 完成標準：相關測試通過、既有登入功能無回歸、提交變更摘要
- 限制：禁止變更認證權杖儲存方式、禁止直接修改使用者資料庫

### 迴圈執行

1. 代理讀取議題說明與相關檔案。
2. 在工作樹中建立獨立分支或工作目錄。
3. 重現失敗測試。
4. 分析錯誤日誌與相關程式碼。
5. 套用修正方案。
6. 執行測試。
7. 若失敗，摘要原因並嘗試其他修正方案。
8. 若成功，整理 diff、測試結果、風險因素。
9. 向人類審查者請求合併批准。

在這個範例中，人類不需要每次複製錯誤日誌來撰寫新提示。相反地，迴圈會執行反覆工作，而人類介入需要最終判斷與責任的階段。

## 設計時必須決定的控制變數

迴圈工程有時會以無限反覆為前提來說明，但在實際系統中，「無限」是危險的。安全的迴圈需要明確限制。

| 控制變數 | 說明 | 範例 |
|---|---|---|
| 最大反覆次數 | 限制同一工作最多重試幾次 | 最多重試 5 次 |
| 時間預算 | 限制迴圈執行時間 | 超過 30 分鐘時中止 |
| 成本預算 | 限制模型呼叫、工具使用、基礎設施成本 | 每項工作 10 美元以下 |
| 權限範圍 | 分離讀取、寫入、執行、部署權限 | 禁止寫入營運 DB |
| 批准節點 | 定義需要人類審查的時刻 | 部署、刪除、付款、外部傳輸前批准 |
| 成功標準 | 判斷為完成的客觀條件 | 測試通過、滿足準確度標準 |
| 失敗標準 | 應中止的危險訊號 | 同一錯誤重複 3 次、發生安全警告 |

好的迴圈不是轉很多次的迴圈，而是**知道在適當時刻停止的迴圈**。

## 品質評估標準

評估迴圈工程系統時，不應只看「AI 是否產生了答案」，而是也要一起看下列指標。

- 目標達成率：成功完成給定工作的比例
- 到第一次成功所需的反覆次數：是否有不必要的重試
- 測試通過率：是否滿足自動驗證標準
- 回歸發生率：破壞既有功能的比例
- 人類介入次數：自動化是否實際減少瓶頸
- 成本效益：相對於模型呼叫成本與基礎設施成本的成果
- 可稽核性：是否可追蹤呼叫了什麼工具以及為什麼呼叫
- 安全違規率：是否存取了禁止的檔案、API、資料
- 可重現性：在相同條件下是否產生相似結果

尤其在軟體開發中，僅靠測試通過可能並不足夠。安全、效能、可維護性、使用者體驗也都必須一併審查。

## 常見失敗模式

### 1. 成功標準模糊時

如果像「幫我做得好一點」這樣完成標準不明確，迴圈很難找到停止依據。需要像「新增 3 個單元測試、所有既有測試通過、維持回應時間 200ms 以下」這樣可驗證的標準。

### 2. 工具權限過度時

如果給代理無限制的營運資料庫寫入、部署、寄送外部郵件等權限，小小的判斷錯誤可能導致重大事故。危險工具必須以批准為基礎分離。

### 3. 沒有記憶或記憶被污染時

如果沒有狀態儲存，就會重複相同失敗。相反地，如果錯誤記憶被累積，就可能持續重用錯誤前提。最好在記憶中區分儲存已驗證事實、推測、失敗記錄。

### 4. 子代理之間責任重疊時

如果多個代理同時修改同一檔案，可能發生衝突。必須決定工作範圍、檔案所有權、審查順序、合併規則。

### 5. 沒有成本限制時

迴圈是反覆結構，因此模型呼叫與工具執行成本可能快速增加。必須限制反覆次數、權杖使用量、外部 API 呼叫數、執行時間。

## 實作檢查清單

將迴圈工程實際套用到專案時，建議依下列順序檢查。

### 目標與評估標準

- 是否用一句話定義了要解決的問題？
- 完成標準是否可自動驗證？
- 是否區分了需要人類批准的標準？
- 失敗時是否有中止條件？

### 工作環境

- 是否有與主要程式碼分離的工作樹？
- 測試執行環境是否可重現？
- 是否限制了祕密金鑰與敏感資訊存取？
- 是否可以用 diff 追蹤變更事項？

### 指引與脈絡

- 是否有專案結構說明？
- 程式碼規則與測試規則是否已文件化？
- 禁止行為與安全規則是否明確？
- 代理參考的文件是否為最新？

### 工具與權限

- 必要工具是否已事先連接？
- 各工具的權限是否已最小化？
- 危險工具呼叫是否有批准階段？
- 是否留下所有工具呼叫日誌？

### 迴圈控制

- 是否有最大反覆次數與時間限制？
- 是否有成本限制？
- 是否偵測相同錯誤的反覆發生？
- 是否可以儲存並恢復中間狀態？

## 適合與不適合迴圈工程的工作

| 工作類型 | 適合度 | 理由 |
|---|---:|---|
| 有測試的程式碼修改 | 高 | 容易以執行結果判斷是否成功 |
| lint、格式化、遷移 | 高 | 具有反覆性且驗證標準明確 |
| 文件草稿生成與審查 | 中 | 可以自動化，但需要事實驗證 |
| 資料清理 | 中～高 | 若有規則與樣本驗證則有效 |
| 安全修補 | 中 | 可以自動化，但需要專家審查 |
| 法律判斷、醫療診斷、投資建議 | 低 | 責任、專業性、法規風險很大 |
| 直接變更營運系統 | 低 | 沒有批准的自動迴圈事故風險很大 |

迴圈工程在「可驗證的工作」中最強。驗證標準不明確或責任重大的決策，必須由人類專家控制。

## 實務導入路線圖

### 第 1 階段：建立單一工作迴圈

先從一個小工作開始。例如縮小範圍到修正測試失敗的迴圈、修正文件連結錯誤的迴圈、解決型別錯誤的迴圈。

### 第 2 階段：固定 Harness

文件化工作前確認、可修改檔案、可執行命令、禁止行為、批准條件。如果這個階段薄弱，迴圈越大，風險也會一起變大。

### 第 3 階段：建立工作樹與日誌體系

所有變更都在隔離空間中執行，並記錄工具呼叫與測試結果。失敗的嘗試也是重要資料。

### 第 4 階段：文件化技能

將反覆需要的知識製作成技能。像是「在這個專案中新增測試的方法」、「API 變更時的檢查清單」、「前端可近用性標準」這類文件很有用。

### 第 5 階段：分離子代理

工作變複雜時，分離規劃者、實作者、QA、審查者。與其一開始就建立過多代理，不如從已確認瓶頸的角色開始分工。

### 第 6 階段：改善記憶與評估指標

記錄反覆失敗原因、成功模式、成本、人類介入次數。以這些資料為基礎改善迴圈的效率與安全性。

## 結論

迴圈工程是一種設計方法，將 AI 代理從單純回應生成器轉變為**目標導向的工作執行系統**。核心不是盲目給予 AI 自主性，而是透過 Harness 工程建立受控環境，並在其中結合自動化、工作樹、技能、外掛程式與連接器、子代理、記憶，建立安全的反覆結構。

設計良好的迴圈會減少人類反覆指示的負擔，並提升工作速度。然而，沒有安全裝置的迴圈可能造成成本增加、品質下降、權限濫用、無限反覆問題。因此，迴圈工程的核心原則是「自動化，但要讓它可驗證，並且在必要時刻一定能停止」。

## FAQ

### 什麼是迴圈工程？
迴圈工程是一種設計作業系統的方法，讓 AI 代理在達成目標之前，反覆進行規劃、執行、驗證、修正與重試。它不只是撰寫好的提示詞，還包括自動重複、工具使用、狀態儲存以及中止條件。

### 迴圈工程與提示詞工程有什麼差異？
提示詞工程著重於將一次性的指示有效傳達給 AI。迴圈工程則是更具系統性的做法，因為它設計的是一種封閉式回饋結構，讓 AI 檢查結果、反映失敗原因後再次執行。

### Harness 工程與迴圈工程有何不同？
Harness 工程是建立讓 AI 安全工作的規則、權限、工具與環境。迴圈工程則是在這個受控環境中，讓 AI 反覆執行直到達成目標。

### 為什麼迴圈工程需要工作樹？
工作樹提供隔離的工作空間，讓 AI 可以在不損害主要程式碼或營運環境的情況下進行實驗。它可以捨棄失敗的變更，只檢視成功的變更，從而提高 AI 編碼迴圈的安全性。

### 在迴圈工程中，技能代表什麼？
技能是 AI 在工作時參考的文件化作業標準，例如指南、檢查清單、編碼規則、測試規則與安全政策。技能越明確，代理就越有可能依照組織的方式工作。

### 為什麼外掛程式和連接器很重要？
外掛程式和連接器讓 AI 能夠存取儲存庫、文件、測試執行器、議題追蹤器、資料庫等工具。如果必要工具沒有連接，迴圈可能會在中途停止，或依賴猜測。

### 什麼時候需要子代理？
當工作分為設計、後端、前端、QA、審查等多個專業角色時，子代理會很有用。不過，如果角色與責任範圍不明確，可能會產生衝突，因此需要協調規則。

### 記憶在迴圈工程中扮演什麼角色？
記憶會儲存目前的工作狀態、先前的嘗試、失敗原因、測試結果與下一步計畫。藉此，即使迴圈中斷，也能接續恢復，並降低重複相同錯誤的可能性。

### 迴圈工程是否意味著無限重複？
概念上，它的意思是反覆進行直到達成目標，但在實際系統中，無限制重複是危險的。必須設定最大重複次數、時間限制、成本限制、失敗偵測與人工核准條件。

### 迴圈工程最適合哪些工作？
它很適合有明確驗證標準的重複性工作，例如有測試的程式碼修正、lint 與格式化、資料清理、文件檢查。像法律判斷、醫療診斷、投資決策這類責任重大的領域，不應只靠自動迴圈來處理。

### 迴圈工程最大的風險是什麼？
主要風險包括權限過大、無限重試、成本暴增、錯誤記憶累積、未經驗證的自動部署，以及存取敏感資訊。因此，最小權限、日誌記錄、核准階段與中止條件都是必要的。

### 首次導入迴圈工程時，最好的方法是什麼？
一開始最好從小而可驗證的單一工作開始，例如修正失敗測試、檢查文件連結、修正型別錯誤。之後再以階段性方式加入工作樹、技能文件、工具連接、記憶與子代理，會比較安全。

## Sources

- [Git 文件：git-worktree](https://git-scm.com/docs/git-worktree)
- [GitHub Docs：GitHub Actions 文件](https://docs.github.com/en/actions)
- [OpenAI Platform Docs：函式呼叫](https://platform.openai.com/docs/guides/function-calling)
- [Model Context Protocol：簡介](https://modelcontextprotocol.io/introduction)
- [LangGraph 文件：持久化](https://langchain-ai.github.io/langgraph/concepts/persistence/)
- [ReAct：在語言模型中協同推理與行動](https://arxiv.org/abs/2210.03629)
- [Reflexion：透過語言強化學習的語言代理](https://arxiv.org/abs/2303.11366)

## Images

![中央 AI 機器人周圍有循環箭頭，以及自動化、文件、驗證與資料圖示](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjMwMSwicHVyIjoiYmxvYl9pZCJ9fQ==--e2cc0e235018c6d93b44f9fe5cf3889bea5aa10a/ai-cccc7ad2.webp)
![機器人與連接工作站透過循環管線組成的自動化驗證系統](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjMwNywicHVyIjoiYmxvYl9pZCJ9fQ==--6e96b4db0ce479ff3ba8d0cefc6dafb74a3e9ce0/ai-20876eb8.webp)