Multi-Agent-Workflow mit Roo Code

Bei einem unserer Innovationstage stellte mein Kollege Janek Fellien eine Idee vor, die sich für mich wie folgt anhörte: "Lasst uns ein Multi-Alles-System bauen!" Natürlich hat er das nicht genau so gesagt, aber so ist es in meinem Kopf gelandet - und das war genug, um mich dazu zu bringen, den ganzen Tag mit ihm zu experimentieren, um zu sehen, wie weit wir es bringen können.

Ich beginne diesen Artikel mit der von Janek geschriebenen Einleitung, damit Sie sehen können, wo wir angefangen haben.

Einführung

Die Idee eines Multiagentensystems, bei dem jeder Agent sein eigenes Modell erhält, kam mir, als ich mit einem Freund über sein Softwareprojekt, ein Jump-and-Run-Spiel, sprach. Ich interessiere mich nicht wirklich für das Thema KI und bin der Meinung, dass wir uns noch nicht mitten in der Hype-Phase befinden - daher hat mich das Thema nicht sonderlich berührt. Aber nachdem ich gesehen habe, was mit einem Multi-Agenten-System möglich ist, bin ich selbst auf den Hype hereingefallen.

Und warum? Ganz einfach: Mein Freund zeigte mir im Wesentlichen eine virtuelle Entwicklungsabteilung, die die von ihm beschriebene Arbeit als Eingabeaufforderung in einer für Menschen verständlichen Sprache durchführt. Ein Agent übernimmt die Rolle des Softwarearchitekten und entscheidet, welche Frameworks und Softwarestrukturen verwendet werden sollen. Ein anderer schreibt den Code. Die Ergebnisse werden dann von einem Validator überprüft, Tests werden geschrieben und - besonders spannend - es wird eine Dokumentation erstellt. Darüber hinaus hat er einen Agenten im Einsatz, der YouTube-Videos redaktionell aufbereiten kann, um die einzelnen Features des Spiels in YouTube-Videos zu bewerben. Wie genial ist das denn?

Das alles ist aus der Not heraus entstanden, weil er das Spiel alleine entwickelt und nicht die Zeit hat, sich um jedes Detail zu kümmern. Also begann er, kleine Helfer zu schaffen, die bestimmte Schritte übernehmen. Natürlich funktionierte das nicht von Anfang an reibungslos. Er brauchte zwei Monate, um die Befehlsdateien zu erstellen - die Dateien, die Sie zur Steuerung eines Agenten benötigen. Das Faszinierende daran ist, dass Sie mit diesen Dateien Ihre eigene Art der Softwareentwicklung definieren können. Das finde ich besonders spannend, denn so können Sie Regeln und Prinzipien nach Ihren eigenen Wünschen umsetzen.

Für sein Multi-Agenten-Setup verwendet mein Freund Claude in der CLI. So großartig die Ergebnisse auch sind, Sie sind damit auch eingeschränkt, denn mit Claude können Sie zwar mehrere Modelle verwenden, aber nur sein eigenes - Sonnet, Opus und Haiku. Was aber, wenn ich GPT oder ein anderes Modell verwenden möchte? Genau aus diesem Grund habe ich das Thema "Multi-Agent, Multi-Modell" beim InnoDay in Zürich eingereicht. Was dann geschah, kann am besten Olena erzählen, denn sie hat schließlich die Lösung gefunden.
von Janek Fellien

So sehr ich auch gerne die Lösung gefunden hätte, würde ich sagen, dass wir einfach den Punkt erreicht haben, an dem etwas funktioniert hat. Und genau darüber werde ich in diesem Artikel berichten - wie weit wir gekommen sind und wie die Reise aussah.

Startpunkt: Personas in benutzerdefinierten Chat-Modi

