Tool与Middleware的区别
在 LangChain 1.0 的 Agent 体系中，「Tool」与「Middleware」虽然都可扩展 Agent 的能力，但它们适用的场景完全不同，当我们需要对一些业务逻辑进行扩展和封装时，那么就需要判断是封装在Tool工具里还是封装在Middleware中间件里。判断标准核心在于：
是否需要让 LLM 通过决策（reasoning → act）来显式调用这段逻辑？
| 维度 | Tool（工具） | Middleware（中间件） |
|---|---|---|
| 作用对象 | 封装具体业务功能（RAG检索、API调用） | 封装执行流程控制（日志、重试、限流） |
| 调用方式 | 由LLM自主决策调用（通过function calling） | 在Agent执行固定节点自动触发（before/after模型调用） |
| 设计目的 | 扩展Agent的能力边界 | 增强Agent的可靠性、安全性、可观测性 |
| 状态访问 | 接收参数，返回结果 | 可直接读写AgentState，控制执行流（如jump_to=“end”） |
| 执行概率 | 0% ~ 100% (不确定) | 100% (确定) |
请在设计功能判断封装场景时，问自己以下三个问题：
- 谁来决定“做不做”？(Who decides?)
- 需要 LLM 根据上下文判断是否执行 → Tool
- 例子：搜索互联网、查询天气、计算器。因为用户可能只是打招呼，不需要搜索。
- 业务流程规定必须执行 → Middleware / Node
- 例子：权限校验、敏感词过滤、日志记录、固定的知识库召回（如客服系统）。
- 参数从哪里来？(Where do args come from?)
- 参数需要从用户的自然语言中提取 → Tool
- 例子：用户说“帮我查下特斯拉的股价”，Tool 需要提取“特斯拉”作为参数。
- 参数是系统上下文或环境变量 → Middleware / Node
- 例子：用户的 UserID、当前的 SessionID、数据库连接配置。这些不需要 LLM 去“猜”。
- 失败了怎么办？(Error Handling)
- 失败了需要 LLM 换个方式重试 → Tool
- 例子：搜索不到结果，LLM 可以尝试换个关键词再次调用 Tool。
- 失败了直接抛异常或走系统降级 → Middleware / Node
- 例子：数据库连接断开、API 鉴权失败。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qq_45629145/article/details/169933132
