2025 ar putea fi anul agenților AI, dacă pot supraviețui iadului întreprinderilor

De zeci de ani, companiile au căutat să automatizeze sarcinile de back-office, introducerea datelor, procesele de facturare și alte fluxuri de lucru repetitive. Dar chiar dacă software-ul a evoluat, automatizarea adevărată end-to-end rămâne evazivă pentru majoritatea întreprinderilor. Acum, odată cu creșterea rapidă a modelelor de limbaj mari (LLM) și apariția „agenților AI” capabili să raționeze și să acționeze în mod autonom, există o credință tot mai mare că 2025 ar putea fi anul în care vedem în sfârșit un salt înainte semnificativ în automatizarea întreprinderilor.

Sam Altman a declarat public că „în 2025, putem vedea primii agenți AI să se alăture forței de muncă și să schimbe material producția companiilor”, în timp ce Marc Benioff orientează Salesforce către „AgentForce” în așteptarea unui viitor în care multe procese organizaționale sunt delegate. la agentii specializati. Aceste predicții ridică o întrebare centrală: pot agenții AI să depășească obstacolele complicate ale sistemelor întreprinderilor din lumea reală? În acest articol, vom examina dificultățile unice ale automatizării întreprinderilor și vom explora unele dintre soluțiile promițătoare (dar încă în curs de maturizare) de astăzi. De asemenea, vom împărtăși teste practice cu un flux de lucru aparent simplu în Salesforce (SFDC) - crearea unei comenzi de reseller pentru un cont nou - care dezvăluie complexitatea care se ascunde în spatele scenei.

De ce este automatizarea întreprinderii atât de provocatoare?

Pe hârtie, automatizarea sarcinilor companiei sună simplă: rotiți un script pentru a vă conecta, completați formulare și faceți clic pe „Trimite”. În practică, complexitatea este uluitoare. Întreprinderile se bazează pe o multitudine de sisteme de înregistrări, cum ar fi Salesforce, SAP, Oracle și o mulțime de soluții locale. Fiecare sistem are propriul său web de permisiuni, fluxuri de autentificare și logică de afaceri personalizată. În plus, aceste sisteme sunt adesea puternic personalizate. Este obișnuit să vedeți interfețe de utilizare specializate, câmpuri de date suplimentare și fluxuri de lucru personalizate care diferă de la o companie la alta.

Potrivit unui sondaj comun realizat de MuleSoft și Deloitte, întreprinderile mari pot folosi în medie 976 de sisteme diferite pentru a susține operațiunile zilnice ( sursa ). Această fragmentare înseamnă că un instrument de automatizare trebuie să comunice cu mai multe sisteme, fiecare cu propria sa nuanță; unele cu API-uri robuste, altele cu deloc. Adesea, cele mai simple sarcini implică conectarea datelor între aplicații vechi, vechi și servicii noi bazate pe cloud. Chiar și platformele standard, cum ar fi Salesforce, pot deveni labirintice odată ce fluxurile de lucru personalizate și integrările terțelor părți sunt în vigoare.

În acest context, agenții bazați pe LLM promit o abordare mai flexibilă: ei pot analiza datele, pot motiva pașii următori și chiar pot naviga în interfețe grafice complicate - cel puțin în teorie. Dar, așa cum veți vedea în exemplul următor, realitatea de a determina un agent AI să facă chiar și un flux de lucru de bază Salesforce fără ajutor uman este mai complicată decât își dau seama mulți.

Un exemplu practic: crearea unei comenzi de reseller personalizată în Salesforce

Sarcina

Imaginează-ți că ești asociat de vânzări la o companie de producție de biciclete care folosește Salesforce. Tocmai ați vândut o bicicletă mare Dynamo X1 pentru 5.000 USD unui nou reseller numit „Northern Trail Cycling”. Sarcina ta este de a:

1 - Autentificați-vă la Salesforce (cu acreditările furnizate).

2 - Creați un cont nou pentru reseller.

3 - Creați o comandă de reseller și adăugați elementul rând (bicicleta).

4 - Trimiteți comanda către producție pentru aprobare.

Pentru o execuție cu succes, ne așteptăm ca rezultatul final să arate astfel:

Pare destul de simplu, dar diavolul este în detalii. Instanța Salesforce a companiei este personalizată: folosește un obiect și un flux personalizat de „comandă de reseller”, o funcție specială de glisare și plasare pentru adăugarea produselor și un pas ascuns de „trimitere la fabricație”, fără etichetare clară. Am testat acest scenariu folosind mai multe abordări emergente de automatizare bazate pe inteligență artificială pentru a vedea cum se potrivesc.

Claude Utilizarea computerului

Ce este?

Claude Computer Use este o caracteristică nouă de la Anthropic, introdusă cu Claude 3.5 Sonnet v2 . Este nevoie de paradigma standard de apelare a funcțiilor LLM cu un pas mai departe, oferindu-i lui Claude un întreg mediu desktop containerizat pentru a „vedea” și „controla”. Poate captura capturi de ecran, le poate interpreta prin raționament vizual/spațial și poate efectua acțiuni la nivel de sistem de operare, cum ar fi clicuri de mouse, derulări și apăsări de taste.

Din perspectiva unui utilizator, îi dați lui Claude o sarcină de nivel înalt („Conectați-vă la Salesforce și creați această comandă de reseller”), iar Claude încearcă să facă exact asta. Se trece printr-o secvență de:

1. Capturarea unei capturi de ecran și interpretarea acesteia.
2. Emiterea de acțiuni în interfața de utilizare (clicuri de mouse, apăsări de taste, comenzi bash).
3. Repetând până când sarcina este finalizată (sau renunță).

Punând-o la încercare

Să începem cu cea mai simplă abordare a rulării implementării de referință a Anthropic fără nicio modificare a promptului de sistem . Aici este începutul interacțiunii care arată promptul inițial, planul propus de Claude și desktopul cu care începe interacțiunea.

Observarea desktopului containerizat al lui Claude a fost inițial impresionantă. A deschis browserul, a vizitat adresa URL Salesforce, s-a conectat cu acreditările furnizate și a navigat la „Conturi”. A creat perfect un cont nou pentru Bike Production Company , introducând detaliile potrivite în formular, apoi a încercat să creeze o nouă comandă de distribuitor. Lucrurile au mers fără probleme până când a întâlnit interfața personalizată cu drag-and-drop pentru adăugarea bicicletei. Sistemul a rămas blocat încercând să efectueze un drag-and-drop bazat pe pixeli.

După câteva eșecuri, a încercat să găsească o metodă alternativă (cum ar fi un buton ascuns „Adăugați element”). Prima încercare cu butonul „editare” nu a reușit.

„Observ că în dialogul de editare nu există o modalitate clară de a adăuga produse. Permiteți-mi să încerc o abordare diferită făcând clic pe meniul drop-down Comenzi pentru reseller pentru a vedea dacă există alte opțiuni”.

În cele din urmă, și-a găsit drumul prin descoperirea unei modalități de a adăuga articole noi prin fila „corelate” - doar pentru a eșua atunci când declanșatoarele dinamice ale aplicației nu ar actualiza automat totalul comenzii. Dezvoltatorii aplicației SFDC nu au finalizat dezvoltarea acestei căi de cod, așteptându-se ca utilizatorul uman să urmeze doar metoda de glisare și plasare. Pe scurt, fluxul a fost conceput pentru oameni, nu pentru un agent AI.

Claude a încercat apoi să găsească butonul „Trimite la fabricație”, care a fost îngropat sub o filă personalizată. Neavând cunoștințe prealabile despre acest pas, s-a zdruncinat încă câteva minute. În cele din urmă, a trebuit să intervin, să adaug manual bicicleta la comandă și să-l îndrept pe Claude către butonul corespunzător. După aproximativ 10 minute și aproximativ 0,80 USD în costuri de utilizare, procesul încă nu a fost complet automatizat. A fost ușor de înțeles de ce Anthropic numește această funcție experimentală: sunt necesare multe balustrade și îmbunătățiri din lumea reală înainte ca Utilizarea computerului să poată fi cu adevărat pregătită pentru producție.

Poate deveni mai bine?

