Was ist ein agentischer Workflow? Wie man einen baut, der plant, handelt und bewertet

Ein agentischer Workflow ist ein mehrstufiges System, bei dem ein Sprachmodell mehr tut als nur einmal zu antworten: Es plant, wählt Werkzeuge aus, führt Aktionen aus, überprüft das Ergebnis und entscheidet, was als Nächstes zu tun ist, bis die Aufgabe abgeschlossen ist. In der Praxis bedeutet das, eine LLM-Argumentationsebene mit Tool-Aufrufen, einer echten Ausführungsumgebung und einer Bewertungsschleife zu kombinieren. Wenn Sie Codierungsagenten, Rechercheagenten oder interne Automatisierung bauen, die sich während der Aufgabe anpassen muss, ist dies in der Regel die Architektur, die Sie tatsächlich bauen.

Was ist ein agentischer Workflow?

Ein agentischer Workflow ist das Muster hinter KI-Systemen, die sich durch eine Aufgabe bewegen können, anstatt bei der Textgenerierung stehen zu bleiben. Anstatt das Modell um eine Antwort zu bitten und diese an den Benutzer zurückzugeben, lassen Sie das Modell innerhalb einer kontrollierten Schleife operieren:

1. Ziel und aktuellen Zustand lesen.
2. Nächsten Schritt planen.
3. Ein Tool aufrufen oder Code ausführen.
4. Ergebnis beobachten.
5. Bewerten, ob die Aufgabe abgeschlossen ist.
6. Bei Bedarf wiederholen.

Dies unterscheidet sich von einem festen Workflow, bei dem jeder Schritt vorab im Code festgelegt ist. In einem festen Workflow legen Sie den Pfad im Voraus fest. In einem agentischen Workflow entscheidet das Modell, welche Aktion als Nächstes ausgeführt wird, innerhalb der von Ihnen vorgegebenen Grenzen.

Diese Unterscheidung ist wichtig, weil viele reale Entwickleraufgaben nicht linear sind. Ein Codierungsagent muss möglicherweise Dateien inspizieren, bevor er weiß, welchen Test er ausführen soll. Ein Rechercheagent muss möglicherweise zweimal suchen, weil die erste Quelle unvollständig war. Ein Browseragent muss sich möglicherweise von einem Anmeldefehler oder einer geänderten Seitenlayout erholen. Das sind Workflow-Probleme, aber sie erfordern Anpassung.

Wie unterscheidet sich ein agentischer Workflow von einem KI-Agenten?

Die Begriffe werden oft synonym verwendet, aber es ist nützlicher, sie zu trennen:

• Ein agentischer Workflow ist das Ausführungsmuster.
• Ein KI-Agent ist das Produkt oder System, das auf diesem Muster aufbaut.

Sie können einen eng gefassten agentischen Workflow haben, der nur Support-Tickets priorisiert, oder einen breiteren KI-Agenten, der Planung, Tool-Nutzung, Gedächtnis und Genehmigungsprüfpunkte über viele Aufgaben hinweg koordiniert.

Wenn Sie eine praktische Regel wünschen, verwenden Sie Workflow, wenn Sie über Architektur und Kontrollfluss sprechen, und Agent, wenn Sie über das benutzerorientierte System sprechen.

Was sind die Kernbestandteile eines agentischen Workflows?

Die meisten Produktionssysteme landen bei denselben fünf Teilen.

1. Planer

Der Planer wandelt eine breite Anweisung in die nächste konkrete Aktion um. Manchmal ist dies ein expliziter Planungsschritt, der eine Aufgabenliste ausgibt. Manchmal ist es implizit und geschieht innerhalb jeder Tool-Aufruf-Runde. In jedem Fall benötigt das Modell genügend Kontext, um zu entscheiden, ob es lesen, schreiben, suchen, ausführen oder anhalten soll.

