6.7 KI-Agentinnen und agentische Systeme

Überblick und Motivation

Eine KI-Agentin ist ein Large Language Model (LLM), eingewickelt in eine Schleife: ihr wird ein Ziel gegeben, sie kann Werkzeuge aufrufen, sie hält etwas Gedächtnis dessen, was sie getan hat, und sie entscheidet ihren eigenen nächsten Schritt, bis das Ziel erreicht ist oder sie aufgibt. Diese Schleife ist der ganze Unterschied zwischen einer Agentin und den schlichten Prompt-Antwort-Aufrufen aus Kapitel 6.3. Ein einzelner Aufruf beantwortet eine Frage. Eine Agentin liest ihre E-Mail, durchsucht eine Datenbank, legt ein Ticket an, prüft das Ergebnis, und versucht es erneut. Das Modell produziert nicht mehr nur Text; es wählt Aktionen in Ihren Systemen.

Diese Verschiebung ändert das Engineering-Problem. Wenn ein Modell nur Worte schreibt, ist eine schlechte Ausgabe ein schlechter Satz. Wenn ein Modell Werkzeuge steuert, kann eine schlechte Ausgabe eine falsche Nachricht senden, eine Aufzeichnung löschen, oder Geld bewegen. Eine intelligente Agentin wird also am besten als nicht vertrauenswürdige Planerin verstanden, die innerhalb eines vertrauenswürdigen Systems sitzt, und der meiste Ihrer Arbeit geht darein, zu begrenzen, was diese Planerin tun darf. Dieses Kapitel baut direkt auf den LLM-Grundlagen aus Kapitel 6.3, den Vertrauens- und Rechenschaftspflicht-Anliegen aus Kapitel 6.5, und den Plattformpraktiken aus Kapitel 6.6 auf.

Für große Teams sind die Einsätze ebenso organisatorisch wie technisch. Unternehmen wollen Agentinnen in echte interne Systeme verdrahtet (Ticketing, Finanzen, Kundenaufzeichnungen), was bedeutet, dass Agentinnen echte Zugriffskontrollen und echte Änderungsmanagement-Pflichten erben. Behörden fügen öffentliche Rechenschaftspflicht hinzu: eine autonome Aktion, die eine Bürgerin betrifft, muss erklärbar, beaufsichtigbar, und im Nachhinein prüfbar sein. Das Muster ist mächtig. Ohne Disziplin deployt, ist es ein schneller Weg, Fehler zu automatisieren.

Kernprinzipien

Eine Agentin ist ein Modell plus eine Schleife, Werkzeuge, Gedächtnis, und ein Ziel. Das Risiko lebt in der Schleife, nicht der Prosa.
Begrenzen Sie Autonomie auf die Aufgabe. Geben Sie die kleinste Menge Freiheit, die die Arbeit erledigt.
Bevorzugen Sie einen festen Arbeitsablauf, wenn die Schritte bekannt sind. Greifen Sie zu offener Autonomie nur, wenn sie es nicht sind.
Behandeln Sie jedes Werkzeug als Angriffsfläche und gewähren Sie ihm das geringste Privileg, mit dem es arbeiten kann.
Setzen Sie eine Person im Loop für folgenreiche oder irreversible Aktionen, und machen Sie Umkehr günstig.
Evaluieren Sie nach Aufgabenerfolg, nicht danach, wie das Transkript klingt.
Verfolgen Sie jeden Lauf. Eine Aktion, die Sie nicht rekonstruieren können, ist eine Aktion, die Sie nicht verwalten können.
Das einfachste Design, das funktioniert, ist üblicherweise das richtige. Oft ist das überhaupt keine Agentin.

Empfehlungen

Mit einem Arbeitsablauf beginnen, Autonomie nur hinzufügen, wo Sie müssen

Der häufigste Fehler ist, zu einer autonomen Agentin zu greifen, wenn eine feste Pipeline reichen würde. Wenn Sie bereits die Schritte kennen (Felder extrahieren, sie validieren, eine Aufzeichnung nachschlagen, eine Antwort entwerfen), schreiben Sie das als orchestrierten Arbeitsablauf, wobei das Modell spezifische Slots füllt. Autonomie verdient sich ihre Existenzberechtigung, wenn der Pfad wirklich nicht vorherbestimmt werden kann, zum Beispiel offene Forschung oder Triage über viele mögliche Werkzeuge. Begrenzen Sie die Autonomie auf die Aufgabe: deckeln Sie die Anzahl der Schritte, beschränken Sie die Werkzeugmenge auf das, was dieses Ziel braucht, und setzen Sie eine klare Stoppbedingung. Eine gute Regel ist, dem Modell genau so viel Freiheit zu geben, wie das Problem fordert, und keinen Grad mehr.

