AI Agent Harness 架構論文閱讀分析：很多團隊真正缺的，不是再多一個 feature，而是先搞清楚自己的 runtime 正在長成哪一種系統

論文基本資訊

• 論文標題：Architectural Design Decisions in AI Agent Harnesses
• 作者：Wei Hu
• 年份：2026
• 來源：arXiv:2604.18071
• 論文連結：https://arxiv.org/abs/2604.18071
• 主題：AI Agents、Agent Harnesses、Software Architecture、MCP、Context Management、Runtime Governance

這篇 Architectural Design Decisions in AI Agent Harnesses 最值得看的地方，不是它又發明了哪個新 agent framework，而是它終於退一步，認真問了一個更根本、也更常被大家跳過的問題：當大家都在做 agent，真正決定系統會長成什麼樣、風險會積到哪裡、可維運性會不會崩的，其實往往不是模型本身，而是外面那層 harness 怎麼搭。

這個 framing 很重要。因為現在很多討論還停在「模型會不會推理」「agent 會不會用工具」「benchmark 幾分」，但真正進到工程現場後，最麻煩的通常變成：

• 子代理到底怎麼分工、怎麼互相傳狀態？
• 上下文是靠 prompt window 撐、靠檔案撐，還是靠資料庫與分層記憶撐？
• 工具是硬編、registry、MCP，還是 plugin ecosystem？
• 有沒有 approval、sandbox、audit？這些東西是一起設計，還是補丁式黏上去？
• 整個執行迴圈是 CLI 風、workflow 風，還是 event-driven / orchestrator 風？

這篇論文真正補上的，不是 agent 能不能做事，而是 agent 系統到底是怎麼被「工程化」出來的。

它在解什麼問題？

作者觀察到一個很明顯的落差：研究界已經談了很多 agent 的 reasoning、planning、tool use、memory，但對於承載這些能力的非 LLM 工程層，也就是 tool mediation、context handling、delegation、safety control、orchestration，那層實際把 agent 變成可跑系統的基礎設施，反而缺少比較系統性的研究。

所以這篇不是單點 proposal，而是做了一個 70 個公開 agent-system 專案的 source-grounded empirical study。它想回答三個問題：

• RQ1： Agent harness 的關鍵設計維度到底有哪些？
• RQ2： 哪些設計決策常常一起出現？哪些常見想像其實不成立？
• RQ3： 不同類型的產品定位，最後會長成哪些典型架構模式？

我很喜歡這個角度，因為它不急著再造一個新框架，而是先把這個生態系到底已經反覆做了哪些選擇整理出來。這比單篇系統 paper 更像在幫整個領域補「架構地圖」。

這篇最關鍵的洞見：agent harness 不是 implementation detail，而是風險與能力一起長出的控制層

論文把 agent harness 定義成一個鬆散但實用的工作概念：它不是模型本身，也不是單純 prompt，而是那層負責工具中介、狀態與上下文處理、委派結構、執行邊界、治理控制的 surrounding infrastructure。

這點其實直接打中現在很多系統的盲點。因為很多團隊在做 agent 時，容易把 harness 當成「外圍 glue code」；但這篇的實證結果反而在說：

• 真正決定一個 agent 能不能長時間運作的，是 context management
• 真正決定它能不能安全碰世界的，是 tool system + isolation + approval
• 真正決定它能不能擴張成平台的，是 registration boundary 與 orchestration

換句話說，harness 不是幫模型接工具而已，而是在替整個 agent system 決定它的操作哲學。

五個最常反覆出現的設計維度

作者最後把 70 個專案濃縮成五個 recurring design dimensions，我覺得這個整理非常有用：

• Subagent architecture：有沒有 subagent、怎麼建立、可不可以巢狀、怎麼溝通
• Context management：上下文如何保存、壓縮、摘要、持久化
• Tool systems：工具如何註冊、探索、執行、隔離
• Safety mechanisms：approval workflow、isolation level、audit visibility
• Orchestration：整個 agent loop 是 imperative、ReAct、declarative 還是 event-driven

