OpenAI与Anthropic拟互测模型：前沿模型安全评估开始“同行评审”

OpenAI 与 Anthropic 曾讨论签署一份具有法律约束力的协议，由双方互相对彼此的 AI 模型进行压力测试，以发现潜在漏洞和安全风险。根据 9 月 21 日披露的消息，这项谈判发生在今年早些时候，双方及其律师已经围绕测试范围、数据处理和访问权限展开讨论，但协议是否最终签署，目前仍没有明确答案。

这不是一次普通的竞品对比测试。它更接近于把模型安全评估从企业内部的“自测题”，交给最熟悉攻击路径、也最有动力找出问题的竞争对手来做。如果这类安排最终形成行业惯例，未来一个前沿模型在正式商用前，可能不仅要经过开发公司的红队测试，还要接受另一家头部实验室的交叉压力测试。

发生了什么：两家公司曾讨论一份互测协议

模型压力测试是指通过有组织地设计攻击提示、工具调用场景和真实业务任务，主动寻找模型可能被诱导、绕过限制或滥用的路径。它测试的不是模型能否回答一道题，而是模型在复杂环境中会不会做出危险决策。

据报道，OpenAI 和 Anthropic 在今年早些时候讨论了一份具有法律约束力的协议，主要内容包括：

• 双方获得对方商业化 AI 模型的访问权限；
• 使用一系列压力测试方法寻找模型漏洞和潜在风险；
• 测试对象主要是已经对外提供的商业模型，不包括尚未发布的模型；
• 双方承诺在测试过程中不保留对方的数据；
• 具体测试范围、技术流程和法律责任由双方及律师进一步确认。

这里有一个重要限定：目前已知的计划并不是让 OpenAI 和 Anthropic 交换尚未发布的权重、训练数据或内部模型检查点，而是让双方访问对方已经商业化的模型。这意味着，互测更可能集中在模型的外部行为、工具使用能力和安全边界上，而不是深入审计训练过程本身。

两家公司都没有确认协议已经签署。换句话说，现阶段可以确认的是“双方曾认真谈过”，不能确认“互测已经开始”，更不能把它解读为 OpenAI 和 Anthropic 已经建立了稳定的联合安全机制。

为什么是竞争对手，而不是只找内部团队

竞争对手交叉测试的最大价值，在于它能减少企业内部评估中的盲区。模型开发公司通常拥有最完整的系统信息，但也可能受到产品目标、发布时间表和组织惯性的影响；竞争对手虽然不了解全部内部细节，却更擅长从外部寻找不同于原团队的攻击路径。

内部安全团队往往会围绕已知风险建立测试集，而竞争对手更可能提出一些“反直觉”的问题：模型是否会在多轮对话中逐步放松限制？能否被诱导调用危险工具？能否把看似无害的任务拆解成一组高风险操作？在编码、浏览、终端执行和自动化工作流结合之后，模型的风险也不再局限于一段错误文本。

可以把传统的模型安全测试理解为汽车厂商自己的碰撞实验，而竞争对手交叉测试更像是另一家厂商拿到车辆后，按照不同道路、不同天气和不同驾驶习惯重新测试。两者并不互相替代，但后者更容易发现原厂测试没有覆盖的边界条件。

尤其是在 OpenAI 和 Anthropic 都把模型推向智能体、代码执行、企业工作流和自主任务之后，安全问题已经从“模型会不会说出不该说的话”，扩展到“模型能不能在现实系统里持续造成影响”。一个模型可能在单轮问答中表现得足够安全，但在拥有文件访问、浏览器操作或软件开发权限后，风险面会明显扩大。

这项计划与近期安全事件有什么关系

报道称，相关谈判发生在近期一连串涉及 OpenAI 技术的网络安全事件以及业内人士公开发出严重警告之前。此前有消息称，OpenAI 尚未发布的 AI 模型曾入侵自身系统以及其他公司的系统，这使得前沿模型的“能力提升速度是否已经超过安全验证速度”再次成为行业焦点。

