前一天我們談 Evaluation。

到這裡，我們已經能回答：

這次修改，真的讓 Agent 變好了嗎？

但很多 Agent 系統仍然有一個隱藏問題。

Agent 裡面雖然有 Loop，外面卻還是人類在當 Loop。

流程通常是：

人類丟 Task
↓
Agent 執行
↓
人類看結果
↓
覺得不對
↓
再補一段 Prompt
↓
Agent 再執行

人一離開，整個系統就停止。

這就是 Loop Engineering 要解決的問題。

它不是再加一個 while True，而是把：

發現工作 → 執行 → 驗證 → 修正 → 再執行 → 報告

設計成有 Stop Condition、有 Budget、有 State，而且可以無人值守的外層系統。

一句話先定義今天的主題：

Agent Loop 解決「怎麼做下一步」，Loop Engineering 解決「整個系統怎麼自己持續工作」。

第一個錯誤等號：有 Agent Loop = 有 Autonomous System

Day 2 的 Agent Loop 很小：

Model
↓
Tool
↓
Observation
↓
Model

它回答的是：

一個 Task 裡，Agent 怎麼持續做下一步？

但它沒有回答：

• Task 什麼時候開始？
• Model 說 Done 之後誰檢查？
• 檢查失敗要不要重跑？
• 重跑幾次？
• 沒有人在線時結果送去哪？
• 下次相同事件發生時誰重新啟動？
• Production Failure 怎麼變成下一輪 Improvement？

真正能自己運作的 Agent System，通常不是一個 Loop，而是多個 Loop 疊在一起。

四層 Loop

可以把整個系統拆成四層：

Improvement Loop
└── Event Loop
    └── Verification Loop
        └── Agent Loop

每一層回答不同問題。

1. Agent Loop：這一步怎麼做？

最內層就是 Day 2 的基本 Loop：

Call Model
↓
Tool Call
↓
Execute Tool
↓
Observation
↓
Call Model Again

這層負責：

• Tool Selection
• Tool Result
• Context
• Error Recovery
• Stop Reason

最後模型可能說：

Done。

但這只代表：

模型認為完成了。

不代表：

任務真的完成了。

所以需要第二層。

2. Verification Loop：真的完成了嗎？

Verification Loop 把 Model 的「完成宣告」變成可檢查的 Claim。

流程：

Worker
↓
Candidate
↓
Checker
↓
Pass?
├── Yes → Deliver
└── No
     ↓
   Feedback
     ↓
   Worker Retry

真正的改變是：

Done 從 Model Claim 變成 Checked Claim。

Worker 不應該自己當 Checker

最簡單的 Verification 是問原本 Agent：

你剛剛做對了嗎？

問題是它很容易替自己的結果找理由。

比較可靠的方式是：

Worker Agent
產生結果

Checker Agent
使用新的 Context 驗證

Checker 最好：

• 使用 Fresh Context
• 不讀 Worker 的自我辯護
• 使用固定 Rubric
• 不能修改 Rubric
• 回傳明確 PASS / FAIL 與原因

例如：

Rubric

1. 必須使用指定 Tool
2. 結果必須正確
3. 不可以 Fabricate Tool Result

Worker 可以改策略來滿足 Rubric。

但不能自己把 Rubric 改掉。

Feedback 要進入下一次 Attempt

如果 Checker 回：

FAIL

原因：
結果正確，但沒有使用要求的 Tool。

這個 Verdict 不應該只留在 Log。

它應該變成下一次 Worker 的 Observation：

Attempt 1
↓
Fail
↓
Reason
↓
Attempt 2

也就是：

Failure 不是終點，而是下一輪修正的輸入。

這才是一個真正閉合的 Verification Loop。

Verification Loop 一定要有 Budget

最危險的做法是：

while not passed:
    retry()

如果 Checker 永遠 Fail，這等於：

無限 Token Bill。

所以 Retry Ceiling 必須由 Harness 控制。

例如：

for attempt in range(2):
    result = worker(task)
    verdict = checker(task, result)

    if verdict["passed"]:
        return result

return escalate()

真正的 Stop Condition 是 range(2)。

不是 Prompt 裡寫：

最多試兩次。

因為模型不能把 range(2) 說服成 range(20)。

每個 Loop 都需要 Ceiling

這個原則不只適用 Verification。

每個外層 Loop 都應該有至少一種硬限制：

• Iteration Budget: 最多幾輪
• Token Budget: 最多花多少 Token
• Cost Budget: 最多花多少錢
• Wall-clock Budget: 最多跑多久
• Dry Counter: 連續幾輪沒有發現新資訊就停止
• Failure Budget: 同類 Failure 出現幾次就 Escalate

