2025 lehet az AI-ügynökök éve, ha túlélik a vállalati poklot

A vállalkozások évtizedek óta törekedtek a back-office feladatok, az adatbevitel, a számlázási folyamatok és más ismétlődő munkafolyamatok automatizálására. De még a szoftverek fejlődésével is, a valódi teljes körű automatizálás a legtöbb vállalat számára megfoghatatlan. Most, a Large Language Models (LLM-ek) gyors térnyerésével és az önálló gondolkodásra és cselekvésre képes „AI-ügynökök” megjelenésével egyre inkább úgy gondolják, hogy 2025 lehet az az év, amikor végre jelentős előrelépést láthatunk a vállalati automatizálás terén.

Sam Altman nyilvánosan kijelentette , hogy „2025-ben láthatjuk, hogy az első AI-ügynökök csatlakoznak a munkaerőhöz, és lényegesen megváltoztatják a vállalatok teljesítményét”, míg Marc Benioff a Salesforce-ot az „AgentForce” felé fordítja, egy olyan jövőre számítva, ahol sok szervezeti folyamatot delegálnak. szakosodott ügynökökhöz. Ezek az előrejelzések központi kérdést vetnek fel: le tudják-e küzdeni az AI-ügynökök a valós világbeli vállalati rendszerek bonyolult akadályait? Ebben a cikkben megvizsgáljuk a vállalati automatizálás egyedi nehézségeit, és feltárunk néhány ma ígéretes (de még kiforrott) megoldást. A gyakorlati teszteket is megosztjuk a Salesforce (SFDC) látszólag egyszerű munkafolyamatával – viszonteladói rendelés létrehozásával egy új fiókhoz –, amely felfedi a színfalak mögött megbúvó bonyolultságot.

Miért olyan kihívást jelent a vállalati automatizálás?

Papíron a vállalati feladatok automatizálása egyszerűnek hangzik: a bejelentkezéshez készítsen egy szkriptet, töltse ki az űrlapokat, és kattintson a „Küldés” gombra. A gyakorlatban a bonyolultság elképesztő. A vállalatok számtalan rekordrendszerre támaszkodnak, mint például a Salesforce, az SAP, az Oracle, és számos saját fejlesztésű megoldásra. Minden rendszernek megvan a saját engedélyei, hitelesítési folyamatai és egyéni üzleti logikája. Ráadásul ezek a rendszerek gyakran erősen testreszabottak. Gyakran előfordul, hogy speciális felhasználói felületeket, további adatmezőket és testre szabott munkafolyamatokat találunk, amelyek vállalkozásonként eltérőek.

A MuleSoft és a Deloitte közös felmérése szerint a nagyvállalatok átlagosan 976 különböző rendszert használhatnak napi működésük támogatására ( forrás ). Ez a töredezettség azt jelenti, hogy az automatizálási eszköznek több rendszerrel kell kommunikálnia, mindegyiknek megvan a maga árnyalata; egyesek robusztus API-kkal, mások pedig egyáltalán nem. Gyakran a legegyszerűbb feladatok közé tartozik az adatok áthidalása a régi, régi alkalmazások és az új felhőalapú szolgáltatások között. Még az olyan szabványos platformok is, mint a Salesforce, labirintussá válhatnak, ha az egyéni munkafolyamatokat és a harmadik féltől származó integrációkat bevezetik.

Ebben a háttérben az LLM-alapú ügynökök rugalmasabb megközelítést ígérnek: képesek adatokat elemezni, megindokolni a következő lépéseket, és még bonyolult grafikus felhasználói felületeken is navigálhatnak – legalábbis elméletben. De amint azt a következő példában látni fogja, az a valóság, hogy egy mesterségesintelligencia-ügynököt még az alapvető Salesforce-munkafolyamat elvégzésére is emberi segítség nélkül hajtanak végre, sokkal bonyolultabb, mint azt sokan gondolják.

Egy gyakorlati példa: Egyéni viszonteladói rendelés létrehozása a Salesforce-ban

A Feladat

