Guardrails and Human-in-the-Loop
当一个 AI Agent 只是做摘要、分类、整理时，风险通常还比较可控。
但一旦它开始具备下面这些能力，问题就不一样了：
- 调内部 API
- 改数据
- 发消息
- 下命令
- 触发外部流程
这时候系统就不再只是“会回答”，而是开始“会行动”。
而只要系统会行动，就一定会碰到一个工程上非常关键的问题：
哪些事情可以自动做，哪些事情必须加限制，哪些事情应该让人来确认。
这篇文档重点讲的就是：
- 什么是
Guardrails - 什么是
Human-in-the-Loop - 为什么 Agent 越能做事，这两层越重要
- 真实系统里该怎么设计边界
1. 什么是 Guardrails
Guardrails 可以理解成系统的护栏、边界和约束机制。
它的目标不是让 Agent “什么都不能做”，而是让它：
- 在允许范围内做事
- 在高风险边界前停下来
- 在不确定时不要擅自行动
所以 Guardrails 的本质不是“削弱能力”，而是“让能力可控”。
2. 什么是 Human-in-the-Loop
Human-in-the-Loop 可以理解成：
在关键节点把人纳入决策闭环。
它通常意味着：
- 某些动作需要人工确认
- 某些结果需要人工审核
- 某些异常需要人工接管
所以它的重点不是“人一直手动干 活”，而是：
在高风险节点，人保留最终控制权。
3. 为什么 Agent 比普通 AI 系统更需要 Guardrails
因为 Agent 的风险不只来自“说错话”，还来自“做错事”。
比如：
- 调错工具
- 用错参数
- 在错误上下文里执行动作
- 把不确定判断当成确定结论
- 在没有权限时继续推进
这类问题的后果可能包括：
- 数据被误改
- 外部消息误发
- 审批链路被误触发
- 内部资源被错误调用
所以越是有行动能力的 Agent，越需要 Guardrails。
4. Guardrails 通常保护什么
一个比较完整的 Agent 系统，Guardrails 通常会覆盖下面几层。
4.1 输入边界
也就是用户输入是否合规。
比如：
- 是否含有敏感内容
- 是否在允许任务范围内
- 是否试图越权
4.2 工具边界
也就是 Agent 到底能调用哪些工具。
比如：
- 哪些工具只读
- 哪些工具可写
- 哪些工具只允许部分角色使用
4.3 参数边界
工具即使能调，也不代表参数可以随便给。
比如：
- 金额上限
- 时间范围
- 资源作用域
- 白名单对象
4.4 动作边界
也就是哪些动作可以自动执行，哪些必须停下来确认。
4.5 输出边界
也就是最终给用户的内容是否合规、是否暴露不该暴露的信息。
5. 哪些动作通常应该要求人工确认
你可以把下面这些动作优先视为高风险 ：
- 删除
- 写入
- 发送
- 对外发布
- 涉及金钱
- 涉及权限变更
- 涉及敏感数据
一个非常实用的原则是：
可逆、低风险、低影响的动作更容易自动化；不可逆、高风险、高影响的动作更适合引入人工确认。
6. 一个简单但很实用的风险分层
可以先把 Agent 动作分成 3 层：
6.1 Low Risk
例如：
- 总结
- 检索
- 草稿生成
- 只读查询
这类动作通常可以自动执行。
6.2 Medium Risk
例如：
- 修改草稿
- 生成建议配置
- 准备待发送内容
这类动作通常可以自动完成，但最好留给人确认最终提交。
6.3 High Risk
例如：
- 删除数据
- 发送正 式通知
- 执行写入型 API
- 触发财务或权限操作
这类动作一般应默认要求人工确认。
7. Guardrails 不只是权限控制
很多人一提 Guardrails，就只想到“权限校验”。
但真实系统里，它还包括：
- 范围限制
- 频率限制
- 成本限制
- 步数限制
- 结果校验
- 异常回退
比如：
- 最多执行 8 步
- 最多重试 2 次
- 单次成本不能超过某个阈值
- 如果结果置信度不足，必须停下来
这些都属于 Guardrails。
8. Human-in-the-Loop 常见放在哪里
8.1 执行前确认
最常见的一种方式。
比如：
- “是否确认发送这封邮件？”
- “是否确认删除这些记录？”
8.2 执行后审核
系统先生成结果，但由人做最终审批。
比如：
- 自动写一份报告草稿
- 自动生成一份客户回复
8.3 异常时接管
当系统遇到这些情况时自动交给人：
- 多次失败
- 风险判断不明确
- 结果冲突
- 权限不足
9. 一个推荐的系统设计思路
真实项目里，一个稳健的 Agent 系统通常不是：
- 模型说能做就直接做
而更像是：
- 模型提出下一步动作
- 系统检查是否符合 Guardrails
- 如果低风险，自动执行
- 如果高风险，转人工确认
- 如果异常，触发人工接管
可以抽象成：
Propose Action -> Check Policy -> Auto Execute or Ask Human -> Observe Result
这条链路很关键，因为它把“模型的建议”和“系统的执行权”分开了。
10. 为什么“能做”和“应该自动做”不是一回事
这是 AI Agent 里特别重要的一句判断。
系统可能在技术上已经能：
- 调 API
- 执行写入
- 自动发消息
但这不代表它应该默认自动做。
真正要问的问题通常是：
- 这件事风险高不高
- 出错代价大不大
- 是否可回滚
- 是否需要责任归属清晰
所以很多成熟系统会选择：
- 自动生成建议
- 但保留人工确认
这并不是“能力不够”，而是“治理更成熟”。
11. 常见误区
11.1 护栏越少越智能
没有护栏并不等于更强，只是更不可控。
11.2 只要工具权限收紧就够了
权限只是第一层，参数范围、执行频率、风险等级同样重要。
11.3 Human-in-the-Loop 就是低效
如果把人放在真正高风险节点，反而能显著降低整体风险和返工成本。
11.4 一刀切全人工或全自动
更成熟的做法通常是：
- 低风险自动化
- 中风险半自动
- 高风险人工确认
12. 一句话总结
如果说 Tool Use 和 Agent Engineering 让系统开始具备“做事”的能力，那么：
Guardrails解决的是“哪些事情能做、做到什么边界”Human-in-the-Loop解决的是“哪些关键节点必须把人纳入控制闭环”
真正可交付的 Agent 系统，追求的通常不是“全自动做一切”，而是：
在自动化效率和可控性之间找到一个足够稳的平衡点。