Meta Wearables Platform 技術略懂：API、資料能力、外部系統整合與 AI Agent 架構

Table of Contents

下一代運算平台

智慧眼鏡正在從單純的消費性硬體，逐漸變成新一代的人機互動平台。

過去使用者若要操作企業系統、查詢資料或與 AI 互動，通常需要拿出手機、打開 App，再透過觸控介面輸入指令。

智慧眼鏡改變了這個流程。

使用者可以直接透過眼鏡所看到的畫面、語音，以及簡短的手勢，與後端系統或 AI Agent 互動。

這使得應用程式不再只是等待使用者主動操作，而是有機會理解使用者當下所在的位置、正在觀看的物體，以及目前執行的工作。

Meta Wearables Platform 正是 Meta 為這類應用建立的開發平台。

不過，Meta 的設計方向與 Apple Vision Pro、Meta Quest、Magic Leap 或 Android XR 並不完全相同。

Meta 目前並不是要把完整的手機作業系統塞進眼鏡裡，也不是讓開發者直接把大型原生 App 安裝到眼鏡上。

它採取的是另一種架構：

眼鏡負責感知世界與提供輕量互動，手機與雲端則負責運算、資料處理與應用程式邏輯。

換句話說，Meta AI Glasses 更像是一個連接現實世界與 AI 系統的感知端點，而不是縮小版的手機。

截至 2026 年 8 月，Meta Wearables Platform 主要提供兩條開發路線：

Wearables Device Access Toolkit，簡稱 DAT。
Meta Ray-Ban Display Web Apps。

這兩條路線服務不同的產品需求。

DAT 適合需要使用相機、拍照、影片串流、音訊與行動 App 整合的產品。

Web Apps 則適合需要在眼鏡顯示器上呈現即時資訊、操作簡單工具或呼叫外部 API 的輕量應用程式。

Meta Wearables Platform 的基本架構

要理解這個平台，首先要理解 Meta 如何分配眼鏡、手機與雲端之間的工作。

整體架構大致如下：

Meta AI Glasses
├── Camera
├── Microphone
├── Open-ear Speakers
├── Captouch
├── Motion Sensors
└── Display（特定型號）
        │
        ▼
Mobile Companion App 或 Web App Runtime
        │
        ▼
Backend、Cloud AI 或 Enterprise Systems

眼鏡本身負責收集使用者周遭的感知資料。

例如，相機可以取得使用者第一人稱視角所看到的畫面。

麥克風可以接收使用者語音，以及環境中的聲音。

特定型號的 Display 則可以顯示簡短文字、圖片、按鈕與影片。

然而，複雜的資料處理通常不在眼鏡上執行。

相機畫面可以傳送到手機，再由手機進行影像抽樣、壓縮或基本辨識。

若需要使用大型 Multimodal Model，手機還可以把圖片或音訊傳送到雲端 AI 平台。

企業資料查詢、RAG、Knowledge Graph、工作流程與 Tool Calling，也由後端系統負責。

因此，實際上的智慧眼鏡應用往往不是只有一個 App，而是由多層軟體共同組成。

Glasses Layer
→ Mobile Layer
→ Gateway Layer
→ Agent Layer
→ Enterprise Systems

眼鏡是使用者看得見的介面。

手機是裝置控制、媒體處理與網路連線的協調層。

Gateway 負責驗證、安全、流量管理與租戶隔離。

Agent Platform 則負責模型推論、知識檢索與工具操作。

Meta Wearables Platform 不是完整的眼鏡作業系統

Meta Wearables Platform 最常被誤解的地方，是有人會把它想像成眼鏡版的 Android。

但現階段並不是如此。

開發者不能把一個完整 Android APK 或 iOS App 直接安裝到 Ray-Ban Meta 眼鏡上。

開發者也不能在眼鏡裡自由執行背景服務、資料庫或大型 AI Model。

DAT 的主要模式，是讓既有手機 App 取得眼鏡能力。

例如，一個原本就存在的 Android 維修 App，可以加入 DAT SDK。

加入之後，這個 App 就可以透過眼鏡取得第一人稱相機畫面。

使用者在維修機器時，不必拿著手機拍攝，眼鏡就可以把現場畫面傳回手機 App。

手機 App 再把畫面送到後端，讓 AI 判斷設備異常或提供維修步驟。

所以，DAT 的本質是：

讓眼鏡成為 iOS 或 Android App 的延伸裝置。

Web Apps 則是另一種形式。

它允許開發者使用 HTML、CSS 與 JavaScript，在支援 Display 的眼鏡上執行輕量 Web 應用程式。

這類 Web App 不適合承載大型企業系統，但很適合呈現簡短、即時且可快速操作的資訊。

例如：

查看下一個維修步驟。
顯示目前工單狀態。
查看行程提醒。
顯示即時比分。
顯示導航方向。
接收 AI Agent 的簡短回答。
查看倉庫揀貨清單。

