常見的解釋是：
不要只設計下一個 Prompt，要設計一個能持續執行、取得回饋並改善結果的 Loop。
這個方向沒有錯，但對工程師來說還是不夠具體。
真正開始實作時，問題馬上就會出現：
先講結論：
Loop Engineering 不是把 Agent 放進
while True，而是設計 Agent 外面的系統，讓它能自動發現工作、執行、驗證、控制預算、保存結果，並決定下一步。
如果沒有這層系統，人類其實就是那個 Outer Loop。
我們手動輸入 Prompt、閱讀答案、判斷對錯、補充資訊，再要求 Agent 重做。人一離開，工作也就停止了。
Loop Engineering 要做的事情，是把這些原本由人類手動完成的控制流程，變成明確、可驗證的系統。
要理解 Loop Engineering，可以先把系統拆成四個不同層級。
hardness1020
Trigger
↓
Agent Loop
↓
Candidate Output
↓
Verifier
├── Pass → Deliver
├── Fail → Feedback → Retry
└── Budget exhausted → Escalate to human
Execution Trace
↓
Evaluate failures
↓
Improve harness, skill or model
這裡其實包含四個 Loop。
這是最基礎的 Agent Loop：
messages → LLM → tool call → tool result → messages → LLM
模型提出工具呼叫，Harness 執行工具，將結果放回 messages[]，再呼叫模型。
def run_agent(messages, tools):
while True:
response = call_model(messages, tools)
messages.append(response)
if response.has_tool_call:
result = execute_tool(response.tool_call)
messages.append(to_tool_result(result))
continue
return response.text
這個 Loop 回答的是：
Agent 如何完成一次工作？
但它有一個很大的問題。
它通常會在模型認為自己完成時停止。
模型可能說：
但它不一定真的執行過測試，也不一定符合原始需求。
因此，只有 Agent Loop 還不夠。
Verification Loop 包在 Agent Loop 外面。
Agent Loop 先產生一個 Candidate Output，再交給獨立的 Checker 驗證。
如果通過，就交付結果。
如果失敗，就把失敗原因變成下一輪的 Feedback。
def verified_run(task, worker, checker, rubric, max_attempts=2):
feedback = None
attempts = []
for attempt in range(1, max_attempts + 1):
candidate = worker(
task=task,
feedback=feedback,
)
verdict = checker(
task=task,
output=candidate,
rubric=rubric,
)
attempts.append({
"attempt": attempt,
"passed": verdict.passed,
"reason": verdict.reason,
})
if verdict.passed:
return {
"ok": True,
"output": candidate,
"attempts": attempts,
}
feedback = {
"previous_output": candidate,
"failure_reason": verdict.reason,
}
return {
"ok": False,
"output": None,
"attempts": attempts,
"action": "escalate_to_human",
}
這段程式碼看起來不複雜，但有四個重要的設計決定。
如果同一個 Agent 同時負責產生答案和判斷答案是否正確，它通常很容易接受自己的結果。
比較可靠的方式是使用 Maker-Checker 分工：
Checker 每次驗證時都應該使用新的 Context，不應繼承 Worker 的推理過程。
def check(task, output, rubric):
messages = [{
"role": "user",
"content": build_review_prompt(
task=task,
output=output,
rubric=rubric,
),
}]
return run_checker_with_fresh_context(messages)
這不是為了讓 Checker 比 Worker 更聰明，而是避免它被 Worker 的推理和自我辯護影響。
Agent 可以努力滿足 Rubric，但不能修改 Rubric。
例如，程式修改任務的驗證條件可以是：
1. 所有既有測試必須通過
2. 必須新增對應的回歸測試
3. 不得刪除或跳過失敗測試
4. 修改範圍不得超出指定模組
如果 Agent 可以自己改寫完成標準，它可能會透過降低標準來讓自己通過。
所以 Rubric、權限和預算，應該由 Agent 無法修改的外層 Harness 控制。
驗證失敗不能只回傳一句：
再試一次。
下一輪需要知道：
例如：
Previous attempt:
新增了 API endpoint，但沒有新增 authorization test。
Verification result:
FAIL
Reason:
需求要求未授權使用者收到 403，目前測試只覆蓋成功路徑。
Required correction:
新增未授權情境測試，確認 endpoint 回傳 403。
這樣第二輪不是重新猜測，而是根據具體失敗證據修正。
每個 Loop 都需要一個模型無法突破的上限。
可以是：
最簡單的 Budget 就是：
for attempt in range(max_attempts):
...
當 max_attempts 是 2，就不可能出現第三次執行。
這和在 Prompt 裡寫「最多嘗試兩次」不同。
Prompt 是建議，程式碼才是限制。
當預算耗盡時，正確的結果不是繼續祈禱下一輪會成功，而是：
ok = false
action = escalate_to_human
沒有 Verifier 的 Loop 只是在自動化產出；沒有 Budget 的 Loop 則是在自動化帳單。
前兩層 Loop 解決了「如何執行」和「是否完成」，但任務仍然需要有人手動啟動。
Event Loop 負責決定工作什麼時候開始。
Trigger 可能來自：
例如：
def on_event(event):
task = convert_event_to_task(event)
result = verified_run(
task=task,
worker=worker,
checker=checker,
rubric=select_rubric(task),
max_attempts=2,
)
persist_result(task, result)
deliver_report(result)
這一層回答的是：
Agent 什麼時候應該開始工作？
但 Event Loop 不應該直接把所有 Trigger 都變成具有寫入權限的自主工作。
比較安全的方式是逐步提高自治程度。
可以將 Loop 分成三個等級。
Loop 只讀取資料並產生報告。
例如：
人類閱讀報告後，再決定是否採取行動。
Loop 可以準備修改，但需要人類批准。
例如：
人類確認後才合併或執行。
Loop 可以直接採取行動，人類在事後稽核。
例如：
不要一開始就給 Loop L3 權限。
比較可靠的升級方式是：
L1 長期產生正確報告
↓
L2 產生的變更長期可直接批准
↓
L3 才取得有限、自動化的寫入權限
自治程度本質上是權限設計，不是 Agent 聰明程度。
當系統開始持續執行後，會累積大量 Trace：
Improvement Loop 使用這些資料改善：
例如，每週可以執行一次失敗分析：
def improve_harness(traces, regression_set):
repeated_failures = mine_failure_patterns(traces)
proposal = propose_bounded_change(repeated_failures)
evaluation = run_regression_test(
change=proposal,
dataset=regression_set,
)
if evaluation.is_better:
return submit_for_review(proposal)
return reject_change(proposal)
這裡最重要的仍然是外部限制。
負責改善 Harness 的 Agent，不能同時修改：
否則 Improvement Loop 可能透過移除限制，讓自己的評分看起來更好。
Loop Engineering 的關鍵不是增加一個新的 Agent 元件，而是把既有元件組合起來：
所以 Loop Engineering 比較像是一種 Composition Discipline。
它把單次 Agent Call，組合成一個可以持續運作的系統。
Agent 不斷收到「繼續改善」，直到 Token 或預算耗盡。
解法是由 Harness 強制限制嘗試次數、時間和成本。
同一個 Context 同時產生答案與判斷答案，導致驗證形同虛設。
解法是使用獨立 Checker、全新 Context 和固定 Rubric。
有 Verifier 不代表有有效驗證。
如果 Rubric 太模糊，Checker 可能每次都回傳通過。
解法是使用可觀察證據、對抗式檢查，以及定期人工抽查。
系統還沒有證明 L1 報告可靠，就直接取得 L3 寫入與部署權限。
解法是逐層提高成熟度，並限制每類任務的權限範圍。
如果狀態沒有持久化，每次 Event 都會重新發現相同問題、重做相同工作。
解法是保存 Task Record、驗證結果、已處理項目和執行 Trace。
如果 Agent 可以修改驗證、Budget 或 Permission，它可能繞過原本的安全邊界。
解法是讓關鍵 Gate 存在於 Loop 無法修改的外層系統。
不需要一開始就建立完整的 Autonomous Agent System。
可以先挑一個範圍明確、容易驗證的任務。
例如：
每天檢查 Repository 中失敗的 CI，找出可能原因並產生修正建議。
第一版只做 L1：
等它長期穩定後，再升級成 L2：
只有當這些 Pull Request 長期都能直接批准時，才考慮讓特定、低風險任務升級成 L3。
很多人把 Loop Engineering 理解成：
讓 Agent 一直跑，直到完成。
但真正的工程問題不是如何讓它一直跑。
而是：
一個真正可用的 Loop，應該具備：
Trigger
+ Agent
+ Independent Verification
+ Feedback
+ Hard Budget
+ Persistent State
+ Escalation
+ Trace
+ Improvement
我最近在開源專案 Awesome Agent Architecture 中，將現代 Agent Harness 拆成 22 個循序漸進的 Sections。
專案從最小 Agent Loop 開始，逐步加入 Tool Runtime、Permission、Hooks、Planning、Subagent、Skills、Context Management、Memory、Task System、Scheduling、Multi-Agent Coordination、Evaluation，最後在 Section 21 將這些機制組合成 Loop Engineering。
Sections 1 到 21 都有可執行的 Python 範例，可以直接比較相鄰章節，觀察每一層新增了什麼機制。
https://github.com/hardness1020/awesome-agent-architecture
如果你已經知道怎麼呼叫 LLM 和 Tools，但還不清楚如何把它們組合成可以長時間運作的 Agent System，可以直接從 Section 1 的 Agent Loop 開始，再一路看到 Section 21。
Loop Engineering 的目標不是移除人類。
它真正做的是把人類從每一輪的操作員，移到整個系統的設計者。
這篇對 loop 的用處定義好讚，我現在終於懂 loop 實際的功能了，有點像是 ai 界的 unittest 的感覺
希望版主能夠寫一篇關於 harness 的實例🙏🙏🙏🙏
拍謝我沒看完文章就急著表達我但感嘆了，我現在才注意到版主分享的資源有 harness 的範例😅😅😅
看影片追技術