程式碼成了代理引擎

這篇綜述把程式碼定位成代理系統的運行層，串起推理、動作、記憶與驗證。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：摘要無公開 benchmark 數字
• 突破點：把程式碼當代理底座

大型語言模型會寫程式，這件事大家已經不陌生。但這篇綜述要講的，不是模型又多會寫幾題，而是程式碼在 agentic 系統裡，開始變成「運行層」本身。它不只是輸出結果，而是把推理、行動、環境建模、執行驗證接起來的那層骨架。

這個角度很實際。因為一個代理系統好不好，不再只是看模型下一個 token 準不準。真正影響體驗的，還有外面那圈 harness：怎麼規劃步驟、怎麼存狀態、怎麼呼叫工具、怎麼檢查結果、怎麼跨步驟或跨代理協作。

這篇論文想解什麼痛點

作者先從一個很簡單的觀察出發：現代 LLM 已經能在很多程式任務上表現不錯，從競賽程式到 repository-level 軟體工程都涵蓋在內。但當這些模型被拿來做 agent 時，程式碼就不再只是被產出的物件，而是讓系統真的能運作的底層材料。

問題來了。當程式碼同時扮演「產物」和「基礎設施」兩種角色時，工程師很容易在概念上切得太散。規劃是規劃，記憶是記憶，工具是工具，驗證是驗證，看起來彼此獨立，但實作上其實都被同一層 code infrastructure 綁在一起。

這篇綜述就是要補這個空缺。它提出一個「agent harness」的框架，幫大家用更清楚的方式看待以程式碼為核心的 agent 系統。白話講，就是不要再把 agent 的周邊能力當零碎外掛，而是把它們看成同一個運行框架裡的不同模組。

它的方法到底怎麼運作

這不是新模型，也不是訓練 recipe，所以沒有傳統論文那種 architecture 圖和 loss function。它的貢獻是整理領域，提出一個結構化的思考方式，把 code-as-harness 系統拆成三層。

第一層是 harness interface。這一層處理程式碼怎麼連到 agent 的推理、動作與環境建模。實作上，這會影響 agent 怎麼表達步驟、怎麼呼叫操作、怎麼表示它正在互動的世界狀態。

第二層是 harness mechanisms。作者把重點放在長程執行所需的規劃、記憶、工具使用，以及回饋驅動的控制與最佳化。這層的目標不是把 agent 做得花俏，而是讓它在多步驟任務裡維持穩定，不要一遇到偏差就整個崩掉。

第三層是從單代理擴展到多代理系統。到了這個層級，共享的程式碼物件可以拿來做協調、審查和驗證。這對需要多個 worker 一起合作的系統很重要，因為大家不只要各自會做事，還要能對齊狀態、檢查彼此輸出、分工處理不同責任。

合在一起看，這三層其實在講同一件事：程式碼不是 agent 行為的副產品，而是讓行為能被執行、被檢查、被回復的操作面。這也是這篇綜述最核心的觀點。

這篇實際證明了什麼

先講清楚，這是綜述，不是實驗論文。摘要沒有公開新的 benchmark、沒有模型釋出、也沒有對照實驗數字可引用。若你想找的是某個指標提升多少，這篇摘要沒有提供完整 benchmark 細節。

但它不是空談。作者整理了一批代表性方法與應用，範圍涵蓋 coding assistant、GUI 與作業系統自動化、embodied agents、科學發現、個人化與推薦、DevOps，以及企業工作流程。這個範圍很廣，表示「程式碼作為 harness」不是只適用於單一 coding benchmark，而是能延伸到多種 agent 場景。

更重要的是，作者也把目前還卡住的地方講得很直接。像是：評估不能只看最後任務有沒有成功；如果回饋不完整，驗證就會變難；harness 的改進要避免引入回歸；多代理共享狀態要一致；安全敏感操作需要人類監督；多模態環境也還需要支援。

這些限制其實很有價值，因為它們指出現在 agent 系統真正脆弱的地方。模型也許能吐出看起來合理的步驟，但外面的 code layer 還要處理狀態、錯誤回復、安全性，這些都不是單一終點指標能完整描述的。

對開發者有什麼影響

如果你正在做 agentic software，這篇的價值在於它逼你換一種工程師視角看問題。不要只想 prompt 怎麼寫，也要想 harness 怎麼設計。因為真正讓 agent 能跑、能重試、能驗證的，通常就是這層程式碼。

對 production 來說，這個框架很有用。code-centric harness 可以更容易承載長流程工作、保留跨步驟狀態，還能插入明確的驗證節點。當 agent 出錯時，也比較容易 debug，因為它的行動是透過程式碼介面被中介，不是完全藏在自由輸出的文字流裡。

但這篇也沒有把問題講得太樂觀。多代理共享狀態依然難搞。安全敏感操作還是需要人類監督。只看最終任務成功與否，也不足以判斷 harness 是否真的穩健。這些都意味著，agent 系統的品質不只在模型本身，而在模型外面那一整圈可執行、可檢查、可恢復的設計。

實作上該怎麼理解這個框架

最實際的 takeaway 是：把程式碼當成 agent 的基礎設施，而不是模型剛好會說的一種語言。這會改變你設計 agent stack 的方式。你可能會更重視明確的介面、更細的 state management、更多驗證鉤子，以及多代理之間如何共享 artifact。

這篇綜述沒有宣稱這套方法能直接解決可靠性問題。它比較像是在幫下一波 agent 工程建立共同語言。當大家都在做 coding assistant、自動化系統或多代理 workflow 時，有一個「harness」視角，會比把所有東西拆成孤立模組更好討論，也更好落地。

如果要用一句話總結，這篇不是在推一個新模型，而是在推一個設計模式：在 agent 時代，程式碼本身就是運行代理的框架。模型負責想，harness 負責讓它真的做得出來、查得到、接得上下一步。

• 程式碼被定義成代理的運行層，而不只是輸出結果。
• 綜述把系統拆成介面、機制、以及多代理擴展三層。
• 它的重點是提供一個可執行、可驗證的 agent 設計視角。

對台灣開發者來說，這種框架特別像在提醒一件事：做 agent 不只是接 API、拼 prompt，而是要把狀態、工具、驗證、協作一起設計進同一個程式骨架裡。這篇論文講的，就是那個骨架。