Agent 中多个工具语义相近且副作用不同，如何设计工具命名、description 和 JSON Schema，避免误选、漏参和高风险误触发？

60 秒回答模板

工具注册质量不是只靠一句 description。命名要用稳定的业务动作和对象帮助模型先缩小候选，description 要说明何时用、何时不用、调用副作用和相似工具差异，JSON Schema 则用类型、枚举、必填和条件约束把参数空间收紧。 命名先做粗筛：工具名应使用稳定业务动作和对象，例如 search_order、update_order_address、cancel_order_requires_confirmation。避免 getInfo、process、handle 这类泛名，也避免同义词堆叠造成候选混淆。 description 写使用边界：description 要明确业务意图、适用场景、禁止场景、调用前置条件、返回结果含义，以及与相似工具的差异。边界不清时，模型会把读操作、写操作和审批操作混成一个候选。 schema 约束参数空间：JSON Schema 里的字段要有自然语言含义、类型、必填条件、枚举、格式、默认值策略和来源说明。用户没给订单号、地址、金额等关键字段时，模型应追问或拒绝执行，而不是猜参数。 副作用和确认前置：写操作、资金、消息发送、删除、审批等工具要在命名、description 和 schema 中共同暴露风险等级、确认要求和幂等键。模型只负责选择和填参，真正执行仍要由服务端权限和业务规则校验。 用评测迭代工具契约：构造工具选择测试集，覆盖相似意图、缺字段、多轮补参、高风险误触发和工具返回失败。记录误选、漏选、参数错、重复调用和无意义调用，再决定改名、改 description、收紧 schema 或拆分工具。 最后要把方案落到可验证的指标、失败兜底和迭代闭环上。面试里不要只讲概念名词，要说明边界、取舍、数据来源、线上观测和出问题后的回滚或人工介入。