# 可攜式 AI 主腦：手機、眼鏡、機器人與電腦的跨身體智能 **系列：狀態驅動的本地具身 AI｜第 8 篇** **版本：v1.0** **日期：2026-08-01** --- ## 摘要 如果個人 AI 的記憶、任務、世界狀態與模型 Runtime 不再固定存在於某一台機器人中，那麼「具身」便不必等同於「只有一個永久身體」。手機可以保存個人世界狀態與權限，智慧眼鏡提供第一人稱視覺與即時顯示，耳機提供語音通道，桌面電腦提供高算力，家庭機器人提供移動與物理行動能力。此時真正持續存在的不是某一個裝置，而是一個跨設備的 Agent Runtime。 2026 年的公開平台已經出現這種方向的若干基礎元件。Android Cross device SDK 正在開發裝置探索、授權、安全連線與多裝置工作階段；其 Sessions API 已把「把一個使用體驗從一台裝置轉移或共享到另一台裝置」作為正式抽象。Android XR 的 Jetpack Projected 更直接採取「AI 眼鏡上的應用實際運行於 Android 手機等 companion host，再把 XR 體驗投射到眼鏡」的設計。這是一個非常具體的例子：**感知／顯示身體與主要計算宿主可以物理分離。** 然而，跨設備 Agent 遠未解決。2026 年 DevicesWorld 基準把手機、桌面與 IoT 組合為 6,140 個可執行跨設備任務；其報告的五種前沿 Agent 中，最好完整成功率仍只有 12.5%。常見錯誤包括混淆資訊來源與輸出裝置、無法完成跨設備依賴、提早終止。這說明「在每台裝置都會操作」不等於「能維持一個跨裝置的一致世界狀態」。 本文因此提出「跨身體智能（Cross-Embodiment Intelligence）」的 Runtime 定義：Agent 的持續核心由身份描述、世界狀態、長期記憶、任務、權限與模型路由構成；不同裝置只是帶有不同感知器、執行器、算力與安全邊界的 embodiment endpoints。Agent 在裝置之間不是複製整個 Prompt，而是傳遞受版本控制、受權限約束的 session state 與 task state。 最終架構為： $$ \boxed{ \text{Personal State Anchor} \leftrightarrow \text{Embodiment Mesh} = \{ \text{Phone}, \text{Glasses}, \text{Robot}, \text{PC}, \text{Car}, \text{Home} \} } $$ 手機因此可以成為「可攜式主腦」的自然候選，但不是唯一可能宿主。真正的主腦不是一塊晶片，而是能在裝置變動時維持操作連續性的狀態、記憶、權限與路由 Runtime。 **關鍵詞：** 跨設備 Agent、跨身體智能、可攜式 AI 主腦、Android Cross device SDK、Android XR、世界狀態、Agent Runtime、記憶連續性、裝置網格、具身智能 --- # 1. 最後一篇真正要回答的問題 第一篇從二白出發時，我們問： > 為什麼一台硬體並不誇張的迷你機器人，仍然可能讓人感覺「它有智能」？ 一路走到第七篇後，問題已經完全改變。 現在我們擁有： - 持續世界狀態； - 雙時間尺度反應； - FSM／BT／LLM 分層； - 事件驅動； - 多模型路由； - 本地與外部主腦； - 手機級本地模型 Runtime。 於是最後剩下一個問題： > **如果 AI 的狀態與記憶不必固定在機器人體內，那 AI 的「身體」還必須是一台裝置嗎？** 本文的答案是： $$ \boxed{ \text{不必。} } $$ 至少在工程意義上，可以把 Agent 與 embodiment 分開。 --- # 2. 先拆開「Agent」與「Device」 傳統機器人很容易被寫成： $$ \text{Robot} = \text{Body} + \text{Controller} + \text{Intelligence}. $$ 三者被封裝在同一物理物件中。 但當本地網路、手機、眼鏡、電腦與雲端都可以參與運算時，更合理的寫法是： $$ \mathcal A_t = ( I, S_t, K_t, G_t, \Pi_t, \mathcal M_t ), $$ 其中： - $I$ ：Agent identity descriptor； - $S_t$ ：目前世界與任務狀態； - $K_t$ ：長期記憶； - $G_t$ ：目標與任務； - $\Pi_t$ ：權限、政策與執行邊界； - $\mathcal M_t$ ：可用模型與路由策略。 而裝置集合是： $$ D= \{ d_{\mathrm{phone}}, d_{\mathrm{glasses}}, d_{\mathrm{robot}}, d_{\mathrm{pc}}, d_{\mathrm{car}}, d_{\mathrm{home}} \}. $$ 每台裝置只提供部分能力： $$ C(d_i) = ( \text{sensors}, \text{actuators}, \text{compute}, \text{network}, \text{permissions} ). $$ 因此： $$ \boxed{ \text{Agent} \neq \text{Device}. } $$ 裝置是 Agent 可以取得的感知、計算與行動端點。 --- # 3. 「跨身體」不是把同一個模型複製很多份 最簡單但錯誤的想法是： ```text Phone：一份 AI Glasses：一份 AI Robot：一份 AI PC：一份 AI ``` 每個裝置都各自保存完整聊天紀錄與 Prompt。 這會很快產生： - 記憶分叉； - 任務重複； - 不同模型互相不知道對方做了什麼； - 權限不一致； - 世界狀態衝突。 因此跨身體不能只是： $$ \text{Model Replication}. $$ 更合理的是： $$ \boxed{ \text{Shared Agent State} + \text{Device-Specific Runtime}. } $$ 也就是同一個 Agent Runtime 對不同裝置投影出不同 view： $$ V_t^{(d)} = \phi_d( S_t, G_t, \Pi_t, C(d) ). $$ 眼鏡看到的是第一人稱視覺與導航。 機器人看到的是局部地圖與運動任務。 電腦看到的是文件與開發工作區。 手機則維持較完整的個人狀態錨點。 --- # 4. 2026 年其實已經出現「主機與身體分離」的商業平台範例 Android XR 的 Jetpack Projected 提供了一個非常直接的案例。 Google 官方開發文件明確說明： > 對 audio glasses 與 display glasses 開發時，App 可以實際運行在 Android phone 等 companion host device，再由 host 將 XR 體驗投射到眼鏡。 也就是： $$ \text{Application Runtime} \in \text{Phone}, $$ 而： $$ \text{Camera / Display / Audio Endpoint} \in \text{Glasses}. $$ 眼鏡可以提供： - 相機； - 顯示； - 音訊； - 使用者輸入； 但主要應用邏輯與算力不必全部在鏡框裡。 這正是： $$ \boxed{ \text{Compute Host} \neq \text{Embodiment Endpoint}. } $$ 對 AI 具身架構而言，這是一個非常重要的現實先例。 --- # 5. 手機為什麼特別適合做 Personal State Anchor？ 不是因為手機一定擁有最強算力。 而是因為手機通常： - 一直跟著使用者； - 已有使用者身份驗證； - 有 secure enclave／TEE 類安全能力； - 有 5G、Wi-Fi、Bluetooth、UWB； - 有 GPS； - 有相機與麥克風； - 有 App 生態； - 有行事曆、通知、聯絡人； - 有電池； - 能在不同地點繼續存在。 因此手機可以成為： $$ d_{\mathrm{anchor}}. $$ 其主要責任不是： > 所有 token 都必須在手機算。 而是： $$ \boxed{ \text{維持個人 Agent 的狀態、憑證、權限與路由中心。} } $$ 算力可以外包。 狀態錨點未必需要外包。 --- # 6. Cross device SDK 顯示「工作階段轉移」正在變成 OS 級抽象 Android Cross device SDK 目前仍是 Developer Preview，不能直接當作成熟量產基礎，而且現階段一次只支援兩台裝置互動。 但它提供的抽象很值得注意： - Device Discovery； - Authorization； - Secure Connections； - Multidevice Sessions。 其 Sessions API 直接定義： $$ \text{Session Transfer} $$ 與： $$ \text{Session Share}. $$ 也就是應用體驗可以： - 從裝置 A 轉移到 B； - 或在多裝置間共享。 本文真正關心的是把： $$ \text{Application Session} $$ 進一步提升成： $$ \boxed{ \text{Agent Session}. } $$ 不只畫面轉移，而是： - 任務； - 工作記憶； - 世界狀態； - 權限； - 工具控制權； 一起安全交接。 --- # 7. Agent Handoff 應該傳什麼？ 假設 AI 正在手機上幫使用者規劃行程，使用者戴上眼鏡後，希望 AI 繼續導航。 最差的方法： > 把完整聊天歷史重新送給眼鏡裡另一個模型。 更好的方法是建立 handoff package： $$ H_{i\rightarrow j} = ( S_t^{\mathrm{session}}, G_t, W_t, \Pi_t, V_t ), $$ 其中： - $S_t^{\mathrm{session}}$ ：此工作階段需要的世界狀態； - $G_t$ ：當前目標； - $W_t$ ：working memory； - $\Pi_t$ ：允許移交的權限； - $V_t$ ：state version / provenance。 例如： ```text task = walking_navigation destination = Taipei Main Station route_step = 7 user_mode = walking phone_location = ... glasses_display = available camera_permission = granted payment_permission = denied state_version = 1842 ``` 眼鏡不需要知道使用者十年前全部聊天歷史。 它只需要目前任務成立所需的最小狀態。 --- # 8. Operational Continuity：工程上的「同一個 Agent」如何判定？ 本文不處理 AI 是否具有某種形而上人格本體。 工程上更實用的問題是： > 兩次裝置切換後，系統是否仍具有操作連續性？ 可以定義一組連續性不變量： $$ \mathcal I= \{ I, G, K_{\mathrm{relevant}}, \Pi, V \}. $$ 如果 handoff 前後： $$ \mathcal I_{t^-} \simeq \mathcal I_{t^+}, $$ 並且任務因果鏈沒有被破壞，就可以稱為： $$ \boxed{ \text{Operational Agent Continuity}. } $$ 這比說「模型權重相同」更合理。 因為模型本身甚至可以改變： $$ M_A \rightarrow M_B, $$ 但如果： - 任務沒丟； - 狀態沒丟； - 記憶可取回； - 權限沒有非法膨脹； - handoff 可追溯； 使用者仍然會感受到同一個工作流程持續存在。 --- # 9. 模型可替換，狀態才是連續性的主要載體 假設： 早上手機使用： $$ M_1=7B. $$ 回到家後工作站接手： $$ M_2=70B. $$ 出門後眼鏡端改用： $$ M_3=\text{small multimodal model}. $$ 若把 Agent 定義成模型： $$ M_1\neq M_2\neq M_3, $$ 好像每天都換了一個 Agent。 但如果真正持續的是： $$ S_t, K_t, G_t, \Pi_t, $$ 則模型只是： $$ \boxed{ \text{可替換的認知執行器}. } $$ 這是本系列一路推導出來的重要結論。 --- # 10. 但不是所有狀態都應該同步到所有身體 如果手機裡保存： - 私人郵件； - 密碼； - 醫療資料； - 完整人物記憶； - 公司文件； 並不代表家中一台簡單陪伴機器人應該取得全部資料。 因此每個裝置應得到： $$ S_t^{(d)} = \operatorname{Project} ( S_t, \Pi(d) ). $$ 其中： $$ \Pi(d) $$ 是裝置能力與權限範圍。 例如眼鏡可能取得： - 導航； - 目前人物； - 相機分析； - 當前會議。 但不取得： - 完整財務資料庫； - 管理員憑證。 所以跨身體的核心不是： $$ \text{Sync Everything}. $$ 而是： $$ \boxed{ \text{Scoped State Projection}. } $$ --- # 11. Capability-Based Authority 比「登入同一帳號」更重要 如果所有裝置只因登入同一帳號就取得同等權力，風險很高。 更合理的是 capability： $$ cap= ( \text{subject}, \text{resource}, \text{action}, \text{scope}, \text{expiry} ). $$ 例如： ```text robot_01: resource = living_room_lights action = on/off expiry = session_end ``` 而不是： ```text robot_01: full_account_access = true ``` 不同 embodiment 應有不同 authority。 因此： $$ \boxed{ \text{Shared Intelligence} \neq \text{Shared Unlimited Privilege}. } $$ --- # 12. 多身體同時在線時，Agent 不再只是 handoff，而是 coordination 如果手機、眼鏡與機器人同時在線： $$ |\eta_t(\mathcal A)|>1, $$ 則 AI 同時有多個 embodiment endpoint。 例如： - 眼鏡看見桌上的杯子； - 機器人在客廳； - 手機知道使用者的位置； - PC 正在執行文件工作。 此時應共享： $$ S_t^{\mathrm{global}}, $$ 但每個裝置只維持： $$ S_t^{(d)}. $$ 可以寫成： $$ S_t^{\mathrm{global}} = \operatorname{Fuse} ( S_t^{(1)}, S_t^{(2)}, \ldots, S_t^{(n)} ). $$ 這已經不是「一個 AI 換身體」。 而是： $$ \boxed{ \text{One Runtime, Multiple Concurrent Embodiments}. } $$ --- # 13. 這正是跨設備 Agent 目前真正困難的地方 2026 年提出的 DevicesWorld 把： - mobile； - desktop； - IoT； 整合成可執行 benchmark，共有： $$ 6140 $$ 個跨設備任務。 研究評估五種前沿 LLM Agent，在固定測試集上： $$ \text{best full success rate}=12.5\%. $$ 很多 Agent 並不是完全什麼都做不到。 約 28.7% 的失敗 trajectory 至少滿足一個 scoring condition，但仍然沒有完成完整跨設備目標。 常見問題包括： - 資訊讀到了，但送錯裝置； - 操作了手機，忘記桌面後續； - 混淆 source device 與 target device； - 還沒完成全部條件就宣布結束。 這個結果非常重要。 它說明： $$ \boxed{ \text{Single-device competence} \not\Rightarrow \text{Cross-device coherence}. } $$ 真正缺少的是跨設備狀態與任務依賴管理。 --- # 14. 所以 Cross-Device Agent 必須有 Global Task Graph 假設任務： > 找到手機裡昨天收到的地址，在電腦上整理成文件，再把結果顯示到眼鏡。 不能只是一條文字 Chain-of-Thought。 應該有： $$ G= (V,E), $$ 其中節點： ```text v1 = read_phone_message v2 = extract_address v3 = create_pc_document v4 = verify_file v5 = display_on_glasses ``` 邊： $$ v_1\rightarrow v_2\rightarrow v_3\rightarrow v_4\rightarrow v_5. $$ 每個節點還包含： - execution device； - required state； - completion verifier； - authority； - retry policy。 這樣 Runtime 才知道： > 手機成功不代表任務成功。 而是： $$ \boxed{ \forall v_i\in V_{\mathrm{required}}, \quad \operatorname{verified}(v_i)=1. } $$ --- # 15. 世界狀態同步不能只有「最後寫入者勝」 跨設備必然遇到 conflict。 例如： - 手機認為主人在車上； - 眼鏡剛看到主人走進商店； - 車機仍保持 connected； - 家中機器人保存舊狀態。 簡單： $$ \text{last-write-wins} $$ 不一定正確。 因為來源可靠度不同。 更合理是： $$ S_{t+1} = \operatorname{Fuse} ( S_t, E_t, \text{source}, \text{confidence}, \text{timestamp} ). $$ 重要狀態甚至需要： - version vector； - causal order； - provenance； - conflict resolution。 也就是第 4 篇世界狀態機，在跨設備後變成了： $$ \boxed{ \text{Distributed World-State Runtime}. } $$ --- # 16. 不是所有資料都需要強一致性 若要求所有裝置任何時候都完全同步： $$ S_t^{(1)} = S_t^{(2)} = \cdots = S_t^{(n)}, $$ 會造成： - 高延遲； - 離線無法工作； - 大量同步成本。 因此應按狀態類型分級。 ## Strong / Near-Strong 需要高一致性的： - 支付授權； - 門鎖； - 安全狀態； - 任務所有權； - 裝置控制 lease。 ## Eventual 可以稍晚同步的： - 非關鍵記憶； - 對話摘要； - 偏好； - 歷史資料。 所以： $$ \boxed{ \text{Consistency Policy} = f(\text{consequence}). } $$ 後果越大，一致性要求越高。 --- # 17. Robot 不是 AI 的全部，但它提供 AI 最直接的物理後果 手機與眼鏡主要提供： - 感知； - 資訊； - 通訊。 機器人則提供： $$ \text{physical agency}. $$ 例如： - 移動； - 抓取； - 開門； - 搬運； - 靠近人類。 所以在跨身體系統中： $$ \Pi_{\mathrm{robot}} $$ 通常應比： $$ \Pi_{\mathrm{display}} $$ 更嚴格。 因為： $$ \text{wrong text} $$ 與： $$ \text{wrong physical action} $$ 的後果不同。 這再次回到第 3 篇： $$ \boxed{ \text{Authority is assigned by consequence, not intelligence.} } $$ --- # 18. 外部主腦與本體自治必須同時存在 如果機器人所有決策都依賴手機： $$ \text{phone disconnected} \Rightarrow \text{robot dead}, $$ 架構仍然很脆弱。 因此 embodiment endpoint 本身應保留： $$ \text{Minimum Viable Autonomy}. $$ 例如： - 安全； - 回充； - 停止； - 本地導航； - 簡單互動； - 短期 state cache。 而手機提供： $$ \text{Extended Intelligence}. $$ 所以： $$ \boxed{ \text{Shared Brain} + \text{Local Reflex Autonomy}. } $$ 這比純 thin client 更適合物理設備。 --- # 19. 眼鏡會成為非常特殊的 embodiment 手機的感知方向並不永遠等於使用者注意方向。 眼鏡則天然接近： $$ \text{first-person perception}. $$ 它知道： - 使用者正在看什麼； - 哪個物體在視野； - 視覺上下文； - 可能的注意方向。 2026 年 Google 已宣布 Android XR 智慧眼鏡路線，並展示： - 導航； - 傳簡訊； - 拍照； - 即時 Gemini 協助。 對 Personal AI 而言，眼鏡最重要的不只是顯示。 而是提供： $$ \boxed{ \text{human-centered sensory endpoint}. } $$ 手機是 state anchor。 眼鏡是 perception anchor。 機器人是 action anchor。 電腦則可能是 compute / productivity anchor。 --- # 20. 因此可以重新定義「身體」 在傳統具身 AI： $$ B=\text{one physical robot}. $$ 在本文框架： $$ B_t = \{ d_i\in D \mid \operatorname{authorized}(d_i,t)=1 \}. $$ 也就是： > 當下所有被 Agent 合法使用的感知／行動裝置集合。 所以「身體」變成動態集合： $$ B_t \neq B_{t+1}. $$ 早上可能： $$ B_t=\{\text{phone}\}. $$ 出門： $$ B_t=\{\text{phone},\text{glasses},\text{earbuds}\}. $$ 回家： $$ B_t=\{\text{phone},\text{robot},\text{PC},\text{home}\}. $$ 這就是： $$ \boxed{ \text{Dynamic Embodiment Set}. } $$ --- # 21. 但 Agent 不能因為有很多身體就假裝自己無處不在 跨設備架構仍然必須知道每個 sensor 的位置與可見範圍。 例如： ```text camera.robot_01 location = living_room ``` 與： ```text camera.glasses location = with_user ``` 不是同一視角。 因此任何 observation 都應帶： $$ E= ( \text{payload}, \text{source}, \text{location}, \text{timestamp}, \text{confidence} ). $$ 否則模型容易犯： > 「機器人看到的，就是使用者看到的。」 這種錯誤。 跨身體智能的前提反而是更嚴格地知道： > 每個「眼睛」在哪裡。 --- # 22. 記憶也應該有 provenance 當多裝置共同寫記憶時，應保存： ```text memory: content = ... observed_by = glasses_camera interpreted_by = local_vlm confirmed_by = user timestamp = ... ``` 因此： $$ K_i = ( content, source, time, confidence, scope ). $$ 這樣未來 Agent 才能區分： - 真正看見； - 模型推測； - 使用者明確告知； - 另一台機器人報告。 這對長期可信記憶非常重要。 近期也已有研究預印本開始探索 portable agent memory 與跨模型 memory transfer；這顯示「記憶不應永久鎖死在單一 Agent runtime」正在成為新的研究問題，但相關協定目前仍遠未形成公認標準。 --- # 23. 模型 Router 也必須跨設備 第 5 篇的 Router： $$ r_t = R(E_t,S_t,G_t,U_t,B_t,P_t) $$ 在這裡需要再多一個維度： $$ d_t. $$ 變成： $$ (r_t,d_t) = R( E_t, S_t, G_t, U_t, B_t, P_t, D_t ). $$ Router 不只決定： > 用哪個模型？ 還要決定： > 在哪一台裝置算？ 例如： ### 即時視覺 $$ \rightarrow \text{glasses local NPU}. $$ ### 7B 日常對話 $$ \rightarrow \text{phone}. $$ ### 70B 深度規劃 $$ \rightarrow \text{home workstation}. $$ ### 極重推理 $$ \rightarrow \text{cloud}. $$ 因此： $$ \boxed{ \text{Model Routing} + \text{Compute Placement} } $$ 會合併成同一個問題。 --- # 24. 一個完整的 Personal AI Mesh 現在可以把整個系列壓縮成一張邏輯架構： ```text ┌─────────────────────┐ │ Personal AI Anchor │ │ State / Memory / ID │ │ Authority / Router │ └──────────┬──────────┘ │ Secure Device Mesh ┌─────────────────────┼─────────────────────┐ │ │ │ ▼ ▼ ▼ Smartphone AI Glasses Robot local models perception/UI physical action │ │ │ ├──────────────┬──────┴──────────────┬─────┤ │ │ │ │ ▼ ▼ ▼ ▼ PC Home AI Server Car IoT heavy compute large models │ ▼ Cloud frontier escalation ``` 每個節點都有自己的： $$ \text{local state} + \text{local authority} + \text{local safety}. $$ 但共享： $$ \boxed{ \text{Agent State Graph}. } $$ --- # 25. 這個架構最大的失敗模式 真正做產品時至少會遇到： ### State Fork 不同裝置各自形成不同世界。 ### Duplicate Action 手機與機器人同時執行同一任務。 ### Stale Authority 一台已離線裝置仍持有舊控制權。 ### Wrong Embodiment AI 把「眼鏡看到」誤認為「機器人可操作」。 ### Memory Leak 不該共享的記憶被同步給低信任裝置。 ### Infinite Handoff 任務不停在設備間轉移，沒有任何一台真正完成。 ### Cloud Dependency Collapse 雲端斷線後所有 embodiment 同時失能。 因此跨身體 Runtime 的價值主要不是「讓 AI 到處跑」。 而是： $$ \boxed{ \text{讓它到處跑而不把狀態、權限與因果關係弄亂。} } $$ --- # 26. 2026 年我們真正在哪一步？ 目前已經存在很多零件： - 本地手機模型； - OS 級 on-device AI； - 跨設備安全連線； - session transfer； - XR projected experiences； - 家庭 IoT； - 邊緣機器人； - Agent tool calling； - 本地大型 AI PC。 但它們還沒有自然收斂成： $$ \text{one persistent personal agent runtime}. $$ 尤其 DevicesWorld 類研究顯示，跨設備任務對目前 Agent 仍然很難。 所以現在比較準確的判斷是： $$ \boxed{ \text{Infrastructure pieces exist;} \quad \text{unified agent continuity does not yet}. } $$ 真正的競爭點可能逐漸從「誰有最強聊天模型」變成： - 誰維護狀態最好； - 誰的 memory 最可攜； - 誰能安全控制最多裝置； - 誰能在 local/cloud 間平滑路由； - 誰能跨設備而不丟任務。 --- # 27. 從二白回頭看：最初的問題其實完全變了 第一篇的二白是一個小型機器人。 當時的問題是： $$ \text{有限算力} \rightarrow \text{如何產生智能感？} $$ 最後我們得到： $$ \text{Fast Reaction} + \text{State} + \text{Behavior} + \text{Sparse LLM}. $$ 再往後： $$ \text{State Machine} \rightarrow \text{World State}. $$ 接著： $$ \text{One Model} \rightarrow \text{Model Router}. $$ 然後： $$ \text{On-Robot Brain} \rightarrow \text{Distributed Compute}. $$ 再到： $$ \text{Phone} \rightarrow \text{Personal AI Runtime}. $$ 最後： $$ \boxed{ \text{One Body} \rightarrow \text{Embodiment Mesh}. } $$ 所以二白真正提供的不是一個特定產品答案。 而是一個很好的起點： > 只要把「智能」從模型本身移回整個狀態—感知—行為—時間系統，許多原本看似需要巨大模型的問題，就會變成架構問題。 --- # 28. 第一批系列的最終統一式 八篇完成後，可以把整個系列寫成： $$ \boxed{ \mathcal A = ( \mathcal S, \mathcal E, \mathcal B, \mathcal R, \mathcal M, \mathcal K, \mathcal P, \mathcal D ) } $$ 其中： - $\mathcal S$ ：Persistent World State； - $\mathcal E$ ：Event System； - $\mathcal B$ ：Behavior / Control Hierarchy； - $\mathcal R$ ：Router； - $\mathcal M$ ：Model Pool； - $\mathcal K$ ：Memory； - $\mathcal P$ ：Permission / Authority； - $\mathcal D$ ：Device / Embodiment Mesh。 其循環為： $$ E_{t+1} \rightarrow S_{t+1} \rightarrow R_t \rightarrow M_t \rightarrow B_t \rightarrow A_t \rightarrow E_{t+2}. $$ 而裝置只決定每一步在哪裡發生： $$ d_t = \operatorname{Place} ( E_t, S_t, R_t, M_t, B_t ). $$ 這就是本文所稱的： $$ \boxed{ \text{State-Driven Distributed Embodied AI}. } $$ --- # 29. 最終結論：主腦不是最大的模型，而是保持連續性的 Runtime 如果一定要從這八篇留下最核心的一句話，那不是： > 未來手機會跑多大的模型。 也不是： > 未來機器人會有多強的 NPU。 而是： $$ \boxed{ \text{真正的「主腦」， 是讓模型、裝置與身體不斷改變時， Agent 仍能保持狀態、任務、記憶與權限連續性的 Runtime。} } $$ 因此： - 模型可以睡眠； - 模型可以替換； - 裝置可以離線； - 身體可以切換； - 算力可以移動； 但： $$ S_t, \quad K_t, \quad G_t, \quad \Pi_t $$ 不能無秩序地消失或分叉。 從這個角度看，「可攜式 AI 主腦」並不是把一台超級電腦縮成手機。 它真正代表的是： > **把個人 AI 的狀態核心變成可攜、可路由、可投射到不同裝置與身體的持續 Runtime。** 而二白式迷你機器人，則只是其中一個非常自然、非常具體的 embodiment endpoint。 --- # 參考資料 1. Android Developers. *Cross device SDK*. Updated 2026-05-07. https://developer.android.com/guide/topics/connectivity/cross-device-sdk/overview 2. Android Developers. *Sessions API — Cross device SDK*. https://developer.android.com/guide/topics/connectivity/cross-device-sdk/sessions 3. Android Developers. *Develop with the Jetpack XR SDK — Jetpack Projected*. Updated 2026-05-19. https://developer.android.com/develop/xr/jetpack-xr-sdk 4. Android Developers. *XR Projected — Jetpack release notes*. Updated 2026-07-15. https://developer.android.com/jetpack/androidx/releases/xr-projected 5. Google. *Intelligent eyewear with Gemini is coming this fall*. 2026-05-19. https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/ 6. Li, H. et al. (2026). *DevicesWorld: Benchmarking Cross-Device Agents in Heterogeneous Environments*. arXiv preprint. https://arxiv.org/abs/2607.13465 7. Tian, J. et al. (2026). *ABot-AgentOS: A General Robotic Agent OS with Lifelong Multi-modal Memory*. arXiv preprint. https://arxiv.org/abs/2607.10350 8. Yan, Y., Jia, Y., & Yang, Q. (2026). *When Multi-Robot Systems Meet Agentic AI: Towards Embodied Collective Intelligence*. arXiv preprint. https://arxiv.org/abs/2606.27929 9. Ravindran, S. K. (2026). *Portable Agent Memory: A Protocol for Cryptographically-Verified Memory Transfer Across Heterogeneous AI Agents*. arXiv preprint. https://arxiv.org/abs/2605.11032