Lokale KI-Agenten werden oft als offline, gerätespezifisch oder vollständig lokal beschrieben. Wir haben drei Tage damit verbracht, das Ökosystem lokaler KI-Agenten zu kartieren, die autonom auf persönlicher Hardware laufen, ohne auf externe APIs oder Cloud-Dienste angewiesen zu sein.
Unsere Analyse kategorisiert die führenden Lösungen in drei Schlüsselbereiche, basierend auf praktischen Tests mit Entwickleragenten, Automatisierungstools und Produktivitätsassistenten.
Kategorisierung lokaler KI-Agenten
Kategorie | Werkzeuge/Frameworks | Primäre Anwendungsfälle (Lokal / Offline) |
|---|---|---|
Entwickler- und Systemagenten | Goose, Localforge, Devika, Roo Code (Boomerang Mode), Continue.dev, Cursor, CodeGenie, SuperCoder, Aider, Cline, Kilo Code | Lokales Codieren, Debuggen, Datei-/Prozessautomatisierung, lokale DevOps-Aufgaben |
Lokale Automatisierungs- und Steuerungsagenten | Beobachter-KI, Browsernutzung, DeepBrowser | Lokale Browsersteuerung, Dateiautomatisierung, App-Interaktion, Workflows auf dem Gerät |
Wissens- und Produktivitätsagenten | AnythingLLM (Desktop), LocalGPT (Einzelbenutzer), PrivateGPT | Offline-Dokument-Fragen und -Antworten, Zusammenfassung, lokale Suche/Ampel |
Siehe Kategoriebeschreibungen .
1. Entwickler- und Systemagenten
*Ausführungstypen:
- Vollständig lokal : Das Tool läuft nativ auf der persönlichen Hardware mit lokalen Laufzeitumgebungen. Es ist vollständig offlinefähig.
- Hybrid lokal : Das Kernmodell bzw. die Aufgabenausführung erfolgt lokal, aber einige Funktionen, wie z. B. die IDE-Integration, die Kontextindizierung, die Synchronisierung oder das Reasoning, sind weiterhin auf Cloud-Dienste oder APIs angewiesen.
** Erläuterung zur Spalte "auf der Maschine":
- Vollständig gerätebasiert: Die gesamte Offline-Operationsinferenz, das Schließen und die Ausführung erfolgen lokal.
- Lokale Inferenz, Cloud-Unterstützung: Das Kernmodell läuft lokal, aber IDE- oder Verwaltungsfunktionen nutzen Online-Dienste.
- Lokale Ausführung, Remote-Schlussfolgerungen: Der Code wird lokal ausgeführt, aber externe APIs steuern die Schlussfolgerungen oder Planungsschritte.
Gans
Goose ist ein Open-Source-Entwicklungsagent, der so konzipiert ist, dass er vollständig auf lokaler Hardware ausgeführt werden kann. 1
Kernkompetenzen:
- Verwendet lokale LLM-Laufzeitumgebungen für Schlussfolgerungen und Codegenerierung.
- Führt mehrstufige Aufgaben wie das Schreiben, Testen und Debuggen von Code aus.
- Interagiert direkt mit dem lokalen Dateisystem und den Entwicklertools.
- Bei Konfiguration mit lokalen Modellen ist keine Netzwerkverbindung erforderlich.
Goose erfüllt eine strenge Definition eines lokalen autonomen Agenten, da Beobachtung, Schlussfolgerung und Handlung auf dem Gerät selbst erfolgen.
Roo-Code (Bumerang-Modus)
Roo Code ist ein in IDEs integrierter Codierungsassistent, der die iterative Verfeinerung betont.
- Der Boomerang-Modus ermöglicht die lokale Ausführung von Aktionen
- Die Argumentation stützt sich üblicherweise auf Cloud-basierte Modelle.
- Die IDE-Koordinierungs- und Verwaltungsfunktionen sind nicht vollständig lokal.
Daher sollte Roo Code eher als hybrider, auf den Menschen abgestimmter Entwickleragent denn als vollständig lokales System eingestuft werden.
Lokale KI-Agentenkonfiguration in Roo Code:
Roo Code ermöglicht es Entwicklern, benutzerdefinierte Konfigurationsprofile zu erstellen, die definieren, wie die Verbindung zu verschiedenen KI-Modellen, einschließlich lokal gehosteter LLMs, hergestellt wird.
Unter Einstellungen → Anbieter können Sie Profile über OpenRouter oder andere unterstützte Anbieter hinzufügen und dann ein lokales Modell auswählen, das über Ollama oder LM Studio läuft.
Jedes Konfigurationsprofil kann seine eigenen Parameter speichern, darunter Temperatur, Analysetiefe und Token-Limits. Dadurch können Sie zwischen ressourcenschonenden Cloud-Modellen und vollständig lokalen Laufzeitumgebungen für die Inferenz auf dem Gerät wechseln.
Cursor
Cursor ermöglicht die Verwendung lokaler LLMs für Inferenzprozesse, bleibt aber für Folgendes von Cloud-Diensten abhängig:
- Code-Indexierung
- Anwendung bearbeiten
- Workflow-Koordination
Daher unterstützt Cursor zwar lokale Inferenz, aber keine vollständig lokale Agentenschleife und kann nicht offline betrieben werden.
So verwenden Sie einen lokalen LLM innerhalb von Cursor:
Quelle: Logan Halluziniert 2
Helfer
Aider ist ein Open-Source-KI-Programmierassistent für die Kommandozeile, der direkt mit lokalen Git-Repositories arbeitet. Er modifiziert Code durch das Generieren von Patches und Commits, anstatt über eine IDE-Oberfläche zu agieren.
Aider wird häufig bei Cloud-basierten Modellen verwendet, aber:
- Das Tool selbst läuft lokal.
- In Verbindung mit einer lokalen Modelllaufzeitumgebung kann es vollständig auf dem Gerät ausgeführt werden.
Die Offline-Fähigkeit ist daher von der Modellwahl abhängig und keine dem Werkzeug inhärente Eigenschaft.
2. Lokale Automatisierungs- und Steuerungsagenten
Beobachter-KI
Observer AI ist ein Open-Source-Framework für lokale Automatisierungsagenten.
Kernfunktionen:
- Führt Agenten mithilfe lokaler LLMs aus
- Erfasst den Bildschirmstatus per OCR oder Screenshots.
- Führt Python-Code über eine eingebettete Ausführungsumgebung aus
- Benötigt keine Cloud-Verbindung
Observer AI stellt die Infrastruktur für das Verhalten von Agenten bereit, anstatt eine feste Agentenrichtlinie vorzugeben, und lässt sich am besten als lokales Regelsystem beschreiben.
Browsernutzung
Browser-Use ermöglicht KI-gesteuerte Browserinteraktion über Playwright.
- Browseraktionen werden lokal ausgeführt.
- Die Schlussfolgerung kann entweder mit lokalen oder entfernten Modellen durchgeführt werden.
- Der Offline-Betrieb ist nur in Verbindung mit lokaler Inferenz möglich.
Damit fällt Browser-Use standardmäßig in die Kategorie der hybriden Automatisierung.
So verwenden Sie ein lokales LLM innerhalb der Browsernutzung:
Eine Möglichkeit zur Installation besteht darin, den Befehl `pip install browser-use` zu verwenden, der sowohl die Python-Schnittstelle als auch die lokale Browsersteuerung auf demselben Rechner einrichtet.
Bei einem späteren Aufruf (z. B. mit python -m browser_use) wird eine Browserinstanz lokal geöffnet und gesteuert, wobei Aktionen und Schlussfolgerungen entweder über ein lokales LLM (z. B. über Ollama) oder über verbundene APIs ausgeführt werden:
Browser-Nutzung lokal einrichten 3
Für alle, die die komplette Einrichtung in Aktion sehen möchten, gibt es hier eine Schritt-für-Schritt-Videoanleitung, die zeigt, wie man Browser-Use auf einem lokalen Rechner installiert und ausführt:
Die Schritt-für-Schritt-Anleitung umfasst alles von der Installation von Abhängigkeiten wie Playwright und LangChain bis hin zur Verbindung von Browser-Use mit einem lokalen Modell über Ollama. 4
Weitere Informationen finden Sie in unserem Benchmark zu den Fähigkeiten der Browser- Toolnutzung.
3. Wissens- und Produktivitätsagenten
AnythingLLM (Desktop)
Bei Konfiguration mit lokalen Modellen: AnythingLLM Desktop:
- Führt die Dokumentenindizierung lokal durch.
- Führt Agentenlogik auf dem Gerät aus
- Unterstützt eingeschränkte Aktionsfunktionen (z. B. Dateischreiben).
- Benötigt keine Cloud-Verbindung.
Obwohl seine Autonomie im Vergleich zu Systemagenten eingeschränkt ist, qualifiziert es sich bei einer engen Aufgabendefinition als lokaler Produktivitätsagent.
Ein beispielhafter Einsatz eines lokalen KI-Agenten
Wir haben AnythingLLM Desktop getestet, um zu sehen, wie ein lokaler, auf dem Gerät installierter Agent von der Einrichtung bis zum Endergebnis funktioniert.
1. Einrichten des Arbeitsbereichs
Wir öffneten die Workspace-Einstellungen und gingen zur Agentenkonfiguration.
Dort wählten wir einen LLM-Anbieter und entschieden uns für das Modell Mistral-Medium-2505.
Nach dem Klicken auf „Workspace-Agent aktualisieren“ bestätigte der Workspace, dass die Einrichtung abgeschlossen war.
2. Agentenfähigkeiten ermöglichen
Als Nächstes öffneten wir das Bedienfeld „Agentenfähigkeiten konfigurieren“.
Über dieses Menü können Sie die integrierten Agentenfunktionen mit einem einzigen Klick aktivieren. Es sind keine Programmierkenntnisse erforderlich.
3. Testen der Fähigkeit „Speicherdateien“.
Wir haben die Funktion „Dateien speichern“ aktiviert, sodass der Agent Ausgaben direkt auf dem lokalen Rechner speichern kann.
Nach dem Einschalten und Speichern der Änderung war der Agent einsatzbereit.
Um das zu testen, sind wir zurück zum Chatfenster gegangen und haben eine der Beispielaufforderungen aus der Dokumentation verwendet.
Dies bestätigte, dass der Agent eine Datei generieren und für die lokale Speicherung vorbereiten konnte.
4. Den Agenten im Chat ausführen
Wir haben den Agenten gebeten, ein historisches Thema zusammenzufassen, und ihn mit @agent aufgerufen.
Wir haben den Befehl so geändert, dass die Ausgabe als einfache Textdatei anstatt als PDF gespeichert wird.
Das System bestätigte, dass der Agenten-Chat-Modus aktiv war und zeigte an, wie man die Schleife verlassen kann.
Der Agent erstellte die Zusammenfassung und bereitete die Datei zum Speichern vor.
5. Die Datei lokal speichern
Um die Ausgabe zu speichern, haben wir den Beispielbefehl aus der AnythingLLM-Dokumentation verwendet:
„@agent kann diese Informationen als PDF in meinem Desktop-Ordner speichern?“
Wir haben die gleiche Struktur im Chat verwendet, allerdings für eine Textdatei.
Ein Dateibrowserfenster öffnete sich, und wir speicherten die Ausgabe auf dem Gerät.
Die Datei erschien im Ordner „Downloads“, was darauf hindeutet, dass der gesamte Prozess, die Schlussfolgerungen, die Ausführung und das Speichern vollständig auf dem Gerät durchgeführt wurden.
Beschreibungen der Kategorien lokaler KI-Agenten
- Entwickler- und Systemagenten (Aktionsschicht): Agenten, die direkt auf Ihrem Gerät ausgeführt werden, um Codierungs-, System- und Workflow-Automatisierungsaufgaben lokal durchzuführen.
- Lokale Automatisierungs- und Steuerungsagenten: Agenten, die Aktionen in der realen Welt auf Ihrem Rechner automatisieren, indem sie den Browser, die Benutzeroberfläche oder das Betriebssystem steuern.
- Wissens- und Produktivitätsagenten: Lokale Assistenten für Chat, Zusammenfassung und Dokumentenbearbeitung, ohne dass Daten in die Cloud gesendet werden müssen.
Architekturschichten im lokalen Agentenstapel
- Aktionsschicht (Agenten) : Systeme, die den Zustand beobachten, Werkzeuge aufrufen und auf die lokale Umgebung einwirken.
- Logik- und Orchestrierungsschicht (Frameworks) : Bibliotheken wie LangGraph oder LlamaIndex, die Planung, Speicherung und Koordination unterstützen. Diese sind selbst keine Agenten.
- Ausführungsschicht (lokale Laufzeitumgebungen) : Modelllaufzeitumgebungen wie Ollama oder LM Studio, die lokale Inferenz ermöglichen.
Praktische Hinweise
Lokale KI-Systeme sollten schrittweise aufgebaut werden:
- Beginnen Sie mit einer lokalen Laufzeitumgebung, wenn Offline-Inferenz erforderlich ist.
- Fügen Sie eine Wissensebene nur dann hinzu, wenn ein besseres Verständnis des Dokuments erforderlich ist.
- Setzen Sie Automatisierungs- oder Steuerungsagenten ein, wenn Aktionen in der realen Welt erforderlich sind.
- Orchestrierungs-Frameworks sollten nur für komplexe, mehrstufige Arbeitsabläufe verwendet werden.
In den meisten Fällen ist ein vollständig geschichteter Stack nicht erforderlich.
Wie man den lokalen KI-Agentenstapel angeht
Beginnen Sie mit dem kleinstmöglichen Satz an Ebenen, den Ihr Anwendungsfall erfordert. Benötigt Ihr Agent Offline-Logik, starten Sie mit einer lokalen Laufzeitumgebung wie Ollama oder LM Studio. Muss er Ihre Dateien verstehen, fügen Sie eine Wissensebene wie AnythingLLM oder LocalGPT hinzu. Für Agenten, die Aktionen ausführen müssen (Apps öffnen, Browser steuern, Dateien verwalten), fügen Sie eine lokale Automatisierungsebene hinzu. Frameworks wie LangGraph oder LlamaIndex sollten Sie nur dann verwenden, wenn Sie mehrstufige Workflows, Planungsschleifen oder komplexe Toolchains benötigen.
FAQs
Lokale KI-Agenten arbeiten autonom auf persönlicher Hardware, ohne auf externe APIs oder Cloud-Infrastruktur angewiesen zu sein.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.