Blog · 16. September 2026 · 11 Min. Lesezeit

KI-Agenten lokal betreiben: was geht

Heller Arbeitsplatz mit einer Ablage an der Wand, unter der Tischplatte steht ein blau beleuchteter Rechner
Foto: Minh Phuc / Pexels

Lokale KI-Agenten funktionieren heute: Ein Terminal-Agent, der Dateien liest, ändert und Befehle ausführt, läuft mit einem offenen Modell und lokaler Inferenz auf eigener Hardware. Bei mir macht das Pi gegen Qwen 3.8 auf einem DGX Spark, und es liest dieselben Regeln aus der CLAUDE.md wie meine Belegschaft auf Claude-Basis. Was noch nicht geht: eine ganze KI-Belegschaft mit mehreren Rollen, Übergaben und Freigabe-Gates eins zu eins lokal nachzubauen. Dafür fehlen den lokalen Harnesses vor allem ein Freigabe-System, die Zuverlässigkeit über viele Schritte hinweg und bei falscher Konfiguration schlicht der Kontext. Dieser Beitrag zeigt die drei Bausteine, die du brauchst, vier Harnesses, die ein lokales Modell anbinden, und die Stelle, an der die Grenze aktuell verläuft.

Ich betreibe mein Business mit einer KI-Belegschaft auf Claude-Basis, jede Rolle als Ordner mit CLAUDE.md, Personalakte, Skills und Learnings. Seit Dezember 2025 steht daneben ein DGX Spark, auf dem ich dieselbe Arbeitsweise mit einem lokalen Modell ausprobiere. Das Ziel: eine Claude-Code-Alternative ohne Cloud für Kunden, die ihre Daten keinem Anbieter geben wollen. Alles zu lokaler KI und zur Belegschaft sammle ich auf der Seite KI.

Was ein lokaler KI-Agent braucht: drei Bausteine

Ein KI-Agent ist ein Modell, das Werkzeuge aufruft: Datei lesen, Datei schreiben, Befehl ausführen, Ergebnis lesen, weiter. Lokal brauchst du dafür drei Dinge, und alle drei müssen zusammenpassen.

Erstens ein Modell, das Tool-Calling beherrscht. Es muss den Aufruf eines Werkzeugs in einem festen Format ausgeben, das der Harness versteht. Qwen 3.8 kann das laut Modellkarte, dazu Thinking und Bilder. Ein Modell ohne Tool-Calling schreibt dir Text, fasst aber keine Datei an.

Zweitens ein Server, der das Modell über eine API bereitstellt. Bei mir ist das SGLang auf dem Spark mit OpenAI- und Anthropic-kompatibler Schnittstelle; einfacher zum Start sind Ollama oder LM Studio. Wie du das einrichtest, steht in Lokale KI einrichten: Ollama bis SGLang und für Ollama im Detail in Qwen 3.8 mit Ollama installieren.

Drittens der Harness: das Programm, das die Werkzeuge bereitstellt, den Kontext verwaltet, deine Regeln liest und die Schleife aus Modellantwort und Werkzeugaufruf fährt. Claude Code ist ein Harness. Pi, OpenCode und Aider sind Harnesses, die sich gegen ein lokales Modell konfigurieren lassen. Der Harness entscheidet mehr als das Modell darüber, ob aus einem Chat ein Mitarbeiter wird.

Vier Harnesses für KI-Agenten lokal: Anbindung, Werkzeuge, Freigaben

Die Tabelle fasst zusammen, was die Dokumentation der vier Projekte zum Betrieb mit einem lokalen Modell sagt, Stand 16.09.2026. Getestet habe ich davon nur Pi; die anderen drei stehen hier, weil ihre Doku den Weg zum lokalen Modell beschreibt.

