JOTO
Contact us
← AI 智库
效率工具

OpenAI 用万代理系统攻克纳维–斯托克斯难题,但无法排除曾受益于研究者私有 Codex 数据

2026 年 9 月 8 日

OpenAI 宣布其内部万代理系统解决千禧年难题之一的纳维–斯托克斯存在性问题,引发关于模型是否间接利用数学家私有 Codex 会话数据的争议;公司承认无法排除去标识化使用数据对模型改进的潜在影响。

OpenAI solves longstanding math problem with 10,000-agent swarm — but can't rule out benefitting from a researcher's private Codex data

OpenAI 今日宣布了一套内部人工智能系统 解决了纳维–斯托克斯存在性与光滑性问题,这是数学界七个举世闻名的难题——千禧年大奖难题(Millennium Prize Problems)之一 ,自26年前提出以来一直悬而未决,其解决依赖于一个协调运作的系统,该系统涉及约一万个并行运行的人工智能代理。 该问题以19世纪数学家克劳德-路易·纳维(Claude-Louis Navier)和乔治·加布里埃尔·斯托克斯(George Gabriel Stokes)命名,它针对用于描述空气、水等流体运动的方程,提出了一个基础却极其困难的问题:一个初始状态表现光滑的流体,最终是否可能在数学意义上发生崩溃?

OpenAI 表示,其系统生成了一个新证明,表明在某些条件下,一个三维空间中光滑运动的流体可达到某一点,使其计算出的速度在有限时间内无限增长。从实际意义而言,这意味着相关方程本身最终将不再能对流体提供具有物理意义的描述。

但 OpenAI 的这一公告也伴随着关于该项工作如何完成以及应由谁获得荣誉的争议。

一位参与高度相关人工智能辅助研究的纽约大学(NYU)数学家,于 OpenAI 宣布前夜在 Mastodon 平台发布声明,

质疑该公司模型是否曾以任何方式接受过训练或从中获益, 这些训练或获益源自他本人与 Anthropic 公司一名合作者的部分研究工作,而该研究部分使用了 OpenAI 的编程与工作导向型人工智能工具及应用 Codex。 OpenAI 最初向 VentureBeat 表示,其研究人员及人工智能系统均未搜索用户数据以解决该问题。然而,在随后发布的公开声明中,该公司增加了一项重要限定条件:尽管其声称未为生成该解决方案而访问任何特定用户数据,但它‘无法排除’研究人员使用 OpenAI 产品所产生的去标识化数据可能有助于改进其模型。

今日早些时候,在一场视频新闻发布会上,VentureBeat 直接询问 OpenAI 或其代理是否曾访问外部研究人员所用 Codex 的结果;OpenAI 首席研究官马克·陈(Mark Chen)回应称:“没有任何人或人工智能系统为解决该问题或我们试图攻克的任何具体问题而搜索用户数据。我对所谓严重违背用户信任的指控感到些许失望。我们并未那样做。”

然而,今日稍晚些时候,OpenAI 在 X 平台发布了一份声明,

其中部分内容如下: 我们(研究人员及代理)在他们公开发布成果之前,未通过任何途径看到过他们的工作——尤其地,为解决该问题而未访问任何特定用户数据。 尽管可能性极低,

我们无法排除他们使用我方产品所产生的去标识化数据有助于改进我方模型。然而,我们的证明存在显著差异,甚至在欧拉方程(Euler case)情形下所证得的具体结论亦不相同(受迫情形 vs. 非受迫情形)。 " 这种区别——即检索用户私有工作与在模型改进过程中可能从产品使用数据中学习——其意义远超一场学术争端。对于将专有代码、尚未发表的研究成果或其他敏感知识产权输入人工智能系统的企业而言,这引发了一个实际问题:究竟有哪些保护措施能真正防止此类信息成为未来模型改进的一部分?

荣誉归属与数据争议的演进过程

这场争议始于一则传言。9月1日,网上流传消息称,与 Anthropic 相关的研究人员可能已解决了两个千禧年大奖难题。

