Agent 的护栏怎么设计？输入、输出和工具层各管什么？
面试怎么回答
我会分三层设计护栏。输入层做范围判断、注入检测、敏感信息脱敏和长度频率限制；工具层是最关键的一层，因为模型可能被说服但执行层不会，这里强制按用户身份鉴权、校验参数和白名单、限制扫描量和返回行数、高风险操作要人工确认、限制单会话调用次数；输出层做格式校验、检查回答里的数字是否来自工具返回、过滤敏感信息、合规审核和引用检查。原则是权限、限额这类强制控制放在确定性代码里，模型类检查只做辅助；护栏异常时默认拒绝；记录每次拦截原因，定期复查误拦和漏拦。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
护栏（Guardrails）是让大模型应用「不出事」的一组控制措施。面试官问这题，想看你是否有分层设计的意识，而不是只说「加一个敏感词过滤」。
输入层：拦住不该进来的
- 意图和范围检查：判断用户的问题是否在 Agent 的服务范围内，超出范围直接引导，而不是硬答；
- 注入检测：识别「忽略之前的指令」这类直接注入，对外部文档、网页内容做标记和检测；
- 敏感信息识别：用户输入里有身份证、银行卡号，可以先脱敏再交给模型；
- 长度和频率限制：防止滥用和成本失控。
工具层：最关键的一层
模型可能被说服，但工具执行层不会。这里的控制是强制性的：
- 权限按用户身份执行，越权直接拒绝；
- 参数校验：数值范围、白名单（比如外发邮件只能发内部域名）；
- 资源限制：SQL 扫描量、超时、返回行数；
- 高风险操作需要人工确认；
- 速率限制：单个会话内调用次数上限，防止循环。
输出层：拦住不该出去的
- 格式校验：结构化输出要符合 Schema；
- 事实核查：对数据类回答，检查回答中的数字是否来自工具返回，而不是编出来的；
- 敏感信息过滤：回答里不能出现不该展示的个人信息、密钥；
- 合规内容审核：违规内容、不当言论；
- 引用检查：RAG 的回答，引用的文档是否真实存在、是否支持该结论。
设计原则
- 强制控制放在确定性代码里：权限、限额、白名单不靠模型判断；
- 模型类检查做辅助：注入检测、事实核查可以用模型，但要接受它们会有误判；
- 失败要安全：护栏服务异常时默认拒绝高风险操作，而不是放行；
- 可观测：记录每次拦截的原因，定期复查误拦和漏拦；
- 成本和延迟：每层检查都有开销，按风险等级决定检查的强度。