核心结论
当模型平台把输入审核、输出审核和生成结果收敛到同一次请求里，安全控制就不该继续作为“旁路服务”存在。OpenAI 在 2026 年 6 月 4 日把 moderation scores 接入 Responses API 和 Chat Completions API，同一份官方文档还明确给出输入与输出审核结果的读取位置，并在安全最佳实践里把审核与人工监督列为生产默认能力。对 AI 全栈架构师来说，这意味着模型网关、Agent Runtime、审计日志和人工复核队列可以围绕同一条请求事务设计，而不是把审核留给另一个难以对账的异步链路。
技术背景
过去很多生成式系统把审核设计成两种割裂路径。第一种是请求前单独调用审核接口，只判断用户输入是否危险；第二种是请求后再做二次扫描，但生成结果、审核结果、工具调用和用户上下文往往已经分散到不同日志里。这种拆法在简单聊天场景还能勉强工作，一旦进入 Agent、工具调用、结构化输出或多模型路由，就会暴露出两个问题：一是决策证据分散，难以解释系统为何放行、拒答或升级到人工；二是安全判断无法稳定参与运行时编排，例如阻断工具执行、降级模型、切换模板或触发人工复核。
架构影响
第一，模型网关应把审核视为生成事务的组成部分，而不是外接插件。第二，Agent Runtime 需要把审核结果与工具调用计划、状态迁移和最终响应写入同一条 trace，才能在越权、误答或高风险请求发生时完整回放。第三，安全策略需要从“是否 block”扩展到“如何路由”：例如输入命中高风险类别时直接拒绝，输出命中中风险类别时进入人工复核，低风险但需留痕的请求则继续放行并记录分类分数。第四，审核能力一旦内联，前端、网关和后台作业就能共享同一套策略版本和审计字段，减少多套实现带来的漂移。
实现路径
- 统一请求信封：让模型请求对象同时携带用户输入、会话 ID、策略版本、租户上下文和审核配置，避免审核逻辑散落在不同中间件里。
- 把审核结果写进运行时状态：无论使用 Responses API 还是 Chat Completions，都应把输入与输出的
flagged、分类标签和评分落到统一审计结构，供日志、告警、人工队列和后续评测复用。 - 把审核结果接入编排决策：不要只把审核结果用来返回 403。更实用的做法是把它接到模型降级、工具熔断、回复模板切换、人工确认和租户级速率限制。
- 把工具调用放在审核之后：对会触发数据库写入、外部请求、文件操作或消息发送的 Agent，先判断输入风险和模型输出，再决定是否允许执行工具计划。
- 把人工监督做成显式分支：对高价值、高风险或高误伤代价的业务，审核命中后不要只给用户一个拒答，而要留下人工复核入口、原因码和可回放证据。
风险边界
内联审核不会自动替代领域策略。审核分数是运行时信号，不是最终政策；同样一条命中结果，在医疗、教育、金融和内部 Copilot 场景里可能对应完全不同的处理动作。另一个边界是，审核与生成共事务会提升可观测性，但并不自动解决工具参数注入、越权资源访问或供应链风险，这些问题仍然需要最小权限、参数校验、审批和沙箱来补足。最后，任何把审核结果直接等同于“可安全执行工具”的设计都过于乐观，因为安全文本输出和安全副作用并不是同一件事。
验证清单
- 输入审核、输出审核、模型响应和工具计划是否共享同一请求 ID 与 trace ID。
- 审核命中后，系统是否区分拒绝、降级、人工复核和继续放行，而不是只有单一阻断动作。
- 分类标签、评分、最终策略决定和人工处理结果是否能落到统一审计记录。
- 高风险工具是否严格依赖审核与审批结果，而不是仅依赖模型“自觉”不调用。
- 回归评测中是否覆盖越权请求、危险指令改写、边界模糊输入和安全拒答误伤。
- 当审核服务不可用、超时或返回异常时，系统是否有明确的 fail-close 或分级降级策略。
采用建议
优先把这套模式用在带工具调用、外发消息、数据库写入或高价值工作流的 Agent 与应用网关上，因为这些场景最需要“安全判断和执行决策同事务”。如果团队还停留在简单问答阶段，可以先从统一审计字段和人工复核队列开始；一旦系统进入多步骤编排或多租户运行，最好尽快把审核能力前移到主请求链路，否则后续的安全治理、事故复盘和责任界定都会越来越贵。