企业官网建设流程全解析

1. 家庭智能新形态：为什么是 HomeAgent 而不是又一个 App

这两年智能家居赛道最大的尴尬，是硬件堆料越来越猛，但用户体验始终在原地打转。手机里装七八个 App，每个 App 对应一个生态，灯光一个、窗帘一个、安防一个，语音助手各喊各的，设备之间基本靠用户当人肉网关。我家里那套智能设备就是典型——买的时候每个单品都挺聪明，连在一起就集体降智。

所以当“后摩智能×绿联 HomeAgent”这个组合出现的时候，我第一反应是：终于有人开始从芯片和系统的角度，而不是从单品 App 的角度来想家庭智能这件事了。HomeAgent 这个名字挺直白——家里的智能代理，它要解决的痛点也很明确：让一个家庭只用一个大脑，而不是一堆各自为政的遥控器。

后摩智能做的是 AI 芯片，绿联做的是 NAS 和网络存储设备，这两家凑到一起做 HomeAgent，本质上是在干一件事——把大模型能力从云端搬到家里，让智能家居系统拥有一个本地化的、私有的、真正理解你这个家的 AI 中枢。它不是往手机里再塞一个 App，也不是往音箱里再堆一个语音助手，而是让家庭里的数据、算力、模型和应用，在一个私有环境里跑起来。

这套思路的核心价值在于三个词：本地化、私有化、场景化。本地化意味着响应速度不受云端的网络波动影响，家里断网也能用；私有化意味着家庭数据不出门，摄像头画面、门锁记录、生活日志这些敏感信息不需要上传到别人的服务器；场景化则是说，它学的不是“通用世界知识”，而是“我们家”的知识——比如你家孩子几点放学、客厅哪个角落光线最差、你的猫每天固定蹲在哪个位置。

这篇文章我想从产品设计、技术实现、实际部署和问题排查几个层面，把这套“家庭智能新形态”拆开聊一聊。对 NAS 玩家、智能家居爱好者，或者想在自己家里跑本地大模型的朋友来说，这套玩法应该能给你不少可落地的参考。

2. 整体设计思路：为什么需要“私有 AI 大脑”而不是云服务

2.1 云智能的天花板：网断了，家就“傻”了

先回顾一下现在绝大多数智能家居的运行逻辑。你对着音箱说“关灯”，语音上传到云端，云端识别语义，下发指令，灯灭。这一套流程平时看起来挺流畅，但一旦宽带出问题、云服务商机房抖动、或者某个智能音箱品牌调整服务策略，整个家立刻退化成手动模式。家里那个号称“智能”的中枢，只是个遥控器。

更麻烦的是数据隐私。家里装个摄像头、买个体重秤、用个智能门锁，产生的数据统统先上云再说。你可能觉得无所谓，但仔细想想——摄像头画面存在服务商手里，睡眠数据、起居时间、出入记录都在别人数据库里躺着，这本身就是个隐患。国内智能家居厂商这些年也在强调隐私，但架构上天生的“云优先”决定了数据必须过一道手。

后摩智能和绿联这次做的 HomeAgent，选了一条相反的路线：把 AI 能力放到家里，让数据在本地闭环。设备产生的数据，在本地的 NAS 里完成存储和处理，大模型推理在本地芯片上完成，只有在需要外部知识的时候才主动去碰云端。这一套下来，核心场景完全自给自足，断网反而成了最能体现价值的时候。

2.2 后摩智能在里面的角色：边缘算力的核心引擎

后摩智能做的是 AI 芯片，但它的定位和常规的 NPU 不太一样——主打量产落地的边缘端大模型推理。也就是说，它不是那种几十上百瓦的云端训练卡，而是功耗、价格、算力都卡在“适合放到家里”这个区间里的推理芯片。

HomeAgent 这种产品形态，对算力的要求其实很微妙。太弱的芯片跑不动大模型，动辄几十瓦的显卡放在家庭环境又完全不现实，毕竟不是每个家庭都有专门的设备间和足够的散热条件。后摩智能的芯片在这个维度上做了平衡——能跑百亿参数级别以下的模型，功耗控制在消费级设备能接受的范围内，同时支持常见的主流模型架构。这意味着你在家里跑一个 7B 或者 14B 的对话模型，不需要一台插着 RTX 4090 的服务器，一台体积正常的 NAS 或者边缘主机就能搞定。

绿联在 HomeAgent 里的角色，则是把这个芯片变成一套普通用户能用的产品。绿联这些年从硬盘盒做到 NAS，最大的积累在于存储、网络、文件系统和消费级产品的整体设计能力。NAS 是天然的家庭数据中心，机身里塞一块后摩智能的推理芯片，再配套一套软件系统，就能把一个“存文件”的设备升级成“能思考”的家庭大脑。

2.3 绿联 NAS 的价值：从“存数据的盒子”到“理解家庭的系统”

如果你用过绿联的 NAS 产品，应该知道它的界面做得比传统 NAS 友好不少，普通用户不需要敲命令行也能完成基本配置。这种产品化能力，在 HomeAgent 这个项目里比“性能参数”更重要——因为目标用户不只是折腾 NAS 的极客，还有只想“让家更聪明”的普通家庭。

我理解这套系统的设计意图是：把 NAS 从“存储工具”变成“家庭服务底座”。存储、计算、模型推理、设备联动，这些都变成 NAS 上的基础能力。用户的家庭相册、监控录像、设备日志、语音交互记录，全部沉淀在本地，模型基于这些数据提供个性化服务——比如问你“上周三晚上客厅有人吗”，它能直接基于本地录像推理回答，而不是给你甩一堆 App 里的时间轴。

2.4 与传统智能家居的差异化：系统联动 vs 单品控制

传统智能家居是“单品控制”逻辑，每个设备一个 App，每个 App 一套云；HomeAgent 是“系统联动”逻辑，整个家庭是一套系统，设备只是这套系统的传感器和执行器。

打个比方，传统智能家居像你雇了五六个各管一摊的保姆，每个保姆只认自己的活儿，互相之间不通气；HomeAgent 更像是你家装了一个大管家，这个管家认识你们家所有人，知道每个房间的情况，能自己拿主意——而且这个大管家住你家，不用每天把家里情况打电话汇报给外面的公司。

这种差异落到实际体验上特别明显。传统模式下，你想实现“晚上回家开门后客厅灯亮、窗帘拉起、空调调到 26 度、音箱开始放轻音乐”，得靠场景自动化规则一条条拼，每个设备都要单独设置，出错了还很难排查。HomeAgent 的方式则是让模型理解“主人回家了”这个意图，自己去调用对应的设备接口，适配当天的天气、时间、甚至你的心情——这是一种从“规则驱动”到“意图驱动”的转变。

3. 核心细节解析：HomeAgent 里的模型、私有数据和算力调度

3.1 模型选型：先弄清楚跑什么模型，再谈智能水平

HomeAgent 这套体系里，模型是大脑的软件载体。目前这个项目透露出来的技术路线，走的是“小模型专用化 + 大模型泛化”的组合方案。

专用小模型负责家庭场景里高频、确定性强的任务，比如语音唤醒、关键词识别、设备状态判断、人脸识别。这类任务用参数量很小的模型就能做得又快又准，在边缘芯片上跑得非常流畅，功耗也低，适合常驻运行。

泛化大模型负责真正需要“理解”的任务，比如“帮我查一下上周厨房摄像头拍到过几次人走动”“根据最近的能耗情况帮我规划一下空调开关时间”——这种开放式、需要推理的任务，靠小模型的规则匹配做不到，需要大模型具备语言理解和多步推理能力。这类模型参数量大、计算量大，不需要常驻运行，但需要做到“随叫随到”。

这套“双模型协同”的思路，和一个通用大模型硬扛所有任务的方案相比，优势在三点：功耗低、响应快、容错高。常驻的小模型只需很小的算力，大模型按需加载，整体功耗能压到消费级设备能接受的范围内。而模型层做了模块化，普通用户甚至可以根据自己家的设备情况，选择不同版本的模型组合。

3.2 私有知识库：让模型认识你的家

模型本身是“通用智能”，但家庭场景需要的是“专属智能”。要让模型知道你的家是什么样的，需要给模型提供家庭相关的上下文信息，这就是私有知识库的用武之地。

HomeAgent 里的私有知识库，建设过程大致是这样的：系统先把家里的设备拓扑、房间分布、人员信息、自动化规则、历史记录等数据规范化，存入本地数据库；当用户向模型提问或下指令时，系统先从知识库里检索相关的上下文信息，把这些信息连同用户的问题一起拼接成 Prompt，再交给大模型做推理。这套流程在技术圈里叫RAG，全称是 Retrieval-Augmented Generation，检索增强生成。

RAG 的好处是不用重新训练模型。大模型还是那个通用模型，但每次回答问题时，都能“临时翻查”你家的专属资料。比如模型本身不知道你家客厅朝南还是朝北，但知识库里记录了这一条，检索到之后，模型就能基于这个信息给出更靠谱的开关窗帘建议。

