企业官网建设流程全解析

做智能大脑这件事，真正难的不是选一个“最强模型”，而是怎么把底座模型、记忆、知识库、工具调用和业务系统组织成一套能长期稳定运行的技术栈。Qwen和DeepSeek是我在模拟项目里用得最多的两组底座，前者中文指令跟随和工具调用非常稳，后者复杂推理和长上下文很有优势。这篇文章把我用这两个模型构建智能大脑的完整思路写下来，包括选型逻辑、分层架构、核心模块拆解、部署参数和排查记录，给正在从“单模型问答”往“系统级智能体”迁移的朋友做个参考。

这套方案适合谁？准备把大模型接进真实业务系统的开发者、已经跑通单一模型接口但总被“没记忆、答非所问、上下文爆掉”困扰的团队，以及正在纠结“Qwen和DeepSeek到底选哪个”的人。先说结论：真正好用的智能大脑，不是靠挑一个更聪明的底座，而是靠一套分工明确的技术栈。

1. 智能大脑的整体蓝图：先搞清楚技术栈里应该放什么

1.1 从“单模型问答”到“系统级大脑”，差的不只是模型

很多人一开始容易踩坑：觉得只要选一个聪明的模型接进来，系统就变聪明了。实际跑起来才发现，没有记忆、没法查内部数据、不能操作业务系统，模型就是一座孤岛。我也见过不少团队把Qwen系列接进聊天窗口，结果一问到具体业务数据就哑火，最后要么把答案硬编码进Prompt，要么靠人工复制粘贴，体验非常糟糕。

一个能落地的智能大脑至少需要解决四件事：知道用户问什么、记得上下文说过什么、能查到外部数据、能调用工具完成动作。这四件事对应到技术栈里就是模型层、记忆层、知识检索层和工具调用层。把它们组合起来才叫大模型技术栈，否则只是在用一个模型接口。

我习惯把整个系统类比成一个人：底座模型是大脑皮层，负责思考和表达；记忆模块像海马体，负责记住刚才聊过什么；知识库是随身携带的图书馆，随时查证；工具调用是手和脚，负责执行动作。任何一个环节缺失，这个人都会显得很笨。

1.2 技术栈的五层划分，每一层都解决一个具体问题

具体到项目里，我把技术栈分成五层：

• 模型层：Qwen系列、DeepSeek系列作为主要推理底座，另外配专门的embedding模型和rerank模型
• 编排层：Agent框架、任务路由、状态管理，负责把用户请求拆解成可执行的动作
• 记忆层：短期上下文管理、长期向量记忆、自动摘要
• 工具层：Function Calling定义、业务API接入、代码解释器执行
• 应用层：统一会话入口、权限控制、日志埋点、效果评估

为什么要分层？因为每一层都在独立演进。今天想换一个更聪明的底座模型，只需要改模型层的接入配置，工具层和应用层完全不用动；明天想新增一个查询工具，只要按既定Schema补一条定义就行。分层最大的价值是降低了“牵一发而动全身”的耦合风险。

另外，分层的系统才方便做评测。跑一轮回归测试，如果输出变差了，可以快速定位是模型版本变了，还是知识库召回变了，还是工具返回格式变了。这个能力在单模型加一大段Prompt的架构里几乎不可能实现。

2. 底座选型：Qwen与DeepSeek的区别和组合策略

2.1 不纠结谁更强，先看各自擅长什么

把Qwen和DeepSeek放在一起比“谁更强”是个伪命题，更合理的方式是先看任务类型。Qwen系列在中文对话、指令跟随、工具调用场景很稳，社区里的Agent案例大量跑在Qwen上，部署方案和周边工具都全，中小团队很快能跑起来。DeepSeek系列在复杂推理、数学、代码逻辑链上优势明显，面对多跳问题不容易中途“断开思路”，同时训练和推理成本控制得比较好，长上下文场景下也有优势。

