Learn How to Build Real-World Agents

OpenAI hat vor kurzem diesen praktischen Leitfaden zum Erstellen von Agenten veröffentlicht, den meiner Meinung nach ein Muss für jeden Entwickler ist, da 2025 das Jahr der Agenten sein soll und es so aussieht, als hätte jedes große Labor seine eigene Sicht auf Agenten. Ende letzten Jahres hat beispielsweise Antropic diesen Leitfaden zum Erstellen effektiver Agenten veröffentlicht, der meiner Meinung nach einer der besten überhaupt ist. Auch Google hatte in diesem Whitepaper, das letztes Jahr veröffentlicht wurde, seine eigene Sicht auf Agenten. Außerdem habe ich vor kurzem einen Vortrag über das Erstellen von Key Agenten gehalten, die bei Google Next funktionieren. Ich habe ein Video basierend auf meiner Präsentation aufgenommen. Der Link befindet sich in der Videobeschreibung, falls Sie interessiert sind. Wenn Sie Agenten erstellen möchten, haben Sie eine ganze Reihe verschiedener Möglichkeiten. Es gibt zahlreiche Pakete, Bibliotheken und SDKs, die in Kürze erscheinen, darunter ein Agenten SDK von OpenAI. Es gibt ein neues Agententwicklungskit von Google. Wir kennen bereits langgraph, Crew, kleine Agenten und viele mehr. Wenn Sie jedoch darüber nachdenken, agentenbasierte Systeme zu erstellen, rate ich Ihnen immer, es einfach zu halten. Stellen Sie sich einen Agenten also als ein LLM vor, das bestimmte Funktionsaufrufe mit den verfügbaren Tools ausführen kann. Mach es nicht zu kompliziert. Ich denke, dieses Meme fängt das Wesentliche dieser dieser Landschaft im Moment wirklich gut ein. Mir persönlich gefällt diese Definition eines Agenten sehr gut. Im Kern gibt es ein Modell oder LLM, das Zugriff auf Tools hat, und es gibt eine Orchestrierungsschicht. Ein Agent ist also eine key gesteuerte Anwendung, die ein LLM verwendet, das von einer Reihe von Anweisungen geleitet wird, die ihr Verhalten formen. Sie hat auch Zugriff auf Tools, die im Grunde ihre Fähigkeiten erweitern, und das alles läuft in einer dynamischen Laufzeitumgebung, die der Agent steuert. In diesem Video werden wir uns diesen praktischen Leitfaden zum Erstellen von Agenten von OpenAI genauer ansehen. Dieser Leitfaden konzentriert sich hauptsächlich auf das Agenten SDK und tatsächlich habe ich eine sehr interessante Sichtweise auf deklarative und nicht deklarative Graphen. Ich glaube, sie verwiesen auf langgraph. Tatsächlich hat der CEO von Lang dies auf X gepostet. Ziemlich schlechter Rat von OpenAI. Es gibt 27 Bibliotheken wie Agenten, die die ursprüngliche Lang Chain in diese Kategorie einordnen, und keine von ihnen ist zuverlässig genug, um für 99 Prozent der Anwendungsfälle in Produktion zu gehen. Dieser Block erscheint dieses Wochenende. Da stimme ich Harrison Chase voll und ganz zu. Wenn Sie ein agentenbasiertes System entwickeln, ist es immer am besten, diese Frameworks für den anfänglichen Proof of Concept zu verwenden. Sobald Sie jedoch den Proof of Concept haben, ist es immer besser, eine benutzerdefinierte Lösung zu implementieren. Dabei kann es sich um eine graphenbasierte Lösung handeln oder auch nicht. Richtig. Ich freue mich aber schon sehr darauf, den Blogbeitrag am Wochenende zu lesen und wir werden wahrscheinlich ein weiteres Video erstellen. In diesem Video werden wir uns eingehend mit diesem Leitfaden befassen und auch einige meiner Gedanken dazu teilen. Zuerst versuchen wir die Frage zu beantworten, was ein Agent ist. OpenAI hat eine sehr spezifische Definition. Agenten sind Systeme, die in ihrem Auftrag selbstständig Aufgaben erledigen. Daher müssen sie über autonome Entscheidungsfähigkeiten verfügen. OpenAI definiert außerdem Workflows, die sich stark von der Definition von Entropic unterscheiden. Ein Workflow ist eine Abfolge von Schritten, die ausgeführt werden müssen, um das Ziel des Nutzers zu erreichen, unabhängig davon, ob es sich dabei um die Lösung eines Kundendienstproblems oder die Reservierung eines Restaurants und so weiter handelt. Richtig, Es handelt sich also im Grunde um eine Abfolge von Schritten, die Sie ausführen müssen, um eine Aufgabe zu erledigen. Nun benötigt nicht jede Anwendung einen Agenten. Anwendungen, die LLMs integrieren, diese aber nicht zur Steuerung der Workflow Ausführung verwenden, wie zb einfache Chatbots, Single Turn LLMs oder Sentiment Klassifikatoren, sind keine Agenten. Es ist also sehr wichtig zu verstehen, dass nicht jede LLM basierte Anwendung die Verwendung von Agenten benötigt. Es gibt wieder zwei wesentliche Erstens muss das LLM in der Lage sein, die Workflow Ausführung zu verwalten und Entscheidungen autonom zu treffen. Zweitens muss es Zugriff auf eine Reihe von Tools haben, die es ihm ermöglichen, mit externen Systemen zu interagieren, und der Agent kann dynamisch entscheiden, wann er diese Tools verwendet. Die wichtigste Frage ist, wann Sie einen Agenten erstellen sollten. Und wie ich bereits sagte, erfordert nicht jede LLM-basierte Lösung einen agentenbasierten Anwendungsfall. Sie können also viele Probleme lösen, indem sie einfach eine normale, regelbasierte Entscheidungsfindungslösung erstellen. Um herauszufinden, ob Sie für ein bestimmtes Problem eine agentenbasierte Lösung benötigen, empfiehlt OpenAI, drei verschiedene Kernanforderungen zu prüfen. Zunächst einmal muss das System komplexe Entscheidungen treffen können. Es muss also ein Bedarf an differenzierten Argumenten bestehen. Dann muss es über schwer aufrechtzuerhaltende Regeln verfügen. Mit einfachen regelbasierten Systemen lässt sich viel erreichen. Allerdings werden die Anzahl der Regeln und die Komplexität irgendwann die Grenzen dessen überschreiten, was für Menschen vertretbar ist. Bei solchen Systemen sollte man sich definitiv eher mit agentenbasierten Lösungen oder LLM basierten Entscheidungen befassen. Das dritte Kriterium, das ich für sehr wichtig halte, ist die starke Abhängigkeit von unstrukturierten Daten. Entscheidungs oder regelbasierte Entscheidungssysteme funktionieren in der Regel sehr gut mit strukturierten Daten. Wenn Sie jedoch über viele unstrukturierte Daten wie natürliche Sprache oder Informationsextraktion für Dokumente verfügen, können Sie sich möglicherweise auf ein LLM basiertes System verlassen. Dies ist jedoch ein sehr wichtiger Punkt, den Sie berücksichtigen sollten. Bevor Sie sich für die Entwicklung eines Agenten entscheiden, stellen Sie sicher, dass Ihr Anwendungsfall diese Kriterien eindeutig erfüllt. Andernfalls reicht möglicherweise eine deterministische Lösung aus. OK. Laut OpenAI gibt es 3 Hauptkomponenten eines agentenbasierten Systems. Das erste ist das Modell, bei dem es sich um das LLM handelt, das die Argumentation und Entscheidungsfindung des Agenten antreibt. Das zweite sind die Tools. Im Grunde genommen sind dies die durch Funktionsaufrufe erweiterten Funktionen. Und das letzte sind die Anweisungen, bei denen es sich um die Richtlinien und Leitplanken für Systemanweisungen handelt, die das Verhalten des Agenten steuern. In diesem Handbuch wird hauptsächlich das Agents SDK von OpenAI verwendet. Alle Beispielcodes, die Sie sehen werden, basieren also darauf. Sie können diese Konzepte jedoch problemlos auf andere SDKs ausweiten, wenn sie möchten. So implementieren Sie einen einfachen Agenten. Der Agent wird hier von einem Modell oder LLM angetrieben. Sie haben nun eine Reihe von Anweisungen, die das Verhalten steuern. Und dann haben Sie eine Reihe von Tools, mit denen Sie die Funktionen Ihres Agenten oder Modells erweitern können. Als Nächstes werden wir diese drei Komponenten im Detail besprechen. Die erste ist, wie Sie verschiedene Modelle für Ihr LLM auswählen. In den letzten Jahren habe ich immer wieder betont, dass Sie nicht für jede Anwendung das leistungsfähigste oder intelligenteste modell benötigen und OpenAI empfiehlt im Grunde genommen dasselbe. Basierend auf Ihrer Anwendung möchten Sie also die Leistung im Verhältnis zu Kosten und Latenz optimieren. Die Empfehlung lautet Wenn Sie ein Agentensystem erstellen, erstellen Sie zunächst Ihren Agenten Prototyp mit dem leistungsfähigsten Modell für jede Aufgabe, um eine Leistungsbasislinie festzulegen. Nehmen wir also an, Sie wählen für jede Aufgabe in Ihrem Agenten Workflow das bestmögliche Modell aus, beispielsweise oder Gemini 2.5 Pro. Anschließend können Sie es durch ein schwächeres Modell ersetzen und sehen, welche Auswirkungen das hat. Die erste Implementierung bietet Ihnen also die beste Leistungsbasislinie, die Sie dann versuchen können zu optimieren. Sie müssen also Entwicklungen einrichten, um eine Leistungsbasislinie festzulegen. Konzentrieren Sie sich dann darauf, Ihr Genauigkeitsziel mit dem besten verfügbaren Modell zu erreichen. Und etwas, worauf Sie sich wirklich konzentrieren müssen, sind Kosten und Latenz. Ich habe mit einer Reihe von Kunden zusammengearbeitet, die mit den intelligentesten Modellen wirklich gute Ergebnisse erzielt haben, aber das ging über Ihre Latenz und Kostenbeschränkungen hinaus. Richtig. Sie müssen also die Kosten und Latenz für eine bestimmte Leistung optimieren. Als nächstes sprechen Sie über Tools. Wenn Sie also Tools definieren, müssen Sie eine sehr detaillierte Toolbeschreibung bereitstellen, mit der das Modell oder der Agent ein Tool für eine bestimmte Aufgabe auswählen kann. OpenAI kategorisiert Tools in drei verschiedene Daten. Aktion und Orchestrierung. Daten ermöglichen es Agenten, Kontakte und Informationen abzurufen, die für die Ausführung des Workflows erforderlich sind. Es könnte sich um eine einfache RAC Pipeline oder ein RAC Tool handeln, das Daten aus Quelldokumenten, Datenbanken oder CRM empfängt oder abruft. Mit diesen Daten reichern Sie den Kontext an, den das ADEN M verwenden wird. Die zweite Gruppe von Tools sind Aktionen. Damit können Agenten mit Systemen interagieren, um Aktionen auszuführen, zb. Neue Informationen zur Datenbank hinzuzufügen, Datensätze zu aktualisieren oder Nachrichten zu senden. Richtig. Beispiele dafür wären das Senden von E Mails oder Textnachrichten, das Aktualisieren eines CRM Datensatzes, das Weiterleiten von Kundendiensttickets an einen Mitarbeiter und so weiter. Die dritte Kategorie ist die Orchestrierung. Agenten selbst können als Tools dienen. Zwei weitere Agenten. Nun wird es zwei verschiedene Muster geben. Eines ist das Manager Muster für die Orchestrierung, bei dem Sie im Grunde einen Agenten als Orchestrator verwenden können und die restlichen Tools oder der Rest des Agente zu Werkzeugen werden. Richtig. Sie können also einen Rückerstattungsagenten, einen Rechercheagenten und einen Schreibagenten haben, die vom Orchestrierungsagenten gesteuert werden. Dann gibt es noch einen weiteren dezentralen Ansatz, den sehen wir uns später im Video an. OK, so implementieren Sie verschiedene Tools mit Hilfe des Agent. SDK Tools sind im Grunde einfache Python Funktionen mit einem Dekorationsfunktionsaufruf namens Function Tool. Nun müssen Sie in der Tool Beschreibung einen DocString hinzufügen, der dem LM mitteilt, was genau dieses Tool macht. Was sind die erwarteten Ein und Ausgaben. Dann stellen Sie dem Agenten einfach diese Liste der Tools zur Verfügung, damit der Agent autonom entscheiden kann, welches Tool er verwenden möchte. Ganz wichtig ist, dass Sie die Anzahl der Tools begrenzen, auf die ein Agent Zugriff hat. Wenn Sie der Meinung sind, dass es viel zu viele Tools gibt, ist es besser, diese Tools in verschiedene Kategorien aufzuteilen und wahrscheinlich separate Agenten um diese Tools herum zu erstellen. Wir sehen uns später im Video ein Beispiel an. Die letzte Komponente sind Anweisungen oder die Systemmeldungen, die das Verhalten Ihres Modells steuern. Im Grunde genommen sagst du dem Modell, wie es Entscheidungen treffen soll, welche Dinge es berücksichtigen soll, welche Werkzeuge dem Modell zur Verfügung stehen und wie es diese Werkzeuge verwenden soll. OK, Sie empfehlen also einige bewährte Verfahren, wie du diese Anweisungen definierst. Nun sagen sie, dass man vorhandene Dokumente verwenden soll. Oft haben wir vorhandene Betriebsverfahren, Arbeitsabläufe oder richtliniendokumente. Du könntest diese also möglicherweise im Kontext deiner Anweisungen verwenden, um dem Modell mitzuteilen, welche Art von Problem es zu lösen versucht und welche verschiedenen Verfahren es verwenden muss. Eine weitere Empfehlung ist, dass die Agenten aufgefordert werden, Aufgaben aufzuteilen. Du solltest Aufgaben also in Unteraufgaben unterteilen. Die Idee ist es, den LLMs so einfach wie möglich zu machen, Entscheidungen zu treffen. Gehe nicht davon aus, dass dies intelligente Systeme sind. Es gibt definitiv eine gewisse Intelligenzkomponente. Du solltest jedoch sehr klare Anweisungen dazu geben, was der Agent tun soll. Andernfalls wird er Annahmen treffen, was zu unerwünschtem Verhalten führt. Du musst also klare Anweisungen definieren. Ein Beispiel ist, dass du den Agenten anweisen könntest, den Benutzer nach seiner Bestellnummer zu fragen oder eine API aufzurufen, um Kontodokumentdetails abzurufen. Das sind die Dinge, die Sie dem Modell explizit mitteilen müssen. Lassen Sie das Modell auch hier keine Annahmen treffen. Außerdem ist es sehr wichtig, Sonderfälle zu erfassen. Manchmal kann es vorkommen, dass der Benutzer unvollständige Informationen bereitstellt. Daher benötigen Sie Anweisungen, die dem Modell helfen, diese Sonderfälle zu beheben. Und noch Wann immer Sie diese agentenbasierten Systeme erstellen, müssen Sie alles iterativ verfeinern, einschließlich der Anweisungs und Werkzeugsätze in den Modellen. Sie benötigen also einen weiterentwickelten Datensatz, indem Sie die Fehlerfälle erfassen und dann Ihre Anweisungen und Werkzeuge auf der Grundlage der festgestellten Fehler aktualisieren. OK. Als nächstes sprechen wir über die Orchestrierungsebene. Es gibt zwei verschiedene Muster für die Erstellung von agentenbasierten Systemen. Eines sind Einzelagentensysteme, bei denen ein einzelnes Modell, das mit den entsprechenden Werkzeugen und Anweisungen ausgestattet ist, Arbeitsabläufe in einer Schleife ausführt. Das zweite sind Multiagentensysteme, bei denen mehrere Agenten verschiedene Teile der Arbeitsabläufe steuern. Und dann gibt es noch Multiagentensysteme, bei denen die Ausführung des Ablaufs auf mehrere koordinierte Agenten verteilt ist. Wir werden uns Beispiele für beides ansehen. In einem Einzelagentensystem haben Sie im Grunde einen Agenten mit einem Satz von Anweisungen, Werkzeugen, Leitplanken und Hooks. Dies ist normalerweise eine iterative Verfeinerung oder inkrementelle Verbesserung. Richtig. Sie erhalten also die Benutzereingabe. Der Agent durchläuft eine Argumentations oder Agentenschleife. Er wählt einen Satz von Werkzeugen aus, führt diese aus, erhält die Ausgabe und leitet diese Ausgaben an einen anderen Schritt oder einen anderen Satz von Werkzeugen weiter. Richtig. Diese Schleife wird solange fortgesetzt, bis der Agent entweder die Aufgabe erledigen oder seine Ausführung beenden kann. Daher hat OpenAI im Agent SDK diese Runner Run Methode implementiert, die die Ausführung beendet, wenn der Agent eine Ausgabe erzeugen kann oder eine Antwort ohne einen To Laufruf zurückgibt. Richtig. Sie richten dies ein, indem Sie dem Agenten eine Benutzernachricht bereitstellen und die gesamte Ausführung intern erfolgt. Das war nun ein Fall eines Einzelagentensystems oder eines Agentensystems. Sie möchten mit einem System mit nur einem Agenten beginnen, selbst wenn Sie davon ausgehen, dass Sie ein System mit mehreren Agenten benötigen. Irgendwann möchten Sie jedoch zu einem System mit mehreren Agenten übergehen. Es gibt nun praktische Richtlinien für die Aufteilung von Agenten in Systeme mit mehreren Agenten. Der erste Punkt sind komplexe Entscheidungen oder komplexe Logik. Wenn Eingabeaufgaben, Aufforderungen, viele bedingte Anweisungen enthalten, z. B. Mehrere, wenn sonst dann Verzweigungen und die Eingabeaufforderungsvorlagen zu schwer zu skalieren sind, sollten Sie jedes logische Segment auf separate Agenten aufteilen. Richtig. Wenn Ihre Anweisungen zu komplex werden, sollten Sie sie wahrscheinlich in Unterenten aufteilen. Der zweite Fall liegt vor, wenn Sie viel zu viele Werkzeuge haben. Sie sollten sicherstellen, dass die Agenten zuverlässig mit allen Werkzeugen arbeiten können. Wenn sich die verschiedenen Werkzeuge stark überschneiden oder die Namen und Beschreibungen der Werkzeuge mehrdeutig sind und sie unterschiedliche Aufgaben erfüllen, sollten Sie sie wahrscheinlich in verschiedene Unterkategorien aufteilen und die Agenten darauf aufbauen. Ich persönlich versuche, die Anzahl der Werkzeuge auf etwa 10 pro Agenten zu. Beschränken. Wenn es darüber hinausgeht, werden einige dieser LLMs in der Regel. Große Probleme haben. OK, nehmen wir also an, Sie haben sich entschieden, ein Framework oder Muster mit mehreren Agenten zu verwenden. Dann gibt es zwei verschiedene Möglichkeiten. Die eine ist der Manager Agent. Es gibt also einen zentralen Agenten, der als Orchestrator arbeitet, und andere Agenten stehen diesem Agenten als Werkzeuge zur Verfügung. Das zweite Muster ist der dezentrale Agent, bei dem jeder Agent autonom arbeitet und eine Übergabe der Kontrolle zwischen den Agenten erfolgt. In den Systemen mit mehreren Agenten können beide als Graphen modelliert werden, wobei die Agenten als Knoten dargestellt werden. Im Manager Muster stellen Edges also Werkzeugaufrufe dar, während Edges im dezentralen Muster die Übergabe der Ausführung zwischen Agenten darstellt. OK, hier ist also ein sehr einfaches Manager Muster oder Orchestrator. Es gibt also einen Hauptagenten, der mit der Umgebung oder dem Benutzer interagiert. Er erhält also Eingaben vom Benutzer. Da es sich um einen Orchestrator handelt, hat er Zugriff auf eine Reihe von Werkzeugen, die selbst Agenten sind, und er wählt das geeignete Werkzeug aus und verwendet dieses Werkzeug oder diesen Agenten, um diese Aufgabe auszuführen. Die Ergebnisse werden an den Manager Agenten zurückgesendet, der dann die Ausgabe erzeugt. Alles durchläuft also diesen Orchestrator. So würde man das implementieren. Man definiert also einen Manager Agenten, der über eine Reihe von Tools verfügt. Diese Tools selbst sind jedoch separate Agenten und die gesamte Kommunikation mit den Benutzern erfolgt über diesen Manager Agenten. Okay. Sie haben auch einen Abschnitt über deklarative und nicht deklarative Graphen. Man könnte diesen Orchestrierrangs oder oder Manager Agenten möglicherweise als Graph darstellen. Nun, einige Leute dachten, dass sie auf etwas wie einen Langgraph abzielen. Ich glaube nicht, dass das der Fall ist. Ich sehe durchaus einen Wert in ihrer Sichtweise. Ich denke jedoch, dass deklarative Graphen in agentenbasierten Systemen immer noch sehr wertvoll sind. Richtig. Die meisten Probleme können mit deklarativen Graphen gelöst werden, bei denen man als Domänenexperte im Grunde eine Reihe von Schritten bereitstellt, die der Agent ausführen kann, um ihre Aufgabe auszuführen oder zu erledigen. Man möchte aber dennoch genügend Flexibilität hinzufügen, damit der Agent oder Workflow flexibel dynamische Entscheidungen treffen kann. Es ist meiner Meinung nach noch zu früh, um zu sagen, welcher Ansatz besser ist, aber die Zeit wird es zeigen. OK. Das zweite Muster ist dezentralisiert. Dabei gibt es im Grunde einen Triage Agenten, der zunächst mit der Umgebung des Benutzers interagiert. Danach entscheidet er, welcher Agent verwendet werden soll, übergibt die Kontrolle an diesen Agenten und dieser spezielle Agent setzt die Ausführung fort. Nehmen wir an, die Benutzereingabe lautet Wo ist meine Bestellung? Dann ermittelt der Triage Agent. OK, ich muss das an einen Agenten weiterleiten, der auf Bestellungen spezialisiert ist. Von diesem Zeitpunkt an kommuniziert dieser spezialisierte Agent mit dem Benutzer. Im Moment könnte er mehrere Hände gleichzeitig haben. Bestellungen können beispielsweise an den Vertrieb gehen. Richtig? Und dann können die Vertriebsinformationen wieder an die Bestellungen zurückgesendet werden. Richtig. Es gibt also diese bidirektionale Kommunikation, aber diese ist dezentraler, da man sich nicht auf einen einzelnen Agenten verlässt, der die Ausführung steuert. Hier ist ein kurzes Beispiel dafür, wie die Implementierung aussehen wird. Wir haben also einen technischen Support Agenten mit einem bestimmten Satz an Tools, einen Vertriebsassistenten Agenten mit einem anderen Satz an Tools, dann einen Auftragsverwaltungsagenten und dann haben wir den Triage Agenten, der Übergaben hat. Ich habe ein ausführliches Video zum Python SDK für das Agent SDK von OpenAI, in dem ich sehr detailliert darauf eingehe, wie Übergaben erfolgen und so weiter. Ich empfehle Ihnen dringend, sich das anzusehen, aber dieses ist dezentraler. Beides sind gültige Muster, die Sie in Ihren Anwendungen verwenden können. Es hängt wirklich von Ihrem spezifischen Anwendungsfall ab, welches Sie verwenden. Die letzte Komponente, über die wir sprechen werden, sind Leitplanken, die für jede kundenorientierte Anwendung von entscheidender Bedeutung sind. Sie möchten also sowohl am Eingang als auch am Ausgang Ihres Agentensystems Schutzmaßnahmen einrichten, die Datenschutzrisiken oder Reputationsrisiken für Ihre Unternehmen kontrollieren oder verwalten. Hier ist ein kurzes Beispiel dafür, wie diese Schutzplanken aussehen könnten. Dies ist die Benutzereingabe, die in das mit dem Agent SDK erstellte Agentensystem eingeht. Dann wird es parallel und völlig unabhängig von Ihrer Implementierung eine Reihe von Schutzmaßnahmen geben, an die Sie sowohl die Eingabe als auch die Ausgabe des Systems weitergeben. Dieser parallele Mechanismus wird feststellen, ob es irgendwelche Risiken, Jailbreaks oder Informationslecks gibt. Richtig, und das wird in der Lage sein, entweder die Eingaben oder die Ausgaben zu blockieren. Jetzt ist es wichtig, dass dies unabhängig von Ihrem Agenten bleibt, da der Benutzer auf diese Weise nicht weiß, dass ein paralleles System ausgeführt wird. OK, es gibt also mehrere Arten von relevanten Klassifikatoren, die im Grunde genommen feststellen, ob eine bestimmte Benutzerabfrage für die Anwendung relevant ist, die Sie lösen möchten. Sicherheitsklassifikator. Er erkennt also unsichere Eingaben und Ausgaben. In den meisten Anwendungen möchten Sie PPIs erhalten. Sie können also einen Filter oder eine Schutzmaßnahme einrichten, die das Leck von PPI verhindert. Sie könnten auch eine Moderationsschutzmassnahme oder Moderation verwenden. Ich glaube, es gibt eine kostenlose API von OpenAI, die Inhalte moderiert und dann das Tool schützt. Sie möchten also sicherstellen, dass Sie über ein System verfügen, das Sie vor der Verwendung von Tools, Ausfällen usw. Schützt. Wahrscheinlich möchten Sie auch einen Mechanismus gegen SQL Injektionen oder Prompt Injektionen verwenden. Außerdem sollten Sie für die Ausgabe weitere Schutzmaßnahmen festlegen, die Ihre Ausgabe validieren. Da diese LLM basierten Systeme manchmal ebenfalls beschädigt werden können. Daher sollten Sie auf jeden Fall eine Ausgabevalidierung durchführen. OK. Richten Sie vor dem Erstellen der Schutzmaßnahmen Schutzmaßnahmen ein, die die bereits für Ihren Anwendungsfall identifizierten Risiken berücksichtigen, und fügen Sie weitere hinzu, wenn Sie neue Schwachstellen codieren. Agentensysteme oder LLM Systeme im Allgemeinen müssen iterativ verfeinert werden. Sie müssen also beobachten, wie sich Ihr System verhält und Schutzmaßnahmen, Systemaufforderungen, Tool Aufrufe und die Liste der Tools aktualisieren, wenn Sie auf immer mehr Dinge stoßen. Daher wird empfohlen, sich auf Datenschutz und Inhaltssicherheit zu konzentrieren. Fügen Sie neue Schutzmaßnahmen auf der Grundlage realer Sonderfälle und Fehler hinzu, auf die Sie stoßen, und optimieren Sie sowohl die Sicherheit als auch die Benutzererfahrung. Passen Sie Ihre Schutzmaßnahmen an die Weiterentwicklung des Agenten an. Hier ist nun ein einfaches Beispiel dafür, wie sie mit Hilfe des Agents SDK Schutzmaßnahmen zu ihren Agenten. Hinzufügen können. Sie können also Schutzmaßnahmen für die Eingabe und die Ausgabe festlegen. Diese werden basierend auf bestimmten von Ihnen festgelegten Stolpersteinen ausgelöst. Richtig. Hier ist beispielsweise ein Agent. Um Gottes zu definieren, müssen Sie eine Python Funktion implementieren. Sie müssen lediglich diesen Dekorateur oben hinzufügen. Richtig. Und Sie geben eine Liste der Schutzmaßnahmen an, die Sie für die Eingabe implementiert haben. Auf ähnliche Weise können Sie auch für die Ausgabe Schutzmaßnahmen hinzufügen, die Sie implementiert haben. Richtig. Die Implementierung ist also sehr einfach. OK. Dies war also ein kurzer Überblick über den praktischen Leitfaden zum Erstellen von Agenten von OpenAI. Dies dies deckt sich sehr gut mit meinen eigenen Erfahrungen beim Erstellen von Agentensystemen für Start-ups und Unternehmen und beim Anleiten verschiedener Teams. Ein paar weitere Dinge, die ich hinzufügen möchte, sind evals. Sie sollten auf jeden Fall über robuste Entwicklungen verfügen, wenn Sie ein LM basiertes System erstellen. Diese evals müssen auch erweitert werden, wenn Sie immer mehr Daten sammeln. Warten Sie also nicht auf eine riesige Entwicklung, um anzufangen. 10 bis 15 Beispiele sind ein ausreichender Anfang. Dann können Sie, je nachdem, wie sich das System verhält, weitere Beispiele hinzufügen. Es ist jedoch sehr wichtig, über ein Entwicklungs oder Testset zu verfügen. Das zweite, was ich hinzufügen würde, sind Metriken, die Sie verfolgen. Denken Sie also nicht über irgendwelche ausgefallenen Metriken nach. Viele Leute verwenden beispielsweise Wahrhaftigkeit und Richtigkeit in REG Systemen. Überlegen Sie sich einfach, wie Ihre Anwendung aussehen soll und welche wichtigen Metriken Sie verfolgen müssen. Das könnte so einfach sein wie Genauigkeit oder Rückruf. Denken Sie also über Metriken nach, die speziell auf Ihre Anwendung zugeschnitten sind. Wenn Sie Hilfe bei der Optimierung Ihrer Agenten, Lösungen oder Bewertungen benötigen, biete ich meine Beratungsdienste an. Einzelheiten finden Sie in der Videobeschreibung. Schauen Sie sie sich also unbedingt an. Wie auch immer, ich bin wirklich froh, dass Pionierlaborunternehmen wie OpenAI, Google und Entropic diese praktischen Anleitungen zum Erstellen von Agenten veröffentlichen. Es scheint eine Annäherung an Ideen zu geben, die möglicherweise zu Industriestandards werden könnten. Ich bin also wirklich gespannt auf diese Annäherung und es scheint jetzt einen gemeinsamen Weg nach vorn zu geben. Ich hoffe jedenfalls, Sie fanden dieses Video hilfreich. Danke fürs Zuschauen und wie immer bis zum nächsten Mal.