三個介面：人類、Apple Intelligence、代理

在iOS 26+上，iOS應用程式中每項有意義的功能,如今最多面對三個可被呼叫的介面。同一個記錄一杯水的Swift函式,可以由人類點擊按鈕觸發,可以由Apple Intelligence路由Siri請求觸發,也可以由外部代理(Claude Code、Cursor、ChatGPT)透過呼叫MCP工具觸發。三種不同的呼叫者、三種不同的義務、三種不同的渲染介面。能力相同;介面則不然。

許多iOS架構錯誤,源於只為單一介面設計,然後硬將該能力套用到其他介面上。UI流程滲入Siri回應;對開發者正確的代理工具,對終端使用者卻成為危險;裝置端LLM功能假設了雲端等級的脈絡。本系列文章已分別在各篇文章中描繪這些介面。本篇文章是綜合整理:三個介面、它們的差異、路由規則,以及應用程式的領域層需要長成什麼樣子,才能在不犧牲任何介面的前提下服務三者。

心智模型如下:挑一項領域能力。問三個介面中哪些應該能呼叫它。問哪些實際上能呼叫。問每個介面對該能力的需求是什麼,以及該能力對它們的回饋是什麼。答案會塑造架構。

TL;DR

• 三個介面:人類(SwiftUI檢視、點擊、手勢、螢幕)、Apple Intelligence(App Intents、Siri、Shortcuts、Spotlight)、代理(MCP伺服器、外部LLM主機)。
• 每個介面有不同的義務:信任姿態、延遲預算、渲染位置、持久化語意、錯誤處理、無障礙需求。
• 正確的架構是讓領域層位於各介面之下。每個介面都是同一組Swift函式之上的薄層轉接器;函式接受一個型別化的Caller參數,讓它能依據跨介面的規則(速率限制、稽核、確認動作)做分支,而不需了解介面協定的細節。
• 並非每項能力都服務三個介面。決定哪個介面才是設計層面的判斷。把能力對不該擁有它的介面隱藏起來,和把能力暴露給該擁有的介面同等重要,都是產品決策。

介面一:人類

人類介面就是螢幕。使用者注視應用程式、點擊、捲動、拖曳、滑動、輸入。框架是SwiftUI(或UIKit,或某些工作負載下visionOS的RealityKit)。渲染發生在使用者的裝置上、應用程式行程中,以使用者選擇的色彩配置、動態字型大小與無障礙設定為準。¹

人類介面對能力的需求:

• 視覺可供性。按鈕、列表列、滑動手勢、情境選單。能力必須能透過應用程式導覽被發現,並與其他UI樣式一致。
• 即時回饋。每一次互動都需要立即可見的回應。觸發長時間執行操作的按鈕,必須顯示進度指示器、啟用/停用狀態與動畫。
• 無障礙。VoiceOver標籤、動態字型支援、色彩對比、運動控制替代方案。人類介面是無障礙需求最嚴苛的介面,因為使用者直接與渲染互動。
• 錯誤可見性。錯誤會出現在使用者的視野中。儲存失敗顯示警示;網路逾時顯示重試;權限拒絕顯示設定連結。

人類介面對能力的回饋:

• 無歧義的使用者意圖。使用者點擊了特定按鈕;能力清楚知道請求的是什麼。沒有推論層。
• 緊湊的延遲預算。點擊後若超過數百毫秒才有可見回應,就會感覺壞掉。能力必須要快,或必須設計成能立即顯示進度。
• 沒有外部權威。使用者在應用程式內;使用者就是代理(以最寬鬆的意義來說,人類在驅動動作)。沒有第三方LLM、沒有系統代理,只有使用者的雙手。

人類介面是三者中歷史最悠久的。自iOS 7以來,平台累積的所有iOS框架、設計模式與無障礙規則,都是為了服務這個介面。另外兩個介面太新,模式都還在沉澱當中。

介面二:Apple Intelligence

Apple Intelligence介面是系統代理。Siri、Shortcuts、Spotlight、系統建議堆疊。使用者說話、輸入到Spotlight,或在Shortcuts中串接動作;系統透過App Intents框架路由請求,找出符合的AppIntent,解析參數,然後執行該意圖的perform()主體。框架是App Intents。²

Apple Intelligence介面對能力的需求:

• 型別化的綱要。AppIntent型別宣告@Parameter屬性;AppEntity型別為系統可以談論的事物提供持久化身分;AppEnum型別為封閉的選項集合命名。系統在安裝時讀取綱要。
• 能在應用程式行程結束後仍存活的身分。使用者昨天透過Siri記錄的喝水資料,今天應該還能透過Siri被引用。AppEntity模型給系統一種跨工作階段穩定談論物件的方式。
• 靜默的錯誤處理。錯誤不會出現在使用者的視野中;它們會出現在Siri回應、Shortcuts輸出或Spotlight結果中。系統期待的錯誤格式是結構化的(Apple的AppIntentError加上符合LocalizedError的拋出),而非視覺化。
• 重試下的冪等性。系統可能在Shortcut鏈中或部分失敗後重新呼叫一個意圖。會改變狀態的能力需要在重複呼叫下安全,或要明確呈現「已完成」的語意。

Apple Intelligence介面對能力的回饋:

• 使用者的真實身分。系統知道使用者是誰,已透過OS驗證,並在他們的脈絡中執行意圖。能力不需要在OS提供的之外再驗證身分。
• 系統層級的渲染。意圖回傳的結果會被系統格式化成適當的外觀(鎖定畫面橫幅、Siri回應卡、Shortcuts輸出)。應用程式無法控制回應如何呈現。
• 不需執行你的程式碼即可被發現。App Intents可以在你的應用程式未執行時被呼叫。系統讀取綱要並主動呈現該能力。

信任姿態:Apple Intelligence是Apple的第一方代理。使用者不需設定它;系統設定。使用者信任OS;OS信任你的應用程式透過審核所提交的App Intents綱要。信任鏈是OS → 應用程式。App Intents確實支援requestConfirmation(...)與前景模式確認,所以需要「您確定嗎?」的能力技術上可以放在這裡;產品判斷(而非平台限制)決定了高風險確認該屬於Siri對話內,還是該屬於應用程式自身的螢幕。任何不可逆的事(刪除帳戶、破壞性的批量編輯、付款)通常即使App Intents能請求確認,放在人類介面上仍然較安全。³

介面三:代理

代理介面是所有其他想要操作應用程式領域的LLM驅動系統。Claude Desktop、Claude Code、Cursor、ChatGPT桌面應用程式、Codex CLI、自製代理框架。框架是Model Context Protocol:MCP伺服器透過JSON-RPC tools/call方法暴露應用程式的領域;主機LLM在工作階段開始時發現工具,並以名稱呼叫,附帶JSON負載。⁴

代理介面對能力的需求:

• JSON-RPC合約。工具名稱、描述、inputSchema、選用的outputSchema。代理讀取描述以決定是否呼叫;它依循綱要來格式化引數。
• 有用的描述。模型基於描述來決定何時使用工具。把描述當成你預期另一位開發者(模型)會閱讀的docstring。模糊的描述會導致錯誤的工具選擇。
• 兩種形態的錯誤。工具執行錯誤以內容區塊加上isError: true的形式回傳於工具結果中,讓模型讀取。協定層級的錯誤(請求格式錯誤、缺少工具、傳輸失敗)以標準的JSON-RPC error回應形式回傳,由主機處理。工具作者擁有第一種;協定擁有第二種。
• 無狀態或明確有狀態的語意。MCP在協定層是有狀態的(工作階段生命週期、Streamable HTTP中的工作階段ID),但持久化的領域身分是伺服器端的責任,不是協定層級的保證。如果同一個識別符在跨工作階段時應指相同的事物,伺服器必須執行該保證。

代理介面對能力的回饋:

• 主機的驗證,而非使用者的。信任來自部署MCP伺服器的人。開發者本機的stdio:開發者自己的檔案系統權限。可從網際網路存取的HTTP:伺服器執行的任何驗證機制。能力必須假設身分聲明就是伺服器給予的。
• 可變的延遲容忍度。主機可以等比人類介面或Apple Intelligence介面更久。一個花費三十秒的工具呼叫在代理介面是可接受的,但在其他介面上不可接受。
• 無渲染介面。結果是模型解讀的文字或結構化資料。沒有外觀、沒有UI、沒有系統格式化。

