企业官网建设流程全解析

2026年开年以来，我收到最多的私信类型之一，就是"大模型教程那么多，Prompt、RAG、Agent到底先学哪个"。问这个问题的人，有刚转行的产品经理，有被公司要求做AI应用的业务线工程师，也有还在校的学生。说实话，这个问题本身没有标准答案，但如果非要给一个原则，我通常会反问一句：你学完之后要干什么？这三样东西看着都是"大模型热门教程"，其实背后是三套完全不同的技能栈。网上盘点教程的文章很多，但大多是按热度排序，把名词堆在一起，越看越焦虑。这篇文章我想换个角度，先拆清楚三者的本质和依赖关系，再按不同目标给出学习路径和教程筛选标准，读完你至少能知道自己该从哪条线入手，以及每个阶段学到什么程度可以停。

1. 先别急着选课：Prompt、RAG、Agent到底在解决什么

1.1 三者不是难度递进，而是三个不同的问题域

很多新手把Prompt、RAG、Agent理解成"小学、中学、大学"的递进关系，这个直觉是错的。它们不是同一个技能的不同等级，而是分别解决三个不同类型的问题。

Prompt解决的是"怎么让模型把已有能力稳定输出"的沟通问题。模型能力和知识都在参数里，但同样的模型，不同人写提示词，产出质量可能天差地别。Prompt Engineering的核心是约束和引导：把任务定义清楚、把输出格式锁死、把思考路径带出来。它不涉及外部系统，通常只需要调接口就能验证效果。

RAG解决的是"怎么让模型知道它没学过的事情"。模型训练完知识就冻结了，新文档、私有数据、实时信息它一概不知道。RAG的思路是从外部知识库里检索相关内容，塞进上下文再让模型回答。它本质是信息检索和上下文工程，绕不开向量化、召回、重排这些环节，技术栈明显更重。

Agent解决的是"怎么让模型动手完成任务而非只回答问题"。它让模型在循环里做规划、调用工具、观察结果、修正下一步。多步执行、工具生态、权限控制、成本管理都是这个方向要面对的问题。Agent是这三者里最接近"系统"的东西，它的复杂度不在模型本身，而在模型之外的工程环境。

1.2 为什么教程越看越不知道学什么

信息噪音是2026年大模型学习最严重的问题。教程不是按学习逻辑组织的，而是按流量热点组织的。某个关键词火了，全网一夜之间冒出几百篇同质化内容。我自己踩过这个坑：2025年那会儿想系统补RAG，结果搜出来的前几页文章全是"十分钟搭建RAG知识库"这种标题，内容要么是API套壳，要么是demo截图，真正讲召回链路和评测方法的很少。

更麻烦的是概念边界在融合。现在的框架里，RAG可以看作Agent的一种工具调用方式，Agent也能用RAG来补充记忆，Prompt则渗透在两者所有环节里。如果你一开始就试图把边界划得很清晰，反而会学得很累。我现在的建议是：不要从名词出发，要从你的目标场景出发。想做知识问答就去摸RAG全链路，想做自动化流程就去拆Agent框架，想先找手感就从Prompt入手，用真实项目反推该学什么，比按教程顺序刷要高效得多。

2. Prompt方向：最像"人人可学"的赛道，水其实很深

2.1 教程盘点：从prompt engineering到prompt optimizer

Prompt方向的教程是最多的，也是质量方差最大的。粗分下来有三个流派，适合不同阶段的人。

第一个流派是结构化提示词派，教你用"角色+任务+上下文+格式约束+示例"的模板组织输入。这类教程适合完全没接触过的纯新手，一周内能跑通基本套路。但它的天花板很低，因为真实业务里的问题远不是一套模板能覆盖的，你会发现copy来的模板经常失效。

第二个流派是推理策略派，聚焦思维链、few-shot示例、self-consistency这些偏研究的玩法。这批教程会开始触及"模型为什么这样表现"的追问，质量普遍高一些，但需要有动手实验的耐心。第三个流派是工具化流派，围绕prompt optimizer、提示词管理平台、自动评测工具展开，适合团队协作和规模化落地的人。我比较推荐新手按"结构化模板打底 → 推理策略进阶 → 工具化沉淀"的顺序走，不要一上来就追求什么"万能提示词"，那东西不存在。

