Przejdź do głównej zawartości

Środowiska wykonawcze w chmurze

Twój kolega z zespołu w innej strefie czasowej wysyła wiadomość na Slacku: “@Codex fix the failing integration tests in the payments service.” W ciągu kilku minut Codex uruchamia kontener w chmurze, klonuje repo, instaluje zależności, identyfikuje przyczynę i odpowiada linkiem do poprawki — wszystko bez otwierania laptopa przez kogokolwiek. To siła wykonywania w chmurze Codex.

  • Gotowa produkcyjna konfiguracja środowiska chmurowego ze skryptami setup, sekretami i cache’owaniem
  • Strategia dostępu do internetu balansująca bezpieczeństwo z potrzebą pobierania pakietów
  • Wzorzec best-of-N do generowania wielu prób rozwiązania i wybierania najlepszego
  • Techniki rozwiązywania problemów z cache’owaniem kontenerów, proxy sieciowymi i dryftem środowisk

Gdy wysyłasz zadanie chmurowe, Codex postępuje według precyzyjnej sekwencji:

  1. Tworzenie kontenera: Codex tworzy kontener z bazowego obrazu universal (lub ze zcache’owanego stanu) i checkoutuje twoje repo na wybranym branchu lub SHA commita.

  2. Skrypt setup: Twój niestandardowy skrypt setup uruchamia się z pełnym dostępem do internetu. Tu instalujesz zależności, narzędzia i konfigurujesz środowisko.

  3. Skrypt maintenance (tylko zcache’owane kontenery): Jeśli wznawiany jest zcache’owany kontener, skrypt maintenance aktualizuje zależności, które mogły się zmienić od czasu utworzenia cache’u.

  4. Blokada dostępu do internetu: Dostęp agenta do internetu jest domyślnie wyłączony. Obowiązuje twoja allowlista per-środowisko.

  5. Wykonanie agenta: Agent pracuje w pętli — czyta pliki, edytuje kod, uruchamia polecenia i waliduje. Używa twojego AGENTS.md do znalezienia poleceń lint i test specyficznych dla projektu.

  6. Wyniki: Agent prezentuje swoją odpowiedź i diff. Możesz otworzyć PR lub zadać pytania uzupełniające.

Konfiguruj środowiska w Codex settings > Environments.

Dla projektów wykraczających poza podstawowe npm install, napisz niestandardowy skrypt setup:

Okno terminala
# Install system dependencies
apt-get update && apt-get install -y libpq-dev redis-tools
# Install language-specific tools
pip install pyright poetry
poetry install --with test
# Install Node dependencies
pnpm install
# Build shared libraries
pnpm run build:shared

Zmienne środowiskowe są dostępne przez cały czas trwania zadania (setup + agent). Używaj ich do niesensytywnej konfiguracji jak NODE_ENV=test lub DATABASE_URL=postgres://localhost/test.

Sekrety mają dodatkową warstwę szyfrowania i są dostępne tylko podczas skryptów setup. Są usuwane przed uruchomieniem agenta. Używaj sekretów do kluczy API potrzebnych podczas npm install (np. tokeny prywatnych rejestrów), ale nigdy do wartości runtime’owych potrzebnych agentowi.

Codex cache’uje stan kontenera przez do 12 godzin. Gdy cache’owanie jest aktywne:

  1. Skrypt setup uruchamia się raz i wynik jest cache’owany
  2. Kolejne zadania pomijają skrypt setup i używają zcache’owanego kontenera
  3. Skrypt maintenance (opcjonalny) obsługuje aktualizacje jak npm install po zmianach zależności

Cache jest automatycznie unieważniany gdy zmienisz skrypt setup, skrypt maintenance, zmienne środowiskowe lub sekrety. Naciśnij Reset cache ręcznie, jeśli zmiany w twoim repo psują kompatybilność.

Dla planów Business i Enterprise cache jest współdzielony między wszystkimi użytkownikami z dostępem do środowiska. Unieważnienie cache’u wpływa na wszystkich.

Domyślnie agent nie ma dostępu do internetu podczas wykonywania. To celowa decyzja bezpieczeństwa — zapobiega prompt injection z niezaufanych treści webowych, eksfiltracji kodu i pobieraniu podatnych zależności.

Gdy potrzebujesz dostępu do internetu, skonfiguruj go per-środowisko:

Allowlista domen: Zacznij od presetu “Common dependencies”, który obejmuje npm, PyPI, crates.io i dziesiątki innych rejestrów pakietów. Dodawaj niestandardowe domeny wedle potrzeb.

Ograniczenia metod HTTP: Dla maksymalnego bezpieczeństwa ogranicz do GET, HEAD i OPTIONS. To zapobiega wysyłaniu danych przez agenta na zewnętrzne serwery, nawet jeśli odwiedzi stronę ze złośliwymi instrukcjami.

Z CLI możesz zażądać wielu równoległych prób dla zadania chmurowego:

Okno terminala
codex cloud exec --env ENV_ID --attempts 3 "Fix the failing integration tests"

Codex uruchamia 3 niezależnych agentów na tym samym zadaniu. Każdy produkuje własne rozwiązanie. Przeglądasz wszystkie trzy i wybierasz najlepsze. Jest to szczególnie skuteczne dla:

  • Złożonych refaktoringów, gdzie istnieje wiele poprawnych podejść
  • Poprawek błędów, gdzie przyczyna jest niejednoznaczna
  • Optymalizacji wydajności, gdzie różne strategie mają różne kompromisy
  • Skrypt setup kończy się cicho błędem: Sprawdź, czy twój skrypt używa set -e lub ma jawną obsługę błędów. Nieudany apt-get install może nie zatrzymać skryptu, prowadząc do brakujących narzędzi w fazie agenta.
  • Cache się przedawnia: Jeśli drzewo zależności twojego projektu zmienia się często, dodaj skrypt maintenance uruchamiający odpowiednik npm install. Bez niego zcache’owane kontenery mogą mieć nieaktualne zależności.
  • Agent nie znajduje poleceń: Pamiętaj, że export w skrypcie setup nie przenosi się. Umieść ścieżki do narzędzi i zmienne środowiskowe w ~/.bashrc zamiast tego.
  • Problemy z proxy sieciowym: Cały ruch wychodzący przechodzi przez proxy HTTP/HTTPS. Niektóre narzędzia (jak curl z niestandardowymi certyfikatami) mogą wymagać konfiguracji uwzględniającej proxy.
  • Niedopasowanie obrazu kontenera: Domyślny obraz universal ma preinstalowane popularne języki. Jeśli potrzebujesz konkretnej wersji, użyj “Set package versions” w ustawieniach środowiska lub zainstaluj ją w swoim skrypcie setup.
  • Tryb nieinteraktywny — Użyj codex exec do uruchamiania workflow w stylu chmury z CI
  • GitHub Action — Automatyzuj zadania w stylu chmury bezpośrednio w GitHub Actions
  • Zarządzanie kosztami — Zadania chmurowe zużywają więcej kredytów niż lokalne; naucz się optymalizować