> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/de/aktionen/playbooks/run-a-playbook.md).

# Ein Playbook ausführen

Führe Playbooks manuell, aus Grids oder mit Triggern aus

Sie können ein Playbook manuell im Editor, über ein Grid oder automatisch mit einem Trigger ausführen. Jede Ausführung erstellt eine Session mit Ausführungsdetails und Artefakten.

## Manuell ausführen

Verwenden Sie eine manuelle Ausführung, wenn Sie ein Playbook testen oder es für einen einzelnen Anwendungsfall ausführen.

1. Öffne den Playbook-Editor.
2. Klicken Sie auf **Playbook ausführen**.
3. Geben Sie alle erforderlichen Eingaben an.
4. Überprüfen Sie die Session-Ausgabe und die Artefakte.

{% hint style="info" %}
Ausführungen, die im Playbook-Editor gestartet werden, verwenden zuerst Testaufgaben und dann Produktionsaufgaben. Jeder Workspace verfügt über 50.000 kostenlose Testaufgaben pro Monat, die für Workflow- und Playbook-Tests verwendet werden können. Wenn Ihr Workspace alle Testaufgaben verbraucht hat, verwendet AirOps für zusätzliche Editor-Ausführungen Produktionsaufgaben. Sie können die Nutzung der Testaufgaben überprüfen in der **Verwendung** Registerkarte.
{% endhint %}

## Aus einem Grid ausführen

Verwenden Sie ein Grid, wenn Sie ein veröffentlichtes Playbook über Zeilen strukturierter Daten hinweg ausführen möchten.

1. Öffnen Sie das Grid.
2. Klicken Sie auf **+ Spalte hinzufügen**.
3. Wähle das **Playbooks** Registerkarte.
4. Suchen Sie nach dem Playbook.
5. Ordnen Sie Grid-Spalten, statische Werte oder Brand Kits den Playbook-Eingaben zu.
6. Führen Sie das Playbook für eine Zeile oder in großen Mengen aus.

{% hint style="info" %}
Wenn ein Playbook von einem Grid aus ausgeführt wird, verwendet es die auf dieser Grid-Spalte konfigurierte Version und die Eingabezuordnungen. Änderungen, die Sie im Session-Chat vornehmen, gelten für die Artefakte, nicht für das Playbook. Um das Playbook selbst zu ändern, öffnen Sie es im Editor.
{% endhint %}

Siehe [Playbooks im Grid ausführen](/docs/de/aktionen/grids/run-playbooks-in-grid.md) für die Versionsauswahl, Massenläufe, den Session-Status und die Artefaktprüfung.

### Zum Quell-Grid zurückkehren

Nachdem Sie ein Playbook aus einem Grid geöffnet haben, wählen Sie **Zurück zum Grid** in den Schnellaktionen des Editors, um zum ursprünglichen Blatt zurückzukehren. Wenn Sie das Playbook direkt geöffnet haben, kehrt AirOps zu seinem verknüpften Grid zurück oder bietet einen Selektor an, wenn mehrere Grids verknüpft sind. Die Option wird ausgeblendet, wenn keine aktiven verknüpften Grids vorhanden sind.

## Automatisch ausführen

Verwenden Sie einen Trigger, wenn das Playbook nach einem Zeitplan, durch ein externes Ereignis oder durch ein AirOps-Signal starten soll.

Zu den Trigger-Typen gehören:

* **Zeitplan:** In wiederkehrendem Rhythmus ausführen.
* **Webhook:** Durch eine HTTP-Anfrage ausführen.
* **Überwachung:** Ausführen, wenn Parallel Web Systems eine Bedingung aus Ihrer Überwachungsabfrage erkennt.
* **AEO-Insight:** Ausführen, wenn ein aktivierter Insights-Schwellenwert erreicht wird.

Ausgelöste Ausführungen werden in der Ausführungshistorie angezeigt. Ausführungen, die eine menschliche Prüfung erfordern, erscheinen ebenfalls im Posteingang.

{% hint style="info" %}
Für die Trigger-Einrichtung, Versionseinstellungen und Beispiele für Webhook-Payloads siehe [Playbook-Trigger](/docs/de/aktionen/playbooks/triggers.md).
{% endhint %}

## Versionen und Eingabeänderungen

Grid-Spalten und Trigger können verwenden **Standard** oder eine angeheftete Playbook-Version.

