拋棄繁重框架的極簡主義：兩百行代碼如何重塑 AI Agent 的記憶與上下文管理

在命令列終端機輸入一串指令，要求 AI 讀取專案裏的某個設定檔。AI 完美地完成了分析。緊接着，在同一個終端機視窗裏，輸入“繼續，告訴我接下來該怎麼修改”。此時，AI 卻像斷電一樣，完全不知道你指的“繼續”是什麼，只能生硬地回答缺乏上下文的通用建議。

這種“失憶”現象，是許多軟體開發者在打造客制化 AI 工具時，最常遇到的第一道高牆。近期，一篇技術文章在開發者社羣引發廣泛討論，作者不使用任何現有的龐大軟體框架，僅用兩百行程式碼，便從底層邏輯建構出一個具備連續對話記憶與自動上下文壓縮功能的 AI Agent。

這項極簡主義的實作之所以引發共鳴，在於它扒開了復雜框架的外衣，直接向第一線的開發者展示了 AI 記憶運作的物理本質。當大型語言模型的競賽聚焦於參數量與多模態能力時，實際在應用端決定產品好不好用的關鍵，往往落在最基礎的上下文管理工程。

變聰明的錯覺與失憶的真相

要理解這兩百行程式碼的價值，必須先釐清一個常見的誤解：AI 並不具備人類意義上的“忘記”。大型語言模型本身是無狀態的。每一次發送 API 請求給模型時，它都是從零開始讀取資訊。

許多開發者在使用 ChatGPT 或 Claude 等商業軟體時，體驗到流暢的連續對話能力，會誤以爲模型本身記住了對話。商業軟體之所以能做到這一點，是因爲前端的工程機制在每一次你發送新訊息時，偷偷把你過去幾輪的對話記錄，連同最新的問題打包在一起，一次性全數送給模型。模型每次都是重新閱讀完整的聊天紀錄，從而展現出連貫的上下文理解。

當開發者開始自己寫程式打造 Agent 時，如果沒有處理好這個打包歷史紀錄的機制，“失憶”就會立刻發生。最典型的情況是，開發者在執行 Agent 任務的函式中，宣告了一個用來存放對話訊息的區域變數。當這次任務執行完畢，函式回傳結果後，該變數在記憶體中的生命周期就結束了。

如果使用者在這個獨立進程中接着提出“繼續”的指令，對函式而言這是一個全新的請求。它不會去撈取上一次已經執行完畢的對話歷史，只會把“繼續”這兩個字當作毫無前因後果的全新輸入丟給模型。模型當然無法給出正確的回應。

記憶體的物理限制與溝通成本

既然只要把歷史紀錄全部打包給模型就能解決失憶，爲什麼不幹脆無限制地把所有對話都送出去？這就牽涉到大型語言模型的物理限制：上下文視窗。

每一個模型都有其能處理的最大字符或 Token 數量限制。即便目前的模型已經支援高達數十萬甚至上百萬 Token 的視窗，依然存在兩個現實層面的阻礙。

第一是運算延遲。當你在終端機裏與 Agent 對話，每一次請求都包含數萬字節的早期無關對話，模型處理和生成回應的時間就會顯著拉長。在需要頻繁呼叫工具、反復修正程式碼的自動化工作流程中，這種延遲會嚴重破壞使用體驗。

第二是 API 費用。商業模型的計價基礎是輸入與輸出的 Token 數量。每一次請求都帶着從頭到尾所有完整對話歷史，意味着你在第一千次對話時，還要爲第一次對話的每一個字付費。

爲了解決這兩個問題，開發者社羣發展出了許多復雜的框架，例如 LangChain。這些框架試圖提供一種標準化的方式，讓開發者可以快速接入各種模型，並自動處理記憶、工具呼叫與歷史紀錄。

拒絕框架的繁重包袱

大型框架的初衷是降低開發門檻，但在實際的專案應用中，它們往往會成爲另一種包袱。以 LangChain 爲例，爲了涵蓋所有可能的使用情境，它的套件結構非常龐大。開發者如果只是想要一個簡單的對話記憶體，卻必須引入龐大的函式庫，遵循框架規定的嚴格資料結構與抽象化流程。當 Agent 出現非預期行爲時，由於對框架底層的運作細節不熟悉，除錯過程會變得異常困難。這種現象在業界被稱爲“黑盒子化”。

