OpenClaw本地部署+cpolar内网穿透：搭建可远程访问的私人AI助手

前阵子我把自己跑了大半年的云端AI助手服务退了，换成了本地部署的OpenClaw，再用cpolar把服务隧道开到公网，让AI助手真正跟着我走。这套组合的核心思路很简单：AI助手住在我自己的机器上，模型我选、数据我留、能力我扩展；cpolar负责在公网和本地之间开一条安全隧道，我在外面用手机、平板、办公室电脑，打开浏览器就能调回家里那套助手。这篇文章我会把从零搭建的完整过程、部署时最容易卡住的WSL和模型配置问题、以及远程访问的实测体验都写出来，适合想自己部署AI代理、又不想被云厂商锁定的朋友参考。

1. OpenClaw到底解决什么问题：一个可自主部署的AI代理平台

1.1 从“AI只能在云端跑”这个痛点说起

用过云端AI助手的同学应该都有同感：刚上手觉得方便，用久了全是拧巴。API额度得天天盯着，对话记录全存在别人的服务器上，想要换一个模型、调整一下回答风格，得等平台方发版本；更别提有些需求根本不让传——私人文档、公司内部资料、还没公开的训练数据，扔给云端API心里总不踏实。

于是我转向了自托管路线。OpenClaw正是这类开源AI代理平台里比较有代表性的一员。它不是单纯的聊天机器人壳子，而是一个具备任务规划、工具调用和模型接入能力的代理框架。你可以把它理解为一个“AI调度中心”：它自己不产生算力，但能指挥你接进来的模型完成问答、写代码、查资料、执行脚本等一系列任务。和云端助手最大的区别是，它的身体在你自己的电脑上。

这个定位决定了它非常适合三类人：一是对数据隐私敏感，希望对话记录完全留在本地的用户；二是想自由切换模型、追求可定制性的折腾型玩家；三是做自动化集成、需要把AI能力接进自己工具链的开发者。对我来说，最直接的收益就是“不再被云服务的使用条款绑架”。

1.2 代理框架、模型接入与Skill：OpenClaw的三层结构

刚开始接触OpenClaw的时候，容易把它想复杂，其实拆开看就是三层结构。

第一层是代理核心。它负责理解你的任务，把任务拆成步骤，然后按步骤调用工具、组织答案。比如你说“帮我整理这个目录下的所有md文件，做一份带摘要的索引”，OpenClaw会先找到目录、扫描文件、读取内容、调用模型生成摘要，再把结果整理成一份文档。整个过程有一个完整的“规划—执行—反馈”循环，而不是简单地把问题丢给大模型。

第二层是模型接入层。OpenClaw本身不内置大模型，它通过配置对接不同的模型来源：可以是本地的Ollama、也可以接入各类云API。这一层决定了你实际使用时的算力来源，也是部署时最需要动脑子的地方。

第三层是Skill机制。中文社区一般叫“技能”或“技能包”，类似IDE里的插件。社区里有大量现成的Skill可以装，比如文件操作、网页抓取、代码执行、日程管理等等。你也可以按自己的需求写新的Skill，给AI助手扩展特定能力。

OpenClaw还提供了一个Web界面和一套API接口。Web界面用于日常对话和配置管理，API接口则方便你把它嵌进别的系统。这里顺便回应一个很多人问的问题：OpenClaw只能用接入API的方式使用算力吗？不是。它原生支持接Ollama这样的本地模型服务，算力完全可以在你本机解决。

1.3 不搞清楚算力来源，部署必翻车

在我接触到的部署失败案例里，有相当一部分不是OpenClaw本身的问题，而是算力路线没想清楚就急着装。你至少要提前想明白一个问题：你打算用什么模型跑对话？

选本地模型，就要面对显存和性能的现实。一个7B参数量的量化模型，跑起来通常需要8GB左右的显存才比较流畅；14B甚至更大的模型，16GB显存是起步。显存不够会出现什么情况？要么推理慢到像拨号上网，要么直接显存溢出报错。所以没有独立显卡、只有核显的机器，老老实实选API模式或者小一点的模型。

