Honor 發佈 MagicOS 11?Agent Harness 如何處理意圖

opoinstall
2026-09-16
5 min read

Honor 發佈 MagicOS 11?2026 年 9 月 15 日,Honor 在深圳全球開發者大會上正式發表 MagicOS 11,這是 Honor 所述業界首個在消費級智慧型手機上進行商用的系統級 Agent Harness(代理框架)架構。該作業系統將於即將推出的旗艦機 Honor Magic9 上首發,標誌著行動系統工程的重大轉變:從傳統的圖形化應用程式容器轉向「代理型作業系統」(Agentic OS, AOS)。早期的行動 AI 助理通常強調對話回覆與受限的任務自動化,而 MagicOS 11 則將重點擴展至更長遠的系統級編排,將其核心引擎(品牌命名為 YOYO Harness)定位為系統級運行時控制平面。對於軟體架構師與行動平台工程師而言,此次發佈引發了關鍵議題:系統級框架如何將不受限的自然語言分解為經過驗證的多步驟任務、如何管理跨結構化協定與視覺回退層(visual fallback layers)的工具調用,以及代理程式操作如何跨越 Android 應用程式與權限邊界進行治理?

架構典範:從應用程式容器到代理型作業系統

過去十年,行動作業系統的演進主要圍繞在資源分配上,例如為沙盒化第三方應用程式優化 CPU/GPU 排程、記憶體壓縮、無線遙測與顯示渲染。使用者互動本質上仍是以用戶為中心:個體開啟應用程式、瀏覽巢狀導航層級、執行特定功能,並手動在碎片化的服務之間建立連接。

概覽

  • 系統級 Harness 控制平面:YOYO Harness 作為前沿推理模型與物理終端能力之間的中間件運行時,負責編排設備感知、長程任務規劃、工具調度與執行回饋。
  • 雙軌工具調用管線:MagicOS 11 透過模型上下文協定 (MCP)、原生 Skills 與系統 API 優先處理結構化、類型化的執行路徑,同時保留電腦視覺 (CV) 與圖形使用者介面 (GUI) 自動化,作為未適配應用程式的動態回退方案。
  • 長程執行邊界:雖然 Honor 報告其具備執行跨越 40 種觸發條件與 130 多種執行動作、超過 100 步的順序任務鏈的能力,但實際的消費級應用仍聚焦於緊湊、高頻率的微工作流(micro-workflows),且在適當情況下,應針對高影響力的動作納入明確的確認檢查點。

Honor CEO 李建於全球開發者大會現場詳細說明 MagicOS 11 以及從應用程式容器轉向代理型作業系統的戰略轉移

Honor 的架構轉型反映了裝置端機器智慧長達十年的發展軌跡。從 2016 年第一代 Magic Live 引擎開始,經歷 MagicOS 8.0 的平台級意圖辨識以及 MagicOS 9.0 的自主代理探索,該平台持續將計算資源轉向上下文理解。在發表會中,Honor 領導層將此里程碑納入其更廣泛的 Alpha 策略與 AHI(AI 人機互動)願景,並延續該公司先前承諾在未來五年內投入超過 100 億美元於 AI 裝置生態系統轉型。

根據大會期間揭露的平台指標,YOYO 目前為超過 1.6 億名月活躍用戶提供服務,涵蓋 1,000 種主動式生活場景。然而,從主動式推薦轉向自主任務執行,需要重構作業系統與外部服務互動的方式。代理型作業系統不再要求用戶尋找並操作個別工具,而是必須能夠詮釋意圖、組合分散式工具、處理中間執行故障並交付驗證後的成果。

解構 YOYO Harness:感知、規劃與雙軌執行

在當代的 AI 系統中,單一基礎模型無法作為自主代理運作。正如系統架構師常提到的,大型模型提供認知推理能力,而框架(Harness)則提供了操作工作台——供應持久記憶、環境感知、結構化工具與安全限制。若缺乏提供持久狀態、工具與執行回饋的編排層,基礎模型本身無法可靠地驗證外部動作或從環境變更中恢復。

Honor MagicOS 11 官方發表會幻燈片,詳細說明 YOYO Harness 性能基準,包括 100 步任務執行、91.8% 意圖理解率與 700 種系統工具