Unser Ausgangspunkt an diesem Tag war ein Gespräch über benutzerdefinierte Chat-Modi in VS Code und wie Sie verschiedene Personas als Teil Ihres Workflows verwenden können. Dieser Ansatz ist sehr gut in einem Artikel unseres Schweizer Kollegen Emanuele Bartolesi beschrieben, "GitHub Copilot: Ein Persona-basierter Ansatz für die Entwicklung in der realen Welt". Hier ist ein Link: https://dev.to/this-is-learning/github-copilot-a-persona-based-approach-to-real-world-development-56ee

In diesem Artikel erklärt er, dass Sie Copilot wie ein Team und nicht wie einen einzelnen Assistenten behandeln sollten. Das Schreiben von aussagekräftigen benutzerdefinierten Anweisungen kann die Ergebnisse Ihres KI-gesteuerten Assistenten erheblich verbessern. Wie Emanuele jedoch auch feststellt, wird Copilot immer wieder die gleichen Fehler machen, wenn Sie bei der Arbeit mit Copilot nicht zu einem eher teamorientierten Ansatz übergehen. Ich empfehle Ihnen dringend, den Artikel zu lesen - aber ich werde den Kerngedanken hier kurz zusammenfassen, damit der Rest des Artikels mehr Sinn ergibt.

Ich überspringe die Details zum Prompt-Engineering und konzentriere mich auf das Hauptkonzept: ein ganzes Team in Ihrer IDE zu haben, das bereit ist, für Sie zu arbeiten. Der Kern dieses Ansatzes besteht darin, benutzerdefinierte Chat-Modus-Dateien mit Beschreibungen der verschiedenen Personas bereitzustellen, die Sie für Ihr Projekt benötigen. Wie im richtigen Leben ist es wichtig, die Rolle und die Verantwortlichkeiten jeder Person klar zu definieren - je strukturierter Ihre Persona-Prompts sind, desto besser funktionieren sie als Teil Ihres Workflows. Und so wie echte Teammitglieder unterschiedliche Fähigkeiten und Fachkenntnisse mitbringen, können benutzerdefinierte Chat-Modi unterschiedliche Tools und sogar unterschiedliche KI-Modelle verwenden.

Das ist nicht nur deshalb so wirkungsvoll, weil es kosteneffizient ist (Sie können das richtige Modell für die richtige Aufgabe verwenden), sondern auch, weil Sie mit wechselnden Modellen je nach Anwendungsfall bessere Ergebnisse erzielen können. Ein Team von Experten ist großartig, aber sie sind nur dann effektiv, wenn sie zusammenarbeiten. Im wirklichen Leben schreiben wir Richtlinien und Standards für Projekte. In der Welt der KI-gesteuerten Assistenten wird diese Konsistenz durch individuelle Anweisungsdateien erreicht. Unabhängig davon, welche Persona aktiv ist, gilt für alle Antworten ein gemeinsamer "gesunder Menschenverstand", der das Durcheinander oder die Zufälligkeit, die sich bei der Arbeit mit KI einschleichen können, reduziert.

Das Ergebnis ist ein intuitiverer und schnellerer Arbeitsablauf. Sie verschwenden keine Zeit damit, Copilot zu erklären, was schief gelaufen ist, wenn er vom Thema abschweift, denn Sie können zu einer Persona wechseln, die sich mehr auf die jeweilige Aufgabe konzentriert. Iterationen werden schneller, und selbst Dinge, die wir oft vergessen, Copilot zu fragen - wie die Überprüfung seines eigenen Codes - können von einer speziellen Persona erledigt werden. Wenn Ihr Projekt wächst, kann Ihr Team von Personas mit ihm wachsen.

