Ghid pentru construirea de agenți ADK cu abilități puternice

Acasă » Piton » Ghid pentru construirea de agenți ADK cu abilități puternice

Agenții inteligenți construiți cu un kit de dezvoltare a agenților (ADK) devin rapid coloana vertebrală a aplicațiilor moderne bazate pe inteligență artificială., depășind cu mult chatboții cu o singură acțiune care doar răspund la întrebări. Cu sistemul de competențe potrivit, acești agenți pot raționa, planifica, apela instrumente, colabora cu alți agenți și chiar își pot rafina propria muncă în bucle, toate acestea menținând sub control utilizarea token-urilor și latența datorită tehnicilor de dezvăluire progresivă.

În acest ghid detaliat, veți învăța cum să proiectați, să structurați și să orchestrați agenți ADK cu ajutorul abilităților necesare., de la fluxurile de lucru cu un singur agent de bază până la fluxurile de lucru cu mai mulți agenți care rulează în secvență, în bucle și în paralel. Veți vedea, de asemenea, cum stivele din lumea reală, precum laboratoarele de cod ADK de la Google, abilitățile comunității și framework-urile de orchestrare, cum ar fi AgentKit 2.0, utilizează modele precum Router, SequentialAgent, LoopAgent și ParallelAgent, plus cum companii precum Q2BSTUDIO combină aceste aspecte cu platformele cloud și securitatea cibernetică pentru a livra sisteme pregătite pentru producție.

De ce agenții ADK cu competențe sunt importanți pentru echipele de software moderne

Explozia inteligenței artificiale în dezvoltarea de software a împins echipele să caute modalități de a încapsula expertiza și fluxurile de lucru în unități reutilizabile și compozabile.ADK-urile răspund acestei nevoi permițându-vă să împachetați comportamentul, regulile de domeniu și instrumentele în agenți care pot fi reutilizați în mai multe proiecte, echipe și chiar produse.

În centrul acestei abordări se află abilitățile agenților, care sunt module de cunoștințe autonome pe care un agent le poate încărca la cerere. În loc să arunce fiecare îndrumare și regulă într-o singură solicitare masivă, abilitățile aplică o dezvăluirea progresivă arhitectură: instrucțiunile, resursele și scripturile sunt dezvăluite doar atunci când este nevoie, ceea ce menține un context minimalist și performanță ridicată chiar și atunci când aveți sute de competențe instalate.

Această eficiență este crucială într-o lume în care bugetele de tokenuri, latența și costurile de calcul reprezintă constrângeri reale.Încărcarea fiecărui ghid de stil, specificație API și regulă de operare într-un singur prompt nu este scalabilă. Abilitățile vă permit să păstrați cunoștințele „reci” pe disc (sau în depozite) și să le introduceți în contextul agentului doar atunci când o anumită capacitate este relevantă.

Companii precum Q2BSTUDIO utilizează acest model pentru a construi sisteme de inteligență artificială personalizate pentru întreprinderi., împletind business intelligence, cunoștințe de domeniu și practici moderne de securitate cibernetică. În acest fel, agenții nu sunt doar capabili și conștienți de context, ci și protejați împotriva vectorilor de atac comuni din peisajul amenințărilor actuale.

Înțelegerea arhitecturii de dezvăluire progresivă a competențelor ADK

Abilitățile de tip ADK urmează de obicei un model de încărcare pe trei niveluri care menține contextul agentului concentrat. permițând în același timp specializarea profundă a domeniului ori de câte ori este necesar. Puteți să vă gândiți la el ca la o conductă etapizată pentru cunoștințe:

Nivelul 1 – DescoperireCând începe o conversație, agentul vede doar un catalog de abilități disponibile: numele și descrierile lor scurte. Încă nu este încărcat nimic complex. Acest lucru este suficient pentru ca agentul să decidă ce abilitate ar putea fi relevantă pentru solicitarea utilizatorului.