Gute Planung bedeutet nicht, für jede Anfrage eine lange Gliederung zu erstellen. Es bedeutet, den nächsten Schritt lesbar zu halten. Für kurze Aufgaben reicht eine einstufige Planung. Für längere Aufgaben wie Repo-Refaktorisierungen, Browser-Automation oder Dokumentenprüfung reduziert ein expliziter Plan das Hin und Her.

2. Tool-Schicht

Tools sind die Schnittstelle des Workflows zur Welt. Eine starke Tool-Schicht ist in der Regel eng und vorhersagbar. Zum Beispiel:

• read_file(path)
• write_file(path, content)
• search_files(query)
• run_command(cmd)
• fetch_url(url)

Kleine Tools sind für das Modell einfacher korrekt aufzurufen, einfacher zu protokollieren und einfacher zu sichern. Große „Alles-können“-Tools wirken zunächst bequem, werden aber schwer zu debuggen, da Sie nicht sagen können, ob Fehler von der Modellentscheidung, der Tool-Implementierung oder dem externen System dahinter stammen.

3. Ausführungslaufzeit

Sobald das Modell beschließt zu handeln, muss etwas die Aktion ausführen. Für jeden Workflow, der Dateien schreibt, Pakete installiert, Code ausführt oder Browsersitzungen öffnet, benötigt diese Laufzeit Isolation.

Hier kommt eine Sandbox ins Spiel. Novita Agent Sandbox ist für diese Ausführungsebene konzipiert: eine separate Umgebung, in der Agentenaktionen ausgeführt werden können, ohne das Hostsystem direkt zu berühren. Dies ist der Unterschied zwischen „das Modell hat einen Befehl vorgeschlagen“ und „der Workflow hat diesen Befehl sicher ausgeführt“.

4. Zustand und Gedächtnis

Ein agentischer Workflow benötigt ein Arbeitsgedächtnis über mehrere Schritte hinweg. Das umfasst in der Regel:

• Gesprächszustand
• Tool-Ausgaben
• Zwischendateien
• Ausführungsprotokolle
• einen Notizblock oder kurzen Plan

Ohne Zustand wird jeder Schritt zu zustandslosem Prompt-Engineering, und das System bricht zusammen, sobald die Aufgabe mehr als eine Aktion umfasst.

5. Bewertungsschleife

Dies ist der Teil, den viele Teams zu spät hinzufügen. Der Workflow benötigt eine Möglichkeit zu beurteilen, ob ein Schritt erfolgreich war und ob die Aufgabe erledigt ist. In einem Codierungs-Workflow könnte das bedeuten, dass Tests bestanden werden. In einem Recherche-Workflow könnte es bedeuten, dass die Antwort genügend zuverlässige Quellen zitiert. In einem Browser-Workflow könnte es bedeuten, dass der erwartete UI-Zustand sichtbar ist.

Ohne Bewertung wird „agentisch“ oft zu „ruft weiterhin Tools auf, bis das Zeitlimit erreicht ist“.

Warum Planung beim Bau agentischer Workflows wichtig ist

Der größte Fehler beim Bau agentischer Workflows ist die Annahme, dass das Modell bei jeder Runde alles von Grund auf improvisieren sollte.

Das schafft in der Regel drei Probleme:

• das Modell besucht dieselben Dateien oder URLs wiederholt
• die Tool-Nutzung wird laut und teuer
• der Workflow verliert eine klare Abbruchbedingung

Ein besseres Muster ist leichte Planung plus fundierte Ausführung. Lassen Sie das Modell die nächste Aktion entscheiden, aber tun Sie dies in Bezug auf eine explizite Aufgabe, einen sichtbaren aktuellen Zustand und eine kleine Menge erlaubter Tools. Das bewahrt Flexibilität, wo sie hilft, und entfernt sie, wo sie nicht hilft.

In Codierungs-Workflows sieht Planung oft so aus:

1. Identifizieren Sie die beteiligten Dateien.
2. Lesen Sie die aktuelle Implementierung.
3. Entscheiden Sie die minimale Änderung.
4. Führen Sie die Bearbeitung durch.
5. Führen Sie die Überprüfung durch.
6. Entweder anhalten oder reparieren.

Dies ist immer noch agentisch, da das Modell abzweigen kann, wenn das Repo es überrascht. Aber es wandert nicht umher.

Wie sollte die Tool-Nutzung in einem agentischen Workflow funktionieren?

Die Tool-Nutzung sollte explizit, typisiert und beobachtbar sein.

Wenn Ihr Modell Funktionsaufrufe unterstützt, verwenden Sie es. Novitas LLM-API bietet einen OpenAI-kompatiblen Endpunkt und dokumentiert Funktionsaufrufe direkt, was der sauberste Weg ist, das Modell zwischen Tools wählen zu lassen, ohne sich auf spröde String-Parsing zu verlassen.

Ein paar Regeln machen die Tool-Nutzung viel zuverlässiger:

• Halten Sie Tool-Namen konkret.
• Verwenden Sie Schemata mit Pflichtfeldern.
• Geben Sie vollständige Ergebnisse zurück, einschließlich Fehlern.
• Protokollieren Sie jeden Aufruf, jedes Argument und jede Ausgabe.
• Machen Sie destruktive Aktionen selten und leicht abschaltbar.

Die Tool-Schicht sollte auch reale Grenzen widerspiegeln. Geben Sie einem Codierungsagenten zum Beispiel kein Mega-Tool namens edit_repo_and_run_tests. Teilen Sie die Lese-, Schreib- und Ausführungsschritte auf, damit das Modell sich erholen kann, wenn etwas fehlschlägt.

Warum benötigt die Code-Ausführung eine Sandbox?

Ein agentischer Workflow, der nie etwas ausführt, kann oft innerhalb eines gewöhnlichen App-Servers bleiben. Sobald er jedoch Shell-Befehle ausführt, Abhängigkeiten installiert, heruntergeladene Dateien verarbeitet oder das offene Web durchsucht, benötigen Sie Isolation.

Sandboxing löst zwei verschiedene Probleme:

• Sicherheit: generierter Code und Tool-Ausgaben können falsch, feindselig oder einfach unvorhersehbar sein.
• Zustandsbehaftung: mehrstufige Aufgaben benötigen einen persistenten Arbeitsbereich, in dem Dateien, Pakete und Ausführungshistorie über mehrere Runden hinweg erhalten bleiben.

Für viele Teams ist der zweite Punkt genauso wichtig wie der erste. Ein Workflow, der Code bearbeitet, Tests ausführt, den Fehler behebt und die Überprüfung wiederholt, ist nicht möglich, wenn jeder Schritt von einer sauberen Maschine ausgeht.

Deshalb ist die praktische Architektur in der Regel:

• LLM-API für Planung und Tool-Auswahl
• Sandbox-Laufzeit für Ausführung und Persistenz

Novita passt diese Aufteilung natürlich: Die LLM-API fungiert als Planungs- und Tool-Aufruf-Schicht, während Agent Sandbox die eigentliche Ausführungsumgebung übernimmt.

Wie bewertet man einen agentischen Workflow?

Die Bewertung muss auf zwei Ebenen erfolgen.

Bewertung auf Schritt-Ebene

Hat die letzte Aktion funktioniert?

Beispiele:

• Wurde der Befehl erfolgreich beendet?
• Hat die API gültiges JSON zurückgegeben?
• Wurde die erwartete Datei erstellt?
• Enthielt die Browserseite das Zielelement?

Bewertung auf Aufgaben-Ebene

Hat der Workflow das Problem des Benutzers gelöst?

Beispiele:

• Bestehen die Tests nach der Code-Änderung?
• Beantwortet die Zusammenfassung die Forschungsfrage mit Belegen?
• Hat die Automatisierung die Transaktion ohne manuelle Bereinigung abgeschlossen?

