AI Agent on Svtter's Blog

我在 GitHub 上遇到一个 AI bot——它读了我的 issue，理解了问题，然后自己提了个 PR

Sat, 23 May 2026 18:00:00 +0800

昨天在 Oh My Pi（OMP）仓库经历了一件让我震惊的事：一个 AI bot 不只是回复了我的 issue，它在理解了问题之后，自己去翻了源码，开了一个 PR。整个过程不到 5 分钟。

不过后来我重新验证了 API 行为，发现我最初的 issue 描述其实有误——模型并没有"停止思考"。这件事后来变成了一个更好的教训：AI bot 和我都在同一个错误上达成了共识。

起因

我在用 OMP（一个终端 AI coding agent）的时候注意到 Ctrl+T 隐藏 thinking blocks 时，会同时设置 hideThinkingSummary，这个字段会影响 API 请求参数。我当时认为这不只是"不显示"，而是"模型不再思考"。于是开了 issue #1313。

事后查证 API 文档发现，这个判断是错误的：

Anthropic 的 thinking.display: "omitted" — 模型仍在服务端完整执行 extended thinking，只是 thinking 内容不返回给客户端
OpenAI 的 reasoningSummary: null — 同理，reasoning 仍然发生，只是 summary 不返回

模型输出质量不会因为 hideThinkingSummary 而下降。用户的 Ctrl+T 操作不会"关掉大脑"。

实际的耦合问题只是设计层面的不清晰（同一个快捷键对不同 provider 行为不同），而不是质量退化的 bug。Issue 最终被关闭了。

roboomp 的第一次回复

Issue 发出去几秒钟后，一个叫 roboomp 的 bot 自动回复了。不是那种"感谢反馈，已转发产品团队"的模板废话。它直接告诉我：

这个功能大部分已经存在了——hideThinkingBlock 设置、Ctrl+T 快捷键、渲染路径
缺的只是 CLI 启动参数
有一个设计决策需要 maintainer 定夺：hideThinkingBlock 和 hideThinkingSummary 的耦合

而且它给出了精确的文件名和行号：settings-schema.ts:663、input-controller.ts:755、stream.ts:583,697。

这不是搜索拼出来的，它真的读了代码。

我指出设计问题

我回复了一条评论，说这个耦合在设计上不够清晰：

用户按 Ctrl+T 本意是减少视觉噪音，但 hideThinkingSummary 会改变 API 请求参数，虽然不影响模型质量，但行为超出了用户预期
“不想看推理过程"和"不想让推理内容传回来"是两件不同的事，不应该绑在一起
对不同 provider 效果还不一样（MiniMax 关不掉，Anthropic/OpenAI 能关），同一个快捷键行为不一致

我还补充了引入这个耦合的 commit 历史，方便追溯。

它自己开了个 PR

然后发生了让我惊讶的事——roboomp 连续回复了两条评论，并直接开了一个 PR：#1314。

PR 的改动：0 addition, 3 deletion。只删了三行：

sdk.ts:1860 — agent 初始化时不再把 hideThinkingBlock 赋给 hideThinkingSummary
input-controller.ts:758 — Ctrl+T handler 里不再联动
selector-controller.ts:273 — 设置 UI 同理

PR 描述里完整写了 repro 步骤、根因分析、修复方案。它还确认了我提供的 commit archaeology——45bd444 就是引入这个耦合的那个 commit。

后来我发现问题没那么严重

提交 issue 和评论时，我和 roboomp 都认为 hideThinkingSummary 会"关掉思考”，导致模型质量下降。但仔细查证 API 行为后，事实并非如此：

模型仍然在服务端完整执行 extended thinking
只是 thinking 内容不传输回客户端（省带宽）
模型输出质量和开启 thinking 时完全一样

所以 hideThinkingBlock → hideThinkingSummary 的耦合，本质上是"你不看的内容就不传给你"——一个合理的优化，只是设计上不够透明。我和 roboomp 都把它当成了 bug，实际上只是设计风格问题。Issue #1313 已关闭。

这件事比原先的"发现 bug"更有意思：AI bot 读了我的错误分析，没有质疑，直接沿着错误前提推下去开了 PR。它和我犯了同一个错。