* **Standard** folgt der aktuell veröffentlichten Version.
* **Angeheftet** verwendet weiterhin die ausgewählte Version, bis Sie sie ändern.

{% hint style="warning" %}
Wenn eine neue Playbook-Version Eingaben ändert, aktualisieren Sie alle Zuordnungen für Grid-Spalten und die Trigger-Eingabekonfiguration, bevor Sie in großem Umfang ausführen. Neue erforderliche Eingaben ohne zugeordnete oder konfigurierte Werte können dazu führen, dass Ausführungen die Validierung nicht bestehen oder übersprungen werden.
{% endhint %}

## Sessions überprüfen

Jede Ausführung erstellt eine Session. Eine Session enthält:

* Das vollständige Ausführungsprotokoll.
* Die für die Ausführung verwendeten Eingaben.
* Das verwendete Modell und dessen Begründungsdetails, sofern verfügbar.
* Jedes vom Playbook erzeugte Artefakt.
* Den Status der menschlichen Prüfung, wenn das Playbook Prüfblöcke enthält.

Sessions sind sichtbar in **Verlauf der Ausführungen** oben rechts im Playbook-Editor und im Posteingang, wenn eine Prüfung erforderlich ist.

Die Session-Aktivität zeigt auch den Prüfungsfortschritt. Aktivitäten der Prüfer werden unter dem Prüfversuch gruppiert, der sie erzeugt hat, während vom Hauptagenten vorgenommene Korrekturen in der Haupt-Zeitleiste verbleiben. Sie können diese Aktivität während einer Ausführung oder nach dem Aktualisieren der Session überprüfen.

## An Artefakten zusammenarbeiten

Artefakte unterstützen Kommentare, Vorschläge, Erwähnungen, den Versionsverlauf und KI-gestützte Bearbeitungen. Verwenden Sie diese Steuerelemente, wenn eine Session-Ausgabe vor der Veröffentlichung oder für die Weiterverwendung geprüft werden muss. Änderungen betreffen das Artefakt dieser Session, nicht die Anweisungen des Playbooks.

Siehe [Artefakte](/docs/de/aktionen/playbooks/artifacts.md) für den vollständigen Workflow für Zusammenarbeit, Wiederherstellung, stabile Verknüpfung und Grid.

## Eine Grid-Session unterbrechen oder erneut ausführen

Wenn eine Session als **Archiviert**markiert ist, können Sie den Verlauf und die Artefakte überprüfen, aber keine neuen Nachrichten mehr senden. Starten Sie eine neue Session, um die Arbeit fortzusetzen.

In einem Grid zeigen Playbook-Zellen den aktuellen Session-Status an. Sie können die Session aus der Zelle öffnen, eine wartende oder laufende Session unterbrechen und terminale Sessions erneut ausführen. Wenn eine Session auf einer älteren Playbook-Version ausgeführt wurde, zeigt die Zelle eine Warnung an, damit Sie sie auf der aktuellen Version erneut ausführen können.

## Verwenden Sie zwei Playbooks für Überwachung und Aktion

Viele Playbook-Setups verwenden ein Zwei-Playbook-Muster.

Das erste Playbook überwacht Daten und findet Arbeit für Sie. Es kann über einen Trigger ausgeführt werden, AirOps Insights durchsuchen, Chancen identifizieren und sie mit dem AirOps MCP in ein Grid übertragen, zum Beispiel URLs zum Aktualisieren oder Prompts zum Ausrichten.

Das zweite Playbook führt diese Zeilen aus und erzeugt die Ausgabe. Sie können es manuell oder als Grid-Aktion für die vom ersten Playbook erzeugte Zeile ausführen, zum Beispiel um einen Blogbeitrag für einen Ziel-Prompt zu entwerfen oder eine bestehende Seite zu aktualisieren.

Ein Playbook findet die Arbeit. Das andere Playbook erledigt die Arbeit und bringt Sie zu einer Ausgabe. Sie können jedes Muster auch einzeln verwenden, sie werden jedoch häufig kombiniert.

{% hint style="info" %}
Ein Playbook, das Daten überwacht, verwendet häufig Memory, um zu vermeiden, dass derselbe Eintrag innerhalb eines konfigurierten Zeitfensters, beispielsweise 60 Tage, erneut empfohlen wird.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.airops.com/docs/de/aktionen/playbooks/run-a-playbook.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.