家用NAS与路由器接入大模型：搭建实用办公AI助手

一、需求分析：什么叫“真正实用”的办公 AI 助手

在动手之前，先明确“实用”的标准。一套能长期用下去的办公 AI 助手，至少要满足三个前提：

1. 7×24 小时在线。助手的价值在于“随时可问、定时可办”：清晨的日程简报、午间的会议纪要整理、深夜的资料检索，都要求服务常驻。这正是 NAS 与路由器相对桌面电脑的核心优势——它们天生为长期运行而设计。
2. 数据可控。办公场景涉及合同、会议记录、内部文档，把所有内容都交给外部平台并不稳妥。理想方案是敏感数据留在内网，仅把必要的推理请求发往云端。
3. 成本可持续。硬件一次投入、能力按需扩展，而不是每次需求变化都推倒重来。

围绕这三点，再来看设备选型，思路会清晰很多。

二、硬件底座：NAS 与可定制路由器如何分工

2.1 路由器能跑 AI 吗？能，但角色有限

目前不少支持自定义配置的路由器，系统层面已经具备容器运行时能力，可以挂载轻量服务；部分采用集成 NPU 的 SoC 方案，也具备执行小型量化模型的条件。因此在路由器上部署一个 Web 管理界面、跑一个轻量 AI Agent，做请求鉴权、日志采样之类的边缘预处理，技术上是成立的。

但把路由器当主力推理底座，会撞上三堵墙：

• 内存与存储受限：经过量化的 7B 级模型通常也需要 8GB 以上的内存余量，主流路由器的硬件配置远达不到；
• 散热与供电瓶颈：持续推理是高负载任务，长期满载会影响设备寿命，甚至波及全网稳定性——路由器一旦过热重启，全家断网；
• 机会成本高：一台支持容器与 NPU 的高端可定制路由器，价格动辄数千元。同样的预算投给一台中端 NAS，能换来更大的内存、独立的存储位和更好的散热，综合性价比完全不同。

2.2 结论：NAS 做大脑，路由器做咽喉

• NAS：承载模型推理服务、向量数据库、知识库文件与 Agent 编排，是系统的“大脑”；
• 路由器：承担内网域名解析、反向代理、HTTPS 终结、访问控制与远程安全隧道，是系统的“咽喉”。

两者各司其职，才能同时满足“在线、可控、省钱”三个目标。

三、架构设计：本地优先、云端兜底的混合推理

3.1 分层视图

• 网络层（路由器）：内网 DNS、反向代理、HTTPS、远程访问隧道；
• 运行时层（NAS）：容器化环境，各组件隔离部署、独立升级；
• 服务层：推理服务、向量检索、Agent 编排；
• 模型层：本地量化小模型 + 云端大模型 API；
• 数据层：文档库、向量库、会话与审计日志。

3.2 混合推理策略

本地小模型处理高频、低复杂度任务（文本改写、摘要、分类、简单问答），长文档分析、复杂代码生成等重任务走云端 API。这样敏感数据默认不出内网，同时保留能力上限。云端侧可选用百度智能云等提供大模型服务的平台，通过标准 HTTP 接口调用，并按用量控制预算。

3.3 容器编排示例

services:
  model-server:
    image: <本地推理服务镜像>
    ports: ["8000:8000"]
    volumes: ["./models:/models"]
    restart: unless-stopped
  rag-store:
    image: <向量数据库镜像>
    ports: ["9000:9000"]
    volumes: ["./index:/data"]
  agent-api:
    image: <自研Agent服务镜像>
    ports: ["8080:8080"]
    depends_on: [model-server, rag-store]

四、实施步骤：从零到可用

4.1 NAS 侧三步走

1. 在 NAS 管理界面启用容器运行时（多数 NAS 系统在套件中心即可开启）；
2. 部署推理服务与向量数据库，挂载模型与索引目录；
3. 配置健康检查与开机自启，确保断电恢复后自动拉起。

4.2 调用验证

以业界通用的对话补全接口风格为例：

import requests
def ask_model(prompt: str) -> str:
    resp = requests.post(
        "http://<NAS内网IP>:8000/v1/chat/completions",
        json={
            "model": "local-8b",
            "messages": [
                {"role": "system", "content": "你是办公助手，回答简洁、准确、可执行。"},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.3,
        },
        timeout=60,
    )
    return resp.json()["choices"][0]["message"]["content"]

4.3 路由器侧：网络打通与收敛

• 内网 DNS：将固定内网域名指向 NAS，全家设备统一入口；
• 反向代理 + HTTPS：证书统一管理，避免端口散落；
• 远程访问：切勿把推理服务直接暴露公网，优先采用基于主流安全隧道协议的异地组网方案；
• 边缘预处理：若路由器支持容器，可挂载轻量 Agent 负责请求鉴权、频控与日志脱敏，重计算全部交给 NAS。

4.4 安全加固清单

最小暴露面、强口令与双因素认证、镜像定期更新、数据盘加密、日志审计、内外网权限分离，缺一不可。

五、定制 Agent：从“能对话”到“能干活”

Agent 的四要素是模型、工具集、记忆与规划。借助大模型自身的代码生成能力“手搓”一个定制 Agent 完全可行：先定义工具契约，再让模型生成骨架，人工补齐鉴权与异常处理，最后挂载上线。

tools = [{
    "name": "search_docs",
    "description": "在团队知识库中检索文档片段",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {"type": "string"},
            "top_k": {"type": "integer", "default": 5}
        },
        "required": ["query"]
    }
}]

主循环伪代码：

while True:
    msg = wait_for_message()          # 来自 Web 界面或 IM 入口
    plan = llm.plan(msg, tools)       # 模型决定调用哪些工具
    results = [execute(step) for step in plan]
    reply = llm.summarize(msg, results)
    send(reply)

轻量 Agent（如消息接入网关）可以直接跑在路由器容器里，负责协议转换与转发；编排与执行逻辑放在 NAS，形成“边缘接入、中心处理”的分工。

六、典型办公场景

• 知识库问答：文档入 NAS，切片向量化，检索结果注入上下文，实现基于私有资料的准确回答；
• 会议与消息摘要：录音转写后本地摘要，敏感内容不出内网；
• 每日简报：定时任务汇总日程、待办与重要邮件，早晨自动推送；
• 任务流转：以 IM 机器人作为入口，Agent 直接创建和跟踪待办。

七、成本与收益

预算优先级上，建议内存优先、缓存盘次之、整机更换最后；尤其不建议为了跑 AI 单独购置数千元的高端路由器——同样的钱放在 NAS 上收益高得多。云端调用通过分级路由与月度预算告警控制成本。收益则是长期性的：服务常在、数据私有、流程可定制。

八、路线图与总结

• 第一周：NAS 容器环境 + 单模型推理 + Web 界面跑通；
• 第二周：知识库检索 + 基础 Agent 工具调用；
• 第三周：路由器侧收尾（HTTPS、DNS、远程隧道），上线定时任务；
• 持续迭代：按任务复杂度调整本地/云端分流策略，逐步替换重复性人工操作。

总结一句话：路由器证明的是“可行”，NAS 承担的是“实用”。把重活交给 NAS、把网络交给路由器、把重计算兜底交给云端大模型服务，这套混合架构才是家用设备搭建办公 AI 助手的最优解。