因此，Meta 目前其實同時提供兩種應用模式。

DAT
→ 眼鏡作為手機 App 的硬體延伸

Web Apps
→ 眼鏡直接執行輕量 Web 介面

Wearables Device Access Toolkit 是什麼？

Wearables Device Access Toolkit 是 Meta 提供給 iOS 與 Android 開發者的原生 SDK。

DAT 的目的，是讓行動 App 可以控制或讀取 Meta AI Glasses 的部分能力。

主要功能包括：

註冊第三方 App。
尋找與選擇眼鏡。
管理權限。
建立 Device Session。
取得即時相機串流。
拍攝照片。
在 Display 上顯示內容。
監控連線與熱狀態。
模擬眼鏡進行開發測試。

在 Android 上，DAT 目前主要拆分成 4 個模組：

mwdat-core
mwdat-camera
mwdat-display
mwdat-mockdevice

這樣的拆分可以避免所有 App 都必須載入完整功能。

若一個 App 只需要相機，就可以主要使用 Core 與 Camera 模組。

若產品需要支援 Ray-Ban Display，才需要加入 Display 模組。

若團隊沒有足夠數量的實體眼鏡，則可以透過 Mock Device 模組進行測試。

`mwdat-core` 負責哪些功能？

mwdat-core 是整套 SDK 的基礎。

它負責 SDK 初始化、App 註冊、權限、裝置選擇、Session 管理與裝置狀態。

可以把它理解為 Meta Wearables Platform 的控制平面。

在使用相機或 Display 之前，App 必須先完成 Core Layer 的流程。

基本流程如下：

初始化 SDK
→ 確認 Meta AI App 狀態
→ 註冊第三方 App
→ 取得使用者授權
→ 探索可用裝置
→ 選擇目標眼鏡
→ 建立 DeviceSession

這個流程之所以較複雜，是因為實際上同時存在多個軟體角色。

包括：

第三方開發者 App。
Meta AI App。
Meta 帳號。
Meta AI Glasses。
iOS 或 Android 作業系統。

第三方 App 並不是直接繞過 Meta AI App 與眼鏡通訊。

使用者需要先透過 Meta AI App 配對眼鏡，並在開發者模式下授權第三方應用程式。

App 註冊與權限模型

DAT 的註冊流程與一般手機權限不同。

以相機為例，開發者不能只向 Android 要求 Camera Permission，就直接存取眼鏡相機。

實際上需要處理 3 層權限：

iOS 或 Android 作業系統權限。
Meta AI App 與眼鏡之間的授權。
第三方 App 在 DAT 中的註冊與 Camera Permission。

這表示 App 必須明確處理多種狀態。

例如：

- 尚未安裝 Meta AI App
- 已安裝但尚未登入
- 已登入但眼鏡尚未配對
- 眼鏡已配對但 App 尚未註冊
- App 已註冊但 Camera 尚未授權
- 權限已授權但眼鏡目前離線

若沒有完善處理這些狀態，使用者很容易遇到「明明已經允許相機，為什麼還是不能使用」的問題。

因此，正式產品不應只顯示單一的「連線失敗」。

應該將每個失敗原因轉換成具體指引。

例如：

請先安裝 Meta AI App。
請先完成眼鏡配對。
請在 Meta AI App 中啟用 Developer Mode。
請重新授權 Camera。
眼鏡目前未連線。
眼鏡韌體需要更新。

可以取得哪些裝置資料？

DAT 可以讓 App 取得目前可用的眼鏡清單。

每個裝置會有對應的 DeviceIdentifier。

這個識別值可以用來建立特定裝置的 Session，或追蹤目前正在使用哪一副眼鏡。

可取得的資料大致包括：

Device Identifier。
裝置名稱。
裝置類型。
連線狀態。
相容性狀態。
韌體相容資訊。
是否支援 Display。
目前被 Selector 選中的裝置。

連線狀態通常包括：

CONNECTING
CONNECTED
DISCONNECTED

這些資料足以讓 App 顯示目前裝置是否可用。

例如，一個企業 App 可以顯示：

Sean 的 Ray-Ban Meta
狀態：已連線
相機：可用
Display：不支援
韌體：相容

不過，Meta 並沒有開放所有底層硬體資料。

目前不能預期取得：

MAC Address。
完整硬體序號。
精確電池百分比。
電池健康度。
即時耗電瓦數。
精確溫度。
CPU 使用率。
記憶體用量。
Wi-Fi 訊號強度。

Meta 提供的是足以讓應用程式做決策的高階狀態，而不是工程診斷等級的完整硬體遙測。

DeviceSession 為什麼重要？

DeviceSession 是 DAT 架構中最核心的物件之一。

它代表第三方 App 與特定眼鏡之間的一段工作階段。

