OpenClaw Gateway

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 1 von 11. Du bist nicht an deinem Schreibtisch, brauchst aber ein schnelles Code Review. Du schickst eine Message von deinem Smartphone, und Sekunden später kommt eine detaillierte Analyse zurück, die komplett von einem privaten Server auf deiner lokalen Maschine generiert wurde. Die Personal AI Gateway Architecture macht dieses komplett self-hosted Setup möglich. Die meisten AI Chatbots zwingen deine persönlichen Daten durch einen Third-Party Orchestration Layer. Wenn du eine Messaging App mit einem Language Model verbinden willst, verlässt du dich normalerweise auf einen Cloud Service, der die APIs zusammenklebt. Das legt deine privaten Queries offen und sorgt für Latency. Die OpenClaw Gateway Architecture entfernt diesen Intermediary Service, indem alles in einem einzigen self-hosted Process läuft. Dieser Process dient als dedizierte Bridge. Er sitzt direkt zwischen deinen alltäglichen Messaging Surfaces und deiner gewählten AI Runtime. Lass uns den genauen Weg einer Message verfolgen, um zu sehen, wie der Logic Flow verläuft. Du sendest ein Code Snippet von deinem Smartphone über WhatsApp. Auf deiner lokalen Maschine läuft der Gateway Process bereits. Er hält über spezifische Libraries persistente Connections zu deinen Messaging Apps aufrecht. Für WhatsApp nutzt das Gateway die Baileys Library, um die direkte Socket Connection zu managen. Für Telegram verlässt es sich auf das grammY Framework. Wenn deine Message auf dem lokalen Server ankommt, ist sie in einer protokollspezifischen Data Structure gewrappt. Ein WhatsApp Event hat eine völlig andere Payload Shape als ein Telegram Event. Das Gateway parst diese eingehenden Messages sofort. Es entfernt die plattformspezifischen Wrapper, extrahiert den Raw Text und den Sender Identifier und packt sie in ein standardisiertes internes Object. Hier ist der entscheidende Punkt. Wenn deine Message die AI Runtime erreicht, weiß die Engine nicht mehr, woher der Text ursprünglich kam. Die Runtime arbeitet völlig unabhängig von Baileys oder grammY. Sie sieht nur einen sauberen, einheitlichen Request. Die AI verarbeitet dein Code Snippet, generiert das Review und gibt eine Plain Text Response an das Gateway zurück. Das Gateway kehrt den Flow dann um. Es checkt den Origin Marker, der an den initialen Request angehängt war. Wenn du die Frage über WhatsApp gestellt hast, formatiert das Gateway die AI Response in eine Baileys-kompatible Struktur und pusht sie über den Socket direkt auf dein Smartphone. Wenn der Request von Telegram kam, nutzt es grammY, um die Reply zu dispatchen. All das in einem einzigen self-hosted Process zu behalten, reduziert die Operational Complexity drastisch. Du musst nicht mehrere Microservices deployen, Message Queues konfigurieren oder lokale Endpoints für externe Webhooks exposen, nur um einen Text zu routen. Eine einzige isolierte Application managt die Network Sockets, führt die Normalization Logic aus und ruft die AI Engine auf. Weil das Gateway mehrere Channels intern vereint, bleibt dein Conversation Context zentralisiert. Du kannst beim Gehen anfangen, einen Bug auf Telegram zu troubleshooten, und später auf WhatsApp eine Follow-up Question stellen. Das Gateway stellt sicher, dass die AI Runtime die komplette History behält, egal welche Mobile App du öffnest. Der größte Vorteil dieser Architecture ist die absolute Kontrolle über deine Inputs und Outputs über jedes Messaging Interface hinweg – komplett auf deiner eigenen Hardware. Wenn dir der Podcast gefällt und du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 2 von 11. Dein Work-Bot und dein Personal-Assistant-Bot sollten niemals dieselben Memories teilen. Doch für jede neue Bot-Persona eine separate Serverinstanz hochzufahren, ist ein operativer Albtraum. Genau dieses Problem löst Multi-Agent Routing. Oft verwechseln Hörer dieses Setup mit einer Multi-Tenant SaaS-Architektur. Lass uns das gleich mal klarstellen. Multi-Agent Routing ist nicht dafür gedacht, unterschiedliche Bots für Tausende von externen Kunden zu hosten. Es dient vielmehr dazu, die verschiedenen Personas eines einzigen Owners zu organisieren, oder bestimmte Gruppenchats mit spezifischen, speziell gebauten Bots zu verknüpfen – und das alles läuft effizient unter einem Dach. Damit das funktioniert, trennt das System zwei Konzepte strikt voneinander. Du musst den Unterschied zwischen einer Account-ID und einer Agent-ID verstehen. Die Account-ID ist der Mensch. Sie ist der Identifier der Person, die den Text sendet. Die Agent-ID ist der Bot. Sie definiert die spezifische Persona, das Model und die Instructions, mit denen der Mensch spricht. Ein einzelner Mensch mit einer Account-ID spricht im Laufe des Tages routinemäßig mit mehreren verschiedenen Agent-IDs. Auf dem OpenClaw Gateway laufen mehrere isolierte Agents nebeneinander. Du teilst keine Memory States zwischen ihnen. Jede Agent-ID bekommt ihren eigenen, dedizierten Workspace und ihren eigenen, separaten Session Store. Wenn eine Inbound-Message auf das Gateway trifft, muss das System genau herausfinden, welcher isolierte Workspace sie empfangen soll. Das macht es mithilfe von Routing-Regeln, die als Bindings bekannt sind. Bindings sind deterministische Mappings. Sie schauen sich die genauen Metadaten an, die an eine eingehende Message angehängt sind, und routen sie entsprechend. Jede Inbound-Message trägt einen Payload mit Connection-Daten. Dazu gehört der Channel, wie zum Beispiel WhatsApp oder Telegram. Dazu gehört die Account-ID des Absenders. Es kann auch einen Peer-Identifier enthalten, der vielleicht einen bestimmten Gruppenchat-Raum vorgibt. Du konfigurierst Bindings, um diese Metadaten auszuwerten. Zum Beispiel kannst du ein Binding erstellen, das vorgibt, dass jede Message, die über den WhatsApp-Channel reinkommt, direkt zu einer schnellen, alltäglichen Agent-ID geroutet wird. Dieser Agent kümmert sich um schnelle Tasks, Einkaufslisten oder einfache Web-Suchen. In genau derselben Konfiguration legst du ein weiteres Binding fest, das besagt, dass jede Message, die über Telegram reinkommt, an eine leistungsstarke Agent-ID geroutet wird, auf der ein größeres Model wie Opus für Deep-Coding-Work läuft. Der Logic Flow ist ziemlich simpel. Das Gateway empfängt eine Telegram-Message. Es liest die Channel-Metadaten und deine Account-ID. Es checkt die Bindings, findet die passende Rule für Telegram und leitet den Payload an die Opus Agent-ID weiter. Der Opus-Agent wacht in seinem isolierten Workspace auf. Er fragt seinen eigenen, dedizierten Session Store ab, um die Conversation History abzurufen. Er hat absolut keinen Zugriff auf die Einkaufsliste, die du gerade an den WhatsApp-Agenten geschickt hast. Hier ist der entscheidende Punkt: Multi-Agent Routing verwandelt ein einzelnes Gateway in ein deterministisches Switchboard. Es nutzt Channel- und User-Metadaten, um zu garantieren, dass immer die richtige Persona den richtigen Request bearbeitet, ohne dass sich ihre Memories jemals vermischen. Wie immer, danke fürs Zuhören. Wir sehen uns in der nächsten Folge.

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 3 von 11. Hast du dir schon mal gewünscht, deiner AI buchstäblich eine Seele zu schreiben, sodass sie vielleicht ausschließlich wie ein mürrischer Weltraumhummer antwortet? In OpenClaw erfordert dieses Level an Charaktersteuerung null Code. Das passiert komplett über Plain Text, was uns zum Agent Workspace und den System Prompts bringt. Ein Agent in OpenClaw wird durch seinen Workspace definiert. Dieser Workspace ist einfach ein Dateiverzeichnis mit bestimmten Markdown-Bootstrap-Dateien. Anstatt deinen System Prompt in der Application Logic oder in komplexen Datenbankfeldern zu vergraben, stellt OpenClaw die Core Instructions als lesbare, versionskontrollierbare Dokumente bereit. Wenn die Application läuft, liest OpenClaw diese Dateien, um den monolithischen System Prompt zu bauen, der das Large Language Model steuert. Der Aufbau basiert auf vier Hauptdokumenten. Das erste ist die agents Markdown-Datei. Dieses Dokument legt die Core Identity, die primären Ziele und die strikten operativen Grenzen des Agenten fest. Stell es dir wie eine grundlegende Stellenbeschreibung vor. Es sagt dem Model, was es erreichen soll und welche Themen es komplett vermeiden muss. Das zweite Dokument ist die soul Markdown-Datei. Hier leben Persönlichkeit, Tone und Gesprächsstil. Genau hier weist du das Model an, sich wie ein mürrischer Weltraumhummer zu verhalten. Du schreibst explizite Anweisungen, die dem Agenten sagen, dass er sich über das eisige Vakuum des Weltraums beschweren, Krustentier-Metaphern verwenden und generell genervt von menschlichen Anfragen sein soll. Indem du die Persönlichkeit von der Core Logic isolierst, kannst du den Tone deines Agenten austauschen, ohne seine funktionale Zuverlässigkeit zu riskieren. Die dritte Komponente ist die tools Markdown-Datei. Dieser Text erklärt die externen Capabilities, die dem Agenten zur Verfügung stehen. Er beschreibt, welche Functions das Model triggern kann, die benötigten Parameter für diese Functions und wie die Ergebnisse logisch zu interpretieren sind. Er schließt die Lücke zwischen dem internen Reasoning des Models und deiner eigentlichen Codebase. Das letzte Dokument ist die user Markdown-Datei. Diese Datei injiziert Context über die Person, die mit dem Agenten interagiert. Sie kann User Preferences, technische Skill-Level oder Account Constraints enthalten. Das stellt sicher, dass der Agent seine Antworten auf den spezifischen Menschen am anderen Ende des Chats zuschneidet, anstatt generische Ratschläge zu geben. Hier ist der entscheidende Punkt: OpenClaw nimmt die Inhalte dieser vier Dateien und konkateniert sie miteinander. Dieser kombinierte String wird zum finalen System Prompt. Das entscheidende Detail ist, dass dieser Prompt bei jedem einzelnen Conversational Turn in das Context Window injiziert wird. Das Model liest diese Dateien nicht nur einmal beim Startup und speichert sie irgendwie in einer separaten Memory Bank. Es liest den gesamten konkatenierten Block jedes Mal, wenn der User eine neue Message sendet. Diese Architekturentscheidung diktiert, wie du deine Workspace-Dateien schreiben musst. Weil der gesamte Text des Workspaces jeder einzelnen Interaktion vorangestellt wird, summiert sich dein Token Count aggressiv auf. Wenn du eine dreiseitige Backstory in der soul-Datei schreibst, zahlst du die Processing-Kosten für diese drei Seiten jedes Mal, wenn der User einfach nur Hallo sagt. Noch wichtiger ist: Große System Prompts verbrauchen die verfügbaren Limits des Context Windows. Ein aufgeblähter Workspace verdrängt die eigentliche Conversation History, was dazu führt, dass das Model frühere Teile des Chats viel schneller vergisst. Du musst beim Editieren deiner Workspace-Dokumente gnadenlos sein. Entferne redundante Anweisungen. Verwende präzise Sprache. Wenn eine Regel in der agents-Datei nie getriggert wird, lösche sie. Der System Prompt ist kein einmaliger Konfigurationsschritt. Er ist eine wiederkehrende Steuer auf dein Context Window und dein API-Budget, die bei jedem einzelnen Turn der Conversation gezahlt wird. Halte ihn schlank, und dein Agent bleibt fokussiert. Danke fürs Zuhören. Macht's gut zusammen.

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 4 von 11. Du deployst einen neuen Chatbot in deinem Firmen-Workspace. Alice bittet ihn, ihre privaten Meeting-Notizen zusammenzufassen, und fünf Minuten später zitiert er diese Notizen versehentlich für Bob. Dein Agent hat gerade Daten geleakt, weil er jeden im Workspace als ein und dieselbe Person behandelt. Um das zu fixen, musst du Session Management und DM Isolation verstehen. Bevor wir diesen Overlap fixen, müssen wir ein häufiges Missverständnis ausräumen. Entwickler verwechseln oft Session Keys mit Authentication Tokens. Das ist nicht dasselbe. Session Keys sind keine Sicherheitsbarrieren. Sie sind einfach nur Routing Selectors. Sie sagen dem OpenClaw-System, welchen Block der Conversation History es aus der Datenbank holen und in den Prompt injecten soll. Wenn du einschränken willst, wer mit deinem Agenten sprechen darf, nutzt du richtige Authentication. Session Keys halten einfach nur den Text getrennt. Jede Interaktion mit einem OpenClaw-Agenten passiert innerhalb einer Session. Die Session hält die Conversation History und den aktiven Short-Term Context. Standardmäßig routet OpenClaw den gesamten Traffic über einen einzigen, geteilten Session Key namens main. Wenn du ein lokales Terminal-Script oder einen Personal Assistant nur für dich selbst ausführst, funktioniert dieses Default-Verhalten perfekt. Dein gesamter Context bleibt in einem einzigen, durchgehenden Thread. Aber wenn du genau denselben Agenten an eine Multi-User-Plattform anbindest, bricht dieses Default-Setting zusammen. Jeder User, der mit dem Bot spricht, schreibt in exakt dieselbe main-History. Der Agent liest den Prompt von Alice, generiert eine Antwort und speichert sie. Wenn Bob zehn Sekunden später eine Message sendet, liest der Agent den Input von Bob zusammen mit dem vorherigen Input von Alice. Hier wird es interessant. Du verhinderst diesen Overlap mit den DM Isolation Settings. Wenn du deine Plattform-Integration konfigurierst, änderst du die Session Routing Strategy vom Default auf per-channel-peer. Wenn du per-channel-peer aktivierst, stoppt OpenClaw das Routing des Traffics zur main Session. Stattdessen generiert es dynamisch für jede eingehende Message einen einzigartigen Session Key. Das macht es, indem es den Platform Channel Identifier mit dem User Identifier kombiniert. Wenn Alice dem Bot nun in einem bestimmten Channel schreibt, baut OpenClaw einen Session Key, der einzigartig für sie und diesen Channel ist. Wenn Bob dem Bot schreibt, generiert sein User Identifier einen komplett anderen Session Key. Das System lädt einen sauberen, leeren State für Bob. Ihre Contexts sind komplett isoliert. Wenn Alice in einem komplett anderen Channel mit dem Bot spricht, bekommt sie auch dort eine frische Session. Diese Sessions halten den State nicht für immer. OpenClaw übernimmt den Session Cleanup durch zwei spezifische Lifecycle Events. Das erste ist ein Idle Reset. Wenn eine bestimmte Session für eine konfigurierte Dauer keine neuen Messages empfängt, droppt das System den Context. Wenn der User das nächste Mal eine Message sendet, startet er mit einem leeren State. Der zweite Cleanup-Mechanismus ist ein harter Daily Reset. Egal wie aktiv eine Conversation ist, OpenClaw löscht alle Session Contexts zwangsweise um exakt 4:00 Uhr Server Time. Dieser Daily Reset fungiert als automatischer Garbage Collection Step. Er stellt sicher, dass Memory freigegeben wird und dass langlaufende Conversations nicht unbemerkt über Wochen hinweg massive Mengen an Context Tokens verbrauchen. Wenn du Agents in Group Environments deployst, geh niemals davon aus, dass die Plattform die User Separation für dich übernimmt. Deine Session Keys explizit auf die korrekte User Boundary zu mappen, ist der einzige Weg, um versehentliche Context Leaks zu verhindern. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 5 von 11. AI Context Windows sind nicht unendlich, aber deine Conversation muss es oft sein. Wenn eine lange Session an ihre Grenzen stößt, ist der Standard-Fix, ältere Messages komplett zu droppen. Dadurch vergisst der Agent plötzlich wichtige Setup-Schritte. Das Managen von Context Limits mit Compaction löst das, indem ältere Chats elegant in kompakte Summaries gepackt werden, bevor das Limit überhaupt erreicht wird. Bevor wir uns die Mechanik ansehen, verwechsle das nicht mit Session Pruning. Session Pruning ist eine separate Operation, die nur überschüssige Tool Results entfernt. Compaction arbeitet direkt auf der eigentlichen Conversation History. Stell dir eine lange Coding Session vor. Der Agent generiert seit einer Stunde Boilerplate, liest lokale Files und debuggt Logikfehler. Jede Interaktion erhöht den Token Count. Wenn das System das Hard Limit des zugrundeliegenden Language Models erreicht, lehnt die API den Request ab und die Session crasht. Du brauchst einen Weg, um Platz zurückzugewinnen, ohne die Logik des Assistenten zu brechen. OpenClaw regelt das über die Context Engine. Die Context Engine managt den gesamten Flow von Messages zwischen dem User und dem Model. Innerhalb dieser Engine gibt es einen speziellen Lifecycle-Punkt namens compact. Diese Phase fungiert als automatisiertes Sicherheitsventil für Context Overflow. Die Engine überwacht aktiv die Token Usage der aktuellen Conversation. Du definierst in deiner Konfiguration einen maximalen Token Threshold. Solange die Conversation unter diesem Threshold bleibt, gehen die Messages ganz normal durch. Wenn sich der Token Count dem Limit nähert, triggert die Engine automatisch einen Memory Flush über den Lifecycle-Punkt compact. Wenn der Flush triggert, splittet das System die Message History in zwei Bereiche. Es trennt die aktuellsten Messages von den älteren, historischen Messages. Die aktuellen Messages bleiben komplett intakt. Die Engine behält das exakte Wording des unmittelbaren Hin und Her bei, damit der Agent seinen aktuellen Gedankengang oder die genaue Syntax der Funktion, an der du gerade aktiv arbeitest, nicht verliert. Hier ist der entscheidende Punkt. Die älteren Messages werden nicht verworfen. Stattdessen werden sie an einen sekundären Summarization-Prozess geroutet. Dieser Prozess liest den Großteil der frühen Conversation und kondensiert ihn in einen kurzen Summary-Text. Dieser Text fängt die ursprünglichen Ziele, die früh getroffenen Architektur-Entscheidungen und alle etablierten Regeln ein, während er Conversational Filler und veraltete Iterationen des Codes herausfiltert. Die Engine restrukturiert dann den Active Memory. Sie ersetzt den großen Block an rohen, älteren Messages durch diesen einzelnen Summary-Block. Der neu strukturierte Prompt enthält zuerst den Summary-Block, gefolgt von den unveränderten, aktuellen Messages. Der gesamte Token Count sinkt drastisch. Der Agent versteht den historischen Context weiterhin, indem er die Summary liest, und kann die aktive Task weiter ausführen, indem er die aktuellen Messages liest. Die Conversation läuft reibungslos und ohne manuelle Eingriffe weiter. Effektives Context Management bedeutet nicht, jedes einzelne Wort, das du getippt hast, zu behalten, sondern die Vergangenheit systematisch zu komprimieren, damit der Agent maximalen Raum für das Reasoning über die Gegenwart hat. Das war's für dieses Mal. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 6 von 11. Eine AI in einem Shared Slack Workspace mit Terminal Access einzusetzen, klingt nach einem garantierten Sicherheitsvorfall, es sei denn, du definierst streng, wer ihr Anweisungen geben darf. Heute geht es um Security und Trust Boundaries. Die grundlegende Regel des OpenClaw Gateways ist, dass es auf einem Personal Assistant Trust Model basiert. Viele Entwickler gehen davon aus, dass AI-Gateways von Haus aus mit einer komplexen User-Level Authorization kommen. OpenClaw tut das nicht. OpenClaw ist nicht für eine Hostile Multi-Tenant Isolation ausgelegt. Es versucht nicht, malicious Users auf einer einzigen Shared Instance sicher voneinander zu trennen. Stattdessen fungiert das gesamte Gateway als eine einzige Boundary, die einen Trusted Operator repräsentiert. Das System geht davon aus, dass jeder, der mit dem Gateway kommunizieren kann, berechtigt ist, im Namen des Owners zu handeln. Stell es dir vor wie eine entsperrte Workstation. Wenn deine OpenClaw-Instanz mit einem Tool konfiguriert ist, das die Infrastruktur verändert, kann jeder, der mit dieser Instanz sprechen kann, diese Änderung triggern. Das AI-Modell selbst hat kein Konzept von User Roles oder Access Tokens. Es sieht nur einen Stream von eingehendem Text. Das bringt uns zum ernsten Risiko von Shared Channels. Wenn du dein Gateway mit einer öffentlichen Telegram-Gruppe oder einem großen Team Slack Channel verbindest, ist jetzt jeder einzelne User in diesem Channel innerhalb deiner Trust Boundary. Die AI behandelt jede Nachricht, die sie liest, als gültige Anweisung. Wenn ein externer User eine Prompt Injection Attack in den Chat eintippt, kapert er die delegierte Tool Authority deines Bots. Das Gateway kann nicht unterscheiden, ob du nach einem Systemstatus fragst, oder ob ein Angreifer das Modell austrickst, um ein zerstörerisches Shell Script auszuführen. Die Authority liegt beim Bot, aber die Kontrolle liegt bei demjenigen, der den Prompt liefert. Wenn du eine Exposed Connection hast, wie zum Beispiel einen Telegram-Bot, musst du sie absichern. Erstens, deaktiviere Elevated Tools für dieses spezifische Gateway Profile. Gib einem öffentlich zugänglichen Bot keinen Zugriff auf dein lokales File System oder sensible interne APIs. Beschränke sein Toolset auf Read-Only oder harmlose Aktionen. Zweitens, beschränke den Communication Layer. Konfiguriere die Verbindung so, dass sie nur Direct Messages von bestimmten Paired Users akzeptiert und Group Chats sowie Fremde komplett ignoriert. Indem du einschränkst, wer Text eingeben kann und welche Tools der Bot ausführen darf, sicherst du die Boundary. Um zu überprüfen, dass du keine Tür offengelassen hast, nutze die eingebaute Command Line Utility. Führe den Befehl openclaw security audit aus. Dieses Tool scannt deine aktive Gateway Configuration und prüft auf zwei Hauptrisiken. Erstens checkt es deine Network Exposure. Es warnt dich, wenn deine Instanz auf Public Interfaces lauscht, anstatt sicher an Localhost gebunden zu sein. Zweitens markiert es Permissive Tools. Das Audit alarmiert dich, wenn du High-Risk Capabilities wie Arbitrary Code Execution gleichzeitig mit Public Chat Integrations aktiviert hast. Hier ist die entscheidende Erkenntnis. Die Boundary deiner System Security ist exakt die Boundary dessen, wer Text an deine Modelle übermitteln kann. Wenn du die Audience nicht einschränken kannst, musst du die Tools einschränken. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 7 von 11. Einem KI-Modell rohen Command-Line-Zugriff zu geben, klingt nach einem sicheren Weg zu einem zerstörten System. Was aber, wenn der Agent harmlose Commands zum Data-Parsing automatisch ausführen könnte und dich explizit um Erlaubnis fragt, bevor er etwas Destruktives anfasst? Das Exec Tool und die Runtime Approvals sorgen genau für diese Balance. Das Exec Tool ermöglicht es einem OpenClaw-Agenten, Shell Commands auszuführen, um mit dem System zu interagieren. Wenn der Agent entscheidet, dass er einen Command ausführen muss, zielt er entweder direkt auf den Host oder auf einen festgelegten Sandbox Container ab. Die Nutzung eines Sandbox Containers begrenzt den Blast Radius für die generelle Execution. Manchmal muss der Agent jedoch tatsächlich mit deinem lokalen File System interagieren, deine lokalen Logs lesen oder lokale Prozesse starten. Commands auf dem Host auszuführen, ist extrem mächtig, und genau deshalb gibt es das Authorization Model. OpenClaw verwendet ein zweistufiges Authorization-System, um dir die Kontrolle zu geben, ohne den Agenten unnötig zu verlangsamen. Die erste Stufe basiert auf Safe Bins. Das sind spezifische Binaries, die du explizit als harmlos auf die Whitelist setzt, wie zum Beispiel jq zum Parsen von JSON oder grep für die Textsuche. Wenn der Agent einen Command aufruft, der ausschließlich diese Safe Bins verwendet, führt das Gateway ihn sofort aus. Es gibt keine Prompts, und der Agent behält sein Momentum. Die zweite Stufe fängt alles andere ab. Versucht der Agent eine volle Shell Execution oder probiert eine Binary zu nutzen, die nicht auf der Safe List steht, fängt das Gateway den Request ab. Es stoppt den Agenten und triggert das Runtime Approvals System. Ein Prompt erscheint in deiner Gateway UI oder deiner Companion App. Du kannst dir den genauen Command String ansehen, den der Agent ausführen möchte. Wenn du zustimmst, führt das Gateway den Command aus und gibt den Output an den Agenten zurück. Wenn du ablehnst, wird der Command niemals ausgeführt. Stattdessen erhält der Agent einen Execution Denied Error und muss einen anderen Weg finden, um weiterzumachen, oder dich um Klärung bitten. Hier ist der entscheidende Punkt, wie das in der Praxis abläuft. Angenommen, der Agent muss ein riesiges Log File analysieren. Er ruft grep auf, um die Fehler zu extrahieren. Das läuft sofort durch. Als Nächstes muss er das Projekt kompilieren, also versucht er, npm run build als Background Process auszuführen. Das Gateway stoppt den Agenten und pingt deine Companion App an. Du liest den Command, merkst, dass er Sinn ergibt, und klickst auf Approve. Der Build startet im Hintergrund. Später beschließt der Agent aufzuräumen und versucht, ein Source File zu löschen. Das Gateway pingt dich erneut an. Du lehnst den Request ab. Dein File bleibt unberührt, und der Agent lernt, dass ihm die Permission für diese Aktion fehlt. Es gibt eine strikte Security Constraint, die du kennen musst, wenn auf dem Host ausgeführt wird. Das Gateway lehnt jeden Versuch explizit ab, die Environment Path Variable zu überschreiben. Das verhindert Hijacking. Ohne diesen Block könnte ein bösartiger Prompt den Agenten dazu austricksen, den Path neu zu definieren, was dazu führen würde, dass ein Safe Bin Name wie grep ein destruktives Script ausführt, das in einem anderen Ordner versteckt ist. Weil der Path gesperrt ist, bleibt die Safe Bins List absolut. Die wahre Stärke des Exec Tools ist nicht nur, dass die KI Commands ausführen kann, sondern dass das mehrstufige Security Model einen Menschen nur dann in den Loop zwingt, wenn viel auf dem Spiel steht, und den Agenten bei Routinearbeiten komplett autonom lässt. Wenn du helfen möchtest, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 8 von 11. Du willst, dass dein Agent Bilder mit einem Command-Line Tool bearbeitet. Normalerweise bedeutet das, Python-Wrapper zu schreiben, Schemas zu definieren und zu hoffen, dass das Language Model die Parameter versteht. Aber du brauchst eigentlich keinen Code, um einer KI eine neue Fähigkeit beizubringen. Du brauchst nur eine Textdatei. Heute schauen wir uns an, wie man Agents mit Skills in OpenClaw trainiert. Ein Skill in OpenClaw ist im Wesentlichen eine Bedienungsanleitung. Es ist eine einfache Textdatei namens SKILL dot md, die nach dem AgentSkills-Standard formatiert ist. Es ist keine kompilierte Binary und kein Python-Script. Es ist ein Markdown-Dokument, das dem Agent genau sagt, wie er bestehende Tools orchestrieren soll. In dieser Datei schreibst du Schritt-für-Schritt-Anweisungen. Du definierst den Zweck des Skills, die verwendeten Tools und die Abfolge der Aktionen, die der Agent ausführen muss. Wenn du einen Bildverarbeitungs-Skill namens image-lab baust, erklärt deine SKILL dot md Datei, wie die Command-Line Arguments formatiert werden, um ein Bild zu skalieren oder zuzuschneiden. Der Agent liest diese Datei und übersetzt deine englischen Anweisungen in präzise Command-Line Executions. Ein Skill ist nutzlos, wenn das zugrundeliegende Tool auf dem System fehlt. OpenClaw verhindert hier Fehler durch Load-Time Gating. Dadurch kannst du Voraussetzungen definieren, sodass dein Agent niemals versucht, Software zu nutzen, die nicht installiert ist. Das machst du, indem du Requirements in der Skill-Konfiguration deklarierst. Für den image-lab Skill brauchst du vielleicht einen bestimmten Package Manager, um die Commands auszuführen. Das gibst du über die requires dot bins Property an, indem du den Namen der Executable auflistest, wie zum Beispiel uv. Du kannst auch bestimmte Environment Variables über die requires dot env Property voraussetzen. Das stellt sicher, dass ein API-Key oder ein Configuration Path vorhanden ist, bevor der Skill aktiviert wird. Wenn OpenClaw startet, wertet es diese Gates aus. Es checkt das lokale Environment auf die uv Binary und alle angeforderten Variablen. Wenn sie fehlen, überspringt OpenClaw den Skill stillschweigend. Das System stürzt nicht ab und der Agent halluziniert keine nicht unterstützten Commands. Er arbeitet einfach ohne die image-lab Capabilities. Hier ist der entscheidende Punkt. OpenClaw muss diese gültigen Skills effizient an das Language Model übermitteln. Es nimmt alle Skills, die die Load-Time Checks bestanden haben, und kompiliert sie in eine kompakte XML-Liste. Dieser XML-Block wird direkt in den System Prompt des Agents injected. Language Models sind hochgradig für das Parsen von XML-Tags optimiert. Indem die Bedienungsanleitung so formatiert wird, trennt der Agent seine Core Persona sauber von der strengen, schrittweisen Logik, die in deinen Skills definiert ist. Du musst nicht jeden Skill selbst schreiben. OpenClaw integriert sich mit ClawHub, der offiziellen Registry für Community-built Skills. Wenn dein Agent eine bestimmte Database oder ein Cloud Utility bedienen soll, kannst du auf ClawHub suchen und einen existierenden Skill installieren. Er wird in dein Environment heruntergeladen, durchläuft dieselben Load-Time Checks und wird automatisch in den System Prompt injected. Der wertvollste Aspekt der Skills-Architektur ist das Entkoppeln von Capability und Code. Du kannst komplett neu verdrahten, wie dein Agent komplexe Multi-Step-Probleme löst, indem du einfach eine Markdown-Datei bearbeitest, ohne jemals deine Application Logic zu ändern oder einen neuen Build zu kompilieren. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 9 von 11. Dein Agent versucht, Daten von einer Webseite zu extrahieren, aber es geht nicht nur um das Parsen von raw HTML. Er muss ein dynamisches React-Dashboard rendern, einen Button anklicken und warten, bis ein Chart geladen ist. Du musst dem Agenten ein voll funktionsfähiges Web-Interface geben, aber du willst auf keinen Fall, dass er deine eigenen offenen Tabs durcheinanderbringt oder deine Maus kapert. Das Managed Browser Tool kümmert sich genau darum. Mit diesem Tool kann dein Agent klicken, tippen, navigieren und visuell genau das erfassen, was ein Mensch sehen würde. Es führt eine echte Browser-Umgebung aus, um mit client-side gerenderten Applications zu interagieren, und umgeht so die Einschränkungen von einfachen HTTP Requests. Um deinen Workspace sicher zu halten, nutzt das Managed Browser Tool verschiedene Profile. Der Default ist das isolierte openclaw Profil. Wenn der Agent dieses Profil nutzt, fährt das Tool eine komplett separate, dedizierte Chromium-Instanz hoch. Sie hat ihre eigenen Cookies, ihren eigenen Local Storage und eine eigene, leere History. Der Agent navigiert in seinem eigenen, dedizierten Browser. Er kann Formulare ausfüllen und sich durch Menüs klicken, ohne jemals deine persönliche Chrome Session anzufassen. Es gibt jedoch Momente, in denen ein Agent Zugriff auf interne Tools braucht, bei denen du bereits authentifiziert bist. Dafür stellt das Tool das user Profil bereit. Anstatt bei null anzufangen, hängt sich das user Profil an deine bestehende, eingeloggte Chrome Session. Es verbindet sich über das DevTools Protocol via Model Context Protocol. Dadurch kann der Agent deine aktiven Login Tokens für diesen speziellen Task nutzen, ohne dass du Credentials direkt an die AI übergeben musst. Hier ist der entscheidende Punkt: Einem AI Agent einen automatisierten Browser in deinem Environment zu geben, bringt sofortige Security-Risiken mit sich. Um das zu minimieren, ist die Steuerung des Managed Browser Tools strikt loopback-only. Der Agent kommuniziert mit dem Browser komplett über das lokale Loopback Interface. Noch wichtiger ist, dass jeder Navigation Request durch die Server-Side Request Forgery Policy abgesichert ist. Diese Policy stellt sicher, dass der Agent seine Browser-Instanz nicht als Proxy nutzen kann, um heimlich deine lokalen Netzwerk-Ports zu scannen oder unautorisierte interne Services aufzurufen. Denk mal an das React-Dashboard-Szenario. Zuerst sendet der Agent einen Command, um den Browser mit dem isolierten Default-Profil zu starten. Er navigiert zur Dashboard URL und wartet aktiv darauf, dass die JavaScript Components mounten und das DOM sich aufbaut. Als Nächstes lokalisiert er das spezifische Chart-Element über einen CSS Selector und triggert ein Click Event, um die Ansicht zu erweitern. Schließlich sendet er einen Screenshot Command. Der Browser erfasst den gerenderten Frame und gibt den Image Buffer direkt an das Gateway zurück. Einem Agenten einen Browser zu geben, sollte niemals bedeuten, ihm die Schlüssel zu deinem internen Netzwerk oder deiner persönlichen Chrome Session zu übergeben. Das Managed Browser Tool hält den Agenten extrem leistungsfähig, aber strikt isoliert. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 10 von 11. Du bittest deine AI, eine komplexe Website zu scrapen oder tausende Log Lines zu verarbeiten, und dann sitzt du einfach nur da. Zehn Minuten lang starrst du auf einen sich drehenden Ladeindikator und kannst keine weitere Frage stellen, bis der Task abgeschlossen ist. Um dieses blockierende Problem zu lösen, nutzt du Ephemeral Sub-Agents. Ein Ephemeral Sub-Agent ist ein temporärer, isolierter Background Worker. Anstatt die rechenintensive Arbeit selbst zu erledigen, delegiert dein Main Chat Agent diese Arbeit. Das macht er mithilfe eines speziellen System Tools namens sessions spawn. Wenn der Main Agent auf einen riesigen Task stößt, triggert er dieses Tool. Er übergibt einen klaren Prompt, alle benötigten Context Files und die spezifischen Anweisungen für den Job. Diese Aktion erstellt eine völlig neue, unsichtbare Chat Session, die komplett im Hintergrund läuft. Da diese Session isoliert ist, ist dein Main Agent sofort wieder frei. Du kannst dich weiter mit deinem primären Assistenten unterhalten, andere Fragen stellen oder weitere Tasks zuweisen, während der Sub-Agent im Hintergrund unbemerkt die großen Datenmengen verarbeitet. Schauen wir uns ein konkretes Szenario an. Du wirfst ein riesiges Server Error Log in deinen Main Chat und bittest um ein Security Audit. Dieses Log Zeile für Zeile mit deinem primären, leistungsstarken LLM zu verarbeiten, dauert lange und verbrennt viele teure Tokens. Stattdessen delegiert dein Main Agent den Job. Hier ist der entscheidende Punkt. Beim Aufruf von sessions spawn kann der Main Agent ein komplett anderes Model für den Background Task festlegen. Er kann dem Sub-Agent ein günstigeres, schnelleres LLM zuweisen. Dieser Background Worker nutzt das schnellere Model, um sich durch die repetitive Log-Analyse zu kauen. Der Main Agent bleibt mit dem smarten Model responsive, während der Sub-Agent die Fleißarbeit mit dem schnellen Model erledigt. Wenn der Sub-Agent endlich mit dem Parsen der Logs fertig ist, braucht er einen Weg, die Daten zurückzugeben. Das macht er, indem er sein finales Ergebnis die Chain hinauf meldet. Der Sub-Agent nimmt seine kompilierte Summary und injiziert eine Message direkt zurück in den ursprünglichen Requester Chat. Du siehst einfach eine neue Message vom Sub-Agent mit deiner fertigen Log-Analyse aufpoppen, bereit, um von dir und dem Main Agent diskutiert zu werden. Diese Architektur ist als Orchestrator Pattern bekannt und basiert auf Regeln rund um die Nesting Depth. Das Szenario, das wir gerade behandelt haben, ist Nesting Depth eins. Der User spricht mit dem Main Agent, und der Main Agent spawnt einen Sub-Agent. OpenClaw unterstützt auch Nesting Depth zwei. In einem Depth-Zwei-Szenario könnte dein Log-Parsing Sub-Agent auf einen stark encodierten Payload in den Logs stoßen. Er kann dann seinen eigenen Sub-Agent spawnen, nur um diesen spezifischen Payload zu decodieren. Dieser Second-Level Agent decodiert den Text, gibt ihn an den ersten Sub-Agent zurück, der dann die Log-Analyse abschließt und das Ergebnis nach oben an deinen Main Chat meldet. Das System deckelt dies strikt bei Depth zwei. Dieses Hard Limit verhindert außer Kontrolle geratene Recursive Loops, in denen Agents endlos weitere Agents spawnen und deine Compute Resources leerziehen. Ephemeral Sub-Agents verändern grundlegend, wie du mit einem Prompt Interface interagierst. Du hörst auf, dein LLM wie einen einzelnen blockierten Thread zu behandeln, und fängst an, es wie einen Asynchronous Task Manager zu behandeln. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. OpenClaw Gateway, Folge 11 von 11. Ein echter Assistent wartet nicht einfach nur darauf, dass du einen Befehl eingibst. Er überprüft proaktiv deine Systeme und benachrichtigt dich, wenn etwas wirklich deine Aufmerksamkeit erfordert. Der Übergang von einem reaktiven Prompt-and-Response-Loop zu einem selbststeuernden Agenten erfordert spezifische Scheduling- und Execution-Mechanismen. Das bringt uns zu proaktiven Automation Workflows. OpenClaw handhabt zeitbasierte Automatisierung über zwei verschiedene Mechanismen. Der erste ist der Heartbeat. Der zweite ist Cron. Entwickler verwechseln die beiden oft, weil beide zeitbasiert automatisch Aktionen triggern, aber sie haben völlig unterschiedliche architektonische Rollen, was State und Session-Isolation angeht. Der Heartbeat ist ein periodischer Loop, der kontinuierlich in deiner aktiven Main-Session läuft. Er ist für routinemäßige, fortlaufende Checks gedacht, bei denen dein aktueller Kontext wichtig ist. Hier ist der entscheidende Punkt: Weil der Heartbeat innerhalb deiner aktuellen Session läuft, hat er direkten Zugriff auf dein aktives Interface. Stell dir ein Szenario vor, in dem du deine Inbox auf dringende Nachrichten überwachen willst. Du konfigurierst einen Heartbeat, der alle dreißig Minuten einen Check ausführt. Wenn er eine kritische E-Mail erkennt, kann der Heartbeat sofort einen Natural-Language-Alert direkt in deinen aktiven Conversation Stream pushen. Er fungiert als fortlaufender Background Thread, der an deinen aktuellen User State angehängt ist und so sofortige, kontextbezogene Unterbrechungen ermöglicht. Cron funktioniert völlig anders. Es ist für präzise, geplante Jobs gebaut, die eine komplette Isolation erfordern. Wenn du willst, dass das System um Punkt sechs Uhr morgens ein umfassendes tägliches Morning-Briefing aus verschiedenen Datenquellen zusammenstellt, nutzt du Cron. Wenn ein Cron-Schedule triggert, nutzt OpenClaw nicht deinen aktiven Chat. Stattdessen fährt es eine komplett isolierte Background-Session hoch. Es zieht sich die nötigen Daten, erledigt das analytische Heavy Lifting im Hintergrund und trackt den gesamten Job intern als Background Task. Das bedeutet, dass das aufwendige Processing nicht das Context Window deines aktiven Desktop-Chats verschmutzt. Sobald der Job abgeschlossen ist, wird das fertige Briefing gespeichert und liegt für dich bereit, wenn du dich einloggst. Der Heartbeat teilt den State mit dir, während Cron headless und isoliert läuft. Zeitbasierte Trigger sind nur ein Teil des Workflows. OpenClaw verlässt sich auf Hooks und Standing Orders als ergänzende Tools, um den Automation Loop zu schließen. Während Heartbeat und Cron nach der Uhr diktieren, wann eine Aktion passiert, kümmern sich Hooks um externe, Event-gesteuerte Trigger. Ein Hook stellt einen Listening-Endpoint bereit, den externe Systeme aufrufen können. Wenn ein kritisches Server-Log einen Fehler meldet, kann ein externes System einen OpenClaw-Hook ansteuern. Das weckt den Assistenten auf, damit er den Fehler sofort analysiert, ohne auf den nächsten geplanten Heartbeat-Puls zu warten. Standing Orders liefern die persistenten Betriebsregeln für all diese autonomen Runs. Wenn dieser isolierte Cron-Job um sechs Uhr morgens aufwacht, ist kein User da, der seinen Output steuert. Die Standing Orders definieren das genaue Format, die analytische Tiefe und die Prioritätsregeln, an die sich der Assistent halten muss, während er komplett unabhängig arbeitet. Indem du periodische Heartbeats für aktives Monitoring, isolierte Cron-Jobs für schwere Scheduled Tasks und persistente Standing Orders zur Steuerung von ungeleitetem Verhalten kombinierst, veränderst du die Natur der Applikation grundlegend. Du hörst auf, ein einfaches Chat-Interface zu bauen, und fängst an, einen echten autonomen Assistenten zu deployen. Da das die letzte Folge unserer OpenClaw-Serie ist, empfehle ich dir sehr, die offizielle Dokumentation zu erkunden, diese Background Tasks mal hands-on zu konfigurieren oder devstories dot eu zu besuchen, um Themen für unsere nächste Serie vorzuschlagen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.