【AI测评】Windows部署OpenClaw实战｜让大模型开始操作本地电脑——模型接入、权限控制与安全远程访问全流程

  #OpenClaw    #AI Agent    #人工智能    #Windows    #大模型 

  #智能体    #本地部署    #PowerShell    #Node.js    #自动化 

摘要 如果大模型只能回答问题，它仍停留在“聊天框”里；当它能够在受控权限下调用 Windows 的文件系统、命令行和桌面能力，AI 才真正迈向可执行的 Agent。本文基于 2026 年 8 月 OpenClaw 官方文档，完整梳理 Windows 原生部署、模型接入、Gateway 与 Windows Hub 节点配对、命令审批、两组低风险验证场景、常见故障排查及 Tailscale 安全远程访问。重点不是把权限全部交给 AI，而是建立“模型理解—网关调度—权限审批—本机执行—结果回传”的可验证闭环，让你知道它能做什么、为什么能做，以及怎样把风险控制在可接受范围内。

先看结论：真正的分水岭，不是模型会不会回答，而是有没有“执行通道”

普通聊天 AI 可以告诉你“如何查文件、如何启动服务、如何修改配置”；OpenClaw 更值得体验的部分，是把模型放进一个带 Gateway、工具策略和节点权限的执行链路里：模型先理解目标，再提出工具调用，由网关与本机节点完成被授权的动作，结果回传后再继续判断。

这意味着它不应该被理解成“AI 直接接管电脑”。更准确的说法是：OpenClaw 给大模型增加了受策略约束的手脚。你允许它看什么、执行什么、是否每次询问、是否可以远程访问，决定了它究竟是一名安全的自动化助手，还是一个风险过大的高权限入口。

截至 2026-08-28 的版本要点 官方安装文档目前支持 Node.js 22.22.3+、24.15+、25.9+，并把 Node 26 作为推荐默认运行时；Windows 可选原生 Windows Hub、PowerShell CLI 或 WSL2 Gateway。Windows Hub 可以作为节点向 Gateway 声明 system.run、screen.snapshot 等能力，敏感操作仍受节点策略、设备配对和执行审批约束。

本文最终要跑通的链路	验证标准
OpenClaw 安装	openclaw --version 可执行，doctor 无阻断问题
模型接入	能够完成最小问答或 infer 验证
Gateway	状态为 running，Connectivity probe 正常
Windows 节点	nodes status 能看到已配对节点
本机执行	在指定测试目录内完成可核验的文件/命令任务
远程访问	Gateway 仍保持 loopback，通过受控隧道访问

目录

1. OpenClaw 到底是什么：从 Chat 到 Agent 的关键变化
2. Windows 部署前准备：先选路线，再谈安装
3. PowerShell 原生安装：最短路径跑通 OpenClaw
4. 模型接入：官方提供商与 OpenAI 兼容接口
5. 让 AI 真正操作 Windows：Windows Hub、节点配对与执行审批
6. 两组低风险实测：文件清单与本地网页任务
7. 远程访问：为什么推荐 loopback + Tailscale Serve
8. 常见故障排查：从“命令找不到”到“Agent 调用失败”
9. 安全清单：高权限 Agent 必须守住的边界
10. 与普通 Chat、RPA、AI Coding CLI 的差异
11. 适合谁、不适合谁
12. 总结与官方参考资料

图 1　OpenClaw 的核心不是“聊天页面”，而是模型、Gateway、策略与 Windows 节点构成的执行链路

1. OpenClaw 到底是什么：从 Chat 到 Agent 的关键变化

很多本地 AI 项目解决的是“把模型跑起来、给它一个聊天界面”。OpenClaw 关注的是再往前一步：当模型已经理解你的意图之后，能否在明确授权的环境里继续调用工具，把回答变成动作。

从官方架构看，Gateway 是控制面：负责会话、模型路由、工具调用和设备连接；Windows Hub 或 headless node 是执行面：负责在这台 Windows 机器上提供 system.run、system.which 等声明过的能力。模型本身仍然通过 Gateway 工作，并不是直接绕过策略去访问操作系统。