Starke Workflows verwenden beide. Wenn Sie nur das Endergebnis bewerten, übersehen Sie offensichtliche Fehlersignale während der Ausführung. Wenn Sie nur Schritte bewerten, kann der Workflow eine lange Serie lokal gültiger Aktionen abschließen und dennoch die eigentliche Aufgabe nicht erfüllen.

Eine praktische Architektur zum Bau agentischer Workflows

Hier ist die Architektur, mit der die meisten Teams beginnen sollten:

1. Eine Benutzeranfrage gelangt in Ihre App.
2. Ihr Controller sendet das Ziel, den Zustand und die verfügbaren Tools an ein LLM.
3. Das LLM gibt entweder eine direkte Antwort oder einen Tool-Aufruf zurück.
4. Ihr Controller führt das Tool innerhalb einer Sandbox oder einer anderen kontrollierten Laufzeit aus.
5. Das Tool-Ergebnis wird an den Gesprächszustand angehängt.
6. Ein Evaluator prüft auf Abschluss, Fehler oder Genehmigungsprüfpunkte.
7. Die Schleife wird fortgesetzt, bis der Workflow abgeschlossen oder blockiert ist.

Diese Controller-Schleife kann einfach sein. In vielen Fällen reicht ein einzelner Orchestrator-Prozess aus. Sie brauchen am ersten Tag kein Multi-Agenten-System. Beginnen Sie mit einem Planer, einigen gut definierten Tools, einer Sandbox-Laufzeit und einem klaren Evaluator.

Beispiel: Ein agentischer Workflow-Controller in Python

Das folgende Beispiel zeigt die Form der Kontrollschleife. Es verwendet Novitas OpenAI-kompatible API für Tool-Aufrufe. Die Ausführungsfunktionen müssen Sie selbst gegen Ihre eigene Laufzeit oder Sandbox implementieren.

import json
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.novita.ai/openai",
    api_key=os.environ["NOVITA_API_KEY"],
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read a file from the workspace",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "Run a shell command in the sandbox",
            "parameters": {
                "type": "object",
                "properties": {"cmd": {"type": "string"}},
                "required": ["cmd"],
            },
        },
    },
]


def read_file(path: str) -> str:
    # Implement this against your own workspace or sandbox filesystem.
    raise NotImplementedError


def run_command(cmd: str) -> str:
    # Implement this against your sandbox runtime.
    raise NotImplementedError


dispatch = {
    "read_file": read_file,
    "run_command": run_command,
}


def run_workflow(task: str, model: str) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "You are a workflow controller. Use tools when needed, "
                "check results after each action, and stop when the task is complete."
            ),
        },
        {"role": "user", "content": task},
    ]

    while True:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for call in message.tool_calls:
            fn = dispatch[call.function.name]
            args = json.loads(call.function.arguments)
            result = fn(**args)
            messages.append(
                {
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": result,
                }
            )

Dies ist bewusst minimal. In der Produktion würden Sie auch hinzufügen:

• Wiederholungsstrategie für vorübergehende Fehler
• Zeitüberschreitungen und Budgetgrenzen
• menschliche Genehmigung für sensible Aktionen
• strukturierte Schrittprotokolle
• einen Evaluator auf Aufgabenebene vor dem endgültigen Abschluss

Welches Modell sollten Sie als Planer verwenden?

Für einen agentischen Workflow benötigt das Planermodell nicht nur rohe Intelligenz. Es benötigt die richtige Form:

• zuverlässige Tool-Aufrufe
• stabiles Langkontextverhalten
• starke Befolgung von Anweisungen
• vorhersagbare Latenz bei mehreren Runden

