想象一下，当你面对一篇长达数万字的医学报告、一份充满专业术语的法律文档，或是一部世界文学名著，你需要从中提取关键信息、分析核心观点、总结主要内容——这在过去可能需要花费数小时甚至数天的时间。但现在，谷歌的最新开源项目LangExtract，将彻底改变这一切。

作为谷歌在文本处理领域的最新成果，LangExtract利用大型语言模型的强大能力，让你能够在几分钟内从任何非结构化文本中提取结构化信息。无论是临床笔记、法律合同、学术论文还是社交媒体内容，LangExtract都能精准捕捉到你需要的每一个细节。

在 Java 统治企业级开发的 20 年里，我们习惯了确定性的逻辑。然而，AI 浪潮让 Python 凭借灵活性抢占了先机。

Spring 创始人 Rod Johnson 在介绍 Embabel 时曾明确表示：这是他自 Spring 之后，最希望投入精力推动的一个方向性项目——目标不是简单追赶 Python，而是为 JVM 生态构建真正可落地的 Agent 能力。

Embabel 并非简单的 LLM 封装，它是类似于 Spring MVC 级别的高级 Agent 框架，旨在为 JVM 生态带来真正的 AI 生产力。

背景与动机：为什么需要状态化对话流

在构建对话式 AI 应用时，一个常见的误区是将每次用户输入视为独立事件，依赖无状态的 LLM 调用直接生成回复。这种模式看似简单，但在真实场景中很快会暴露出根本性问题：上下文断裂。

想象用户发起多轮对话：“明天烟台天气怎么样？”、“那北京呢？”、“记得我之前问的城市吗？”。如果系统每次只看到当前问题而看不到历史消息，就无法正确理解“之前问的城市”指代什么。更严重的是，当涉及工具调用（如查询天气）、条件分支或人工干预时，缺乏统一的状态管理会导致流程失控——比如重复执行、跳过关键步骤。

这就是为什么我们需要状态化对话流。LangGraph 的出现正是为了解决这一类复杂交互的编排问题。它基于有向无环图（DAG）模型，将对话建模为一系列节点与边的流转过程，每个节点代表一个动作（如调用模型、执行工具），每条边决定下一步走向。更重要的是，整个流程围绕一个共享的 state 对象进行演化，确保所有参与者都能看到一致的上下文。

尤为关键的是，LangGraph 支持通过 checkpointer 机制持久化对话状态。这意味着你可以随时暂停会话、保存快照，并在未来任意时刻恢复到断点继续执行。这不仅支持 Web 应用中的长期对话保持，还极大提升了调试能力——开发者可以回放某次失败的交互路径，逐节点检查状态变化，就像调试传统程序一样精准。

简言之，从无状态调用迈向基于 LangGraph 的状态机架构，是从“问答机器人”进化到“可信赖代理”的必经之路。接下来我们将深入其核心抽象，看看它是如何实现这一切的。

在 LangChain 的生态中，当我们需要让大模型完成查天气、查数据库、调用外部接口这类任务时，核心逻辑其实高度统一：让模型决策 “是否使用工具、使用哪款工具、传入什么参数”，但绝不是模型直接执行工具操作。

围绕这一核心，LangChain 提供了两种实现路径 —— 一种是新手易上手的Agent，另一种是更适配生产环境的Tool Calling。二者看似效果相近、底层原理同源，但在工程可控性、可扩展性与生产可用性上，存在天壤之别。

简单来说，initialize_agent是帮你封装好全流程的高层工具，而bind_tools + 手动调度则是将执行权完全交还给开发者的底层实现。在实际生产落地中，后者往往是更优的选择。

LangChain 的多轮对话，本质不是“模型记住了历史”，而是 Runnable 在每次调用前，把历史消息重新拼进 Prompt，再把新结果写回存储。

这一篇将基于一个完整的多轮对话流程，从零梳理：

• 多轮对话在 LangChain 中是如何工作的
• RunnableWithMessageHistory 到底做了什么
• 使用 PostgreSQL或其他数据库进行持久化存储
• 多用户 / 多会话是如何隔离的