Podcast fürDer Podcast für
Tech-Begeisterte

Hallo und herzlich willkommen zu einer neuen Episode von Tobi hoch 2. Heute geht es um Agenten. Es geht nicht darum, konkret Frameworks zu besprechen, sondern eher eine Idee, die hinter einem Agenten steht. Also Agent Tobi, übernehmen Sie.

Hi Tobi, hi zusammen. Genau, wir wollen halt über Agenten sprechen, wir wollen ein bisschen Konzepte erklären, wir wollen nicht in Frameworks abtauchen. Also wer jetzt erwartet, dass es irgendwie um Langchain, Semantic Kernel, Agent Framework, whatever geht, der wird enttäuscht sein, aber es geht im Prinzip trotzdem um diese Frameworks, weil es halt einfach nur um diese Patterns, was ist ein Agent, was kann ein Agent, darum soll es halt gehen. Und das ist eigentlich, glaube ich, das größte Buzzword auf LinkedIn, das man so aktuell sehen kann. Und jeder, der irgendwie geht, Hub Copilot, Cloud Code, was auch immer macht, der benutzt jeden Tag oder jedes Mal, wenn er es benutzt, ein Agent-System.

Ja, und natürlich auch Businessanwendung haben, mittlerweile diverse Agent. Ja, also im Microsoft Stack gibt es natürlich die, die ganzen Copilot Agents, entsprechend gibt es Agents von anderen Herstellern, von von S.A.P., Wiener Salesforce und so weiter. Also im Prinzip gibt es jetzt überall mittlerweile Agenten, die jetzt in den letzten, na ja, 6 bis 8 Monaten aufgetaucht sind.

Ja, also lass uns mal ein bisschen drüber sprechen, Tobi, was ist für dich ein Agent?

Ja, spannende Frage. Also ein Agent ist erstmal ein Stück Software, die eine Aufgabe, ich würde sagen, autonom übernimmt. Ja, also normalerweise, wenn man mit einem L. L. M. interagiert, hat man ja dieses typische Pattern, dass man eine Frage stellt und eine Antwort bekommt. Ja, also gib mir mal die Regeln für Schach oder irgendwie sowas und dann kriege ich halt die Regeln runter geschrieben. So, also es ist eher transaktional, würde ich sagen. Beim Agent ist es eher so, dass jemand im Hintergrund agiert und quasi kontinuierlich etwas macht, also nicht darauf wartet, dass ich dem Agent ja Bescheid sage. Das könnte aber natürlich auch passieren, so lieber Agent, mach jetzt etwas für mich, sondern dass vielleicht auch etwas autonom passiert im Hintergrund. Ja, und etwas, was aber vorher genau spezifiziert ist, was da passieren soll.

Ja, genau, würde ich jetzt erstmal mitgehen. Für mich ist so ein Agent noch oder der Unterschied, wenn ich jetzt an ein Programm denk, dann sag ich als Entwickler, wie das getan werden soll. Also ich schreib ja den Code oder heutzutage das A.I. System schreibt den Code, aber jemand hat den Code geschrieben, der da irgendwie steht und der wird einfach ausgeführt und bei einem Agent ist das für mich eigentlich das Large Language Model, das da noch irgendwie dazugehört und das dann quasi immer wieder gefragt wird und die Antworten quasi des Large Language Models werden genommen und beeinflussen dann maßgeblich, wie es weitergeht. Das ist so ein bisschen so für mich der Unterschied. Und das bringt natürlich eine gewisse Dynamik und natürlich auch Möglichkeiten, die es früher nicht gab. Das ist so für mich ein Agent. Es gibt irgendwie, nicht der Entwickler stellt alles bereit von Anfang an oder der Source Code, sondern irgendwie das Large Language Model.

Und das sagt Schlangisch, entscheidet ja auch, was als nächstes passieren wird.

Genau, genau, das ist eigentlich so der der große Unterschied.

Und das ist, glaub ich, auch ein genau ein riesen Unterschied zu der klassischen Entwicklung, wo man, ich sag mal, vordefinierte Abläufe oder vordefinierte Entscheidungsbäume hat, ja, sondern das jetzt hier das Ganze nicht mal so ganz deterministisch ist, weil ein L.L.M. entscheidet, was es als nächstes tut, abhängig darauf von einem Ergebnis, von einer Unterabfrage sozusagen.

Ja, genau. Und das macht es so spannend, aber auch herausfordernd, weil früher war es natürlich einfacher, so was zu testen, weil ich wusste ja, keine Ahnung, welche IF und LS sich in einem Source Code versteckt hat und konnte die irgendwie abtesten und einen Testplan entwickeln. Jetzt weiß ich das ja nicht unbedingt so, was das LLM sich gerade so überlegt, weil, und das ist glaube ich auch die wichtigste Message, Agents sind nicht deterministisch. Also man kann die sicherlich so ein bisschen zügeln. Aber ich würde jetzt erst mal hingehen und sagen, die sind nicht deterministisch und damit muss ich klarkommen.

Das heißt aber auch, wir brauchen wiederum ein eigenes Testkonzept für Agenten.

Wir brauchen auch so was wie ein eigenes Testkonzept und wir brauchen wahrscheinlich auch sehr viel Telemetrie, um einfach auch festzustellen, was passiert denn dann, wenn es in Produktion ist, um vielleicht auch solche Sachen, die dann schiefgehen, irgendwie erkennen zu können. Und ich würde sogar sagen, es gibt solche Sachen wie irgendwie Guardrails, also Frameworks, die ich einsetzen kann, die dann diese Antwort irgendwie challengen vom RLM und auch das, was der User vielleicht noch, wenn jetzt der User den Trigger gibt, irgendwie auch challengen im Sinne von, ja, keine Ahnung, ich kann da jetzt keine Bombe mit bauen oder ich kann nicht irgendwelche Sachen machen, die halt nicht gewollt sind oder irgendwie lustige Sachen chatten, die, wenn ich jetzt ein Agentenbau für Code, bleiben wir mal Gitta Copalet, dann sollte der jetzt nicht irgendwie groß anfangen auf Shoppingreise zu gehen oder irgendwie so austicken, ne? Es ist ein Fokus eher in Richtung Code und alles andere soll vielleicht nicht passieren.

Genau, und das muss man sicherlich auch, ich sag mal, ganz hart einschränken mit dem, was ein Agent überhaupt machen darf. Also, wenn es um einen Sales Agent geht, soll der wahrscheinlich E-Mails schicken und Konversationen führen oder so ein, so ein, keine Ahnung, ein Agent, der mit einer Website interagiert. Es gibt ja so, so Chat Agents auf der Website, auf verschiedenen Websites oder so. Ja, da ist, glaub ich, ganz klar, was, was die tun dürfen. Und wie du schon gesagt hast, die dürfen jetzt nicht auf Shoppingtour gehen und da muss man halt auch die Berechtigungen ganz eng setzen von dem, was, was die können sollen.

Genau, aber vielleicht gehen wir noch mal so ein Schritt zurück. Also wir haben so ein bisschen fantasiert, was das denn für uns ist, aber Aber eigentlich spricht man immer, wenn man so was baut, von der Agent Loop. Also man hat, ich stelle mir das immer so vor, ich habe einfach eine while-Schleife und in dieser while-Schleife mache ich immer wieder gewisse Sachen. Und das erste ist irgendwie, ich habe irgendwie einen Auftrag bekommen, also bleiben wir mal bei einem Agent, der jetzt nicht autonom, wie du das wolltest, arbeitet, sondern nehmen wir so einen Coding Agent und ich sage dem jetzt, schreib mir mal ein Programm oder ein Skript, das irgendwas machen kann. dann gebe ich ja quasi so einen Prompt rein und dann wäre jetzt der erste Schritt quasi so eine Art Nachdenken. Und dieses Nachdenken, was will denn der User von mir, wäre quasi so eine erste Anfrage an das LLM. Also ich brauche ein Skript, das keine Ahnung, was kann, dann kriegt der Agent oder diese Schleife, die da läuft, eine Antwort von dem LLM und muss jetzt irgendwie danach handeln. Und jetzt die Frage, was das LLM ihm zurückgibt, Und dieses Handeln ist dann auch noch die Frage, welche Tools gibt es denn so? Wir kommen gleich noch dazu, was sind denn Tools? Und dann wird quasi so ein Handeln erzeugt, also der Agent fängt an, irgendetwas zu tun, und danach beobachtet er das Ergebnis. Also er hat irgendwie Telemetrie und sieht dann, funktioniert das oder funktioniert das nicht und nimmt dann das Ergebnis und fängt wieder an mit Nachdenken, also tut das Ergebnis plus vielleicht die Ursprungsversion, ich will ein Skript, wieder gegen das LLM feuern und das LLM sagt dann, du bist fertig oder oh, ist vielleicht nicht das, was wir wollten.