绿联 NAS 本身就擅长管理结构化数据和文件存储，把私域知识库建在 NAS 上是顺理成章的。相册、语音记录、设备日志这些非结构化数据存放在 NAS 的存储池里，向量化之后灌入向量数据库，检索的时候按语义相似度召回。这块包含了不少工程细节，后面我会写一篇专门的实操笔记展开讲。

3.3 算力调度与功耗控制：边缘推理不是把显卡塞进 NAS

先说一个认知误区——很多人觉得“本地跑大模型”就是把一块大显卡塞进 NAS 机箱里，这就想得太简单了。NAS 要常年 7×24 小时开机，功耗和噪音是硬约束。你放一张 350W 的显卡在家里，电费先不说，那个风扇噪音你一个星期就受不了。

HomeAgent 这类方案更现实的路径，是对算力做分层调度。简单的推理任务，用芯片上的低功耗核来跑；复杂的任务，才启动高性能核做加速计算；任务结束后，高性能核可以完全关断，只保留低功耗常驻核。这种机制对软硬件协同设计的要求很高——芯片要支持动态电压频率调节，系统软件要能在毫秒级别切换不同功耗档位。

另外，模型精度也有讲究。家用场景对绝对精度没有那么高的要求，但非常在意延迟和功耗。用 INT8 甚至 INT4 量化后的模型，体积能缩小到 FP16 模型的一半甚至四分之一，推理速度更快，功耗也更低。后摩智能这类主打端侧推理的芯片，通常都对低精度计算做了专门优化，实际跑起来比“通用芯片硬跑大模型”的体验要顺滑很多。

3.4 家庭数据安全与隐私边界

本地化带来的直接收益，就是隐私保护。HomeAgent 的系统架构里，用户的家庭数据默认留在本地，模型推理也在本地完成，云端只承担必要的外部服务调用——比如查天气、查菜谱这种本身就依赖外部数据的请求。

但这不代表本地化之后就万事大吉。本地系统同样需要考虑访问控制、数据加密、攻击面管理的问题。NAS 设备本身暴露在家庭网络中，如果网络里有其他不安全设备，或者用户把 NAS 的管理端口暴露到了公网，依然存在被入侵的风险。所以我一直建议：所有本地 AI 系统都要默认假设网络环境不可信，做好分区和权限隔离。后面我会专门列一个安全配置清单。

4. 实操过程：在绿联 NAS 上部署一个最小可用的本地 AI 服务

4.1 准备工作：硬件要求与系统环境

要说清楚实际部署，得先有一个能落地的平台。后摩智能和绿联的合作产品现在还在导入阶段，但基于现有的绿联 NAS 设备，我们完全可以抢先搭一套“HomeAgent 最小可用版”——本质上是把大模型跑在绿联 NAS 上，私有知识库和模型调用都放在本地，实现一个基础版的家庭智能问答与联动控制。

硬件方面，我建议准备一台至少 x86 架构、内存 16GB 以上的绿联 NAS。模型推理非常吃内存，尤其是加载 7B 模型并执行推理时，内存占用能到 6～8GB，这还没算 NAS 本身的系统、存储服务和其他 App 的开销。如果你打算跑 14B 模型，内存建议直接上到 32GB。

软件层面，绿联 NAS 的系统基于 Linux，官方提供了 Docker 支持，这是运行本地大模型服务最方便的路径。我用的是绿联私有云系统，在应用中心里启用了 Docker，然后在 Docker 里跑开源推理框架，比如 Ollama 或者 LocalAI。这类框架对硬件的要求比较宽松，能自动检测环境中的 GPU 或者 NPU 加速设备，没有的话也可以用 CPU 硬扛，只是速度和功耗要有所妥协。

提示：如果只是体验性质，不必一上来就追求顶配。先跑一个 1.5B～3B 的小模型，把全链路摸通了，再逐步换大模型。直接上大模型调试成本高，容易劝退。

4.2 部署流程：从拉取镜像到跑通第一个对话

第一步，在绿联 NAS 的应用中心里启用 Docker。不同型号的绿联 NAS 入口位置略有区别，但基本都在“应用中心”→“Docker”这个菜单下。启用之后，点击“镜像”→“拉取镜像”，搜索 ollama/ollama，选择带版本号的官方镜像拉取。

拉镜像这一步可能会踩坑——国内网络环境下，Docker Hub 的访问速度不稳定，大镜像（Ollama 的镜像不算大，几百 MB 左右）容易超时。我当时的处理办法是在镜像加速器配置里填了几个可用的镜像源地址，重新拉取之后速度就正常了。这个操作在 Docker 的设置界面里就能改，不需要 SSH 进后台。

