# SREAgent 的 Skill、SOP 与运维知识管理策略报告

| 项目 | 内容 |
|---|---|
| 版本 | v2.1 |
| 更新日期 | 2026-09-28 |
| 决策范围 | 运维智能体可加载资产（Skill、SOP、运维知识、常驻指令）的含义、拆分粒度、组织形式、公共与个性化分工、个性化隔离与降噪，以及这些资产在 SREAgent 中的承载形式（见 §0） |
| 继承文档 | 《SREAgent 架构设计建议》**v1.6**（2026-09-23，下称 v1.6）；《SREAgent 智能体架构决策报告（ADR）》**v1.4**（2026-09-28，`debates/003-sreagent-adr-external-review/SREAgent-架构决策报告-v1.4.md`，下称 ADR）。授权、能力类别、执行契约、数据链、评测与阶段准入**以 v1.6 为准**，本报告只作引用。v1.6 后续版本中收紧安全、授权或准入要求的变更立即生效；本报告与 v1.6 冲突时，以 v1.6 为准 |
| 决策状态 | 讨论收敛：已完成（首轮研讨加五轮复审）。外部独立评审处置：已完成（两轮审议，加提出人定向复核；强模型席位的阻塞项全部闭环，Codex 终稿差异复核通过，见附录 A.7）。组织批准：未进行。生产准入：未进行，按 v1.6 第 9 章逐能力准入。本报告是治理规则，不代表任何机制已通过运行验证 |

---

## 0. 决策范围与结论摘要

### 0.1 本报告决定什么、引用什么

| 事项 | 归属 |
|---|---|
| 资产的类型边界、拆分粒度、分层组织、组合与替代规则 | **本报告决定** |
| 资产注册表字段、发布门禁、生命周期、回退与吊销在资产侧的规则 | **本报告决定**（在 v1.6 §2.4、§4.2、§4.6 之上细化） |
| 公共与个性化资产的协作分工 | **本报告决定** |
| 授权判定、能力类别 L0–L3、能力网关 | 引用 v1.6 §1.5–1.6 |
| 跨应用扩域 | 引用 v1.6 §4.5 |
| 标识体系、证据对象、结构化移交、执行契约与状态机 | 引用 v1.6 §7.1–7.3、§7.7–7.8 |
| 高风险流程的决策与执行分离、写操作协调 | 引用 v1.6 §2.7、§3.5 |
| 智能体拓扑（主控、专家、子智能体） | 引用 ADR |
| 阶段划分与生产准入 | 引用 v1.6 §9.1–9.2；本报告 §9 只给出资产侧交付在各阶段的映射 |

### 0.2 结论摘要

1. **四类资产按作用划分，不按文件形态划分。**
   - **Skill** 管"怎么研判"：程序性内容，按需加载。
   - **运维知识**管"环境是什么样"：信息性内容，只读，按需读取。
   - **SOP** 管"已知情形按什么步骤处置"：需要问责、可审计的规程。其中改变生产状态的步骤，在对应工作流完成登记和准入之前，标注为 `manual`，由人按组织现有的变更流程执行；工作流登记并通过准入之后，改为引用该工作流。模型不按 SOP 文本自由执行（v1.6 §2.7）。
   - **CLI Tools** 管"能取什么证据、能做什么动作"：动作按 v1.6 的能力类别 L0–L3 登记，经能力网关鉴权。
   - 另有**常驻指令**：每次会话无条件注入，必须保持很小。
2. **关系**：Skill 编排研判，引用知识获取事实，经 Tools 取证，按 ID 指向 SOP 给出处置建议。**引用关系不带来任何权限。**
3. **粒度**：
   - Skill：一个决策点，即一个可辨认的故障场景或研判任务。
   - SOP：一次可独立执行、可交接的处置流程。
   - 知识：一个可单独更新、可追溯来源的事实或教训。
   - Tool：一种单一职责的动作，按动作而不是按工具登记。
4. **组织**：
   - 资产分为**平台层 / 技术域层 / 应用层**，另有**环境差异数据**。层与层之间是组合与引用关系，不是继承。
   - 应用通过**具名扩展点**补充技术域层的 Skill，只能追加内容。
   - 需要偏离公共方法时，新建应用专属 Skill，用 `supersedes` 显式替代。平台层资产不可被替代。
5. **分工**：
   - 平台团队：格式、注册表、能力网关、策略、评测与发布门禁、平台层资产、L1 及以上动作。
   - 技术域团队：技术域层的研判方法与工具契约。
   - 应用团队：应用层的画像、Skill、知识、SOP 内容与回放用例。应用侧 Skill 只能调用 L0 动作（v1.6 §2.4）。
6. **隔离与降噪**：
   - 可见性隔离和权限隔离在**检索和调用之前**由服务端生效。统一作用域包含**租户、环境、应用、服务**。授权按 v1.6 §1.6 逐次求交集。
   - 上下文隔离在**加载阶段**控制注入量，手段是分级加载、按阶段定向、子智能体深挖。
   - 目录位置、`allowed-tools`、MCP 工具注解、工作负载身份、模型输出，**都不是**授权依据。
7. **运行时可追溯与可撤销**：
   - 会话冻结资产版本，**只用于复现**；有效授权始终以当前的撤销与限制策略为准。
   - 资产加载前核对注册表摘要，不一致即拒绝加载。
   - 安全吊销的安全底线是加载前和调用时的**同步拦截**，并规定可测的最大传播时效和失联拒绝规则。
8. **持续改进**：
   - 沉淀与发布：草稿 → 内容核验 → 门禁与回放 → 签核 → 按 v1.6 发布链逐级上线。
   - 改变决策语义的知识更新，须反查所有消费者并做定向回归。
   - 回退前重验依赖。

---

## 1. 概念澄清：含义、关系与承载形式

### 1.1 定义

| 资产 | 回答的问题 | 性质 | 在 SREAgent 中的承载形式 | 业界对照 |
|---|---|---|---|---|
| **Skill** | 这类问题怎样研判：何时适用、取证顺序、如何判断、如何排除、输出什么 | 程序性，给模型看；由模型解释执行，因而不确定 | Agent Skills 格式的目录：`SKILL.md` 加可选的 `references/`、`assets/` [1]；企业字段放在 `metadata` 中，按 v1.6 §2.4 的 Schema 填写。**资产包不带可执行脚本**：需要计算或访问系统的逻辑，由平台登记为动作，经能力网关调用；确有例外的，按 v1.6 §4.2 走独立审核沙箱 | Agent Skills 规范 [1]；AWS DevOps Agent Skills [2] |
| **运维知识** | 环境是什么样：拓扑、关键链路、指标含义、阈值、已知异常、历史根因 | 信息性，只读；本身无副作用，但进入上下文后会影响决策，也可能造成泄露 | 三种形式，优先级依次降低：① **结构化事实**（CMDB、拓扑、告警目录、SLO）以权威系统为准，经 L0 查询实时获取，作为证据对象回传（v1.6 §7.3），不写入知识库；② **经验性条目**：Markdown 格式，一条一个事实，带来源、负责人、有效期，按"库 → 条目"两级描述逐层打开 [3]；③ **长文档**（手册、复盘长文）分块做带权限检索 [9]，只在①②都不能回答时使用 | AWS DevOps Agent Memories [3]；Azure SRE Agent 知识库 [5] |
| **SOP** | 已知情形按什么条件和步骤处置：进入与停止条件、恢复条件或补偿、复核 | 程序性，需要问责、可审计 | 有版本、有唯一 ID 的规程，经负责人签核。**诊断方法沉淀在 Skill 中，SOP 只保留处置部分**。进入条件写成可以重新校验的可判定条件。改变生产状态的步骤分两种：执行平面上线前，标注为 `manual`，并注明所走的组织现有变更流程；该步骤对应的工作流登记并通过准入（P4）之后，改为引用动作注册表中已登记的工作流，能力类别与可恢复性说明以注册表为准（v1.6 §1.5、§7.4）。模型不按 SOP 文本自由执行（v1.6 §2.7） | AWS：Runbook 已自动迁移为 Skill [2]；Azure：runbook 作为知识库文档检索 [5] |
| **CLI Tools** | 能取什么证据、做什么动作 | 能力接口；接口确定，返回结果随生产状态变化 | 由能力网关统一暴露，底层可以是 CLI 封装、API 或 MCP Server。**按动作登记**：输入输出 Schema、能力类别（L0 被动读取 / L1 主动诊断 / L2 有界影响处置 / L3 高风险处置）、数据与资源风险属性、作用范围、执行器（v1.6 §1.5、§7.4）。CLI 的边界见 §1.3 | v1.6 §1.5；MCP Tools 规范 [6]；OWASP LLM06 [7] |
| **常驻指令** | 每次会话必须遵守的规则：安全红线、输出格式、环境约定 | 程序性，常驻，无条件注入 | 一份全局 `AGENTS.md`，另按研判阶段各一份，内容保持极简。应用级红线不放在这里，见 §3.2 | AWS agent instructions：建议约 120 行，硬上限 25 KB [4] |

**Skill 与 SOP 的判定规则**：内容偏差需要追责、审计的，归 SOP；内容是在告诉智能体"怎么想"的，归 Skill。以"支付通道超时"为例：

- Skill 写研判：先看哪几个指标，如何区分上游银行问题和自身连接池问题。
- SOP 写处置：通道切换对应的工作流、恢复条件、适用前提。
- Skill 只写"满足条件 X 时，建议执行 `SOP-PAY-012`"，**不复述 SOP 的步骤**。
- 应用侧 Skill 不声明写动作（v1.6 §2.6）。

**事实冲突时的优先级**（只适用于"事实"；"规则与约束"以更上层为准，见 §5.3）：

1. 权威系统的实时数据（Tool 返回的证据对象）
2. 已核验、未过期的应用层知识条目
3. 技术域层、平台层的通用经验
4. 长文档检索片段
5. 已过期但仍在宽限期内的条目：只能作为佐证，不能单独作为结论依据，也不能覆盖更新鲜的事实

草稿永远不会被生产会话加载（§3.3），不参与排序。比较之前，先核对双方指向的环境、资源、时间窗口和数据新鲜度是否一致。确认是同一对象后，以高优先级为准，把冲突写入证据链，并通知低优先级条目的负责人复审。无法确认是同一对象时，保留冲突，结论状态按 v1.6 §7.3 标为 `conflicting_evidence`。

