OpenClaw京东云部署指南：从智能体框架到常驻服务

1. 先搞懂OpenClaw在京东云上到底跑了个什么东西

1.1 我眼中的OpenClaw：大脑、手、嘴

先说结论：OpenClaw不是一个聊天网页，也不是某个模型的手机App，它更像一个跑在你自己机器上的智能体运行框架。你可以把大模型的API当成它的“大脑”，把能执行任务的各种Skill当成它的“手”，把微信、Web、命令行这些入口当成它的“嘴”。大脑负责思考和输出，手负责真正干活，嘴负责跟外界对话。

我第一次看到这个项目时，最强烈的感受是“这不就是个聊天机器人吗”。后来实际部署完才发现，判断一个智能体框架好不好用，关键不在于它能不能聊天，而在于它能不能把“聊天”转换成“行动”。比如让它在指定目录里整理文件、定时抓取某个页面的信息、把群里的提问汇总成日报——OpenClaw这类框架的核心卖点就是把模型输出变成可执行的步骤。

在京东云上跑OpenClaw，本质上就是给自己准备一台24小时在线的云主机，然后把OpenClaw的服务端装上去。让我下决心折腾的原因其实很朴素：家里的电脑不能一直开着，而很多智能体场景需要长时间挂着。比如接一个微信群机器人，半夜群里有人问问题，如果服务跑在个人电脑上，电脑一休眠就断了。放到云服务器上，这个问题基本不存在。

我这次选京东云，不是因为有什么独家优势，单纯是手头有一台闲置的云主机，而且它的控制台操作路径对新手还算友好。标题里写“京东云”，不是说只有京东云能这么玩，而是把整个操作过程限定在一台真实的云服务器上，避免空谈理论。你换成其它云厂商的Linux服务器，绝大部分步骤是一样的。

1.2 为什么我把部署目标放在了京东云

很多教程上来就让你装Docker、拉镜像，但从来不解释为什么要这么做。这里先说清楚选择云服务器的逻辑。

第一点，OpenClaw需要长期运行。本地部署最大的敌人是断电、睡眠、网络波动。云服务器只要不欠费，一般不会出现半夜自动关机的情况。第二点，它需要对外开放端口。如果你想让微信机器人或Web页面能访问到它，服务端必须有一个公网可达的地址。家里宽带虽然也能做端口映射，但运营商动态IP、路由器设置、安全策略，每一项都可能让新手折腾到崩溃。第三点，环境隔离。OpenClaw会在服务器上创建自己的工作目录、配置文件、执行审批记录，这些东西丢在自己的主力电脑上，出了事故容易影响日常使用。

这台京东云服务器的配置我很老实地说，不需要太高。我用的是一台2核4G内存的实例，系统选的Ubuntu 22.04 LTS。跑OpenClaw本体、接一个模型API、常驻一个微信通道，资源占用并不夸张。内存占用通常在1G到1.5G之间浮动，CPU在空闲对话时几乎可以忽略，只有在触发批量任务或技能执行时才会短暂冲高。

选Ubuntu 22.04主要是因为社区资料多、依赖好装。如果你熟悉Debian或CentOS也可以，但后面涉及的一些包管理器命令会不一样。对新手而言，跟随一个主流系统能少踩很多坑。

1.3 一次典型使用背后发生了什么

为了后面章节不跑偏，这里先描述一下部署完成后，用户发一条消息给OpenClaw时，内部会依次发生什么。理解这个流程，后面排查问题会顺畅很多。

消息先进到接入层。如果你接的是微信，那就是微信的收件回调到OpenClaw；如果你开的是Web界面，那就是浏览器请求打到Web服务。OpenClaw收到消息后，会做一轮上下文整理，把当前对话历史、长期记忆、用户身份信息拼装成一次模型请求。模型返回的文字会被OpenClaw解析，判断里面是否包含需要执行工具的指令。如果判断需要调用Skill，它会弹出一个执行审批请求，允许后才真正执行命令或脚本。最后把执行结果返回给模型，模型再整理成用户能看懂的自然语言。

也就是说，模型不是直接操作服务器，它只是提出“想干什么”，真正动手的是OpenClaw的执行器。这套机制保证了安全性，也引出了很多新手必踩的坑，比如审批文件、权限控制，这些我在第6章会集中讲。

2. “2分钟集成”的真实边界：哪些事提前做好了，才有2分钟

