系列說明 >> 本系列大部分 PR 來自私人或公司專案，部分程式碼、環境設定與實作細節不便公開。

我只能保證文中提到的 PR 與問題皆為真實案例，但會經過必要的匿名化與內容調整。

本系列主要分享問題如何被發現、背後的思考方式，以及解法如何形成，不會深入討論完整實作與部署細節，敬請見諒。

Today’s Change

• Base Repo： paulshaclaw
• Change Ref： PR #57－feat(stage2): add dream service and replay bundle＋PR #60－feat: add stage2 paulsha mem moc pipeline
• Issue： D24 已能把 Captured Session 拆成帶 Provenance 的 Atomic Slice，但 Slice 數量持續增加後，手動瀏覽檔名、逐一重建 Relation 與臨時拼接 Context 都不可長期維持。Knowledge 有被保存，卻沒有穩定的整理、搜尋與重播入口。
• Root Cause： Atomize 只解決 Knowledge Unit，沒有回答何時整理、如何 Materialize 可讀導覽、如何建立可重建索引，以及 Agent／Operator 需要一組 Knowledge 時該怎麼安全組裝。若全部靠前景 Session 即時處理，整理成本又會回到人腦。
• Solution： 建立 Idle-gated Dream Background Loop，負責在系統空閒時執行整理與提案；加入 MOC Materialization、Readable Naming、Relation Links、SQLite FTS Search，以及只組裝 Distilled Knowledge 的 Replay Bundle。MOC Pass 若退化會向上回報 partial，不得靜默當成功。
• Evidence： Dream E2E、Memory Suite、Stage 2 Integration 與 Full Repo Tests 通過；MOC／Search 亦完成 Conflict、E2E 與 Integration Regression。這些證據支持 Slice 已能被背景整理、索引、搜尋與重播；它不代表搜尋結果一定相關，也不代表 Agent 在真正 Task 出現時已經會讀取它。

Atomic Slice 都很乾淨，我第一個反應還是 grep

上一篇，Transcript 終於被拆成一張一張可追來源的小卡。

剛開始用起來，確實比整本 Transcript 輕鬆。

每張 Slice 都比原本的 Session 短，也知道從哪裡來。

然後 Knowledge 目錄開始往上長：

serialwrap 一批
testpilot 一批
paulshaclaw 一批
不同 Project、Session、Relation 又各有一批

反正都是 Markdown，需要時 grep 就好。

小bu也覺得沒問題。

「知道關鍵字就找得到。」

對。

問題是如果我已經知道正確關鍵字，通常也差不多知道答案在哪裡了。

例如前面那組 Service Cutover 經驗，可能寫成：

old timer
second state owner
manager daemon
service cutover

下一隻 Agent 搜的是「拆 Repo 之後舊程式要不要留」，不一定會碰到同一組字。

老Go翻了幾個目錄。

「以前是一本帳讀不完。」

「現在是幾百張卡片，還得先知道它們各自叫什麼。」

很好。

Memory 成功從「太長」進化成「太散」。

我差點再維護一份總目錄，小re只問：它跟 Slice 不一致時信誰？

既然檔案太散，我乾脆想做一份總目錄。

依 Project 把 Slice 排好，順手補上 Relation，讓人先從目錄往下找。

小bu已經準備開一份新的 Markdown：

「這個我來維護。」

我差點就讓它動手。

小re問：

「新 Slice 進來後，誰保證總目錄一定同步？」

「背景流程可以更新。」

「如果總目錄跟原 Slice 不一致，哪份算真的？」

……Slice。

「那就不要把目錄寫成第二份 Knowledge。」

這一問把 MOC 的身分定下來了。

MOC 是 Map of Content，也就是把散落 Slice 依 Project 與 Relation 組成可瀏覽入口。

但它只是 Materialized View。

Knowledge Slice + Relations Ledger
            ↓ rebuild
           MOC

MOC 畫錯，可以重建。

不能拿 MOC 反過來改寫原 Slice，再養出另一份 Authority。

這跟前面幾天的 Read Model 是同一條底線：

好讀可以是衍生能力，不能順便取得改寫真相的權力。

每次開工前重建 MOC，好像很合理，但也太沒效率

有了可重建的 MOC，我又想：

Agent 開工前先重建一次，保證看到最新資料。

小bu覺得這次很穩。

「反正重建是 deterministic，跑完再開始。」

小ma抬頭：

「MOC Pass 退化時，前景工作要一起卡住嗎？」

不應該。

Atomize、Relation、MOC、Index 都是整理工作。

它們很重要，但不該每次都在使用者送出 Prompt 時，把前景 Session 先扣在門口等全套重建。

這時 PR #57 的 Dream 才有合理位置。

Dream 不是模型半夜自由悟道。

它是一條 Idle-gated Background Loop：系統空閒時，再去跑整理、索引與 Replay 準備。

Foreground Task
→ 優先做工程工作

System Idle
→ Atomize / MOC / Index / Replay preparation

背景執行也不代表可以把失敗藏起來。

每個 Pass 仍會留下結果；MOC 若退化，整輪回報 partial，不能因為 Process Exit 0 就寫成乾淨完成。

換到背景的是時間。

不是 Evidence 標準。

Search 找候選，小bu又想把命中的全部塞回 Context

PR #60 接著補上 SQLite FTS Search，也就是對 Knowledge Slice 建立可重建的全文索引。

這讓 Operator 可以問：

「跟 Service Cutover 有關的經驗在哪裡？」

Search 會先找出候選 Slice。

小bu看著結果清單：

「既然都命中了，整批交給 Agent 不就好了？」

小re問：

「命中的是候選，還是已經通過本次 Context Boundary 的答案？」

不是同一件事。

所以另一邊還有 Replay Bundle：Selector 選出需要的 Slice 後，再組成一份可交給 Agent／Operator 的 Artifact。

Search
→ 找候選

Replay Bundle
→ 把選中的 Distilled Knowledge 組成可重播集合

而 Bundle 只收 Distilled Knowledge。

不把 Raw Transcript 順手全包回去。

否則 D24 好不容易把整本帳拆開，Replay 時又把整本帳塞回 Context，整條 Pipeline 只是繞了一圈回到原點。

今天蓋好的是圖書館，還不知道讀者進門時要找哪一本

PR #57／#60 能支持：

• Dream 可以在 Idle 時執行背景整理。
• MOC 能把 Slice／Relation Materialize 成可瀏覽地圖。
• FTS Search 能提供文字檢索入口。
• Replay Bundle 只組裝已蒸餾 Knowledge。
• MOC 退化時會向上回報，不會靜默成功。

它們不能支持：

Search 命中就代表 Agent 真的使用，也不能保證 Session 一開始就拿到跟當前 Task 有關的 Knowledge。

因為 Session 剛開始時，系統通常只知道你在哪個 Project。

使用者這一輪到底要修 UART、搬 Service，還是查 Plan Authority，可能還沒說。

老Go把 MOC 關掉。

「圖書館總算蓋好了。」

「讀者進門時，館員還不知道他今天要查什麼。」

下一篇，Knowledge 都躺在 Memory 裡，Agent 開工時怎麼還是不知道？

Have a nice day.