第10章 工具调用实战：搜索·计算·API·数据库全掌握
AI智能体实战训练营 · 章节 10/33 · 45 学时
工具调用实战：搜索·计算·API·数据库全掌握
如果说RAG让智能体拥有了"知识"，那么工具调用（Tool Calling / Function Calling）就让智能体拥有了"双手"。没有工具的智能体只能"纸上谈兵"——能回答问题，但不能真正做事。有了工具，智能体就可以搜索网络、查询数据库、调用API、执行代码、发送邮件、操作企业系统，真正成为能干活的数字员工。
工具调用是智能体从"问答机器人"进化为"自主任务执行者"的关键技术。本章将带你深入学习工具调用的原理、设计方法和实战技巧。
• 突破知识边界：大模型的知识有截止日期，工具可以获取实时信息（搜索、API）
• 突破能力边界：大模型只能生成文本，工具可以执行实际操作（计算、代码、数据库、系统操作）
• 保证准确性：大模型可能算错、记错，工具可以提供精确的计算和数据查询
• 连接真实世界：通过API和系统集成，智能体可以操作真实的业务系统
• 可扩展性：通过添加新工具，智能体的能力可以无限扩展
一、工具调用的基本原理
1.1 什么是工具调用？
工具调用（Tool Calling，也叫Function Calling）是指大模型根据用户的需求，自动判断需要调用什么工具，并生成工具调用的参数，然后由系统执行工具调用，把结果返回给大模型，大模型再基于工具结果生成最终回答。
简单来说，工具调用就是大模型"说"出它想调用什么工具、传什么参数，系统"替"它执行，然后把结果告诉它。
用户："帮我查一下广州今天的天气，然后告诉我适不适合出门"
第一步：大模型判断需要调用工具
大模型思考：用户需要知道广州今天的天气，我的训练数据没有实时天气信息，需要调用天气查询工具。
第二步：大模型生成工具调用指令
大模型输出（JSON格式）：
{
"tool": "get_weather",
"params": {
"city": "广州",
"date": "2026-09-01"
}
}
第三步：系统执行工具调用
系统调用天气API，获取结果：
{
"city": "广州",
"date": "2026-09-01",
"weather": "多云转晴",
"temperature": "26-33℃",
"humidity": "75%",
"wind": "东南风2级",
"air_quality": "良"
}
第四步：把工具结果返回给大模型
系统把天气查询结果传给大模型。
第五步：大模型基于工具结果生成最终回答
大模型输出："广州今天（9月1日）多云转晴，气温26-33℃，湿度75%，东南风2级，空气质量良。
天气整体不错，适合出门。不过气温较高、湿度较大，建议做好防晒和补水，户外活动尽量避开中午最热的时段。"
这就是一个完整的工具调用过程：判断→调用→执行→返回→回答。
1.2 工具调用的技术实现
工具调用的实现依赖于大模型的"函数调用"（Function Calling）能力。目前主流的大模型（GPT-4o、Claude 3.5、DeepSeek、文心一言、通义千问等）都支持函数调用。
实现流程：
- 定义工具：开发者用JSON Schema格式定义工具的名称、描述、参数（名称、类型、是否必填、描述）
- 传给大模型：把工具定义和用户问题一起传给大模型
- 大模型决策：大模型判断是否需要调用工具，如果需要，输出工具调用指令（JSON格式，包含工具名和参数）
- 执行工具：系统解析大模型的输出，执行对应的工具/函数/API，获取结果
- 返回结果：把工具执行结果作为新的消息，和历史对话一起再次传给大模型
- 生成回答：大模型基于工具结果，生成最终的自然语言回答
工具定义的JSON Schema示例：
{
"name": "get_weather",
"description": "查询指定城市指定日期的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如'广州'、'北京'"
},
"date": {
"type": "string",
"description": "查询日期，格式为YYYY-MM-DD，如'2026-09-01'"
}
},
"required": ["city"]
}
}1.3 工具调用 vs 直接让大模型输出
有人可能会问："为什么不直接让大模型输出结果，还要绕一圈调用工具？"
答案是：大模型只能生成文本，不能执行实际操作。它不能真的去查天气API、不能真的去查询数据库、不能真的去发送邮件。它只能"假装"知道这些信息（这就是幻觉的来源）。而工具调用，让大模型可以"指挥"系统去执行这些操作，然后基于真实的执行结果来回答。
| 维度 | 大模型直接输出 | 工具调用 |
|---|---|---|
| 信息时效性 | 只有训练截止日期前的知识 | 可以获取实时信息 |
| 准确性 | 可能编造（幻觉） | 基于真实执行结果，准确可靠 |
| 能力范围 | 只能生成文本 | 可以执行各种实际操作 |
| 私有数据 | 不知道企业内部数据 | 可以查询企业数据库和系统 |
| 可追溯性 | 无法验证 | 工具执行结果可验证、可审计 |
二、常见的工具类型和实战场景
智能体可以调用的工具非常丰富，以下是最常见的几类工具及其应用场景：
2.1 信息检索类工具
这类工具帮助智能体获取外部信息，突破大模型的知识边界。
| 工具 | 功能 | 典型应用场景 |
|---|---|---|
| 网页搜索 | 搜索互联网，获取最新信息 | 查询最新政策、新闻、产品信息、技术文档 |
| 知识库检索 | 从企业知识库中检索相关信息 | 查询产品手册、内部制度、历史案例（即RAG） |
| 数据库查询 | 查询企业数据库中的数据 | 查询订单状态、客户信息、销售数据、库存 |
| API数据获取 | 调用第三方API获取数据 | 天气查询、股票行情、物流跟踪、汇率查询 |
| 文件读取 | 读取指定文件的内容 | 读取配置文件、数据文件、日志文件 |
2.2 计算处理类工具
这类工具帮助智能体进行精确的计算和数据处理，避免大模型"算错"。
| 工具 | 功能 | 典型应用场景 |
|---|---|---|
| 计算器 | 进行数学计算 | 财务计算、统计分析、单位换算 |
| 代码执行器 | 执行Python/JS代码，进行复杂计算和数据处理 | 数据分析、图表生成、算法执行、批量处理 |
| 数据清洗 | 清洗和格式化数据 | 去除重复、处理缺失值、格式转换 |
| 图表生成 | 根据数据生成图表 | 生成柱状图、折线图、饼图、仪表盘 |
2.3 内容生成类工具
这类工具帮助智能体生成各种格式的内容。
| 工具 | 功能 | 典型应用场景 |
|---|---|---|
| 文档生成 | 生成Word/PDF文档 | 生成报告、合同、方案、说明书 |
| PPT生成 | 生成演示文稿 | 生成汇报PPT、培训课件、产品介绍 |
| 图片生成 | 根据文字描述生成图片 | 生成产品示意图、海报、插图、UI设计稿 |
| 表格生成 | 生成Excel表格 | 生成数据表、报价单、计划表、统计表 |
| 代码生成 | 生成可执行的代码 | 生成脚本、接口、页面、工具函数 |
2.4 操作执行类工具
这类工具帮助智能体执行具体的操作，真正"动手干活"。
| 工具 | 功能 | 典型应用场景 |
|---|---|---|
| 浏览器操作 | 操作网页浏览器，完成网页任务 | 网页填表、数据抓取、自动化测试、系统操作 |
| 文件操作 | 读写、移动、删除文件 | 文件整理、批量重命名、格式转换 |
| 邮件发送 | 发送电子邮件 | 自动回复客户、发送报告、通知提醒 |
| 消息推送 | 发送即时消息 | 企业微信/钉钉/飞书消息通知、告警推送 |
| 系统命令 | 执行操作系统命令 | 服务器管理、日志查询、服务重启、文件备份 |
| API调用 | 调用任意REST API | 与企业系统（ERP、CRM、MES、OA）集成 |
2.5 通信协作类工具
这类工具帮助智能体与其他系统或人进行通信和协作。
| 工具 | 功能 | 典型应用场景 |
|---|---|---|
| 日历管理 | 查看和创建日程、会议 | 自动安排会议、提醒重要事项、协调时间 |
| 任务管理 | 创建和管理任务、待办事项 | 自动创建跟进任务、分配工作、跟踪进度 |
| 审批流程 | 发起和处理审批 | 自动发起报销、请假、采购审批 |
| 多智能体通信 | 与其他智能体交互 | 多智能体协作完成复杂任务 |
三、工具设计的核心原则和最佳实践
设计好的工具，是工具调用效果的关键。一个设计糟糕的工具，大模型经常调用错误（传错参数、选错工具）；一个设计好的工具，大模型几乎每次都能正确调用。以下是工具设计的核心原则：
原则一：单一职责——一个工具只做一件事
每个工具应该只做一件事，功能清晰明确。不要设计"万能工具"（如一个工具既可以查天气又可以查股票还可以发邮件），那样大模型很难正确判断什么时候用、传什么参数。
反例：handle_customer_request(type, params)——一个工具处理所有客户请求，type参数区分类型，大模型很容易传错type。
正例：拆分成query_order(order_id)、refund_order(order_id, reason)、change_address(order_id, new_address)等多个工具，每个工具职责单一。
原则二：描述清晰——让大模型知道什么时候用、怎么用
工具的名称和描述是大模型判断"是否调用这个工具"的依据。描述要清晰、准确、具体，让大模型一看就知道这个工具是做什么的、什么时候应该用。
反例：名称get_data，描述获取数据——太模糊，大模型不知道获取什么数据、什么时候用。
正例：名称get_customer_order_list，描述根据客户ID查询该客户的所有历史订单列表，包含订单号、下单时间、金额、状态。当用户询问"我的订单"、"历史购买记录"、"订单状态"时使用。——清晰明确，大模型知道什么时候用、能获取什么。
描述技巧：
- 说明工具的功能（做什么）
- 说明适用场景（什么时候用）
- 说明返回结果（能得到什么）
- 如果有多个相似工具，说明它们的区别（什么时候用A，什么时候用B）
原则三：参数规范——名称、类型、描述、是否必填都要明确
参数是大模型调用工具时需要传递的数据。参数定义要规范，每个参数都要有明确的名称、类型、描述、是否必填。
参数设计要点：
- 名称清晰：参数名要能反映含义，如
customer_id比id好，start_date比date1好 - 类型明确：string、integer、number、boolean、array、object，明确指定类型
- 描述详细：说明参数的含义、格式、取值范围。如日期格式"YYYY-MM-DD"、枚举值列出所有选项
- 必填/可选：明确哪些参数是必填的，哪些是可选的。可选参数要有默认值说明
- 枚举约束：如果参数只有几个固定值，用enum列出所有选项，大模型就不会传错
- 避免嵌套过深：参数结构不要太复杂，嵌套层级不要超过2层，否则大模型容易构造错误
参数描述示例：
"order_status": {
"type": "string",
"description": "订单状态，用于筛选指定状态的订单。可选值：pending(待付款)、paid(已付款)、shipped(已发货)、completed(已完成)、cancelled(已取消)。不传则返回所有状态的订单。",
"enum": ["pending", "paid", "shipped", "completed", "cancelled"]
}原则四：结果结构化——返回结构化的JSON，而不是自然语言
工具的返回结果应该是结构化的（如JSON），而不是一堆自然语言。结构化的结果更容易被大模型理解和使用，也方便后续的处理和校验。
反例：返回"查询到3个订单，第一个是2026-08-15下单的，金额500元，状态已完成；第二个是..."——大模型需要解析这段文字才能提取信息，容易出错。
正例：返回
{"total": 3, "orders": [{"order_id": "O001", "date": "2026-08-15", "amount": 500, "status": "completed"}, ...]}——结构清晰，大模型可以直接使用。
原则五：错误友好——出错时返回清晰的错误信息
工具执行失败时，应该返回清晰、具体的错误信息，告诉大模型哪里错了、该怎么修正。不要只返回"error"或"失败"，那样大模型不知道该怎么办。
反例：返回{"error": "查询失败"}——大模型不知道为什么失败、该怎么重试。
正例：返回{"success": false, "error_code": "ORDER_NOT_FOUND", "error_message": "订单号O999不存在，请检查订单号是否正确。订单号格式为O+3位数字，如O001。", "suggestion": "请向用户确认正确的订单号后重试"}——清晰说明错误原因和修正建议，大模型可以据此调整。
原则六：粒度适中——不要太粗也不要太细
工具的粒度要适中。太粗（一个工具做很多事），大模型难以正确调用；太细（一个工具只做一个原子操作），大模型需要调用很多次才能完成任务，效率低且容易出错。
经验法则：一个工具对应一个"业务动作"。比如"创建订单"是一个业务动作（包含验证库存、创建订单记录、扣减库存等多个内部步骤），可以作为一个工具。而"验证库存"、"创建订单记录"、"扣减库存"是内部步骤，不需要单独暴露为工具。
原则七：工具数量可控——不要给大模型太多选择
工具不是越多越好。工具太多，大模型会"选择困难"——不知道该用哪个工具，或者用错工具。一般来说，一个智能体同时可用的工具控制在5-15个比较合适。
管理技巧：
- 按场景分组：不同场景加载不同的工具集，而不是所有工具都加载
- 合并相似工具：功能相似的工具合并成一个，用参数区分
- 移除不常用工具：很少用到的工具暂时移除，需要时再加
- 工具描述中说明区别：如果有多个相似工具，在描述中明确说明"这个工具和XX工具的区别是..."
四、工具调用的高级技巧
4.1 多工具串联调用
复杂任务通常需要调用多个工具，按顺序串联执行。比如"查询客户订单→分析消费习惯→生成个性化推荐→发送推荐邮件"，需要调用4个工具。
实现方式：大模型在ReAct循环中，每次调用一个工具，获取结果后决定下一步调用什么工具，直到任务完成。系统需要支持多轮工具调用（大模型输出工具调用→系统执行→返回结果→大模型再输出工具调用→...）。
注意事项：
- 设置最大调用次数（如10次），避免无限循环
- 记录调用历史，方便调试和审计
- 如果某个工具调用失败，大模型应该能够调整策略（换工具、改参数、或告知用户）
4.2 并行工具调用
有些任务可以同时调用多个工具，并行执行，提高效率。比如"同时查询订单数据、客户数据、库存数据"，三个查询没有依赖关系，可以并行执行。
实现方式：大模型在一次输出中生成多个工具调用指令，系统并行执行这些调用，把所有结果一起返回给大模型。
注意事项：
- 只有没有依赖关系的工具才能并行调用
- 并行调用的结果要按顺序对应，不要搞混
- 如果其中一个调用失败，要能处理部分失败的情况
4.3 工具调用的校验和容错
大模型生成的工具调用参数可能有错误（类型不对、格式不对、缺少必填参数、值不在范围内）。系统应该在执行工具前进行参数校验，如果有错误，把错误信息返回给大模型，让它修正后重试。
容错机制：
- 参数校验：执行前校验参数类型、格式、范围，不合法则返回错误让大模型修正
- 超时控制：每个工具调用设置超时时间，避免长时间等待
- 重试机制：对于临时错误（网络超时、API限流），自动重试（最多3次）
- 降级方案：工具不可用时，有备用方案或告知用户"该功能暂时不可用"
- 最大调用次数：设置整个任务的最大工具调用次数，避免无限循环
4.4 工具调用的可观测性
工具调用是智能体执行过程中的关键环节，需要完整的日志和监控，方便调试和优化。
需要记录的信息：
- 每次工具调用的：工具名、参数、执行时间、执行结果（成功/失败）、返回数据
- 大模型的决策过程：为什么选择这个工具、思考过程
- 整个任务的工具调用链：调用了哪些工具、顺序是什么、每次的结果
- 统计指标：工具调用成功率、平均响应时间、常用工具排行、错误类型分布
4.5 动态工具加载
对于工具很多的场景，可以采用动态加载策略：根据用户的问题，先判断需要哪类工具，只加载相关的工具集，而不是加载所有工具。这样可以减少大模型的选择负担，提高调用准确率。
实现方式：可以用一个"工具路由器"（可以是大模型本身，也可以是分类器），先判断用户问题属于哪个场景，然后加载对应场景的工具集。
五、工具调用实战：制造业场景
场景：为工厂的生产主管设计一个智能体，可以查询生产进度、分析产能、处理异常、生成报表。
设计的工具集（共8个）：
1. query_production_progress（查询生产进度）
- 描述：查询指定日期/订单/产线的生产进度，包含计划产量、实际产量、完成率、在制品数量
- 参数：date(可选，默认今天)、order_id(可选)、line_id(可选)
- 返回：结构化的生产进度数据
2. query_capacity_analysis（产能分析）
- 描述：分析指定时间段的产能利用率，包含理论产能、实际产出、利用率、瓶颈工序
- 参数：start_date、end_date、line_id(可选)
- 返回：产能分析数据和图表数据
3. query_equipment_status（设备状态查询）
- 描述：查询指定设备或产线的设备运行状态，包含运行/停机/故障状态、运行时长、故障次数
- 参数：equipment_id(可选)、line_id(可选)
- 返回：设备状态列表
4. query_quality_data（质量数据查询）
- 描述：查询指定时间段的质量数据，包含良品率、不良品数量、不良类型分布、top缺陷
- 参数：start_date、end_date、product_id(可选)
- 返回：质量统计数据
5. create_work_order（创建生产工单）
- 描述：创建新的生产工单，指定产品、数量、计划完成时间、产线
- 参数：product_id(必填)、quantity(必填)、plan_finish_date(必填)、line_id(可选)
- 返回：创建结果和工单编号
6. update_work_order_status（更新工单状态）
- 描述：更新生产工单的状态（开始生产、暂停、完成、取消）
- 参数：order_id(必填)、status(必填，枚举：start/pause/complete/cancel)、remark(可选)
- 返回：更新结果
7. generate_production_report（生成生产报表）
- 描述：根据指定时间段的生产数据，生成完整的生产日报/周报/月报，包含进度、产能、质量、设备等维度
- 参数：report_type(必填，枚举：daily/weekly/monthly)、date(必填)
- 返回：报表内容（结构化，可导出为Excel/PDF）
8. send_notification（发送通知）
- 描述：向指定人员或班组发送企业微信通知，用于异常告警、任务分配、进度提醒
- 参数：receiver(必填，人员ID或班组ID)、title(必填)、content(必填)、priority(可选，枚举：normal/high/urgent)
- 返回：发送结果
工具设计亮点：
• 每个工具单一职责，功能清晰
• 工具描述详细，包含适用场景说明
• 参数有明确的类型、描述、枚举值
• 返回结果结构化
• 工具数量8个，在可控范围内
• 覆盖了生产管理的核心场景（查询、分析、操作、报表、通知）
• 工具调用（Tool Calling）让智能体从"问答机器人"进化为"自主任务执行者"，是智能体的核心能力
• 工具调用流程：定义工具→传给大模型→大模型决策生成调用指令→系统执行→返回结果→大模型生成回答
• 五大类工具：信息检索（搜索/数据库/API）、计算处理（计算器/代码执行）、内容生成（文档/PPT/图片）、操作执行（浏览器/邮件/API/系统）、通信协作（日历/任务/审批）
• 工具设计七大原则：单一职责、描述清晰、参数规范、结果结构化、错误友好、粒度适中、数量可控
• 高级技巧：多工具串联、并行调用、校验容错、可观测性、动态工具加载
• 关键原则：永远不要让大模型直接做复杂计算，一定要用工具！
下一章，我们将学习多智能体协作——这是应对复杂任务的高级技术。通过多个智能体的分工协作，可以完成单个智能体无法胜任的复杂项目级任务。
📝 本章练习（5题）
答案与解析请在 互动学习看板 中作答查看。
📚 AI智能体实战训练营 课程目录（33 章）
- 第1章 什么是AI智能体：从聊天机器人到自主决策系统
- 第2章 智能体的四大核心能力：感知·思考·行动·记忆
- 第3章 范式转移：智能体与传统软件的本质区别
- 第4章 2025年主流智能体平台全景对比与选型
- 第5章 智能体应用场景地图：从个人效率到企业级落地
- 第6章 编排思维：如何把大模型变成可执行的业务流程
- 第7章 Prompt工程实战：写出让智能体精准执行的指令
- 第8章 工作流编排入门：节点、连线、条件分支与循环
- 第9章 知识库RAG实战：让智能体拥有你的专业数据
- 第10章 工具调用实战：搜索·计算·API·数据库全掌握
- 第11章 多智能体协作：角色分工、任务分发与结果汇总
- 第12章 Coze/扣子入门：30分钟搭建你的第一个智能体
- 第13章 Coze进阶：插件开发、工作流深度编排与知识库优化
- 第14章 Dify入门：开源可私有化部署的智能体平台搭建
- 第15章 Dify进阶：RAG管道优化、Agent模式与工作流编排
- 第16章 LangChain入门：用代码构建可定制的智能体应用
- 第17章 LangChain实战：自定义Agent、工具链与记忆系统
- 第18章 Agent Harness与新一代框架：2025年智能体开发趋势
- 第19章 平台选型决策树：不同业务场景下的最优平台选择
- 第20章 任务拆解方法论：把复杂问题变成智能体可执行的步骤
- 第21章 提示词编排艺术：System·User·Function的三层协同
- 第22章 记忆系统设计：短期记忆、长期记忆与向量数据库选型
- 第23章 错误处理与容错：智能体执行失败时的兜底策略
- 第24章 评估与优化体系：如何量化衡量智能体的效果并持续改进
- 第25章 安全与合规：智能体应用的数据安全、隐私保护与风险防控
- 第26章 实战项目一：企业知识库智能问答助手（全流程实操）
- 第27章 实战项目二：制造业设备故障诊断智能体
- 第28章 实战项目三：供应链采购智能分析与比价助手
- 第29章 实战项目四：多智能体协同的项目管理办公室（PMO）
- 第30章 实战项目五：智能体与MES/ERP系统的深度集成
- 第31章 智能体落地路线图：从POC验证到规模化应用的完整路径
- 第32章 AI智能体工程师/产品经理的能力模型与成长路径
- 第33章 作品集打造与面试准备：如何拿到AI智能体岗位Offer