2025 год можа стаць годам агентаў штучнага інтэлекту, калі яны змогуць перажыць карпаратыўнае пекла

На працягу дзесяцігоддзяў кампаніі імкнуліся аўтаматызаваць бэк-офісныя задачы, увод даных, працэсы выстаўлення рахункаў і іншыя паўтаральныя працоўныя працэсы. Але нават па меры развіцця праграмнага забеспячэння сапраўдная скразная аўтаматызацыя застаецца няўлоўнай для большасці прадпрыемстваў. Зараз, з хуткім ростам вялікіх моўных мадэляў (LLM) і з'яўленнем «агентаў штучнага інтэлекту», здольных разважаць і дзейнічаць аўтаномна, расце вера ў тое, што 2025 год можа стаць годам, калі мы нарэшце ўбачым значны скачок наперад у сферы аўтаматызацыі прадпрыемстваў.

Сэм Альтман публічна заявіў , што «ў 2025 годзе мы можам убачыць, што першыя агенты штучнага інтэлекту далучацца да працоўнай сілы і істотна зменяць прадукцыйнасць кампаній», у той час як Марк Беніёф паварочвае Salesforce да «AgentForce» у чаканні будучыні, дзе многія арганізацыйныя працэсы будуць дэлегаваны. спецыялізаваным агентам. Гэтыя прагнозы выклікаюць цэнтральнае пытанне: ці могуць агенты штучнага інтэлекту пераадолець складаныя перашкоды рэальных карпаратыўных сістэм? У гэтым артыкуле мы разгледзім унікальныя цяжкасці аўтаматызацыі прадпрыемстваў і даследуем некаторыя перспектыўныя на сённяшні дзень (але ўсё яшчэ наспелыя) рашэнні. Мы таксама падзелімся практычнымі тэстамі з, здавалася б, простым працоўным працэсам у Salesforce (SFDC) — стварэннем замовы ў рэсэлераў для новага ўліковага запісу — якія раскрываюць складанасць, якая хаваецца за кадрам.

Чаму аўтаматызацыя прадпрыемства такая складаная?

На паперы аўтаматызацыя карпаратыўных задач гучыць проста: запусціце скрыпт для ўваходу ў сістэму, запоўніце формы і націсніце «Адправіць». На практыцы складанасць ашаламляе. Прадпрыемствы абапіраюцца на мноства сістэм запісу, такіх як Salesforce, SAP, Oracle, і мноства ўласных рашэнняў. Кожная сістэма мае сваю ўласную сетку дазволаў, патокі аўтэнтыфікацыі і карыстальніцкую бізнес-логіку. Больш за тое, гэтыя сістэмы часта моцна настроены. Звычайна можна ўбачыць спецыялізаваныя карыстальніцкія інтэрфейсы, дадатковыя палі даных і індывідуальныя працоўныя працэсы, якія адрозніваюцца ад бізнесу да бізнесу.

Паводле сумеснага апытання MuleSoft і Deloitte, буйныя прадпрыемствы могуць выкарыстоўваць у сярэднім 976 розных сістэм для падтрымкі штодзённых аперацый ( крыніца ). Гэтая фрагментацыя азначае, што інструмент аўтаматызацыі павінен размаўляць з некалькімі сістэмамі, кожная са сваімі нюансамі; некаторыя з надзейнымі API, іншыя наогул без іх. Часта самыя простыя задачы ўключаюць у сябе пераадоленне даных паміж старымі праграмамі і новымі хмарнымі сэрвісамі. Нават стандартныя платформы, такія як Salesforce, могуць стаць лабірынтамі, калі будуць створаны карыстальніцкія працоўныя працэсы і інтэграцыі іншых вытворцаў.

На гэтым фоне агенты на базе LLM абяцаюць больш гнуткі падыход: яны могуць аналізаваць даныя, разважаць аб наступных кроках і нават арыентавацца ў складаных графічных інтэрфейсах — прынамсі, тэарэтычна. Але, як вы ўбачыце ў наступным прыкладзе, прымусіць агента штучнага інтэлекту выканаць нават асноўны працоўны працэс Salesforce без дапамогі чалавека больш складана, чым многія разумеюць.

Практычны прыклад: стварэнне індывідуальнага заказу рэсэлера ў Salesforce

Задача

