1. 两类检查
每一条防护栏规则和每一次防火墙评估都属于两类之一。内置/确定性检查
关键词拒绝列表（keyword）、正则表达式（regex）、PII 检测
（pii）和最大长度（max_chars）防护栏规则是纯本地字符串和
正则操作——没有模型调用，没有网络跳转，没有任何可能超时的东西。
防火墙规则评估（工具名 glob 匹配、参数谓词、出站流量范围）同样如此：
确定性且本地。
从实际角度看，这些检查给你的请求增加了可以忽略不计的延迟。
它们可以安全地在热路径上运行，也是内置防护栏模板的构成材料。
高级/语义检查
llm_judge、grounding 和 external 供应商规则将检查委托给
模型或供应商。它们确实会消耗一次往返。三个属性限制了这个成本：
- 并发派发。 如果你的策略有多条高级规则，它们会并行派发—— 一个慢检查永远不会串行阻塞另一个。
- 每条规则的超时。 每条高级规则都有一个超时
（
judge_timeout_ms/grounding_timeout_ms/timeout_ms）。 grounding 检查默认约 3 000 ms；judge 使用可配置值（0 → 引擎 默认值）。规则是有边界的——它不会无限期挂起。 - 默认故障开放。 当规则超时或其供应商返回错误时，事件被记录
但请求继续。将
judge_fail_open: false（judge）或fail_open: false（external）设置为故障关闭。
2. 一览表
| 检查类型 | 增加延迟？ | 如何限制 |
|---|---|---|
keyword 拒绝列表 | 可以忽略不计——本地字符串扫描 | 无网络；无需超时 |
regex | 可以忽略不计——RE2 本地匹配 | 无网络；无需超时 |
pii 检测 | 可以忽略不计——本地正则/实体扫描 | 无网络；无需超时 |
max_chars | 可以忽略不计——字符计数 | 无网络；无需超时 |
| 防火墙规则评估 | 可以忽略不计——glob + 谓词匹配 | 无网络；无需超时 |
llm_judge | 一次有边界的模型调用 | judge_timeout_ms；默认故障开放 |
grounding | 一次有边界的模型调用 | grounding_timeout_ms（默认约 3 000 ms）；默认故障开放 |
external 供应商 | 一次有边界的供应商调用 | timeout_ms；默认 fail_open |
| 多条高级规则 | 一次有边界的往返（并发派发） | 最坏情况 = 最长单个超时，而非总和 |
3. 请求生命周期中检查在哪里运行
执行并不都在同一个点发生。输入和输出筛查在不同的地方增加时间：llm_judge）
在主模型调用开始之前增加一次有边界的模型调用。
输出防护栏在模型响应之后运行。内置输出规则在尾部增加可以
忽略不计的开销。高级输出规则（例如检查 RAG 忠实度的 grounding）
在你已经有了模型答案之后增加一次有边界的调用。
防火墙规则评估是确定性的，内联发生在工具调用路由上——
如上所述，可以忽略不计。
被拦截的请求对于输入阶段拦截不消耗模型令牌，也不增加上游
延迟。输入拦截在计量之前和上游调用之前触发，因此你既不付配额，
也不付上游往返时间。输出阶段拦截在响应被拒绝后退回预先扣除的配额。
4. 超时和故障开放如何限制最坏情况
高级规则有两个旋钮： 超时——检查被允许的最大壁钟时间。请求最多等待这条规则的 这么长时间。并发派发意味着此上限是每条规则的，而不是每个策略的。 如果你有三条llm_judge 规则，每条有 2 000 ms 超时，它们同时运行，
总等待时间约为 2 000 ms，而不是约 6 000 ms。
故障开放 vs. 故障关闭——当规则未及时完成（或供应商出错）时
该怎么做：
| 设置 | 超时/错误时的行为 |
|---|---|
fail_open: true（默认） | 记录事件；让请求像检查通过一样继续 |
fail_open: false | 将超时/错误视为拦截；返回 HTTP 400 guardrail_blocked |
5. 实用指导
将热路径规则保持为内置规则。 如果你的主要关注是 PII、 凭证泄露、提示词长度或关键词拒绝列表——所有这些都是内置规则。 它们不增加任何可测量的延迟，应该是你处理文本匹配能处理的任何 检查的默认选择。 在需要语义的地方使用llm_judge 和 grounding。 毒性、
骚扰、跑题检测、提示注入意图和 RAG 忠实度是真正模糊的——没有
任何正则能可靠地捕获它们。这些是高级规则的正确使用场景。
接受每个都会增加一次有边界的额外模型调用。
调优超时以适应你的延迟预算。 如果你的端到端目标是 1 000 ms，
将 judge_timeout_ms: 800（或更少）设置，以便 judge 不会消耗
你的整个预算。引擎的默认超时是一个安全的起点；如果你有严格
要求，就降低它。
对于输出 grounding，模型调用已经完成了。 grounding 检查在
上游模型响应之后运行——额外的延迟只在尾部，而不在首个令牌时间
的关键路径上。这使它成为添加语义执行的低风险场所。
多条高级规则？分散工作。 由于高级规则并发运行，叠加三条
llm_judge 规则的成本与一条大致相同——最长的单个超时决定壁钟
时间，而不是数量。利用这一点分层语义检查而不产生累加成本。
执行模式
故障开放 vs. 故障关闭——在超时和错误条件下调优策略行为的完整参考。
防护栏
规则类型、judge 字段、grounding 阈值和完整防护栏配置参考。