家用NAS与路由器搭建私有办公AI助手实践

一、先拆需求：办公 AI 助手到底要做什么

在动手之前，先把“实用”两个字翻译成工程需求。一套能长期用下去的办公 AI 助手，通常覆盖三类能力：

1. 对话与文本处理：日常问答、文案润色、翻译、会议纪要摘要；
2. 知识库检索（RAG）：把团队文档、合同模板、个人笔记变成“可提问”的私有知识；
3. 任务自动化（Agent）：让模型调用工具，完成查日程、整理待办、定时汇总、消息推送等闭环动作。

再对照家中设备的能力边界：

• NAS：7×24 小时在线、磁盘容量大、多数系统自带容器运行时，天然适合做常驻服务与数据底座；
• 可定制路由器：处于网络边界，适合做接入控制、反向代理与远程访问；如果固件支持容器、剩余内存充足，也能承载轻量服务；个别集成 NPU 的 SoC 还能承担小模型的端侧推理。

这里必须先厘清一个容易混淆的问题：“技术上能不能跑”与“投入上值不值得跑”是两回事。 一台支持容器的路由器确实可以充当 AI 服务的底座——跑一个 Web 界面、做一层 API 网关都不成问题；但高端可定制路由器的售价动辄数千元，同样的预算完全可以组建一台算力强得多的迷你主机，再配一台普通路由器。因此更合理的思路不是“在一台设备上死磕”，而是按角色分工：路由器管网络与调度，NAS 管存储与服务，本地算力不足时用云端大模型补齐。

二、总体架构：三层设计

[终端设备]            [接入层：路由器]              [服务层：NAS]                  [数据层]
手机/PC/平板 ──内网──▶ 反向代理/HTTPS/防火墙 ──▶ Web界面·模型网关·RAG·Agent ──▶ 文件存储·向量库·审计日志
      └────────────── 远程访问：加密隧道 + 强认证 ──────────────┘

• 接入层（路由器）：负责内网寻址、反向代理与 HTTPS 终结、按需的远程访问隧道与防火墙规则，原则是“最小暴露面”；
• 服务层（NAS）：Web 界面、模型网关、RAG 检索服务、Agent 调度器全部容器化部署，升级、回滚、迁移都只动配置；
• 数据层：原始文档放本地文件共享或对象存储，切分后的语义索引进向量数据库，所有调用写审计日志。

分层的价值在于：任何一层出问题都不影响其他层排障；将来更换路由器或扩展算力，只需替换对应层的实现。

三、大模型接入的两条路线与混合策略

路线 A：本地推理

• 优点：数据不出内网、无按量费用、内网延迟低；
• 限制：消费级 NAS 的 CPU 与内存通常只能承载数 B 到十几 B 参数的量化模型，长上下文与高并发都吃力；
• 关键手段：权重量化（4bit/8bit）压缩内存占用；限制上下文长度；启用 KV 缓存复用；若 SoC 集成 NPU，可把 Embedding 计算或小模型推理下沉到 NPU，减轻 CPU 压力。

路线 B：云端大模型 API

• 优点：能力上限高——长上下文、多模态、函数调用开箱即用，且免运维；
• 代价：数据需要出网，按调用量计费；
• 工程要点：切忌把密钥散落在各个应用里。正确做法是在 NAS 上部署统一的模型网关，集中管理密钥、限流、重试与审计。国内可选百度智能云等云平台提供的大模型服务，其通用能力类别一般涵盖对话推理、知识库检索、监控告警等。

推荐策略：混合路由

在网关层按请求属性分流：涉及合同、薪酬、客户资料的请求走本地小模型；通用写作、翻译、代码生成走云端大模型。这样既守住数据安全底线，又不牺牲效果上限。

四、容器化部署：一份最小可用配置

部署前先确认三件事：设备提供容器运行时（多数 NAS 系统已内置；路由器需固件支持且剩余内存充裕）、存储路径已规划、镜像来源可信。

以下是一份简化的容器编排配置示例：

