第 2 章从“为什么需要 LangChain”讲到第一个聊天机器人，并介绍 LangChain 表达式。表面上这是快速入门，真正重要的是建立一个最小心智模型：输入如何进入系统，模型如何被调用，结果如何流向下一步。

LangChain 解决的是最后一公里

大模型 API 已经能直接返回文本，为什么还要框架？因为一个可用应用通常还要处理提示词变量、聊天消息、重试、流式输出、结构化结果、外部数据、工具调用和运行追踪。每个点单独写都不难，组合起来却很容易形成紧耦合代码。

框架的意义不是减少一两行 HTTP 请求，而是让模型、数据和业务流程可以替换。模型供应商变化时，业务逻辑不应整体重写；提示词变化时，数据加载逻辑不应跟着移动。

第一个应用的最小结构

一个最小聊天应用可以拆成四部分：配置密钥，创建模型对象，准备输入消息，执行调用并处理返回值。真实项目还应加上超时、错误分类、日志和成本控制。

环境变量不要写死在源码里，尤其不要把密钥提交到仓库。开发环境可以使用本地配置文件，部署时交给密钥管理系统。模型名、温度、最大输出长度也应集中配置，而不是散落在业务函数里。

聊天模型的输入不是普通长字符串，而是一组带角色的消息。系统消息定义行为边界，用户消息表达本轮任务，历史消息提供上下文。把所有内容粗暴拼接成一个字符串，会丢失角色语义，也更难调试。

两个关键词：组件与组合

书中强调 LangChain 的两个关键词，我理解为“组件”和“链式组合”。组件负责单一能力，例如提示词模板、模型、解析器、检索器；组合负责把前一步输出接到后一步输入。

好的组合有清晰契约。提示词模板输出模型能接受的消息，模型输出解析器能识别的对象，检索器输出带来源信息的文档。只要契约稳定，内部实现就可以替换。

表达式不是语法糖那么简单

LangChain 表达式希望把流程写成类似管道：输入经过提示词，再到模型，最后进入解析器。它的价值不是符号更短，而是让一段流程成为可调用、可流式、可批处理、可追踪的整体。

不过表达式也不应掩盖业务逻辑。遇到复杂分支、事务操作、权限检查和人工确认时，我更愿意保留显式函数。框架组合适合描述模型相关数据流，普通代码负责确定性的业务控制。

从聊天机器人开始检查什么

第一，检查消息边界。系统指令、用户输入和检索上下文要分清来源，不能让用户文本轻易覆盖系统约束。

第二，检查失败行为。限流、超时、内容过滤、网络错误和模型返回空内容都需要明确处理。

第三，检查对话长度。历史消息会不断增长，需要截断、摘要或外部存储，不能无限塞入上下文。

第四，检查可追踪性。一次回答用了哪个模型、哪个提示词版本、多少 token、耗时多久，至少在日志中可见。

我的理解

第一个聊天机器人不是最终产品，而是一块试纸。它能帮助我确认模型接入是否正确，也能尽早暴露配置、消息和错误处理上的缺口。

入门阶段最重要的不是追求功能多，而是让最小流程边界清楚：输入可验证、调用可替换、输出可处理、运行可观察。有了这个骨架，后面的检索、记忆和 Agent 才不会变成一团互相引用的代码。

版本提示：本书采用较早期 LangChain 写法，实际运行时请对照当前官方文档调整包名、初始化方式和表达式 API。

文章摘自：https://www.cnblogs.com/hazy-star/p/22048342