So planst du einen Coding-Agenten in Open WebUI auf einem Homeserver ein

Eva Wong

IceWhale author

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

How to Schedule a Coding Agent in Open WebUI on a Home Server - Zima Store Online

Open WebUI v0.13.3 kann einen Programmieragenten für einen geplanten Lauf einem ausgewählten Terminal und Arbeitsverzeichnis zuweisen. Beginne mit einem reinen Berichtsauftrag in einem entbehrlichen Checkout: Führe einen bekannten Testbefehl aus, fasse die Fehler zusammen und sende das Ergebnis an einen Chat. So überprüfst du den Scheduler, die Berechtigungen und den Übermittlungsweg, bevor du einem wiederkehrenden Auftrag Zugriff auf wichtige Dateien gibst.

Du benötigst eine kompatible Open-WebUI-Installation, eine erreichbare Terminalintegration, die den vorgesehenen Agenten anbietet, und einen zugänglichen Arbeitsbereich. In den Versionshinweisen zu v0.13.3 steht, dass bei geplanten Läufen geprüft wird, ob das gespeicherte Terminal und der Agent noch verfügbar sind. Betrachte das Terminal, das Dateisystem und die zugrunde liegende Modellverbindung als getrennte Bestandteile der Einrichtung.

Was hat sich mit der November-Version geändert?

Im Automatisierungseditor kannst du ein Terminal und ein Verzeichnis auswählen und dann einen von diesem Terminal angebotenen Agenten wählen. Das konfigurierte Terminal und der Ordner werden für den geplanten Lauf übernommen. Ergebnisse der Agentenautomatisierung gehen an einen Chat, während es bei anderen Automatisierungstypen andere Zieloptionen geben kann. Die frühere Version v0.13.1 führte Programmieragenten in der Modellauswahl ein, sofern ein verbundenes Terminal sie anbietet.

Ein ausgewähltes Terminal kann auf demselben Host wie Open WebUI oder als separater, erreichbarer Dienst laufen. Für den Auftrag ist das Dateisystem des Terminals entscheidend. Ein auf deinem Laptop angezeigtes Verzeichnis muss in einem Container nicht vorhanden sein. Eine Datei, die für ein Terminal verfügbar ist, muss nicht auch in einem anderen vorhanden sein. Überprüfe den Pfad im genau für die Automatisierung ausgewählten Terminal.

Screenshot der Open-WebUI-Dokumentation mit der Terminalauswahl im Chat. Originalquelle

Wie solltest du den Arbeitsbereich vorbereiten?

Erstelle einen dedizierten Test-Checkout, idealerweise für ein kleines Repository ohne Produktionsgeheimnisse. Lege eine bekannte Revision fest und richte einen harmlosen, erfolgreichen Test sowie einen bekanntermaßen fehlschlagenden Test ein. Stelle für den ersten Bericht den Eingabe-Checkout schreibgeschützt bereit, sofern der Test-Runner das unterstützt. Stelle einen beschreibbaren temporären Speicherort für Test-Caches und Protokolle bereit. Manche Build-Tools müssen in den Verzeichnisbaum schreiben. Konfiguriere sie daher so, dass sie an anderer Stelle schreiben, oder verwende eine beschreibbare Wegwerfkopie.

Grenze	Praktische Standardeinstellung	Überprüfung
Repository	Dedizierter Checkout oder Worktree	Der Agent kann nur die vorgesehene Revision und das vorgesehene Verzeichnis sehen.
Dateisystemzugriffe	Temporärer oder entbehrlicher Checkout	Auf übergeordnete Verzeichnisse und sensible Einbindungen kann nicht zugegriffen werden.
Zugangsdaten	Für den ersten Auftrag keine Deploy-Schlüssel oder Produktions-Tokens	Die Umgebung und eingebundenen Pfade enthalten nur genehmigte Eingaben.
Agentenmodell	Den tatsächlich verwendeten Anbieter auswählen und dokumentieren	Prüfe, welche Prompt- oder Toolausgaben den Host verlassen könnten.
Ergebnisse	Chatbericht mit Status und kurzem Logauszug	Der Job liefert nützliche Belege, auch wenn Tests fehlschlagen.

