google-apps-script gemini linux-sandbox google-drive agents automation

Przenoszenie obciążeń Apps Script do przestrzeni sandbox Linux zarządzanej przez Gemini Managed Agent

Google Apps Script sterujący sandboxem Linux dla zarządzanego agenta Gemini: przesyłanie plików do Drive za pomocą ggsrun, omijanie ograniczenia 50 MB, uruchamianie Playwright, FFmpeg i esbuild.

Wydawca: REACTAPP.TOPDodane na tej stronie 28 paź 202613 min czytania2934 słów

Źródła: Taking Advantage of Gemini Managed Agents with Google Apps Script

Dlaczego łączyć Apps Script z sandboxem Linux?

Google Apps Script to wygodny sposób na automatyzację Google Workspace, jednak jest to lekki, ograniczony środowisko bez serwera bez dostępu na poziomie systemu operacyjnego. To wyklucza wiele zadań wymagających większych zasobów. Kontrola sieci i protokołów na niskim poziomie jest ograniczona. Brakuje bezobsługowego przeglądarki do renderowania stron dynamicznych, nie ma możliwości uruchamiania binarnych plików do transkodowania mediów lub przetwarzania sygnałów, brakuje nowoczesnych kompilatorów czy narzędzi do budowania oprogramowania, a także obowiązują ścisłe limity czasu działania i wielkości danych przekazywanych.

Gemini Managed Agents oferują rozwiązanie tego problemu. Będąc częścią API Gemini v1beta Interactions and Environments, umożliwiają programistom tworzenie zdalnych sandboxów Linux, które mogą samodzielnie wykonywać kod, uruchamiać polecenia w terminalu i zarządzać pakietami. Połączenie ich z interfejsem CLI Google Workspace już wzbudziło zainteresowanie społeczności.

Opisana tutaj architektura łączy te dwa elementy. Apps Script zarządza trwałym kontenerem Linux z 4 procesorami wirtualnymi i 16 GB pamięci RAM, a także z Pythonem 3.12, Node.js 22 oraz standardowymi menedżerami pakietów (apt, npm, pip). Kontener przesyła generowane pliki bezpośrednio do Google Drive za pomocą narzędzia linii poleceń ggsrun. Ponieważ pliki nigdy nie przechodzą z powrotem przez odpowiedź API, taka konstrukcja unika ograniczeń dotyczących wielkości danych oraz dodatkowych kosztów związanych z tokenami, umożliwiając wysokowydajną automatyzację w chmurze.

Problem z zwracaniem plików binarnych w formacie Base64

Załóżmy, że środowisko testowe generuje duże pliki, takie jak ekranorysy w wysokiej rozdzielczości, fale dźwiękowe lub spakowany plik JavaScript, które muszą trafić do Drive. Oczywistym rozwiązaniem jest zwrócenie surowych bajtów jako ciągu Base64 w odpowiedzi API Gemini oraz ich dekodowanie w Apps Script. Ten sposób napotyka jednak kilka przeszkód jednocześnie.

UrlFetchApp w Apps Script narzuca limit 50 MB na zawartość odpowiedzi.
Środowisko wykonywania kodu w API Interactions ogranicza bufor stdout, więc wielomegabajtowy ciąg Base64 może zostać przerwany w trakcie przesyłania.
Managed Agents mają limit 200 000 tokenów na minutę. Kod Base64 powiększa rozmiar danych binarnych o około jedną trzecią, a w sesjach wieloetapowych wcześniejsze ciągi Base64 gromadzą się w historii rozmowy, aż wyczerpią się limity wejścia i natychmiast pojawią się błędy 429 Quota Exceeded.
Dekodowanie długich ciągów Base64 oraz tworzenie plików w Drive w Apps Script zużywają czas wykonywania i pamięć skryptu.

Następny diagram porównuje tę metodę z bezpośrednim strumieniowaniem.

Lepszym rozwiązaniem jest uruchomienie narzędzia ggsrun opartego na Go bezpośrednio wewnątrz sandboxu, przy użyciu tokena dostępu OAuth wstrzykiwanego w czasie wykonywania za pomocą ScriptApp.getOAuthToken(). Sandbox następnie przesyła pliki binarne do Drive przez wewnętrzną infrastrukturę Google Cloud z prędkością powyżej 2 MB/s, omijając w ten sposób ograniczenia pamięci Apps Script, limity wielkości odpowiedzi oraz wyczerpanie kwot tokenów.