Уявіце, што вы гандлёвы супрацоўнік у кампаніі па вытворчасці ровараў, якая выкарыстоўвае Salesforce. Вы толькі што прадалі 1 вялікі ровар Dynamo X1 за 5000 долараў новаму прадаўцу пад назвай "Northern Trail Cycling". Ваша задача:

1 - Прайдзіце аўтэнтыфікацыю ў Salesforce (з прадастаўленымі ўліковымі дадзенымі).

2 - Стварыце новы ўліковы запіс для рэсэлера.

3 - Стварыце заказ рэсэлера і дадайце пазыцыю (ровар).

4 - Адпраўце гэты заказ на зацвярджэнне вытворчасці.

Для паспяховага выканання мы чакаем, што канчатковы вынік будзе выглядаць наступным чынам:

Здаецца, гэта досыць проста, але д'ябал хаваецца ў дэталях. Асобнік кампаніі Salesforce настроены: ён выкарыстоўвае карыстальніцкі аб'ект і паток «заказ рэсэлера», спецыяльную функцыю перацягвання для дадання прадуктаў і схаваны этап «перадаць на вытворчасць» без выразнай маркіроўкі. Я пратэставаў гэты сцэнар, выкарыстоўваючы некалькі новых падыходаў да аўтаматызацыі, якія кіруюцца штучным інтэлектам, каб убачыць, наколькі яны падыходзяць.

Claude Карыстанне кампутарам

Што гэта?

Claude Computer Use - гэта новая функцыя ад Anthropic, уведзеная ў Claude 3.5 Sonnet v2 . Стандартная парадыгма выкліку функцый LLM ідзе на крок наперад, даючы Клоду ўсё кантэйнернае асяроддзе працоўнага стала для «бачання» і «кантролю». Ён можа рабіць здымкі экрана, інтэрпрэтаваць іх з дапамогай візуальнага/прасторавага разумення і выконваць дзеянні на ўзроўні АС, такія як пстрычкі мышы, пракруткі і націсканні клавіш.

З пункту гледжання карыстальніка, вы даяце Клоду задачу высокага ўзроўню («Увайсці ў Salesforce і стварыць гэты заказ рэсэлеру»), і Клод спрабуе зрабіць менавіта гэта. Ён праходзіць праз паслядоўнасць:

1. Стварэнне скрыншота і яго інтэрпрэтацыя.
2. Выдача дзеянняў карыстацкага інтэрфейсу (пстрычкі мышы, націсканне клавіш, каманды bash).
3. Паўтарэнне да таго часу, пакуль заданне не будзе выканана (або яно не адмовіцца).

Выпрабаванне

Давайце пачнем з самага простага падыходу да запуску эталоннай рэалізацыі Anthropic без якіх-небудзь змяненняў у сістэмным падказцы . Вось пачатак узаемадзеяння, які паказвае пачатковую падказку, план, прапанаваны Клодам, і працоўны стол, з якога пачынаецца ўзаемадзеянне.

Назіранне за кантэйнерным працоўным сталом Клода спачатку ўражвала. Ён адкрыў браўзер, наведаў URL-адрас Salesforce, увайшоў у сістэму з прадастаўленымі ўліковымі дадзенымі і перайшоў у раздзел «Уліковыя запісы». Ён бездакорна стварыў новы ўліковы запіс для Bike Production Company , увёўшы правільныя дадзеныя ў форму, а затым паспрабаваў стварыць новы заказ для рэсэлераў. Усё ішло гладка, пакуль не з'явіўся карыстальніцкі інтэрфейс перацягвання для дадання матацыкла. Сістэма затрымалася, спрабуючы выканаць перацягванне на аснове пікселяў.

Пасля некалькіх няўдач ён паспрабаваў знайсці альтэрнатыўны метад (напрыклад, схаваную кнопку «Дадаць элемент»). Першая спроба з кнопкай «рэдагаваць» не ўдалася.

«Я заўважыў, што ў дыялогавым акне рэдагавання няма дакладнага спосабу дадання прадуктаў. Дазвольце мне паспрабаваць іншы падыход, націснуўшы на выпадальнае меню "Заказы рэсэлераў", каб убачыць, ці ёсць іншыя варыянты ".

У рэшце рэшт ён знайшоў свой шлях, знайшоўшы спосаб дадаваць новыя элементы праз укладку «Звязаныя» — толькі да няўдачы, калі дынамічныя трыгеры праграмы не абнаўлялі агульную суму заказу аўтаматычна. Распрацоўшчыкі прыкладання SFDC не скончылі распрацоўку гэтага шляху кода, чакаючы, што чалавек-карыстальнік будзе проста прытрымлівацца метаду перацягвання. Карацей кажучы, паток быў распрацаваны для людзей, а не для агента штучнага інтэлекту.

