Die Abwicklung von Apps Script-Aufgaben auf einer von Gemini verwalteten Linux-Sandbox.

Warum Apps Script mit einer Linux-Sandbox kombinieren?

Google Apps Script ist eine praktische Möglichkeit, Google Workspace zu automatisieren, doch es handelt sich um eine leichte, eingeschränkte serverlose Ausführumgebung ohne Zugriff auf die Betriebssystemebene. Dadurch sind viele anspruchsvollere Aufgaben nicht möglich. Die Kontrolle über Netzwerk und Protokolle auf niedriger Ebene ist begrenzt. Es gibt keinen headless-Browser zur Darstellung dynamischer Seiten, keine Möglichkeit, native Binärdateien für die Medienumwandlung oder Signalverarbeitung auszuführen, keine modernen Compiler oder Build-Toolchains, und es gelten strenge Quoten für Laufzeit und Payload-Größe.

Gemini Managed Agents bieten eine Lösung für dieses Problem. Als Teil der Gemini v1beta Interactions and Environments API ermöglichen sie Entwicklern, entfernte Linux-Sandboxes bereitzustellen, die eigenständig Code ausführen, Shell-Befehle ausführen und Pakete verwalten können. Die Kombination dieser Sandboxes mit der Google Workspace CLI hat bereits das Interesse der Community geweckt.

Die hier beschriebene Architektur verbindet diese beiden Komponenten miteinander. Apps Script steuert einen persistenten Linux-Container mit 4 vCPUs und 16 GB RAM sowie Python 3.12, Node.js 22 und den üblichen Paketverwaltern (apt, npm, pip). Der Container streamt die generierten Dateien direkt in Google Drive mithilfe des ggsrun-Befehlszeilenwerkzeugs. Da die Dateien niemals über die API-Antwort zurückgesendet werden, umgeht dieses Design die Payload-Beschränkungen sowie den Token-Overhead und ermöglicht eine hocheffiziente Cloud-Automatisierung.

Das Problem bei der Rückgabe von Binärdateien als Base64

Nehmen wir an, der Sandbox erzeugt etwas Großes, wie hochauflösende Screenshote, Audiosignale oder eine zusammengepackte JavaScript-Datei, und diese muss in Drive gespeichert werden. Der offensichtliche Weg besteht darin, die Rohdaten als Base64-String in der Gemini-API-Antwort zurückzugeben und sie in Apps Script zu decodieren. Dieser Ansatz stößt jedoch sofort auf mehrere Hindernisse.

• UrlFetchApp in Apps Script setzt eine Obergrenze von 50 MB für die Antwortinhalte.
• Die Codeausführungsumgebung in der Interactions-API beschränkt den stdout-Puffer, sodass ein mehrere Megabyte großer Base64-String mitten im Stream abgeschnitten werden kann.
• Managed Agents haben eine Quotenbegrenzung von 200.000 Tokens pro Minute. Base64 vergrößert die Größe von Binärdaten um etwa ein Drittel, und in mehrstufigen Sitzungen häufen sich die früheren Base64-Strings im Gesprächsverlauf an, bis die Eingabekontingente aufgebraucht sind und sofort 429 Quota Exceeded-Fehler auftreten.

Die Dekodierung großer Base64-Strings sowie die Erstellung von Drive-Blobs in Apps Script verbrauchen Ausführungszeit und Speicher des Skripts.

Das nächste Diagramm zeigt den Unterschied zwischen diesem Ansatz und dem direkten Streaming.

Der bessere Ansatz besteht darin, das auf Go basierende Tool ggsrun direkt innerhalb des Sandboxes auszuführen, wobei ein OAuth-Zugriffstoken zur Laufzeit über ScriptApp.getOAuthToken() eingegeben wird. Der Sandbox überträgt anschließend die binären Dateien über Google Clouds internes Netzwerk mit Geschwindigkeiten von über 2 MB/s nach Drive – dadurch werden die Speicherkapazitäten von Apps Script, die Limits bezüglich der Antwortgröße sowie das Auslaufen der Token-Quoten auf einen Schlag umgangen.