開發者在終端機環境中操作時，真正需要的是對程式碼的絕對掌控感。“手搓”這兩百行程式碼的核心訴求，就是奪回這種掌控權。這不僅與極簡程式設計的趨勢相符，也與業界對於打造專屬工具的考量一致，如同先前探討的矽谷 AI 招募戰中，客制化與底層邏輯理解已成爲當前技術發展最受看重的特質。

這篇引發討論的技術文章，其核心概念是直接操作傳遞給模型 API 的訊息陣列。這包含兩個步驟：首先是建立交互式循環，讓 Agent 程式在同一個執行緒內保持運行狀態，將每次使用者的輸入與模型的輸出實時推入同一個變數中，維持短期的記憶。其次是針對長期對話，實作上下文壓縮機制。

自動摘要：替 AI 打造短期與長期記憶

當對話持續累積，即將超過模型上下文視窗的安全水位之前，這兩百行程式碼會執行一個非常直接的動作：摘要壓縮。

這種壓縮機制的運作方式如下：程式會持續監控當前上下文陣列的總長度。一旦發現長度逼近設定的臨界值，它會將最早期的一部分對話內容提取出來，透過另一次獨立的 API 請求，要求模型將這些早期對話總結成一段精簡的重點摘要。隨後，程式會用這份摘要，替換掉原本佔據龐大篇幅的早期完整對話記錄。

這是一種模仿人類認知模式的工程實作。人類在參與長達數小時的會議時，不會逐字記住每個人在第一小時說的每一句話，而是會將其歸納爲幾個核心結論，並將注意力集中在當前最新的討論上。在程式碼的實作中，AI Agent 的記憶體被劃分成了“近期完整記憶”與“早期摘要記憶”。這種設計確保了對話不僅能夠無限延長，同時也把 API 請求的資料量控制在合理範圍內。

這種極簡實作帶來的效能提升是顯而易見的。終端機裏的 Agent 不再需要啓動龐大的依賴項，每一次執行都能以極高的效率完成。更重要的是，當 Agent 出現“幻覺”或呼叫錯誤的工具時，開發者可以立刻在這兩百行程式碼裏找到對應的邏輯錯誤，而不需要去翻閱框架的原始碼。這與我們在聽泉鑑寶的破產劇本現象中看到的，創作者對於內容控制權掌握的訴求有着異曲同工之妙；在技術實作端，開發者同樣需要舍棄虛華的包裝，回歸對底層工具的直接控制。

看懂趨勢：AI 開發走向去框架化

這兩百行引發關注的手刻程式碼，並非只是一次炫技，它折射出 AI 軟體開發產業正在發生的板塊位移。過去兩年，許多開發者急於將 LangChain 等重型框架塞入專案，深怕落後於時代。但隨着對大型語言模型特性的理解加深，業界逐漸意識到，Agent 的核心邏輯其實非常直觀。

一旦開發者看懂了上下文陣列的堆積原理，以及模型如何解析這些訊息，龐大框架提供的便利性就顯得不夠吸引人。拋棄框架、直接使用模型原廠 SDK（軟體開發套件）搭配少量客制化程式碼的趨勢正在成形。企業內部的開發團隊更傾向於培養這種“手搓”能力，因爲這代表團隊具備真正的除錯與維護能力，而不是被第三方框架的版本更新牽着鼻子走。

對於一般數位工具的使用者而言，理解這個技術脈絡同樣具有意義。它解釋了爲什麼有些基於 AI 的網頁服務或終端機工具反應極快且精準，而有些則顯得笨重且容易卡頓。關鍵往往不在於它們背後接了多強大的模型，而在於開發者如何處理你與 AI 之間的那些對話歷史。輕量、精準的上下文管理工程，才是優質 AI 體驗的基石。當我們在評估各種新興的 AI 生產力工具時，除了看它支援哪些昂貴的模型，更該關注的是它在記憶與歷史資料的處理上，是否做到了極致的化繁爲簡。