Erweiterungen und agentische Abläufe

Erweiterungen und agentische Abläufe

0:00 Willkommen zu Modul zehn. Im letzten Modul haben wir den Störmelder von außen an Lotsenhaus angebunden, über einen eigenen Dienst. Jetzt gehen wir einen Schritt tiefer, in die Plattform selbst. Open WebUI lässt sich mit Python erweitern, mit Werkzeugen für das Modell und mit Funktionen, die das Verhalten der ganzen Plattform verändern.

0:19 Das ist mächtig, und genau deshalb gefährlich, denn jede Erweiterung ist Code, der auf dem Server läuft. Dazu kommt eine zweite Entwicklung: Modelle rufen Werkzeuge inzwischen selbstständig und mehrfach hintereinander auf. Wir klären, wie man solche Abläufe begrenzt, wo Codeausführung hingehört und wie eine Erweiterung bei Brandtner geprüft und freigegeben wird.

Erweiterungen und agentische Abläufe

0:39 Der Satz auf dieser Folie fasst die zweite Hälfte des Tages in zwei Gedanken. Erstens: Jede Erweiterung ist Code mit den Rechten der Plattform. Wer eine installiert, gibt ihr dieselben Schlüssel, die Open WebUI selbst hat. Zweitens: Ein Agent ist nur so verlässlich wie seine engste Grenze. Nicht die Intelligenz des Modells schützt Sie, sondern die Leitplanken, die Sie ziehen. Beides schauen wir uns jetzt genau an.

Tools und Functions

1:05 Zuerst ein Überblick über den Baukasten. Open WebUI unterscheidet zwischen Fähigkeiten, die das Modell nutzt, und Verhalten, das die Plattform prägt. Fünf Bausteine, und die Logik dahinter ist die Frage, wer sie auslöst. Ein Tool ruft das Modell selbst auf, wenn es etwa eine API abfragen will. Eine Pipe tritt dagegen als eigenes Modell in der Auswahl auf und beantwortet die Anfrage ganz allein.

1:30 Ein Filter sitzt wie ein Zollhäuschen im Datenstrom und kann Anfragen und Antworten unterwegs verändern. Eine Action ist ein Knopf an der Nachricht, den ein Mensch drückt. Und Events, neu seit Version 0.10.0, reagieren auf Systemereignisse wie eine Anmeldung. Wichtig ist die Fußzeile: Alles außer den Tools zählt als Function, und Functions verwalten nur Administratoren.

1:54 So sieht ein Werkzeug im Kern aus, und es ist überraschend schlicht. Eine Klasse mit Einstellungen, die der Admin setzt, hier die Adresse des Störmelders und ein Zeitlimit. Darunter eine Methode, die den Status eines Tickets liest. Worauf es ankommt, ist der Kommentar unter dem Methodennamen, der Docstring. Den liest das Modell, um zu verstehen, wofür das Werkzeug gut ist und was es als Parameter erwartet.

2:18 Er ist also keine Doku für Kollegen, sondern eine Gebrauchsanweisung für die Maschine. Und die Fußzeile verrät eine Konvention mit Folgen: Jede öffentliche Methode wird zum Werkzeug. Hilfsfunktionen beginnen deshalb mit einem Unterstrich. Valves heißen auf Deutsch Ventile, und das Bild passt: Es sind die Stellschrauben einer Erweiterung. Es gibt zwei Sorten.

2:40 Valves gelten für alle und setzt der Admin, bei Tools auch Eigentümer und Personen mit Schreibrecht. UserValves stellt dagegen jede Person für sich ein, etwa ein persönliches Kürzel. Diese Trennung ist wichtig, damit nicht jeder an der Serveradresse dreht. Bei den letzten beiden Punkten sollten Sie hellhörig werden. Ein Passwortfeld versteckt den Wert nur auf dem Bildschirm, gespeichert wird er im Klartext.

3:03 Verschlüsselt wird erst mit einer eigenen Einstellung, und die hängt am geheimen Schlüssel der Plattform. Hier ein Filter, der eine Regel aus unserer Governance-Matrix technisch unterstützt. Streng vertrauliche Inhalte sollen gar nicht erst an ein Modell gehen. Der Filter schaut sich vor dem Modellaufruf die letzte Nachricht an, und findet er das Sperrwort, bricht er mit einer Meldung ab.

