企业官网建设流程全解析

1. 入门大模型，先别急着看各路教程，先把这几个基本概念搞明白

我见过太多人拿着“大模型”“LLM”“AIGC”这些词就开始网上冲浪式学习，结果第一周就看了一堆相互矛盾的文章，学三天就放弃了。大模型学习这件事，最大的问题从来不是资料太少，而是资料太杂、太散、太多结论而太少推理过程。这篇资料我希望给一个相对系统的框架，你把这篇文章当成一张地图，顺着地图找自己需要的具体教程，效率和心态都会好很多。

先说清楚大模型是什么。大模型全称“大型语言模型”，英文是Large Language Model，简称LLM。它本质上是一个基于深度神经网络的概率模型，通过海量文本数据的训练，学会了人类语言的统计规律。你可以把它理解成一个“见过几万亿句话的老同事”，你给它上半句话，它能根据历史统计规律给你接下半句话，接得足够多、足够准的时候，看起来就像在“理解”和“生成”内容了。

这里有个很重要的认知：大模型不是在“查答案”，它是在“预测下一个词”。它之所以能回答复杂问题、写代码、做翻译，是因为训练数据里见过太多类似的模式，它能够把这些模式组合、泛化出来。理解了这一点，你就明白为什么它会一本正经地胡说八道——因为它本质是在做概率预测，不是在做知识检索。

大模型能做什么？从应用角度说，文本生成、代码补全、翻译、摘要、问答、对话、分类、抽取、改写、角色扮演推理，全部能做。进阶一点，通过插件和工具调用，它还能帮你查天气、订机票、操作Excel、控制智能家居、做数据分析。这就是“应用开发”层面的东西，后面我会细说。

大模型不能做什么，这个同样重要。它没有真正的事实核查能力，不知道自己的知识截止日期之外的新事件，数学计算能力不稳定，对超长文本的处理会衰减，而且它没有“记忆”——每次对话结束，它就忘了你。所有看似“记得的内容”，都是你把上下文再次塞给了它。

我建议的入门路径是一条线：基础认知 → 选型了解 → 本地部署跑通 → 提示词工程 → 微调 → 应用开发。这条线的好处是，每一步都能看到东西、玩到东西，不会一直在啃理论。

2. 学习路线怎么排：从跑通第一个模型到玩转微调，我对每个阶段的理解

网上关于“大模型学习路线”的内容非常多，很多博主动辄给你画一张三十天的学习表，我看过几张，说实话都不太适合新手实操，太理想化了。我自己走过的路和踩过的坑，整理下来就六个阶段。

2.1 第一阶段：建立手感，跑通第一个对话模型

这个阶段的目标只有一个，让你亲眼看到模型那句话是怎么生成的，以及体验Prompt对输出的影响。不要在这个阶段碰任何微调的东西，也不要去读Transformer论文，你不是搞科研的，没必要从Attention开始。

最现实的做法是找一个在线平台先把基础对话玩熟。目前国内外主流的闭源大模型，比如OpenAI的GPT系列、Anthropic的Claude系列、Google的Gemini系列，国内的有通义千问、DeepSeek、文心一言、豆包、Kimi，你都注册一个账号，拿同样的问题去问它们，感受一下各自的回答风格和强项。这一步看着简单，但非常重要，你是在建立“模型之间有差异”的直觉。

然后就可以尝试调用API了。OpenAI、DeepSeek、通义千问、Kimi这些平台都提供免费额度，申请一个API Key，用Python写一个几十行的脚本，把对话请求发过去，拿到返回结果。图中这一步最核心的收获是理解“Prompt作为输入、Text作为输出、Tokens是计费单位”这个基本链路。Line这个环节的时间控制在三到五天，不要恋战。

2.2 第二阶段：理解大模型的关键概念和运行原理

这个阶段可以开始读概念了，但要有选择地读。我推荐按下面这个顺序逐个搞懂：

