OpenClaw 2026.8.2 升级实录：SERVICE_DEFINITION_SEALED、systemd 与多 Agent 怎么修

这篇不是 Release Notes 翻译，而是一次真实升级现场的匿名化复盘。

环境是 Ubuntu VPS、npm 全局安装、Gateway 长期常驻、多个 Agent，并接了多个飞书账号。OpenClaw 从 2026.7.1-2 升级到 2026.8.2。升级过程中 Core 实际已经成功更新，但自动重启 Gateway 时出现：

SERVICE_DEFINITION_SEALED: [system-owned]
SystemSystemdOwnershipError
Refusing to create or activate a user systemd unit with the same name

随后执行 openclaw status，又遇到：

Multiple agents are configured, but this operation has no explicit owner.

最后没有重装 OpenClaw，也没有删除 ~/.openclaw。通过重新确认 systemd ownership、保留唯一 Gateway manager、设置 multi-agent system owner 和显式 channel binding，服务恢复正常。

如果你也是 Linux/VPS 长期跑 Gateway，这次经验比“升级命令怎么敲”更重要。

先说结论：这次最值得记住的 6 件事

1. openclaw update 报 Gateway restart failed，不等于 Core 升级失败。 先看 openclaw --version。
2. system-level systemd 和 user-level systemd 不能同时管理同一个 Gateway 名称/端口。 只能选一个生命周期管理者。
3. VPS 上如果本来由 /etc/systemd/system/openclaw-gateway.service 管理，就不要再跑 openclaw gateway install 去创建同名 user service。
4. 多 Agent 环境要给 ambient system work 一个明确 owner。 agents.defaults.systemAgent.agentId 是当前官方入口。
5. routing binding 和 channel runtime 是两回事。 有 binding 不代表飞书账号已经 running, connected, works。
6. 以后 system-owned Gateway 更适合用 openclaw update --no-restart，然后由原生 systemd 手动重启。

下面按现场顺序拆开。

1. 升级前先 dry-run：先确认“我要从哪升到哪”

这次最有用的第一步不是直接更新，而是：

openclaw update --channel stable --dry-run

现场输出确认了：

Current version: 2026.7.1-2
Target version: 2026.8.2
Channel: stable
Mode: npm

而且 dry-run 明确列出了计划动作：

• 更新全局 npm package
• 同步 tracked plugins
• 刷新 shell completion
• 重启 Gateway
• 运行 doctor checks

这一步的意义是：先把“版本选择错误”排除掉。

如果 dry-run 的 Target 不是你预期的 stable，或者安装模式和你记忆中的不一致，先停下来，不要把后面的故障和版本选择混在一起。

当前稳定版与版本定位可以同时参考版本中心和2026.8.2 更新解读。

2. Core 已经升到 2026.8.2，但自动重启失败：先别回滚

实际执行升级后，关键错误是：

Failed to refresh gateway service environment from updated install
SERVICE_DEFINITION_SEALED: [system-owned]

以及：

Refusing to create or activate a user systemd unit with the same name
because duplicate managers can restart-loop the gateway.

第一反应很容易是“升级把 OpenClaw 搞挂了”。

但这个判断太早。

先执行：

openclaw --version

如果已经显示目标版本，例如：

OpenClaw 2026.8.2

说明至少 Core package replacement 已经完成。当前失败发生在后面的 service refresh / restart 阶段。

2026.8.2 的 updater 对 service ownership 更保守：如果它判断同名 Gateway 已经由另一层 system manager 所有，就不会为了“把更新跑完”强行覆盖 service definition，更不会偷偷再创建一套竞争的用户级服务。

这类错误应该先按服务生命周期问题排查，而不是立刻重装 Core。

3. SERVICE_DEFINITION_SEALED 到底在保护什么

Linux 下 OpenClaw 常见有两种 systemd 运行方式。

user-level service

典型路径：

~/.config/systemd/user/openclaw-gateway.service

常见管理命令：

systemctl --user status openclaw-gateway.service
systemctl --user restart openclaw-gateway.service

这是 OpenClaw CLI 默认更容易管理的一类服务。

system-level service

典型路径：

/etc/systemd/system/openclaw-gateway.service

常见管理命令：

sudo systemctl status openclaw-gateway.service
sudo systemctl restart openclaw-gateway.service

官方当前明确建议：多用户 / always-on 主机可以使用 system unit。 这种部署的生命周期由系统管理员负责。

问题出在：如果一台机器同时残留了 system unit 和 user unit，或者 Core updater 发现 system unit 已经占用同一个 Gateway unit name，它不能安全假设“我可以再生成一个 user unit”。