这里顺带提一句，2026年热词里的space bunny带火了端侧多模态推理这个话题，它其实也在改变Prompt的写法——以前提示词以文字为主，现在截图、流程图、音频都能作为输入的一部分。多模态提示词怎么写、怎么降噪，已经成了新的细分方向，但核心逻辑没变：说清楚你要什么，给出可校验的反馈信号。

2.2 绕不开的token和上下文长度：Prompt不是越长越好

调Prompt第一个要搞懂的概念就是token。模型不是按字数理解文本的，而是按token切分输入，一个token大致对应一个词的一部分或者一个汉字。搞懂token有两个实际用处：一是控成本，很多计费按token走，提示词写太长，调用成本线性上涨；二是防报错，超出上下文窗口上限后请求会直接被拒。

我见过不少人在prompt上栽跟头，就是因为它能塞的东西太多了。2026年的模型上下文窗口普遍到了百万token级别，很多人以为可以无脑丢一整个知识库进去，这是观念上的误区。长上下文不等于长记忆，更不等于好效果，相关性和信噪比才是关键。塞入过多无关内容，模型反而会"迷失在中间"，回答质量断崖式下降。我自己写Prompt的一条经验是：能让模型少读一个字就少读一个字，上下文是稀缺资源，不是垃圾桶。

关于报错，热词里那条invalid prompt: your prompt was flagged as potentially violating our usage policy，翻译成人话就是内容安全策略把请求拦截了。遇到别慌，先检查是不是触发了关键词规则，再检查是不是图片或特殊编码导致误判，把内容换成中性表达一般就能过。真正要防的是生产环境里用户输入不可控，这时候需要在应用层做输入过滤和改写，而不是干等模型服务商放宽策略。

2.3 Prompt调优的经典套路与"instruction闪退"排查

很多教程讲Prompt喜欢堆术语，什么zero-shot、few-shot、CoT、ReAct一长串，但实操里的调优路径其实很朴素。我一般按这个顺序排查：先确认任务定义有没有歧义，接着检查输出约束是否可校验，然后看有没有给出正反示例，最后再考虑用思维链还是分步拆分。大部分效果差的问题都出在前两步，根本轮不到上高级策略。

热词里的"prompt闪退"值得单独说一说。市面上说的闪退，大部分不是模型崩了，而是请求层面出了问题：一种是上下文超长被服务端拒绝，返回异常直接被客户端当成崩溃；一种是特殊字符、超长连续文本、重复token触发了服务端的防护逻辑；还有一种是免费API或代理层超时，本质是网络问题。排查时先看接口返回码，再看请求体里有没有乱码和二进制的字符，最后检查客户端有没有正确处理流式中断。掌握了这三个排查方向，比盲目换个提示词有用得多。

热词里还有一条"you can prompt the model to try again or start a new conversation if the err"，这是OpenAI接口常见的错误提示文案，意思是让用户重试或新建会话。它出现的原因通常是对话历史太长、服务端上下文溢出，或者是临时限流。处理办法很直接：要么压缩历史消息，要么按轮次截断，要么用摘要替代旧的对话记录，而不是真的让用户手动重开。

2.4 学到什么程度可以停

我的判断是，纯做应用开发的人，Prompt学两周就足够了，不需要花一个月去钻研提示词技巧。为什么？因为Prompt能解决的问题就那么大，它没法弥补模型知识的缺失，也处理不了多步骤的复杂任务。当你发现"提示词已经写得很好，答案依然不对"，说明问题不在Prompt层，该往RAG或者Agent那边走了。

