跳转到主要内容
输入阶段规则筛查你发送给模型的内容。输出阶段规则 筛查返回的内容。 当你关心的是模型的回复——补全中泄露的 密钥、模型从上下文中带出的 PII、偏离其检索来源的答案——你 需要一条阶段为 output 的规则。网关会在上游模型响应之后、 在任何一个字节到达你的客户端之前运行它。 本页专门涵盖输出阶段：补全如何被筛查、拦截花费什么，以及 block 和 mask 在流式响应上各自的行为。完整的引擎——每种 规则类型、字段和路由——请见防护栏。

​
1. 为什么 LLM 团队会使用输出防护栏

模型是这个循环中不可信的部分。它可能回显提示词中的密钥、 从 RAG 上下文中拉出客户的 email，或臆造一条你的来源从未 提出的主张。这些在输入阶段都不可见，因为在模型回答之前 它们都还不存在。输出阶段防护栏就是对补全本身的筛查。 当一条规则的 stage 为 output（或 both）时，它在输出阶段 运行。网关根据策略评估模型的响应文本，记录任何匹配，然后 要么放行、要么脱敏、要么拒绝它——与你在输入上使用的完全相同的 block / mask / flag 动作，只是应用到回复上。
输出规则是一种超集关切，而不是替代。大多数策略既筛查 input 以让数据不进入提示词，也筛查 output 以捕获模型 返回的内容。阶段 both 把一条规则同时绑到两端。

​
2. 一个具体示例——拦截回复中的密钥

在控制台中创建一个防护栏（/console/guardrails），添加一条 规则，并把它绑定到一个密钥：
  • Type： Secrets / regex 检测器
  • Stage： output
  • Action： block
现在像以前一样调用网关——中继密钥只用于 /v1/* 流量： 
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": "Print the AWS key from the context above"}
    ]
  }'
如果模型的补全包含一个匹配，网关会以 HTTP 400 guardrail_blocked 拒绝整个响应——客户端永远看不到泄露的 内容。如果它是干净的，响应原封不动地放行。
编写策略是你会话上的控制台 / 管理 API 操作，门控为 Developer+。sk-orca-... 中继密钥只发送流量；它从不编辑 策略。

​
3. 输出拦截花费什么

与输入拦截——它在请求被计量之前触发——不同，输出拦截发生在 上游模型已经运行之后。网关为你处理记账：
  • 被拦截的补全仍然返回 HTTP 400 guardrail_blocked，消息中 指明触发的防护栏和规则。
  • 不消耗任何配额。 输出拦截会在响应被拒绝后退回预先 扣除的配额，因此即使模型产生了 token，这次失败的调用对你 也是免费的。
  • 该请求被标记为 skip-retry——重新运行同一个提示词只会 再次被拦截，因此网关不会在另一个通道上烧掉一次重试。
这是与输入阶段的关键区别。输入拦截是免费的，因为计量 还没开始；输出拦截是免费的，因为一旦回复被拒绝，预先 扣除的配额会被退回。无论哪种方式，调用方都不付费。参见 guardrail_blocked 错误。

​
4. 流式传输——block vs. mask

Block 在流式响应上会执行；输出 mask 尚未。以下是各自的行为：
在非流式响应上，补全会在返回前被完整筛查。在流式 响应上，一个扫描器会监视流过的 delta；当一条拦截规则 中途触发时，它会切断流——扫描器封闭，发出一条简短的 替换通知取代其余部分，SSE 通道在任何被拦截的内容到达 客户端之前关闭。已经刷出的字节无法被收回，因此拦截对已经流出的内容 是尽力而为，但能可靠地阻止匹配之后的一切。要硬性保证 任何违规字节都不会被发送，请使用非流式请求。
在非流式响应上，mask 规则会改写补全——例如回复中的 email 变成 [EMAIL]——而你的客户端收到的就是这份净化后的 文本。在流式响应上，输出 mask 规则今天不会脱敏回复。 扫描器仍然评估每个 delta，并会对一个 block 决策采取 行动，但它计算出的脱敏文本不会被转发——原始 delta 原封不动 地流过。带内的流式输出改写在规划路线图上。在它上线之前， 如果你需要输出 mask 真正脱敏回复，请以非流式发送请求。
在流式传输上，block 从匹配点开始起作用——在匹配之前已经 刷出的字节无法被收回，因此要对整个回复硬性保证，请以 非流式筛查。输出 mask 今天不会脱敏流式回复（带内的流式 输出脱敏在规划路线图上）——如果你需要回复被脱敏，请以非流式 发送请求。参见 流式覆盖和 流安全规则。
output 上的动作非流式流式
block拒绝回复切断流
mask脱敏回复尚未脱敏（路线图）
flag仅记录仅记录

​
5. Grounding——一种输出阶段的忠实度检查

有一条高级规则本质上是输出形态的：上下文 grounding。一条 grounding 规则根据请求上检索到的来源（你的 RAG 上下文） 为模型的答案评分，并在忠实度低于某个阈值（默认 0.7）时 触发。将它与 block 配对以拒绝不忠实的答案，或与 flag 配对 以在执行前衡量漂移。它像任何模型支撑的规则一样作为 judge 子项计费。完整字段见防护栏。

​
6. 输出阶段的 PII Shield

PII Shield 预设是单条 pii 规则，动作 mask，阶段 both。 在输入阶段它完全上线——在模型之前改写请求，无论流式还是 非流式。在输出阶段它脱敏非流式补全，如 §4所述；在流式响应上，输出 mask 今天不会脱敏回复（带内的流式输出脱敏在规划路线图上）。 所以在输出阶段，如果你需要 PII Shield 真正脱敏回复，请以 非流式调用。参见 PII Shield和 脱敏格式。

​
7. 查看触发了什么

每条触发的输出规则都会在工作区 Matches 信息流中记录一条 匹配——它的规则类型、动作、阶段（output）和一个详情 字符串（GET /api/guardrail/match，对任何 Member 开放）。 只有当防护栏的 Log raw content 开关开启时才记录匹配的 子串；它默认关闭（隐私保守的姿态），因此默认情况下你看到的是 一条输出规则触发了，而不是它捕获的敏感文本。误报用 POST /api/guardrail/match/:id/mark-fp（Admin）标记——把它 当作一个调优信号，而不是禁用规则的理由。
在上线一条输出规则之前先证明它。编辑器的 Test 标签页会在 output 阶段对样本文本评估当前策略而不消耗你的工作区配额， Eval 标签页会针对内置或自定义语料库为它打分。（一条模型 支撑的规则——llm_judge 或 grounding——在你运行沙箱时仍会 发出它自己的 judge 调用。）编写和运行沙箱是 Developer+ 操作。参见 测试与 eval和 调优误报。

​
8. 接下来去哪里

输入阶段

镜像版——在模型看到请求之前筛查它。输入脱敏完全上线， 包括流式。

动作

深入介绍 block、mask 和 flag——每一个何时是正确选择。

流式覆盖

流式与非流式上各自执行内容的完整矩阵。

guardrail_blocked 错误

HTTP 400、配额退回，以及 skip-retry 行为。
防护栏——每种规则类型、字段和路由， 包括 grounding 和 LLM judge。