Werkzeugnutzung zur Kernfähigkeit machen, und sie sicher machen

Werkzeugnutzung (auch Function Calling genannt) ist, was ein Modell in eine Agentin verwandelt. Definieren Sie jedes Werkzeug mit einem präzisen Schema, validieren Sie jedes Argument, das das Modell liefert, und wenden Sie das Prinzip des geringsten Privilegs an: eine Nur-Lesen-Berichts-Agentin bekommt Nur-Lesen-Zugangsdaten, nie Schreibzugang, den sie missbrauchen könnte. Führen Sie Werkzeuge innerhalb einer Sandbox aus, damit ein schlechter Aufruf nicht über seinen Explosionsradius hinausreichen kann. Bevorzugen Sie viele enge, einzweckige Werkzeuge über ein paar breite, denn ein enges Werkzeug ist leichter zu begründen, mit Berechtigungen zu versehen, und zu prüfen. Das ist dieselbe Zurückhaltung, die Kapitel 6.3 für LLM-Werkzeugnutzung fordert, zentral gemacht.

Explizite Argumentations- und Planungsmuster nutzen

Agentinnen funktionieren besser, wenn ihr Denken strukturiert ist. In einem Argumentieren-und-Handeln-Muster (populär gemacht durch die ReAct-Forschung) wechselt das Modell zwischen Argumentieren über die Situation und Ergreifen einer Aktion, beobachtet dann das Ergebnis, bevor es erneut argumentiert. Für schwerere Ziele lassen Sie das Modell zuerst planen (in Teilaufgaben zerlegen) und dann ausführen, damit Sie den Plan inspizieren und sogar genehmigen können, bevor irgendein Werkzeug läuft. Halten Sie diese Schleifen beobachtbar und unterbrechbar. Ein Plan, den Sie lesen können, ist ein Plan, den Sie stoppen können.

Menschen im Loop für folgenreiche Aktionen behalten

Entscheiden Sie, pro Werkzeug und pro Aktion, ob das Modell allein handeln darf oder zuerst fragen muss. Reversible, niedrig-einsatzige Aktionen (suchen, entwerfen) können unbeaufsichtigt laufen. Folgenreiche oder irreversible (externe Kommunikationen senden, Geld bewegen, Produktionsdaten ändern, den Fall einer Bürgerin entscheiden) brauchen ein Mensch-im-Loop-Tor mit echter Autorität, Nein zu sagen. Gestalten Sie wo möglich für Reversibilität: bevorzugen Sie, eine Änderung zu staging, statt sie zu committen, und machen Sie Rückgängig zu einem erstklassigen Feature, damit eine fehlerhafte Aktion Minuten kostet, keinen Vorfall.

Das Sicherheitsmodell als gegnerisch behandeln

Agentinnen erweitern die in Kapitel 4.2 beschriebene Angriffsfläche. Die Schlagzeilenbedrohung ist Prompt-Injektion: böswillige Anweisungen, versteckt in einer Webseite, einem Dokument, oder einer E-Mail, die die Agentin liest und befolgt. Eng verwandt ist das Confused-Deputy-Problem, wo eine Angreiferin eine privilegierte Agentin dazu bringt, ihren eigenen legitimen Zugang zu missbrauchen, zum Beispiel Daten durch ein Werkzeug zu exfiltrieren, das die Agentin aufrufen darf. Nehmen Sie an, dass jeder Inhalt, den die Agentin aufnimmt, feindlich sein könnte. Trennen Sie vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Daten, schränken Sie Werkzeuge ein, damit eine gekaperte Agentin sensible Systeme nicht erreichen kann, und lassen Sie rohe Modellausgabe nie eine irreversible Aktion auslösen ohne Validierung.

Auf Aufgabenerfolg evaluieren und die Nicht-Determinismus regressionstesten

