Hvordan A2A fungerer i Zero: Agenter, chatter og overleveringer

Hva er A2A i Zero?

Zero A2A er en praktisk form for agent-til-agent-kommunikasjon i produktet. Det lar én agent åpne flere isolerte chatter, lar en koordinator delegere avgrenset arbeid til spesialistagenter, og lar deg skrive @ i chat-komponisten for å hente en eksisterende chat inn i en sammenligning, overlevering eller avgjørelse.

Dette er nyttig når en oppgave er for bred, støyende eller risikabel for én lang samtale. I stedet for å be én agent holde alle tester, kilder og avgjørelser i samme kontekst, gir du hvert arbeid et tydelig hjem og henter kun tilbake det beviset som er relevant.

Tre måter A2A fungerer i Zero

Hva du vil gjøre	Bruk denne oppsettet	Et godt første scenario
Gjenta én metode med ren kontekst	Én agent, flere chatter	Test registrering, fakturering, tillatelser og mobil separat
Gi deler av en oppgave til ulike eksperter	Én koordinator, flere spesialistagenter eller subagenter	Del en lansering mellom research, nettleser-QA, skriving og publisering
Gjenbruk eksisterende arbeid	@ en annen chat i komponisten	Sammenlign to QA-rapporter eller overfør research til en skriveoppgave

Tre produktobjekter ligger bak disse mønstrene:

• En agent er den gjenbrukbare arbeideren. Den eier instruksjoner, arbeidsflyter, koblinger, tillatelser, tone, rolle og modellvalg.
• En chat er én isolert samtale med en agent. Den holder en test, gjennomgang eller produksjonsoppgave i sin egen kontekst.
• En run er én aktiv respons i en chat. Runs utfører arbeidet og kan vente hvis arbeidsområdet når sin samtidighetsgrense.

Det viktige poenget er enkelt: en ny underchat arver ikke hele historikken fra kontrollchatten. Den første meldingen bør inneholde alt den trenger for å utføre oppgaven.

A2A, flere chatter, subagenter, arbeidsflyter og automatiseringer

Disse begrepene løser ulike problemer. Bruk det minste oppsettet som gir deg den grensen du trenger.

Produktmønster	Hva det endrer	Best brukt til
A2A i Zero	Hvordan agenter og chatter koordinerer arbeid	Delegering, sammenligning, overleveringer og endelig syntese
Flere chatter under én agent	Kontekst, mens instruksjoner og tillatelser forblir de samme	Parallell testing, lokaliseringskontroller, research-batcher og modellevalueringer
Spesialistagenter eller subagenter	Rolle, instruksjoner, modell, verktøy eller tillatelser	Research, QA, skriving, dataanalyse og kontrollert publisering
Arbeidsflyt	En lagret prosedyre en agent kan gjenta	En stabil sjekkliste eller flertrinnsmetode
Automatisering	En trigger som starter en arbeidsflyt med en agent	Planlagte rapporter, hendelsesstyrt triage og gjentakende kontroller

En nyttig tommelfingerregel: del opp i chatter når metoden er den samme, del opp i spesialistagenter når metode eller tilgang endres, og bruk en arbeidsflyt når prosedyren skal gjentas på samme måte.

1. Én agent åpner flere rene chatter

Du skal til å lansere. Registrering, fakturering, tillatelser og mobil trenger alle en siste gjennomgang. Å legge alle sjekker i én lang chat virker praktisk, men tilstand kan lekke fra én reise til neste. Et faktureringsoppgradering kan endre kontoen før tillatelsestesten starter.

Bruk én chat per reise i stedet.

Ett felles oppdrag, fire isolerte sjekker, deretter én endelig rapport.

Vi gjenskapte dette oppsettet i staging-produktet 25. august 2026. Den samme Zero-agenten åpnet fire reelle chatter for onboarding, fakturering, tillatelser for teammedlemmer og mobil- samt lokaletest.

Hver reise har sin egen chat, så bevisene er enkle å inspisere.

Prøv denne prompten:

Gå gjennom denne staging-lanseringen som fire separate oppgaver. Åpne én chat for registrering og onboarding, én for faktureringsoppgradering, én for invitasjon av teammedlem og avviste tillatelser, og én for mobil- og lokalitetssjekker. Bruk samme gjennomgangsagent for hver chat. Hver arbeider må returnere testet URL, kontorolle, nummererte steg, skjermbilder, bestått/ikke bestått-status og nøyaktige reproduksjonstrinn. Ta resultatene tilbake hit og grupper dupliserte blokkere.

Dette mønsteret fungerer også for:

• Én chat per nettleser eller skjermstørrelse
• Én chat per lokale eller kontorolle
• Én chat per pull request eller feature flag
• Én chat per anmelder, med funn holdt adskilt til slutt
• Én chat per kundeintervjubatch eller research-kildesett
• Én chat per modell når du vil sammenligne utdata rettferdig

