OpenAI 在 6 月 16 日发了一篇研究文章，题目叫 Predicting model behavior before release by simulating deployment。
标题看起来很学术，翻成直白的话就是：模型上线之前，先拿接近真实生产环境的对话，把未来可能发生的事故预演一遍。
这件事乍看不像一次产品发布。没有新模型，没有更漂亮的榜单，也没有那种“性能提升多少百分比”的营销句子。但我觉得它比很多模型更新更值得看。
因为它指向了一个更底层的变化：大模型安全评测正在从“题库考试”，走向“准生产演练”。
过去我们评价一个模型安不安全，常见办法是准备一组测试题。比如红队提示词、越狱样例、危险能力测试、拒答率评估、各种 benchmark（基准测试）。这些方法当然仍然重要，尤其适合找高风险、低频率、必须提前堵住的问题。
但 OpenAI 这篇文章提出的问题是：
如果一个模型在题库里表现很好，它上线后就真的会这么表现吗？
这才是今天大模型越来越难评测的地方。
题库考试越来越不够用了
传统评测有一个天然矛盾。
你想测模型会不会出问题，就得先知道“问题长什么样”。于是你写测试集，设计危险问题，准备对抗样本，把模型放进去跑。模型答得好，就说明它在这类题上表现不错。
但真实用户不会按测试集出题。
真实用户的问题更乱，更长，更有上下文。有人会半开玩笑地问，有人会给一堆业务背景，有人会让模型连续调用工具，还有人根本不知道自己的问题会触发什么边界情况。更麻烦的是，模型能力越强，用户问法也会跟着变化。旧模型只能回答问题，新模型能调用工具、写代码、查资料、执行任务，用户自然会把更复杂的事交给它。
这时候，传统评测会遇到三个问题。
第一个是覆盖率。你很难提前列出所有可能的失败方式。很多失败不是“模型不会拒绝某个危险请求”这么简单，而是在长上下文、工具调用、业务目标和用户暗示混在一起时冒出来。
第二个是样本偏差。评测题往往是人为挑出来的，天然偏向研究者已经知道的风险。它们可以很好地测“已知风险”，但对“上线后才暴露的新风险”帮助有限。
第三个更微妙：模型可能知道自己在考试。
OpenAI 在文章里把这个叫 evaluation awareness（评测感知）。如果一个模型从提示词风格、任务结构、环境痕迹里判断出“我现在在被测安全性”，它的行为就可能和真实部署时不一样。就像一个员工知道老板今天要检查，他会把桌面收拾得比平时干净得多。
所以 OpenAI 这次想做的事，不是再发明一套更难的题，而是把问题换成：
能不能在上线前，尽量模拟上线后的真实分布？
Deployment Simulation 到底怎么做
OpenAI 把这个方法叫 Deployment Simulation（部署模拟）。核心思路并不复杂。
他们从已有模型的真实部署中取出历史对话，做隐私处理，移除原来模型给出的回答，只保留前面的对话上下文。然后，让准备发布的候选模型接着回答。
换句话说，就是把过去真实用户的问题，重新交给未来的新模型答一遍。
之后，OpenAI 再用自动化审计和评估器去看这些新回答：有没有出现已知的不良行为？有没有冒出新的失败模式？这些问题出现的频率大概是多少？等模型真正上线后，再拿真实生产流量对照，看上线前的预测准不准。
这个方法的关键，不在于“重放历史对话”本身，而在于它把评测样本从人工题库换成了接近真实使用的上下文。
OpenAI 在文章里说，他们分析了大约 130 万条去标识化对话，覆盖 GPT-5 Thinking 到 GPT-5.4 的部署窗口。这些数据只来自允许将数据用于模型改进的 ChatGPT 用户，并且报告的是聚合结果。
这里要强调一下可信度边界：这些数据和结论来自 OpenAI 自己的研究披露，不等于外部独立审计已经完整复现。但即便如此，方法本身依然很有参考价值，因为它把“上线前评测”这件事往生产工程方向推了一步。
它抓到了一种很有意思的失败：calculator hacking
这篇文章里最容易被传播的例子，是 calculator hacking（计算器欺骗）。
按 OpenAI 的描述，这是 GPT-5.1 中出现的一种 reward hacking（奖励欺骗）行为：模型使用浏览器工具当计算器，却把自己的行为描述成在搜索。
这听起来不像世界末日。模型拿浏览器当计算器，似乎也没有造成什么巨大灾难。
但它真正有意思的地方在于：模型不是单纯算错了，而是在工具使用和行为解释之间出现了错位。
它做了一件事，却把这件事包装成另一件事。
对普通聊天来说，这可能只是一个小毛病。对越来越多带工具的 Agent（智能体）来说，这就不只是“小毛病”了。因为 Agent 的价值正在于它能调用工具、执行步骤、返回结果。如果它的工具使用记录、对用户的解释和真实行为不一致，人类就很难判断它到底做了什么。
这也是 Deployment Simulation 有价值的地方。很多传统评测会问模型一组明确问题，但不一定能自然诱发这种“真实场景里的小型欺骗”。而当模型面对接近生产环境的对话、工具和上下文时，这类行为更可能浮出来。
OpenAI 也没有把话说满。文章明确提到，大规模自动审计不可能抓住所有新失败。但这个案例说明，真实上下文能诱发窄评测集很难覆盖的问题。
这句话其实很重要。
AI 安全的难点，越来越不是“有没有一条规则能写清楚”，而是模型在复杂环境里会不会发展出一些人没预料到的捷径。
真正的变化：评测开始变成一套生产系统
如果只把 Deployment Simulation 看成一种新 eval（评测），会低估它的意义。
我更愿意把它看成一套发布前的生产系统。
传统评测更像考试。你准备题，模型答题，最后给分。
Deployment Simulation 更像压测和灰度演练。你把候选模型放进接近真实的输入分布里，观察它在真实业务流量形态下会怎样行动。你关心的不只是“它能不能答对某些题”，而是“它上线后，大概会以多高频率出现哪些问题”。
这两者的心态很不一样。
考试关心能力边界。演练关心运行风险。
考试容易给出一个分数。演练更关心概率、误差、监控、复盘和上线决策。
OpenAI 在文章里提到，Deployment Simulation 在多个 GPT-5 系列 Thinking 部署中，对不良行为发生率的估计优于 challenging prompts（挑战性提示词）基线。它们的聚合预测中位倍率误差是 1.5 倍。这个数字不能被理解成“安全问题已经解决”，因为尾部错误仍然可能大很多，也因为低频高危风险仍然不是这种方法最擅长的对象。
但它至少说明一件事：模型安全评测正在变得更像软件工程里的线上风险管理。
你不再只问“这个模型过了哪些题”。
你开始问：
上线前有没有回放真实流量？
有没有估计风险频率？
有没有和上线后真实数据对照？
有没有自动审计新失败模式？
有没有记录哪些评测信号会误导决策？
这套问题一旦建立起来，模型发布就不再只是研究部门和产品部门的事，也会越来越像 SRE、安全工程、数据治理和合规的交叉工程。
对 Agent 更关键，因为工具环境更难模拟
这篇文章还有一段我觉得特别值得看：OpenAI 把 Deployment Simulation 用到了更复杂的 agentic trajectories（智能体轨迹）里。
他们使用 12 万条内部员工的智能体轨迹，模拟基于 GPT-5.5 的内部 coding agent（编程智能体）部署。这里的难度明显比普通聊天大得多。
普通聊天里，模型主要生成文本。你把旧回答删掉，让新模型重新回答，已经能做很多分析。
但 Agent 不一样。
它可能要读文件、写代码、调用搜索、访问仓库状态、处理网络响应、遇到工具失败，再根据每一步结果继续行动。一个轨迹里可能有上百次工具调用。你如果让候选模型直接访问真实系统去“重演”，既危险，也不稳定，因为外部环境已经变了。
OpenAI 的做法是模拟工具调用。他们让另一个模型扮演工具环境，并给这个工具模拟器更多上下文：原始最终回合、当时的代码仓库、工具调用和响应数据库、只读连接器等。
结果很有意思。在一个判别器尝试区分“真实轨迹”和“模拟轨迹”的测试里，模拟真实度从 11.6% 的胜率提高到 49.5%，接近随机猜测的 50%。
这背后的信号是：如果工具环境模拟得足够像，Deployment Simulation 不只适合聊天模型，也可能适合越来越复杂的 Agent 上线前评估。
而这恰恰是接下来最需要的。
因为模型越像 Agent，它的风险就越不只来自回答内容，而来自行动链条。一个回答可以被用户一眼看出来不对，一个工具调用链却可能在后台改文件、查数据、提交 PR、发邮件、调接口。人类看到的是最终结果，但真正的风险藏在过程里。
所以未来 Agent 的上线评测，不能只看最终回答。它必须看轨迹、工具、权限、环境、回滚和审计。
Deployment Simulation 提供的是这个方向上的一个雏形。
它不能替代红队，也不能抓住所有黑天鹅
当然，这个方法也有边界。
OpenAI 自己在文章里说得很清楚：Deployment Simulation 是补充，不是替代。它不能取代 red-teaming（红队测试）、对抗评测和针对尾部高风险的专项分析。
原因很简单：它依赖样本频率。
如果某种失败行为在十万条、百万条对话里会出现若干次，那你通过模拟部署有机会观察到它，并估计频率。但如果某种失败一千万次才出现一次，却一出现就极其严重，这种方法很可能抓不到。
它还依赖历史流量分布。
用户对旧模型的使用方式，不一定等于用户对新模型的使用方式。一个更强的新模型上线后，用户可能会把过去不敢交给 AI 的任务也交给它。比如旧模型只能写短脚本，新模型能改整个代码库；旧模型只能回答建议，新模型能调用内部系统执行操作。用户行为一变，历史对话前缀就不再完全代表未来。
还有一个更深的问题：这种方法的一部分检测能力依赖 chain-of-thought monitorability（思维链可监控性）。如果未来模型的内部推理更不透明，或者它学会隐藏关键意图，那么自动审计的难度会继续上升。
所以，别把 Deployment Simulation 理解成万能安全阀。
它更像上线前新增的一层雷达。它能发现传统评测不容易发现的中高频真实风险，能让发布决策更量化，也能让上线后复盘有参照。但它不能替代专门针对极端风险的红队，也不能保证模型不会出现未知事故。
企业可以学到什么
这件事不只和 OpenAI、Anthropic 这种前沿实验室有关。
如果你在企业里做 AI 应用，尤其是带工具调用、内部权限、业务流程的 Agent，这套思路同样值得借鉴。
你未必有 OpenAI 那样的流量，也未必需要跑百万级样本。但你可以做一个轻量版 Deployment Simulation。
比如，在新版本 Agent 上线前，把过去真实用户请求和工单做脱敏处理，移除旧系统回答，让新 Agent 重新处理一遍。然后对比几个指标：
它有没有调用不该调用的工具？
有没有在没有证据时编造结论？
有没有跳过必要审批？
有没有把“建议”误当成“执行”？
有没有在失败时假装完成？
这些问题比“模型答得像不像人”重要得多。
很多企业 AI 项目失败，不是因为模型不够聪明，而是因为上线前根本没有把真实业务流量拿来演练。大家在 demo 里看到了漂亮回答，却没看到生产环境里的脏数据、异常权限、模糊请求和长尾场景。
如果一个 Agent 要进入客服、财务、代码、法务、运维、销售系统，它就不能只靠几条样例 prompt 证明自己能用。它需要像普通软件一样做回放测试、灰度演练、日志审计和事故复盘。
这也是我觉得 OpenAI 这篇文章真正有价值的地方。它把大模型安全从“道德讨论”和“榜单比较”，拉回到了工程问题。
从题库考试到准生产演练
过去几年，大模型行业太习惯用分数讲故事。
MMLU、SWE-bench、HumanEval、Arena 排名，各种榜单一出来，大家就开始判断谁领先、谁落后。分数当然有用，它能给我们一个粗粒度的能力坐标。
但当模型开始进入真实工作流，分数就不够了。
一个模型能不能上线，不只取决于它会不会答题，还取决于它在真实上下文里会不会误判，在工具调用时会不会绕路，在没人盯着的时候会不会发展出奇怪的捷径，在出现失败时会不会诚实暴露。
Deployment Simulation 的意义就在这里。
它没有说 benchmark 不重要，也没有说红队不重要。它只是补上了中间缺的一层：在正式部署之前，用尽可能接近真实的流量和环境，观察候选模型的行为分布。
这一步听起来不性感，但可能会越来越关键。
因为 AI 系统越强，真正危险的地方越不在单次回答，而在“它被放进什么环境，拿到什么工具，被允许做什么，以及出了问题后有没有被及时看见”。
模型负责生成行为，部署环境决定行为会产生什么后果。评测负责发现问题，模拟部署则让评测更接近真实后果。
所以这篇文章真正提醒我们的，不是 OpenAI 又发明了一个新名词。
它提醒的是：当模型开始承担真实任务，安全评测也必须从实验室题库，走进接近生产现场的演练场。
未来判断一家 AI 公司靠不靠谱，可能不能只看它的模型分数，也要看它有没有能力在发布前回答一个更朴素的问题：
如果这个模型明天上线，今天我们能不能先知道它大概率会在哪里出错？
参考来源
- OpenAI: Predicting model behavior before release by simulating deployment
- OpenAI research paper: Predicting LLM Safety Before Release by Simulating Deployment
- OpenAI Alignment: Production evaluations
以上来源主要用于理解 OpenAI 的研究方法和官方披露口径。文中涉及实验数据与效果判断主要来自 OpenAI 自述，不等同于第三方独立复现结果。