粒度取决于动作是否经常独立使用，以及业务规则能否由程序稳定封装。工具越细，组合更灵活，但调用轮次更多，模型也更容易遗漏步骤。 例如把“读取余额、减余额、创建流水”分别暴露给模型，容易出现部分成功。更合适的是提供受控的业务接口，由后端在事务中完成这些操作。 另一方面，把所有事情塞进一个“处理用户请求”工具，参数和行为都不透明，也不利于模型选择。查询、试算、提交通常值得分开，方便先展示结果再执行有副作用的动作。  实践中可采用“稳定业务动作封装，探索性查询保留细粒度”的方式。根据任务成功率、调用次数和误用情况调整，不单纯追求工具数量少。