Brand LogoBrand Logo (Dark)
首页智能体广场工具包广场GitHub 精选提交智能体博客

分类

  • AI 绘画
  • AI 音频
  • 自动化工具
  • 聊天机器人
  • 编程工具
  • 金融工具

分类

  • 大语言模型
  • 营销工具
  • 零代码/低代码
  • 研究与搜索
  • 视频与动画
  • 视频编辑

GitHub 精选

  • DeerFlow — 字节跳动开源超级智能体框架

最新博客

  • OpenClaw vs Composer 2 Which AI Assistant Delivers More Value
  • Google AI Studio vs Anthropic Console
  • Stitch 2.0 vs Lovable Which AI Design Tool Wins in 2026
  • Monetizing AI for Solopreneurs and Small Teams in 2026
  • OpenClaw vs MiniMax Which AI Assistant Wins in 2026

最新博客

  • OpenClaw vs KiloClaw Is Self-Hosting Still Better
  • OpenClaw vs Kimi Claw
  • GPT-5.4 vs Gemini 3.1 Pro
  • Farewell to Bloomberg Terminal as Perplexity Computer AI Redefines Finance
  • Best Practices for OpenClaw
LinkStartAI© 2026 LinkstartAI. 版权所有。
联系我们关于
  1. 首页
  2. GitHub 精选
  3. OpenClaw
OpenClaw logo

OpenClaw

基于 TypeScript 和 MCP 协议的自托管 AI 助手,通过 Gateway 架构统一接入 WhatsApp、Telegram、Slack 等消息平台,内置文件驱动记忆系统与 5000+ 可扩展技能
25.1kTypeScriptMIT License
#个人ai助手#自托管#多平台集成#记忆系统#ai-agent
#langchain平替
#autogpt平替
#消息机器人
#技能扩展
#docker部署
#本地优先
#跨平台

项目简介

OpenClaw 是一个完全自托管的个人 AI 助手框架,核心理念是将数据主权交还给用户,与依赖云端的 AutoGPT 或需要复杂抽象的 LangChain 不同,OpenClaw 通过本地优先架构确保所有对话、记忆和工作流都存储在用户自己的设备上。Gateway 控制平面充当统一枢纽,将来自 WhatsApp、Telegram、Discord、Slack 等不同消息平台的请求路由到对应的 Agent Runtime 进行处理,每个对话会话都维护在独立的 SQLite 数据库中,结合 Markdown 日志文件和向量检索实现持久化记忆。技术栈以 TypeScript 为核心(占比约 84%),配合 Swift 和 Kotlin 分别构建 iOS 与 Android 原生应用,整个项目采用 pnpm monorepo 管理数十万行代码。部署方式支持 Docker Compose 一键启动,但需要手动配置模型供应商 API 密钥、消息平台 OAuth 认证以及工具权限策略。最大亮点是 ClawHub 技能注册表,提供超过 5000 个社区贡献的技能包,涵盖网页搜索、图像生成、日历同步、代码执行等能力,通过 MCP 原生协议实现标准化集成。

痛点 vs 创新

✕传统痛点✓创新方案
传统云端 AI 助手将全部对话和工作流存放在第三方服务器上,用户很难做到真正的本地隐私控制和数据可迁移OpenClaw 采用本地优先的存储和执行模型,会话、记忆和向量索引全部落在 SQLite 与 Markdown 文件上,配合 Docker 实现跨平台一致性
以 AutoGPT 为代表的自主代理框架过度依赖开放式试错循环,任务容易陷入无限自我反思和无意义工具调用中执行循环以固定迭代上限和工具使用策略为核心,为每一步推理显式设定目标,从设计上避免 AutoGPT 式的无限循环和成本失控
LangChain 的链式抽象层级复杂,企业在落地时需要维护大量胶水代码和观测基础设施才能排障通过 Model Context Protocol 替代厚重的链式抽象,工具层以标准化 JSON 能力描述为边界,使技能扩展更接近 Unix 风格的小而专一组件
多数 AI 助手只支持单一入口,用户需要在不同 App 间来回切换才能访问自己的多套助手配置Gateway 统一路由层将 WhatsApp、Telegram、Discord、Slack 等多平台会话汇聚到同一 Agent 实例,真正做到“任何平台,同一大脑”

架构深度解析

