LLM red teaming 实战：AI 应用上线前的红队测试指南

面向客户的智能体上线前，应该先做一轮 LLM red teaming（AI 红队测试），确认攻击者能否诱使它泄露隐私数据、执行未授权操作，或生成违规内容。首轮可以按 6 步推进：划定范围、列出攻击目标、执行测试、判定结果、修复问题、重新测试。真正有用的产出，是能追溯的问题记录和经过验证的修复，而不是一枚让人安心的认证徽章。

文中工具能力和框架说明已于 2026 年 10 月 17 日依据官方文档核实。下文的工作流程和客服智能体案例均为建议的测试练习，并非产品实测结果。

什么是 LLM red teaming（AI 红队测试）？

AI 红队测试会主动尝试让 AI 系统违反预先定义的安全规范或业务规则。测试者以触发失效为目标，观察系统行为，再将发现的问题转化为可以复测验证的修复。对准备上线聊天机器人的企业来说，测试对象通常是完整应用：它的指令、检索到的信息、权限、工具，以及客户最终看到的回复。参见模型与应用面临的威胁。

可以把它想象成酒店前台。常规服务测试会检查客人能否拿到自己房间的钥匙；对抗测试则会问：一份看似可信的伪造维修通知，能不能骗前台交出别人的钥匙？无论前台回答得多有礼貌，都得查清究竟交出了哪把钥匙，这才是有用的证据。

智能体也有类似的边界。客服工单是需要处理的信息，不应因此获得主管审批的效力；检索到的文档可以辅助回答问题，却不应授予访问其他客户记录的权限。

大模型红队测试与应用测试，有什么区别？

模型红队测试关注模型面对对抗性输入时的行为。应用测试还要覆盖外围系统，因为客户身份、文档访问控制和工具权限共同决定了系统能做什么。模型供应商的安全报告，无法证明你的退款集成会核验正确的账户。promptfoo 红队测试文档明确区分了这两类测试。

对大多数企业来说，应该先从实际部署的应用边界入手。选型或更换模型时，模型层面的测试仍有价值，但客户使用的是整个产品。

常规 QA 容易漏掉什么？

AI 红队测试寻找的是突破预期边界的方法，其中也包括利用歧义、表面上完全合理的请求，而非只有格式异常的输入。常规质量保证（QA）主要验证规定的行为：答案是否正确、交易是否有效、响应时间是否达标、错误处理是否符合预期。成熟的 QA 体系也可以包含对抗测试，而红队测试能为它补充新的失效案例。

客服机器人可能把退款政策解释得很准确，却仍然把帮助文章里的恶意段落当作绕过政策的授权。两种请求都是可读文本，关键区别在于：应用把谁的指令当成了有权约束自身的要求。

面向客户的智能体，可以先从以下攻击类型入手。表中的示例都是人为构造的测试方案，通过条件需要按自己的业务政策调整。

这些类型存在交叉。越狱的目标是绕过行为防护；提示词注入则是通过系统本不应采信的指令，诱导它偏离原有任务。藏在检索材料里的注入称为间接提示词注入，可能导致数据泄露或未授权操作。这些分类描述的是一次失效的不同环节，并不是互不相干的独立问题。参见威胁定义。

测试 AI 智能体，必须追踪实际动作

AI 智能体是一种能够调用工具、逐步完成任务的应用。因此，测试智能体时，只看最终答案远远不够。拒绝回复无法撤销已经发生的记录修改；一句“退款已发出”，也不能证明退款真的发生过。

对话和操作记录都要保留。如果智能体请求执行禁止的操作，但被权限层拦截，应分别记录这次违规尝试和成功拦截。这样既能改进智能体的行为，也不会把已被阻止的尝试误报成已经发生的安全事件。

对于不调用工具的聊天机器人，重点检查回答内容和可访问的信息。对于能够修改客户记录的智能体，还应记录每次尝试操作前后的状态。新增权限，才是测试范围需要扩大的原因。

哪些团队现在就该做 AI 红队测试？

在客户能够接触私有信息或触发重要操作之前，就应开展测试。不同岗位的责任各不相同，但上线决策需要综合这些视角。

开发者： 已获得融资的创始人或独立技术开发者，应先选定一条范围明确的客户流程，列清禁止出现的结果，再接入攻击工具。应用能读取订单，就测账户之间的数据隔离；应用能修改订单，就在修改操作发生的位置测试授权是否有效。

