Az OpenAI nyilvános bétaverzióban bevezette az Agents API-t, így a fejlesztők saját maguk készíthetnek és futtathatnak felhőügynököket egy felügyelt Codex kábelköteg segítségével. A szeptember 10-i megjelenés nem egy újabb modellkiadás. Ez egy infrastrukturális lépés: az OpenAI az ügynöki munka köré tömöríti a futási időt, beleértve a kábelezést, a végrehajtási környezet megválasztását és a hosszabb ideig tartó feladatokhoz szükséges felhőréteget.
A kódoló ügynökökkel, kutatóügynökökkel, támogató automatizálással vagy belső munkafolyamat-asszisztensekkel már kísérletező csapatok esetében a változás lényeges. A modellhívások, az eszközvégrehajtás, a fájlállapot, a feladatmemória, a sandbox-kezelés és az újrapróbálkozások összefűzése helyett a fejlesztők az ügynöki munkamenetek köré tervezett API-ból indulhatnak ki. Az OpenAI szerint a béta lehetővé teszi a fejlesztők számára, hogy az OpenAI által felügyelt sandbox, saját infrastruktúra vagy támogatott sandbox partnerek közül válasszanak. Azt is mondja, hogy a használt tokeneken és eszközökön kívül nincsenek további ügynöki API-díjak.
Ez az árképzési részlet számít, de nem szabad összetéveszteni az egyszerűséggel. Az ügynökök tokeneket fogyaszthatnak a tervezés, az eszközhasználat, a fájlellenőrzés, a részfeladat delegálása és az ismételt próbálkozások során. Amint a munka a gyors válaszmintáról a futó ügynöki folyamat felé halad, a vállalatoknak a költségeket a munkafolyamat és a munkamenet szintjén kell mérniük, nem csak az egyéni kérések szintjén.
Mi változott
A lényegi változás az, hogy az OpenAI felügyelt ügynöki réteget kínál, nem pedig az ügyfeleket hagyja, hogy saját kábelköteg-vermet kezeljenek. A Codex már társult a szoftver-orientált ügynöki munkafolyamatokhoz. Az Agents API nyilvános béta fejlesztői felületként teszi elérhetővé ezt a kábelt a felhőalapú végrehajtáshoz.
Ez azt jelenti, hogy az integrációs egység bővül. A hagyományos vállalati LLM API integráció általában követi a kéréseket, a modellneveket, a jogkivonatok mennyiségét, a késleltetést, a hibákat és a kulcsokat. Az ügynökintegrációnak figyelembe kell vennie a munkamenetet, a rendelkezésre bocsátott eszközöket, a kiválasztott sandboxot, a megadott engedélyeket, valamint az esetleges segédügynököket vagy háttérfeladatokat.
Az OpenAI infrastrukturális lehetőségei a piac gyakorlati megosztottságára utalnak. Egyes csapatok az OpenAI által kezelt homokozót részesítik előnyben, mert csökkenti a működési terheket. Mások, különösen a szabályozott vagy biztonsági szempontból érzékeny környezetekben, azt szeretnék, ha az ügynökök saját infrastruktúrájukban vagy partnerek homokozóiban futnának, ahol szigorúbban szabályozható a hálózati hozzáférés, az adatok tartózkodási helye és az auditálás.
Miért érdemes odafigyelniük a vállalkozásoknak
Az indítás egy olyan pillanatban történik, amikor a vállalati mesterséges intelligencia a csevegési interfészekről olyan rendszerekre mozdul el. Egy kérdésre válaszoló modell egyfajta kockázat. Egy másik működési modell egy olyan ügynök, amely fájlokat olvas, eszközöket hív meg, kódot szerkeszt, jegyeket nyit meg, belső rendszereket kérdez le vagy shell-parancsokat hajt végre.
A fejlesztők számára a felügyelt ügynök API csökkentheti a differenciálatlan platformmunkát. A megbízható kábelköteg felépítéséhez döntésekre van szükség az állapotra, a szerszámsémákra, a hibakezelésre, a homokozó életciklusára, a megfigyelhetőségre és a biztonsági ellenőrzésekre vonatkozóan. A szállító által felügyelt verzió lehetővé teheti a termékcsapatok gyorsabb mozgását, különösen akkor, ha ügynöki funkciókat szeretnének prototípusba hozni anélkül, hogy az összes vízvezetéket karbantartanák.
A platform- és biztonsági csapatok számára ugyanaz az absztrakció új irányítási kérdéseket vet fel. Mely API-kulcsok hozhatnak létre ügynököket? Milyen homokozókat használhatnak ezek az ügynökök? Mely eszközök engedélyezettek alapértelmezés szerint? Korlátozhatja-e a csapat egy ügynöki munkamenet vagy egy munkafolyamat-osztály kiadását? A naplók képesek megkülönböztetni a modellválaszt, az eszközhívást, a fájlműveletet és a delegált részfeladatot?
Itt válik konkréttá az üzleti hatás. Az ügynöki munkafolyamatokat nehezebb megtervezni, mint a szokásos befejezéseket, mivel a munka mennyisége kevésbé kiszámítható. A felhasználó kérhet egyszerű választ, de az ügynök megvizsgálhatja a környezetet, futtathat eszközöket, létrehozhat egy tervet, felülvizsgálhatja azt, és újra megpróbálhatja a sikertelen műveleteket. Az a tény, hogy az OpenAI nem ad hozzá külön ügynöki API-díjat, nem szünteti meg a költségvetések, a riasztások és a használati elemzések szükségességét. Pénzügyi ellenőrzési felületté teszi a token- és eszközkönyvelést.
Kit érint?
A legközvetlenebb közönség a mérnöki csapatok az OpenAI-modelleken felüli ügynöktermékek kiépítése. Most már rendelkeznek egy kezelt útvonallal, amely kiválthatja a házon belüli kábelköteg egyes részeit, vagy felgyorsíthatja az új projekteket. A mesterséges intelligencia fejlesztői eszközeit, belső automatizálási termékeket, ügyfélszolgálati ügynököket vagy kutatási asszisztenseket fejlesztő induló vállalkozások az API-t gyorsabb termelési útnak tekinthetik.
A nagyvállalatok másként értékelik. Értékelhetik a belső ügynök futtatókörnyezetét, de azt is megkérdezik, hogyan illeszkedik a meglévő felhőbiztonsághoz, a szoftverellátási lánc felülvizsgálatához, az identitás-ellenőrzésekhez, a beszerzéshez és az incidensekre adott válaszokhoz.Az infrastruktúra vagy a sandbox partnerek kiválasztásának lehetősége fontos lehet ezeknek a vásárlóknak, mert az ügynök végrehajtása érzékeny adatokat és privilegizált rendszereket érinthet.
Az AI-átjárókat és a megfigyelhetőségi szolgáltatókat is érinti. A csak nyers modellhívásokat látó átjáró sok mindent kihagy az ügynöki munkafolyamatban. A vonatkozó telemetria mostantól magában foglalja az ügynök azonosítóját, a munkamenet időtartamát, az eszközszekvenciát, a sandbox környezetet, a jóváhagyási eseményeket, a gyorsítótár viselkedését, az újrapróbálkozásokat és a befejezett feladatonkénti költséget. A B2B LLM gyakorlati kapcsolata ebben a vezérlőrétegben van: a több modellt és API-t használó csapatoknak következetes API-kulcsos irányításra, költségkezelésre és használati elemzésre van szükségük még akkor is, ha az alkalmazási réteg ügynökivé válik.
Ami még bizonytalan
A béta címke több nyitott kérdést hagy maga után. A nyilvános béta API-k gyakran változnak, ahogy a fejlesztők éles eseteket fedeznek fel a régóta futó feladatok, az állapotkezelés, az eszközengedélyek és a telepítési határok körül. Az OpenAI leírta az infrastruktúra-választási lehetőségeket és a költségmodellt, de a vásárlóknak továbbra is ellenőrizniük kell a működési részleteket, mielőtt az API-t a kritikus munkafolyamatok alapjaként kezelnék.
Van egy versengő kérdés is. Az ügynök-infrastruktúra termékkategóriává válik, nem csak a modell API-kon belüli funkcióvá. A felhőszolgáltatók, a fejlesztői eszközökkel foglalkozó cégek, a SaaS platformok és az AI-átjárók szállítói mind a felügyelt ügynökvégrehajtás, a szabályzatok betartatása és a megfigyelhetőség felé haladnak. Az OpenAI előnye, hogy egy fejlesztői élmény alatt tudja összehangolni a modellt, a Codex kábelköteget és a felhőügynök futtatókörnyezetét. A kompromisszum az, hogy a vállalatok nem akarják, hogy egy szállító birtokolja a modellelérés, -végrehajtás és -irányítás minden szintjét.
A legvilágosabb rövid távú következmény az, hogy az ügynöki architektúra egyre szabványosabbá válik. A fejlesztők egyre inkább elvárják, hogy az API-k ne csak a következtetéseket kezeljék, hanem azt a környezetet is, amelyben az autonóm vagy félig autonóm munkavégzés történik. Ez emeli a lécet a modell minden platformján: a naplózásnak, a jóváhagyásoknak, a kulcshatókörnek, a költségellenőrzésnek és az ellenőrzési nyomvonalaknak mostantól az ügynököt kell követniük, nem csak a kérést.