运维智能体（SREAgent）架构设计建议报告

0. 执行摘要与阅读说明 #

0.1 核心结论 #

总纲：故障与需求的多样性交给 Skill 与路由；上下文与并行的需要交给 子智能体；身份、权限与故障域的隔离交给 执行域、执行器与 Cell；跨组织协作交给 协议 + 网关。四者不混用同一种机制。

0.2 表述类型标注 #

为区分证据强度，正文关键论断按下列类型标注；未标注的一般性说明视为【推论】。

引用材料性质：第 12 章将参考资料分为「一手」（厂商工程博客、官方文档、基金会公告、规范原文）与「三方」（媒体转述、会议报道、第三方测评与分析）。作者署名的经验分享按其实际发布渠道归类，不因转述厂商观点而归为一手。

1. 架构形态：执行域、能力模型与授权 #

1.1 业界案例（采样观察） #

• Anthropic【事实】：默认从单智能体起步；多智能体适用于上下文保护、可并行化、工具集专门化三类情形，且「只有当上下文能够被真正隔离时才应拆分」；按问题类型而非上下文边界拆分会产生「传话游戏」，协调开销可能超过实际工作[1]。多智能体对同等任务的 token 消耗为单智能体的 3–10 倍，属其测试观察[1]；其研究系统中 agent 约为对话的 4 倍、多智能体约 15 倍，Opus 4 主导 + Sonnet 4 子智能体在其内部研究评测上比单一 Opus 4 高 90.2%[2]。
• Cognition【事实】：2025 年主张共享完整上下文与轨迹、「动作隐含决策，冲突的决策带来糟糕的结果」[3]；2026 年修正为单写者原则——写操作保持单线程、其余智能体只贡献判断不贡献动作时，多智能体才有效；无前置上下文的评审智能体每个 PR 约发现 2 个缺陷、其中 58% 为严重缺陷；无结构 swarm 基本是干扰项[4]。该经验来自围绕单个开发任务的多智能体协作。
• Datadog Bits Investigation【事实】：单智能体 + 假设树，提出假设、定向查询验证、递归下钻；早期版本工具调用增多导致汇总提示 token 线性增长，修正方向是聚焦告警与特定假设之间的因果关系[12]。
• Azure SRE Agent【事实】：主 agent + 可选子 agent；可扩展点为 skill、自定义 agent、Python 工具、MCP server、hook[14]；子 agent 用于「健康报告、告警分诊、通知投递」等聚焦任务，配置项为指令、skill、工具与 hook，skill 与工具选择留空时默认继承全局[16]；事件响应计划以过滤条件路由到自定义 agent 并指定 Autonomous / Review 自治级别[15]。
• AWS DevOps Agent【事实】：2026-03-31 正式可用[28]；报道称其为构建于 Bedrock AgentCore 的单一自治 agent，通过 agent skill 与 MCP 扩展；预览期厂商数据为 MTTR 最多下降 75%、根因准确率 94%，未经独立验证[34]。
• Google SRE【事实】：按流程阶段组织多类 agent（异常检测、告警处理、事件编排、调查、剧本执行）；工具面以 MCP 为基础；要求 agent 具备强身份、角色与权限，「偏向透明而非黑盒自动化」；事件知识由独立的向量化洞察系统供给[17]。
• Dynatrace【事实，三方报道】：主张确定性分析先行；以单步 95% 在十步链路后约 60% 的示意说明误差复合；「不能把 PB 级日志装进一个 agent」[36]。
• STRATUS（学术研究）【事实】：基于 LLM 的多智能体自治 SRE 系统，由检测、诊断、缓解等专职智能体组成，并以状态机组织编排，以支撑系统级安全推理与强制执行；提出「事务性无回归（Transactional No-Regression，TNR）」安全规范，使缓解动作能在受约束条件下安全探索与迭代；论文报告其在 AIOpsLab 与 ITBench 两个 SRE 基准上的故障缓解成功率，较当时先进 SRE 智能体至少高 1.5 倍（跨多个模型）[41]。
• Flow-of-Action（学术研究）【事实】：SOP 增强的 LLM 多智能体根因分析系统：以「SOP 流」在关键节点约束模型——检索相关 SOP、缺失时自动生成、并转为可执行代码；另设辅助智能体负责噪声过滤、缩小搜索空间与判定流程可否停止；论文报告其准确率 64.01%，显著高于 ReAct 基线的 35.50%[42]。

观察【观察】：所引案例都支持优先按权限、上下文与运行约束评估划分，不支持仅按故障名称机械拆分。厂商材料给出的是职责示例，不构成对全部产品形态与用户部署的穷尽证明；本报告据此给出的是建议的评估顺序，不是领域规律。

与学术先例的对照【推论】：STRATUS 以状态机编排专职智能体、并以「缓解不得使目标系统状态回退」的安全规范约束动作，与 §3.5「统一策略入口、单写者」及 §7.8「成功判定以业务后置条件为准、补偿与成功分开」的取向互为印证；Flow-of-Action 以 SOP 约束诊断路径，支持「决策与执行分离、模型不按 SOP 文本自由执行」的分工取向（§2.7）。两文的评测条件、基线与环境均为各自论文所述，其数值不作企业内部目标参照（§10.2）。

反例说明【推论】：若按现象拆成「CPU 智能体、超时智能体、重启智能体」，一次真实故障往往同时出现 CPU 冲高、超时、Pod 重启、GC 异常、依赖失败与近期变更，会被多个智能体重复分析并产出相互矛盾的结论，且智能体数量随现象种类无上限增长。

1.2 划分因子：三层优先级 #

硬边界要求分离而上下文不可隔离时：以结构化移交替代上下文共享（契约见 §7.7）。移交物不是对话轨迹，而是结论、证据引用、与安全性和适用性相关的反证与未决假设、建议动作、参数与前置条件；下游须在执行前复核当前适用性。无需传递模型的隐含推理过程，但必须提供可核验的事实依据。

架构不变式：生产写操作经唯一的逻辑策略入口授权，在同一冲突域内单写者（§3.5）。这不是拆分判据，而是拆分后始终成立的约束。

1.3 执行域与实例化 #

执行域（强制分离）：

实例化（按收益决定）：

评审判据：「把这个域的 LLM 换成一张规则表，会损失什么？」 回答不了则不放 LLM。

诊断智能体内部的首期设计选择【推论】：保留单一证据合并者负责假设收敛与结论，同时允许并行验证彼此可独立验证的假设或证据路径。是否扩大并行度，由评测收益决定。子智能体的用途（委派契约见 §7.11）：

1. 并行只读取证：日志、指标、变更、拓扑、配置各一路，回传结构化证据对象（§7.3）。
2. 上下文污染型任务：大范围检索、全量配置扫描，隔离执行，只回传结果[5][8]。
3. 独立复核：虚警复核、结论复核。复核方不继承主诊断的结论与推理，但必须获得告警原文、业务影响、证据与数据缺失信息；复核只出建议，不直接静默告警（§8.6）。同模型、独立上下文不保证错误相互独立。

运维需求与执行域的映射：

1.4 总体架构 #

flowchart TB
    subgraph SRC["接入层"]
        A1["监控告警"]
        A2["工单 / ITSM"]
        A3["巡检定时任务"]
        A4["人工会话 / ChatOps"]
    end

    subgraph RT["分诊与路由（确定性为主）"]
        R1["规范化: 告警类型/对象/应用/严重级"]
        R2["规则表路由: 执行域 + Skill 候选 + 自治级别"]
        R3["语义兜底分类: 校准后的检索置信度"]
        R4["路由决策留痕"]
    end

    subgraph DOM["逻辑执行域"]
        C1["诊断域 · LLM 智能体<br/>L0 + L1 白名单"]
        C2["处置域 · 策略阶段<br/>校验/选流程/填参数/送审"]
        C3["巡检域 · 独立资源池<br/>L0"]
    end

    subgraph SUB["诊断域子智能体"]
        S1["并行取证"]
        S2["污染型检索"]
        S3["独立复核（建议模式）"]
    end

    subgraph SR["Skill Resolver"]
        K1["授权过滤（不可越过）"]
        K2["相关性过滤（可按拓扑扩域）"]
        K3["渐进式披露"]
    end

    subgraph PKG["能力包"]
        P1["core"]
        P2["domain"]
        P3["app（声明式）"]
        P4["knowledge（与 Skill 分离）"]
    end

    subgraph GW["能力网关（统一策略入口）"]
        G1["每次调用重新鉴权"]
        G2["动作注册表: 类别 + 风险属性"]
        G3["限流/超时/熔断/审计"]
    end

    subgraph EXE["执行器"]
        E1["L0 查询执行器"]
        E2["L1 受控取证执行器"]
        E3["L2/L3 工作流执行器"]
    end

    subgraph PLAT["平台与远端"]
        M1["容器 / 日志 / LB / APM / CMDB / 变更 / ITSM"]
        M2["App Capability Service"]
        X1["远端平台智能体（A2A）"]
    end

    SRC --> RT --> DOM
    C1 --> SUB
    DOM --> SR --> PKG
    C1 --> GW
    C3 --> GW
    SUB --> GW
    C2 --> GW
    GW --> E1 & E2 & E3
    E1 --> M1 & M2
    E2 --> M1
    E3 --> M1
    GW -. "A2A 委托（范围/能力上限/截止时间）" .-> X1
    C1 -. "结构化移交（结论 + 证据 + 反证 + 前置条件）" .-> C2

图示约定：所有工具调用与远端委托均经能力网关，不存在绕过网关的直连通路。L1 取证执行器与 L2/L3 工作流执行器是不同的执行器，共享同一策略入口与冲突协调（§3.5）。

前置工程约束【推论】：可确定化的部分做成确定性服务——拓扑关联、变更时间窗关联、指标异常检测、依赖链推导由确定性组件产出，LLM 负责假设生成、证据编排与叙述。须注意可重复计算不等于准确，时间相关不等于因果：确定性组件的输出同样是证据而非结论，须附数据版本与时效（§7.3）。

1.5 能力安全模型 #

为什么「只读 / 可写」二分不够【事实 + 推论】：

模型结构：能力类别（由动作语义与状态影响确定）＋ 独立的数据与资源风险属性，按动作登记。

