zclaw

你正在厨房炒菜，手上沾满了油渍，突然想起今天有没有雨——这时候你对着灶台边的电路板说了一句「今天天气怎么样」，一个沉稳的男声从旁边的小音箱里传出来：「今天多云，最高气温 26 度，不用带伞。」

这一幕不是科幻电影，而是真实发生在一个叫 zclaw 的开源项目上。作者用一块 12 块钱的 ESP32-C3 开发板，加上大约 888 KiB 的固件，就做出了这样一个永远在线、随叫随到的微型 AI 助手。

它从哪里来？

zclaw 的作者是 GitHub 用户 tnm，项目的核心理念非常明确：在极端受限的嵌入式硬件上实现完整的 AI 个人助理。和大多数 AI 项目追求更大模型、更多参数不同，zclaw 选择做减法——它不跑任何本地模型，而是作为 LLM（大语言模型）与物理世界之间的「翻译层」和「执行层」。

你可以把它理解成给 ESP32 写的「AI 外壳」：硬件负责感知和控制（GPIO、传感器、继电器），LLM 负责理解和对话，两者通过自然语言指令连接在一起。项目采用了 ESP-IDF v5.4 作为底层框架，完全用 C 语言编写，目标芯片覆盖 ESP32、ESP32-C3、ESP32-S3、ESP32-C6 全系列。

图1：zclaw 项目作者头像

888 KiB 的「魔法」是怎么做到的？

理解这个数字的意义很重要：888 KiB 不是某个函数库的压缩体积，而是整个固件镜像的完整大小——包括 ESP-IDF 运行时、Wi-Fi 协议栈、TLS 加密层、数字证书包，再加上 zclaw 自己的应用逻辑，全部加在一起还不到 1 MB。

项目的 size breakdown 非常有意思：zclaw 应用本身只占 ~38 KiB（4.6%），真正的体积大户是 Wi-Fi + 网络协议栈（~370 KiB，占 44%）和 TLS 加密层（~132 KiB，占 16%）。这说明对于一个需要联网的嵌入式设备来说，安全通信的开销远大于业务逻辑本身。

有意思的是，整个固件还有约 55 KiB 的预留空间，说明作者的「888 KiB 上限」设置得比较保守，给了后续功能扩展的余地。

它能做什么？

zclaw 提供的功能可以分为三类：对话、感知、执行。

对话通道方面，支持三种交互方式：

• Telegram 机器人（推荐方式）：在 Telegram 中和设备对话，延迟低、体验好，支持对话历史和群组白名单
• Hosted Web Relay：通过 scripts/web-relay.sh 启动一个云端中继服务，适合没有公网 IP 的家庭网络用户
• USB 串口本地管理控制台：硬件还没联网时也能通过串口直接发指令（/wifi scan、/gpio all、/diag 等）

定时任务系统是 zclaw 的一大亮点。它内置了类似 cron 的调度器，支持三种调度模式：daily（每天固定时间）、periodic（周期重复）、once（一次性定时）。比如你可以设置「每天早上 7 点播报天气」，或者「每隔 30 分钟检查一次温湿度传感器」。调度任务完全通过自然语言创建，不需要写代码。

GPIO 和硬件控制是 zclaw 和普通聊天机器人的本质区别。通过内置工具，它可以直接读写 GPIO 引脚、扫描 I2C 总线设备、读取 DHT 温湿度传感器、执行自定义的 user_tools。指令同样通过自然语言下达，例如「把 5 号引脚设为高电平」或者「读取 I2C 地址 0x40 的数据」。所有 GPIO 操作都有内置的 policy guardrail，防止意外损坏硬件。

持久化记忆也是一个被低估的功能。zclaw 的 memory 系统可以在 NVS（非易失性存储）中保存对话历史、用户偏好、设备状态，重启后依然保留。配合 persona 设定（neutral、friendly、technical、witty），可以让助手有不同的说话风格。

用它容易吗？门槛在哪里？

zclaw 的上手分两个阶段：

阶段一：安装开发环境。官方提供了一个 bootstrap.sh 脚本，在 macOS/Linux 上可以一键完成：自动安装 ESP-IDF v5.4、QEMU 模拟器（用于无硬件调试）、cJSON 库，以及所有系统依赖。脚本支持 apt-get、pacman、dnf、zypper 等主流包管理器，自动检测 Linux 发行版。

阶段二：烧录固件到硬件。这一步需要真实硬件（推荐 Seeed XIAO ESP32-C3，性价比最高），通过 USB 连接到电脑，然后运行 flash.sh 脚本。烧录完成后，用 provision.sh 配置 Wi-Fi 和 LLM 凭证。支持 Anthropic、OpenAI、OpenRouter 和 Ollama（本地模型）四个后端。

整体来说，有 Linux/WSL 使用经验、能看懂几行 Bash 脚本的用户，按照官方文档大概 1-2 小时可以跑起来。最大的门槛其实是硬件——你得先有一块 ESP32 开发板。

固件内置了速率限制（默认 100 次/小时、1000 次/天），可以防止 LLM API 费用失控。

它有什么局限？

坦诚地说，zclaw 的局限是显而易见的：

完全依赖外部 LLM API。zclaw 本身不运行任何 AI 模型，所有理解和生成都通过外部 LLM 完成。这意味着：

1. 需要稳定的网络连接，断网即失联
2. API 费用随使用量线性增长
3. 隐私方面，所有对话数据都会发送到第三方 LLM 服务商

硬件资源极度受限。ESP32 的主频通常只有 160-240 MHz，没有 MMU，没有文件系统原生支持，所有事情都要在 400 KiB 不到的 RAM 里完成。这决定了 zclaw 的「智能」上限——它不是 AI 的载体，而是 AI 的管道。

部署复杂度高于普通软件。需要编译固件、烧录芯片、处理串口驱动、配置 Wi-Fi——这些步骤对没有嵌入式开发经验的用户来说并不友好。

它的意义在哪里？

zclaw 值得关注的真正原因，是它代表了一种边缘 AI 部署的新思路：不是把大模型压缩到端侧，而是让端侧设备成为大模型的「手和脚」。

过去，物联网设备只能做简单的传感器上报或指令执行；有了 LLM API 的加持，任何一个联网的小芯片都可以拥有「理解自然语言」的能力——你说「帮我关灯」，它不仅关灯，还会记住你关灯的时间，积累成你的生活习惯数据。

从更大的视角看，ESP32 级别的硬件每年出货量以亿计，如果其中很小一部分能接入 LLM，那带来的将是真正的「万物智能」。zclaw 就是在探索这条路是否走得通。从 2159 颗 GitHub Stars 的社区反馈来看，这条路至少是有人愿意走下去的。