走了七篇，我們把一個 AI Agent 的 harness 拆到見骨：從能動性到底從哪來、最小的 agent loop 怎麼轉、怎麼拆解扛不動的複雜任務，一路拆到記憶與崩潰後的韌性、長時間非同步地跑、多代理分工協作，再到上一篇的MCP、外掛與可觀測性。每一篇都是在「一次 model 呼叫」的周圍多裝一個零件。這最後一篇要做的事只有一件——把散在桌上的零件全部組回去，變成一台你不在旁邊也能自己轉的機器。

這一層在書裡叫 Layer 7「組合」，主題是 loop engineering（迴圈工程）。它沒有發明任何新元件，它教的是怎麼把前面的迴圈疊起來，讓 agent 從「你一句一句餵 prompt」進化成「它自己找工作、自己做、自己驗、自己回報」。

從「下 prompt 的人」變成「設計 loop 的人」

先講一個心態上的轉彎。你平常用 Claude Code 或任何 agent，其實一直在當那個「外層迴圈」：你想一個 prompt、讀它的輸出、判斷對不對、不對就再下一句、覺得可以了就收工。這整套「觸發 → 執行 → 檢查 → 重試」的流程，是靠你的手和你的眼睛在驅動的。你一離開座位，agent 就停在原地。

loop engineering 的核心觀念，就是把「你這個人」做的事，寫成程式。與其一個 turn 一個 turn 地想下一句要打什麼，不如打造一個外層系統：由它去找出該做的工作、把 agent 跑起來、檢查輸出、再決定下一步。書裡有句話講得很直白——別再想下一句 prompt 要寫什麼，去設計那個不需要你也能把 agent 跑起來的 loop。人的角色從「操作者」變成「設計者」。

要撐起這個轉變，外層 loop 有五件事非做不可：它得靠 trigger 自己啟動，而不是等你按 enter；輸出要先通過檢查才算數；靠一個事先設好的 budget（花費上限）停下來，而不是靠運氣；把狀態存下來，讓下一次接著做而不是從頭來過；還有，就算沒人盯著，也要老實回報這一趟到底發生了什麼。少了這一層，那個外層迴圈就永遠是你本人。

一台機器裡，有四個迴圈同時在轉

你可以把整套系統想成一個作業系統：最外面有個 scheduler 不斷把工作丟進來，中間有一層在判斷「這個工作做完了沒」，最裡面才是真正動手的那個 process。agent 系統的結構幾乎一模一樣——一個 agent loop 外面，再包三層 loop，一層包一層，每一層只回答一個問題。

最裡面是 agent loop（第 2 篇的核心迴圈）：呼叫 tool，直到任務看起來做完了。它回答的是「這一步怎麼做完」。往外一層是全新的 驗證 loop：拿一份 rubric（評分準則）替輸出打分，沒過就帶著 feedback 重試，試到 budget 用完為止。它回答的是「是不是真的完成了」。再往外是 事件 loop：cron 排程、webhook、channel 負責在對的時機把工作推進來，它回答「工作什麼時候開始」（對應第 5、7 篇）。最外面是 改進 loop：trace 和 eval 回頭去改 harness 的設定、skill 甚至 model，它回答「整個系統有沒有越跑越好」（對應第 7 篇）。

資料的流向是由內往外。trigger 一 fire，就把一個 prompt 塞進 queue；agent loop 產出一個候選輸出；評分者替它打分；沒過而且 budget 還有剩，就帶著上次錯在哪的 feedback 重試；過了就從這個 task 的 channel 投遞出去。整趟做了什麼，全記成 trace 存進 telemetry，改進 loop 之後就是讀這些紀錄，來決定 harness 哪裡該動刀。這個改進 loop 玩到極致時，改的會是 harness 本身——從 trace 裡挖出弱點、提一個範圍受限的修改、再用 regression 測試驗證。到那一步，loop 的結構本身就變成一個可以被搜尋、被最佳化的空間，而不再是你手工敲出來的模板。

驗證 loop：整本書唯一的新零件

前面七篇你其實已經見過三個迴圈了——agent loop、事件相關的排程與 channel、還有可觀測性。真正沒出現過的，只有這個驗證 loop。它要處理的是 agent 最惱人的老毛病：內層 loop 是 model 自己說「我做完了」就停。有了驗證 loop，「完成」不再是 model 說了算，得通過一個獨立的檢查才算數。

1
2
3
4
5
6
7
8
9
10
11
def verified_run(task, worker, checker, budget=2):    # src/verify.py
    feedback = ""
    attempts = []
    for n in range(1, budget + 1):                    # 上限：由 harness 強制，繞不過去
        out = worker(task + feedback)                 # 內層迴圈（第 1 章那個 agent loop）
        verdict = checker(task, out)                  # 另一個獨立的評分者（第 6 章）
        attempts.append({"attempt": n, "passed": verdict["passed"], "reason": verdict["reason"]})
        if verdict["passed"]:
            return {"ok": True, "output": out, "attempts": attempts}
        feedback = f"\n\n上一次的嘗試被打回了。失敗原因：{verdict['reason']}"
    return {"ok": False, "output": None, "attempts": attempts}   # budget 用完 → 交給人接手

這段程式碼藏了四個關鍵設計。第一，評分者是另一個 agent，用的是全新的 context——你不能讓寫作業的人改自己的考卷，worker 評自己的輸出幾乎都會給過。第二，rubric 定在 loop 之外，model 只能想辦法滿足它，不能改寫它。第三，feedback 是資料，不是空話：沒過的 verdict 會併進下一次重試的 prompt，讓第二次嘗試知道第一次栽在哪裡。第四，ok: False 是一個明確的訊號——budget 燒完還沒過，就把整份嘗試紀錄交給人接手，loop 絕不無止境地重試下去。

Budget：讓機器停得下來

每一個 loop 都需要一個 model 講什麼都繞不過去的上限。可以是迭代次數、token budget、時間上限，也可以是一個 dry counter（連續 K 輪都沒有新發現就停）。重點在於，這個上限是由 harness 強制執行的。拜託 model 自己適可而止，那只是提示，不是停止條件。在上面那段 verified_run 裡，上限就藏在 range() 的邊界——第 budget + 1 次嘗試在物理上就不可能發生。

把四個迴圈疊起來，骨架長得像這樣。你會看到停止條件和「不管成敗都回報」是怎麼被放進結構裡的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 一台會自己轉的機器：迴圈由外往內一層層包
# 最外層 event loop：由 trigger 決定「什麼時候開始」
def event_loop(triggers, budget):
    for task in wait_for(triggers):          # cron / webhook / channel 把工作推進來
        result = verified_run(task, budget)  # 進入驗證迴圈
        deliver(result)                      # 不管成敗都回報，就算現在沒人在看
        record_trace(task, result)           # 留下 trace，給最外層的改進迴圈日後去讀

# 中層 verification loop：判斷「是不是真的完成了」
def verified_run(task, budget=2):
    feedback = ""
    for n in range(1, budget + 1):           # 上限由 harness 強制，不靠 model 自己喊停
        output = agent_loop(task + feedback) # 進入最內層的 agent 迴圈
        verdict = fresh_checker(task, output)# 用全新 context 的評分者，不讓 worker 自己評自己
        if verdict["passed"]:
            return {"ok": True, "output": output}
        feedback = f"上一次被打回，原因：{verdict['reason']}"  # feedback 帶進下一次重試
    return {"ok": False}                      # budget 用完 → 交給人接手

# 最內層 agent loop：把「這一步」做完，就是第 2 篇那個核心迴圈
def agent_loop(prompt):
    ...                                       # 呼叫 model、跑 tool、把結果接回去，直到 end_turn

成熟度等級：你敢讓它做多少事

