BLUEPRINT

2 核心能力矩阵

第二章：核心能力矩阵

本章对 CAP 协议的五项核心能力进行战略层面的描述，涵盖离线授权、在线票据、会话管理、控制权交接策略和资源访问模式。每项能力从设计动机、生命周期、关键机制和策略配置等维度展开，为后续协议技术规范的制定提供顶层指引。

2.1 离线授权（Authorization_Descriptor）

设计动机

Authorization_Descriptor 是 CAP 协议的核心授权机制。其设计动机源于一个基本判断：终端离线时不应完全剥夺 Fay 的接管权，因为 Fay 可能事先已被人类宿主授权。

在现实场景中，终端设备经常处于网络不可用或不稳定的状态——飞行模式、地下空间、偏远地区、网络故障等。如果授权校验完全依赖在线服务，一旦网络中断，Fay 将立即丧失对终端资源的所有控制权，即使人类宿主（Natural_Person）或官方岗位（Official_Post）此前已明确授权。例如，一位野外摄影师的 iFay 正在帮助其操控无人机拍摄，飞入山谷后手机信号中断——如果没有离线授权机制，iFay 将立即失去对无人机的控制权，可能导致无人机坠毁。这种设计将导致 Fay 的可用性严重依赖网络状态，与 iFay 体系追求的"智能代理无缝接管终端"愿景相悖。

Authorization_Descriptor 通过将授权关系以加密文件的形式持久化到终端本地，使终端在离线状态下仍能独立完成授权校验。这份文件包含 Fay 被授权访问的资源范围、权限类型和有效期，终端侧的 Descriptor_Validator 无需联网即可验证其合法性和有效性。

生命周期概览

Authorization_Descriptor 的生命周期包含以下 5 个阶段：

  1. 签发（Issuance）：由 Descriptor_Issuer 在获得授权人（Natural_Person 或 Official_Post）的明确授权后生成并签发 Authorization_Descriptor。签发过程包括确定授权范围、设置有效期、生成数字签名等步骤。签发完成后，Authorization_Descriptor 被传递给对应的 Fay 实体。例如，用户张三通过授权管理界面，授权其 iFay 在未来 30 天内可以使用笔记本电脑的摄像头和麦克风，Descriptor_Issuer 据此生成一份包含这些权限的 Authorization_Descriptor 并交给 iFay。

  2. 本地存储（Local Storage）：Fay 将获得的 Authorization_Descriptor 提交给目标终端，终端将其以加密形式存储在本地安全存储区域。本地存储确保终端在离线状态下仍可访问授权信息，是离线授权机制的物理基础。例如，iFay 将上述授权文件提交给张三的笔记本电脑，电脑将其加密存储在本地安全芯片中。

  3. 校验（Validation）：当 Fay 请求访问终端资源时，终端侧的 Descriptor_Validator 对本地存储的 Authorization_Descriptor 进行校验。校验内容包括：数字签名的合法性（使用 Verification_Key 验证）、有效期是否过期、授权范围是否覆盖请求的资源和操作类型、是否已被撤销。例如，iFay 请求开启摄像头，终端检查授权文件的签名是否合法、是否在 30 天有效期内、是否包含摄像头的使用权限。

  4. 撤销（Revocation）：当授权人决定收回授权时，通过签发撤销声明使对应的 Authorization_Descriptor 失效。撤销声明通过多种渠道分发到终端（详见下文"撤销声明分发策略"），终端在后续校验中将拒绝已被撤销的 Authorization_Descriptor。例如，张三发现 iFay 的行为不符合预期，立即撤销其摄像头使用授权，终端在下次校验时将拒绝该 iFay 的摄像头访问请求。

  5. 更新（Renewal）：当 Authorization_Descriptor 即将过期或授权范围需要调整时，由 Descriptor_Issuer 签发新的 Authorization_Descriptor 替换旧版本。更新过程本质上是一次新的签发，旧版本在新版本生效后自动失效。例如，30 天有效期即将到期，张三决定续期并额外授权 iFay 使用存储设备，Descriptor_Issuer 签发一份新的授权文件替换旧版本。

信任链模型

离线授权的可信性依赖于一条完整的信任链，从授权人到终端侧验证器的信任传递路径如下：

授权人（Natural_Person / Official_Post）
    │
    │ 授权委托
    ▼
