护栏与安全模式（Guardrails and Safety Patterns）

护栏（Guardrails），也称为安全模式，是确保智能体安全、合规并按预期运行的一组机制。

随着智能体获得更高自主性，并接入文件、数据库、支付、代码执行等关键系统，护栏也从“内容过滤器”演变为完整的风险控制体系。

护栏可以作用于输入验证与清洗、输出过滤与后处理、提示级行为约束、工具权限、外部内容审核 API，以及人工介入（Human-in-the-Loop，HITL）等环节。

核心思想：不要要求模型独自保证安全，而要在模型之外建立可验证、分层、默认拒绝高风险动作的控制面。

护栏的目标不是简单限制能力，而是在可接受的风险范围内释放能力，使智能体的行为更稳健、可信、可预测、可审计，并符合伦理、法律和业务规则。

护栏不只是内容审核

内容审核关注“能否输入或输出某类内容”，智能体安全还要关注“模型能访问什么、能代表谁行动、能够产生什么副作用”。

一个完整的护栏体系通常包括四类控制：

系统提示词可以引导行为，却不是可靠的安全边界。提示注入、幻觉、间接注入或工具返回的恶意内容，都可能影响模型决策。

权限校验、资源归属检查和高风险审批必须在确定性代码或下游系统中执行。

先做威胁建模

护栏设计应从智能体的能力、领域、部署环境和风险承受度出发，而不是复制一份通用敏感词表。

至少需要识别以下信任边界：

常见威胁包括提示注入与越狱、敏感信息泄露、过度代理权、工具滥用、不安全输出处理、错误信息、资源耗尽、供应链风险、记忆污染和跨用户越权。

OWASP 将过度代理权的根因概括为三类：功能过多、权限过大、自主性过强。因此，安全设计不能只判断模型“说了什么”，还要限制它“能做什么”。

分层防御架构

可靠的护栏不是一个单点分类器，而是一组相互补位的控制。

flowchart LR
    U["用户或外部数据"] --> I["输入护栏"]
    I --> A["智能体与模型"]
    A --> T["工具调用护栏"]
    T --> S["沙箱或下游系统"]
    S --> O["工具观察结果"]
    O --> A
    A --> R["输出护栏"]
    R --> H{"是否需要人工审批"}
    H -->|否| F["返回结果"]
    H -->|是| P["人工复核或接管"]
    P --> F

    C["身份、权限、策略与密钥"] -.约束.-> I
    C -.约束.-> T
    M["日志、指标、评测、检查点"] -.观测.-> A
    M -.观测.-> T
    M -.观测.-> R

防御层之间应尽量采用不同失效模式。例如，LLM 分类器适合判断语义，JSON Schema 适合检查格式，IAM 适合限制权限，人工审批适合处理不可逆且高影响的动作。

1. 输入护栏

输入护栏在内容进入主智能体前执行，常见措施包括：

• 校验数据类型、长度、编码、文件类型和结构化 Schema
• 清理控制字符、恶意标记和不需要的元数据
• 使用内容审核 API 或专用分类器识别有害内容
• 检测直接提示注入、越狱和业务越界请求
• 对外部网页、邮件、RAG 文档标记“不可信数据”，避免将其当作高优先级指令
• 限制速率、并发、Token、文件大小和请求成本
• 对敏感字段脱敏或拒绝接收

快速、低成本的模型可作为额外预筛查层，但不能成为唯一防线。它本身也可能误判、被绕过或在分布外输入上失效。

2. 模型与行为护栏

模型层护栏通过系统指令、角色、目标、背景故事、结构化输出和工作流状态限制行为。专用智能体通常比职责宽泛的“万能智能体”更容易测试和约束。

应明确：

• 允许和禁止的任务范围
• 不确定时是拒绝、降级，还是转人工
• 必须引用证据或调用验证器的条件
• 最大上下文、最大步骤、停止条件和预算
• 能否委托给其他智能体
• 输出 Schema、语气、品牌和合规要求

提示级约束属于软控制。不得仅靠“不要泄露数据”“不要调用危险工具”等文字来实现授权。

3. 工具与动作护栏

工具调用是智能体安全的核心边界。模型提出动作，确定性代码决定动作是否真的执行。

每次调用都应尽可能检查：

