OpenAI 公开了自身安全运营的改造成果，将其命名为 Defense Factory。这是一套不间断运转的机制：AI 智能体发现漏洞、复现问题、生成修复方案，并确认修复确实生效。人类的角色则转向划定边界和处理例外情况。背后的紧迫感很直接——攻击方正借助能力不断提升的开放权重模型推进自动化，防守方若不能以同样的速度行动，就会被甩在后面。
防守方剩下的时间
攻击自动化早已不是研究者的假设。智能体能够跨会话保留学到的内容，建立起对系统结构的理解，再把彼此孤立的弱点串联起来。过去无法一次性拼出的攻击路径，如今可以在时间中逐步成形。加上智能体可以成群运行，这种规模远非人工确认加修补的节奏所能应对。
不过防守方手中也握有两张牌：可以让智能体直接接触自家代码，以及可以使用比攻击者常用的开放权重模型更强的前沿模型。OpenAI 把这一优势带来的余地称为"防守方的窗口"。这个窗口不会一直敞开，如果不落实持续防御，它就会逐渐关闭。
起点是一次内部的 Code Red
Defense Factory 并非从纸面设计开始。当模型能力提升到可以更深入检查自家系统时，OpenAI 在内部宣布进入 Code Red，把安全、应用和研究等团队集中起来展开了一次高强度冲刺。动员人数超过 250 人，覆盖的服务领域超过 100 个。
仅第一天就处理了 53 个被划为紧急或高优先级的问题。当时的负责人向公司表示，团队正以重大事件的紧迫感加固防线，这项工作的优先级仅次于关键业务运营。这次冲刺没有以一次性行动收尾，而是被改造成常态化的循环，这就是 Defense Factory。
五个环节持续运转
循环由资产清点、发现、动态验证、责任归属分配和修复验证五个环节构成。每个环节都会读写共享的上下文，下一轮可以复用此前建立的系统地图和归属信息。由于不必每次从零开始，越往后的轮次越能集中在变化和尚未解决的风险上。
一组数字能说明这套工程究竟解决了什么。责任自动分配的接受率达到 90.6%，报告中有 37% 被合并为重复项。在隔离环境中实际运行并成功复现的占 19.5%，经过动态验证之后的误报率降到 0.81%。修复补丁全部由 Codex 生成，被回滚的比例为 0.53%。
受挫的地方同样被坦率公开。早期的严重程度标签过于粗糙，分类结果会随着给智能体的指令不同而摇摆。团队为判定标准和提示词加上版本管理，补上可重复的评估机制，并记录审阅者给出的优先级及其理由，才让结果稳定下来。在去重精度提升之前，自动路由是被刻意暂停的。
使用的工具组合
整套架构的前提是接入已有工具。源码管理对应 GitHub 或 GitLab，检测类工具包括 Snyk、Semgrep 和 Tenable，工单管理则是 Jira、Linear 或 ServiceNow。Defense Factory 被定位为它们之间的黏合层，在可复现的隔离环境之上运行智能体。
智能体本身是 Codex，按用途分为桌面版、CLI 和面向安全的 CLI。模型方面除通用模型外，还使用了偏防守的 Daybreak Blue 和承担攻击视角的 Daybreak Red。验证环境每次重建这一点同样关键，上一次运行的状态不能混入下一次，这是可复现性的前提。
朝这个方向推进的不只有 OpenAI。Cloudflare、Ramp 和谷歌的团队也在尝试同样的思路，并各自公开了实践成果。
三个入门途径
OpenAI 建议不要一上来就搭建整套系统，而是先选一条工作流跑起来。目前提供三个入口：用于在公司内部提案的说明材料、面向授权防御用途申请高级网络安全模型的 Daybreak 通道，以及可以试用从漏洞检测到修复方案生成的 Codex Security 插件。据称涉及技术细节的博客文章也将在近期发布。
总结
Defense Factory 既不是新的扫描器，也不是新的模型，而是把既有工具重新排布成智能体可以触及的形态的运营设计图。它的价值在于，把 250 人规模冲刺中获得的经验，连同 0.81% 的误报率、0.53% 的回滚率这类具体数字一并公开。它所描述的路径同样值得借鉴：自动化不是一次性铺开的，而是在人工审阅积累起信任之后才逐步放手。
