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 權限，每種存取模式需要獨立授權