Képzelje el, hogy egy Salesforce-ot használó kerékpárgyártó cég értékesítési munkatársa. Ön éppen most adott el 1 nagy Dynamo X1 kerékpárt 5000 dollárért egy új viszonteladónak, „Northern Trail Cycling”-nek. Az Ön feladata:

1 – Hitelesítés a Salesforce-ban (a megadott hitelesítő adatokkal).

2 – Hozzon létre egy új fiókot a viszonteladónak.

3 – Hozzon létre egy viszonteladói rendelést, és adja hozzá a sort (a kerékpárt).

4 – Nyújtsa be a megrendelést a gyártóhoz jóváhagyásra.

A sikeres végrehajtás érdekében a végeredményt a következőképpen várjuk:

Elég egyszerűnek tűnik, de az ördög a részletekben rejlik. A vállalat Salesforce-példánya testre szabott: egyéni „viszonteladói rendelés” objektumot és folyamatot, speciális fogd és vidd funkciót használ a termékek hozzáadásához, valamint egy rejtett „eladás a gyártáshoz” lépést egyértelmű címkézés nélkül. Ezt a forgatókönyvet számos feltörekvő AI-vezérelt automatizálási megközelítéssel teszteltem, hogy megtudjam, hogyan teljesítenek.

Claude számítógéphasználat

Mi az?

A Claude Computer Use az Anthropic új szolgáltatása, amelyet a Claude 3.5 Sonnet v2-vel vezettek be . Egy lépéssel tovább viszi a szabványos LLM függvényhívási paradigmát azáltal, hogy Claude számára egy teljes konténeres asztali környezetet biztosít a „látáshoz” és a „vezérléshez”. Képernyőképeket készíthet, vizuális/térbeli érveléssel értelmezheti őket, és olyan operációs rendszer szintű műveleteket hajthat végre, mint az egérkattintások, görgetések és billentyűleütések.

A felhasználó szemszögéből Ön magas szintű feladatot ad Claude-nak („Jelentkezzen be a Salesforce-ba, és hozza létre ezt a viszonteladói rendelést”), és Claude pontosan ezt próbálja megtenni. A következő sorozaton keresztül fut át:

1. Képernyőkép készítése és értelmezése.
2. UI műveletek kiadása (egérkattintások, billentyűleütések, bash parancsok).
3. Addig ismételje, amíg a feladat be nem fejeződik (vagy feladja).

Próbára tétele

Kezdjük azzal a legegyszerűbb megközelítéssel, hogy az Anthropic referencia-implementációját a rendszerprompt megváltoztatása nélkül futtatjuk. Itt van az interakció kezdete, amely megmutatja a kezdeti promptot, Claude javasolt tervét és azt az asztalt, amellyel az interakciót megkezdi.

Claude konténeres asztalának megfigyelése kezdetben lenyűgöző volt. Megnyitotta a böngészőt, felkereste a Salesforce URL-t, bejelentkezett a megadott hitelesítő adatokkal, és navigált a „Fiókok” oldalra. Hibátlanul létrehozott egy új fiókot a Bike Production Company számára, megadva a megfelelő adatokat az űrlapon, majd megpróbált új viszonteladói rendelést létrehozni. A dolgok zökkenőmentesen mentek, amíg nem találkozott az egyéni fogd és vidd felülettel a kerékpár hozzáadásához. A rendszer elakadt, amikor pixel alapú fogd és vidd műveletet próbált végrehajtani.

Néhány hiba után megpróbált alternatív módszert találni (például egy rejtett „Elem hozzáadása” gombot). Az első próbálkozás a „szerkesztés” gombbal nem sikerült.

„Észrevettem, hogy a szerkesztési párbeszédpanelen nincs egyértelmű módja a termékek hozzáadásának. Hadd próbáljak ki egy másik megközelítést a Viszonteladói rendelések legördülő menüre kattintva, hogy megnézzem, vannak-e más lehetőségek is.

Végül megtalálta az utat azáltal, hogy felfedezte a módját, hogyan adhat hozzá új tételeket a „Kapcsolódó” lapon keresztül – csak akkor, amikor az alkalmazás dinamikus triggerei nem frissítik automatikusan a rendelés végösszegét, akkor ez meghiúsult. Az SFDC alkalmazás fejlesztői nem fejezték be ennek a kódútvonalnak a fejlesztését, azt várták az emberi felhasználótól, hogy csak kövesse a drag and drop módszert. Röviden, az áramlást embereknek tervezték, nem mesterséges intelligencia-ügynöknek.

