从 LLM 到 AI Agent：工具调用框架（Tool Calling Framework）完整技术指南

从 LLM 到 AI Agent：工具调用框架（Tool Calling Framework）完整工程指南

过去两年，大语言模型（LLM）几乎改变了整个 AI 应用开发方式。但只要真正做过一些项目，很快就会发现一个现实问题：

LLM 很聪明，但不太会“做事”。

它可以：

• 写文章
• 总结内容
• 回答问题
• 做推理

但在真实业务中，用户往往需要的是：

• 查询数据库
• 获取实时数据
• 调用业务 API
• 执行自动化任务
• 操作企业系统

举个最简单的例子。

用户问：

北京今天的天气怎么样？

如果只是一个普通聊天机器人，模型只能猜测天气。但在真实应用里，我们希望系统能够：

1. 调用天气 API
2. 获取实时数据
3. 返回准确结果

于是一个关键技术出现了：

Tool Calling（工具调用）

它的核心思想非常简单：

LLM + Tools = AI Agent

工具调用让模型从一个“会聊天的系统”，变成一个 可以执行任务的智能体系统。

本文会系统介绍：

• Tool Calling 的核心思想
• 工具调用架构设计
• 常见实现方式
• Agent 系统结构
• Tool Router 与工具调度
• 工程实践问题
• 生产系统设计

如果你正在做 AI Agent / LLM 应用 / RAG 系统，工具调用几乎是绕不开的核心能力。

---

一、为什么 LLM 需要工具

首先必须理解一件事：

LLM 本质上是一个概率语言模型。

它擅长的是：

• 文本生成
• 语言理解
• 推理

但在很多场景中存在天然限制。

能力限制	示例
无法获取实时信息	天气、股票
无法访问私有系统	CRM、订单
无法执行操作	发邮件
数学能力有限	复杂计算
无法处理复杂数据	CSV、数据库

例如：

用户输入：

帮我查一下今天上海到北京的航班

如果没有工具调用，模型只能：

编造航班信息

但如果系统支持工具调用：

LLM → Flight API → 返回真实航班

这才是一个 可用的 AI 系统。

---

二、工具调用的核心思想

工具调用的本质是：

让 LLM 在推理过程中调用外部能力。

一个典型流程如下：

User Query
    │
    ▼
LLM Reasoning
    │
    ▼
Tool Selection
    │
    ▼
Tool Execution
    │
    ▼
Observation
    │
    ▼
LLM Final Answer

我们看一个简单例子。

用户：

345 × 982 等于多少？

模型推理：

需要调用 calculator

调用工具：

calculator("345*982")

返回结果：

338790

模型最终回答：

345 × 982 的结果是 338790。

这就是 Tool Use Loop。

---

三、工具如何被模型理解

一个关键问题是：

模型怎么知道有哪些工具可以用？

答案是：

Tool Schema

每个工具都需要提供结构化描述。

例如：

{
  "name": "get_weather",
  "description": "Get weather information for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    }
  }
}

这些信息通常包含：

字段	含义
name	工具名称
description	工具用途
parameters	参数结构

LLM 会根据 description 判断是否使用工具。

因此：

Tool Description 写得好不好，直接影响工具调用成功率。

---

四、工具调用的三种实现方式

目前主流实现方式主要有三种。

---

1 Function Calling

这是最稳定的方式。

开发者定义函数：

def get_weather(city):
    return weather_api(city)

并提供 schema。

模型返回：

{
 "tool": "get_weather",
 "arguments": {
  "city": "Beijing"
 }
}

系统执行函数。

优点：

• 工程化友好
• 易于解析
• 适合生产

---

2 ReAct Agent

ReAct 是经典 Agent 思路。

Reason + Act

模型输出推理过程：

Thought: 我需要查询天气
Action: get_weather
Action Input: Beijing
Observation: 晴 26℃
Thought: 我知道答案了
Final Answer: 北京今天晴 26℃

优点：

• 可解释性强
• 适合复杂任务

缺点：

• Token 成本较高

