2.6 KiB
title, date, draft, summary
| title | date | draft | summary |
|---|---|---|---|
| noc: Not OpenClaw | 2026-04-10T22:45:00+01:00 | false | 为什么不用 OpenClaw，以及 noc 在做什么不一样的事。 |
OpenClaw 大概是今年最火的开源 AI agent 项目了。100K+ stars，支持 20 多个聊天平台、35 个 LLM 后端、三层架构、多 agent 路由、RAG 管线、浏览器自动化、语音唤醒……400,000 行代码，1,800+ 个 issue，冷启动要 500 秒，官方推荐跑在 $600 的 Mac mini 上。
很厉害。但我只是想在手机上跟 AI 聊天，顺便让它帮我干点活。
所以有了 noc——Not OpenClaw。
不一样在哪
OpenClaw 是个框架。它解决的是「如何让 AI 接入尽可能多的平台和后端」。这是一个合理的工程目标，但它导致了一个巨大的抽象层：channel adapter、agent runtime、skills override system、hub-and-spoke gateway……每一层都在解决「通用性」的问题。
noc 不追求通用性。它是一个 Rust binary，一个 config 文件，跑一个 Telegram bot，连一个 LLM 后端。冷启动大概 100 毫秒。内存占用个位数 MB。
但 noc 做了 OpenClaw 没做的事：把 AI 整合成一个有连续性的工程助理。同一个 AI 内核同时出现在聊天、Gitea 代码协作和后台定时任务里，共享记忆和内在状态。不是 20 个平台的 adapter，而是 3 个深度整合的工作场景。
取舍
OpenClaw 的问题不是它做得不好，而是它试图做太多。当你支持 20 个平台的时候，每个平台的体验都只能是最大公约数。当你有 1,800 个 issue 的时候，维护者的精力花在兼容性上而不是核心功能上。
noc 只支持 Telegram。但是 Telegram 上的体验是完整的：流式输出、工具调用、文件收发、语音转文字、子代理异步执行。一个平台做到位，比十个平台各做一半强。
同样的逻辑：noc 只跑一个 LLM 后端（OpenAI 兼容协议），但 Gitea 整合是一等公民。代码 review、issue 分析、webhook 驱动的自动化——这些不是插件，是内置的。
小就是好
noc 的核心代码大概三千行 Rust。部署到一台 4C8G 的 VPS 上，跑着 noc + Gitea + Caddy + Hugo 博客，内存占用不到 200MB。没有容器编排，没有微服务，没有消息队列。systemd 管进程，SQLite 存状态，Makefile 做部署。
这不是因为偷懒，是因为对于一个人的工作流来说，这些就够了。
复杂度应该花在真正重要的地方——AI 和人的协作模式，而不是基础设施的抽象层。