+180 XP

Wiederkehrende Arbeit mit dem OpenAI-Stack automatisieren

# Wiederkehrende Arbeit mit dem OpenAI-Stack automatisieren

Dieses Wettbewerbs-Briefing, das Sie jeden Montagmorgen schreiben, bei dem Sie fünf Konkurrenz-Blogs durchsehen, Preisänderungen zusammenfassen und alles in eine E-Mail kopieren, kann sich selbst erledigen, während Sie schlafen. Der Trick: ChatGPT nicht mehr als Ort behandeln, den man besucht, sondern die OpenAI API als Komponente, die man einplant. Diese Lektion verwandelt einen wiederholten Chat in eine Pipeline, die ohne Sie läuft, mit den Guardrails, die verhindern, dass es teuer oder peinlich wird.

Zwei Wege zur Automatisierung: im Produkt vs. über die API

Bevor Sie Code schreiben: OpenAI bietet eine No-Code-Option. In ChatGPT können Sie mit scheduled tasks den Assistenten bitten, einen Prompt nach einem festen Zeitplan auszuführen und Sie zu benachrichtigen. Das ist wirklich nützlich für persönliche Erinnerungen und leichte Digests. Siehe Scheduled tasks in ChatGPT.

Aber scheduled tasks leben in Ihrem ChatGPT-Konto. Sie können nicht einfach in ein Repo committen, in Ihr Data Warehouse schreiben oder Mail über den transaktionalen Anbieter Ihres Unternehmens versenden. Sobald Sie echte Integration, Versionskontrolle oder einen Service-Account brauchen, der nicht an Ihr persönliches Login gebunden ist, wechseln Sie zur API plus einem externen Scheduler.

Die Entscheidungsregel:

  • Eine Person, leichter Output, benachrichtige-mich: ChatGPT scheduled tasks.
  • Geteilter Output, echte Systeme, auditierbare Runs: API + cron oder CI.

Der Rest dieser Lektion behandelt den zweiten Weg.

Die Pipeline in vier Stufen

Unser Beispiel: jeden Montag um 6 Uhr aktuelle Wettbewerbsinhalte abrufen, ein strukturiertes Briefing erzeugen, es als E-Mail rendern und versenden.

Ein geplanter Job besteht nur aus vier zusammengeklebten Stufen:

1. Gather der Inputs (RSS-Feeds, ein paar URLs, das Briefing der letzten Woche).

2. Generate des Briefings über die API.

3. Validate des Outputs gegen ein Schema.

4. Deliver (E-Mail, Slack, eine committete Datei).

Das Modell besitzt nur Stufe 2. Dass gather, validate und deliver einfacher Code sind (keine Modellaufrufe), macht die Pipeline günstig und vorhersehbar.

Warum Structured Outputs hier nicht verhandelbar sind

Im Chat lesen Sie Prosa und machen weiter. In einer Pipeline ist die nächste Stufe Code, der das Ergebnis *parsen* muss. Wenn das Modell Woche für Woche leicht unterschiedliche Formen zurückgibt, bricht Ihr E-Mail-Renderer.

Nutzen Sie Structured Outputs, um das Modell zu JSON zu zwingen, das einem von Ihnen definierten Schema entspricht. Das ist kein Prompt-Betteln („bitte gib JSON zurück“); die API beschränkt die Generierung auf Ihr Schema. Lesen Sie Structured Outputs.

Den Briefing-Generator bauen

Hier der zentrale Aufruf mit der Responses API, OpenAIs aktueller Hauptschnittstelle für neue Projekte. Beachten Sie den text.format-Block, der die Antwort an ein Schema bindet.

python
import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

SCHEMA = {
    "type": "object",
    "properties": {
        "summary": {"type": "string"},
        "items": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "competitor": {"type": "string"},
                    "headline": {"type": "string"},
                    "why_it_matters": {"type": "string"},
                    "source_url": {"type": "string"},
                },
                "required": ["competitor", "headline", "why_it_matters", "source_url"],
                "additionalProperties": False,
            },
        },
    },
    "required": ["summary", "items"],
    "additionalProperties": False,
}