Descriptor_Issuer（授权描述文件签发方）
    │
    │ 签发 Authorization_Descriptor（附带数字签名）
    ▼
Fay（iFay / coFay）
    │
    │ 提交 Authorization_Descriptor
    ▼
终端侧 Descriptor_Validator
    │
    │ 使用 Verification_Key 校验签名
    ▼
校验结果（通过 / 拒绝）

信任链的关键环节：

  • 授权人 → Descriptor_Issuer：授权人通过安全的授权委托机制将签发权委托给 Descriptor_Issuer，确保只有经过授权的签发方才能生成合法的 Authorization_Descriptor
  • Descriptor_Issuer → Fay：Descriptor_Issuer 使用私钥对 Authorization_Descriptor 进行数字签名，Fay 获得签名后的授权文件
  • Fay → Descriptor_Validator：Fay 向终端提交 Authorization_Descriptor，终端侧的 Descriptor_Validator 使用由 Registration_Authority 分发的 Verification_Key 校验签名的合法性
  • Registration_Authority → 终端：Registration_Authority 作为信任基础设施，负责向终端分发 Verification_Key，确保终端能够验证 Authorization_Descriptor 的签名来源

撤销声明分发策略

在离线场景下，撤销声明的及时分发是一个核心挑战。终端需要在无法实时查询在线撤销服务的情况下，尽可能获取最新的撤销信息。CAP 协议采用以下分发策略：

  • 本地撤销列表（Local Revocation List）：终端维护一份本地撤销列表，记录已知的被撤销 Authorization_Descriptor 标识。每次终端联网时，自动从撤销服务同步最新的撤销列表
  • 联网时主动同步：当终端从离线状态恢复到联网状态时，优先同步撤销列表，确保本地撤销信息尽可能接近最新状态
  • 有效期兜底：Authorization_Descriptor 自身携带有效期，即使撤销声明未能及时送达，过期的 Authorization_Descriptor 也会自动失效，限制了撤销延迟的最大影响窗口
  • 下次校验生效：终端在每次校验 Authorization_Descriptor 时检查本地撤销列表，一旦撤销声明到达终端，后续的校验请求将立即拒绝被撤销的授权

2.2 在线票据（Trusted_Ticket）

定位与使用场景

Trusted_Ticket 是 CAP 协议在联网环境下的在线授权补充机制。其核心定位是：在联网环境下提供实时授权签发和撤销状态查询能力，弥补离线授权在时效性和撤销响应速度上的不足。

Trusted_Ticket 的典型使用场景包括：

  • 临时授权：人类宿主需要临时授予 Fay 对某项资源的访问权限，无需经历完整的 Authorization_Descriptor 签发流程，通过在线服务即时签发 Trusted_Ticket。例如，用户临时需要 iFay 帮忙打印一份文件，通过手机一键授权，在线服务即时签发一张仅限使用打印机的临时票据，无需走完整的离线授权签发流程
  • 实时撤销验证：终端在联网状态下可通过 Trusted_Ticket 机制实时查询授权的撤销状态，获得比本地撤销列表更及时的撤销信息。例如，公司管理员刚刚撤销了某个 coFay 的会议室设备控制权，联网的终端可以通过在线票据机制立即获知这一撤销，而不必等待本地撤销列表的下一次同步
  • 动态权限调整：在联网环境下，授权范围可通过 Trusted_Ticket 进行动态调整，无需重新签发 Authorization_Descriptor。例如，iFay 原本只有读取文件的权限，用户在手机上临时将其权限提升为可写入，通过在线票据即时生效

与 Authorization_Descriptor 的关系

Trusted_Ticket 与 Authorization_Descriptor 之间是补充关系而非替代关系：

  • Authorization_Descriptor 是核心：离线授权始终是 CAP 协议的基础机制，Trusted_Ticket 不能脱离 Authorization_Descriptor 体系独立存在
  • 在线签发可转换为离线格式：在线签发的 Trusted_Ticket 可转换为本地 Authorization_Descriptor 格式以供离线使用。这意味着通过 Trusted_Ticket 获得的授权不会因为网络中断而立即失效
  • 优先级关系：当终端同时持有 Trusted_Ticket 和 Authorization_Descriptor 时，优先使用 Trusted_Ticket 提供的实时授权信息，因为其时效性更强

在线到离线降级策略

当在线服务不可用时，CAP 协议执行平滑的降级策略：

  1. 检测在线服务状态：终端持续监测与在线授权服务的连接状态
  2. 自动回退：当在线服务不可用时，终端自动回退到本地 Authorization_Descriptor 校验，不中断 Fay 的资源访问
  3. Trusted_Ticket 转换：在联网期间签发的 Trusted_Ticket 已转换为本地 Authorization_Descriptor 格式存储，确保降级后仍可使用
  4. 恢复后同步：当在线服务恢复可用时，终端自动恢复使用 Trusted_Ticket 机制，并同步离线期间可能遗漏的撤销信息

降级过程对 Fay 透明——Fay 无需感知终端当前使用的是在线票据还是离线授权，授权校验的结果在两种模式下保持一致。

2.3 会话管理（Session）

生命周期

Session（控制会话）是从授权校验通过到访问结束的完整生命周期，包含以下 3 个阶段：

  1. 创建（Creation）：当 Fay 的授权校验通过后，Protocol_Engine 为其创建一个 Session 实例。Session 创建时记录关联的 Fay 标识、目标 Terminal_Resource、授权权限列表和创建时间。创建成功后，Fay 获得对目标资源的控制权。例如，iFay 请求使用笔记本电脑的浏览器，授权校验通过后，系统创建一个绑定到浏览器的控制会话，iFay 从此刻起可以操作浏览器。

  2. 活跃（Active）：Session 创建后进入活跃状态，Fay 可在授权权限范围内对绑定的 Terminal_Resource 执行操作。活跃期间，Liveness_Detection 机制持续监测会话的存活状态，确保 Fay 仍在有效使用该会话。例如，iFay 正在通过浏览器帮用户查询航班信息，期间持续发送心跳表明自己仍在活跃使用中。

  3. 终止（Termination）：Session 可通过以下方式终止：

    • 主动释放：Fay 完成操作后主动释放 Session，归还对 Terminal_Resource 的控制权。例如，iFay 完成航班查询后主动释放浏览器控制权
    • 超时终止：Liveness_Detection 检测到 Fay 会话不再活跃（心跳超时），自动终止 Session 并回收资源。例如，iFay 因运行时崩溃而停止发送心跳，终端在超时后自动回收浏览器控制权
    • 撤销终止：授权被撤销时，关联的活跃 Session 被强制终止。例如，用户发现 iFay 在浏览不当内容，立即撤销授权，浏览器会话被强制终止

Session 终止后，Fay 对该 Terminal_Resource 的控制权立即解除，资源恢复为可被其他控制方获取的状态。

与 Terminal_Resource 的绑定关系

Session 与 Terminal_Resource 之间存在严格的绑定关系：一个活跃 Session 对应一个 Terminal_Resource 的控制权。

这一绑定关系的核心规则：

  • 一对一绑定：每个活跃 Session 绑定到一个具体的 Terminal_Resource，Fay 通过 Session 对该资源执行操作。例如，iFay 获得了一个绑定到"前置摄像头"的 Session，它只能通过这个 Session 操作前置摄像头，不能用它去操作麦克风
  • 排他性控制：对于需要排他访问的操作模式（write、execute、configure），同一 Terminal_Resource 在同一时刻最多只有一个活跃的排他 Session。例如，当 iFay-A 正在以 write 模式向 SD 卡写入数据时，iFay-B 不能同时获得 SD 卡的 write Session
  • 多读并发：对于 read 模式，同一 Terminal_Resource 可同时存在多个活跃的只读 Session。例如，iFay-A 和 iFay-B 可以同时以 read 模式读取 GPS 模块的位置数据
  • 生命周期联动：当 Terminal_Resource 不可用时（如硬件断开），绑定到该资源的所有活跃 Session 将被终止。例如，用户拔掉 USB 摄像头后，所有绑定到该摄像头的 Session 自动终止

存活检测机制

Liveness_Detection（存活检测）通过长连接与应用层心跳结合的方式检测 Fay 会话是否仍然活跃，其设计意图是及时回收失效会话占用的资源。

存活检测的工作机制：

  • 长连接维持：Fay 与终端之间通过长连接保持通信通道，连接状态作为存活检测的基础信号
  • 应用层心跳：在长连接之上，Fay 定期发送应用层心跳消息，表明其仍在有效使用当前 Session。心跳间隔和超时阈值可配置
  • 双重判定：仅当长连接断开且应用层心跳超时同时满足时，才判定 Session 失效。这种双重判定机制避免了因短暂网络波动导致的误判
  • 资源回收：当 Session 被判定为失效后，Protocol_Engine 自动终止该 Session 并释放其占用的 Terminal_Resource，使资源可被其他控制方获取