能力类别（回答「这是哪一类能力」，用于执行域归属、执行器选择与身份绑定；只由动作语义与状态影响决定，数据与资源属性不改变类别）：

L2 的判据是「恢复条件可验证」，而非「可逆」：重启、缩容、流量切换并不天然可回滚——恢复副本数不能恢复已中断的在途交易，也不能恢复丢失的内存状态。

状态影响与类别的对应（定义性）：

登记时两者不一致即为登记错误，退回重新登记；动作语义改变时重新分类。

独立风险属性（不改变类别，决定审批、脱敏、产物去向与限制）：

敏感等级与产出形态分开登记：同一份敏感数据以摘要形态输出与以原始形态导出，风险不同。此外，动作注册表还须登记作用范围（单对象 / 批量 / 全局）与可恢复性说明，作为策略判定输入。

示例【推论】：

两点由此可见：支付服务的 heap dump（L1）在数据风险上高于重启 Pod（L2），单一序数无法表达；从日志存储导出原始敏感文件的数据风险很高，但它不因此变成 L1——它不在目标上发起现场采集，执行器与身份仍按 L0 选择，数据风险由策略另行处理。

判定原则：

1. 有效风险由「语义动作 ＋ 参数 ＋ 目标对象 ＋ 环境 ＋ 目标当前状态」共同决定，不由工具名决定。注册表按动作而非按工具登记；同一工具的不同参数可能落入不同类别。参数敏感的拆分要求：凡参数差异会改变 capability-class、data-sensitivity、output-form 或 resource-impact 上界的，必须拆分为独立的语义动作 ID 分别登记（如「摘要查询」与「原始片段导出」），allowed-tools 与能力包引用一律填写动作注册表 ID，使发布门禁可按动作粒度保守推导（§2.4），运行时再按具体参数逐次判定。
2. 通用 shell / exec 通道不授予诊断模型，拆为平台维护的、参数受限的固定动作（如 collect_thread_dump(pod, duration)），每个动作单独登记类别与属性。
3. 能力类别是枚举，不可比较大小。 策略以查表判定，禁止出现 class <= L1 一类比较；类型层面使用字符串枚举，CI 做静态扫描。
4. 没有合法策略的组合直接拒绝，由登记流程重新分类或补充专门策略；不以改变类别的方式绕过或收紧。例如首期若不支持被动原始导出，则「L0 + restricted + raw」直接拒绝，而不是把它改记为 L1。
5. 数据保护适用于所有类别，不限于 L1。

策略输入与输出：

输入：能力类别 + data-sensitivity + output-form + resource-impact
      + 作用范围 + 应用敏感度 + 环境 + 目标当前状态 + 当前负载
         ↓  策略引擎（表驱动，由平台维护；无匹配策略即拒绝）
输出：是否允许 / 审批要求 / 执行身份 / 执行器与沙箱 / 产物去向 / 配额与频次 / 审计流向

审批要求由属性组合决定而非仅由类别决定：例如 output-form = raw、data-sensitivity = restricted 或 resource-impact = high 任一成立即需审批。

三个反例的判定结果：

L1 与原始产物的数据管控（数据风险独立于状态影响；以下同样适用于 output-form = raw 的 L0 动作）：

• 产物落受控加密存储，限定留存期，不落智能体可自由读取的位置；
• 智能体默认只读取经脱敏与摘要处理的分析结果（如「堆中占用最大的对象类型与数量」），不读取原始产物；
• 审计记录归入数据访问审计流；
• 敏感应用（支付、账务、客户信息等）的 L1 动作须人工批准；
• 与处置冲突时优先保证处置（例如目标正在重启时禁止采集堆转储，§3.5）。

与 MCP 工具注解的关系：readOnlyHint / destructiveHint 等是提示，客户端须视为不可信，不可信服务端可以谎报只读；需要数据不外泄的保证时应依靠网络管控或沙箱[25]。注解既不能表达上述类别与属性，也不提供保证。本模型以网关侧动作注册表为准，注解只用于展示与发现。

1.6 授权模型 #

本节是全报告关于授权的唯一定义，与本节冲突的表述以本节为准。

各机制解决什么、不解决什么【事实】：

授权判定（能力网关在每次工具调用时执行）：

有效权限 = 已认证主体的权限
         ∩ 目标租户 / 环境范围（由身份与资源目录校验）
         ∩ 平台动作注册表的策略（§1.5）
         ∩ 本次会话被授予的范围
         ∩ 有效、未过期、适用范围匹配的审批（当 §1.5 平台动作策略要求审批时适用）

硬性要求：

1. 每次调用重新鉴权；拒绝未知动作、过期策略与失效会话。

2. 租户与应用归属由身份与资源目录校验，不采信模型输出、告警文本或能力包自报值；包的 scope 受发布者权限约束。

3. 模型、告警文本与能力包只能请求权限，不能定义权限。

4. 凭证留在受控执行器，模型只见引用；凭证不进入提示、日志与评测副本。

5. 第三方或应用自建 MCP server 须单独审查其自有凭证、出网能力与实际权限——仅下发只读凭证不能约束它已持有的权限。

6. 拒绝未经校验的 token 透传：MCP 规范要求服务端不得接受非签发给自身的 token，token 透传被明确禁止，其风险包括混淆代理与审计失真[26]。网关对下游使用独立授权，并校验凭证 audience。

7. 状态句柄不作为认证：operation_id、任务 ID 等句柄须与已认证主体服务端绑定，持有句柄不等于有权操作[26]。

8. 运行中撤权在约定的最大传播时效内生效：该时效须可验证；网关与执行器在无法确认当前撤销状态时（如与策略服务失联超时）拒绝新调用。判定口径与边界（与 §3.6、§10.1 同口径）：①「失联超时」指本地策略 / 撤权心跳同步中断超过最大允许 TTL，该 TTL 须可验证并在准入测试中验收；②低风险 L0（data-sensitivity = normal 且 output-form = summary）可在数据策略确定的缓存有效期内按已签名缓存降级执行，属受控例外，须在审计与结论中标注；③其余 L0 动作（涉及 sensitive / restricted 数据或 raw 产出）与 L1 及以上动作不适用例外——其策略缓存有效期不得超过撤权最大传播时效，同步中断超过该时效即拒绝新调用；④撤权指令已覆盖的资产或会话不受任何缓存降级保护。已加载进上下文的 Skill 正文不会因下架而消失，须收回工具权限或终止会话。

   版本冻结与当前授权的关系：会话冻结的模型、Skill、Knowledge、策略等版本（§4.6、§7.2）用于复现决策输入；有效授权始终受当前撤销与限制策略约束，不以会话冻结的策略版本为准。每次调用记录实际生效的策略版本；策略更新在会话中只能收紧、不能自动扩大原授权。

9. 未知应用身份不走全局通用账号兜底，直接拒绝并进入人工路径。

2. Skill 治理与上下文 #

2.1 三种干扰机制 #

可直接作为验收标准的判据【事实】：「如果人类工程师都无法明确说出某个场景该用哪个工具，就不能指望 agent 做得更好」；工具应自包含、无歧义、功能重叠最小[5]。该原则同样适用于 Skill。

2.2 上下文成本：估算方法而非阈值 #

计算口径【推论】：

常驻成本  C_res = T_system + Σ T_meta(skill_i) + Σ T_schema(tool_j)
激活成本  C_act = Σ T_body(已加载且仍保留的 skill) + Σ T_ref(已加载且仍保留的引用文件) + Σ T_know(已加载且仍保留的知识条目)
证据成本  C_ev  = 仍保留在上下文中的全部工具结果与证据片段（含此前各轮）
约束      C_res + C_act + C_ev + C_reserve ≤ W（所选模型的上下文窗口）

计数口径是每次模型请求实际携带的全部内容。常驻成本从会话开始就存在；正文、引用文件与知识条目在命中时首次加载，此后只要仍保留在上下文中，每次请求都继续占用；历史轮次的证据同样如此，直到被压缩或裁剪。提示缓存如何计费另行核算，不改变上下文占用。

可引用的量级参考：

为什么这些数字不能直接当阈值【推论】：

• 规范的「约 100 token」是近似值，而 description 上限为 1,024 字符[24]；按 §2.6 的要求写入判别关键词与排除条件后，描述会显著变长；中文与英文的 token 密度也不同。
• 示例：若每会话注入 20–40 个工具、每个 300–600 token，工具 Schema 占 6k–24k token；若要求其不超过窗口的 10%，对应窗口需 60k–240k。结论完全取决于所选模型与实际 Schema，只能按实测参数计算。

规模化语义检索的启用条件（替代固定数量阈值）：满足任一即启用 Resolver 的语义检索层——

1. 常驻元数据占上下文预算超过设定比例（初始建议 10%【建议值】，见 §2.9）；
2. Skill 选择准确率在评测集上出现下降；
3. Resolver 离线召回或准确率低于目标。

实测方法见 §10.4。Skill 总数只用于容量规划。

证据进入上下文的方式【推论】：

• 默认返回结构化摘要，不批量灌入原始数据——「不能把 PB 级日志装进一个 agent」[36]；
• 按需获取受限、已授权、已脱敏的原始片段，带行数、字节数与时间窗上限，并按 §1.5 的 output-form = excerpt 与相应 data-sensitivity 判定。异常顺序、局部尖峰与具体错误串往往只存在于原始行中，一律禁止原始片段会制造调查盲区。

2.3 最小能力集的加载机制 #

flowchart LR
    I["告警/工单/请求"] --> A["授权过滤<br/>租户/应用/环境/能力类别<br/>不可越过"]
    A --> B["确定性路由<br/>结构化字段 → Skill 候选"]
    B --> C["相关性过滤<br/>可按可信拓扑扩域"]
    C --> D["语义检索 Top-K<br/>规模化后启用"]
    D --> E["渐进式披露<br/>元数据 → 正文 → 引用"]
    E --> F["工具子集注入"]
    F --> G["上下文隔离<br/>污染型任务入子智能体"]
    G --> H["度量与回收"]

Skill Resolver 的职责与分层：

两层过滤必须分开：

• 授权过滤决定「允许看到什么」，由身份与资源目录判定，永远不可越过；
• 相关性过滤决定「初始加载什么」，是对调查方向的猜测，必须可扩展。例如仅凭「时延上升、Pod 重启」线索排除 Redis、MQ、LB 相关 Skill，若根因恰在依赖，就会把一个相关性猜测固化成不可恢复的盲区。扩域路径见 §4.5。