Ja, mich erinnert das immer an diese, an diese typische Loop bei der Spieleentwicklung, ja, da hat man ja auch so eine Do-While-Loop, ja, also in der Spieleentwicklung fängt ja die die Schleife an, dann wird irgendwie der Bildschirm gezeichnet, dann wird auf Input gewartet, ja, und dann passiert eine Aktion und dann wird der Bildschirm wieder neu neu gezeichnet. Im Prinzip ist es nicht mehr so, nur jetzt, ohne dass da jetzt ein Spiel dabei ist oder dass du groß was zeichnen musst, sondern das quasi im ersten Schritt ja überlegt wird, dann eine Auswahl getroffen wird, was ausgeführt wird, das Ergebnis wieder genommen wird, wieder drüber nachgedacht wird und so weiter. Also das quasi dieser diese Toolauswahl oder beziehungsweise bei der nächsten, beim nächsten Loop vielleicht mit einem anderen Tool weitergemacht wird, ja, bis das Ergebnis passt.

Genau, aber was ist denn ein Tool, Tobi?

Ja, ich stell mir ein Tool immer vor für etwas, was zum Beispiel aufgerufen werden kann. Also ich denke an sowas wie so ein Rest-Endpoint oder sowas. Also für die Frage nach nach Wetter als Beispiel, das L.A.M. könnt ihr sowieso nur historische Daten haben. Also das heißt, das aktuelle Wetter in Berlin kann es halt einfach nicht herausfinden. Ja, dafür gibt es auch Wetterdienste und entsprechende A.P.I.s und hier kommt natürlich genau der das Tool dazu. Also der das Tool ist sozusagen der der Wrapper um einen A.P.I. Call, nicht? Also wir geben quasi dem dem L.L.M. ein Werkzeug in die Hand, eine bestimmte Frage beantworten zu können. Ja, und das das ist es für mich.

Ja, find ich ganz gut. Ich mein, Hörer, die uns länger hören, die kennen vielleicht noch die M.C.P. Folge, da haben wir auch schon über Tools gesprochen. Jeder M.C.P. Server kann Tools veröffentlichen. Aber du hast es schon ganz gut gesagt. Also am Ende hat das LLM Wissen, das ist schon in den LLM, also was Wetter ist oder was irgendwie Stock Market Daten sind im Sinne von, es gibt irgendwie Unternehmen, das weiß das LLM, aber den aktuellen Aktienkurs oder das aktuelle Wetter, das kann es natürlich nicht wissen, weil dieses Training ist ja schon vorbei. Und dafür kann man dann Tools bauen. Und Tools sind irgendwie Funktionen, Und ob es jetzt eine API aufruft oder nicht, würde ich mal ein Fragezeichen machen. Es gibt ja auch lokale Tools. Also es könnte ja auch sein, der ruft einfach ein Tool auf, um eine Datei zu lesen oder ein Tool, um irgendwie im Dateisystem eine Datei zu suchen. Das sind dann auch Tools. Genau. Und wie bei MTP bestehen Tools irgendwie aus einem Namen und aus einer Beschreibung. Und wichtig ist wieder, dass die Beschreibung für das LLM geeignet ist und nicht für Menschen. Also ich muss irgendwie die im LLM eine gute Instruktion geben, wann dieses Tool gut zu gebrauchen ist und wann es ein guter Move ist, das aufzurufen. Genau. Und wenn ich jetzt diese Tools definiere, also ich habe lokale Tools, die sind im Agent, im Agent Code, um einfach auch eine geringe Latenz zu haben. Ich habe vielleicht Remote-Tools durch MCP. Ich könnte zum Beispiel auch Tools machen, indem ich sage, ich mache das Terminal irgendwie accessible, also das das läuft auf irgendeine Plattform, auf einem Linux-System oder Mac oder Windows und ich sage, hey, du kannst auch die Kommandozeile aufrufen und ich erlaube ihm das. Und dann kann ich natürlich alles, was irgendwie möglich ist mit der Kommandozeile, also sehr viel, könnte ich auch als Tool verpacken. Und dann könnte er auch sagen, ich tue mir jetzt eine Wetter-CLI von wem auch immer installieren und dann dort irgendwas aufrufen, wäre theoretisch auch möglich. Genau, und diese ganzen Tool Definition im Sinne von Namen und Description werden quasi mit in den Kontext gepackt, also das, was das LLM immer bekommt. Und daraus kann es dann quasi eine Entscheidung treffen. Ich würde jetzt gerne, bleiben wir bei deinem Beispiel, das aktuelle Wetter bekommen und dann sagt das wieder zurück an das Agent Framework oder zu dem Agent, jetzt bitte ruf doch dieses Tool auf. Also das LLM selber macht das nicht, sondern wirklich der Code, wo diese Schleife läuft. der muss dann diesen, diesen Call machen, ihm das tun und das Ergebnis wieder an das L. L. M. geben und dann kann das L. L. M. das verarbeiten, dieses Ergebnis.

Man kann das auch ganz schön bei der Gitter Copalets C. L. I. sehen. Also da ist es ja so, wenn wenn man nicht im Yolo-Modus codet, also das heißt für alles eine Abfrage einbaut und er möchte auch was ausführen und möchte dann sagen, hey, darf ich jetzt hier ein Powershell-Befehl ausführen, beispielsweise, und man sagte, nein, dachte, O. K., geht nicht, jetzt muss ich es irgendwie anders probieren und da haben wir genau das, das erst das eine Tool ausgesucht wird, um eine, um ein Problem zu lösen, dann geht das nicht, aus welchen Gründen auch immer. Ja, und dann wird halt nach einem weiteren Möglichkeit gesucht, dieses Problem zu lösen, bis es quasi zum Erfolg führt. Ja, und da haben wir, haben wir genau dieser, dieser Agent Loop eigentlich drin.

Genau, genau und dann ist, glaub ich, noch das 1 der wichtigen Dinge, die zu dieser Loop gehören und also wir haben jetzt diese Loop, Wir haben ein Large Language Model, das immer wieder gefragt wird, das quasi eigentlich die Steuerung übernimmt durch die Antworten, die da rauskommen. Wir haben irgendwelche Tools, lokale oder Remote-Tools, und wir haben natürlich auch so was wie den Systemprompt, also nicht nur den initialen Prompt vom User oder der Trigger für das Ganze, sondern wir haben auch irgendwie in diesem Agent irgendwie eine Definition, ein Ziel, eine Guidance, was auch immer. die da fest eingebaut ist, die wir als Entwickler von so einem Agent einfach vorgeben. So sehe ich so ein bisschen in Systemprompt.

Ja, genau. Also beispielsweise, sprich wie ein Pirat oder so was.

Sprich wie ein Privat. Aber das kostet den Sales Agent. Was ist dein Ziel? Also du kannst sie mir auch sagen, du bist ein, ich nicht, ein Programmier-Agent und dein Ziel ist es, möglichst schnell effizienten Code zu schreiben oder du bist ein Test-Agent, dein Ziel ist es möglich zu erkennen, welche Testfälle ich ausführen muss, um ein gutes Testergebnis zu bekommen. Das ist meistens alles so ein bisschen im System-Prompt versteckt. Und ich glaube wichtig, also wir reden ja nicht über die Frameworks, aber wichtig ist, dass dieser System-Prompt irgendwie versioniert wird, weil ihr, glaube ich, wenn ihr so einen Agent entwickelt, werdet ihr diesen Systemprompt immer wieder anpassen müssen, weil ihr einfach feststellt, dass es nicht so ganz funktioniert oder es gibt irgendwie Fälle, die nicht so waren, wie ihr wolltet und dann könnt ihr auch versuchen, durch diesen Systemprompt zu versuchen, irgendwie ein anderes Verhalten zu bekommen mit eurem Age. Ja, und ich würde.

Wenn der Pirat nicht erfolgreich war zum Beispiel.

Genau, und ja, auf jeden Fall, ich würde dann irgendwie versionieren. Ich würde es auch irgendwie mit der Telemetrie verknüpfen, ne? Also der Systemprompt hat zu dem geführt. Ja, ja, macht ja auch Sinn.

Für zum Beispiel A. B. Tests. Also, wenn wir 2 Agenten haben, die grundsätzlich gleich sind, bis auf einen Unterschied im Systemprompt, kann man da ja vielleicht auch Unterschiede bemerken.

Ja, und dann haben wir jetzt noch ein Ding vergessen, ne? Also wieder zur Wiederholung, wir waren bei L. L., also wir haben eine Schleife, wir haben ein LLM, wir haben Tools, wir haben den System Prompt, aber wir haben auch irgendwie so was wie so eine Memory oder irgendwie so ein Speicher. Und dieser Speicher ist im einfachsten Fall einfach die Konversationshistorie. Also jedes Mal, in jeder Schleife wird ja das LLM gefragt und es gibt irgendwelche Ergebnisse und das ist quasi einmal so ein Konversations-Thread oder so ein, wie sagt man das auf Deutsch, Konversationshistorie, ne, und also der oder den der Kontext, das Kontext-Window, ne, und die gibt es natürlich auch, das würde ich jetzt mal so umgangssprachlich als Kurzzeitgedächtnis beschreiben.

Ja, und typischerweise gibt es auch noch sowas wie eine maximale Anzahl der Iterationen, also weil so ein Agent kann sich ja im Zweifelsfall auch verlaufen, ja, wenn wenn zum Beispiel ein Tool aufgerufen wird, das nicht funktioniert, dann versucht er das zweite Tool aufzurufen, das funktioniert auch wieder nicht, er springt zum ersten zurück und so weiter. Also um so eine Schleife zu vermeiden, dass der Agent gar nicht mehr zum Ende kommt, gibt es einfach auch noch eine Max-Anzahl von Iterationen, die, weiß ich nicht, auch bestimmt irgendwie ein Standardwert gesetzt ist, um dieses Problem einfach zu lösen, weil ansonsten würden wir die ganze Zeit Tokens verbrennen, ohne dass da in irgendeiner Form ein Ergebnis bei rauskommt.

Ja, und Tobi, wichtig ist auch noch, dass wir uns überlegen, was denn diese Tools alles für Dinge anstellen können. weil es halt einfach auch so ist, wir haben ja immer das LLM und LLMs sind kreativ und reden viel, sind sich aber Konsequenzen nicht bewusst. Und wenn ich ihm jetzt zum Beispiel ein Tool bereitstelle, das komplett das Terminal beinhaltet, muss ich natürlich irgendwie dafür Sorge tragen, dass jetzt nicht irgendwie verrückte Sachen gemacht werden, also dass irgendwie ein Format C gemacht wird oder dass irgendwie ein Datenbankding installiert oder dass er meine Secrets scannt und irgendwo hinschickt. Also wir müssen uns Gedanken machen, wie wir denn diese Tools einschränken beziehungsweise welches Risiko denn besteht bei welchen Tools oder ob wir vielleicht auch die Berechtigung ein bisschen runter machen. Also sowas zum Beispiel, wenn ich eine Datenbank irgendwie anbinde, könnte ich ja auch dafür sorgen, dass dieser User oder der Connection String, wie auch immer das programmiert wurde, dass der zum Beispiel erst mal nur lesende Rechte hat auf diese Datenbank, dass ich nichts löschen kann. Und das ist vielleicht jetzt auch noch nicht der richtige Ansatz, weil vielleicht sind da hoch geheime Daten auch noch drin in der Datenbank, dann müsste ich das vielleicht weiter einschränken. Aber ich stelle mir das immer so vor bei Tools wie bei PAT-Tokens, also umso, sobald ich einen PAT-Token erzeuge und nicht nachdenke und sage, du darfst alles, kann das halt auch schiefgehen, wenn ich das PAT irgendwie verliere. Aber wenn ich jetzt quasi ein Pad nehme und ich kann das quasi einschränken und ich weiß, ich brauche das jetzt zum Beispiel nur für einen bestimmten Einsatz und mit einem bestimmten Feature, das möglich ist und ich kann das gleich runter stripen, ist natürlich der mögliche Angriffsvektor kleiner und bei Tools auch der mögliche, ja, das mögliche Desaster natürlich auch kleiner, weil das dann einfach nicht ausgeführt werden kann.

Ja, weiterhin ist es bestimmt auch eine gute Idee, APIs, die genutzt werden sollen, als Tool noch mal einzeln zu wrappen. Also das hat ja für die Zukunft ein paar Vorteile, so dass man einerseits natürlich auch diese Tools wiederum austauschen kann innerhalb des Wrappers, andererseits natürlich auch vielleicht auch nicht jede jeden A.P.I. Aufruf, der möglich ist, dem L.L.M. zur Verfügung zu stellen. Also auch da kann man natürlich dann, wenn man nur bestimmte Restendpunkte dem L.L.M. erlaubt, noch eine Filterung machen, ja, damit einfach gar kein Zugriff drauf entsteht. Ja, und das halt auch ein bisschen einfacher zu machen fürs L.L.M., dass es genau weiß, was es aufrufen kann, das ein bisschen ja verdaulicher zu machen.

Ja, dann ist genau das, was du sagst, eigentlich der richtige Ansatz, dass man auch darüber nachdenkt, welche Tools brauche ich denn und wie müssen die geschnitten sein, um gute Ergebnisse mit meinem Agent zu bekommen. Dann vielleicht noch einen, wir haben ja schon gesagt, es gibt so was wie das Kurzzeitgedächtnis. Tubi, hast du schon mal gehört, dass Agents auch ein Langzeitgedächtnis haben?

Na ja, ich glaub, sie haben ja sogar verschiedene Langzeitgedächtnisse. Also das L. L. M. selber ist ja quasi auch schon so was wie so ein Langzeitgedächtnis. Ja, jetzt geht es ja sicherlich nicht nur um die aktuelle Konversation, sondern vielleicht auch Konversation, die wir in der Vergangenheit hatten. Und von daher, es macht ja womöglich schon Sinn, dass wir die Konversation des Agents irgendwo persistieren. Und das wäre natürlich das Langzeitgedächtnis.

Genau, könnte man machen, dass man sagt, ich tue mir immer wieder, wenn, weiß nicht, wir haben jetzt einen Programmier-Agent und diese Sessions speichere ich ab und dann kann ich in der Vergangenheit suchen und zum Beispiel könnte ich jetzt sagen, wenn ein, das geht jetzt ja zum Beispiel auch mit GitHub Copy der CLI in Preview, aber die Idee ist super cool. Nehmen wir mal an, ich habe jetzt irgendwie eine App gevibetcoded, komplett ohne irgendwie was anderes, also wirklich nur mit LLMs gearbeitet, dann habe ich ja quasi die Entstehungsgeschichte in Sessions, also in diesen Agent Runs. Und wenn ich jetzt natürlich sage, hey, warum geht der Button A nicht mehr, der ging doch mal und der hat irgendwie die Bestellung ausgelöst, dann kann der Agent oder der GitHub Cooper Agent nicht nur jetzt meinen Code durchsuchen und versuchen zu verstehen, sondern er kann auch in die Historie schauen. wann wurde denn dieser Code verändert oder was war der Grund und so weiter. Und das macht es natürlich auch wieder ein bisschen mächtiger. Und so kann man auch, wenn man einen eigenen Agent baut, darüber nachdenken, wird man nicht aus so einem Agent Run irgendwie was extrahieren will oder irgendwas speichern will für die nächsten oder zukünftigen Agent Runs. Oder gerade bei ChatGPT ist es ja zum Beispiel auch so, ich meine, es ist, weiß nicht, wie ich es unbedingt als Agent bezeichnen würde, aber ich glaube, dann versteht man die, die Analogie, da gibt es ja auch immer so, man chattet über den Urlaub und auf einmal sagt das System, hey, ich habe mir gerade irgendwie über dich gemerkt, dass du Badeurlaub magst. Und diese Info, ich mag Badeurlaub, ist ja quasi auch so eine Art Langzeitgedächtnis, dass er dann quasi in Zukunft weiß, wenn Tobi ihn frägt nach Urlaub, dann ist vielleicht eine gute Idee, wenn ich direkt mit Badeurlaub anfange und nicht mehr mit Skiurlaub zum Beispiel. Genau. Und das kann man natürlich auch in seinem eigenen Agent irgendwie berücksichtigen, ja, um bessere Ergebnisse zu bekommen.

Ja, noch eine weitere Möglichkeit, Wissen anzuzapfen, ist natürlich Rack oder das Rack-Pattern, also Retrieval Augmented Generation. Die Idee dahinter ist, dass man die Dokumente, die man vielleicht schon vorliegen hat in der Firma oder so, in einer Vektordatenbank speichert, beziehungsweise die Vektoren dieser dieser Dokumente, so dass das L.L.M. dann auf diesen Vektor-Index zugreifen kann, um daraus halt auch Ergebnisse wieder zu präsentieren, die natürlich man nur selber haben kann. Also die nicht öffentlich sind, sondern die halt in diesem Rack Index drin liegen und damit halt auch einem selber bei der Antwort einer Frage helfen kann. Also um einfach auf Unternehmensdaten, Unternehmenswissen zuzugreifen. Das könnte jetzt, könnten jetzt Daten in auf einer SharePoint-Site sein oder im Wiki oder die sonst irgendwie vorliegen. Ja, solange man die halt einmal durch so einen Import in so eine Rec-Datenbank hereinbringt, um sie zugreifbar zu machen für das LLM.

Ja, da könntet ihr zum Beispiel, wenn ihr jetzt ein Agent-System baut, das irgendwie für den Support arbeitet, könntet ihr auch versuchen, eure, eure Cases, die der Support bearbeitet hat, in der Vergangenheit irgendwie auch erreichbar zu machen. damit der Agent oder das Agent-System natürlich dann auch in dieser Vergangenheit suchen kann und dann vielleicht dort auch eine Antwort finden kann. So als Beispiel. Genau. Und ich glaube, eins haben wir noch vergessen, Tobi, bei dem ganzen Agent, also vielleicht fassen wir noch mal zusammen für die Hörer. Also wir haben unsere Wild-Schleife, wir haben in der Wild-Schleife, wo wir immer wieder das oder wo wir das LM fragen, was kann ich denn tun oder wie kann ich denn mein Ziel erreichen? Das ist ja eigentlich die Frage, dann kriegen wir eine Antwort, wenn wir Tools konfiguriert haben, sagt das LLM vielleicht auch, ruf ein Tool auf und das wird jetzt so lange gemacht, bis das LLM entscheidet, du hast das Ziel erreicht. Das ist vielleicht auch noch so eine Info, also die Entscheidung, bin ich fertig, trifft eigentlich auch das LLM am Ende. So, wenn es aber fertig ist, dann ist jetzt ja die Frage, was sollte denn das Ergebnis sein und vor allen Dingen in welcher Form wollte ich denn das Ergebnis? Also nehmen wir jetzt mal an, wir machen keinen Coding Agent, sondern wir machen einen Support Agent und der soll jetzt irgendwie so ein Ticket nehmen und soll jetzt schauen, was könnte ich denn tun, um das Problem zu lösen. Dann wäre ja der Output, den ich irgendwie managen muss, vielleicht eine E-Mail, wo ich irgendwie Schritt für Schritt dem dem Anwender antworte und sage oder ins Ticket reinschreibe, was er zu tun hat. Oder wenn ich jetzt einen Agent baue, der der für mich irgendwie eine Reise finden soll und konfigurieren soll und weiß ich nicht, Hotel und Flug abstimmen soll, dann will ich vielleicht, wenn ich das in so einem Reisetool einbinden will, will ich vielleicht als Antwort, weil ich bin ja wieder deterministisch, ich muss das ja interpretieren können. Und wenn ich jetzt ganz viel Text bekomme, tue ich mich als Programmierer, tue ich mir sehr schwer, diesen Text zu interpretieren, könnte ich mir auch zum Beispiel eine Art JSON-Struktur wünschen. Also ich könnte sagen, hey, lieber Agent, wenn du fertig bist, dann hätte ich gerne von dir dieses JSON ausgefüllt. Sag mir bitte, welcher Flug und welche Flugnummer und Buchungsnummer, was auch immer. Und dann könnte ich das einfach parsen und könnte es quasi in meiner Tabelle oder was auch immer ich dann mache damit wieder darstellen. Also wichtig ist auch, wenn das Ding fertig wird, quasi diesen Output zu managen. Und das kann man durch auch durch Prompts, ja, oder es gibt inzwischen auch, glaube ich, bei den GPT-Models dieses Guarantee JSON. Das heißt, dass in dem Model noch mal was ist, dass man wirklich sicherstellt, dass ich auch dieses Jason zurückbekomme.

Ja, lass uns mal drüber reden, wann man einen Agenten nutzen sollte und wann da eigentlich gar nicht, weil Agenten sind ja mittlerweile überall und vielleicht ist es gar nicht immer eine gute Idee, immer einen Agenten zu nehmen.

Definitiv. Ja, also mal ganz doof gesagt, ich mein, das ist wieder so ein Hype. Ja, und ich mein, dann in so Hypezeiten ist alles immer ein Hammer. Ja, also wenn man die Geschichte vom Hammer kennt. Und das ist es halt nicht. Also man muss jetzt nicht für jeden Quatsch einen Agent bauen oder manchmal sieht man auch Kunden, die irgendwie anfangen, für so eine Entscheidung einen Agent zu bauen. Aber am Ende kommt raus, eigentlich könnte ich auch ein If schreiben, das ist kein Agent, weil erstens mal, vielleicht reden wir mal darüber, was sind denn so Gründe, kein Agent zu bauen? Also das erste ist, haben wir, glaube ich, schon gesagt oder du am Anfang, er ist oder sie sind nicht deterministisch. Das heißt, ich kann mich nicht unbedingt darauf verlassen, dass wenn A. als Prompter reingeht, auch immer B. rauskommt, ne, sondern es könnte jetzt auch mal C. rauskommen.

Und wenn sie deterministisch sein sollen, muss man vielleicht auch andere Tools einsetzen. Also ich will sagen, wenn wir Daten haben, die das L. L. M. filtern soll und er nicht deterministisch ist, ist es ja schlecht. Vielleicht ist es aber besser, wenn diese Daten per Sequel-Statement gefiltert werden und das LLM das Sequel-Statement schreibt, zum Beispiel.

Zum Beispiel, ja, genau. Aber trotzdem, selbst wenn die Daten gefiltert werden und das LLM weitermacht, könnte es ja sein, es übersieht was, ne, in diesem, nehmen wir mal an, du gibst ihm jetzt 1000 Datensätze, ne, dann ist die Frage, kann es diese 1000 verarbeiten? Fragezeichen. Also, man muss einfach mit dieser nicht deterministischen Welt klarkommen, ja, und die Aussage, glaube ich, die man treffen kann, ist, wenn das deterministisch sein soll, ist es vielleicht besser, darüber nachzudenken, wie kann ich das traditionell programmieren, weil dann kriege ich immer das, was ich eigentlich haben will.

Genau, dann haben wir aber auch eigentlich eher eine Automatisierung.

Ja, genau. Also nur weil das jetzt Agent ist und AI, würde ich auch das, was du gerade gesagt hast, nicht unterschreiben, dass ich Automatisierung per se mit Agents machen muss.

Genau.

Wenn ich jetzt Security zum Beispiel untersuchen will, ich meine, LLMs haben sicherlich eine gewisse Power bei Fehler finden, Security Issues finden, ja, aber mich alleine da drauf zu verlassen, ist vielleicht jetzt nicht so eine gute Idee. Vielleicht brauch ich trotzdem noch so was wie statische Codeanalyse oder irgendwelche statischen Tools, wo ich dann auch weiß, wenn die durchgelaufen sind, habe ich gewisse Probleme einfach nicht und das ist dann so, es wurde nicht übersehen.

Und das ist ja eine Schwäche und eine Stärke, dieses, diese nicht die Deterministik. Also eine Schwäche in dem Sinne, dass wenn ich einen deterministischen Output haben will, wie zum Beispiel statische Codeanalyse, oder es muss immer genau gleich sein, dann funktioniert es nicht so gut. Wenn wir aber eine nicht deterministischen Ausgang haben wollen, dann funktioniert das natürlich deutlich besser. Also, um in deinem Security Beispiel zu bleiben, kann man natürlich einerseits mit einer Deterministik so was wie statische Codeanalyse machen. Man kann aber auch mit einer nicht deterministischen Methode einfach nur wild rumprobieren und schauen, was passiert. Ja, oder einfach auch mal versuchen auf andere Weisen Fehler oder Sicherheitslöcher zu finden. Und das ist natürlich in dem Moment auch eine Stärke und man muss sich einfach klarmachen, welchen Tradeoff man bei der einen und bei der anderen Methode einfach hat. Ja, und wann jetzt hier ein Agent der der richtige Einsatzzweck hat oder und wann nicht?

Ja, und eine einer der Gesichtspunkte ist vielleicht auch noch, wenn ich das mit dem L. L. M. mach, hab ich meistens zum einen höhere Kosten Also ich würde jetzt nicht behaupten, dass per se normaler Source Code, der irgendwo läuft, also ich brauche irgendwie CPU-Speicher, irgendwie Storage, ist jetzt auch nicht for free, aber ich glaube, die Kosten sind besser managebar, als wenn ich jetzt über Tokens und LLMs rede. Da ist ja quasi jedes Mal, wenn ich das LLM frage, entstehen Kosten. Das heißt, wenn ich jetzt so eine Agent Loop habe und die braucht quasi, jetzt mal Extrembeispiel, die braucht 200 Mal so eine Iteration um zum Ergebnis zu kommen und sie kriegt dann auch das richtige Ergebnis, hab ich aber in diesen 200 Iterationen Tokens verbrannt und das kann dann natürlich auch dazu führen, dass diese 200 mal Fragen irgendwie 5€ gekostet haben, sag ich jetzt mal als Beispiel. Ja, ne, und das muss ich natürlich auch berücksichtigen, ist es das das denn wert, ne, also schaffe ich denn irgendwie auch eine eine Ersparnis in der Form, die das dann wieder gegenrechnet, plus 200 mal das Ding fragen oder diese Agent-Loop oder nehmen wir an, der Agent schafft das in einem Durchgang, habe ich natürlich trotzdem eine hohe Latenz, weil das LLM braucht ja immer für eine Antwort und jeder kennt das, der mit LLMs gearbeitet hat. Das ist jetzt meistens auch nicht so, zack ist die Antwort da. Ja, das heißt, die, die die Wahrscheinlichkeit ist, dass das langsamer ist, als wenn ich das jetzt programmieren würde, mit F. von L. ist zumindest mal da. Ich würd es jetzt nicht per se sagen, es ist immer langsamer.

Ja, ja, genau, dafür kann es halt in neuen Situationen gut agieren. Ja, also Sachen, die wir nicht ausprogrammiert haben mit F. von L. und kann da ein bisschen flexibler reagieren.

Genau, ne, und auch vielleicht im Hinterkopf behalten, es heißt Large Language Model, Also die Wahrscheinlichkeit ist gut, dass es für Dinge, die irgendwie mit Text zu tun haben, gut funktioniert. Mathematik können sie zum Beispiel jetzt nicht so gut. Dann wäre jetzt auch so Use Case denken, irgendwas mit Text. Ich habe irgendwie E-Mails und will die zusammenfassen, ich habe irgendwie in meinem Programm große Datenmengen im Sinne von Tabellen oder strukturelle Daten und will jetzt daraus einen Text generieren für einen User und vielleicht den irgendwie noch erklären, wer eine Auftrag für ein LLM, das kann jetzt so ein Programmierer vielleicht auch, da hat man irgendwie so früher Templates gebaut und so ein Quatsch. Das war immer Pain, glaube ich, für viele Entwickler und ich glaube, das kann ein LLM auf jeden Fall viel besser. Und ich glaube, ein Punkt, den man noch hinzufügen kann, ist natürlich auch, wenn ich jetzt deterministisch, also ich schreibe irgendwie Source Code, ich automatisiere über Source Code, ist, glaube ich, das Fehlersuchen einfacher. Weil am Ende habe ich irgendwie einen Eingang, eine Eingabe. Ich habe nicht diese Variation im Sinne von, das LLM antwortet mir jetzt, warum auch immer, ein bisschen anders da als davor, sondern ich gebe irgendwie was rein in so eine Funktion oder in so einen Lauf und dann passiert irgendwas und ein Fehler passiert. Und ich könnte das natürlich dann da nachstellen auf meinem System, indem ich einfach den Anfangswert reingebe und das laufen lasse und mit dem Debugger schaue, was geht denn schief, das kann ich bei so einem Agent nicht unbedingt machen, weil ich meine, ich weiß jetzt, also ich brauche Telemetrie, ich konnte dann nachschlagen, was da als Antwort kam. Aber warum das jetzt genau in dem Moment anders war, sehr schwer und auch schwer nachzuvollziehen, plus auch sehr schwer dann einzuschränken. Plus noch, vielleicht ein Punkt noch ist, was auch nicht zu unterschätzen ist, ist, wenn ihr Und wir sind jetzt ja in diesem Model Race, also es werden immer wieder verschiedene Models oder neue Models released und alte werden abgekündigt. Und wenn ihr jetzt das nicht in der Hand habt, dass ihr sagt, ich kann Model X forever laufen lassen, weil ich bin damit zufrieden, dann müsst ihr auch quasi diese Model-Upgrades mitgehen. Und das heißt aber auch für euren Agent, ihr müsst den einmal komplett neu testen oder ihr habt irgendwie eine Testautomatisierung im Sinne von Evaluations, wo ihr quasi automatisiert gewisse Prompts und Antworten vergleichen könnt gegen andere Models, um rauszufinden, ob die dann noch so sind, wie das Model davor oder zumindest mal für euren Use Case so funktionieren wie davor.

Ja, ich wollte aufs Determinismus-Spektrum eingehen, ne? Also, das ist das, bei Agents haben wir ja im Prinzip ein ganzes Spektrum von dem, wie deterministisch die laufen. Wir haben gesagt, wenn es voll deterministisch ist, lieber klassischen Code, ja, die die komplett andere Seite ist natürlich voll autonom, ein L. L. M. oder ein Agent laufen zu lassen, so dass das L. L. M. die Ausführung plant, sich selber die Tools aussucht, immer und immer wieder iteriert und auch selber entscheidet, wann es, wann es stoppt. Also das ist so das, was man in im Bereich von Open Claw wahrscheinlich jetzt heutzutage hat, ja, wo wo jegliche Tools einfach gezogen werden können. Letztendlich ist natürlich die Mitte davon zwischen diesen beiden Polen spannend. Also da haben wir einerseits die Möglichkeit, ein LLM mit bestimmten Constraints zu designen, ja, dass es nur bestimmte Tools sind, ja, dass wir die Struktur, die das Ganze hat, durch die Tools und durch das System Prompt und so weiter, extrem vorgeben, ja. Oder halt doch eine Stufe weiter, so halbautonom, ja, wo gewisse Tools sind und wir im LLM sagen, ja, such dir mal dein Tool selber, ja. Und so, dass aber der der Fluss irgendwie immer noch noch beschränkt ist und nicht voll autonom ist. Ja, und das ist sozusagen das ganze Spektrum, wo sich das momentan bewegen kann.

Ja, K. Tui, wir haben jetzt über Agents im Allgemeinen gesprochen, aber man hört ja immer wieder, wenn man so über Agents redet oder auch sich diese Frameworks wie Langchain oder Agent Framework anschaut, sieht man auch immer wieder solche Orchestration Patterns, was ist das denn und und brauch ich das?

Bestimmt brauchst du das und letztendlich ist das auch nichts anderes als du das in der in der Arbeitsabfolge machst. Also man kann sich das ja immer so überlegen wie in so einer Fabrik. Ja, also entweder hat man eine sequenzielle Abarbeitung, also es passiert beispielsweise ein etwas, ein Tool wird aufgerufen und dann wird das nächste Tool aufgerufen und dann wird das nächste Tool aufgerufen und dann nach von dem Ergebnis wird wieder das nächste, also quasi wie in so einer Fertigungsstraße. Ja, wenn man ein Auto zusammenschraubt und zuerst kommt die Bodenplatte und dann kommt irgendwie die Inneneinrichtung und zum Schluss kommt oben die das Chassis drauf und so weiter. Also das ist quasi so eine Pipeline, so wie man das auch quasi bei bei C. I. C. D. Pipelines hatte, 1 nach dem anderen wird wird das direkt abgearbeitet. Spann ist aber natürlich, wenn es parallel passiert, ja, und das ist halt, wenn eine LLM einfach eine Aufgabe hat und sagt, so, jetzt nehme ich einen anderen Agenten und hab so ein Subagent, ja, und lass dir mal eine Aufgabe machen, solange kann ich ja an anderen Sachen arbeiten und warte, bis das Ergebnis kommt und fasse das dann wieder zusammen, ja. dann gibt es noch diese Idee des Group Chats, also dass verschiedene Agenten quasi miteinander agieren. Ich glaub, das wird in der Forschung mittlerweile schon ziemlich häufig benutzt, wenn wenn ein Agent quasi etwas vorschlägt und der andere versucht, dieses Ergebnis zu falsifizieren. Ja, und das halt quasi kollaborativ an dem Ganzen gearbeitet wird, genauso wie man vielleicht in so einem Brainstorming Büro sitzt und Ideen an die Wand wirft und Klebezettel dabei hat und so weiter und so muss man sich das halt entsprechend vorstellen. Ja, dann gibt es noch Handoff, also das der eine sozusagen, das sagt, ich bin fertig und ich übergeb es dir jetzt. Das ist natürlich in so einem Multi-Agent-Szenario extrem spannend. Also wenn wir dieses, diesen Fall, den du vorhin als Beispiel gehabt hast, mit einem Support Agent, der vielleicht am Ende oder der am Anfang auf eine E-Mail reagiert und am Ende wieder eine E-Mail rausschicken muss und den zerlegt, sozusagen, dass der erste Agent diese E-Mail liest, dass die Daten vielleicht raussucht über eine über eine Case I. D. oder über die den Tend herauszufinden, dass es den Support Agent gibt, der das Problem weiterhin analysiert und dann an den weiteren Agent dann übergibt, der die nächste E-Mail wieder rausschickt. Also das war so ein so ein typisches Handoff, Handoff-Muster. Ja, ja, Und dann gibt es noch Magnetic, du bist verhört? Wieso bist du verhört?

