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

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

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

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 定义 #

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 关系 #

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. 拆分粒度 #

尺寸约束

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

Tool 为模型而设计 [8]：

• 合并多步操作；
• 只返回高信号的信息；
• 默认提供分页、过滤或截断；
• 报错信息要可操作；
• 用服务名或资源名作前缀，区分命名空间。

3. 组织形式 #

3.1 分层结构 #

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 为敏感级的资产，必须放在独立仓库或受控存储中，编写阶段的读权限也要控制。

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）。注册表另外为所有类型的资产维护以下字段：

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

策略只以平台登记的版本为准。 实际生效的约束 = 平台策略 ∪ 已登记的应用加严规则，取二者中更严的一方；应用规则只能收紧，不能放宽。画像、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 三道防线 #

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. 持续改进 #

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 为准。下表只列出资产侧的交付与准入测试在各阶段的映射。

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

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），不再列出。

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 席的表决，主持席一行仅供参考。

法定人数满足：计票席 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 席） #

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

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） #

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

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

同时采纳的非阻塞项：

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

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

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

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

同时采纳的非阻塞项：

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

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

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

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

同时采纳以下非阻塞项：

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

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

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

表决结果：计票席 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 席）

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

未采纳的具体建议：

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

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

• 计票与落实核对：计票席 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/）