Beurteilen Sie Agentinnen danach, ob sie die Aufgabe erledigen, nicht danach, ob das Transkript intelligent klingt. Bauen Sie eine Evaluationsmenge repräsentativer Ziele mit prüfbaren Erfolgskriterien (bekam das Ticket die richtige Priorität, entsprach die Rückerstattung der Richtlinie) und führen Sie sie bei jeder Prompt-, Modell-, oder Werkzeugänderung durch. Weil Agentinnen nicht-deterministisch sind, beweist ein einzelner Durchlauf wenig: führen Sie jeden Fall mehrfach durch und verfolgen Sie eine Erfolgsrate, nicht ein Bestehen oder Scheitern. Das erweitert die Offline- und Online-Evaluationsdisziplin aus den Kapiteln 6.3 und 6.2 (Machine-Learning-Engineering und MLOps) auf Systeme, deren Ausgabe eine Sequenz von Aktionen ist.

Läufe für Beobachtbarkeit, Kosten, und Fehlerhandhabung instrumentieren

Sie können nicht verwalten, was Sie nicht sehen können. Verfolgen Sie jeden Agentinnenlauf Ende-zu-Ende (Kapitel 6.6): das Ziel, jeden Argumentationsschritt, jeden Werkzeugaufruf mit seinen Argumenten und Ergebnis, die verbrauchten Tokens, und das finale Ergebnis. Diese Verfolgung ist Ihre Debuggerin, Ihre Prüfspur, und Ihr Kostenzähler zugleich. Setzen Sie harte Budgets auf Schritte, Zeit, und Ausgaben, denn eine Agentin, die schleift, kann Latenz und Geld schnell verbrennen. Handhaben Sie Fehler explizit: wiederholen Sie transiente Werkzeugfehler mit Backoff, erkennen Sie aber Schleifen, in denen das Modell eine scheiternde Aktion wiederholt, und scheitern Sie sicher statt zu thrashen.

Abwägungen: Vor- und Nachteile

Wahl	Vorteile	Nachteile	Am besten wenn
Fester Arbeitsablauf (Modell füllt Slots)	Vorhersagbar, günstig, leicht zu testen und zu prüfen	Starr; bricht bei unvorhergesehenen Pfaden	Schritte sind vorab bekannt
Autonome Einzelagentin	Flexibel; handhabt offene Ziele	Schwerer zu kontrollieren, evaluieren, und begrenzen	Der Pfad kann nicht vorherbestimmt werden
Multi-Agentinnen-Orchestrierung	Parallelismus; spezialisierte Rollen	Koordinationskosten, sich verdichtende Fehler, höhere Ausgaben	Eine Aufgabe zerlegt sich wirklich in unabhängige Teile
Unbeaufsichtigte Aktion	Schnell, wenig Reibung	Fehler werden ohne Prüfung ausgeführt	Aktionen sind reversibel und niedrig-einsatzig
Mensch-im-Loop-Tor	Sicherheit, Rechenschaftspflicht, Reversibilität	Langsamer; braucht Prüferinnenkapazität	Aktionen sind folgenreich oder irreversibel

Die zentrale Spannung ist Autonomie gegen Kontrolle. Mehr Autonomie handhabt mehr Situationen, fordert aber mehr Leitplanken, mehr Evaluation, und mehr Geld, und sie scheitert auf Weisen, die schwerer vorherzusagen sind. Multi-Agentinnen-Designs verlocken Teams mit Eleganz, doch jede zusätzliche Agentin fügt Koordinationsoverhead und eine weitere Stelle hinzu, wo sich ein kleiner Fehler zu einem falschen Ergebnis verdichtet. Lösen Sie die Spannung, indem Sie mit der geringsten Autonomie beginnen, die das Problem löst, und Freiheit nur hinzufügen, wenn eine konkrete Aufgabe Sie dazu zwingt, immer gepaart mit einer passenden Leitplanke.

Fragen zur Diskussion mit Ihrem Team

