系列：「邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力」— 第 11 天
紀錄日期：2026-09-21
能力區：第 4 區 記憶與 RAG（兼第 9 區 評估）｜類型：做

工作草稿，已存網站草稿、尚未發布。Day 10 的能力地圖已收尾，本篇另開新的實驗單位；不因增加探針就調高能力分數。原候選題 prompt-transit-check 保留到後續，不冒稱本日重新執行過。

它是什麼

記憶召回是把儲存內容帶到本次回答；工具則讓模型能再搜尋或讀取細節。兩者接起來，還要觀察模型是否做了有用的選擇，不能只看到工具呼叫成功就算任務完成。

專案裡哪件事逼我用到

Spectyn 希望使用者改正一次偏好，之後換對話或執行器仍能使用新值。上一批 MemOS 探針只把自動召回的 packet 交給模型，沒有接上 memos_search/get。因此今天先補宿主能力，讓比較的限制更小、更明確。

做之前我以為

我以為把搜尋與讀取工具補上，模型至少有機會自行找回修正。另一個假設是，設定 llmFilterEnabled=false 就能測到關掉篩選的效果。這兩個假設都要用實際軌跡核對。

做完的證據

新的 TypeScript 探針提供簡化工具 schema，把模型呼叫轉成上游 MemoryCore.searchMemory/getTrace；保留工具輸入、回傳與下一輪回答。資料來自上一批三個獨立 SQLite 資料庫的 backup 副本；模型仍是同一個 Llama 3.2 64K alias，向量模型仍是 all-minilm。這是自寫實驗宿主，不是完整上游 App 的測試。

最重要的一段 runtime 證據是：

{"requestedLlmFilter": false, "lightweight": true, "effectiveLlmFilter": true}

上游 lightweight 模式會覆蓋這個設定。這一批結果保留為設定診斷，沒有拿它證明篩選好或不好。前三個召回判準則由作者依回答語意核對；語言案例問的是偏好的語言名稱，不是模型用哪種語言輸出。

今天真正學到的

遇到舊記憶問題，至少拆成四個觀察點：新資料是否存在、自動召回選了什麼、模型實際使用哪些工具、最後用了哪個值。今天補到後三段的部分證據，並找出一個設定未生效的實驗陷阱。單次三例不足以判定框架整體能力。

如果你也想這樣做

先保留失敗資料庫，再從副本做下一輪；保存原問題，不把正確答案塞入工具描述；把程式強制搜尋與模型自主搜尋分開；改參數後核對實際生效值。完整參數與原始輸出見工作樹 MESH-COMPOSITION §15、m5 round3 證據。

明天

等使用者在裝置完成 Apple 安裝驗證，繼續 PocketPal 小模型真機測試。同時為桌面召回補更精細的候選／篩選觀測；不把工具接通當成 Spectyn 主記憶已換好，也不在文章中虛構手機量測數字。

審查補註：「舊」指各案例 initial 訊息中的值，新值指時間較晚的 correction 訊息。直接核對本批 DB，三案均保留 initial/correction 兩筆 trace 及各1536-byte向量 blob（384個float32）；檢索 log 的 tier2 traceCount 為2。本輪未另驗向量索引內部一致性。false 設定未生效的重跑，對篩選效果既非正證也非反證，該效果仍未量測。PocketPal 尚未安裝，沒有裝置端推論證據。