Kategorie: Erklärer

Einen neuen Mitarbeiter stattet man nicht nur mit Stift und Zettel aus. Er bekommt einen Schreibtisch, einen Rechner, Zugang zu den richtigen Ordnern und die Werkzeuge für seine Arbeit. Erst dann kann er loslegen. Cloudflare überträgt das auf KI-Agenten. Die fähigsten Agenten haben eines gemeinsam: Sie bekommen einen eigenen Computer. Ein Container allein reicht nicht. Der Agent braucht eine Umgebung, in der er Dateien sieht, Befehle ausführt, Werkzeuge nutzt und das Ergebnis testet.

Cloudflare hat mit @cloudflare/computer eine erste Vorschau einer Laufzeitumgebung vorgestellt. Jeder Agent bekommt einen virtuellen Arbeitsplatz. Die Plattform übernimmt die Details, ob der Code in einem Isolate, einer Container-Sandbox oder im Browser läuft. Der Agent merkt davon nichts. Entwickler müssen sich nicht mehr um die Infrastruktur kümmern und können sich auf die Aufgabe konzentrieren. Das klingt unspektakulär, ist aber ein Denkwechsel.

Vom Container zum Sandbox-Werkzeug

Wer in den letzten Monaten KI-Agenten gebaut hat, kennt das Muster: Erst startete man einen Container und ließ den Agenten darin laufen. Inzwischen bekommen Agenten Sandboxen nur noch als Werkzeug. Das Gehirn des Agenten – die Schleife aus Denken, Handeln und Bewerten – läuft getrennt von den Händen, die im Sandbox-System arbeiten. Cloudflare nennt das eine Befreiung. Aber es bringt ein neues Problem mit sich.

Das Problem ist einfach: Es gibt nicht genug Compute. Wenn Hunderte Millionen oder Milliarden Agenten gleichzeitig arbeiten, kann nicht jeder einen eigenen Container mit kompletter Linux-Umgebung bekommen. Die Clouds und Hyperscaler haben dafür nicht genug Ressourcen. Diese Knappheit erklärt den Bedarf an CPU-Leistung, nicht nur an GPUs. Wer skalierbare Agenten bauen will, muss über Container hinausdenken.

Cloudflare hat das früh getan. Mit Cloudflare Workers setzte das Unternehmen vor fast zehn Jahren auf Isolates. Das ist eine leichtere Ausführungsform als Container. Isolates teilen sich den zugrunde liegenden Prozess, starten in Millisekunden und verbrauchen nur dann Speicher, wenn sie arbeiten. Vor fast sechs Jahren kam mit Durable Objects der nächste Schritt: Zustand und Logik in einem horizontal skalierbaren Objekt, das bei Bedarf aufwacht und wieder einschläft. Das zahlt sich jetzt aus.

Warum Isolates besser zu Agenten passen

Isolates haben Eigenschaften, die zu KI-Agenten passen. Sie skalieren horizontal nahezu unbegrenzt. Sie starten und stoppen schnell. Sie können in den Ruhezustand gehen, wenn der Agent nichts tut. Sie speichern ihren eigenen Zustand. Und sie können eigene Isolates starten, um nicht vertrauenswürdigen Code auszuführen. Agenten wechseln ständig zwischen Warten und Arbeiten – genau dafür sind sie gebaut.

Ein Container ist dagegen ein schweres Geschütz. Er fährt ein vollständiges Betriebssystem hoch und braucht Speicher und CPU, auch wenn nichts passiert. Manche Aufgaben brauchen einen Container: Linux-Befehle, npm-Pakete, native Binaries. Für sie ist ein Isolate überfordert. Deshalb können Isolates seit dem vergangenen Jahr bei Bedarf eigene Container-Sandboxes starten. Der Agent selbst läuft in einem Durable Object, also einem Isolate. Den Container ruft er nur auf, wenn er ihn braucht.

Die Kombination aus horizontaler Skalierung im Isolate und vertikaler Skalierung im Container ist stark. Aber sie zwingt Entwickler, die beiden Welten selbst zu verdrahten. Man muss wissen, wann man welches Primitive einsetzt, und die Synchronisation zwischen Dateisystem und Umgebung selbst organisieren. Cloudflare glaubt, dass es einfacher geht. Hier setzt @cloudflare/computer an.

Ein Computer für den Agenten

Die zentrale Idee von @cloudflare/computer ist ein vorbereitetes Dateisystem. Der Agent bekommt ein virtuelles Dateisystem, deklarativ definiert und mit allem, was er für seine Aufgabe braucht. Dazu kommen mehrere Ausführungsumgebungen, mit denen er auf diesen Dateien arbeitet. Jede Umgebung hat eigene Stärken und Schwächen – bei Geschwindigkeit, Fähigkeiten und Kosten. In den Tests von Cloudflare wählten die Modelle überraschend zuverlässig die richtige Umgebung.

Eine Aufgabe, die nur Dateien verschiebt, Daten verarbeitet oder ein Git-Repository verwaltet, läuft direkt im Isolate. Ein Befehl, der Linux, npm oder eine native Binary braucht, läuft im Container. Beide Umgebungen arbeiten auf denselben Dateien, die permanent synchronisiert werden. Der Agent sieht eine konsistente Welt, egal wo der Code ausgeführt wird. Das ist die Kernabstraktion: ein Computer mit einem Dateisystem und mehreren Ausführungsmodi.

Technisch ist das Werkzeug eine Open-Source-Bibliothek. Eine Workspace-Instanz läuft auf jedem Durable Object und stellt ein virtuelles Dateisystem plus Ausführungsruntime bereit. Das Dateisystem wird von SQLite gestützt und kann aus verschiedenen Quellen befüllt werden – aus Git-Repositories, Storage-Buckets oder eigenen Dateien. Dazu kommen Werkzeuge zum Lesen, Schreiben und Bearbeiten von Dateien, im Code-Modus oder über Bash-Befehle. Alle Operationen sind protokolliert und überwacht. Entwickler bekommen so feingranulare Kontrolle darüber, was der Agent ändern darf – und eine lückenlose Nachvollziehbarkeit.

Wie du es einsetzt