Claude ezután megpróbálta megtalálni a „feladás a gyártáshoz” gombot, amely egy egyedi fül alatt volt eltemetve. Mivel nem tudtak erről a lépésről, még néhány percig akadozott. Végül be kellett avatkoznom, manuálisan hozzá kellett adni a kerékpárt a rendeléshez, és rá kellett mutatnom Claude-ra a megfelelő gombra. Nagyjából 10 perc és körülbelül 0,80 USD használati költség után a folyamat még mindig nem volt teljesen automatizált. Könnyű volt belátni, hogy az Anthropic miért nevezi ezt a funkciót kísérletinek: sok valós védőkorlátra és fejlesztésre van szükség ahhoz, hogy a számítógéphasználat valóban gyártásra kész legyen.

Lehet jobb?

Durva élei ellenére a koncepció izgalmas. A GUI interakcióhoz szükséges látásalapú AI gyorsan javul, és a következtetések költséggörbéje gyorsan csökken. Egy nemrégiben készült a16z tanulmány azt sugallja, hogy ugyanazon teljesítmény mellett az LLM-költségek évente nagyjából tízszeresére csökkennek. Elvileg a Claude jövőbeli verziói gyorsabbak, olcsóbbak és pontosabbak lehetnek az olyan vizuális/térbeli feladatoknál, mint a drag and drop.

Az alapvető probléma azonban továbbra is fennáll, hogy a vállalati felhasználói felületek, különösen a régebbi vagy erősen testreszabottak, ritkán épülnek az automatizálásra. A pixelszintű interakciók törékenyek. Az elrendezés kisebb módosításai vagy a dinamikus előugró ablakok megszakíthatják a teljes folyamatot. Egyre növekszik a kutatás a vizuálisan megalapozott grafikus felhasználói felülettel kapcsolatban is, de ezeknek a több száz különböző munkafolyamathoz való termelési színvonalúvá tétele komoly feladat.

Fej nélküli böngészők: A grafikus felhasználói felület teljes kihagyása

Az egyik alternatív megközelítés a „vizuális határoló dobozok” teljes figyelmen kívül hagyása. Ha a célalkalmazás webböngészőben fut, akkor DOM-szinten automatizálhatja, kihagyva a képernyőképeket és a pixel-alapú interakciókat. Míg a hagyományos fej nélküli böngészőket, például a Playwrightot és a Seleniumot gyakran társítják tesztelési keretrendszerekkel, az AI-használati esetekre fókuszáló fej nélküli böngészők új generációja van kialakulóban. Ezek az újabb platformok a Playwright és a Selenium tetejére épülnek, hogy dinamikusabb, LLM-alapú interakciókat tegyenek lehetővé.

Böngészőbázis

A BrowserBase egy ilyen példa. Infrastruktúra-platformként működik, amely a böngésző munkameneteit tárolja és méretezi anélkül, hogy a fejlesztőknek konténereket kellene kezelniük. Az interakciós minta az oldal HTML-tartalmának az xPath-jukhoz társított komponensekké (pl. űrlapok, gombok) történő elemzése körül forog, és ezt a struktúrát átadja egy választott LLM-nek. Az LLM ezután előállítja a Playwright kód következő készletét a végrehajtásra, lehetővé téve a DOM-mal való interakciót kódon keresztül, nem pedig a hagyományos grafikus felhasználói felület kattintásait. Mivel tisztán fej nélküli, kevesebb képernyőképet használ, vagy egyáltalán nem használ képernyőképet, így a környezeti hossz rövidebb, a késleltetés pedig alacsonyabb, mint a teljes „asztali környezet” megközelítése.

