Lokale KI-Agenten: Goose, Observer KI, AnythingLLM

Lokale KI-Agenten werden häufig als offline, geräteintern 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 über Entwickleragenten, Automatisierungstools und Produktivitätsassistenten.

Kategorisierung lokaler KI-Agenten

Siehe Kategoriebeschreibungen.

1. Entwickler- & Systemagenten

*Ausführungstypen:

• Vollständig lokal: Das Tool läuft nativ auf persönlicher Hardware unter Verwendung lokaler Laufzeitumgebungen. Tools, die vollständig offline arbeiten können.
• Hybrid lokal: Die Kernmodell- oder Aufgabenausführung findet lokal statt, aber einige Funktionen, wie IDE-Integration, Kontextindizierung, Synchronisierung oder Argumentation, sind immer noch auf Cloud-Dienste oder APIs angewiesen.

** Erklärung zur Spalte Geräteintern:

• Vollständig geräteintern: Kompletter Offline-Betrieb: Inferenz, Argumentation und Ausführung laufen alle lokal.
• Lokale Inferenz, Cloud-unterstützt: Kernmodell läuft lokal, aber IDE- oder Managementfunktionen nutzen Online-Dienste.
• Lokale Ausführung, entfernte Argumentation: Code läuft lokal, aber externe APIs treiben die Argumentation oder Planungsschritte an.

Goose

Goose ist ein Open-Source-Entwicklungsagent, der dafür ausgelegt ist, vollständig auf lokaler Hardware zu arbeiten.¹

Kernfähigkeiten:

• Verwendet lokale LLM-Laufzeitumgebungen für Argumentation und Codegenerierung
• Führt mehrschrittige Aufgaben wie Schreiben, Testen und Debuggen von Code aus
• Interagiert direkt mit dem lokalen Dateisystem und den Entwicklertools
• Erfordert keine Netzwerkverbindung, wenn mit lokalen Modellen konfiguriert.

Goose erfüllt eine strenge Definition eines lokalen autonomen Agenten, da Beobachtung, Argumentation und Aktion geräteintern stattfinden.

Roo Code(Boomerang Mode)

Roo Code ist ein IDE-integrierter Coding-Assistent, der iterative Verfeinerung betont.

• Der Boomerang-Modus ermöglicht die lokale Ausführung von Aktionen
• Die Argumentation stützt sich üblicherweise auf Cloud-basierte Modelle
• IDE-Koordination und Verwaltungsfunktionen sind nicht vollständig lokal

Infolgedessen sollte Roo Code als hybrider Entwickleragent mit menschlichem Eingriff eingestuft werden, nicht als vollständig lokales System.

Konfiguration eines lokalen KI-Agenten in Roo Code:

Roo Code ermöglicht Entwicklern, benutzerdefinierte Konfigurationsprofile zu erstellen, die definieren, wie es sich mit verschiedenen KI-Modellen verbindet, einschließlich lokal gehosteter LLMs.

Über 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, einschließlich Temperatur, Argumentationstiefe und Token-Limits. Dies ermöglicht Ihnen, zwischen leichtgewichtigen Cloud-Modellen und vollständig lokalen Laufzeitumgebungen für geräteinterne Inferenz zu wechseln.

Cursor

Cursor erlaubt die Nutzung lokaler LLMs für Inferenz, bleibt aber abhängig von Cloud-Diensten für:

• Code-Indizierung
• Bearbeitungsanwendung
• Workflow-Koordination

Daher unterstützt Cursor lokale Inferenz, aber keinen vollständig lokalen Agenten-Loop und kann nicht offline arbeiten.

So verwenden Sie ein lokales LLM in Cursor:

Quelle: Logan Hallucinates²

Aider

Aider ist ein Open-Source, kommandozeilenbasierter KI-Coding-Assistent, der dafür konzipiert ist, direkt mit lokalen Git-Repositories zu arbeiten. Er ändert Code, indem er Patches und Commits generiert, anstatt über eine IDE-Schnittstelle zu arbeiten.

Aider wird oft mit Cloud-gehosteten Modellen verwendet, aber:

• Das Tool selbst läuft lokal
• In Kombination mit einer lokalen Modelllaufzeit kann es vollständig geräteintern arbeiten

Die Offline-Fähigkeit ist daher bedingt durch die Modellauswahl, nicht intrinsisch zum Tool.

2. Lokale Automatisierungs- & Steuerungsagenten

Observer KI

Observer KI ist ein Open-Source-Framework für lokale Automatisierungsagenten Agenten-Framework.

Kernfunktionen:

