LLM 如何“看懂”你定义的 Function 并决定调用？——从 Web 开发者视角拆解决策机制

图片来源网络，侵权联系删。

文章目录

• 1. 引言
• 2. 模型决策流程全景：从用户输入到函数调用
• • 2.1 完整交互流程（Mermaid）
• 3. LLM 如何“理解”Function 的用途？
• • 3.1 核心依据：Function 的 `description` 字段
  • • Web 类比：Swagger 注释指导前端调用
  • 3.2 最佳实践：编写高区分度的描述
• 4. LLM 如何从自由文本中抽取结构化参数？
• • 4.1 核心机制：基于 JSON Schema 的约束生成
  • • Web 类比：DTO 反序列化（如 Spring Boot @RequestBody）
  • 4.2 为什么有时参数抽取失败？
• 5. LLM 如何在多个 Functions 中做选择？
• • 5.1 决策依据：语义相似度 + 描述匹配度
  • • Web 类比：API 路由匹配（如 Express.js）
  • 5.2 避免函数冲突的最佳实践
• 6. 通过日志观察 LLM 的决策过程
• • 6.1 记录完整交互日志
  • 6.2 典型日志分析
• 7. Web 开发者如何掌控 LLM 的 Function 调用？
• • 推荐工具与资源

1. 引言

作为 Web 开发者，你熟悉这样的场景：

用户点击“查询订单” → 前端发送GET /api/orders?id=123→ 后端验证权限 → 返回 JSON 数据

这个过程依赖明确的路由规则和参数契约。

但在 AI Agent 中，用户输入是自由文本：“帮我查一下订单 123 的状态”。
LLM 是如何从这句话中识别出“需要调用 get_order_status 函数”，并正确提取 id=123 的？

💡 本文将深入解析：LLM 内部如何基于开发者声明的 Function Schema 进行意图识别、参数抽取与调用决策，并通过 Web 开发类比（如 API 路由匹配、DTO 反序列化）彻底消除其“黑盒感”。

---

2. 模型决策流程全景：从用户输入到函数调用

2.1 完整交互流程（Mermaid）

✅关键点：LLM 的“决策”发生在第一次响应中，输出的是结构化调用指令，而非最终回答。

---

3. LLM 如何“理解”Function 的用途？

3.1 核心依据：Function 的description字段

当你注册一个 Function 时：

{"name":"get_order_status","description":"根据订单ID查询物流状态。仅当用户询问订单进度、位置或状态时调用。","parameters":{...}}

LLM 会将这段描述视为上下文的一部分，用于判断是否匹配用户意图。

Web 类比：Swagger 注释指导前端调用

在 RESTful API 中，我们写：

/** * 查询订单物流状态 * @param orderId 订单ID（必填） * @return 物流信息对象 */@GetMapping("/orders/{orderId}/status")publicOrderStatusgetOrderStatus(@PathVariableStringorderId){...}

前端开发者通过阅读注释，知道何时调用此接口。

🔍LLM 的行为类似：它“阅读”你的description，学习何时应触发该函数。

3.2 最佳实践：编写高区分度的描述

❌ 差："获取订单信息"
✅ 好："查询订单的实时物流状态，包括当前位置和预计送达时间。仅当用户明确提到‘订单状态’、‘到哪了’、‘物流’等关键词时调用。"

📌技巧：在描述中加入触发关键词和使用场景限制，可显著提升调用准确率。

---

4. LLM 如何从自由文本中抽取结构化参数？

4.1 核心机制：基于 JSON Schema 的约束生成

LLM 在生成arguments时，必须严格遵循你提供的parametersSchema。

例如，Schema 定义：

"parameters":{"type":"object","properties":{"order_id":{"type":"string","pattern":"^\\d{1,10}$"},"include_history":{"type":"boolean","default":false}},"required":["order_id"]}

当用户说：“查下订单123，顺便看看历史记录”，LLM 会：

1. 识别order_id = "123"
2. 识别include_history = true
3. 生成合法 JSON 字符串："{\"order_id\":\"123\",\"include_history\":true}"

