Das Prompt als Regelwerk - Anleitung für LLM-Agenten jenseits grundlegender Anweisungen

Auf unserer Reise zur Integration von Large Language Models (LLMs) mit herkömmlichen APIs haben wir gesehen, wie Prompts zu den neuen "API-Dokumenten" werden, die beschreiben, was ein Tool kann. Auf den ersten Blick klingt das alles wunderbar einfach. Sie geben dem LLM Zugang zu einigen Tools, beschreiben sie, und voilà, Sie haben einen intelligenten Agenten! Aber wie viele von uns entdecken, gibt es einen entscheidenden Unterschied zwischen einem LLM, der ein Werkzeug benutzen kann, und einem LLM, der ein Werkzeug klug oder effektiv in einem breiteren Kontext benutzt. Dies spricht direkt die Herausforderungen an, die wir bei unserem einfachen Kalenderassistenten gesehen haben.

Hier treffen wir oft auf das, was ich das Syndrom des "begeisterten Praktikanten" nenne. Ähnlich wie ein eifriger, aber unerfahrener Praktikant befolgt Ihr LLM-Agent fleißig die ausdrücklichen Anweisungen für seine Werkzeuge. Ihm fehlt jedoch möglicherweise das erfahrene Urteilsvermögen eines erfahrenen Mitarbeiters, der intuitiv unausgesprochene Regeln, subtile menschliche Faktoren oder das "beste Gesamtergebnis" berücksichtigt. Derzeitige LLMs sind außerordentlich gut darin, den ihnen vorgegebenen Text zu verstehen und auszuführen, aber sie erfassen nicht von Natur aus den unausgesprochenen Kontext oder das nuancierte "Warum" hinter einer Aufgabe, das oft über den wahren Erfolg entscheidet.

Das bedeutet, dass sich unsere Rolle als Entwickler weiterentwickelt. Wir beschreiben nicht mehr nur die Funktionen des Tools, sondern erstellen in unseren Prompts akribische Regelwerke, die den LLM durch komplexe Entscheidungsprozesse führen.

Fallstudie: Der "rücksichtsvolle" Kalenderassistent

Lassen Sie uns noch einmal unser "Kalender-Assistent" Werkzeug aus Teil 2 betrachten. Stellen Sie sich vor, unser Haupt-LLM-Agent hat Zugriff auf die beiden primären Funktionen, die wir definiert haben:

1. CreateMeeting(attendees, subject, startTime, duration, location): Terminiert eine Besprechung.
2. FindFreeTime(attendees, duration, timeWindow): Findet freie Steckplätze.

Unsere anfänglichen Eingabeaufforderungen für diese Tools dienen der grundlegenden Interpretation und sind so konfiguriert, dass die Standardarbeitszeiten des Unternehmens eingehalten werden, z. B. Montag bis Freitag, 8.00 bis 18.00 Uhr Ortszeit für jeden Mitarbeiter.

Nun stellt ein Benutzer, der Teamleiter in London ist, folgende Anfrage: "Wir müssen Anfang nächster Woche eine kritische 1-stündige Strategiesitzung für Projekt Atlas abhalten. Teilnehmer werden ich selbst, Maria (ebenfalls in London) und Ben (in Edinburgh) sein. Dies erfordert von allen Teilnehmern eine gute Vorbereitung. Bitte vereinbaren Sie einen Termin in unserem Londoner Hauptquartier."

Der Agent "begeisterter Praktikant" macht sich an die Arbeit. Er fragt mit FindFreeTime die Kalender ab und stellt fest, dass Montag um 8:30 Uhr GMT für alle innerhalb der definierten Standardarbeitszeiten technisch "frei" ist.

• Er fährt fort, anzurufen: CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

Technisch gesehen ist ein Treffen geplant. Aber ist es ein gutes Ergebnis? Bedenken Sie die Auswirkungen:

1. Reiseerwägungen werden ignoriert: Für Ben, der in Edinburgh lebt, ist ein persönliches Treffen um 8:30 Uhr in London höchst problematisch. Dazu müsste er am Montagmorgen extrem früh anreisen oder, was wahrscheinlicher ist, am Sonntagabend anreisen. Da der Vermittler nur die "verfügbaren Arbeitszeiten von 8 bis 18 Uhr" im Kalender berücksichtigte, ließ er die logistischen Unzulänglichkeiten und die persönlichen Auswirkungen einer Besprechung am frühen Morgen, die eine längere Reise erfordert, völlig außer Acht. Er machte keinen Unterschied zwischen einem Termin um 8:30 Uhr für einen Teilnehmer vor Ort und einem Termin für einen Teilnehmer aus der Ferne, der physisch anwesend sein muss.
2. Die Vorbereitungszeit wurde übersehen: Der Nutzer hat ausdrücklich darauf hingewiesen, dass es sich um eine "kritische Strategiesitzung" handelt, die "umfangreiche Vorbereitungen" erfordert. Der Termin am Montagmorgen (8:30 Uhr) setzt die Teilnehmer unter Druck, ihre persönliche Wochenendzeit für die Vorbereitung zu nutzen, wenn sie für einen so frühen Start bereit sein wollen.

