Apple 在 WWDC26 把 Private Cloud Compute（PCC）上的 Apple Foundation Model 開放給第三方 App。開發者可以用 Foundation Models framework 呼叫具備 32K context 與 Reasoning 的雲端模型，不必自己申請 API key，也不用按 Token 支付雲端 API 費用。
Prompt 不必先送到開發者伺服器，Custom Tool 也不是由 PCC 直接呼叫開發者 API；一次 Agent workflow 會在 App 與 PCC 之間來回。本文從資料實際經過的位置，拆解每一層的責任與隱私邊界。
Private Cloud Compute 是什麼
Private Cloud Compute 是 Apple 為 Apple Intelligence 建立的雲端 AI 運算系統，簡稱 PCC。當 iPhone、iPad 或 Mac 的裝置端模型不足以完成較複雜的工作時，系統可以把處理請求所需的資料加密送到 PCC，利用規模較大的伺服器模型完成推理，再把結果傳回裝置。它不是一般的 iCloud 儲存空間，也不是開發者自行架設的 AI 後端。
雲端模型需要接觸使用者送出的內容，因此 PCC 的設計重點是把雲端端點限制成只能完成當次運算。Apple 為它建立自訂伺服器硬體、精簡的作業系統、Secure Enclave、remote attestation 與公開的 transparency log；節點處理後不保留個人資料，Apple 維運人員也沒有能繞過限制的管理介面。
從 Apple Intelligence 延伸到第三方 App
2025 年推出的 Foundation Models framework 先讓 App 使用裝置端模型；到了 WWDC26，Apple 新增 PrivateCloudComputeLanguageModel，第三方 App 可以透過相同的 LanguageModelSession 使用 PCC。Structured output、@Generable、Custom Tool 與多輪 Session 等既有寫法都能沿用。
| 能力 | 裝置端模型 | PCC 模型 |
|---|---|---|
| 網路需求 | 可以離線 | 必須連網 |
| Context size | 4K；OS 27 部分較新裝置為 8K | 32K |
| Reasoning | 不支援 | Light、Moderate、Deep |
| 使用額度 | 沒有每日請求上限 | 每位使用者有每日額度 |
| API key | 不需要 | 不需要 |
App 是不是直接連到 Apple 的 PCC
是。採用標準 PrivateCloudComputeLanguageModel 流程時，App 透過 Foundation Models framework 把請求交給系統服務，再由系統加密送往通過 attestation 驗證的 PCC 節點。開發者不必在自己的伺服器建立轉送 Prompt 的 API，也不需要把雲端模型的憑證放進 App。
使用者驗證與每日額度綁定 iCloud 帳號，由作業系統處理。開發者伺服器預設不在這條資料路徑上，因此不會因為 App 使用 PCC 就自動取得完整 Prompt、模型回答或使用者的 iCloud 身分。
Apple 管理的服務不等於所有硬體都在 Apple 自有機房
這裡的「直連 Apple」指的是 App 呼叫 Apple 管理的 PCC 服務，而不是承諾每次推論一定使用 Apple 自有資料中心。Apple 已把部分 PCC 能力延伸到 Google Cloud 的 NVIDIA GPU，並表示仍維持 PCC 的加密與驗證保證。不過，Apple 沒有說明第三方 App 的 PrivateCloudComputeLanguageModel 目前會被送到哪一種硬體，也沒有公布這個開發者端點對應 AFM 3 Cloud、AFM 3 Cloud Pro 或其他特定模型。
Custom Tool 是 PCC 直接呼叫開發者伺服器嗎
不是。第三方 App 定義的 Custom Tool 會回到 App 執行。PCC 模型判斷需要 Tool 時，先產生 Tool 名稱與 arguments；Foundation Models framework 收到 Tool Call 後，在 App 內呼叫開發者實作的 Tool.call(arguments:)。Tool 完成工作後，framework 再把 output 傳回 PCC，讓模型繼續推理或生成最終回答。
Tool 可以完全不經過開發者伺服器
Tool.call() 執行的是 App 程式碼，可以查詢 App 內的資料庫、讀取經使用者授權的 Contacts 或 HealthKit、調整介面狀態，也可以使用 WeatherKit 等系統 framework。這些工作如果在裝置端完成，開發者伺服器不會進入資料路徑。
只有 Tool 主動發出網路請求時，開發者後端才會收到資料。例如訂房 App 可以把 PCC 產生的日期、地點與人數傳給自家搜尋 API。後端看得到這些 Tool arguments，但不必取得使用者原本輸入的整段 Prompt。
Tool output 會重新進入 PCC
Tool 回傳的內容會加入 Session transcript，送回 PCC 作為後續模型輸入。這代表開發者仍要控制 Tool output 的資料量與敏感程度，不能因為 Tool 在 App 執行，就把準備傳回 PCC 的內容視為只留在本機。
反過來看，開發者也能把隱私邊界縮得很小：Tool 只向後端傳送完成查詢所需的結構化欄位，再把最少量的結果交給模型。完整 Prompt、iCloud 帳號與 App 裡其他沒有被 Tool 選取的資料，都不需要送往開發者後端。
第三方 App 的 Agent 位於 App 還是 PCC
第三方 App 建立的 agent workflow 沒有位於單一位置。App 掌握自訂 Tool 的實作、產品流程與介面狀態；PCC 執行模型推理，內部也有自己的 workflow orchestration；Foundation Models framework 則負責兩邊的 Prompt、Tool Call、Tool output 與最終回答往返。把它理解成 App 與 PCC 共同完成的流程，比把整個 Agent 塞進其中一端更準確。
App 負責自訂 Tool 與產品流程
App 建立並在執行期間持有 LanguageModelSession，定義 Instructions、Tools、Dynamic Profiles 與介面狀態，也決定何時發出請求、何時停止、發生錯誤後要不要改用裝置端模型。需要 Contacts、HealthKit、檔案或 App 私有資料庫權限的工作，同樣由 App 端 Tool 處理。
PCC 負責模型推理核心
PCC 接收 Session context 與當次 Prompt，執行 Reasoning，判斷是否需要 Tool，產生符合 @Generable schema 的 arguments，再整合 Tool output 生成下一個動作或最後回答。Reasoning 有 Light、Moderate 與 Deep 三種層級；越深入通常需要較長時間，也會占用更多 32K context window。Apple 的安全文件另有一個正式元件名為「PCC Agent」，負責 PCC 內部特定工作流程；它不是本文所稱的第三方 App agent workflow。
它不是長時間常駐的後端 Agent
Tool 必須回到 App 執行，因此這套架構比較適合使用者在 App 內啟動、短時間完成的 Agent workflow。App 被關閉、系統暫停背景執行或網路中斷後，流程通常不能像部署在開發者伺服器上的 Agent 一樣持續工作數小時。需要排程、長時間監控、可靠重試或跨裝置佇列時，仍要由開發者後端負責。
第三方 App 使用 PCC 的資格與費用
PCC 目前不是所有 Apple Developer Program 會員都能直接啟用的公開雲端 API。開發者必須加入 App Store Small Business Program、旗下每款 App 都少於 200 萬次 First-Time Downloads，並向 Apple 申請 com.apple.developer.private-cloud-compute managed entitlement。
First-Time Downloads 是裝置第一次下載 App 的數量，不包含更新與重新下載。Apple 新聞稿使用「total first-time downloads」，PCC 申請頁則寫成「from any of their apps」；實際是否符合資格仍以 entitlement 審核為準。
免 Cloud API 費不等於無限使用
符合資格的開發者不必按 Token 支付 Cloud API 費，但每位使用者每天有 PCC 額度，額度綁定 iCloud 帳號；iCloud+ 訂閱者會有較高額度。Apple 沒公布各層級的確切 request 或 Token 數量，因此 App 必須使用 quotaUsage 檢查接近上限、額度耗盡與重設日期，不能在介面承諾固定次數。
如果 App 後來超過 200 萬次 First-Time Downloads，或開發者不再符合 Small Business Program 資格，Apple 會通知開發者，並提供六個月遷移期。正式產品仍應準備裝置端模型或其他雲端模型作為替代方案。
Foundation Models 程式如何切換到 PCC
已經使用 Foundation Models framework 的 App，只要在建立 Session 時指定 PCC model，Prompt、structured output 與 Tool 寫法不必重做：
import FoundationModels
func findOptions() async throws {
let model = PrivateCloudComputeLanguageModel()
guard model.isAvailable else {
// 改用裝置端模型或顯示替代介面
return
}
let session = LanguageModelSession(model: model)
_ = try await session.respond(
to: "找出符合條件的選項",
contextOptions: ContextOptions(reasoningLevel: .moderate)
)
}PrivateCloudComputeLanguageModel 從 iOS 27、iPadOS 27、macOS 27、watchOS 27 與 visionOS 27 起提供，而且裝置與地區必須支援 Apple Intelligence。PCC 也需要網路連線，正式功能應同時檢查 OS availability、model.availability、網路錯誤與每日 quota。
截至 2026 年 8 月，這套 API 與 entitlement 文件仍標示為 Beta。類別名稱、quota 行為與資格細節在作業系統正式版推出前仍可能調整，準備上線的 App 需要再用正式 SDK 驗證。
PCC 的隱私保證與可驗證範圍
PCC 的重點不是只靠服務條款要求 Apple 不讀取資料，而是讓裝置先驗證節點的硬體身分與軟體量測值（measurement），再把請求加密給符合條件的節點。裝置只會信任已登錄在公開透明度紀錄（transparency log）的正式環境軟體；節點沒有遠端管理 shell，Ephemeral Data Mode 則讓重新開機後的資料無法再解密。
Apple 公開正式環境的 binary（執行檔）、部分安全關鍵原始碼與 Virtual Research Environment，讓研究者檢查實際執行的軟體。PCC Provisioning System 也有 SOC 3 獨立稽核，不過報告只涵蓋節點 provisioning、持續驗證與相關控制流程，不評估 AI 模型表現，也不能解讀成整套 Apple Intelligence 已接受完整的第三方程式碼證明。
PCC 保護不到 App 自己送出的副本
如果 App 在呼叫 PCC 前自行記錄 Prompt、把內容傳給 analytics SDK，或在 Custom Tool 裡送往開發者 API，這些副本位於 PCC 信任邊界之外。PCC 可以保護交給它處理的資料，但無法替第三方 App 約束自己的 logging、資料庫與網路請求。
Apple 的安全文件也保留已知限制，包括流量分析、可觀測性紀錄（observability log）意外包含使用者資料、Virtual Research Environment 無法重現所有正式環境執行路徑，以及公開原始碼不支援可重現建置（reproducible build）。PCC 提供的是可檢查、可限制的雲端隱私架構，不等於所有實作錯誤與旁通道攻擊（side-channel attack）都已經消失。
哪些 App 適合使用 PCC
PCC 適合需要較長 context、較深入 Reasoning，又希望 Prompt 不經開發者後端的互動功能，例如在 App 內分析長文件、根據本機資料規劃行程、使用多個 Tool 完成短流程，或在 Apple Watch 上提供需要雲端模型的助理功能。
如果工作可以由裝置端模型的 context window 完成，裝置端仍有離線、沒有每日 quota，以及在合適工作中避免網路往返的優勢。需要 Android、Web、server-to-server API、長時間背景 Agent、固定吞吐量或完全由開發者控制模型版本時，PCC 也不適合作為唯一後端。
本站的 iOS 27 與 Siri AI 支援整理 介紹了 PCC 在 Apple Intelligence 裡的用途；第三方 App 則多了一層 Tool 與 Agent 控制權。對開發者來說，這個差別比模型跑在哪張 GPU 更實際：Prompt 可以不經自家後端，但 App 仍要為 Tool 的資料流、quota、fallback 與產品生命週期負責。
常見問答
開發者能在自己的伺服器直接呼叫 PCC 嗎
Apple 目前沒有文件化、可讓開發者後端直接呼叫的 PCC cloud API。Foundation Models framework 開源或 macOS 本機工具能使用相關能力，不等於開發者取得 PCC 的 server-to-server endpoint；需要這類呼叫時，仍要改用其他模型供應商或自建服務。
開發者後端預設會收到使用者的 Prompt 嗎
不會。PCC 不會自動把 Prompt 送給開發者後端，Prompt 可以由 App 經系統服務直接送往 PCC。不過，開發者控制的 App 程式仍有能力在送出前讀取、儲存或轉送 Prompt，因此實際隱私還要看第三方 App 的程式與隱私政策。
Custom Tool 可以連開發者 API 嗎
可以。Tool 在 App 端執行，可以使用一般網路 API。PCC 不會直接替 Tool 連線，也不會自動把完整 Prompt 交給後端；送出哪些欄位由 Tool 的程式碼決定。
PCC 的 Agent 能在背景持續執行嗎
不能把它當成常駐的後端 Agent。模型推理位於 PCC，但 Session、Tool 與控制流程仍依賴 App。能否短暫在背景完成工作也受各平台的背景執行規則限制。
參考來源
- Apple Developer：Accessing Private Cloud Compute
- Apple Developer Documentation：Adding server-side intelligence with Private Cloud Compute
- Apple Developer Documentation：Expanding generation with tool calling
- WWDC26：Build with the new Apple Foundation Model on Private Cloud Compute
- Apple Machine Learning Research：Introducing the Third Generation of Apple’s Foundation Models
- App Store Connect Analytics：Metric definitions
- Apple Security Research：Private Cloud Compute Security Guide
- Apple Security Research：Anticipating Attacks
- Apple Private Cloud Compute SOC 3 audit reports