从漏洞思维到 Agent Skill：如何把安全方法论交给大模型

从漏洞思维到 Agent Skill：如何把安全方法论交给大模型

前言：我开始思考一个新的问题

前面我一直在研究一件事：

漏洞到底是怎么被想到的？

我花了很多时间去理解：

业务规则
↓
业务不变量
↓
程序判断条件
↓
允许世界
↓
禁止世界
↓
漏洞假设
↓
Expected
↓
Observed
↓
Evidence

慢慢地，我开始不再把漏洞理解成：

参数能不能改
Payload能不能打进去
某个工具能不能跑出来结果

而是理解成：

服务器本来想维持什么业务规则，而程序在哪一个判断条件、关系、状态、信任来源或执行路径上失去了这个保证。

但当我开始开发 PI Agent 的安全扩展以后，又出现了一个新的问题：

既然这些方法已经逐渐形成了一套稳定的漏洞思维，那能不能把它交给 Agent？

最开始，我想到的是：

做一个安全推理 Extension

后来我才发现，这里面其实涉及三个完全不同的东西：

Skill
Extension
LLM

而如果这三个边界没有想清楚，很容易把一个本来应该“增强模型推理”的系统，做成一个限制模型能力的规则引擎。

于是我开始重新思考：

到底什么内容应该成为 Skill？什么内容应该写进 Extension？什么事情应该继续交给大模型自己判断？

---

一、Skill 到底是什么

我现在更愿意把 Skill 理解成：

一套可以反复复用、按需加载的领域工作方法。

它不是新的模型。

也不是一个新的推理引擎。

更不是一个固定脚本。

它更像是：

当 Agent 进入某类任务时
临时获得的一份专业工作手册

例如一个通用 Agent 平时可能需要处理：

代码
PDF
部署
安全分析
日志
数据库

如果把所有专业规则都永久塞进 System Prompt：

PDF应该这样做……
SQL应该这样分析……
安全测试应该这样做……
部署应该这样做……

那么随着能力越来越多：

System Prompt
↓
越来越大
↓
大量内容和当前任务无关
↓
上下文被污染
↓
模型注意力被分散

Skill 的价值就在于：

平时只知道：
“存在这个能力”

真正遇到对应任务时：
再加载完整方法

所以 Skill 的核心不是：

给模型更多文字

而是：

让领域知识在需要的时候出现。

---

二、什么内容最适合做成 Skill

经过今天的讨论，我觉得可以用一个很简单的标准判断。

如果一段内容满足：

以后会经常重复使用

每次遇到类似任务时
都希望模型按照类似的方法思考

主要依赖语义理解
而不是固定程序逻辑

不需要保存某个具体项目的长期状态

那么它通常很适合做成 Skill。

例如我的《漏洞思维》。

它反复强调：

不要看到参数就直接判断漏洞

先理解业务动作

识别：
Actor
Action
Object
Relation
State
Fact

再建立：
Business Invariant

然后：
构造禁止世界

形成：
Hypothesis

最后：
Expected
Observed
Evidence
Conclusion

这本质上就是：

一种可迁移的分析方法。

非常适合 Skill。

---

三、方法论 Skill 和技术 Skill 并不冲突

做渗透时，我看到了很多：

SQL Injection Skill
File Upload Skill
XSS Skill
SSRF Skill

一开始我会觉得：

这些是不是太偏技术了？

后来我发现，问题其实不在于：

SQLi 能不能做成 Skill

而在于：

这个 Skill 到底在教模型什么。

例如一个比较差的 SQLi Skill 可能是：

发现 id 参数
↓
加 '
↓
试 OR 1=1
↓
试 UNION SELECT
↓
调用 sqlmap

这种 Skill 本质上是：

固定攻击剧本

模型只是在执行：

parameter
→ payload

而一个更合理的 SQLi Skill 应该告诉模型：

先判断输入在业务里是什么

这个输入是否可能进入数据库查询结构？

它可能处于：
值位置
排序位置
搜索条件
标识符
分页参数
还是其他位置？

当前响应变化
能不能被数据库行为解释？

下一步验证
应该证明什么？

这样：

SQLi Skill

仍然是方法论。

只是它的作用范围从：

通用漏洞思维

缩小到了：

数据库查询语境

---

四、Upload Skill 也应该如此

同样地，一个低质量 Upload Skill 可能只是：

改后缀
改 MIME
双后缀
大小写
特殊扩展名

这种设计很容易让 Agent 退化成 Checklist Runner。

但如果真正从漏洞思维出发，Upload Skill 应该建立：

Client File
↓
Upload Handler
↓
Validation
↓
Transform / Rename
↓
Storage
↓
Retrieval
↓
Interpretation

然后问：

服务器到底检查了什么？

文件名？
扩展名？
MIME？
Magic Bytes？
内容？

上传后发生了什么？

文件被放在哪里？
文件名有没有改变？
谁可以访问？
返回时由什么组件处理？
最终被当作什么内容解释？

这种 Skill 仍然保留了：

模型的语义推理能力

而不是写死：

看到文件上传
→ 固定尝试某几个 Payload

所以我逐渐形成了一个观点：

好的技术 Skill，不应该告诉模型“固定怎么打”，而应该告诉模型“什么证据会让我想到这个方向，以及下一步到底需要证明什么”。

---

五、为什么固定参数可能限制大模型

这是我今天特别在意的一点。

例如我们可以很容易写：

看到 user_id
→ Authorization

看到 price
→ Trust

看到 status
→ State Machine

看起来很聪明。

但实际上问题很大。

因为：

user_id

可能表示：

当前身份
目标用户
创建人
负责人
过滤条件
租户范围

而：

price

也可能只是：

price_min
price_max

用于搜索。

所以：

参数名
≠
业务含义

如果 Skill 写成：

字段名 → 漏洞类型

实际上是在削弱 LLM。

因为 LLM 真正擅长的是：

参数
+
接口动作
+
页面上下文
+
请求响应
+
业务关系
↓
判断这个字段在当前业务中到底代表什么

所以 Skill 应该固定：

思考原则
判断问题
输出结构
证据纪律

而不是固定：

参数值
Payload
结论

---

六、漏洞思维为什么特别适合 Skill

我的漏洞思维其实从一开始就不是漏洞字典。

它真正训练的是：

为什么想到这里？

例如：

user_id=1

我不应该马上想到：

越权

而应该先问：

这个接口是什么业务动作？

当前主体是谁？

user_id 在这里到底是什么？

Target？
Identity？
Owner？
Filter？
Scope？

当前主体和这个目标之间
应该满足什么关系？

然后才形成：

Authorization Hypothesis

同样：

price=1

也不能直接等于：

价格篡改

而应该先问：

price 在这里代表什么？

这是用户意图？
还是业务事实？

谁真正有资格决定这个事实？

服务器是否重新从权威来源确认？

这就是：

Trust Reasoning

所以我的《漏洞思维》真正适合交给 Skill 的，不是：

14篇文章全文

而是其中反复出现的：

思维框架
判断原则
触发问题
证据纪律

---

七、那 Extension 又是做什么的

如果 Skill 是：

怎么想

那么 Extension 更像：

怎么把已经想出来的东西
稳定保存、管理和推进

例如 Agent 分析一个目标后生成：

H-001

Hypothesis:
当前用户可能访问未授权订单

Invariant:
订单必须处于当前主体授权范围

Expected:
未授权目标应 Deny

如果只有 Skill，这些主要存在于：

当前上下文

任务短的时候没问题。

但如果持续分析：

几十个接口
多个对象
多个 Hypothesis
大量 Response
多个 Evidence

模型可能开始：

忘记H-001

重复生成H-001

忘记原来的Expected

把Hypothesis直接说成Conclusion

搞混哪个Evidence支持哪个Hypothesis

这已经不是：

不会思考

而是：

状态管理问题

这种问题应该交给 Extension。

---

八、Skill 和 Extension 的关系

我现在觉得可以用一句非常简单的话记住：

Skill
= Method

Extension
= Mechanism

Store
= State

也就是：

Skill
告诉模型：
应该怎么分析

LLM
根据当前上下文：
完成语义判断

Extension
负责：
保存、约束、执行

Store
记录：
当前已经知道什么

例如：

Skill
↓
生成 H-001

Extension
↓
保存 H-001

Skill
↓
告诉模型怎么验证 H-001

Extension
↓
记录 Validation Plan

Tool
↓
执行

Extension
↓
记录 Evidence

LLM + Skill
↓
重新解释 Evidence

Extension
↓
更新 H-001 状态

整个过程就是：

Think
↓
Store
↓
Act
↓
Record
↓
Think Again

---

九、为什么不能什么都做成 Extension

Extension 很强，但它不应该承担所有推理。

例如如果写成：

if (field.name === "user_id") {
    addLens("authorization");
}

if (field.name === "price") {
    addLens("trust");
}

系统很快会退化成：

字段匹配
↓
规则匹配
↓
漏洞类型匹配

这其实违背了漏洞思维。

因为真正重要的是：

这个变量
在当前业务决策中
承担什么角色

这是语义问题。

语义问题应该交给：

LLM + Skill