Camera Stream 與 Display 都依附在 DeviceSession 上。

架構大致如下：

Wearables SDK
    │
    ├── DeviceSelector
    │
    └── DeviceSession
            ├── Camera Stream
            ├── Display
            ├── Session State
            └── Session Errors

這種架構的好處，是可以把裝置生命週期集中管理。

例如，當眼鏡斷線時，Camera Stream 與 Display 都可以收到對應狀態。

當眼鏡過熱時，Session 可以通知上層應用程式降低負載。

當使用者停止使用功能時，App 也可以統一釋放 Session 資源。

常見的 Session 狀態包括：

IDLE
STARTING
STARTED
PAUSED
STOPPING
STOPPED

STARTED 代表 Session 已經準備完成。

但這並不代表相機一定已經開始傳送影片。

Camera Stream 與 Session 有各自的狀態。

所以，產品程式不能只判斷 Session 是否啟動。

它還必須進一步判斷 Stream 是否真正進入 STREAMING。

Session 可以回報哪些異常？

智慧眼鏡受到體積與電池限制，很容易受到溫度與峰值功率影響。

因此，DAT 會回報多種重要異常。

例如：

BATTERY_CRITICAL
PEAK_POWER_SHUTDOWN
THERMAL_CRITICAL
THERMAL_EMERGENCY
DAT_APP_ON_THE_GLASSES_UPDATE_REQUIRED

這些錯誤不是單純提供給開發者看紀錄。

產品應該根據這些狀態，自動調整行為。

例如，當眼鏡出現 THERMAL_CRITICAL 時，App 不應繼續嘗試維持 30 fps 高解析度串流。

它應該立即停止持續影片，改成按需拍照。

當出現 BATTERY_CRITICAL 時，App 也可以關閉非必要功能，並提示使用者充電。

因此，Device Health 應該被視為產品邏輯的一部分，而不是單純的錯誤處理。

Camera API 是目前最重要的能力

在 Meta Wearables Platform 已開放的能力中，相機是最成熟也最具有商業價值的部分。

眼鏡相機提供的是使用者第一人稱視角。

這與手機相機最大的差異，是使用者不需要特別拿出裝置取景。

眼鏡自然地看到使用者正在看的東西。

因此，它很適合以下場景：

現場設備檢查。
商品辨識。
文件辨識。
視障輔助。
食物辨識。
遠端協作。
倉儲揀貨。
教育與訓練。
第一人稱影音紀錄。
Multimodal AI Agent。

影片串流有哪些設定？

DAT 可以建立即時 Camera Stream。

開發者可以設定影片品質與 Frame rate。

目前公開的 Frame rate 包括：

2 fps
7 fps
15 fps
24 fps
30 fps

不同 Frame rate 適合不同情境。

2 fps 適合低頻率的場景辨識。

例如，使用者正在閱讀文件，畫面變化不大，沒有必要每秒傳送大量 Frame。

7 fps 適合一般 AI Vision 分析。

它可以提供相對流暢的畫面變化，又不至於產生過高的運算與網路負載。

15 fps 適合遠端協助與較即時的辨識。

24 fps 或 30 fps 則適合接近一般影片播放的使用體驗。

不過，Frame rate 越高，眼鏡的耗電、溫度與無線傳輸負載也越高。

因此，正式產品不應永遠固定使用 30 fps。

應根據使用場景動態調整。

可以取得哪些 VideoFrame 資料？

Camera Stream 會持續產生 VideoFrame。

每個 VideoFrame 可以包含實際影片資料，以及用於同步與判斷格式的 Metadata。

主要資料包括：

Frame Payload。
presentationTimeUs。
isCompressed。
isCodecConfig。
解碼後影像或壓縮影片資料。

presentationTimeUs 是 Frame 的呈現時間戳記。

它可用於排序 Frame、計算延遲，或進行音訊與影片同步。

isCompressed 用來判斷目前 Frame 是否仍為壓縮影片資料。

isCodecConfig 則表示該資料是否為 Codec 初始化資訊。

Codec Config 並不是一般可以直接顯示的畫面。

它通常用來初始化 HEVC Decoder。

因此，若產品自行處理壓縮串流，必須正確區分 Codec Config 與一般 Video Frame。

Decoded Frame 與 Compressed HEVC 有什麼差異？

DAT 支援兩種主要影像處理模式。

第一種是取得已經解碼的影像。

Glasses Camera
→ DAT Decoder
→ Bitmap／Pixel Buffer
→ App

這種模式使用簡單。

開發者可以直接把 Frame 交給：

OCR 模型。
條碼辨識器。
Object Detection Model。
Scene Classifier。
本機 Vision Framework。

缺點是解碼後的影像資料量很大。

例如，一張未壓縮的 RGB Frame 可能比壓縮影片大上許多。