信任姿態:MCP伺服器是開發者的合約,規定誰能呼叫它。同一個伺服器的兩種部署(開發用本機stdio、終端使用者用網際網路HTTP)有極不同的信任姿態,需要極不同的防護措施。協定相同;部署才是架構。詳細討論見App Intents vs MCP: The Routing Question與When the LLM Lives in Your App vs in Your Tooling。⁵

三個介面意見分歧的六個面向

把三個介面拉進比較表格,讓架構決策變得具體:

這些分歧會疊加。為人類介面設計的能力假設了緊湊延遲、豐富渲染、應用程式管理的錯誤。硬套到Apple Intelligence會失去渲染控制權,並加上OS中介的身分。硬套到代理介面則完全失去渲染,並把信任邊界轉移到部署伺服器的人身上。能力必須被重新塑形,而不只是重新包裝。

架構規則:領域層位於介面之下

橫跨三個介面而留存的模式,是位於它們之下的領域層。領域層是純粹的Swift函式:型別化輸入、型別化輸出、無協定假設。每個介面都是領域之上的薄層轉接器。同一個logWater(amount:caller:)函式同時支撐SwiftUI按鈕、App Intent的perform(),以及MCP工具的處理器。

草圖如下(實際生產環境會讓WaterEntry符合AppEntity以便App Intent回傳、把domain作為依賴注入而非頂層引用,並在意圖中加上必要的static var title):

// Domain layer (the actual capability)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter A: human surface (SwiftUI button)
Button("Log 250ml") {
    Task {
        let entry = try await domain.logWater(
            amount: .init(value: 250, unit: .milliliters),
            at: .now,
            caller: .human
        )
        // Update view state, show confirmation animation, etc.
    }
}

// Adapter B: Apple Intelligence surface (AppIntent)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>
    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)  // WaterEntry conforms to AppEntity
    }
}

// Adapter C: agent surface (MCP tool handler)
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

三位呼叫者。一個領域函式。領域函式接受一個Caller參數,讓它能依不同介面執行不同規則(速率限制、稽核紀錄、確認需求),而不需每個介面各自重新實作。轉接器是笨的;領域才是聰明的。

這個形狀把App Intents vs MCP中的雙重轉接器模式進一步推廣;把人類介面加為第三類呼叫者是自然的延伸。Foundation Models裝置端LLM在應用程式內被使用時,位於人類介面上(使用者呼叫了一個應用程式內的功能,而該功能恰好呼叫模型);執行階段LLM不是第四個介面,它是執行原本就屬於人類介面之能力的方式。⁶

並非每項能力都服務三個介面

均等暴露不是目標。不同的能力屬於不同的介面。

通常需要前景人類在場的能力。拍照、生物辨識驗證、敏感PII輸入、付款確認、刪除帳戶。人必須注視螢幕、必須同意、必須驗證。Apple Intelligence技術上可以將應用程式帶到前景並請求確認;代理介面則沒有等價的在場保證。產品判斷是,這些能力應以前景UI搭配明確的審慎動作執行,而非靜悄悄的Siri或背景工具呼叫。

該住在人類 + Apple Intelligence介面的能力。多數面向使用者的動作。記錄喝水、開始冥想、在清單中加入項目、顯示我週二的紀錄。使用者可能點按鈕,也可能說「Hey Siri」。兩個介面都是有效的;兩者都應通向同一個領域函式。

該住在三個介面上的能力。跨行程整合。一個跨使用者iPhone與會匯入食譜的Claude Code工作階段共享的購物清單。人類介面負責日常使用;Apple Intelligence介面負責Siri/Spotlight觸達;代理介面負責由開發者或使用者驅動的外部工作流。

只該住在代理介面的能力。沒有終端使用者審核流程的開發者或管理員批量匯入、與外部系統的整合、沒有Siri或應用程式內表現的代理協作工作流。在一次性回填中,從開發者CSV批量匯入500筆歷史紀錄。終端使用者的檔案匯入往往有人類介面的流程(Shortcuts可傳遞檔案;應用程式內匯入器可分塊呈現進度);僅限代理介面的情境,是真正在另兩個介面上沒有任何位置的工作流。

決策即設計。列出能力不服務的介面,和列出它服務的介面同等重要。

我會用什麼方式重新打造

兩個本系列應用程式已經出貨,或希望已經出貨的模式。