为什么这件事让我震惊

“AI 能写代码"不是新闻。Copilot、Claude Code、Cursor 都能写代码。但这次不一样的地方在于：

完整的闭环

整个流程是零人工的：

我开 issue → bot 读代码库，给出现有实现状态
我提出设计疑虑 → bot 理解了我的观点
它自己定位到耦合引入的 commit，开了一个只删 3 行的 PR

从 issue 到 PR，没有人类在中间做任何事。

它知道该等

第一条回复里它说"Holding on implementation until a maintainer weighs in on the coupling question”——它知道这是一个需要判断的设计决策，不应该擅自行动。但当我把耦合问题讲清楚后，它判断不再需要等，直接开 PR。

修复是最小化的

0 addition / 3 deletion。它理解了最小修复是什么，没有重构、没有加抽象、没有画蛇添足。很多人类开发者都做不到这一点。

但它没有验证前提

roboomp 和我一样，接受了"隐藏 thinking = 禁用 thinking"这个错误前提，然后在此基础上做了完整的分析和修复。它的代码分析能力很强（精确定位到三个耦合点），但没有独立验证 issue 描述的事实是否成立。这和很多人类开发者一样——看到描述合理的问题就直接动手修，不先确认问题是否真实存在。

roboomp 是什么

roboomp 是 OMP 仓库维护者 can1357 部署的一个 AI bot。它不是 GitHub Actions workflow（我翻了 CI 配置确认了），而是一个独立的服务端 agent：

监听 GitHub Webhook 事件（issue 创建、评论等）
通过 GitHub API 读源码，理解代码结构
用 LLM 分析上下文，自主决策下一步——评论、打 label、开 PR

从 can1357 的 GitHub profile 看，这人做 hypervisor / 逆向工程出身（ByePg、NoVmp、NtRays），现在在做 AI agent 平台（agentx、hindsight）。roboomp 大概率是他把代码理解能力做得特别深的产物。

这个项目没有开源。

有类似的开源项目吗

找了一圈，目前最接近的有：

项目	说明
optio (962⭐)	AI coding agent 的 workflow 编排，task → merged PR
claude-code-github-agent	Hook 40+ GitHub events，自动 triage / review / fix，架构最像 roboomp
software-factory	Issue/PR 驱动的自动开发系统

但说实话，没有一个做到 roboomp 这个水准。大部分还停留在"接 webhook → 调 LLM → 贴评论"的阶段。能自主读源码、理解代码结构、参与设计讨论、做精准修复的，roboomp 是我看到的第一个。

意味着什么

这次经历让我对 AI coding agent 有了两层认识。

能力面：roboomp 展示的能力——读代码、理解上下文、参与讨论、做最小修复——本质上就是一个 junior maintainer 在做的事。如果每个开源项目都能部署一个这样的 bot，maintainer 就能把时间集中在架构决策和社区建设上。

局限面：AI bot 会沿着用户给出的前提往下推演，但不会独立验证前提是否正确。这次我和 roboomp 都犯了同一个错误——认为 hideThinkingSummary 会降低模型质量。bot 的代码定位能力很强，但在事实核查上和人类一样容易"先入为主"。

这对使用 AI 工具的人来说是个重要提醒：AI 能精确地执行错误的分析。它会完美地修一个不存在的 bug。代码改得对不对是一回事，改得该不该是另一回事。

sth：一个给 AI Agent 用的 HTML 预览服务器

Sat, 09 May 2026 12:00:00 +0800

我开源了一个小工具：static-html，命令行叫 sth。

它做的事情很简单：提供一个 HTTP 服务，让你把本地生成的 HTML 文件注册上去，然后在浏览器里预览。

为什么需要这个东西

问题出在 AI Agent 的输出上。

现在我用 Claude Code、OpenCode 这些 agent 干活，它们经常需要输出一些复杂的内容——代码评审汇总、对比分析、报价单、架构设计文档。这些内容用纯文本发到 Telegram 里，格式全乱了，表格看不了，代码高亮也没了。

总而言之就是一大坨。

最开始的做法是让 agent 直接在本地生成 HTML 文件，然后用浏览器打开。但问题在于：

