AI Agent 工具调用设计
很多团队把工具调用理解成“给模型多几个函数”。真正上线之后才会发现，难点不在函数数量，而在这四个问题：
- 模型什么时候该调用工具。
- 工具参数怎么限制。
- 调用失败后怎样回退。
- 整个过程如何审计与复盘。
如果这些边界不先设计，工具越多，系统越不稳定。
1. 工具调用不是能力堆叠，而是责任分工
模型擅长的是理解意图和组织决策，工具擅长的是执行确定动作。
所以一个好工具，不应该让模型“自由发挥”，而应该让模型在可控边界内完成调用。
| 层级 | 应做的事 | 不该做的事 |
|---|---|---|
| 模型 | 判断是否需要工具、组织参数 | 直接拼任意危险指令 |
| 工具协议层 | 校验参数、鉴权、记录日志 | 承担模糊推理 |
| 工具执行层 | 真正读写系统资源 | 推测用户真实意图 |
2. 工具设计先看“最小可调用单元”，不要先看函数名
真正应该先想清的是：一次调用要完成什么最小动作。
例如“发布文章”这个需求，不要一上来设计成一个大工具包办所有事情。更稳的拆法可能是：
- 读取草稿元数据。
- 生成摘要。
- 校验 frontmatter。
- 执行发布。
越是高风险动作，越应该拆小，而不是做成一键万能工具。
3. 参数模式比自然语言说明更重要
如果你只是写“这个工具可以创建文章”，模型仍然有大量误用空间。
更稳的做法是给工具明确 schema：
{
"name": "publish_article",
"input_schema": {
"type": "object",
"properties": {
"slug": { "type": "string" },
"category": { "type": "string" },
"confirm": { "type": "boolean" }
},
"required": ["slug", "confirm"]
}
}
工具 schema 的意义，不只是让模型“更好调用”，更是让你能校验、拒绝和审计。
4. 一个常见失败案例：把高风险写操作暴露成“无确认工具”
典型事故链路是：
- 工具允许直接删除、覆盖、发布。
- 模型根据模糊意图做出激进调用。
- 没有人类确认，也没有 dry run。
- 最后线上状态被误改。
根因是把“工具存在”误当成“工具就该自动执行”。
修复方式通常是：
- 高风险工具默认只返回预览结果。
- 真正执行前必须二次确认。
- 保留回滚点和操作日志。
5. 权限与环境隔离，决定工具调用是否可上线
工具调用最怕两个混淆：
- 把开发环境和生产环境权限混在一起。
- 把“可读”和“可写”当成一类能力。
更稳的权限模型通常至少分三层：
- Read only
- Propose only
- Execute with approval
这样即使模型判断错了，也不会立刻造成不可逆后果。
6. 失败兜底要能回答“是模型错了，还是工具错了”
工具调用失败时，至少要分清三种情况：
- 模型给了错误参数。
- 工具内部异常。
- 权限或资源条件不满足。
如果所有失败都汇总成一个“tool call failed”，你根本没法优化下一版系统。
7. 上线前 Checklist
- 已定义最小可调用单元，而不是一键万能工具。
- 每个工具都有明确 schema 与参数校验。
- 高风险工具默认不可直接执行。
- 开发、测试、生产环境权限已经隔离。
- 工具调用日志能区分模型错误与工具错误。
- 已为关键工具准备 dry run 或预览模式。
- 已定义回滚路径和人工接管流程。
- 新增工具前有注册、审批与废弃策略。
FAQ
工具越细越好吗？
不一定。太粗会失控，太细会让调用链过长。关键是围绕最小业务动作设计，而不是机械拆分。
Function Calling 和 Agent 工具调用是同一回事吗？
不是。Function Calling 更像协议能力，Agent 工具调用还包含权限、流程、失败恢复和治理问题。
工具调用一定要有人审批吗？
不是所有都要，但高风险写操作和外部资源变更，默认应该有人类确认。