选API模式则要考虑费用和网络依赖。好处是模型能力强、出结果快，坏处是你又回到了“数据经过第三方”的路径上。如果选API，记得把API密钥妥善保管，不要顺手写进会被同步的配置文件里。

我个人的建议是：部署前先用一张纸把两个问题写清楚——你的机器能跑多大的本地模型？你的使用场景能不能接受云API？答案清晰了再动手装环境，后面会省掉大量反复调试的麻烦。

2. Windows搭建第一关：WSL2环境与“无法安全验证”报错

2.1 为什么Windows上绕不开WSL2

如果你在Windows上部署OpenClaw，绕不开的一个组件就是WSL2，也就是基于WSL的第二代Windows Linux子系统。原因不复杂：OpenClaw及其依赖的许多组件，在Linux环境下的兼容性和运行效率明显更好。

WSL2和旧版WSL最大区别是它跑了一个真正的Linux内核，而不是API翻译层。这意味着你熟悉的Linux命令、软件的安装方式、文件权限模型在WSL2里都完全一致。更重要的是，WSL2对GPU加速的支持已经比较成熟，如果你想在Windows上通过Ollama调用本机显卡来跑模型，WSL2几乎是必经之路。

很多新手的第一个挫折就发生在这一关。装好了OpenClaw，运行安装脚本时报“无法安全验证”，或者在终端里看到“sl2环境”相关提示，要求你去Windows PowerShell里运行wsl --status查看状态——这其实都是WSL环境没就绪的典型信号。下面我把整个检查和修复过程说清楚。

2.2 一步步把WSL2环境调到就绪

首先，以管理员身份打开PowerShell。注意是管理员身份，否则很多命令会因权限不足而失败。然后按顺序执行：

wsl --install

这个命令在Windows 10 2004及以上版本、Windows 11上会一次性安装WSL2所需的全部组件和默认Linux发行版。执行完成后，重启系统。重启后第一次打开终端，系统会要求你为新装的Linux发行版设置用户名和密码，按提示设置即可。

接着确认WSL版本：

wsl --status wsl --list --verbose

wsl --status会显示默认版本、内核状态等关键信息。如果显示默认是v1，需要手动切到v2：

wsl --set-default-version 2

如果提示内核版本过旧，再执行：

wsl --update

这里给一个常用命令速查表，方便你对照排查：

还有一个容易被忽略的坑：老版本Windows 10没有wsl --install命令，那就得去“控制面板—启用或关闭Windows功能”里手动勾选“适用于Linux的Windows子系统”和“虚拟机平台”，重启后再用wsl --set-default-version 2指定版本。装好WSL2之后，再回到OpenClaw的安装流程，你会明显感觉顺畅很多。

2.3 “无法安全验证”背后通常是这两件事

“无法安全验证”这个报错，几乎每个Windows用户都会遇到，但原因并不单一。

第一类是PowerShell执行策略拦截。Windows默认的策略是Restricted，只允许运行签名的本地脚本。而OpenClaw的安装脚本一般是仓库里的.ps1或.sh文件，第一次执行时会被系统拦住。处理办法是在PowerShell里给当前用户放开远程脚本执行权限：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

执行完以后，再运行安装脚本通常就能通过。如果你看到的是“是否要运行此软件”之类的SmartScreen弹窗，那是Windows在警告你“这个文件不是来自受信任的发布者”。你要是确认脚本是从官方仓库拉下来的，点“仍要运行”即可；不确认来源的话，先停下来核对一下再继续。

第二类才是和WSL相关的硬性问题。OpenClaw的Windows配套安装器（Windows Companion）在初始化时会检查WSL发行版是否可信、内核组件是否完整。如果WSL本身没装好，或者发行版签名验证出问题，就会出现“sl2环境，请在PowerShell中运行wsl --status”这类提示。遇到这种情况，不要急着绕过校验，先回到上一步，把wsl --status的实际输出看清楚：如果提示内核不可用，执行wsl --update；如果发行版显示为v1，就执行wsl --set-default-version 2。

