先想清楚「一个工具做几件事」
最常见的错误是做一个万能工具，参数一大堆。模型在参数多、语义模糊的接口上几乎一定会用错。反过来，粒度切得太细也不行——一次任务要调十几个工具，中间任何一步出错都会让整条链路断掉。
- 按用户意图切分工具，而不是按后端接口切分
- 一个工具只做一件能一句话说清的事
- 参数越少越好，能推断出来的默认值不要暴露给模型
- 只读操作与写操作必须分成两个工具
权限边界要放在工具这一层
把安全寄托在提示词上是不现实的。可靠的边界在工具实现里：危险动作要求二次确认、写操作限制影响范围、敏感数据在返回前脱敏。这样即使模型判断错了，越界操作也不会真的执行。
- 只读工具：放开，让模型自由探索
- 有副作用的写操作：默认需要确认，或先返回「将要做什么」的预览
- 不可逆动作：强制人工确认，且不提供批量入口
- 涉密数据：在工具内脱敏，不让原始内容进入模型上下文
调试按这个顺序排
链路出问题时，从下往上排比从上往下猜快得多：先用独立客户端直接调工具，确认它能跑通；再确认工具描述与参数schema没有歧义；然后单独测一次模型选工具的过程；最后才看多步编排。多数问题会停在第二步——不是模型笨，是描述写得让人看不懂。
工具描述是写给模型看的接口文档，它的清晰度直接决定调用准确率。