YOYO Harness 透過作為 MagicOS 內部的系統級編排層來協調這些職責,連接終端輕量化模型與雲端推理叢集。

工程範圍說明:下列圖表為參考模型,係根據 Honor 對感知、規劃、工具調用、執行與外掛程式介面的公開說明所合成。Honor 尚未公開完整的內部 YOYO Harness 元件拓撲結構。

+-------------------------------------------------------------------------+
|      參考模型:YOYO HARNESS 系統級編排                                     |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 多模態攝取層:語音、螢幕上下文、感測器狀態 ]                            |
|                                |                                        |
|                                v                                        |
|  [ 上下文聚合器:個人偏好與環境遙測 ]                                      |
|                                |                                        |
|                                v                                        |
|  [ 認知規劃器:逐步任務規劃與目標分解 ]                                    |
|                                |                                        |
|                                v                                        |
|  [ YOYO Harness 控制平面:任務調度與策略檢查 ]                             |
|                                |                                        |
|         +----------------------+----------------------+                 |
|         |                                             |                 |
|         v (主要:結構化路徑)                           v (回退路徑)      |
|  [ 標準化工具路由 ]                         [ GUI 基礎引擎 ]          |
|  - 模型上下文協定 (MCP 外掛程式)             - 螢幕 OCR / CV 模型      |
|  - 系統 API (電話、行事曆、提醒)             - 系統調解 UI 動作        |
|  - 已註冊應用程式技能架構 (Skill Schemas)     - 視覺狀態觀察            |
|         |                                             |                 |
|         +----------------------+----------------------+                 |
|                                |                                        |
|                                v                                        |
|  [ 執行回饋迴路:步驟觀察與故障恢復 ]                                      |
|                                                                         |
+-------------------------------------------------------------------------+

雙軌調用管線

為了跨越異質應用生態系統執行動作,YOYO Harness 部署了雙層執行階層:

  1. 結構化高速公路 (MCP、Skills 與系統 API):當第三方服務或系統元件公開正式契約時(例如模型上下文協定 MCP、驗證過的身分端點或原生 Android Intent),YOYO 會透過結構化工具與服務介面進行互動。MagicOS 11 隨附 700 種內建系統工具與超過 500 種標準化 Skills。同時,Honor 報告稱其廣大的生態系統已連接超過 10,000 種第三方 AI 服務。與視覺自動化相比,結構化介面通常提供更明確的參數契約、較低的互動開銷與更清晰的權限邊界。
  2. 動態回退 (電腦視覺與 GUI 基礎):對於缺乏結構化介面的應用程式,YOYO 可回退至基於 GUI 的互動。公開資料顯示,代理程式可解讀應用程式介面並執行類似用戶的操作,但 Honor 尚未公開此回退路徑背後的完整感知與輸入注入堆疊。平台工程師將 GUI 自動化視為一種務實的回退方案,主因其容易受 UI 佈局變更、動態渲染延遲及應用程式反自動化措施的影響。

Honor MagicOS 11 官方系統架構圖,說明終端-雲端協作大型模型基礎架構、YOYO Harness 中間件與動態液體玻璃設計

意圖解析與日常微工作流

Honor 指出,YOYO 的綜合意圖理解率達到 91.8%,簡單任務的執行準確度達到 93%,複雜工作流則達到 87%,整體閉環完成率為 90%。儘管行銷揭露資訊強調執行超過 100 步連續任務序列的技術里程碑,但對於許多日常消費者場景而言,其實際價值可能更多來自於較短、可重複的工作流,而非 100 步的鏈條。

發表會簡報展示 YOYO 日常主動服務場景,包括日程管理與分類物流包裹追蹤

為將這些日常任務實作化,MagicOS 11 引入了「YOYO 任務」,允許用戶在 40 種觸發條件與 130 多種執行原語之間綁定動作:

  • 自動化服務排隊:AI 通話助理可撥打客服專線、導航交互式語音應答 (IVR) 鍵盤樹、在呼叫隊列中保持連線,並僅在真人客服接聽時透過觸覺通知提醒用戶。
  • 多模態上下文提取:在蜂巢式網路通話期間,裝置端音訊轉錄可提取提到的會議日期、航班號碼或電話聯絡人,直接將其導入本地行事曆與聯絡人提供者中。
  • 情境物流解析:系統不僅從簡訊與電子商務應用程式中聚合追蹤號碼,還會根據物品屬性將配送代碼分類——例如標記易腐爛的雜貨以進行即時領取,或協調大型貨物的運送協助。