Braucht dieses Feature tatsächlich eine Agentin, oder wäre ein fester Arbeitsablauf sicherer und günstiger? Autonomie ist verführerisch, aber die meisten Jobs haben wissbare Schritte, die eine orchestrierte Pipeline mit weit weniger Risiko handhabt. Für ein großes Team bedeutet standardmäßig Agentinnen, dass jede Gruppe Evaluations-, Verfolgungs-, und Sicherheitslasten übernimmt, die ein einfacheres Design vermeiden würde. Bringen Sie die spezifische Aufgabe und fragen Sie, ob ihre Schritte vorherbestimmt werden können; wenn ja, ist eine Agentin wahrscheinlich Überkonstruktion. Reservieren Sie offene Autonomie für Ziele, wo der Pfad wirklich pro Fall variiert. Die Antwort sollte die meisten Features zu einem Arbeitsablauf drängen und eine kleine, absichtliche Menge als echte Agentinnen belassen.
Für jedes Werkzeug, das unsere Agentin aufrufen kann, was ist das Schlimmste, das eine gekaperte Agentin damit tun könnte, und was verhindert das? Prompt-Injektion und Confused-Deputy-Angriffe wenden den eigenen legitimen Zugang der Agentin gegen Sie, die richtige Linse ist also gegnerisch (Kapitel 4.2). Inventarisieren Sie jedes Werkzeug, seinen Privilegienumfang, und ob eine böswillige Anweisung, durch aufgenommenen Inhalt geschmuggelt, es erreichen könnte. Für Unternehmen, die Agentinnen in interne Systeme verdrahten, wird hier geringstes Privileg, Sandboxing, und menschliche Tore auf irreversiblen Aktionen echt. Bringen Sie die Liste der Werkzeuge und die Zugangsdaten, die jedes hält. Wenn irgendeine folgenreiche Aktion ohne Validierung oder menschliche Prüfung erreichbar ist, ist das das Erste, zu beheben.
Wie würden wir wissen, dass die Erfolgsrate einer Agentin gefallen ist, gegeben, dass jeder Lauf plausibel aussieht? Agentinnen sind nicht-deterministisch, ein Transkript, das gut liest, könnte also trotzdem die falsche Aktion ergriffen haben, und ein grüner Lauf beweist nichts. Fragen Sie, ob Sie eine Evaluationsmenge von Zielen mit prüfbaren Ergebnissen haben, mehrfach pro Fall durchgeführt, um eine Erfolgsrate statt eines einzelnen Durchlaufs zu produzieren. Für hocheinsatzige oder öffentliche Deployments diskutieren Sie, wie Lauf-Verfolgungen Ihnen erlauben, genau zu rekonstruieren, was geschah, wenn etwas schiefgeht (Kapitel 6.5 und 6.6). Wenn Ihr einziges Signal Nutzerinnenbeschwerden sind, sind Sie bereits zu spät. Die Antwort sollte einen Evaluations-Harness vor dem Maßstab finanzieren, nicht nach einem Vorfall.
Welche Aktionen dieser Agentin sind wirklich irreversibel, wer hat die Autorität, sie zu genehmigen, und haben wir die Prüferinnenkapazität, dieses Tor zu besetzen? Die Versuchung ist, das Modell überall unbeaufsichtigt handeln zu lassen, aber ein menschliches Tor ist nur echt, wenn eine benannte Person mit der Autorität, Nein zu sagen, verfügbar ist, wenn die Agentin fragt. Für ein großes Team wird eine Genehmigungswarteschlange, die niemand besitzt, still zu einem Gummistempel, und die Sicherheit, die Sie entwarfen, verdunstet unter Volumen. Bringen Sie die vollständige Liste der Aktionen, die die Agentin ergreifen kann, markieren Sie jede reversibel oder irreversibel, und schätzen Sie das tägliche Volumen niedrig-vertrauenswürdiger Fälle, die bei einer Prüferin landen würden. Wägen Sie die Reibung und Personalkosten eines Tors gegen den Explosionsradius eines unbeaufsichtigten Fehlers ab, und bevorzugen Sie, eine irreversible Aktion in eine gestagte, rückgängig machbare umzugestalten, über eine weitere Prüferin hinzuzufügen. In Unternehmens- und Behördenumgebungen binden Sie jede folgenreiche Aktion an eine rechenschaftspflichtige Beamtin und eine Änderungsmanagement-Aufzeichnung, denn eine autonome Aktion, die eine Bürgerin oder Kundin betrifft und die kein Mensch genehmigte, ist genau der Fehlschlag, den eine Prüfung finden wird.
Greifen wir zu einem Multi-Agentinnen-Design, weil sich die Aufgabe wirklich zerlegt, oder weil es elegant aussieht? Arbeit über spezialisierte Agentinnen aufzuteilen ist verführerisch, doch jede zusätzliche Agentin fügt Koordinationsoverhead und eine weitere Stelle hinzu, wo sich ein kleiner Fehler zu einem falschen Ergebnis verdichtet. Für eine große Organisation sind die Kosten nicht nur Ausgaben und Latenz: ein Multi-Agentinnen-System ist weit schwerer zu verfolgen, zu evaluieren, und zu begründen, wenn es scheitert, die Governance-Last vervielfacht sich also mit jeder Rolle, die Sie hinzufügen. Bringen Sie die Aufgabe und zeigen Sie konkret, welche Teile unabhängig und parallel laufen, vergleichen Sie dann die gemessene Erfolgsrate und Kosten einer Multi-Agentinnen-Version gegen eine einzelne Agentin auf derselben Evaluationsmenge. Wenn die Einzelagentin gewinnt oder gleichzieht, ist das elegante Design Überkonstruktion. Für regulierte oder öffentliche Deployments erinnern Sie sich, dass jede Agentin in der Kette eine weitere Komponente ist, die eine Aufsichtsstelle inspizieren können muss, zusätzliche Struktur, die Sie nicht rechtfertigen können, ist also zusätzliche Haftung.
Was sind die harten Budgets auf die Schritte, Zeit, und Ausgaben einer Agentin, und wie würde eine schleifende Agentin erwischt, bevor sie Kosten oder Latenz hochtreibt? Eine Agentin, die eine scheiternde Aktion wiederholt, kann Geld und Zeit ohne Warnung verbrennen, unbegrenzte Autonomie ist also ebenso sehr ein finanzielles Risiko wie ein Sicherheitsrisiko. Für ein großes Team, das viele Agentinnen betreibt, kann eine einzelne fehlverhaltende Schleife eine Cloud-Rechnung in die Höhe treiben oder ein Rate-Limit erschöpfen, das jede andere Workload verhungern lässt, was Pro-Lauf-Grenzen zu einem geteilten Betriebsanliegen macht statt dem Problem eines Teams. Bringen Sie die aktuellen Schritt-, Zeit-, und Token-Budgets für jede Agentin, die Alarmierung, die feuert, wenn ein Lauf sie überschreitet, und die Schleifenerkennung, die sicher scheitert statt zu thrashen. Wägen Sie enge Budgets, die eine legitim schwere Aufgabe abschneiden könnten, gegen lockere ab, die Kosten davonlaufen lassen. In Unternehmens- und Behördenumgebungen, wo Ausgaben vorhergesagt und gerechtfertigt werden müssen, ist eine Agentin, deren Kosten unbegrenzt sind, ein Postenpunkt, den Sie in einer Budgetüberprüfung oder Prüfung nicht verteidigen können.

