你的 AI Agent 什麼都記不住：修復 context 膨脹的 MCP 技巧

沒有人願意公開的問題

每一場 AI 程式設計 agent 的示範都大同小異：乾淨的終端機、清楚的指令、整齊的結果。沒有人讓你看第三個小時會發生什麼事，此時 agent 已經讀過四十個檔案、跑過十幾套測試，把每一道執行過的指令的雜訊輸出都塞滿了它的 context window。到了那個時候，agent 不會變得更聰明，反而會變笨、健忘，還會很有自信地重複它早就做完的工作。

這是 agentic 程式設計裡最不光采、也最普遍的問題。context 就是 agent 的工作記憶，而它是有限的。agent 讀到的每一樣東西都在搶同一塊空間，而它讀到的大部分都是垃圾：建置日誌、堆疊追蹤、目錄列表、那些它只需要一行卻抓了全文的檔案。視窗被沉積物填滿，最初讓 agent 變得有用的那部分推理能力被擠了出去。

解決這個問題的工具，並不是在基準測試裡勝出的那些工具。它們是管線。而在這個十月，正是這些管線爬上了 GitHub 的熱門榜。

工具輸出 sandboxing 背後的思路

浮出檯面、比較有意思的專案裡，有一個是面向程式設計 agent 的 context 優化層，它從源頭下手解決這個問題。它最亮眼的數字是：到達模型的工具輸出量少了約 98%。

機制在概念上很直接。與其讓指令的原始輸出直接倒進對話裡，你把它放進 sandbox 執行，只把模型需要的那部分結果交給它：一段摘要、結束狀態、命中查詢的那幾行。完整紀錄仍然可以被模型主動取用，但它不會只因為「也許有用」就一直占著視窗的空間。

這和一位優秀工程師的習慣性做法是同一種紀律。當重點只是那一行錯誤時，你不會把整段日誌貼進對話。而 agent 一旦放任不管，做的正好相反。

這背後是有帳單的，所以這些工具並不只是工程上的錦上添花。context window 不是免費的。模型要處理的每一個 token 都在花錢、花時間，它要記住的每一個 token 都在消耗注意力。一個往工作階段裡倒進十萬 token 建置輸出的工具，是在向你收兩次費：一次是 token 本身，另一次是當訊號被埋沒之後模型判斷力的下降。這 98% 的縮減，其實是披著省錢外衣的品質修復。

比工作階段更長壽的記憶

問題的另一半是：agent 不只會在一個工作階段內遺忘，它會跨工作階段遺忘。關掉終端機，context 就沒了。隔天重新打開，agent 完全不知道你做過什麼決定、否決過哪條路線、程式碼為什麼長成現在這樣。你重新解釋一遍，agent 重新推導一遍，某個決定就這樣被做了兩次。

這個領域裡的持久化記憶工具採用了不同的路子。其中最受注目的一個會捕捉 agent 在工作階段裡做的事，用模型把它壓縮，再把相關的部分注入到未來的工作階段裡。它的賣點並不炫，但說得很對：一個記得你專案大致樣貌的 agent，比一個在單一任務上稍微聰明一點的 agent 更有價值。主流的模型廠商也在往同一個方向走，加入了讓 subagent 比父對話更早壓縮自身 context 的開關，正是為了不讓它把整個工作階段的歷史帶進一個根本不需要這些歷史的任務裡。

這裡有意思的設計問題是：該記住什麼。什麼都記，你等於用更慢的方式重建了最初的問題。記得太少，記憶就毫無用處。真正獲得動能的專案，都是那些有選擇地記憶的專案，它們信奉的理論是：對過去一個月的一份好摘要，勝過對過去一小時的一份完美紀錄。

把 routing 當作 context 策略

第三塊拼圖是 routing：在任務執行之前，就決定它需要哪個模型、哪些工具，這樣它就不會被載入一堆永遠用不到的能力。一個被告知了十七種不同整合的模型，即便任務只需要其中一種，也會為這十七種都花掉 context。跨平台強制執行 routing 聽起來像是基礎設施細節，實際上它是一項偽裝起來的 context 預算決策。

到了這一步，問題就不再像快取問題，而開始像系統設計。agent 的 context window 是一種資源，就像記憶體和磁碟是資源一樣，而那些把它當資源對待的工具，才能讓 agent 在長任務中保持一致。sandboxing、記憶和 routing 這幾個專案會走到一起並非偶然：它們是同一種稀缺性的三個側面。

subagent 模式是最清楚的例子。當一個 agent 派生出一位幫手去做某項很窄的工作時，這位幫手並不需要繼承整段對話。交給它一個只包含手頭任務的乾淨 context，既更便宜也更準確，這也是為什麼較新的 harness 允許 subagent 比父層更早壓縮自己的 context。父層保留長長的歷史，子層得到一張乾淨的書桌。那些讓 agent 跑過長達一週重構的團隊，往往會自己得出這條規則，通常是在看著一個 subagent 把整個視窗都花在重讀一段它根本不需要的對話之後。

為什麼是現在

這些問題都不是新問題。從第一個 agent 跑起來開始，agent 就一直在丟 context。變化在於：現在人們期望 agent 能連續跑上好幾個小時、跨很多個工作階段、處理真正重要的工作。玩具忘了東西無所謂。而一個團隊賴以進行一週重構的工具，忘掉東西的代價就大得多。

市場已經注意到了。兩年前，「我們的 agent 有 200k 的 context window」是個賣點。現在真正有用的問題是：這個視窗裡有多大比例花在了訊號上。懂得這一點的廠商正在推出壓縮控制和 subagent 的 context 隔離。社群則在推出讓其餘部分變得可以忍受的管線。

不光采的結論

人們很容易把十月這波 agent 新聞讀成一個關於更聰明的模型和更巧妙的外掛的故事。但更安靜、更持久的故事是關於衛生（hygiene）的。agent 已經變得足夠有用，可以長時間執行，而長時間執行會暴露出它們管理自身記憶方式上的每一處弱點。

在熱門榜上爬升的專案，都是那些接受了一個平淡事實的專案：自主工作的瓶頸很少是純粹的智慧，而是能否不淹沒在自己的筆記裡、始終待在任務上。把記憶修好、把雜訊放進 sandbox、把能力做好 routing，一個僅僅稱職的模型會突然顯得很出色。做錯了這些，即便是前沿模型也會把它一下午的時間花在重讀一個它已經讀過五遍的日誌檔上。