一文搞懂 Agent 工具机制：从 Schema 到 Tool Calling

《一文搞懂 Agent 工具机制：从 Schema 到 Tool Calling》

一、什么是 Agent Tool？

在 Agent 系统中，Tool（工具）是大模型与外部环境交互的桥梁，让原本主要负责理解和生成文本的 LLM，能够读取文件、执行代码、搜索信息，甚至操作其他软件。

例如，用户要求：

帮我读取 main.py，看看代码有什么问题。

LLM 本身不能直接访问本地文件，但如果 Agent 配备了 read_file 工具，就可以借助这个工具获取文件内容，再分析代码。

因此，一个典型的 Agent 系统可以简单理解为三个部分：

组成部分	核心职责
LLM	理解任务、推理决策、选择工具
Tool	提供读取文件、执行命令等外部能力
Agent Harness	管理工具调用、执行流程和结果反馈

三者相互协作，Agent 才能从单纯的文本生成系统，变成能够执行实际任务的智能体。

二、工具是如何定义的？

一个工具通常涉及两个核心部分：

Tool Definition（工具定义） + Implementation（工具实现）。

其中，工具定义负责告诉 LLM 工具能做什么、如何调用；工具实现负责真正执行操作。

1. Tool Definition：告诉 LLM 工具怎么用

以一个 Coding Agent 的 read_file 工具为例：

tool_definitions = [
    {
        "name": "read_file",
        "description": "Read the contents of a file.",
        "input_schema": {
            "type": "object",
            "properties": {
                "file_path": {
                    "type": "string",
                    "description": "Path of the file to read"
                }
            },
            "required": ["file_path"]
        }
    }
]

这个工具定义主要包含三个字段：

name：工具名称，用于唯一标识工具，例如 read_file。
description：工具描述，告诉 LLM 这个工具能够完成什么任务。
input_schema：输入参数定义，告诉 LLM 调用工具时应该传入哪些参数，以及参数的格式。

其中，input_schema 采用 JSON Schema 风格的结构：

字段	含义
`type: object`	工具输入是一个对象
`properties`	定义可以传入哪些参数
`file_path`	参数名称
`type: string`	参数类型为字符串
`description`	参数的用途
`required`	指定必须传入哪些参数

因此，当 LLM 想要读取文件时，就知道需要生成这样的参数：

{
    "file_path": "main.py"
}

需要注意：整个字典属于 Tool Definition，而 **input_schema** 才是专门描述输入参数的 Schema。

2. Implementation：工具真正的执行逻辑

Tool Definition 只是描述工具，并不能真正读取文件。

因此，我们还需要编写 Implementation（工具实现）：

def read_file(file_path: str) -> str:
    with open(file_path, "r", encoding="utf-8") as f:
        return f.read()

这段 Python 函数才是真正执行文件读取的代码。

Implementation 不一定是 Python 函数，也可以是 HTTP API、数据库查询或者远程服务。

至此，我们可以这样理解：

Definition：告诉模型工具能做什么、怎么调用。
Implementation：负责执行工具的具体操作。

模型通常只需要了解工具定义，不需要了解工具的内部实现。

三、Agent 是如何调用工具的？

定义好工具之后，还需要让 LLM 的调用请求与实际执行代码连接起来，这就是 Agent Harness 的职责之一。

假设用户要求：

读取 main.py 文件。

整个调用过程可以划分为四个步骤。

第一步：将工具定义提供给 LLM

Agent Harness 将 read_file 的工具定义传递给模型，让模型知道当前有哪些工具可以使用。

工具定义通常通过模型 API 的 tools 参数提供，而不一定直接拼接到普通聊天消息中。

第二步：LLM 生成工具调用请求

LLM 根据用户任务，决定调用 read_file，并生成结构化请求：

{
    "name": "read_file",
    "input": {
        "file_path": "main.py"
    }
}

注意：LLM 只是生成了工具调用请求，并没有亲自执行 Python 函数。

第三步：Agent Harness 执行工具

Agent Harness 接收到请求后，需要找到对应的 Implementation。

一种常见的方式是使用工具注册表（Tool Registry）：

TOOL_REGISTRY = {
    "read_file": read_file
}

注册表建立了工具名称与实际执行函数之间的映射关系。

当 Harness 收到调用请求后，就可以执行：

tool_name = "read_file"
tool_args = {"file_path": "main.py"}

tool_func = TOOL_REGISTRY[tool_name]
result = tool_func(**tool_args)

这样，工具调用请求就转化成了真正的 Python 函数执行。

实际项目中还需要进行参数校验、权限检查、异常处理等操作，不能直接信任 LLM 生成的参数。

第四步：将执行结果返回 LLM

工具执行完成后，Agent Harness 会把执行结果作为工具消息反馈给 LLM。

LLM 获取文件内容后，可以继续分析代码，也可以决定调用其他工具，直到完成任务。

整体调用链路如下：

用户提出任务
      ↓
LLM 接收任务和工具定义
      ↓
LLM 选择工具并生成调用请求
      ↓
Agent Harness 接收请求
      ↓
根据工具名称查找 Implementation
      ↓
执行工具并获取结果
      ↓
Agent Harness 将结果反馈给 LLM
      ↓
LLM 继续推理或输出最终答案

这就是 Agent 系统中最基础的 Tool Calling 主链路。

四、Tool、Function Calling 和 MCP 有什么关系？

学习 Agent 时，经常遇到 Tool、Function Calling、MCP 等概念，它们关注的问题并不相同。

概念	核心作用
Tool	为 Agent 提供外部操作能力
Tool Definition	描述工具的功能和调用方式
Implementation	实现工具的具体执行逻辑
Function Calling	让 LLM 生成结构化工具调用请求
MCP	标准化 AI 应用与外部工具、资源等能力的连接方式
Agent Harness	负责工具调度、执行控制、结果反馈等流程

举个例子：

如果 read_file 是项目内部的 Python 函数，可以直接通过工具注册表调用。

如果 read_file 由外部 MCP Server 提供，Agent 则可以通过 MCP Client 与服务器通信，由 MCP Server 执行对应操作。

两者的主要区别在于工具的接入与执行方式不同，但对于 LLM 来说，通常都可以通过工具定义了解工具能力，并生成调用请求。

五、总结

Agent Tool 的核心机制可以归纳为三个层次：

工具定义层（Definition）：通过 name、description 和 input_schema，向 LLM 描述工具的功能及参数要求。
工具实现层（Implementation）：通过 Python 函数、API 或其他程序，真正执行工具操作。
工具调度层（Agent Harness）：连接 LLM 的工具调用请求与实际实现，负责执行控制及结果反馈。

最重要的是理解：

LLM 负责决定调用什么工具，Implementation 负责真正执行工具，而 Agent Harness 负责把两者连接起来。

掌握这条正常运行的主链路后，再进一步学习参数校验、权限控制、异常处理、超时重试等机制，就能逐步建立起对 Agent 工具系统的完整认识。

posted @ 2026-10-22 19:16 Tomorrowland_D 阅读(38) 评论(0) 收藏举报

刷新页面返回顶部