第49篇全栈 AI 用LLM打LLM

现在做 AI 安全，最容易被低估的不是某个 prompt 技巧，而是体系变化：当攻击、检测、评审、修复都开始由模型参与时，安全就不再是“人手工盯着系统”，而是“模型之间互相制衡”。这就是今天的 AI 安全新战场，也是 AI 攻防的 AI、用 LLM 打 LLM 真正成立的地方。

基于当前可见信息来看，这一轮变化不是“再多一个工具”，而是控制面迁移：以前靠安全工程师写规则、做抽检、人工复核；现在要同时管理攻击生成、在线拦截、离线评估、策略更新四条链路。谁只盯住一个环节，谁就会在别的环节被绕过去。

一、为什么“用LLM打LLM”会成为主线

先把概念说透：这里的“用 LLM 打 LLM”，不是指某种神秘的新攻击手法，而是指 AI 全栈里开始出现一整套模型对模型的安全协作。

典型链路大概是这样：

攻击侧：LLM 帮助生成测试样本、变体、组合式提问，提升覆盖率
防守侧：LLM 或小模型做输入输出过滤、策略判定、内容分级
评估侧：LLM-as-Judge 负责批量判定模型输出是否越界、是否泄露、是否符合策略
编排侧：系统根据判定结果决定拒绝、改写、降级、转人工

这意味着一个现实变化：安全不再只是“挡住一个坏请求”，而是“让整个系统持续做出正确决策”。

如果只用人工审核，成本会爆；如果只靠规则，覆盖会塌；如果只上一个 Guardrail，不管评审和治理，系统会越来越脆；如果只做离线测评，不接在线闭环，发现问题也修不动。

所以，AI 安全新战场的核心，不是单点模型，而是一个可治理的对抗体系。

二、这场对抗里的四个角色

要理解 AI 攻防的 AI，先别急着看具体模型名，先看角色。

1）攻击生成者：把“试一试”变成“规模化试验”

在合规场景里，攻击生成者更准确地说是“红队样本生成器”。它的价值不是教人绕过什么，而是让安全团队能系统地构造测试集：

多轮对话样本
上下文污染样本
角色混淆样本
业务边界样本
输出泄露样本

如果没有这一层，安全测试很容易停留在“人工想到什么测什么”。问题在于，人脑会天然偏好熟悉路径，而模型能把边界条件展开得更宽。

2）守门人：把风险挡在系统外

守门人就是 Guardrail。它的任务不是“理解世界”，而是“在策略边界上做快速判断”。

它通常做三件事：

识别输入是否可疑
判断输出是否越界
对高风险请求做阻断、降级、转人工

守门人的关键价值在于：它把安全前移了。很多事故不是模型“想坏”，而是系统没拦住坏输入、没拦住坏上下文、没拦住坏输出。

但守门人也不是万能的。它擅长已知模式，不擅长未知组合；擅长分类，不擅长推理；擅长快速拦截，不擅长最终裁决。

3）裁判：把“好不好”变成可批量评估

LLM-as-Judge 的意义非常大。它解决的是一个长期痛点：安全评估不能只靠人工，不然速度、成本和一致性都不够。

裁判型模型适合做这些事：

判定输出是否符合安全策略
给出违规类型
评估改写前后是否更安全
对多轮对话做整体合规判断

它的价值不在于“绝对正确”，而在于“可以规模化”。但前提是：你得承认它是一个带偏差的裁判，而不是事实真理。

4）调度器：把判定结果接回业务流

很多团队只看到了前面三层，忽略了最后一层：调度器。

调度器负责把“模型判断”变成“系统动作”：

放行
拒绝
改写
补充提示
触发复审
记录审计日志
提交安全工单

没有调度器，LLM 打 LLM 只停留在实验室。有了调度器，才进入真正的 AI 全栈治理。

三、AI全栈里，安全不是一层，而是四层控制面

如果把这个体系拆成控制面，可以理解为四层：

输入控制：用户进来之前先看一眼
生成控制：模型生成时看策略是否越界
输出控制：结果出去之前再看一眼
反馈控制：把线上问题回流到评估与训练

这四层缺一层，系统就会有盲区。

只有输入控制，没有输出控制：模型可能在安全输入下生成危险结果
只有输出控制，没有输入控制：恶意上下文会在内部慢慢发酵
只有离线反馈，没有在线控制：问题会被发现，但来不及止损
只有控制，没有回流：策略会越来越旧，最后被真实业务甩开

这也是为什么 AI 安全新战场不是“加一个过滤器”就能解决，而是要重建控制闭环。

四、哪些模块是必须的，哪些短板最常见

下面这个表，适合拿去做团队评审时对照：

