LLM调用外部工具已经成为 AI 应用的一部分，但“能用”并不等于“好用”。在实践中，使用者往往会遇到参数错误、工具选择失误、错误循环、Token 消耗过大还有安全漏洞等痛点。下面将从设计模式角度，对如何让 LLM 调用工具更流畅进行程序梳理。

1、为什么 Tool Use 需要设计模式？其实，

自从 OpenAI 在 2023 年推出 Function Calling 功能后几乎所有 AI 产品都在尝试让 LLM 与外部 API 对接。但不同团队部署后出现两种截然不同的体验：

• 顺畅精准：调用过程自然、返回结果符合预期。说起来，
• 工具调用频繁报错。或者返回的数据无法被后续处理。

原因在于这方面。LMM 本质是语言模型，而不是程序执行引擎。它通过语言描述来“理解”工具，而不是像代码那样按函数签名直接调用。为此，需要一套可复用的设计模式来指导 LLM 如何正确地解析、调用和处理工具。

常见使用者痛点

• 参数幻觉：LMM 生成不存在或无效的参数值。
• 工具选择错误：当多个相似功能的工具共存时LMM 选错了目标。
• Error Loop：工具返回错误后LMM 无法恢复，只是不断重复相同请求。
• Token 泄漏：每一次调用都消耗大量 Token，导致被快速占满。怎么说呢，
• 安全风险：LMM 被诱导使用高权限或危险操作。

2、参数设计模式

a) 明确参数约束

LMM 在生成参数时最容易出错的是模糊的类型与范围。以下示例展示了改进前后的差异：

{
"name"这方面，"search_products","description": "搜索商品列表，返回分页结果","parameters": {
从"type"来看，"object","properties": {
"keyword": {
说到"type"，"string","description": "搜索关键词，最长 30 字","maxLength": 30
},"page": {
说到"type"，"integer"。"description": "页码，从 1 开始",“minimum”: 1,“default”: 1
},“sort”: {
从“type”来看，“string”,“enum”:,“description”: “排序方式：价格升序/降序、销量、最新”
}
},“required”:
}
}

• MUST vs OPTIONAL： "required" 明确哪些字段必填；
• Coding Enumeration first： "enum" 避免自由文本；
• Detailed description： “页码，从 1 开始”;
• Narrow numeric range： "minimum"/"maximum" 限制数值范围。

b) 参数抽取：从自然语言中提取信息

User Input: “帮我查一下张三上个月的订单”

{
至于"name"，"query_orders","parameters":{
"properties":{
{"user_name":{"type":"string","description":"使用者姓名，从对话中提取"}},{"date_range":{"type":"string"。"description":"查询时间范围 YYYY-MM 或 YYYY-MM-DD~YYYY-MM-DD"}}
},}
}

The description explicitly tells LLM that se values should be extracted from context rar than supplied by user again.

避免参数爆炸

• 每个工具尽量保持不超过6个主要参数；如果超过可拆分成多步或使用复合对象。

示例拆分策略