分叉、汇总、再验收：一万 Agent 协同科研的组织方式
9 月 8 日，OpenAI 公布了一份纳维–斯托克斯（Navier–Stokes）存在性与光滑性问题的候选证明：一个初始光滑、静止的三维不可压缩流体，在光滑外力作用下，可以在有限时间内形成奇点，动能全程保持有限。公司同时放出可读论文与 Lean 形式化仓库，并表示不打算申领克雷数学研究所的百万美元千禧年奖。
媒体标题几乎都落在“千禧难题被 AI 攻克”。对做 Agent 系统的人来说，更值得盯住的是另一件事：大约一万个并发 Agent，怎样被组织成一条能产出可验收结果的科研流水线。
官方数字很硬：找到纳维–斯托克斯结果的那一组峰值约 1 万 并发 Agent；从 9 月 1 日启动到 9 月 5 日出结果，约 88 小时；这一题约 270 万 条消息、1300 亿 输出 token；全部尝试过的问题合计约 490 万 条消息、3000 亿 输出 token。之后 GPT-6 Astra 又花约 17 小时完成 Lean 形式化与机器检查。驱动 Agent 的是一个尚未公开发布、官方称“显著强于 Astra”的内部模型。
数学结论是否被学界最终接受，要留给同行审查和克雷的正式程序——那是以年计的事。下面只拆组织方式。
一、流水线长什么样
可以把这次系统理解成五段流程，而不是“一万个聊天窗口同时刷题”。
第一段：能力与工具。 Agent 可以读缓存互联网、跑代码，并在小组内部通信。官方只说“分成多组、组的大小不一”，没有公布一共多少组；能核对的规模数字是：产出纳维–斯托克斯结果的那一组峰值约一万并发，欧拉那条线则是近百个 Agent。OpenAI 称全程沿用前沿评测的监控与隔离措施。
第二段：问题变体分叉。 对同一道千禧年题，官方表述里有多条路径。能确认的划分依据主要是问题变体：不同组被分配不同表述——A、B 朝“证明光滑成立”走，C、D 朝“构造有限时间爆破 / 否证光滑”走；此外还鼓励各组探索不同方法路径。至于是否还按方法学派、工具权限或随机分桶再切一层，公告没写。并行的目的不是放大同一种搜索，而是同时覆盖互斥的结论方向。
第三段：跨组汇总与再分发。 各组探索一段时间后，用 Codex 把各组最有价值的中间结果汇总成后续提示，再喂回 Agent。最终找到解的那一组，就是在这种“探索 → 汇总 → 再推进”的循环里被引导到正确路线上的。换言之，Codex 在这里干的是调度与知识蒸馏，不是再写一篇证明。
第四段：资源重分配。 流水线不是从第一分钟就压满一万 Agent。先有近 100 个 Agent 用约 50 小时，在无外力欧拉方程上做出有限时间奇点结果；随后资源从其他问题上抽走，集中到纳维–斯托克斯。规模是跟着“哪条线出了可迁移的突破”涨起来的。
第五段：独立验收。 分析证明出来之后，才进入 Lean：由 Astra 把推理写进形式化语言，让内核逐步检查。生成候选与机器验收被拆开——验收侧问的不是“模型有多自信”，而是“在给定定义下，推导是否逐步成立”。
二、逻辑架构：四层怎么叠在一起
官方没有放出组件级架构图、消息协议或调度器源码。下面这张图是按公告里的可核对事实重建的逻辑架构，用来回答“系统大概分成哪几层”，不是 OpenAI 内部部署图。
图上按常见分层习惯，上层靠近交付、下层是底座。按底座往上写，四层依次是：
| 层 | 公开可确认的内容 | 仍属黑盒的部分 |
|---|---|---|
| 能力层（底座） | 未发布的内部前沿模型；工具含缓存互联网与代码执行；宣称有监控与隔离 | 模型结构、训练配方、沙箱实现 |
| 执行层 | 多组 Agent 并行；组内可通信；不同组被分配不同问题变体（A/B vs C/D） | 组间是否直连、会话状态如何持久化 |
| 调度层 | Codex 跨组蒸馏中间结果并再分发；人/系统把算力从其他题抽向 NS；中途可换更强模型版本 | 分支评分、杀枝策略、自动调度 vs 人工拍板的比例 |
| 验收层（顶层） | 换用 Astra 做 Lean 形式化与机器检查，与生成侧分岗 | 形式化流水线细节、失败回灌机制 |
有三点值得单独标出来。
第一，执行层是并行铺开的，调度层是往回收束的。 一万并发发生在各组内部的探索；跨组并不靠“所有人进同一个超长上下文”，而是靠阶段性工件（主张、证据、前提、未决）被蒸馏后再注入。这更像分布式搜索，而不是把聊天窗口横向堆到一万。
第二，调度层同时做三件事：知识蒸馏、提示再分发、资源重分配。欧拉突破后把 Agent 从其他千禧年题抽走、并把欧拉结果写进后续提示，说明调度输入里既有“中间引理”，也有“该把算力押在哪”。
第三，验收层刻意不与生成层共用同一套岗位。 Lean 内核提供的是生成侧控制不了的检查：它只验形式化陈述里的每一步推导是否成立。
公开产品线里的 Codex Subagents、Symphony（以任务看板为控制面的编排器）展示了 OpenAI 在编码场景如何做编排，但官方并未声明纳维–斯托克斯科研跑的就是同一套实现。可以借鉴其“一任务一工作区 / 父子 Agent / 等待汇总”的产品直觉，不宜直接等同于这次科研系统的内部栈。
三、三个可迁移的组织原则
抛开流体方程本身，这套结构里有三条对一般 Agent 系统也成立的设计。
1. 先分叉问题，再堆并发
一万并发很容易被误读成“人海战术”。官方描述更接近：先给不同组不同问题变体与不同探索方向，再在有希望的分支上加码。 十个组都问“请给出最优方案”，多半只会重复同一次搜索；十个组分别负责互斥假说、不同失败模式，才可能产生互补证据。
落地时可以先问：这个任务有没有几种互不兼容的成功定义？如果有，就按定义分叉，而不是按人数分叉。并发度是后加的旋钮，不是第一步。
2. 汇总要保争议，不要抹平成故事
跨组汇总最容易犯的错，是把互相打架的中间结论收成一段通顺摘要。那样一来，当初分叉换来的多样性就被调度层亲手毁掉了。
更稳妥的交接物应包括四样：主张是什么、证据在哪（diff、计算、文献段落）、依赖哪些前提、还剩什么未决。 接收方要能顺着链接核验证据，而不是只能读到一句“我们认为……”。被否掉的分支也要可检索，避免后来者重新踩坑。
Codex 在这里的价值，不在于文笔，而在于压缩可检验的中间产物，并带着前提一起传递。
3. 生成与验收必须分岗
如果还是同一批 Agent、同一套奖励，去判断“我们是不是做对了”，系统很容易自我说服。OpenAI 把 Lean 验收单独放在后段，等于换了一套验收标准：形式化语句在内核下是否成立。
对企业里的 Agent 流水线，同构的是：搜索侧负责提出候选，验收侧负责执行生成侧控制不了的检查——回归测试、独立复算、引文逐条核对、策略仿真。预算上要给验收留口粮；搜到最后一刻才想起验收，往往已经没时间证伪。
形式化通过，也不等于新闻稿里每一句外延主张都成立。Lean 验的是形式化陈述；克雷问题是否被“解决”、外力项设定是否落入奖项条款，仍要人来对齐定义。把验收规格本身也当成要审的对象。
四、成本与争议，只作边界条件
按 Astra 公开标准价粗算，1300 亿输出 token 仅输出侧就约 650 万美元——这只是用公开价做量级示意，不是 OpenAI 内部账单。真正贵的往往还包括：分支废弃、跨组读上下文、工具调用，以及人的调度。并行只有在“可验收结果变好”时才划算，否则只是把日志写厚。
同期，NYU 的 Tristan Buckmaster 与 Anthropic 的 Levent Alpöge 也发布了相关线上的形式化工作，双方就优先权、署名与数据使用有公开争议。OpenAI 称未在发布前看到对方未公开细节，但不能排除去标识化产品使用改进了模型。这条线很重要，但不是本文主线；对流水线设计者，它提醒的是另一件事：大规模并行搜索一旦接上公开文献与产品日志，独立发现与污染的边界会变得很难从外部切开。 组织流程里最好把“证据来源与时间戳”一并记下。
结论
- 这次发布的工程新闻，是一条可描述的 Agent 科研流水线，外加一层可重建的逻辑架构。 流程上：问题变体分叉 → 组内工具化探索 → Codex 跨组汇总再分发 → 向有突破的路线集中算力 → Lean 独立验收。架构上自下而上是能力层 → 执行层 → 调度层 → 验收层——一万并发落在执行层，底座仍是模型与工具。
- 可抄的是结构，不是规模。 先分叉互斥假说，再增加并发；汇总时保留前提与异议；生成与验收分岗，并单独给验收留预算。
- 机器验收抬高了“可发布”的门槛，也划清了它验不到的边界。 Lean 能把逻辑自洽从人工审稿里拆出去一截；陈述是否对应奖项条款、是否构成优先权，仍要人审定义与时间线。
如果你也在搭多 Agent 系统，不妨先画一张和上面类似的图：哪些步骤在搜索，哪些步骤在调度，哪些步骤在验收。三者混在同一个循环里，系统会看起来很忙；三者分开，才谈得上规模化。