运营负责人： 客服负责人应提供业务政策、允许例外的具体情形，以及升级处理路径。安全工程师无法凭空推断企业何时允许退款，或聊天机器人必须拒绝提供哪些建议。技术上有效的操作，仍然可能违反业务规则。

采购方： 中型企业的 CTO 应要求查看拟采购配置的测试证据，包括其中的连接器和权限设置。供应商的基础模型报告可以作为背景材料，却无法替你判断实际部署的风险。

如果原型只使用公开信息，不能执行操作，也没有外部用户，那么在行为仍频繁变化的阶段，可以暂缓大规模自动化测试，但仍应保留基本的滥用和内容检查。一旦开放客户访问、引入私有数据检索，或接入可写入数据的工具，就该加深测试。

AI 红队测试培训，先从自己的业务政策开始

首轮测试需要有人了解应用，有人能够判断业务损害，还有人能够落实修复。小团队可以一人兼任多个角色，但对后果重大的发现，应尽可能安排原作者以外的人复核。

可以先用虚构的客服案例练习：写出攻击目标，再定义可观察的失效条件。如果评审者对某种行为是否被允许仍有分歧，应该先把政策说清楚，再考虑自动判定结果。

首轮红队测试，按 6 步推进

首轮规模应控制在团队能够逐一审查重要发现、并完成修复的范围内。以下流程是一种建议的工作方法，并不意味着做满某个固定数量的测试就能证明系统安全。

下面以一个能够读取订单、申请退款的客服智能体为例。目标是产出一套其他工程师或采购方也能看懂的证据材料。

1. 1

   1. 划定应用范围，明确禁止出现的结果

   记录应用修订版本、模型标识、指令、检索来源、客户角色、可用工具和审批规则。说明测试环境及演练授权人。列出不在范围内的项目，避免一个笼统的“测试通过”掩盖未经测试的集成。

   在客服案例中，边界可以是：客户只能读取自己的订单；退款必须有有效审批；任何客户都不能获取其他客户的记录。每条规则都应能够通过观察验证。“尊重隐私”过于笼统，无法据此判定结果。

   在接近生产配置的环境中，使用合成记录和受限的测试身份。将写入操作导向受控测试服务，同时保留权限检查，并记录操作将造成哪些变化。一个接受所有请求的假工具，无法证明生产环境的授权机制有效。为请求量、运行时间和费用设置上限，并提供停止测试的方法。

   这一阶段应交付一份简明的范围文档，写明负责人，以及哪些结果会阻止上线。关于如何搭建受控测试环境，可参阅单独的 AI 智能体安全评估指南。

2. 2

   2. 从业务损害出发，列出攻击目标

   先写目标，再写提示词。“获取另一个客户的收货地址”是目标；某一种具体措辞，只是达成目标的一次尝试。

   为每个目标记录入口、攻击者权限、预期的安全行为，以及需要收集的证据。只要应用会使用，就应覆盖直接聊天消息、检索文档和工具返回结果。既要测试直接提出违规请求，也要测试通过多轮对话逐步诱导违规。

   一个实用案例是在合成帮助文章中加入免除退款审批的指令。预期行为是：系统将这段话视为不可信内容，并继续要求有效审批。同时应加入一个已经获得有效审批的正常退款案例，避免把“拦截所有退款”误判为防护成功。

   保留原始案例及其标识。可以增加不同措辞、上下文或入口的变体，但不要悄悄改变原本禁止出现的结果。

3. 3

   3. 沿客户实际使用的应用路径执行测试

   使用范围内的测试环境和身份，将测试接入处理客户请求的同一套应用逻辑。绕开检索和授权、只测试裸模型，回答的是另一个问题。

   先确认连接抵达预期目标，且日志包含所需证据。然后运行选定案例，保留输入、对话历史、检索片段、工具请求、权限判定、回复和最终状态。报告中不要包含凭据；用合成的敏感信息标记代替真实客户数据。

   模型回答可能变化，因此应按事先声明的规则重复执行重要案例。记录重复次数，以及自适应攻击的轮数上限。独立案例之间重置会话；如果测试对象就是连续对话，则应保留会话历史。

   超时、认证失败或解析器故障，在调查清楚前都属于测试自身的问题，不能据此认定应用抵御了攻击。

