你為了繞過模型缺陷做的工程，會在模型變強時變成技術債

Anthropic 工程團隊發表〈Scaling Managed Agents: Decoupling the brain from the hands〉，說明他們如何重構長時間運行的 AI 代理架構。技術細節之外，這篇最有價值的是一個對所有導入 AI 的企業都成立的觀察。

官方的原話是：外框程式（harness）「編碼了關於 Claude 自己做不到什麼的假設」，而「這些假設需要經常被質疑，因為它們會隨著模型改善而過時」。

先界定：什麼是「為缺陷寫的程式」

企業導入 AI 時，工程師花的時間有相當比例不是在實現功能，而是在繞過模型當下做不好的事：把長文件切小、加重試邏輯、寫額外的檢查步驟、限制模型的自由度避免它走偏。

這些程式在當下是必要的、有效的。問題在於：它們的價值建立在「模型現在做不到」這個前提上，而這個前提會過期。

這跟一般的技術債不同。一般技術債是因為當初趕工寫壞了；這種債是當初寫對了，但世界變了。

機制：context anxiety 這個具體案例

Anthropic 給了一個很清楚的例子。他們先前發現 Claude Sonnet 4.5 會出現一種行為：「當它感覺到上下文限制逼近時，會過早地把任務收尾」。團隊稱之為 context anxiety（上下文焦慮）。

用生活的例子講：像一個人看到會議室預約時間快到了，即使討論還沒完，也開始草草做結論。

為了處理這個問題，工程上必然要寫一些對策——切分任務、提前提示、加檢查。但官方在文中直接寫道：在 Claude Opus 4.5 上測試時，這個行為「已經消失了」，使得原本的繞道方案變成多餘。

換句話說，那段為了解決 context anxiety 而寫的程式，在模型升級後不但沒有價值，還留在系統裡增加複雜度。

他們的解法：把大腦和手分開

Managed Agents 的核心架構是把三件事解耦：「大腦」（Claude 與其外框）、「手」（執行動作的沙盒與工具）、以及「session」（事件紀錄），讓三者能各自獨立失敗或被替換。

具體做法是把外框從容器裡搬出來：官方描述是「外框不再住在容器裡。它呼叫容器的方式，就跟呼叫其他任何工具一樣：execute(name, input) → string」。

這個設計帶來三個可量化的結果，依官方公布：

• 回應速度　首字回應時間 p50 下降約 60%、p95 下降超過 90%。
• 擴展性　外框變成無狀態，可以「多個大腦」擴展，不必為閒置的容器預留資源。
• 安全性　憑證「永遠不會從 Claude 生成程式碼所執行的沙盒中被觸及」。

最後這一項與我們談過的 MCP 資安風險是同一個原則：讓模型能執行動作的環境，跟持有權限的環境分開。

邊界：哪些工程不會過時

不是所有繞道都會變成負債。判準是：這段程式解決的問題，是模型的限制，還是你的業務規則？

• 會過時的　補償模型能力不足的邏輯：切分過長輸入、修正格式錯誤、防止提前收尾、重試不穩定的輸出。
• 不會過時的　權限控管、稽核紀錄、人工核可流程、公司自己的業務規則與驗收標準。這些跟模型多強無關。

所以架構上值得做的事，是把這兩類程式在檔案結構上就分開，並在補償型的程式旁邊註明「這是為了繞過什麼」。半年後模型升級時，你才知道哪些可以拆掉。

對台灣企業的意義

這對正在評估外部顧問或系統商的企業，提供了一個很實用的驗收問題：「這套系統裡，有哪些部分是為了繞過現在模型的限制？模型變強之後那些會怎麼處理？」

答得出來的，代表對方分得清楚哪些是暫時性工程。答不出來或說「都是必要的」，那多半是把補償邏輯和業務邏輯混在一起寫了——那種系統在模型換代時會很難維護。

另一個實際考量是合約週期。前沿模型的迭代速度目前約半年一輪，如果簽的是三年期的客製化開發，中間至少會遇到四到六次模型更新。合約裡是否包含「因模型更新所需的架構調整」，值得在議約時就談清楚。

需要保留的懷疑

本文引用的效能數字（TTFT p50 下降約 60%、p95 下降超過 90%）出自 Anthropic 自己公布，是其特定架構與工作負載下的結果，未說明測試條件與對照組設定。這類數字不宜直接套用到其他環境的預期。

此外，Anthropic 同時是模型供應商與該架構服務的提供者。「模型會變強所以不要寫太多繞道程式」這個論點本身站得住（有 context anxiety 的具體案例佐證），但它同時也導向「多用平台原生功能」的結論，這對供應商是有利的。兩者可以並存，讀者自行權衡。

常見問題

什麼是 context anxiety（上下文焦慮）？

指模型在感覺到上下文視窗限制逼近時，會過早地將任務收尾的行為。Anthropic 在 Claude Sonnet 4.5 上觀察到此現象，並在後續的 Claude Opus 4.5 測試中發現該行為已消失。這個案例說明：為補償特定模型缺陷所撰寫的工程對策，會隨模型改善而失去必要性。

「把大腦和手解耦」在架構上具體是什麼意思？

指將三個部分分離：大腦（模型與其外框程式）、手（執行動作的沙盒與工具）、session（事件紀錄），使三者能各自獨立失敗或被替換。實作上是把外框程式移出執行容器，改以標準介面呼叫容器，如同呼叫任何其他工具。依 Anthropic 公布，此設計使首字回應時間 p50 下降約 60%、p95 下降超過 90%，並讓憑證無法從模型執行程式碼的沙盒中被觸及。

企業建置 AI 系統時，哪些程式碼會變成技術債？

判準是這段程式解決的是模型限制還是業務規則。補償模型能力不足的邏輯會過時，例如切分過長輸入、修正格式錯誤、防止提前收尾、重試不穩定輸出。不會過時的包括權限控管、稽核紀錄、人工核可流程與公司自身的業務規則。建議在架構上將兩類分開，並在補償型程式旁註明其繞過的問題，以便模型升級後判斷是否可移除。

評估系統商時該問什麼問題？

可詢問：這套系統中哪些部分是為了繞過當前模型的限制，模型改善後將如何處理。能明確回答者代表其分得清暫時性工程與長期邏輯。此外由於前沿模型迭代週期目前約半年一輪，長期客製開發合約應在議約時釐清「因模型更新所需的架構調整」由誰負擔。

下一步

這篇談的是架構層面的長期成本。若你正在規劃企業內部的 AI 系統，建議搭配上下文腐化那篇一起看——一個講短期的準確度，一個講長期的維護成本。需要協助盤點既有系統中哪些屬於暫時性工程，可透過白皮書專區索取評估架構。

出處

本文引述出自 Anthropic 工程部落格〈Scaling Managed Agents: Decoupling the brain from the hands〉，anthropic.com/engineering/managed-agents。加註引號之敘述為該文原始表述之中譯。

文中效能數字（TTFT p50、p95）為 Anthropic 自行公布，未揭露完整測試條件，請勿直接套用至其他環境。