Branchenperspektive

Startup. Liefern Sie eine enge Agentin aus, die Ihren Kernwert berührt, auf einem gehosteten Modell, mit der kleinsten Werkzeugmenge, die die Arbeit erledigt, und einer harten Deckelung auf Schritte und Ausgaben. Widerstehen Sie der Multi-Agentinnen-Demo: Ihre knappe Engineering-Aufmerksamkeit ist besser darauf verwendet, die Autonomie einer einzelnen Agentin zu begrenzen und ihre Läufe zu verfolgen, als Rollen zu koordinieren, die Sie nicht pflegen können. Halten Sie jede folgenreiche Aktion hinter einem einzelnen “Entwurf, nie senden”-Tor, damit ein Fehler einen Klick zum Rückgängigmachen kostet, keinen Vorfall.

Kleinunternehmen. Sie haben niemanden, um einen Evaluations-Harness oder eine Sandbox zu betreiben, bevorzugen Sie also Agentinnen, eingebettet in bereits vertraute Werkzeuge, und schalten Sie nur die Autonomie ein, die Sie mit dem Auge beaufsichtigen können. Behandeln Sie jede Agentin, die in Ihrem Namen senden, bezahlen, oder löschen kann, als etwas, das ausgeschaltet bleibt, bis eine Person jede Aktion bestätigt, denn eine falsche automatisierte Nachricht an eine Kundin kostet Sie die Beziehung. Bevorzugen Sie Anbieterinnen, die Ihnen zeigen, was die Agentin tat, und Ihnen erlauben, die Automatisierung abzuschalten.

Großunternehmen. Das Problem ist, Agentinnen über viele Teams zu verwalten: geteilte Muster, Autonomie zu begrenzen, geringste-Privileg-Werkzeugzugangsdaten, Sandboxing, Mensch-im-Loop-Tore, und Ende-zu-Ende-Verfolgung, damit keine Gruppe die Leitplanken neu erfindet. Verdrahten Sie Agentinnen in interne Systeme unter denselben Zugriffskontrollen, die eine Person halten würde, torwächten Sie irreversible Aktionen hinter benannten Genehmigerinnen und Änderungsmanagement, und verwalten Sie das Portfolio mit Erfolgsraten-Kennzahlen, Pro-Lauf-Budgets, und gegnerischem Injektionstesten. Standardisieren Sie die Verfolgungs- und Evaluationsschicht, damit das Verhalten jeder Agentin rekonstruiert und geprüft werden kann.