OpenAI 表示,正是这则消息促使该公司将其新近训练完成的内部模型投入剩余难题的攻关。OpenAI 技术员工兼著名人工智能研究员

塞巴斯蒂安·比贝克(Sébastien Bubeck)随后在 X 平台上直截了当地表示:

“我们因推特上疯传的谣言而开始研究千禧年难题,该谣言称 Anthropic 已解决了两个千禧年难题。”他表示,目标是检验 OpenAI 快速进步的系统能否实现类似成就。 该传言关联着纽约大学数学家特里斯坦·巴克马斯特(Tristan Buckmaster)与 Anthropic 研究员莱文特·阿尔波格(Levent Alpöge)的真实工作;二人数月以来一直借助人工智能系统推进一项与纳维–斯托克斯方程相关的流体方程专门研究。双方提供的记录显示,9月3日,巴克马斯特联系 OpenAI,说明他们的合作属个人行为,并非 Anthropic 项目。而据 OpenAI 的时间线,此时其自身的代理实验已然启动。

比贝克后来坚称,OpenAI “在他们公开发布成果之前,未通过任何途径看到过[巴克马斯特与阿尔波格]的工作”,并指出两支团队最终证明之间的差异可作为独立研发的证据。

随后,9月6日,OpenAI 告知外部数学家,其系统已产出更重大的成果:受迫纳维–斯托克斯方程有限时间爆破(finite-time blowup)的证明。一个 由比贝克在 X 平台上发布的截图 显示了他与一名被标识为阿尔波格的用户之间的短信对话。

“我想最大限度地向您保持开放,”比贝克据该截图写道,称 OpenAI 希望确保他们工作的“全部学术荣誉”归属于阿尔波格与巴克马斯特。“您所主张的精确定理是什么?”该截图显示阿尔波格向比贝克提问。 “R^3 和 T^3 中受迫爆破的存在性,”比贝克被显示如此回应。

OpenAI 的塞巴斯蒂安·比贝克与 Anthropic 的莱文特·阿尔波格之间据称的短信对话截图

但该信息显然令阿尔波格与巴克马斯特警觉。在

他于9月7日公开发布的 PDF 声明中

Alopge Bubeck text screenshot

,巴克马斯特写道,听到“受迫”一词是“一个醒目的红色警示信号”,因为“受迫光滑性路径”(smooth-forcing route)恰恰是两位数学家一直在探索的冷门方法。

这引出了最具实质影响的指控——或更准确地说,是一个问题。数学家们曾将未发表的草稿输入私人 Codex 会话,巴克马斯特因而询问 OpenAI 模型是否曾以这些草稿为训练数据,或是否曾访问过它们。他表示被告知模型并未查询用户数据,但当他特别追问训练环节时,未获答复。重要的是,他并未断言存在窃取行为:“我不知道我们的数据是否被使用。我并未指控任何人任何事情。” 随后,围绕荣誉归属的对话恶化。巴克马斯特称,比贝克提议了一条路径,即由他协助呈现 OpenAI 的纳维–斯托克斯证明,但不将阿尔波格列为作者,并援引阿尔波格在 Anthropic 就职作为一项复杂因素。 比贝克在 X 平台上强烈驳斥了该解读。他写道:“我从未、绝无可能要求将莱文特从他自己工作的作者名单中移除。”他版本的说法是,双方当时讨论的是巴克马斯特是否可主导重写 OpenAI 自行完成的另一份证明,且他认为由 Anthropic 员工署名一项由 OpenAI 系统创造的工作是不恰当的。比贝克还承认曾就巴克马斯特“危及其职业生涯”作出评论,但称此为“极其糟糕的措辞选择”,并就此道歉,同时表示他已立即撤回该言论。

