我們前面幾篇講述的是"知識怎樣表示、組織與檢索"，但一個上線運行的用戶記憶或共享知識庫還會持續收到新訊息。只更新不整理，內容會越來越亂; 只做定期重寫，新訊息又無法即時生效。因此，完整的更新機制需同時包含兩條路徑：事情觸發的增量更新 以及週期觸發的全量整理。

用戶記憶與知識庫的增量更新

增量更新處理的是"剛剛出現了一條新證據，應該對當前知識做甚麼局部修改"。最穩妥的工程答案是：把知識庫當程式庫，把每次知識變更當成一次pull request(PR)。這不只適用於User as Code這類python形式的可執行記憶; Markdown知識庫、用戶記憶文件和規則文件同樣應該進入Git，獲得差異審查、版本歷史、責任追溯和一鍵回滾能力。生產環境不應讓任何一個模型繞過審核，直接改主分支或線上向量庫。

具體可以使用提議者-審核者 模式，把知識更新做成一個有外部證據的迭代閉環：

1.Proposer Agent提交PR：它從原始證據中發現新事實、衝突或過期內容，在工作分支上提出盡可能小而完整的Diff。它不是把最新一次對話粗暴追加到文件末尾，而是先檢索相關的已有知識，再增、刪、改對應條目，同步維護連接、索引、時間元數據與證據引用。
2.Review Agent獨立審核：它拿到變更前的知識、diff和原始證據(ex.execution trajectory、原始對話、業務文件或工具執行結果)，獨立檢查每個新斷言是否能被證據支持、是否遺漏限定條件、是否與其他文件衝突，以及刪除或改寫是否過度，它應返回指向具體證據和行號的可執行意見，而不是模糊地說"還需要改進"。
3.雙方迭代至收斂：Proposer根據拒絕理由修改diff，Reviewer再次回到原始證據覆核; 只有Reviewer明確批准，PR才可合入。同時要設置最大迭代次數或成本預算; 超出上限仍未收斂時轉入人工審核，不能默認放行。
4.合入後再發布：CI先檢查格式、連接、元數據、權限標籤; 若知識以程式表示，還要運行類型檢查和測試。通過後才從已合入的版本增量重建受影響的分塊、摘要和向量索引。因此索引是可重建的派生物，Git中已審核的知識才是真正的來源。

這條流水線應當明確分開3層：原始證據層保存只增不改的對話、軌跡和原始文件; 知識層保存經過提煉、可持續修訂的markdown或是程式; 服務層保存從特定已合入版本生成的檢索索引。PR需要紀錄證據指標、知識庫版本、審核意見與最終決定，使線上的每條知識都能回答"從哪條證據而來、誰在何時批准"。

今天稍微短一些，明天整理一下。

Vals AI 測試 Claude Fable 5.1，在零人工干預下耗時 44 分鐘破解懸宕 370 年的烏克哈特歷史密文，並順勢解開《The Jewel》285 字八行詩密文。
https://www.aiposthub.com/claude-fable-solves-cyphral-distich-urquhart-cipher/