說在前面：這又是一篇講Harness的Survey，你最近可能已經看過了數篇講Harness的文章、論文，其中還可能包括我上週解讀的《Agent Harness Engineering：Agent的底盤工程綜述｜CMU、耶魯、Amazon》。
上週的《Agent Harness Survey》更像是在回答一個系統架構問題：一個真正可用的 Agent，外面應該包哪些東西？
而UIUC、Meta、Stanford這篇最新綜述關心的是另一個問題：當Agent被放進長期任務環境裡，真正把推理、行動、回饋、驗證和協作串起來的操作對象是什麼？
他們給出的答案是：程式碼化的執行過程。
這裡的「程式碼」不是指Agent框架本身由程式碼寫成，這當然是常識。它指的是Agent在執行任務時不斷生成、執行、修改、儲存和共享的一系列中間產物。具象到實際的工程場景中，就是Claude Code生成的Plan.md，或者產出的Skills.md，驗證用的Python檔案等等。
這篇綜述原文長102頁，引用Reference有478篇，本文將為您直接抽絲剝繭，用最快的速度看懂這三大頂級機構是如何打通Claude Code到機器人Agent的底層運作邏輯的。
這篇論文如何定義Harness？
在深入技術細節之前，我們需要先釐清幾個核心概念。
為什麼需要「鷹架（Harness）」？
一個純粹的大型語言模型是無狀態的，它本質上只是在預測下一個詞。為了讓它變成一個能夠執行長期任務的「智慧體」，我們需要在模型外圍包裹一層軟體基礎設施。這層基礎設施包括：
- 工具和API介面
- 安全的沙盒執行環境
- 記憶與上下文管理系統
- 驗證器與權限邊界
- 執行與回饋的控制迴圈
這整套外圍系統，就被研究者稱為智慧體鷹架（Agent Harness）。
為什麼「程式碼」是最佳的鷹架媒介？
研究者指出，程式碼具備自然語言所不具備的三大核心特質：
可執行性（Executable）：程式碼可以直接在電腦上執行，產出明確的客觀結果。
可檢查性（Inspectable）：程式碼的執行過程會產生堆疊、日誌和報錯，這些是可以被精確追蹤和分析的。
狀態化（Stateful）：程式碼環境（如檔案系統、資料庫）可以持久化儲存任務的進度。
基於這三大特質，研究者建構了一個三層架構來系統性地拆解程式碼在智慧體中的角色：鷹架介面層、鷹架機制層以及多智慧體擴展層。
論文將程式碼作為智慧體鷹架拆成三層：介面層讓程式碼承載推理、行動和環境建模，機制層負責規劃、記憶、工具、控制與最佳化，多智慧體層則把程式碼儲存庫、測試、軌跡和執行狀態變成協作基底。
第一層：鷹架介面
在這一層，程式碼充當了智慧體與現實世界溝通的基礎介面。它具體表現在三個方面：用於推理、用於行動、用於環境建模。
介面層的核心是把模型輸出接到可執行程式、工具呼叫、狀態追蹤和回饋軌跡上，使推理可驗證、行動可落地、環境變化可觀察。
論文按程式碼在推理、行動和環境建模中的不同角色整理代表工作，展示這一層如何從程式輔助推理擴展到機器人控制、GUI/OS操作和軟體工程評測環境。
用於推理的程式碼（Code for Reasoning）
早期的智慧體通常依賴純文字的「思維鏈（CoT）」進行推理，但這往往會導致邏輯錯誤或計算不準確。將推理過程轉化為程式碼，可以讓外部直譯器或求解器來驗證邏輯。
程序委託推理：模型不再直接輸出計算結果，而是生成一段Python腳本，交給Python直譯器執行。這種方式將高層的邏輯分解與底層的精確計算徹底剝離。
形式化驗證與符號推理：結合如Lean等形式化證明語言，讓智慧體的每一步推理都能夠被機器驗證器自動校驗。這在數學定理證明和高安全性程式碼驗證中尤為關鍵。
迭代式基於程式碼的推理：智慧體透過「生成程式碼 -> 執行程式碼 -> 獲取報錯回饋 -> 修正程式碼」的閉環，利用真實的執行軌跡來引導下一步的推理方向。
用於行動的程式碼（Code for Acting）
當智慧體需要與物理世界（機器人）或數位世界（軟體GUI）互動時，程式碼就成了它的執行載體。
基於環境約束的技能選擇：智慧體不直接生成底層的物理控制指令，而是呼叫預先寫好的、符合物理規律的程式碼技能庫（如SayCan系統），確保動作的可行性。
程序化的策略生成：智慧體直接編寫包含條件分支、迴圈的控制腳本。例如，生成一段完整的Python行為樹程式碼，來精細化地控制機械手臂的運動。
終身程式碼智慧體：智慧體在長期的執行中，不斷將成功解決問題的操作封裝成新的程式碼函式，存入長期「技能庫」中（如著名的Voyager系統），實現能力的持續進化。
用於環境建模的程式碼（Code for Environment）
環境的狀態往往是複雜且動態的，用純文字很難精確描述。程式碼可以將環境具象化為可操作的物件。
結構化的世界表示：用程式碼中的類別、物件關係或樹狀結構（如網頁的DOM樹）來精確刻畫當前環境的空間和邏輯結構。
基於執行軌跡的世界建模：智慧體透過閱讀程式碼的執行日誌、測試結果，來推斷環境狀態發生了什麼改變，從而建立起對環境動態變化的預測模型。
可驗證的環境建構：利用單元測試、測試樁（Mock）等程式碼工程手段，為智慧體建構一個具備客觀對錯評判標準的微型世界。
第二層：鷹架機制
有了底層的介面，智慧體還需要一套複雜的機制來保證它在長達數小時甚至數天的任務中不崩潰。研究者將這些機制歸納為五大模組。
機制層覆蓋規劃、記憶、工具使用、控制迴圈和鷹架最佳化五類問題，強調智慧體可靠性來自模型判斷、可變任務狀態和受治理的執行時基礎設施共同作用。
智慧體的規劃機制（Planning）
處理複雜的軟體工程任務，智慧體必須要有清晰的執行路徑。
規劃機制可以是單路徑的步驟拆解，也可以利用顯式結構、多路徑搜尋或系統級工作流編排來控制長週期任務的執行軌跡。
線性分解規劃：將大任務拆解為線性的步驟列表（如生成一份
PLAN.md檔案），智慧體嚴格按照步驟生成程式碼。基於結構的規劃：利用程式碼儲存庫的依賴圖譜（AST、類別關係圖）來指導操作順序。智慧體能夠知道修改這個函式會影響哪些其他檔案，從而制定更安全的修改計畫。
基於搜尋的規劃：引入蒙地卡羅樹搜尋（MCTS）等演算法。在生成程式碼時探索多個可能的分支，遇到走不通的路徑時，能夠利用報錯資訊進行回溯。
基於編排的規劃：將任務劃分為理解、檢索、編碼、測試等不同的流水線階段，透過系統級別的流程調度來控制智慧體的下一步行動。
記憶與上下文工程（Memory and Context Engineering）
處理百萬行級別的程式碼庫，大型模型極其容易受限於上下文長度限制，因此需要極強的記憶體治理方案。
記憶層把工作記憶、語義記憶、經驗記憶、長期記憶、多智慧體記憶以及上下文壓縮統一到同一個狀態治理問題中，目標是在有限上下文內保留真正影響任務成敗的證據。
工作記憶（Working Memory）：嚴格管理當前正在編輯的局部狀態（如當前檔案的行號、最近的幾條報錯日誌），防止上下文被無關資訊淹沒。
語義記憶（Semantic Memory）：利用檢索增強生成（RAG）技術，從龐大的程式碼儲存庫中精準調取相關的類別定義、API介面和歷史文件。
經驗與長期記憶（Experiential Memory）：智慧體將過去排查Bug的經驗、成功驗證的補丁等，轉化為結構化的經驗庫，實現跨任務的知識重用。
上下文壓縮與卸載：當日誌過長時，系統會自動對其進行粗細粒度的壓縮，或者將完整的日誌儲存到外部檔案中，只在提示詞中保留關鍵的摘要。
工具使用（Tool Use）
工具是智慧體改變外部世界的手段，但在程式碼鷹架中，工具的使用必須受到嚴格的管控。
工具層不僅包括函式呼叫和外部API，也包括終端機、儲存庫、沙盒、驗證器和多步驟工作流；關鍵問題是讓工具可發現、可呼叫、可審計並能在失敗時恢復。
功能導向工具：用於補充模型欠缺的知識，例如呼叫外部API搜尋文件、查詢特定的庫函式用法。
環境互動工具：允許智慧體直接在真實環境中操作，如執行終端機命令（Shell）、進行檔案讀寫、導航程式碼儲存庫。
驗證驅動工具：使用程式碼檢查器（Linter）、型別檢查器或單元測試框架，為智慧體的輸出提供決定性的客觀回饋。
工作流編排工具：負責調度多個子工具的呼叫順序，並處理工具呼叫失敗時的異常恢復。
計畫-執行-驗證迴圈（PEV Loop）
研究者指出，Agent的除錯過程本質上是一個控制論問題，應當被框架化為PEV迴圈（Plan-Execute-Verify）。
PEV迴圈將規劃、沙盒執行、靜態/動態驗證和權限控制組織成可重複的狀態轉換流程，使智慧體的每次修改都能被觀測、判斷和必要時回滾或升級給人類。
計畫（Plan）：將使用者需求轉化為明確的操作契約，確定要修改的範圍。
執行（Execute）：必須在沙盒環境（Sandboxed Execution）中執行。透過隔離的檔案系統和分級的權限控制，確保智慧體的破壞性操作不會影響宿主機的安全。
驗證（Verify）：利用靜態分析和動態測試作為「決定性感測器」。如果測試失敗，智慧體必須根據日誌進行修復；如果涉及高風險操作，必須強制接入人類審批（Human-in-the-loop）。
自適應鷹架工程（Agentic Harness Engineering）
這是該論文提出的一個極其前沿的概念。系統不應該僅僅停留在修復程式碼本身，還應該能夠自動最佳化包圍在模型外圍的「鷹架」。
自適應鷹架工程把提示詞、檢索策略、工具描述、驗證器、權限規則和工作流本身都視為可最佳化物件；但這些修改必須經過軌跡回放、保留任務評測和治理規則約束。
深度遙測（Deep Telemetry）：全面記錄智慧體的Token消耗、延遲、工具呼叫成功率以及完整的執行軌跡。
進化智慧體（Evolution Agent）：專門設立一個元級別的智慧體，它不寫業務程式碼，而是分析遙測資料，自動修改檢索策略、更新提示詞模板或重構沙盒規則，從而讓整個系統越來越穩定。
第三層：擴展鷹架
面對真實的、極度複雜的企業級需求，單一智慧體的上下文和能力很容易達到瓶頸。引入多智慧體協同（MAS）是必然趨勢。在這個階段，程式碼正式成為了各個智慧體之間溝通、協同與達成共識的「共享基底」。
多智慧體擴展層透過角色專業化、共享程式碼基底、執行回饋和自適應協作拓撲，緩解單智慧體在上下文、專業能力和自我糾錯上的瓶頸。
角色分工（Role Specialization）
系統會模仿人類的軟體開發團隊，拆分出高度專業化的角色：
程式設計師（Coder）：負責具體的程式碼編寫。
測試員（Tester）：專門編寫刁鑽的測試案例，刻意尋找程式設計師程式碼中的漏洞。
審查員（Reviewer）：對程式碼進行架構和規範層面的審查。
執行者（Executor）：負責在沙盒中執行程式碼並收集客觀的報錯日誌。
規劃經理（Manager）：負責全局的任務拆解和流程調度。
互動模式（Interaction Modes）
結對程式設計（Collaborative Synthesis）：兩個智慧體共同建構程式碼，一個負責導航和規劃，一個負責具體實作。
審查與修復（Critique and repair）：最常見的模式，驗證智慧體提出批評，程式設計智慧體據此修改。
對抗性驗證（Adversarial validation）：利用模糊測試（Fuzzing）等手段，生成極端輸入來刻意觸發崩潰，並將崩潰軌跡回饋給程式設計者。
推理辯論（Reasoning debate）：多個智慧體對需求理解或程式碼規範產生分歧時，透過多輪對話達成共識。
核心陣地：共享的程式狀態（Shared Program State）
研究者嚴厲指出，目前許多多智慧體系統僅僅依靠「聊天記錄」來傳遞訊息，這會導致嚴重的「狀態發散」，不同智慧體對程式碼當前到底是什麼樣產生了認知錯位。
未來的多智慧體系統必須建立基於程式碼的客觀全域共享狀態：
- 無論是透過真實的Git儲存庫、記憶體中的黑板架構（Blackboard），還是完整的執行上下文。
「共識」不應該僅僅是幾個智慧體互相說「看起來不錯」，而必須是客觀的測試全量通過、靜態檢查無警告、效能指標達標。
論文進一步把多智慧體協同拆為工作流協作、共享儲存庫狀態、執行驗證和自適應協調四類問題，強調協作必須落在可檢查的程式狀態上，而不是只停留在對話記錄中。
五大前沿應用領域
「程式碼作為智慧體鷹架」的理念，目前已經在以下五個真實應用場景中落地開花：
論文將落地場景概括為程式碼助手、GUI/OS智慧體、科學發現、個人化推薦和具身智慧體，說明程式碼鷹架正在從軟體工程擴展到數位介面、科研流水線和物理世界控制。
AI程式設計助手（Code Assistants）
從早期的單純程式碼補全（如早期的Copilot），進化為能夠處理GitHub Issue的「自動化研發員工」（如SWE-agent、OpenHands）。它們能夠自主拉取程式碼、閱讀報錯、在本地沙盒中不斷試錯並最終提交Pull Request。在這個過程中，沙盒、測試框架和Git版本控制就是它們的鷹架。
GUI/作業系統智慧體（GUI/OS Agents）
桌面或手機螢幕上的點擊操作，正在被轉化為可執行的程式碼腳本（如Playwright腳本或DOM樹操作）。智慧體透過閱讀螢幕的HTML結構或無障礙樹（Accessibility Tree）來感知環境，輸出Python程式碼來執行點擊和滑動。UI介面變成了被程式碼操控的世界。
科學發現（Scientific Discovery）
在自動化實驗室中，科研流程被整合成了一條無縫銜接的「程式碼流水線」。從文獻檢索、提出假設，到編寫Python模擬程式、控制真實的液體處理機器人進行化學合成，再到處理實驗資料，程式碼貫穿了科研的每一個環節（如AI Scientist系統）。
個人化推薦引擎（Personalization）
智慧體能夠根據使用者的即時回饋，自動編寫和修改推薦系統的策略程式碼，並將使用者的偏好沉澱為可被程式讀取的持久化狀態物件。
具身智慧體（Embodied Agents）
在機器人領域，抽象的行動意圖被轉化為帶有運動學參數的可執行控制程式碼。程式碼充當了安全邊界，確保機器人的動作（如機械手臂抓取）符合物理定律，並在進入真實物理世界前在模擬器程式碼中完成排雷。
亟待解決的挑戰與開放問題
儘管前景廣闊，研究者也清醒地指出了該領域目前面臨的幾大核心挑戰：
評測指標的瓶頸（Evaluation Beyond Final Success）：目前的評測大多只看「測試案例是否通過」。但這無法區分智慧體是寫出了優雅的高品質程式碼，還是僅僅用一堆補丁「糊弄」過了測試卻破壞了原有的系統架構。我們需要更深度的語義和架構級別的評測。
不完整的執行回饋（Verification Under Incomplete Feedback）：有時候程式碼能夠執行，但可能存在安全漏洞或效能隱患。目前的驗證器在處理這類非功能性需求時依然非常薄弱。
無倒退的自我進化（Regression-Free Evolution）：當系統嘗試自動修改鷹架或重構程式碼時，極其容易陷入「災難性遺忘」，修復了一個舊Bug，卻引入了十個新Bug。
多智慧體併發的語義衝突（Semantic Conflict Resolution）：當多個智慧體同時修改同一個程式碼庫的不同部分時，如何解決它們在底層業務邏輯上的隱式衝突？目前的文字合併工具（如Git merge）無法解決深層的邏輯斷裂。
安全問責與人類監督（Human-in-the-Loop Safety）：當程式碼智慧體獲得直接操作生產環境、甚至是物理設備的權限時，我們必須建立堅不可摧的攔截機制，確保人類對高風險操作擁有絕對的否決權。
結語
這篇論文為AI領域提供了一張極其清晰且具有歷史意義的「智慧體系統工程藍圖」。
想要讓AI真正走向複雜的真實世界，絕不能僅僅依靠大型模型自身算力的提升。必須將「程式碼」作為系統的骨架、神經和肌肉。 大型模型提供了強大的「大腦」，而基於程式碼建構的智慧體鷹架（Agent Harness），則賦予了這顆大腦以穩固的沙盒、真實的物理回饋、可靠的記憶機制以及多角色協同的組織法則。只有深深植根於這套「可執行、可檢查、狀態化」的程式碼基底之中，AI智慧體才能真正從演示級的玩具，蛻變為工業級的可靠生產力。
未來已來，有緣一起同行！
本文完結