3:27 Das Muster ist typisch für Filter: eingreifen, bevor etwas passiert, statt hinterher aufzuräumen. Aber die Fußzeile ist ehrlich, und das sollten Sie auch sein, wenn Sie so etwas einführen. Dieser Filter ist ein Hinweisgeber, keine Datenschleuse. Ein Stichwort erkennt längst nicht jedes vertrauliche Dokument. Er fängt Versehen ab, keine Absicht.

3:48 Wer Open WebUI schon länger kennt, ist vielleicht über Pipelines gestolpert, einen eigenen Worker-Container, in dem Erweiterungen liefen. Diese Tabelle zeigt, wohin das alles umgezogen ist. Was früher eine Pipeline vom Typ pipe oder filter war, ist heute eine Function direkt im Prozess von Open WebUI. Und wer einen externen Dienst anbinden will, nimmt die Wege aus dem letzten Modul, einen OpenAPI Tool Server oder einen MCP-Server. Der zusätzliche Container entfällt ganz.

4:17 Für Lotsenhaus ist die Entscheidung damit einfach: Die Doku führt Pipelines als Legacy, nur noch für bestehende Installationen. Neu bauen wir darauf nichts.

Erweiterungen verantwortlich betreiben

4:27 Eine Erweiterung zu schreiben ist schnell erledigt. Eine Erweiterung zu betreiben ist eine Verantwortung, die oft unterschätzt wird. Denn wer importiert, installiert Anwendungscode. Diese Folie ist bewusst unbequem. Tools, Functions und Pipelines führen beliebigen Python-Code aus, mit allen Rechten von Open WebUI. Stellen Sie sich vor, Sie lassen einen Handwerker ins Haus und geben ihm den Generalschlüssel.

4:52 Er könnte Daten mitnehmen, Schadsoftware nachladen oder von Ihrem Netz aus andere Systeme angreifen. Dass eine Erweiterung in der Community beliebt oder hervorgehoben ist, sagt darüber nichts. Die Einträge werden ungeprüft eingereicht. Und der letzte Punkt erweitert den Blick über die Oberfläche hinaus: Wer das Datenverzeichnis beschreiben kann, kann ebenfalls Code einschleusen.

5:15 Auch dieser Speicherort gehört also zur Angriffsfläche. Daraus folgt ein Freigabeprozess, der sich bewusst an normaler Softwareentwicklung orientiert. Am Anfang steht das vollständige Lesen des Codes, mit einem Blick auf Abhängigkeiten und Netzwerkziele. Dann wandert die Datei mit Versionsangabe ins Repository lotsenhaus-betrieb und bekommt ein Review. Getestet wird auf der Testinstanz, auch mit Grenzfällen.

5:40 Ein Punkt verdient besondere Beachtung: Abhängigkeiten gehören ins Image, nicht in eine Installation, die beim Speichern nebenbei passiert. Deshalb schaltet die Fußzeile genau diese automatische Installation in Produktion ab. Zuletzt importiert lh-admin und dokumentiert Zweck, Verantwortliche und Version. So weiß später jemand, warum die Erweiterung da ist.

6:02 Vier Fallen aus dem Betrieb. Die erste ist eine Rechtefrage: Wer normalen Nutzern das Recht auf Workspace Tools gibt, erlaubt ihnen eigenen Python-Code auf dem Server. Das wirkt wie eine harmlose Freigabe, ist aber eine weitreichende. Die zweite und dritte betreffen Abhängigkeiten. Verlangen zwei Erweiterungen verschiedene Versionen eines Pakets, gewinnt eine, und welche, ist Zufall.

6:26 Laufen mehrere Worker, installieren sie gleichzeitig und stolpern übereinander. Beides verschwindet, wenn Pakete ins Image wandern. Die vierte Falle ist die leiseste: Eine Function, die beim Laden scheitert, wird stillschweigend inaktiv. Den Grund finden Sie nur im Serverlog.

Agentische Abläufe begrenzen

6:43 Jetzt zum Modell selbst. Es entscheidet zunehmend allein, welches Werkzeug es wann aufruft. Umso wichtiger wird, wo die Plattform die Grenzen zieht. Agentisch heißt hier etwas sehr Konkretes. Seit Version 0.10.0 ist der Native Mode Standard für Werkzeugaufrufe. Das Modell bekommt die Werkzeuge als strukturierte Beschreibung und ruft sie selbst auf, und zwar auch mehrmals hintereinander.