Behörde. Beschaffung, Transparenz, und öffentliche Rechenschaftspflicht begrenzen jede Wahl. Halten Sie Agentinnen aufs Sammeln von Fakten und Entwerfen, und reservieren Sie jede Entscheidung, die eine Bürgerin betrifft, für eine rechenschaftspflichtige Person, denn Verantwortung für eine Entscheidung des öffentlichen Sektors kann nicht an ein Modell delegiert werden. Protokollieren Sie jeden Lauf, damit eine Aufsichtsstelle sehen kann, welche Quellen konsultiert wurden und was getan wurde, fordern Sie, dass Anbieterinnen die Werkzeuge und Einschränkungen der Agentin offenlegen, und beweisen Sie durch eine gegnerische Evaluationsmenge, dass die Agentin sich weigert, über ihr begrenztes Mandat hinaus zu handeln.

Beispiele

Startup. Ein fünfköpfiges Analytics-Startup baut eine Support-Triage-Agentin. Sie liest ein eingehendes Ticket, durchsucht die Dokumentation, und entwirft entweder eine Antwort oder routet das Ticket an eine Person, und das ist die gesamte Werkzeugmenge. Die Zugangsdaten sind Nur-Lesen plus eine einzelne “Entwurf erstellen”-Aktion, die nie sendet, ohne dass eine Person auf Senden klickt. Jeder Lauf wird verfolgt, damit die Gründerinnen sehen können, warum ein Ticket dorthin geroutet wurde, wo es geroutet wurde, und eine nächtliche Evaluationsmenge von fünfzig echten Tickets führt die Agentin jeweils fünfmal durch, um eine Routing-Genauigkeitsrate zu verfolgen. Wenn die clevere Multi-Agentinnen-Demo einer Konkurrentin sie verlockt, bleiben sie bei einer Einzelagentin, weil sich ihre Aufgabe nicht zerlegt.

Großunternehmen. Eine Bank baut eine Agentin, die Betriebspersonal hilft, gescheiterte Zahlungen abzustimmen. Sie integriert sich mit internen Systemen unter denselben Zugriffskontrollen, die eine menschliche Sachbearbeiterin hat, gewährt durch geringste-Privileg-Servicezugangsdaten, auf Abstimmung allein abgegrenzt. Die Agentin darf frei ermitteln (Kontobücher lesen, Transaktionsgeschichte durchsuchen), aber jede Aktion, die Geld bewegt oder eine Aufzeichnung bearbeitet, wird gestagt und fordert eine benannte menschliche Genehmigerin, Änderungsmanagement erfüllend. Aufgenommene Dokumente werden als nicht vertrauenswürdig behandelt, um Prompt-Injektion abzustumpfen, Werkzeuge laufen in Sandboxes, und jeder Lauf wird für Prüfung Ende-zu-Ende verfolgt. Eine Offline-Evaluationsmenge torwächtet jede Modell- oder Prompt-Änderung, und Pro-Lauf-Budgets deckeln Schritte und Ausgaben, damit eine schleifende Agentin Kosten oder Latenz nicht hochtreiben kann.

Behörde. Eine Leistungsbehörde pilotiert eine Agentin, um Fallbearbeiterinnen beim Zusammenstellen der Fakten für einen Anspruch zu helfen: Aufzeichnungen ziehen, Berechtigungsregeln prüfen, und eine Zusammenfassung entwerfen. Die Behörde zieht eine harte Linie: die Agentin sammelt und entwirft, aber eine menschliche Fallbearbeiterin trifft und besitzt jede Entscheidung, die eine Bürgerin betrifft, denn Rechenschaftspflicht für Entscheidungen des öffentlichen Sektors kann nicht an ein Modell delegiert werden (Kapitel 6.5). Jeder Lauf wird vollständig protokolliert, zeigend, welche Quellen konsultiert wurden und was entworfen wurde, damit eine Aufsichtsstelle jeden Fall prüfen kann. Autonomie ist absichtlich auf Lesen-und-Entwerfen begrenzt, Werkzeuge sind geringste-Privileg und in Sandboxes, und eine gegnerische Evaluationsmenge bestätigt, dass sich die Agentin weigert, über das Sammeln von Fakten hinaus zu handeln.

Geschäftsnutzen: Motivation, ROI und Gesamtbetriebskosten

