Guardrails

很多 AI 系统一开始关注的都是能力：

1. 能不能答
2. 能不能调工具
3. 能不能自动往下做

但只要系统开始接真实业务，后面很快就会发现，另一个同样重要的问题是：

它会不会做错、会不会越界、会不会在不该动的时候真的动起来。

这就是 Guardrails 真正开始有分量的地方。

1. Guardrails 到底是什么

Guardrails 直接看成运行时护栏。

它不是某一个单点组件，而是一组约束、检查和拦截机制，用来保证系统在输入、执行、输出三个阶段都不要轻易越界。

它最关心的不是“让模型更聪明”，而是：

1. 输入是不是安全
2. 执行是不是合规
3. 输出是不是可接受

2. 为什么 AI 系统特别需要它

因为 AI 系统和传统接口不太一样。

传统接口通常是：

1. 路由固定
2. 参数明确
3. 执行路径相对稳定

而 AI 系统经常会出现这些情况：

1. 用户输入不可控
2. 上下文可能混入外部内容
3. 模型会产生调用工具的意图
4. 输出不一定天然符合格式和合规要求

这意味着，只要没有护栏，系统很容易在某个环节出界。

3. 护栏通常放在哪几层

最常见的放置位置可以分成 3 层：

flowchart LR
    A[输入前] --> B[执行中]
    B --> C[输出后]

3.1 输入前

这一层主要防的是：

1. 恶意输入
2. Prompt 注入
3. 越权请求
4. 敏感信息直接混入上下文

3.2 执行中

这一层主要防的是：

1. 工具权限越界
2. 参数非法
3. 高风险动作被直接执行
4. 调用次数异常

3.3 输出后

这一层主要防的是：

1. 结构不合法
2. 内容不合规
3. 敏感信息泄露
4. 最终结果不满足业务要求

4. 常见的 Guardrails 长什么样

更贴近工程一点的例子，通常包括：

1. 工具调用前做权限校验
2. 高风险操作前强制二次确认
3. 对结构化输出做 JSON Schema 校验
4. 对模型输出做敏感词和脱敏检查
5. 对外部网页或知识内容做清洗和过滤

这些机制未必都复杂，但都很有必要。

5. Guardrails 和 Security 有什么关系

这两个词很容易被混到一起。

可以这样分：

1. Guardrails 更偏 AI 运行时边界控制
2. Security 更偏整套系统安全体系

前者更像在关键位置加检查点，后者则会继续覆盖：

1. 身份认证
2. 权限体系
3. 密钥管理
4. 数据隔离
5. 审计与合规

所以 Guardrails 很重要，但它并不等于完整安全。

6. Guardrails 和 Human-in-the-loop 也不是一回事

它们经常一起出现，但职责不同。

1. Guardrails 更偏规则和机制
2. Human-in-the-loop 更偏把决定权交还给人

比如：

1. “金额超过阈值就不允许自动执行”更像 Guardrails
2. “金额超过阈值时必须人工审批”更像 Human-in-the-loop

一个负责拦，一个负责判。

7. 最容易踩的几个坑

7.1 只在输出后加检查

这样很多问题已经在执行阶段发生了，事后再拦只能补救，不能真正控住过程。

7.2 护栏全靠提示词

提示词可以提供约束，但它本身不等于硬边界。真正高风险的地方，最好还是要有程序级校验和拦截。

7.3 护栏过多，导致系统几乎动不了

护栏的目标是控边界，不是把系统封死。太重的检查也会带来误拦、延迟和维护负担。

8. 一段更稳的总结

Guardrails 解决的是“系统在运行过程中不要越界”这个问题。它通常分布在输入前、执行中、输出后这几层，用来控制权限、格式、风险动作和内容合规。很多 AI 系统能不能从 Demo 走到真实业务，差别往往不在模型有多强，而在护栏有没有搭起来。