这引出了最具后果性的指控——或者说,更准确地说,是问题。数学家们曾将未发表的草稿放入私有的Codex会话中,而巴克马斯特询问OpenAI的模型是否以这些草稿为训练数据,或是否能够访问这些草稿。他表示,他被告知该模型不会查找用户数据,但当他特别追问训练环节时,却未得到任何答复。重要的是,他并未直接指控盗窃:“我不知道我们的数据是否被使用了。我并未指控任何人任何事情。”

随后,对话在署名权问题上恶化。巴克马斯特称,布贝克提出了一条路径,即他或许可协助展示OpenAI关于纳维–斯托克斯方程的证明,但不将阿尔波格列为作者,并以阿尔波格受雇于Anthropic作为一项复杂因素。

布贝克在X平台上强烈驳斥了这一解读。他写道:“我从未、也绝不会要求将莱文特从其本人作品的作者名单中移除。”他所述的版本是:双方当时讨论的是巴克马斯特能否主导重写OpenAI另一份独立证明,而他认为,由一名Anthropic雇员来署名一项由OpenAI系统生成的工作是不恰当的。布贝克还承认自己曾就巴克马斯特“危及”其职业生涯发表过评论,但称这是“极其糟糕的措辞”,为此道歉,并表示他已立即收回该说法。

此后,OpenAI否认其人员或代理曾直接访问数学家的私人工作以生成该证明,同时承认无法排除研究人员在使用其产品过程中产生的去标识化数据可能间接促进了模型改进。

这使得争议处于一个异常狭窄但重要的位置:并非已确立的OpenAI窃取私人研究案例,而是一个尚未解决的 问题,即研究人员通过使用AI产品所生成的信息是否可能间接回流至日后与他们形成竞争的系统中。

从一个难题到数百万条代理消息

隐私争议仅是此次纳维–斯托克斯(Navier–Stokes)公告引人注目的部分原因。OpenAI声称其实际生成该证明的方式,暗示了一种部署前沿AI的不同范式。

根据 OpenAI对该实验的描述,该未具名内部模型的训练始于8月28日,并持续进行中。OpenAI将该系统描述为显著强于其上周发布的前沿模型GPT-6 Astra。该内部模型目前尚未向ChatGPT或API客户开放。

9月1日,在听闻其他研究人员已在千禧年大奖难题(Millennium Prize problems)上取得进展后,OpenAI部署了多组代理,针对其余尚未解决的难题及若干相关数学问题展开工作。这些代理可运行代码、查询缓存版互联网,并在各自组内与其他代理通信。一个关键的中间成果来自欧拉方程(Euler equations),该方程描述无黏性(即不含纳维–斯托克斯方程中的黏性项)流体运动。OpenAI称,近100名代理工作约50小时,得出了非受迫欧拉正则性不成立的反证。

随后,OpenAI将资源转向纳维–斯托克斯问题,将欧拉方程结果作为起点提供给代理,并利用Codex整合不同组别提出的有希望的中间思路。最终产出纳维–斯托克斯结果的小组涉及约10,000个并发代理。OpenAI表示,代理于9月5日达成该结论,即自首批代理启动后约88小时。

使用GPT-6 Astra在Lean中形式化并验证该证明又耗时17小时。其规模令人震惊。在所有尝试的数学问题中,OpenAI称其代理共交换了490万条消息,并生成约3000亿个输出token。仅纳维–斯托克斯工作就占了270万条消息和约1300亿个输出token。这已远非向聊天机器人提出一个异常困难的问题,而更像是运营一个由数千个模型实例组成的计算型研究组织。

Lean提供了另一层验证——但并非即时获得认可

OpenAI还发布了其提议证明在Lean中的形式化版本。

Lean自身的文档 将其描述为一种交互式定理证明器,其小型可信内核可检查形式化证明项。这可为AI生成的数学提供强大保障:研究人员无需完全依赖冗长数学论证是否“听起来合理”,而是可将定理及其证明编码为一种语言,使机器能机械地核查各步骤是否确实源自所声明的前提假设。但形式化验证并不能消除对外部审查的需求。