若每秒處理 30 張，會造成顯著的記憶體與 CPU 負擔。

第二種模式是保留 HEVC 壓縮資料。

Glasses Camera
→ HEVC Access Units
→ Mobile App
→ 儲存、轉送或自行解碼

這種模式更適合：

雲端影片傳輸。
遠端協作。
長時間錄影。
低頻寬網路。
自訂 Media Pipeline。
Edge Video Processing。

開發者可以把壓縮影片傳給後端，再由後端解碼。

這通常比每張 Bitmap 個別上傳有效率。

Wi-Fi Video Streaming 的意義

早期眼鏡與手機之間的資料傳輸高度依賴 Bluetooth。

Bluetooth 適合控制訊息、音訊與較低頻寬資料。

但高解析度影片需要更穩定的頻寬。

DAT 0.8.0 開始加入 Wi-Fi Video Streaming。

這讓高解析度影片有機會透過 Wi-Fi 傳輸，減少 Bluetooth 頻寬限制。

不過，Wi-Fi Streaming 仍然會面臨：

連線切換。
Wi-Fi 建立失敗。
Frame 丟失。
Codec 解碼中斷。
延遲波動。
眼鏡熱負載。
手機網路路由問題。

因此，產品架構不能假設 Wi-Fi 永遠穩定。

較好的方式是建立 Transport Abstraction。

Video Transport Layer
├── Bluetooth Transport
├── Wi-Fi Transport
└── Fallback Policy

當 Wi-Fi 不可用時，App 可以自動降低影片品質，切換到較低 Frame rate。

拍照 API 適合什麼情境？

除了持續影片串流，DAT 也提供 Photo Capture。

拍照通常比持續影片更容易產品化。

使用者可以在需要時主動觸發拍照。

例如：

「這台機器顯示什麼錯誤？」
「這個商品的成分是什麼？」
「請讀出這份文件。」
「這個零件應該怎麼安裝？」
「這道菜可能含有哪些過敏原？」

典型流程如下：

使用者觸發
→ App 要求眼鏡拍照
→ 取得 PhotoData
→ 手機壓縮或裁切
→ 上傳 Multimodal Model
→ Agent 分析
→ 語音或 Display 回答

Photo Capture 可能回傳以下錯誤：

DeviceDisconnected
NotStreaming
CaptureInProgress
CaptureFailed
Timeout

其中 NotStreaming 很重要。

它表示拍照功能通常仍依賴有效的 Camera Stream 或 Camera Session。

產品不能在相機尚未準備完成時直接要求拍照。

相機 API 不會直接替你理解畫面

DAT 提供的是影像資料，不是 AI 辨識結果。

它不會直接告訴開發者：

畫面中有一台機器。
機器型號是什麼。
文件上寫了什麼。
商品名稱是什麼。
使用者是否在工廠。
畫面中是否有危險物品。

這些語意都必須透過外部模型取得。

例如：

VideoFrame
→ Object Detection
→ OCR
→ Multimodal LLM
→ Knowledge Retrieval
→ Agent Decision

Meta 目前開放的是感知入口。

至於如何理解感知資料，仍由開發者自行設計。

Camera API 還缺少哪些空間資料？

Meta AI Glasses 的 Camera API 與 Magic Leap、HoloLens 或完整 AR Platform 不同。

目前沒有公開保證可取得：

Camera Intrinsic Matrix。
Lens Distortion Parameters。
Focal Length。
Exposure Time。
ISO。
White Balance。
Focus Distance。
Depth Map。
Spatial Mesh。
Plane Detection。
SLAM Pose。
World Anchors。
Camera 與 IMU Calibration Matrix。

因此，DAT Camera 很適合影像辨識與第一人稱串流。

但它不適合直接建立需要精確空間定位的 AR 應用程式。

例如，若要把一個 3D 箭頭固定在真實世界的機器按鈕上，DAT 現階段並不是最合適的平台。

Audio API 的實際運作方式

Meta 官方會描述眼鏡具有麥克風與喇叭能力。

但這不代表 DAT 提供了一套完整的 Raw Audio SDK。

目前的主要模式，是透過手機的 Bluetooth Audio Framework 使用眼鏡音訊。

在 iOS 上，開發者通常會使用：

AVAudioSession
AVAudioEngine
AVAudioRecorder
Speech Framework
WebRTC

在 Android 上，常見技術包括：

AudioManager
AudioRecord
AudioTrack
MediaRecorder
SpeechRecognizer
WebRTC

資料流大致如下：

Glasses Microphone
→ Bluetooth Audio Route
→ Mobile OS Audio Framework
→ App

語音回覆則反向進行：

Agent Response
→ Text-to-Speech
→ Mobile Audio Framework
→ Glasses Speakers

這使得開發者可以建立自己的語音 Agent。

例如：

