Wskazówki praktyczne: Co nauczyłem się o wysyłaniu agenta AI produkcyjnego za pomocą usług Google

Niech to służy jako przebudowa idei z artykułu „What I Learned Shipping a Production AI Agent with Google’s Gemini Function Calling” przeznaczona dla operatorów: wyraźne etapy, uporządkowane sekcje kodu oraz notatki dotyczące napraw, które przetrwają przeniesienie obowiązków. Etap Przeglądu działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny zapis rozmowy, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.

1. Deklaracje funkcji: Traktuj je jako umowę API z modelem

W fazie Think dla deklaracji funkcji nr 1 należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zapisuj czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Oddziel konstrukcję klienta od pętli komunikatów, aby można było zmieniać dostawców bez konieczności przepisywania maszyny stanu rozmowy.

// ❌ Vague — model won’t know when to use it
{ name: ‘get_data’, description: ‘Gets data about a location.’ }

// ✅ Trigger-specific — model knows exactly when this is relevant
{
 name: ‘find_backup_spots’,
 description: ‘Finds nearby indoor/covered alternatives within walking distance ‘
 + ‘if the venue is crowded or weather turns.’,
}

{
 name: ‘calculate_transit_route’,
 description: ‘Calculates precise walking/driving/transit travel times to the venue.’,
 parameters: {
 type: ‘OBJECT’,
 properties: {}, // No parameters — dispatcher injects from context
 },
}

2. Pętla narzędzia wielokrotnych rund: maszyna stanów, a nie pojedyncze wezwanie

W fazie 2 narzędzia Multi-Turn Tool należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Konfigurację należy przechowywać poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Należy oddzielić budowę klienta od pętli komunikatów, aby można było zmieniać dostawców bez konieczności przepisywania maszyny stanu rozmowy.

Turn 0: [user prompt + system instructions]
 → Model returns: functionCall { name: “tool_a”, args: {…} }

Turn 1: [user prompt, model’s functionCall, your functionResponse for tool_a]
 → Model returns: text response (synthesized from tool_a’s output)

Turn 0: [user prompt]
 → Model returns: functionCall { name: “tool_a”, args: {…} }

Turn 1: [user prompt, functionCall_a, functionResponse_a]
 → Model returns: functionCall { name: “tool_b”, args: {…} }

Turn 2: [user prompt, functionCall_a, functionResponse_a, functionCall_b, functionResponse_b]
 → Model returns: final text (synthesized from both tools)

3. Kaskadowanie modeli: Unikaj przywiązania do jednego modelu

Dla etapu 3 Model Cascading Don należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżkę naprawczą. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Należy oddzielić budowę klienta od pętli przekazywania wiadomości, aby można było zmieniać dostawców bez konieczności przepisywania maszyny stanów rozmowy. Dla etapu 3 Model Cascading Don należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.

Primary: gemini-3.5-flash-lite (fastest, cheapest, zero-thinking overhead)
Secondary: gemini-3.1-flash-lite (slightly older, same tier)
Tertiary: gemini-2.5-flash (thinking-capable, higher quality)

4. Architektura klucza API: wzorzec proxy

Gdy przechodzisz przez 4 etapy architektury klucza API, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Zapisuj ID żądania, ID modelu oraz opóźnienie przy każdym wywołaniu. Bez takiego śladu przerywane błędy dostawcy wyglądają jak błędy aplikacji.

Rozwiązanie: proxy po stronie serwera

Gdy przechodzisz przez etap The Solution A Server-Side, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Zapisuj ID żądania, ID modelu oraz opóźnienie przy każdej próbie połączenia. Bez tych informacji przerywane błędy dostawcy wyglądają jak błędy aplikacji.

const res = await Promise.race([
 proxyCallable({ model: modelName, body: requestBody }),
 new Promise((_, reject) =>
 setTimeout(() => reject(new Error(‘AI proxy timeout’)), 15000)
 ),
]);

5. Kompresja kontekstu: to, co podajesz modelowi, ma większe znaczenie niż to, jaki model używasz

Gdy przechodzisz przez 5 etapów Context Compression What, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, kontrola przez ludzi oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później. Zapisuj ID żądania, ID modelu oraz opóźnienie przy każdej próbie połączenia. Bez tych informacji przerywane błędy dostawcy wyglądają jak błędy aplikacji. Gdy przechodzisz przez 5 etapów Context Compression What, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań.