Resolver 的接口首期冻结，实现可替换：首期实现为确定性过滤与规则表；语义检索与重排在同一接口后替换实现，不改动运行时核心。首期不引入向量库与重排，避免挤占评测集建设。

确定性路由：告警与工单的结构化字段（告警名、对象类型、应用 ID、严重级、集群、变更窗口标记）经规则表映射为「执行域 + Skill 候选 + 工具候选 + 自治级别」。该路径可审计、可回归、不随模型升级漂移。Azure SRE Agent 的事件响应计划即此形态[15]。

语义检索（规模化后）：规则过滤 → 向量检索 Top-K → 可选重排。进入门限的只能是校准后的检索置信度（§2.8）。Resolver 本身须单独评测，其召回率是整个诊断能力的上限。

渐进式披露【事实】：元数据常驻，判定相关后读入 SKILL.md 正文，引用文件按需加载[6][24]。运维知识的切法：正文只保留判定流程骨架（适用条件、判据顺序、收敛条件、结论口径），阈值表、命令清单、查询模板、历史案例、字段字典下沉到引用文件。

工具子集注入：按路由结果注入本会话所需工具，可采用工具检索模式（三方测量显示可保留约 85% 上下文[37]）。本层解决上下文问题，不解决授权问题（§1.6）。

上下文隔离：大输出任务以子智能体执行，子智能体默认不带对话历史、已读文件与已调用 Skill[8]。

度量与回收：统计 Skill 命中率、加载后被引用率、结论采纳率；长期零命中但常驻元数据的 Skill 下架（参照 /skill-doctor 的用途[7]）。默认值须为「显式声明才可见」——Azure 子 agent 在未选择时默认继承全局 skill 与工具[16]，这正是上下文过载的常见来源。

2.4 Skill 元数据：唯一企业 Schema #

规范基础【事实】：Agent Skills 规范必填 name（≤64 字符，小写字母、数字与连字符，须与目录同名）与 description（≤1,024 字符）；可选 license、compatibility、metadata（字符串到字符串的映射，供客户端存放规范未定义的属性，建议键名足够独特）与实验性的 allowed-tools；提供 skills-ref validate 校验[24]。

企业字段一律放入 metadata，不新增顶层字段，以保持 SKILL.md 可跨宿主移植。metadata 的值只能是字符串，多值以英文逗号分隔。

---
name: k8s-pod-restart
description: 诊断 Kubernetes Pod 异常重启与 CrashLoopBackOff。适用于容器重启类告警、
  Pod 状态异常、OOMKilled。不适用于节点驱逐导致的重启（见 k8s-node-eviction），
  不适用于主动发起的滚动更新（见 deployment-change-correlation）。
license: Proprietary. LICENSE.txt has complete terms
compatibility: 需要容器平台只读查询能力与事件查询能力
allowed-tools: k8s.get_pod_status k8s.get_events k8s.get_pod_spec
metadata:
  BANK.domain: "kubernetes"
  BANK.scenario: "pod-restart,crash-loop"
  BANK.signal: "metric,log,event"
  BANK.resource-type: "pod"
  BANK.intent: "diagnosis"
  BANK.owner: "cloud-platform"
  BANK.version: "2.3.1"
  BANK.scope: "global"
  BANK.env: "prod,nonprod"
  BANK.kernel-api: "1"
  BANK.capability-classes: "L0"
  BANK.data-sensitivity-max: "sensitive"
  BANK.output-forms: "summary"
  BANK.resource-impact-max: "low"
  BANK.eval-manifest: "evals/manifest.yaml"
---

字段语义与校验：

静态推导的边界：发布门禁的保守推导依赖动作注册表的拆分粒度——凡参数差异会改变 capability-class、data-sensitivity、output-form 或 resource-impact 上界的，动作注册表必须将其拆分为独立语义动作 ID（§1.5 判定原则 1），allowed-tools 填写动作注册表 ID；或由能力包的结构化模板（如 §4.4 的 queries/）显式声明静态参数范围上限，供门禁联合校验。门禁只校验静态属性元组（能力类别、data-sensitivity、output-form、resource-impact、作用范围、环境）是否存在合法策略；目标当前状态 与 当前负载 等运行时变量不在发布期求值，由能力网关在每次调用时按具体参数逐次判定（§1.5）。

应用侧能力包约束（平台准入策略，不是 L0 动作的天然性质）：只允许类别集合为 L0、output-forms 不含 raw、intent ≠ remediation 的 Skill；L1 及以上由平台团队维护。

2.5 Skill、Knowledge、Tool 分离 #

Google SRE 将事件知识做成独立的洞察系统（嵌入模型 + 向量库）供 agent 取用，与剧本分立[17]。

知识更新的回归规则：分离使知识更新无需重发 Skill 包，但不等于无需评测。阈值、判据依据与拓扑知识即使不改动任何 Skill，也会改变决策结果；叠加单一事实源后，一处未经验证的阈值可同时影响所有引用它的应用。因此：

• 改变决策语义的知识更新（阈值、判据、拓扑、依赖关系）须做影响分析，按引用关系反查受影响 Skill 与应用，触发相关回归；
• 仅修订措辞、补充案例说明等不改变判据的更新可免回归，但须由审核人确认；
• 会话须冻结并记录所用 Skill、Knowledge、拓扑的版本（§7.2）。

2.6 Skill 编写规范 #

1. 一个 Skill 对应一个决策点。description 写「何时用」，并写明排除条件与替代 Skill。
2. description 含判别性关键词（真实告警名、对象类型、错误码），不用「性能问题」「异常分析」一类泛词。
3. 阈值、命令、查询模板外置到引用文件；正文控制在规范建议的量级内（< 5,000 token、< 500 行），引用只下沉一层[24]。
4. 单一事实源：同一阈值或口径只在一处定义，其他 Skill 引用；发布前做重复定义与冲突扫描。
5. 声明所需工具，不声明写动作（应用侧一律禁止）。声明是意图，不是授权（§1.6）。
6. 字段完整：按 §2.4 Schema 填写。
7. 附评测用例作为发布门禁：每个 Skill 至少包含正例、反例（应不触发）与边界例；平台建议初始不少于 5 条【建议值】，这是建设起点而非质量证明（§8.7）。

2.7 高风险流程：决策与执行分离 #

模型不按 Markdown SOP 自由执行高风险动作。 对生产变更、扩缩容、流量切换、应急止损、数据修复：

诊断智能体 → 结构化移交（§7.7）：建议动作 + 目标 + 参数 + 证据 + 反证 + 前置条件
              ↓
处置策略阶段 → 适用性校验 → 选择已登记工作流 → 规范化参数 → 送审
              ↓（审批绑定，§7.8）
工作流执行器 → 执行前复核 → 执行 → 结果核实 → 成功 / 补偿 / 转人工

处置域的「工具」是已编排、可单独测试、带恢复或补偿分支的工作流（如 workflow.restart_pod），不是底层命令。模型可以选工作流、填参数，不能绕过工作流直接调用底层能力。

这减少了模型自由执行的环节，但不消除分布式执行问题【推论】：审批后目标被替换、执行完成但响应丢失、工作流重启后重复执行、回滚时已有新变更等情形仍会发生，须由执行契约处理（§7.8）。Dynatrace 的「单步 95%、十步约 60%」只是示意模型（§8.7），不能据此声称风险被压缩为一次模型决策。

Google SRE 的缓解剧本同样包含验证与回滚步骤，并明确「目前仍需人在回路验证所建议的缓解措施」「在一个上下文下安全的动作在另一个上下文下可能不安全」[32]；Azure SRE Agent 以 hook 与 Autonomous / Review 自治级别控制动作[15][16]。

2.8 置信度 #

三种来源必须区分：

根因输出携带证据结构而非裸分数（证据对象见 §7.3）：

{
  "status": "root_cause_candidate",
  "root_cause": "OOMKilled",
  "evidence": [
    {"ref": "ev-2291", "support": "direct"},
    {"ref": "ev-8831", "support": "corroborating"}
  ],
  "contradicting_evidence": [],
  "unresolved_hypotheses": ["dependency-latency"],
  "evidence_completeness": "partial",
  "diagnosis_confidence": "medium"
}

• status 取值区分事实 / 假设 / 根因候选 / 已确认根因，并保留 unknown、insufficient_evidence、conflicting_evidence、stale；
• diagnosis_confidence 由确定性评分规则或校准过的分类器给出；contradicting_evidence 非空时须显著降级；
• 「无数据」不得报告为「健康」。

校准是门限的前提：置信度只有在「报某一分值的案例中实际正确率与该分值相符」时才能作门限。要求：在独立留出集上计算可靠性曲线，按技术栈、难度、有无噪声分段统计；模型、Resolver 实现、Skill 或 Knowledge 语义变更后重算；未经校准的分数只能用于排序，不能用于门限。没有校准结果，不开启任何基于置信度的自动执行。

2.9 上下文预算 #

会话级硬限额：最大步数、最大工具调用次数、最大 token、最长时长。超限即输出当前证据、未决假设与覆盖缺口并转人工。各项取值按 §10.4 实测后确定。

3. 多智能体协同、写操作协调与部署 #

3.1 划分依据 #

沿用 §1.2 的三层优先级。不能仅凭故障类型、运维需求类型或 SOP 数量机械划分；是否分离仍按安全、上下文、并行价值与运行约束判定。

3.2 共性 Skill 的共享 #

共享指同一份源以受控版本在多处被消费，要避免的是无版本的共享读取与单实例部署：它们使知识成为单点，且无法按智能体灰度。共享知识服务本身并无问题，只要采用版本化数据集、会话固定版本与高可用副本，同样可以支持灰度。

三层能力包：

分发机制可参照 Claude Code 的插件市场模型【事实】：清单登记包名与来源（git、子目录、npm、归档）；版本显式指定或由 commit SHA / 归档摘要派生；企业可限定受信来源；插件内 Skill 自动命名空间化；支持重命名迁移与多发布通道；市场本身无审核闸门，信任取决于来源[9]。企业内部应映射到既有制品库、变更审批与灰度流程。版本一致性：core-* 随内核统一对齐；domain-* 允许约定的兼容窗口；app-* 独立节奏，声明依赖的内核 API 版本。

