7.1 接口与工具调用基础

智能体要与外部世界交互，必须借助工具。而工具的运转依赖接口。本节从接口的基本概念讲起，逐步引出工具调用的核心机制，为后续章节的 MCP 协议和实践应用奠定基础。

7.1.1 API 与 JSON 基础

API（Application Programming Interface，应用程序编程接口）是软件系统之间交换信息的标准通道。调用方按照约定格式发送请求，服务端处理后返回结果。在金融行业，API 无处不在：证券交易所推送行情、银行提供账户查询、Wind 等平台提供数据服务，都通过 API 实现。

当前主流的 RESTful API 基于 HTTP 协议，包含四个核心要素：

要素	说明	示例
URL 端点	服务的地址	https://api.example.com/stocks/600519
HTTP 方法	操作类型	GET（获取数据）、POST（提交数据）
请求体	附带的参数	{"period": "daily", "count": 30}
响应体	返回的结果	{"price": 1680.50, "change": 2.3}

API 通信使用 JSON（JavaScript Object Notation）格式组织数据。JSON 用键值对表示信息，花括号 {} 包裹对象，方括号 [] 包裹数组，支持字符串、数字、布尔值和嵌套结构。例如一条股票数据：

{
  "symbol": "600519",
  "name": "贵州茅台",
  "price": 1680.50,
  "change_pct": 2.3,
  "is_suspended": false
}

JSON 结构清晰、机器易解析、人也能直接阅读，是后续工具调用的基础数据格式。

7.1.2 大语言模型为什么需要工具

有了 API 和 JSON 的基础，我们来思考一个关键问题：大语言模型（Large Language Model, LLM）为什么需要调用外部工具？

LLM 的三大固有限制

大语言模型的能力来源于训练数据。这决定了它有三个无法靠自身克服的限制：

限制	表现	金融场景举例
知识截止	训练数据有时间边界，无法获取之后的信息	无法回答今天的股价、最新的货币政策
无法执行操作	只能生成文本，不能与外部系统交互	无法真正查询数据库、下载财报、发送邮件
计算精度有限	复杂数学运算容易出错	计算投资组合的夏普比率时可能给出错误结果

这三个限制意味着，如果仅靠模型自身，它在很多实际场景中是不够用的。一个金融分析师需要实时行情、需要访问数据库、需要精确的数值计算——而这些恰恰是 LLM 的短板。

工具调用的核心思路

工具调用（Tool Use，也称 Function Calling）的解决思路很直接：让 LLM 扬长避短。

模型擅长的是理解自然语言、分析意图、组织信息。那就让模型专注于做这些事，而把它不擅长的事——获取实时数据、执行计算、操作外部系统——交给专门的工具来完成。

具体来说，模型的任务不是亲自执行操作，而是生成一个结构化的调用请求（JSON 格式），说明它想调用哪个工具、传入什么参数。外部系统收到请求后执行操作，把结果返回给模型，模型再用自然语言组织最终回复。

注记知识卡片

工具调用的设计逻辑遵循分工原则：模型负责理解自然语言和决策，工具负责执行操作和精确计算，各司其职，实现整体效率最优。

工具调用与传统 API 调用的区别

传统的 API 调用中，决策者是人。程序员编写代码，明确指定在什么条件下调用什么接口、传入什么参数。这些逻辑是写死在程序里的。

工具调用有一个根本性的不同：决策者从人变成了模型。

维度	传统 API 调用	LLM 工具调用
决策者	程序员预先编写逻辑	模型根据上下文判断
调用时机	代码中的条件分支	模型理解用户意图后自主决定
参数来源	代码中硬编码或用户表单输入	模型从自然语言中提取
灵活性	只能处理预设的场景	能应对开放式的自然语言请求

例如，传统方式下，你需要在界面上设计一个下拉菜单让用户选择股票代码，再设计一个按钮触发查询。而使用工具调用，用户只需说一句贵州茅台今天表现怎么样，模型就能理解意图，自动调用行情查询工具，传入正确的股票代码。

这种从规则驱动到意图驱动的转变，正是智能体区别于传统软件的核心所在。

7.1.3 工具调用的基本流程

工具调用五步流程

理解了工具调用的动机，我们来看它的完整流程。一次典型的工具调用包含五个步骤：

五步流程模型

用户提问 → ① 定义工具 → ② 模型决策 → ③ 系统执行 → ④ 返回结果 → ⑤ 模型整合回复

