nanobot: Ein extrem schlankes, selbst gehostetes Framework für persönliche KI-Agenten mit einem Gateway für Browser, Terminal und Chat-Apps

Der erste Satz der README von HKUDS/nanobot ist eindeutig: ein extrem schlankes, quelloffenes, selbst gehostetes Framework für persönliche KI-Agenten, geschrieben in Python. Man nutzt es im Browser, Terminal oder in einer Chat-App, um mit Dateien zu arbeiten, Vorlieben zu merken und Aufgaben zu planen. Einen unterstützten Modellanbieter oder lokalen Modellserver muss man selbst anbinden, denn nanobot liefert kein Modell. Stand 13. Oktober 2026 hat das Repository etwa 48.978 Sterne und 8.626 Forks, eine MIT-Lizenz, Python-Code, wurde am 1. Februar 2026 angelegt und zuletzt am 12. Oktober gepusht. Die README nennt fünf Gründe: dauerhafte Arbeitsabläufe, Reichweite über Chat-Apps, Modellfreiheit, einen kleinen lesbaren Kern und die Hoheit über den eigenen Stack.

Der Funktionsumfang ist breit. Es verbindet sich mit Telegram, Discord, Slack, WeChat, E-Mail, Mattermost, Linear und weiteren Kanälen; liest mit eingebauten Dateiwerkzeugen PDF, Word (.docx), Excel (.xlsx) und PowerPoint (.pptx), etwa um Berichte zusammenzufassen; nutzt Shell, Websuche und -abruf, MCP-Anbindungen, Cron, Bilderzeugung und Multi-Agenten-Delegation; bewahrt Sitzungsverlauf und Langzeitgedächtnis über einen Mechanismus namens Dream; führt langfristige Ziele und geplante Automatisierungen aus; bietet ein Python-SDK und eine OpenAI-kompatible API; und lässt sich als dauerhaft laufendes lokales oder serverseitiges Gateway betreiben. Die neueste Version ist v0.3.5, die die Arbeitsumgebung ins Terminal bringt und das Fortsetzen von Gesprächen zwischen Browser, Terminal und Chat-Apps erleichtert, mit bis zu vier nebeneinander angeordneten Gesprächen in der WebUI sowie Kontextverbrauch und Kompaktierungsfortschritt je Runde.

Der Installationsweg ist klar. Nötig ist Python 3.11 oder neuer. Empfohlen ist das Installationsskript: curl install.sh unter Linux und macOS, install.ps1 in PowerShell unter Windows. Es installiert oder aktualisiert nanobot-ai in einer aktiven virtuellen Umgebung, uv, pipx oder einer verwalteten venv unter ~/.nanobot/venv, öffnet auf einem lokalen Desktop die WebUI und bei SSH oder headless den Terminal-Assistenten, und --dry-run zeigt den Plan vorab. Wer die eigene Toolchain bevorzugt, nutzt uv tool install nanobot-ai oder pip. Dann nanobot webui ausführen, in den Einstellungen ein Modell wählen, Zugangsdaten speichern und „Hello!“ senden, um die Verbindung zu prüfen. Mit einem Übungsordner und eingeschränktem Zugriff lässt man es notes.txt lesen und summary.md schreiben und prüft, ob die Dateiberechtigungen wie erwartet greifen. Plattform-Wheels enthalten WebUI und natives Terminal-UI für macOS 13+, Linux mit glibc 2.17+ (ARM64 und x64) und Windows x64; x64 braucht SSE4.2. Für die neuesten Funktionen installiert man aus dem Quelltext, was Git und Bun erfordert.

Die architektonische Abwägung ist das, was es einen kleinen Kern nennt. Das Python-Gateway besitzt Agentenausführung, Sitzungen, Werkzeuge, Gedächtnis und Sicherheitsrichtlinie, und WebUI, TUI und Chat-Apps teilen diese Laufzeit. Die zentrale Agentenschleife baut Kontext auf, ruft das Modell auf, führt angeforderte Werkzeuge aus und gibt das Ergebnis zurück; Gedächtnis, Skills, Kanäle und MCP-Anbindungen erweitern diese Schleife. Das Python-SDK bettet die Laufzeit in den eigenen Anwendungsprozess ein, während die OpenAI-kompatible API einen eigenen HTTP-Dienst für /v1/chat/completions startet; jede Anfrage enthält eine Nutzernachricht, der Verlauf liegt beim Server und das Modell kommt aus der Konfiguration. Die WebUI hält getrennte Themen für verschiedene Aufgaben und bietet temporäre Chats, die nicht in Verlauf oder Gedächtnis gespeichert werden. Die README warnt jedoch: Themen trennen nur den Gesprächsverlauf, Projektordner bestimmen nur, wo die Dateiarbeit stattfindet; keines von beiden erzeugt ein eigenes Langzeitgedächtnis. Eine Instanz teilt Agentenprofil, Gedächtnis und Skills über alle Projekte hinweg; für isolierte Kundendaten oder Vorlieben nimmt man getrennte Instanzen.

Für alle, die selbst hosten, stehen die Sicherheitshinweise voran. Die README sagt, WebUI-Zugang bedeute Verwaltungsrechte über dieselbe Agenteninstanz, also nur an vertrauenswürdige Betreiber weitergeben. Vor dem Anbinden von Chat-Apps sind DM-Kopplung, Allowlist und Gruppenzugriffsregeln jeder Plattform getrennt zu prüfen, denn die Freigabe eines privaten Absenders beschränkt nicht überall den Gruppenzugriff. Geplante Aufgaben brauchen ein laufendes Gateway und einen wachen Host; verpasste Zeitpunkte werden nach einem Neustart nicht nachgeholt. Außerdem senden temporäre Chats ihre Anfragen weiter an den konfigurierten Modellanbieter, und von Werkzeugen erzeugte Dateien bleiben nach dem Schließen bestehen: „temporär“ heißt nicht „nichts wird gesendet“.

Unsere Einordnung: nanobots Wert liegt darin, den persönlichen Agenten zu einem kleinen lesbaren System zu machen statt zu einem an eine Cloud gebundenen Produkt: Man sieht die Kernschleife, entscheidet über das Modell und über den Ort der Daten. Die Vorbehalte sind ebenso klar. Erstens zeigen Sterne und Aktualisierungsrhythmus eine aktive Gemeinschaft, keine Stabilität; die README trennt selbst Stable-Release und aktuellen Quelltext, für den Alltag ist Stable zu wählen. Zweitens hält der Agent Rechte auf Dateien, Shell und Chat-Kanäle, Fehler in den Einstellungen wiegen so schwer wie seine Fähigkeiten; mit eingeschränktem Zugriff und einem Übungsordner beginnen. Drittens hängen Modellkosten oder lokale Hardware von Ihrer Wahl ab, nanobot löst das nicht. Erst auf einer isolierten Maschine oder in einem Container bereitstellen, nur das eigene Chat-Konto mit Allowlist anbinden und nach einer Woche echter Aufgaben beurteilen, ob es einen Dauerplatz verdient.