Strumieniowanie działa w obu kierunkach

Bezpośrednia transmisja z chmury do chmury pomaga również przy pobieraniu plików. Gdy duże zewnętrzne zbiory danych, takie jak obrazy o wysokiej rozdzielczości, pliki audio, wideo, pliki CSV lub JSON o wielkości kilku gigabajtów, czy modele sztucznej inteligencji, muszą trafić do środowiska testowego, umieszczanie ich w instrukcji w formie Base64 lub zserwowanego tekstu niemal natychmiast wyczerpuje limit tokenów wejściowych, co skutkuje błędem 429. Dzięki ggsrun środowisko testowe pobiera plik bezpośrednio z Drive, a instrukcja wymaga jedynie krótkiego polecenia w stylu „pobierz zbiór danych z Drive i przeanalizuj go”. Zużycie tokenów wejściowych spada praktycznie do zera, co zapobiega wyczerpaniu limitów przepustowości.

Dzielenie się jedną trwałą przestrzenią sandbox obniża koszty jeszcze bardziej. Jedno kroku konfiguracji generuje environmentId, który mogą wykorzystywać projekty Apps Script, lokalne stanowiska pracy Node.js, skrypty Python oraz pipeline’y CI/CD. Zbiory danych, korpusy, biblioteki lub modele wstępnie wytrenowane przechowywane pod adresem /workspace/ są dostępne dla każdego klienta, dzięki czemu nikt nie musi ponownie przesyłać danych ani powtarzać konfiguracji przy każdym użyciu. To zmniejsza opóźnienia, przepustowość sieci oraz ogólne obciążenie API, a zadania mogą ponownie wykorzystywać wspólne pliki robocze oraz z góry zainstalowane pakiety.

Poniższy diagram przedstawia pełną architekturę, w której Apps Script i lokalne stanowiska pracy Node.js koordynują tę samą trwałą przestrzeń sandbox za pomocą wspólnego environmentId, wykorzystując dwukierunkowy przepływ danych oraz wspólne zbiory danych do szybkiej generacji treści.

Architektura składa się z czterech części:

Kilku klientów obsługuje jeden kontener. Aplikacje Apps Script oparte na chmurze wykorzystują synchroniczny wyzwalacz oraz dynamiczny token OAuth, natomiast lokalne stacje robocze Node.js korzystają z transmisji w czasie rzeczywistym typu SSE oraz autoryzacji za pomocą gcloud.
Sandbox przechowuje udostępnione zestawy danych oraz narzędzia do budowania, takie jak Playwright, FFmpeg i esbuild, dzięki czemu treść może być generowana bez ponownego przesyłania danych.
ggsrun download przesyła duże zestawy danych z Drive do sandboxu, co pozwala uniknąć natychmiastowego wgrzewania danych i chroni limit 200 tys. TPM.
ggsrun upload wysyła gotowe pliki binarne do Drive z prędkością 2 MB/s lub wyższą, omijając w ten sposób limit 50 MB ładunku oraz problem ścięcia standardowego wyjścia.

Pełny źródłowy kod (klasy Apps Script, klienty strumieniowe Node.js, zestawy testowe oraz surowe logi wykonywania) znajduje się w publicznym repozytorium projektu na GitHubie.

Ustawianie

Najpierw utwórz klucz API w Google AI Studio. Służy on do autoryzacji żądań skierowanych do API Gemini v1beta Interactions and Environments. Następnie stwórz projekt Apps Script na dwa sposoby: jako samodzielny projekt z script.google.com poprzez opcję „Nowy projekt” lub jako projekt powiązany z kontenerem, otwierając arkusz kalkulacyjny, dokument lub formularz, a następnie wybierając „Rozszerzenia”, a potem „Apps Script”.

Kopiuj dwa pliki z repozytorium do edytora:

ManagedAgentSandboxClient.js to główna klasa klienta. Zarządza cyklem życia środowiska testowego oraz zmiennymi środowiskowymi dynamicznymi, przechowuje dane sesji w PropertiesService i stosuje rozsądne opóźnienia w przypadku błędu 429.
tests.js to główne zestaw testów. Obejmuje ono konfigurację środowiska testowego, sprawdzanie narzędzi, przetwarzanie mediów, scrapowanie stron internetowych oraz testy wydajności.

Następnie otwórz Ustawienia projektu, potem Właściwości skryptu i dodaj właściwość o nazwie GEMINI_API_KEY, która będzie przechowywać klucz. Na koniec upewnij się, że plik manifestu (appsscript.json) zawiera odpowiednie zakresy OAuth. Zakres https://www.googleapis.com/auth/script.external_request jest potrzebny do wywołań UrlFetchApp, natomiast https://www.googleapis.com/auth/drive umożliwia tworzenie folderów docelowych oraz przesyłanie plików. Kod, który korzysta z istniejących folderów bez użycia DriveApp.createFolder(), może funkcjonować przy użyciu zakresu https://www.googleapis.com/auth/drive.file. Logi wykonywania każdego testu znajdują się w pliku gas-src/execution-logs.md w repozytorium.

Przygotowanie współdzielonego środowiska testowego

Wykonanie provisionSharedSandbox() uruchamia nowy zdalny kontener Linuxa, instaluje narzędzia CLI oraz zależności, konfiguruje ścieżki w docelowym Drive i zapisuje uzyskany environmentId w PropertiesService.

Infografika pokazuje cztery kroki. Najpierw Drive tworzy folder docelowy o nazwie ManagedAgent_Artifacts_YYYYMMDD. Następnie kontener z 4 vCPU i 16 GB uruchamia poprzez komendę inicjalizacyjną ggsrun, ffmpeg, sox, jq, typescript, esbuild oraz Playwright z Chromium. Potem sandbox weryfikuje zainstalowane pliki binarne i zgłasza READY. Na koniec unikalny environmentId jest przechowywany pod SHARED_SANDBOX_SESSION, aby późniejsze testy i inne klienty mogły go ponownie wykorzystać. Wywołanie funkcji testListSandboxes() następnie zapytuje API Environments w celu potwierdzenia, że sandbox jest aktywny, i zwraca jego metadane.

Test 1: niestandardowe nagłówki, które Apps Script nadpisuje

Pierwszy test pokazuje, czego UrlFetchApp nie potrafi zrobić. Apps Script automatycznie zastępuje dostosowany nagłówek User-Agent ciągiem identyfikacyjnym proxy Google, natomiast środowisko sandbox zachowuje wszelkie nagłówki, które sam ustalisz, ponieważ wysyła żądania przez surowe gniazda POSIX oraz narzędzie curl.

Diagram przedstawia żądanie zawierające User-Agent: sample user agent skierowane do httpbin.org/anything. Po stronie Apps Script polityka proxy platformy zmienia tę nagłówek. Po stronie sandboxu curl zachowuje dokładny tekst nagłówka. Następnie wbudowany skrypt w Pythonie porównuje odzwierciedlone treści JSON i wyświetla macierz weryfikacji. W praktyce Apps Script wysyła żądanie GET z dostosowanym nagłówkiem, sandbox wysyła to samo żądanie curl, a porównanie potwierdza, że Apps Script zastąpił nagłówek na Mozilla/5.0 (compatible; Google-Apps-Script; beanserver; ...), podczas gdy sandbox zachował dokładnie sample user agent.

Test 2: autoryzacja w Drive z wnętrza sandboxu

To test sprawdza autoryzację w Drive oraz bezpośredni dostęp przez ggsrun, wprowadzając nowy token OAuth z funkcji ScriptApp.getOAuthToken() do wykonywania danego kroku.

W pierwszym kroku Apps Script pobiera token i wprowadza go jako zmienną środowiskową GGSRUN_AT, co eliminuje ryzyko wygaśnięcia tokena po godzinie. W drugim kroku sandbox generuje plik weryfikacyjny 00_ggsrun_verification.txt w katalogu /workspace/test2/ i przesyła go za pomocą ggsrun upload w trybie nadpisywania bez blokowania (--nc --cm OverwriteIfNewer -j). W trzecim kroku ggsrun searchfiles przeszukuje folder docelowy i zwraca ustrukturyzowane metadane potwierdzające obecność wszystkich dziewięciu plików. Cały cykl tworzenia, przesyłania i weryfikacji trwał 12,1 sekundy, a żaden wrażliwy token nie pozostał między sesjami.