2.1 我实测下来，2分钟从哪一秒开始计时

标题写了“2分钟集成”，我得先坦白，这个2分钟不是从零开始。

我第一次部署时，光是看文档和理解目录结构就花了将近半小时。如果你把买服务器、注册模型API、实名认证这些时间都算上，那怎么也得一个小半天。“2分钟”指的是什么？指的是在你已经把服务器准备好、模型API Key已经拿到手的前提下，从开始执行安装命令，到OpenClaw能正常回复第一条消息，这段操作时间可以压缩到2分钟左右。

这个前提很关键，但我见过太多教程刻意模糊它。他们展示的效果是“一行命令装完”，但实际上你在终端看到安装进度条之前，已经默默完成了系统初始化、安全组配置、API密钥申请。所以这篇文章我会把“前置准备”单独拎出来讲，这才是决定你是否顺利的核心。

如果你是老手，可能觉得这些准备工作不值一提。但“喂奶级步骤”的意思就是，每一步我都按新手会卡住的地方来写，宁滥勿缺。

2.2 服务器参数：2C4G还是4C8G

先给一个可以直接抄的结论：单机测试、个人使用，2核4G足够；打算接多平台、跑频繁任务、挂多个模型，建议直接4核8G。

我实际在2核4G上跑了一周，日常使用没有明显卡顿。唯一一次感觉到瓶颈，是让OpenClaw同时处理两个稍重的任务，日志里出现了明显的等待。查看监控发现内存占用接近3.5G，当时正在运行一个需要加载较大数据集的Skill，加上模型上下文历史越攒越多，内存压力就上来了。

如果你问我的建议，京东云这类云主机新用户活动价通常很便宜，与其买2C4G后面再升级，不如一步到位选4C8G。差别不只在性能，更在容错。智能体框架这种东西，跑起来之后你会忍不住给它接越来越多功能，内存这玩意儿，预留比折腾扩容舒服多了。

磁盘默认给40G到50G也够用。OpenClaw的工作目录会随着对话记录和技能缓存逐渐变大，但正常用一两个月不会有压力。记得别把日志文件当摆设，后面我会提到日志轮转的问题。

2.3 提前备好的物料清单

再罗列一份清单，对照准备就行。

• 一台Linux云服务器，推荐Ubuntu 22.04，已绑定公网IP，能通过SSH登录。
• 一个模型API Key。这里要重点提醒，OpenClaw本身不带模型，它需要调用外部大模型API。目前主流方式是用OpenAI兼容协议的接口，这就意味着很多国产模型也能接，只需要把接口地址和模型名称改掉。
• 一个用来测试的机器人身份。如果只想用Web界面调试，这一步可以先跳过；如果要接微信，需要准备机器人账号或企业微信相关配置。
• 基本的SSH工具，Windows用户可以用PowerShell自带SSH，也可以装Termius之类的工具。

这些看起来简单，但每一项都可能成为新手卡住的点。尤其是模型API Key，很多人第一次接触API，不知道去哪里创建。现在主流的模型服务商基本都有控制台，登录后找到“API Key管理”或“密钥管理”，创建一个即可。创建完之后一定要立刻复制保存，很多平台只显示一次。

2.4 安全组与入站规则别忽略

云服务器和本地电脑最大的一个区别是安全组。京东云控制台里叫“安全组”，本质是一个虚拟防火墙，控制哪些端口可以从公网访问。

如果你某一天发现OpenClaw服务明明启动了，浏览器却死活打不开，十有八九是安全组没有放行对应端口，而不是程序出了问题。

默认情况下，OpenClaw的Web管理界面会监听某个本地端口。为了安全，我建议不要把Web面板直接暴露到公网。真正的用法是只允许本机或内网访问，平时通过SSH隧道来查看，或者干脆放在本机端口中用命令行管理。微信接入的收件回调则必须放行对应端口，这个按官方文档要求配置即可。

我在安全组上踩过的坑是这样的：第一次只放行了SSH的22端口，安装完成后用浏览器去访问管理面板，一直超时。排查了很久才发现是安全组没放行目标端口。放行之后秒开。这个坑很小，但很典型。

3. 懒人可用但能看懂的部署实操

3.1 初始化服务器

拿到一台全新的京东云服务器后，第一步不是装OpenClaw，而是先做基础初始化。

SSH登录服务器，先更新系统软件源：