再补充一个基础环境要求：Node.js。OpenClaw本身依赖Node.js运行，去官方网站下载LTS版本安装即可，不要用系统包管理器里那种过时的版本。装完以后用node -v和npm -v确认版本号，能正常输出版本号，说明Node.js这一关也过了。

3. Ollama还是云API：本地模型与云端算力的配置取舍

3.1 用Ollama接本地模型的完整配置

先把结论放前面：如果你有多余的显存，本地模型方案值得优先尝试，因为它的体验最接近“一个完全属于你的AI助手”。

安装Ollama很简单，去官网下载对应平台的安装程序，macOS和Windows都有图形化安装包，Linux就用官方脚本。装好之后拉一个模型下来，这里以中英双语能力不错的Qwen系列为例：

ollama pull qwen2.5

拉取完成后，先用ollama run qwen2.5在终端里做一次对话测试。测试通过说明模型本身没问题。Ollama启动后默认监听本地11434端口，你可以用下面这个命令确认API是否正常：

curl http://localhost:11434/api/tags

如果返回一个包含模型列表的JSON，说明Ollama服务就绪。接下来到OpenClaw的配置文件里，把模型提供方设置为Ollama，填上模型名称和API地址。不同版本的项目配置项位置会有差异，以你克隆下来的项目文档为准，核心就是三个字段：provider类型、model名称、base_url指向http://localhost:11434。

配置完成后启动OpenClaw，在Web界面里发起一次对话，看能否正常返回。第一次请求可能会等得久一点，因为模型要加载进显存，这个是正常现象，第二次开始就快了。

这里有个实操提醒：显存是硬约束。比如一张8GB显存的显卡，跑7B量化模型基本是及格线；跑14B模型就会比较吃力，回复速度可能降到能接受的下限以下。如果你只有集成显卡，那就老老实实选小模型，比如3B、4B级别的量化模型，或者直接走API路线。

3.2 云API模式：不折腾显卡的接入路线

本地模型好是好，但不是每个人都有大显存。如果你手里的机器没有独立显卡、或者显存只有几GB，那我建议直接走云API模式。这条路线几乎没有硬件门槛，只要网络通畅就行。

操作上，你先去云服务商那边注册账号、开通API服务、拿到一个API Key。然后在OpenClaw的配置里切换到对应的provider，填入API Key、基础地址和你想用的模型名。相比Ollama，你不需要下载任何模型文件，也不需要关心显存占用，配置对话返回的速度通常也更快、更稳定。

不过API模式有它的代价。首先是费用，按token计费，日常高频使用一个月下来账单不容忽视。其次是数据路径，你的对话内容会经过云服务商的服务器，对隐私敏感的场景要慎重。还有网络要求，如果网络不稳定，响应体会非常明显。

实际操作中，API模式最常见的报错有三种：API Key填错或带了多余的空格、模型名称和官方接口里的名字对不上、base_url末尾多了斜杠。遇到401或404错误，优先检查这三处。

3.3 混合玩法：大模型规划、小模型执行

聊完两种方案，我得说一句：它们不是非此即彼的关系，完全可以混着用。

什么意思？OpenClaw支持同时配置多个模型来源。我可以让复杂任务走云API，用大模型完成深度分析、代码生成这类高难度工作；日常的简单问答、信息提取、批量整理，则交给本地小模型处理。这样做的好处是：既保住了日常使用的手感和响应速度，又只在关键场景才消耗API额度。

配置思路大致长这样：

models: - name: local_quick provider: ollama model: qwen2.5:7b base_url: http://localhost:11434 roles: [chat, summarize] - name: cloud_power provider: api model: your-cloud-model-name api_key: ${API_KEY} base_url: https://api.example.com roles: [plan, deep_analysis]

