LangChain 最容易被误解为“把提示词、模型和工具包起来”的库。深入使用后我更看重它提供的统一组件协议、可组合 Runnable、回调追踪和生态集成，而不是某一个封装函数。

LCEL 的价值在组合与可替换

Prompt、模型、解析器、检索器都可以作为 Runnable 组合，并统一支持调用、批处理、流式与异步。链路清晰时，替换模型或插入日志更容易；但过度追求一行链式表达，也会让异常处理和业务分支难读。

Agent 不等于无限工具循环

生产中要明确最大迭代次数、超时、工具权限和退出条件。工具描述、结构化输出、消息历史与错误恢复需要一起设计。简单确定性流程优先写成普通 Chain；只有需要模型动态决定下一步时，才引入 Agent。

可观测性应该从第一天接入

LangSmith 一类追踪能力能记录每次模型输入输出、工具调用、耗时、token 和错误。

请求 -> Runnable 链路 -> 子调用 Trace -> 反馈/评测 -> 回归数据集

没有 trace，线上“偶尔答错”很难定位究竟是检索、Prompt、模型还是工具的问题。

生产模式要把框架放回系统里

缓存、限流、重试、幂等、配置管理和权限并不会由 LangChain 自动解决。框架适合承载模型相关编排，业务真相仍应留在领域服务。保持边界后，生态的便利才不会变成对框架内部细节的过度耦合。

这章给我的启发

LangChain 的意义不是让代码看起来更像 AI，而是给模型、工具、检索和追踪提供共同接口。用好它的关键，是知道哪些变化交给框架，哪些确定性规则必须掌握在自己的应用里。

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