• Token：大模型处理文本的最小单位，不是字，也不是词，是模型自己切出来的符号片段。“大模型”这三个字，可能被切成两个甚至三个Token。Token直接决定你的上下文长度和API费用。
• 上下文窗口（Context Window）：模型一次能“看到”的Token上限。现在的模型动不动就128K、200K，也就是大约十万汉字级别的输入，但实际效果会随长度衰减。
• 参数规模：7B、13B、70B是什么意思。“B”是Billion（十亿），指模型神经网络里的参数数量。参数量越大，模型通常越聪明，但需要的显存和算力也越大。
• 基座模型与对齐模型：基座模型已经练完了海量文本但还没调教好，只会续写；对齐模型经过了指令微调和人类反馈强化学习，才懂得“回答问题”。你日常用的是对齐模型。
• 温度（Temperature）、Top-p等推理参数：控制生成随机性的旋钮。温度越高越有创造力和发散性，越低越保守稳定。
• 幻觉（Hallucination）：模型编造不存在的知识、引用不存在的论文、给出错误的网址。这个后面实操时会反复遇到。
• 微调（Fine-tuning）：在预训练好的模型基础上，用你自己的数据继续训练，让模型适配你的领域。
• 量化（Quantization）：把模型的参数精度从FP16降到INT8甚至INT4，大幅减少内存占用，代价是轻微质量损失。这是本地部署的关键技术。
• RAG（检索增强生成）：把外部知识库检索出来的内容，拼到Prompt里，让模型基于你的资料作答，解决“模型不知道你公司的知识”的问题。
• Agent/AI智能体：让大模型做“大脑”，调用外部工具和API去完成任务，比如查天气、订票、访问网页。

这个概念阶段的节奏可以放慢一点，每搞清楚一个概念，就去查一两篇相关的实操文章加深印象。我自己的感觉是，概念这个东西不用一次全记住，但遇到一个要查透一个，否则后面全是窟窿。

2.3 第三阶段：本地部署，亲手把一个开源模型跑起来

在线API哪怕玩得再溜，你依然对大模型有种“黑盒子”的感觉。本地部署一次开源大模型，你会真正理解模型文件、显存占用、推理速度这些概念是怎么回事。现在本地部署的门槛已经很亲民了，有Ollama、llama.cpp、vLLM这类工具，不需要你会写CUDA，不需要自己从零实现神经网络，跟着下面思路就能跑起来（这部分后面有详细章节展开）。

2.4 第四阶段：提示词工程与上下文工程

很多人用大模型觉得“不聪明”，实际上大部分原因是提问水平不够。提示词工程就是研究怎么把问题描述清楚、把约束条件说透，让模型稳定输出你想要的东西。上下文工程则更进一步，研究怎么管理和组织给模型的那一大段上下文。这里要掌握的核心技术点包括角色设定、Few-shot示例、思维链CoT、结构化输出约束、长上下文的管理策略。尤其是结构化输出，让模型给你JSON而不是一段废话，会直接决定你能不能把大模型接进自己的程序里。

2.5 第五阶段：微调，让模型变成“你的模型”

等你跑通了多个开源模型，发现通用的Chat模型回答你行业问题时太泛、太空，你就开始想微调这事了。微调整体分成全参数微调和LoRA等参数高效微调。对于绝大多数个人开发者、中小团队来说，LoRA是绝对的主流选择，因为一张消费级显卡就能跑起来。国内目前最活跃的微调开源基座是Qwen系列，比如Qwen2.5-7B，微调资料成体系，社区活跃度高，踩坑解法也容易搜到。

2.6 第六阶段：应用开发，让大模型进入你的产品和业务

到这一步，你已经不只是“学习者”，而是“开发者”了。需要掌握的能力包括：API调用的封装与鉴权、流式输出SSE的对接逻辑（让AI回答一个字一个字蹦出来）、Function Calling/工具调用（让模型能调用你定义的函数）、Agent框架的选型、向量数据库与RAG的实际搭建。

从我的经验讲，这个阶段最大的认知转变是：大模型不是你产品的全部，它只是一个组件、一个服务，你要用软件工程的方法论去治理它的输入输出。结构性输出、错误重试、成本控制、协议兼容，才是研发团队真正的日常工作。

3. 市面上的主流大模型怎么选：知名模型速览和一个靠谱的选型思路