def build_brief(gathered_text: str) -> dict:
    resp = client.responses.create(
        model="gpt-4.1-mini",
        input=[
            {"role": "system", "content": "You are a competitive analyst. "
             "Only use facts present in the provided sources. If a claim is "
             "not supported, omit it. Never invent pricing or dates."},
            {"role": "user", "content": gathered_text},
        ],
        text={"format": {"type": "json_schema", "name": "brief",
                         "schema": SCHEMA, "strict": True}},
    )
    return resp.output_parsed

Drei bewusste Entscheidungen:

  • Ein kleines, günstiges Modell (hier gpt-4.1-mini) erledigt Zusammenfassungen problemlos. Reservieren Sie Frontier-Modelle für Aufgaben, die tatsächlich Reasoning brauchen. Das ist Ihr größter einzelner Kostenhebel.
  • `strict": True` garantiert, dass das JSON validiert, also kann Stufe 4 ohne defensives Parsing rendern.
  • Der System-Prompt verbietet Erfindungen. Wiederkehrende Jobs laufen unbeaufsichtigt, ein halluzinierter Konkurrenzpreis kann also im Postfach der Geschäftsführung liegen, bevor es jemand merkt.

Inputs sammeln ohne riesiges Context Window

Kopieren Sie nicht fünf komplette Blogs in den Prompt und zahlen für Tokens, die Sie nicht brauchen. Rufen Sie jeden Feed ab, behalten Sie nur Einträge, die neuer als Ihr letzter Run sind, und kürzen Sie jeden Artikel auf den Anfangsteil. Ihr gathered_text wird so ein kompakter, datierter Digest. Weniger Kontext bedeutet niedrigere Kosten, schnellere Runs und weniger Gelegenheiten für das Modell, abzuschweifen.

Hier speichern Sie auch State: Schreiben Sie nach jedem erfolgreichen Run last_run.json, damit Sie nächste Woche nur *neue* Items verarbeiten. Eine Pipeline, die jede Woche dieselben Artikel neu zusammenfasst, ist verschwenderisch und verrauscht.

Delivery: erst rendern, dann senden

Halten Sie das Modell vollständig aus der Delivery heraus. Nehmen Sie das validierte JSON, rendern Sie es mit einem Template und versenden Sie über das, was Ihre Organisation bereits nutzt.

python
def render_email(brief: dict) -> str:
    lines = [f"<p>{brief['summary']}</p>", "<ul>"]
    for item in brief["items"]:
        lines.append(
            f"<li><b>{item['competitor']}:</b> {item['headline']} "
            f"&mdash; {item['why_it_matters']} "
            f"<a href='{item['source_url']}'>source</a></li>"
        )
    lines.append("</ul>")
    return "".join(lines)

Versenden Sie über das SDK Ihres transaktionalen E-Mail-Anbieters oder per SMTP. Der Punkt: Das Modell hat *strukturierte Fakten* produziert, deterministischer Code hat das *Artefakt* produziert. Wenn sich das E-Mail-Layout ändern muss, bearbeiten Sie ein Template, keinen Prompt.

Den Job einplanen

Jetzt machen Sie es wiederkehrend. Zwei saubere Optionen.

Option A: cron auf einem kleinen Server

Auf jeder dauerhaft laufenden Linux-Maschine, crontab -e:

bash
# Monday 06:00, write logs, never let a crash go silent
0 6 * * 1 cd /opt/briefs && /opt/briefs/.venv/bin/python run.py >> /var/log/brief.log 2>&1 || curl -s "$ALERT_WEBHOOK" -d "brief job failed"

Einfach, aber Sie verantworten den Server, die Secrets-Datei und die Uptime.

Option B: GitHub Actions (für die meisten Teams empfohlen)

Runner für Continuous Integration sind für leichte geplante Jobs kostenlos, Secrets werden verwaltet und jeder Run wird geloggt. CI bedeutet hier nur eine gehostete Umgebung, die Ihr Skript bei einem Trigger ausführt.

