AgentenkompassKI-Agenten · Tools · Automatisierung

Tutorial: WordPress-Drafts für KI-Agenten mit REST-API und Freigabe-Gate aufsetzen

Verfasst von

·

Ein guter Redaktionsagent veröffentlicht nicht. Er bereitet vor. Genau das ist der Kern dieses Tutorials: Ein lokaler KI-Agent recherchiert, schreibt, prüft Quellen, lädt ein Featured Image hoch und legt in WordPress ausschließlich einen Entwurf an. Die Veröffentlichung bleibt bei einem Menschen.

Was ist der Workflow?

Der Aufbau ist bewusst klein gehalten: Ein Agent sammelt Quellen, prüft die Erreichbarkeit per HTTP, erstellt den Artikel als HTML, lädt ein 16:9-Bild in die Mediathek und schreibt den Beitrag über die WordPress REST API mit dem Status draft. Danach liest er den Beitrag erneut über die API aus und meldet Post-ID, Slug, Kategorie, Tags und Bild-ID zur Freigabe.

Warum gerade WordPress REST API?

Die WordPress REST API ist die offizielle Schnittstelle, um Inhalte als JSON zu lesen und zu schreiben. Für Beiträge liefert die Posts-Referenz die entscheidenden Felder: title, content, excerpt, status, slug, categories, tags und featured_media. Damit lässt sich ein sauberer Draft-Workflow bauen, ohne direkt im WordPress-Backend zu arbeiten.

Schritt 1: Anwendungspasswort getrennt vom Login nutzen

Für automatisierte Schreibzugriffe sollte kein normales Konto-Passwort im Skript liegen. WordPress unterstützt seit Version 5.6 Application Passwords. Der offizielle Integration Guide beschreibt, dass solche Passwörter separat erzeugt, genutzt und wieder widerrufen werden können. In der Praxis gehört das Passwort in einen sicheren Secret-Speicher, nicht in den Artikel, nicht ins Repository und nicht in Logs.

POST /wp-json/wp/v2/posts
Authorization: Basic base64(user:application_password)
Content-Type: application/json

{
  "title": "Mein geprüfter Entwurf",
  "status": "draft",
  "slug": "mein-gepruefter-entwurf",
  "content": "<p>Artikeltext ...</p>",
  "excerpt": "Kurze Zusammenfassung",
  "categories": [8],
  "tags": [29, 83],
  "featured_media": 123
}

Schritt 2: Draft-only als harte Regel setzen

Der wichtigste Guardrail ist banal, aber wirksam: Der Agent darf nur status: draft senden. Nicht publish, nicht future, nicht „später umstellen“. Zusätzlich sollte der Agent nach dem Erstellen einen REST-Readback machen und abbrechen, wenn der Status nicht draft ist. So wird aus einer redaktionellen Absicht eine technische Kontrollregel.

Schritt 3: Quellen vor dem Schreiben prüfen

Ein redaktioneller Agent sollte keine Quellenliste dekorativ anhängen, sondern sie vorab prüfen: Ist die Seite erreichbar? Ist es eine Primärquelle? Passt sie wirklich zur Aussage im Text? Für Agenten-Workflows ist das besonders wichtig, weil Standards wie das Model Context Protocol externe Tools und Datenquellen leichter anschließbar machen. Je leichter ein Agent handeln kann, desto wichtiger werden klare Grenzen.

Schritt 4: Freigabe-Gate statt Autopublish

Das Freigabe-Gate ist der Moment, an dem der Agent stoppt. Er liefert eine Review-Vorlage mit Post-ID, Preview-Link, Quellen und einer eindeutigen Bestätigungsformulierung. Erst in einer späteren aktiven Session darf daraus eine Veröffentlichung werden. Diese Trennung reduziert das Risiko, dass fehlerhafte Quellen, unpassende Bilder oder eine falsche Einordnung direkt öffentlich sichtbar werden.

Praxis-Einordnung

Für kleine Redaktionsteams ist dieser Ansatz oft sinnvoller als ein großer Publishing-Stack. Der Agent erledigt Fleißarbeit: Recherche, Struktur, Bild, Metadaten, REST-Readback. Die redaktionelle Entscheidung bleibt menschlich. Genau diese Rollenverteilung ist der Unterschied zwischen Automatisierung und Kontrollverlust.

Risiken und Grenzen

  • Zu breite Rechte: Das WordPress-Konto sollte nur die Fähigkeiten haben, die für Entwürfe wirklich nötig sind.
  • Secrets in Logs: Application Passwords dürfen nie in Ausgaben, Reports oder Wissensdatenbanken landen.
  • Tool-Zugriff ohne Grenze: Die OWASP-Übersicht zu LLM-Anwendungsrisiken erinnert daran, dass übermäßige Handlungsmacht und unsaubere Datenflüsse echte Sicherheitsprobleme sind.
  • Öffentliche Sichtbarkeit: Nach der späteren Veröffentlichung reicht ein erfolgreicher API-Call nicht aus. Startseite, Rubrikseite, Card-Link, dunkles Layout und Quellenlinks müssen sichtbar geprüft werden.

Fazit

Ein KI-Agent muss nicht direkt publizieren, um nützlich zu sein. Der bessere Startpunkt ist ein stabiler Draft-Workflow: offizielle API, getrennte Credentials, harte Draft-Regel, Quellenprüfung, Featured Image und ein klarer Freigabeprozess. So entsteht Tempo, ohne die redaktionelle Verantwortung aus der Hand zu geben.

Quellen