services:
  web-ui:            # 对话界面
    image: registry.local/chat-ui:stable
    ports: ["8888:8080"]
    environment:
      GATEWAY_URL: http://model-gateway:9000
    restart: unless-stopped
  model-gateway:     # 统一封装本地/云端模型调用
    image: registry.local/model-gateway:stable
    environment:
      LOCAL_ENDPOINT: http://local-inference:9100
      CLOUD_API_URL: ${LLM_API_URL}
      CLOUD_API_KEY_FILE: /run/secrets/llm_key
    volumes:
      - ./secrets:/run/secrets:ro
    restart: unless-stopped
  local-inference:   # 本地小模型（可选，按需启动）
    image: registry.local/inference:quantized
    environment:
      MODEL_PATH: /models/q4-7b
      CONTEXT_LEN: "8192"
    volumes:
      - /volume1/models:/models:ro
  vector-db:         # 向量数据库
    image: registry.local/vector-db:stable
    volumes:
      - /volume1/vector-data:/data
    restart: unless-stopped

网关侧的调用逻辑可以很薄，以常见的对话接口为例：

import os, requests
def chat(prompt: str, sensitive: bool = False) -> str:
    base = os.environ["LOCAL_ENDPOINT"] if sensitive else os.environ["CLOUD_ENDPOINT"]
    resp = requests.post(
        f"{base}/chat",
        headers={"Authorization": f"Bearer {os.environ['LLM_KEY']}"},
        json={"messages": [{"role": "user", "content": prompt}],
              "temperature": 0.3},
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["content"]

要点只有三条：密钥经环境变量或密钥文件注入，绝不写进镜像；对本地与云端设置不同的超时与重试策略；所有请求记录审计日志。

agent-">五、知识库与 Agent：从“能聊”到“能干活”

rag-">RAG 流水线

1. 解析与切分：按标题层级或语义边界切块，保留来源、时间等元数据；
2. 向量化入库：Embedding 模型可选本地小模型或云端接口，敏感文档务必走本地；
3. 检索：相似度 Top-K 召回，叠加关键词与权限过滤，确保不同成员只能检索到各自有权限的文档；
4. 重排与生成：把最相关的若干片段交给模型生成答案，并要求标注引用来源，显著降低幻觉。

Agent 实践

• 工具注册：日历查询、待办读写、文件搜索、HTTP 调用等，每个工具都要显式授权；
• 定时任务：例如每周五 18:00 自动拉取本周会议纪要，生成结构化摘要后推送到指定渠道；
• 权限最小化：Agent 只拿到完成任务所需的最小权限，所有工具调用留痕，出问题可回溯。

六、安全与稳定性清单

• 网络隔离：所有服务只监听内网；远程访问必须走加密隧道并启用强认证；
• 密钥管理：环境变量或密钥文件挂载，配合定期轮换；
• 数据治理：上传文档先脱敏，审计日志定期归档，向量库与配置纳入备份计划；
• 资源守护：为每个容器设置内存与 CPU 上限，避免推理进程拖垮 NAS 上的其他服务；
• 路由器的三个坑：封闭外壳散热差、高负载易降频；闪存写入寿命有限，日志与数据必须外移；内存普遍偏小，容易触发 OOM。结论：路由器只承担网关与调度，重负载一律交给 NAS。

七、成本核算与演进路线

• 阶段一（零新增投入）：NAS 起容器 + 云端大模型 API，一两天即可跑通最小闭环；
• 阶段二：引入本地量化小模型承接敏感任务，尝试 NPU 或核显加速；
• 阶段三：若本地并发成为瓶颈，花小几千元添置带独立显卡的迷你主机，而不是购买数千元的高端“可玩性”路由器——把预算花在真正的算力与可靠性上，而不是花在“顺便能跑 AI”的附加属性上。

回到最初的问题：家里的 NAS 与可定制路由器能不能搭一套实用的办公 AI 助手？能，而且仅靠路由器做 AI 底座在技术上也成立；但理性的答案是——让路由器做路由器擅长的事，让 NAS 做服务器擅长的事，让云端大模型补足算力上限。设备复用的真正价值在于低成本验证方案，而一套长期好用的办公 AI 助手，靠的是清晰的架构分工、混合的模型路线与扎实的安全底线。