Session、State、Memory 到底差在哪裡？Agent 能不能續跑，取決於這三層

一個採購 Agent 正在處理請購案件：它已經讀取需求表、比對供應商報價、寫入一筆待審核請購單，接著準備通知主管。就在此時網路連線中斷。使用者重新開啟對話，問：「剛才那件事繼續做。」如果 Agent 能接續聊天，是否就代表不會重建請購單？答案是否定的。能記住前面說了什麼，和能判斷外部系統已執行到哪一步，是兩種不同能力。

Agent 的持續運作至少包含三層：Session、State 和 Memory。Session 用來連接一段互動，State 描述某次工作目前進行到哪裡，Memory 保存未來仍可能有用的資訊。實作上這些名詞可能因框架而有重疊，但在架構決策中刻意分開，能避免把「看起來會聊天」誤當成「能可靠執行企業流程」。

名詞上的混亂，來自各家框架對「記憶」的定義不同

OpenAI Agents SDK 的文件使用「session memory」來描述對話歷史保存；MongoDB 的文件則將短期對話和長期記憶分開；LangGraph 的 Thread 與 Checkpoint 又提供另一套執行狀態保存機制。[1][2][3] 三份文件都在討論如何讓 AI 跨越單一次模型呼叫，但使用的抽象層次不同。讀文件時若只看到 Memory 一個詞，很容易以為每家工具提供的是等價產品。

因此，評估框架應改用行為提問，而不是只問有沒有 Session 或 Memory。第一，關閉應用程式後能否取回上一段對話？第二，執行中斷後能否還原已完成的節點及外部副作用回執？第三，隔幾天開始一個新任務，能否取回使用者正式確認且仍適用的偏好？第四，是否能刪除或更正過時資料？第五，跨使用者與跨部門權限如何控制？

同一個產品可能已經實作其中兩項，其他仍需開發者自行補足。甚至同一個儲存資料庫也能同時存放三類資料，但這不會讓它們的責任自動合併。判斷能力時，應看可重現的測試結果，以及應用與外部正式系統的整合方式。

第一層 Session：讓下一句話知道上一句發生過什麼

Session 可直譯為「會話」，在 Agent 應用中通常代表一段有識別碼的互動範圍。使用者說「把剛才的第三個選項打開」，系統必須知道「剛才」是誰、是哪個會話、前一輪列了哪三個選項。OpenAI Agents SDK 的 Sessions 文件說明，SDK 可在每次執行前讀取該 Session 的對話歷史，執行後再把新的互動項目寫回儲存層。[1]

這類設計的直接用途，是不必每一次把先前所有對話手動複製給模型。SDK 可以使用 SQLite、Redis、MongoDB 等不同儲存後端，也能用 OpenAI 託管的 Conversation 方案。這些選項影響部署、資料管理與多執行個體共用，但不能單憑某一種後端，就說 Agent 已經擁有長期記憶或完整容錯機制。[1]

Session 的識別碼也不能當成授權。假如系統只要知道 session_id 就能讀取某位使用者的全部歷史，外部存取控制就可能有漏洞。OpenAI 的文件特別提醒，SQLite Session 本身不負責驗證誰有權讀取該筆歷史。[1] 因此，Session 必須配合使用者身分、租戶邊界及後端授權檢查。

第二層 State：工作不是一段話，而是一連串可觀察的變化

State 指「狀態」。對一個需要執行多個動作的 Agent 而言，狀態可能包含任務編號、目前步驟、每個步驟的輸入與結果、待核准項目、外部回執、重試次數，以及已寫入哪些系統。它的核心問題不是「剛才聊了什麼」，而是「這件事現在完成到哪裡」。

回到採購案例。如果 Agent 聊天歷史裡寫著「我已建立請購單」，這句話仍不能替代 ERP 的建立回執。真正的工作狀態應保留 ERP 回傳的請購單 ID、建立時間、審批狀態，以及後續可查驗的操作紀錄。若 API 在建立成功後、回覆訊息送達前斷線，單憑聊天歷史可能無法判斷是否成功。此時直接重送建立請求，可能造成重複單據。

LangGraph 的 Checkpoint 文件把某個時間點的圖形狀態保存成快照，並可透過 thread_id 追蹤一系列快照。框架也描述了在多個節點執行時，保留已成功節點寫入結果，以便發生失敗後盡可能避免重跑已完成工作。[2] 這是持久化執行狀態的一種方式，仍須配合外部 API 的冪等性與交易機制。