Wenn mehrere Jobs dasselbe Repository verwenden, erstelle für jeden Agenten oder jede Aufgabe einen Worktree. Bewahre Backups und Arbeitsverzeichnis getrennt auf. Lies warum Backups bei gemeinsamem Zugriff fehlschlagen können, bevor du einer Aufgabe weitreichende Schreibberechtigungen auf einem Dateiserver erteilst.

Wie richtest du den ersten geplanten Job ein?

Öffne den Automatisierungseditor in einer Version mit Agentenautomatisierung. Wähle dein Terminal, das in diesem Terminal sichtbare Verzeichnis und anschließend den Agenten aus. Wähle für den ersten Test einen einmaligen Lauf in naher Zukunft, sofern deine Installation diese Planungsoption bietet. Lies den Zeitplan in deiner konfigurierten Zeitzone ab. Lege mithilfe der für deinen Agenten und deine Bereitstellung verfügbaren Steuerelemente ein moderates Laufzeit- oder Schrittlimit fest.

Gib dem Job eine konkrete Eingabe, einen Befehl und ein Ergebnisformat vor. Zum Beispiel:

Überprüfe den Checkout im ausgewählten Arbeitsverzeichnis.
Führe den vorhandenen lokalen Smoke-Test-Befehl einmal aus.
Melde den Befehl, den Exit-Status und den ersten fehlgeschlagenen Test.
Falls der Befehl oder der Ordner nicht verfügbar ist, melde diesen Fehler.
Installiere keine Abhängigkeiten, ändere das Repository nicht und kontaktiere keine externen Dienste.

Anweisungen leiten den Agenten. Setze Grenzen für Dateisystem und Netzwerk separat über die Terminal- und Containerkonfiguration durch. Vergewissere dich, dass eine fehlende Abhängigkeit zu einem klaren Fehler führt und nicht zu einer unerwarteten Installation. Die Open-WebUI-Dokumentation ist der Ausgangspunkt für Terminal- und Administratoreinstellungen.

Was solltest du nach dem ersten Lauf überprüfen?

Öffne den resultierenden Chat und überprüfe die Identität des Agenten, den Arbeitsverzeichnispfad, den Testbefehl, den Exit-Status und die getestete Revision. Vergleiche das Ergebnis mit einem manuellen Lauf desselben Befehls in diesem Terminal. Ein abgeschlossener Automatisierungslauf zeigt lediglich, dass der Workflow beendet wurde. Der Bericht muss weiterhin belegen, dass der vorgesehene Test tatsächlich ausgeführt wurde.

Teste absichtlich einen Fehlerfall. Gib einem Testjob eine harmlose, nicht vorhandene Eingabe oder stoppe das Wegwerf-Terminal kurz und beobachte den resultierenden Status. Stelle den ursprünglichen Zustand nach dem Test wieder her. Ein Administrator sollte zwischen nicht verfügbarem Agenten, fehlendem Verzeichnis, fehlgeschlagenem Test und Modell-Timeout unterscheiden können, ohne das gesamte Chatprotokoll lesen zu müssen. Vergewissere dich, dass beim nächsten regulären Lauf nicht unbemerkt veraltete Ausgaben wiederverwendet werden.

Bleibt der Code beim Self-Hosting von Open WebUI lokal?

Open WebUI und sein Terminal können selbst gehostet werden, während der ausgewählte Coding-Agent ein entferntes Modell verwendet. Ermitteln Sie, wohin der Agent Systemprompts, Dateiauszüge und Testprotokolle sendet. Prüfen Sie die Anbieterkonfiguration, bevor Sie ein privates Checkout verbinden. Speichern Sie die Zugangsdaten des Anbieters in der dafür vorgesehenen Secret-Konfiguration des Dienstes und geben Sie sie weder in Prompts noch in Protokollen weiter.

