NAS上部署OpenClaw接入飞书，打造私有AI智能助理

最近好几个朋友都在问我，家里那台 NAS 除了存照片、挂下载、跑 PT 之外，到底还能不能干点“有灵魂”的事。我的回答是：把 OpenClaw 部署到 NAS 上，再接入飞书，让 NAS 从一个“存储盒子”变成 7×24 小时待命的 AI 助理。这个组合听起来好像有点跨界，但实际落地后你会发现，这就是目前普通人能快速拥有的、真正属于自己的 AI 中控台。

OpenClaw 是个开源的个人 AI Agent 框架，可以理解成一个“通用的智能体运行底座”。它能连各种聊天平台，调用各种大模型，还能自己调度工具去完成任务。飞书则承担了“前台”的角色，你在手机或电脑上的飞书里跟它对话，就像跟一个同事聊天一样自然。这篇文章就把我完整的部署经历、踩坑记录和个人配置方案写下来，希望能帮你少走几个弯路。

1. 为什么是“NAS + OpenClaw + 飞书”这个组合

1.1 OpenClaw 到底解决了什么问题

先说说 OpenClaw 是什么。简单讲，它是一个让你可以“自托管”的 AI 代理框架。市面上的大模型聊天工具，通常都是打开网页、输入问题、等答案。而 OpenClaw 不一样，它强调的是“代理式交互”：你可以给它一个目标，比如“把本周的销售数据整理成表格发到群里”，它会自己拆解成多个步骤，调用代码执行、访问 API、生成文件，最后把结果丢到飞书会话里。

这类框架的核心价值在于“自主行动”，而不只是“回答问题”。它把大模型、工具调用、会话管理、多平台接入这些能力集成在一起，你只需要准备一个模型 API Key 和一套渠道配置，就能把它跑起来。社区里这套东西目前很活跃，很多人在拿它做个人助理、自动化脚本、信息聚合机器人。它也支持通过配置文件定义不同的模型供应商和不同的“Channel”（渠道），Channel 就是飞书、钉钉、Slack 这类入口。

1.2 为什么我不选云服务器，而是部署在 NAS 上

很多人第一反应是：AI Agent 不是应该放云服务器上吗？确实可以，但我最终选了 NAS，理由很实在。

NAS 本来就是 7×24 小时开机，电费比起云服务器低得多，而且计算资源平时大量闲置。我在群晖上跑个下载、存个照片，CPU 占用常年不到 10%，跑一个 OpenClaw 容器完全没压力。如果你是飞牛 NAS（fnOS）玩家，也一样，fnOS 自带 Docker 和 Compose 支持，跑这类应用非常顺手。

云服务器当然有它的优势，比如公网 IP 固定、带宽大。但缺点同样明显：要一直付费，内存和磁盘扩容都要加钱，而且敏感数据放在别人的机器上总归要掂量一下。放 NAS 上，数据完全在自己手里，模型调用只把必要内容发出去，其他都在本地处理。

我做了个对比，供参考：

1.3 飞书当“前台”的优势

接入渠道我选的是飞书，不是微信，也不是 Telegram。微信个人号机器人有风控风险，我直接放弃；Telegram 在国内使用不方便，对很多朋友来说门槛也高。飞书的好处是：个人免费版也能建自建应用，有完整的机器人 API，支持事件订阅、长连接、多维表格、富文本卡片。你可以在手机、电脑多个端同时跟它对话，也能拉一个“个人助理”群，把家人或同事拉进来一起用。

飞书还有一个我很看重的点，就是它天生是“工作流工具”。消息、文档、表格、多维表格、日程都是一套体系。OpenClaw 接到飞书之后，不只是聊天，它可以直接操作多维表格、发送富文本卡片，这让整个 AI 助理的“干活能力”上了一个台阶。

2. 部署前的关键设计：网络通道与消息通道

2.1 给 NAS 一个稳定的访问入口：DDNS 与端口转发

