OpenAI 研究组织跑到 3.1 Agent 工作日后，Builder 的瓶颈开始转移

OpenAI 研究组织已经跑到 3.1 Agent 工作日，Builder 的瓶颈开始转移#

OpenAI 在 2026 年 9 月 6 日公开了一组来自研究组织内部的数据。最值得关注的一项是，截至 8 月中旬，按标准 8 小时工作日折算，研究组织每 1 个“人类工作日”已经使用约 3.1 个 Agent 工作日。 这个数字很容易被写成“Agent 已经顶 3.1 个人”，但这不是原文的意思。OpenAI 统计的是 Agent runtime 与人类工作日的组织级折算。它说明 Agent 使用规模已经很高，不说明单个 Agent 的生产力是人的 3.1 倍。 真正值得看的，是工作流本身开始变化。 OpenAI 描述的研究人员正在更频繁地并发运行多个 Coding Agent。研究人员贡献代码更快，实验次数也在增加。与此同时，OpenAI 给出了一个很重要的限制：这些指标很容易测，但很难直接解释成“研究进展”。2026 年可用计算资源也在增长，而且当一部分工作被自动化后，剩下那些难自动化的环节会占据更多时间。 这正是 Agent 工程里最重要的变化。 过去我们讨论 Coding Agent，经常把问题简化成“它能不能把代码写对”。当 Agent 进入并发工作流后，问题会变成一组系统问题。 第一，任务怎么拆。一个大任务如果不能被拆成边界清楚、上下文独立的子任务，多开 Agent 只会增加冲突。 第二，执行怎么组织。Agent 需要知道代码、工具、权限、环境和前置结果。一个稳定的 Harness 要处理上下文装载、工具调用、并发、超时、重试、恢复和交接。 第三，结果怎么验证。Agent 可以很快地产生实现、实验和结论，但速度越快，验证压力越大。Eval 需要把“看起来能跑”变成明确的通过条件，包括测试、基准、回归、成本、延迟和失败模式。 第四，人做什么。人的价值会更多集中在定义问题、选择实验、判断证据、处理冲突和决定下一步。Agent 可以增加候选方案，但不会自动替你确定什么值得继续投入。 这也解释了为什么我认为 Harness 和 Eval 会成为 AI Builder 的基础能力。 Google 9 月 2 日总结 AI Agents Challenge 的优秀工程方案时，也出现了类似信号。双向 MCP、事件驱动并发、模型 fallback、分层路由，这些都不是“写一个更长 Prompt”。它们是系统设计。 开源 Agent Runtime 也在往这个方向收敛。Nous Research 的 Hermes Agent 已经把 Memory、Skills、Cron、Delegation、MCP、多执行后端和多平台入口放进同一个 Runtime。它说明市场需求正在从“一个会聊天的 Agent”转向“一个能长期运行和被管理的 Agent 系统”。 如果你是独立开发者，我会把接下来的学习顺序改成这样。 先把一个真实开发任务拆成可验证的子任务。然后让两个或三个 Agent 并发完成不同部分。每个任务都定义输入、允许调用的工具、完成条件和失败条件。最后用自动测试、静态检查、浏览器验证或人工审查做 Eval。 等这个流程稳定后，再考虑更多 Agent、更复杂的模型路由和更长的自动运行时间。 模型升级会继续发生。真正能复用的资产，是你的 Harness、Eval、任务模板、工具接口和失败恢复机制。 OpenAI 这组数据最有价值的地方，不是告诉我们 Agent 已经“替代”了多少人。它告诉我们，当 Agent 使用规模上去以后，瓶颈会移动。Builder 要开始为新的瓶颈设计系统。