TaskGoblin ist ein Cloud-Agent, und damit hat die wichtigste Frage überhaupt — wo läuft mein Code? — nur eine Antwort: in einer isolierten Cloud-Sandbox, niemals auf jemandes Laptop. Diese Seite erklärt, was diese Sandbox ist, warum sie isoliert ist und wie sie es bleibt, während Ihr Team wächst.
Was die Sandbox ist
Eine Sandbox ist ein isolierter Container in der Cloud mit einem Checkout Ihres Repositories. Wenn Sie eine Aufgabe übergeben, läuft der Agent innerhalb dieses Containers — er liest und bearbeitet dort Dateien, führt Befehle aus und untersucht das Repository, ohne Zugriff auf Ihren Rechner und ohne darauf angewiesen zu sein, dass dieser eingeschaltet ist.
Weil die Sandbox in der Cloud lebt, ist die Arbeit von Natur aus asynchron: Sie weisen eine Aufgabe zu und gehen, und der Agent arbeitet weiter — ob Sie zusehen oder nicht.
Isolation: eine Grenze pro Organisation
Die Arbeit jeder Organisation läuft in ihrer eigenen Sandbox. Diese Grenze ist der Kern der Datenisolation von TaskGoblin — eine Organisation kann niemals Code, Repositories oder Laufhistorie einer anderen lesen oder schreiben. Der Agent sieht immer nur die Workspaces, Repositories und Projekte, die Sie ausdrücklich verbinden; trennen Sie eine Verbindung, verliert er den Zugriff auf der Stelle.
Persistenz: er merkt sich die Umgebung, nicht nur die Aufgabe
Die Sandbox ist persistent und wird über die Nachrichten eines Threads hinweg wiederverwendet. Eine Rückfrage zum selben Issue landet in einer Umgebung, in der das Repository bereits geklont ist und der Zustand des vorherigen Durchlaufs vorliegt — der Agent macht also schnell weiter, statt jedes Mal bei einer leeren Kiste anzufangen. Genau das lässt das Iterieren an einer Aufgabe zusammenhängend statt repetitiv wirken. (Wie diese Kontinuität Entscheidungen über Durchläufe hinweg trägt, lesen Sie unter So funktioniert der Agent zu Threads und Übergabe-Gedächtnis.)
Geheimnisse bleiben außerhalb des Agenten
Der Agent sieht Ihre Zugangsdaten nie. Der Git-Zugriff in der Sandbox wird zur Laufzeit pro Organisation bereitgestellt — ein GitLab-OAuth-Token oder ein frisch ausgestelltes GitHub-Installations-Token — und in die Umgebung um den Agenten herum eingespeist, statt ihm als Lesestoff übergeben zu werden. Der Agent kann den Zugriff, den er zum Klonen und Pushen braucht, nutzen, ohne dass Ihre Geheimnisse je in sein Protokoll oder seinen Kontext gelangen.
Das ist eine bewusst gezogene Grenze, kein Nebeneffekt: Die Zugangsdaten stehen dem Git-Werkzeug in der Sandbox zur Verfügung, sind aber nie Teil des Materials, das der Agent liest oder über das er nachdenkt.
Eigene Sandboxes
In den Team-Plänen können Sie eine eigene Sandbox mitbringen — ein Container-Image, in dem Toolchain, Systempakete und Dienste vorinstalliert sind, die Ihr Projekt zum Bauen und Testen braucht. Wenn die Arbeit des Agenten mehr als einen nackten Checkout voraussetzt (eine bestimmte Laufzeitumgebung, eine Datenbank, internes Build-Werkzeug), bedeutet eine eigene Sandbox, dass die Umgebung im Moment des Aufgabenstarts bereitsteht und die Änderungen des Agenten in einem realistischen Aufbau überprüft werden können.
Selbst gehostete Sandboxes
Teams mit Compliance- oder Datenresidenz-Anforderungen können Sandboxes auf eigener Infrastruktur betreiben. Die Control Plane plant und steuert die Arbeit weiterhin, aber der Container, in dem Ihr Code ausgecheckt und ausgeführt wird, liegt in Ihrer Umgebung — Quellcode, Build-Artefakte und Laufzustand verlassen also nie eine Grenze, die Sie kontrollieren. Das ist die Option, wenn „in der Cloud" Ihre Cloud bedeuten muss.
Wie es weitergeht
- So funktioniert der Agent — der komplette Weg vom Auslöser zum Merge Request, Threads und Übergabe-Gedächtnis.
- Weisen Sie dem Agenten Arbeit zu — jede Möglichkeit, einen Durchlauf zu starten, und wie parallele Arbeit eine Sandbox pro Aufgabe nutzt.
- Loops — wiederkehrende Durchläufe, die dasselbe Sandbox-Modell im Takt nutzen.