很多關於 Agent 的討論，最後都會回到模型排行榜。

哪個模型推理更強，哪個上下文視窗更長，哪個在程式 benchmark 裡得分更高，這些問題當然重要。但 [《Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering》](/papers/2604.08224v1.pdf) 指向了另一個更底層的重心。

它問的不是「模型還能學會什麼」，而是：

**哪些原本壓在模型身上的認知負擔，其實應該被搬到模型外部？**

這就是論文使用 `externalization` 這個詞的原因。它不是單純替 LLM 加幾個外掛，也不是把工具清單塞進 prompt。它描述的是任務表示方式的改變。人類使用紙、地圖、日曆和電腦也是這樣：外部物件沒有讓大腦本身突然變大，卻改變了問題的形狀。回憶變成辨識，心算變成符號操作，臨場發揮變成遵循流程。

LLM Agent 也正在經歷類似的轉變。

![論文 Figure 1：LLM Agent 設計中的外部化主線](/images/posts/externalization-in-llm-agents/figure-1-externalization-overview.webp)

*Figure 1, from Zhou et al., [arXiv:2604.08224](https://arxiv.org/abs/2604.08224), [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/), format-converted for web display, content unchanged.*

## 這篇綜述釐清了什麼

這不是一篇新模型論文，也不是 benchmark 論文。它的價值在於概念整理：替正在發生的工程遷移命名。

早期我們習慣把能力理解成權重裡的東西：更大模型、更好預訓練、更強對齊。接著，能力越來越多地被放進上下文裡組織：prompt、few-shot 範例、RAG、推理軌跡、工具說明。到了實際 Agent 系統，能力又進一步進入更厚的 runtime：記憶庫、檔案系統、技能庫、工具協議、沙箱、審批、日誌、評估器、子 Agent 編排。

論文把這條路徑概括成：

**weights → context → harness**

![LLM Agent 的認知外部化地圖](/images/posts/externalization-in-llm-agents/cognitive-externalization-map.webp)

這張圖表達的是一條工程主線：能力不是只放在模型權重裡。早期系統更多依賴 weights；上下文工程成熟之後，任務可以在 context 裡被臨時組織；到了 Agent，長期可靠性必須落到 harness。Memory 保存狀態，skills 沉澱流程，protocols 規範工具和 Agent 之間的互動，governance 處理權限、審計和失敗恢復。

因此，Agent 的關鍵問題不只是模型有多強，而是外部執行環境能不能把任務穩定地表示、約束和恢復。

## Memory：把時間搬到模型外面

最容易理解的外部化是 memory。

如果 Agent 只依賴上下文視窗，每次執行都只是帶著一段臨時工作記憶。更長的上下文有幫助，但不能消除選擇問題：什麼該放進來，什麼該忘掉，什麼已經過時，什麼只是噪音。更關鍵的是，上下文是暫時性的。沒有外部狀態，任務結束後很多經驗就消失了。

外部 memory 把問題從「模型能不能憑空回憶」改寫成「模型能不能辨識並使用被檢索出的狀態」。這和 cognitive artifacts 的觀點一致：購物清單不是擴大生物記憶，而是改變記憶任務。

對 Agent 來說，memory 可以保存使用者偏好、專案約定、歷史決策、失敗軌跡、領域事實和重複出現的限制。真正困難的地方不只是儲存，而是篩選：哪些狀態值得寫入，什麼時候檢索，檢索多少，如何壓縮，如何避免舊狀態污染新判斷。

所以 memory 不是「更長上下文」的替代品，而是時間維度上的基礎設施。

## Skills：把過程搬到模型外面

第二種外部化是 skills。

這裡的 skill 不是「模型會呼叫某個工具」，而是一段可重用的過程性知識。它可能包含步驟、判斷啟發式、停止條件、升級規則、失敗恢復方式和安全限制。一個成熟的 skill 告訴 Agent：這類任務通常應該怎麼做。

這和工具調用不是同一層抽象。工具提供動作，protocol 定義動作如何被發現與呼叫，skill 則封裝如何把動作組織成一件可重複完成的事。

![論文 Figure 5：技能作為外部化的過程性知識](/images/posts/externalization-in-llm-agents/figure-5-skills-lifecycle.webp)

*Figure 5, from Zhou et al., [arXiv:2604.08224](https://arxiv.org/abs/2604.08224), [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/), reproduced unchanged.*

軟體工程 Agent 讓這件事特別具體。

模型可能知道如何改程式、跑測試、讀錯誤日誌、寫 PR 摘要。但穩定完成任務，還需要很多本地流程：先讀哪些檔案，如何保護使用者改動，什麼時候用 `rg`，什麼時候跑完整驗證，如何處理既有 staged changes，哪些命令不能隨便執行。

如果這些都留給模型每次現場推導，Agent 的行為就容易發生漂移。把它們外部化成 skill，任務就不再是「臨場發明工作流」，而是「選擇並執行已驗證的流程」。

這也是 skills 容易被低估的地方。它不炫，但它直接降低行為方差。

## Protocols：把互動秩序搬到模型外面

第三種外部化是 protocols。

沒有 protocol 的 Agent 互動，本質上是自由文本協商。模型說自己要呼叫工具，工具回傳一段文字，另一個 Agent 再猜那段文字代表什麼。這在 demo 裡可行，在生產系統裡會很脆。

Protocol 把含糊互動變成機器可讀的契約。工具如何發現，參數如何宣告，權限如何表達，錯誤如何回傳，Agent 之間如何委託，使用者審批如何進入流程，這些都不應該只靠 prompt 約定。

它的價值也不只是互操作性。Protocol 還提供治理入口。只要互動是結構化的，系統就能驗證、審計、回放、監控和限權。自由文本很靈活，但很難治理。

## Harness：不是包裝器，而是認知環境

論文最重要的收束，是把 memory、skills 和 protocols 放進 harness engineering 裡。

Harness 不是包在模型外面的一層薄 wrapper。它是 Agent 實際運作的認知環境：控制迴圈、上下文預算、權限模型、沙箱、人工審批、日誌、評估、失敗恢復、子 Agent 編排，都在這裡發生。

![論文 Figure 3：Harnessed LLM Agent 的外部化架構](/images/posts/externalization-in-llm-agents/figure-3-harnessed-agent-architecture.webp)

*Figure 3, from Zhou et al., [arXiv:2604.08224](https://arxiv.org/abs/2604.08224), [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/), reproduced unchanged.*

重點是，harness 不是和 memory、skills、protocols 並列的另一個模組。它是承載並協調這些外部化結構的 runtime。Memory 提供狀態，skills 提供過程，protocols 提供互動結構，harness 決定它們何時被載入、如何彼此影響、要受哪些約束。

這也解釋了為什麼成熟 Agent 越來越像小型操作環境。它們有資源、權限、生命週期、日誌、策略和恢復路徑，而不只是「一個模型加一串工具」。

## 能力邊界正在移動

這篇論文最有用的地方，是它改變了「能力在哪裡」這個問題。

如果能力只在權重裡，改進 Agent 主要就是換模型、微調或重新訓練。如果能力也在上下文裡，prompt 和檢索就成為工程主戰場。如果能力進一步進入 harness，那麼系統設計本身就是能力的一部分。

這不是在貶低模型。相反，越強的模型，越值得被放進更好的外部結構裡。LLM 擅長綜合、判斷和泛化，但它並不天然擅長持久記憶、重複流程、權限治理、長期狀態和跨系統協調。

外部化不是作弊。它是工程上承認邊界，然後重寫任務。

好的 Agent 系統不會逼模型每次都從零開始想辦法。它會把可沉澱的狀態變成 memory，把可重用的流程變成 skills，把可治理的交換變成 protocols，再用 harness 把它們組織成可運行的環境。

## 外部化也有代價

這個框架很漂亮，但外部化不是免費擴展。

Memory 會帶來過時狀態、隱私邊界和檢索污染。Skills 可能過期、過度擬合，或在錯誤組合時變得不安全。Protocols 可能碎片化成互不相容的標準，也可能把系統鎖進僵硬介面。Harness 則會增加複雜度：審批、日誌、沙箱、策略和子流程越多，就越需要工程紀律。

還有評估問題。如果 Agent 能力分布在模型與外部基礎設施之間，我們到底在評測什麼？同一個模型放進不同 harness，表現可能完全不同。「模型能力」和「Agent 能力」已經不是同一件事。

這正是論文的位置。它不是說外部化解決一切，而是把問題放在正確的位置：可靠的 agency 來自模型與環境的共同設計。

## 實用判斷

這篇綜述的釘子句是：**Agent 進步的一條主線，是把認知負擔從模型權重遷移到可檢查、可複用、可治理的外部結構。**

這不是說模型不重要。模型仍然決定理解、規劃和生成的上限。但當 Agent 真正進入長期任務，可靠性不可能只靠一次次現場推理撐住。狀態要能保存，流程要能複用，工具呼叫要有協議，權限和失敗要能被 harness 接住。

外部化的本質，是把任務從「讓模型每次想明白」改成「讓系統把可沉澱的東西留下來」。Memory 保存時間，skills 保存過程，protocols 保存互動秩序，governance 保存邊界，harness 把它們組織成運行環境。

下次看一個 Agent 系統，不要只問它用了哪個模型。先問它把什麼認知負擔搬到了外部，哪些外部結構可檢查、可更新、可回滾。這個問題比模型名更接近系統的真實能力。