În ciuda marginilor sale aspre, conceptul este incitant. Inteligența artificială bazată pe viziune pentru interacțiunea GUI se îmbunătățește rapid, iar curba costurilor pentru inferență scade rapid. Un studiu recent a16z sugerează că, pentru aceeași performanță, costurile LLM scad de aproximativ 10 ori pe an. În principiu, versiunile viitoare ale lui Claude ar putea deveni mai rapide, mai ieftine și mai precise la sarcini vizuale/spațiale precum drag-and-drop.

Cu toate acestea, problema fundamentală rămâne aceea că interfețele de utilizator pentru întreprinderi, în special cele mai vechi sau puternic personalizate, sunt rareori construite având în vedere automatizarea. Interacțiunile la nivel de pixeli sunt fragile. Modificările minore ale aspectului sau ferestrele pop-up dinamice pot întrerupe întregul flux. Există, de asemenea, cercetări în creștere în ceea ce privește cadrele GUI bazate vizual, dar realizarea acestor produse de calitate pentru sute de fluxuri de lucru diferite este o întreprindere majoră.

Browsere fără cap: Omiterea completă a GUI

O abordare alternativă este de a ignora în întregime „casetele de delimitare vizuale”. Dacă aplicația dvs. țintă rulează într-un browser web, puteți automatiza la nivel DOM, sărind capturi de ecran și interacțiuni bazate pe pixeli. În timp ce browserele tradiționale fără cap, cum ar fi Playwright și Selenium, sunt adesea asociate cu cadre de testare, apare o nouă generație de browsere fără cap axate pe cazuri de utilizare AI. Aceste platforme mai noi se bazează pe Playwright și Selenium pentru a permite interacțiuni mai dinamice, bazate pe LLM.

BrowserBase

BrowserBase este un astfel de exemplu. Funcționează ca o platformă de infrastructură care găzduiește și scalează sesiunile de browser fără a solicita dezvoltatorilor să gestioneze containerele. Modelul de interacțiune se învârte în jurul analizării conținutului HTML al unei pagini în componente (de exemplu, formulare, butoane) mapate la xPath-urile lor și transmiterea acestei structuri la un LLM la alegere. LLM generează apoi următorul set de cod Playwright de executat, permițând interacțiunea cu DOM prin intermediul codului, mai degrabă decât prin clicuri tradiționale GUI. Deoarece este pur fără cap, folosește mai puține capturi de ecran sau deloc, păstrând lungimea contextului scurtă și latența mai mică decât o abordare completă de „mediu desktop”.

Mai recent, BrowserBase și-a livrat biblioteca StageHand open-source pentru a ușura lucrurile pentru dezvoltatori. În modelul original, interacțiunile erau încă foarte manuale, necesitând dezvoltatorilor să lucreze cu detaliile de nivel scăzut ale browserului fără cap, inclusiv scrierea directă a codului Playwright și analizarea manuală a HTML. Cu StageHand, BrowserBase oferă un nivel mai ridicat de abstractizare, permițând dezvoltatorilor să folosească comenzi în limbaj natural bazate pe intenții, cum ar fi „navigați” sau „extractați”. Această abordare include, de asemenea, unele procesări pentru a converti HTML brut în componente, facilitând gestionarea sarcinilor de către LLM. Cu toate acestea, utilizatorii trebuie să își creeze propriile straturi de orchestrare pentru a se conecta și a gestiona fluxurile de lucru, deoarece StageHand în sine nu oferă orchestrare încorporată.

Pentru a testa BrowserBase, am folosit terenul de joacă pentru dezvoltatori, care oferă o consolă pentru scrierea codului Playwright și un scriitor de prompt LLM pentru a produce automat acele scripturi. Ideea este să faceți o navigare în mai mulți pași - conectați-vă, creați un cont, creați o comandă de distribuitor. Dar platforma se așteaptă ca tu să orchestrezi singur pașii. Începând cu același prompt dat lui Claude, BrowserBase s-a împiedicat, deoarece nu a putut să raționeze în mai mulți pași. Așa că am continuat să ofer un prompt în limbaj natural pentru fiecare pas și am observat dacă codul Playwright generat făcea ceea ce era intenționat. În captura de ecran de mai jos, puteți vedea seria de solicitări și codul Dramaturg generat.