Dies ist der Moment, in dem Sie als Entwickler erkennen, dass der Agent seine Aufgabe auf der Grundlage der expliziten Kalenderverfügbarkeit ausgeführt hat, aber entscheidende implizite menschliche Faktoren und praktische Überlegungen außer Acht gelassen hat. Ihm fehlte das Urteilsvermögen, um ein wirklich effektives und rücksichtsvolles Ergebnis zu gewährleisten.

Kodierung von "Erfahrung" und "Überlegung" in Prompts

Um unseren "Praktikanten" zu einem "erfahrenen Assistenten" zu machen, müssen wir eine ausgefeiltere Logik in das Programm einbauen. Leitprompt des Hauptagenten (oder die übergreifenden Anweisungen, denen es bei der Orchestrierung von Tools folgt). Dies geht über die bloße Beschreibung der FindFreeTime oder CreateMeeting Werkzeuge selbst. Wir müssen dem Agenten sagen wie man sich rücksichtsvoller verhält.

Dabei wird der Agent oft angewiesen, ein "drittes Werkzeug" oder eine zusätzliche Informations- und Logikebene zu suchen und zu verwenden. In diesem Fall ist es Standort des Teilnehmers, Reisebedingungen und Art der Sitzung. Unser Agent muss unter Umständen implizit (oder explizit über ein anderes Tool wie GetUserProfile(email)) zugreifen oder ableiten:

• Der primäre Arbeitsort jedes Teilnehmers.
• Die Art der Besprechung (z. B. persönlich oder virtuell).
• Die Bedeutung der Wichtigkeit und des Zeitpunkts der Besprechung (z. B. "kritische Besprechung am Montagmorgen").

Mit dem Zugriff auf diese "Kontextdaten" müssen wir dann eine Liste von Anweisungen im Stil von "wenn...dann..." in die Hauptabfrage des Agenten einfügen:

Überarbeiteter Agent Prompt Logic Snippet (konzeptionell):

"...Wenn Sie mit der Planung eines Meetings beauftragt werden:

1. Erweitertes Sammeln von Kontexten: Ermitteln Sie für jeden Teilnehmer seinen wahrscheinlichen Aufenthaltsort (z. B. anhand GetUserProfile(attendee_email)). Beachten Sie, ob die Besprechung als "persönlich" angegeben ist und ob es sich um Fernteilnehmer handelt.
2. Berücksichtigen Sie die Reisekosten für persönliche Treffen:
   • Wenn das Treffen findet persönlich statt, und ein Teilnehmer ist entfernt, und ein Zeitfenster am frühen Morgen (z.B. vor 10:00 Uhr Ortszeit des Tagungsortes) wird vorgeschlagen:
     • Weisen Sie dann den Anfragenden darauf hin. Zum Beispiel: "Ben reist für dieses persönliche Treffen aus Edinburgh an. Würden Sie es vorziehen, die Besprechung um 10.30 Uhr oder später zu beginnen, damit er am Montag bequem reisen kann, oder soll ich virtuelle Optionen prüfen?
3. Berücksichtigen Sie die Vorbereitungszeit für wichtige Besprechungen:
   • Wenn eine Sitzung als "kritisch", "wichtig" oder "in erheblichem Maße vorbereitungsbedürftig" bezeichnet wird und die Sendung wird für einen frühen Termin an einem Montag (oder unmittelbar nach einem Feiertag) angesetzt:
     • Bitten Sie dann den Antragsteller um eine Bestätigung. Zum Beispiel: "Wäre für diese kritische Montagssitzung, die vorbereitet werden muss, eine Startzeit von 8.30 Uhr für alle am Montagmorgen selbst ausreichend, oder wäre ein Zeitfenster um 10.00 Uhr besser geeignet, um die Bereitschaft am Tag selbst zu ermöglichen?