3.3 路由与协同 #

flowchart TB
    E["事件到达"] --> N["规范化与富化<br/>确定性关联：拓扑/变更/资源目录"]
    N --> Z["授权过滤"]
    Z --> D{"规则表命中?"}
    D -- "命中" --> P1["执行域 + Skill 候选 + 工具候选 + 自治级别"]
    D -- "未命中" --> C["语义分类<br/>输出候选与校准后的检索置信度"]
    C --> T{"达到门限?"}
    T -- "是" --> P1
    T -- "否" --> P2["通用诊断 + 仅 L0 + 转人工"]
    P1 --> X["执行"]
    P2 --> X
    X --> L["路由与执行全链路留痕"]
    L --> F["人工反馈 → 评审后更新规则与评测集"]

要求：规则优先、语义兜底；进入门限的只能是校准后的检索置信度（§2.8）；路由决策留痕并可回放；人工反馈进入评审流程后再更新规则与评测集，不直接改变生产策略。

3.4 中控实现选项 #

推荐：B 为主干，C 用于域内并行，D 用于跨域自治协作。中控职责为分诊 + 编排 + 审计点，不承担跨领域根因推理。

LangChain 对子智能体 / Skill / 交接 / 路由四种模式的比较【事实】：多领域且文档量大的查询中，子智能体因上下文隔离比单智能体加载多个 Skill 节省约 67% token；总体建议是「先用单智能体与良好的提示；先加工具，再加智能体」[11]。该数字与 Anthropic 的 3–10 倍来自不同任务与基线，均不能直接用于本项目预算，须在相同场景与质量门槛下对比（§10.3）。

3.5 写操作协调 #

统一策略入口，分离执行器：

执行契约的适用范围：所有有副作用的 L1–L3 动作都适用 §7.8 的执行契约，包括操作身份、审批绑定、去重、执行状态、超时后核实与停止规则。L1 可采用简化状态机（§7.8），不要求包装成 L2/L3 处置工作流。dump、profiling 等 L1 动作同样可能在「已启动、响应丢失、执行器重启」后被重复执行，白名单与频次限制不能代替幂等与结果核实。

冲突域与单写者：同一冲突域内在任一时刻只有一个有效写所有者；不相交的冲突域可并发。不要求全公司所有变更物理串行——那会在大面积故障时把处置能力压成排队。

1. 冲突域按资源层级判定：锁定节点隐含锁定其上 Pod；锁定 Deployment 隐含锁定其副本。只按资源 ID 互斥会漏掉「摘除节点 N」与「重启 N 上 Pod」一类冲突。跨层级加锁采用自顶向下的意向锁：先行取得祖先节点的意向锁、再对目标资源加锁；同一祖先下不同子资源的意向锁相容、可并发，祖先的独占锁（如摘除节点、删除 Deployment）须等其下全部意向锁释放并完成对账后才能取得。意向锁与第 5 条的执行代次配合使用。

2. Incident 级方案一致性：同一事件中对不同资源的动作可能资源上不冲突、逻辑上冲突（如一边扩容服务 A、一边把流量从 A 摘走）。处置策略阶段须对同一事件的全部待执行动作做整体规则校验。

3. L1 与处置的冲突规则：登记于动作注册表，例如目标正处于重启、缩容或流量切换中时禁止堆转储与抓包；处置优先。「处置优先」的执行方式：高优先级 L2/L3 处置到达且与在途 L1 动作冲突时，由受控执行器（必要时经能力网关）主动向在途 L1 动作下发停止指令；L1 按 §7.8 进入待核实并完成对账与残留清理（VERIFYING → STOPPED）后，处置方可接管。等待 L1 租约到期或动作自行结束仅作为主动停止不可达时的兜底，且接管前仍须完成对账（第 5 条）；未停止且未对账的 L1 动作与处置动作不得并行。

4. 外部写者协调：智能体不是唯一写者。GitOps 控制器（启用自动同步与自愈时会把绕过 Git 的直接修改改回）、自动扩缩容、人工变更与其他自动化同样会写入同一资源。执行前须检查目标资源代次与最近外部变更；与变更管理的变更窗口、冻结期联动；对 GitOps 管理的资源，处置应经 Git 提交或经受控方式暂停同步，不与控制器对抗。

5. 锁的可靠性：资源版本校验 + 执行所有者代次校验。 锁以租约持有，持有者失联后租约到期释放。但资源版本校验不能代替所有者校验：执行者 A 持锁读取资源版本 v 后长时间暂停，租约到期由 B 接管；若 B 尚未修改资源，A 恢复后携带的版本仍是 v，其提交可以通过版本校验。exec、抓包等不改变资源版本的动作，这一问题更明显。资源有没有变，与执行者是否仍被授权，是两个不同条件。

   因此规则是：

   • 每次接管生成单调递增的执行代次（fencing token / 执行 epoch）。代次在同一冲突管理域内统一分配：同一资源层级树（或所属集群 / Cell）须共享单一全局单调递增的序列分配源，使不同锁键的代次可全序比较——若只在单个锁键（各自资源 ID）内独立计数，父级路径的接管会携带更低代次而被误拒，或无法拦截旧子资源持有者的滞后请求；
   • 由能够阻断副作用的一方校验代次，即执行侧或下游，而不只是网关在收请求时检查一次。受保护的一方须拒绝代次低于已见最大值的请求[40]；校验须覆盖祖先路径：放行对某资源的操作时，须同时比对该资源自身与其全部祖先节点已见的最大代次（层级锁含义见第 1 条）；
   • 下游不支持代次校验时，由受控执行代理提供等效的串行化与取消确认；取消确认须覆盖在途请求：切断或终止旧代次实例与下游之间的底层传输通道（连接池连接、会话或短期凭证），或等待超过下游单次请求的最大网络超时窗口后再对账——仅靠新代次实例自身的串行化，无法拦截已通过旧实例本地校验、处于网络传输或内核缓冲中的请求；在确认旧操作已停止或已完成对账之前，不开放冲突动作；
   • 租约失效不代表旧执行已停止：接管方须先对账旧操作的实际状态；
   • 资源版本仍用于检测外部变更。

3.6 部署形态 #

六个独立概念：

权限分离由独立身份与执行授权实现；是否还需要物理隔离，取决于威胁模型与资源保证，可在进程、容器、节点池、独立集群、网络分区之间选择。不同身份或不同 SLO 不自动要求不同集群。

目标形态：共享控制面 + Cell 化执行面。

flowchart TB
    subgraph CP["共享控制面（逻辑唯一，多副本高可用）"]
        CP1["Registry / 能力包"]
        CP2["策略与动作注册表"]
        CP3["评测与发布"]
        CP4["审计汇聚"]
        CP5["模型网关与配额"]
    end
    subgraph DP["Cell 化执行面"]
        D1["生产诊断 Cell"]
        D2["生产处置 Cell"]
        D3["巡检 Cell"]
        D4["非生产 Cell"]
    end
    CP -- "签名配置下发 / 缓存" --> D1 & D2 & D3 & D4
    D1 -. "结构化移交" .-> D2

「逻辑唯一」指治理唯一，不指单实例。Cell 的具体切分由 §10.1 的方法依据企业内部安全域判定【待判定】。

起步形态：从两个 Cell 起步（生产诊断、非生产）的前提是——首期不开放生产 L2/L3；巡检未启用，或仅在可证明不影响实时负载的条件下试验。处置与巡检能力准入时再分出对应 Cell。Cell 化会成倍增加 SLO、升级窗口、容量规划与跨 Cell 配置一致性的运维成本，这是需要权衡的代价。

会话级隔离（任何 Cell 内都须满足）：独立上下文；Skill 可见范围按租户与应用决定；凭证按身份下发；会话级 token、步数、时长、并发限额；会话产物与记忆按租户分区；审计可按租户导出。

控制面可用性与降级：

缓存有效期、撤权时效由 §10.1 与安全负责人确定【待判定】。

降级边界与失联判定（与 §1.6 硬性要求 8 同口径）：

• 失联判定：以本地策略 / 撤权同步心跳中断超过最大允许 TTL 为准；单次连接失败不触发停止。
• L1 及以上：在受撤权最大传播时效约束的短 TTL 签名缓存内可继续接受调用——该 TTL 即 §10.1 第 6 步所称「策略缓存有效期」；同步中断超过该 TTL 即视为无法核验授权，停止接受新调用；已开始的执行按 §7.8 收尾与对账。
• L0 的例外与边界：低风险 L0（normal + summary）在失联期间可按数据策略确定的缓存有效期降级执行（受控例外），并在审计与结论中标注「按缓存降级执行」；其余 L0（涉及 sensitive / restricted 数据或 raw 产出）与 L1 及以上同规。撤权指令已覆盖的资产或会话不受缓存降级保护。

不阻断现有运维链：智能体任何组件故障，都不得阻断现有告警、工单与人工处置链路；人工接管须有明确负责人与时限。

4. 生态共建：平台与应用的解耦 #

4.1 目标模型：运行时内核 + 能力包 #

平台团队交付四件套：运行时内核（推理循环、上下文治理、路由、网关、审计、限额、人在回路）、契约（能力包格式、SOP 模板、查询模板规范、禁止项）、门禁（契约校验、能力推导、评测、安全扫描）、观测（包维度成功率、超时率、人工否决率、成本）。

应用团队的默认交付物是声明式能力包——一组文本文件，不是服务进程。 平台侧扩展点设计可参考 Azure SRE Agent 的 skill、自定义 agent、Python 工具、MCP server、hook 五类[14]。

4.2 研发流程与发布链 #

flowchart LR
    subgraph REPO["应用仓库（默认路径）"]
        R1["skills/"]
        R2["queries/ 声明式查询"]
        R3["topology/ 依赖声明"]
        R4["knowledge/"]
        R5["evals/"]
    end
    subgraph CI["应用侧 CI"]
        C1["契约校验 skills-ref + BANK.*"]
        C2["能力推导与策略校验"]
        C3["重复定义 / 冲突扫描"]
        C4["禁止项与注入测试"]
        C5["离线评测"]
    end
    subgraph REG["Registry"]
        G1["版本 + 摘要锁定"]
        G2["来源证明"]
        G3["发布通道"]
    end
    subgraph REL["发布"]
        L1["Shadow"]
        L2["Canary"]
        L3["Production"]
    end
    REPO --> CI --> REG --> REL