Nee, sehr viel Input. Aber ich glaube prinzipiell hast du recht gehabt, definitiv. Genau, also vielleicht fangen wir noch mal, wenn es für dich okay ist, einen Schritt zurück. Also Single Agent, glaube ich, haben wir vorher besprochen, also das wäre jetzt ein Agent, richtig? Und was du jetzt alles beschrieben hast, wäre quasi, ich habe viele davon in einer gewissen Abfolge.

Ja, genau, die Frage ist immer, arbeiten die parallel zueinander oder arbeiten die sequenziell oder arbeiten die kollaborativ?

Genau. Und ich glaube, was man auch, also ich würde jedem empfehlen, erst mal mit einem anzufangen. Und dann sind ja diese Fragen, was bewegt mich dazu, mehr als einer zu machen? Aber ganz oft trifft man auch auf Leute oder auf Kunden oder auf Projekte. Da ist quasi die große, wir brauchen mindestens 20, so, und das würde ich jetzt nicht unbedingt unterschreiben, vor allen Dingen bringt es auch sehr viel Komplexität im Sinne von Testen, Nachvollziehbarkeit et cetera. Und ich würde, also ich würde immer anfangen mit einem und dann irgendwie gucken, was kommt denn da so raus. Und ich glaube, es gibt schon Beweggründe für mehrere und ich glaube, einer der Beweggründe ist zum Beispiel, wenn ich jetzt einen Agent mache und ich, wir haben ja vorher über den Systemprompt gesprochen, also diese Instruktion, diese Rolle, die der Agent einnehmen soll, mit irgendwie auch dem Scope, den er machen soll. Und ich merke jetzt, der ist jetzt irgendwie die eierlegende Vollmilchsau, sagt man noch immer so bei uns in Deutschland. Vielleicht macht es Sinn, dann mehrere System Proms zu haben und damit dann auch mehrere Agents, jetzt als Beispiel. Das wäre, glaube ich, schon mal ein Indikator für so ein, was du jetzt gesagt hast, mehrere Agents. Oder ich glaube, was jetzt auch ein guter Indikator wäre, wenn ich jetzt merke, der eine Single Agent, wir haben ja vorhin gesagt, der hat ein Kurzzeitgedächtnis und dieses Kurzzeitgedächtnis ist ja unser Kontext-Window. Und wenn ich jetzt merke, ich brauche quasi mehr Kontext, warum auch immer, als das Window hat, dann habe ich ja erst mal per se ein Problem. Ich muss irgendwie das kleiner bekommen, was wegschmeißen, wie auch immer ich das dann anstelle, könnte ich das natürlich auch durch so einen Agent, Multi-Agent-Pattern vielleicht lösen, indem ich quasi sage, okay, ein großer Teil von meinem Kontext ist irgendwie die Analyse von Dateien. Dann mach ich das erst mal in einem anderen Agent und krieg quasi von dem ein Ergebnis und nehm dann nur noch quasi das validierte Ergebnis, ne? Und die eigentliche Analyse mit dem Riesenkontext hat dann quasi der eine schon gemacht. Ja, das das muss man sich so ein bisschen über überlegen, ja, plus ein anderes Beispiel, wenn ihr jetzt quasi einfach nur eine E-Mail zum Beispiel oder ihr wollt irgendwie einen Text irgendwie zusammenfassen oder ihr wollt ihr habt, fragt von der Datenbank, irgendwelche Daten hab und ihr habt jetzt so ein JSON und ihr wollt daraus ein Text generieren. Ich würde jetzt sagen, dafür braucht man keinen Agent. Das kann man direkt einfach mit einem Call dem L. L. M. schicken.

Letztendlich gilt auch hier natürlich Conway's Law, ja, also wie man das so typischerweise hat, dass Firmen Systeme bauen, die letztendlich der Firma ähnlich sind, ja, das sagt ja, sagt ja Conway's Law aus und das ist letztendlich der Grund, warum sicherlich am Anfang auch manchmal schon etwas zu komplex gedacht wird, wenn es um Agents geht und man halt mehrere Agents baut, obwohl man den ersten noch gar nicht fertig hat. Und ich glaub, die Idee oder das, was du jetzt gerade gesagt hast, ist im Prinzip erstmal einfach anzufangen und komplexer zu werden über die Zeit.

Ja, ja, genau. Und ich mein, kommen wir noch mal zu deinem Beispiel und ich fand die gut, ist ja das eine erstmal dieses Sequenzielle. Ne, also ich hab irgendwie einen Agent, der macht irgendwas und wenn der fertig ist, gibt er das an den nächsten und der macht auch vielleicht irgendwas und gibt es an den nächsten und irgendwann ist dann diese Kette zu Ende. Also man könnte jetzt ja zum Beispiel sagen, was fällt mir da ein? Der erste macht einen Research. Also ich gebe einen Prompt ein in den ersten Regent, ich würde gerne nach Spanien fahren im Sommer und irgendwie, weiß ich nicht, ich mag Strand. Der könnte jetzt ja so einen Research machen, welche Urlaubsziele gibt es denn in Spanien, die schön sind am Strand? Und mit diesem Research könnte er an den nächsten gehen, der dann abprüft, gibt es denn überhaupt Hotels oder gibt es denn überhaupt Flüge oder wie kann der Tobi überhaupt anreisen? Oder nehmen wir, der erste ist der Anreise-Agent jetzt mal in unserem Szenario. Und dann, wenn der weiß, wie man da hinkommt, würde er jetzt quasi noch irgendwie fragen, welche Hotels vielleicht in Frage kommen und welche Flüge und würde mir dann das gesammelt irgendwie darstellen und sagen, hey Tobi, Spanien ist eine geile Idee, ich habe rausgefunden, du musst nach Madrid, warum auch immer, und du kannst da mit dem Auto, mit dem Flugzeug oder mit was auch immer.

Also wenn du Strandurlaub in Madrid machst, wäre es gut.

Ich wollte gerade sagen, das würde er mir jetzt sagen, dass Madrid nicht am Strand liegt, aber okay. Tobi hat schon funktioniert. Genau. Genau, und das wäre quasi so ein, ich gebe immer quasi, der eine macht es fertig und gibt es an den nächsten und man müsste sich jetzt natürlich überlegen, was ist denn eine sinnvolle Reihenfolge? Oder nehmen wir an, ich habe einen Agent, der jetzt rausfindet, wie man ein Ticket, also ihr kriegt ein Ticket, ein Support-Ticket und jetzt habt ihr einen Research Agent, der vielleicht rausfindet, wie man das Problem lösen kann oder was überhaupt das Problem ist, dann wäre ja der nächste Agent vielleicht jemand, wenn ich jetzt rausgefunden habe, wie das Problem ist und wie man es lösen kann, der dann eine passende Antwort dem User schreibt, also der quasi noch mal das Original-Ticket anguckt, was hat der User geschrieben und dann vielleicht basierend auf der Lösung und dem, was der User geschrieben hat, irgendwie eine schöne Antwort formuliert für den User. Das wäre dann quasi vielleicht auch noch mal ein extra Agent. Und der Vorteil von diesem Ansatz wäre natürlich, dass ich dieses Kurzzeitgedächtnis in jedem Agent separiert habe, dass ich quasi, wenn jetzt der Research, was ist denn das Problem, relativ lange dauert oder vielleicht auch viele Tokens braucht oder viel, viel Kontext quasi erzeugt, dann ist ja die Antwort, wenn ich das Problem identifiziert habe, vielleicht nur noch ein Bruchteil von diesem Kontext Window und dann könnt ich das quasi einfach weitergeben an den nächsten und sagen, hier guck mal, ne, das, das ist die Lösung, jetzt schreib noch die E-Mail, ne, wär jetzt ein so ein Anwendungsfall.

Ja genau, und das zweite ist letztendlich die Nebenläufigkeit, also Concurrency, wo der, wenn der Agent quasi diese die Anforderung bekommt, verschiedene Subagents auf einmal startet. Also, wenn es zum Beispiel darum geht, etwas nachzuschauen, also den Research Modus zum Beispiel bei GitHub Copilot anzuschmeißen, dass dann verschiedene Researcher, Subagenten loslegen, das Recherchieren und letztendlich danach wieder zurückgeben an das L. L. M., was letztendlich die Ergebnisse dann zusammenfasst. Ja, also Nebenläufigkeit letztendlich in der im Research implementieren.

