企业官网建设流程全解析

零基础学大模型应用开发，最常见的困境不是看不懂“大模型”“智能体”“微调”这些词，而是打开教程后不知道从哪里动手。与其先去啃一本大模型原理书，不如先把“AiAgent 智能体搭建”作为主线。搭建一个能对话、能查资料、能调用工具的智能体，需要把提示词工程、知识库检索（RAG）、模型选择、接口调用、私有化部署串起来使用，这些恰好是企业级大模型项目的核心环节。本文的目标很具体：从零开始，用开源工具链完成一个可交互的企业级智能体，再走一遍模型微调和私有化部署的完整链路。学完之后，你能独立回答四个问题：智能体该用什么工具搭；业务知识怎么让它读到；垂直场景模型怎么微调；微调后的模型怎么安全地交付给生产系统。

1. 先理清智能体、RAG、模型微调分别在解决哪一层问题

零基础学习者最容易犯的错误，是认为“RAG、微调、提示词工程”三者可以互相替代。实际上它们解决的是不同层级的问题。先把这个分层关系想清楚，后面做技术选型时才不会乱。

1.1 提示词工程：让模型理解你要什么

提示词工程是成本最低、见效最快的一层。它的本质是：在不修改模型参数的前提下，通过输入文本的设计，引导模型输出更符合期望的结果。

举一个业务例子：同样的模型，一个只写“你是客服”的提示词，和一份完整定义角色、口径、禁区、输出格式的提示词，在真实客服场景下的可用性会相差很大。提示词工程解决的是“表达层”问题。它适合处理规则明确、偶尔失灵的对话场景，但它有天然边界：模型不知道的事，提示词写得再好也没用。比如产品上线后新增的内部故障案例，模型在训练时没有见过，提示词无法凭空制造这段知识。

1.2 RAG：把私有知识临时“贴”给模型

RAG（Retrieval-Augmented Generation，检索增强生成）解决的是“知识层”问题。它的思路是在用户提问之后、模型生成之前，先从知识库中检索相关片段，再把片段拼进上下文，让模型基于这些材料回答。

RAG 最大的价值，是让大模型可以回答私有知识、实时知识和业务知识，而不需要重新训练模型。典型实现是：把企业文档切块、向量化后存入向量数据库，用户提问时做相似度检索，把最相关的若干条内容拼进提示词。

RAG 的优点是可以随时更新知识、可解释性强、训练成本低；缺点也很明显：检索质量会影响回答质量。如果知识库本身很乱，模型就会“一本正经地胡说”。

1.3 模型微调：改变模型本身的“本领”

模型微调是在模型权重层面做文章。它的目标是让模型在特定领域、特定风格、特定任务上的表现发生实质性变化。比如让模型习惯企业内部的术语体系、学会特定的回复格式、在某个业务场景下减少空话。

微调解决的是“能力层”问题。RAG 能解决“知道不知道”，微调更多解决“做得好不好”和“像不像”。实际项目中两者经常结合使用：微调让模型的语气和格式更贴合业务，RAG 让模型及时获取最新的私有知识。

零基础学习时，可以先不急着微调。先用提示词和 RAG 跑通业务，等发现模型“怎么调提示词都不对”时，再考虑微调。这个顺序很重要。

1.4 智能体：负责调配提示词、知识和工具的“控制系统”

智能体（Agent）可以理解为一个控制层。它以大模型为推理核心，把大模型、工具调用、记忆、知识库、工作流组合成一个能完成多步骤任务的应用系统。当一个任务涉及“先查资料、再调用接口、再汇总回答”时，就需要智能体来编排。

从实现上看，很多智能体框架都借鉴了 ReAct 这类思路：模型先思考要做什么，再决定调用哪个工具，观察工具返回的结果，再继续下一步。Dify、Coze、LangChain 等平台，本质上都是把这种循环变成可视化或半自动化的工程实现。

新手理解智能体，不要把它想成“有意识的人工智能”，把它想成一个“带工具、带知识、带流程的大模型封装系统”就行。

2. 零基础工具链：本地模型、智能体平台、微调框架怎么组合

零基础学习者做这条链路，不需要一开始就买大量 GPU。关键在于先把工具链跑通。推荐一套组合：Ollama 提供本地模型接口，Dify 提供智能体搭建和知识库能力，Llama-Factory 提供微调实验能力。三者都是开源或免费可用的，社区资料多，适合学习，也适合中小团队做企业级原型验证。

2.1 硬件预期：不同配置能做多大规模实验

先对硬件建立合理预期，避免一上来就被显存劝退。

如果只有普通笔记本，先从 1B 到 3B 模型开始，训练和推理都能跑。不要一开始就追求 70B 模型。企业级实战中还要考虑成本和并发，小模型的性价比和可控性反而更适合入门。

2.2 用 Ollama 快速提供本地大模型接口

Ollama 是目前很省心的本地模型运行工具。它把模型下载、量化、启动、API 暴露做成了几条命令。对零基础用户来说，最大的价值是：不用自己写推理服务代码，也不用手动处理模型格式转换。