所謂「冪等性」，就是同一操作重複執行，業務結果不會被重複放大。例如設定客戶地址為某個值，重複設定通常不會產生兩筆地址；但「新增一筆付款」若沒有唯一交易識別與去重規則，重送一次就可能多扣一次。可靠的 Agent 要把這種差異交給後端服務控制，而不是寄希望模型讀懂自己上次說過什麼。

第三層 Memory：下次執行仍值得知道的內容

Memory 在這個比較中指跨工作、跨會話仍有用的持久資訊。比如已確認的客戶聯絡偏好、採購審查的既有原則、上次專案決策的背景，或某個產業的內部術語。它幫助 Agent 減少重問，但不一定是某次執行立即恢復所需的資料。

MongoDB 的 Atlas Agent Engine 文件把短期對話及長期記憶分開，並將長期記憶分類為事實、事件、程序與術語。官方說明，部分記憶是從會話背景提取，因此新對話中的資訊可能需要一段時間，才會出現在跨次可查詢的長期記憶中。[3] 這提醒開發團隊：Memory 適合承載持久知識，不宜直接用來代表某個步驟已經完成。

假設採購 Agent 記得「主管偏好用 Excel 附件」，對製作通知很有幫助。但它不能因此判定主管已批准該案。批准必須查審批系統的現況；已確認偏好則可從 Memory 取得。只有把這兩種資料的效力分開，才能兼顧便利和正確。

用同一個案例看三層如何協作

假設某個企業內部系統收到「幫我核對 20 筆報價並提交請購」。Session 綁定此次對話與提出任務的使用者；State 建立一筆任務，記錄已讀取哪個檔案版本、核對到第幾筆、哪幾筆存在例外，以及尚未送出的寫入動作；Memory 提供過去已確認的供應商分類規則和報告格式偏好。

開始執行前，系統先根據登入身分確認權限。Agent 讀取報價、套用規則，碰到無法判斷的項目時，將待決問題寫入 State，向使用者索取確認。使用者回覆後，Session 把新輸入接回原任務；State 更新被批准的處理方式；真正要跨次保留的穩定偏好，才在適當時機寫入 Memory。

送交 ERP 的步驟最需要小心。系統應在發送請求前有唯一操作鍵，收到 ERP 回執後保存結果。如果發生斷線，先查既有操作鍵所對應的結果，而不是讓 Agent 猜測「剛才應該有成功」。這就是 State 與交易系統的責任，而不是靠長期記憶多存幾句就能解決。

用時間線拆解「中斷之後會發生什麼」

把一項任務畫成時間線，就比較容易辨認資料應放哪裡。上午 9 點，使用者提出需求並登入系統，這時先建立 Session 與獨立任務 ID。9 點 1 分，Agent 下載報價並核對欄位，這些輸入檔案版本與核對結果寫入 State。9 點 3 分，系統準備建立 ERP 請購單，必須產生一個不會因重試而改變的業務操作識別碼。

9 點 4 分發生斷線。應用程式重新啟動後，先從 State 查到任務最後的已知進度與操作鍵，再向 ERP 查詢這個操作究竟有沒有成功。如果正式系統回報已建立，就把單據 ID 記入狀態並前進；如果確認沒有建立，才可能依既定重試規則重送；如果無法判斷，應停下來人工處置。這種恢復方式不是 AI「自己想起來了」，而是系統能用客觀回執還原現況。

9 點 10 分使用者回覆主管的補充指示，Session 讓 Agent 將回答對回原對話，State 才能在通過權限驗證後解除等待並進入下一步。若這次指示同時包含可長期使用的正式偏好，例如日後都以公司指定格式寄送，則可另經適當確認寫入 Memory。把時間線拆開之後，不同資料層的職責也就清楚了。

把 Agent 的「已完成」拆成三種不同意義

第一種是模型已產生結果。例如 Agent 已生成一份採購摘要，但還沒有寫入任何正式系統。第二種是工作步驟在測試或執行層完成，例如某支程式已通過檔案核對。第三種是業務事實已被權威系統正式確認，例如 ERP 已建立請購單、主管已批准或電子郵件服務已回覆寄件識別。

這三種完成狀態不能使用同一個布林值 done=true 混為一談。若系統只知道「Agent 回答已完成」，下次續跑時很難辨認哪些工作要重新執行。更可靠的做法是有明確的狀態轉移，例如已收到、處理中、待確認、已提交、外部確認成功、失敗待查及已終止。各狀態應定義誰有權變更、允許哪些下一步。

同樣的邏輯也適用於 AI 寫程式。Agent 說「功能完成」並不等於程式已提交 Git，更不等於已通過 PR 審核、CI 或正式部署。一個工作狀態模型能把不同階段分開，讓非工程主管也能辨認真正的交付進度。

