Guardrails / Safety
这一节解决什么问题
Guardrails 解决的是 Agent 在真实环境中如何被约束、审查和保护的问题。
Agent 一旦具备 Tool Calling、文件操作、数据库查询、消息发送、配置修改等能力，就不再只是生成文本，而是在影响真实系统。此时安全不能只靠 Prompt 提醒，必须进入系统层设计。
Guardrails 的核心思想
Guardrails 的目标不是让 Agent 什么都不能做，而是让它在明确边界内做事。
核心原则：
- 低风险操作可以自动执行；
- 中风险操作需要额外校验；
- 高风险操作需要人工确认；
- 禁止操作必须在系统层拦截；
- 所有关键操作都要留下审计记录。
风险分级
低风险操作
例如搜索文档、读取公开知识库、生成草稿、汇总内容。
这类操作通常可以自动执行，但仍需要记录 Trace。
中风险操作
例如查询业务数据、生成 SQL、修改非关键草稿、调用内部接口。
这类操作需要参数校验、权限校验和结果检查。
高风险操作
例如删除数据、发送邮件、发布内容、修改生产配置、触发财务或权限变更。
这类操作必须经过人工确认或审批流。
禁止操作
例如访问密钥、泄露隐私、绕过权限、执行未知来源脚本、删除系统关键目录。
这类操作不能交给模型判断，必须由系统层拒绝。
Guardrails 应该放在哪里
不要只把安全规则写在 Prompt 里。更合理的分层是：
Prompt：说明安全原则
Tool Schema：限制参数形态
Runtime：控制流程和停止条件
Permission Gate：判断是否有权限
Hook：执行前后强制检查
Audit Log：记录关键操作
Human-in-the-loop：处理高风险确认Prompt 可以提醒 Agent，但不能作为唯一防线。真正的强约束应该放在 Runtime、Permission Gate、Hook 和工具执行层。
常见 Guardrails 类型
Input Guardrail
检查用户输入是否包含越权请求、敏感信息、Prompt Injection 或危险意图。
Tool Guardrail
检查工具调用是否合规，包括工具是否允许使用、参数是否安全、操作范围是否越界。
Output Guardrail
检查模型输出是否包含隐私泄露、错误承诺、危险建议或不该公开的信息。
Data Guardrail
控制 Agent 能访问哪些数据，哪些字段需要脱敏，哪些结果不能回填给模型。
Cost Guardrail
限制 token、调用次数、工具执行时长和并发，避免成本失控。
Workflow Guardrail
限制流程必须按顺序执行，例如必须先检索再回答、必须先评估再发布、必须先人工确认再执行。
Human-in-the-loop
Human-in-the-loop 是 Guardrails 中最重要的机制之一。它适合处理模型不应该自主决定的场景：
- 高风险操作确认
- 多个方案取舍
- 需要业务负责人审批
- 模型置信度不足
- 涉及用户隐私或合规风险
人工确认不应该只是弹窗，而应该包含：操作摘要、影响范围、关键参数、风险提示、可回滚方案。
和 Hook 的关系
Hook 是实现 Guardrails 的重要方式。
例如：
- 命令执行前检查路径是否安全；
- 文件写入后检查是否包含密钥；
- 工具调用前检查权限；
- 发布前检查是否通过构建；
- 输出前检查是否泄露敏感信息。
Hook 的价值在于它不会因为模型忘记规则而失效。模型可能忽略 Prompt，但 Hook 可以在系统层强制拦截。
常见误区
误区一：把安全完全写进 Prompt
Prompt 可以表达原则，但不能保证执行。安全边界应该由系统层实现。
误区二：所有操作都要人工确认
这样会让 Agent 失去效率。正确做法是按风险分级，只有高风险或不可逆操作需要人工确认。
误区三：只关注输入，不关注工具结果
工具返回结果也可能包含敏感信息、错误数据或超长噪声，需要清洗后再回填给模型。
误区四：没有审计记录
没有审计就无法复盘。关键操作必须记录谁触发、调用了什么、参数是什么、结果是什么、是否审批。
面试表达
可以这样表达：
> 我理解的 Guardrails 不只是 Prompt 里的安全提示，而是一套系统层控制机制。它包括输入检查、工具权限、参数校验、输出审查、成本限制、Hook 拦截和 Human-in-the-loop。低风险操作可以自动执行，高风险操作必须人工确认，禁止操作由系统层直接拒绝。这样 Agent 才能在真实业务环境里可控运行。