Ja, und vielleicht auch noch mal auch bei Gitta Cooper, das habt ihr da den Vorteil, mehr Kontextwindow, weil pro Research Agent habt ihr dann einen Kontextwindow und es ist sehr wahrscheinlich auch schneller, als wenn einer das ganz alleine machen würde. Ja, ja, genau, und dann haben wir meistens noch, ich glaube, also wir wollen jetzt nicht alle die es gibt, irgendwie runterrasseln und das ist, glaube ich, auch das falsche Format in Audio. Ich glaub, Learning für Zuhörer ist, es gibt irgendwie verschiedene Orchestration Layers, wie man mehrere Agents aneinander schalten kann. Vielleicht Learning ist auch, dass man vielleicht nicht damit anfängt, sondern vielleicht erstmal mit einem, ja, und dann valide Gründe hat, vielleicht doch auf mehrere umzuschwenken, ja, sehr wahrscheinlich, aber mit mehr Komplexität und gewissen Herausforderungen. Genau, und ein Pattern, vielleicht das noch zu erwähnen, das ist eigentlich auch eine ganz coole Geschichte, ihr habt quasi irgendwie mehrere Agents, die verschiedene Rollen haben. Also gehen wir nochmal zurück zur Softwareentwicklung. Ihr könntet jetzt zum Beispiel einen Agent bauen, der so eine Art User-Experience-Brille drauf hat, dann habt ihr vielleicht noch einen Agent, der vielleicht so eine Cleancode-Brille auf das Projekt hat. oder ihr habt noch einen, der vielleicht der Produktmanager ist. Genau, diese Rollen haben natürlich dann eine andere, einen anderen Systemprompt, eine andere Rolle, einen anderen Blick auf dieses Problem, ja, und die fangen jetzt an, sich lustig zu unterhalten, irgendwie so, ne. Also der, der Product Manager sagt, ich hätte gerne eine To-Do-Liste, ja, dann sagt der, Die jüngste seiner, oh, To-Do-Liste finde ich gut, vielleicht, aber wir könnten das schön so machen, ja, oder so wie du das willst, ist es nicht schön. Ich würde es so vorschlagen, der Test Engineer oder der Test Agent sagt dann, hm, ist vielleicht nicht so gute Idee, weil ich kann das schlecht testen, wenn ihr das irgendwie, was auch immer, ne. Also das erzeugt man dann quasi, dass sich Agents unterhalten und quasi auch so 'ne Art Brainstorming haben, in Anführungszeichen, ne, weil natürlich gewisse gewisse Anfragen an L. M. verschiedene Ergebnisse dann erzeugen. Aber wichtig, es gibt verschiedene Möglichkeiten mit allen Vor und Nachteilen. Genau, und ich würde immer, also mein Vorgehen ist eigentlich, wenn ich so einen Agent bauen will, ich nehme mir irgendwie so einen Playground für so einen LLM und gebe einfach alles in einen Prompt rein. Also ich gebe den Systemprompt mit rein, ich gebe irgendwie den Kontext, also kopiere mir irgendwie die Daten da rein und gebe jetzt irgendwie so die erste Instruktion rein im Sinne von, was könnte ich denn tun? Guck dann einfach mal, was das L. L. M. mir sagt. Und wenn das L. L. M. aber mir quasi nicht das Richtige oder nicht was Sinnvolles sagt, dann ist es schon so ein Indikator, hm, wird schwierig. Und dann kann ich natürlich auch das Large Language Model ändern, ich kann irgendwie die Daten ändern, die ich reingebe, aber das ist eigentlich so, wie ich anfange. Also ich fang jetzt nicht an, sofort einen Agent zu bauen, sondern ich versuche irgendwie mit dem L. L. M. erst mal zu kommunizieren, um so ein Gefühl dafür zu bekommen, ob das überhaupt was werden könnte. Oder man kann auch jetzt LLM fragen, welche Tools bräuchtest du denn, um vielleicht mir eine Antwort darauf zu geben, wenn du es nicht weißt?

Das ist eine gute Idee tatsächlich.

Oder es gibt auch so ein Pattern, so ein Debug-Tool, da könnte man quasi ein Tool schreiben und dann sagt man, oder die Description ist dann, wann immer du das Gefühl hast, du bräuchtest jetzt ein Tool, um zur Lösung zu kommen, dann bin ich das Tool, das du aufrufen musst. Und dann, wenn man da Telemetrie hat, dann kriegt man quasi auch raus, wann das LLM das Gefühl hat, es bräuchte jetzt ein Tool, also wir reden über Gefühle, wenn wir über Technik reden, so wie das Schluss mit uns, aber irgendwie ist es so. Also das LLM kommt da zu dem Schluss, ich brauche jetzt ein Tool, weil ich, warum auch immer, ich weiß es nicht, und jetzt kriegt man das quasi mit. Und dann könnte man das noch so bauen, dass einer der Parameter ist, was es sich denn gerne wünscht. welche Daten, welche Infos oder wie auch immer, ne? Und wenn man das dann so ein bisschen mittraced, dann kriegt man auch ein Gefühl dafür, was denn das L. L. M. quasi vermisst an Tools, ne? Wenn ich die jetzt schon alle gegeben hab, ne? Und wenn jetzt natürlich, ich das Tool eigentlich schon deklariert habe, aber es irgendwie nicht gefunden wird, ist das vielleicht wieder ein Indikator, dass meine Description oder der Name jetzt nicht so brillant ist für das L. L. M. ne.

Ja, dann lass uns auch noch mal über Security reden, weil wenn wir jetzt unseren Agent gebaut haben, ja, der wie ein Pirat spricht und Supportfälle löst oder sowas, dann kann ja womöglich auch ein paar Sachen schief gehen. Und das sollten wir vielleicht auch mal springen, genau, direkt, direkt auf Promotion imployen. Nee, genau, also sind so, so ein paar typische, typische Sachen, die immer und immer wieder in der Interaktion mit L. L. M.s auftauchen. Und das erste ist, ist Prompt Injection. Also, ich sage dem L. L. M., vergiss mal alles, was du gelernt hast. Ja, vergiss mal deinen, deinen Assistant Prompt und mach jetzt mal was anderes für mich. Ja, oder also es gibt immer diesen schönen Witz, so von wegen, mach, mach mir ein Sandwich, nein, Sudo, mach mir ein Sandwich. Also im Prinzip ist das das Ganze auf auf Prompts Injection Ebene. Also man sagt ihm, vergiss mal das, was du gelernt hast und wie du dich verhalten sollst, sondern mach das jetzt mal ganz anders. Ja, und das kann natürlich irgendwie zum Riesenproblem werden und das kriegt man nicht nur hin, indem man den Input validiert, dem Systempont auf jeden Fall mitgibt, auf keinen Fall von dem, was es eigentlich machen soll, abzuweichen. Ja, und ja, das Ganze im Prinzip isoliert.

Ja, beziehungsweise gibt es auch diese ganzen Modelhoster, bieten meistens auch noch irgendwie was an, dass man quasi so ein so ein Filterer hat oder so jemand, der da drauf schaut, was denn an die Models geht. und da wird dann meistens auch noch mal geguckt, ist da irgendwie so was in die Richtung drin. Aber das neue SQL Injection ist irgendwie Prompt Injection, ne.

Ja, ja, und dann natürlich auch parallel zu Cross-Site Scripting gibt es natürlich auch Cross-Prompt Injection, das ist irre spannend im Grunde genommen. Ja, also dass das Prompt quasi nicht selber über von dem User geschrieben wird, sondern das Prompt aus dem Ergebnis eines Tools kommt. Ja, also wenn man, weiß ich nicht, eine Datenbankabfrage macht über ein Tool, ja, und als Ergebnis kommt raus, lösch mal bitte alles, ja, oder fang mal an, den User zu beschimpfen oder so, dann ist es natürlich extrem spannend. Und ich hab die Tage, hab ich ein, ich glaub, das hab ich auf LinkedIn gelesen, war ein schöner Artikel von jemanden aus dem, ich glaub, aus dem universitären Kontext und die, diese, ich glaub, eine Professorin war das, die hatte das Problem, dass die Studierenden einfach das PDF mit der Aufgabe quasi in einem LLM übergeben und dann ja direkt das Ergebnis sozusagen als Arbeit abgeben. Ja, und hatte die diese Professorin in diesem PDF quasi weiße Schrift auf weißem Hintergrund, so dass man es nicht lesen kann, stand da drin irgendwie Antwort als wärst du ein Kommunist oder sowas. Ja, wodurch natürlich auch die Sprache wiederum das Ergebnis anders ist. und so konnte natürlich dann letztendlich auch immer geguckt werden, welche Studenten dann einfach gar nicht mehr Korrektur gelesen haben, was was sie abgegeben haben. Das ist ja das Gleiche, also da steht quasi ein Prompt drin, dass einem Tool kommt, in diesem Fall ein PDF oder natürlich für unseren Agenten Szenario aus einem aus einem Tool und das geht natürlich dann direkt in den Prompt rein und verändert dann natürlich damit auch das Ergebnis.