「續跑」也要區分三種故障

第一種是使用者暫時離線。Agent 可能仍在伺服器端繼續執行，使用者回來時只需重新讀取最新進度。第二種是應用程式程序停止，例如容器重新啟動或背景工作者被終止。這時如果 State 沒有安全持久化，工作進度可能消失。第三種是外部工具發生不確定性，例如付款 API 收到請求，但回覆逾時，連本地程式也不知道操作是否成功。

不同故障需要不同恢復機制。使用者離線主要是會話與任務連結；服務重啟主要依賴 Checkpoint、工作佇列與持久化 State；外部工具不確定則必須查正式回執、使用冪等操作與必要的人工核對。把三種情況都統一交給模型「繼續推理」，不但無法保證結果，還可能放大重試錯誤。

在流程比較長、具有人工審批的情況中，停住反而是正確功能。比如合約 Agent 發現交易金額超過授權門檻，應能保存已準備好的文件、記下待核准原因，並在主管正式批准後才恢復。若要求它無論如何都自動完成，反而會讓高風險工作失去控制。

只有 Session，為什麼可能重複扣款？

很多初期 Agent 展示都在單次連線內成功執行，沒有模擬中途失敗。當服務重新啟動，開發者發現只要把歷史對話存回資料庫，AI 就能接續說話，於是把這當成任務恢復。這是過度延伸。

假設 Agent 呼叫付款 API 後收到網路逾時。可能的真實狀態至少有三種：付款沒有建立；付款已建立但回覆遺失；付款正在處理。聊天歷史最多告訴我們「已經發送付款請求」，無法代替付款平台的最終狀態。若重試設計沒有冪等鍵，第二次執行可能新增重複付款。這類副作用有法律與財務後果，應由交易系統、操作日誌與查詢 API 共同控制。

合適的恢復流程，是重新載入可靠的任務 State，對照外部系統回執，再決定是否重試。若已成功，直接向後續步驟移動；若未完成，依規則重試；若結果不明，停在待人工查核。Agent 可以解釋原因並整理例外，但不應對未知結果編造確定答案。

Checkpoint 不是萬靈丹，因為外部世界不會跟著倒轉

把流程狀態寫入資料庫，能降低服務重啟後遺失進度的風險。但即使儲存了每個節點的 Checkpoint，也不能讓已寄出的郵件自動收回，或讓已完成的轉帳自動撤銷。這是軟體工作流與真實世界互動時的基本限制。

所以企業應該區分可重複計算和不可重複執行的步驟。讀取資料、解析文件、生成草稿通常可以在明確版本下重新計算；付款、刪除資料、發送正式通知和部署生產系統，則需要特別的去重、審批、補償或回滾規則。若框架提供 Checkpoint，應善用它保存進度；但仍要自行定義外部副作用的安全邊界。

在複雜工作流中，某些操作不能直接「Undo」。例如供應商已收到報價詢價信，系統最多能再寄更正通知，不可能讓對方忘記先前內容。這時流程設計常需要補償動作，以及完整記錄由誰決定執行。把這種例外當成架構的一部分，比失敗時一直按重試更可靠。

Agent 可以有很多 Session，但不該因此產生很多真實世界的訂單

同一個使用者可能從手機與電腦登入，也可能在一天之內開啟多段對話。Session 數量與實際業務任務數量並不必然相等。使用者換一個對話框要求「繼續昨天的請購」，如果系統只根據這個新 Session 重新開一個任務，就有可能重複執行。

因此，正式的業務任務應擁有獨立主鍵，並與對話 Session 建立關聯。多個 Session 可以查同一件尚未完成的任務，但執行動作前要確認誰有權操作、目前 State 是否允許，以及是否存在另一個工作者已經在執行。這種設計也能避免同一位主管從兩個視窗同時點擊批准，造成重複更新。

如果兩個 Agent 同時讀到相同的 State，後來各自寫回不同結果，可能產生遺失更新。需要以版本號、原子更新或工作佇列等方法控制並行。模型不會天然知道另一個工作者在幾毫秒前已經修改資料，因此併發一致性不能只寫在 Prompt 裡，必須由資料層落實。

Session 歷史和記憶同時存在，會不會提供矛盾資訊？

會，而且這是一種正常但需要處理的情況。假設目前 Session 中使用者說「這次暫時改寄到新信箱」，Memory 仍保存「平時寄到原公司信箱」。兩個資訊可能都是真實的，差別是適用範圍。系統應由任務規則判斷一次性要求能否改變正式聯絡方式，以及是否需要核身確認，而不是機械性地讓其中一方覆蓋另一方。

