> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/ai-red-teaming-vendor-evaluation-criteria-2027.md).

# 2027年AI红队测试供应商评估标准：供应商与工具选型指南

本文整理自 Duaer 文档站，围绕企业选择AI红队测试服务商与工具时的关键标准，涵盖威胁模型匹配、结果可复现性、数据处理规则、工具与人工的权衡，以及测试能否持续改进系统。

## 问题所在：一份干净的报告不等于系统安全

大多数购买AI红队测试服务的企业，最后得到的是一份整齐的PDF、一份问题清单，以及一种模糊的安心感。更难回答的问题是：测试是否覆盖了对你的系统真正重要的攻击方式；发现的问题能否被你自己的团队复现；当你修改提示词、更换模型或新增智能体工具时，同样的弱点还能不能被发现。

选型的难点在于，“AI红队测试”如今涵盖的内容差异很大。有些供应商是安全咨询公司，主要开展人工对抗测试；有些则售卖自动化扫描器，向接口发送成千上万条提示词；还有平台同时提供两者。演示效果可能让任何一家看起来都很亮眼。下面的评估标准，旨在区分一次性的项目与企业能够长期使用的测试能力。

## 从威胁模型出发，而不是看供应商的攻击清单

常见误区是按供应商宣传的攻击类别数量来比较。一长串越狱模板并不能说明这些攻击是否贴近你的真实风险。只基于知识库回答问题的客服助手，与能够读取邮件、调用内部接口并写入工单系统的智能体，面临的威胁完全不同。

在与任何供应商接触之前，先为待测系统写一份简短的威胁模型：系统能看到什么、能做什么、哪些人可以与它交互，以及不良后果会是什么样子，例如客户记录泄露、未经授权的操作、有害建议或违反政策。然后要求每家供应商把其测试方案映射到这份模型上。好的供应商会对你的测试范围提出修改意见，并建议你没有想到的测试项，比如通过检索文档进行的间接提示注入，或通过工具调用进行的权限提升。差的供应商只会报一个通用套餐的价格。

审查方案时，要检查测试覆盖范围是否依据公认的框架进行说明，例如针对大语言模型应用的OWASP指南；还要看供应商能否说明哪些内容不会测试，以及原因何在。

## 以可复现性评判测试方法

红队测试只有在结果可以重复的前提下才有价值。请询问每家供应商如何记录攻击过程、使用了哪些输入和模型版本，以及你这边的人员如何重放某个发现。如果得到的回答是“我们的专家在测试中发现的”，那么这个发现很难验证、很难修复，也无法进行回归测试。

优秀的方法论应当把三件事区分开：攻击模式、触发故障的具体输入，以及判定成功与否所依据的标准。举例来说，一个发现应当写明：某份检索PDF中的特定间接注入，导致助手泄露了内部系统指令，并附上文档、提示词、模型版本和通过/不通过的判定规则。签约前索取一份样例报告。如果样例无法转化为测试用例，说明该方法论还不足以支撑长期使用。

还要询问供应商如何处理模型的不确定性。语言模型对同一提示词的不同次运行可能给出不同回答。可信的方法会对有风险的探测重复多次，并以比例或区间的形式报告结果，而不是只给出一次通过或失败。

## 评估数据处理与交战规则

红队测试意味着向你的系统输入对抗性内容，而且往往需要测试人员访问提示词、检索索引、日志或内部工具。这些访问权限非常敏感。任何工作开始之前，都需要一份书面协议，明确测试数据存放在哪里、谁能看到、是否用于训练供应商的模型、保存多久，以及数据是否会离开你所在的司法辖区。

交战规则同样重要。它们规定哪些环境可以测试、生产系统是否在范围之内、测试人员发现真实客户数据时如何处理，以及测试引发运营问题时如何叫停。有过类似经验的供应商通常会针对这些问题准备标准模板。如果供应商在这些方面含糊其辞，应把它视为风险信号，而不是走过场的手续。