將Caller設為領域層的一級型別。每個公開的領域函式都接受一個Caller參數。型別編碼是哪個介面發出呼叫(.human、.siri、.mcp(host:))。領域邏輯依此分支,以決定確認提示、速率限制、稽核紀錄與敏感動作門檻。替代方案(每個介面各自重新實作規則)會偏移;集中化版本則保持一致。

將介面覆蓋視為明確的檢核清單。新增能力時,設計文件列出三個介面中哪些該暴露、哪些該拒絕。拒絕清單不是預設;它是有意的選擇。拒絕:Apple Intelligence介面,因為該能力需要Siri無法提供的使用者注意力證明。推理被記錄下來;之後的稽核會抓出偏移。

此模式對iOS 26+上出貨的應用程式意味著什麼

三個重點。

1. 三個介面、三種信任姿態。人類、Apple Intelligence、代理。每個介面都有其他介面沒有的義務。為其中一個設計然後硬套到其他介面上,會在每個介面上產生糟糕的架構。

2. 領域在下;轉接器在上。每項能力一個Swift函式;每個介面一個薄層轉接器;函式接受一個Caller參數,以便在單一位置執行介面特定規則。

3. 並非每項能力都服務三個介面。把能力對不該擁有它的介面隱藏起來,和把它暴露同等重要,都是設計決策。拒絕清單有其價值。

完整的Apple Ecosystem系列:為Apple Intelligence介面設計的型別化App Intents;為代理介面設計的MCP伺服器;兩者之間的路由問題;用於人類介面內裝置端LLM功能的Foundation Models;執行階段與工具LLM的區分;用於iOS鎖定畫面狀態機的Live Activities;Apple Watch上的watchOS執行階段合約;人類介面底層基質的SwiftUI內部;visionOS場景的RealityKit空間心智模型;跨介面持久化的SwiftData綱要紀律;人類視覺層的Liquid Glass模式;跨裝置觸達的多平台出貨。中樞位於Apple Ecosystem系列。如需更廣泛的「iOS搭配AI代理」脈絡,請參見iOS Agent Development指南。

FAQ

iOS應用程式的三個介面是什麼?

人類介面(SwiftUI檢視、點擊、手勢、螢幕)、Apple Intelligence介面(App Intents、Siri、Shortcuts、Spotlight),以及代理介面(暴露給外部LLM主機如Claude Code、Cursor、ChatGPT的MCP伺服器)。每個介面都有自己的呼叫者身分、延遲預算、渲染位置、持久化語意與信任姿態。想服務多個介面的能力,應該位於每個介面薄層轉接器之下的領域層上。

是否每項能力都該暴露給三個介面?

不。某些能力適當地僅限於一兩個介面。拍照、生物辨識驗證與敏感動作確認,通常最好作為前景人類介面流程,因為信任訊號(使用者注意力、審慎動作)在那裡最可靠地存在。當沒有終端使用者審核流程時,開發者驅動的批量操作只屬於代理介面。設計判斷是能力服務哪些介面、又拒絕哪些介面。

Apple Intelligence與代理介面的差別是什麼?

Apple Intelligence是Apple的第一方代理:使用者呼叫Siri、Shortcuts或Spotlight;系統透過App Intents路由。信任來自OS。代理介面是其他所有的LLM主機:開發者執行Claude Code或Cursor,終端使用者執行Claude Desktop或ChatGPT。信任來自部署MCP伺服器的人。App Intents是前者的協定介面;MCP是後者的協定介面。

裝置端Foundation Models LLM放在哪裡?

在人類介面內。當使用者呼叫一個會呼叫Foundation Models的應用程式內功能時,執行階段LLM是人類介面能力的實作,而非第四個介面。執行階段LLM本身沒有Siri或外部主機呼叫者。Foundation Models工具是裝置端模型讀寫應用程式領域狀態的方式;使用者才是驅動呼叫的人。

領域層模式如何簡化多介面程式碼?

藉由集中規則。一個Swift函式接受一個Caller參數,並在單一位置執行介面特定的行為(確認提示、速率限制、稽核紀錄)。每個介面都是薄層轉接器(SwiftUI繫結、AppIntent.perform、MCP處理器),負責把該介面的協定翻譯為領域函式。各介面之間的偏移變得不可能,因為只有一個事實來源。

參考資料