防禦性安全、沙盒隔離與錯誤堆疊

授權自主軟體代理程式對行動工作流進行程式化控制,會引入重大營運風險。正如自主代理的標準漏洞分類(例如 OWASP 的 LLM 與 Agentic AI 安全分類學,強調包括提示詞注入、過度代理與工具誤用等風險)所述,當助理能夠變更系統或應用程式狀態時,這些擔憂會變得尖銳。

多步驟代理執行的一個基本工程現實是錯誤機率的複合性質。如果單一任務步驟保持 95% 的獨立可靠率,根據示範性可靠度模型,成功完成一個未經協助的 100 步任務鏈的機率將急劇下降:

P(成功)=0.951000.0059(0.59%)P(\text{成功}) = 0.95^{100} \approx 0.0059 \quad (0.59\%)

因此,100 步以上的數字更適合作為已驗證的長程執行能力的上限,而非典型消費者工作流應在無人看管下執行 100 步的證據。為防止狀態漂移失控,自主行動架構需要嚴格的控制措施:

  1. 應用程式級治理:Honor 記錄了一種應用程式聲明控制機制,讓第三方開發者能透過清單 (manifest) 元資料決定 YOYO 的 GUI 代理是否可與其應用程式互動。系統級 YOYO 運行時的完整權限模型尚未公開說明,但其在 Android 基礎平台隔離的基礎上運作。
  2. Android 沙盒上下文:標準 Android 安全隔離(包括運行時權限對話框、軟體包簽章檢查與隔離進程空間)仍是第三方軟體的底層邊界,要求代理整合必須尊重所聲明的清單邊界。
  3. 工程確認檢查點:在企業級代理設計中,高影響力的狀態變更——例如財務結算、憑證更改、不可逆刪除以及物理硬體控制(例如智慧鎖或聯網車輛)——在提交變更前需要明確的人機協作 (HITL) 確認對話框。
維度 傳統行動 OS (應用導向) 早期行動語音助理 系統級 Agent Harness (MagicOS 11)
執行原語 靜態應用程式二進位檔 硬編碼語音意圖處理器 多步驟任務 / 意圖圖譜
用戶互動 手動螢幕觸控與 UI 導航 嚴格的語音指令控制 自然語言目標 -> 編排執行
工具整合 顯式意圖過濾器與深度連結 專有雲端擴充功能 混合式:標準化外掛程式 + 動態 GUI
上下文範圍 僅限活躍的前台應用程式 僅限語音輸入工作階段 全系統:螢幕、音訊、位置、偏好設定
故障恢復 進程崩潰 / 應用程式 ANR 對話框 通用語音錯誤道歉 執行結果檢查、用戶中斷與恢復邏輯

開發者整合與跨品牌互通性

對於第三方軟體開發者而言,與代理型作業系統整合需要轉向結構化、機器可讀的工具契約。Honor 開發者生態系統透過 Honor Agent Platform 提供程式化存取,支援包括透過 StreamableHTTP 或伺服器發送事件 (SSE) 通訊的 MCP 伺服器外掛程式整合,以及標準 API 外掛程式與系統自動化介面。

當應用程式透過標準化架構公開其功能時,它會向作業系統規劃器提供類型化的參數說明、所需的輸入限制與執行要求。這使得系統代理能夠透過後端服務綁定器或網路端點乾淨地分派請求,而無需依賴脆弱的螢幕自動化。

// 概念性參考設計 — 非執行性 Honor SDK 範例:
// 以下 Kotlin 範例展示了應用程式端架構驗證、狀態冪等性以及人機協作 (HITL) 確認概念,用於代理型工具執行。
// 它並未實作 Honor 的專有 YOYO SDK 或 MCP 伺服器協定,且不應直接作為整合實作使用。

package com.example.platform.agent.tools

import android.content.Context
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import org.json.JSONObject
import java.util.UUID

// MARK: - 工具參數與執行契約
data class BookingParameters(
    val serviceId: String,
    val appointmentTimestamp: Long,
    val clientMutationToken: String,
    val requiresHighValueConfirmation: Boolean
)