• Führt Agenten mit lokalen LLMs aus
• Beobachtet den Bildschirmzustand über OCR oder Screenshots
• Führt Python-Code über eine eingebettete Ausführungsumgebung aus
• Erfordert keine Cloud-Konnektivität

Observer KI bietet die Infrastruktur für Agentenverhalten und nicht eine feste Agentenrichtlinie und wird am besten als lokales Regelkreisframework beschrieben.

Browser-Use

Browser-Use ermöglicht KI-gesteuerte Browserinteraktion über Playwright.

• Browseraktionen werden lokal ausgeführt
• Die Argumentation kann entweder mit lokalen oder entfernten Modellen durchgeführt werden
• Offline-Betrieb ist möglich, wenn er mit lokaler Inferenz kombiniert wird

Dies platziert Browser-Use standardmäßig fest in der hybriden Automatisierungskategorie.

So verwenden Sie ein lokales LLM in Browser-Use:

Eine Methode zur Installation ist die Verwendung des Befehls „pip install browser-use“, der sowohl die Python-Schnittstelle als auch die lokale Browsersteuerung auf demselben Rechner einrichtet.

Wenn es später ausgeführt wird (z. B. mit python -m browser_use), öffnet es eine Browser-Instanz lokal und führt Aktionen und Argumentation entweder über ein lokales LLM (z. B. via Ollama) oder über verbundene APIs aus:

Browser-Use lokal einrichten³

Für diejenigen, die das vollständige Setup 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 Anleitung deckt alles ab, von der Installation von Abhängigkeiten wie Playwright und LangChain bis hin zur Verbindung von Browser-Use mit einem lokalen Modell über Ollama.³

3. Wissens- & Produktivitätsagenten

AnythingLLM (Desktop)

Wenn mit lokalen Modellen konfiguriert, AnythingLLM Desktop:

• Führt die Dokumentenindizierung lokal durch
• Führt die Agentenargumentation geräteintern aus
• Unterstützt begrenzte Aktionsfähigkeiten (z. B. Dateischreiben)
• Erfordert keine Cloud-Konnektivität

Obwohl seine Autonomie im Vergleich zu Systemagenten eingeschränkt ist, qualifiziert es sich unter einer engen Aufgabendefinition als lokaler Produktivitätsagent.

Ein beispielhafter Einsatz eines lokalen KI-Agenten

Wir testeten AnythingLLM Desktop, um zu sehen, wie ein lokaler, geräteinterner Agent vom Setup bis zur endgültigen Ausgabe funktioniert.

1. Einrichten des Arbeitsbereichs

Wir öffneten die Arbeitsbereichseinstellungen und gingen zur Agentenkonfiguration.
Dort wählten wir einen LLM-Anbieter aus und wählten das Modell mistral-medium-2505.
Nach dem Klicken auf „Update Workspace Agent“ bestätigte der Arbeitsbereich, dass das Setup abgeschlossen war.

2. Aktivieren der Agentenfähigkeiten

Als nächstes öffneten wir das Panel „Agentenfähigkeiten konfigurieren“.
Dieses Menü ermöglicht es Ihnen, integrierte Agentenfähigkeiten mit einem einzigen Klick zu aktivieren. Es ist keine Codierung erforderlich.

3. Testen der Fähigkeit „Files speichern“

Wir aktivierten die Fähigkeit „Files speichern“, die es dem Agenten ermöglicht, Ausgaben direkt auf den lokalen Rechner zu schreiben.
Nach dem Einschalten und Speichern der Änderung war der Agent bereit.

Um es zu testen, gingen wir zum Chat-Fenster zurück und verwendeten einen der Beispiel-Prompts aus der Dokumentation.
Dies bestätigte, dass der Agent eine Datei generieren und für die lokale Speicherung vorbereiten konnte.

4. Ausführen des Agenten im Chat

Wir baten den Agenten, ein historisches Thema zusammenzufassen, und riefen ihn mit @agent auf.
Wir änderten den Befehl, um die Ausgabe als einfache Textdatei anstelle einer PDF zu speichern.

Das System bestätigte, dass der Agenten-Chat-Modus aktiv war, und zeigte, wie man die Schleife verlässt.
Der Agent produzierte die Zusammenfassung und bereitete die Datei für die Speicherung vor.

5. Datei lokal speichern

Zum Speichern der Ausgabe verwendeten wir den Beispielbefehl aus der AnythingLLM-Dokumentation:
„@agent can save this information as a PDF on my desktop folder?“
Wir führten die gleiche Struktur im Chat aus, jedoch für eine Textdatei.

Ein Dateibrowserfenster öffnete sich, und wir speicherten die Ausgabe auf dem Gerät.
Die Datei erschien im Downloads-Ordner, was darauf hinweist, dass der gesamte Prozess, Argumentation, Ausführung und Speicherung vollständig geräteintern durchgeführt wurden.