学习环境可以这样启动：

# 拉取一个 7B 对话模型 ollama pull qwen2.5:7b # 交互式对话测试 ollama run qwen2.5:7b # 启动 API 服务，默认监听 11434 端口 ollama serve

Ollama 默认提供 OpenAI 兼容接口，路径是http://localhost:11434/v1。Dify、LangChain 等平台可以直接填写这个地址来完成模型接入。这里要注意：Ollama 更多用于学习和原型阶段；生产环境并发较高时，通常迁移到 vLLM 这类专门推理框架。

2.3 用 Dify 承担智能体的 UI、工作流和知识库

Dify 是一个开源大模型应用开发平台。它的价值在于把智能体搭建从“写大量胶水代码”变成“配置化开发”。一个典型的 Dify 应用中会包含：模型设置、系统提示词、知识库、工具、工作流等模块。

学习环境可以用 Docker Compose 一键部署：

# 拉取 Dify 官方仓库（具体以项目文档为准） git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动后访问 Web 界面，创建一个新的“聊天助手”或“Agent”应用，就能进入智能体配置页面。Dify 内置了许多工具，也支持自定义工具，后面章节会具体演示。

注意：Dify 的模型配置页可以同时接入多个模型供应商。学习阶段建议把 Ollama、OpenAI 兼容接口都填进去，方便对比不同模型在同一智能体上的表现。

2.4 用 Llama-Factory 承接数据处理与微调实验

Llama-Factory 是一个覆盖面很广的微调工具，支持多种主流模型架构和多种微调方式。它提供了命令行和 WebUI 两种操作方式。对零基础用户来说，WebUI 能降低起步门槛。

# 安装依赖 pip install llama-factory # 启动 WebUI llamafactory-cli webui

WebUI 中可以把模型路径、数据集路径、LoRA 参数、训练轮数一次性配置好，训练过程和监控指标都会显示在界面里。用 Llama-Factory 之前，需要先准备数据，下一章会说明数据格式。

3. 用 Dify 从零搭建一个可交互的企业级智能体

在零基础阶段，不建议一上来就手写智能体框架。先用 Dify 做可视化搭建，看清智能体的组成部分，再回头理解底层逻辑会容易得多。下面以“企业销售客服智能体”作为例子。

3.1 先拆需求：把“智能体”拆成提示词、知识和工具

搭建之前需要明确三件事：

1. 智能体的身份和边界是什么？比如“某产品的售前知识助手”。
2. 它必须掌握什么私有知识？比如产品文档、价格表、常见问题。
3. 它需要调用哪些实时动作？比如查询订单、提交工单、对接 CRM。

把需求拆清楚后，对应关系就出来了：身份和边界写进系统提示词，私有知识进知识库，实时动作进工具调用。下面用表格整理：

3.2 创建应用并配置系统提示词

在 Dify 中新建应用，选择“聊天助手”或“Agent”。系统提示词建议写成结构化文本，而不是一句话。

你是“云产品售前助手”，面向潜在客户提供产品咨询。 服务边界： - 只回答与产品功能、价格、部署方式、售后服务相关的问题。 - 如果问题超出边界，说明“该问题需要转人工”，不要自行猜测。 回答要求： - 先基于知识库内容回答，引用关键信息。 - 如果知识库没有答案，明确告知用户“资料库中暂无相关信息”。 - 保持简洁，不编造数据。

这里的关键是“写边界和兜底策略”。很多智能体在测试时看起来正常，上线后用户问一个越界问题，模型就自由发挥。系统提示词里必须写好“遇到不确定内容时应如何处理”。

3.3 接入知识库，把私有资料变成可检索内容

Dify 中进入“知识库”，新建数据集，上传产品文档。系统一般会执行三个步骤：解析文档、分段切块、向量化。切块大小会影响检索效果：

• 切块太小：上下文碎片化，模型找不到完整信息。
• 切块太大：浪费上下文窗口，检索精度下降。

常见做法是先用默认参数跑一遍，再看实际检索命中情况，最后根据文档结构调整。比如 300 到 800 字之间的分块，按内容段落切，而不是按字符数硬切。上传完成后，在应用编排页面把知识库挂到“关联知识库”中。

3.4 通过工具调用让智能体具备现场动作能力

Dify 支持内置工具和自定义工具。内置工具如网络搜索、计算器等；更常用的是把业务接口包装成工具。Dify 的自定义工具通常遵循 OpenAPI/Swagger 规范。

一个典型场景是订单查询。假设已有GET /api/orders/{orderNo}接口，可以在工具配置中填入接口地址和鉴权方式。智能体先通过知识库理解用户的“订单号”概念，触发工具调用时把参数传过去，拿到结果后再整理回答。

这样做的好处是：模型不需要真的掌握订单系统，它只要学会“什么时候该调用工具”和“如何解释工具返回的结果”。这是智能体与普通聊天机器人的核心区别。

3.5 联调验证：对话框和 API 都要覆盖哪些用例

配置完成后，先在 Dify 界面的调试框里逐一验证：

