讓兩個代理取得同一份已審查的記憶紀錄

Anthropic 的 Managed Agents 記憶儲存空間可跨工作階段保留文字。應用程式若要讓兩個代理取得相同的已審查事實，持續儲存只是第一步。應用程式必須確認紀錄的歸屬、檢查原始證據、選定一個已儲存修訂版本，並在任何代理看見紀錄前保留精確位元組。本指南適用於具有授權 Managed Agents 測試版存取權，且能控制應用程式驗證、儲存空間選擇及代理設定的開發者。依據是Anthropic 目前的記憶文件及2026年10月20日查核的 API 參考資料；BIG CHANGE 沒有進行帳戶或模型測試。

關鍵改變

• 改變了什麼： 經審查的具型別 JSON 記憶可持續存放於 Managed Agents 儲存空間。應用程式檢查來源與精確儲存位元組，凍結一份私人快照，再把相同核准位元組送到兩個獨立的授權工作階段，且不附加記憶儲存空間。
• 為何重要： 後續修改儲存內容，無法改變已為這些工作階段建構的輸入。
• 應留意什麼： 來源正確性、使用者授權及回答品質仍須分別檢查。

開始之前

準備一項真實事實、偏好或專案規則，具備獲准使用的原始來源、穩定來源 ID 及修訂版本，並由負責人核准儲存及揭露給兩種代理角色。審查前，先為該紀錄決定合適的審查有效期限。確認帳戶具備 Managed Agents 測試版存取權、私人 API 金鑰、授權工作區、兩個已設定代理 ID、環境及允許的模型。在允許本程序的四個受限取用工作階段前，檢查目前用量與價格。金鑰不要放進提示或憑據紀錄。

應用程式需要將驗證身分對應至範圍。在可信的應用程式狀態中，將身分繫結至核准的 ownerScopeId、工作區 ID、儲存空間 ID 及兩個允許的代理 ID。私人使用者或專案的存取規則不同時，應分開儲存。工作區 API 金鑰不會驗證終端使用者，路徑不是租戶邊界，提示也無法移除工具或憑證。確認兩個取用端設定都沒有附加儲存空間，也沒有可通往可變儲存空間的連接器、環境憑證或工具路徑。無法建立這個邊界，就在傳送紀錄前停止。

1. 對照來源核准紀錄

使用這個結構範本，以真實核准證據取代每個角括號中的值。它不是事實範例，也不是聲稱已達成的結果。核准前，將完整物件序列化為一段精確的 UTF-8 JSON 文字。驗證器應只接受這些欄位及型別，拒絕未知欄位，要求非空白字串及有效 UTC 時間戳記，將 kind 限定為 fact、preference 或 project_rule，並將 status 限定為 active、disputed 或 superseded。只有 active 狀態的紀錄可以注入。核准的陳述須符合引用的原始來源，包括生效日期及適用範圍。

{
  "schemaVersion": "memory-record/v1",
  "recordId": "<opaque stable record ID>",
  "ownerScopeId": "<trusted mapped scope ID>",
  "kind": "<fact | preference | project_rule>",
  "claim": "<precise source-supported claim>",
  "sourceId": "<private original-source ID>",
  "sourceRevision": "<original revision or exact source hash>",
  "sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
  "validFrom": "<UTC timestamp>",
  "checkedAt": "<UTC timestamp>",
  "status": "active",
  "reviewerId": "<approved human reviewer ID>",
  "reviewedAt": "<UTC timestamp>"
}

應用程式的私人核准憑據必須標示真正的核准者、擁有者許可、原始來源及修訂、範圍及允許代理、時效規則，以及這些精確 UTF-8 JSON 位元組的 SHA-256。它記錄的是人對實際陳述的判斷。紀錄中的 reviewerId 字串不是身分驗證。若仍有未解矛盾或缺少許可，不要持續儲存紀錄。Anthropic 儲存文字，但不驗證此結構描述，也不證明陳述為真。

2. 儲存並重新讀取

在授權工作區建立或選取範圍有限的記憶儲存空間，記下真正的 memstore_... ID。使用不敏感路徑，例如 /records/{opaque-record-id}.json。請求前，記錄操作人、UTC 時間、來源修訂、核准位元組雜湊、儲存空間及路徑，以及 pending 狀態。直接呼叫記憶儲存空間時使用 agent-memory-2026-07-22；工作階段呼叫使用 managed-agents-2026-04-01。Anthropic 表示，在儲存請求合併這兩個測試版標頭會傳回 HTTP 400。建立參考文件及記憶手冊展示以下 SDK 寫法；請將安裝的 SDK 與目前參考資料比對：

mem = client.beta.memory_stores.memories.create(
    store.id,
    path="/records/<opaque-record-id>.json",
    content=approved_json_text,
)

建立不會覆寫現有路徑。保存傳回的 mem_... ID，再列出限定儲存空間中的 /records/，把每個 next_page 用作下一頁的 page。預設基本清單不含內容。擷取選定記憶的 ID 以取得完整文字；將儲存空間 ID、記憶 ID、路徑、內容及 content_sha256 與核准位元組比較。在日誌與登錄表記錄回應及直接重新讀取的結果。只有建立回應並非完成檢查。若回應不確定，先檢查確切路徑及直接紀錄，再判斷發生什麼；僅搜尋不到結果，不足以重複建立。

3. 凍結選定修訂版本

