← 返回项目列表
LangChain 是构建 LLM 应用和 Agent 的框架,官方现在将其定位为 “agent engineering platform” 中的 agent framework。它提供标准模型接口、工具、消息、短期记忆、流式输出、结构化输出、middleware、MCP、检索、human-in-the-loop 等能力;更复杂的长运行有状态编排则交给 LangGraph。售前上适合讲“快速构建可替换模型、可接工具、可观测的 LLM 应用底座”,但不应把 LangChain 当成完整业务平台。

1. 项目定位

LangChain 是一个面向 LLM 应用和 Agent 的开发框架。README 写到它帮助开发者把可互操作组件和第三方集成串起来,简化 AI 应用开发,并在底层技术变化时保留可替换性。

最新文档的核心表达是:

Agent = Model + Harness。LangChain 提供 create_agent,作为最小但高度可配置的 Agent harness。

LangChain 负责模型、工具、prompt、middleware 和集成;LangGraph 负责更低层的持久化、有状态、长运行编排;LangSmith 负责可观测、调试和评估。

2. 主要能力

能力说明售前价值
标准模型接口OpenAI、Anthropic、Google、Ollama、Azure、Bedrock 等避免被单一模型绑定
create_agent快速组合 model、tools、system prompt、middleware快速搭建业务 Agent
Tools把函数/API/外部系统暴露给模型连接企业系统
Messages标准消息抽象多模型适配
Streaming / event streaming流式响应和事件改善交互体验与调试
Structured output结构化输出适合表单、字段抽取、工作流
Middlewareguardrails、routing、重试、策略控制更容易产品化
Retrieval文档检索/RAG知识库问答基础能力
MCP接入外部工具协议扩展工具生态
LangSmith 集成tracing、debug、evaluation生产排障和评估

3. 适用场景

快速构建 LLM 应用原型

适合从 0 到 1 验证客户场景:知识问答、文档总结、工具调用、客服 Agent、数据查询助手。LangChain 的抽象和集成生态能降低 PoC 开发成本。

多模型适配和迁移

客户常常不确定最终用 GPT、Claude、Gemini、国产模型还是本地模型。LangChain 的标准接口可以让同一应用在多个模型之间切换,便于评估成本、效果和可用性。

Agent 工具调用

适合把 CRM、ERP、数据库、搜索、工单系统包装成 tool,让 Agent 能执行任务,而不只是回答。

RAG 和企业知识库

LangChain 仍是 RAG 生态中的常见选择,尤其适合和 embedding、vector store、retriever、chunking、prompt 模板、LangSmith 评估一起使用。

4. 不太适合的场景

场景原因建议
长运行、强状态、多分支 AgentLangChain agent harness 可用,但复杂编排应转 LangGraph用 LangGraph
只调用一次模型直接 SDK 更简单不必引入框架
极致性能和最小依赖框架抽象有成本自研轻量封装
完整企业平台LangChain 是开发框架,不是权限/运维/治理平台配合 LangSmith/自建平台

5. 使用示例

uv add langchain
from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

result = agent.invoke({
    "messages": [{"role": "user", "content": "What's the weather in San Francisco?"}]
})

6. 售前可以怎么讲

LangChain 的价值不是某个单点算法,而是让企业能更快地把模型、工具、知识库和业务系统组合成 LLM 应用。它适合用来快速验证业务闭环,并保留模型可替换性;当应用变复杂、需要持久化和人审时,再升级到 LangGraph 和 LangSmith 体系。

7. PoC 建议

阶段工作指标
场景选择选一个清晰任务,如知识库问答或工单助手业务闭环明确
多模型对比接 2-3 个模型准确率、成本、延迟
工具接入接一个真实 API/数据库工具调用成功率
RAG 评估接客户文档命中率、引用准确率
可观测接 LangSmith 或等价 tracing可排障、可评估

8. 风险和注意事项

  • LangChain 生态变化快,版本升级和文档路径要固定。
  • 框架不能代替 prompt、数据治理、权限控制和业务流程设计。
  • Agent 工具调用必须有权限、审计和防误操作策略。
  • 对复杂多步骤任务,早期就要判断是否应直接用 LangGraph。

9. 我的售前判断

LangChain 适合做企业 LLM 应用的“组合层”和“原型加速器”。售前上最有效的表达不是“LangChain 很火”,而是:

用 LangChain 快速接模型、工具、检索和结构化输出;
用 LangGraph 管复杂状态;
用 LangSmith 做可观测和评估。

10. 参考资料

信息核查日期:2026-06-30。GitHub API 匿名访问触发限流,本笔记未写实时 stars/forks。