发布链：契约校验 → 能力推导与策略校验 → 冲突扫描 → 禁止项与注入测试 → 离线评测 → Shadow → Canary → Production，配合语义化版本、版本锁定、在线指标、自动熔断与快速回滚。

• Shadow：新版本以只读方式并行运行，结论不进入正式报告、不触发动作，与人工结论或旧版本对比。
• 注入测试：在知识正文、工具描述、工具返回与模拟日志中嵌入恶意指令，验证不被执行。发布前通过不等于运行时安全，运行时防护见 §7.9。
• 禁止项：应用包中的脚本、hook、动态 shell、任意外部引用一律禁止；确有需要的进入独立审核沙箱。
• 内核 API 版本化：内核升级不强制所有应用包同步升级。

4.3 运行面隔离 #

依赖失败的区分：强制工具或安全配置加载失败 → 会话失败退出；可选证据源失败 → 继续，但必须在结论中报告覆盖损失。

4.4 能力包契约与承载 #

目录结构：

<app>-sre-package/
├── package.yaml      # 应用 ID、owner、请求的可见范围、依赖的内核 API 版本、请求的动作清单
├── skills/           # SKILL.md，metadata 按 §2.4，能力类别仅 L0
├── queries/          # 参数化只读查询模板（类型化参数、行数/扫描成本/时间窗上限）
├── topology/         # 业务依赖声明，供确定性关联与相关性扩域使用
├── knowledge/        # 架构说明、错误码、业务口径（与 Skill 分离）
└── evals/            # 评测清单与用例

topology/ 使确定性关联覆盖业务自定义依赖（平台 CMDB 往往只到应用粒度）；queries/ 使业务信息查询成为可审计、可限流的参数化模板。

承载路径：

默认与例外的实际比例待盘点后确定；试点出口不以「零自建进程」为条件，以免排除合法的例外路径。

App Capability Service：逻辑统一、物理随 Cell 部署。 统一承载不会消除故障，只是把故障从独立 server 转移到共享执行器；应用 A 的重查询、连接泄漏或解析错误仍可能影响应用 B。因此：

4.5 跨应用诊断的授权协作 #

严格的应用隔离与跨应用根因定位之间需要显式的协作机制。

1. 候选依赖的确定：由确定性关联与应用 topology/ 声明给出候选下游（共享 Redis、MQ、LB、数据库等）。topology/ 属应用包自报内容，只作为相关性候选线索，不作为依赖范围的授权来源；跨应用资产自动加载的授权边界严格以平台权威服务目录 / CMDB 登记的依赖关系为准（§1.6 硬性要求 2 不采信自报值；§4.3 闸 1 的加载隔离不因 topology/ 声明而放宽）。
2. 在授权范围内扩域：候选依赖的相关 Skill 与查询若在当前会话授权范围内，直接加载。
3. 跨应用扩域的两种方式：
   • 联合事件授权：以事件为单位申请有范围、有期限的跨应用取证授权，经审批后生效，事件关闭即失效；
   • 委托取证：由目标应用的授权主体独立取证，返回经授权的摘要，不暴露原始数据。
4. 未知应用身份不走全局通用账号兜底。
5. 证据不足出口：扩域被拒或证据不可共享时，结论状态为 insufficient_evidence，并列明缺失的依赖与原因，不得静默收敛为已确认根因。

4.6 版本与供应链 #

• 摘要（SHA）的作用是内容锁定与篡改检测，不证明由谁授权发布，也不阻止一个恶意但已被锁定的版本运行。发布记录须绑定作者、审核人、构建与测试证据、完整依赖摘要，以签名制品或受控制品库的等效来源证明约束来源。
• 撤销与紧急下架：维护撤销列表；紧急下架须同时收回相关工具权限或终止活跃会话——已加载进上下文的文本不会因下架而消失。
• 会话版本清单：每个会话冻结并记录模型、提示、Skill、Knowledge、工具、工作流、策略、拓扑的版本，线上观测记录查询时点，以便复现。冻结的策略版本只用于复现决策输入；有效授权始终以当前撤销与限制策略为准（§1.6）。

5. 平台集成：MCP、A2A 与能力网关 #

5.1 协议现状 #

• AAIF【事实】：Linux Foundation 于 2025-12-09 成立 Agentic AI Foundation，首批项目为 MCP（Anthropic）、goose（Block）、AGENTS.md（OpenAI）[19]；2026-08 A2A 加入，AAIF 表述其项目分层为 AGENTS.md（指令与上下文）、goose（运行时）、MCP（智能体与工具连接）、agentgateway（流量中介与管控）、A2A（智能体间互操作）[21]。

• A2A【事实】：v1.0 为首个稳定规范，含多协议支持、企业级多租户、签名 Agent Card；截至 2026-04 支持组织超过 150 家，已进入 Azure AI Foundry / Copilot Studio、AWS Bedrock AgentCore Runtime 与 Google Cloud[20]。

• 分层【事实，三方分析】：MCP 管智能体与工具 / 数据的纵向集成，A2A 管智能体之间的横向协作，多数生产系统两者并用[38]。

• 「ACP」一词有三种含义，企业内部文档须写全称【事实】：

  名称	含义	现状
  Agent Communication Protocol（IBM / BeeAI）	智能体间通信	2025-08-29 宣布并入 A2A，ACP 团队收束自身开发、转向贡献 A2A[22]
  Agent Client Protocol（Zed / JetBrains）	编辑器或客户端与编码智能体之间	活跃，与本场景基本无关[31]
  腾讯侧所称 ACP	融合 MCP / A2A / AG-UI 的企业交互层框架	厂商自定义，非跨厂商标准[35]

  本报告中智能体间协议统一指 A2A。

5.2 集成方式判定 #

flowchart TB
    Q1{"对方提供的是<br/>查询/取数/受控动作?"}
    Q1 -- "是" --> Q5{"新建或重构的<br/>跨边界能力?"}
    Q5 -- "是" --> A["MCP Server"]
    Q5 -- "否，存量接口" --> A2["能力网关适配<br/>暴露统一工具契约"]
    Q5 -- "否，同进程稳定能力" --> A3["原生工具<br/>遵守统一工具契约"]
    Q1 -- "否" --> Q2{"对方能独立理解目标、规划、<br/>调用工具并产出专业结论，<br/>且有独立权限域与任务生命周期?"}
    Q2 -- "是" --> B["A2A（经网关，§5.4）"]
    Q2 -- "否" --> Q4{"仅有 CLI / 脚本?"}
    Q4 -- "是" --> D["CLI 适配层 → 统一工具契约（§6.5）"]
    Q4 -- "否" --> E["先做网关适配"]

5.3 MCP 的适用边界 #

无论采用哪种实现，工具契约必须统一（§7.4）：输入输出 Schema、动作注册表登记、鉴权、限流、超时、审计由能力网关统一施加，与协议选择无关。

可以说：MCP 是企业级工具能力的首选北向互操作协议；底层实现可以是 API、SDK 或 CLI；治理由网关按统一契约施加。

证据支撑【观察】：Google SRE 的工具面以 MCP 为基础[17]；Azure SRE Agent 以 MCP server 接入外部观测平台[14]；Google SRE 使用 Gemini CLI 处理故障时同样经 MCP 连接 Grafana、Prometheus、PagerDuty[32]。

5.4 A2A 与远端委托 #

「对方有智能体形态」不是使用 A2A 的充分条件。 判据是对方能否独立理解目标、规划、调用工具并产出专业结论，且拥有独立的权限域与任务生命周期。只提供 getPodStatus、getEvents、getYaml 一类能力的平台用 MCP 或网关适配即可；能独立完成「分析某服务为何频繁重启并给出证据链」的平台智能体，才值得以 A2A 接入。

把远端智能体包装成 ask(question, context) 不会使它变为只读。 若对方持有写权限，一句自然语言请求就可能绕过本地处置工作流。因此远端委托必须：

任务生命周期语义【事实】：A2A 任务的终态为 completed、canceled、rejected、failed；任务进入终态后不能重启，后续交互须在同一 contextId 下发起新任务[27]。据此约定：

• 以持久任务 ID 跟踪；重复提交须幂等；
• 超时后先查询任务状态，不盲目重发；
• 请求结束不等于任务终态；取消请求不等于远端动作已回滚；
• 晚到结果绑定原任务，不得用于已关闭事件，也不得触发新事件的处置；
• 委托身份过期时任务应失败而非以其他身份续跑。

签名 Agent Card 与协议本身不替代业务权限审查。

5.5 平台集成建议 #

5.6 能力网关 #

MCP、A2A、原生工具与 CLI 适配的调用都经过能力网关。AAIF 将「流量中介与管控」单列为栈中一层（agentgateway）[21]，说明这是智能体架构的标准组成部分。

MCP 工具注解只用于展示与发现：注解是提示且不可信，不可信服务端可以谎报只读；需要不外泄保证时依靠网络管控或沙箱，注解也不能使模型抵抗提示注入[25]。审批与授权由网关依据动作注册表判定。

6. CLI 集成模式 #

6.1 判断 #

• 调用接口层没有统一标准，但原语已高度收敛，参数名各家不同。
• 能力包层在标准化：Agent Skills 的 SKILL.md 与渐进式披露已有独立规范站点与参考校验实现[24]。企业内部能力包格式直接采用该规范，企业字段放入 metadata。
• AGENTS.md 属于另一层次：官方定位为「a simple, open format for guiding coding agents」「a README for agents」，承载构建命令、代码规范、测试步骤等仓库级上下文[23]，不是企业能力包格式。

• 工具层：跨边界互操作以 MCP 为首选（§5.3）。CLI 只作实现，不作契约。

6.2 收敛的调用原语 #

以 Claude Code 官方文档为样本【事实】[10]：

能力语义相近、参数名不同，且宿主间格式可移植不等于权限、hook 与工具语义等价。业务侧不直接调用 CLI，由平台维护宿主适配层。

6.3 跨宿主适配案例 #

