跳转到主要内容
一个太急切的防护栏比没有防护栏更糟——你的团队学会忽略 Matches 信息流，或者你放松规则并失去你真正想要的捕获。OrcaRouter 给你 一条精确的中间路径：把单条匹配标记为误报，引擎就会记住那个 发现并在未来请求上跳过它——而不触碰规则、不放松模式，也不上线 一次 SDK 变更。 这是误报工作流的专注落地页。完整的防护栏引擎——每种规则类型、 字段和路由——请见防护栏参考。
这里的每一步都是托管网关（api.orcarouter.ai）上的控制台操作。 你在自己的会话下分诊匹配；只有最后的 /v1/* 调用使用 sk-orca-... 中继密钥。把一条匹配标记为误报需要工作区 Admin 角色；读取 Matches 信息流和由此产生的抑制列表对每个成员开放。

​
1. 在不削弱规则的情况下减少防护栏误报

当一条规则过度触发时的本能是放松它——放宽一个正则排除、丢掉一个 实体、把 block 翻成 flag。那是用一个误报换策略中的一个洞。 标记误报抑制是外科手术式的替代方案：

抑制一个发现

静音误触发的确切匹配——某条规则下的某个特定子串——而不是 整条规则。下一个真正敏感的命中仍然触发。

无规则编辑，无重新部署

抑制作为工作区记忆存在于网关中。规则保持完全如其所写；你的 应用继续不变地调用 /v1/*。

工作区范围的记忆

一个 Admin 标记它一次；抑制在工作区范围内去重，因此每个成员的 流量都受益——无需按密钥扇出。

可逆

取消标记匹配（或删除抑制），该发现就在下一个请求上再次触发。 什么都没被销毁。
抑制用于你判定为良性的一个发现。如果整条规则被错误校准—— 错误的形态、错误的阶段——修复规则并在 Eval 工具中证明它，而不是 一条又一条地静音匹配。

​
2. 一条匹配如何变成一次抑制

每条触发的规则都会在工作区 Matches 信息流中记录一条 匹配——规则类型、动作、阶段和一个详情字符串。当你把那些匹配 之一标记为误报时，网关为该发现派生一个稳定的指纹，并把它 写入工作区的抑制列表。在每个未来请求上，引擎会把每个发现的指纹 与那个列表核对，并在一个被抑制的发现能拦截、脱敏或 flag 之前 跳过它。 两类发现会产生一个指纹：
一个 CVE / SBOM 发现已经随附一个稳定身份——警示或组件身份 随该发现一同流转。抑制一个会静音那个确切的 CVE/组件，且只有 那一个。这是抑制存储为之构建的原生用例。
Keyword、regex、PII 和其他确定性规则类型不携带它们自己的身份， 因此网关从写入侧（你的标记 FP 点击）和执行侧（下一个请求）上 相同的数据合成一个：防护栏、规则的匹配身份，以及——当原始 捕获开启时——匹配的子串本身。
合成指纹的精度取决于 Log raw content，而它默认关闭。捕获 开启时，指纹以确切的匹配子串为键，因此抑制 ORD-48291507 会 静音那个订单号而不静音其他任何东西。捕获关闭时，没有子串 可作键，因此抑制回退到一个规则级静音——它为工作区静音那一条 规则（在那个阶段）。该回退永不超出它来自的那条规则。参见 日志与隐私。

​
3. 一个具体示例

假设你运行一条 regex 规则，它脱敏形如 ORD- 加八位数字的内部 订单号。一张支持工单以一种你已决定可以放行的方式合法地引用了 ORD-48291507。你不想削弱规则——你只想这一个号码停止触发。
1

打开 Matches 信息流

在控制台中打开 Guardrails → Matches。按防护栏和规则类型 过滤，找到 ORD-48291507 命中的那一行。（要看到字面子串， 记录该匹配时防护栏的 Log raw content 必须开启——它默认 关闭。）
2

把它标记为误报

打开匹配详情并选择 Mark as false positive。作为工作区 Admin，这会给匹配盖戳并镜像一条以该发现指纹为键的工作区 抑制。
3

确认它被抑制

打开 Suppressions 列表——新条目出现，标注它来自的防护栏和 规则，以及原因*“Marked as false positive from Matches”*。工作区 的每个成员都能读取这个列表。
4

再次发送相同的请求

用你的中继密钥，像以前一样调用 OrcaRouter——无需新的请求头， 无需修改 SDK：
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Status of order ORD-48291507?"}
    ]
  }'
被抑制的发现被跳过——ORD-48291507 通过——而任何其他订单号 仍然匹配并像以前一样被脱敏。

​
4. 抑制 vs. 替代方案

抑制是安抚一条嘈杂规则的四种方式之一。选择最窄的合适方式：
方法它改变什么何时使用它
标记 FP一个发现（或一条规则，捕获关闭时）一个特定的良性命中；规则其他方面正确
编辑规则匹配本身错误的形态/阶段——修复它，然后重新 eval
flag 动作仅观察，不拦截一条你还不信任的新规则
Eval 工具不改变实时——衡量在上线前证明精确率
不要靠一条又一条地标记 FP 来掩盖一条系统性错误的规则。如果你在 反复抑制相同的形态，那条规则被错误校准了——给 正则加锚点、收窄 关键词列表，或选择一个 更紧的 PII 实体，并用 一次 eval 运行验证。

​
5. 撤销一次抑制

这里没有任何东西是单向的：
  • 取消标记匹配——同一个 Admin 操作，反向执行，移除匹配的 FP 戳，并（当没有其他被标记 FP 的匹配仍映射到它时）丢弃抑制。该 发现在下一个请求上再次触发。
  • 直接删除抑制——从 Suppressions 列表，一个 Developer+ 操作移除该条目。同样的效果：该发现再次实时。
由于抑制是工作区记忆，撤销一个会一次性为每个成员的流量恢复 捕获——与把它为所有人抑制的方式相同。

​
6. API 面

这些是控制台路由，由你的会话鉴权——而不是中继密钥。逐个操作 角色门控：标记一条匹配 FP 是 Admin；抑制读取是 Member； 抑制写入是 Developer+。
方法与路径角色用途
GET /api/guardrail/matchMember列出匹配以分诊。
POST /api/guardrail/match/:id/mark-fpAdmin把一条匹配标记为误报（镜像一条抑制）。
DELETE /api/guardrail/match/:id/mark-fpAdmin取消标记——恢复该发现。
GET /api/guardrail/suppressionsMember列出工作区的活跃抑制。
POST /api/guardrail/suppressionsDeveloper+直接添加一条抑制。
DELETE /api/guardrail/suppressions/:idDeveloper+移除一条抑制。
标记 FP 端点是限速的——它们是一个刻意的、低量的分诊操作，而不是 一个批量 API。当你在调优一整个策略时，使用 Eval 工具，而不是 一个标记 FP 调用的循环。

​
7. 接下来去哪里

Matches 信息流

每条触发的规则落地的地方——你标记任何东西之前从中分诊的 地方。

测试与 eval

在你上线之前针对一个语料库证明一条规则的精确率——当抑制只是 在治标时的系统性修复。

日志与隐私

Log raw content 如何控制抑制以确切子串为键还是回退到一个 规则级静音。

防护栏参考

完整引擎——每种规则类型、动作和路由。
抑制治理内容发现。要安抚一条嘈杂的智能体防火墙规则——一个 你判定为安全的工具匹配——那是一个单独的面；参见 防火墙及其 异常信息流。要理解防护栏 和防火墙在哪里分界，请阅读 防护栏 vs 防火墙。