安全与 Guardrails
模型越能做事，越需要边界。Guardrails 不是单一“拒答提示词”，而是一套围绕输入、工具权限、输出内容和审计日志构建的系统防线。它的目标不是让模型什么都不做，而是在可用性和风险之间建立更稳的控制带。
先识别风险
再选约束策略
最后审计与回退
换一个风险场景，看看 Guardrails 怎么接管
切换场景，再切换当前阶段。你会看到系统是在做输入检测、策略判断、工具权限约束、输出重写，还是进入日志与人工复核流程。
当前请求
高风险场景常常不仅要拦，还要记录“为什么拦、拦了什么、是否需要人工复核”。
没有 Guardrails 时
有 Guardrails 时
Guardrails 常见的四个位置
输入前置过滤
先看请求本身有没有明显风险，比如越权操作、违规内容、提示注入或可疑数据外传意图。
工具权限控制
就算模型判断要调用工具，也不能默认全工具可用。不同用户、不同任务和不同风险等级往往对应不同权限。
输出后处理
模型生成后的结果也可能需要再扫描，比如脱敏、风险提示、拒绝重写、引用补充或人工审批。
日志与人工复核
真正的系统不会只关心“这次挡住了没”，还要留下可复盘记录，并在必要时引入人工审批链路。
为什么安全不是“全拒绝”
拒绝只是其中一种动作
有些请求应该直接拒绝，但有些请求更适合降权、改写、提醒、脱敏或转人工，而不是一刀切。
安全要和任务目标一起设计
客服、办公助理、代码助手、医疗支持系统面对的风险不一样，所以 Guardrails 的策略也应该不同。
误杀也要被关注
如果系统把正常请求也大量拦掉，可用性会快速下降，所以安全系统也需要评测与调参。
安全是分层工程
提示词、模型对齐、工具权限、规则引擎、日志审计、人工复核往往要一起工作，单层很难覆盖全部风险。
一句话总结： Guardrails 不是给模型加一句“注意安全”，而是在输入、调用、输出和审计四个层面建立可执行的风险控制流程。