“龙虾”危机警示： OpenClaw还能用吗？事故频发下， NanoBot + 飞书/七牛大模型快速接入指南
|
摘要 ：OpenClaw 近期发生 512 项漏洞、 ClawJacked 高危风险、 3.22 更新导致主流插件集体失效，国家知识产权局同时警示 OpenClaw 等智能体存在多重安全风险。本文给出轻量替代方案 NanoBot + 七牛云 + 飞书的接入指南， 10 分钟可完成，适合追求稳定迭代的团队。 国家知识产权局提示：用 OpenClaw 等智能体撰写专利文件存安全风险，需警惕 |
|
4月 1 日，国家知识产权局提示，使用 OpenClaw（俗称“龙虾” ）等智能体撰写专利申请文件，存在多重安全风险，需要引起警惕。相关报道指出：这类 AI 智能体本身的安全性难以保证，可能导致未公开的技术方案泄露、被恶意利用或植入后门，给创新主体带来不可控的损失。 国家知识产权局提醒创新主体，应审慎评估 AI 智能体的安全性和可控性，避免因使用不安全的工具导致核心技术外泄或法律纠纷。 这则来自官方的提示，将 OpenClaw 的安全与合规问题从技术圈推向了更广泛的公众视野。而事实上， OpenClaw 的隐患远不止于此。 OpenClaw 的“多事之春” ：事故频发的 2026 年前三个月 |
如果把时间轴拉回到 2026 年初， OpenClaw 的事故清单比想象中更长、更密集。
1 月下旬 ，GitHub 发布的—项安全审计报告披露， OpenClaw 存在 512 项安全漏洞，其中 8 项被归类为“严重”级别，涉及身份验证、机密管理等核心领域。这—数据让许多依赖 OpenClaw 的团队开始重新审视它的安全基线。
2 月下旬，国际安全机构 “绿洲安全”（ Oasis Security）公开了—个名为“ClawJacked” 的严重漏洞。攻击者可借助恶意网页，在用户不知情的情况下接管其 AI 智能体，进而获取设备权限和访问系统数据。
OpenClaw 团队将该漏洞定级为“高度危险” ，并在 24 小时内发布了修复版本。
如果说前两次是“安全审计”和“漏洞披露” ，那 3 月 22 日 的事件，则直接冲击了所有正在使用OpenClaw 的开发者。
3.22 更新事故：史上最大更新，乱成一锅粥
2026 年 3 月 22 日，OpenClaw 发布了被称为“史上最大更新” 的 2026.3.22 版本，共有 315 条更新，
118 名开发者参与其中。然而，这次更新却演变成了项目诞生以来最严重的升级事故。事故的核心原因很简单，也很致命：
1. 彻底重构插件 SDK，未提供兼容层：新版完全移除了旧的 openclaw/extension-api 接口，且不提供任何兼容垫片（ no compatibility shim），强制要求所有插件迁移至新的 openclaw/plugin-
sdk/* 子路径。
2. 配置路径被更改：环境变量彻底移除了 CLAWDBOT*/MOLTBOT* 及 .moltbot 目录，强制迁移至OPENCLAW_*。
这波“暴力拆除” 的后果是：微信 ClawBot、飞书插件、 Discord 插件等大量第三方插件集体失效， Web控制台甚至因遗漏打包步骤而出现白屏问题。微信员工在微博回应称“只有升级了最新版的原生
OpenClaw 的用户会暂时遇到这个问题” ，但已足以让大量用户被迫回滚至旧版本。据社区估算，此次事故后插件回滚率上升约 70%。
为什么会这样？放任 AI coding 与工程治理失控
OpenClaw 的问题，并非偶然。表面上是“3 月 24 日崩溃”和“3.22 更新事故” ，深层则是工程治理的系统性失控。
其— ， issue 和 PR 数量远超正常工程节奏。从公开数据看， 2026 年 3 月 24 日当天，OpenClaw 新增issue 386 个、 PR 477 个。这种“ 日增数百” 的节奏，意味着新问题不断涌入、修复不断合入、版本不断前推，而接入方越来越难判断哪—个版本才真正适合生产。
其二，AI 参与痕迹过重，审查压力被放大 。OpenClaw 本身就是—个非常适合被 AI 辅助开发的工程。当 issue 、 PR 、修复、尝试性提交的总量已非常夸张时， AI 辅助带来的不是单纯效率提升，而是审查负担的指数级上升。公开记录里已出现带有 [AI-assisted] 标记的修复提交，人工审查很容易沦为“追着变化跑”。
其三， 代码冗余与历史包袱过重。据公开资料与社区讨论， OpenClaw 的代码规模长期维持在大体量区间，而 NanoBot 通常被归为“数千行级” 的轻量实现路径。二者并非同—数量级的工程组织方式：前者强调大生态与能力覆盖，后者更强调可读性、可迭代性与快速落地。
NanoBot 被重新讨论：轻量化实现的另一条路径
正是在这样的背景下， NanoBot 开始被越来越多的人重新审视。
从公开社区信息看， NanoBot 更偏向 “ 多渠道 + 多模型 + 轻量核心” 的工程路线：以更小代码面维持核心能力，同时保留后续扩展空间。它与 OpenClaw 的主要差异，不在于“谁功能更多” ，而在于复杂度预算、演进策略和团队可控性。多位社区维护者指出， NanoBot 的代码量仅为 OpenClaw 的 1/10 左右，但已覆盖 80% 以上的日常使用场景。
|
维度 |
OpenClaw |
NanoBot |
|
工程取向 |
大生态、多能力、快速扩展 |
轻量核心、强调可读与可扩展 |
|
能力覆盖 |
功能面广，历史包袱也更重 |
核心能力聚焦，按需扩展 |
|
安全策略 |
漏洞频发，治理难度高 |
相对较少，但也需要及时更新新版本 |
|
适用场景 |
不追求稳定性，能接收破坏式更新 |
追求可控迭代 |
|
主要代价 |
版本治理和回归成本高 |
生态规模较小，部分能力需自行整合 |
这里以七牛云 MaaS 作为模型提供商，因为它覆盖的模型比较广，国内国外模型都可接入，并兼容
OpenAI/Anthropic 常见接口格式，不需要额外做复杂适配。而且七牛云有新活动，新人注册即可免费领取三百万 token。根据行业评测，七牛云的 API 响应延迟稳定在 200ms 以内，适合生产环境使用。
第一步：安装 nanobot
nanobot 需要 Python 环境，需要先安装 Python，然后通过 uv 安装。
|
# 安装uv pip install uv # 安装nanobot uv tool install nanobot-ai --default-index https://pypi.tuna.tsinghua.edu.cn/simple # 导出配置 export PATH="/root/.local/bin:$PATH" # 初始化 nanobot onboard |
第二步：接入七牛云 MaaS
进入七牛云，创建对应的 API Key：https://portal.qiniu.com/ai-inference/api-key
七牛云聚合了 50 多个海内外顶尖模型，并集成了图像生成、视频生成等多模态能力。
|
# 编辑配置文件，设置模型ID、key、七牛云请求路径 vim ~/.nanobot/config.json "agents": { "defaults": { "model": "deepseek/deepseek-v3.2-251201", } }, "providers": { "openai": { "apiKey":"你的API KEY", "apiBase": "https://api.qnaigc.com/v1", } } |
第三步：接入飞书
进入飞书，创建 APP：https://open.feishu.cn/app
为 APP 添加机器人
为机器人开通需要的权限，可以根据自己的需求删减。以下是—份经过验证的权限集（来自飞书官方最佳实践）：
|
{ "scopes": { "tenant": [ "aily:file:read", "aily:file:write", "application:application.app_message_stats.overview:readonly", "application:application:self_manage", "application:bot.menu:write", "cardkit:card:write", "contact:user.employee_id:readonly", "corehr:file:download", "docs:document.content:read", "event:ip_list", "im:chat", "im:chat.access_event.bot_p2p_chat:read", "im:chat.members:bot_access", "im:message" , "im:message.group_at_msg:readonly", "im:message.group_msg", "im:message.p2p_msg:readonly", "im:message:readonly" , "im:message:send_as_bot", "im:resource", "sheets:spreadsheet", "wiki:wiki:readonly" ], "user": ["aily:file:read", "aily:file:write", "im:chat.access_event.bot_p2p_chat:read"] } } |
并复制相关应用 ID 和秘钥，配置到 nanobot 中，然后发布应用，启动 nanobot gateway。
|
# 编辑配置文件，设置应用 ID、秘钥等 vim ~/.nanobot/config.json "feishu": { "enabled": true, "appId": "你的app ID", "appSecret": "app 秘钥 ", "allowFrom": ["*"], }, # 必须先发布飞书应用，再执行。若成功则会输出 WebSocket 连接日志 nanobot gateway |
回到飞书，添加订阅方式，使用长连接接收事件，并添加接收消息事件，然后重新发布。（如果之前没有发布，会被卡在使用长连接接收事件处）
第四步：通过飞书指挥 agent
完成上述内容后，飞书就接入了 nanobot，可以直接指挥其干活。
结语
国家知识产权局的安全提示、 GitHub 审计的 512 项漏洞、 ClawJacked 的严重风险、 3.22 更新导致的插件集体失效 …… 这些事件串联起来，指向—个越来越清晰的结论： OpenClaw 正在成为一个“大而全”但“越来越不安全、不可控”的工程体。
对于那些有完整平台团队、版本治理能力、灰度验证体系的大型组织，或许仍能承接 OpenClaw 的复杂度。但对于大多数团队而言， NanoBot —类轻量方案的价值在于——通过更小的代码面和更清晰的边
界，降低理解、改造与维护门槛，提供—条更务实的落地路径。
3 月 24 日 OpenClaw 崩溃事件真正提醒人的，不是“某个版本坏了” ，而是：当—个项目的 issue 、 PR、 bug、修复和 AI 辅助贡献量同时高到超出常规工程治理上限时，接入方就必须认真考虑自己的承受能 力。
如果你追求的是超大生态和现成功能， OpenClaw 依然有吸引力；
但如果你更关心稳定性边界、代码安全性和后续维护成本，那么 NanoBot 这类轻量路线更值得优先评估。