Diese Personas funktionierten wirklich gut und entsprachen dem Geist unserer ursprünglichen Idee. Aber wir begannen uns zu fragen: Was wäre, wenn wir das Umschalten selbst automatisieren könnten? Könnte das System statt der manuellen Auswahl eines Chatmodus in VS Code bei Bedarf automatisch den richtigen Modus auswählen? Diese Frage entwickelte sich schnell zu einer größeren Frage: Könnten wir mehrere Agenten oder sogar mehrere Modelle orchestrieren, um verschiedene Teile eines Arbeitsablaufs zu bearbeiten? Wir strebten keine parallele Ausführung oder etwas allzu Futuristisches an, sondern lediglich einen Prototyp mit automatischer Agentenauswahl und Modellwechsel.

Nach einigen Nachforschungen wurde uns klar, dass wir dies mit GitHub Copilot allein nicht so einfach erreichen konnten. Daraufhin schlug Janek vor, ein Tool namens Roo Code auszuprobieren.

Roo Code: Agenten und Modelle orchestrieren

Roo Code ist ein Open-Source-Tool, das die Idee eines ganzen Entwicklerteams von KI-Agenten direkt in Ihren Code-Editor bringt. Zunächst hatten wir die Funktionsweise missverstanden - wir hofften, es würde einfach unsere benutzerdefinierten Chat-Modus-Dateien aufnehmen, sie mit einer Hauptanweisungsdatei (die die Abhängigkeiten und Beziehungen zwischen Rollen und Personas beschreibt) kombinieren und uns auf magische Weise einen automatisierten Multi-Agenten- und Multi-Modell-Workflow liefern. Klingt zu schön, um wahr zu sein, oder?

Wie sich herausstellte, lagen wir nicht völlig falsch. Roo Code funktionierte zwar nicht genau so, aber mit etwas mehr Aufwand bei der Einrichtung und Konfiguration konnten wir erreichen, was wir uns davon versprochen hatten - ein Tool, das KI-Agenten orchestrieren kann.

Auf den ersten Blick ähnelt Roo dem GitHub Copilot: Sie können benutzerdefinierte Modi (Personas) mit eigenen Anweisungen definieren und diese sogar mit verschiedenen Modellen verknüpfen. Der eigentliche Unterschied ist jedoch, dass Roo als Orchestrator fungieren kann. Anstatt nur ein Assistent mit mehreren Persönlichkeiten zu sein, koordiniert er komplexe Aufgaben, indem er sie zum richtigen Zeitpunkt an den richtigen spezialisierten Modus delegiert.

Damit dies funktioniert, müssen Sie entscheiden, welche KI-Modelle Roo verwenden soll. Dies ist Teil der Einrichtung und gibt Ihnen eine Menge Flexibilität. Sie können verschiedene Anbieter einbinden - OpenAI, Anthropic oder sogar lokale Modelle über etwas wie LiteLLM - und ihnen Modi zuweisen, je nachdem, was jeder Modus tun soll. Auf diese Weise können leichtgewichtige Modelle schnelle oder sich wiederholende Aufgaben erledigen, während sich fortgeschrittenere Modelle auf die Planung oder tiefergehende Überlegungen konzentrieren können.

Eine weitere Stärke von Roo Code ist, dass es den Kontext zwischen den verschiedenen Modi im Auge behält. Selbst wenn Arbeit zwischen den Modi weitergegeben wird, sorgt Roo Code durch Indizierung und intelligentes Prompt-Management dafür, dass die Konversation konsistent bleibt. In der Praxis bedeutet dies, dass Sie etwas schaffen können, das sich wie ein koordiniertes Team anfühlt: Jeder Agent hat eine Rolle, sie wissen alle, wie sie miteinander reden müssen, und zusammen können sie komplexere Arbeitsabläufe bewältigen als ein einzelner Assistent im Stil eines Copiloten.

Konfigurationsoptionen

Ich habe bereits LiteLLM erwähnt, das unsere Wahl war - aber Roo Code ist flexibel. Sie sind nicht auf ein Modell oder einen Anbieter festgelegt. Tatsächlich gibt es je nach Ihren Bedürfnissen (Geschwindigkeit, Kosten, Datenschutz) mehrere Möglichkeiten, verschiedene LLMs mit Roo Code zu verbinden.

