OpenClaw自托管AI网关实操手册：模型路由、Skill与数据主权

你有没有过这种瞬间——花了一个下午跟某个AI助手梳理清楚的项目方案第二天想再翻出来发现它已经被“记忆优化”折叠进某个遥远的会话列表里。几个月前我连续遇到几次这种事以后终于决定不再依赖任何一家云端助手的存档把目光放到了自托管这条路上。折腾了一段时间现在主力设备上跑着的就是OpenClaw这个AI助手网关。这篇文章不是官方文档翻译也不是安装手册复读只是我这段时间踩坑之后的实操复盘希望能给同样想把数据握在自己手里的朋友省掉一点弯路。先说结论OpenClaw解决的核心问题不是“再给你一个AI聊天窗口”而是让你自己决定AI跑在哪里、记忆存在哪里、能调用哪些本机能力。适合的对象也很明确——已经有本地模型基础、对隐私有要求、愿意花点时间维护配置的人。如果你只想要一个开箱即用的云端助手那没必要折腾但如果你受够了“今天记不住昨天的事”和“数据都在服务商手里”这两个老问题下面这些内容可以接着看。1. 为什么需要“AI助手网关”一个不聊天的层反而解决了大问题1.1 你的对话记录到底存在哪里大部分人在用云端AI助手的时候很少会想一件事你和它的每一句话、上传的每一个文档、授权它读取的每一份资料最终都存在别人的服务器上。大多数服务条款里都写明了使用者协议但说实话普通人不会去逐条读。我见过一个同样做开发的朋友把自己公司的半年度经营数据粘贴给AI助手做复盘结果三个月后那条对话被官方“智能清理”了。数据到底是被训练了、被删了、还是被内部人员看过了你拿不到任何审计记录。更要命的是这类服务的记忆力是平台替你管的。你今天跟它聊了十篇论文的要点下周再去问它可能只剩下一个模糊的摘要因为平台做了上下文压缩。你想导出一条完整的原始对话对不起很多产品根本不提供导出功能。这就像你把日记本交给别人保管对方答应“随时可以看”但每次翻阅都要经过它的允许而且它会自作主张帮你擦掉几页。自托管这件事说白了就是把日记本拿回自己抽屉里。1.2 “网关”到底指什么很多朋友一听“网关”两个字就想到路由器、网络设备觉得跟AI八竿子打不着。其实逻辑是相通的。企业网络里网关是进出流量的统一关口内网的机器不用直接暴露给外部所有请求都走这一个口子统一做转发、校验、过滤。AI助手网关也是这个概念AI服务的接入、消息的路由、工具的执行全部集中在一个你自托管的层里由这个层来决定“这句指令交给哪个模型”“要不要读取本地文件”“执行结果存在哪里”。你把它想成一个“总机接线员”。以前是你分别打电话给三家不同的AI公司每家都要建档、都要交一份资料现在你打给总机总机按你的规则转接给对应的人最后把通话记录存在你自己的话务室里。这就是OpenClaw这类项目跟普通客户端最根本的区别。普通客户端只是“连到某一个AI服务的门”网关则是“你自家装的门”并且这扇门后面的走廊、房间、储物柜都是你的。1.3 OpenClaw与普通AI客户端的差异我整理过一张对比表放在一起看会直观很多维度常见云端AI客户端OpenClaw自托管网关账号体系必须注册厂商账号不需要云端账号本地配置即可模型来源厂商内置不可选可配置多家API也可接Ollama等本地模型对话记录存在服务商服务器存在本地数据库可导出可删除工具调用平台预设受限制通过Skill/连接器自己注册本机能力更新策略平台强制升级随时变自己控制版本想更才更数据链路黑盒全部可审计这不是说云端客户端一无是处它的“开箱即用”确实更省事。但OpenClaw把“AI服务的最终控制权”交回给你这一步对很多开发者来说价值极大。你可以对着一个完全可审计的系统做调试出了问题查日志就好而不是去猜“厂商今天是不是又改算法了”。2. 拆解OpenClaw的调度逻辑模型路由、记忆与Skill体系2.1 模型路由同一份指令走API还是走本地Ollama很多人第一次用OpenClaw会问一个问题它是不是必须接外部API才能用算力答案是不一定。它的算力来源完全取决于你在配置文件里怎么定义模型提供方。你可以只接Ollama让所有请求都在本机完成也可以把不同类型的请求拆分简单问答走本地模型复杂推理走云端API。这个设计在项目里叫“模型路由”model routing。我自己的配置大致长这样[model] default_provider local [model.providers.local] type ollama base_url http://127.0.0.1:11434 model qwen2.5:14b [model.providers.openai] type openai api_key sk-xxxx model gpt-4o-mini [[model.routes]] name math_and_code provider openai condition task_type math || task_type code这里最关键的是condition字段的写法不同版本的OpenClaw支持的语法略有差异有的是写内置的task_classifier有的是直接让本地小模型做一次意图判断。不管哪种思路都是一样的先用最便宜、最隐私的本地模型处理大部分请求只有命中特定条件时才转给外部API。这么做的好处我能列出一串来全本地方案的延迟通常更低因为省去了网络往返隐私敏感内容默认留在本机云端API的消耗量被压到最低账单好看断网环境下基本的辅助问答依然可用。所以我建议刚上手的人别急着配云API先用Ollama把链路跑通再说。等确认本地模型确实无法满足某些场景再逐步加路由规则这样后续排查问题也容易定位。2.2 记忆与上下文自托管网关如何管理你的历史会话普通聊天工具的记忆是“模型上下文窗口”的事窗口一满就开始遗忘。OpenClaw的做法多了一层它先把完整的对话记录落到本地数据库里给模型看的是经过摘录和筛选的上下文片段。这个设计非常实在。因为模型上下文窗口现在是挺宽但也没宽到能把几个月的历史全塞进去而且全塞进去的成本和延迟都非常高。OpenClaw有个“记忆服务”的概念通常会启用一个轻量的向量数据库来存放历史消息摘要。每次会话开始前它会把相关度最高的几条旧记忆检索出来当作背景信息补进提示词。这么做有一点好——它真的能让你感觉“这个助手记得我”。有一次我在一个项目中断两周后问OpenClaw“上次我们讨论到哪了”它从本地向量库里捞出了之前那几条关键结论回复直接命中主题。那一下我确实觉得云端助手的“记忆”换来换去本质上还是借来的这种放在自己电脑里的记忆才踏实。不过要注意记忆服务本身也需要配置。如果你开着文档扫描它会定时读指定目录里的文本做索引。这个能力是个双刃剑索引做得好问答质量会明显提升做不好比如目录权限没设对它会把乱七八糟的缓存文件也灌进库里导致检索噪声非常大。我给个建议记忆和文档扫描的目录一定要单独建一个纯文本目录不要指到整个用户主目录。2.3 Skill从“被动回答”到“主动接活”的执行机制如果说模型路由和记忆让OpenClaw“记得住”那Skill体系就是让它“干得动”。所谓Skill本质上是一段注册好的函数或脚本模型在回答过程中发现某个需求就会调用对应的Skill来执行。这个概念跟目前很多助手工具的Function Calling很像但OpenClaw更强调本地系统能力的开放。举个例子你写一个“查询磁盘剩余空间”的Skill那么在对话里说“看看根目录还有多少空间”模型的回复就不再是一句“建议您打开文件管理器查看”而是真的执行一段df -h命令再把结果整理成自然语言回给你。这就是从“会聊天”到“会干活”的区别。这些Skill的调度核心在于模型要先判断意图再决定调用哪个工具工具返回结果后再组织语言。整个链路都是可配置、可扩展的。我在用的Skill大约二十来个涵盖阅读本地Markdown、执行定时提醒、操作小米网关设备、查询NAS上某个目录的文件列表等。后面专门开一章讲配置细节这里先强调一个观点Skill才是自托管AI网关区别于普通聊天工具的灵魂值得花最多时间去维护。3. 部署实操Ubuntu、Windows、安卓Termux的三条路线与排错3.1 我为什么推荐把服务主体放在Ubuntu上部署之前先聊选型。我折腾过三个位置Ubuntu服务器、Windows桌机、安卓旧手机。最终把OpenClaw服务端放在一台24小时开机的Ubuntu小主机上Windows和安卓都只当“瘦客户端”来用。原因很简单OpenClaw这类项目需要同时跑模型推理、向量存储、定时任务、可能还要挂载NAS目录这些东西在Linux下的权限管理最干净systemd能让你一条命令重启服务日志集中管理出问题也好排查。Windows不是不能跑但作为长期服务进程各种更新重启、电源策略都会捣乱。安卓则受限于进程后台限制撑不起完整链路。所以如果你是新手我强烈建议先在一台Ubuntu机器上跑通再考虑其他平台。命令整体是这么一套具体以官方仓库README为准不同版本依赖略有不同sudo apt update sudo apt install -y git python3-venv python3-pip nodejs git clone https://github.com/openclaw/openclaw.git cd openclaw python3 -m venv .venv source .venv/bin/activate pip install -e . openclaw initopenclaw init会生成一个默认配置目录里面包括主配置config.toml和若干子模块目录。装完之后先别急着启动去config.toml里把模型提供方改成本地Ollama然后启动openclaw serve首次启动会看到一堆日志刷屏这是正常的。这时在另一个终端用openclaw ping或者直接curl一下网关的本地端口确认进程活了就行。我实测首次启动容易卡在“模型加载”这一步因为Ollama那边如果还没把目标模型下载完网关会一直等。这个不算Bug只有一点耐心等模型拉完就好。真正容易踩坑的反而是默认端口openclaw serve默认监听8080如果你机器上已经跑了其他Web服务记得在config.toml里把监听端口改掉并建议把监听地址设为127.0.0.1避免局域网里任何设备都能直连你的网关。初始化完成后用systemd托管是最省心的方式。写一个/etc/systemd/system/openclaw.service指向你虚拟环境里的可执行文件设置成开机自启之后基本就是零维护。这里有个细节systemd里要指定User选项不要用root跑服务。原因很直白Skill可以执行本机命令万一哪个Skill写得不严谨用root跑的话风险窗口太大。3.2 Windows companion配置最容易卡住的环节Windows端OpenClaw叫“companion”它的角色是系统级的辅助进程负责把网关能力接入Windows的剪贴板、通知中心、语音输入这些系统组件。你可以在Ubuntu服务器上跑核心服务然后Windows电脑跑companion连过去这样既不牺牲稳定性又能享受桌面端的便利。配置过程中我见过最多人卡住的地方有两个。第一是Windows防火墙拦截了companion访问局域网内的网关端口。症状很典型companion界面显示“服务未连接”但你去浏览器里访问网关HTTP端口又是通的。排查思路很简单在Windows高级防火墙里给companion放行专用网络访问或者临时关防火墙测试一下确认是这块的问题再精准放行。第二是路径问题。companion的配置目录如果放在带中文和空格的路径下部分内嵌脚本会找不到资源。别问我是怎么知道的问就是我曾经在“D:\软件\AI助手\我的网关”下折腾了一个晚上最后把所有目录改成纯英文才跑通。Windows端的底层逻辑有时对这些细节格外敏感遇到莫名其妙的问题先检查路径。还有一个值得说的点companion的剪贴板监控功能默认是开着的它会实时读取系统剪贴板判断有没有可以交给网关处理的内容。这个功能好用是好用但如果你经常复制敏感内容比如密码、密钥建议在配置里把剪贴板监控关掉只保留手动唤起。否则你以为开了一个助手实际上是开了一个“自动读取你所有复制内容”的监控器跟数据自主的初衷就背道而驰了。3.3 Termux安卓端把助手装进口袋的细节与限制在安卓上部署OpenClaw主流方式是用Termux。它给你一个完整的Linux用户空间可以安装Python、Node、Git等环境。具体步骤大致是pkg update pkg install git python nodejs-lts git clone https://github.com/openclaw/openclaw.git cd openclaw pip install -e . openclaw serve --config-dir /sdcard/Download/.openclaw把配置目录放到/sdcard/Download这类共享目录是为了方便你直接在文件管理器里编辑配置不用开编辑器的终端。这个做法我在多个项目里都用了省事很多。但要说句实在话Termux里跑完整的OpenClaw是很受限的。主要问题有三个后台限制安卓的Doze省电机制会把后台进程冻结除非你把它加进电池白名单并打开Termux的“唤醒锁”功能在Termux终端里执行termux-wake-lock。算力瓶颈手机跑小模型可以但14B级别的模型就会又慢又热。所以安卓端更适合做“入口”通过局域网连接服务器上的网关而不是本机跑完整推理。存储与内存手机上同时跑向量库、模型推理、日志内存不够时常会被系统强杀。我目前的用法是安卓端装一个Termux启动时连回Ubuntu主机上的OpenClaw服务只把它当成一个语音输入和快捷面板。这样既能在外面联网设备上快速调用家里的AI又不牺牲性能。如果你问我Termux部署到底值不值得我的答案是当备用入口值得纯手机自托管目前还是有点勉强。4. 把这些能力接进真实场景Skill配置、物联接入与本地知识库4.1 配置自己的Skill从“能聊”到“能干”Skill写起来不难但第一次上手有几个点需要理解清楚。以“读取指定目录下的Markdown笔记”为例简单实现分三步写一个函数、注册到Skill列表、在对话中触发。伪代码大致是# skills/file_reader.py async def run(ctx, path: str): with open(path, r, encodingutf-8) as f: content f.read() return {content: content[:4000]}# skills manifest 片段 [[skill]] name read_markdown description 读取本机指定路径下的Markdown文件内容 entry file_reader parameters { path 文件路径必填 }配置好之后在对话里输入“读一下这几天的工作笔记”网关会先完成意图识别匹配到read_markdown再自动提取参数path。如果你只有一个笔记目录建议直接在Skill里写死默认路径省得每次都要跟模型解释“我的工作笔记在哪个目录”。这里有个我经常提醒别人的细节description字段写得越具体越好最好带上一两个使用范例因为这行描述会被模型读到直接影响它的调用准确率。我见过有人写“读文件”三个字结果模型每次都要猜路径错误率很高。后来改成“读取指定Markdown文件内容适用于总结笔记、检索本地文档示例read_markdown(path/home/user/notes/xx.md)”准确率立刻提上去。4.2 接入家庭物联用miio连接小米网关的实测很多人搜OpenClaw都会带上智能家居我也不例外。把AI助手网关接到家庭设备上确实是最直观的“让AI干活”的体现。以小米网关为例OpenClaw这边可以用python-miio这个库作为底层连接器。你需要先拿到设备的token常见办法是用米家APP的局域网协议日志获取。要特别强调一句请确保设备在你自己名下抓token只针对你自己的设备不要拿别人家设备做实验。拿到token和IP之后最简单的验证方式是先写一个不经过OpenClaw的Python脚本来测连接是否通畅from miio import Gateway gw Gateway(192.168.1.100, your_token) print(gw.get_prop([power]))脚本跑通了再把它包成OpenClaw的Skill。启动之后你对网关说“关掉客厅灯”模型会调用这个Skill通过局域网API向设备下发指令然后根据返回结果告诉你“已关闭”。整个链路延迟很低基本感觉不到中间有一层网关调度。不过我必须提醒一个安全细节这类局域网API通常没有任何密码保护一旦暴露到公网任何人都能控制你的设备。所以OpenClaw连这些设备的连接器只允许走内网访问绝不要做端口映射。4.3 本地知识库与SMB让网关读取你真正的资料自托管一个很现实的价值是可以把家里的NAS资料变成AI问答的知识源。OpenClaw对接SMB的方式我建议先直接在宿主机上把NAS共享目录挂载成普通文件夹再让网关去扫描这个文件夹。比如在Ubuntu上sudo apt install cifs-utils sudo mkdir -p /mnt/nas sudo mount -t cifs //192.168.1.2/share /mnt/nas -o usernameyouruser,passwordyourpass,iocharsetutf8挂载好之后在OpenClaw配置里指定文档根目录为/mnt/nas它会按周期扫描文档并建立索引。这里有几个点必须提前处理NAS目录里如果有很多压缩包、临时文件要在配置里排除掉否则索引会塞满无用数据中文字符文件名在SMB挂载时偶尔会乱码记得加上iocharsetutf8首次扫描大批量文档时CPU和内存会明显飙升建议放在夜间执行。建立起索引后你可以问“去年夏天买的那款路由器的配置参数是什么”它能从几百份文档里把对应内容检索出来再基于检索结果回答。这种体验确实有一点“私人管家”的味道尤其是所有索引都在本地不会有资料泄漏到外部模型。4.4 维护习惯日志、备份与卸载很多自托管项目都有一个通病部署一时爽运维火葬场。我在OpenClaw上也吃过亏。分享几个现在保持的习惯。日志是第一道防线。OpenClaw默认日志会打到终端如果走systemd就统一收进journald。我遇到过网关偶尔“失忆”查了发现是向量库索引文件被某个Skill误删了一半。没有日志的话这种问题几乎无法定位。建议把所有组件日志集中到一个目录方便排查。配置备份比数据库备份更重要。Skill代码、路由规则、模型参数这些都在目录里我通常把整个配置目录做成一个Git仓库每次改完配置就提交一次。这个方法已经救了我至少三次其中一次是更新版本后兼容性变动直接回滚到上一个提交就恢复正常了。卸载这个问题也常有人问。OpenClaw的卸载其实很简单停止服务删除虚拟环境、源码目录和配置目录。没有全局安装的残留文件也没有注册表。但有个地方要留意它可能在Ollama里留下了你单独拉取的模型这些模型文件体积很大如果不再用记得单独在Ollama里清掉。5. 自托管的安全分寸数据真正属于你不等于无条件信任自己5.1 本地数据与外部API的隐私警戒线标题说“数据真正属于你”但我必须泼一盆冷水自托管解决的只是“数据存储在你控制的硬件上”不等于你发给AI的所有内容都不会离开这台机器。如果你在OpenClaw里配置了云端模型的API那么每次把请求转发给外部模型时提示词、Skill的执行结果、你可能塞进上下文的文档片段都会被传到第三方服务器。这不是OpenClaw独有的问题是所有“本地调度云端推理”架构的通病。我的处理方式是在模型路由里加一条“敏感任务强制本地”。比如你日常会跟AI讨论一些尚未公开的技术方案那就把这类话题的关键词维护成一个本地过滤表凡是命中相关词库的请求一律只走Ollama不允许路由到云端。这么说吧OpenClaw给你的是“选择权”和“知情权”但最终“哪些数据能出网”这个决定还是要你自己用配置去落实。指望一个工具替你默认做好所有隐私决策是不现实的。5.2 端口、密钥与日常备份安全配置上我踩过一次很深的坑。刚部署的时候为了省事把网关监听地址设成了0.0.0.0想着局域网内方便从手机访问。结果有一次在公共网络环境下手机连的设备恰好和网关在一个网段别人通过IP直连就能访问到网关的HTTP接口配置里明文保存的API key几乎等于裸奔。那次之后我把监听地址改回127.0.0.1需要远程访问时只通过局域网内的其他受控设备中转访问绝不让核心网关直接挂到可以被人扫到的网段上。密钥管理也值得单独说。OpenClaw初始配置里API key是明文写在config.toml里的。建议至少把配置文件的权限收紧到当前用户可读写chmod 600 ~/.openclaw/config.toml如果你的系统部署了密钥管理服务可以进一步把API key改成环境变量注入避免敏感信息落盘。另外Ollama默认只监听127.0.0.1:11434这个设置千万不要改成全网监听否则任何同网段设备都能拿你的算力池跑私有推理你的设备还会被占得死死的。备份的策略也讲一下。我每周做一次全量备份内容包括配置目录、向量数据库目录、Skill源码仓库。恢复方法很简单新机器上装好OpenClaw把备份解压回对应路径再启动服务就行。真正让我安心的是“可回溯性”任何时候出了状况我都能回到某一个确定的历史状态。5.3 与WorkBuddy、Trae、Codex这类工具的定位差异最后横向说两句市面上一些同类工具。WorkBuddy、Trae、Codex这类产品我也有用它们确实做得不错面向的场景很明确——编程、文档生成、特定办公流程。但它们大多数还是以云端账号为核心工具链、记忆、插件都由平台统一管理。如果你做的是轻量任务直接用它们没毛病省心、迭代快、一次配置到处用。OpenClaw的定位跟它们不太一样它更像是一个“个人基础设施”项目不绑定任何具体业务的偏向。你可以在它上面同时搭编程助手、家居控制、知识库问答、定时任务再用Skill自由拼接。代价是你要自己承担部署、维护和安防的职责。所以我给朋友的建议通常是买现成的西装和量体裁衣不冲突你工作日可以穿现成的但周末那件不打版型不合身。自托管不适合所有人但一旦你需要定制能力它会比那堆现成工具顺手得多。我现在的体会是自托管AI网关跟养植物很像——需要定期浇水、换盆、修枝过程谈不上轻松但它长成什么样由你说了算而且根始终扎在你自己的土里。数据自主这句话实践起来其实是一个个琐碎决定堆出来的监听地址设成什么、模型路由怎么划、Skill能访问哪些目录、密钥放在哪。每一个决定都不大但组合起来就是你真正拥有这套系统的程度。最后再分享一个小技巧给所有Skill建立一个独立Git仓库每个Skill的改动都留下提交记录。我靠这个习惯排查过不少“上次还好好的这周就不行”的问题——不是OpenClaw坏了而是我某次改参数的时候把一个共用配置改错了。有了历史记录十分钟就能定位回滚。希望你用上这套组合拳之后也能早点体会到“数据在自己手里”这种安心感。