Wie SpatialAgents arbeiten.

Ein Chat verläuft als Kette aus Frage und Antwort, und jede Antwort ist ein Endpunkt.

Ein Coding-Agent ist kein Sprachmodell, sondern eine Arbeitsumgebung, in die ein Sprachmodell eingebettet ist. Die Umgebung stellt die Werkzeuge bereit, also Dateien lesen und schreiben, Kommandos ausführen und nachschlagen. Und sie stellt die Schleife bereit, die vom Auftrag über den Plan zum Werkzeugaufruf führt, das Ergebnis prüft und zum Plan zurückkehrt.

In dieser Schleife plant das Modell, ruft ein Werkzeug auf und liest das Ergebnis. Trägt der erste Weg nicht, probiert es einen anderen und plant neu.

Die Schleife endet an einem geprüften, brauchbaren Ergebnis oder an einer Rückfrage an den Menschen. Eine Prüfung allein beendet sie nicht, und nach einer Antwort läuft sie weiter.

Ein einzelner Lauf kann mehrere hundert Werkzeugaufrufe umfassen und über zwei Stunden dauern, ohne dass jemand eingreift. Die Erlaubnis dazu wird einmal am Anfang erteilt, nicht bei jedem Schritt.

Solche Umgebungen muss niemand selbst bauen, es gibt sie fertig.

Ein Sprachmodell kann nichts ausführen, es kann nur schreiben. Ein Werkzeugaufruf ist deshalb eine Nachricht mit festem Aufbau, die das Werkzeug und seine Eingaben nennt; die Umgebung führt das Werkzeug aus und schreibt das Ergebnis zurück.

Dieses Ergebnis landet im Kontext, also in dem Text, den das Modell bei jedem Schritt vor sich hat. Der Kontext ist begrenzt.

Gemessen wird er in Token. Ein Token ist ein Wort oder ein Teil eines Wortes, und in solchen Einheiten liest und schreibt ein Sprachmodell.

Jedes Ergebnis belegt einen Teil des Kontexts, deshalb kommt es darauf an, wie viel ein Werkzeug zurückgibt.

Wie viel dabei zusammenkommt, hängt am Modell. Bei derselben Aufgabe reicht der mittlere Verbrauch eines Laufs von drei Millionen bis zu fast hundert Millionen Token, und die höhere Zahl steht nicht für die bessere Karte.

Für Geodaten muss man solche Werkzeuge nicht erst bauen, es gibt sie seit Jahrzehnten.

Open-Source-GIS-Werkzeuge haben eine Eigenschaft, die für Agenten entscheidend ist: Man bedient sie mit Text.

Die GIS-Werkzeuge der Kommandozeile lesen, schreiben, projizieren und verschneiden Geodaten mit einem Befehl, und QGIS führt seine eigenen Geoalgorithmen über ein solches Kommando aus. Wer lieber in Python arbeitet, schreibt dieselbe Arbeit mit den GIS-Python-Bibliotheken als Skript.

Ein Coding-Agent schreibt genau solche Kommandos, und ein Übersetzer dazwischen ist nicht nötig, weil das Werkzeug schon da ist.

Was ein solcher Befehl erzeugt, ist eine Datei, die in der Fachsprache Layer heißt, also Datenebene. Eine Datenebene enthält Geometrien oder Rasterzellen und ihre Werte, aber noch kein Bild. Die Karte entsteht erst in QGIS, und das ist ein eigener Schritt.

Damit fehlt noch eines: der Weg zu QGIS selbst.

Damit ein Agent eine Anwendung bedienen kann, braucht er eine Liste ihrer Werkzeuge. Das Model Context Protocol, kurz MCP, legt fest, wie eine Anwendung diese Liste bereitstellt.

Jeder Eintrag nennt drei Dinge: den Namen des Werkzeugs, wofür es gut ist und welche Angaben es erwartet.

Ein Agent liest diese Liste, sobald er startet. Von da an steht sie in seinem Kontext, und er weiß, was die Anwendung kann.

Für QGIS gibt es einen solchen Server, die SpatialAgents-Bridge. Sie bietet 67 Werkzeuge an, geordnet in neun Gruppen. Die reichen vom Öffnen eines Projekts und dem Lesen seines Zustands über das Laden von Layern und das Abfragen ihrer Objekte bis zur Karte, zum Druck-Layout und zu länger laufenden Aufträgen. Die Bridge läuft als Prozess auf demselben Rechner wie QGIS.

