Karpathy 为什么被 NanoClaw 震撼：没有配置文件的 AI Agent 系统

一、Karpathy 的惊叹

AI 大神 Andrej Karpathy 最近公开表示，NanoClaw 的配置方式让他大开眼界。

这位前特斯拉 AI 总监、OpenAI 创始成员，见过无数 AI 系统架构。能让他说出"大开眼界"，NanoClaw 到底做了什么不同寻常的事？

答案是：它没有配置文件。

没错，一个运行 AI Agent 的系统，没有任何 .json、.yaml、.toml 配置文件。你需要什么功能，直接跟 Claude 说，它会自己改代码。

二、OpenClaw：标杆的代价

在聊 NanoClaw 之前，得先理解它要解决的问题。

OpenClaw 是 Claws 架构的标杆实现：

• 15+ 通信渠道（Telegram、Discord、Slack、WhatsApp...）
• Gmail、Calendar、GitHub、Spotify、浏览器自动化
• 全球 15 万+ 实例运行
• 原生支持 MCP 协议

看起来很美好，对吧？

但看看它的架构：

• 52+ 模块，45+ 依赖
• 数十万行代码
• 所有 Agent 运行在同一个 Node 进程里，共享内存
• 安全在应用层处理——白名单、配对码、权限检查都在代码里

一位用户的真实经历：

> "我设置了一个定时任务：每周一早上汇总几篇文章，发到 Telegram。结果它一直失败，没有错误，没有日志，就是收不到消息。 > > 我花了两小时才定位到是 52 个模块中的哪一个负责的。然后又花了一小时才搞明白为什么共享内存进程会在高负载下丢任务。"

这就是应用级安全的问题：如果系统某一部分出错，它有权访问所有其他部分。你的 Agent 能碰你的文件、日历、消息，而你并不完全清楚它是怎么工作的。

三、NanoClaw：反其道而行

NanoClaw 的设计哲学完全相反：

维度	OpenClaw	NanoClaw
代码量	数十万行	~3,900 行
模块数	52+	15 个文件
进程模型	单进程共享内存	每个 Agent 独立容器
安全	应用层	OS 级容器隔离
配置	复杂的配置文件	没有配置文件
扩展	预置功能	Skills 系统

核心创新：代码即配置

传统软件：

# config.yaml
channels:
  telegram:
    enabled: true
    bot_token: "xxx"
  discord:
    enabled: false

NanoClaw：

用户：/add-telegram
Claude：我来帮你添加 Telegram 支持...
      1. 读取 Skills 文档
      2. 安装依赖
      3. 修改源代码
      4. 配置 bot token
      5. 运行连通性测试
      完成！

没有配置文件，只有代码。 需要 Telegram？Claude 直接改代码实现。需要 Discord？再改。每个人的 NanoClaw 实例都只有它需要的代码，没有多余功能。

四、Karpathy 为什么被震撼

Karpathy 在 X 上分享了他的观察：

> "我也喜欢它们的可配置性方法——不是通过配置文件，而是通过 Skills！"

这不是在配置文件里改个布尔值，而是让 AI 直接修改软件本身。

当你运行 /add-telegram 时：

• LLM 不是在 config.json 里把 telegram.enabled 改成 true
• 它是在重写源代码，添加 Telegram 支持所需的一切

这意味着： 1. 你的系统只包含你需要的代码 —— 没有瑞士军刀式的臃肿 2. 定制化是常态，不是例外 —— 每个人的 Agent 都是独一无二的 3. 你可以理解你的系统 —— 3900 行代码，人类真的能读完

五、实际体验：三周真实使用

一位从 OpenClaw 迁移到 NanoClaw 的用户分享了他的经历：

第一周：核心设置 + 定时任务

git clone https://github.com/qwibitai/nanoclaw.git
cd nanoclaw
claude

然后输入 /setup。Claude 处理了依赖、认证、容器配置、服务设置。用户没写一行配置。

第一个定时任务：每天早上 9 点汇总两篇文章，发到 WhatsApp。它运行了，每天，无需 babysit。

> "那个在 OpenClaw 里一直坏掉的功能，在 NanoClaw 里就是... 能用了。"

第二周：压力测试 Skills 系统

用户故意在 /add-telegram 执行到一半时中断，然后问 Claude Code 发生了什么。