Затым Клод паспрабаваў знайсці кнопку «Адправіць у вытворчасць», якая была схавана пад карыстальніцкай укладкай. З-за недахопу папярэдняга веды аб гэтым кроку, ён вагаўся яшчэ некалькі хвілін. У рэшце рэшт мне прыйшлося ўмяшацца, уручную дадаць ровар у заказ і накіраваць Клоду на адпаведную кнопку. Пасля прыблізна 10 хвілін і выдаткаў на выкарыстанне каля 0,80 долараў працэс усё яшчэ не быў цалкам аўтаматызаваны. Было лёгка зразумець, чаму Anthropic называе гэтую функцыю эксперыментальнай: неабходна шмат рэальных агароджаў і паляпшэнняў, перш чым Computer Use можа быць сапраўды гатовым да вытворчасці.

Ці можа гэта стаць лепш?

Нягледзячы на шурпатасці, канцэпцыя захапляльная. Візуальны штучны інтэлект для ўзаемадзеяння з графічным інтэрфейсам імкліва паляпшаецца, і крывая выдаткаў на вывад хутка падае. Нядаўняе даследаванне a16z паказвае, што пры аднолькавай прадукцыйнасці выдаткі на LLM змяншаюцца прыкладна ў 10 разоў у год. У прынцыпе, будучыя версіі Claude могуць стаць больш хуткімі, таннымі і больш дакладнымі ў візуальных/прасторавых задачах, такіх як перацягванне.

Аднак фундаментальнай праблемай застаецца тое, што карпаратыўныя карыстальніцкія інтэрфейсы, асабліва старыя або моцна наладжаныя, рэдка ствараюцца з улікам аўтаматызацыі. Узаемадзеянне на ўзроўні пікселяў нетрывалае. Нязначныя змены ў макеце або дынамічныя ўсплывальныя вокны могуць парушыць увесь паток. Таксама растуць даследаванні вакол візуальна абгрунтаваных фрэймворкаў графічнага інтэрфейсу, але зрабіць іх вытворчага класа для сотняў розных працоўных працэсаў - сур'ёзная задача.

Аглядальнікі без галавы: поўнасцю прапускаем графічны інтэрфейс

Адзін з альтэрнатыўных падыходаў - цалкам ігнараваць "візуальныя абмежавальныя рамкі". Калі ваша мэтавае прыкладанне працуе ў вэб-браўзеры, вы можаце аўтаматызаваць на ўзроўні DOM, прапускаючы скрыншоты і ўзаемадзеянне на аснове пікселяў. У той час як традыцыйныя браўзеры без галавы, такія як Playwright і Selenium, часта асацыююцца з фрэймворкамі тэсціравання, з'яўляецца новае пакаленне браўзераў без галавы, арыентаваных на варыянты выкарыстання штучнага інтэлекту. Гэтыя новыя платформы створаны на аснове Playwright і Selenium, каб забяспечыць больш дынамічнае ўзаемадзеянне на аснове LLM.

BrowserBase

BrowserBase - адзін з такіх прыкладаў. Ён функцыянуе як інфраструктурная платформа, якая размяшчае і маштабуе сеансы браўзера, не патрабуючы ад распрацоўшчыкаў кіравання кантэйнерамі. Шаблон узаемадзеяння круціцца вакол разбору змесціва HTML старонкі на кампаненты (напрыклад, формы, кнопкі), адлюстраваныя ў іх xPaths, і перадачы гэтай структуры LLM па вашаму выбару. Затым LLM стварае наступны набор кода Playwright для выканання, дазваляючы ўзаемадзейнічаць з DOM з дапамогай кода, а не праз традыцыйныя клікі графічнага інтэрфейсу. Паколькі ён цалкам без галавы, ён выкарыстоўвае менш скрыншотаў або зусім не выкарыстоўвае яго, захоўваючы даўжыню кантэксту кароткую і затрымку меншую, чым падыход з поўным «асяроддзем працоўнага стала».