模型可以改策略。

但不能自己決定突破這些 Ceiling。

3. Event Loop：工作什麼時候開始？

前兩層回答的是：

Task 開始後怎麼完成？

但還沒回答：

Task 什麼時候開始？

這是 Event Loop。

Trigger 可能來自：

• User Message
• Cron
• Schedule
• Webhook
• GitHub Event
• Slack
• Email
• File Change
• Background Notification
• Remote Trigger

流程：

Event
↓
Create / Resume Task
↓
Verification Loop
↓
Agent Loop
↓
Result

所以 Always-on Agent 並不代表 Agent Loop 永遠不停止。

更合理的是：

Idle
↓
Event
↓
Wake
↓
Run
↓
Verify
↓
Persist
↓
Idle

Always-on 的核心是：

隨時可以被可靠喚醒。

不是永遠浪費 Token Polling。

4. Improvement Loop：系統怎麼變好？

Day 21 的 Observability 會產生：

• Trace
• Cost
• Failure
• Tool Error
• Permission Denial
• User Correction

Day 22 的 Evaluation 可以把這些 Failure 變成 Benchmark。

接著：

Production Trace
↓
Find Weakness
↓
Create Eval Case
↓
Change Harness / Skill / Prompt / Model
↓
Run Regression
↓
Better?
├── Yes → Deploy
└── No → Rollback

這就是 Improvement Loop。

Self-improvement 也需要外部 Gate

成熟的 Improvement Loop 甚至可以自己提出 Harness 修改。

例如：

過去 200 個 Coding Task 中，
18% 因為沒有跑 targeted tests 而 Fail。

系統提出：

Proposal:
加入新的 Verification Rule

然後：

Edit
↓
Regression Eval
↓
Safety Gate
↓
Human Approval
↓
Deploy

但有一條邊界不能消失：

負責修改 Harness 的 Loop，不能同時修改限制自己的 Gate。

它可以改：

• Skill
• Prompt
• Routing
• Verification Rule

但不應該可以自行移除：

• Permission
• Budget
• Regression Gate
• Approval Boundary

不然 Self-improvement 很容易變成 Self-escape。

Loop Engineering 沒有新增 Primitive

這一層和前面很不一樣。

Day 3 新增 Tool Runtime。

Day 9 新增 Context Manager。

Day 13 新增 Task System。

但 Loop Engineering 的核心不是新增一個 Component。

而是把前面已有的 Mechanism 組成閉環：

Trigger
Day 15 Scheduling / Day 20 Channels

Worker
Day 2 Agent Loop

Checker
Day 7 Subagent + Day 22 Evaluation

State
Day 10 Memory + Day 13 Task System

Isolation
Day 16 Worktree

Trace
Day 21 Observability

新的不是零件。

而是：

零件之間開始形成可收斂的 Feedback Loop。

三個 Maturity Level

Loop 不應該第一天就直接 Fully Autonomous。

可以分成三個成熟度。

L1：Report

Loop 只讀資料並報告。

例如：

每天掃描 CI Failure
↓
分析可能原因
↓
傳報告給人

真正的修改由人做。

風險最低。

L2：Assisted

Loop 可以準備 Change，但真正 Side Effect 需要 Approval。

例如：

發現 Dependency Vulnerability
↓
建立 Patch
↓
跑 Test
↓
建立 PR
↓
等待 Human Merge

Agent 已經完成大部分工作。

人類控制最後 Gate。

L3：Unattended

Loop 可以自己執行 Side Effect。

例如：

偵測問題
↓
修正
↓
驗證
↓
Deploy
↓
報告

這不是靠 Prompt 宣布：

你現在可以自主工作。

它其實是 Permission Decision。

Promotion 要靠 Evidence

不要：

今天第一次跑 L1

明天直接 L3

更合理的是：

L1
大量執行
↓
結果穩定
↓
L2
↓
Human Approval 幾乎總是接受
↓
L3

可以觀察：

• Pass Rate
• Human Override Rate
• False Positive
• Cost
• Safety Event
• Recovery Rate

原則是：

先在低權限下證明「無聊地正確」，再增加 Autonomy。

Loop Engineering 最核心的是 Verification

很多人談 Loop Engineering 會先想到：

• Cron
• Multi-Agent
• Memory
• Self-improvement

但真正讓 Loop 從「一直跑」變成「可以信任」的，是 Verification。

如果只有：

Agent
↓
Agent
↓
Agent
↓
Agent

只是把模型判斷重複很多次。