**关于厂商术语**：各家叫法不统一。AWS 把 Runbook 并入 Skill [2]，也允许在自定义 Memory Store 中存放标准规程 [3]；Azure 把 runbook 作为知识库文档检索 [5]。上表是 SREAgent 内部的治理边界，划分依据只有两条：内容是程序性还是信息性，以及会不会改变生产状态。

### 1.2 关系

```mermaid
flowchart LR
    A["告警 / 用户提问"] --> R{"路由<br/>范围硬过滤 + 描述匹配"}
    R -- "确定性注入" --> PF["应用画像"]
    PF --> S
    R --> S["Skill<br/>研判方法"]
    S -- "逐层打开 / 带权限检索" --> K["运维知识<br/>经验条目 / 长文档"]
    S -- "指导调用" --> T["CLI Tools<br/>能力网关逐次鉴权"]
    T -- "L0 查询 / 经准入的 L1 取证<br/>回传证据对象" --> S
    S -- "结构化移交<br/>引用 SOP ID" --> P["SOP"]
    P -- "workflow 步骤<br/>已登记并准入" --> X["处置策略阶段与工作流执行器<br/>审批绑定 / 执行前复核 / 结果核实"]
    P -- "manual 步骤<br/>工作流准入前" --> HM["人工执行<br/>组织现有变更与审批流程"]
    X --> W["生产系统"]
    HM --> W
    I["常驻指令"] -. "始终在上下文" .-> S
```

研判阶段只调用 L0 动作，以及经逐动作准入的 L1 动作。L1 由平台维护的受控取证执行器执行（v1.6 §1.5、§3.5；ADR 边界③）。改变生产状态的 L2/L3 动作只经处置策略阶段和工作流执行器执行（v1.6 §2.7；ADR 边界④）。

### 1.3 CLI 在 SREAgent 中的边界

业界有"CLI + Skill"路线：智能体直接调用命令行工具，Skill 负责说明用法。在 SREAgent 中，CLI **只作为动作的实现形式**，不直接交给模型。理由有三：

- 直接向模型开放任意命令行，难以保证逐次鉴权与审计。
- 参数注入、解释器、重定向、管道等绕过手段，黑名单挡不住 [7]。
- 输出没有结构，难以控制注入上下文的量 [8]。

**通用 shell 和 exec 通道不授予诊断模型**，而是拆成平台维护的、参数受限的固定动作，每个动作单独登记能力类别与风险属性（v1.6 §1.5 判定原则 2）。例如 `collect_thread_dump(pod, duration)` 属于 L1，只有经逐动作准入后，才能由受控取证执行器执行。

### 1.4 演进趋势

以下观察来自截至 2026-09-25 核对的 Agent Skills 规范、AWS 和 Azure 文档，样本有限，厂商产品行为可能变化：

1. **程序性内容与信息性内容分开存放。** AWS DevOps Agent 以前把从调查中学到的内容呈现为 "learned skills"，现在改为作为 Memory 维护；Memory 定位为"信息性知识"，与"程序性"的 Skill 相对 [3]。
2. **Runbook 被吸收为 Skill 格式。** AWS 已把现有 Runbook 自动迁移为 Skill [2]。
3. **分级披露。** 两者都采用"先读名称和描述，命中后再读内容"的加载方式 [1][3]。
4. **常驻指令单独成类**，与按需加载的 Skill 明确区分 [4]。
5. **自动沉淀。** AWS 由后台学习代理提炼根因与工具使用经验，并把用户反馈转成 reflection 记忆 [3]；Azure 支持由智能体把调查发现整理成 runbook [5]。

---

## 2. 拆分粒度

| 资产 | 默认粒度 | 拆得过粗的症状 | 拆得过细的症状 |
|---|---|---|---|
| Skill | 一个决策点，如"数据库连接耗尽诊断""支付渠道超时研判" | 描述写不出清晰的触发条件；正文加载后大半无关 | 按 Metric、Log、Trace 各写一个 Skill，路由时互相争抢 |
| SOP | 一次完整、可交接的处置流程，如"支付通道切换" | 一份 SOP 里有多个互斥分支 | 单条命令也写成 SOP（这种应该是登记的动作） |
| 知识条目 | 一个事实或一条教训；同一阈值或口径只在一处定义，其他地方引用（v1.6 §2.6 第 4 条） | 整本手册切块检索，片段缺上下文 | 碎到单句，丢失来源和适用条件 |
| Tool | 一个语义动作，按动作登记；同一工具的不同参数可能落入不同能力类别（v1.6 §1.5） | `run_shell(cmd)` 包打天下 | 同一个查询按参数拆成十几个动作 |

**尺寸约束**

| 资产 | 约束 |
|---|---|
| Skill | 元数据约 100 token；正文建议少于 5000 token、少于 500 行；细节放到 `references/`；文件引用只下探一层 [1] |
| 知识条目 | 一条一个事实或教训；只存结论，不存原始数据 [3] |
| 常驻指令 | 约 120 行（建议值），25 KB（硬上限）[4] |
| 应用画像 | 须设尺寸上限，并与常驻指令合并计入常驻 token 预算（§3.2） |

**`description` 就是路由接口。** 描述要同时写清"做什么"和"何时用"，写明排除条件和替代 Skill，并带上症状、服务名、错误类型等判别性关键词 [1][2]（v1.6 §2.6）。描述含糊或缺失时，Skill 可能被整个跳过 [2]。

**Tool 为模型而设计** [8]：
- 合并多步操作；
- 只返回高信号的信息；
- 默认提供分页、过滤或截断；
- 报错信息要可操作；
- 用服务名或资源名作前缀，区分命名空间。

---

## 3. 组织形式

### 3.1 分层结构

```mermaid
flowchart TB
    subgraph Assets["资产层（组合 / 引用，非继承）"]
        P["平台层<br/>通用研判框架、输出规范、常驻指令"]
        D["技术域层<br/>MySQL / Redis / Kafka / K8s / 网络 研判 Skill 与工具契约"]
        A["应用层<br/>应用画像、专属 Skill、扩展内容、SOP 内容、知识、回放用例"]
    end
    E["环境差异数据（非资产层）<br/>仅限没有权威系统来源的环境差异值"]
    A -. "引用 / 向扩展点追加" .-> D
    A -. "引用" .-> P
    D -. "引用" .-> P
    A -. "按环境读取" .-> E
```

资产分层与 v1.6 的能力类别 L0–L3 是两个维度，互不对应：分层回答"谁维护、谁可见"，能力类别回答"动作会产生什么影响"。

参考布局如下。应用层资产的目录结构与 v1.6 §4.4 的能力包契约对齐。每个应用使用独立仓库或目录，用 CODEOWNERS 约束写权限。`data_class` 为敏感级的资产，必须放在独立仓库或受控存储中，**编写阶段的读权限也要控制**。

```text
sreagent-assets/
├── platform/                          # 平台层（平台团队）
│   ├── AGENTS.md                      # 全局常驻指令
│   ├── agents/{triage,rca,mitigation}.md
│   └── skills/latency-triage/SKILL.md
├── domains/                           # 技术域层（技术域团队）
│   └── mysql/skills/mysql-connection-exhaustion/
│       ├── SKILL.md                   # 正文预留具名扩展点
│       └── references/
└── apps/payment/                      # 应用层（应用团队，v1.6 §4.4 能力包）
    ├── package.yaml                   # 应用 ID、owner、请求的可见范围、内核 API 版本、请求的动作清单
    ├── profile.md                     # 应用画像（信息性，确定性注入）
    ├── skills/payment-channel-timeout/SKILL.md   # 仅调用 L0 动作
    ├── extensions/mysql.conn-exhaustion.md
    ├── queries/                       # 参数化只读查询模板
    ├── topology/                      # 业务依赖声明
    ├── sops/SOP-PAY-012-channel-switch.md        # 处置规程内容；工作流由平台登记
    ├── knowledge/
    ├── evals/
    └── env/prod.yaml                  # 环境差异数据；不含审批信息
```

### 3.2 公共层与个性化层的组合方式

- **应用画像**（`profile.md`）是信息性的应用层入口，内容包括：
  - 组件、依赖服务、SLO：装配时从 CMDB 和 SLO 系统渲染，不手写；
  - 关键请求链路的说明：手写；
  - 专属 Skill 和 SOP 的索引：由注册表自动生成，不手写症状映射；
  - 应用级红线，例如"账期窗口禁止切流"：这里只是给模型的说明，强制执行靠平台登记到策略中的规则（§4）。

  **画像不参与任何范围或授权判定**，也不参与描述匹配。会话范围命中该应用后，画像由路由层确定性注入。超出尺寸上限的部分放进知识条目，按需打开。AWS 的环境理解记忆也采用"系统总览 + 每个逻辑容器一份 + 每条关键请求链路一份，先读索引"的结构 [3]。
- **具名扩展点，只能追加**：
  - 技术域层 Skill 在正文中预留扩展锚点。加载时，装配层把 `{app}/extensions/<锚点>.md` 拼接到锚点处；应用没有定义扩展时，折叠该锚点，不向模型暴露未解析的占位符。
  - 只装配主范围应用的扩展内容。
  - 扩展内容须经对应技术域负责人审阅，并纳入冲突检查和回放评测。无论写了什么，扩展内容都改变不了权限、审批或工具边界。
- **需要偏离时，显式替代**：新建应用专属 Skill，在元数据中写 `supersedes: <技术域层 Skill ID>`。
  - 替代是确定性的：范围内存在已发布、且适用于当前环境、阶段、范围和会话所在发布通道的专属 Skill 时，被替代的 Skill 在候选集阶段就被剔除，不交给模型选择。
  - `supersedes` 须经被替代资产的负责人审阅。
  - **平台层资产不可被替代**（v1.6 §4.3 闸 2："`core-*` 优先且不可被覆盖"）。
- **不做继承、抽象基类或 SPI 钩子**：自然语言资产没有编译期检查，多层覆盖之后，"模型最终看到了什么"无法推断。
- **环境差异数据只放没有权威系统来源的值**。资源 ID、告警阈值这类已有权威来源的数据，只存引用键，值实时查询。环境差异数据**不承载**审批策略或审批人。
- **个性化的单位是应用 / 服务**：值班人员或团队的个人偏好（语言、详略、常用看板）只影响输出呈现，不进入资产目录，不影响可见范围，也不参与授权。

### 3.3 注册表最小元数据

Skill 的企业字段按 v1.6 §2.4 放在 `metadata` 中（例如 `BANK.scope`、`BANK.capability-classes`）。注册表另外为所有类型的资产维护以下字段：