Die Installation läuft über npm: npm install @cloudflare/computer. Danach erstellst du eine Workspace auf einem Durable Object. Im Blogbeitrag wird ein Agent gebaut, der Bug-Reports sortiert. Der Agent bekommt die Workspace mit Dateisystem und Tools, dazu einen Container als Backend. Die Modell-Schleife nutzt die Tools, um Issues zu analysieren und zu beantworten. Du kannst die Workspace-API auch direkt verwenden, etwa um die Umgebung vorzubereiten, bevor der Agent startet.

Im Paket sind mehrere Execution Backends enthalten. Das erste ist ein Isolate-basiertes Runtime, das mit just-bash Shell-Code in JavaScript übersetzt und in einem dynamischen Worker ausführt. Das Dateisystem ist hier direkt über Worker-Bindings verfügbar. Das zweite Backend ist ein Container-Runtime, das Cloudflare Containers nutzt und eine vollständige Linux-Umgebung bereitstellt. Das Dateisystem wird über ein FUSE-Mount eingebunden. Änderungen im Container werden automatisch zurückgeschrieben. Wer will, kann eigene Backends schreiben.

Für Agenten gibt es ein AI-SDK-kompatibles Toolkit mit den üblichen Werkzeugen: read, write, edit, ls und exec. Das exec-Tool akzeptiert ein backend-Argument. Die Tool-Beschreibung führt das Modell dazu, selbst zu entscheiden, ob es den schnellen, günstigen Worker oder den vollwertigen Container braucht. In den Tests von Cloudflare treffen die aktuellen Frontier-Modelle diese Entscheidung zuverlässig. Sie greifen nur dann zum Container, wenn es nötig ist.

Was das für die Zukunft bedeutet

Cloudflare sieht heute Agenten, die ausschließlich Isolates nutzen, um JavaScript-Anwendungen zu bauen, zu test

Quelle: blog.cloudflare.com

Stell dir vor, du arbeitest in einem Team. Ihr nutzt einen gemeinsamen Chat, in dem ein KI-Agent sitzt. Du schreibst ihm eine persönliche Nachricht, und er erledigt Aufgaben für dich. Er kennt deine Vorlieben, deine Projekte, deine Art zu arbeiten. Der Agent ist nützlich, weil er dich versteht. Aber was passiert, wenn dieser Agent nicht nur dein Assistent sein soll, sondern für die ganze Firma arbeiten soll? Dann darf er nicht mehr nur dich kennen. Er muss verstehen, wer gerade spricht, in welchem Raum die Anfrage gestellt wurde, welche Informationen für wen gedacht sind und welche Rechte an welcher Stelle gelten. Genau dieses Problem versucht das neue Open-Source-Projekt QM zu lösen.

Der Unterschied zwischen persönlichem Agenten und Company-Agent

Ein persönlicher Agent wird nützlich, indem er eine einzige Person lernt. Er speichert Vorlieben, wiederkehrende Abläufe und Tools. Seine Kontinuität ist persönlich. Das macht ihn mit der Zeit so wertvoll. Ein Company-Agent hat eine schwierigere Aufgabe. Er muss genug wissen, damit Menschen effektiv zusammenarbeiten können – ohne das gesamte Unternehmen als eine einzige Person mit einer einzigen Berechtigung zu behandeln. Ein Firmen-Chat ist eben kein besonders langes Gespräch mit einem riesigen Verlauf. Es ist ein Geflecht aus verschiedenen Menschen, Teams, Projekten und Vertraulichkeitsstufen.

Der Tech-Blogger, der diesen Artikel verfasst hat, beschreibt genau diese Problematik. Er hat sich intensiv mit QM beschäftigt, dem neuesten Wurf von Y Combinator. Die bekannte Startup-Schmiede hat QM als Open-Source-Projekt veröffentlicht, nachdem sie wertvolle Erfahrungen gesammelt hat: Y Combinator hat mehr als 50 Hermes-Agenten als persönliche Assistenten für Mitarbeiter bereitgestellt. Und dabei festgestellt, dass allein die Verwaltung dieser Flotte eine Herausforderung ist. Eine charmante Erkenntnis: Selbst mit 50 gut funktionierenden persönlichen Agenten ist die Organisation des Ganzen komplex. Und jetzt stell dir mal vor, wie das erst bei einer Firma mit tausend Mitarbeitern aussieht.

Die Analogie des Hauses mit vielen Räumen

Um zu verstehen, was QM anders macht, hilft eine einfache Analogie. Stell dir ein großes Haus vor. In diesem Haus arbeitet ein Unternehmen. Es gibt Einzelbüros, in denen Mitarbeiter private Notizen machen. Es gibt Besprechungsräume für kleine Gruppen. Es gibt Abteilungsflure, Team-Bereiche und schließlich das Foyer, das alle betreten können. Jeder Raum hat eigene Regeln. Im Intranet-Schrank liegen andere Zugangsdaten als im Projektraum. Und wenn ein Mitarbeiter das Haus verlässt, verliert er automatisch seinen Schlüssel – aber die Erinnerungen an seine Projekte bleiben dort, wo sie entstanden sind.

Ein normaler KI-Agent, der alle diese Räume als einen einzigen Raum behandelt, würde bald entscheidende Grenzen übersehen. Wer darf die Antwort sehen? Gehört das Memo zum Projekt oder zur persönlichen Vorbereitung? QM führt dafür eine explizite Struktur ein. Die Software erkennt fünf verschiedene Bereiche: persönlich, Kanal, Gruppe, Team und Organisation. Das klingt banal, ist aber ein entscheidender Schritt. Damit gesteht die Architektur ein, dass ein Unternehmen keine einzige riesige Konversation ist. Es braucht einen Vokabular, um zu beschreiben, wo Arbeit hingehört und wer dort zuhause ist.

Eine Steuerungsebene statt einer monolithischen KI-Schleife

Die eigentliche architektonische Entscheidung von QM ist, die Organisationslogik aus der KI-Schleife herauszulösen. Ein Agent-Harness – also das System, das die KI-Abfrage ausführt – kann für einen einzelnen Schritt zuständig sein: Anfrage interpretieren, Tools aufrufen, Aufgabe bearbeiten, Ergebnis liefern. QM übernimmt als „Control Plane“ die Verantwortung für den Kontext: Es klärt, wer spricht, welcher Bereich betroffen ist, welcher gemeinsame Zustand existiert und welche Richtlinien und Genehmigungen gelten. Dann entscheidet es, wo die Arbeit laufen soll und welche Harness – etwa Pi, OpenCode, Codex oder Claude Code – verwendet wird.

Diese Trennung ist wichtiger als die konkrete Liste der unterstützten Systeme. Ein Unternehmen kann so eine genehmigte Harness und ein genehmigtes Modell wählen, ohne dass sie sich in die Chat-Historie der Werkzeuge ausweiten. Die KI-Schleife macht die Arbeit. Die Steuerungsebene merkt sich, was diese Arbeit im Kontext des Unternehmens bedeutet. Das ist keine magische Portabilität. Man kann nicht einfach ein laufendes System zwischen verschiedenen Harnesses hin- und herschieben, ohne dass sich Verhalten oder Abläufe ändern. Aber der gemeinsame Kontext hat einen festen Ort.

Warum diese Perspektive gerade für Hermes-Fans interessant ist

Der Autor des ursprünglichen Artikels liest QM aus der Perspektive eines Menschen, der den Hermes-Agenten gewohnt ist. Das ist kein objektiver Produktvergleich, sondern eine sehr ergiebige Kontrastübung. Hermes funktioniert intuitiv als persönlicher Agent. Sein Wert wächst mit den persönlichen Tools, Erinnerungen und Arbeitsabläufen einer einzelnen Person. Der Agent wird über die Zeit nützlicher, weil er genau diese eine Person abbildet. Kontinuität ist etwas sehr Individuelles. QM stellt nun die Frage, was passiert, wenn diese Kontinuität für eine Gruppe gelten soll.

Ein Team möchte ebenfalls, dass die Arbeit mit der Zeit leichter wird. Ein Projektraum sollte sich merken, wie der Release-Prozess funktioniert, ohne dabei private Gespräche aus dem ganzen Unternehmen aufzusaugen. Menschen sollen durch denselben Agenten zusammenarbeiten können, ohne zu einer anonymen Masse zu verschmelzen. Deshalb braucht es eine Vorstellung davon, wessen Absicht gerade ausgeführt wird, welcher Raum den Kontext liefert, wer Änderungen vornehmen darf und wo das Ergebnis sichtbar bleibt.

Sicherheit und Governance: keine rosarote Brille

Der Artikel macht sehr deutlich, dass QM ambitioniert und früh ist. Die Autoren warnen davor, die Isolationsziele als Garantie zu verstehen. Es gibt kein Zertifikat, keinen Beweis, dass keine Daten leaken. Das ist keine Kritik am Projekt, sondern eine vernünftige Ansage: Wer eine so mächtige Software betreibt, braucht eine eigene Sicherheitsüberprüfung. QM hat einen Modus namens „Auto“, der Inhalte nicht immer prüft, und einen Modus „Strict“, der bei jedem Tool-Aufruf eine menschliche Freigabe verlangt. Die Sandbox-Optionen haben unterschiedliche Eigenschaften. Die Autoren betonen, dass man die funktionierenden Komponenten nicht mit vollständiger Netzwerk-Isolation verwechseln sollte.

Ein weiterer wichtiger Punkt ist der gemeinsame Speicher. Ein System, das sich im Namen einer Gruppe erinnert, braucht klare Regeln für Aufbewahrung, Löschung, Audit-Zugriff und rechtliche Pflichten. Das ist eine Governance-Frage, kein Hinweis auf einen Datenleak. Wer einen Agenten in ein Unternehmen einlädt, muss wissen, wer für das Gelernte verantwortlich ist. Eine persönliche KI-Erinnerung ist eine Sache. Eine geteilte Erinnerung betrifft alle Mitarbeiter.

Der Kern: Ein Unternehmen ist keine Person

Die Idee hinter QM ist größer als diese erste Implementierung. Die Liste der Harnesses kann sich ändern, das Sicherheitsmodell kann reifen, manche Entscheidungen von heute werden verschwinden. Aber das Grundproblem bleibt: Ein geteilter Agent ist nicht einfach ein persönlicher Agent mit mehreren Benutzern im selben Chat. Er braucht eine explizite Theorie von Personen, Räumen, Autorität, Erinnerung und Verantwortung. QM hat dieses Problem in den Vordergrund gerückt.

Es trennt den Agenten, der einen Arbeitsschritt ausführt, von der organisatorischen Steuerungsebene, die diesem Schritt Kontext und Grenzen gibt. Damit bekommen wir etwas Konkretes zum Beobachten: Schafft QM es, dass Umfang, Autorität und Erinnerung im normalen Arbeitsalltag nutzbar werden – nicht nur in einem Architekturdiagramm? Wenn ja, dann sieht der Company-Agent nicht mehr aus wie ein riesiger Chat, sondern wie eine gemeinsame Infrastruktur. Selbst wenn diese konkrete Software nicht die endgültige Antwort ist, ist genau dieser Wechsel der Denkweise bemerkenswert.

Für alle, die sich mit KI-Technologie beschäftigen, ist QM ein spannendes Beispiel dafür, wie wir die nächste Stufe der Zusammenarbeit mit künstlicher Intelligenz gestalten. Es zeigt, dass es bei KI nicht nur um schlauere Modelle geht, sondern um die Frage, wie wir diese Modelle in soziale und organisatorische Strukturen einbetten. Wer verstehen will, was KI für Einsteiker bedeutet und wie KI-Anwendungen im Unternehmen konkret aussehen, findet in diesem Projekt viele Antworten. QM erklärt auf seine Art, was eine künstliche Intelligenz braucht, um nicht nur zu antworten, sondern wirklich zu verstehen – in welchem Raum sie sich gerade bewegt.

Quelle: magnus919.com

Stell dir vor, du bekommst einen neuen Kollegen. Er ist hochmotiviert, lernt schnell und arbeitet rund um die Uhr. Aber er kommt aus einer anderen Welt: Er hat noch nie auf deinem Rechner gearbeitet, kennt deine Skripte nicht und scheitert an den stillschweigenden Absprachen, die in deinem Team einfach jeder zu wissen scheint. So ähnlich erging es dem Unternehmen Cursor, als es seinen Cloud-Agenten eigene Computer gab. Die Entwicklerinnen und Entwickler merkten schnell: Wer Cloud-Agenten produktiv einsetzen will, muss deren Entwicklungsumgebung genauso ernst nehmen wie ein Produkt. Dieser Blogpost erklärt, wie Cursor das angegangen ist und warum die Umgebung zum entscheidenden Faktor wurde.

