工具调用（Tool / Function Calling）入门与自定义 Tool 编写

引言：为什么很多 Agent 看起来“像会做事”？

很多人第一次看到 Agent，会觉得很神奇。

例如：

• 帮我查天气
• 帮我搜航班
• 帮我发邮件
• 帮我读数据库
• 帮我调用公司内部接口

模型居然真的能“去做”。

于是很多人会误以为：

大模型本身就会查天气、会发邮件、会操作系统。

但实际上，大模型本身什么都不会。

它既不能联网，也不能直接访问数据库，更不会真的帮你点按钮。

真正让 Agent 看起来“会做事”的关键，是 Tool Calling（工具调用）。

一句话理解：

模型负责“决定要做什么”，工具负责“真正执行”。

例如：

用户：帮我查一下北京明天的天气。

模型并不会直接知道天气。

它真正做的，是：

我需要调用 weather_tool(city="北京")

然后程序去执行真正的天气 API，再把结果返回给模型。

最后模型再整理成自然语言回复用户。

所以，一个真正的 Agent，本质上通常是：

用户 → 模型判断是否需要工具 → 调用工具 → 得到结果 → 模型整理输出

这篇文章，我们就来讲清楚：

1. 什么是 Tool / Function Calling
2. 模型到底是怎么调用工具的
3. 如何在 LangChain 中编写自己的 Tool
4. 如何让 Agent 调用你的数据库、API、公司系统

一、什么是 Tool Calling？

所谓 Tool Calling，就是：

给模型一组“它可以使用的工具”，由模型自己决定什么时候调用。

例如：

你给模型两个工具：

1. 查询天气 2. 查询股票

然后用户说：

北京明天天气怎么样？

模型会自动判断：

这个问题需要用“查询天气”工具。

而不会去调用股票工具。

再比如：

帮我查一下英伟达最近股价。

模型就会选择股票工具。

Tool Calling 和普通 Prompt 最大区别

普通 Prompt：

用户提问 → 模型直接回答

Tool Calling：

用户提问 → 模型判断是否需要工具 → 调用工具 → 拿到结果 → 再回答

所以：

Tool Calling 是 Agent 真正开始“行动”的第一步。

二、Function Calling 到底是什么？

你可能会看到两个名字：

• Tool Calling
• Function Calling

它们本质上几乎是同一个东西。

区别只是：

• Tool：更偏 Agent / LangChain 里的说法
• Function Calling：更偏 OpenAI API 的说法

例如，OpenAI 会要求你先告诉模型：

{"name":"get_weather","description":"查询城市天气","parameters":{"city":"string"}}

然后模型可能返回：

{"tool_call":{"name":"get_weather","arguments":{"city":"北京"}}}

这时，你的程序再真正去执行：

get_weather("北京")

最后把结果回给模型。

所以要特别记住：

模型不会真的执行函数。
它只是“告诉你，它想调用哪个函数”。

真正执行的，是你的代码。

三、一个最简单的 Tool 示例

先看一个最小例子。

我们写一个天气工具：

fromlangchain.toolsimporttool@tooldefget_weather(city:str)->str:"""查询指定城市的天气"""returnf"{city}今天晴天，25度。"

这里：

• 函数名：get_weather
• 参数：city
• 返回值：字符串
• 注释：告诉模型这个工具是干什么的

注意这个 docstring 很重要：

"""查询指定城市的天气"""

因为模型会根据这个描述，判断什么时候应该调用这个工具。

四、让模型真正调用 Tool

接下来，把工具交给模型。

fromlangchain_openaiimportChatOpenAIfromlangchain.agentsimportinitialize_agent,AgentType llm=ChatOpenAI(model="gpt-4.1-mini")tools=[get_weather]agent=initialize_agent(tools=tools,llm=llm,agent=AgentType.OPENAI_FUNCTIONS,verbose=True)

然后调用：

response=agent.invoke("北京今天天气怎么样？")print(response)

运行时，你会看到类似过程：

模型判断：需要调用 get_weather 调用参数：city="北京" 工具返回：北京今天晴天，25度。 最终回答：北京今天晴天，25度。

这就是一个最基础的 Agent + Tool Calling。

五、自定义 Tool：调用你自己的 API

真实项目里，你不会只查天气。

更常见的是：

• 调公司接口
• 查数据库
• 调 ERP
• 调 CRM
• 调订单系统
• 调 MCP 平台

例如：

@tooldefquery_order(order_id:str)->str:"""根据订单号查询订单状态"""# 实际项目里，这里通常会调用数据库或 HTTP APIiforder_id=="123456":return"订单123456：已发货，预计明天送达。"return"未找到订单。"

然后：

