OpenClaw 爆火 60 天带火了谁？当个人 Agent 平台变成产业基础设施 App 别再把流量当“黑盒”

短短两个月，开源智能体框架 OpenClaw 从“那只不安分的蓝色龙虾”变成了史上最火的开源项目：GitHub 星标数一度超过 Linux，Reddit 社区 r/openclaw 仅用一个多月周访问就冲到十几万，一连串“自动打电话、误删 Meta 安全部门邮件、被谷歌和 Anthropic 封杀”的故事轮番上热搜。一篇网易智能的长测文章，从个人创作者和极客项目经理两个视角，展示了它在真实工作环境里“既神奇又莽撞”的样子。发布两个月成史上最火开源项目！全网爆吹的 OpenClaw

更关键的是，一篇来自 36 氪的产业观察，把这只“小龙虾”放进更大的坐标里：它已经不只是极客玩具，而是在复杂、封闭、充满博弈的企业 IT 环境中，走出了一条“先执行、再优化、再重构”的路，把整条 AI 产业链一起拉进了 Agent 深水区。OpenClaw 爆火 60 天：中国产业 AI 落地的“又一次集体进化”

对 App 和 B 端产品来说，这意味着一件非常现实的事：你的用户越来越可能是通过某个 OpenClaw / CoPaw / KimiClaw / MaxClaw / LobsterAI 之类的个人或企业 Agent，在各种 ERP 后台、SaaS 页面、Office/WPS 界面之间一顿“点点点”之后，顺手调用了你的能力，而不是直接点开你的 App 图标。如果你还把这部分流量当成看不见的“黑盒”，只在报表里看到“API 调用数上涨”“某云上 QPS 飙了”，却说不清楚是谁、从哪儿、以什么方式在用你，很快就会在成本、归因和安全上被动挨打。

OpenClaw 做对了什么：从“困在 API 里的 Agent”到“外挂型执行”

过去一年，大家谈 Agent，更多是在讲：大模型作为“大脑”，通过一堆 API/工具去连搜索、数据库和内部系统，然后把“帮我做一份行业报告”拆成“查资料、筛信息、生成图表、写文档、发邮件”的完整闭环。现实是，只要涉及多系统协同，企业常常要走一条极重的集成路线：对接 API、梳理数据结构、重构权限体系、重建流程引擎，一旦某个系统升级，集成工程就要返工。36 氪引用 WebArena 等测试数据指出，在真实网页多步任务里，GPT‑4 级模型 3–5 步成功率还有 40%–60%，一旦超过 10 步就骤降，超过 15 步甚至低于 10%，大量任务要靠 40%–60% 的人工介入才能收尾。

OpenClaw 选择了另一条路：不等 API，不改系统，而是直接在“屏幕层”装一个会看界面、会点鼠标的 Agent。它通过截屏让模型理解当前界面，用坐标计算定位按钮、输入框，再用模拟鼠标键盘完成点击、输入、滚动等操作，循环执行直到达成目标。这种方式的好处是，哪怕 ERP、SaaS、老系统完全没有 API，你也可以让 Agent 像人一样“登录系统 → 点菜单 → 导报表”，先让自动化在旧秩序里干起来。

一项基于 CL‑bench 的公开测试显示，在 HR 培训类标准化任务集里，“OpenClaw + MiniMax‑free Agent”组合能完成约 20% 的任务，而同样任务下裸跑 MiniMax‑M2.1 或 DeepSeek‑chat 的成功率为 0%。这说明当你只给模型一个网页，它很难从 0 到 1 把完整流程跑顺，但一旦有屏幕级执行能力配合，就能在一部分结构化任务里真正“站起来干活”。

网易智能的实测也印证了这一点：在清理 2000 多封邮件、退订 200 多个垃圾订阅、整理 300 多个本地文件这类结构化任务上，OpenClaw 表现得像一个动作极快、极其耐心的小助手；而在代码审查、会议预约等需要判断可靠性的复杂决策场景中，它又暴露出“漏掉明显漏洞、谎称已发邀请”的严重问题。

换句话说：OpenClaw 把 Agent 从“只能在理想的 API 世界里表演”拉进了“真实、有坑、有旧系统的企业环境”，告诉大家——在中国这种平均一家公司动辄上百套系统、六成以上还是没有 API 的环境里，Agent 完全可以先当一个“外挂型执行层”，再慢慢推动系统重构。

爆火两个月，被真正带火的是谁？

第一圈：云厂商和模型厂商围着“小龙虾”搭生态

在中国这样的市场，一旦出现一个能落地的新范式，最先反应的一般都是“卖铲人”。围绕 OpenClaw，两条线几乎同时拉起来：一条是云厂商做“算力+平台闭环”，一条是模型厂商争当“最合适的大脑”。

