跳至主要內容

AI agent 脈絡記憶狀態架構教學

實作

脈絡、記憶與狀態:中斷後如何接著做

拆開模型當下的工作中脈絡、正式可信的工作狀態與選擇性保留的記憶,再測暫停、恢復、到期時間、刪除與污染。

難度
中階
預估時間
125 分鐘
更新日期
2026-10-02
文案複核
speak-human-tw
兩輪
本課內容
  1. 01先把定義說清楚
  2. 02現場情境
  3. 03實作範例
  4. 04照著做,每一步都有檢查點
  5. 05實務脈絡
  6. 06動手實作
  7. 07故障診間
  8. 08正式上線前的邊界
  9. 09資料來源與主張限制

這一課會完成什麼

  • 替本輪脈絡、正式可信的狀態與持久保存的記憶定義不同契約
  • 用最少而高訊號、可追來源的紀錄組出脈絡
  • 工作暫停後恢復,也不重做已完成操作效果
  • 測過期摘要、被污染的筆記、跨租戶檢索、到期時間與刪除

開始前先準備

  • • 模組 02 的可信的工作階段與稽核模式
  • • 基本關聯式資料庫概念與 JSON 序列化

先把定義說清楚

脈絡、記憶與狀態

模型脈絡(context)是本次判斷能看到的有限資訊;狀態(state)是應用程式保存的目標、進度、核准與操作紀錄;記憶(memory)則是挑選後留給未來執行的資訊。記憶需要來源、負責人、保存期限與刪除規則。三者可以互相引用,但工作是否完成、操作是否已執行,必須查正式狀態紀錄。對話摘要只提供線索,不能取代資料庫,也不能讓舊核准在恢復工作時自動生效。

對話對話紀錄可以當證據,卻不是好資料庫。它可能漏掉外部操作效果、混入不受信任的工具文字、超過脈絡時段,也很難確定性的資料遷移或修復。系統若只靠聊天紀錄恢復工作,最危險的是它看起來還能繼續跑。

持久保存的記憶會把過期、私有或惡意資訊帶進未來任務。寫入規則、到期時間與刪除測試應該第一版就有;等到記憶已經跨執行影響決策,再來清理,通常已經無法完整追溯。

現場情境

Atlas campaign reconciliation

具名合成情境。Atlas 媒體、行銷活動紀錄、核准、記憶項目與時間戳記都是實作測試資料,不是正式環境歷史紀錄。

負責人
你維護一個比對核准行銷活動中繼資料與合成分析匯出的工作;遇到差異時要停下來等操作人員審查。
要做的決策
決定哪些欄位存資料庫、哪些進下一次模型脈絡,以及哪些觀察紀錄可以保留成記憶。
目前狀態
工作可能跑得比單一模型脈絡還久。原型把進度寫進對話訊息,因此恢復後會重讀已完成的匯出,也把舊模型摘要當成目前核准狀態。團隊需要能重啟程序、重新登入,仍從資料庫裡的實際進度接續。
預期成果
工作在審查點暫停,依資料庫狀態恢復一次;已到期或其他租戶記憶不會進脈絡,刪除也能用測試證明,不必相信自動產生的摘要。

限制條件

  • • 工作狀態、completed 操作效果與核准以資料庫為唯一權威。
  • • 脈絡只能放目前目標、相關紀錄、最近已核准的筆記與來源紀錄指標。
  • • 記憶必須有租戶、負責人、來源、建立時間時間、到期時間、信心水準與刪除狀態。
  • • 恢復 token 只識別已序列化的應用程式狀態,不能授權新的使用者或租戶。

實作範例

寫得再順的摘要,也不能蓋過核准表

證據類型: 具名模擬情境

工作 job_atlas_17 已讀取匯出版本 44,也建立差異 d_08。較早的脈絡摘要寫核准待處理;操作人員後來在應用程式裡拒絕 d_08。原型直接重播對話歷史紀錄,恢復脈絡因此仍帶著過期摘要。

改版後先查 jobs、effects、discrepancies 與 approvals 表。脈絡組裝器送出 approval_status: rejected 和 record version 3,移除舊摘要。迴圈以 rejected 結束;操作台帳已有冪等鍵,匯出版本 44 不會再讀一次。

恢復測試斷言只有 1 次匯出讀取、1 筆差異、目前拒絕狀態,以及 0 筆過期記憶紀錄。這些都是確定性的測試資料結果,不代表各供應商的對話功能有相同語意。

主張限制

起始範本用 SQL 表示關聯式狀態,脈絡序列化器也採簡單設計。正式環境還須處理加密、保存期限、並行控制、備份、資料存放區域與供應商的對話語意。用代表性執行軌跡檢查壓縮漏掉什麼,不能假設摘要保留全部限制。

做法

照著做,每一步都有檢查點