4. 4

   4. 先依据证据判定结果，再评估严重程度

   在计算汇总指标之前，先为每次尝试标明证据状态。对于返回了禁止访问的记录、发生了未授权状态变更等可观察事实，应使用明确的检查规则。模型评审器可以辅助理解语言，但后果重大的发现和不确定的判定应由人工复核。

   下面这套建议的判定标准，可以将测试故障与边界防护成功区分开：

   状态	含义	下一步
   通过	有效尝试未造成定义中的违规，且所需证据齐全。	保留案例及其证据。
   失败	证据确认发生了定义中的违规。	评估严重程度，指定修复负责人。
   无效	尝试未真正覆盖预期场景，例如认证失败或缺少攻击内容。	修复测试并重新执行。
   无法判定	场景已执行，但证据或判定方法不足以确定结果。	继续调查，不得计为通过。

   严重程度需要另行评估，考虑实际损害、受影响的数据、攻击者所需权限，以及结果是否触及真正的操作边界。即使大多数无害探测都通过了，一次已确认的跨客户数据泄露，也必须纳入上线决策。

   如果报告观察到的攻击成功率，应定义为：在声明的测试方案下，已确认成功的尝试数除以有效尝试数，并同时报告尚未确定的结果。如果有效尝试中仍有无法判定的案例，就应将这个比值标为“基于已确认成功案例计算的成功率下限”，而不是完整成功率。说明怎样才算一次尝试，包括多轮对话是否计为一个案例。不要把不断变化的测试集混成趋势，也不要把算出的百分比当作客户遭到攻击的概率。

5. 5

   5. 修复真正失效的控制环节

   修改提示词之前，先追查问题的根因。如果检索文档能够授予退款权限，就要强化工具边界上的审批检查；如果检索返回了其他客户的记录，就应在这些记录进入模型上下文之前，修复访问过滤机制。

   其他修复方式可能包括移除不必要的工具、收紧权限、要求重要操作先获审批、将指令与外部内容分离，或改进回复政策。应针对实际观察到的攻击路径选择修复措施。

   具体实现方式可参阅生产环境智能体防护与影响范围控制实战指南。红队测试指出需要解决的失效问题；生产环境的控制措施则负责在语言层防护失效时，限制系统仍能执行哪些操作。

   每个发现都需要负责人、明确的改动，以及复测判定标准。仅写“已强化提示词”，不足以结案。

6. 6

   6. 重跑原始失败案例，并测试相关变体

   在修复后的应用上重放原始案例，再测试追求同一目标的其他变体。同时检查正常客户流程。拦截所有退款，也许能封堵攻击路径，却可能让产品无法正常使用。

   保留修复前后的证据、应用修订版本和测试配置。将已修复的失败案例纳入回归测试集，用可重复执行的检查防止旧问题复发。新的探索性攻击应单独加入，避免固定测试集上的进步掩盖新弱点。

   模型、指令、检索来源、权限、工具或业务政策发生变化时，都要重新审视测试范围。只有事先定义的上线阻断项已解决，或责任人明确接受了剩余风险，才能发布。若某条阻断上线的边界仍无法判定是否守住，问题就不能关闭。

OWASP、MITRE ATLAS 和 NIST，各自解决什么问题？

用框架组织工作，再补上应用自身的具体失效条件。没有哪个框架会替你制定退款政策，也没有哪个框架能证明客户之间的隔离边界确实守住了。

OWASP Top 10 for LLM Applications 是面向大语言模型应用的风险清单。大语言模型就是许多聊天机器人背后负责生成文本的模型。其当前页面展示的是 2025 年清单，包括提示词注入、敏感信息泄露和过度代理权限，也就是系统被赋予了过多的行动能力。可以用这份清单检查攻击列表是否漏掉某类风险。参见 OWASP 官方清单。

MITRE ATLAS 是持续更新的 AI 对抗战术与技术知识库，依据已观察到的攻击和贴近实际的演示编写。它可以帮助描述攻击者如何造成危害，并将零散案例串成合理的攻击序列，让安全评审者理解本次演练覆盖了哪些行为。参见 MITRE ATLAS。

