deepseek harness大模型网关“敏感内容拦截“谜案：元凶竟是 OpenAI 的 developer 角色（附国内厂商接入工程经验）

aiAIman

322人浏览 · 2026-08-16 10:39:31

aiAIman · 2026-08-16 10:39:31 发布

"敏感内容"是它的借口：大模型网关连 “hi” 都拦，真凶竟是 OpenAI 的 developer 角色

摘要：接入国内大模型网关后，一切正常；直到我给模型配置了"思考深度"，从此每个请求都被同一个理由拒绝——“抱歉，系统检测到您当前输入的信息存在敏感内容，我无法响应您的请求，请检查后重新输入”。折腾一天，真凶落网：不是内容敏感，而是客户端把系统提示词发成了 developer 角色，而国内网关只认 system。本文完整复盘排雷现场，并沉淀一条所有 AI 工程人都会用到的经验：非 OpenAI 官方的网关，一律显式配置 supportsDeveloperRole: false。

TL;DR（先存这张图再往下看）

一句话结论：
不是你的内容敏感，是客户端把系统提示词发成了 developer 角色，国内网关只认 system。

一句话修法：
compat 里显式加 supportsDeveloperRole: false。

一句话原则：
非 OpenAI 官方网关，一律显式加；不要依赖客户端的自动探测。

一、离奇现场：写完配置，网关开始"装受害者"

我的智能体框架（DSH，底层通过 pi-ai 对接 OpenAI 兼容协议）里接了几个国内模型网关：商汤日日新、阿里云百炼都正常，唯独其中一个网关频繁报错，报错文案还特别"委屈"：

抱歉，系统检测到您当前输入的信息存在敏感内容，我无法响应您的请求，请检查后重新输入。

配合客户端的错误信息：

Provider finish_reason: content_filter
PI_AI_ERROR

乍一看，铁证如山——内容审核拦截，没什么好说的。

但注意两个极其诡异的细节：

报错时间点：问题恰好出现在"写完一份带 reasoningEfforts（思考深度档位）的模型配置"之后。写之前约 20 次请求全部正常，写之后每一个请求都被拦。
内容完全无辜：被拦的请求里没有任何违规内容，纯粹是正常的代码、配置、日常对话。

第一反应难免被带偏：“是不是配置里的 IP 端口、Key 名之类的字符串被’指纹识别’了？”——后来证明，这个方向浪费了至少三个小时。

二、排雷过程：三个决定性证据

证据一：0 token —— 模型根本没被调用

回放被拦请求的完整链路日志：

text-delta: "抱歉，系统检测到您当前输入的信息存在敏感内容……"
usage: {"inputTokens": 0, "outputTokens": 0}
finish: content_filter

input/output token 全部为 0。审核如果真在审查"生成内容"，模型得先吐字才有东西可审；而现在模型压根没机会开口，网关在收到请求后 1 秒内直接短路返回了模板文案。

结论：这是一个快、确定性、与生成内容无关的前置检查。

证据二：1 秒短路 —— 审核不看内容，看"形态"

所有被拦请求的响应时延都在 1 秒左右（正常对话要十几秒），且返回的模板文案逐字相同。这不是把内容送进审核模型的节奏，这是规则引擎对请求结构打钩的节奏。

证据三：角色对照实验 —— 连 “hi” 都拦

对网关做了一组只有"角色"不同的对照请求：

请求	结果
`[{"role":"developer","content":"hi"}]`	❌ 拦截（敏感内容模板 + content_filter）
`[{"role":"system","content":"You are an AI agent."}]`	✅ 正常
`[user] + [role=developer]`	❌ 拦截
`[user] + [role=system]`	✅ 正常

拦的不是内容，是角色。连 "hi" 都拦——"内容审核"只是它的名义理由，真正的开关是消息的 role 字段。

三、真凶认罪：一行 if 引发的血案

继续翻客户端源码，pi-ai 决定系统提示词用哪个角色，只有一行判断：

// pi-ai dist/api/openai-completions.js
const useDeveloperRole = model.reasoning && compat.supportsDeveloperRole;
const role = useDeveloperRole ? "developer" : "system";

完整因果链：

我声明了 reasoningEfforts（想自定义每个模型的思考深度）
        ↓
客户端把该模型标记为"推理模型"：model.reasoning = true
        ↓
自动探测：未知网关一律默认"支持 developer 角色"
        ↓
系统提示词角色：system → developer
        ↓
国内网关的兼容层只认 system、不认识 developer
        ↓
网关按自己的方式拒绝：有的扮"敏感内容"，有的报"Request extraction failed"

两个背景知识补全拼图：

developer 是 OpenAI 在 2025 年才为推理模型引入的新角色，国内厂商的兼容层绝大多数尚未跟进；
客户端对未知 URL 的自动探测过于乐观——只对内置已知厂商做特殊处理，其他一切 URL 都默认"支持 developer"。

这也解释了为什么问题在"写完配置"那一刻才爆发：写 reasoningEfforts 之前，model.reasoning=false，系统提示词一直是人畜无害的 system 角色；写入之后，角色升级为 developer，网关六亲不认。

你以为撞上的是"内容指纹"，其实撞上的是"协议指纹"。

四、同一条根因，各家的"拒绝演技"盘点

网关	拒绝方式	表面看起来像什么
OpenAI 官方 API	✅ 原生支持 developer 角色	——
商汤日日新 SenseNova	`400: {"message":"Request extraction failed","type":"invalid_request_error","code":"BadRequest"}`	请求解析失败 / 参数错误
阿里云百炼（兼容模式端点）	对 developer 角色同样报请求级 4xx	非法请求
某国产中转网关（匿名）	流式返回"抱歉，系统检测到您当前输入的信息存在敏感内容……"，`finish_reason=content_filter`，usage=0	内容安全审核（伪装性拉满）

划重点：同一条根因，不同厂商的拒绝文案天差地别。 尤其"敏感内容"这种说法会把排查方向彻底带进沟里。遇到 4xx / content_filter，第一反应应该是核对请求的 wire 格式（角色、字段），而不是审查内容。

五、一行修复，立竿见影

在提供方配置的 compat 块里显式补一行：

# DSH settings.yaml
llm-pi-ai:
  providers:
    my-provider:                       # 你的自定义路由
      displayName: 我的模型网关
      apiKeyEnv: XXX_API_KEY
      api: openai-completions
      baseURL: https://your-gateway.example.com/v1
      compat:
        thinkingFormat: openai
        supportsReasoningEffort: true
        supportsDeveloperRole: false   # ← 非 OpenAI 官方网关，务必显式加这一行
      models:
        - id: some-model
          name: some-model
          maxTokens: 64000
          reasoningEfforts:
            off:
            low: low
            high: high
            max: max

三个要点：

这是客户端 schema 官方支持的合法配置项（supportsDeveloperRole: z.boolean()），不是改源码、不是 hack；
配置热加载生效，无需重启；
修好后系统提示词恢复 system 角色，连之前"被污染"的旧会话也能正常续跑——历史和内容从来不是问题。

修复后的对照验证（同样的历史、同样的内容，仅角色变化）：

修复前：payload[0].role = developer  →  拦截
修复后：payload[0].role = system     →  正常完成

六、值得收藏的三条工程经验

① 国内 / 自建 OpenAI 兼容路由，一律显式 supportsDeveloperRole: false。
不要依赖客户端自动探测——它对未知端点默认"支持"，而国内网关普遍不支持。

② 开启"推理 / 思考"配置会触发一整套适配副作用。
reasoningEfforts 不只是多传一个参数，还会连带切换系统提示词角色、改变 effort 传递方式。改完配置，要确认的是最终发出去的 wire 格式，而不是"配置有没有写入成功"。

③ 报错文案 ≠ 根因。
服务器只展示它拒绝的"方式"，永远不会告诉你它拒绝的"原因"。先看请求形态，再排内容——顺序反了，浪费一天。

附：一分钟自查清单（截图收藏版）

□ 被抓包的请求：[0] 的 role 是 developer 还是 system？
□ 模型配置里声明了 reasoningEfforts 吗？
□ 提供方是 OpenAI 官方吗？不是 → 显式写 supportsDeveloperRole: false
□ 被拦时 usage 是 0 吗？（0 = 前置短路，与生成内容无关）
□ 报错文案像"内容审核"吗？（先别信，先看角色字段）