LangChain、LangGraph 和 LangSmith 正在重塑 AI Agent 的开发范式。从标准化接口、复杂流程编排到生产级质量验证，这三个工具构成了完整的 Agent 开发生命周期。本文通过医疗分诊 Agent 的实战案例，带你深度解析这套技术栈如何应对真实业务场景中的多轮对话、紧急分流和人工审批等复杂需求。

在正式开始之前，先给这三个名词各一句话的定义，帮你在脑中建立一个基础坐标系。

• LangChain 是一个开源框架，它提供了连接大语言模型与外部工具、数据源的标准化接口，让你能快速搭建一个 AI Agent 的基础能力。
• LangGraph 是一个底层编排引擎，它用”图”的方式来建模 Agent 的工作流——每个动作是一个节点，每个决策是一条边——让 Agent 能处理有分支、有循环、有状态记忆的复杂业务流程。
• LangSmith 是一个商业化平台，它负责 Agent 的可观测性、质量评估和生产部署——简单说，它让你能看到 Agent 每一步在干什么、判断 Agent 好不好用、并最终把 Agent 安全地推上线。

这三者都来自同一家公司 LangChain Inc.，但它们解决的是 Agent 开发生命周期中三个截然不同的阶段。一个简单的类比：如果把造 Agent 比作造一辆车，LangChain 是零部件供应商，LangGraph 是总装车间里的流水线，LangSmith 是质检站加4S店。零件得先有，流水线才能组装，质检通过了才能交付给用户。

接下来，我们不做干巴巴的名词解释。我们来讲一个故事——一个医疗问诊 Agent 从零开始被创造、被打磨、最终上线的完整旅程。在这个故事里，你会自然地理解每个工具在什么时候登场、为什么登场、以及它到底解决了什么问题。

故事的起点：我们要造什么

假设你是一家互联网医疗公司的 AI 产品经理。公司决定开发一个”智能分诊 Agent”——患者在线上描述自己的症状，Agent 需要完成几件事：理解患者的自然语言描述，判断症状的紧急程度，匹配最合适的科室，最终给出一份结构化的就医建议。

这不是一个简单的聊天机器人。它需要医学知识储备，需要多轮对话来追问模糊症状，需要在涉及紧急情况时触发特殊流程，还需要在输出用药建议前经过人工医生的审批。最关键的是，这是一个医疗场景——容错率极低，每一步决策都必须可追溯、可解释。

带着这个需求，我们出发。

第一阶段：搭骨架——让 Agent 先能跑起来

LangChain 登场

任何 Agent 的开发都从一个最基本的问题开始：它需要哪些”器官”？

对我们的分诊 Agent 来说，它需要三样东西：一个足够聪明的”大脑”来理解患者的描述，一双能查阅医学知识的”手”来检索相关信息，以及一套输出格式来生成结构化的分诊建议。

LangChain 解决的就是这个阶段的问题。它像一个标准化的零部件供应商，把构建 Agent 所需的每一个模块都做了封装和标准化。

第一个能力：模型接口的标准化。 在 LangChain 出现之前，如果你想让 Agent 用 Claude 做推理，你需要写一套 Anthropic 的 API 调用代码；如果后来想换成 GPT-4，你得重写一遍 OpenAI 的接口；如果还想试试 Gemini，再来一遍。每家模型厂商的 API 格式、参数命名、返回结构都不一样。LangChain 做的事情是在这些不同的 API 之上建了一层统一的抽象——你只需要改一个模型名称的字符串，底层的调用方式、消息格式、返回解析全部自动适配。对于我们的分诊 Agent 来说，这意味着你可以先用 Claude 跑通功能，然后轻松切换到 GPT-4o 做对比测试，看看哪个模型在医学推理上表现更好，而不需要改动任何业务逻辑代码。

这不是一个小事。在实际的产品开发中，模型选型往往需要经历多轮测试和对比。如果每次换模型都要改代码，不仅浪费工程资源，还容易引入新的 bug。LangChain 的模型标准化接口，让”换模型”这件事变成了改一行配置，而不是一次代码重构。目前 LangChain 已经集成了超过一千个外部服务和模型提供商，覆盖了市面上几乎所有主流的大语言模型。

