Codex 扩展至所有角色：六款角色插件、Sites 功能与 500 万周活跃用户对 AI 路由架构的意义

OpenAI Codex 已跨越一个改变路由计算方式的门槛：截至 2026 年 6 月 2 日，其每周活跃用户超过 500 万——其中约 20% 并非开发者。分析师、营销人员、销售团队、产品设计师、投资者、银行家等非技术角色的增速超过开发者群体的 3 倍。Codex 已悄然转变为多角色编程智能体平台，这一转变对任何在 gateway 背后路由请求的团队都有直接影响。

发生了什么

OpenAI 在单次更新中发布了三项新能力：

六款角色专属插件。 每款插件都捆绑了与特定角色相关的应用、技能、指令和工作流，共整合 62 款主流应用和 110 项独立技能：

• 数据分析 — Snowflake、Databricks Genie、Hex、Tableau
• 创意制作 — Figma、Canva、Shutterstock、Picsart、Fal
• 销售 — Salesforce、HubSpot、Slack、Outreach、Clay
• 产品设计 — Figma、Canva；支持从在线 URL 制作原型
• 股权投资 — Moody's、FactSet、LSEG、S&P、PitchBook、Hebbia
• 投资银行 — 路演材料制作、可比公司分析、尽职调查工作流

这些插件已在 GitHub 上开源，支持团队扩展或替换，以构建自定义工具链。

Sites（企业版/商业版预览）。 Codex 现可根据提示词生成、托管并提供交互式 Web 应用服务——包括仪表盘、情景规划器、项目看板、客户评审中心等，并通过 URL 在工作区内共享。底层部署栈涉及 Vercel、Wix、Replit、Lovable、Figma、Webflow 和 Emergent 等早期合作伙伴。

批注（Annotations）。 开发者此前用于精炼代码和 Markdown 的内联编辑功能，现已延伸至 Codex 生成的文档、电子表格和幻灯片。用户选中一个区域并描述需要修改的内容，Codex 便会将编辑范围限定于该区域。

对 AI 工程团队的意义

从单一开发者场景扩展至多角色，带来了大多数团队尚未针对性设计的复合路由挑战。

上下文预算因角色而大相径庭。 软件工程师要求 Codex 重构一个函数，其上下文窗口边界清晰、可预测：代码文件、测试覆盖率、lint 输出。而投资银行家要求 Codex 准备路演材料，单次会话可能涉及财报记录、CRM 数据、10-K 报告 PDF、可比公司表格以及幻灯片模板——token 占用量、上游延迟敏感度以及 provider 中途断连的失败成本都截然不同。

工具调用模式非线性增长。 每款角色插件都引入了独立的工具集：一次销售插件会话可能在单次对话中调用 Salesforce、Slack 和 HubSpot；一次数据分析会话可能依次执行 Snowflake 查询、渲染图表并生成摘要。这将改变 gateway 侧 API 流量的形态。按 token 统一计费会低估多工具角色的实际算力成本；按工具调用次数或会话复杂度计费将成为可行的替代方案。

Sites 引入了全新的异步工作负载类型。 根据提示词生成交互式站点并非单次 chat completion，而是一条多步流水线：设计、代码生成、资源打包、部署。若你的路由层当前已处理 Codex 流量，则应预期出现一类新的长周期任务——其结构更接近 /v1/jobs/:id 异步模式，而非标准 /v1/chat/completions 响应。

模型选择问题已转变为按角色区分。 运行 Canva 集成和图像生成的创意制作团队，与运行财报记录分析的金融团队，在延迟与质量之间的权衡截然不同。若你将所有 Codex 流量路由至同一上游模型，很可能对某些角色过度消费，而对另一些角色供给不足。

路由与运营视角

六款角色插件的发布，标志着平台层正在吸收此前运营商需手动处理的工作负载差异化问题。OpenAI 将应用集成、系统提示词、工具定义和技能库打包成预置插件。对运营商而言，这意味着一个转变：从模型路由（哪个模型处理此请求？）转向工作负载路由（哪个插件上下文、模型层级和计费桶拥有这个会话？）。

路由策略中需重点关注的三个变化：

1. 会话级成本归因。 当单次 Codex 会话跨越分析、文档撰写、幻灯片制作时，token 成本属于同一会话，但在概念上跨越不同任务类别。按角色插件而非仅按模型进行成本归因，将成为企业内部成本分摊的正确计量单位。

2. 各集成的工具调用速率限制。 Salesforce、HubSpot 和 Snowflake 各有其 API 速率限制。若你的 gateway 正在代理 Codex 插件的工具调用流量，需要在会话级别对每个集成进行速率限制监控，而不仅仅是按用户或按组织统计。

3. Sites 产生的流量是新的部署信号。 Codex 部署一个站点后，该站点的下行负载将随用户采用情况增长——而非随提示词节奏变化。这种不对称性（单次提示词生成大量下行请求）值得现在就在可观测层中标记，而不是等 Sites 流量规模化之后再处理。

TheRouter 用户应关注或尝试的事项

若你正通过 TheRouter 路由 Codex 或 ChatGPT 流量，建议采取以下步骤：

• 按角色上下文为会话打标签。 若用户正在添加 Codex 角色插件，可在路由标签或元数据字段中加入插件类型标识。这将为未来按角色进行模型选择或成本控制提前做好准备。
• 针对长周期会话审视计费模型。 Sites 和多工具分析会话产生的 token 量将超过普通 chat completion 计费的典型值。请确认当前的按请求计费模型能否准确捕捉长会话的实际算力消耗。
• 监控异步任务模式。 Sites 流水线是智能体任务向后台异步完成这一更大趋势的缩影。若你的路由遥测尚未追踪 /v1/jobs/:id 风格的异步模式，现在是接入监控的好时机。

完整插件源码已发布至 GitHub 上的 openai/role-based-plugins 仓库。