两个 supervisor 同时拉起同一 Gateway，最坏会出现：

• 端口抢占
• 进程互相重启
• 新旧安装根混用
• 环境变量/SecretRef 来源不一致
• Gateway 看似在线，但实际运行的是另一套 Node/OpenClaw

所以 SERVICE_DEFINITION_SEALED 不是“systemd 坏了”，而是一个所有权保护机制。

4. 先查清楚谁在管理 Gateway，不要猜

现场应该同时看两个 scope：

systemctl --user status openclaw-gateway.service --no-pager
sudo systemctl status openclaw-gateway.service --no-pager -l

再看实际 system unit：

sudo systemctl cat openclaw-gateway.service

如果 user unit 也存在，再检查：

systemctl --user cat openclaw-gateway.service

你要回答的不是“哪个命令能把它启动”，而是：

以后到底由谁负责这个 Gateway 的启动、停止、重启和开机自启？

对于长期运行的 VPS，如果已经有明确的 /etc/systemd/system/openclaw-gateway.service，保留 system service 作为唯一 manager 通常更清晰。

但这不是要求所有人都改成 system service。桌面/单用户机器继续使用 user service 也完全合理。关键是同一 profile / port 只保留一个 manager。

5. 本次 VPS 的处理：保留 system service，移走残留 user service

这台 VPS 最终选择 system-level service 作为唯一 Gateway manager。

先停止并禁用 user service：

systemctl --user disable --now openclaw-gateway.service

如果存在 user unit 文件，不直接删除，先备份：

mv ~/.config/systemd/user/openclaw-gateway.service \
  ~/.config/systemd/user/openclaw-gateway.service.bak

然后刷新 user systemd：

systemctl --user daemon-reload

确认用户级 unit 已不存在：

systemctl --user status openclaw-gateway.service --no-pager

如果返回：

Unit openclaw-gateway.service could not be found.

说明 user manager 已经清理干净。

接着确保 system service 开机自启：

sudo systemctl enable openclaw-gateway.service
sudo systemctl daemon-reload

这里有一个容易忽略的状态：

Loaded: loaded (...; disabled)
Active: active (running)

它代表现在正在运行，但 unit 没有启用开机自启。对于长期 VPS，这不算完整收尾。

完成后确认：

sudo systemctl is-enabled openclaw-gateway.service

预期：

enabled

再重启真正的 system service：

sudo systemctl restart openclaw-gateway.service

6. 不要在这种现场继续跑 openclaw gateway install

如果错误已经明确告诉你：

System systemd unit openclaw-gateway.service already owns this gateway unit name.

这时不要把下面这些当“万能修复”：

openclaw gateway install
systemctl --user start openclaw-gateway.service

前者可能尝试建立/修复 CLI-managed user service；后者则直接要求 user manager 启动同名服务。

如果你已经决定 system service 是唯一生命周期管理者，正确方向是：

sudo systemctl restart openclaw-gateway.service

而不是再创建第二个 manager。

官方 runbook 还特别说明：system unit 负责生命周期时，不要让 openclaw doctor --fix 再为同一 profile/port 自动安装 user-level Gateway；可以使用：

OPENCLAW_SERVICE_REPAIR_POLICY=external openclaw doctor

把 service lifecycle 明确留给外部/system 管理。

7. 为什么 gateway status --deep 比普通 status 更重要

处理完 systemd 后，不要只看“端口有没有监听”。

推荐：

openclaw gateway status --deep --require-rpc

这里两个参数的意义不同：

• --deep：同时扫描 system-level service。
• --require-rpc：不仅要求 WebSocket 能连，还要求只读 RPC probe 成功；失败时返回非零。

理想结果至少包括：

CLI version: 2026.8.2
Gateway version: 2026.8.2
Runtime: running
Read probe: ok
Listening: 127.0.0.1:18789

如果 service 标签看起来仍有点奇怪怎么办

本次现场曾出现一个容易误导人的情况：Gateway probe 已经命中 system service 的实际 PID，RPC 也成功，但 CLI 的某个 service 标签仍显示为 user service。

遇到这种情况，不要只盯一行字符串做结论。交叉确认三件事：

sudo systemctl status openclaw-gateway.service --no-pager -l
openclaw gateway status --deep --require-rpc
ss -lntp | grep 18789

看 PID、运行状态和 RPC 是否指向同一个实际 Gateway。

8. systemd 修好后，openclaw status 又报 multi-agent owner 错误

Gateway 恢复后，这台机器的第二个问题是：

Multiple agents are configured, but this operation has no explicit owner.

这不是 Gateway 又挂了。