架構圖分開目前模型脈絡、正式可信的工作/核准狀態、帶到期時間的持久保存的記憶,以及重新驗證身分後的暫停/恢復路徑。

現場情境

決定哪些欄位存資料庫、哪些進下一次模型脈絡,以及哪些觀察紀錄可以保留成記憶。

  1. 01每個事實只能歸到一類
  2. 02建立暫停中的測試工作
  3. 03組最小脈絡

驗收條件

脈絡重設後工作仍能接續,因為進度與操作效果存在對話紀錄外。模型看到的是由已授權目前紀錄組成的精簡檢視,不是一路累積的對話歷史紀錄。

這張圖要幫你看懂什麼用確定性的架構與存續時間圖解分開脈絡、資料庫狀態、記憶儲存區、來源紀錄、到期時間與恢復流程。自動產生的 art 無法準確表示正式紀錄。
  1. 01

    每個事實只能歸到一類

    把工作目標、進度、紀錄、核准、工具觀察紀錄、偏好與摘要分成脈絡、狀態、記憶或捨棄。狀態可以渲染進脈絡,但權威來源仍是資料庫。

    檢查點 · 核准與操作效果狀態只存在資料庫事實;自動產生的摘要無法覆寫。

  2. 02

    建立暫停中的測試工作

    插入 job_atlas_17、匯出操作效果版本 44、差異 d_08、待處理核准、1 筆有效記憶、1 筆已到期記憶與 1 筆其他租戶記憶。

    檢查點 · 恢復前,原始測試資料已包含 3 種記憶案例與 completed 冪等鍵。

  3. 03

    組最小脈絡

    依可信工作階段的租戶與工作 ID 查詢,附目前紀錄版本及來源參考。按歸屬、到期與刪除狀態過濾記憶,再序列化成有大小上限的脈絡,不把其他租戶或過期內容混入。

    檢查點 · 脈絡只有 1 筆有效記憶與目前核准;已到期與其他租戶的紀錄都不存在。

  4. 04

    拒絕後再恢復

    以樂觀版本檢查把 d_08 更新為 rejected。呼叫端重新驗證身分,讀取已保存的工作狀態,再建立脈絡;測試同時確認舊摘要沒有帶回待核准判斷。

    檢查點 · 工作以 rejected 結束;匯出版本 44 不再讀取,也不建立新差異。

  5. 05

    測刪除與污染

    Soft-delete 有效記憶,確認未來脈絡不再出現。另加一筆聲稱規則已改的被污染的記憶,證明規則仍來自有版本紀錄的應用程式設定。

    檢查點 · 已刪除記憶消失,被污染的文字改不了規則;稽核紀錄列出每筆被考慮與被過濾的記憶。

實務脈絡

展示版之後

G1

實作拆解

先列正式紀錄表,再寫脈絡組裝器。每個欄位記下可信儲存位置、負責人、時效、版本、可見租戶、可否送給供應商及刪除時間。工作狀態、核准和已完成操作從資料庫讀;模型摘要只當觀察。偏好記憶缺來源或期限,就不跨次保存。表中也要列使用者刪除資料時,哪些衍生儲存區必須一併清理。

在不同保存邊界刻意讓程序崩潰:操作計畫寫入前、寫入後但尚未派送、工具完成但觀察未存,以及檢查點完成後。每案驗操作效果次數、狀態版本、租約負責人與終止狀態。恢復權杖只定位工作;重新登入後若租戶或角色改變,就重新授權,避免舊權杖變成長期權限,或離職人員仍能恢復工作。

壓縮評測逐項核對必要保留清單:目標、已接受證據 ID、未解限制、核准狀態、操作回執、未解問題與來源紀錄。除了節省 token,也測保留資訊的召回率、過期摘要、被污染的工具文字和矛盾筆記。會影響決策的欄位若無法靠文字摘要穩定保留,就改存結構化狀態。

G2

營運檢查

狀態遷移應用交易或樂觀鎖保護。以等待審查為例,程式先讀目前版本,寫入審查結果時同時要求版本相同;若另一位操作員已決定,更新必須失敗並重新讀取,不能用最後寫入者覆蓋。外部效果則先建立計畫紀錄與穩定冪等鍵,執行後保存回條;若回條保存前中斷,恢復流程先對帳,不能只靠對話摘要判斷要不要再做一次。這些紀錄會增加資料表與程式碼,卻換來一個重要能力:任何人都能指出現在狀態、造成它的事件,以及哪些工作已經不可安全重做。