Hva går vanligvis galt? Oppdraget er for kort. “Sjekk fakturering” lar arbeideren gjette på konto, build, forventet resultat og bevisformat. Gi hver chat samme sjekkliste og en separat testkonto når flyten endrer delt data.

2. Bruk @ for å hente en annen chat inn i oppgaven

Noen ganger finnes det nyttige arbeidet allerede. En research-chat har kundesitater. En QA-chat har skjermbilder. En annen gjennomgang kommer til en annen konklusjon. Du trenger ikke kopiere og lime inn alt.

Klikk i komponisten og skriv @. Zero åpner en liste over dine eksisterende chatter.

Begynn å skrive en tittel for å begrense listen, og velg deretter chatten du trenger.

Den valgte chatten vises som en klikkbar oransje brikke.

Brikken peker til den eksakte onboarding-chatten. Svaret skrives i nåværende chat.

Legg så til et verb. Fortell Zero hva som skal gjøres med den chatten:

• “Sammenlign @Onboarding QA med denne faktureringsgjennomgangen.”
• “Fortsett fra @Customer research batch 2 og skriv anbefalingen her.”
• “Utfordre den mest risikofylte konklusjonen i @Security review.”
• “Gjør skjermbildene i @Mobile walkthrough om til en feilrapport.”
• “Trekk ut alle uløste spørsmål fra @Launch research.”

Skriv @, velg chatten, og si hva du vil Zero skal gjøre med den.

Henvisningen er en adresse, ikke en vag tekstetikett. Den peker Zero til valgt chat uten å lime inn hele samtalen i komponisten. Det holder meldingen lesbar, men instruksjonen din må fortsatt ha en tydelig handling. “Bruk denne” er svakt. “Sammenlign de mislykkede stegene og ranger felles blokkere” er tydelig.

3. Gi ulike deler til spesialistagenter eller subagenter

Bruk flere chatter når du vil ha rene kopier av samme arbeider. Bruk spesialistagenter når oppgaven krever ulike instruksjoner, verktøy, modeller eller tillatelsesgrenser. En spesialistagent som gjør en avgrenset oppgave for en koordinator kalles ofte en subagent.

En produktlansering er et godt eksempel. Research Scout kan verifisere bevisene. Browser QA kan sjekke det lanserte produktet. Launch Writer kan utarbeide siden. Publishing Operator kan lage CMS-kladden etter at påstandene er godkjent.

Staging-arbeidsområdet har én kjerneagent og fire navngitte spesialister, hver klar for en avgrenset oppgave.

Koordinatoren eier resultatet. Spesialistene returnerer bevis og artefakter, så skriver én eier det endelige resultatet.

Her er et praktisk lanseringsoppdrag:

Koordiner en lanseringspakke for Feature X. Be Research Scout verifisere kundebevis og konkurrentpåstander. Be Browser QA reprodusere alle produktpåstander i staging og legge ved skjermbilder. Be Launch Writer utarbeide siden først etter at bevisene er mottatt. Publishing Operator kan lage CMS-kladden, men må ikke publisere den. Rapporter manglende bevis og motstridende påstander i denne chatten.

Verdien kommer fra reelle grenser. En research-agent kan forbli skrivebeskyttet. En publiseringsagent kan ha kladdetilgang uten publiseringstillatelse. En QA-agent kan følge en fast nettlesersjekkliste hver gang. Zeros tillatelseskontroller hjelper med å holde grensene smale.

Ikke opprett spesialister bare for å gjøre sidepanelet travlere. Opprett én når rollen endrer hvordan arbeidet utføres.

4. La uavhengige anmeldere være uenige, bruk deretter en dommer

To gjennomganger er kun nyttige når den andre anmelderen ikke kopierer den første. Åpne rene chatter, gi begge anmeldere samme bevis, og hold deres første rapporter adskilt.

Start deretter en dommerchat og referer til begge rapportene i én prompt.

Én prompt kan referere til to reelle QA-chatter og be Zero finne felles blokkere.

For eksempel:

Sammenlign @Onboarding QA med @Billing QA. List opp blokkere funnet av begge chatter, problemer funnet av kun én chat, og bevis som fortsatt mangler. Bestem deretter om lanseringen bør gjennomføres. Siter skjermbildet eller steget som støtter hver blokker.

Dette mønsteret fungerer for designgjennomgang, sikkerhetsgjennomgang, leverandørvalg, arkitekturvalg, kontraktsgjennomgang og modellsammenligning. Definer vurderingskriteriene før rapportene kommer. Ellers kan dommeren belønne den mest selvsikre teksten i stedet for det sterkeste beviset.

5. Overlever arbeid fra én agent til neste

Noen oppgaver bør ikke kjøres samtidig. Research må fullføres før utkastet. Utkastet må fullføres før QA. QA må fullføres før publisering.

