跳转至

langchain-ai/langchain: AI 原语的编排与组合

LangChain 解决的核心问题是：如何将碎片化的 AI 原语（Prompt、LLM、Retriever、Parser）组装成一条可观测、可替换、结构化的执行链。 它通过 Runnable 协议与 LCEL（LangChain Expression Language），将“隐式的 Helper 代码”转化为了“显式的编排逻辑”。

1. 核心协议：Runnable

在 LangChain 体系中，一切皆可运行。

  • 统一接口：无论是提示词模板（PromptTemplate）、模型（LLM）还是解析器（OutputParser），都遵循统一的 invoke、batch、stream 接口。工程直觉：这种一致性让开发者能以极低的成本替换底层实现（如将本地 Ollama 切换为 OpenAI），而无需改动编排逻辑。
  • LCEL (表达式语言)：使用管道操作符（|）定义数据流向。它将复杂的逻辑嵌套展平为直观的拓扑路径，增强了链路的透明度。

2. 执行链的生命周期

一条典型的 LCEL 链 chain = prompt | model | parser 运行过程如下：

  1. 输入装配：将业务参数填入 Prompt 模板。
  2. 模型交互：将格式化后的文本發给 LLM。
  3. 结果归一：解析器接住模型产出的自由文本，将其转换为 JSON 或业务对象。
  4. 可观测性挂载：链条的每一步都会自动触发追踪（Tracing）钩子，上报至 LangSmith 等平台。

3. 工程防腐：组合层不等于运行时

  • 组合的局限：Chain 本质上是单向、无状态的执行流。
  • 不负责恢复：如果 Chain 在执行到一半时由于网络波动失败，它无法从断点处恢复。关键决策：如果你需要循环、重试或长周期状态保持，应立即转向 LangGraph，而不是在 Chain 里写一堆 if-else 试图模拟循环。

4. 常见误区与失效模式

  • 隐式状态污染：在 Lambda 节点或 Helper 函数中强行读写全局变量，破坏了 Runnable 的幂等性与可追溯性。
  • Parser 脆弱性：过度依赖复杂的 Prompt 来控制格式，而忽略了模型可能会因为 Token 截断或幻觉而返回非法 JSON。应结合 Pydantic 进行强校验。
  • 链条过长导致黑盒化：将几十个步骤塞进一条 LCEL 链中，虽然看起来整洁，但在 P99 抖动时，极难定位到底是哪一个节点拖慢了整体时延。

5. 排查顺序：从协议到节点

  1. 核对数据流向：LCEL 链中每一步的输出类型是否与下一步的输入类型匹配？
  2. 分析 Parser 结果：模型返回的文本是否能被解析器正确结构化？是否存在编码乱码或截断？
  3. 监测中间件时延：Retriever（检索）是否花费了过多时间？是否因为并发数限制导致了排队？
  4. 查 Context 注入：历史记录（Memory）是否被正确装配进了 Prompt 模板？

结论： LangChain 是 AI 组件的“乐高”底座。好的设计应利用其 Runnable 协议屏蔽供应商细节，利用 LCEL 确立主链路，并将长任务的状态治理交给更专业的运行时（Runtime）层。