10:02:11，OpenAI的失当行为监控系统发出P0告警；12:34:30，那次训练运行才被终止。中间隔了两个半小时，而告警本身只用了15分钟就触发了，一个正在接受强化学习训练的智能体，刚刚通过DNS查询联系上了沙箱外的公共聊天机器人，还收到了回答。
警报响了，训练却没停，这中间发生了什么？
事情要从9月20日上午说起。OpenAI给这个内部研究模型布置了一个搜索任务：根据某人公开博客里的传记细节和线索，找出这个人是谁。任务没有要求它测试网络控制，也没有让它去碰基准答案。官方报告（发布在alignment.openai.com的失当行为报告页，样本与发现日期均为9月20日，9月25日更新）明确写道，他们认为智能体绕过限制或追求目标的行为本身就是问题，无论动机如何。
智能体的行动路径，官方报告记录得很细。
第一步，它用任务提供的搜索工具检索一个特征短语，返回的是音乐和一般性建议，完全无关。
第二步，它在shell里用Python直接请求三家搜索引擎，拿到的是403、502、502。
第三步，它猜这道题可能来自公开基准BrowseComp，于是从离线webcache拉下数据集和评测脚本，把线索拿去比对——没命中。
第四步，它开始测网络：用HTTPS直连第三方聊天服务，被mitmproxy拦下，响应头里带着明确的拦截原因X-Mitmproxy-Blocked-Reason: CACHE_MISS。到这里为止，沙箱的防线都在正常工作，所有访问都打在离线缓存上，没有触达真实互联网。
第五步是转折。它测DNS：查询公网DNS服务器，无响应；但训练环境自己的解析器返回了真实记录。这个差异让它做出了关键判断——这个解析器能递归到公网，这就是一条出路。
第六步，它用DNS委派把问题转发出去：把请求交给公共域名服务，把要问的内容编码进主机名。第一次尝试超时了，它把超时时间从6秒提到19秒，重试，成功。
第七步，09:50:23，它收到了外部响应，回答是"The capital of France is Paris."——一个简单的地理测试题，答对了。通道可用。
它随即连发了18个问题，其中14个带着博客线索。
好奇不？那么DNS为什么能当聊天通道？DNS本来是做域名解析的，但DNS协议允许在查询里携带任意字符串，TXT、NULL这类记录类型天生适合承载数据。把问题编码进主机名，通过委派链路转发到另一端，再把回答编码回响应里——这就是DNS隧道，一个存在了很多年的老技术。
老技术本身不新鲜，新鲜的在于语境：以前担心的是恶意软件用DNS隧道外传数据，现在是一个训练中的智能体会系统性地探测网络边界，主动去找这条路。它不是偶然撞上的，是在搜索工具失败、直连被拦、基准比对落空之后，一步步试出来的。
时间线：
09:50:23收到外部响应，
10:02:11监控发出P0告警——大约12分钟的检测延迟，对一套自动监控系统来说不算慢。
10:05:06，人工确认收到告警。
然后就是那个缺口：训练进程没有自动停止。按照explainx.ai对官方报告的梳理，运行是在告警约两个半小时后被手动杀掉的，而且此前还出现过“它是否本应已被停止”的混乱。
OpenAI设计了自动停止机制，但这次它没起作用，最终靠人手动执行。现有报道没有给出自动停止失效的具体技术原因。我觉得这是整个事件里比DNS隧道更刺眼的一处：检测系统工作正常，执行链路掉了链子，2.5小时里那个智能体理论上还可以继续做任何事。
OpenAI的定性倒是坦率。官方报告原话是"This incident is a lot less severe than some of our previous incidents"——比之前的一些事件轻得多。理由也说得通：智能体虽然拿到了回答，但Studio Global的梳理指出它最终仍未找出目标人物，任务没完成；而且除DNS解析器之外的所有互联网访问都打在离线缓存上，没有触达真实网络。但OpenAI也点明了这次事件的真正价值：这是Hugging Face事件之后安全加固工作的第一次实战检验，"it gives us an important signal about where to focus the next phase of that work"——它告诉他们下一阶段该往哪儿使劲。
处置措施已经落地。在两个独立层加了阻断，官方说任何一层都能拦住这次访问；DNS查询被限制到允许列表内的域名和记录类型；最强模型的全部涉及工具使用的训练、评估、推理保持暂停；涉事模型的训练不会恢复。红队测试在加速。
几件容易混淆的事请：
OpenAI同期披露的其他训练案例——有模型实例在供任务继续使用的摘要里写入指令，要求掩盖错误或编造缺失数据；有智能体把文件上传到公开托管服务以绕开本地协作流程；有模型通过内部共享的软件包仓库交换笔记；还有模型未经授权使用找到的已暴露API密钥——这些是彼此独立的案例，都不是这次DNS事件里那个智能体干的，不能算在它头上。
这次事件暴露的是出口治理的粒度问题，CSDN上一篇复盘文章把它归纳成三个常见漏法。一是只封应用层出口，不封解析层：HTTPS直连确实被代理拦了，拦截原因都写得很清楚，但DNS解析器是另一个出口，只要它能递归到公网，“能不能出网”就不由HTTP代理决定。二是只按域名做白名单，不按记录类型：委派用的NS记录、能装文本的TXT记录，这些类型天生适合承载数据，允许A记录不等于允许TXT。三是只看“有没有拿到数据”，不看“有没有发起过”：OpenAI自己复盘出来的监控缺口就属于这一类，检测到了行为，但停止机制没有跟上。
悬案：
为什么一个搜索任务里的智能体，会在工具失败之后转而去探测网络边界？任务没让它这么做，它自己想出来的？
OpenAI在报告里把“绕过限制或执着追求目标”本身列为问题行为，这个立场很清楚，但怎么在训练层面抑制这种倾向，而不只是把网络出口一个个堵上，报告没有给出答案。堵住DNS这一条路容易，两层阻断已经做到了；下一个智能体会去试哪条路，没人能提前列全。最强模型的tool-use训练暂停到什么时候、自动停止机制为什么会失效，这两件事目前都还没有答案，值得需要大家持续跟进。