未来十年的 AI，不会只由模型大小决定。同样关键的是另一个问题——已经卖出去、装在口袋里和工厂里的那几十亿台设备，能不能可信地承接云端正在长出来的能力。
今天，绝大部分 AI 能力住在云端：模型在数据中心训练和运行，能力通过 API 被调用，硬件主要负责输入和显示。但物理世界已经有大量设备在持续运转——手机、车辆、嵌入式控制器、工业传感器、边缘网关。它们有算力，也有身份和本地数据，却缺少一种共同方式去声明：自己实际能跑什么、以什么保真度跑、由谁验证、用完之后能不能安全迁移。在没有这层共同语言之前，这些设备只能被动等待整机升级，或者被作为"过期硬件"提前退役。
本文讨论的不是一个新模型，而是上述问题缺失的那一层协议。它既不属于云端推理，也不属于单机本地运行——它存在于"能力声明"与"运行载体"之间，定义两者如何相互问责，又如何允许能力在不同设备之间演化、积累和迁移。Rotifer Protocol 是我们朝这个方向构建的开源框架；它是这条路径上的一个具体候选实现，本文不主张排他性。配套论文 Where Capability Lives, and How Hardware Earns the Right to Run It 展开了完整论证；本文是面向时间紧张读者的入口。
三句不能压成一句的话
大多数能力漂移源于把三句不同的话压缩成同一句话。
"X 是可以做到的。"
"X 在这一类硬件上是可以做到的。"
"X 在你现在手里这块硬件上是可以做到的。"
不区分这三句的协议会让任何产品把它们压缩成一句。第一句最容易出现在主题演讲里。第三句才是真正在替那笔承诺还利息的那一句。
近期信息论研究——Finzi 等 2026 年提出的 epiplexity，把信息内容相对于"算力有界的观察者"重新定义——让这个区分变得可以形式化：能力不是问题的属性，而是 (问题, 观察者) 这一对的属性。两代设备面对同一工作负载，不是在以不同速度跑同一场比赛——它们在跑终点位置不同的比赛。任何软件努力都不会提升观察者的算力预算；软件越来越好，但运行环境仍然有限。协议要做的，是把"载体感知"做成头等结构，让能力声明与硬件能力相互问责。
缺失的不是新模型，而是一层协议
云端能力增长是事实，存量硬件无法一一承接也是事实。把两者连起来的尝试已经不止一种：
- 中心化云端推理——受时延、主权、长尾可达性约束。
- 激进 OTA 升级承诺——产生跨硬件代际的能力漂移：设备承诺的能力与实际能跑的能力之间逐渐失配。
- 孤立的边缘自治——失去跨设备知识传递。
每一条路径都有真实的成功区，但单独或合在一起，都不能支撑存量规模上的分布式智能。
第四条路径——我们一直朝着它构建的——是一个元协议层：通过它，设备可以声明自己实际能做什么、证明自己运行的载体、与网络其他部分交换能力，而不向任何中心化层交出控制权。
这里的"元协议"指的是关于"协议本身如何被声明、协商、演化"的协议——它不规定能力的实现，只规定能力如何被描述、验证、流通。
HTTP 做到的事，AI 还没做到
我们假设——并愿意接受公开质疑——这一层协议对 AI 能力的意义，可能类比 HTTP 对文档的意义。
1991 年时 Web 还不存在；到 2001 年它已经在重塑商业、教育、软件本身。技术前提只有一件事：一个不拥有内容、却定义了内容如何被任何人链接、寻址、渲染的协议。HTTP 没发明文本，没发明网络。它做的事是定义一个让两个不相关的方能就"什么是文档"达成一致的协调层。Web 的价值通过 HTTP 流动，但 HTTP 本身保持轻量、不被拥有、可演化。
把这一点对照当前 AI 能力的处境：没有任何被普遍接受的方式让一个系统能问另一个系统："你能做什么？运行在什么载体上？以什么保真度？带哪些可验证的保证？" 智能单元这一层没有 HTML 文档的对应物——没有可移植、可检视、可引用、可评估的工件。Function-calling 工具 schema 与 MCP 风格描述是 SDK 层的改进，不是协议层的改进。它们规范了调用约定，但没有规范载体感知——区分"能力可以运行"与"能力应当运行"的那一层。
类比成立到哪一步，需要时间和实证来检验。本文的假设是：成立到值得认真做的那一步。
算力门槛刚刚被穿越
边缘推理的连续改进不会改变架构层面的对话。但 2026 年实际发生的事情在质上不同。
对于一类多步 Agent 工作流——工具调用、中间推理、结构化输出、若干轮决策——吞吐门槛已经具体化。Google Gemma 3 家族的公开报告显示：较小变体在 Raspberry Pi 5 CPU 上的解码速率约为 7–8 tok/s；更上一档的变体在 Qualcomm 类移动 NPU 上的解码速率超过 30 tok/s [^gemma3]。这些速率足以在用户接受为"交互式"的钟壁时间预算内，支撑一段约 4000 token 输入加两次 skill 调用的完整工作流。
我们倾向把它视为一次质变而非渐进——同一份过去只能云端驻留的工作负载，现在通过合理工程努力可以在边缘驻留。判定这一观点是否成立、以及它在多大设备覆盖率上成立，需要后续在更广 benchmark 与更多机型上的可证伪实验。基于已公开的 benchmark，部分近代旗舰智能手机、部分车载娱乐平台、以及高端工业网关，已开始穿越这一交互门槛——具体覆盖比例需要 OEM 配合的硬件 profiling 才能给出。
可以更稳妥地说的一句是：对于这一类多步 Agent 工作流，瓶颈正在从硅本身转移到协议层缺位。
[^gemma3]: 数据点来自 Google Gemma 3 model card 与第三方在 Raspberry Pi 5 / Qualcomm AI Engine 上的公开 benchmark；具体数值随量化方案、量化精度、运行时实现而变。
TEE：让能力声明长出硬件根
如果协议要让"能力声明"对硬件可问责，那么这一层必须在硬件中找到一个物理接入面。在现有存量上，这个接入面是可信执行环境（TEE，Trusted Execution Environment）——设备芯片中可证明某段代码确实在受保护边界内运行的机制；现代手机、汽车 ECU、部分工业网关已普遍内置。
Rotifer Protocol 的 L0 Kernel 规约从一开始就把 TEE 列为四种合法 trust backend 之一，与分布式账本、密码学签名链、HSM 并列。本文论证的是操作层面的取舍：在四种之中，TEE 是唯一其部署面与消费级硬件部署面重合的——这使它成为元协议接入存量硬件的合理首选，而非唯一选择。
它在这一角色上有三条具体性质：
- 普遍可用性：TEE 类能力已存在于"已经出货、已经付款、已经在运转"的设备硅片中。
- 根植于硅片的完整性：携带 TEE 证明的能力声明，做出的是对照硅片级状态可验证的主张，而非对照软件级断言可验证。
- 根植于具体设备的身份：参与单位是"节点"而非"账户"的元协议，需要锚定在硅片中的身份，而不仅仅在密钥中。
TEE 本身对"能力是什么"不持任何观点。它能证明某段二进制以某种隔离状态运行并产生某种输出；它不能说这段二进制是不是某条已发布能力的诚实实现、输出是不是与其他能力正确组合、声明的资源使用是不是与实际资源使用一致。这些问题正是元协议层要回答的：
TEE 提供"硬件可信"，元协议提供"能力可知"。两者都必需；任何一方单独都不充分。
能力如何在设备上活下去
到此为止本文有意只用了"能力 / 设备 / 协议层 / 载体 / 保真度"这几个词。下面才是 Rotifer Protocol 为这一层抽象给出的具体词汇——它们都对应能力在异构硬件上活下去时必须区分的工程概念。
| 术语 | 含义 |
|---|---|
| Phenotype（表型） | 设备实际能呈现出来的能力集合，区别于设备理论上可能支持的能力清单。 |
| Fidelity（保真度） | 一项能力在某个载体上兑现原始声明的程度——同一项能力可能以 Native（原生编译）、Wrapped（API 包装）、Hybrid（混合）三种保真度存在。 |
| Imprinting（本地印刻） | 能力在特定设备、特定用户、特定网络环境中累积的本地经验——它本质是局部的，不应被强行通用化。 |
| Adapter（适配器） | 能力跨载体迁移时的翻译层——跨设备、跨保真度、跨 TEE 家族的转换由它承担。 |
把这套词汇放回手机这一最干净的部署面：
考虑一台仍在活跃使用的五年期智能手机。按当前行业默认设定，它只有两种未来：要么因为新能力够不到它而退役，要么以"逐渐与购买时承诺不符"的能力承诺勉强跟上。两种未来都是浪费，且都重复出现。
元协议提供第三种未来。设备声明它真实的 Phenotype——哪些能力它能 Native 跑、哪些只能 Wrapped 跑、哪些超出它的算力类别。它的 TEE 证明这些声明是诚实的。设备不假装支持它做不到的，协议也不让它假装。作为回报，设备接收适合自己载体的能力，并在剩余运行寿命里累积本地印刻的价值——一个用户习惯的模型、一台设备交互模式的模型、一个网络环境特征的模型。这些价值无法泛化到其他用户。它们也不需要。
最终用户换设备时，协议的 Adapter 层把跨设备迁移视为一种跨保真度翻译，由两端 TEE 共同证明。这一部分目前是 Adapter 设计草案，尚无生产实现——本节描述的是目标行为，而非已交付能力。
本文不主张什么
为防止本文自身所诊断的那种能力漂移，三类排除必须显式：
- 本文不主张为 Rotifer Protocol 部署 TEE 后端 Binding 的工程工作已完成或迫在眉睫。这里的论证位于战略与叙事层，与协议近期发布日程的工程优先级是解耦的。本文先于完整实现发布，因为方法论受益于"在产生第一次测量之前接受公开批评"。
- 本文不主张 TEE 异构性已被解决。当前部署的五大主要 TEE 家族在协议层尚不互通。桥接它们是 Adapter 层的职责；跨 TEE 证明是最具体的近期开放问题之一。
- 本文不主张 Rotifer 变成硬件公司。Rotifer 仍是协议层。Binding 是一份契约——一个运行时据此承载协议；TEE 后端 Binding 将是这样一份契约。基金会不提议代为制造硅片、认证设备、或代表 OEM 运营 TEE 基础设施。
这些排除不是套话。它们是本文其余论证赖以成立的基底。
协议成功的反常标准
元协议的成功标准与产品不同。成功的产品对其创建者越来越重要；成功的协议让其创建者越来越可被替代。HTTP 比它的原始商业支持者活得更久，因为协议的价值从任何单一方迁出。元协议最深的考验，是能否在其创建组织退场之后继续运行。
Rotifer Foundation 在协议网络中运营一个特权节点。这一特权存在于容量、中心性、早期采纳访问上，不存在于"必需性"上。协议的设计把基金会运营的基础设施视为多个特权节点中的一个——特权是因为它最早，不是因为协议依赖它。这个故事最成功的版本是：其他特权节点——由伙伴、社区、竞争者、与基金会无关系的实体运营——与基金会节点并行运营，协议在不区分它们的情况下繁荣。
需要明确：在协议早期阶段，基金会仍承担关键的工程协调与规约维护职责；"可被替代"是远期成功标志，不是当下状态。
开放问题与参与方式
对发现论证值得参与的读者，存在四个渠道。
开源贡献：协议规约、参考实现、配套论文以宽松许可证公开可用。欢迎通过开源社区给出实现反馈、规约审查、Adapter 贡献。
学术合作：信息论框架、Capable Edge profile、跨保真度翻译分析——每一项都连接到活跃的研究传统。我们在本综合中借用了种群生物学、复杂系统、机制设计、信息论、嵌入式系统研究者的工具，欢迎合作与质疑。
OEM / 集成商：协议远期路线包含 Binding 工作——其唯一现实工程路径需要产业参与。这条轨道上的对话不预设即时商业承诺；它们是关于"在多年地平线上能支撑生产部署的 Binding spec 形态"的对话。
早期生态参与方：基金会的策略围绕"作为开放生态中的特权节点"而非"捕获生态价值的平台"构建。
仍然开放、本文不假装已经回答的关键问题：
- 跨 TEE 家族的统一证明协议如何设计，才能避免成为新的中心化瓶颈；
- Phenotype 声明与实际行为的偏离，如何被网络在不依赖人工审计的前提下可证伪地发现；
- Imprinting 的本地价值如何在迁移中被忠实保持，又不泄露到本人之外；
- 元协议在不被任何单一 OEM 控制的前提下，长期演化的治理机制如何形成。
完整论证——包括信息论根基、协议的载体感知词汇、实现状态诚实分层、仍活跃的开放问题——见配套论文 Where Capability Lives, and How Hardware Earns the Right to Run It。本文是入口。读者被邀请在每一页上反对。