Streaming funktioniert in beide Richtungen

Der direkte Cloud-zu-Cloud-Transfer hilft auch bei Downloads. Wenn große externe Datensätze wie hochauflösende Bilder, Audio- und Videodateien, mehrere Gigabyte große CSV- oder JSON-Dateien oder Machine-Learning-Modelle in den Sandbox gelangen müssen, führt das Einbetten dieser Dateien in einen Prompt als Base64 oder serialisierter Text dazu, dass die Eingabetoken-Quoten fast sofort aufgebraucht werden und schließlich ein 429-Fehler auftritt. Mit ggsrun lädt der Sandbox die Datei direkt aus dem Drive herunter, und der Prompt benötigt lediglich eine kurze Anweisung wie „Lade das Ziel-Datensatz aus dem Drive herunter und analysiere es.“ Dadurch sinkt der Verbrauch an Eingabetoken nahezu auf Null, was ein Ausschöpfen der Rate-Limits verhindert.

Das Teilen eines persistenten Sandboxes verringert die Kosten weiter. Ein einziger Bereitstellungs Schritt erzeugt eine environmentId, die von Apps Script-Projekten, lokalen Node.js-Workstations, Python-Skripten sowie CI/CD-Pipelines genutzt werden kann. Datensätze, Korpora, Bibliotheken oder vorge trainierte Modelle, die unter /workspace/ abgelegt sind, stehen somit jedem Kunden zur Verfügung, sodass niemand Daten erneut hochladen oder bei jedem Vorgang die Einrichtung wiederholen muss. Dadurch wird die Latenz, die Netzwerkbandbreite sowie die gesamte API-Overhead reduziert, und Aufgaben können gemeinsam genutzte Arbeitsdateien sowie vorinstallierte Pakete wiederverwenden.

Das folgende Diagramm zeigt die gesamte Architektur, bei der Apps Script und lokale Node.js-Workstations denselben persistenten Sandbox über eine gemeinsame environmentId orchestrieren und dabei zweistufiges Streaming sowie gemeinsame Datensätze zur schnellen Inhaltsgenerierung nutzen.

Es ist in vier Teile unterteilt:

• Mehrere Clients steuern einen Container. Cloud-basierte Apps Script verwenden einen synchronen Auslöser sowie ein dynamisches OAuth-Token, während lokale Node.js-Workstations Echtzeit-SSE-Streaming sowie gcloud-Authentifizierung nutzen.
• Der Sandbox speichert gemeinsam genutzte Datensätze sowie Build-Tools wie Playwright, FFmpeg und esbuild, sodass Inhalte ohne erneutes Hochladen von Daten erstellt werden können.
• ggsrun download streamt große Datensätze aus Drive in den Sandbox, wodurch ein sofortiges Einbetten von Daten vermieden wird und die 200k TPM-Quoten eingehalten bleiben.
• ggsrun upload überträgt fertige Binärdateien mit einer Geschwindigkeit von 2 MB/s oder mehr nach Drive, wodurch die 50 MB große Payload-Limit sowie das Trunkieren von Standardausgabe umgangen werden.

Die vollständige Quelle (die Apps Script-Klassen, die Node.js-Stream-Klienten, die Testsuite sowie die Rohausführungsprotokolle) befindet sich im öffentlichen GitHub-Repository des Projekts.

Einrichtung

Zuerst generieren Sie einen API-Schlüssel in Google AI Studio. Er authentifiziert Anfragen an die Gemini v1beta Interactions- und Environments-APIs. Anschließend erstellen Sie ein Apps Script-Projekt auf eine von zwei Arten: entweder ein eigenständiges Projekt über script.google.com unter „Neues Projekt“ oder ein in einem Container gebundenes Projekt, indem Sie eine Tabelle, ein Dokument oder ein Formular öffnen, auf „Erweiterungen“ klicken und anschließend „Apps Script“ wählen.

