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

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

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

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

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

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

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

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

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

中断-检查点-恢复模式 是当前主流框架（LangGraph、OpenAI Agents SDK）都支持的实现方式23。它的工作流程是：

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

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

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

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

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

校验可以发生在多个层面4：

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

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

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

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

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

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

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

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

别等出事了才加护栏

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

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