原因是这台实例配置了多个 Agent，但一些 ambient system work 没有明确 agentId。2026.8.2 当前提供的配置入口是：

agents.defaults.systemAgent.agentId

它用于给系统级、未显式指定 Agent 的路径提供 fallback owner，例如部分 model/auth、skill/status、doctor/memory、channel bootstrap 和 unscoped main-session routing。

先看 Agent：

openclaw agents list --bindings

选择真正承担“默认系统 owner”的 Agent。这里用 main 作为示例：

openclaw config set agents.defaults.systemAgent.agentId main --dry-run

然后正式写入：

openclaw config set agents.defaults.systemAgent.agentId main

再运行：

openclaw config validate

一个小细节：config set --dry-run 不是完整 resolvability check

2026.8.2 的 value-mode dry-run 会提示：它不会替你完整检查 schema/resolvability。

所以正确理解是：

dry-run 用来预览写入，openclaw config validate 才是后续正式校验。

不要因为看到 Dry run successful 就跳过 validate。

9. openclaw status --agent main 不能用来解决这个错误

这次现场还验证了一个很容易写错的命令：

openclaw status --agent main

在 2026.8.2 中会报：

--agent is only valid with --usage

官方当前 CLI reference 也是这个语义：status --agent <id> 用于选择 --usage 的 provider auth/profile scope，不是给普通 openclaw status 指定 owner 的通用开关。

所以 multi-agent ambient owner 的修复方向是：

agents.defaults.systemAgent.agentId

而不是给每条 status 命令临时加 --agent。

10. 多飞书账号环境：给默认账号建立明确 binding

这台实例还有多个飞书账号，每个账号对应不同 Agent。

升级后检查：

openclaw agents list --bindings

发现默认 Agent 没有 routing rule，而其他 Agent 都有明确的 Feishu <account> 绑定。

这类环境更适合把默认账号也显式绑定：

openclaw agents bind --agent <agent-id> --bind feishu:<account-id>

例如：

openclaw agents bind --agent main --bind feishu:main

再确认：

openclaw agents list --bindings

预期能看到类似：

Routing: Feishu main
- feishu accountId=main

显式 binding 的价值是：入站 channel/account 到 Agent 的归属不再依赖隐式 fallback。

11. 但 binding 存在，不等于渠道真的在线

这是这次另一个很实用的经验。

agents list --bindings 只能告诉你“这条入站流量应该路由给谁”。

真正的运行状态要看：

openclaw channels status --probe

官方当前把 --probe 定义为 live path。Gateway 可达时，它会对每个账号运行实时 probe/audit，因此输出可能是：

enabled, configured, running, connected, works

也可能是：

disabled, not configured, stopped

所以：

• binding = routing 配置
• channel status –probe = 实际运行健康

两者不要混为一谈。

如果某个飞书账号本来就应该在线，但 probe 显示 stopped，再单独检查：

openclaw channels list --json
openclaw channels status --channel feishu --probe --json
openclaw channels logs --channel feishu

不要为了修一个账号，把所有已工作的账号重新 login 一遍。

12. GEMINI_API_KEY 缺失：是 degraded feature，不是升级失败

升级和 status 过程中，这台机器一直有类似警告：

memory.search.remote.apiKey:
Missing env var "GEMINI_API_KEY"
feature using this value will be unavailable

最终 openclaw status 也会把对应 memory provider 标成 degraded。

这类信息要分级处理。

如果 Gateway、模型和渠道都正常，而缺失变量只影响 memory.search.remote.apiKey，它表示的是：

配置里引用了 Gemini remote memory search，但当前命令/Gateway 环境没有这个变量。

它可能让 Memory Search 不可用，但不是这次 systemd restart failure 的根因。

正确做法是把它列入后续配置债务，单独修 SecretRef / service environment；不要在主故障还没定位时被 warning 带跑偏。

13. Skill precedence collision 也不一定是致命错误

Gateway 重启后，日志里还出现过多条：

Skill precedence collision
winner=...
loser=...

这表示同名 Skill 在多个来源出现，OpenClaw 已按 precedence 选出了 winner。

需要长期整理，但只要：

• Gateway 正常运行
• Plugin compatibility 没有阻塞项
• 目标 Skill/runtime 行为正确

就不应该把 collision warning 和“升级失败”自动画等号。

排障时先区分：

• blocker / fatal
• degraded capability
• warning / precedence

否则很容易一次升级顺手改五六个子系统，最后失去因果关系。

14. 本次最终验证顺序

这次恢复完成后，用的是下面这组检查：