2.4 控制权交接策略（Handover_Policy）

核心场景

控制权交接发生在多个控制方需要先后使用同一 Terminal_Resource 的场景中。CAP 协议定义了两类核心交接场景：

  • Fay 之间的控制权转移：一个 Fay 将其持有的 Terminal_Resource 控制权转移给另一个 Fay。例如，负责数据采集的 iFay 完成任务后，将摄像头控制权交接给负责视频通话的 iFay；又如，在智能工厂中，负责质检的 coFay 完成产品拍照后，将工业相机控制权交接给负责包装的 coFay
  • Fay 与人类用户之间的控制权转移：Fay 将控制权归还给人类用户，或人类用户将控制权委托给 Fay。例如，一架无人机正由 iFay 自主巡航，飞行员发现异常天气需要手动接管，iFay 立即让出飞行控制权；天气好转后，飞行员将控制权重新交还给 iFay 继续自主飞行。再如，用户正在手动编辑文档，需要 iFay 帮忙排版，将文档编辑器的控制权临时交给 iFay，排版完成后 iFay 归还控制权

策略化配置能力

Handover_Policy 提供策略化的配置能力，支持以下 3 种策略类型：

  1. 优先级规则脚本（Priority Rule Script）：通过预定义的规则脚本确定控制权交接的优先级。规则脚本基于 Fay 的角色、任务紧急程度、资源类型等因素计算优先级分数，优先级高的控制方获得资源控制权。这种策略适用于交接规则明确、可预先定义的场景。例如，在医疗场景中，负责紧急报警的 iFay 优先级始终高于负责日常数据采集的 iFay，当两者同时请求使用通信模块时，紧急报警 iFay 自动获得控制权。

  2. AI 模型实时判定（AI Model Real-time Decision）：由 AI 模型根据当前上下文实时判定控制权的分配。AI 模型综合考虑多个控制方的任务状态、资源使用紧迫性、历史交接模式等因素做出决策。这种策略适用于交接规则复杂、难以用静态规则覆盖的动态场景。例如，在智能家居中，负责安防监控的 iFay 和负责视频通话的 iFay 同时请求摄像头，AI 模型根据当前是否有安全威胁、通话是否紧急等上下文信息实时判定优先级。

  3. 人类用户决策（Human User Decision）：将控制权交接的决策权交给人类用户。当多个控制方竞争同一资源时，终端向人类用户呈现选择界面，由人类用户决定将控制权授予哪一方。这种策略适用于高敏感资源或需要人类判断的场景。例如，两个 iFay 同时请求使用用户的银行 App，终端弹出提示让用户自行决定授权给哪一个，因为涉及金融操作需要人类最终把关。

三种策略类型可按 Terminal_Resource 粒度独立配置，同一终端上的不同资源可采用不同的交接策略。

原子性保证

控制权交接过程必须满足原子性要求：在任意时刻，一个 Terminal_Resource 最多只有一个活跃控制方。

原子性保证的实现原则：

  • 先释放后获取：交接过程中，原控制方的 Session 先终止，新控制方的 Session 再创建，确保不会出现两个控制方同时持有同一资源控制权的状态。例如，无人机的飞行控制权从 iFay-A 交接给 iFay-B 时，iFay-A 的控制会话必须先终止，iFay-B 的控制会话才能创建，绝不会出现两个 iFay 同时控制无人机飞行的情况
  • 不可分割：交接操作作为一个整体执行，要么完全成功（原控制方释放 + 新控制方获取），要么完全失败（回滚到交接前状态）
  • 无中间状态暴露：外部观察者在任意时刻看到的资源控制状态都是一致的，不会观察到交接过程中的中间状态

超时处理原则

控制权交接过程可能因各种原因（网络延迟、控制方无响应等）未能在预期时间内完成。CAP 协议对交接超时的处理原则是：超时未完成的交接应回滚到交接前状态，保持原控制方的会话不变。