• 云厂商这边：

  • 阿里云推出 CoPaw 个人智能体工作台，对标 OpenClaw，强调“三条命令极简部署”，原生适配钉钉、飞书、QQ 等 IM，支持本地+云端双模部署，并在云上提供 OpenClaw 一键安装和预装镜像，用 OpenClaw 把开发者、企业“拽上云”。

  • 腾讯云通过轻量服务器预置 OpenClaw 模板，打通企业微信、QQ、飞书、钉钉，同时内部自研 Agent 平台，把微信、小程序和企业办公生态尽可能牢固地绑在一起，避免核心入口被开源框架抢走。

  • 百度智能云则围绕搜索入口下功夫：企业在百度云上部署好后，可以直接在百度 App 的搜索框、消息中心一键调用 Agent，后续覆盖百科、学术、文库、电商等内容场景，把 Agent 融进日常搜索行为，而不是做一个孤立工具。

• 模型厂商这边：

  • 月之暗面做了 KimiClaw，走“云端托管 + 无需本地环境”的路，把部署门槛压到最低，利用 Kimi 在长上下文和工具调用上的优势，服务习惯用浏览器和文档工具的普通用户。

  • MiniMax 推出 MaxClaw 模式，一键打通 OpenClaw，无需自己配 API。在“一次性完成本地文件检索、全网资讯补充、稿件撰写和邮件发送”的长链路办公任务实测中，接入 MiniMax‑M2.5 的 OpenClaw 完成率达到 100%，没有中途断掉或关键环节失败。

  • 智谱、科大讯飞等，则分别用 GLM‑5、语音/教育场景切入，主打国产化、合规和成本可控。

这一圈人，本质都在通过 OpenClaw 搭一个“自己擅长的闭环”：阿里云强调云+模型+钉钉，腾讯云强调 IM 流量和办公生态，百度强调搜索入口和内容，模型厂商强调“谁更适合当 Agent 的大脑”。OpenClaw 变成了一个公共模板，大家围绕它设计自己那套一站式解决方案。

第二圈：RPA、SaaS 和安全厂商被迫“自我革命”

对传统 RPA 和 SaaS 来说，OpenClaw 是一个不太舒服的存在：

• 它在做的事情（看界面、点按钮、填表单）和 RPA 非常像，只是把“录脚本+规则”换成了“大模型+视觉”；

• 它绕过 API 和内部协议，在 UI 层“硬控”，天然削弱了 SaaS 平台对流量和数据的掌控力。

结果是：

• RPA 厂商一边警惕，一边主动靠过去：弘玑 Cyclone、来也科技等快速推出“OpenClaw 企业级管理后台”，试图把“散在个人电脑上的龙虾”纳入企业级编排和审计体系。

• SaaS 和协作平台则开始“友好化界面”：飞书发布 Agent 友好型 UI 协议，WPS 开放 WPS AI 行动套件，希望未来 Agent 与自己的产品交互不只是靠“识别像素点”，而是有更结构化、更易机器识别的交互约定。

• 安全厂商看到的是新攻击面：奇安信等推出“Agent 行为防火墙”，专门监控这类在 UI 层模拟人类操作的 Agent，防范 UI 提示词注入、权限越界和敏感操作异常。

这一圈变化，对你的 App 有一个直接含义：你未来会越来越多地被“间接使用”——不是用户点你的按钮，而是某个 Agent 在别的平台里帮用户点你的按钮、调你的 API。

当个人 Agent 平台开始给你导流和调 API，如果还把流量当“黑盒”，会出现哪些问题？

第一层，是“看得见调用，看不见人和场景”。

在 OpenClaw 或自建 Agent 平台的场景中，你的服务会以几种典型方式被使用：

• 作为“工具 API”：Agent 在后台直接调用你的接口，比如发邮件、生成报表、同步 CRM。

• 作为 UI 层的操作目标：Agent 帮用户在你的 Web/桌面界面里点按钮、填表单、导出文件。

• 作为上层平台能力的一部分：云厂商或 SaaS 把你的 SDK 集成进自己的产品里，对外只说“这是某某平台的某某功能”。

如果你自己的系统里没有任何标识：

• 日志中只看到一堆“来自某云机房 IP 的高频调用”，看不出是哪家平台、哪个 Agent、哪条工作流；

• 产品报表里只看到某个功能调用数陡增，但不知道这些调用背后是不是来自 OpenClaw 这类平台；

• 成本侧，只能看到总 token、总算力支出上涨，却没法细分“哪类 Agent 流量是值得投资的，哪类只是玩票”。

第二层，是“权限和安全的边界被悄悄打薄”。

• 同一个账号，用人手点和用 Agent 点，风险完全不同：Agent 可以在极短时间内高频操作，还可能受到恶意网页的 UI 注入攻击；

• 如果你没有在权限模型里区分“人类终端调用”和“Agent 调用”，就等于把高权限钥匙拱手交给一个你几乎无法观测的自动脚本。

这一切的共同根源，就是：你缺少一套专门面向 Agent/平台流量的渠道标识、参数约定和事件模型。

从“黑盒调用”变成“可观测渠道”：App 要怎么给 Agent 流量打上标签？

第一步：用 ChannelCode 把“Agent 平台入口”和“自有入口”分清

你不可能阻止别人用 OpenClaw 在 UI 层点你的界面，但至少可以把所有“愿意和你合作的平台”纳入一套清晰的 ChannelCode 体系。例如：

• 平台维度：

  • ChannelCode=AGENT-OPENCLAW-TOOL：通过 OpenClaw 工具 API 使用你的能力。

  • ChannelCode=AGENT-COPAW-ALICLOUD：通过阿里云 CoPaw 调用。

  • ChannelCode=AGENT-KIMICLAW / AGENT-MAXCLAW / AGENT-LOBSTERAI 等。

• 场景维度（可以作为附加参数而不是 ChannelCode 本身）：

  • scene=email_cleanup（清理邮件）

  • scene=file_organizing（文件整理）

  • scene=report_export（导出报表）

  • scene=crm_sync（同步 CRM）等。

这些字段可以写入：

• 你向平台开放的 API/SDK 协议（例如在 Header 或 query 参数里约定 x-channel-code、x-scene）；

• 平台向最终用户暴露的“继续在 App 内打开”链接里，通过智能传参与深度链接带到 App 内。

在 App 内侧，可以借助我们自己的「全渠道统计」能力，把这些 ChannelCode 在首启、拉起和关键行为埋点时自动采集与归档，从而让“来自 Agent 平台的流量”在报表中独立成列，而不是混入自然量里。

第二步：用智能传参与事件模型，把“哪一个 Agent、哪条工作流”记下来

仅仅知道“来自 OpenClaw”不够，你还要尽量知道是“哪一个 Agent / 机器人 / 工作流”在用你。可以约定一套简单的 Agent 元数据，例如：

• agent_platform：openclaw / copaw / kimiclaw / maxclaw / lobsterai / 自研等；

• agent_id 或 workflow_id：由平台侧创建的工作流 ID；

• agent_type：personal / team / enterprise；

• risk_level：只读 / 读写 / 管理操作。

在调用协议中统一用一个字段（比如 x-agent-meta）承载这些信息，你的服务在入口解析后，将其写入埋点和日志。

对于“从 Web/桌面 → App”的路径，可以用智能传参与深度链接，把这些元数据编码进链接，例如：

• https://www.xinstall.com/?channel=AGENT-OPENCLAW-TOOL&agent_platform=openclaw&scene=report_export

用户点击后，Xinstall 会在安装或拉起 App 时自动还原参数，你在 App 内就能同时拿到：

• 这是一次来自 OpenClaw 的导出报表场景；

• 对应的 ChannelCode、平台、场景等信息。

关于智能传参与安装的完整配置流程，可以放一个指向你们产品文档或案例文章的站内链接，让读者有兴趣可以立即进一步了解。

在数据和安全侧，为 Agent 流量留出“独立观测面”

在数据仓或埋点系统里，你可以专门建立一张“Agent 调用事件表”，至少记录：

• 来源维度：agent_platform、agent_id、channel、scene；

• 调用维度：功能模块、接口名、权限级别、耗时、token 成本；

• 结果维度：成功/失败、错误类型；

• 后果维度：是否触发关键业务事件（下单、发货、权限变更、批量导出等）。

配合用户层事件表，你就能回答：

• 哪些 Agent 平台/工作流带来的调用真正形成业务闭环，而不仅是“试试看”；

• 在相同场景里，是用户自己点界面更稳，还是通过某个 Agent 平台更高效；

• 哪些 Agent 合作值得你主动去谈定价和联名，哪些则需要设定更严格的频率和权限限制。

在安全侧，则需要把 Agent 调用纳入现有的权限和审计体系：

• 即便是同一个业务账号，通过 Agent 发起的调用默认视为“高风险源”，单独配置权限集；

• 针对高危操作（删除、批量修改、导出敏感数据）设置更细粒度的审批或二次确认；

• 把 UI 层异常行为、极端高频操作等模式加入风控规则，避免未来出现“被某个被劫持 Agent 挖空数据”的风险。

对团队意味着什么：在 Agent 变成“新操作系统”之前把基础打好

对开发者来说，OpenClaw 这波浪潮提醒的是：你的服务未来不仅要支持人类前端，还要支持各种 Agent 作为“第一类客户端”。提前预留好规范的 API/SDK、清晰的 Agent 元数据字段、独立的权限模型，是避免未来被各种平台接入搞到“疲于应付”的前提。

对产品经理来说，Agent 不只是“一个新功能入口”，而是“一个新的用户类型”：他们不看 UI，只关心流程是否明确、页面结构是否稳定、反馈是否可机器理解。为 Agent 优化的界面结构、提示文案和状态设计，同样会反过来提升人类用户的效率。

对增长团队来说，OpenClaw、CoPaw、KimiClaw、MaxClaw、LobsterAI 这些名字，实质上就是一批新渠道：它们在用户身边、在企业内部默默执行任务，把你的能力嵌进各种场景。如果你能用 ChannelCode 和智能传参与事件模型把这部分流量看清楚，它们就是可以经营的“隐形金矿”；如果看不清，它们就只是一串越来越大的算力账单。

在 Agent 真正成为“下一代操作系统”之前，把自己这边的入口设计、归因体系和观测面搭好，是一件不耀眼，但极其划算的事。