Von statisch zu adaptiv: Ein dynamisches Agenten-Orchestrierungssystem auf Basis eines geteilten Arbeitsbereichs

Cockpit-Architektur und plattformübergreifender Agenten-Kollaborationsmodus

📌 Kernzusammenfassung

Mit der Verbesserung der Fähigkeiten großer Sprachmodelle (LLMs) haben einzelne Agenten bei der Bearbeitung komplexer, langfristiger Aufgaben inhärente Einschränkungen wie agentische Trägheit, selbstbevorzugende Verzerrung und Zielabweichung offenbart.

Die von Claude Code vorgeschlagenen dynamischen Workflows lösen diese Probleme durch Multi-Instanz-Isolation und aufgabenspezifische Orchestrierung, aber ihre Einzelmodellfamilie und zustandslose Orchestrierung schränken die praktischen Anwendungsszenarien ein.

Dieser Artikel schlägt die Cockpit-Architektur vor – ein adaptives Agenten-Orchestrierungssystem, das auf einem gemeinsamen Arbeitsbereich basiert. Diese Architektur führt ein:

• 🎯 Zentrale Zustandsverwaltungsschicht (Cockpit)
• 🧠 Intelligenter Koordinator (PM)
• 🤖 Heterogener Agentenpool (Worker Pool)

Unter Beibehaltung der Kernvorteile dynamischer Workflows wird eine plattformübergreifende Agenten-Kollaboration und adaptive Optimierung basierend auf historischer Leistung erreicht.

Die Praxis zeigt, dass die Cockpit-Architektur bei komplexen Aufgaben wie Code-Migration und tiefergehender Recherche höhere Aufgabenerfüllungsraten und bessere technische Kontrollierbarkeit aufweist.

Schlüsselwörter

: Dynamischer Workflow · Agenten-Orchestrierung · Gemeinsamer Arbeitsbereich · Adaptives System · Plattformübergreifende Kollaboration

01 Einleitung: Vom Dilemma zum Durchbruch

🔴 Drei Dilemmata des Einzelkontexts

In praktischen KI-Agenten-Anwendungen verfolgen Entwickler normalerweise den direktesten Ansatz: Sie lassen Claude, GPT oder andere LLMs Aufgaben in einem einzigen Konversationsfenster erledigen.

Dieser Modus funktioniert gut für einfache Szenarien, aber wenn Aufgaben komplex werden – das Durchsehen von 50 Dateien, die Migration einer gesamten Codebasis oder die Durchführung tiefergehender Recherchen – zeigt der Einzelkontextmodus systemische Probleme.

Die Veröffentlichungsdokumentation von Anthropic für dynamische Claude Code-Workflows weist explizit auf drei Fehlermodi hin:

💤 Agentische Trägheit

Der Agent erklärt die Aufgabe vorzeitig für abgeschlossen, nachdem er nur einen Teil der Arbeit erledigt hat.

Typisches Szenario: Bei einem Sicherheitsaudit verarbeitet er 20 von 50 Punkten und markiert den Rest als "bearbeitet".

🎭 Selbstbevorzugende Verzerrung

Wenn ein Agent gebeten wird, seine eigene Ausgabe zu überprüfen, neigt er dazu, seine eigenen Ergebnisse zu bevorzugen.

Kernproblem: Ein Prüfer, der ein Interesse am Ergebnis hat, kann kein unparteiischer Richter sein.

🌊 Zielabweichung

Bei mehreren Interaktionen, insbesondere nach der Kontextkomprimierung, weicht der Agent allmählich vom ursprünglichen Ziel ab.

Realer Fall: Die Einschränkung "mache X nicht" verschwindet in der 47. Gesprächsrunde stillschweigend.

🟢 Das Versprechen dynamischer Workflows

Um diese Probleme zu lösen, hat Anthropic im Mai 2026 die Funktion Dynamische Workflows eingeführt.

Kernidee: Claude lässt automatisch ein maßgeschneidertes Koordinationsframework für eine bestimmte Aufgabe generieren – eine JavaScript-Datei, die mehrere Unter-Agenten durch spezielle Funktionen generiert und koordiniert, wobei jeder Unter-Agent ein unabhängiges Kontextfenster und fokussierte Ziele hat.

Drei Schlüsselfähigkeiten

✅ Isolation pro Agent: Jeder Unter-Agent hat einen unabhängigen Kontext, der Interferenzen verhindert.

✅ Modellauswahl pro Agent: Verwenden Sie Opus für komplexes Denken und Haiku für kostengünstige Erkundungen.

✅ Isolationsstufe pro Agent: Arbeitsbaum (unabhängiger Git-Checkout) oder entferntes Repository.

Sechs Kernmuster

Anthropic-Ingenieure haben sechs wiederkehrende Orchestrierungsmuster zusammengefasst:

• 🔀 Klassifizieren und Weiterleiten
• 🌟 Aufteilen und Synthetisieren
• ⚔️ Adversarielle Verifikation
• 🎯 Generieren und Filtern
• 🏆 Turnier-Ranking
• 🔄 Schleife bis zur Fertigstellung

Diese Muster lösen strukturell die Fehlermodi eines einzelnen Kontexts.

▲ Drei Fehlermodi des Einzelkontexts: Agentische Trägheit, Selbstbevorzugende Verzerrung, Zielabweichung

🟡 Die Lücke zwischen Theorie und Ingenieurspraxis

Dynamische Workflows stehen jedoch in der praktischen technischen Anwendung vor zwei wesentlichen Einschränkungen:

⚠️ Einschränkung der Einzelmodellfamilie

Dynamische Workflows können nur Modelle der Claude-Familie (Opus/Sonnet/Haiku) verwenden.

In realen Szenarien haben Agenten verschiedener Plattformen unterschiedliche Stärken:

• Claude Code zeichnet sich durch Code-Refactoring aus
• Codex ist hervorragend in der Algorithmusimplementierung
• Gemini hat Vorteile bei multimodalen Aufgaben

Eine einzelne Modellfamilie kann das Fachwissen verschiedener Plattformen nicht voll ausschöpfen.

⚠️ Zustandslose Orchestrierung

Jede Aufgabe generiert ein brandneues Workflow-Skript; es gibt keine historische Erinnerung zwischen den Agenten.

Probleme:

• Unfähigkeit, Agentenauswahlstrategien basierend auf vergangener Leistung zu optimieren
• Unfähigkeit, Wissen zwischen Aufgaben anzuhäufen
• Jedes Mal "bei Null anfangen"

💡 Cockpit-Architektur: Eine Lösung zur Überbrückung der Lücke

Die in diesem Artikel vorgeschlagene Cockpit-Architektur soll diese Lücke schließen.

Wir behalten die Kernvorteile dynamischer Workflows bei:

• ✅ Multi-Instanz-Isolation
• ✅ Dynamische Orchestrierung

Während wir neue Fähigkeiten einführen:

• 🆕 Gemeinsamer Arbeitsbereich
• 🆕 Adaptiver Mechanismus
• 🆕 Plattformübergreifende Kollaboration

Erreichen einer flexibleren und intelligenteren Agenten-Kollaborationsweise.

02 Überprüfung der Theorie dynamischer Workflows

Statisch vs. Dynamisch: Ein Vergleich zweier Paradigmen

Bevor wir dynamische Workflows verstehen, ist es notwendig, das Konzept der statischen Workflows zu klären.

🔵 Statischer Workflow: Vordefinierte feste Prozesse

Unabhängig davon, ob Sie visuelle Automatisierungsplattformen wie N8N oder Zapier oder mit dem Claude Agent SDK geschriebene Koordinationsskripte verwenden, sind die Merkmale:

Beispiel: Ein in N8N entworfener "Code-Review-Workflow"

1Code extrahieren → Claude zur Analyse aufrufen → Ergebnisse speichern → Benachrichtigung senden

Der Prozess ist derselbe, unabhängig davon, welcher Code überprüft wird.

🟣 Dynamischer Workflow: Aufgabenspezifische Ausführungspläne

Ein von Claude für die aktuelle Aufgabe maßgeschneiderter Ausführungsplan:

Beispiel: Für dieselbe Code-Überprüfung könnte ein dynamischer Workflow:

1. Zuerst die Codebasis scannen, um sie als React-Projekt zu identifizieren
2. Basierend auf der Komponentenkomplexität entscheiden, ob Haiku oder Opus verwendet werden soll
3. Einen spezialisierten Review-Agenten für die Hooks-Nutzung generieren
4. Einen Schritt zur TypeScript-Typüberprüfung hinzufügen
5. Parallel statt sequentiell verarbeiten

Detaillierte Erklärung der sechs Kernmuster

Anthropic-Ingenieure haben in der Praxis sechs wiederkehrende Orchestrierungsmuster zusammengefasst:

1️⃣ Klassifizieren und Weiterleiten

Verwenden Sie einen Klassifizierungsagenten, um den Aufgabentyp zu bestimmen, und leiten Sie ihn dann an verschiedene Verarbeitungsagenten weiter.

Szenario: "Erklären Sie, wie das Authentifizierungsmodul funktioniert"

• Der Klassifizierungsagent bewertet zuerst die Komplexität
• Einfache Module verwenden Sonnet
• Komplexe Module verwenden Opus

2️⃣ Aufteilen und Synthetisieren

Zerlegen Sie eine Aufgabe in mehrere unabhängige Unteraufgaben, führen Sie sie parallel aus und aggregieren Sie schließlich die Ergebnisse.