你如果最近看很多 agent 專案，應該會有種「對，就是這五塊在反覆折磨人」的感覺。這篇的價值在於，它不是只把這些列出來，而是證明這些東西在跨專案比較時真的足夠穩定，能拿來當分析主軸。

第一個很實用的發現：大家其實早就不再相信「只靠 prompt window 就夠」

論文在 context management 這塊抓到一個很關鍵的現實：純 prompt-window 導向的系統很少，真正的中心地帶反而是 file-persistent、hybrid、hierarchical 的 context strategy。

這句話背後其實很有分量。它代表業界和開源圈已經用腳投票了：一旦系統不只是單回合助手，而是要做多步、長任務、角色分工、可恢復執行，context handling 就不再是 prompt engineering 小技巧，而會被提升成一個 infrastructure concern。

這也解釋了為什麼最近很多 framework 會開始出現：

• 檔案型持久記憶
• summary + raw history 雙層保留
• layered / hierarchical memory
• 顯式的 token budgeting 與 prompt assembly

這篇其實在提醒一件事：當 coordination complexity 上升，memory 不是附加功能，而是系統服務。

第二個發現也很準：大家先把工具「內部制度化」，才慢慢走向 MCP / plugin 生態

在 tool system 上，這篇的結論不是「MCP 已經統治世界」，而是更接近現實的版本：registry-oriented tool systems 還是主流，但 MCP-first 與 plugin-oriented extensions 正在冒出來。

這個觀察我覺得很對。因為很多系統在擴張初期，通常會先做：

• 顯式 tool registry
• schema-based discovery
• 分類後的 capability surfacing

等到它真的開始想當平台、想吸第三方工具、想做更廣的互通，才會把邊界 formalize 成 MCP 或 plugin model。

論文的語氣很克制，但意思其實很清楚：tool registration 不只是開發便利性問題，它是平台野心的前兆。 一旦一個專案開始 formalize discovery boundary，它通常也正在往更大的 ecosystem ambition 走。

第三個發現最值得安全圈記：中等隔離很多，高保真稽核很少

這篇在安全設計上的發現，我覺得是整篇最值得 agent builder 貼在牆上的一句：

Intermediate isolation is common, but high-assurance audit is rare.

作者把這件事講得很白：很多專案確實開始加 sandbox、container、approval、command filtering，但真正做到高 assurance audit 的很少。論文裡甚至列出一個很刺眼的分布：

• No isolation：17%
• Container isolation：31%
• No audit：40%
• Structured audit：20%
• Tamper-evident audit：5%

這些數字真正刺的地方在於：很多系統已經願意加「限制它」的東西，卻還沒認真加「事後查得清楚」的東西。 也就是說，大家開始知道 agent 要被關，但還沒有真的把 agent 當成需要可追責、可稽核、可還原的操作主體。

這對資安與高風險工作流很重要。因為沒有 audit，你就很難分清楚：

• 哪個 tool call 是誰授權的
• 哪次狀態漂移是正常重規劃，哪次是被毒內容帶偏
• 哪個中介層在重寫、過濾、壓縮、或誤傳上下文

所以這篇雖然不是純安全 paper，卻意外地把agent runtime security 的真實成熟度照得很清楚。

真正有料的是 co-occurrence 分析：架構決策不是亂長，而是成 bundle 長

這篇最有價值的部分之一，是它不只列 feature，而是去看哪些設計決策會一起出現。這讓它從 catalog 升級成比較像 architecture study。

它抓到三個很有解釋力的 bundle：

1. 更深的 subagent coordination，通常會逼出更明確的 context service

這個其實非常合理。多代理一出現，狀態交接、部分結果保存、執行軌跡共享、摘要轉交就都會變成顯性問題。論文甚至指出，file persistence 在 orchestrator-worker 與 recursive 類型的專案裡比例遠高於單 loop 類型。

翻成人話就是：當你開始把工作切給多個角色做，記憶就不再只是聊天紀錄，而是協作基礎設施。

2. 更強的 execution isolation，通常會和更結構化的 governance 一起出現