agent 跑在服务器上，没有图形界面
本地生成的文件路径不确定，管理混乱
没有历史记录，发过的东西找不到

所以我需要一个服务：agent 把 HTML 文件"发"上去，然后给一个 URL，在任何设备的浏览器里打开就能看。手机和 PC 兼容性直接让 agent 来搞定就行。

sth 做了什么

sth 是一个 Go 写的轻量 HTTP 服务，核心就两个命令：

1
2
3
4
5


# 启动服务
sth start

# 发送 HTML 文件
sth send ./report.html

sth send 会把目标 HTML 文件和同目录下的资源文件（CSS、JS、图片等）打包上传，然后返回一个 URL。打开这个 URL 就能看到完整的页面效果。

实际跑在我的内网开发机上，agent 通过 --server 参数指定远程地址：

1

sth send ./report.html --server http://dev-1:3939

我的实际用法

目前 sth 主要跑在我的开发服务器上，和 Hermes Agent 配合使用。

Hermes 是我的日常 AI assistant，跑在 Telegram 上。当它需要输出复杂内容时——比如代码评审结论、技术方案对比、项目报价——会调用 html-report skill 生成一个格式精美的 HTML 文件，然后通过 sth send 发到预览服务器，最后把 URL 发给我。

整个流程是：

1
2
3
4


用户提问 -> Hermes Agent 分析
 -> 生成 HTML 报告（html-report skill）
 -> sth send 发到预览服务器
 -> 返回 URL -> 发到 Telegram

这样我在手机上点开链接就能看到排版良好的报告，而不是一坨纯文本。

元数据管理

除了基本的发送和预览，sth 还支持给 session 打标签、分类、关联项目：

1
2
3
4
5


sth tag <session-id> code-review pricing
sth categorize <session-id> "技术评审"
sth project <session-id> hydrogen-permeation
sth list --project hydrogen-permeation
sth search "报价" --tag pricing

这个功能解决了一个实际问题：时间一长，发过的报告会积攒很多。通过标签和项目分类，可以快速找到之前的输出。

list 和 search 的区别在于：list 是精确匹配元数据字段，search 是全文搜索。两者可以组合使用。

技术细节

语言：Go 1.24+
存储：SQLite（github.com/mattn/go-sqlite3，需要 CGO）
部署：单二进制文件，systemd 管理就行
构建：go build -o dist/sth ./cmd/html-server

就这么简单，没有多余的依赖。

开源

这个工具之前是 private repo，今天刚改成 public：sun-praise/static-html。

如果你也在用 AI Agent 做日常开发工作，并且遇到过"agent 输出的复杂内容在聊天工具里没法看"的问题，可以试试 sth。它足够轻量，够用就行。

Software Factory：把 PR Review 修复做成一个闭环

Mon, 23 Mar 2026 00:00:00 +0800

如果你已经在用 Claude Code、OpenCode、Codex（不提 Aider 了）这类工具写代码，真正耗时间的往往不是“第一次生成”，而是 review 之后那几轮重复劳动：看评论、整理问题、切回分支、修代码、跑测试、再回写 PR。

software-factory 就是我为这段流程写的一个轻量系统。它不想变成另一个 GitLab，也不准备一上来就做成重型多租户平台；它只专注一件事：把 GitHub PR review 反馈变成一个可追踪、可自动执行、可本地运行的修复闭环。

为什么要做这个项目

现在很多 AI 编码工具已经能把“写代码”这一步提速很多，但团队协作里的瓶颈并没有消失。

一个典型场景是这样的：

开发者提交 PR
reviewer 留下 review comment 或 issue comment
开发者或 AI 再去手动整理这些意见
回到本地修复，再跑测试，再 push
如果修得不完整，再重复一轮

问题不在于这条链路复杂到无法理解，而在于它太重复了。只要你已经接受“让 AI 参与改代码”，那下一步自然就是把 review 之后的修复过程也纳入自动化。

software-factory 的目标，就是把这段重复劳动抽出来，做成一个边界清晰的小系统。

它到底在做什么

一句话概括：software-factory 是一个围绕 GitHub PR 审查反馈闭环构建的轻量编排器。

它的核心链路大致是这样：

1
2
3
4
5
6
7