Nemrég a BrowserBase szállította a StageHand nyílt forráskódú könyvtárát, hogy megkönnyítse a fejlesztők dolgát. Az eredeti modellben az interakciók még mindig nagyon manuálisak voltak, ezért a fejlesztőknek a fej nélküli böngésző alacsony szintű részleteivel kellett dolgozniuk, beleértve a Playwright kód közvetlen írását és a HTML manuális elemzését. A StageHand segítségével a BrowserBase magasabb szintű absztrakciót biztosít, lehetővé téve a fejlesztők számára, hogy intent-alapú természetes nyelvi parancsokat használjanak, mint például a „navigáció” vagy a „kivonás”. Ez a megközelítés bizonyos feldolgozási folyamatokat is magában foglal a nyers HTML komponensekké alakítására, megkönnyítve az LLM-nek a feladatok kezelését. A felhasználóknak azonban továbbra is létre kell hozniuk saját hangszerelési rétegeiket a munkafolyamatok összekapcsolásához és kezeléséhez, mivel maga a StageHand nem kínál beépített hangszerelést.

A BrowserBase teszteléséhez a fejlesztői játszóterüket használtam, amely konzolt biztosít a Playwright kód írásához, és egy LLM prompt írót, amely automatikusan létrehozza ezeket a szkripteket. Az ötlet az, hogy többlépcsős navigációt hajtson végre – jelentkezzen be, hozzon létre fiókot, hozzon létre egy viszonteladói rendelést. De a platform elvárja, hogy a lépéseket saját maga hangszerelje. A Claude-nak adott felszólítástól kezdve a BrowserBase megbotlott, mivel nem tudott többlépcsős módon gondolkodni. Ezért minden lépéshez természetes nyelvű promptot adtam, és megfigyeltem, hogy a generált Playwright kód azt csinálja-e, amit szándékoztunk. Az alábbi képernyőképen láthatja a promptok sorozatát és a hozzájuk generált Playwright kódot.

A gyakorlatban alkalmanként ütköztem bele a Playground böngészőkörnyezete és a kitöltendő HTML űrlapok közötti eltérésbe. A gombok furcsán jelennek meg, a várakozási idők meghosszabbodtak, és az űrlapmezők nem töltődtek be pontosan a várt módon. E hibák ellenére az LLM által generált Playwright kóddal sikerült bejelentkezni, fiókot létrehozni, és részben kitölteni a viszonteladói megrendelőlapot. Az elem hozzáadásának fogd-és vidd művelete azonban ismét buktató volt. Körülbelül hét percig foglalkoztam vele, mielőtt feladtam. Nyilvánvaló volt, hogy a platform még nem alkalmas ilyen típusú automatizálásra. Valószínűleg ez működik a legjobban a webkaparás felhasználási eseteiben.

Skyvern

A Skyvern egy több minden az egyben fej nélküli megközelítés, amely alapértelmezés szerint hangszerelést ad hozzá. A BrowserBase-től eltérően, amely megköveteli a felhasználóktól, hogy manuálisan határozzák meg és kezeljék a lépéseket, a Skyvern megpróbálja kezelni a hangszerelést. A motorháztető alatt a BrowserBase-hez hasonlóan működik – ahogy az a nyílt forráskódban is látható –, de egy webes ügynököt is hozzáad, amely képes megtervezni és megindokolni a lépéseket. Ez magában foglal egy opcionális látásmódot, amely képernyőképeket küld az LLM-nek a kibontott összetevőkkel és azok xPath-jaival együtt, hogy segítse a döntéshozatalt.

A BrowserBase-ben a kézi lépések létrehozásának korlátainak kiküszöbölése érdekében úgy döntöttem, hogy tesztelem a Skyvernt felügyelt szolgáltatásával, kifejezetten a munkafolyamat módra összpontosítva. Ezt a módot többlépcsős folyamatokhoz tervezték, és szerettem volna felmérni, hogy mennyire működik jól a Salesforce-munkafolyamattal. Sajnos a futás több mint 15 érvelési lépést és 1 dollárnyi jóváírást költött el a kéttényezős hitelesítési (2FA) folyamatban. A Skyvern hosztolt IP-címe meg lett jelölve, ami 2FA-t váltott ki, és nem lehetett manuálisan kódot adni vagy cookie-t megosztani a helyzet megkerülésére. Ez rávilágít a hitelesítés folyamatos kihívásaira a vállalati beállításokban, és rávilágít arra, hogy az olyan startupok, mint az Anon, miért csak az AI-ügynökök hitelesítési megoldásaira koncentrálnak.

A Skyvern csapata úgy pozícionálja a platformot, hogy alkalmas legyen egyszerűbb, kisebb feladatok elvégzésére, ahol a kapcsolatfelvételi űrlapok automatizálása az elsődleges támogatott használati eset. Más lehetséges felhasználási esetek (pl. állások, számlák) továbbra is „képzés alatt állóként” szerepelnek, jelezve, hogy a platform az egyszerű felhasználásra fókuszált automatizálással kezdődik, nem pedig a vállalati munkafolyamatok bonyolultabb igényeire. Bár ígéretes, egyértelmű, hogy a Skyvern jobban megfelel a kevésbé bonyolult forgatókönyveknek a fejlesztés ezen szakaszában.

Kompromisszumok

A fej nélküli böngészők kihagyják a pixelszintű találgatásokat, ami gyakran kevesebb hibához és gyorsabb végrehajtáshoz vezet. De amint eléri a speciális funkciókat, például a fogd és vidd vagy az összetett egyoldalas alkalmazásokat, előfordulhat, hogy vissza kell térnie a részleges képernyőkép-elemzéshez vagy a speciális kódhoz. A böngészők a 2FA és az IP feketelistájába is belefuthatnak. Több bérlős vállalati alkalmazások esetén a hitelesítés önmagában trükkös lehet, és továbbra is szükség lehet egyéni hangszerelési rétegekre.

Egy másik korlátozás az, hogy ezek a platformok a munkafolyamat minden egyes végrehajtásakor dinamikusan generálnak kódot LLM-eken keresztül. Mivel az LLM-ek természetüknél fogva nem determinisztikusak, a kimeneti kód futásokonként változhat, ami kihívást jelent az auditálás vagy a konzisztencia ellenőrzése során. Ez a kiszámíthatatlanság problémákhoz vezethet, különösen az érzékeny munkafolyamatoknál. Bár úgy tűnik, hogy a generált kód gyorsítótárazása bizonyos platformok ütemtervében szerepel, jelentős kihívásokat jelent az LLM-ek számára. Még az azonnali vagy kötegelt feldolgozásban a következtetés során végrehajtott kisebb változtatások is teljesen eltérő eredményeket eredményezhetnek, megnehezítve a gyorsítótárazási folyamatot.

Összességében elmondható, hogy a fej nélküli böngészés olcsóbb és stabilabb lehet, mint a teljes grafikus felhasználói felület manipulálása, de messze van a varázslatos megoldástól. Sok megoldás, mint például a BrowserBase és a Skyvern, a szűkebb felhasználási esetekre összpontosít (pl. űrlapok, adatkinyerés), ahelyett, hogy „mindent automatizálnának egy platformot”.

Reverse Engineering belső API-k

A harmadik megközelítés a weboldal teljes megkerülése azáltal, hogy elfogja azokat a hálózati hívásokat, amelyek akkor történnek, amikor rákattint. Ha rögzíteni tudja a böngészője által küldött kéréseket, akkor ezeket a hívásokat kódban is rekonstruálhatja. Ez elvileg elkerüli a zűrzavaros UI-alapú lépéseket, és biztosítja, hogy ugyanazt a háttérlogikát érje el, amelyet az alkalmazás is használ. Ez a tendencia nem teljesen új, mivel a reverse-engineering API-k már régóta léteznek. Az új kiegészítés azonban egy mesterséges intelligencia-ügynököt tartalmaz a hálózati kérések megfontolására, így a folyamat intelligensebbé és alkalmazkodóbbá válik.

Néhány hónappal ezelőtt az Integuru nevű termék megjelent a Hackernews-on , és nyílt forráskódú megközelítésével és újszerű módszertanával hívta fel magára a figyelmet. Érdekelt a benne rejlő lehetőségek, és elhatároztam, hogy tesztelem, mivel érdekes gráf-alapú megközelítése és az AI-ügynökök integrációja a hálózati kérések érvelésére szolgál. Az az ígéret, hogy drasztikusan csökkenti az automatizálás idejét és költségeit, lenyűgöző lehetőséget kínál a felfedezésre.

Az Integuru tárolója viszonylag új, de ígéretes. Lényegében rögzíti az összes hálózati forgalmat és cookie-kat a Chromiumban egy feladat során. Ezután létrehozza a kérések grafikonos ábrázolását, leképezve, hogy mely oldalak melyik végpontot hívják meg. Ezzel a grafikonnal bejárást hajt végre, átadva azt egy LLM-nek, hogy kódot generáljon minden egyes csomóponthoz, amely ugyanazokat a kéréseket játssza le, szükség szerint beinjektálja a dinamikus paramétereket (például a „Bike Production Company”), és összeállítja azokat a függőségek alapján. Ez a megközelítés elméletileg jelentősen leegyszerűsítheti az automatizálási folyamatot.

A gyakorlatban azonban nem működött jól a mi használati esetünkben, főleg a kontextusablak korlátai miatt. Lehet, hogy az áramlás túl hosszú volt ahhoz, hogy az LLM hatékonyan kezelje. Még a bejelentkezési cookie-k közvetlen beágyazásával és a kezdőlapról történő indítással történő rövidzárlati kísérletek sem jártak sikerrel. Bár gyanítom, hogy az alacsony szintű OpenAI API-kulcsom hozzájárult ezekhez a problémákhoz, egyértelmű, hogy az Integuru még mindig a kezdeti időszakában van. A potenciál megvan, de a termék további finomítást igényel. Demói (például az adózási dokumentumok letöltése a Robinhoodtól) a modern webes keretrendszereken működtek a legjobban, egyszerűbb folyamatokkal. A Salesforce bonyolult kezelőfelületével és labirintusszerű egyedi objektumaival hibákat vezetett be.

Ez a módszer azonban még nem univerzális megoldás. Az összes lépés rögzítésének szükségessége korlátozza a rugalmasságát, és egy statikusabb megközelítés felé hajlik, amely előre meghatározott folyamokhoz kódot állít elő, emlékeztetve az egy évtizeddel ezelőtt népszerű szabályalapú RPA-eszközökre. Ez rávilágít egy alapvető korlátra: bár a mesterséges intelligencia indoklásának hozzáadása a hálózati kérésekhez izgalmas, és megnyithatja az ajtókat az API-val nem rendelkező rendszerekkel való integráció előtt, mégis jobban megfelel kontrolláltabb vagy ismételt feladatokhoz, mint dinamikus, változatos munkafolyamatokhoz. vállalati környezetek.

AgentForce: A Salesforce natív megoldása

A AI-vezérelt automatizálásról a Salesforce-ban egyetlen beszélgetés sem lenne teljes az AgentForce megemlítése nélkül, amely Marc Benioff nagy tétje, hogy „ügynököket” építsen a Salesforce ökoszisztémán belül. A fent tesztelt többi megoldástól eltérően, amelyek fejlesztőközpontúak, és célja a munkafolyamatok automatizálása a különböző rendszerek között, az AgentForce alacsony kódszámú, beágyazott megoldásként van elhelyezve, kifejezetten a Salesforce számára. Számos összetevőt csomagol össze, és a Salesforce platformon belüli teljes folyamatra összpontosít.

Az ötlet az, hogy olyan ügynököket hozzanak létre, amelyek teljes mértékben a Salesforce-ban vannak, és az Ön testreszabásaira építenek. A felhasználók meghatározzák az ügynök általános leírását, hozzárendelhetik a témaköröket, és hozzárendelhetik a kapcsolódó műveleteket, amelyek kódban vagy a Salesforce UI-n keresztül előre beépített folyamatok. Ezután a rendszer beállítja az engedélyeket, a felhasználói szerepköröket és az utasításokat, hogy lehetővé tegye az ügynök működését. Ez a koncepció elméletileg lehetővé teszi a vállalkozások számára, hogy meglévő Salesforce-adataikat és munkafolyamataikat széleskörű kódolás nélkül hajtsák végre az automatizálás érdekében.

Az AgentForce-t közvetlenül az eBikes viszonteladói rendelési példánkkal akartam tesztelni. Sajnos az Einsteinhez (AI-funkciókhoz) való hozzáférés szükséges, ami ingyenes fejlesztői fiókban nem érhető el. Ehelyett felfedeztem a 30 perces játszóterüket a kitalált „Coral Beach Resort” alkalmazással. A tesztfeladat egy ügynök konfigurálása volt, hogy automatizálja a foglalás létrehozását. Ez a folyamat némileg analóg a viszonteladói megrendeléshez az eBikes forgatókönyvünkben.

A beállítás meglehetősen bonyolult volt, több lépést igényelt: engedélyek meghatározása, témák engedélyezése, csatlakozás az előre elkészített műveletekhez, adatmezők leképezése és az utasítások tisztázása. Miközben alacsony kódú megoldásként forgalmazták, világossá vált, hogy a Salesforce bonyolultságainak jelentős ismeretére van szükség. Ha egy vállalat Salesforce-példánya nem tartalmaz jól dokumentált egyéni mezőket és előre konfigurált műveleti folyamatokat, akkor a kezdeti növekedés jelentős lehet. Valószínűleg a legtöbb vállalkozásnak rendszerintegrátorokat vagy tanácsadókat kellene bevonnia ezen ügynökök teljes körű megvalósításához és optimalizálásához.

Az AgentForce szabályalapú természete is kitűnt. A felhasználóknak gondosan fel kell térképezniük a kitöltött vagy átadott mezőket, hogy az automatizálás pontosan működjön, így gyakorlatiasabb, mint egyes AI-vezérelt platformok. Bár ez a megközelítés biztosítja a pontosságot, megerősíti az erős Salesforce-szakértelemtől és a meglévő infrastruktúrától való függőséget.

Míg az AgentForce a Salesforce ökoszisztémájára korlátozódik, ennek vannak előnyei és hátrányai is. Egyrészt ez egy olyan csomagolt megoldás, amely egyetlen platformon belül egyesíti a hitelesítést, a felhasználói engedélyeket, az eszközdefiníciókat és a hangszerelési logikát. Másrészt sok vállalati munkafolyamat több rendszert is átölel, és az AgentForce szilárd jellege korlátozza a szélesebb körű automatizálási igényekre való alkalmazhatóságát. Marc Benioff kijelentette, hogy ügyfelek százai írták alá már az AgentForce használatára vonatkozó szerződéseket, így annak alakulását érdemes lesz figyelemmel kísérni.

Szóval… Ott vagyunk már?

Ezekből a kísérletekből világossá vált, hogy a jelenlegi AI-ügynök-megoldások tisztességes munkát végeznek a többlépcsős feladatok okoskodásában és a terv kidolgozásában. Az igazi kihívás a végrehajtás egy rendetlen, valós környezetben, törzsi tudással arról, hogy ezek a rendszerek hogyan viselkednek valójában. A grafikus felhasználói felületek az emberi interakcióhoz készültek, és minden vállalat egyedi logikája olyan, mint egy bonyolult mini fekete lyuk. Még ha kihagyja is a grafikus felhasználói felületet a fejetlen megközelítés érdekében, vagy visszafejti a háttér API-kat, akkor is szembe kell néznie szélsőséges esetekkel, hitelesítési akadályokkal, sebességkorlátokkal vagy dinamikus munkafolyamatokkal, amelyek az LLM-ek legjobbjait dobják ki.

A fennmaradó kihívásokat túlnyomórészt mérnöki problémák jelentik: robusztus eszközök kiépítése, mélyreható integráció a vállalati rendszerekkel, korlátok kialakítása, valamint megbízható felügyeleti és hangszerelési keretrendszerek létrehozása. Ezek dedikált erőfeszítéssel és specializációval megoldhatók. A mai LLM-ek már jóval meghaladja az egy évvel ezelőtti érvelési képességeket, és költségük gyorsan csökken. A hangsúlyt most az e képességek hatékony kiépítéséhez szükséges infrastruktúra és folyamatok kiépítésére kell helyezni.

Ezek a nehézségek azonban nem árnyékolhatják be a folyamatos fejlődést. Már látunk speciális, vertikálisan fókuszált mesterséges intelligencia automatizálásokat (pl. SDR vagy ügyfélszolgálati ügynökök), amelyek nagy pontosságot tudnak biztosítani egy ellenőrzött tartományban. Ahogy az egyszer használatos automatizálások mindegyike kifejlődik, láthatjuk, hogy szélesebb munkafolyamatokba láncolják őket. Végső soron így lehet feltörni a nagyvállalatok teljes körű automatizálását: több speciális ügynököt kombinálva, ahelyett, hogy egyetlen általános célú ügynöktől várnánk el mindent. Egyelőre a nulláról induló ügynök létrehozásának megtérülése nem biztos, hogy a legnagyobb volumenű feladatokon kívül mindenre alkalmas.

Specializáció és az előttünk álló út

E tesztek egyik tanulsága a specializáció fontossága. A szinte tökéletes megbízhatóság elérése egyetlen tartományban (például számlák létrehozása a NetSuite-ban) jelentős finomhangolást igényel. Azok az induló vállalkozások vagy belső csapatok, amelyek egyetlen speciális munkafolyamatra összpontosítanak, jobb élményt nyújthatnak, mint egy átfogó, általános megoldás. Már most látjuk a „vertikális ügynökök” hullámát, amelyek célzott feladatokat látnak el a pénzügy, a logisztika, a HR vagy az ellátási lánc területén. Mindegyik ügynök mélyen integrálódna, esetleg kombinálná a felhasználói felület automatizálását, ha szükséges, közvetlen API-hívásokkal, valamint tartományspecifikus tartalék logikával és védőkorlátokkal.

A nagy kérdés továbbra is fennáll: 2025 valóban az az év lesz, amikor ezek az ügynökök bekerülnek a mainstreambe, vagy hosszabb kifutópályát keresünk? A technológia gyorsan fejlődik, és bővelkedik az optimizmus. De ahogy a szoftvermérnökök sem tűntek el, amikor a kódgenerálás javult, valószínűleg nem fogjuk látni a „kihangosított” vállalati automatizálást minden folyamatban. Ehelyett ismétlődő fejlesztéseket fogunk látni a speciális zsebekben, végül részleges automatizálások mozaikjaként összefűzve őket.

Következtetés

Az autonóm AI-ügynökök koncepciója tagadhatatlanul lenyűgöző, különösen olyan vállalati környezetben, ahol bővelkedik az ismétlődő feladatok. A lehetséges előnyök – az időmegtakarítás, a hibák csökkentése és az alkalmazottak kreatívabb és stratégiaibb munkára összpontosítása – óriásiak. Bár az AI-ügynökök alapvető képességei erősek, a széles körben elterjedt alkalmazáshoz vezető út a mérnöki kihívások leküzdésén múlik, valamint az alapul szolgáló kutatás előmozdításán.

A megfelelő infrastruktúra kiépítése kulcsfontosságú: robusztus szerszámok, megbízható integrációk és tartományspecifikus megoldások jól meghatározott védőkorlátokkal és hangszerelési rétegekkel. A valós vállalati rendszerek összetettsége speciális megoldásokat igényel, és a vertikális ügynökök itt tudnak kiemelkedni. A szűk, jól definiált munkafolyamatokra való összpontosítás lehetővé teszi a csapatok számára, hogy nagy pontossággal és megbízhatósággal finomítsák megoldásaikat, megbirkózva az egyes tartományok egyedi kihívásaival. Idővel ezek a speciális ügynökök összekapcsolódhattak, és az automatizálások szélesebb hálózatát hozhatták létre.

2025 lenyűgöző előrelépéseket és egyre több kísérleti programot hozhat. Ahelyett, hogy egy robotpilóta világban futnánk, nagyobb valószínűséggel látunk célzott, rendkívül hatékony automatizálásokat, amelyek speciális problémákat kezelnek. A teljes vállalati automatizálás felé vezető út iteratív lesz, amelyet a specializáció és az együttműködés vezérel. A lendület erősödik, és ezeknek a mérnöki kihívásoknak a megoldása előkészíti az utat a vállalati innováció következő hulláma előtt.

(Kiemelt képek a DALL-E-hez)