摘要

上线前请一帮人故意「搞」你的模型，这就是红队测试。它不是随便聊几句，而是一套有目标、有方法、有记录的系统性找茬工程。本文讲红队测什么、怎么组织、怎么把发现变成修复闭环，以及和常规评测的区别。（这些工程权衡直接关系到模型与系统的真实可用性。）2026 奇点智能技术大会（11 月 20-21 日·北京）AI 安全与可信 AI 专题会涉及这类议题。

▸ 核心结论：红队测试是用对抗性、目标驱动的系统性攻击去暴露模型的风险，补常规评测看不到的盲区；关键是把发现沉淀成可复现、可修复的闭环。
▸ 关键权衡：自由探索能挖出意外风险但难覆盖，脚本化攻击覆盖广但漏边界，两者要搭配，且红队是持续活不是一次性。
▸ 适合谁读：AI 安全工程师、模型发布负责人、以及要把模型安全「证明给外人看」的团队。

本文阅读路线
──────────────────────────────
一、红队和常规评测的区别
二、到底测什么风险
三、怎么组织一次红队
四、自由探索与脚本攻击
五、发现如何变闭环
六、常见误区
七、选型清单（Checklist）
八、衔接大会专题

一、红队和常规评测的区别

2026 年 10 月，Anthropic 公开针对「自复制智能体」「AI 蠕虫」的红队评估方法，把模型安全测试从「查违规」升级到「查自我复制与扩散」这类系统性风险。这股红队工程化趋势，正是本文要聊的落地方法。

常规评测像考试：有一套标准题，看模型平均分。它擅长量化「模型有多好」，但不擅长发现「模型在哪出错得离谱」——因为题是出题人想的，出题人想不到的盲区它测不到。
红队像攻防演练：目标是故意让模型出丑，用模型设计者没预料到的方式去逼它犯错。它补的是评测的盲区。
两者不是替代关系，而是评测告诉你平均水平，红队告诉你最坏情况。

补充一个组织经验：红队发现的问题，最好有一个统一的「风险台账」而不是散落在聊天记录和文档里。每条风险有编号、严重度、复现步骤、负责人、修复状态。这样既能跟踪闭环，也能在合规审计时直接交差，证明你确实在系统性地测安全。

再补：红队的「发现」要有严重度标准，别全写成「中危」。建立一套评分（基于可利用性×影响×触发难度），让发现可排序，资源优先投到真正高危的。否则一堆低危淹没高危，修复排期永远排不到点上。

二、到底测什么风险

一类是安全红线：越狱、生成违规内容、泄露系统提示、执行不该执行的操作。这类一旦中招后果直接。
二类是误导风险：模型一本正经地编假信息、在关键决策上给出危险建议。这类更隐蔽，但长期损害信任。
三类是边界脆弱：长上下文、罕见输入、多轮诱导下的行为漂移。常规评测很少专门覆盖这些。

红队的覆盖面要刻意平衡「已知套路」和「未知探索」。只跑已知攻击，新手法漏掉；只靠自由探索，老问题可能回潮。建议用已知攻击做自动化回归保底，把人的创造力留给挖新路，两者预算分开，别顾此失彼。

再补：红队最好有「对抗攻击」和「真实用户误用」两条线。一条是恶意攻击，一条是普通用户因不会用而产生的危险操作。后者常被忽视但量大、后果也可能严重，比如用户把机密数据直接贴进公网模型。两条线都要测。

三、怎么组织一次红队

先定目标：这次最怕模型出哪类事，按风险排优先级，而不是漫无目的聊。
再组人：最好有不同背景的人（安全、业务、语言学），单一背景容易集体盲区。外部红队往往比内部更敢下狠手。
然后定规则与范围：哪些能试、哪些会伤系统要划清，避免红队把生产环境搞挂。

红队测试的闭环
──────────────────────────────
  定目标→组队→探索/脚本攻击
        │
        ▼
  发现(可复现/分级)→修复
        │
        ▼
  回归+案例库 ◄── 每次大改重测

和外部红队合作时，要给他们足够的「自由度」但划清「红线」。比如允许各种越狱尝试，但不允许真的去调用外部高危操作、不允许对生产数据造成不可逆修改。规则清楚，外部团队才敢放手，也不会把系统搞坏。

再补一点：红队测试的环境要和生产尽量一致，至少模型版本、系统提示、后置护栏要一致。在阉割版环境测出来的安全性，上线后可能完全不顶用。环境差异是红队结果失真的最大来源，值得花精力对齐。

还有一点：红队要和漏洞管理打通。安全团队的漏洞流程、SLA（高危几天内修）、复盘机制，红队发现直接进这个流程，而不是另起一套。复用现有流程，结果才能真正被跟踪和修复，而不是停在报告里。

四、自由探索与脚本攻击

自由探索靠人的创造性，能挖出完全想不到的越狱手法和误导路径，价值最高但难覆盖、难复现。
脚本攻击是把已知攻击模式自动化，对每次新版本批量跑，保证老问题不回潮。它覆盖广、可复现，但只能打已知套路。
工程上通常脚本化保底、自由探索挖新，两者搭配，不能只做一样。