Kopieren Sie zwei Dateien aus dem Repository in den Editor:

• ManagedAgentSandboxClient.js ist die zentrale Client-Klasse. Sie verwaltet den Lebenszyklus des Sandboxes sowie dynamische Umgebungsvariablen, speichert Sitzungsdaten in PropertiesService und wendet bei einem Fehlercode 429 einen sinnvollen Wartezeitmechanismus an.
• tests.js ist die Haupt-Testsuite. Sie umfasst Tests zur Bereitstellung des Sandboxes, Überprüfungen der Tools, Verarbeitung von Medieninhalten, Webscraping sowie Leistungsvergleiche.

Öffnen Sie anschließend die Projekteinstellungen, dann die Skripteigenschaften, und fügen Sie eine Eigenschaft mit dem Namen GEMINI_API_KEY hinzu, in der der Schlüssel gespeichert wird. Stellen Sie schließlich sicher, dass das Manifest (appsscript.json) die richtigen OAuth-Berechtigungen enthält. Der Berechtigungsrahmen https://www.googleapis.com/auth/script.external_request ist für Aufrufe von UrlFetchApp erforderlich, während https://www.googleapis.com/auth/drive das Erstellen von Zielordnern sowie das Hochladen von Dateien ermöglicht. Code, der bereits vorhandene Ordner ohne DriveApp.createFolder() verwendet, kann mit https://www.googleapis.com/auth/drive.file auskommen. Die Ausführungslogbücher für jeden Test finden Sie in gas-src/execution-logs.md des Repositoriums.

Vorbereitung des gemeinsamen Sandboxes

Durch Ausführung von provisionSharedSandbox() wird ein neuer entfernter Linux-Container gestartet, die CLI-Tools sowie Abhängigkeiten installiert, die Ziel-Drive-Pfade konfiguriert und die resultierende environmentId in PropertiesService gespeichert.

Die Infografik zeigt vier Schritte. Zunächst erhält Drive ein Zielverzeichnis mit dem Namen ManagedAgent_Artifacts_YYYYMMDD. Anschließend startet der Container mit 4 vCPU und 16 GB über eine Initialisierungsanfrage ggsrun, ffmpeg, sox, jq, typescript, esbuild sowie Playwright mit Chromium. Danach überprüft das Sandbox-System die installierten Binärdateien und gibt READY an. Schließlich wird die eindeutige environmentId unter SHARED_SANDBOX_SESSION gespeichert, damit spätere Tests und andere Clients sie wiederverwenden können. Durch Aufruf von testListSandboxes() wird anschließend die Environments-API abgefragt, um zu bestätigen, dass das Sandbox-System aktiv ist, und seine Metadaten werden zurückgegeben.

Test 1: benutzerdefinierte Header, die von Apps Script überschrieben werden

Der erste Test zeigt etwas, was UrlFetchApp nicht kann. Apps Script ersetzt automatisch einen benutzerdefinierten User-Agent-Header durch Google’s Proxy-Identitätszeichenkette, während der Sandbox jeden von Ihnen festgelegten Header beibehält, da er Anfragen über rohe POSIX-Sockets sowie natives curl sendet.

Das Diagramm zeigt eine Anfrage mit User-Agent: sample user agent an httpbin.org/anything. Auf der Apps Script-Seite ändert die Plattform-Proxy-Richtlinie den Header. Auf der Sandbox-Seite behält curl den ursprünglichen String bei. Anschließend vergleicht ein eingebettetes Python-Skript die reflektierten JSON-Daten und gibt eine Überprüfungsmatrix aus. Konkret sendet Apps Script eine GET-Anfrage mit dem benutzerdefinierten Header, die Sandbox sendet dieselbe curl-Anfrage, und der Vergleich bestätigt, dass Apps Script Mozilla/5.0 (compatible; Google-Apps-Script; beanserver; ...) eingefügt hat, während die Sandbox sample user agent exakt beibehalten hat.

