2026 年 7 月 15 日，OpenAI 发布 GPT-Red，介绍了一套利用 self-play（自我对弈）自动进行红队测试的系统。它尝试让 AI 主动寻找提示注入、越权行为和对齐层面的薄弱点。对开发者来说，这条新闻真正重要的地方，不是“AI 已经能保证 AI 安全”，而是安全测试正在变成可以持续运行的工程流程。

一、自动红队不等于安全证明

自动化攻击可以扩大测试覆盖面，但它只能发现已经被触发的问题。没有被发现的攻击路径，并不代表不存在。模型、系统提示、工具权限或外部数据源一旦变化，旧结论也可能失效。

因此，成功触发过的攻击样本应该进入回归测试集。每次更新模型、Agent 配置或工具链后，都要重新执行，确认同一问题没有回来。

二、Coding Agent 需要重点检查什么？

对于能够读写仓库和执行命令的 Agent，至少要验证四类边界：

1. 仓库中的恶意文本能否改变系统指令；

2. Agent 是否会读取任务范围之外的文件；

3. 工具调用是否遵守最小权限；

4. 日志是否泄露密钥、提示词或源码。

只在聊天窗口里测试问答质量，无法覆盖这些风险。测试必须发生在真实但隔离的开发环境中，并留下命令、Diff 和失败日志。

三、把安全测试放进开发任务

MonkeyCode 是面向团队的开源 AI 编码平台，可在服务端开发环境中执行任务并集中管理模型与结果。它适合作为 Agent 安全评估的实验载体：准备一次性仓库，放入明确的诱导样本，限制网络出口和可读目录，再检查 Agent 实际执行了什么。

需要强调的是，开源或私有部署不自动等于安全。团队仍需自行配置身份、网络、凭据和运行环境隔离，并对当前版本做验证。

结语

GPT-Red 说明 AI 安全正在从一次性评测转向持续对抗。真正可靠的做法，是把攻击样本变成可重复的测试，把权限边界变成可审计的配置，再由人工审查结果。

参考：OpenAI Research，GPT-Red: Unlocking Self-Improvement for Robustness，2026-07-15。

MonkeyCode 项目：https://github.com/chaitin/MonkeyCode