第二个能力：Tool Calling 的封装。 Agent 之所以比普通的聊天机器人强大，核心在于它能”动手做事”——不只是生成文字，而是能调用外部工具来获取信息、执行操作。对我们的分诊 Agent 来说，它需要调用疾病知识库来检索症状与疾病的对应关系，需要调用科室信息数据库来匹配合适的就诊科室，可能还需要调用一个紧急程度评估模型来判断患者是否需要立即就医。

在 LangChain 中，你只需要把这些外部能力定义为”工具”，每个工具有一个名字、一段描述和一个执行函数。Agent 在推理过程中会根据当前的对话内容，自主决定要不要调用某个工具、传什么参数。这就是所谓的 Tool Calling——模型不只是回答问题，而是在需要的时候主动”拿起工具干活”。

举个具体的例子。患者说”我最近总是头晕，早上起来特别明显，有时候还会耳鸣”。Agent 的大脑——大语言模型——理解了这段话之后，会自主判断”我需要查一下头晕加耳鸣可能对应什么疾病”，然后调用疾病知识库工具，传入”头晕””晨起加重””耳鸣”这几个关键词，拿到检索结果后再综合生成回复。整个过程中，Agent 什么时候调工具、调哪个工具、传什么参数，都是模型自己决定的。你只需要在一开始定义好工具有哪些，具体的调用时机交给 Agent 的推理能力来判断。

第三个能力：Agent 预制架构。 LangChain 内置了一套叫做 ReAct 的 Agent 模式。ReAct 的全称是 Reasoning and Acting——推理与行动交替进行。简单说，Agent 的每一步都遵循”想一想 → 做一做 → 看结果 → 再想一想”的循环。对于我们的分诊场景，Agent 先推理”患者描述了头晕和耳鸣，我需要更多信息来判断”，然后行动”调用知识库检索”，接着观察检索结果，再推理”结果显示可能是美尼尔氏综合征或高血压，我需要追问血压情况”，如此循环直到收集够信息、给出最终建议。

有了 LangChain，我们用十行左右的代码就能跑通一个基础版本的分诊 Agent。它能理解患者的描述，能调用知识库检索，能按照 ReAct 模式进行多步推理，最终输出一份分诊建议。

但这个”能跑”和”能用”之间，还有巨大的鸿沟。

第二阶段：编流程——让 Agent 应对真实世界的复杂性

LangGraph 登场

基础版的分诊 Agent 跑通之后，你很快就会发现它的局限。

真实的医疗问诊不是”患者说一句、Agent 查一下、回一个建议”这么线性的过程。真实世界里充满了分支、循环和例外情况：

患者描述模糊怎么办？Agent 需要发起追问，而且是有策略的追问——不能像审讯一样一口气问十个问题，要根据已有信息判断最需要补充哪个维度。如果追问三轮患者还是说不清楚，Agent 需要能识别出”信息不足以做判断”，并建议直接线下就诊而不是硬给一个不靠谱的结论。

紧急症状出现怎么办？如果患者在对话中提到”胸口剧烈疼痛””突然说不出话””一侧肢体无力”这类可能提示急性心梗或脑卒中的症状，Agent 不能按照常规流程慢慢走完所有步骤。它需要立即跳出正常流程，进入紧急通道——停止一切非必要的追问，直接输出”请立即拨打120或前往最近的急诊”。

涉及用药建议怎么办？在中国的医疗监管框架下，AI 直接给出具体的用药建议存在合规风险。所以在 Agent 生成涉及药物的内容时，这条输出不能直接发给患者，必须先经过一个人工医生的审批环节——医生确认内容没有问题后，才能放行。

涉及未成年人怎么办？如果患者是儿童，分诊逻辑可能完全不同——同样是发烧38.5度，成人可以建议居家观察，但三岁以下的婴幼儿可能需要立即就诊。

这些”如果……那么……否则……”的条件分支，加上”不够就回去再问一轮”的循环逻辑，再加上”到了这一步必须有人类介入”的审批节点——用 LangChain 的基础 Agent 是处理不了的。LangChain 的 ReAct 模式本质上是一个线性的推理循环，它没有显式的状态管理，也没有内置的流程分支机制。

这就是 LangGraph 登场的时刻。

LangGraph 的核心思想是：把 Agent 的工作流程用“图”来表达。这里的”图”不是图片的图，而是数学和计算机科学中的概念——由节点和边组成的网络结构。每个节点代表一个具体的动作——可以是调用大语言模型做推理，可以是调用外部工具查数据，也可以是一个纯逻辑判断。每条边代表一个流转规则——从这个节点做完之后，下一步该去哪里。

对我们的分诊 Agent 来说，用 LangGraph 建模出来的流程大致是这样的：

入口是一个”症状采集”节点。患者每说一句话，这个节点负责理解内容、提取症状信息、更新当前已知的症状列表。

接下来是一个”信息充分度判断”节点。它检查当前已经采集到的症状信息是否足够做出分诊判断。如果不够——这是一条条件边——流程回到”症状采集”节点，Agent 会针对性地追问缺失的信息。如果够了，流程继续往下走。这就形成了一个循环：采集 → 判断 → 不够 → 再采集 → 再判断。这种循环在线性的 Agent 架构里很难实现，但在图结构里只是一条回指的边而已。

然后是一个”紧急度评估”节点。它根据已采集的症状信息判断紧急程度。这是一个条件分支：如果判定为紧急，流程直接跳到”紧急通道”节点，输出急救建议，跳过后续所有步骤；如果判定为非紧急，流程正常继续。

再然后是”科室匹配”节点和”建议生成”节点。科室匹配负责根据症状匹配最合适的科室，建议生成负责综合所有信息输出一份结构化的就医建议。

最后是一个关键的”人工审批”节点。如果 Agent 的建议中涉及了药物信息，流程会在这里暂停——不是技术上的暂停，而是设计上的暂停。Agent 的状态被保存下来，一个通知发给值班医生，医生在自己的工作台上查看 Agent 生成的内容，确认没问题后点击”通过”，流程才继续往下走，把建议发给患者。如果医生觉得有问题，可以修改内容后再放行，或者直接打回让 Agent 重新生成。

这就是 LangGraph 最核心的价值所在。当你面对的业务流程中存在条件分支、循环、人工介入、异常处理这些复杂性时，图结构是最自然的建模方式。每个节点做什么、什么条件走哪条边，都是显式定义的，没有任何隐藏的魔法。

除了流程编排本身，LangGraph 还带来了几个对医疗场景至关重要的底层能力。

• 持久化执行。 Agent 在处理一个患者的问诊时，可能需要经历多轮对话，中间还可能因为等待人工审批而暂停数小时。如果在这个过程中系统发生了重启或崩溃，患者之前描述的所有症状信息不能丢失。LangGraph 的检查点机制会在每个节点执行完毕后自动保存当前状态，系统恢复后可以从断点继续，不需要患者从头描述。这对于医疗场景来说不是锦上添花，而是基本要求——你不能让一个正在等待急诊建议的患者因为系统重启而重新走一遍分诊流程。
• 状态回溯。 假设一个 case 出了问题——Agent 给出了一个明显不合理的分诊建议。在 LangGraph 的架构下，你可以完整回溯这个 case 的状态变化：第一轮对话后状态是什么，知识库检索返回了什么结果，紧急度评估是怎么判的，科室匹配是基于什么信息做的。每一步的输入输出和状态变化都有据可查。这在传统的”黑箱”Agent 中几乎不可能做到。
• 记忆管理。 LangGraph 原生支持两种记忆：短期记忆保存当前这次对话的上下文——患者说过什么、Agent 追问了什么、已经提取了哪些症状；长期记忆可以跨对话保存——比如这个患者上个月做过一次分诊，当时的记录可以作为参考。对于需要连续跟踪的慢性病患者场景，长期记忆是一个非常有价值的能力。

到这一步，我们的分诊 Agent 已经有了完整的业务逻辑：能采集、能判断、能分流、能循环追问、能在关键节点拉人介入、能记住每个患者的上下文。从功能上说，它已经是一个可以工作的系统了。

但”能工作”和”值得信任”之间，还有最后一道关卡。

第三阶段：验质量——用数据证明 Agent 靠谱

LangSmith 登场

医疗场景对质量的要求是极端严格的。你不能对着老板说”我觉得这个 Agent 还不错”——你需要拿出数据来证明它到底有多靠谱，哪些场景它处理得好，哪些场景它还不行，不行的原因具体是什么。

这就是 LangSmith 要解决的问题。如果说 LangChain 负责”造”，LangGraph 负责”编”，那 LangSmith 负责的就是”验”和”管”。

Trace：看清 Agent 每一步在干什么

LangSmith 最基础也最强大的能力是 Trace——全链路追踪。

接入方式极其简单，只需要设置一个环境变量。设置完之后，Agent 每一次执行都会被完整记录：每个节点的输入是什么，输出是什么，用了多长时间，消耗了多少 token，中间调用了哪些工具，工具返回了什么结果。所有这些信息都会以可视化的瀑布图形式展示在 LangSmith 的 dashboard 上。

这对 PM 来说意味着什么？

意味着你再也不需要猜 Agent 为什么给出了一个奇怪的回答。你可以打开那条 trace，像看监控录像一样回放整个过程：患者说了”我胃疼了三天，吃不下饭”，Agent 提取了”胃痛””三天””食欲下降”三个症状，然后调用了知识库检索，检索返回了五条结果，Agent 选择了其中两条作为参考依据，最终生成了”建议消化内科就诊”的建议。

如果这个建议是错的，你可以精确定位问题出在哪一步。是症状提取有误？是知识库检索的召回结果不相关？是模型在综合推理时出了偏差？还是最终的建议生成模板有问题？每一步都看得清清楚楚。

这种透明度在医疗场景中尤其重要。当一个分诊 case 出了问题被患者投诉时，你需要能够完整还原 Agent 的决策链路，向医务部门解释”Agent 是基于什么信息、经过什么推理过程、得出了这个结论”。如果没有 trace，你面对的就是一个黑箱——患者输入了什么你知道，Agent 输出了什么你也知道，但中间发生了什么你一无所知。

Eval：批量测试 Agent 的质量

Trace 解决的是”单个 case 发生了什么”的问题。但作为产品负责人，你还需要回答一个更宏观的问题：这个 Agent 整体的质量水平如何？

LangSmith 的 Eval 功能就是用来做这件事的。你可以准备一个测试数据集——比如一百个真实的患者问诊案例，每个案例都有标注好的”正确答案”——然后让 Agent 跑一遍这些 case，Eval 会自动对比 Agent 的输出和标准答案，按照你预设的评分维度打分。

对分诊 Agent 来说，你可能会设计这样几个评估维度：

• 分诊准确率——Agent 推荐的科室是否与标准答案一致。这是最核心的指标。
• 紧急识别率——对于标注为紧急的 case，Agent 是否正确触发了紧急通道。这个指标的要求是极高的，漏判一个急性心梗可能就是人命关天的事。
• 追问合理性——Agent 的追问是否有针对性，有没有问了一堆无关的问题浪费患者时间。
• 建议可读性——输出的就医建议是否结构清晰、表述准确、不包含可能引起误解的内容。

Eval 跑完之后，你会得到一份量化的质量报告：总体准确率 87%、紧急识别率 95%、在”头晕”相关的 case 中准确率明显偏低只有 72%、在”儿科”相关 case 中追问轮次过多平均要追问 5 轮。这些数字直接告诉你下一步应该优化什么。

更重要的是 Eval 支持版本对比。当你的工程师做了一次优化——比如更新了知识库的内容，或者调整了 Agent 的 prompt，或者换了一个更新的模型——你可以用同一份测试集重新跑一遍 Eval，对比优化前后的分数变化。这让每一次迭代都是有据可依的，而不是”感觉好像好了一点”。

Studio：交互式调试

LangSmith 还提供了一个叫 Studio 的可视化环境，让你可以直接和 Agent 进行交互式调试。你可以在 Studio 里模拟一个患者的输入，实时观察 Agent 的推理过程，在任意一个节点暂停、检查当前状态、甚至修改中间结果然后继续执行，看看不同的中间状态会导致什么不同的最终输出。

这对于调试那些”偶尔出错”的边缘 case 特别有用。你可以把出错的那条 trace 在 Studio 里重放，走到出问题的那个节点，修改输入看看是不是某个特定的措辞触发了错误推理，或者替换知识库的检索结果看看是不是检索质量的问题。这种交互式的调试方式，比看日志猜问题要高效得多。

接入成本

值得一提的是 LangSmith 的接入门槛极低。如果你的 Agent 是用 LangChain 和 LangGraph 搭建的，接入 LangSmith 只需要做一件事：设置一个环境变量，告诉系统”把 trace 数据发送到 LangSmith 平台”。不需要改动任何业务代码，不需要在代码里手动埋点。这是因为 LangChain 和 LangGraph 在设计时就预留了与 LangSmith 的集成接口——它们是一个生态中的三个组件，天然就能无缝协作。

第四阶段：上生产——三者如何形成闭环

Agent 通过了质量验证，现在要正式上线服务真实的患者了。上线不是终点，而是另一个循环的起点。

LangSmith 在生产环境中扮演的角色从”调试工具”转变为”监控中枢”。它会持续追踪线上的每一次问诊请求：平均响应时间是多少、每天有多少 case 触发了紧急通道、人工审批的通过率和打回率分别是多少、用户在对话中途放弃的比例有多高。这些指标构成了一个实时的健康度仪表盘。

当监控发现异常——比如某天下午紧急通道的触发率突然翻倍——你可以钻取到具体的 trace，发现是因为知识库更新后某个症状的紧急度标注被误改了。定位到问题后，修复发生在 LangChain 层面——更正知识库的数据，或者调整 Tool 的检索策略。

如果发现 Agent 在处理某类复杂 case 时经常陷入无限追问的循环，问题可能出在 LangGraph 层面——需要在”信息充分度判断”节点加一个最大追问轮次的限制，或者增加一条”超过三轮未收集到足够信息就建议线下就诊”的退出边。

修复完成后，重新用 LangSmith 的 Eval 跑一遍测试集，确认改动解决了问题且没有引入新的回归，然后发布新版本。

这就是三者的闭环协作：LangSmith 发现问题 → 定位到 LangGraph 的流程编排或 LangChain 的基础能力 → 修复后用 LangSmith 验证 → 重新部署。这个循环会在 Agent 的整个生命周期中不断重复，每一轮循环都让 Agent 变得更可靠一点。

三者关系的另一种理解方式

讲完了完整的故事，让我们跳出来再看一次全景。

如果把 Agent 开发比作建造一栋医院大楼，LangChain 提供的是建筑材料——钢筋、水泥、玻璃、管道。你需要什么材料它都有，而且规格标准统一，不同厂商的材料可以互换。它解决的是”有没有”的问题。

LangGraph 是建筑的结构设计和施工——它决定了楼层怎么划分，走廊怎么连接，紧急通道设在哪里，电梯和楼梯的流线怎么安排。它解决的是”怎么组织”的问题。同样的建筑材料，不同的结构设计会得到功能完全不同的建筑。

LangSmith 是建筑的验收和物业管理——消防检查通不通过，电路负载测试达不达标，日常运营中哪里的灯坏了、哪个门禁出了故障，都由它来监测和报告。它解决的是”好不好”和”稳不稳”的问题。

三者之间有一个重要的技术依赖关系：LangChain 的 Agent 底层实际上运行在 LangGraph 之上。这不是可选的——当你用 LangChain 的 create_agent 创建一个 Agent 时，它在底层自动使用 LangGraph 来获得持久化执行、流式输出、human-in-the-loop 这些能力。对于简单场景，你完全不需要知道 LangGraph 的存在，LangChain 帮你封装好了一切。只有当你需要自定义复杂的流程逻辑时，你才需要直接操作 LangGraph 的 API。

