# 为什么智能体在无人值守时格外危险，以及怎么给它装护栏

自主执行放大了模型的固有风险，三种工程化护栏方案：人类审批中断、结构化校验、多智能体分工协作

> 护栏 · 可靠性 · 人在回路 · 约 5 分钟 · 07 月 11 日

## 本篇要点

1. 智能体在自主执行时，模型的幻觉、跑偏、死循环等缺陷从'可见的聊天错误'变成'静默的生产事故'，代价远高于聊天机器人
2. 中断-检查点-恢复模式是最可靠的高风险操作拦截方案：在模型调用被标记的工具前暂停执行，序列化状态，等待人类审批后恢复
3. 有外部验证信号（工具执行结果、独立验证器）的护栏模式，比完全依赖模型自我评估的模式可靠得多

---

前几篇我们一直在讲如何让智能体"动起来"——套上 ReAct 循环、注册工具、加上记忆和规划，它就能自主执行多步任务了。但如果你打算把它真正部署到生产环境里，哪怕是发一封邮件、改一条数据库记录这样的小操作，你也必须面对一个事实：**智能体在无人值守时犯错的代价，远比聊天机器人高得多。**

一个聊天机器人答错了，用户看到的是错的，但通常没有实际损害。一个智能体调错了工具——参数填错、调了不该调的工具、或者在同一个步骤上循环上千次——造成的可能是真实世界的经济损失、数据污染或安全事件。这篇就来拆解为什么自主执行放大了模型的固有风险，以及当前工程上最主流的三种护栏方案。

## 为什么自主执行放大了风险

模型本身就会幻觉、会跑偏、会重复。但在"你问它答"的聊天模式下，这些缺陷是暴露的——用户看到了可以纠正、可以追问。智能体模式下，同样的缺陷变成了**静默执行**：模型调用了一个工具，你作为开发者可能几小时后甚至几天后才发现它做了什么。

