OpenAI 披露 3.1 个 Agent 工日：AI 中转站该如何管理并行任务成本

OpenAI 披露 3.1 个 Agent 工日：AI 中转站该如何管理并行任务成本

OpenAI 在 9 月 6 日发布的研究文章中给出了一组罕见的内部使用数据：到 8 月中旬，其研究组织中位数研究员每天使用 Agent 的 API 标价推算超过 600 美元，使用量位于前 10% 的研究员超过 7000 美元；全部 Agent 运行时折算为每一个人类八小时工作日对应 3.1 个 Agent 工日。文章还说，越来越多人在一天内运行四个或更多 Agent。

这些数据来自前沿实验室研究场景，不是普通团队的预算建议，也不能推导出并行越多越好。它们有价值，是因为把一个常被忽略的变化量化了：当 Agent 同时读代码、跑实验、查资料和等待工具结果，成本与风险不再主要由单次聊天决定，而由整组任务的调度方式决定。只看模型单价或按人头订阅的管理方式，很快会失去解释力。

并行带来的不是四倍效率，而是一组新的排队问题

并行 Agent 适合依赖较少的工作，例如同时调查三个故障原因，或让一个准备测试、一个阅读历史、一个梳理接口契约。它能缩短等待，也可能让同一份大上下文、同一个 MCP 工具和同一套测试资源被重复占满。若四个 Agent 都从头扫描仓库，再把相似结论交给主 Agent 汇总，输入 Token 和工具调用会先于产出成倍增加。

任务拆分的质量因此比并发数更重要。每个子任务应有明确问题、允许读取范围、预期产物和截止条件；主任务只接收必要证据，不收集长篇转述。对代码库和知识库，优先给子任务精确文件、检索结果或版本号，减少请先理解整个项目之类的宽泛指令。已经没有新增信息的子任务应尽早停止，而不该因为已经启动就持续消耗预算。

共享资源会形成隐蔽瓶颈。数据库、浏览器自动化、CI 队列和外部 API 都有速率限制；并行度过高时，Agent 可能把限流或超时误判为业务错误，随后进入重试循环。网关日志若只记录模型名称和总 Token，很难判断问题来自模型、工具还是排队。请求链路 ID、父子关系、工具耗时、重试原因和最终状态应当被关联保存。

预算要跟着任务走，不能只跟着账号走

一次长任务的输入会随上下文累积，输出之外还有推理、工具结果、缓存写入和失败重试。对大模型 API 中转或统一模型网关而言，预算不应只有每次最多 Token，还要覆盖一个任务树能启动多少子任务，每个子任务可持续多久，以及失败后最多重试几次。没有这些上限，任何看似小的自动化都可能在后台扩张。

较实用的做法是设置分级预算闸门。起步只允许低成本调查与规划；获得复现证据、定位模块或测试计划后，才允许启动更多 Agent、调用更强模型或执行昂贵工具。账号级月度额度仍然必要，但它只能阻止总额失控；项目或工作流级预算更接近责任，可以说明谁发起、目标是什么、是否成功、花费是否合理。

在多个模型间切换也需要被记录。轻模型负责分类、检索或格式化，高能力模型处理复杂诊断，并不天然降低费用；若升级条件不清晰，低能力路径失败后再全量重做，成本可能更高。团队应以固定任务比较不同路由策略的完成率、总时延、人工返工和总费用，并让独立模型或人工审阅关键判断。

用任务账本把模型调用变成可追溯运营

AI 中转站容易提供统一 Key、模型入口和账单视图，但 Agent 还需要任务账本。每个请求应带上项目、环境、任务类型和父任务标识；工具调用保存允许范围、结果摘要和失败原因；任务结束时写下通过的验收信号。这样既能按团队结算，也能在异常飙升后追到具体的提示、工具或重试策略。

告警也不宜只盯日消耗。更早的信号包括同一任务反复读取相同材料、子任务数突然增加、工具错误率上升、缓存命中下降、测试持续失败却仍在写入。对这些信号设置暂停或降级，比等账单出来再追责有效。涉及安全、合规和生产数据时，暂停应保留人工接管入口，而不是把长任务直接丢弃。

3.1 个 Agent 工日不是该追逐的目标，它只是提示 AI 工作量已经能够同时增长、同时出错、同时消耗。先为一条可验收工作流建立任务 ID、预算、工具权限和结果记录，再逐步增加并行度，通常比直接追逐多 Agent 数量更稳。需要集中观察自建应用模型调用、项目预算与降级策略的团队，可以在 [AnyAIS 控制台](/dashboard) 用独立 Key 跑出自己的任务账本，再决定哪些并行流程值得扩大。

来源：[OpenAI：Research acceleration: The view inside OpenAI](https://openai.com/index/research-acceleration-view-inside-openai/)（2026-09-06）。