换个宇宙1. 热度曲线背后：OpenClaw 为什么会被推上神坛，又为什么迅速冷却
1.1 从 Clawdbot 到 OpenClaw：一个开源 Agent 的爆发起点
如果你不是从 2025 年 10 月底就开始关注开源 AI 圈，可能很难体会当时 OpenClaw 给人带来的冲击感。这个项目最开始叫 Clawdbot，后来因为商标问题改名 OpenClaw，一夜之间冲上 GitHub 趋势榜第一，Star 数短时间内涨到数万，各种群里都在讨论"要不要本地跑一个"。我身边原本对 AI Agent 不太感冒的同事，那几天也在问"这东西是不是真的能替我把活儿干了"。
OpenClaw 火起来的核心逻辑其实并不复杂。它把"Agent 能做的事"拉低到了大众可以理解的程度：给模型一个可操作的环境，让它自己规划步骤、调用工具、执行任务，整个过程在本地部署、数据不出门。再加上 Claude 的 computer use 能力带来的演示效果非常炸裂，很多人第一次看到 AI 真能自己打开浏览器、操作文件、写代码、跑测试，都会被震一下。更关键的是，OpenClaw 在 token 消耗上比 Claude Code 便宜太多，这让大量被 API 账单劝退的人重新燃起了希望。
但热度这东西来得快去得也快。大概两三个月之后，GitHub 的 issue 区开始堆积大量相似问题，社区讨论从"这个东西太牛了"迅速转变成"我的 Agent 又跑挂了"和"这个报错有谁能看看"。这种从兴奋到困惑的过程，其实在任何一个开源项目里都会经历，但在 OpenClaw 身上被压缩到了极短的时间窗口。
1.2 退潮的三个信号：报错、收费教程与沉默的群聊
很多人在 2026 年回头看 OpenClaw 的时候，会用"退潮"这个词来形容，但我觉得更准确的说法是"分层"——这波热度里真正沉淀下来的，和当时被热度裹挟进来的，已经是两拨完全不同的用户。
第一个信号是社区讨论内容的变化。早期 OpenClaw 的讨论基本围绕"能做什么"，比如能不能写小说、能不能自动写代码、能不能接入微信。到了后期，搜索记录里大量出现的是"OpenClaw 安装教程""openclaw control ui did not start""the agent run failed before producing a reply"这类问题。原因很简单：真正上手之后，普通用户发现它远远没有 ChatGPT 那么开箱即用，它需要配置模型、配置 API、写 skill、调 prompt，每一样对没接触过开源项目的人来说都是门槛。
第二个信号是商业嗅觉灵敏的人开始进场。搜索"openclaw一键部署工具"能找到不少付费服务，甚至有公司打出"终身会员特惠"这种极富中国互联网特色的推广方式。这说明什么？说明当开源项目的使用门槛高到普通用户搞不定的时候，就会有人靠"替用户搞定"来变现。这类服务未必不好，但它代表的是用户群体的真实状态——大部分人不是不想用，而是真的装不上、配不好。
第三个信号最微妙，就是各种群的沉默。刚开始那几周，AI 群里一天能刷几百条 OpenClaw 的讨论，有人分享自己写的 skill，有人晒 Agent 自动完成任务的截图。大概一个多月之后，这些群明显安静下来了。不是所有人都弃坑了，而是大多数人在跑通第一个 demo 之后，发现下一步不知道做什么，只好把项目晾在一边。真正还在持续用的人，已经开始进入"玩细节"的阶段了，而这种深度讨论的频率本来就低。
1.3 一次集体误判：把"演示级能力"当成了"生产级标准"
我复盘这段时间的讨论，觉得 OpenClaw 口碑分化的根源，在于人们对它的期待存在一个集体误判。OpenClaw 本质上是一个框架，不是一个产品。它的定位是"给你一个 Agent 的运行底座，能力上限取决于你怎么搭"，但很多人下意识地拿它去对标"开箱即用的商业化 AI 应用"。
用做饭来类比：商业化 AI 产品是外卖，打开就吃；OpenClaw 是一套顶级厨具加一个菜谱库，做得好不好吃，取决于你的手艺和耐心。外卖点多了的人拿到厨具，第一顿饭做糊了，大概率会把锅扔到一边骂一句"这什么破玩意儿"。但真正想学做饭的人，会从最简单的蛋炒饭开始练，一步一步把这道菜做明白。
我当时从 OpenClaw 的文档、社区帖子和自己的实测里得到一个结论：它能做好的是结构清晰、边界明确的任务，比如"从数据库里查出异常日志并按规则分类""每天定时抓取某个网页的变化并生成摘要""根据模板批量生成周报初稿"。而它做不好的，是那种开放式、需要长期上下文和多轮纠错的复杂任务，比如"帮我统筹整个项目的推进"。
这个认知后来让我少踩了很多坑。把 OpenClaw 当框架用，你会觉得它是神器；把它当全能 AI 员工用，你会觉得它是人工智障。 两者的差别，不在于它本身的代码，而在于你对它的定位。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 浪潮退去之后，自托管 Agent 沉淀下来的硬需求
2.1 IM 接入是刚需：微信、飞书、钉钉背后是真实的工作流
看各个平台上的搜索热词，我最深的感受是：大家真正想要的不是"又一个 AI 聊天机器人"，而是"能接进我现有工作流的 Agent"。"openclaw接入微信""openclaw接入飞书""openclaw接入钉钉"这几个词条的搜索量一直很高，这不是偶然。
为什么大家执着于把 Agent 接进 IM？因为对绝大多数打工人来说，IM 就是工作流的核心入口。你的待办、你的审批、你的交接、你的客户沟通，全都长在微信/飞书/钉钉里。一个 AI Agent 如果只活在网页端或者终端里，它和你的工作流就是割裂的——你得专门打开它，把任务复制进去，再把结果粘回来，这和使用成本没本质区别。
而 IM 接入的意义就在于，Agent 变成了工作流里的一个协作者，而不是一个需要你主动去访问的外部工具。消息到了、事件发生了，Agent 自己就启动了。这种"被动触发"的体验，才是自托管 Agent 相比网页版 AI 产品的核心优势。
还有一层需求是数据闭环。我在本地部署一个 Agent 接进飞书，它可以读我授权的群聊记录、会议纪要、文档库，帮我把这些零散的信息整理成结构化的任务清单。这件事在数据不出内网的前提下可以做到，但任何云端的 SaaS Agent 都做不到，因为你的数据根本不敢传出去。自托管在这里不是一种折腾，而是一种刚需。
2.2 数据主权：私有部署解决的是"不敢上传"的问题
很多人聊自托管，喜欢聊技术指标、聊模型能力、聊 token 成本，但我觉得最核心的其实是"数据主权"四个字。对外说我部署了一个 Agent，听起来很极客，但本质上是在说：我的代码、我的文档、我的客户数据、我的内部流程，只在我自己的机器上跑，不上传云端。
这个需求不是所有人都有的。个人的公开兴趣数据、不敏感的信息处理，用云端 AI 很爽；但一旦涉及公司内部的项目代码、财务数据、客户信息、内部制度，很多人是不敢往任何第三方服务里传的。我见过一个朋友为了"能不能让 AI 帮我看合同、提炼关键条款"，纠结了一周——不是模型能力不行，是他不愿意把合同内容传到外部服务。
自托管 Agent 解决的就是这个"不敢上传"的问题。OpenClaw 这类平台天然支持本地模型部署，你可以全程不连外网，用 Ollama 跑一个量化版的开源模型，把 Agent 的所有计算留在本机。代价是模型能力比云端 API 弱一截，但换来的是数据完全在自己手里。这个取舍在商业场景下，绝大多数时候是值得的。
我自己的体会是，数据主权不是一个可以量化的"功能"，而是一个能不能用的"前提"。在前提不满足的时候，再强的模型能力都是空中楼阁。
2.3 成本账：Token 费用、本地模型与长期持有逻辑
自托管还有一个经常被低估的点是成本结构。用云端 API 跑 Agent，你支付的是 token 费用，特点是"每用一次付一次钱"，频率越高、任务越复杂，账单越吓人。而 OpenClaw 这类平台的优势在于，它的模型后端是插件化的——你想用 Claude、GPT、DeepSeek 都行，也可以接本地模型。
实际算一笔账。假设你有一个每日任务：抓取行业新闻、生成摘要、推送到飞书群。如果用云端大模型 API 跑，每天消耗大约 200K token，按主流 API 的价格算，一个月下来大概是几十到上百块。听起来不贵，但这仅仅是一个任务。当你的 Agent 开始处理日志分析、工单分类、文档总结、定时报表，十几个任务加起来，月度成本会非常可观。
而本地模型的账单完全不同。花 5000 块买一张二手 GPU 或者直接用 Mac mini 的本地算力，跑一个 7B 或者 14B 的量化模型，日常任务完全够用，电费一个月几十块。前期投入高一点，但边际成本趋近于零。 这就是自托管长期持有的核心逻辑——它是"资产持有"而不是"按量付费"。
当然，本地模型不是万能的。复杂推理任务还是得上云端 API，但你可以把任务分级：简单琐碎的任务走本地，复杂推理的走云端。OpenClaw 支持给不同 skill 分配不同模型，这个能力我后文会细讲，它本质上就是帮助你做这种成本优化。
3. 未来三岔路：自托管 Agent 平台的走向判断
3.1 路线一：个人 AI 基础设施，替代的是手机里的通用助手
从热搜词里"手机上的 openclaw 怎么玩？我花了三天时间"这句话，能读出一种很有意思的期待——有人想把它变成一个随身携带的私人 Agent。自托管平台如果往这个方向走，它最终会变成类似 JARVIS 一样的"个人 AI 基础设施"，替代的是手机里那些联网的语音助手。
但要成为个人基础设施，有两条硬性指标：一是响应速度得跟上，不能问一句话等 30 秒；二是私密性要够，你的对话记录、日程安排、健康数据不能上传云端。这两条恰恰是云上 AI 产品的软肋，而本地部署的 Agent 天然满足。
我记得 OpenClaw 社区里有人做过一个"companion"项目，用本地模型跑一个日常陪聊、日程管理、信息记录的小助手，只存在于自己的电脑或手机上。它没有云端 AI 那么聪明，但那种"我知道它在本地、我的数据不会出去"的踏实感，是云产品给不了的。
这个方向的未来，其实不是模型能力的竞争，而是设备算力的竞争。当新一代终端设备的本地推理能力越来越强，个人 Agent 的体验会迎来一次质变。到时候 OpenClaw 这类平台的定位，就不再是"极客玩具"，而是个人数字生活的底层系统。
3.2 路线二：垂直职业的专用工作流 Agent
另一个我比较看好的方向，是"垂直职业的专用工作流 Agent"。从热词来看，"openclaw 写小说""ai agent 通过 es rest api 智能分析日志"这些搜索，已经不是泛泛地"让我看看 AI 能干嘛"，而是带着具体职业问题来的人：网文作者想知道它能不能辅助创作，运维工程师想知道它能不能自动分析日志。
这类需求有一个共同的模式：用户需要的是一个"会干我这个行业活儿的助手"，而不是一个"什么都会一点但什么都不精通"的通用对话机器人。 而 OpenClaw 的 skill 机制，恰好是实现这种专用的核心抓手。
举个例子，运维场景。你可以写一个 skill：输入一个 ES 索引的查询语句，Agent 自动从 Elasticsearch 拉取日志、按错误码聚类、生成异常分析报告。这个 skill 一旦写好，你的 Agent 就从"能聊天"变成了"会查日志的同事"。这就是垂直化的意义——它把 Agent 从"泛能力"收缩到"专用的专业能力"，价值反而更大。
商业上这也是最顺的方向。通用 Agent 的市场已经被大厂卷穿了，而垂直行业的 Agent 需要行业知识、内部数据、私有部署，大厂的服务很难覆盖到这么细的颗粒度。未来能在这波浪潮里赚到钱的人，大概率不是做平台的，而是拿着 OpenClaw 这类工具去给某个具体行业做深度定制的人。
3.3 路线三：Agent OS 化——不要做应用，做底座
如果说前两条路线是在已有的用户心智上做深，那第三条路线更像是在赌未来的标准。我始终觉得，OpenClaw 这类项目的终极价值不是做成一个应用，而是成为"Agent 的操作系统底座"。
什么叫 Agent OS？就是一套运行 Agent 的基础环境，提供任务调度、工具调用、记忆管理、多模型接入、权限控制、对外 API 等通用能力。应用可以在这个底座上跑，用户可以在这个底座上同时跑多个 Agent，每个 Agent 负责一个方向，彼此之间还能通过 API 协作。
现在很多人在做 Agent，但大家做出来的是一个一个的孤岛：写作 Agent 不会读你的数据库，HR Agent 不会和财务 Agent 沟通。Agent OS 干的事，就是把它们串起来，用统一的协议和机制让 Agent 之间可以互操作。这个方向其实已经有了一些探索，比如 MCP 协议让 Agent 可以统一调用外部工具，各类 Agent 编排框架也在解决"一群 Agent 怎么协同"的问题。
OpenClaw 的 skill 体系，本质上就是朝着这个方向长的一颗芽。一个 skill 定义了 Agent 的一项能力，多个 skill 组合起来，Agent 就能完成复杂任务。如果这种"能力即文件"的思路被更多人接受，并且形成通用的 skill 分发市场，那 OpenClaw 就真的不再是"一个软件"了，而是"Agent 生态的宿主"。
这个方向最大的变数在于社区能不能形成统一的协议和生态。单靠一个开源项目的社区力量去推，速度会慢很多，但一旦成型，其价值远远超过任何一个单独的应用。
4. 从"能跑"到"好用"：OpenClaw 落地中的经验与雷区
4.1 部署方式选择：Docker、WSL2 与原生安装的取舍
凡是想上手自托管 Agent 的人，第一个要过的坎就是部署。OpenClaw 不是那种双击安装、一路 Next 的软件，部署方式选错了，后面的坑会一个接一个。
我在不同环境里试过几种部署方式，结论是：没有最好的方案，只有最适合你环境的方案。
| 部署方式 | 适合场景 | 优点 | 主要痛点 |
|---|---|---|---|
| Docker | Linux 服务器、NAS、长期稳定运行 | 环境隔离、卸载干净、迁移方便 | 端口映射和卷挂载需要理解；Docker Desktop 在 Windows 上资源占用高 |
| WSL2 + 原生安装 | Windows 开发机 | 性能和原生接近，网络和文件系统适配好 | WSL2 的 localhost 转发偶尔抽风；路径转换容易踩坑 |
| Windows 原生/PowerShell | Windows 个人电脑快速体验 | 安装简单，一条命令，适合小白 | 环境依赖容易冲突；重装时会遇到资源锁定问题 |
| macOS 原生 | Mac 用户日常使用 | 上手顺滑，配合 Apple Silicon 跑本地模型方便 | 部分依赖对 ARM 架构适配不完美 |
如果你只是想先跑起来看看效果，Windows 上直接用官方 PowerShell 脚本装，Mac 上直接 brew 加脚本装，是最快的路径。但如果你打算长期跑、接多个 IM、做自动化任务，建议直接用 Docker Compose 部署在 Linux 服务器或群晖 NAS 上，省心很多，也方便后续迁移。
这里有一个我在 Windows 上实测踩过的坑：卸载重装 OpenClaw 的时候，很容易报 EBUSY: resource busy or locked, unlink 这种错误。 原因是 Agent 的进程还在后台占用文件，尤其是配置目录 ~/.openclaw 下的日志和数据库文件。解决方法是先彻底停掉 Agent 进程和 Control UI 进程，有时候还需要重启一下 Docker Desktop（如果 Agent 跑在容器里），再执行卸载命令。别急着删文件夹，先把进程杀干净，否则会一直报错。
另外一个常见报错是"oneclaw node runtime not found"（实际上是 OpenClaw 的 node 运行时路径没有找到）。这类问题的本质是 Node.js 的安装路径和 OpenClaw 的检测逻辑不一致。最简单的处理是重装 Node.js 并勾选"Add to PATH"，或者手动在配置里指定 node 路径。
4.2 模型配置的坑：DeepSeek、本地模型与多模型切换
OpenClaw 的模型配置，是用户报错的重灾区。很多人装完之后第一件事就是接 API，然后发现 Agent 一直报错，比如这个非常典型的报错：agent failed before reply: unknown model: deepseek。
这个报错的根因，通常不是模型本身不支持，而是 配置里的模型名称和 API 服务商实际返回的模型 ID 对不上。OpenClaw 的模型配置是严格的，必须在 openclaw.json 里正确指定 model 字段，而且这个字段的值必须和目标 API 服务商定义的模型 ID 完全一致。你如果写的是"deepseek-chat"，但 API 服务商那边返回的是"deepseek-chat-v3"之类更具体的 ID，就会报 unknown model。
正确的配置方式是这样的：先明确你要接哪家的 API，然后去对应服务商的文档里查准确的模型 ID。以 DeepSeek 为例，配置里 model 字段要填 deepseek-chat，base_url 要填对应的 API 地址，api_key 从服务商控制台获取。每一步都要核对，不能凭印象写。
还有一个很实用的点是 给不同 skill 分配不同模型。OpenClaw 允许在 skill 级别覆盖模型配置，这意味着你可以让"每日新闻摘要"这种简单任务走便宜的本地模型，让"复杂代码分析"走云端更强的模型。我试过用 Ollama 跑 Qwen 系列模型做本地任务，效果在可接受范围内，速度比云端 API 快很多，而且不用考虑 token 消耗。
提示：如果你想让 Agent 在完全离线的环境里跑，模型后端可以配置为 Ollama。安装 Ollama 后在本地拉一个量化版本的模型，然后在 OpenClaw 的模型配置里指定
ollama作为 provider 即可。关于本地模型，建议不要一上来就跑 70B 这种大模型，先试试 7B 或 14B 的量化版本，跑通了再升级。
4.3 写 Skill 的正确姿势：从"调 API"到"编排工作流"
Skill 是 OpenClaw 的灵魂。如果说 Agent 是一个会说话的大脑，skill 就是它学会的手艺。一个没有 skill 的 Agent 只能简单聊天；一个有丰富 skill 的 Agent 才能真正"干活"。
我第一次尝试写 skill 的时候踩了一个典型的坑：我以为 skill 是一个编程脚本，用 Python 或者 JavaScript 去写的。实际上，OpenClaw 的 skill 本质上是一个 Markdown 格式的能力说明书，它告诉 Agent"你有这个能力、你的执行流程是什么、你可以调用哪些工具"。真正的逻辑执行，由 Agent 自己去理解并完成。这种设计的好处是灵活，坏处是你得把自己的流程讲得非常清楚。
写一个有效的 skill，我总结了几个步骤：
- 定义清晰的触发场景。 这个 skill 解决什么问题、在什么情况下被调用，写清楚。
- 描述执行步骤。 把任务拆成 Agent 可以逐步执行的流程，步骤要明确。
- 指定可用工具。 告诉 Agent 这个 skill 可以调用哪些 API、哪些系统命令、哪些文件路径。
- 提供参考示例。 给一个输入输出的示例，Agent 就知道"做成这样是对的"。
举个例子。我写过一个"分析日志异常"的 skill，流程大概是：从指定 ES 索引拉取最近一小时的日志 → 按错误级别和错误类型聚类 → 生成异常摘要 → 推送到飞书群。整个 skill 不需要写一行 Python 代码，靠的是把 Elasticsearch REST API 的调用方法、字段含义、输出格式写清楚，Agent 自然会组合这些能力去完成。
但这里有一个专业的提醒：skill 的权限控制一定要收窄。 不要让 Agent 在 skill 里拥有调用所有 API key 的权限。最稳妥的做法是给每个 skill 配置单独的密钥或最小化权限的 token，只让它访问完成任务所需的那几个接口。不然有一天你让 Agent 分析日志，它顺手把你的数据库记录删了，哭都来不及。
4.4 接入 IM 与 Control UI 的常见故障排查
把 Agent 接进 IM，是你真正开始"使用"它而不是"折腾"它的标志。但这一步同样有隐藏的雷。
先说各自的情况。飞书和钉钉的体验相对顺滑，因为它们的开放平台上机器人接口很成熟，你可以自己创建一个自定义机器人，拿到 Webhook 地址，然后填进 OpenClaw 的配置里。微信的情况特殊一些，个人微信没有官方开放的机器人接口，有一些方案通过 hook 或者其他方式来做，但存在账号风险，我个人的建议是如果只是自用，优先考虑企业微信或者替代方案，不要在个人微信上折腾太狠——账号出了问题得不偿失。
接入 IM 之后，经常遇到的问题是 Agent 不回复消息。这个问题的排查链路一般是：
- 先检查 OpenClaw 日志。 看消息有没有进来，如果没有，说明 Webhook 或回调地址配置有问题。
- 再看 Agent 有没有生成回复。 如果日志显示回复生成了但没发出去，大概率是 IM 平台侧的接口权限问题。
- 最后看模型调用。 如果模型调用超时或者报错，Agent 会直接放弃回复，你看到的就是"装死"。
控制 UI 起不来是另一个高频问题。比如报 openclaw control ui did not start，本质原因多数是端口冲突或服务进程异常。默认端口被占用时，UI 起不来但 Agent 还在后台跑，导致你以为整个服务挂了。解决办法是查看默认端口占用情况，改一个端口重新启动 UI 进程。
提示：跑 OpenClaw 的时候，尽量养成看日志的习惯。它所有的运行信息都在日志里，报错原因、调用链、模型输入输出，一目了然。很多人卡住是因为从头到尾都不看日志，只凭感觉猜问题。日志是你排查问题最可靠的抓手，比任何教程都管用。
4.5 一个务实的落地路径：从一个 48 小时能跑通的小场景开始
很多人在 OpenClaw 上坚持不下去，不是因为能力不够，而是因为一开始就给自己定了太大的目标。我见过有人装完第一天就想着让 Agent 接管所有工作流，结果跑了一下午没跑通，直接弃坑。
更务实的路径是这样的：先给自己一个 48 小时能跑通的极小场景。
第一天，完成安装和基础配置，让 Agent 能在终端里回答你"你是谁、你能做什么"。此时不要急着接模型，先用默认配置跑通对话，确认整个链路是通的。
第二天，接入一个真实可用的模型（DeepSeek 或其他 API），然后"写一个最小的 skill"，比如"把一份纯文本格式的聊天记录整理成 Markdown 表格"。这个任务足够小、足够具体，既能验证 skill 机制能否工作，又能让你感受到自托管 Agent 的真正价值。
跑通这两个步骤之后，你才算是真正入门了。之后再考虑接入 IM、写更复杂的 skill、编排多个任务，都是水到渠成的事。
我自己实际用下来的体会是：决定一个自托管 Agent 能不能用起来的，往往不是模型能力，而是你对任务的拆分能力。 把任务拆得足够小、边界足够清晰的时候，Agent 的完成度会超出你预期；反过来，任务一模糊，它就开始自由发挥，结果不可控。这个规律，不管用 OpenClaw 还是用自己的代码去拼一个 Agent，都是一样的。
5. 浪潮教会我的几件事
说回标题的问题——OpenClaw 的浪潮过去了，自托管 AI Agent 平台的未来在哪？
我的判断是：未来不在"下一个 OpenClaw"身上，而在你亲手搭出来的那套工作流里。 平台会不断迭代，工具会不断更换，但"把 AI 的能力私有化、定制化、嵌入自己真实场景"这个需求，只会越来越强烈。
这波浪潮让我最深的体会有三点。第一，不要高估趋势、低估需求。OpenClaw 的热度确实退了，但搜索"openclaw接入微信""openclaw 写 skill"的人并没有消失，他们从围观者变成了真正的使用者，这是更健康的社区状态。第二，不要把工具当产品。一个框架能火说明它踩中了需求，但框架要变成生产力，还需要大量的场景适配和工程打磨，这恰恰是所有后来者的机会。第三，自托管这条路虽然折腾，但它给你的是掌控感——数据在手里、流程在手里、成本在手里，这种掌控感在云服务越来越强势的今天，反而是一种稀缺的东西。
如果你还在犹豫要不要入坑，我的建议是：先别想什么大趋势，找一个小场景，花一晚上把 OpenClaw 跑起来，写一个最简单的 skill，让 Agent 帮你完成一件真实的小事。做完这一步，你对"自托管 Agent 平台"这个词的理解，会比刷一百篇文章都深刻。浪潮什么时候过去根本不重要，重要的是你能不能在这个浪潮里，捡到一件真正属于自己的趁手工具。