Apple Foundation Models WWDC26 多 Provider 支持：Claude 和 Gemini 接入对工程团队意味着什么

WWDC 2026 上，苹果完成了一项对路由视角的工程团队来说值得关注的架构动作：它把 provider 选择从应用代码中完全抽离出来。Foundation Models framework 现在可以通过一个 Swift LanguageModelSession 调用，把 prompt 路由到本地 Apple Intelligence 模型、苹果的 Private Cloud Compute (PCC)，或者第三方云服务——包括 Anthropic Claude 和 Google Gemini。调用入口不指定哪个后端响应，provider 由外部配置决定。

这个分离本身才是这次更新的核心，不是模型，是架构。

WWDC 2026 带来了什么变化

Foundation Models framework 在 2025 年首次发布，本次新增了三项能力，合力将其变成一个路由层：

第三方服务端模型支持。 任何实现了苹果 LanguageModel 协议的 provider 都可以接入。苹果明确了 Claude 和 Gemini 作为首批示例。无论模型运行在本地还是云端，session API 完全一致。这意味着同一套单元测试、结构化输出解码器、工具调用代码，在切换后端时无需改动。

Dynamic Profiles（动态配置）。 指令、工具和可用能力可以在运行时无需新建 session 直接替换。这是多智能体工作流的基础——不同子任务需要不同模型或不同工具集时，模型可以路由到正确配置，而不需要宿主应用手动编排每次切换。

小开发者免费使用 Private Cloud Compute。 App Store 小企业计划成员、首次下载量不超过 200 万的应用，可以零云端 API 费用使用 Apple Foundation Models on PCC。超出该范围后，云端调用的成本结构将发生变化。

对 AI 工程团队意味着什么

架构转变的核心是：过去在 iOS 应用中接入语言模型，意味着选择一个 provider、集成其 SDK，并将应用逻辑与该 vendor 绑定。现在苹果提供了一层协议级抽象，让 provider 变成一个配置决策。

这带来几个运营层面的影响：

Swift 应用中的 provider 切换成本接近于零。 如果你的 iOS 功能基于 Foundation Models 构建并把 Claude 作为服务端后端，切换到 Gemini（或退回本地）只是配置变更，不需要重构代码。对于正在评估多个 provider、或在 outage 期间需要 fallback 的团队，这一点很重要。

隐私边界变成一个显式的路由决策。 On-device 完全本地运行。PCC 是无状态可验证的，但数据会离开设备。第三方云调用则完全离开苹果的信任边界。这不是实现细节，而是合规和安全团队需要主动管理的数据治理决策。Framework 将这个决策在代码中显式化，比之前"数据发给了某个 API"的隐式方式有明显改进。

结构化输出和工具调用与具体模型解耦。 @Generable 宏和 Swift 类型注解描述输出契约，底层模型负责履行。这意味着 eval 可以面向 schema 契约编写，而不是面向特定模型行为——这个模式在切换 provider 时完全可迁移。

上下文管理和 KV 缓存变成一等公民。 苹果为长会话的语义搜索和上下文管理新增了原语。对于管理长期编码或文档会话的 operator 来说，问题已不再只是"用哪个模型"，而是"上下文在哪里保留、成本是多少、遵循哪些隐私规则"。这些原语让这个决策变得可见和可控。

路由/运营角度的分析

对于通过后端 AI gateway 服务移动客户端的团队，Foundation Models 更新带来了一个新的拓扑问题：路由决策应该放在 iOS 应用层（通过 LanguageModelSession 配置）、后端 gateway、还是两者都有？

实践中通常这样划分：

• On-device 和 PCC：由 Foundation Models 原生处理，没有后端 gateway 介入；适用于隐私敏感或离线场景。
• 第三方云（Claude、Gemini）：可以通过后端 gateway 路由（增加可观测性、账单对账、fallback 和用量归因），也可以直接从设备发出（更简单，但可见性更低）。

如果团队需要统一账单、按 team 分配用量、或者在不发布客户端更新的情况下 A/B 测试 provider，将云端调用通过后端 gateway 而非直连上游 provider，可以提供更强的控制力。这种架构意味着 iOS 端的 LanguageModel 协议实现指向你的 gateway 的 OpenAI-compatible endpoint，而不是直接指向上游 provider。

Fallback 场景值得提前规划。 如果第三方云 provider 不可用，Foundation Models 可以 fallback 到 on-device 或 PCC——但前提是路由配置提前预设了这条路径。硬编码单一第三方 provider 的团队将看到错误；配置了本地 fallback 的团队则能得到降级但可用的行为。

需要持续关注的信号

• 开源时间线。 苹果确认计划在 2026 年夏季晚些时候开源 Foundation Models。届时自定义 provider 的协议实现将公开，企业团队可以为任意兼容 endpoint 编写自己的 LanguageModel adapter。
• 哪些第三方 provider 会发布合规包。 Claude 和 Gemini 已确认。OpenAI 是否会发布 Foundation Models 合规包，目前尚不清楚。
• 第三方后端的上下文保留规则。 苹果自己的 PCC 按设计是无状态的；第三方 provider 有各自的上下文保留策略。在受监管行业运营的团队，在上线前需要验证所选后端的保留行为是否符合数据分类要求。
• 小企业计划阈值以上的 PCC 定价。 苹果尚未公布超出小企业计划范围的 PCC 按调用定价，这个数字将决定 PCC 对中大型应用是否具备与直接调用 provider 竞争的成本优势。

TheRouter 用户可以如何行动

如果你的团队通过 TheRouter 路由 Claude 或 Gemini 调用，Foundation Models 架构与之兼容：iOS 端的 LanguageModel adapter 可以指向 TheRouter 的 OpenAI-compatible endpoint。这样可以在苹果客户端侧抽象层之上，叠加 provider 级 fallback、账单对账和用量归因能力。

实际配置思路：把 Foundation Models 的服务端模型 adapter 目标 URL 指向你的 TheRouter base URL，而不是直接指向上游 provider。请求经过 gateway，gateway 应用路由规则、记录账本条目，并在主 provider 不可用时自动 fallback——对上层 Swift 应用代码完全透明。

查看相关配置起点，可以参考 OpenAI-compatible endpoint 文档。