Nivelul 2 – Instrucțiuniodată ce o abilitate este considerată potrivită, agentul îi citește SKILL.md sau un fișier cu instrucțiuni echivalent. Acest document oferă îndrumări detaliate, modele și reguli pentru acea competență și este introdus în contextul modelului doar atunci când este necesar.

Nivelul 3 – Resurseresursele voluminoase, cum ar fi scheme mari, liste de verificare lungi, scripturi sau documente extinse, rămân în sistemul de fișiere ca referințe

și sunt preluate la cerere numai dacă abilitatea respectivă indică în mod specific către ele. Agentul citește sau execută aceste resurse după cum este necesar, în loc să le aibă mereu în promptul principal.

Acest model este esențial pentru framework-uri precum AgentKit 2.0 și setări bazate pe Antigravity.Puteți instala abilități direct în agenți compatibili (Claude Code, Cursor, Antigravity și alții) folosind comenzi precum npx add-skill vercel-labs/agent-skills, care clonează depozitele de competențe, le plasează în directoarele corecte și le fac detectabile fără a edita manual solicitările.

Modele de proiectare pentru structurarea abilităților ADK

Scrierea unei noi competențe de la zero ține adesea mai puțin de instrumente și mai mult de designul de conținut.Specificația ADK vă spune de obicei cum să structurați pachetul (frontmatter în YAML, references/, assets/, scripts/ directoare și așa mai departe), dar nu vă spune cum să scrieți instrucțiunile propriu-zise. Aici intervin modelele de design reutilizabile.

Practicienii care au dezvoltat zeci de abilități raportează că o serie de modele structurale acoperă majoritatea cazurilor de utilizare din lumea reală.Cinci dintre cele mai utile sunt:

Înfășurător de scule: acest model încapsulează convențiile și cele mai bune practici ale unei anumite biblioteci sau platforme într-o competență. Instrucțiunile descriu regulile de urmat, în timp ce references/ conține documentația oficială. De obicei, nu există șabloane sau scripturi; ideea este de a oferi agentului un „model mental” al unui instrument precum FastAPI, React sau Postgres.

Generatoraici, abilitatea produce un rezultat structurat consistent folosind șabloane stocate în assets/Exemplele includ documentația API, mesajele de validare, rapoartele tehnice sau jurnalele de modificări. Instrucțiunile definesc regulile de calitate, în timp ce șabloanele definesc forma rezultatului, astfel încât să obțineți formate repetitive cu conținut diferit de fiecare dată.

Referentacest model separă ceea ce a verifica de la cum pentru a o verifica. Un fișier de verificare în references/ stabilește elementele de verificat (securitate, stil, arhitectură etc.), în timp ce instrucțiunile definesc protocolul de revizuire: gruparea constatărilor după severitate, solicitarea justificării, sugerarea corecțiilor. Schimbați fișierul listei de verificare și obțineți practic un recenzent complet nou, fără a rescrie competența.

Interviu (Inversiune)În loc să acționeze imediat, abilitatea intervievează mai întâi utilizatorul prin întrebări structurate în faze, cu porți de genul „nu începeți construcția până când toate fazele nu sunt finalizate”. Acest lucru împiedică agentul să facă presupuneri mari și îl obligă să clarifice obiectivele și constrângerile înainte de a genera rezultate detaliate.

ConductăAcest model codifică fluxuri de lucru în mai mulți pași cu porți explicite între pași, cum ar fi „nu treceți la pasul 3 până când utilizatorul nu confirmă”. Este mai complex decât celelalte, dar este singurul care împiedică în mod fiabil agenții să sară peste etapele de validare. Abilitățile de gestionare a fluxului pot încorpora pași de revizuire, ieșiri de generator sau faze de interviu în cadrul aceluiași flux.

Abilitățile practice de la Google, Vercel și Supabase combină adesea două sau mai multe dintre aceste modele per abilitate.De exemplu, o competență de guvernanță ar putea intervieva utilizatorul cu privire la constrângerile proiectului, apoi ar putea rula o analiză folosind liste de verificare distincte și ar putea genera un raport de guvernanță cu un generator bazat pe șabloane.

