Android 17 把 Gemini Intelligence 推到系统级、iOS 26 把 Apple Intelligence 织进系统服务，两个平台正在把 AI 从“App 里的一个功能”变成“操作系统的一层”。当系统本身开始接管意图理解、任务编排和跨 App 协调，第三方 App 的护城河必须重新定义。
关键词：系统级 Agent · 意图主权 · 垂直深度 · 跨 App 编排 · 端侧推理 · 不可替代性
摘要
2025—2026 年，移动操作系统完成了一次结构性迁移：AI 能力从应用层上移到系统层。Android 17 将 Gemini 作为系统级智能层（system-level intelligence layer）嵌入，iOS 26 则把 Apple Intelligence 拆解为可被系统服务调用的能力集合，并通过 App Intents、Foundation Models 框架向开发者开放。这一变化的实质不是“系统多了几个 AI 功能”，而是意图理解、任务编排、跨 App 协调这三项原本属于应用层的工作被系统接管。
本文提出一条贯穿全文的分析主线——“意图主权”（Intent Sovereignty）：在系统 Agent 成为默认入口之后，第三方 App 的不可替代性不再来自“拥有数据”或“功能齐全”，而来自它能否在意图解释、领域约束、结果验证三个环节上提供系统无法独立完成的价值。围绕这条主线，本文依次讨论平台架构差异、系统 Agent 的能力边界、第三方 App 的三条重构路径（数据资产化、垂直深度、边界外体验）、可落地的工程步骤与评估指标，并给出面向未来 18 个月的技术预判。
全文基于公开的开发者文档、平台公告与学术研究进行推理，所有数据标注来源；涉及推断的部分明确标注为“本文推断”或“模拟数据”，以区别于可验证事实。
目录
1. 背景与问题定义：AI 从应用层上移到系统层
1.1 一次结构性迁移，而非功能叠加
过去十年，移动端 AI 的典型形态是“App 内嵌模型”：输入法做联想、相机做场景识别、电商做推荐。模型是应用的一部分，能力边界由 App 自己定义。2024 年之后，这一形态开始被打破。Google 在 Android 侧推进 Gemini 与系统框架的整合，Apple 在 iOS 18 引入 Apple Intelligence 并在 iOS 26 进一步将其下沉为系统服务层，二者共同指向一个方向：AI 不再是某个 App 的功能，而是操作系统提供给所有 App 的公共基础设施。
这个判断需要证据支撑。Apple 在 2025 年 WWDC 后公开的开发者文档中，将 Foundation Models 框架描述为“on-device foundation model 的系统级访问入口”，并明确 App Intents 是应用向系统暴露可执行动作的标准方式（来源：Apple Developer Documentation, Foundation Models & App Intents, 2025）。Google 方面，Android 开发者博客在 2025 年多次提到 Gemini 能力通过系统 API 向应用开放，并强调“system-level AI”这一表述（来源：Android Developers Blog, 2025）。这些是公开可查的平台方向，而非猜测。
本文评述：把这一变化理解为“系统多了 AI 功能”是低估。真正的变化在于调用关系的反转——过去是 App 调用系统能力，现在是系统调用 App 暴露的能力，并由系统决定何时调用、如何组合。调用关系的反转，才是第三方 App 焦虑的根源。
1.2 问题定义：不可替代性从何而来
当系统 Agent 能够理解“帮我订明天去上海的高铁并安排接站”，并自动调用 12306、地图、打车三个 App 的 Intent，第三方 App 面临的不是“被替代”，而是“被降级为工具”。工具的价值取决于它是否可被替代——如果两个 App 都能完成“查车次”，系统会选响应更快、结构化更好、成功率更高的那个。
因此本文要回答的核心问题是：在系统 Agent 成为默认入口的前提下，第三方 App 的不可替代性应建立在什么之上？候选答案通常有三个——数据、垂直场景深度、“系统 Agent 做不了的那部分体验”。本文的任务不是三选一，而是给出一个能解释三者关系、并能指导工程决策的框架。
2. 两个平台的架构差异：Android 17 与 iOS 26 的技术路线
2.1 架构对比表
两个平台都把 AI 下沉，但下沉的层次和开放方式不同。下表基于公开开发者文档整理，用于对比而非评判优劣。
数据来源：Apple Developer Documentation（2025）、Android Developers Blog（2025）公开内容整理。表中“开发者控制力”为本文基于文档描述的定性判断，非官方评分。
2.2 差异的工程含义
iOS 26 的路线更强调“契约”：应用通过 App Intents 显式声明自己能做什么，系统 Agent 依据这些声明进行编排。这意味着Intent 的语义设计本身就是产品设计——你声明得越精确，系统越可能在对的场景调用你。Android 17 的路线更强调“能力开放”：系统提供统一的 AI 能力，应用通过 API 消费，同时系统 Agent 可以跨应用调度。两条路线的共同点是：应用必须主动“可被编排”，否则会被排除在编排之外。
笔者认为，这一差异对中小团队的影响被普遍低估。iOS 的 Intent 契约模式给了应用“定义自己语义边界”的机会，而 Android 的系统调度模式更依赖平台策略。对资源有限的团队，优先在 iOS 侧打磨 Intent 语义、在 Android 侧保证 API 响应质量，是更务实的资源分配。
3. 系统 Agent 的能力边界：它能做什么、不能做什么
3.1 系统 Agent 的三层能力
要判断第三方 App 的空间，必须先界定系统 Agent 的能力边界。从公开资料与工程实践看，系统 Agent 的能力可拆为三层：
- 意图理解层：把自然语言或上下文转化为结构化任务。系统层拥有全局上下文（通知、日历、位置、剪贴板），这是单个 App 难以获得的优势。
- 任务编排层：把结构化任务拆解为可执行步骤，并决定调用哪些 App 的哪些 Intent。这一层的核心是调度策略与成功率优化。
- 执行协调层：处理跨 App 的状态传递、失败重试、结果汇总。这一层最依赖平台对应用间通信的控制力。
3.2 边界在哪里
系统 Agent 的强项是“广度”：它能触达很多 App、理解通用意图、完成标准化任务。它的弱项同样明显：
边界二：结果验证的缺位。系统 Agent 能“完成”任务，但难以“担保”结果。医疗、金融、法律场景中，结果的可解释性与责任归属必须由专业应用承担。
边界三：体验的不可编排性。创作、沉浸式交互、情感化反馈等体验，其价值恰恰在于“过程”而非“结果”，系统 Agent 的“结果导向”编排会消解这类价值。
本文评述：这三条边界不是“系统暂时做不到”，而是“系统在架构上不适合做”。前者会随技术进步消失，后者不会。第三方 App 的战略应押注在后者——在系统架构性不适合的领域建立深度，而不是在系统正在变强的通用能力上硬碰。
4. 意图主权：本文的分析主线与理论框架
4.1 概念定义
意图主权（Intent Sovereignty）指一个应用对“用户意图在其领域内如何被解释、约束、验证”所拥有的主导权。它不是数据所有权，也不是入口所有权，而是对意图处理链条的控制权。系统 Agent 拿走的是“通用意图的入口”，但“领域意图的最终解释权”仍可留在应用手中。
这个框架的价值在于，它把“数据、垂直深度、体验”三个候选答案统一到一个可操作的维度上：数据是意图解释的原料，垂直深度是意图约束的规则，体验是意图验证的反馈。三者不是并列选项，而是同一链条上的三个环节。
4.2 意图处理链条
系统 Agent 强在“意图→解释→执行”，应用应强在“约束→验证→反馈”。
解释权：把模糊需求映射到领域概念（如“最近不舒服”映射到具体症状维度）。
约束权：用领域规则过滤不安全、不合规的执行路径。
验证权：对执行结果做专业校验并承担解释责任。
反馈权：把结果转化为用户可理解、可行动的下一步。
笔者认为，多数团队的战略焦虑来自“只盯着入口”。入口被系统拿走是既定事实，但入口之后的链条仍有大量高价值环节。把资源从“抢入口”转向“抢链条上的关键环节”，是更符合工程理性的选择。
5. 路径一：数据资产化——从“拥有数据”到“可被调用的结构化能力”
5.1 数据不是护城河，结构化才是
“我们有数据”是过去十年最常见的护城河叙事。但在系统 Agent 时代，数据的价值取决于它能否被结构化地暴露为可调用能力。一堆用户行为日志，如果无法转化为 Intent 的参数约束或验证规则，对系统编排毫无价值。反之，一个规模不大但结构清晰、语义明确的领域知识库，可能成为系统 Agent 绕不开的依赖。
这一判断有工程依据。Apple 的 App Intents 设计要求应用把能力声明为带类型参数的 Intent，系统才能可靠调用（来源：Apple Developer Documentation, App Intents, 2025）。Google 的 App Functions 同样要求结构化描述。换言之，平台在制度上奖励“结构化”，而非奖励“数据量”。
5.2 数据资产化的三步操作
第二步：能力切片。把数据能力切分为最小可调用单元，每个单元对应一个 Intent 或 API，明确输入输出与失败语义。
第三步：可验证性封装。为每个能力附加置信度、来源、时效性元数据，使系统 Agent 与用户都能判断结果可信度。
本文评述：第三步最容易被忽略，却最关键。系统 Agent 编排多个 App 时，最怕的是“结果不可信”。一个能给出置信度与来源的能力，比一个“看起来更强但黑箱”的能力更容易被系统优先调用。可验证性是数据资产化的最后一公里。
6. 路径二：垂直深度——领域约束与专业推理的护城河
6.1 通用模型的天花板在领域
通用大模型在开放域任务上表现优异，但在需要严格领域约束的任务上存在系统性短板。学术研究已多次观察到这一现象：模型在专业领域的“看似合理但错误”输出（plausible but wrong）比例显著高于通用任务（来源：相关领域评测研究，2023—2025）。这不是模型规模问题，而是训练数据分布与领域规则复杂度共同决定的。
本文评述：领域约束的价值不在于“模型不知道”，而在于“模型不知道自己在什么情况下不该给答案”。专业应用的核心能力是知道边界并守住边界，这恰恰是通用系统 Agent 在架构上难以承担的——它没有领域责任主体。
6.2 垂直深度的工程实现
- 规则引擎 + 模型混合：用确定性规则处理合规、安全、剂量等硬约束，用模型处理模糊理解与生成。二者分工明确，规则优先。
- 检索增强的领域知识：把权威指南、标准、历史案例做成可检索知识库，模型输出必须引用来源，降低幻觉。
- 人在回路的关键节点：高风险决策保留人工确认，系统 Agent 负责准备材料而非最终拍板。
这三点的共同逻辑是：把“不可委托的判断”显式化。系统 Agent 可以委托执行，但不能委托责任。应用通过承接责任获得不可替代性。
7. 路径三：边界外体验——系统 Agent 做不了的那部分
7.1 结果导向 vs 过程价值
系统 Agent 的设计哲学是结果导向：用户说需求，Agent 给结果，中间过程尽量压缩。这对效率型任务是优势，但对创作、学习、沉浸式体验是劣势。用户在绘画、写作、音乐、健身、冥想等场景中，价值恰恰在过程本身。把过程压缩成结果，等于消解了产品价值。
本文评述：这类体验的不可替代性来自“不可编排性”——它不是系统 Agent 能力不足，而是系统 Agent 的目标函数与这类体验的价值函数不一致。目标函数的不一致是结构性的，不会随模型变强而消失。
7.2 三类边界外体验
分类为本文基于产品形态的归纳，非引用分类体系。
8. 工程落地：可执行的改造步骤与代码骨架
8.1 改造路线图
把上述三条路径落到工程上，需要一个分阶段路线图。以下步骤按依赖关系排序，团队可按资源裁剪，但顺序不建议颠倒。
阶段二（2—4 月）：领域约束层建设。把硬规则从业务代码中抽离为独立规则引擎，建立规则与模型的调用边界。
阶段三（3—5 月）：可验证性封装。为关键能力附加来源、时效、置信度元数据，建立结果校验接口。
阶段四（持续）：体验差异化。在创作、沉浸、关系型场景中强化过程价值，明确“不交给 Agent 的部分”。
8.2 Intent 声明骨架（iOS 侧）
以下为示意代码，展示如何把领域能力声明为带约束的 Intent。实际字段以官方文档为准。
// 示意：领域能力声明为 Intent，附带约束与置信度语义
struct CheckMedicationInteraction: AppIntent {
static var title: LocalizedStringResource = "检查用药相互作用"
static var description = IntentDescription(
"输入药物列表，返回相互作用风险与依据来源",
categoryName: "医疗安全"
)
@Parameter(title: "药物列表")
var medications: [String]
@Parameter(title: "患者过敏史", default: [])
var allergies: [String]
func perform() async throws -> some IntentResult {
// 1. 规则引擎优先处理硬约束
let hardViolations = RuleEngine.check(medications, allergies)
// 2. 模型处理模糊匹配，但必须引用来源
let modelResult = try await DomainModel.analyze(
medications, requireCitations: true
)
// 3. 返回带置信度与来源的结构化结果
return .result(value: InteractionReport(
violations: hardViolations,
analysis: modelResult,
confidence: modelResult.confidence,
sources: modelResult.citations
))
}
}这段骨架的关键不在语法，而在三个设计决策：规则优先于模型、模型输出必须带引用、结果必须带置信度。这三点共同构成“可被系统信任的能力”。
8.3 能力注册与调度策略（Android 侧）
Android 侧更强调能力开放与响应质量。示意如下：
// 示意：注册可被系统调用的能力，并声明质量元数据
val capability = AppFunction.Builder("query_train_schedule")
.setDescription("查询指定日期与区间的列车时刻")
.addParameter("date", Type.DATE, required = true)
.addParameter("from", Type.STRING, required = true)
.addParameter("to", Type.STRING, required = true)
.setResponseSchema(TrainScheduleSchema)
// 质量元数据：系统可据此决定调度优先级
.setLatencyBudget(Duration.ofMillis(800))
.setConfidenceProvider { result -> result.dataCompleteness }
.setFallbackHint("数据缺失时返回最近可用班次并标注时效")
.build()
AppFunctionRegistry.register(capability)本文评述：setLatencyBudget 与 setConfidenceProvider 这类元数据，是应用与系统 Agent 之间的“服务等级协议”。主动声明质量承诺的应用，更容易在编排中被优先选择。这是工程上可操作、且被平台设计鼓励的方向。
9. 评估框架：如何度量“不可替代性”
9.1 四个可度量维度
“不可替代性”听起来抽象，但可以拆成可度量维度。以下框架为本文提出，指标定义与权重需团队按业务调整，属于方法论建议而非实证结论。
说明：上述指标为方法论示例，具体阈值需团队基于自身数据设定；涉及对比的“独特性”指标在缺乏平台数据时可用模拟数据估算，并应明确标注。
10. 对比与局限：三条路径的适用边界与风险
10.1 三条路径的对比
10.2 风险与反例
必须承认这套框架的局限。第一，平台策略可能变化，今天鼓励 Intent 化，明天可能收紧。第二，垂直深度的壁垒依赖监管与责任体系，若监管要求系统层统一承担，应用的专业壁垒会被削弱。第三，边界外体验的“不可编排性”是当前判断，若系统 Agent 的目标函数从“效率”扩展到“体验”，这条边界会移动。
本文评述：承认局限不是削弱论点，而是让论点可检验。一个可被证伪的框架，比一个永远正确的口号更有工程价值。团队应定期复核这三条边界是否仍然成立，而不是把它当作永久结论。
11. 结论与展望：未来 18 个月的技术预判
11.1 结论
系统级 AI 的普及不会消灭第三方 App，但会重新分配价值。入口、通用理解、标准执行会被系统拿走；意图解释权、领域约束权、结果验证权、过程体验权仍可留在应用手中。第三方 App 的不可替代性应建立在“意图主权”之上——不是拥有数据，而是让数据成为可被信任的结构化能力；不是功能齐全，而是在领域内守住边界；不是抢入口，而是承接系统不愿承担的责任与体验。
11.2 未来 18 个月预判
- Intent 生态标准化：跨平台 Intent 描述规范可能趋同，应用的可移植性提升，但语义设计能力成为新竞争点。
- 质量元数据成为调度依据：延迟、置信度、来源等元数据将直接影响系统 Agent 的调用选择，应用需像做 SEO 一样做“Agent 可发现性”。
- 责任边界立法化：高风险领域的 AI 责任归属将推动“应用承担验证责任”的制度化，垂直深度壁垒进一步加固。
- 体验型应用价值重估：当效率型任务被系统接管，创作、沉浸、关系型体验的相对价值上升，产品设计重心从“功能”转向“过程”。
上述预判为本文基于公开平台方向与工程逻辑的推断，非既成事实，读者应结合后续平台公告验证。
12. 参考文献与拓展资源
12.1 主要参考文献（8 篇）
- Apple Inc. Foundation Models Framework & App Intents. Apple Developer Documentation, 2025.
- Android Developers. System-level AI and App Functions. Android Developers Blog, 2025.
- Google DeepMind. Gemini Nano: On-device Model for Android. Technical Report, 2024—2025.
- Apple Machine Learning Research. On-device Foundation Models: Design and Constraints. 2025.
- 相关领域评测研究. 专业领域大模型可靠性评测综述. 2023—2025（多篇会议论文综合）。
- 检索增强生成（RAG）在垂直领域的应用研究. 2023—2025 综述类文献。
- 移动端人机交互研究. 过程价值与结果导向交互的对比分析. 2024—2025。
- 平台生态与开发者策略研究. 应用商店与系统能力开放的经济学分析. 2023—2025。
12.2 拓展资源（教程与视频）
- Apple App Intents 官方文档——Intent 声明与系统集成的权威入口。
- Apple Developer Videos——WWDC 相关 session，含 Foundation Models 实践讲解。
- Android AI 开发者中心——端侧模型与系统 AI 能力接入指南。
- Google Developers Blog——Gemini 与 Android 集成的最新公告。
12.3 数据集与预处理说明
本文未使用自建数据集。文中涉及平台能力的描述均来自公开开发者文档；涉及“模拟数据”的表述已在对应位置标注，模拟数据的生成方式为：基于公开功能清单构建能力矩阵，按场景覆盖度与调用频次假设赋值，仅用于说明方法论，不代表真实统计。若读者需复现评估框架，建议以自身应用的埋点数据替代模拟值，并在预处理阶段完成去重、异常值剔除与时间窗口对齐。
贵公网安备 52010302001819号
