Wo ein Agent arbeitet: Sandbox, Arbeitsplatz und Server

Ein Agent, der Code schreibt, muss ihn auch ausführen können. Er braucht eine Shell, ein Dateisystem, eine Programmiersprache, manchmal eine Datenbank zum Testen. Er braucht also einen Computer.

Diesen Computer gibt Covey ihm — als abgeschottete Umgebung, die wir Sandbox nennen. Wie sie aufgebaut ist, entscheidet darüber, was der Agent kann und was er nicht kann. Dieser Beitrag beschreibt sie.

Zwei Ebenen, absichtlich getrennt

Covey besteht aus zwei Teilen mit sehr unterschiedlichen Eigenschaften.

Die Control Plane ist die Steuerung. Sie weiß, welche Agenten es gibt, was sie dürfen, welche Aufgaben anliegen und was bisher passiert ist. Sie hält den gesamten Zustand, sie ist immer erreichbar, und sie ist der einzige Ort mit Zugriff auf die Datenbank. Technisch ist sie ein einzelnes Go-Programm neben einer Postgres-Datenbank.

Die Data Plane ist die Arbeitsebene: die Sandboxen, in denen die Agenten tatsächlich arbeiten. Sie ist bewusst dumm gehalten. Sie enthält nichts, was nicht woanders auch steht.

Diese Trennung ist der Grund, warum eine verlorene Sandbox kein Problem ist. Fällt sie aus, wird sie aus zwei Zutaten neu gebaut: aus der versionierten Konfiguration des Agenten und aus seinem Home-Verzeichnis. Nichts geht verloren, weil in der Sandbox nichts liegt, was nur dort liegt.

Was einen Neustart übersteht

In der Sandbox gibt es genau einen Ort, der bleibt: das Home-Verzeichnis des Agenten. Dort liegen seine ausgecheckten Projekte, seine Notizen, seine Zwischenstände.

Alles andere ist kurzlebig. Die Sandbox selbst wird aufgebaut, wenn der Agent zu arbeiten beginnt, und wieder abgeräumt, wenn er fertig ist. Ein Agent, der nichts zu tun hat, verbraucht keine Rechenleistung.

Das Home-Verzeichnis ist außerdem von außen begehbar. Man kann hineinsehen, Dateien herunterladen, welche hochladen, verschieben und löschen — und man sieht, was den Platz belegt. Das klingt banal, ist aber der Unterschied zwischen einem nachvollziehbaren und einem undurchsichtigen System. Ein volles Home-Verzeichnis fällt sonst erst auf, wenn ein Lauf daran scheitert.

Der Arbeitsplatz: mehr als ein Image

Womit die Sandbox ausgestattet ist, beschreibt der Arbeitsplatz. Er besteht aus einem Container-Image — also der Grundausstattung an Werkzeugen und Programmiersprachen — und den Diensten, die daneben laufen sollen.

Der zweite Teil ist der interessantere. Braucht ein Projekt eine Datenbank, um seine Tests laufen zu lassen, läuft diese Datenbank als eigener Container neben der Sandbox und ist von dort unter ihrem Namen erreichbar. Der Agent installiert und betreibt sie nicht selbst.

Das ist eine bewusste Entscheidung. Ein Agent, der sich seine Testdatenbank selbst einrichtet, macht das bei jedem Aufbau der Sandbox neu, jedes Mal ein bisschen anders, und niemand kann hinterher sagen, wogegen eigentlich getestet wurde. Steht die Datenbank im Arbeitsplatz, ist sie Konfiguration: versioniert, überprüfbar und für alle Agenten mit demselben Arbeitsplatz identisch.

Fehlt einem Agenten trotzdem ein Paket, baut er sich keine Notlösung in sein Home-Verzeichnis. Er stellt einen Antrag, und ein Mensch entscheidet darüber. Was gefehlt hat und wer es genehmigt hat, bleibt danach nachlesbar.

Wohin die Sandbox sprechen darf

Der Netzwerkausgang der Sandbox ist kontrolliert. Welche Adressen ein Agent erreichen darf, legt die Plattform fest — nicht der Agent und nicht sein Prompt.

Das ist mehr als eine Vorsichtsmaßnahme. Ein Agent, der beliebige Adressen erreichen kann, kann Daten aus seinem Arbeitsverzeichnis überallhin senden, und niemand würde es bemerken. Eine Freigabeliste macht aus dieser Frage eine Entscheidung, die jemand getroffen hat und die man nachlesen kann.

Server, die nicht unsere sind

Anfangs liefen alle Sandboxen auf derselben Maschine wie die Control Plane. Für eine kleine Installation ist das genau richtig, und es ist bis heute die Voreinstellung: Covey bringt einen eingebauten Server für die Data Plane mit, und wer nichts weiter einrichtet, bekommt ihn.

Wer mehr Kapazität braucht oder aus anderen Gründen trennen will, registriert weitere Server — bei uns heißen sie Runner. Wer GitLab kennt, kennt das Prinzip: Der Server meldet sich an, bekommt ein Token und nimmt von da an Arbeit entgegen.

Zwei Eigenschaften sind uns dabei wichtig.

Ein Runner hat keinen Zugriff auf die Datenbank. Er bekommt Aufträge über dasselbe Protokoll, das auch der eingebaute Server spricht, und sonst nichts. Ein zusätzlicher Server erweitert also die Rechenleistung, nicht die Angriffsfläche der Daten.

Runner werden nach Merkmalen ausgewählt. Man versieht sie mit Bezeichnungen — etwa dafür, dass sie in einem bestimmten Netz stehen oder besonders viel Arbeitsspeicher haben — und ein Agent, der so etwas braucht, landet dort.

Für Wartung lässt sich ein Server pausieren. Er bleibt eingetragen, Zugangsdaten und Arbeitskopien bleiben erhalten, laufende Arbeit wird fertig, und er nimmt nur nichts Neues mehr an. Aufheben lässt sich die Pause ohne Neustart. Ein Server, den man für ein Update herausnehmen will, muss deshalb nicht abgebaut und wieder aufgebaut werden.

Warum dieser Aufbau

Alles daran folgt aus einer Annahme: Die Arbeitsumgebung eines Agenten ist der Ort, an dem er Fehler macht. Dort führt er fremden Code aus, dort probiert er Dinge aus, dort geht etwas kaputt.

Deshalb liegt dort nichts, was nicht ersetzbar wäre. Keine dauerhaften Zugangsdaten, kein Zustand, den nur diese eine Umgebung kennt, kein unkontrollierter Netzwerkzugang. Was zählt, liegt in der Control Plane, und die Sandbox ist ein Werkzeug, das man wegwerfen und neu bauen kann.