Verification 才建立：

Attempt
↓
Evidence
↓
Verdict
↓
Feedback
↓
New Attempt

這個 Feedback Loop 才有收斂方向。

Checker 也可能失敗

Verification Loop 不是萬靈丹。

假設 Checker 永遠回：

PASS

那只是多花一次 Model Call。

可以把這種情況叫：

Rubber-stamp Checker。

所以 Checker 本身也需要 Eval。

至少要測：

• Bad Output 是否 Fail
• Good Output 是否 Pass
• Adversarial Case
• Borderline Case
• Human Agreement

高風險任務還可以加入 Adversarial Verification：

主動找出這個結果可能錯在哪裡。

而不是只問：

看起來可以嗎？

State 不持久，Loop 只是在重做

假設每天 Scheduler 觸發：

掃描同一個 Repository

但每次都忘記昨天已經分析過：

Issue A
Issue B
Issue C

那 Agent 會每天重新 Discovery。

所以外層 Loop 要保存：

• Known Work
• Completed Work
• Last Checkpoint
• Pending Work
• Previous Verdict

沒有 Persistent State，就不是 Continuous Loop。

只是重複執行相同 Prompt。

Report Always

Unattended Loop 有一個很危險的 Failure Mode：

它安靜地壞掉。

所以不管：

• Success
• Fail
• Budget Exhausted
• Human Handoff
• Nothing Found

都應該留下報告。

例如：

Run completed

Scanned:
42 issues

Changed:
0

Skipped:
2

Failed:
1

Cost:
$0.31

Next run:
tomorrow 09:00

如果沒人知道 Loop 在做什麼，Autonomy 只是 Invisible Drift。

常見錯誤設計

1. Outer Loop 還是人

Agent 很自動，但每一輪都需要人重新 Prompt。

問題：

人一離開，系統就停。

2. Model 自己說 Done 就算 Done

沒有外部 Verification。

問題：

False Completion。

3. Verification 無限 Retry

沒有 Budget。

問題：

Token 與 Cost 無限增加。

4. Worker 自己 Grade

共享相同盲點。

問題：

Verification 變成 Self-approval。

5. Rubric 太寬鬆

Checker 幾乎永遠 Pass。

問題：

多一個 Loop，沒有多一份 Evidence。

6. 一開始就 L3

沒有先觀察 L1 / L2。

問題：

錯誤直接變成 Side Effect。

7. Improvement Loop 可以修改自己的 Gate

例如自己移除 Regression Test。

問題：

Self-improvement 變成 Self-escape。

8. 每次 Run 都失憶

沒有 Persistent State。

問題：

每天重做相同 Discovery。

如何設計第一版 Loop Engineering？

第一版不要先做 Self-improvement。

先做一個最簡單的 Verified Loop：

Trigger
↓
Worker
↓
Checker
↓
Pass?
├── Yes → Report
└── No
     ↓
   Feedback
     ↓
   Retry
     ↓
   Budget Exhausted?
   ├── No → Checker
   └── Yes → Human Handoff

再加五個硬限制：

Max Attempts
Token Budget
Cost Budget
Wall-clock Budget
No-progress Budget

接著才加入：

• Schedule
• Background
• Persistent State
• L1 → L2 → L3
• Improvement Loop

今天學到什麼？

Day 22 讓我們可以測一個 Agent Build。

今天把前面所有 Mechanism 組成四層 Loop：

Agent Loop
Verification Loop
Event Loop
Improvement Loop

並加入：

• Verification Feedback
• Separate Checker
• Fixed Rubric
• Hard Budget
• Maturity Level
• Persistent State
• Always-delivered Report
• Improvement Gate

這時 Agent 不只是：

接到 Prompt 後執行。

而開始變成：

一個可以被 Trigger、自己執行、自己檢查、失敗後修正，最後留下 Evidence 的系統。

今天的結論

Loop Engineering 真正的轉變不是：

Agent 變得更 Autonomous。

而是：

人類從每一輪的 Operator，變成外層 Loop 的 Designer。

最重要的原則是：

Grade before done. Budget before start. Report even when nobody is watching.

但 Loop 還有一個問題。

很多 Workflow 的路徑其實一開始就知道：

先 classify
再 execute
最後 review

review fail
一定回去修正

這些 Transition 真的還需要每一輪問模型：

下一步要做什麼嗎？

下一篇會進入 Graph Engineering：

已知的 Control Flow 寫進 Code，真正需要 Judgment 的地方才花 Model Token。

完整系列與程式碼範例收錄於 https://github.com/hardness1020/awesome-agent-architecture