企业官网建设流程全解析

2025年最后一天，我一个人坐在工位前翻GitHub提交记录，从1月的“feat: init project”到12月的“fix: 评估集标注错误”，一整年攒了三千多次commit。年初写技术规划时，我把Agent、RAG、微调、多模态全塞了进去，觉得2025年是大模型应用全面爆发的一年，不抓紧上车就晚了。现在回头看，真正留下来的不是那些炫酷的Demo，而是一堆踩坑记录、几套勉强能跑的评估脚本，和一些关于“技术到底怎么落地”的清醒认知。

这篇年度总结没有代码仓库可以clone，也不是什么行业报告。它更像是我作为一线开发者，把过去一年在AI应用落地过程中遇到的真问题、犯过的错、改对的方式，原原本本摊开来聊聊。如果你是做工程、做AI应用、带技术团队或者独立开发的人，这篇文章里记录的经验大概率能帮你少走几个月的弯路，尤其是Agent项目复盘和RAG评估那两段，建议直接收藏。

1. 2025年的技术主线：从“追新词”到“看指标”

1.1 上半年与下半年的两种技术气候

2025年上半年，整个技术圈还弥漫着上一年的惯性热情。几乎每一个技术社区都在讨论“Agent会不会取代软件”“多少个Agent能组成一家公司”这样的问题。很多团队立项时已经不再问“要不要用大模型”，而是问“用几个大模型、跑多少个Agent”。我也身处其中，上半年带着团队做了一个客服Agent项目，当时以为三个月就能上线，结果到7月还在调评测指标。

下半年风向突然变得务实起来，大家开始冷静地关心成本、延迟、准确率和误报率。这种转变不是某一天发生的，而是当第一批Agent项目带着漂亮的Demo视频走进真实业务环境之后，所有人都被现实教育了一遍。行业里开始流行一句话：“大模型应用的上限是模型决定的，下限是工程决定的。”这一年，我见过太多项目死于下限。

1.2 大模型应用从“能不能做”变为“值不值得做”

2025年，“能不能做”已经不是核心问题。以文本生成、摘要、分类、信息抽取为代表的基础能力，几乎被主流模型覆盖得很完善。真正难回答的是“值不值得做”——投入一套RAG或Agent系统，运维成本、评测成本、数据治理成本摆在那里，换来的准确率提升和用户体验改善是否划算。

以我自己经常被问到的“客服问答机器人”为例。如果只是做FAQ检索，用一个向量数据库加一个中等规模的模型，成本只相当于以前的三分之一，效果还更好。但如果要做多轮对话、带情绪识别、能够自动执行退款或改签动作，那工程量至少翻五倍。前者是“值”的，后者就要慎重评估了。

1.3 真正进入日常的AI基础设施

这一年的关键词里，MCP（Model Context Protocol）绝对绕不开。它把模型与外部工具之间的交互标准化了，就像当年HTTP标准化了网页访问一样。以前接一个内部工具，要给模型写一堆函数调用描述，还要处理各种格式不统一的问题；现在定义几个MCP Server，配置好权限，模型就能直接调用。这个变化让我手上的项目集成效率提升了至少一个量级。

推理成本也在这一年大幅下降。2024年跑一个大规模RAG服务，算下来每个月GPU账单心惊肉跳；到了2025年下半年，通过量化部署、小模型蒸馏、缓存命中优化，同样的业务场景成本能压到年初的三成。技术指标上，首token延迟从曾经的“不可用”降到可以接受的水平，吞吐量也有了明显提升。这些看起来不那么性感的基础设施改进，才是2025年AI应用能真正铺开的原因。

2. Agent项目复盘：上半年有多激动，下半年就有多清醒

2.1 项目背景与目标：客服助理Agent

年初，我们接到一个业务需求：给一家电商平台的客服团队做一个智能助理，不是简单的问答机器人，而是能帮忙查询订单、解释售后政策、必要时发起退款流程的Agent。目标很明确——把人工客服处理一次会话的平均时长从8分钟压到4分钟以内。

当时团队的信心很足。模型能力够强、工具调用生态也成熟了，MCP都已经在社区铺开，理论上这个项目毫无难度。我们规划了四层结构：会话入口、意图路由、工具调用、兜底回复。从架构图上看非常完美。

2.2 第一个致命问题：没有设计“困难集”