De la agenți singulari la sisteme multi-agent cu ADK

După ce înțelegeți cum abilitățile îmbină cunoștințele cu pachete, următorul pas este să vedeți cum agenții ADK orchestrează aceste cunoștințe în fluxuri de lucru.Laboratoarele de codare ADK oficiale de la Google sunt o referință excelentă: te ghidează de la un singur agent de bază prin instrumente, memorie și coordonare multi-agent, toate în caiete Colab practice.

Călătoria începe cu primul tău agent construit cu un RunnerÎn laboratorul de codare, definiți un day_trip_agent a cărui misiune este de a crea un itinerariu de călătorie de o zi care să respecte preferințele și bugetul utilizatorilor. Trei componente ilustrează modelul general de interacțiune ADK:

Agentul este „creierul” definit de instrucțiunile sale, modelul subiacent (de exemplu, Gemini) și instrumentele pe care le poate apela. În exemplu, agentul are instrucțiuni detaliate, plus acces la Căutarea Google.

Sesiunea funcționează ca un depozit de memorie conversațională, păstrând istoricul complet al mesajelor utilizatorilor și al răspunsurilor agenților. Reutilizarea aceluiași obiect de sesiune menține contextul activ de-a lungul turelor.

Runner coordonează execuția prin preluarea unui agent și a unei sesiuni, procesarea fiecărei interogări a utilizatorului și returnarea răspunsului

în timp ce actualizezi sesiunea pe parcursAjutoare de utilități precum run_agent_query() încapsulează această buclă astfel încât să poți declanșa cu ușurință agenți prin teste sau integrări cu interfața utilizator.

Citind acest prim exemplu, se vede cum instrucțiunile bune se conectează direct la solicitările utilizatorului.O interogare de testare ar putea solicita o excursie de o zi „prietenoasă cu buget” și „relaxantă”, iar deoarece instrucțiunile subliniază importanța respectării costurilor, agentul include în mod fiabil considerații bugetare în răspunsurile sale.

Conectarea instrumentelor personalizate la agenții ADK

Agenții devin cu adevărat puternici odată ce pot apela propriile API-uri și servicii interne, în loc să apeleze doar instrumente generice precum căutarea web.ADK-urile simplifică acest lucru transformând funcțiile normale în instrumente bazate pe semnăturile și șirurile de documentație ale acestora.

În laboratoarele de codare, un exemplu simplu folosește o funcție Python care apelează o API pentru vreme în timp real.O funcție precum get_live_weather_forecast(location: str) preia date actuale de la un serviciu meteo public și returnează informații structurate, de exemplu, temperatura și condițiile dintr-un dicționar.

Partea crucială este docstring-ulADK analizează șirul de documentație al funcției pentru a înțelege ce face instrumentul, ce argumente acceptă și ce returnează. Modelul de limbaj citește acea descriere și decide când și cum să apeleze instrumentul în timpul raționamentului.

Pentru a conecta instrumentul la un agent, pur și simplu îl transmiteți ca parte a listei de instrumente în timpul inițializării., De exemplu, tools=[get_live_weather_forecast]Instrucțiunile weather_agent poate apoi spune explicit modelului să apeleze acest instrument înainte de a propune activități în aer liber.

În timpul testelor, solicitări precum „Vreau să fac drumeții lângă Lacul Tahoe, cum e vremea?” declanșează direct instrumentul., deoarece misiunea și instrucțiunile agentului insistă asupra utilizării prognozei live înainte de a recomanda un plan. Acest model se generalizează la propriile API-uri: inventar, prețuri, CRM, analize sau orice backend pe care îl puteți încapsula ca funcție.

Modelul Agent-ca-Instrument: construirea de echipe de specialiști

În loc să înghesui fiecare responsabilitate într-un singur agent monolitic, ADK te încurajează să creezi o echipă de experți mai mici.Cheia este modelul Agent-as-a-Tool, în care un agent poate apela un alt agent ca și cum ar fi doar un alt instrument.

O demonstrație tipică în laboratoarele de codare construiește un sistem de planificare a călătoriilor pe mai multe niveluri:

Agenți de specialitate gestionează domenii înguste: a food_critic_agent care sugerează doar restaurante, un db_agent care interoghează datele hotelului și a concierge_agent care acționează ca un asistent politicos pentru interacțiunile cu utilizatorii.

Însuși concierge-ul îl tratează pe criticul culinar ca pe un instrument, delegând selecția restaurantului criticului și apoi reformuland rezultatul într-un limbaj mai ușor de utilizat.

În vârf se află un agent orchestrator, cum ar fi trip_data_concierge_agent, a cărui sarcină este de a înțelege solicitarea generală a utilizatorului și de a decide ce specialist să invoce prin funcții wrapper dedicate, cum ar fi call_db_agent și call_concierge_agent.

Când executați o interogare de genul „găsește-mi un hotel și un restaurant în apropiere”, jurnalele din instrumente arată un lanț de delegare: orchestratorul apelează agentul bazei de date pentru hoteluri, apoi agentul concierge pentru sfaturi despre restaurante, iar concierge-ul, la rândul său, apelează la criticul culinar. Fiecare agent rămâne concentrat pe propriul domeniu, în timp ce orchestratorul se ocupă de compoziție.

Această abordare se aliniază îndeaproape cu modul în care AgentKit 2.0 își structurează cei 16 agenți specializați. în frontend, backend, securitate, testare și infrastructură. Fiecare agent este livrat cu competențe specifice domeniului (cele mai bune practici React, configurarea bazelor de date, audituri de securitate, fluxuri de implementare și multe altele), iar un orchestrator le compune pentru a atinge obiective mai ample, cum ar fi „construirea și implementarea unui modul de autentificare a utilizatorilor”.

Oferirea de memorie agenților: sesiuni și planificare adaptivă

Pentru a se simți cu adevărat inteligent, un agent trebuie să-și amintească contextul pe parcursul mai multor etape., adaptând planurile ca răspuns la feedback, în loc să trateze fiecare mesaj ca pe un nou început. Aici intervin sesiunile și gestionarea memoriei.

În laboratorul de cod ADK, un agent de planificare a excursiilor de mai multe zile ilustrează diferența dintre memoria corectă și cea defectă.O funcție precum create_multi_day_trip_agent() stabilește un agent ale cărui instrucțiuni pun accent pe planificarea graduală, memorarea alegerilor și răspunsul atent la corecții.

O demonstrație adaptivă reutilizează un singur obiect de sesiune pentru mai multe ture:

Rotiți 1utilizatorul solicită un plan de excursie de două zile, iar agentul propune activități pentru ziua 1.

Rotiți 2Utilizatorul spune că nu-i plac castelele. Deoarece sesiunea conține itinerariul anterior, agentul știe ce parte să ajusteze și propune o alternativă pentru segmentul respectiv, păstrând în același timp celelalte detalii intacte.

Rotiți 3Utilizatorul confirmă modificarea și solicită următorii pași, astfel încât agentul continuă cu planificarea zilei 2, conștient de contextul anterior.

O demonstrație contrastantă de „eșec” creează o sesiune nouă pentru fiecare rundăAgentul răspunde corect la prima întrebare, dar când utilizatorul face referire ulterior la „ziua 2”, noua sesiune nu are istoric, iar agentul are practic amnezie, incapabil să lege solicitarea de planul anterior.

Concluzia este simplă, dar fundamentală: conversațiile continue necesită sesiuni continue.Pentru sistemele de producție, trebuie să persisteți și să recuperați starea sesiunii în apeluri API, dispozitive și uneori chiar utilizatori, mai ales când fluxurile de lucru se întind pe zile sau săptămâni.

Agentul Router: direcționarea solicitărilor către specialistul potrivit

Pe măsură ce catalogul tău de agenți și competențe crește, ai nevoie de un mecanism pentru a trimite fiecare solicitare primită expertului potrivit.Aceasta este sarcina unui agent Router, o componentă mică, dar crucială în arhitecturile multi-agent.

Principala responsabilitate a unui router este clasificarea, mai degrabă decât răspunsul direct la întrebările utilizatorului.Instrucțiunile sale îi spun de obicei să citească o interogare a utilizatorului și să afișeze doar numele agentului (sau fluxului de lucru) cel mai potrivit pentru jobul respectiv.

În secțiunile multi-agent ale laboratorului de codare, routerul alege între diverși agenți de domeniu cum ar fi un planificator de excursii de o zi, un agent gastronomic sau un agent de transport. Funcția de execuție solicită mai întâi routerului o rută, apoi folosește o logică condițională simplă pentru a invoca specialistul corect pe baza răspunsului routerului.

Acest model se aliniază cu modul în care este descrisă orchestrarea multi-agent în AgentKit 2.0Acolo, un agent orchestrator primește un obiectiv de nivel înalt, deleagă proiectarea schemei către un agent de baze de date, scheletarea formularului către un agent frontend, execută o revizuire de securitate, apoi predă sarcina către un agent de implementare și, în final, agregă diferențele și adresele URL într-un rezumat coerent pentru utilizator.

SequentialAgent: orchestrarea fluxurilor de lucru ordonate în mai mulți pași

Unele sarcini se împart în mod natural în etape ordonate, unde rezultatul unei etape se alimentează în următoarea.De exemplu, „găsește cel mai bun sushi din Palo Alto, apoi spune-mi cum ajung acolo” necesită în mod evident mai întâi o etapă de descoperire și apoi o etapă de navigare.

ADK-urile oferă un agent specializat pentru fluxul de lucru, adesea numit SequentialAgent, pentru a gestiona aceste lanțuri în mod curatÎn loc să scrieți logica de orchestrare manuală, definiți o listă de subagenți și chei de stare partajate, iar framework-ul se ocupă de secvențiere și transmiterea datelor.

În exemplul de codelab, agentul foodie este refactorizat pentru a emite rezultatul său sub un output_key precum "destination"Instrucțiunile agentului de transport includ apoi un provizoriu, cum ar fi {destination} pe care ADK-ul o completează automat cu valoarea stocată din starea partajată.

Agentul fluxului de lucru general, să zicem find_and_navigate_agent, este configurat ca un SequentialAgent cu subagenți într-o ordine fixă precum [foodie_agent, transportation_agent]Când este invocat, se comportă ca un singur agent din perspectiva apelantului, coordonând intern cei doi pași și gestionând starea partajată.

Această abordare simplifică drastic codul de orchestrareArborii condiționali și conexiunile de date ad-hoc dispar, fiind înlocuite de definiții declarative ale subagenților și cheilor. De asemenea, acest lucru facilitează testarea și extinderea fluxurilor de lucru, deoarece fiecare subagent rămâne modular și poate fi reutilizat în alte lanțuri.

LoopAgent: rafinare iterativă cu planificator, critic și rafinator

Multe probleme din lumea reală beneficiază de îmbunătățiri iterative, mai degrabă decât de răspunsuri dintr-o singură încercareGândește-te la elaborarea unui plan, criticarea lui, rafinarea lui și repetarea acestuia până când atingi un anumit standard de calitate. Fluxurile de lucru în buclă răspund acestei nevoi.

ADK-urile captează acest model cu un LoopAgent, un agent de flux de lucru care rulează în mod repetat o secvență de subagenți până când este declanșată o condiție de ieșireAcest lucru este ideal pentru agenții „perfecționiști” care trebuie să se autoevalueze și să își corecteze propriile rezultate pe baza unor criterii formale.

O configurație clasică de buclă include trei roluriun agent planificator care produce un plan inițial, un agent critic care evaluează planul în funcție de constrângeri și un agent de rafinare care editează sau rescrie planul pe baza feedback-ului criticului.

Definiția buclei conectează aceste roluri într-un ciclu cu un număr maxim de iterații pentru a evita buclele infinite, de exemplu max_iterations=3La fiecare trecere, criticul decide dacă planul este acceptabil; dacă nu, rafinatorul generează o versiune revizuită, iar bucla continuă.