sealed class ToolExecutionResult {
    data class Success(val transactionId: String, val message: String) : ToolExecutionResult()
    data class RequiresUserConfirmation(val confirmationPrompt: String, val pendingToken: String) : ToolExecutionResult()
    data class Failure(val errorCode: String, val errorMessage: String) : ToolExecutionResult()
}

// MARK: - 標準化代理工具提供者
class AppointmentBookingTool(private val context: Context) {

    companion object {
        const val TOOL_NAME = "schedule_appointment"
        const val TOOL_DESCRIPTION = "以驗證的狀態冪等性預約服務。"
        private const val MAX_VALID_ADVANCE_DAYS = 90L
    }

    // 公開說明性 JSON 架構以展現結構化工具定義
    fun getToolDefinition(): JSONObject {
        return JSONObject().apply {
            put("name", TOOL_NAME)
            put("description", TOOL_DESCRIPTION)
            put("parameters", JSONObject().apply {
                put("type", "object")
                put("properties", JSONObject().apply {
                    put("serviceId", JSONObject().apply {
                        put("type", "string")
                        put("description", "目標服務的唯一識別碼。")
                    })
                    put("appointmentTimestamp", JSONObject().apply {
                        put("type", "integer")
                        put("description", "預約的紀元時間戳(毫秒)。")
                    })
                    put("clientMutationToken", JSONObject().apply {
                        put("type", "string")
                        put("description", "持久性 UUID,確保代理重試期間的冪等執行。")
                    })
                })
                put("required", org.json.JSONArray().apply {
                    put("serviceId")
                    put("appointmentTimestamp")
                    put("clientMutationToken")
                })
            })
        }
    }

    // 在隔離的協程上下文中執行工具
    suspend fun execute(rawArgumentsJson: String): ToolExecutionResult = withContext(Dispatchers.IO) {
        val params = try {
            parseAndValidateParameters(rawArgumentsJson)
        } catch (e: IllegalArgumentException) {
            return@withContext ToolExecutionResult.Failure(
                errorCode = "ERR_INVALID_SCHEMA",
                errorMessage = e.message ?: "參數驗證失敗。"
            )
        }

        // 防禦性冪等檢查:防止規劃器重試期間出現重複的副作用
        if (IdempotencyManager.isTokenProcessed(params.clientMutationToken)) {
            val existingId = IdempotencyManager.getTransactionId(params.clientMutationToken)
            return@withContext ToolExecutionResult.Success(
                transactionId = existingId ?: "UNKNOWN",
                message = "動作已在先前的執行週期中完成。"
            )
        }

        // 安全閘道:針對高影響力限制強制實施人機協作 (HITL) 確認
        if (params.requiresHighValueConfirmation) {
            return@withContext ToolExecutionResult.RequiresUserConfirmation(
                confirmationPrompt = "確認服務 ${params.serviceId} 在 ${params.appointmentTimestamp} 的預約嗎?",
                pendingToken = params.clientMutationToken
            )
        }

        // 領域執行:執行實際的業務變更
        return@withContext try {
            val transactionId = UUID.randomUUID().toString()
            
            // 提交變更至本地資料庫或遠端服務
            BackendBookingService.commitBooking(
                serviceId = params.serviceId,
                timestamp = params.appointmentTimestamp,
                txId = transactionId
            )

            // 記錄變更權杖以保證後續冪等性
            IdempotencyManager.recordToken(params.clientMutationToken, transactionId)

            ToolExecutionResult.Success(
                transactionId = transactionId,
                message = "預約成功。"
            )
        } catch (e: Exception) {
            ToolExecutionResult.Failure(
                errorCode = "ERR_BACKEND_REJECTION",
                errorMessage = e.localizedMessage ?: "無法執行遠端服務的預約。"
            )
        }
    }

