紀錄留在本地，AI 請求去了哪裡？
作者 Clifford · 產品研究
本文由 Memex 團隊撰寫。Memex 用戶端原始碼和 Ollama 文件已於 2026 年 10 月 19 日核對。這是基於原始碼的解釋，未進行封包擷取、伺服器稽核或特定商店版本驗證。
假設你在晚餐後記下一段話，附上一張收據照片。Memex 的紀錄庫保存在本地工作區。啟用的工作流程請模型整理這頓晚餐時，應用程式還會向設定的端點提交請求。
請求裡的內容可能比這一條紀錄更多。之前的對話、記住的偏好、工具讀到的其他紀錄，都可能影響傳送內容。追蹤這些新增材料，比只問日記是「本地」還是「雲端」更有用。
先看路徑，再看模型名稱
本次檢查的 Memex 用戶端透過模型設定選擇用戶端類型、模型，以及相應類型支援的基礎端點網址。不同 Agent 可以解析各自的模型設定，或使用預設設定。一個熟悉的模型名稱，不能說明從手機到推論之間涉及的所有機構。
下面畫的是模型請求路徑，並非應用程式或作業系統全部連線的清單。也要核對啟用的工作流程何時開始呼叫模型：記錄輸入與 AI 處理可能屬於同一次交流。回應沿設定的服務連線返回，但紀錄庫與請求各有自己的生命週期。
直接連接供應商
- 手機應用程式
- 所選供應商 API
供應商收到組裝後的請求。這假定設定的端點確實屬於該供應商，且沒有額外模型閘道。
模型服務或閘道
- 手機應用程式
- 設定的模型服務
- 若有轉發：上游模型
服務端點收到請求。下游提供方及處理方式，需要另查該服務的說明。
另一台裝置上的模型
- 手機應用程式
- 你的電腦端點
- 按設定進行本地推論
資料離開手機。應核對電腦確實在本地執行模型，而非把請求轉給雲端模型。
供應商收到的內容，可能多於你剛輸入的文字
模型接收的是應用程式組裝的請求。裡面可能包含指令、對話歷史、相關紀錄、附件和先前工具回傳的結果。在 Memex 的 SuperAgent 原始碼中，使用者記憶會作為脈絡加入 Agent 狀態，Agent 也具備回查紀錄和讀取檔案的工具。
這不等於每次都上傳整個紀錄庫。它意味著「我只選了一條紀錄」描述的是你的動作，不能證明整次執行被強制限制在這條紀錄內。模型選擇工具之前，就可能已經有記憶脈絡；之後的工具結果還會增加材料。實際請求取決於這次執行的狀態與操作。
| 材料 | 如何進入工作流程 | 核對什麼 |
|---|---|---|
| 目前紀錄 | 作為任務文字加入。 | 準備傳送的原話，以及其中的人名、日期。 |
| 記憶與歷史 | 作為補充脈絡或先前對話加入。 | 新訊息不一定意味著空白脈絡。 |
| 照片或音訊 | 作為所選模型路徑支援的媒體附件加入。 | 遠端處理的是媒體位元組、提取的文字，還是兩者。 |
| 工具結果 | 來自檢索紀錄或上一步的輸出。 | 後續請求可能含有首次請求中沒有的資訊。 |
直接連線與模型服務，是兩種選擇
直接連線時，請求發往該用戶端設定的供應商端點。如果改用相容閘道，即使模型名稱沒變，接收方也變成了閘道。自備 API key 不能證明正在使用哪條路徑，還需要查看實際生效的端點網址。
Memex 也有可選的 Memex AI 服務設定。用戶端從帳號服務取得端點網址和憑證，再據此儲存模型設定。因此，接收請求的模型服務端點也屬於處理邊界。僅憑用戶端程式碼，無法證明它的上游路由、提示詞保留時間或訓練政策。
不要把它與設定中的可選網路代理欄位混為一談。傳輸代理和應用層模型閘道承擔不同角色。只看到「代理」二字，不能判斷中間方是否能看到解密後的提示詞。
Ollama 網址不能證明推論只在手機上完成
手機連接筆電上的 Ollama 時，是筆電收到請求。只有服務實際執行所選本地模型時，推論才在筆電上進行，而日記可以留在手機。端點必須能被手機存取；手機上的 localhost 指向手機本身，不是身旁那台電腦。
Ollama 文件同時介紹了本地和雲端模型，包括透過本地服務使用雲端模型。在把路徑稱為本地推論之前，應核對實際模型及伺服器設定。文件也提供了關閉雲端功能的方法。下載模型檔案又是另一項網路操作，與傳送日記內容做推論不同。
本地轉寫之後，文字仍可能傳往遠端
語音很適合說明這個問題，因為同一段錄音可以經過不同步驟。核對的 Memex 實作有本地語音辨識和雲端轉寫兩條路徑。本地路徑使用下載到裝置的模型；雲端路徑會編碼音訊，連同轉寫指令一起提交給聊天 Agent 所設定的模型。
如果辨識在裝置上完成，這個轉寫步驟不需要把錄音傳給雲端模型。但轉寫文字之後仍可能交給使用遠端模型的 Agent。要分別核對轉寫和後續分析。選了一個純文字模型，也不等於所有媒體功能都能正常使用。
工具、日誌與備份也各有去向
讀取本地紀錄，與把該紀錄傳回模型，是兩個操作。如果啟用的工作流程帶有遠端工具，工具輸入就多了一個接收方；更換主要模型，不會自動改變工具的目的網址。應檢查實際工具，不能假定所有工作都走聊天端點。
核對的原始碼還會寫入本地診斷日誌，也能把工作區資料、資料庫和設定打包進備份。備份的範圍比匯出一條紀錄更大。診斷包和備份檔都應視為可能包含敏感內容，在分享或存入其他服務之前檢查其中的內容。
供應商處理、內容保留與用於訓練，是分別需要回答的問題。本次檢查的原始碼不能替其他營運方證明伺服器端做法。刪除一條本地紀錄，也不會自動撤回已經傳送的請求、清除備份，或一定移除記憶脈絡。每份副本都需要自己的生命週期與刪除機制。
先用虛構紀錄追蹤一次
使用虛構內容，例如「週二在範例咖啡館吃了晚餐」，不要附真實收據。記下要使用的功能、負責工作的一個或多個 Agent、實際模型連線、端點營運方及中間服務，再列出可能的承載內容：文字、歷史、記憶、媒體和工具結果。
如果包含語音，另外核對轉寫設定。如果希望本地推論，要確認接收請求的主機和它執行的模型。新開一段對話可以簡化檢查，但不能據此證明沒有記憶與檢索。
這份筆記也應允許留下未知項：服務目前的保留條款、尚未辨識的下游提供方，或尚未檢查的附件路徑。它是路徑清單，不是封包擷取。要確定完整承載內容，需要在受控條件下檢查請求組裝或流量，只用虛構資料並保護憑證。本文未執行這樣的裝置端追蹤。
測試用的請求路徑筆記
功能與負責的 Agent：
實際模型與端點營運方：
模型閘道或網路代理（如有）：
包含的文字／歷史／記憶／媒體：
本地還是雲端轉寫：
其他工具的目的網址：
產生的備份或日誌：
尚未核實的項目：留下紀錄，選擇要交給 AI 的工作
開源讓你能檢查請求如何組裝；可選模型讓你能選擇處理連線。實際價值是路徑可以被檢查和調整。這兩個標籤，都不能取代核對目前生效的設定和即將使用的功能。嘗試另一個設定好的端點，不需要把原始紀錄庫搬到該服務。
即使今天不再分析，晚餐紀錄也仍有儲存價值。以後，一個小問題也許值得把一些脈絡交給信任的模型。把儲存紀錄與展開分析分別考慮，才能同時容納個人紀錄庫和有用的 AI。