Зусім нядаўна BrowserBase выпусціў сваю бібліятэку з адкрытым зыходным кодам StageHand , каб палегчыць задачу распрацоўшчыкам. У арыгінальнай мадэлі ўзаемадзеянне па-ранейшаму было вельмі ручным, што патрабавала ад распрацоўшчыкаў працы з нізкаўзроўневымі дэталямі абезгалоўленага браўзера, у тым ліку непасрэднага напісання кода Playwright і ручнога аналізу HTML. З дапамогай StageHand BrowserBase забяспечвае больш высокі ўзровень абстракцыі, дазваляючы распрацоўшчыкам выкарыстоўваць заснаваныя на намерах каманды натуральнай мовы, такія як «навігацыя» або «выманне». Гэты падыход таксама ўключае некаторую апрацоўку для пераўтварэння неапрацаванага HTML у кампаненты, што палягчае LLM апрацоўку задач. Тым не менш, карыстальнікам усё яшчэ трэба ствараць уласныя ўзроўні аркестроўкі для падлучэння працоўных працэсаў і кіравання імі, паколькі сам StageHand не прапануе ўбудаваную аркестроўку.

Каб праверыць BrowserBase, я выкарыстаў іх пляцоўку для распрацоўшчыкаў, якая забяспечвае кансоль для напісання кода Playwright і запіс падказкі LLM для аўтаматычнага стварэння гэтых сцэнарыяў. Ідэя складаецца ў тым, каб зрабіць шматэтапную навігацыю — увайсці, стварыць уліковы запіс, стварыць заказ рэсэлеру. Але платформа чакае, што вы самі арганізуеце крокі. Пачынаючы з той жа падказкі, дадзенай Клоду, BrowserBase спатыкнуўся, бо не мог разважаць шматэтапным спосабам. Таму я перайшоў да прадастаўлення падказкі на натуральнай мове для кожнага кроку і назірання, ці выконвае згенераваны код Playwright тое, што было задумана. На скрыншоце ніжэй вы бачыце шэраг падказак і згенераваны код Playwright.

На практыцы я часам сутыкаўся з неадпаведнасцю паміж асяроддзем браўзера Playground і формамі HTML, якія трэба было запоўніць. Кнопкі адлюстроўваліся дзіўна, час чакання павялічыўся, а палі формы загружаліся не так, як чакалася. Нягледзячы на гэтыя збоі, згенераваны LLM код Playwright здолеў увайсці, стварыць уліковы запіс і часткова запоўніць форму замовы рэсэлера. Аднак перацягванне для дадання элемента зноў стала каменем перапоны. Я патраціў каля сямі хвілін на тое, каб павазіцца з ім, перш чым адмовіцца. Было відавочна, што платформа пакуль не прыстасаваная для такога тыпу аўтаматызацыі. Верагодна, гэта лепш за ўсё працуе для выпадкаў выкарыстання вэб-скрабання.

Скайверн

Skyvern - гэта больш комплексны безгаловы падыход, які па змаўчанні дадае аркестроўку. У адрозненне ад BrowserBase, які патрабуе ад карыстальнікаў вызначаць крокі і кіраваць імі ўручную, Skyvern спрабуе апрацоўваць аркестроўку адразу. Пад капотам ён працуе аналагічна BrowserBase - як відаць з іх адкрытага зыходнага кода - але таксама дадае вэб-агента, які можа арганізоўваць і разважаць аб кроках. Гэта ўключае ў сябе дадатковы рэжым бачання, які адпраўляе скрыншоты ў LLM разам з вынятымі кампанентамі і іх xPath, каб дапамагчы ў прыняцці рашэнняў.

Каб ліквідаваць абмежаванні ручнога стварэння крокаў у BrowserBase, я вырашыў праверыць Skyvern з выкарыстаннем яго кіраванага сэрвісу, засяродзіўшы ўвагу менавіта на рэжыме Workflow. Гэты рэжым прызначаны для шматэтапных працэсаў, і я хацеў ацаніць, наколькі добра ён працуе з нашым працоўным працэсам Salesforce. На жаль, у працэсе двухфактарнай аўтэнтыфікацыі (2FA) на сеанс затрачана больш за 15 этапаў развагі і 1 долар крэдытаў. Размешчаны IP-адрас Skyvern быў пазначаны, што выклікала 2FA, і не было магчымасці ўручную ўвесці код або абагуліць файл cookie, каб абыйсці сітуацыю. Гэта падкрэслівае пастаянную праблему аўтэнтыфікацыі ў карпаратыўных наладах і падкрэслівае, чаму такія стартапы, як Anon, засяроджваюцца выключна на рашэннях аўтэнтыфікацыі для агентаў штучнага інтэлекту.

