Agyn-arkkitehtuuri: Tuotantotason multi-agent toteutettuna oikein

Agyn-arkkitehtuuri: Tuotantotason multi-agent toteutettuna oikein

Agyn ei optimoinut SWE-benchiä varten. He rakensivat tuotantoalustan autonomiselle ohjelmistokehitykselle ja testasivat sitä sitten benchmarkissa validointina. Tulos: #1 suorituskyky GPT-5-luokan mallien joukossa, 7,2 % absoluuttista parannusta yksittäisagentjärjestelmiin kuten OpenHandsiin verrattuna. [2]

Heidän salaisuutensa ei ole paremmat mallit—se on parempi organisointi. Agyn-järjestelmä käyttää neljää erikoistunutta agenttia: Manager (tehtävien pilkonta), Researcher (koodikannan analyysi), Engineer (toteutus) ja Reviewer (laadunvalvonta). [1] Jokainen agentti toimii eristetyissä hiekkalaatikoissa määritellyillä vastuualueilla ja strukturoidulla kommunikaatiolla GitHub-primitiivien kautta.

Manager-agentti vastaanottaa GitHub-issuen ja luo projektisuunnitelman alitehtävineen. Researcher-agentti analysoi koodikantaa, tunnistaa relevantit tiedostot ja dokumentoi toteutukseen tarvittavan kontekstin. Engineer-agentti kirjoittaa koodia tutkimuksen perusteella luoden committeja ja pull requesteja. Reviewer-agentti tutkii muutokset, ajaa testit ja joko hyväksyy tai pyytää muutoksia.

Mikä saa tämän toimimaan on infrastruktuuri, ei pelkät roolit. Jokaisella agentilla on eristetyt suoritusympäristöt, mikä estää yhden agentin virheet kaskadoitumasta muille. Kommunikaatio tapahtuu strukturoitujen GitHub-artefaktien—pull requestien, committien ja koodikommenttien—kautta eikä lyhytaikaisten chat-viestien. Konteksti tiivistetään ja välitetään agenttien välillä määriteltyjen rajapintojen kautta, ei ad-hoc promptauksella.

Agyn-tiimi havaitsi, että "tiimirakenteen, metodologian ja kommunikaation replikointi on voimakas paradigma autonomiselle ohjelmistokehitykselle, ja tulevaisuuden edistys saattaa riippua yhtä paljon organisaatiosuunnittelusta ja agentti-infrastruktuurista kuin malliparannuksista." [1] Tämä oivallus menee vastoin vallitsevaa viisautta, että isommat mallit ratkaisevat kaiken.

CAID: Git-natiivi asynkroninen delegointi joka skaalautuu

Kun Agyn todistaa multi-agent orkestroinnin toimivan tuotannossa, CMU:n CAID (Centralized Asynchronous Isolated Delegation) -kehys näyttää kuinka rakentaa se perusperiaatteista lähtien. CAID saavuttaa 26,7 % absoluuttisen parannuksen PaperBenchissä ja 14,3 % Python-kirjastotehtävissä perustamalla multi-agent koordinoinnin ohjelmistokehityksen primitiiveihin. [4]

CAID-arkkitehtuuri keskittyy manager-agenttiin, joka delegoi tehtäviä useille engineer-agenteille, jotka työskentelevät asynkronisesti eristetyissä git-työpuissa. Jokainen engineer-agentti saa oman työtilansa—erillisen git-haaran omalla riippuvuusympäristöllään—eliminoiden konfliktit ja mahdollistaen rinnakkaisen työn. [3]

Näin se toimii käytännössä: Manager vastaanottaa monimutkaisen tehtävän kuten "toteuta OAuth2-autentikointi rate limitingin kanssa." Se pilkkoo tämän alitehtäviksi: luo tietokantaskeema, toteuta auth-middleware, lisää rate limiting -logiikka, kirjoita testit, päivitä dokumentaatio. Jokainen alitehtävä annetaan engineer-agentille omassa git-työpuussaan.

Engineerit työskentelevät asynkronisesti tehden committeja eristetyille haaroilleen. Kun engineer suorittaa alitehtävänsä, manager tarkistaa muutokset ja joko mergaa ne tai pyytää muutoksia. Alitehtävien väliset riippuvuudet käsitellään git merge -prosessin kautta—jos auth-middleware riippuu tietokantaskeemasta, se merge tapahtuu ensin.

CAID-repositorio tarjoaa täydellisen toteutuksen Docker-työtiloilla, LiteLLM-tuella useille mallitarjoajille ja modulaarisilla tehtävärajapinnoilla. [4] Voit ajaa sen paikallisesti uv syncillä ja ympäristömuuttujilla mallin API-avaimillesi. Koodikanta demonstroi käytännön malleja: työtilan eristys, riippuvuuksien hallinta, tehtävien pilkonta ja tulosten aggregointi.

Orkestrointimallit jotka todella toimivat