Ieșirea din buclă implică de obicei un instrument specializat, Cum ar fi exit_loop, pe care rafinatorul îl apelează atunci când evaluarea criticului devine pozitivă. În acel moment, planul final validat este returnat utilizatorului sau transmis agenților din aval.

Acest model este util în special în domenii precum proiectarea arhitecturii, revizuirea securității sau crearea de conținut., unde răspunsurile rapide sunt rareori suficient de bune, iar ciclurile de critică încorporate pot crește substanțial calitatea medie.

ParallelAgent: accelerarea lucrului cu subagenți concurenți

Când diferite părți ale unei cereri a utilizatorului sunt independente, rularea lor secvențială pierde timp.De exemplu, „găsește un muzeu, un concert și un restaurant grozav pentru diseară” nu necesită ca fiecare căutare să le aștepte pe celelalte.

Fluxurile de lucru paralele rezolvă acest lucru prin lansarea mai multor specialiști în același timpÎn ADK-uri, un ParallelAgent Rulează concurent o listă de subagenți, apoi îmbină rezultatele acestora printr-o stare partajată și o etapă finală de sinteză.

O configurație tipică definește trei agenți specifici domeniului precum museum_finder, concert_finder și restaurant_finder, fiecare cu ale lui output_key în starea partajată. Agentul paralel execută toate trei în paralel, astfel încât timpul total este apropiat de cel al celui mai lent agent individual, mai degrabă decât de suma tuturor trei.

După ce acești agenți se termină, un agent de sinteză citește substituenți precum {museum_result}, {concert_result} și {restaurant_result} din starea partajată, apoi elaborează un răspuns coerent și ușor de utilizat, combinând toate cele trei canale de informații.

Acest model reflectă beneficiile „execuției paralele” descrise în fluxurile de orchestrare ale AgentKit 2.0.Subagenții independenți își livrează munca simultan, izolați de propriile abilități, astfel încât să nu contamineze reciproc contextul, în timp ce orchestratorul menține toleranța generală la erori și auditabilitatea.

AgentKit 2.0, competențe comunitare și orchestrare modulară a agenților

AgentKit 2.0 prezintă cum arată în practică un ecosistem matur de competențe și agenți ADKVine cu 16 agenți specializați care acoperă frontend, backend, securitate, testare și infrastructură, fiecare fiind pre-echipat cu abilități de domeniu, astfel încât să poată opera autonom pe subtask-uri complexe.

Peste 40 de competențe axate pe domeniu sunt incluse în pachet, acoperind domenii recurente precum fluxurile de autentificare, configurarea bazelor de date, implementările în timp real și monitorizarea performanței. Acestea sunt exact părțile stivelor moderne care necesită de obicei cel mai mult timp de inginerie.

Pe lângă acestea, comunitatea extinsă contribuie cu peste 1,000 de competențe întreținute.Împreună cu framework-uri precum Agent MD, aceste competențe permit agenților să interpreteze reguli operaționale detaliate și să le aplice în mod consecvent în baze de cod mari și complexe și implementări multi-strat.

Filosofia de bază este dezvoltarea modulară, condusă de agențiÎn loc ca un singur mega-agent să încerce să facă totul, aduni o echipă de specialiști restrânși și îi orchestrezi. Fiecare agent încarcă doar abilitățile de care are nevoie pentru domeniul său, respectând același model de dezvăluire progresivă utilizat la nivel de competență.

Fluxurile de orchestrare tipice urmează un model clarUn agent orchestrator primește un obiectiv de nivel superior, predă proiectarea bazei de date unui agent DB (folosind o abilitate de schemă), trimite scheletarea UI către un agent frontend (cu abilități de bune practici React), rulează un agent de securitate pentru audituri și, în final, solicită unui agent de implementare să trimită datele către o infrastructură precum InForge. Pe parcursul procesului, orchestratorul colectează rezultate, repetă pașii care eșuează atunci când este necesar și înregistrează interacțiunile pentru audit.

