最近我把个人 AI 助理的整套链路从头搭到了本地宿主机上用 VM 虚拟机跑了一套 Ubuntu Server消息入口放在飞书机器人中间用 OpenClaw 做智能体调度大模型后端接的是 Qwen 本地推理。折腾了几天中间踩了不少坑现在整体已经稳定跑了小半个月。这套组合解决的问题很直接——你想要一个能随时在聊天框里调用的私人助理但又不希望对话记录、知识库、工具调用过程全部托管在别人的服务器上。适合愿意花一晚上做环境调试、后续想深度定制智能体行为的开发者参考也适合想低成本验证“个人助理”到底能干什么的爱好者。1. 整条链路的角色拆解为什么是这四样拼在一起1.1 OpenClaw 是大脑的接线员很多人第一次看到 OpenClaw 会误以为它是个大模型其实完全不是。它更像一个消息网关加智能体调度器飞书里的消息推过来OpenClaw 负责判断该调用哪个模型、要不要触发工具调用、怎么把回复组装成飞书能识别的消息格式再发回去。它自己不做推理推理这活儿全部丢给后端的 Qwen。用生活里的话说OpenClaw 就是客厅里的那个智能遥控器你按的是飞书这个“面板”遥控器收到信号后去指挥电视、空调、音响各自干活干完之后再把结果汇总到你面前。没有它你就得自己写一堆处理消息回调、维护会话状态、调模型接口的胶水代码而且换一个 IM 入口整套逻辑全得重来。有了这一层消息从哪个渠道进来、模型用哪个、工具怎么调度都变成了可配置的东西。我最初看过一些商用方案它们确实开箱即用但定制门槛高很多内部逻辑是封闭的。OpenClaw 这类开源智能体框架的好处在于你能看到每条消息到底走了哪条路径能自己塞自定义工具也能随时换模型。这种可控性在个人助理场景里非常重要因为你不知道未来会往里面加什么奇奇怪怪的需求。1.2 飞书当入口IM 不只是聊天为什么选飞书而不是别的聊天工具理由其实很朴素——我日常办公就在飞书里工作群、文档、日程都已经沉淀在那里再把 AI 助理放进来使用成本几乎为零。你不需要打开另一个网页不需要切窗口在聊天框里打个字就完事了。飞书对于这类个人助理项目的友好程度比很多人想象中高。它的开放平台支持创建自建应用机器人能力齐全单聊、群聊、消息卡片都能处理。最关键的是事件订阅支持长连接模式也就是说飞书服务器可以通过一条长连接直接把消息推给本地服务不需要你有公网 IP不需要去配置 HTTPS 回调地址。这对跑在虚拟机里的服务来说简直是救命稻草省掉了内网穿透那一堆麻烦事。另外 IM 本身是一种天然适合 AI 交互的界面。聊天记录就是上下文异步消息适合长时间任务。比如你跟它说“帮我整理一份会议纪要”它不用像网页端那样一直挂着连接处理完直接把结果发回来就好。这种“消息即接口”的体验是命令行和网页都替代不了的。1.3 Qwen 做本地大脑数据留在自己手里大模型后端我选了 Qwen也就是通义千问的开源系列。为什么不是闭源 API一个很现实的原因是隐私。你把个人聊天记录、文档摘要、日程安排喂给远端 API等于默认信任服务商的数据处理策略。本地部署之后所有输入输出都留在自己的机器上不经过外网这种心理安全感是 API 方案给不了的。另一个原因是成本结构。如果你只是偶尔用API 按 token 计费问题不大但智能体场景下消息会频繁触发多轮对话加上系统提示词每次都占一批 token积少成多之后费用并不低。本地部署是一次性硬件投入后面怎么折腾都不再产生调用费。Qwen 系列在开源模型里属于中文能力扎实的那一批指令遵循和工具调用表现都不错而这两点恰恰是智能体最需要的。我用的 7B 量化版在纯 CPU 环境下虽然速度不算快但处理日常对话、总结、简单工具调用完全够用。如果以后需求变大模型文件换大一号就行链路不用动。1.4 虚拟机兜底折腾的隔离区把整套服务装在虚拟机里是我这次最不后悔的决定之一。虚拟机提供了一层完美隔离你可以在里面随便装系统、随便改配置、随便折腾依赖搞挂了也不会影响宿主机上的工作文件。配合快照功能每次大操作之前打一个快照出了问题秒回滚这种安全感是直接装在物理机上完全体会不到的。有人会问性能损失怎么办确实虚拟机会有一定开销但个人助理这种场景本身对延迟不敏感聊天框里多等一两秒根本无感。更重要的是虚拟机的网络模式和资源分配是可调的后期想迁移到别的物理机直接把整个虚拟机目录拷过去就行。对我来说这比在宿主机上裸装一套 Ubuntu 再装一堆服务要干净得多。2. 虚拟机与 Ubuntu 环境准备先把地基打牢2.1 给虚拟机分配多少资源才够用这一节先聊资源配置因为后面很多问题都出在资源不够上。我的宿主机是 32GB 内存的机器给虚拟机分配了 4 核 CPU、16GB 内存、80GB 动态磁盘。这个配置跑 Qwen 7B 量化版比较从容内存里除了模型本身还得留出系统缓存和框架运行空间。很多人容易低估内存需求。Qwen 7B 的 Q4 量化模型文件大约 4.7GB但 Ollama 加载模型时不只是把文件读进内存还要为 KV Cache 分配额外空间上下文越长占得越多。再加上 Ubuntu 系统本身、OpenClaw 进程、可能出现的中转日志12GB 内存属于紧巴巴的及格线16GB 才算舒服。如果你打算跑 14B 模型建议虚拟机内存直接给到 20GB 以上否则会出现加载到一半进程被杀的情况。CPU 方面4 核是起步6 到 8 核会让生成速度快不少。因为纯 CPU 推理吃的是多核并行能力核心数翻倍每秒生成的 token 数基本能涨一大截。磁盘给 80GB 是因为模型、日志、系统快照都会占空间动态分配模式下实际用多少占多少不用担心前期浪费。2.2 安装 Ubuntu Server 的几个细节镜像选择上我建议直接用 Ubuntu Server LTS 版本不要用桌面版。Server 版没有图形界面省下来的内存全都能给服务用而且你本来就会通过 SSH 远程操作图形界面根本用不上。安装过程里有两个地方值得注意。第一磁盘分区直接用默认的整个磁盘方案就好不需要手动分区除非你有特别的加密需求。第二安装到“软件选择”那一步时记得勾选 OpenSSH server这样装完就能从宿主机直接 SSH 登录不用在虚拟机窗口里敲命令。如果当时忘了勾选后面装一个 openssh-server 包再启动服务也一样。装完之后第一件事是更新系统sudo apt update sudo apt upgrade -y。这一步会把内核和基础库升到新版本避免后面装软件时碰到依赖版本太老的问题。再把 curl、wget、git 这些常用工具装上后面下载模型、拉代码都要用。整个过程十分钟出头不复杂但值得认真做一遍因为基础系统就像房子的地基后面所有服务都长在它上面。2.3 网络模式选择桥接还是 NAT虚拟机的网络模式我建议直接用桥接。桥接模式下虚拟机就像局域网里一台独立机器有自己的 IP宿主机、手机、其他电脑都能直接访问它。OpenClaw 通过长连接主动连飞书服务器不需要外部回连但你还是需要从宿主机 SSH 进去部署独立的局域网 IP 会让这一切简单很多。NAT 模式也不是不能用但你需要额外配置端口转发把虚拟机的 22 端口映射到宿主机否则 SSH 都连不进去。NAT 的多层地址转换对长连接、回调这类东西不友好排查网络问题时你会多一个变量要排除。所以除非你对网络很有把握否则就用桥接少给自己找麻烦。网络配好之后我给虚拟机设了静态 IP也就是在路由器后台绑定 MAC 地址或者在 Ubuntu 里直接写 Netplan 配置。静态 IP 的意义在于OpenClaw 配置、飞书回调、SSH 别名里的地址不会因为 DHCP 重新分配而失效。IP 一旦变了所有引用它的配置都得跟着改这种坑我踩过一次之后再也不碰了。3. Qwen 本地推理服务的部署模型这一环决定体验上限3.1 推理框架选型Ollama 比 vLLM 更合适本地跑 Qwen 的方式有好几种最常见的是 Ollama、llama.cpp、vLLM。我选了 Ollama因为它对个人用户太友好了装一个二进制就能用模型管理、量化、OpenAI 兼容接口全都内置不需要你自己编译也不需要手写加载脚本。vLLM 当然性能更强尤其是在 GPU 环境下吞吐量可以把 Ollama 甩开几条街。但它需要 CUDA、PagedAttention 这些配套配置复杂度高适合拿来做正式服务端。个人助理场景没有高并发没必要上这么重的方案。llama.cpp 则偏底层适合想手动调优的人但对大多数人来说反而增加了维护负担。如果你之前用过其他大模型工具会发现 Ollama 暴露的 API 是 OpenAI 兼容格式/v1/chat/completions这种端点跟主流生态完全对齐。这意味着 OpenClaw 这类框架只需要改一个 base_url 就能接上不需要写自定义适配层。生态兼容这件事在集成的时候省下的时间远远超出你的预期。3.2 模型选择与量化参数的真相Qwen 2.5 系列有很多尺寸和变体我做的是 7B Instruct 量化版。为什么要量化因为原版 7B 模型 FP16 格式要占约 14GB 内存个人机器跑起来很吃力量化之后体积直接砍到三分之一左右速度更快内存占用更少而能力损失在大多数任务上几乎可以忽略。Ollama 的模型标签里常见的q4_K_M是一种混合量化方案它对模型的不同层采用不同位宽在体积和效果之间折中得很好。实测下来q4_K_M 对于对话、总结、结构化输出这些场景非常稳没必要上 q8徒增内存压力。14B 版本我也试过生成质量确实更好但内存占用接近 9GB整机压力一下就上来了如果你的虚拟机内存只有 16GB还是老老实实跑 7B 吧。模型拉取这一步其实很简单ollama pull加上模型标签就会自动下载断点续传也做得很稳。但下载前建议确认一下磁盘剩余空间7B 量化模型虽然只有 4.7GB下载过程还会产生临时文件空间不够会直接失败。3.3 部署步骤与性能基线验证安装 Ollama 我用的是官方给的一键安装方式装完先确认服务状态是 running然后把 Ollama 设为开机自启。这一步很重要否则虚拟机重启之后服务不会自动拉起飞书消息就会石沉大海。# 安装完成后把服务设为开机自启 sudo systemctl enable ollama sudo systemctl status ollama接下来拉取模型并验证接口可用。ollama pull qwen2.5:7b-instruct-q4_K_M curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct-q4_K_M, messages: [{role: user, content: 用一句话介绍你自己}], stream: false }看到正常的 JSON 返回说明推理链路已经通了。我习惯在这个阶段顺手记录一下性能基线用ollama run进交互模式随便问几个问题观察每秒生成 token 数。纯 CPU 环境下7B 量化模型大约在每秒 8 到 15 个 token具体取决于 CPU 主频和内存带宽。这个速度虽然比不上云端但聊天场景完全够用因为人的阅读速度也就每秒几个字。隐藏的性能杀手是上下文长度。默认上下文拉得越长KV Cache 占的内存越多生成速度越慢。如果你只做日常聊天把上下文设置在 4096 左右就足够了太长不仅慢还会频繁触发内存交换。这个参数可以在启动 Ollama 时通过环境变量控制后面我会再细说。4. OpenClaw 的安装与配置把模型能力变成服务4.1 依赖准备与初始化流程OpenClaw 这类智能体框架通常依赖 Python 运行时和一堆第三方库部署方式分两种容器和裸进程。我选择直接跑在系统进程里少一层容器网络转发排错也更直观。如果你的系统比较干净建议先装好 Python 3.10 以上版本以及 pip然后按照项目文档把仓库克隆到/opt/openclaw这类专门目录。克隆完成后项目里通常会有一个初始化命令或者配置模板会生成config.yaml和其他必要的目录结构。我第一次初始化完习惯先看一下生成的配置文件结构确认哪些字段是必填的再开始改。这一步别跳过因为版本不同配置字段可能会有差异直接套别人写的现成配置容易踩到格式过期的坑。初始化完成之后我强烈建议先用 CLI 模式做一次冒烟测试。也就是说不接飞书直接在终端里跟 OpenClaw 对话看看它能不能正确调用后端的 Qwen。这样把模型链路和消息链路分开验证模型有问题先在这一步暴露后面接飞书时就不会两头都错排错范围一下子缩小了一半。4.2 接入本地 Qwen 的配置写法OpenClaw 支持 OpenAI 兼容接口而 Ollama 恰好就提供了这种接口所以模型配置部分非常顺。核心字段就是 base_url、model、api_key 这三样。Ollama 不校验 key随便填一个非空字符串就行但字段不能留空否则有些框架的请求会直接报错。下面是一份典型的配置片段你可以根据自己的模型标签和路径微调model: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 api_key: ollama-local model: qwen2.5:7b-instruct-q4_K_M temperature: 0.7 max_tokens: 2048 channels: feishu: app_id: cli_xxxxxxxxxxxxxx app_secret: xxxxxxxxxxxxxxxxxxxxxxxx event_mode: websocketbase_url 后面要带/v1因为 Ollama 的 OpenAI 兼容路由挂在/v1下面漏掉这个路径你会收到 404。max_tokens 我设 2048足够生成中等长度的回答又不会因为输出太长拖慢响应。temperature 按场景来普通对话 0.7 比较自然如果你让它做提取、总结这类任务降到 0.3 会更稳定。4.3 扩展配置工具调用与多角色OpenClaw 真正厉害的地方是可以注册自定义工具。比如让它在回答之前查一下本地日历、读一个文件、执行一段脚本然后把结果拼进回答里。这些工具本质上是函数返回 JSON 给模型Qwen 2.5 对 function calling 支持得不错所以工具调用的成功率在实测中很高。配置工具时注意描述写清楚一点。模型不像人它只能通过你写的 description 判断这个工具适不适合当前任务。比如一个“获取天气”的工具描述写成“根据城市名返回当前天气情况”模型就能准确触发。描述写得含糊模型就经常不调用或者乱调用。多角色方面我配置了一个默认助理角色也尝试加了一个专门做文本总结的“编辑”角色。不同角色对应不同 system promptOpenClaw 会根据消息上下文选用。这个功能特别适合把个人助理扩展成多功能工作台不过新手阶段建议先跑通一个角色再慢慢加别一上来就把系统搞得很复杂。5. 飞书机器人接入让智能体无处不在5.1 创建自建应用并开启机器人能力飞书接入的第一步不是写代码而是去开放平台后台创建企业自建应用。如果你自己就是企业管理员审核环节可以直接自己通过整个过程非常快。创建完应用之后第一件事是在“应用能力”里添加机器人能力这一步相当于给你的应用开通了一个能收发消息的身份。接下来是权限配置。在权限管理界面搜索消息相关的权限比如读取用户发给机器人的消息、以机器人身份发送消息然后把它们加到应用上。权限不开全后面会出现“消息能收到但回复不出去”或者“完全收不到消息”的诡异现象而且飞书的报错往往模棱两可排查成本很高。最后在版本管理里发布一个版本等审核通过后应用就正式生效了。如果你是测试阶段建议先只往自己的企业里发布别直接全员可见否则同事看到你机器人回消息卡顿体验会很尴尬。等你调好了再放开范围也不迟。5.2 事件订阅长连接是本地部署的最优解飞书事件订阅有两种模式长连接WebSocket和请求回调Webhook。我的建议非常明确本地部署无脑选长连接。因为回调模式要求飞书服务器能访问到你配置的地址这通常意味着你需要一台公网服务器或者在内网穿透工具上折腾 HTTPS、域名、白名单麻烦不说还会引入额外延时。长连接模式下你的 OpenClaw 作为客户端主动向飞书服务器发起 WebSocket 连接飞书通过这条连接把消息事件推过来。整个过程都是从内网向外发起不要求公网入站。这跟手机上的推送机制很像你的手机没有公网 IP但照样能实时收到消息因为它跟推送服务器保持着一条长连接。配置长连接时把事件订阅方式选成“使用长连接接收事件”然后在 OpenClaw 的飞书渠道配置里填上 App ID 和 App Secret事件模式设成 websocket。启动后你会在日志里看到连接成功的记录这时候再去飞书里给机器人发消息日志里就该出现消息事件了。5.3 单聊与群聊的验收姿势飞书机器人配置好之后验收方式可以分两层。第一层是单聊给你自己的机器人发一条普通消息比如“你好”看它是否回复。这一步能通过说明从飞书到 OpenClaw 到 Qwen 再到回消息的完整闭环已经打通了。第二层是群聊。把机器人拉进一个测试群然后在群里 它 再发消息。注意一定要 机器人飞书群聊里如果不 机器人默认是收不到消息的。这一层通过之后你就可以正式把它放进日常工作群了。我个人习惯是专门建一个“助理调试群”把机器人和自己都拉进去所有测试都在这里做不打扰别人日志也好查。验收时还要试一下工具调用。给它一个需要查数据或者执行脚本的任务观察日志里工具是否被正确触发结果是否拼进了最终回复。端到端都通了这套系统的价值才真正体现出来因为它从“聊天机器人”升级成了“能干活的智能体”。6. 联调与常见问题排查实录6.1 端到端联调流程我在所有配置完成后的第一次完整联调是按照“模型 - 框架 - 渠道”的顺序来的。先单独验证模型接口能返回正常内容再验证 OpenClaw 在终端模式下能调用模型最后才接飞书。每加一层只引入一个新变量出了问题立刻知道该往哪查。具体操作上我在三个环节各留了一个快速验证命令模型层用 curl 打接口框架层用 OpenClaw 自带的 CLI 发一句话渠道层直接在飞书里发消息看日志。三层都通了之后再做一次群聊 测试确认工具调用也能在真实场景里跑通。整个联调过程大概半小时但它能帮你把可能出错的位置从十几个缩小到一两个省下的排查时间远超半小时。6.2 常见问题速查表下面这几个问题是我在部署和后续使用中真实遇到的整理成速查表方便你对照排查。症状可能原因解决办法模型响应很慢内存不足触发 swap或上下文过长调低上下文到 4096增加虚拟机内存OpenClaw 连不上 Ollamabase_url 少了 /v1或 Ollama 没监听检查端口和配置路径确认 11434 在监听飞书完全收不到消息事件订阅模式没选长连接或权限没开进入后台确认事件模式检查应用权限消息能收到但回复不出去机器人发消息权限缺失在权限管理里补充 im 消息发送权限群聊里机器人没反应没有 机器人群发消息时 机器人虚拟机重启后服务全挂Ollama 和 OpenClaw 未设置开机自启用 systemd 托管这两个服务回复内容出现乱码系统区域设置或终端编码问题确认 LC_ALL 为 UTF-8终端用 UTF-8 编码6.3 稳定性与性能调优心得服务稳定运行一周之后我总结了三条经验新手可以直接抄。第一条是解决开机自启问题。Ollama 装完默认会注册 systemd 服务但 OpenClaw 需要你自己写一个 service 文件。把启动命令、工作目录、日志输出都写进去再通过 systemctl enable 设为开机自启。这样虚拟机断电重启后所有服务都会自动拉起来不需要每次手动敲命令。第二条是控制上下文长度和保持模型常驻内存。我给 Ollama 设置了环境变量把默认上下文限制在 4096同时把模型保持时间拉长避免每来一条消息都重新加载模型。模型反复加载一次要等十几秒这种延迟非常影响体验。设置之后只要内存够用模型就一直驻留在内存里响应速度明显提升。第三条是善用日志。OpenClaw 的日志是你最忠实的排错伙伴但日志文件不能无限涨否则磁盘会被写满。我在 systemd 服务里配置了日志轮转按大小切割保留最近几份就够。磁盘满了不会立刻让系统挂掉但会让模型加载失败或者数据库写入失败这种问题排查起来特别隐蔽预先做好日志轮转能避免一半麻烦。我个人在实际操作中最深的体会是这套链路的难点不在任何一个单独组件而在把四个组件协调起来。单看 OpenClaw、单看 Ollama、单看飞书后台文档都很清晰但把它们连在一起之后问题往往出在配置之间互相影响的地方。所以我的建议是始终保持“逐层验证”的习惯每加一层就确认一次不要等全部装完了再一次性排错。最后再分享一个小技巧在虚拟机上保存一个配置完善后的干净快照后续升级模型版本或者乱改配置都不用怕一秒回到可用状态。这个习惯我已经离不开了。如果你也在折腾类似的项目不妨就从“先跑通一条飞书私聊消息”这个最小闭环开始再慢慢加工具、加角色、加知识库你会发现自己能掌控的东西越来越多。