实际跑起来以后，我发现这种“重活给云端、轻活给本地”的路子，体验非常舒服。长期挂着用，API消耗也控制得住。你完全可以根据自己的需求调整分工：把代码任务给强模型、把闲聊给本地模型，或者反过来。

4. cpolar内网穿透：让AI助手从“本机独占”变成“随身服务”

4.1 内网穿透解决的根本问题

OpenClaw部署好之后，默认只能在你自己的局域网里访问。你在家里用WiFi，手机连同一个路由器，当然能访问；可一旦到了办公室、去了外地，就完全连不上了。原因很直接：你的电脑在一个内网里，外网没有办法直接找到它。

要解决这个问题，常见方案是去路由器里做端口映射、申请公网IP，但对于大多数普通用户来说，这套操作既麻烦又不现实，而且运营商给的家庭宽带往往并没有独立的公网IP。cpolar这类内网穿透工具，就是专门解决这个问题的。

打个比方：你的服务像是住在一个不对外公开门牌号的小区里，外人只知道这个小区名字却找不到具体楼栋。cpolar相当于在小区门口设了一个收发室，公网用户访问cpolar分配的域名，请求就被安全地转送到你家里的电脑上。整个过程不需要公网IP、不需要改路由器、不需要申请域名。把本地端口映射成一个公网可访问的URL，这就是内网穿透的本质。

需要明确的是：这里说的是把自己机器上运行的服务开放给公网，用于你个人远程访问，这是常规的自托管用法。

4.2 cpolar安装、认证与隧道建立

cpolar的安装很直白。先去官网注册一个账号，拿到属于你的authtoken，然后在你部署OpenClaw的机器上安装cpolar客户端。Windows有安装包，Linux环境可以用npm或官方脚本装：

npm install -g cpolar

装好以后先执行认证：

cpolar authtoken <你的token>

这一步会把你的账号和本地客户端绑定。之后假设OpenClaw的Web界面跑在3000端口，建立一条HTTP隧道：

cpolar http 3000

执行完，终端里会输出一条公网地址。在上面的示例里通常是一段随机子域名，比如https://xxxx.cpolar.top。在浏览器里打开它，如果能正常看到OpenClaw的登录或对话界面，就说明隧道已经通了。

cpolar的套餐差别主要体现在几个维度：免费版域名是随机生成的，每次重启隧道都可能变；付费版本可以固定一个二级域名，还能自定义更快更稳的节点、开更多隧道。对只是偶尔远程用一下的场景，免费版够用；但如果你打算长期自托管、天天要访问，我建议至少保留一个固定域名，不然每天记新地址太折腾。下面是一张简单的对比：

4.3 隧道建好之后必须做的三件事

隧道通了只是开始，下面三件事不在第一时间做，后面大概率要后悔。

第一件，给OpenClaw加上访问鉴权。你把自己电脑上的服务暴露到了公网，如果Web界面没有登录机制，就等于把自己家的门钥匙放进了公共信箱。cpolar管理后台可以给隧道设置访问密码，或者用Basic Auth保护入口，建议务必配置；OpenClaw自身如果有登录功能，也要把口令设好。两层保险至少要有其一。

第二件，只穿透必要的端口。我的OpenClaw跑在3000端口，那我就只建一条3000端口的隧道，不要把Ollama的11434端口也穿透出去。你想想，如果Ollama API暴露到公网，别人就能直接调用你显卡上的算力，用你的模型、吃你的显存，这是实打实的资源被盗用。内网穿透的端口范围要克制到最小。

第三件，把隧道和本地服务做成开机自启。家里的电脑不可能天天手动开服务，cpolar和OpenClaw都可以注册成系统服务实现开机自启，具体命令依平台而定，装好之后确认一次重启后仍然能访问，才算真正完成了“随身可用”的闭环。

5. 运行实测：从服务起不来到远程访问的排查链路

5.1 最常见的三处卡点与定位过程

部署和配置都完成之后，最考验人的其实是调试环节。我在整个过程中踩得最多的坑有三处，每处的表现都不一样，排查方式也完全不同。

