Phase 5 讲 Agent 的「手」（工具）和「脑」（记忆）。这一篇先讲工具——怎么定义工具、怎么让模型会用工具。
工具是 Agent 能「做事」的关键。没有工具，Agent 只能说话；有了工具，Agent 能查数据、调接口、执行操作。这一篇讲 LangChain 的工具定义和绑定。
工具的本质：给模型看的 API
理解工具，最关键的一点：工具的描述和参数 schema，就是给模型看的「API 文档」。
模型决定调哪个工具、传什么参数，完全依据你提供的工具描述。描述写不清楚，模型就会乱调；参数 schema 不明确，模型就会传错参数。
所以定义工具时，描述要像写给同事看的接口文档一样认真——这个工具干什么、什么时候用、参数什么含义、返回什么。模型就是你的「调用方同事」，它按这份文档决定怎么用。
定义工具：三种方式
LangChain 提供三种定义工具的方式：
| 方式 | 用法 | 适合 |
|---|---|---|
@tool 装饰器 |
给函数加 @tool，自动从 docstring + 类型注解生成 schema |
最常用、最简单 |
| StructuredTool | 显式指定参数 schema（Pydantic） | 参数复杂、要严格校验 |
| 继承 BaseTool | 完全自定义 _run/_arun |
需要复杂初始化状态 |
最常用的是 @tool：你写个普通函数，加 docstring（说明干什么），加类型注解（说明参数），@tool 自动把它转成模型能理解的工具。
@tool
def search_order(order_id: str):
"""根据订单号查询订单状态。当用户问订单相关问题时使用。"""
return db.query(order_id)
注意 docstring——它是工具描述的主要来源，模型靠它判断「什么时候用这个工具」。写清楚「干什么、何时用」。
bind_tools：把工具绑给模型
定义好工具后，要用 bind_tools 把它绑给模型：
model_with_tools = model.bind_tools([search_order, send_email])
bind_tools 做的事：把工具的描述和 schema 告诉模型，让模型在生成时能「决定调用某个工具并给出参数」。
绑完后，模型的输出可能包含「工具调用」——它说要调哪个工具、传什么参数。Agent（第 18 篇的 create_agent）就是解析这个，执行工具，再把结果回灌模型。
v1.0 的标准化：统一各家模型
bind_tools 在 v1.0 有个重要价值：统一了各家模型的工具调用格式。
不同模型厂商（OpenAI、Anthropic、Gemini）的「工具调用」原生格式不一样。如果没有标准化，你换一家模型，绑定工具的代码要重写。bind_tools 把这些差异抹平——不管什么模型，用同一套 API 绑定工具。
这是 v1.0 的一个具体收益：工具调用从「每家模型各写一套」变成「一套 API 通吃」。
一个容易忽视的点：工具数量与质量
定义工具时容易两个极端：
- 工具太少：Agent 能做的事有限，很多需求满足不了
- 工具太多/描述差：模型选择困难，不知道该调哪个，容易乱调
工具不是越多越好。一组职责清晰、描述准确的工具，比一堆描述模糊的工具好用得多。模型在十几个描述清晰的工具里选，比在五十个描述含糊的工具里选，准确率高得多。
所以定义工具，宁缺毋滥，描述要精。每个工具的「干什么、何时用」要写得模型一看就懂。
工具也是 Runnable
和其它组件一致，工具也是 Runnable——invoke 执行工具。所以它能进 LCEL 链，能被追踪。在 Agent 里，工具的执行就是 tool.invoke(参数)。
收束：工具是 Agent 的手，描述是关键
这一篇讲了工具调用：
- 工具的描述和 schema 就是给模型的 API 文档，要认真写
- 三种定义方式，
@tool最常用 bind_tools把工具绑给模型- v1.0 的 bind_tools 统一了各家模型格式
- 工具质量比数量重要，描述要精
- 工具也是 Runnable
下一篇讲 MCP——一个让工具能跨应用共享的开放协议。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
