本文范围：只用一个订单退货案例讲清 LangChain 是什么、它发生了什么变化，以及一个 Agent 怎样跑完一轮。

先说结论

• LangChain 是一个用来快速搭 Agent 的开发框架。
• 它主要帮我把模型和工具接成一个能运行的 Agent：
  • 模型：
    • 理解问题，判断下一步。
  • Tool（工具）：
    • 查询真实数据，或者执行动作。
  • LangChain：
    • 把问题交给模型，执行模型选中的工具，再把结果送回模型。
• 可以把它想成：给一个客服接上公司后台。
  • 客服很会理解用户的话。
  • 但是它看不到订单，也不知道公司现在使用哪一版退货规则。
  • 我给它接上“查订单”和“查退货规则”两个工具。
  • LangChain 负责在客服、工具和用户之间传话，直到客服能够回答。

Tool：给模型使用的函数，例如查订单、搜索知识库或者创建工单。

• 现在不用先背 Models、Prompts、Chains、Memory 等一堆名词。
• 先记住这一条流程：

用户提问 → 模型决定要不要用工具 → 应用执行工具 → 结果交回模型 → 模型回答。

• 这套反复判断、使用工具、继续判断的过程，叫作 Agent Loop。
• 不用 LangChain，我也能直接调用模型 API。
  • 但模型一旦需要反复使用工具，我就要自己处理：
    • 调用哪个函数、函数结果怎样交回模型、什么时候结束。
  • LangChain 帮我省掉这些重复工作。
• LangChain 不是模型，也不会让模型自动变聪明。
  • 它更像一套已经装好的大模型应用脚手架。

LangChain 为什么和旧文章不一样

• 早期的 LangChain 像一个大工具箱。
  • 提示词、知识库、对话记录、固定流程和 Agent，什么都往里面放。
• 东西越来越多以后，入口也越来越多。初学者很难判断应该从哪里开始，复杂 Agent 也需要更灵活的控制。
• 所以官方后来做了一次大整理：
  • LangChain 专心帮我快速搭 Agent。
  • LangChain Agent 本身运行在 LangGraph 上。
  • 需要自己控制复杂步骤时，可以直接使用 LangGraph。
  • 当前 v1 用来创建 Agent 的主要入口是 create_agent。
• 这次变化对我只有一个影响：

旧文章里的“六大模块”可以当作历史背景；现在入门先学 create_agent，不用再背那套旧目录。

一个案例看懂 LangChain 怎样工作

• 用户问客服 Agent：

订单 A102 已经签收了，我现在还能退货吗？

• 模型不能直接回答，因为它不知道：
  • A102 的真实订单状态。
  • 当前正在使用的退货规则。
• 我给 Agent 两个工具：
  • get_order_status：查询订单状态。
  • search_refund_policy：查询退货规则。
• 这里的订单状态和退货规则都是模拟数据，不代表任何真实平台的政策。
• 然后这一轮这样运行：

模型负责判断“我还缺什么信息”；LangChain 负责调用工具，再把结果送回来；模型拿到真实结果后，才组织回答。

• 这里最容易搞错的是：

模型说“请调用工具”，不等于工具已经执行。

• 模型只是提出了一张“调用申请单”。
  • LangChain 收到申请后，才会执行工具。
  • 工具执行完，LangChain 再把结果交回模型。
• 模型没有直接进入订单数据库。
  • 真实订单和政策，仍然来自工具背后的业务系统。
  • 最终回答仍然可能出错，所以 LangChain 不能替代业务验证。

代码只看结构

• 下面不是完整项目，只看 create_agent 需要哪些东西：

from langchain.agents import create_agent


agent = create_agent(
    model="正在使用的模型",
    tools=[get_order_status, search_refund_policy],
    system_prompt="必须先查询真实订单和退货规则，再回答。",
)

agent.invoke({
    "messages": [
        {"role": "user", "content": "订单 A102 还能退吗？"}
    ]
})

• 这段结构只告诉 LangChain 四件事：
  • 使用哪个模型。
  • 开放哪些工具。
  • 回答时要遵守什么要求。
  • 用户刚才问了什么。
• 之后，create_agent 帮我反复运行前面的流程。

这个案例一定要用 Agent 吗

• 不一定。
• 如果所有退货问题都固定执行：

查订单 → 查规则 → 生成回答

• 那我直接写一个固定流程，会更简单、更稳定。
• 只有当用户问题很多样，模型需要自己决定查订单、查物流、查规则，还是继续追问用户时，Agent 才真正有价值。
• 所以学习 LangChain，不是为了把所有程序都改成 Agent。
• 真正要判断的是：

步骤能够提前写死，就写固定流程；下一步必须根据现场决定，才使用 Agent。

我现在最少需要记住什么

• LangChain 以前像一个什么都装的大工具箱。
• 现在 v1 把 Agent 当作主线，最常用的入口是 create_agent。
• 我把模型和工具交给 LangChain。
  • 它让模型判断下一步。
  • 需要时执行工具。
  • 把工具结果交回模型。
  • 继续判断，直到得到答案。
• 固定步骤不需要 Agent。
• 只有下一步要根据现场决定时，Agent 才有价值。

考考你

LangChain 是做什么的？

它把模型、工具和应用流程接起来，帮助我开发大模型应用和 Agent。它本身不是大模型。

LangChain 为什么从六大模块变成以 Agent 为主？

早期 LangChain 什么都装，后来入口越来越多。现在 v1 以 Agent 为主线，入门先学 create_agent。

当前 LangChain 创建 Agent 的主要入口是什么？

create_agent。我把模型、工具和要求交给它，它负责反复运行“判断、使用工具、拿回结果”这套流程。

模型说调用工具，工具就已经执行了吗？

没有。模型只是提出调用请求，LangChain 还要真正执行工具，再把结果交回模型。

LangChain 和 LangGraph 是什么关系？

LangChain 帮我快速搭一个 Agent，它的 Agent 本身运行在 LangGraph 上。需要自己控制复杂步骤时，可以直接使用 LangGraph。

什么情况下不应该使用 Agent？

步骤能够提前确定时，直接写普通流程更简单、更稳定。只有下一步确实需要模型根据现场决定时，才使用 Agent。

参考

• 【内部：旧笔记：LangChain 基础入门】
• 【内部：旧笔记：LangChain 概述】
• 从模型 API 到 Agent 应用，还差什么？
• LangChain v1 release
• LangChain v1 migration guide
• langchain 1.3.14