可攜式 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. 「跨身體」不是把同一個模型複製很多份

最簡單但錯誤的想法是：

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。

例如：

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} ).

例如：

robot_01:
  resource = living_room_lights
  action = on/off
  expiry = session_end

而不是：

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),

其中節點：

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 的位置與可見範圍。

例如：

camera.robot_01
location = living_room

與：

camera.glasses
location = with_user

不是同一視角。

因此任何 observation 都應帶：

E= ( \text{payload}, \text{source}, \text{location}, \text{timestamp}, \text{confidence} ).

否則模型容易犯：

「機器人看到的，就是使用者看到的。」

這種錯誤。

跨身體智能的前提反而是更嚴格地知道：

每個「眼睛」在哪裡。

22. 記憶也應該有 provenance

當多裝置共同寫記憶時，應保存：

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

現在可以把整個系列壓縮成一張邏輯架構：

                         ┌─────────────────────┐
                         │ 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。

參考資料

Android Developers. Cross device SDK. Updated 2026-05-07.
https://developer.android.com/guide/topics/connectivity/cross-device-sdk/overview
Android Developers. Sessions API — Cross device SDK.
https://developer.android.com/guide/topics/connectivity/cross-device-sdk/sessions
Android Developers. Develop with the Jetpack XR SDK — Jetpack Projected. Updated 2026-05-19.
https://developer.android.com/develop/xr/jetpack-xr-sdk
Android Developers. XR Projected — Jetpack release notes. Updated 2026-07-15.
https://developer.android.com/jetpack/androidx/releases/xr-projected
Google. Intelligent eyewear with Gemini is coming this fall. 2026-05-19.
https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/
Li, H. et al. (2026). DevicesWorld: Benchmarking Cross-Device Agents in Heterogeneous Environments. arXiv preprint.
https://arxiv.org/abs/2607.13465
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
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
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

08_可攜式AI主腦_手機眼鏡機器人與電腦的跨身體智能