上一篇文章讨论了如何用 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 promptChatPromptTemplate.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.ipynbDemo 可以这样写。生产项目不能长期这样写。七、为什么只用 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 可以集成 LangChainAI 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 模板、版本规划和开源许可证。