Vom lokalen Rechner zur Cloud-VM

Der erste Schritt war ernüchternd simpel und gleichzeitig verdammt aufwendig: Die Cloud-Agenten sollten Codeänderungen testen können. Dafür musste das Monorepo von Cursor in einer Cloud-VM lauffähig sein. Wer schon einmal eine Remote-Entwicklungsumgebung eingerichtet hat, kennt das Problem: Was lokal funktioniert, ist in der Cloud nicht automatisch vorhanden. Die meisten Entwicklerinnen und Entwickler bei Cursor arbeiten auf Macs, die Cloud-VMs laufen aber auf Linux. Also mussten Utilities und Setup-Skripte so angepasst werden, dass sie auf Ubuntu funktionieren. Dazu kam ein Dockerfile, das als Startpunkt für jeden Cloud-Agenten dient und die kritischen Entwicklungsabhängigkeiten enthält.

Doch damit war es nicht getan. Denn Agenten brauchen Zugriff auf Secrets, um Tests auszuführen. Das Sicherheitsteam von Cursor hat deshalb Funktionen eingebaut, die den Zugriff kontrollieren: Netzwerk-Egress-Restriktionen, gescopte und proxierte Git-Zugriffe, Secret-Scanning in Commits und Commit-Messages sowie Redaktion von Secrets in Tool-Ergebnissen. Letzteres ist besonders elegant: Selbst wenn der Agent versucht, einen Secret-Wert auszulesen, bekommt er nur maskierten Text zu sehen. Das sind Sicherheitsmaßnahmen, die nicht den Menschen schützen sollen, sondern die Infrastruktur vor ungewolltem Datenabfluss bewahren.

Der Agent als Nutzer einer vereinfachten Oberfläche

Nachdem die Entwicklungsumgebung technisch auf Linux lief, zeigte sich das nächste Problem: Die Agenten waren trotzdem schlecht darin, den Code auszuführen. Das lag nicht an mangelnder Intelligenz, sondern an der Komplexität der Entwicklererfahrung. Bei Cursor gab es zahlreiche Build-Kommandos, Build-Flags und Utility-Skripte, die man erst lernen musste. Ein Mensch merkt sich solche Abläufe nach ein paar Wochen. Ein Agent, der jedes Mal frisch startet, steht vor einem Berg aus undokumentiertem Zusammenhangswissen.

Die naheliegende Lösung waren Skills, also dokumentierte Anleitungen für den Agenten. Sie halfen am Rand, lösten das Grundproblem aber nicht: Die Kommandos selbst waren verschachtelt und voller Stolperfallen. Deshalb entstand bei Cursor ein Werkzeug namens anydev. Diese CLI erlaubt es Agenten, alle Dienste mit einem einzigen Befehl zu starten. Utility-Skripte werden durch anydev geroutet, und jeder Unterbefehl hat ausführliche --help-Menüs. Dazu kommt ein Supervisor-Prozess, der langlaufende Build-Kommandos überwacht und bei Abstürzen neu startet. Der Agent muss sich also nicht mehr darum kümmern, ob ein Prozess noch läuft.

Dieser Schritt war der Wendepunkt. Vorher mussten Agenten mehrere Befehle kennen, versteckte Fußangeln vermeiden und Prozesse im Auge behalten. Nachher war die Komplexität in einem Tool gebündelt, das selbst erklärend war. Skills dokumentierten dann nur noch, wie man anydev benutzt – und nicht mehr, welche kryptischen Flags man für welchen Dienst braucht. Laut dem Cursor-Team war das der Moment, in dem Cloud-Agenten echten Mehrwert gegenüber lokalen Agenten boten. Mit eigenem Rechner, Bildschirmaufnahme und funktionierender Entwicklungsumgebung konnten sie Änderungen end-to-end testen und die Korrektheit ihrer Arbeit nachweisen. Sie zeichneten Demos auf, teilten sie in Slack oder hängten sie an Pull Requests. Ingenieure konnten Merges und Deployments durchführen, ohne den Branch lokal auszuchecken.

Eine selbstheilende Umgebung

Eine Entwicklungsumgebung ist aber kein statisches Gebilde. Sie ändert sich mit jedem Commit, mit jeder neuen Abhängigkeit, mit jeder Verschärfung der Sicherheitsrichtlinien. Ein Cloud-Agent, der heute fehlerfrei arbeitet, kann morgen scheitern, weil sich ein Pfad geändert hat oder ein Secret nicht mehr gültig ist. Cursor hat deshalb eine Diagnose- und Reparatur-Ebene gebaut: den Cursor Cloud MCP. MCP steht für Model Context Protocol, ein offener Standard, der es ermöglicht, Werkzeuge dynamisch bereitzustellen. Der Vorteil: Die Schnittstellen lassen sich ändern, ohne den Agenten-Loop neu bauen zu müssen.

Cloud-Agenten nutzen diese MCP-Schnittstelle, um ihre eigene Umgebung zu inspizieren. Sie prüfen, ob Setup-Fehler vorliegen, ob die Egress-Policy noch stimmt, ob sich Secrets geändert haben. So können sie Probleme erkennen, noch bevor sie zu Fehlern führen. Darauf aufbauend entstand der Cloud Doctor: eine Automatisierung, die regelmäßig nach Fehlern sucht, zwischen transienten und dauerhaften Fehlern unterscheidet, eine Ursachenanalyse durchführt und bei hoher Konfidenz selbst Pull Requests öffnet, um die Umgebung zu reparieren.

Das klingt nach einem versierten DevOps-Team, nur eben als Software realisiert. Der Cloud Doctor ist nicht einfach ein Watchdog, der einen Dienst neu startet. Er versteht den Kontext: Dieser Fehler kam letzten Freitag schon einmal und war harmlos, jener ist neu und deutet auf ein echtes Problem hin. Er erinnert sich, welche Fehler transiente Ausreißer sind und welche auf systematische Schwächen hinweisen. Und er kann nicht nur reparieren, sondern auch die Ursache beheben – indem er einen Pull Request erstellt, der die Umgebung an die neue Realität anpasst.

Die Umgebung als lernendes System

