一篇文章告诉你什么是Tool
前言
你有没有遇到过这种情况：
-
让AI帮你整理电脑里的文件，它给你写出一整套整理方案，分类规则写得头头是道，但最后还是得你自己一个个打开文件夹、手动移动
-
让它帮你查今天的天气，它说「我的知识截止到某年某月，无法获取实时天气」
-
让它帮你订明天的机票，它只能告诉你去哪个网站、怎么操作，然后你默默打开了去哪儿网
这不是大模型不够聪明。 大模型非常聪明，但它天生就被关在一个「小盒子」里——它只能接收文字、输出文字，它的「手」根本伸不出来，没有办法和外部世界产生任何交互。
这就引出了我们这章的主角：Tool（工具）。
Tool就是给大模型「装上手」的方案，让它从「只动嘴的参谋」，变成「能落地干活的实干家」。
一、Agent + Tool：两个角色怎么配合干活
在聊Tool之前，先把另一个容易混淆的概念说清楚：Agent。
很多同学以为「Agent就是更厉害的大模型」。这个理解偏了。Agent本质上是我们开发者写的一套程序，它不是更聪明的AI，而是一个全程在线的「调度员」，负责在用户、大模型、工具之间协调任务、传递信息、推进流程。
用一个外卖平台来类比这三个角色的关系
| 角色 | 类比 | 职责 |
|---|---|---|
| 用户 | 点餐的你 | 提出需求 |
| Agent | 调度员 | 协调任务、传递信息、推进流程 |
| 大模型 | 店长 | 做决策、规划步骤 |
| Tool | 厨师/骑手 | 真正执行操作 |
完整的工作流程
-
Agent把需求+工具清单打包，发给大模型：「用户想做这件事，你有这些工具可以用，第一步该怎么做？」
-
大模型做决策，返回指令：「调用[读取文件]工具，路径是C://hello_world.cpp」
-
Agent执行指令，调用工具：真正去磁盘上读文件
-
Agent把结果回传给大模型：「文件读取成功，内容是……」
-
大模型根据结果，决定下一步：「好，现在调用[移动文件]工具，把它移到D盘」
-
循环执行，直到任务完成：所有步骤跑完，大模型生成最终总结
-
Agent把结果反馈给你：任务完成
你看，这整个过程里，「决策」始终在大模型，「执行」始终在工具，而Agent就是那个来回传话、推进任务的协调员。
二、Tool到底是什么？光写函数不够
好，现在聚焦到工具本身。
你可能会想：「工具不就是函数嘛，我写一个Python函数，Agent直接调用就行了？」
听起来很合理，但这里有个关键问题：大模型根本看不到你的Python代码。
大模型不是程序员，它不会去扫你的代码库，发现「哦你这里有个get_weather函数」。它能读的，只有你放进它对话上下文里的文字。
所以，哪怕你把函数写得多优雅，只要没有专门告诉大模型「这个函数叫什么、干嘛用的、参数怎么传」，大模型就永远不知道这个工具的存在。
结论：要让大模型用上工具，必须额外给它写一份「说明书」。
-
函数 = 「手」
-
说明书 = 「让大模型学会用这只手的指南」
两者缺一不可。
这份说明书由四个部分组成，就是Tool的四要素
| 要素 | 作用 | 谁看 |
|---|---|---|
| 函数本体 | 真正干活的代码 | Agent执行，大模型看不到 |
| name（名称） | 大模型的识别标签 | 大模型 |
| description（描述） | 告诉大模型「什么时候用」 | 大模型 |
| parameters（参数定义） | 告诉大模型「怎么填参数」 | 大模型 |
三、Tool的四要素详解
1. 函数本体（真正干活的代码）
这是实现具体功能的代码，查数据库就是查数据库，发通知就是发通知。
这部分大模型看不到，但是Agent最终会执行它。大模型只负责「决策调用哪个工具、传什么参数」，至于这个工具内部怎么实现，大模型完全不关心。
2. name（名称），大模型的识别标签
大模型决定「调哪个工具」的时候，第一步靠的就是名称。名字要望名知意。
| ✅ 好名字 | ❌ 坏名字 |
|---|---|
get_weather |
func_001 |
send_email |
tool_a |
query_database |
do_something |
起名的原则很简单：让大模型看名字就能猜出大概。
3. description（描述）—— 整个工具定义里最重要的字段，没有之一
大模型每轮决策的核心问题是：「当前这一步，该不该调这个工具？」
它做这个判断的唯一依据，就是工具的description。
-
描述写清楚了 → 大模型准确选工具
-
描述写模糊了 → 大模型要么选错工具，要么该用的时候没用，或者不该用的时候乱用
一个好的description应该包含三件事：
| 要素 | 说明 | 示例 |
|---|---|---|
| 能做什么 | 这个工具的核心功能是什么 | 「查询指定城市在指定日期的天气」 |
| 什么场景用 | 遇到哪类问题、哪种情况该选它 | 「当用户询问某地天气、出行建议、是否需要带伞时使用」 |
| 返回什么 | 调用完会得到哪些信息 | 「返回天气状况、温度、湿度」 |
4. parameters（参数定义），告诉大模型怎么「填参数」
有了函数，大模型还得知道：调用这个工具要传哪些参数、每个参数是什么类型、哪些是必填的。
这些信息用JSON Schema格式来定义。
JSON Schema听起来很技术，但你可以把它理解成网站上的一张「填写表单」：
你在网上买东西填收货地址的时候，表单会告诉你，「姓名」「地址」「手机号」是必填项（标了*号），「备注」是选填的；「手机号」只能填数字，不能填文字。
JSON Schema做的就是同样的事：定义这个工具有哪些「格子」需要填、每个格子填什么类型的数据、哪些格子必须填。
四、完整案例：给Agent配一个「查天气」的工具
假设我们要给Agent提供一个查询天气的工具。
第一步：写函数本体（大模型看不到，Agent负责执行）
python
# ===== 第一部分：函数本体（大模型看不到，Agent负责执行）=====
import requests
def get_weather(city: str, date: str) -> dict:
"""调用天气API，查询指定城市指定日期的天气"""
response = requests.get(
"https://api.weather.com/v1/forecast",
params={"city": city, "date": date}
)
data = response.json()
return {
"city": city,
"date": date,
"weather": data["condition"], # 晴/多云/雨
"temperature": data["temp_c"], # 摄氏度
"humidity": data["humidity"] # 湿度百分比
}
这段代码没什么特别的，就是调了一个天气API，把结果整理成字典返回。
⚠️ 注意：大模型看不到这段代码，它只负责决定「要调这个工具、传什么参数」，至于你用什么API、代码怎么写，大模型完全不关心。
第二步：写工具说明书（大模型看到的部分）
函数有了，接下来写大模型能看到的部分：name + description + parameters：
json
{
"name": "get_weather",
"description": "查询指定城市在指定日期的天气情况。当用户询问某地天气、出行建议、是否需要带伞等问题时使用。返回天气状况、温度、湿度。",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "要查询天气的城市名称，例如：北京、上海、广州"
},
"date": {
"type": "string",
"description": "查询日期，格式：YYYY-MM-DD，例如：2025-03-21"
}
},
"required": ["city", "date"]
}
}
逐行拆解这份说明书
| 字段 | 内容 | 作用 |
|---|---|---|
| name | get_weather |
望名知意，大模型一看就猜到这是查天气的工具 |
| description | 包含「能做什么」「什么场景用」「返回什么」 | 最关键。注意写的是「当用户询问某地天气、出行建议、是否需要带伞时使用」，这就是在告诉大模型：你遇到这类问题，就来用我 |
| parameters.city | 字符串，必填，给了示例 | 大模型知道城市名填什么格式 |
| parameters.date | 字符串，必填，给了格式和示例 | 大模型知道日期必须按YYYY-MM-DD格式填 |
完整对照图
text
用户问：「明天上海天气怎么样？」
↓
大模型读完说明书
↓
判断：该调 get_weather
↓
填参数：city="上海"，date=明天的日期
↓
Agent执行函数 → 返回结果
这就是函数本体和工具说明书的完整对照。
五、大模型怎么「认识」这些工具？
工具写好了，下一个问题：大模型怎么知道我有哪些工具？
答案是：你得主动告诉它。
Agent在每次对话开始前，会把所有可用工具的 name + description + parameters 打包成一个列表，通过API的tools参数传给大模型。这个列表就叫工具清单。
用场景帮你理解
你入职一家新公司，第一天HR给你发了一份《内部系统清单》：
| 系统 | 用途 | 参数 |
|---|---|---|
| OA系统 | 提交请假申请、报销单据 | 开始日期、结束日期、事由 |
| 代码仓库 | 提交代码、发起MR | 分支名、目标分支 |
| 监控平台 | 查看服务状态、报警记录 | 服务名、时间范围 |
拿到这份清单，你自然就知道：「哦，我下周要请假，得用OA系统，填开始日期和结束日期」。
大模型收到工具清单，完全是同样的逻辑。 它遇到用户的问题，就在清单里找「哪个工具能处理这个场景」，然后按照parameters定义填好参数，告诉Agent去调用。
一个重要结论
大模型选对工具的能力，不只取决于模型有多聪明，更取决于工具描述写得有多清晰。
描述太模糊、两个工具描述太相似、工具太多但没有区分场景——这些问题，换再强的模型也没用。根本原因在工具描述本身写得不够好。
这就是为什么前面把description列为「最重要的字段」。
工具清单越丰富、描述越清晰，Agent能干的事越多、越准确。
六、工具有哪些类型？风险从低到高
工具不是只有一种，按照「对系统的影响程度」，从低风险到高风险分成四类。
这个顺序不是随意排的，它决定了每类工具在Agent里该怎么用、要不要加人工审批。
1. 查询类（只读）—— 风险：低
| 典型场景 | 示例 |
|---|---|
| 查天气 | get_weather |
| 搜索网页 | web_search |
| 读取文件 | read_file |
| 查数据库记录 | query_db |
特点：只读取数据，不改变任何状态。查完数据库，数据库还是那个数据库；读完文件，文件没有任何变化。
风险等级：低
调用策略：可以放心让Agent自主调用，不需要人工确认。出错了顶多是拿到没用的数据，不会产生不可逆的后果。
2. 写入类（有副作用）—— 风险：中
| 典型场景 | 示例 |
|---|---|
| 往数据库插记录 | insert_record |
| 发通知消息 | send_notification |
| 发邮件 | send_email |
| 更新配置 | update_config |
特点：会改变系统状态，而且有些操作不可逆——发出去的通知收不回来，写进数据库的记录再删也留了痕迹。
风险等级：中
调用策略：对高风险的写入操作（比如发通知给几百个人、修改线上配置），建议加一个人工确认步骤，而不是让Agent完全自主执行。
3. 执行类（高风险）—— 风险：高
| 典型场景 | 示例 |
|---|---|
| 执行shell命令 | run_shell |
| 跑脚本 | execute_script |
| 重启服务 | restart_service |
| 部署代码 | deploy |
特点：能直接操作系统。一条错误的shell命令能删掉整个目录，一次错误部署能把线上服务打挂。这类工具的影响范围最大，破坏性最强。
风险等级：高
调用策略：
-
严格限制权限范围（比如只允许执行白名单里的命令）
-
重要操作必须走人工审批，绝对不能让Agent自主决策
4. AI辅助类 —— 风险：低~中
| 典型场景 | 示例 |
|---|---|
| RAG检索 | search_knowledge_base |
| 调用子模型 | classify_log |
特点：这是很多同学没想到的一类——AI能力本身也能封装成工具。比如，给Agent配一个RAG检索工具，让它能随时查内部知识库、历史故障案例。
风险等级：低到中（操作本身不会改变外部系统状态）
调用策略：通常可以让Agent自主调用，主要关注检索结果的质量和子模型的可靠性。
风险等级总结表
| 类型 | 典型场景 | 风险 | Agent能自主调用？ |
|---|---|---|---|
| 查询类 | 查天气、读文件、搜索网页 | 低 | ✅ 可以 |
| 写入类 | 发通知、改配置、写数据库 | 中 | ⚠️ 高风险操作需人工确认 |
| 执行类 | 跑脚本、重启服务、部署 | 高 | ❌ 必须人工审批 |
| AI辅助类 | RAG检索、调用子模型 | 低~中 | ✅ 通常可以，关注结果质量 |
这四类工具，风险依次递增。设计Agent系统时，每个工具的风险等级直接决定了两件事：它能不能自主调用？需不需要人工确认？
这是保证Agent安全可靠运行的基本原则，不要等出了问题再加。
七、总结
整理一下这章的核心认知：
1. 工具是Agent的「双手」
-
没有工具 → Agent只是一个只会输出文字的大模型
-
有了工具 → Agent才能真正和外部世界交互、完成具体任务
2. 一个工具 = 函数本体 + 名称 + 描述 + 参数定义
| 要素 | 谁看 | 作用 |
|---|---|---|
| 函数本体 | Agent执行 | 真正干活的代码 |
| name | 大模型 | 识别标签，望名知意 |
| description | 大模型 | 最关键，是大模型选工具的唯一依据 |
| parameters | 大模型 | 告诉大模型怎么填参数 |
3. 四类工具，风险从低到高
| 类型 | 风险 | 自主调用？ |
|---|---|---|
| 查询类 | 低 | ✅ 可以 |
| 写入类 | 中 | ⚠️ 高风险需确认 |
| 执行类 | 高 | ❌ 必须审批 |
| AI辅助类 | 低~中 | ✅ 通常可以 |
4. 核心结论
工具描述的清晰度决定Agent的准确率。
不是换更聪明的模型，是把
description写清楚。
后续预告
后面几章会继续深入这条链路：
| 章节 | 内容 | 与Tool的关系 |
|---|---|---|
| Function Calling | 大模型怎么把「我要调哪个工具、传什么参数」这个决策，用标准化格式告诉Agent | 工具调用的底层机制 |
| RAG | 把知识库检索封装成工具，让Agent能访问私有数据 | 重要到单独一章 |
| MCP | 工具的标准化协议，让你不用每次都从头写工具 | 直接接入现成的工具生态 |
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
9
0- 0
已为社区贡献9条内容
所有评论(0)