热搜词里有一个是“世界有哪些知名的大模型？”这几乎是每个新手都会问的问题。我按几个维度给你盘一盘，不追求把市面上所有模型列全，只列你现在大概率听得到、用得上的。

3.1 闭源商用模型：直接调用API，省心省力

国外梯队里，OpenAI的GPT系列目前依然是综合能力第一梯队。GPT-4o这个级别的模型在复杂推理、代码生成、多模态理解上依然是标杆。Anthropic的Claude系列在长上下文理解和专业写作领域口碑很好，很多人觉得它写长文比GPT更自然。Google的Gemini系列的优势是多模态原生和超长上下文，背靠Google的生态，与搜索、办公套件的集成越来越深。

国内闭源模型里，DeepSeek这两年的表现非常亮眼，R1/V3系列在推理能力上直接对标国际顶尖水平，关键是API价格便宜得不像话，可以说是目前很多中小开发者的首要选择。通义千问（阿里的Qwen系列闭源版本）在中文知识覆盖和工具调用上做得扎实，和阿里云生态绑定比较紧。Kimi（月之暗面）以超长上下文起家，擅长处理长篇文档，K2版本的编程和Agent能力也有明显进步。百度的文心一言、字节的豆包、腾讯的混元，也都在各自生态里跑应用。这些模型的特点是你不需要部署，注册平台申请API Key就能用。适合做原型验证、想做产品但不想买显卡的人。

3.2 开源模型：可以本地部署和微调的玩法和斗

开源模型现在的主流格局，我很看好Qwen系列和Llama系列的基本盘。Meta的Llama系列是海外开源的老大哥，Llama 3.1 8B/70B/405B是业内非常经典的选择，405B的模型能力已经接近闭源第一梯队，但显存要求非常离谱，基本不是个人玩家能碰的。大家更常用的是8B和70B这两档。

阿里的Qwen系列是中文开源生态里绕不开的存在。Qwen2.5系列，从0.5B到72B都有，其中7B、14B、32B这几个中间档是个人开发者和中小公司的首选。它的优势是中文能力强、社区资料丰富、微调生态成熟，和AI框架的适配度也高。我在本地部署和微调实战中，绝大部分场景选的都会是Qwen系列。

还有一个方向是DeepSeek的开源版本，DeepSeek-R1的蒸馏小模型（1.5B到70B）在推理能力上表现很好，如果你需要的是“能思考、能解题”的本地模型，值得试试。此外还有Google的Gemma系列、Mistral的混合专家模型、微软的Phi系列，质量都不错，适合做轻量化场景。

3.3 选型思路与高清避坑

怎么选模型，我给你一个可复用的思路，不要光看跑分榜单：

1. 先定部署方式是云端API还是本地部署。要上生产且不想碰显卡，首选闭源API，成本算清楚就好；要数据私有化、要离线运行，就上开源模型本地部署。
2. 再定参数档位。个人电脑基本跑7B~14B的量化模型最舒服（16G内存起步）；一台有24G显存的显卡（比如RTX 4090、3090）就能跑32B的量化模型；70B以上的模型基本要双卡或服务器级别的配置了。
3. 然后用你的实际任务去测，不要看排行榜。拿你自己的一批业务问题，找三五个候选模型，用同样的提示词问，按“内容质量、格式符合度、响应速度、中文语境”打分。很多排行榜分数高的模型，在你的场景下可能是灾难。
4. 最后注意许可证问题。开源模型也有许可证约束，商用之前查清楚是否允许商用，比如Llama系列Meta有自己的社区许可，Qwen系列用的是Apache 2.0，相对宽松。

4. 本地部署实操：把大模型真正跑在你的电脑上

本地部署大模型，听起来很“极客”，但现在真的是入门友好的状态了。我给一个零基础也能跑通的路线，顺便把背后的原理讲清楚。

4.1 本地部署的硬件门槛到底要多少

硬件是本地部署最大的拦路虎。先记住两个核心概念：显存和内存决定你能跑多大的模型，CPU和算力决定你跑多快。