真正值得深耕Prompt的是两类人：一类是做模型评测和数据集设计的工程师，需要精确控制模型输出行为；另一类是做AI产品交互设计的人，提示词模板就是产品逻辑的一部分。其余人停留在"能用、会调、懂排查"的水准，性价比已经拉满。这也解释了为什么网上那么多Prompt课程，但很少看到有人靠它落地出能挣钱的东西——它太容易被掌握了，掌握后又太容易被模型版本迭代抹平。

3. RAG方向：知识库工程才是真正的分水岭

3.1 教程盘点：从RAG实战到ontology RAG

RAG是2026年学习热度最高的一块，也是我认为最值得投入时间的方向。原因很现实：企业想用大模型，第一步几乎都是让模型理解自己的文档和数据，这条路绕不过RAG。

标准RAG实战教程的核心链路是：文档解析 → 分块 → 向量化 → 存入向量库 → 用户query向量化 → 相似度检索 → 注入Prompt → 生成答案。市面上的"RAG实战"教程基本都在讲这条链路，但讲得好不好差距很大。好的教程会告诉你分块策略怎么影响召回率、embedding模型选型怎么评估、向量库和传统数据库怎么配合；差的教程只会教你调用一个现成的RAG框架，跑通demo就觉得会了。

再往上走就是进阶方向。2026年的热点已经不只是基础RAG了，GraphRAG、ontology RAG、混合检索这类概念频繁出现在技术社区里。GraphRAG的思路是把文档里的实体关系抽出来构建知识图谱，用图结构辅助检索，解决"多跳问题"和"全局性问题"回答不好的痛点；ontology RAG更进一步，在检索之前先用领域本体约束信息的组织和关联方式。这些进阶玩法现在还比较硬核，但如果你要做垂直行业应用，比如医疗、法律、工业制造，它们大概率是绕不开的。

3.2 三种知识库别搞混：KG知识库、RAG知识库、结构化知识库

热词里有一条很典型的混淆："kg知识库、rag知识库和结构知识库区分以及应用场景"。这三样东西市面上经常被混着说，实际是完全不同的技术路线。

RAG知识库面向的是非结构化数据，比如PDF、Word、网页、聊天记录。流程是把文档切成块，做embedding，然后靠向量相似度做语义检索。它适合"用自然语言问文档"的场景，最典型的落地是智能客服、企业知识问答。缺点是检索结果是"相关片段"，不是精确答案，需要模型自己去整合，所以会有幻觉和被不相关片段带偏的风险。

KG知识库，也就是知识图谱，面向的是实体和关系。它把数据建模成"节点+边"的结构，比如"张三是李四的客户，李四的公司是某某科技"。图结构天然适合多跳查询、关系推理和一致性校验，比如"找出所有和A企业有合作、且合作金额超过100万的公司"。但建图谱成本很高，需要实体抽取、关系抽取、数据清洗，规模一大维护起来特别费劲。

结构化知识库则是传统的关系型数据库和数仓，按表结构组织，SQL一查一个准。它适合精确查询、统计分析和事务处理，比如"上个月订单量是多少，客单价多少钱"，这是向量检索和知识图谱都不擅长的。

现实里的企业级方案从来不是单选，而是混合架构：结构化知识库管事实和账目，KG管关系推理，RAG管非结构化文档问答，外面再套一个路由层，根据问题类型分发到不同引擎。这也是我推荐做RAG的人一定要补一点数据库和知识图谱概念的原因，纯向量检索撑不起真正的业务系统。

3.3 RAG的瓶颈到底在哪

热词里"rag瓶颈"这个话题值得花点篇幅说，因为它直接决定了你能不能把RAG项目做成，而不是做一个能跑但没用的demo。

我自己的体会是，RAG系统的瓶颈十有八九不在生成环节，而在检索环节。第一层瓶颈是召回不精准，文档分块太粗，垃圾信息跟着进来了；分块太细，语义被割裂，该召回的内容又召不回。第二层瓶颈是上下文污染，检索回来的片段里混了大量无关内容，模型被干扰，答案质量反而下降，这在专业领域特别明显。第三层瓶颈是评估困难，回答得好不好没有统一标准，你很难说清楚系统到底是变好了还是变坏了。