Womit gearbeitet wird, ist damit geklärt. Wie im Projekt gearbeitet wird, steht in einer eigenen Datei.

Bevor ein Agent arbeitet, liest er eine Datei mit Anweisungen, die im Projekt liegt; jeder der drei Coding-Agenten kennt eine solche Datei unter seinem eigenen Namen. Darin steht, wie im Projekt gearbeitet wird.

Üblicherweise stehen vier Dinge darin: die Regeln der Arbeit, der Aufbau des Verzeichnisses, die verfügbaren Werkzeuge und die Prüfungen, die ein Ergebnis bestehen muss.

Bei SpatialAgents gibt es diesen Fachkontext nur einmal. Codex, Claude Code und OpenCode lesen denselben Text und arbeiten nach denselben Regeln, und wer die Arbeitsweise ändert, ändert eine Datei statt drei Konfigurationen.

Das gilt für das ganze Projekt. Fachwissen für einzelne Aufgaben steht woanders und wird erst geladen, wenn es gebraucht wird.

Ein Skill ist Fachwissen in einem Ordner: eine Beschreibung, dazu Referenzen und Skripte. Ein Agentensystem liest zu Beginn nur die Beschreibungen, und erst wenn eine Aufgabe zu einem Skill passt, lädt es ihn in den Kontext.

Der Gewinn liegt im Kontext, denn was nicht geladen ist, belegt keinen Platz.

Vier Skills gehören zum System. Der erste beschreibt die Werkzeuge der Bridge, der zweite die Gestaltung von Layern, der dritte die Druck-Layouts und der vierte die Diagramme in der Karte.

Der Anwender sagt in normaler Sprache, was er braucht, und das Fachwissen dazu steht im Skill; QML oder Layout-Interna muss niemand kennen.

Damit ist beschrieben, was ein Agentensystem weiß. Wie es daraus einen Plan für eine große Aufgabe macht, zeigt die agentische Planung.

Eine Gefahrenanalyse für eine Stadt ist keine Aufgabe für einen Schritt. SpatialAgents zerlegen sie in vier Teilaufgaben, nämlich Daten beschaffen, Geometrien prüfen, Indizes rechnen und Karte erzeugen, und legen diese Zerlegung als Plan an. Die vier Teilaufgaben arbeiten sie nacheinander ab: drei davon mit Python oder auf der Kommandozeile im Workspace, die Karte über das QGIS-Plugin und die Bridge. Der Plan bleibt dabei die Mitte der Arbeit und wird nach jedem Teilergebnis fortgeschrieben. Eine Prüfung, die nicht aufgeht, führt zum Auftrag zurück und erzeugt einen weiteren Schritt. Der Plan entsteht, bevor die Arbeit beginnt.

Der Plan ist freigegeben. Was dann geschieht, hat drei Stationen und eine Prüfung.

Zuerst läuft die Werkzeugschleife: Der Coding-Agent ruft Werkzeuge auf, und im Workspace entstehen Dateien. Der Workspace ist das gemeinsame Verzeichnis für SpatialAgents und QGIS, und gerechnet wird dort mit Python und auf der Kommandozeile.

Dann wirkt die Bridge in QGIS, wo aus den Dateien Layer werden und aus den Layern eine Karte.

Zum Schluss folgt die Prüfung, die der Plan für diese Teilaufgabe nennt. Die Bridge holt einen Screenshot und die Angaben zu den Layern aus QGIS, und passt das Ergebnis nicht, geht es zurück in die Schleife.

Die Zeit verteilt sich ungleich. Bei Opus entfielen von gut vierzig Minuten Laufzeit im Mittel mehr als zwei Drittel auf das Modell, knapp ein Drittel auf die Geoverarbeitung und nur wenige Sekunden auf QGIS.

Wie kurz der Rechenteil ausfällt, hängt an der Bibliothek, mit der gerechnet wird.

Die Geospatial API, kurz Geo-API, ist eine Python-Bibliothek, geschrieben für den Gebrauch durch Agenten. Ein Aufruf holt Daten, ein zweiter rechnet, und ein dritter schreibt das Ergebnis als Datei.

Ohne sie entsteht dieselbe Arbeit als lange Kette von Einzelschritten, bei der jeder Schritt ein Zwischenergebnis liefert und jedes Zwischenergebnis im Kontext landet.

Vier Eigenschaften senken den Tokenaufwand. Die Aufrufe sind deklarativ und lassen sich aneinanderhängen. Vor dem Laden lässt sich zählen, wie viele Objekte eine Abfrage trifft. Fehlermeldungen nennen den nächsten sinnvollen Schritt. Und der Aufruf geht direkt aus Python oder von der Kommandozeile heraus, ohne Umweg über einen Werkzeug-Wrapper.