4. Umgang mit allgemeinen Zeitzonen-/Arbeitszeitkonflikten (wie zuvor beschrieben):
   • (Integrieren Sie eine Logik für die Priorisierung von "sozialen Kernzeitfenstern", die Behandlung von Zeitfenstern außerhalb dieser Zeitfenster und bitten Sie gegebenenfalls um eine Bestätigung für ungünstige Zeiten in verschiedenen Zeitzonen, auch für virtuelle Treffen).
5. Explizite Benutzerüberschreibungen respektieren:
   • Wenn der Benutzer eine ungünstige Vereinbarung ausdrücklich bestätigt (z. B. "Ja, Ben weiß Bescheid und reist am Sonntag"), dann fahren Sie fort, vielleicht mit einer abschließenden Bestätigung: "Verstanden. Terminplanung wie bestätigt.'"

Aufforderungen: Von einfachen Beschreibungen bis zu komplexen Algorithmen

Wie Sie sehen können, hat sich die Eingabeaufforderung für unseren Hauptagenten erheblich weiterentwickelt. Es handelt sich nicht mehr nur um eine Liste der verfügbaren Werkzeuge. Es ist ein detaillierter, bedingter Entscheidungsbaum. Es ist ein Miniatur-Algorithmus, der in natürlicher Sprache ausgedrückt ist. Diese "wenn...dann..."-Anweisungen werden zum Rückgrat des "Denkprozesses" des Agenten und führen ihn nicht nur zu einer Lösung, sondern zu einer besseren Lösung.

Die Herausforderung - und die sich daraus ergebende Fähigkeit für Entwickler - besteht darin, diese potenziellen Fallstricke vorherzusehen und die "Erfahrung", die "Firmenpolitik" oder die "allgemeine Höflichkeit" direkt in die Anweisungen des LLM zu kodieren. Es beweist, dass LLMs zwar eine unglaubliche Macht mit sich bringen, dass aber die Arbeit eines Entwicklers, diese Macht in wirklich nützliche und rücksichtsvolle Anwendungen zu lenken, entscheidender ist denn je. Es geht darum, den "enthusiastischen Praktikanten" in einen zuverlässigen, erfahrenen digitalen Kollegen zu verwandeln, eine sorgfältig ausgearbeitete Anweisung nach der anderen.

In Zukunft sollen sich diese Agenten sogar über die detailliertesten, auf Eingabeaufforderungen basierenden Regelwerke hinaus entwickeln, indem sie in die Lage versetzt werden, aus den Ergebnissen ihrer Handlungen wirklich zu "lernen". Während wir heute Erfahrungen akribisch kodieren, geht es in Zukunft um Agenten, die ihre Strategien autonom verfeinern können. Stellen Sie sich einen Agenten vor, der nicht nur Zugang zu Werkzeugen und Daten hat, um seine Aufgabe zu erfüllen, sondern auch zu kontinuierlichem Feedback über den Erfolg oder Misserfolg dieser Aktionen bei der Erreichung der gewünschten Geschäftsergebnisse. Wenn unser Kalender-Assistent beispielsweise konsequent beobachtet, dass Besprechungseinladungen für 12:00 Uhr von einem bestimmten Benutzer mit der Begründung "Mittagspause" abgelehnt werden, könnte er im Laufe der Zeit lernen, diesen Termin für die betreffende Person zu depriorisieren oder sogar zu vermeiden, ohne dass ein Entwickler explizit eine Regel "keine Besprechungen am Mittag für Benutzer X" programmieren muss.

Nun kann man diese Lernfähigkeit auf kompliziertere Geschäftsprozesse ausdehnen. Ein Agent, der zunächst mit einer Reihe von Verfahren programmiert wurde, z. B. für die Aufnahme von Kunden oder die Logistik in der Lieferkette, könnte durch die Messung wichtiger Leistungsindikatoren und die Beobachtung realer Ergebnisse beginnen, Ineffizienzen zu erkennen oder optimalere Wege zu entdecken. Im Laufe der Zeit könnte es seinen Ansatz subtil anpassen, Schritte neu priorisieren oder sogar Änderungen an den grundlegenden Prozessen vorschlagen, die die Entwickler zunächst entworfen haben. In der Zukunft könnten die Entwickler daher nicht nur die ursprünglichen Architekten dieser Agentenverhaltensweisen sein, sondern auch die Erzeuger von Systemen, in denen die Agenten ihre eigenen operativen "Algorithmen" nach und nach verfeinern und optimieren, so dass sie wirklich zu dynamischen und lernenden Partnern bei der Erreichung der Unternehmensziele werden.

Erfahren Sie, wie Akamai Ihre KI-Workloads in großem Umfang unterstützen kann. Sprechen Sie noch heute mit unseren Experten.