Agenten sind da, wo Microservices 2015 waren — Roberto Milev & Uday Kanagala, Navan
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Hallo zusammen. Willkommen zu unserem Vortrag. Mein Name ist Roberto Milev. Ich bin Chefarchitekt bei
00:00:20Navan und neben mir ist Uday, der ebenfalls zum Architekturteam gehört. Navan ist ein Reise- und
00:00:27Spesenmanagement-Unternehmen und wir möchten einige unserer Erkenntnisse mit Ihnen teilen,
00:00:32wie wir KI betreiben und was wir dabei herausgefunden haben. Wenn Sie schon lange genug
00:00:41in dieser Branche sind, erinnern Sie sich daran, dass es im Laufe der Zeit einige Paradigmenwechsel gab und
00:00:46wir alle dazu neigen, auf den Zug aufzuspringen und Dinge auf bestimmte Weise anzugehen. Das letzte Mal
00:00:53war, als wir alle auf den Microservices-Zug aufgesprungen sind und daraus
00:00:58viele gute Dinge hervorgegangen sind, wie Container-Orchestrierung, Kubernetes, dann hatten wir
00:01:05Service Meshes, Circuit Breaker und all diese guten Dinge. Aber das ist nicht
00:01:11über Nacht passiert. Es hat eine ganze Weile gedauert. Es hat einige Zeit gedauert, bis wir gelernt hatten,
00:01:16wie man diese Dinge macht. Ein Zitat dazu lautet daher: Wenn man einen gut
00:01:21strukturierten Monolithen bauen kann, warum überhaupt versuchen, Microservices zu bauen? Das lässt sich
00:01:26heute übertragen: Wenn man keine einzelne agentische Schleife bauen kann, warum dann versuchen, ein
00:01:32multi-agenten-orchestriertes System zu bauen? Im Laufe der Zeit entsteht also, genau wie zuvor, eine
00:01:41Referenzarchitektur. Wir haben durch die Arbeit in der Produktion einiges gelernt. Wir haben eine
00:01:50Menge Agenten und es werden täglich viele Token verbraucht. Und wie ich schon sagte, es gibt einige Schichten, die sich
00:01:58standardisiert und herauskristallisiert haben, was wir brauchen, um agentische Abläufe
00:02:04zuverlässig in der Produktion auszuführen. Laufzeitgedächtnis, Kontextverwaltung, rund um operative
00:02:12Querschnittsthemen und auch rund um die Orchestrierung. Heute gehen wir also auf einige dieser Schichten ein,
00:02:18tatsächlich auf alle diese Schichten. Und wir zeigen, wo die Branche steht, was wir getan haben, was wir gelernt haben und so weiter.
00:02:27Beginnen wir mit der Laufzeitschicht. Wir haben viel darüber gesprochen und eine Menge
00:02:34Dienste gebaut, um sie zuvor zustandslos zu skalieren. Und jetzt befinden wir uns in einer neuen Welt, in der Agenten
00:02:43von Natur aus zustandsbehaftet sind. Sie benötigen persistente Sitzungen. Sie brauchen Isolierung. Ihr Lebenszyklus
00:02:51unterscheidet sich vom Lebenszyklus eines herkömmlichen API-Dienstes und so weiter. Die Cloud-Anbieter
00:02:59haben sich also eingeschaltet und versucht, diese Lücke zu füllen. AWS, GCP, Azure – sie alle haben irgendeine
00:03:10Form einer agentischen Laufzeit. Wenn Sie den QR-Code für diese Folie und für die folgenden Folien scannen,
00:03:16sehen Sie einen Vergleich einiger Funktionen und wie verschiedene Cloud-Anbieter versuchen, dies anzugehen.
00:03:25Bei Navan betreiben wir alles auf AWS. AWS verfügt über eine Agent-Core-Laufzeit. Wir nutzen diese intensiv, aber wir haben einige Lücken
00:03:33darin geschlossen, wie etwa Sitzungspersistenz und Rehydration, die wir selbst entwickelt haben. Und wir
00:03:41betreiben auch eine Reihe anderer SDKs zum Schreiben von Agenten. Und ein Teil dieser Laufzeiten ist typischerweise
00:03:50frameworkunabhängig, obwohl sie alle ihr eigenes natives Framework bevorzugen.
00:03:58Die nächste Schicht im Stack betrifft den Speicher.
00:04:04Wir haben mit RAG begonnen. RAG war eine Zeit lang eine große Sache. Wir wurden gewissermaßen aus der Not heraus
00:04:11dazu gedrängt, weil man nicht eine unbegrenzte Menge an Kontext in einen Agenten packen kann. Im Laufe der Zeit
00:04:20haben all diese Cloud-Anbieter und die Branche eine Pipeline implementiert, in der der Speicher gewissermaßen
00:04:27automatisch generiert wird, indem ein Workflow aus Ingestion, Extraktion sowie Konsolidierung und
00:04:33Abruf durchlaufen wird. Und es gibt Teile von RAG, die in Dingen wie einem Langzeitgedächtnis eingebaut sind, das
00:04:40von Natur aus einige semantische Eigenschaften aufweist. Aber der Speicher baut sich im Laufe der Zeit auf, vom kurzfristigen
00:04:46Konversationsspeicher hin zu einem Langzeitgedächtnis, das man gewissermaßen selbst verwaltet. Dann episodische Speicher über
00:04:54Instanzen, die gut funktioniert haben oder eben nicht und so weiter. Wir bei Navan nutzen – wieder als AWS-Shop –
00:05:02deren Agent Core Memory. Aber wir tun dies auch auf eine Weise, die
00:05:09zu unserem Anwendungsfall passt. Das nächste Thema ist die Kontextverwaltung. Wissen Sie, das ist ein heißes Thema. Es war
00:05:18ein heißes Thema und ist es immer noch. Kontextfenster werden größer, aber es ist nie genug
00:05:23Kontext vorhanden. Oder wenn es zu viel Kontext gibt, kämpfen Agenten wiederum damit, weil man den Fokus verliert
00:05:29und so weiter. Was sich bei uns bewährt hat, ist die Konzentration auf Fähigkeiten als Kontexteinheit. Ich werde erklären, was
00:05:39ich damit meine. Wir betrachten Fähigkeiten so, dass sie sowohl Kontext besitzen – das heißt Anweisungen und Setup zu einer bestimmten
00:05:48Domäne oder Aufgabe. Und es gibt auch den zweiten Teil der Fähigkeit, nämlich die Tool-Ausführung und
00:05:54den agentischen Teil. Und wir stellen den Kontext dynamisch aus Fähigkeiten zusammen, die wir als Arbeitseinheiten nutzen, die
00:06:06austauschbar sind, die wir unabhängig voneinander testen können und die wir wiederverwenden können. Wenn wir also zum Beispiel einen Agenten haben,
00:06:15haben wir Fähigkeiten, die domänenspezifisch sind. Und basierend darauf stellen wir sie zusammen. Und wir stützen uns auf die
00:06:24progressive Offenlegung, die ein Merkmal der Fähigkeiten selbst ist, um mit einem begrenzten Kontextumfang zu beginnen und diesen
00:06:32dann durch das Einbeziehen von Metadaten später zu erweitern. Ich übergebe nun an Uday, der uns durch
00:06:42den Rest davon führt. Danke, Uday. Gut. Kann ich hier eine kurze Handzeichenabfrage machen? Wer hat schon mal einen Agenten gebaut,
00:06:52der auf halbem Weg durch einen 20- oder 30-Schritte-Prozess fehlgeschlagen ist, und konnte schnell herausfinden oder nachvollziehen,
00:07:00warum der Agent fehlgeschlagen ist?
00:07:05Also, nochmals: Logs. Wir waren traditionell bei Microservices alle an Logs gewöhnt.
00:07:11Es gibt Logs da draußen, und dann schauen wir uns die Logs an. Aber das ändert alles in dem Moment, in dem wir
00:07:16zu Agenten wechseln. Agenten geben eine Menge Gedanken aus. Es ist zu viel, um es zu konsumieren. Das ist also nicht der richtige
00:07:22Weg dafür, oder? Traditionell war das der Weg, aber unsere Denkweise muss sich jetzt ändern,
00:07:28so wie Claude es als Beispiel zeigt. Wenn wir Claude als Beispiel für einen Agenten nehmen, gibt es Hooks,
00:07:35und wir können alles abfangen, was Claude als Agent auf dieser Ebene tut. Also welche Art von Tool er aufruft,
00:07:42oder? Welche Art von Entscheidung er trifft? Also vor dem Tool-Aufruf und nach dem Tool-Aufruf oder vor oder nach einer Sitzung. All das
00:07:49sind Zeitpunkte für uns, um einzugreifen und eine Entscheidung zu treffen und entweder
00:07:56eine blockierende Operation durchzuführen oder eine Metrik zu protokollieren oder auszugeben, richtig? Dies ist ein kritischer
00:08:04Ort, an dem wir Otel-Traces ausgeben können. Bei Navan nutzen wir einen unserer Anbieter, Brain Trust, um diese Otel-
00:08:11Traces auszugeben. Und durch diese Traces sollten wir in der Lage sein, die Spans, die Traces und den genauen
00:08:17Zeitpunkt zu ermitteln, an dem der Agent feststeckt, was uns viel mehr Vertrauen in unsere Arbeits- und Bauweise mit den
00:08:25Agenten gibt. Dies ist eine operative Herausforderung für Tag 2. Das Erstellen von Agenten bietet heutzutage so viele Frameworks,
00:08:32aber wie man das Erstellen und den späten Betrieb eines Agenten steuert, ist mittlerweile ein Hauptanliegen.
00:08:39Darüber hinaus die Argumentationskette, der Denkprozess und die kritischen Signale, die wir hier ausgeben. Als
00:08:45Teil der Trace-Erfassung geben wir hier einige primäre Signale aus. Was ist das aktuelle Ziel, das der Agent
00:08:52verfolgt? Die Gründe hinter seinen Operationen und der Überzeugungsstatus sowie die Tool-Aufrufe, die er
00:08:57getätigt hat. Das gibt uns sozusagen Beurteilungshinweise in den Traces. Und wenn der Agent eine Entscheidung trifft,
00:09:07gibt es einen Konfidenzwert, der zeigt, wie sicher er sich bei dieser Beurteilung ist, richtig? Also, ob es
00:09:12mehrere Pfade gibt, die zu dieser Wahl führen, oder ob dies eine geschlussfolgerte Antwort ist. Im Grunde sind
00:09:18dies Signale, die uns später Vertrauen für die Überprüfung geben. Wenn dies eine geschlussfolgerte Antwort ist, könnte ein
00:09:24Mensch in der Schleife sein, um den Agenten zu leiten und zu schulen, damit er etwas bessere Leistungen erbringt.
00:09:32Nochmals: Kann ich wieder ein Handzeichen sehen, um zu erfahren, wie zuversichtlich – wie zu 100 % zuversichtlich – Sie bei
00:09:40Testpipelines mit Ihren Agenten sind?
00:09:43Richtig? Das ist heute einer der anderen kritischen Aspekte.
00:09:51Weil Agenten nicht-deterministisch sind. Wir sind alle daran gewöhnt, zu programmieren und viel
00:09:55deterministischere Abläufe zu schreiben. Und wir wissen, wie das funktioniert. Wenn ich einen Ingenieur frage, kann dieser mir erklären,
00:10:02wie der Algorithmus, die Operationssequenz und alles in unserem Kopf programmiert ist, alles entspricht
00:10:06den Erwartungen. Aber jetzt treten Agenten auf eine nicht-deterministische Weise auf, und wie testen wir sie,
00:10:11richtig? Das ist hier äußerst kritisch. Und ja, auch wir kämpfen damit. Wir haben begonnen,
00:10:19Agenten zu bauen. Die Datenoperationen waren anspruchsvoll, und dann sind wir in vielen
00:10:23Schritten gescheitert. Wie korrigieren wir unseren Kurs? In dem Moment, in dem wir etwas ändern, geht etwas anderes kaputt, richtig?
00:10:29Wie machen wir das also? Ein Ansatz, den wir gewählt haben, stammt aus Forschungspapieren zum Konzept
00:10:36der Trajektorie. Wenn ein Agent bei einer mehrstufigen Orchestrierung 30 Schritte oder Entscheidungen trifft, um ein
00:10:44Ziel zu erreichen, ist das eine Sache, wenn es ein Programm wäre. Aber das ist kein Programm. Das ist eine
00:10:51nicht-deterministische Art, bei der er jedes Mal seine eigenen Schritte anders aufbaut. Wie können wir also
00:11:00hier einen deterministischen Graphen abbilden? Ist das möglich? Nein. Können wir eine Trajektorie von Anfang bis
00:11:09zu einem Ziel haben und dann sehen, wie weit er auf dieser Trajektorie vorangekommen ist und wie weit er von der Quelle
00:11:15bis zum Ziel entfernt war? Das können wir berechnen, um die Effizienz oder Vollständigkeit der Agenten
00:11:23zu bewerten. Wir stützen uns also stark auf Trajektorien-Evals. Und es gibt ein paar andere Signale, wie ich vorhin
00:11:35kurz auf der vorherigen Folie erwähnte, rund um das geschlussfolgerte Signal. Wenn die Antwort eine geschlussfolgerte Antwort ist,
00:11:42wie können wir das einbinden und Signale dafür erstellen, wie wir klassifizieren können, dass dies eine Regression ist, und
00:11:52Korrekturen am Agenten vornehmen? Als nächstes folgen die Leitplanken (Guardrails).
00:12:11Ist das die richtige? Ja. Leitplanken und Autorisierung. Dies spielt eine kritische,
00:12:21eine kritische Rolle in Unternehmens-KI. Viele Informationen werden in Modelle eingespeist.
00:12:28Es könnten sensible Informationen darin enthalten sein, die ohne unser Wissen einfließen. Und wie können wir
00:12:35als Führungskräfte diese Governance-Schicht einziehen, um dies zu stoppen? Das ist hier von entscheidender Bedeutung. Und das Konzept
00:12:44von Authentifizierung und Autorisierung nimmt hier einen anderen Ansatz ein. Traditionell
00:12:51haben wir einen Benutzer oder ein Dienstkonto gesehen, aber was ist jetzt ein Agent? Ein Agent kann im Auftrag von
00:13:00Benutzern handeln. Es gibt so viele Dinge, so viele Anwendungsfälle dort. Hey, buche mir einen Flug, wenn er günstiger ist
00:13:06als 200 Dollar ist, richtig? Wir stellen diese Anforderung und der Agent findet es heraus und führt diese Aktion in meinem
00:13:12Namen aus. Tätige ich diesen Kauf also selbst oder tut der Agent das in meinem Namen? Also da gibt es
00:13:19Der Agent handelt im Namen des Benutzers oder der Agent nutzt auch ein Dienstkonto. Die Grenzen verschwimmen hier also und wir müssen
00:13:27hier präzise Autorisierungsentscheidungen treffen. Und die Richtlinienebene, da spielen die Leitplanken
00:13:32sowie Authentifizierung und Autorisierung eine entscheidende Rolle. Und bei Navan setzen wir Folgendes ein:
00:13:39Vor jedem Tool-Aufruf, vor und nach dem Tool, nutzen wir diese Leitplanken, um Prüfungen vorzunehmen, zu blockieren und fundierte Entscheidungen zu treffen.
00:13:51Und Single Agent versus Multi-Agent – das ist im Grunde wieder so eine Art Orchestrierungskrieg, über den man nachdenken kann,
00:14:00ob man einen einzelnen Agenten oder mehrere Agenten bauen soll. Wie Roboto bereits kurz angedeutet hat,
00:14:05wenn man keinen perfekten einzelnen Agenten bauen kann, warum dann zu Multi-Agenten übergehen, richtig? Lernen wir also aus unseren
00:14:14Fehlern und Erfahrungen und arbeiten darauf hin. Bei Navan ist der Ansatz, den wir gewählt haben,
00:14:22ein einzelner Master und dann haben wir Unterfähigkeiten übernommen. Es gibt Unteragenten darin. Es ist also ein einzelner Agent, der
00:14:32die Fähigkeiten schrittweise laden und genau verstehen kann, was in den Kontext geladen werden muss, um dann
00:14:39diesen Anwendungsfall zu navigieren. Es entstehen aber auch andere Muster.
00:14:48Es gibt verschiedene Arten von Anwendungsfällen. Einer davon ist
00:14:51die Agent-zu-Agent-Kommunikation. Wenn man also eine große Organisation nimmt und es so viele
00:14:56dieser Teams gibt, die als Grenzen agieren und nicht miteinander sprechen, sagen wir mal,
00:15:02wie kommunizieren wir? Es gibt zwei Agenten auf jeder Seite, richtig? Wie machen wir das?
00:15:07Es gibt also ein A2A-Protokoll, das uns helfen kann, die Verträge hinsichtlich der Fähigkeiten festzulegen,
00:15:14und wir können A2A dort als Protokoll verwenden, das sozusagen eine Grenze zwischen den Teams darstellt.
00:15:22Ja, das A2A-Protokoll.
00:15:29Gut. Wenn wir den Stack durchgehen, wird deutlich, dass sich einige Komponenten des Stacks in einem
00:15:36reifen Zustand befinden und wir bereits gute Antworten dafür haben. Wie ich schon sagte, die Laufzeit ist meiner Meinung nach
00:15:42ziemlich gelöst. Wir sind in der Orchestrierung sehr fortgeschritten und führen LLMs auf eine sehr
00:15:50bruteale Art und Weise aus. Skalierung ist also kein Problem. Speicher ebenfalls. Ich denke, während die modernen LLMs besser werden
00:15:59und unsere Praktiken sich verbessern, werden wir einen Weg finden, die Mehrheit der Anwendungsfälle abzudecken, und es gibt
00:16:06eine gute Reife bei den Cloud-Anbietern. MCP hat sich als De-facto-Protokoll etabliert und Tool-Calling ist
00:16:15mittlerweile eine Funktion, die jeder unterstützt. Wir sehen also auch diesbezüglich eine gewisse Konvergenz in der Branche.
00:16:23Und MCP entwickelt sich als Standard ebenfalls weiter. Es wird nun zustandslos. Wir erreichen einen Punkt,
00:16:29an dem wir wissen, wie man Dienste und Tools mit Agenten aufruft. In einigen Bereichen passiert vieles,
00:16:39aber es gibt immer noch viele Unbekannte rund um die Beobachtbarkeit. Es gibt einen Drang zu Otel, aber
00:16:45funktioniert Otel wirklich für agentische Aufrufe? Ja, man kann es zum Laufen bringen, wie Uday sagte.
00:16:53Außerdem werden wir sicherer im Umgang mit Testmustern. Es ist sehr schwer zu testen,
00:17:00aber wir haben einen Weg gefunden, Kunden hochwertige Erfahrungen zu bieten, selbst trotz der Unzuverlässigkeit agentischer
00:17:07Systeme. Und ich denke, das erreicht einen Zustand, der besser definiert ist. Orchestrierung ist
00:17:15ein weiterer Bereich, in dem wir Muster haben. Wir können größere oder kleinere Agenten bauen. Wie wir zuvor sagten,
00:17:29ist die richtige Antwort wahrscheinlich, es nicht zu überengineering. Wir lernen also dazu und ein Muster
00:17:40zeichnet sich ebenfalls ab. Worunter wir alle leiden – und der vorherige Vortrag handelte davon aus Sicht der
00:17:47KI-gestützten Entwicklung, aber wir sehen diese Probleme auch bei unseren Produktionsagenten –, ist, dass es sehr
00:17:54schwierig ist, die Kosten vorherzusagen, sie zu verwalten, Leitplanken zu setzen und das so zu lösen,
00:18:02dass es einen zuverlässigen Fallback gibt oder Agenten für bestimmte Aufgaben günstigere Modelle nutzen.
00:18:12Das wird im Grunde von den großen KI-Anbietern angetrieben, deren Interesse es meiner Ansicht nach ist, dass wir alle
00:18:20mehr Token ausgeben. Replay und Debugging, Uday hat darüber gesprochen, das ist ebenfalls ein sehr großes Problem. Es ist sehr schwer
00:18:28zu verstehen, aber ich denke, auch das wird gelöst werden, weil wir nun Agenten nutzen können,
00:18:36um die kognitive Überlastung bei dem Versuch zu überwinden, ihr Tun zu debuggen. Und dann Standards. Standards
00:18:46entstehen durch die Community. Otel, wie ich erwähnte, Agent-zu-Agent ist noch jung. Es wird von bestimmten
00:18:55Anbietern vorangetrieben, aber ich denke, mit der Zeit werden wir dorthin gelangen. Nach alledem wissen wir, was wir brauchen,
00:19:04und es liegt an uns, es zu versuchen und zu bauen. Vielen Dank an alle.