【2026 最新】Hindsight 記憶驗收怎麼做？Hermes 漏記、Tag 與重算的六步檢查

你讓 Hermes 記住專案期限，隔天問它還能答對，就以為記憶正常。直到對話變長、新期限漏掉，或帳單裡反覆出現整合工作，才發現「查得到舊資料」與「新資料可靠寫入」是兩件事。Hindsight 記憶驗收要把這個差別變成看得見的證據。

這篇寫給第一次維護 Agent 記憶、願意複製簡短指令的讀者。你會用一段假對話，沿著原文、切塊、事實與查詢逐層核對，再留下更新前後的驗收表。以下是依截至 2026 年 10 月 7 日的官方文件、程式碼與兩則原始回報設計的方法；本文未在 Hindsight 服務上執行這組測例，表中的結果由你自己的環境填入。

先說結論：Hindsight 記憶驗收要看四張收據

記憶驗收＝原文對得上＋關鍵事實找得到＋來源說得清＋整合工作可解釋。把記憶系統想成倉庫：Retain 是收貨，Chunk 是分箱，Fact 是貨品索引，Recall 是找貨；Consolidation 則把多張索引整理成長期摘要。找到一箱舊貨，並沒有驗過今天的收貨單。

• 先保存假對話與版本，再送進獨立測試 Bank（記憶庫）。
• 沿同一個 document_id 查原文切塊、抽取事實與 Recall，錯在哪一層就記在哪一層。
• 比較追加、Tag 變動、壓縮及重啟；把整合呼叫與真正保留的成果一起計帳。

為什麼能 Recall，仍值得查漏記與重算？

2026 年 10 月 5 日，Issue #5262 的回報者指出，Hermes connector 把每輪訊息包成內層陣列，最後形成巢狀陣列，使對話專用切塊分支未被選中。回報環境為 integration 1.0.1、client 0.10.2、API 0.10.0；它描述的是接縫與說話者脈絡問題，不是所有記憶都消失。

同日的Issue #5267描述另一條路：同一文件追加時，Tag 在 session:S 與加上 parent:S 的集合間變動，導致 observations 被清除後重整。當事人用 API 0.10.2、integration 1.1.0 與指定 Hermes commit 提供資料；後續也貼出本機補丁與一小時觀察。這些是當事人自報，並非官方修復交付或普遍故障率的證明。

本文把這兩種疑點變成驗收題。你不必先判定作者的根因全對；只要能留下「送出了什麼、儲存了什麼、哪些工作被重做」，就有材料定位自己的問題。若還不熟悉 Hermes 的工作方式，可先讀Hermes 進階教學。

先懂原理：原文、事實與 observation 各驗什麼？

Hindsight 的Documents 文件說明，切塊保留來源文字片段；抽取出的 facts 則是模型整理的資訊。兩者不應逐字相等：原文像會議錄音，fact 像會議紀錄。驗收要問的是必要的日期、否定與責任人是否保留，不能要求每句寒暄都變成一則 fact。

Observation 是以來源事實整理出的較長期認識。官方 observations 說明介紹這層整合；驗它時要沿來源 ID 回查，不能只看摘要句子漂亮。新事實已寫入、長期摘要仍在等待，是可以分開記錄的兩個狀態。

還有一個容易誤判的細節：Recall 文件列出來源 chunks 的獨立 token 預算，最後一塊可能因回傳預算被截短並標示 truncated。看到 Recall 裡的句子少一半，先查完整儲存切塊，再判定是不是寫入問題；否則會把「展示太短」誤當成「倉庫漏收」。

Hindsight 記憶驗收的六步流程

① 建「測試倉庫」：先隔離 Bank 與版本

怎樣避免試一個設定，污染正式記憶？建立獨立 Bank，凍結環境收據。把 Hermes commit、Plugin resolved commit、client／API 版本、模型名稱、Bank 設定和 UTC 時間存成 environment.json。執行 hermes plugins list 查看已安裝插件，再在自己的 Hermes 原始碼目錄執行 git rev-parse HEAD；它們回答不同版本問題。

官方10 月 1 日插件遷移指南說明，插件現在獨立更新，安裝資訊中的 resolved commit 與 pin 很重要。單獨更新 Hermes，不能作為「connector 已換版」的驗收證據。新裝的讀者可用 hermes plugins install hindsight，接著 hermes memory setup 選 Hindsight；安裝完成後還要確認 memory.provider。已正常使用的人直接做驗收，無須重裝。

依HTTP API Reference建立兩個全新 Bank，例如 accept-fixed-01、accept-flip-01；建立 Bank 的路徑是 PUT /v1/default/banks/{bank_id}，JSON body 可用 {}。將測試專用 Hermes profile 的 bank_id 指向其中一個，並檢查動態 bank_id_template、鏡像與 additional banks，確認寫入目的地只有測試庫。