bash复制sudo apt update && sudo apt upgrade -y

然后创建一个专门用于运行服务的用户，不建议一直在root下操作。后面OpenClaw会有执行审批机制，如果服务跑在root上，一旦Skill里的命令出了偏差，影响面会非常大。

bash复制sudo useradd -m -s /bin/bash claw

把当前用户加到sudo组，或者直接用usermod都行。这一步不是必须的，但我会习惯性地做隔离。接着安装常用工具，比如curl、wget、vim，以及后面可能用到的git。

bash复制sudo apt install -y curl wget git vim

这些操作看起来跟OpenClaw没关系，但它们是后续所有步骤的地基。我见过有人在没装curl的极简镜像里执行安装脚本，结果第一条命令就报command not found，然后就开始怀疑人生。

3.2 安装OpenClaw主程序

安装这一步，不同版本提供的命令不一样。以当前常见版本为例，官方提供了两条路线：一是使用一键安装脚本，二是下载便携压缩包手工解压。

一键安装脚本的好处是快，自动处理依赖；坏处是如果网络不好，脚本中断后的残留状态会让你很痛苦。便携压缩包的好处是可控，下载解压后就能用，删掉文件夹即卸载，适合喜欢干净环境的人。

我的选择是便携包。原因很简单，可控。服务器上跑一个常驻服务，我希望能明确知道每个文件在哪里，出了故障能自己处理。脚本方式虽然快，但对新手来说，它把整个安装过程变成了黑盒，一旦出错很难排查。

下载安装包时要注意CPU架构。绝大多数云服务器是x86_64架构，如果你买的是ARM实例，需要下载对应的ARM版本。用命令行查看架构：

bash复制uname -m

得到x86_64就选amd64的包，返回aarch64就选arm64的包。下载完成后解压到/opt或用户目录下，然后把可执行文件路径加入PATH：

bash复制sudo tar -zxvf openclaw_linux_amd64.tar.gz -C /opt/
sudo ln -s /opt/openclaw/openclaw /usr/local/bin/openclaw

然后验证一下版本：

bash复制openclaw --version

能看到版本号输出，说明主程序已经装好了。从这里开始，才进入“2分钟”倒计时。

3.3 第一次启动会生成什么

执行：

bash复制openclaw init

这一步会初始化工作目录。初始化完成后，在用户目录下会生成一个.openclaw文件夹。里面通常包括配置文件、工作空间、运行日志、审批记录等几个核心内容。

我在第一次看到这个目录时一度很懵，里面文件太多，不知道哪个是干什么的。实际只要重点关注这几个：

• 主配置文件，控制模型连接、服务端口、全局参数。
• workspace目录，OpenClaw执行文件操作时的默认工作目录，相当于它的“家”。
• exec-approvals.json，记录哪些命令被允许直接执行，哪些还需要人工审批。
• 日志文件，排查问题时的第一现场。

初始化完成后，直接启动服务：

bash复制openclaw serve

但如果此时你还没有配置模型和入口，它大概率会启动失败，或者起来了也无法正常回复。所以不要急着测试，先把第4章的配置做完再回来启动。

3.4 验证服务是活着还是伪活

很多人说“我明明启动了，为什么用不了”，这里要区分两个概念：进程在跑，和功能可用，是两回事。

进程在跑，只说明主程序没有崩溃。功能可用，要求模型连接正常、入口通道连通、认证通过。验证方法很简单，看日志。

bash复制openclaw logs -f

一个正常的启动日志应该包含：配置文件加载成功、模型客户端初始化完成、入口通道注册成功、监听端口启动。如果其中任何一行后面跟着error或failed，都说明某个环节有问题。

另外一个很实用的验证方法是直接在工作目录里跑一个最简单的命令行对话：

bash复制openclaw run

这个命令会启动一次交互式会话，你直接在里面问一句“你好，请回复一句话证明你在线”。如果能正常收到回复，说明核心链路是通的，后面再排查入口通道就简单多了。

4. 模型与记忆配置：没有这两项，OpenClaw只是空壳

4.1 Config里最核心的模型连接

OpenClaw的主配置文件里，模型相关的配置核心只有几个字段：API地址、API Key、模型名称。看到这里别笑，很多人花最多时间的就是这个看起来最直白的部分。