层次/模块	作用	常见短板	改进方向
输入检测	识别高风险提问、上下文污染、越界意图	只看单轮，不看多轮上下文	引入会话级策略与历史窗口
Guardrail
在线拦截明显违规内容	误杀高、漏报多、延迟高	分级策略、灰度放行、轻重分流
LLM-as-Judge
批量评估输出是否合规	偏差大、标准不一、可被提示影响	多裁判投票、统一 rubric、抽样人工复核
风险调度
决定放行、拒绝、降级、转人工	规则割裂，动作与策略不一致	建立策略引擎和响应矩阵
审计与回流
记录问题、反哺策略与训练	只有日志，没有闭环	把失败样本纳入红队与回归集
策略治理
定义边界、责任、例外处理	业务口径不一致	建立统一安全分级与审批机制

这个表里最值得注意的一点是：真正薄弱的往往不是模型，而是“模型到业务动作之间”的衔接。

很多事故不是因为“没检测到”，而是因为“检测到了但没接住”。

五、为什么这些层次缺一不可

1）没有在线守门，安全就靠运气

只做离线测试，等于你在事故发生后才知道系统有问题。尤其在高频交互场景里，单次失误不是个案，而是会被持续放大。

2）没有裁判，安全就没有尺度

如果每个安全工程师各自判断，结果往往是：

标准不一致
误报解释不统一
评估结论不可复现

LLM-as-Judge 的意义就在于把尺度拉齐。哪怕它不是完美裁判，也比“每个人凭感觉”更适合规模化治理。

3）没有反馈，防御会过时

安全策略一旦上线，很快就会遇到新型输入、新业务场景、新组合方式。如果没有回流机制，Guardrail 会慢慢变成“历史规则集”，看起来很严，实际已经落后。

4）没有分层，团队会把所有问题都扔给模型

这是大坑。模型不是安全架构本身，它只是控制链路中的一个部件。把所有责任压给模型，最后只会得到两个结果：误杀业务，或者被业务绕过。

六、落地时最容易犯的误区

误区一：把 Guardrail 当成最终答案

Guardrail 只能做快速筛查，不能承担全部裁决。一旦把它当作“绝对真理”，误杀和漏报都会很难处理。

正确做法是分级：

低风险：快速放行
中风险：改写后放行
高风险：拒绝或转人工
特殊风险：进入审计队列

误区二：把 LLM-as-Judge 当成客观标准

裁判模型也会受提示、位置、上下文和训练偏差影响。所以它适合做“批量判定”和“趋势分析”，不适合做唯一裁决。

正确做法是：

用统一 rubric
用多个 Judge 交叉验证
对边界样本保留人工复核
把争议样本纳入回归集

误区三：只建防线，不建回路

没有回流，意味着每次修补都是临时补丁。安全团队需要的是一条闭环：发现问题、归档样本、更新策略、回归验证、上线观察。

误区四：只看模型，不看系统

AI 全栈里的风险，常常出现在模型之外：

调用链拼接
工具权限
记忆缓存
上下文注入
多 Agent 协作边界

所以“用 LLM 打 LLM”从来不是孤立的模型问题，而是系统级问题。

七、团队该怎么建这套能力

如果你要把这件事做成工程能力，而不是一次演示，建议按三步走。

第一步：先定义安全边界

先回答三个问题：

哪些内容绝对不能出
哪些内容允许改写后出
哪些场景必须转人工

没有边界，模型就没有执行依据。

第二步：建立样本体系

至少要有三类样本集：

正常业务样本
已知风险样本
回归测试样本

其中最重要的是回归集。因为安全能力真正的价值，不是“今天测出来了”，而是“下次不再犯”。

第三步：把模型接进治理链路

把 Guardrail、Judge、审计、工单、版本管理串起来。只要链路断在任何一处，安全能力就会变成孤岛。

八、结论：用LLM打LLM，真正考验的是体系设计

AI 攻防的 AI，不是“谁更会写 prompt”，而是“谁更懂控制面”。

在 AI 安全新战场里，LLM 的价值有三种：

做攻击生成器，提升测试覆盖
做守门人，提升在线防护
做裁判，提升离线评估

但真正决定上限的，是你有没有把这三者接成一个闭环。这也是 AI 全栈视角下最重要的变化：安全不再是附属功能，而是系统设计的一部分。

如果你只记住一句话，那就记住这一句： 用 LLM 打 LLM，不是让模型替人做判断，而是让模型参与构建一套可持续运转的安全治理系统。

给读者的实践建议

如果你所在团队已经在做 LLM 应用，下一步不要急着“再上一个模型”，先做这三件事：

画出你们当前的输入、输出、评估、审计链路，找出断点
选一批真实业务样本，建立可回归的安全测试集
给 Guardrail 和 Judge 定义清晰职责，避免一个模型背所有锅

真正成熟的 AI 安全，不是更复杂的口号，而是更清楚的分工、更稳定的闭环、和更可复现的治理。