Agentinnen liefern Rendite, indem sie Mehrschritt-Arbeit automatisieren, die früher eine Person brauchte, um zwischen Systemen zu klicken: Triage, Abstimmung, Forschung, und Routine-Operationen. Der Wert zeigt sich als Arbeit, abgeschlossen ohne eine Person bei jedem Schritt, schnellere Zykluszeiten, und Personal, freigesetzt für urteilsintensive Aufgaben. Weil Agentinnen auf existierenden LLMs und Werkzeugen aufbauen, ist die Zeit bis zu einem funktionierenden Prototyp kurz, was genau ist, warum Teams überbauen.

Die Gesamtbetriebskosten sind, wo sich Agentinnen von schlichten LLM-Features unterscheiden. Über Inferenzkosten hinaus bezahlen Sie für die Werkzeugintegrationen, die Sandboxing- und Berechtigungssanitärinstallation, den Evaluations-Harness, den Verfolgungs- und Beobachtbarkeits-Stack (Kapitel 6.6), und die menschlichen Prüferinnen, die die Genehmigungstore besetzen. Eine schleifende oder schlecht begrenzte Agentin fügt eine variable Kostenposition hinzu, die ohne Warnung spiken kann, Budgets auf Schritte und Ausgaben sind also Teil des Designs, kein Nachgedanke. Die Kosten der Nicht-Übernahme sind langsamerer Betrieb und manuelle Plackerei, die Ihre Konkurrentinnen automatisieren. Die Kosten sorgloser Übernahme sind eine autonome Aktion, die die falsche Nachricht sendet, Daten leckt, oder eine nicht rechenschaftspflichtige Entscheidung trifft. Machen Sie den Fall gegenüber der Führung, indem Sie ein konkretes Automatisierungsziel mit einem konkreten Plan für Leitplanken, Evaluation, und menschliche Aufsicht paaren, und indem Sie ehrlich sind, dass die Leitplanken den größten Teil der Kosten ausmachen.

Anti-Muster und Fallstricke

Agentin, wo ein Arbeitsablauf reichen würde. Das volle Risiko von Autonomie für eine Aufgabe übernehmen, deren Schritte wissbar waren.
Übermäßig breite Werkzeuge und Zugangsdaten. Ein “alles tun”-Werkzeug statt enger, geringste-Privileg-Werkzeuge.
Prompt-Injektions-Blindheit. Nicht vertrauenswürdigen Inhalt an eine Agentin füttern, die echte Privilegien hält.
Kein menschliches Tor auf irreversiblen Aktionen. Das Modell senden, bezahlen, oder löschen lassen ohne Prüfung.
Multi-Agentinnen-Theater. Eine einfache Aufgabe über Agentinnen aufteilen, Koordinationskosten ohne Gewinn zahlend.
Gefühlsbasierte Evaluation. Nach dem Klang des Transkripts urteilen statt Aufgabenerfolgsrate.
Unbegrenzte Schleifen. Keine Deckelung auf Schritte, Zeit, oder Ausgaben, sodass eine feststeckende Agentin Geld und Latenz verbrennt.
Unverfolgte Läufe. Keine Aufzeichnung, was die Agentin tat, Sie unfähig lassend zu debuggen, zu prüfen, oder Rechenschaft abzulegen.

Reifegradmodell