Kernwert: Löst das Problem "zu vieles auf einmal". Jeder Unter-Agent sieht nur seinen eigenen Teil und wird nicht von 50 irrelevanten Details abgelenkt.

💡

Dies ist das am häufigsten verwendete Muster

3️⃣ Adversarielle Verifikation

Erstellen Sie für jedes generierte Ergebnis einen unabhängigen Verifikationsagenten. Dieser Prüfer hat die ursprüngliche Arbeit nie gesehen und kann keine selbstbevorzugende Verzerrung erzeugen.

Strukturelle Lösung: Die grundlegende Methode zur Lösung selbstbevorzugender Verzerrung.

4️⃣ Generieren und Filtern

Generieren Sie mehrere Kandidatenlösungen und filtern Sie diese dann mit einem Prüfer.

Hauptunterschied: Im Gegensatz zur direkten Frage nach der "besten Antwort" ermöglicht dieses Muster dem Agenten, die Entscheidung hinauszuzögern, und trifft eine Entscheidung erst, nachdem alle Optionen in Frage gestellt wurden.

5️⃣ Turnier-Ranking

Lassen Sie mehrere Agenten um dieselbe Aufgabe konkurrieren und bestimmen Sie den Gewinner durch paarweise Vergleiche.

Anwendbares Szenario: Geschmacksorientierte Arbeit

• Designentscheidungen
• Namensgebung
• UI-Entscheidungen

Kernvorteil: Vergleichende Beurteilung ist zuverlässiger als absolute Bewertung.

6️⃣ Schleife bis zur Fertigstellung

Generieren Sie kontinuierlich Agenten, bis eine Abbruchbedingung erfüllt ist.

Beispiele für Abbruchbedingungen:

• Keine neuen Entdeckungen
• Keine Fehler in den Protokollen
• Theorie verifiziert

Garantie: "Wirklich abgeschlossen" statt "behauptet abgeschlossen".

▲ Sechs Kern-Orchestrierungsmuster: Klassifizieren und Weiterleiten, Aufteilen und Synthetisieren, Adversarielle Verifikation, Generieren und Filtern, Turnier-Ranking, Schleife bis zur Fertigstellung

Einschränkungen bestehender Lösungen

Obwohl dynamische Workflows theoretisch elegant sind, haben sie in der Ingenieurspraxis vier große Mängel:

Kernfrage: Können wir eine Architektur entwerfen, die die Vorteile der dynamischen Orchestrierung beibehält und gleichzeitig technische Kontrollierbarkeit besitzt?

03 Cockpit-Architekturdesign

Systemübersicht: Drei-Schichten-Architektur

Die Cockpit-Architektur verwendet ein Drei-Schichten-Design:

1┌─────────────────────────────────────────┐
2│      Cockpit (Gemeinsame Arbeitsschicht) │
3│  ┌──────┬──────┬──────────────────┐    │
4│  │ Plan │ Tasks│ Forschung        │    │
5│  │ Ziel │ Fort │ Forschung        │    │
6│  ├──────┼──────┼──────────────────┤    │
7│  │Berichte│Probleme│ Wissensdatenbank│    │
8│  │ Bericht│ Problem│ Wissensdatenbank│    │
9│  └──────┴──────┴──────────────────┘    │
10└─────────────────────────────────────────┘
11              ↕️ Lese-/Schreibzugriff
12┌─────────────────────────────────────────┐
13│         PM (Koordinationsschicht)        │
14│  • Aufgabenzerlegung                     │
15│  • Worker-Auswahl (Hist. Leistung)       │
16│  • Fortschrittsüberwachung               │
17│  • Planpflege                            │
18└─────────────────────────────────────────┘
19         ↕️ Aufgabenverteilung & Ergebnisabholung
20┌─────────────────────────────────────────┐
21│      Worker Pool (Ausführungsschicht)    │
22│  ┌────────┬────────┬──────────────┐    │
23│  │ Claude │ Codex  │ Gemini       │    │
24│  │ Code   │ Agent  │ Agent        │    │
25│  └────────┴────────┴──────────────┘    │
26│       ↕️ Aufgabenstatus an Cockpit aktualisieren│
27└─────────────────────────────────────────┘

▲ Cockpit-Drei-Schichten-Architektur: Gemeinsame Arbeitsschicht, PM-Koordinationsschicht, Worker-Ausführungsschicht

Kernentwurfsidee: Alle Agenten arbeiten um dasselbe "Whiteboard" (Cockpit) herum, anstatt durch Nachrichtenübermittlung zu kollaborieren.

💡

Ähnlich wie ein Softwareteam, das um ein Git-Repository + Projektboard herum zusammenarbeitet, anstatt sich gegenseitig E-Mails zu schicken.

