tone down noc post

content/posts/noc.md

@@ -5,32 +5,14 @@ draft: false
 summary: "为什么不用 OpenClaw，以及 noc 在做什么不一样的事。"
 ---
 
-[OpenClaw](https://openclaw.ai) 大概是今年最火的开源 AI agent 项目了。100K+ stars，支持 20 多个聊天平台、35 个 LLM 后端、三层架构、多 agent 路由、RAG 管线、浏览器自动化、语音唤醒……400,000 行代码，1,800+ 个 issue，冷启动要 500 秒，官方推荐跑在 $600 的 Mac mini 上。
+[OpenClaw](https://openclaw.ai) 是今年最火的开源 AI agent 项目。400,000+ 行代码，1,800+ 个 open issue，支持几十个平台和后端。做得很全，但也很重。
 
-很厉害。但我只是想在手机上跟 AI 聊天，顺便让它帮我干点活。
+我的需求没那么复杂，所以写了 noc——Not OpenClaw。三千行 Rust，一个 binary，跑在一台小 VPS 上。
 
-所以有了 noc——Not OpenClaw。
+noc 的两个亮点：
 
-## 不一样在哪
+**工程化。** 内置 Gitea 整合，AI 的工作有地方落——代码变成 PR，任务变成 issue，讨论沉淀在 comment 里。不是聊完就散了。[详见这篇](/posts/ai-suite/)。
 
-OpenClaw 是个框架。它解决的是「如何让 AI 接入尽可能多的平台和后端」。这是一个合理的工程目标，但它导致了一个巨大的抽象层：channel adapter、agent runtime、skills override system、hub-and-spoke gateway……每一层都在解决「通用性」的问题。
+**连续性。** Life loop 让 AI 不只是被动应答。它有持久记忆、内在状态、定时反思，在没人找它的时候也在运行。同一个内核跨聊天、代码协作和后台任务共享上下文。
 
-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 和人的协作模式，而不是基础设施的抽象层。
+不追求通用，够用就好。