În practică, am întâlnit ocazional nealiniere între mediul browser al Playground-ului și formularele HTML care trebuiau completate. Butoanele au fost randate ciudat, timpii de așteptare au fost prelungiți, iar câmpurile de formular nu s-au încărcat exact așa cum se aștepta. În ciuda acestor erori, codul Playwright generat de LLM a reușit să se conecteze, să creeze un cont și să completeze parțial formularul de comandă pentru reseller. Cu toate acestea, glisarea și plasarea pentru a adăuga elementul a fost din nou o piatră de poticnire. Mi-am petrecut aproximativ șapte minute mângâindu-l înainte de a renunța. Era clar că platforma nu este încă potrivită pentru un astfel de tip de automatizare. Probabil funcționează cel mai bine pentru cazurile de utilizare a web scraping.

Skyvern

Skyvern este o abordare mai all-in-one fără cap, care adaugă orchestrare în mod implicit. Spre deosebire de BrowserBase, care impune utilizatorilor să definească și să gestioneze manual pașii, Skyvern încearcă să gestioneze orchestrarea imediat. Sub capotă, funcționează similar cu BrowserBase - așa cum se vede în codul lor open-source - dar adaugă și un agent web care poate orchestra și raționa pașii. Acesta include un mod opțional de viziune care trimite capturi de ecran la LLM împreună cu componentele extrase și xPath-urile acestora pentru a ajuta la luarea deciziilor.

Pentru a aborda limitările creării manuale a pașilor în BrowserBase, am decis să testez Skyvern folosind serviciul său gestionat, concentrându-mă în mod special pe modul Workflow. Acest mod este conceput pentru procese în mai mulți pași și am vrut să evaluez cât de bine funcționează cu fluxul nostru de lucru Salesforce. Din păcate, cursa a cheltuit peste 15 pași de raționament și 1 USD din credite blocate în procesul de autentificare cu doi factori (2FA). IP-ul găzduit de Skyvern a fost semnalat, declanșând 2FA și nu a existat nicio modalitate de a furniza manual un cod sau de a partaja un cookie pentru a ocoli situația. Acest lucru evidențiază provocarea continuă a autentificării în setările întreprinderii și subliniază de ce startup-uri precum Anon apar să se concentreze exclusiv pe soluții de autentificare pentru agenții AI.

Echipa Skyvern poziționează platforma ca fiind potrivită pentru sarcini mai simple și mai mici, automatizarea formularelor de contact fiind cazul de utilizare principal acceptat. Alte cazuri potențiale de utilizare (de exemplu, Locuri de muncă, Facturi) sunt încă listate ca „în curs de formare”, ceea ce indică faptul că platforma începe cu o automatizare simplă axată pe caz de utilizare, mai degrabă decât cu nevoile mai complexe ale fluxurilor de lucru ale întreprinderii. Deși promițător, este clar că Skyvern este mai potrivit pentru scenarii mai puțin complicate în această etapă a dezvoltării sale.

Compensații

Browserele fără cap omit ipotezele la nivel de pixeli, ceea ce duce adesea la mai puține erori și la o execuție mai rapidă. Dar, de îndată ce accesați funcții avansate, cum ar fi drag-and-drop sau aplicații complexe cu o singură pagină, poate fi necesar să reveniți la analiza parțială a capturii de ecran sau la codul specializat. Browserele ar putea, de asemenea, să intre în lista neagră 2FA și IP. Pentru aplicațiile de întreprindere cu mai mulți chiriași, autentificarea singură poate fi dificilă și este posibil să aveți nevoie în continuare de straturi de orchestrare personalizate.

O altă limitare este că aceste platforme se bazează pe generarea de cod în mod dinamic prin LLM-uri de fiecare dată când fluxul de lucru este executat. Deoarece LLM-urile sunt în mod inerent nedeterministe, codul rezultat poate varia în funcție de rulări, ceea ce face dificilă auditarea sau verificarea coerenței. Această imprevizibilitate poate duce la probleme, în special în fluxurile de lucru sensibile. În timp ce memorarea în cache a codului generat pare să fie pe foaia de parcurs pentru unele platforme, aceasta reprezintă provocări semnificative pentru LLM. Chiar și modificări minore ale procesării prompte sau în lot în timpul inferenței pot produce rezultate complet diferite, complicând procesul de stocare în cache.