部署之前，先想清楚一个问题：OpenClaw 怎么跟飞书通信。这里涉及两种模式，一种需要从公网主动访问你的 NAS，另一种不需要。

先说需要公网的情况。飞书服务器要把用户消息推送给你的机器人，传统做法是配置一个“回调地址”，也就是飞书把你的 NAS 地址当作 webhook 来调用。这时 NAS 需要有一个公网可达的入口。大部分家庭宽带的 IP 是动态的，所以要用 DDNS 动态解析到一个固定域名上，再在路由器上做端口转发，把外网访问的端口映射到 NAS 内网 IP。

如果你有“动态公网 IP”，在群晖的 DDNS 设置里可以直接注册一个 xxx.synology.me 域名，或者绑定阿里云、DNSPod 这类域名。飞牛 NAS 也有 DDNS 模块，填好账号就行。路由器上做一个端口转发，比如外部访问 8443 转发到 NAS 的 443，这样飞书回调请求就能进来。

不过我这里要特别提醒一句：把 NAS 的服务暴露到公网，风险等级完全不一样。尽量不要把 22、5000 这种常用管理端口直接映射出去。正确做法是只暴露一个反向代理端口，用 HTTPS 证书，并且开启白名单访问。如果你没有把握，建议直接走下面说的另一种更安全的模式。

2.2 长连接模式：不暴露公网也能收消息

飞书开放平台支持“长连接”接收事件，也就是飞书 SDK 与服务器之间维持一条 WebSocket 连接，消息由飞书主动推送到你的客户端，不需要公网回调地址。这个模式对 NAS 用户极其友好。NAS 作为客户端主动去连飞书服务器，所有通信都是出站，不需要在路由器上开任何端口，也就不存在暴露风险。

我在实际配置中，强烈推荐用长连接。哪怕你有公网 IP，也建议优先长连接，省事又安全。OpenClaw 的飞书 Channel 如果配置成长连接模式，只要填上飞书应用的 App ID 和 App Secret，它启动后就会自己建立连接，收消息、回消息都能正常工作。

两种方式的对比：

2.3 环境检查：Docker、内存、存储

部署前先确认 NAS 上的 Docker 环境。群晖从 DSM 7.2 开始自带“Container Manager”，飞牛 NAS 的应用中心里也有 Docker。如果你还没装，先去套件中心装好。然后确认容器管理工具支持 Docker Compose，这个很重要，后面我们直接用 compose 文件来定义整个服务。

资源方面，OpenClaw 本体很轻，主要吃内存的是模型调用和会话缓存。我建议至少 2GB 可用内存，如果只有 1GB 可能会遇到 OOM 导致容器被杀。存储上留 5GB 就够了，主要是日志和 session 文件。CPU 倒是不挑，x86 平台最好，ARM 的 NAS 也能跑，但部分镜像可能不提供 ARM 版本，需要留意。

3. 飞书侧接入配置：自建应用的完整姿势

3.1 创建自建应用并开启机器人能力

打开飞书开放平台，用管理员账号登录，在“开发者后台”里创建一个“企业自建应用”。名字随意，比如“NAS 助理”。创建之后，在“凭证与基础信息”页面拿到 App ID 和 App Secret，这两个值就是 OpenClaw 连接飞书的钥匙，先保存在本地。

接着在“能力配置”里添加“机器人”能力。这意味着你的应用可以在飞书里被搜索、被拉群、被 @。群里添加机器人时，搜到这个应用名称即可。记住，机器人不是“自定义机器人”，自定义机器人只有 webhook，只能单向发消息，不能收消息，也不能读取事件。我们要的是“自建应用 + 机器人能力”。

3.2 配置权限与事件订阅

权限是新手容易卡壳的地方。在“权限管理”里，你需要开通以下常用权限：

• im:message：读取与发送单聊消息
• im:message.group_at_msg：接收群聊中 @ 机器人的消息
• im:chat：读取群组信息
• im:resource：读取图片、文件等资源
• 如果要用多维表格，还需要加多维表格相关权限，比如 bitable:app