---

3 Code Interpreter

另一种方式是：

让模型写代码执行任务。

例如：

用户：

分析这个 CSV 文件

模型生成：

import pandas as pd
df = pd.read_csv("data.csv")
df.describe()

系统执行代码并返回结果。

适合：

• 数据分析
• 文件处理
• 自动化任务

---

五、Agent 系统整体架构

在生产环境中，一个完整 Agent 系统通常如下：

User
 │
 ▼
API Gateway
 │
 ▼
Agent Service
 │
 ├── Tool Registry
 ├── Tool Router
 ├── Tool Executor
 ├── Memory Manager
 └── Planner
 │
 ▼
LLM
 │
 ▼
External Tools

核心组件包括：

---

Tool Registry

负责管理所有工具。

例如：

weather_api
search
database_query
python_executor

---

Tool Router

根据任务选择工具。

---

Tool Executor

执行工具调用。

---

Memory Manager

管理上下文。

---

Planner

拆解复杂任务。

---

六、Tool Router 设计

当工具数量增加时，一个关键问题出现：

模型如何选择正确工具？

这就是：

Tool Router

常见实现方式包括：

---

1 LLM Routing

直接让模型选择工具。

优点：

简单。

缺点：

不稳定。

---

2 Rule-based Routing

使用规则：

if query contains weather → weather tool

优点：

稳定。

缺点：

不灵活。

---

3 Hybrid Routing（生产系统常用）

Rule + LLM

流程：

Rule Filter → Candidate Tools → LLM Selection

这样既稳定又灵活。

---

七、多工具任务调度（Tool Graph）

在复杂任务中，往往需要多个工具。

例如：

查询订单 → 查询物流 → 发送邮件

可以用 Tool Graph 表示：

Order API
   │
   ▼
Logistics API
   │
   ▼
Email API

Agent 按顺序执行。

这其实类似：

Workflow Engine

---

八、完整 Agent 示例

下面是一个简单 Agent 示例。

定义工具

from langchain.tools import tool

@tool
def get_weather(city: str):
    return "晴 26℃"

---

创建 Agent

from langchain.agents import initialize_agent

agent = initialize_agent(
    tools=[get_weather],
    llm=llm,
    agent="zero-shot-react-description"
)

---

运行

agent.run("北京天气怎么样")

Agent 会自动调用工具。

---

九、工程实践中的常见问题

真实项目中经常会遇到一些坑。

---

1 模型乱调用工具

例如：

北京在哪个国家？

模型却调用天气 API。

解决方法：

• 优化 description
• Prompt engineering
• Tool filtering

---

2 参数错误

模型可能生成：

city = 123

解决方法：

Pydantic
JSON Schema

进行参数校验。

---

3 无限调用

模型可能：

tool → tool → tool

解决方法：

max_tool_calls = 3

---

4 API 延迟

外部 API 可能很慢。

优化：

• Async
• Redis Cache
• Batch Request

---

5 安全问题

如果工具具有系统权限：

风险很大。

例如：

delete database

解决方法：

• RBAC
• Sandbox
• Tool Whitelist

---

十、生产环境最佳实践

一些真实工程经验。

控制工具数量

建议：

< 20

工具过多会影响选择。

---

description 非常重要

模型高度依赖 description。

---

监控

必须记录：

• Tool Calls
• Latency
• Error Rate

---

缓存

Redis 可以极大降低成本。

---

十一、未来发展方向

工具调用只是 Agent 的第一步。

未来系统可能发展为：

Agent OS
Tool Marketplace
Multi-Agent System

AI 系统将：

• 自动规划任务
• 调度工具
• 多 Agent 协作

从 聊天机器人 走向 自动化系统。

---

结语

LLM 正在从：

会聊天

走向：

会做事

而 Tool Calling 正是这一步的关键技术。

理解并设计好工具调用框架，是构建 AI Agent 系统的基础能力。

未来几年，随着 Agent 技术发展，Tool Calling 很可能成为 AI 工程师的核心技能之一。