Third Moment Research 让一万个 AI 智能体连续运转 36 小时以上

OpenAI 在 2026 年 10 月 14 日发布了一篇客户案例，介绍 AI 实验室 Third Moment Research 的做法。这家实验室同时运行一万个 AI 智能体，并让它们连续工作 36 小时以上。它使用的模型和工具包括 GPT-6 Astra、GPT-6.1 Sol、Codex，以及面向网络安全场景的 Daybreak。按照原文的概括，实验室的目标是打造能持续专注数天、并且在使用过程中不断改进的智能体。这里有两个关键数字，一个是规模，一万个并行的智能体。另一个是时长，超过一个半工作日的连续运行。两者放在一起，已经不是常见的单人对话式助手，而是一套需要调度、监控和回收结果的生产系统。需要说明的是，公开摘要没有给出每个智能体的具体任务、成功率或成本，所以下面的讨论建立在已知事实和行业常识之上，不对未披露的细节做断言。

这件事的难点不在把模型调用一万次，而在让每一次调用在很长的时间线上不跑偏。短任务里，模型只需要在一个上下文窗口内完成推理。任务拉长到数十小时，问题就变了。上下文会被工具输出和中间步骤塞满，早期的目标容易被稀释。某一步的小错误会被后续步骤放大。外部环境，比如依赖库、网络接口和文件状态，也可能在运行中发生变化。要撑过这么久，系统通常需要几类机制：把计划和进度写到外部存储，而不是只留在对话里。定期压缩或重置上下文，再从记录中恢复。为每个步骤设置可验证的检查点。出错时能回滚或重试。从模型分工上看，Astra 与 Sol 两个版本很可能承担不同角色，比如一个偏重规划与判断，另一个偏重高吞吐的执行，这是合理推断，原文摘要并未明说。Codex 代表代码智能体，意味着智能体不只是写文字，而是能直接读写代码、运行命令、查看结果，这让任务本身带有可检验的信号。Daybreak 面向网络安全，说明这套长时运行方法也被用在漏洞发现、防御分析这类需要反复试探、耐心很强的工作上。至于使用中不断改进，较可能的实现方式是把成功与失败的轨迹沉淀成可复用的经验、提示或工具，而不一定是更新模型权重。

对行业来说，这个案例有几层含义。首先，竞争的焦点正在从单次回答的质量，转向在长时间、多步骤任务里的可靠性。谁能让智能体连续跑两天仍然不偏题，谁就更接近能替代一部分研究员和工程师的工作量。其次，编排能力变得和模型能力同样重要。一万个并行智能体需要任务队列、资源配额、失败重试、结果去重和审计日志，这些都是传统分布式系统的老问题，只是现在执行单元换成了会自己做决定的模型。拥有成熟基础设施的团队，在这个方向上会有明显优势，而只会调用接口的应用层公司，门槛会越来越高。再次，对代码智能体赛道而言，长时运行意味着产品形态从在编辑器里补全代码，变成交给它一个目标，几小时后回来验收。这会和其他编程助手、自动化测试平台、安全扫描厂商形成直接竞争。网络安全一侧的影响更敏感：同样的持久、并行能力既能帮防守方更快地排查漏洞，也可能被攻击方利用，所以访问控制、使用审查和责任划分会成为产品设计的一部分。最后，对企业用户来说，成本和可控性将成为采购时的核心问题。一万个智能体跑一天多，算力开销不小，必须有清晰的终止条件和预算上限，否则很容易出现无效消耗。

接下来值得关注的信号有几个。第一，原文是否会披露更具体的评估数据，例如任务完成率、人工介入的频率、单位任务成本，以及与短时运行方案的对比。没有这些数据，很难判断 36 小时这个数字是能力上限，还是一次展示。第二，使用中不断改进的机制是否会标准化，比如形成可共享的技能库或经验库，让一个智能体学到的东西能被其他智能体复用。第三，运行时间能否从一两天延伸到一周甚至更长，同时错误率不随时间明显上升，这是检验长时可靠性的硬指标。第四，监管与安全层面的反应。当智能体能自主、持续地执行网络安全相关操作时，审计、权限隔离和人工审批点如何设计，会影响这类产品能否进入大型企业和政府场景。第五，同类实验室和云厂商是否会跟进相似的规模演示，从而把一万个并行智能体变成行业常见的基准。总体来看，这个案例传递的方向很清晰：智能体正在从演示走向需要长期运维的工程系统，真正拉开差距的，会是稳定性、编排和安全治理，而不只是模型本身的聪明程度。