② 做「標準答案」：保留說話者與跨接縫句子

對話這麼長，怎麼知道漏了哪一句？先定三個必答欄位，再產生固定假對話。案例使用虛構專案 ALPHA-17：舊期限 11 月 20 日；使用者改成 2026 年 11 月 22 日，且只有 Mina 能批准延後；助理提出的 11 月 30 日只是問句，並未獲准。

把以下內容存成 make_fixture.py，執行 python3 make_fixture.py。中間的重複填充只是拉長對話，讓尾端關鍵句有機會碰到切塊接縫；它不是模型品質評測題。

import json
from pathlib import Path
messages = [
 {"role":"user","content":"ALPHA-17 負責人 Mina，期限是 2026-11-20。"},
 {"role":"assistant","content":"已記下原訂期限。"},
 {"role":"user","content":"背景筆記；" * 700 + "ALPHA-17 期限改成 2026-11-22；只有 Mina 能批准延後。"},
 {"role":"assistant","content":"如果改成 2026-11-30，可以嗎？"}
]
Path("source.json").write_text(json.dumps(messages, ensure_ascii=False), encoding="utf-8")

這支程式只建立素材。把同樣內容按四則訊息送入測試 Hermes 對話，保存實際 connector 請求；另外可把 source.json 的文字作為直接 API 對照。後者測 Hindsight 接口，前者才測 Hermes connector，兩種結果不能互相冒充。送入後的驗收題固定為「最新期限？」「誰能批准延後？」「11 月 30 日是否已獲批准？」。

③ 查「分箱接縫」：先看真正儲存的 Chunk

答錯期限，問題一定是模型忘記嗎？沿來源逐層對帳。從 retain 回應或 documents 清單找到實際 document_id，讀取 GET /v1/default/banks/{bank_id}/documents/{document_id}/chunks?limit=100&offset=0。回應有更多頁時繼續移動 offset，保存全部切塊；只查第一頁會漏掉後面的證據。

逐塊找出 ALPHA-17、11 月 22 日與 Mina 的句子，檢查相鄰塊能否拼回必要上下文，並保留 user／assistant 的角色。再用 GET /v1/default/banks/{bank_id}/memories/list?document_id={document_id}&limit=100&offset=0 保存抽取事實，同樣查完分頁。原文完整、fact 少了否定，先記為抽取層；fact 正確、查詢漏掉，再追檢索範圍與預算。

在本次核對的固定 commit 切塊程式中，平面訊息陣列可進入對話分支；但單輪超過 retain_structured_chunk_size 仍可能切分。把巢狀格式修成平面格式，不能推得「任何長度的輪次都完整不切」。驗收收據應同時記錄普通 chunk 與 structured chunk 的設定。

④ 比「追加工作」：固定 Tag 與變動 Tag 分開

每次追加都重整，是必要工作還是異常？用兩組相同內容，只改 Tag 序列。固定組每次維持 ["session:s1"]；變動組依序使用 ["session:s1"]、["session:s1","parent:s1"]、再回到第一組。兩個 Bank 從相同初始資料開始，使用相同 document_id、模型與切塊設定。

依Retain 文件，API 追加項目使用 update_mode: "append"，並提供固定 document_id。示意 body 為 {"items":[{"content":"ALPHA-17 增補：會議改到週三。","document_id":"accept-doc","update_mode":"append","tags":["session:s1"]}],"async":false}，送到 POST /v1/default/banks/{bank_id}/memories。這是伺服器對照樣本，真 connector 的內容與 Tag 則另保存。

每次追加後，等 retain operation 完成，再在相同整合控制條件下取快照：來源 fact ID、updated_at、consolidation 狀態、observation ID 與來源關係。需要手動觸發時使用 POST /v1/default/banks/{bank_id}/consolidate，並追完其 operation；自動排程開啟時，把自動工作也記下，不能混成一筆「我按了一次」。

Tag 不是貼紙而已，它也可能決定 observations 的範圍。官方文件明列重新標記可能使衍生 observations 失效；所以「有重整」本身不足以判錯。要找的是：同一來源、相同作用範圍，是否反覆丟棄工作；或本來應穩定的 session Tag，為何在不同程序間來回變動。也不要把來源追蹤 Tag 當成資料存取授權。

⑤ 測「壓縮與重啟」：看請求內容有沒有變

長對話壓縮後，舊資訊從哪裡找？把對話壓縮與記憶 consolidation 當成兩條流程。前者縮短 Hermes 眼前的對話，後者整理 Hindsight 的事實；名稱都像整理，工作卻不同。保留壓縮前後 session ID、parent_session_id、實際 retain Tag、document_id 與查詢結果。