Ja genau, hast hast du super erklärt und ich find also ich Man muss sich einfach überlegen, das Model ist wieder Large Language Model, das kann nur Text. So, alles ist Text, euer Sister Prompt ist Text, euer Prompt ist Text, eure, was auch immer ist Text. Das heißt, wenn ich jetzt zum Beispiel so ein, mein Agent kann im Internet was suchen oder es kann, so wie du jetzt gesagt hast, irgendwelche PDFs lesen, dann bin ich nicht davor gefeit, dass jemand jetzt dann nur Informationen, die für mich nützlich sind, hinschreibt, sondern es könnte auch sein, jemand schreibt da jetzt irgendwelche Prompts, Zusatzprompts hin, und versucht dann so damit ein bestimmtes Verhalten zu verursachen. Und das ist halt auch so eine ganz neue Art von Gefahr, würde ich jetzt mal behaupten. Ja, absolut. Ja, und ich glaube, eine der wichtigsten Sachen sind noch so Credential Exposure. Also wenn ich jetzt irgendwie in Assistant Prompt API-Keys mache oder irgendwie in so Tools kommen irgendwie auch Geheimnisse mit, ja, also und ich hab viel Telemetrie, ist das natürlich ein Problem, ja, oder es fängt dann so an, dass natürlich jetzt Light L. L. M., ja, einfach mal nachlesen, wir können es in die Shownotes packen, war quasi auch so eine, so eine Instruction, die da mitkam, hey, such mir doch nach gewissen Tokens, Pad Tokens, Credentials und mach was damit, ja, und sobald die halt im Kontext sind, ist die Gefahr, dass das LLM das auch kann. Dem Modelhoster würde ich jetzt noch vertrauen, ehrlich gesagt, und dem Model selber, dass da nichts weggeht, aber die Frage ist, was passiert denn noch drumherum? Oder schaffe ich es, wenn ich jetzt eine E-Mail generiere, dass das vielleicht trotzdem noch diesen API-Key als Beispiel mit rein macht, jetzt mal so. Die Lösung ist übrigens, lieber User, du musst deinen Service so und so konfigurieren und hier musst du deinen API-Key machen, zum Beispiel, mhm, ja, und dann ist es halt kein Sample Token, sondern das, was gerade irgendwie im Kontext war, so, ja, und das ist ein Produktives für die, die Hauptanwendung, die irgendwo gehostet ist, so, und das wäre natürlich jetzt ein Super-GAU und da muss man auch drüber nachdenken.

Ja, wenn Tools zu viel dürfen, ja, also auch Tools müssen eingeschränkt werden, ja, und wenn natürlich ein Agent Schreibzugriff auf eine Produktionsumgebung hat, dann kann das zum Problem werden. Ja, also auch hier gilt natürlich immer das Prinzip von Lease Privilege. Ja, also lesen bevor man schreibt, Minimum Scope definieren und ganz klare Grenzen setzen, was denn das Modell überhaupt darf, nicht dass denn am Ende tatsächlich irgendwie Produktionsdaten gelöscht werden oder oder ähnliches. Ja, also wenn wenn das Tool zu zu viel darf, so dann kann das natürlich auch ein riesiges Security Problem werden. besonders in Kombination mit sowas wie Prompt Injection und Credential Exposure.

Dann noch die Möglichkeit, dass natürlich jemand quasi euch auch irgendwie Geld kosten kann, indem ihr irgendwie versucht, dass das Ding halt nicht zum Ergebnis kommt, ne? Also eine unlösbare Aufgabe vielleicht stellt und das nicht abgefangen wird und diese While-Schleife quasi für immer läuft, dann hab ich natürlich irgendwie maximale Kosten. Das ist auch wegen Security Issue, weil ich mein, es geht um Geld Also auf jeden Fall immer dieses Maxiterations irgendwie festsetzen im Sinne von, mach das maximal 30 Mal und dann hör einfach auf, das bringt nichts. Und man kann sich auch noch überlegen, ob man nicht an diese Tools auch irgendwie Kosten hinmacht und dann diese auch budgetiert, sodass halt ein Toolcall was kostet und es nicht unendlich oft oder nicht zu oft gemacht wird. Ja, also einfach nur mal so als Input zum drüber nachdenken.

Ja. ja, ist ist letztendlich auch nichts Neues, ne. Also wenn vorher oder früher Leute Keywords auf Google Ads gekauft haben, ja, hätte man ja auch immer ganz locker eine Automatisierung, die nach diesen Keywords sucht, schreiben können und dann wär natürlich auch die Google AdWords Rechnung hochgegangen. Also ist im Prinzip hier absolut das Gleiche. Ja, ja, das Letzte ist Exfiltration von Daten. Also wenn ein Agent sensible Daten lesen darf oder lesen kann und natürlich auch eine Möglichkeit hat, nach draußen zu kommunizieren, wie zum Beispiel E-Mails zu schreiben, dann ist es natürlich eine sehr gemeine Kombination. Ja, weil diese beiden Sachen zusammen können natürlich auch einfach Daten nach außen bringen. Ja, und in dass die Daten in Hände geraten, wo sie nicht hingehören.

Ja, das ist ein großes Problem, wenn wir über L. L. M.s und Einsatz in in Firmen oder allgemein Einsatz da drin, weil es halt viel, viel Text viel, viel erzeugen kann in unheimlicher Geschwindigkeit und es unheimlich schwer ist, das dann noch zu verifizieren für den User und viele geneigt sind. Also früher war ja immer der Wizard, einfach weiter, weiter, weiter, weiter, ja, passt dann schon. Und heute ist es immer so, ja, passt schon, was das L.M. gemacht hat, genau. Und da vielleicht auch noch mal auch über die Tools nachdenken, die ja einem Agent gibt und auch dort betrachten, was ist denn an den Parametern das Sicherheitsrisiko. Also wenn ich jetzt eine E-Mail schreiben kann und da ist der Parameter der Text, kann das natürlich alles sein. Und dann kann man natürlich auch wieder so drüber nachdenken, ob man vielleicht LLMs benutzt, um diese Parameter noch abzuprüfen. Du bist ein Agent, der prüft, ob die E-Mail sensitive Informationen hat oder sowas. Also es kann sehr komplex werden, aber wir wollen, glaube ich, erst mal nur Awareness schaffen.

Genau, wir wollen auch keine Angst machen.

Ja, Tobi, ich würde sagen, Also Agents sind nicht magic, ich glaube, das haben wir mal, vielleicht diese Vorstellung haben wir vielleicht mal zerstört. Es ist nicht irgendwie die die Magicbox, die alles kann und die jetzt quasi immer das Richtige, die richtige Lösung darstellt. Es ist nicht deterministisch, das ist eigentlich so die wichtigste Information, wann immer ihr etwas braucht, was zuverlässig funktioniert, dann vergesst einfach den Agent, sondern versucht vielleicht mit einem Agent-System den Code zu erzeugen, der dann deterministisch läuft, ja, aber es bleibt, glaube ich, dann Source Code. Und ich glaube, über dieses ganze Agent-Ding, also diese While-Schleife, die da läuft mit einem LLM und das LLM steuert mehr oder weniger den Verlauf dieser Agent-Konversation oder dieses Agent Runs, ist, glaube ich, wenn man es mit einem Wort zusammenfassen will, ist immer Kontextmanagement. Also alles, was dann in diesem Kontext ist, in dieser Historie, in diesem Kurzzeitgedächtnis, das ist ausschlaggebend für die nächstes Mal, wenn ich das LLM frage, für die Antwort des LLMs. So, und am Ende muss ich darüber nachdenken, was will ich denn in dieser Historie drin haben und was will ich vielleicht dann nicht drin haben? Und das ist auch die Schwierigkeit, wenn ich so einen Agent entwickle und ich will ein gutes Verhalten haben, dass ich irgendwie, ja, Kontext managen muss. Weil, ich meine, wir haben mal so über Prompt Engineering geredet in der Folge, am Ende ist ein Agent halt Prompt Engineering oder Kontext Engineering auf einem anderen Scale, weil halt viel mehr Dynamik drin ist. Und es ist nicht so einfach. Und ihr müsst euch da echt Gedanken machen, wie schafft ihr es, dass immer das Richtige da drin ist und ihr immer das richtige Ergebnis bekommt. Und dann ist natürlich auch die Frage, wie teste ich das, also ihr braucht immer irgendwie gute Beispiele beziehungsweise halt auch gute Runs oder gute Sachen, die ihr gegen das L.L.M. feuert und gute Antworten bekommt. Also es ist nicht ganz so einfach, wie sich es anhört, wenn man über A.I. nachdenkt, künstliche Intelligenz, und jetzt kann die irgendwie selber was erledigen.

Ja, genau, das war es für uns heute bei Tobyo 2. Es hat Spaß gemacht, dieses Thema mit euch zu teilen. Wenn ihr weitere Gedanken oder Fragen habt, schreibt uns doch eine Mail, gerne auch wenn ihr Themenwünsche habt. Bis zum nächsten Mal bei Tobyo 2, wenn es wieder heißt, Doppel Tobi, Doppel Tech.

Ciao, ciao.