Sekä Agyn että CAID onnistuvat, koska ne toteuttavat pienen joukon todistettuja suunnittelumalleja. Hyödyt eivät tule prompt-engineeringistä tai mallin hienosäädöstä—ne tulevat arkkitehtuuripäätöksistä, jotka heijastavat sitä, miten ihmisten insinööritiimit todella työskentelevät. [6]

Eristetyt suoritusympäristöt estävät agenttien virheet kaskadoitumasta. Kun yksi agentti rikkoo buildin tai korruptoi tilan, muut agentit jatkavat työskentelyä omissa hiekkalaatikoissaan. Tämä vikaisten eristys on kriittistä luotettavuudelle tuotantojärjestelmissä.

Eksplisiittiset roolimäärittelyt antavat jokaiselle agentille selkeät vastuut ja onnistumiskriteerit. Agynin Researcher ei kirjoita koodia; se analysoi koodikantoja ja dokumentoi löydökset. Engineer ei tee arkkitehtuuripäätöksiä; se toteuttaa tutkimuksen ja vaatimusten perusteella. Nämä rajat estävät roolisekaannukset ja parantavat tuotosten laatua.

Strukturoitu kommunikaatio GitHub-artefaktien kautta luo pysyviä, tarkistettavia tallenteita agenttien päätöksistä. Toisin kuin chat-pohjainen koordinointi, pull requestit ja koodikommentit tarjoavat kontekstin, joka säilyy agenttiistuntojen yli ja jota ihmiskehittäjät voivat tarkistaa.

Kontekstin hallinta pitkäkestoisille tehtäville ratkaisee agenttien muistirajoitusten ongelman. Sen sijaan että tunkisi kokonaisia koodikantoja konteksti-ikkunoihin, agentit tiivistävät löydöksensä ja välittävät strukturoitua dataa määriteltyjen rajapintojen kautta. Agynin Researcher luo dokumentaatiota, johon Engineer voi viitata analysoimatta koodikantaa uudelleen.

Nämä mallit toimivat, koska "ohjelmistokehitys on yhteistyöprosessi. Työ jaetaan roolien kesken, koordinointi tapahtuu jaettujen artefaktien kautta, ja edistys syntyy iteroinnin ja tarkistuksen kautta." [6] AI-järjestelmät, jotka kunnioittavat näitä todellisuuksia, päihittävät ne, jotka käsittelevät koodausta yksinäisenä toimintana.

Rakentajan toteutusopas

Valmis käyttöönottamaan multi-agent orkestrointia? Aloita avoimen lähdekoodin perustoista ja rakenna tuotantomalleihin.

Kokeilua varten kloonaa CAID-repositorio ja aja esimerkit. [4] Asennus vaatii Python 3.11+:n, Dockerin työtilan eristykseen ja API-avaimet haluamillesi kielimalleille. Repositorio sisältää tehtäviä paperien reprodukointiin ja Python-kirjastojen kehitykseen, jotka demonstroivat ydinkuviot.

Tuotantokäyttöönottoa varten tutki Agyn-alustan arkkitehtuuria. [5] Vaikka heidän täysi alustansa ei ole avointa lähdekoodia, heidän blogissaan dokumentoidaan keskeiset suunnittelupäätökset: agenttiroolien määrittelyt, hiekkalaatikon eristysstrategiat, GitHub-integraatiokuviot ja kontekstin hallinnan lähestymistavat.

Keskity git-natiiveihin työnkulkuihin alusta alkaen. Molemmat onnistuneet järjestelmät perustavat orkestrointinsa ohjelmistokehityksen primitiiveihin—haaroihin, committeihin, mergeeihin, pull requesteihin. Tämä ei ole vain yhteensopivuutta olemassa olevien työkalujen kanssa; se johtuu siitä, että nämä primitiivit koodaavat vuosikymmenten oppimisen siitä, miten koordinoida monimutkaisia ohjelmistomuutoksia.

Mittaa sitä mikä merkitsee: päästä päähän tehtävien suorittamista, ei agenttien chat-laatua. SWE-bench benchmark testaa, voivatko agentit todella korjata oikeita GitHub-issueja, ei sitä kuulostavatko heidän perustelunsa uskottavilta. Rakenna arviointikehyksesi ennen kuin rakennat agenttisi.

Aloita kapeista aloista, joissa voit määritellä selkeät onnistumiskriteerit. Sekä Agyn että CAID toimivat, koska ne käsittelevät hyvin määriteltyjä ohjelmistokehitystehtäviä mitattavilla tuloksilla. Älä yritä rakentaa yleiskäyttöistä AI-tiimiä; rakenna erikoistunut tiimi omaan käyttötapauksesi.

Tapaustutkimukset: Multi-agent tiimit luonnossa

Tutkimuspapereissa on benchmarkeja, mutta entä todellinen käyttöönotto? Varhaiset omaksujat näkevät käytännön hyötyjä eri tyyppisissä ohjelmistokehitystehtävissä.

