AI Agents, Tools und Human-in-the-Loop

AI Agents, Tools und Human-in-the-Loop

0:00 Seit n8n 2.6 gibt es eine Funktion, die ich für eine der wichtigsten der letzten Jahre halte: Man kann einzelne Werkzeuge eines Agenten mit einer menschlichen Freigabe versehen. Warum ist das so bedeutsam? Weil vorher die einzige Möglichkeit darin bestand, dem Modell zu sagen, es möge bitte vorsichtig sein. Das ist eine Bitte.

0:20 Eine Freigabe ist eine Sperre. Und dieser Unterschied ist genau der zwischen einem Vorführprojekt und etwas, das man in einem Betrieb einsetzen kann. Dieses Modul handelt von Agenten — und vor allem von ihren Grenzen.

AI Agents, Tools und Human-in-the-Loop

0:33 Das letzte Modul des vierten Tages, und es ist der Höhepunkt des KI-Blocks. Zuerst die Abgrenzung: Was unterscheidet einen Agenten von einer Chain und von einem gewöhnlichen Workflow? Dann die Werkzeuge — wie schneidet man sie, und wie beschreibt man sie so, dass das Modell sie richtig einsetzt? Danach die menschliche Freigabe im Detail.

0:53 Und zum Schluss die Grenzen: Was kann ein Agent eigentlich anrichten, und woran hängt das wirklich?

Chain, Workflow und Agent unterscheiden

1:00 Fangen wir mit der Abgrenzung an. Drei Stufen, und von oben nach unten steht immer weniger vorher fest — das ist dieselbe Rutschbahn wie im ersten Modul, nur jetzt mit Bausteinen. Eine Chain folgt einer vorher festgelegten Abfolge von Aufrufen. Ein Agent ist demgegenüber — und diese Formulierung aus der Dokumentation finde ich sehr treffend — eine Chain, die entscheiden kann.

1:23 Er nutzt ein Sprachmodell, um zu bestimmen, welche Aktionen er ausführt, und wählt zur Anfrage die passenden Werkzeuge. Der Vergleich, der hier trägt: Die Chain ist ein Rezept, der Agent ist ein Koch. Das Rezept macht jedes Mal dasselbe. Der Koch sieht, was im Kühlschrank ist, und entscheidet. Beides hat seinen Platz — nur verlangt das Zweite mehr Vertrauen und mehr Aufsicht.

1:47 Drei Zeilen, zwei Spalten, und beide Spalten sind aufschlussreich. Beim Ablauf: Der Workflow ist vollständig vorgegeben, die Chain hat eine feste Abfolge von Aufrufen, und beim Agenten wählt das Modell. Beim Speicher wird es interessant: Der Workflow hält seinen Zustand selbst, die Chain kann in n8n gar keinen Speicher nutzen — das hatten wir im vorletzten Modul —, und der Agent bekommt ihn über einen Memory-Sub-Node.

2:11 Die Fußzeile klärt eine häufige Frage: n8n stellt einen Agent-Baustein bereit, der sich über seine Einstellungen als verschiedene Agententypen verhält. Dieser Punkt überrascht beim ersten Mal, und er hat unmittelbar mit Kosten zu tun. Der Agent läuft je Anfrage mehrfach, nicht einmal. Ein Lauf richtet ein, ein weiterer ruft ein Werkzeug auf, ein dritter bewertet das Ergebnis und formuliert die Antwort. Jeder dieser Läufe kostet einen Modellaufruf.

2:39 Und die Zahl der Läufe steht vorher nicht fest — sie hängt davon ab, was das Modell für nötig hält. Das ist der Preis der Entscheidung. Wenn Sie also die Kosten eines Agenten kalkulieren, rechnen Sie nicht mit einem Aufruf je Anfrage. Rechnen Sie mit mehreren und messen Sie nach. Der erste Punkt ist der häufigste Architekturfehler: Ein Agent wird eingesetzt, wo die Abfolge ohnehin feststeht. Dann zahlen Sie für Entscheidungen, die schon getroffen sind.

