AI

nanobot：港大團隊打造的輕量級自架個人 AI Agent 框架

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

「我想要一個屬於自己的 AI 助理，跑在自己的機器上，能記得我、能幫我排程、還能在 Slack 或 Telegram 回我訊息。」這個需求聽起來簡單，但現成方案不是太重（一整套企業級平台），就是太陽春（一個 chat UI）。nanobot（HKUDS/nanobot）來自香港大學資料智慧實驗室，主打「超輕量、可自架」，在 GitHub 上已累積約 48.9k stars，最近也持續出現在 AI 開源趨勢榜上。

1. 專案背景與定位

nanobot 是一個 Python 寫成、MIT 授權的個人 AI Agent 框架，官方描述是「Ultra-lightweight, open-source, self-hosted personal AI agent framework」。它可以跑在瀏覽器 WebUI、終端機，或作為長駐的 gateway 接上各種聊天 App。

最新版本為 9 月 15 日釋出的 v0.3.5，帶來原生終端機工作台、多窗格 WebUI 與每輪 context 用量顯示；9 月中下旬又陸續加入可搜尋的供應商設定、Linear 整合、中斷任務的恢復機制等更新，開發節奏相當密集（main 分支已有 4,700+ commits）。

2. 技術架構與核心設計

  • 小而清楚的 Agent 迴圈：訊息從聊天 App 進來，LLM 決定何時呼叫工具，記憶與 skill 只在需要時才作為 context 帶入。官方強調核心保持「易讀、易擴充」。
  • 內建工具集：檔案、shell、網頁搜尋與擷取、MCP、cron 排程、圖片生成、subagent。
  • 記憶系統「Dream」：處理對話歷史與長期記憶（README 未詳述儲存與檢索細節）。
  • 多通道 Gateway：支援 Telegram、Discord、Slack、微信、飛書、Email、Mattermost、Linear 等，nanobot gateway --background 可在關閉終端機後持續運作。
  • WebUI 開箱即用：隨 wheel 一起發佈，不需另外 build 前端；支援最多四個並排對話、顯示工具呼叫與檔案 diff、管理 MCP Apps、Skills 與 Automations。
  • 模型彈性：支援 OpenAI 相容 API、Ollama/vLLM 等本機模型與 fallback 模型；另提供 Python SDK 與 OpenAI 相容 API，方便嵌入其他系統。

3. 社群熱度與生態採用

約 48.9k stars、8.6k forks，open PR 高達 624 個，顯示社群貢獻非常活躍。官方合作夥伴列出 Kimi 與 MiniMax，並有 Discord、X 與微信／飛書社群。部署方面支援 Docker、Docker Compose、Linux service、macOS LaunchAgent，以及 Render 一鍵部署，對個人與小團隊都算友善。

4. 局限性與潛在風險

  • shell 與檔案工具的權限面：一個能執行 shell、能被聊天訊息觸發的長駐 Agent，等於在你的機器上開了一個遠端操作入口。務必限制哪些帳號能對它下指令，並善用 Restricted 存取模式。
  • 聊天平台成為攻擊入口：接上 Slack、Telegram 後，任何能傳訊息給 bot 的人都可能嘗試 prompt injection；網頁擷取的內容同樣可能夾帶惡意指令。
  • 安全警示：GitHub 頁面顯示有 5 個 security alerts，雖然 repo 有 SECURITY.md，但 README 沒有完整的威脅模型說明。
  • 雲端部署的憑證管理：Render 部署需要 ANTHROPIC_API_KEY 與 NANOBOT_WEB_TOKEN，token 外洩就等於 Agent 被接管。
  • 快速迭代的穩定性：更新頻率很高，對追求穩定的生產環境來說，升級前需要測試。

5. 應用價值與適用場景

適合想要「自己掌控資料、又想要多通道存取」的個人開發者與小團隊：例如讓 Agent 每天早上整理資訊推到 Telegram、在 Slack 裡幫團隊查文件、或透過 cron 定期執行腳本。WebUI 的工具呼叫與 diff 可視化，也讓人比較容易理解 Agent 到底做了什麼。

如果你需要的是嚴格的企業權限控管與稽核，nanobot 目前的定位仍偏向個人工具，需要自行補強。

Monday 的觀點與架構建議

  • nanobot 證明了「個人 Agent」不需要複雜的平台：一個清楚的 Agent 迴圈 + 工具 + 記憶 + 通道 gateway，就能涵蓋大部分日常需求。想自建 Agent 的人可以把它當作架構參考。
  • 部署時把「誰能對 Agent 下指令」當成第一優先的安全設計：通道白名單、預設 Restricted 模式、shell 工具獨立沙盒（repo 中的 docker-compose.bwrap.yml 值得研究）。
  • 長期記憶是雙面刃——記得越多越好用，但也越容易被污染。建議定期檢視與清理記憶內容。
  • 學術團隊主導的開源 Agent 框架正在快速追上商業產品的體驗，這對想避免供應商鎖定的使用者是好消息。

參考來源