步骤	执行者	动作	产出
① 定义工具	开发者	用 JSON 描述工具的名称、功能和参数	工具定义列表
② 模型决策	LLM	分析用户意图，决定是否调用工具及传入什么参数	工具调用请求（JSON）
③ 系统执行	外部系统	接收请求，执行实际操作（如调用 API）	执行结果
④ 返回结果	外部系统	将结果以 JSON 格式返回给模型	工具响应（JSON）
⑤ 整合回复	LLM	将工具返回的数据组织成自然语言	最终回复

用金融场景走一遍完整流程

假设用户向智能体提问：贵州茅台今天涨了多少？

第一步：定义工具。 开发者事先定义了一个名为 get_stock_quote 的工具：

{
  "name": "get_stock_quote",
  "description": "获取 A 股股票的实时行情数据，包括价格、涨跌幅和成交量",
  "parameters": {
    "type": "object",
    "properties": {
      "symbol": {
        "type": "string",
        "description": "6 位 A 股股票代码，如 600519"
      }
    },
    "required": ["symbol"]
  }
}

这个定义告诉模型：有一个工具可以查询 A 股行情，需要传入一个股票代码参数。

第二步：模型决策。 模型接收到用户的问题后，进行两层判断。第一层：这个问题需要实时数据吗？需要，因为用户问的是今天的涨跌。第二层：哪个工具能提供这个数据？get_stock_quote 可以。于是模型生成一个调用请求：

{
  "tool": "get_stock_quote",
  "arguments": {
    "symbol": "600519"
  }
}

注意，模型自动完成了一个关键步骤：将自然语言中的贵州茅台映射为股票代码 600519。这种从非结构化语言到结构化参数的转换，正是 LLM 在工具调用中发挥的核心作用。

第三步：系统执行。 外部系统接收到调用请求，向金融数据 API 发送查询，获取贵州茅台的实时行情。

第四步：返回结果。 系统将查询结果以 JSON 格式返回给模型：

{
  "symbol": "600519",
  "name": "贵州茅台",
  "current_price": 1680.50,
  "prev_close": 1642.70,
  "change": 37.80,
  "change_pct": 2.30,
  "volume": 3250000,
  "timestamp": "2025-03-15T15:00:00+08:00"
}

第五步：模型整合回复。 模型读取返回的数据，生成自然语言回复：

贵州茅台（600519）今日收盘价 1680.50 元，较昨日收盘价 1642.70 元上涨 37.80 元，涨幅 2.30%。全天成交量 325 万股。

整个过程中，用户看到的只是一个自然的问答交互。底层的 JSON 请求、API 调用、数据解析全部由系统自动完成。

重要核心概念

工具调用的五步流程中，模型承担了两个关键角色：在第二步中充当决策者，理解用户意图并生成结构化请求；在第五步中充当翻译者，将机器可读的数据转化为人类可读的自然语言。这就是为什么工具调用需要大语言模型——传统程序可以执行 API 调用，但无法理解开放式的自然语言指令。

7.1.4 从 API 到工具生态

本节介绍了从 API、JSON 到工具调用的基础概念。这些概念构成了整个工具扩展体系的底层逻辑。

回顾一下核心脉络：

• API 是软件系统之间交换信息的标准通道
• JSON 是 API 通信的标准数据格式
• LLM 因为知识截止、无法执行操作和计算精度有限，需要借助外部工具
• 工具调用让模型充当决策者，自主判断何时调用什么工具
• 五步流程（定义→决策→执行→返回→整合）完成一次完整的工具调用

但是，单个工具的调用只是起点。在实际应用中，一个金融智能体可能同时需要行情查询、财务数据、新闻搜索、计算引擎等多种工具。如何管理这些工具？如何让不同来源的工具以统一的方式接入？如何保障调用过程的安全性？

这些问题的答案，就是下一节要介绍的 MCP（Model Context Protocol，模型上下文协议）。MCP 提供了一套标准化的协议，让各种工具能够以统一的方式连接到智能体。

提示学习建议

如果你是第一次接触 API 和 JSON，不必追求完全记住所有语法细节。关键是理解三件事：API 是系统间通信的桥梁；JSON 是通信使用的数据格式；工具调用让模型能够主动使用这些桥梁。后续的实践环节会反复用到这些概念，在实际操作中你会逐渐熟悉它们。