LangChain

先确认你要省掉哪部分工作#

当应用要接入模型、定义工具并反复处理工具结果时，重复的连接代码会越来越多。LangChain 提供接口与常见智能体执行结构；它本身不提供模型的训练知识。当前官方入口包括 create_agent，可组合模型、工具、提示和中间件。1 2

本站的工程建议是：先写出最小业务流程，再决定引入多少框架。代码行数变少只是收益之一，调试成本、依赖升级和团队理解成本也要一起比较。

一次工具调用经过谁#

以“查询订单状态”为教学情境：应用接收问题，模型提出查询工具及参数，工具访问订单服务，工具结果回到模型，模型再组织回答。LangChain 可以组织这一循环，应用仍须在访问服务前检查用户是否拥有该订单的读取权限。2

记录每一步的模型输入、工具参数、耗时和错误。模型把订单号写对，不代表当前用户有权查看；工具执行成功，也不代表最终回答正确。有关职责分离见工具调用。

和 LangGraph 怎么选#

LangChain 偏向复用模型、工具与常见智能体结构；LangGraph 提供更底层的状态与流程编排。LangChain 的智能体建立在 LangGraph 之上，二者可以配合，不应理解为必须二选一的竞争产品。1

如果需求只是常见工具循环，先验证 LangChain 是否够用；如果必须明确每个节点、分支、暂停与恢复位置，再研究 LangGraph。这是本站的选择建议，不是性能排名。

动手验证#

无需安装依赖，先拿一个真实需求画出四列：输入、模型决策、工具动作、业务校验。再加入“模型提出不存在的工具”“工具超时”“越权订单”三个失败输入。

验收标准：每个失败都有明确处理位置，并且能说清框架负责哪一步。如果唯一的模型动作就是返回一个标签，用直接调用加结构化输出完成同一练习，比较两种方案的维护工作量。此练习是设计检查，不是已运行的框架性能测试。