response=agent.invoke("帮我查一下订单123456现在到哪了")

模型就会自动提取：

order_id = 123456

然后调用query_order。

这也是为什么很多企业里的 Agent，最终看起来像“会操作业务系统”。

因为它背后其实是：

LLM + 公司已有接口

六、Tool 最重要的，其实是描述

很多人第一次写 Tool 时，会觉得：

代码写好了，为什么模型不用？

最常见的原因，不是代码错了，而是 Tool 描述太差。

例如：

@tooldeffoo(x:str):return...

模型根本不知道这个工具是干什么的。

更好的写法应该是：

@tooldefsearch_flight(city:str)->str:"""查询指定城市最近的航班信息"""

Tool 最好满足三点：

• 名字清楚
• 注释清楚
• 参数清楚

例如：

@tooldefsend_email(to:str,subject:str,content:str)->str:"""向指定邮箱发送邮件"""

模型看到后，就更容易知道：

• 什么情况下该调用
• 参数应该填什么

七、Tool 可以不只是返回字符串

真实项目里，Tool 往往会返回结构化数据。

例如：

@tooldefget_user_info(user_id:str)->dict:"""根据用户ID查询用户信息"""return{"name":"张三","vip":True,"balance":120.5}

模型收到后，可以继续推理：

用户是 VIP，余额 120.5 元。

很多复杂 Agent，本质上就是：

调用工具 → 得到结构化结果 → 再调用下一个工具 → 最后总结

八、多个 Tool 时，模型如何选择？

例如：

tools=[get_weather,query_order,send_email]

然后用户说：

帮我查一下订单123456

模型通常会自动选择：

query_order

而不是天气或邮件。

所以 Agent 的关键不是“写很多 Tool”，而是：

Tool 描述要足够清晰，让模型知道该选哪个。

如果两个 Tool 描述太像，模型就容易选错。

例如：

search_user query_user

模型就不一定分得清。

更好的方式是：

根据用户ID查询用户资料 根据手机号查询用户资料

九、Tool Calling 的局限

虽然 Tool Calling 很强，但它也有几个常见问题。

1. 模型可能调用错工具

例如：

• 本来该查订单
• 却调用了查用户

2. 模型可能参数提取错误

例如：

订单123456

被错误提取成：

12345

3. 模型可能明明不需要工具，却还是调用

因此，真实项目里通常会加：

• 参数校验
• 权限校验
• 白名单
• Tool 调用日志

例如：

ifnotorder_id.isdigit():return"订单号格式错误"

十、企业项目里，Tool 往往就是“系统能力接口”

如果你做的是企业 Agent，那么你的 Tool 很可能不再是：

• 查天气
• 查股票

而是：

• 查询订单
• 创建工单
• 发起审批
• 查询 CRM
• 查询数据库
• 调用 MCP
• 调用内部微服务

例如，你之前做的 MCP 平台，本质上就非常适合作为 Agent 的 Tool 层。

因为 MCP 本身就是：

把各种系统能力统一封装成标准接口。

那么 Agent 只需要：

模型决定调用哪个能力 → MCP 执行 → 返回结果

这正是企业级 Agent 最常见的架构。

十一、一个推荐的 Tool 设计原则

如果你准备自己设计 Tool，建议遵守下面几个原则：

1. 一个 Tool 只做一件事
2. 名字和描述尽量明确
3. 参数不要太多
4. Tool 不负责复杂逻辑
5. 复杂流程交给 Agent 编排

例如：

不要写：

万能业务处理工具

而要拆成：

• 查询订单
• 查询用户
• 创建工单
• 发送短信

这样模型才更容易选对。

十二、下一步：Tool Calling 之后，才是真正的 Agent

很多人第一次接触 Tool Calling，会觉得：

这不就是模型调用函数吗？

没错。

但真正的 Agent，并不是只调用一次 Tool。

它通常会：

思考 → 调工具 → 看结果 → 再思考 → 再调工具 → 最终完成任务

例如：

用户：帮我安排下周去上海出差

Agent 可能会：

1. 查日程
2. 查机票
3. 查酒店
4. 比较预算
5. 发确认邮件

而这背后，其实就是很多 Tool 串起来。

下一篇，我们就会进入真正的 Agent：

ReAct：模型如何边思考、边调用工具、边观察结果。

结语

一句话总结：

Tool Calling 是 Agent 真正开始“行动”的能力。

模型不负责真正执行。

模型真正负责的是：

• 判断是否需要工具
• 选择哪个工具
• 提取参数
• 根据结果继续推理

而你负责：

• 提供 Tool
• 执行 Tool
• 返回结果

只要你掌握了 Tool Calling，你就已经迈出了从“聊天机器人”到“真正 Agent”的第一步。