Test 2: Authentifizierung bei Drive von innerhalb der Sandbox

Diese Test überprüft die Authentifizierung bei Drive sowie den direkten Zugriff über ggsrun, indem ein frischer OAuth-Token aus ScriptApp.getOAuthToken() in die Ausführung dieser Testrunde eingefügt wird.

In Schritt eins extrahiert Apps Script das Token und injiziert es als Umgebungsvariable GGSRUN_AT, wodurch das Risiko eines Ablaufs des einstündigen Tokens beseitigt wird. In Schritt zwei generiert der Sandbox eine Verifizierungsdatei mit dem Namen 00_ggsrun_verification.txt unter /workspace/test2/ und lädt sie mit ggsrun upload im nicht-blockierenden Überschreibungsmodus (--nc --cm OverwriteIfNewer -j) hoch. In Schritt drei durchsucht ggsrun searchfiles den Zielordner und gibt strukturierte Metadaten zurück, die die Existenz aller neun Dateien bestätigen. Der gesamte Zyklus aus Erstellen, Hochladen und Verifizieren dauerte 12,1 Sekunden, und kein sensibles Token blieb über verschiedene Sitzungen hinweg bestehen.

Test 3: headloses Scraping mit Playwright

Anschließend führt eine automatisierte, headlose Chromium-Sitzung im Sandbox-Umfeld das Scraping von dynamischem, durch JavaScript gerendertem Inhalt durch und erstellt Screenshots in verschiedenen Ansichtsgrößen.

Ein Node.js Playwright-Skript öffnet eine mit JavaScript gerenderte Zitate-Website (quotes.toscrape.com/js/), erstellt Vollseiten-Screenshots in Desktop-Größe (1280x800) sowie in iPhone-Emulation (375x812), klickt anschließend auf die Seitenleiste, nimmt einen Desktop-Screenshot der zweiten Seite auf und extrahiert die Zitate in 02_Page2_Quotes.json. Die Größen lagen bei etwa 92,5 KB für den Desktop-Screenshot, 51,6 KB für das Mobilformat und 171,9 KB für die zweite Seite, plus 4,1 KB für die JSON-Datei – insgesamt also rund 320 KB für die vier Dateien. Ein einziger ggsrun upload-Befehl übertrug alle drei PNG-Dateien sowie das JSON-Datensatz ohne jegliche Base64-Konvertierung in Drive, und die gesamte Ausführung dauerte 20,4 Sekunden. Das ist eine Client-Seite-Rendierung, die Apps Script nicht nativ verarbeiten kann.

Test 4: Audio-Synthese mit FFmpeg und SoX

Der vierte Test führt natives digitales Signalverarbeitung in der Sandbox durch und erstellt mit FFmpeg und SoX einen Mehrtonakkord.