Wenn Sie einen Open-Weight-Startpunkt auf Novita wünschen, ist Qwen3 Coder 30B A3B Instruct eine praktische Option für Workflow-Planung und codierungsorientierte Tool-Nutzung. Novitas aktuelle Modellseite listet OpenAI-kompatiblen Zugriff, Funktionsaufruf-Unterstützung, strukturierte Ausgabeunterstützung und ein 160K gehostetes Kontextfenster auf. Für viele interne Automatisierungs- und Codierungsaufgaben reicht das aus, um eine ernsthafte erste Version zu bauen, bevor Sie zu einem größeren oder spezialisierteren Planer wechseln.

Das richtige Modell hängt dennoch von der Aufgabe ab. Für breite, argumentationsintensive Workloads wählen Sie zuerst nach Planungsqualität. Für die Automatisierung mit hohem Volumen können Latenz und Kosten genauso wichtig sein wie die Benchmark-Stärke.

Häufige Fehlermodi in agentischen Workflows

Die meisten Fehler sind nicht dramatisch. Sie sind repetitiv und teuer.

Übermäßige Tool-Nutzung

Wenn jede Fähigkeit zu einer eigenen Remote-Abhängigkeit wird, verbringt der Workflow mehr Zeit mit Koordination als mit nützlicher Arbeit.

Schwache Abbruchregeln

Wenn das System nie weiß, wann „erledigt“ wahr ist, generiert es immer einen weiteren Schritt.

Schlechte Fehlerbehandlung

Wenn Tools vage Nachrichten wie „fehlgeschlagen“ anstelle von umsetzbaren Ausgaben zurückgeben, kann sich das Modell nicht erholen.

Keine Sandbox-Grenze

Der Workflow funktioniert möglicherweise in der Entwicklung, wird aber unsicher, sobald er echte Dateien, Anmeldeinformationen oder externe Systeme berührt.

Kein Evaluator

Der Agent scheint beschäftigt, beweist aber nie, dass die Aufgabe korrekt abgeschlossen wurde.

Wann sollten Sie keinen agentischen Workflow verwenden?

Bauen Sie keinen nur, weil der Begriff populär ist.

Sie benötigen wahrscheinlich keinen agentischen Workflow, wenn:

• die Aufgabe eine einmalige Generierung ist
• der Pfad festgelegt ist und sich selten ändert
• ein traditionelles Programm jeden Schritt kostengünstig entscheiden kann
• keine Notwendigkeit für Tool-Nutzung oder Ausführung besteht

Wenn Ihre App zum Beispiel immer eine Formulareingabe nimmt, einen Prompt aufruft und eine formatierte E-Mail zurückgibt, ist ein gewöhnlicher LLM-Workflow einfacher und besser.

Agentische Workflows zahlen sich aus, wenn die Umgebung das System überraschen kann und das System dennoch weitermachen muss.

FAQ

Ist ein agentischer Workflow dasselbe wie Funktionsaufruf?

Nein. Funktionsaufruf ist ein Mechanismus innerhalb des Workflows. Der vollständige Workflow benötigt auch Kontrollfluss, Zustand, Ausführung und Bewertung.

Benötige ich mehrere Agenten, um agentische Workflows zu bauen?

Nein. Die meisten Teams sollten mit einer einzigen Controller-Schleife und einigen Tools beginnen. Multi-Agenten-Designs sind später nützlich, aber sie sind nicht der Standard-Startpunkt.

Was ist die wichtigste Sicherheitskontrolle?

Für Workflows, die Code ausführen oder externe Systeme berühren, ist die wichtigste Kontrolle eine isolierte Ausführungsumgebung in Kombination mit engen Tool-Berechtigungen.

Was ist der einfachste produktionsreife Stack?

Ein guter erster Stack ist: eine OpenAI-kompatible LLM-API, ein kleines Tool-Register, eine Sandbox-Laufzeit und ein Evaluator, der entscheiden kann, wann die Aufgabe tatsächlich erledigt ist.

Empfohlene Artikel

• Was sind Codierungsagenten? Wie sie funktionieren und wie man einen baut
• Was ist eine KI-Agenten-Sandbox?
• Agent vs. Workflow: Hauptunterschiede und praktische Abwägungen