镜像拉取完成后，创建容器。关键配置如下：

• 端口映射：宿主机的 11434 端口映射到容器的 11434 端口，这是 Ollama 默认的 API 端口。
• 目录挂载：把 NAS 上某个存储空间挂载到容器内的 /root/.ollama，这个目录用来存放模型文件。好处是 Docker 容器本身可以随时重建，但模型文件不会丢。
• 环境变量：如果内存充裕，可以设置 OLLAMA_KEEP_ALIVE 来控制模型在内存中保持加载的时间。默认情况下，模型处理完一次请求后会在内存里停留几分钟，避免频繁加载。

容器启动成功后，进入容器终端或者直接通过 SSH 操作宿主机，执行ollama pull qwen2.5:3b。这里选通义千问的 3B 版本是因为它对中文支持好，模型体积大约 2GB 左右，家用 NAS 的 CPU 也能在几秒内完成一轮对话。拉取完成后执行ollama run qwen2.5:3b，输入“你好”，能正常回复就说明部署成功了。

4.3 接入家庭知识库：用向量检索让模型“认识”你的家

模型能对话只是第一步，要让它真正服务家庭，还得给它喂“家庭知识”。这一步我用的是 RAG 方案。

先跑一个向量数据库容器，像 Qdrant 或者 Milvus Lite 都行，资源占用都不大。然后写一段脚本，把家庭的设备清单、房间结构、常用自动化规则等结构化信息，以及家庭手册、设备说明书这类文档，分割成 chunk，用嵌入模型转成向量，写入向量数据库。

之后每次向大模型提问，流程是这样的：把用户的问题先做向量嵌入，在向量数据库里做相似度检索，取回最相关的家庭知识片段，然后拼接 Prompt 发给大模型。大模型基于这些上下文信息，才能给出贴合家庭实际情况的回答。

这个流程跑通之后，你就可以问“我家客厅的灯支持色温调节吗”，系统会先检索知识库中有关“客厅”和“灯”的条目，再带着这些上下文去询问大模型，最后给出的答案就不再是“我无法回答”了。

嵌入模型的选择上，我用的 BGE 系列的中文嵌入模型，它体积很小，CPU 上就能跑，检索效果在中文场景下属于第一梯队。嵌入模型常驻内存，占用大约 300～500MB，对 NAS 来说压力不大。

4.4 接入家庭设备联动：把问答变成行动

到了这一步，系统已经能“回答问题”了，但还谈不上“智能家庭”。更进一步的玩法，是把大模型的输出对接上设备控制接口。

绿联 NAS 的智能家居集成能力目前还在逐步完善，但通用的路径是通过 MQTT 协议或 HTTP API 对接家里的智能设备网关（比如 Home Assistant）。思路是：大模型理解用户意图后，输出结构化的指令（比如开灯、关空调、调亮度），系统再把这个指令转换成对应平台的 API 调用。

这一步的典型问题是“幻觉”。大模型可能编造一个不存在的设备名称，或者理解错了设备状态。我的经验是：在 Prompt 里明确给出可操作设备的完整清单和状态字段，并约束模型只能从清单中选择设备，不能自由发挥。同时在系统层面做一道校验，如果模型输出的设备 ID 不在清单里，直接拒绝执行并请用户重新描述。

我搭的最小可用版，最终做到了这样的体验：对系统说“离家的时候记得关掉客厅的灯和空调”，系统会先在设备清单里检索出“客厅主灯”“客厅空调”，再生成执行序列，然后调用 MQTT 接口下发指令。整个过程不经过任何云服务，延迟在 2 秒以内。

5. 常见问题与排查技巧：本地 AI 部署最容易踩的五个坑

5.1 容器日志看不到内容，怎么排查

Docker 容器启动了，但 ollama 的日志里没有任何输出，这种情况多半是容器内部服务没起来，或者端口监听异常。先检查容器状态：docker ps -a，如果容器状态是 Exited，用docker logs <容器名>看退出原因，常见的是目录挂载权限问题——宿主机的挂载目录没有给足读写权限，容器内进程无法写入。

另外有个容易忽略的点：绿联 NAS 的 Docker 管理界面里，创建容器时如果勾选了“与宿主机共享网络”这种网络模式，端口映射就不生效了。这种情况下要用容器 IP 而不是 localhost 访问服务。排查时先确认网络模式，再确认 API 端口能通：curl http://localhost:11434/api/tags，能返回 JSON 就说明服务正常。

