AI Agent护栏：输入输出检查与工具级防护

AI Agent 的能力边界正在从“能回答”扩展到“能调用工具、执行任务”，但这也让一个老问题变得尖锐：你怎么知道它接收的输入是安全的，产出的结果是可信的？这正是“护栏”（Guardrail）要解决的事。它本质上是对 Agent 输入或输出施加的一项检查——可以放行、可以改写，也可以直接拦截。本文基于一个白板讲解视频的梳理，结合 OpenAI Agents SDK、NVIDIA NeMo Guardrails 与 Anthropic 的相关观点，拆解护栏的分层设计与落地取舍。

什么是 AI Agent 护栏

按照 OpenAI Agents SDK 的定义，护栏用于对用户输入和 Agent 输出执行检查与验证。它明确区分了两类：输入护栏作用于用户的初始输入，输出护栏作用于 Agent 的最终输出。此外还有工具护栏，它包装你自己编写的函数工具，在每次调用前后进行检查。

这个定义看似简单，但护栏的“动作”其实有三种：放行、修改、阻断。理解这一点很关键——很多团队一开始只想到拦截，实际上改写（例如脱敏、重写Prompt）往往比硬性阻断更实用。

绊线（tripwire）机制是 OpenAI Agents SDK 护栏设计中的一个关键工程细节。它并不是一个独立的技术组件，而是一种异常处理约定：当护栏判定输入或输出不合规时，SDK 会抛出一个特定的异常对象（通常携带护栏名称、判定结果和原始数据），从而立即中断 Agent 的整个运行链路。这种设计的价值在于，护栏的判定逻辑与业务逻辑天然解耦——你不需要在每个工具函数里写 if 判断，只要在 Agent 外层统一捕获这个异常即可决定后续动作，例如返回预设话术、转人工、记录审计日志或触发告警。相比之下，如果护栏只是“返回一个布尔值”，调用方很容易忽略它，安全边界就形同虚设。绊线的代价是它偏向“硬中断”，对于希望护栏仅做标记而非阻断的场景，需要额外配置或改用其他回调方式。

输入护栏与输出护栏的分工

输入护栏的典型价值是“挡住不该进来的请求”。原视频给出的例子很具体：一个客服 Agent 使用了非常聪明的模型，因此又慢又贵；于是用一道护栏配上快速、便宜的模型，专门识别用户是否在求助数学作业。一旦检测到误用，护栏触发“绊线”（tripwire），整个运行以异常中止，而你的代码可以捕获并处理这个异常。

这里的设计哲学值得注意：用便宜模型做分诊，用昂贵模型做核心任务。这与 Episode 4 中提到的“分段处理”思路一致——一个模型负责回答，另一个模型负责筛查。Anthropic 的相关文章指出，这种分工通常比让单次 LLM 调用同时完成两件事表现更好。

运行模式：并行与阻塞的代价

护栏何时执行，直接决定了它的成本与效果。默认情况下，输入护栏与 Agent 运行是并行的；但如果护栏触发，Agent 可能已经消耗了 token、甚至执行了工具调用。在阻塞模式下，护栏会在 Agent 启动前完成，一旦触发，Agent 根本不会运行。

这个取舍很现实：并行更快，但可能白花钱；阻塞更省，但增加延迟。对高成本工具调用场景，阻塞模式通常更划算；对低延迟优先的对话场景，并行更合适。原视频还提到，OpenAI SDK 对敏感工具调用支持“暂停运行、等待人工批准或拒绝”，这相当于把护栏从自动检查升级为人工闸门。

提示注入（prompt injection） 是理解护栏必要性的核心威胁模型。它指攻击者把恶意指令藏在用户输入、检索文档甚至工具返回结果中，诱导 LLM 偏离系统设定、泄露系统提示词或执行非预期操作。与传统 SQL 注入不同，提示注入没有明确的语法边界——自然语言中“忽略之前的指令”和正常请求可以无缝混合，因此很难用规则穷举拦截。这也解释了为什么文章强调要在“依据工具输出行动之前先筛查工具输出”：工具返回的网页、文件或 API 响应同样可能携带注入内容，形成间接注入（indirect prompt injection）。护栏在此扮演的是概率性过滤器，而非确定性防火墙，所以组合多种策略、缩小 Agent 权限、隔离执行环境才构成完整防线。

NVIDIA NeMo Guardrails 的分层思路

第二个工具包是 NVIDIA 的 NeMo Guardrails，它是一个开源 Python 包，用于给基于 LLM 的应用添加可编程护栏，官方称之为“rails”。它的分层比 OpenAI SDK 更细：

• 输入护栏（Input rails）：在模型之前运行
• 检索护栏（Retrieval rails）：作用于检索到的内容
• 对话护栏（Dialogue rails）：作用于对话过程
• 执行护栏（Execution rails）：作用于工具调用
• 输出护栏（Output rails）：在模型之后运行

其中输入与输出护栏最常见。原视频特别提到一个事实核查护栏，目标是减少幻觉，但它的效果“强烈依赖于模型是否遵循其提示词”——这句话点出了护栏的软肋：护栏本身也是模型驱动的，它并非确定性的安全边界。

检索护栏（Retrieval rails） 的独立成层，反映的是 RAG（检索增强生成）架构带来的新攻击面。在 RAG 中，模型回答所依据的上下文来自向量库或搜索引擎，这些内容可能来自用户上传、第三方网页或过期知识库，一旦其中混入错误信息或恶意指令，模型会“忠实”地将其带入回答。检索护栏的作用是在检索结果进入提示词之前，对其做相关性、安全性或事实性筛查，例如过滤低质量片段、标记敏感来源、剔除疑似注入文本。它与输入护栏的区别在于检查对象不同：输入护栏看的是用户说了什么，检索护栏看的是系统“读到了什么”。在 NeMo 的分层模型中，这一层常被忽视，但对于知识库开放或内容来源不可控的应用，它往往是防止幻觉与注入的关键环节。

护栏的成本、误差与测试建议

护栏不是免费的保险。Anthropic 的文章警告，对 Agent 而言护栏会带来更高的成本，并可能产生复合误差（compounding errors），因此建议在沙箱化、隔离的环境中做大量测试并配合护栏使用。

针对提示注入（prompt injection），CLAUDE 文档的建议是：用轻量模型筛查用户输入，并在依据工具输出行动之前先筛查工具输出，同时强调组合多种策略而非依赖单一防线。这与 NeMo 的分层思路互为印证——多源信息在这里指向同一个结论：单层护栏不够，分层与组合才是常态。

小结

护栏的核心不是“加一个过滤器”，而是把 Agent 的输入、工具调用、输出拆成可检查的节点，并在每个节点上决定放行、改写还是阻断。OpenAI SDK 提供了输入/输出/工具三类护栏与人工审批闸门，NeMo Guardrails 提供了更细的 rails 分层，而 Anthropic 则提醒我们关注成本与复合误差。三者共同指向一个实践原则：护栏要分层设计、在隔离环境中充分测试，并接受它本身也需要被验证。