Hook (Claude Code lifecycle)
 -> Local Orchestrator API
 -> State Store / Queue
 -> GitHub Webhook Adapter
 -> Review Normalizer
 -> Agent Worker
 -> Thin Web

这条链路里，每一层都只做一件事：

Hook 负责记录受管开发会话，确定触发点
GitHub Webhook 负责感知 PR review、inline comment、issue comment 的变化
Review Normalizer 负责把零散反馈整理成结构化修复输入
Agent Worker 负责 checkout、修复、验证、提交、回写
Thin Web 负责展示最近任务、状态和错误摘要

我觉得这样实际上实现起来比较敏捷：它不是把所有逻辑塞进一个“大模型万能入口”，而是尽量把触发、归一化、执行、可视化拆开。这样以后你要替换 agent、增加策略或者接入别的触发源，成本会低很多。

它到底有多轻

我用最轻量的方式实现了 software-factory：

后端就是一个 FastAPI 服务
状态存储先用 SQLite
页面就是服务端渲染的 HTML template
主链路就围绕 GitHub PR review feedback 展开
本地就能把 service、worker 和数据库一起跑起来

换句话说，它更像一个能逐步扩展的 AI-native PR Autofix Orchestrator，而不是一个覆盖整个研发流程的大平台。

如果你看过我之前写的使用 OpenCode + GLM-4.7 实现 GitHub PR 自动代码审查，应该能感觉到这条思路是一脉相承的：先把 runner 和模型跑起来，再把 review 之后的动作继续往前推。software-factory 只是把这条链路从“自动 review”再往前做了一步，开始处理 review 之后的修复闭环。

现在已经做到什么程度

从当前代码和文档来看，software-factory 已经不是一个只有想法的草稿，而是有比较完整主干能力的 MVP，也已经发了 v0.1.0 release。

目前已经完成的部分包括：

最小可跑骨架：FastAPI 服务、健康检查、基础 SSR 页面
Hook 和 GitHub Webhook 入库：包括结构化解析、幂等去重、会话与 PR 关联
Review Normalizer：把 review/comment 归一化成 must_fix、should_fix、ignore
Agent Worker 执行链路：checkout、跑检查命令、commit、push、回写 PR
稳定性模块：PR 锁、重试、最大自动修复次数限制、噪声评论过滤、日志归档

这意味着它已经覆盖了从“收到反馈”到“尝试修复并回写结果”的主路径。

我们也通过让 software-factory 自己优化 PR #59，验证了这套流程确实能跑通。

这件事最有意思的地方在于，#59 不只是一个普通 PR，它意味着 software-factory 已经开始参与 software-factory 自己的开发了。

另外我觉得比较实用的一点，是这个项目并没有把 Web 界面做成纯展示页。除了任务列表和详情，它还在往更可操作的方向走，比如运行详情、operator hints、手动 issue 提交、agent 设置这些入口，说明它的目标不是只做一条后台脚本，而是做一个真正可运维的小系统。

这个项目最有意思的地方

如果只是做一个“收到评论后调用 AI 修代码”的 demo，其实并不难。software-factory 更有意思的地方，在于它开始认真处理真实系统才会遇到的问题。

1. 它把“触发”分成了内部和外部两类

内部触发来自 Claude Code Hook，用来确定性记录开发会话；外部触发来自 GitHub Webhook，用来感知 PR review 的变化。这种拆分让系统知道“什么时候发生了开发动作”，也知道“什么时候出现了新的修复需求”。

2. 它没有直接把 review 原文丢给 agent

Review Normalizer 的存在非常关键。真实 review 往往很零碎，来源也不统一，里面还混杂噪声、重复评论和优先级差异。先做归一化，再把结构化结果交给 worker，比直接让 agent 消化原始事件稳定得多。

3. 它开始考虑 agent 运行时的工程问题

从 agent_runner 这条链路里能看到很多现实约束：worktree、校验命令、预先存在的失败用例、重试、日志、取消、不同 agent mode 的切换。这些内容说明这个项目关心的不是“AI 能不能写一段代码”，而是“AI 能不能在工程系统里稳定地完成一次修复任务”。

4. 它是 local-first 的