项目启动后的前两周，我们只做了一件事：拿模型直接跑历史客服会话，然后人眼观看效果。当时觉得效果还行，客服主管也表示“能看懂用户在说什么”。于是我们直接进入prompt工程和工具开发阶段，完全没有建立一套正式的评测集。

到了第三周，问题开始出现。用户问“我昨天买的那个蓝色的杯子什么时候发货”，模型确实能识别出意图，但系统把“蓝色的杯子”匹配到了一个不存在的商品编号上。这种例子多了以后，我们意识到没有困难测试集的评测纯属盲人摸象。后来我们花了整整一周时间，从历史会话里挖出一千多条“困难问题”，专门覆盖模糊表达、隐含商品信息、售后政策边界等场景，再拿这批数据重新跑评测，结果系统准确率从表面的90%掉到了真实水平的63%。

这个教训我记了一整年：**任何大模型应用项目，第一优先级是建立评测集，而不是调prompt。**没有评测集，你看到的“效果不错”只是幸存者偏差。

2.3 第二个致命问题：上下文窗口不等于记忆

项目的第二个大坑，是把模型的上下文窗口当成了记忆。当时主流模型的上下文窗口已经能做到128K甚至更长，我们天真地以为把所有会话历史都塞进去，模型就能完美记住前因后果。实际上，当对话超过二十轮、历史里夹杂着商品链接、订单快照、政策条文这些信息时，模型的注意力严重分散，它记不住最关键的“用户当前到底要干什么”。

我们做了一个小实验：构造二十轮对话，在第21轮问一句“我刚才说要退货的是哪一件商品”，让模型回答。结果准确率只有57%。后来把商品信息做成结构化状态，每次只传递关键信息，放弃“全文搬运”的做法，同样的问题准确率到了96%。这个对比让我明白了一个朴素的道理：**上下文窗口是存储，不是记忆。**要想让Agent记住重要信息，必须设计显式的状态管理，就像人不会背下整本聊天记录，但会拿笔记下重要事项。

2.4 第三个致命问题：Agent自主度给得太早

项目进入第五周，我们开始让Agent自动执行退款操作。前期测试做了权限模拟，看起来没问题。结果一上灰度，出现了一起事故：用户说“这个商品我不要了，你们自己看着办”，Agent真的去执行了退款。严格从用户语义上看，退款指令并不明确，但Agent在一连串推理里选择了“最合理的操作”。业务方直接叫停了灰度。

复盘后我们加了两道保险：第一，高风险动作（退款、改地址、补发）必须经过人工确认；第二，Agent的自主度分级——L1只能查不能改，L2可以改但需要二次确认，L3才能自动执行，并且L3只开放给经过大量测试的高置信场景。后来又加了“对话语义置信度阈值”，低于阈值的操作一律转人工。这一改动让系统的安全事件从每周十几起降到了零。

2.5 复盘后的重构方案

8月，我们完成了这个项目的重构。最终架构和年初的设想已经有了很大区别：不再追求让Agent“无所不能”，而是划定清晰的决策边界。核心查询走RAG，复杂动作由工作流编排，Agent只处理边界内的灵活对话，一旦超过边界就优雅地交给人工。这个“优雅”很关键——用户不会觉得自己被扔给了机器人，而是觉得机器人知道自己搞不定，正在找专业人士帮忙。

重构后的系统，平均处理时长从8分钟降到了4分半，虽然没有达到4分钟的目标，但用户满意度反而提升了。原因很简单：以前人工客服被大量简单问题拖住，真正复杂的咨询得不到及时响应；现在简单问题被Agent分流，人工客服的精力能放到真正需要人的地方。

3. RAG落地最耗神的一环：检索质量评估与知识库治理

3.1 为什么先做评估再做优化

下半年接手了一个知识库问答项目：把企业内部的制度文档、产品手册、FAQ整合成一个问答系统。这个项目让我把RAG从里到外摸了一遍，也彻底改变了我对检索质量的看法。很多人以为RAG的核心是把文档切成小块、灌进向量库，然后用相似度检索top_k就完事了。但实际上，检索质量上不去，后面接什么模型都白搭。

我踩的第一个坑就是不做评估直接优化。当时觉得模型生成的结果看起来不错，直到业务方拿了一个特别刁钻的问题来问：“员工年假在入职当年按比例折算吗？”系统答非所问。后来一查，知识库里关于年假的文档有十几份，向量检索召回的第一名是一篇提到“年假”但根本没讲折算比例的旧公告，真正的政策文件排在第七位。

3.2 评估集构建：从真实会话里挖

