烂人不配爱如果你最近在折腾开源智能体，大概率见过“人人养虾”这个说法。一开始我以为是什么水产养殖自动化项目，点进去才发现，大家说的“虾”其实是 OpenClaw——一个把大模型、消息平台、自动化脚本串联起来的个人智能体运行时。社区里把安装部署一台 OpenClaw 戏称为“养虾”，养熟了它就像你的小秘书，能收消息、调工具、定时干活，甚至还能写点小说消遣。
但这只虾刚装好的时候有个尴尬问题：它只活在你电脑的终端里。你人在公司、在地铁、在老家，它就完全失联，顶多算个“单机版宠物”。真正让它变得有用，靠的是一层远程网关——让 OpenClaw 从“只能在电脑前指挥”变成“7x24 小时在线待命”。这篇分享我就把远程网关这条线完整拆开讲清楚，包括架构选择、服务器部署、IM 接入、Skill 联动、稳定性和安全加固，以及我实际踩过的一堆坑，希望能帮正在“养虾”的朋友少走弯路。
1. 为什么说网关才是 OpenClaw 真正“上线”的分水岭
1.1 本地跑通的 OpenClaw，其实还是台“半成品”
很多人在本地跑通 OpenClaw 的那一刻是很兴奋的：在终端里跟 Agent 对话，让它查资料、写代码、调 API，感觉无所不能。但用不了几天就会发现一个致命问题——它只能在你打开电脑、开着终端的时候工作。
我自己的经历很典型。最初在一台 Mac mini 上跑 OpenClaw，白天上班人不在家，想让它定时抓取某个网页并整理成摘要推给我，结果什么都没发生。原因很简单：家里的路由器没有公网 IP，外部消息根本进不来；Mac mini 虽然没关机，但 OpenClaw 的进程只是挂在终端里，没有常驻机制，断电、休眠、网络波动一次，进程就没了。
换句话说，本地部署解决的是“能不能跑”的问题，远程网关解决的才是“能不能随时用”的问题。OpenClaw 这类智能体，真正的价值不在于你坐在它面前问问题，而在于它能在你离开之后继续替你处理消息、执行任务、主动汇报。没有网关，这些都无从谈起。
1.2 “远程网关”拆开看，其实是三件事
远程网关这个词听起来高大上，拆开其实就三件事：常驻在线、双向消息、回调可达。
- 常驻在线：OpenClaw 进程必须跑在一个不会随你下班而关机的环境里，比如云服务器、家里常开的 NAS，或者至少是配置了自动重启的桌面电脑。
- 双向消息：你能通过微信、飞书、钉钉等 IM 工具给它发指令，它也能主动给你推送消息。单向的 webhook 能通知，但没法对话；完整的双向接入才算是真正的“遥控器”。
- 回调可达：IM 平台要能把用户消息转发给 OpenClaw，就需要一个公网可访问的 HTTP 回调地址。如果你的服务器在云上，这一步天然满足；如果跑在家里，就得想其它办法，比如让 OpenClaw 主动向外建立长连接。
一个形象的类比是：养在本地电脑上的 OpenClaw 就像虾缸里的虾，只能隔着玻璃看；网关则是在虾缸上开了一条管道，让你在外面也能喂食、换水、观察状态。管道通没通，直接决定这只虾是观赏品还是生产力工具。
1.3 网关和“内网折腾”的关系，很多人一开始想反了
一说到远程访问，很多人的第一反应是把家里的电脑暴露到公网，搞各种端口映射。但 OpenClaw 这类工具的特点决定了，它更适合“云上托管 + 消息平台中转”的架构，而不是“把家里电脑映射出去”。
为什么？因为 OpenClaw 的核心交互是消息。微信、飞书、钉钉这些平台本身就是天然的消息中转站，它们既托管了用户身份，又提供了回调能力。你只需要让 OpenClaw 所在的环境能访问这些平台的 API（这个方向是出站访问，几乎所有网络环境都允许），以及让平台能把消息 POST 到你的回调地址（这个方向需要公网可达）。把这两条理顺了，网关就通了。
所以我的建议很明确：第一条路线优先用云服务器部署，别在复杂的网络方案上消耗精力。等跑通了，再根据需求考虑混合部署。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 网关方案怎么选：三条路线对比
2.1 路线A：云服务器直跑，最省心的“托管虾塘”
把 OpenClaw 直接部署在一台有公网 IP 的云服务器上，这是最正统、也最适合新手的方案。它的核心优势是：网络模型最简单。
- IM 平台的回调直接指向服务器公网 IP，不需要任何中转。
- OpenClaw 要调用模型 API、IM API 都是出站请求，云服务器天然放行。
- 服务器 7x24 小时在线，只要进程守护做好，基本不用管。
成本方面，一台 2 核 4G 的入门云主机就够跑 OpenClaw 加各种 Skill 了，不同的云厂商价格有差异，但整体性价比很高。对大多数人来说，这是“养虾”的最优起点。
配置上，你可以选择直接在服务器上装 Node 环境跑，也可以用 Docker 跑。我的经验是：如果服务器上还跑着别的服务，优先用 Docker 隔离；如果这台服务器就是专门给 OpenClaw 用的，直接二进制部署反而排障更直观。
2.2 路线B：本地机器常开 + 出站回连，零服务器成本
如果你手头有常开的电脑、Mac mini 或者 NAS，又不想额外买服务器，可以选择让 OpenClaw 跑在本地，通过“出站回连”的方式接入消息。所谓出站回连，就是 OpenClaw 主动向外部的消息网关建立一条长连接，由网关负责把 IM 平台的消息推给它。
这个方案的优点是不需要公网入站，家里没有公网 IP 也能用；数据全在本地，隐私性更好。缺点是稳定性受本地环境影响很大：断电、断网、系统休眠，都会让虾“翻肚皮”。而且你还需要自己维护一个转发层，复杂度并不低。
我个人的看法是：这条路更适合已经有 NAS 或软路由、并且熟悉容器运维的朋友。如果只是图省事，还是直接上云更稳。
2.3 路线C：混合部署，网关在云上、模型留在本地
还有一条进阶路线：OpenClaw 的网关进程放在云服务器上保证在线率，但大模型不调用云端 API，而是通过本地推理服务（比如 Ollama、NVIDIA NIM）来提供。
这样做的主要动机是数据隐私和成本。比如你有一些内部文档要喂给 Agent 处理，不想经过云 API，就可以在本地跑一个模型服务，云上的 OpenClaw 通过加密通道访问本地模型。代价是网络链路多了一跳，响应延迟会高一些，而且本地推理对硬件有要求，不是所有人都有好显卡。
这条路我建议等前面两种跑通之后再尝试，不要一上来就搞，否则出问题的时候变量太多，排障排到怀疑人生。
2.4 三条路线的直观对比
| 对比维度 | 路线A 云服务器直跑 | 路线B 本地出站回连 | 路线C 混合部署 |
|---|---|---|---|
| 公网要求 | 需要公网 IP | 不需要入站公网 | 需要公网 IP |
| 在线稳定性 | 高 | 取决于本地环境 | 高 |
| 部署复杂度 | 低 | 中 | 高 |
| 月成本 | 几十元起 | 电费+设备折旧 | 服务器+本地设备 |
| 数据隐私 | 一般 | 较好 | 最好 |
| 适合人群 | 新手、追求省心 | 已有 NAS/常开设备 | 对隐私有强需求 |
3. 实操：云服务器上的 OpenClaw 网关搭建全流程
3.1 基础环境：Node 版本是第一个大坑
OpenClaw 对 Node.js 版本有严格限制，这一点很多人在安装时就吃过亏。官方要求是 Node.js >=22.22.3 <23，或者 >=24.15.0 <25，或者 >=25.9.0。注意不是“大于某个版本就行”，而是有明确的上下界，装成 Node 21 或者 Node 23 都会直接报错。
我推荐用 nvm 来管理 Node 版本，方便随时切换。在 Ubuntu 云服务器上基本是这样的流程：
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install 24.15.0
nvm use 24.15.0
node -v
把 node -v 的输出版本号确认好，再执行下一步。如果你用的是 Debian 系的服务器，系统自带的 apt 源里 Node 版本往往偏旧，一定不要图省事直接用，否则后面会遇到“node runtime not found”这类问题。
3.2 安装 OpenClaw 并完成首次初始化
Node 版本就绪后，安装 OpenClaw 本身很简单：
bash复制npm install -g openclaw
openclaw setup
openclaw setup 会引导你完成初始化：设置数据目录、生成身份文件、选择默认模型供应商、配置 API Key 等。初始化完成后，OpenClaw 的配置和状态都存放在 ~/.openclaw 目录下。这个目录就是整只“虾”的家，以后备份、迁移、删除重来，都是围绕它进行的。
有个小细节容易忽略：如果你经常用 root 用户操作服务器，注意 npm 全局安装可能需要 sudo。装完之后确认一下 openclaw --version 能正常输出版本号，再继续。
初始化时如果遇到网络问题导致安装中断，大概率是 npm 源的问题。可以临时切换 npm 镜像源，安装完成后再切回来。这不是什么特殊操作，属于 Node 生态的常规技巧。
3.3 Docker 部署路径：隔离环境的另一种选择
如果你不想在服务器上装一堆 Node 相关依赖，或者服务器上还跑着别的服务，Docker 是更干净的选择。一个可用的 docker-compose.yml 大概是这样的：
yaml复制version: '3'
services:
openclaw:
image: openclaw/openclaw:latest
container_name: openclaw
restart: unless-stopped
ports:
- "127.0.0.1:8080:8080"
volumes:
- ./openclaw-data:/root/.openclaw
environment:
- OPENCLAW_MODEL=deepseek-chat
- OPENCLAW_API_KEY=${OPENCLAW_API_KEY}
- OPENCLAW_BASE_URL=https://api.deepseek.com/v1
注意这里我把端口绑定到了 127.0.0.1:8080，目的是不让端口直接暴露到公网。如果后面要让 IM 平台回调，我会用 Nginx 做 HTTPS 终结和请求转发，而不是直接把 OpenClaw 的端口裸奔到公网。这个安全习惯能帮你挡掉大量扫描攻击。
用 Docker 跑还有个额外好处：以后想升级 OpenClaw 版本，只需要 docker compose pull && docker compose up -d，不需要手动处理 Node 依赖变更。
3.4 首次启动与模型配置验证
无论用哪种方式安装，第一次启动前都要确保模型配置正确。OpenClaw 支持主流模型供应商，包括 DeepSeek、千问、OpenAI 兼容接口等。如果你的 API Key 是通过环境变量注入的，启动前把它 export 好：
bash复制export OPENCLAW_API_KEY=sk-xxxxxxxx
export OPENCLAW_MODEL=deepseek-chat
export OPENCLAW_BASE_URL=https://api.deepseek.com/v1
openclaw run
启动后先别急着接 IM，先在终端里跟它对话测试。这一步非常重要，因为后续接 IM 时如果出问题，你会分不清是回调问题、消息通道问题还是模型问题。先用终端验证模型链路通了，再往下走。
如果你更喜欢图形化界面，可以试试 openclaw tui 或者打开 WebUI 面板查看运行状态。WebUI 默认在 8080 端口，但正如前面所说，不建议直接暴露到公网。
3.5 进程守护：别让网关说挂就挂
很多人部署完就以为万事大吉了，结果第二天发现 OpenClaw 进程因为日志满了或者内存波动退出了，虾直接躺平。所以进程守护是网关部署里必不可少的一步。
用 systemd 的话，可以新建一个服务文件 /etc/systemd/system/openclaw.service：
ini复制[Unit]
Description=OpenClaw Gateway
After=network.target
[Service]
Type=simple
User=openclaw
WorkingDirectory=/home/openclaw
ExecStart=/usr/bin/openclaw run
Restart=always
RestartSec=5
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
然后：
bash复制sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
Restart=always 是关键，进程异常退出后 systemd 会在 5 秒后自动拉起来。配合日志查看 journalctl -u openclaw -f，就能实时看到 OpenClaw 的运行状态。用 Docker 部署的话，restart: unless-stopped 已经替你做了类似的事情。
4. 打通消息通道：把 IM 变成远程遥控器
4.1 消息通道的原理：其实就是个回调机器人
OpenClaw 接入 IM 平台的原理并不复杂。在 IM 平台上创建应用或机器人后，IM 平台会把用户发给机器人的消息打包成一个 HTTP 请求，POST 到你配置的回调地址上。OpenClaw 收到请求后，取出消息文本，交给 LLM 生成回复，再调用 IM 平台的 API 把回复发出去。
所以这里有个硬性前提：你的回调地址必须能被 IM 平台公网访问到。云服务器部署天然满足这一点，这也是我推荐先用云服务器的原因。如果你用 127.0.0.1:8080 部署，千万别忘了在 Nginx 里配置一条路径转发到 OpenClaw 的监听端口，否则 IM 平台根本找不到你家虾在哪。
4.2 企业微信、钉钉、飞书的接入差异
不同的 IM 平台接口细节差别很大，但整体思路是共通的。我三套都接过，简单列一下关键点：
- 企业微信：需要创建自建应用，拿到 CorpID、AgentId 和 Secret。配置接收消息服务器时，要求填 URL、Token 和 EncodingAESKey。URL 指向 OpenClaw 的回调地址，Token 和 EncodingAESKey 用于签名校验和消息加解密。
- 钉钉：在开发者后台创建企业内部应用，拿到 AppKey 和 AppSecret。回调地址填到“事件订阅”里，同时需要配置加解密用的 AES Key。钉钉的签名校验是 timestamp + nonce + sign 的逻辑，注意别配漏。
- 飞书：在开放平台创建企业自建应用，拿到 App ID 和 App Secret。在“事件与回调”里配置请求地址，打开“加密”开关并设置 Encrypt Key。飞书的验签逻辑是 timestamp + nonce + encrypt_key 参与计算。
4.3 最先跑的验证步骤：Webhook 推送
在配置完整的双向交互之前，我强烈建议你先验证“OpenClaw 能主动发消息”。方法很简单：在飞书或钉钉群里添加一个自定义机器人，得到一个 Webhook 地址，然后手动调用一次推送：
bash复制curl -X POST -H "Content-Type: application/json" \
-d '{"msg_type":"text","content":{"text":"网关已上线"}}' \
https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxx
如果群里能收到消息，说明 OpenClaw 所处的网络环境能正常访问 IM 平台 API，出站通道通了。这一步通常几分钟搞定，但能帮你排除掉一大半网络层面的问题。注意自定义机器人只能单向推送，要实现双向对话，还是需要走完整的事件订阅回调。
4.4 网关侧配置：以 config.yaml 为例
OpenClaw 的消息通道配置集中在 ~/.openclaw/config.yaml 里。各个版本的字段名略有差异，但大体结构是类似的。以下是一个接了企业微信和飞书的配置片段，供参考：
yaml复制channels:
wecom:
enabled: true
corpid: "ww1234567890"
agentid: "1000002"
secret: "your-secret-here"
token: "your-callback-token"
encoding_aes_key: "your-encoding-aes-key"
lark:
enabled: true
app_id: "cli_xxxxxxxx"
app_secret: "your-app-secret"
encrypt_key: "your-encrypt-key"
model:
provider: deepseek
model: deepseek-chat
api_key_env: OPENCLAW_API_KEY
base_url: "https://api.deepseek.com/v1"
改完配置后重启服务。然后在 IM 里给机器人发一条“你好”，如果一切正常，你会在 journalctl -u openclaw -f 里看到收到消息的日志，同时群里出现机器人的回复。到这里，远程网关的核心链路就算彻底打通了。
5. 从玩具到工具：Skill 让远程网关真正“干活”
5.1 Skill 机制是什么
网关通了之后，OpenClaw 就从一个“只能聊天的虾”变成了“能在外面指挥的虾”。但要让它真正干活，还得靠 Skill。
Skill 的本质是一组指令和脚本的封装。你可以把它理解成给 Agent 安装的“外挂技能包”：告诉它“当用户要求查天气时，调用这个接口解析数据”，或者“当用户要求生成周报时，执行这个脚本汇总数据”。OpenClaw 的 Skill 目录通常在 ~/.openclaw/skills/ 下，每个 Skill 是一个独立文件夹，里面至少有一个 SKILL.md 描述文件，以及一个或多个可执行脚本。
5.2 手写一个最小 Skill
一个最基础的 Skill 的目录结构长这样：
code复制~/.openclaw/skills/
└── server-disk/
├── SKILL.md
└── check_disk.sh
SKILL.md 的内容是告诉模型在什么场景下调用这个 Skill、怎么调用：
markdown复制---
name: server-disk
description: 检查 OpenClaw 所在服务器的磁盘使用情况
triggers:
- 磁盘
- 空间
- disk
- df
---
执行 `bash {{skill_dir}}/check_disk.sh`，将输出结果原样返回给用户。
check_disk.sh 则实现具体的逻辑：
bash复制#!/bin/bash
df -h | head -20
把这个脚本放进目录后，在 OpenClaw 里执行 openclaw skill reload 加载一下，再通过 IM 机器人说“看一下磁盘”，它就会自动调用脚本并把结果回传给你。你可以在这个基础上扩展出无数玩法：查服务器状态、调用外部 API、抓取网页、执行定时任务……本质上都是同一个套路。
5.3 让网关主动说话：定时推送与告警
远程网关还有一个很有意思的能力：让 OpenClaw 主动找你，而不是每次等你找它。做法是在服务器上配置一个 cron 任务或者脚本，定时调用 IM 的 Webhook 推送消息。
比如每天早 8 点推送一份“今日待办摘要”，或者当服务器磁盘超过 80% 时推送告警。这类需求不一定非得写进 Skill，直接用 cron 配合 Shell 脚本就能实现。我自己有一个脚本，每天定时检查服务器负载、OpenClaw 进程状态和磁盘用量，把摘要推到飞书群里，养虾养出了“监控大屏”的感觉。
bash复制#!/bin/bash
STATUS=$(systemctl is-active openclaw)
DISK=$(df -h / | awk 'NR==2 {print $5}')
MSG="OpenClaw 状态: ${STATUS}\n磁盘使用率: ${DISK}"
curl -X POST -H "Content-Type: application/json" \
-d "{\"msg_type\":\"text\",\"content\":{\"text\":\"${MSG}\"}}" \
https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxx
这一步做扎实之后，OpenClaw 才真正从“你问它答”变成了“替你操心”。
5.4 远端维护的一些实用技巧
网关跑在云服务器上，日常维护基本靠 SSH。这里分享几个实用习惯：
- 看日志用
journalctl -u openclaw -f，错误信息定位最快。 - 修改配置文件前先备份
~/.openclaw。 - 想彻底重置 OpenClaw，不要直接删目录，用官方提供的卸载命令或先停服务，避免文件占用问题。
- 远程改配置导致起不来的时候，别慌，先看日志，大部分是缩进错误或者环境变量没生效。
6. 稳定运行与安全加固：别让网关裸奔在公网
6.1 服务器基础安全：三条底线必须守住
网关一旦跑在公网服务器上，暴露面就完全不一样了。那些扫描公网 IP 的僵尸程序不会因为你是个小项目就手下留情。我建议至少做三件事：
第一，SSH 禁止密码登录，改用密钥。把本机公钥追加到服务器的 ~/.ssh/authorized_keys 后，编辑 /etc/ssh/sshd_config，设置 PasswordAuthentication no，重启 sshd。
第二，用防火墙限制端口。只放行 SSH 端口、HTTP/HTTPS 端口以及必要的服务端口，其余全部拒绝。
bash复制sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
第三，不要用默认 SSH 端口。把 Port 改成一个高位端口，能挡掉绝大多数无差别扫描的噪音。
6.2 回调接口安全：验签必须开着
IM 平台配置回调时，通常会生成一个 Token 或加解密参数。有些人在本地调试时为了省事，把验签功能关了，这是非常危险的做法。一旦回调地址被扫到，任何人都可以伪造消息发给你的机器人，诱导 Agent 执行恶意指令。
正确的做法是：IM 平台的验签逻辑保持开启，同时在 OpenClaw 配置里如实填入 Token、EncodingAESKey 或 Encrypt Key，让它能正确解密并校验请求。不要因为“本地测着麻烦”就关掉，这点偷懒会让整个网关失去安全边界。
6.3 前端加一层 HTTPS：用 Nginx 做请求转发
前面提到 OpenClaw 的端口只绑定在 127.0.0.1，那么 IM 平台怎么访问它呢？答案是在前面加一层 Nginx，监听 443，做 TLS 终结和请求转发。
一个最简配置大概是这样的：
nginx复制server {
listen 443 ssl;
server_name your-domain.com;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/key.pem;
location /openclaw/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
HTTPS 证书可以用 Let’s Encrypt 免费申请，配合自动续期，基本是一劳永逸。很多 IM 平台回调时也会更信任 HTTPS 地址，有些甚至强制要求 HTTPS。
6.4 日志与备份：虾死了要能复活
OpenClaw 跑得再稳，也要预想翻车时的恢复方案。日志方面，配置 logrotate 防止日志文件无限增长撑爆磁盘：
bash复制/path/to/openclaw/logs/*.log {
daily
rotate 7
compress
missingok
notifempty
}
备份方面，~/.openclaw 目录包含全部配置、身份和数据，是整个网关的核心资产。写个定时打包脚本，把目录压缩后传到对象存储或者别的机器上。真要迁移到新服务器，只要 Node 版本满足要求，把这个目录拷过去再启动，基本就能恢复原样。
7. 高频翻车现场：搜索关键词里的坑我都替你踩过了
7.1 “Agent run failed before producing a reply”
这是最常见、也最让人头大的报错。它的本意是 Agent 还没生成回复就挂了。根据我的排查经验，按以下顺序定位：
- 模型 API Key 是否有效、额度是否耗尽；
- Base URL 是否填对，DeepSeek、OpenAI 各有各的接口地址；
- 配置的模型 ID 是否正确，很多供应商的实际模型 ID 和宣传名不一样；
- 消息上下文是否太长，导致模型接口报超限。
排查时把日志级别调到 debug，通常会看到上游 API 返回的具体错误码，比看这句笼统报错有用得多。
7.2 “node runtime not found”和 Node 版本限制
这类报错多半出现在 Windows 安装脚本里，或者使用了系统自带的老版本 Node。OpenClaw 对 Node 版本的要求非常严格，装完 Node 之后先确认版本落在官方要求的区间内，再用 node -v 验证。
7.3 Windows 下 “EBUSY: resource busy or locked, unlink”
这个报错我见的次数太多了。你在 Windows 上想删除 ~/.openclaw 目录重新初始化，结果系统提示文件被占用。原因通常是还有 OpenClaw 进程、TUI 界面或者残留的 node 进程没退出。
解决方法很简单：打开任务管理器，把所有 node 进程结束掉，关掉所有正在运行 OpenClaw 的终端窗口，再执行删除。如果还是不行，重启一次电脑再删，基本肯定能清掉。
7.4 “unknown model: deepseek”
配置里写了 deepseek 作为模型 ID，但供应商那边实际的模型 ID 可能是 deepseek-chat 或 deepseek-reasoner。这类问题本质上是模型名映射没写对。可以查一下当前模型供应商的模型列表，在配置里改成准确的 ID。
7.5 “Control UI did not start”
WebUI 面板起不来，大概率是端口被占用。8080 端口被别的服务抢走是家常便饭。改个端口就能解决，注意改端口后 Nginx 转发也要同步更新。
7.6 给 Windows 用户的最后建议
尽量用 WSL2 跑 OpenClaw，别在原生 Windows 环境折腾。不是 Windows 不行，而是很多开源工具链对 Linux 环境的适配更完善，排障时网上的方案也大多基于 Linux。如果非要在 Windows 上跑，注意安装路径别有中文和空格，开发版 Node 不要用。
结尾：网关通了，才算真正开始“养虾”
我到现在还记得第一次在外地用手机给企业微信里的 OpenClaw 发消息，它回复我的那一刻。当时人还在高铁上，服务器在几百公里外的机房，模型请求发到另一个服务商的 API。那一刻最直接的感受是：这只虾终于不只是活在终端里的玩具了。
回顾整个搭建过程，你会发现真正花时间的不是装 OpenClaw，而是想清楚网关的架构、搞定消息回调和排掉那些看似不起眼的坑。我的建议是：先定一个小目标，比如“让网关能稳定响应 IM 消息”，把这条链路跑通，再慢慢加 Skill、加定时任务、加多模型切换。虾先养活，再谈养好。网关通了之后，后面所有玩法才有根基。