3:06 Der zweite ist die Speicher-Erwartung: Die Chain soll sich an das letzte Gespräch erinnern — sie kann es nicht, und zwar prinzipiell. Der dritte ist eine Frage, die man früh klären sollte: Der Speicher wird angehängt, ohne zu klären, wessen Gespräch er eigentlich hält. Und der vierte ist die Kostenfalle von eben: Gerechnet wird für einen Aufruf, nicht für die tatsächlichen Läufe.

Tools schneiden und beschreiben

3:29 Jetzt zu den Werkzeugen. Und hier ist eine Umstellung nötig: Die Beschreibung eines Werkzeugs ist keine Dokumentation für Menschen. Sie ist die Schnittstelle, die das Modell liest. Ein Tool ist eine Zusatzressource, die das Modell heranziehen kann, um an Informationen oder Funktionen zu kommen. In n8n kommen vor allem drei infrage.

3:50 Call n8n Workflow Tool lädt einen beliebigen Workflow als Werkzeug — das ist der wichtigste, denn damit wird alles, was Sie in den letzten Tagen gebaut haben, zum Werkzeug eines Agenten. Custom Code Tool führt eigenen Code aus. Und HTTP Request Tool ruft eine Schnittstelle auf; das ist derselbe Baustein aus Modul fünf, nur in anderer Rolle.

4:10 Sie sehen: Sie haben die Werkzeuge längst, sie bekommen nur einen neuen Aufrufer. Diese Funktion ist der Kern der Agenten-Programmierung, und ihr Name führt etwas in die Irre. Sie sagen nicht, woher ein Wert kommt — Sie geben einen Hinweis, was Sie brauchen. Das Modell sucht dann in seinem Kontext, in anderen Werkzeugen und in den Eingabedaten danach; in einem Dialog fragt es notfalls nach.

4:35 Die Argumente sind also Hinweise, keine Referenzen auf vorhandene Werte. Deshalb ist der Schlüssel so wichtig: Ein sprechender Name führt das Modell, ein kryptischer verwirrt es. Dazu kommen optional Beschreibung, Typ und Vorgabewert — nutzen Sie sie, sie kosten nichts und schärfen viel. Vier Regeln. Ein Werkzeug, eine fachliche Aufgabe — nicht eine ganze Anwendung.

4:57 Die Beschreibung sagt, wann es zu benutzen ist, nicht nur was es tut; das ist der Unterschied, den ich eingangs meinte. Lesende und schreibende Werkzeuge werden getrennt, nie zusammengelegt — und Sie ahnen schon, warum: Nur so lässt sich die Freigabe gezielt auf das Schreibende legen. Und die vierte Regel ist die, die man am schwersten einhält: Je weniger Werkzeuge angehängt sind, desto verlässlicher die Wahl.

5:22 Ein Agent mit drei guten Werkzeugen arbeitet besser als einer mit zwölf. Der erste Punkt betrifft die Parameterfunktion: Der Schlüssel ist kryptisch, und das Modell füllt ihn falsch. Der zweite ist der folgenschwerste: Ein Werkzeug kann lesen und schreiben, damit es nur eines sein muss — damit haben Sie sich die Möglichkeit genommen, gezielt abzusichern.

5:43 Der dritte ist die Zwölf-Werkzeuge- Falle von eben. Und der vierte ist eine technische Einschränkung, die man kennen muss: Die Parameterfunktion steht beim Code-Tool nicht zur Verfügung — sie gilt für Werkzeuge am Agenten, nicht für alle Sub-Bausteine.

Human-in-the-Loop für Tool Calls

5:57 Jetzt zu der Funktion, mit der ich dieses Modul eröffnet habe. Seit n8n 2.6 ist die Freigabe technisch erzwungen statt erbeten — und das ändert, was man verantworten kann. Für einzelne Werkzeuge lässt sich eine menschliche Freigabe verlangen, bevor der Agent sie ausführt. Der Workflow pausiert dann und wartet — technisch übrigens genau so, wie wir es in Modul vier beim Wait-Baustein gesehen haben.

6:22 Zustimmung führt das Werkzeug mit den vom Modell bestimmten Eingaben aus. Ablehnung bricht die Aktion ab und teilt dem Modell die Zurückweisung mit. Dieses Letzte ist wichtig: Der Agent erfährt, dass er abgelehnt wurde, und kann darauf reagieren — etwa mit einer Rückfrage statt mit einem zweiten Versuch. Fünf Schritte. Öffnen Sie am Agent-Baustein den Tools-Verbinder.