7:08 Vergleichen Sie das mit einem Praktikanten, dem Sie nicht mehr jeden Handgriff ansagen, sondern ein Ziel. Er entscheidet selbst, welche Schritte nötig sind. Das ist effizient, aber eben auch eine Übergabe von Kontrolle. Der frühere Modus, bei dem die Werkzeuge über den Prompt beschrieben wurden, heißt jetzt Legacy und wird nicht mehr unterstützt. Der Weg zurück ist also keine Option.

7:31 Diese Folie dämpft Erwartungen, und das ist gut so. Ob ein agentischer Ablauf funktioniert, hängt stark am Modell. Kleine lokale Modelle unter etwa dreißig Milliarden Parametern erzeugen oft fehlerhaftes JSON, und dann scheitert der Werkzeugaufruf schon an der Form. Mehrstufige Ketten brechen früher als einzelne Aufrufe, besonders in langen Gesprächen. Und ein Werkzeug anzubinden macht ein Modell nicht klüger im Umgang damit.

7:57 Für Lotsenhaus mit dem lokalen Modell auf inferenz-01 ist das eine wichtige Einordnung. Die Doku empfiehlt bei Problemen ein stärkeres Modell, nicht den Rückweg zum alten Modus. Planen Sie Tests deshalb mit dem Modell, das später wirklich läuft. Diese Tabelle ist der Werkzeugkasten für Leitplanken. Die Logik: Jede Zeile begrenzt eine andere Dimension. Die erste begrenzt, wie viele Werkzeugrunden eine Antwort drehen darf.

8:23 Der Standard liegt bei 256, das ist großzügig. Die nächsten beiden begrenzen Zeit, einmal das Warten auf einen Tool-Server, einmal das Warten auf eine Rückfrage im Browser, und für die gibt es ohne Ihr Zutun kein Limit. Die letzten beiden begrenzen die Auswahl, also welche Werkzeuge eines MCP-Servers und welche eingebauten Kategorien das Modell überhaupt sieht.

8:46 Und die Fußzeile hilft beim Budget: Die Token-Angaben der API zählen alle Modellaufrufe einer Antwort zusammen. Im letzten Modul haben wir Freigaben über die Plattform eingeholt. Hier sitzt die Freigabe im Werkzeug selbst. Bevor die Methode die Priorität eines Tickets ändert, schickt sie eine Bestätigungsfrage in den Browser, mit Ticketnummer und neuer Stufe. Dann wartet sie.

9:09 Sagt der Mensch nein, kommt eine klare Meldung zurück, und nichts passiert. Das Schöne an diesem Muster: Die Bremse ist fest eingebaut und hängt nicht davon ab, welchen Modus eine Person gewählt hat. Die Fußzeile nennt den Haken. Ohne gesetztes Zeitlimit wartet die Rückfrage unbegrenzt, und ein Lauf bleibt einfach hängen, wenn niemand antwortet.

9:30 Vier Fallen, die alle mit falschem Vertrauen zu tun haben. Wer die Grenze von 256 Werkzeugrunden nicht anfasst, erlaubt einem Lauf, sehr lang und sehr teuer zu werden. Ein Werkzeug, das sich als lesend ausgibt, intern aber schreibt, unterläuft jede Freigabelogik, die auf diese Unterscheidung baut. Wer ein schwaches Modell retten will, indem er auf Legacy zurückschaltet, verliert dort sämtliche eingebauten Werkzeuge.

9:55 Und schließlich der Test: Freigaben, die im Chat funktionieren, sagen nichts über Automationen. Dort greifen die Tool Permissions nicht. Testen Sie Freigaben deshalb in jedem Kontext, in dem das Werkzeug später tatsächlich läuft.

Codeausführung

10:10 Ein Modell, das Code nicht nur schreibt, sondern auch ausführt, ist ein großer Schritt. Wo dieser Code läuft, ist deshalb keine Komfortfrage, sondern eine Architekturentscheidung. Open Terminal gibt einem Modell eine echte Shell und ein eigenes Dateisystem, meist in einem Docker-Container. Stellen Sie es sich als Werkstatt vor, die neben dem Büro steht.

10:32 Das Modell bekommt Werkzeuge, um Befehle auszuführen, Dateien zu lesen und Dateien zu schreiben. Damit kann es Daten auswerten, Skripte testen oder Dateien umwandeln, statt nur darüber zu reden. Wichtig ist der Unterschied zu früher. Die ältere Codeausführung im Browser des Nutzers oder über Jupyter führt die Doku nur noch als Legacy.

