很多团队做 AI Agent 时，精力都放在模型能力上：

- 选哪个模型
- 推理够不够强
- 上下文窗口够不够长
- 多轮对话稳不稳

这些当然重要。但 Agent 真正上线之后，最容易出问题的，往往不是模型变笨了。

而是：

**工具调用链路失控。**

Agent 和普通大模型应用最大的区别，就是它会自己决定调用什么工具、传什么参数、执行什么操作。一旦这条链路没接住，模型再强也会出事——选错工具、传错参数、副作用不可回滚、权限边界没守住。

这篇拆解 Agent 上线后最容易失控的 4 个环节，以及一个最小可用的工具调用治理框架。

---

## 一、为什么 Agent 上线后最先出事的不是模型

先说清楚一个反直觉的事实：Agent 上线后出问题，多数不是模型能力不够。

原因有 3 个：

### 1）模型能力有上限，但工具调用没有上限

模型能力是有限的，你能预判它大概能做什么。但工具调用是开放的——工具数量会涨，工具组合会变，工具的副作用会叠加。一个看起来不复杂的工具集，组合起来的调用路径可能远超模型能稳定处理的范围。

### 2）模型出错是回答层面的，工具出错是执行层面的

模型答错了，用户最多觉得"回答不好"。但工具调用出错了，就是真的执行了错误操作——发了一封邮件、改了一条数据、调了一次付费 API、删了一个文件。错误从"信息层"升级到了"物理层"。

### 3）模型出错容易发现，工具出错不容易发现

模型答错了，用户能直接看到。但工具调用出错了，往往藏在链路中间——模型选了工具、传了参数、拿到了结果、继续推理，最后给了一个看起来正常但实际错误的回答。团队不特意追踪，根本发现不了。

Agent 真正的风险，不在模型层，而在工具调用层。

---

## 二、失控 1：工具选择错误——模型选了不该选的工具

这是最常见的失控方式。

Agent 接了一堆工具：查询类、写入类、通知类、分析类。模型在推理时，要根据用户意图选一个合适的工具。但这个选择，比想象中更容易出错。

### 更像真实现场的过程

用户问"帮我查一下昨天的订单情况"。Agent 有两个工具：`query_orders`（查询订单）和 `send_report`（发送报告）。模型选了 `send_report`，把报告发给了全组。

原因不是模型笨，而是 `send_report` 的描述里写了"用于同步团队信息"，和"查订单情况"在语义上有一点点沾边。模型就选了。

### 为什么容易失控

- 工具描述写得模糊，多个工具的适用场景有重叠
- 工具数量多了之后，模型在候选集里选对的概率会下降
- 工具名称相似但语义不同，模型容易混淆
- 上下文里有历史调用记录，模型会"跟着惯性"选上一次选过的工具

### 真正该补的是什么

- 工具描述要写清"什么时候用"和"什么时候不用"
- 相似工具要在描述里显式区分
- 工具选择结果要可追踪——模型为什么选了这个工具，理由要留痕
- 高风险工具（写入、通知、删除）要加二次确认，不能让模型直接选了就执行

### 一句判断

**工具选择错误，往往不是模型的问题，而是工具描述和候选集设计的问题。**

---

## 三、失控 2：参数构造错误——参数从哪来、对不对、能不能验证

工具选对了，参数构造还可能出错。

Agent 调用工具时，参数来源通常有 3 种：

- 模型从用户输入里抽取
- 模型从上下文里推断
- 模型自己生成

每一种来源都可能出错，而且错误方式不一样。

### 更像真实现场的过程

用户说"把上周的会议纪要发给张三"。Agent 调 `send_email` 工具，参数构造出问题了：

- 收件人：模型从上下文推断"张三"，但团队里有两个张三，模型选了邮箱后缀更短的那个
- 主题：模型自己生成了"上周会议纪要"，但实际纪要标题是"Q3 复盘会议纪要"
- 附件：模型从上下文里抽取了"上周会议纪要"，但抽取的是两周前的版本

邮件发出去了。收件人错了、主题不对、附件是旧的。但 Agent 觉得任务完成了。

### 为什么容易失控

- 参数从用户输入抽取时，用户表述本身就有歧义
- 参数从上下文推断时，上下文里可能有多个候选，模型选了错的
- 参数模型自己生成时，没有外部事实校验，纯靠"猜"
- 参数没有类型校验和范围校验，模型传了不合预期的值也能执行

### 真正该补的是什么

- 参数来源要标记——是抽取的、推断的、还是生成的
- 关键参数要做事实校验——收件人是否存在、是否有多个匹配、附件是否是最新版本
- 参数要有 Schema 校验——类型、范围、枚举值、必填项
- 高风险参数（收件人、金额、操作对象）要加确认环节，不能让模型直接传了就执行

### 一句判断

**参数错误是工具调用里最隐蔽的失控——选错工具会被发现，传错参数可能藏在正常执行里。**

---

## 四、失控 3：副作用不可回滚——写操作没有 dry-run 和确认

工具调用里最危险的，是带副作用的写操作。

读操作出错了，最多查不到数据。但写操作出错了，就是真的改了系统状态——发邮件、改数据、调付费 API、删文件、触发流程。这些操作往往不可回滚。

### 更像真实现场的过程

Agent 有一个 `update_database` 工具。某次模型判断需要更新一条记录，调了工具，把 `status` 字段从 `active` 改成了 `cancelled`。但这条记录是测试数据，模型从上下文里误判了它的状态。

