Appearance
47. 如何确保 Agent 的行为安全、可控且符合人类意图？
难度 P0 必背 · 岗位 应用 · 频率 ★★★ · 预计阅读 5 min
👔面试官：如何确保 Agent 的行为安全、可控且符合人类意图？
🙋♂️我：做模型对齐，用 Prompt 约束。
👔面试官：不够。模型对齐只能提供基础边界，应用层必须补四层治理：提示层、工具权限层、执行流程层、观测审计层。还有预算和熔断。你能系统讲吗？
TL;DR 速记
- 是什么：Agent 安全不是只靠模型对齐，而是应用层四层治理：提示、权限、流程、审计。
- 关键点：工具最小权限、参数校验、人机审批、预算熔断、全链路 trace 要一起设计。
- 怎么答：模型负责基础边界，系统负责业务边界；高风险动作必须由代码、权限和流程兜住。
图解
💡 简要回答
四层治理：
| 层级 | 措施 |
|---|---|
| 模型与提示层 | System Message 明确角色、边界、安全规则、拒答策略 |
| 工具与权限层 | Schema约束、鉴权、参数校验、最小权限 |
| 执行与流程层 | 最大步数、超时、人工审批、转人工、失败兜底 |
| 观测与审计层 | 调用日志、trace、决策点记录、人工复盘 |
预算与熔断：
- 最大工具调用次数、Token预算、费用预算
- 连续失败停止、异常率告警
核心：模型对齐解决"基础行为别太离谱"，应用治理解决"在你的业务系统里别出事"。
常见踩坑与反例
踩坑 1：只靠 System Prompt 做安全
错误描述：「在提示词里写不要做危险操作就够了。」
正确做法：Prompt 只能提供软约束。真正的权限、参数校验、敏感操作审批必须由应用代码和权限系统执行。
踩坑 2：工具权限过大
错误描述：给 Agent 一个通用数据库执行工具或管理员 API。
正确做法：按最小权限拆工具，限制可访问资源、可执行动作和参数范围；写操作默认需要审批或二次确认。
踩坑 3：没有预算和熔断
错误描述：让 Agent 一直重试、一直调用工具，直到模型觉得完成。
正确做法：设置最大步数、Token 预算、费用预算、超时、连续失败停止和异常率告警。
踩坑 4：没有审计日志
错误描述：出问题后只看到最终回答，不知道中间调了什么工具。
正确做法：记录用户输入、模型决策、工具参数、工具结果、审批动作和最终输出，方便复盘和合规审计。
面试官可能继续追问
追问 1：高风险工具怎么设计权限？ 答题要点：工具按动作拆小，默认只读，写操作加鉴权、参数白名单、审批和审计；不要暴露通用执行入口。
追问 2：如何做 Human-in-the-loop？ 答题要点：在转账、删除、发布、发邮件等关键节点暂停，展示计划和参数，人工确认后再继续执行。
追问 3：Prompt Injection 怎么防？ 答题要点：区分系统指令和外部内容，对检索内容降权，不让外部文本覆盖系统规则；工具调用前做权限和参数校验。
追问 4：安全效果怎么评估？ 答题要点：构造红队用例、越权用例、恶意输入、异常工具返回，观察拒答率、误拒率、越权调用率和人工介入命中率。
📝 详细解析
四层治理深入展开
模型与提示层：System Message 是第一道防线，明确 Agent 的角色、禁止动作、拒答策略。但这只是软约束——模型可能被 Prompt Injection 绕过，所以必须有后续三层的硬约束兜底。
工具与权限层：每个工具都应该遵循最小权限原则。例如：
- 查询 DB 的工具只有 SELECT 权限，无 INSERT/DELETE
- 发邮件工具限制收件人域名白名单
- 所有工具的参数输入做类型校验和范围检查，防止 SQL 注入等攻击
执行与流程层：设置硬性约束——最大步数（如 20 步）、最大运行时间（如 5 分钟）、最大 Token 消耗预算。高风险动作（转账、删除、发布）插入人工确认节点，不允许 Agent 自动执行。
观测与审计层：记录每一步的输入、输出、工具调用参数和结果。关键点是用统一的 trace_id 串联整个链路，事后可以完整重放和审计每一个决策。
Prompt Injection 防御
外部内容（用户上传文档、网页搜索结果）是 Prompt Injection 的主要攻击面。防御措施：
- 结构化区分系统指令区和外部内容区（不同 XML 标签）
- 工具调用前做独立的权限检查，不依赖模型的「判断」
- 对检索内容降权——不允许检索内容覆盖系统指令
🎯 面试总结
四层治理 + 预算熔断。模型能力 + 权限边界 + 流程控制 + 人机协同。