Nanobot - 超輕量級個人AI智慧體框架

解決什麼

Nanobot針對大型AI Agent框架(如OpenClaw)動輒40萬行程式碼、配置複雜、難以理解和定製的痛點,提供一個僅4000行Python核心程式碼的極簡替代方案。它將智慧體執行時的不可約簡要素——迴圈排程、模型抽象、工具分發、聊天閘道器——壓縮到最小可用集,同時保留長期記憶(Dream)、MCP協議整合、多智慧體委託、定時任務自動化等生產級功能。開發者可以在瀏覽器WebUI、終端或Telegram/Discord/微信/飛書等聊天應用中執行個人AI助手,完全自託管,無需依賴商業平臺。

為何火

該專案在GitHub獲得4.6萬星標,HN討論獲257點贊128條評論,核心吸引力在於極致的程式碼精簡與功能完整性的平衡。社群開發者普遍認同"99%的程式碼縮減來自剔除RAG管道、複雜規劃器、多智慧體編排UI和生產運維層",而保留的核心恰好是個人助手場景的必需品。相比需要團隊維護的重型框架,Nanobot的可讀性讓個人開發者能在週末理解全部實現並按需魔改。其MIT協議、Docker一鍵部署、多聊天平臺整合(尤其支援國內微信/飛書)、本地LLM相容等特性,使其成為自建AI助手的實用起點。

核心功能

• 多模型路由與降級: 支援OpenAI、Anthropic、本地LLM等相容API,可配置主備模型自動切換
• 工具生態: 內建檔案操作、Shell執行、網頁搜尋/抓取、影像生成、子智慧體呼叫、定時任務(cron)
• MCP協議整合: 原生支援Model Context Protocol,可擴充套件第三方工具服務
• 長期記憶(Dream): 會話歷史與知識持久化,支援跨會話上下文檢索
• 多智慧體協作: 主智慧體可委託子智慧體處理專項任務,避免單一智慧體許可權過大(社群討論的"致命三要素"防範)
• 聊天應用閘道器: 官方支援Telegram、Discord、Slack、微信、飛書、Mattermost、郵件,統一訊息路由
• WebUI與API: 內建瀏覽器介面配置模型與工具,暴露OpenAI相容API供第三方整合
• 定時自動化: 基於croniter實現週期性任務觸發,可執行長時程目標

安裝

一鍵安裝(推薦桌面環境):

# macOS/Linux
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh

# Windows PowerShell
irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1 | iex

指令碼自動檢測環境,優先使用虛擬環境/uv/pipx安裝PyPI穩定版,桌面環境直接啟動WebUI配置。

手動安裝:

# PyPI穩定版
pip install nanobot-ai

# uv快速安裝
uv tool install nanobot-ai

# 原始碼最新特性(需bun/npm構建WebUI)
git clone https://github.com/HKUDS/nanobot.git
cd nanobot && pip install -e .

Docker部署:

docker compose up -d  # 啟動gateway(18790/8765埠)與API服務(8900埠)

首次執行執行nanobot webui開啟配置介面,在Settings → Models新增OpenAI Key或本地模型端點。國內使用者可配置通義千問、智譜等相容API,或用Ollama跑本地模型無需外網。

適合誰

• 個人開發者想自建AI助手但不想啃大型框架原始碼
• 隱私敏感使用者需要完全自託管、資料不出本地的方案
• 多平臺整合需求要在Telegram/微信/Slack等聊天工具統一呼叫AI
• 本地LLM愛好者希望用Ollama等工具跑開源模型,避免API費用
• 快速原型驗證需要週末搭建可用Agent演示,而非生產級企業部署

不適合: 需要開箱即用的複雜RAG檢索、多智慧體視覺化編排、企業級許可權管理的團隊,建議選LangChain/AutoGPT等成熟方案。

社群評價

HN討論熱度257點,核心爭議集中在RAG與多智慧體的必要性。支持者認為"讓編碼智慧體通過管理資料夾實現記憶比RAG更直觀",且子智慧體模式避免主智慧體許可權過大的安全風險。反對者指出"一旦記憶超過數百行文本,RAG的檢索效能優於直接塞滿上下文",並引用Anthropic 2023年的針刺實驗證明長上下文仍有召回問題。有開發者提到Simon Willison的"致命三要素"理論(智慧體同時擁有程式碼執行+網路訪問+資料讀寫許可權),建議任務分解到多個受限智慧體並用資料管道隔離。

正面觀點: "4000行可讀核心讓我終於理解Agent執行時本質"、"Docker一鍵部署+微信整合太適合國內個人使用者"、"MIT協議可以放心商用魔改"。負面擔憂: "773個開放issue說明快速迭代帶來穩定性問題"、"缺少視覺化工作流編排,複雜任務需手寫Python"、"文件雖有中文但配置項說明不如商業產品詳細"。

選型對比

vs OpenClaw: Nanobot是其極簡替代,程式碼量從40萬行降至4000行(99%),剔除RAG管道、視覺化編排器、生產運維層,保留核心Agent迴圈與工具呼叫。OpenClaw適合企業團隊需要開箱即用的完整解決方案,Nanobot適合個人開發者要可讀可改的最小核心。

vs LangChain/LlamaIndex: 後者是通用LLM應用開發框架,提供豐富的元件庫但學習曲線陡峭。Nanobot專注個人助手場景,內建聊天閘道器、長期記憶、定時任務等開箱即用功能,程式碼量小適合快速上手。

vs AutoGPT: AutoGPT強調自主規劃與長時程目標執行,Nanobot更輕量且支援多聊天平臺整合,適合日常互動式助手而非完全自主的後臺Agent。

已知坑

1. RAG缺失: 官方移除了向量檢索,記憶依賴Dream的檔案管理。社群反饋超過數百行文本後檢索效能下降,需自行整合Chroma/Pinecone等向量庫。
2. 773個開放issues: 快速迭代導致bug修復滯後,生產環境建議鎖定PyPI穩定版(v0.3.0)而非main分支。
3. WebUI構建依賴: 原始碼安裝需bun或npm,國內網路可能遇到依賴下載慢,建議配置映象或直接用PyPI預構建包。
4. 多智慧體無視覺化: 子智慧體呼叫需手寫Python配置,缺少LangGraph式的圖形化編排介面。
5. 中文文件滯後: 雖提供中文版但更新慢於英文,複雜配置(如MCP整合、Langfuse追蹤)需參考英文文件或原始碼註釋。
6. 聊天應用限流: Telegram等平臺有API呼叫頻率限制,高頻互動可能觸發封禁,需自行實現速率控制。

來源: GitHub (https://github.com/HKUDS/nanobot) + Hacker News討論