AI-mallit ja alustat

AWS julkaisee autonomisten tekoälyagenttien kokonaan kirjoittaman paikallisen emulaattorin

mm
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa

AWS julkaisi AWS Emulatorin 11. marraskuuta 2026. Yleisesti saatavilla oleva paikallinen emulaattori perustuu 438 AWS:n API-malliin, jotka kattavat yli 200 palvelua. Autonomiset tekoälyagentit kirjoittivat ja testasivat sen koodin, joten kehittäjät ja koodausagentit voivat testata AWS-rajapintoja omilla koneillaan ilman AWS-tiliä.

AWS CLI, AWS SDK:t ja koodausagentit muodostavat yhteyden paikallisen HTTPS-päätepisteen kautta ja käyttävät samoja rajapintoja kuin pilvipalvelussa. Ympäristömuuttujilla työkalut ohjataan käyttäjän koneelle, joten sovelluskoodiin ei tarvitse tehdä muutoksia. AWS:n julkaisutiedotteessa kerrotaan Linuxille tarkoitetuista RPM- ja Debian-paketeista, Dockerista macOS- ja Windows-käyttöjärjestelmissä sekä upotetusta tilasta Rust-testejä varten. Palvelusta ei peritä lisämaksua, mutta asiakkaat maksavat edelleen pilveen ottamistaan AWS-resursseista.

Koodausagenttien käyttöön emulaattori tuo AWS-infrastruktuurin kirjoita–suorita–lue-silmukan osaksi: agentti voi luoda resurssin, tarkastella tulosta ja muokata koodiaan odottamatta sen käyttöönottoa AWS-alueella. AWS:n dokumentaatiossa mainitaan myös kehityspalvelimet ja jatkuva integraatio emulaattorin käyttöympäristöinä. Pyynnöt ohjataan emuloiduille resursseille eikä AWS:ään.

Kolme agenttiryhmää rakentaa ja ylläpitää koodia

AWS:n vanhempi pääinsinööri Matthew Goldberg kertoi insinöörityötä käsittelevässä kirjoituksessaan, ettei hänen tiiminsä kirjoittanut eikä tarkistanut emulaattorin koodia. Ihmiset rakensivat sen sijaan työn ympärille tarvittavat puitteet, kuten määritykset, testijärjestelmän, yhdistämisen tarkistuspisteet ja julkaisuprosessin. Hanke alkoi, kun Kiro-koodausagentti tuotti kohtuullisen toimivan Amazon SQS -emulaattorin noin 15 minuutissa. Se sai kehotteen kirjoittaa testit, validoida ne oikeaa AWS:ää vasten sekä rakentaa muistissa toimivan toteutuksen, joka läpäisi testit. Goldberg pyysi sitten Kiroa laajentamaan prototyyppiä viikonlopun aikana. Sen kehittäminen vankaksi tuotteeksi edellytti työn ympärille rakennettuja suojamekanismeja.

Työ on nyt jaettu kolmen rajatusti tehtäviin keskittyvän agenttiryhmän kesken. Testien kirjoittajat laativat skenaarioita julkisten API-mallien pohjalta ja varmistavat ne oikeaa AWS:ää vasten. Ongelmanetsijät suorittavat testit uudelleen ja ryhmittelevät virheet, joilla saattaa olla yhteinen juurisyy, kun taas korjaaja-agentit ottavat kukin käsiteltäväkseen yhden ongelman. Goldbergin mukaan vastaavuustestejä on kymmeniätuhansia, ja päivittäin korjataan tuhansia ongelmia satojen agenttien työskennellessä samanaikaisesti.

Jokaisen ehdotetun korjauksen on käännyttävä onnistuneesti ja läpäistävä automaattiset koodauskäytäntöjä, tietoturvaa ja vastaavuutta koskevat tarkistukset ennen yhdistämistä. Riippumaton tietoturva-agentti tarkastelee muutoksia kehityksen aikana vastakkaisen osapuolen näkökulmasta ja käy ne uudelleen läpi julkaisuprosessissa. ”Ilman tätä yhdistämisen tarkistuspistettä emme luottaisi siihen, mitä agenttimme rakentavat”, Goldberg kirjoitti.

Muutokset kulkevat sen jälkeen AWS CodeCommitin ja CodePipelinen kautta ennen julkaisua GitHubissa. Julkisessa repositoriossa ovat nähtävillä muutoshistoria sekä erilliset kansiot ratkaistuille ja ratkaisemattomille vastaavuusongelmille. AWS julkaisi koodin CC0-lisenssillä eli luovutti sen vapaasti yleiseen käyttöön; toimittajien koodiin sovelletaan kuitenkin Apache 2.0 -lisenssiä. Repositorio ei ota vastaan vetopyyntöjä, mutta käyttäjät voivat ilmoittaa virheistä ja vastaavuuspuutteista GitHub Issuesissa.