記憶寫入政策至少回答六件事:誰要求保存、屬於哪個租戶、原始來源在哪裡、信心如何取得、何時過期、如何刪除。模型自行整理的偏好若沒有可驗證來源,只能當低信心候選,不能直接影響權限、付款或審查。讀取時先套租戶、擁有者、刪除與期限,再依相關性排序;快取鍵也必須包含這些限制。刪除測試要涵蓋主要資料、向量索引、快取與未來脈絡。若使用者刪掉一筆記憶,下一次執行仍因舊摘要採取行動,系統就沒有完成刪除。

G3

驗證與上線

脈絡組裝器本身要當成安全關鍵元件測試。給它混合租戶、過期、已刪除、來源不明、版本互相衝突與超過大小的紀錄,確認過濾順序固定,輸出列出採用來源與被排除理由。若總量超過上限,依事前優先級裁切:目前目標、權威狀態與未解限制先保留,一般背景或低信心記憶才移除。裁切結果要可觀測,不能讓模型只收到殘缺資料,卻不知道關鍵來源被省略。

資料保留要納入提供者邊界。送進模型的脈絡可能離開自有系統,需記錄資料類別、供應商設定、保留與刪除條件,以及是否允許用於除錯。敏感內容能以識別碼取代時,不要複製全文;工具結果過大時,先在受控環境篩選,再只傳決策需要的段落。若法務或資料擁有者改變政策,版本化設定要能阻止新執行,舊記憶與既有脈絡也要依規則重新評估。

恢復流程最後要做人工演練。操作員在不知道模型先前對話的情況下,只靠工作紀錄、效果帳本、核准表與升級封包,判斷能否安全恢復。若他必須閱讀完整逐字稿或詢問原作者,代表權威狀態仍有缺口。演練同時測兩位操作員競爭更新、租戶權限在暫停期間被撤回、記憶剛好過期與來源文件被刪除,確認每種改變都在下一個重要決定前被重新讀取。

G4

補強練習

替每筆跨次執行記憶做資料盤點,列出內容類型、來源、使用目的、讀取次數、到期日與刪除驗證。從未被使用、來源不明或無法刪除的記憶不要保留。保留量減少後再量任務結果,確認清理沒有移除真正必要的條件。

狀態資料表也要有遷移測試。新增欄位或改終止狀態時,用舊版本工作紀錄跑升級、恢復與回滾,確認既有效果不會重做,舊核准不會被解讀成新政策。模型提示可以快速改,權威狀態格式則需要明確相容與修復計畫。

G5

交付前最後檢查

把脈絡建構結果存成測試快照時,只保留合成欄位與來源識別碼。快照若因排序漂移頻繁變動,先固定優先級與穩定排序;不要關掉比較。穩定輸出能讓團隊看見某次修改是否意外帶入過期、已刪或其他租戶紀錄。

G6

延伸實作

替脈絡、狀態與記憶各設定不同的備份與復原要求。權威工作狀態與效果帳本需要交易一致、可還原版本與定期復原測試;短暫脈絡可重建,不必當永久紀錄;記憶則依擁有者、期限與刪除規則備份,還原後仍要保留刪除標記。若災難復原把已刪記憶帶回,或讓已拒絕核准退回等待中,系統就違反原決定。以固定快照演練還原,再跑恢復與刪除案例,確認每類資料真的依自己的責任運作。

動手實作

建立可恢復的 Atlas 工作紀錄

建立起始範本的 schema,放入測試工作 job_atlas_17,讓它暫停等待審查。改變核准內容後,以讀取目前狀態的脈絡組裝器恢復執行。

準備項目

  • • 使用 SQLite,或把起始範本翻成你的關聯式資料庫語法。
  • • 恢復 token 與身分驗證/授權必須分開。
  • • 測試資料時間固定為 2026-08-20T09:00:00Z,到期時間測試才能重現。
  • • 原始供應商推理與機密不得保存成記憶。

本課產出

資料遷移、初始測試資料、脈絡組裝結果、暫停與恢復測試、操作台帳測試、內容污染測試及記憶刪除驗證。

起始模板: 正式可信的狀態與記憶 schema

SQL
CREATE TABLE jobs (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('ready','running','awaiting_review','completed','rejected','failed')),
  goal TEXT NOT NULL,
  version INTEGER NOT NULL,
  updated_at TEXT NOT NULL
);

CREATE TABLE effects (
  job_id TEXT NOT NULL,
  idempotency_key TEXT NOT NULL,
  kind TEXT NOT NULL,
  result_ref TEXT NOT NULL,
  completed_at TEXT NOT NULL,
  PRIMARY KEY (job_id, idempotency_key)
);

CREATE TABLE approvals (
  job_id TEXT NOT NULL,
  subject_id TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN ('pending','approved','rejected')),
  reviewer_id TEXT,
  version INTEGER NOT NULL,
  decided_at TEXT,
  PRIMARY KEY (job_id, subject_id)
);