我自己的实测感受是：要求“把一段需求拆解成三个步骤并安排执行顺序”，Qwen给出的结果工整、适合直接执行；DeepSeek会给出更深入的分析和备选方案，但偶尔会夹带较多思考性描述。不能简单说谁比谁好，只能说它们回答的风格和适用场景不同。

下面这个表是我做选型时的常用参考，注意它不是绝对的，具体还要看你的数据和部署条件：

这个表只是选型起点。真正做决定时要结合自己的场景跑一组评测问题，而不是看谁热度高。项目里要留一个评测集，至少准备30到50条真实业务问题，每次换模型都跑一遍，对比回答质量和格式合规率。

2.2 组合使用：用路由层把两个模型放进同一条流水线

既然两个模型各有优势，最自然的组合方式不是二选一，而是让路由层根据请求类型把任务分发给对应模型。我们项目里，简单的FAQ查询、日常聊天、工具操作对话走Qwen，因为它快、风格稳；复杂的多跳推理、长文档总结、代码调试走DeepSeek，因为它更适合慢下来思考。

路由听起来高大上，实现起来可以很朴素。早期用规则加关键词就能分类：请求里有“推导”“证明”“对比分析”“计算”“规划”这类词，就路由到DeepSeek；剩下的走Qwen。等日志数据积累多了，可以换一个小模型做意图分类，本质上也是把文本分类任务交给模型。

def route_query(query: str) -> str: reason_keywords = ["推导", "证明", "对比分析", "计算", "规划", "为什么"] if any(k in query for k in reason_keywords): return "deepseek" if detect_tool_intent(query): return "qwen" return "qwen"

有个心得非常重要：路由层不要做得太重。很多人一上来就上复杂的Agent规划框架，结果模型还没干活，路由先出问题。最初的版本只要做到“把明显需要深度推理的请求识别出来”就够了，剩下的默认走日常模型。等有足够日志和错误样本后再逐步优化路由规则。

组合使用的另一个好处是容灾。Qwen的服务因为模型版本更新出现抖动时，可以把流量切到DeepSeek，反过来也行。同一个请求在两个底座上各跑一遍做效果对比，也比只用一个模型更容易发现回归问题。这在实际长期运行中的价值比单纯“谁强用谁”大得多。

3. 记忆、工具调用与知识检索：三个让大脑真正能用的关键设计

3.1 记忆系统：短期上下文、长期记忆和摘要策略

没有记忆的智能助手，每轮对话都是“初次见面”。很多项目的失败点恰恰在这里：不加节制地把所有历史对话塞进上下文，结果窗口爆掉，模型开始答非所问。记忆系统至少要分两层：短期记忆管理最近N轮对话，长期记忆保存用户偏好、历史结论和关键事实。

短期记忆的建议做法是给模型上下文设置一个软预算。比如模型窗口是32K，可以只让对话历史占16K，留出一半给工具返回结果和知识库内容。每次组装请求时算一下当前历史有多少token，超过预算就把最老的几轮丢掉，或者转成摘要。别等上下文满了再处理，到那时已经晚了。

长期记忆我用“向量存储加摘要”的形式。不是把每轮对话都塞进向量库，而是当对话满足一定条件时，调用模型生成一段摘要，再写回向量库。比如用户提到“这个季度要重点优化转化率”，这就是值得存的信息。触发条件可以设计成：检测到新实体、出现决策性结论、对话轮数达到阈值。

这里给一个我常用的摘要提示词模板：

请把下面的对话压缩成一段不超过100字的用户画像或关键结论， 只保留对后续对话有价值的信息，不要重复已经知道的事实。 对话内容：...

这个模板看起来简单，但实际效果很好。关键是“只保留对后续对话有价值的信息”这句话，能帮模型过滤寒暄和无效信息。长期记忆不是越多越好，少而精准才是核心。