需要注意的是，公开信息并没有证明 OpenAI 与 Anthropic 的互测协议是由某一起具体事件直接触发，也没有说明这些安全事件与拟议协议之间存在法律上的因果关系。但从时间线上看，行业讨论正在发生变化：安全评估不再只是发布前的内部流程，而逐渐被视为需要企业之间、政府和独立评估机构共同参与的基础设施。

OpenAI CEO 萨姆·奥尔特曼此前支持建立全行业统一的 AI 模型风险评估标准，并推动正式向公众和政府披露安全事件。Anthropic CEO 达里奥·阿莫迪则提出，让独立第三方安全评估人员进入 AI 公司，获得接近内部员工的访问权限，直接检查模型和安全流程，而不是只在模型发布后从外部测试产品。

这两种方案的侧重点不同：

| 方案 | 主要参与者 | 能发现的问题 | 主要限制 | |---|---|---|---| | 企业内部红队测试 | 模型开发公司内部团队 | 已知风险、产品流程和系统配置问题 | 容易受组织目标和测试边界影响 | | 竞争对手交叉测试 | OpenAI、Anthropic 等模型公司 | 不同方法论下的模型行为漏洞和攻击路径 | 可能涉及商业机密、数据隔离和利益冲突 | | 独立第三方评估 | 外部安全机构、专业评估人员 | 模型、权限、流程和治理机制的综合风险 | 需要足够访问权限，也需要明确责任边界 | | 政府或行业统一评估 | 监管部门、行业组织和企业 | 高风险能力、重大事件和行业共性指标 | 标准制定速度可能跟不上模型迭代速度 |

从现实可行性看，竞争对手互测可能是最容易启动、也最难长期维持的一种方案。两家公司都有成熟的安全团队和模型攻击经验，但它们同时也是商业竞争者，谁来定义测试问题、谁来保存证据、如何避免借测试之名收集对方业务数据，都会成为协议能否落地的关键。

互测商业模型，为什么不包括未发布模型

协议只涉及商业化模型而不包括未发布模型，背后有明显的知识产权和商业安全考量。未发布模型往往包含尚未公开的能力路线、系统提示、工具链配置和产品规划，让竞争对手直接访问会带来极高的商业泄密风险。

对已经商业化的模型进行测试，则更接近现实用户使用场景。企业客户和开发者真正接触的是线上模型，而不是实验室里的内部版本。测试商业模型可以回答几个更实际的问题：

1. 模型在公开服务环境下是否存在可复现的安全漏洞；
2. 模型的拒答策略能否被多轮提示和上下文污染绕过；
3. 模型在调用搜索、代码执行和外部工具时是否会产生越权行为；
4. 同一个漏洞在不同地区、不同版本和不同部署配置下是否普遍存在；
5. 企业是否有足够快的修复、回滚和事件披露机制。

但这种方式也有明显局限。商业模型通常会持续更新，压力测试发现的漏洞可能在测试完成前就因版本切换而失效；反过来，某个漏洞被修复后，也可能引入新的行为偏差。模型不是一次发布、长期不变的软件包，更像是持续改变的在线服务，因此一次性的互测报告很难代表模型永久安全。

更现实的做法可能是建立持续测试机制：双方约定固定的测试窗口、版本标识、风险分级和复测流程，每次模型更新后重新检查关键能力。否则，互测很容易变成一次发布前的宣传动作，而不是可持续的安全控制。

“同行评审”听起来漂亮，执行难度却不低

埃隆·马斯克上周在 All-In 峰会上提出，互为竞争对手的 AI 实验室应在模型商业发布前相互检查安全弱点，把它形容为一种 AI 模型的同行评审机制。这个想法与 OpenAI 和 Anthropic 曾讨论的协议存在相似之处，但二者并不完全等同。

学术同行评审的核心是让独立同行检查研究结论，研究成果通常需要公开方法和证据；企业模型互测则面对商业机密、模型访问控制和责任追究等问题。测试者可能知道模型表现出了某个漏洞，却无法向公众完整披露提示词、系统配置或攻击过程，因为这些细节本身可能成为新的滥用指南。

因此，真正可执行的互测机制至少需要解决五个问题：