权限开完之后，并不会立刻生效。自建应用必须“创建版本并发布”，发布后需要企业管理员审核，审核通过后机器人才能在企业内正常使用。这一步经常有人漏掉，结果发现机器人始终不回复，原因就是发布了旧版本或无权限版本。

然后是事件订阅。在“事件订阅”页面，选择“使用长连接接收事件”，然后添加事件 im.message.receive_v1，这个事件就是“收到消息”的触发点。长连接模式不需要填回调地址，飞书会通过 WebSocket 把事件推给你。

3.3 发送表格与多维表格的几种 API 姿势

OpenClaw 接入飞书后，如果只是发文字消息，未免浪费。飞书的优势在于可以发富文本、发文件、读写多维表格。常见的三种用法我给你拆开讲。

第一种，用 markdown 或 post 富文本在消息里直接渲染表格。适合几十行以内的小数据。你可以让 OpenClaw 把结果拼成表格文本，再通过飞书消息接口发出去。优点是实现简单，群里直接能看。

第二种，生成 Excel/CSV 文件，通过文件消息发送。适合数据量稍大的报表。OpenClaw 可以用 Python 脚本生成文件，然后调用飞书上传消息接口，把文件作为附件发到群里。

第三种，也是我认为最实用的，就是直接操作多维表格。飞书多维表格本质是一个数据库，有专门的 API。你可以在多维表格里建一张“任务清单”或“周报汇总”表，让 OpenClaw 定期往里写数据，或者在群里查询。下面是一个获取企业自建应用 access_token 并发送消息的通用示例，字段以飞书官方 API 文档为准：

python复制import requests

# 获取 tenant_access_token
resp = requests.post(
    "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal",
    json={"app_id": "cli_xxx", "app_secret": "xxx"}
)
token = resp.json()["tenant_access_token"]

# 发送文本消息到群聊
headers = {"Authorization": f"Bearer {token}"}
payload = {
    "receive_id": "oc_xxxxxxxx",       # 群聊的 chat_id
    "msg_type": "text",
    "content": "{\"text\":\"早上好，我是 NAS 上的 AI 助理\"}"
}
r = requests.post(
    "https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=chat_id",
    headers=headers,
    json=payload
)
print(r.json())

多维表格的写入类似，先获取多维表格的 app_token 和 table_id，再调用 /open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records 接口创建记录。OpenClaw 可以做成一个“技能”，你只要在群里说“帮我把今天的任务进度更新到多维表格”，它就开始干活。

4. NAS 上落地 OpenClaw：Compose 部署与配置

4.1 目录结构与 Compose 文件

在 NAS 上新建一个目录，比如 ~/docker/openclaw/。里面放 .env、docker-compose.yml、config.yaml，再建 sessions 和 data 两个子目录，分别用来存放会话状态和持久化数据。

OpenClaw 官方镜像和配置项更新比较快，我这里给出一套通用的 Compose 模板，你可以根据自己的 NAS 架构和实际镜像来调整：

yaml复制version: "3.8"

services:
  openclaw:
    image: openclaw/openclaw:latest   # 以官方 Docker Hub 实际镜像名为准
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"         # 只绑定本机，提供调试接口，不对公网开放
    environment:
      - TZ=Asia/Shanghai
      - OPENCLAW_LLM_PROVIDER=openai_compatible
      - OPENCLAW_LLM_MODEL=qwen-plus
      - OPENCLAW_LLM_API_KEY=${LLM_API_KEY}
      - OPENCLAW_LLM_BASE_URL=${LLM_BASE_URL}
      - FEISHU_APP_ID=${FEISHU_APP_ID}
      - FEISHU_APP_SECRET=${FEISHU_APP_SECRET}
      - FEISHU_CHANNEL_ENABLED=true
      - FEISHU_EVENT_MODE=websocket
    volumes:
      - ./sessions:/sessions
      - ./data:/data
      - ./config.yaml:/app/config.yaml:ro
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