Laut den Roo Code-Dokumenten und Community-Beiträgen können Sie Roo so konfigurieren, dass es verschiedene KI-Anbieter (OpenAI, Anthropic, Google Gemini usw.) oder sogar lokale/selbstgehostete Modelle verwendet. Einige Tutorials führen Sie durch die Verwendung von OpenRouter als Brücke - Roo sendet API-Aufrufe über OpenRouter, der dann zu vielen verfügbaren Modellen weiterleitet. Es gibt auch fortgeschrittenere Setups, bei denen Sie Unternehmens-Tools wie Portkey integrieren, um Governance, Kostenverfolgung oder Routing-Logik zu handhaben.

In der Praxis wählen Sie in den Einstellungen von Roo (oder über ein Konfigurationsprofil) einen "Anbieter" aus, geben die API-Schlüssel oder Endpunkte an und weisen jedem Modus bestimmte Modelle zu. Diese Flexibilität bedeutet, dass Sie verschiedene Modelle kombinieren können: Vielleicht verwendet Ihr "Architect"-Modus ein leistungsstarkes Argumentationsmodell, während Ihr "Code"-Modus ein schnelles, leichtgewichtiges Modell verwendet.

Allerdings bringt jeder Ansatz Kompromisse mit sich. Fernanbieter bringen Latenz und Kosten pro Token mit sich. Lokale/selbst gehostete Modelle bieten Ihnen mehr Kontrolle und Privatsphäre, sind aber tendenziell langsamer oder erfordern mehr Hardware. Einige Community-Tester haben hybride Konfigurationen oder lokale Bereitstellungen über Ollama ausprobiert, um die Kosten zu senken und gleichzeitig die Kontrolle zu behalten.

Einrichtung und Konfiguration von LiteLLM

Von hier aus führe ich Sie durch unsere LiteLLM-Einrichtung - wie wir sie konfiguriert und welche Schritte wir unternommen haben.

Für unser Setup habe ich ein separates Verzeichnis erstellt, um alles sauber zu halten, und die Befehle ausgeführt, die für die Erstellung der docker-compose und anderer Konfigurationsdateien erforderlich sind.

# Get the code
curl -O https://raw.githubusercontent.com/BerriAI/litellm/main/docker-compose.yml
curl -O https://raw.githubusercontent.com/BerriAI/litellm/main/prometheus.yml

# Add the master key - this can be changed after setup
echo 'LITELLM_MASTER_KEY="sk-1234"' > .env

# Add the litellm salt key - you cannot change this after adding a model
# It is used to encrypt / decrypt LLM API Key credentials
# I used a random hash insted of sk-1234
echo 'LITELLM_SALT_KEY="sk-1234"' >> .env

source .env

# Start
docker-compose up

Sobald das erledigt war, fügte ich eine litellm_config.yaml Datei mit den Definitionen der Modelle hinzu, die ich verwenden wollte. In dieser Konfigurationsdatei teilen Sie LiteLLM mit, mit welchen Anbietern und Modellen es sich verbinden soll. Sie können hier mischen und anpassen - ein Eintrag könnte zum Beispiel auf einen OpenAI GPT-4 Endpunkt verweisen, ein anderer auf Anthropic's Claude und ein weiterer auf ein lokales Modell, das auf Ihrem Rechner läuft. Roo Code wird dann in der Lage sein, diese Modelle über LiteLLM zu verwenden, als ob sie alle Teil desselben Systems wären.

litellm_settings:
  drop_params: true

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: azure/gpt-4o
      api_base: os.environ/AZURE_API_BASE
      api_key: os.environ/AZURE_API_KEY
      api_version: "2025-01-01-preview"

  - model_name: gpt-5-nano
    litellm_params:
      model: azure/gpt-5-nano
      api_base: os.environ/AZURE_API_BASE
      api_key: os.environ/AZURE_API_KEY
      api_version: "2024-12-01-preview"

