Nanobot 轻量AI智能体走红：它为何越小越能用

字数 2381，阅读大约需 12 分钟

最近这两个月，Agent 框架的竞争有点卷到极致了。

一方面，OpenClaw、Claude Code、Codex 这类工具持续朝“全能工作台”演进：功能越来越多，界面也越做越完整，整套生态看起来越来越厚。

另一方面，Nanobot 这种更小的框架忽然出现，反而显得格外耐看。

Nanobot（由香港大学数据系统实验室 HKUDS 推出，nanobot.wiki）是一款面向个人或小团队的超轻量本地 AI 助手，定位是成为 OpenClaw 的轻量替代方案。它可以对接多种社交与办公平台（Telegram、Discord、飞书、钉钉等），让具备工具调用能力的智能体在这些环境里运行。它并不急着上来就讲宏大的多智能体协作，也不会把自己包装成企业级自动化平台。它最核心、也最朴素的卖点是：把一个能够长期运行、能接入聊天工具、能使用工具、还能保留上下文的个人 Agent，做成足够小、足够好读、足够容易动手改的形态。

Nanobot 官方将其描述为开源、超轻量的个人 AI Agent，并表示灵感来自 OpenClaw、Claude Code 与 Codex。它强调让核心 Agent loop 保持“小而清晰”，同时兼顾聊天入口、记忆能力、MCP 以及可落地的部署路径。

很多 Agent 框架真正的痛点，并不是“不能用”，而是“用久了就不敢改”。

一层层抽象、一堆配置、一堆插件，还有看起来很先进的编排逻辑。刚开始当然很爽，跑个 demo 往往十分钟就能搞定。可当你真的要把它接到自己的工作流里，比如飞书消息、定时提醒、文件处理、本地脚本、MCP 工具、私有模型等，麻烦就会接踵而来。

你会搞不清楚它到底把决策放在了哪里，也看不出来上下文究竟是在何时塞进去的，更不知道工具调用失败以后是谁来兜底。

而 Nanobot 的思路几乎是反着来的。

它尽可能把主路径做薄：消息从聊天应用进来，LLM 只在需要时决定是否调用工具；记忆和 Skills 也只在确实需要作为上下文时才被拉取出来，而不是把整个过程变成一套厚重的调度层。

这件事非常关键。

因为对个人 Agent 来说，最难的从来不是“能不能干活”，而是“出了问题你能不能看明白”。看不明白，就只能把希望寄托在运气上；看得明白，才有资格把它改成适合自己的版本。

我起初还以为它只是把 OpenClaw 做了一个更极简的变体，适合用来研究 Agent 的基本原理。但翻阅近期资料后，才发现它已经在往更实用的方向走。

它支持多种聊天入口，比如 Feishu、Slack、Discord、Telegram、WeChat、QQ、邮件等；同时也提供 MCP、记忆与定时任务能力，并且给出 Docker、Linux service 等部署方式。

这说明它并不是那种只在命令行里跟你聊聊天的小项目，而是可以作为常驻助手持续工作。

比如你可以让它每天早上帮你抓取行业信息，晚上再把汇总结果发到飞书；也可以接入 MCP 工具，让它去查资料、跑脚本、读文档；甚至把它放在服务器上，通过聊天软件响应你的指令。

它并不会像大型 Agent 平台那样从一开始就替你把一切安排妥当，但它给的是一套你可以自己改的骨架。

如果只会聊天，Nanobot 当然不算稀奇。

真正让我觉得它有意思的，是它开始具备一个长期运行的 Agent 应该具备的几项基础能力：工具调用、记忆、定时任务，以及对外部服务的接入。

例如官方案例里就包括搜索任务、代码任务、定时任务和记忆任务。它们听起来不一定“炫”，但都很落地。

个人 Agent 未来大概率不会每天陪你闲聊，而是在固定场景里替你处理重复事务：查资料、整理信息、跑脚本、提醒事项、汇总日报、处理一些简单代码类任务。

这些事情并不算大，但只要能稳定跑起来，就会变得很有价值。

Bright Data 也做过一个 Nanobot 与 MCP 的实操教程：把 Nanobot 和 Bright Data 的 MCP Server 组合起来，让 Agent 获得网页搜索、网页抓取、结构化提取以及浏览器自动化等能力。

这类案例表明，Nanobot 不只是“能跑起来”，而是已经能够被接入更真实的数据获取与自动化任务中。