AgenticSeek: lokaler Agent mit Websuche und Code-Ausführung, aber ohne fertige Releases

Für wen der lokale Zwang ein Vorteil ist und für wen nicht

Der Auslöser für AgenticSeek ist der Preis und die Datenhoheit gehosteter Agenten. Das README beschreibt das Projekt als eine 100 Prozent lokale Alternative zu Manus AI, die Webseiten durchsucht, Code schreibt und Aufgaben plant, während alle Daten auf dem eigenen Gerät bleiben. Wer mit Dokumenten arbeitet, die das Haus nicht verlassen dürfen, bekommt damit einen Agenten, der Dateien unter WORK_DIR liest und verändert, ohne dass ein fremder Dienst davon erfährt. Die API-Schlüssel im .env-Beispiel sind ausdrücklich als optional markiert, und der Text stellt klar, dass lokale LLMs der Hauptzweck sind. Das ist die Zielgruppe: Nutzer mit eigener GPU oder Unified Memory, die den Suchindex und den Zwischenspeicher selbst betreiben wollen. Wer keinen Rechner mit genug Speicher für ein brauchbares Modell hat, ist hier falsch; das README verweist solche Nutzer selbst auf einen anderen Weg, statt eine Cloud-Ausweichlösung anzubieten.

SearxNG und Redis als lokale Infrastruktur

Der Agent besteht nicht nur aus einem Modell. Zwei Dienste tragen die Arbeit: SearxNG liefert die Suchergebnisse, Redis fungiert als Zwischenspeicher, adressiert über REDIS_BASE_URL mit dem Wert redis://redis:6379/0. Beide laufen laut Einrichtung als Docker-Container, gestartet über docker compose. Das Modell selbst kommt von außen, aus Ollama auf OLLAMA_PORT 11434, aus LM Studio auf LM_STUDIO_PORT 1234 oder aus einem eigenen Dienst auf CUSTOM_ADDITIONAL_LLM_PORT 11435. Die Aufgabe des Agenten liegt also in der Orchestrierung: Er entscheidet laut README selbst, welcher Unteragent für eine Anfrage zuständig ist, zerlegt größere Aufträge in Schritte und führt sie aus. Die Websuche ist dabei kein API-Aufruf an einen kommerziellen Anbieter, sondern ein HTTP-Zugriff auf die eigene SearxNG-Instanz. Genau diese Kopplung macht die Portkonfiguration so fehleranfällig, wie der nächste Abschnitt zeigt.

Die Portfalle zwischen Docker und Host

Die verwirrendste Stelle der Einrichtung ist das Verhältnis von SEARXNG_PORT zu SEARXNG_BASE_URL, und das README behandelt sie ausführlich, weil sie offenbar häufig zu Fehlern führt. SEARXNG_PORT steuert nur, auf welchem Port Docker den Container nach außen freigibt. Innerhalb des Containers lauscht SearxNG immer auf 8080, unabhängig davon, was in der .env steht. SEARXNG_BASE_URL beschreibt dagegen, wie der Backend-Prozess SearxNG erreicht, und dieser Wert hängt davon ab, wo das Backend läuft. Im Web-Betrieb über ./start_services.sh full liegt das Backend selbst in Docker und nutzt http://searxng:8080, wobei der Hostname searxng nur innerhalb des Docker-Netzwerks existiert. Im CLI-Betrieb über uv run cli.py läuft das Backend auf dem Host und braucht http://localhost:8080, oder den geänderten Port, falls SEARXNG_PORT angepasst wurde. Wer hier den Docker-Hostnamen einträgt, bekommt eine Verbindung, die im Browser funktioniert und im Agenten scheitert. Ein zweiter Stolperstein: Die .env wird nur beim Prozessstart gelesen, Änderungen erfordern also einen Neustart des Backends.

Installation: festgelegte Python-Version und ein Docker-Stack

Die Einrichtung beginnt mit drei Zeilen: git clone https://github.com/Fosowl/agenticSeek.git, cd agenticSeek und mv .env.example .env. Danach folgt der kritische Punkt. Das README empfiehlt ausdrücklich Python 3.10.x und warnt, dass andere Versionen zu Abhängigkeitsfehlern führen können. Das ist keine vage Warnung, sondern eine harte Einschränkung für Umgebungen, in denen bereits eine neuere Python-Version systemweit installiert ist. Docker Engine und Docker Compose V2 werden für die gebündelten Dienste vorausgesetzt, auf Linux nennt das README dafür explizit sudo apt-get install docker-compose-plugin. Die Prüfung erfolgt über docker info. Im .env-Beispiel stehen neben den Ports und REDIS_BASE_URL auch WORK_DIR, das auf ein lokales Verzeichnis zeigt, sowie optionale Schlüssel für OpenAI, DeepSeek, OpenRouter, Together, Google und Anthropic. Das Repository enthält laut Angabe keine veröffentlichten Releases, es gibt also keinen versionierten Tarball und keinen Changelog, an dem man sich orientieren könnte. Installation bedeutet hier: den main-Branch klonen und mit dem leben, was gerade dort steht.