5.2 模型下载速度慢或者拉取失败

ollama pull卡在下载阶段，大部分原因还是网络问题。模型文件存放在境外对象存储上，下载速度受网络环境影响很大。解决思路有三个：

• 配置镜像加速器，Docker Hub 本身可以加速，但 Ollama 的模型下载不走 Docker Hub，而是走 registry.ollama.ai，这个域名目前没有通行的加速方案。
• 手动下载模型文件然后导入，在另一台网络环境更好的机器上把模型文件下载好，传到 NAS 上，再用ollama create命令从本地文件导入模型。这个方法麻烦一点，但最可靠。
• 换用支持从 Hugging Face 下载模型的推理框架（如 LocalAI），Hugging Face 在国内环境也有镜像站，下载难度会低一些。

5.3 推理速度慢：CPU 跑模型如何优化

家用 NAS 如果没有独立 GPU 或 NPU，纯 CPU 推理的速度确实感人。3B 模型生成一段 100 字的回答，可能需要 30 秒左右，14B 模型会慢到难以忍受。优化手段有几条：

• 降低模型精度。用 q4 量化版本的模型文件，推理速度能提升 1～2 倍，显存占用下降一半。
• 限制上下文长度。Ollama 默认的上下文长度是 2048，如果不需要太长对话历史，保持默认即可。上下文越长，计算量越大。
• 关闭其他高负载容器。NAS 上同时跑着下载任务、相册索引任务时，CPU 资源被抢占，推理速度会进一步恶化。优先保证推理容器的 CPU 配额。

5.4 知识库检索不到相关内容

RAG 系统里经常出现“感觉模型没看过知识库”的情况。排查顺序如下：

• 先检查向量数据库里有没有数据，查一下 collection 的 count，为 0 说明写入部分出了问题。
• 检查嵌入模型是否正常工作。嵌入模型本身也是一个小模型，如果嵌入模型服务没起来，所有文档写入都会失败。
• 检查 chunk 切分逻辑。如果一段文本太长，比如把整本说明书当成一个 chunk，嵌入后的向量检索命中率会很低。建议 chunk 长度控制在 300～500 字之间，覆盖相邻业务逻辑的内容放在同一个 chunk 里。

5.5 设备联动指令不生效

模型已经输出了“打开客厅灯”这样的指令，但设备没反应。这种问题通常不在模型侧，而在指令翻译层。先手动调用一下设备平台的 API，确认接口本身可用；再确认指令格式和平台要求的格式是否一致——有些平台用 JSON-RPC，有些用 RESTful，还有的要求先鉴权。

另一个隐蔽的坑是权限问题：NAS 上运行的容器如果需要调外部 API，出网权限要放行。绿联 NAS 的 Docker 默认网络模式是桥接，容器访问外部网络没问题，但如果开了防火墙策略，就要检查出站规则。

6. 对整个行业的思考：边缘 AI 会不会成为智能家居的标配

我把这套 HomeAgent 的方案在本地完整跑了一遍之后，最大的感受是：智能家居行业折腾了这么多年，一直缺的不是智能，而是“隐私前提下的大模型能力”。前些年的智能音箱、智能中控屏，本质上是把语音助手放到家里，但数据和逻辑都在云端，用户体验受制于网络和服务商策略。HomeAgent 的本地化路线，等于把大模型这块最后短板也补上了。

而且，从成本结构上看，边缘 AI 也在变得越来越可行。以前说“本地跑大模型”，大家第一反应是买显卡、改机箱、搞水冷，那是极客玩法。但随着后摩智能这类端侧推理芯片的量产，以及 NAS 厂商把推理能力做成标准功能，普通家庭用户很快也能享受到“买一台 NAS 就送 AI 大脑”的体验。这不需要用户懂技术，厂商已经把复杂都封装在产品里了。

当然，这套方案的挑战也很明显——模型能力相比云端大模型还是有差距，家庭场景复杂的多轮对话、多设备协同，对模型泛化能力的要求很高；本地算力决定了无法运行超大参数的模型，这也是为什么 HomeAgent 这类系统需要持续在“小模型效果优化”上投入。但方向对了，剩下的都是工程问题。

从我自己的实际体验来说，把大模型跑在自己家里的意义，并不只是一个“能聊天的 NAS”，而是重新拿回了对家庭数据的控制权。你不需要担心哪天某个云服务商调整政策导致设备失灵，也不需要担心敏感数据被拿去训练别人的模型。这个价值，越用得久越有体会。接下来我会继续在这个平台上尝试接入更多设备，用真实场景检验这套方案的边界在哪里。