工具设计的目标不是「能做更多」，而是「做错时后果可控」。
四条原则
一、少而准
工具越多，模型选错的概率越高。优先做「职责单一、命名直白」的工具；能合并的相似工具就合并（例如一个带 channel 参数的发送工具，而不是六个 send_x）。
二、参数要有约束
· 枚举优于自由文本（能选就不要填）；
· 必填与选填分清，选填要有安全默认值；
· 参数名与描述写用途与边界，不只写类型（「时间范围，最长 90 天」比「string」有用得多）。
三、写操作要有边界
· 影响范围要小：能改一行就不要写一个批量接口；
· 幂等：同样的请求重复执行结果一致（否则重试就会重复扣款、重复发信）；
· 可回滚：留撤销手段或反向接口；
· 高风险操作必须二次确认，且确认信息要展示给真人看（人看得懂才叫确认）。
四、错误要能自解释
返回结构化错误（错误码 + 人类可读原因 + 建议动作），而不是一句「失败」。模型会据此改参数重试，否则它只会反复撞墙。
三个反面例子
· 万能工具：一个能发任意 HTTP 请求的工具——等于把系统权限交给模型；
· 隐式副作用：读接口里顺手写日志或更新统计，让「只读」变成不可预测；
· 无上限批量：删除接口接受任意长度列表，一次失误清空一批数据。
常见的参数设计对照
· 不好：一个任意表达式字符串；好：关键词字符串 + 上限 1~50；
· 不好：任意文件路径；好：从可选文档列表里挑一个；
· 不好：一个任意对象；好：明确字段与类型。
上线前的检查
1. 每个工具问一句：它被误用时最坏会怎样？ 答不上来就先别接；
2. 写操作逐个确认幂等性与回滚方案；
3. 统计工具调用失败率与「模型选错工具」的比例，按数据精简工具集——这通常比加工具更能提升完成率。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：让模型稳定输出 JSON：约束、校验与重试的工程做法
下一篇：响应慢在哪里：把首字延迟与总时长分开优化 →
第 11 / 171 篇