从零实现 OpenClaw (0)：为什么OpenClaw会火？当AI成为操作系统，而非应用

Wu_Dylan

747人浏览 · 2026-03-03 17:33:37

Wu_Dylan · 2026-03-03 17:33:37 发布

一、现象：为什么开发者突然"上头"

2025年11月，奥地利开发者Peter Steinberger将首个commit推至GitHub时，项目还叫"Molty"（一只太空龙虾）。三个月后，这个更名为OpenClaw的项目以每天数千star的速度增长，截至2026年3月初，已成为GitHub开发者工具类别中增长最快的非聚合类项目。

真实的用户行为更能说明问题。Discord社区凌晨2点仍有300+在线用户，讨论的不是安装问题，而是生产环境调优；X（Twitter）上的使用截图显示，有人在WhatsApp里用它调试代码，有人在Telegram里管理智能家居，还有人在树莓派上跑7×24小时值班。

这不是"又一个AI玩具"的短暂热度。观察这些用户，你会发现两个共性：

第一，他们在真实工作流中使用。 不是尝鲜后丢弃，而是替代了部分原有工具：独立开发者用它管理知识库和代码审查，小团队用它做客服自动化，甚至有公司将其部署为"数字员工"处理理赔、排期、数据录入。

第二，他们选择本地而非云端。 所有推理、记忆、工具执行发生在用户自己的机器上，数据不出本地网络。这与2025-2026年AI领域"云端能力过剩但隐私焦虑同步增长"的悖论直接相关。

OpenClaw的爆发，本质是开发者对"AI基础设施"的投票——不是想要更聪明的模型，而是想把已有的聪明模型，真正嵌入到日常工作流中。

二、本质：Agent操作系统的三大设计哲学

将OpenClaw归类为"Agent框架"是常见误解。框架提供API供你编排，而OpenClaw提供的是运行环境：内存管理、进程调度、权限控制、持久化存储、后台任务、沙箱隔离——这些操作系统级能力已内置，你只需定义Agent的"灵魂"和"技能"。

这一设计体现在三个核心哲学：

哲学1：本地优先 = 数据主权

云端Agent的悖论在于：你越依赖它处理敏感事务，越需要将数据上传至不可控的第三方服务器。OpenClaw的默认架构是单进程本地运行，Gateway监听ws://127.0.0.1:18789，所有外部通道（WhatsApp/Telegram/Discord等20+平台）先接入Gateway，再路由至本地Agent。

模型可接OpenAI/Anthropic，也可接本地Qwen/DeepSeek/Llama。关键设计：无论模型在哪里，上下文组装、工具执行、记忆存储始终在本地完成。这对处理代码、财务、医疗等敏感场景的用户是决定性因素。

哲学2：消息原生 = 零UI成本

传统AI应用要求用户学习新界面、记住新App、适应新交互范式。OpenClaw的逆向思维是：用户已经在聊天软件里，Agent应该去那里找他们。

Gateway的通道适配器架构将Agent能力"翻译"为各平台的原生消息格式。你在WhatsApp里发的文字、在Telegram里传的图片、在Discord里@它的指令，对Agent而言是统一的消息流。用户零学习成本，Agent获得自然的多模态输入。

哲学3：资源抽象 = 可迁移性

这是OpenClaw最优雅的设计。每个Agent是一个文件系统资源，通常位于~/.openclaw/workspace/xxx/：

workspace/
├── SOUL.md          # 人格设定（系统提示词）
├── SKILL_*.md       # 技能元数据（自然语言描述，非代码）
├── MEMORY.sqlite    # 结构化长期记忆
└── daily-logs/      # 自动压缩的会话历史

Agent-as-Resource意味着：你可以git clone这个目录到新机器，Agent立即恢复全部记忆和能力；可以版本控制人格演进；可以在团队内分发"预配置Agent"。这与云端Agent的"黑箱状态"形成鲜明对比。

三、架构：一张图看懂OpenClaw

OpenClaw的架构可概括为三层：

┌─────────────────────────────────────────┐
│           Channels（通道层）              │
│  WhatsApp / Telegram / Discord / Feishu │
│  统一消息格式 → Gateway                   │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│          Gateway（控制平面）              │
│  WebSocket路由 · 会话管理 · 权限校验      │
│  Heartbeat调度 · 流式输出 · 远程访问      │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│        Pi Agent Runtime（执行引擎）       │
│  上下文组装 → LLM推理 → 工具拦截执行      │
│  自动重试 · 上下文压缩 · 模型降级         │
└─────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────┐
│      Agent Resource（资源抽象层）          │
│  SOUL人格 · SKILL技能 · MEMORY记忆        │
│  文件系统持久化 · 版本可控 · 可迁移        │
└─────────────────────────────────────────┘

关键原则：Gateway只是控制平面，产品形态是Agent本身。官方文档对此有明确界定："The Gateway is just the control plane — the product is the assistant."

后续12篇将逐层拆解这个架构，每篇提供可运行的代码实现。

四、这个系列能给你什么

本系列提供三条渐进路径，你可以根据需求选择跟随：

路径A：从零构建（第2-9篇）

适合想深入理解Agent操作系统的开发者。从200行Python的最小Loop开始，逐步添加工具调用、记忆持久化、网关路由、主动任务，最终得到一个生产级原型。无需预先安装OpenClaw，每篇提供独立可运行的代码。

路径B：科研实战（第12篇）

适合AI研究者。直接跳到终篇，看如何将OpenClaw改造为CV科研助手，实现文献管理-实验跟踪-论文写作的闭环。提供完整Skill代码仓库，支持Qwen-VL多模态理解。

路径C：企业部署（第10-11篇）

适合需要安全合规的团队。聚焦Docker沙箱、网络隔离、多Agent协作、审计日志，提供可直接用于内部服务器的部署方案。

五、系列路线图

篇目	核心目标	交付物
1	架构总览与路径选择	本文 + 架构图
2	最小Agent Loop	200行Python可运行原型
3	工具抽象与函数调用	浏览器/文件操作Skill
4	Gateway消息总线	WebSocket路由实现
5	持久化上下文	Session + SQLite方案
6	多平台接入	Telegram/微信适配器
7	人格与技能系统	SOUL.md + SKILL.md规范
8	主动任务调度	Heartbeat + Cron机制
9	生产级韧性	WAL日志 + 重试 + 并发控制
10	安全与沙箱	Docker隔离 + 零信任网络
11	多Agent协作	社区协议（MCP/A2A）对接
12	科研Agent实战	CV文献闭环系统（SaaS原型）