nanobot

nanobot 是由香港大学数据智能实验室（HKUDS）于 2026 年 2 月开源、以 MIT 许可发布的超轻量级个人 AI Agent 框架，核心定位是“一个任何人都能在 5 分钟内启动、一个周末就能读完全部源码的 Agent 运行时”——用约 4,000 行纯 Python 代码实现了 OpenClaw 同类产品的核心能力，代码量约为后者的 1%，安装体积约 5 MB，运行内存门槛低至 1 GB，而 OpenClaw 通常需要 2 GB 以上。它不试图做“全能的 Agent 平台”，而是把可读性、可审计性、可改造性作为第一设计约束：核心 agent loop 保持小而透明，工具调用、记忆、MCP、多渠道、定时任务和子 Agent 都围绕这个环展开，WebUI、TUI、Telegram、Slack、Discord、飞书、微信等入口共享同一个运行时。截至 2026 年 10 月，项目已积累约 49K Star、8,000 以上 Fork，最新版本为 v0.3.5（2026 年 9 月），提交活动仍在持续。但它的“轻”是一把双刃剑：小到能读完，也小到很多工程细节仍在打磨之中。

一、nanobot 是什么

nanobot 的诞生背景是一个已经被反复验证的痛点：Agent 框架正在变得不可读、不可审计、不可改造。LangChain 约 50 万行，AutoGPT 约 10 万行，OpenClaw 膨胀到 43 万行以上，部署一台“AI 战斗机”需要推荐 4 GB 以上内存、冷启动 8 到 12 秒，对个人开发者和研究者来说，理解、审计和二次开发的成本已经高到不划算。HKUDS 的解法不是“再做一个更大的平台”，而是做减法：把 agent 的核心循环抽出来，只保留“构建上下文 → 调用模型 → 执行工具 → 把结果喂回模型”这条最小闭环，其余能力以可插拔的方式挂在环外。官方对 nanobot 的自我描述是 “ultra-lightweight, open-source, self-hosted personal AI agent framework”，它本身不执行推理——推理交给 OpenAI 兼容 API、Ollama、vLLM 或 15+ 家模型供应商，nanobot 只做那个“把模型、工具、记忆和渠道串起来”的运行时。

架构上，nanobot 由一个 Python gateway 拥有 agent 执行、会话、工具、记忆和安全策略，WebUI、TUI 和聊天应用作为客户端共享同一个运行时；会话以 JSONL 持久化，长期记忆写入 MEMORY.md 并可通过 Dream 机制提炼，技能以文件形式存放在 workspace 中，MCP 服务器在配置中声明后暴露为可调用工具。这种“一个进程、一份会话文件、一个可读的核心循环”的形态，与它“you can truly own”的定位完全一致：出了问题，你可以直接打开文件看模型当时拿到了什么上下文、调用了什么工具、记忆里写了什么，而不是在一个分布式平台的黑箱里排查。

二、nanobot 能做什么

极简 agent 核心与工具调用——不是功能最多，而是每一行都能被读懂。nanobot 的内置工具覆盖文件读写/编辑、shell 执行、网页搜索与抓取、MCP、cron 定时任务、图像生成和子 Agent 委派，足够支撑“让 Agent 真正做事”的日常需求，但没有任何为了“功能清单好看”而堆叠的冗余模块。它的价值不在工具数量，而在工具与核心循环之间的接线是透明的：你可以打开 tools/ 目录，看到一个工具从声明、参数 schema 到执行结果回填的完整路径，然后照着写一个自己的。

多模型与多渠道——模型不锁定，入口跟着你走。对话模型可以是 OpenAI、Anthropic、DeepSeek、Kimi、MiniMax、OpenRouter、AWS Bedrock、NVIDIA NIM，也可以是本地 Ollama、vLLM、LM Studio 上的任意 OpenAI 兼容端点；fallback_models 允许你列出降级序列，主模型不可用时自动切换。渠道侧支持 WebUI、终端、Telegram、Discord、Slack、飞书、微信、Email、Mattermost、Teams、Linear 等 10 个以上入口，且跨渠道会话可以在同一个运行时中统一管理。

