系列說明 >> 本系列大部分 PR 來自私人或公司專案，部分程式碼、環境設定與實作細節不便公開。
我只能保證文中提到的 PR 與問題皆為真實案例，但會經過必要的匿名化與內容調整。
本系列主要分享問題如何被發現、背後的思考方式，以及解法如何形成，不會深入討論完整實作與部署細節，敬請見諒。
Base Repo： paulsha-hippo
Change Ref： PR #30－feat(hooks): 跨 CLI recall＋offered/read/applied funnel＋capability matrix → PR #59－feat(usage): session 層級 offered→read→applied 漏斗報表
Issue： D26 已能依 Task 提供 Shortlist 並觀察 Agent 的實際 Read，D27 又把 Memory 拆成可獨立使用的 Hippo；但原本的 Usage 只看得到 Slice 層級計數，回答不了「拿到 Memory 的 Session，到底有多少真的往下讀」。第一份把全部 Offered Session 算進分母的報表，Read-through 只有 0.09%。
Root Cause： Usage Event 本身沒有壞，壞的是我怎麼解讀它。報表分母混入大量 Title-generation no-findings Session，它們不是來解工程 Task，也不預期使用 Memory；另一邊，沒有先 Offer 就直接開檔的 Direct Read 若混進 Conversion，又會把別人的功勞算到 Shortlist 身上。
Solution： 以收到非空 Memory Shortlist 的 Session 建立 Offered→Read→Applied Funnel；預設排除最終狀態為 no-findings 的已知 Noise。Read-through 只計同一 Session 先 Offer、之後才 Read 的事件，Direct Read 另列；Applied 採顯式 Acknowledgement，寫入前必須能反查到對應 Offer。
Evidence： 含 Noise 時為 23,478 Offered Sessions、Read-through 0.09%、Applied 0.06%；排除 23,333 個 Title-generation Noise Sessions 後，剩 145 Sessions，Read-through 15.17%、Applied 9.66%。另有 Offer-then-read 48 events / 22 sessions、Direct Read 550 events / 2 sessions。PR #59 新增 7 Tests，報表為唯讀，執行前後 Ledger／Index 檔案狀態不變。這些證據支持 Memory Consumption 已能被較誠實地歸因，不代表 Memory 內容正確或改善 Engineering Outcome。
上一篇，Hippo 已經可以離開 paulshaclaw 自己活著。
Capture 會收。
Dream 會整理。
Task 進來會找 Shortlist。
Agent 真的開 Knowledge，也會留下 Read。
前面折騰這麼久，我一直沒敢認真算一件事：
到底有多少 Session 收到 Memory 後，真的會往下翻？
原本的 hippo usage 會告訴我某則 Slice 被送過幾次、開過幾次。
看久了還是一團。
slice A offered 73
slice B read 4
slice C applied 1
我想看的不是哪張卡片比較紅。
是一百個拿到 Memory 的 Session，到底有幾個真的往下讀。
所以把事件改成用 Session 折起來看。
第一張報表跑出來：
sessions_offered: 23,478
read-through: 0.09%
applied-rate: 0.06%
我看了一次。
再看一次。
0.09%。
這不是低。
這根本像沒人在理 Hippo。
我差點先往「是不是 Offer 太多」那邊想。
但 23,478 看久了更奇怪。
我哪來兩萬三千多個工程 Session？
沒有。
那這些 Session 到底在幹嘛？
我去翻 Processing Ledger。
一折到最後狀態，先冒出一大坨：
state: no-findings
數量：
23,333
再往裡面看。
幾乎都是 Title-generation。
也就是幫文件、Slice 取標題的 Session。
不是來修 UART。
不是來做 Service Cutover。
也不是來追 Plan Authority。
它們根本不需要拿 Memory 去解工程問題。
老Go看完只問：
「你不是要算有多少工程工作會查資料？」
「幫筆記取名字的也算讀者？」
……
對喔。
我前面居然拿二萬三千多個「取標題」的 Session，去當工程 Memory 的使用母體。
這不是 Hippo 沒人用。
是我的分母先飛走了。
把最終狀態為 no-findings 的 Title-generation Noise 排掉後，再跑一次：
sessions_offered: 145
read-through: 15.17%
applied-rate: 9.66%
從 0.09% 變成 15.17%。
Hippo 沒有在我查 Ledger 的這段時間突然開竅。
變的是分母。
原本的數字在回答：
所有被記成 Offered 的 Session 裡，有多少 Read？
我真正想問的是：
真正在做工程 Task、又拿到 Memory 的 Session，有多少往下 Read？
只差一個篩選條件。
結果差兩個數量級。
我本來都快開始懷疑 Recall 是不是整套沒人要用了。
查完才發現，第一個該修的不是 Retrieval。
是我拿一個被 Noise 灌爆的分母，準備對整套 Memory 判死刑。
數字變成 15.17% 後，我在筆記裡先寫了一句：
Memory 開始有效了。
小ma看了一眼。
「Read 是什麼？」
Agent 真的開過 Knowledge。
「那有做對嗎？」
……
沒有這回事。
我把那句刪掉。
這裡才真的需要把三個事件拆清楚：
Offered
→ 系統有把 Memory 送到 Session
Read
→ Agent 真的開啟 Knowledge
Applied
→ Agent 明確表示這次有採用它
而且 Applied 也不是靠看回答裡有沒有出現相似字串猜的。
PR #30 要求 Agent 留明確的 Structured Acknowledgement。
寫入前還要回頭查：
這則 Memory 前面有沒有真的 Offer 給這個 Session？
沒有對應 Offer，這筆 Applied 不收。
至少不會讓 Usage Ledger 自己亂認親。
但就算三層都成立，也只能證明：
送到了
打開了
Agent 說用了
不等於：
做對了
測過了
真的改善 Outcome
這條線不能偷跳。
不然前面才剛把分母修乾淨，後面又自己把 Claim 灌水。
報表裡還有一組數字很搶眼：
offer-then-read: 48 events / 22 sessions
direct-read: 550 events / 2 sessions
550 比 48 大太多。
乍看很爽。
Memory 被打開五百多次。
但小re只問一句：
「那 550 次前面有 Offer 嗎？」
沒有。
那就不能拿來算 Shortlist 的 Read-through。
Direct Read 是 Agent 沒有先收到該 Session 的 Offer，仍然直接去開 Knowledge。
可能是 Operator 指定 Path。
可能是 Batch Tool。
也可能是 Agent 本來就知道檔案在哪。
它們是真的 Read。
但不是 Offer Conversion。
如果今天要問的是：
Knowledge 總共被開過多少次？
當然要算。
但我現在問的是：
Shortlist 塞出去後，到底有多少 Session 真的往下讀？
那 550 次就得站旁邊。
不然前面才把二萬三千個不該算的 Session 從分母拿掉，後面又把五百多次不該領的功勞塞進分子。
數字一樣會很好看。
只是已經不是原本那題。
PR #30／#59 到這裡能回答：
有沒有送到
有沒有真的打開
有沒有明確表示採用
也能把不該進分母的 Title-generation Noise 排掉，把沒有先 Offer 的 Direct Read 另外算。
但 15.17% 到底算高還是低？
不知道。
Agent 說 Applied 的 Memory 到底有沒有幫它少踩一次坑？
也不知道。
現在只是終於有一份不會先把自己騙死的 Usage Funnel。
接著很快就冒出另一個問題。
既然已經知道哪些 Memory 被 Read 過：
被讀過的，要不要比較容易被找回來、比較晚被清掉？
那一直沒有被 Read 的呢？
這次先不要急著刪。
下一篇，被讀過的記憶，應該比較容易留下來嗎？
Have a nice day.
iThome鐵人賽
看影片追技術