Această arhitectură nu numai că îmbunătățește performanța și fiabilitatea, dar se scalează și pe măsură ce abilitățile comunității cresc în mii.Nu mai aveți nevoie de un singur agent „știutor atotcuprinzător”; în schimb, vă bazați pe o echipă compusă, în care fiecare membru își menține perspicaceitatea în cadrul propriilor abilități.

Practic: rularea agenților web ADK local pe macOS, Linux și Windows

Toate aceste concepte devin mult mai clare atunci când pornești un agent real bazat pe ADK pe propria mașină.Configurarea ADK Web furnizată în exemplele de repozitorii vă permite să rulați local un agent de planificare a excursiilor de o zi cu o interfață web simplă.

Înainte de a începe, veți avea nevoie de câteva condiții prealabilePython 3.8 sau o versiune ulterioară (se recomandă 3.9+), o cheie API Google AI Studio și o conexiune la internet. Pentru versiunile recente de Python, puteți instala google-adk==1.5.0, în timp ce utilizatorii Python 3.8 ar trebui să utilizeze o versiune compatibilă precum google-adk==0.3.0.

Fluxul de bază pentru macOS și Linux începe prin clonarea depozitului și configurarea unui mediu virtualDupă ce a alergat git clone și cd în proiect, puteți fie să executați un script automat, cum ar fi ./setup_venv.sh (după acordarea permisiunilor de execuție) sau creați și activați manual un mediu virtual cu python3 -m venv .adk_env și source .adk_env/bin/activate, urmat de pip install -r requirements.txt.

Un pas important este setarea variabilelor de mediu prin intermediul unui .env de fișier în agent/ directorCreați acest fișier, îl deschideți într-un editor și adăugați linii precum GOOGLE_GENAI_USE_VERTEXAI=FALSE și GOOGLE_API_KEY=your_actual_api_key_here, înlocuind provizoriul cu cheia API reală. Omiterea acestui pas va împiedica agentul să apeleze modelele subiacente.

Odată ce mediul este activ, pur și simplu rulați adk web pentru a porni interfața web localăTerminalul afișează o adresă URL, de obicei http://localhost:8000, unde puteți deschide browserul, selectați agent opțiune dintr-un meniu derulant și începeți să discutați cu planificatorul de excursii de o zi. Când ați terminat, dezactivați mediul virtual cu deactivate comanda.

Utilizatorii de Windows urmează un model foarte similar folosind Command Prompt sau PowerShellDupă clonarea depozitului și schimbarea în acesta, puteți rula un script convenabil, cum ar fi setup_venv.bat sau creați manual un venv cu python -m venv .adk_env și activați-l prin .adk_env\Scripts\activate în Linia de comandă sau .adk_env\Scripts\Activate.ps1 în PowerShell.

.env fișierul de pe Windows se află în același loc agent\ director, creată de exemplu cu type nul > agent\.env și editate folosind Notepad. Apoi adăugați aceleași perechi cheie-valoare pentru a configura accesul Google AI. Dacă întâmpinați probleme de politică de execuție în PowerShell, o comandă precum Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser le rezolvă pentru scripturile locale.

După instalarea dependențelor și configurarea variabilelor de mediu, rularea adk web vă oferă aceeași experiență de agent bazată pe browser pe Windows ca și pe macOS sau Linux, cu posibilitatea de a dezactiva mediul în orice moment folosind deactivate.

Combinând toate elementele, agenții ADK cu abilități, dezvăluire progresivă și orchestrare multi-agent oferă o modalitate puternică de a construi sisteme de inteligență artificială scalabile, sigure și extrem de specializate. care se aliniază cu fluxurile de lucru software reale. Prin structurarea abilităților cu modele de design solide, conectarea agenților la propriile instrumente și API-uri, valorificarea agenților Router, Secvențiali, Bucle și Paraleli și rularea configurărilor local sau în cloud, echipele pot trece de la simpli chatbots la colaboratori robusti bazați pe inteligență artificială, care lucrează alături de dezvoltatori, analiști și operatori în munca de zi cu zi.