| 字段 | 说明 |
|---|---|
| `id / name / layer / owner / reviewer / version` | 基本标识；`layer` 取平台层、技术域层、应用层之一 |
| `status` | `draft`：草稿或候选。只在隔离的回放评测环境，以及 v1.6 发布链的 Shadow 环境中加载，永远不会被生产会话加载<br/>`active`：已签核发布，生效范围由 `channel` 限定<br/>`inactive`：暂停，可恢复；过期后超过宽限期的知识转入此状态<br/>`deprecated`：计划下线<br/>`revoked`：安全吊销，见 §6 |
| `channel` | `canary` / `production`，对应 v1.6 §4.2 的发布通道，只适用于 `active` 资产。v1.6 §4.3 闸 5 所说的"上一已验证版本"，指曾以 `production` 通道稳定运行的版本 |
| `scope` | **租户**、环境、应用、服务。发布范围受发布者权限约束，应用团队不得发布全局资产（v1.6 §2.4） |
| `exposure` | 仅适用于应用层资产，取值 `internal`（默认）或 `contract`。只有 `contract` 资产会下发给依赖范围会话（§5.1-1）；标为 `contract` 须经资产所属方负责人审批；`contract` 资产不得引用本应用的 `internal` 资产 |
| `phase` | triage / rca / mitigation / generic。按阶段定向加载，可以降低上下文消耗 [2] |
| `depends_on / refs / extends / supersedes` | 依赖、引用、扩展、替代关系。注册表据此维护**反向引用索引**，用于知识变更影响分析（§8）和回退前的依赖校验 |
| `semantic_class`（知识条目、画像手写部分、`topology/`、环境差异数据） | `decision`（阈值、判据、拓扑、依赖关系）或 `descriptive`（措辞、案例说明），决定变更后的回归要求（§8） |
| `data_class` | 数据敏感级别，决定存储位置和读权限 |
| `review_by / valid_until` | 复审日期、有效期 |
| `eval_set` | 关联的回放用例 |
| `origin` | `human` / `agent-generated` |
| `digest / provenance` | 内容摘要（加载时校验，§6）与来源证明（v1.6 §4.6） |
| `step_kind` / `workflow_refs`（仅 SOP） | 每个改变生产状态的步骤标注 `manual` 或 `workflow`：<br/>- `manual`：注明所走的组织现有变更流程；<br/>- `workflow`：须引用已登记的工作流或动作 ID，能力类别与可恢复性说明以动作注册表为准（v1.6 §7.4）。<br/>平台登记工作流时声明它实现哪条 SOP 的哪一步（`implements: <SOP-ID>#<step>`），校验器据此判定对应关系。<br/>对应的工作流登记并通过准入后，**新发布**的 SOP 版本中该步骤不得再标为 `manual`。注册表按反向引用通知 SOP 负责人，在平台策略配置的期限内发布引用该工作流的新版本。替代版本发布之前，已发布的旧版本继续有效 |

---

## 4. 公共与个性化的协作分工

| 事项 | 平台团队 | 技术域团队 | 应用团队 |
|---|---|---|---|
| 资产格式、注册表、校验工具链、评测框架 | **负责** | 咨询 | 使用 |
| 能力网关、动作注册表、策略、审计（v1.6 §1.5–1.6、§7.4） | **负责** | 提供工具契约 | 申请动作与权限 |
| L1 取证动作、L2/L3 工作流的登记与维护 | **负责** | 提供技术动作建议 | 提出需求 |
| 审批要求：由能力类别与风险属性组合决定，例如 L3 须强制人工批准加双人复核（v1.6 §1.5） | **负责**，与安全团队共同制定 | 咨询 | 知会 |
| **应用加严规则**：应用红线、更高的审批要求 | 审核，登记为有版本的策略 | 咨询 | 提出 |
| 平台层 Skill 与常驻指令 | **负责** | 咨询 | 知会 |
| 技术域层 Skill、扩展锚点、工具契约 | 审核 | **负责**，并审阅各应用提交的扩展内容 | 反馈 |
| 应用层画像、专属 Skill（仅 L0）、扩展内容、知识、查询模板 | 提供模板与准入门禁 | 咨询 | **负责** |
| SOP 内容：适用条件、步骤、恢复条件说明 | 登记对应的工作流 | 审核技术动作 | **负责** |
| 回放用例 | 维护框架 | 提供本领域用例 | 提供本应用用例 |

**策略只以平台登记的版本为准。** 实际生效的约束 = 平台策略 ∪ 已登记的应用加严规则，取二者中更严的一方；应用规则只能收紧，不能放宽。画像、SOP、环境差异数据中关于审批或红线的文字，只是给模型和人看的说明，能力网关和执行器不读取。每项资产指定唯一的内容负责人和复核人。

**发布门禁**：与 v1.6 §4.2 的发布链对应。门禁 1–4 通过后，资产以 `draft` 状态进入 Shadow；Shadow 对比达标并经发布签核后，转为 `active`，先以 `canary` 通道、再以 `production` 通道生效。门禁编号不代表执行顺序：内容核验在评测之前，发布签核在评测之后。

1. **契约校验**：
   - frontmatter 与 `metadata` 合规；行数和 token 不超标 [1]。
   - 引用的 SOP、知识 ID 存在，且版本有效。
   - SOP 中 `workflow` 类步骤引用的工作流已登记并通过准入；`manual` 类步骤须注明变更流程，且按 `implements` 声明，其对应的工作流尚未通过准入。
   - `contract` 资产不引用本应用的 `internal` 资产。
2. **能力推导与策略校验**：按 v1.6 §2.4，由可调用动作反查动作注册表，推导出能力类别集合。应用层 Skill 只能调用 L0 动作；每个动作的属性组合都必须有合法策略。
3. **冲突与禁止项扫描**：
   - 同一可见范围内，描述高度重叠的资产要拦截，或说明理由。
   - 同时加载的应用层与技术域层 Skill 在研判方法上存在实质冲突时拦截，要求改用 `supersedes`。
   - 重复定义的阈值或口径要拦截。
   - 可执行脚本、hook、动态 shell 要拦截（v1.6 §4.2）。
   - 注入测试：在资产正文中嵌入恶意指令，验证不会被执行。
4. **回放评测**：在隔离环境中加载候选版本。基线在评测候选版本之前建立。按资产类型适用的检查项与指标如下：

   | 资产类型 | 必过检查 | 适用的行为指标 |
   |---|---|---|
   | Skill、扩展内容、`supersedes` | 1、2、3 | 命中率、误触发率、根因准确率、证据引用有效率、无关资产量 |
   | 知识条目 | 1、3 | `decision` 类：按反向引用对消费者做定向回归（§8）；`descriptive` 类：免回归，由审核人确认 |
   | SOP | 1、3；步骤类型标注完整 | 研判回放只校验 SOP 推荐与路由是否正确；步骤的正确性由负责人审阅和安全审阅保证，执行正确性按 v1.6 §7.8 在 P4 工作流准入时验证 |
   | 常驻指令、画像模板 | 1、3；尺寸上限 | 全量回归 |
   | 画像手写部分、`topology/`、环境差异数据 | 1、3 | 按知识条目的 `decision` / `descriptive` 规则处理。`topology/` 只提供候选依赖，不作为依赖范围的授权来源（§5.1-1） |
   | `queries/` 查询模板 | 1、2、3；类型化参数与行数、扫描成本、时间窗上限（v1.6 §4.4） | 按引用它的 Skill 做定向回归 |

   Tool 与动作契约不在本表范围内，由平台按 v1.6 §7.4 管理；契约变更后，按反向引用对引用它的 Skill 做定向回归。

   首版的对照基线是"不加载 Skill、仅用工具研判"的结果或人工值班结论；之后以 `production` 通道上的 `active` 版本为基线。会波动的指标采用多次运行加容差判定，次数与容差由评测契约确定（v1.6 §8）。
5. **负责人审阅**：分两步。内容核验在评测之前，核对事实是否正确；发布签核在评测之后。

**上收路径**：应用层中有通用价值的内容，先去除私有标识和敏感数据，经技术域负责人和平台审阅后，才能进入技术域层或平台层。

---

## 5. 个性化部分的隔离与降噪

### 5.1 三道防线

```mermaid
sequenceDiagram
    participant E as 告警(tenant, app=payment, env=prod)
    participant G as 会话网关
    participant C as 资产目录
    participant A as SREAgent
    participant T as 能力网关
    E->>G: 事件
    G->>G: 身份与资源目录校验<br/>tenant, env, primary={payment}, dependencies=[account]
    G->>C: 按范围硬过滤，冻结资产版本清单
    C-->>A: 平台层 + 相关技术域层 + payment 应用层元数据与画像<br/>+ account 的 exposure=contract 资产（摘要校验通过）
    A->>A: 描述匹配 → 加载少量 SKILL.md → 按需读 references
    A->>T: 动作调用（携带会话范围）
    T->>T: 查吊销状态 + 按 v1.6 §1.6 求交集鉴权
    T-->>A: 证据对象（标注来源，作为数据）
```

**1. 可见性隔离（检索之前，服务端生效）**

- **统一作用域** = 租户 + 环境 + 应用 + 服务，由身份与资源目录校验得出，不采信模型输出、告警文本或资产自报的值（v1.6 §1.6 硬性要求 2）。以下各环节使用同一个作用域，缺失或冲突时默认拒绝：
  - 候选资产
  - 检索索引及其**缓存键**
  - 原文获取
  - 能力网关
  - 执行凭据
  - 审计查询
- 创建会话时，校验发起主体（自动会话以事故授权为准）是否有权访问主范围。之后每次读取资产、获取原文、检索知识，都要与该资格、`data_class`、作用域求交集；校验不通过时，连资产的名称和描述都不下发。
- 范围分两级：
  - **主范围**（primary）：被排查的应用。
  - **依赖范围**（dependencies）：服务目录中登记的直接依赖。只下发 `exposure=contract` 的资产（接口、SLO、对外告警、联系人）和 `dependency_visible` 的公共健康度 L0 动作。调用这类动作时，网关还要校验入参资源确实属于登记的直接依赖。这是经被暴露方与平台审批、登记进策略的常设授权，即 v1.6 §4.5 第 2 步所说的"授权范围内扩域"。
- 告警正文、日志、应用画像、模型输出，都不能改变范围。
- 知识检索必须带权限：每个块都存有访问控制元数据，在**检索时**校验；租户 A 的块绝不能被租户 B 的查询召回 [9]。
- MCP 规范允许 `tools/list` 按请求所带的授权返回不同的工具集 [6]，可以借此实现"每个会话只看到本范围的工具"。

**2. 上下文隔离（加载阶段）**