Beschreibungen der Kategorien lokaler KI-Agenten

• Entwickler- & Systemagenten (Aktionsebene): Agenten, die direkt auf Ihrem Gerät laufen, um Codierungs-, System- und Workflow-Automatisierungsaufgaben lokal auszuführen.
• Lokale Automatisierungs- & Steuerungsagenten: Agenten, die reale Aktionen auf Ihrem Rechner automatisieren, indem sie den Browser, die Benutzeroberfläche oder das Betriebssystem steuern.
• Wissens- & Produktivitätsagenten: Lokale Assistenten für Chat, Zusammenfassung und Dokumentenverarbeitung, ohne Daten in die Cloud zu senden.

Architekturebenen im lokalen Agenten-Stack

• Aktionsebene (Agenten): Systeme, die den Zustand beobachten, Tools aufrufen und auf die lokale Umgebung einwirken.
• Argumentations- und Orchestrierungsschicht (Frameworks): Bibliotheken wie LangGraph oder LlamaIndex, die Planung, Speicher und Koordination unterstützen. Diese sind selbst keine Agenten.
• Ausführungsebene (lokale Laufzeitumgebungen): Modelllaufzeitumgebungen wie Ollama oder LM Studio, die lokale Inferenz ermöglichen.

Hardware: Was lokale Agenten tatsächlich benötigen

Das Modell und das Framework sind die halbe Geschichte. Die Hardware entscheidet, was tatsächlich möglich ist. Für das lokale Ausführen von Sprachmodellen sind zwei Zahlen besonders wichtig: wie viel Speicher Sie haben und wie schnell dieser Speicher ist.

RAM (oder VRAM) legt die Obergrenze für die Modellgröße fest

Ein Modell muss in den Speicher passen, bevor es ausgeführt werden kann. Eine grobe Richtlinie für 4-Bit-quantisierte Modelle: Ein 3B-Modell benötigt etwa 2 GB, ein 7–8B-Modell benötigt etwa 5–6 GB, ein 13B-Modell benötigt etwa 8–10 GB und ein 70B-Modell benötigt etwa 40–48 GB. Fügen Sie Spielraum für den Kontext, das Betriebssystem und alle anderen ausgeführten Anwendungen hinzu. In der Praxis ist der Speicher häufiger der Engpass als die Rechenleistung, und bei Copilot+ PCs wird für eine komfortable lokale LLM-Nutzung mindestens 32 GB RAM empfohlen.⁴

Speicherbandbreite bestimmt die Geschwindigkeit

Sobald ein Modell passt, hängt die Geschwindigkeit, mit der es Tokens generiert, hauptsächlich davon ab, wie schnell das System die Modellgewichte aus dem Speicher lesen kann. Deshalb ist die hohe Speicherbandbreite von Apple Silicon (bis zu 800 GB/s beim M4 Max) der praktische Vorteil für die LLM-Inferenz, nicht die Anzahl der Neural Engines.⁵

NPU-TOPS sind weniger wichtig, als das Marketing suggeriert

Eine Neural Processing Unit ist ein Chip, der für KI-Mathematik entwickelt wurde, und seine Leistung wird in TOPS (Billionen Operationen pro Sekunde) angegeben. Die Copilot+ PC-Zertifizierung von Microsoft erfordert mindestens 40 TOPS. Diese Schwelle ist auf die eigenen geräteinternen Funktionen von Microsoft (Live-Untertitel, Bildeffekte, Recall) ausgerichtet und nicht auf das Ausführen eines Chat-LLM. Bei LLM-Workloads dominieren RAM und Bandbreite. Die NPU-Leistung ist ein nützliches Unterscheidungsmerkmal, aber nicht die Hauptkennzahl.

Eine praktische Regel:

• Für Assistenzmodelle der 3B-Klasse reicht ein aktueller Laptop mit 16 GB vereinigtem Speicher oder RAM.
• Für 7–8B-Modelle mit angenehmer Geschwindigkeit zielen Sie auf 32 GB RAM und hohe Speicherbandbreite ab. Apple Silicon, Snapdragon X-Serie und aktuelle Intel/AMD Copilot+ PCs funktionieren alle; die Unterschiede zeigen sich in Tokens pro Sekunde, nicht darin, ob das Modell läuft.
• Für größere Modelle (30B und höher) teilen sich die Optionen. Apple Silicon mit viel Speicher (Mac Studio oder MacBook Pro-Konfigurationen mit 64–192 GB vereinigtem Speicher) können große Modelle ausführen, die keine Consumer-diskrete GPU aufnehmen kann. Die Alternative ist eine Workstation mit einer oder mehreren diskreten GPUs mit hohem VRAM. Beide Wege funktionieren; sie haben unterschiedliche Kosten- und Leistungsprofile.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Praktische Anleitung

