OpenAI 万级 Agent 实测：36 小时消耗 1 万亿 Token，开发者该怎么读-字节棱镜 (Byte Prism)

最近 OpenAI 首次披露了一场 Agent 压力测试：上万 Agent 并发跑 36 小时不中断，累计消耗约 1 万亿 Token。这不是一次单模型跑分，而是 OpenAI 第一次把”Agent 系统级”的工业级负载公开——上万智能体同时在线、连续工作一天半、累计吞吐 1 万亿 Token，已经脱离了”对话式 AI”的算力量级。

对开发者来说，更值得关注的不是数字本身，而是数字背后的工程信号：模型怎么做到 36 小时上下文不爆、单 Agent 任务 Token 消耗到底有多高、以及这场实测背后 OpenAI 内部已经成型的新工作范式。

一、这场万级 Agent 实测，到底跑了什么

这场实测的关键不在于”跑了个新模型”，而在于 OpenAI 第一次按工业级负载来压 Agent 系统。上万 Agent 并发、连续运行 36 小时不中断、累计消耗约 1 万亿 Token——这三个数字放在一起，衡量的其实是一套 Agent 系统的稳定性、持续性和总吞吐，而不是任何单一模型的对话能力。

对比之下，1 万亿 Token 的量级就很清楚：传统 ChatGPT 形态的对话式 AI，单次交互的 Token 消耗通常在千到万级；而在 Agent 实测里，单 Agent 任务动辄消耗数十万到上百万 Token，是前者的十倍以上 [5]。把这两个量级放在一起看，1 万亿 Token 不是某个模型”答了很多题”，而是一整套持续作业的 Agent 系统跑下来的总吞吐。当 OpenAI 把这个量级的实测数据公开出来，等于正式把”Agent 系统级算力”作为一种新的评估维度摆上了台面——这把尺子一旦被官方背书，下游所有做 Agent 的团队都得跟着重新算账。

二、撑住 36 小时不中断的关键：模型会自己压缩上下文

让 Agent 连续工作 36 小时，最大的瓶颈是上下文窗口会爆。任何模型都有上下文上限，一个任务跑了几个小时之后，历史记录、工具调用结果、中间状态会迅速把窗口填满；填满之后再继续，要么截断历史丢失关键信息，要么直接报错退出。

OpenAI 撑住长时间任务的核心技术是 compaction（上下文压缩）：模型在接近上下文窗口上限时，自动对历史进行摘要压缩，把关键决策、当前状态、未完成任务保留下来，为后续工作腾出空间 [2]。这个机制看起来像一个”工程技巧”，但 OpenAI 给它的位置抬得很高——他们认为”能够持续进行连贯工作，是迈向更通用、更可靠 AI 系统的基础能力”[2]。换句话说，compaction 不是单纯让一个长任务能跑完，而是 Agent 系统能不能从”演示”走到”生产”的分水岭。这也是为什么 1 万亿 Token 这个数字能出现：没有 compaction，单 Agent 跑不到 36 小时；没有 compaction，1 万亿 Token 也无从积累。

三、1 万亿 Token 背后：Agent 时代的真实成本结构

算完账才会发现，”AI 帮我做一件事”和”Agent 帮我跑一个流程”在成本上根本不在一个数量级。

公开信息显示，复杂 Agent 单次任务的 Token 消耗可达数十万至百万级，相比传统对话式推理高出 10 倍以上 [5]。换句话说，今天一个企业级 Agent 流程跑一轮，等价于和一个聊天机器人来回对话几十上百轮。这个差距并不是哪个模型突然变贵，而是”持续工作”这件事本身的代价——历史越长、工具调用越多、状态越复杂，单次任务的 Token 消耗越往百万级靠拢。而这个代价，是按 token 计费的 API 设计和传统 SaaS 的成本模型里完全没有预留过的。

这意味着 Agent 商业化要回答的第一个问题，不是”技术上能不能做”，而是”Token 经济账算不算得过来”。一场单 Agent 任务消耗的算力成本，可能已经超过这条业务线一周的人力成本。这也解释了为什么 OpenAI 在另一条线拼命压基础模型的 API 价格——只有当单 Token 成本降到足够低，长时 Agent 才从 Demo 跨进生产。