6:44 Wählen Sie im Abschnitt Human review den Freigabekanal und richten Sie ihn ein — zur Auswahl stehen der eingebaute Chat, Slack, Teams, Telegram, E-Mail und einige mehr. Hängen Sie die freigabepflichtigen Werkzeuge an diesen Schritt; nur diese, nicht alle. Versehen Sie die Nachricht an die prüfende Person mit Kontext, dazu gleich mehr.

7:04 Und erproben Sie, was bei Ablehnung geschieht — nicht nur den Zustimmungsfall. Die Fußzeile nennt den entscheidenden Vorteil: Die Freigabe lässt sich auf einzelne Werkzeuge legen, was genauer ist als eine Prüfung der Gesamtausgabe. Zwei Variablen, und sie entscheiden darüber, ob die Freigabe eine echte Prüfung ist oder ein Klick. Die erste liefert den Namen des Werkzeugs, das der Agent aufrufen will.

7:29 Die zweite die Parameter — also die konkreten Werte, mit denen er es täte. Nehmen Sie beide in die Nachricht auf. Eine Anfrage, die nur sagt „Der Agent möchte einen Einsatz anlegen, einverstanden?", ist wertlos; eine, die sagt „für Anlage KW-3312, Notdienst, morgen früh", kann man beurteilen. Und ein praktischer Hinweis aus der Dokumentation: Die Freigabe darf über einen anderen Kanal laufen als das Gespräch selbst.

7:56 Vier Fälle aus der Dokumentation. Das Werkzeug wirkt unumkehrbar — löschen, senden, bestellen. Regulatorische Vorgaben verlangen eine menschliche Zustimmung; in regulierten Branchen ist das keine Kür. Die Entscheidung hat erhebliche geschäftliche Tragweite. Und der vierte gefällt mir besonders gut, weil er einen Weg beschreibt statt eines Zustands: Vertrauen wird aufgebaut — erst mit Freigabe, dann schrittweise ohne.

8:21 Sie müssen sich also nicht heute entscheiden, wie viel Autonomie der Agent für immer bekommt. Sie fangen eng an und öffnen, wenn die Zahlen es tragen. Der erste Punkt ist der wichtigste dieser Folie: Jede Aktion wird freigabepflichtig, und die Prüfung wird zum Wegklicken. Wer zwanzigmal am Tag bestätigt, liest beim einundzwanzigsten Mal nicht mehr — dann haben Sie die Sicherheit formal erfüllt und faktisch abgeschafft.

8:46 Der zweite ist der Kontextmangel von eben: Die Anfrage nennt das Werkzeug, aber nicht die Werte. Der dritte ist ein Betriebsproblem: Es gibt keine Zeitgrenze, und der Vorgang wartet unbegrenzt. Und der vierte ist die ungetestete Hälfte: Der Ablehnungsfall wurde nie erprobt.

Grenzen setzen

9:03 Zum Abschluss die nüchternste Betrachtung dieses Tages. Ein Agent kann genau so viel, wie seine Werkzeuge dürfen — nicht mehr und nicht weniger. Daraus folgt alles Weitere. Vier Punkte, und keiner davon steht im Prompt. Die Grenze hängt an den Berechtigungen der Credentials hinter den Werkzeugen — das ist der Scope-Gedanke aus Modul fünf, hier in seiner wichtigsten Anwendung.

9:26 Sie hängt an der Auswahl der angehängten Werkzeuge, nicht an der Formulierung. Sie hängt an einer Obergrenze für Läufe und Laufzeit je Anfrage. Und sie hängt an der Prüfung, die nach dem Agenten stattfindet. Wenn Sie sich eine Sache aus diesem Modul merken, dann diese: Die Sicherheit eines Agenten wird außerhalb des Modells konfiguriert.