API-integraatiotehtävät toimivat erityisen hyvin multi-agent järjestelmissä. Yksi agentti tutkii kohde-API:n dokumentaatiota ja luo integraatiospesifikaatiot. Toinen agentti toteuttaa asiakaskoodin näiden spesifikaatioiden perusteella. Kolmas agentti kirjoittaa kattavat testit ja käsittelee virhetapaukset. Eristys estää API:n rate limitingiä estämästä muita työketjuja.

Legacy-koodikantojen modernisointi hyötyy tutkimuspainotteisesta lähestymistavasta. Researcher-agentit voivat analysoida vanhentuneet riippuvuudet ja dokumentoida migraatiopolut koskematta tuotantokoodiin. Engineer-agentit voivat toteuttaa muutoksia eristetyissä haaroissa. Reviewer-agentit voivat validoida, että uudet toteutukset säilyttävät käyttäytymisyhteensopivuuden.

Dokumentaation generointi esittelee yhteistyöedut. Yksi agentti analysoi koodirakenteen ja tunnistaa dokumentoimattomat funktiot. Toinen agentti kirjoittaa alkuperäisen dokumentaation koodianalyysin perusteella. Kolmas agentti tarkistaa dokumentaation tarkkuuden ja täydellisyyden ristiinviittaamalla todellisiin käyttökuvioihin koodikannassa.

Yhteinen lanka: tehtävät, jotka hyötyvät erikoistumisesta ja rinnakkaisesta työstä, näkevät suurimmat hyödyt multi-agent orkestroinnista. Yksittäiset agentit kamppailevat kontekstin vaihtamisen kanssa tutkimuksen, toteutuksen ja tarkistuksen välillä. Erikoistuneet agentit säilyttävät keskittymisen ja tuottavat korkeampilaatuisia tuloksia omilla aloillaan.

Mikä muuttuu kun AI rakentaa ohjelmiston

Siirtymä yksittäisistä agenteista AI-tiimeihin edustaa enemmän kuin asteittaista parannusta koodausautomaatiossa. Se on AI-järjestelmien syntymistä, jotka voivat käsitellä ohjelmistokehityksen täyden monimutkaisuuden: tutkimuksen, arkkitehtuurin, toteutuksen, testauksen ja tarkistuksen. [1]

Tämä muuttaa ohjelmistokehityksen taloutta tavoilla, joita alamme vasta ymmärtää. Kun AI-tiimit voivat luotettavasti korjata GitHub-issueja ja toteuttaa ominaisuuksia, pullonkaula siirtyy koodin kirjoittamisesta vaatimusten määrittelyyn ja arkkitehtuuripäätösten tekemiseen. Koodista tulee ilmaista; harkinnasta tulee kaikki kaikessa.

Pohjoismaisille teknologiayrityksille, jotka jo johtavat AI:n omaksumisessa, tämä edustaa merkittävää kilpailuetua. Kyky käyttää AI-tiimejä rutiininomaisiin ohjelmistokehitystehtäviin vapauttaa ihmiskehittäjät keskittymään tuotestrategiaan, käyttäjäkokemukseen ja liiketoimintalogiikkaan. Se on automaatiota, joka vahvistaa ihmisten kykyjä sen sijaan, että korvaisi ne.

Mutta vaikutukset ulottuvat syvemmälle. Multi-agent orkestrointikuviot, jotka toimivat ohjelmistokehityksessä, toimivat todennäköisesti muussakin monimutkaisessa, yhteistyöhön perustuvassa tietotyössä. Samat periaatteet—roolien erikoistuminen, eristetty suoritus, strukturoitu kommunikaatio, kontekstin hallinta—pätevät tutkimukseen, analyysiin, sisällöntuotantoon ja strategiseen suunnitteluun.

Rakentajat, jotka hallitsevat nämä orkestrointikuviot tänään, muokkaavat sitä, miten AI-järjestelmät käsittelevät monimutkaisia ongelmia huomenna. Kysymys ei ole siitä, automatisoidaanko ohjelmistokehitys AI:lla—järjestelmät kuten Agyn ja CAID todistavat sen jo tapahtuvan. Kysymys on siitä, rakennatko harkintaa orkestroida näitä kykyjä tehokkaasti.

Koodin jälkeinen aikakausi ei tarkoita, ettei ohjelmointi enää ole. Se tarkoittaa, että ohjelmoinnista tulee korkeamman tason toimintaa: AI-tiimien suunnittelua, niiden vuorovaikutusten määrittelyä ja niiden tuotosten varmistamista palvelemaan ihmisten tavoitteita. Tulevaisuus kuuluu niille, jotka voivat arkkitehtuurin älykkyyden, eivät vain soveltaa sitä.

Lähteet

1. https://arxiv.org/abs/2602.01465
2. https://agyn.io/blog/we-tested-ai-team-swe-bench-verified
3. https://arxiv.org/abs/2603.21489
4. https://github.com/JiayiGeng/CAID
5. https://agyn.io/blog
6. https://agyn.io/blog/multi-agent-orchestration-patterns-that-actually-work
7. https://www.swebench.com/