18. 2026 年初起：OpenClaw 与个人智能体生态热潮

来源：大模型技术演进

2026 年 1 月 29 日，Peter Steinberger 在项目博客里宣布了一个新名字：OpenClaw。按他当时披露的数据，这个两个月前还只是周末实验的项目，已经获得超过 10 万个 GitHub 星标，一周吸引了 200 万访问者。星标和访问量不等于长期活跃用户，但足以说明：一个个人开发者做出的 Agent，正在吸引远超普通开源工具的关注。OpenClaw 更名公告

到了 3 月，这种关注已经走出了开发者的代码仓库。《齐鲁晚报》报道，3 月 6 日，深圳腾讯大厦楼下出现了带着电脑排队参加免费安装活动的人群。“养龙虾”也成了安装和使用 OpenClaw 的形象说法。当时的报道

这个画面很能体现变化：人们不只是在围观一段 AI 演示，而是想把一个能长期使用的助手装进自己的数字生活。给它一个消息入口，让它接触自己的资料，在需要时替自己做事，成了可以亲手尝试的事情。

前几篇讨论的 Coding Agent、研究 Agent 和多模态创作，已经展示了模型如何完成连续任务。OpenClaw 把另一个问题推到了台前：这些能力能否围绕一个人持续组织起来，而不总是从一次新的对话开始？

它从哪里来，又到底是什么

OpenClaw 的故事起于 2025 年末。创始人的回顾提到，项目最初是连接 WhatsApp 的实验，经历了 Clawd、Moltbot 等名称，最终在 2026 年 1 月采用 OpenClaw。早期资料里也经常出现 Clawdbot，阅读旧教程时需要留意名称和版本，而不是把它们误认为几套完全无关的产品。

这次热潮的主角是一套开放的 Agent 平台。它可以部署在用户选择的电脑或服务器上，通过聊天软件接收任务，再调用模型和工具。OpenClaw 本身并不是与 Claude、DeepSeek 或 Kimi 同一层次的基础模型；更名公告中也列出了对不同模型的支持。项目定位与早期沿革

这一点解释了它与前面章节的关系。模型负责理解要求、选择下一步和生成内容；OpenClaw 负责把这些能力接到消息、会话、文件、工具和运行环境上。模型变强，可以提高复杂任务的完成质量；应用组织方式变好，则可以让同样的模型更容易进入日常使用。

因此，不能把 OpenClaw 的出现解释成“它训练出了一个突然学会所有事情的新模型”。更合适的理解是：此前逐渐成熟的能力，在这里形成了一种吸引人的产品组合。

创始人个人的去向也引发了关注。2 月中旬，Steinberger 宣布加入 OpenAI，同时表示 OpenClaw 将走向基金会形式并保持开放、独立。这是人才和项目治理的重要变化；不能据此把 OpenClaw 简单写成一个只能使用 OpenAI 模型的封闭产品。创始人说明

为什么聊天入口会改变 Agent 的使用方式

过去使用很多 AI 工具，需要先打开专门的网站，找到对应对话，再把资料搬进去。OpenClaw 强调通过人们已有的聊天软件使用助手。这个变化看起来只是换了一个输入框，实际会改变使用频率和任务组织方式。

比如，外出时突然想到一件事，用户可以从手机发消息，把任务交给仍然在线的电脑或服务器。任务执行和人盯着某个网页，不必发生在同一块屏幕上。需要补充信息时，助手也可以通过相应消息渠道继续沟通。

这背后有一个重要组件：Gateway，通常译为网关。可以把它理解成常驻的接待与协调服务，负责连接消息渠道、会话和执行端。OpenClaw 的架构文档把长期运行的 Gateway 放在中心，命令行、网页界面和设备节点围绕它连接。Gateway 架构说明

一条任务的大致路径可以写成：

聊天消息 → 网关找到对应会话 → 模型结合上下文选择行动 → 工具执行并返回结果 → 助手继续判断或回复。

这条路径里，手机可以只是遥控入口。真正读取文件、运行程序的可能是家中的电脑，也可能是云服务器；模型推理还可能由另一家云端 API 提供。

所以，“把助手装在我的电脑上”并不自动等于“所有模型都在本地运行”，也不自动等于“资料完全不会离开电脑”。要理解数据和计算在哪里发生，需要分别看消息渠道、Agent 的执行位置和模型服务。这也为最后一篇的硬件讨论留下了一个关键区分。

持续使用，需要记忆，也需要有人按时叫醒它

如果助手每天都忘记项目背景，用户就得不断重讲；如果它只有在收到新消息时才运行，就很难承担持续关注的任务。这是个人 Agent 与一次性问答之间的两道门槛。

先看记忆。OpenClaw 在 2026 年 1 月底版本的文档中，已经把记忆组织为工作目录里的 Markdown 文件：日常记录与整理过的长期记忆分别保存，还可以对相关笔记建立检索索引。这里的记忆是写下、保存、再找回，并不是用户每说一句话，模型权重就重新训练一次。1 月底版本的记忆文档

