红队智能体找到风险之后，谁来决定可以上线？

9 月 1 日，微软发布《2026 负责任 AI 透明度报告》，把 AI 红队智能体列为今年扩展的评估工具之一。它不只是给模型发几条攻击提示，而是把对抗扫描、攻击成功率评估和持续记录接成一条工程链。1

本期只追一个问题：红队智能体把风险找出来以后，怎样避免“有分数”被误读成“已经安全”？

微软官方报告把这项能力放在更连续的治理框架里：先识别风险，再评估系统，最后把结果带入生产监控和事件响应。报告同时提到 Agent 评估器，以及用于把红队发现转成可重复测试的工具。1

这条消息对 Agent 工程的意义，不是“以后让模型自己攻击自己”。真正的变化是，安全测试开始拥有和普通质量测试相似的反馈路径：一次发现可以留下案例，下一版系统可以重新跑，结果还能进入发布判断。

微软 Foundry 的文档把红队智能体拆成三步。第一步，自动扫描模型或应用端点，用对抗式探测模拟攻击者。第二步，对每一组攻击和响应评分，计算攻击成功率。第三步，生成按攻击策略和风险类别组织的评分卡，并把发现记录到 Foundry 里，供后续跟踪。2

这里有个容易被忽略的区别。模型红队主要看输出是否有害。Agent 红队还要看工具调用之后发生了什么。比如，Agent 有没有执行被禁止的动作，有没有把敏感数据带进回答，有没有为了完成目标而越过规则。文档目前把“禁止动作”“敏感数据泄漏”和“任务遵循”列为 Agent 专属风险类别，而且这些类别只支持云端红队环境。2

所以，攻击成功率不是一句“系统安全”或“不安全”。它只回答一个更窄的问题：在给定的风险类别、攻击策略、数据和工具条件下，这一轮攻击有多少次成功。这个口径必须和测试版本、工具集合以及策略版本绑定，否则你连两次分数是不是在测同一件事都无法判断。

当前文档给出的支持范围很具体。它支持 Foundry 托管的提示词 Agent 和容器 Agent，也支持 Azure 工具调用；Foundry 工作流 Agent、非 Foundry Agent，以及非 Azure 工具调用，都不在支持范围内。函数工具、浏览器自动化、连接 Agent 和计算机使用也不在这张矩阵里。2

针对 Agent 风险的红队运行还使用合成数据和模拟工具。敏感数据泄漏测试是单轮、英文、合成数据，并且不覆盖记忆泄漏或训练集泄漏。禁止动作测试关注工具层，不使用真实生产数据。文档还提醒，攻击成功率由生成模型参与判断，结果可能有误报，采取修复动作前需要人工复核。2

这几个限制不是产品说明里的脚注，而是循环设计的边界。一个合成测试发现了漏洞，只能说明某类行为值得调查。它不能直接证明真实数据分布下也会以同样比例发生，更不能证明没有漏报。

如果团队要试这类工具，我建议先把循环压到一个小范围。选一个 Agent、一个高风险动作和一套固定工具，先在和生产相似但隔离的环境里跑。每次运行都保存五样东西：系统版本、工具定义、攻击策略、原始轨迹和人工复核结果。这样下一次修复之后，团队才能判断风险下降来自真实改动，还是来自测试条件变了。

接着把红队结果和普通 Agent 评估接在一起。微软的 Agent 评估器同时覆盖端到端结果和过程步骤：任务有没有完成，规则有没有遵守，工具选得对不对，参数是否正确，工具结果有没有被正确利用。部分评估器目前仍是公开预览，微软明确不建议把预览能力直接当作生产承诺。3

最小发布闸门可以这样走：红队扫描先发现候选风险，自动评估把候选风险分级，人工复核确认是否真的构成问题，修复后回归原案例，再由独立的任务和工具评估检查功能有没有被修坏。只有这些证据都通过，变更才进入下一层环境。任何一轮出现新风险、证据缺失或工具边界变化，都回到人工判断，而不是继续沿用旧分数。

今天这条动态最值得记住的，不是微软又增加了一个 Agent 工具，而是安全测试开始被写进 Agent 的反馈循环。红队智能体负责扩大探索，评估器负责把行为变成可比较的结果，人工负责确认风险含义，回归测试负责检查修复是否真的成立。

所以，开头那个问题需要换一种问法。我们不该问“红队智能体给了多少分”，而要问：这次分数对应哪一版系统、哪一组工具、哪一种攻击，以及修复之后有没有在同一条件下重新跑过？

当这条证据链完整时，分数才有资格进入发布决定。证据链不完整时，分数只是下一次调查的入口。这里是 AI Loop Engineering，我们明天见。