Verwenden Sie einen lokalen Modellendpunkt, wenn Ihre Anforderungen die externe Verarbeitung ausschließen. Verifizieren Sie den Endpunkt und die Fallback-Konfiguration des Agenten und prüfen Sie anschließend alle Netzwerkbeschränkungen, die für das Terminal gelten. Weitere Informationen zur Begrenzung der Risiken finden Sie in diesem Leitfaden zur KI-gestützten Schwachstellenanalyse und zum Umgang mit Geheimnissen.

Wie wird aus einem Job, der nur Berichte erstellt, ein regelmäßiger Workflow?

Sobald sowohl erfolgreiche als auch fehlgeschlagene erste Läufe nachvollziehbar sind, fügen Sie einen regelmäßigen Zeitplan hinzu, der sich nicht mit einem anderen Job überschneidet, der dasselbe Verzeichnis verwendet. Versehen Sie Berichte mit einem Zeitstempel und der Repository-Revision. Halten Sie die Benachrichtigungen einfach: Machen Sie handlungsbedürftige Fehler sichtbar und bewahren Sie genügend Kontext auf, um sie reproduzieren zu können. Prüfen Sie regelmäßig, ob Agent-Zugangsdaten, Terminalverbindung und geplantes Verzeichnis nach Aktualisierungen weiterhin funktionieren.

Wenn Sie später Patches zulassen, halten Sie diese in einem isolierten Branch und verlangen Sie vor dem Zusammenführen eine Prüfung. Andernfalls können Wiederholungsversuche des Schedulers Nebenwirkungen duplizieren. Ein Job, der nur Berichte erstellt, lässt sich leichter wiederholen, weil er lediglich ein Ergebnis schreibt, während Abhängigkeitsaktualisierungen und Bereitstellungsbefehle den Zustand ändern. Behandeln Sie diesen Übergang als separate Berechtigungsentscheidung.

FAQ

In welcher Version wurden Agent-Automatisierungen eingeführt?

Die betreffende Funktion ist in Open WebUI v0.13.3 aufgeführt. Die Agentenauswahl-Funktion in v0.13.1 hängt damit zusammen, ist aber eine separate Funktion.

Warum wird der Agent nicht im Auswahlmenü angezeigt?

Vergewissern Sie sich, dass das ausgewählte Terminal erreichbar ist und diesen Agenten anbietet und dass Ihre installierte Version und Kontoberechtigungen die Funktion bereitstellen.

Kann ich einen Ordner auf meinem Laptop auswählen?

Wählen Sie im Terminal einen Pfad, über den der Job tatsächlich ausgeführt wird. Binden Sie das Checkout dort ein oder kopieren Sie es dorthin, falls nötig.

Wird ein Automatisierungsergebnis an einen Kanal gesendet?

In den Versionshinweisen zu v0.13.3 wird die Zustellung per Chat für Agent-Automatisierungen angegeben. Prüfen Sie die Optionen der aktuellen Version, bevor Sie sich auf ein anderes Ziel als diesen Chat verlassen.

Was soll ich tun, wenn sich zwei Läufe überschneiden?

Verwenden Sie separate Worktrees oder wählen Sie einen Zeitplan und ein Laufzeitlimit, die Überschneidungen verhindern. Prüfen Sie jeden Lauf, bei dem die falsche Revision verwendet wurde, bevor Sie dem Bericht vertrauen.

Fazit

Verwenden Sie ein Terminal, ein abgegrenztes Arbeitsverzeichnis und einen kleinen Job, der nur Berichte erstellt, um den gesamten Ablauf zu prüfen. Verifizieren Sie den Modellanbieter, testen Sie sowohl Erfolge als auch Fehler und halten Sie Produktionszugangsdaten aus dem Terminal heraus. Sobald sich das Ergebnis wiederholen lässt, kann dieselbe Einrichtung regelmäßige Repository-Prüfungen übernehmen.