Behandle hver overlevering som en kort leveringslapp:

1. Navngi mottakende agent eller chat.
2. Legg ved eller referer til artefaktet.
3. Oppgi akseptkriteriene.
4. Si hvor mottakeren skal rapportere tilbake.

“Fortell skribenten hva du fant” er vanskelig å verifisere. Dette er bedre:

Send godkjent research-sammendrag til Launch Writer. Utkastet må kun bruke verifiserte påstander, beholde godkjent terminologi og merke manglende bevis med [EVIDENCE NEEDED]. Returner utkastlenken og uløste spørsmål til denne chatten.

@-chatbrikken er nyttig her fordi den gir neste arbeider en presis kilde. For oppgaver med mange filer, send også artefaktlenken. Koordinatoren trenger status, avgjørelser og endelig pakke. Den trenger ikke alle kladdenotater kopiert inn i sin egen kontekst.

Hvordan deler AI-agenter kontekst i Zero?

Agenter i Zero trenger ikke én stor felles samtale. Kontekst flyttes gjennom eksplisitte oppdrag, @ chat-henvisninger, artefaktlenker og returnerte sammendrag. Hver arbeider mottar minimum nyttig kontekst, utfører en avgrenset oppgave og sender bevis eller avgjørelse tilbake til koordinatoren.

Denne tilnærmingen unngår to vanlige multi-agent-problemer. For det første fyller ikke irrelevant historikk opp arbeiderens kontekst. For det andre kan koordinatoren se nøyaktig hvilken kilde eller chat som støtter en påstand.

Bruk disse fire mønstrene for kontekstdeling:

1. Selvstendig oppdrag: best for en ny underchat som må starte rent.
2. @ chat-henvisning: best når en eksisterende samtale er kilden.
3. Artefaktlenke: best for dokumenter, skjermbilder, datasett og kodeendringer.
4. Strukturert retur: best når flere arbeidere må rapportere i samme format.

Ikke anta at en underchat allerede kjenner kontrollchattens avgjørelser. Hvis et begrep, begrensning, konto, datoperiode eller utdataformat er viktig, ta det med i første melding.

Flere A2A- og multi-agent arbeidsflytscenarier

Scenario	Hvordan splitte det	Hva som kommer tilbake
Lanseringsgjennomgang	Samme agent, én chat per brukerreise	Skjermbilder, bestått/ikke bestått-sjekker og felles blokkere
Lokaliserings-QA	Samme agent, én chat per lokale	Ødelagte strenger, layoutproblemer og lokale-spesifikke skjermbilder
Nettleser- og enhetstesting	Samme agent, én chat per nettleser eller visningsområde	Et sammenlignbart kompatibilitetsmatrise med bevis
Pull request-gjennomgang	Samme agent, én chat per PR eller gjennomgangsvinkel	Feil, risikonotater og linjenivå-anbefalinger
Kundereasearch	Samme agent, én chat per intervjubatch	Sitater, mønstre, innvendinger og kildehenvisninger
Hendelsesrespons	Koordinator pluss app-, API-, deploy- og kundeagent	Én tidslinje med avtalte og motstridende punkter
Innholdsproduksjon	Research-, skrive-, design-, QA- og publiseringsagenter	Et gjennomgått utkast og en kontrollert publiseringsoverlevering
Kundestøtte-triage	Koordinator pluss konto-, produkt-, fakturerings- og svaragenter	Rotårsak, prioritet, eier og et utkast til svar
Dataanalyse-QA	Analytikeragent pluss en uavhengig anmelder	Kontrollerte koblinger, nevner, tidssoner og antakelser
Modellsammenligning	Rene chatter med samme oppdrag og ulike modeller	Nøyaktighet, kostnad, latenstid og formatskår

Riktig oppdeling skaper en nyttig grense. Det kan isolere kontekst, beskytte en tillatelse, holde gjennomganger uavhengige eller la ferdig arbeid kjøre samtidig.

Når bør du bruke én chat, flere chatter eller flere agenter?

Bruk én chat når hvert neste steg avhenger av svaret rett før. En sekvensiell feilsøkingsøkt er et godt eksempel.

Bruk flere chatter under én agent når instruksjonene er de samme, men du trenger ren kontekst eller uavhengige bevis. Dette er vanligvis det beste utgangspunktet for testing, research-batcher og rettferdige sammenligninger.

Bruk flere spesialistagenter når hver del krever ulik ekspertise, koblinger, tillatelser eller modeller. Gi én koordinator ansvar for endelig avgjørelse.

Bruk en arbeidsflyt når prosedyren skal være repeterbar. Legg til en automatisering kun når prosedyren også trenger en tidsplan eller hendelsestrigger. Zero dokumenterer disse to byggeklossene separat: arbeidsflyter definerer metoden, mens automatiseringer bestemmer når den kjøres.