Каманда Skyvern пазіцыянуе платформу як прыдатную для больш простых дробных задач, прычым аўтаматызацыя кантактнай формы з'яўляецца асноўным варыянтам выкарыстання. Іншыя патэнцыйныя варыянты выкарыстання (напрыклад, вакансіі, рахункі-фактуры) па-ранейшаму пазначаны як "у стадыі навучання", што сведчыць аб тым, што платформа пачынае з аўтаматызацыі, арыентаванай на простае выкарыстанне, а не на больш складаныя патрэбы працоўных працэсаў прадпрыемства. Нягледзячы на тое, што Skyvern абяцае, відавочна, што на гэтай стадыі свайго развіцця Skyvern лепш падыходзіць для менш складаных сцэнарыяў.

Кампрамісы

Аглядальнікі без галавы прапускаюць здагадкі на ўзроўні пікселяў, што часта прыводзіць да меншай колькасці памылак і больш хуткага выканання. Але як толькі вы націснеце пашыраныя функцыі, такія як перацягванне або складаныя аднастаронкавыя прыкладанні, вам можа спатрэбіцца вярнуцца да частковага аналізу скрыншотаў або спецыяльнага кода. Браўзеры таксама могуць трапляць у чорны спіс 2FA і IP. Для карпаратыўных прыкладанняў з некалькімі арэндамі адна толькі аўтэнтыфікацыя можа быць складанай, і вам усё роўна могуць спатрэбіцца ўласныя ўзроўні аркестроўкі.

Іншым абмежаваннем з'яўляецца тое, што гэтыя платформы абапіраюцца на дынамічную генерацыю кода праз LLM кожны раз, калі выконваецца працоўны працэс. Паколькі LLM па сваёй сутнасці недэтэрмінаваныя, выведзены код можа адрознівацца ў розных серыях, што ўскладняе аўдыт або праверку ўзгодненасці. Гэтая непрадказальнасць можа прывесці да праблем, асабліва ў адчувальных працоўных працэсах. Нягледзячы на тое, што кэшаванне згенераванага кода, здаецца, уключана ў дарожную карту для некаторых платформаў, гэта стварае значныя праблемы для LLM. Нават нязначныя змены ў падказцы або пакетнай апрацоўцы падчас вываду могуць даць зусім іншыя вынікі, ускладняючы працэс кэшавання.

У цэлым прагляд без галавы можа быць таннейшым і больш стабільным, чым поўнае маніпуляванне графічным інтэрфейсам, але гэта далёка не магічнае рашэнне. Многія рашэнні, такія як BrowserBase і Skyvern, сканцэнтраваны на больш вузкіх выпадках выкарыстання (напрыклад, формы, выманне даных), а не з'яўляюцца «адзінай платформай для аўтаматызацыі ўсяго».

Унутраныя API зваротнага праектавання

Трэці падыход заключаецца ў тым, каб цалкам абыйсці вэб-старонку, перахопліваючы сеткавыя выклікі, якія адбываюцца, калі вы націскаеце. Калі вы можаце захапіць запыты, якія адпраўляе ваш браўзер, вы можаце аднавіць гэтыя выклікі ў кодзе. У прынцыпе, гэта дазваляе пазбегнуць бязладных крокаў, заснаваных на карыстальніцкім інтэрфейсе, і гарантуе, што вы выкарыстоўваеце тую ж бэкэнд-логіку, якую выкарыстоўвае ваша прыкладанне. Гэтая тэндэнцыя не зусім новая, бо API зваротнага праектавання існуюць ужо даўно. Тым не менш, новае дапаўненне ўключае ў сябе агента штучнага інтэлекту для разважанняў аб сеткавых запытах, што робіць працэс больш разумным і адаптыўным.

Некалькі месяцаў таму прадукт пад назвай Integuru быў запушчаны на Hackernews і прыцягнуў увагу сваім падыходам з адкрытым зыходным кодам і новай метадалогіяй. Заінтрыгаваны яго патэнцыялам, я вырашыў праверыць яго, прыцягнуты цікавым падыходам, заснаваным на графах, і інтэграцыяй агентаў штучнага інтэлекту для разважанняў аб сеткавых запытах. Абяцанне рэзка скараціць час і кошт аўтаматызацыі зрабіла гэта пераканаўчым варыянтам для вывучэння.