- **分级加载**：先只给元数据（约 100 token/个），命中后加载正文，需要时再读资源 [1]；知识按"库描述 → 条目描述 → 全文"逐层打开 [3]。
- **按阶段定向**：triage、RCA、mitigation 各自只加载本阶段的 Skill 和常驻指令 [2][4]。
- **子智能体隔离长链路调查**：子智能体只加载对应技术域层的 Skill 深挖，只回传证据对象或浓缩摘要。Anthropic 描述的做法是：子智能体可以消耗数万 token 探索，只回传约 1000~2000 token 的摘要 [10]。拓扑与委派规则按 ADR（星型，不递归派生）。这里的"跨域"指跨技术域，不扩大跨应用的权限。
- **动作集随范围装配**：如果人都说不清该用哪个工具，模型也不可能做得更好 [10]。
- **常驻指令保持极简** [4]。

**3. 权限隔离（调用阶段，服务端生效）**

- 授权判定**以 v1.6 §1.6 为准**：已认证主体的权限 ∩ 目标租户 / 环境范围 ∩ 平台动作注册表的策略 ∩ 本次会话被授予的范围 ∩ 有效的审批。每次调用都重新鉴权。
- 凭据留在受控执行器，模型只见引用（v1.6 §1.6 硬性要求 4）。
- 能力网关对下游观测系统实施限流和并发配额；执行器舱壁与资源保护按 v1.6 §4.4。
- 以下**都不是**授权依据：
  - Skill 元数据、目录位置、命名空间、模型的选择。
  - **工作负载身份**（如 SPIFFE ID、服务 JWT）：只证明"调用方是谁"，不证明"能对哪个资源做什么"。
  - `allowed-tools`：规范将其标注为实验性字段，含义只是"预先批准"，各实现的支持程度不同 [1]。
  - MCP 工具注解：规范要求客户端视其为不可信，除非来自可信服务器 [6]；官方博客也明确说它不是强制控制 [11]。
  - 能力包自报的类别或范围：只能请求权限，不能定义权限（v1.6 §1.6）。
- OWASP LLM06 的缓解措施作为基线 [7]：
  - 最少扩展、最小功能、避免开放式扩展、最小权限；
  - 以用户身份执行；
  - 高影响操作需人工批准；
  - 在下游系统完整鉴权。

### 5.2 跨应用依赖

跨应用的资产访问按 v1.6 §4.5 执行：

1. **授权范围内扩域**：§5.1-1 所述的依赖范围，即 `contract` 资产与 `dependency_visible` 动作。
2. **超出授权范围的跨应用取证**：只能通过**联合事件授权**或**委托取证**进行，两者都经审批，有范围、有期限。此项在 v1.6 的 P3 开放。
3. **扩域被拒或证据不可共享时**：结论状态标为 `insufficient_evidence`，列明缺失的依赖和原因，**不得静默收敛为已确认根因**。

脱敏后上收的公共资产不属于跨应用访问，按普通的技术域层或平台层资产处理。不允许仅凭文本相似召回另一个应用的私有知识；语义相似度只用于排序，不能扩大权限。

### 5.3 不可信内容

按信任来源，分三类处理：

- **运行时内容**：日志、工单、复盘、检索到的知识片段、工具返回结果。
  - 一律作为带来源的**证据数据**处理，在结构上与指令分开 [12]。它们不能修改规则、扩大范围或触发动作。
  - MCP 规范**建议**（SHOULD）客户端在把工具结果交给模型之前先做校验 [6]。**SREAgent 内部要求**：能力网关对工具返回强制做 Schema 校验和来源标注。
  - 知识入库时记录来源、版本和哈希，检索结果保留出处 [9]。
- **已发布的信息类资产**：应用画像、知识条目。作为带出处的事实参考，不能修改规则、扩大范围或触发动作。
- **已发布的指令类资产**：Skill、扩展内容、常驻指令，以及 SOP 中供模型阅读的部分。
  - 它们的信任来自发布门禁、负责人审阅和供应链校验（§4、§6），加载后按指令生效。
  - 同时加载时，指令优先级为：平台常驻指令 > 平台层 Skill > 技术域层 > 应用层。扩展内容按应用层处理；已被 `supersedes` 替代的资产不参与排序。
  - 研判方法上的实质冲突由发布门禁拦截（§4 门禁 3）。运行时的优先级只作兜底。
  - 即使内容有问题，也无法改变权限、审批或动作边界：能力网关与执行器兜底。

内容过滤只是辅助手段，不能替代确定性的权限控制。

### 5.4 候选集规模

默认做法是"元数据硬过滤 + 模型读描述匹配"。过滤后候选仍然过多、描述列表占用明显时，再按 v1.6 §2.2–2.3 的条件启用语义预筛。阈值、Top-N、步数上限、超时等参数，目前没有可核实的通用数值，**由本组织的回放评测确定**。

---

## 6. 版本、供应链与审计

- **会话版本清单**：会话开始时冻结所用的 Skill、SOP、知识、工具、策略、拓扑的版本（v1.6 §4.6、§7.2）。冻结的版本**只用于复现决策输入**；有效授权始终以当前的撤销与限制策略为准，每次调用记录实际生效的策略版本（v1.6 §1.6）。
- **加载时完整性校验**：每次加载资产，都用可信注册表中的 `digest` 核对实际内容。不一致即拒绝加载，并写入审计。这项校验自 P0-B 起强制执行。摘要只负责内容锁定与篡改检测，**不证明由谁授权发布**；来源证明按 v1.6 §4.2、§4.6 随发布链建立 [13]。
- **两类撤回**：
  - **常规停用**（`inactive` / `deprecated`）：只影响新会话。
  - **安全吊销**（`revoked`，用于恶意或被篡改的资产；吊销到具体版本）。已进入模型上下文的内容无法撤回，所以吊销的**安全底线是同步拦截**：
    - **加载前**：待加载资产的 ID 与版本在吊销列表中，就拒绝加载。
    - **调用时**：会话已加载的资产集合与吊销列表有交集，就拒绝该会话后续的动作调用与处置提交，并中断会话。
    - **时效与失联**：吊销在约定的**最大传播时效**内生效。该时效必须可验证，在准入测试中验收。能力网关与执行器无法确认当前吊销状态时（如与策略服务失联超时），**拒绝新调用**（v1.6 §1.6 硬性要求 8）。
    - **主动通知**：会话控制器主动下发吊销事件，用于尽早中断生成。这一步是减少无效输出的措施，不是安全保证。
    - **已送达的输出**：无法收回。按装配审计反查所有加载过该版本的会话（包括已结束的），异步追加吊销警示，标记"须人工复核"，并通知相关人员。
    - **恢复**：只能用剔除该资产的新版本清单重建会话，或交由人工处理，不能在原上下文上继续。
- **不可变版本，优先停用**：每次更新都生成不可变版本，可查历史 [3]；优先停用，不直接删除 [2]。
- **装配审计**：每次诊断记录以下内容：
  - 候选集
  - 实际加载的资产 ID、版本与摘要校验结果
  - 扩展点的装配结果
  - 画像渲染结果的摘要，以及所用 CMDB 数据的时间戳
  - 调用的动作与授权判定
  - 证据链与结论
- **分层审计与数据最小化**：业务审计层记录身份、作用域、资产版本、动作 ID、参数摘要、审批、结果、证据引用，敏感字段脱敏；原始交互轨迹进入受控存储，设保留期。数据分类、留存与删除按 v1.6 §7.9。

---

## 7. 写操作与 SOP

- **决策与执行分离，按 v1.6 §2.7**：
  - 模型只提交**结构化移交**（v1.6 §7.7），内容包括建议的 SOP 与工作流、目标、参数、证据、反证、前置条件。
  - 处置策略阶段负责适用性校验和选择已登记的工作流；工作流执行器负责执行、复核和核实。
  - Skill 中不允许出现裸写步骤。
- **执行契约以 v1.6 §7.1–7.2、§7.8 为准**，包括：
  - `operation_id`、幂等键
  - 目标资源的不可变身份与代次
  - 审批与参数摘要、目标代次、版本绑定
  - `owner_epoch`
  - 超时与回包丢失时进入待核实状态
  - 成功只以原审批目标的业务后置条件为准
  - 补偿与成功分开记录

  适用范围：L1 取证动作使用简化状态机，随逐动作准入落实（P1 起）；L2/L3 使用完整状态机，随逐工作流准入落实（P4）。
- **能力类别与审批**：SOP 中每个 `workflow` 类步骤，其能力类别（L2 / L3）与可恢复性说明以动作注册表为准。L2 的判据是"恢复条件可验证"，而非"可逆"；L3 须强制人工批准与双人复核（v1.6 §1.5）。本报告不另设可逆性分类或审批人数。
- **执行平面上线之前（P0-A 至 P3）**：SOP 以人工执行文档的形式存在，Skill 只输出建议，由人执行。
  - 这些人工动作**仍须**经过组织现有的变更管理、审批与应用红线流程。
  - 模型建议与 SOP 文本都不构成批准，也不代表模型获得了写权限。
  - SOP 的 ID 与版本从 P0-A 起进入注册表，Skill 对 SOP 的引用自始可校验。改变生产状态的步骤此时标注为 `manual`（§3.3）；进入 P4 后，逐步骤改为引用已登记的工作流，并完成准入。

---

## 8. 持续改进

```mermaid
flowchart LR
    subgraph Loop1["沉淀与发布环"]
        I["事故/研判结束"] --> F["人工反馈<br/>根因是否正确"]
        F --> D["生成草稿（draft）<br/>附源证据、标注 agent-generated"]
        H["人工编写 / 存量分拣"] --> D
        D --> V["内容核验"]
        V --> E["门禁 + 回放评测<br/>含知识变更的定向回归"]
        E -->|未达标| D
        E -->|达标| SG["发布签核"]
        SG --> M["Shadow → Canary → Production"]
    end
    subgraph Loop2["日常治理环"]
        M --> O["线上监测与质量熔断"]
        O -->|指标退化| RB["停用 / 回退到上一已验证版本"]
        M --> X["到期复审 / 零命中巡检"]
        X -->|需更新| D
        X -->|过期未复审| DG["降权为佐证并标注已过期<br/>宽限期满转为 inactive"]
        X -->|确认废弃| AR["下线归档"]
    end
```

- **草稿管控**：
  - 人工编写和智能体生成的新版本，都从 `draft` 开始。
  - 智能体生成的内容必须附上源证据链接，标注 `origin: agent-generated`，并按 `data_class` 先做脱敏。
  - 核验人不得是触发该事故会话的操作者；高风险知识须两人核验。