loop engineering 的幾個出處都用同一個維度替 loop 分級——你敢放手讓它做多少事。L1 是回報：loop 只讀取和回報，動手的還是人。L2 是協作：loop 起草修改，交給人核准。L3 是無人看管：loop 直接動手，人只在事後稽核。

這個等級本質上是一個權限決定（第 1 篇談過的 permission）。書裡的建議很保守也很實在：只有在目前這一級的輸出已經穩定到「讓你覺得無聊」的程度時，才把 loop 往上升一級。你不會想在還會出錯的階段就把寫入權限交出去。

把這一路走過的每一層，攤開來看

第 0 層先把地基打好——講清楚 agency 從哪來、誰負責推理誰負責行動。接著七層機制一層層疊上去，最後在第 7 層收束成一台能自己轉的機器。這張表就是整個系列的地圖：

層級 這一層在做什麼 對應機制 解決什麼問題
第 0 層 · 基礎 先講清楚能動性從哪來 model vs harness、action、observation、permission 誰負責推理、誰負責行動的分工
第 1 層 · 核心迴圈 讓 agent 能一直轉 agent loop、tool runtime、permission/sandbox、hooks 模型怎麼呼叫工具、副作用怎麼擋、擴充怎麼掛進迴圈
第 2 層 · 複雜工作 把大任務拆得動 planning/todos、subagent、skill、context 管理 大工作怎麼拆、子問題怎麼隔離、能力怎麼隨需載入、視窗塞不下怎麼辦
第 3 層 · 知識與韌性 跨執行記住事情、失敗後活下來 memory、system prompt 組裝、error recovery 怎麼記住、每輪提示怎麼組、長任務怎麼在失敗中存活
第 4 層 · 長時間非同步 讓工作跨越單一輪次 task 系統、背景執行、scheduling、worktree 隔離 工作怎麼持續、怎麼在主迴圈外跑、怎麼排到之後執行、平行怎麼不打架
第 5 層 · 多代理 讓多個 agent 一起做事 coordination、protocol、autonomy agent 之間怎麼溝通、怎麼乾淨收尾、怎麼自我組織
第 6 層 · 擴充與整合 連到外面的世界、也看得見自己在幹嘛 MCP/plugin/channel、observability/evaluation harness 怎麼接外部工具、我們怎麼知道它到底有沒有效
第 7 層 · 組合（你在這裡） 把上面全部組成會自己轉的系統 verification loop、trigger、budget、成熟度等級 迴圈怎麼疊成一台不用你盯著也能運轉的機器

看這張表最好的方式，是回頭對照你天天在用的 Claude Code。書裡就是拿 Claude Code 和另一套開源的 Hermes Agent 當拆解對象。舉例來說，Claude Code 的 /loop <interval> <prompt> 就是讓一個 prompt 按節奏重複執行的事件 loop；Workflow tool 的 agent()、pipeline()、parallel() 把工作扇出，它文件裡的 adversarial verify、judge panel、loop-until-dry 這些品質模式，本身就是各種驗證 loop；budget.remaining() 把 token 目標變成硬上限，超過就直接拋錯；resumeFromRunId 讓修好的 workflow 從快取接著跑而不是從頭跑。你每天敲的那些指令，其實就是這八層的實體。

動手跑：把 repo clone 下來，逐節看 diff

看到這裡，最有價值的下一步不是再讀一篇文章，而是把這個 repo 拉下來自己跑。它的每一個可執行章節都只需要一把 Anthropic API key、一份 requirements.txt 和一個 .env。從 repo 根目錄設定一次就好：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 1. 把 repo 抓下來
git clone https://github.com/hardness1020/awesome-agent-architecture.git
cd awesome-agent-architecture

# 2. 建一個乾淨的虛擬環境並裝相依套件（repo 原生用 uv）
uv venv
uv pip install -r requirements.txt

# 沒裝 uv 的話，用內建的 venv 也行：
# python3 -m venv .venv
# source .venv/bin/activate
# pip install -r requirements.txt

