Agent Router Codex：长程 AI 工作需要策略通道

OpenAI 最新的 Codex 使用研究，与其说是一次生产力展示，不如说是一个架构提醒：当 Agent 从聊天回答变成被委派的工作单元，API 运营就必须管理时长、并行度、身份和成本归属。被路由的不再是一次模型调用，而是一个可能运行数分钟到数小时、调用工具、跨越文件并带来业务风险的任务。

发生了什么

OpenAI 发布了经济研究文章《How agents are transforming work》，基于 Codex 在个人用户、组织用户以及 OpenAI 内部员工中的使用情况。几个数字很直接：到 2026 年 5 月，80.6% 的抽样个人用户至少发起过一次预计超过 30 分钟人工工作量的 Codex 请求，70.2% 发起过一次超过 1 小时的请求，25.6% 发起过一次超过 8 小时的请求。

在 OpenAI 内部，Codex 已从编程工具变成主要的 AI 工作界面。OpenAI 表示，包括 Legal、Finance、Recruiting 在内的所有部门，现在都把 Codex 作为主要 AI 工具。对平均员工而言，Codex 占其输出 token 的 85% 以上；在内部每周输出 token 总量中，这一占比被报告为 99.8%。非开发者采用速度尤其快：自 2025 年 8 月以来，个人用户中的非开发者增长 137 倍，组织用户中的非开发者增长 189 倍，OpenAI 内部增长 12 倍。

最重要的运营信号是并行度。OpenAI 称，到 2026 年 6 月，第 99 百分位用户每天经常产生超过 60 小时的 Codex Agent turn，并分布在多个并行 Agent 上。这已经不是聊天工作流，而是一支小型 Agent fleet。

为什么对 AI 工程团队重要

这项研究给正在采用 Codex、Claude Code、Cursor、Kimi Code 或其他 Agentic workbench 的团队一个现实提醒：Agent 需求不会停留在开发部门。一旦工具可以把杂乱文件、重复分析和轻量自动化变成完成品，legal、finance、recruiting、support、operations 团队都会开始使用。

这会改变控制问题。编程团队往往可以接受高上下文模型、较宽的仓库访问和较大的 token 消耗，因为结果会在 PR 中被审查。但招聘或财务工作流可能需要更严格的文件访问、更低的数据留存风险、更清晰的人工批准，以及不同的预算归属。如果这些工作流共用同一个 provider key 和同一个默认模型，公司就很难回答谁花了钱、哪些任务需要高价路由、哪些工具调用越过了策略边界。

它也改变了容量规划。长程任务会带来排队、重试和并行突发。在一小时 Agent 运行中遇到 provider 故障或 rate limit，比一次 chat completion 失败代价更高，因为它可能浪费中间状态、丢失上下文，或让业务流程半途停住。

路由与运维视角

Router 的决策应从“哪个模型最好”转向“哪个任务类别应该进入哪条执行通道”。一个可用策略至少包含四个维度。

第一，按任务时长路由。短问答、30 分钟委派任务和多小时 Agent 运行，不应共用同样的 timeout、retry 和 fallback 假设。第二，按影响半径路由。只读综合可以使用更宽的 fallback；但会写文件、开 PR 或触碰私有业务数据的任务，需要更严格的 provider 和工具限制。第三，按部门预算路由。Legal 分析 Agent 和 CI 修复 Agent 都可能使用 Codex 式执行，但成本中心和审计轨迹应不同。第四，按状态性路由。如果 Agent session 累积 memory、checkpoint 或环境状态，fallback 就不再只是第二次模型调用，而是一次 continuation strategy。

这也是 OpenAI-compatible routing layer 不再只是便利包装的地方。使用 TheRouter docs 的团队应把 Agent 工作视为受治理 workload：按团队拆分 API key 或 virtual provider，按任务类别标记 traffic，显式配置 fallback，并在运行结束后做成本核对，而不是只在请求时数 token。

TheRouter 用户应关注或尝试什么

可以把 OpenAI 的数字当成自己 Agent rollout 的压力测试。如果你公司里的非开发者 Agent 使用量增长 100 倍，你的 gateway 能回答这些问题吗？

• 哪个部门承担并行 Agent run 的成本？
• 哪些任务类别可以 fallback 到更便宜的 provider，哪些必须因为质量、隐私或工具兼容性留在特定 provider？
• 长程 Agent 运行 45 分钟后撞上 provider limit 时，会发生什么？
• 你能否区分只读综合任务，以及会写代码、编辑文档或调用外部系统的工作流？
• 日志是否保留了足够的 request、tool 和 user context，既能 debug 结果，又不会暴露敏感文件？

下一波 Agent 采用看起来不会只是购买更多聊天席位，而更像是在运营一支 fleet。真正跑赢的团队，不会简单地给每位员工最强模型；他们会为长程工作定义通道，把预算和审批绑定到这些通道，并在第一张失控的 Agent 账单出现之前，就让 provider fallback 保持可见。