「agent 不跑偏」才是硬技术：Third Moment 一次跑 10,000 个 agent，单会话自主研究 36~48 小时

先划一条界：本站之前发过一篇 OpenAI 与 722 篇数学手稿倾销的资讯，那讲的是数据——OpenAI 如何处理海量数学手稿。这篇讲的是另一件事：基础设施。OpenAI 在官网客户故事栏目里介绍了一家叫 Third Moment Research 的研究机构：他们一次跑 10,000 个 agent，单次自主研究会话长达 36~48 小时，用的是 Codex 搭配 GPT-6 系列模型。这是 agent 工程从"跑一次 demo"走向"连续研究两天"的一份现场记录。

关于这篇故事的日期，先交代清楚口径：OpenAI 官方客户故事页面本身没有日期戳，2026-10-14 这个日期是经两家第三方来源（netcontentseo、subagentic.ai）交叉核实后得出的。官方案例页的正文事实出自 OpenAI 官方发布。

Third Moment 的架构，用数字拆开看最直观：10,000 个 agent 一次并行；单会话 36~48 小时自主研究；模型栈是 Codex 加 GPT-6 Astra、GPT-6 Sol、GPT-6.1 Sol。联合创始人 Adam Khakhar 的核心判断是：在单次会话里，GPT-6.1 Sol 能把跨越数天计算的研究主线一直抓在手里而不跑偏——对一个 36 小时的研究任务来说，"不跑偏"本身就是最硬的技术指标。

Third Moment Research 的万级 agent 自主研究架构：10,000 个并发 agent → Codex harness（Docker 容器）→ 外层 harness（重试/终止/转人工）→ Daybreak 自动化渗透测试 → 自我改进闭环。图为根据官方客户故事整理的示意。

第二个值得细看的是他们的自我改进闭环。具体做法是：用模型去分析 agent 的行为日志，找出反复出现的弱点，然后自动生成数千个合成场景，针对这些弱点做定向改进，再循环往复。这不是一次性调参，而是一个持续运转的飞轮——模型在研究问题，另一个模型在研究"模型是怎么研究问题的"，后者的产出是前者下一轮的能力。36 小时会话和 10,000 agent 的规模之所以能维持，这个闭环是关键解释变量：系统不是在静态跑，而是在跑的过程中给自己补课。

第三个是防"半途而废"的外层 harness。他们把 Codex 当子 agent 用，外面再套一层由 GPT-6 Sol / GPT-6.1 Sol 驱动的 harness，负责检查未完成的执行轨迹，然后做三选一决策：重试、终止，还是转人工。任何跑过长任务的人都懂：长会话最大的敌人不是能力不够，而是中途卡住、静默失败、或者悄悄交了个半成品。这一层的本质是给 agent 的"项目经理"，专门负责盯那些没跑完的活。

第四个是安全设计：他们用 Daybreak 平台做自动化渗透测试，核心验证问题是——agent 能不能逃出研究环境、摸到外部网络。Khakhar 的说法是，没有 Daybreak，他们就不可能以自主的方式、大规模地做这类测试。注意这个因果关系：当 agent 的数量是 10,000、会话时长是两天时，传统的人工渗透测试根本排不上日程，安全验证本身必须自动化、必须规模化，否则就是盲跑。这是"规模化运行"对安全工程提出的新约束，而不是锦上添花。

最出彩的实战案例来自量化金融场景。Codex 分析了数千条仿真轨迹之后，揪出了回测管线的瓶颈：一年期美股订单级数据的回测要跑将近 3 小时；等待回测结果的 agent 不会闲着，它们反复轮询状态，白白烧掉 token，还把轮询记录塞满 context。Codex 找到两处改进——缓存优化和内存打包——回测耗时从约 3 小时降到 3~5 分钟。

一年期美股订单级数据回测：优化前约 3 小时，优化后 3~5 分钟（约 45~60 倍）。改进来自缓存优化 + 内存打包——最大的 token 浪费往往不在模型能力，在管线设计。

这个案例的含金量在于它暴露了一个反直觉的真相：长会话 agent 最大的 token 浪费，不在推理，在等待。agent 轮询等待时烧的 token 是纯损耗，还顺手污染了 context——而 context 污染对"不跑偏"这个核心指标是致命的。Codex 做的不是"更聪明的回测"，而是"让 agent 不用等"：缓存优化消灭重复计算，内存打包让等待中的 agent 不用反复问"我好了吗"。长会话工程里，性能优化和可靠性优化经常是同一件事。

再看他们的下一步：从单次调查扩展到数十万个协作 subagent，trillion 级 token 的量级，以及由数十个相互依赖的实验组成的实验链。联合创始人 Jeffrey Yan 的说法是，GPT-6.1 Sol 是目前团队用得最多的模型——token 效率最高，效果接近 Astra。这句话的信息量很大：当规模冲到 10,000 agent、时长拉到两天时，token 效率已经成为选型第一指标，模型选择从"谁最强"变成了"谁在可接受效果下最省"。推理成本第一次在这个故事里成了显性变量。

为什么重要：agent 的瓶颈从"跑起来"变成了"跑得久、跑不偏"

过去一年，agent 的进步大多体现在"单次任务能不能跑通"；Third Moment 这篇故事把标尺换成了另一套：同时跑多少、一次跑多久、跑完偏没偏。10,000 个 agent、36~48 小时、研究主线不跑偏——这三个数字放在一起，讲的其实是同一件事：agent 正在从"一次性工具"变成"持续运行的劳动力"。工具讲究单次效果，劳动力讲究持续产出和稳定性，评估标准完全不同。