Рэпазітар Integuru адносна новы, але абяцае. Па сутнасці, ён запісвае ўвесь сеткавы трафік і файлы cookie ў Chromium падчас выканання задання. Затым ён стварае графічнае прадстаўленне запытаў, адлюстроўваючы, якія старонкі выклікаюць якія канчатковыя кропкі. Выкарыстоўваючы гэты графік, ён выконвае абход, перадаючы яго ў LLM для генерацыі кода для кожнага вузла, які прайгравае адны і тыя ж запыты, уводзячы вашыя дынамічныя параметры (напрыклад, «Кампанія па вытворчасці ровараў») па меры неабходнасці і аб'ядноўваючы іх на аснове залежнасцей. Тэарэтычна такі падыход можа значна ўпарадкаваць працэс аўтаматызацыі.

На практыцы, аднак, гэта не спрацавала добра для нашага выпадку выкарыстання, у асноўным з-за абмежаванняў кантэкстнага акна. Паток мог быць занадта доўгім, каб LLM мог эфектыўна справіцца з ім. Нават спробы перапыніць працэс, убудаваўшы кукі для ўваходу напрамую і запусціўшы з галоўнай старонкі, не ўвянчаліся поспехам. Хаця я падазраю, што мой нізкаўзроўневы ключ OpenAI API спрыяў гэтым праблемам, відавочна, што Integuru ўсё яшчэ толькі ў пачатку свайго існавання. Патэнцыял ёсць, але прадукт патрабуе далейшай дапрацоўкі. Яго дэманстрацыі (напрыклад, спампоўка падатковых дакументаў з Robinhood) лепш за ўсё працавалі на сучасных вэб-платформах з больш простымі патокамі. Salesforce з яго складаным інтэрфейсам і лабірынтнымі карыстальніцкімі аб'ектамі ўводзіў памылкі.

Тым не менш, гэты метад яшчэ не з'яўляецца універсальным рашэннем. Патрэба ў запісе ўсіх крокаў абмяжоўвае яго гнуткасць, і ён схіляецца да больш статычнага падыходу генерацыі кода для пэўных патокаў загадзя, што нагадвае заснаваныя на правілах інструменты RPA, папулярныя дзесяць гадоў таму. Гэта падкрэслівае фундаментальнае абмежаванне: у той час як даданне AI аргументацыі да сеткавых запытаў з'яўляецца захапляльным і можа адкрыць дзверы для інтэграцыі з сістэмамі, якія не маюць API, гэта ўсё ж лепш падыходзіць для больш кантраляваных або паўтаральных задач, а не дынамічных, разнастайных працоўных працэсаў у карпаратыўныя асяроддзя.

AgentForce: уласнае рашэнне Salesforce

Ніякая размова пра аўтаматызацыю ў Salesforce на аснове штучнага інтэлекту не будзе поўнай без згадвання AgentForce , вялікай стаўкі Марка Беніёфа на стварэнне «агентаў» у экасістэме Salesforce. У адрозненне ад іншых пратэставаных намі вышэй рашэнняў, арыентаваных на распрацоўшчыкаў і накіраваных на аўтаматызацыю працоўных працэсаў у розных сістэмах, AgentForce пазіцыянуецца як убудаванае рашэнне з нізкім кодам спецыяльна для Salesforce. Ён аб'ядноўвае мноства кампанентаў і сканцэнтраваны на ўсім патоку ўнутры платформы Salesforce.

Ідэя складаецца ў тым, каб стварыць агентаў, якія цалкам знаходзяцца ў Salesforce і абапіраюцца на вашы налады. Карыстальнікі вызначаюць агульнае апісанне агента, прызначаюць тэмы і звязаныя з імі дзеянні, якія з'яўляюцца загадзя створанымі патокамі, вызначанымі альбо ў кодзе, альбо праз карыстацкі інтэрфейс Salesforce. Затым наладжваюцца дазволы, ролі карыстальнікаў і інструкцыі, якія дазваляюць агенту працаваць. Гэтая канцэпцыя тэарэтычна дазваляе прадпрыемствам выкарыстоўваць існуючыя дадзеныя і працоўныя працэсы Salesforce для аўтаматызацыі без шырокага кадавання.

Я хацеў праверыць AgentForce непасрэдна на нашым прыкладзе замовы ў рэсэлераў eBikes. На жаль, патрабуецца доступ да Einstein (функцыі AI), які недаступны ў бясплатным уліковым запісе распрацоўшчыка. Замест гэтага я вывучыў іх 30-хвілінную гульнявую пляцоўку з выдуманым дадаткам «Coral Beach Resort». Тэставая задача складалася ў тым, каб наладзіць агента для аўтаматызацыі стварэння браніравання, працэсу, у нечым падобнага на заказ рэсэлера ў нашым сцэнары eBikes.