例如，“这个复习助手先做网页版，移动端以后再说”，是一项可以保存的项目决定。下一次讨论开发计划时，系统把这项决定带回来，模型就更有可能接着原来的方向工作。

但保存不等于永远正确。项目可能改期，用户偏好可能变化，旧记录也可能与新决定冲突。实用的记忆需要能更新、能追溯来源，而不是不断堆积。模型能处理的当前上下文仍然有限，硬盘上存了很多资料，也不代表每次调用都完整读过。

再看持续运行。早期文档中的 Heartbeat，会周期性启动一轮 Agent 检查，让它判断有没有需要关注的事情；没有事情时，可以不向用户发送通知。它与“某个具体时间执行一项任务”的定时安排相关，但关注点不同：前者偏向定期检查，后者偏向明确日程。早期 Heartbeat 文档

所谓主动性，因而可以拆成很具体的过程：调度器触发检查，系统提供任务和状态，模型判断是否要行动，再通过工具执行或通知。助手并不是在两次调用之间拥有一条永不停歇的思维。

这个区别会影响使用预期。电脑睡眠、网关停止、网络断开或模型额度耗尽，都可能中断任务。想得到“持续可用”的体验，就需要一个持续可用的运行环境。

Skills 和插件，让个人助手能够接上更多实际工作

记住目标、收到消息以后，还得有办法完成任务。一个只能生成文字的模型，不会因为被称作 Agent，就自然拥有日历、文件系统或办公软件的操作权限。

这里可以先区分三种作用：

组成	解决的问题	简单例子
消息渠道	人从哪里交代任务、接收结果	在飞书里给助手发消息
工具或插件提供的接口	系统实际能做哪些动作	读取文档、查询日历、保存文件
Skill	什么时候使用这些工具，按什么步骤工作	整理学习资料时保留来源，并生成复习清单

OpenClaw 的 Skills 以 SKILL.md 等说明文件组织，可以配合脚本和相关资源。它们为模型提供任务方法，并不等于给基础模型安装了一块新的知识权重。Skills 文档

这使生态扩展变得直观。开发者不必为每一种任务重新做整套聊天产品，可以围绕已有助手补充接口、步骤和资源，其他人再把这些能力组合到自己的工作里。ClawHub 则承担了技能分发的一部分工作。

与此同时，“装了一个技能”不等于依赖、账号和权限都已齐备。如果技能教模型查询某项服务，但账号尚未授权，模型知道步骤也无法执行。对于应用开发者来说，这提醒我们把说明、真实工具和授权状态分开设计，避免让用户把“知道怎么做”误认为“现在已经能做”。

中国生态的跟进，是分批接通真实入口

对中国用户而言，能否接入日常使用的消息与办公平台，会直接影响 OpenClaw 是偶尔体验的玩具，还是容易继续使用的助手。2026 年春季的生态跟进，正是在降低这道门槛。

飞书是一个清晰的例子。飞书官网标注为 3 月 5 日的文章宣布推出官方插件；其官方说明把消息、文档、多维表格、日历和任务等工作能力，与在飞书中聊天的入口联系起来。用户获得的不只是一个能回话的机器人，还包括经授权后接触工作资料和执行操作的可能。飞书官方插件公告及持续更新说明

这里也有容易混淆的地方：OpenClaw 文档所列的 @openclaw/feishu 是社区维护的渠道插件，飞书厂商推出的官方插件是另一条分发路线。“出现在 OpenClaw 官方文档里”和“由飞书官方开发”，不能直接画等号。社区插件的维护归属

QQ、企业微信和微信也应分别看待：

可核实的时间节点	具体变化	不应混淆的边界
2026 年 3 月，QQ 插件持续迭代	腾讯组织下的 QQBot 插件日志至少记录了 3 月 6 日起的版本；随后增加引用上下文、提醒等改进	QQ 机器人渠道，不等于接管个人 QQ 账号的全部功能
到 3 月下旬，腾讯云配置文档列出企业微信等通道	云上 OpenClaw 可以配置企业微信、QQ、飞书等消息入口	企业微信是独立的协作平台，不能当成个人微信
到 3 月下旬，微信也进入云端通道配置；另有腾讯微信插件	通过微信 ClawBot 等入口，把消息交给连接的 Agent	聊天入口不代表开放所有微信数据或支付、社交操作

这些节点分别可以从 QQBot 版本记录、3 月 24 日更新的腾讯云通道说明和腾讯微信插件仓库核对。表格采用能够确认的记录时间，不把文档更新时间当成每项能力的首次发布日期。

同样，持续更新的插件文章可能加入后来的功能。3 月的发布节点，并不证明今天列出的所有功能都在首日开放，更不能全部提前算到 1 月的热潮里。

从应用演进看，这些连接的意义在于减少搬运：用户不必每次复制整段资料，再把答案粘回去。但能收发消息、能读取业务数据、能修改业务数据，仍然是不同程度的接入，需要各自对应的接口和授权。

云端托管和桌面产品，把安装难题变成产品机会

排队安装的热闹，既说明人们有兴趣，也说明部署仍有门槛。运行环境、模型配置、消息授权、升级维护，对于非专业开发者并不轻松。

2026 年的产品跟进中，出现了不同的简化路线。截至本系列观察时，Kimi 的官方帮助中心介绍了通过 Kimi Claw 一键部署云端 OpenClaw，也支持关联已有实例；MiniMax 的 MaxClaw 官方页面则明确把自己定位为基于 OpenClaw 的云端 Agent。这些是托管和使用方式上的产品，不应只因名字带有 Claw，就当成新一代基础模型。Kimi Claw 官方介绍、MaxClaw 官方介绍

另一条路线是把配置和本地执行包装成桌面应用。腾讯 4 月 21 日的公告介绍了 QClaw 国际测试版，说明它基于 OpenClaw，可安装在 Windows 或 macOS 上，通过消息软件远程下达任务。该公告也明确了首批开放地区和名额，因此这里的日期是国际测试节点，不是国内首发日期。QClaw 国际测试公告

托管产品可以让用户少维护一台服务器，本地产品则更容易围绕本机文件和软件工作。二者各有适合的任务：云端实例持续在线，并不意味着它自动能读取家里电脑的桌面；本地助手拿得到某个文件，也不意味着笔记本关机后还能继续处理它。

这场热潮还吸引了基础设施厂商。3 月 16 日，NVIDIA 宣布 NemoClaw，为 OpenClaw 组合 Nemotron 模型和 OpenShell 运行环境，强调隐私与安全控制。它体现出一个新的产业需求：个人 Agent 不只需要模型 API，还需要能长时间承载执行、管理权限的环境。NVIDIA 公告

助手越常驻，成本和可靠性越需要重新计算

模型能力和调用成本的改善，为多步任务提供了条件，但常驻助手会增加新的调用来源：检查消息、检索记忆、读取工具结果、重试失败步骤，都可能消耗计算或 API 额度。

举一个纯粹用于理解频率的例子：如果某项检查每半小时触发一次，一天就有 48 个调度时点。实际是否调用模型、传入多少上下文，要看配置和跳过逻辑。这不能直接换算成固定账单，却能说明为什么“我今天只主动发了两条消息”不等于“系统只工作了两次”。

长期使用的目标也应当随之改变。一次演示成功，证明一条路径可能走通；连续一周没有漏任务、重复通知或处理错文件，才更接近日常工具的要求。

生态开放还会扩大需要信任的范围。2026 年 2 月 7 日，OpenClaw 宣布与 VirusTotal 合作，为 ClawHub 技能增加扫描。这项措施针对技能分发的风险，但公告同时承认扫描并不能发现所有问题。技能安全合作公告

原因并不难理解：助手既能读内容，又能使用工具，外部文档里的文字就可能被误当成新的指令；第三方技能还可能带来脚本和依赖。更强的模型有助于判断，但实际可以操作哪些文件、能否发送消息、失败后怎样停止，仍要由应用的权限和执行机制落实。

这不是个人 Agent 之外的附加问题。用户越希望它在自己离开时继续工作，就越需要知道它会做什么、做到了哪一步，以及什么时候会停下来等待。

回到个人项目：把复习助手变成持续服务

用前几篇的复习助手做一个教学构造，可以把这些变化串起来。这个例子不是 OpenClaw 的实际运行测试，也不意味着安装后自动具备全部能力。

你希望每天晚上收到一份复习清单，并在手机里补充新笔记。系统需要完成的事情大致是：接收笔记并保存来源，找出到期卡片，生成当日清单，在约定时间发给你，再记录哪些卡片已经完成。

这里至少有三类信息，不能只混在聊天记录里：稳定的学习偏好、当前卡片与完成状态、下一次任务的执行时间。偏好可以进入记忆；卡片和进度更适合保存为明确的数据；执行时间交给调度机制。让模型读懂它们并提供帮助，与让模型凭聊天印象管理一切，是不同的设计质量。

如果今天已经完成五张卡片，明天的提醒应当依据更新后的状态；如果发送失败，系统应当知道任务还没有交付；如果同一条消息被重试处理，也不应重复创建卡片。验收时，可以检查已保存的卡片、消息投递记录和下一次调度时间，而不能只看助手说了一句“已经安排好了”。

当这些环节接起来，个人 Agent 的价值才变得具体：它围绕你的项目保留必要信息，在合适的时候使用工具，把结果送到你常用的入口。OpenClaw 的热潮让更多人第一次认真尝试这种使用方式，也让模型厂商、消息平台、云服务和插件作者围绕它继续补齐生态。

这条历史线索没有终结于一个“万能助手”。它把问题推进到了下一层：在持续运行的应用里，模型究竟能稳定承担多少判断和行动？下一篇将回到截至 2026 年 10 月的模型进展，比较推理、编程、多模态、上下文和工具使用的能力边界。

---

上一篇：17｜2024—2025：从单次生成到连续创作，多模态应用进入工作流程

下一篇：19｜截至 2026 年 10 月：模型能力与应用边界推进到了哪里

返回：第 0 部分大纲