具体处理规则：

  • 超时阈值可配置：每种交接策略可配置独立的超时阈值，适应不同场景的时效要求
  • 回滚保护：超时触发后，交接操作自动回滚，原控制方的 Session 保持活跃状态不受影响。例如，iFay-A 正在控制摄像头，尝试将控制权交接给 iFay-B，但 iFay-B 因网络延迟未能在规定时间内响应，交接自动回滚，iFay-A 继续保持对摄像头的控制
  • 通知机制：超时回滚后，Protocol_Engine 向相关控制方发送交接失败通知，说明超时原因
  • 重试策略：交接失败后，可根据策略配置决定是否自动重试或等待人工干预

2.5 资源访问模式（Resource_Access_Mode）

分级模型

Resource_Access_Mode 按操作类型将资源访问分为 4 种模式，形成从低到高的权限分级：

  1. read（读取）：对 Terminal_Resource 进行只读访问，不修改资源状态。例如读取温度传感器的实时数据、查看用户相册中的照片、获取 GPS 模块的当前定位信息。read 模式是可共享的，允许多个 Fay 同时以 read 模式访问同一资源——比如多个 iFay 可以同时读取同一个温度传感器的数据，互不干扰。

  2. write（写入）：对 Terminal_Resource 进行数据写入或状态修改。例如将拍摄的照片保存到存储设备、修改智能家居设备的温度设定值、向文档中写入内容。write 模式是排他的，同一时刻只允许一个控制方以 write 模式访问资源——比如两个 iFay 不能同时向同一个文件写入数据，否则会导致数据损坏。

  3. execute（执行）：对 Terminal_Resource 执行操作指令。例如启动手机上的导航 App、触发无人机的起飞指令、执行打印机的打印任务。execute 模式是排他的，确保操作指令的执行不会被其他控制方干扰——比如一个 iFay 正在控制无人机执行降落程序时，另一个 iFay 不能同时发送起飞指令。

  4. configure（配置）：对 Terminal_Resource 进行系统级配置变更。例如修改摄像头的分辨率和帧率参数、调整网络防火墙规则、变更蓝牙模块的配对设置。configure 模式是排他且高权限的，通常需要更高级别的授权才能执行——比如修改路由器的安全策略比单纯读取网络状态需要更高的授权级别。

读写锁本质

Resource_Access_Mode 的并发控制本质上是一个读写锁（Read-Write Lock）模型：

  • read 操作允许多个 Fay 并发访问：多个 Fay 可同时持有同一 Terminal_Resource 的 read 模式 Session，互不干扰。这类似于读写锁中的共享锁（Shared Lock）。例如，三个 iFay 可以同时读取同一个气象传感器的温湿度数据，彼此不会阻塞
  • write、execute 和 configure 操作要求排他控制：当任一 Fay 以 write、execute 或 configure 模式访问资源时，其他 Fay 不能同时以任何写类模式访问该资源。这类似于读写锁中的排他锁（Exclusive Lock）。例如，当一个 iFay 正在向 SD 卡写入视频文件时，另一个 iFay 不能同时向同一 SD 卡写入照片
  • 读写互斥：当资源上存在活跃的 write、execute 或 configure Session 时，新的 read 请求也将被阻塞，直到排他 Session 释放。反之，当资源上存在活跃的 read Session 时，write、execute 和 configure 请求将等待所有 read Session 结束。例如，iFay 正在修改一个配置文件（write 模式），此时另一个 iFay 想要读取该文件也需要等待写入完成，以避免读到不一致的中间状态

这种读写锁模型在保障数据一致性和操作安全性的同时，最大化了 read 操作的并发性能。

与 Session 权限的关系

Resource_Access_Mode 与 Session 的授权权限紧密关联：Session 的授权权限列表决定 Fay 可执行的操作类型。

具体关系如下：

  • 权限列表约束：每个 Session 在创建时携带一个授权权限列表，该列表源自 Authorization_Descriptor 或 Trusted_Ticket 中定义的权限范围。Fay 只能以权限列表中包含的模式访问资源
  • 最小权限原则：Session 的权限列表应遵循最小权限原则，仅包含 Fay 完成当前任务所需的最低权限模式
  • 权限不可提升：Session 创建后，其权限列表不可在会话生命周期内提升。如果 Fay 需要更高权限的访问模式，必须通过新的授权校验创建新的 Session
  • 权限层级包含：高权限模式不自动包含低权限模式的能力。例如，持有 configure 权限不意味着自动拥有 read 权限，每种访问模式需要独立授权