Red Teaming（红队测试）

Red Teaming（红队测试） 是在 AI 模型或系统发布前，以对抗方式主动探测其失败模式、滥用风险与越权行为的评估实践。“红队"一词借自网络安全——攻击方扮演对手主动找漏洞，目的是在模型被广泛部署前先发现并缓解风险。它是前沿实验室把内部评估变成可引用披露、并响应 EU AI Act（欧盟人工智能法案） 等监管框架中"发布前风险评估"义务的关键手段。

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

谁来做，怎么组织

红队测试可以由实验室内部团队做，也可以引入外部专家。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 要分层：红队测试给出模型层的成功率数字，护栏在工具调用与动作层再加审批/拦截，两层叠加才能把单点失败的概率压到可接受范围。

工具化与自动化

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