能力	普通网页 Chat	OpenClaw 执行链路
回答问题	强	强
读取本机环境	通常不能	可在授权范围内通过节点/工具完成
运行命令	通常不能	可通过 system.run / exec，但受策略约束
多步任务	以建议为主	可执行“计划—调用—观察—修正”循环
远程入口	通常由云服务提供	可自托管，但必须自己负责认证与网络边界
风险模型	主要是内容风险	还包括主机权限、密钥、网络暴露和误执行

1.1 为什么 Windows 场景尤其值得关注

Windows 是多数办公与个人电脑的主环境：文件、浏览器、Office、桌面程序、PowerShell、开发工具都在同一台机器上。一旦 Agent 能够通过受控节点调用这些能力，它的价值会从“告诉你怎么做”变成“在你批准后替你做”。但这也意味着 Windows 上的 OpenClaw 部署不能只看“能不能启动”，还必须同时看三件事：执行面是否可控、权限是否可审计、远程入口是否被正确隔离。

1.2 2026 年 8 月一个很重要的变化：不要照着旧教程先折腾一堆依赖

较早的教程经常要求先手工安装 Node.js、Git，再处理 PATH 和镜像源。当前官方 Windows 安装器已经会检查并处理运行时：如果缺少受支持的 Node.js，会优先尝试 winget、Chocolatey、Scoop，必要时使用便携式 Node；Git 缺失时也能为安装流程引导或准备可用 Git。

因此更稳的思路 先运行官方安装器，让它负责“能自动处理的依赖”；只有遇到明确报错时，再针对 Node、Git、PATH 单独排查。这样能减少把旧版本教程中的环境假设带入新版本。

2. Windows 部署前准备：先选路线，再谈安装

路线	优点	适合人群	注意点
Windows Hub	图形化、托盘状态、Chat、节点模式、原生 Windows 能力	第一次体验、需要本机能力的用户	需要完成 Gateway 配对与权限设置
PowerShell CLI	过程透明、可复现、适合写教程和自动化	开发者、运维、希望看清每一步的人	需要能够运行 PowerShell 5+
WSL2 Gateway	Linux 生态完整，适合脚本与服务端工作流	偏 Linux 的开发者、长期运行 Gateway	要操作 Windows 原生桌面能力时，仍建议配合 Windows Hub 节点

2.1 本文选择：PowerShell 安装 + Windows Hub 节点

这条路线兼顾两件事：一方面，PowerShell 安装可以清楚看到 OpenClaw、Gateway 和配置文件发生了什么；另一方面，Windows Hub 节点更适合承接 Windows 原生能力。也就是说，Gateway 负责“想与调度”，Windows 节点负责“在本机执行”，两者通过配对和策略连接起来。

2.2 环境最低检查

项目	建议
系统	Windows 10/11，64 位；保持系统和安全补丁正常更新
PowerShell	5+；可通过 $PSVersionTable.PSVersion 查看
Node.js	安装器会处理；当前推荐 Node 26，亦支持官方文档列出的 22/24/25 对应最低版本
Git	安装器可处理缺失场景；仅从源码构建时更依赖完整 Git
模型	可用官方云端提供商，也可接 OpenAI 兼容 API；本地模型不是必需条件
GPU	使用远程 API 时不需要；只有本地运行模型才与显卡/显存直接相关
权限	建议使用普通用户账户；第一次实验不要直接给主目录、系统盘和高风险设备能力

不要为了“顺利安装”关闭 Windows Defender OpenClaw 是高权限自动化工具，首次部署更应该保留系统安全防护，而不是关闭它。如果安全软件拦截了某个具体文件或命令，应该先核对来源、签名、安装脚本和实际路径，再做最小范围处理。

图 2　从安装到远程访问，建议按“先本地可用、再节点执行、最后远程”的顺序逐层验证

3. PowerShell 原生安装：最短路径跑通 OpenClaw

3.1 先确认 PowerShell，不必先改执行策略

PowerShell $PSVersionTable.PSVersion Get-ExecutionPolicy -List

官方安装命令可以直接在当前 PowerShell 会话执行。不要一上来就把整个用户环境长期改成更宽松的执行策略；如果公司组策略或安全软件确实阻止了远程脚本，先确认组织策略和脚本来源，再决定是否需要调整。

3.2 运行官方 Windows 安装器

PowerShell iwr -useb https://openclaw.ai/install.ps1 | iex

