nanobot：一个把记忆、工具和定时任务塞进小核心的 Python AI Agent

它解决的是个人 Agent 的碎片化问题

nanobot 面对的问题很具体：一个自托管的 AI Agent 要跑起来，通常得拼凑多个组件，模型调用、工具执行、记忆存储、聊天接入各是一套东西。nanobot 把这些收进一个 Python 包，你装完就能在 WebUI 或终端里用。它面向的是个人或小团队，不是企业平台。README 里反复强调 self-hosted 和 personal，说明它默认你愿意自己管服务器和配置。它不试图成为多租户平台，也没有提到权限管理或审计日志。

核心机制：模型路由、工具、记忆和委托在一个循环里

从 README 的结构看，nanobot 的核心是一个循环：接收消息，调用模型，模型决定用哪个工具，执行工具，把结果送回模型，再输出。它支持 OpenAI 兼容 API 和本地 LLM，这意味着模型层是插拔的。工具包括文件、shell、web search、web fetch、MCP、cron、图像生成和 subagent。其中 subagent 是委托机制，主 Agent 可以把任务拆给子 Agent，但 README 没说清拆分的粒度或通信方式。记忆部分叫 Dream，文档里只提到它能保持 session history 和 long-term memory，具体实现是向量库还是摘要重写，没有细节。

安装和启动：从一条命令到配置模型

安装路径分稳定版和源码版。稳定版用 pip 或 uv：`python -m pip install nanobot-ai` 或 `uv tool install nanobot-ai`。一条命令的安装脚本也提供，macOS/Linux 是 `curl -fsSL .../install.sh | sh`，Windows 用 PowerShell 的 `irm ... | iex`。脚本默认从 PyPI 装，然后在桌面环境启动 `nanobot webui`，你到 Settings → Models 里配第一个 provider 和 model。如果你不想改环境，加 `--dry-run` 可以只看计划。源码安装需要 Git 和 Bun，因为源码树直接跑 TUI，而不是下载发布版二进制。这个设计意味着源码版和 PyPI 版的 TUI 行为可能不一致，README 明确说源码版是给想要最新特性的人。

聊天应用接入是它的主要入口，但配置细节在文档里

nanobot 支持 Telegram、Discord、Slack、WeChat、Email、Mattermost 等聊天应用，README 里列了一串，但具体怎么连，比如 bot token 放哪个配置键、是否需要 webhook，都指向 `docs/chat-apps.md`。这意味着核心 README 只是入口，实际部署你得翻文档。对普通用户来说，这个门槛不低，但对愿意读文档的人，好处是每个平台都有专门说明。值得注意的是，WebUI 和 TUI 是内置的，聊天应用是插件式的，这种分层让核心保持小，但代价是你要自己处理每个平台的认证细节。

定时任务和长期目标：cron 工具与 Dream 记忆

nanobot 把 cron 作为工具内置，这意味着你可以让 Agent 按计划执行任务，比如每天定时抓取网页。长期目标（long-horizon goals）和定时自动化是它的卖点，但 README 没说这些目标是怎么持久化的，也没说失败重试的策略。Dream 是记忆机制，名字很形象，但文档里只有一句：保持 session history 和 long-term memory。没有说记忆是存在 SQLite、向量数据库还是文件里，也没有说记忆如何被检索。对依赖记忆的 Agent 来说，这是个关键盲点。如果你要做需要跨会话记住用户偏好的应用，得先确认 Dream 的实现是否满足你的检索需求，否则可能得自己写记忆层。

限制：小核心意味着你要自己补边界

nanobot 的轻量是双刃剑。它没有内置的权限系统，shell 工具意味着 Agent 能执行任意命令，这在自托管环境里是风险，你得自己限制网络暴露。多智能体委托（multi-agent delegation）听起来强，但 README 没有说明子 Agent 之间如何共享上下文，也没有说并行度控制。另一个限制是模型路由的 fallback 机制，README 提到支持 fallback models，但没说切换条件，比如超时还是错误码。如果你需要精细的模型降级策略，可能要改源码。还有，安装脚本会用 `~/.nanobot/venv` 或 pipx，这意味着它不碰系统 Python，但如果你在服务器上跑，得注意 PATH 问题，README 也提醒了。

替代方案：对比 LangChain 和 Dify 的差异

和 LangChain 相比，nanobot 的差异在架构哲学。LangChain 是一个库，你写代码编排链和 Agent，它不提供 WebUI 或聊天接入。nanobot 是一个运行时，装完就有界面和聊天连接，你配置而不是编程。Dify 则是一个更重的平台，提供可视化编排、知识库和团队协作，但部署复杂度高，核心不是 Python 可读的小代码。nanobot 的定位在两者之间：比 LangChain 更开箱即用，比 Dify 更轻、更可读。如果你需要的是在代码里完全控制每一步，LangChain 更合适；如果你要的是给非技术用户用的界面，Dify 更合适。nanobot 适合那些想要一个能改的运行时，而不是一个框架或一个平台。

维护成本与许可：MIT 下的可扩展性

nanobot 采用 MIT 许可，这意味着你可以改源码、商用，只要保留版权声明。它的维护节奏看起来活跃，v0.3.0 在 2026 年 7 月发布，距离 v0.2.2 一个月。但版本号还在 0.x，API 可能不稳定，升级时要看 changelog。源码安装的更新方式是 `git pull --ff-only` 加 editable 依赖同步，这要求你保持 Git 工作区干净。PyPI 版本则用包管理器更新，相对简单。文档提到 published packages 会拉取 checksummed 的 TUI 存档，这降低了供应链风险，但首次使用要下载二进制，离线环境会卡住。整体上，维护成本取决于你选源码还是稳定版，以及你是否愿意跟进 0.x 的 API 变化。

编辑结论

nanobot 适合那些想要一个可读、可改、能自托管的 AI Agent 运行时，并且愿意在 Python 3.11 和 OpenAI 兼容接口的生态里工作的个人开发者或小团队。它不适合需要企业级多租户、复杂权限或大规模并发调度的人，因为文档里没有这些能力，而且它的记忆机制 Dream 和 subagent 委托都还停留在个人工具层面。在采用之前，先确认三件事：你的模型提供商是否兼容 OpenAI API，你的聊天平台是否在支持列表里，以及你是否接受用 cron 和 shell 工具来搭建自动化。如果你需要的是开箱即用的生产级 Agent 平台，nanobot 不是那个答案；如果你想要一个能拆开看、能改的骨架，它值得一试。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes