本章涵盖以下内容：
- 构建由大语言模型驱动的应用时所面临的核心挑战
- LangChain 的模块化架构与组件
- 引擎、聊天机器人与智能体的模式
- 提示工程与检索增强生成（RAG）的基础
像 GPT、Gemini 和 Claude 这样的大语言模型（LLM），已经从“新奇事物”变成了“基础能力”。LLM 使应用能够回答复杂问题、生成定制化内容、总结长文档，并在多个系统之间协调执行动作。最近，LLM 又解锁出一类全新的应用：AI 智能体。智能体能够接收自然语言输入，自主决定调用哪些工具或服务，编排多步骤工作流，并以清晰、对人友好的格式返回结果。
AI 应用与智能体系统可能相当复杂。它们需要摄取和管理数据、组织提示、可靠地串联模型调用，并集成外部 API 与服务。幸运的是，LangChain、LangGraph 和 LangSmith 等框架提供了模块化的构建积木，能够消除大量样板代码、推广最佳实践，并让你把精力放在应用逻辑上，而不是底层连线与胶水代码上。本书中，你将学习如何使用当前最优秀的工具和框架，设计、构建并扩展真实的、基于 LLM 的应用与智能体。
1.1 构建基于 LLM 的应用与智能体
LLM 非常擅长处理自然语言——它们能够理解文本、生成文本，并在需要时从中提取信息。这使它们适用于各种类型的应用：摘要、翻译、情感分析、语义搜索、聊天机器人以及代码生成。也正因如此，如今你会看到 LLM 出现在教育、医疗、法律和金融等差异极大的领域中。
尽管应用场景各不相同，大多数 LLM 应用在底层看起来却非常相似。它们接收自然语言输入，处理非结构化数据，从一个或多个来源拉取额外上下文，然后把这些内容打包进一个提示中交给模型处理。从高层来看，这类系统通常可以分为三大类别：
基于 LLM 的应用或引擎（engines） ，是提供某种特定、边界明确能力的系统（例如摘要、搜索或内容生成）。引擎通常被调用来产出结果，任务完成后即停止；它不会自主决定接下来做什么，也不会在当前请求之外继续推进工作。
聊天机器人（chatbots） ，是能在多轮交互中维持上下文的对话式界面。它们主要聚焦于对话与交互式问答，而不是独立采取行动。
AI 智能体（AI agents） ，是利用 LLM 来选择动作、制定计划并执行多步骤任务以达成目标的自治或半自治系统。与引擎不同，智能体可以循环运行（观察 → 决策 → 行动 → 再观察），协调多个工具/API，并根据中间结果、错误或新信息动态调整下一步。
在探讨 LangChain 如何支持这些系统的开发之前，我们会依次考察上述三类系统。先从基于 LLM 的应用和引擎开始。
1.1.1 基于 LLM 的应用：摘要引擎与问答引擎
基于 LLM 的应用，通常作为后端工具，为其他系统处理特定的自然语言请求。比如，一个摘要引擎会把冗长的文本段落压缩为简洁的摘要。这些摘要既可以立即返回给客户端，也可以存入数据库，供其他应用后续使用，如图 1.1 所示。
图 1.1 摘要引擎能够高效地对海量文本内容进行总结与存储，并可通过 REST API 被其他系统调用。
摘要引擎通常以共享服务的形式部署，通常通过 REST API 对外暴露，以便多个系统按需调用。另一种常见类型是问答（Q&A）引擎，它针对知识库回答用户问题。Q&A 引擎通常分为两个阶段：摄取（ingestion） 和 查询（query） 。
在内容摄取阶段，引擎通过拉取文本、将其切分为块（chunks），并把这些块转换为嵌入（embeddings）来构建知识库。所谓嵌入，就是能够表达语义的数学向量。嵌入和原始文本块都会被存储到向量存储（vector store）中，以便后续高效检索。如果你现在对嵌入模型或向量存储还不熟悉，也不必担心；后文会详细介绍。此刻，你只需要把这个步骤理解为：把原始文本转换成一种可搜索的表示形式。
定义 嵌入（Embeddings）是词、token 或更大文本单元——如句子、段落或文档块——在连续高维空间中的向量表示（通常有数百到数千维）。这些向量能够捕捉语义和句法关系，使语言模型能够理解意义、上下文与相似性。嵌入通常在预训练阶段习得：模型在大规模文本语料上训练，根据周围上下文预测 token。通过同时编码单词层面的信息与更广义的语义含义，嵌入使模型能够进行更有效的推理、检索和语言理解。
在查询阶段，引擎会接收用户问题，使用同一个嵌入模型将问题转换为嵌入，然后在向量存储上执行语义搜索。系统会检索出最相关的文本块，将它们与原始问题组合成一个提示，再发送给 LLM。接着，模型基于问题和检索到的上下文生成回答，目标是让答案既准确，又有来源依据——当然，最终结果的质量仍取决于检索相关性、分块策略以及模型自身的行为等因素。
这一工作流被称为检索增强生成（Retrieval-Augmented Generation，RAG） ，如图 1.2 所示。RAG 已迅速成为现代 LLM 应用的基石之一。它是让 LLM 输出更加有用、更加及时、并且扎根于外部相关信息的一项基础技术。
定义 检索增强生成（RAG）是一种设计模式：在查询时，从本地知识库（通常存储在向量存储中）检索额外上下文，并将其并入 LLM 的文本生成过程之中，从而增强生成结果。
图 1.2 使用 RAG 设计实现的问答引擎。一个 LLM 查询引擎将领域特定的文档信息存储在向量存储中。当外部系统发来查询时，它会先把自然语言问题转换成嵌入（或向量）表示，从向量存储中检索相关文档，再把这些信息提供给 LLM，使其能够生成自然语言回答。
引擎并不局限于问答。它们还可以通过执行预定义的步骤序列来调用外部工具，这类步骤序列通常被称为链（chains） 。例如，一个处理用户请求的引擎，可能会把自然语言指令转换为 API 调用，从外部系统拉取数据，然后再使用 LLM 对结果进行解释和整理，并以清晰、适合人阅读的格式呈现出来。
从本质上说，这类引擎是为系统层面的工作而设计的：自动化流程、智能化处理数据、以及把不同平台串联起来。它们通过接管自然语言相关流程中那些“脏活累活”——检索、转换、编排——来简化工作流，让你无需亲自处理这些复杂细节。
后文我们会看到，AI 智能体建立在这些能力之上，但二者在“决策权”落在哪里这一点上存在关键差异。引擎通常执行的是一条预定义的链：步骤与分支逻辑大多提前设计好，系统针对某个请求把这条工作流跑完。相比之下，智能体会利用 LLM 在运行时进行规划并动态调整方法——决定调用哪些工具、根据中间结果修订计划，并可能循环执行多轮动作，直到达到停止条件。简单来说：引擎是在运行工作流，而智能体是在管理工作流。它牺牲了一部分可预测性，换来了在开放式、多步骤任务上的更大灵活性。
一旦系统变成由真人实时直接交互，局面就不同了。此时，引擎开始承担对话角色，从纯自动化转向交互式对话。这也正是聊天机器人登场的地方。
1.1.2 基于 LLM 的聊天机器人
基于 LLM 的聊天机器人，作为一种智能助手，使用户能够与语言模型进行持续、自然的对话。与简单的问答脚本不同，这类系统的目标是让交互既有用又安全。它们高度依赖提示设计：清晰的指令能够塑造模型行为，并帮助避免无关、不准确或不安全的回复。现代聊天 API——例如 OpenAI 提供的 API——支持基于角色的消息格式（system、user、assistant），这使你可以定义助手的人设，并在整段对话中保持一致的行为。
为了提升准确性，聊天机器人常常会从本地知识源（如向量存储）中拉取事实性上下文。这样一来，它们既能保持对话流畅，又能获得领域特定的事实支撑，使回答不仅自然，而且相关、可靠。
聊天机器人的一个关键优势是对话记忆。通过跟踪前面的对话轮次，它们能够让回复保持连贯并具备个性化特征。这种记忆会受到模型上下文窗口大小的限制。更大的上下文窗口当然有帮助，但很多系统仍会压缩或总结对话历史，以控制在上下文限制之内——同时也为了管理成本。
基于 LLM 的聊天机器人通常专注于某类任务，例如摘要、问答或翻译。它们既可以直接响应用户输入，也可以把用户输入与已存储知识结合起来处理。比如，一个摘要聊天机器人的架构（见图 1.3）就是在基础摘要引擎之上，增加了对话管理与上下文感知层。
图 1.3 摘要聊天机器人与摘要引擎有一些相似之处，但它提供的是一种交互式体验，让 LLM 和用户能够协同细化与改进结果。
摘要引擎与摘要聊天机器人之间最关键的差异，在于交互性。聊天机器人让你可以实时调整结果：比如你想要更短一点，或者口语化一点的摘要，直接提出要求即可，如图 1.4 的时序图所示。
图 1.4 时序图展示了用户如何通过聊天机器人与 LLM 交互，以生成更精炼的摘要
这种来回交互使整个过程变成一种协作过程——从而产出更贴合需求、也更能感知上下文的答案。在下一章中，我们将探讨角色指令、少样本示例以及更高级的提示工程技巧，以帮助你更精确地控制聊天机器人的行为和输出。
1.1.3 AI 智能体
AI 智能体是一种与 LLM 协同工作的系统，用于执行多步骤任务——这些任务通常涉及多个数据源、分支逻辑以及自适应决策。与简单流水线不同，智能体可以在一定程度上独立运作：它遵守你设定的约束，但会自行决定下一步该做什么。
在每一步中，智能体都会借助 LLM 来决定要使用哪些工具，执行这些工具，并在继续前处理结果。这个循环会持续进行，直到智能体生成一个完整的解决方案。在实际应用中，这可能意味着同时从结构化来源（如数据库或 API）和非结构化来源（如文档或网页）中拉取信息，将结果整合起来，并以连贯的格式呈现出来。
来看一个例子：一家旅游运营商使用 AI 智能体，根据预订网站上的自然语言请求生成度假套餐。正如图 1.5 所示，这个过程可能如下：
- 智能体向 LLM 发送一个提示，要求其为该请求选择最相关的工具，例如航班、酒店和租车服务提供商，天气预报服务，以及内部度假优惠数据库。
- 在开发者编写的提示引导下，提示中列出了可用工具及其说明，LLM 会选择合适的工具，并生成所需查询，例如面向度假优惠数据库的 SQL，或对外部服务提供商的 REST API 调用。
- 智能体执行这些查询，收集结果，然后向 LLM 发送另一个提示，其中同时包含原始度假请求和收集到的数据。
- LLM 返回一个汇总后的度假方案，其中包含全部预订信息，随后由智能体将该方案返回给预订网站。
图 1.5 一个负责组装度假套餐的 AI 智能体工作流
在生成最终输出（例如完整度假计划）之前，这一工作流可能需要智能体与 LLM 之间进行多轮迭代。此外，图 1.5 展示的架构也只是众多可能方案中的一种。另一种设计可以基于一组更细粒度的智能体，并由顶部的一个监督者智能体（Supervisor agent）进行协调。
在金融或医疗这类高风险领域中，通常会加入人在回路中（human-in-the-loop） 的步骤。这可以确保在执行关键动作之前——比如批准一笔金融交易，或确认一项复杂的医疗建议——由人工进行审核与确认。在度假规划这个例子中，智能体也可以被设计为在把行程发送给客户之前先暂停，并请求人工批准拟定的行程，从而额外增加一层监督与信任保障。
近来，AI 智能体引发了广泛关注。OpenAI、Google 和 Amazon 等大型公司，以及 LangChain、LlamaIndex 和 Pydantic 等独立开发者，都发布了智能体 SDK，以推动这一范式的广泛采用。
在本书中，我们将聚焦于 LangGraph——LangChain 专门面向智能体的框架。LangGraph 提供了预构建的智能体和编排器类，以及开箱即用的工具集成，因此你无需重复造轮子。你还将通过动手实践，学习如何使用 LangGraph 构建高级智能体，掌握其设计、编排与迭代优化的方法。
从很多方面看，AI 智能体代表了基于 LLM 应用的最先进形态。它充分利用了 LLM 在文本理解、生成和推理方面的全部能力，以支撑复杂的自动化工作流。智能体能够在你设计的提示引导下，动态选择并使用多种工具，因此在金融、医疗、物流等领域极具价值——这些领域往往都离不开多步骤推理与数据整合。
随着 Anthropic 推出 Model Context Protocol（MCP） ，人们对智能体的兴趣又进一步升温。MCP 定义了一种标准，使服务能够通过 MCP 服务器暴露工具，而智能体则可以通过 MCP 客户端像访问本地组件一样访问这些工具。这将集成负担转移到了服务本身，使开发者能够把精力集中在构建更强大的智能体上，而不是维护定制连接器。自 2024 年底发布以来，MCP 迅速成为事实上的标准——被 OpenAI、Google 等主要 LLM 提供商采用，如今已有数千种工具可通过公共 MCP 门户访问。在本书中，你将学习这一协议的工作原理，考察其生态系统的实际情况，并亲手构建一个可直接与智能体应用集成的 MCP 服务器。
1.2 LangChain 简介
设想一下，你被要求构建一个聊天机器人，让它能根据公司文档回答客户问题；或者构建一个搜索引擎，从数千份内部报告中精确检索答案。你很快就会碰到一系列相同的痛点：
- 如何把你自己的数据可靠地送入模型，而不是把整份文档一股脑塞进提示里？
- 随着功能增长，如何让提示、链和各种集成依然保持可维护性？
- 如何在上下文限制和成本约束下，仍尽量保证准确性？
- 如何在不依赖脆弱胶水代码的前提下，编排多步骤工作流与 API 调用？
- 当应用上线后，又该如何评估、调试并监控其行为？
如果没有框架，开发者往往会一遍又一遍地重复实现同样的底层管道：加载数据、切分数据、生成嵌入、存储、检索、组装提示。这种反复造轮子的过程，正是让“如何可靠地把私有数据引入模型、而不把提示塞爆”，以及“如何避免提示、链和集成随着功能增长而演变成不可维护的一团乱麻”变得困难的根源。与此同时，你还希望在上下文限制、成本和回答质量之间做平衡。
LangChain 正是为了解决这些问题而设计的。它提供了一套一致的构建模块：用加载器导入数据、用分割器进行切块、用嵌入加向量存储建立索引、用检索器在查询时只拉取最相关的上下文——这样你就不必把整篇文档直接粘进提示中。提示模板和结构化链组合则帮助你在功能扩张时规范化并复用提示与集成逻辑，而不是在代码库中到处复制粘贴。至于多步骤工作流，LCEL 和 Runnable 接口为你提供了一种统一方式，用来编排工具调用与处理步骤，并在应用上线后以更清晰的结构支持追踪、调试和评估。
LangChain 也在快速演进，这很大程度上得益于一个活跃的开源社区。它持续跟上 LLM 架构、新数据源和检索技术的发展，同时也在帮助行业建立构建和部署基于 LLM 系统的共同最佳实践。
LangChain 的设计遵循三大原则：模块化（modularity） 、可组合性（composability） 和 可扩展性（extensibility） 。各个组件遵循标准接口，因此你可以替换 LLM、更换向量存储，或新增一个数据连接器，而无需重写整个应用。现实世界中的任务可以由多个组件组合而成，形成链或智能体工作流，并动态选择最适合当前任务的工具。与此同时，虽然框架提供了默认实现，但你始终可以对其进行扩展或替换为自定义逻辑或第三方集成，从而避免被锁定在某个技术栈上，并促进互操作性。
通过学习 LangChain，你不仅能获得构建生产级 LLM 应用的能力，还会掌握可迁移的技能。竞争框架通常也在以相似方式解决相似问题，因此一旦你理解了这些模式，未来无论使用哪种技术栈，都能举一反三。
1.2.1 LangChain 架构
LangChain 的文档相当全面，但理解它最好的方式，还是亲手去构建。本节将给出一个高层次概览，后续章节中我们会反复回到这里。你可以把它当作一张地图，帮助你在后面深入细节与代码示例时始终把握全局。
大多数 LLM 框架在整体模式上都比较相似，但各自定义的组件有所不同。在 LangChain 中，工作流大致如图 1.6 所示。你先从不同来源——文件、数据库或网站——拉取文本，并把它封装为 Document 对象。然后，这些文档通常会被切分成更小的块，以便更容易处理。接着，每个块都会经过嵌入模型，将文本转换为能够表达语义的向量。原始文本块及其嵌入都会被存储进向量存储中，从而可以基于相似度搜索快速检索出最相关的文本片段。
图 1.6 LangChain 架构。文档加载器导入数据，文本分割器将其切分为块；这些块由嵌入模型向量化后存入向量存储，再经检索器提供给 LLM。LLM 缓存用于检查过往请求并返回缓存响应，输出解析器则对 LLM 的最终响应进行格式化。
当 LLM 应用执行某项任务时——比如摘要或语义搜索——它会构建一个提示，将用户问题与额外上下文组合起来。这个上下文通常来自从向量存储中取出的文档块。有时，你也可能希望引入图数据库中的信息。尽管向量存储仍是大多数 RAG 工作流的骨干，但图数据库在那些需要表示和推理实体间关系的应用中正变得越来越常见。这一点对智能体尤为重要：与通常执行一次检索后即返回结果的引擎不同，智能体可能需要维持更持久的记忆，跟踪实体及其关系，并利用这些关系来规划后续动作（例如决定下一步调用哪个工具，或检索哪类信息）。LangChain 已经支持与 Neo4j 等主流方案集成，并允许你使用基于图的记忆或规划组件——这些能力在高级智能体架构中正越来越常见。
为了让这些组件更容易串联起来，LangChain 引入了 Runnable 接口和 LCEL。它们为你提供了一种干净、一致的方式来连接组件，而无需编写大堆胶水代码。本章稍后会进一步深入这两项内容。
还值得注意的是，LangChain 的工作流并不局限于简单流水线。你可以把组件组织成图，以处理更复杂、带分支的流程——这一能力在 LangGraph 模块中被正式化了。下一节中，我们会继续深入这些模式与架构变体，在那里，LLM 应用设计的更大图景会逐步清晰起来。
下面对各个组件做一个更详细的说明（对应图 1.6 中的编号）：
文档加载器（1） —— 从各种来源（文件、网页、SaaS 工具和数据库）提取内容，并将其转换为 LangChain 的 Document 对象。
文本分割器（2） —— 将大文本切分为更小的块/Document 对象，使其能够落入上下文限制内，并能被有效地嵌入、索引和检索。
Document —— LangChain 的核心内容容器，封装内容与元数据（如来源、页码、作者和时间戳），从摄取到检索全流程贯穿使用。
嵌入模型（3） —— 将文本转换为表示语义含义的向量，从而支持基于相似度的搜索与匹配。
向量存储（4） —— 专门存储嵌入（以及关联的 Document 对象）的数据库，并支持高效的语义检索，是 RAG 的关键基础设施。
知识图数据库 —— 存储实体与关系的图数据库。当你需要建模和查询概念之间的连接，而不仅仅是文本相似性时，这类数据库会很有用。
检索器（5） —— 查询一个或多个后端（如向量存储、SQL、图数据库），并为用户问题返回最相关 Document 的组件。
提示（6） —— 可复用的提示模板，用于将用户输入与检索到的上下文（可选地也包含示例）组合起来，形成最终发送给 LLM 的请求。
LLM 缓存（7） —— 一个可选层，用于复用以往响应，以降低重复或相似查询的延迟和成本。
LLM/聊天模型（8） —— 用于生成输出的 LLM 接口；LangChain 支持多个提供商，也支持用于测试的 mock/fake 模型。
输出解析器（9） —— 将模型响应转换成结构化格式（如 JSON），从而让下游处理更加可靠。
上述组件既可以组织成链（chain） ，也可以围绕**智能体（agent）**构建：
链（Chain） —— 这是 LangChain 处理中工作流的一种组合式安排，面向特定用例，由前述组件按照一定顺序构成。
智能体（Agent） —— 它负责管理动态工作流，是顺序链的一种扩展。智能体的处理流程更灵活，可以根据用户输入或组件输出进行适配。在动态工作流中，资源通常在大多数框架文档中被称作工具（tools）或插件（plugins），而所有工具的集合则称为工具包（toolkit）。
LangChain 的完整设计支持三种主要应用类型，稍后我们将详细考察：摘要与查询服务、聊天机器人以及智能体。虽然这个框架乍看之下可能显得复杂，但随着我们通过示例一步步构建各个部件，它的结构和核心概念会逐渐变得清晰。
1.2.2 LangChain 的核心对象模型
在对 LangChain 的高层架构有了较好的理解之后，我们现在可以转向它的核心对象模型，以更清晰地把握框架是如何运作的。理解这些关键对象及其相互关系，将显著提升你有效使用 LangChain 的能力。同样重要的是，这些类家族与大多数 LLM 应用中常见的构建积木高度对应——文档、切块、检索、提示和模型调用——因此，学习 LangChain 的对象模型，也是在建立一个关于 LLM 应用通常如何组装的实用心智模型。
这个对象模型由一系列类层次结构组织而成，起点是抽象基类，随后派生出多个具体实现。图 1.7 从可视化角度概览了围绕 Document 实体展开的主要类家族。它展示了加载器如何生成 Document 对象，分割器如何将它们拆分成更小片段，以及这些对象随后如何流向向量存储与检索器，供下游处理使用。
图 1.7 围绕 Document 核心实体的一组类的对象模型，包括文档加载器（创建 Document 对象）、分割器（创建 Document 对象列表）、向量存储（将 Document 对象存入向量存储）以及检索器（从向量存储及其他来源检索 Document 对象）
正如在 1.2.1 节关于 LangChain 架构中介绍的那样，主要类包括：
DocumentDocumentLoaderTextSplitterVectorStoreRetriever
LangChain 在这些组件上集成了种类繁多的第三方工具和服务，因此具备极大的灵活性。你可以在官方文档中找到完整的支持集成列表。此外，LangChain 还提供了 LangChain Hub，这是一个由社区驱动的仓库，用于发现和共享可复用组件，例如提示、链和工具。
许多这类组件——从加载器到 LLM——共享的一个关键架构特征，是 Runnable 接口。这个统一接口使得对象能够以一致方式组合和串联起来，从而支持高度模块化的工作流。在后续关于构建可组合、富表达力 LLM 流水线的章节中，我们会进一步深入这一特性，以及 LCEL。
在图 1.8 中，你可以看到与 LLM 相关的对象模型，其中包括 PromptTemplate 和 PromptValue。该图展示了这些类如何连接到 LLM 接口，并暴露出一个比前面介绍的类层次稍微更复杂的结构。
图 1.8 与 LLM 相关的类的对象模型，包括 PromptTemplate 和 PromptValue
到这里，你已经了解了 LangChain 的用途、架构，以及它支持的核心应用类型。接下来，我鼓励你使用附录 B 中介绍的 Jupyter Notebook 亲手体验 LangChain。这是一个快速且实用的方式，能帮助你在我们继续深入之前，对这个框架先建立直观感受。
注 由于你将构建基于 LLM 的 LangChain 应用和 LangGraph 智能体，本书中的大多数示例都会使用 OpenAI 模型，主要来自 GPT-5 系列。在运行它们之前，你需要创建一个 OpenAI 账户并绑定借记卡或信用卡（参见附录 A 的说明）。大多数示例使用成本最低的 GPT-5-nano 即可顺利运行，完成全书练习的总成本应低于 5 美元。当然，如果你愿意，也可以尝试更大的模型。
每一个 LangChain 应用的核心，都是 LLM 的能力。基于 LLM 的应用，本质上可以看作是围绕模型构建的专用封装或接口，针对特定用例进行定制。下面我们就来看看 LLM 特别擅长处理的几类主要应用场景。
1.3 典型的 LLM 用例
LLM 可应用于广泛任务，从文本分类到代码生成，再到逻辑推理。以下列出一些最常见的用例，并附带现实世界中的例子，便于进一步了解：
文本分类与情感分析 —— 例如对新闻文章进行分类，或基于情感分析推荐股票。举例来说，GoDaddy 使用 LLM 自动对支持工单进行分类，这一点可见文章 “LLM from the Trenches: 10 Lessons Learned Operationalizing Models at GoDaddy”。
自然语言理解与生成 —— LLM 可以识别文本中的主要主题，并按长度、语气或术语要求生成定制化摘要。Duolingo 利用 AI 加速课程创建，详见博客文章 “How Duolingo Uses AI to Create Lessons Faster”。
语义搜索 —— 这意味着基于问题的意图与上下文来查询知识库，而不是依赖简单关键词。Picnic 超市应用使用 LLM 改进菜谱搜索，见 Medium 上的文章 “Enhancing Search Retrieval with Large Language Models (LLMs)”。
自主推理与工作流执行 —— LLM 可以处理诸如规划完整度假套餐这类任务，通过理解请求并管理流程中的每一步来达成目标。
结构化数据抽取 —— 例如从非结构化文本中抽取结构化数据，如实体及其关系，常见于金融报告或新闻文章。
代码理解与生成 —— LLM 可以分析代码以发现问题、给出改进建议，或者根据用户指令生成新的代码组件——从简单函数和类，到整个应用程序都可以。这项能力支撑了 GitHub Copilot 和 Cline AI 等流行 IDE 插件，以及 Cursor、Windsurf 等新兴的 AI 编码助手，它们能够在你编程时实时给出代码建议和错误检测。此外，像 Anthropic 的 Claude Code 和 OpenAI 的 Codex 这样的命令行编码工具，还允许开发者通过终端与 AI 交互，在 CLI 环境中直接完成代码生成、重构和调试。
个性化教育与辅导 —— LLM 也越来越多地被用作交互式导师，提供个性化帮助和反馈。例如，Khan Academy 的 Khanmigo 就使用 LLM 来辅助学生进行互动式学习。
这些用例都默认 LLM 能够胜任用户请求。但在现实场景中，任务往往涉及模型初始训练之外的特定领域或特定情境。在这种情况下，如何确保你的 LLM 依然能有效满足用户需求？这正是下一节要解决的问题。
1.4 如何让 LLM 适配你的需求
你可以使用多种技术来增强 LLM 对用户请求的响应能力，即使它事先并不了解某个特定领域，也没有接受过该领域训练。主要技术包括：
- 提示工程（Prompt engineering）
- 检索增强生成（RAG）
- 微调（Fine-tuning）
我们先从最基础的方法开始：提示工程。
1.4.1 提示工程
给 LLM 的提示可以简单到一句命令，也可以复杂到一整段包含指令、示例与上下文的信息块。提示工程，就是设计这些输入的实践，使模型能够理解任务，并产出有用且准确的回答。做得好的提示工程，可以让开发者引导模型行为，使其适配特定领域需求，甚至处理模型未被明确训练过的问题。其中一种常见技术是上下文学习（in-context learning） ：模型从直接嵌入提示中的示例中归纳出模式——无需微调。
在实践中，提示通常会被组织成模板：一个固定指令，加上一些可接收动态输入的可变字段。这样一来，提示在应用不同部分中就更容易复用，也更容易维护。另一种广泛使用的模式是少样本提示（few-shot prompting） ，即通过放入少量示例，教模型如何泛化到相似输入上。
精心设计的提示往往威力惊人。它们可以在无需额外训练数据的前提下，从 LLM 中“引导”出高质量、具备领域感知能力的输出。例如，聊天机器人通常会把最近几轮对话嵌入提示中，从而让模型保持上下文，并生成连贯的多轮回复。提示工程往往能把你带得很远，因此它是许多现实应用中一种轻量却有效的工具。
LangChain 进一步在这一思路之上提供了用于一致管理和复用提示的抽象，我们将在下一章中详细探讨。不过，仅靠提示工程也有其局限——尤其当应用需要把答案建立在用户特有数据或企业内部数据之上时。在这种情况下，下一步自然就是 RAG（本章前文已经提到），即通过从外部来源动态拉取知识来增强提示。
1.4.2 RAG
提升 LLM 响应质量的最有效方式之一，就是让它扎根于你自己的数据之上。与其只依赖模型在预训练阶段学到的内容，不如通过实现 RAG，从本地知识库（通常存放在向量数据库中）中检索相关上下文，并把这些信息加入提示。RAG 已经成为现代 LLM 应用中的核心模式之一。
这一工作流从构建知识库开始。文档会被摄取进来、切分成更小的块，再通过嵌入模型转换为向量表示。这些嵌入能够捕捉语义含义，使文本之间的比较不再依赖字面一致，而可以基于相似度进行。LangChain 提供了工具，用于加载多种格式的文档、高效切分文档、生成嵌入，并将所有内容存储到向量数据库中（见图 1.9）。
图 1.9 一组文档被切分成文本块，并转换为基于向量的嵌入。文本块及其对应嵌入随后都会存储到向量存储中。
RAG 具有多方面的优势：
效率 —— 不必将整篇文档都传给模型，而是只检索关键块——从而保持输入精简、减少 token 成本，并满足上下文窗口限制。
准确性 —— 回答建立在真实数据基础上，从而降低幻觉风险。在本书后面，你还将学习如何让 LLM 在回答中给出来源引用，进一步提升透明度与可信度。
灵活性 —— 通过替换嵌入模型、检索器或向量存储，你可以将同一种模式适配到不同领域与需求中。
定义 对 LLM 进行 grounding（扎根、落地），是指在提示中加入从可信知识源中拉取的上下文——这类知识通常存储在向量存储中。这样可以确保 LLM 的回答基于经过验证的事实，而不是仅仅依赖其预训练知识；后者可能已经过时，或并不可靠。
定义 幻觉（hallucination）是指 LLM 生成了错误、误导性或捏造的回答。这通常发生在模型训练时吸收了低质量数据，或者在回答问题时缺乏足够信息。由于 LLM 具有自回归特性，即使缺少相关内容，它们也会试图继续生成答案——于是会用听起来似乎合理、但其实错误的信息去填补空白，从而产生幻觉。
为了让 RAG 可靠，提示中应明确要求 LLM 只依赖检索到的上下文进行回答。LangChain 也支持护栏（guardrails）和校验器（validators），以帮助约束模型的安全行为。在高风险场景中，人在回路中的审核仍然是最稳妥的保护措施。
总之，RAG 架起了静态预训练模型与动态、领域特定应用之间的桥梁。通过让你的应用学会用与 LLM “相同的语言”——也就是向量——进行交流，你就获得了一种既务实又高性价比的方式，来提供有依据、成本可控的回答。如果提示工程和 RAG 仍无法满足你的需求，那么下一步就是对模型进行微调，下一节我们就来讨论这一点。后文中，我们还会回到 RAG，深入分析它，并探讨那些能将其能力拓展到真实应用场景中的高级模式与技术。
1.4.3 微调
微调，是指让一个预训练好的 LLM 在某项特定任务或某个特定领域上表现更好。做法是：用一组精心整理的数据集对模型继续训练，这些数据集能够体现你希望模型掌握的风格、术语和推理模式。传统上，微调需要专门的机器学习框架和强大的硬件资源；但如今，许多平台——包括 OpenAI 的微调 API 以及若干开源工具链——已经让这件事变得简单得多，通常只需上传数据集并进行极少量配置即可。
微调最主要的好处在于效率：一旦模型吸收了领域特定知识，你就不必再把冗长的说明和示例塞进每一个提示中。换句话说，模型已经“知道”在你的上下文中该如何回答。不过，代价也是真实存在的。准备高质量数据集需要时间和专业知识，而训练本身往往也不便宜，因为通常需要 GPU。
近年来，像 Low-Rank Adaptation（LoRA） 这样的低秩适配方法，以及其他参数高效微调技术，已经显著降低了成本和复杂度，使微调更易于实施。与之相关的技术，如 instruction tuning 和 Reinforcement Learning from Human Feedback（RLHF） ，则进一步推动模型更可靠地遵循指令，不过它们通常也要求更多工程投入与基础设施支持。
至于微调是否真的有必要，这仍是一个持续讨论中的问题。通用 LLM 在开箱状态下已经非常强大，特别是在与 RAG 搭配使用时更是如此。事实上，“Fine-Tuning vs. RAG for Less Popular Knowledge” 这项研究（作者为 Heydar Soudani、Evangelos Kanoulas 和 Faegheh Hasibi）表明，RAG 往往优于微调，因为它可以在运行时动态提供上下文，从而同时降低成本与重复训练需求。
尽管如此，在医学、法律、金融等高度专业化的领域中，微调依然极具价值。它使模型能够掌握领域特定术语与工作流，而这往往是通用模型难以充分匹配的。典型例子包括：
- BioMistral（生物与生命科学）
- LexiGPT（LexisNexis 的法律领域 LLM）
- BloombergGPT（金融）
- Anthropic 的 Claude Code 以及类似的代码导向模型
总结来说，微调能让 LLM 具备领域专长和更高的专用准确性，但代价是时间、资金与复杂度。作为开发者，你需要判断：什么时候它真正值得，什么时候使用 RAG 或提示工程就足以更快达成目标。不过，本书不会深入讲解 LLM 微调，因为本书重点是构建 AI 智能体与应用，而不是创建或修改模型本身。
1.5 如何选择 LLM
在开发基于 LLM 的应用时，你会面对大量模型可供选择。有些模型是专有的，只能通过订阅制或按量付费 API 使用；另一些则是开源的，可以自行托管。大多数现代 LLM 都提供 REST API，便于集成，同时也提供便于直接使用的聊天界面。许多模型还会有不同规模的版本，使你可以在性能、速度和成本之间做权衡。
LangChain 让集成不同 LLM 变得很简单。由于它提供了标准化接口，你只需做极少代码改动就能切换模型——在今天这样快速演进的 LLM 生态中，这是一项非常关键的能力。
在选择模型时，通常需要权衡三大因素：
准确性（Accuracy） —— 一般而言，更大的模型由于接受了更多数据训练，所以更准确。但它们的推理速度更慢，成本也更高，因为供应商通常按每百万 token 收取更高费用。
速度（延迟，Latency） —— 更小的模型响应更快。这使它们非常适合聊天机器人这类对交互响应速度要求较高的应用——但代价则是准确性较低。
成本（Cost） —— 推理成本与模型规模直接相关。更大、更准确的模型通常有更高的每 token 费用，而小模型则更适合大规模使用。
实际中，你需要在这三者之间取得平衡。所谓“最佳”模型，通常既不是最大的，也不是最便宜的，而是最符合你应用需求的那个。例如，客服聊天机器人可能更偏向速度和成本，而法律文档分析工具则会优先考虑准确性，即使代价更高也在所不惜。
除了这三项核心权衡之外，还有一些其他因素也会使某一类模型比另一类更适合你的场景：
模型用途 —— 对于摘要、翻译或分类等通用任务，大多数主流模型（GPT、Gemini、Claude、Llama、Mistral）都表现良好。对于代码生成等专门任务，则应选择针对该领域微调过的模型，例如 Meta 的 Code Llama 或 Claude Code。
上下文窗口大小 —— 更大的上下文窗口可以处理更长的提示和文档。有些模型支持数百万 token，而许多标准 API 则限制在 128K 到 256K。更大的窗口确实扩展了能力边界，但也可能增加成本与处理负担。
多语言支持 —— 如果你的应用需要处理多种语言，应优先考虑那些在多语言训练方面更强的模型。Qwen 和 Llama 因覆盖广泛而受到关注，而某些 Gemma 版本则专门擅长亚洲语言。
指令模型与推理模型 —— 指令模型（如 GPT-5-mini、Gemini Pro）适合你已经清楚知道要执行哪些步骤的场景；推理模型（如 GPT-5 Thinking、Gemini Thinking）则是为了“自己想办法”解决问题而设计。这里的权衡与准确性/速度/成本很相似：推理模型更强，但也更慢、更贵。
开源与专有 —— 开源模型（Llama、Mistral、Qwen、Falcon）提供了隐私、控制权和部署灵活性。专有 API 则更容易上手，而且往往在较少投入下就能提供一流效果，但长期来看成本可能较高。
通过综合考虑这些因素，你就能选择出最符合项目目标与约束的 LLM。在很多应用中，最有效的策略其实是：针对不同任务使用不同模型。例如，一个工作流可以用 GPT-5-nano 做快速摘要，用 GPT-5-mini 做答案整合，再用完整版 GPT-5 处理复杂查询路由——从而在整个系统层面实现准确性、速度与成本之间的优化平衡。
1.6 你将从本书中学到什么
如果你已经读到这里，那么你应该已经认识到：构建由 LLM 驱动的应用具有非常高的价值。与 LLM 的交互正在迅速成为现代软件的核心能力——就像 2000 年代早期，网站为服务器端应用打开了一个全新的交互通道一样。而且，这一趋势只会继续加速。
我们将从提示工程开始，这是高效与 LLM 交互的基础技能。你会先通过 ChatGPT 进行交互式实验，然后再过渡到通过 REST API 进行编程式访问。这些练习将为本书中的许多项目打下基础。
接下来，我们会使用 LangChain 构建两类应用：定制引擎（例如摘要系统和问答系统），以及将对话流畅性与知识检索结合起来的聊天机器人。每个项目都会小而完整，但都会围绕旅游行业这一共同背景展开，这样你就能在一个连贯的领域中看到这些思想是如何互相配合的。
在这些基础之上，我们会进一步转向 LangGraph，构建 AI 智能体——也就是能够编排多步骤工作流、协调工具并进行自适应决策的应用。这将带你进入 LLM 驱动系统中最先进的一类形态：引擎与工具被组合进动态的、自主运行的应用中。为了让这部分内容更易上手，我会先从一个简单的 Python 脚本开始，然后一步一步扩展。每次扩展都会引入一种新的能力——例如工具使用、规划或记忆——这样你就能看到智能体是如何逐步变得更复杂的，而不会一下子被整体复杂度压垮。
我们还会深入剖析 RAG，这是许多真实系统背后的架构模式。RAG 的概念将通过简短、聚焦的脚本引入——有些脚本是独立的，有些则会逐步演进为更高级的工作流——从而帮助你同时掌握基础原理与前沿技巧。
尽管本书中的示例主要出于易用性和快速起步的考虑而采用 OpenAI 模型，你也会学习如何通过附录 E 中列出的推理引擎使用开源模型。这样一来，你将具备构建和部署成本可控、重视隐私、并且完全由自己掌控的应用的能力。
除了构建应用本身，你还将探索 LLM 应用的完整生命周期：借助 LangSmith 进行调试、监控与迭代优化；使用 LangGraph 编排复杂工作流；以及采用生产部署最佳实践，以确保系统具备可扩展性与可维护性。
当你读完整本书时，你将拥有一组可运行的应用作品，掌握核心架构模式，并具备自信设计与实现基于 LLM 系统的能力。你不仅会理解这些应用是如何工作的——你还将真正具备继续创新、并不断推动 LangChain、LangGraph 与 LLM 应用边界向前拓展的能力。
小结
- 基于 LLM 的系统主要分为三类：引擎（执行特定任务，例如摘要）、聊天机器人（具备记忆的多轮对话）以及智能体（可自主执行多步骤任务并选择工具）。
- 嵌入会把文本转换为能表达语义的数学向量。文本块及其嵌入都会被存储到向量数据库中，以支持高效的基于相似度的检索。
- 检索增强生成（RAG）会在生成答案之前，从你的知识库中拉取相关信息，从而增强 LLM。这让回答建立在实际文档之上，而不只是依赖训练数据。
- LangChain 依据三项原则把常见模式封装为可复用组件：模块化（可轻松替换实现）、可组合性（通过 LangChain Expression Language，LCEL，将组件串联起来）以及可扩展性（可添加自定义加载器、检索器或工具）。
Document是 LangChain 的基础构建块，它将文本与元数据打包在一起。文档加载器会把来自 PDF、网页、数据库等来源的内容提取为标准化的Document对象。- LangChain 的核心组件包括：
BaseLoader（将内容提取为文档）、TextSplitters（切分大文本）、嵌入模型（把文本转成向量）、VectorStores（存储与检索嵌入）、BaseRetriever（查询后端）以及BaseLanguageModel（统一的 LLM 接口）。 - Runnable 接口通过 LCEL 让 LangChain 中的所有组件能够顺畅协作。组件可以通过管道操作符
|串联起来，构建复杂工作流。 - 提示工程的目标，是构造出让模型明确理解你需求的输入。少样本提示会在提示中加入示例，以教模型学会所需模式。
- 在选择模型时，需要在三项维度上做平衡：准确性（更大模型训练数据更多）、速度（更小模型响应更快）和成本（更大模型每 token 更贵）。客服聊天机器人更重视速度和成本；法律分析工具则更优先考虑准确性。
- 在同一工作流中，针对不同任务使用不同模型通常更优。例如，可以用 GPT-5-nano 做快速摘要，用 GPT-5-mini 进行答案整合，再用完整版 GPT-5 处理复杂查询路由，从而优化整个系统的准确性、速度与成本权衡。
- 在 RAG 与微调之间做选择时，可以这样理解：RAG 在运行时动态提供上下文（从而降低成本和重复训练需求），而微调则是把领域知识直接嵌入模型中（从而在专门任务上提升效率与表现）。