记忆与 Dream——跨会话的事实留存，文件可读、可改、可删。nanobot 的会话历史以 JSONL 持久化，长期记忆沉淀到 workspace 中的 MEMORY.md；Dream 机制负责从会话中发现可复用的技能和事实，v0.1.5 之后进一步拆分为“发现”与“巩固”两阶段，并加入了按需的语义检索与 token 预算控制。和把记忆封装成黑盒向量库的做法不同，nanobot 的记忆首先是你可以用编辑器打开的文件——这也意味着它的记忆能力在长周期、大项目场景下仍有明显局限，社区中已有关于“细节保留吃力”的反馈。

MCP 原生与技能体系——从设计第一天就按协议扩展，而不是事后打补丁。MCP 服务器在配置中声明即可接入，stdio 和 HTTP 两种传输方式都支持；技能以 workspace 中的文件形式存在，v0.1.5 引入的 Dream 技能发现让 Agent 可以在运行过程中“学到”新技能并沉淀下来。与 OpenClaw 大量依赖内置集成不同，nanobot 的扩展路径更接近“协议优先”：外部能力通过 MCP 进来，内部能力通过技能文件出去，核心保持不动。

定时任务与子 Agent——把“重复动作”和“并行子任务”做进核心循环。cron 工具支持一次性提醒、固定间隔和标准 cron 表达式三种调度方式，Agent 自己就能在对话中创建、列出和管理定时任务；子 Agent 允许主 Agent 把可以并行的子任务 spawn 出去，各自在独立的上下文中执行后汇回。配合 WebUI、API 和聊天渠道，这构成了“长期运行的个人 Agent”最基本的自动化骨架。

WebUI、Python SDK 与 OpenAI 兼容 API——能自己用，也能嵌进你的东西里。nanobot 自带浏览器 UI 和终端 TUI，同时暴露 Python SDK 和 OpenAI 兼容的 Agent API（含 SSE 流式输出），你可以把它当作一个可编程的 Agent 后端，用自己的脚本、机器人或前端来消费。这一点在同类轻量框架中并不常见：很多项目要么只给 CLI，要么只给 Web，nanobot 把“交互界面”和“集成接口”都收进了同一个运行时。

三、nanobot 适合谁用

想真正读懂一个 Agent 框架、而不是调 API 碰运气的开发者。4,000 行代码意味着你可以在一个周末通读核心，理解上下文如何拼装、工具调用如何解析、记忆如何写入、错误如何回传。对于想从“用框架”进阶到“改框架”甚至“写自己的框架”的人，nanobot 是目前开源生态中可读性/功能完整度比最高的选择之一。

机器资源有限、但仍想要一个可长期运行的个人 Agent 的用户。1 GB 内存、约 5 MB 安装体积，Raspberry Pi 4 上就能跑；官方最低规格 0.5 vCPU / 256 MB RAM，推荐 1 vCPU / 2 GB RAM。如果你手上有一台闲置的小主机、软路由或 ARM 板子，nanobot 的门槛比 OpenClaw 低一个数量级。

需要在微信、飞书、钉钉等中文生态渠道中使用 Agent 的用户。主流重型框架的渠道覆盖往往以 WhatsApp、Telegram、Slack 为先，对微信、飞书、企业微信的支持要么缺失、要么靠第三方桥接。nanobot 原生覆盖飞书、微信、QQ、企业微信，并提供流式响应和媒体消息支持，在中文工作流中是实际的差异化优势。

想把 Agent 嵌进自己 Python 项目或脚本的技术用户。Python SDK 和 OpenAI 兼容 API 让 nanobot 可以作为一个“Agent 运行时”被外部程序调用，而不是只能通过聊天窗口交互。如果你需要的是一个可编程的、可审计的 Agent 组件，而不是一个成品助手，nanobot 的接口面比大多数同类项目更直接。

对“数据与运行时全部在自己手里”有执念的自托管用户。会话、记忆、技能、配置都在本地文件系统中，没有必须依赖的外部数据库或托管服务；模型可以完全走本地 Ollama/vLLM，整个 Agent 的“状态”你都可以用 cat、grep 和编辑器直接检查和修改。