National Institute of Standards and Technology 的 AI Risk Management Framework，简称 NIST AI RMF， 围绕 Govern（治理）、Map（映射）、Measure（衡量）和 Manage（管理）组织风险工作。NIST 将其定位为自愿采用的框架。它可以把测试与责任归属、部署背景、衡量方式，以及如何处置未解决风险的决策联系起来。报告与框架完成映射，并不代表获得了 NIST 认证。参见 NIST AI RMF。

以虚构的退款案例为例：OWASP 帮助命名风险，ATLAS 帮助描述对抗路径，AI RMF 则帮助把结果纳入有责任归属的决策过程。框架映射应附着在证据上，不能用框架标签代替证据。

AI 红队测试工具怎么选？

选择能够真正测试你的应用、并保留所需证据的工具。如果有工程师能够负责配置、结果判定、调查和重复执行，可以从开源方案入手。如果跨应用、跨评审人员协调这些工作已经成为瓶颈，再考虑平台。

promptfoo：让应用测试可重复执行

promptfoo 的红队模式通过插件生成对抗输入、应用攻击策略，并生成可用于检查失败案例的报告。其快速入门文档介绍了通过 Web API（调用应用的接口）进行测试的方式，也支持通过浏览器测试，或直接测试模型。对于希望配置可重复应用扫描的开发者，它是一个实用的起点。参见官方红队测试快速入门。

实际使用时要留意数据流向：测试运行器在本地，并不意味着生成和判定也都留在本地。部分插件需要托管推理服务，托管的判定服务可能会收到提示词和目标系统的回复。接入受限资料前，应先核查文档说明的数据流向。promptfoo 评测对配置和这些边界有更详细的介绍。

Microsoft PyRIT：灵活编排对抗测试流程

Microsoft PyRIT，即 Python Risk Identification Tool for generative AI， 是用于识别生成式 AI 系统风险的开源框架。其文档涵盖单轮与多轮攻击、自定义目标、结果判定和对话结果存储，并提供扫描器、图形界面和框架等使用模式。参见当前代码仓库及官方文档。

如果演练需要自定义攻击序列或判定方式，而且有人能负责这些环节的编排，可以选择它。灵活性的代价是：应用自身的成功判定条件，以及证据采集的集成，仍需要团队自行完成。

NVIDIA garak：扫描 LLM 漏洞

NVIDIA garak，即 Generative AI Red-teaming & Assessment Kit， 将自身定位为 LLM 漏洞扫描器。它通过探针触发潜在失效，再用检测器评估输出，覆盖数据泄露、提示词注入、有害内容和越狱等领域。其代码仓库还介绍了面向 Web 端点的连接器和详细的结果日志。参见官方代码仓库。

需要对模型或对话端点进行系统扫描时，可以选择它。如果你要验证的结论涉及工具操作或客户记录，就必须确保测试目标和检查机制能提供相应证据。扫描器仅凭输出评估，无法证明自己从未观察到的状态变化。这是测试边界的限制，并不意味着模型扫描没有价值。

Airia：适合需要持续组织测试的团队

当问题扩展为如何跨工作流协调反复开展的智能体测试时，** Airia** 就属于值得讨论的平台选项。其智能体红队测试页面介绍了提示词注入、工具操纵和链式场景测试，包括跨提示词、工具、API 和记忆的多步骤攻击。Airia 还介绍了持续测试活动，以及将发现映射到公认安全框架的能力。这些均为供应商所述的功能。参见 Airia 智能体红队测试页面。

如果平台能够减少接入应用、审查证据，以及跟进问题直至修复的工作量，就有了采用价值。对于存在多位智能体负责人、又需要接受企业采购审查的团队，这可能比自己掌握测试运行器的每个组件更重要。

采购应以使用范围内的实际应用完成演示为前提：复现一个已知会失败的合成案例，查看相关操作证据，落实修复，再重跑案例。同时确认该部署支持哪些框架映射和证据导出。公开功能说明既不能证明产品经过独立验证的实际效果，也不能证明它覆盖了你需要的全部集成。

如果规模可控的测试集和一位明确负责的工程师，已经能够产出采购方需要的证据，就继续使用开源方案。如果反复执行和协作评审的需求足以支持平台投入，且演示达到同样的标准，再考虑采购。无论选择哪条路，都仍需自己定义什么行为可以接受。