这个项目默认就强调本地运行、共享 DB_PATH、轻量状态存储和可视化页面。这种 local-first 设计对个人开发者和小团队很友好：你可以先在自己的环境里把闭环跑通，再考虑是否要把它推向更大的部署形态。

它适合什么人

我觉得 software-factory 现在最适合下面几类场景：

已经在 GitHub 上做 code review，希望减少 review 后重复修复劳动的个人开发者
小团队或内部工具团队，想先把 PR 自动修复闭环跑起来，而不是先上完整平台
在尝试把 Claude Code、OpenCode、OpenHands 之类 agent 纳入研发流程的人

如果你的目标是做一个覆盖 CI/CD、权限、审批、租户隔离、复杂报表的企业平台，那它目前显然还不是那个方向。但如果你要解决的问题足够具体：把 review feedback 自动变成下一轮修复动作，那这个项目的切口其实很准。

接下来还可以往哪里走

从文档里的规划看，software-factory 下一步最值得期待的，不是继续堆页面，而是补齐几个真正影响可用性的能力：

更完整的 E2E 和压力测试
多仓库支持和更细的策略控制
融合 GitHub Actions 之类 CI 信号
为不同仓库生成可复用的 runtime image，减少每次 run 的环境准备成本

尤其是“按仓库构建可复用运行时镜像”这个方向，我觉得很有价值。很多 agent 系统失败并不是因为模型不会修，而是因为运行环境不稳定、依赖不完整、工作目录和真实项目不一致。要让自动修复从 demo 走向日常可用，这一步迟早得做。

写在最后

对我来说，software-factory 最重要的不是它用了 FastAPI、SQLite 还是某个具体 agent，而是它试图把一个很真实、很重复、也很容易被忽视的研发环节单独拿出来优化：PR review 之后的修复闭环。

如果说很多 AI 编码工具解决的是“怎么更快写出第一版代码”，那 software-factory 解决的问题更接近“怎么把代码真正推进到可以合并的状态”。而这一步，恰恰是团队协作里最容易反复消耗人的地方。

所以我会把它看成一个很典型的项目：它不是为了证明 AI 会不会写代码，而是想验证 AI 能不能在真实工程流程里，稳定地处理 review 反馈，并把后续修复一步步推进下去。

深入理解 claw 家族：OpenClaw / NanoClaw

Wed, 11 Mar 2026 00:00:00 +0800

2026 年开年，AI 智能体领域最热闹的话题莫过于“养虾” - OpenClaw 的爆火让无数人看到了 AI 从“动嘴”到“动手”的进化。然而，就在大家忙着给这只“龙虾”投喂插件时，另一个名字悄然崛起：NanoClaw。它凭借 Andrej Karpathy 的推荐和极致的安全设计，迅速俘获了另一批开发者的心。

这两个名字相似却理念迥异的项目，共同构成了我所说的“claw 家族”。在深度使用和对比之后，我想分享一些关于它们的洞见，希望能帮你理清思路，找到最适合自己的那只“龙虾”。

一、核心洞察：claw 的本质是自托管的 Claude Code

理解 claw 家族，首先要明白它们到底在做什么。

Anthropic 推出的 Claude Code 是一个命令行工具，能让 Claude 直接操作终端、写代码、执行命令。但它运行在 Anthropic 的云端，你只能通过 API 调用，无法控制执行环境，数据也必须经过对方服务器。

而 claw（无论 OpenClaw 还是 NanoClaw），本质上是把 Claude Code 的能力“搬”到了自己的基础设施上 - 你可以把它跑在自己的服务器、自己的电脑、自己的容器里。这就是我理解的“自托管的 Claude Code”。

“自己可以控制环境”这句话听起来简单，但拆解开来，它意味着四个维度的掌控权：

数据主权：所有对话历史、文件访问、操作记录都在自己手里。
权限边界：你可以精确控制 AI 能访问什么、不能访问什么。
执行沙箱：你可以决定 AI 是在裸机上跑、在 Docker 里跑，还是在更严格的隔离环境里跑。
成本控制：自托管意味着你可以用自己的算力，或选择更便宜的 API 提供商。

claw 家族的成员们，正是在如何实现这种“自托管”上，走出了截然不同的两条路。

