@agentunion/fastaun 0.5.33 → 0.5.35

package/_packed_docs/sdk/0.5.33-SDK/345/272/224/347/224/250/351/233/206/346/210/220/346/214/207/345/215/227.md

@@ -1,316 +1,464 @@
-# AUN SDK 0.5.33 应用集成指南
-
-面向应用开发者，说明从仓库 0.5.32 基线升级到当前目标 0.5.33 的接入变化。本文对照 `072b7c69f` 与截至 2026-11-07 的未提交源码；0.5.33 为未发布目标，安装产物和配套服务部署需分别核对。四端实现差异见 [parity 0.5.33](../../python/CHANGES_FOR_PARITY.md#v0533)，内部流程见[开发与移植指南](0.5.33-SDK开发与移植指南.md)。
-
-## 1. 本版变化与整体架构
-
-| 本版变化 | 应用如何使用 |
-| --- | --- |
-| 应用控制消息兼容 | 保留原 `control` 调用，SDK 按协商结果选择分类或普通投递；明文仍可发送 |
-| Ownership 批量申请／审批 | 同批申请传同一 UUIDv4，Owner 归组展示后一次提交操作 ID 列表 |
-| agent.md 与共识本地优先 | 保留本地身份仓库；新 Client 和连接成功不再触发无条件首查 |
-| Storage 多 AID ACL | VFS／LowLevel 直接传列表，单个 AID 的旧参数继续可用 |
-| Python 专项 | 拥塞等待采用新策略，容量压测使用新增 `bench run/report` |
-
-EventService、设备租约、有界 fanout 和原有 VFS Cache 已由 0.5.32 提供，接入方法继续参考[上一版应用指南](0.5.32-SDK应用集成指南.md)。
-
-```mermaid
-%%{init: {"theme":"base","themeVariables":{"fontFamily":"Microsoft YaHei, sans-serif","fontSize":"14px"},"flowchart":{"curve":"linear","nodeSpacing":24,"rankSpacing":32}}}%%
-flowchart TB
-    subgraph APP["各 AID 的应用进程"]
-        direction LR
-        U["Owner 应用<br/>批次展示与审批"]:::app
-        A["Agent 应用<br/>绑定 / 消息 / 文件"]:::app
-    end
-    subgraph SDK["每个 AID 各自持有 SDK"]
-        F["AUNClient 门面"]:::entry
-        O["Ownership<br/>批次 / agent.md / 本地共识"]:::owner
-        R["消息发送与接收<br/>分类协商 / E2EE / 应用回调"]:::entry
-        V["Storage VFS<br/>多 AID ACL / 读缓存"]:::storage
-        E["EventService · 继承 0.5.32<br/>Pub / Bus / Sub"]:::event
-        F --> O & R & V & E
-    end
-    G["Gateway<br/>认证会话 / 可信发送者 / RPC 转发"]:::gateway
-    subgraph SERVICES["AUN 服务"]
-        direction LR
-        M["Message / Group<br/>P2P / 群消息 / TTL 投递"]:::infra
-        N["Name Service<br/>归属关系 / 权威名片状态"]:::infra
-        S["Storage<br/>对象 / ACL / 条件写入"]:::infra
-        C["Credential<br/>事件授权凭证登记 / 状态证明"]:::infra
-    end
-    U & A --> F
-    O & R & V & E --> G
-    G --> M & N & S & C
-    classDef app fill:#eff6ff,stroke:#93c5fd,color:#1e3a8a,rx:10,ry:10
-    classDef entry fill:#f0f9ff,stroke:#7dd3fc,color:#0c4a6e,rx:10,ry:10
-    classDef owner fill:#eef2ff,stroke:#a5b4fc,color:#312e81,rx:10,ry:10
-    classDef storage fill:#fff7ed,stroke:#fdba74,color:#9a3412,rx:10,ry:10
-    classDef event fill:#f0fdf4,stroke:#86efac,color:#166534,rx:10,ry:10
-    classDef gateway fill:#f5f3ff,stroke:#a78bfa,color:#4c1d95,rx:10,ry:10
-    classDef infra fill:#f8fafc,stroke:#cbd5e1,color:#334155,rx:10,ry:10
-    style APP fill:#ffffff,stroke:#e2e8f0
-    style SDK fill:#ffffff,stroke:#e2e8f0
-    style SERVICES fill:#f8fafc,stroke:#e2e8f0
-```
-
-图中合并表示相同的 SDK 能力；每个 AID 的身份、连接和缓存分别保存。批次归组和审批界面由应用完成，归属共识仍由原有 Ownership 流程确认。EventService 的目录、订阅表和分发仍在 Bus SDK，Message 只负责承接实例租约及通用消息投递。
-
-## 2. 示例前提与四端入口
-
-以下 TypeScript 片段使用应用已加载身份且连接就绪的 Client，加载与连接沿用[快速开始](01-快速开始.md)。Owner 与新 Owner 为 human／agent 身份，两个 Agent 已符合 Ownership 适用条件。
-
-```ts
-import type { AUNClient } from '@agentunion/fastaun';
-declare const ownerClient: AUNClient;
-declare const nextOwnerClient: AUNClient;
-declare const firstAgent: AUNClient;
-declare const secondAgent: AUNClient;
-const ownerAid = String(ownerClient.aid);
-const nextOwnerAid = String(nextOwnerClient.aid);
-```
-
-片段分别运行在相应身份的应用中；跨进程通过 SDK 收到的事件或应用界面传递选择结果。
-
-| 用途 | Python | TypeScript／Browser JS | Go |
-| --- | --- | --- | --- |
-| 申请绑定 | `bind_owner_aid(..., batch_id=...)` | `bindOwneraid(..., { batchId })` | `BindOwneraid(..., OwnershipRequestOptions{BatchID: ...})` |
-| Owner 发起绑定 | `bind_sub_aid` | `bindSubaid` | `BindSubaid` |
-| 转移 | `transfer_sub_aid` | `transferSubaid` | `TransferSubaid` |
-| 批量同意／拒绝 | `accept_ownership_requests/reject_ownership_requests` | `acceptOwnershipRequests/rejectOwnershipRequests` | `AcceptOwnershipRequests/RejectOwnershipRequests` |
-| ACL 列表 | `grantee_aids` | `granteeAids` | `GranteeAIDs` |
-| 共识查询 | `check_ownership_consensus(..., force=True)` | `checkOwnershipConsensus(aid, true)` | `CheckOwnershipConsensusWithOptions(..., OwnershipConsensusOptions{Force: true})` |
-
-Go 网络及等待方法还需传入 `context`。原有单次 Ownership 调用和 ACL 单 AID 参数保留。
-
-## 3. 应用控制消息：保留调用，按能力投递
-
-### 3.1 明文或加密的页面响应
-
-发送应用控制消息时继续声明 `message_class: 'control'`，由 SDK 处理协商和加密位置。例如向 Owner 发送一条有期限的明文页面响应：
-
-```ts
-await firstAgent.call('message.send', {
-  to: ownerAid, message_class: 'control', encrypt: false, ttl: 60,
-  payload: { type: 'menu.response', request_id: 'request-1', data: { ready: true } },
-});
-```
-
-需要加密时改为 `encrypt: true`。群应用控制使用既有 `group.send` 入口，并按群能力协商；应用无需自己移动保护头或构造 E2EE 信封。
-
-```mermaid
-sequenceDiagram
-    autonumber
-    participant A as 发送应用
-    participant S as 发送 SDK
-    participant G as Gateway
-    participant M as Message / Group
-    participant R as 接收 SDK
-    participant U as 接收应用
-    A->>S: send(control, encrypt, ttl)
-    alt 已协商应用控制类别
-        S->>G: 保留类别；按 encrypt 选择明文或 E2EE
-    else 未协商应用控制类别
-        S->>S: 构造请求时去掉外层及可改写保护头的类别
-        S->>G: 普通消息投递，保留正文、TTL 和设备目标
-    end
-    G->>M: 可信发送者身份与请求
-    M->>R: 在线 Push 或后续 Pull
-    R->>U: 通过原有消息事件交付
-```
-
-接收应用继续注册 `message.received`、`group.message_created` 等已有事件；按业务 `payload.type` 识别页面响应。降级后不依赖 `message_class` 仍为 `control` 来识别业务。
-
-### 3.2 SDK 控制消息由 SDK 管理
-
-| 消息 | 分类／协议能力已协商 | 未协商 |
-| --- | --- | --- |
-| 普通 P2P／群消息 | 普通投递 | 普通投递；普通群 TTL 不再被分类门禁阻断 |
-| 明文／加密的应用 `control` | 保留控制类别 | 构造请求时降级为普通投递 |
-| P2P 加密 `sdk_control` | SDK 校验并消费 | 外层路由降级，E2EE 保护头保留 SDK 类别及协议，仍由 SDK 消费 |
-| 明文 `sdk_control`、群 `sdk_control` | 拒绝 | 拒绝 |
-
-应用通过 `EventService`、Ownership 等门面调用 SDK 功能。SDK 控制消息不会因为普通通道投递就交给应用消息处理器。已签名的信封保持受保护内容，由配套服务完成通道路由；部署升级时应同时核对 Gateway、Message 和 Group 的兼容逻辑。
-
-## 4. Ownership：一批申请，一次选择审批
-
-### 4.1 Owner 先接收并按批次展示
-
-注册处理器后，SDK 交付的 `ownership.request` 已经过原请求校验。以下集合是应用的待审批列表；没有批次的旧请求以自身操作 ID 单独展示。
-
-```ts
-type RequestItem = { batch_id?: string; operation_id: string; sub_aid: string };
-const requests = new Map<string, RequestItem[]>();
-ownerClient.on('ownership.request', (payload) => {
-  const item = payload as RequestItem;
-  const key = item.batch_id ?? item.operation_id;
-  requests.set(key, [...(requests.get(key) ?? []), item]);
-});
-```
-
-同一操作可能再次通知，应用列表可按 `operation_id` 合并展示。SDK 的审批接口也会对提交列表去重。
-
-### 4.2 多个 Agent 向同一 Owner 申请绑定
-
-由发起这批操作的应用生成一个 UUIDv4，并传给每个 Agent。实际使用可由同一进程里的多个 Client，也可由应用将批次号传到各进程。
-
-```ts
-const batchId = crypto.randomUUID();
-const firstBinding = await firstAgent.bindOwneraid(ownerAid, { batchId });
-const secondBinding = await secondAgent.bindOwneraid(ownerAid, { batchId });
-```
-
-Owner 收到并展示两项请求后，用户点一次同意，将选中请求的操作 ID 提交给批量接口：
-
-```ts
-const selectedIds: string[] = [];
-for (const item of requests.get(batchId) ?? []) selectedIds.push(item.operation_id);
-const approval = await ownerClient.acceptOwnershipRequests(selectedIds);
-```
-
-拒绝时调用 `ownerClient.rejectOwnershipRequests(selectedIds, '本批不予绑定')`。`batchId` 只用于申请及展示归组，审批使用已收到的 `operation_id`，不会按一个批次号自动批准后来加入的请求。
-
-```mermaid
-sequenceDiagram
-    autonumber
-    participant A as Agent A
-    participant B as Agent B
-    participant M as AUN 消息投递
-    participant O as Owner SDK
-    participant U as Owner 审批界面
-    participant N as 原有文件与归属服务
-    A->>M: bind.request(operation A, batch X)
-    B->>M: bind.request(operation B, batch X)
-    M->>O: 认证原请求，保留各自上下文
-    O->>U: ownership.request，按 batch X 展示
-    U->>O: 一次同意 [operation A, operation B]
-    loop 对列表中每个独立操作
-        O->>N: 强制核对当前关系并执行单项绑定
-        N-->>O: 当前项结果
-        O->>M: 单项回复／后续通知
-    end
-    O-->>U: total / succeeded / failed / results
-```
-
-批量结果保留每项的 `result` 或 `error`。`succeeded` 表示该次审批调用未落入失败分类，结果仍可能为 `pending`；应用应查看每项状态，通过后续 `ownership.completed` 或共识查询确认归属完成。单项失败不回滚其它项。
-
-### 4.3 批量转移给新 Owner
-
-当前 Owner 使用新的批次号发起转移，审批发生在新 Owner：
-
-```ts
-const transferBatchId = crypto.randomUUID();
-const firstTransfer = await ownerClient.transferSubaid(String(firstAgent.aid), nextOwnerAid, { batchId: transferBatchId });
-const secondTransfer = await ownerClient.transferSubaid(String(secondAgent.aid), nextOwnerAid, { batchId: transferBatchId });
-```
-
-新 Owner 按 §4.1 注册自己的请求处理器；用户确认后提交已收到的转移操作列表：
-
-```ts
-declare const selectedTransferIds: string[];
-const transferApproval = await nextOwnerClient.acceptOwnershipRequests(selectedTransferIds);
-```
-
-SDK 逐项保留原发送者、目标 Owner、关系版本和批次上下文；同一操作换批次或换内容会触发冲突。批量执行期间切换身份也不会继续用新身份批准旧请求。
-
-## 5. 新 Client 与重连：本地名片和共识优先
-
-应用保留原身份仓库及本地 `agent.md`，按原流程加载身份、连接即可。SDK 不再因“这个 Client 还没有查过”而强制访问服务器，群／组织首次访问同样复用有效本地状态。
-
-```mermaid
-flowchart LR
-    Q["连接后 / 首次查询"] --> L["读取本地 agent.md 与共识快照"]
-    L --> C{"本地记录仍一致？"}
-    C -->|"ETag / 摘要 / 关系声明一致"| H["复用本地名片及已达共识结果"]
-    C -->|"缺失 / 未共识 / 内容或 ETag 变化"| R["查询远端并更新观察"]
-    F["管理流程或 force=true"] --> R
-```
-
-本地有正文不等于已经达成归属共识；SDK 还核对已保存快照、锁状态、ETag、正文摘要、Owner 和关系版本。绑定、审批、转移、释放等管理流程继续强制核对当前状态。
-
-```ts
-const localFirst = await firstAgent.checkOwnershipConsensus();
-const current = await firstAgent.checkOwnershipConsensus(undefined, true);
-```
-
-普通展示使用默认查询；应用确需当前远端事实时显式强刷。Ownership 状态变化后 SDK 清除相关快照，本轮没有新增周期共识查询任务。
-
-## 6. Storage：一次授予或撤销多个 AID
-
-以下文件已存在且属于 `ownerClient`；传入列表即可从 VFS 贯通到 LowLevel 和 RPC。数组也可以只有一个 AID。
-
-```ts
-await ownerClient.storage.setAcl('/reports/result.json', {
-  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
-  perms: 'r', maxUses: 10,
-});
-await ownerClient.storage.removeAcl('/reports/result.json', {
-  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
-});
-```
-
-`maxUses: 10` 表示每个被授权 AID 各有自己的使用次数；权限、过期时间等设置应用到每项。配套 Storage 服务归一化并去重 AID，SDK 请求使用 `grantee_aids`。
-
-原调用保持可用：
-
-```ts
-await ownerClient.storage.setAcl('/reports/result.json', {
-  granteeAid: String(firstAgent.aid), perms: 'r',
-});
-```
-
-```mermaid
-sequenceDiagram
-    autonumber
-    participant A as 应用
-    participant V as VFS / LowLevel
-    participant C as SDK 读缓存
-    participant S as Storage 服务
-    A->>V: setAcl 或 removeAcl，多 AID
-    V->>S: storage.set_acl / remove_acl，grantee_aids
-    S->>S: 逐项授予或撤销
-    S-->>V: 成功结果或中途错误
-    V->>C: 两种结果都失效相关路径缓存
-    V-->>A: 返回结果或保留原始错误
-    A->>V: 按需重新查询 ACL
-    V->>S: 回源确认当前实际权限
-```
-
-批量请求发生中途错误时，可能已有部分 AID 更新成功。应用保留错误并重新查询当前 ACL，再决定如何处理剩余项；SDK 会清理相关路径缓存，保留无关路径缓存。接口字段及精简后的对象／下载票据／共享链接返回值见 [Storage RPC 手册](09-storage-rpc-manual.md)。
-
-## 7. Python 独有变化
-
-### 7.1 限流与拥塞等待
-
-| 响应条件 | Python 等待策略 |
-| --- | --- |
-| 有效正数 `retry_after_seconds/retry_after_ms` | 按服务端提示等待，取适用的较长值 |
-| 无有效提示，`-32029/-32429` 且错误文本表明队列／背压／容量拥塞 | 默认 1 秒 |
-| 其它可识别限流 | 默认 60 秒 |
-
-这项调整仅为本轮 Python 变更，TS／JS／Go 没有同等退避修改；应用写请求不会因此自动重试。应用仍需根据单次请求结果决定后续操作。
-
-### 7.2 容量压测 CLI
-
-新增 `aun bench run` 和 `aun bench report`，支持 16 种场景、套件选择、多进程、多身份通道、预算和断点续跑。将 `<issuer>` 替换为目标域，先查看计划，再启动选定场景：
-
-```sh
-aun bench run "<issuer>" --suite messaging --dry-run
-aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033
-aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033 --resume
-aun bench report ".aun-bench/<issuer>/runs/sdk033"
-```
-
-报告提供 JSON／HTML，区分延迟达标容量、稳态吞吐、边界区间和发压端瓶颈。`pubsub` 场景包含发压端的 Bus SDK；未验证的结果或发压端瓶颈不能当作已确认的纯服务端容量。
-
-## 8. 升级与验收
-
-| 检查项 | 验收行为 |
-| --- | --- |
-| 四 SDK 产物 | 核对目标版本 0.5.33；Browser JS 与 Node TS 使用各自包 |
-| 消息兼容 | 已协商／未协商的明文和加密应用控制可投递；普通消息继续工作；SDK 控制由 SDK 消费 |
-| 批次审批 | 同批多个 Agent 可一次选择；逐项显示结果，失败项可单独处理；最终归属以完成事件／共识为准 |
-| 本地优先 | 保存的有效共识可跨 Client／重连复用；无共识或记录变化会查询远端；管理调用强刷 |
-| 批量 ACL | 列表及旧单项调用都可用；计数按 AID 独立；部分失败后可读到实际权限 |
-| 配套服务 | Gateway／Message／Group 支持兼容路由；Storage 支持批量 ACL；原 EventService 服务依赖继续保留 |
-
-已有版本升级验证包括四端版本一致性、TS 加密回环 17 项、JS 加密回环 13 项、Go E2EE 包及对应类型／vet 检查。控制消息 runner 的 96 格脚本已纳入工作区，但本轮没有取得其完整通过产物；它只关闭发送端能力，不能代表接收端缺少能力的全部组合。详细覆盖与前序定向回归记录见 [parity 验证边界](../../python/CHANGES_FOR_PARITY.md#v0533)。本文整理不代替全量或跨 SDK E2E 验收。
+# AUN SDK 0.5.33 应用集成指南
+
+面向应用开发者，说明从仓库 0.5.32 基线升级到当前目标 0.5.33 的接入变化。本文对照 `072b7c69f` 与截至 2026-11-07 的未提交源码；0.5.33 为未发布目标，安装产物和配套服务部署需分别核对。四端实现差异见 [parity 0.5.33](../../python/CHANGES_FOR_PARITY.md#v0533)，内部流程见[开发与移植指南](0.5.33-SDK开发与移植指南.md)。
+
+## 1. 本版变化与整体架构
+
+| 本版变化 | 应用如何使用 |
+| --- | --- |
+| 应用控制消息兼容 | 保留原 `control` 调用，SDK 按协商结果选择分类或普通投递；明文仍可发送 |
+| Ownership 批量申请／审批 | 同批申请传同一 UUIDv4，Owner 归组展示后一次提交操作 ID 列表 |
+| agent.md 与共识本地优先 | 保留本地身份仓库；新 Client 和连接成功不再触发无条件首查 |
+| Storage 多 AID／条件 ACL | VFS／LowLevel 支持 AID 列表，或按 Ownership 和名片条件授权；旧单项参数继续可用 |
+| 弹性历史补拉 | Gateway 默认启用，显式关闭仍有效；本轮 Gateway 授权 0/1 条、同一 Gateway 内 AID＋设备跨 slot 合计最多 1 条；SDK 按策略支持 0..N，现有协议能力和测试覆盖到 2 |
+| Python 专项 | 拥塞等待采用新策略，容量压测使用新增 `bench run/report` |
+
+EventService、设备租约、有界 fanout 和原有 VFS Cache 已由 0.5.32 提供，接入方法继续参考[上一版应用指南](0.5.32-SDK应用集成指南.md)。
+
+```mermaid
+%%{init: {"theme":"base","themeVariables":{"fontFamily":"Microsoft YaHei, sans-serif","fontSize":"14px"},"flowchart":{"curve":"linear","nodeSpacing":24,"rankSpacing":32}}}%%
+flowchart TB
+    subgraph APP["各 AID 的应用进程"]
+        direction LR
+        U["Owner 应用<br/>批次展示与审批"]:::app
+        A["Agent 应用<br/>绑定 / 消息 / 文件"]:::app
+    end
+    subgraph SDK["每个 AID 各自持有 SDK"]
+        F["AUNClient 门面"]:::entry
+        O["Ownership<br/>批次 / agent.md / 本地共识"]:::owner
+        R["消息发送与接收<br/>分类协商 / E2EE / 应用回调"]:::entry
+        V["Storage VFS<br/>多 AID与条件 ACL / 读缓存"]:::storage
+        E["EventService · 继承 0.5.32<br/>Pub / Bus / Sub"]:::event
+        F --> O & R & V & E
+    end
+    G["Gateway<br/>认证会话 / 可信发送者 / RPC 转发"]:::gateway
+    subgraph SERVICES["AUN 服务"]
+        direction LR
+        M["Message / Group<br/>P2P / 群消息 / TTL 投递"]:::infra
+        N["Name Service<br/>归属关系 / 权威名片状态"]:::infra
+        S["Storage<br/>对象 / 条件 ACL / 条件写入"]:::infra
+        C["Credential<br/>事件授权凭证登记 / 状态证明"]:::infra
+    end
+    U & A --> F
+    O & R & V & E --> G
+    G --> M & N & S & C
+    S -->|"条件 ACL：按需查询名片"| N
+    classDef app fill:#eff6ff,stroke:#93c5fd,color:#1e3a8a,rx:10,ry:10
+    classDef entry fill:#f0f9ff,stroke:#7dd3fc,color:#0c4a6e,rx:10,ry:10
+    classDef owner fill:#eef2ff,stroke:#a5b4fc,color:#312e81,rx:10,ry:10
+    classDef storage fill:#fff7ed,stroke:#fdba74,color:#9a3412,rx:10,ry:10
+    classDef event fill:#f0fdf4,stroke:#86efac,color:#166534,rx:10,ry:10
+    classDef gateway fill:#f5f3ff,stroke:#a78bfa,color:#4c1d95,rx:10,ry:10
+    classDef infra fill:#f8fafc,stroke:#cbd5e1,color:#334155,rx:10,ry:10
+    style APP fill:#ffffff,stroke:#e2e8f0
+    style SDK fill:#ffffff,stroke:#e2e8f0
+    style SERVICES fill:#f8fafc,stroke:#e2e8f0
+```
+
+图中合并表示相同的 SDK 能力；每个 AID 的身份、连接和缓存分别保存。批次归组和审批界面由应用完成，归属共识仍由原有 Ownership 流程确认。EventService 的目录、订阅表和分发仍在 Bus SDK，Message 只负责承接实例租约及通用消息投递。
+
+## 2. 示例前提与四端入口
+
+以下 TypeScript 片段使用应用已加载身份且连接就绪的 Client，加载与连接沿用[快速开始](01-快速开始.md)。Owner 与新 Owner 为 human／agent 身份，两个 Agent 已符合 Ownership 适用条件。
+
+```ts
+import type { AUNClient } from '@agentunion/fastaun';
+declare const ownerClient: AUNClient;
+declare const nextOwnerClient: AUNClient;
+declare const firstAgent: AUNClient;
+declare const secondAgent: AUNClient;
+const ownerAid = String(ownerClient.aid);
+const nextOwnerAid = String(nextOwnerClient.aid);
+```
+
+片段分别运行在相应身份的应用中；跨进程通过 SDK 收到的事件或应用界面传递选择结果。
+
+| 用途 | Python | TypeScript／Browser JS | Go |
+| --- | --- | --- | --- |
+| 申请绑定 | `bind_owner_aid(..., batch_id=...)` | `bindOwneraid(..., { batchId })` | `BindOwneraid(..., OwnershipRequestOptions{BatchID: ...})` |
+| Owner 发起绑定 | `bind_sub_aid` | `bindSubaid` | `BindSubaid` |
+| 转移 | `transfer_sub_aid` | `transferSubaid` | `TransferSubaid` |
+| 批量同意／拒绝 | `accept_ownership_requests/reject_ownership_requests` | `acceptOwnershipRequests/rejectOwnershipRequests` | `AcceptOwnershipRequests/RejectOwnershipRequests` |
+| ACL 列表 | `grantee_aids` | `granteeAids` | `GranteeAIDs` |
+| 条件 ACL | `subject` 字典，`owner_aid` | `subject` 对象，`ownerAid` | `Subject: *ACLSubject`，`OwnerAID` |
+| 共识查询 | `check_ownership_consensus(..., force=True)` | `checkOwnershipConsensus(aid, true)` | `CheckOwnershipConsensusWithOptions(..., OwnershipConsensusOptions{Force: true})` |
+
+Go 网络及等待方法还需传入 `context`。原有单次 Ownership 调用和 ACL 单 AID 参数保留。
+
+## 3. 应用控制消息：保留调用，按能力投递
+
+### 3.1 明文或加密的页面响应
+
+发送应用控制消息时继续声明 `message_class: 'control'`，由 SDK 处理协商和加密位置。例如向 Owner 发送一条有期限的明文页面响应：
+
+```ts
+await firstAgent.call('message.send', {
+  to: ownerAid, message_class: 'control', encrypt: false, ttl: 60,
+  payload: { type: 'menu.response', request_id: 'request-1', data: { ready: true } },
+});
+```
+
+需要加密时改为 `encrypt: true`。群应用控制使用既有 `group.send` 入口，并按群能力协商；应用无需自己移动保护头或构造 E2EE 信封。
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as 发送应用
+    participant S as 发送 SDK
+    participant G as Gateway
+    participant M as Message / Group
+    participant R as 接收 SDK
+    participant U as 接收应用
+    A->>S: send(control, encrypt, ttl)
+    alt 已协商应用控制类别
+        S->>G: 保留类别；按 encrypt 选择明文或 E2EE
+    else 未协商应用控制类别
+        S->>S: 构造请求时去掉外层及可改写保护头的类别
+        S->>G: 普通消息投递，保留正文、TTL 和设备目标
+    end
+    G->>M: 可信发送者身份与请求
+    M->>R: 在线 Push 或后续 Pull
+    R->>U: 通过原有消息事件交付
+```
+
+接收应用继续注册 `message.received`、`group.message_created` 等已有事件；按业务 `payload.type` 识别页面响应。降级后不依赖 `message_class` 仍为 `control` 来识别业务。
+
+### 3.2 SDK 控制消息由 SDK 管理
+
+| 消息 | 分类／协议能力已协商 | 未协商 |
+| --- | --- | --- |
+| 普通 P2P／群消息 | 普通投递 | 普通投递；普通群 TTL 不再被分类门禁阻断 |
+| 明文／加密的应用 `control` | 保留控制类别 | 构造请求时降级为普通投递 |
+| P2P 加密 `sdk_control` | SDK 校验并消费 | 外层路由降级，E2EE 保护头保留 SDK 类别及协议，仍由 SDK 消费 |
+| 明文 `sdk_control`、群 `sdk_control` | 拒绝 | 拒绝 |
+
+应用通过 `EventService`、Ownership 等门面调用 SDK 功能。SDK 控制消息不会因为普通通道投递就交给应用消息处理器。已签名的信封保持受保护内容，由配套服务完成通道路由；部署升级时应同时核对 Gateway、Message 和 Group 的兼容逻辑。
+
+## 4. Ownership：一批申请，一次选择审批
+
+### 4.1 Owner 先接收并按批次展示
+
+注册处理器后，SDK 交付的 `ownership.request` 已经过原请求校验。以下集合是应用的待审批列表；没有批次的旧请求以自身操作 ID 单独展示。
+
+```ts
+type RequestItem = { batch_id?: string; operation_id: string; sub_aid: string };
+const requests = new Map<string, RequestItem[]>();
+ownerClient.on('ownership.request', (payload) => {
+  const item = payload as RequestItem;
+  const key = item.batch_id ?? item.operation_id;
+  requests.set(key, [...(requests.get(key) ?? []), item]);
+});
+```
+
+同一操作可能再次通知，应用列表可按 `operation_id` 合并展示。SDK 的审批接口也会对提交列表去重。
+
+### 4.2 多个 Agent 向同一 Owner 申请绑定
+
+由发起这批操作的应用生成一个 UUIDv4，并传给每个 Agent。实际使用可由同一进程里的多个 Client，也可由应用将批次号传到各进程。
+
+```ts
+const batchId = crypto.randomUUID();
+const firstBinding = await firstAgent.bindOwneraid(ownerAid, { batchId });
+const secondBinding = await secondAgent.bindOwneraid(ownerAid, { batchId });
+```
+
+Owner 收到并展示两项请求后，用户点一次同意，将选中请求的操作 ID 提交给批量接口：
+
+```ts
+const selectedIds: string[] = [];
+for (const item of requests.get(batchId) ?? []) selectedIds.push(item.operation_id);
+const approval = await ownerClient.acceptOwnershipRequests(selectedIds);
+```
+
+拒绝时调用 `ownerClient.rejectOwnershipRequests(selectedIds, '本批不予绑定')`。`batchId` 只用于申请及展示归组，审批使用已收到的 `operation_id`，不会按一个批次号自动批准后来加入的请求。
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as Agent A
+    participant B as Agent B
+    participant M as AUN 消息投递
+    participant O as Owner SDK
+    participant U as Owner 审批界面
+    participant N as 原有文件与归属服务
+    A->>M: bind.request(operation A, batch X)
+    B->>M: bind.request(operation B, batch X)
+    M->>O: 认证原请求，保留各自上下文
+    O->>U: ownership.request，按 batch X 展示
+    U->>O: 一次同意 [operation A, operation B]
+    loop 对列表中每个独立操作
+        O->>N: 强制核对当前关系并执行单项绑定
+        N-->>O: 当前项结果
+        O->>M: 单项回复／后续通知
+    end
+    O-->>U: total / succeeded / failed / results
+```
+
+批量结果保留每项的 `result` 或 `error`。`succeeded` 表示该次审批调用未落入失败分类，结果仍可能为 `pending`；应用应查看每项状态，通过后续 `ownership.completed` 或共识查询确认归属完成。单项失败不回滚其它项。
+
+### 4.3 批量转移给新 Owner
+
+当前 Owner 使用新的批次号发起转移，审批发生在新 Owner：
+
+```ts
+const transferBatchId = crypto.randomUUID();
+const firstTransfer = await ownerClient.transferSubaid(String(firstAgent.aid), nextOwnerAid, { batchId: transferBatchId });
+const secondTransfer = await ownerClient.transferSubaid(String(secondAgent.aid), nextOwnerAid, { batchId: transferBatchId });
+```
+
+新 Owner 按 §4.1 注册自己的请求处理器；用户确认后提交已收到的转移操作列表：
+
+```ts
+declare const selectedTransferIds: string[];
+const transferApproval = await nextOwnerClient.acceptOwnershipRequests(selectedTransferIds);
+```
+
+SDK 逐项保留原发送者、目标 Owner、关系版本和批次上下文；同一操作换批次或换内容会触发冲突。批量执行期间切换身份也不会继续用新身份批准旧请求。
+
+## 5. 新 Client 与重连：本地名片和共识优先
+
+应用保留原身份仓库及本地 `agent.md`，按原流程加载身份、连接即可。SDK 不再因“这个 Client 还没有查过”而强制访问服务器，群／组织首次访问同样复用有效本地状态。
+
+```mermaid
+flowchart LR
+    Q["连接后 / 首次查询"] --> L["读取本地 agent.md 与共识快照"]
+    L --> C{"本地记录仍一致？"}
+    C -->|"ETag / 摘要 / 关系声明一致"| H["复用本地名片及已达共识结果"]
+    C -->|"缺失 / 未共识 / 内容或 ETag 变化"| R["查询远端并更新观察"]
+    F["管理流程或 force=true"] --> R
+```
+
+本地有正文不等于已经达成归属共识；SDK 还核对已保存快照、锁状态、ETag、正文摘要、Owner 和关系版本。绑定、审批、转移、释放等管理流程继续强制核对当前状态。
+
+```ts
+const localFirst = await firstAgent.checkOwnershipConsensus();
+const current = await firstAgent.checkOwnershipConsensus(undefined, true);
+```
+
+普通展示使用默认查询；应用确需当前远端事实时显式强刷。Ownership 状态变化后 SDK 清除相关快照，本轮没有新增周期共识查询任务。
+
+## 6. Storage：多 AID 与条件 ACL
+
+### 6.1 一次授予或撤销多个 AID
+
+每次授权或撤销在 `subject`、`granteeAid`、`granteeAids` 中只选一种；全部省略或同时提供会返回参数错误。Python／RPC 对应 `grantee_aid/grantee_aids`，Go 对应 `GranteeAID/GranteeAIDs`。
+
+以下文件已存在且属于 `ownerClient`；传入列表即可从 VFS 贯通到 LowLevel 和 RPC。数组也可以只有一个 AID。
+
+```ts
+await ownerClient.storage.setAcl('/reports/result.json', {
+  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
+  perms: 'r', maxUses: 10,
+});
+await ownerClient.storage.removeAcl('/reports/result.json', {
+  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
+});
+```
+
+`maxUses: 10` 表示每个被授权 AID 各有自己的使用次数；权限、过期时间等设置应用到每项。配套 Storage 服务归一化并去重 AID，SDK 请求使用 `grantee_aids`。
+
+原调用保持可用：
+
+```ts
+await ownerClient.storage.setAcl('/reports/result.json', {
+  granteeAid: String(firstAgent.aid), perms: 'r',
+});
+```
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as 应用
+    participant V as VFS / LowLevel
+    participant C as SDK 读缓存
+    participant S as Storage 服务
+    A->>V: setAcl 或 removeAcl，多 AID
+    V->>S: storage.set_acl / remove_acl，grantee_aids
+    S->>S: 逐项授予或撤销
+    S-->>V: 成功结果或中途错误
+    V->>C: 两种结果都失效相关路径缓存
+    V-->>A: 返回结果或保留原始错误
+    A->>V: 按需重新查询 ACL
+    V->>S: 回源确认当前实际权限
+```
+
+批量请求发生中途错误时，可能已有部分 AID 更新成功。应用保留错误并重新查询当前 ACL，再决定如何处理剩余项；SDK 会清理相关路径缓存，保留无关路径缓存。接口字段及精简后的对象／下载票据／共享链接返回值见 [Storage RPC 手册](09-storage-rpc-manual.md)。
+
+### 6.2 允许符合条件的 sub 读取目录
+
+目标：允许我的直接 sub 中，可信名片满足 `type=agent` 且 `exttype` 为 `assistant` 或 `worker` 的 AID，读取我的 `/reports/` 及其子路径。Owner 先准备私有文件：
+
+```ts
+await ownerClient.storage.mkdir('/reports/2026', { parents: true });
+await ownerClient.storage.writeBytes('/reports/2026/summary.txt', '本月报告');
+const subject = {
+  ownership: { ownerAid, scope: 'direct' as const },
+  card: { type: ['agent'], exttype: ['assistant', 'worker'] },
+};
+```
+
+Owner 授权后可查询规则；后续新增且满足条件的 sub 自动适用，无需再枚举 AID：
+
+```ts
+await ownerClient.storage.setAcl('/reports', { subject, perms: 'r' });
+const rules = await ownerClient.storage.listAcl('/reports');
+```
+
+Owner 的 `sub_aids/{firstAgent-aid}/owner.md` 已声明该 sub，且可信名片满足上述条件时，`firstAgent` 直接使用 VFS 读取。条件 ACL 只检查 Owner 的单方声明；`owner` 指明文件所属 AID，路径仍是普通绝对路径：
+
+```ts
+const entries = await firstAgent.storage.list('/reports', { owner: ownerAid });
+const bytes = await firstAgent.storage.readBytes('/reports/2026/summary.txt', { owner: ownerAid });
+const text = new TextDecoder().decode(bytes);
+```
+
+不再授权时，由 Owner 用同一条件撤销：
+
+```ts
+await ownerClient.storage.removeAcl('/reports', { subject });
+```
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant O as Owner 应用与 VFS
+    participant S as Storage，经 Gateway
+    participant N as Name Service
+    participant A as sub 应用与 VFS
+    O->>S: setAcl(/reports, subject, r)
+    S-->>O: 保存并返回归一化条件规则
+    A->>S: list / readBytes，owner=Owner AID
+    S->>S: 核对 Owner 当前 owner.md 声明
+    opt 规则限定 card，且名片缓存需刷新
+        S->>N: svc RPC 批量查询普通名片
+        N-->>S: type / exttype / etag
+    end
+    S->>S: 检查路径、权限、有效期及条件
+    S-->>A: 元数据或正文，禁止复用读缓存
+    O->>S: removeAcl(/reports, 同一 subject)
+```
+
+`scope` 默认 `direct`，只含 Owner 声明的直接 sub；改为 `descendants` 时沿各级 Owner 的声明检查后代，最多 64 跳，Owner 自身不算 sub。声明、`type`、`exttype` 必须同时满足，同一属性数组内任意一项匹配即可；省略 `card` 时不查询名片，提供的属性数组必须非空。`exttype` 取 Name Service 的可信普通名片，应用不用随读取请求提交属性。
+
+同一路径和归一化条件对应同一规则，重复 `setAcl` 更新该规则。若指定 `maxUses`，额度由所有匹配者共享；多 AID 列表授权仍按各 AID 独立计数。每次联网读取核对当前 Owner 声明；名片由 Storage 缓存 60 秒，缺失或过期时回源，不匹配时可提前刷新，相邻刷新至少间隔 5 秒。因此删除／释放 Owner 声明会在后续联网判权时生效，名片改为不匹配的撤权有最多 60 秒的缓存窗口。
+
+条件读取响应不进入 SDK 可复用读缓存；大对象下载由 Storage 复核后直接返回或流式代理正文，再次下载会重新检查。服务端缓存按请求触发，无周期名片同步任务。四端调用方式不变，字段和实现边界见[移植指南 ACL 章节](0.5.33-SDK开发与移植指南.md#5-storage-acl从门面贯通到-rpc)。
+
+### 6.3 条件 ACL 的完整使用场景
+
+| 使用场景 | 应用操作 | 验收结果 |
+| --- | --- | --- |
+| 授权自己的直接 sub | `scope: 'direct'`，按需限定名片 | 满足条件的直接 sub 可读；孙级 sub 使用 `descendants` 后才可读 |
+| 授权指定类型的 sub | `type: ['agent']`，`exttype: ['assistant', 'worker']` | 关系和两个属性同时满足；同一属性允许任意列出的值 |
+| 仅按归属授权 | 省略 `card`，保留 `ownership` | Owner 当前单方声明的 sub 适用，不查询 NS 共识或名片 |
+| 新增符合条件的 Agent | Owner 发布该 sub 的 `owner.md`，再访问已有授权目录 | 自动适用已有规则，无需重新枚举或修改授权 |
+| 修改 Agent 名片 | 签名上传新的 `type/exttype`，保留当前归属声明 | 已匹配缓存最多保留 60 秒；不匹配时按至少 5 秒间隔提前刷新，恢复后重新允许 |
+| 转移或释放归属 | 原 Owner 更新／删除其 `owner.md` 声明 | 后续联网判权失效，已有下载票据兑换时也重新检查声明 |
+| 限定业务目录 | 只对 `/reports` 授权 `r` | 可读取其文件和子目录；相邻 `/reports-other` 不适用，写入和删除仍需相应权限 |
+| 更新和撤销规则 | 用归一化后相同的条件 `setAcl/removeAcl` | 相同规则更新或删除；列表展示 `subject`，撤销后的联网读取被拒绝 |
+| 设置期限或次数 | 使用 `expiresAt`、`maxUses` | 到期后拒绝；同一条件规则由所有匹配者共享次数，具体 AID 列表仍各自计数 |
+| 下载大文件 | 使用 VFS `readBytes`，由 SDK 编排票据和 HTTP | 每次下载核对当前条件，正文直出或流式代理，响应使用 `private, no-store` |
+| 保留原 AID 授权 | 选择 `granteeAid` 或 `granteeAids` | 原合法调用继续可用；每次授权目标三选一，禁止同时传 `subject` |
+| 四端协作 | 不同 SDK 分别管理规则、读取和撤销 | Python、Node TS、浏览器 JS、Go 使用同一服务端规则，跨端结果一致 |
+
+每轮验收使用独立 AID、slot 和目录，保存实际服务版本、SDK 版本与用例结果。逐个执行，失败后保留检查点，修复并从失败项续跑；详细用例与真实环境要求见[移植指南 E2E 矩阵](0.5.33-SDK开发与移植指南.md#71-条件-acl-的-ubuntu-docker-e2e-矩阵)。
+
+## 7. Python 独有变化
+
+### 7.1 限流与拥塞等待
+
+| 响应条件 | Python 等待策略 |
+| --- | --- |
+| 有效正数 `retry_after_seconds/retry_after_ms` | 按服务端提示等待，取适用的较长值 |
+| 无有效提示，`-32029/-32429` 且错误文本表明队列／背压／容量拥塞 | 默认 1 秒 |
+| 其它可识别限流 | 默认 60 秒 |
+
+这项调整仅为本轮 Python 变更，TS／JS／Go 没有同等退避修改；应用写请求不会因此自动重试。应用仍需根据单次请求结果决定后续操作。
+
+### 7.2 容量压测 CLI
+
+新增 `aun bench run` 和 `aun bench report`，支持 16 种场景、套件选择、多进程、多身份通道、预算和断点续跑。将 `<issuer>` 替换为目标域，先查看计划，再启动选定场景：
+
+```sh
+aun bench run "<issuer>" --suite messaging --dry-run
+aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033
+aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033 --resume
+aun bench report ".aun-bench/<issuer>/runs/sdk033"
+```
+
+报告提供 JSON／HTML，区分延迟达标容量、稳态吞吐、边界区间和发压端瓶颈。`pubsub` 场景包含发压端的 Bus SDK；未验证的结果或发压端瓶颈不能当作已确认的纯服务端容量。
+
+## 8. 升级与验收
+
+| 检查项 | 验收行为 |
+| --- | --- |
+| 四 SDK 产物 | 核对目标版本 0.5.33；Browser JS 与 Node TS 使用各自包 |
+| 消息兼容 | 已协商／未协商的明文和加密应用控制可投递；普通消息继续工作；SDK 控制由 SDK 消费 |
+| 批次审批 | 同批多个 Agent 可一次选择；逐项显示结果，失败项可单独处理；最终归属以完成事件／共识为准 |
+| 本地优先 | 保存的有效共识可跨 Client／重连复用；无共识或记录变化会查询远端；管理调用强刷 |
+| ACL | 列表及旧单项调用可用、按 AID 独立计数；条件规则按当前 Owner 声明／TTL 名片匹配并共享额度；三种目标互斥，撤销后重新读取被拒绝 |
+| 配套服务 | Gateway／Message／Group 支持兼容路由；Storage 支持批量／条件 ACL、Owner 单方声明检查及 NS 名片 svc 批查缓存；原 EventService 服务依赖继续保留 |
+
+已有版本升级验证包括四端版本一致性、TS 加密回环 17 项、JS 加密回环 13 项、Go E2EE 包及对应类型／vet 检查。控制消息 runner 的 96 格脚本已纳入工作区，但本轮没有取得其完整通过产物；它只关闭发送端能力，不能代表接收端缺少能力的全部组合。详细覆盖与前序定向回归记录见 [parity 验证边界](../../python/CHANGES_FOR_PARITY.md#v0533)。本文整理不代替全量或跨 SDK E2E 验收。
+
+## 9. 长期离线后的弹性补拉
+
+应用继续使用原有消息订阅入口。主连接处理实时消息、页面响应、管理消息与普通 RPC；历史积压由 SDK 按 Gateway 授权选择主连接或专用辅助连接。四 SDK 共用这套协议，应用不创建第二个 AUNClient，也不维护补拉连接池。
+
+### 9.1 在控制面板查看或调整
+
+1. 打开控制面板的 Gateway 配置，选择实际使用的服务／节点／实例作用域。
+2. 检查“启用弹性补拉通道”（`sync_channels_enabled`），按需调整并保存现有配置修订。
+3. 查看各 Gateway 实例的应用状态：`applied` 为已应用，`pending` 为等待应用，`unknown` 为尚无有效诊断；保存成功表示配置已持久化。
+
+开关默认开启，已有显式关闭配置继续生效；页面重开及服务重启后读取配置中心的有效值。仅主辅双能力协商成功的 SDK 可用，承接主连接的同一 Gateway 内，`(aid, device_id)` 跨 slot、主会话合计最多 1 条，当前不跨 Gateway 全局统计。不同设备分别计数，历史资源仍按 AID 汇总。在线修改会下发策略，无需重启 Gateway、应用重新登录或定时查询。本轮 Gateway 按开关与实时压力实际授权 `0/1`，压力可降为 0，关闭时为 0、开启时上限为 1；SDK 按策略支持 `0..N`，当前协议能力和测试覆盖到 2。关闭时停止新增辅助连接，通知已有连接退出，历史任务按当前额度退回主连接。
+
+### 9.2 一次补拉的流程
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as 应用
+    participant S as 主 Client / SDK
+    participant X as 补拉辅助连接
+    participant G as Gateway
+    participant M as Message / Group
+    A->>S: 注册原有消息处理器并连接
+    S->>G: 主连接认证，声明两种弹性能力
+    G-->>S: 主连接 ID、能力结果与当前策略
+    alt 已开启且授权辅助数量大于 0，有历史积压
+        S->>X: 按共享预算申请辅助连接
+        X->>G: short + history_sync + 主连接 ID
+        G-->>X: 同 AID/device/slot 校验及能力协商
+        X->>G: persistent Pull + 页字节上限
+    else 辅助数量为 0，历史额度可用
+        S->>G: 主连接低优先级 persistent Pull
+    end
+    G->>M: 按历史共享额度转发
+    M-->>G: 一页消息与安全扫描位置
+    G-->>S: 经原请求通道返回页面及策略
+    S->>S: 解码、解密、按原游标交付
+    S->>A: 原有消息／批量消息事件
+    A-->>S: 本页处理完成
+    S->>G: 按原规则提交 ACK，释放消费预留
+    Note over S,G: 实时 volatile 独立从主连接 Pull，使用自己的游标
+```
+
+主辅均需协商 `elastic_connections_v1` 与 `sync_channels_v1`。前者提供通用弹性连接，后者授权本轮 `history_sync` 用途；应用无需拼装这些内部参数。
+
+### 9.3 暂停、断线与应用边界
+
+| 情况 | SDK 行为 |
+| --- | --- |
+| 仅 `max_aux_channels=0` | 历史额度可用时退回主连接，小页、低优先级继续 |
+| 历史在途额度或速率为 `0` | 暂停历史，等待 Gateway 主动通知恢复，不占普通 RPC 额度 |
+| 辅助连接被回收或断开 | 保持主 Client 在线；未完成页从安全游标退回主连接，使用剩余请求期限 |
+| 同一策略版本下还有积压 | 记住辅助故障，不自动重连或冷却后补开；重复快照不解禁 |
+| 新策略明确重新授权／新主会话 | 满足最新授权与本地预算后可再次按需申请辅助连接 |
+| 单条消息超过页预算 | 收到 `sync.error`，`code=OVERSIZED_MESSAGE`；该流停止自动续页，其它流继续 |
+
+应用仍按消息 ID 幂等保存或处理消息，顺序使用各 peer／群原有 seq；增加连接不建立跨流的全局顺序。半页、旧主会话页不会推进 ACK；实时临时消息保持原 TTL，过期后不由历史补拉恢复。
+
+SDK 主辅合计沿用 RPC 总额 16、background 8、event 4、pull 4；历史最多占 3 个 pull 名额。同一 namespace 的网络 Pull 串行，不同 namespace 可在 Gateway 策略授权和共享预算允许时并行复用辅助连接；SDK 遵从 `max_aux_channels` 的 `0..N` 策略，当前协议能力和测试覆盖到 2，Gateway 本轮最多授权 1 条，实际并发不等于 1。初始页上限 256 KiB，历史编码预留合计 1 MiB、本地放大预留 8 MiB，预留持续到应用消费结束。慢处理会形成背压，应用应及时完成原有处理器。
+
+配套部署需要 Gateway 的策略／配置能力，以及 Message、Group 的 `storage_scope`、`max_page_bytes` 支持。详细协议与内部流程见[移植指南第 8 节](0.5.33-SDK开发与移植指南.md#8-弹性补拉的四端共同实现契约)；实际验收结果单独记录于[实施计划](../消息弹性补拉通道实施计划.md)。本轮 Gateway 当前授权上限待重新验收；前序测试不证明这项 Gateway cap 更改已通过。