当前安装器会检测 Windows 环境、检查受支持的 Node.js、安装 OpenClaw，并在正常交互流程中启动 onboarding。对于大多数用户，这比“手动装 Node → 手动装 Git → 手动 npm -g → 再修 PATH”更短，也更符合当前官方路径。

3.3 如果想把安装与初始化拆开

PowerShell & ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard openclaw onboard --install-daemon

拆开执行适合需要先检查安装结果、再单独做模型与 Gateway 配置的场景。onboarding 会引导你选择模型提供商、配置认证，并建立 Gateway。

3.4 第一轮验证：不要急着让 AI 操作电脑

PowerShell openclaw --version openclaw status openclaw gateway status openclaw doctor openclaw dashboard

理想状态是：openclaw 命令可找到；Gateway 显示正在运行并通过连接探针；doctor 没有阻断性的配置或服务错误；dashboard 能在浏览器打开。只有这四件事稳定后，才值得继续配置本机执行。

3.5 如果 PowerShell 提示“openclaw 不是内部或外部命令”

PowerShell npm config get prefix Get-Command openclaw -ErrorAction SilentlyContinue $env:PATH -split ';' | Select-String -Pattern 'npm|OpenClaw'

Windows 上最常见的原因不是“OpenClaw 没装成功”，而是新终端尚未加载更新后的用户 PATH，或者 npm 全局前缀目录没有进入 PATH。先关闭并重新打开 PowerShell；仍不生效，再检查 npm config get prefix 返回的目录是否在用户 PATH 中。

4. 模型接入：官方提供商与 OpenAI 兼容接口

OpenClaw 负责 Agent 编排，不等于它自带一个大模型。你需要选择模型提供商。最省事的是在 onboarding 中直接选择官方支持的提供商；如果你已有企业网关、LiteLLM、vLLM、LM Studio 或其他 OpenAI 兼容服务，也可以通过 models.providers 接入。

4.1 先理解“模型能聊天”与“模型适合 Agent”不是一回事

检查项	为什么重要
工具调用能力	Agent 需要稳定生成工具调用，而不只是纯文本回复
上下文窗口	OpenClaw 会携带工具 Schema、工作区上下文和历史，过小的上下文可能“curl 能通、Agent 却失败”
输入模态	如果要让模型理解截图，模型条目需要声明 image 能力且后端真实支持视觉输入
接口兼容性	多数 OpenAI 兼容后端应使用 openai-completions；只有真实支持 /v1/responses 时才选 openai-responses
超时	本地或远程慢模型要合理设置 provider timeout 与 Agent 总超时

4.2 自定义 OpenAI 兼容接口示例

先把 API Key 放到当前 PowerShell 会话的环境变量中，避免把密钥直接写进文章、截图或命令历史。

PowerShell $env:CUSTOM_API_KEY = "sk-替换成你自己的密钥" openclaw config file

然后在 OpenClaw 配置中加入类似下面的 JSON5。请把 baseUrl、模型 ID、contextWindow、maxTokens 改成你的真实后端能力，不要照抄示例数值。

JSON5 {   models: {     mode: "merge",     providers: {       "custom-proxy": {         baseUrl: "https://your-endpoint.example/v1",         apiKey: "${CUSTOM_API_KEY}",         api: "openai-completions",         models: [           {             id: "your-model-id",             name: "Your Model",             input: ["text"],             contextWindow: 131072,             maxTokens: 8192           }         ]       }     }   },   agents: {     defaults: {       model: { primary: "custom-proxy/your-model-id" }     }   } }

4.3 三步验证模型链路

PowerShell openclaw models list openclaw models status openclaw infer model run --local --model custom-proxy/your-model-id --prompt "只回复：OpenClaw 模型链路正常" --json

如果直接调用 /v1/chat/completions 能成功，但 OpenClaw Agent 仍失败，优先检查模型 ID、/v1 路径、上下文窗口、消息格式和工具调用兼容性，而不是反复重装 OpenClaw。Agent 请求比一个最小 curl 请求更大、更复杂。

5. 让 AI 真正操作 Windows：Windows Hub、节点配对与执行审批

到这里，你只是完成了“OpenClaw 能和模型说话”。下一步才是标题里的重点：让模型在受控条件下调用本机能力。官方 Windows Hub 可以注册为 OpenClaw Node，节点向 Gateway 声明自己支持的能力；Gateway 只会转发节点声明且策略允许的命令。