yaml
name: weekly-brief
on:
  schedule:
    - cron: "0 6 * * 1"   # Mondays 06:00 UTC
  workflow_dispatch: {}    # lets you run it manually to test

jobs:
  brief:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: python run.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          EMAIL_API_KEY: ${{ secrets.EMAIL_API_KEY }}

workflow_dispatch ist die unterschätzte Zeile: Sie gibt Ihnen einen „Run workflow“-Button, mit dem Sie die ganze Pipeline auf Abruf testen können, ohne auf Montag zu warten. Secrets liegen in den verschlüsselten Einstellungen des Repos, nie im Code.

Schedule Python Scripts with GitHub Actions

Watch on YouTube

Guardrails, die es sicher und günstig halten

Ein unbeaufsichtigter Job, der eine bezahlte API aufruft und Ihrem Team E-Mails schickt, braucht Limits. Setzen Sie sie, bevor Sie ausliefern, nicht nach einer überraschenden Rechnung.

Kosten-Guardrails

  • Setzen Sie ein usage limit im API-Dashboard, damit eine außer Kontrolle geratene Schleife Ihr Konto nicht leersaugen kann. Siehe Usage limits.
  • Begrenzen Sie Output-Tokens mit max_output_tokens. Ein Briefing braucht keine 4.000 Tokens.
  • Nutzen Sie ein eigenes Projekt und einen eigenen API-Key für diesen Job. Keys pro Projekt bedeuten, dass Sie genau sehen, was diese Pipeline kostet, und sie unabhängig widerrufen können.
  • Wählen Sie das günstigste Modell, das Ihre Eval besteht. Testen Sie gelegentlich neu; günstigere Modelle werden immer besser.

Korrektheits-Guardrails

  • Grounden Sie das Modell ausschließlich in abgerufenen Quellen und verlangen Sie eine source_url pro Item (das Schema erzwingt das bereits). Ein Item ohne Quelle ist ein Warnsignal, das Ihr Code verwerfen kann.
  • Bauen Sie einen Sanity Check zwischen validate und deliver ein: Wenn items leer ist, senden Sie „keine nennenswerten Änderungen diese Woche“ statt einer leeren Hülle, und wenn es verdächtig lang ist, markieren Sie es zur Prüfung.

Operative Guardrails

  • Scheitern Sie laut. Ein stiller Cron-Job, der vor drei Wochen aufgehört hat zu laufen, ist schlimmer als kein Job. Pingen Sie bei Fehlern einen Webhook an (siehe das cron-Beispiel).
  • Wiederholen Sie transiente Fehler mit Backoff. Netzwerkaussetzer und Rate Limits passieren; umgeben Sie den API-Aufruf mit einem Retry mit ein paar Versuchen.
  • Loggen Sie Token-Verbrauch und Kosten jedes Runs, auch bei Erfolg, damit Sie Drift erkennen.

Wissenscheck

1. Welcher grundlegende Perspektivwechsel ist laut Lektion nötig, um eine wiederkehrende Aufgabe mit dem OpenAI-Stack zu automatisieren?

2. Ein Team braucht ein automatisiertes Briefing, das in ein gemeinsames Repository committet, einen Service-Account ohne Bindung an ein persönliches Login nutzt und auditierbare Runs erzeugt. Welchen Ansatz empfiehlt die Lektion?

3. Warum besteht die Lektion in der vierstufigen Pipeline (Gather, Generate, Validate, Deliver) darauf, dass nur Stufe 2 ein Modellaufruf sein sollte?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen über Structured Outputs, wie in der Lektion beschrieben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Szenarien, in denen ChatGPT scheduled tasks (die No-Code-Option) laut Lektion eine passende Wahl sind.

Wählen Sie alle richtigen Antworten aus.

Skalieren: wenn ein Prompt nicht reicht

Das Single-Call-Design oben ist der richtige Startpunkt und deckt überraschend viel wiederkehrende Arbeit ab. Greifen Sie erst zu mehr Struktur, wenn die Aufgabe sie wirklich braucht.

Wann Tools ergänzen

