Kas nutinka, kai vietoj duomenų išgavimo pradedamas naudoti dirbtinis intelektas, kuris peržiūri ir naršo darbo skelbimų portalus, kaip tai darytų žmogus.
Problema: darbo skelbimų portalai be API
Darbo skelbimų portalai yra būtini norint pasiekti kandidatus, tačiau dauguma jų, ypač regioniniai portalai, neteikia API. Norint paskelbti darbo skelbimą, reikia prisijungti prie interneto portalo, užpildyti daugiažingsnę formą, įkelti duomenis ir paspausti „Publikuoti“. Norint pašalinti skelbimą, reikia vėl prisijungti, surasti skelbimą, paspausti „Ištrinti“ ir patvirtinti per iškylančius langus. Taip reikia daryti kiekviename portale. Su kiekvienu skelbimu.
Norint tai automatizuoti tradiciniais įrankiais, reikia rašyti skriptus, nukreiptus į konkrečius HTML elementus: paspausk šį mygtuką su šia CSS klase, užpildyk šį laukelį su šiuo ID, palauk, kol pasirodys šis div. Tai veikia, kol portalas nepakeičia klasės pavadinimo, neperkelia mygtuko ar neprideda iškylančio lango. Tada skriptas nustoja veikti, o darbo skelbimai arba nepavyksta paskelbti, arba nepavyksta pašalinti.
Toks pažeidžiamumas sukelia daug problemų:
- Tradiciniais būdais programuojamos sistemos nuolat genda - bet koks portalo vartotojo sąsajos žymėjimo pakeitimas panaikina automatizavimo galiojimą. Net nedidelis dizaino pakeitimas gali sutrikdyti visą skelbimų publikavimo procesą.
- Naršyklės automatizavimas darbo eigos varikliuose yra rizikingas – pilnas „headless“ naršyklės veikimas „n8n“ sistemoje eikvoja atmintį ir procesoriaus resursus, keldamas grėsmę visų kitų toje pačioje instancijoje veikiančių darbo eigų stabilumui.
- Dvigubi skelbimai ir likę be priežiūros skelbimai - be tinkamo būsenos stebėjimo, darbo skelbimas gali būti paskelbtas du kartus tame pačiame portale arba likti paskelbtas ilgai po to, kai jau turėjo būti panaikintas.
- Kiekvienas naujas portalas reiškia naują kodą - kiekviena darbo skelbimų lenta turi skirtingą išdėstymą, skirtingą struktūrą, skirtingą patvirtinimo eigą. Naujo portalo palaikymas reiškia visiškai naujo selektorių rinkinio rašymą ir priežiūrą.
Mes ėmėmės visiškai kitokios strategijos.
Agentinis požiūris
Vietoj to, kad rašytume scenarijus, nukreiptus į HTML elementus, sukūrėme sistemą, kurioje dirbtinio intelekto agentas vizualiai naršo darbo skelbimų portaluose taip pat, kaip tai darytų žmogus: skaito puslapį, randa reikiamus mygtukus, užpildo laukelius ir patvirtina veiksmą. Agentas nepriklauso nuo CSS selektorių ar DOM struktūros. Jis mato sąsają ir ją analizuoja.
Sistema valdo visą darbo skelbimo ciklą: kai personalo atrankos specialistas duomenų bazėje pažymi, kad darbą reikia publikuoti, agentas prisijungia prie portalo ir jį paskelbia. Kai darbo vieta pažymima užpildyta, agentas vėl prisijungia, suranda skelbimą ir jį pašalina. Personalo atrankos specialistas niekada tiesiogiai neliečia portalo.
Veikia trys tarpusavyje sąveikaujančios sudedamosios dalys:
Duomenų bazė, kurioje registruojami visi darbo skelbimai, portalai ir publikacijos
Trys „Baserow“ lentelės sudaro sistemos pagrindinį informacijos šaltinį. Lentelėje „Darbai“ saugomi visi darbo pasiūlymai su išsamia informacija ir būsena. Lentelėje „Darbo skelbimų portalai“ saugomi kiekvieno palaikomo portalo prisijungimo duomenys ir konfigūracija. Lentelėje „Darbo skelbimai“ registruojami visi publikacijos įvykiai: koks darbo skelbimas buvo paskelbtas kuriame portale, kada, jo dabartinė būsena ir viešasis URL.
Dėl šios struktūros sistema visada žino kiekvieno skelbimo būseną. Prieš skelbdama, ji patikrina, ar darbo skelbimas jau yra paskelbtas tame portale. Prieš pašalindama, ji patvirtina, kad yra aktyvus skelbimas, kurį reikia pašalinti. Nėra dubliavimų. Nėra likusių skelbimų.
DI agentas, kuris savarankiškai naršo portaluose
Sistemos pagrindinis modulis yra naršyklėje veikiantis DI agentas, kurį palaiko GPT-4o ir Playwright, veikiantis kaip atskira mikroserviso programa „Google Cloud Run“ platformoje. Kai agentas iškviečiamas, jis gauna darbo skelbimo duomenis ir portalo prisijungimo duomenis, paleidžia naršyklę ir savarankiškai naršo portale, prisijungia, užpildo skelbimo formą ir paskelbia darbo skelbimą.
Norėdamas pašalinti skelbimą, tas pats agentas prisijungia, peržiūri darbdavio valdymo skydelį, suranda konkretų skelbimą pagal ID arba pavadinimą, spusteli „ištrinti“ ir patvirtina per bet kurį modalinį dialogą. Jei skelbimas jau buvo pašalintas rankiniu būdu, agentas tai atpažįsta ir apie tai praneša.
Esminis skirtumas nuo tradicinės automatizacijos: agentas nesiremia iš anksto užkoduotais selektoriais. Jei portalas pakeičia išdėstymą, perkelia mygtuką ar prideda naują patvirtinimo etapą, agentas prisitaiko, nes jis vizualiai skaito sąsają ir mąsto, ką daryti, o ne laikosi fiksuoto scenarijaus.
Viską sujungiantis koordinavimo lygis
n8n tvarko logiką, maršrutizavimą ir duomenų bazės operacijas. Kai „Baserow“ pasikeičia užduoties būsena, „webhook“ suaktyvina atitinkamą darbo eigą. Sistema lygiagrečiai gauna portalo konfigūracijas ir esamus publikacijų įrašus, sujungia duomenis, patikrina, ar veiksmas yra reikalingas (užkertant kelią pasikartojantiems įrašams ar nereikalingam pašalinimui), pradeda agento veiklą ir atnaujina publikacijos įrašą su rezultatu.
Personalo atrankos specialisto darbas yra paprastas: pakanka pakeisti statuso laukelį „Baserow“ sistemoje. Visi tolesni veiksmai – navigacija portale, formų pildymas, patvirtinimas ir duomenų saugojimas – vyksta automatiškai.
Kaip veikia sistema
Architektūra sąmoningai atskiria funkcijas. „n8n“ tvarko koordinavimą ir duomenis. DI agentas tvarko sąveiką su naršykle. „Baserow“ saugo būsenos duomenis.
„Webhook“ aktyvinimas ir patvirtinimas - kai personalo atrankos specialistas „Baserow“ pakeičia darbo skelbimo statusą, suveikia „webhook“. Darbo eiga išskiria atnaujintą darbo skelbimo įrašą ir patikrina, ar statusas iš tiesų pasikeitė į „Publikuoti“ arba „Pašalinti“, taip užkertant kelią klaidingam aktyvinimui dėl nedidelių pakeitimų, pvz., rašybos klaidos taisymo darbo aprašyme.
Lygiagretus duomenų paėmimas - skelbiant darbo skelbimą, darbo eiga vienu metu paima visus aktyvius portalus, atitinkančius darbo vietos šalį, ir patikrina „Darbo skelbimai“ lentelę dėl esamų įrašų. Šalinant skelbimą, ji paima aktyvius darbo skelbimus ir atitinkamus portalo prisijungimo duomenis. Šis lygiagretus metodas užtikrina greitą darbo eigą.
Dubliavimo ir būsenos apsauga - prieš skelbiant, sistema patvirtina, kad tikslinėje svetainėje nėra aktyvaus skelbimo apie šį darbą. Prieš pašalinant, ji patvirtina, kad yra aktyvus skelbimas, kurį reikia pašalinti. Šis lygmuo užkerta kelią dažniausiai pasitaikančioms klaidoms: dvigubam darbo skelbimo paskelbimui arba bandymui pašalinti skelbimą, kurio jau nebėra.
Agento API iškvietimas - patikrintas duomenų paketas siunčiamas HTTP POST metodu į „Google Cloud Run“ aplinkoje veikiančią agento mikropaslaugą. Agentas paleidžia naršyklę, įvykdo užduotį ir grąžina rezultatą, įskaitant viešą užduoties URL adresą bei portalui būdingą ID naujiems skelbimams arba patvirtinimą apie sėkmingą pašalinimą.
Duomenų bazės atnaujinimas - Sėkmingai įvykdžius operaciją, „n8n“ įrašo rezultatą atgal į „Baserow“. Naujų skelbimų atveju „Darbo skelbimai“ lentelėje sukuriamas įrašas su būsena „Paskelbta“ ir viešuoju URL. Pašalinimo atveju esamas įrašas atnaujinamas į „Pašalinta“ su laiko žyma.
Sistemos nauda
Sistema sukurta ir paruošta naudoti regioniniuose darbo portaluose, pradedant Nigerijos darbo skelbimų portalu „Jobslin“.
Perėjimas nuo tradiciniais metodais pagrįstos automatizacijos prie agentinio požiūrio keičia galimybes:
- Svetainės pokyčiai nesugadina sistemos - kadangi agentas naršo vizualiai, o ne pagal CSS klasių pavadinimus, darbo skelbimų lentos atnaujinimai vartotojo sąsajoje nereikalauja kodų pakeitimų iš mūsų pusės.
- Naršyklės variklis veikia už n8n ribų - izoliavus našų „Playwright“ naršyklės variklį specialiai tam skirtame „Cloud Run“ konteineryje, užtikrinamas n8n stabilumas. Darbo eigos variklis tvarko logiką, o agento mikropaslauga – naršyklės veiklą.
- Skelbimo būsena visada žinoma - kiekvienas skelbimo paskelbimas ir pašalinimas yra stebimas „Baserow“ su laiko žymėmis ir būsena. Nėra skelbimų, kurių būsena būtų nežinoma.
- Naujų portalų analizė tampa konfigūracijos užduotimi, o ne kodavimo projektu - naujos darbo skelbimų lentos pridėjimas reiškia sistemos užklausos ir maršruto į mikropaslaugą pridėjimą, o ne naujo trapaus selektorių rinkinio rašymą ir priežiūrą.
- Darbuotojų paieškos specialistų darbo eiga išlieka paprasta - jie keičia laukelį lentelėje. Sistema tvarko viską kitą. Agentinė architektūra vartotojui yra visiškai nematoma.
Kaip sistema bus tobulinama
Dabartinė sistema viename portale apima visą skelbimo paskelbimo ir pašalinimo ciklą. Keletas plėtinių padėtų išplėsti jos taikymo sritį:
- Plėtra į kelis portalus - papildomų darbo skelbimų svetainių integravimas įvairiose rinkose. Kiekvienam naujam portalui reikia naujos užklausos mikropaslaugos portale, o ne naujo automatizavimo kodo, todėl plėtra vyksta žymiai greičiau nei taikant tradicinį metodą.
- Agentų užklausų optimizavimas - vykdymo žurnalų stebėjimas, siekiant nustatyti, kur agentas atlieka nereikalingus veiksmus arba susipainioja dėl netikėtų vartotojo sąsajos elementų, ir užklausų sugriežtinimas, siekiant užtikrinti trumpiausią ir efektyviausią navigacijos kelią.
- Skelbimų patikrinimas - periodiškas tikrinimas, ar paskelbti skelbimai vis dar yra portale, siekiant aptikti atvejus, kai portalas pašalina skelbimą dėl politikos priežasčių, nepranešęs apie tai sistemai.
Išvada
Dauguma darbo skelbimų portalų niekada nesiūlys API. Tradiciškai tai reiškė pasirinkimą tarp rankinio darbo ir trapios automatizacijos, kuri sugenda po kiekvieno vartotojo sąsajos atnaujinimo. Agentinis metodas atveria trečią kelią: DI, kuris naršo portale taip, kaip tai darytų žmogus, tačiau tai daro nuosekliai, automatiškai ir dideliu mastu.
Sistema nekonkuruoja su portalo sąsaja, o dirba su ja. Kai portalas keičiasi, agentas prisitaiko. Kai reikia pridėti naują portalą, agentas gauna naują užklausą, o ne naują kodų bazę. Tai yra skirtumas tarp automatizavimo, kuris veikia, kol nesugenda, ir automatizavimo, kuris veikia nuolat.