企业官网建设流程全解析

把大模型接入项目，和把大模型项目做到能上线，是两个层次的问题。很多开发者刚开始接触 LangChain、RAG、Agent 时，容易被概念淹没：为什么要引入向量数据库？Embedding 到底是什么？Agent 和普通模型调用有什么区别？实际上，这些概念并不孤立，它们共同组成了一条完整的大模型应用链路。

这篇文章会从零开始，基于一个“电商产品知识库问答 + 工具调用”的场景，把模型接入、文档切分、Embedding、向量数据库、RAG 检索、提示词模板、Agent 和工具调用串联起来。整个过程会给出可运行的 Python 示例、关键参数说明、常见报错排查和上线前检查清单。适合已经会写 Python、但第一次系统接触大模型应用开发的开发者，也适合想从 demo 走向生产环境的工程师。

1. 先从全链路视角理解：LLM、Embedding、向量库、RAG 和 Agent 各自解决什么问题

1.1 大模型本身只提供生成能力，业务系统需要把能力组合起来

大模型本质上是文本生成模型。它根据用户输入的 Prompt，预测最合理的下一段文本。这个能力非常强，但放到真实业务里有两个明显限制：

第一，知识有截止时间。模型在训练完成后，参数就固定了，它无法自动知道公司内部产品手册、私有文档、实时公告等新知识。

第二，没有执行能力。模型只能输出文本，不能直接查询天气、计算订单优惠、修改数据库状态。即使模型告诉你可以这样做，也没有实际发生。

所以，一个可落地的大模型项目，通常不会只由一个 LLM 完成，而是由 LLM 加外部模块共同完成。后面要讲的 Embedding、向量数据库、RAG、Agent 和工具调用，本质都是围绕这两条限制做补充。

1.2 RAG 与向量库：解决模型“不知道私域知识”的问题

Embedding 的任务，是把一段文本转换成一串浮点数向量。这段向量可以理解为文本在语义空间中的坐标。两个句子如果语义相近，它们的向量距离通常也比较近。

向量数据库负责存储这些向量，并支持快速检索最近邻。常见的向量数据库包括本地单机适合的 ChromaDB、FAISS，生产级常用的 Milvus、Qdrant、pgvector。它们解决的并不是“存数据”这个简单问题，而是“如何在百万级向量中快速找到最相似的几个”。

RAG（Retrieval-Augmented Generation，检索增强生成）的流程是：先把用户问题转换成向量，去向量库中检索最相关的文档片段，把片段拼进 Prompt，再让大模型根据片段生成回答。它解决的是模型不知道内部知识、又不想每次重新训练模型的问题。

RAG 和微调是两条不同路线。微调要准备训练数据、消耗算力、训练后更新周期长；RAG 只需要维护文档和索引，数据更新时可以重新写入向量库，无需重训练。RAG 的缺点是检索质量直接决定回答质量，如果检索到的内容不相关，Prompt 再优化也救不回来。

1.3 Agent 与工具调用：解决模型“只能聊天不能办事”的问题

Agent 智能体的核心是让模型具备“决策 + 行动”的能力。它不再是单次回答用户问题，而是进入一个循环：