Red Teaming（红队测试）

Red Teaming（红队测试） 在本库默认指：在 AI 模型或系统发布前，以对抗方式主动探测其失败模式、滥用风险与越权行为的评估实践。“红队"一词借自网络安全——攻击方扮演对手主动找漏洞，目的是在模型被广泛部署前先发现并缓解风险。它是前沿实验室把内部评估变成可引用披露、并响应 EU AI Act（欧盟人工智能法案） 等监管框架中"发布前风险评估"义务的关键手段。红队测试的结果也常被用来支撑像 Preparedness Framework（预备框架） 这类逐等级能力判定中的证据，但它测的是"找出缺口”，等级判定与部署防护则由框架与护栏分别承担。

红队测试与普通评估的区别在于意图：普通 eval 量测模型在既定任务上的表现，红队测试主动构造对抗输入，去触发"合理用户不会预期且会强烈反对"的输出或动作——prompt injection、jailbreak、数据泄露、绕过业务规则、越权操作等。

注意同一词在 网络安全交付 里仍保留原义：对目标系统做授权攻防演练（渗透测试 / 红队）。Daybreak Red 与 Cyber Partner Program 所说的 red teaming / pen testing 属于后者——用专用模型帮防御方测客户系统，不是测模型本身。两条线共用"红队"一词，但对象、证据与治理完全不同。

谁来做，怎么组织

红队测试可以由实验室内部团队做，也可以引入外部专家。OpenAI 维护一个 Red Teaming Network，把外部专家纳入模型测试流程，让发现的风险不被单一组织视角局限。生态层面，前沿模型论坛（Frontier Model Forum）、与美国 CAISI 和英国 AISI 的合作、以及第三方评估实践，都在推动共享安全研究与更统一的评估标准。红队测试结果通常汇总进随发布公开的 系统卡（System Card），成为模型发布决策依据的一部分。

红队测试能测什么，不能保证什么

红队测试的有效性有两个硬约束：

1. 它发现的是"已知未知"：只能测出红队成员能想到、能构造的攻击路径，对真正的未知失败模式没有覆盖保证。
2. 指标是概率不是零风险：成功率低不等于没有风险。例如 Anthropic 报告的模型层指标中，Claude Opus 4.7 在 Gray Swan Agent Red Teaming benchmark 的单次 prompt injection 攻击成功率约 0.1%，100 次自适应尝试后仍约 5–6%；Claude Code Auto Mode 可在执行前拦住约 83% 的 overeager behaviors。这样的结果很强，但不是零风险，所以红队测试只能作为 defense-in-depth 的一层，而非安全保证。详见 Agent Guardrails（Agent 护栏）。

这也解释了为什么 Agent Guardrails 要分层：红队测试给出模型层的成功率数字，护栏在工具调用与动作层再加审批/拦截，两层叠加才能把单点失败的概率压到可接受范围。

当红队测试本身是高能力的网络能力评测（如由国家 AI 安全研究所或外部安全公司在自建靶场里测评 Agent 的攻防能力）时，参与方还必须把评测环境当作与 Agent 对抗的硬边界——因为被测 Agent 越强，越可能把动作延伸到评测边界之外（例如使用遗留凭据、公共隧道或配置错误实现的公网访问触及真实系统）。这既是对模型的红队，也是在对评测环境做红队；详见 第三方评测（Third-Party Evaluation）。

工具化与自动化

红队测试已从人工构造攻击逐步走向工具化。promptfoo 等工具提供自动化红队扫描，覆盖 prompt injection、jailbreak、数据泄露、业务规则绕过等 50+ 漏洞类型，把"红队想到的攻击模式"沉淀成可复跑的测试集。自动化的价值是规模与可重复，代价仍是只能覆盖已知模式——真正的安全边界仍需结合人工红队、运行时护栏与事件响应来共同构成。

相关词条

• Agent Guardrails（Agent 护栏） — 红队发现后的运行时分层防护
• Daybreak — 网络安全交付语境下的授权红队 / 渗透测试通道
• Preparedness Framework（预备框架） — 红队与其它证据如何支撑能力分级
• Third-Party Evaluation（第三方评测） — 外部靶场评测中的红队与环境边界
• System Card（系统卡） — 红队结果的常见披露载体
• Eval — 与对抗探测相对的常规评估