你需要搞清楚一个概念：OpenClaw并不知道模型叫什么，它只知道向某个地址、带某个密钥、发某个模型名。换句话说，你告诉它“去这个地址找叫deepseek-r1的模型”，它就真的会这么去找。

配置后千万不要忘了把默认模型改成你实际使用的那一个。很多人在这一步报错“unknown model”，原因就是他们填了一个OpenAI官方根本不存在的模型名，或者填了一个当前账号没有开通权限的模型。模型服务商返回错误后，OpenClaw只负责把错误抛给你，并不会帮你纠错。

我测试下来，最稳妥的做法是先单独用curl或任意HTTP调试工具测一下API连通性，确定Key有效、模型名正确，再去改OpenClaw配置。跳过这个验证步骤，你会分不清问题出在OpenClaw还是模型服务商。

4.2 千问等多模型如何共存

OpenClaw支持配置多个模型，这对我这种喜欢多家对比的人非常实用。你可以把主模型设置成一个日常对话能力强的，同时备一个推理模型用于复杂问题拆解，再准备一个便宜或免费的模型来处理批量简单任务。

热搜词里提到的“openclaw 使用千问免费token”，其实就是指把千问这类模型的免费额度套餐接进OpenClaw。操作上并不复杂，关键是找到正确的API地址。以DashScope兼容模式为例，你把Base URL填成兼容地址，再填入千问的API Key，模型名称填成千问对应的标识字符串即可。

多模型配置的实际价值，不只是省钱。不同模型擅长的事情不一样。我经常遇到一个长文本总结任务，如果走贵的旗舰模型，消耗快得惊人；如果走便宜模型，效果又不够稳定。于是我会写一个小Skill，让它自动根据任务类型分流到不同模型。省了成本，效果也稳。

4.3 跑起来才真正理解Active Memory的作用

配置好模型，OpenClaw已经能回话了。但如果你只用它做纯问答，根本不值得专门部署到云服务器上。真正拉开差距的，是记忆系统。

OpenClaw有一个长期记忆机制，很多资料里管它叫Active Memory。这种记忆不是简单地把聊天记录存下来，而是把每次对话中提炼出的用户偏好、任务状态、关键事实写入一个可检索的存储里，之后的对话会自动调取相关内容。

举个例子。你告诉OpenClaw“我平时喜欢简洁回复，不要超过三句话”，如果它没有记忆机制，下次换个会话窗口它又忘记了。有了长期记忆，哪怕你重启服务，它再次醒来时仍然记得这个偏好。更进阶的用法是让记忆和工作流绑定：比如你跟它说“每天早上九点帮我整理项目进度”，它会把这句话记住，并且结合定时任务每天执行。

我在服务器上真正把这套东西用起来，是在连续几天测试之后。一开始觉得长期记忆就是花架子，后来让它基于前几天讨论过的技术方案生成一份对比分析，它居然能准确引用几天前我说过的一句话。那一刻我才觉得，这不只是一个聊天框，确实是个“有记性”的工作助手。

Active Memory的日常维护需要关注一下。记忆内容多了之后，检索准确率可能会下降。你需要定期清理无用记忆条目，或者在对话中直接让它遗忘某些不再需要的信息。这个管理动作在Web面板或命令行里都能做，建议每周花一两分钟扫一眼，别让记忆库变成垃圾堆。

5. 接微信、加Skill，才算把Agent用进日常

5.1 给OpenClaw装上一个微信入口

命令行里能聊，只是一个阶段性的胜利。真正让OpenClaw融入日常，我选择给它接一个微信入口。

做这件事前，我要先把预期管理好。接微信和直接跑一个Web服务不一样，它依赖机器人账号的接入方式。不同的接入协议有不同的限制，有些方案要求客户端保持在线，有些方案需要企业微信的配置，没有一个万能方案能通吃所有情况。具体选哪种，要看官方文档当前的推荐，别照着某篇老教程硬套。

接入的核心逻辑其实很简单：微信侧收到消息后，把消息内容通过回调或Webhook发送到OpenClaw监听的端口；OpenClaw处理后，把回复内容原路返回。这个链路里，最容易出问题的就是端口连通性和消息格式。

如果你的OpenClaw在云服务器上，微信服务通过公网回调你的服务器，那么安全组必须放行对应端口。我用的是京东云控制台的安全组管理，添加入站规则时，端口范围填实际监听端口，协议选TCP，来源建议先填一个测试范围，调试通了再收紧。

