智能体工具设计：名称清楚，还不够

一个工具应表达一个可以辨认的业务意图

“处理客户”这样的名称过于宽泛，查询资料、更新联系人和发送通知可能被混在一起。更清楚的工具边界能够让智能体判断何时使用，也让审核者理解动作的影响。

输入字段应使用业务含义明确的名称，说明单位、取值范围和必填条件。对于已有正式标识的对象，优先使用标识进行操作，避免仅凭相似名称选错客户或产品。

查询与改变状态，应有不同要求

读取资料和修改业务记录的影响不同。工具目录可以明确标注动作性质，并在执行层校验身份、对象范围与必要确认。不能只在提示词里写“谨慎操作”，却让工具本身接受任意目标。

涉及多个步骤时，尽量让智能体先展示拟操作对象和关键参数，再进入对应执行流程。具体是否需要人工确认，应由业务授权决定，而不是每次凭模型语气判断。

错误结果也属于工具说明的一部分

工具失败时，应提供能够区分原因的信息，例如对象不存在、参数不符或状态已经变化。含混的“失败”会诱使智能体盲目重试或猜测参数。

同时避免在错误信息中暴露无关敏感数据。对允许重试的情况给出明确规则，对不可继续的情况提供合理去向。工具返回值应便于程序校验，也便于人理解。

用容易混淆的任务测试工具选择

测试集可以包含相似工具、缺失输入和不应执行的请求，观察智能体是否选对动作、是否会询问关键条件。只测试工具能够成功调用，还不足以说明工具目录设计合理。

未来工具数量增加时，清楚的职责比丰富的名称更重要。一个边界明确的小工具集，往往更容易维护，也更容易让业务人员理解系统实际拥有的能力。

把查询客户与修改客户拆成工具

为每个工具写出输入、单位、影响和结果证据，使用相似名称与缺失字段测试选择是否正确。写入目标、授权与当前状态由执行层检查，工具文字说明不能替代实际校验。