从一篇工程博客里总结的智能体生产翻车案例来看，最常见的五类故障是[[1]](#ref1)：

- **工具调用幻觉**：模型调用了不存在的工具，或给正确的工具填了错误的参数
- **死循环**：反复调用同一个工具，永远不收敛，一夜烧掉一个月的 API 预算
- **上下文爆炸**：历史越滚越长直至超限，导致报错、变慢、成本飙升
- **不可复现**：同样的输入两次给出不同答案，无法调试
- **成本失控**：单次任务消耗远超预期，无人察觉

这些问题的共性在于：**模型在自主行动时，没有人给它踩刹车。**

## 护栏一：关键动作前加人类审批（interrupt）

最直接也最可靠的护栏是：在模型执行高风险操作之前，暂停执行，等人批准。

**中断-检查点-恢复模式**是当前主流框架（LangGraph、OpenAI Agents SDK）都支持的实现方式[[2]](#ref2)[[3]](#ref3)。它的工作流程是：

1. 模型发出一个被标记为"需要审批"的工具调用
2. 框架不执行该工具，而是将当前状态序列化，暂停执行
3. 外部系统（可以是 Slack 消息、审批面板、API）通知人类审核员
4. 人类批准或拒绝该调用
5. 框架读取序列化状态，从暂停处恢复执行

这个模式的关键设计是**状态自足（self-contained）**：检查点中保存的上下文要足够完整，让恢复执行时不需要重新查询外部系统——因为外部状态在等待期间可能已经变了[[2]](#ref2)。

一个实用的风险分级方案是：对只读、无副作用的查询操作自动放行；对写入操作、金融交易、大规模外发通信、删除操作等标记为"需审批"；对超出模型动作空间的操作直接拦截[[1]](#ref1)。

## 护栏二：对模型输出做结构化校验

人类审批能拦截高风险操作，但不能处理所有场景——每步都等人审批，自主性就没了。对于中等风险的操作，更实用的方案是**程序化校验**：在模型输出到达工具执行层之前，用代码验证它的格式、参数范围和业务逻辑。

校验可以发生在多个层面[[4]](#ref4)：

- **输入护栏**：在用户消息进入主模型之前，拦截不当请求
- **输出护栏**：在模型最终答案返回给用户之前，验证或脱敏
- **工具护栏**：在工具调用之前或之后，校验参数和结果

工具护栏是最实用的例子。当你给模型注册一个`send_email(to, subject, body)`工具时，可以在工具内部加一层校验：`to`必须是合法邮箱格式，`subject`不能为空，`body`不超过指定长度。如果校验失败，工具返回一个结构化错误消息，比让模型收到空回复或崩溃要安全得多。

一篇关于 LLM 多智能体系统可靠性模式的综述指出，**有外部验证信号（工具执行结果、编译结果、单元测试、检索结果）的模式，比完全依赖模型自我评估的模式可靠得多**[[5]](#ref5)。模型自我纠正（self-correction）在推理密集型任务上反而可能退步，但加上一个外部验证器（validator agent 或 judge）后，可靠性有显著提升。

## 护栏三：多个各司其职的智能体协作分工

单个智能体既要规划、又要执行、又要验证——这相当于让一个人既当项目经理又当工程师又当 QA。更可靠的架构是把这些角色拆成多个各司其职的智能体[[6]](#ref6)：

- **规划器（Planner）**：分解任务，生成子任务列表和依赖关系
- **执行器（Executor）**：执行具体的子任务，只能访问与其角色相关的工具
- **验证器（Validator）**：检查执行器的输出是否符合预期，不符合时触发重试或上报

这种分工带来的好处很直接：执行器只能访问最小权限的工具集（比如搜索助手只能读不能写），验证器用独立的模型来评估结果（避免了"自己检查自己"的盲区），规划器在更高层面协调全局。

**最小权限原则**是这里的关键：给每个智能体只分配它完成任务所需的最少工具。一个只负责查找信息的智能体不需要"删除数据库记录"的能力。如果它真的调了不该调的工具，那也不是幻觉的问题——是工具注册表的问题[[1]](#ref1)。

## 别等出事了才加护栏

工程化的核心观念是：**护栏不是在模型犯错后补救，而是在模型犯错前约束它可行动的范围。** 一个 demo 能跑通和一套系统能上线，中间隔的正是这些不性感的工程——注册表、中断点、校验函数、最小权限[[1]](#ref1)。

模型越强，低级的错误越少，但概率性输出的本质不会变。护栏决定的是系统的下限，而生产系统的稳定性恰恰由下限决定。下一期我们进入一个更实操的话题：工具描述（tool schema）怎么写，才能让模型更少地调错工具、更少地填错参数。

## 来源

1. [智能体工程化实战：五种生产翻车模式 + 护栏设计决策树 + 七条工程铁律](https://blog.biekanle.com/technicalcourse/26399.html)
2. [审批门禁设计：中断-检查点-恢复模式详解，含审批疲劳、拒绝反馈循环、熔断机制](https://tianpan.co/zh/blog/2026-03-06-designing-approval-gates-for-autonomous-ai-agents)
3. [OpenAI Agents SDK 人在回路文档：interrupt 机制、状态序列化与恢复 API](https://openai.github.io/openai-agents-python/zh/human_in_the_loop/)
4. [OpenAI 护栏与人工审核指南：输入/输出/工具三层护栏，审批生命周期](https://developers.openai.ac.cn/api/docs/guides/agents/guardrails-approvals)
5. [LLM 多智能体系统可靠性模式综述：六种工程模式及其证据等级，外部验证信号的关键作用](https://linus-teklenburg.de/reliability)
6. [Harness Engineering 五要素：动作空间注册表、人工检查点、执行边界、审计日志、回滚机制](https://jishuzhan.net/article/2064335034152202242)

---

原文：https://pangzhengboyin.com/articles/agent-guardrails-for-autonomy-68e98ea2

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com