而 Extension 更适合那些：

必须精确
必须长期保存
必须强制执行

的内容。

例如：

ScopeGuard
Approval
Evidence Schema
Hypothesis State
ToolExecutor
Trace

这些不能靠一句 Prompt：

“请记得不要越界”

来保证。

---

十、我现在理解的最佳结构

对于 PI Security，我现在更倾向于：

                 PI / LLM
                    │
                    ▼
              Security Skills
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
漏洞思维       SQLi Reasoning   Upload Reasoning
       │            │            │
       └────────────┼────────────┘
                    ▼
             Candidate Hypothesis
                    │
                    ▼
            pi-security Extension
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
 BusinessModel   Hypothesis     Evidence
     Store          Store         Store
                    │
                    ▼
               ScopeGuard
                    │
                 Approval
                    │
               ToolExecutor

这个结构里：

大模型
负责聪明

Skill
负责方法

Extension
负责稳定

Tool
负责执行

这样每一层职责都比较清楚。

---

十一、我的漏洞思维应该拆成多少个 Skill

现阶段我并不打算直接把：

14篇文章

拆成：

14个Skill

这样粒度太碎。

第一阶段更适合只有：

vulnerability-reasoning/
└── SKILL.md

把核心方法蒸馏进去。

先验证它能不能稳定帮助 PI 完成：

Business Action
↓
Actor
↓
Target
↓
Intent
↓
Business Fact
↓
Relation
↓
Invariant
↓
Hypothesis
↓
Expected
↓
Evidence Discipline

等真正打了一批靶场以后，再根据实际使用情况拆分。

最终可能形成：

security-reasoning

business-modeling

authorization-reasoning

state-machine-reasoning

trust-boundary-reasoning

也就是说：

先让方法跑起来，再根据真实复杂度拆模块。

而不是因为理论上有14篇文章，就提前做14个 Skill。

---

十二、什么时候应该从 Skill 升级成 Extension

这是今天我觉得最值得记住的判断方式。

如果问题是：

模型不知道怎么想

优先考虑：

Skill

如果问题是：

模型知道怎么想
但经常忘记之前想过什么

优先考虑：

Extension / Store

如果问题是：

某个安全规则绝对不能违反

例如：

未授权目标绝不能请求

那就应该：

Extension

而不是 Skill。

所以：

不知道怎么思考
→ Skill

知道怎么思考但记不住
→ Store

必须强制执行
→ Extension

这个判断对我以后设计 PI 非常重要。

---

十三、真正值得做成 Skill 的不是“知识”，而是“工作方式”

我现在越来越觉得：

SQL注入是什么
XSS是什么
CSRF是什么

这种百科知识不是 Skill 最有价值的部分。

真正应该 Skill 化的是：

遇到这种问题时
我要怎么看？

哪些证据重要？

什么只是推测？

下一步应该证明什么？

什么结论现在还不能下？

这也是为什么我的漏洞思维比单纯的 Payload 列表更适合 Skill。

因为它最终关注的是：

Observation
↓
Inference
↓
Hypothesis
↓
Validation
↓
Evidence
↓
Conclusion

而不是：

漏洞类型
↓
Payload

---

十四、我现在对 Skill 的最终理解

如果一定要用一句话总结：

Skill 不是给大模型写一个固定脚本，而是给大模型安装一套领域思维习惯。

它应该告诉 Agent：

进入这个领域以后：

先看什么
为什么看
怎么判断
哪些错误不能犯
什么证据才足够
输出应该怎么组织

但具体：

这个 user_id 到底是什么
这个 price 到底是什么
这个状态到底允不允许

仍然应该让模型根据真实上下文判断。

这样才能真正发挥大模型的价值。

---

结语：不是把人的思维写死，而是把人的方法留下

最开始我考虑的是：

能不能把漏洞思维写进 Agent

现在我觉得这个问题应该换一种说法：

能不能让 Agent 拥有一套稳定的漏洞分析习惯，同时又不限制它对新业务、新接口、新语义的理解能力？

答案不是：

把所有规则写成代码

也不是：

把14篇文章全部塞进Prompt

而应该是：

方法论
→ Skill

语义理解
→ LLM

状态与证据
→ Extension / Store

执行与安全边界
→ Extension / Tool

真正好的安全 Agent，不应该只是：

更会打 Payload

而应该越来越接近：

看到业务
↓
建立模型
↓
理解变量
↓
找到不变量
↓
产生假设
↓
用证据验证
↓
根据结果更新认识

如果以后我的 pi-security 能做到这一点，那么它真正增加的就不是：

更多工具

而是：

一套能够被长期复用的安全研究方法。