    private fun parseAndValidateParameters(jsonString: String): BookingParameters {
        val json = JSONObject(jsonString)

        val serviceId = json.optString("serviceId")
        require(serviceId.isNotBlank()) { "參數 'serviceId' 不得為空白。" }

        val timestamp = json.optLong("appointmentTimestamp", -1L)
        val currentEpoch = System.currentTimeMillis()
        val maxFutureEpoch = currentEpoch + (MAX_VALID_ADVANCE_DAYS * 24 * 60 * 60 * 1000)
        
        require(timestamp > currentEpoch) { "預約時間戳必須在未來。" }
        require(timestamp < maxFutureEpoch) { "無法預約超過 $MAX_VALID_ADVANCE_DAYS 天後的服務。" }

        val mutationToken = json.optString("clientMutationToken")
        require(mutationToken.isNotBlank()) { "需要持久性的 'clientMutationToken'。" }

        // 動態風險評估:標記優質服務的範例業務規則
        val isHighValue = serviceId.startsWith("PREMIUM_")

        return BookingParameters(
            serviceId = serviceId,
            appointmentTimestamp = timestamp,
            clientMutationToken = mutationToken,
            requiresHighValueConfirmation = isHighValue
        )
    }
}

// MARK: - 支援型 Mock 基礎設施
object IdempotencyManager {
    private val processedTokens = mutableMapOf<String, String>()

    @Synchronized
    fun isTokenProcessed(token: String): Boolean = processedTokens.containsKey(token)

    @Synchronized
    fun getTransactionId(token: String): String? = processedTokens[token]

    @Synchronized
    fun recordToken(token: String, txId: String) {
        processedTokens[token] = txId
    }
}

object BackendBookingService {
    fun commitBooking(serviceId: String, timestamp: Long, txId: String) {
        // 模擬資料庫寫入或認證後的遠端 API 調度
    }
}

除了軟體代理整合外,MagicOS 11 還解決了多裝置互通性。Honor 與主流 Android OEM 合作建立了統一的跨品牌「Tap-to-Share」技術標準,透過支援裝置間的觸碰發起互動,實現鄰近檔案共享。

官方發表會簡報展示跨品牌 Tap-to-Share 以及 Apple 生態系統互通性,包含 iPhone 通話與訊息同步

此外,該平台透過 Honor Connect 擴展跨生態系統連續性,實現檔案在支援的 iPhone、iPad 與 Mac 裝置間傳輸(包含在支援的 iPhone 上透過 NFC 發起的觸碰傳輸),以及與支援的 Apple 端點進行通知共享。

常見問題 (FAQ)

YOYO Harness 與早期語音助理的主要區別是什麼?
早期行動語音助理主要依賴預定義的語法領域與剛性的意圖解析器,執行如設定鬧鐘或開啟特定應用程式頁面等單輪動作。MagicOS 11 中的 YOYO Harness 則作為多階段編排控制平面運作。它詮釋不受限的自然語言目標、執行多步驟任務規劃、在可用時選擇結構化工具,並在必要時跨越應用程式邊界回退至 GUI 調解互動。
為何 MagicOS 11 實作雙軌執行模型,而非完全依賴 GUI 自動化?
完全依賴電腦視覺與 GUI 自動化(「電腦使用」)會引入顯著的處理延遲、更高的功耗,且容易受到視覺介面重新設計的影響。反之,僅依賴結構化 API 會將代理程式的效用限制在已部署專用外掛程式的應用程式上。將結構化協定(MCP、Skills 與系統 API)作為主要路徑,並結合 GUI 基礎作為動態回退方案,通常能在有結構化介面時提高參數精度、執行效率與可觀察性,同時在舊有軟體上保持廣泛的操作覆蓋範圍。
代理型作業系統架構如何防止未經授權或具破壞性的動作?
穩健的代理架構應結合基於策略的授權與針對高影響力變更的明確用戶確認。根據平台與動作的不同,確認可能涉及系統對話框、憑證、生物辨識或其他受信任的互動機制。雖然 Honor 已記錄第三方 GUI 控制宣告並強調敏感場景治理,但所有執行類型中精確的系統級授權管線仍屬專有技術。

戰略意義與平台展望

Honor 對 MagicOS 11 的商用部署反映了行動裝置軟體更廣泛的演進轉變。隨著矽晶圓節點、顯示面板與鏡頭模組的硬體差異化達到邊際遞減,作業系統的差異化正轉向系統級自主編排。

雖然多步驟複合錯誤率、介面漂移與跨平台隱私治理等技術挑戰仍是活躍的工程前沿,但系統級框架已確立了未來終端智慧運作的基礎。對於行動工程團隊而言,使命明確:應用程式必須從被動的圖形容器轉變為結構化、具備權限意識的工具提供者,旨在自主多代理作業環境中順暢運作。

參考資料

Share this article