使用者說話
→ Speech-to-Text
→ Intent Detection
→ Agent
→ Tool Calling
→ Text-to-Speech
→ 眼鏡播放

不能直接擴充 Meta AI 內建助理

這裡必須特別釐清。

第三方開發者可以建立自己的語音 Agent。

但目前不能假設可以把自己的 API 直接註冊成 Meta AI 的 Tool。

目前沒有公開介面讓第三方：

攔截「Hey Meta」。
取得 Meta AI 對話內容。
讀取 Meta AI Memory。
接收 Meta AI 辨識結果。
將企業 API 註冊進 Meta AI Function Calling。
改變 Meta AI 的系統提示詞。
取得 Meta AI 的 Speech-to-Text 結果。

因此，第三方語音 Agent 必須在自己的手機 App 中執行。

它不是 Meta AI 內建 Agent 的 Plugin。

Display API 的定位

支援 Display 的眼鏡，可以透過 mwdat-display 顯示資訊。

目前可用元件主要包括：

FlexBox
Text
Button
Image
Icon
VideoPlayer

這些元件足以建立簡單資訊介面。

例如：

設備異常
馬達溫度高於正常範圍
［查看處理步驟］

或：

下一個揀貨商品
A 區 3 排 12 號
商品：Organic Oat Milk
數量：2

Display 的核心設計原則是 Glanceable UI。

也就是使用者只需要看一眼，就能理解目前最重要的資訊。

它不是要讓使用者在眼鏡上閱讀完整報表或操作複雜表單。

為什麼不能把手機介面直接搬到眼鏡？

眼鏡 Display 的使用情境與手機不同。

手機可以讓使用者長時間注視，並透過手指精細操作。

眼鏡 Display 通常只能呈現有限畫面。

使用者也不適合長時間閱讀密集文字。

因此，Display API 具有明顯限制：

一次只能呈現有限內容。
每次更新可能取代整個畫面。
適合單一 Root View。
不適合複雜 Dashboard。
不支援自由 3D Rendering。
不等同 Android View。
不等同 SwiftUI。
不等同 React Native。
不支援 Unity Scene。

設計上應該遵循：

一個畫面
一個問題
一個主要動作
少量文字
清楚層級
快速完成

例如，客服 Agent 不應顯示完整客服後台。

它只需要顯示：

訂單延遲
預計明日下午送達
［通知客戶］

Display 可以取得哪些操作事件？

Display 上的 Button 或可點擊元件，可以接收 Callback。

使用者在眼鏡上選擇按鈕後，事件會回傳手機 App。

手機 App 再執行實際商業邏輯。

User Click
→ Display Callback
→ Mobile App
→ Backend API
→ Update Display

例如：

使用者點擊「查看處理步驟」
→ App 呼叫維修 API
→ 取得下一個 SOP
→ Display 更新內容

所以 Display 並不是獨立應用程式環境。

它仍然與手機 App 的狀態與網路邏輯高度相關。

VideoPlayer 可以做什麼？

Display API 支援播放 MP4 影片。

這很適合呈現短時間教學內容。

例如：

如何更換耗材。
如何重設機器。
如何安裝零件。
如何進行安全檢查。
如何包裝商品。

典型流程如下：

Agent 判斷使用者需要教學
→ 後端回傳影片 URL
→ Mobile App 更新 Display
→ VideoPlayer 播放 MP4

目前不能把它當成完整影音串流平台。

不應假設它具備：

完整 HLS。
DASH。
DRM。
複雜字幕軌。
多音軌。
WebRTC 即時播放。
自訂播放器 Rendering。

它比較像受控的短影片播放元件。

Web Apps 是什麼？

Web Apps 是另一條完全不同的開發路線。

它允許開發者使用 Web 技術建立 Display 應用程式。

主要語言是：

HTML
CSS
JavaScript
TypeScript

Web App 可以部署在公開 HTTPS URL。

使用者再透過 Meta 支援的方式，把這個 Web App 加入眼鏡。

這使得 Web 團隊可以快速建立原型，而不必先開發完整 iOS 或 Android App。

Web Apps 特別適合資訊型應用。

例如：

即時比分。
行程提醒。
天氣資訊。
工單狀態。
導航方向。
即時庫存。
簡單遊戲。
Agent 回答介面。

Web Apps 可以取得哪些感測器資料？

Web Apps 可以使用標準 Web Sensor Event。

其中之一是 deviceorientation。

window.addEventListener("deviceorientation", event => {
  console.log(event.alpha);
  console.log(event.beta);
  console.log(event.gamma);
});

可取得的主要資料包括：

alpha：繞 Z 軸旋轉。
beta：頭部前後傾斜。
gamma：頭部左右傾斜。
absolute：是否為絕對座標。

這些資料可以用來判斷頭部方向變化。

例如，開發者可以自行推導：

點頭。
搖頭。
左右傾斜。
朝向改變。
簡易姿態互動。