四、OpenAI 内部的工程师，已经活在”Agent 分层”的新规则下

前 36 小时证明了模型层面的能力；更深一层的信号是 OpenAI 内部已经发生的变化。

OpenAI API 与开发者平台工程负责人 Sherwin Wu 近期在播客里给出了一组数据：95% 的工程师每天都在用 Codex，100% 的 PR 每天都会被 Codex 审查，代码评审时长从原来的 10～15 分钟压到 2～3 分钟；真正拥抱工具的工程师，PR 提交量比同事高出 70%，而且这个差距还在继续扩大 [1]。工程师越来越像「Tech Lead + 调度员」，同时盯着 10～20 条并行的 Codex 线程，主要工作变成引导、验收、兜底，亲手写代码反倒成了偶尔为之 [1]。

Sherwin 在同一场合还抛出一个判断：今天很多公司引以为豪的 AI “脚手架”——向量数据库、Agent 框架、复杂流程编排——可能只是一段过渡期的拐杖，模型进化会把它们吞掉。真正跑出来的团队已经换了打法：为模型将要到达的能力提前设计工作流，产品现在只有 80% 好用也能上线，等下一代模型升级，直接跨过那条门槛 [1]。

更深一层的变化在组织结构本身。AI 不会平均抬升所有人，会把高主观能动性的工程师推到一个”不成比例”的高度——能拆需求、能控上下文、能调度多 Agent、能把验证闭环做扎实的人，一个人就能顶过去一个小团队 [1]。OpenAI 已经在用 Agent 重写工程分层和团队结构，这场 36 小时实测只是把这种变化量化成可计算的算力规模。

五、给盯项目的开发者三条硬信号

第一，框架层面的架构决策，比语言层面的原始速度更重要。一个纯 Python 写的开源 Hermes Agent，通过三项工程优化把启动时间从 701ms 砍到 258ms，并在框架开销维度击败了用 Rust 写的 Codex [6]。这说明在 Agent 赛道，决定胜负的不是 Python 还是 Rust，而是缓存策略、懒加载、配置读取这些”看起来很土”的工程决策。

第二，现在该练的不是”怎么写 Agent”，而是”怎么让 Agent 跑得久不出错、上下文不爆”。compaction 是当前最关键的技术路径之一 [2]，但围绕它要做的事远不止模型本身——日志、状态持久化、出错恢复、上下文窗口的工程化预算，都决定着任务能跑 10 分钟还是 36 小时。

第三，提前为下一代模型”会吞掉什么”做减法。Sherwin 的判断已经给了方向：今天花大力气搭的脚手架，明年的模型可能直接绕过去 [1]。如果一款产品只在”等下一代模型升级后才有竞争力”，那现在的工程投入应该集中在工作流设计、用户场景和数据闭环上，而不是框架本身。

FAQ

这场万级 Agent 实测的原始数据 / 论文在哪里能看到？
目前 OpenAI 此次披露以官方说明和合作伙伴报道为主，尚未公开独立可引用的论文或 benchmark 页面。如需追溯细节，建议直接关注 OpenAI 官方博客及其工程团队成员在播客、社交平台上的进一步披露。

中小团队想复刻类似规模的 Agent 集群，在基础设施上需要满足哪些要求？
从这场 36 小时、1 万亿 Token 的实测规模倒推，至少有几条门槛无法跳过：足够稳定的模型推理后端（保证长时任务不中断）、可靠的上下文压缩与状态持久化机制（对应 compaction 这类关键能力 [2]）、可观测性体系（能在 Agent 跑几个小时出错时定位到上下文哪一段），以及配套的成本预算——单 Agent 任务动辄消耗数十万到上百万 Token，复刻万级并发意味着必须有专门的算力与计费规划 [5]。

普通开发者现阶段用 Codex 类工具，单次任务 Token 消耗大致在什么量级，成本怎么估算？
基于公开观察，复杂 Agent 任务的单次 Token 消耗在数十万到百万级，是普通对话的十倍以上 [5]。粗略估算时，可以把”一次完整 Agent 流程”按”几十到上百次普通 API 调用”的算力来预算，再按所用模型每百万 Token 的单价换算成实际成本。任务越复杂、需要保留的历史越长、工具调用越多，单次成本越往百万级 Token 靠拢。