在獨立測試對話中，先正常追加，再依你固定版本的 Hermes 操作讓它進入壓縮，保存 compression 事件；接著按正常關閉流程停止測試程序，確認待辦 retain 完成後重啟。同一題在重啟後再問一遍，對照 Tag 與來源事實。如果未真正觸發壓縮，就把那格標成「未執行」，不能把普通續聊當成壓縮測試。

對 #5267 的補丁也用同一把尺：當事人後續指出，長駐程序可能仍持有舊模組。更新檔案、重啟程序、伺服器換版應各留時間。本文不提供直接覆寫正式插件的補丁指令；先在測試環境驗來源、相容性與這套收據，再選擇是否採用一個明確 commit。

⑥ 填「驗收收據」：把品質與工作量放一起

費用降了就算成功嗎？同時驗事實與保留成果。每輪固定觀察窗口，分開記錄 retain、consolidation、embedding 與其他工作；同一輪看 observation 數量及其來源是否保留。呼叫數與金額都取實際紀錄，沒有分項就填「缺資料」，不要用總帳單硬推 consolidation 費用。

你可以先建立 CSV 表頭：run_id,phase,hermes_sha,plugin_sha,api_version,bank_id,document_id,tags,source_ok,facts_ok,recall_ok,observations_kept,consolidation_calls,cost,decision。每格用「通過／失敗／未執行／缺資料」，再附原始檔路徑。保留成果的成本＝同一窗口內總相關費用 ÷ 驗收通過且仍保留的成果數，分母為零就記未產生成果，不計一個虛假的低成本。

怎樣判讀結果、停手與復原？

先跑不帶 Tag 篩選的 Recall 查三題，再用實際產品的 types、Tag 與預算重跑；HTTP body 可用 {"query":"ALPHA-17 的最新期限與批准人？","types":["world","experience","observation"],"include":{"chunks":{}},"trace":true}。送到 POST /v1/default/banks/{bank_id}/memories/recall。如果只有廣範圍查得到，下一步查產品篩選設定；不是立刻判定寫入失敗。

把答案對回三個標準欄位：期限 2026-11-22、批准人 Mina、11 月 30 日未獲批准。這是本案例的驗收規格，不是預測系統一定返回的文字。用相同問法做固定次數的重複，再比較更新前後；保持模型、切塊與觀察窗口相同，避免一次改三件事，最後不知道哪一件造成差異。

• 立即停：資料寫到正式 Bank、來源包含真實個資、超出你預先設定的測試預算，或必要事實持續失敗。
• 暫緩放行：只有 Recall 截圖、缺請求／來源 ID、整合工作未完成，或某個必測階段仍標「未執行」。
• 復原：先停止測試寫入，保存問題包，回到已保存的設定與已驗過 commit；重新啟動後再驗，保留原 Bank 的資料。回退程式與復原資料分開處理。

一份可交給維護者的最小問題包，包含去識別化原文、版本收據、完整請求、全部 chunks／facts／Recall、operation ID、時間窗口、費用資料與預期／實際差異。只附「它忘記了」讓人猜；指出「source.json 的第幾則訊息，在 chunk／fact／recall 哪一層變了」，才有可追查入口。

FAQ：八個直接答案

1. Recall 答對一次，就通過記憶驗收嗎？

還不夠。再查新事實、來源、壓縮與重啟；一次命中只證明那次查詢取到了答案。

2. 每句原文都必須變成 fact 嗎？

不需要逐字對齊。先寫必要欄位與 extraction mission；寒暄可省，期限、否定與批准人則按本案例要求驗。

3. 跨 Chunk 就一定是 bug 嗎？

不一定。超長單輪可依 structured limit 切分。要核對設定、上下文與角色，而不只是數箱子。

4. 固定 Tag 就能處理所有重算嗎？

先當成對照條件。#5267 還討論相同 Tag 下 updated_at 影響在途工作；單一操作不能當成全部問題的修復。

5. 壓縮就是 consolidation 嗎？

是兩種流程。一個整理對話上下文，一個整理記憶事實，各自保留事件與來源。

6. Issue 貼了補丁，可以寫成官方已修復嗎？

必須另核對交付。本機補丁、主分支 commit、catalog pin 與你實際載入版本逐項查，不能用其中一項替代其他項。

7. 新舊版本費用怎麼比較？

先對齊工作量。使用相同對話、模型、設定與窗口，區分首次補齊積壓工作和反覆重做，再看驗收成果是否保留。

8. 沒有服務帳號，今天能做什麼？

先完成素材與判準。產生 source.json，寫好三題標準答案與 CSV 欄位；執行環境到位後再填結果，現在不要填通過率。

給新手的三個重點

• 先驗「收進來了嗎」，再驗「找得到嗎」；原文、事實與查詢各有收據。
• 把 session、Tag、壓縮和 consolidation 分開記；重整是否合理，要由工作與來源判定。
• 更新前後用相同素材與判準。通過要有證據，缺資料就保留缺資料。