RAG的评估集和模型评测集不一样。模型评测集关心模型本身的知识能力，RAG评估集关心的是“给定文档集合后，系统能不能找到并生成正确的答案”。我采用的评估维度有三个：检索召回率（Recall@K）、答案忠实度（Faithfulness）、答案有用性（Answer Relevance）。

评估集怎么来？我没有用网上公开的数据集，而是从企业真实的使用场景里挖。把过去一年客服和员工咨询的量整理出来，挑出一千个有代表性的问题，再请业务专家给每个问题标注标准答案和答案所在的源文档位置。这个过程很辛苦，但效果非常明显——后来每次升级模型或调整切片策略，我都能在半天内跑出一份完整的回归报告，而不是靠感觉说“好像效果变好了”。

3.3 知识库治理的三个易丢分点

第一个丢分点是切片切坏了语义。一开始用固定长度（512字符）硬切，结果一个完整的政策条款被切成了两半，检索时只召回了一半，模型看到的信息不完整。后来我彻底放弃了固定长度切片，改成了“按标题结构+段落语义”切。具体做法是：先按文档的标题层级分块，再在块内按段落边界和句子边界微调，每一片控制在500到1000字左右。这个改动单独让Recall@5提升了将近10个百分点。

第二个丢分点是知识库里有大量重复和过期内容。我们导入了三年的公告和制度修订版，旧版本并没有下线。结果用户问“报销标准是多少”，系统经常召回旧政策。后来给知识点加了生效日期和版本号，检索时优先召回当前生效版本，问题才解决。

第三个丢分点是相似标题的歧义。“请假流程”和“请假审批”听起来差不多，但内容完全是两回事。光靠向量相似度很难区分这种语义和字面的错位。后来我在索引里加了标题实体标记，检索时对标题匹配结果做加权，歧义问题有了明显改善。

3.4 混合检索：一个“老词”在2025年的新意义

混合检索（稀疏检索+向量检索）不是什么新技术，但在2025年RAG应用里，它的价值被重新放大了。向量检索擅长语义相似的模糊匹配，BM25这类稀疏检索擅长精确词匹配。实际使用中，员工问“考勤异常怎么处理”，文档里的原话可能是“员工打卡异常管理办法”，向量检索大概率能搞定；但如果问的是“APP打不了卡”，文档里恰好有“APP打卡失败”这个关键词，BM25反而更能精准召回。

我的做法是两块并行召回，再用一个Reranker做融合排序。第一次上线时我没有加Reranker，只是简单把两个结果去重合并，虽然召回率不错，但排序不够准，Top1经常不是正确答案。加上一个轻量级Reranker模型后，Top1准确率从68%提升到了79%。这个提升看着不大，放到真实问答场景里，用户体感差异是肉眼可见的。

检索参数方面，我最终采用的效果较好的一组配置是：向量检索TopK=20，BM25 TopK=20，Reranker重排序后取Top5喂给生成模型。有人觉得TopK拉大是不是更慢？实测下来，多花的时间不到50毫秒，换来的是准确率提升和漏召回概率下降，性价比非常高。

4. 大模型本地部署与微调：一年里踩得最实的硬成本

4.1 部署选型的真实对比：Ollama、vLLM、推理服务

2025年，本地部署和微调不再是大型企业的专利，个人开发者和中小团队也能跑起来。我前后在几个项目里试过不同部署方式，这里直接说结论。

Ollama适合个人开发和轻量Demo，一条命令就能拉起一个模型服务，支持OpenAI兼容接口，开发时用起来非常顺手。它的问题也很明显：大规模并发下吞吐量不够，不适合生产环境。我们一个内部工具用Ollama扛了两个月，到了每天几千次请求时明显顶不住，后来切到了vLLM。

vLLM在吞吐量上确实强很多，显存利用率也高。我用vLLM部署Qwen系列模型，吞吐量比Ollama提升了将近四倍。代价是配置和学习成本更高，需要自己管理模型权重、配置量化参数、处理显存调度。如果你想在生产环境里跑开源模型，vLLM基本是绕不开的。

还有一类是托管推理服务，无论是各大云平台提供的还是开源社区自建的，优势在于不用运维底层基础设施。对于没有GPU资源的小团队，这是最现实的选择。但如果要把模型部署到私有网络环境，或者对数据出域有严格要求，本地部署仍然是刚需。

4.2 量化与上下文长度的权衡

本地部署时，量化是最常被提起的词。FP16、INT8、INT4、AWQ、GPTQ，这些名词看起来复杂，本质只有一个：用精度换显存。我做了很多次对比实验，在业务场景里，INT8量化几乎无损，INT4在某些任务上会有可感知的下降。我的建议是，如果你的显存刚好能塞下INT8，就别为了省显存去用INT4。

还有一个很容易被忽略的点是上下文长度对显存的影响，长上下文不是免费的。官方宣称支持128K上下文，那是理论值，实际跑到64K时KV Cache占用的显存可能已经超过模型本身。我在一个项目里部署7B模型，FP16权重占14G显存，看起来没问题；但把上下文窗口从8K拉到32K后，显存直接爆了。后来改用了GQA（Grouped Query Attention）优化的模型，KV Cache显存占用才降下来。

4.3 LoRA微调：什么时候真的值得

2025年，很多人还在纠结“要不要微调”。我自己的经验是：**大多数业务场景不需要微调。**提示工程加RAG能解决八成需求，微调的成本和风险都不小。

但有一类情况微调非常值——领域术语密集且格式要求固定的场景。比如法律文书的摘要模板、医疗报告的结构化输出、代码仓库的注释规范，这类任务如果只靠prompt约束，模型经常出现格式漂移。我用LoRA在Qwen-7B上做了两次微调实验，训练数据大概是两万条领域样本，单卡A100训练时间约八小时。效果很明显：JSON格式输出合法率从88%提升到了99.5%，关键实体识别的F1分数也提升了四个百分点。

LoRA训练里最值得注意的坑是数据质量。很多人觉得模型效果上不去是参数没调好，实际上绝大部分是训练数据太脏。如果训练样本里字段抽取错了一半，模型学到的只会是把错误模式固定下来。我清理数据花的时间是训练时间的三倍，这个比例在行业里很正常。微调不是“喂得越多越好”，而是“喂得越准越好”。

4.4 数据合规与迭代闭环

2025年做模型落地，数据合规是绕不开的一环，任何人都必须认真对待用户隐私和敏感信息。做本地部署的一大优势就是数据不出域，这也让很多企业愿意把模型部署在自己的机房而不是云上。但我们内部仍要对所有训练数据做脱敏处理：手机号、身份证号、地址等信息在进入训练流程之前必须完成匿名化。

关于迭代闭环，我的体会是：模型部署上线不是终点，而是起点。每次跑完一轮评测，都要把错误Case收集起来，分析是数据问题、检索问题还是模型问题，然后针对性修复。2025年下半年，我几乎每周都在重复“跑评测—看错误—改数据—重训练—回归”这个循环。看起来繁琐，但这才是AI应用真正稳定可靠的原因。

5. 年度选型印象：哪些技术留在了牌桌上

5.1 MCP为什么成了事实工具协议

2025年年中，MCP在开源社区和支持度上快速上升，年底时基本上已经成为大模型工具调用的事实标准。原因不难理解：它把“模型与工具的交互方式”标准化了，生态里的服务端和客户端可以即插即用，这和省去大量重复开发的收益相比，实在太有吸引力。

我们团队内部原来有一套自研工具协议，每次加新工具都要写一遍描述文档和鉴权逻辑。接入MCP之后，新工具注册只需要几步配置，整个上手时间从一两天压缩到半小时。这不是说MCP完美无缺，安全边界、权限管理还在演进，但它的方向是对的。如果2026年你要新起AI应用项目，我建议优先考虑支持MCP的框架。

5.2 RAG vs 长上下文：不是二选一

很长一段时间，朋友圈里都在争论“有了长上下文还需要RAG吗”。我的答案是：两者解决的是不同的问题。长上下文能让你把更多资料塞给模型，但代价是成本高、注意力分散；RAG能精准召回最相关的片段，但依赖检索质量。成熟的方案是两者结合：RAG负责定位最相关的信息，长上下文负责容纳多轮对话和必要的历史信息。

我们后续的架构基本定型为：短期历史用对话状态存储，知识点问答走RAG召回，遇到跨文档综合分析时再把多个召回片段拼接进长上下文。这样既控制了成本，又保证了效果。

5.3 微调 vs 提示工程 vs Agent：按成本排序

2025年技术选型的核心不是选“最先进的”，而是选“最划算的”。我给自己定了一个决策顺序：**先提示工程，再RAG，再微调，最后才是Agent编排。**每一步都有明确的判断标准：提示工程解决不了的，看RAG能不能通过补充知识解决；RAG解决不了的，看微调能不能让模型适配特殊格式；微调还不行，再考虑用多步Agent编排把复杂任务拆解掉。