CREATE TABLE memories (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  owner_id TEXT NOT NULL,
  source_ref TEXT NOT NULL,
  content TEXT NOT NULL,
  confidence REAL NOT NULL,
  created_at TEXT NOT NULL,
  expires_at TEXT NOT NULL,
  deleted_at TEXT
);

預期結果

脈絡重設後工作仍能接續,因為進度與操作效果存在對話紀錄外。模型看到的是由已授權目前紀錄組成的精簡檢視,不是一路累積的對話歷史紀錄。

留給下一課

保留工作、操作效果、核准、記憶與脈絡組裝器契約。模組 04 的檢索中繼資料與模組 06 的迴圈檢查點會接到這些紀錄。

驗收條件

  1. 01恢復必須重新身分驗證,恢復 token 永遠不能當租戶權限來源。
  2. 02Completed 操作效果不重複;同時進行的核准更新使用版本檢查。
  3. 03已到期、已刪除與其他租戶記憶不得進模型脈絡。
  4. 04自動產生的或已檢索的記憶不能取代已設定的規則或目前核准狀態。

常見故障

故障診間

F1已恢復的工作重複執行已完成讀取或寫入。
先檢查
對照操作台帳、冪等鍵、檢查點提交版本與中斷前後工具執行軌跡。
可能原因
進度從對話歷史紀錄推測,或外部操作效果完成後才存紀錄。
修復方式
用穩定冪等鍵記已規劃的/completed 操作效果,恢復一律先查台帳。
下次怎麼避免
測派送執行前、派送執行後與結果持久保存前中斷。
F2操作人員已改核准或偏好,agent 仍沿用舊值。
先檢查
比較脈絡紀錄版本與正式可信的表,定位已快取的摘要或記憶。
可能原因
過期摘要被當成狀態,或快取失效忽略新版本。
修復方式
會影響決策的欄位每次從目前狀態重建,脈絡附版本與來源紀錄。
下次怎麼避免
各欄位設時效規則,版本不一致就拒絕組脈絡。
F3另一個租戶的筆記出現在提示詞。
先檢查
查檢索篩選、快取鍵值、記憶負責人、工作階段綁定與脈絡組裝器紀錄。
可能原因
記憶查詢先做語意相似度,沒有先套租戶與負責人篩選。
修復方式
排序與序列化前,先以已驗證身分的租戶限制查詢與快取。
下次怎麼避免
保留跨租戶 canary,斷言未授權脈絡命中永遠是 0。
F4脈絡壓縮省了 token,也丟掉後面必須遵守的未解決限制條件。
先檢查
用必要保留項目清單對照具代表性的長時間的執行軌跡的已壓縮的脈絡。
可能原因
Summarizer 只追求短,沒有要求決策、阻礙與來源紀錄的召回率。
修復方式
結構化狀態分開保存;脈絡壓縮依必要保存期限檢查調整。
下次怎麼避免
先量召回率,再談 token 節省;近期關鍵紀錄不放進自由文字摘要。

展示版之後

正式上線前的邊界

  1. 01權限、操作效果、核准與任務狀態存在正式可信的應用程式狀態。
  2. 02每次已恢復的執行都重新身分驗證與授權。
  3. 03狀態轉移有版本,同時進行的更新用樂觀式或具交易一致性的控制。
  4. 04每筆記憶有負責人、租戶、來源、信心水準、建立時間時間、到期時間與刪除路徑。
  5. 05敏感狀態要加密;送出系統的脈絡需檢查供應商保存期限。
  6. 06每次重要決定前,以時效、來源紀錄、大小與 access 檢查重建脈絡。
  7. 07測脈絡超出上限、脈絡壓縮遺失、被污染的記憶、刪除與跨租戶污染。
  8. 08紀錄記記憶選擇與狀態版本,不複製不必要的私有內容。

證據類型

資料來源與主張限制

資料來源只支撐本課標示的主張,不代表換一個系統也會得到相同結果。

  1. [1]
    AI agent 的有效 context engineering

    Anthropic · 官方文件 · 2026-08-20

    context 預算 · 壓縮 · 結構化筆記
  2. [2]
    Conversation state

    OpenAI · 官方文件 · 2026-08-20

    延續 response · conversation objects · 由應用程式管理歷史紀錄
  3. [3]
    Compaction

    OpenAI · 官方文件 · 2026-08-20

    長時間 response context · 壓縮後狀態 · context window 管理
  4. [4]
    AI Risk Management Framework

    NIST · 官方文件 · 2026-08-20

    風險治理 · 衡量方式 · 營運責任

延伸的 Tenten 資源

實作準備進正式環境時

帶著實作證據來,不用從空白摘要開始。

有效的實作審查,起點應該是任務測試資料、權限地圖、執行軌跡、評測報告、失敗案例與成本上限。Tenten 可以根據這些資料檢查整合與營運缺口,不必把課程裡已經證明過的決策全部重開。