OpenAI ir atvēris jaunu fronti aģentu infrastruktūras sacensībā ar Agents API publisko beta versiju, kas tika palaists 2026. gada 10. septembrī. Pakalpojums ļauj izstrādātājiem izveidot aģenta sesiju, norādot uzdevumu, modeli, rīkus un izpildes vidi vienā API izsaukumā, nevis apvienojot modeļu izsaukumus, rīku izsaukšanas cilpas un konteksta pārvaldību, kas tagad ir tikai cita lietojumprogramma.

izstrādātāja galapunkts. Svarīgākā pārmaiņa ir arhitektoniskā: OpenAI ir pati iepakošanas aģenta orķestrēšana kā mitināta API virsma. Beta versija atbalsta MCP, pielāgotas funkcijas un iebūvētos rīkus, piemēram, meklēšanu tīmeklī. OpenAI arī saka, ka platforma ietver automātisku konteksta blīvēšanu, programmatisku rīku izsaukšanu un paralēlus apakšaģentus.

Izstrādātājiem veido aģentu produktus, kas vairākas darbības problēmas pārvieto no lietojumprogrammas izpildlaika uz nodrošinātāja slāni. Uzņēmumiem, kas izmanto vārtejas, norēķinu sistēmas vai iekšējās AI platformas, tas rada arī jaunu integrācijas problēmu. Pieprasījums vairs var nebūt tīri saistīts ar vienu modeļa zvanu. Tā var būt sesija, kas pirms atbildes atgriešanas izplatās dažādos rīkos, vidēs un apakšaģentos.

Kas mainījies

Līdz šim daudzas ražošanas aģentu sistēmas tika veidotas, izmantojot tērzēšanas vai atbilžu stila API. Izstrādātāji paši apstrādāja orķestrēšanas cilpu: nosūtīja uzvedni, pārbauda rīka izsaukšanas pieprasījumus, palaida rīku, pievieno rezultātus, pārvaldīja konteksta ierobežojumus, atkārtoja kļūmes un izlemj, kad uzdevums ir pabeigts. Ietvari un aģentu izpildlaiki palīdzēja, taču atbildība lielākoties palika lietojumprogrammas īpašniekam.

Agents API maina šo darba sadalījumu. OpenAI piedāvā mitināta aģenta sesijas modeli, kurā izstrādātājs apraksta darbu un pieejamās iespējas, savukārt platforma pārvalda vairāk izpildes plūsmas. API atbalsts MCP ir svarīgs, jo MCP ir kļuvis par izplatītu veidu, kā aģentiem pakļaut rīkus un ārējās sistēmas. Vietējais atbalsts padara rīku slāni mazāk pārdomātu un vairāk par pirmās klases līgumu.

OpenAI saka, ka par aģentu API izmantošanu nav jāmaksā nekāda papildu maksa, izņemot izmantotos marķierus un rīkus. Šī cenu noteikšanas izvēle samazina šķēršļus eksperimentiem, taču tas nepadara vienkāršu darba slodzes uzskaiti. Mitinātā aģenta palaišana joprojām var patērēt modeļa marķierus, iebūvēto rīku lietojumu un, iespējams, ārējo infrastruktūru aiz savienotajiem rīkiem. Komandām, kas jau cenšas centralizēt vienoto AI API norēķinus, norēķinu vienība kļūst mazāk pamanāma.

Kāpēc tas ir svarīgi vārteju un platformu komandām

Palaišana rada spiedienu uz AI vārtejām, lai tās atbalstītu vairāk nekā ar OpenAI saderīgiem galapunktiem. Ja klienti sāk izmantot mitināto aģentu sesijas, vārtejām, iespējams, būs tieši jāīsteno jaunā virsma starpniekserveris, jāpārvērš tā iekšējās politikās vai jāizlemj, ka dažas aģenta darbības ir ārpus viņu atbalstītās vadības plaknes.

Tas ir būtisks produkta lēmums. Vārtejai, kas redz tikai augstākā līmeņa pieprasījumu, var nebūt informācijai par operatīvo informāciju, kas ir svarīga uzņēmuma klientiem: kuri rīki bija atļauti, kuri apakšaģenti tika palaisti, kura vide apstrādāja izpildi, kādi dati pārsniedza robežu un kā jāattiecina izdevumi. Vārtejai, kas vēlas palikt par ierakstu sistēmu, būs nepieciešami sesiju zinoši žurnāli, rīka līmeņa atļaujas un skaidrāks izmaksu sadalījums.