.env 文件中保存敏感信息，不要直接写死在 compose 里：

bash复制LLM_API_KEY=sk-xxxx
LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
FEISHU_APP_ID=cli_xxxx
FEISHU_APP_SECRET=xxxx

注意 ports 这里，我故意把端口绑定到 127.0.0.1，因为 OpenClaw 的 web 控制台我们只需要在 NAS 本机访问，完全不需要暴露到局域网，更不需要暴露到公网。如果你有远程查看需求，可以通过 SSH 隧道访问，或者加一层带认证的反代。

4.2 配置模型与 Channel

模型配置我建议走 OpenAI 兼容接口。国内可用的有通义千问的 dashscope、DeepSeek、智谱 GLM 等，这些平台都提供 OpenAI 兼容端点，OpenClaw 可以直接接。如果你不想用云 API，也可以接 NAS 上的 Ollama，但说实话，NAS 的 CPU 推理速度太慢，体验会打折。除非你的 NAS 有独立 GPU 或 NPU，否则优先用云端 API。

config.yaml 是一个关键的配置中心。我习惯用环境变量引用敏感字段，既方便管理，也能避免密钥写在配置文件里造成泄露：

yaml复制llm:
  provider: openai_compatible
  base_url: ${LLM_BASE_URL}
  api_key: ${LLM_API_KEY}
  model: ${OPENCLAW_LLM_MODEL}

channels:
  feishu:
    enabled: true
    app_id: ${FEISHU_APP_ID}
    app_secret: ${FEISHU_APP_SECRET}
    event_mode: websocket

session:
  lock_timeout: 120000

里面 session.lock_timeout 是我在踩过坑之后才专门加的字段。后面第 5 节详细说。

4.3 启动与首次联调

配置好之后，在 ~/docker/openclaw/ 目录下执行：

bash复制docker compose up -d
docker compose logs -f

第一次启动会拉取镜像，看到日志出现 channel feishu connected 或类似字样，说明长连接建立成功。如果没这个日志，先检查环境变量是否加载，再检查飞书应用是否已经发布。

联调时，在飞书里创建一个只有你自己和机器人的群，然后在群里 @ 它，发一句“你好”。正常情况下，几秒后它就会回复。如果没反应，去开发者后台的“事件订阅”里看有没有收到事件推送。长连接模式下，可以在“事件订阅”页面直接测试事件订阅，如果事件订阅正常，那就是 OpenClaw 侧的消息处理问题，看容器日志定位。

5. 常见问题与排查实录

5.1 agent failed before reply: session file locked

这个报错我一开始也遇到过，英文提示大约是 agent failed before reply: session file locked (timeout 60000ms)。它表示 OpenClaw 想要写 session 文件，但那个文件被另一个进程锁住了。

原因往往是并发。比如群里有几个人同时 @ 机器人，或者飞书事件重复推送，导致两个请求想同时复用同一个会话文件。另一个常见场景是容器被强制重启，上次的 session 锁没有释放，残留了锁文件。

解决方法有几个。最直接的是到 sessions 目录下找到 .lock 文件删掉，然后重启容器。更根本的是调大锁超时时间，比如把 session.lock_timeout 设成 120000 甚至更长，给前一个任务足够的处理时间。同时，尽量不要让同一个会话被并发调用。如果业务上确实需要多人同时使用，那就拆成不同 session key，比如按用户 ID 维度区分会话。

5.2 飞书输出容易被截断

飞书对单条消息的长度和卡片复杂度有限制。OpenClaw 如果一次性生成一篇很长的周报，很可能在飞书里显示不全。我遇到的情况是：明明日志里结果完整，群里却只看到前半段。

解决办法是让 OpenClaw 在输出层做“分段处理”。可以让它把长内容拆成多条消息，或者先发一个摘要，再把全文存成飞书云文档或本地 Markdown 文件，最后把链接发到群里。如果你需要它定期输出长报告，建议在提示词里就约定好“如果内容超过 50 行，先生成文件再发链接”。