Die Geo-API stand in den Läufen der Messreihen zur Verfügung.

Damit ist der Rechenteil beschrieben. Der Weg zurück nach QGIS führt über Plugin und Bridge.

Das Plugin macht das geöffnete QGIS-Projekt für SpatialAgents erreichbar. Es öffnet eine Verbindung, die nur auf diesem Rechner gilt und einen Zugangsschlüssel verlangt.

Über diese Verbindung kommen Werkzeugaufrufe an, und die Bridge setzt sie in QGIS-Operationen um: Sie lädt Layer, gestaltet sie, bewegt die Karte und baut Druck-Layouts.

Zurück gehen drei Dinge, nämlich der Zustand des Projekts, die Liste der Layer und ein Bild der Karte. Dieses Bild ist die Art, wie ein Coding-Agent sein eigenes Ergebnis ansieht.

Zwei Grenzen gelten dabei. Eingriffe, die das Projekt verändern, legt QGIS dem Anwender zur Bestätigung vor, und in QGIS läuft kein beliebiger Programmcode, sondern nur die deklarierte Operation.

Gerechnet wird deshalb an einer anderen Stelle.

SpatialAgents trennen zwei Arten von Arbeit: das Steuern von QGIS und das Rechnen mit Geodaten.

Gesteuert wird über die Bridge: Layer laden, gestalten, die Karte bewegen, ein Druck-Layout bauen, einen Screenshot holen.

Gerechnet wird im Workspace: mit Python-Bibliotheken, mit Kommandozeilenwerkzeugen, dazu Websuche, Datendownload und die Prüfung vorhandener Vektor- und Rasterdaten.

Das hat zwei Folgen. QGIS bleibt bedienbar, weil keine lange Rechnung die Oberfläche anhält. Und jedes Ergebnis liegt als Datei vor, die sich unabhängig vom Projekt öffnen und nachrechnen lässt.

An einer Stelle treffen sich beide Bahnen. Im Workspace entsteht ein GeoPackage, und die Bridge lädt es als Layer in das Projekt.

Offen ist noch, wo das Sprachmodell dabei rechnet.

Welches Sprachmodell rechnet, ist eine Einstellung. Dieselbe Aufgabe läuft mit einem Modell in der Cloud oder mit einem Modell auf dem eigenen Notebook, während Werkzeuge, Skills und die Verbindung zu QGIS dieselben bleiben.

Der letzte Abschnitt stellt eine Messreihe vor, Benchmark 8. Sie hat beide Wege gemessen und jeden Lauf nach denselben Kriterien auf einer Skala von hundert Punkten bewertet. Sieben Systeme aus Agent und Modell lösten dieselbe Gefahren- und Klimaanalyse für Stuttgart, jedes davon drei Mal.

Eines dieser Modelle lag dabei auf dem Schreibtisch: Qwen lief auf einem Notebook, erreichte knapp 84 von hundert Punkten und lag damit vor allen drei Cloud-Modellen von OpenAI.

Im lokalen Betrieb verlässt keine Anfrage das eigene Netz, und beide Wege führen zur selben QGIS-Karte.

Ob ein System die Aufgabe löst, entscheidet die Messung.

Ob ein System eine Aufgabe löst, zeigt eine Messreihe, und dafür gibt es Benchmarks.

Ein Benchmark ist eine feste Fachaufgabe mit einem Bewertungsrahmen. Jedes Modell bearbeitet sie mehrmals, jeder Lauf wird nach denselben Kriterien bewertet, und aus den Punkten wird eine Medaille.

Zwei Akten sind veröffentlicht. Die erste heißt Benchmark 8: Sieben Systeme aus Agent und Modell lösen dieselbe Gefahren- und Klimaanalyse für Stuttgart, jedes System drei Mal.

Die zweite ist die Behördenakte Alpen mit acht Aufgaben aus dem Amtsalltag auf offenen Katasterdaten, ALKIS, der Gemeinde Alpen am Niederrhein. Sonnet aus der Cloud trat gegen Qwen auf einem Notebook an, und das lokale Modell holte in allen gewerteten Läufen Gold.

Die Läufe nutzten das Forschungssystem mit zusätzlichen Fachskills für Geoprocessing und der Geospatial API.

Die beiden Akten zeigen die Ergebnisse im Einzelnen.