[C/C++] 纯C实现、零API费用的Telegram AI助手：mini-claw的极简设计哲学

年初，一个名为 OpenClaw 的项目迅速走红。它是一个跨平台的AI代理网关，能够将 Claude、GPT 等大模型接入 Telegram、WhatsApp、Discord 等即时通讯软件，让你直接在聊天应用中与AI对话，甚至让它在你本地执行命令、管理文件。

这听起来功能强大且充满吸引力。然而，当我第一次接触它时，脑海中首先浮现的不是赞叹，而是一个疑问：这东西的运行开销得有多大？

OpenClaw 基于 Node.js 构建，作为一个常驻进程运行，需要 Node.js 运行时、npm 依赖安装以及一套初始化流程。其功能丰富，架构完整，但相应的资源消耗和部署复杂度也水涨船高。于是我开始思考：如果我仅仅是想在 Telegram 上通过一个Agent执行一些Shell命令、处理代码或进行基本运维，我真的需要一个如此“重量级”的方案吗？

我相信不止我一个人有此疑问。这也解释了为何后续出现了用 Rust 编写的 zeroclaw 和用 Zig 编写的 nullclaw 等衍生项目，它们的共同目标就是削减体积与开销。

mini-claw 是什么？

mini-claw 是 OpenClaw 的一个极简替代品。

它专注于实现 OpenClaw 最核心的功能：

• 连接 Telegram，作为你的 AI 助手前端。
• 对接 Claude Pro/Max 或 ChatGPT Plus，无需额外支付 API 费用，直接使用你已订阅的账号。
• 支持持久化会话，并具备自动压缩（automatic compaction）机制。
• 支持基础的 Shell 命令：/cd、/shell、/pwd。
• 提供会话管理：/new、/session archive/switch。
• 能够自动发送生成的文件（如 PDF、图片、文档）。
• 支持用户白名单，进行安全控制。

然而，最关键的差异并非功能，而在于技术选型。OpenClaw 使用 Node.js，而 mini-claw 的核心逻辑由 C 语言 编写。这个选择背后，是一套清晰的工程权衡。

为什么选择 C 语言？一个值得推敲的决定

在2026年用 C 语言写一个 Telegram Bot？这听起来或许有些“复古”。但深入分析，其逻辑层层递进。

第一层：运行环境的极致轻量化。
一个 Node.js 运行时本身大约 60-100 MB，加上 npm 依赖树，轻松占用数百 MB 乃至 GB 级的磁盘空间。部署前，你需要先准备好 Node.js 环境。而 C 语言编译出的二进制文件，大小仅在几十到几百 KB 之间。它无需任何运行时，可直接执行。这意味着你可以将 mini-claw 部署在任何角落：一台仅有 512MB 内存的 VPS、一个树莓派，甚至是一块 5 美元的芯片（如后文提到的 MimiClaw）。

第二层：长期运行的性能与稳定性。
这是一个需要 7x24 小时驻留的后台进程。Node.js 虽在 I/O 密集型场景表现优异，但其 V8 引擎的垃圾回收（GC）机制可能带来偶发的停顿，长期运行也存在内存泄漏的风险。C 语言则完全由开发者手动管理内存，没有 GC 和虚拟机的开销。只要代码稳健，它就能以极低且恒定的内存占用与响应速度，持续运行数月。

第三层：依赖与安全性的根本简化。
OpenClaw 的 npm 依赖树包含大量直接与间接依赖，每一个都可能成为潜在的安全漏洞。曾有报道指出，因配置问题，有超过 42,000 个 Clawdbot 实例暴露在公网。依赖越多，攻击面越大。C 语言编写的程序通常只依赖系统库，几乎不存在“供应链攻击”的风险。

因此，选择 C 并非炫技，而是一个明确的工程权衡：以更高的开发复杂度为代价，换取极致的运行时效率、超小的资源占用和最小的安全攻击面。对于那些追求效率和掌控感的开发者而言，这是一个值得研究的开源实战案例。

数据流程图：mini-claw 如何工作？

我们可以将其工作流梳理如下：

用户
  │
  ▼ 发送消息（Telegram）
Telegram Bot API
  │
  ▼ Webhook / Long Polling
mini-claw 核心进程（C 语言编写）
  │
  ├─► 解析命令（/cd /shell /pwd /new /session）
  │         │
  │         ▼
  │   本地 Shell 执行
  │         │
  │         ▼
  │   返回执行结果
  │
  └─► 普通对话
          │
          ▼
      Pi Coding Agent（调用 Claude Pro / ChatGPT Plus OAuth）
          │         ← 不走 API 计费，走订阅账号
          ▼
      AI 回复内容
          │
          ▼
      本地 JSONL 存储（会话记录）
          │
          ▼
      自动压缩（超长会话 compaction）
          │
          ▼
      Telegram 返回消息 / 发送文件
  │
  ▼
用户收到回复

值得注意的是，其中的“Pi Coding Agent”模块直接沿用了经 OpenClaw 项目验证过的可靠实现，保证了与AI交互的稳定性。整个链路的核心是那个用 C 语言 编写的进程，它负责驻守、消息路由、命令解析以及与 Telegram API 通信。

会话存储采用 JSONL 格式，简单直观，无需依赖数据库，可直接用文本编辑器查看。这再次体现了其“能用简单绝不用复杂”的设计哲学。

横向对比：明确各自的定位

仅说 mini-claw 好是不够的，将其与 OpenClaw 放在一起对比，才能看清各自适合的场景。

维度	OpenClaw	mini-claw
实现语言	Node.js	C
二进制体积	~GB 级（含依赖）	~KB 级
内存占用	较高（V8 引擎）	极低
依赖数量	大量 npm 包	几乎无外部依赖
支持平台	WhatsApp/Telegram/Discord/Signal 等全平台	主要 Telegram
功能完整度	极完整，有技能系统、语音、画布等	极简核心功能
部署难度	中等（需要 Node 环境 + 初始化）	低（编译即用）
安全攻击面	较大（依赖多，历史上有暴露案例）	极小
适合人群	需要完整助手生态的用户	开发者、极简主义者

这个对比揭示了一个有趣的事实：C 语言 作为系统级实现语言，为这类AI接入架构提供了“无限下沉”的可能性。无论是服务器上的 mini-claw，还是运行在 5 美元芯片上的 MimiClaw，都共享着同一个核心理念：AI 的接入层不应该比 AI 本身更笨重。

最后的思考

我并非在否定 OpenClaw。它拥有庞大的社区、丰富的插件生态和全面的平台支持，是一个成熟且强大的产品。如果你需要的是一套功能完备的个人AI助手系统，OpenClaw 无疑是更优选择。

但 mini-claw 的存在，向我们展示了技术的另一种可能性：

在正确的约束条件下，使用正确的工具，你可以用千行级别的 C 代码，解决一个别人用数十万行 JavaScript 才能解决的问题。

这不是反工程的激进主义，而是一种宝贵的思维方式——在动手之前，先问自己：我的核心需求究竟是什么？能满足这个需求的最小、最简洁的实现是什么？

技术债往往不是一次性欠下的，而是由每一次“先装个 npm 包凑合”的决策累积而成。选择用 C 语言 重写一个极简的 AI 助手接入层，这个决策本身，就值得每一位关心系统设计与工程实践的开发者在云栈社区这样的技术论坛中深入探讨和反思。它让我们重新审视，在追求功能强大的同时，“够用”与“优雅”的边界究竟在哪里。