另一種情況是 Memory 已過時。使用者換了部門，系統仍留著舊職務資料。這時最新人事主檔應優先於先前對話摘要。若資訊只在聊天中出現、沒有正式來源，就應顯示不確定性並要求確認。這說明資料層次除了分 Session、State、Memory，還必須有權威來源和資訊新鮮度的規則。

框架提供自動歷史合併、Checkpoint 或背景記憶提取，只是讓工程師不必從零開發每個元件；實際業務優先順序仍由應用程式決定。OpenAI Agents SDK 文件也列出不同 Session 後端、歷史剪裁與恢復方式，顯示「會話保存」不是固定只有一種設計。[1]

長期記憶為什麼也要能更新與遺忘？

企業常期待 Agent 能記住越多越好，卻很少先規劃如何更正過時資訊。假設員工的職務已變更，Agent 還記得他是舊部門的審核主管；如果 Memory 直接影響可執行動作，就可能造成錯誤轉派甚至權限問題。正式身分與權限必須查權威系統，Memory 只能提供有條件的上下文。

記憶也可能包含不該跨會話保留的資訊。個人資料、客戶事件、受限文件、臨時密碼和未確認的推測，不應一律保存。設計時須區分允許儲存的類型，決定保存期間、同意與刪除機制。適用的法規義務與實際資料處理條件需依場域另行評估，不能只靠技術文章替代法遵審查。

選擇框架之前，先畫出三份資料表

初期設計不一定需要很複雜的資料架構，但應能分開說明三種資料。Session 表至少能對應到已驗證使用者、會話識別與回合紀錄；State 表應包含任務識別、狀態版本、目前步驟、回執、例外與安全重試資訊；Memory 表應保留記憶內容、來源、適用範圍、有效期、權限與最後確認時間。

這不是要求所有系統只能用三個資料表，而是要求設計者說得清楚每筆資料應放在哪一層。若一個欄位同時被用作對話歷史、審批結果與長期偏好，就容易出現資料更新後彼此矛盾，甚至被過期記憶覆蓋正式紀錄的風險。

一份可持久化任務的最小規格

企業準備開發 Agent 時，可以先寫一頁任務規格。其一，任務的唯一 ID 與發起人；其二，目前狀態、版本號與下一個允許的步驟；其三，每個可能改變外部系統的動作所需授權；其四，外部回執、去重鍵與重試限制；其五，失敗後何時停止並交由人工處置。這些資訊不用在第一天就變成大型流程引擎，但至少必須由團隊共同確認。

例如新增 CRM 客戶資料，安全的流程可以先搜尋既有客戶 ID，再生成候選資料，由使用者確認後才建立；建立請求附帶唯一業務鍵，回覆成功後保存 CRM ID。若程序重啟，先查該業務鍵是否已寫入，而非重新新增。最後將「這件事已完成」放入工作狀態，相關業務資訊若有長期價值，才按照資料治理規則寫入 Memory。

可以把這份規格交給不同技術供應商或內部開發者實作，再用相同故障測試比較。這比讓每家產品各自展示最擅長的對話效果更公平，也能直接回答公司真正關心的問題：發生中斷、改變身分、修改資料或遇到錯誤時，系統會做什麼。

一個常被忽略的介面要求：讓人看懂續跑狀態

可靠的 State 不能只存在於工程師才能讀懂的日誌。使用者可能不知道 Agent 為何停住，也不知道是否能安全重試。好的介面應明確指出任務編號、最近完成的正式步驟、目前待處理事項、資料來源，以及下一步將採取什麼動作。若系統沒有取得外部回執，應顯示「結果尚待查核」，而不是為了讓畫面看起來完整就寫成「成功」。

當工作進入人工核准，介面最好能顯示批准的範圍與可能後果，例如即將新增一筆請購、寄送一封正式郵件或部署哪個版本。人員按下批准後，State 應記錄審核身分與時間，再確認工作者使用的是尚未過期的狀態版本。這能避免主管批准的是舊草稿，Agent 卻執行已改動的新版本。

若多個部門共用同一套 Agent，這種可讀的狀態資訊還可以降低跨班交接成本。下一位接手者不必從數百句對話裡猜測發生什麼，只需查看正式紀錄就知道哪些事情已完成、哪些仍需判斷。

如何做一個真正有辨識力的續跑測試