openclaw config validate
sudo systemctl status openclaw-gateway.service --no-pager -l
openclaw gateway status --deep --require-rpc
openclaw status
openclaw agents list --bindings
openclaw channels status --probe

判断升级真正收敛，不是只看一条 openclaw --version，而是同时确认：

• Core version 是目标 stable。
• Gateway version 与 CLI version 一致。
• 唯一 systemd manager 正常运行。
• system service 已 enabled，VPS 重启后能自动回来。
• Read probe: ok。
• multi-agent systemAgent 已明确。
• 关键 channel/account 有显式 binding。
• channels status --probe 对关键账号返回 works。
• warnings 与 blockers 已分开处理。

15. 以后这种 VPS 怎么升级：不要让 updater 管它不拥有的 service

如果你已经明确采用 system-level unit：

/etc/systemd/system/openclaw-gateway.service

以后更稳的流程是先预览：

openclaw update --channel stable --dry-run

然后更新 Core，但不让 updater 尝试重启 Gateway：

openclaw update --channel stable --no-restart

官方当前说明：--no-restart 会完成 package replacement，但正在运行的 Gateway 会继续使用旧代码，直到你手动重启。

所以随后由真正的 deployment owner 执行：

sudo systemctl restart openclaw-gateway.service

再验证：

openclaw gateway status --deep --require-rpc
openclaw status
openclaw channels status --probe

这套流程的核心是：

Core 更新归 OpenClaw updater，system service 生命周期归 systemd/root owner。不要让两个工具互相抢 ownership。

16. 如果 core 已更新但 plugin finalization 没完成怎么办

这次没有最终走到这一步，但 2026.8.2 已经提供明确恢复入口：

openclaw update repair

适合：

• core package 已经更新
• tracked plugin sync 没收敛
• managed npm plugin metadata 有问题
• configured plugin payload 缺失
• plugin registry / doctor finalization 失败

但要记住两个边界：

1. update repair 不会重新安装 Core。
2. update repair 不会重启 Gateway。

如果你的 Gateway 本来就是 system-owned，repair 后仍然由你自己：

sudo systemctl restart openclaw-gateway.service

详细恢复逻辑见故障排查中心。

17. 这次升级真正改变的排障思路

过去很多 OpenClaw 教程一遇到问题就建议：

重装 → 重启 → 再重装

对单机玩具环境可能凑巧有效，但一旦你已经有：

• 多 Agent
• 多渠道账号
• systemd 常驻
• 插件
• cron / retained sessions
• SecretRef / 外部环境变量

这种做法会让现场越来越难判断。

这次更有效的顺序是：

版本 → 安装根 → service ownership → RPC → multi-agent owner → routing binding → channel live probe → 非阻塞 warning。

每一步只解决一个层级的问题。

最后得到的不是“它又能跑了”，而是能明确解释：

• 为什么 updater 拒绝 restart
• 哪个 systemd unit 才是真正 manager
• 为什么 status 需要 systemAgent
• 为什么有 binding 的飞书账号仍可能 stopped
• 哪些 warning 可以稍后处理

这才是适合长期跑 OpenClaw 的升级方式。

一份可直接保存的 VPS 升级模板

如果你的前提是：Ubuntu/Linux VPS + npm package + system-level Gateway + 多 Agent，可以把下面这份当作起点，但执行前仍要核对自己的 unit name 和 profile：

# 1. 先看版本和计划
openclaw --version
openclaw update --channel stable --dry-run

# 2. Core 更新，不抢 system service ownership
openclaw update --channel stable --no-restart

# 3. 由系统服务 owner 重启
sudo systemctl daemon-reload
sudo systemctl restart openclaw-gateway.service

# 4. 验证配置和 RPC
openclaw config validate
openclaw gateway status --deep --require-rpc

# 5. 多 Agent / 渠道验证
openclaw status
openclaw agents list --bindings
openclaw channels status --probe

如果第 2 步已经把 Core 更新成功，但后处理失败，再考虑：

openclaw update repair

不要连续覆盖安装，也不要为了绕过 ownership 保护再创建一套同名 user service。

核验边界

本文涉及的 update --no-restart、system-level Gateway、gateway status --deep --require-rpc、agents.defaults.systemAgent.agentId、agents bind、channels status --probe 与 status --agent 语义，均按 OpenClaw 2026.8.2 / 2026-09-02 官方文档重新核验。

现场中的具体错误顺序和恢复结果来自一台实际 Ubuntu VPS 的匿名化升级记录；主机名、IP、账号和 Agent 昵称均未保留。

后续版本如果调整 service ownership 或 multi-agent CLI 行为，请优先以官方文档和版本中心的最新核验为准。