但 API 不會直接回傳「使用者剛剛點頭」。

開發者需要分析連續的角度資料，建立 Gesture Detection Logic。

DeviceMotion 可以取得哪些資料？

Web Apps 也可以監聽 devicemotion。

window.addEventListener("devicemotion", event => {
  console.log(event.acceleration);
  console.log(event.accelerationIncludingGravity);
  console.log(event.rotationRate);
  console.log(event.interval);
});

可取得的資料包括：

X、Y、Z 線性加速度。
包含重力的 X、Y、Z 加速度。
Alpha、Beta、Gamma 角速度。
感測器事件時間間隔。

這些資料可以用來建立：

頭部動作辨識。
移動狀態判斷。
簡易步態推估。
互動式遊戲。
頭部控制選單。

不過，IMU 資料會產生 Drift。

因此，它不能直接替代完整 SLAM。

也不能直接提供使用者在房間中的精確位置。

Web Apps 可以取得 GPS 嗎？

可以，但 GPS 來自配對手機，而不是眼鏡本身。

使用方式是標準 Web Geolocation API。

navigator.geolocation.getCurrentPosition(position => {
  const latitude = position.coords.latitude;
  const longitude = position.coords.longitude;
  const accuracy = position.coords.accuracy;
});

可取得：

緯度。
經度。
水平精確度。
定位錯誤。
定位逾時。

這可以支援：

導航。
附近地點。
地區限定資訊。
現場服務。
物流與外勤。
路線與位置提醒。

產品應注意，手機可能沒有授權定位。

室內定位也可能不夠精確。

因此，GPS 不應作為唯一的高風險判斷依據。

Meta Neural Band 可以取得 Raw EMG 嗎？

目前不行。

Web Apps 可以接收 Neural Band 轉換後的高階輸入事件。

例如：

上
下
左
右
選取
返回

這些事件會被轉換成類似 D-pad 或 Keyboard Navigation 的操作。

Web App 可以知道使用者選擇了哪個項目。

但不能取得：

Raw EMG。
肌肉電位強度。
各肌群訊號。
手指骨架。
手腕姿態。
手勢辨識信心分數。
Neural Band 原始取樣資料。

Meta 將敏感的生理訊號留在平台內部。

第三方開發者只能使用已經辨識完成的高階事件（哭哭）。

Web Apps 能不能呼叫外部 API？

可以。

這是 Web Apps 很重要的能力。

由於它使用標準 JavaScript，因此可以透過 fetch() 呼叫 REST API。

async function loadWorkOrder() {
  const response = await fetch(
    "https://api.example.com/v1/work-orders/A1024",
    {
      method: "GET",
      headers: {
        "Accept": "application/json"
      }
    }
  );

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json();
}

這代表眼鏡上的 Web App 可以取得：

ERP 資料。
CRM 資料。
MES 狀態。
即時庫存。
工單。
天氣。
交通。
行程。
AI Agent 回答。
Knowledge Graph 資料。
企業內部服務。

例如：

使用者開啟眼鏡 Web App
→ Web App 呼叫工單 API
→ API 回傳目前任務
→ 眼鏡顯示下一個步驟

Web Apps 可以使用 WebSocket 嗎？

可以。

WebSocket 適合需要即時更新的應用。

const socket = new WebSocket(
  "wss://api.example.com/v1/events"
);

socket.addEventListener("message", event => {
  const data = JSON.parse(event.data);
  renderStatus(data);
});

例如，一台機器發生異常時，後端可以主動推送事件。

Machine Alert
→ Backend Event
→ WebSocket
→ Display Glasses

使用者不需要反覆重新整理頁面。

這很適合：

工廠告警。
遠端協作。
AI Agent 非同步結果。
即時比分。
物流狀態。
排隊進度。
工單更新。

DAT 本身如何呼叫外部 API？

DAT 沒有提供特殊的 Meta HTTP Client。

因為 DAT 執行在 iOS 或 Android App 裡，所以開發者直接使用手機原生網路工具。

Android 常見選項：

OkHttp
Retrofit
Ktor Client
GraphQL Client
gRPC

iOS 常見選項：

URLSession
URLSessionWebSocketTask
Alamofire
GraphQL Client
gRPC

例如，Android App 可以在拍照後呼叫自己的 Agent API。

data class AgentRequest(
    val sessionId: String,
    val question: String,
    val imageBase64: String
)

interface AgentApi {
    @POST("v1/wearable-agent/respond")
    suspend fun respond(
        @Body request: AgentRequest
    ): AgentResponse
}

資料流程如下：

Glasses Photo
→ DAT
→ Android App
→ Agent API
→ Multimodal LLM
→ RAG
→ Tool Calling
→ Response
→ Display／Audio

能不能直接呼叫 OpenAI 或 Anthropic？

技術上可以發出 HTTP Request。

