排程觸發一個 AI coach agent,每天早上七點半準時發訊息。運作兩週後你發現它會重複問同一個問題,會忘記你上週說過的目標,會把已經完成的事項再提醒一次。不是 API 壞了,是你碰到 isolated session 的第一個違反直覺之處:每次排程觸發,系統建立一個全新的 process,對話歷史不攜帶、上下文不繼承。模型本身沒有記憶。
就像早餐店阿姨如果每天醒來都失憶——她還是可以接你的單,但前提是昨天有人把你的慣例菜單寫進那本舊筆記本裡。記憶不住在阿姨腦子裡,住在那本本子裡。
外部記憶檔:唯一的持久層
解決方式不是讓 AI「真的記住」,而是在每次啟動時讀取一個進度檔,在每次結束前把當前狀態覆寫進去。這個純文字檔就是它唯一的記憶載體。你可能以為 AI 的記憶是訓練出來、存在模型參數裡的,但在 agent 設計的實務裡,持久記憶的實作方式跟最老派的方法一模一樣——寫個檔案。
我用的是一個 progress.md,裡面記錄當前目標、完成進度、上次對話的關鍵決策。每次 agent 啟動,第一件事是把這個檔案讀進 system prompt 的一部分,讓模型以為自己「知道」你是誰。每次對話結束前,agent 呼叫一個 function 把更新後的狀態寫回去。下次啟動,迴圈重來。
違反直覺的地方
你以為 GPT-4 或 Claude 這種模型應該「越用越懂你」。實際上模型參數在 inference 階段是唯讀的,不會因為你跟它聊天就改變。Fine-tuning 可以調整參數,但那是另一個流程,跟日常對話無關。所有「記憶」都是外掛的——context window 暫存對話、vector database 存長期資料、或者最簡單的方式,一個文字檔。
isolated session 模式下,每次觸發都是冷啟動。Process 起來、讀檔、執行、寫檔、關閉。下次觸發,上一個 process 已經不存在,記憶體清空,只有那個 .md 檔活下來。這個設計的好處是乾淨:不用管理長期連線、不用處理 session 過期、不用擔心記憶體洩漏。壞處是你必須自己管理狀態。
寫檔案的細節
progress.md 的內容要結構化,但不能太複雜,因為它會被塞進 prompt。我用 markdown 格式,分三個區塊:current goals、completed tasks、last conversation summary。每個區塊最多五行。太長的話 token 成本會爆,太短的話脈絡不夠。
覆寫檔案的時機也要抓準。太早寫,對話還沒結束可能漏掉後續決策;太晚寫,process 可能被 timeout 殺掉來不及存檔。我把寫檔邏輯放在對話的最後一輪,讓模型自己判斷「這次對話的關鍵更新是什麼」,然後呼叫 update_progress 這個 function。模型生成的更新內容直接覆蓋舊檔。
記憶住在外面
這個架構讓我想起以前寫 shell script 的習慣:把狀態存在 /tmp/state.txt,每次執行前先 cat 進來,結束前 echo 進去。AI agent 的記憶管理本質上沒有更高級,只是檔案內容從幾個變數變成幾段自然語言。模型不記得你,檔案記得。
每天早上七點半,agent 醒來,讀那個檔案,然後假裝記得你。
— 邱柏宇
延伸閱讀
Your AI Coach Wakes Up Amnesiac Every Morning
You schedule an AI coach agent to send you a message every morning at 7:30. After two weeks, you notice it asks the same question twice, forgets the goal you mentioned last week, and reminds you of tasks you’ve already completed. The API isn’t broken. You’ve just encountered the first counterintuitive aspect of isolated sessions: every scheduled trigger creates a brand new process. No conversation history carried over, no context inherited. The model itself has no memory.
Like a breakfast vendor who wakes up amnesiac every morning — she can still take your order, but only if someone wrote your usual menu in that old notebook yesterday. The memory doesn’t live in her head. It lives in the notebook.
External Memory File: The Only Persistent Layer
The solution isn’t to make the AI “truly remember.” It’s to read a progress file at startup and overwrite it with the current state before shutdown. This plain text file is its only memory carrier. You might think AI memory is trained in, stored in model parameters. But in agent design practice, persistent memory is implemented the oldest way possible — write a file.
I use a progress.md that records current goals, completion status, and key decisions from the last conversation. Every time the agent starts, the first thing it does is read this file into part of the system prompt, making the model think it “knows” who you are. Before each conversation ends, the agent calls a function to write the updated state back. Next startup, the loop repeats.
The Counterintuitive Part
You’d think GPT-4 or Claude should “understand you better the more you use it.” Actually, model parameters are read-only during inference. They don’t change because you chat with it. Fine-tuning can adjust parameters, but that’s a separate process, unrelated to daily conversation. All “memory” is external — context window caches dialogue, vector databases store long-term data, or the simplest way: a text file.
In isolated session mode, every trigger is a cold start. Process spins up, reads file, executes, writes file, shuts down. Next trigger, the previous process no longer exists, memory cleared, only that .md file survives. This design is clean: no long-lived connections to manage, no session expiration to handle, no memory leaks to worry about. The downside is you manage state yourself.
File Writing Details
The progress.md content needs structure, but not too complex, because it gets stuffed into the prompt. I use markdown format with three sections: current goals, completed tasks, last conversation summary. Five lines max per section. Too long and token costs explode; too short and you lose context.
Timing the file overwrite matters. Write too early and you might miss later decisions; too late and the process might get killed by timeout before saving. I put the write logic in the last conversation round, letting the model decide “what’s the key update from this conversation,” then call the update_progress function. The model-generated update directly overwrites the old file.
Memory Lives Outside
This architecture reminds me of old shell script habits: store state in /tmp/state.txt, cat it in before each run, echo into it before exit. AI agent memory management isn’t fundamentally more advanced — just that file contents went from a few variables to a few paragraphs of natural language. The model doesn’t remember you. The file does.
Every morning at 7:30, the agent wakes up, reads that file, and pretends to remember you.
— 邱柏宇