OpenClaw 深度技术分析:安装、安全与最佳实践指南
OpenClaw 是什么
OpenClaw 是一个开源的、自托管的 AI 个人助手 Agent,运行在你自己的硬件上(笔记本、Mac Mini、VPS 等),并连接到你日常使用的消息平台——WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat 等。
它不是一个云端聊天机器人。它是一个完整的自主 Agent 运行时,能够代你执行操作:运行 Shell 命令、读写文件、控制浏览器、管理日历和邮件、发送消息、运行定时自动化任务。
简要历史
这个项目经历了多次更名:
- Clawdbot(最初名称)
- Moltbot(因商标问题更名)
- OpenClaw(2026 年 1 月至今的最终名称)
项目由 Peter Steinberger(GitHub: @steipete)创建,最初只是一个周末项目(”WhatsApp Relay”)。2026 年 2 月 14 日,Steinberger 宣布加入 OpenAI,OpenClaw 正在过渡为 OpenClaw Foundation,获得 OpenAI 的资金和技术支持。
核心数据
| 指标 | 数值 |
|---|---|
| GitHub Stars | ~219,000 |
| Forks | ~41,600 |
| 许可证 | MIT |
| 主要语言 | TypeScript |
| 运行时 | Node.js >= 22 |
| 创建时间 | 2025 年 11 月 24 日 |
技术架构解析
系统架构
OpenClaw 的核心是一个运行在本地的 WebSocket Gateway,监听 ws://127.0.0.1:18789。这个 Gateway 是整个系统的统一控制平面,负责协调以下组件:
┌─────────────────────────────────────────────────┐ │ OpenClaw Gateway │ │ ws://127.0.0.1:18789 │ ├──────────┬──────────┬──────────┬────────────────┤ │ Pi Agent │ Multi-Ch │ Web UI / │ Device Nodes │ │ Runtime │ Inbox │ Control │ (macOS/iOS/ │ │ (RPC) │ │ UI │ Android) │ ├──────────┴──────────┴──────────┴────────────────┤ │ Skills System │ Persistent Memory │ Cron │ │ (ClawHub) │ (Long-term ctx) │ Jobs │ └─────────────────┴─────────────────────┴─────────┘
技术栈
| 层级 | 技术 |
|---|---|
| 运行时 | Node.js >= 22, TypeScript, pnpm |
| 消息集成 | Baileys (WhatsApp), grammY (Telegram), discord.js, Bolt (Slack) |
| 语音 | ElevenLabs (TTS & 语音唤醒) |
| 浏览器自动化 | Chromium/Chrome (快照 + 操作) |
| LLM 后端 | 多供应商:Anthropic Claude、OpenAI 等,支持 API Key 或订阅 |
| 包管理 | pnpm (monorepo) |
Monorepo 结构
openclaw/ ├── .agent/workflows # Agent 自动化流程 ├── apps/ # 伴侣应用(macOS、iOS、Android) ├── packages/ # 核心库 ├── skills/ # 内置和托管 Skills ├── ui/ # 前端界面 ├── src/ # Gateway 和 Agent 实现 └── test/ # 测试基础设施
生态系统
OpenClaw 已经形成了一个庞大的生态:
- ClawHub (
openclaw/clawhub) — 社区 Skill 市场 - awesome-openclaw-skills — 精选 Skill 合集(18.3K Stars)
- nanobot (
HKUDS/nanobot) — 超轻量级 OpenClaw 变体(23.4K Stars) - moltworker (
cloudflare/moltworker) — 在 Cloudflare Workers 上运行(9.1K Stars) - secure-openclaw (
ComposioHQ/secure-openclaw) — 安全加固版 - OpenClawInstaller — 一键部署工具
本地安装详细指南
系统要求
| 要求 | 说明 |
|---|---|
| 操作系统 | macOS、Linux、或 Windows(通过 WSL2;不建议原生 Windows) |
| Node.js | >= 22 |
| 内存 | Gateway 本身至少 1 GB,建议 4 GB+ |
| 端口 | 18789(Control UI) |
| LLM 账户 | Anthropic Claude Pro/Max($20-$100/月)、OpenAI、或本地模型(Ollama) |
方法一:CLI 一键安装(推荐)
# macOS / Linux / WSL2
curl -fsSL https://openclaw.com/install.sh | bash
# Windows (PowerShell)
iwr -useb https://openclaw.com/install.ps1 | iex
方法二:NPM 全局安装
npm install -g openclaw@latest
openclaw onboard --install-daemon
方法三:Docker 部署(最佳隔离性)
git clone https://github.com/openclaw/openclaw.git
cd openclaw
./docker-setup.sh
安装后配置
安装完成后,运行 onboarding wizard:
openclaw onboard --install-daemon
向导会引导你完成:
- 安全警告确认 — 了解风险并确认
- 选择 Quick Start 模式
- 选择 LLM 模型提供商 — 配置 API Key 或登录
- 连接聊天平台 — 例如 Telegram 通过 BotFather、WhatsApp 通过扫码
- 配置 Agent 人设 — 名称、称呼方式等
--install-daemon将 OpenClaw 注册为后台服务(Linux 用 systemd,macOS 用 launchd)
验证安装
openclaw --version # 检查版本
openclaw gateway status # 检查 Gateway 状态
openclaw doctor # 运行诊断
托管选项
如果不想自己维护:
- DigitalOcean 1-Click Deploy — $24/月,安全加固版
- Oracle Cloud Free Tier — 4 ARM 核心、24 GB RAM、200 GB 存储,社区中广泛使用的免费方案
安全分析:不可忽视的风险
这是 OpenClaw 最值得关注的部分。 作为一个在短短数月内爆发式增长的项目,其安全历史可以用”惊心动魄”来形容。
已知 CVE 列表
| CVE 编号 | CVSS 评分 | 描述 | 状态 |
|---|---|---|---|
| CVE-2026-25157 | High | Gateway 漏洞 | 已修复 (v2026.1.25) |
| CVE-2026-25253 | 8.8 | 一键 RCE — Control UI 通过 gatewayUrl 查询参数泄露认证令牌 |
已修复 (v2026.1.29) |
| CVE-2026-24763 | High | Docker 沙箱绕过(上述修复不完整) | 已修复 (v2026.1.30) |
| CVE-2026-26322 | 7.6 | Gateway 工具中的 SSRF | 已披露 (Endor Labs) |
| CVE-2026-26319 | 7.5 | Telnyx Webhook 缺少认证 | 已披露 (Endor Labs) |
| CVE-2026-26329 | High | 浏览器上传中的路径遍历 | 已披露 (Endor Labs) |
| 其他 GHSA | Moderate-High | 图片工具 SSRF、Urbit 认证 SSRF、Twilio Webhook 认证绕过 | 已披露 (Endor Labs) |
暴露实例:触目惊心的数字
安全研究人员的发现令人震惊:
- 安全研究人员发现超过 42,000 个 OpenClaw 实例以不安全的默认配置暴露在公网上
- SecurityScorecard 后续发现超过 135,000 个互联网可达实例
- 其中超过 12,800 个可通过已修复的 RCE 漏洞直接利用
- 这些暴露的实例正在泄露 API Key、聊天记录和账户凭证
ClawHub 供应链攻击:”ClawHavoc” 事件
这可能是 OpenClaw 生态中最令人不安的安全事件。
- Koi Security 审计了 ClawHub 上全部 2,857 个 Skills,发现341 个恶意 Skills,其中 335 个追踪到同一组协调攻击(”ClawHavoc”)
- 随后恶意 Skills 数量增长至 824+
- 安全研究员 Paul McCarty 表示”在市场上看了不到两分钟就发现了恶意软件”
- 恶意 Skills 包含:加密货币窃取恶意软件、通过
curl外泄数据、直接 Prompt Injection 绕过安全准则、嵌入 bash 命令的命令注入
架构层面的根本性风险
根据 Cisco Talos、Kaspersky、Microsoft Defender、Giskard 等安全团队的分析:
OpenClaw 可以在宿主机上运行任意 Shell 命令、读写文件、执行脚本。这是其核心功能,但也是最大的攻击面。一旦 Agent 被 Prompt Injection 劫持,攻击者等同于获得了你机器上的 Shell 访问权限。
API Key、OAuth Token 和 Bot Token 以明文存储在 ~/.openclaw/ 目录下。这些凭证已成为 RedLine 和 Lumma 等信息窃取木马的目标。
Agent 处理的任何内容——邮件、Google Doc、Slack 消息、网页、文件元数据——都可能包含隐藏指令,劫持 Agent 行为。这不是理论风险,而是已经被验证的攻击向量。
一个用户/群组的对话和文件可能在另一个会话中重新出现。
在最近的 PR 之前,系统对插件注册、工具执行、配置修改或认证尝试完全没有审计跟踪。
创建者的态度转变
值得注意的是,OpenClaw 的创建者最初公开表示安全”不是他想要优先考虑的事情”(Aikido Security 引述)。The Register 甚至称其为”安全灾难”。
然而随着项目影响力的扩大,安全态度发生了转变:
- 安全研究员 Jamieson O’Reilly 加入担任首席安全顾问
- 添加了 VirusTotal 集成用于 Skill 扫描
- 移除了
gateway auth mode "none"选项,强制要求 Token/密码认证 - 正在开发:基于能力的 Skill 安全模型、HTTP API 安全钩子、HSTS 安全头、明文凭证检测、Agent 自主性控制和速率限制
企业级方案:OpenClaw on AWS with Bedrock
前面分析的安全问题——明文 API Key 存储、缺乏审计日志、端口暴露、凭证管理混乱——很大程度上源于 OpenClaw 的”本地优先”设计哲学。对于需要在生产环境中使用 OpenClaw 的团队,AWS 社区提供了一个值得关注的开源方案:sample-OpenClaw-on-AWS-with-Bedrock。
这个项目将 OpenClaw 部署到 AWS 基础设施上,用 Amazon Bedrock 替代多供应商 API Key 管理,从架构层面消除了多个安全隐患。
架构设计
Phone → WhatsApp/Telegram/Discord/Slack
│
▼
┌───────────────┐ VPC Endpoint ┌──────────────┐
│ EC2 Instance │ ──── (Private) ─────▶ │ Amazon │
│ (OpenClaw │ │ Bedrock │
│ Gateway) │ │ │
└───────────────┘ └──────────────┘
│ │
SSM Session CloudTrail
Manager (安全访问) (审计日志)
核心安全改进
这个方案对照 OpenClaw 原生部署的安全问题,做了针对性的改进:
| OpenClaw 原生问题 | AWS 方案解决方式 |
|---|---|
明文 API Key 存储于 ~/.openclaw/ |
IAM Role 自动认证,零 API Key 管理 |
| 缺乏审计日志 | CloudTrail 自动记录所有 Bedrock API 调用 |
| 端口 18789 暴露到公网 | VPC Endpoint 私有网络访问,Bedrock 流量不经过公网 |
| 需要 VPN/Tailscale 做远程访问 | SSM Session Manager 安全 Shell 访问,无需开放端口 |
| 多供应商 API Key 管理复杂 | Bedrock 统一接口,一个 IAM Role 访问 8+ 模型(Nova、Claude、DeepSeek、Llama) |
| 无原生费用控制 | AWS Cost Explorer 原生计费集成 |
部署方式
项目提供三种部署选项:
1. 标准 EC2 部署(推荐起步方案)
通过 CloudFormation 一键部署,约 8 分钟完成:
# 支持多区域:US West, US East, EU Ireland, Asia-Pacific Tokyo
# 提供 CloudFormation 模板:
# - clawdbot-bedrock.yaml (Linux)
# - clawdbot-bedrock-mac.yaml (macOS)
# - clawdbot-bedrock-agentcore.yaml (Serverless)
支持 x86(t3, c5)和 ARM/Graviton(t4g, c7g)实例,Graviton 可节省 20-40% 计算成本。
2. macOS 实例
适用于需要 iOS 开发/Xcode 工作流的场景。
3. Serverless(AgentCore Runtime)— 弹性负载场景
- 按需自动扩缩容,按使用计费
- 每次执行在隔离的 Firecracker microVM 中运行
- 相比常驻 EC2 预计节省 40-70% 计算成本
重要提示: AgentCore 方案存在显著的架构限制,请务必阅读下方”AgentCore 部署的注意事项”章节。
AgentCore 部署的注意事项
AgentCore Runtime 是这个项目中最具吸引力的选项(按需付费、自动扩缩容),但它与 OpenClaw 的架构之间存在根本性的匹配问题。在决定采用之前,你需要理解以下限制:
它并不能运行完整的 OpenClaw
这是最关键的一点:AgentCore Runtime 不运行完整的 OpenClaw 栈。实际的架构是将系统拆分为两部分:
┌─────────────────────────────────┐ ┌──────────────────────────────┐
│ EC2 实例(始终在线) │ │ AgentCore Runtime(按需启动) │
│ │ │ │
│ • OpenClaw Gateway │────▶│ • AI 推理循环 │
│ • 消息平台连接 │ │ • LLM 调用 (Bedrock) │
│ (WhatsApp/Telegram/Discord) │◀────│ • 工具执行 │
│ • WebSocket 控制平面 │ │ • 上下文组装 │
│ • 凭证存储 │ │ │
│ • 消息路由 │ │ 每次调用 → 新 microVM │
└─────────────────────────────────┘ └──────────────────────────────┘
始终运行 (~$35/月) 按使用计费(节省 AI 计算成本)
也就是说,你仍然需要一个 24/7 运行的 EC2 实例来承载 Gateway 和消息连接。AgentCore 只是将 AI 推理部分(调用 LLM、执行工具、组装上下文)从 EC2 卸载到 Serverless 环境中。
关键技术限制
AgentCore 的 microVM 具有严格的生命周期限制:
- 空闲超时: 默认 900 秒(15 分钟),最长可配置到 8 小时
- 最大生命周期: 默认 28,800 秒(8 小时),这是硬性上限
- 当超时触发时,整个 microVM 被终止,内存被清理
OpenClaw 的所有持久化状态(~/.openclaw/ 下的配置、凭证、会话记录、Skill 文件)在 microVM 终止时全部丢失。AgentCore Runtime 不支持持久化卷挂载。每次启动都是全新环境,必须从外部存储(AgentCore Memory、S3、DynamoDB)重新加载状态。
这是最脆弱的环节。Baileys 库使用 Signal Protocol 加密,认证状态以文件形式存储(creds.json + session-*.json)。在 ephemeral 环境中:
- 容器/microVM 重启 = 凭证丢失 = 需要重新扫描 QR 码
- 非正常关闭(空闲超时触发的强制终止)可能损坏 Signal Protocol 会话状态
- 即使使用外部存储(Redis、DynamoDB),Baileys 官方文档明确警告其内置的
useMultiFileAuthState“效率极低,纯粹用于演示目的”
这也是 AWS 参考架构将 WhatsApp 连接保留在 EC2 Gateway 上而非放入 AgentCore 的原因。
OpenClaw 的 Gateway 是一个 WebSocket 服务器,需要维持到 WhatsApp、Telegram、Discord 等平台的持久连接。AgentCore 的调用模型是请求-响应式的(HTTP /invocations 端点),不支持入站 WebSocket 监听。此外:
- Cold start 延迟(300-800ms)对实时消息不可接受
- 15 分钟空闲超时会杀死消息平台连接——而 WhatsApp 和 Discord 要求更短间隔的心跳
- 自动水平扩展会创建多个竞争的 Gateway 进程,破坏 OpenClaw 的单进程设计假设
AgentCore 不保证 HTTP 请求的粘性路由到同一容器实例。AWS 文档明确指出会话亲和性”只是优化,不是正确性机制”。OpenClaw 的浏览器自动化会话、文件操作上下文等依赖进程本地状态的工具,可能在 microVM 回收时中断。
何时适合使用 AgentCore
尽管有以上限制,AgentCore 在特定场景下仍然有价值:
| 适合 | 不适合 |
|---|---|
| AI 推理部分的弹性计费(高峰时段 burst) | 完整 OpenClaw 栈的 Serverless 化 |
| 定时任务/”心跳”工作负载(唤醒 → 执行 10 秒 → 终止) | 需要持久 WhatsApp/Discord 连接的场景 |
| 多用户共享 Agent 的会话隔离 | 需要进程本地状态的工具(浏览器自动化等) |
| 已经有 EC2 Gateway 作为前端的混合架构 | 想要完全消除常驻实例的纯 Serverless 部署 |
部署建议
如果你决定使用 AgentCore 方案:
- 先在纯 EC2 模式下验证 — 确保 OpenClaw 在标准 EC2 部署上正常工作后,再考虑将 AI 推理层迁移到 AgentCore
- 保留 EC2 Gateway — 不要尝试将 Gateway 和消息连接放入 AgentCore
- 将空闲超时设置为合理值 — 过短会导致频繁 cold start 和状态重建开销
- 为状态重建做好准备 — 所有会话上下文需要通过 AgentCore Memory 或 DynamoDB 持久化
- 监控 cold start 对用户体验的影响 — 在低流量时段,每次消息可能增加 300-800ms 延迟
🚀 想要完全 Serverless 的方案? 上述 AgentCore 混合架构仍然需要一个 EC2 实例来运行 Gateway。如果你希望完全消除常驻实例,可以参阅 Deploy OpenClaw on AWS with Amazon Bedrock AgentCore,该方案通过 Router Lambda + AgentCore Runtime 实现了无 EC2 的纯 Serverless 多用户部署。
成本估算
以 Graviton EC2(c7g.large)为例的月度基础设施成本:
| 项目 | 月费用 |
|---|---|
| EC2 c7g.large | $52.60 |
| EBS 存储 (30GB) | $2.40 |
| VPC Endpoints | $21.60 |
| 数据传输 | $5-10 |
| 基础设施小计 | ~$76-81 |
如果采用 AgentCore 混合架构,EC2 实例可以降级(只需运行 Gateway,不需要 AI 推理算力),但仍需要一个始终在线的实例。
LLM 推理成本方面,Bedrock 上的 Nova Lite 约 $0.01/请求,Nova Pro 定价 $0.80/$3.20 per 1M tokens,比直接订阅 Claude Pro($20/月)更灵活——适合用量波动较大的场景。
模型灵活性
通过 Bedrock 统一接口,无需修改代码即可在以下模型之间切换:
- Amazon Nova (Lite / Pro)
- Anthropic Claude (Sonnet / Haiku / Opus)
- Meta Llama
- DeepSeek
这消除了对单一 LLM 供应商的锁定,也让你可以根据任务复杂度选择合适的模型——简单消息路由用 Nova Lite 降低成本,复杂推理用 Claude Opus 保证质量。
与本地部署的权衡
AWS 方案并非没有取舍:
| 优势 | 劣势 |
|---|---|
| 企业级安全(IAM、VPC、审计) | 需要 AWS 账户和基础 AWS 知识 |
| 无需管理 LLM API Key | 基础设施成本(~$76-81/月起步) |
| 内置合规审计能力 | 对 AWS 服务产生依赖 |
| 一键 CloudFormation 部署 | 数据经过 AWS 基础设施,需信任云供应商 |
| 多模型按需切换 | 不适合纯离线/air-gapped 场景 |
| AgentCore 弹性计费(混合架构) | AgentCore 无法运行完整 OpenClaw 栈,仍需 EC2 |
对于企业用户或对安全有较高要求的个人开发者,标准 EC2 + Bedrock 方案是目前最成熟的 OpenClaw 生产部署路径。 AgentCore 混合架构适合高级用户在验证 EC2 部署稳定后进一步优化成本,但不建议作为起步方案。
社区评价与使用体验
正面评价
OpenClaw 在社区中获得了大量积极反馈:
- 被多位评论者描述为”自 Claude Code 以来最令人印象深刻的技术”
- 用户报告在几天内清理了数千封邮件、从手机上部署代码、通过 Telegram 消息运行整个业务
- Codecademy 发布了完整教程;YouTube 频道 ProgrammingKnowledge 发布了演练视频
- 一位用户通过 Telegram 聊天构建了一个完整的 iOS 应用(包含地图和录音功能),并部署到 TestFlight
awesome-openclaw-usecases仓库展示了大量实际用例:PR Review Bot、早间简报自动化、CLI 工具构建器、完整应用开发- 一位 LinkedIn 评论者称之为”AI 作为队友,而非工具。数字员工的终局就在这里。”
负面评价
批评同样尖锐:
- Hacker News 评论称其为”最无意义的 vibecoded slop”,质疑它是真正的智能还是”简单的自动化”
- 多位评论者指出它”感觉像一个粗糙的 MVP”,并且”第一次接触时令人生畏”
- The Register 在安全方面称其为”dumpster fire”
- Aikido Security 指出它”从未以安全为目标而构建”——创建者”在一个周末就做出了 OpenClaw”,”发布时并未考虑安全问题”
典型使用场景
根据社区分享,以下是 OpenClaw 最受欢迎的使用场景:
- 邮件和消息管理 — 自动分类、总结、回复草稿
- 代码开发辅助 — 从 Telegram/WhatsApp 指挥代码修改和部署
- 日常自动化 — 早间简报、日程管理、提醒
- 研究和总结 — 网页抓取、文档分析、信息整理
- 文件操作 — 批量处理、格式转换、数据提取
我的观察
OpenClaw 本质上是一个”便利性与安全性的权衡”。它的能力确实令人印象深刻——从消息平台远程控制一台拥有完整开发环境的机器,这在概念上是革命性的。但这种能力正是它的阿喀琉斯之踵:任何能够影响 Agent 输入的人或内容,都可能控制你的机器。
最佳实践:安全使用 OpenClaw 的 20 条建议
以下建议综合了 Auth0、Microsoft、Kaspersky、DigitalOcean 和社区安全指南:
网络与基础设施
将 Gateway 绑定到 127.0.0.1。这是最基本也是最关键的一步。
# 使用 Tailscale Serve 暴露
tailscale serve --bg 18789
# 或使用 SSH 隧道
ssh -L 18789:127.0.0.1:18789 user@your-server
使用专用 VM、容器或独立物理设备。将运行环境视为可丢弃的。
Docker 提供最佳隔离性。但注意:不要挂载 Docker Socket 或整个 home 目录。
确保使用 Node.js v22.12.0+(修复了 CVE-2026-21636)。
认证与凭证
使用 Token 或密码,永远不要在无认证模式下运行。
永远不要连接你的主要工作账户或个人账户。创建专用的 bot 账户。
~/.openclaw/credentials/
默认的明文存储是已知的攻击目标。使用系统钥匙链集成或 Secrets Manager。
# 检查凭证文件
ls -la ~/.openclaw/credentials/
# 确保文件权限至少为 600
chmod 600 ~/.openclaw/credentials/*
对所有 SaaS 集成,尽可能使用 OAuth 短期令牌。
在所有 LLM 提供商账户上设置消费上限,防止 Agent 失控循环导致账单飙升。
Skills 与插件
不要信任未经审查的社区 Skills。记住:824+ 个恶意 Skills 已被发现。
curl | bash 的 Skills
这是主要的恶意软件分发机制。任何要求下载外部二进制文件的 Skill 都应该被视为可疑。
调查显示 7.1% 的被调查 Skills 存在凭证泄露行为。
# 在安装前检查 Skill 源码
openclaw skill inspect <skill-name>
廉价模型更容易受到 Prompt Injection 攻击。Claude Opus/Sonnet 或 GPT-4 级别模型在抵抗注入攻击方面表现更好。
运营安全
配置命令白名单、文件系统白名单、集成白名单和网络白名单。
# 示例配置
security:
command_allowlist:
- git
- npm
- node
filesystem_allowlist:
- /home/user/projects
require_confirmation:
- file_delete
- permission_change
- credential_handling
文件删除、权限变更、SSH/Git 配置修改、凭证处理都应该需要人工确认。
在开放访问之前使用配对/审批流程。
openclaw doctor openclaw doctor
# 检查所有已知安全配置问题
openclaw security audit
# 检测错误配置和已知漏洞
一个被攻破的个人频道不应该能够横向移动到业务系统。
附加建议
- 保持 OpenClaw 更新 — 项目对关键 CVE 的修复通常在 24-48 小时内发布
- 如果无法承诺持续的安全维护,考虑托管方案(如 DigitalOcean 1-Click Deploy)
- 对安全要求较高的场景,考虑 AWS 原生部署 — sample-OpenClaw-on-AWS-with-Bedrock 方案通过 IAM、VPC Endpoint 和 CloudTrail 从架构层面解决了 API Key 明文存储、端口暴露和审计缺失等问题
- 参考 Microsoft Defender 的建议:仅在”不包含任何非专用凭证的隔离环境”中运行 OpenClaw
总结与建议
OpenClaw 适合谁?
| 适合 | 不适合 |
|---|---|
| 有 DevOps/安全背景的个人开发者 | 不熟悉服务器管理的非技术用户 |
| 在隔离环境中的实验性使用 | 直接连接到生产系统 |
| 有安全意识并愿意持续维护的用户 | 安装后不再关注的”set and forget”用户 |
| 自动化重复性开发任务 | 处理高敏感数据(医疗、金融) |
最终评估
OpenClaw 代表了 AI Agent 领域一个令人兴奋但仍处于早期阶段的方向。它的 219K Stars 证明了社区对”自托管 AI 助手”这一概念的强烈需求。但它的安全历史——6+ 个 CVE、135,000+ 暴露实例、824+ 恶意 Skills——清楚地表明:这是一个需要你主动承担安全责任的工具。
如果你决定使用 OpenClaw,请:
- 在隔离环境中运行,不要在有重要数据的机器上直接部署
- 遵循上述安全最佳实践,特别是网络隔离和凭证管理
- 持续关注安全更新,这个项目的安全态势正在快速演进
- 不要盲目信任 ClawHub Skills,每一个都应该视为潜在的供应链攻击载体
- 如果面向企业或生产场景,优先评估 AWS 原生部署方案,用 IAM + VPC + CloudTrail 替代 OpenClaw 原生的脆弱安全层
OpenClaw 的力量是真实的。但正如 Spider-Man 的叔叔所说——能力越大,责任越大。在 AI Agent 的世界里,这份责任主要落在你自己身上。
本文基于截至 2026 年 2 月的公开信息撰写。OpenClaw 项目正在快速发展,安全态势可能已有变化。请以官方仓库和安全公告为准。
参考来源:
- OpenClaw GitHub
- sample-OpenClaw-on-AWS-with-Bedrock — AWS 原生部署方案
- Aikido Security、SecurityScorecard、Endor Labs、Koi Security — 安全研究报告
- Cisco Talos、Microsoft Defender、Kaspersky — 威胁分析
- The Register、Hacker News — 社区讨论
Related Posts
- How I Actually Use OpenClaw
- How I Built Two AI Agents That Talk to Each Other
- Deploy OpenClaw on AWS with AgentCore
- OpenFang on AWS