解决这三大瓶颈，有经验的团队普遍会做三件事：第一，做混合检索，把向量召回和BM25关键词召回结合，再让重排模型统一打分；第二，建评测集，挑几十上百个真实问题，人工标注标准答案，每次改动都跑一遍回归；第三，引入路由和意图识别，让简单问题走精确查询，复杂问题走图谱或长文本链路，而不是一个问题全系统都跑一遍。把这套体系建起来，你才算把RAG从"检索增强生成"做成了"知识工程基础设施"。

3.4 落地避坑：向量库选型、本地部署和免费API的坑

实操层面，有几个老生常谈但反复有人踩的坑。

向量库选型上，中小项目我建议优先用轻量方案，比如Qdrant或者PGVector，别一上来就上大规模分布式集群。很多项目的检索数据量可能连一百万条向量都不到，用重型组件纯属给自己找运维负担。等到真的到了千万级向量、QPS上来了，再考虑Milvus这类专业集群方案不迟。

Mac上搭建RAG知识库现在也很成熟，本地跑个大模型再配合SQLite+向量扩展完全够个人学习用。这里有个小建议：本地部署先把模型跑顺，再逐步换更强的embedding模型，不要一上来就追求生产级配置，很容易被环境问题劝退。

另一个坑是免费大模型API。免费API在学习和demo阶段确实香，但你要清楚它的限制：限流很严、高峰时段排队、数据不保证私有。最麻烦的是免费接口的报错不透明，经常出现前面说的invalid prompt这类安全拦截，却不给具体理由，排查起来非常耽误时间。如果项目要给别人演示，或者涉及业务数据，直接用付费接口或本地部署更省心——省下的时间远比你省的钱值钱。

还有一条热词问"rag知识库能存储图片嘛"，答案是能，但要理解存的是什么。RAG知识库不能直接"记住"图片内容，它存的是图片的向量表征和元数据。如果要让模型理解图片里的文字或物体，需要先做OCR、主体识别、caption生成，把这些派生文本拿去向量化，再存进知识库。所以图片进RAG的正确姿势是"图片 → 多模态模型抽取信息 → 文本/结构化数据 → 向量化 → 入库"，而不是把图片文件本身丢进向量库。

4. Agent方向：从Demo到可靠系统的鸿沟

4.1 Agent教程与框架盘点：从agent开发到agent架构

Agent是2026年最热、也最容易被高估的方向。我见过太多人拿着一个能调用搜索的脚本demo，就对外说"我做了个Agent"，实际上这只是个被包装过的工具调用函数。

现在主流的技术栈大致分两类：一类是低门槛的编排框架，比如LangGraph、CrewAI、AutoGen这一类，能帮你快速搭出多角色协作或多步骤流程；另一类是从模型层直接构建，自己管循环、工具、记忆和权限，灵活度最高但工程量也最大。还有一条热词是"agent anywhere"，我的理解是Agent能力正在被嵌入到各种既有产品里，从笔记工具到IM到IDE都有，这会让Agent开发逐渐从"搭一个独立系统"变成"在现有产品里加一个智能层"。

选框架时我的原则是：先看你的核心逻辑是"顺序流程"还是"动态决策"。如果流程基本固定，普通工作流引擎配上模型调用就够了，不需要Agent；如果流程需要模型根据中间结果做判断，再上Agent框架。上来就堆Agent框架，很容易把简单事情做复杂，维护成本暴涨。

4.2 先搞懂概念：harness和agent的区别

热词里有一条"harness和agent区别"，这是个特别好的问题，但大部分教程都没讲清楚。我尽量用大白话解释。

harness是Agent运行的"脚手架"和"运行时环境"，包括模型调用循环、工具注册表、上下文管理、错误处理、重试机制、权限校验这些基础设施。agent本身则是"决策主体"，负责理解任务、制定计划、判断该调用哪个工具、评估结果是否达成目标。一句话：harness是"身体"，agent是"大脑"。