Interessant wird es, wenn der Cloud Doctor nicht nur Fehler behebt, sondern die Umgebung für zukünftige Agenten verbessert. Das passiert laut Cursor über die Analyse von Trace-Daten. Wenn ein Agent einen Fehler gemacht hat, einen umständlichen Weg gegangen ist oder ein Skill ihn in die Irre geführt hat, dann sieht man das in den Logs. Der Cloud Doctor schaut sich diese Stellen an und fragt: Welcher Skill war irreführend? Welches Kommando war nicht eindeutig? Welcher Workflow dauert systematisch zu lange?

Aus diesen Erkenntnissen entstehen dann konkrete Verbesserungen: Ein Skill wird neu formuliert, ein Befehl vereinfacht, die Umgebung wird so verändert, dass der nächste Agent einen kürzeren und sichereren Weg hat. Diesen Kreislauf könnte man als Selbstheilung bezeichnen, aber eigentlich ist es mehr: Es ist eine kontinuierliche Optimierung der Entwicklererfahrung für Maschinen. Cursor behandelt die Agenten wie Nutzer, deren Produktivität davon abhängt, wie gut die Umgebung zu ihrer Art zu arbeiten passt. Und diese Nutzer sind gnadenlos ehrlich: Wenn etwas nicht funktioniert, scheitern sie sichtbar. Das ist ein Vorteil gegenüber menschlichen Nutzern, die oft einfach stillschweigend einen Workaround finden.

Die Zahlen, die das Cursor-Team nennt, sind beeindruckend. Im Dezember verfassten Cloud-Agenten etwa eines von zehn Pull Requests, die in das Monorepo gemergt wurden. Heute, nur wenige Monate später, sind es mehr als die Hälfte. Das ist kein Beweis für überirdische KI-Fähigkeiten, sondern für die Qualität der Umgebung. In einer Umgebung, die regelmäßig repariert, vereinfacht und an die aktuelle Codebasis angepasst wird, können Agenten ihre Stärke ausspielen: Sie arbeiten schnell, parallel und ohne Angst vor Fehlern – solange die Fehler schnell sichtbar und behebbar sind.

Drei Fragen an die eigene Codebasis

Was bedeutet das für Teams, die Cloud-Agenten einführen wollen? Das Cursor-Team schlägt vor, sich drei Fragen zu stellen. Erstens: Haben Agenten Zugriff auf dieselben Werkzeuge und Daten wie ein Entwickler? Zweitens: Können Agenten Skills finden, die dokumentieren, wie die Entwickler wirklich arbeiten? Drittens: Können Agenten die zentralen Workflows testen und verifizieren? Wer diese drei Fragen ehrlich beantwortet, erkennt schnell, wo die eigene Umgebung Lücken hat.

Die erste Frage zielt auf technische Gleichberechtigung. Ein Agent, der nicht dieselben Bibliotheken, Datenbanken oder Secrets nutzen kann wie ein Mensch, wird immer ein Bürger zweiter Klasse bleiben. Die zweite Frage ist eine Frage der Kultur: Viele Teams dokumentieren nicht, wie sie tatsächlich arbeiten. Sie haben Skripte auf dem Rechner eines Kollegen, Notizen in einem Ticket oder gar kein Wissen, weil es nur als Bauchgefühl existiert. Agenten können damit nichts anfangen – sie brauchen explizite, auffindbare Beschreibungen. Die dritte Frage ist der Härtetest: Kann ein Agent eine Änderung machen und dann beweisen, dass sie funktioniert? Wenn dafür zehn manuelle Schritte nötig sind, wird es schwierig.

Auf den ersten Blick mag das wie eine Checkliste für KI-Projekte wirken. Tatsächlich ist es eine Checkliste für gute Softwareentwicklung. Dass Cursor das Monorepo auf Ubuntu lauffähig gemacht hat, ist keine KI-Magie, sondern solides Engineering. Dass anydev die Build-Kommandos vereinfacht hat, ist eine klassische Verbesserung der Entwicklererfahrung – nur eben für einen anderen Nutzer. Und dass der Cloud Doctor Fehler behebt, bevor sie zum Problem werden, ist nichts anderes als Site Reliability Engineering, angewendet auf Agenten.

Was bleibt, ist eine erwachsene Erkenntnis: Cloud-Agenten sind keine Wunderwaffe, sondern Werkzeuge, die nur so gut sind wie ihre Umgebung. Eine chaotische Codebasis mit undokumentierten Skripten wird auch durch die besten Modelle nicht produktiv. Wer jedoch bereit ist, die Entwicklungsumgebung wie ein Produkt zu behandeln – mit Nutzerforschung, Bugfixes und kontinuierlicher Verbesserung – der bekommt Agenten, die nicht nur Code produzieren, sondern auch Verantwortung übernehmen können. Das ist der eigentliche Umbruch: Nicht die KI schreibt die Mehrheit der Pull Requests, sondern die Umgebung macht es möglich.

Quelle: cursor.com

Du kennst das: Du liest einen Artikel, und nach drei Sätzen hast du ein ungutes Gefühl. Das hat eine KI geschrieben. Nicht unbedingt, weil der Text fehlerhaft ist, sondern weil bestimmte Wörter und Floskeln immer wieder auftauchen. Künstliche Intelligenz hat einen eigenen Sound. Ein Tech-Blogger wollte das ändern – mit einem eher unbekannten Hebel: logit_bias. Das ist ein Parameter in manchen KI-APIs, mit dem sich die Wahrscheinlichkeit beeinflussen lässt, mit der ein bestimmtes Wort oder Wortteil erzeugt wird. Klingt trocken, hat aber weitreichende Folgen.

Ein kleiner Eingriff im Kopf der KI

Bevor eine Sprach-KI das nächste Wort schreibt, berechnet sie für jedes mögliche Wort einen Zahlenwert, den sogenannten Logit. Aus diesen Werten entstehen Wahrscheinlichkeiten, und danach wird das nächste Wort ausgewählt. logit_bias greift an genau dieser Stelle ein: Du kannst einen Zahlenwert zu einem bestimmten Wort hinzuaddieren, bevor die KI ihre Wahl trifft. Ein negativer Wert senkt die Chance, dass dieses Wort gewählt wird. Ein Wert wie -100 wirkt praktisch wie ein Verbot.