Google 开源的 SRE 扩展仓库以同一组 Skill 提供多套宿主清单（.claude-plugin、.copilot-plugin、.codex-plugin、.gemini、.agents），其兼容表对不同宿主标注了不同状态（充分测试、可用但部分测试、未测试等）；Skill 组织为「调查入口 + 分域剧本」形态（如 investigation-entrypoint、gcp-playbooks、cloud-logging、postmortem-generator）[18]。

这提供了一个跨宿主适配的案例：Skill 与 SOP 可以跨宿主复用，宿主适配层需要各自维护。单一项目不能证明行业主流，也不能替代本项目的端到端验证——宿主版本与实测矩阵须自行建立。

6.4 本文采样案例中的差异 #

以上为少量案例的观察，不代表国内外市场整体。企业内部取向【推论】：编排形态与既有变更、审批、值班、审计治理对齐；能力包格式对齐 Agent Skills 规范，以保持知识资产可移植。

6.5 CLI 适配层契约 #

禁止形态：shell("kubectl " + 模型生成的参数)、bash -c "${LLM_OUTPUT}"。这类形态同时放大提示注入、参数与选项注入、越权、不可审计、输出不可结构化五类风险。

适配层要求：

对上暴露语义化工具，例如将 kubectl get pod 包装为：

get_pod_status(namespace, pod_name)
  → {"status": "Running", "restartCount": 3, "lastTerminationReason": "OOMKilled", "observedAt": "..."}

7. 核心契约 #

本章列出首期须冻结的契约（第 9 章 P0-A）。字段为最低要求，具体编码在契约评审中确定。

7.1 标识体系 #

7.2 Incident Context #

事件标识与来源告警集合；受影响对象的不可变身份与代次；租户、应用、环境、敏感度；时间窗；已知近期变更；会话版本清单（模型、提示、Skill、Knowledge、工具、工作流、策略、拓扑的版本）；授权范围与扩域记录（§4.5）。

7.3 Evidence 对象 #

结论对象（§2.8）引用证据对象，并区分事实、假设、根因候选、已确认根因，保留 unknown、insufficient_evidence、conflicting_evidence、stale 状态。

7.4 工具契约与动作注册表 #

每个动作登记：名称与语义；输入 / 输出 Schema；能力类别与风险属性（§1.5）；作用范围；可恢复性说明；冲突规则（§3.5）；所需身份；执行器；超时与配额；数据分级与产物去向；owner 与版本。授权以注册表为准，不以工具注解或能力包自报为准。

7.5 能力包契约 #

见 §2.4（Skill 元数据）与 §4.4（目录结构与承载路径）。发布门禁校验：规范字段、BANK.* 字段、能力推导与策略覆盖、scope 发布权限、评测清单、禁止项。

7.6 Resolver 接口 #

resolve(incident_context, session_grant) →
  { authorized_scope,       // 授权过滤结果，不可越过
    skills[],               // 初始能力集及选择依据
    tools[],                // 工具子集
    expansion_candidates[], // 候选依赖与扩域线索（topology/ 仅作候选，授权以平台服务目录为准，§4.5）
    retrieval_confidence,   // 校准后的检索置信度（规模化后）
    resolver_version }

re_resolve(incident_context, session_grant, expansion_grant) →
  { expanded_scope,         // 扩域获批后的授权范围
    skills_add[],           // 增量装配：目标应用的技能增量
    tools_add[] }           // 增量装配：目标应用的工具增量

扩域后的增量重解析：跨应用扩域获批后（§4.5 第 3 条），由 re_resolve 按扩域授权执行增量重解析，返回目标应用 skills[] / tools[] 的增量并经授权过滤后装配；初始能力集不重放、不重载。两种扩域模式在能力网关与 App Capability Service 侧的凭证与隔离边界：

• 联合事件授权：在目标应用范围内使用该应用自己的执行身份（§4.4「每应用独立身份」）；能力网关按目标应用作用域逐次鉴权并审计，凭证由对应执行器按目标应用身份绑定与下发，不以主应用身份跨应用执行；
• 委托取证：不装配目标应用资产；由目标应用的授权主体在其范围内取证，仅返回经授权的摘要，遵守目标应用的数据策略与摘要隔离，主会话不接触目标应用的原始数据与凭证。

7.7 结构化移交 #

从诊断域到处置域：incident_id；结论对象（§2.8）；证据引用；与安全性和适用性相关的反证与未决假设；建议动作（登记的工作流名）与规范化参数；前置条件（目标状态、代次、时间有效期）；移交时间。处置域执行前须复核前置条件。

7.8 执行契约与状态机 #

适用范围：所有有副作用的 L1–L3 动作（§3.5）。L2/L3 使用完整状态机；L1 使用下方的简化状态机。两个状态机均描述整个 operation_id 的生命周期（§7.1）——其中「执行 → 待核实」的每一轮（L2/L3 为 EXECUTING → VERIFYING，L1 为 RUNNING → VERIFYING）对应一次 attempt_id；受控重试（见下）在同一 operation_id 下生成新 attempt_id，不重签审批（审批须仍有效且绑定未变），但必须重新通过执行前复核。

操作记录最低字段：operation_id；目标资源不可变身份与代次；动作或工作流名与版本；规范化参数摘要；证据版本；策略版本；审批人、审批期限与适用范围；幂等键；冲突域与 owner_epoch；operation_outcome 与 compensation_outcome（分别记录）。

规则：

• 审批绑定：审批与参数摘要、目标代次、动作或工作流版本绑定；任一变化须重新审批；过期或被撤销的审批不得复用。
• 去重：以幂等键去重；重复提交返回已有操作的状态，不产生第二次执行。受控重试（见下）是同一 operation_id 下的新 attempt_id，不视为重复提交。
• 执行前复核：重新检查目标状态、前置条件、冲突域锁、owner_epoch 与外部近期变更。
• 超时不等于失败：超时进入「待结果核实」，先对账实际结果，不得直接重试。「已启动但回包丢失」同样进入待核实，对账确认未执行后方可重试。受控重试的条件：对账确认为未执行且无副作用（L1 亦含动作已结束且无残留副作用、但未生成有效产物的情形），且（a）审批仍有效、绑定未变（参数摘要、目标代次、动作 / 工作流版本均未变化）、（b）重试次数未超过策略配置的上限；满足时在同一 operation_id 下以新 attempt_id 回到执行前复核——L2/L3 由 FAILED 回到 APPROVED，L1 由 FAILED 回到 AUTHORIZED（见状态机）；任一条件不成立时，L2/L3 经 FAILED 转人工（MANUAL），L1 终结于 FAILED（无副作用与产物，证据缺口在结论中报告，§4.3）。
• 成功判定：只有原审批目标的业务后置条件满足才记为成功；以调用返回成功为准是错误的。
• 补偿与成功分开：补偿完成只说明已恢复到可接受状态，不表示原处置目标达成，记为 COMPENSATED；补偿完成不自动关闭业务事件。
• 补偿前复查：补偿前检查目标当前状态，若已有新变更则转人工。
• 人工接管：任何状态均可转人工。MANUAL 只表示自动化的责任移交给人，不表示影响已消除；转交须关联接管记录（接管人、时间、当前剩余影响）。
• 紧急停止：在约定时效内生效；停止后进入待核实，而不是直接判定失败。

L2/L3 状态机：

stateDiagram-v2
    [*] --> PENDING_APPROVAL
    PENDING_APPROVAL --> APPROVED: 审批通过（绑定参数/代次/版本）
    PENDING_APPROVAL --> REJECTED: 驳回或过期
    APPROVED --> PENDING_APPROVAL: 参数/代次/版本变化
    APPROVED --> EXECUTING: 执行前复核通过
    APPROVED --> MANUAL: 复核失败
    EXECUTING --> VERIFYING: 返回 / 超时 / 回包丢失 / 紧急停止
    VERIFYING --> SUCCEEDED: 原目标后置条件满足
    VERIFYING --> FAILED: 确认未生效且无副作用
    VERIFYING --> COMPENSATING: 部分生效或有副作用
    VERIFYING --> MANUAL: 无法确认结果
    FAILED --> APPROVED: 受控重试（新 attempt_id；限额内、审批未过期）
    FAILED --> MANUAL
    COMPENSATING --> COMPENSATED: 补偿完成并核实（原目标未达成）
    COMPENSATING --> MANUAL: 补偿失败或出现新变更
    COMPENSATED --> MANUAL
    REJECTED --> [*]
    SUCCEEDED --> [*]
    MANUAL --> [*]

状态标签：PENDING_APPROVAL 待审批；APPROVED 已批准；EXECUTING 执行中；VERIFYING 待结果核实；SUCCEEDED 原目标成功；FAILED 失败；COMPENSATING 补偿中；COMPENSATED 已补偿（原目标未达成）；MANUAL 人工接管；REJECTED 已驳回。

L1 简化状态机：

stateDiagram-v2
    [*] --> PENDING_APPROVAL: 需审批的 L1 动作
    PENDING_APPROVAL --> AUTHORIZED: 审批通过（绑定参数/代次/动作版本）
    PENDING_APPROVAL --> REJECTED: 驳回或过期
    [*] --> AUTHORIZED: 免审批动作授权通过
    AUTHORIZED --> PENDING_APPROVAL: 需审批动作的参数/代次/动作版本变化
    AUTHORIZED --> RUNNING: 执行前复核通过（含冲突规则与 owner_epoch）
    AUTHORIZED --> REJECTED: 权限驳回
    AUTHORIZED --> MANUAL: 复核发现临时冲突或前置状态漂移
    RUNNING --> VERIFYING: 返回 / 超时 / 回包丢失 / 停止
    VERIFYING --> DONE: 产物已按数据策略落地，副作用已结束
    VERIFYING --> FAILED: 确认未执行且无副作用，或动作已结束且无残留副作用但未生成有效产物
    VERIFYING --> STOPPED: 确认已终止，残留副作用已清理
    VERIFYING --> MANUAL: 无法确认是否仍在目标上运行
    FAILED --> AUTHORIZED: 受控重试（新 attempt_id；限额内、审批未过期）
    REJECTED --> [*]
    DONE --> [*]
    FAILED --> [*]
    STOPPED --> [*]
    MANUAL --> [*]