Harness Lokale Modelle anbinden Werkzeuge Freigaben Quelle
Pi Provider in ~/.pi/agent/models.json mit baseUrl (etwa http://localhost:11434/v1), api: openai-completions, Dummy-Key; oder direkt ollama launch pi Read, Write, Edit, Bash, Grep; Skills, Subagents, MCP-Adapter Keine, führt alles ohne Rückfrage aus Pi-Doku
OpenCode Provider in opencode.json über @ai-sdk/openai-compatible, baseURL für Ollama (Port 11434), LM Studio (1234), llama-server (8080) Tool-Calls über den Provider; die Doku rät bei Problemen zu num_ctx 16k bis 32k In der Provider-Doku nicht beschrieben OpenCode-Doku
Aider OLLAMA_API_BASE setzen, dann aider --model ollama_chat/<modell> Arbeitet in deinen Dateien; Kontext fest per .aider.model.settings.yml (Beispiel num_ctx: 65536) In der Ollama-Seite der Doku nicht beschrieben Aider-Doku
Claude Code gegen Ollama ANTHROPIC_BASE_URL=http://localhost:11434, ANTHROPIC_AUTH_TOKEN=ollama, dann claude --model <modell>; Ollama empfiehlt 64k Kontext oder mehr Read, Write, Edit, Bash wie im Cloud-Betrieb Freigabe-Dialog je Werkzeug bleibt erhalten Ollama-Doku

Zwei Anmerkungen zur Tabelle. Bei Claude Code gegen Ollama steht in der Doku nicht, ob Anthropics Nutzungsbedingungen den Weg decken; das prüfst du selbst, und ich habe ihn nicht im Betrieb. Und die Spalte „Freigaben" ist die wichtigste für alles, was über ein Testprojekt hinausgeht: Nur Claude Code fragt von sich aus nach, bevor es einen Befehl ausführt oder eine Datei überschreibt.

Die Kontextfalle: 4.096 Token reichen nicht

Der häufigste Fehler beim ersten lokalen Agenten liegt im Kontextfenster, nicht im Modell. Ollama startet Modelle laut seiner FAQ mit 4.096 Token Kontext; die Aider-Doku nennt sogar 2.048 als Standard, die beiden Dokus widersprechen sich hier. Für einen Chat reicht das. Ein Agent aber schiebt Systemprompt, Werkzeugdefinitionen, deine CLAUDE.md, gelesene Dateien und Befehlsausgaben in denselben Kontext. Bei 4.096 Token ist dieses Budget je nach Prompt, Dateigröße und Tokenisierung schnell aufgebraucht: In dieser Größenordnung fällt der Anfang oft schon nach der ersten oder zweiten gelesenen Datei heraus, und die Werkzeugaufrufe werden unzuverlässig. Genau das beschreibt die OpenCode-Doku: Wenn Tool-Calls nicht funktionieren, num_ctx auf 16k bis 32k erhöhen. Ollama empfiehlt für Claude Code 64k oder mehr, Aider setzt den Wert automatisch hoch und lässt ihn fest konfigurieren.

Zum Vergleich aus meiner Belegschaft: Connys Learnings-Datei hat 1.347 Zeilen (Stand 14.09.2026), und sie wird bei jedem Sitzungsstart gelesen, bevor die erste Aufgabe beginnt. Die Tokenzahl dieser Datei habe ich nicht gemessen, die Zeilenzahl allein beweist nichts. Als Überschlag: Schon bei angenommenen 10 Token je Zeile wären das rund 13.000 Token, also ein Vielfaches von 4.096. Qwen 3.8 bringt laut Modellkarte 262k Kontext mit; entscheidend ist, dass der Server diesen Kontext auch reserviert, und das kostet Speicher.

Kann eine ganze KI-Belegschaft lokal laufen? Drei Schichten

Hier trennt sich die Frage „geht ein lokaler Agent" von der Frage „geht meine Belegschaft lokal". Meine Mitarbeiter bestehen aus drei Schichten, und die lassen sich unterschiedlich gut übertragen.

Schicht 1: Dateien. Jeder Mitarbeiter bei mir ist ein Ordner: CLAUDE.md als Vertrag, personalakte.md mit Auftrag und Zugriffsrechten in drei Stufen (frei, nur nach Freigabe, nie), .claude/skills/ mit einem Skill je Aufgabe, wissen/learnings.md als Gedächtnis, postfach/eingang und postfach/ausgang für Übergaben. Das ist reiner Text, und Pi liest CLAUDE.md und AGENTS.md aus dem Projekt, kennt Skills aus .pi/skills/ und .agents/skills/ und hat Subagents. Diese Schicht ist übertragbar, und das ist der Grund, warum ich Rollen als Dateien baue. Wie ich die CLAUDE.md nutze, steht in CLAUDE.md: das Gedächtnis von Claude Code, wie die Belegschaft aufgebaut ist in Meine KI-Belegschaft: acht Mitarbeiter.

Schicht 2: Fähigkeiten des Modells. Peter, mein Buchhaltungs-Mitarbeiter, hat im September 2026 63 Belege ausgewertet: zwölf Befehle ausgeführt, zwei davon fehlgeschlagen, bei allen 63 Belegen die Kontrollrechnung Netto plus Steuer gleich Brutto gemacht, und vor der Ausgabe zwei Rückfragen gestellt, weil ein Satz im Auftrag abgebrochen war und zwei Währungen vorkamen. Ich habe entschieden: „Alles in Euro, Tageskurs." Ob ein lokales Modell diese Kette genauso sauber fährt, kann ich für Qwen 3.8 nicht mit Zahlen belegen; mein Vergleich mit Claude Code ist bisher qualitativ. Die Rechnung dahinter ist ernüchternd: Wenn jeder Werkzeugschritt zu 95 Prozent gelingt, liegt die Trefferquote über zehn Schritte bei rund 60 Prozent. Bei langen, unbeaufsichtigten Läufen bleibt das Cloud-Modell bei mir vorn, so wie ich es in Qwen vs Claude: lokal gegen Cloud beschreibe.

Schicht 3: Kontrolle. Bei Claude Code fragt das Werkzeug vor jedem heiklen Schritt nach; ich habe das über Hooks an mein Mitarbeiter-OS angeschlossen, sodass ich Freigaben auch außerhalb des Terminals erteile (siehe Claude Code Hooks: Regeln, die immer gelten). Pi hat kein Permission-System, es führt alles ohne Rückfrage aus. Für eine Belegschaft, bei der jede Aufgabe an einem Freigabe-Gate endet (Bericht an den Kunden senden, Website live stellen, Geld ausgeben), ist es aktuell ein Ausschlusskriterium: Das Gate muss dann außerhalb des Harness liegen, etwa als Review-Pass durch eine getrennte Rolle, bevor irgendetwas das Haus verlässt.

Mein Setup: Pi gegen Qwen 3.8 auf dem DGX Spark

Pi habe ich lokal installiert und auf den Spark geschaltet, auf dem Qwen 3.8 unter SGLang läuft. Das hat erstaunlich gut funktioniert: Der Agent hat seine Werkzeuge sauber aufgerufen und in meinen Ordnern gearbeitet, ohne dass ich lange am Setup schrauben musste. Pi arbeitet wie Claude Code mit Read, Write, Edit, Bash und Grep, liest AGENTS.md und CLAUDE.md, hat Sessions, einen MCP-Adapter, Web-Suche, Subagents, Plan-Modus und eine Todo-Liste. Den Erfahrungsbericht zum Werkzeug selbst findest du in Claude Code Alternative ohne Cloud: Pi, die Messwerte zum Modell in Qwen 3.8 lokal: Erfahrung mit DGX Spark.

Was ich damit heute mache: dieselbe Ordnerstruktur wie bei meiner Claude-Belegschaft öffnen und prüfen, ob Pi die Regeln aus der CLAUDE.md befolgt und die Skills findet. Das tut es. Erwartungsgemäß ist es langsamer als Claude Code, und das merke ich in jeder Runde; gemessen habe ich es nicht, es bleibt ein qualitativer Eindruck. Solange die Zahlen fehlen, bleibt mein Urteil eine Einschätzung: Für abgegrenzte Aufgaben in einem Ordner reicht das lokale Setup, für lange Läufe über viele Dateien und für alles mit Freigabe-Gate bleibt Claude Code bei mir das Werkzeug.

Was lokal gut klappt und wo es kippt

In meinen bisherigen Läufen haben Aufgaben am besten geklappt, die in einem Ordner bleiben und in wenigen Schritten erledigt sind: eine Datei nach Regeln umschreiben, ein Protokoll aus Rohnotizen bauen, Belege sortieren, ein Skript anpassen und laufen lassen. Meine Tests sind qualitativ, eine Erfolgsquote kann ich dir deshalb nicht nennen. Modell, Server und Harness reichen dafür, sobald der Kontext groß genug ist.

Es kippt bei langen, unbeaufsichtigten Läufen über viele Dateien; bei Aufgaben, in denen der Agent zwischendurch zurückfragen müsste, was bei Pi ohne Freigabe-System bedeutet, dass es einfach weitermacht; und bei allem, was das Haus verlässt. Und es kippt beim Datenschutz leicht in eine falsche Sicherheit: Lokal heißt, dass kein Modellanbieter deine Eingaben an das Modell bekommt. Es heißt nicht, dass die übrigen Pflichten wegfallen, etwa Zugriffskontrolle auf den Server, Protokollierung, Löschfristen und die Frage, welche Daten der Agent überhaupt lesen darf. Das ist keine Rechtsberatung; welche Pflichten beim lokalen Betrieb bleiben, steht mit Quellen in Lokale KI und Datenschutz: Cloud oder Server?.

Häufige Fragen

Kann ich Claude Code komplett offline nutzen?

Laut Ollama-Doku lässt sich Claude Code über die Umgebungsvariable ANTHROPIC_BASE_URL auf einen lokalen Ollama-Server umleiten und mit claude --model <modell> starten; das Modell läuft dann auf deinem Rechner. Das belegt lokale Inferenz, nicht Netzwerkfreiheit des Werkzeugs: Claude Code spricht weiter mit Web-Suche, MCP-Servern und Update-Quellen, solange du das nicht abschaltest. Ob Anthropics Nutzungsbedingungen den Weg decken, steht dort nicht. Ich habe ihn nicht im Betrieb.

Welches lokale Modell kann Tool-Calling?

Schau in die Modellkarte: Steht dort „Tools" oder „Function Calling", kann das Modell Werkzeugaufrufe im passenden Format ausgeben. Qwen 3.8 bringt das laut Modellkarte mit, zusammen mit Thinking und Bildeingabe. Fehlt der Hinweis, bekommst du einen Chat, aber keinen lokalen KI-Agenten.

Wie viel Kontext braucht ein KI-Agent lokal?

Mehr als der Standard. Die OpenCode-Doku rät bei hakenden Tool-Calls zu 16k bis 32k, Ollama empfiehlt für Claude Code 64k oder mehr, das Aider-Beispiel setzt 65.536. Bei mir gilt: lieber 64k reservieren und dafür ein kleineres Modell wählen, als ein großes Modell mit 4.096 Token Kontext.

Läuft ein lokaler KI-Agent ganz offline?

Das Modell ja, sobald es heruntergeladen ist. Der Harness nicht zwingend: Pi hat Web-Suche und einen MCP-Adapter, Paketmanager holen Updates. Wer „KI-Agent offline" ernst meint, schaltet diese Wege bewusst ab und prüft mit einem Netzwerkmitschnitt, statt es zu behaupten.

Was ist Pi und wie unterscheidet es sich von Claude Code?

Pi ist ein Terminal-Coding-Agent (npm-Paket @earendil-works/pi-coding-agent). Laut Pi-Doku (abgerufen 18.09.2026) spricht er einen Server über die OpenAI-Chat-Completions-Schnittstelle /v1/chat/completions an, mit eigenen Schaltern für Fähigkeiten, die nicht jeder Server hat. Ein OpenAI-kompatibler Server reicht also für die Anbindung; brauchbar als Agent wird es erst, wenn Server und Modell Werkzeugaufrufe im erwarteten Format liefern. Werkzeuge und Regeldateien sind dieselben wie bei Claude Code, das Modell wählst du frei. Die Unterschiede: kein Permission-System, kleinerer System-Prompt, und kein Abo, dafür eigene Hardware.

Kann meine KI-Belegschaft komplett lokal laufen?

Die Dateien ja: CLAUDE.md, Personalakte, Skills, Learnings und Postfach sind Text und funktionieren mit Pi. Die Kontrolle nein: Ohne Freigabe-System im Harness musst du das Gate außerhalb bauen. Mein Stand: einzelne Rollen lokal, die Belegschaft mit Freigabe-Gates auf Claude.

Ist ein KI-Agent ohne Cloud automatisch datenschutzkonform?

Nein. Lokal fällt der Modellanbieter weg, der deine Eingaben sonst bekäme, nicht die Verantwortung für Zugriff, Protokoll und Löschung. Das ist keine Rechtsberatung; die Abgrenzung steht in meinem Beitrag zu lokaler KI und Datenschutz.

Wie du weitermachst

Für den Einstieg reicht ein Nachmittag: Ollama installieren, Qwen 3.8 laden, num_ctx hochsetzen, Pi installieren und in einem Testordner eine CLAUDE.md mit drei Regeln hinterlegen. Dann eine abgegrenzte Aufgabe geben und beobachten, ob der Agent die Regeln liest und die Werkzeuge sauber aufruft. Wie das Werkzeug im Alltag läuft, steht in Claude Code Alternative ohne Cloud: Pi; wann du beim Cloud-Modell bleibst, in Qwen vs Claude: lokal gegen Cloud; und welche Pflichten der lokale Betrieb nicht abnimmt, in Lokale KI und Datenschutz: Cloud oder Server?. Die acht Pakete meiner KI-Mitarbeiter gibt es fertig in meiner Community; sie sind als Dateien gebaut und laufen deshalb auch mit einem lokalen Harness, mit der Einschränkung, dass die Freigabe-Gates dann außerhalb des Werkzeugs liegen müssen.

Kevin Welter

Kevin Welter

Entwickler, IT-Architekt, Fachbuchautor (Kubernetes, Cloud-Infrastrukturen) und Speaker. Betreibt sein Business mit einer KI-Belegschaft aus acht KI-Mitarbeitern und zeigt Selbstständigen in seiner Community, wie sie ihren ersten KI-Mitarbeiter einstellen.

Mehr über KI-Mitarbeiter

In einer Stunde läuft dein erster KI-Mitarbeiter

Zur Community