Cockpit-Komponentendesign: Sechs Kernkomponenten

Das Cockpit ist das Nervenzentrum des Systems und enthält sechs Kernkomponenten.

Unten ist die Cockpit-Oberfläche im tatsächlichen Betrieb:

▲ Cockpit-Planansicht – Zeigt Projektziele und Meilensteinfortschritt

▲ Cockpit-Aufgabenansicht – Echtzeitverfolgung des Aufgabenerfüllungsstatus

▲ Cockpit-Zeitachsenansicht – Worker-Auslastungsanalyse und Dispatch-Trends

📋 Plan (Zielverankerung)

Funktion:

• Speichert die Kernprojektziele und -einschränkungen
• Alle Agenten müssen den Plan lesen, um die Ziele vor der Ausführung abzugleichen

Wert: Verhindert Zielabweichung – selbst nach mehreren Interaktionsrunden bleibt die ursprüngliche Absicht klar.

Tatsächliche Daten: Aus dem Screenshot geht hervor, dass der Fortschritt des HippoTeam-Projekts 89% (187/209) beträgt, einschließlich 6 Meilensteinen von M1-M6, jeder mit einem klaren Erfüllungsstatus.

✅ Tasks (Fortschrittsverfolgung)

Funktion:

• Zeichnet den Status aller Unteraufgaben auf: Ausstehend, In Bearbeitung, Abgeschlossen
• Worker aktualisieren den Status nach Abschluss der Aufgaben
• PM passt die nachfolgende Orchestrierung basierend auf dem Echtzeitstatus an

Wert: Löst "agentische Trägheit" – der Aufgabenerfüllungsstatus ist auf einen Blick klar und verhindert Falschmeldungen.

Tatsächliche Daten: Es gibt 408 Aufgaben im tatsächlichen Betrieb, mit einer Erfüllungsrate von 401/408, und detaillierte Dispatch-Aufzeichnungen sind sichtbar.

🔬 Research (Forschungsakkumulation)

Funktion:

• Speichert während des Forschungsprozesses gesammelte Informationen
• Für alle Agenten zugänglich, um redundante Forschung zu vermeiden

Wert: Unterstützt Wiederverwendung von Wissen und iterative Vertiefung.

Tatsächliche Daten: Es gibt derzeit 71 Forschungsaufzeichnungen im System.

📊 Reports (Ergebnisverwaltung)

Funktion:

• Speichert Ausgabeergebnisse aus jeder Phase
• Unterstützt Versionsverfolgung und Rückverfolgung

Wert: Erleichtert die endgültige Aggregation und Qualitätsprüfung.

Tatsächliche Daten: 78 Berichte wurden im System angesammelt.

⚠️ Issues (Problemverwaltung)

Funktion:

• Zeichnet während der Ausführung entdeckte Probleme auf
• Jeder Agent kann ein Issue hinzufügen

Wert: PM passt Strategien an oder weist Reparaturaufgaben basierend auf Issues zu.

📚 Knowledge Base (Wissensdatenbank)

Funktion:

• Wissensakkumulation über Aufgaben hinweg
• Zeichnet Betriebsstatistiken der Worker auf

Wert: Bietet eine Datenbasis für menschliche Analysen und zukünftige adaptive Optimierung.

Tatsächliche Implementierung: Zeichnet die historische Leistung der Worker über die Zeitachsenansicht auf. Aus dem Screenshot sind detaillierte Daten für Guan Yu (55 Dispatches, Ø 12 Min), Zhao Yun (21 Dispatches, Ø 10 Min), Dian Wei (20 Dispatches, Ø 10 Min) und Zhang Fei (4 Dispatches, Ø 7 Min) sowie Dispatch-Trenddiagramme vom 20.05. bis 25.05. ersichtlich. Diese Daten werden derzeit für die Überwachung und menschliche Analyse verwendet und können in Zukunft zum Aufbau automatischer Rückkopplungsschleifen genutzt werden.

💡

Ergänzende Komponenten: Das tatsächliche System enthält auch Hilfsmodule wie Ideas (Ideenpool, 4 zur Bewertung ausstehend) und Decisions (Entscheidungsaufzeichnungen, 24), die fortgeschrittene Muster wie "Generieren und Filtern" unterstützen.

Datenfluss und Interaktionsmechanismus

Bevor wir uns mit dem PM-Orchestrierungsmechanismus befassen, wollen wir den Datenfluss zwischen Agenten und dem Cockpit verstehen.

🔄 Datenflussdiagramm Agent-Cockpit

▲ Vollständiger Datenfluss zwischen Agent und Cockpit

Kerninteraktionspfad:

Schlüsseldesign:

• ✅ Einwegabhängigkeit: Worker sind vom Cockpit abhängig, kommunizieren aber nicht direkt mit dem PM oder anderen Workern.
• ✅ Zentralisierter Zustand: Alle Zustandsänderungen durchlaufen das Cockpit und gewährleisten so globale Konsistenz.
• ✅ Asynchrone Entkopplung: Worker aktualisieren einfach ihren Status nach Abschluss einer Aufgabe, ohne auf eine PM-Antwort zu warten.

🔒 Zustandssynchronisationsmechanismus für gleichzeitigen Zugriff

Wenn mehrere Worker gleichzeitig auf das Cockpit zugreifen, wie wird die Datenkonsistenz gewährleistet?

▲ Zustandssynchronisationsmechanismus für gleichzeitigen Zugriff mehrerer Worker

Dreischichtiger Garantiemechanismus:

1️⃣ Optimistische Sperre

Jede Cockpit-Komponente führt eine Versionsnummer:

1Tasks v1 → Worker A liest
2Tasks v1 → Worker B liest
3
4Worker A reicht Update ein → prüft Version v1 → Erfolg → Tasks v2
5Worker B reicht Update ein → prüft Version v1 → Konflikt erkannt → Automatischer Wiederholungsversuch

Vorteil: In den meisten Fällen sperrenfrei, hohe Leistung.

2️⃣ Transaktionswarteschlange

Alle Schreiboperationen werden in eine Warteschlange gestellt und sequentiell ausgeführt:

1Worker #1: Task-001-Status aktualisieren → Warteschlangenposition 1
2Worker #2: Report-042 schreiben → Warteschlangenposition 2
3Worker #3: Issue-015 hinzufügen → Warteschlangenposition 3
4Worker #4: Task-002-Status aktualisieren → Warteschlangenposition 4

Garantie: Atomizität und Reihenfolge der Schreiboperationen.

3️⃣ Konflikterkennung und automatischer Wiederholungsversuch

Wenn ein Versionskonflikt erkannt wird:

1. Rollback: Das aktuelle Update verwerfen.
2. Erneutes Lesen: Den neuesten Zustand abrufen.
3. Neuberechnung: Das Update basierend auf dem neuen Zustand neu generieren.
4. Erneutes Einreichen: Erneut versuchen zu schreiben.

Tatsächlicher Fall:

Worker A und Worker B schließen Task-001 und Task-002 gleichzeitig ab und versuchen beide, die Abschlussratenstatistik in der Tasks-Komponente zu aktualisieren.

- Worker A reicht zuerst ein, Tasks aktualisiert von v5 auf v6, Abschlussrate 400/408.

- Worker B stellt bei der Einreichung fest, dass sich die Version auf v6 geändert hat (nicht die v5, die er gelesen hat).

- Das System veranlasst Worker B automatisch, v6 erneut zu lesen und die Abschlussrate auf 401/408 neu zu berechnen.

- Worker B reicht erfolgreich ein, Tasks aktualisiert auf v7.

Leistungsoptimierung:

• 🟢 Sperrenfreie Leseoperationen: Mehrere Worker können gleichzeitig lesen, ohne sich gegenseitig zu blockieren.
• 🟡 Leichte Schreiboperationen: Die meisten Updates sind Anhängeoperationen (Hinzufügen von Berichten, Issues), daher ist die Konfliktwahrscheinlichkeit gering.
• 🔴 Seltene Konflikte: Konflikte treten nur auf, wenn derselbe Aufgabenstatus gleichzeitig aktualisiert wird, mit einer tatsächlichen Auftrittsrate von < 2%.

PM-Adaptiver Orchestrierungsmechanismus

Der PM (Projektmanager) ist das Gehirn des Systems, verantwortlich für die dynamische Orchestrierung.

Im Gegensatz zur zustandslosen Orchestrierung dynamischer Claude-Workflows besitzt der Cockpit-PM Gedächtnis und Lernfähigkeiten.

🧩 Aufgabenzerlegung

Prozess:

1. Nach Erhalt der Benutzeranforderungen analysiert der PM die Aufgabenmerkmale.
2. Liest historische Daten und den aktuellen Kontext aus dem Cockpit.
3. Zerlegt die Aufgabe in parallele oder serielle Unteraufgaben.
4. Aktualisiert die Plan- und Tasks-Komponenten.

🎯 Rollenbasierte Worker-Auswahl

Der PM führt eine intelligente Zuweisung basierend auf dem Aufgabentyp und den Worker-Rollen durch:

Entscheidungsprozess:

11️⃣ Aufgabentyp identifizieren
2   Code-Refactoring / Algorithmusimplementierung / Code-Review / Multimodale Analyse
3
42️⃣ Rollenvoreinstellung zuordnen
5   Coder / Tester / Reviewer / Researcher
6
73️⃣ Explizite Benutzerzuweisung berücksichtigen
8   Bestimmte Aufgaben, die bestimmten Workern zugewiesen sind
9
104️⃣ Aktuelle Auslastung berücksichtigen
11   Aktuelle Aufgabenanzahl und Verfügbarkeit des Workers

