source preview
source preview 查看原始材料 ↗
White Third Moment wordmark over smoky plum glass illuminated by warm amber light.
White Third Moment wordmark over smoky plum glass illuminated by warm amber light. 查看原始材料 ↗
Third Moment Research’s continual improvement loop: agents run experiments, identify recurring issues, generate simulations, and improve the agent, using Codex and OpenAI models.
Third Moment Research’s continual improvement loop: agents run experiments, identify recurring issues, generate simulations, and improve the agent, using Codex 查看原始材料 ↗

先看证据

案例称10,000个智能体同时运行关键事实
自主研究会话36–48小时关键事实
研究环境包含约1 TB数据与资料关键事实
回测约3小时降至约3–5分钟关键事实
页面摘要称回测时间减少97%关键事实
分析数千条轨迹并生成数千个合成场景关键事实

把机制串起来

输入先把素材压到可处理的规模

长时程智能体不只是“模型想得久”,还要有执行工具、持久任务状态和处理失败的外层调度框架;模型上下文有限,不能把数十小时的全部过程都塞进一次对话。量化回测提供可运行的环境与相对明确的反馈,但一次回测结果可能只是噪声,并不等于策略能在真实市场赚钱。

机制再把计算集中到关键步骤

每个量化研究智能体在 Docker 化的 Codex harness 中工作,可访问约 1 TB 的数据、文档和研究代码;GPT‑6 系列负责推理,harness 提供计划、执行、子智能体和上下文压缩等能力。智能体运行策略实验、读取结果并决定下一轮实验;遇到未完成任务时,外层 harness 检查执行轨迹,再决定重试、终止或交人工审查。更关键的改进环节是从大量轨迹中找出重复弱点,并围绕弱点生成合成场景,供后续改进与测试;公开材料未说明场景生成、筛选及防止评测泄漏的具体方法。C

结果最后落到可验证的工作结果

['适合结果可计算、可重复的研究与仿真实验', '先用轨迹和时间戳定位瓶颈,再优化慢工具与轮询', '缓存前校验数据、参数和代码版本,避免复用错结果', '回测结果不能直接证明实盘收益;高风险操作需人工把关']

案例的重点不是把模型开得更多

OpenAI 于 2026 年 10 月 14 日发布了 Third Moment Research 的案例:这家 AI 实验室把 GPT‑6 系列模型与 Codex 执行框架用于量化研究,让智能体在历史市场数据和仿真环境中测试交易策略,并根据实验结果安排后续工作。案例称,系统可以同时运行 10,000 个智能体,单次自主研究持续 36 至 48 小时。

这组数字容易把注意力引向模型规模,但案例更值得读的变化,是研究任务从“按要求执行一次实验”转向“观察结果、选择下一项实验,再继续运行”。要让这种工作成立,光增加推理能力不够:数据、代码、仿真、任务调度和失败处理必须组成一个可持续的工作环境。智能体能否长时间做研究,因而也是系统工程问题。

执行环境决定智能体能做什么

在量化研究场景里,智能体运行于 Docker 环境中的 Codex harness。它们可以访问约 1 TB 的数据、文档和研究代码库,后者包含特征工程、GPU 模型训练、交易策略与仿真模块。GPT‑6 系列模型负责推理,harness 则提供工具、规划目标、创建子智能体和压缩上下文等执行能力。

这个分工很关键:模型负责判断下一步,harness 把判断转成对代码和环境的操作,并在长任务中管理工作状态。研究智能体不是只回答“哪种策略更好”,还要测试策略、比较结果是否可能只是噪声,再据此决定接下来做什么。案例称,新模型可以借助子智能体并行调查数百项实验,但公开材料没有披露这些任务的调度方式或完成率。

一次回测说明了等待也会消耗推理预算

案例中最具体的工程证据,不是一个新模型基准,而是一次回测优化。Third Moment 使用 Codex 分析数千条智能体执行轨迹、时间戳和代码库,发现年度订单级美国股票数据的回测原本需要约 3 小时。等待期间,智能体会反复查询任务是否完成,既浪费 token,也把上下文空间挤给了状态检查。

Codex 随后通过分析回测输入和使用方式,找到缓存与内存打包方面的优化,并将修复部署到生产环境。OpenAI 报告的结果是,回测耗时降至约 3 至 5 分钟,摘要将降幅概括为 97%。按约 3 小时计算,5 分钟大致对应 97% 的缩短,但 3 分钟对应的降幅更高,页面没有说明百分比采用哪个终值或统计口径。无论如何,这个例子揭示的不是智能体突然更会研究,而是更快的反馈减少了空转,让预算能留给真正的实验。

“越用越好”还需要一条可检验的闭环

OpenAI 将这套系统描述为会自我改进:它分析智能体行为,找出反复出现的弱点,再围绕这些问题生成数千个合成场景,用场景改进智能体,并在新问题出现时重复这一过程。这里的关键不是“合成数据”本身,而是能否把线上失败转成针对性的测试,再确认修复是否让后续表现改善。

但公开资料没有解释这条链路如何与 Third Moment 自己描述的服务衔接。公司网站介绍的流程是收集请求轨迹、诊断失败,由客户选择需要修复的问题,再基于客户数据建立评测并进行模型后训练或 harness 优化。这与案例中的合成场景改进有关联,却不能据此认定两者采用同一套实现。对技术负责人来说,应把“使用后改进”拆成可审查的步骤,而不是把它当作已经自证的系统属性。

规模数字之外,仍要看运行边界

案例还列出单日 1 万亿 OpenAI tokens,但没有说明统计范围、输入与输出口径,也没有证明它与 10,000 个并发智能体属于同一运行记录。10,000 个智能体和 36 至 48 小时同样来自 OpenAI 的客户案例,公开页面未提供运行日志、硬件配置、任务成功率、人工介入频率或成本。因此这些数字适合作为系统规模的线索,不适合作为独立验证过的性能指标。文章提到的数十万协作子智能体和数万亿 token,则是未来目标,不是当前已实现能力。

长时间自主运行还把安全问题带进了执行架构。OpenAI 称,Third Moment 使用 Daybreak 检查智能体能否逃离研究环境并访问外部网络,但公开材料没有给出具体部署细节,也没有独立证据说明测试覆盖范围。对准备建设类似系统的团队,更可执行的判断是先测量任务完成率、无效轮询、失败后的恢复路径和人工升级频率,再逐步扩大并发;同时把环境隔离与外部访问测试作为上线条件。并发数可以展示负载,只有可复核的结果和明确的边界,才能说明系统是否真的适合研究工作。