这个顺序帮我省了很多钱，也少走了很多弯路。上半年有几个项目一上来就想上Agent，最后都因为状态管理、评测复杂度过高而延期；下半年老老实实从简单方案做起，反而更快到达了可用状态。

5.4 对于2026年的预判

基于一年下来的观察，我个人的预判是：Agent会从“主动执行”回归到“辅助人类”的定位，工作流编排的价值会进一步凸显；多模态应用会从小众实验变成常规需求；模型的推理能力继续增强，但工程化的重心会转向评测自动化、可观测性和安全护栏。2026年最稀缺的能力，可能不是会调模型，而是能设计出清晰、可评估、有边界的AI应用架构的人。

6. 一年下来，真正改变工作方式的四个习惯

6.1 从“能跑起来”到“能复现”

2025年之前，我习惯在Notebook里验证环境，代码能跑通就算完成。今年被Agent项目狠狠地教训了一次之后，我彻底改掉了这个毛病。现在每一个效果验证都有完整的记录：模型版本、推理参数、数据版本、评测脚本、随机种子，全部锁死在配置里。这样一次修改产生的效果波动，能够清楚地追溯到是哪一环引起的。

有一回同事调整了prompt里一个标点符号，离线评测分数涨了两个点。但在复现的时候，我们换了批量化参数，分数反而跌了。最终查下来是采样温度设置不一致导致的。这种“神秘波动”在AI应用里很常见，但通过固定版本和参数，能让它从玄学变成可解释的技术问题。

6.2 给上下文留痕：新项目的AI协作粘结剂

2025年，AI辅助编码已经成了日常。但高效使用AI协作的前提是，给足上下文。我开始在项目里维护一个简洁的技术上下文文档，内容包括项目背景、核心流程、数据结构、依赖关系、已知坑点。这个文档不是给人类同事看的，而是给AI辅助工具看的。

效果非常明显。以前问AI“这段代码怎么改”，它给的建议经常是泛泛而谈；把上下文文档丢给它之后，回答质量完全是另一个量级。有个同事半开玩笑说，这已经成了我们团队新的“入职培训材料”。我觉得这背后其实是思维方式的变化：与其抱怨AI不懂业务，不如主动把业务知识结构化，这本身就是工程能力的体现。

6.3 数据意识：模型效果的上限由数据决定

这一年反复验证了一个道理：**数据质量决定体验上限。**无论用多强的模型，输入数据的质量不行，系统就永远达不到预期。具体到RAG就是知识库治理，具体到微调就是训练数据清洗，具体到评测就是评估集的代表性。

下半年我养成了一个习惯——每次模型表现不符合预期，第一反应不是换更大的模型，而是去看数据：是不是知识库缺了关键文档？是不是评估集里有一条标注错了？是不是训练样本里混入了噪声？这个转变得到了很多次正向反馈，也节省了不必要的计算成本。

6.4 团队协作：少开技术会，多跑评测脚本

2025年技术团队最容易出现的争论是“我的方案效果好”，但没有任何依据。下半年我们调整了做法：每次方案改动，必须附带评测脚本和跑分结果；开会讨论时先跑一遍回归测试，再讨论具体设计。这不只是流程变化，更是一种文化转变——用数据做裁判，而不是用嗓门和资历做裁判。

这套做法落地后，团队里关于“该不该升级模型”“该不该调整切分策略”“要不要加一个Agent工具”的争论都变得高效了很多。大家不再凭感觉争辩，而是先跑一轮评测再说。我相信这个习惯在2026年会继续带来回报。

最后，关于2026年的一点个人预期

回看2025年，我最大的收获不是学会了多少个新工具，而是终于想明白了一件事：AI应用开发的核心不是AI，而是应用。模型能力会越来越强，但真正决定项目成败的，是围绕它建立的评测体系、数据工程和系统边界。

如果你也在做AI应用的落地，我的建议很朴实：先建评测集，再谈效果；先做简单方案，再想复杂架构；先管理好数据，再去调模型。这些话听起来不性感，但实践中真的能保命。2026年，我计划继续沿着这个思路往前走，把评测自动化和可观测性做得更扎实一些。

希望这些经验对你有用。有任何问题欢迎在评论区交流，尤其是RAG评估和Agent状态管理相关的坑，我很想听听你们是怎么解决的。