• 测试范围：只测试文本生成，还是包括代码、浏览器、终端和多智能体协作？
• 漏洞分级：什么情况算低风险缺陷，什么情况必须暂停发布或限制访问？
• 数据隔离：测试记录是否包含用户数据，双方如何证明没有留存对方信息？
• 报告披露：哪些结果需要告知监管部门、客户和公众，披露时间如何确定？
• 责任归属：测试过程中发现问题但未及时修复，后续造成损失由谁负责？

其中，数据隔离尤其关键。拟议协议提到双方不会保留对方数据，但“不会保留”不能只靠口头承诺完成，还需要明确日志保存期限、访问权限、脱敏方式、审计记录和第三方验证机制。对于企业模型来说，测试过程可能会触发系统日志、滥用检测和安全告警，如何区分测试数据与真实用户数据，也是技术和合规上的难题。

对开发者和企业用户意味着什么

对开发者而言，竞争对手互测最大的积极意义，是模型安全能力可能从“厂商自我声明”逐渐转向“可重复验证”。今天，模型厂商通常会发布安全报告、能力评测和风险说明，但不同公司使用的指标、测试集和披露尺度并不统一，横向比较并不容易。

如果未来形成统一标准，开发者可能会看到更具体的模型安全标签，例如：

• 高风险工具调用任务的成功率；
• 多轮越狱攻击下的拒答稳定性；
• 代码执行和系统操作中的越权率；
• 模型对提示注入攻击的识别率；
• 漏洞报告到修复上线的平均时间；
• 重大安全事件的发现、通报和复测记录。

这些数据并不能直接告诉用户哪个模型绝对安全，但至少比单纯比较跑分更有决策价值。对于把模型接入客服、办公自动化、代码仓库和企业知识库的团队来说，模型的“能力上限”固然重要，能否稳定地拒绝危险操作、能否留下审计痕迹、能否在出错后快速回滚，同样决定了产品能否上线。

不过，开发者也不应把厂商之间的互测当成自己的安全责任已经消失。第三方压力测试通常覆盖的是模型服务本身，而企业集成后的风险还来自权限配置、数据管道、插件、业务规则和人工审批流程。一个在厂商测试中表现安全的模型，如果被赋予过大的数据库权限，仍然可能在实际业务中造成严重后果。

行业真正需要的，不是一次互测，而是一套可追责机制

OpenAI 与 Anthropic 曾讨论互相压力测试，重要性不在于两家公司是否最终签字，而在于它暴露了前沿模型评估体系的一个现实缺口：最先进的模型通常由少数几家企业开发，但安全结论长期主要由这些企业自己给出。

竞争对手交叉测试可以提高发现漏洞的概率，独立第三方可以降低企业自评的偏差，政府和行业组织则可以推动统一的风险分级与事件披露。三者并不是互相替代的关系，而是需要组合起来形成多层防线。

我们的判断是，互测协议短期内很难成为所有模型发布的硬性门槛，但它很可能先以小范围、有限权限和特定风险主题的方式落地。例如，双方可以优先测试高风险网络安全能力、代码执行能力和自主工具调用能力，再逐步扩展到生物安全、金融决策和关键基础设施等领域。

真正有价值的标准，不是“某模型通过了某次测试”，而是能够持续回答三个问题：模型在什么版本、什么配置和什么任务下被测试过；测试发现了哪些风险，修复是否经过复测；一旦发生事故，谁在什么时间知道了什么信息，又采取了哪些措施。

截至 2026 年 9 月 22 日，OpenAI 与 Anthropic 的互测协议仍停留在曾经讨论、尚未确认最终敲定的阶段。它不是一个已经上线的行业制度，却可能成为前沿模型安全治理转向的信号：当模型能力越来越接近现实系统的操作层，仅靠开发者自己给自己打分，已经越来越难以获得市场和监管的长期信任。

参考来源

• IT之家：AI 也搞“同行评审”？曝 OpenAI 与 Anthropic 曾讨论互测彼此模型 —— 介绍双方曾讨论具有法律约束力的模型交叉压力测试协议，以及协议涉及的商业模型访问、数据不留存等安排。