第一次接入成功时，我给自己的小号发了一句话，十几秒后收到了OpenClaw回复。那一刻确实有点兴奋，因为这意味着你可以用平时最常用的聊天工具跟一个私人智能体对话了。它在做事的时候，不再需要你打开任何面板，像聊天一样就能管理日程、查资料、执行命令。

5.2 Skill机制：别让它只会耍嘴皮子

模型本身是“嘴”，Skill才是“手”。在OpenClaw里，如果你只是聊天，那不需要Skill；但如果你想让它“做点什么”，就必须装对应的Skill。

Skill本质上是一段预设的能力封装，比如一个“定时提醒”Skill、一个“网页抓取”Skill、一个“文件整理”Skill。你需要在配置里加载对应的Skill，然后模型在对话中发现用户需求时，就会自动匹配并调用。

第一次测试Skill，我选择一个简单的场景：让OpenClaw读取我指定的一个URL页面，提取标题和正文摘要。装好Skill后，我发了一条消息：“打开这篇新闻链接，提炼三句话摘要。”OpenClaw没有直接回答，而是先调用网页抓取Skill，抓完页面后把结果交给模型做摘要，最后返回一段非常精炼的三句话。

新手最容易犯的错误，是想一次性把所有Skill都装上。我劝你反过来，先装一个做通一个场景。Skill越多，模型判断和选择的成本越高，出现误调用的概率也越大。比如你已经装了“定时器”Skill和“文件删除”Skill，万一模型错误理解了你的意图，后果就需要你自己背。

5.3 运行日志里值得留意的几个指标

经过几天的运行，我建议你培养一个习惯：偶尔翻翻日志。

日志不是只有在报错时才看，它还会记录每次请求的耗时、模型token消耗、Skill执行时间、审批动作。我会重点关注几个指标。

第一个是请求响应时间。如果某天开始响应变慢，先确认是模型侧问题还是OpenClaw侧问题。模型侧通常是服务商波动，OpenClaw侧则可能是内存不足或日志积压。第二个是token消耗。OpenClaw每次对话都会把历史上下文一起发给模型，如果对话太长，token消耗会指数级上升。第三个是审批记录。查看哪些命令被自动批准执行了，这是衡量风险的重要指标。

在服务器上跑Agent，天然就有一个“信任边界”问题：你愿意让它在多大范围内自动执行操作。我的原则是，一开始全部手动审批，跑熟之后再逐步放行常用的无风险命令。

6. 从报错到稳定的排查全过程

6.1 “unknown model”这类报错到底在说啥

我在部署过程中遇到的最典型报错，是模型应答阶段直接失败，提示模型不存在。搜热搜词也能看到很多人遇到过：Agent failed before reply: unknown model。

这个报错乍看像是OpenClaw的问题，其实是配置里填写的模型名与模型服务商实际支持的模型名不一致。

排查过程分三步。第一步，打开配置文件，确认默认模型名和你API Key所属账号是否匹配。第二步，去模型服务商的文档中查“模型列表”，找到准确的模型标识字符串。很多模型对外展示的名称和API调用名称不一样，展示名是“千问Plus”，API里的调用名可能是一串带日期或规格标识的字符串。第三步，改完配置后重启OpenClaw，再次测试。

不要小看这三步，我至少看到几十个人卡在第二步。他们拿着文档里的展示名往配置里填，能成功才怪。API配置永远以官方文档里的“模型ID”或“model name”列表为准，别凭印象敲。

6.2 exec-approvals.json 弹出审批提示怎么办

运行时OpenClaw会提示审批记录文件的位置，内容类似：current record in /root/.openclaw/exec-approvals.json。很多新手看到这个文件很慌，不知道它是干什么的，更不知道能不能删。

这个文件是命令执行审批的台账。当模型提出要执行某条命令时，OpenClaw的审批机制会判断这条命令是否在“白名单”里。如果在，就直接执行；如果不在，就需要你手动批准。

我一开始的做法是看到审批弹窗就手动确认，后来越来越烦，就想着把所有命令都加进白名单。这是安全隐患最大的操作。模型是由外部API驱动的，它的输出是概率性的，哪怕99%的情况都正常，那1%的异常输出也可能包含危险命令。如果全自动放行，就等于把服务器的root权限交给了一个概率模型。