Наладжванне было даволі складаным, патрабуючы некалькіх крокаў: вызначэнне дазволаў, уключэнне тэм, падключэнне да загадзя створаных дзеянняў, адлюстраванне палёў даных і ўдакладненне інструкцый. Нягледзячы на тое, што прадавалася як рашэнне з нізкім кодам, стала ясна, што неабходныя значныя веды пра тонкасці Salesforce. Калі асобніку Salesforce кампаніі не хапае добра задакументаваных наладжвальных палёў і папярэдне настроеных патокаў дзеянняў, першапачатковы рост можа быць значным. Рэальна, большасці прадпрыемстваў, хутчэй за ўсё, спатрэбіцца прыцягнуць сістэмных інтэгратараў або кансультантаў для поўнага ўкаранення і аптымізацыі гэтых агентаў.

Прырода AgentForce, заснаваная на правілах, таксама вылучалася. Карыстальнікі павінны ўважліва вызначыць, якія палі запаўняюцца і праходзяць, каб аўтаматызацыя працавала дакладна, што робіць яе больш практычнай, чым некаторыя платформы, якія кіруюцца штучным інтэлектам. Хоць такі падыход забяспечвае дакладнасць, ён узмацняе залежнасць ад моцнага вопыту Salesforce і існуючай інфраструктуры.

Хоць AgentForce абмяжоўваецца экасістэмай Salesforce, гэта мае як перавагі, так і недахопы. З аднаго боку, гэта ўпакаванае рашэнне, якое аб'ядноўвае аўтэнтыфікацыю, правы карыстальніка, азначэнні інструментаў і логіку аркестроўкі ў рамках адной платформы. З іншага боку, многія карпаратыўныя працоўныя працэсы ахопліваюць некалькі сістэм, і ізаляваны характар AgentForce абмяжоўвае яго прымяненне для больш шырокіх патрэб аўтаматызацыі. Марк Беніёф заявіў, што сотні кліентаў ужо падпісалі здзелкі на выкарыстанне AgentForce, таму варта сачыць за яго развіццём.

Такім чынам... Мы ўжо там?

З гэтых эксперыментаў стала ясна, што сучасныя рашэнні для агентаў штучнага інтэлекту могуць годна разважаць пра шматэтапныя задачы і складаць план. Сапраўднай праблемай з'яўляецца выкананне ў бязладным рэальным асяроддзі з племяннымі ведамі аб тым, як на самой справе паводзяць сябе гэтыя сістэмы. Графічны інтэрфейс быў створаны для ўзаемадзеяння з людзьмі, і індывідуальная логіка кожнага прадпрыемства падобная да маленькай чорнай дзіркі складанасці. Нават калі вы прапусціце графічны інтэрфейс для беспамылковага падыходу або сканструюеце API бэкэнда, вы ўсё роўна сутыкнецеся з гранічнымі выпадкамі, перашкодамі аўтэнтыфікацыі, абмежаваннямі хуткасці або дынамічнымі працоўнымі працэсамі, якія выкідваюць лепшае з LLM.

Астатнія праблемы - гэта пераважна інжынерныя праблемы: стварэнне надзейных інструментаў, глыбокая інтэграцыя з карпаратыўнымі сістэмамі, усталяванне агародж і стварэнне надзейных структур маніторынгу і аркестроўкі. Яны вырашаюцца пры дапамозе адданых намаганняў і спецыялізацыі. Сённяшнія LLM ужо дэманструюць магчымасці развагі, якія значна перавышаюць тыя, што былі даступныя нават год таму, і іх кошт імкліва падае. Цяпер акцэнт павінен быць перанесены на стварэнне інфраструктуры і працэсаў, неабходных для эфектыўнага разгортвання гэтых магчымасцей.