但不應讓 Web App 直接持有正式 API Key。

例如，以下設計很危險：

const OPENAI_API_KEY = "sk-...";

JavaScript Bundle 可能被讀取。

Network Request 也可能被攔截或檢視。

正確架構應該是：

Wearable App
→ Own Backend
→ Secrets Manager
→ AI Model API

你的後端負責：

驗證使用者。
保存 API Key。
Rate Limiting。
租戶隔離。
Prompt Policy。
Audit Log。
Cost Control。
Response Filtering。

眼鏡前端只取得短效 Session Token。

不要讓眼鏡 App 持有：

OpenAI API Key。
AWS Access Key。
Database Password。
ERP Admin Token。
長效 Service Account Secret。

企業 Agent 的完整架構

對企業應用而言，眼鏡不應直接連接每一套後端系統。

較好的做法，是建立統一的 Wearable Agent Gateway。

Meta AI Glasses
        │
        ▼
Mobile App／Web App
        │
        ▼
Wearable Agent Gateway
├── Authentication
├── Tenant Isolation
├── Session Management
├── Rate Limiting
├── Privacy Filter
├── Media Processing
└── Response Router
        │
        ▼
Agent Platform
├── Multimodal LLM
├── Speech-to-Text
├── Text-to-Speech
├── RAG
├── Ontology
├── Knowledge Graph
├── Workflow Engine
├── Tool Calling
└── Human Escalation
        │
        ▼
Enterprise Systems
├── ERP
├── CRM
├── MES
├── WMS
├── Ticketing
└── Data Warehouse

Gateway 可以避免眼鏡 App 直接知道所有企業系統的 API。

它也可以統一處理身分驗證與權限。

例如，同一個眼鏡 Agent 收到「顯示這台機器最近的維修紀錄」時，Gateway 可以先確認使用者是否有權限查看該設備。

之後 Agent 才能呼叫 MES 或維修系統。

不要把每一個 Camera Frame 都送給 LLM

這是智慧眼鏡 AI 架構中最重要的成本與效能問題之一。

若 Camera Stream 是 30 fps，代表每秒可能產生 30 張圖片。

如果每張圖片都送給 Multimodal LLM，成本與延遲都會非常高。

而且連續 Frame 通常高度相似。

例如，使用者看著同一台機器 10 秒，可能產生 300 張幾乎相同的畫面。

較好的架構是：

Camera Stream
→ Frame Sampling
→ Scene Change Detection
→ Image Quality Check
→ Privacy Filter
→ Key Frame Selection
→ Multimodal Model

只有重要 Frame 才需要送到模型。

例如：

靜態場景
→ 每 3 秒取樣一次

畫面快速變化
→ 每 0.5 秒取樣一次

使用者主動提問
→ 立即拍攝高品質照片

沒有新物體或場景變化
→ 不送模型

這可以顯著降低：

Token 成本。
網路流量。
推論延遲。
電池消耗。
裝置熱度。
隱私風險。

隱私與資料治理不能留到最後

第一人稱相機比手機相機更敏感。

因為眼鏡可能持續看到：

同事。
客戶。
螢幕。
文件。
身分證件。
工廠機密。
個人住宅。
醫療資訊。
車牌。
金融資料。

因此，產品應建立 Privacy Filter。

例如：

Camera Frame
→ Face Blurring
→ Screen Detection
→ Sensitive Document Detection
→ PII Redaction
→ Upload Policy

企業還需要定義：

哪些 Frame 可以上傳雲端。
哪些資料只能在手機端處理。
影像保存多久。
是否保留原始影片。
哪些人能查看紀錄。
是否需要使用者明確觸發。
是否需要現場錄影指示。

智慧眼鏡不是一般手機 App。

影像資料治理必須成為平台架構的一部分。

建議建立跨平台 Wearable Adapter

Meta 目前很有潛力，但智慧眼鏡市場仍在快速變動。

未來企業可能同時使用：

Meta AI Glasses。
Android XR Glasses。
XREAL。
Vuzix。
Magic Leap。
其他工業眼鏡。

因此，上層 Agent 不應直接綁死 Meta DAT。

建議定義平台無關介面。

interface WearableDeviceAdapter {
  connect(): Promise<void>;
  disconnect(): Promise<void>;

  capturePhoto(): Promise<CapturedImage>;

  startVideoStream(
    config: VideoStreamConfig
  ): Promise<void>;

  stopVideoStream(): Promise<void>;

  renderView(
    view: WearableView
  ): Promise<void>;

  clearView(): Promise<void>;

  observeDeviceState(
    listener: (
      state: WearableDeviceState
    ) => void
  ): Unsubscribe;
}

不同平台再各自實作：

MetaWearablesAdapter
AndroidXRAdapter
XrealAdapter
VuzixAdapter
MockWearableAdapter

