1. Clawdbot不是聊天机器人，是能自己“上班”的数字员工
Clawdbot在GitHub上狂揽数万星标，绝不是靠花哨的UI或营销话术——它踩中了当前AI落地最痛的三个点：被动响应、数据割裂、隐私焦虑。你用过那些大厂AI助手吗？发个“帮我总结这份PDF”，它回你一句“好的”，然后卡住；你想让它把微信里的会议纪要自动存进NAS的指定文件夹，它说“暂不支持该功能”；更别说所有对话、文档、截图都得上传云端，家里孩子的照片、公司未公开的财报PDF，全在别人服务器上跑。Clawdbot干的恰恰相反：它不等你开口，早上8点准时推来NAS昨日备份报告；你随手在飞书群里发张手机拍的发票照片，它秒识别金额、OCR提取明细、自动归档到“财务/2025Q2”目录；你上周让AI查过某款硬盘的固件更新路径，这周它看到新日志里出现相同错误码，立刻主动推送修复方案——整个过程，数据没离开你家NAS半步。
这背后是它彻底重构的运行逻辑：Clawdbot本质是一个本地AI网关（Local AI Gateway），不是传统意义上的“模型+前端”。它像一个装了智能大脑的路由器，一端连着你的各种数据源（NAS文件系统、飞书API、本地数据库），另一端连着大模型（可自由切换Qwen、Kimi、GLM等），中间用一套叫“Skill”的模块化技能系统做翻译和调度。比如“飞书消息处理”这个Skill，会监听飞书Webhook事件，自动解析消息类型（文本/图片/文件）、提取关键信息（时间/人名/金额）、调用对应工具（OCR引擎/日历API/文件系统写入），最后把结果塞回飞书。整个链路里，Clawdbot只负责“决策”和“调度”，真正的计算（OCR、语音转写、代码生成）由你本地部署的Ollama、Whisper.cpp或直接调用的云API完成——这才是它能在绿联NAS这种资源受限设备上稳定跑起来的核心原因。
很多人第一次听说Clawdbot，会下意识把它和ChatGPT网页版类比。但真正在绿联NAS上跑起来后，你会发现根本不是一回事。我部署完第二天，就让它自动处理飞书群里的采购申请：当有人@AI并发送“采购申请-打印机耗材”时，Clawdbot会立刻从NAS的“合同模板”库调出标准采购单，填入申请人姓名、日期、物品清单（从消息里自动提取），生成PDF后存到“待审批/耗材”目录，并@行政同事。整个过程耗时17秒，全程没碰过公网，所有PDF生成、存储、通知都在局域网内闭环。这种“感知-决策-执行”的完整链条，才是它被称为“数字员工”的底气。而绿联NAS之所以成为首选载体，关键在于UGOS Pro系统对Docker和虚拟机的原生支持，以及DXP系列机型（如DXP4800 Plus）配备的Intel奔腾8505处理器+32GB DDR5内存，足以支撑Clawdbot核心服务+1-2个轻量级模型（如Qwen2-0.5B）同时运行——既避免了树莓派的性能瓶颈，又比自建服务器省电安静。
提示：Clawdbot官方已更名为Moltbot，但社区仍习惯称Clawdbot。本文所有操作均基于v0.9.2版本，该版本对飞书API兼容性最佳，且无需修改源码即可接入飞书Skill。后续升级请务必查看CHANGELOG中关于
lark-skill的更新说明。
2. 绿联NAS部署不是“装软件”，而是构建AI运行沙盒
在绿联NAS上部署Clawdbot，最危险的认知误区就是把它当成普通Docker应用——点几下Web界面，填个镜像地址，启动就完事。实际操作中，90%的失败案例都源于忽略了NAS环境的特殊性：UGOS Pro系统本质是精简版Linux，它没有完整的包管理器，Docker容器默认无法访问宿主机的硬件设备（如GPU加速），且文件权限体系与通用Linux存在差异。我见过太多人卡在第一步：用Docker方式拉取Clawdbot镜像后，发现Web界面打不开，或者飞书机器人收不到消息。问题根源往往不是配置错了，而是Clawdbot需要读取NAS的Samba共享目录、调用飞书API的Token需要持久化存储、甚至日志文件要写入特定挂载点——这些需求，直接跑Docker容器根本满足不了。
因此，绿联NAS部署Clawdbot必须采用“双轨制”策略：核心服务走虚拟机，外围能力走Docker。具体来说，用UGOS Pro的虚拟机功能创建一台Ubuntu 22.04 LTS虚拟机（推荐2核CPU/4GB内存/40GB磁盘），作为Clawdbot的主运行环境；而像Ollama（本地大模型）、Whisper.cpp（语音转写）、Tesseract（OCR）这些计算密集型组件，则单独用Docker容器部署在NAS宿主机上，通过局域网IP让虚拟机内的Clawdbot调用。这种架构的好处极其明显：虚拟机提供完整的Linux环境，Node.js依赖、Python Skill、系统级权限全部可控；Docker容器则利用NAS的硬件直通能力，让Ollama能调用NPU（如DXP4800 Plus的Intel Arc GPU）加速推理，Whisper.cpp能直接读取NAS的视频文件流——两者通过标准HTTP API通信，互不干扰。
为什么非得用虚拟机？举个真实例子：Clawdbot的飞书Skill需要监听Webhook，这要求虚拟机有固定局域网IP且端口可被外部访问。如果直接在NAS宿主机跑Clawdbot，UGOS Pro的防火墙规则极其严格，开放18789端口需要手动编辑iptables，稍有不慎就导致NAS管理界面失联。而虚拟机网络模式设为“桥接（LinuxBridge）”后，它就像局域网里一台独立电脑，IP地址（如192.168.3.100）和端口完全由你掌控，飞书后台填Webhook地址时直接写http://192.168.3.100:18789/webhook/lark，零配置障碍。更重要的是，虚拟机环境完全隔离——哪怕Clawdbot某个Skill崩溃导致内存溢出，也只会杀掉虚拟机进程，NAS的文件服务、备份任务、媒体库依然稳如泰山。这种“故障域隔离”能力，是家庭用户敢把AI管家放进生产环境的底线保障。
2.1 虚拟机网络配置：让Clawdbot真正“活”在局域网里
绿联NAS虚拟机的网络配置，是整个部署中最容易被跳过的致命环节。很多人按教程启用“桥接模式”就以为万事大吉，结果Clawdbot启动后，飞书收不到回调，本地浏览器也打不开Web界面。问题出在两个细节上：虚拟桥接开关未启用，以及LinuxBridge网络接口未正确绑定。
首先，登录UGOS Pro管理后台，进入【控制面板】→【网络设置】→【虚拟桥接】，确保“启用虚拟桥接”开关是打开状态。这一步常被忽略，因为UGOS Pro默认关闭此功能以节省资源。如果此处未开启，后续所有网络配置都是无源之水。开启后，系统会自动生成一个名为virbr0的虚拟网桥设备，这是虚拟机获取局域网IP的基础。
其次，在【虚拟机管理】→【网络设置】中，将虚拟机的网络模式选为“桥接模式”，并在“LinuxBridge”下拉菜单中选择virbr0（而非默认的docker0或br0）。这里有个关键陷阱：UGOS Pro的br0是NAS宿主机的管理网桥，直接桥接到br0会导致虚拟机和NAS管理界面争夺同一IP段，引发ARP冲突。而virbr0是专为虚拟机设计的隔离网桥，它会自动为虚拟机分配192.168.100.x网段的IP（可通过virsh net-dumpxml default命令查看DHCP范围），完美避开NAS主网段（通常是192.168.3.x）。
验证是否成功，只需在虚拟机Ubuntu中执行：
ip a | grep "inet 192.168" # 正常应返回类似：inet 192.168.100.101/24 brd 192.168.100.255 scope global dynamic noprefixroute eth0如果看到的是192.168.3.x网段，说明桥接到了错误的网桥，需立即修改虚拟机网络设置。此时，从你办公电脑的浏览器访问http://192.168.100.101:18789，就能直接打开Clawdbot Web界面——这才是它真正“活”在局域网里的标志。
2.2 Ubuntu系统安装避坑：SSH和国内源是生命线
在虚拟机中安装Ubuntu 22.04 LTS时，有三个选项看似微小，实则决定后续80%的操作效率：
第一，必须勾选【Install OpenSSH server】。绿联NAS的虚拟机管理界面不支持剪贴板共享，你在Web控制台里敲命令，复制粘贴基本是摆设。而SSH连接后，用Mac的Terminal或Windows的PuTTY，就能流畅地复制长命令、粘贴API Key、拖拽上传配置文件。更重要的是，Clawdbot的onboard配置流程全程依赖命令行交互，没有SSH，你只能对着黑屏Ctrl+C Ctrl+V，效率极低且极易出错。
第二，镜像源必须换为国内源。Ubuntu安装过程中会提示选择“mirror address”，默认是archive.ubuntu.com，但在国内访问极慢，经常卡在“正在下载软件包”阶段。直接替换为阿里云镜像：https://mirrors.aliyun.com/ubuntu/。这不仅能加速安装，还能避免因网络超时导致的包损坏。安装完成后，还需手动更新apt源列表：
sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo apt update第三，用户名和密码务必简单易记。不要用复杂密码，因为后续所有SSH连接、Clawdbot配置、飞书Token存储都依赖这个账户。我建议用户名设为clawd，密码设为clawd123（部署完成后可再加强）。原因很简单：Clawdbot的onboard流程中，有一步需要输入“sudo密码”来安装systemd服务，如果你设了复杂密码，每次输错一次，就得重启整个配置流程——而onboard本身要执行10+个交互步骤，容错率极低。
注意：绝对不要用
sudo -i切换到root用户操作！UGOS Pro虚拟机的root账户被深度锁定，强行切换会导致Clawdbot的systemd服务注册失败，报错Failed to connect to bus: No such file or directory。所有操作请严格在clawd用户下执行，需要用root权限时，统一用sudo前缀。
3. Node.js环境不是“装个包”，是Clawdbot的呼吸系统
Clawdbot用Node.js开发，这决定了它的运行高度依赖Node.js环境的纯净度和版本兼容性。网上很多教程教人用apt install nodejs，结果装上的是Ubuntu仓库里的v12.x版本，而Clawdbot v0.9.2明确要求Node.js v20.10.0+。更隐蔽的坑是：Node.js的全局模块（如pm2进程管理器）和Clawdbot的本地依赖（node_modules）如果混用，会导致Skill加载失败，报错Error: Cannot find module 'lark-sdk'。所以，Node.js环境的搭建，本质是在为Clawdbot构建一个专属的“呼吸系统”——既要供氧（提供稳定运行时），又要过滤杂质（隔离依赖冲突）。
3.1 为什么必须用NodeSource安装而非apt？
Ubuntu官方仓库的Node.js版本严重滞后。以22.04 LTS为例，apt list nodejs显示最高版本是v12.22.9，而Clawdbot的package.json中engines.node字段明确写着>=20.10.0。强行用旧版本启动，会在npm install阶段就报错：
error clawdbot@0.9.2: The engine "node" is incompatible with this module. Expected version ">=20.10.0", got "12.22.9".NodeSource提供的安装脚本（setup_22.x）则直接从官方二进制源拉取v22.x最新LTS版，完美匹配Clawdbot需求。执行以下三行命令，是经过千次验证的黄金组合：
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejs node --version # 必须返回 v22.x.x这里的关键是sudo -E bash -中的-E参数：它保留当前用户的环境变量（尤其是PATH），确保安装后的node和npm命令能被系统立即识别。如果漏掉-E，安装完node --version会报“command not found”，因为新安装的二进制文件路径（/usr/bin）未加入PATH。
3.2 npm权限管理：绕过sudo的终极方案
Clawdbot安装脚本（install.sh）内部大量调用npm install，如果npm全局目录（/usr/lib/node_modules）权限属于root，普通用户clawd执行时就会报错：
npm ERR! code EACCES npm ERR! syscall access npm ERR! path /usr/lib/node_modules网上常见解法是sudo chown -R $USER:$USER /usr/lib/node_modules，但这会破坏系统稳定性。更安全的做法是重定向npm全局目录到用户空间：
mkdir ~/.npm-global npm config set prefix '~/.npm-global' echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc source ~/.bashrc这样，所有npm install -g命令都会把模块装到/home/clawd/.npm-global下，clawd用户拥有完全控制权。Clawdbot的install.sh脚本检测到npm可写，就会静默跳过权限检查，安装成功率从60%提升到100%。
3.3 验证Node.js环境的三个必测点
安装完Node.js，别急着跑Clawdbot，先用这三个命令做压力测试，确保“呼吸系统”健康：
版本与架构验证：
node -v && npm -v && node -p "process.arch" # 正常输出：v22.14.0, 10.9.0, x64 （绿联NAS是x86_64架构，非arm64）如果
process.arch返回arm64，说明你误装了ARM版Node.js（常见于用WSL或树莓派教程照搬），必须卸载重装x64版。HTTPS证书验证（飞书API的生命线）：
node -e "require('https').get('https://open.feishu.cn', r => console.log(r.statusCode))" # 正常返回：200若返回
UNABLE_TO_VERIFY_LEAF_SIGNATURE，说明Node.js的CA证书库过期，需执行：sudo apt install ca-certificates && sudo update-ca-certificates大内存分配测试（防止Clawdbot OOM崩溃）：
node -e "console.log(Buffer.alloc(1024*1024*500).length)" # 正常输出：524288000 （500MB缓冲区分配成功）如果报
FATAL ERROR: invalid array length Allocation failed - JavaScript heap out of memory，说明虚拟机内存不足或Node.js堆内存限制太小，需在启动Clawdbot时加参数--max-old-space-size=3072。
4. Clawdbot onboarding不是“点下一步”，是AI员工的入职体检
clawdbot onboard命令看似只是个向导，实则是Clawdbot的“入职体检”流程。它要检查12项核心能力：网络连通性、文件系统读写、模型API可达性、飞书Webhook注册、Skill依赖完整性……任何一项失败，AI员工就无法上岗。网上教程常把onboard描述成“全自动”，但实际操作中，85%的用户会卡在“gateway bind”或“auth token”环节。这是因为onboard的交互逻辑极度反直觉：它要求你先配置好所有外部依赖（飞书Token、模型API Key），再反向验证，而大多数人习惯先启动服务再配参数。
4.1 Gateway Bind：监听所有网卡的底层逻辑
onboard中问到gateway bind时，选项有LAN (0.0.0.0)、localhost、custom IP。99%的人选LAN (0.0.0.0)，却不知其背后的网络原理。0.0.0.0不是随便写的，它是IPv4的“通配地址”，告诉Clawdbot的HTTP服务器：“把我的服务绑定到本机所有网络接口上”。这意味着：
- 从虚拟机内部访问：
curl http://localhost:18789 - 从NAS宿主机访问：
curl http://192.168.100.101:18789 - 从你办公电脑访问：
curl http://192.168.100.101:18789
如果选localhost，服务只绑定到127.0.0.1，外部设备根本连不上；如果选custom IP填错（如填成NAS的192.168.3.10），Clawdbot会启动失败，报错Error: listen EADDRNOTAVAIL。更隐蔽的坑是：UGOS Pro虚拟机的/etc/hosts文件默认把localhost映射到::1（IPv6），而Clawdbot的HTTP服务器默认只监听IPv4。所以即使选了localhost，也可能因IPv6优先导致连接超时。0.0.0.0是唯一能覆盖所有场景的安全选项。
4.2 Auth Token：飞书机器人身份的动态密钥
onboard中gateway auth选项，必须选Token而非None或Basic Auth。这不是为了安全，而是飞书API的强制要求。飞书机器人的Webhook认证机制是：每次飞书向你的Clawdbot发送消息时，会在HTTP Header中携带X-Lark-Signature和X-Lark-Timestamp，Clawdbot必须用你配置的Token+时间戳+原始Body生成HMAC-SHA256签名，与Header中的签名比对。如果选None，飞书会直接拒绝发送消息，报错401 Unauthorized；如果选Basic Auth，飞书根本不认这个Header格式。
Token的生成有严格规范：必须是32位以上随机字符串，且不能含特殊字符。我试过用openssl rand -hex 16生成的Token（含a-f0-9），飞书验证通过；但用pwgen -s -y 32生成的含!@#的Token，Clawdbot解析时会因URL编码问题失败。最稳妥的方法是用Node.js生成：
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" # 输出类似：e8a3b4c7d9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6把这个字符串填入onboard，Clawdbot会自动存入~/.clawdbot/config.json，后续所有飞书消息验证都依赖它。
4.3 Skill Dependencies：按需加载的AI技能包
onboard最后一步Install missing skill dependencies，强烈建议选no跳过。原因很现实：Clawdbot的Skill生态虽丰富，但90%的Skill（如password-manager、apple-notes）在绿联NAS环境下根本跑不起来——它们依赖macOS的Keychain、iOS的HealthKit等专有API。强行安装不仅浪费时间，还会因依赖缺失导致npm install报错，中断整个onboard流程。
正确的做法是：先用clawdbot onboard完成基础配置，启动Clawdbot服务（clawdbot start），然后打开Web界面http://192.168.100.101:18789，在【Skills】页面手动启用你需要的Skill。比如飞书相关功能，只启用lark和file-handler两个Skill即可。larkSkill负责接收/发送飞书消息，file-handler负责处理飞书传来的图片、PDF、Excel。其他Skill（如git、calendar）留待后续扩展，按需安装，避免“一步到位”带来的兼容性灾难。
经验：Clawdbot的Skill安装本质是
npm install，所以必须确保虚拟机内已配置好npm国内源。执行npm config get registry，确认返回https://registry.npmmirror.com/。若为https://registry.npmjs.org/，立即执行npm config set registry https://registry.npmmirror.com/，否则Skill安装会超时失败。
5. 飞书Skill接入不是“填个Token”，是构建双向通信管道
Clawdbot的飞书Skill，远不止是把飞书机器人Token填进配置文件那么简单。它要解决三个核心问题：消息路由（谁发的消息给谁处理）、上下文保持（如何记住上一条指令）、执行反馈（任务完成如何通知用户）。很多用户部署后发现，飞书群里@AI没反应，或者AI回复了但内容驴唇不对马嘴，根源都在这三层管道没打通。
5.1 飞书开发者后台配置：Webhook与事件订阅的精准匹配
在飞书开发者后台（https://open.feishu.cn）创建机器人时，最关键的设置在【安全设置】和【事件订阅】两处：
【安全设置】中，IP白名单必须填Clawdbot虚拟机的IP（如
192.168.100.101），而不是NAS的IP（192.168.3.10）。因为飞书发送Webhook时，目标地址是你在onboard中配置的http://192.168.100.101:18789/webhook/lark，流量直接到达虚拟机，不经过NAS宿主机。如果填错IP，飞书会因“IP不在白名单”拒绝发送，Clawdbot日志里看不到任何请求记录。【事件订阅】中，必须勾选
message和file事件。message事件让Clawdbot能收到文本消息（包括@消息），file事件让它能接收飞书传来的图片、PDF等附件。很多人只勾选message，结果用户发张发票照片，Clawdbot完全无感。更关键的是，message事件的“校验类型”必须选Encrypt（加密），因为Clawdbot的飞书Skill默认启用AES-256加密，如果选Plain（明文），Clawdbot会因解密失败丢弃所有消息。
5.2 消息路由机制：从群聊到个人助理的智能分流
Clawdbot默认把所有飞书消息都当作“群聊指令”处理，这会导致严重问题：你在工作群@AI查天气，它可能把结果发到整个群；而你想让它私聊你查NAS剩余空间，它却在群里广播。解决方案是启用消息路由（Message Routing），在Clawdbot Web界面的【Settings】→【Lark】中，开启Route by chat type，并配置：
Group Chat：路由到default工作区，执行通用指令（如“总结今日日报”）Private Chat：路由到personal工作区，执行个人指令（如“查我NAS的硬盘温度”）
这样，Clawdbot就能区分消息来源，群聊指令在群内回复，私聊指令只发给你。路由规则基于飞书API返回的chat_type字段，Clawdbot在接收到消息后，会先解析event.message.chat_type，再决定调用哪个工作区的Skill——这是它实现“多身份AI员工”的技术基石。
5.3 上下文保持：跨会话记忆的本地化实现
Clawdbot的“持久记忆”功能，依赖一个叫memory-store的模块，它默认把记忆存到SQLite数据库（~/.clawdbot/memory.db）。但问题来了：SQLite是文件锁数据库，当多个飞书消息并发到达时（如群内多人同时@AI），会出现database is locked错误，导致部分消息丢失。解决方案是改用Redis作为记忆后端，而绿联NAS的Docker正好能跑Redis：
在NAS宿主机执行：
docker run -d --name redis-clawd -p 6379:6379 -v /etc/clawd/redis:/data redis:alpine在Clawdbot Web界面【Settings】→【Memory】中，将
Store Type改为Redis，填入redis://192.168.3.10:6379（NAS宿主机IP）。
这样，所有记忆操作都变成Redis的原子命令，彻底解决并发锁表问题。实测表明，启用Redis后，Clawdbot在10人以上活跃群聊中，消息处理成功率从72%提升到99.8%，且能准确记住跨天对话：“昨天让我查的硬盘型号是什么？”——它真能从记忆库里翻出WD Red SN700 2TB。
6. 实战场景：让Clawdbot成为你NAS的“主动管家”
部署完成只是起点，Clawdbot的价值体现在它如何把NAS从“被动存储”变成“主动服务”。下面三个真实场景，展示了它如何无缝融入你的数字生活：
6.1 场景一：飞书群内自动归档会议纪要（OCR+NAS写入）
需求：市场部每天在飞书群发会议录音和PPT，需自动转文字、提取重点、存NAS归档。
Clawdbot配置：
- 启用
lark、file-handler、whisper-cpp（语音转写）、tesseract（OCR）Skill - 在Web界面【Workspaces】创建
meeting-assistant工作区 - 设置触发词：
/meeting（群内发/meeting即启动流程）
执行流程：
- 用户在飞书群发
/meeting+ 上传MP3录音文件 - Clawdbot监听到
file事件，调用whisper-cpp容器（http://192.168.3.10:8080/transcribe）转文字 - 将文字送入Qwen2-0.5B模型，Prompt为：“提取会议纪要：时间、主持人、决议事项、待办人。格式：Markdown”
- 生成Markdown文件，用
fs.writeFileSync写入NAS路径/share/Meeting/2025Q2/20250405-市场部周会.md - 在飞书群回复：“已归档至[会议纪要/2025Q2]，点击查看”
关键技巧：NAS的Samba共享目录/share/Meeting需在Clawdbot虚拟机中挂载。执行：
sudo mkdir -p /mnt/nas-meeting sudo mount -t cifs //192.168.3.10/Meeting /mnt/nas-meeting -o username=admin,password=xxx,uid=clawd,gid=clawd这样Clawdbot就能像操作本地文件一样写入NAS，无需FTP或API。
6.2 场景二：NAS异常主动告警（日志监控+飞书通知）
需求：NAS硬盘温度超阈值、RAID降级时，自动发飞书告警。
Clawdbot配置：
- 启用
shellSkill（执行系统命令） - 创建
nas-monitor工作区 - 设置定时任务：每5分钟执行
smartctl -a /dev/sda | grep "Temperature_Celsius"（查硬盘温度）
执行流程：
- Clawdbot用
child_process.exec运行smartctl命令 - 解析输出，提取温度值（如
42） - 若
>45，则调用飞书API发送消息：“⚠️ 硬盘sda温度42°C，接近阈值45°C！请检查散热” - 消息发送到预设的“运维告警”飞书群
避坑经验：smartctl命令需sudo权限，但Clawdbot默认以clawd用户运行。解决方案是给clawd用户免密执行权限：
echo "clawd ALL=(ALL) NOPASSWD: /usr/sbin/smartctl" | sudo tee /etc/sudoers.d/clawd这样既保证安全，又避免sudo: no tty present错误。
6.3 场景三：家庭相册智能整理（人脸识别+NAS分类）
需求：手机拍的照片自动同步到NAS，Clawdbot识别家人面孔，按人名建文件夹归档。
Clawdbot配置：
- 启用
face-recognitionSkill（基于face_recognition库） - 创建
family-photo工作区 - 设置文件监听：监控NAS路径
/share/Photo/Upload
执行流程：
- 手机通过绿联App把照片同步到
/share/Photo/Upload - Clawdbot的
fs.watch监听到新文件，调用face_recognition.compare_faces - 与预存的家人脸谱（
/share/Photo/FaceDB/）比对，识别出“爸爸”、“女儿” - 将照片移动到
/share/Photo/Family/爸爸/20250405.jpg和/share/Photo/Family/女儿/20250405.jpg - 发飞书私信：“已为您归档5张照片：爸爸3张，女儿2张”
性能优化：人脸比对耗CPU，直接在虚拟机跑会卡顿。解决方案是用Docker跑专用容器：
docker run -d --name face-recog -v /share/Photo:/data -p 8081:8080 face-recognition-apiClawdbot通过http://192.168.3.10:8081/recognize调用，释放虚拟机资源。
7. 运维与升级：让AI员工持续进化不掉线
Clawdbot不是一劳永逸的“装完就跑”，它需要像真实员工一样定期“体检”和“培训”。以下是我在绿联NAS上维护3个月总结的运维铁律：
7.1 日志诊断：读懂Clawdbot的“健康报告”
Clawdbot的日志是排错的第一手资料，但默认日志级别（info）太嘈杂。在~/.clawdbot/config.json中，把logLevel改为debug，并添加logFile：
{ "logLevel": "debug", "logFile": "/home/clawd/logs/clawdbot.log" }这样所有日志会写入文件，方便用tail -f /home/clawd/logs/clawdbot.log实时监控。重点关注三类错误：
Webhook timeout：飞书消息超时，检查虚拟机网络和飞书IP白名单Model API error：大模型调用失败，检查Ollama容器是否运行（docker ps | grep ollama）Permission denied：文件写入失败，检查NAS挂载点权限（ls -ld /mnt/nas-meeting）
7.2 版本升级：平滑过渡不中断服务
Clawdbot升级不是npm update那么简单。v0.9.2升级到v0.10.0时，lark-skill的API有 breaking change。安全升级流程：
- 停止服务：
clawdbot stop - 备份配置：
cp ~/.clawdbot/config.json ~/.clawdbot/config.json.bak - 升级：
curl -fsSL https://clawd.bot/install.sh | bash -s -- --upgrade - 检查依赖：
cd ~/.clawdbot && npm ci --only=production - 启动：
clawdbot start - 验证：在飞书群发测试消息，确认Webhook回调正常
提示：
npm ci比npm install更安全，它会严格按照package-lock.json安装，杜绝“看似升级成功，实则依赖错乱”的陷阱。
7.3 资源监控：给AI员工配个“健康手环”
绿联NAS资源有限，Clawdbot跑久了会内存泄漏。我用htop实时监控，发现clawdbot进程内存常驻在1.2GB，但偶尔飙升到2.8GB。解决方案是加内存限制：
# 编辑systemd服务文件 sudo