一站式搞懂如何在LiteLLM上配置 Amazon Bedrock Guardrail
内容提要
实测 LiteLLM 接入 Bedrock Guardrail 的四种配置，目标是输入侧仅检查用户输入、输出侧不检查。Proxy 模式会误查 system prompt 和 tool result，模型级 guardrailConfig 无法关闭输出检查。可行方案是自研两步调用：先用 ApplyGuardrail 单独检查用户输入，再发起不带 guardrailConfig 的模型请求，从架构上规避输出检查延迟。
延伸解读
两种 Guardrail 用法的本质差异
文章指出 Bedrock Guardrail 有两种用法：一是模型请求中带 guardrailConfig，由 Bedrock 内部自动执行输入和输出检查，流程焊死、无法单独关闭输出检查；二是单独调用 ApplyGuardrail API，检查内容完全由代码决定，与模型调用解耦。需求越精细，越应选择后者，因为只有门外模式才能精确控制送检内容并规避输出检查带来的延迟。
LiteLLM 标准配置为何无法满足需求
实测表明，LiteLLM 的 Proxy pre_call 模式会把 system prompt、tool result 等一并送检，导致误拦截；experimental_use_latest_role_message_only 参数只检查最后一条消息，在 agent 工具循环中常误查 tool result。模型级 guardrailConfig 虽能精准检查用户输入，但输出检查无法关闭，即使策略全为 NONE 仍会产生缓冲延迟。两种标准玩法各满足一半需求，无法同时达成目标。
自研两步调用的架构优势
推荐方案是自研两步调用：先单独调用 ApplyGuardrail 仅检查用户输入，再发起不带 guardrailConfig 的模型请求。这样 system prompt 和 tool result 根本不会送检，输出路径上也不存在检查环节，从架构上同时满足输入精准和输出零延迟。若需保留 LiteLLM，可编写自定义 CustomGuardrail hook，在 pre_call 中回溯最后一条 user 消息并单独调用 ApplyGuardrail，约百行代码即可实现。
GPT-5.6 的偶然行为与风险
实测发现 GPT-5.6 在带 guardrailConfig 时，输入检查正常但输出检查未执行，trace 中 modelOutput 为空且无 outputAssessments。这可能是因其专属 serving 栈尚未接入输出检查钩子。该行为是临时实现，AWS 文档并未承诺输出不检查。若依赖此捷径，必须部署金丝雀监控，定时验证输出是否仍未被拦截，并准备自定义 hook 作为随时可切换的退路。
Q&A
LiteLLM 的 Proxy pre_call 模式配置 Bedrock Guardrail 时，为什么会出现 HTTP 400 误拦截？
因为该模式会把整个 messages 原样送给 ApplyGuardrail，包括 system prompt、历史消息和 tool result，而不仅是用户输入。system prompt 中固定措辞可能触发 Guardrail 策略，导致整单被拒，返回 HTTP 400 Violated guardrail policy。
LiteLLM 的 experimental_use_latest_role_message_only 参数能保证只检查用户输入吗？
不能。该参数的实际语义是“只查最后一条 message，不管它是谁写的”。在 agent 工具循环中，最后一条经常是 role=tool 的 tool result，此时会把 tool result 内容送检，同样可能触发 HTTP 400。
在 LiteLLM 模型级配置 guardrailConfig 时，为什么输出侧检查无法关闭？
因为 guardrailConfig 属于 Bedrock 的驻场安检模式，input 和 output 检查在流水线里是焊死的。即使把所有 output 策略设为 NONE，trace 中仍会出现 outputAssessments，guarded=40/40，只是 policyUnits=0，流式缓冲延迟照付，没有开关可以关掉出门检查。
如何用自研两步调用实现“输入只查用户输入、输出完全不检查”？
第一步单独调用 ApplyGuardrail，source 设为 INPUT，content 只传用户输入文本；若 action 为 GUARDRAIL_INTERVENED 则直接返回拦截结果。第二步调用 converse_stream，请求中不带任何 guardrailConfig 字段，输出直接流回客户端。这样查什么由代码决定，输出路径上结构性地不存在检查环节。
为什么流式输出做 output 检查一定会引入延迟？
因为流式响应是逐段生成、逐段流过转发代码的，不迭代就没有数据。要在放行前检查内容，就必须扣住一段、查一段、放一段，无法做到零延迟。AWS 驻场安检默认攒块检查，自研网关调用 ApplyGuardrail 每次约 150ms，都会带来缓冲延迟。
GPT-5.6 在 Bedrock 上使用 guardrailConfig 时，output 检查会执行吗？
实测不会。用 EMAIL→BLOCK 的 Guardrail 做闭环实验，Claude Haiku 4.5 和 gpt-oss-120b 的输出被正常拦截，但 GPT-5.6 Sol/Terra/Luna 仍返回原文，非流式 trace 中 modelOutput 为空且无 outputAssessments。input 检查则正常执行，提示词注入攻击会返回 guardrail_intervened 且 inputTokens: 0。
如果依赖 GPT-5.6 目前跳过 output 检查的行为，需要做什么风险防范？
必须配置金丝雀监控：定时任务让模型固定输出可拦截内容（如邮箱），断言客户端收到原文。一旦金丝雀被拦截，说明 output 检查已生效，需立即切换方案。同时应把自定义 hook 方案写进二期规划，作为随时可切换的退路。
