红队测试是什么：主动寻找失败边界，不能只收集怪问题
解释针对模型与应用的对抗检查，说明授权范围、失败证据和正常任务回归怎样共同构成有效测试。
先理解这个概念
AI 红队测试是主动设计有挑战的输入和场景，寻找模型或应用的失败与不当行为。它可以关注提示词注入、工具边界或错误信息，不只测答案是否好看。测试需要明确允许范围及判定标准，发现问题后记录可复现条件并修复。通过有限红队样本不代表对所有未知输入安全，也不替代正常任务的质量评测。
测试对象可能包含模型之外的系统
OpenAI 与 Anthropic 都讨论用对抗方式识别模型风险，但实际应用还包含工具权限与资料处理。一个模型拒绝危险请求，不代表程序没有错误暴露内部信息；反过来，权限限制生效也不证明模型每句回答准确。先确定要检查的边界和允许动作，用模拟目标替代真实影响。红队不是未经授权攻击他人系统，不能因为研究安全就随意操作外部账号。分类记录行为和影响，才便于修复，而不是只展示最夸张的一次回答。
无害样本也能检查关键控制
例如在测试资料中加入要求偏离摘要任务的无关标记，检查助手是否仍按原任务处理；写入工具使用模拟返回，核对没有越过允许范围。保存原请求、实际输入与工具结果，能让维护者重现失败。修复后不仅重跑该样本，还应检查正常资料仍可使用，避免通过拒绝一切取得表面成功。本文没有开展攻击或操作外部系统，例子属于验收设计，不提供任何真实目标的漏洞信息，也不声称防护已经通过。
新增工具后需要重新检查影响范围
系统能力变化会引入新失败路径，模型或提示升级后也应重放已有红队案例。记录测试版本与已知限制，不能让一次通过永久代表后续版本。成本包括设计场景、分析失败及修复回归，不只是自动发出大量请求。选择样本应覆盖真实使用边界，优先处理可产生实际错误的情况。最终报告同时说明发现、修复和未覆盖部分，保留可恢复配置，不把没有发现问题写成不存在问题的证明。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。