第一个卡点是服务起来了，但浏览器访问没有反应。这时候先在终端看进程是不是真的还活着，窗口是不是因为某行日志报错而退出了。最常见的原因是启动时依赖的服务没就绪，比如WSL环境没起来，导致整个进程非正常退出。用wsl --status确认环境状态，如果是好的再重启一遍服务。

第二个卡点是对话请求一直转圈，像卡死了一样。这种情况优先怀疑模型配置。我当时第一次配Ollama的时候，在配置文件里随手写了一个没拉取过的模型名称，Ollama那边根本找不到这个模型，请求就一直挂着。解决办法是回到curl http://localhost:11434/api/tags看一眼实际可用的模型列表，把配置文件里model字段改成列表里的准确名称。

第三个卡点最隐蔽：cpolar隧道明明显示在线，公网地址也打得开，但页面就是转圈或者白屏。后来排查发现，OpenClaw服务默认监听的是127.0.0.1，也就是只接受本机访问，而cpolar隧道转发到这台机器时，请求进不来。解决方法是把服务监听地址改成0.0.0.0，让它接受来自本机所有网卡的连接请求，再重启服务。

5.2 用curl和日志把问题一步步逼出来

遇到问题不要瞎猜，用一条链路把问题分层定位。我在调试时基本按这个顺序来：

第一步，确认本地服务活着。在部署OpenClaw的机器上执行：

curl http://localhost:3000

如果有响应，说明服务本身在跑。这一步挂掉，问题在OpenClaw或它的依赖环境，先别碰隧道。

第二步，确认模型服务正常：

curl http://localhost:11434/api/tags

有JSON返回，说明Ollama活着。这一步挂掉，问题在Ollama、模型路径或显存占用上。

第三步，确认隧道转发正常。换一台不在同一局域网的设备，或者干脆用手机流量访问你的cpolar域名：

curl https://你的cpolar域名

能通，说明隧道没问题；不能通，就看cpolar的日志，检查是否是域名失效、隧道绑定的本地端口不对、或者服务监听地址还是127.0.0.1。

每执行一步，就把嫌疑缩小一圈。我的经验是，80%的问题都能被这个三步法定位出来。剩下20%看日志：OpenClaw的日志文件在哪，以项目文档为准，一般会在运行目录下的logs文件夹里；Ollama的日志比较直接，终端跑起来时所有输出都在屏幕上。

5.3 远程访问体验的稳定性优化

跑通之后，还有一个长期课题：怎么用着舒服。远程访问自托管服务最明显的问题就是延迟和断连。

首选优化方案是让OpenClaw和Ollama跑在同一台机器上。如果你把模型服务放在家里另一台服务器上，OpenClaw在穿透的机器A、模型在服务器B，那你每次对话都要走两层局域网转发，延迟翻倍。能同机就同机，能局域网就尽量局域网。

其次是注意家庭宽带的上行带宽。下载带宽再大，上行不够，远程使用时输出速度也会受限。这属于物理限制，只能通过升级宽带或选择质量更好的隧道节点缓解。

第三是长连接的稳定性。OpenClaw对话是流式输出，长回答耗时几十秒是常事。如果你访问过程中频繁断流，除了检查隧道稳定性，还可以考虑在Web界面里缩短单次输出长度，或者把复杂任务拆成多次对话。另外，不要在移动网络极差的环境下做长问答，等信号稳定了再继续，体验会好很多。

6. 进阶场景：安卓Termux部署、ROS2联动与日常接入

6.1 用Termux在手机上部署OpenClaw

出门在外不想带电脑？那就直接在手机上跑一套OpenClaw。很多人在网上搜“openclaw安卓部署”、“termux安装openclaw手机版”，说明这个需求很普遍。

Termux是安卓上比较成熟的Linux终端模拟器。需要注意一点：Google Play商店里的Termux版本因为系统限制功能不全，建议从F-Droid渠道安装完整版。装好之后，按顺序执行：