Stell dir das wie einen Weichenwärter vor, der bei jedem Zug eine Weiche etwas anders stellt. Nicht komplett, nur um ein paar Grad. Die KI kann immer noch viele Wörter wählen, aber ein paar sind plötzlich nicht mehr so attraktiv. Der Unterschied zu einem normalen Prompt ist gewaltig. Wenn du in den Prompt schreibst „benutze das Wort nicht“, liest die KI das als Anweisung. Sie kann es aber ignorieren, wenn andere Anweisungen wichtiger erscheinen. logit_bias fragt nicht, es arbeitet auf der Ebene der Zahlen.

Warum ein Verbot im Prompt nicht reicht

Ein Wort in den Prompt zu schreiben ist einfach und erfordert kein technisches Verständnis. Die KI hat dabei aber Spielraum. Sie kann entscheiden, ob ein Wort wirklich weggelassen werden muss oder ob es in einem bestimmten Satz die beste Wahl ist. Dieser Spielraum ist sowohl eine Stärke als auch eine Schwäche. Manchmal hält sich die KI daran, manchmal nicht. Und wenn sie sich zu genau daran hält, ersetzt sie ein normales Wort durch ein unpassendes Synonym.

Der Autor des Versuchs hat das in einem separaten Test mit einem anderen Modell geprüft. Er fügte eine Liste mit 93 verbotenen Wörtern in den Prompt ein. Fast alle Wörter wurden vermieden, aber in zwei von fünf Artikeln gingen Informationen verloren. Die KI hatte die Anweisung zu wörtlich genommen und dabei Fakten verändert oder weggelassen. Das zeigt: Ein Prompt ist eine Bitte, kein Hebel an der Maschine.

Nicht jede API kann das

Der nächste Punkt ist praktischer Natur. Nicht jedes KI-Modell unterstützt logit_bias. OpenAI erwähnt den Parameter zwar noch in der Dokumentation, aber die aktuellen Modelle lehnen ihn mit einer Fehlermeldung ab. Anthropic, der Hersteller von Claude, hat den Parameter erst gar nicht. Etwas besser sieht es bei OpenRouter aus, einer Art Sammel-Schnittstelle für viele Modelle. Dort gibt es eine Suche nach unterstützten Parametern, und der Autor fand 115 Modelle.

Auch das ist noch kein Grund zur Freude. Manche Anbieter listen den Parameter zwar, ignorieren ihn aber stillschweigend. Der Autor berichtet von einem Modell, das den Parameter akzeptierte, dann aber einen Wert von -100 einfach ignorierte. Man muss also vorher testen, ob der jeweilige Anbieter den Parameter tatsächlich verarbeitet. Im Experiment half es, einen bestimmten Provider festzulegen und Fallbacks zu deaktivieren. Selbst wenn der Parameter in der Modellliste steht, heißt das nicht, dass er überall funktioniert.

Der Selbstversuch: Acht Artikel, zwei Durchgänge

Der eigentliche Test war aufwendig. Der Autor nahm acht komplette KI-generierte Artikel und schickte sie durch das Modell DeepSeek V4 Flash. Jeder Artikel wurde zweimal bearbeitet: einmal ohne besonderen Filter, einmal mit einer Negativ-Bewertung von -8 für eine Liste auffälliger KI-Wörter. Die Aufgabe war immer dieselbe: Den Text bearbeiten, aber alle Fakten, Namen, Zahlen und Schlussfolgerungen beibehalten.

Das Ergebnis war eindeutig. In den Quelltexten kamen 264 Wörter aus der schwarzen Liste vor. In den gefilterten Versionen waren es noch 180. Der Filter entfernte also etwa ein Drittel der auffälligen Wörter. Aber er veränderte auch mehr am Text. Die Übereinstimmung zwischen Quelle und Bearbeitung war geringer, wenn der Filter aktiv war. Sieben der acht gefilterten Versionen blieben inhaltlich korrekt. Eine veränderte eine Entität und strich eine Absicherung – das ist ein Problem, weil dadurch eine vorsichtige Aussage zu einer falschen Gewissheit wurde.

Bei der Bewertung von Grammatik, Klarheit und Stil schnitten drei gefilterte Artikel besser ab als die Quelle, vier waren gleichwertig, einer war schlechter. Dieser eine enthielt Sätze wie „That details why…“, ein offensichtlicher Fehler, der durch den Wortfilter entstanden war. Am Ende bestanden sieben von acht ungefilterten Versionen den Qualitätscheck, aber nur sechs von acht gefilterten. Der Preis für weniger KI-Sprache war also ein verlorener Artikel.

Warum die KI dann dümmer wirkt

Interessant ist ein Nebeneffekt: Die KI wirkte mit Filter manchmal weniger intelligent. Nicht, weil sie weniger wusste, sondern weil ihr die passenden Wörter fehlten. Die schwarze Liste enthielt nur die Wörter, aber keine Hinweise darauf, was stattdessen besser wäre. Die KI musste improvisieren und griff dabei manchmal zu Konstruktionen, die ein Mensch so nicht schreiben würde.

Eine höhere Strafe half nicht weiter. Der Autor testete auch Werte von -4 und -12, aber der Effekt blieb uneinheitlich. Bei -100 verschwanden die Wörter zwar komplett, aber die KI begann, denselben Text immer wieder zu wiederholen. Ein zu starker Eingriff scheint das Gleichgewicht der Textproduktion zu stören. Die KI weiß nicht, warum ein Wort verboten ist, also kann sie nicht gezielt nach einer guten Alternative suchen.

Das ist der entscheidende Unterschied zwischen einer Anweisung im Prompt und einem Eingriff über logit_bias. Der Prompt hat Kontext. Er versteht, dass ein Wort in einer bestimmten Situation wichtig sein kann, auch wenn es auf der Liste steht. Die Zahlenkorrektur sieht nur den Token, nicht die Bedeutung. Sie ist stark, aber unempfindlich.

Was das für den Alltag bedeutet

Die Idee, KI-Texte allein durch das Verbannen bestimmter Wörter menschlicher zu machen, klingt verlockend. Der Versuch zeigt aber, wie fragil dieses Vorgehen ist. Die Wortwahl ist nur ein Teil des KI-Klangs. Rhythmus, Satzstruktur, Gedankensprünge und der Umgang mit Unsicherheit sind mindestens so wichtig. Ein Filter, der nur einzelne Wörter entfernt, behandelt das Symptom, nicht die Ursache.