为什么这个区分很重要？因为很多所谓的Agent项目，bug其实出在harness层，而不是决策层。比如调工具时上下文没清干净，模型把上一轮的中间结果当成这一轮的输入；再比如重试逻辑没写好，模型卡在一个失败的循环里烧token。这些问题是"身体"的问题，不是"大脑"的问题。我的建议是，初学阶段先用成熟的harness，把精力放在设计agent的行为策略上；等对机制熟悉了，再考虑定制自己的harness，才能在踩坑时准确判断问题出在哪层。

4.3 Agent最难的不是规划，是安全和成本

Agent demo跑通很容易，难的是让它稳定运行并且可控。这里面最核心的两座大山，一个是安全，一个是成本。

安全方面，最需要警惕的是prompt注入和权限放大。Agent能调用工具，意味着如果输入里藏了恶意指令，它可能被诱导去执行高权限操作，比如读取敏感数据、发送邮件、支付转账。2026年Agent越来越多地接入真实业务系统之后，这类攻击面只会变大。我的经验是：工具权限必须最小化，每个工具只暴露完成任务所必需的能力；凡是涉及外部可见操作，比如发消息、写库、下单，一律加人工确认的human-in-loop环节；Agent运行时的输入输出要做审计日志，出了问题能追溯。做Agent项目，安全设计要在第一版就进架构，别等出事了再补。

成本问题更隐蔽。Agent每次任务要多次调用模型，规划一次、调用工具一次、观察结果一次、修正再调用，一个简单任务可能烧掉几十万token。那些"Agent跑飞了"的案例，多半是循环没有终止条件或者重试没有上限。解决手段很简单：最高迭代次数设死、单轮任务预算设上限、复杂操作先做规划再批量执行、中间结果用摘要压缩上下文。我在项目里实测，光是把无界循环改成有界循环，成本能降一半以上。

4.4 企业级Agent：私有化部署、微调和"用什么模型足够"

企业落地Agent，绕不开部署和模型选型的问题。热词里"企业大模型私有化部署"和"工业ai检测、服装检测用云还是单机"都属于这一类。

私有化部署的核心诉求是数据安全和定制化。2026年的主流做法是本地跑开源模型，用ollama这类工具几步就能把模型拉起来，vLLM这类推理引擎负责高并发场景。但要提醒的是，部署只是第一步，后续的模型版本管理、GPU资源调度、推理加速、监控告警都要有人维护，否则系统跑不长久。

至于"用什么模型足够"这个问题，我的经验是三个约束条件做取舍：能力、速度、成本。工业质检这类对实时性要求高的场景，优先选轻量级端侧模型，哪怕能力弱一点，只要检测准确率达到业务要求就行；复杂文档分析和智能客服这类需要理解深度的场景，上大模型；介于两者之间的，用中小模型加适度微调来平衡。不要在能力上一味求大，也不要为了省成本让模型答非所问，核心是拿真实业务数据做评测，用评测结果定模型。

关于大模型微调，需要说清它和RAG、Agent的关系：微调解决的是模型"底子"的问题，比如输出风格像不像客服、格式符不符合规范；RAG解决的是"新鲜知识"的问题；Agent解决的是"干活流程"的问题。三者是互补关系，不是替代关系。一个成熟的AI应用往往是"微调定调性 + RAG管知识 + Agent控流程"。很多企业一上来就想微调大模型，其实先用RAG把知识库跑了，很多问题根本不需要微调就能解决。

5. 到底该先学什么：我给出的两条路线图和一套决策表

5.1 应用开发者的学习主线：Prompt → RAG → Agent

如果你是做应用、做产品的人，最终目标是"能落地可用的AI功能"，我推荐按Prompt → RAG → Agent的顺序走，时间分配大概是1:2:2。

第一阶段学Prompt，目标不是成为提示词大师，而是建立对模型行为的直觉。你要能判断"回答不对"是因为任务没描述清楚，还是模型能力不够，还是知识缺失。这个判断能力是后面一切工作的基础。时间控制在两周以内，别恋战。