În general, navigarea fără cap poate fi mai ieftină și mai stabilă decât manipularea completă a GUI, dar este departe de a fi o soluție magică. Multe soluții, cum ar fi BrowserBase și Skyvern, se concentrează pe cazuri de utilizare mai restrânse (de exemplu, formulare, extragerea datelor), mai degrabă decât să fie „unica platformă pentru automatizarea tuturor”.

API-uri interne de inginerie inversă

O a treia abordare este de a ocoli pagina web prin interceptarea apelurilor de rețea care au loc atunci când faceți clic în jur. Dacă puteți captura solicitările pe care le trimite browserul dvs., puteți reconstrui acele apeluri în cod. În principiu, acest lucru evită pașii dezordonați bazați pe interfața de utilizare și vă asigură că atingeți aceeași logică backend pe care o folosește aplicația dvs. Această tendință nu este cu totul nouă, deoarece API-urile de inginerie inversă există de mult timp. Cu toate acestea, noua adăugare încorporează un agent AI pentru a raționa cererile rețelei, făcând procesul mai inteligent și mai adaptabil.

În urmă cu câteva luni, un produs numit Integuru a fost lansat pe Hackernews și a atras atenția pentru abordarea open-source și metodologia nouă. Intrigat de potențialul său, am decis să-l testez, atras de abordarea sa interesantă bazată pe grafice și de integrarea agenților AI pentru a raționa cererile rețelei. Promisiunea de a reduce drastic timpul și costul automatizării a făcut din aceasta o opțiune convingătoare de explorat.

Depozitul lui Integuru este relativ nou, dar arată promițător. În esență, înregistrează tot traficul de rețea și cookie-urile în Chromium în timpul unei sarcini. Apoi creează o reprezentare grafică a solicitărilor, mapând paginile care apelează la ce puncte finale. Folosind acest grafic, efectuează o traversare, trecându-l într-un LLM pentru a genera cod pentru fiecare nod care redă aceleași solicitări, injectând parametrii dvs. dinamici (cum ar fi „Compania de producție de biciclete”) după cum este necesar și împletindu-i pe baza dependențelor. Această abordare ar putea teoretic eficientiza procesul de automatizare în mod semnificativ.

În practică, totuși, nu a funcționat bine pentru cazul nostru de utilizare, mai ales din cauza limitărilor ferestrei de context. Fluxul s-ar putea să fi fost prea lung pentru ca LLM să se descurce eficient. Nici măcar încercările de a scurtcircuita procesul prin încorporarea directă a cookie-urilor de conectare și pornind de la pagina de pornire nu au reușit. Deși bănuiesc că cheia mea API OpenAI de nivel inferior a contribuit la aceste probleme, este clar că Integuru este încă la început. Potențialul există, dar produsul necesită o rafinare suplimentară. Demo-urile sale (cum ar fi descărcarea documentelor fiscale de la Robinhood) au funcționat cel mai bine pe cadre web moderne, cu fluxuri mai simple. Salesforce, cu front-end-ul său complicat și obiectele personalizate labirintice, a introdus erori.

Acestea fiind spuse, această metodă nu este încă o soluție universală. Nevoia de a înregistra toți pașii îi limitează flexibilitatea și se înclină spre o abordare mai statică de generare în avans a codului pentru fluxuri specifice, care amintește de instrumentele RPA bazate pe reguli populare cu un deceniu în urmă. Acest lucru evidențiază o limitare fundamentală: în timp ce adăugarea raționamentului AI la solicitările de rețea este interesantă și poate deschide ușile pentru integrarea cu sisteme care nu au API-uri, este totuși mai potrivită pentru sarcini mai controlate sau repetate decât pentru fluxuri de lucru dinamice și diverse în medii de întreprindere.

AgentForce: soluția nativă Salesforce

Nicio conversație despre automatizarea bazată pe inteligență artificială în Salesforce nu ar fi completă fără a menționa AgentForce , marele pariu al lui Marc Benioff pentru construirea de „agenți” în cadrul ecosistemului Salesforce. Spre deosebire de alte soluții pe care le-am testat mai sus, care sunt axate pe dezvoltatori și au ca scop automatizarea fluxurilor de lucru în diferite sisteme, AgentForce este poziționată ca o soluție încorporată cu cod redus, special pentru Salesforce. Acesta împachetează multe componente și se concentrează pe întregul flux din cadrul platformei Salesforce.

