# KI-Agent-Workflow: Teams, Parallelteile und Flows

URL: https://agentvera.dev/de/blog/ai-agent-workflow-pipeline/ · Veröffentlicht: 2026-09-26 · Aktualisiert: 2026-10-17

Einen KI-Agent-Workflow auf mehrere Agenten verteilen: Team mit Manager und Rollen, Parallel-Team mit einem PR am Ende und Flows, die Arbeit weiterreichen.

**Kurz gesagt:**

- AgentVera bietet drei Wege, Arbeit auf Agenten zu verteilen: eine Team-Ansicht mit Manager und Rollen, ein Parallel-Team mit einem PR am Ende und Flows, die die Ausgabe eines Agenten an den nächsten weiterreichen.
- Ein Team fasst bis zu 24 Agenten; ein Parallel-Team führt jeden Teil in eigenem Worktree und Branch aus, standardmäßig 3 gleichzeitig, höchstens 6, führt sie zusammen und startet den Test-Befehl des Projekts.
- Am wertvollsten ist es, den Plan zu lesen, bevor Code entsteht: Setze in einem Flow einen Human-approval-Knoten vor den Builder oder lass dir vom Team-Manager zuerst den Plan schicken.

Wenn Leute an einen KI-Agent-Workflow denken, stellen sich die meisten einen Agenten, eine lange Aufgabe und das Warten aufs Ergebnis vor. Für kleine Jobs funktioniert das. Bei etwas Großem wie „Zahlungen auf einen neuen Anbieter umstellen“ recherchiert, plant und implementiert ein Agent alles auf einmal: Der Kontext bläht sich auf, du siehst nie einen Plan, und Fehler zeigen sich erst, nachdem der Code geschrieben ist.

Dieser Beitrag zeigt drei Wege, wie AgentVera diese Arbeit auf mehrere Agenten verteilt: ein **Team** mit Manager und Rollen, ein **Parallel-Team**, das unabhängige Teile gleichzeitig ausführt, und **Flows**, die die Ausgabe eines Agenten an den nächsten weiterreichen.

## Warum einen KI-Agent-Workflow aufteilen?

Die Probleme einer Sitzung mit einem einzelnen Agenten:

- **Der Kontext wächst.** Jede bei der Recherche gelesene Datei bleibt bei der Umsetzung im Kontext.
- **Der Plan ist unsichtbar.** Der Agent entscheidet, was zu tun ist, und geht direkt ans Coden.
- **Fehler zeigen sich spät.** Eine falsche Annahme fällt erst auf, wenn die Tests fehlschlagen.

Mehrere Agenten mit klaren Aufgaben lösen das. Ein Researcher schreibt keinen Code, ein Planer schreibt nur den Plan, ein Entwickler setzt ihn um und ein Reviewer prüft ihn. Jeder arbeitet mit seinem eigenen kleinen Kontext.

## Option 1: ein Team mit Manager und Rollen

Die [Team-Ansicht](/de/features/team-view/) macht aus den Agenten, die in deinem Workspace offen sind, ein Team. Im Fenster Team structure ordnest du sie in einem Organigramm an: Einer wird Manager, die anderen bekommen eine Rolle, Anweisungen, jemanden, dem sie berichten, und jemanden, an den sie ihre Arbeit übergeben. Ein Team fasst bis zu 24 Agenten.

Du musst nicht bei null anfangen. Vorgefertigte Rollen füllen Researcher, Planer, Entwickler, Reviewer, Tester und mehr aus; vorgefertigte Teams, etwa das Software-Team (Tech Lead, Planer, Entwickler, Reviewer und Tester), öffnen die benötigten Agenten für dich. Das Team und jede Rolle können eigene MCP-Server mitbringen, sodass der Tester mit Playwright startet, ohne dass du es pro Agent einrichtest.

Beim Bauen des Teams startet nichts. Du tippst die Arbeit in das Feld darunter und wählst **Give to the team**. Sie geht an den Manager, der sie aufteilt, verteilt und die Ergebnisse prüft. Die Agenten klären das über den Agent-Chat und eine gemeinsame Aufgabenliste untereinander.

Während es läuft, zeigt die Team-Ansicht, wer woran arbeitet, wie Nachrichten zwischen Agenten wandern und wo jede Aufgabe steht. Berechtigungsanfragen landen in der Attention-Leiste über dem Diagramm, wo du sie direkt genehmigst oder ablehnst. **Status report** bittet den Manager um eine kurze Zusammenfassung; **Interrupt all** stoppt alle.