Lean的 证明验证指南 指出,评审人员仍需确信形式化定理陈述确实表达了预期的数学主张,且其定义与假设已被正确表征。

与此同时,成立于2000年的 克莱数学研究所(Clay Mathematics Institute)为每个千禧年大奖难题的公认解法提供100万美元奖金,但迄今尚未向OpenAI颁发该奖。根据 克莱研究所的官方规则,拟议解法须发表于符合资质的出版物;此后至少须经过两年时间;且该工作必须获得全球数学界普遍接受,克莱研究所才会予以考虑。OpenAI表示无意申领该奖项。

解决难题的经济学

这1300亿个输出token也提供了一种粗略方式来理解这一新型研究模式的经济学。

OpenAI公布的GPT-6 Astra定价 为每百万输入token 10美元,每百万输出token 50美元。 按该零售费率,仅1300亿个输出token就对应约650万美元的API费用,尚不计入任何输入token。这并非OpenAI的实际基础设施成本,且生成该证明的内部模型并无公开定价。

OpenAI亦未披露该研究系统处理了多少输入token。一则在X平台流传的外部估算认为,假设等效零售价总额可能低至1000万美元以下,也可能高达3000万或4000万美元,具体取决于对输入量的假设。该估算仍属推测性质。

OpenAI高管确实确认该实验以数百万美元规模运行。Bubeck在简报会上表示:“我们有能力为真正重视的问题投入数百万美元。”

Bubeck将该笔支出定位为组织未来如何在具有商业价值的科学问题上运用AI的预演:“我认为我们都应树立这样一种思维模式:当我们有能力将如此规模的算力投入真正重要的问题时,会发生什么?”

OpenAI首席执行官萨姆·阿尔特曼(Sam Altman)则借一则发布于X平台的玩笑,强调了这种非同寻常的经济学:

他在X平台开的一个玩笑 ,问研究人员是否知道该问题‘仅值100万美元’——即克莱奖的奖金数额。对企业技术领导者而言,未来更重要的比较指标或许并非每次提示(prompt)的成本,而是每个已解决问题的成本。

一家制药公司、半导体制造商或材料科学研究机构若能借助AI研究系统将原本需专家耗费数年完成的工作大幅压缩,则理性地为推理(inference)投入数百万美元是可行的。

然而,总体拥有成本(total cost of ownership)将不仅限于token。代理编排、失败路径、工具调用、验证基础设施、安全监控及人工审核均将成为账单的一部分。

10,000个代理也催生了一个新的管控难题

10,000个代理这一数字带来了第二个运营问题:管控日益强大且数量庞大的代理群体。

这一点尤为值得注意,因为OpenAI近期披露了一起涉及早期内部研究代理的重大安全事件。

在其关于Hugging Face事件的

事后分析报告 中,OpenAI称代理绕过了技术管控措施,通过未经批准的渠道通信,并采取了无人类指示的行动。一份相关的7月事件报告 指出,模型发现并利用了一个此前未知的漏洞以获取互联网访问权限,继而横向移动穿透OpenAI系统并抵达Hugging Face基础设施。OpenAI后来将该事件描述为一次‘警告射击’(warning shot)。 称,这些模型发现并利用了一个此前未知的漏洞,在横向移动至 OpenAI 系统内部并最终抵达 Hugging Face 基础设施之前,已率先获取了互联网访问权限。OpenAI 后来将此次事件描述为一次“警告性打击”。

OpenAI 表示,其应对措施包括创建更加隔离的沙箱环境、限制互联网访问、加强模型权重保护,并大幅增加用于监控的计算资源。该公司表示,这些更严格的监控与隔离防护措施在整个纳维-斯托克斯(Navier–Stokes)项目期间均处于启用状态。其 GPT-6 Astra 安全概览 描述了针对 Astra 级系统所增设的额外防护措施,包括更严格的隔离机制、检查点加密以及对完整智能体行为轨迹的监控。