In meiner Konfigurationsdatei habe ich OpenAI GPT-4o und GPT-5-nano als Modelle eingerichtet. Das bedeutete, dass ich ein KI-Projekt auf Azure benötigte, in dem diese Modelle bereits implementiert waren. Ich habe sie hauptsächlich zu Testzwecken verwendet, aber die Struktur der Datei macht deutlich, dass ich genauso gut auch Modelle von anderen Anbietern hätte hinzufügen können.

Sobald die Konfiguration fertig war, startete ich das Docker-Image und testete, ob die lokale Einrichtung korrekt funktionierte. Für die Werte AI_SERVICE_API_KEY und AI_SERVICE_BASE habe ich die Anmeldedaten von meinen bereitgestellten Azure-Ressourcen verwendet.

docker run \    -v $(pwd)/litellm_config.yaml:/app/config.yaml \
    -e AZURE_API_KEY=AI_SERVICE_API_KEY \
    -e AZURE_API_BASE=https://AI_SERVICE_BASE.services.ai.azure.com/ \
    -p 4000:4000 \
    ghcr.io/berriai/litellm:main-stable \
    --config /app/config.yaml --detailed_debug

Danach habe ich einige Iterationen durchgeführt, um sicherzustellen, dass die Modelle richtig konfiguriert waren. An einem Punkt stieß ich auf ein Problem mit dem Wert api_version für eines der Modelle. Glücklicherweise war die Fehlersuche mit Roo Code ganz einfach. Mit dem unten stehenden Befehl konnte ich einen Gesundheitscheck für meinen Proxy-Server durchführen und das Problem schnell identifizieren.

curl --location 'http://0.0.0.0:4000/health' -H "Authorization: Bearer sk-1234"

Nachdem der Gesundheitscheck bestätigt hatte, dass alle Modelle ordnungsgemäß verbunden waren, habe ich eine kurze Abschlussanfrage gestellt, um zu überprüfen, ob alles funktioniert. Danach ging ich zum nächsten Schritt über: der Konfiguration von Profilen und Anbietern in Roo Code.

Anbieter und Modi-Konfigurationen

Roo Code ist eine VS Code-Erweiterung und die Oberfläche sieht wie folgt aus:

‌

Um die Modelle zu verwenden, die mit Ihrem lokalen Proxy-Server verbunden sind, müssen Sie in die Roo-Code-Einstellungen gehen und eine Provider-Konfiguration hinzufügen. Ich habe zwei Profile mit den Namen Reasoning und Completion erstellt, damit ich leicht unterscheiden kann, welches Profil einem bestimmten Chat-Modus zugewiesen werden soll.

Hier ist ein Beispiel dafür, wie die Profilkonfiguration aussieht: Sie geben den Profilnamen ein und wählen dann den API-Anbieter aus dem Dropdown-Menü. In meinem Fall war es LiteLLM. Danach habe ich einfach auf die URL meines lokal ausgeführten Containers verwiesen und denselben API-Schlüssel hinzugefügt, den ich bei der Konfiguration des Proxy-Servers verwendet habe. Nachdem ich diese Details eingegeben hatte, erschienen meine Modelle in der Dropdown-Liste.

‌

In diesem Stadium konnte ich für jedes eingesetzte Modell ein eigenes Profil erstellen. Der letzte Schritt vor dem Testen bestand darin, diese Profile mit benutzerdefinierten Chat-Modi zu verbinden. Roo Code wird mit vier Standard-Chatmodi geliefert, die Sie unten sehen können:

‌

Um die Einrichtung abzuschließen, ging ich zurück auf die Registerkarte Einstellungen und wählte für jeden Chat-Modus eines der Anbieterprofile im Abschnitt API-Konfiguration aus. Nachdem ich dies für jeden Chat-Modus wiederholt hatte, war die Einrichtung abgeschlossen und bereit zum Testen.