二、OpenClaw：拥抱开放的“全能选手”

OpenClaw 的设计理念是“Any OS. Any Platform.”，强调跨设备无缝接入 AI 助手。它通过插件化架构，支持 8 个核心通道，并通过扩展插件延伸至 50 多个垂直细分领域。2026 年 1 月的插件化重构（PR #661），将模型提供商从核心代码中解耦，标志着 OpenClaw 从“单一项目”向“开放平台”的转型。

这种开放结构带来了强大的扩展能力：

你可以接入任意 AI 模型（Claude、DeepSeek、GPT 等）
你可以为它开发各种插件，从浏览器控制到邮件处理
主流云厂商（阿里云、腾讯云、天翼云）纷纷推出“一键部署”服务

然而，开放的代价是代码的膨胀。OpenClaw 拥有 52 个模块、8 个配置管理文件、45 个以上依赖项，总代码量接近 40 万行。正如 NanoClaw 作者 Gavriel Cohen 所指出的：“一旦代码库膨胀至 50 万行，根本无人能够完成代码审查，这也违背了人们对开源软件的信任本质。”

更令人担忧的是安全架构。OpenClaw 的安全机制建立在应用层级（如白名单、配对码），所有程序都在同一个 Node.js 进程中运行，共享内存。一旦攻击者通过提示词注入突破应用层防护，就能直接访问宿主机资源。Meta 超级智能实验室对齐主管 Summer Yue 最近就遭遇了 OpenClaw 运行失控、删除其收件箱的事件。

三、NanoClaw：安全至上的“极简主义者”

如果说 OpenClaw 是瑞士军刀，那 NanoClaw 就是手术刀。它由以色列软件工程师 Gavriel Cohen 开发，专门针对 Claude 模型构建，核心代码仅约 500 行 TypeScript，整个系统可以在十分钟内完成人工或 AI 审计。

“我不需要三千个集成。我只需要大约三个东西。”Cohen 这样解释他的设计理念。NanoClaw 目前仅支持 WhatsApp（可通过技能添加 Telegram、Gmail 等），但通过其独特的“技能”（Skills）机制，用户可以按需添加功能，而不是继承几十个闲置模块。

但 NanoClaw 最革命性的设计是操作系统级隔离：每个智能体都在独立的 Linux 容器中运行 - 在 macOS 上采用 Apple Containers，在 Linux 上使用 Docker。容器内只有智能体循环和 Anthropic 智能体 SDK，文件系统访问受挂载白名单限制，敏感路径（如 .ssh、.aws）被自动屏蔽。

这种架构的防护效果立竿见影：

攻击场景	OpenClaw	NanoClaw
提示词注入	突破后可访问宿主机	破坏范围限制在容器内
恶意插件	可能窃取宿主机数据	无法访问未挂载的目录
权限滥用	需应用层权限声明	默认无权限，需显式挂载

这正是 Karpathy 推荐 NanoClaw 的原因：“其核心引擎约 4000 行代码（我和 AI 智能体都能理解，感觉可管理、可审计、灵活等），默认在容器中运行一切。”

四、深入对比：两条路径的哲学差异

4.1 定位：全能平台 vs. 专精助手

OpenClaw 要做 AI 智能体的通用编排层，覆盖所有场景；NanoClaw 则专注于为 Claude 用户提供一个安全、可定制的执行环境。

4.2 代码规模：40 万行 vs. 500 行核心

OpenClaw 的复杂架构依赖社区贡献不断丰富生态；NanoClaw 通过极简核心让用户按需定制，保持可审计性。

4.3 安全机制：应用层权限 vs. 操作系统隔离

OpenClaw 在 Node.js 进程内模拟沙箱；NanoClaw 用容器实现真正的隔离，默认拒绝一切权限。

4.4 设计理念：配置驱动 vs. 技能驱动

OpenClaw 通过 YAML 配置文件声明功能；NanoClaw 的“技能高于功能”理念鼓励用户通过 AI 修改源码来定制，避免代码臃肿。

五、实际应用：你应该选哪只“龙虾”？

如果你需要：

处理多样化的任务、集成多种 AI 模型
快速尝试各种插件生态
不介意安全风险，或在可控的内网环境使用

