AI Scaffold 和 LangChain、LangGraph 是什么关系？

上一篇文章讨论了如何用 AI Scaffold 做一个智能客服应用。

智能客服应用把 RAG、多轮对话、Tool Calling、Repository、日志、安全和人工兜底串在了一起。

到了这一步，读者很容易提出一个问题：

既然已经有 LangChain 和 LangGraph，为什么还需要 AI Scaffold？

这个问题必须认真回答。

因为如果讲不清这个关系，AI Scaffold 就容易被误解成又一个想替代 LangChain 的框架。

但从工程定位看，它们不是同一层东西。

LangChain、LangGraph 和 AI Scaffold，更合理的关系不是互相替代，而是分层协作。

一、先把问题说清楚

很多开发者接触 AI 应用时，最早听到的框架就是 LangChain。

后来做 Agent、复杂 Workflow 或状态机编排时，又会接触 LangGraph。

所以当一个项目提出 AI Scaffold 这种脚手架概念时，疑问很自然：

有了 LangChain，还需要 AI Scaffold 吗？ 有了 LangGraph，还需要自己设计 Workflow 吗？ AI Scaffold 是不是又造了一个框架？

这些问题不是反对意见。

它们是定位问题。

如果一个项目不能讲清楚自己和已有生态的关系，就很难让开发者信任。

所以这篇文章的重点不是证明谁更好。

而是讲清楚：

• LangChain 解决什么。
• LangGraph 解决什么。
• AI Scaffold 解决什么。
• 它们在真实项目中如何配合。

二、LangChain 更像能力组件层

LangChain 的核心价值，是提供构建 LLM 应用所需的一系列能力组件。

例如：

• 模型调用封装。
• Prompt 模板。
• Retriever。
• Tool。
• Agent。
• 文档加载。
• RAG 相关组件。
• 与不同模型和外部系统的集成。

从开发者视角看，LangChain 可以帮助你更快接入大模型能力。

例如：

fromlangchain_core.promptsimportChatPromptTemplate prompt=ChatPromptTemplate.from_messages([("system","你是一个客服助手"),("human","{question}")])

这种能力对 AI 应用开发很有用。

它让开发者不必从零封装 Prompt、模型调用、Retriever 和 Tool。

所以 LangChain 更像是 AI 应用能力库。

它解决的是“如何调用和组合 AI 能力”的问题。

三、LangGraph 更像流程编排层

LangGraph 的重点不只是单次模型调用。

它更关注状态、节点和执行流。

当一个 AI 应用包含多个步骤、分支、循环、人工介入或 Agent 状态时，就需要更明确的流程编排。

例如：

接收用户问题 -> 检索知识库 -> 判断是否需要调用工具 -> 调用工具 -> 生成回答 -> 判断是否转人工

这种流程如果只写成一串函数调用，后续会难以维护。

LangGraph 的价值在于用图结构表达这些节点关系。

它适合处理：

• 多步骤任务。
• Agent 执行流。
• 条件分支。
• 循环重试。
• 状态传递。
• 人工介入。
• 长流程任务。

所以 LangGraph 更像 Workflow / Agent 编排层。

它解决的是“复杂 AI 流程如何执行”的问题。

四、AI Scaffold 更像项目骨架层

AI Scaffold 关注的不是某一个模型调用，也不是某一个图编排算法。

它关注的是一个 AI 应用项目应该如何组织。

例如：

• 项目目录怎么设计。
• CLI 如何创建项目。
• 配置系统怎么管理。
• .env如何组织。
• Prompt 放在哪里。
• LLM 抽象层如何封装。
• Workflow 文件放在哪里。
• Tool 如何注册。
• Repository 如何访问数据。
• Memory 如何设计。
• 日志和可观测性如何接入。
• 安全策略如何集中管理。
• Docker 和部署模板如何生成。
• README、示例和开源结构如何组织。

这些问题 LangChain 和 LangGraph 不一定负责。

它们更多关注 AI 能力和流程。

而 AI Scaffold 关注的是工程项目本身。

