摘要：范式迁移的三个命题
操作系统（Operating System）的历史，是一部「抽象对象不断上移」的历史。每一次范式迁移都不是对上一代的替代，而是在更高的抽象层上重新回答三个问题：系统为谁抽象什么资源、以什么单元进行调度、以及用什么机制建立信任。
命题一 · 抽象对象的上移
iOS 与 Android 把操作系统从「管理机器资源」上移到「管理个人体验」——抽象的是传感器、触控、位置与注意力。Infinite Domain OS 再上移一层：抽象的是企业既有的系统版图、数据语义与组织规则。它不与移动 OS 竞争设备入口，而是坐在企业 15–30 个 Legacy/SaaS 系统之上，把这些系统变成「可选的执行后端」。
命题二 · 调度单元的换代
移动 OS 的调度单元是沙箱化的 App 进程；Domain OS 的调度单元是携带意图、工具与执行策略的 Agent 任务（ReAct 循环 × Tool Calling × Saga 编排）。进程调度关心的是公平与隔离，Agent 调度还必须关心正确性、可逆性与成本——这是全新的调度学。
命题三 · 信任机制的重构
iOS 的信任来自代码签名 + App Review（代码是确定的，签名即可信）；Android 用兼容契约 + 权限模型治理开放生态。Domain OS 面对的是概率性的 AI，信任必须重建在三个新支点上：数字真实性（只取不编）、写安全（R0–R3 分级沙箱）、决策可审计（Agent Trace + 决策快照）。
用一句话概括三个系统：iOS 是出售确定性的体验机器，Android 是出售兼容性的生态机器，Infinite Domain OS 是出售可验证智能的治理机器。前两者解决「人如何使用计算」，第三者解决「组织如何可信地运行智能」。三者处于操作系统概念树的不同分枝，Domain OS 之于企业系统版图，正如移动 OS 之于 PC——不是取代，而是跃迁。
三个系统速览
- XNU 混合内核（Mach + BSD），仅运行于 Apple 芯片
- 信任链：Secure Boot → 代码签名 → App 沙箱 → App Review
- Apple Intelligence：端侧基础模型 + Private Cloud Compute
- Liquid Glass 统一设计语言（iOS/iPadOS/macOS/visionOS 26）
- Linux 内核 + HAL + ART 运行时，Binder IPC
- 治理术：Project Treble（框架/厂商分层）+ Mainline（模块化 OTA）
- CTS/VTS 兼容认证 + GMS 授权作为生态控制点
- Gemini（含端侧 Gemini Nano）成为系统级 AI 层
- 1×Intelligence Platform × N×Domain Pack × ∞×Domain App
- 六层平台（L1 服务 / L2 连接 / L3 语义·知识·分析 / L4 Agent 运行时）+ 两条横切面
- 信任三支柱：数字只取不编 · R0–R3 写安全 · 决策快照审计
- Legacy 桥接：让 15–30 个既有系统变成「可选执行后端」
研究方法、范围与基准系
比对分析的可信度取决于基准系的选择与口径的一致。本章说明本报告的取材来源、比对维度设定，以及为保证「同一把尺子量三个系统」所做的口径约定。
2.1 资料来源与核验方式
| 对象 | 主要资料来源 | 现状核验（2026-08） |
|---|---|---|
| iOS | Apple Developer Documentation（iOS SDK、Platform Security Guide）、Apple Newsroom / WWDC 公告、公开技术分析 | iOS 26 于 2025-09-15 发布；Apple 于 2025 年改用「年份版本号」（iOS 18 直接跳至 iOS 26）；Liquid Glass 为跨 OS 统一设计语言；Apple Intelligence 持续演进 |
| Android | AOSP 官方架构文档（Platform Architecture）、Android 开发者文档、Google I/O 与 Android 版本公告 | Android 16（2025-06-10）开启一年两更节奏；Android 17 于 2026-06-16 发布；全球用户约 39 亿，为全球使用最广泛的操作系统 |
| Infinite Domain OS | 内部权威架构文档：《Architecture Baseline v2.0.0》（对齐 Architecture Overview v2.1.0，Frozen 状态）、《域定义与整体设计 v2.0》、组件蓝图 v1.0.8 系列 | 以 Baseline v2.0.0 为单一事实快照；冲突时以 Overview v2.1.0 为准 |
2.2 七个比对层面与十四个维度
为使「操作系统」这一概念在三种语境下可通约，我们将 OS 定义为「在给定硬件/环境之上，为上层使用者提供资源抽象、调度执行与信任治理的系统层」，并沿七个层面展开，细化为第 7 章的十四维矩阵：
2.3 为什么选择 iOS 与 Android 作为基准系
选择二者并非因为它们与 Domain OS 形似，恰因为它们代表了操作系统工程两种已被验证的极致路线：
- iOS = 垂直整合路线的极致。芯片、内核、框架、分发、审核全部自营，用封闭换确定性——这是 Domain OS「宪法级原则」（每个能力有且只有一个家）的精神源头。
- Android = 开放治理路线的极致。内核开源、厂商联邦、靠兼容契约（CTS/VTS）而非直接控制来维持统一——这是 Domain OS 面对「客户自有 Legacy 系统版图」时必须学会的相处方式。
换言之，Domain OS 的设计张力恰好落在两条路线之间：平台侧需要 iOS 式的集中治理（一套运行时、统一门禁），生态侧需要 Android 式的契约化开放（连接器、域资产包、BYOO 部署）。第 8 章将逐一展示这种继承关系。
操作系统四十年：抽象对象的三次跃迁
在进入三系统深潜之前，先把镜头拉远。操作系统的每一次范式迁移，本质都是「核心抽象对象」的上移：从机器资源，到个人体验，再到组织能力。理解这条主线，才能理解为什么 AI 时代的企业需要一个新的 OS，而不是「给 ERP 加一个 AI 助手」。
| 时代 / 代表 | 核心抽象对象 | 调度单元 | 信任机制 | 交互范式 | 「OS」向用户承诺什么 |
|---|---|---|---|---|---|
| 大型机时代 1960s–80s · OS/360, UNIX | CPU 时间、内存、I/O 设备 | 作业（Job）与进程 | 特权级 / 账户权限 | 批处理、终端命令 | 昂贵的机器被公平、高效地共享 |
| PC 时代 1980s–2000s · Windows, macOS | 桌面设备 + 文件 + 外设 | 进程 + 窗口 | 用户账户 + ACL + 杀毒软件 | 键鼠 GUI、桌面隐喻 | 一个人可以驾驭一台复杂的机器 |
| 移动互联网时代 iOS Android | 传感器、触控、位置、连接、电量、注意力 | 沙箱化 App 进程 | 代码签名 + 应用商店审核 + 运行时权限 | 触控 + App 图标 + 推送 | 随时随地的、可信赖的个人计算 |
| AI 时代（企业运营） Infinite Domain OS | 企业数据语义、Legacy 系统能力、模型与知识、组织规则 | Agent 任务（Skill × Playbook × 工具调用） | 数字真实性 + 写安全分级 + 决策审计 | 自然语言对话 + 富媒体画布 + 主动推送 | 组织可以可信地把决策与执行交给智能 |
3.1 每次跃迁的驱动力：核心资源变得「值得被抽象」
抽象不会凭空发生。当某种资源从稀缺、易管理变得丰裕、异构、易失控时，操作系统化的时机就成熟了：
- 1960s：CPU 极贵 → 需要多道程序与作业调度，让昂贵硬件被共享。
- 1980s：个人设备爆发但能力有限 → 需要桌面抽象，让普通人无需理解机器。
- 2007–：传感器、网络与人的注意力成为核心资源 → 需要 App 沙箱、推送、权限体系，让「个人体验」可被工业化交付。
- 2023–：智能（模型能力）变得丰裕，但企业数据语义、既有系统接口与组织信任成为新的稀缺与失控源——15–30 个 SaaS 工具各有一套数据模型、权限体系与定价逻辑，AI 是附加品而非原生能力。这正是 Domain OS 的设计前提。
3.2 跃迁不是替代：层级堆叠而非零和
移动 OS 没有杀死 PC OS，而是在其上添了一层「个人移动体验」；同理，Domain OS 不取代 iOS/Android，也不直接取代 ERP/CRM，而是在企业系统版图之上添加一层「组织智能的运行时」。三者关系如下：
图 3-1 · 操作系统层级的堆叠关系：每一代 OS 都以上一代的产出为运行环境之一
iOS 架构深潜：封闭精制的体验机器
iOS 是操作系统史上「垂直整合」路线最成功的工程实践：从芯片、内核、运行时、框架到分发渠道全部自营，用封闭换取体验的确定性。本章按「内核 → 服务 → 框架 → 应用 → 分发」五层解剖其架构，并重点分析其信任链设计与 AI 内化方式——这两者对 Domain OS 的设计影响最直接。
4.1 分层架构总览
图 4-1 · iOS 分层架构。与教科书式分层的关键区别在于：每一层的「接口面」都由 Apple 单方定义并强制收敛
4.2 内核与运行时：XNU —— 为「确定性」而生的混合内核
XNU（X is Not Unix）是一个混合内核：Mach 微内核的 IPC 与内存管理，叠加 BSD 子系统（进程模型、网络栈、POSIX 接口）与 IOKit 驱动框架。其架构含义有三：
- 单一供应商、单一硬件目标。XNU 只跑在 Apple 芯片上，内核调度器、内存压缩、I/O 栈都可以为特定硬件深度调优——这是 Android 永远无法获得的自由度，也是「封闭换确定性」的物理基础。
- 受控的能力暴露面。App 不能直接调用内核或驱动，只能通过 XPC/Mach 消息访问系统服务；动态代码加载被禁止（JIT 仅限系统组件），从根上压缩了攻击面与不确定性。
- 神经引擎进入一等公民。ANE 与 Core ML/Apple Intelligence 的协同，使「端侧推理」成为与 CPU/GPU 平级的系统能力——AI 时代的 OS 竞争中，这是 iOS 最关键的先手。
4.3 信任链：从硅到 App 的四级完整性
iOS 的安全模型是「信任逐级传递」的经典实现，每一级只信任上一级签名/验证过的产物：
另有两条独立信任支线：Secure Enclave（SEP）以独立安全协处理器托管密钥与生物特征数据，主处理器被攻破也无法读取；App Tracking Transparency（ATT）把「数据使用同意」变成系统级强制交互。两者的共同哲学是：信任不靠承诺，靠架构约束。
iOS 证明了一条可以被直接移植的原则：安全与可信必须设计进架构，而不是作为事后的检查与补丁。Domain OS 的「数字只取不编」（禁止 LLM 心算业务数字）与「一次性写令牌」（写操作需任务绑定、短 TTL、动作白名单）正是这条原则在 AI 语境下的等价物——把「AI 不作恶」从提示词承诺改写为架构约束。
4.4 分发与生态：App Store 作为「策展式分发」原型
App Store（2008）确立了移动互联网的软件分发范式：统一入口、强制审核、签名分发、平台抽成。其架构意义远超商业模式：
- 分发即治理。审核门禁使「什么代码可以到达用户」成为平台可控变量——这是后来一切「资产生命周期管理」思想的源头。
- API 演进的单方面纪律。开发者只能使用公开 SDK，废弃 API 由 Apple 统一节奏推进，保证了整个生态的技术栈收敛速度。
- 监管压力下的有限开放。欧盟 DMA 自 2024 年起强制允许替代应用市场与侧载（限欧盟），Apple 以「公证（notarization）+ 额外安全扫描」维持最低安全基线——这说明即便在强制开放下，「策展式治理」仍是 iOS 的架构底线。
4.5 AI 内化：Apple Intelligence 与「隐私优先」的混合推理
Apple 的 AI 战略（Apple Intelligence，2024 年随 iOS 18 发布并持续演进）是三大系统中唯一以隐私作为架构第一约束的方案：
| 机制 | 设计要点 | 架构含义 |
|---|---|---|
| 端侧基础模型 | 约 3B 参数的端侧模型运行于 ANE，经量化与蒸馏适配设备；iOS 26 起通过 Foundation Models framework 以系统 API 形式开放给开发者 | 把 LLM 变成「系统服务」而非第三方 SDK——智能成为 OS 的一等能力 |
| Private Cloud Compute（PCC） | 端侧无法处理的请求发送到 Apple Silicon 服务器集群：无状态计算、不留存用户数据、软件镜像可被独立安全研究者验证（可验证透明性） | 「云推理」被改造成可审计的隐私设施——信任延伸到云端的方式是公开验证，而非口头承诺 |
| 分级路由 | 系统自动决定任务在端侧还是 PCC 执行；第三方模型（如 ChatGPT）仅在用户显式确认后介入 | 端云分工由 OS 而非 App 决策——这是「AI Gateway」的雏形 |
4.6 演化机制与结构性局限
演化优势
- 年度大版本 + 年份版本号（2025 起），升级渗透率极高（新版本发布一年内主流设备覆盖率通常超过八成）
- 软硬协同：新内核特性与新芯片同代发布，能力可被即时兑现
- 设备支持周期长（约 6–7 年），生态技术栈收敛快
结构性局限
- 抽象对象是「单设备上的个人」，无组织协作与多租户语义
- 封闭模型在监管（DMA）下被迫开孔，长期治理成本上升
- AI 能力开放度受隐私路线约束：端侧模型能力天花板与迭代速度受制于设备算力
- 「策展」假设代码是确定的——面对概率性的 AI 资产，审核范式本身需要重构（见第 9 章）
Android 架构深潜：开放联邦的兼容机器
Android 是操作系统史上最大规模的「开放联邦」实验：开源内核 + 数百家硬件厂商 + 一个由兼容契约而非直接控制维系的生态。它以约 39 亿用户成为全球使用最广泛的操作系统。对 Domain OS 而言，Android 的价值在于回答了一个 iOS 不需要回答的问题：当你不拥有底层（硬件/厂商 → 对应 Domain OS 语境中的 Legacy 系统），如何仍然维持一个统一的平台？
5.1 分层架构总览
图 5-1 · Android 分层架构。与 iOS 的关键差异：HAL 层是一道「契约边界」，边界之下属于厂商联邦，边界之上属于平台统一
5.2 内核与运行时：为「可移植性」而生的组合
- Linux 内核（LTS 分支）。复用成熟内核换取驱动生态，代价是内核升级受制于厂商适配——这是 Android 碎片化的第一因。
- Binder IPC。Android 的进程间通信骨干：一切系统服务（Activity Manager、Package Manager 等）都是 Binder 服务端，App 以受控的代理方式访问——与 iOS 的 XPC 同构，但开放给数百万第三方开发者。
- Zygote + fork 模型。应用进程从预暖的 Zygote 进程 fork 而来，类与资源预加载共享，冷启动成本被系统性压低——「体验确定性」用运行时机制弥补硬件差异。
- ART 运行时。安装时 AOT + 运行时 JIT + 基于使用画像的再优化（profile-guided compilation），在异构硬件上换取可接受的一致性体验。
5.3 碎片化治理：Treble 与 Mainline —— 开放生态的两把手术刀
Android 最有架构价值的不是任何单一功能，而是它对抗自身碎片化的两次结构性手术：
| 机制 | 引入 | 解决的问题 | 架构手法 |
|---|---|---|---|
| Project Treble | Android 8（2017） | OS 升级被厂商驱动适配卡死，版本碎片化严重 | 将厂商实现（vendor）与系统框架（framework）以稳定接口（VINTF）切开：框架可独立升级，厂商只需维持接口契约 |
| Project Mainline / APEX | Android 10（2019） | 安全补丁与核心模块依赖 OEM 整机 OTA，覆盖缓慢 | 把权限控制器、媒体框架、安全组件等核心模块「包化」，经 Google Play 直接推送更新——模块化交付，绕过厂商节奏 |
| CTS / VTS / GTS | 持续 | 开放生态如何保持「Android」的统一语义 | 兼容性测试套件 + GMS 授权绑定：不通过认证就无法预装 Google 服务——用商业杠杆执行技术契约 |
Treble 的「稳定接口切割」与 Mainline 的「模块化独立交付」，分别对应 Domain OS 的两条宪法级设计：「平台稳、资产活」（Platform 版本稳定，业务变化全部落在 ΔDomain 资产上，经资产管理面上架，不需要平台发版）与资产生命周期平面的灰度/lockfile/回滚机制（资产级交付，不绑定平台版本）。可以说 Domain OS 把 Android 用十年试错换来的治理经验，直接写进了初始架构。
5.4 安全模型：UID 沙箱 + SELinux + 权限
Android 的隔离哲学与 iOS 同源但实现路径不同：每个 App 一个独立 Linux UID，内核级隔离默认生效；SELinux 以强制访问控制覆盖全系统（including root 进程）；Verified Boot 保证启动链完整性；Keystore 以硬件支持（StrongBox/TEE）托管密钥。权限模型（运行时权限 + 权限自动重置 + 照片部分授权等细粒度演进）与 iOS 的 ATT 一样，把「同意」变成系统机制。
与 iOS 的根本差异在于信任的分布：iOS 的信任收敛于 Apple 一家的签名与审核；Android 必须信任「契约 + 认证」——只要厂商通过 CTS、应用通过 Play Protect 扫描，即被允许进入生态。这是联邦制与中央集权制的架构分野。
5.5 AI 内化：Gemini 作为系统级智能层
Google 的 AI 战略与 Apple 相反：云侧强模型优先，端侧小模型跟进，生态开放度最高：
- Gemini 应用取代 Google Assistant，成为系统默认助手入口（含 Pixel 上的深度系统集成）；屏幕上下文（screen context）使助手能理解当前界面。
- Gemini Nano 端侧化：通过 AICore 系统服务托管端侧模型，供摘要、回复建议、图像等任务在设备本地执行——与 Apple 的 Foundation Models framework 异曲同工：模型能力被 OS「服务化」。
- 模型开放：Android 对第三方模型/助手持开放态度（OEM 可替换默认助手），这是其联邦哲学的自然延伸。
5.6 演化机制与结构性局限
演化优势
- 自 Android 16（2025-06）起改为一年两更 + 季度 QPR，SDK 与平台能力解耦（Jetpack/Play Services 独立演进）
- Mainline 使安全与核心模块更新不再依赖整机 OTA
- 生态规模带来最强的硬件多样性与最低的价格门槛
结构性局限
- 版本碎片化仍是事实：大版本在存量设备上的覆盖以年计，安全补丁尾部漫长
- 体验一致性受制于 OEM 定制层，「Android」作为产品语义被稀释
- 抽象对象同样是「单设备上的个人」，无组织/租户语义
- AI 深度集成受开放生态牵制：Gemini 的系统级能力在大量 OEM 设备上被弱化或替换
Infinite Domain OS 深潜：组织智能的治理机器
本章依据《Architecture Baseline v2.0.0》（Frozen，对齐 Architecture Overview v2.1.0）这一单一事实快照，解析 Infinite Domain OS 的组成公式、六层平台、七类资产与信任体系。阅读视角与前两章保持一致：内核/运行时、调度单元、信任机制、分发与生态、AI 内化、演化机制。
6.1 本质定义：一条组成公式与三条宪法
- Intelligence Platform（共享底座）：全平台仅一套运行时。「家是逻辑唯一，物理可分片」——逻辑归属单例，物理可按租户/性能域 cell 化部署。
- Domain Pack（域能力包） = 底座实例订阅 + 一份 ΔDomain 资产包。域边界在能力，不在运行时——这是与「按域拆微服务」路线的根本分野。
- Domain App（场景应用） = 跑在 Domain Pack 之上的能力组合（Skill × Playbook × 语义 × 交互体验）。每个 App 有唯一主宿主 Pack（资产归属与版本责任），可经共享底座跨域调用；数量无上限。
- Skill：Agent 可执行的原子能力单元（意图触发 + 工具集 + 执行策略 + 输出格式）。定义归域（L4b），执行归平台（L4a）。
宪法一
每个能力有且只有一个家——能力归属一律查边界矩阵，不在第二处重建。
宪法二
每个数字有且只有一个出处——数字只取不编，衍生数字只来自注册公式。
宪法三
平台稳、资产活——Platform 版本稳定，业务变化全部落在 ΔDomain 资产上，上架即生效，不需平台发版。
6.2 平台全景：六层运行时 + 两条横切面
图 6-1 · Infinite Domain OS 运行时全景。外部边界：System of Record（CRM/ERP/Billing 等源系统层）独立在外、非 Domain OS 组成部分，经 L2 连接器平等接入——查询走联邦、训练走授权沉降，数据留在源头
6.3 ΔDomain：七类资产与「业务变化资产化」
Domain OS 把所有业务差异收敛为七类可管理资产（明确不增第八类），全部经资产生命周期平面上架：
| 资产类型 | 运行层 | 职责 | 移动 OS 中的近似物 |
|---|---|---|---|
| 连接器包 | L2 | 外部系统接入定义 | 设备驱动 / HAL 定义 |
| 行业语义包 | L3b | 行业指标/实体/口径（注册至 L3a） | （无对应物——移动 OS 不承载业务语义） |
| 知识包 | L3b′ | 文档/规章/经验知识 | （无对应物） |
| Skill 库 | L4b | 原子能力定义，附 golden set 强制评测集 | App + 其单元测试的合并体 |
| 编排策略 / Playbook | L4b | 流程与策略；跨域（≥2 Pack 写操作）Playbook 治理上收至平台场景目录 | 快捷指令 / 自动化工作流 |
| 合规策略包 | 注入 L4a | R0–R3 分级与审批规则 | MDM 策略 / 沙箱 entitlement 配置 |
| 模型 | 经 L1 Model Ops | 训练/上架/供数 | Core ML 模型文件（但治理等级完全不同） |
iOS/Android 的扩展单元是 App——一个自带 UI、数据与逻辑的黑盒；Domain OS 的扩展单元被拆解为七类正交资产，UI（交互模态）只是 App Manifest 的一个因子。这种「能力原子化」使同一 Skill 可被多个 App/Playbook 复用、可被独立评测与灰度——软件供给从「交付应用」变为「交付可验证的能力」。
6.4 调度单元：Agent 任务的生命周期
移动 OS 调度「进程」，Domain OS 调度「Agent 任务」。一个任务在 L4a 的完整生命周期：
6.5 信任体系：AI 原生 OS 的三根支柱
这是 Domain OS 与移动 OS 分道扬镳最彻底的地方。iOS/Android 的信任对象是确定的代码，签名与审核足以覆盖；Domain OS 的信任对象是概率性的模型输出，必须新增三类架构约束：
支柱一 · 数字真实性
- 一切业务数字只从源系统/语义层取数，LLM 禁止生成或心算
- 衍生指标一律执行 L3a 注册公式（版本化留痕）
- 查无数据按规范拒答；可信是架构约束，不是提示词承诺
支柱二 · 写安全纵深
- R0–R3 四级风险分级，注入四层防御（来源打标 → 指令数据隔离 → 规则预检 → 模型复核）
- RPA 写操作默认升一级（自 R1 起）
- 统一审批链：一次审批覆盖多域联动写
支柱三 · 可审计性
- Agent Trace：task → step → tool call → LLM call 四级 span，会话可回放
- R2/R3 决策快照：四要素版本冻结 + 上下文引用，留存 ≥180 天
- 可信度 SLO：数字溯源率 100% · 引用回填率 ≥95% · 规范拒答率 100%
场景级评测：AI 资产的三档门禁
确定性软件靠单元测试，概率性 AI 靠评测集。Domain OS 将评测工业化：冒烟集（≤20 条断言、<10min，上架硬门禁）、全量集（nightly 回归与趋势）、对抗集（注入/诱导编数/越权样例）。golden set 是 Skill/App Template 的强制附件；LLM-as-Judge 判定 + 元评估定期校准裁判本身；评测不过阻断上架，灰度劣化自动回滚。
6.6 跨域协同与 Legacy 相处之道
- Event Catalog：跨域事件目录与统一事件契约（at-least-once + 幂等键 + 实体分区保序），三域以事件驱动协作而非互相直调。
- 一致性底座：不引入新中间件——Outbox、分级对账（钱账 T+1、一般周级）、悬挂事务检测均为模式复用；原则是「补偿尽力而为，对账最终兜底」。
- Legacy 哲学：System of Record 层独立在外、受客户控制或由 Lianwei 独立产品提供，与平台平等接入。读走联邦查询（数据不出源）、写走受控写回、训练走授权沉降——对应企业版的「不拥有底层，但维持统一平台」，正是 Android Treble 问题的组织版。
- BYOO（Bring Your Own OpenAI/模型）：模型接入可客户自带，prompt 采样快照不出域——数据主权作为部署架构的一等公民。
6.7 演化机制与商业模式：Credit 作为系统计量学
Domain OS 的演化单元不是「OS 版本」而是「资产版本」：平台按语义化版本稳定演进，边界矩阵与红线变更升第二位并全员通告；业务变化经资产上架即时生效。商业模式本身也是架构的一部分：底座基础费 + 域订阅费 + Credit 用量费。Credit 体系按结果计费（只有产出有效结果才消耗）、复杂度分级、透明可查——L1 是 Credit 的唯一事实源，L3a 供口径、L3c 呈现。OS 第一次把「价值消耗」纳入了系统自身的可观测面，这在 iOS/Android 的世界里没有对应物（应用内购买是 App 的事，不是 OS 的事）。
十四维核心比对矩阵
下表将三个系统置于同一坐标系。三列分别代表两种已被验证的移动 OS 路线与 AI 时代的企业 OS 路线。阅读建议：先看奇数行的「抽象与调度」差异（范式之别），再看偶数行的「信任与治理」差异（工程之别）。
| 维度 | iOS | Android | ∞ Infinite Domain OS |
|---|---|---|---|
| ① 时代与定位 | 移动互联网 · 个人体验 OS；Apple 软硬一体闭环 | 移动互联网 · 开放生态 OS；Google 主导的厂商联邦 | AI 时代 · 企业运营 OS 与底座；跑在客户既有系统版图之上，不拥有也不替换底层 |
| ② 核心抽象对象 | 传感器、触控、位置、电量、用户注意力 | 异构硬件能力 + 开放应用生态 | 企业数据语义、Legacy 系统能力、模型与知识、组织规则 |
| ③ 内核 / 运行时形态 | XNU 混合内核（Mach+BSD+IOKit），仅 Apple 芯片；单一供应商深度调优 | Linux LTS 内核 + HAL 契约边界 + ART 运行时；为可移植性而生 | 一套逻辑唯一的共享运行时（Intelligence Platform）：六层平台，物理可分片；「域边界在能力，不在运行时」 |
| ④ 调度单元 | 沙箱化 App 进程（+ 系统严格管控的后台执行预算） | UID 隔离的 App 进程（Zygote fork，后台限制相对宽松后持续收紧） | Agent 任务（ReAct × Tool Calling × Saga）：带意图、工具集、风险等级与成本预算的执行单元 |
| ⑤ 信任根 | 硬件信任根（Secure Boot/SEP）+ Apple 代码签名 + App Review | Verified Boot + CTS/VTS 兼容契约 + Play Protect；信任分布在契约而非单一审核方 | 三重信任：数字真实性（只取不编）+ 写安全分级（R0–R3）+ 决策可审计（Trace/快照）；可信度本身被定义为 SLO |
| ⑥ 隔离模型 | 进程沙箱（Seatbelt MAC）+ entitlement 最小授权 | 每 App 独立 UID + SELinux 全系统 MAC | 租户隔离 QoS + 语义级写隔离：按动作风险分级而非仅按进程边界；不可信内容打标与指令数据隔离 |
| ⑦ 权限与授权 | 运行时权限 + ATT 追踪同意，用户逐次授予 | 运行时权限 + 自动重置 + 细粒度授权（部分照片等） | 统一审批链：授权对象从「设备能力」变为「业务动作」；一次审批覆盖多域联动写；R2/R3 确认在 App 接触点完成 |
| ⑧ 分发与审核 | App Store 单一策展入口；审核 = 人工 + 自动静态分析 | 多通道（Play/OEM/侧载）；审核 = 自动扫描 + 兼容性认证 | 资产生命周期平面：七类资产统一上架，三档评测门禁（冒烟/全量/对抗）+ LLM-as-Judge + 灰度/lockfile/自动回滚 |
| ⑨ 开发者模型 | Swift/SwiftUI + 受管 SDK；API 面由 Apple 单方收敛 | Kotlin/Jetpack + AOSP 开源；生态庞大但版本分散 | Domain Pack SDK 自助生域 + 七类资产开发范式；评测集（golden set）是交付物的强制组成部分，代码与「证明其正确的证据」一起交付 |
| ⑩ 数据与记忆 | App 私有数据 + iCloud 同步；数据主权以隐私框架表达 | App 私有数据 + 账号同步；碎片化的备份体验 | 语义层为数据唯一口径（L3a 双签注册）；三层知识引擎 + 记忆治理（TTL/衰减、用户可见可删、错误记忆修正）；数据主权以 BYOO/不出域表达 |
| ⑪ AI 内化方式 | Apple Intelligence：端侧基础模型 + PCC 隐私云；Foundation Models framework 系统 API 化 | Gemini（云优先）+ Gemini Nano 端侧（AICore）；对第三方模型开放 | AI 即平台本体：AI Gateway 成本感知路由 + LLM Failover + Model Ops；混合策略（通用能力调度第三方 LLM，域专属模型自建微调）；「数字只取不编」划定模型能力边界 |
| ⑫ 交互范式 | 触控 + App 图标 + 通知/Widget；Siri 演进为 AI 入口 | 触控 + 多启动器 + 通知；Gemini 助手为 AI 入口 | 自然语言对话 + 富媒体画布 + IM 生态（企微/钉钉/飞书）+ 主动推送（系统主动找人，而非人找系统） |
| ⑬ 演化与碎片化治理 | 年度大版本 + 高升级渗透率；碎片化极低（自营硬件） | 一年两更 + QPR；Treble/Mainline 对抗版本与补丁碎片化 | 「平台稳、资产活」：平台版本稳定，业务变化全部资产化上架；克制清单（红线）防止架构漂移 |
| ⑭ 商业模式 | 硬件利润 + App Store 抽成；OS 是硬件价值的放大器 | 广告与服务变现 + 生态授权；OS 是流量与数据的入口 | OS 本身即产品：底座订阅 + 域订阅 + Credit 按结果计费；消耗可观测、可预估、可审计 |
矩阵揭示了一个清晰的递进：iOS 用集中控制解决体验确定性，Android 用契约治理解决生态规模，Domain OS 必须同时解决确定性（AI 输出的可信）与规模（Legacy 版图的异构）——这解释了为什么它的架构同时出现了 iOS 式的宪法原则与 Android 式的契约边界，并额外新增了两者都没有的第三类机制：面向概率性智能的评测、写安全与审计体系。
机制映射：移动 OS 工程智慧的继承与升维
Domain OS 并非凭空发明——移动 OS 近二十年积累的治理机制，几乎都能在 Domain OS 中找到「升维版本」。下表逐一映射：移动时代的机制解决什么问题、在 AI 语境下为什么不够、Domain OS 如何继承并升级它。
| 移动 OS 机制 | 移动语境下的问题 | Domain OS 对应机制 | 升维之处 |
|---|---|---|---|
| App 沙箱 iOS Android |
进程级隔离，防 App 互扰与越权；爆炸半径限于单设备 | R0–R3 安全沙箱（L4a）：按动作后果分级——只读 / 低风险写 / 高风险写 / 不可逆 | 隔离对象从「进程」变为「写动作的语义风险」；爆炸半径的参照系从设备变为生产经营系统 |
| 代码签名 iOS |
静态验证代码完整性与来源；代码确定，故签名即可信 | 一次性写令牌：任务绑定 · 短 TTL · 目标系统+动作白名单 · 参数摘要；L2 验令牌后才执行写回 | 从「证明代码身份」升级为「授权一次具体动作」——AI 时代代码合法不等于动作合法 |
| App Store 审核 iOS |
人工 + 静态分析审「上架前」；对确定性代码有效 | 资产生命周期平面：三档评测门禁（冒烟/全量/对抗）+ LLM-as-Judge 元评估 + 灰度 + 自动回滚 | 审核从「上架前的一次性事件」变为「贯穿全生命周期的持续验证」；审的对象包含模型行为的概率分布 |
| 运行时权限 iOS Android |
用户为「设备能力」（相机/定位）逐次授权 | 统一审批链：用户/管理员为「业务动作」审批；一次审批覆盖多域联动写 | 授权粒度从设备能力到业务后果；审批本身被留痕并可回放 |
| Project Treble Android |
以稳定接口切割框架与厂商实现，使 OS 可独立升级 | 「平台稳、资产活」宪法 + Connector API Boundary：平台版本稳定，业务变化全部落 ΔDomain 资产 | 切割线从「框架/驱动」移到「平台/业务」；实现同样的解耦目标，但对象是组织能力而非硬件驱动 |
| Mainline / APEX Android |
核心模块脱离整机 OTA，独立灰度推送 | 资产级交付：lockfile 锁定依赖 · 灰度发布 · 劣化自动回滚 · 遥测 ROI | 交付单元从「系统模块」细化到「单个 Skill/知识包/策略包」，且每个单元自带评测证据 |
| Private Cloud Compute iOS |
云推理做到无状态 + 可验证透明，以架构兑现隐私承诺 | BYOO 部署 + 数据不出域：模型接入可客户自带；联邦查询数据不出源；prompt 快照不出域 | 数据主权从「消费者隐私」语境迁移到「企业资产」语境，成为部署架构的一等选项 |
| Foundation Models / AICore iOS Android |
把端侧模型封装为系统服务 API，供 App 调用 | AI Gateway + Model Ops + Skill Runtime：成本感知路由 · 健康探针 · Failover · 漂移哨兵 | 从「单模型 API」到「多模型治理平面」：路由、降级、计量、漂移监测都是平台职责 |
| 通知 / Widget / Siri iOS Android |
系统向人推信息，但「推什么、何时推」由 App 决定 | 主动推送 + 哨兵机制：平台持续监测业务信号（健康度下降、交付延迟），主动发起经营动作建议 | OS 从「响应人的操作」进化为「主动发现组织的异常」——主动性第一次成为 OS 职责 |
| ATT / 权限透明 iOS Android |
数据使用的同意管理，粒度到 App 与数据类型 | 记忆治理 + 文档级 ACL：记忆条目用户可见可删、错误记忆可修正、知识按文档级授权 | 同意与可解释性的粒度细化到「系统记住了什么、为什么这样决策」 |
映射表说明：Domain OS 不是对移动 OS 经验的否定，而是把「治理确定性软件」的成熟工具箱，整体迁移并改造成「治理概率性智能」的工具箱。继承的部分（沙箱、签名、门禁、契约分层）保证了工程可信度；升维的部分（语义风险分级、动作级授权、持续评测、决策审计）则是 AI 时代的新增量——后者正是第 9 章的主题。
新问题域：AI 原生 OS 必须独立回答的五道题
第 8 章展示了继承，本章直面不可继承的部分。以下五类问题在 iOS/Android 的世界里要么不存在、要么由 App 自行负责；在 Domain OS 的世界里，它们全部上升为平台级架构问题。
9.1 真实性问题：系统第一次可能「说谎」
iOS/Android 从不为 App 显示的数字负责——App 是确定性代码，错了是 Bug。Domain OS 的输出流经 LLM，幻觉是概率性固有属性：一个编造的续约金额或流失率可能直接触发错误的经营动作。因此「每个数字有且只有一个出处」被写成宪法：业务数字只从源系统/语义层取，衍生数字只执行 L3a 注册公式，查无数据规范拒答。可信从产品承诺变成了架构约束——这是两个移动 OS 从未需要处理的命题。
9.2 写爆炸半径问题：沙箱关不住的经营后果
移动 App 出错，最坏损失限于单设备与个人数据；Agent 出错，写的是客户的生产系统——错改价格、错发促销、错确认收入。进程沙箱对此无效，因为动作本身是「被授权的合法写入」。Domain OS 的答案是把治理前移到动作语义：R0–R3 分级 + 一次性写令牌 + Saga 补偿 + 分级对账（钱账 T+1、一般周级），并坚持「补偿尽力而为，对账最终兜底」。移动 OS 没有等价物，最接近的参照系是金融交易系统的清算纪律。
9.3 多主体信任问题：从「一人一机」到组织权限学
移动 OS 的信任模型默认单用户单设备（家庭共享只是边缘场景）。企业语境下，同一个 Agent 能力要面对角色、部门、法人实体与数据域的组合爆炸：谁能问、谁能看、谁能批、谁能改。Domain OS 以租户隔离 QoS、统一 IAM、文档级 ACL 与审批链组合应对，且把「审批」设计为可跨域联动的系统机制而非各域自建——这在移动世界没有先例。
9.4 异构共存问题：不拥有底层，还要统一
Apple 拥有芯片，Google 用 CTS 认证硬件，两者都至少有「底层准入」的抓手。Domain OS 面对的是客户自有的 15–30 个 Legacy 系统，各有数据模型、权限体系与演进节奏，且「不能要求客户换系统」。解法是 Android Treble 思路的组织版：契约化边界（L2 Connector API Boundary + 域专属适配器）、数据不搬家（联邦查询 + 授权沉降）、渐进替代（智能叠加 → 能力接管 → 原生运营三阶段）。这是比硬件碎片化更难的碎片化——因为「厂商」是客户自己的历史决策。
9.5 评测问题：如何为概率性软件做质检
确定性软件的质量可以用单元测试穷尽；AI 资产的质量是一个分布。Domain OS 把评测工业化：golden set 强制附件、三档门禁、LLM-as-Judge + 元评估校准裁判、线上失败样本回流评测集。值得注意的是其克制：「不在评测流水线跑通前承诺新的 SLO 数字」——先有测量方法，再有承诺数字。这种对「可测量性」的纪律，恰是移动 OS 成熟度在新领域的复刻。
风险与挑战的结构性对比
公允的比对必须包含风险面。三个系统面对的挑战性质不同：iOS/Android 的风险是「成熟系统的边界压力」，Domain OS 的风险是「新范式的建立成本」。下表按风险类别对齐呈现。
| 风险类别 | iOS | Android | ∞ Infinite Domain OS |
|---|---|---|---|
| 治理/监管 | DMA 等反垄断强制开放分发渠道，策展模型被动开孔，合规成本持续上升 | 各地隐私/数据法规叠加 OEM 行为差异，合规面分散 | 企业数据跨境与行业合规（金融/医疗）要求本地化部署与审计留痕——已以 BYOO、数据不出域、≥180 天快照正面承接，但各法域适配是长期工程 |
| 碎片化/复杂度 | 极低（自营硬件）；复杂度集中在 Apple 内部 | 版本与安全补丁的长尾仍是顽疾，Treble/Mainline 缓解但未根除 | 复杂度来源是客户 Legacy 版图：连接器语义映射、口径对齐、历史数据质量——L2/L3a 的设计正是为此，但落地强度取决于实施纪律 |
| 技术信任 | 信任集中于 Apple 单点；一次审核失守即全局性事件 | 开放面大，恶意应用与供应链攻击需持续对抗（Play Protect） | AI 信任必须靠可验证性建立：溯源率、拒答率、决策快照都要可被客户审计——「证明给怀疑者看」的能力是采纳前提 |
| 生态冷启动 | 已跨越（先发 + 硬件绑定） | 已跨越（开源 + GMS 杠杆） | 最大挑战：域资产包、行业语义包需要行业知识沉淀；三阶段渐进策略（智能叠加起步）降低切换门槛，但首批客户的成功案例决定生态势能 |
| 成本与经济性 | AI 成本由硬件溢价消化，端侧为主 | 云端 AI 成本以广告与服务变现覆盖 | 推理成本直接进入客户账单——故有 AI Gateway 成本感知路由、按结果计费（失败不扣费）、成本驾驶舱 dogfooding；单位经济性需随模型降价与缓存优化持续证明 |
| 工程成熟度 | 近 20 年商用打磨 | 约 18 年商用打磨、39 亿用户验证 | 架构基准 v2.0.0 处于 Frozen 设计态，克制清单（不提前 cell 化、不承诺未验证 SLO）显示架构纪律，但规模化运行证据仍在积累中——这是与两个移动 OS 比对时最诚实的注脚 |
结论与展望
11.1 三条结构性结论
结论一 · OS 的抽象对象沿「机器资源 → 个人体验 → 组织能力」上移
每一次上移都由同一条规律驱动：当某种资源变得丰裕、异构、易失控时，它就需要被操作系统化。2023 年后，模型能力丰裕而企业语义稀缺，智能输出强大而不可自证——企业运营因此成为下一个「值得被抽象」的对象。Infinite Domain OS 的定位正当其位：它不是移动 OS 的竞争者，而是操作系统概念树在 AI 时代的新分枝。
结论二 · 信任机制从「验证代码」进化为「验证行为与事实」
iOS 证明信任可以设计进架构（签名+沙箱+审核），Android 证明信任可以用契约分布式治理（CTS+VINTF）。Domain OS 的贡献在于指出：面对概率性智能，信任的验证对象必须从静态的代码身份，转向动态的行为边界（写安全）、事实出处（数字只取不编）与决策过程（可审计快照）。这三根支柱很可能成为未来一切企业级 AI 系统的公共架构词汇。
结论三 · 「平台稳、资产活」是碎片化治理的通用解
Android 用 Treble/Mainline 花了近十年学会「把变化关进可独立交付的模块」；Domain OS 把这条经验提升为宪法：平台版本稳定如地基，业务变化全部资产化、带评测证据上架、可灰度可回滚。对实施者的含义是明确的——不要试图用平台发版解决业务需求，也不要让业务资产绕过门禁直接生效。这两条纪律的坚持程度，将决定 Domain OS 能否复制移动 OS 的生态收敛速度。
11.2 展望：操作系统概念的下一站
- 交互终态：App 图标网格不会消失，但会逐渐退化为「高频快捷方式」；组织的主交互面将是对话与主动推送的混合——系统的主动性（哨兵、预警、建议）第一次成为 OS 的核心职责而非 App 的营销功能。
- 软件供给终态：从「交付应用」到「交付可验证的能力」（Skill + golden set）。评测集之于 AI 软件，将如测试覆盖率之于确定性软件——先成为最佳实践，再成为准入门槛。
- 计量终态：Credit 式的结果计费预示 OS 将把「价值消耗」纳入可观测面；算力、Token、业务结果的三级计量可能成为企业 AI 的「水电表」。
- 生态位终态：iOS/Android 继续做「人的 OS」，Domain OS 类系统做「组织的 OS」；两者经由触达渠道（移动端 App、IM、推送）衔接。未来十年最值得观察的，是组织 OS 能否像移动 OS 在 2008–2015 年那样，完成从「新概念」到「默认基础设施」的跨越。
1980 年代，个人电脑行业问「谁需要操作系统」，答案是每个用户；2007 年，移动行业问「手机上需要什么样的操作系统」，答案是体验与生态；2026 年，企业软件行业的问题是——当智能像电力一样可得，组织需要什么样的「电网调度系统」？iOS 与 Android 用近二十年给出了各自时代的最优解；Infinite Domain OS 提交的，是 AI 时代的一份架构答卷。它的设计深度（宪法原则、边界矩阵、克制清单）表明这不是一次营销定位，而是一次认真的操作系统工程实践。答案是否正确，将由市场与时间评测——而这恰好也是它自己架构中最重视的机制。
附录：术语表与参考来源
A.1 术语表（按主题分组）
| 术语 | 释义 | 所属系统 |
|---|---|---|
| XNU | Apple 混合内核：Mach IPC + BSD 子系统 + IOKit 驱动框架，iOS/macOS 的内核 | iOS |
| SEP / Secure Enclave | 独立安全协处理器，托管密钥、生物特征与支付凭证，与主处理器隔离 | iOS |
| AMFI / Seatbelt | Apple Mobile File Integrity（代码签名强制）与沙箱 MAC 策略框架 | iOS |
| PCC | Private Cloud Compute：Apple 的隐私优先云推理设施，无状态、可验证透明 | iOS |
| Foundation Models framework | iOS 26 起的系统 API，将端侧基础模型能力开放给第三方开发者 | iOS |
| HAL / VINTF | 硬件抽象层及其接口清单（Vendor Interface），框架与厂商实现的契约边界 | Android |
| Project Treble | Android 8 引入的框架/厂商分层架构，使 OS 升级独立于驱动适配 | Android |
| Mainline / APEX | Android 核心模块的独立更新机制，经 Play 系统更新绕过整机 OTA | Android |
| ART / Zygote / Binder | Android 运行时（AOT+JIT）、进程孵化模型、进程间通信骨干 | Android |
| CTS / VTS / GTS | 兼容性/厂商接口/GMS 测试套件，开放生态的统一性认证工具 | Android |
| AICore / Gemini Nano | Android 端侧模型托管服务与 Google 端侧小模型 | Android |
| Intelligence Platform | Domain OS 共享底座：全平台一套运行时，逻辑唯一、物理可分片 | Domain OS |
| Domain Pack / ΔDomain | 域能力包：底座实例订阅 + 一份七类资产包；域边界在能力不在运行时 | Domain OS |
| Skill / Playbook | Agent 原子能力单元（定义归域、执行归平台）/ 流程与策略资产 | Domain OS |
| L1–L4a | 平台六层：L1 服务 / L2 连接 / L3a 语义 · L3b′ 知识 · L3c 分析 / L4a Agent 运行时 | Domain OS |
| R0–R3 | 写安全分级：只读 / 低风险写 / 高风险写 / 不可逆；配套一次性写令牌与审批链 | Domain OS |
| 数字只取不编 | 宪法二：业务数字只从源系统/语义层取，衍生数字只执行 L3a 注册公式 | Domain OS |
| golden set / 三档门禁 | Skill/App 强制评测附件；冒烟集（上架硬门禁）、全量集（nightly）、对抗集 | Domain OS |
| BYOO | Bring Your Own（模型/OpenAI）：客户自带模型接入，prompt 快照不出域 | Domain OS |
| Credit | 统一计量单位：按结果计费、复杂度分级、透明可查；L1 为唯一事实源 | Domain OS |
A.2 参考来源
- iOS：Apple Developer Documentation（iOS Platform Guide、Platform Security Guide）；Apple Newsroom 与 WWDC 2024/2025 公告；Wikipedia「iOS」「iOS 26」「Apple Intelligence」「Liquid Glass」条目（2026-08 在线核验：iOS 26 于 2025-09-15 发布，采用年份版本号）。
- Android：AOSP「Platform Architecture」文档；Android Developers 文档；Google 系统更新公告；Wikipedia「Android (operating system)」「Android 16」「Android 17」条目（2026-08 在线核验：Android 16 于 2025-06-10 发布、Android 17 于 2026-06-16 发布、全球用户约 39 亿）。
- Infinite Domain OS：《Architecture Baseline v2.0.0》（Frozen，Architecture Group）；《Architecture Overview v2.1.0》；《域定义与整体设计 v2.0》；组件蓝图 v1.0.8 系列（Platform Services / Universal Connector / Semantic Foundation / Knowledge Engine / Unified Analytics / Agent Runtime / Asset Lifecycle Plane / 三大 Domain Pack / Domain Apps）。