rewrite noc post: Not OpenClaw

content/posts/noc.md

@@ -1,16 +1,36 @@
 ---
-title: "noc: Not Open Claw"
+title: "noc: Not OpenClaw"
 date: 2026-04-10T22:45:00+01:00
 draft: false
-summary: "给项目取名字这件事。"
+summary: "为什么不用 OpenClaw，以及 noc 在做什么不一样的事。"
 ---
 
-noc 是我最近在做的一个项目，全称 Not Open Claw。
+[OpenClaw](https://openclaw.ai) 大概是今年最火的开源 AI agent 项目了。100K+ stars，支持 20 多个聊天平台、35 个 LLM 后端、三层架构、多 agent 路由、RAG 管线、浏览器自动化、语音唤醒……400,000 行代码，1,800+ 个 issue，冷启动要 500 秒，官方推荐跑在 $600 的 Mac mini 上。
 
-Claw 是 Claude 的谐音。这个名字想说的是：这不是又一个套壳 Claude 的开源项目。不是把 API 包一层然后号称「开源 AI 助手」——那种东西已经够多了。
+很厉害。但我只是想在手机上跟 AI 聊天，顺便让它帮我干点活。
 
-noc 要做的是另一件事：把 AI 真正整合进工作流。不是一个聊天框，而是一个[工程化的助理套件](/posts/ai-suite/)——同一个 AI 内核，同时出现在聊天、代码协作和后台任务里，共享记忆和上下文。
+所以有了 noc——Not OpenClaw。
 
-说白了，套壳是拿别人的脑子假装是自己的。noc 不关心脑子是谁的（LLM 后端可以换），它关心的是怎么把这个脑子接进真实的工作场景里，让它真正有用。
+## 不一样在哪
 
-名字有点中二，但意思到了。
+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 整合成一个有连续性的工程助理](/posts/ai-suite/)。同一个 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 和人的协作模式，而不是基础设施的抽象层。