验证通过后，可以发布应用并通过 HTTP API 接入到自己的 Web 页面、企业微信或客服系统中。开发阶段建议先使用blocking响应模式，调试更方便；生产环境再按需改用流式模式。

POST {应用API地址}/v1/chat-messages Content-Type: application/json Authorization: Bearer {应用密钥} { "inputs": {}, "query": "你们的产品支持私有化部署吗？", "response_mode": "blocking", "conversation_id": "", "user": "customer-001" }

这个接口的返回值里会包含answer字段，就是智能体生成的最终回复。联调时先确认返回的文本是否正确，再确认业务日志和 token 消耗是否符合预期。

4. 用 Llama-Factory 微调一个垂直业务模型

智能体搭建完成后，你会发现模型在通用对话上表现不错，但到了专业领域，它经常出现“口吻不像、术语不准、格式不统一”的问题。这时可以开始学习微调。

4.1 数据集格式：指令对是微调的基本单元

微调前必须先准备数据。Llama-Factory 等工具通常要求 JSON 或 JSONL 格式。最基础的是指令对：

[ { "instruction": "客户问：你们的产品支持本地化部署吗？", "output": "支持的。我们的产品提供公有云和私有化部署两种方式。私有化部署时，我们会提供部署文档、环境检查清单和远程协助，通常一个工作日内可以完成标准部署。" }, { "instruction": "客户问：私有化部署需要什么硬件配置？", "output": "最低配置为 8 核 CPU、16GB 内存、200GB 磁盘。如果需要部署智能问答模块，建议增加一块 16GB 显存的 GPU。具体配置需要根据并发数和模型大小做规划。" } ]

数据质量比数据数量更重要。企业级微调的第一份数据，建议来自人工整理的真实对话记录，而不是让模型批量生成。脏数据会让模型学会错误的表达方式。

4.2 选微调方式：Full fine-tuning、LoRA、QLoRA 怎么取舍

零基础入门建议直接学 LoRA，并在显存不足时切换到 QLoRA。LoRA 的思路是冻结原模型的大部分参数，只训练一小部分低秩矩阵，所以显存占用低、训练速度快。它特别适合“用 1 万条以内数据让模型适配业务风格”的场景。

4.3 启动训练并监控关键指标

用 Llama-Factory WebUI 或命令行都可以。命令行示例：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset my_business_data \ --template qwen \ --output_dir ./output/qwen_business_lora \ --num_train_epochs 3 \ --learning_rate 5e-5 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --lora_rank 8 \ --lora_target all

训练过程中主要看两个指标：loss 是否在下降，以及验证集效果是否在提升。loss 下降不一定代表业务效果好，所以要留一部分验证集，在训练结束后对验证集做实际生成测试。

注意：不要只盯着训练集 loss。训练集 loss 降到很低水平时，很可能已经开始过拟合，模型会在验证集上出现复读、格式错乱等问题。

4.4 导出合并模型，用 vLLM 重新起推理服务

LoRA 训练完成后，产出的是一个轻量适配器，不能直接作为独立模型推理。需要把 LoRA 权重合并回基础模型，导出完整模型权重：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./output/qwen_business_lora \ --template qwen \ --export_dir ./output/qwen_business_merged

导出后的模型可以交回 Ollama、vLLM、TensorRT-LLM 等框架推理。生产环境并发较高时，vLLM 更常见：

vllm serve ./output/qwen_business_merged \ --served-model-name qwen-business \ --port 8000

启动后会提供一个 OpenAI 兼容接口：http://localhost:8000/v1。用 curl 做一次冒烟测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-business", "messages": [ {"role": "user", "content": "客户问：私有化部署需要什么硬件配置？"} ] }'

如果返回结果已经使用微调后的口径和格式，说明微调链路已经跑通。

5. 私有化部署：从训练机到生产环境的落地链路

微调只是模型变更环节，真正要交付给业务，必须走上私有化部署链路。私有化部署的核心目标不是“把模型跑起来”，而是“稳定、可控、可维护地对外提供服务”。

5.1 不同并发和规模下的部署形态选择

“私有化部署”不等于“在 Docker 里起一个模型”。它还包括数据不出域、访问控制、审计日志、版本回滚、容量规划。对金融、医疗、政务或企业客户，私有化部署通常意味着整个调用链都要在客户环境内闭环。

5.2 vLLM 部署与 OpenAI 兼容接口

vLLM 依赖模型格式、显卡驱动、CUDA 版本。如果直接用合并后的目录不稳定，可以先用模型转换脚本转成标准格式。推荐用命令行参数明确指定端口和并发：

vllm serve ./output/qwen_business_merged \ --served-model-name qwen-business \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000

其中max-model-len决定上下文最大长度，gpu-memory-utilization控制显存占用比例。调大上下文长度会增加显存开销，生产环境要结合业务单轮对话平均长度来决定，不要盲目设置成 32K。

5.3 把微调模型接入 Dify 或其他应用系统

部署好 vLLM 后，回到 Dify 的“设置 -> 模型供应商”，添加