Das passt zu Arbeit, bei der Agenten miteinander reden müssen: ein Planer, der dem Researcher eine Rückfrage stellt, ein Reviewer, der eine Änderung an den Entwickler zurückschickt.

## Option 2: ein Parallel-Team, das in einem PR endet

Manche Jobs zerfallen in unabhängige Teile: zum Beispiel API, UI und Migration eines neuen Features. Ein [Parallel-Team](/de/features/parallel-team/) führt sie gleichzeitig aus.

Ein Agent startet das Team selbst, wenn sich eine große Änderung so aufteilen lässt. Er schreibt die Teile selbst oder bekommt nur das Ziel und lässt Claude Sonnet das Repository lesen und sie planen. Dann:

1. Jeder Teil geht an einen eigenen Agenten in einem eigenen Worktree und Branch, sodass Agenten nie an den Dateien der anderen arbeiten. Standardmäßig laufen 3 gleichzeitig, höchstens 6.
2. Ein Agent beendet seine Arbeit mit dem Marker `[[TESLİM]]`, wenn er fertig ist, oder mit `[[YARDIM]]`, wenn er feststeckt. Ein hängender Teil wartet auf dich: Übernimm, was er getan hat, lass ihn weitermachen oder überspringe ihn.
3. Fertige Teile werden in einem Integrationsbranch zusammengeführt, und der Test-Befehl des Projekts läuft als letzte Prüfung. Gibt es einen Merge-Konflikt oder schlägt die Prüfung fehl, springt ein Integrations-Agent ein.
4. Du öffnest einen Pull Request oder stellst den Branch in die Merge Queue.

Das passt zu großen Änderungen, bei denen die Teile nicht miteinander reden müssen, sondern am Ende nur zusammenpassen.

## Option 3: Flows, die Arbeit weiterreichen

Wenn du eine feste Kette willst, baue sie in [Flows](/de/features/flows/). Die klassische Abfolge Recherche, Plan, Umsetzung sieht so aus:

| Schritt | Agent | Was er bekommt | Regel |
| --- | --- | --- | --- |
| Recherche | Researcher | Das Ziel | Kein Code; Ist-Zustand und Optionen berichten |
| Plan | Planer | Die letzte Antwort des Researchers | Ziel, außerhalb des Umfangs, Dateien, Schritte, Teststrategie, Abnahmekriterien |
| Freigabe | Du | Der Plan | Human-approval-Knoten |
| Umsetzung | Builder | Der freigegebene Plan | Plan umsetzen, Tests ausführen |

Wenn ein Agent seinen Zug beendet, wird seine letzte Antwort in die Nachrichtenvorlage der Verbindung (`{{output}}`) eingesetzt und an den nächsten Agenten gesendet. Ist der nächste Agent beschäftigt, wartet der Flow, bis sein Zug endet. Diese Knoten machen die Kette sicher:

- **Condition:** Weiter geht es nur, wenn die Antwort eine Wendung enthält oder auf einen Regex passt, damit eine Zwischenfrage nicht den nächsten Schritt auslöst.
- **Transform:** Sende nur den letzten Codeblock oder die ersten N Zeilen.
- **Human approval:** Stopp, bis du in der App oder über Telegram freigibst.
- **Wait** und **Notify:** Zeit zwischen Schritten lassen und über wichtige Schritte informiert werden.
- **Turn limit:** Eine Verbindung pausieren, die in einer Schleife hängt.

## Der Freigabeschritt ist am wichtigsten

Für welche Option du dich auch entscheidest: Den Plan zu lesen, bevor Code entsteht, ist der wertvollste Moment. Ein falscher Plan ist dort in fünf Minuten korrigiert, mit vorhandenem Code kostet es Stunden. Am häufigsten fallen auf:

- Ein Modul, das außerhalb des Umfangs bleiben sollte, schleicht sich in den Plan.
- Bestehende Tests fehlen in der Teststrategie.
- Die Reihenfolge der Schritte, etwa erst das Interface, dann die Implementierung.

Bitte in einem Team den Manager, dir den Plan zu schicken, bevor er die Arbeit verteilt. Setze in einem Flow einen Human-approval-Knoten vor den Builder.

## So schreibst du ein gutes Ziel

