Einblick in die Workflow-Engine von HappyRobot

Die HappyRobot-Plattform hilft dabei, Agenten in komplexen Unternehmensumgebungen einzusetzen. Im Kern der Plattform steht unsere Workflow-Engine, die komplexe Workflow-Logik auswertet. Während die Agenten das Gespräch führen und schlussfolgern, definiert die Workflow-Logik die Schritte, Bedingungen und das Agentenverhalten, die jede Interaktion auf Kurs halten – unabhängig davon, wie sich das Gespräch entwickelt. In diesem Blog-Beitrag tauchen wir tief in unseren Workflow-Orchestrator und die zugrunde liegende Engine ein, die alle Workflows auf unserer Plattform antreibt.

Workflow-Editor

Der HappyRobot Workflow-Editor ist ein Low-Code-/No-Code-Ansatz, mit dem unsere Kunden und die Forward Deployed Engineers (FDEs), die sie betreuen, Lösungen für komplexe geschäftliche Anwendungsfälle abbilden können. Der UI-Workflow-Editor ist der wichtigste Weg, auf dem unsere Nutzenden Workflows erstellen. Über die Oberfläche können sie außerdem Ausführungen prüfen, die Agentenausgabe auditieren, A/B-Tests durchführen und vieles mehr.

Der Editor ist zwar der Hauptweg, auf dem unsere Nutzenden bauen, aber nicht der einzige. Jede Operation in der Oberfläche wird von unserer öffentlichen API gestützt, mit einem typisierten TypeScript-SDK (@happyrobot-ai/sdk) obendrauf: Sie können Workflows erstellen, Nodes hinzufügen und konfigurieren, Variablen verwalten, Versionen veröffentlichen und Ausführungen starten – vollständig per Code. Die Low-Code-Erfahrung ist eine Schicht über denselben Primitiven: Teams, die Workflows lieber als Code behandeln, können sie programmatisch erstellen, versionieren und bereitstellen. Die unten beschriebene Engine führt sie in beiden Fällen identisch aus.

Workflow-Darstellung

Mit der äußerst einfachen No-Code-UX, die wir anbieten, können unsere Nutzenden Zehntausende einzigartiger Workflows auf unserer Plattform erstellen. Wie üblich verwenden wir relationale Tabellen für Nodes und Edges, um den Workflow-Graphen abzubilden. Unsere Engine erstellt aus diesen und weiteren Tabellen eine interne Repräsentation, bevor die Ausführung beginnt.

Dieses Datenmodell gibt uns die Möglichkeit, eine stabile „Blaupause“ des Graphen zu behalten und dazu ein Ausführungsmodell derselben Blaupause. In manchen Fällen ist das Ausführungspendant nahezu identisch mit der Blaupause; da wir jedoch code-artige Ausführungsentscheidungen wie Bedingungen, Schleifen (und Breaks) sowie parallele Ausführungen unterstützen, kann ein Ausführungsgraph völlig anders aussehen als seine ursprüngliche Blaupause.

Überblick über den Workflow-Executor

Der Kern unseres Workflow-Executors ist unsere Orchestrierungs-Engine. Immer wenn unsere Nutzenden einen Workflow ausführen, läuft sie im Hintergrund. Eine grobe Skizze, wie unser Ausführungs-Stack einen Workflow End-to-End verarbeitet:

Designprinzip der Engine

Ein Kernprinzip hinter unserer Workflow-Engine ist die strikte Trennung der Verantwortlichkeiten zwischen dem Orchestrator und den ausführbaren Einheiten (den Nodes im Graphen). Die ausführbaren Objekte sind in sich geschlossen, und der Orchestrator hat keinerlei Kenntnis davon, wie sie intern funktionieren. Das ist keineswegs neu – es ist allgemein als Node-Actor-Modell bekannt. Orchestrator und Node-Actors stehen in einer Koordinator-/Worker-Beziehung.

Der Orchestrator besitzt die globale Sicht auf den Workflow-Graphen. Er entscheidet anhand der Abhängigkeitsbereitschaft, welche Nodes ausgeführt werden dürfen. Der Node-Actor besitzt den lokalen Lebenszyklus einer einzelnen Node-Ausführung.

Ein Node-Actor kapselt seine zentralen Graph-Operationen in sich selbst, und die Orchestrierungs-Engine wartet auf die Rückmeldung des Actors, sobald er fertig ist. Ein vereinfachtes Modell des Node-Actors:

Eine zentrale Designentscheidung ist, dass ein Node-Actor dafür verantwortlich ist, den Ausführungsgraphen während seiner Ausführung zu verändern. Genau dieses Verhalten erlaubt es uns, Schleifeniterationen zur Laufzeit des Workflows zu expandieren, ohne dass der Orchestrator die Details kennt. Sobald eine Schleife expandiert ist, führen wir den Graphen einfach wie jede andere Node weiter aus: eine Node nach der anderen.

Workflow-Throttling und System-Schock