• 工具是否位于当前智能体和当前流程的允许列表
• 参数是否符合 Schema、枚举、范围和长度限制
• 参数中的用户、租户和资源 ID 是否与可信会话状态一致
• 当前用户和智能体身份是否拥有下游权限
• 操作是否只具备完成任务所需的最小功能与最小权限
• 写入、删除、支付、发送、发布等副作用是否需要确认
• 是否支持幂等键、试运行、事务、补偿操作或回滚
• 目标域名、文件目录、数据库表和网络出口是否在允许范围内

授权应在每次工具调用和下游访问时重新校验，即“完全仲裁（Complete Mediation）”。不要相信模型在自然语言中声称“用户已经授权”。

对于代码执行，应使用隔离环境，并限制文件系统、网络、进程、时间、内存和 CPU。执行结束后还应清理数据，避免跨会话泄露。

4. 输出护栏

输出护栏在结果交给用户或下游系统前执行，常见措施包括：

• 用 Pydantic、JSON Schema 或类型系统验证结构
• 检查引用、事实依据、单位和关键计算
• 使用内容分类器识别仇恨、暴力、露骨、自残等风险
• 检测密钥、个人信息和组织敏感数据
• 删除或标记违反政策的问题片段
• 对医疗、法律、金融等高风险建议增加边界说明并转交专业人员
• 在浏览器中转义模型生成的 HTML、JavaScript、Markdown 链接和 URL

后处理可以阻止不安全结果继续传播，但不能撤销已经执行的工具副作用。因此，高风险动作必须在执行前阻断，而不是只在最终回复中补一句警告。

5. 人工介入

人工介入不是失败兜底，而是高风险工作流中的正常控制节点。

拒绝、人工复核和安全降级应向用户提供清楚、不过度暴露内部策略的解释。

典型应用场景

这些护栏既保护用户和组织，也保护系统声誉。

但“政治、宗教、竞品讨论”等不天然属于有害内容，它们是否越界取决于产品定位和业务政策，不能被当作所有系统通用的安全禁区。

护栏实现方式

不同问题需要不同控制。越能确定表达的规则，越应该优先用确定性代码。

推荐顺序是：确定性校验 → 专用分类器 → LLM 语义评审 → 高风险人工审批。这不是固定流水线，可按场景跳过不需要的层。

Fail-open、Fail-closed 与人工复核

• Fail-open：护栏故障或不确定时放行。适合影响很低、可轻易撤销的请求。
• Fail-closed：护栏故障或不确定时拒绝。适合高风险或不可逆动作。
• Needs-review：暂停流程并转人工。适合有业务价值但无法安全自动判定的请求。

原始示例采用“有疑问时默认合规”。这会在分类器低置信度或异常时静默放行，不适合高风险系统。

本章示例增加 needs-review 状态，并在内部错误、格式异常或判断不确定时暂停处理。

CrewAI：输入政策预筛查

CrewAI 的任务护栏可校验或转换 TaskOutput。当前版本同时支持函数式护栏、LLM 式护栏、多个串联护栏、guardrail_max_retries 和 output_pydantic。

本章示例使用一个快速、低成本的专用智能体，在主智能体处理输入前进行政策评估。政策包括：

1. 指令绕过与越狱尝试
2. 仇恨、危险、露骨、辱骂等禁止内容
3. 产品定义的越界话题与学术作弊
4. 专有、品牌和竞争信息规则

输出由 PolicyEvaluation 约束，包含：

• compliance_status：compliant、non-compliant 或 needs-review
• evaluation_summary：简要判定说明
• triggered_policies：命中的政策列表

函数式护栏会提取 TaskOutput.pydantic 或解析原始 JSON，去除 Markdown 代码围栏，再执行 Pydantic 与逻辑一致性校验。格式错误会反馈给任务重试，超过上限则进入安全失败路径。

完整代码见 CrewAI 护栏示例。

示例保留了原有的 Agent、Task、Crew、Pydantic 校验、异常处理和测试用例，并补充了：

• 不确定状态与高风险默认暂停
• 输入长度与空值的确定性预检
• 指数退避重试
• 日志中只记录输入哈希和长度，避免直接写入敏感原文
• 严格枚举、禁止额外字段和跨字段一致性校验
• 通过环境变量管理模型和 API 密钥

生产环境还应接入真实内容审核 API、持久化审计、指标告警和人工审核队列。LLM 评审器不能替代身份认证、授权或下游权限。

Google ADK / Vertex AI：工具调用前校验