如此一來，RAG、Ontology、Knowledge Graph、Workflow 與 Agent Policy 都可以保持不變。

當企業改用另一款眼鏡時，只需要更換底層 Adapter。

目前還沒有開放哪些重要能力？

Meta Wearables Platform 已經可以建立很多有價值的應用。

但它仍不是完整開放的 Spatial Computing Platform。

目前沒有公開給一般第三方開發者的能力包括：

Meta AI 內部能力

Meta AI 對話 API。
Meta AI Memory。
Meta AI Context。
自訂喚醒詞。
Meta AI Tool Registration。
Meta AI Function Calling。
Meta AI 回答內容。
Meta AI Speech Transcript。

空間運算

SLAM。
6DoF World Pose。
Depth。
Spatial Mesh。
Plane Detection。
World Anchors。
3D Scene Understanding。
完整 AR Rendering。

生物與精細輸入

Eye Tracking。
Gaze Point。
Pupil Data。
Raw Neural Band EMG。
Hand Skeleton。
Finger Coordinates。
Gesture Confidence。

硬體遙測

精確電池百分比。
充電狀態。
精確溫度。
CPU／GPU／NPU 負載。
完整 Wi-Fi 訊號資訊。
Camera Exposure Control。
Raw Microphone Array。

這些限制會影響產品定位。

若產品需要完整 AR 空間定位，可能應優先評估 Android XR 或 Magic Leap。

若產品需要第一人稱 Camera、Voice 與輕量資訊顯示，Meta Wearables Platform 則非常適合。

哪些產品適合使用 DAT？

DAT 最適合已有 iOS 或 Android App 的團隊。

典型情境包括：

企業現場作業。
遠端協作。
維修輔助。
第一人稱影像分析。
視覺 AI Agent。
語音客服助理。
文件與商品辨識。
照護輔助。
現場稽核。
安全巡檢。

DAT 也比較適合需要複雜驗證、背景服務或離線快取的產品。

例如：

OAuth。
Enterprise SSO。
Mobile Push Notification。
Encrypted Local Database。
Background Upload。
MDM。
Device Policy。
Secure Token Storage。

哪些產品適合使用 Web Apps？

Web Apps 適合需要快速開發與簡單 Display 介面的產品。

例如：

天氣。
行程。
工單。
待辦清單。
即時比分。
導航提示。
庫存查詢。
食譜步驟。
AI 回答卡片。
簡單互動遊戲。

若團隊主要由 Web Developer 組成，Web Apps 也能降低進入門檻。

不過，如果產品需要 Camera、複雜 Background Service 或安全保存大量憑證，DAT Mobile App 會更適合。

平台目前適合正式商業化嗎？

Meta Wearables Platform 已經足以建立：

PoC。
Prototype。
Enterprise Pilot。
Internal Tool。
Controlled Beta。
展示型應用。
研究專案。

但平台仍處於快速演進階段。

產品團隊需要預留以下風險：

API 簽章改動。
SDK 版本升級。
韌體差異。
裝置型號能力不同。
Display API 變更。
Wi-Fi Streaming 穩定性。
Developer Preview 發布限制。
市場區域限制。
App Review 政策變更。
隱私與錄影規範調整。

所以，現階段適合建立可替換、可測試、低耦合的架構。

不適合把整個產品核心直接寫死在某個 Preview API 上。

小結一下：Meta 正在打造的是 AI Agent 的感知入口

Meta Wearables Platform 最重要的價值，不只是讓開發者取得眼鏡相機。

它真正改變的是人與軟體互動的方式。

傳統軟體的流程是：

使用者發現問題
→ 拿出手機
→ 打開 App
→ 找到功能
→ 輸入資料
→ 等待回答

智慧眼鏡 Agent 的流程則可能變成：

使用者看著問題
→ 眼鏡取得情境
→ 使用者直接提問
→ Agent 理解畫面
→ Agent 查詢企業資料
→ 眼鏡立即回覆

軟體不再只存在於一個矩形螢幕裡。

它開始進入使用者所處的環境與工作流程。

在這個架構中，Meta AI Glasses 負責：

看見。
聽見。
接收簡短輸入。
提供即時回饋。

手機負責：

裝置連線。
媒體處理。
本機運算。
權限與網路。

後端 Agent Platform 則負責：

理解意圖。
檢索知識。
呼叫工具。
執行工作流程。
存取企業系統。
產生可執行建議。

因此，Meta Wearables Platform 最合理的產品定位，不是「把手機 App 搬到眼鏡」。

而是：

將眼鏡變成企業 AI Agent 的第一人稱感知與互動端點。

這也代表，智慧眼鏡真正的競爭力，不只取決於硬體規格。

長期來看，決定產品價值的，會是眼鏡背後所連接的 Agent、Ontology、Knowledge Graph、Workflow、Enterprise API 與治理架構。