Wenn einem KI-Agenten Zugriff auf eine isolierte Umgebung (Sandbox) gewährt wird, stellt sich die grundlegende Frage, wie die Dateien organisiert werden sollen, an denen der Agent arbeiten wird. Die Docker Sandbox-Plattform (als sbx bezeichnet) bietet drei Hauptmodelle zur Verwaltung des Quellcodes, die jeweils einen direkten Einfluss auf den Arbeitsablauf des Entwicklers und dessen Interaktion mit dem Agenten haben.
1. Direkte Einbindung (Shared Mounts)
Diese Option ermöglicht es, den aktuellen ArbeitsPfad direkt vom Host-Gerät aus mit der isolierten Umgebung zu teilen. Beim Ausführen von sbx run aus dem Projektordner heraus wird der Ordner unter demselben absoluten Pfad innerhalb der Umgebung eingebunden. Dieses Modell ist ideal für die enge Zusammenarbeit bei einer einzelnen Aufgabe, da der Entwickler Änderungen sofort in seinem lokalen Editor sehen kann und lokale Entwicklungsserver Aktualisierungen über die Hot-Reload-Funktion erfassen können.
Warnung: Vorsicht ist geboten bei Abhängigkeitskonflikten; Pakete mit nativen Binärdateien funktionieren möglicherweise in der isolierten Linux-Umgebung, schlagen aber unter macOS oder Windows fehl. Daher wird empfohlen, die Laufzeitumgebung zu vereinheitlichen oder die Installation von Abhängigkeiten zu trennen.
2. Verwendung von Git-Arbeitsbäumen (Git Worktrees)
Diese Option eignet sich für die gleichzeitige Ausführung mehrerer Aufgaben. Sie weist jeder Aufgabe einen eigenen Ordner und Branch zu, wodurch jeder Arbeitsbaum in einer separaten isolierten Umgebung eingebunden werden kann. Der Vorteil liegt hier in der vollständigen Isolierung der Aufgaben, jedoch besteht weiterhin eine technische Einschränkung: Die .git-Datei verweist auf Metadaten außerhalb des Einbindungsbereichs, was bedeutet, dass Operationen wie Statusprüfungen (git status) oder das Wechseln zwischen Branches vom Host-Gerät aus durchgeführt werden müssen.
3. Klon-Modus (Clone Mode)
In diesem Modus erstellt das Tool sbx eine unabhängige Kopie des Codes innerhalb der isolierten Umgebung, während der Host-Code als schreibgeschützt eingebunden wird. Dies gibt dem Agenten vollen Zugriff auf Git innerhalb der Umgebung, wodurch er bei der Verwaltung von Branches und Commits völlig unabhängig ist. Nach Abschluss der Arbeit kann der Entwickler die Änderungen über ein Remote-Git-Repository abrufen.
Was ändert dies am Arbeitsablauf des Entwicklers?
Die Wahl der richtigen Methode hängt von der Art der Aufgabe und dem gewünschten Grad an direktem Eingreifen ab:
- Enge Zusammenarbeit: Verwenden Sie die direkte Einbindung, wenn Sie die Arbeit des Agenten Schritt für Schritt überwachen möchten.
- Unabhängigkeit: Verwenden Sie den Klon-Modus oder vollständig isolierte Umgebungen (Mountless), wenn Sie dem Agenten Freiraum bei der Aufgabenverwaltung geben möchten, ohne Ihre lokale Arbeitsumgebung zu beeinträchtigen.
- Verwaltung mehrerer Projekte: Workspace-Manager können verwendet werden, um mehrere Repositories in einer einzigen Umgebung zu bündeln, was es dem Agenten erleichtert, mit zusammenhängenden Projekten (wie Frontend und Backend) zu arbeiten.
Denken Sie daran, dass isolierte Umgebungen, die nicht auf die Einbindung von Host-Dateien basieren (Mountless), eine manuelle Verwaltung von Ports erfordern, um von Ihrem lokalen Browser aus auf Entwicklungsserver zuzugreifen. Dies ist eine Praxis, die die Sicherheit der Isolierung erhöht, aber einige zusätzliche Einrichtungsschritte erfordert.