Table of Contents
🤖 做出一個會跑的 AI Agent 不難，難的是讓它在沒人盯著的時候，每天跑幾百次都不出事。多數 Agent 死在 demo 到上線之間。原因不是模型不夠聰明——demo 和上線用的是同一個模型。真正的差別是：demo 時旁邊坐著一個人，看它繞圈就按 Ctrl+C、看它要刪檔案就先攔下來。上線之後，那個人不見了，而沒有任何東西補上他的位置。
一個生產級 Agent 要同時回答兩個問題：
🔁 接下來該做什麼？—— 這是 Loop，Agent 的判斷
🚧 什麼是它不能做的？—— 這是 Harness，Agent 的邊界
兩條軸互不相干。換更強的模型只會讓判斷變好，邊界一動也不動。這件事醫院早就知道了：醫師自己複核處方是自檢，藥師獨立審核是稽核，兩者不是同一道防線。再好的醫師，也不能沒有醫院。🏥 第一個問題模型會越答越好。第二個問題，永遠要你自己答。
It Can Think — But Who Draws the Line? Two Axes of Production-Grade AI Agents: Loop and Harness
一、Demo 裡那個按 Ctrl+C 的人，上線後去哪了？
過去一年，做出一個能跑的 AI Agent 已經不難。拉一個開源框架，接上模型，給幾個工具，半天就能有一個會查資料、會寫程式、會幫你訂會議室的 demo。難的是下一步：把它放進真正的環境裡，讓它在沒有人盯著的情況下，每天跑幾百次。
多數 Agent 就死在這一步。症狀大同小異：跑到一半開始繞圈、一個任務燒掉幾十萬 token、對不該動的資料動了手、或者更常見——安安靜靜地給出一個看起來合理但其實錯了的結果。
大家的第一反應通常是「模型還不夠聰明」。但仔細想想，demo 裡的模型和上線後的模型是同一個。推理能力沒有變，變的是環境。
demo 的時候，旁邊坐著一個人。他看到 Agent 繞圈就按 Ctrl+C，看到它要刪檔案就先攔下來，看到成本不對就停掉重來。這個人就是 Agent 的邊界、預算、審批和稽核——只是他自己沒有意識到。
上線之後，這個人不見了。而沒有任何東西補上他的位置。
這就是本文想講的事：一個能進生產環境的 Agent，需要同時回答兩個完全不同的問題，而多數人只回答了第一個。
二、兩個問題，兩條軸
產品經理 Greg Coquillo 畫過一張很流行的資訊圖，把 Agent 開發拆成 Loop Engineering 和 Harness Engineering 兩件事。圖的最下面有一張對照表，其中一列我認為是整張圖最準確的一句話：
- Loop 問的是：接下來該做什麼？（What should happen next?）
- Harness 問的是：什麼是被允許、被提供的？（What is allowed and available?）
先說明一下，這兩個詞不是通行的學術術語。「Harness」近一年主要出現在 OpenAI、Anthropic 的工程文章裡，指模型外圍那一整套執行環境；「Loop Engineering」則比較像原作者為了對仗自創的說法。本文借用這組框架，但把它整理成我自己覺得更站得住的版本。
Loop：Agent 的行為策略
Loop 定義 Agent 如何一圈一圈地把任務做完。壓縮成最短的節奏，大概是：
看（讀取輸入、狀態、記憶）、想（決定下一步）、做（呼叫工具、查資料庫、打 API）、查（檢查結果對不對、安不安全）、記（更新狀態）、然後判斷：任務完成了嗎？沒完成就再繞一圈，完成了就輸出。
Loop 工程要處理的是：怎麼決定下一步、失敗了怎麼重試或換策略、什麼時候該停、怎麼驗證自己做的對不對。它是 Agent 的判斷。
Harness：Agent 的運行約束
Harness 不參與判斷，它決定判斷可以在什麼範圍內發生。它組裝上下文、管理記憶與狀態、限制能用哪些工具和權限、設定防護欄和人工審批的關卡、限制重試次數、token 預算和超時、記錄所有軌跡。
Harness 工程要處理的是：這個 Agent 到底能碰什麼、不能碰什麼、花到多少要停、什麼事必須有人簽字。它是 Agent 的邊界。
為什麼不是內外層
很多人會把這兩者畫成同心圓：Loop 在裡面，Harness 包在外面。這個畫法有個問題——在實際的系統裡，loop 本身就是寫在 harness 裡的程式碼，說「loop 在 harness 裡面」是廢話，說「harness 包住 loop」則沒有說出任何有用的東西。
更好的畫法是兩條正交的軸。一條軸是「判斷得好不好」，一條軸是「約束得緊不緊」。任何一個 Agent 都可以在這兩條軸上分別打分數，而且分數互不相干。
三、四個象限：你的 Agent 死在哪一格
把兩條軸交叉，會得到四種 Agent：
值得注意的是右下角那一格。多數團隊卡在這裡，而且卡得很委屈——他們花了最多力氣把 Loop 做好，模型也確實聰明，但就是不敢上線。原因不是判斷不好，而是根本沒有邊界。他們一直在做 Loop 工程，以為再多做一點就能上線，但問題出在另一條軸上，再怎麼優化 Loop 都到不了上面那一排。
這也解釋了為什麼「換更強的模型」常常沒有幫助。更強的模型讓 Agent 在橫軸上往右移，但縱軸一動也不動。
四、為什麼同一個東西會出現在兩邊
看過 Loop / Harness 框架的人，很快會發現一件怪事：有些元件兩邊都有。
- 記憶：Loop 說「整個循環裡都在讀寫記憶」，Harness 那邊又列了「記憶與狀態管理」。
- 重試：Loop 有「失敗恢復、重試、重新規劃」，Harness 有「重試次數上限、預算、超時」。
- 觀測：Loop 有「日誌、評估」，Harness 也有「軌跡、指標、評估」。
到底誰管？
答案可以濃縮成一句話：Harness 擁有資源，Loop 使用資源。
用重試當例子最清楚。Loop 決定的是「這一次失敗了，我要不要再試一次？換一種方法還是換一個工具？」——這是判斷。Harness 決定的是「不管你怎麼判斷，最多讓你試三次」——這是上限。兩者不衝突，甚至必須同時存在：沒有 Loop 的重試策略，Agent 遇到暫時性錯誤就放棄；沒有 Harness 的重試上限，Agent 遇到永久性錯誤就無限繞圈。
記憶也一樣。Harness 決定記憶存在哪、能存多久、Agent 能看到哪一段；Loop 決定這一步要讀什麼、要寫什麼。觀測也一樣：Harness 保證每一步都留下軌跡，這是 Agent 無法關掉的；Loop 則利用這些軌跡來評估自己做得好不好。
所以每一個能力其實都有兩個面向：決策面歸 Loop，約束面歸 Harness。一個東西出現在兩邊不是框架的矛盾，而是框架在提醒你：每個能力都要問兩次——它怎麼用，以及它的上限在哪。
五、誰擋得住誰：自檢與稽核不是同一道防線
Loop 裡有一步叫「查」（Verify），Harness 裡有一項叫「防護欄」（Guardrails）。兩者聽起來都是「檢查」，但有一個根本差別，原始框架沒有標出來：
Loop 的 Verify 是 Agent 自己檢查自己；Harness 的 Guardrail 是 Agent 繞不過的檢查。
Agent 在 Loop 裡驗證結果的時候，用的是同一個模型、同一段上下文、同一套判斷。如果它的判斷本來就偏了，驗證的時候多半也會偏在同一個方向。這不是模型的缺陷，任何自我檢查都有這個限制——你複查自己寫的東西，會漏掉的往往就是你一開始就沒看到的那種錯。
Harness 的防護欄則站在 Agent 的判斷之外。它不管 Agent 覺得這一步對不對，它只看這一步有沒有超出邊界：要刪的是不是生產資料庫、要寄的信是不是給客戶、要花的錢有沒有超過額度。Agent 說服不了它，因為它根本不聽 Agent 的理由。
醫院早就知道這件事
如果你在醫院工作，這個結構會非常眼熟。
一位醫師開藥前會自己複核一遍：劑量對不對、有沒有過敏、有沒有交互作用。這是 Loop 裡的 Verify——負責任的醫師都會做，但它是自檢。
處方送出後，藥師會獨立審核一次。醫師說「我已經看過了」沒有用，藥師照樣審。系統裡的高警訊藥品會跳 hard stop，超過最大劑量開不出去，不管開的人是誰。這是 Harness 的 Guardrail——它不信任判斷，它信任邊界。
再往外看，整間醫院其實就是一套 Harness：
- 專科執業許可（privileging）決定你能開哪些醫囑——這是工具權限。
- 醫囑系統的 hard stop 與用量警示——這是防護欄與運行控制。
- 住院醫師的處置要主治醫師 co-sign——這是人類審批（human-in-the-loop）。
- 病歷與稽核軌跡——這是可觀測性，而且是醫師無法選擇不留的。
而每一位醫師腦中的臨床推理循環——評估、處置、再評估——就是 Loop。
醫院用了幾十年學到的結論是：再好的醫師也不能沒有系統。這句話不是在懷疑醫師，而是在承認判斷本身的極限。我在〈防線不是為了刁難誰〉那篇寫過的多層防線，講的就是這件事：防線的意義不在於誰比較不可信，而在於單一判斷點一定會失效，所以要有一道判斷點之外的東西。
AI Agent 只是讓這個老問題換了一個主角。
六、邊界會移動，但治理不會消失
有一個合理的質疑：模型越來越強，Loop 裡很多手寫的東西——顯式的規劃步驟、自我批評、重試策略——正在被模型內化。那 Harness 會不會也一樣，最後被模型吃掉？
我的看法是：一半會，一半永遠不會。
會被吃掉的那一半，是「能力」性質的東西。今天要在 Loop 裡手寫的 replan 邏輯，明年可能模型自己就會做。今天要在 Harness 裡幫它組裝的上下文，以後模型可能自己會去拿。這條邊界確實會往模型那邊移，而且移得很快。
永遠不會被吃掉的那一半，是「治理」性質的東西：權限、預算、審批、稽核軌跡。這些不是模型做不到，而是不應該由模型決定。一個 Agent 再聰明，也不該由它自己決定自己能碰哪些資料、能花多少錢、哪些事要問人。就像一位醫師再資深，也不該由他自己決定自己的執業範圍和是否需要被稽核。
這是判斷和邊界的根本差別：判斷可以委託給越來越強的模型，邊界必須留在模型之外——因為邊界的意義，就是它不隨判斷而改變。
Greg Coquillo 的圖裡有一句話被放在一個很小的框裡，我覺得它應該是全圖最大的字：
Frameworks may help, but the discipline is still yours.
框架能給你 Loop，很少能給你 Harness。因為 Harness 綁的是你的組織：你的資料在哪、你的權限怎麼分、你的預算有多少、你的哪些決定必須有人簽字。沒有任何開源框架能替你回答這些問題。
七、結語：內修判斷，外築邊界
回到開頭那個 demo 裡按 Ctrl+C 的人。
他不是多餘的。他在做的事，是這個 Agent 要上線前必須被寫成程式的那一半。Loop 工程做得再好，只是讓那個人可以少按幾次；Harness 工程做的，是讓那個人可以離開房間。
所以下次有人問「這個 Agent 為什麼還不能上線」，先別急著換模型。先問兩個問題：
它知道接下來該做什麼嗎？——這是 Loop。
它知道什麼是它不能做的嗎？——這是 Harness。
第一個問題模型會越答越好。第二個問題，永遠要你自己答。
參考與延伸
Greg Coquillo, Loop Engineering vs Harness Engineering（資訊圖，LinkedIn）
本站〈防線不是為了刁難誰〉——多層防線的系統設計
本站〈交班的藝術：用醫院的方法，管理 AI 的 Context〉——Harness 中「上下文組裝」的醫院類比