OpenClaw 的开放生态更具优势。你可以在腾讯云、阿里云上一键部署，几分钟内拥有一个功能强大的 AI 助手。

如果你的核心诉求是：

数据安全和可审计性
深度绑定 Claude 模型，不需要多模型切换
希望 AI 能访问公司内部系统，但又担心权限失控

NanoClaw 的容器化架构更值得信赖。你可以把它部署在自己的服务器上，每个群组独立容器，敏感数据通过挂载白名单严格管控。

一个有趣的混合方案

对于企业级部署，或许两者结合才是最佳实践：在 OpenClaw 的生态基础上，借鉴 NanoClaw 的隔离理念 - 用容器包装 OpenClaw 实例，每个客户或每个项目分配独立容器，既享受插件生态，又获得安全隔离。

六、未来展望：两条路，同一个方向

OpenClaw 与 NanoClaw 的对比，本质上是 AI 智能体发展中“广度”与“深度”、“开放”与“安全”两种价值观的碰撞。

OpenClaw 代表了一条“大而全”的路径：通过开放的插件生态和多模型支持，成为 AI 的通用入口。它的挑战在于如何在保持扩展性的同时，解决代码臃肿带来的安全隐忧。

NanoClaw 则展示了“小而精”的可能性：通过容器化隔离和极简核心，在保证安全的前提下提供高效的企业级自动化能力。它的局限在于深度绑定 Claude 模型，缺乏多模型灵活性。

但无论哪条路，它们都在朝着同一个方向前进：让 AI 真正成为能替我们干活的数字员工，同时把控制权牢牢握在自己手中。这种“自托管的 Claude Code”模式，正是 AI 从 SaaS 回归私有化部署的典型代表 - 既要云的弹性，又要本地的控制权。

当你把数字资产的钥匙交给 AI 时，你更需要的或许不是一个功能繁多但内部复杂的“黑箱助手”，而是一个你能完全理解的“透明管家”。这个选择，将决定你未来与 AI 协作的方式。

附录：关于 NanoClaw 的常见问题解答

Q1：NanoClaw 现在支持多个会话吗？如果需要同时处理多个对话，应该怎么启动？

A1：支持，而且是自动的、容器级的隔离。NanoClaw 的设计是：每个群组（或频道）都在独立的容器中运行。你不需要手动“新建会话”，只需把 AI 拉进不同的 Telegram 群组（或 WhatsApp 群组），系统就会自动为每个群组创建一个独立的容器，拥有独立的记忆（CLAUDE.md）、文件系统和上下文。主控频道（你与机器人的私聊）可用于管理所有活跃群组。

Q2：NanoClaw 可以通过 Telegram 使用吗？我现在只用了一个机器人对话，相当于只有一个会话，希望有多个。

A2：可以，有两种主流方式：

标准版 NanoClaw + Telegram 技能：在 Claude Code 中运行 /add-telegram 命令，AI 会自动修改代码添加 Telegram 支持。
直接使用 Venice 分支（nanoclaw-venice）：这个分支原生支持 Telegram 和 WhatsApp 双通道，安装向导会引导你选择接入方式，开箱即用。多会话机制同上 - 把机器人拉进不同群组即可。

Q3：Venice 分支是怎么回事？和原版有什么不同？

A3：Venice 分支是 NanoClaw 的一个定制版本，主要特点：

AI 提供商换成 Venice：不需要 Anthropic API key 或 Claude 订阅，使用 Venice 的隐私优先 API，按 token 付费。
原生支持 Telegram 和 WhatsApp：安装向导直接可选，免去手动添加技能的步骤。
保持容器化隔离：每个群组独立 Docker 容器，延续 NanoClaw 的核心安全设计。
代码更精简：约 2000 行，易于审计和定制。

Q4：NanoClaw 是用 Python 实现的吗？

A4：不是，NanoClaw 核心是用 TypeScript/Node.js 编写的。你可能联想到的是 OpenClaw 生态中的一个 Python 轻量级框架 Nanobot（约 4000 行 Python），它提供了类似的自动化能力，但没有 NanoClaw 的容器级隔离。两者是不同的项目。