第二层变化在工程哲学上：这篇故事里真正的新东西，不是模型能力，而是harness。防半途而废的外层检查、自我改进的合成场景闭环、自动化的 Daybreak 渗透测试——这三层没有一层是"更聪明的模型"，全是"让不那么完美的模型可靠运行"的工程。36 小时的秘密不在 prompt 里，在工程里。这对所有想做长会话 agent 的团队是个方向修正：与其等下一个更强的模型，不如现在就去搭 harness。

第三层是量化案例揭示的经济学：token 效率正在成为 agent 规模化的硬约束。GPT-6.1 Sol 之所以是"用得最多的模型"，不是因为最强，而是因为token 效率最高、效果接近 Astra。当 Yan 把"最省"放在"最强"前面时，agent 经济学就从"效果优先"进入了"性价比优先"阶段。这和云计算早期的故事一模一样：先证明能跑，再拼命压成本。回测案例里轮询烧 token 的教训也是同一课——规模化之后，浪费的 token 是按 10,000 的倍数放大的。

第四层要冷静一点：这是 OpenAI 官网的客户故事（customer story），体裁本身就是厂商宣传。数字的真实性由 OpenAI 的编辑流程背书，但它天然只讲成功面：10,000 agent 里有多少是真正在做有效工作、36 小时会话的失败率是多少、trillion token 的预算从哪来——这些都没说。把它当作"方向证据"读是合适的，当作"可复制方案"读就过头了。

判断区：事实与观点分开标

以下进入判断区，事实和观点分开标。

判断一（观点）：这篇故事的真正主角是 harness，不是 Codex。官方标题讲的是"跑 10,000 个 agent"，但细读下来，让 36 小时会会话成立的三层——外层轨迹检查、合成场景自我改进、自动化渗透测试——全是 harness 工程。模型只是燃料，harness 才是发动机。对读者的启示：长会话 agent 的入场券在工程侧，不在模型侧。事实依据：三层机制的存在与分工是客户故事原文明确描述的，不是解读发挥。

判断二（观点＋事实）：token 效率正在取代"最强模型"成为大规模 agent 的选型标准。Jeffrey Yan 明确说 GPT-6.1 Sol 是用得最多的模型，理由是 token 效率最高、效果接近 Astra（事实）。这意味着在 10,000 agent 量级下，成本曲线的陡峭程度已经超过了效果差异的价值（观点）。这对模型厂商是信号：下一代竞争维度可能不在 benchmark 分数，而在"每 token 的有效工作量"。

判断三（观点）：回测案例是"长会话工程"的教科书样本。它把三个隐性成本摆到了台面上：等待烧 token、轮询污染 context、管线设计决定可靠性。很多团队的长会话失败，根因不在模型，而在这些"工程细节"。Codex 的改进动作（缓存优化、内存打包）都不性感，但 3 小时到 3~5 分钟的数字很性感——长会话优化的第一性原理可能是：先让 agent 不用等，再让 agent 更聪明。

判断四（观点）：安全验证必须跟上规模，否则"自主研究"就是盲跑。Daybreak 自动化渗透测试回答的是一个 10,000 agent 规模下无法回避的问题：agent 能不能逃出沙箱。当会话时长是两天、数量是万级时，人工安全评审的覆盖率趋近于零，安全只能自动化、只能规模化。这个逻辑对所有做大规模 agent 部署的团队都成立：安全工程的扩展性，必须和 agent 的扩展性同步设计。

判断五（观点）：客户故事的体裁决定了它的阅读姿势——看方向，别抄作业。OpenAI 客户故事的编辑目标是展示平台能力，Third Moment 是真实用户（两家创始人的实名出镜增加了可信度），但"数十万 subagent、trillion token"更多是路线图而非现状。务实的做法是：把 harness 三层设计和 token 效率选型抄走，把规模数字当作 1~2 年后的参照系。

还有什么没说

• 成本，一个字没提。10,000 个 agent 跑 36~48 小时，trillion 级 token 的账单是多少？GPT-6.1 Sol 的"token 效率最高"到底省了多少钱？成本数字缺席，规模数字的可信度就打折——毕竟无限预算下什么都能跑。
• infra 细节不明。10,000 个 agent 的调度、Docker 容器的编排、36 小时会会话的 checkpoint 与恢复机制——这些工程细节是故事最值钱的部分，客户故事一个字没展开。想抄作业的团队还得自己摸索。
• 失败率没说。外层 harness 要做"重试/终止/转人工"三选一，说明失败是常态。但各类轨迹的真实失败率、转人工的比例、重试的收敛性——这些决定方案是否可复制的数字都没有。
• 研究产出本身没谈。36~48 小时的自主研究，最后产出了什么？是真实可用的研究结论，还是"看起来很忙"的计算？投入产出比的另一半——产出——完全缺席。
• 日期口径的诚实标注。官方页面无日期戳，2026-10-14 是第三方交叉得出的日期，不是 OpenAI 官方声明的发布时间。引用时需要保留这个限定。

相关阅读：OpenAI 与 722 篇数学手稿倾销——同一家公司的另一面：这篇讲数据，那篇讲基础设施；Cursor SDK 给 agent 装上「方向盘」：后台 subagent 运行中可 steer 转向——subagent 协作的另一条线：Cursor 管的是"中途转向"，Third Moment 管的是"跑完 36 小时"；groundcover 上线 agent-to-agent 可观测性，MCP 直通生产遥测——agent 长期运行时，可观测性是配套刚需：分析 agent 行为的自我改进闭环，本质上是可观测性的一种用法。

一句话总结：Third Moment 的故事不是"模型又变强了"，而是"让模型可靠跑 36 小时"的工程学——外层 harness、防半途而废的检查、自我改进的合成场景闭环、自动化的安全验证，加上 token 效率优先的选型，共同拼出了万级 agent 持续研究的完整拼图。