Ideea este să creați agenți care locuiesc pe deplin în Salesforce și să se bazeze pe personalizările dvs. Utilizatorii definesc descrierea generală a unui agent, atribuie subiecte și leagă acțiunile asociate, care sunt fluxuri predefinite definite fie în cod, fie prin interfața de utilizare Salesforce. Permisiunile, rolurile utilizatorului și instrucțiunile sunt apoi configurate pentru a permite funcționarea agentului. Acest concept teoretic permite companiilor să-și folosească datele și fluxurile de lucru Salesforce existente pentru a conduce automatizarea fără codificare extinsă.

Am vrut să testez AgentForce direct cu exemplul nostru de comandă pentru reseller eBikes. Din păcate, este necesar accesul la Einstein (funcții AI), care nu este disponibil într-un cont de dezvoltator gratuit. În schimb, am explorat locul lor de joacă de 30 de minute cu aplicația fictivă „Coral Beach Resort”. Sarcina de testare a fost de a configura un agent pentru a automatiza crearea unei rezervări, un proces oarecum analog cu o comandă de reseller în scenariul nostru eBikes.

Configurarea a fost destul de implicată, necesitând mai mulți pași: definirea permisiunilor, activarea subiectelor, conectarea la acțiuni predefinite, maparea câmpurilor de date și instrucțiunile de clarificare. Deși a fost comercializată ca o soluție low-code, a devenit clar că sunt necesare cunoștințe semnificative despre complexitățile Salesforce. Dacă instanța Salesforce a unei companii nu are câmpuri personalizate bine documentate și fluxuri de acțiuni preconfigurate, creșterea inițială poate fi substanțială. În mod realist, majoritatea companiilor ar trebui probabil să aducă integratori de sistem sau consultanți pentru a implementa și optimiza pe deplin acești agenți.

Natura bazată pe reguli a lui AgentForce a ieșit, de asemenea, în evidență. Utilizatorii trebuie să cartografieze cu atenție câmpurile care sunt completate sau transmise pentru ca automatizarea să funcționeze cu acuratețe, făcând-o mai practică decât unele platforme bazate pe AI. Deși această abordare asigură precizie, ea întărește dependența de expertiza puternică Salesforce și de infrastructura existentă.

În timp ce AgentForce se limitează la ecosistemul Salesforce, acest lucru are atât avantaje, cât și dezavantaje. Pe de o parte, este o soluție pachet care unifică autentificarea, permisiunile utilizatorului, definițiile instrumentelor și logica de orchestrare într-o singură platformă. Pe de altă parte, multe fluxuri de lucru ale întreprinderii se întind pe mai multe sisteme, iar natura izolate a AgentForce limitează aplicabilitatea acestuia pentru nevoi mai largi de automatizare. Marc Benioff a declarat că sute de clienți au semnat deja oferte pentru a utiliza AgentForce, așa că evoluția sa va merita monitorizată.

Deci... Suntem încă acolo?

Din aceste experimente, este clar că soluțiile actuale de agenți AI pot face o treabă decentă de a raționa sarcinile în mai mulți pași și de a crea un plan. Adevărata provocare este execuția într-un mediu dezordonat, din lumea reală, cu cunoștințe tribale despre modul în care aceste sisteme se comportă cu adevărat. Interfețele grafice au fost create pentru interacțiunea umană, iar logica personalizată a fiecărei întreprinderi este ca o mini gaură neagră de complexitate. Chiar dacă omiteți interfața grafică pentru o abordare fără cap sau faceți ingineria inversă a API-urilor backend, vă confruntați în continuare cu cazuri de margine, obstacole de autentificare, limite de rate sau fluxuri de lucru dinamice care aruncă în evidență cele mai bune LLM-uri.