# 3. 設定 .env，把你的 Anthropic API key 填進去
cp .env.example .env
# 接著編輯 .env，至少填 ANTHROPIC_API_KEY，
# 另有選填的 ANTHROPIC_MODEL 與 ANTHROPIC_BASE_URL

# 4. 進到任一章，先跑不用金鑰的離線測試，再跑即時 demo
python sections/01-agent-loop/src/test.py         # 離線檢查，不用金鑰
uv run python sections/01-agent-loop/src/demo.py  # 即時示範，需要金鑰

# 收束這一篇的 Layer 7，就跑第 21 章：
python sections/21-loop-engineering/src/test.py         # 離線
uv run python sections/21-loop-engineering/src/demo.py  # 跑一次完整的 verified run

真正讓這個 repo 好學的，是它的程式碼是「一章一章長出來」的。第 1 到第 21 章的 src/ 是同一條程式碼鏈，每一章只加一個機制、只讓 loop.py 往前演進一小步。所以最有效的讀法，是拿相鄰兩章的 src/ 來 diff——那個差異，就是這一章新增的那一個機制，乾乾淨淨，沒有雜訊。以這一篇為例，第 21 章的 verify.py 就是把第 20 章那個一模一樣的 run_turn 包進一層驗證裡，worker 完全沒動，新增的只有外面那圈評分與重試。你會親眼看到「多包一層 loop」這件事在程式碼裡長什麼樣子。

⚠️ 跑 demo 前先知道兩件事。 一、test.py 是離線的、不花錢，但 demo.py 會真的打 Anthropic API，會產生費用；先跑 test 再跑 demo，並留意你的用量。二、這個 repo 是教學骨架，不是生產框架——它的價值在於把每個機制拆到最小、看得最清楚，不是拿來直接上線扛流量。把它當成理解你正在用的那些 agent 的一面 X 光片。

幾個放著跑之前一定要想清楚的坑

無人看管的 loop 會把你的產出放大好幾倍，但它同時也把錯誤放大好幾倍。讓一個 L3 的 loop 敢放著跑的，從來不是它多聰明，而是驗證和 budget 這兩道關卡。書裡把常見的翻車方式列得很清楚，這裡挑幾個最容易中的：

沒有停止條件的重試 loop，會一路燒 token 直到有人看到帳單——解法是 harness 強制的迭代、token 和時間上限。讓 worker 自己評自己的輸出，等於什麼都沒驗——解法是獨立的 checker 加上定在 loop 之外的 rubric。比沒有評分者更糟的，是一個「評什麼都過」的評分者，它會替爛輸出蓋上「已驗證」的章——解法是對抗式驗證（要求 checker 想辦法推翻結果）再配上定期人工抽查。還有一個很隱蔽的：能改 harness 程式碼的改進 loop，也有能力去改那些負責把關它的程式碼，所以權限和 budget 一定要放在這個 loop 改不到的地方。

💡 一句話記住這一層的取捨：沒有評分者的 loop，自動化的是工作；沒有 budget 的 loop，自動化的是帳單。 兩道關卡都到位，你才真的敢把手放開。

收尾

八篇走到這裡，你手上握著的已經不是零散的名詞，而是一張能拆解幾乎任何 agent 的地圖。寫程式的工具、聊天助理、自動執行器，它們之間的差別，多半就只在這八層 harness 的設計選擇上——同一個 agent loop，配不同的記憶、不同的權限、不同的驗證關卡，就長成了完全不同的產品。

如果這系列只留一個動作給你，我會希望是這個：把這個 repo clone 下來，挑一章、跑一次 test，再 diff 它和前一章的 src/。然後打開你天天在用的 Claude Code，試著把你剛剛在程式碼裡看到的那個機制，對應回它身上——你會突然看懂，原來 /loop、Workflow、budget 上限、subagent 這些東西，就是書裡那幾層的實體。那一刻，harness 對你就不再是黑盒子，而是一台你看得見每個齒輪、也知道怎麼自己組一台的機器。

Repo 在這裡，自己去跑一遍最實在：hardness1020/awesome-agent-architecture。