正确的做法是只放行那些可预期、低风险、固定格式的命令。比如“读取某个文件”“列出目录内容”这类只读操作，可以加入白名单。涉及删除、写入系统目录、执行网络请求的命令，保持手动审批。审批文件可以用文本编辑器直接改，但一定要备份原文件后再动手。

6.3 在云服务器上最容易被忽略的三个不稳定因素

OpenClaw在本地电脑上跑，可能一切正常；放到云服务器上，就开始出现各种玄学问题。我调过几次之后发现，所谓玄学基本都是下面三个因素造成的。

第一个因素是内存不足。云服务器不像本机有几十G内存，2C4G的配置很容易被各种后台进程塞满。OpenClaw启动后内存占用看着不高，但一次长对话、一次大模型响应、一次Skill执行同时发生时，内存可能瞬间飙升。如果系统没有swap，进程可能直接OOM被杀，表现就是服务突然失联。所以我强烈建议给服务器加2G或4G的swap分区，加完能解决大半“莫名其妙挂掉”的问题。

第二个因素是时钟偏移。云服务器如果长时间不重启，系统时间可能与真实时间产生偏差，导致HTTPS请求的证书校验失败。OpenClaw调用模型API时如果突然开始报SSL错误，第一个想到的不是配置，而是检查系统时间。

第三个因素是端口冲突。OpenClaw默认使用的端口可能已经占用了。用命令查一下端口占用情况，把OpenClaw的监听端口换掉即可，改动很小但排查起来很费时间。

6.4 一套能复用的排查顺序

遇到OpenClaw部署问题，我形成了一套固定排查顺序，按下面这个列表来，能避免大多数盲目尝试。

• 第一步，看日志。任何问题都先翻日志，重点关注日志中error和failed字段的前后信息。
• 第二步，复现最小链路。跳过通道和Skill，直接跑一次命令行对话，看核心链路是否正常。
• 第三步，检查模型API连通性。单独调用一次API，确认密钥和模型名没问题。
• 第四步，排查网络和端口。测试端口监听状态、安全组策略、入站规则。
• 第五步，检查系统资源。内存、磁盘、时间、CPU占用。

这五步看着枯燥，但每一条都可能对应数小时的无效排查。按顺序执行，比你挨个搜报错再试着改配置高效得多。

7. 跑完这一轮，我对“集成”这件事有了新理解

7.1 别再神话“2分钟”，流程标准化才是重点

这次折腾下来，我对“2分钟集成”有了自己的理解。真正的2分钟，来自于流程的标准化和前置工作的完善，而不是工具本身有多快。

我把自己从零到一的步骤做了复盘，发现耗时主要集中在几个地方：申请API Key时的账号配置、微信入口的通道选择、安全组策略的反复调整。一旦把这些都跑顺，后面再部署第二台、第三台服务器，真的就是几分钟的事。所以这篇文章最想传递的经验不是某个命令有多厉害，而是“把准备工作做在前面”这个思路。

7.2 从一个玩具到常驻服务，还需要补哪些课

如果你跟着前面的步骤把OpenClaw跑起来，恭喜，你已经越过了最难的从无到有。但它此刻还是一个玩具，距离一个稳定可依赖的服务还有几步路要补。

第一是开机自启。OpenClaw不会因为你登录服务器才启动，你需要让它在系统启动后自动在后台运行。用systemd写一个服务单元是比较干净的做法，设置好开机自启后，就算云服务器意外重启，OpenClaw也能自己活过来。

第二是日志轮转。运行时间一长，日志文件会越来越大，不仅占磁盘，还会影响排查时翻日志的速度。配置按大小或天数切分的日志，别让单文件无限增长。

第三是定期备份。OpenClaw的整个.openclaw目录就是它的全部状态，包含配置、记忆、工作空间。你只需要打包这个目录，定时同步到另一个存储位置即可。这样即使服务器报废，换一台机器，解压恢复就能满血复活。

我在把这些做完之后，OpenClaw才真正从“一个可以玩的玩具”变成了“一个值得托付日常杂事的常驻服务”。现在它每天早上给我推一次待办摘要，我不用再打开任何面板去查看，它自己会把结果发过来。

这就是我这一轮在京东云上折腾OpenClaw的全部过程。里面没有魔法，都是踩过坑之后梳理出来的笨办法。但笨办法只要有效，就是好办法。如果你在部署时卡在哪一步，不妨试试回到我这套流程的前置准备和排查顺序里去找答案。