3.2 工具调用：先有结构化协议，再谈让模型“动手”

让大模型操作业务系统，靠的不是在对话里让它“直接改”，而是Function Calling机制。简单说，模型不是真正执行函数，而是输出一个结构化的调用请求，由程序去执行。Qwen和DeepSeek都支持类似能力，但具体到提示词模板和工具Schema的写法上会有差异。

以查订单为例，工具定义大概长这样：

{ "name": "query_order", "description": "根据订单号查询订单状态，包括物流信息、支付金额、创建时间。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "用户提供的订单号" } }, "required": ["order_id"] } }

注意description字段要写得足够详细，因为模型的工具意图识别主要靠它。不要只写“查询订单”三个字，要写清楚这个工具在什么情况下使用、参数格式是什么。我见过很多工具调用失败案例，根因都是description太简略，模型根本不知道什么时候该用这个工具。

程序拿到模型输出的结构化调用请求后，执行实际逻辑，再把结果作为一条消息拼回对话上下文，让模型基于结果生成最终回答。这个闭环里有三个容易出错的地方：一是模型输出JSON不合法，二是工具执行失败后模型“将错就错”编造结果，三是没有限制工具返回长度导致上下文被撑爆。

我的兜底建议：解析JSON时不要直接一把梭，先用正则提取代码块里的JSON；工具执行失败时明确告诉模型“该工具调用失败，请基于已有信息回答，不要编造结果”；工具返回结果进入上下文之前做好截断和字段筛选，只保留关键信息。

3.3 知识检索：给智能大脑外挂一个专业资料库

大模型的知识截止时间有限，专业领域数据也不在预训练范围里，所以RAG基本是智能大脑的必选项。RAG的流程并不复杂：文档切块、向量化、召回、重排、把结果拼进Prompt。但细节非常多，每个环节都会让答案质量出现明显波动。

先说切块。很多人直接把PDF按固定字数切，两刀下去把一个完整概念切成两半，检索出来自然缺胳膊少腿。更稳妥的做法是按文档结构切：先按标题分章节，再按段落分块，块与块之间保留少量重叠。我常用的参数是chunk_size设256到512 token，overlap约50 token，既能保证语义完整，又不会让索引过大。

再说向量化。中文场景下，embedding模型的选择比很多人想象的更重要。一个针对英文优化的向量模型，遇到中文长句时匹配质量会明显下降。建议先用几组同义问题做召回测试，看看排序结果是否合理，别只盯着公开评测分数。

召回后的重排层值得单独说。初筛召回20条，直接全部塞进Prompt既浪费token又引入噪声，用rerank模型重排后只保留前3到5条，回答准确度会明显提升。重排层计算量不大，但收益非常明显，应该作为标配而不是可选优化。

最后是Prompt组装。把召回结果拼进提示词时，要告诉模型“以下内容来自知识库检索结果，如果与问题无关，请明确说不知道”。同时给每条结果加一个来源编号，让模型在回答时能引用，方便人工审计。这不仅能降低幻觉，还能让用户看到答案有据可查。

4. 本地部署与编排层实现：我跑通一套智能大脑的实操记录

4.1 模型服务部署：vLLM与量化选型

模型要落地，离不开推理服务。推理框架我用得最多的是vLLM，吞吐量和显存控制都比较好，适合同时服务多个业务请求。Qwen系列的较小尺寸模型可以直接加载运行，DeepSeek系列因为参数量更大，需要重点考虑显存和量化方式。

启动命令大致如下：

python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen-7b-instruct \ --served-model-name qwen-brain \ --max-model-len 32768 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85

几个关键参数说一下。max-model-len是最大上下文长度，设置成32K不代表每次都占用这么多，而是给了一个上限，但不要盲目设大，否则KV Cache会吃掉大量显存。tensor-parallel-size是张量并行数，只有单卡显存不够时才需要多卡分摊。gpu-memory-utilization控制在0.85左右，别顶满，留点余量给偶发的显存峰值，不然高并发时容易OOM。

量化方面我踩过“无脑上量化”的坑。如果显卡能跑FP16或BF16就不要急着量化，因为量化一定会带来精读损失。只有在显存确实捉襟见肘，或需要提高并发时，再考虑AWQ或GGUF。AWQ对生成任务更友好，GGUF可以用CPU和GPU混合部署，但速度和精度都要实测之后再决定。

还有一个容易被忽略的点：服务上线前一定要压测。不要一上来就接业务流量，用脚本模拟并发请求，观察P95延迟和显存变化。我见过有人只测了单请求延迟，一上生产并发就超时，原因是并发时KV Cache占用的显存翻倍增长，直接打爆显存。

4.2 编排层的代码骨架：怎么把路由、记忆、工具和RAG串起来

编排层是整个智能大脑的中枢，我习惯用一个统一入口串联各个模块。下面是精简骨架，真实项目里会在此基础上加日志、异常处理和权限校验，但核心结构不变：

class Brain: def __init__(self, config): self.router = Router(config.router) self.memory = MemoryManager(config.memory) self.rag = RAGEngine(config.rag) self.tools = ToolRegistry(config.tools) self.llm = LLMClient(config.llm) def chat(self, user_id, query): history = self.memory.load(user_id) search_results = self.rag.search(query) model_name = self.router.route_query(query) messages = self.llm.build_context(history, search_results) response = self.llm.call(model_name, messages, tools=self.tools.schemas()) if response.tool_calls: tool_result = self.tools.execute(response.tool_calls) messages.append({"role": "tool", "content": tool_result}) response = self.llm.call(model_name, messages) self.memory.save(user_id, query, response) return response

这段骨架的核心思想只有一个：所有模块都通过统一的客户端和Schema连接，切换模型只需改配置。比如把某个任务的模型从qwen-brain切到deepseek-brain，只需要改路由配置，业务代码完全不用动。这个特性在模型快速迭代的阶段非常重要，能随时切换才敢持续优化。

注意，上面的骨架里我故意没有把“记忆保存”放在模型回答之前，因为记忆保存要依赖最终回答的完整上下文。实际操作时要做两件事：保存用户问题，保存系统回答，方便后续做效果评估和日志审计。

编排层还有一个职责是兜底。假如模型调用超时，或者工具抛了异常，系统必须返回一个面向用户的友好提示，而不是把异常堆栈直接甩给前端。这个兜底逻辑看起来不起眼，但在真实业务里的价值比任何高深的Prompt都大。

5. 排查实录：上下文爆掉、工具调用失败与成本失控这三座大山

5.1 上下文爆掉与幻觉：最常见的两类质量事故

先说上下文爆掉。现象很典型：对话到第10轮之后，模型开始忘记最开始说了什么，甚至答非所问。排查方法不复杂，把每次请求发出的token数记录下来，看是不是接近窗口上限。如果是，说明历史消息没有做滑窗或摘要，直接把最近10轮全塞进去了，哪有不爆的道理。

解决办法刚才提过：给上下文设软预算，历史只占窗口一半；超预算内容先转成摘要再决定保留还是丢弃。另一个容易被忽视的点是工具返回结果也占token。我遇到过一次性把整个订单列表几百条数据扔给模型的情况，直接把上下文撑爆。后来给所有工具结果统一加了截断和字段筛选，问题立刻改善。

幻觉问题则是另一座大山。模型一本正经地编造订单、虚构政策条款，原因大多是知识库里没有对应内容，但Prompt没有约束模型的“不知道边界”。处理分三步：一是在Prompt里明确写“如果知识库中没有明确依据，请回答不知道”；二是把检索结果和来源编号绑定，模型只能基于检索内容作答；三是把temperature调低到0.2左右，减少自由发挥空间。

这里有个更隐蔽的坑：检索结果明明存在，但模型还是会偏离它去讲自己的“常识”。这时候不要只怪模型，看看Prompt是否把“检索结果”和“闲聊内容”混在一起。我的做法是给检索内容单独加标签，比如用<knowledge>...</knowledge>包起来，并告诉模型“只有标签内的内容可以作为事实依据”。上下文爆掉和幻觉，本质上都是“输入结构和预算失控”，先管理输入，再谈优化模型。

5.2 工具调用失败与知识库命中率低：从日志里找根因

工具调用失败最讨厌的点在于，它不是每次都失败，而是随机失败，很难复现。常见情况有三种：模型没在结果里输出tool_calls、输出的JSON格式不合法、工具执行失败后模型继续编造答案。排查第一步是看日志里模型原始输出是什么样，而不是直接怀疑模型不行。

如果模型经常不输出tool_calls，先检查工具Schema的description是否足够清晰，有没有给出触发条件。如果JSON经常不合法，大概率是提示词里的格式约束不够，可以在system prompt里加一句“你必须输出严格的JSON，不要包含Markdown代码块标记”。如果工具执行失败后模型还在编，就要在Prompt里显式声明“工具调用失败后，请回复用户无法完成操作，绝不猜测结果”。

知识库命中率低的问题，很多人的第一反应是换更强的模型，方向其实错了。命中率低要去查检索链路：切块是不是破坏了语义完整、embedding是不是中文优化、召回top_k是不是太小、重排有没有加。可以单独做一个“检索命中测试”，用20个真实问题检查召回结果是否包含正确答案。

我调过最久的一次案例，最后的根因是：文档里同一个概念有多种叫法，用户问的是A叫法，文档里写的是B叫法，向量召回匹配不上。解决办法很朴素：在元数据里维护一批同义词和别名，做检索时进行query扩展。这类问题换再大的模型也解决不了，只能在知识工程层面下功夫。

5.3 成本与延迟控制：让智能大脑跑得起长期业务

智能大脑上线之后，最痛的往往是账单。不做控制的话，每个请求都把几十轮历史和二十条检索结果丢给模型，token消耗会非常快。我的做法是给每个请求建立token预算表：历史占40%，检索结果占20%，工具返回占20%，输出预留20%。哪一块超了就先压缩哪一块。

路由策略对成本的影响也很大。简单任务用小模型，复杂任务才用大模型，这个道理大家都懂，但落地时要敢“多分流”。给“走Qwen还是DeepSeek”加一个简单阈值逻辑：普通问答直接走Qwen，识别到需要深度推理的关键词或问题复杂度评分高时才切DeepSeek。这在我的项目里让DeepSeek侧调用量下降了接近一半，成本也随之下降。

缓存策略值得认真对待。至少两层缓存：一是相同system prompt的前缀缓存，避免重复计算KV；二是相同问题的结果缓存，常见FAQ可以不经过模型直接命中缓存返回。对在线业务来说，结果缓存不仅省钱，还能让P95延迟断崖式下降。

最后提醒一点：度量要先行。从第一天起就给每次请求记日志：模型名、输入token、输出token、耗时、路由决策。建立一张简单的成本看板，每天看一次。没有度量，成本控制全是拍脑袋；有了度量，哪怕费用突然涨了，也能逐层排查是哪个环节出了问题。

这套架构在我自己的模拟项目里跑了好几个月，最大的体会是：模型能力只是起点，真正决定智能大脑好用程度的，是记忆、知识、工具和编排之间的耦合是否顺畅。Qwen和DeepSeek各有各的长处，与其花时间争论哪个更强，不如把它们放进同一条流水线，让各自干最擅长的事。今天能快速切换底座模型，明天能加一个新工具，后天能换一套知识库，这样的系统才算得上真正意义上的智能大脑。如果这篇文章能帮你在选型和调试时少走几步弯路，那就不亏。