团队发现的时候，记录已经被改了。回滚不了，因为工具没有记录"改之前是什么值"。只能手动查日志、手动恢复。

### 为什么容易失控

- 写操作默认直接执行，没有 dry-run（预演）环节
- 写操作没有记录"改之前是什么"，回滚时不知道恢复成什么
- 写操作的幂等性没保证——重试一次就改两次
- 高风险写操作没有分级——发邮件和删数据用同一套执行逻辑
- 没有审批或确认环节——模型决定调用就直接执行

### 真正该补的是什么

- 写操作分等级：低风险（日志、状态标记）可直接执行，高风险（删除、通知、付费）要加确认
- 写操作默认 dry-run：先预演执行结果，用户或策略确认后再真正执行
- 写操作要记录前值：改之前是什么、改成什么、谁改的、什么时候改的
- 写操作要幂等：同一个调用重试不会重复执行
- 写操作要有副作用范围控制：一个工具能改什么、不能改什么，边界要明确

### 一句判断

**模型"决定调用"不等于"应被执行"。决策面和执行面必须分开。**

---

## 五、失控 4：权限边界没守住——工具能访问什么、不该访问什么

这是最容易被忽略、但风险最高的一类失控。

Agent 的工具能访问什么数据、能调什么系统、能操作什么范围，往往没有清晰的边界。一旦模型在调用时越权，后果不亚于一次安全事故。

### 更像真实现场的过程

Agent 有一个 `query_customer_info` 工具，能查客户信息。某次用户 A 通过 Agent 问"帮我查一下客户 B 的订单"。Agent 调了工具，返回了客户 B 的全部信息——包括 A 本不该看到的合同金额和折扣。

原因不是模型越权，而是工具本身没有做权限校验——谁在调、能看什么字段、能查哪个范围，工具层完全没管。

### 为什么容易失控

- 工具没有按角色/租户/用户做权限隔离
- 工具返回的数据没有做字段级脱敏——能查到的就全返回
- 工具能访问的系统范围没有限制——一个工具能查全库
- 提示注入风险——用户通过输入诱导模型调用不该调用的工具
- 工具的访问凭证管理松散——谁都能用同一套凭证调所有工具

### 真正该补的是什么

- 工具层做权限校验：谁在调、能调什么、能看什么字段
- 工具返回数据要脱敏：按调用者权限返回不同字段
- 工具访问范围要限制：按租户/部门/角色做数据隔离
- 工具凭证要隔离：不同场景用不同凭证，不能一套凭证通吃
- 提示注入防护：对用户输入做校验，防止诱导调用高风险工具

### 一句判断

**工具调用安全不是模型层的事，是工具层和执行层的事。模型不该承担全部安全责任。**

---

## 六、一个最小可用的工具调用治理框架

如果想避免工具调用失控，最值得先做的不是加更多工具，而是建一个最小治理框架。

### 第一步：工具注册和分类

- 所有工具必须注册，不能散落在代码里
- 工具按风险分级：读操作、写操作、高风险操作
- 工具按权限分级：公开、内部、敏感

### 第二步：调用决策和执行分离

- 模型负责"决定调用什么工具、传什么参数"
- 执行器负责"校验权限、校验参数、执行操作、记录日志"
- 模型的决策不等于执行，必须经过执行器的校验和放行

### 第三步：关键决策点留痕

- 工具选择原因：为什么选了这个工具
- 参数来源：每个参数从哪来
- 执行结果：执行了什么、返回了什么、改了什么
- 失败原因：为什么失败、是否重试

### 第四步：写操作分级保护

- 低风险写操作：可直接执行，但要记录日志
- 中风险写操作：要 dry-run + 确认
- 高风险写操作：要人工审批 + 完整审计

### 第五步：可观测性和复盘

- 工具调用成功率、失败率、重试率要监控
- 工具选择错误率要监控——模型选错工具的频率
- 参数错误率要监控——参数校验失败的频率
- 高风险操作要告警
- 生产事故要回灌成测试样本

### 这个框架的价值

这 5 步不复杂，但它们决定了：

**Agent 是一个"能自己调工具的玩具"，还是一个"能被治理的生产系统"。**

工具调用治理，是 Agent 从 Demo 走向生产的第一道门槛。

---

## 七、结语

Agent 上线后最容易失控的，不是模型能力，而是工具调用。

模型能力有上限，你能预判。但工具调用是开放的——工具数量会涨，参数组合会变，副作用会叠加，权限边界会模糊。

4 个最容易失控的环节：

- 工具选择错误
- 参数构造错误
- 副作用不可回滚
- 权限边界没守住

这 4 个环节出问题，都不是模型层能解决的。它们需要的是工程治理：工具注册分类、决策执行分离、关键决策留痕、写操作分级保护、可观测性和复盘。

对技术负责人来说，做 Agent 最该先建立的，不是"模型够不够强"的判断，而是：

**工具调用链路有没有被治理住。**

如果工具调用没有被治理，Agent 就只是一个"能自己执行操作但没人能兜底"的系统。模型越强，能调的工具越多，失控的时候就越难收拾。

而真正能把工具调用治理住的，不是一个更好的模型，而是一个能把决策、执行、审计、回滚分层管起来的统一治理层。这正是网关层在 Agent 时代该承担的新角色。