LangChain 中的 Tool（工具）

在 LangChain 里，Agent 本质上是一个能干活、会思考的 AI 实体，它的本事很大程度上取决于手上有多少好用的“工具”。这些工具就是一些有特定功能的小模块——比如查个当前时间、访问一下数据库，Agent 通过调用它们来完成复杂任务。说白了，工具就是给 Agent 开了个“外设”，让它能执行特定操作。

这些工具可以直接传给支持工具调用的聊天模型，模型拿到后就能在需要时请求执行某个函数，带上具体的参数。整个过程就像是模型在说：“我想用这个工具干这件事，帮我跑一下。”

工具的核心接口

所有工具的底层标准都定义在 BaseTool 类里，它继承自 LangChain 的 Runnable 接口。所以工具本身也是可调用的执行单元，拥有统一的生命周期。

和工具模式直接相关的几个关键属性：

• name
  ：工具的名字，模型靠它来匹配和调用。

• description
  ：描述工具是干嘛的，越清晰越好。

• args
  ：返回工具参数的 JSON 结构，模型依据这个来填参数。

执行层面主要有两个方法：

• invoke
  ：同步调用，给参数直接运行。

• ainvoke
  ：异步调用，适合 LangChain 的异步编程场景。

用 @tool 装饰器创建工具

写工具最推荐的方式就是直接用 @tool 装饰器。它极大简化了创建过程，自动帮你搞定三件事：

• 自动推断工具的名称、描述和输入参数（当然你也可以手动覆盖）。
• 支持生成包含“工件”（artifact）的工具，比如返回一张图片或一个 DataFrame。
• 支持注入工具参数，这样某些内部参数就不会暴露给模型。

具体做法很简单：定义一个普通函数，然后在它头上加 @tool，这个函数就成了一个符合工具接口的可调用对象。你还能在装饰器里指定额外配置，比如修改名字、描述，或者让装饰器自己解析函数的文档字符串来推断参数模式。深度的定制可以戳官方文档：https://python.langchain.com/api_reference/core/tools/langchain_core.tools.convert.tool.html

定义好之后，直接像调用普通函数一样调用就可以。另外还可以随时查看这个工具的结构（比如它的 JSON schema）和其他属性。

一点设计上的小建议

给模型设计工具时，有几个坑可以提前避开：

• 工具的名字、文档字符串以及参数的类型提示越准确，模型就越容易用对。
• 保持工具功能单一、范围狭窄，这样模型选错的可能性会小很多。
• 一定要用支持工具调用 API 的聊天模型，才能充分发挥工具的价值。
• 尽量别给模型一个超长的工具列表——让它在几十个甚至上百个选项里选，难度会直线上升。

工具调用的完整流程

很多 AI 应用最终要和人类对话，这时候自然语言回复就够了。但如果想让模型直接去调一个数据库或外部 API，那就需要它输出符合特定格式的结构化数据——这就是工具调用（有时也叫函数调用）概念的由来。模型不再只是说“我要查天气”，而是直接输出一个结构化的请求：“请调用 get_weather 函数，参数为 city=北京”。

整个流程可以分为四步：

1. 创建工具
   ：用 @tool 装饰器先做出来。

2. 绑定工具
   ：把工具通过 .bind_tools() 方法绑到模型上，让模型知道现在有这些工具可用，以及每个工具的参数结构长什么样。

3. 调用工具
   ：根据用户输入，模型自主判断是否要调用工具。如果决定调用，它输出一个符合工具参数模式的响应。

4. 执行工具
   ：拿到模型回传的工具调用指令（包含工具名和参数），直接扔给工具的 invoke 方法去执行。

下面的伪代码演示了标准工作流。创建好的工具放进一个列表，传到 .bind_tools() 里。然后像往常一样调用模型。如果模型认为需要工具，它的返回消息里会多出一个 tool_calls 属性，里面罗列了调用的工具名和参数。之后把这些参数原封不动传给工具即可。

值得注意的一点是：模型并不总是需要调用工具。它自己会根据输入的相关性做判断——比如你问“你好”，它大概率不会去调任何工具，直接回一句“你好”就够了。结果会是一个普通的 AIMessage。但如果你问一句“今天北京的气温如何”，而模型正好绑了一个天气工具，它很可能就会选择调用，返回的 AIMessage 里就会带上 tool_calls 属性，里面每个条目都包含了工具名称和对应的输入参数。