5.1 Windows 节点能提供哪些典型能力

能力族	代表命令	权限含义
System	system.run、system.which	在本机运行命令或查找可执行文件，是最核心也最需要限制的能力
Screen	screen.snapshot	允许 Agent 获取屏幕信息；屏幕录制需要更明确的授权
Camera	camera.list / camera.snap	涉及隐私，默认应保持关闭，只有明确场景再开启
Device	device.info / device.status	获取设备状态与基础信息
Talk	talk.speak 等	语音输出/对讲类能力，按需启用

5.2 启用 Windows Hub 的 Node 模式并完成配对

在 Windows Hub 中启用节点模式后，Gateway 会看到新的配对请求。首次连接不要直接批准一个你看不懂的设备 ID，先核对设备名、来源与当前操作，再在 Gateway 主机执行：

PowerShell openclaw devices list openclaw devices approve <requestId> openclaw nodes status

配对解决的是“这台设备是不是我允许加入的节点”；它并不等于“这台设备上的所有命令以后都可以无条件执行”。真正的命令边界还要靠 Exec Approvals 与工具策略。

5.3 把执行默认指向节点，并使用 Ask / Allowlist

PowerShell openclaw config set tools.exec.host node openclaw config set tools.exec.node "<node-id-or-name>" openclaw config set tools.exec.mode ask

推荐从 ask 开始：白名单命令可以直接执行，不匹配的命令需要人工确认。熟悉自己的工作流后，再逐步把稳定、低风险、可复现的命令加入 allowlist。不要为了“更爽”直接把长期策略改成 full + ask off。

一个非常实用的授权原则 把“允许 AI 做什么”拆成三层：目录范围（只碰测试目录）→ 命令范围（只允许明确工具）→ 操作类型（删除、覆盖、联网、安装软件始终需要确认）。这比单纯设置“允许/禁止”更接近真实工程环境。

6. 两组低风险实测：文件清单与本地网页任务

第一次测试不要拿工作文档、浏览器密码目录或真实项目做实验。下面先创建一个完全可丢弃的实验目录，再让 OpenClaw 在这个“小沙盒”里证明它确实具备“理解—执行—验证”的闭环。

6.1 准备一个可控实验目录

PowerShell $root = "$env:USERPROFILE\OpenClawLab" New-Item -ItemType Directory -Force "$root\docs","$root\web" | Out-Null "OpenClaw demo file A" | Set-Content "$root\docs\alpha.txt" -Encoding UTF8 "OpenClaw demo file B" | Set-Content "$root\docs\beta.txt" -Encoding UTF8 Get-ChildItem "$root\docs"

6.2 场景一：让 Agent 生成文件完整性清单

建议直接发给 OpenClaw 的任务 请只在 %USERPROFILE%\OpenClawLab\docs 范围内工作。列出目录中所有文件的文件名、字节大小和 SHA256，并生成 manifest.csv。不要访问其他目录，不要联网，不要删除或移动现有文件；执行命令前先给出计划，遇到需要审批的命令等待我确认。

这个任务非常适合验证 Agent 是否真的在操作本机，因为结果可以客观核对：manifest.csv 是否存在，里面的文件名是否与目录一致，SHA256 是否能用 Get-FileHash 再算一次得到相同结果。

验证项	通过标准
目录边界	没有读取 OpenClawLab\docs 之外的文件
结果文件	manifest.csv 只生成在测试目录
哈希	与手工 Get-FileHash 结果一致
审批	未授权的命令没有被静默执行
可重复性	删除 manifest.csv 后再次执行仍得到同样结构

6.3 场景二：一句话生成静态网页并在本机启动

建议任务 请只在 %USERPROFILE%\OpenClawLab\web 中创建一个单文件 index.html，做一个简洁的“OpenClaw Windows 实验室”页面，包含标题、三张能力卡片和当前日期。完成后使用本机 Node.js 工具把该目录以 127.0.0.1:8080 提供服务；不要监听 0.0.0.0，不要做公网穿透，不要安装系统级软件，遇到新依赖先询问。

这个任务验证的不是“网页写得有多漂亮”，而是多步骤执行能力：创建文件 → 选择可用命令 → 启动本地服务 → 返回访问地址 → 根据页面反馈继续修改。