Web 类比：DTO 反序列化（如 Spring Boot @RequestBody）

@PostMapping("/search")publicResultsearch(@RequestBodyOrderQueryDTOdto){// Spring 自动将 JSON 转为 Java 对象，并校验字段类型/必填}

🔁LLM 的角色相当于“智能前端”：它负责将自然语言“序列化”为符合 Schema 的 JSON。

4.2 为什么有时参数抽取失败？

常见原因及解决方案：

问题	原因	解决方案
漏掉必填字段	用户未提及，LLM 不敢编造	在description中提示：“若用户未提供订单ID，请反问”
类型错误（如数字传字符串）	LLM 输出格式不规范	使用强类型模型（如 GPT-4o），并在后端用 Zod 校验
多值混淆（如多个订单ID）	用户说“订单123和456”	在 Schema 中支持数组："order_ids": { "type": "array", "items": { "type": "string" } }

---

5. LLM 如何在多个 Functions 中做选择？

5.1 决策依据：语义相似度 + 描述匹配度

假设你注册了两个函数：

• get_weather: “获取城市天气”
• get_stock_price: “获取股票价格”

当用户问：“北京今天多少度？”，LLM 会计算：

• 问题与get_weather.description的语义相似度 → 高
• 问题与get_stock_price.description的语义相似度 → 低

从而选择get_weather。

Web 类比：API 路由匹配（如 Express.js）

app.get('/weather/:city',weatherHandler);// 路径含 "weather"app.get('/stock/:symbol',stockHandler);// 路径含 "stock"// 请求 /weather/beijing → 匹配第一个路由

🧠LLM 的路由表就是你注册的所有 Functions，匹配依据是语义而非 URL 路径。

5.2 避免函数冲突的最佳实践

• 命名清晰：book_hotelvssearch_hotels（动词+名词）
• 描述互斥：明确说明各自适用场景
• 参数差异化：避免两个函数有完全相同的参数结构

⚠️ 若两个函数描述高度相似（如“查订单”和“看订单”），LLM 可能随机选择，导致不可控行为。

---

6. 通过日志观察 LLM 的决策过程

6.1 记录完整交互日志

// agent.tsconsole.log("➡️ 用户输入:",userInput);console.log("🔧 注册的 Functions:",registry.getOpenAISchema());constresponse=awaitopenai.chat.completions.create({...});if(response.choices[0].message.function_call){constfc=response.choices[0].message.function_call;console.log("🧠 LLM 决策: 调用函数",fc.name);console.log("📦 参数:",fc.arguments);// 执行函数...}else{console.log("💬 LLM 直接回答:",response.choices[0].message.content);}

6.2 典型日志分析

➡️ 用户输入: "帮我订明天去上海的机票" 🔧 注册的 Functions: [book_flight, get_weather, search_hotels] 🧠 LLM 决策: 调用函数 book_flight 📦 参数: {"departure_city":"北京","arrival_city":"上海","date":"2026-01-05"}

🔍 通过日志，你可以验证：

• 是否调用了预期函数？
• 参数是否完整准确？
• 是否存在误判？

---

7. Web 开发者如何掌控 LLM 的 Function 调用？

LLM 的 Function 调用并非魔法，而是一个受控的、基于契约的决策过程。作为 Web 开发者，你可以通过以下方式确保其可靠运行：

1. 精心设计 Function 描述：像写 Swagger 一样，明确使用场景与触发条件
2. 严格定义参数 Schema：利用 JSON Schema 约束输入，防止无效调用
3. 避免函数语义重叠：确保每个 Function 职责单一、描述互斥
4. 全面记录调用日志：监控 LLM 决策，持续优化提示词与函数设计

🌟核心认知：
LLM 是一个“智能 API 客户端”，而你定义的 Functions 就是它的“服务目录”。
掌握这一点，你就掌握了构建可靠 AI Agent 的钥匙。

推荐工具与资源

• 🛠️ Zod：TypeScript 优先的 Schema 校验，完美匹配 Function 参数验证
• 📊 LangSmith：可视化调试 LLM 调用链与函数决策
• 📚 OpenAI Function Calling 调试指南