Drei Sinuswellengeneratoren bei 440 Hz (A4), 554,37 Hz (C#5) und 659,25 Hz (E5) werden über den ffmpeg amix-Filter zu einem drei Sekunden langen Major-Akkord-MP3 mit 73,4 KB gemischt. ffprobe extrahiert anschließend Metadaten des Streams in 03_Audio_Analysis.json, das 1,8 KB groß ist. ggsrun upload übertrug 03_Chord_Major.mp3 sowie die JSON-Datei direkt in Drive. Die Synthese, die Extraktion der Metadaten und das Hochladen dauerten insgesamt 9,1 Sekunden.

Test 5: TypeScript-Parsing und esbuild-Bündelung

Bei diesem Test wird gezeigt, wie moderne JavaScript- und TypeScript-Build-Tools in der Sandbox funktionieren.

Zwei Toolchains arbeiten an einem TypeScript-Modul, matrix.ts, das generische Klassen und Schnittstellen definiert und sich in /workspace/test5/ befindet. Im ersten Zweig verwendet ein Node.js-Skript die offizielle TypeScript Compiler API, um den abstrakten Syntaxbaum zu analysieren und die Schemata von Schnittstellen sowie Methoden in 04_TypeScript_AST.json zu exportieren – dieser Dateiinhalt umfasst lediglich 152 Bytes. Im zweiten Fall packt esbuild das Modul zusammen und komprimiert es zu einer eigenständigen IIFE-Datei, 04_Matrix_Bundle.iife.js, mit einer Größe von 1,2 KB; die Kompilierzeit beträgt dabei nur 13 Millisekunden. Anschließend sendet ggsrun upload beide Ergebnisse an Drive, wobei die gesamte Ausführung 10,0 Sekunden in Anspruch nahm.

Test 6: Direkter Upload über Base64 mittels Apps Script

Der Benchmark überträgt eine 10.000-Byte große Binärdatei aus dem Sandbox in Drive mithilfe zweier unterschiedlicher Methoden.

In Ansatz A erstellt das Sandbox-Umfeld ein 10 KB großes Binärdatei aus /dev/urandom und streamt sie mit ggsrun in einer einzigen Interaktionsrunde (freshInteraction: true) an Drive. In Ansatz B kodiert das Sandbox-Umfeld dieselben Bytes im Base64-Format und gibt sie im API-Antworttext zurück; Apps Script dekodiert anschließend die Zeichenkette und speichert die Datei in Drive. Ansatz A war in 16,20 Sekunden bei einer Geschwindigkeit von 0,60 KB/s abgeschlossen und verbrauchte keine CPU-Ressourcen von Apps Script. Ansatz B benötigte 32,13 Sekunden bei einer Geschwindigkeit von 0,30 KB/s sowie zusätzlich 1,23 Sekunden CPU-Zeit für Apps Script – somit war Ansatz A 1,98 Mal schneller. Zudem wird so die etwa 33-prozentige Vergrößerung durch Base64 sowie das Problem des Token-Ausfalls bei mehrstufigen Sitzungen vermieden. Der aufgezeichnete Bericht sieht wie folgt aus.

================================================================================
PERFORMANCE BENCHMARK REPORT: 10,000 BYTES FILE TRANSFER TO GOOGLE DRIVE
================================================================================
| Metric                       | Approach A: Direct ggsrun Upload | Approach B: Base64 via Gemini API -> GAS |
| :--------------------------- | :------------------------------- | :--------------------------------------- |
| Transfer Method              | Direct Sandbox-to-Drive (Go CLI) | Base64 Stream -> GAS -> Drive            |
| Drive File Name              | benchmark_10kb_ggsrun.bin        | benchmark_10kb_gas.bin                   |
| Verified File Size           | 10,000 bytes (9.77 KB)           | 10,000 bytes (9.77 KB)                   |
| API Turns Required           | 1 Turn (Direct Offload)          | 1 Turn (Base64 Retrieval)                |
| Local GAS Processing Time    | 0.00 s (Zero CPU overhead)       | 1.23 s (Base64 Decode & Blob Creation)   |
| Total End-to-End Duration    | 16.20 s                          | 32.13 s                                  |
| Effective Throughput         | 0.60 KB/s                        | 0.30 KB/s                                |
| Performance Multiplier       | 1.98x FASTER                     | Baseline (Higher Latency & Token Usage)  |
================================================================================

Das Streaming über ggsrun war 1,98 Mal schneller, beseitigte alle CPU- und Speicherkosten von Apps Script durch Dekodierung und verbrauchte keinen Teil der Konversations-Token-Quoten. Bei mehrere Megabyte großen Datenmengen verhindert dieser direkte Weg Fehler vom Typ 429 Quota Exceeded.

Steuerung derselben Sandbox von einer lokalen Arbeitsstation aus

Um zu zeigen, dass dieselbe persistente Linux-Sandbox sowohl von Apps Script als auch von einem Laptop gesteuert werden kann, wurde mithilfe des @google/genai SDK ein Node.js-Client mit Server-Sent Events-Streaming entwickelt. Apps Script läuft synchron und blockierend und sammelt Agentenevents am Ende der HTTP-Anfrage ein, wodurch der lokale Ausführer Entwicklern Funktionen bietet, die Apps Script nicht bieten kann.

• Echtzeit-Überblick über den Ablauf. Die Denkschritte (thought), Shell-Befehle (code_execution_call), Standard- und Fehlerausgaben der Sandbox (code_execution_result) sowie der Modelltext (model_output) werden in Echtzeit mit ANSI-Farben in die Konsole übertragen.
• Ein hybrider Arbeitsablauf für die Entwicklung. Anfragen und Toolchains können lokal mit Echtzeit-Feedback prototypiert, debuggt und optimiert werden, bevor sie in automatisierte Apps Script-Auslösungen überführt werden, die unüberwacht laufen.
• Einfaches Teilen der Sandbox. Durch das Einfügen des während der Apps Script-Einrichtung generierten Identifikators in ENVIRONMENT_ID in einer lokalen .env-Datei wird der Client mit dem vorhandenen Container verknüpft – inklusive aller installierten Pakete, kompilierten Binärdateien und Arbeitsplatzdateien – ohne Neuinstallation.

Automatische OAuth-Verarbeitung. Der Ausführungsprozess erhält mit gcloud auth print-access-token neue Google-Zugriffstoken und injiziert sie in GGSRUN_AT, sodass Uploads direkt in Drive genauso funktionieren wie in Apps Script, ohne dass man die Zugangsdaten manuell kopieren muss.

Das Ausführen der lokalen Tests umfasst vier Schritte.

1. Klonen Sie das Repository und führen Sie innerhalb von local-node.js-src npm install aus.
2. Erstellen Sie eine Kopie von .env.example als .env und füllen Sie drei Werte ein: Ihre API-Schlüssel als GEMINI_API_KEY, den langfristig gültigen Sandbox-Identifikator als ENVIRONMENT_ID sowie den Drive-Ordner, in den geschrieben werden soll, als TARGET_FOLDER_ID.
3. Führen Sie npm test aus oder einen einzelnen Test mit npm run test:1 bis test:6 und beobachten Sie in Echtzeit, wie der Agent arbeitet.
4. Sobald alles erledigt ist, führen Sie npm run test:teardown aus, um den entfernten Sandbox zu löschen und die Cloud-Ressourcen freizugeben.

Die vollständigen Rohtranskripte zusammen mit den live gestreamten Ausgaben werden im local-node.js-src/execution-logs.md des Repositoriums gespeichert und zeigen dieselben funktionalen Ergebnisse wie die Ausführungen von Apps Script.

API-Muster für Managed Agents

Die unten aufgeführten Muster fassen die gängigen Methoden zur Arbeit mit der Gemini v1beta Interactions- und Environments-API zusammen. Jedes davon sendet eine POST-Anfrage an denselben Basis-Endpunkt.

POST https://generativelanguage.googleapis.com/v1beta/interactions?key=${API_KEY}
Content-Type: application/json

Szenario 1 teilt sich einen einzigen, dauerhaften Sandbox unter vielen Clients. Erstellen Sie die entfernte Umgebung einmal, wobei environment.type auf "remote" gesetzt wird. Behalten Sie die zurückgegebene environment_id bei und senden Sie diese als gewöhnlichen String in späteren Anfragen aus Apps Script, Node.js, Python oder einem CI/CD-Job.

{
  "agent": "antigravity-preview-05-2026",
  "input": "Run task in shared container...",
  "environment": "environments/env-12345"
}

Szenario 2 stellt für jeden Ausführungsvorgang eine isolierte Sandbox bereit. Wenn eine Aufgabe eine völlig neue Linux-Umgebung benötigt, setzen Sie environment.type bei jedem Aufruf auf "remote".

{
  "agent": "antigravity-preview-05-2026",
  "input": "Execute client-specific isolated task...",
  "environment": {
    "type": "remote"
  }
}

Szenario 3 bewahrt den konversationellen Kontext über mehrere Nachrichtenaustausche hinweg. Fügen Sie previous_interaction_id hinzu, wenn der Agent sich an frühere Überlegungen, Variablen oder Befehlsergebnisse erinnern muss.

{
  "agent": "antigravity-preview-05-2026",
  "input": "Based on the previous output, proceed to step 2...",
  "environment": "environments/env-12345",
  "previous_interaction_id": "interaction-prev-67890"
}

Szenario 4 wiederverwendet einen Sandbox mit einem neuen Kontext mithilfe der Option freshInteraction. Geben Sie die vorhandene environment_id an und lassen Sie previous_interaction_id aus. Alle Dateien sowie installierten Tools im Container bleiben erhalten, während die Konversationshistorie auf null Token zurückgesetzt wird, wodurch eine Überlastung der TPM-Grenze vermieden wird.

{
  "agent": "antigravity-preview-05-2026",
  "input": "Execute a completely new task in the existing sandbox...",
  "environment": "environments/env-12345"
}

Vergleich auf einen Blick

Die Zusammenfassungsmatrix stellt die verschiedenen Ansätze nebeneinander dar.

Was das bedeutet

Durch die Kombination von Apps Script mit Gemini Managed Agents werden die üblichen Grenzen eines serverlosen Ausführungsumfelds überschritten. Ein dauerhafter Remote-Sandbox sowie der direkte Stream-Transfer in beide Richtungen zwischen dem Cloud-Speicher und dem Sandbox ermöglichen Arbeitslasten, die Apps Script allein nicht bewältigen kann, und umgeht außerdem die Limits für API-Datenmengen sowie die Quoten für Konversations-Token.

• Die Einschränkungen von Apps Script werden überwunden. Aufgaben, die eine native Linux-Umgebung erfordern – wie das Scraping mit einem headless Browser über Playwright, die Audio-Synthese mit FFmpeg oder die Kompilierung mit TypeScript mittels esbuild – können nun von Apps Script aus gestartet werden.
• KI-Logik trifft auf Linux-Ausführung. Anstatt feste externe Befehle auszuführen, wird Geminis Logik mit einer echten Shell kombiniert, sodass Befehle dynamisch zusammengestellt werden, der Code zur Laufzeit ausgeführt wird und das Agent sich in komplexen Workflows selbst korrigieren kann.
• Doppelrichtungs-Streaming spart Tokens und Datenmengen. Das Hochladen von Artefakten sowie das Herunterladen großer Eingabedatenmengen aus Drive in den Sandbox vermeidet das Hineinpacken von Daten in Prompts sowie die Base64-Konvertierung, wodurch die Anzahl der Eingangs- und Ausgangstokens gering bleibt und die Grenzen von 50 MB sowie der Quotenlimit von 200.000 TPM eingehalten werden.
• Gemeinsame Sandboxes senken die Kosten. Das Speichern gemeinsamer Datensätze und Tools in einem gemeinsamen Container-Dateisystem eliminiert wiederholte Uploads und Einrichtungen für jede Aufgabe, wodurch Latenzzeiten und Bandbreitenverbrauch reduziert werden.
• Die Benchmark-Ergebnisse bestätigen dies. Das direkte Cloud-zu-Cloud-CLI-Streaming war 1,98 Mal schneller als das Abrufen von Base64 über die API, ohne CPU-Decodierungskosten und ohne Nutzung lokaler Speicher in Apps Script.