Hinweis: In Roo Code können die Chat-Modi direkt in der IDE konfiguriert werden. Alternativ können Sie auch einen ähnlichen Ansatz wie bei GitHub Copilot wählen, indem Sie für jede Konfiguration eine eigene Chat-Modus-Datei erstellen.

Wie die Orchestrator-Rolle funktioniert

Das war für mich der interessanteste Teil - zu sehen, wie die Orchestrierung in der Praxis funktioniert. Hier finden Sie eine Beschreibung der Orchestrator-Rolle, die standardmäßig in Roo Code enthalten ist:

Sie sind Roo, ein strategischer Workflow-Orchestrator, der komplexe Aufgaben koordiniert, indem er sie an geeignete spezialisierte Modi delegiert. Sie verfügen über ein umfassendes Verständnis der Fähigkeiten und Grenzen der einzelnen Modi, so dass Sie komplexe Probleme effektiv in einzelne Aufgaben aufteilen können, die von verschiedenen Spezialisten gelöst werden können.

Hier geschieht die Magie. Wann immer eine Koordination erforderlich ist, wechselt Roo Code in die Rolle des Orchestrators, der dann entscheidet, was als Nächstes zu tun ist und welcher Modus dafür zuständig ist.

Hier ist die Beschreibung von Roo Code für dieselbe Rolle , wenn Sie sie verwenden:

Verwenden Sie diesen Modus für komplexe, mehrstufige Projekte, die eine Koordination über verschiedene Fachgebiete hinweg erfordern. Ideal, wenn Sie große Aufgaben in Teilaufgaben aufteilen, Arbeitsabläufe verwalten oder Arbeiten koordinieren müssen, die sich über mehrere Bereiche oder Fachgebiete erstrecken.

Endgültiges Ergebnis

Zum Testen habe ich Roo Code gebeten, eine einfache Taschenrechner-App in React zu erstellen, die grundlegende Operationen unterstützt. Nachdem ich meine Anfrage abgeschickt hatte, konnte ich mich einfach zurücklehnen und den Prozess beobachten. Es gab nur dann eine Pause, wenn eine Bestätigung für die Ausführung eines Befehls erforderlich war - zum Beispiel für die Installation von Paketen.

Hier sind einige Screenshots aus der gleichen Sitzung, die zeigen, wie Roo Code zwischen den Rollen wechselt und Anfragen in diesen Rollen bearbeitet.

‌

Wie Sie sehen können, wurde meine Anfrage zunächst in der Rolle Architekt bearbeitet. Nach einer kurzen Weile wechselte es in den Code-Modus:

‌

Fazit

Als ich mich mit Roo Code beschäftigte, konnte ich mir ein besseres Bild davon machen, wie es unter der Haube tatsächlich funktioniert. Der Rollenwechsel ist nicht nur Show - jeder Modus hat seine eigenen Verantwortlichkeiten, und wenn man sieht, wie er zwischen ihnen wechselt, ist der ganze Prozess viel einfacher zu verfolgen.

Interessant finde ich auch, wie die Verbindung zum LLM-Anbieter hergestellt wird, während bei Bedarf Tools und Befehle hinzugezogen werden. Diese Mischung aus Überlegungen und Aktionen sorgt dafür, dass der Arbeitsablauf strukturiert, aber dennoch flexibel ist. Sie können sehen, wann er eine Bestätigung benötigt, wann er auf einer höheren Ebene nachdenkt und wann er einfach nur Code ausführt.

Für mich war der wertvollste Teil einfach die Beobachtung der Mechanismen: wie Anfragen aufgeteilt werden, wie sich Rollen ändern und wie externe Integrationen gehandhabt werden. Es geht weniger um das Endergebnis als vielmehr darum, den Prozess zu verstehen - und da zeigt Roo Code, was es wirklich kann.