第 8 章 · 02 技能体系

第 8 章 · 02 技能体系

本节摘要:本节讲透 Strix 的核心机制之一——技能(Skills)。LLM 的安全知识「广而浅」:它知道 SQL 注入的存在,却缺乏老牌渗透测试员手里的解析器怪癖、WAF 绕过、链式攻击等「肌肉记忆」。Skills 就是把这些深度专家知识打包成结构化的 Markdown,在 agent 创建时按上下文动态注入最多 5 个到它的系统 prompt 里,把一个通用 agent 瞬间「特化」成某个漏洞类/框架/工具的专家。本节覆盖:Skills 的设计思想、「最多 5 个」的注入机制、八大分类全景、一个 skill 该长什么样,以及「好的 skill 包含什么」。理解了它,你才算真正理解 Strix 为什么比裸 LLM 强。

内容来源:原项目文档 docs/advanced/skills.mdx 与 strix/skills/README.md,汉化并套用体系化模板。

💡 本节是前面多章提及的「skills」的官方正解。第 5、6 章讲过的各类漏洞,在 Strix 里都对应一个 /vulnerabilities skill。

学习目标

阅读完本节,你应当能够:

1. 说清 **LLM 安全知识「广而浅」**的问题,以及 Skills 如何补上「深」这一维。
2. 描述 agent 创建时**「最多注入 5 个 skill」**的机制:谁选、怎么选、注入到哪。
3. 列举 Skills 的 八大分类,并知道每类的代表 skill。
4. 画出 skill 的标准 Markdown 结构(YAML frontmatter + Attack Surface/Methodology/Techniques/Bypass/Validation)。
5. 判断一个 skill 好不好:四个质量维度。
6. 理解为什么「动态注入 skill」比「把所有知识塞进系统 prompt」更合理。

一、为什么需要 Skills:LLM 知识「广而浅」

通用大模型的安全知识是广而浅的。你问它「什么是 SQL 注入」,它能讲得头头是道;但你让它真正去打一个有 WAF、用了参数化但又拼了一段、数据库是某个冷门版本的目标,它往往只会最基础的 ' OR 1=1--。

真正的渗透测试员手里有一堆**非显然(non-obvious)**的招式:

• 某个数据库版本的解析器怪癖:同样的 payload 换个写法就能绕过过滤
• 一串实际可用的 payload 及其变体:知道哪个在哪种语境下生效
• 各种绕过方法:WAF、输入校验、ORM 转义
• 链式攻击:把一个低危问题串成 RCE
• 版本/环境相关的边界行为:这个框架这个版本才有这个坑

这些知识不在论文里、不在 OWASP 速查表里,而散落在实战经验里。Skills 的使命就是把这些深度、专门化的知识直接塞进 agent 的上下文,让它从一个「通用选手」变成「当前任务的专家」。

⚠️ 别把 Skills 当成「RAG 检索文档」。它们不是「让模型查资料」,而是在 agent 出生那一刻,把专家知识焊进它的系统 prompt,成为它「天生就会」的东西。这决定了 agent 后续每一步推理的起点。

二、核心机制:创建 agent 时注入「最多 5 个」skill

这是 Skills 体系最关键的机制,值得单独讲透。

当 Strix 为某个子任务派生(spawn)一个 agent 时,会根据当前上下文选出最多 5 个与该任务相关的 skill,把它们注入到这个 agent 的系统 prompt 里:

# 为「测试认证机制」派生的 agent 自动加载相关 skills
create_agent(
    task="Test authentication mechanisms",
    skills=["authentication_jwt", "business_logic"]
)
​

注入后,这个 agent 就能访问 skill 提供的三类内容:

• 高级技巧(Advanced techniques)——超出标准测试的非显然方法
• 可用 payload(Working payloads)——带变体的实战例子
• 验证方法(Validation methods)——如何确认发现、避免误报

为什么是「最多 5 个」?

这个数字是上下文预算与专注度之间的权衡:

• 太少(0~1 个):agent 退化成裸 LLM,深度不够。
• 刚好(≤5 个):每个 skill 都精准命中当前任务,深度够,且不会把系统 prompt 撑爆。
• 太多(全塞):系统 prompt 被海量 skill 文本稀释,主任务指令被淹没,agent 容易跑偏,而且每次调用都要为冗余 token 付费。

💡 「选哪些」比「选多少」更重要。Strix 的选择逻辑基于上下文相关性:任务是测 JWT,就选 authentication_jwt;目标是 Supabase 应用,就追加 supabase。这套相关性匹配,正是 agent 编排(第 3 章)的职责之一。你要做的是保证 skill 库里有足够精准的选项可供挑选——这也是为什么后面要讲「好的 skill 包含什么」。

三、八大分类全景

Strix 的 skill 库按用途分成八大类。下面是完整分类表与代表 skill(本教程第 5、6、7 章分别对应其中若干类)。

1. /vulnerabilities —— 漏洞类(核心)

核心漏洞类的深度利用技巧。这是 skill 库的主干,与第 5、6 章一一对应:

2. /frameworks —— 框架类