Die erste Eingabe ist das Ziel, das du schreibst. Ein gutes Ziel:

- **Beschreibt das Ergebnis:** „Stelle den Zahlungsanbieter von X auf Y um, ohne den aktuellen API-Vertrag zu ändern.“
- **Nennt die Grenzen:** „Fasse das Rechnungsmodul nicht an.“
- **Definiert Erfolg:** „Die bestehenden Zahlungstests müssen bestehen, und füge einen Integrationstest für den neuen Anbieter hinzu.“

Ein Ziel wie „Zahlungen verbessern“ treibt jeden Agenten dazu, die gesamte Codebasis zu lesen.

## Was solltest du nutzen?

- **Ein Agent:** ein Ein-Datei-Fix, ein Tippfehler oder eine kleine Stiländerung. Aufteilen dauert länger als die Arbeit.
- **Team-Ansicht:** laufende Arbeit, bei der Agenten mit verschiedenen Rollen miteinander reden, nachfragen und sich gegenseitig reviewen müssen.
- **Parallel-Team:** eine große Änderung mit unabhängigen Teilen, die als ein Branch und ein PR enden soll.
- **Flows:** eine feste Abfolge, die du immer wieder ausführst, mit Freigaben und Bedingungen dazwischen.

## Lange Jobs laufen lassen, während du weg bist

Du musst nicht am Rechner sitzen, während ein langer Job läuft:

- **Telegram-Benachrichtigungen:** Gib einen Flow-Schritt vom Handy frei und antworte auf eine Benachrichtigung, um Text an diesen Agenten zu senden.
- **[AgentVera-Mobile-App](/de/blog/claude-code-mobile-app/):** Verfolge Chat, Terminal und Diff jedes Agenten auf iOS oder Android und beantworte seine Berechtigungsanfragen.
- **Geplante Aufgaben:** Sende einem Agenten per Cron-Zeitplan eine Nachricht, zum Beispiel um jeden Morgen die Recherche zu Abhängigkeiten zu starten.
- **Ruhezustand verhindern:** Die Einstellung, die den Rechner wach hält, während Agenten arbeiten, verhindert, dass nächtliche Jobs stocken.

## Checkliste

- [ ] Beschreibt das Ziel Ergebnis und Grenzen in einem Absatz?
- [ ] Hat jeder Agent eine klare Aufgabe?
- [ ] Siehst du den Plan, bevor Code entsteht?
- [ ] Laufen die Tests, bevor die Arbeit als fertig gilt?
- [ ] Wirst du benachrichtigt, wenn es endet?

## Fazit

Einen KI-Agent-Workflow auf mehrere Agenten zu verteilen macht sie bei großen Jobs berechenbarer: Jeder Kontext bleibt klein, der Plan ist sichtbar und Fehler zeigen sich früh. AgentVera bietet dir dafür drei Wege, vom Live-Team bis zum Parallellauf, der in einem PR endet.

[Starte im kostenlosen Tarif](/de/) und sieh dir [Benachrichtigungen und Freigaben](/de/features/notifications-and-approvals/) an, um Freigaben aus der Ferne zu erledigen.

## Häufige Fragen

**Warum mehrere Agenten statt einem?** Recherche, Planung, Umsetzung und Review sind verschiedene Aufgaben. Getrennte Agenten halten jeden Kontext klein, lassen dich den Plan sehen, bevor Code entsteht, und fangen Fehler früh ab.

**Was ist der Unterschied zwischen Team-Ansicht und Parallel-Team?** Die Team-Ansicht macht aus deinen offenen Agenten ein dauerhaftes Team mit Manager und Rollen, das zusammenarbeitet, während du zusiehst. Ein Parallel-Team ist ein Agent, der einen Job in Teile zerlegt, jeden Teil in einem eigenen Worktree ausführt und alles in einem Branch und einem PR zusammenführt.

**Wie geben Agenten in einem Team Arbeit aneinander weiter?** Über den Agent-Chat: Sie senden Nachrichten, warten auf Antworten und teilen eine Aufgabenliste mit Abhängigkeiten. Agenten verschiedener CLIs können miteinander sprechen.

**Kann ich eine Kette aus Recherche, Plan und Umsetzung weiterhin selbst bauen?** Ja, mit Flows. Platziere drei Agenten auf der Canvas, verbinde sie über Nachrichtenvorlagen und füge einen Human-approval-Knoten vor dem Builder ein.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/