AI 不是讀越多越好：上下文壓縮正在變成 Agent 基礎功

很多人用 AI 工具時，第一個直覺是：資料給越多，回答就會越準。

但在 Agent 工作流裡，這個直覺正在變得危險。

當 AI 開始自己查檔案、讀 log、呼叫工具、搜尋程式碼、整理文件，它每一步都會產生新的上下文。這些上下文有些很重要，有些只是雜訊。如果系統沒有先整理，就把所有東西一口氣塞給模型，結果不一定更好，成本卻一定更高。

真正成熟的 Agent，不只是會回答，而是會先判斷哪些東西值得讀。

為什麼「多給資料」不等於更準

大型語言模型推理時，能看到的內容會被放進 context window。這個空間看起來越來越大，但它不是無限的，也不是免費的。

一個 Agent 如果要修改一段程式碼，可能會面對整個專案、文件、錯誤訊息、歷史對話、工具輸出與測試結果。把所有內容都交給模型，表面上很完整，實際上有三個問題。

第一，成本會上升。輸入 token 越多，花費越高，延遲也可能增加。

第二，注意力會被稀釋。模型需要在大量資訊中找真正重要的線索，雜訊越多，越可能抓錯重點。

第三，答案可能被無關內容帶偏。舊資訊、錯誤假設或工具輸出的殘留片段，如果沒有被清掉，可能會影響後續判斷。

所以 AI 工具不是把上下文塞滿就好，而是要把高訊號內容挑出來。

Context engineering 變成新的基本功

過去大家常談 prompt engineering，也就是怎麼把指令寫清楚。

但 Agent 的問題更複雜。它不是只回答一次，而是會在多個步驟中持續讀資料、呼叫工具、記住狀態，再決定下一步。

這時候真正重要的是 context engineering：每一步要把哪些資訊交給模型？哪些要留下？哪些要壓縮？哪些要隔離在外部狀態裡，不要直接塞進 prompt？

這不是文字技巧，而是系統設計。

下一代 Agent 會先篩，再想

比較成熟的做法，會把上下文處理拆成幾層。

先找相關內容。不要讓模型自己讀完整倉庫，而是先用檢索、關鍵字、向量、程式碼結構或任務線索找出候選片段。

再壓縮內容。重複的 log、太長的工具輸出、已經不重要的歷史對話，可以整理成摘要或直接丟掉。

接著隔離狀態。不是每個資料都要放進模型的短期記憶，有些可以放在外部 state、scratchpad 或資料庫裡，需要時再取回。

最後才交給模型推理。模型看到的是精選後的上下文，而不是整片雜訊。

省 token 只是表面，真正目標是可靠

上下文壓縮最容易被看成省錢技術，因為它確實可以降低 token 使用量。

但更大的價值是可靠性。

當 Agent 要長時間工作，真正困難的不是單次回答，而是每一步都要帶著正確背景前進。上下文太少，模型不知道發生什麼事；上下文太多，模型又可能被雜訊干擾。

好的 Agent 系統會在兩者之間找到平衡：只給足夠的資訊，不把整個世界塞進去。

一般使用者該看什麼

你不需要記住所有技術名詞，但可以看懂一個趨勢：

未來 AI 工具的差距，不只在模型多強，也在它怎麼管理上下文。

一個好工具，不會每次都叫模型重讀全部資料，而會先幫你整理問題、找出相關片段、排除無關內容，再讓模型做判斷。

這也是為什麼 code search、retrieval、memory compression、context engineering 會越來越常被提到。

AI 不是讀越多越好。

真正能長時間工作的 Agent，會知道什麼該讀、什麼該忘、什麼該先放在旁邊。

回文章列表