只问模型一句话，不需要这层。一旦答案必须来自某份内部文档、某个接口或某个固定栏目，就需要有人把这些步骤接稳。这就是这层编排在做的事。
它不负责生成本身
| 步骤 | 编排层负责 | 不要交给它的 |
|---|---|---|
| 准备材料 | 把问题和检索结果拼进同一次调用 | 代替你决定哪份文档有效 |
| 调用工具 | 按事先写好的参数格式执行 | 在参数空着时编一个值 |
| 解析输出 | 把文本收成约定字段 | 字段缺失时当作成功 |
| 更换模型 | 尽量只换封装 | 顺便改掉业务停机规则 |
生成仍由背后的模型完成。编排层负责把输入整理成模型能读的材料，决定要不要先检索，把工具的参数说明交给模型，再把模型给出的结构解析成程序能用的字段。换一个模型时，理想情况是只换这一段封装，而不是重写整条业务。
知识库问答是常见路径：问题进来，检索器返回若干段，编排层把段和问题一起送进模型，并要求答案标明用来自哪一段。没有这段编排，模型只能凭训练时见过的文本回答。
工具调用要有参数格式
让模型“去查工单”是不够的。工具需要名称、参数、哪些参数必填、返回里哪些字段可信。编排层把这份说明和模型接上，并在调用前检查参数是否齐。参数缺失就停，不要靠模型编一个编号。
人们用腻它的常见原因
抽象层一多，一次失败要穿过模板、检索器、解析器和回调才能看到原始输入。升级之后，旧的链名和返回结构会变，业务代码跟着改。若团队只需要一次检索加一次生成，自己写二十行调用往往更清楚。
若路径里已有分支、重试和不同角色，继续把逻辑堆在一条链的提示词里会更难维护。那时应把循环交给状态图，而不是再包一层链。编排层适合接组件，不适合隐藏业务规则。
一条链只保留看得到的四段
把现有调用画成四段：材料从哪来、模型标识是什么、工具参数谁检查、输出字段谁解析。画不出四段，说明抽象已经挡住了日志。先去掉一层包装，让这四段重新出现在同一次请求日志里。
然后用一个缺参数的例子。期望是在调用前停下，并指出缺哪个字段。若模型自己补了一个看起来像编号的值，并被当成成功，这一层就不能继续加功能。
升级库之前，把这四段的样例请求存下来。升级后重放。只有材料、参数检查和字段名都没变，才把升级留在生产。业务停机规则不应随库的版本一起变。
常见问题 FAQ
LangChain 是一个大模型吗？
不是。它是把模型、检索、工具和输出解析接起来的库。生成仍由你接入的模型完成。
什么情况下不必用它？
只调用一次模型、没有检索也没有工具时，直接调用更短，日志也更少。
它和检索增强是什么关系？
检索增强是一种做法：先取资料再生成。这个库可以用来实现那种做法，但不是唯一的实现。
为什么有人会放弃这条链？
常见原因是层太多，失败时看不到原始输入，或者升级后返回结构变了。简单路径不一定要留着它。
业务规则应该写在链里吗？
停机、权限和分支应写成程序能检查的条件。提示词只描述这一步要模型做什么。