框架专属的测试模式:

3. /technologies —— 第三方技术类

第三方服务与平台安全:

4. /protocols —— 协议类

协议专属的测试技巧:

5. /reconnaissance —— 侦察类

被动发现与攻击面测绘:

6. /tooling —— 工具类

沙箱 CLI 的核心侦察与扫描工具的操作手册:

7. /cloud —— 云类

云服务商安全测试:覆盖 AWS、GCP、Kubernetes 等(第 7 章已讲)。

8. /custom —— 社区贡献类

社区贡献的、面向专门或行业场景的 skill。这一类是本章第 4 节「自定义 skill」的舞台,也是「从用到造」的桥梁。两个值得注意的源码感知(source-aware)skill:

• source_aware_whitebox(/coordination):白盒编排手册
• source_aware_sast(/custom):semgrep/AST/密钥/供应链静态分诊工作流
• dependency_cve_scanning(/custom):基于 trivy 的 SCA 工作流,用 create_dependency_report 上报已知依赖 CVE

💡 分类是「目录」,不是「隔离」。agent 选 skill 时可以跨类组合:打一个跑在 AWS 上的 Supabase + GraphQL 应用,可能同时注入 supabase+graphql+aws+sql_injection+business_logic——刚好 5 个,精准覆盖。

四、Skill 的标准结构

每个 skill 都是一个带 YAML frontmatter 的 Markdown 文件。frontmatter 提供元数据(name 和 description),正文按固定小节组织:

---
name: skill_name
description: 简要描述这个 skill 的覆盖范围
---

# Skill 标题

关于这个漏洞/技术的关键洞察。

## Attack Surface
本 skill 覆盖什么、在哪里找。

## Methodology
逐步的测试方法。

## Techniques
如何发现并利用这个漏洞。

## Bypass Methods
如何绕过常见防护。

## Validation
如何确认发现、避免误报。
​

⚠️ frontmatter 的 name 必须与文件名一致(或可被加载器映射),description 要写清「这个 skill 管什么场景」,因为它会参与 agent 选 skill 时的相关性匹配。描述写得含糊,skill 就可能在该被选中时没被选中——等于白写。

五、好的 skill 包含什么:四个质量维度

社区贡献 skill 时,文档明确给出「好 skill」的四条标准:

1. 真实可用的技巧(Real-world techniques)——实战中确实有效的方法,不是教科书空谈。
2. 实用的 payload(Practical payloads)——带变体的可用例子,覆盖不同语境。
3. 验证步骤(Validation steps)——如何确认而不产生误报(呼应 Strix「PoC 而非误报」的灵魂)。
4. 上下文感知(Context awareness)——版本/环境相关的行为差异,这种「边界知识」最值钱。

💡 「上下文感知」是最拉开差距的一条。一个写「Pydantic v2 在某版本下会把 X 类型 coerce 成 Y,从而绕过校验」的 skill,价值远高于一个泛泛讲「FastAPI 要测输入校验」的 skill。前者是只有踩过坑才知道的知识,后者 GPT 自己就会说。

六、为什么是「动态注入」而不是「全塞进系统 prompt」

新手常问:既然 skill 是知识,为什么不把所有 skill 一次性塞进 root agent 的系统 prompt,省得每次选?

答案在第三节那张图里——上下文是稀缺资源:

• 成本:系统 prompt 的每个 token 在每次 LLM 调用都要付费。塞 80 个 skill,等于每次调用都为 75 个无关 skill 买单。
• 专注度:prompt 越长,主任务指令的「信号」越容易被淹没,agent 更容易跑偏。
• 准确性:无关知识会干扰判断。一个被注入了 aws skill 的 agent 在测一个纯本地 Node 应用时,可能误把正常行为往云配置错误上靠。

动态注入的精髓是:每个 agent 只带它这次任务真正需要的知识。这既是经济学,也是认知科学——专家之所以是专家,不仅因为他知道得多,更因为他在对的时刻调用对的知识。

本节要点回顾

1. 痛点:LLM 安全知识「广而浅」,缺老牌渗透员的非显然技巧、可用 payload、绕过方法、边界行为。
2. 机制:agent 创建时按上下文注入最多 5 个 skill 到系统 prompt,把通用 agent 特化成专家。
3. 「最多 5 个」是权衡:太少则浅、太多则上下文爆炸且贵——选哪些比选多少更重要。
4. 八大分类:vulnerabilities/frameworks/technologies/protocols/reconnaissance/tooling/cloud/custom,可跨类组合。
5. 标准结构:YAML frontmatter(name+description)+ Attack Surface/Methodology/Techniques/Bypass/Validation 五段正文。
6. 好 skill 四维度:真实技巧、实用 payload、验证步骤、上下文感知——最后一条最拉开差距。
7. 动态注入优于全塞:每个 agent 只带当下所需知识,既省钱又保专注度与准确性。

理解了 skill 的机制与结构,下一节先看一个不用自己搭环境的选项——Strix Cloud;然后再回到本地,在第 4 节亲手写两个自定义 skill,完成「从用到造」的闭环。