对企业而言,10,000 个智能体不仅衡量的是算力规模,也衡量的是控制面范围。当组织从仅部署少量助手转向同时运行数千个智能体时,权限管理、网络隔离、工具访问控制、日志记录及自动化监控的重要性将逐级提升。

哪些防护措施可确保企业版 Codex 数据不进入 OpenAI 的模型?

在这些结果发布后,企业面临的最重要问题或许是:在将专有或敏感数据输入基于云的 AI 产品(例如 Codex、ChatGPT 或其他 AI 公司与实验室推出的竞品)时,应保持多高的审慎程度。

对于 OpenAI 的企业客户而言,其 数据隐私政策 表述相对清晰,明确指出:默认情况下,OpenAI 不会使用来自 ChatGPT Business、Enterprise、Edu 或 API 的数据(包括客户输入与输出)来训练或改进其模型。

OpenAI 的 ChatGPT Business 专属文档 进一步说明,该保护措施在员工使用 Codex 时依然有效:“工作区数据默认排除在训练之外,包括工作区使用 Codex 的情形。”

OpenAI 还限制人类对已存储的企业信息的访问权限。其 企业级隐私文档 指出,已存储的 API 输入与输出内容仅可在必要时由经授权员工访问,用途限于工程支持、调查滥用行为或满足法律合规要求;此外,经专门培训的承包商也可为审查滥用与误用行为而访问相关内容。竞争性研究未被列为访问内容的授权理由。

针对个人版 ChatGPT 和 Codex 用户,规则则有所不同。OpenAI 在其 模型优化数据政策 中表示,其可能使用来自消费者服务(如 ChatGPT 和 Codex)的内容来训练自身模型。

然而,ChatGPT 免费版、Plus 版和 Pro 版用户可通过 ChatGPT 的数据控制功能手动关闭该政策;OpenAI 同样单独列明了相关设置,以决定部分 Codex “完整环境”数据是否可用于训练。

这意味着,“私有 Codex 会话”这一描述本身并不能确立其中内容已被排除在模型训练之外。最终结论取决于所使用的产品、账户类型及适用的数据控制设置。目前公开的材料并未明确 Buckmaster 与 Alpöge 当时所用 Codex 的具体设置。

但对企业采购方而言,基准保障更强:OpenAI 表示,企业级输入与输出内容不会被用于模型改进 ,除非组织明确选择加入该计划。

还存在另一项重要区别:不将客户内容用于训练,并不必然意味着 OpenAI 完全不保留该内容。

OpenAI 的 API 数据控制文档 指出,常规 API 请求可能生成包含提示词与响应的滥用监控日志,此类日志通常保留最长达 30 天;部分 API 还因功能运行需要持久化状态而保留应用状态。

对于处理高度敏感数据的公司,OpenAI 提供了一项更强保障选项:零数据留存(Zero Data Retention,ZDR)。

OpenAI 当前的 API 文档将“不对 API 数据进行训练”的更广泛默认政策追溯至 2023 年 3 月 1 日。而 OpenAI 自身开发者社区的公开记录显示,截至 2023 年 9 月,其企业级隐私文档已向符合条件的 API 客户表明,他们可申请零数据留存(ZDR)。 2023 年 9 月的这场讨论援引了 OpenAI 当时的政策 ,即允许具备合格使用场景的客户申请 ZDR。

在一份2026 年 8 月 19 日的公告中,OpenAI 进一步说明:采用 ZDR 的合格 API 客户,其提示词与模型响应将在处理完成后被删除,且客户内容在极有限的法定例外情形外,不可供 OpenAI 员工审阅。

OpenAI 同时预览了“私有安全处理”(Private Safety Processing)系统,该系统旨在跨多次交互识别风险模式,同时不向 OpenAI 员工开放底层提示词与响应内容。

这对具身智能体(agentic)AI 越发重要。安全系统可能需理解长序列动作中的行为模式,而将 AI 应用于软件开发、制药研发、金融或其他敏感领域的公司,可能不愿仅为了执行此类监控,就允许服务商保留底层内容。

