Tool Node：如何把外部工具接入 LangGraph

上一篇文章里，我们讨论了 Reducer。

一个重要结论是：

多个节点更新 State 时，必须有清晰的合并规则，否则状态会乱。

但 Agent 真正变得强大，不只是会改 State。

它还要会调用工具。

比如：

查数据库
调用搜索接口
读写文件
请求内部服务
触发工作流

这就涉及 Tool Node。

这篇文章讨论：

LangGraph 里怎么把外部工具接入图流程？

为什么工具调用很重要？

如果 Agent 只能回答模型本身“记得的内容”，那它的能力就很有限。

真实业务里，很多问题都需要外部工具支持。

比如：

查订单状态
看库存
查用户资料
查知识库
生成报表
执行审批
读取文件
写入系统

Agent 的价值，很大一部分就是把这些工具串起来。

所以 Tool Node 是 Agent Workflow 的关键能力之一。

Tool Node 的基本作用

Tool Node 可以理解为图里的工具执行节点。

它通常负责：

接收工具调用请求
校验参数
执行工具
记录结果
把结果写回 State

例如：

模型决定要查订单
↓
Tool Node 调用订单服务
↓
把订单结果写回 State
↓
后续节点基于结果继续处理

这样工具就进入了图流程，而不是散落在业务代码里。

工具调用不要只看“能不能调”

很多人一开始接工具，只想着：

模型能不能调用成功？
接口能不能返回？

但工程上真正重要的是：

参数对不对
权限够不够
结果是否可信
失败怎么处理
超时怎么处理
重试怎么处理

工具调用不是简单的函数调用。

它往往涉及真实业务系统。

所以必须把它当成一个受控步骤，而不是任意执行的动作。

Tool Node 要有明确输入输出

和普通 Node 一样，Tool Node 也应该有清楚边界。

输入通常包括：

工具名称
工具参数
当前用户上下文
租户或权限信息

输出通常包括：

tool_result
tool_status
tool_error
tool_latency

这样后面的节点才能知道工具是否成功、结果是否可用、是否需要重试。

工具参数一定要校验

这是非常重要的一点。

Agent 生成的工具参数不一定可靠。

比如模型可能：

传错字段名
传错类型
漏掉必填参数
生成不存在的 ID

所以 Tool Node 必须做参数校验。

不要直接把模型输出原样丢给真实系统。

尤其是涉及：

写数据库
删除数据
发通知
执行审批
修改配置

这类高风险操作时，校验尤其重要。

工具调用要考虑失败路径

真实工具一定会失败。

常见情况包括：

超时
接口返回错误
网络失败
权限不足
参数错误
依赖服务不可用

所以 Tool Node 不能只设计成功路径。

还要设计失败后的图流程。

比如：

Tool 调用失败
↓
判断是否可重试
├─ 可重试：重试
└─ 不可重试：切换备用工具或转人工

这类设计比“调用失败就报错”更符合 Agent 场景。

工具结果应该回写到 State

Tool Node 执行完后，不只是返回一个值给下一步。

更重要的是把关键结果写回 State。

比如：

tool_result
tool_status
tool_error
attempt_count
last_tool_name

这样后面的节点可以根据状态继续判断。

如果只把结果局部传递，流程一复杂就很难追踪。

Tool Node 和权限控制有关

工具调用不是完全自由的。

有些工具只能某些角色调用。

有些工具在某些租户下不可用。

有些操作需要人工确认。

比如：

查询类工具可以直接调用
写入类工具需要审批
删除类工具必须双重确认
跨租户工具不能执行

所以 Tool Node 往往要结合权限层一起设计。

不能让模型决定一切。

工具是否可调用，应该由系统规则约束。

Tool Node 适合和 Conditional Edge 配合

工具节点通常不会单独存在。

它常常和条件边配合使用。

比如：

判断是否需要工具
├─ 不需要：直接回答
└─ 需要：进入 Tool Node
         ↓
       判断工具结果
       ├─ 成功：继续
       └─ 失败：重试或转人工

这会让工具调用和流程控制分离。

模型负责提出动作。

图结构负责控制动作是否执行、执行后去哪。

常见误区

第一个误区，是把工具当作普通函数直接暴露给模型。

这样风险太高。

第二个误区，是不做参数校验。

模型输出不能直接等于真实请求。

第三个误区，是工具调用失败后没有兜底。

真实系统必须考虑失败路径。

第四个误区，是工具结果不回写 State。

这样后续节点就没有上下文。

第五个误区，是所有工具都能被模型自由调用。

权限边界必须由系统控制。

总结

Tool Node 的价值，是把外部工具纳入 Agent Workflow。

它让模型不只是会说，还能去查、去算、去执行。

但工具调用不能失控。

必须考虑：

参数校验
权限边界
失败路径
重试策略
结果回写

只有把工具调用做成图里的受控节点，Agent 才更像一个可靠系统，而不只是一个会说话的模型。

下一篇文章，可以继续讨论 Human-in-the-loop。

因为不是所有工具调用都应该自动执行，有些操作必须留给人来确认。