Lokale KI-Systeme sollten inkrementell zusammengestellt werden:

1. Beginnen Sie mit einer lokalen Laufzeitumgebung, wenn Offline-Inferenz erforderlich ist.
2. Fügen Sie eine Wissensebene hinzu, wenn Dokumentenverständnis benötigt wird.
3. Führen Sie Automatisierungs- oder Steuerungsagenten ein, wenn reale Aktionen erforderlich sind.
4. Verwenden Sie Orchestrierungs-Frameworks für komplexe, mehrschrittige Workflows.

In den meisten Fällen ist ein vollständig geschichteter Stack unnötig.

Vorgehensweise beim lokalen KI-Agenten-Stack

Beginnen Sie mit dem kleinsten Satz an Ebenen, den Ihr Anwendungsfall erfordert. Wenn Ihr Agent Offline-Argumentation benötigt, beginnen Sie mit einer lokalen Laufzeitumgebung wie Ollama oder LM Studio. Wenn er Ihre Dateien verstehen muss, fügen Sie eine Wissensebene wie AnythingLLM oder LocalGPT hinzu. Für Agenten, die Aktionen ausführen müssen (Öffnen von Apps, Steuern des Browsers, Dateiverwaltung), fügen Sie eine lokale Automatisierungsebene hinzu. Verwenden Sie Frameworks wie LangGraph oder LlamaIndex, wenn Sie mehrschrittige Workflows, Planungsschleifen oder komplexe Toolchains benötigen.

Warum einen Agenten lokal ausführen

Datenschutz ist eine rechtliche Frage, keine Präferenz

Ab dem 2. August 2026 treten die Hochrisikoverpflichtungen des EU-KI-Gesetzes in Kraft. Die Strafen können bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes betragen. Ein Modell, das auf Ihrer eigenen Hardware läuft, verarbeitet Daten in Ihrer Umgebung, ohne sie an einen Cloud-Anbieter zu übertragen. Das Risiko einer grenzüberschreitenden Datenübermittlung verschwindet.⁶

Latenz

Cloud-API-Aufrufe fügen 200–500ms Netzwerkverzögerung hinzu, bevor das erste Token erscheint. Geräteinterne Inferenz reduziert dies auf unter 20ms. Für Sprachagenten, Code-Vervollständigung und alles, was eine Benutzeroberfläche in Echtzeit berührt, ist dies der Unterschied zwischen flüssig und verzögert.

Kosten bei Volumen

Cloud-Aufrufe sind pro Anfrage günstig und in großen Mengen teuer. Ein lokales Modell hat feste Hardwarekosten und keine Abrechnung pro Token. Der Kompromiss ist immer noch real: Lokale Agenten sind durch das Modell begrenzt, das in den Speicher passt, und durch die Hardware auf dem Schreibtisch. Die nächsten Abschnitte behandeln beides.

FAQs

Diese Forschung zitieren

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and PhD., Ezgi Arslan,},
  title  = {{Lokale KI-Agenten: Goose, Observer KI, AnythingLLM}},
  year   = {2026},
  month  = may,
  howpublished    = {\url{https://aimultiple.com/local-ai-agent}},
  note   = {AIMultiple. Abgerufen am 30. Mai 2026}
}

Referenzlinks

1.

GitHub - aaif-goose/goose: an open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM · GitHub

2.

Bevor Sie zu YouTube weitergehen

3.

Install Browser Use Locally to Integrate AI Agents with Websites - YouTube

4.

How to Run LLM Locally: The Ultimate 2026 Guide

Boltic

5.

Native LLM and MLLM Inference at Scale on Apple Silicon

6.

AI Act | Shaping Europe’s digital future

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 60% der Fortune 500.

Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.

Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.

Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.

Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab und hat einen MBA von der Columbia Business School.

Vollständiges Profil anzeigen

Recherchiert von

Ezgi Arslan, PhD.

Branchenanalystin

Folgen auf

Ezgi hat einen Doktortitel in Betriebswirtschaftslehre mit Spezialisierung auf Finanzen und arbeitet als Branchenanalystin bei AIMultiple. Sie treibt Forschung und Erkenntnisse an der Schnittstelle von Technologie und Wirtschaft voran, mit Fachkenntnissen in den Bereichen Nachhaltigkeit, Umfrage- und Sentimentanalyse, KI-Agenten-Anwendungen im Finanzwesen, Antwortmaschinenoptimierung, Firewall-Management und Beschaffungstechnologien.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten