12. Agent 的 Guardrails 怎么设计？输入输出分别怎么防护？
整理 Agent Guardrails 的设计思路及输入输出两侧的防护方法。
简单回答
Agent Guardrails 是在 Agent 的输入端和输出端设置的安全防线。输入端防护包括：用户输入的意图分类（拦截恶意或超范围请求）、Prompt 注入检测、敏感信息过滤。输出端防护包括：工具调用合规性检查（参数是否越权）、生成内容的安全审核（有害内容、敏感信息泄露检测）、以及对高风险操作的拦截和人工审批。Guardrails 的原则是"在代码层做硬约束，不依赖 LLM 自身的判断"。
详细解释
Guardrails 的整体架构
Agent 的 Guardrails 可以理解为一系列"检查站"，分布在 Agent 流程的各个关键节点。一个完整的 Guardrails 系统至少覆盖三个位置：输入端（用户请求进入 Agent 之前）、决策端（Agent 做出工具调用决策之后、实际执行之前）、输出端（Agent 生成回复之后、返回给用户之前）。
输入端防护
意图分类和越界检测。 用一个分类器（可以是规则、小模型或 LLM）对用户输入做意图识别。如果请求超出了 Agent 的能力范围或职责范围（比如一个客服 Agent 收到了"帮我写代码"的请求），直接拒绝或引导到正确渠道。这比让 Agent 自己判断"该不该处理这个请求"更可靠——Agent 可能会过度积极地尝试处理所有请求。
Prompt 注入检测。 前面在 Agent 安全那道题里提到过，Prompt 注入在 Agent 场景下尤其危险。检测方法包括：基于规则的关键词匹配（检测"忽略之前的指令"、"你是一个"等注入模式）；基于模型的分类器（训练一个专门的注入检测模型）；以及 LLM-based 检测（用另一个 LLM 判断输入是否包含注入尝试）。
多层检测效果最好——规则层做快速过滤，模型层做深度检测。但要注意误报率——如果正常的用户输入被频繁误判为注入，用户体验会很差。
输入内容的安全审核。 检测用户输入中的有害内容（仇恨言论、暴力威胁等）、敏感个人信息（不应该被处理或存储的信息）、以及不合规内容（根据业务场景的合规要求）。
决策端防护
这是 Agent 特有的防护环节——Agent 做出工具调用决策后、实际执行之前，检查这个决策是否合规。
工具调用白名单验证。 确认 Agent 要调用的工具在其授权范围内。这在代码层做硬检查，不依赖 LLM。
参数合规性检查。 对工具调用的参数做校验——格式是否正确、值是否在允许范围内、是否涉及越权操作。比如 Agent 要执行一条 SQL，在执行前解析 SQL 确认是 SELECT 而不是 DROP。
操作风险评级。 根据工具调用的类型和参数自动评估风险等级。低风险（查询、搜索）自动放行；中风险（创建、修改）记录日志并放行；高风险（删除、发送、支付）拦截等待人工审批。
速率限制。 限制 Agent 在单位时间内的工具调用次数，防止异常行为（如被注入后疯狂调用 API）。
输出端防护
内容安全审核。 对 Agent 生成的回复做有害内容检测。可以用 OpenAI 的 Moderation API、Anthropic 的内容安全检测、或自建的审核模型。
敏感信息脱敏。 检测回复中是否包含敏感信息（身份证号、手机号、API Key、内部系统细节等），如果有则做脱敏处理或拦截。这对于 Agent 查询了数据库或内部系统后生成回复的场景特别重要。
事实性检查（可选）。 用另一个 LLM 或检查机制验证 Agent 的回复是否与工具返回的数据一致，防止幻觉。成本较高，适合高风险场景。
格式和协议检查。 确保输出符合预期的格式（如果约定了 JSON 格式输出，检查是否是合法 JSON）。防止格式错误导致下游系统处理失败。
Guardrails 框架
NeMo Guardrails（NVIDIA 开源）是目前比较成熟的 Guardrails 框架，提供了输入输出过滤、话题控制、事实检查等能力。Guardrails AI（guardrails-ai）专注于输出验证——定义输出的 schema 和约束，自动检测和修复不合规的输出。Anthropic 的 Claude 也内置了一些安全机制。
在实际项目中很多团队会自建 Guardrails，因为安全需求高度业务化——什么内容算"越界"、什么操作算"高风险"、什么信息算"敏感"，每个业务的定义都不同。
面试时可以这样答
Agent Guardrails 要覆盖三个关键位置：输入端、决策端和输出端。
输入端做意图分类拦截越界请求、Prompt 注入检测、以及内容安全审核。决策端是 Agent 特有的——Agent 要调工具之前，检查工具是否在白名单内、参数是否合规、操作风险等级如何。高风险操作必须人工确认。输出端做内容安全审核和敏感信息脱敏。
核心原则是"在代码层做硬约束"。LLM 是概率模型，任何通过 Prompt 做的安全约束都可能被绕过。工具白名单、参数校验、操作拦截这些必须在应用层代码里实现。
实际项目中 Guardrails 往往需要自建，因为安全规则高度业务化。也可以参考 NeMo Guardrails 这类框架做基础能力，再叠加业务定制的规则。
常见追问
- Prompt 注入检测的误报率怎么控制？
- 高风险操作的审批怎么设计不影响用户体验？
- 你在项目中用了什么 Guardrails 方案？效果如何？