這條也非常關鍵。作者觀察到 container-isolated projects 幾乎都更常搭配 policy engine、approval logic 與 audit trail。也就是說，sandboxing 不是獨立 feature，它通常是整個 control stack 的一部分。

這對現實世界很重要。因為如果一個系統給了更多執行能力，它就自然會承受更高 governance burden。這不是道德問題，是工程結構問題。

3. MCP / plugin 類型的註冊邊界，常出現在更平台化的產品定位

這點前面提過，但放到 co-occurrence 裡就更有味道：extension model 和 ecosystem ambition 是一起長的。 想做 developer-facing CLI、平台、可擴充 orchestration substrate 的專案，通常更有動機 formalize tool discovery 與 registration boundary。

更有意思的是三個「不成立的想像」

除了正向 co-occurrence，這篇也做了幾個我很喜歡的 non-co-occurrence，因為它們專門拿來拆掉那些很常被講得太簡單的說法。

1. 語言不決定架構

不是 Python 就一定鬆散，不是 Rust 就一定嚴謹，不是 TypeScript 就一定走 CLI。語言會影響實作風格，但不會直接把你鎖進某種 harness architecture。

2. Use case 不完全決定複雜度

同樣叫 coding assistant，有的很輕，有的已經是完整治理平台；同樣叫 research automation，有的只是窄任務原型，有的則做出很深的 orchestration。也就是說，產品標籤不等於架構深度。

3. 能力變強，不代表安全成熟度會自動跟上

這一條根本該印成 agent 圈警語。論文非常直接：有些框架工具面很廣、執行力很強，但 oversight 很普通；也有些系統能力不算最大，卻比較早投資在治理與安全。換句話說，capability growth does not automatically produce safety maturity.

這其實就是很多今天 agent 產品的寫照：功能長得飛快，但審計、授權、隔離、回溯能力還停在「之後再補」。

作者最後整理出的五種典型模式，很像一張 agent 框架地形圖

這篇最後把整個 corpus 總結成五種 recurring patterns，我覺得這是它最實用的輸出：

• Lightweight tools：小而快、低負擔、窄任務
• Balanced CLI frameworks：有一定 persistence、extensibility、operational practicality
• Multi-agent orchestrators：靠 coordination 拉高解題能力，但 context 與治理成本也跟著升
• Enterprise systems：context、extensibility、isolation、audit 一起成套出現
• Scenario-verticalized projects：為特定研究或垂直場景強化某一維，其他維度故意保持簡化

這種分法很有幫助，因為它提醒人一件事：不是所有 agent framework 都該長成同一個樣子。 真正重要的不是「誰比較先進」，而是你的 operating model 到底需要哪一包設計 bundle。

我怎麼看這篇？

如果你最近一直在看 agent security、MCP、runtime governance、CLI harness 或 orchestration framework，這篇會讓你有種「終於有人把這些看似零碎的工程選擇整理成一個可比較的架構語言」的感覺。

它最有價值的地方有三個：

• 第一，它把 harness 正名成研究對象。 不是雜項，不是 glue code，而是能力、風險與治理真正交會的地方。
• 第二，它用實證方式說明架構決策會成 bundle 長。 這比單篇系統 paper 更接近真實工程。
• 第三，它給了 framework builder 一個很實用的提醒：先定義 complexity envelope，再選 coherent bundle，不要 feature 一個一個亂長。

如果要挑一個我覺得最該被記住的句子，我會選這句：

很多 agent 團隊真正缺的，不是再多一個 feature，而是先搞清楚自己的 harness 正在往哪一種架構型態長。

因為 agent 系統一旦碰到長任務、工具擴張、多人協作、權限治理、稽核要求，你最後要補的幾乎都不是模型，而是 harness。

一句話總結

這篇論文真正說服我的地方，在於它把 agent engineering 從「功能拼裝」拉回「架構選型」：當 coordination、context、tooling、sandbox 與 audit 會一起長成 bundle 時，你就不能再把 harness 當成模型外面的零碎配線了。