状态标签：PENDING_APPROVAL 待审批；AUTHORIZED 已授权；RUNNING 执行中；VERIFYING 待结果核实；DONE 产物落地；FAILED 执行失败（确认未执行且无副作用，或动作已结束且无残留副作用但未生成有效产物）；STOPPED 已停止并清理；MANUAL 人工接管；REJECTED 已驳回。

需审批的 L1 动作从 PENDING_APPROVAL 进入（审批绑定与 L2/L3 同规）；免审批动作直接进入 AUTHORIZED。AUTHORIZED 的复核失败出边按原因拆分：授权 / 权限驳回 → REJECTED；审批绑定项（参数摘要、目标代次、动作版本）变化 → 回到 PENDING_APPROVAL 重新审批；与处置动作的临时冲突或前置条件漂移无法自动处置 → MANUAL。

L1 结果核实关注两件事：动作是否已在目标上结束（如 profiling 是否仍在运行），以及产物是否已进入受控存储。对账结果与状态机的对应：执行完成且产物按数据策略落地 → DONE；已终止且残留清理完成 → STOPPED；确认未执行且无副作用，或动作已结束、无残留副作用但未生成有效产物 / 落盘失败 → FAILED。FAILED 满足受控重试条件时回到 AUTHORIZED（新 attempt_id），否则终结（证据缺口在结论中报告，§4.3）。状态与 §6.5 的输出契约（成功 / 失败 / 超时 / 拒绝授权）对应。

可复用企业内部既有工作流或变更平台承担上述保证，但须在契约中明确由哪个组件承担哪一项。

7.9 数据链：分类、授权、留存与删除 #

信任等级与执行权限分离：经审批发布的 Skill 可作为受控任务指引，但不能授予或扩大执行权限；日志内容、工具描述与工具返回、检索得到的知识中的指令性内容一律按非可信数据处理，不获得任何执行权限。导出控制：已授权的查询工具不得被用于把敏感数据导出到未授权目标；约束导出目标、长连接与远程资源获取。

7.10 评测数据 Schema #

真实根因标签（与调查输入隔离）；可用信号快照或受限快照查询服务的引用；数据时间窗；工具、查询语义、拓扑与知识版本；事件族与划分标记（训练 / 调参 / 测试，§8.2）；标注人、复核人与争议状态；可回放性标记（§8.3）。

7.11 内部子智能体委派契约 #

进程内子智能体（并行只读取证、上下文污染型任务、独立复核，§1.3）的委派适用本契约；字段为最低要求，语义细则（取消、迟到结果、重启恢复与部分失败的处理）随 §9.1 P0-A 契约评审冻结。

8. 评测体系 #

8.1 原则 #

没有评测集就没有泛化，也没有自动化。 评测集既度量效果，也是置信度校准（§2.8）与各阶段准入（第 9 章）的前置依赖。

• 阿里云智能运维团队在会议分享中指出「做 demo 容易，泛化难」，大模型 agent 易出现误诊（如把普通 GC 增多判为内存泄漏）、拒绝合理泛化与死循环，并主张「唯有先构建评测集，泛化性才会从抽象口号变成可触摸的目标」；其评测数据优先采集线上真实故障、其次演练复现、最后模拟系统，要求覆盖每个实体类型与属性字段【事实，三方转述】[33]。该分享公布的根因召回与定位准确率数字评测条件未公开，不作为企业内部目标参照。
• Datadog 以「真实根因 + 当时可获得信号的快照」构成评测样本，把标注嵌入产品交互，用 agent 辅助校验标签（单条校验耗时一周内下降 95% 以上），按技术类型、问题类别、难度分段，刻意保留无关信号与组件作为噪声，每周全量回归，更换模型时全量评估「改进了什么、破坏了什么」【事实】[13]。
• Anthropic 在其研究系统中发现，单次 LLM 调用输出 0.0–1.0 分数与通过 / 失败判定的评分方式与人工判断最一致【事实】[2]。LLM 评分只作辅助，安全类指标由确定性检查与人工复核保证。

8.2 评测集构建 #

数据来源优先级：线上真实故障 > 演练环境复现 > 模拟系统[33]。

覆盖矩阵（验收依据，替代数量门槛）：

标注与切分：

• 标注由负责故障复盘的人确认，保留争议标签与复核记录；
• 按时间、应用或事件族划分训练 / 调参 / 测试集，防止同一故障的变体同时出现在调参集与测试集；
• 数据集冻结并版本化，指标与数据集版本绑定；
• 线上反馈进入评审后才更新评测集与规则，不直接改变生产策略。

8.3 World Snapshot 与重放 #

两种模式共同的约束：

• 不得回查当前生产环境，不得引入事故结束后才存在的数据，不得无依据地生成证据；
• 仿真结果须标明来源，不能冒充真实观测；
• 根因标签与调查输入隔离；
• L1 及以上动作在模拟或演练环境执行，评测重放不得触发真实动作。

8.4 指标字典 #

通用规则：

• 每个指标写明适用总体。不同指标的分母可以不同（如条件准确率与 FNR），但不得因本系统失败（超时、拒答、证据不足、未解决）而把样本移出其适用总体；
• 尚无裁定标签的样本单列数量与覆盖损失，不纳入正确率分母，也不伪造根因标签；
• 分母为零时报告「不适用」并注明原因，不报告 0% 或 100%；
• 所有指标报告置信区间并按 §8.2 维度分段；覆盖率与条件准确率成对报告，防止以拒答抬高准确率。

三组算例（用于校验指标实现）：设 50 个真实故障（均有根因标签）+ 50 个非故障：

目标值、置信要求与责任人按 §10.2 的方法设定【待判定】。

8.5 置信度校准 #

见 §2.8。校准在独立留出集上进行，按技术栈、难度、有无噪声分段；模型、Resolver、Skill 或 Knowledge 语义变更后重算；未经校准的分数只能用于排序。

8.6 虚警复核的安全定义 #

• 「独立」指不继承主诊断的结论偏见，而不是不给复核方信息——复核方须获得告警原文、业务影响、证据与数据缺失情况；
• 复核只出建议，不直接静默告警；
• 复核与主诊断分歧、或证据不足时，保留告警并转人工；
• 同模型、独立上下文不保证错误独立；以 FNR 为首要指标，未见过的故障类型须计入覆盖率与漏报统计。

代码评审场景中「无前置上下文的评审更有效」的经验[4]可作为设计启发，不能直接证明在虚警判定上同样成立，须以本场景评测验证。

8.7 统计与量化说明 #

• 零失误样本的上界：独立同分布的简化条件下，n 次零失误时失误率的单侧 95% 置信上界为 1 − 0.05^(1/n)；n = 100 时约 2.95%（近似 3/n）。因此 100 个零失误案例不能支持「生产极低风险」的结论；安全测试还须结构化覆盖失败机制，而不只是增加正例数量。
• 链式成功率示意：0.95^10 ≈ 59.87%，只在各步条件成功率均为 95% 且成功要求全部步骤成功时成立；平均单步准确率不足以推出端到端成功率，重试、校验与相关错误都会改变结果。仅作示意，不是 SREAgent 实测。
• 用例数量：每 Skill 不少于 5 条用例、首批种子案例规模都是建设起点，不是质量证明。

9. 实施路线与能力准入 #

9.1 阶段与准入 #

本报告不给出承诺性工期；工期与人力按 §10.3 的方法估算。

P1 生产接入前置条件（安全控制不后置于生态规模化）：身份与数据边界已按 §10.1 判定并落实；会话级限额；基础提示注入测试；脱敏与审计；紧急停止；人工降级路径与负责人；L1 审批机制；目标系统负载保护；智能体故障不阻断现有告警、工单与人工处置链。

flowchart LR
    A["P0-A 契约冻结"] --> B["P0-B 最小实现 + 评测集"]
    S["P1 前置安全控制"] --> C
    B --> C["P1 生产诊断试点"]
    C --> D["P2 诊断增强"]
    B --> E["P3 生态共建"]
    C --> F["P4 处置与扩展"]
    D --> F

关键路径由依赖关系决定。若各阶段串行，总周期为各阶段之和，P4 为持续阶段；并行需要独立人力，且不能把关键路径上的依赖并行化。

9.2 三档门禁 #

9.3 验收场景与能力映射 #

以下为待执行用例，具体阈值由服务 owner、安全负责人与平台负责人在试点前批准。每个场景绑定适用能力与最晚验证阶段——须在该能力首次开放前验证，可以在非生产环境提前完成；未通过时，对应能力在执行侧保持禁用。尚未启用的能力，其场景标「不适用」并写明执行侧的禁止条件，不能只写「未测试」。

任何生产 L1 动作开放前，其审批、去重、超时核实、冲突协调、停止与数据控制（A01、A04–A06、A13）必须已验证——不能因为工作流执行器计划在 P4 就推迟这些验证。

评测样本不依赖先放开生产智能体：经授权的历史脱敏故障数据与演练环境数据可以在生产智能体开放前用于建设评测集。因此评测集与生产接入之间不存在必然的循环依赖，没有必要为取得第一批样本而放松安全准入。

10. 实施前需企业内部完成的判定 #

本章不代入企业内部具体信息，只给出每项判定需要依据什么、如何判断、产出什么。判定完成前，相关条目在正文中视为【待判定】。

10.1 安全域与隔离边界 #

依据：

• 网络安全域划分与域间访问控制策略（生产、测试、办公、互联网接入区等）；
• 等级保护定级结果及各安全域的防护要求；
• 数据分类分级目录（哪些数据属于敏感或重要数据，允许在何处处理）；
• 身份、特权账号与凭证管理制度；
• 变更管理与应急处置制度；
• 现有平台的部署拓扑、故障域划分与资源池划分。

判断方法：

1. 列清单：列出待部署组件（控制面各服务、诊断推理实例、L0 / L1 / L2–L3 执行器、App Capability Service、评测与回放环境），以及每个组件访问的资源与数据等级。

2. 识别威胁：对每一组「组件 × 所访问资源」及「共存组件对」，识别凭证泄露后的横向移动、跨租户数据混用、资源争用、故障传播、审计主体混淆五类威胁。

3. 确定要求强度：区分制度强制、内控要求、仅效率考虑三档。