Test 3: scrapowanie bez interfejsu graficznego za pomocą Playwright

Następnie zautomatyzowana sesja Chromium bez interfejsu graficznego w środowisku sandbox scrapuje dynamiczny treść renderowaną przez JavaScript i robi zrzuty ekranu w kilku rozmiarach okna przeglądarki.

Skrypt Node.js Playwright otwiera stronę z cytatami renderowaną w JavaScript (quotes.toscrape.com/js/), robi zrzuty ekranu całej strony w rozdzielczości komputera stacjonarnego (1280x800) oraz w emulacji iPhone’a (375x812), następnie klikuje przycisk nawigacji stron, pobiera zrzut ekranu drugiej strony w rozdzielczości komputera stacjonarnego i wydobywa cyaty do pliku 02_Page2_Quotes.json. Rozmiary plików wynosiły około 92,5 KB dla zrzutu z komputera stacjonarnego, 51,6 KB dla wersji mobilnej oraz 171,9 KB dla drugiej strony, plus 4,1 KB pliku JSON – łącznie około 320 KB dla czterech plików. Jedno polecenie ggsrun upload wysłało wszystkie trzy pliki PNG oraz zbiór danych w formacie JSON do Drive bez żadnej konwersji na Base64, a cały proces trwał 20,4 sekundy. To przykład renderowania po stronie klienta, którego Apps Script nie może natywnie przetworzyć.

Test 4: synteza dźwięku za pomocą FFmpeg i SoX

Czwarty test uruchamia natywną obróbkę sygnałów cyfrowych w środowisku sandbox, tworząc akord wielotonowy za pomocą FFmpeg i SoX.

Trzy generatorzy fal sinusoidalnych o częstotliwościach 440 Hz (A4), 554,37 Hz (C#5) i 659,25 Hz (E5) są miksowane za pomocą filtru amix w programie ffmpeg w celu utworzenia trzysekundowego pliku MP3 z akordem mayor o rozmiarze 73,4 KB. Następnie ffprobe wydobywa metadane strumienia do pliku 03_Audio_Analysis.json, który waży 1,8 KB. Polecenie ggsrun upload wysyła plik 03_Chord_Major.mp3 wraz z plikiem JSON bezpośrednio do Drive. Proces syntezy, wydobywania metadanych i ich przesyłania trwał 9,1 sekundy.

Test 5: Analiza kodu TypeScript i pakowanie za pomocą esbuild

Ten test pokazuje, jak nowoczesne narzędzia do budowania kodu w JavaScript i TypeScript działają w środowisku sandbox.

Oba zestawy narzędzi pracują z modułem TypeScript, matrix.ts, który definiuje klasy i interfejsy generyczne i znajduje się w katalogu /workspace/test5/. W pierwszej gałęzi skrypt Node.js wykorzystuje oficjalną API kompilatora TypeScript do analizy drzewa składni abstrakcyjnej oraz eksportuje schematy interfejsów i metod do pliku 04_TypeScript_AST.json, który waży zaledwie 152 bajty. W drugiej gałęzi esbuild pakuje i minimalizuje ten moduł do samodzielnego pliku IIFE, 04_Matrix_Bundle.iife.js, o wielkości 1,2 KB, przy czasie kompilacji wynoszącym zaledwie 13 milisekund. Następnie polecenie ggsrun upload wysyła oba pliki do Drive, a cały proces trwał 10,0 sekundy.

Test 6: bezpośrednie przesłanie pliku w formacie Base64 za pośrednictwem Apps Script

W tym teście 10 000-bajtowy plik binarny jest przenoszony z środowiska sandbox do Drive za pomocą dwóch różnych metod.

W podejściu A sandbox tworzy plik binarny o rozmiarze 10 KB z /dev/urandom i przesyła go do Drive za pomocą ggsrun w ramach jednej rundy interakcji (freshInteraction: true). W podejściu B sandbox koduje te same bajty w formacie Base64 i zwraca je w tekście odpowiedzi API, a Apps Script dekoduje ten ciąg znaków i zapisuje plik w Drive. Podejście A zakończyło się w 16,20 sekundy przy szybkości 0,60 KB/s i nie wykorzystało żadnych zasobów CPU Apps Script. Podejście B wymagało 32,13 sekundy przy szybkości 0,30 KB/s oraz 1,23 sekundy zużycia CPU Apps Script, więc podejście A było 1,98 raza szybsze. Ponadto unika ono mniej więcej 33-procentowego powiększenia rozmiaru pliku spowodowanego kodowaniem Base64 oraz problemu wyczerpania tokenów, z którym borykają się sesje wielorundowe. Zapisany raport wygląda w ten sposób.

================================================================================
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)  |
================================================================================