所以它更像项目脚手架。

它解决的是“一个 AI 应用项目应该长什么样”的问题。

五、三者不是同一层东西

可以用一个简单分层来理解：

AI Scaffold：项目骨架层 LangGraph：流程编排层 LangChain：能力组件层 模型 API / 数据库 / 外部系统：基础能力层

或者换一种表达：

AI Scaffold 管项目。 LangGraph 管流程。 LangChain 管能力组件。 模型厂商和业务系统提供底层能力。

这就是三者最核心的区别。

它们不是完全重叠的东西。

如果把 AI 应用比作一个后端项目：

• LangChain 像一组 SDK 和能力库。
• LangGraph 像流程引擎或状态机。
• AI Scaffold 像项目模板、目录规范和工程底座。

所以讨论“谁替代谁”意义不大。

更有价值的问题是：

它们如何组合得更好。

六、为什么只用 LangChain 还不够

只用 LangChain，开发者仍然需要自己解决很多工程问题。

例如：

• 项目目录如何拆分。
• 多环境配置如何管理。
• API Key 如何注入。
• Prompt 模板如何版本化。
• 数据访问层如何设计。
• Tool 调用如何审计。
• 日志和 Trace 如何记录。
• 安全策略放在哪里。
• Dockerfile 如何写。
• 测试目录如何组织。
• README 和示例如何维护。

这些不是 LangChain 的主要职责。

LangChain 可以帮助你调用模型、使用 Retriever、组织 Tool 和 Agent。

但它不会自动帮你设计完整项目结构。

所以一个真实项目里，即使使用 LangChain，也仍然需要工程脚手架。

否则项目很容易变成：

main.py utils.py prompt.txt demo.ipynb

Demo 可以这样写。

生产项目不能长期这样写。

七、为什么只用 LangGraph 也不够

LangGraph 很适合复杂流程。

但它也不是完整项目脚手架。

例如你用 LangGraph 编排了一个智能客服流程：

retrieve -> decide_tool -> call_tool -> generate_answer -> handoff_check

这解决了流程问题。

但项目仍然需要：

• 配置系统。
• API 层。
• Repository 层。
• Tool 注册目录。
• Prompt 模板目录。
• 日志模块。
• 安全模块。
• 部署文件。
• 测试结构。

LangGraph 可以放在workflows/里。

但它不等于整个项目。

所以 LangGraph 和 AI Scaffold 的关系，更像是：

LangGraph 是 AI Scaffold 项目中的一个可选 Workflow 实现方式。

它可以被脚手架组织起来。

而不是必须和脚手架竞争。

八、AI Scaffold 可以集成 LangChain

AI Scaffold 不需要排斥 LangChain。

相反，它可以提供默认适配层。

例如：

app/ ├── llms/ │ ├── base.py │ └── langchain_client.py ├── rag/ │ ├── retriever.py │ └── langchain_retriever.py ├── tools/ │ ├── registry.py │ └── langchain_adapter.py └── prompts/ └── customer_service.md

这样项目可以在内部使用 LangChain 能力。

但业务代码不直接到处依赖 LangChain。

例如可以封装一个统一 LLM 接口：

classLLMClient:defchat(self,messages:list[dict])->str:...

底层实现可以是 LangChain。

也可以是 OpenAI SDK、DeepSeek SDK、Qwen SDK 或其他实现。

这样做的好处是：

业务层保持稳定。

底层能力可以替换。

九、AI Scaffold 可以集成 LangGraph

同样，AI Scaffold 也可以把 LangGraph 作为 Workflow 实现。

例如：

app/ ├── workflows/ │ ├── document_analysis_workflow.py │ ├── customer_service_workflow.py │ └── langgraph_runtime.py

对于简单流程，可以直接使用普通 Python Workflow。

对于复杂 Agent 流程，可以使用 LangGraph。

例如：

简单文档总结： 普通 Workflow 足够。 复杂智能客服： 可以使用 LangGraph 表达状态和分支。 多 Agent 协作： 更适合使用 LangGraph 或类似图编排方式。