大模型推理时，需要的显存约等于“参数量 × 每参数的字节数”。以7B模型为例，参数是70亿个，如果用FP16精度（每个参数2字节），推理需要约14GB显存/内存；如果量化到INT4（每个参数约0.5字节），只需要约3.5GB到4GB。所以对于没有独立显卡、只有16GB内存的普通笔记本，跑一个量化后的7B模型是可行的，就是速度会慢一些（每秒几个Token）。如果有一张8GB显存的显卡，跑7B量化模型已经比较流畅；24GB显存的显卡（RTX 3090/4090），可以尝试32B级别的量化模型；要跑70B，建议至少48GB显存。这里给的数值都是“闲时“的经验值，实际操作时还要加上上下文缓存的额外开销，所以留20%的余量是明智的。

判断你的电脑能不能跑某个模型，我建议先去查一下模型卡里标注的“Recommended Memory”，各大模型下载平台也会给出建议配置。

4.2 Ollama方式：五分钟跑起一个本地对话模型

Ollama是目前最友好的本地部署工具，我就是用它入门本地大模型的。它把模型文件下载、环境配置、API服务启动全都封装好了，你只需要几条命令。我给出一个Windows 11的完整流程：

第一步，去Ollama官网下载Windows客户端，安装后打开终端（PowerShell或CMD）。

第二步，从模型仓库选择一个模型下载，最常用的命令是：

ollama run qwen2.5:7b

这个命令会下载Qwen2.5 7B模型并启动交互式对话界面。你也可以换成其他模型，比如ollama run llama3.1:8b、ollama run deepseek-r1:7b。

第三步，等模型文件下载完成，你会进入一个>>>的对话界面，就可以直接聊天了。

第四步，如果想通过API调用本地模型，Ollama默认监听的端口是11434。你的任何程序都可以用OpenAI兼容的接口格式调用：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}]}'

这意味着本地模型也能接入你的应用，这对接下来的应用开发非常有用。

4.3 GGUF文件与llama.cpp：理解模型文件和量化之间的关系

如果你只在Ollama里玩，其实不需要关心底层，但如果你想下载模型文件手动部署，就需要了解GGUF。GGUF是llama.cpp项目提出的一种模型序列化格式，专门针对CPU和消费级GPU推理做了优化，是目前个人本地部署的主流格式。各大下载平台上可以找到形如qwen2.5-7b-instruct-q4_k_m.gguf的模型文件。文件名里有几个信息：q4代表INT4量化，K_M代表量化方式，这个Q4_K_M是目前质量/体积比比较均衡的选择。

用llama.cpp手动部署跟Ollama比确实麻烦一些，要编译、要手动构建命令，但也给你更多控制权，比如可以调整线程数、KV缓存大小、采样参数。llama.cpp的核心命令是llama-cli和llama-server，后者可以提供一个OpenAI兼容的HTTP接口。如果你爱钻研、想彻底弄明白推理细节，这个工具很值得花时间；如果只是想把模型跑起来做应用，用Ollama即可。

另外补充一个“大模型下载平台”的科普：除了Hugging Face这个全球最大的模型社区外，国内用户还可以用ModelScope魔搭社区和对应的一些国内镜像站，下载速度比直连海外快得多，而且是全中文界面，适合新手。

4.4 部署完成后的使用技巧和常见问题

模型跑起来之后，有几个细节直接影响体验：

第一，新增模型。Ollama会在后台自动管理模型文件，磁盘空间要注意，一个7B的Q4量化模型大概要4.5GB左右，32B的Q4量化模型要接近19GB。建议把模型文件放在剩余空间充足的盘里。

第二，上下文长度设置。Ollama默认上下文长度可能有上限，如果要处理长文档，启动时显式设置上面的就行，比如：

ollama run qwen2.5:7b --num-ctx 32768

但要注意，上下文调长之后显存占用也会大幅增加。

第三，推理速度优化。如果你用CPU推理速度很慢，可以试试调整线程数、开启部分GPU层加速。Ollama会自动检测GPU并尽量把模型加载进显卡，如果没生效，检查显卡驱动和显存是否足够。