Wenn der Job entscheiden muss, *welche* Quellen er zieht, oder Live-Systeme aufrufen soll (eine Pricing-API, eine interne Suche), geben Sie dem Modell function calling, damit es diese Aktionen anfordern kann und Ihr Code sie ausführt. Das Modell schlägt vor; Ihr Code entscheidet. So kommt das Modell an nichts heran, was Sie nicht ausdrücklich erlaubt haben.

Wann das Agents SDK sinnvoll ist

Für mehrstufige Jobs (sammeln, entwerfen, den eigenen Entwurf kritisieren, überarbeiten, dann formatieren) gibt Ihnen das OpenAI Agents SDK einen saubereren Weg, Schritte, Tools und Handoffs zu orchestrieren, ohne die Kontrollschleife selbst zu bauen. Nutzen Sie es, wenn Ihre Pipeline echte Verzweigungslogik hat. Greifen Sie nicht dazu, um einen Feed zusammenzufassen; das ist Overengineering, und jeder zusätzliche Modellaufruf bedeutet Latenz und Kosten.

Eine Anmerkung zum ChatGPT-Agent und zu Codex

Der ChatGPT agent kann in einer Session browsen und agieren, um Aufgaben zu erledigen, und Codex kann Code für Sie schreiben und ausführen. Beide sind hervorragend, um diese Pipeline interaktiv zu *bauen und zu prototypen*. Aber die Produktionsversion eines wiederkehrenden Jobs sollte deterministischer Code unter Versionskontrolle mit einem Scheduler sein, keine interaktive Agent-Session, die Sie bewachen müssen. Bauen mit dem Agent; ausliefern mit der API.

Alles zusammensetzen

Ihr run.py sind jetzt nur die vier Stufen in Folge:

python
def main():
    state = load_state("last_run.json")
    gathered = gather_sources(feeds, since=state["last_run"])
    if not gathered.strip():
        notify("No new competitor content this week.")
        return
    brief = build_brief(gathered)
    if not brief["items"]:
        notify("No notable changes this week.")
        return
    send_email(render_email(brief))
    save_state("last_run.json", now())

if __name__ == "__main__":
    main()

Lesbar, testbar und langweilig im besten Sinne. Das Modell ist eine Zeile in der Mitte. Alles darum herum ist einfacher, debugbarer Code, genau die Eigenschaft, die Sie bei etwas wollen, das ohne Ihre Aufsicht läuft.

Wichtigste Erkenntnisse

  • Lassen Sie dem Modell nur die Generierung. Gather, validate und deliver gehören in deterministischen Code. Diese Trennung macht geplante Jobs günstig und zuverlässig.
  • Erzwingen Sie Structured Outputs mit `strict": True`, damit die nächste Stufe Ergebnisse ohne defensiven Code und ohne wöchentliche Ausfälle parsen kann.
  • Planen Sie für Teams mit GitHub Actions: verwaltete Secrets, geloggte Runs und ein workflow_dispatch-Button zum Testen auf Abruf. Nutzen Sie cron nur, wenn Sie die Maschine kontrollieren.
  • Setzen Sie Guardrails vor dem Ausliefern: ein hartes usage limit, einen API-Key pro Projekt, das günstigste Modell, das Ihre Eval besteht, begrenzte Output-Tokens und einen Failure-Webhook, damit ein toter Job nie unbemerkt bleibt.
  • Interaktiv bauen, deterministisch ausliefern. Prototypen Sie mit dem ChatGPT-Agent oder Codex, aber betreiben Sie den wiederkehrenden Job als versionskontrollierten Code; greifen Sie zum Agents SDK nur, wenn die Aufgabe echte mehrstufige Verzweigungen hat.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Geplante Tasks als vollständige, eigenständige Prompts schreiben, die das Verhalten in ruhigen Wochen festlegen
  • Harte Abrechnungslimits setzen, mit separaten API-Keys pro Umgebung
  • Lassen Sie das Modell nur die Generierung übernehmen; Sammeln, Validieren und Ausliefern erledigt der Code
Vollständiges Action Playbook ansehen →

Zurück

Ecosystem-Integrationen

Weiter

Capstone: ein echter End-to-End-ChatGPT-Workflow