pkg update && pkg upgrade pkg install nodejs git python git clone <OpenClaw仓库地址> cd openclaw npm install npm start

跑起来之后，手机就能作为OpenClaw的宿主机了。算力方面有两种选择：手机连同一个局域网，把模型请求转发给局域网里的Ollama服务；或者直接在手机上跑一个小模型，比如3B、4B级别的量化版，不追求速度的话也可以。

但手机当服务器有两个现实问题：一是安卓系统会回收后台进程，开个屏幕锁屏放几个小时，服务可能就被系统杀了；二是发热和续航都扛不住长时间运行。我的实际体验是：手机部署更适合应急，比如出门在外临时跑一个代理任务，主力服务还是放在家里电脑上更靠谱。如果你真的想长期在手机上跑，可以研究Termux:Boot和WakeLock的用法，能缓解一部分问题，但别指望它能替代一台正经服务器。

6.2 rosclaw与ROS2仿真：机器人方向的额外惊喜

如果你走的是机器人方向，OpenClaw社区里还有一个比较硬核的扩展方向叫rosclaw。它在OpenClaw和ROS2之间搭了一座桥，常见的组合是在ROS2 Humble + Gazebo仿真环境里跑。思路是让AI代理订阅机器人的状态话题、接收传感器数据，再通过自然语言指令去控制仿真机器人的运动或行为。

我在这个方向上初步摸索过，目前还处在研究阶段。给我的感觉是：潜力很大，但门槛也确实高。你要先熟悉ROS2的工作空间结构、colcon构建工具、topic和服务机制，才能把OpenClaw接进仿真系统里。普通用户或者没有机器人背景的朋友，这一节可以直接跳过；但如果你在做相关课题，建议先跑通基础OpenClaw再碰rosclaw，两个项目叠在一起排错难度是乘法级别的。

6.3 把OpenClaw嵌入日常工具链的几种姿势

最后聊点更贴近日常的用法。OpenClaw有了公网地址之后，能做的事情比“打开网页聊个天”多得多。

第一，手机浏览器直接访问cpolar域名，这是最基础的使用姿势。导航栏里存好链接，随时随地打开就是一个完整AI助手，历史记录因为都存储在你家里那台机器上，所以手机换到平板、平板换到电脑，对话上下文是连续的，这点自托管比云端服务体验还好。

第二，把OpenClaw的API接口接到你的自动化工具里。比如我写了一个简单的快捷指令，用curl向OpenClaw的对话接口发一段文本，再把回复追加到我的笔记文件里。这样我可以把OpenClaw当成一个后台助手，每天帮我整理信息、生成摘要、定时跑一些文本处理任务。

curl -X POST http://localhost:3000/api/chat \ -H "Content-Type: application/json" \ -d '{"message":"把这份会议纪要点整理成三条待办事项","session_id":"daily"}'

公网隧道打通之后，把这里的localhost:3000换成你的cpolar地址，这套自动化就从局域网工具变成了随身服务。

第三，如果追求更极致的“跟着走”，还可以考虑在OpenClaw上接入外部消息通道，比如把它挂到即时通讯软件上，在外面发个消息就能触发家里的AI助手干活。不过这种扩展依赖网络服务和三方鉴权，配置起来要花更多时间，建议先把基础链路用顺了再折腾。

从部署OpenClaw到接上cpolar，整个过程折腾了大概一个周末。我个人最大的体会是：这套方案的底层逻辑其实非常简单——把AI助手的“身体”放在自己能控制的机器上，再用隧道把门牌号挂出去。它带来的自由度是云端服务给不了的：模型随便换、数据自己管、行为完全可定制。唯一需要你认真对待的是安全边界，公网开了口子，鉴权就要做好，不该暴露的端口一台都别暴露。以后想扩展更多模型、更多Skill，或者接上家里的智能设备，都是在同一个底座上做加法。想清楚自己打算怎么用，再跟着上面的步骤一步步走，这个AI助手是真的能“跟着你走”的。