一文讲清楚 OpenClaw 是什么，以及 Windows 下的部署

OpenClaw 到底是什么1. 它在系统里干的事接入层 运行时管理很多人第一次看到 OpenClaw会把它当成“一个聊天 UI”。更工程化的视角是它负责把外部请求接进来并把后面的执行系统跑起来、管起来。接入层把外部入口Web、App、IM、Webhook、业务系统统一接到 AI 能力上运行时管理配置、鉴权、路由、调试、观测下面这张图把“它在系统里做什么”以及它和模型/Agent/Workflow/Skills 的关系放到同一张图里每条连线都写清楚“是什么关系”如果你做过“把一个脚本产品化”的事这里会很熟你需要一个稳定入口鉴权、限流、端口、路由你需要一个控制台配置、日志、调试、验证你需要把能力拆成可组合的模块技能、工具、流程OpenClaw 的 Gateway/Dashboard对应的就是“入口 控制台”。这几个概念经常被混着用我用“谁负责什么”来拆概念负责什么你应该关心什么模型推理与生成能力上限、成本、延迟、上下文窗口工具链把动作执行出来权限、网络、依赖、失败重试、观测SkillAI Skill把工具包装成可复用动作输入输出是否清晰、失败是否可解释Agent在多步任务里做决策何时调用哪个 skill、何时停、怎么纠错Workflow把不确定变成确定流程步骤顺序、分支条件、回滚/重试OpenClaw把上述能力“跑起来并接出去”入口鉴权、配置管理、调试体验2. 一个具体的任务流以“IM 里的发布助手”为例同事在群里丢一句“发布失败了帮我看看”系统要做的通常是抓日志、定位原因、给出修复动作必要时还能帮你生成修复 PR。宏观位置关系可以对照上面的“外部入口 → OpenClaw → 执行系统”那张图这里我们把它落到一个具体链路上。把这件事映射到组件上大概是这样的外部入口IM/Webhook把消息推给 GatewayGateway 做鉴权token并把请求路由到对应的 Agent/WorkflowAgent 决策先调用fetch_logs再调用analyze_error必要时再调用propose_fixSkills 通过工具链去执行HTTP 拉日志、Shell 跑命令、读写文件、查数据库Workflow 把“多步排障”固化成稳定流程分支、重试、回滚Dashboard 用来调试整个链路配置、观察、复现、验证你会发现OpenClaw 更像把“能做事的 AI”装进一个可管理的运行时里而不是只提供一个聊天窗口。3) 为什么这类项目在变热从 Chat 走向 Action我看到的趋势大概有三条偏工程侧Agent 从“会聊”变成“要执行”一旦要执行就需要工具链、权限边界、失败处理、可观测性Workflow 变成刚需团队希望“可复现”而不是每次让模型自由发挥多模型、多入口常态化同一套能力要接 Web、App、IM同一业务要支持多个 provider所以“接入层 运行时管理”的价值会越来越明显它能把一堆碎片能力收敛成一个可以运营、可以上线的系统。4) 什么时候你会需要 OpenClaw给几个更工程化的场景你要把内部知识库问答做成一个可控服务有 token、有入口、有调试台你要把一组 skills 做成“可复用能力库”给不同业务线/渠道调用你要把 Agent 做成长期运行的服务不仅要能跑还要能看日志、能回放、能定位失败部署先说结论生产/长期运行优先 Linux 或云服务器环境更干净、依赖更好处理本地开发/体验Win11 也能跑但坑更多主要集中在 token、shim、.env加载顺序1) Linux 更省心云服务器也常有“一键部署”Linux 环境做这类部署通常更顺脚本和依赖生态对 Linux 更友好进程管理、端口占用、权限边界更清晰很多国内云服务器的“应用市场/镜像/一键脚本”对这类 AI 项目也很友好选模板、填参数、几分钟就能拉起来。如果你的目标是“跑一个稳定服务”建议优先走 Linux/云上。最小准备清单一般就这几项端口与鉴权Gateway 端口、token模型配置*_API_KEY、默认模型/provider观测日志路径/输出、必要时接入 metrics/tracing进程托管Docker/systemd/进程守护2) 我在 Win11 的部署官方安装脚本 wrap 启动Win11 真正难的不是安装而是几件事叠加token少了 token 就 401shimnpm 可能生成同名 shim你以为跑的是仓库脚本实际跑了转发脚本.env很多 CLI 不会自动加载.env你写了 Key 但进程环境里没有openclaw脚本不要直接启动否则不能正确读取你自己的配置文件下面按步骤走尽量一次跑通。Step 0环境准备Windows 11PowerShell 5.1推荐 7Node.js建议 LTS版本以官方要求为准Step 1运行官方安装脚本powershell -ExecutionPolicy Bypass -File scripts/windows/install-openclaw.ps1安装完成后通常会生成环境文件路径可能类似%USERPROFILE%\.openclaw-main\.envStep 2只改.env填 provider Key 确认 token在.env里填你的模型 Key例如DEEPSEEK_API_KEY... OPENAI_API_KEY... GEMINI_API_KEY...并确认存在OPENCLAW_GATEWAY_TOKEN...建议先别动openclaw.json。很多“看起来配置都对但就是不工作”根因就是两个地方都写了配置读取顺序不一致。Step 3用 wrap 脚本启动确保.env真被加载先确认自己跑到的不是 shim可选但很省时间Get-Command openclaw | Format-List Source然后用 wrap 脚本启动注意C:\openclaw按你的安装目录调整cd C:\openclaw\scripts\windows # 先检查环境变量是否真的加载进进程 .\openclaw-wrap.ps1 -DebugEnv # 验证 provider 可用以 deepseek 为例 .\openclaw-wrap.ps1 models list --all --provider deepseek --plain .\openclaw-wrap.ps1 models set deepseek/deepseek-chat # 启动 Gatewaytoken 鉴权 .\openclaw-wrap.ps1 gateway --port 18789 --auth token # 启动 Dashboard输出带 token 的访问地址 .\openclaw-wrap.ps1 dashboard --no-open打开 Dashboard 时只用命令输出的那条 URL里面会包含?token...。注意URL 里的 token 等同于“钥匙”别发到群里、别写进公开仓库。3) 常见报错速查报错/现象常见原因最快解决unauthorized: token_missing打开了不带 token 的 URL用dashboard --no-open输出的 URLGateway auth is set to token, but no token is configured.env里没有OPENCLAW_GATEWAY_TOKEN或没加载检查.env用 wrap 启动并先跑-DebugEnvlsof not found/ 类 Unix 工具报错用了 Unix 方式清理端口Windows 用 wrap 脚本已兼容-DebugEnvunknown option运行到了 shim用C:\openclaw\scripts\windows\openclaw-wrap.ps1