Gateway 控制平面与多会话隔离
Gateway 是整个系统的中枢,负责管理来自 WhatsApp、Telegram、Discord、Slack 等不同渠道的连接请求并路由到对应的 Agent Runtime。每个用户会话维护独立的状态容器,包括专属 SQLite 数据库(存储对话历史和向量索引)以及按日期归档的 Markdown 日志文件。这样的设计在保证水平扩展能力的同时,将不同会话的上下文彻底隔离,避免信息侧漏。Gateway 通过 WebSocket 长连接和类型化 JSON 协议传递请求、事件和流式响应,CLI 客户端和 Web UI 都可以实时消费同一事件流。
文件驱动的混合记忆检索层
OpenClaw 以文件系统作为记忆的单一真实来源,将短期记忆写入每日 Markdown 日志,将长期知识固化为语义化文档,如 identity、preferences 等核心文件。检索层在 SQLite 上同时启用 FTS5 全文索引与向量扩展插件,通过 BM25 关键词得分与嵌入向量相似度的加权融合返回候选记忆片段。为控制嵌入成本,系统对文本块计算 SHA-256 哈希,仅对新增或变更内容调用模型生成向量,并支持在本地 Ollama、OpenAI、Gemini 等供应商之间切换。整个记忆流水线在启动时预加载最近两天的日志以构建运行时上下文窗口,再按需增量更新,兼顾延迟与一致性。
工具执行与 Docker 沙箱安全层
工具执行层围绕 Model Context Protocol 构建,将每个技能抽象为声明式 JSON 能力描述,并通过工具白名单和黑名单组合进行授权控制。运行时在收到 Agent 发起的工具调用请求时会先在配置中检查 agents.list[].tools.allow 以及 sandbox 工具允许列表,并校验命令是否包含重定向、子 Shell、管道链式执行等高危模式。被允许的调用会在隔离的 Docker 容器中执行,容器默认使用无网络模式并仅挂载显式声明的工作目录,避免越权访问宿主机资源。工具执行结果以流式形式回传到主进程并注入后续模型上下文中,形成「观察–思考–行动」的闭环。

部署指南

1. 安装 Docker 与 Node.js(建议 Node.js 22 或以上),然后克隆官方仓库到本地

bash
1git clone https://github.com/openclaw/openclaw.git && cd openclaw

2. 运行官方提供的 Docker 安装脚本,启动交互式向导配置模型供应商 API 密钥、默认模型以及本地或云端嵌入服务

bash
1./docker-setup.sh

3. 在提示下为 WhatsApp、Telegram、Discord、Slack 等渠道配置 Bot Token 或 OAuth 凭据,并写入 openclaw.json 配置文件

bash
1nano ~/.openclaw/openclaw.json

4. 使用 Docker Compose 构建镜像并启动 Gateway 与 Agent Runtime 服务,首次启动会自动初始化 SQLite 数据库和内置记忆目录

bash
1docker compose up -d

5. 通过 CLI 或 Web UI 连接运行中的 Gateway,创建第一个个人 Agent,并用 npx clawhub@latest install 安装常用技能如网页搜索、日历同步等

bash
1npx clawhub@latest install web-search

落地场景

核心场景目标人群解决方案最终收益
个人知识管理自动化需要跨平台同步笔记的知识工作者通过 WhatsApp 语音输入会议纪要后由 Agent 自动整理为结构化 Markdown 并同步到 Obsidian 笔记库消除手动转录时间并利用记忆系统自动关联历史项目上下文提升检索效率
多渠道客户支持代理想要统一客服体验的小型电商团队在 Telegram、Discord、Slack 配置同一 Agent 实例让客户无论从哪个渠道咨询都能获得一致的产品推荐与订单查询将人工响应时间减少约 60% 并借助持久化记忆识别回头客提供更个性化话术
开发环境自动化运维负责频繁部署和排障的后端工程师通过聊天指令触发 Agent 执行 Docker 容器重启、日志分析与数据库备份等运维脚本在不离开消息界面的前提下完成约 80% 日常运维任务且沙箱隔离降低误操作对生产环境的影响

避坑指南

避坑指南
  • ClawHub 技能注册表存在供应链安全风险,2026 年初出现多起恶意技能伪装为行情监控或钱包工具窃取用户私钥的事件,安装前必须核查作者信誉并在沙箱环境中先行测试
  • Docker 沙箱的多层权限配置较为复杂,新手常遇到默认 network: none 导致联网工具全部失效、环境变量无法正确传入容器以及文件路径预校验误拦合法挂载目录等问题
  • 内置 Cron 定时任务在长时间运行和容器重启场景下可靠性有限,社区反馈周期任务偶发性不执行且缺乏结构化告警,许多团队选择配合 n8n 或系统级调度器来接管关键任务
  • Agent 一旦被授予过高系统权限,错误配置可能导致删除生产文件或泄露敏感环境变量,因此推荐将高危工具限定在专用开发容器或只读文件系统中运行
  • 官方 Subreddit 与 Discord 中存在大量营销和低质量自动回复,真实的故障分析和架构讨论被淹没,新手排障需要投入不少时间筛选噪音内容
  • 相比 LangChain 等框架,当前缺乏类似 LangSmith 的端到端可观测性组件,无法在图形界面中完整回放推理链路和工具调用成本,这在企业级落地时会增加运维难度

常见问题

