工具决定 Agent 能影响什么。模型再聪明，如果工具名称模糊、参数复杂或权限过大，也会出现选错动作、传错参数和越权操作。工具设计首先是一项 API 与安全设计工作。
每个工具只做一件清楚的事
search_documents(query, filters)、get_order_status(order_id) 和 calculate(expression) 都有明确目的。相反，execute_action(type, payload) 把多种能力藏在一个入口里，模型难以选择，也很难设置细粒度权限。
工具描述应说明何时使用、何时不要使用、必填参数、返回值和常见失败。两个工具职责重叠时，模型容易随机选择；可以合并能力，或把适用边界写清楚。
参数要少而有约束
使用明确类型、枚举、长度和格式，避免让模型自由拼接 URL、SQL 或命令。能由程序从当前用户和会话确定的字段，不必让模型生成。例如租户 ID 和权限范围应由服务端注入，而不是由模型选择。
执行前再次校验所有参数。工具调用来自模型，并不比普通用户输入更可信。资源标识、金额、收件人、文件路径和查询范围都必须经过授权检查。
只读与写入分离
查询、搜索和计算可以作为初始工具集。发送、创建、修改和删除应使用独立工具，并返回将要执行的动作摘要。高影响操作在真正执行前要求用户确认，确认内容要包含目标、关键参数和不可逆影响。
凭据由工具运行环境保存，模型只看到必要结果。每个工具使用最小权限账号，并限制可访问的域名、目录和数据范围。不要给通用 Agent 一个管理员令牌。
返回结构服务于下一步判断
工具结果应短小、结构稳定，并明确区分成功、无结果和失败。不要把整个数据库响应或几十页网页原样塞回上下文。可以返回摘要、关键字段、来源标识和是否还有更多结果。
工具失败时提供机器可识别的错误码和可读说明。Agent 可以决定换一种查询或停止，但不应无限重试。写操作最好使用幂等键，避免超时重试造成重复提交。
从调用轨迹改进工具
观察 Agent 经常选错哪个工具、哪些参数缺失、哪些返回值被误解。问题可能不在提示词，而在工具接口本身。一个好工具即使换了模型，也应容易理解、容易验证、容易限制影响。