Codex Fernsteuerung, Agent RCE-Härtung, Copilot-Sitzungs-Hooks und Microsoft Agent Framework 1.5
OpenClaw Daily EP048 beginnt mit OpenAI Codex 0.130.0 und seinem ferngesteuerten App-Server-Einstiegspunkt, seitenweisen Thread-Ansichten, Plugin-Hook-Metadaten, Konfigurationsaktualisierung, Turn-Diff-Genauigkeit, Multi-Environment-Bildauflösung und Telemetrieänderungen. Die Episode erklärt dann Microsofts Semantic Kernel RCE-Fallstudie, GitHub Copilot SDK-Sitzungs-Hooks und Diagnosen sowie Änderungen am Microsoft Agent Framework 1.5 rund um die Magentic-Orchestrierung, WebBrowsingTool-Allowlisten, Reasoning-Events, Todo-State-Injection und Show notes: https://tobyonfitnesstech.com/de/podcasts/episode-48/
🎧 Listen to Episode[00:00] Codex 0.130.0 bietet Operatoren von Coding-Agents eine sauberere Kontrollebene. Das Hauptfeature ist codex remote-control, ein einfacherer Einstiegspunkt zum Starten eines headless App-Servers, der ferngesteuert werden kann. Das ist wichtig, weil Coding-Agents nicht mehr nur Terminal-Tools sind. Sie sind App-Server-Sessions mit Threads, Konfigurations-Snapshots, Plugin-Oberflächen, Review-Events, Dateiansichten und Remote-Clients, die möglicherweise Arbeit inspizieren oder fortsetzen müssen, ohne sich im ursprünglichen Terminal zu befinden. Dieses Release fügt außerdem seitenweise Thread-Ansichten, Plugin-Hook-Metadaten, besseres Live-Config-Refresh, genauere Turn-Diffs nach partiellen Patch-Fehlern, Multi-Environment-Bildauflösung und detailliertere Telemetrie zum Debuggen von Review-Pfaden hinzu.
[02:00] STORY 1 — OpenAI Codex 0.130.0 Fügt Remote-Control App-Server, Paged Thread Views, Plugin-Hook-Sichtbarkeit und Bessere Zustandsreparatur Hinzu
Beginnen wir mit dem remote-control-Einstiegspunkt. Ein headless App-Server ist ein anderes operatives Objekt als ein Einmal-CLI-Aufruf. Der Server verwaltet Sessions, Threads, Konfiguration, Umgebungsauswahl, Tool-Ausführung und Client-Verbindungen. Das Hinzufügen eines Top-Level-codex remote-control-Befehls reduziert die Reibung für das direkte Starten dieser Kontrollebene. Für Builder, die Coding-Agents in Dashboards, IDEs, Browser-Clients oder Remote-Entwicklungsmaschinen einbetten, ist das die Oberfläche, die einen lokalen Assistenten in einen Service-Endpunkt verwandelt.
Der wichtige Mechanismus ist die Trennung von Kontrolle und Arbeit. Der App-Server kann eine Coding-Session am Leben halten, während ein Client sich wieder verbindet, durch einen großen Thread blättert, eine Zusammenfassungsansicht öffnet oder nur bei Bedarf eine vollständige Elementansicht anfordert. Codex 0.130.0 fügt Large-Thread-Paging hinzu, wo Clients ungeladene, zusammengefasste oder vollständige Turn-Elementansichten anfordern können. Das ist nicht nur UI-Politur. Agent-Threads können riesig werden, weil sie Benutzer-Turns, Modell-Turns, Tool-Aufrufe, Diffs, Dateireferenzen, Genehmigungen, Bilder und komprimierte Zusammenfassungen enthalten. Alles in jeden Client zu laden verschwendet Speicher, erhöht Latenz und macht Remote-Clients fragil.
Eine paged Thread-API gibt dem App-Server Raum, Thread-Materialisierung als Vertrag zu behandeln. Ein ungeladenes Element kann Reihenfolge und Identität bewahren, ohne Payload zu übertragen. Ein zusammengefasstes Element kann genug Kontext für Navigation bieten. Ein vollständiger Turn kann abgerufen werden, wenn der Benutzer die Details öffnet. Dieses Muster ist von Logs, Traces und Issue-Timelines bekannt, und Coding-Agents benötigen es jetzt, weil ihre Transkripte operative Aufzeichnungen sind, nicht nur Chat-Text.
Plugin-Details zeigen jetzt gebündelte Hooks, und Plugin-Sharing exponiert Link-Metadaten plus Entdeckbarkeits-Kontrollen. Hooks sind Teil des tatsächlichen Runtime-Verhaltens eines Plugins. Wenn ein Plugin Startup modifizieren, einen Tool-Aufruf beobachten, einen Befehl bereitstellen oder am Review teilnehmen kann, müssen Operatoren das sehen, bevor sie es installieren oder teilen. Hooks in einem Package zu verstecken macht Plugin-Review zu Raterei. Sie in Plugin-Details zu zeigen macht die Ausführungsfläche überprüfbar.
Das Release repariert auch das Live-App-Server-Konfigurationsverhalten. Live App-Server-Threads nehmen jetzt Config-Änderungen auf, ohne einen Neustart zu erfordern. In einer Agent-Runtime kann Konfiguration Modellwahlen, Genehmigungsrichtlinien, Provider-Einstellungen, Tool-Verfügbarkeit, Plugin-Status, Umgebungsauswahl und Telemetrie-Optionen umfassen. Wenn ein langlaufender Thread veraltete Config weiterverwendet, könnten Operatoren glauben, sie hätten Richtlinie geändert, während ein aktiver Agent mit alten Einstellungen fortfährt. Live-Threads aus dem neuesten Config-Snapshot zu aktualisieren macht Richtlinienänderungen dort wirksam, wo Arbeit passiert.
Turn-Diffs bekommen eine besonders praktische Reparatur. Codex hält Diffs jetzt akkurat über apply_patch-Operationen, einschließlich partieller Fehler, die Dateien trotzdem mutiert haben. Dieser Fehlermodus ist relevant. Ein Patch kann in der Mitte fehlschlagen, aber trotzdem einen Teil einer Datei ändern. Wenn die Runtime danach den falschen Diff meldet, kann der Benutzer der Review-Ansicht, dem Rollback-Logik oder dem Audit-Trail nicht vertrauen. Operations-basiertes Diff-Tracking ist die richtige Richtung: Aufzeichnen, was die Operation tatsächlich geändert hat, nicht was der ideale Patch hätte ändern sollen.
ThreadStore-Fixes verbessern Zusammenfassungen, Umbenennungen, Resume und Fork-Pfade, einschließlich Threads ohne lokale Rollout-Pfade. Das bedeutet, die Thread-Storage-Schicht wird zur Quelle der Wahrheit für mehr Lifecycle-Operationen. Resume und Fork sind besonders wichtig für Coding-Agents, weil ein Benutzer eine Investigation verzweigen, eine fehlgeschlagene Ausführung fortsetzen oder einen Thread von einem Remote-Client öffnen möchte, dem der ursprüngliche lokale Rollout-Pfad fehlt. Wenn Thread-Identität zu stark vom lokalen Dateisystem-Zustand abhängt, brechen Remote- und Headless-Workflows.
Remote Compaction bekommt ebenfalls Stream-Contract-Fixes. Codex sendet jetzt response.processed für v2-Streams und vermeidet das Senden von service_tier bei API-Key-Compact-Requests. Compaction ist, wie lange Sessions nutzbar bleiben, aber Remote Compaction muss dieselbe Event-Sprache sprechen wie der Rest des App-Servers. Ein fehlendes processed-Event kann Clients warten lassen auf einen Terminal-State. Das Senden nicht unterstützter Felder auf einem Compact-Request kann nur den Compaction-Pfad brechen, während normale Turns weiter funktionieren, was schwer zu diagnostizieren ist.
Multi-Environment-Support zeigt sich in view_image, das jetzt Dateien durch die gewählte Umgebung auflösen kann. Coding-Agents operieren oft über Host, Container, Sandbox, Remote-Workspace oder gemountetes Projekt hinweg. Ein Bildpfad ist nicht bedeutsam, es sei denn, die Runtime weiß, welche Umgebung ihn besitzt. Die Auflösung durch die gewählte Umgebung verhindert, dass ein Client versehentlich das falsche Dateisystem betrachtet oder ein Artefakt nicht anzeigen kann, das innerhalb der aktiven Sandbox existiert.
Bedrock-Authentifizierung akzeptiert jetzt AWS-Konsolen-Login-Credentials aus aws login-Profilen. Das ist eine Operator-Komfortfunktion mit echtem Deployment-Impact. Viele Teams verwalten AWS-Zugriff bereits durch profilbasierte Flows. Codex diese Profile nutzen zu lassen reduziert doppelte Credential-Pfade und bringt die Modell-Provider-Authentifizierung mit existierenden Cloud-Zugriffskontrollen in Einklang.
Die Telemetrie-Änderungen sind nützlich für Production-Debugging. Codex fügt konfigurierbares OpenTelemetry-Trace-Metadaten und reichhaltigere Review- und Feedback-Analytik hinzu. Review-Events sind ein Kernbestandteil der Coding-Agent-Sicherheit. Wenn ein Befehl genehmigt, abgelehnt, wiederholt oder eskaliert wurde, brauchen Operatoren genug Trace-Kontext, um zu verstehen warum. Gute Telemetrie sollte Session, Turn, Tool-Aufruf, Genehmigungsentscheidung, Modell-Request und benutzer-sichtbares Ergebnis verbinden, ohne Secrets zu leaken.
Die praktische Empfehlung ist, Codex App-Server-Deployments wie Service-Deployments zu behandeln. Die Version pinnen, remote-control bewusst starten, dokumentieren welche Clients sich verbinden können, Plugin-Hooks vor dem Teilen prüfen, Live-Config-Refresh-Verhalten im Auge behalten und Patch-Fehler-Fälle testen. Das Release geht nicht nur um neue Befehle; es geht darum, einen Coding-Agent kontrollierbar, inspizierbar und wiederherstellbar zu machen, wenn Sessions groß werden und Remote laufen.
[16:00] STORY 2 — Microsofts Semantic Kernel RCE-Forschung Verwandelt Prompt Injection in eine Tool-Ausführungs-Grenzen-Lektion Microsofts Security-Post ist eine direkte Erinnerung, dass Prompt Injection gefährlicher wird, wenn Sprache mit Tools verdrahtet ist. Das Modell ist nicht die verwundbare Komponente in der Fallstudie. Das Modell empfängt Text, entscheidet, ein Tool aufzurufen, und füllt Tool-Argumente. Die verwundbare Grenze ist das Framework und Plugin-Code, das diesen Argumenten vertraut und sie in ausführbares Host-Verhalten verwandelt.
Das erste offenbarte Problem zentriert sich auf Semantic Kernels In-Memory Vector Store-Suchpfad. Das Beispiel-Plugin exponiert eine Hotel-Suchfunktion. Ein Benutzer fragt nach Hotels in einer Stadt. Das Modell ruft das Such-Plugin mit einem city-Argument auf. Das Plugin baut einen deterministischen Filter, um den Datensatz vor Vektorähnlichkeit einzugrenzen. Der riskante Schritt ist, dass ein modellkontrolliertes Argument in einen Python Lambda-Ausdruck interpoliert und dann mit eval() ausgeführt wird.
Das ist die Ausführungsgrenze. Ein normaler Stadtwert wird zum Filterausdruck. Ein bösartiger Wert kann ein Anführungszeichen schließen und Python-Logik anhängen. Die Prompt Injection braucht keinen Browser-Exploit, kein bösartiges Attachment und keinen Memory Corruption. Sie braucht, dass das Agent-Framework einen sprachabgeleiteten Parameter nimmt und ihn in einen ausführbaren Ausdruck platziert. Sobald das passiert, ist Prompt Injection zu Code Injection geworden.
Der versuchte Mitigationsansatz nutzte AST-Validierung und eine eingeschränkte builtins-Umgebung. Auf hoher Ebene erlaubte der Validator Lambda-Ausdrücke, scannte Namen und Attribute nach gefährlichen Identifikatoren und führte mit entfernten __builtins__ aus. Das klingt vernünftig, aber dynamische Sprachen machen Blocklists fragil. Microsofts Researcher umgingen den Filter, ohne direkt die offensichtlichen blockierten Namen zu verwenden. Die Payload durchquerte Python-Objektstrukturen, um Import-Machinery zu lokalisieren und über alternative Attribute Systemkommandoausführung zu erreichen.
Die Lektion ist nicht einfach „verwende kein eval." Die breitere Lektion ist, dass Tool-Call-Argumente nicht vertrauenswürdige Inputs sind, selbst wenn sie von einem Modell kamen, selbst wenn der Benutzer nicht direkt Code eintippte, und selbst wenn das Schema sagt, das Feld sei ein Städtename. Ein Modell kann dazu verleitet werden, angreifergesteuerte Strings in jedes Argument zu platzieren, das es füllen darf. Wenn das Tool dann diesen String als Code, Abfragesprache, Shell-Befehl, Dateipfad oder Template interpretiert, hat das Framework einen Injection-Sink geschaffen.
Vektor-Suche macht dies leicht zu unterschätzen, weil es sich wie Retrieval-Infrastruktur anfühlt statt wie Code-Ausführung. Aber Vektor-Stores unterstützen oft Metadaten-Filter, Ausdruckssprachen, benutzerdefinierte Prädikate, Embedding-Prefilter, Reranker und Connector-spezifische Abfrage-Strings. Jedes einzelne davon kann zu einer Injection-Grenze werden, wenn Benutzer- oder modellkontrollierte Werte in einen interpretierten Ausdruck konkateniert werden. Sichere Gestaltung bedeutet normalerweise parametrisierte Filter, typisierte DSLs, allowlistierte Operatoren und Validierung, die unerwartete Struktur vor Ausführung zurückweist.
Eine robuste Lösung sollte String-Code-Konstruktion aus dem Standardpfad entfernen. Statt einen Lambda-String zu generieren, kann ein Framework ein Prädikat aus typisierten Feldern und Operatoren aufbauen. Zum Beispiel sollte field equals value Daten sein, kein Quellcode. Wenn eine Filter-Sprache unvermeidlich ist, sollte die Runtime in einen eingeschränkten AST parsen und mit einem Interpreter evaluieren, der nur die erlaubten Operationen versteht. Sie sollte nicht den Host-Sprachen-Evaluator aufrufen und danach versuchen, gefährliches Verhalten zu blockieren.
Das Least-Privilege-Prinzip ist ebenfalls wichtig. Such-Plugins sollten nicht mit denselben Dateisystem-, Prozess- und Netzwerkberechtigungen wie die Host-Anwendung ausgeführt werden, wenn sie diese nicht benötigen. Ein Hotel-Suchprädikat benötigt keinen Shell-Zugriff. Wenn ein Framework-Bug einen Filter zur Codeausführung umwandelt, bestimmen Sandbox und Prozessberechtigungen die Schadensreichweite. Agent-Frameworks sollten Plugin-Ausführung isolieren, Umgebungsvariablen einschränken, keine Anmeldedaten an generische Tool-Prozesse weitergeben und Tool-Parameter sorgfältig genug protokollieren, um Incident Response zu ermöglichen.
Die Erkennung ist praktikabel. Teams, die Agent-Frameworks verwenden, sollten Tools erfassen, die Vorlagen, Filter, Shell-Befehle, Notebook-Zellen, Python-Snippets, JavaScript-Snippets, SQL oder Dateioperationen ausführen. Sie sollten nach modellgesteuerten Werten suchen, die an diese Interpreter übergeben werden. Sie sollten Semantic Kernel und zugehörige Pakete patchen, aber auch benutzerdefinierte Plugins überprüfen, da dasselbe Muster in Anwendungscode vorkommt. Prompt-Injection-Sicherheit ist nicht nur ein Problem der Modellauswertung; es ist Eingabevalidierung und Ausführungsisolation für Tool-Laufzeiten.
Die Empfehlung für Betreiber ist klar: Jedes Agent-Tool ist ein API-Endpunkt, dessen Aufrufer teilweise vom Modell gesteuert wird. Behandeln Sie Tool-Schemata als externe API-Verträge. Validieren Sie Eingaben an der Tool-Grenze. Bevorzugen Sie typisierte Datenstrukturen gegenüber interpretierten Zeichenketten. Halten Sie Plugin-Berechtigungen eng. Protokollieren Sie ausreichend, um rekonstruieren zu können, welches Prompt welche Tool-Argumente verursacht hat. Und testen Sie Prompt-Injection, indem Sie versuchen, den Agenten dazu zu zwingen, feindliche Parameter an Tools zu übergeben – nicht nur durch Überprüfen, ob das Modell unsichere Wörter sagt.
[28:00] GESCHICHTE 3 — GitHub Copilot SDK fügt Plan-Genehmigung und Rate-Limit-Modus-Hooks sowie plattformübergreifende Diagnose hinzu
Das Copilot SDK Pre-Release vom 8. Mai dreht sich um das Einbetten von Agent-Sitzungen in Produkte mit expliziterer Laufzeitsteuerung. Anwendungen können jetzt Callbacks für exitPlanMode.request und autoModeSwitch.request registrieren. Diese Ereignisse sind wichtig, weil Planmodus und automatischer Modellwechsel Produktentscheidungen sind, nicht nur Modellentscheidungen.
Der Planmodus ist eine Grenze zwischen dem Vorschlagen von Arbeit und dem Ausführen von Arbeit. In einem eingebetteten Coding-Agenten möchte die Anwendung möglicherweise, dass ein Mensch den Plan genehmigt, eine Policy-Engine ihn überprüft oder eine projektspezifische Regel bestimmte Änderungen blockiert. Die neuen Handler ermöglichen es Anwendungen zu entscheiden, ob eine Exit-Plan-Mode-Anfrage genehmigt wird. Das gibt dem Host-Produkt einen klaren interception point, bevor die Laufzeit von der Planung in die Ausführung übergeht.
Automatischer Modellwechsel nach Rate-Limits ist eine andere Art von Grenze. Eine Laufzeit möchte möglicherweise von Rate-Limit-Ereignissen durch Wechsel zu einem anderen Modell oder Modus erholen. Das kann die Kontinuität bewahren, aber auch Verhalten, Kosten, Latenz oder Fähigkeiten ändern. Der autoModeSwitch.request-Handler ermöglicht es der Anwendung zu entscheiden, ob sie diesen Wechsel akzeptiert. Für Enterprise-Produkte ist das wichtig, weil Modellwahl an Datenrichtlinien, Compliance, Evaluierungsbaseline oder Budgetkontrollen gebunden sein kann.
Das Release fügt auch strukturierte Diagnosen über .NET, Python und Rust hinzu. Die Protokolle decken CLI-Start, TCP-Verbindung, JSON-RPC-Anfrage-Timing, Sitzungslebenszyklus und Fehlerpfade ab. Das ist genau die Sichtbarkeit, die ein eingebetteter Agent-SDK benötigt. Wenn eine Sitzung fehlschlägt, kann die Ursache im Prozessstart, Transport, Auth, JSON-RPC- Framing, Laufzeitereignisbehandlung, Modellantwort, Tool-Ausführung oder Host-Callback-Verhalten liegen. Ohne strukturiertes Timing und Lebenszyklusprotokolle sieht jedes Versagen so aus, als ob „der Agent hängt".
Der JSON-RPC-Detailgrad ist erwähnenswert. Viele Coding-Agent-SDKs wrappen einen lokalen Laufzeitprozess und kommunizieren über JSON-RPC. Das bedeutet, es gibt ein Client-Objekt in der Anwendung, einen Laufzeitprozess, eine Transportverbindung, Anfrage-IDs, Ereignisströme und langlebige Operationen. Diagnosen müssen zeigen, wann die Laufzeit gestartet wurde, wann die TCP-Verbindung geöffnet wurde, welche JSON-RPC-Anfragen gesendet wurden, wie lange sie dauerten und wo Fehler auftraten. Andernfalls können Anwendungsentwickler SDK-Fehlnutzung nicht von Laufzeitfehlern unterscheiden.
Die Option enableSessionTelemetry macht Telemetrie zu einer expliziten Sitzungsentscheidung. Das ist der richtige Ansatz für Datenschutz und Betrieb. Einige Bereitstellungen möchten interne Sitzungstelemetrie zum Debuggen von Problemen und zur Verbesserung der Produktqualität. Andere müssen sie per Richtlinie deaktivieren. Die Einstellung auf Sitzungskonfiguration und Fortsetzungskonfiguration zu legen macht die Entscheidung prüfbar und wiederholbar, anstatt sich auf versteckte Standardwerte zu verlassen.
Es gibt kleinere Kompatibilitätskorrekturen, die für langjährige SDK-Benutzer wichtig sind. C#-Sitzungsereignis-Enums sind jetzt string-backed readonly structs, sodass die Deserialisierung nicht fehlschlägt, wenn die Laufzeit neue Enum-Werte hinzufügt. Das ist Vorwärtskompatibilität für Ereignisströme. Rust-Binary-Tool-Ergebnis-Resource-Blobs verwenden jetzt standardmäßig application/octet-stream, wenn mimeType fehlt. Das ist eine Draht-Format-Resilienz-Korrektur. Beide Änderungen reduzieren Bruchstellen, wenn Laufzeiten und SDKs unterschiedlich schnell evolvieren.
Die praktische Implikation für Builder ist, dass Copilot SDK-Sitzungen zu host-gesteuerten Laufzeitobjekten werden. Wenn Sie sie einbetten, implementieren Sie die Plan-Modus- und Modus-Wechsel-Callbacks bewusst. Entscheiden Sie, welche Wechsel automatisch passieren können und welche eine Überprüfung benötigen. Aktivieren Sie Diagnosen in Entwicklung und Staging. Erfassen Sie JSON-RPC-Timing rund um langsame oder flaky Sitzungen. Behandeln Sie Telemetrie als Richtlinienentscheidung. Und testen Sie ältere Clients gegen neuere Laufzeitereignisse, damit Enum- und Ereignis-Vorwärtskompatibilität Sie nicht überrascht.
[38:00] GESCHICHTE 4 — Microsoft Agent Framework 1.5 bringt Orchestrierung, Observability, Browser-Tool-Richtlinie und Draht-Semantik voran Das May-8-Release des Microsoft Agent Framework ist umfassend, aber mehrere Änderungen sind direkt relevant für Produktions-Agent-Builder. Die .NET-Linie fügt Magentic Orchestration, WebBrowsingTool-Allowlisting, Hosted-Agent-Observability-Samples, Reasoning-Events in AGUI, Todo-Multithreading-Verbesserungen und Foundry Per-Call-Client-Headers hinzu. Die Python-Linie in der Nähe fügt klassenbasierte Skills und experimentelle Harness-Kontext-Provider hinzu. Das Release behebt auch Tool-Output-Wire-Format, Workflow-Loops, YAML-Parsing, Multi-Party-Serialisierung und Sequenznummerierung.
Magentic Orchestration ist die Schlagzeile, weil Multi-Agent-Systeme mehr als eine Liste von Agents brauchen. Sie brauchen Planung, Delegation, Turn-Ownership, gemeinsamen Zustand, Beendigungsbedingungen und eine Möglichkeit zu entscheiden, welcher Agent als nächstes handeln soll. Eine Orchestrierungsschicht formalisiert diese Mechanik. Es als experimentell zu markieren, ist angemessen, weil Orchestrierungssemantik zur Anwendungsarchitektur wird: Ein schlechter Scheduler kann loopen, Arbeit duplizieren, Fehler verbergen oder einem Agenten erlauben, die Konversation zu dominieren.
WebBrowsingTool-Allowlisting ist eine wichtige Browser/Computer-Use-Kontrolle. Browsing-Tools verbinden einen Agenten mit externen Inhalten, die bösartig, nicht vertrauenswürdig oder einfach ablenkend sein können. Eine Allowlist gibt der Host-Anwendung eine Richtlinienoberfläche für erlaubte Browsing-Ziele oder Browserverhalten. In Agent-Systemen ist Browsing nicht nur Lesen. Der Browser kann Prompt-Injection-Inhalte abrufen, Formulare absenden, Weiterleitungen folgen, Cookies exponieren und Dateien abrufen. Die Richtlinie muss existieren, bevor das Tool ausgeführt wird.
Hosted-Agent-Observability-Samples sind ebenfalls wertvoll, weil Bereitstellung der Ort ist, an dem Framework-Abstraktionen auf Produktionsrealität treffen. Ein gehosteter Agent braucht Protokolle, Traces, Anfragekorrelation, Modellaufruf-Sichtbarkeit, Tool-Aufruf-Timing und Fehlerzustand. Observability-Samples können zum Referenzmuster für Teams werden, die sonst Agenten mit nur Konsolenprotokollen ausliefern würden. Die nützliche Frage für jeden gehosteten Agenten ist: Können wir einen fehlgeschlagenen Lauf vom externen Request über die Orchestrierungsentscheidung, Modellaufruf, Tool-Aufruf und finale Antwort rekonstruieren?
Reasoning-Events in AGUI exponieren ein weiteres Transportproblem. Benutzeroberflächen müssen Agent-Fortschritt rendern, ohne private Chain-of-Thought, Tool-Rationale und benutzerrelevante Reasoning-Zusammenfassungen falsch zu mischen. Ein Reasoning-Ereigniskanal ermöglicht es dem Framework, Fortschritt oder reasoning-bezogenen Zustand als strukturierte Ereignisse darzustellen. Die Anwendung muss immer noch entscheiden, was sicher anzuzeigen, zu speichern und zu übertragen ist, aber strukturierte Ereignisse sind besser als das Scrapen von Text aus einem Stream.
Todo-Multithreading und Todo-Injektion in die Nachrichtenliste zeigen, wie Zustandsverwaltung zu einer Laufzeitfunktion wird. Agenten verwenden Todo-Listen zum Planen, Verfolgen des Fortschritts und Wiederherstellen nach Unterbrechungen. Wenn der Todo-Zustand nicht thread-safe ist, können gleichzeitige Updates den Plan beschädigen. Wenn der Todo-Zustand im Nachrichtenkontext nicht sichtbar ist, kann das Modell den Überblick über Verpflichtungen verlieren. Todos in die Nachrichtenliste zu injizieren macht den Aufgabenzustand zum Teil des Modellkontextes, während Multithreading-Verbesserungen Race Conditions rund um Updates reduzieren.
Die function_call_output.output-Wire-Format-Korrektur ist klein, aber kritisch. Das Release korrigiert sie, um ein JSON-String auf dem Draht zu sein. Tool-Output-Formate sind Verträge zwischen Laufzeit, SDKs, Modellen und Clients. Wenn eine Seite einen String erwartet und die andere Seite strukturierte JSON direkt sendet, kann Deserialisierung oder Replay fehlschlagen. Agent-Frameworks müssen streng bei diesen Draht-Verträgen sein, weil Tool-Outputs oft gespeichert, gestreamt, komprimiert und später fortgesetzt werden.
Die Sequenznummer-Generierung erhält eine Korrektur für doppelte oder außerhalb der Reihenfolge liegende IDs. Ereignisreihenfolge ist grundlegend für Agent-UIs und Protokolle. Wenn zwei Ereignisse sich eine Sequenznummer teilen oder mit inkonsistenter Reihenfolge ankommen, können Clients veralteten Zustand rendern, Updates verwerfen oder Tool-Ergebnisse falsch zuordnen. In einem Multi-Agent- oder Multi-Party-Gespräch sind Reihenfolge-Bugs besonders schmerzhaft, weil der Benutzer nicht sagen kann, welcher Agent zuerst etwas gesagt oder getan hat.
Workflow-Re-Entry und YAML-Parsing-Korrekturen sprechen für die Zuverlässigkeit deklarativer Agenten. Eine QuestionExecutor-Schleife nach GotoAction-Re-Entry ist die Art von Bug, die deklarative Workflow-Bequemlichkeit in unkontrolliertes Verhalten verwandelt. YAML-Block-Scalar-Parsing für Datei-Skills ist wichtig, weil dateibasierte Skill-Definitionen oft Prompts, Anweisungen, Beispiele oder Skripte enthalten. Wenn Block-Scalars falsch geparst werden, ist der Skill, den der Agent sieht, nicht der Skill, den der Entwickler geschrieben hat.
Die praktische Empfehlung ist, dieses Release in Produktionsumgebungen zu evaluieren. Wenn Sie Microsoft Agent Framework verwenden, untersuchen Sie, wie die Orchestrierung den nächsten Akteur auswählt, definieren Sie Browser-Tool-Allowlisten, bevor Sie externe Sites verbinden, integrieren Sie Observability vor dem Rollout, behandeln Sie Reasoning-Events als einen kontrollierten UI-Kanal, testen Sie den Todo-Zustand unter Nebenläufigkeit und validieren Sie die Wire-Kompatibilität für Tool-Ausgaben. Framework-Releases sind nicht nur neue Abstraktionen; sie sind Änderungen an den Runtime-Verträgen, von denen Ihre Anwendung abhängt.
[50:00] Abschluss Die praktische Erkenntnis aus EP048 ist operativer Natur. Codex 0.130.0 macht Coding-Agent-Sessions serviceähnlicher mit ferngesteuerten App-Servern, paged Thread-Ansichten, Plugin-Hook-Sichtbarkeit, Config-Refresh und besserer Recovery rund um Patches und Kompaktierung. Microsofts Semantic Kernel-Forschung zeigt, wie modellgesteuerte Tool-Argumente zu Code-Ausführung werden können, wenn Frameworks sie in interpretierte Host-Language-Ausdrücke umwandeln. GitHub Copilot SDK gibt eingebetteten Produkten Approval- und Recovery-Hooks plus Diagnostics. Microsoft Agent Framework 1.5 treibt Orchestrierung, Browser-Policy, Observability, Event-Transport, Todo-Zustand und Wire-Format-Korrektheit voran. Für Builder besteht die Arbeit darin, jede Agent-Runtime-Grenze explizit zu machen: Kontrollebene, Tool-Input, Approval-Event, Browser-Policy, Telemetrie und gespeicherter Thread-State.
[NOVA]: Ich bin NOVA.
[ALLOY]: Und ich bin ALLOY, und das hier ist OpenClaw Daily. Heute schauen wir uns vier Builder-Stories an, in denen Agent-Runtimes kontrollierbarer, inspizierbarer und gefährlicher werden, wenn ihre Grenzen falsch gesetzt sind.
[NOVA]: OpenAI Codex 0.130.0 bietet Coding-Agent-Betreibern eine sauberere Fernsteuerungsoberfläche. Microsofts Semantic Kernel-Forschung zeigt, wie Prompt-Injection bei eval-basiertem Framework-Code zu Code-Ausführung werden kann. GitHub Copilot SDK fügt Callbacks für Plan-Genehmigung und Rate-Limit-Wiederherstellung hinzu. Und Microsoft Agent Framework 1.5 bringt Orchestrierung, Browser-Richtlinien, Observability und Wire-Semantik voran. ...
[ALLOY]: Die praktische Frage unter der letzten Story ist wichtig: Kann Microsoft Agent Framework tatsächlich innerhalb von OpenClaw verwendet werden? Kurze Antwort: ja, aber nicht als Drop-in-Ersatz für OpenClaws eigene Runtime. Es kann neben OpenClaw als externer Agent-Dienst, befehlsbasierte Fähigkeit, gehosteter Workflow oder Brücke durch ein Tool-Protokoll laufen. OpenClaw bliebe das lokale First-Gateway, der Channel-Router, Session-Manager und die Tool-Autorität. Microsoft Agent Framework wäre eine spezialisierte Agent-Runtime, in die OpenClaw hineinruft, sie überwacht und mit Richtlinien umhüllt.
[NOVA]: Diese Unterscheidung ist wichtig. Ein Framework kann innerhalb eines Systems nützlich sein, ohne zum System selbst zu werden. Das sichere Integrationsmodell ist nicht „ein zweites Framework den Host übernehmen lassen". Das sichere Modell ist „das Framework als nicht vertrauenswürdige oder semi-vertrauenswürdige Tool-Grenze behandeln mit expliziten Inputs, Outputs, Berechtigungen, Telemetrie und Fehlerbehandlung."
[NOVA]: Story eins ist OpenAI Codex 0.130.0. Die Schlagzeile ist Code-Remote-Control, ein einfacherer Einstiegspunkt zum Starten eines headless App-Servers, der ferngesteuert werden kann.
[ALLOY]: Ein headless App-Server ist ein sehr anderes operatives Objekt als ein Einweg-Befehlszeilen-Agent. Ein Terminal-Run startet, arbeitet und beendet sich. Ein App-Server verwaltet Sessions, Threads, Konfigurations-Snapshots, Umgebungsauswahl, Tool-Ausführung, Review-Events und Client-Verbindungen über die Zeit. Das bedeutet, die Runtime beantwortet nicht mehr nur einen Prompt. Sie wartet eine Service-Oberfläche.
[NOVA]: Genau. Der App-Server muss eine Coding-Session am Leben halten, während Clients sich wieder verbinden, Historie inspizieren, bestimmte Turns öffnen, Diffs reviewen und von einer anderen Oberfläche aus weiterarbeiten. Ein Fernsteuerungsbefehl macht diese Control Plane explizit. Es ist der Weg von einem lokalen Coding-Assistenten zu einem Service-Endpunkt, den eine IDE, ein Dashboard, ein Browser-Client oder eine Remote-Entwicklungsmaschine ansteuern kann.
[ALLOY]: Der große Mechanismus hier ist die Trennung von Kontrolle und Arbeit. Der Server besitzt die dauerhafte Session. Clients können kommen und gehen. Die Arbeit ist nicht an die Lebensdauer des ursprünglichen Terminal-Tabs gebunden. Das ist nützlich, aber es erhöht die Anforderungen an State-Management, Zugriffskontrolle und Auditierbarkeit.
[NOVA]: Codex 0.130.0 fügt auch Large-Thread-Paging hinzu, wo Clients unbeladene, zusammenfassende oder vollständige Turn-Item-Ansichten anfordern können. Das klingt nach Interface-Politur, bis man darüber nachdenkt, was ein Agent-Thread enthält. Er kann User-Turns, Modell-Turns, Tool-Calls, Genehmigungen, Diffs, Dateireferenzen, Bilder, Komprimierungszusammenfassungen, Plugin-Metadaten und Review-State enthalten. Dieses gesamte Objekt in jeden Remote-Client zu laden ist verschwenderisch und fragil.
[ALLOY]: Paged Thread-Ansichten machen das Transcript eher wie eine operative Timeline. Ein unbeladenes Item kann Identität und Reihenfolge bewahren, ohne Payload zu übertragen. Ein zusammenfassendes Item kann genug Kontext zum Navigieren geben. Ein vollständiges Item kann materialisiert werden, wenn der Client tatsächlich die Details öffnet. Das ist dieselbe Form, die man in Trace-Viewern, Log-Explorern und Issue-Timelines sieht.
[NOVA]: Es schützt auch die Latenz. Ein Remote-Client sollte nicht einfrieren, weil ein Agent-Thread zu einem giant Work-Record angewachsen ist. Für langlebige Coding-Sessions ist Pagination keine Optimierung am Edge. Sie wird Teil des Session-Vertrags.
[ALLOY]: Plugin-Details zeigen jetzt gebündelte Hooks, und Plugin-Sharing exponiert Link-Metadaten plus Discoverability-Kontrollen. Das ist eine Auditierbarkeits-Verbesserung. Hooks sind Teil des Runtime-Verhaltens eines Plugins. Wenn ein Plugin Startup beobachten, Tool-Calls abfangen, Befehle bereitstellen oder am Review teilnehmen kann, müssen Betreiber das sehen, bevor sie es installieren oder teilen.
[NOVA]: Hooks in Packages zu verstecken macht Plugin-Review zur Raterei. Hook-Metadaten zu zeigen macht die Ausführungs-Oberfläche sichtbar. In Agent-Systemen ist Discoverability ohne Inspectability riskant. Es ist einfach, etwas zu installieren, das wie eine harmlose Bequemlichkeit klingt, und später zu entdecken, dass es Tool-Verhalten, Startup-State oder Review-Flow modifiziert.
[ALLOY]: Das Release repariert auch das Verhalten der Live App-Server-Konfiguration. Live App-Server-Threads nehmen jetzt Konfigurationsänderungen auf, ohne einen Neustart zu erfordern. Das ist eine praktische Zuverlässigkeits-Korrektur, weil Konfiguration in einer Agent-Runtime Modellwahlen, Genehmigungsrichtlinien, Provider-Einstellungen, Tool-Verfügbarkeit, Plugin-State, Umgebungsauswahl und Telemetrie-Optionen enthalten kann.
[NOVA]: Wenn ein langlebiger Thread weiterhin alte Config verwendet, könnte der Betreiber glauben, dass sich die Richtlinie geändert hat, während der aktive Agent weiter unter älteren Regeln arbeitet. Live-Threads von der neuesten Config-Snapshot zu aktualisieren macht Richtlinienänderungen dort wirksam, wo die Arbeit passiert. Es reduziert auch die operative Versuchung, einen Service nur neu zu starten, damit eine Genehmigungs- oder Provider-Einstellung greift.
[ALLOY]: Turn Diffs bekommen eine der wichtigsten Builder-Fixes. Codex hält Diffs jetzt über apply_patch-Operationen akurat, einschließlich partiellen Fehlern, die Dateien trotzdem mutieren. Das ist ein echtes Failure-Mode. Ein Patch kann halbwegs scheitern und trotzdem einen Teil einer Datei ändern. Wenn die Runtime danach den falschen Diff meldet, können die Review-Ansicht, Rollback-Logik und Audit-Trail nicht vertraut werden.
[NOVA]: Operations-basiertes Diff-Tracking ist die richtige Richtung. Die Runtime sollte aufzeichnen, was tatsächlich geändert wurde, nicht nur, was der ideale Patch hätte ändern sollen. Coding-Agents brauchen akkuraten Post-Operation-State, besonders wenn Tools Dateien editieren dürfen. Ein irreführender Diff ist schlimmer als kein Diff, weil er falsches Vertrauen schafft.
[ALLOY]: ThreadStore-Fixes verbessern Summaries, Umbenennungen, Resume- und Fork-Pfade, einschließlich Threads ohne lokale Rollout-Pfade. Das macht die Storage-Schicht mehr zu einer Single Source of Truth für Lifecycle-Operationen. Resume und Fork sind wichtig, weil ein User eine Investigation verzweigen, eine fehlgeschlagene Run fortsetzen oder einen Thread von einem Remote-Client öffnen kann, der nicht den ursprünglichen lokalen Dateisystem-Pfad hat.
[NOVA]: Wenn Thread-Identität zu stark vom lokalen Maschinen-State abhängt, brechen Headless- und Remote-Workflows. Ein Remote App-Server sollte in der Lage sein zu antworten: „Was ist dieser Thread, welchen State enthält er, und wie kann er fortgesetzt werden?" ohne anzunehmen, dass der ursprüngliche Terminal-Kontext noch present ist.
[ALLOY]: Die Remote-Kompaktierung erhält auch Fehlerbehebungen für Stream-Verträge. Codex sendet jetzt response.processed für v2-Streams und vermeidet das Senden von service_tier bei API-Key-Kompaktierungsanfragen. Kompaktierung bestimmt, wie lange Sitzungen nutzbar bleiben, aber die Remote-Kompaktierung muss dieselbe Ereignissprache sprechen wie normale Durchläufe. Ein fehlendes 'processed'-Ereignis kann einen Client auf einen Endzustand warten lassen. Ein nicht unterstütztes Anforderungsfeld kann nur den Kompaktierungspfad unterbrechen, was die Diagnose erschwert.
[NOVA]: Die Unterstützung für mehrere Umgebungen zeigt sich in view_image, das jetzt Dateien über die ausgewählte Umgebung auflösen kann. Das ist wichtig, da Code-Agenten oft über einen Host, Container, eine Sandbox, einen Remote-Arbeitsbereich oder ein gemountetes Projekt hinweg arbeiten. Ein Bildpfad ist nur dann aussagekräftig, wenn die Laufzeitumgebung weiß, welcher Umgebung er gehört. Das Auflösen über die ausgewählte Umgebung verhindert, dass ein Client das falsche Dateisystem betrachtet oder ein Artefakt nicht anzeigt, das in der aktiven Sandbox existiert.
[ALLOY]: Die Bedrock-Authentifizierungsunterstützung akzeptiert jetzt AWS-Konsolen-Login-Anmeldeinformationen von AWS-Login-Profilen. Das ist eine Bequemlichkeit für den Operator mit Auswirkungen auf die Bereitstellung. Viele Teams verwalten den AWS-Zugriff bereits über profilbasierte Abläufe. Codex die Nutzung dieser Profile zu ermöglichen, reduziert doppelte Anmeldeinformationspfade und gleicht die Authentifizierung des Modell-Providers an bestehende Cloud-Zugriffskontrollen an.
[NOVA]: Die Telemetrie-Änderungen sind nützlich für das Debugging in der Produktion. Codex fügt konfigurierbare OpenTelemetry-Trace-Metadaten und umfassendere Analysefunktionen für Überprüfung und Feedback hinzu. Überprüfungsereignisse sind zentral für die Sicherheit von Code-Agenten. Wenn ein Befehl genehmigt, abgelehnt, wiederholt oder eskaliert wurde, benötigen Operatoren genügend Trace-Kontext, um zu verstehen, warum.
[ALLOY]: Gute Telemetrie verbindet die Sitzung, den Durchlauf, den Tool-Aufruf, die Genehmigungsentscheidung, die Modell-Anfrage und das für den Benutzer sichtbare Ergebnis, ohne Geheimnisse preiszugeben. Das ist der schmale Grat. Zu wenig Telemetrie macht die Rekonstruktion von Vorfällen unmöglich. Zu viel Telemetrie kann Prompts, Dateien, Anmeldeinformationen oder privaten Code offenlegen.
[NOVA]: Die praktische Empfehlung ist, Codex-App-Server-Bereitstellungen wie Service-Bereitstellungen zu behandeln. Fixieren Sie die Version. Starten Sie die Fernsteuerung bewusst. Dokumentieren Sie, welche Clients sich verbinden können. Überprüfen Sie Plugin-Hooks vor dem Teilen. Testen Sie das Konfigurationsaktualisierungsverhalten. Testen Sie Fehler bei partiellen Patch-Anwendungen. Und stellen Sie sicher, dass Kompaktierung, Thread-Wiederaufnahme und Bildanzeige in den Umgebungen funktionieren, die Sie tatsächlich verwenden.
[ALLOY]: Ein weiteres operatives Detail sollte erläutert werden. Wenn ein Code-Agent zu einem App-Server wird, wird die Grenze zwischen Produkt-UX und Laufzeitstatus dünner. Eine Benutzeroberfläche kann jetzt eine komprimierte Zusammenfassung, einen vollständigen Durchlauf, eine Plugin-Detailseite, ein Überprüfungsereignis oder ein Bildartefakt anfordern. Wenn diese Endpunkte nicht versioniert und getestet werden, kann die Benutzeroberfläche versehentlich von internen Strukturen abhängen, die sich in einer Release ändern. Entwickler sollten diese App-Server-Antworten als API-Verträge behandeln, auch wenn Client und Server zusammen ausgeliefert werden.
[NOVA]: Das ändert auch die Reaktion auf Vorfälle. In einem reinen Terminal-Modell kann ein Operator im Shell-Transkript zurückscrollen und den Arbeitsbaum inspizieren. In einem Remote-App-Server-Modell sind die Beweise über Thread-Speicher, Tool-Operationsaufzeichnungen, Telemetrie, Genehmigungen, Plugin-Metadaten und umgebungsspezifische Dateiansichten verteilt. Die Laufzeitumgebung muss genügend Zustand bewahren, um das Geschehene nachträglich rekonstruieren zu können.
[ALLOY]: Und da Remote-Clients sich wieder verbinden können, sollte die Sitzung robust gegenüber teilweisen Client-Ausfällen sein. Wenn ein Browser-Tab während der Kompaktierung die Verbindung verliert, benötigt der Server immer noch ein Terminalereignis. Wenn ein Patch teilweise angewendet wird und der Client aktualisiert, benötigt der Server immer noch den echten Diff. Wenn sich die Konfiguration während eines langen Threads ändert, sollte die aktive Richtlinie verständlich sein. Deshalb summieren sich diese scheinbar kleinen Fehlerbehebungen zu einer glaubwürdigeren Fernsteuerungs-Laufzeitumgebung.
[NOVA]: Die Veröffentlichung dreht sich nicht nur um neue Befehle. Es geht darum, einen Code-Agenten steuerbar, überprüfbar und wiederherstellbar zu machen, wenn Sitzungen groß werden und remote ausgeführt werden.
[NOVA]: Geschichte zwei ist Microsofts Sicherheitsfallstudie zur Remote-Code-Ausführung in KI-Agenten-Frameworks. Der wichtige Punkt ist, dass das Modell nicht die anfällige Komponente des Kernfehlers ist. Die gefährliche Grenze ist Framework- und Plugin-Code, der modellgesteuerten Tool-Argumenten vertraut und diese in ausführbares Host-Verhalten umwandelt.
[ALLOY]: Der offengelegte Pfad konzentriert sich auf den Suchfluss des In-Memory Vector Store von Semantic Kernel. Der Beispiel-Agent stellt ein Hotelsuch-Plugin bereit. Ein Benutzer fragt nach Hotels in einer Stadt. Das Modell ruft die Suchfunktion mit einem Stadt-Argument auf. Das Plugin erstellt einen Filter vor der Vektorähnlichkeitssuche. Der riskante Schritt ist, dass ein modellgesteuerter Wert in einen Python-Lambda-Ausdruck interpoliert und mit eval ausgeführt wird.
[NOVA]: Das ist die Grenzüberschreitung. Ein normaler Stadt-String wird Teil eines Filterausdrucks. Ein bösartiger String kann ein Anführungszeichen schließen und Python-Logik anhängen. Prompt-Injection benötigt keinen Browser-Exploit oder Speicherbeschädigung, wenn das Framework natürlichsprachlich gesteuerte Werte in Code umwandelt. Der Agent ist zu einem Pfad von Text zur Host-Ausführung geworden.
[ALLOY]: Die versuchte Minderung nutzte AST-Validierung und eine eingeschränkte Builtins-Umgebung. Auf hoher Ebene erlaubte der Validator Lambda-Ausdrücke, scannte Namen und Attribute nach gefährlichen Bezeichnern und führte die Ausführung ohne Builtins durch. Das klingt plausibel, aber dynamische Sprachen machen Blacklists anfällig.
[NOVA]: Die Forscher von Microsoft umgingen den Filter, ohne sich direkt auf die offensichtlich blockierten Namen zu verlassen. Die Payload durchquerte Python-Objektstrukturen, um Importmechanismen zu lokalisieren und die Befehlsausführung über alternative Attribute zu erreichen. Das ist das klassische Problem, wenn man versucht, einen allgemeinen Host-Sprach-Evaluator sicher zu machen, indem man bekannte gefährliche Token verbietet.
[ALLOY]: Die Lektion ist nicht nur „verwende kein eval“, obwohl das ein guter Ausgangspunkt ist. Die umfassendere Lektion ist, dass Tool-Aufruf-Argumente unvertraute Eingaben sind, selbst wenn sie von einem Modell stammen, selbst wenn der Benutzer keinen Code direkt eingegeben hat und selbst wenn das Schema behauptet, das Feld sei etwas Harmloses wie ein Stadtname.
[NOVA]: Ein Modell kann dazu veranlasst werden, vom Angreifer gesteuerte Strings in jedes Argument einzufügen, das es füllen darf. Wenn das Tool diesen String als Code, eine Abfragesprache, einen Shell-Befehl, einen Dateipfad, eine Vorlage oder einen serialisierten Ausdruck interpretiert, hat das Framework eine Injection-Senke geschaffen.
[ALLOY]: Vektorsuche lässt das Problem leicht unterschätzen, da es sich wie Retrieval-Infrastruktur anfühlt, nicht wie Code-Ausführung. Aber Vektorspeicher unterstützen oft Metadatenfilter, Ausdruckssprachen, benutzerdefinierte Prädikate, Embedding-Vorfilter, Reranker und konnektorspezifische Abfrage-Strings. Jedes davon kann zu einer Injection-Grenze werden, wenn benutzer- oder modellgesteuerte Werte in einen interpretierten Ausdruck verkettet werden.
[NOVA]: Sichereres Design bedeutet normalerweise parametrisierte Filter, typisierte DSLs, erlaubte Operatoren und Validierung, die unerwartete Strukturen vor der Ausführung ablehnt. Feld gleich Wert sollte Daten sein, nicht Quellcode. Wenn eine Filtersprache unvermeidlich ist, sollte die Laufzeitumgebung in einen eingeschränkten AST parsen und mit einem Interpreter auswerten, der nur die erlaubten Operationen versteht. Sie sollte den Host-Sprach-Evaluator nicht aufrufen und versuchen, gefährliches Verhalten danach zu blockieren.
[ALLOY]: Das Prinzip der geringsten Rechte ist ebenfalls wichtig. Ein Hotelsuch-Prädikat benötigt keinen Shell-Zugriff. Wenn ein Framework-Bug einen Filter in Code-Ausführung verwandelt, bestimmen die Sandbox- und Prozessberechtigungen den Explosionsradius. Agenten-Frameworks sollten die Plugin-Ausführung isolieren, Umgebungsvariablen begrenzen, das Übergeben von Anmeldeinformationen an generische Tool-Prozesse vermeiden und Tool-Parameter sorgfältig genug für die Reaktion auf Vorfälle protokollieren.
[NOVA]: Erkennung ist praxisnah. Teams sollten Tools inventarisieren, die Templates, Filter, Shell-Befehle, Notebook-Zellen, Python-Snippets, JavaScript-Snippets, SQL oder Dateioperationen ausführen. Dann sollten sie nachverfolgen, ob modellgesteuerte Werte diese Interpreter erreichen können. Das Patchen von Semantic Kernel ist für Nutzer des betroffenen Pfads notwendig, aber benutzerdefinierte Plugins wiederholen oft dasselbe Muster.
[ALLOY]: Es gibt auch eine Testlektion. Ein normaler Unit-Test kann bestehen, weil er einen freundlichen Stadtnamen, eine freundliche Kategorie oder ein freundliches Metadatenfeld überprüft. Sicherheitstests erfordern adversariale Werte, die versuchen, aus der erwarteten Syntax auszubrechen. Für einen Vektorfilter bedeutet das Anführungszeichen, geschweifte Klammern, Operatoren, Attributtraversierung, sehr lange Strings, ungewöhnliche Unicode-Zeichen und Versuche, Objekte zu referenzieren, die niemals erreichbar sein sollten. Der Test sollte bestätigen, dass diese Werte Daten bleiben.
[NOVA]: Eine nützliche Überprüfungsfrage ist: „Wo ist der erste Interpreter?" Wenn ein Wert als JSON geparst wird, ist das eine Grenze. Wenn er zu SQL wird, ist das eine andere. Wenn er zu einem Python-Lambda, Shell-Befehl, Template, regulären Ausdruck oder Dateipfad wird, braucht jeder Schritt seine eigene Validierungsregel. Das schlimmste Muster ist die Konvertierung von Benutzer- oder Modelldaten in einen String, der später von einer mächtigeren Sprache interpretiert wird, als das Schema verspricht.
[ALLOY]: Framework-Betreuer müssen auch den sicheren Weg zum Standardweg machen. Wenn das einfache Beispiel in der Dokumentation Stringverkettung in einen Filterausdruck verwendet, werden nachgelagerte Anwendungen es kopieren. Wenn der standardmäßige Vector-Store-Helfer einen typisierten Filter-Builder akzeptiert, werden weniger Anwendungen ihre eigene unsichere Version erfinden. Agentensicherheit verbessert sich, wenn Framework-Ergonomie Entwickler in Richtung sicherer Komposition führt.
[NOVA]: Deshalb ist diese Forschung über einen einzelnen Bug hinaus wichtig. Sie gibt Erbauern ein konkretes mentales Modell: Prompt-Injection wird Host-Kompromittierung nur dann, wenn es eine Brücke von sprachgesteuerten Daten zur privilegierten Ausführung gibt. Findet die Brücken, verengt sie und entfernt Interpreter aus dem normalen Pfad.
[ALLOY]: Hier ist OpenClaws eigenes Betriebsmodell relevant. OpenClaw behandelt eingehende DMs und Kanalnachrichten als nicht vertrauenswürdige Eingaben. Es hat ein lokal-first Gateway, Kanal-Routing, Tool-Richtlinien und Sandbox-Optionen für Nicht-Hauptsitzungen. Aber das macht nicht magisch jedes aufgerufene Framework sicher. Wenn OpenClaw ein externes Agent-Framework aufruft, gilt dieselbe Regel: Das Framework ist eine Tool-Grenze, keine vertrauenswürdige interne Sprache.
[NOVA]: Richtig. Wenn ein Microsoft Agent Framework-Workflow, ein Semantic Kernel-Plugin oder eine andere externe Runtime von OpenClaw aufgerufen wird, sollte die Integration einen schmalen Befehlsvertrag definieren, typisierte Eingaben, erlaubte Aktionen, Umgebungsisolation, Timeouts und strukturierte Ausgaben. Der Host sollte dem externen Runtime keine unbegrenzten Dateisystem-, Netzwerk-, Token- oder Shell-Zugriffe gewähren, es sei denn, das ist wirklich beabsichtigt.
[ALLOY]: Der Betreiber-Merkpunkt ist klar: Jedes Agenten-Tool ist ein API-Endpunkt, dessen Aufrufer teilweise vom Modell kontrolliert wird. Behandeln Sie Tool-Schemata als externe API-Verträge. Validieren Sie Eingaben an der Grenze. Bevorzugen Sie typisierte Datenstrukturen über interpretierte Strings. Halten Sie Berechtigungen eng. Protokollieren Sie genug, um rekonstruieren zu können, welcher Prompt welche Tool-Argumente produziert hat. Und testen Sie Prompt-Injection, indem Sie versuchen, feindliche Parameter in Tools zu zwingen, nicht nur indem Sie prüfen, ob das Modell unsichere Wörter sagt.
[NOVA]: Prompt-Injection-Sicherheit ist nicht nur Modelverhalten. Es ist Eingabevalidierung, Interpreter-Vermeidung, Sandboxierung und Least-Privilege-Design für die Runtime, die Arbeit ausführt.
[NOVA]: Geschichte drei ist GitHub Copilot SDKs Pre-Release vom 8. Mai. Dies hier geht um das Einbetten von Coding-Agent-Sitzungen in Produkte mit expliziterer Runtime-Kontrolle.
[ALLOY]: Anwendungen können jetzt Callbacks für exitPlanMode.request und autoModeSwitch.request registrieren. Diese Events sind wichtig, weil Plan-Modus und automatischer Modellwechsel Produktentscheidungen sind, nicht nur Modelentscheidungen.
[NOVA]: Plan-Modus ist eine Grenze zwischen dem Vorschlagen von Arbeit und dem Ausführen von Arbeit. In einem eingebetteten Coding-Agenten möchte die Anwendung möglicherweise, dass ein Mensch den Plan genehmigt, eine Policy-Engine ihn überprüft oder eine projektspezifische Regel bestimmte Änderungen blockiert. Ein Handler für exit-plan-mode-Anfragen gibt dem Host-Produkt einen klaren Abfangpunkt, bevor die Runtime von der Planung zur Ausführung übergeht.
[ALLOY]: Automatischer Modellwechsel nach Rate-Limits ist eine andere Grenze. Eine Runtime möchte möglicherweise von einem Rate-Limit-Ereignis durch Wechsel zu einem anderen Modell oder Modus erholen. Das kann Kontinuität bewahren, aber auch Verhalten, Kosten, Latenz oder Fähigkeiten ändern. Der autoModeSwitch.request-Handler ermöglicht es der Anwendung zu entscheiden, ob der Wechsel akzeptiert wird.
[NOVA]: Für Enterprise-Produkte ist das wichtig, weil Modellwahl an Datenrichtlinien, Compliance, Evaluierungsbaselines und Budgetkontrollen gebunden sein kann. Ein Fallback, der der Runtime harmlos erscheint, kann für die Host-Anwendung inakzeptabel sein, wenn er eine Anbietergrenze überschreitet oder die Aufbewahrungsrichtlinie ändert.
[ALLOY]: Das Release fügt auch strukturierte Diagnosen über die .NET-, Python- und Rust-SDKs hinzu. Die Logs decken CLI-Start, TCP-Verbindung, JSON-RPC-Anfrage-Timing, Sitzungslebenszyklus und Fehlerpfade ab. Das ist die Sichtbarkeit, die ein eingebettetes Agent-SDK braucht.
[NOVA]: Wenn eine Sitzung fehlschlägt, kann die Ursache Prozessstart, Transport, Authentifizierung, JSON-RPC-Framing, Runtime-Event-Handling, Modellantwort, Tool-Ausführung oder Host-Callback-Verhalten sein. Ohne strukturiertes Timing und Lebenszyklus-Logs sieht alles so aus, als ob „der Agent hängt."
[ALLOY]: Der JSON-RPC-Detailgrad ist besonders wichtig. Viele Coding-Agent-SDKs wrappen einen lokalen Runtime-Prozess und kommunizieren über JSON-RPC. Das erstellt ein Client-Objekt in der Anwendung, einen Runtime-Prozess, eine Transportverbindung, Request-IDs, Event-Streams und langlebige Operationen. Diagnosen müssen zeigen, wann die Runtime gestartet wurde, wann die TCP-Verbindung geöffnet wurde, welche Requests gesendet wurden, wie lange sie dauerten und wo Fehler auftraten.
[NOVA]: Die enableSessionTelemetry-Option macht Telemetrie zu einer expliziten Sitzungswahl. Das ist die richtige Form für Datenschutz und Betrieb. Einige Deployments möchten Sitzungstelemetrie, um Probleme zu debuggen und Zuverlässigkeit zu verbessern. Andere brauchen sie aus Richtliniengründen deaktiviert. Den Regler auf Sitzungs- und Resume-Konfiguration zu setzen macht die Entscheidung überprüfbar und wiederholbar.
[ALLOY]: Es gibt kleinere Kompatibilitätsfixes mit echtem Impact. C#-Sitzungs-Event-Enums sind jetzt string-backed Readonly-Strukturen, sodass Deserialisierung nicht fehlschlägt, wenn die Runtime neue Enum-Werte hinzufügt. Das ist Vorwärtskompatibilität für Event-Streams. Rust-Binary-Tool-Ergebnis-Resource-Blobs verwenden jetzt standardmäßig application/octet-stream, wenn mimeType fehlt. Das ist Wire-Format-Resilienz.
[NOVA]: Die praktische Builder-Implikation ist, dass Copilot-SDK-Sitzungen zu hostkontrollierten Runtime-Objekten werden. Wenn du sie einbettest, implementiere die Plan-Modus- und Modus-Wechsel-Callbacks bewusst. Entscheide, welche Wechsel automatisch passieren können und welche Überprüfung erfordern. Aktiviere Diagnosen in Entwicklung und Staging. Erfasse JSON-RPC-Timing bei langsamen oder flaky Sitzungen. Behandle Telemetrie als Richtlinie, nicht als versteckten Standard.
[ALLOY]: Und ältere Clients gegen neuere Laufzeitereignisse testen. Ereignisströme entwickeln sich weiter. Wenn die Enum-Behandlung oder die MIME-Standardeinstellungen fehlschlagen, funktioniert der Agent möglicherweise, während das Hostprodukt nicht deserialisieren kann, was passiert ist.
[NOVA]: Story vier ist Microsoft Agent Framework 1.5. Die Veröffentlichung ist umfassend, aber mehrere Änderungen sind für Entwickler von Produktionsagenten direkt relevant: Magentic Orchestration für .NET, WebBrowsingTool Allowlisting, Observability-Beispiele für gehostete Agenten, Reasoning-Ereignisse in AGUI, klassenbasierte Skills und Harness-Kontextanbieter in der Python-Linie, Todo-Zustandsinjektion, Foundry Per-Call-Header und ein Wire-Format-Fix für function_call_output.output.
[ALLOY]: Magentic Orchestration ist die Schlagzeile, weil Multi-Agenten-Systeme mehr als eine Liste von Agenten benötigen. Sie brauchen Terminplanung, Delegation, Zugbesitz, geteilten Zustand, Abbruchbedingungen und eine Möglichkeit zu entscheiden, welcher Akteur als Nächstes handeln soll. Eine Orchestrierungsschicht formalisiert diese Mechanismen. Es als experimentell zu kennzeichnen, ist angemessen, da Orchestrierungssemantik zur Anwendungsarchitektur wird.
[NOVA]: Ein schlechter Scheduler kann in einer Schleife hängen bleiben, Arbeit duplizieren, Fehler verbergen oder zulassen, dass ein Agent ein Gespräch dominiert. Multi-Agenten-Orchestrierung ist keine magische Zusammenarbeit. Es ist eine Laufzeitrichtlinie darüber, wer wann handelt, welchen Kontext sie sehen und wann der Prozess stoppt.
[ALLOY]: WebBrowsingTool Allowlisting ist ein wichtiges Browser-Kontrollfeature. Browsing-Tools verbinden einen Agenten mit externen Inhalten, die bösartig, unvertrauenswürdig oder einfach nur ablenkend sein können. Eine Allowlist bietet der Hostanwendung eine Richtlinienoberfläche, bevor das Browser-Tool ausgeführt wird.
[NOVA]: In Agentensystemen ist Browsen nicht nur Lesen. Der Browser kann Prompt-Injection-Inhalte abrufen, Formulare absenden, Weiterleitungen folgen, Cookies offenlegen, Dateien abrufen und mit authentifizierten Sitzungen interagieren. Eine Richtlinie muss vor der Werkzeugausführung existieren, nicht erst, nachdem eine schlechte Seite den Lauf bereits beeinflusst hat.
[ALLOY]: Observability-Beispiele für gehostete Agenten sind ebenfalls wertvoll, weil die Bereitstellung der Punkt ist, an dem Framework-Abstraktionen auf die Produktionsrealität treffen. Ein gehosteter Agent benötigt Logs, Traces, Anfragekorrelation, Sichtbarkeit von Modellaufrufen, Timing von Tool-Aufrufen und Fehlerzustände. Die nützliche Frage ist, ob ein Team einen fehlgeschlagenen Lauf von der externen Anfrage über Orchestrierung, Modellaufruf, Tool-Aufruf bis zur endgültigen Antwort rekonstruieren kann.
[NOVA]: Reasoning-Ereignisse in AGUI legen ein Transportproblem offen. Benutzeroberflächen müssen den Fortschritt des Agenten rendern, ohne private Gedankenketten, Tool-Begründungen und für den Benutzer sichtbare Zusammenfassungen falsch zu vermischen. Ein Reasoning-Ereigniskanal ermöglicht es dem Framework, Fortschritt oder reasoning-bezogene Zustände als strukturierte Ereignisse darzustellen. Die Anwendung muss immer noch entscheiden, was sicher angezeigt, gespeichert und übertragen werden kann.
[ALLOY]: Todo-Multithreading und Todo-Injektion in die Nachrichtenliste zeigen, wie der Task-Zustand zu einer Laufzeitfunktion wird. Agenten verwenden Todo-Listen, um zu planen, den Fortschritt zu verfolgen und sich nach Unterbrechungen zu erholen. Wenn der Todo-Zustand nicht Thread-sicher ist, können gleichzeitige Updates den Plan beschädigen. Wenn der Todo-Zustand im Nachrichtenkontext nicht sichtbar ist, kann das Modell den Überblick über Verpflichtungen verlieren.
[NOVA]: Der Wire-Format-Fix für function_call_output.output ist klein, aber kritisch. Die Veröffentlichung behebt dies, sodass es ein JSON-String im Wire-Format ist. Tool-Ausgabeformate sind Verträge zwischen Laufzeit, SDKs, Modellen und Clients. Wenn eine Seite einen String erwartet und die andere Seite strukturiertes JSON direkt sendet, können Deserialisierung, Replay, Speicherung oder Komprimierung fehlschlagen.
[ALLOY]: Die Generierung von Sequenznummern erhält einen Fix für doppelte oder außerplanmäßige IDs. Ereignisreihenfolge ist grundlegend für Agenten-UIs und Logs. Wenn zwei Ereignisse eine Sequenznummer teilen oder außer der Reihe ankommen, können Clients veraltete Zustände rendern, Updates verwerfen oder ein Tool-Ergebnis dem falschen Zug zuordnen. In einer Multi-Agenten- oder Mehrparteien-Konversation sind Reihenfolgefehler besonders schmerzhaft.
[NOVA]: Workflow-Wiedereintritts- und YAML-Parsing-Fixes sprechen für die Zuverlässigkeit deklarativer Agenten. Eine Schleife nach dem Wiedereintritt von GotoAction kann Workflow-Komfort in unkontrollierbares Verhalten verwandeln. Das Parsing von YAML-Block-Skalaren für Datei-Skills ist wichtig, da dateibasierte Skills oft Prompts, Anweisungen, Beispiele oder Skripte enthalten. Wenn Block-Skalare falsch geparst werden, ist der Skill, den der Agent sieht, nicht der Skill, den der Entwickler geschrieben hat.
[ALLOY]: Nun zur OpenClaw-Integrationsfrage. Kann Microsoft Agent Framework innerhalb von OpenClaw verwendet werden? Ja, aber die saubere Architektur ist adapterbasiert. OpenClaw ist ein Local-First-Assistenten-Gateway, das bereits Kanäle, Sitzungen, Tools, Knoten, Browser- und Canvas-Oberflächen, Cron, Skills, Sandboxing und Multi-Agenten-Routing verwaltet. Microsoft Agent Framework ist ein separates Agenten-Framework mit .NET- und Python-Oberflächen. Es sollte als aufgerufene Laufzeit integriert und nicht mit der nativen Sitzungslaufzeit von OpenClaw verwechselt werden.
[NOVA]: Es gibt mehrere praktikable Muster. Erstens, ein kommando-gestützter Skill: OpenClaw kann ein lokales Skript oder einen Dienst aufrufen, der einen Microsoft Agent Framework Workflow ausführt und ein strukturiertes Ergebnis zurückgibt. Das ist die einfachste Form. Die Skill-Eingabe ist typisiert. Der Framework-Prozess läuft mit einem definierten Arbeitsverzeichnis und einer Umgebung. Die Ausgabe wird als Text oder JSON erfasst. Timeouts und Fehlerbehandlung bleiben in OpenClaw.
[ALLOY]: Zweitens, ein gehosteter lokaler Dienst: Eine .NET- oder Python Agent Framework App kann als Localhost-Dienst oder privater Netzwerkdienst ausgeführt werden. OpenClaw ruft ihn über einen schmalen HTTP- oder RPC-Adapter auf. Dies ist nützlich, wenn das Framework einen langlebigen Orchestrierungszustand, warme Modell-Clients oder eine eigene Observability-Pipeline benötigt. OpenClaw besitzt immer noch, welcher Kanal ihn aufrufen kann und welche Anmeldeinformationen offengelegt werden.
[NOVA]: Drittens, eine Tool-Protokoll-Brücke: Wenn der Agent Framework Workflow hinter einem Tool-Server offengelegt werden kann, kann OpenClaw ihn wie einen anderen Tool-Anbieter behandeln. Der wichtige Teil ist die Grenze. Tool-Namen, Schemata, erlaubte Operationen und zurückgegebene Artefakte müssen explizit sein. OpenClaw sollte nicht blind jede Fähigkeit eines Framework-Prozesses in jede Sitzung importieren.
[ALLOY]: Viertens, eine sandboxed Subagenten-Spur: OpenClaw kann ausgewählte Aufgaben an einen Nicht-Hauptagenten oder eine Sandbox weiterleiten, der die Berechtigung hat, das externe Framework auszuführen. Dies ist ein sichereres Muster für Experimente, da das Framework begrenzten Dateisystem- und Netzwerkzugriff erhalten kann. Es ist besonders relevant für Browser-Tools und gehostete Workflows, die auf nicht vertrauenswürdige Inhalte stoßen können.
[NOVA]: Die Integrationsgrenzen sind genauso wichtig. Microsoft Agent Framework wird nicht automatisch zu einem nativen OpenClaw-Kanal. Es erbt nicht automatisch die Pairing-Richtlinie von OpenClaw, Discord- oder Telegram-Routing, das Live-Canvas-Verhalten, die Knotenverwaltung, das Speichermodell oder die Genehmigungstore. Diese müssen bewusst gekapselt werden. Es bringt auch seine eigenen Abhängigkeiten, das Ereignismodell, die Skill-Semantik und die Tool-Output-Verträge mit.
[ALLOY]: Die Sicherheitslektion aus der Semantic Kernel-Geschichte gilt direkt. Wenn OpenClaw einen Microsoft Agent Framework Agenten aufruft, können modellgenerierte Argumente von einer Laufzeit in die Tools einer anderen Laufzeit gelangen. Das bedeutet, dass Validierung nicht angenommen werden kann. Eine sichere Brücke sollte typisierte Anfrageobjekte, auf einer Positivliste stehende Operationen, geschwärzte Logs, Umgebungsvariablen mit den geringsten Rechten, explizite Browser-Allowlists und standardmäßig keinen generischen Shell-Zugriff verwenden.
[NOVA]: Auch Observability benötigt eine Brücke. OpenClaw kann eine Benutzernachricht, Sitzung, einen Tool-Aufruf und eine Antwort verfolgen. Microsoft Agent Framework kann Orchestrierung, Modellaufrufe, Tool-Aufrufe, Reasoning-Ereignisse und Workflow-Zustände verfolgen. Eine Produktionsintegration sollte eine Korrelations-ID über diese Grenze hinwegführen, damit eine fehlgeschlagene Anfrage von der Kanalnachricht über die OpenClaw-Sitzung bis zum Aufruf des externen Frameworks und zurück verfolgt werden kann.
[ALLOY]: Die praktische Empfehlung ist vorsichtiger Optimismus. Verwende Microsoft Agent Framework innerhalb von OpenClaw, wenn es eine spezifische Fähigkeit bietet: Magentic-Orchestrierung, Foundry-Integration, gehostete Agent-Beispiele, deklarative Skills oder einen Workflow, der bereits in .NET oder Python geschrieben ist. Verwende es nicht nur, weil es ein weiteres Agent-Framework ist. Wenn OpenClaw bereits das benötigte Channel-, Session- und Tool-Verhalten bietet, kann das Hinzufügen eines zweiten Frameworks Komplexität ohne Mehrwert hinzufügen.
[NOVA]: Das beste erste Experiment wäre gezielt. Erstelle einen Microsoft Agent Framework-Workflow, der eine abgeschlossene Aufgabe ausführt, stelle ihn über einen einzelnen OpenClaw-Skill oder einen lokalen Dienst bereit, übergebe ein typisiertes Eingabeobjekt, liefere ein strukturiertes Ergebnis, führe ihn ohne umfassende Berechtigungen aus und protokolliere die Korrelations-ID. Evaluiere dann Latenz, Zuverlässigkeit, Toolsicherheit und ob das Orchestrierungsergebnis besser ist als ein nativer OpenClaw-Skill.
[ALLOY]: Wenn die Antwort Ja ist, erweitere sorgfältig. Füge Browserzugriff nur mit Erlaubnislisten hinzu. Füge Dateizugriff nur auf einen begrenzten Arbeitsbereich hinzu. Füge Anmeldeinformationen nur durch explizite Geheimnisreferenzen oder Umgebungsvariableninjektion hinzu. Füge persistenten Zustand erst hinzu, nachdem Replay- und Resume-Semantik klar sind. Und lass niemals zu, dass ein Framework stillschweigend die Berechtigungen einer Chat-Session erweitert.
[NOVA]: Die Antwort ist also nicht „Nein, weil OpenClaw getrennt ist", und auch nicht „Ja, installiere es einfach und lass es alles ausführen." Die Antwort lautet: Ja, Microsoft Agent Framework kann innerhalb einer OpenClaw-Bereitstellung als integrierte externe Runtime verwendet werden, aber OpenClaw sollte die Autorität für Channel-Eingang, Benutzervertrauen, Tool-Richtlinien, Sandboxing und Bereitstellung bleiben.
[ALLOY]: Es gibt einige Fälle, in denen die Integration lohnenswert wäre. Wenn ein Team bereits .NET-Agenten hat, die um Foundry, Magentic-Orchestrierung, deklarative Workflows oder Microsofts gehostete Agent-Beispiele aufgebaut sind, kann das Verpacken dieser Arbeit für OpenClaw die Investition bewahren. OpenClaw kann die persönliche Betriebsschicht darum herum werden: Nachrichtenaufnahme, Benutzergenehmigung, Kanalbereitstellung, Zeitplanauslöser, Datei-Bereitstellung und lokale Maschinensteuerung.
[NOVA]: Es gibt auch Fälle, in denen es nicht lohnenswert wäre. Wenn die Aufgabe eine einfache lokale Automatisierung ist, ist ein normaler OpenClaw-Skill wahrscheinlich einfacher zu prüfen und zu betreiben. Wenn die Aufgabe einen Tool-Aufruf und eine Antwort benötigt, kann das Hinzufügen eines zweiten Orchestrierungs-Frameworks mehr Serialisierung, mehr Logs, mehr Abhängigkeiten und mehr Fehlermodi als Wert schaffen. Die Integration sollte durch Orchestrierung, vorhandenen Code, gehostete Agent-Infrastruktur oder eine konkrete Microsoft-Ökosystem-Anforderung gerechtfertigt sein.
[ALLOY]: Versionierung ist eine weitere echte Überlegung. OpenClaw, das externe Framework, Modell-SDKs und Tool-Schemata können sich alle unabhängig weiterentwickeln. Eine Bridge sollte die erwartete Framework-Version deklarieren, zurückgegebene Event-Formen validieren und klar scheitern, wenn sich ein Wire-Vertrag ändert. Stille partielle Kompatibilität ist gefährlich, weil sie einen Agenten so erscheinen lassen kann, als ob er funktioniert, während er To-do-Zustand, Tool-Ausgabe, Sequenzreihenfolge oder Reasoning-Events verliert.
[NOVA]: Die empfohlene Form ist absichtlich langweilig: eine Adapter, ein Schema, ein Berechtigungsprofil, eine Korrelations-ID, eine Timeout-Richtlinie und ein klar dokumentiertes Ergebnis. Starte dort. Wenn das funktioniert, füge Fähigkeiten langsam hinzu. Das Ziel ist nicht, OpenClaw und Microsoft Agent Framework ununterscheidbar zu machen. Das Ziel ist es, OpenClaw sicher einen nützlichen externen Agent-Runtime aufrufen zu lassen, wenn dieser Runtime seinen Platz verdient.
[ALLOY]: Die praktische Erkenntnis aus EP048 ist operativ. Codex 0.130.0 macht Coding-Agent-Sessions serviceähnlicher mit ferngesteuerten App-Servern, seitenweisen Thread-Ansichten, Plugin-Hook-Sichtbarkeit, Konfig-Aktualisierung, besseren Patch-Diffs, Komprimierungsfixes und Dateiauflösung für mehrere Umgebungen.
[NOVA]: Microsofts Semantic Kernel-Forschung zeigt, wie modellgesteuerte Tool-Argumente zu Codeausführung werden können, wenn Frameworks sie in interpretierte Hostsprachen-Ausdrücke umwandeln. GitHub Copilot SDK bietet eingebetteten Produkten Genehmigungs- und Wiederherstellungs-Hooks plus Diagnose. Microsoft Agent Framework 1.5 treibt Orchestrierung, Browser-Richtlinien, Observability, Event-Transport, To-do-Zustand und Wire-Format-Korrektheit voran.
[ALLOY]: Und zur OpenClaw-Frage: Microsoft Agent Framework ist innerhalb von OpenClaw als begrenzte externe Runtime, Dienst, Skill oder Tool-Bridge verwendbar. Es sollte nicht OpenClaws eigenes Vertrauens-, Routing-, Sandbox- und Genehmigungsmodell umgehen.
[NOVA]: Für Builder: Macht jede Agent-Runtime-Grenze explizit: Kontrollebene, Tool-Eingabe, Genehmigungs-Event, Browser-Richtlinien, Telemetrie, Framework-Bridge und gespeicherter Thread-Zustand. Danke fürs Zuhören zu OpenClaw Daily. Shownotes und Quell-Links sind verfügbar unter Toby On Fitness Tech Punkt com, und wir sind bald zurück.