问：智能体调用业务系统的API时，经常选错工具、传错参数。换了更大的模型也没解决问题。问题到底出在哪？
答：问题可能出在工具（Tool）的描述上，而不是模型能力上。大多数智能体工具调用的失败，不是因为模型不够聪明，是因为工具描述写得不够清晰。大模型选工具依赖的是描述文本，不是代码注释。
一、工具描述的常见问题
问题一：描述太短，模型不知道这个工具是干什么的
错误示例：
这种描述对大模型来说信息量严重不足——这个“订单”是什么业务含义？是销售订单、采购订单、还是生产工单？参数“订单号”的格式是什么？查询结果返回哪些字段？
问题二：没有说明适用场景
大模型需要知道“什么时候该用这个工具”。同一个订单查询功能，可能有两种不同的工具：一个用于客服查单（返回状态、物流、收货人信息），一个用于财务查单（返回金额、支付状态、发票信息）。如果描述里不说清楚适用场景，模型可能用错。
问题三：没有写异常处理指引
工具调用失败时，模型应该怎么处理？返回“订单不存在”时该怎么说？超时时该怎么办？这些如果不在工具描述里写清楚，模型就“自由发挥”——可能编造数据、可能美化错误、可能反复调用同一个工具。
二、一个经过验证的工具描述结构
以“销售订单查询”工具为例：
三、好的工具描述让模型“知道怎么干活”
用这个结构描述清楚之后，模型的工作流程就清晰了：
用户说“查一下订单”，模型识别意图是查询订单，但缺少必要参数（订单号），先反问用户要订单号
用户说“X12345678”，模型确认格式正确，调用工具，传入订单号
工具返回“订单已发货，物流单号SF1234567890”，模型将结果组织成自然语言反馈给用户
如果工具描述没写清楚，模型的执行流程可能是混乱的——参数格式不对、不知道要反问、甚至调用错了工具。
目前市场上做企业AI智能体定制的服务商，在交付智能体时通常会把工具描述的设计作为标准环节，包含一套经过验证的模板和示例。如果企业自己写Prompt遇到了选错工具的问题，按上述结构重写一遍工具描述，通常能解决大部分问题。
FAQ
Q：工具描述写多长合适？
A：每个工具描述200-400字比较合适。太短信息量不够，太长会占用上下文窗口。如果工具本身逻辑复杂，可以考虑拆分成多个更细粒度的工具。
Q：工具描述里的“不适用场景”要不要写？
A：建议写。模型知道“什么时候不用这个工具”和知道“什么时候用”同样重要。加了“不适用场景”后，模型调用错误工具的概率会明显下降。
Q：工具描述需要持续优化吗？
A：需要。上线后至少观察两周，记录模型选错工具的案例，分析是描述不够清晰还是遗漏了某种场景。每次迭代优化描述，模型的工具选择准确率会逐步提升。
一句话总结：智能体调用API出错，大概率是工具描述写得不够好。把适用场景、参数格式、返回字段、异常处理四个部分写清楚，模型自然知道什么时候用什么工具、参数怎么传、出错了怎么处理——不需要换更大的模型。
热门跟贴