本文以 Project k8s-log-<id> 为例，展示Generate SLS SOP 工具的完整执行过程和生成知识后的使用方法。
背景
Generate SLS SOP是一个从 SLS Project 中自动提取、精选、结构化日志知识的工具，生成 SOP Agent 可直接消费的结构化知识库。
k8s-log-<id> 是 ACK 集群开启容器可观测后自动创建的，内置覆盖 K8s 审计、事件、容器日志等核心场景的预置资源。
本文展示了从数据到知识的完整链路：
知识生成：Generate SLS SOP 自动从 SLS Project 中提取、精选、结构化日志查询知识，生成 SOP Agent 可直接消费的结构化知识库。
知识使用：生成的 SOP 支持两种使用模式——模板匹配适用于常规监控、审计等标准化场景；知识引用适用于故障定位等需要多轮推理的场景。
两种模式的共同点是：用户无需了解底层日志结构，查询能力已被结构化沉淀在 SOP 中。Generate SLS SOP 将分散在不同 LogStore 中的查询能力提炼为可复用的知识模块，使 SOP Agent 能够在各类排障场景中自动编排查询，降低日志分析的门槛。
准备工作
Generate SLS SOP 以 SKILL 形式分发——一种可安装到 AI Agent 的可复用指令模块，通过以下方式一键安装到支持的 Agent 平台（Cursor、Claude Code、Cline 等）：
npx skills add https://github.com/aliyun/sop-chat --skill generate-sls-sop -g -y前置依赖包括 Python 3 和 aliyun CLI（>= v3.0.308，用于 SLS 模式）。详细用法请参考README。
一、知识生成
向 Agent 发出指令：「帮我生成 project k8s-log-c8f3002d205724aa0aa692ab153ac30b8 的 SOP 文档，需要验证 query」，generate-sls-sop 这个 SKILL 随即被加载，依次执行全局准备（Phase A）、并行处理（Phase B）、全局聚合（Phase C）三个阶段。
Phase A：全局准备
Step 0：恢复检测
首次运行时，检测到无历史检查点，自动从 Step 1 开始执行。
Step 1：资源筛选
经过自动筛选Project 下的LogStore。跳过无关联资源的 LogStore（无 dashboard/alert/scheduled_sql 关联）和内部 LogStore（如 internal- 前缀）——最终保留具备生成价值的 LogStore。
Step 3：配置确认
人机协作检查点：确认 LogStore 的简化名称和输出路径，并自动匹配到包含现有 SOP 文档的根目录 sls-docs。
Phase B：并行处理
进入 Phase B，为 LogStore 启动并行 Task Agent 进行处理。
容错机制：若某个 Task Agent 因模型限流导致执行失败。得益于步骤级检查点机制，无需从头重跑——只需重新运行 SKILL，系统自动从失败步骤恢复继续执行。
Phase C：全局聚合
LogStore 的 SOP 文档全部生成完成，进入 Phase C 进行全局聚合。
生成的 SOP 文档包含结构化的查询模板，可直接用于日志分析。
二、知识使用
生成的 SOP 不绑定到特定集群——它沉淀的是通用的日志查询能力，可被应用到任意同类型的集群。本节通过另一个 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 的场景，展示生成的日志知识如何被使用。
模板匹配
生成的 SOP 文档可直接被 SOP Agent 读取并执行。本节展示「用户发出指令 → SOP Agent 匹配查询模板 → 执行并返回结果」的直接使用模式。在智能问答助手中新建对话，输入自然语言指令即可完成查询。
场景一：安全审计——保密字典访问记录
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 中 Secret 最近一天的访问记录。
SOP Agent 自动匹配 k8s-audit SOP 中的相关查询模板，生成并执行审计日志查询，返回所有 Secret 资源的访问记录（包括操作的账号、访问的 Secret、源地址、访问频率等）。
场景二：运维监控——命令执行列表
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 最近一天的命令执行列表。
SOP Agent 定位到 k8s-audit SOP 中 exec 相关的查询模板，返回集群内所有 kubectl exec 操作记录（包括执行者、目标 Pod、执行命令、时间戳等），便于安全回溯和合规审计。
场景三：异常事件——Pod OOM 事件
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 最近一天的 Pod OOM 事件。
SOP Agent 匹配 k8s-event SOP 中的 OOM 事件查询模板，返回因内存不足被终止的 Pod 列表（包括 Pod 名称、命名空间、所在节点、OOM 发生时间等），帮助快速定位内存异常问题。
知识引用
上一节展示的是 SOP 模板匹配场景——SOP Agent 直接匹配已有查询模板，一次执行返回结果。但真实的故障排查往往需要多次查询日志，并根据中间结果选择不同的排查路径。这类场景需要编写独立的排查 SOP，并引用 Generate SLS SOP 已生成的日志知识——无需了解底层日志结构，只需指定「查询 k8s 事件」或「查询 k8s 审计」即可。
场景一：故障排查——Pod 驱逐问题
排查 SOP 编写：排查文档通过引用 Generate SLS SOP 生成的内容获取查询能力。
## 依赖文件
排查过程中需要引用以下文件获取查询能力：
- [k8s-event/overview.md](k8s-log/k8s-event/overview.md) - Kubernetes 事件日志查询
- [k8s-audit/overview.md](k8s-log/k8s-audit/overview.md) - Kubernetes 审计日志查询排查流程按驱逐类型分支处理，但编写时不需要了解日志细节：
## 排查流程
### 步骤 1: 查询 Pod 驱逐事件
**数据源**: k8s 事件
**提取信息**:
- 驱逐类型（如 Evicted、TaintManagerEviction）
- 驱逐原因详情
- Pod 所在节点
**判断标准**:
- 如果驱逐类型为 `Evicted` → 进入路径 A
- 如果驱逐类型为 `TaintManagerEviction` → 进入路径 B
---
### 路径 A: Evicted（kubelet 资源压力驱逐）
**场景**: 节点资源不足，kubelet 主动驱逐 Pod
**步骤 A1**: 从驱逐事件获取原因
- 典型原因示例: `The node was low on resource: memory`
- 提取 Pod 驱逐时所在的节点信息
**步骤 A2**: 查询节点事件确认根因
- **数据源**: k8s 事件
- **查询目标**: 找到节点相关的资源压力事件
---
### 路径 B: TaintManagerEviction（污点驱逐）
**场景**: 节点被打上 NoExecute 污点（如节点 NotReady），控制平面驱逐 Pod
**步骤 B1**: 从审计日志获取 Pod 删除记录
- **数据源**: k8s 审计
- **提取信息**: 找到对应 Pod 的删除记录和所在节点
**步骤 B2**: 查询节点事件确认根因
- **数据源**: k8s 事件
- **查询目标**: 找到节点的污点/状态变化事件实际排查过程：
用户指令：K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 的 Pod k8s-event-sim-oom-kill-3f25adf1 被驱逐，调查原因。
SOP Agent 定位到 pod-eviction-troubleshooting.md，并通过引用的 k8s-event SOP 获取查询 Pod 驱逐事件的方法。并找到 Pod 被调度到了某个节点A上，进一步查询节点A上是否有资源压力事件，继续查询 Pod 完整生命周期，综合分析后得出结论。