Provocările rămase sunt în principal probleme de inginerie: construirea de instrumente robuste, integrarea profundă cu sistemele întreprinderii, stabilirea balustradelor și crearea cadrelor de monitorizare și orchestrare fiabile. Acestea sunt rezolvabile cu efort dedicat și specializare. LLM-urile de astăzi demonstrează deja capacități de raționament mult peste cele disponibile chiar și acum un an, iar costul lor scade rapid. Accentul trebuie să se îndrepte acum către construirea infrastructurii și proceselor necesare pentru implementarea eficientă a acestor capabilități.

Cu toate acestea, aceste dificultăți nu ar trebui să umbrească progresul constant care se întâmplă. Observăm deja automatizări AI specializate, focalizate pe verticală (de exemplu, SDR sau agenți de asistență pentru clienți) care pot oferi o precizie ridicată într-un domeniu controlat. Pe măsură ce fiecare dintre aceste automatizări de unică folosință se maturizează, le putem vedea înlănțuite în fluxuri de lucru mai largi. Acesta ar putea fi în cele din urmă modul în care spargem automatizarea end-to-end în întreprinderile mari: prin combinarea mai multor agenți specializați, în loc să ne așteptăm ca un singur agent cu scop general să facă totul. Deocamdată, rentabilitatea investiției pentru construirea unui agent de la zero s-ar putea să nu fie stabilită pentru toate sarcinile, cu excepția celor de cel mai mare volum.

Specializarea și drumul de urmat

O lecție din aceste teste este importanța specializării. Obținerea unei fiabilități aproape perfecte într-un singur domeniu (de exemplu, crearea de facturi în NetSuite) necesită o reglare fină semnificativă. Startup-urile sau echipele interne care se concentrează pe un singur flux de lucru specializat pot oferi o experiență mai bună decât o soluție largă, generică. Asistăm deja la un val de „agenți verticali” care abordează sarcini specifice în finanțe, logistică, resurse umane sau lanțul de aprovizionare. Fiecare agent s-ar integra profund, poate combinând automatizarea interfeței de utilizare, acolo unde este necesar, cu apeluri directe API atunci când este posibil, plus logica de rezervă și balustradele specifice domeniului.

Marea întrebare rămâne: va fi 2025 cu adevărat anul în care acești agenți vor intra în masă sau ne uităm la o pistă mai lungă? Tehnologia se mișcă rapid, iar optimismul abundă. Dar, așa cum inginerii de software nu au dispărut când generarea codului s-a îmbunătățit, probabil că nu vom vedea automatizarea întreprinderii „mâini libere” pentru toate procesele. În schimb, vom vedea îmbunătățiri iterative în buzunarele specializate, în cele din urmă îmbinându-le împreună ca un mozaic de automatizări parțiale.

Concluzie

Conceptul de agenți AI autonomi este incontestabil convingător, mai ales în mediile de întreprindere unde abundă sarcinile repetitive. Beneficiile potențiale - economisirea timpului, reducerea erorilor și permiterea angajaților să se concentreze pe o muncă mai creativă și strategică - sunt enorme. Cu toate acestea, în timp ce capacitățile de bază ale agenților AI sunt puternice, calea către adoptarea pe scară largă depinde de depășirea provocărilor de inginerie, pe lângă avansarea cercetării subiacente.

Construirea infrastructurii potrivite este esențială: instrumente robuste, integrări fiabile și soluții specifice domeniului, cu balustrade și straturi de orchestrare bine definite. Complexitatea sistemelor de întreprindere din lumea reală necesită soluții specializate, iar aici agenții verticali pot excela. Concentrarea pe fluxuri de lucru înguste și bine definite permite echipelor să-și perfecționeze soluțiile la un grad ridicat de acuratețe și fiabilitate, abordând provocările unice ale fiecărui domeniu. În timp, acești agenți specializați s-ar putea interconecta, creând o rețea mai largă de automatizări.

2025 poate aduce progrese impresionante și un număr tot mai mare de programe pilot. Mai degrabă decât o lume care rulează pe pilot automat, este mai probabil să vedem automatizări țintite, extrem de eficiente, care abordează probleme specifice. Călătoria către automatizarea completă a întreprinderii va fi iterativă, condusă de specializare și colaborare. Elanul se construiește, iar rezolvarea acestor provocări de inginerie va deschide calea pentru următorul val de inovație în întreprinderi.

(Prezentare imagine pentru DALL-E)