Hardware ist die eigentliche Einstiegshürde

Das README sagt, man solle die API-Schlüssel leer lassen, wenn die Hardware ausreicht, und verweist Nutzer ohne geeignete Ausstattung auf einen anderen Weg. Eine konkrete Mindestanforderung an VRAM oder Arbeitsspeicher nennt es nicht, und das ist eine der schwächsten Stellen der Dokumentation. Wer wissen will, ob ein Modell auf der eigenen Maschine läuft, muss das selbst herausfinden, bevor er den Stack startet. Die Sprachsteuerung, im README als voice-enabled beworben, trägt den Zusatz in progress. Wer den Agenten wegen der Sprachfunktion auswählt, sollte diesen Hinweis ernst nehmen und nicht mit einem fertigen Assistenten rechnen. Auch die Demo im README arbeitet mit erfundenen Dateien, was das Projekt selbst offenlegt; sie taugt als Illustration des Ablaufs, nicht als Beleg für Zuverlässigkeit bei echten Datenmengen.

Pflege, Upgrades und die GPL-3.0-Frage

Das README beschreibt das Projekt als Nebenprojekt ohne Roadmap und ohne Finanzierung. Für die Adoption heißt das: Es gibt keinen angekündigten Release-Zyklus, keine Versionierung und damit auch keinen klaren Upgrade-Pfad. Wer den main-Branch klont, zieht Änderungen mit, sobald er aktualisiert, und hat keinen Zwischenstand, auf den er zurückfallen könnte. Die Lizenz ist GPL-3.0, eine Copyleft-Lizenz. Wer AgenticSeek nur lokal für eigene Aufgaben einsetzt, berührt die Verteilungsfrage nicht. Wer den Code jedoch in ein Produkt einbettet oder zusammen mit eigener Software weitergibt, muss die Bedingungen der GPL-3.0 einhalten; das ist eine technische Einordnung und keine Rechtsberatung. Ein Punkt, der dabei leicht übersehen wird: Der Agent liest und verändert Dateien unter WORK_DIR. Wer dieses Verzeichnis auf ein Projekt mit fremden Lizenztexten zeigt, lässt ein Modell darauf schreiben, dessen Ausgaben man prüfen muss.

Wo eine gehostete Plattform die bessere Wahl bleibt

Die naheliegende Alternative ist ein gehosteter Agent wie Manus AI selbst, gegen den das Projekt im README antritt. Der Unterschied liegt nicht in der Funktionsliste, sondern im Betriebsmodell. Bei einem gehosteten Dienst läuft das Modell auf fremder Hardware, die Einrichtung beschränkt sich auf ein Konto, und es gibt einen Anbieter, der Fehler nachvollzieht. Bei AgenticSeek läuft das Modell auf der eigenen Maschine, die Suche über die eigene SearxNG-Instanz, und die Fehlersuche liegt vollständig beim Betreiber. Dafür fallen keine laufenden Gebühren an, und die Daten verlassen das Gerät nicht. Ein zweiter Vergleichspunkt ist der Aufwand: Ein gehosteter Dienst kennt die Grenzen seiner Modelle und skaliert sie selbst, während AgenticSeek die Modellwahl und die Frage, ob sie zur Hardware passt, an den Nutzer zurückgibt. Wer diese Entscheidung nicht treffen will, ist mit einem gehosteten Angebot besser bedient, auch wenn er dafür bezahlt.

Redaktionelles Fazit

Wer eine Maschine mit ausreichend VRAM oder Unified Memory besitzt, Python 3.10.x nicht scheut und den gesamten Stack selbst betreiben will, findet hier einen Agenten, der ohne Cloud-Schlüssel auskommt. Wer eine gehostete Lösung mit Support, versionierten Releases oder GPU-losen Laptops sucht, sollte Abstand nehmen. Vor dem ersten Start ist zu prüfen, ob der eigene Rechner das gewählte Modell überhaupt laden kann; das Repository nennt dafür keine Mindestanforderung, und diesen Punkt muss man selbst testen.

Offizielle Quellen

1. Fosowl/agenticSeek on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README