Azure OpenAI 的 Content Filter：当 Safety Theater 阻碍真实工作

Source: Dev.to

问题

在为函数调用定义工具时，某些词语会触发 Azure 的内容过滤器，即使上下文完全无害：

• run script → 被阻止
• click element → 被阻止
• fill form field → 被阻止

这些都是任何浏览器自动化工具（Playwright、Puppeteer、Selenium）的标准操作。Azure 的过滤器将它们视为威胁。

变通办法

解决方案非常简单：使用中性同义词。

使用相同意图的中性语言即可瞬间通过。

为什么重要

过滤器会把工具名称和描述作为提示的一部分进行筛选。它是基于关键字的模式匹配，而不是分析实际风险。一个名为 clickElement、用于自动化表单提交的工具会被阻止，而同样功能的工具如果改名为 activatePageItem 则可以通过。过滤器并未提供额外的安全性——它只是迫使开发者使用委婉说法。

与 Google Gemini 的比较

在 Google 的 Gemini 模型上测试相同的工具定义时，使用过程性措辞毫无阻力。工具能够如预期工作，无需对词汇进行清理。这并不是说某个供应商“更不安全”；而是 Azure 实施了安全戏剧，给合法开发者带来不便，却几乎没有提供实际保护。

更深层的问题

任何有恶意意图的人都可以直接采用这些委婉说法。过滤器并没有阻止坏人——它只给合法使用场景增加了摩擦。

真正的安全来自于：

• 理解上下文和意图
• 限流与监控
• 用户身份验证和审计日志
• 明确的服务条款并加以执行

关键词阻断就像在烹饪网站上禁止出现“刀”字一样，属于安全的等价物。

实用建议

如果你在使用 Azure OpenAI 的函数调用构建工具：

• 在部署前审查工具名称，确保没有触发词。
• 在描述中使用中性、抽象的术语。
• 尽早使用实际 API 调用进行测试——Playground 的表现可能不同。
• 记录这些转换，让团队了解映射关系。

已消毒的工具定义示例

{
  "name": "activatePageItem",
  "description": "Activates an interactive item on the page at the specified coordinates",
  "parameters": {
    "type": "object",
    "properties": {
      "x": { "type": "number", "description": "Horizontal position" },
      "y": { "type": "number", "description": "Vertical position" }
    }
  }
}

更自然（被阻止）的版本

{
  "name": "clickElement",
  "description": "Clicks an element on the page at the specified coordinates",
  "parameters": { ... }
}

结论

Azure 对函数调用的内容过滤器需要改进。仅凭关键字匹配而不进行上下文分析，会给开发者带来摩擦，却几乎没有安全收益。在此改变之前，变通办法很简单：使用委婉说法。你的浏览器自动化工具并不是“点击按钮”，而是“激活交互式页面项”。

最初发表于 javieraguilar.ai。