5.3 机器人不回复、无权限、收不到消息

这三个问题经常一起出现，核心原因大多是“应用权限和发布状态不对”。

• 检查权限列表：看 im:message 和 im:message.group_at_msg 是否已开通。
• 检查版本发布状态：在开发者后台“版本管理与发布”里，确认最新版本已经发布并且状态为“已启用”。如果只是创建了版本但没发布，机器人等于没有申请到权限。
• 检查事件订阅：确认事件 im.message.receive_v1 已添加，并且长连接状态是“已连接”。

另外，如果是在多维表格场景报权限错误，需要去“权限管理”里额外开通对应多维表格应用的权限，然后再次创建版本发布生效。

5.4 NAS 重启后服务不恢复

很多人部署好了机器，但 NAS 一重启，OpenClaw 没自动拉起来。其实这是 compose 配置的问题，只要在服务定义里加上 restart: unless-stopped，容器就会在守护进程启动后自动拉起。群晖的 Container Manager 和飞牛 NAS 的 Docker 都遵循这个规则。如果配置了但依然不正常，检查一下是不是手动停止过容器，因为 unless-stopped 不会启动一个被手动停止的容器，需要手动 start 一次。

常见问题速查表：

6. 后续还能怎么玩：从“聊天机器人”到“NAS 管家”

6.1 接入本地模型，做一个完全离线的助理

如果你不想把对话内容送到云端 API，可以在 NAS 上用 Ollama 跑小模型。在 Ollama 里拉取一个 7B 级别的量化模型，然后通过 OpenAI 兼容接口暴露给 OpenClaw。这样飞书里聊天的内容不会出内网，适合对隐私要求极高的场景。但别对大模型效果抱太高期望，7B 模型做些摘要、分类、简单问答还可以，让它完成复杂的任务调度会显得吃力。

6.2 让 OpenClaw 成为多维表格的自动化“填表员”

我最推荐的实际场景是：让 OpenClaw 定时读取某个多维表格里的任务状态，生成统计摘要发到群里。比如团队里大家每天更新“项目进度”表格，OpenClaw 每天早上九点自动汇总前一天的最新进度，发给所有人。这个能力比单纯发消息高级得多，它是真正把数据、会话、自动化串在了一起。

实现思路也不复杂：提前把多维表格的 app_token 和 table_id 写进 OpenClaw 的配置或工具脚本里，然后在系统里安排一个定时任务调用它。OpenClaw 收到定时任务后，自己读取表格数据、做聚合、生成总结、发送到飞书。整个过程可以完全无人值守。

6.3 定时提醒与主动推送

NAS 天然适合跑定时任务。OpenClaw 如果能配合 cron 使用，就可以做很多主动推送的活：每天早上推送天气和待办事项，每周五下午生成周报草稿，每天晚上提醒你备份照片。飞书消息支持强通知，手机和电脑都会弹出来，比普通的日历提醒体验更好。

我现在的做法是：定时用 crontab 调用 OpenClaw 的接口，触发一个“每日站会摘要”任务。任务内部读取多维表格数据，调用大模型生成总结，然后通过飞书消息发送到群里。整个链路跑了一个多月，稳定没出过岔子。

最后，说点真实体会

这套东西部署起来不难，但真正让它变成“好用”的助理，需要花时间调整提示词和工具链。不要指望一部署完它就什么都能干。最值得投入的方向，是结合你自己的日常习惯去设计任务：让周报自动生成、让待办每天都有人催你、让 NAS 的存储告警也通过飞书推给你。我踩过最大的坑就是并发会话锁和权限发布，这两个问题只要先解决，后面基本一路畅通。如果你也是 NAS 用户，手头又正好有闲置算力，真的可以试试把 OpenClaw 跑起来，接入飞书的那一刻，你会觉得这台 NAS 突然就“活”了。