5. 提示词工程与上下文工程，用同一个模型拉开差距的关键

很多人有一个误解，认为“提示词工程就是会写几个固定模板”，其实它的核心是“和模型高效沟通的方法论”。我在大量实战中发现，用好提示词和上下文工程，同一个模型的能力差距可以很大。这里我把我认为最重要的知识框架分享出来。

5.1 提示词工程的核心技巧

提示词（Prompt）是用户传给模型的输入文本，提示词工程就是设计这个输入文本的结构与内容。对于一个新手来说，先记这些原则性技巧：

一是明确角色与任务边界。经典的结构是“你是一个[身份]，请帮我[具体任务]，要求[输出格式]”。比如：“你是一个资深Python工程师，请帮我写一段从CSV文件读取数据并做统计分析的脚本，要求使用pandas，并输出异常处理完备的版本。”这比直接说“帮我写个Python脚本”好得多。原因是大模型在训练时针对不同角色有不同的分布偏好，你给了角色设定，它就更可能在对应的专业分布里取样。

二是给出约束条件和成功标准。模型需要具体的“什么能做、什么不能做、做到什么程度算好”。比如“如果信息不足，直接说不知道，不要编造”“控制在500字以内”“使用Markdown格式输出”等都是有效的约束。

三是提供Few-shot示例。只告诉模型要什么，它可能理解偏了。你给它两三个输入输出示例，它会照着示例的格式和风格输出。这说明模型擅长模式匹配，你给的模式越清晰，它输出越稳定。比如你要提取简历信息，给两条“从以下简历中提取姓名、年龄、技能列表”的示例，比只提需求效果好一个档次。

四是要求结构化输出。与程序集成时，让模型输出JSON比输出散文靠谱得多。可以这样写：“请以JSON格式输出，字段包括title、content、tags，不要输出其他内容。”然后你再做JSON解析。这件事是应用开发的基础。

五是使用思维链CoT处理复杂推理。遇到数学题、逻辑推理、多步骤分析任务，不加指引模型容易跳步出错。你可以写“请一步步思考，把推理过程写出来”，这就是最简单有效的思维链提示。OpenAI的o1、DeepSeek-R1这些专门“思考”的推理模型，本身就会在内部生成思维链，用户只需要把问题描述清楚。

5.2 上下文工程：管理“模型看到的所有文本”

上下文工程比提示词工程更底层、更进阶。它研究的是“你给模型的那一整段上下文，怎么组织才最有效”。我理解它包含以下几个方面：

第一，上下文不是越长越好。模型的注意力会随着距离衰减，中间部分的信息容易被忽略，学术上叫“迷失在中间”（Lost in the Middle）。我实测下来，长文档问答时，把关键信息放在最开头和结尾，比放在中间的有效性强得多。所以做RAG时，检索结果按相关性重排时可以考虑把最相关的放在上下文开头和末尾。

第二，把知识注入（In-Context Knowledge）与指令分开。不要让大段参考资料淹没你的指令。常见的做法是先写系统指令，然后明确标注“以下是参考资料”，再注明“请基于以上资料回答”。用分隔符把两个区域隔开，模型就会明白各自的作用。

第三，管理多轮对话的累积成本。每轮对话都要把所有历史消息发给模型，上下文窗口满了就得丢弃最早的或做摘要压缩。这就产生了一些专门的上下文管理策略：消息滑动窗口、历史摘要、向量检索召回。对一个新手，我建议在做应用时，先采用“只保留最近的N轮+系统摘要”的策略，这是性价比最高的方案。

第四，上下文工程的进阶形态是RAG（检索增强生成）。把知识文档切块，用向量模型嵌入成向量存在向量数据库里，用户提问时，先检索最相似的知识片段，拼进Prompt，让模型基于这些片段回答。这就是目前企业做私有知识库问答的标准方案。RAG既解决模型不知道你的私有知识的问题，也解决幻觉问题（因为答案有了出处）。

6. 微调实战：从环境准备到效果展示的完整链路

微调是“让模型变得更懂你”的关键手段。如果提示词工程解决不了领域适配的问题，那就要考虑微调了。我以一个经典案例来说明：用Qwen2.5-7B微调成“行业模型”，比如做一个客服领域的垂直模型。下面是完整链路。

