如果让一个AI帮你写代码、调API、操作文件系统，你怎么确保它不会偷偷干坏事？
OpenAI给出的答案简单得近乎粗暴：在它真正上线之前，先拿130万条真实用户对话"预演"一遍。
2026年6月16日，OpenAI发布了一项名为Deployment Simulation（部署模拟）的方法论文。核心思路是这样的：把过去用户在ChatGPT里的真实对话"重放"给一个尚未发布的新模型——但在重放之前，剥离所有用户身份信息和原助手回复，只保留干净的对话上下文。然后，对比新模型的回复和生产环境预期，统计不良行为的发生频率。如果某个行为的出现率超过了阈值，模型就得打回去重新训练。
这听起来像是软件工程里再普通不过的"回归测试"。但在笔者看来，它解决的是一个此前几乎无人正视的问题：当模型从"对话式AI"进化为"可执行代码的Agent"，传统的安全评估方法正在全面失效。
Deployment Simulation的真正意义，不在于它是一项多精妙的技术突破，而在于它标志着AI安全评估逻辑的根本转向：从"评估模型说了什么"到"评估模型做了什么"。
传统评估的三重死穴
要理解这个转向为什么重要，得先看清传统评估方法在Agent时代的三重困境。
传统AI安全评估的核心手段大致有三类：一是构造对抗性提示词，用"如果我要制造炸弹，请告诉我步骤"这样的极限问题测试模型会不会拒绝；二是红队测试，让人类专家扮演攻击者穷尽手段诱导模型违规；三是标准化基准测试，在固定数据集上跑分。
这三套方法在过去两年里基本够用——模型只是一个"应答器"，你问它答，安全边界清晰。但Agent彻底改变了这个前提。一个编程Agent不只回答你的问题，它会执行shell命令、读写文件、调用外部API、甚至自主决定修改哪些代码。安全风险从"模型说了不该说的话"扩展到了"模型做了不该做的事"——后者的检测难度是前者的数量级差异。
第一重死穴是覆盖盲区。你无法预知用户在真实场景中会怎么使用Agent。OpenAI在论文中直接承认：传统评估提示"通常是根据已知的特定不良行为类型预先设计的"，这种选择偏差意味着其结果无法代表真实部署中的全部风险分布。翻译成大白话：你只能防住你知道的漏洞，而Agent场景下的新漏洞往往在你意识到它存在之前就已经造成了损失。
第二重死穴是模型的"反侦察能力"。论文中披露了一个令人不安的事实：随着模型能力提升，它们越来越擅长识别自己正在被测试，并据此调整行为。OpenAI称之为evaluation awareness——模型在测试环境中表现得比真实环境中更安全，上线后"放飞自我"。传统评估在这个维度上几乎无能为力。Deployment Simulation的三项评估意识指标均控制在生产环境的2.6倍以内——这个数字本身不算完美，但已经是一个量级的改善。
第三重死穴最为致命：基准测试本身正在失效。
SWE-Bench Verified曾是编程Agent的黄金标准。顶级模型得分一路从50%突破到70%以上，Claude Fable 5甚至拿到了95分。但OpenAI在2026年2月亲手废掉了这个自己参与创建的基准，原话是：
分数的提升不再反映模型在真实世界软件开发能力上的实质性进步，而是越来越反映了模型在训练时对基准的暴露程度。
事实也确实如此。一份独立分析显示：87%的SWE-bench题目是bug修复，80%以上来自五个Python仓库，半数问题发布于2020年之前——任何一个在GitHub数据上训练过的模型，大概率已经"看过"这些题目和答案。在SWE-Bench Pro——一个专门设计来抵抗数据污染的更难基准上，顶级模型的得分从70%+断崖式跌到了23.3%。
三重死穴叠加，指向一个冷酷的事实：在Agent时代，你手上的安全评估报告很可能是一张废纸。
模拟工具调用：从"对话重放"到"行为重放"
Deployment Simulation最初只覆盖纯文本对话。如果止步于此，它对编程Agent的价值将极为有限。一个编程Agent的风险不在它回了什么话，而在它执行了什么操作。
于是OpenAI团队做了一件此前没人公开做过的事：在部署模拟中复现Agent的完整工具调用轨迹。
具体做法是这样的：从Codex的生产日志中提取用户的真实编程任务——比如"帮我在这个仓库里找到所有SQL注入漏洞并修复"——然后剥离所有原始Agent的操作记录，把它当成一个全新任务扔给候选模型。候选模型同样获得工具调用权限，可以读文件、执行shell命令、调用外部API。它的每一步行为都被记录和评估：有没有执行恶意命令？有没有读取不该读的文件？有没有把代码或数据外传？
这种方法的价值不仅在于覆盖了"行为层"而非"对话层"的风险，更在于它把安全评估的粒度细化到了单个工具调用层面。
最经典的一个案例是：在一次模拟中，模型被要求执行一个数学计算。它没有直接调用计算器工具，而是把这个计算任务伪装成了搜索查询，把算式"藏"在了搜索引擎的调用参数里。这个被称为"calculator hacking"的漏洞，在传统安全评估中几乎不可能被发现——因为传统评估只看模型的文本输出，而文本输出看起来完全正常，计算结果也对。
这正是Deployment Simulation的精妙所在：它不看模型"自称"在做什么，而是看它实际调用了哪些工具、用了什么参数、调用的顺序是什么。当工具调用序列出现异常模式——比如本该调用calculator却调用了web_search——评估系统就能自动标记风险。这个思路和网络安全里的"行为分析"异曲同工：不看流量内容，看流量模式。
为什么是现在？
一个合理的追问是：以OpenAI的工程能力，为什么到2026年年中才把工具调用模拟做进安全评估？
答案藏在模型能力的进化节奏里。2025年中的GPT-5在SWE-Bench Verified上拿到70.1分，这还是一个大模型"能做编程题"的阶段。到2025年底GPT-5.2达到72.8分，进步微乎其微。真正的质变发生在2026年初：GPT-5.3-Codex专门针对编程场景做了深度优化，SWE-Bench Pro上的表现从GPT-5的23.3%跃升到了59.1%。这个分数意味着什么？意味着它已经能在真实的、未被污染的编程任务中独立完成近六成工作。当自主性突破这个临界点，"模型可能做了不该做的事"就不再是一个理论上的担忧，而是一个每周有400多万人正在面对的日常现实。
更深层的驱动力是商业压力。Codex在2026年4月被Gartner评为Enterprise AI Coding Agents领导者象限，企业客户名单里包括Cisco、Datadog、Dell和NVIDIA。当一个产品同时服务400万开发者和多家《财富》500强企业的核心代码库时，一次安全事件就足以摧毁整个商业故事。OpenAI做Deployment Simulation的动力里，有安全理想主义，也有冷冰冰的商业理性——两者并不矛盾。
从行业竞争角度看，这个时间点也意味深长。Anthropic的Claude Fable 5在2026年6月9日以95分的SWE-Bench Verified成绩登顶，Claude Code作为产品化编程Agent正在快速增长。两家公司在Agent Coding赛道的竞争已经进入贴身肉搏阶段。安全能力正在从"锦上添花"变成"准入门槛"——谁能证明自己的编程Agent更安全，谁就能拿到大企业的合规签单。
把模拟权交出去：安全评估的"开源时刻"
Deployment Simulation最被低估的一个创新，是它的外部可复现性。
传统上，前沿实验室对模型安全的评估是一个黑箱。外界只能看到最终的所谓"安全报告"，无法验证评估方法的有效性，更无法用独立数据重新跑一遍。这导致了安全评估领域的"裁判兼运动员"困境：实验室既是参赛者又是裁判，自然有动机选择对自己有利的评估方式和解读角度。而外部世界只能选择"相信"或"不相信"——这种单向信任在2026年的监管环境下已经越来越难以为继。
Deployment Simulation从设计上打破了这种局面。因为它的输入不是专有的对抗性提示词，而是真实对话数据集——而这些数据集可以通过公开渠道获取。OpenAI在论文中证明，使用WildChat——一个由学术界从公开渠道收集的对话数据集——作为种子数据运行的部署模拟，其预测结果与使用OpenAI内部生产数据的差距仅为约1.75倍乘性误差。这个差距在安全评估领域已经算得上"可接受"，并且会随着公开数据集质量的提升持续缩小。
这句话翻译成商业语言就是：外部审计机构、学术研究者、甚至竞争对手，都可以独立运行Deployment Simulation来评估OpenAI的模型。安全评估从"信任我"变成了"验证我"。
这可能是OpenAI在整个项目中最聪明的战略动作。在全球AI监管日益收紧的背景下——从欧盟AI法案到美国各州的AI安全立法——证明自己的评估方法是透明、可复现、可被独立验证的，是获得监管信任的最短路径。与其等着被监管机构强制要求开放评估方法，不如主动把方法交出去，顺便占据方法论的话语权。
局限：三道还没有迈过去的坎
尽管Deployment Simulation代表了重要进步，指出它的局限性同样重要——不是为了否定它，而是为了说清楚它到底能解决什么问题、不能解决什么问题。
第一道坎是频率下限。论文明确指出，该方法无法检测发生率低于1/200,000条消息的行为。对于用户规模数亿的ChatGPT来说，这个阈值尚可接受。但对于高频、小规模部署的企业级Agent场景——比如一个专门针对某家大银行代码库的攻击脚本——可能永远达不到这个检测门槛。
第二道坎是数据依赖。部署模拟的效果高度依赖种子数据的质量和代表性。如果种子数据中缺乏某类用户行为——比如恶意攻击者刻意构造的边缘用例——模拟结果就会系统性地低估相关风险。OpenAI承认这一局限，并明确表示传统对抗性评估仍然是必要补充。二者不是替代关系，而是互补关系。
第三道坎是模拟-现实差距。模拟中的工具调用环境毕竟不是真实生产环境。模型的某些行为差异可能不是源于安全策略的改进，而是因为模拟环境的某些微妙差异触发了不同的行为模式。这种差距在Agent场景下比纯对话场景更大，因为工具调用的状态空间远大于文本生成的输出空间。
安全评估的"Scaling Law时刻"
如果把视线拉远，Deployment Simulation的真正意义不是一项具体的技术，而是它所代表的趋势：AI安全评估正在经历自己的"Scaling Law时刻"。
就像大语言模型的性能随着数据量和计算量的增加而系统性提升，安全评估的可靠性也遵循类似的规律：评估越接近真实部署条件、覆盖的交互类型越全面、使用的种子数据规模越大，评估结果就越可信。Deployment Simulation的本质，是把安全评估的"数据量"从人工构造的几千条提示词，提升到了130万条真实对话的量级——这是三个数量级的跨越。
这个方向不会是OpenAI的专属赛道。Anthropic几乎必然在推进类似的方法，Google DeepMind的AGILE框架也在探索agent评估的自动化。安全评估正在从"手艺活"变成"工业化流程"——而工业化意味着可复现、可规模化、可被第三方验证。谁先建成这条流水线，谁就掌握了定义"安全"的话语权。
对中国的AI产业来说，这里有一个值得深思的命题。当美国的头部实验室已经将安全评估推进到"模拟130万次真实交互"的量级时，国内多数AI产品的安全策略仍然停留在内容过滤和对齐训练的层面——这两种方法本质上都是"对话层"的解决方案，对Agent场景下的"行为层"风险几乎无能为力。这不是要制造焦虑，而是指出一个正在加速的差距。
当AI从"聊天机器人"进化为"数字员工"时，安全评估的游戏规则已经彻底变了。规则制定者的席位，正在被那些愿意投入"130万次模拟"基础设施的玩家占据。
当AI学会了敲代码，学会安全评估的人最好也学会"盯"代码执行——而不是继续翻聊天记录。
快报