Für die Praxis bedeutet das: Wer KI-Texte natürlicher machen will, sollte lieber in die Prompt-Formulierung investieren und dem Modell erklären, wann welche Formulierungen angemessen sind. Danach gehört eine manuelle Überarbeitung dazu. Das ist weniger aufregend als ein API-Trick, aber es liefert verlässlichere Ergebnisse. Der Autor räumt selbst ein, dass logit_bias ein Werkzeug für bestimmte Fälle ist – nicht mehr und nicht weniger. Es kann gezielt verhindern, dass ein bestimmtes Token erscheint, aber es kann nicht entscheiden, was stattdessen richtig ist. Diese Entscheidung bleibt weiterhin eine menschliche Aufgabe.

Quelle: vincentschmalbach.com

Stell dir vor, du hast eine KI, die Videos versteht und generiert. Du gibst ihr ein Standbild und eine Anweisung, etwa: „Hier rollt ein Ball durch ein Hindernisparcours – wo landet er?“ Und die KI zeigt dir eine Animation. Oft funktioniert das erstaunlich gut. Aber manchmal liefert sie Unsinn. Sie lassen den Ball durch die Wand plumpsen oder übersehen das Ziel komplett. Was dann? Bei Sprachmodellen kennt man das Problem: Ein schlecht formulierter Prompt führt zu einer schlechten Antwort. Also verbessert man den Text. Doch was, wenn die Eingabe gar kein Text ist, sondern ein Bild? Eine neue Arbeit von Google DeepMind zeigt, dass man auch das Bild selbst „prompten“ kann – und das oft besser wirkt als jeder Text.

Prompt Engineering: Mehr als nur Worte

Seit einigen Jahren weiß man, dass die Qualität von KI-Antworten stark davon abhängt, wie man die Anfrage formuliert. Ein kurzer, vager Satz wie „Erkläre Quantenphysik“ führt zu einem anderen Ergebnis als eine präzise Anweisung mit Beispielen und Zielgruppe. Diese Praxis nennt man Prompt Engineering. Sie ist eine Kunst, die sich ausprobiert, verfeinert und manchmal in Formelsammlungen gegossen wird. Doch mit dem Aufkommen multimodaler Modelle, die nicht nur Text, sondern auch Bilder und Videos verarbeiten, stellt sich die Frage: Gibt es das Pendant für visuelle Eingaben? Genau hier setzt die Forschung von Google DeepMind an.

Die Wissenschaftler nennen ihren Ansatz „Visual Prompt Engineering“ oder kurz VIPE. Die Idee ist bestechend einfach: Wenn ein Video-Modell Schwierigkeiten mit einem Eingabebild hat, dann verändert man eben das Bild, bevor man es der KI gibt. Das kann eine radikale Stiländerung sein, etwa von einer abstrakten Skizze zu einer fotorealistischen Szene. Es kann aber auch eine subtile Anpassung sein, wie das Hinzufügen einer dicken Kontur oder das Ändern des Hintergrunds. Das Entscheidende ist: Man bleibt in der visuellen Domäne, man tippt keine neuen Anweisungen ein, sondern manipuliert das Bild selbst.

Wie VIPE funktioniert

Die Methode ist verblüffend unkompliziert. Man nimmt das ursprüngliche Aufgabenbild und lässt es von einem Bildbearbeitungsmodell umwandeln. Solche Modelle sind inzwischen so gut, dass sie aus einer einfachen Strichzeichnung eine plausible Fotografie erzeugen können, ohne die zugrunde liegende Struktur zu verändern. Man kann auch gezielter vorgehen: Statt das ganze Bild neu zu gestalten, editieren die Forscher einzelne Konzepte. Sie ersetzen etwa die flache Farbe eines Kreises durch eine glänzende 3D-Oberfläche oder entfernen die Sättigung aller nicht relevanten Objekte. Diese feinen Eingriffe nennen sie „Atomic Concept Edit“.

Die Wahl der Transformation ist nicht willkürlich. Die Forscher testen mehrere Varianten und schauen, welche die besten Ergebnisse liefert. Das erinnert ein wenig an das Ausprobieren verschiedener Textprompts – nur eben im Bildraum. Und hier zeigt sich eine interessante Beobachtung: Oft reicht es nicht, das Bild einfach „schöner“ zu machen. Die Transformation muss zur Aufgabe passen. Bei einer Physik-Aufgabe, bei der ein Ball durch Rampen rollt, hilft ein fotorealistischer Industriehallen-Stil mehr als eine bunte Candy-Landschaft. Bei einem Puzzle, bei dem Punkte verbunden werden sollen, sorgt eine dicke schwarze Kontur um die Punkte für den entscheidenden Unterschied.

Sechs Aufgaben, sechs Erfolge

Die Forscher haben ihr Verfahren an sechs verschiedenen Aufgaben getestet. Da ist zuerst die Physik-Aufgabe: Ein Ball rollt über Rampen und soll in einem von drei Eimern landen. Das Originalbild, eine abstrakte Skizze, führt oft zu Fehlern. Wird dasselbe Bild in eine fotorealistische Förderanlage verwandelt, gelingt die Vorhersage deutlich besser. Ähnlich sieht es bei der Suche nach einem Objekt aus, das gleichzeitig eine bestimmte Form und Farbe haben muss. Hier hilft es, die relevanten Kreise in glänzende 3D-Kugeln zu verwandeln – so stechen sie für das Modell klar hervor.

Auch bei einfachen Denksportaufgaben wie „Verbinde gleichfarbige Punkte“ oder „Sortiere drei Zahlen“ wendet sich das Blatt. Ein minimalistisches Bild mit flachen Kreisen wird zum Stolperstein. Derselbe Bildinhalt, aber als Tafel mit Kreidepunkten oder als Retro-Arcade-Sprites, bringt das Modell auf die richtige Spur. Selbst beim Labyrinth-Lösen, einer Aufgabe, die ein hohes Maß an räumlichem Verständnis erfordert, kann eine Umwandlung in eine „klassische 2D-Arcade-Szene“ die Erfolgsquote erheblich steigern. Und beim Rush-Hour-Puzzle, bei dem ein rotes Auto aus einem Stau herausgefahren werden muss, zeigt sich ein ähnliches Muster.

