Human-in-the-Loop 设计模式
核心
工具授权，核心的问题点就是自动化和安全性之间的天然对立性：
方案
方案一：无授权
直接让 Agent 执行敏感操作，没有任何授权环节。
方案二：执行前授权
流程：
- Agent 决定调用支付工具
- 系统拦截，弹窗让用户确认
- 用户确认后，执行转账
4，返回结果
问题一：授权时用的参数，和执行时的参数可能不一样了。
解决：授权时锁定参数，执行时校验。
上面的实现中，对于授权时锁定参数，但遗漏了关键的防重设计，如果auth_token被重复使用了怎么办？ 当前 token： 可以被重复使用 没有标记“已消费”
解决：在auth中维护使用状态
问题三：没有绑定用户身份，任何人拿到token都能执行
解决： 在实际的生产环境中，需要绑定用户身份
方案三：决策前授权（保守方案）
在 Agent 决定调用敏感工具之前就获取授权。
适用场景：高安全要求环境、企业级应用。
方案四：分级授权体系
根据敏感级别设计不同的授权策略。
适用场景：大型复杂系统、需要精细化安全控制的企业。推荐用于生产环境。
授权时机问题：之前还是之后？
执行前授权 + 参数锁定。
上下文同步问题
授权通过后，Agent 的上下文已经变了，参数还是原来那个吗？
| 变化情况 | 处理方式 |
|---|---|
| 参数变了 | 重新授权 |
| 意图变了 | 拒绝执行，重新开始 |
| 计划变了 | 提示用户，重新授权 |
批量敏感操作处理
如果一次订 10 张机票，需要 10 次授权吗？
根据数目不同执行的授权方式不同
授权有效期设计
根据不同行为设置不同有效期
面试话术
展示安全意识
"敏感工具授权的本质矛盾是：Agent 的优势是自动化，但自动化意味着减少用户干预；而安全意味着增加用户确认。这两者天然矛盾。我的设计思路是分级——低敏感操作放行，高敏感操作拦截，在保证安全的前提下最大化自动化。"
展示工程化思维
"我的设计包含五个核心组件：敏感级别定义器（定义哪些工具需要授权）、授权策略选择器（根据级别选择授权方式）、参数锁定器（锁定授权时的参数）、上下文同步器（同步授权时的状态）、有效期管理器（管理授权有效期）。每个组件独立可配置，便于扩展。"
展示实际项目经验
"我们上线后发现，80% 的操作是查询类（无需授权），15% 是普通操作（简单确认），只有 5% 是高敏感操作（显式确认）。通过分级授权，既保证了安全，又避免了过度干扰用户体验。"
展示权衡思维
"自动化和安全性是 Trade-off 关系。如果安全要求高，就增加授权环节，用户体验下降；如果追求用户体验，就减少授权环节，安全风险增加。我的方案是通过分级授权让用户选择：低敏感操作快速执行，高敏感操作强制确认。"
面试追尾
授权通过后，参数被人篡改了怎么办？
应该在授权时锁定参数，执行时校验参数哈希。如果参数变了，不仅要拒绝执行，还要记录安全事件。
如果用户连续点击授权会很烦怎么办？
可以设计"本次授权"和"本次会话授权"两种模式。本次授权只对当前操作有效，本次会话授权在会话期间内对同类操作有效。让用户选择。
紧急情况下需要跳过授权吗？
不应该跳过，但可以设计"紧急模式"——紧急模式下记录更详细的审计日志，事后可以追溯和审核。
授权可以代理吗？比如让管理员统一授权？
可以设计授权代理机制，但需要限制代理范围、代理时间、记录代理操作。敏感操作不建议代理。
在上面的设计中，还有什么需要补充的吗？
敏感工具授权的本质是一个多层的安全机制的设计问题，不能只靠Agent层来解决，在上面的设计中，分别介绍了 策略层（预授权），交互层（执行前授权），执行层（Tool执行校验），但是还有一些安全审计、监控相关的实现同样也是生产环境中不可缺少的部分，如（日志记录+防重放幂等设计+最小权限原则+上下文隔离限制+动态风险评估）等，也是我们在实现的过程中需要考虑的因素