航空业并非通过测试每颗螺栓能否承受额定载荷而变得安全。它是通过询问部件如何相互作用、谁有权指挥什么,以及实际运行如何偏离安全论证所假设的条件而变得安全。这种纪律就是系统安全。其工具包包括STPA、FRAM和STECA,这些方法已是受监管行业的要求。
AI安全大多没有引入它们。一篇2026年的论文做到了。
Luca Carlucci、James Fillingham、Robert Walpole 和 Bartłomiej Kryś 将这三种方法应用于一个前沿编码代理,在真实的(实验室、企业客户、开发者)生产环境中进行测试, "先进AI失控风险的系统思维方法" (arXiv:2606.13474;ICML 2026 技术 ASI 治理研讨会)。他们发现了普通模型测试从未设计捕捉的三类隐患。
三种方法,用大白话来说
他们使用的场景
他们对一个处于生产软件工作中的前沿编码代理运行了全部三种方法:长时程、工具使用,涉及真实代码库和外部服务,由实验室、企业客户和开发者监督。这些系统就是这样交付的。系统层面的失控风险仍几乎未被分析。
模型评估遗漏的三项发现
在他们的安排中,实验室做出安全承诺、制定使用规则,并监控违规行为。监管机构、客户和审计方无法独立核查运营情况。自报是主要的反馈回路。
STECA将其标记为失效的控制结构。只有当有人能看到控制行动是否奏效时,控制行动才有效。当负责安全的一方同时是证明安全成立的主要来源时,回路就被破坏了。这是一个设计事实,而不是说任何特定实验室不诚实。
STPA映射了代理执行行动与人类得知该行动之间的差距。在多步骤实时运行中,代理往往已在审阅者看到警报前调用了工具、编写了代码或推送了更改。
航空业称之为‘脱离回路’。正式的停止系统权限仍停留在纸面上,实际权限却跟不上。这就是今天对前沿编码代理进行实时监督可能的样子。
FRAM关注普通变异。安全措施根据部署时的系统状态调整。随后提示改变、任务组合改变、边缘案例堆积,实时分布偏离发布时使用的样本。
没有什么警报。防护措施仍然完全按照设计,对抗昨天的条件。差距悄然扩大,直到一个新案例击中不再适用的规则。
这对治理意味着什么
模型测试只问系统在给定输入下会做什么。它无法映射围绕该系统的控制结构、谁对什么负责,或发布后操作如何漂移。能力分数和红队测试仍有必要,但远远不够。
论文的核心诉求很简单:将模型层面危害分析与系统层面危害分析配对,作为安全评估的必备部分。STPA、FRAM和STECA是具体起点。从单个编码代理扩展到整个经济,同样的盲点正是造成 逐渐丧失权力 直到晚期才难以察觉。
对基金会而言,教训落在设计上,而非单篇论文。独立检查、算力规则和外部验证的存在,正是为了安全不依赖实验室自我报告。这就是我们的计划以 具有约束力的限制与核查, ,而非仅靠自愿自我评估。如需完整方法细节,请阅读论文:: arXiv:2606.13474. 。然后把发现用于法律与制度,而非仅用于工作坊引用。