如果 Agent 需要一个简单的 Node 静态服务工具，可以使用 npx 临时运行 http-server；为了保持本地边界，监听地址明确写成 127.0.0.1。

PowerShell npx --yes http-server "$env:USERPROFILE\OpenClawLab\web" -p 8080 -a 127.0.0.1

检查点	如何确认
文件	OpenClawLab\web\index.html 存在
端口	浏览器打开 http://127.0.0.1:8080
监听范围	服务绑定 127.0.0.1，而不是 0.0.0.0
修改闭环	要求 Agent 改一处文案，刷新后能看到变化
退出	结束服务后 8080 不再监听

7. 远程访问：为什么推荐 loopback + Tailscale Serve

图 3　高权限 Agent 的远程访问应把 Gateway 留在回环地址，通过受控隧道提供访问

OpenClaw 的 Gateway 默认围绕本机回环地址设计，常见端口是 18789。官方远程访问建议同样强调：只要没有明确理由，就让 Gateway 保持 loopback；远程访问通过 SSH 隧道或 Tailscale Serve 进入，而不是把控制面端口直接映射到公网。

7.1 Tailscale Serve 的核心价值

• Gateway 仍然绑定 127.0.0.1，减少直接暴露面。
• Tailscale 负责 HTTPS、路由和身份层，远程设备通过 Tailnet 访问。
• 远程客户端仍可能需要设备配对，节点执行仍受审批策略约束。
• 相比“公网随机域名 + 直接暴露控制面”，更适合长期使用。

7.2 配置思路

PowerShell openclaw config set gateway.bind loopback openclaw config set gateway.tailscale.mode serve openclaw gateway restart --safe

完成 Tailscale 登录与 Serve 配置后，通过你的 MagicDNS HTTPS 地址访问 Dashboard。第一次远程浏览器连接如果出现 pairing required，回到 Gateway 主机核对并批准请求。

7.3 如果你使用反向代理或其他远程入口

非回环 Control UI 部署要把浏览器 Origin 当成安全边界。需要设置 allowedOrigins 时，写完整、精确的 origin；不要用 ["*"] 省事。公网远程主机必须使用 TLS，Token/Password 也不应该出现在 URL、聊天记录或公开截图中。

本文刻意不把“公网暴露 OpenClaw 控制面”做成默认教程 OpenClaw 能运行本机命令，这种能力与普通博客、静态网页完全不是一个风险等级。远程访问的目标应该是“我本人安全地访问自己的 Gateway”，而不是“让任何能拿到链接的人都能碰到 Gateway”。

8. 常见故障排查：从“命令找不到”到“Agent 调用失败”

现象	优先检查	处理方向
openclaw 命令找不到	npm prefix、用户 PATH、新终端	重新打开终端；确认全局 bin 目录进入 PATH
Node 版本不支持	node --version	让官方安装器处理，或切换到受支持的 22/24/25/26 版本
Gateway 不运行	openclaw gateway status	openclaw doctor；必要时 gateway install --force + restart
Dashboard 打不开	Gateway 端口、auth、浏览器地址	先用本机 dashboard 命令确认 loopback 访问
模型 401/404	API Key、baseUrl、/v1、模型 ID	用提供商最小请求验证，再核对 OpenClaw provider 配置
curl 能通但 Agent 失败	上下文、工具 schema、消息格式	增大正确 contextWindow；检查兼容 API 类型和模型工具能力
pairing required	设备未批准	devices list → 核对 → approve
system.run denied	node 策略或 allowlist	查看审批策略；只放行需要的命令
远程 UI Origin 错误	allowedOrigins 不匹配	填写精确 origin，不使用通配符
升级后行为异常	旧服务/旧二进制仍在运行	status --all、doctor --fix、gateway restart，检查 PATH 指向新版

8.1 推荐的诊断顺序

PowerShell openclaw status openclaw gateway status openclaw logs --follow openclaw doctor openclaw models status

排错最怕“看到一个报错就重装”。按上面的顺序可以快速判断问题是在 CLI、Gateway、日志、配置，还是模型提供商。尤其是 Windows 上的 PATH 和后台 Scheduled Task，常常会出现“新 CLI 已安装，但旧服务仍在跑”的版本错配。

9. 安全清单：高权限 Agent 必须守住的边界