10:51 Wer heute Codeausführung plant, plant also einen eigenen Dienst, mit allem, was zum Betrieb eines Dienstes gehört. Die mittlere Spalte ist hier die entscheidende, denn sie beantwortet die Frage nach der Isolation. Der alte Code Interpreter läuft im Browser und ist nur noch Bestand. Open Terminal isoliert mit einem Container je Verbindung, gut für eine Person oder ein Team.

11:14 Der Multi-User-Modus teilt einen Container in Arbeitsbereiche, aber, und das steht ausdrücklich dort, ohne Sicherheitsgrenze. Echte Trennung je Nutzer bietet erst der Orchestrator Terminals, und der braucht für Produktion eine Enterprise-Lizenz. Ganz unten steht Open WebUI Computer, das auf den echten Rechner einer Person zugreift.

11:33 Das ist eine persönliche Arbeitsumgebung für genau einen vertrauten Eigentümer, keine Plattform. Für das Seminarlabor haben wir vier Regeln, und sie lassen sich auf jede spätere Einführung übertragen. Open Terminal läuft immer im Container und mit Grenzen für Speicher und Rechenzeit. Ohne Docker gelten schlicht die Rechte des Hostkontos, und das will niemand.

11:54 Der API-Schlüssel wird bewusst gesetzt, stark und eigen, statt den Wert zu behalten, der beim Start erzeugt wurde. Die Verbindung legt ein Admin an, damit der Schlüssel auf dem Server bleibt und sich Rechte steuern lassen. Und mehrere Personen an einem Container gibt es nur im Multi-User-Modus, und nur, wenn alle einander gleich vertrauen.

12:14 Die vier Fallen dieses Kapitels entstehen fast immer aus Bequemlichkeit. Codeausführung wird freigeschaltet, weil sie praktisch ist, ohne vorher zu klären, welche Datenklassen dort landen dürfen und welches Netz der Container erreicht. Ein gemeinsamer Container ohne Multi-User-Modus bedeutet, dass alle dieselbe Shell, dieselben Dateien und dasselbe Netzwerk teilen.

12:35 Der Multi-User-Modus wiederum wird gern für eine Sicherheitsgrenze gehalten, die er nicht ist. Für Personen, die einander nicht vertrauen, braucht es Terminals auf Kubernetes. Und wer Terminals im Pilot produktiv nutzt, sollte die Enterprise-Lizenz von Anfang an einplanen, sonst wird der Erfolg des Pilots zum Lizenzproblem.

Übung

12:54 Klein, geprüft, begrenzt, freigegeben. Diese vier Worte beschreiben die Übung, und sie fassen zugleich das ganze Modul zusammen. In dieser Übung entsteht ein eigenes Werkzeug für den Störmelder, aber das Werkzeug ist nur das Mittel. Geübt wird, eine Erweiterung so zu entwerfen, zu prüfen und zu begrenzen, dass ein mehrstufiger Ablauf erst dann etwas bewirkt, wenn ein Mensch zugestimmt hat.

13:18 Fertig sind Sie, wenn das Werkzeug SM-4711 liest, die Priorität nur nach Bestätigung ändert, bei einer Ablehnung sauber abbricht und mit Versionsangabe freigegeben ist. Achten Sie besonders auf den Abbruch, denn ein Nein muss genauso ordentlich enden wie ein Ja. Wer schnell vorankommt, ergänzt den Filter gegen streng vertrauliche Inhalte.

13:39 Der Ablauf folgt der Logik des Moduls. Zuerst schreiben Sie das Werkzeug mit Einstellungen für Adresse und Zeitlimit, einer lesenden und einer schreibenden Methode. In die schreibende kommt die Bestätigungsfrage. Dann begrenzen Sie die Werkzeugrunden auf der Testinstanz und spielen den Ablauf mit Ja und mit Nein durch. Erst danach geht der Code durch die Freigabe-Checkliste und ins Repository lotsenhaus-betrieb. Zum Schluss Import, Freigabe für lh-it und Vorführung.

14:06 Die Fußzeile beschreibt den Ablauf, den Sie zeigen: lesen, vorschlagen, warten, ausführen. Im nächsten Modul drehen wir die Perspektive um und sichern die Plattform gegen Angriffe ab.