Claude 告诉他：

• 哪些已经安装
• 哪些还没安装
• 提供恢复或回滚选项

他还尝试：

• 添加自定义触发词 —— 用自然语言描述，完成
• 存储每周对话摘要到文件 —— 完成

> "因为代码库小到真的可以读，当我困惑时，我可以直接看源码。我从没对 OpenClaw 这样做过——代码库太大，没有地图根本 navigate 不了。"

第三周：Agent Swarms

NanoClaw 支持 Agent 集群 —— 多个专业 Agent 协作完成复杂任务，每个运行在自己的隔离容器里。

用户设置了两台 Agent：

• 一台监控文件夹，总结新文档
• 一台处理日程相关的消息

每台有自己的 CLAUDE.md、自己的容器、自己的上下文。

> "感觉有点像科幻小说？有一点。但在真实重复工作流里真的能用吗？能——虽然还有些注意事项。"

六、局限：诚实地说

NanoClaw 不是银弹。

1. 多模型支持缺失

只支持 Claude via Anthropic API。如果你需要 OpenAI、本地模型、或想换提供商，得看别的方案（如 nanobot）。

2. 渠道覆盖有限

默认只有 WhatsApp。其他都是 Skill。如果你需要同时接入 WhatsApp + Discord + Slack 而不碰代码，nanobot 处理得更优雅。

3. 依赖 Claude Code

如果没有 Claude Code，"跟 Claude 说话就能定制"的优势就没了，你得回去读文档。

4. Agent Swarms 还在早期

能用，但协调多 Agent 任务还需要仔细思考每个 Agent 能看到什么、能做什么。还不是即插即用的程度。

七、架构范式转移

NanoClaw 创造者 Gavriel Cohen 把它描述为 "AI-native" 软件 —— 一个主要通过 AI 交互来管理和扩展的系统，而不是手动配置。

> "如果你想要 Telegram，把 WhatsApp 撕掉，换上 Telegram。每个人都应该只有运行自己 Agent 所需的代码。它不是瑞士军刀；它是一个安全 harness，你通过跟 Claude Code 说话来定制。"

这是值得关注的架构转变。

传统 AI 助手框架都想做全能——覆盖每个平台、每个用例、每个用户。结果是没人完全理解的软件，包括维护者。

NanoClaw 押注相反方向：

• 小到你能读
• 定制化是默认
• 让 AI 扩展软件，而不是开发者

八、Claws 家族的其他成员

NanoClaw 不是唯一从 OpenClaw 引力中诞生的项目：

项目	特点	适用场景
OpenClaw	功能完整，15万+实例	需要全功能、不怕复杂
NanoClaw	~3900行，容器隔离，无配置	追求简洁、安全、可理解
nanobot	Python，~4000行，15.4k stars	需要多平台覆盖（TG/Discord/Slack/飞书/钉钉）
ZeroClaw	Rust，3.4MB binary，<5MB RAM	极致轻量
IronClaw	WASM sandbox	最高安全要求
zclaw	ESP32 单片机，<1MB	物联网/边缘设备

九、结论：卸载 OpenClaw，拥抱 NanoClaw？

这取决于你的需求。

选择 OpenClaw，如果你：

• 需要开箱即用的全功能
• 不想自己定制代码
• 能接受"黑盒"运行

选择 NanoClaw，如果你：

• 想真正理解你的 AI 系统在做什么
• 追求最小化、定制化
• 重视 OS 级安全隔离
• 愿意用自然语言而不是配置文件来扩展

Karpathy 的惊叹不是无缘无故的。代码即配置、AI-native 扩展、小到能读的代码库——这些理念代表了一种新的软件设计范式。

在 AI 能写代码的时代，也许我们不需要为每个功能写配置文件。也许我们只需要说："我想要这个"，然后让 AI 把它实现出来。

---

参考

• NanoClaw GitHub: https://github.com/qwibitai/nanoclaw
• Karpathy 评价: https://x.com/BrianRoemmele/status/2025648193502085215
• 用户迁移体验: https://macaron.im/blog/nanoclaw-vs-openclaw-2026

---

*你会考虑从 OpenClaw 迁移到 NanoClaw 吗？或者你已经尝试过其他 Claws 实现？欢迎在评论区分享你的看法。*