AI 軟體工程師的雙重記憶：地圖與日誌，如何建構可持續的決策能力
AI 代理在軟體工程中，常因缺乏長期記憶與全域視野而顯得力不從心。想像一個能理解專案全貌、又能從過往經驗中學習的 AI 協作者！本文將深入探討如何結合程式碼的「靜態結構地圖」與「動態開發日誌」，為 AI 代理建構可持續的決策基礎，使其從單純的指令執行者，進化為真正具備脈絡感知能力的智慧夥伴。
近年來，我們看到許多 AI 代理（Agent）在軟體工程領域展現了驚人的能力，它們能獨立完成編寫函式、修復 Bug、甚至撰寫單元測試。然而，當任務的複雜度與時間跨度拉長時，這些代理的表現往往會急遽下降。它們像是記憶短暫的實習生，雖然能處理眼前的單點指令，卻對專案的整體架構與歷史脈絡一無所知，導致決策短視，甚至在大型重構任務中迷失方向。
這個問題的核心，在於當前多數 AI 代理缺乏一個健全的「長期記憶」與「空間感知」系統。它們的決策依賴於有限的上下文視窗（Context Window），一旦對話重啟或任務切換，過去的經驗與教訓便煙消雲散。要讓 AI 代理從一個「指令執行者」進化為一個可靠的「工程協作者」，我們必須為它建構一個更為穩固的認知基礎。這需要結合兩種截然不同但相輔相成的能力：靜態的結構地圖，與動態的歷程記憶。
失憶的 AI 代理：短期任務的能手，長期專案的迷途者
一個人類工程師在接手一個複雜專案時，通常會做兩件事：首先，他會花時間閱讀程式碼、查看架構圖，理解各個模組之間的依賴關係，在腦中建立一張「地圖」；其次，在開發過程中，他會記住自己踩過的坑、成功的解法、與團隊成員的討論結論，形成一本開發「日誌」。這張地圖與這本日誌，共同構成了他做出明智決策的基礎。
然而，多數 AI 代理卻同時缺乏這兩者。它們在執行任務時，就像一個被蒙上眼睛，只能透過對講機接收指令的士兵。它知道下一步要往左走三步，卻不知道自己身在何處，也不知道為何要這麼走。這種缺乏全域視野與歷史感的狀態，使得它們在面對需要權衡取捨的複雜決策時，顯得力不從心。例如，在重構一個老舊系統（Legacy System）時，如果代理不了解某個看似無用的模組其實是多個核心功能的隱性依賴，它的「優化」很可能引發一場災難。
靜態地圖：用程式碼圖譜描繪全域結構
解決方案的第一步，是賦予 AI 代理一張「地圖」。這張地圖，就是整個專案的靜態程式碼結構圖譜。近期看到一個名為 graphify 的開源工具，其設計理念正是在解決這個問題。它透過靜態分析技術，為 AI 提供專案的全域視野。
graphify 的運作核心，在於其強大的靜態分析能力。它首先透過抽象語法樹（AST）解析原始碼，精準提取函式、類別、模組間的呼叫與依賴關係。更進一步，它結合大型語言模型（LLM），從 README、設計文件等非結構化文本中抽取核心概念與架構描述，補足程式碼本身無法提供的語意資訊。最終，這些結構化與非結構化的數據被整合，利用 NetworkX 等圖論函式庫與 Leiden 等社群發現演算法，生成一個視覺化且可查詢的程式碼知識圖譜。
有了這張地圖，AI 代理在接到任務時，就不再是盲目執行。例如，當需要修改某個 API 時，它可以先查詢圖譜，了解這個改動會影響到哪些下游服務，從而做出更周全的規劃。在進行系統重構或模組拆分時，這張地圖更是不可或缺的決策依據，它能幫助代理找到最合理的切割邊界，最小化風險。
動態日誌：以跨會話記憶記錄開發脈絡
有了地圖，我們解決了「空間」問題，但還需要解決「時間」問題。AI 代理不僅要知道「我在哪裡」，還需要記得「我做過什麼」。這就需要一個動態的歷程記憶系統，一個類似 agentmemory 的工具所嘗試建立的機制。
一個無法從過去經驗中學習的系統，注定只能重複犯錯。動態記憶正是為了解決這個根本問題而存在。
這類系統的核心目標，是捕捉並儲存 AI 代理在多次、跨會話（cross-session）互動中的操作與決策歷程。它會像一本鉅細靡遺的日誌，記錄下每一次的工具調用、檔案操作、遇到的錯誤、以及最終的解決方案。記憶被分層儲存，從短期的工作記憶到長期的程序記憶，確保關鍵經驗能夠被有效沉澱與檢索。
當一個新的開發任務開始時，系統會將相關的歷史記憶注入到代理的上下文中。例如，如果代理上週在處理某個特定模組時，曾因一個依賴版本問題而卡關許久，這次當它再次接觸同一個模組時，這段「踩坑紀錄」就會被喚醒，提醒它避免重蹈覆轍。對於多代理協作的場景，這套共享的記憶系統更是至關重要，它能確保不同代理之間的知識傳承，讓整個開發系統形成一個能持續學習與進化的有機體。
地圖與日誌的協奏：建構可持續的決策系統
靜態地圖與動態日誌，兩者缺一不可。它們共同構成了一個 AI 代理在軟體工程中進行長期、複雜決策的認知雙引擎。我們可以透過一個簡單的比較，來理解它們如何協同工作：
| 靜態結構地圖 (如 Graphify) | 動態歷程記憶 (如 Agentmemory) | |
|---|---|---|
| 核心功能 | 解析程式碼全域相依性與架構 | 捕捉跨會話的操作、錯誤與決策 |
| 回答的問題 | 「我在哪裡？」「這段程式碼與誰有關？」 | 「我做過什麼？」「上次的嘗試為何失敗？」 |
| 主要價值 | 提供結構性大局觀，支援架構級決策 | 提供時序性經驗，避免重複錯誤，加速學習 |
| 應用時機 | 系統分析、重構規劃、影響評估 | 持續開發、錯誤排查、多代理協作 |
在一個理想的「Harness Engineering」實踐中，AI 代理的工作流程會是這樣的：接到任務後，它首先向「地圖系統」查詢，了解任務涉及的程式碼在整個專案中的位置與關聯；接著，它向「日誌系統」查詢，調閱與此相關的歷史操作紀錄與經驗。基於這兩份情報，代理才能制定出一個既有全域視野、又吸取了歷史教訓的行動方案，並交由底層的 CLI 工具執行。
從系統設計的層次來看，這不僅僅是兩個工具的簡單疊加，而是一種認知架構的轉變。它意味著我們不再將 AI 代理視為一個無狀態的函式呼叫，而是將其視為一個在特定環境中持續存在、能夠積累經驗的實體。這種轉變，是讓 AI 真正融入複雜軟體開發流程的關鍵一步，也為未來的 AI 治理與協作模式奠定了更穩固的基礎。
延伸閱讀
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。