LangSmith 则是独立于前两者的——它可以监控任何框架构建的 Agent，不限于 LangChain 和 LangGraph。但当三者一起使用时，集成体验是最丝滑的，一个环境变量就能打通全链路。

从 PM 的视角回看：你需要建立什么认知

读完这个故事，你可能会问：作为一个 AI 产品经理，我又不写代码，知道这些有什么用？

用处比你想象的大。

第一，你需要能定义 Agent 需要什么能力

这对应 LangChain 的思维方式。当你在写 PRD 时，你需要明确列出 Agent 需要连接哪些外部工具和数据源——知识库、数据库、第三方 API、内部系统。你需要知道”Tool Calling”的概念，理解 Agent 不是什么都自己生成，很多时候它需要调用外部工具来获取真实信息。你还需要判断不同的基础模型在你的场景下哪个更合适——这不是一个纯技术决策，它涉及成本、延迟、准确率的权衡，PM 需要参与。

第二，你需要能画出业务流程的状态图

这对应 LangGraph 的思维方式。在和工程团队沟通 Agent 方案时，如果你能画出一张流程图——哪些是节点，哪些地方需要条件分支，哪里需要循环，哪里需要人工介入——沟通效率会高一个数量级。你不需要知道代码怎么写，但你需要能把业务流程翻译成”节点 + 边”的语言。这本质上就是产品经理一直在做的事——画流程图、定义状态机——只不过现在你画的流程图可以直接映射到 Agent 的技术实现。

第三，你需要能设计评估体系

这对应 LangSmith 的思维方式。Agent 的质量不像传统软件可以用”功能是否正常”来二元判断，它的输出是概率性的——同样的输入，不同时刻可能给出不同的回答。你需要设计合理的评估维度和测试用例：什么算”好”的分诊建议？怎么衡量追问是否合理？紧急识别的召回率底线是多少？这些指标的定义是 PM 的职责，工程师负责实现评估的自动化。

三个思维方式，一个底层逻辑

这三种思维方式其实指向同一个底层能力：把一个模糊的 AI 产品需求，翻译成可拆解、可实现、可度量的技术方案。LangChain 帮你拆解”Agent 需要什么器官”，LangGraph 帮你拆解”Agent 的工作流程是什么”，LangSmith 帮你回答”Agent 做得好不好”。

掌握了这三层认知，你就拥有了和工程团队对齐 Agent 方案的共同语言。你不需要自己写代码，但你需要能听懂工程师说”这个节点的状态需要持久化””这条边的条件判断逻辑要改””这个 case 的 trace 显示问题出在检索环节”——然后做出正确的产品决策。

结尾：回到起点

我们从一个医疗问诊 Agent 的需求出发，走过了搭骨架、编流程、验质量、上生产四个阶段。在这个过程中，LangChain、LangGraph、LangSmith 分别在各自的阶段自然登场、各司其职：

• LangChain 让 Agent 有了基础能力——连接模型、调用工具、完成推理循环。
• LangGraph 让 Agent 有了处理复杂场景的能力——条件分支、循环追问、人工介入、状态持久化。
• LangSmith 让 Agent 有了被信任的资格——全链路追踪、批量质量评估、生产监控、持续迭代。

这三者不是三个独立的产品，而是一个完整生态的三个层次。就像你不会问”发动机和方向盘和仪表盘哪个更重要”一样——它们各自负责不同的维度，缺少任何一个，这辆车都上不了路。

对于 AI 产品经理而言，理解这个生态最大的价值，不在于你要去用这些工具写代码，而在于它给了你一套思考 Agent 产品的框架：先想清楚 Agent 需要什么能力，再想清楚它的工作流程怎么设计，最后想清楚怎么衡量它做得好不好。这三个问题想清楚了，无论底层用的是 LangChain 还是其他框架，你的产品方案都会更扎实、更有说服力。