这是一种务实策略。

不要为了使用 LangGraph 而使用 LangGraph。

也不要因为有了普通 Workflow 就排斥 LangGraph。

根据复杂度选择工具。

十、真实项目里的组合方式

一个真实 AI 应用项目，可以这样组合：

AI Scaffold ├── CLI 生成项目结构 ├── config 管理配置 ├── prompts 管理 Prompt ├── repositories 管理数据访问 ├── observability 管理日志和追踪 ├── security 管理安全策略 ├── deployment 提供 Docker 模板 └── workflows └── LangGraph 编排复杂流程 LangChain ├── LLM 调用 ├── Retriever ├── Tool Adapter └── Prompt Template

这种方式的核心是：

项目结构由 AI Scaffold 统一组织。

AI 能力可以由 LangChain 提供。

复杂流程可以由 LangGraph 编排。

这比把所有东西堆在一个脚本里更可维护。

也比试图自己重写所有生态能力更现实。

十一、不要把脚手架写成框架竞争者

AI Scaffold 如果要做得可信，就不能把自己包装成“替代 LangChain”。

这是不准确的。

更合理的定位是：

AI Scaffold 是 AI 应用工程化脚手架。 它可以使用 LangChain，也可以不使用 LangChain。 它可以集成 LangGraph，也可以使用自己的轻量 Workflow。

这会让项目定位更稳。

开发者也更容易接受。

因为真实开发中，很少只有一种工具能解决所有问题。

好的工程方案，通常是把不同层次的工具组合起来。

十二、什么时候不需要 LangChain 或 LangGraph

也不是所有 AI Scaffold 项目都必须使用 LangChain 或 LangGraph。

如果项目很简单：

一个接口。 一个 Prompt。 一次模型调用。 少量配置。 没有复杂 Tool。 没有多步 Workflow。

那直接使用模型 SDK 可能就够了。

如果项目只有简单顺序流程：

上传文件 -> 解析 -> 总结 -> 保存报告

普通 Python Workflow 也可能够用。

当项目出现更复杂的状态、分支、循环、Agent 决策和人工介入时，再引入 LangGraph 会更合适。

工程选型不要为了显得高级。

应该为了降低复杂度。

十三、什么时候应该引入 LangGraph

如果项目出现以下特征，可以考虑 LangGraph：

• 多节点流程。
• 条件分支明显。
• Agent 需要多轮决策。
• 工具调用结果会影响下一步。
• 需要人工介入。
• 需要状态持久化。
• 需要循环重试。
• 需要清晰描述执行图。

例如智能客服、复杂任务助手、多 Agent 协作、自动化运维助手，都可能适合 LangGraph。

但即使引入 LangGraph，也建议放在清晰目录里。

例如：

app/workflows/customer_service_graph.py

不要让图编排代码和 API、数据库、配置、Prompt 全部混在一起。

这正是 AI Scaffold 可以发挥作用的地方。

十四、总结

AI Scaffold、LangChain 和 LangGraph 的关系，不应该被理解成简单竞争关系。

更合理的分层是：

• LangChain 解决 AI 能力组件问题。
• LangGraph 解决复杂流程和 Agent 编排问题。
• AI Scaffold 解决项目结构和工程化组织问题。

一个真实 AI 应用项目里，它们可以组合使用：

• 用 AI Scaffold 生成项目骨架。
• 用 LangChain 接入模型、Retriever、Tool 和 Prompt 能力。
• 用 LangGraph 编排复杂 Workflow 或 Agent。
• 用 AI Scaffold 管理配置、Repository、日志、安全、部署和文档。

这样做的好处是边界清楚。

能力归能力。

流程归流程。

项目结构归项目结构。

AI 应用工程化不是选择一个万能框架。

而是把合适的工具放在合适的位置。

下一篇文章可以继续讨论如何把 AI Scaffold 做成一个真正的开源项目，包括 README、示例、Roadmap、Issue 模板、版本规划和开源许可证。