LangChain
提问
立正把 LangChain 当作一个“名词”:值得了解,但学会它不等于会用 AI,真正的差距在上下文管理、任务拆解、人机分工这些“动词”上。
LangChain 是名词,不是能力
材料里的观点立正把 LangChain 和 RAG、fine-tune、harness 归为一类:有仓库、有文档、有版本号,所以看起来像“要学的技术”,也容易被写进简历和面试题。但这类名词读文档、跑 demo 就能上手,他公开说自己不用 LangChain,理由是理解了它的本质、知道它不适合自己1,2。真正拉开差距的是动词——什么时候给 AI 更多或更少上下文、复杂任务怎么拆、哪些环节必须有人判断、出错时能不能定位是模型能力、上下文还是 routing 的问题3。
框架替你定了问题怎么拆
在讲 MCP 时,立正说 LangChain 试图把所有抽象都打包进来,做的东西太多,反而让框架不好用;Anthropic 只定义怎么用工具,不把多步推理和计划塞进去,所以更有效4。另一篇材料引述鸭哥的批评:用多个 Agent 消息协作、用图描述工作流、用代码当工具调用媒介,这些不只是接口选择,而是在替你规定问题该怎么拆、状态该怎么组织;简单 demo 容易跑,一旦要对接企业已有接口或改变执行方式,就得追进层层抽象去改5。所以判断标准是任务是否恰好符合框架的假设,而不是框架本身强不强。
材料没有对 LangChain 各版本或与 LangGraph、Dify 的具体对比,也没有给出“该不该用”的统一结论;上面关于框架假设的部分来自立正转述鸭哥的文章,不是他本人的原话。
回到5份原文
解释为什么 LangChain 这类名词容易被当成值得学的东西,以及名词与动词的分类错误。
可回到原文核对这部分判断
说明真正拉开差距的动词具体是什么,可对照自己是否只在学名词。
立正本人对 LangChain 抽象过多、不如 MCP 聚焦的直接判断。
框架如何用架构假设替代构建者判断,以及定制时的迁移成本。