Strumieniowanie przez ggsrun było 1,98 raza szybsze, eliminowało całe obciążenie procesora i pamięci spowodowane dekodowaniem w Apps Script oraz nie zużywało żadnej kwoty tokenów rozmowy. W przypadku plików o wielkości kilku megabajtów to właśnie ta bezpośrednia ścieżka zapobiega błędom 429 Quota Exceeded.

Kierowanie tą samą przestrzenią sandbox z lokalnej stanowiska roboczego

Aby pokazać, że tę samą trwałą przestrzeń sandbox w Linuxie można kontrolować zarówno z Apps Script, jak i z laptopa, stworzono klienta Node.js z funkcją strumieniowania Server-Sent Events na bazie SDK @google/genai. Apps Script działa synchronicznie i blokująco, zbierając wydarzenia agenta na końcu żądania HTTP, dzięki czemu lokalny silnik oferuje programistom kilka funkcji, których Apps Script nie posiada.

Rzeczywisty przegląd przebiegu procesu. Kroki rozumowania (thought), polecenia w shellu (code_execution_call), dane z stdout i stderr z środowiska sandbox (code_execution_result) oraz tekst generowany przez model (model_output) są przekazywane do terminala w czasie rzeczywistym, z użyciem kolorów ANSI.
Hybrydowy proces pracy przy rozwoju. Prompty i łańcuchy narzędzi mogą być prototypowane, debugowane i dostosowywane lokalnie przy użyciu informacji zwrotnych w czasie rzeczywistym, a następnie przenoszone do automatycznych wyzwalaczy Apps Script, które działają bez nadzoru.
Łatwe udostępnianie środowiska sandbox. Umieszczenie identyfikatora wygenerowanego podczas konfiguracji Apps Script w polu ENVIRONMENT_ID w lokalnym pliku .env łączy klienta z istniejącym kontenerem, wraz ze wszystkimi zainstalowanymi pakietami, zbiornikami skompilowanymi oraz plikami z obszaru roboczego, bez konieczności ponownej instalacji.

Automatyczne obsługiwanie OAuth. Narzędzie pobiera nowe tokeny dostępu do Google za pomocą polecenia gcloud auth print-access-token i wprowadza je do zmiennej GGSRUN_AT, dzięki czemu przesyłanie plików bezpośrednio do Drive działa tak samo jak w Apps Script, bez konieczności ręcznego kopiowania danych dostępowych.

Uruchomienie lokalnych testów wymaga czterech kroków.

Klonuj repozytorium i uruchom polecenie npm install w katalogu local-node.js-src.
Zrób kopię pliku .env.example jako .env i uzupełnij trzy wartości: swój klucz API jako GEMINI_API_KEY, identyfikator środowiska długotrwałego jako ENVIRONMENT_ID, oraz folder w Drive, do którego mają być zapisywane pliki, jako TARGET_FOLDER_ID.
Uruchom polecenie npm test lub pojedynczy test za pomocą npm run test:1 do test:6 i obserwuj pracę agenta w czasie rzeczywistym.
Gdy skończysz, uruchom npm run test:teardown, aby usunąć zdalną przestrzeń sandbox i zwolnić zasoby chmurowe.