不适合谁，同样清晰。 如果你想要的是开箱即用、功能齐全、稳定到可以当生产工具的助手，nanobot 不是：社区中关于稳定性（“very not stable”）、工具调用偶尔只完成一步就报告完成、WebUI 重启后会话卡住等反馈并不少见，项目版本号仍停留在 0.x，API 和行为仍可能变化。如果你需要企业级的权限模型、SSO、集中策略和合规审计，nanobot 的 restrictToWorkspace 被社区指出并非真正的沙箱——shell 命令在执行期间仍可访问工作区之外的文件，安全边界更多依赖审批和运维纪律，而不是内核级隔离。如果你追求的是渠道最广、原生应用最全、插件生态最丰富，OpenClaw 仍然是那个“更大更重但覆盖更全”的选择；nanobot 明确是“小而够用的核心 + 你自己补齐的周边”。

四、nanobot 的应用场景是什么

个人服务器的 7×24 常驻助手——你有一台始终在线的小主机，希望它能在 Telegram 或飞书里响应消息、读写文件、执行 shell、按计划运行任务，同时资源占用低到不影响机器上的其他服务。nanobot 的 1 GB 内存起步和单进程运行时让这种“常驻但不喧宾夺主”的部署成为可能。

中文 IM 工作流中的自动化入口——你在飞书或微信里接收任务、转交文件、需要定时提醒和简单自动化。nanobot 对这些渠道的原生支持和流式响应，使它可以直接嵌进已有的沟通习惯，而不是要求你打开一个新的 Web 应用。

量化、监控、日报等定时任务的轻量宿主——你用 cron 让 Agent 每 10 分钟检查一次某个指标、每天早上生成一份简报、或定时拉取数据并写入文件。nanobot 的 cron 工具和子 Agent 并行能力让这些任务不需要一个重型调度系统，Agent 自己就是调度器。

Agent 框架的学习与教学——你想理解 Agent 到底是怎么工作的，而不是背 LangChain 的抽象。nanobot 的源码规模让“读完全部核心代码”成为现实可行的学习目标；HKUDS 的学术背景和围绕该项目形成的教程生态，也使它成为 Agent 课程和面试准备的常见素材。

嵌入式 Agent 组件——你的 Python 应用需要一个“能调工具、有记忆、可接入聊天渠道”的 Agent 层，但不想引入一个独立服务或庞大依赖。nanobot 的 Python SDK 和 OpenAI 兼容 API 让你可以把 Agent 当作一个库来用，而不是当作一个平台来运维。

五、nanobot 为什么值得关注

“代码量本身就是一种功能”。在 Agent 框架普遍以“支持多少集成、多少工具、多少渠道”作为卖点的竞争里，nanobot 提出了一个反向命题：可理解性是一种被低估的能力。4,000 行代码意味着一个开发者可以在一天内建立完整的心理模型，知道每一行代码在做什么；出问题时不需要在层层抽象之间“猜”，而是可以直接追踪从用户消息到工具执行再到模型回复的完整路径。这种“小到能读完”的品质，在 2026 年的 Agent 生态中已经接近稀缺。

它把“拥有”从口号变成了文件系统里的事实。会话是 JSONL，记忆是 MEMORY.md，技能是文件，配置是 JSON，模型走你自己的 API key 或本地推理。没有隐藏的托管状态，没有必须依赖的外部数据库，没有“导出”这一步——你随时可以用 grep 搜索记忆、用编辑器改一条技能、用 git 管理整个 workspace。在一个“个人 AI”越来越多地被包装成云端黑盒的时代，状态的透明性本身就是一种产品立场。

中文渠道的原生覆盖，补上了一个真实的市场空白。OpenClaw 等项目的渠道列表里，微信和飞书要么缺席，要么需要额外桥接；nanobot 把飞书、微信、QQ、企业微信放进了第一批渠道，并持续打磨流式、媒体和域支持。对于工作流扎根在中文 IM 生态中的用户，这不是“锦上添花的功能”，而是能不能用起来的分界线。

MCP 原生 + 协议优先，让“轻”不等于“封闭”。nanobot 没有因为核心小而砍掉扩展性：MCP 从第一天就是一等公民，技能以文件形式存在，工具接口面向外部开放。它的哲学是“核心保持最小，扩展通过协议和文件进行”，而不是“核心什么都有，但每加一个功能都要改核心”。这让它既适合当成品用，也适合当底座改。