6.1 微调的两种主流方式和LoRA原理

首先是全参数微调。所有参数都参与训练，效果上限高，但需要非常大的显存，而且训练成本昂贵，对个人来说并不现实。业内主流是LoRA（Low-Rank Adaptation）这类参数高效微调。LoRA的做法是冻结原模型的全部参数，在模型的线性层旁边额外插入两个低秩矩阵（A和B），只训练这两个小矩阵。这相当于你不需要重写一整本书，只需要在一本书的页边写注释，然后把它粘贴到原书上。训练显存需求大幅降低，效果在很多场景上接近全参微调。

我第一次听到这个概念时也是觉得高深，但你要知道：用工具时，你只需知道LoRA能在消费级显卡上微调七八十亿的模型，训练完后会产出一个很小的adapter权重文件（几十到几百MB），部署时再把它和基座模型合并加载。这就够了。

6.2 环境准备与数据集准备

硬件上，要微调7B模型，如果你的显卡显存低于16GB，会比较吃力。NVIDIA显卡建议至少16GB显存（比如RTX 4090、RTX 4070Ti Super），没有的话可以用云GPU服务，比如AutoDL、阿里云、腾讯云上租卡，价格按小时计，对个人练手来说更划算。

软件环境准备好之后就是数据集。微调最核心的不是模型，而是数据。你要准备一批（输入、输出）配对的数据。比如客服领域，就是几百上千条“客户提问 + 期望回答”。训练前要把这些数据整理成模型要求的格式，常见的有alpaca格式和sharegpt格式。Alpaca格式简单，每条是instruction、input、output三个字段，适合指令微调。ShareGPT格式适合多轮对话。我建议先收集200条以上的高质量数据作为起点。数据量不是越大越好，质量差的数据会让你得到一个“变傻”的模型。

数据质量方面，有几点要提醒：不要有脏数据（前后不一致、答非所问），不要有重复过高的数据，尽量让答案风格统一。我踩过的最大的坑就是数据里夹杂了一些“我不确定”“可能是”这种含糊回答，导致微调完的模型客服语气不够果断。处理数据是一件很费事但非常值得投入的事情。

6.3 训练、合并与部署展示

现在主流的微调框架是LLaMA-Factory，它对Qwen、Llama等主流模型的开箱支持做得非常好，界面友好，参数配置都有默认推荐值。在LLaMA-Factory界面里选择基座模型路径、数据集路径、LoRA参数（一般保持默认），设置训练轮数（epochs），优化器用adamw_torch，学习率一般取1e-4或2e-5，然后就可以开始训练了。

训练过程中实时看loss曲线，loss下降到平台期就可以停了。训练完成会产出一个LoRA权重目录。然后是合并，把LoRA权重合并回基座模型，得到一个完整的模型文件。如果你之后要部署，可以用Ollama等方式加载。最终效果展示时，一定用一个明确的对比：同一个问题，在微调前用通识大模型的回答是什么，微调后模型的专业回答是什么。有了对比，微调的价值立刻可见。

7. 大模型应用开发：从API调用到Agent框架，一篇讲透

最后一个大模块是我自己最常被问到的：大模型会聊了也会部署了，到底怎么集成到自己的应用里？这里我把应用开发的几个关键点全部串起来。

7.1 技术栈怎么选：直接封装API还是用框架

新人通常会纠结“基于什么技术栈封装AI交互逻辑”。我的建议很直接：如果你想快速做原型验证，直接用Python写一个requests或openaiSDK调用API，完全不用上框架。如果后端的同事要用Java，那么Spring AI这类适配器框架就很方便，它提供了统一的接口，让你快速接入不同模型。如果做复杂应用，就用LangChain或LlamaIndex这类LLM应用框架，它们封装了提示词管理、工具调用、向量检索、记忆管理等繁琐工作。但提醒一句，框架虽然方便，但会掩盖底层细节，如果你不理解原生的API和流式处理，调试框架出问题时很容易一头雾水。