可以用一個小型五步驟流程測試，而不是只問 Agent「你記得我嗎」。先建立一筆有獨立 ID 的任務，讓它讀取測試資料、產生核對結果、模擬寫入外部系統、停在人工批准點，再輸出最終紀錄。執行到不同步驟時，刻意中斷應用程式、重開服務，檢查它能否恢復而不重複執行具有副作用的動作。

應至少安排四種失敗情境：工作尚未開始就斷線；API 成功但回覆遺失；審批中等待超時；前次寫入的資料被另一位工作者修改。每一種情境的預期結果都應事先明訂。真正成熟的 Agent 不一定會在所有情境自動完成，但至少必須能指出目前狀態、留下原因並安全停下。

還要測試兩種記憶情境：使用者明確更新一項偏好時，舊記憶會不會仍被優先引用；原本有權限的員工離職之後，他的 Session 與 Memory 是否仍可能被其他人讀取。這些都是「能不能可靠續跑」的必要條件。

五項驗收證據，比一段成功的聊天示範更重要

第一是能重現的任務識別。每一次正式工作都能從 task_id 找到開始、結束與負責使用者。第二是可持久化的狀態，重新啟動服務後仍知道已確認哪些步驟。第三是外部動作回執，能從正式系統查核寫入、付款或通知是否真的成功。第四是去重與重試規則，避免中斷時重複產生副作用。第五是權限與審計，能說明誰提出、誰批准，以及哪個 Agent 執行。

這五項證據不需要一開始全部做成大型平台，但與實際工作風險高度相關。若系統只負責整理內部知識，強化會話與資料引用可能就足夠；若它會自動付款、發送合約或部署程式碼，就必須對 State、回執與人工批准建立更嚴格的要求。

從商業價值看，可靠續跑的意義是減少中途失敗後的人力補救，而不只是讓使用者不必再次打字。一套 Agent 即使能連續運作十小時，只要在第十小時發生一次重複交易，損失也可能抵消此前省下的時間。企業應把「能不能安全恢復」視為品質指標，而不是附加功能。

管理者如何在不閱讀程式碼的情況下驗收？

管理者不需要理解每個框架的資料結構，也能要求三種可見證據。第一是任務時間軸，顯示哪一步已開始、完成、等待或失敗。第二是正式系統回執，能與 ERP、CRM、郵件或檔案系統的記錄相互核對。第三是異常情境測試，證明服務中斷、重試與未授權操作不會造成重複或越權結果。

此外，應能查看記憶的來源與更正方式。當 Agent 說「我依照你上次確認的偏好處理」，管理者可以要求系統指出偏好在哪裡確認、現在是否仍適用。如果無法追溯，這只是模型聲稱自己知道，不是正式的資訊治理。

採用新框架時，這四類證據可以直接成為驗收清單。即使未來 Session、State、Memory 的產品命名改變，企業仍能以工作是否可追溯、可安全恢復及可控制資料存取來評估，而不必每次重新跟隨供應商的名詞。

技術名詞再多，最後還是回到責任

Session 解決交談如何延續；State 解決工作如何恢復與確認；Memory 解決知識如何跨次保存。三者都有助於 Agent，但哪一層也不能替代身分驗證、正式業務資料、交易保護與人工責任。尤其是同時操作多個企業系統時，最危險的不是 Agent 說「我忘記了」，而是它明明不知道自己執行到哪裡，卻宣稱「我已完成」。

一套可靠的 Agent 應該能在任何時間回答三個問題：我正在為誰處理哪件事？有哪些動作已獲正式系統確認？哪些知識是來自過去，且現在仍有權使用？如果系統能用可追溯資料回答，而不是只靠模型重新敘述一次，續跑才具有工程意義。

延伸閱讀與來源

[1] OpenAI Agents SDK，〈Sessions〉，2026 年 11 月 5 日查閱：https://openai.github.io/openai-agents-python/sessions/

[2] LangGraph Reference，〈Checkpointing〉，2026 年 11 月 5 日查閱：https://reference.langchain.com/python/langgraph/checkpoints

[3] MongoDB Atlas Agent Engine Docs，〈Agent Memory〉，2026 年 11 月 5 日查閱：https://www.mongodb.com/docs/agentengine/add-features/memory-types/

[4] MongoDB Atlas Agent Engine Docs，〈Memory Extraction〉，2026 年 11 月 5 日查閱：https://www.mongodb.com/docs/agentengine/add-features/memory-extraction/

圖片資訊

封面為原創 AI 流程概念圖，三個圖形區分對話、工作狀態與持久記憶，不代表任何單一 Agent 框架的完整正式架構。