边界	推荐做法
主机	首次使用放在测试账户、备用电脑或虚拟机；不要直接拿生产主机练手
目录	先限定 OpenClawLab 等专用目录，再逐步扩大
命令	从 ask/allowlist 开始；删除、覆盖、安装、联网操作保持人工确认
设备能力	屏幕、摄像头、位置等隐私能力按需开启，不做“全选”
密钥	API Key 用环境变量/SecretRef；不要粘贴进 Prompt、截图或公开仓库
Gateway	保持 loopback；非必要不直接监听 LAN/公网
远程	优先 Tailscale Serve 或 SSH；公网必须 TLS + 强认证 + 精确 Origin
Token	定期轮换；怀疑泄露立即换新并重启 Gateway
系统安全	不要关闭 Defender；不要运行来源不明的所谓“免环境一键包”
审计	保留日志；高风险任务先看计划、再批准、最后核对结果

9.1 为什么“给 AI 全权限”反而不是高级玩法

真正稳定的 Agent 系统不是把摩擦全部去掉，而是把“确定性高、风险低”的操作自动化，把“影响大、难回退”的操作留给人工确认。OpenClaw 的配对、Allowlist、Ask、Gateway auth、Origin 限制，本质上都是为了把执行能力放进一个可审计的信任边界。

10. 与普通 Chat、RPA、AI Coding CLI 的差异

工具形态	强项	弱项	最适合的任务
普通网页 Chat	知识问答、写作、分析	无法直接触达你的本机环境	方案设计、解释、内容生成
AI Coding CLI	代码仓库理解、终端开发流	通常聚焦代码与开发工具	改代码、测试、重构、工程任务
传统 RPA	流程确定、界面固定时稳定	对页面变化和语义理解较弱	固定表单、重复办公流程
OpenClaw	模型推理 + Gateway + 多节点/工具执行	权限与安全设计更复杂	需要自然语言规划并调用真实主机能力的自动化

11. 适合谁、不适合谁

11.1 适合

• 想系统学习 AI Agent，而不满足于只使用聊天窗口的开发者。
• 需要把模型与 Windows 文件、命令行、节点能力连接起来的自动化用户。
• 希望自己掌控 Gateway、模型供应商和远程入口，而不是完全依赖云端黑盒的人。
• 愿意花时间设计权限边界、测试目录和审批流程的技术用户。

11.2 不适合

• 只想找一个更好看的聊天界面；OpenClaw 对这种需求明显偏重。
• 不愿意管理 API Key、Gateway、节点配对和执行审批。
• 希望“一句话就给 AI 全盘权限”，又不准备做备份、审计和恢复方案。
• 需要严格多租户隔离的企业环境，但还没有做身份、网络、密钥和主机隔离设计。

12. 总结：Agent 的价值不在“像人”，而在“能验证地做完事情”

OpenClaw 在 Windows 上最值得体验的地方，不是把一个大模型聊天页面搬到本地，而是把“理解任务”与“执行任务”真正接起来：模型负责意图理解和规划，Gateway 负责会话、工具与策略，Windows 节点负责执行，审批与配对负责守住边界。

当你能在一个明确的测试目录里，让 Agent 生成文件清单、计算哈希、创建网页、启动本地服务，并且每一步都有可检查的输入、命令、输出和回退方式时，它才真正从“会说”变成“会做”。

同样重要的是，能力越强，安全就越不能靠“相信模型不会犯错”。保持 Gateway loopback、使用受控远程隧道、把 Exec 设为 Ask/Allowlist、按需开放节点能力、对密钥与 Token 做隔离，这些不是额外负担，而是让 Agent 从玩具走向长期可用工具的前提。

官方参考资料（访问日期：2026-08 ）

• OpenClaw 安装：https://docs.openclaw.ai/install
• Windows：https://docs.openclaw.ai/windows
• Getting Started：https://docs.openclaw.ai/quickstart
• Nodes：https://docs.openclaw.ai/nodes
• Exec Approvals：https://docs.openclaw.ai/tools/exec-approvals
• Gateway Security：https://docs.openclaw.ai/gateway/security
• Remote Access：https://docs.openclaw.ai/gateway/remote
• Tailscale：https://docs.openclaw.ai/gateway/tailscale
• Model Providers：https://docs.openclaw.ai/concepts/model-providers
• Gateway Troubleshooting：https://docs.openclaw.ai/gateway/troubleshooting