手機端與伺服器端 Agent：技術、體驗與未來
作者 Clifford · 產品研究
本文由 Memex 團隊撰寫。平台文件與 Memex 原始碼核對於 2026 年 10 月 17 日。這是架構討論，未進行耗電、速度或背景可靠性的對照測試。文中的混合架構構想不是 Memex 已發布的功能。
散步後，你錄下一句話：「春天可以去京都，但我不想再過一次行程排得滿滿的假期。」此刻，你只是想留下這個念頭，或把它和之前的紀錄連起來。幾個月後，你才可能需要 Agent 查日期、找旅行方案。紀錄的價值，比任務出現得更早。
這兩種交流可以發生在同一個聊天視窗裡。一種貼近你正在經歷的生活，另一種可能需要在你放下手機後繼續。Agent 在哪裡執行，會改變這段時間裡能發生什麼，也會改變工作停下時，應用程式需要向你交代什麼。
三個位置，三項獨立的決定
Agent 的協調程式讀取輸入、詢問模型、呼叫工具，再儲存結果。協調程式可以在手機應用程式裡執行，同時向模型供應商請求推論。紀錄儲存又是第三個位置：日記留在手機上，並不能說明模型在哪裡執行。工具操作也有自己的執行邊界：手機上的協調程式既可以修改本地檔案，也可以呼叫遠端行事曆 API。
「本地模型」也需要說明是哪台裝置上的本地。如果筆電上的 Ollama 服務實際執行所選本地模型，推論才發生在筆電上；手機連上該端點本身，既不能證明推論在手機內完成，也不能排除雲端轉發。下面比較的是協調程式及其工具的執行位置，不假定三層必須一起移動。
| 設計決定 | 手機端協調程式 | 伺服器端協調程式 |
|---|---|---|
| Agent 迴圈 | 在應用程式的執行環境中運作。 | 在遠端工作程式或服務中運作。 |
| 紀錄 | 可以使用應用程式的本地紀錄庫。 | 需要授權存取相關紀錄，或接收提供的副本。 |
| 模型推論 | 可以使用裝置端模型或遠端端點。 | 可以使用主機上的模型或獨立端點。 |
| 手機應用程式關閉後 | 取決於系統執行時間與恢復機制。 | 如果主機與任務系統可用，可以獨立繼續。 |
| 工具與權限 | 受應用程式權限和作業系統約束。 | 受主機工具、憑證及明確的裝置連線約束。 |
背景執行需要遵守平台的規則
在 iOS 上，應用程式不能把任意迴圈變成永久服務，背景執行時間由系統管理。iOS 和 iPadOS 26 增加了 BGContinuedProcessingTask，讓使用者明確發起的工作在進入背景後繼續，配有可見進度、取消和到期處理機制。它擴大了應用程式能完成的工作範圍，卻沒有賦予任意無人值守任務隨時啟動的權利。
Android 區分一般非同步工作、持久任務和前景服務。WorkManager 用於持久任務，前景服務則有可見性和啟動限制。一些服務類型還有隨系統版本、目標版本而變化的時間額度。只把函式寫成 async，並不會取得這些執行權限。
伺服器讓協調程式不再直接受手機應用程式生命週期支配。但它仍需要可用的主機、排程器或佇列、有效憑證、故障處理和監控。代管雲端服務與家中持續開機的電腦都可以承擔這個角色，只是維運責任不同。
任務被儲存，不等於操作能精確接續
假設一個工具建立了行事曆事項。事項已經建立成功，回應卻在 Agent 記下成功之前遺失了。重試工具，可能再建立一個相同事項。把協調程式搬到伺服器，並不會消除這種不確定性。
可靠恢復既需要持久任務狀態，也需要處理狀態之外的實際操作。如果目標 API 支援，穩定的操作識別碼能讓它辨識同一次請求的重試；否則，Agent 可能需要先核實究竟發生了什麼，再決定是否操作。AWS 關於冪等 API 的文章解釋了呼叫方提供請求識別碼的重要性。
佇列可以記住一個任務尚未完成，但處理這個任務的程式仍可能從頭執行。若要從每次模型呼叫或工具步驟繼續，就需要額外狀態和針對工具的保證。「中斷後能恢復」，不能悄悄變成「每個操作都只發生一次」。
技術差異會出現在螢幕上
做一次簡短回顧時，手機端協調程式可以讀取選取的本地紀錄，趁你還記得當時的想法繼續追問。它也不能自動查看其他所有應用程式，存取仍受權限和可用介面約束。如果最新紀錄從未同步，伺服器 Agent 就需要一個明確的管道才能取得同樣的脈絡。伺服器可以配備瀏覽器和命令列工具，但這些工具不會賦予它存取手機獨有內容的權限。
等到後來真的要研究旅行方案，遠端執行可以支援「做好後我再回來」。結果可以等手機重新連線後再送達。但應用程式仍應給出有意義的狀態：正在調查、等待網路、已暫停、失敗，或需要你回答。執行已經停止，螢幕上的載入圖示卻還在轉，會把任務最重要的事實藏起來。
協調程式在本地，並不保證回答更快。如果兩種方案呼叫同一個遠端模型，推論與網路延遲可能占據大部分等待。裝置端推論則把計算移到手機，受到具體裝置的記憶體、能耗和散熱限制。同樣，離線儲存紀錄與離線完成一個依賴遠端模型的流程，是兩種能力。
隱私與成本取決於工作走過的路徑
手機端協調程式可以選取少量相關段落，而不必先把整個紀錄庫複製到執行伺服器。但這些段落仍可能隨著模型請求離開裝置。伺服器也可以採用嚴格的權限範圍和有限保留時間。評估兩種設計，都應該追蹤紀錄、提示詞、工具輸出、日誌和備份的去向，而不只看迴圈跑在哪台機器上。
模型選擇是另一項決定。選擇端點，就是選擇一種處理邊界，並不意味著每個供應商都私密或支援離線。增加工作伺服器可能帶來計算和維護成本；手機執行消耗裝置資源，也仍可能產生 API 費用。沒有明確工作負載與實測資料，無法給出普遍成立的「更便宜」或「更有效率」。
Memex 原始碼能支持哪些判斷
本次查看的原始碼版本中，Memex 有持久的本地任務佇列，包含任務狀態、執行所有權、停滯任務恢復和可設定重試。背景協調程式把任務活動與應用程式生命週期連接起來。Android 有透過 WorkManager 處理佇列的路徑；iOS 橋接層包含背景處理任務，以及帶進度和到期處理的 iOS 26 繼續處理路徑。
背景工作程式也會記錄暫停狀態，並可安排再次嘗試。這些機制用來管理中斷，不能證明程式始終執行、每個內部步驟都精確接續，或所有外部操作都不會重複。原始碼檢查不等於安裝到裝置後的測試，具體發行版本是否支援，也需要另外核對。
開源讓這些邊界可以被檢查，也給開發者留下修改空間。Memex 的起點是個人紀錄，以及貼近這些紀錄的可設定工作流程。偶爾出現的個人需求，不必全部變成一個永久執行的伺服器任務。
一種未來協作方式：交出任務，留下歷史
未來的設計可以把原始紀錄留在手機，把範圍明確的調查交給另一台主機。以旅行請求為例，手機可以傳送選定的日期、預算和相關偏好，伺服器回傳附有來源的候選方案，而不需要長期儲存每一篇日記。
交接需要任務識別碼、輸入快照、允許的工具、費用上限，以及下一步由誰負責。假設任務執行期間，你把「安靜的旅行」改成了「和朋友一起旅行」，回傳的清單應該說明它使用的是之前的偏好，並讓你決定是否修改，而不是默默覆蓋新的計畫。
取消也要區分停止後續調查與撤銷已經發生的操作。回傳的草稿可以審閱；真正預訂則需要獨立的批准邊界和辨識重複請求的方式。這些是設計構想，不是 Memex 已發布的手機到伺服器委派功能。更好的裝置端模型不會取消系統生命週期規則，更多伺服器算力也不會自動補齊缺失的個人脈絡。
先想想，你希望留下什麼
一段語音紀錄，即使沒有後續長任務，也應該值得儲存。對許多日常時刻，有用的交流就是記錄、一小段對話，以及以後還能回看的內容。讓這條路徑貼近手機，符合這些材料本來抵達的方式。
散步幾個月後，旅行調查需要的起點已經在那裡：你當時希望什麼，用自己的話寫下，帶著日期和後來的修改。執行時間更長的工作程式可以接手偶爾的調查，而日常紀錄給了它值得據以工作的材料。