OpenClaw 3.8: ACP Provenance, Brave-Suche und warum Tempo die richtige Antwort ist

OpenClaw 3.8 ist ein kleineres Release als 3.7. Weniger geänderte Zeilen, weniger Punkte im Changelog. Aber es steckt ein Feature drin, das deutlich wichtiger ist, als sein Diff vermuten lässt.

ACP Provenance: Deine Agenten wissen jetzt, wer da spricht

Als Agenten nur mit Menschen kommunizierten, war Identität einfach — am anderen Ende der Chat-App saß ein Nutzer. Jetzt sprechen Agenten mit anderen Agenten. Eine OpenClaw-Instanz kann einen Task von einer CI-Pipeline erhalten, von einem Scheduling-Agenten oder von einem anderen OpenClaw-Knoten in einem Multi-Agenten-Workflow. Die Frage „Wer hat das geschickt?" ist schon länger nicht mehr trivial.

3.8 bringt ACP Provenance — optionale Ingress-Metadaten, mit denen dein Agent die Herkunft eingehender ACP-Sessions verifizieren kann. Starte openclaw acp --provenance meta und jede eingehende Session trägt einen signierten Origin-Kontext mit einer Session-Trace-ID. Schalte auf meta+receipt und der Agent injiziert eine sichtbare Quittung in die Konversation — eine auditierbare Kette, wer was ausgelöst hat.

Drei Modi: off, meta, meta+receipt. Standardmäßig deaktiviert — keine Breaking Changes, kein überraschender Overhead. Einschalten, wenn du es brauchst.

Warum das die Schlagzeile ist

Agenten-Identität ist das ungelöste Problem im Multi-Agenten-Stack. MCP regelt den Zugang zu Tools — „Was kann dieser Agent tun." ACP/A2A regelt die Kommunikation zwischen Agenten — „Wie sprechen Agenten miteinander." Aber keines beantwortet: „Wer ist dieser Agent, und sollte ich ihm vertrauen?"

IBMs ACP-Protokoll und Googles A2A haben sich unter der Linux Foundation vereinigt, mit über 100 Unternehmen hinter dem gemeinsamen Standard. DeepLearning.AI bietet bereits einen eigenen Kurs dazu an. Die Branche konvergiert auf Agenten-Interoperabilität, und Identitätsverifikation ist das fehlende Puzzlestück.

OpenClaws ACP Provenance ist ein erster Schritt, nicht die endgültige Antwort. Es löst nicht das gesamte Identitätsproblem — es gibt noch keine Zertifizierungsstelle für Agenten, keinen universellen Agenten-Pass. Aber es liefert ein praktisches Werkzeug für heute: Dein Agent kann jetzt unterscheiden zwischen „Anfrage von meiner vertrauenswürdigen CI-Pipeline" und „Anfrage unbekannter Herkunft" — und entsprechend reagieren.

Für Teams mit Multi-Agenten-Setups ist das der Unterschied zwischen „funktioniert in der Demo" und „funktioniert in Produktion."

Brave LLMContext: Suchergebnisse, die für KI gemacht sind

Websuche in OpenClaw lieferte bisher rohes HTML oder einfache Snippets. Nützlich für Menschen, umständlich für Agenten. Der Agent verbrannte Context-Window-Tokens allein damit, die Seitenstruktur zu parsen und die eigentliche Antwort zu finden.

3.8 fügt Unterstützung für Braves LLMContext-Endpoint hinzu. Einmal konfiguriert, liefert die Websuche vorextrahierte Zusammenfassungsfragmente mit Quell-Metadaten — strukturierte Inhalte, die für Sprachmodelle konzipiert sind. Weniger Rauschen, mehr Signal, weniger verschwendete Tokens.

Das ist keine Kosmetik. Für Agenten, die im Rahmen ihres Workflows das Web durchsuchen, bedeutet es einen kleineren Context-Footprint und genauere Ergebnisse. Der Agent bekommt, was er braucht, ohne vorher HTML-Parser spielen zu müssen.

Podman + SELinux: Enterprise Linux funktioniert endlich einfach

Wer OpenClaw auf Fedora oder RHEL mit SELinux im Enforcing-Modus betrieben hat, kennt das Spiel: mysteriöse Permission-Denied-Fehler, manuelles Hinzufügen von :Z-Labels, Forenthreads voller widersprüchlicher Ratschläge.

3.8 erkennt automatisch, ob SELinux im Enforcing- oder Permissive-Modus läuft, und setzt die korrekten :Z-Volume-Labels. Kein manueller Eingriff. Keine Config-Flags. Es funktioniert einfach.

Kleine Änderung. Große Erleichterung für alle in einer Enterprise-Linux-Umgebung — und angesichts der wachsenden Verbreitung von OpenClaw in regulierten Branchen sind das ziemlich viele.

Docker-Image: Wieder schlanker

Entwicklungsabhängigkeiten und Build-Metadaten wurden aus dem Runtime-Image entfernt. Das Ergebnis: kleinerer Pull, schnellere Kaltstarts, weniger Angriffsfläche.

Nicht viel zu sagen — es ist die Art von Housekeeping, die keinen spannenden Lesestoff abgibt, sich aber über tausende Deployments summiert.

Die Geschwindigkeitsfrage

Manche sagen, OpenClaw aktualisiert zu schnell. Das ist ein berechtigter Einwand, wenn man eine Version pinnen und vergessen will.

Aber tritt einen Schritt zurück und überleg, was „zu schnell" bei einem Open-Source-Projekt wirklich bedeutet. Es bedeutet, dass Pull Requests fließen. Es bedeutet, dass Maintainer reviewen und mergen. Es bedeutet, dass die Contributor-Pipeline — das, was Open Source überhaupt am Laufen hält — kein Rinnsal ist, sondern ein Strom.

Ein Open-Source-Projekt, das schnell genug ist, um schwer mitzuhalten, ist ein Projekt mit einer aktiven Community dahinter. Diese Geschwindigkeit ist ein Signal. Sie sagt dir: Die Spur ist heiß und die Richtung stimmt.

3.7 hat mit ContextEngine das Fundament gelegt. 3.8 füllt die Lücken — Agenten-Identität, intelligentere Suche, breitere Plattform-Unterstützung. Das Tempo lässt nicht nach. Gut so.

Was sich geändert hat