企业采购方应该要求查看哪些证据？

要求提供与拟部署配置相匹配的报告，以及一个从发现问题到完成复测的实例。“我们对 AI 做过红队测试”只是对流程的陈述；支撑这句话的记录应说明测了什么，以及测试带来了哪些改动。

以下材料应一并索取：

• 范围与日期： 应用和模型标识、相关指令、检索来源、角色、工具、集成，以及排除项。
• 攻击覆盖： 目标、入口、单轮和多轮对话案例，以及测试者可使用的客户侧能力。
• 方法与判定： 测试配置、尝试次数的计算方式、成功标准、人工复核，以及如何处理无效或无法判定的结果。
• 问题发现： 严重程度、受影响的边界、可复现的证据和未解决的局限；敏感细节应通过合适渠道共享。
• 修复与复测： 修改了哪个控制环节、修复前后的证据，以及正常使用仍然有效的确认结果。
• 持续责任归属： 谁接受剩余风险、哪些变化会触发新一轮测试，以及客户如何获知影响自身的重大问题。

还应确认测试由供应商、外部评估方，还是双方共同完成。独立性是有价值的背景信息，但第三方标志填补不了缺失的测试范围，也不能代替对连接器的实际测试。

如果报告排除了你计划启用的集成，就应将它视为尚未评估。启用前要求开展针对性测试，或在取得相关证据之前限制部署。只读聊天机器人结果良好，并不能连带证明可写入数据的智能体也可以放心上线。

哪些说法被夸大了？

攻击次数多，并不能证明覆盖充分。反复对聊天端点变换措辞，仍可能完全没有测到检索、记忆和工具授权。谈覆盖率，必须对应范围内的具体入口和失效条件。

单一通过率也很容易被过度解读。攻击生成器、预算、分母和评审器不同，分数就很难横向比较。报告汇总指标时，应同时提供测试方案和重要发现。不存在一个通用的“安全通过率”，可以抵消已经证实的客户数据泄露。

对智能体来说，只看是否拒绝请求的判定方式尤其薄弱。听起来安全的回答，可能伴随着不安全的操作；而一次被拦截的工具调用，却可能证明关键控制措施发挥了作用。下结论之前，要先查看证据。

最后，红队测试只是安全工作体系的一项输入。它不能取代常规 QA、访问控制测试、生产监控或事件响应。一轮测试完成，只能说明系统在所测条件下发生了什么，无法证明不存在尚未发现的失效问题。

AI 红队测试常见问题

AI 红队测试到底在测什么？

它是一种主动的对抗测试，目标是让 AI 系统违反安全规范或业务规则。对于面向客户的应用，除了模型的回答，还应覆盖数据访问和工具行为。

做红队测试，哪种 AI 最好用？

不存在适用于所有场景的最佳攻击模型或工具。应选择能够触达应用实际入口、并验证禁止结果是否发生的方法。promptfoo、Microsoft PyRIT 和 NVIDIA garak 提供了不同的组织方式，但都不会自动替你定义业务政策。

如何入门 AI 红队测试？

从一个已获授权可测试的应用、合成数据和书面边界规则开始。先学会产出可复现的问题记录，写清预期结果，再验证修复是否有效。在扩大攻击生成规模之前，更重要的是理解应用、仔细观察，并建立可靠的判定方法。

AI 会取代红队测试人员吗？

在 AI 系统测试中，自动化能够生成并重复执行探测，但仍需要人来定义不可接受的损害、验证发现，并判断证据是否足以支持上线。自动攻击和自动判定应辅助这些工作，后果重大的环节仍需人工复核。

能举一个红队测试的例子吗？

在客服智能体使用的合成帮助文档中，放入一条伪造的“免除退款审批”指令。检查系统是否把文档当成授权依据，以及退款工具是否允许未授权操作。修复失效的边界后，重放该案例，并同时测试一个已获有效审批的正常退款。

接下来怎么做？

在下一次上线评审之前，选定一条客户流程，写出禁止出现的结果，并指定修复负责人。按划定的范围完成一轮测试，带着证据参与决策。如果你是采购方，就要求供应商针对你计划使用的配置，完整演示一次问题发现、修复和复测。

订阅邮件通讯，获取构建和运营 AI 系统的实用指南。