7.2 SSE流式输出：让AI的回答“打字机”一样显示出来

大模型响应时间通常要好几秒甚至十几秒，如果让用户全程干等一个转圈图标，体验太差了。所以几乎所有的生产级应用都会采用SSE（Server-Sent Events）流式输出。SSE是一种基于HTTP的服务器推送技术，服务端可以把大模型生成的文本切成一个个片段，逐步推给前端，前端收到一片就渲染一片，用户看到的就是“打字机效果”。

技术实现上并不复杂。后端拿openai SDK请求模型时，设置stream=True，然后循环遍历返回的增量块，每个块里通常会有一个delta.content字段，把它通过SSE协议写到输出流；前端使用EventSource或封装好的fetch流式读取接口，每收到一个数据块就追加到界面上。这里还需要配套AbortController（前端）来实现“停止生成”的功能，否则用户在界面上点“停止”按钮是没法中断模型的输出的。

我自己第一次实现SSE时，卡在两个地方。一是忘了设置响应头Content-Type: text/event-stream和Cache-Control: no-cache，导致前端收不到流；二是SSE消息格式的data:前缀没写对，前端解析失败。这些小坑建议你亲自踩一遍，印象很深刻。

7.3 Function Calling与Agent框架：让模型能调用工具

大模型本身没有手和脚，不能真的去查数据库、调用你的业务接口。但现代大模型支持Function Calling（函数调用），你可以定义一组函数的描述（名称、参数、功能说明），把描述发给模型，模型在回答时如果觉得需要某个函数，就会返回一个结构化的“我想调用这个函数，参数是这些”的信息。你的程序收到后执行函数，再把结果回传给模型，模型基于结果继续输出。这就实现了模型与外部世界的闭环。

基于Function Calling，业界搞出了Agent（智能体）的概念。智能体的本质是一个循环：模型根据目标思考下一步要做什么，调用工具，获得结果，再思考。目前主流的Agent框架有LangGraph、AutoGen、MetaGPT、Claude Agent SDK等。如果只是学习，我推荐你从LangGraph上手，因为它的核心状态图机制和“节点-边”的抽象比较符合程序员直觉。你可以在上面轻松实现“旅游推荐Agent”：用户提需求 → 模型调用景点查询工具、天气查询工具 → 聚合信息 → 输出推荐路线。这个例子在热搜词里也出现了，说明大家对这个方向兴趣很浓。

7.4 本地模型接入应用的实战路径

如果你已经把本地大模型部署好了，你会发现它和云端API完全可以无缝集成。因为Ollama和llama.cpp默认提供的是OpenAI兼容接口，你在代码里只需要把base_url改成http://localhost:11434/v1，把api_key改成ollama，其他地方用openai SDK照样跑。这样以来，你在云端API上调通的代码，几乎可以原封不动地切换成本地模型。另外，你也可以用手机App去集成本地模型，头像的选择在于你准备的是OpenAI API还是本地接口，本地接口通过局域网访问就能在手机上调试。

8. 最后分享几句我踩过坑之后的真心话

如果你想系统入门大模型，言语上的学习速度要超过工具迭代的速度，这是常态。我个人的体会是，这一行入门容易、精通极难、但永远值得。什么Transformer论文看不懂的时候不要慌，直接上手玩模型，玩着玩着回头再看理论，很多地方就通了。不用担心显卡差，先跑小模型，把链路趟通，比盲目追求70B大模型有意义得多。我一再强调，模型在本地跑通了，你的胆量和理解深度都会上一个台阶。

最后再多分享一个小技巧：准备一个“模型测试笔记本”，把你在实践中遇到的每个模型、每个提示词、每次微调的结果都记录下来。这个动作很老派，但坚持半年后，你会有一份属于自己的“大模型规律汇总”，那些模型回答风格的差异、参数对结果的影响、各种框架的隐藏问题，都变成了你的直觉。别人还在百度“为什么模型老是回答不好”的时候，你已经能拿出自己的一套排查思路去修了。这个行业不缺资料，缺的是系统化的吸收和持续实践，这篇文章就是带你上个头，剩下的路，你自己走。