系列：「一人艦隊：用一群 AI CLI 打造跨平台代理 mesh」— 第 26 篇
紀錄日期：2026-09-21

工作草稿，已存網站草稿、尚未發表。本篇接續 Day 25，記錄新的測試工具與實測結果。篇次代表素材順序，不代表已連續發表，也不把失敗測試算成產品完成度。

今天的一件事

上一篇把開源選型的接點畫清楚，也開始測記憶修正。今天不再擴大候選清單，先補上一個已知的測試缺口：MemOS 自動召回的文字會提示模型可以使用 memos_search 和 memos_get，但上一輪的探針沒有提供這兩個工具。

如果工具根本沒接上，答錯只能代表那個受限探針失敗，不能拿來評斷完整系統。今天做的第一件事，是把這個缺口補成能觀察的呼叫鏈。

手機先往前一步，但停在真正需要人的地方

iPhone 13 mini 的鏡像已能操作。我在 App Store 找到 Asghar Ghorbani 的 PocketPal AI，按下取得與安裝，接著遇到 Apple 帳號密碼驗證。這一步留給使用者在裝置上完成，不收集密碼。

目前證據只有「能操作真機並走到官方安裝驗證」，還沒有 App 安裝完成、模型載入或離線推論的成績。上一篇的鏡像連線阻礙已解除，新的阻礙是安裝驗證；兩者不能混成同一個手機測試通過。

等待驗證時，繼續做不依賴手機的桌面實驗。

寫一個真的會執行工具的宿主

新的 memos-toolhost 探針向本機 Ollama 提供兩個工具，接收模型的 tool_calls 後，呼叫上游的 MemoryCore.searchMemory 或 MemoryCore.getTrace，再把結果送回模型。最多四輪，每次模型請求有逾時限制，保存每個模型回應、工具參數和實際回傳值。

這是自己寫的實驗宿主與簡化工具 schema，不是完整 OpenClaw 或 Hermes 整合。它補上先前欠缺的能力，但不能因此說已覆蓋上游所有工具行為、隔離或權限。

資料也不重做成比較容易答對的版本。我用 SQLite backup，把上一輪三個案例的資料庫各複製一份；保留同一個 Llama 3.2 的 65536-context alias、all-minilm 384 維向量與原始問題。每案獨立程序、獨立資料庫。這次只測召回，不重新寫入修正。

三次都真的叫了工具，三次仍然答舊值

三次都是兩輪模型回應、一次 get 呼叫，沒有自主 search。自動召回先給了舊紀錄，模型再讀那一筆的完整內容，最後用舊值回答。

所以「工具呼叫成功」和「任務成功」是不同的事。這次工具確實接通了，但並沒有讓模型主動找出修正。表格只代表指定模型與宿主設定的單次結果，不能拿三例去排名整個框架。

直接搜尋也要與自主行為分開記

接著加上獨立的搜尋診斷：每案固定跑原問題與短關鍵詞，共六次 MemoryCore.searchMemory。短詞是 meeting time、飲料、response language，沒有把正確答案藏進查詢。

結果五次只回舊紀錄，response language 的短詞查詢回空。這六次是探針強制呼叫，不是模型自己決定搜尋；即使它們找到了新值，也不能倒算成前面助理答對。

這讓問題範圍縮小：不只是「模型沒有按搜尋按鈕」，這套設定下的搜尋結果本身也沒有把修正帶回來。仍不能只憑結果就認定是哪一個排序或篩選步驟有錯，必須再拆解。

一次不能算數的對照實驗

我試著把 algorithm.retrieval.llmFilterEnabled 設為 false，在新的資料庫副本重跑三例。結果仍是舊答案。

如果在這裡停下，很容易寫成「關掉 LLM 篩選也沒用」。但那會是錯誤結論。讀回上游 core/pipeline/deps.ts 第 166 行，lightweight 模式會強制把這個篩選設為 true。再用執行時探針核對，得到：

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

因此這不是有效的開／關對照，只是設定覆蓋的重現。紀錄保留，但排除於篩選效果的比較。沒有改上游原始碼硬把它關掉，也沒有把輕量模式整個換掉後假裝只改一個變數。

今天真正學到的

今天補的是測試工具與失敗定位，還不是主記憶模組的產品修復。能提供工具、模型選擇哪個工具、工具帶回哪些記憶，以及模型最後回答什麼，四段都需要留下證據。

另一個教訓是設定檔寫了什麼，未必等於執行時用了什麼。無效對照如果沒有查出來，文章會很順，選型結論卻會走錯方向。

目前仍沒有採用或淘汰 MemOS 的決定，也沒有全面重寫 Spectyn。原始程式與輸出保存在隔離工作樹的 oss-expanded/round3；它們是本機實驗證據，尚未成為產品 CI。

明天

PocketPal 安裝驗證完成後，依序做模型載入、一般生成、離線生成、同對話修正與新對話召回。桌面則繼續追蹤召回候選如何被保留或排除，並加入 Spectyn 現有路徑的同案例基準。沒有量到的延遲、記憶體與成功率不先填數字。

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