如果团队正在处理[AI试点项目上线前的安全检查](https://doc.duaer.com/zh/guides/ai-security-compliance-2027-pilot-checks/)，这一部分可以并入同一轮审查，使测试访问权限与其他安全控制一起审批。

## 区分工具与测试人员，并明确你能保留什么

很多买家以为自己购买的是一样东西，实际上买的是两样：人的专业能力和软件。应当分别进行比较。人工测试人员擅长发现新的攻击路径，尤其是在智能体和多步骤工作流中。自动化工具则能大规模运行已知的攻击类别，在每次变更后重复测试，并产出一致的记录。一套健全的测试方案通常两者都需要，但两者的比重取决于你的发布频率和系统复杂度。

对于工具，要检查你能否添加自己的攻击用例、根据业务规则定制判定标准，以及能否把测试运行接入构建流水线。还要问清楚，如果你更换供应商，你积累的攻击用例库会怎样。如果你积累的测试用例只能在供应商的平台内使用，那么你形成的是依赖，而不是能力。

这里一个实用的做法是对比：让两三家供应商对同一个约定的测试端点运行同一组小规模探测，然后比较发现的问题、证据质量以及复现所需的时间。一次短期的付费试点，往往比任何评分表都更有参考价值。

## 衡量测试方案是否真正改进了系统，并落实本周行动

最后一项标准是结果。询问供应商如何验证修复是否有效。复测应当写入合同，而不是可选的额外服务。好的测试方案会按严重程度、组件和攻击类别跟踪发现的问题，并显示同类故障在模型或提示词变更后是否再次出现。

对于核心指标要保持谨慎。除非攻击集、判定方式和目标配置都已披露，否则一个单独的“攻击成功率”几乎没有意义。对供应商公布的模型安全数据也应同样审慎。[如何在选择供应商前核查幻觉率声明](https://doc.duaer.com/zh/guides/llm-hallucination-rate-evaluation/)中的方法同样适用：坚持使用你自己的测试集、你自己的判定规则和你自己的重复运行。

一个务实的起步方式，是从第一次测试开始建立一套小型内部回归测试集，之后每次新版本发布都用它来检验。这样做的团队，可以用稳定的基线来评判未来的供应商，比较起来也更公平。

本周可以先起草一份单页评估表，包含五列：与你系统相匹配的威胁覆盖、发现问题的可复现性、数据处理与交战规则、工具及测试资产的归属，以及复测承诺。用同一张表为每家入围的供应商打分，并在签约前要求每家提供一份样例报告和一个样例测试用例。

如果你希望在不从零搭建流程的情况下进行这类结构化比较，可以访问 https://www.duaer.com 注册，在一个工作流中整理你的威胁模型、测试运行记录和供应商评分表。它并不能取代安全团队的判断，但有助于在不同供应商和不同版本之间保持证据的一致性。

准备好建立一套可重复的评估流程了吗？请访问 https://www.duaer.com 注册并试用该工作流，先在一个系统上完成第一次比较，再逐步扩大范围。

总结：选择AI红队测试供应商，关键不在于谁的攻击清单最长，而在于测试是否贴合你的真实风险、能否产出可复现的证据、是否负责任地处理你的数据，以及是否让你留下可以持续运行的测试资产。

## 常见问题

### 如何判断AI红队测试报告是否可靠？

可靠的报告应当把攻击模式、触发故障的具体输入以及判定标准分开记录，并附上模型版本和文档等上下文。签约前应索取样例报告，看其中的发现能否转化为可以重复执行的测试用例。如果无法复现，报告的价值就很有限。

### 企业应该优先选择人工红队还是自动化工具？

两者通常都需要，但比重取决于发布频率和系统复杂度。人工测试人员擅长发现新的攻击路径，尤其适合智能体和多步骤工作流；自动化工具适合大规模运行已知攻击类别，并在每次变更后重复测试。对于频繁发布的系统，自动化回归测试的价值更为突出。

### 选择AI红队测试供应商之前应该先做什么？

先为待测系统编写一份简短的威胁模型，明确系统能看到什么、能做什么、哪些人可以与它交互，以及不良后果是什么。再据此要求供应商提交测试方案，并说明不会测试的内容。同时要求书面的数据处理协议和交战规则，确保测试访问权限在可控范围内。