Stufe 1, Beginnen: Agentinnen werden ad hoc prototypt mit breitem Werkzeugzugang und keinen Grenzen. Erfolg wird durch Demos beurteilt, reaktiv, nachdem etwas bricht. Es gibt keine Evaluationsmenge, keine Verfolgung, und kein menschliches Tor auf folgenreichen Aktionen.
Stufe 2, Entwickeln: Manche Agentinnen haben begrenzte Schleifen und geringste-Privileg-Werkzeuge, und grundlegende Verfolgung existiert, aber Praxis variiert von Team zu Team. Eine manuelle Evaluationsmenge erwischt grobe Regressionen in ein paar Projekten, während andere keine haben. Menschliche Genehmigung bewacht die offensichtlichsten irreversiblen Aktionen, doch Abdeckung ist ungleich und undokumentiert.
Stufe 3, Standardisieren: Geteilte Muster verwalten Autonomie, Werkzeugberechtigungen, Sandboxing, und Mensch-im-Loop-Tore, dokumentiert und über jedes Team durchgesetzt. Jede folgenreiche Aktion ist torwächtet oder validiert, Agentinnen werden Ende-zu-Ende verfolgt, und eine automatisierte Evaluationsmenge mit Erfolgsraten-Bewertung läuft bei jeder Änderung. Prompt-Injektion wird als stehende Bedrohung mit definierter Reaktion behandelt.
Stufe 4, Steuern: Das Agentinnen-Portfolio wird gegen Baselines gemessen und gesteuert. Erfolgsrate pro Aufgabe, Prompt-Injektions-Verteidigungs-Bestehensrate, Kosten und Schrittzahl pro Lauf, menschliche-Genehmigung-Latenz, und Schleifen- oder Fehlschlag-Vorfälle werden als Kennzahlen verfolgt; Rollback- und Tötungsschwellen werden auf diesem Beleg durchgesetzt statt auf Beschwerden. Pro-Lauf-Budgets auf Schritte, Zeit, und Ausgaben werden überwacht, und eine Regression in irgendeiner Kennzahl löst Aktion vor dem Maßstab aus, nicht nach einem Vorfall.
Stufe 5, Orchestrieren: Autonomie wird per Richtlinie an Aufgabenrisiko angepasst und kontinuierlich justiert, während Ergebnisse eintreffen. Laufende Offline- und Online-Evaluation bindet Agentinnenverhalten an Geschäftsergebnisse, und die Organisation mustert Agentinnen routinemäßig aus, rahmt sie neu ab, oder ändert ihre Berechtigungen, während sich das Risikobild verschiebt. Verfolgung, Kostenbudgets, und Prüfspuren sind über das Portfolio hinweg uniform; Injektions- und Confused-Deputy-Verteidigungen werden gegnerisch getestet; Rechenschaftspflicht für autonome Aktionen ist klar und prüfbar.

Diskussionsideen

Welche Ihrer aktuellen LLM-Features sind still zu Agentinnen geworden, und wurde die Autonomie jeder absichtlich begrenzt?
Für jedes Agentinnenwerkzeug, was ist der günstigste Weg, wie eine Angreiferin es durch injizierten Inhalt missbrauchen könnte, und was verhindert das?
Wo haben Sie Multi-Agentinnen-Designs gewählt, und können Sie zeigen, dass sich die Koordinationskosten gegenüber einer einzelnen Agentin auszahlten?
Welche Agentinnenaktionen sind wirklich irreversibel, und könnte jede davon so umgestaltet werden, dass sie reversibel oder gestagt ist?
Wenn eine Agentin morgen eine schädliche Aktion ergriffe, könnten Sie genau rekonstruieren, was sie tat und wer rechenschaftspflichtig war?

Wichtigste Erkenntnisse

Eine Agentin ist ein LLM in einer Schleife mit Werkzeugen, Gedächtnis, und einem Ziel. Das Risiko lebt in der Schleife und den Werkzeugen, nicht im Text.
Bevorzugen Sie einen festen Arbeitsablauf, wenn die Schritte bekannt sind; reservieren Sie Autonomie für wirklich offene Ziele und begrenzen Sie sie eng.
Werkzeugnutzung ist die Kernfähigkeit. Geben Sie jedem Werkzeug geringstes Privileg, ein validiertes Schema, und eine Sandbox.
Torwächten Sie folgenreiche und irreversible Aktionen hinter einer Person mit echter Autorität, und gestalten Sie für günstige Umkehr.
Behandeln Sie Agentinnen als gegnerisch: verteidigen Sie sich gegen Prompt-Injektion und Confused-Deputy-Missbrauch (Kapitel 4.2).
Evaluieren Sie nach Aufgabenerfolgsrate über viele Läufe, und verfolgen Sie jeden Lauf für Debugging, Kostenkontrolle, und Prüfung (Kapitel 6.5 und 6.6).
Oft ist die richtige Antwort, überhaupt keine Agentin zu bauen.

Referenzen und weiterführende Literatur

Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models
Timo Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools
Anthropic, Building Effective Agents (Engineering-Leitlinien zu Arbeitsabläufen versus Agentinnen)
OWASP Foundation, OWASP Top 10 for Large Language Model Applications (einschließlich Prompt-Injektion und übermäßiger Handlungsfähigkeit)
Simon Willison, Schriften über Prompt-Injektion und die “tödliche Trifecta” für KI-Agentinnen
Norman Hardy, The Confused Deputy (die klassische Formulierung des Confused-Deputy-Problems)
Chip Huyen, AI Engineering: Building Applications with Foundation Models
Stuart Russell und Peter Norvig, Artificial Intelligence: A Modern Approach (intelligente Agentinnen und rationales Handeln)