Pełne transkrypcje w formacie surowym wraz z wynikami transmisji na żywo są przechowywane w pliku local-node.js-src/execution-logs.md w repozytorium i pokazują te same wyniki funkcjonalne co wykonywanie skryptów Apps Script.

Wzorce API dla zarządzanych agentów

Poniższe wzorce podsumowują najczęstsze sposoby pracy z API Gemini v1beta Interactions and Environments. Każdy z nich wysyła żądanie POST do tego samego endpointu bazowego.

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

Scenariusz 1 wykorzystuje jeden wspólny, trwały sandbox między wieloma klientami. Utwórz środowisko zdalne raz, ustawiając environment.type na "remote", zapisz otrzymany environment_id i wysyłaj go jako zwykły ciąg znaków w późniejszych żądaniach z Apps Script, Node.js, Python lub zadania CI/CD.

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

Scenariusz 2 to izolowana środowisko testowe dla każdego uruchomienia. Gdy zadanie wymaga zupełnie nowego środowiska Linux, ustaw environment.type na "remote" przy każdym wywołaniu.

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

Scenariusz 3 zachowuje kontekst rozmowy między kolejnymi krokami. Należy uwzględnić previous_interaction_id, gdy agent musi pamiętać wcześniejsze rozumowanie, zmienne lub wyniki poleceń.

{
  "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"
}

Scenariusz 4 ponownie wykorzystuje środowisko sandbox z nowym kontekstem za pomocą opcji freshInteraction. Wystarczy podać istniejący environment_id i pominąć previous_interaction_id. Wszystkie pliki oraz zainstalowane narzędzia w kontenerze pozostają nietknięte, natomiast historia rozmów jest resetowana do zera tokenów, co zapobiega wyczerpaniu limitu prędkości TPM.

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

Porównanie na pierwszy rzut oka

Matryca podsumowująca umieszcza różne podejścia obok siebie.

Co to oznacza

Łączenie Apps Script z Gemini Managed Agents pozwala przezwyciężyć typowe ograniczenia środowiska bezserwerowego. Trwała zdalna przestrzeń sandbox, w połączeniu z transmisją danych w obie strony bezpośrednio między chmurowym magazynem a przestrzenią sandbox, umożliwia przetwarzanie obciążeń, których Apps Script sam nie może obsłużyć, a także omija ograniczenia ilości danych w żądaniach API oraz kwoty tokenów do rozmów.

Przekracza się ograniczenia Apps Script. Zadania wymagające natywnego środowiska Linux, takie jak scrapowanie stron za pomocą bezekranowego przeglądarki z Playwright, synteza dźwięku z FFmpeg czy kompilacja kodu TypeScript za pomocą esbuild, mogą teraz być uruchamiane z Apps Script.
Rozumowanie AI łączy się z wykonywaniem w Linuxie. Zamiast uruchamiania stałych poleceń z zewnątrz, mechanizm rozumowania Gemini współpracuje z prawdziwym shelliem, dzięki czemu polecenia są tworzone w czasie rzeczywistym, kod jest wykonywany podczas działania, a agent może sam się korygować podczas złożonych procesów pracy.
Przepływ danych w obu kierunkach oszczędza tokeny i dane. Wrzucanie plików oraz pobieranie dużych zbiorów danych z Drive do środowiska sandbox unika konieczności umieszczania danych w promptach i konwersji na Base64, co zapewnia niską liczbę tokenów wejściowych i wyjściowych, a także pozwala uniknąć ograniczenia 50 MB oraz kwoty 200 000 TPM.
Wspólne środowiska sandbox obniżają koszty. Przechowywanie wspólnych zbiorów danych i narzędzi w wspólnym systemie plików kontenera eliminuje konieczność powtarzalnego przesyłania i konfiguracji dla każdego zadań, co zmniejsza opóźnienia i zużycie przepustowości.
Badania porównawcze potwierdzają to. Bezpośrednie przesyłanie danych z chmury do chmury za pomocą interfejsu CLI było 1,98 raza szybsze niż pobieranie danych w formacie Base64 przez API, bez kosztów dekodowania na poziomie procesora i bez wykorzystania pamięci lokalnej w Apps Script.

← Wszystkie artykuły Wyślij brief