Das Bemerkenswerte an diesen Ergebnissen ist nicht, dass alle Aufgaben perfekt gelöst werden. Es gibt weiterhin Fehler und Schwächen. Aber die Verbesserung ist systematisch und reproduzierbar. Die Forscher zeigen für jede Aufgabe mehrere Varianten, die alle zum Erfolg führen. Das ist ein starkes Indiz dafür, dass der Effekt kein Zufall ist, sondern eine grundlegende Eigenschaft von Video-Modellen widerspiegelt.

Warum dieser Ansatz so überraschend wirkt

Man sollte meinen, dass ein Video-Modell, das auf riesigen Datenmengen trainiert wurde, auch mit abstrakten Skizzen umgehen kann. Schließlich sehen Modelle während des Trainings Millionen von Bildern, auch Diagrammen und Zeichnungen. Doch die Realität sieht anders aus. Offenbar sind diese Modelle auf „natürliche“ visuelle Eingaben spezialisiert, also auf Fotos oder realistische Szenen. Abstrakte Darstellungen fallen aus ihrer Verteilung heraus und führen zu unsinnigen Vorhersagen. Indem man das Bild in einen vertrauten Stil übersetzt, holt man das Modell sozusagen in seine Komfortzone zurück.

Interessanterweise ist dieser Effekt stärker als die Optimierung des Textprompts. Das bedeutet: Die visuelle Eingabe trägt mehr zur Lösung einer visuellen Aufgabe bei als die sprachliche Beschreibung. Das ist eine wichtige Erkenntnis für alle, die mit Video-KI arbeiten. Es reicht nicht, eine detaillierte Textanweisung zu formulieren. Das Bild muss zur Aufgabe passen. Für die Praxis heißt das: Nutzer können ihre Ergebnisse verbessern, ohne das Modell zu verändern oder teure Rechenressourcen zu erhöhen. Ein einfacher Bild-Edit kann mehr bewirken als ein längerer Prompt oder mehr „Denkzeit“ des Modells.

Ein weiterer überraschender Punkt ist, dass die besten visuellen Transformationen nicht unbedingt die aufwendigsten sind. Ein schlichter Hintergrundwechsel von Weiß auf Schwarz oder das Hinzufügen einer dicken Kontur reicht manchmal aus, um das Modell auf die richtige Lösung zu bringen. Das spricht dafür, dass Video-Modelle stark auf visuelle Kontraste und klare Kanten reagieren. Sie scheinen Objekte besser zu „verstehen“, wenn diese deutlich abgegrenzt und mit einer satten Farbe oder einer 3D-Oberfläche versehen sind.

Eine Brücke zwischen Bild und Verständnis

Man kann sich das Ganze wie eine Übersetzung vorstellen. Das Modell spricht eine Sprache, die auf fotorealistischen Bildern beruht. Eine abstrakte Skizze ist für es wie eine Fremdsprache – es erkennt zwar einzelne Elemente, aber die Grammatik, also die physikalischen Gesetze und Beziehungen zwischen den Objekten, geht verloren. Visual Prompt Engineering übersetzt das Bild in die Muttersprache des Modells. Auf diese Weise kann die KI ihr gesamtes Wissen über Physik, Objekte und deren Interaktion nutzen, das sie aus unzähligen Videos gelernt hat.

Diese Perspektive macht auch deutlich, warum die Methode so effektiv ist. Video-Modelle sind darauf trainiert, die Welt in Bewegung zu verstehen. Sie haben gelernt, dass Bälle auf Rampen rollen, dass Autos sich durch Verkehr schlängeln und dass Zahlen sortiert werden können. Aber dieses Wissen ist eng mit dem visuellen Erscheinungsbild verknüpft. Wenn man ein Bild präsentiert, das wie ein abstraktes Diagramm aussieht, kann das Modell die Verbindung zu seiner Wissensbasis nicht herstellen. Die Transformation schafft diese Verbindung.

Natürlich hat die Methode auch Grenzen. Nicht jede Aufgabenstellung lässt sich durch eine einfache Bildtransformation verbessern. Die Forscher räumen ein, dass die Wahl der richtigen Transformation Erfahrung und Ausprobieren erfordert. Man weiß nicht immer im Voraus, welche Stiländerung dem Modell helfen wird. Und nicht jede Transformation ist neutral – man muss aufpassen, dass man nicht versehentlich wichtige Informationen im Bild verändert. Aber gerade die Kombination aus freier Stilwahl und gezielten Konzept-Editionen bietet einen flexiblen Werkzeugkasten.

Was bedeutet das für dich?

Wenn du selbst mit Video-Modellen experimentierst, also etwa mit KI-generierten Clips oder visuellen Reasoning-Aufgaben, dann nimm dir diesen Gedanken mit: Das Aussehen des Eingabebildes ist ein Teil des Prompts. Du solltest es genauso sorgfältig gestalten wie deine Textanweisung. Stelle dir Fragen: Ist das Bild klar? Heben sich die relevanten Objekte genug ab? Entspricht der Stil dem, was das Modell wahrscheinlich aus Videos kennt? Wenn dein Modell scheitert, versuche nicht nur, den Text zu ändern, sondern auch das Bild.

Diese Erkenntnis ist ein weiteres Puzzlestück im Verständnis von KI-Systemen. Sie zeigt, dass multimodale Modelle nicht einfach „alles sehen“, sondern dass sie auf bestimmte visuelle Muster angewiesen sind. Für Entwickler und Anwender ist das eine wertvolle Heuristik. Statt in Testzeit-Rechenleistung zu investieren, kann man mit einem einfachen Bild-Edit oft mehr erreichen. Das senkt die Kosten und macht KI zugänglicher.

Die Forschung von Google DeepMind trägt damit zu einer pragmatischen Sicht auf KI bei. Es geht nicht darum, Modelle unfehlbar zu machen, sondern darum, sie besser zu nutzen. Visual Prompt Engineering ist ein Werkzeug, das uns hilft, die Fähigkeiten bestehender Systeme voll auszuschöpfen. Und das ist vielleicht die wichtigste Botschaft: Die Zukunft der KI liegt nicht nur in größeren Modellen, sondern auch in klügeren Interaktionen. Das Bild, das du der KI zeigst, ist Teil der Botschaft. Gestalte es weise.

Quelle: visual-prompt-engineering.github.io