01
Entwicklung
development-Branch
Erstellen, starten, debuggen und veröffentlichen Sie Workflow-Änderungen mit Entwicklungsdiensten und -zugangsdaten.
Veröffentlichen aktiviert
KI-Workflows in Produktion
Bringen Sie KI-Workflows von der Entwicklung in Produktion, ohne Umgebungen zu teilen.
Betreiben Sie Entwicklung, Staging und Produktion als getrennte Dagu-Instanzen. Übernehmen Sie nur geprüfte Workflow-Definitionen über Git, während jede Instanz eigene Zugangsdaten, Worker, Verläufe, Zugriffsrichtlinien und Incident-Routen behält.
agent-workflow.yaml
name: release-review
steps:
- id: collect_context
run: ./scripts/collect-context.sh
output: CONTEXT
- id: draft
action: harness.run
with:
provider: codex
prompt: |
Review this release:
${steps.collect_context.outputs.CONTEXT}
retry_policy:
limit: 2
approval:
prompt: Review the agent output before release
rewind_to: collect_context
depends: [collect_context]
- id: publish
run: ./scripts/publish.sh
depends: [draft]
Eine getrennte Dagu-Instanz pro Umgebung
Workflow-Promotion nach Git-Review
Freigaben, Retries, Logs, Metriken und Traces
Slack, PagerDuty und authentifizierte MCP-Wiederherstellung
Umgebungsarchitektur
Git befördert Definitionen. Getrennte Instanzen schaffen Isolation.
Ein Entwicklungs-Workspace auf einem gemeinsamen Server ist keine Produktionsgrenze. Geben Sie jeder Umgebung einen eigenen Dagu-Server, Speicher, Zugangsdaten, Worker und Netzwerkzugriff. Konfigurieren Sie Git Sync jeder Instanz für den Branch, der für diese Umgebung freigegeben ist.
Per Pull Request befördern
02
Staging
staging-Branch
Laden Sie geprüfte Definitionen in eine isolierte Instanz und validieren Sie sie gegen Staging-Abhängigkeiten.
Git Sync schreibgeschützt
Per Pull Request befördern
03
Produktion
geschützter main-Branch
Führen Sie nur beförderte Revisionen mit produktionsspezifischen Zugangsdaten, Richtlinien, Telemetrie und Incident-Routen aus.
Git Sync schreibgeschützt
Produktionskontrollen
Umschließen Sie nichtdeterministische Arbeit mit deterministischen Kontrollen.
Modell oder Agent-Runtime können wechseln, ohne den betrieblichen Vertrag zu ändern. Dagu hält den umgebenden Ausführungspfad explizit, prüfbar und wiederherstellbar.
Workflow versionieren
Speichern Sie DAG-Definitionen und Skills zur Workflow-Erstellung in Git, prüfen Sie Diffs und befördern Sie eine bekannte Revision zwischen Umgebungen.
Nebenwirkungen freigeben
Pausieren Sie nach der Agent-Ausgabe, sammeln Sie Review-Eingaben und geben Sie den Workflow vor einer Produktionsaktion frei, lehnen ihn ab oder senden ihn zurück.
Fehler begrenzen
Verwenden Sie Abhängigkeiten, Timeouts, begrenzte Retry-Regeln, Queues und Nebenläufigkeitskontrollen statt unbegrenzter Prompt-Verkettung.
Ausgabe validieren
Führen Sie deterministische Tests, Richtlinienprüfungen oder externe Evaluationen vor Freigabe oder Veröffentlichung als normale Workflow-Schritte aus.
Ausführung beobachten
Prüfen Sie Verlauf, Logs und Artefakte; exportieren Sie Metriken nach Prometheus und DAG-/Schritt-Traces über OpenTelemetry.
Wiederherstellung steuern
Benachrichtigen Sie den Betrieb, öffnen Sie Incidents nach ausgeschöpften Retries und lassen Sie autorisierte MCP-Clients Runs untersuchen und wiederherstellen.
Git-basierte Promotion
Produktion soll Git konsumieren, keine lokalen Änderungen.
Die Entwicklung darf Änderungen veröffentlichen. Staging und Produktion sollten üblicherweise `push_enabled: false` setzen, geschützten Branches folgen und nur geprüfte Definitionen laden. Für Staging eignet sich automatischer Pull; Produktion kann einen geschützten Branch automatisch laden oder nach Deployment-Freigabe kontrolliert pullen.
Git Sync verfolgt DAG-Dateien und Skills zur Workflow-Erstellung. Secrets, Serverkonfiguration, Speicher, Run-Verlauf, Worker und Netzwerkzugriff bleiben lokal in jeder Dagu-Instanz.
Produktions-config.yaml
git_sync:
enabled: true
repository: github.com/acme/ai-workflows
branch: main
push_enabled: false
auth:
type: token
token: ${GITHUB_TOKEN}
auto_sync:
enabled: true
on_startup: true
interval: 300
Fehler und Wiederherstellung
Machen Sie aus einem Agent-Fehler einen Betriebsprozess.
Dagu trennt normale Benachrichtigungen vom Incident-Lebenszyklus und stellt authentifizierte Workflow-Operationen für MCP-Clients bereit.
- 01
Ein Workflow oder Agent-Schritt schlägt fehl und führt die konfigurierten Retries aus.
- 02
Nach Ausschöpfen der Retries sendet Dagu den endgültigen Fehler an die konfigurierten Slack-Routen.
- 03
PagerDuty-Routing kann einen deduplizierten Incident für den fehlerhaften Workflow öffnen oder aktualisieren.
- 04
Ein autorisierter MCP-Client liest Run und Logs, prüft eine DAG-Änderung vorab und wiederholt oder stoppt den Run mit Dagu-Tools.
- 05
Ein später erfolgreicher Run löst den offenen Incident, solange die Provider-Route identifizierbar bleibt.
Präzise Grenzen
Was Dagu bereitstellt – und was in eine andere Schicht gehört.
Dagu ist die Workflow-Kontrollschicht um ein KI-System. Klare Grenzen machen die Architektur sicherer und die Produktionsaussage nützlicher.
| Dagu stellt bereit | Grenze | |
|---|---|---|
| Umgebungstrennung | Unabhängige Server, Speicher, Zugangsdaten, Worker, Zugriffsrichtlinien und Incident-Konfiguration mit Git Sync für Definitionen. | Workspaces und Runtime-Profile in einer Instanz ersetzen keine harte Isolation von Umgebungen. |
| Workflow-Observability | Run- und Schrittstatus, Logs, Artefakte, Verlauf, Prometheus-Metriken und OpenTelemetry-Traces für DAGs und Schritte. | Prompt-Traces, Token- und Kosten-Telemetrie sowie semantische Ausgabequalität müssen Agent oder Evaluation-Stack liefern oder messen. |
| Evaluation und Guardrails | Einen Graphen für deterministische Validatoren, externe Evaluationen, Freigaben und begrenzte Retries. | Dagu entscheidet nicht, ob eine LLM-Antwort faktisch richtig oder für eine bestimmte Domäne sicher ist. |
| Sicherheit und Incident Response | Authentifizierte Operationen, eingeschränkte API-Schlüssel, Benachrichtigungen, MCP-Kontrollen und Incident-Provider-Routing. | Audit-Logging und Incident-Integrationen bei Self-Hosting erfordern eine aktive Lizenz oder Testphase; Managed Dagu enthält sie. |
FAQ
Praktische Fragen vor dem Produktionsbetrieb
Sollten Entwicklung, Staging und Produktion einen Dagu-Server teilen?
Nicht, wenn Isolation wichtig ist. Betreiben Sie getrennte Instanzen, damit Zugangsdaten, Speicher, Worker, Netzwerk, Logs und Richtlinien keine gemeinsame Betriebsgrenze haben. Befördern Sie Definitionen mit Git Sync.
Kopiert Git Sync Produktions-Secrets oder Run-Verläufe?
Nein. Git Sync gleicht DAG-Dateien und Skills zur Workflow-Erstellung mit einem Repository ab. Secrets, Konfiguration, Speicher, Run-Verlauf und Worker bleiben lokal in jeder Instanz.
Kann Dagu messen, ob eine Agent-Antwort richtig ist?
Nicht allein. Dagu kann Ihre deterministischen Tests oder Evaluation-Tools als Schritte ausführen und die nächste Aktion vom Ergebnis abhängig machen; die Bewertungslogik gehört jedoch zu diesen Tools und den Fachprüfern.
Was kann ein MCP-Client während eines Incidents tun?
Im Rahmen der Dagu-Authentifizierung und -Autorisierung kann er DAGs, Runs und Logs untersuchen, validierte DAG-Änderungen vorab prüfen oder anwenden und Runs starten, einreihen, wiederholen, stoppen oder verfolgen.
Nächster Schritt
Bringen Sie zuerst einen Agent-Workflow in Produktion.
Setzen Sie einen vorhandenen Agent-Befehl hinter einen Dagu-DAG, validieren Sie seine Ausgabe, ergänzen Sie eine Freigabegrenze und befördern Sie dieselbe geprüfte Definition durch isolierte Entwicklungs-, Staging- und Produktionsinstanzen.