如果你最近刷各种AI工具群大概率会看到“养虾”这个词频繁出现。别误会大家不是在搞水产养殖而是在聊 OpenClaw。OpenClaw 是原 Clawdbot 改名重构后的开源 AI 代理项目名字里的 Claw 就是爪子自然就让人联想到龙虾、螃蟹的钳子圈友干脆把部署一个自己的 OpenClaw 实例叫作“养虾”。你给这只“虾”配上大模型、给足工具权限它就能在服务器上连续干活写代码、查资料、操作文件、跑自动化流程本质上就是一个能替你打工的 AI 代理。不过真正把“虾”养起来之后第一道坎往往不是模型能力而是怎么随时控制它。你不可能每次都搬个显示器坐到服务器跟前尤其当这只“虾”被部署在云服务器、公司内网甚至是异地电脑上的时候远程控制就成了刚需。这篇文章就把 OpenClaw 部署和远程控制这件事从头到尾捋一遍涵盖 Linux 和 Windows 的安装、模型配置、SSH 和可视化远程控制、与 Codex 的联动编排、常见坑位排查。不管你是第一次装 OpenClaw 的小白还是已经在服务器上跑了一段时间的老手都能在这里找到能直接抄作业的内容。1. 人人都能“养虾”OpenClaw 到底是个什么东西1.1 OpenClaw 的前世今生OpenClaw 的前身是 Clawdbot早期还叫过 Moltbot项目在 2025 年做了比较大的一次改名和重构对外以 OpenClaw 的名字开源。它的定位非常明确一个跑在你机器上的 AI 代理平台和云端 SaaS 产品不同OpenClaw 把所有执行环境都留在本地你给一个大模型 API 的 Key它就能控制你的电脑或服务器做各种事。GPU 不强没关系推理不在本地模型走 API机器配置再差只要系统命令能跑OpenClaw 基本都能转起来。这里面的判断逻辑其实很简单AI 代理负责“思考”OpenClaw 负责“执行”。你给它一个任务它会把任务拆解成多个步骤每一个步骤可能对应一条 shell 命令、一个文件操作、一个网页请求或一段代码执行。等到一切结束后你只看到最终结果和过程日志。对个人来说这相当于雇了一个干活不要工资、只用 API 费用的数字助理对团队来说它又是一个可重复、可审计的自动化底座。开源这件事也非常关键。OpenClaw 的代码全公开意味着你可以审查它每一步会执行什么、有没有上传无关数据还能自己改逻辑、做二次开发。社区版本迭代很快像 2.0 开始把插拔式的技能 Skills、运行时元数据 runtime metadata、审批机制等做得越来越细很多官方没覆盖的功能几天后社区就有人提交补丁。这也是为什么我对这个项目比较有好感它不是一套封闭的产品而是一个能跟着你需求长的工具。1.2 为什么大家把 OpenClaw 叫“养虾”“养虾”这个叫法其实没有官方来源纯粹是社区玩出来的梗。OpenClaw 的图标和名字都带点“爪”的元素加上代理在工作时不仅会思考还会真的动手去操作环境那个状态就很像一只活蹦乱跳的小龙虾在缸里爬来爬去。你把它部署好、喂给它模型额度、给它配好工具就像给虾缸换水喂食一样日常只要偶尔看一眼日志保持环境稳定就行。甚至有群友在部署时截图下了个“龙虾 OpenClaw 下载”的安装包解压出来一只小珊瑚虾这群里的欢乐氛围一下就有了。这个比喻虽然搞笑但意外地把 OpenClaw 的核心特质说清楚了第一它是一个需要长期驻留的程序不是用完就走的网页工具第二它需要你持续关注环境模型、权限、磁盘空间、网络状态都会影响健康度第三你投入多少准备它就回报你多少效率。用养宠物的心态去运维一个开源项目听起来有点不着调实际上反而让人更容易养成备份和巡检的习惯。1.3 为什么远程控制是养虾的基本功如果你只在工作电脑上通过交互模式运行 OpenClaw你可能会发现自己被它绑住了离开工位、换成笔记本、出门旅行就没法再派任务这显然浪费了 AI 代理最值钱的“随时随地干活”能力。反过来如果把“虾”部署在一台 24 小时开机的云服务器或家里的小主机上你想在哪控制就在哪控制这才算把价值发挥出来。远程控制的场景比想象中多白天在公司操作家里的服务器晚上在笔记本上查看云端任务的进度出差途中临时给服务下个命令或者团队里几个人共用同一个实例协作。特别是当 OpenClaw 接了飞书、微信、Obsidian 这类入口之后远程控制就不只是“远程敲命令”那么简单而是把任务派发入口放到了你日常使用最频繁的工具里面。所以才说远程控制不是附加功能而是养虾的基本功。2. 先把“虾缸”搭起来部署与初始化2.1 Linux 服务器部署方案Linux 是最稳的部署环境OpenClaw 官方也在 Linux 上维护得最勤。云服务器、VPS、树莓派甚至 WSL 都行建议选 Ubuntu 22.04 或 Debian 12 这类比较常见的发行版遇到问题搜答案也容易。部署方式基本就是官方脚本一把梭网络通畅的情况下几分钟就能完成这里我刻意不写死命令因为官方安装脚本的 URL 和参数会随版本变化直接贴容易误导人具体以官网 README 为准。打开终端连接上你的服务器执行官方给出的安装命令装完以后用openclaw --version验证。如果提示 command not found多半是安装路径没有加入 PATH常见的解决方法是把~/.openclaw/bin或/usr/local/bin加进去然后重开终端。旧版本升级时建议先看官方公告新老版本的配置目录都在~/.openclaw升级不当容易把授权文件和配置覆盖掉。如果你不想污染主机环境可以用 Docker 跑。官方仓库一般会提供镜像构建文件核心思路是把~/.openclaw和 workspace 目录挂载出来这样容器销毁重建之后数据和配置还在。因为镜像 tag 和端口映射变化也很快仍然以官方 README 为准。第一次用 Docker 部署的人最容易漏掉挂载重启容器后所有配置回滚相当于虾缸刚换完水又给倒空了所以挂载这步一定要仔细检查。2.2 Windows 本地安装要点Windows 环境尤其是 Win11OpenClaw 在 PowerShell 里也能装。Windows 上常见的坑就是“无法将 openclaw 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”我后面专门讲这个问题。安装前先确认 PowerShell 版本和执行策略一般用管理员身份运行 PowerShell把本地执行策略改成 RemoteSigned再执行安装脚本。安装路径不确定的时候默认用户目录下的.openclaw文件夹就是全部家当删了就等于重置。如果官方提供了便携包可以在部分内网机器上直接解压运行不用做完整安装。便携包的好处是灵活但要注意它一般不会自动注册 PATH 和系统服务远程管理时你得知道启动器放在哪个目录。Win11 用户尤其要注意系统版本和更新OpenClaw 依赖一些底层命令行工具系统过于精简、缺少运行库会出现各种奇怪问题。安装后建议跑一次自检命令确认核心依赖都装全了再配置模型。2.3 初始化、模型与 API 配置装好之后第一件事是初始化会话配置大模型 API。OpenClaw 支持 OpenAI 兼容接口这意味着主流的模型服务商、本地推理网关、企业网关基本都能接。初始化时会要求你输入模型提供方的 Base URL、API Key、模型名称这些参数存到~/.openclaw下面的配置文件里。配置时有几个细节值得强调。第一模型名称一定要填服务商给你发的完整 ID别想当然写个通用名很多网关同一个模型有多个版本填错会出现 404 或模型加载失败。第二Base URL 末尾的斜杠很关键不同的网关要求不同填错会出现连接成功但模型加载失败错误信息又模模糊糊。第三如果你有多个服务商可以在配置文件里拆成多个条目方便切换主备模型。NVIDIA NIM 的接入也是这个思路NIM 提供 OpenAI 兼容接口配置好 Base URL 和 API Key 之后就能把 OpenClaw 的模型后端切到本地或 NIM 托管的推理服务上适合对数据安全要求比较高、不想把任务内容全部发给公网模型的场景。提示初始化时如果要你选择命令执行审批策略建议先保留审批模式等跑顺了再逐步放开。审批记录会存在~/.openclaw/exec-approvals.json之类的文件里这个文件对你的自动化流程很重要别动不动就清空后面专门讲。3. 远程控制方案全梳理总有一种适合你3.1 SSH 和命令行最基础也最可靠的“遥控器”SSH 是远程控制的基石。如果说 OpenClaw 是虾那么 SSH 直接把养虾的缸挂在你眼前。不论服务器在云上还是家里的虚拟机只要开放 SSH你就能从任何有终端的设备连上去这也符合很多开发者“远程控制就用命令行”的习惯。连接服务器后直接运行openclaw相关命令就能查看状态、派发任务。如果“虾缸”在 WSL 或远程 Windows 上可以先用ssh usernamehost登录再调用 openclaw 命令。需要特别注意OpenClaw 是一个交互式工具直接跑的进程会在退出 SSH 后跟着结束所以我一般建议用 tmux 或 screen 把进程挂到后台创建一个常驻会话在里面启动 OpenClaw断开 SSH 后任务继续跑。这样远程控制就变成了“稍后回来收结果”的模式而不是必须盯着的交互会话。SSH 的安全习惯也要养好别用弱密码建议换成密钥认证如果不是必须不要把端口暴露在公网用跳板机做中转或者只在内网网段开放 SSH。远程管理云服务器时最好再从安全组层面限制来源 IP只允许你自己常驻的 IP 段访问。3.2 可视化远程桌面mstsc、向日葵这类工具怎么选命令行不是所有人的菜尤其 Windows 用户要管理文件、看日志窗口、操作图形界面时远程桌面更直接。Windows 自带的 mstsc 远程桌面连接就不用多说了局域网和带公网 IP 的机器直接连体验最原生。向日葵这类第三方工具的价值在于“打洞”能力内网没有公网 IP 也能连Windows、macOS、手机端都有客户端适合临时应急和跨平台控制。mstsc 使用中要留意两点。第一是默认端口 3389如果改了默认端口需要同时修改注册表和防火墙放行规则不然连接会直接超时第二是如果连接时报“这可能是由于 CredSSP 加密数据库修正”的错误多半是两端系统版本差异和加密 Oracle 策略不匹配可以临时把远程主机的组策略调到允许旧版本客户端或者把两端系统升级到接近版本。总之你连接的质量最终取决于网络链路本身mstsc 对丢包和延迟敏感移动网络下表现会差很多。向日葵这类第三方工具的好处是不用管网络拓扑登录账号就能连。从个人实操看如果只是偶尔远程操作文件、看个界面向日葵完全够用但如果要长期高频操作建议还是优先用 mstsc 配合内网环境。远程桌面还有一个容易被忽略的问题远程连接时如果开启了剪贴板同步在剪贴板内容较大的时候可能拖垮连接这个问题在第 5 章细聊。3.3 Codex 联动让 AI 控制 AI 干活Codex 是 OpenAI 出的命令行编码代理最近社区讨论很热因为它支持在服务器或远程环境里进行任务控制。把 Codex 和 OpenClaw 结合起来玩法就很野了Codex 负责在终端里理解你的自然语言指令OpenClaw 负责更复杂的执行环境控制和工具调度简单说你在本地用 Codex 规划任务让 OpenClaw 在服务器上执行具体步骤。我在本地编码环境里用 Codex 拆解需求把需要跑服务端任务的部分丢给 OpenClaw两个 AI 之间通过命令行接口和文件交换任务省去了很多手动维护中间过程的成本。用 Codex 连接远程环境时“codex 无法启用远程控制”是很常见的报错原因我放到第 5 章排查。这里先说一个思路Codex 更适合编码相关的交互场景OpenClaw 更适合系统操作和工具链路的执行场景两者协作时先各跑一次冒烟测试确认互相之间通过文件或端口交换数据没问题再放大任务量否则出问题都分不清是哪端出错。3.4 通过运行时元数据和 Skill 做远程任务接入OpenClaw 提供了运行时元数据 runtime metadata核心是提供一个统一的接口来获取当前代理的运行状态、版本、工作目录、配置路径等。远程控制不一定非要手动敲 shell写好脚本读取运行时元数据就能在自己写的 Web 面板或监控系统里展示这只“虾”是否健康、在跑什么任务、有没有错误。比如我习惯写一个健康检查脚本定时读取元数据把存活状态推送到飞书群晚上做梦都知道“虾”还活着。配合 Skills 机制OpenClaw 可以把自己封装成一个“可被远程调用的服务”。你可以写一个 Skill 来监听特定目录的新任务文件写一个 Skill 来调用企业的内部 API也可以让飞书机器人把消息转发成任务。远程控制的实现在这个层面就不再纠结于“用什么连接软件”而是变成“用什么入口触发任务”。我的建议是三种入口都要配SSH 做底层保底远程桌面做图形操作API 或 Skill 做自动化触发。4. 配置细节与工作区管理4.1 exec-approvals.json审批机制要留个心眼初次使用或升级老版本后会在~/.openclaw/目录下生成 exec-approvals.json 文件里面记录了你在交互中批准过的命令。比如我遇到过这样的提示legacy exec approvals exist at /root/.openclaw/exec-approvals.json意思是旧的审批文件还在系统希望确认是否要继续沿用。出现这种提示多半是跨大版本升级后审批文件的格式或字段发生了变化。这个文件不是垃圾它承载的是一条条你亲自确认过的命令白名单。白名单的价值在于让 OpenClaw 在无人监督的情况下自动执行你信任的常见命令比如ls、cat、git status、python script.py而不用每次打断你。遇到迁移提示时别急着删先看提示后面的建议如果是让你执行迁移命令就按提示跑一下如果是新版本识别不了旧格式再考虑备份后重建。审批文件一旦清空老任务里的命令都得重新人工确认一次自动化轮询流程会很被动。注意跨版本升级前先把整个.openclaw目录打包备份再动配置文件。我吃过一次亏升级后忘记备份结果所有授权记录都失效花了一整天重新跑任务确认。4.2 workspace 工作区的备份与同步Windows 默认的 workspace 路径类似C:\Users\Administrator\.openclaw\workspaceLinux 一般就在~/.openclaw/workspace。这是“虾缸”日常活动的地方任务生成的中间文件、脚本、输出结果都会落到这里。工作区最大的风险是磁盘写满和误删除。OpenClaw 跑批处理任务会产生大量临时文件我给的建议是定期把 workspace 里的产物归档到其他目录并用同步工具把重要目录备份到另一台机器或对象存储。配置目录和 workspace 要分开管理配置目录适合用 git 做版本管理workspace 则是可以重建的动态数据用同步工具备份即可。这样即使“虾”养崩了配置还在工作区也能快速恢复。关于本地 vs 云端部署的选择你也要提前想好。本地部署的好处是隐私可控云端部署的好处是设备脱机也能跑、更方便远程访问。如果你经常出差那就优先考虑云服务器如果只是在自己家里用那就用一台常开的小主机配合远程桌面和 SSH 工具来管。无论是本地还是云workspace 的备份策略都别落下环境崩了不可怕数据没了才真要命。4.3 接入飞书、微信、Obsidian 的玩法远程控制的最舒服状态是你根本感觉不到在控制。OpenClaw 社区里有多个现成插件和技能可以把入口搬到常用 IM 和工作流工具里。飞书机器人是最常见的做法之一配置好 webhook 和事件订阅后你在飞书群里发一条消息OpenClaw 后台就拆解任务执行然后把结果贴回群里这和直接在服务器上疯狂刷命令行相比门槛低了不止一个量级团队协作时还可以把任务分发记录留在群里。微信生态相对封闭想接入 OpenClaw 通常需要借助个人微信协议或第三方 SDK这类插件下载使用时要特别谨慎因为协议不稳定账号封禁风险需要自己评估。如果只是自己用我更推荐用飞书或 Telegram 这类开放生态的工具如果团队内部习惯用微信那就要做好插件升级和维护的预期。Obsidian 结合 OpenClaw 做项目管理是我比较推荐的组合把任务写入 Obsidian 的 markdown 笔记OpenClaw 监听笔记变化解析任务状态并自动更新完成情况。这样远程控制就演化成了“在笔记里随手改一行字即可调度 AI”体验很顺。4.4 配置 NVIDIA NIM 等备选模型端点有些场景不想把数据发给公网模型服务商于是本地或内网模型推理就变得重要。NVIDIA NIM 提供了 OpenAI 兼容的推理端点你可以在内网跑一个小型 NIM 服务然后把 OpenClaw 的模型配置指向这个端点。这样做的好处是数据不出内网延迟通常也更稳定在模型推理量大的时候还可以通过 NIM 做负载调度。配置方法和普通 OpenAI 兼容服务一样设置 Base URL 为 NIM 服务的地址API Key 可以填 NIM 分配的密钥本地部署时很多方案甚至允许填占位符模型名称填 NIM 支持的模型 ID。远程控制与模型端点的关系容易被忽略当你的 OpenClaw 位于内网模型端点也在内网时除了管理 SSH你其实还需要维护一条从模型端点到 OpenClaw 进程的网络通路确保模型推理请求不会因为网络变化而中断。用一台机器部署 OpenClaw另一台机器部署 NIM两个网络区域之间的端口连通性要提前测不然会出现“控制面板看着正常任务一跑就超时”的怪问题。5. 常见问题与排查技巧实录5.1 安装报错openclaw 命令无法识别Windows PowerShell 下最常见的错误是“无法将‘openclaw’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这种报错本质上就是 PATH 里没有 openclaw。先确认安装目录一般会得到C:\Users\你的用户名\.openclaw\bin之类的位置把它加进环境变量 PATH。如果是通过 npm、cargo 等包管理器安装的检查对应包管理器的全局 bin 目录是否加入 PATH。Linux 上出现类似问题的原因也差不多通常是安装脚本把二进制放在~/.openclaw/bin而你当前 shell 环境没加载重开终端或 source 一下 profile 就行。还有一个隐藏原因安装脚本根本没跑成功。安装过程中网络访问失败、磁盘空间不足、权限不够都会导致半途而废看起来好像装了其实没有。遇到这种情况卸载后换一个网络环境或换用包管理器镜像重新装90% 能解决。另外记得用管理员权限运行 PowerShell因为安装脚本可能要创建系统目录或写入注册表权限不足时会静默失败。5.2 远程桌面掉线和剪贴板问题Mac 用户经常遇到的问题远程控制 Windows 或另一台 Mac 时只要在远程机器上复制文本、使用剪贴板同步远程连接就掉线。这个现象我在实际测试中也碰到过主要是默认剪贴板同步通道在某些网络环境下不稳定特别是远程桌面客户端和主机端版本存在兼容问题时只要一触发剪贴板内容同步连接线程就被打崩。我建议的处理办法分两步先关闭剪贴板共享重连确认掉线不再发生再单独开启剪贴板单向同步或者使用独立的剪贴板同步工具。远程桌面连接不稳定优先从网络链路排查移动网络下掉线率明显高于有线网络。另一个经验是长时间空闲的连接优先被服务端踢掉所以长任务尽量放在 OpenClaw 后台跑远程桌面只用于查看和干预不要长时间挂着不动这样既能减少连接占用也能降低安全风险。问题现象常见原因快速处理mstsc 连接超时端口被封/防火墙未放行检查 3389 端口和防火墙规则向日葵频繁断线网络跨运营商/信号不稳切换有线网络或更换主控端网络复制文本后远程掉线剪贴板同步通道冲突关闭剪贴板共享或改用单向同步打开远程桌面卡顿远程主机负载过高先查看服务器 CPU/内存再考虑带宽5.3 Codex 无法启用远程控制“codex 无法启用远程控制”出现时先检查版本旧版 CLI 不支持远程控制或捕捉会话模式需要升级到新版。其次是配置远程控制模式通常需要先在本地完成登录和授权如果登录态过期或 token 失效就会直接报错重新登录一般能解决。还有一种情况是你的终端环境比较特殊比如在 Windows 的某些模拟器上交互式 TTY 支持不完整导致 Codex 无法维持远程控制会话解决思路是换用 Windows Terminal或直接在 WSL 里运行 Codex。如果 Codex 和 OpenClaw 配合使用时在远程机器的命令窗口一直卡住我建议换个思路让 Codex 在本地跑OpenClaw 在远程跑先把两者之间的 token、端口、文件目录这些依赖理清楚。还有远程机器上的 Codex 如果使用了自定义配置文件路径不对也会出现无法启用远程控制的提示定位方法就是打开调试日志一步步看它卡在哪个环节。5.4 卸载 OpenClaw 与残留清理卸载 OpenClaw 不复杂难的是彻底。最干净的方式是找到安装目录把二进制和可执行文件删掉再把用户目录下的.openclaw整个删除。为了避免误删删除前先备份配置和 workspace。如果用过计划任务、系统服务还需要把对应的服务项停掉并删除不然注册表或启动项里残留可能会导致开机时旧进程又跑起来。“关闭 OpenClaw”和“卸载 OpenClaw”是两个不同需求。前者只要结束进程可以叫停当前会话后者才需要清文件。想要停掉开机自启就把系统服务或启动项里的相关配置移除。在 Linux 上如果使用 systemd 管理记得systemctl disable相关服务再删除 service 文件在 Windows 上则是到任务计划程序或服务管理器里找到对应项先停用再删除。写到这里我想起自己第一次在服务器上部署 OpenClaw 时也踩过不少坑。当时那只“虾”跑一个批量文件处理任务中途因为审批文件没处理好卡了一整晚。后来养成的习惯是凡是涉及.openclaw目录的操作先备份凡是远程控制连接先确认网络链路稳定凡是模型中转配置先用简单命令验证连通性。这些习惯听起来平平无奇但实际养虾的时候能把很多突发问题提前消灭掉。如果你也在折腾远程控制自己的 AI 代理希望这篇文章能帮你少走几步弯路。顺手再分享一个小技巧定期用 OpenClaw 的运行时元数据把配置目录和模型端点的连通性打成一个检查脚本每天早上看一次要比出问题后临时排查舒服得多。