Tatsächlicher Betriebsfall:

Aus den tatsächlichen Betriebsdaten von HippoTeam können wir ersehen:

Code-Refactoring-Aufgaben

→ Workern mit der Coder-Rolle zugewiesen (Guan Yu, Zhao Yun, Dian Wei)

Code-Review-Aufgaben

→ Unabhängigen Reviewer-Rollen zugewiesen (Zhong Kui), um adversarielle Verifikation sicherzustellen

Algorithmusimplementierungsaufgaben

→ Basierend auf der Komplexität wird ein geeigneter Coder-Worker ausgewählt

Zeitachsenüberwachung: Das System zeichnet die Dispatch-Anzahl und die durchschnittliche Bearbeitungszeit für jeden Worker (z. B. Guan Yu 55 Mal/Ø 12 Min, Zhao Yun 21 Mal/Ø 10 Min) über die Zeitachsenansicht auf, was die menschliche Analyse und die Anpassung der Rollenkonfiguration erleichtert.

💡

Zukünftige Richtung: Aktuelle Zeitachsendaten dienen der Anzeige; in Zukunft kann eine Rückkopplungsschleife eingerichtet werden, damit der PM die Worker-Auswahlstrategien basierend auf der historischen Leistung automatisch optimieren kann.

📈 Fortschrittsüberwachung und dynamische Anpassung

Echtzeitfähigkeiten:

• Echtzeit-Lesen des Tasks-Status.
• Wenn ein Worker längere Zeit nicht reagiert, die Aufgabe neu zuweisen.
• Wenn ein blockierendes Problem in Issues auftaucht, den Ausführungsplan anpassen.

Worker-Pool-Design

Der Worker-Pool ist die Ausführungsschicht des Systems und enthält mehrere heterogene Agenten.

🌐 Plattformübergreifende heterogene Agenten

Im Gegensatz zu dynamischen Claude-Workflows, die nur die Claude-Familie verwenden können, unterstützt Cockpit Agenten von jeder Plattform:

Jede Plattform kann mehrere Instanzen haben (z. B. Claude Code #1, #2, #3), was eine echte Parallelverarbeitung ermöglicht.

⚖️ Feste Rollen vs. Dynamische Verantwortlichkeiten

Dies ist ein wichtiger technischer Kompromiss.

Cockpit verwendet einen Modus "Fester Rollenpool + Dynamische Verantwortungszuweisung":

✅ Feste Rollen: Worker-Fähigkeitsgrenzen sind vordefiniert (Claude Code ist ein Code-Experte, Gemini ist ein multimodaler Experte).

✅ Dynamische Verantwortlichkeiten: Spezifische Aufgaben werden vom PM dynamisch basierend auf der Situation zugewiesen.

Designvorteile:

🔄 Zustandsaktualisierungsprotokoll

Nach Abschluss einer Aufgabe muss ein Worker das Cockpit aktualisieren:

• ✅ Aufgabenstatus in Tasks aktualisieren.
• 📄 Ergebnisse in Reports schreiben.
• ⚠️ Ein Issue hinzufügen, wenn ein Problem gefunden wird.
• 📚 Akkumuliertes Wissen in Research schreiben.

Dies gewährleistet Konsistenz und Rückverfolgbarkeit des Systemzustands.

▲ Plattformübergreifende heterogene Agenten, die um einen gemeinsamen Arbeitsbereich herum zusammenarbeiten

Implementierung der sechs Muster im Cockpit

Die Cockpit-Architektur ist vollständig kompatibel mit den sechs Mustern dynamischer Claude-Workflows und verbessert deren Implementierung:

🔀 Klassifizieren und Weiterleiten

Implementierung:

• PM fungiert als Klassifikator und wählt basierend auf Aufgabenmerkmalen den geeigneten Worker aus.

Verbesserung:

• Im Gegensatz zum ursprünglichen Muster basiert die Klassifikationsentscheidung des PM auf historischen Daten und ist daher genauer.

🌟 Aufteilen und Synthetisieren

Implementierung:

• PM zerlegt die Aufgabe und weist sie mehreren Workern zur parallelen Ausführung zu.
• Alle Worker schreiben Ergebnisse in Reports im Cockpit.
• PM liest alle Ergebnisse und führt Aggregation und Synthese durch.

⚔️ Adversarielle Verifikation

Implementierung:

• PM weist jeder Generierungsaufgabe einen unabhängigen Verifikationsworker zu.
• Der Verifikationsworker liest nur Ergebnisse aus Reports und weiß nicht, wer sie generiert hat.
• Verifikationsergebnisse werden in Issues geschrieben, und der PM entscheidet basierend auf Issues, ob eine Wiederholung erforderlich ist.

🎯 Generieren und Filtern

Implementierung:

• PM weist mehrere Worker zur Generierung von Kandidatenlösungen zu.
• Weist dann Verifikationsworker zu, um zu filtern und zu bewerten.
• Die optimale Lösung wird in Reports geschrieben.

🏆 Turnier-Ranking

Implementierung:

• PM organisiert paarweise Vergleiche und weist jedes Mal zwei Vergleichsaufgaben Workern zu.
• Vergleichsergebnisse werden im Cockpit aufgezeichnet, und der PM pflegt das Ranking.
• Der endgültige Gewinner wird in Reports geschrieben.

🔄 Schleife bis zur Fertigstellung

Implementierung:

• PM überprüft den Status von Tasks und Issues.
• Solange es unerledigte Aufgaben oder ungelöste Issues gibt, werden weiterhin Worker zugewiesen.
• Bis alle Tasks als abgeschlossen markiert sind und Issues leer sind.

04 Wichtige Designentscheidungen

Warum ein fester Rollenpool?

Beim Entwurf des Cockpits standen wir vor einer Kernfrage:

Sollten wir jedes Mal temporär Agenten generieren wie bei dynamischen Claude-Workflows oder einen festen Agentenpool unterhalten?

Wir haben uns aus folgenden Gründen für Letzteres entschieden:

💰 Kostenkontrollierbarkeit

Das temporäre Generieren von Agenten kann zu unkontrollierten Kosten führen.

Risikoszenario: Bei einer komplexen Aufgabe könnte das System ohne Begrenzung Dutzende oder sogar Hunderte von Agenteninstanzen generieren.

Lösung: Ein fester Rollenpool setzt eine Parallelitätsgrenze und macht die Kosten vorhersagbar.

🛠️ Technische Stabilität

Feste Rollen bedeuten, dass die Fähigkeitsgrenzen jedes Agenten klar sind, was Folgendes erleichtert:

• Überwachung
• Fehlersuche
• Optimierung

Vergleich: Temporär generierte Agenten sind schwer zu verfolgen und bei Problemen schwer zu lokalisieren.

🌐 Plattformübergreifende Vorteile

Ein fester Rollenpool ermöglicht es uns, Agenten von verschiedenen Plattformen zu integrieren und ihre jeweiligen Stärken zu nutzen.

Einschränkung: Temporäre Generierungsmodi sind schwer plattformübergreifend zu koordinieren.

📊 Grundlage für adaptives Lernen

Nur mit festen Rollen können historische Leistungsdaten für jeden Agenten akkumuliert werden, was eine intelligente Zuweisung basierend auf der Leistung ermöglicht.

Dies bedeutet nicht, dass Flexibilität verloren geht

Der PM kann dennoch dynamisch entscheiden:

• ✅ Wem diese Aufgabe zugewiesen wird.
• ✅ Wie viele Worker für die Parallelverarbeitung verwendet werden.
• ✅ Ob adversarielle Verifikation erforderlich ist.
• ✅ Wann die Schleife gestoppt wird.

💡

Was fest ist, ist die Rolle; was dynamisch ist, ist die Orchestrierungsstrategie.

Gemeinsamer Arbeitsbereich vs. Nachrichtenaustausch

Im Bereich der Agenten-Kollaboration ist die gängigste Lösung der Nachrichtenaustausch-Modus:

1Agent A erledigt Aufgabe → sendet Ergebnis als Nachricht → Agent B

Dieser Modus ist einfach und intuitiv, hat aber Probleme:

❌ Drei Hauptprobleme des Nachrichtenaustauschs

✅ Cockpit's Gemeinsamer Arbeitsbereich-Modus

Vorteile:

Analogie: Paradigmenwechsel in der Softwareentwicklung

1Von „E-Mail-Kommunikation" → zu „Zusammenarbeit an einem Git-Repository"

Letzteres verbessert die Kollaborationseffizienz erheblich.

Vorteile von plattformübergreifenden Agenten

Einer der größten Vorteile der Cockpit-Architektur ist die Unterstützung für plattformübergreifende hybride Agenten-Orchestrierung.

🎯 Plattformstärken nutzen

🛡️ Plattformabhängigkeitsrisiko reduzieren

Nicht an eine einzelne Plattform gebunden zu sein, ermöglicht einen schnellen Wechsel zu Alternativen, falls eine Plattform ausfällt oder ratenbegrenzt ist.

💰 Kostenoptimierung

Wählen Sie das passende Modell basierend auf der Aufgabenkomplexität:

• Einfache Aufgaben → Kostengünstige Modelle
• Komplexe Aufgaben → Leistungsstarke Modelle

Der adaptive Mechanismus des PM findet allmählich den optimalen Kosten-Qualitäts-Punkt.

🏗️ Praxisbeispiel

Szenario: Codebasis-Migrationsaufgabe

💡

Diese Art der hybriden Orchestrierung ist in einer Einzelplattform-Lösung nicht möglich.

Umfassender Vergleich der drei Modi

▲ Entwicklung von drei Workflow-Paradigmen: Von statisch zu dynamisch, dann zu kollaborativ

Empfehlungen für anwendbare Szenarien

🔵 Verwenden Sie statische Workflows (N8N/Zapier), wenn:

• ✅ Aufgabenabläufe sehr festgelegt sind und kaum Änderungen erfordern.
• ✅ Keine komplexe Agenten-Kollaboration benötigt wird.
• ✅ Extreme Einfachheit und Visualisierung angestrebt werden.

🟣 Verwenden Sie Claude Dynamische Workflows, wenn:

• ✅ Aufgaben komplex sind und eine Multi-Agenten-Isolation erfordern.
• ✅ Nur die Claude-Plattform verwendet wird.
• ✅ Kein Wissensaufbau über Aufgaben hinweg benötigt wird.
• ✅ Ein hoher Token-Verbrauch akzeptabel ist.

🟢 Verwenden Sie die Cockpit-Architektur, wenn:

• ✅ Eine plattformübergreifende hybride Agenten-Orchestrierung benötigt wird.
• ✅ Ein Bedarf an Wissenswiederverwendung zwischen Aufgaben besteht.
• ✅ Feste Rollenpools und rollenbasierte intelligente Zuweisung erforderlich sind.
• ✅ Anforderungen an Kostenkontrolle und Rückverfolgbarkeit bestehen.
• ✅ Sie bereit sind, technische Ressourcen in den Aufbau des Systems zu investieren.

Fazit

Die in diesem Artikel vorgeschlagene Cockpit-Architektur erreicht einen technischen Durchbruch auf der theoretischen Grundlage dynamischer Workflows, indem sie einen gemeinsamen Arbeitsbereich und rollenbasierte Orchestrierungsmechanismen einführt:

✅ Behält die Kernvorteile dynamischer Workflows bei

• Multi-Agenten-Instanz-Isolation, die agentische Trägheit und Zielabweichung löst.
• Adversarielle Verifikation, die Selbstbevorzugungs-Bias löst.
• Dynamische Orchestrierung, optimiert für spezifische Aufgaben.

🚀 Überwindet die Einschränkungen ursprünglicher Lösungen

• Plattformübergreifender Agenten-Pool, der die Stärken jeder Plattform nutzt.
• Rollenbasierte intelligente Zuweisung, die sicherstellt, dass Aufgaben den Fähigkeiten entsprechen.
• Gemeinsamer Arbeitsbereich, der Zustandskonsistenz und Wissenswiederverwendung erreicht.
• Fester Rollenpool, der Kostenkontrollierbarkeit und technische Stabilität gewährleistet.

Praxisverifikation

Betriebsdaten aus dem HippoTeam-Projekt (408 Aufgaben, 8 feste Worker, 71 Forschungsaufzeichnungen, 78 Berichte) zeigen, dass die Cockpit-Architektur bei komplexen Aufgabenkollaborationen Folgendes demonstriert:

• ✅ Bessere technische Kontrollierbarkeit
• ✅ Höhere Kollaborationseffizienz
• ✅ Vollständige Rückverfolgbarkeit

Zukunftsausblick

Da die LLM-Fähigkeiten weiter zunehmen und Agenten-Anwendungen tiefer werden, glauben wir:

Der gemeinsame Arbeitsbereich-Modus wird zum Standardparadigma für komplexe Agenten-Kollaborationssysteme werden.

Referenzen

1. Anthropic. (2026). „Dynamische Workflows in Claude Code: 6 Muster und 14 Schritte"
2. „Wie man dynamische Workflows in Claude Code meistert: 6 Muster und 14 Schritte, die Anthropic-Ingenieure tatsächlich verwenden"
3. AutoGPT-Projekt. „Autonomes KI-Agenten-Framework"
4. LangChain-Dokumentation. „Agenten- und Ketten-Orchestrierung"
5. CrewAI. „Rollenbasiertes Agenten-Kollaborations-Framework"

Autor: Huangserva Datum: Juni 2026 Schlüsselwörter: Dynamischer Workflow · Agenten-Orchestrierung · Gemeinsamer Arbeitsbereich · Adaptives System · Plattformübergreifende Kollaboration

💡

Wenn dieser Artikel für Sie hilfreich war, teilen Sie ihn gerne mit weiteren Freunden, die sich für KI-Agenten-Architektur interessieren!