每次後續執行都要驗證呼叫者，並從可信登錄表解析其範圍、儲存空間及選定紀錄 ID。如需尋找，遍歷限定前綴的所有頁面，再直接擷取選定的 mem_...。對傳回內容的 UTF-8 編碼計算 SHA-256，與供應商的 content_sha256 以及人工核准的精確位元組雜湊比對，再驗證一次 JSON。檢查紀錄 ID、擁有者範圍、來源修訂、active 狀態、來源是否仍有效，以及預先決定的時效上限。任一檢查失敗，就什麼都不傳。

將擷取的精確位元組一次寫入按雜湊定址的私人儲存空間，使用獨佔建立語意，例如 Python 的 open(path, "xb")。立即重新讀取檔案並計算雜湊，並在每次傳送前再檢查。絕不覆寫現有快照。檔案不完整，或同一位置已有不同位元組，都需要暫停並核對解決。把原始核准、儲存空間 ID、記憶 ID、供應商雜湊、快照雜湊、範圍決定保存在私人擷取憑據中。這種一次寫入快照是應用程式設計，不是 Anthropic 提供的固定版本掛載。

4. 將相同位元組提供給兩個新工作階段

用真正授權的代理及環境 ID 建立代理 A 的新工作階段，並且不要在下列欄位加入記憶儲存空間：resources。確認回傳工作階段的資源，以及代理的實際工具和憑證，都沒有其他存取儲存空間的路徑。Anthropic 的工作階段指南分別說明建立及傳送 user.message 的操作：

session = client.beta.sessions.create(
    agent=approved_agent_id,
    environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
    session.id,
    events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)

呼叫 events.send 前，重新讀取私人快照並計算雜湊。以確定性方式建構 message_text，包含明確的「已審查資料」標籤、紀錄與來源及審查識別資訊、不變的 JSON 文字及 SHA-256，接著放入原始來源可回答的具體問題。顯示的欄位是應用程式訊息格式，並非供應商回應欄位。傳送前，記錄完整 UTF-8 訊息位元組及雜湊、選定快照雜湊、授權代理 ID、工作階段 ID、傳送狀態。保存傳送結果與實際已傳送事件 ID，或可取得的事件清單重新讀取結果。傳送結果不明時，要重新讀取事件，不能盲目重傳。

為代理 B 建立第二個新工作階段，使用其另行核准的代理 ID，同樣不得存取儲存空間。重新讀取同一份一次寫入快照，驗證位元組雜湊，建構並記錄 B 的完整訊息，再傳送。兩則訊息的工作問題或收件者中繼資料可以不同；但須確認嵌入的 JSON 位元組與核准紀錄雜湊完全相同。對照原始來源檢查各代理回答及所有工具事件。合理的回答或引用，不能證明模型內部依賴了注入文字；訊息與供應商事件憑據能證明的是應用程式提供了什麼。若任一工作階段有即時掛載或其他存取儲存空間的路徑，就不要傳送。

5. 重新審查來源後才能更新

原始來源改變時，直接擷取目前記憶，與擁有者比較新舊證據。請人工核准精確的替換 JSON 位元組，包含穩定紀錄 ID、修正陳述或來源指標、新來源修訂，以及檢查與審查時間。保留舊憑據及雜湊。記錄 mem_... ID、目前直接讀到的 content_sha256、預定替換雜湊、操作人、核准及待處理狀態。文件中的條件式更新如下：

client.beta.memory_stores.memories.update(
    memory_id=memory_id,
    memory_store_id=store_id,
    content=approved_replacement_json_text,
    precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)

供應商對精確 UTF-8 內容計算雜湊，不作正規化。條件不符會傳回 HTTP 409 memory_precondition_failed_error。收到該回應或網路結果不確定時，重新擷取即時記憶，按需檢查版本歷史。比較競爭的來源修訂，請擁有者合併、拒絕或核准一份新的精確替換；絕不盲目重試過時寫入。成功後，必須直接擷取確認路徑、完整替換文字、雜湊及記憶版本 ID，才能把日誌狀態改成 confirmed。

從驗證過的修訂凍結一份新的核准快照。啟動新的授權 A、B 工作階段，不掛載儲存空間，重複兩次傳送及來源檢查。不要更改舊快照，也不要聲稱已傳送訊息會自行更新。將先前快照標為不再適用於後續注入。擁有者撤回紀錄時，停止新的傳送，依其保留與刪改政策處理：刪除目前記憶，不一定移除保留版本。封存或刪除整個儲存空間是另一項決定。

什麼才算完成

私人憑據應將原始許可及來源修訂連結至精確核准 JSON 雜湊；真正的工作區、儲存空間、路徑及 mem_... 身分與直接建立重新讀取結果；一份不可變快照；兩個不同、授權且未掛載的工作階段 ID，以及已傳送訊息雜湊、對照來源檢查的回答；核准的條件式更新、新的直接讀取及新工作階段檢查。任何連結不明，就把整個練習標為未完成，保留確切暫停原因。實際執行時，記錄工作階段、工具的真實用量及帳戶對應費用；這份僅依文件撰寫的指南未測量節省或模型表現。

相關但不同的工作方面，為後續工作階段審查一份 Dream 輸出處理的是生成的儲存提案。這裡的流程從擁有者核准的來源紀錄開始，固定兩個取用端實際接收的內容。