賦予 AI 智能體記憶：遊戲開發中的自組織知識庫

為什麼我不再讓我的 AI 助理每天早上重新學習整個程式碼庫，而是為它建立了一個能夠自我管理的記憶庫。

需要服的問題

在游戲開發項目中整合 AI 助理最困難的部分不是模型本身，而是上下文。每次啟動，助手都要從零開始：重新閱讀程式碼庫，重新推導出某個功能的工作原理，最終得到的答案往往與昨天略有不同。與此同時，實際的知識分散在三個彼此矛盾的地方——每日提交記錄、代碼審查筆記和問題描述——而不懂 C# 的遊戲設計師仍然需要知道“這個功能涉及哪些方面，以及這個需求是否可行？”

總結的重點如下：

1. token 消耗過大問題
2. ai 幻覺問題
3. 成員如何快速理解項目

於是一個能夠自我更新的記憶庫需求因應而生。

賭注：三個系統，一個知識飛輪

沒有採用單一的整體架構，而是將工作分散到三個相互協作的系統：

• 遊戲來源(game source) — 遊戲用戶端。它只負責產生素材：每日程式碼審查，輸出純粹的「程式碼執行 X + 檔案:行」之類的事實，不包含任何個人觀點。

• 遊戲代理(game agent) — 大腦。它將這些原始素材整理成知識庫，解答可行性問題，並且特意將其置於遊戲程式碼庫之外，以便整個機制可以移植到下一個專案中。

• 任務(task hub) — 一個自建的工單系統。代理處理的需求會以工單的形式流入系統；完成的工單會回饋到知識庫。

最後一個循環至關重要：需求輸入，完成的工作回饋，知識庫隨著專案運行時間的延長而不斷壯大。這是一個知識迭代飛輪，而非快照。

不那麼顯而易見的權衡

有些決定違背了我的第一直覺，而這些決定值得記錄下來。

爲何不選擇使用 RAG

下意識的做法是將所有資料分塊、嵌入，然後以相似度檢索。我曾在之前的系統中嘗試過這種方法，但它並不適用於遊戲開發數據：結構化的規範被壓縮成一團亂麻，過時的討論與最終決策混淆，“誰做的決定”變成了猜測。因此，我將繁重的工作從查詢階段轉移到了寫入階段。當智能體進行整理時，它會保留結構並編寫清晰、易於閱讀的知識頁面——每個頁面都包含機器可讀的前置信息、簡潔易懂的閱讀層以及引用精確 file.cs:line 的腳註。一個文件，三個受眾，無需建立分支。

LLM（知識庫管理）從不推論權威性。

來自真實代碼審查（一級）的知識始終優先於工單規範（二級），無論日期如何——一個兩個月前的工單絕不應該覆蓋我剛剛從實時代碼中讀取到的事實。但關鍵在於，層級劃分和「最終決策」狀態由人和規則決定；模型只負責正確執行和寫入結構化內容。它從不猜測哪個來源會勝出。這使得整個流程可預測且可審計——當出現問題時，是規則出錯，而不是模型當天的狀態問題。

爲何不使用 Jira 或 Trello，而是自己建立了工單系統。

遊戲內容工單高度客製化，需要接入代理流程。因此我特意將工單系統保持極簡且完全解耦——它完全不包含任何 LLM 邏輯。所有智慧都保留在代理端；工單層僅負責持久化和追蹤工作。

代理程式也使用一個路由索引進行檢索。我使其無法手動編輯：它會根據每個頁面的 frontmatter 重新生成，如果發生偏差，持續整合 (CI) 就會失敗。因爲...一個可能悄無聲息地失效的路由表比沒有路由表更糟。

作爲下一個專案的經驗基石

最普遍適用的經驗教訓並非巧妙的提示或框架，而是：代理系統中最稀缺的資源是進入知識庫的資訊的信噪比。 我曾經計劃將設計電子表格自動轉換為 AI 可讀的文檔，但測量後發現有效轉換率只有約 30%，於是取消了整個功能。

事實證明，AI時代中原始數據的重要性遠比其他模塊更甚至。
賦予你的代理記憶功能－但要嚴格控制它記住的內容。

參考：GamePlusAIAgent-starter