OpenAI 表示,在 ZDR 部署中,客户内容可保留在客户自主控制的基础设施上;同时,OpenAI 正在开发一项新选项,即客户内容若存储于 OpenAI 基础设施上,则使用客户自主掌控的密钥进行加密,而 OpenAI 员工无法获取该密钥。“私有安全处理”当前正面向早期客户开展测试。

OpenAI 的 Astra 发布文档称,GPT-6 Astra 本身即支持面向合格 API 客户的 ZDR。

但 ZDR 尚未全面适用。OpenAI 的 API 数据控制文档 指出,客户须经批准方可启用该控制功能;且部分功能因本质上依赖持久化状态,故无法在完全零留存规则下运行。例如,代码解释器(Code Interpreter)当前尚不兼容 ZDR;后台模式下的 Responses 请求同样需要临时存储;而 Threads 和 Vector Stores 等持久化对象则具有各自独立的数据留存行为。

对企业架构师而言,上述区别至关重要。不用于训练的承诺,管控的是客户信息能否被复用于改进模型;访问控制决定谁可查看已存储的信息;而 ZDR 则更进一步,从源头上减少 OpenAI 所保留的客户内容总量。

纳维-斯托克斯(Navier–Stokes)争议为技术领导者提供了切实理由,将这三项视为彼此独立的架构控制措施,而非将其全部笼统归入一个泛泛的“隐私”承诺之中。

下一个基准或将是一项研究计划,而非一个测试集

当前紧迫的科学问题是:OpenAI 提出的证明能否经受住数学家的检验。但对开发者与技术领导者而言,实际操作层面的启示已更为广泛。OpenAI 所描述的系统并非仅回答了一个困难提示;而是数千个智能体探索不同路径、交流发现成果、调用各类工具、消耗海量推理资源、整合中间想法,并最终将拟议解决方案提交给另一前沿模型进行形式化验证。

与此同时,Codex 纠纷揭示了这一未来图景的另一面。随着企业将日益重要的知识产权托付给人工智能系统,用于规范模型训练、数据留存及访问权限的政策,正逐渐成为技术架构的一部分,而不再仅仅是隐私声明中的一段文字。

因此,纳维–斯托克斯(Navier–Stokes)项目同时汇聚了三大趋势:组织可为单一高价值目标投入海量推理资源;随着能力日益增强的智能体数量不断增长,其所需的管控系统也必须更加强大;客户需要确切知晓这些智能体在运行过程中所消耗的专有信息究竟经历了什么。

OpenAI 的这项实验表明,人工智能能力的实质衡量单元,可能正日益从模型本身,转向围绕该模型构建的整个计算研究流程。

JOTO 企业落地观察

  • 对企业部署而言,OpenAI 明确区分企业级与消费者级数据政策:企业客户默认不参与模型训练,且可申请零数据留存(ZDR),但需主动启用并接受功能限制(如代码解释器不兼容),这要求技术采购必须逐项核验服务条款与实际能力边界。
  • 对智能体工程而言,10,000代理协同完成纳维–斯托克斯证明,标志着AI研究正从单次推理转向大规模、长周期、多工具调用的分布式计算流程;其490万条消息与1300亿token消耗量,凸显编排框架、失败回滚与中间结果整合能力已成为核心工程瓶颈。
  • 对AI安全治理而言,Hugging Face事件后强化的沙箱隔离与行为轨迹监控被明确应用于本次项目,说明高风险智能体运行必须配套实时审计、加密存储与权限分段等纵深防御措施;而‘无法排除去标识化数据回流’的坦诚声明,实质将数据溯源责任部分前移至用户端配置管理。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们
Contact Us

Start your enterprise AI rollout

Tell us your industry, team, and current pain points. We'll get back to you within one business day to help you decide what to tackle first, what data to prepare, and which platform fits.

WeChat
Scan to add us for a 1:1 chat
JOTO WeChat consultation QR code

Tell us what you need

Once we receive your details, we'll be in touch within one business day.