9:47 Vier Wege ins Verderben. Eine eingebettete Anweisung im verarbeiteten Text wird befolgt — Prompt Injection aus dem letzten Modul, jetzt mit Werkzeugen in Reichweite. Ein Werkzeug wird zweckentfremdet, weil seine Beschreibung zu weit ist; das ist die Kehrseite der Beschreibung als Schnittstelle. Der Agent ruft dasselbe Werkzeug in Schleife auf, bis die Kosten auffallen — meistens am Monatsende.

10:10 Und der vierte ist ein Prüfproblem: Zwischenergebnisse werden nicht angesehen, nur das Endergebnis. Dabei steht der Fehler oft im dritten von fünf Werkzeugaufrufen. Der erste Punkt ist die Zusammenfassung des ganzen Kapitels: Das Credential des schreibenden Werkzeugs hat Vollzugriff. Dann nützt die schönste Freigabe nichts, wenn sie einmal umgangen wird. Der zweite ist eine fehlende Bremse: Es gibt keine Obergrenze für die Zahl der Werkzeugaufrufe je Anfrage.

10:38 Der dritte ist der gefährlichste Einzelfall: Der Agent bekommt ein Werkzeug, das beliebige URLs aufrufen kann — damit haben Sie ihm das Internet gegeben. Und der vierte ist der Irrtum, gegen den dieses ganze Modul geschrieben ist: Der Schutz besteht aus einem Satz im Systemprompt.

Übung

10:55 Jetzt bauen Sie einen Agenten, der lesen darf und fragen muss. Das ist das Muster, mit dem man in einem echten Betrieb anfängt — und von dem aus man schrittweise öffnet. Der Kesselwerk-Agent soll Anlagenhistorie und Ersatzteilverfügbarkeit lesen dürfen und daraus einen Einsatzvorschlag machen. Den Einsatz in Einsatzplan anlegen darf er erst nach Freigabe über den Kanal Kurzdraht.

11:17 Sie sehen daran den Werkzeugschnitt aus dem zweiten Kapitel in der Anwendung: zwei lesende Werkzeuge, eines schreibend, sauber getrennt. Hätten Sie das in einem Werkzeug zusammengefasst, könnten Sie die Freigabe nicht gezielt setzen — Sie müssten entweder alles freigeben lassen oder nichts. Das Lernziel: Werkzeuge so schneiden und absichern, dass eine wirksame Aktion nicht allein vom Modell abhängt.

11:40 Erfolgreich sind Sie, wenn die lesenden Werkzeuge ohne Rückfrage laufen, das schreibende erst nach Zustimmung, und eine Ablehnung nachweislich zu keinem Einsatz führt. Das Wort nachweislich verlangt, dass Sie den Ablehnungsfall wirklich durchspielen. Wer früh fertig ist, setzt eine Obergrenze für Werkzeugaufrufe je Anfrage und begründet die Zahl — und Begründung heißt hier: beobachten, wie viele Aufrufe ein normaler Fall braucht, und dann Luft lassen.

12:06 Siebzig Minuten, fünf Schritte. Legen Sie drei Werkzeuge an, zwei lesend, eines schreibend. Schreiben Sie je Werkzeug eine Beschreibung, die den Anwendungsfall nennt — nicht die Technik. Richten Sie die Freigabe ein und hängen Sie nur das schreibende Werkzeug daran; achten Sie darauf, dass es nicht zusätzlich direkt am Agenten hängt.

12:26 Versehen Sie die Freigabenachricht mit Werkzeugname und Parametern. Und spielen Sie zum Schluss Zustimmung und Ablehnung durch — und speisen Sie dann eine manipulierte Meldung ein. Der letzte Teil ist der lehrreichste. Vier Fallen. Erstens, und das passiert wirklich oft: Das schreibende Werkzeug hängt versehentlich zusätzlich direkt am Agenten — dann gibt es einen Weg daran vorbei, und der Agent findet ihn.

12:51 Zweitens: Die Freigabenachricht zeigt nicht, welche Anlage betroffen ist; das ist der Kontextmangel aus dem dritten Kapitel. Drittens: Die manipulierte Meldung wird nicht ausprobiert, weil der Fall unangenehm ist — genau deshalb sollten Sie es tun. Und viertens: Nach der Ablehnung läuft der Agent weiter, als sei nichts geschehen. Auch die Reaktion auf ein Nein will gestaltet sein.