- **知识变更的影响分析**（v1.6 §2.5）：
  - 对 `decision` 类知识（阈值、判据、拓扑、依赖关系）的任何变更，都要按注册表的反向引用索引，找出直接和间接引用它的 Skill 与应用，对这些消费者的回放用例做定向回归，通过后才能发布。
  - `descriptive` 类变更可以免回归，但须由审核人确认它确实没有改变判据。
  - 验收用例：一个被多个应用引用的共享阈值更新后，能反查出全部受影响的消费者，并完成它们的回归。
- **回退**：把上一个不可变版本重新激活，不需要重新走草稿流程和模型评测，但激活前**必须重新校验**以下四项：
  - 它引用的 SOP、知识、工作流、Tool 契约仍然存在；
  - 版本兼容；
  - 没有被吊销或下线；
  - SOP 的步骤类型仍然合规：`workflow` 类步骤引用的工作流仍然有效；某个 `manual` 类步骤如果此后已有对应工作流通过准入，则不得回退到这个版本。

  任何一项校验失败都不得激活，只能停用。执行器不可用时的应急人工处置，按组织现有的变更流程执行，不通过回退 SOP 版本实现。质量熔断时自动回退的目标，限于"上一已验证版本"（v1.6 §4.3 闸 5）。
- **过期治理**：知识条目必须有 `valid_until` 或复审日期。过期后，在宽限期内只能作为佐证加载，并标注"已过期"（§1.1 第 5 位），同时通知负责人；宽限期满仍未复审的，转为 `inactive`。长期零命中的资产进入清理候选。
- **度量指标（按应用统计；定义与目标值按 v1.6 §8.4、§10.2）**：

  | 指标 | 定义 |
  |---|---|
  | Skill 命中率 / 误触发率 | 实际加载集合与回放用例中"期望加载资产集合"的比对 |
  | 根因准确率 | 结论与复盘结论的比对 |
  | 证据引用有效率 | 引用的证据可解析、且支持结论的比例 |
  | 无关资产量 | 已加载、但未被最终证据链引用的资产数或 token 数 |
  | 越权拦截率 | 按 Skill 统计被能力网关拒绝的调用占比 |
  | 其他 | 每次调查的 token 数与步数、知识过期率 |

- **回放用例**：每条用例必须标注"期望加载资产集合"。证据不足、被拒绝、未解决的难样本也要保留，避免只用成功案例高估效果。

---

## 9. 分阶段落地与验收

阶段划分与生产准入以 v1.6 §9.1–9.2 为准。下表只列出资产侧的交付与准入测试在各阶段的映射。

| v1.6 阶段 | 资产侧交付 | 本阶段须通过的资产侧准入测试 |
|---|---|---|
| **P0-A 契约冻结** | 资产格式与注册表 Schema（含租户作用域、`exposure`、`semantic_class`、`digest`、反向引用）；SOP 的 ID 与版本入册；契约校验器 | 契约校验器可运行 |
| **P0-B 最小实现（非生产）** | 注册表与装配；会话范围解析（身份与资源目录，主范围与依赖范围）；加载时摘要校验；版本清单与装配审计；最小吊销能力（手动吊销，阻断新会话、终止进行中会话；网关吊销检查）；门禁 1–5 与回放评测；存量文档分拣（按 §1.1 拆成 Skill、SOP、知识，以草稿形式走核验） | ① ② ③（只读凭据）④a ⑤ ⑥a ⑧ |
| **P1 生产诊断试点** | 平台层、技术域层资产，以及试点应用的文本类应用层资产上线生产。文本类资产以下列为限：画像、仅调用平台已登记 L0 动作的 Skill、扩展内容、知识、`topology/`、环境差异数据、SOP 内容。这些资产，由平台发布链代为发布。依赖 App Capability Service 的 `queries/` 模板随 P3 上线（v1.6 §4.4、§9.1）；L1 取证动作逐动作准入（简化执行契约）；吊销同步拦截与最大传播时效、失联拒绝；知识变更定向回归 | ④b ⑥b ⑨；L1 动作按 v1.6 逐项准入。P1 生产接入前，v1.6 §9.1 列出的前置条件须全部满足 |
| **P2 诊断增强** | 子智能体跨技术域并行取证；语义预筛（按 v1.6 §2.2 条件启用）；智能体生成草稿的流程；画像按研判阶段裁剪 | ⑤（子智能体约束） |
| **P3 生态共建** | 应用自助发布链；由 App Capability Service 承载的 `queries/` 模板；上收机制；跨应用联合事件授权与委托取证（§5.2） | ① 扩展至联合授权与委托取证；④b 扩展至自助发布的资产 |
| **P4 处置与扩展** | SOP 对应的工作流登记与准入（登记时声明 `implements`），相关 SOP 随后发布切换为 `workflow` 步骤的新版本；平台审批策略与应用加严规则；L2 逐工作流准入，L3 另行决策 | ⑦ |

**资产侧准入测试**（每项同时核验：拒绝结果、下游资源状态、审计记录）：

1. **隔离**：跨租户碰撞与伪造租户；跨应用检索与缓存隔离；依赖范围不能访问对方的 `internal` 资产和深层动作；无权的发起主体拿不到主范围资产的名称和描述。
2. **伪造**：伪造告警标签或作用域；试图通过修改画像扩大范围。
3. **凭据**：失效、过期或受众错误的凭据。
4. **注入**：
   - ④a：日志与工具返回内容中的注入，不能扩大范围或触发动作。
   - ④b：恶意知识、SOP、扩展内容。
5. **越权与约束**：越权的动作参数；资产包夹带脚本或 hook；子智能体违反约束（递归派生、专家之间直接通信、超出并发或时限）。
6. **吊销**：
   - ⑥a：手动吊销后，新会话被阻断，进行中的会话被终止，网关拒绝对应调用，并留有审计记录。
   - ⑥b：加载前与调用时的同步拦截；最大传播时效；失联时拒绝新调用；反查已结束的会话。
7. **执行契约**（按 v1.6 §7.8）：
   - 成功但回包丢失后重试
   - 同名资源被替换（目标代次变化）
   - 执行所有者切换（`owner_epoch`）
   - 审批后目标变化
   - 应用规则试图放宽平台策略
8. **完整性**：资产内容与注册表摘要不一致时，拒绝加载并写入审计。
9. **知识影响分析**：共享阈值更新后，能反查出全部直接与间接消费者，并完成它们的定向回归；回退时引用失效的旧版本被禁止激活。

原则：**某项能力在哪个阶段开放，对应的拒绝测试就必须在该阶段通过**，并且各阶段累计回归。静态配置审查只能证明规则已写入，不能证明生产边界有效。

**需要补齐的组织输入**：服务与数据权限矩阵（含租户）、现有动作与工作流清单、带归属和真实噪声的历史事故样本。

---

## 10. 少数意见（保留）

以下意见不改变 §0–§9 的结论，保留下来作为实施细则或后续版本的候选。M1–M10 的编号沿用 v1.5.1；M11 起是本轮外部评审处置中新提出的意见。v1.5.1 中的 M2、M3、M4、M6、M8、M9、M10 已在本版纳入正文（见附录 A.7），不再列出。

| 编号 | 意见 | 提出席位 | 对应章节 | 主张 | 依据 | 与报告结论的差异及影响范围 |
|---|---|---|---|---|---|---|
| M1（部分保留） | 发布门禁按风险分级签核，以缓解人工节点的吞吐压力 | Claude strategy-analyst；Claude code-reviewer | §4、§8 | 低风险知识条目走"内容核验 + 格式校验 + 抽样回放"；两步签核只用于 Skill、扩展内容、`supersedes`、SOP 和高风险知识 | 推理：P3 应用自助接入后，人工审阅节点会成为吞吐瓶颈 | 已纳入正文的部分：按资产类型适用门禁、波动指标多次运行加容差（§4 门禁 4）。保留的部分：分级签核与抽样回放，只影响执行成本 |
| M5 | 能力网关应按技术域设置舱壁隔离与自适应熔断 | Antigravity backend-architect | §5.1-3 | 下游过载时，网关应返回结构化的背压信号，而不只是静态限流 | Circuit Breaker、Bulkhead 模式（Michael T. Nygard,《Release It!》）；v1.6 §4.4 已要求执行器舱壁 | 不改变结论，作为能力网关详细设计的参考 |
| M7 | 越权拦截率偏高时，应分类排查原因 | Claude research-synthesizer | §8 度量指标 | 按拒绝原因分项统计：Skill 指引越界、动作装配与范围不一致、注入诱导、参数错误 | 推理：`tools/list` 已按授权裁剪 [6]，剩余的拒绝也可能来自注入或依赖登记不全 | 指标不变，只影响解读方式和跟进责任人 |
| M11 | 吊销时，已生成但尚未送达的输出应有处理细则 | Codex security-auditor | §6、§9 | 在实施设计中明确这类输出如何中断、如何标记 | 推理：§6 已承认进入上下文的内容和已送达的输出都无法收回，本报告也没有设服务端输出闸门 | 安全底线仍是同步拦截，这条只影响会话输出和事故响应的细则 |
| M12 | 正文点明 L1 敏感产物的处理方式 | Claude strategy-analyst | §1.2、§1.3 | 补一句："L1 产物按 v1.6 §1.5、§7.9 落入受控存储，智能体只读取脱敏摘要" | v1.6 §1.5"L1 与原始产物的数据管控" | 现有的整体引用已经覆盖，这条只为提高可读性 |
| M13 | `decision` 类知识转为 `inactive` 后，应通知引用方并报告覆盖损失 | Claude strategy-analyst | §8 | 按反向引用通知消费者；运行时缺少该知识时，在结论中报告覆盖损失，不静默跳过 | v1.6 §4.3（可选证据源失败时须报告覆盖损失）；v1.6 §2.5 | 属于实施细则 |
| M14 | 回放用例应包含过期知识与新鲜事实冲突的样例 | Claude code-reviewer | §8、§1.1 | §8 的回放用例要求中，增加"宽限期内过期条目与新鲜事实冲突"的样例 | 外部评审第 10 条要求用冲突样例回放；§1.1 第 5 位已规定相应语义 | 只影响评测覆盖面 |
| M15 | 扩展内容拼入 Skill 时加来源定界标记 | Claude code-reviewer | §3.2、§5.3 | 装配层用标明层级和资产 ID 的定界标记包裹扩展段，并记入装配审计；否则模型分不清哪段是扩展内容，§5.3 的运行时兜底规则无从施加 | 推理 | 主要防线仍是门禁 3 和能力网关，这条只影响装配实现 |
| M16 | `decision` 类知识回退时，应对新增的消费者补做回归 | Claude research-synthesizer | §8 | 回退时，如果反向引用集合比该版本当初验证时多出了新消费者，要对新消费者补做定向回归；紧急熔断可以先激活，限期内补做 | v1.6 §2.5 与 §4.3 闸 5 都成立，但本报告没有说明两者如何衔接 | 只影响回退细则与 ⑨ 的用例 |
| M17 | 扩展内容同样只能引用 L0 动作 | Claude research-synthesizer | §3.2、§4 门禁 2 | 扩展内容不得引导模型改变宿主 Skill 中 L1 动作的目标或参数 | v1.6 §4.3 闸 3"应用包仅 L0"；§5.3 已规定扩展内容按应用层处理 | 能力网关仍然兜底，这条只让门禁校验更完整 |
| M18 | 限制同时展开的 Skill 数量，并在阶段流转时卸载已完成的正文 | Antigravity context-manager | §2、§5.1-2 | 规定会话中同时展开正文的 Skill 数量上限；阶段流转或排除某个假设后，卸载相应正文，只保留判定摘要与证据引用 | 推理：同时展开多个 Skill 会挤占证据窗口。主持人核实：原意见引用的 Anthropic 文章原句，未能在原文中找到；OWASP LLM06 不涉及上下文最小化；原意见的"≤ 2 个"没有出处。以上均未保留，只保留推理部分 | 只影响平台层上下文管理器的调度策略，数值由评测确定 |

---

## 11. 参考资料

**内部文档**（本报告的继承依据，引用时注明章节号）：
- 《SREAgent 架构设计建议》v1.6（2026-09-23）
- 《SREAgent 智能体架构决策报告（ADR）》v1.4（2026-09-28），路径 `debates/003-sreagent-adr-external-review/SREAgent-架构决策报告-v1.4.md`

**外部资料**（主持人已于 2026-09-25 核对原文）：

1. Agent Skills Specification：目录结构（`scripts/`、`references/`、`assets/` 均为可选）、frontmatter、`allowed-tools` 为实验性字段、分级加载、正文少于 500 行、引用只下探一层。https://agentskills.io/specification
2. AWS DevOps Agent Skills：按需加载；agent type 定向；description 含糊时会被跳过；Runbook 自动迁移；停用只影响新调查；默认仅支持非可执行文档，开启 Sandbox（preview）后可带可执行代码。https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html
3. AWS DevOps Agent Memories：程序性与信息性之分；Store 与条目两级描述；每条一个事实；不可变版本；学习代理与 reflections；环境理解记忆的结构；learned skills 改为 Memory 维护。https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html
4. AWS DevOps Agent — Agent instructions：常驻注入；分全局与分 agent 两类；建议约 120 行，硬上限 25 KB。https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-agent-instructions.html
5. Azure SRE Agent — Add your team's knowledge：把 runbook 等文档上传到知识库；原文 "your agent can create them for you during conversations … turns investigation findings into documented procedures"。https://learn.microsoft.com/en-us/azure/sre-agent/first-value
6. MCP Specification 2026-07-28 — Tools：原文 "The set MAY vary by the authorization presented on the request"；注解 "MUST consider … untrusted unless they come from trusted servers"；Security Considerations 中 "Clients SHOULD: … Validate tool results before passing to LLM"。https://modelcontextprotocol.io/specification/2026-07-28/server/tools
7. OWASP GenAI Top 10 — LLM06:2025 Excessive Agency。https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
8. Anthropic Engineering — Writing effective tools for AI agents（2025-09-11）：合并工具，只返回高信号信息，提供分页、过滤与截断，报错可操作，使用命名空间。https://www.anthropic.com/engineering/writing-tools-for-agents
9. OWASP RAG Security Cheat Sheet。https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html
10. Anthropic Engineering — Effective context engineering for AI agents（2025-09-29）：原文 "returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)"；"If a human engineer can't definitively say which tool should be used … an AI agent can't be expected to do better"。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
11. MCP Blog — Tool Annotations as Risk Vocabulary（2026-03-16）：原文 "They aren't enforcement"。https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/
12. OWASP LLM Prompt Injection Prevention Cheat Sheet。https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
13. SLSA v1.2 — Provenance。https://slsa.dev/spec/v1.2/provenance

---

## 附录 A：研讨过程与表决记录

> 说明：A.1–A.6 记录 v1.0–v1.5 的过程。其中资产分层使用的是旧称 L1 平台 / L2 技术域 / L3 应用 / L4 环境差异；自 v2.0 起改称平台层 / 技术域层 / 应用层 / 环境差异数据，以免与 v1.6 的能力类别 L0–L3 混淆。

### A.1 第一轮：研讨（run `20260925-140331-0108ac`，deep，5 席）

各轮席位相同。插件的法定人数规则是：
- **只统计非主持席**（核验席、质疑席、顾问席）的表决，主持席的表决不计入。
- 三家模型中须有至少两家的非主持席投 APPROVE。

本组每家恰有 1 个非主持席，因此计票席为 3 席：Claude 核验席、Codex 质疑席、Antigravity 顾问席。以下各表列出全部 5 席的表决，主持席一行仅供参考。

| 席位类型（persona） | 成员 | 表决 |
|---|---|---|
| 主持席 1（strategy-analyst） | Claude | 最终表决超时（120 s）；主持席本就不计票 |
| 顾问席（backend-architect） | Antigravity | APPROVE |
| 质疑席（security-auditor） | Codex | **REVISE** |
| 主持席 2（research-synthesizer） | Claude | APPROVE |
| 核验席（code-reviewer） | Claude | APPROVE（附条件） |

法定人数满足：计票席 2:1，Antigravity 顾问席和 Claude 核验席 APPROVE，Codex 质疑席 REVISE。据此产出 v1.0。v1.0 纳入了 Codex 的 7 条 REVISE 意见，但其中"工作负载身份不等于授权"一条实际没有写进正文，已在 v1.1 补上。

**裁决要点**：
- SOP 的承载采纳 Codex 的方案（写步骤才进入执行平面）。
- 个性化扩展采纳"具名扩展点 + `supersedes`"方案，不用 Antigravity 提出的继承 + SPI。
- Skill 路由和知识承载部分采纳 Antigravity 的方案，参数一律交由评测确定。

**已删除的无法核实内容**："工具超过 30 个准确率骤降"；工具超时 5~30 s、最多 10 步、Top 3~5；虚构的版本历史；"破坏性写操作必须具备事务与自动回滚"。

**更正插件自动综合稿**：席位数应为 5 席而非 3 席；Codex 的表决应为 REVISE 而非"未表态"；"无法打开的架构报告"实为 ADR-001。

### A.2 第二轮：v1.0 终稿复审（run `20260925-150116-001bd8`，review，5 席）

第一次发起时网络中断，三家都未能连通，结果作废。第二次发起时把上下文预算调大，保证评委收到报告全文。

| 席位类型（persona） | 成员 | 表决 | 阻塞项 |
|---|---|---|---|
| 主持席 1（strategy-analyst） | Claude | REVISE | 状态表述；审批策略可被应用覆盖；`scripts/` 绕过网关；安全吊销 |
| 顾问席（backend-architect） | Antigravity | REVISE | 画像用 SKILL.md 承载；§1.2 中 T→K 错误边；依赖范围扁平并入；§8 中 X→I 错误边 |
| 质疑席（security-auditor） | Codex | 超时（120 s），未表决 | — |
| 主持席 2（research-synthesizer） | Claude | REVISE | 工作负载身份条目缺失；L4 审批人；画像用 SKILL.md 承载 |
| 核验席（code-reviewer） | Claude | REVISE | `scripts/` 绕过网关；附录可追溯性；审批策略与名单混淆 |

**v1.1 的处理**：
- 阻塞项全部采纳，落实位置分别在 §0、§1.1、§1.2、§3.1–3.3、§4、§5.1、§6、§8、附录 A。
- 同时采纳的非阻塞项：
  - 知识的第三种承载形式及事实冲突优先级
  - CLI 边界（§1.3）
  - 应用红线的归属
  - SOP 只保留处置部分
  - 不可逆操作示例的更正
  - "可复现"改为"可追溯"
  - 扩展点缺省时折叠
  - 子智能体并发上限与限流
  - 分层审计
  - 草稿防投毒
  - 过期降权与宽限期
  - 度量口径
  - 存量迁移
  - 供应链与准入测试按阶段落地
  - 个性化范围界定
  - 编写期读权限控制
  - 按 P0–P3 标注 SOP 形态
- 未采纳 Antigravity 给出的具体数值（子智能体并发上限为 2、追踪数据保留 7~14 天），因为没有出处，改为"由平台设定"。
- 评委提出的引用疑点：[6] 是否写明"可按授权变化"、[4] 的"建议值与硬上限"、[1] 的"目录均可选"。三处均已对照原文确认报告表述准确，并在参考资料一节（现为第 11 节）补充了原文摘录。

### A.3 第三轮：v1.1 复审（run `20260925-151328-013944`，review，5 席，各席超时上限放宽到 900 s）

| 席位类型（persona） | 成员 | 表决 | 阻塞项 |
|---|---|---|---|
| 主持席 1（strategy-analyst） | Claude | REVISE | 依赖范围缺少可过滤的元数据；§8 与 §4 的发布/评测顺序矛盾；画像依赖列表与 CMDB 两套来源 |
| 顾问席（backend-architect） | Antigravity | APPROVE | — |
| 质疑席（security-auditor） | Codex | REVISE | 应用加严规则缺少服务端生效路径；§5.3 中 Skill 的信任定位矛盾；吊销无法阻断会话；依赖方升为主范围须重新授权；发布与评测顺序矛盾；凭据测试排得太晚 |
| 主持席 2（research-synthesizer） | Claude | REVISE | `exposure` 字段缺失、画像不应参与范围计算；§5.3 信任定位矛盾；生命周期矛盾 |
| 核验席（code-reviewer） | Claude | REVISE | 生命周期矛盾；缺少受众字段；吊销不可执行且上线太晚；准入测试的阶段安排与能力上线不匹配 |

各席确认：v1.0 复审提出的 10 项阻塞项已在 v1.1 正文落实。本轮阻塞项集中在两类问题：修订后缺少落地机制；前后顺序不一致。

**v1.2 的处理**：以下阻塞项全部采纳。

| 阻塞项 | 落实位置 |
|---|---|
| `exposure` / `dependency_visible` 字段；范围只由 CMDB 决定，画像不参与 | §3.3、§3.2、§5.1-1 |
| 生命周期统一为"草稿 → 核验 → CI 门禁与回放评测 → 发布"，`draft` 仅在评测环境加载 | §8、§4、§3.3、§0 |
| 吊销改为"实时拦截 + 暂停会话 + 重建会话"；最小吊销能力提前到 P0 | §6、§9 |
| 运行时内容与已发布指令类资产分开处理，并规定指令优先级 | §5.3 |
| 应用加严规则由平台审核登记，与平台最低策略取更严的一方 | §4 |
| 升为主范围须重新授权；"跨域"限定为跨技术域 | §5.2 |
| 准入测试按能力开放的阶段安排，并累计回归 | §9 |

同时采纳的非阻塞项：
- 脚本禁止任何网络出口，由沙箱强制
- 只读调用的鉴权交集不含审批
- `supersedes` 改为确定性替换
- 扩展内容只装配主范围，并由 L2 负责人审阅
- 画像中的索引由注册表生成，按研判阶段裁剪，计入常驻预算
- L4 只放无权威来源的值
- SOP 进入条件写成可判定条件
- 事实冲突时先核对是否为同一对象
- §1.2 图补上画像注入路径
- §1.3 措辞
- 可逆性示例
- [5][8][10] 补充原文要点（由主持人此前核对原文所得）
- 附录各轮表格统一格式

### A.4 第四轮：v1.2 复审（run `20260925-152538-00b52c`，review，5 席）

| 席位类型（persona） | 成员 | 表决 | 阻塞项 |
|---|---|---|---|
| 主持席 1（strategy-analyst） | Claude | REVISE | P0 已提供吊销能力，但测试 ⑥ 排在 P2 |
| 顾问席（backend-architect） | Antigravity | APPROVE | — |
| 质疑席（security-auditor） | Codex | REVISE | 初始主范围缺少对发起主体的授权；吊销没有取消正在进行的生成；不可逆动作的审批人数前后矛盾；P0 资产与发布门禁的上线顺序对不上 |
| 主持席 2（research-synthesizer） | Claude | REVISE | 测试 ⑥ 的阶段；P0 资产无法按 §4 发布，且首版没有基线 |
| 核验席（code-reviewer） | Claude | REVISE | 测试 ⑥ 的阶段 |

各席确认，A.3 所列阻塞项均已写进正文。本轮阻塞项都是 v1.2 调整阶段安排时留下的字面矛盾。有评委建议：之后只做澄清，不再增加新机制。

**v1.3 的处理**：阻塞项全部采纳。

| 阻塞项 | 落实位置 |
|---|---|
| 测试 ⑥ 拆为 ⑥a（P0，手动吊销）和 ⑥b（P2） | §9 |
| P0 过渡规则（资产只用于非生产或影子模式）；首版基线的定义 | §4、§9 |
| 双人审批的触发条件统一为"高影响的不可逆动作" | §4、§7 |
| 会话创建时校验发起主体（自动会话以事故授权为准）；每次资产读取都与该资格求交集 | §5.1-1、§9 ① |
| 吊销事件由会话控制器主动下发，取消正在进行的生成；按装配审计反查已结束的会话 | §6 |

同时采纳的非阻塞项：
- `exposure` 只适用于 L3，引用约束限定在本应用内；`dependency_visible` 的审批流程
- 区分内容核验与发布签核，门禁编号不代表执行顺序；§0 与 §8 的链条统一
- 画像中的组件、依赖、SLO 改为从 CMDB 渲染生成，消除第二个数据来源
- 画像与知识条目归入"已发布的信息类资产"
- 指令优先级纳入 L1，并注明不适用于已被替代的资产；事实优先级与规则优先级方向相反，补充说明原因
- 事实优先级中去掉草稿一项
- 区分 `inactive` 与 `deprecated`；过期后的状态转移；回退的语义
- `supersedes` 的生效条件与审阅要求
- 自动会话升为主范围时需人工确认
- 注入测试拆分，日志注入测试提前到 P0
- 新增子智能体约束测试
- §8 流程图补上人工编写和存量分拣的入口

### A.5 第五轮：v1.3 复审（run `20260926-005031-013bac`，review，5 席）

| 席位类型（persona） | 成员 | 表决 | 阻塞项 |
|---|---|---|---|
| 主持席 1（strategy-analyst） | Claude | REVISE | P0 资产在影子模式下没有合法状态；基线可能拿自己比自己 |
| 顾问席（backend-architect） | Antigravity | APPROVE | — |
| 质疑席（security-auditor） | Codex | REVISE | P0 资产状态；基线按指标给出对照口径；P1 生产上线早于逐次吊销拦截 |
| 主持席 2（research-synthesizer） | Claude | REVISE | P0 资产状态与基线口径；§0 中吊销的描述与 §6 不一致 |
| 核验席（code-reviewer） | Claude | APPROVE（附非阻塞性建议） | — |

**表决结果**：计票席 2:1。Antigravity 顾问席、Claude 核验席 APPROVE，Codex 质疑席 REVISE。法定人数满足，未触发否决，**v1.3 通过**。两个不计票的 Claude 主持席均投 REVISE。各席均确认 A.4 所列阻塞项已写进正文。

**v1.4 的处理**：三位反对评委提出的阻塞项都属于措辞层面的矛盾，v1.4 全部作了澄清，没有新增机制。v1.4 没有再次表决。

| 阻塞项 | 落实位置 |
|---|---|
| P0 阶段 `draft` 可在影子模式加载的例外及隔离要求 | §3.3 |
| 基线先于候选版本建立，并按指标给出对照口径；P0 资产补跑门禁的方式 | §4 |
| §0 吊销描述与 §6 同步 | §0 |
| 生产会话上线（P1）以具备逐次吊销拦截与生成取消能力为前提；⑥ 拆为 ⑥a/⑥b/⑥c | §9 |

同时采纳以下非阻塞项：
- 门禁第 3 项改为检查画像手写部分，不再比对 CMDB
- 装配审计记录画像渲染结果的摘要和 CMDB 时间戳
- 扩展内容的指令优先级
- 影响等级由平台策略判定
- 执行平面上线前的阶段补上 P0
- 画像按阶段裁剪从 P2 开始
- L1/L2 与 `exposure` 的措辞
- 依赖范围 Tool 的入参校验
- 已结束会话的反查改为异步执行
- 新增越权拦截率指标

### A.6 第六轮：v1.4 最终表决（run `20260926-015935-015f0c`，review，5 席）

本轮规则：只审议主体（§0–§9）；只有会导致结论错误、主体自相矛盾或无法落地的问题才能投 REVISE；其他有依据的不同意见，作为少数意见提交并标注保留。

| 席位类型（persona） | 成员 | 表决 | 阻塞项 / 少数意见 |
|---|---|---|---|
| 主持席 1（strategy-analyst） | Claude | APPROVE（附少数意见） | 少数意见 4 条 → M1、M2、M3、M9 |
| 顾问席（backend-architect） | Antigravity | APPROVE（附少数意见） | 少数意见 2 条 → M4、M5 |
| 质疑席（security-auditor） | Codex | REVISE | 阻塞项：加载前的吊销检查不能只靠"已加载集合 ∩ 吊销列表"，因为尚未加载的已吊销版本无法被拦截 |
| 主持席 2（research-synthesizer） | Claude | APPROVE（附少数意见） | 少数意见 3 条 → M6、M7、M10 |
| 核验席（code-reviewer） | Claude | APPROVE（附少数意见） | 少数意见 3 条 → M1、M8、M9 |

**表决结果**：计票席 2:1。Claude 核验席、Antigravity 顾问席 APPROVE，Codex 质疑席 REVISE。法定人数满足，未触发否决，**通过**。两个不计票的 Claude 主持席均投 APPROVE（附少数意见）。

**v1.5 的处理**：
- Codex 的阻塞项成立，属于机制层面的遗漏，修正后不影响结论。已在 §6 补充"加载前检查待加载资产的 ID 与版本"，只改了这一句。
- 12 条少数意见合并为 10 条（M1–M10），列入第 10 节，并在对应章节加注指向第 10 节。正文结论未作其他改动。
- Antigravity 为 M4 援引的 RFC 9110 与其论点对应不上，主持人未予保留，只保留了其中的工程推理。

### A.7 外部独立评审的处置（v1.5.1 → v2.0）

**来源**：2026-09-28，Codex with ChatGPT 对 v1.5.1 做了只读交叉审阅，共 12 条意见，已对照 v1.6、ADR 和原始规范核实。原文见 `ext-review/inputs/external-review.md`。主持人核验时另发现 4 项（H1–H4），与外部意见一并提交讨论组审议。

**第 1 轮审议**（run `20260928-062002-01093e`，review，5 席）

| 项目 | 内容 |
|---|---|
| 材料 | v1.5.1 全文、外部评审原文、v1.6 相关章节摘录、ADR v1.4 摘录（`ext-review/inputs/`） |
| 席位 | Claude strategy-analyst（主持）；Codex security-auditor（质疑）；Antigravity context-manager（顾问）；Claude code-reviewer（核验）；Claude research-synthesizer（主持） |
| 表决 | 计票席中，Claude 核验席、Antigravity 顾问席投 APPROVE；Codex 质疑席对"按裁定修订"投 APPROVE，对 v1.5.1 现稿投 REVISE。两个主持席均投 APPROVE |
| 输入截断 | 输入超出插件的上下文预算。各席均引用了最后一份材料（ADR v1.4）和 v1.6 §7.8、§9.1，据此判断被截掉的是 v1.5.1 附录 A 这段过程记录，不影响裁定 |

**裁定**（16 项中 13 项采纳、3 项部分采纳、0 项不采纳；另有补充发现 S1–S4）：

| 项 | 裁定 | 要点 | 落实位置 |
|---|---|---|---|
| 1 租户作用域 | 采纳 | 统一作用域加入租户；授权以 v1.6 §1.6 为准；新增跨租户测试 | §3.3、§5.1、§9 ① |
| 2 L1 主动诊断 | 采纳 | 研判阶段为 L0 加经逐动作准入的 L1，L1 由受控取证执行器执行；通用 shell 不授予模型 | §0、§1.1–1.3、§5.1 |
| 3 知识变更影响分析 | 采纳 | 新增反向引用索引与 `semantic_class`；`decision` 类变更须对消费者定向回归 | §3.3、§4、§8、§9 ⑨ |
| 4 加载时完整性 | 采纳 | 自 P0-B 起加载时校验摘要，不一致即拒绝；来源证明按 v1.6 | §6、§9 ⑧ |
| 5 执行契约 | 部分采纳 | 引用 v1.6 §7.8。按 Codex 的更正，L2/L3 执行契约作为 **P4**（非外部意见所说的 P3）的前置条件；L1 简化契约随 P1 逐动作准入落实 | §7、§9 ⑦ |
| 6 回退依赖 | 采纳 | 回退前重验引用、版本兼容与依赖状态（原少数意见 M8） | §8 |
| 7 吊销时效 | 部分采纳 | 安全底线定为同步拦截，另加可测的最大传播时效和失联拒绝；主动中断定性为减少无效输出的措施（原 M4）。**不新增**服务端输出闸门，同时删除"停止可见输出"的承诺 | §0、§6、§9 ⑥ |
| 8 人工 SOP 审批 | 采纳 | 执行平面上线前，人工动作仍走组织现有的变更与审批流程（原 M3） | §7 |
| 9 类型×指标 | 部分采纳 | 新增"资产类型 × 必过检查 / 适用指标"表；波动指标的参数由评测契约确定。M1 的分级签核部分保留为少数意见 | §4 |
| 10 运行时语义 | 采纳 | 研判方法冲突改由门禁拦截，运行时优先级只作兜底（原 M2）；宽限期内的过期知识只能作佐证（原 M6） | §1.1、§4、§5.3、§8 |
| 11 P0 吊销测试 | 采纳 | ⑥a 纳入 P0-B，覆盖网关拒绝 | §9 |
| 12 出处与路径 | 采纳 | MCP 的要求改为"建议（SHOULD）"，并与内部强制要求区分；ADR 改为引用 v1.4 | §5.3、表头、§11 |
| H1 继承 v1.6 | 采纳 | 表头声明继承；新增 §0.1 决策范围表；共用契约改为引用 | 全文 |
| H2 分层命名 | 采纳 | 改称平台层 / 技术域层 / 应用层 / 环境差异数据 | 全文 |
| H3 阶段口径 | 采纳 | 采用 v1.6 的 P0-A、P0-B、P1–P4，逐项映射 | §9 |
| H4 脚本 | 采纳 | 资产包不带可执行脚本；例外按 v1.6 §4.2 走独立审核沙箱；应用侧 Skill 仅限 L0 | §1.1、§4、§5.1 |
| S1 可逆性分类 | 采纳（3 席独立提出） | 删除本报告自定的可逆性表；以 v1.6 §1.5 的 L2/L3 判据与审批要求为准 | §3.3、§4、§7 |
| S2 跨应用扩域 | 采纳（Codex、核验席、研究综合席） | 按 v1.6 §4.5：`contract` 资产属于授权范围内扩域；超出范围的走联合事件授权或委托取证（P3），扩域被拒时出口为 `insufficient_evidence`；删除"另开会话"的做法 | §5.2 |
| S3 冻结版本与当前授权 | 采纳（strategy-analyst） | 冻结版本只用于复现，授权以当前策略为准 | §0、§6 |
| S4 `supersedes` 范围 | 采纳（code-reviewer） | 平台层资产不可被替代 | §3.2 |
| 原 M9、M10 | 纳入正文 | M9：准入测试按能力开放的阶段排期，⑥a 在 P0-B，涉及画像的测试随画像交付；M10：§1.4 注明核对日期与产品行为可能变化 | §9、§1.4 |

**未采纳的具体建议**：
- Antigravity 建议"最大传播时效 ≤ 1 s"。该数值没有出处，改为由准入验收确定。
- Antigravity 建议新增服务端流式输出切断闸门。这属于新机制，strategy-analyst、research-synthesizer、code-reviewer 均认为超出本议题范围。

**第 2 轮终审**（run `20260928-065659-00fbb3`，review，5 席；上下文预算调至 80000，本轮无截断）

| 席位类型（persona） | 成员 | 表决 | 阻塞项 / 少数意见 |
|---|---|---|---|
| 主持席（strategy-analyst） | Claude | REVISE | 阻塞项 B1；少数意见 5 条 |
| 质疑席（security-auditor） | Codex | REVISE | 阻塞项 B1（与主持席相同）；少数意见 1 条 |
| 顾问席（context-manager） | Antigravity | APPROVE（附少数意见） | 少数意见 1 条 |
| 核验席（code-reviewer） | Claude | APPROVE（附少数意见） | 少数意见 5 条；附录勘误 2 处 |
| 主持席（research-synthesizer） | Claude | APPROVE（附少数意见） | 少数意见 5 条；附录勘误 2 处 |

- **计票与落实核对**：计票席 2:1，达到法定人数。按项目规则，Codex 的阻塞项须闭环后才能定稿。各席均确认 A.7 所列各项已在正文落实，没有只写在附录里的项。
- **阻塞项 B1**：执行平面上线前，工作流尚未登记，而含写步骤的 SOP 必须引用有效的工作流，导致这类 SOP 无法通过门禁。修正方式：引入 `manual` / `workflow` 步骤类型（§1.1、§3.3、§4、§7）。
- **随同修正的一致性问题**（均由 3 席分别提出）：
  - `draft` / `active` 状态与发布通道的对应关系，新增 `channel` 字段（§3.3、§4）；
  - P1 应用层资产限于文本类，`queries/` 随 P3 上线（§9）；
  - 门禁 4 表补全资产类型（§4）。
- **附录勘误**：A.7 计数更正为"13 采纳、3 部分采纳"；补上 M9、M10 的落实位置。
- **核对说明**：研究综合席请主持人核对"ADR 边界③④"。经对照 ADR v1.4 §3 原文确认：边界③为工具/连接器层（区分 L0 与 L1），边界④为确定性执行平面，与 §1.2 的引用一致。
- **少数意见**：其余 16 条中，与上述修正重复的已并入正文，余下的整理为 §10 M11–M18。Antigravity 所提 M18 中未能核实的引用与数值，未予保留。

**提出人定向复核**（按项目规则，不再全员重审；由 B1 提出人单独复核，同时作为 Codex 对终稿差异的最终复核；原文见 `ext-review/r3/`）

| 次序 | 复核人 | 结论 | 主要意见与处理 |
|---|---|---|---|
| 1 | Claude strategy-analyst（独立 `claude -p` 子进程） | APPROVE | 确认 B1 已闭环。所提 10 条非阻塞意见全部吸收：§0.2 同步；`implements` 声明；登记与准入的空档；准入后通知；回退时校验步骤类型；基线取 production 通道、`supersedes` 按通道判定；`semantic_class` 的范围；`queries/` 补门禁 3；P1 完整列举；补记更新历史 |
| 1 | Codex security-auditor（`codex exec`，只读沙箱） | REVISE | ① §0.2、§7 仍沿用旧规则，§1.2 缺人工路径；② 登记与准入之间有空档。两项均已修正：切换条件统一为"登记并通过准入"，旧版在替代版本发布前继续有效；另吸收其 3 条非阻塞意见 |
| 2 | Codex security-auditor | **APPROVE** | 两项阻塞均已闭环，未引入新的阻塞问题。另有 3 处措辞建议（明确禁止的是"新发布"、期限由平台策略配置、§8 项数笔误），已照改 |

## 附录 B：更新历史

| 版本 | 日期 | 摘要 |
|---|---|---|
| v1.0 | 2026-09-25 | 首版成稿（复审未通过）：基于第一轮 council 综合，纳入 Codex 的 REVISE 意见，逐条核实引用，与 ADR-001 对齐 |
| v1.1 | 2026-09-25 | 按第二轮复审意见修订：应用画像改为知识类资产并确定性注入；审批策略收归平台；限定 Skill 脚本边界；新增安全吊销；依赖范围分级；补充工作负载身份条目；修正三张图；新增 CLI 边界、事实冲突优先级、存量迁移、度量口径；按阶段安排准入测试 |
| v1.2 | 2026-09-25 | 按第三轮复审意见修订：新增 `exposure` 字段，范围只由 CMDB 决定；统一资产生命周期（先评测后发布）；安全吊销改为可执行机制，最小能力提前到 P0；区分运行时内容与指令类资产的信任；应用加严规则登记路径；升为主范围须重新授权；准入测试按能力阶段安排 |
| v1.3 | 2026-09-26 | 按第四轮复审意见修订：吊销测试拆分，最小部分提前到 P0；新增 P0 过渡规则和首版基线定义；统一双人审批条件；会话创建时校验发起主体；吊销主动下发并追溯已结束的会话；另做若干一致性澄清 |
| v1.4 | 2026-09-26 | 终稿：v1.3 经第五轮法定人数表决通过；按反对席提出的阻塞项作措辞澄清，包括 P0 资产状态、基线口径、§0 同步、P1 吊销前提，另吸收若干非阻塞建议 |
| v1.5 | 2026-09-26 | 终稿：v1.4 经最后一轮表决通过（计票席 2:1）；修正 §6 加载前的吊销检查；新增第 10 节少数意见（M1–M10）并在正文对应处标注 |
| v1.5.1 | 2026-09-26 | 勘误：更正表头及附录中的计票表述。主持席不计入法定人数，最后一轮的计票席为 2:1，不是"4 席 APPROVE、1 席 REVISE"；补全 A.1 的计票规则说明。正文结论不变 |
| v2.0 | 2026-09-28 | 按外部独立评审与讨论组审议结果修订：声明继承 v1.6 与 ADR v1.4，共用契约改为引用；新增租户作用域、L0/L1 研判边界、加载时摘要校验、知识变更影响分析、回退依赖校验；吊销改为以同步拦截为底线，并规定最大传播时效与失联拒绝；资产分层改名；阶段对齐 v1.6 的 P0-A 至 P4；删除自定的可逆性分类，改用 v1.6 §1.5 的判定；跨应用扩域按 v1.6 §4.5；原少数意见 M2、M3、M4、M6、M8、M9、M10 纳入正文 |
| v2.1 | 2026-09-28 | 按外部评审处置第 2 轮终审意见修订：SOP 步骤区分 `manual` / `workflow`，解决执行平面上线前 SOP 无法通过门禁的问题；新增 `channel` 字段，理清状态与发布通道；P1 应用层资产限于文本类；门禁适用表补全；新增少数意见 M11–M18；附录计数勘误。经提出人定向复核（strategy-analyst 一次通过；Codex 第二次复核通过），补充：工作流切换条件改为"登记并通过准入"并声明 `implements`；回退时校验步骤类型；§1.2 补画人工执行路径；基线取 production 通道版本。外部评审处置完成 |