OpenAI API 内联 Moderation 评分上线:零延迟安全信号对多 Provider 路由架构意味着什么

OpenAI 现支持在 Responses API 单次调用中同时返回用户输入和模型输出的 moderation 评分。对多 provider 路由团队来说,这消除了独立安全检测的额外请求,并改变了网关层内容治理的设计方式。

发布于 来源 OpenAI Developers Changelog

归档条目:由 AI 根据所引信源辅助生成,发布时未经逐篇审阅。责任编辑:Joe Werner。

API 路由架构中内容安全评分流转示意图

OpenAI 6 月 4 日的 API Changelog 新增了工程团队期待已久的功能:通过在单次生成请求中携带 moderation 对象,可以同时获取用户输入和模型输出的 omni-moderation-latest 评分——无需额外请求。此变更适用于 Responses API 和 Chat Completions API。

对于构建或运营多 provider 路由层的团队而言,这不仅是一个便利特性,更是一种可直接嵌入生成路径的新型安全信号。

发生了什么

从 2026 年 6 月 4 日起,任何生成请求都可以携带 moderation 对象:

{
  "model": "gpt-5.5",
  "input": [{"role": "user", "content": "..."}],
  "moderation": {"model": "omni-moderation-latest"}
}

响应结构包含 response.moderation.input 和 response.moderation.output,每个对象均含有 flagged、categories 和 category_scores,与独立 moderation endpoint 的返回格式完全一致。关键细节:

  • 免费:moderation 模型不产生额外费用。
  • 双向检测:同时获取用户 prompt 和模型输出的评分,即使输入内容正常,也能捕获有问题的生成内容。
  • Tool-call 感知:moderation 覆盖对话内容中的 tool-call 参数和输出,但不涵盖 tool 名称、schema 或 response-format schema。
  • Streaming 限制:moderation 结果在完整输出生成后返回,不包含在 partial delta 中。
  • 错误处理:moderation 无法完成时,对应字段返回错误对象而非评分。

moderation 模型在 OpenAI 侧与生成并行执行,实际延迟开销接近于零。

为什么对 AI 工程团队重要

此前,希望对 API 输出进行内容审核的团队有两种选择:(a) 生成后单独调用 /moderations,增加约 200-400ms 的额外请求;(b) 自建分类器 pipeline。前者在批处理场景还能接受,在实时对话和 coding-agent 用例中则明显拖慢链路。后者需要维护独立的模型部署。

内联 moderation 将两种路径合并为单次 API 调用。对于纯 OpenAI 的架构,迁移成本极低——只需在请求 JSON 中多加一个字段。但对于多 provider 路由架构,含义更为深刻。

Router/Operator 视角

此次变更引入了一个目前竞争 endpoint 上尚不存在的 provider 专有信号,这给路由层运营商带来了三个具体决策点:

1. 跨 provider 的安全信号碎片化。 OpenAI 现在能在请求内联返回结构化 moderation 评分。Anthropic 返回 stop_reason: "refusal",但不提供分类详情。DeepSeek、Qwen/DashScope 以及大多数国内 provider 则两者都没有——要么静默拦截,要么返回错误。如果你的路由层需要执行统一的内容安全策略,你无法假设每个 provider 都返回相同的数据。核心问题变成:是将不同 provider 的异构安全信号(拒绝原因码、内联 moderation、自建分类器)规范化为统一评分,还是在每次输出上统一跑一遍 provider 无关的安全 pass?

2. 生成后的路由决策。 有了内联评分,网关现在可以在生成之后再做路由决策。如果 GPT-5.5 返回了被标记的输出(例如 violence 评分 > 0.8),网关可以自动以更严格的 system prompt 重试、切换到不同的模型层,或上报人工审核——全部在同一次请求生命周期内完成。这是一种此前缺乏清晰 API primitive 支持的新模式。

3. 审计记录与合规对齐。 内联 moderation 使你能以零额外调用的方式获得每次请求和每次响应的安全审计记录。对于须遵循 EU AI Act 或同类治理框架的企业团队,这是构建可信审计日志的最低成本路径:每次生成在 API 层即附带安全评分,零额外延迟和费用。

注意:这些评分仅在直接路由至 OpenAI 时生效。如果你的网关代理的是不返回内联 moderation 的 provider,则什么都拿不到。这构成了一种轻度 provider 绑定信号——并非因为该功能是专有的,而是因为其他 provider 尚未推出等价实现。

TheRouter 用户应关注什么

如果你的路由策略包含内容安全门控,且流量会路由至 OpenAI,则内联 moderation 的新 primitive 值得集成。核心问题在于:你的网关应把 moderation 对象视为透传的可选扩展字段,还是把跨 provider 的安全信号规范化为统一策略层。

对于使用 TheRouter OpenAI 兼容 endpoint 的团队:moderation 参数会透传至上游 provider,当上游为 OpenAI 时可获得评分;当上游是不支持内联 moderation 的 provider 时,该字段被静默忽略——不报错,但也没有评分返回。这一点值得监控:随着更多 provider 推出等价 primitive,你的路由层将自然成为聚合安全信号的最佳位置。

值得持续关注的方向:

  • Anthropic、Google 或 DashScope 是否会在未来 6 个月内推出等价的内联安全信号。
  • 合规团队是否要求每次响应均有安全评分——若是,内联 moderation 目前只覆盖一个 provider。
  • OpenAI 是否会将 moderation 模型扩展至音频输入(目前仅支持文本和图像)。
编辑风格插图,展示分叉的 API 路由路径,其中标有 agents sessions 的分支偏离主网关,背景为低饱和深色调

OpenAI Agents API 公测:网关运营商需要正视的新绕道路径

OpenAI 的 Agents API 公测版引入了 client.beta.agents 这个独立命名空间,它根本不经过 /v1/chat/completions。对于通过 AI 网关路由流量的团队来说,这意味着账单盲区、缺失的审计记录,以及一个需要单独管理的 API key 权限范围。

来源 OpenAI
帮助与联系