4. 查表定最低隔离粒度：

   要求来源	主要威胁	最低隔离
   制度强制的网络分区	横向移动	网络分区 + 独立集群
   数据分级不允许混合处理	数据混用	独立集群或独立节点池 + 独立存储
   身份不同但处于同一安全域	凭证滥用	独立身份 + 独立执行器进程或容器
   SLO 或负载特征不同	资源争用	独立资源池（节点池、配额、舱壁）
   仅效率考虑	—	逻辑隔离

5. 聚类出 Cell：需要「独立集群 / 网络分区」级隔离的组件聚成不同 Cell；其余在 Cell 内以进程、容器、节点池隔离。不从能力类别直接推导 Cell。

6. 确定时效参数：由安全策略允许的最长失效窗口确定撤权时效；L1 及以上使用的策略缓存有效期不得长于撤权时效（该 TTL 同时是 §3.6 的失联停机判定值）；L0 的缓存有效期由数据策略确定——其中低风险 L0（normal + summary）构成 §1.6 硬性要求 8 的受控例外，其余 L0（涉及 sensitive / restricted 数据或 raw 产出）与 L1 及以上同规，有效期不得长于撤权时效。

产出：边界矩阵——每条隔离要求对应控制措施、依据条款、责任人、验证方式（对应 §9.3 验收场景）；Cell 划分方案；缓存与撤权时效参数。

责任角色：安全负责人批准；平台负责人执行；审计或合规部门复核。

10.2 指标目标值与责任人 #

依据：

• 人工基线：同一冻结评测集上值班工程师的诊断表现，或历史复盘数据中的首次定位正确率、定位耗时、虚警处理耗时；
• 现有自动化基线：已有规则或 AIOps 能力在同一评测集上的表现；
• 业务影响分级与各场景的风险容忍度；
• 可获得的样本量。

判断方法：

1. 先测基线，后定目标。目标相对基线设定，不凭空给出绝对值。

2. 区分两类指标：

   • 安全门禁指标（数据违规、越权、真实故障被静默）：以验收场景验证，目标为不发生，不按平均值折算；
   • 效果指标（正确率、召回、覆盖率、MTTM 改善）：按相对基线的改进设定。

3. 按指标方向取置信界判定达标，不以点估计判定：

   • 收益指标（正确率、召回率、覆盖率等，越高越好）：置信区间下界不低于目标；
   • 风险指标（漏报率、误报率、不必要动作率等，越低越好）：置信区间上界不高于目标；
   • 违规事件（数据违规、越权、真实故障被静默）：独立的一票否决规则，不以平均比例抵消；零观测违规不等于证明真实风险为零（§8.7）。

   样本量规划：比例指标的 95% 置信区间半宽约为 1.96 × √(p(1−p)/n)。示例：预期正确率约 0.8、要求半宽不超过 0.05，得 1.96² × 0.8 × 0.2 ÷ 0.05² ≈ 245.9，每个统计分段约需 246 个样本。这是独立伯努利比例下的正态近似规划；小样本、接近 0 或 1 的比例、稀有错误应使用适当的二项区间方法（如 Wilson 区间或精确区间），不能照搬该近似。

4. 分段设目标：按场景、技术栈、难度分别设定，不以整体平均掩盖困难分段。

5. 成对设定：覆盖率与条件准确率同时设目标，防止以拒答抬高准确率。

6. 明确回退动作：指标低于目标时的处置（降低自治级别、关闭相关能力、回退版本）。

产出：指标实例化表——指标、定义（引用 §8.4）、分母、目标、置信要求、数据集版本、Accountable、回退动作。

责任角色：每个指标一个 Accountable（效果指标为服务 owner，安全指标为安全负责人）；数据集 owner；标注复核人。目标值的设定与变更须经评审并留痕。

10.3 阶段 owner、人力（FTE）与总成本（TCO） #

依据：

• 现有平台能力盘点：网关、工作流或变更平台、制品库、CMDB、可观测平台、身份平台、检索能力等；
• 复用 / 改造 / 新建清单；
• 团队技能与可投入人力；
• 模型的采购与计费方式；
• 历史告警量与事件量（按场景）。

判断方法：

1. 工作分解：按第 7 章契约与 §9.1 阶段做工作分解，每项标注复用、改造或新建。

2. 区间估计：每项用三点估算（乐观 O、最可能 M、悲观 P，期望值 (O + 4M + P) / 6），汇总为 FTE·月的区间。

3. 关键路径：画依赖图，工期由关键路径决定；并行须有独立人力，关键路径上的依赖不能并行化。

4. Owner 指定：每个阶段一个 Accountable；每个契约一个 owner；跨团队依赖明确接口人。

5. TCO 口径（逐项估算）：

   成本项	估算口径
   模型调用	Σ 场景（事件量 × 每事件会话数 × 每会话 token × 单价），分峰值与均值；计入重试、子智能体与复核带来的倍数——多智能体的 token 倍数须在本场景实测（§3.4）
   存储与回放	证据、审计、快照的容量 × 留存期
   下游查询负载	对日志、APM 等平台新增的查询量与成本
   平台开发与运维	FTE
   应用侧能力包维护	FTE
   安全审核与合规	FTE 或外部成本
   评测标注与复核	FTE

6. 收益只在试点实测后计算，与基线采用同一口径（节省的人工时、MTTM 改善对应的影响减少）；试点前不给出投资回报结论。

产出：阶段计划（owner、依赖、关键路径、FTE 区间、出口判据）；TCO 模型表。

10.4 中文元数据的 token 实测 #

依据：选定的目标模型及其版本（含官方 token 计数接口或同源 tokenizer）；选定的宿主（CLI 或平台）及其版本；代表性样本（Skill 元数据、SKILL.md 正文、引用文件、工具 Schema、典型证据摘要）。

判断方法：

1. 用目标模型的计数接口实测，不用字符数或英文经验换算——中文与英文的 token 密度不同，不同模型的 tokenizer 也不同。
2. 确认宿主的常驻范围：实测宿主实际在启动时加载哪些字段（仅 name 与 description，还是包含其他字段），按实际常驻内容计数。
3. 分项测量：常驻（元数据）、激活（正文与引用文件）、工具 Schema、典型证据摘要分别统计。
4. 报告分布：P50、P95、最大值，不只报均值。
5. 按 P95 做容量估算：常驻容量估算 ≈ N_skill × P95(元数据) + N_tool × P95(Schema) + T_system。这是保守的规划值，不是硬上界，也不等于合计值的 P95。用它检验 §2.9 的占比，反推在所选窗口下可常驻的 Skill 数与可注入的工具数，据此确定 §2.2 语义检索层的启用时点。运行时每次请求仍按实际选中内容计数，并为输入、输出与其他模型开销保留预算；超限时按既定顺序裁剪、压缩或拒绝。
6. 质量实测同步进行：在评测集上观察 Skill 选择准确率随常驻 Skill 数的变化，作为 §2.2 第 2 条启用条件的依据。
7. 重测触发：更换模型或宿主版本；元数据规范变更；Skill 数量显著增长。

产出：token 实测报告（模型与宿主版本、样本说明、分布、预算结论、启用时点建议）。

11. 风险与规避 #

12. 参考资料 #

一手（官方文档、工程博客、基金会公告、规范原文）

1. Anthropic — When to use multi-agent systems (and when not to)
2. Anthropic — How we built our multi-agent research system
3. Cognition — Don't Build Multi-Agents
4. Cognition — Multi-Agents: What's Actually Working
5. Anthropic — Effective context engineering for AI agents
6. Anthropic — Equipping agents for the real world with Agent Skills
7. Claude Code Docs — Skills（含 allowed-tools 预批准语义）
8. Claude Code Docs — Subagents
9. Claude Code Docs — Create and distribute a plugin marketplace
10. Claude Code Docs — Run Claude Code programmatically
11. LangChain — Choosing the Right Multi-Agent Architecture
12. Datadog — How we built an AI SRE agent that investigates like a team of engineers
13. Datadog — How we built a real-world evaluation platform for autonomous SRE agents at scale
14. Microsoft Learn — Overview of Azure SRE Agent
15. Microsoft Learn — Incident Response Plans in Azure SRE Agent
16. Microsoft Learn — Create and configure subagents in Azure SRE Agent
17. Google Cloud Blog — How Google SRE is using agentic AI to improve operations
18. GitHub — gemini-cli-extensions/sre
19. Linux Foundation — Formation of the Agentic AI Foundation (AAIF)
20. Linux Foundation — A2A Protocol Surpasses 150 Organizations
21. Agentic AI Foundation — A2A joins AAIF's open agentic stack（2026-08-17）
22. LF AI & Data — ACP Joins Forces with A2A（2025-08-29）
23. AGENTS.md
24. Agent Skills — Specification
25. Model Context Protocol Blog — Tool Annotations as Risk Vocabulary
26. Model Context Protocol — Security Best Practices（token 透传、混淆代理、状态句柄）
27. A2A Protocol — Life of a Task
28. AWS — AWS DevOps Agent is now generally available（2026-03-31）
29. Kubernetes — KEP-277: Ephemeral Containers
30. PostgreSQL — EXPLAIN
31. Zed — Agent Client Protocol

三方（媒体转述、会议报道、第三方测评与分析，仅作趋势与量级参考）

32. InfoQ — From Paging to Postmortem: Google Cloud SREs on Using Gemini CLI for Outage Response
33. InfoQ — 突破泛化瓶颈：阿里云智能运维 Agent 评测体系实践（会议分享报道）
34. InfoQ — AWS Announces General Availability of DevOps Agent
35. 腾讯云开发者社区 — 2026 AI Agent 落地实践大公开：ACP 协议、智能体平台架构、工作流引擎
36. diginomica — Dynatrace Perform 2026: why agentic AI only works when determinism comes first
37. Unblocked — How Many MCP Servers Is Too Many? The Tool Overload Problem
38. Zylos Research — Agent Interoperability Protocols 2026

一手（补充）

39. arXiv — RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation（论文原文，表 1 为方法对照）
40. Hazelcast Docs — FencedLock: Fencing Tokens（仅用于说明执行代次机制，不代表建议采用该产品）
41. arXiv — STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds（论文原文；Yinfang Chen 等，2025）
42. arXiv / ACM — Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis（论文原文；Changhua Pei 等，WWW '25 Industry Track，2025）

未纳入的材料：国内银行同业运维智能体的一手架构材料、华为云相关产品的架构级材料，本次均未检索到可引用的公开原文，正文未据此下结论。