Аднак гэтыя цяжкасці не павінны азмрочваць стабільны прагрэс, які адбываецца. Мы ўжо бачым спецыялізаваную вертыкальна арыентаваную аўтаматызацыю штучнага інтэлекту (напрыклад, SDR або агентаў падтрымкі кліентаў), якая можа забяспечваць высокую дакладнасць у кантраляванай вобласці. Па меры сталення кожнай з гэтых аднаразовых аўтаматызацый мы можам убачыць іх аб'яднанымі ў больш шырокія працоўныя працэсы. У канчатковым рахунку гэта можа быць тое, як мы ўзломваем скразную аўтаматызацыю на буйных прадпрыемствах: аб'ядноўваючы некалькі спецыялізаваных агентаў, а не чакаючы, што адзіны агент агульнага прызначэння будзе рабіць усё. На дадзены момант рэнтабельнасць інвестыцый пры стварэнні агента з нуля можа быць вызначана не для ўсіх задач, акрамя самых вялікіх аб'ёмаў.

Спецыялізацыя і дарога наперад

Адзін урок з гэтых тэстаў - важнасць спецыялізацыі. Дасягненне амаль ідэальнай надзейнасці ў адным дамене (напрыклад, стварэнне рахункаў-фактур у NetSuite) патрабуе значнай тонкай налады. Стартапы або ўнутраныя каманды, якія сканцэнтраваны на адным спецыялізаваным працоўным працэсе, могуць забяспечыць лепшы вопыт, чым шырокае агульнае рашэнне. Мы ўжо бачым хвалю «вертыкальных агентаў», якія вырашаюць мэтавыя задачы ў галіне фінансаў, лагістыкі, кадраў або ланцужкоў паставак. Кожны агент будзе глыбока інтэгравацца, магчыма, спалучаючы аўтаматызацыю карыстальніцкага інтэрфейсу, калі гэта неабходна, з прамымі выклікамі API, калі гэта магчыма, плюс даменна-спецыфічную рэзервовую логіку і агароджы.

Застаецца вялікае пытанне: ці сапраўды 2025 год стане годам, калі гэтыя агенты стануць мэйнстрымам, ці мы чакаем даўжэйшай узлётна-пасадачнай паласы? Тэхналогія хутка развіваецца, і аптымізму шмат. Але гэтак жа, як інжынеры-праграмісты не зніклі, калі генерацыя кода палепшылася, мы, верагодна, не ўбачым "свабодных рук" аўтаматызацыі прадпрыемства для ўсіх працэсаў. Замест гэтага мы ўбачым ітэрацыйныя паляпшэнні ў спецыялізаваных кішэнях, якія ў канчатковым выніку злучаюць іх у мазаіку частковай аўтаматызацыі.

Заключэнне

Канцэпцыя аўтаномных агентаў штучнага інтэлекту бясспрэчна пераканаўчая, асабліва ў карпаратыўных умовах, дзе шмат паўтаральных задач. Патэнцыйныя перавагі — эканомія часу, скарачэнне памылак і магчымасць супрацоўнікам засяродзіцца на больш творчай і стратэгічнай працы — велізарныя. Аднак, нягледзячы на тое, што асноўныя магчымасці агентаў штучнага інтэлекту моцныя, шлях да шырокага прыняцця залежыць ад пераадолення інжынерных праблем у дадатак да прасоўвання асноўных даследаванняў.

Ключавым з'яўляецца стварэнне патрэбнай інфраструктуры: надзейныя інструменты, надзейныя інтэграцыі і даменна-спецыфічныя рашэнні з дакладна вызначанымі агароджамі і ўзроўнямі аркестроўкі. Складанасць рэальных карпаратыўных сістэм патрабуе спецыяльных рашэнняў, і менавіта ў гэтым вертыкальныя агенты могуць пераўзысці. Канцэнтрацыя на вузкіх, выразна акрэсленых працоўных працэсах дазваляе камандам удасканальваць свае рашэнні з высокай ступенню дакладнасці і надзейнасці, вырашаючы унікальныя праблемы кожнай вобласці. З часам гэтыя спецыялізаваныя агенты змаглі злучыцца, стварыўшы больш шырокую сетку аўтаматызацыі.

2025 год цалкам можа прынесці ўражлівы прагрэс і рост колькасці пілотных праграм. Замест таго, каб свет працаваў на аўтапілоце, мы, хутчэй за ўсё, убачым мэтанакіраваную, высокаэфектыўную аўтаматызацыю, якая вырашае пэўныя праблемы. Шлях да поўнай аўтаматызацыі прадпрыемства будзе паўтаральным, абумоўленым спецыялізацыяй і супрацоўніцтвам. Імпульс нарастае, і вырашэнне гэтых інжынерных задач адкрые шлях для наступнай хвалі карпаратыўных інавацый.

(Крэдыты выявы для DALL-E)