OpenClaw 与 AutoGPT 在任务执行可靠性和成本上的差异有多大?▾
社区基准表明,在单轮数据分析和多步研究任务中,传统 AutoGPT 流派往往依赖长链自我反思和暴力搜索,成功率常低于 70%,且容易触发数十次甚至上百次 API 调用。OpenClaw 通过在执行循环中预设固定迭代上限、显式工具目标和中间检查点,将多步任务压缩为有限次数的高价值调用,复杂任务的成功率可以稳定在 85% 左右。实践中,同一份 CSV 分析任务 AutoGPT 可能消耗几十万 tokens,而 OpenClaw 借助本地记忆和精简工具调用通常只需不到十分之一的 token 成本。对于自建用户来说,这种差异直接体现在每月云端模型账单上,长时间运行的个人助手尤其明显。
为什么说 OpenClaw 更适合作为 LangChain 的平替而不是补充组件?▾
LangChain 的定位更偏向通用 LLM 编排框架,本身不直接关心长期运行的个人 Agent 形态,也不提供原生的多渠道入口与记忆结构约束。OpenClaw 在架构上从“单一长期 Agent”出发设计了 Gateway、多会话隔离和文件驱动记忆系统,使其在个人场景中可以独立承担对话、检索与执行链路,而不是被嵌入到外部应用。更重要的是,OpenClaw 基于 Model Context Protocol 实现工具层抽象,这与 LangChain 针对 Python 生态的链式封装哲学不同,二者在相同项目中并存往往会引入两套完全不同的调试与监控体系。对于希望自托管个人助手的用户来说,以 OpenClaw 为主干、按需调用后端向量库或函数调用库,比在现有 LangChain 项目上“外挂一个助手模式”更干净。
ClawHub 技能供应链攻击事件之后应如何安全使用社区技能?▾
ClawHub 事件暴露出技能层是 OpenClaw 攻击面最大的部分之一,特别是包含 Bash 或网络访问能力的技能。安全策略上,一是只安装在 GitHub 上有长期维护记录且在生产环境被广泛引用的高星技能,避免盲目尝试新账号提交的敏感类别技能。二是在安装到主实例前,先在隔离容器中启用最高日志级别运行技能,观察其是否访问异常域名或扫描本地文件系统。三是充分利用 OpenClaw 的工具白名单与路径前缀限制,为高风险技能单独分配只读目录与无网络沙箱,将可能的泄露面控制在极小范围内。对于涉及私钥、密码库或财务数据的任务,强烈建议自己编写最小可信工具而不是依赖第三方技能。
为什么社区建议不要把确定性定时任务完全交给 OpenClaw?▾
OpenClaw 的内置 Cron 机制本质上是运行在 Node.js 进程中的轻量调度器,在容器重启、宿主机休眠或时钟漂移等场景下,无法做到像系统级 Cron 那样严格保障任务触发。实际反馈包括:某些每日汇总任务会在容器滚动升级后静默失效,以及长时间高负载运行后调度线程被阻塞导致任务延迟数十分钟以上。这些问题对“容错性强、对时间点不敏感”的任务影响有限,例如早晚总结、每日回顾等,却会对账单拉取或自动转账一类任务造成严重后果。基于这些教训,社区逐渐形成了共识:让 n8n、Airflow 或系统 Cron 负责精确调度,而让 OpenClaw 只在被触发时承担智能决策与内容生成。
在多渠道接入场景下 OpenClaw 如何保证会话上下文的一致性?▾
OpenClaw 的 Gateway 将所有渠道抽象为统一的会话标识,背后指向同一套 SQLite 数据库和文件型记忆空间,实现了“多入口,同状态”的语义。无论用户从 WhatsApp 还是 Discord 发起对话,请求最终都会路由到同一个 Agent,读取相同的身份定义、长期偏好和历史对话记录,从而避免出现“不同平台上的助手记忆完全不同”的割裂体验。技术上,Gateway 使用统一的事件总线处理来自各渠道的消息并为每条消息打上会话主键和来源标签,后续记忆写入和检索始终围绕该主键展开。这样设计的副作用是配置初期略微复杂,但换来的是长期运行时极高的一致性和可迁移性,用户迁移消息平台时无需重新训练或导入记忆。
OpenClaw 与 n8n、Zapier 这类自动化工具在技术定位上有什么本质区别?▾
n8n 和 Zapier 代表的是确定性工作流自动化,核心是由人类提前绘制出“如果发生 A 就执行 B、C、D”的流程图,每一步的输入输出完全可预测,更多是在替代手动点击和 API 调用。OpenClaw 则是围绕 LLM 的不确定性推理能力构建的智能代理,更关注在信息不完全的场景下如何拆解目标、规划步骤并实时选择合适工具完成任务。实践中,二者最理想的组合方式是:使用 n8n 负责精确调度和系统集成,当流程中的某个节点需要开放式决策或语义理解时将上下文交给 OpenClaw,再把结果回写到后续节点。这样既可以保留 n8n 在可观测性和重放上的优势,又能利用 OpenClaw 为流程插入“会思考”的环节。
在 GitHub 上查看

项目指标

Star 数25.1 k
编程语言TypeScript
开源协议MIT License
部署难度中等

Table of Contents

  1. 01项目简介
  2. 02痛点 vs 创新
  3. 03架构深度解析
  4. 04部署指南
  5. 05落地场景
  6. 06避坑指南
  7. 07常见问题

相关项目

nanobot
nanobot
22.5 k·Python
CoPaw
CoPaw
1.1 k·Python
DeerFlow — 字节跳动开源超级智能体框架
DeerFlow — 字节跳动开源超级智能体框架
26.1 k·Python
gstack
gstack
0·TypeScript