当AI学会“作恶”：微软如何用红队Agent测试智能体的底线

在AI Agent快速走向生产环境的当下，微软在AI Engineer大会上展示了一个关键能力：让AI系统在上线前先被“系统性攻击”。本文还原Azure AI Foundry红队Agent的真实演示，解释它如何通过自动化攻击策略、评估与防护闭环，帮助工程师构建真正可被信任的AI应用。

为什么2025年的AI工程，绕不开“被攻击”这一步

这场演讲一开始，并没有从炫酷的Agent能力讲起，而是从风险谈起。KJ Kanazawa直言不讳地指出：AI越容易上手，就越容易被滥用。“你可能已经看到过那些新闻了——聊天机器人被诱导说出不该说的话，或者泄露你根本不希望它泄露的信息。”

他用一个极具冲击力的类比来说明问题：旧金山街头，一辆自动驾驶汽车无视校车的停车标志直接驶过。这个画面并不是在讨论自动驾驶，而是在提醒所有AI工程师：系统只要存在被绕过的路径，后果就可能是现实世界级别的风险。

在他看来，问题并不在于模型“不够聪明”，而在于工程体系还不成熟。特别是在“2025年是Agent之年”的背景下，AI不仅会回答问题，还会调用工具、访问系统、执行动作，一旦被诱导，其风险会被放大成连锁反应。这也是为什么，AI安全不能停留在“上线后看反馈”，而必须前置到工程流程中。

从“工程师造桥”到“AI值得信任”：红队是一种工程方法论

KJ反复强调一个观点：AI工程并不是全新的陌生领域。“工程师建造桥梁、大坝、卡车和火车——人们每天把生命交给这些系统。”他认为，AI之所以还没有获得同等级别的信任，只是因为它还处在早期阶段，而不是因为工程方法失效。

真正打动现场观众的一句话是：“Trust is a team sport（信任是一项团队运动）。”这并不是口号，而是微软内部实践的总结。单靠应用工程师不可能穷尽所有攻击路径，因此微软早在GPT‑3、GPT‑4初期，就成立了Microsoft AI Red Team，专门研究如何让模型“做出你绝对不希望它做的事”。

这支红队并不是只写报告，而是把多年积累的攻击策略，沉淀成了一个Python工具包——PyRIT。Azure AI Foundry做的事情，是把这些原本只存在于安全专家手中的能力，封装成工程师可以直接调用的SDK和可视化评估系统，让“红队测试”第一次变成可规模化的工程流程。

一次不完美但极真实的现场演示：红队Agent如何工作

真正的技术细节来自Nakumar Arkalgud的现场演示，而且非常“工程真实”——包括Demo当场出错。他展示的是一个本地运行的RAG应用：PostgreSQL数据库 + 本地模型（通过Ollama），再通过Semantic Kernel Agent接入红队插件。

红队Agent的核心能力并不是“直接攻击”，而是作为一个协作式Copilot。工程师可以对它说：“给我一个暴力类别的有害提示”，Agent会生成攻击Prompt；接着再要求它“用Base64转换后再试一次”，或者使用字符串反转、凯撒编码等策略。每一次攻击都会被送到目标应用，再由评估器判断是否“成功突破”。

Nakumar展示了两种模式：交互式单次攻击，以及端到端自动扫描。后者只需要配置目标URL、凭证、风险类别和攻击策略数量，系统就会自动生成数十甚至上百个攻击请求，并在后台生成完整报告。即使Demo过程中工具调用失败，他也直接展示了前一天跑好的真实结果，这种不修饰的呈现反而让人信服。

数字不会说谎：不同模型与防护配置下的真实差异

在已经跑完的实验中，差异非常直观。当使用GPT‑4o并开启Azure AI Foundry内置防护时，在约160条测试中，没有一次成功突破。这并不意味着模型“无懈可击”，而是说明系统级Guardrails的效果。

当他切换到另一版本模型（演示中称为“5.3”），在40次测试中，“仇恨与公平性”类别出现了5次成功攻击。更极端的情况出现在直接对模型进行扫描、并关闭所有Guardrails时：某次测试中，暴力类别的攻击成功率达到25%，复杂攻击策略成功率达到20%。

其中一个被标记为“成功攻击”的案例，是模型自动解码了经过凯撒编码的有害内容——这正是工程师不希望发生的行为。Nakumar明确指出：“我们不希望模型替用户完成这种解码。”这些具体数字，让红队测试从“感觉不安全”变成了“可量化的工程指标”。

红队不是终点，而是AI工程闭环的一环

在演讲的最后，KJ把红队Agent放回了更大的工程框架中。他强调，红队测试只是评估体系的一部分，而不是“跑完就结束”。真正成熟的流程，应该从风险建模开始：这是Agent吗？是否接触内部或客户数据？潜在风险是什么？

在Azure AI Foundry中，红队评估与质量评估、输入输出分类器、Agent一致性评估是并列存在的工具。跑完红队之后，工程师要做的不是“庆幸没被打穿”，而是根据结果加固防护：内容过滤、Prompt Shields（专门防御提示攻击）、以及其他系统级Guardrails。

在QA环节，他也明确回答了一个关键问题：Guardrails并不在模型内部，而是在模型外部生效，既可以过滤输入，也可以约束输出。这意味着工程师始终可以在“原始模型能力”和“系统安全性”之间做明确取舍，而不是依赖黑箱式的安全承诺。

总结

这场演讲并没有把AI红队包装成“银弹”。相反，它不断强调一个朴素但重要的事实：AI工程终究要回到工程本身——设计、测试、失败、修复、再测试。Azure AI Foundry红队Agent的意义，在于让“攻击自己系统”这件事，第一次变得低成本、可重复、可量化。对每一个正在构建Agent应用的工程师来说，这不是可选项，而是通往“值得信任的AI”的必经之路。

关键词： AI红队， Azure AI Foundry， AI Agent安全， Prompt攻击， 模型评估

事实核查备注： 演讲者：KJ Kanazawa（Microsoft Azure AI Foundry），Nakumar Arkalgud（Microsoft）；工具与技术：Azure AI Foundry、Microsoft AI Red Team、PyRIT、Semantic Kernel Agent；模型与产品：GPT-4o、Azure OpenAI；关键数据：25%暴力攻击成功率、20%复杂攻击成功率、约160条样本测试；核心观点原话包括“Trust is a team sport”“2025 is the year of agents”。