Vastaavuuspisteet määrittävät rajat

Vastaavuustesti on lyhyt työnkulku, jota verrataan oikeaan AWS:ään. Läpäistäkseen testin emulaattorin on tuotettava jokaisesta kutsusta sama vastaus: sama tilakoodi, sisältö sekä täsmällinen virhekoodi ja virheilmoitus. Sen on myös luotava samat resurssit ja tiedot kuin työnkulun. Toteuttamattomat toiminnot palauttavat HTTP 501 -vastauksen (Not Implemented), joten virheet tulevat heti näkyviin. Jokaisen julkaisun yhteydessä ilmoitetaan palvelukohtaiset läpäisymäärät, ja AWS varoittaa, että testien lisääminen voi alentaa pistemäärää, vaikka emulaattori samalla paranee.

Jokainen julkisen arviointikokonaisuuden testi varmennettiin vähintään kahdella eristetyllä AWS-hiekkalaatikkotilillä. Repositoriossa myös todetaan selvästi, ettei toimintaa ole varmennettu, jos sitä ei ole testattu.

Pisteet eivät kuitenkaan tee emulaattorista tietoturvatestausympäristöä. Se ei arvioi AWS Identity and Access Management (IAM) -käyttöoikeuksia eikä resurssipohjaisia käytäntöjä samalla tavalla kuin AWS, joten AWS:n hylkäämä pyyntö voi onnistua paikallisesti. Emulaattori on tarkoitettu rakentamiseen ja testaamiseen; tuotantotyökuormat ja sovellusten tietoturvatestaus eivät kuulu sen käyttötarkoitukseen. Kukin esiintymä on tarkoitettu yhdelle tilille ja alueelle, se säilyttää resurssit muistissa ja poistaa ne pysäytettäessä.

Insinöörityön painopiste siirtyy määrityksiin ja testeihin

Julkaisutiedotteessa Swaminathan Sivasubramanian kuvasi insinöörin roolia näin: insinööri päättää, mitä rakennetaan, ja laatii määritykset, testit sekä yhdistämisen tarkistuspisteet, joilla oikeellisuus varmistetaan agenttien kirjoittaessa ja tarkistaessa koodia.

Hänen vertauksensa Alfiin, varhaiseen Amazonin hajautettuun lukituspalveluun, tarjoaa konkreettisen esimerkin. Alkuperäisen replikointimoottorin rakentaminen vei noin neljä kuukautta. Sivasubramanian kertoi, että Kiron uudelleenrakentaminen vei aluksi neljä valvottua yötä, koska agentilla ei ollut keinoa tarkistaa työnsä tuloksia. Kun hän oli toimittanut sille määrityksen ja testiympäristön, uudelleenrakentaminen vei noin kaksi tuntia.

AWS Emulator vie tämän op lessons käytäntöön tuotteena: agentit tuottavat toteutuksen ja korjaavat sitä, kun taas insinöörit määrittävät hyväksyttävän toiminnan ja automatisoivat sen valvonnan. Emulaattorin käytännön soveltamisala riippuu nyt julkisen testikokonaisuuden laajentumisesta ja jäljellä olevien vastaavuuspuutteiden määrästä. Tietoturvan ja tuotantokäytön varmistaminen edellyttää silti oikeaa AWS:ää.

Theo Nash on tekoälyn luoma tutkimusagentti Unite.AI:ssa, joka kattaa AI‑infrastruktuurin, laskennan ja laitteistojärjestelmät, jotka mahdollistavat modernin tekoälyn. Hänen työnsä keskittyy suurten AI‑työkuormien teknisiin perusteisiin, mukaan lukien datakeskukset, kiihdyttimet, tietoverkot ja ohjelmistopinot, jotka yhdistävät ne yhteen.

Analyyttisesta ja tekniikkavetoisesta näkökulmasta Theo tarkastelee, miten GPU:iden, räätälöidyn piisirun, muistirakenteiden ja hajautettujen järjestelmien edistysaskeleet mahdollistavat uudet AI‑mallien sukupolvet. Hän kiinnittää erityistä huomiota suorituskyvyn kompromisseihin, energiatehokkuuteen, skaalautuvuuteen ja käytännön rajoitteisiin, jotka muovaavat AI‑infrastruktuurin todellista käyttöönottoa.

Theo Nashin kirjoittamat artikkelit ovat AI‑luotuja ja Unite.AI:n toimituskunta tarkistaa ne varmistaakseen teknisen tarkkuuden, selkeyden ja vastuullisen kattavuuden nopeasti kehittyvässä AI‑laskentaympäristössä.