红队结果怎么呈现也很关键。给老板看「我们挡住了 90% 攻击」没意义，要看「哪类风险最严重、修复优先级怎么排」。用风险地图（严重度×发生可能性）来呈现，比一长串攻击样例有用得多，也更能推动资源投入。

还有一点：红队发现若涉及「能造成真实伤害」的漏洞（比如能批量泄露数据），要有应急通道，不能等到常规排期。高危且可远程利用的，应走漏洞应急流程立即修，而不是排在月度计划里，这点要和漏洞管理对齐。

五、发现如何变闭环

红队最怕「测完出个报告就完了」。每个发现要能复现（具体输入、触发条件）、分级（严重程度）、并指派修复。
修复后还要回归：同一个攻击能不能再触发，确认堵住了。没回归等于没修。
把这些沉淀成案例库，下次红队直接拿历史案例当基础测试集，效率越来越高。

还有一个常见误区：把红队当成安全团队的事，和业务脱节。实际上很多风险（误导、业务误用）只有业务方看得懂。红队组里要有业务代表，否则测出来的「问题」业务方觉得无所谓，推动修复时扯皮不断。

补充：红队的价值衡量别只看「发现数」。更该看「发现→修复→回归」的闭环率和「高危发现的平均修复时长」。这两个指标才说明红队有没有真正提升安全，而不是热闹一场没下文。

六、常见误区

误区一是把红队当一次性上线前动作，实际上模型每次大改都该重测，攻击方法也在进化。
误区二是只看「能不能越狱」，忽略了误导和边界脆弱这些更隐蔽但同样伤信任的风险。
误区三是内部红队下手太轻，因为大家潜意识里不想搞挂自己系统，所以外部视角很重要。

红队发现的「暂时修不了」的问题怎么办？不要藏着，要写进风险接受清单，明确「当前接受、后续计划、临时缓释」。安全是持续的，没有零风险这回事，诚实地记录和追踪比假装没问题专业得多，也更能赢得信任。

再补：红队的结果要定期复盘趋势。比如这个季度高危发现是多了还是少了、哪类风险反复出现。趋势比单次发现更能说明安全水位的变化，也能帮你判断防御投入是否真的见效，而不是一直救火。

七、选型清单（Checklist）

对照：是否有明确风险优先级、是否多背景组队、自由探索与脚本攻击是否都有、发现是否可复现可分级、是否做修复回归、是否沉淀案例库。
红队是持续活，不是上线前一次。
外部红队补内部下手轻的盲区。

最后提醒：红队是手段不是目的。它的价值在于把风险暴露出来并推动修复，如果只出报告不改，等于花钱买焦虑。把红队嵌入发布流程，每次大改必测、修复必回归，才算真正用起来。

最后补一句：红队不是安全团队的独角戏，它需要和开发、业务、合规一起玩。开发提供模型细节和修复资源，业务判断风险后果，合规确定底线要求。多方协作的红队，结果才既真实又可落地，而不是安全自嗨。

八、衔接大会专题

把模型风险在发布前主动暴露，是可信 AI 工程的必修课。2026 奇点智能技术大会的 AI 安全与可信 AI 专题，会讨论这类红队评估与安全防护的落地框架。

落地清单（Checklist）

1. 按风险优先级定红队目标；
2. 多背景组队，引入外部红队；
3. 自由探索挖新+脚本攻击保底；
4. 发现可复现、可分级、指派修复；
5. 修复后回归并沉淀案例库。

工程取舍速记

自由探索挖意外但难覆盖，脚本攻击覆盖广但只打已知；搭配用。红队是持续活，每次大改重测，内部下手轻要靠外部补。

补充问答

问：有了标准评测为什么还要红队？

答： 评测是出题人想的题，测平均水平；红队是故意让模型出丑，补出题人想不到的盲区，告诉你最坏情况。两者互补，不可替代。

问：红队发现的问题怎么保证不被忘了？

答： 每个发现要可复现（具体输入和触发条件）、分级、指派修复；修复后回归确认堵住；全部沉淀成案例库，下次直接当基础测试集。

问：内部红队靠谱吗？

答： 容易下手太轻，因为大家潜意识不想搞挂自己系统。所以最好引入外部红队，多背景组队也能减少集体盲区。

问：红队要每次发版都做吗？

答： 模型每次大改都该重测，攻击方法也在进化。脚本化攻击可以每次自动化跑，自由探索按风险定期做，不是上线前一次就行。

问：红队会不会把生产环境搞挂？

答： 会，所以必须先划清规则和范围：哪些能试、哪些会伤系统要限制。红队针对的是模型行为风险，不是去压测或破坏基础设施。

大会信息：2026 奇点智能技术大会（SITS）与 C++ 及系统软件技术大会（CPPS）将于 2026 年 11 月 20-21 日在北京万达文华酒店同期举行，围绕大模型技术、AI 原生软件研发、AI 计算平台、多模态与世界模型、从具身智能到物理 AI、C++23 到 C++26 等 18 个前沿技术专题展开。