A2A-sikkerhet og tillatelsesgrenser

Multi-agent-arbeid er tryggere når tilgang følger oppgaven. Gi hver spesialist kun de koblinger og tillatelser som kreves for sin del. En research-agent trenger sjelden publiseringstilgang. En QA-agent kan trenge staging-innlogging, men ikke produksjonsfakturering. En publiseringsagent kan ha kladdetilgang, men fortsatt kreve godkjenning før endelig publisering.

Hold eksterne skrivinger under én navngitt eier. Flere agenter kan lese et repository, CRM eller CMS, men én agent bør opprette endelig sak, oppdatere posten, sende kundesvar eller publisere siden. Dette forhindrer dupliserte skrivinger og gjør revisjonssporet enklere å følge.

For arbeid med høyere risiko, legg til en stoppbetingelse i oppdraget: “Kun utkast”, “Ikke send”, “Eskaler hvis bevis er motstridende” eller “Be om godkjenning før endring i produksjon”. A2A gjør delegering enklere; det fjerner ikke behovet for tydelig ansvar.

Fire regler som holder A2A-arbeid ryddig

1. Gjør hver første melding selvstendig

Ta med mål, kildemateriale, begrensninger, utdataformat, destinasjon og stoppbetingelse. En underchat skal ikke måtte gjette hva kontrollchatten allerede vet.

2. Gi arbeiderne samme svarformat

Hvis fire QA-chatter returnerer fire ulike formater, bruker koordinatoren tiden på å rydde tekst. Be hver arbeider om samme felter: miljø, steg, bevis, status og neste handling.

3. Gi felles skriving til én eier

To riktige agenter kan fortsatt lage rot ved å skrive to ganger. Navngi agenten som eier den endelige eksterne handlingen.

4. Del kun arbeid som har nytte av oppdelingen

Å opprette åtte chatter betyr ikke at åtte runs kjører samtidig. Arbeidsområdets samtidighet gjelder fortsatt, og avhengig arbeid bør vente på sitt input. Hold en oppgave i én chat når hvert neste steg avhenger av forrige svar.

Er Zero A2A det samme som Googles Agent2Agent-protokoll?

Det påstås ingen protokoll-ekvivalens her. Denne veiledningen beskriver produktkoordinering mellom agenter og chatter i Zero: hvordan arbeid deles, refereres, vurderes og overleveres via grensesnittet.

Googles Agent2Agent åpne protokoll er en teknisk standard for kommunikasjon mellom eksterne agentsystemer, inkludert kapabilitetsoppdagelse, oppgavehåndtering, meldinger og artefakter. Søkeresultater for “A2A” fokuserer ofte på den protokollen, så skillet er viktig: Zero A2A er den praktiske produktarbeidsflyten som dekkes i denne artikkelen.

Ofte stilte spørsmål

Er en chat det samme som en agent?

Nei. En agent er en gjenbrukbar arbeiderkonfigurasjon. En chat er én isolert samtale med den agenten. Én agent kan eie mange chatter.

Deler underchatter kontrollchattens kontekst?

Nei. Start hver underchat med et komplett oppdrag. Arbeidere kan returnere resultater eller sende avgrensede artefakter til en annen chat, men de skal ikke anta delt historikk.

Hva skjer når jeg @-nevner en chat?

Zero setter inn en strukturert referanse til chatten du valgte. Referansen identifiserer samtalen du mener. Den limer ikke inn hele samtalen i komponisten, så legg til en tydelig handling som sammenlign, gjennomgå, fortsett eller trekk ut.

Hva er en subagent i Zero?

En subagent er en spesialistagent som mottar en avgrenset oppgave fra en koordinator. Den kan bruke ulike instruksjoner, verktøy, tillatelser eller en annen modell, og returnerer deretter sitt resultat til kontrollchatten.

Kan flere chatter kjøres parallelt?

Ja, når arbeidsområdets samtidighet er tilgjengelig og oppgavene er uavhengige. Ekstra oppgaver kan havne i kø når grensen er nådd. Arbeid med avhengigheter bør kjøres i rekkefølge.

Når bør jeg bruke ulike agenter?

Bruk ulike agenter når arbeidet krever ulike instruksjoner, arbeidsflyter, modeller, koblinger eller tillatelser. Bruk flere chatter under samme agent når du hovedsakelig trenger ren kontekst.

Prøv staging-gjennomgangen først

Åpne en ny chat i Zero og del én reell lanseringssjekk i fire rene chatter. Be om skjermbilder og samme bestått/ikke bestått-format i hver chat. Når det fungerer, bytt ut én gren med en spesialistagent eller referer til to fullførte chatter i en dommerprompt.

For flere ideer, se 20 AI-agent brukstilfeller med eksakte prompt og verktøy.