本文以 Project k8s-log-<id> 为例，展示 Generate SLS SKILL 工具的完整执行过程和生成知识后的使用方法。
背景
Generate SLS SKILL 是一个从 SLS Project 中自动提取、精选、结构化日志知识的工具，生成 SLS DataAgent 可直接消费的结构化知识库。
Generate SLS SKILL 与 SLS DataAgent 是上下游关系：前者生产 SKILL 知识文档，后者在排障/审计场景中加载并执行其中的查询模板。
k8s-log-<id> 是 ACK 集群开启容器可观测后自动创建的，内置覆盖 K8s 审计、事件、容器日志等核心场景的预置资源。
本文展示了从数据到知识的完整链路：
知识生成：Generate SLS SKILL 自动从 SLS Project 中提取、精选、结构化日志查询知识，生成 SLS DataAgent 可直接消费的结构化知识库。
知识使用：生成的 SKILL 知识支持两种使用模式——模板匹配适用于常规监控、审计等标准化场景；知识引用适用于故障定位等需要多轮推理的场景。
两种模式的共同点是：用户无需了解底层日志结构，查询能力已被结构化沉淀在 SKILL 知识中。Generate SLS SKILL 将分散在不同 LogStore 中的查询能力提炼为可复用的知识模块，使 SLS DataAgent 能够在各类排障场景中自动编排查询，降低日志分析的门槛。
准备工作
Generate SLS SKILL 以 SKILL 形式分发——一种可安装到 AI Agent 的可复用指令模块，通过 npx skills add 一键安装到支持的 Agent 平台（Codex、Claude Code、Qoder 等）：
# 项目级安装（在目标 workspace 根目录执行，推荐）
npx skills add https://github.com/aliyun/sop-chat --skill generate-sls-skill -a codex claude-code qoder -y
# 全局安装
npx skills add https://github.com/aliyun/sop-chat --skill generate-sls-skill -a codex claude-code qoder -g -y前置依赖包括 Python 3 和 aliyun CLI（>= v3.0.308，用于 SLS 模式）。详细用法请参考 README。
一、知识生成
向 Agent 发出指令：「帮我生成 project k8s-log-c8f3002d205724aa0aa692ab153ac30b8 的 SKILL 文档，需要验证 query」，generate-sls-skill 这个 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 的简化名称和输出路径，并自动匹配到包含现有 SKILL 知识文档的根目录 skills。
Phase B：并行处理
进入 Phase B，为 LogStore 启动并行 Task Agent 进行处理。
容错机制：若某个 Task Agent 因模型限流导致执行失败。得益于步骤级检查点机制，无需从头重跑——只需重新运行 SKILL，系统自动从失败步骤恢复继续执行。
Phase C：全局聚合
LogStore 的 reference 文档全部生成完成，进入 Phase C，生成或更新 project 的 SKILL 入口文档（<root>/<project>/SKILL.md），各 LogStore 的查询知识沉淀为 references/<logstore>.md。
生成的 reference 文档包含结构化的查询模板，可直接用于日志分析。
二、知识使用
生成的 SKILL 知识不绑定到特定集群——它沉淀的是通用的日志查询能力，可被应用到任意同类型的集群。本节通过另一个 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 的场景，展示生成的日志知识如何被使用。
模板匹配
生成的 SKILL 知识文档可直接被 SLS DataAgent 读取并执行。本节展示「用户发出指令 → SLS DataAgent 匹配查询模板 → 执行并返回结果」的直接使用模式。在SLS DataAgent 中新建对话，输入自然语言指令即可完成查询。
场景一：安全审计——保密字典访问记录
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 中 Secret 最近一天的访问记录。
SLS DataAgent 自动匹配 audit reference（SKILL 知识文档）中的相关查询模板，生成并执行审计日志查询，返回所有 Secret 资源的访问记录（包括操作的账号、访问的 Secret、源地址、访问频率等）。
场景二：运维监控——命令执行列表
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 最近一天的命令执行列表。
SLS DataAgent 定位到 k8s-audit reference 中 exec 相关的查询模板，返回集群内所有 kubectl exec 操作记录（包括执行者、目标 Pod、执行命令、时间戳等），便于安全回溯和合规审计。
场景三：异常事件——Pod OOM 事件
用户指令：查看 K8s 集群 ce76790c8d8dc4eed99b2326112f9a29a 最近一天的 Pod OOM 事件。
SLS DataAgent 匹配 k8s-event reference 中的 OOM 事件查询模板，返回因内存不足被终止的 Pod 列表（包括 Pod 名称、命名空间、所在节点、OOM 发生时间等），帮助快速定位内存异常问题。
知识引用
上一节展示的是模板匹配场景——SLS DataAgent 直接匹配已有查询模板，一次执行返回结果。但真实的故障排查往往需要多次查询日志，并根据中间结果选择不同的排查路径。这类场景需要编写独立的排查 SKILL，并引用 Generate SLS SKILL 已生成的日志知识 SKILL——无需了解底层日志结构，只需声明依赖的 SKILL 名称即可获取查询能力。
场景一：故障排查——Pod 驱逐问题
排查 SKILL 编写：排查文档通过引用 Generate SLS SKILL 生成的 SKILL k8s-log 获取查询能力。
---
name: pod-eviction-troubleshooting
description: K8s Pod 驱逐问题排查，根据驱逐类型分支定位根因。
---
## 依赖 SKILL
排查过程中需要引用 SKILL k8s-log 获取查询能力。
## 排查流程
### 步骤 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 chaos-daemon-dp7kv 被驱逐，调查原因。
SLS DataAgent 首先加载 SKILL pod-eviction-troubleshooting，并通过引用 SKILL k8s-log 获取查询 Pod 驱逐事件的方法。并找到 Pod 被调度到了某个节点A上，进一步查询节点A上是否有资源压力事件，继续查询 Pod 完整生命周期，综合分析后得出结论。