Tas ir īpaši svarīgi Model Gate stila platformām, kuras jau atrodas starp komandām un vairākiem modeļu nodrošinātājiem. Praktiskā prasība vairs nav tikai pieprasījuma novirzīšana uz lētāko vai ātrāko modeli. Aģentu darba slodzēm ir nepieciešamas politikas vadīklas saistībā ar rīkiem, smilškastes, piekļuvi datiem un budžetiem. Viņiem ir nepieciešama arī analītika, kas izskaidro, vai pieaugumu izraisīja marķiera izmantošana, meklēšana tīmeklī, koda izpilde, ilgstoša sesija vai atkārtoti apakšaģenta izsaukumi.

OpenAI laiks atbilst arī plašākam modelim. Nesenie pakalpojumu sniedzēju un vārtejas palaišanas gadījumi ir tuvinājuši izpildi un pārvaldību infrastruktūras slānim: mitinātie čaulas rīki, MCP servera vadīklas, reģionam specifiska maršrutēšana un uzņēmuma aģenta atļaujas liecina par vienu un to pašu maiņu. Aģentu uzvedība kļūst par kaut ko tādu, kas jāpārvalda platformu komandām, nevis tikai par to, ko izstrādātāji ievieš lietojumprogrammas kodā. Tādējādi komandas API pārvaldība ir produkta arhitektūras ceļā.

Ietekmētie cilvēki

Aģentu lietojumprogrammu izstrādātāji ir pirmā mērķauditorija. API varētu samazināt to uzturētā orķestrēšanas koda daudzumu un atvieglot modeļu, MCP rīku, tīmekļa meklēšanas un pielāgoto funkciju apvienošanu vienā pārvaldītā plūsmā.Tas ir noderīgi atbalsta aģentiem, kodēšanas palīgiem, izpētes darbplūsmām, iekšējiem operāciju rīkiem un automatizācijas produktiem, kur uzdevums aptver vairākas darbības.

Otrā auditorija ir platformas inženieri un drošības komandas. Hosted orķestrēšana maina audita modeli. Tā vietā, lai pārskatītu tikai lietojumprogrammas kodu un modeļa uzvednes, komandām ir jāsaprot aģenta sesijai piešķirtās atļaujas un to rīku darbība, kas savienoti, izmantojot MCP vai pielāgotas funkcijas. Jautājums kļūst mazāks: “Kuram modelim tika izsaukta šī lietotne?” un vēl vairāk “Ko šis aģents drīkstēja darīt un ko tas patiesībā darīja?”

Tas skar arī finanšu un operāciju komandas. OpenAI saka, ka nav atsevišķas Agents API piemaksas, taču uz sesijām balstīts darbs var izjaukt izmaksu attiecinājumu. Viena lietotāja darbība var aktivizēt vairākus modeļu izsaukumus un rīkus. Šī struktūra ir jāatspoguļo katras atslēgas budžetiem, produktu līmeņa ierobežojumiem un klientu līmeņa pārskatiem. Nopietnai aģentu izvietošanai nepietiks ar AI API lietojuma analīzes informācijas paneli, kurā tiek apkopoti tikai marķieri pēc modeļa.

Tas, kas joprojām ir neskaidrs

Lielākais nezināmais ir tas, cik labi notiek ražošanas modeļa mitināšana vai ražošanas vide. OpenAI palaišanas materiālā ir iekļauti klientu ziņoti uzlabojumi saistībā ar izmaksām, latentumu un novērtējumiem, taču tie ir pārdevēju publicēti lietu apgalvojumi. Tie ir jāuztver kā norādes, līdz pircēji var pārbaudīt API, lai tie atbilstu saviem uzdevumiem, datiem, rīkiem un uzticamības mērķiem.

Nav arī skaidrs, cik ātri ekosistēma standartizēsies ap pakalpojumu sniedzēja mitinātiem aģentiem salīdzinājumā ar neatkarīgiem izpildlaikiem. Dažas komandas dos priekšroku OpenAI pārvaldītajai pieejai, jo tā samazina infrastruktūras darbu. Citi saglabās orķestrēšanu uz vietas, lai saglabātu pārnesamību, novērojamību vai stingrākas drošības robežas. Daudzi, iespējams, izmantos abus: viesotos aģentus dažām darbplūsmām, lietojumprogrammu pārvaldītus aģentus citām.

Beta etiķete ir svarīga. Izstrādātājiem vajadzētu sagaidīt, ka informācija attīstīsies, OpenAI mācoties no agrīnas lietošanas. Pagaidām stratēģiskais virziens ir skaidrāks nekā API galīgā forma: aģentu orķestrēšana kļūst par pakalpojumu sniedzēja līmeņa produktu virsmu. Jebkuram uzņēmumam, kas pārdod, pārvalda vai analizē AI piekļuvi, aģentu sesijas ir jāuzskata par pirmšķirīgiem objektiem, nevis tikai sarežģītām uzvednēm.