第二阶段学RAG，这是应用开发者性价比最高的投入。学会解析和分块文档、搭一套最简单的向量检索、再把检索结果喂给模型生成答案。做完一个端到端知识问答项目，你就会对"模型和知识的关系"有切身体感。这个阶段大约三到四周，重点放在检索质量的评估上。

第三阶段学Agent，这时你已经理解模型能干什么、知识库能补什么，再去学怎么让系统自动完成任务，思路会顺很多。我的建议是从自动化流程入手，比如写一个能查天气、建日程、发邮件的助手，逐步加入工具调用、条件判断和循环。这个阶段没有固定周期，因为它真的是靠项目喂出来的，两个月能独立做出一个带工具调用的Agent，已经算学得很快了。

5.2 算法工程师和研究者的路线：基础理论 → 微调 → Agent

如果你本身有算法基础，或者目标是做模型侧的工作，路线完全不同：先补大模型基础理论，再学微调，最后才是Agent。

基础理论包括Transformer结构、注意力机制、tokenizer原理、训练目标和推理采样策略。这些看起来和业务没关系，但决定了你遇到问题时的定位能力，比如为什么同样的温度参数生成结果差别这么大，为什么某些格式任务怎么调prompt都不稳，根源都在模型机制里。网上讲这些的高质量课程不少，选有数学推导但不过分学院派的那种，两周时间能建立框架。

微调阶段，优先学LoRA和QLoRA这类参数高效微调方法。它们的思路是冻结原模型、只训练小的低秩适配器，训练成本低，效果在垂直领域立竿见影。2026年的开源模型生态里，这类微调工具链已经非常成熟，一套流程走下来你就能理解"模型的个性是怎么被数据塑造的"。

Agent对这个群体来说反而可以放到最后，因为Agent研究前沿还没有统一范式，等你在模型和微调上有了充分理解，再碰Agent的研究问题会更笃定。

5.3 按目标场景的推荐路线表

这张表是我处理咨询时实际会用到的判断框架。核心逻辑是：以终为始，别因为哪个风口热就先学哪个。Agent确实最炫，但如果你要做客服系统，没学会RAG就去学Agent，最后大概率要用Agent去补检索的窟窿，绕远路。

6. 筛选教程的三个笨办法

最后分享几个我筛选教程的土办法，不一定聪明，但这些年帮我省下大量试错时间。

第一，看教程有没有可复现的评测数据，而不是只有效果截图。一个教程如果通篇都在展示"看，多智能"的demo视频，却说不清楚在什么数据上测过、失败案例是什么，我基本会放弃。真正有价值的教程会告诉你"这个方法在某某评测集上召回率从60提升到75，但在长尾问题上仍然失效"，这种边界感比任何炫技都可贵。

第二，看教程是否覆盖成本和报错。2026年的大模型学习，成本管理和错误排查已经占了日常工作量的大头。如果一个RAG教程只字不提API费用和向量库运维成本，或者一个Agent教程完全没讲token失控怎么办，那它大概率是没做过生产环境的人写的。反过来，愿意花篇幅讲invalid prompt怎么排查、上下文超限怎么处理、token预算怎么控制的教程，作者往往是有实战经验的。

第三，看教程的发布时间是否跟得上模型换代。大模型领域半年就是一代，2026年还在逐字讲解2024年提示词套路的课程，直接跳过。但这并不意味着基础概念不用学，而是要区分什么是稳定的底层原理，什么是短命的技巧。RAG的分块和召回逻辑、Agent的循环和工具调用架构，这些是稳定的；某个模型的特定提示词模板、某个框架的最新API，这些是易变的。优先学稳定的东西，易变的按需查文档。

说回开头那个问题，Prompt、RAG、Agent到底先学什么——我这几年的体会是，不要试图做那个"全都懂了再动手"的人。真正学得快的人，都是先选定一个真实场景，把对应的那条线打穿，做出一个能跑的东西，再回头补另外两条线。大模型领域的更新速度根本不允许你从容地按教科书顺序学完再上岗，边做边补，才是最接近实战的学习姿势。