[CONTEXT]
Category: Coffee
Date: Saturday, Aug 30, 2026
Time: 10:00 AM — 11:30 AM (90 mins)
Group Size: 4/8 participants
User Role: Attendee
Country: AU
Currency: AUD
[END CONTEXT]

6. Projektowanie agenta z naciskiem na pracę offline: deterministyczne rozwiązanie awaryjne

Etap 6 projektowania agenta z naciskiem na pracę offline działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres projektu. Zapisuj czasy wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy przechodzi się od środowiska demonstracyjnego do współdzielonych środowisk. Ustal stałe wartości interpretera oraz pliku blokującego zależności przed nauczeniem pętli. Różnice między laptopem a środowiskiem CI są najczęstszą przyczyną ukrytych awarii w demonstracjach API.

7. Dostrojenie generationConfig

Faza dostrojowania configurationConfig 7. generacji działa najlepiej, gdy traktuje się ją jako mierzalną powierzchnię. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres prac. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustal stałe wartości interpretera oraz pliku blokującego zależności przed nauczeniem pętli. Różnice między laptopem a środowiskiem CI są najczęstszą przyczyną ukrytych awarii w demonstracjach API.

{
 “responseMimeType”: “application/json”,
 “temperature”: 0.4,
 “maxOutputTokens”: 600
}

{
 “temperature”: 0.7,
 “maxOutputTokens”: 700
}

8. Inżynieria promptów systemowych dla korzystania z narzędzi

8 etap inżynierii promptów systemowych działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zdokumentuj zarówno prawidłowy przebieg działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrola przez ludzi oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później. Zabezpiecz interpreter oraz plik blokujący zależności przed rozpoczęciem pracy z pętlami. Rozbieżności między laptopem a środowiskiem CI są najczęstszą przyczyną niewidzialnych awarii w demonstracjach API. 8 etap inżynierii promptów systemowych działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzucaj przypadki cichego, częściowego ukończenia zadania.

You have access to autonomous action tools. When users ask for rides,
ALWAYS call request_rideshare. When users ask to book a table,
ALWAYS call reserve_table. When users ask about cultural norms,
ALWAYS call get_cultural_etiquette.

NO RAW MARKDOWN HEADINGS: Never use ‘#’. Use **Bold Text** for headers.
NO ASTERISKS FOR BULLETS: Use clean unicode bullet points (• ).
CONCISE: Jump straight to the answer. No filler introductions.

9. Uwagi z doświadczeń

W fazie „9 lekcji wyciągniętych” należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Należy oddzielić budowę klienta od pętli komunikacji, aby można było wymieniać dostawców bez konieczności przepisywania maszyny stanu rozmowy.

Lista kontrolna operacyjna

Podczas pracy nad fazą listy kontrolnej operacyjnej najpierw należy spisać umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie.

Należy preferować małe, łatwe do testowania jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji.

Zapisuj identyfikator żądania, identyfikator modelu oraz czas opóźnienia przy każdym wywołaniu. Bez tych informacji przerywane błędy dostawcy wyglądają jak błędy aplikacji.

Zachowuj strukturę grafu w prostej formie i z określonym typem danych. Wkładki o podporządkowanej strukturze ukrywają informację o tym, który węzeł zapisał dane do którego pola, co utrudnia kontynuację pracy po przerwach.

Gdy budżet na to pozwala, dodaj test wstępny, który sprawdza kluczowy szlak działania w środowisku CI przy użyciu narzędzi do konfiguracji, a nie rzeczywistych, płatnych API.

Konfigurację należy przechowywać oddzielnie od kodu aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności przeglądania całej struktury grafu.

Zanim wdrożysz tę architekturę, zamroź wersje, utwórz dokładny zapis dla kluczowych etapów realizacji oraz potwierdź kroki odwracania zmian. Środowiska współdzielone wymagają ograniczeń szybkości, weryfikacji przynależności użytkowników oraz wyraźnego właściciela odpowiedzialnego za rotację haseł. Wolimy nudną niezawodność od pomysłowych, jednorazowych demonstracji.

Uwaga dotycząca zlecenia 0ead08720324: trzymaj klucze dostawcy poza repozytorium, ustaw ograniczenie liczby tokenów na sesję oraz przechowuj zapisy obok plików przygotowawczych do testowania, aby późniejsze zmiany modeli pozostawały porównywalne.