Stellen Sie sich einen Workflow vor, der eine Liste mit 10.000 Elementen lädt, über jedes Element iteriert und eine Reihe von Aktionen ausführt. Als Code ist das natürlich trivial:

1for item in items:
2    output = do_foo(item)
3    output2 = do_bar(output)
4    output_3 = do_voice_call(output2)
Copy

Für unsere Engine und unsere Infrastruktur können große Workflows jedoch wirklich schädlich sein, wenn wir nicht aufpassen. Unsere Infrastruktur lässt sich bis zu einem gewissen Grad horizontal skalieren, aber eine zentrale Herausforderung, die auch verantwortungsvolle Skalierung nicht löst, ist der System-Schock. 10.000 Iterationen für sich genommen sind nicht viel, aber sie könnten zu viel sein, wenn wir versuchen, jede Iteration nahezu gleichzeitig mit allen anderen laufenden Workflows zu planen und zu orchestrieren.

Da wir den Schock begrenzen wollen, muss unser Rate Limiting/Throttling zwei Wege berücksichtigen, auf denen ein Workflow unsere Infrastruktur belasten kann:

1. Große Schleifen mit umfangreicher Arbeit im Schleifenkörper: Am obigen Beispiel – wir haben in der Engine selbst Rate Limiter eingebaut, die die Ausführung jeder Iteration drosseln. In unseren Skalierungsexperimenten hat sich das als einfach, aber äußerst wirksam erwiesen, um System-Schock zu reduzieren. Horizontale Skalierung kann höheren Durchsatz weiterhin abfangen, ohne dass unsere Infrastruktur kollabiert
2. Große Anzahl unabhängiger Workflow-Ausführungen: Unsere Nutzenden haben API-Zugriff, um Workflows zu starten. Unser API-Limiter hat zwei Stellschrauben: die Anzahl der Workflows, die eine Nutzerin oder ein Nutzer pro Sekunde starten kann, und die Anzahl der gleichzeitig laufenden Workflows. Der Rate Limiter für Aufrufe pro Sekunde verteilt den System-Schock, und der Concurrency-Limiter stellt sicher, dass kein Client die Ressourcen der Plattform monopolisiert

Sprachanrufe

Das High-Level-Diagramm zeigt, wie jede Node in unserem Graphen sequenziell ausgeführt wird. Das bedeutet auch: Sobald eine Node ausgeführt wurde, versucht unsere Engine sofort, die nächste auszuführen – wie unterstützen wir dann aber Sprachanrufe in unseren Workflows? Nehmen wir an, wir wollen einen Anruf abschließen, bevor wir zur nächsten Node übergehen.

Unsere Voice-Service-Pods sind zustandsbehaftete Services, wobei jeder Pod bis zu 200 Sprachanrufe gleichzeitig verarbeiten kann. Jeder Anruf wird als Goroutine innerhalb des Pods verwaltet. Unsere Voice-Agenten führen mitunter 30- bis 60-minütige Telefonanrufe mit Menschen, unterstützen Weiterleitungen zwischen Parteien und erlauben es den Agenten, die den Anruf annehmen, benutzerdefinierte Tools auszuführen, die von den Workflow-Erstellenden gebaut wurden. Wir unterstützen außerdem Nodes in unseren Workflows nach Voice-Agenten (z. B. den Anruf analysieren, API-Aufrufe tätigen, Daten speichern, Folgeaufgaben starten). All das heißt: Wir brauchen eine Möglichkeit, den Workflow zu „pausieren“, bis ein Sprachanruf beendet ist, und sicherzustellen, dass der Voice-Agent jederzeit auf den Zustand des Workflows zugreifen kann, um zu wissen, was bereits ausgeführt wurde und welche Tools ihm zur Verfügung stehen.

Wie machen wir das also? Kurz gesagt nutzen wir Signale – eine Kommunikationsschicht zwischen dem Orchestrator-Pod und einem Voice-Agent-Pod. Wenn wir einen Sprachanruf in einem Pod starten, erlaubt uns die Zustandsbehaftung des Anrufs, die workflowspezifischen Informationen in der Voice-Session zu speichern. Der Session-Handler im Voice-Pod nutzt diese Workflow-Informationen, um Signale zu Tool-Aufrufen, Session-Abschluss, Weiterleitungen, Anrufstatus und mehr an den Worker der Orchestrierungs-Engine zurückzumelden. Ein vereinfachtes Interaktionsdiagramm:

Fazit

Die HappyRobot Workflow-Engine entstand aus einer Kombination von ereignisgesteuerter Architektur (z. B. Signale) und strikter Trennung der Systemverantwortlichkeiten. Dadurch können wir äußerst komplexe Geschäftslogik in einer No-Code-Plattform abbilden und sie dennoch als Code ausführen, um Aufgaben und Aktionen in großem Umfang zu erledigen. Die Engine entwickelt sich weiter, und wir ergänzen laufend neue Features und Fähigkeiten, um die Plattform von einem Workflow-Executor zu einem wirklich verteilten Workflow-Operations-System auszubauen.