Google Cloud 的智能体安全建议采用多层控制，包括身份与授权、输入输出护栏、Gemini 内置安全功能、模型与工具回调，以及低成本模型预筛查。

这些控制还包括隔离代码执行、评测与追踪，以及 VPC Service Controls 等网络边界。

Google ADK 的 before_tool_callback 在工具执行前触发：

• 返回 None：允许工具使用当前参数继续执行
• 返回字典：跳过工具执行，并把该字典当作工具结果

因此，回调可以检查用户 ID、租户、工具允许列表和参数 Schema。完整代码见 Google ADK 工具护栏示例。

示例使用 tool_context.state 中由服务端写入的可信 session_user_id，与模型生成的 user_id_param 比较。身份缺失、不匹配、工具越界或参数异常时都会拒绝执行。

这里有三个重要边界：

1. 会话状态必须由可信服务端建立，不能由模型或用户任意覆盖。
2. 回调是应用层防线，下游 API、数据库和 IAM 仍须独立授权。
3. 跨智能体通用的安全政策应封装为 Runner 级插件，避免每个 Agent 重复实现并产生策略漂移。

简单允许/拒绝列表适合固定工具和资源；提示词驱动的 LLM 护栏适合检测越狱、有害内容、品牌风险和智能体偏离。两者应组合使用，且确定性权限检查优先。

工程化可靠智能体

即使确定性软件也会出现缺陷和不可预测行为。智能体还增加了概率模型、外部工具和动态环境，因此更需要成熟的软件工程方法。

本节只保留与安全直接相关的可靠性边界；状态机、预算、幂等、重试和恢复的完整整理见智能体运行时可靠性，Trace 与故障闭环见智能体可观测性与故障归因。

检查点与回滚

自主智能体管理复杂状态时容易偏离目标。检查点类似数据库事务中的提交点：只有状态通过验证后才保存为可恢复版本。

执行步骤 → 验证状态 → 创建检查点 → 执行下一步
                         ↓ 失败
                    回滚或补偿

并非所有副作用都能直接回滚。邮件发送、公开发布和真实支付通常需要补偿操作、审批或幂等设计，而不能假设“恢复内存状态”就撤销了现实影响。

模块化与关注点分离

单一大智能体难以调试和约束。可把系统拆成数据检索、分析、验证和用户沟通等专用智能体或工具。

模块化有利于并行处理、故障隔离、独立测试、升级和维护，但多智能体也会增加身份传播、上下文污染和跨代理信任问题。每条消息和工具调用仍要经过授权与校验。

可观测性与审计

可靠系统必须能解释“发生了什么”。建议记录：

• 请求 ID、用户或租户的隐私保护标识
• 使用的模型、提示与策略版本
• 计划摘要、工具名称、参数摘要和调用结果
• 状态变化、检查点、重试、人工审批和最终处置
• 延迟、成功率、错误率、阻断率和资源消耗

“记录完整思考链路”在工程上应理解为记录动作轨迹、证据、状态和决策摘要，而不是保存或暴露模型的原始私有思维链。原始推理文本可能不忠实，也可能包含敏感信息。

日志本身也需要访问控制、脱敏、保留期限和删除机制。不要把 API 密钥、完整个人信息或机密提示写入普通日志。

错误处理与弹性

需要预判模型超时、限流、工具故障、格式错误和护栏不可用等情况：

• 用 try-except 捕获并分类错误
• 仅对暂时性故障使用带抖动的指数退避
• 设置最大重试次数、总超时和成本预算
• 使用熔断、降级模型或只读模式
• 给用户清楚但不泄露内部安全细节的错误信息
• 在关键决策或策略冲突时转交人工

无限重试会放大成本和资源耗尽风险。重试前还要判断操作是否幂等。

智能体配置与运行环境

角色、目标和背景故事可以引导行为，但安全还依赖运行环境：

• 采用职责清晰的专用智能体
• 管理上下文窗口，防止旧指令和无关数据污染
• 设置速率、并发、步骤、Token 和成本限制
• 使用密钥管理服务和短期凭据，不把密钥写入代码
• 保护输入、记忆、日志和中间产物中的敏感数据
• 通过对抗测试、安全微调或对抗训练增强稳健性
• 对第三方模型、插件、MCP 服务器和依赖做供应链审查

最小权限原则应贯穿所有层。若智能体只需读取新闻 API，就不应获得私有文件访问或写入权限。

测试、评测与持续优化

护栏不是发布前配置一次就结束。策略、模型、攻击方式和用户分布都会变化，需要持续评测。

测试集至少应覆盖：

• 正常输入和边界输入
• 明显违规与隐晦违规
• 直接和间接提示注入
• 编码、分隔、长上下文和多轮绕过
• 身份缺失、跨用户资源 ID 和越权工具
• 工具异常、模型超时与审核服务不可用
• 误报申诉与人工接管
• 输出中的 PII、密钥、恶意 HTML 和危险链接

关键指标包括：

离线评测、红队测试、生产监控、用户申诉和事故复盘应形成闭环。每次模型、提示、工具、权限或政策变更后，都应运行回归测试。

局限与常见误区

单一护栏不会解决所有问题

分类器和评审模型都有误报、漏报和分布漂移。多个高度相关的 LLM 护栏也可能同时失败，因此需要确定性控制与权限边界。

把提示词当授权系统

模型可能被直接或间接提示注入操纵。真正的授权必须由服务端、IAM、数据库或工具代码执行。

只审核最终文本

若智能体已经删除文件或发起支付，最终输出过滤来不及阻止损害。副作用应在工具执行前审批。

不确定时一律放行

Fail-open 会改善可用性，却可能放大高风险事故。应根据影响范围、可逆性和数据敏感度选择拒绝或人工复核。

记录全部内容以便审计

未经脱敏地保存输入、输出和内部推理可能制造新的隐私与泄露风险。审计需要最小必要记录，而不是无限制留存。

用安全规则掩盖产品范围

“不谈政治、宗教或竞品”通常是业务范围或品牌政策，不等于普适安全原则。规则应透明、具体、可申诉，并避免不必要地阻止合法内容。

一图速览

flowchart TD
    A["智能体输出或动作会影响用户、系统或业务吗"] -->|否| B["使用基础校验与监控"]
    A -->|是| C["评估影响、可逆性、权限与数据敏感度"]
    C --> D["输入和输出筛查"]
    C --> E["工具最小权限与逐次授权"]
    C --> F["超时、限流、检查点与回滚"]
    D --> G{"动作是否高风险或判断不确定"}
    E --> G
    F --> G
    G -->|否| H["自动执行并记录审计事件"]
    G -->|是| I["暂停并请求人工审批"]
    H --> J["持续评测、监控与策略迭代"]
    I --> J

是什么：护栏是围绕智能体输入、行为、工具、输出和运行环境建立的多层风险控制。

为什么：无约束智能体可能产生有害、偏见、违法、错误或越权行为，也可能被提示注入操纵，造成现实损害、法律责任和声誉风险。

经验法则：只要智能体可能影响用户、系统、资金、敏感信息或业务声誉，就应实施与风险等级相匹配的护栏。

用户侧聊天、内容生成以及金融、医疗、法律等场景尤其需要人工责任边界。

关键要点

• 护栏是构建负责任、合规、安全智能体的基础。
• 护栏可部署在输入、模型、工具、输出、人工审核和基础设施等多个环节。
• 多种失效模式不同的护栏组合，比单一模型分类器更稳健。
• 权限、身份和高风险动作审批必须在模型之外执行。
• 护栏需要持续监控、评测和优化，以适应风险与用户变化。
• 有效护栏是维护用户信任、品牌声誉和系统可控性的关键。
• 工程级智能体应采用容错、状态管理、模块化、可观测性和全面测试等传统软件工程实践。

总结

护栏是负责任 AI 开发的核心承诺，不只是附加的内容过滤功能。

战略性地组合输入验证、输出审核、行为约束、工具权限、沙箱、网络边界和人工介入，可以把概率模型的不确定性限制在可管理范围内。

精心设计的护栏既不会盲目放大能力，也不会用粗糙禁令压制正常需求。它根据真实风险分配控制强度，让智能体在安全、合规、可审计的前提下高效服务用户。

参考资料

• CrewAI：Task Guardrails
• Google ADK：Safety and Security for AI Agents
• Google ADK：Before Tool Callback
• OWASP LLM01:2025 Prompt Injection
• OWASP LLM06:2025 Excessive Agency
• NIST AI 600-1：Generative AI Profile
• Google AI Principles
• OpenAI Moderations API

相关笔记

• 推理技术
• 反思模式
• 模型上下文协议 MCP
• 目标设定与监控
• Harness Engineering 实践启示
• 智能体运行时可靠性
• 智能体评测