系列:「從單一 agent 到多 agent 集群,再到接進我的生活」;不設天數,第 13 篇

這篇接續 Day 12 的交付,把「手機也能成為工作節點」拆成可驗收的跨平台能力、任務權責、記憶邊界與下一步順序。

圖 1｜Spectyn 的手機、桌面與其他裝置如何圍繞共同核心協作。

前言

今天在重新檢查 Spectyn 的狀態時，我發現需要先改一件比功能更上游的事：我們口中的「跨平台」，究竟承諾了什麼？

我想要的產物很具體：Windows、macOS、Linux、Android、iOS 各有一個 Spectyn App。對話、任務、記憶、生活記錄、工作工具與裝置管理，都從這個 App 進入。需要其他 AI 時，它能調用可用的 AI App、CLI 或服務。

但只寫「各平台都有 App」仍然不夠。假如桌面一關機，手機就只剩一個連線失敗的畫面，那手機端距離我想天天用的私人 AI 還很遠。

先把「手機能做什麼」寫清楚

這次調整的核心是：手機自己也能工作。

只有一支手機時，仍要能保存記錄、管理自己的資料、搜尋記憶；配置可用的 AI 後，可以發起並處理任務。連上其他裝置後，手機可以請桌面做重工作，桌面也可以把合適的工作交給手機，其他手機之間同樣可以合作。

這不表示每台裝置都能執行相同的命令。我們需要的是共同的使用流程，以及誠實的能力說明：這項工作可在本機做、需要另一台裝置、需要保持前景，還是目前不支援。手機不依賴另一台 Spectyn 裝置，也不代表所有 AI 模型都能離線執行。

Mermaid 圖中的雙向箭頭是一項待驗收承諾。只有把箭頭畫出來，還不能說網路斷線、重連、取消與資料同步都做完了。

圖 2｜能力矩陣把本機處理、派工、重連與資料保存拆成可驗收項目。

一個 App 背後，也要有清楚的權責

盤點目前程式時，我們看到三條需要釐清的執行入口：spectyn serve、舊的 spectyn-mesh daemon，以及 Tauri 程序內的 runtime。它們涉及不同 caller、session 與資料位置。把畫面放進同一個視窗，並不會自動解決這些差異。

所以「共用一個後端」在新計劃裡，指共用核心實作與契約。桌面可以由 App 管理執行程序，手機則驗證能嵌入哪些核心能力。每台裝置仍可擁有自己的資料與工作能力，每個任務也必須知道由誰負責執行。

例如手機派出任務後斷線，重新連上時不能直接重跑，因為對方可能已經完成了寫檔。同樣地，按下停止之後，要分清楚「已送出取消要求」與「執行端已確認停止」。這些都被列入後續契約，今天尚未取得實作驗收證據。

flowchart LR
  Phone[手機 App：本機工作與資料] <-->|配對與授權後派工| Desktop[桌面 App：本機工作與資料]
  Phone <-->|雙向工作| Other[其他 Spectyn 裝置]
  Desktop <-->|雙向工作| Other
  Phone -->|授權的必要上下文| AI[可用的 AI App／CLI／服務]
  Desktop -->|授權的必要上下文| AI

圖 3｜任務從提出、授權到執行、保存與回報的責任邊界。

把大目標換成可以驗收的順序

我把執行順序收回同一份計劃，避免文章題目表又變成另一套 roadmap。

第一步是可信基線與契約：保留既有修復，處理資料遺失、session 隔離、刪除邊界及停止結果傳遞，列清目前每條呼叫路徑。接著先讓 Mac 與 iPhone 各自跑完「輸入、AI 處理、保存、重啟、召回」，再驗證兩個派工方向。

之後補跨工具與裝置的記憶治理，讓其餘平台通過相同的核心流程。生活與工作的實際使用從前期就開始記錄，最後以連續使用的證據驗收。這樣手機從第一組交付就參與，不會一直排在「桌面全部完成之後」。

圖 4｜從可信基線到持續使用，五個階段共同構成驗收路線。

記憶同步也需要邊界。配對不代表把所有資料、金鑰與憑證複製給對方；授權某個裝置工作，也不代表它可以把整份記憶送往外部 AI。哪些資料能離開裝置，必須跟著任務一路傳遞。外部服務收到明文的流程，不能因為本地資料有加密就宣稱是零知識。

今天真的改了什麼

今天完成的是目標與計劃文件調整。BIG-GOAL 加上有日期的正式修訂，原有「私人 AI、天天用、越用越有累積」的目的保留。執行計劃、交接文件與文件索引同步更新，舊排程保留歷史註記。

另一個具體發現是手機殼文件過時了：文件還說 AppTemplate 是使用中的入口，但目前 App.tsx 已經走 MobileApp／MobileShell。我修正了這個說法，也提醒自己：元件存在、路由存在、真機流程可用，是三種不同的證據。

獨立審查又抓到另一個漏網之魚：舊治理規則列了 Linux CLI，卻沒列 Linux App。若只更新大目標而漏掉驗收規則，之後仍可能拿 CLI 測試通過來宣稱五平台完成。因此我們連同文件治理的對應條文一起修正，要求五個 App 平台各自提供流程、驗收條件與測試。

讀者可以在自己的 checkout 做同樣的唯讀核對；結果依版本而異：

git rev-parse --short HEAD
rg -n 'MobileApp|MobileShell|AppTemplate' app/src/App.tsx
git diff --stat
git diff --check

圖 5｜把文件變更、目前主張與可重跑證據放在同一張檢查圖。

這幾行能幫忙確認受查版本、畫面入口與文件變更，不能證明手機已獨立完成任務。下一個工作包會先交付執行與資料契約、保留 caller 的遷移清單，再依計劃接線驗收。

這次最值得記下的教訓是：一句「手機也要接近桌面」，會改變安裝方式、任務權責、記憶位置與驗收順序。先把這些改動寫清楚，後面的每一次實作，才知道自己要補哪一段。