Poza panelami kontrolnymi: tworzenie autonomicznego agenta analityka danych BigQuery
Autonomiczny agent analityka danych BigQuery z Google ADK i Gemini: dlaczego panele kontrolne oraz proste narzędzia konwertujące tekst na SQL zawodzą w końcowej fazie, i jak to naprawić w procesach CI/CD.
To przewodnictwo pokazuje, jak odtworzyć proces od surowców do gotowego systemu w ramach projektu: Beyond Dashboards: Building an Autonomous BigQuery Data Analyst Agent with Google ADK for Customer 360. Skupia się na konkretnych krokach realizacji, jasnych sprawdzeniach oraz kodzie, który można bez problemu umieścić w repozytorium, bez konieczności domyślania się intencji twórcy. Na etapie przeglądu należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu systemu. Lepiej używać małych, łatwych do przetestowania jednostek niż rozbudowanych skryptów. Gdy dany krok zawiedzie, powinien wskazywać na konkretną przyczynę problemu, a nie na skomplikowany łańcuch operacji.
1. Wąskie gardło na końcowym etapie: Dlaczego tradycyjne narzędzia BI i proste metody konwersji tekstu na SQL zawodzą
Gdy przechodzisz przez etap 1 „Wąskie gardło ostatecznego kroku”, 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 odrzuć możliwość cichego, częściowego ukończenia zadania. Ustaw punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Dlaczego tradycyjne panele analityczne zawodzą
Gdy przechodzisz przez etap „Dlaczego tradycyjne panele BI?”, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co się dzieje 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 proces przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Ustal punkty kontrolne po kosztownych krokach. System nie powinien ponownie naliczać opłaty za ten sam wywołanie LLM, gdy operator ponawia próbę z późniejszym węzłem.
Dlaczego naiwne narzędzia typu „Tekst do SQL” oparte na LLM zawodzą w przedsiębiorstwach
Gdy przechodzisz przez etap Why Naive Text-to-SQL LLM, 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. Zachowuj w pamięci podręcznej stabilne instrukcje systemowe oraz schematy narzędzi. Ponowne wysyłanie identycznego prefiksu to częsty powód marnotrawstwa zasobów. Gdy przechodzisz przez etap Why Naive Text-to-SQL LLM, 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. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną ścieżkę przetwarzania.
2. Architektura agentowa: Framework Google ADK
Architektura agentowa funkcjonuje najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zanim rozszerzysz zakres, zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań. Traktuj tę fazę 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ń. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane w danym polu, co powoduje przerwanie kontynuacji po przerwach.
3. Filar inżynierii 1: Ugruntowanie wiedzy i buforowanie kontekstu w Vertex AI
Faza 1 trzeciego filaru inżynieryjnego funkcjonuje najlepiej, gdy jest traktowana jako mierzalna powierzchnia. Zapisz jeden idealny przykład działania, jeden przypadek awarii oraz notatkę o cofnięciu zmian, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy przechodzi się z środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione struktury ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po przerwach.
Kompilowanie słowników Markdown do promptu systemowego
Kompilowanie słowników Markdown do etapu rozwoju działa najlepiej, gdy traktuje się je 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. Trzymaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny poufnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Ustal limit tokenów na jeden ruch i sesję. Narzędzia typu agentic intensywnie rozszerzają kontekst; sztywne ograniczenia zapobiegają temu, by demonstracje przerodziły się w niespodziewane rachunki. Kompilowanie słowników Markdown do etapu rozwoju działa najlepiej, gdy traktuje się je 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. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną sekwencję działań.
# c360_agent/config.py
import os
import glob
def compile_knowledge_base(knowledge_dir: str) -> str:
"""Recursively compiles markdown architecture guides into structured agent context."""
context_chunks = []
guide_files = glob.glob(os.path.join(knowledge_dir, "**/*.md"), recursive=True)
for file_path in sorted(guide_files):
with open(file_path, "r", encoding="utf-8") as f:
rel_name = os.path.relpath(file_path, knowledge_dir)
content = f.read()
context_chunks.append(f"### KNOWLEDGE GUIDE: {rel_name}\n\n{content}\n")
return "\n---\n".join(context_chunks)
KNOWLEDGE_CONTEXT = compile_knowledge_base("c360_agent/knowledge")
SYSTEM_PROMPT = f"""
You are an expert BigQuery Data Analyst Agent for an Enterprise Customer 360 (C360) Lakehouse.
Your mission is to answer business and analytical questions by generating and executing accurate, cost-effective SQL queries.
CRITICAL OPERATIONAL RULES:
1. TARGET CONFORMED MARTS FIRST: Always query `c360_curated_unified` for golden demographics or cross-system questions. Use Spoke marts (`c360_curated_*`) only for system-specific line-item grain.
2. MANDATORY DRY RUN: You MUST execute `dry_run_bq_query` on every generated SQL statement before calling `execute_bq_query`. Inspect syntax and bytes scanned.
3. CLUSTER AWARENESS: Always filter or join on clustered keys (`UnifiedCustomerDimId`, `UnifiedOrderDimId`) to minimize BigQuery slot consumption.
4. STRICT READ-ONLY: You are strictly forbidden from executing INSERT, UPDATE, DELETE, DROP, or ALTER statements.
DOMAIN ARCHITECTURE CONTEXT:
{KNOWLEDGE_CONTEXT}
"""
Zmieniacz zasad gry pod względem kosztów: Cache kontekstu Vertex AI
Dla etapu Vertex „Zmieniacz zasad gry pod względem kosztów” 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. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj kryteria sukcesu i odrzucaj ciche, częściowe ukończenie zadań. Wprowadź ludzką aprobatę dla operacji, które powodują wydatki lub zmieniają dane produkcyjne. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej.
# c360_agent/agent.py
from google.adk.agents.llm_agent import Agent
from google.adk.apps import App
from google.adk.agents.context_cache_config import ContextCacheConfig
from .config import SYSTEM_PROMPT
from .tools import (
execute_bq_query,
dry_run_bq_query,
get_table_schema,
list_dataset_tables,
get_table_preview
)
# 1. Initialize the Google ADK Agent
root_agent = Agent(
name="c360_data_analyst",
model="projects/enterprise-c360-prod/locations/us-central1/publishers/google/models/gemini-2.5-flash",
description="Autonomous BigQuery Data Analyst for the Enterprise Customer 360 Lakehouse.",
instruction=SYSTEM_PROMPT,
tools=[
dry_run_bq_query,
execute_bq_query,
get_table_schema,
list_dataset_tables,
get_table_preview
]
)
# 2. Wrap in App with Vertex AI Context Caching
app = App(
name="c360_agent_app",
root_agent=root_agent,
context_cache_config=ContextCacheConfig(
ttl_seconds=1800, # Cache prompt for 30 minutes
cache_intervals=10 # Reuse across up to 10 conversational turns
)
)
4. Drugi filar inżynierii: Bezpieczne wykonywanie narzędzi z kontrolą kosztów
Dla etapu 4 Engineering Pillar 2 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ć czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Autoryzacja powinna odbywać się przy bramie wejściowej, a ponowna autoryzacja – na poziomie warstwy danych. Sam token nie stanowi granicy między poszczególnymi użytkownikami.
# c360_agent/tools.py
import subprocess
import re
def dry_run_bq_query(query: str) -> str:
"""Dry-runs a BigQuery SQL query to validate syntax and estimate bytes scanned."""
clean_query = query.strip().upper()
# Layer 1: Strict Read-Only Guard
if not (clean_query.startswith("SELECT") or clean_query.startswith("WITH")):
return "SECURITY ERROR: Only SELECT queries are permitted. DDL/DML is strictly forbidden."
try:
# Executes 'bq query --dry_run' to inspect execution planner without billing slots
result = subprocess.run(
["bq", "query", "--use_legacy_sql=false", "--dry_run", query],
capture_output=True,
text=True,
check=True
)
# bq CLI outputs estimated bytes scanned to stderr on dry run
dry_run_output = result.stderr if result.stderr else result.stdout
return f"DRY_RUN SUCCESS: {dry_run_output.strip()}"
except subprocess.CalledProcessError as e:
return f"DRY_RUN SYNTAX ERROR: {e.stderr.strip()}"
def execute_bq_query(query: str) -> str:
"""Executes a validated BigQuery SQL query and returns the formatted tabular results."""
clean_query = query.strip().upper()
if not (clean_query.startswith("SELECT") or clean_query.startswith("WITH")):
return "SECURITY ERROR: Only SELECT queries are permitted."
try:
result = subprocess.run(
["bq", "query", "--use_legacy_sql=false", "--format=pretty", "--max_rows=50", query],
capture_output=True,
text=True,
check=True
)
return result.stdout
except subprocess.CalledProcessError as e:
return f"EXECUTION ERROR: {e.stderr.strip()}"
5. Engineering Pillar 3: Autonomiczny cykl samokorekcyjny
W ramach etapu 3 z 5 filarów inżynierii należy określić 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 przeglądania całej struktury. Konieczna jest ludzka akceptacja dla operacji, które wiążą się z wydawaniem pieniędzy lub modyfikacją danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełnej kompletności biznesowej. W ramach etapu 3 z 5 filarów inżynierii należy określić 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. Należy preferować małe, testowalne jednostki nad rozbudowanymi skryptami. Gdy dany krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną strukturę procesów.
Prawdziwy ślad produkcji: pętla samolecząca w działaniu
Podczas pracy nad etapem Prawdziwego śladu produkcji najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego awarii. 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 odrzuć ciche, częściowe ukończenie zadań. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Pytanie użytkownika biznesowego
Gdy przechodzisz przez etap użytkownika biznesowego, 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. Zapisz czas trwania oraz koszt tokena lub zapytania obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Zrób kontrolę po kosztownych krokach. Narzędzie do kontynuacji nie powinno ponownie naliczać opłaty za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Krok 1: Pierwsza próba i odrzucenie przez kompilatora
Gdy przechodzisz przez etap Pierwszej próby z kroku 1, 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. Ustaw punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł. Gdy przechodzisz przez etap Pierwszej próby z kroku 1, 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. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną ścieżkę przetwarzania.
-- Attempt 1: Generated by Agent (Pre-Flight Dry Run)
SELECT
SUM(c.total_spent) AS total_vip_revenue
FROM `enterprise-c360-prod.c360_curated_shopify.dim_customer` c
JOIN `enterprise-c360-prod.c360_curated_shopify.CustomerWarranties` w
ON c.customer_id = w.customer_id;
Krok 2: Autonomiczna diagnostyka i samokorekcja
Etap autonomicznej diagnostyki w Kroku 2 działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres. 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ń. Utrzymuj stan grafu w prostej formie i określonej typologii. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, co powoduje przerwanie kontynuacji po przerwach.
SELECT SUM(c.total_spent) AS total_vip_revenue
FROM `enterprise-c360-prod.c360_curated_shopify.dim_customer` c
JOIN `enterprise-c360-prod.c360_curated_shopify.CustomerWarranties` w
- ON c.customer_id = w.customer_id;
+ ON c.UnifiedCustomerDimId = w.UnifiedCustomerDimId;
Krok 3: Weryfikacja kosztów przed rozpoczęciem działania
Etap kosztów przed lotem w kroku 3 działa najlepiej, gdy traktuje się go jako mierzalną wielkość. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę o cofnięciu działań, zanim rozszerzysz zakres badania. Zapisuj czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Utrzymuj stan grafu w prostej formie i z określonym typem danych. Wplecione elementy ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji po zakłóceniach.
Krok 4: Ograniczona eksploatacja i synteza wykonawcza
Faza Wykonywania Ograniczonego z Kroku 4 funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres. 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. Utrzymuj stan struktury w formie prostych, typowanych elementów. Wtórne struktury ukrywają informację o tym, który węzeł zapisał dane w danym polu, i utrudniają kontynuację działania po przerwach. Faza Wykonywania Ograniczonego z Kroku 4 funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną sekwencję działań.
6. Od interfejsu CLI do interaktywnego interfejsu webowego
W fazie 6 From Terminal CLI 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. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy artefaktom, zdefiniuj sprawdzenia sukcesu i odrzuć ciche, częściowe ukończenie zadań. Wymagaj ludzkiej aprobaty w przypadkach, gdy dochodzi do wydawania pieniędzy lub modyfikacji danych produkcyjnych. Połączenia realizowane w czasie kompilacji nie równają się pełności biznesowej.
Tryb 1: Terminal CLI dla inżynierów danych i CI/CD
W fazie terminala CLI w trybie 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ć dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy rejestrować czasy wykonywania 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. Konieczne jest ludzkie zatwierdzenie w przypadkach, gdy dochodzi do wydatków lub zmian w danych produkcyjnych. Połączenia skompilowane w czasie kompilacji nie gwarantują pełnej kompletności rozwiązania biznesowego.
python3 c360_agent/agent.py "Show me top 5 customers by SAP delivery volume in 2026"
Tryb 2: Interaktywna konsola debugowania w sieci (adk web)
Dla etapu Mode 2 Interactive Web należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok od 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. Konieczne jest ludzkie zatwierdzenie dla operacji, które wiążą się z wydatkami lub zmianą danych produkcyjnych. Połączenia skompilowane w czasie kompilacji nie gwarantują pełnej kompletności biznesowej. Dla etapu Mode 2 Interactive Web należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić dany krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy preferować małe, testowalne jednostki nad rozbudowanymi skryptami. Gdy dany krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną strukturę procesów.
adk web --port 8001 c360_agent --reload
Streszczenie: Lista kontrolna autonomicznego agenta przedsiębiorstwa
Podczas przechodzenia przez etap autonomicznego agenta przedsiębiorstwa, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Ta 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 odrzuć ciche, częściowe ukończenie zadań. Ustaw punkty kontrolne po kosztownych krokach. System powrotu nie powinien ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Zakończenie trylogii: Nowoczesna baza danych przedsiębiorstwa
Gdy pracujesz nad etapem „The Trilogy Concluded The”, 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. Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Ustal punkty kontrolne po kosztownych krokach. Narzędzie do kontynuacji pracy nie powinno ponownie naliczać opłat za tę samą wywołanie LLM, gdy operator próbuje ponownie uruchomić późniejszy węzeł.
Lista kontrolna operacyjna
Etap listy kontrolnej operacyjnej 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 ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownego uruchomienia, kontrole ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
Zachowuj prostą i typowaną strukturę stanu grafu. Wkładane błyny ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji działania po przerwach.
Dodaj test wstępny, który sprawdza kluczową ścieżkę w procesie CI przy użyciu fixitów, a nie rzeczywistych, płatnych API, gdy tylko pozwala na to budżet.
Wolę małe, testowalne jednostki niż rozbudowane skrypty. Gdy jakiś krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji.
Zachowuj prostą i typowaną strukturę stanu grafu. Wkładane błyny ukrywają informację o tym, który węzeł zapisał dane do którego pola, i powodują przerwanie kontynuacji działania po przerwach.
Literatura pokrewna
- Praktyczne notatki: Budowanie autonomicznego agenta UI Critic z użyciem nowego Google — Szczegółowy przewodnik po praktycznych notatkach dotyczących budowania autonomicznego agenta UI Critic z użyciem nowego Google: kontrakty, sprawdzenia oraz miejsca na kod do wklejenia dla zespołów wdrażających ten wzorzec.
- Praktyczne notatki: Budowanie agenta rozmówczego BigQuery na Vertex AI z użyciem ADK — Szczegółowy przewodnik po praktycznych notatkach dotyczących budowania agenta rozmówczego BigQuery na Vertex AI z użyciem ADK: kontrakty, sprawdzenia oraz miejsca na kod do wklejenia dla zespołów wdrażających ten wzorzec.