《一文搞懂 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 工具系统的完整认识。