🇸🇮 Priklopna postaja CM AI: Od poskusa integracije umetne inteligence do protokola za povezane sisteme

CM Journal / r/CM_Ecosystem — 2026-10-07

Epilog k prvotni objavi (30. 9. 2026).

1. Od eksperimenta do opredeljenega protokola

Projekt CM AI Docking Port se je začel s praktičnim vprašanjem: kako lahko agent umetne inteligence (UI) komunicira z obstoječim programskim sistemom, ne da bi moral ta sistem sam postati aplikacija, ki temelji na UI?

Rešitev ni bila v izdelavi novega pogona za UI, uvedbi osrednje tržnice ali podvajanju obstoječe poslovne logike. Namesto tega je projekt raziskoval možnost vzpostavitve tanjše plasti: standardizirane vstopne točke, prek katere lahko agent UI odkrije sistem, razume njegove deklarirane zmogljivosti, pošlje strukturirano zahtevo in prejme strojno berljiv odgovor.

Končna zasnova je dokumentirana v specifikaciji »CM AI Docking Port — Reception Protocol Specification v1.0«, ki je na voljo na naslovu:

cmfree.duckdns.org/app/public/ai/spec.html

Osnovno načelo je preprosto: obstoječi sistemi morajo ohraniti odgovornost za lastne podatke in poslovne odločitve. Integracija UI naj bi se s temi sistemi povezovala, ne pa jih nadomeščala.

Sistem CM, ki predstavlja prvotni primer uporabe, že zagotavlja poslovne funkcionalnosti prek svojega obstoječega vmesnika API. Docking Port nadgrajuje to zmogljivost, namesto da bi ustvarjal še en vir resnice.

2. Delovanje protokola

Arhitektura ločuje odkrivanje, komunikacijo in poslovno logiko na posamezne plasti.

Odkrivanje Sodelujoča namestitev objavi strojno berljiv manifest, ki ga spremlja dokumentacija, razumljiva ljudem. Manifest identificira vozlišče, njegovo vstopno točko za sprejem (Reception endpoint), deklarirane zmogljivosti in ustrezne operativne omejitve.

To agentu zagotavlja določeno izhodišče, ne da bi bila za vsako namestitev potrebna uporaba vtičnika, specifičnega za CM, ali trdo kodirana integracija.

Sprejem (Reception) Vstopna točka za sprejem (Reception endpoint) predstavlja enotno komunikacijsko točko med agentom UI in sodelujočim omrežjem.

Agent pošlje strukturirano zahtevo HTTP/JSON izbranemu vstopnemu vozlišču. Komponenta Reception zahtevo preveri, po potrebi dostopi do lokalnega poslovnega API-ja in lahko zahtevo posreduje konfiguriranim sosednjim vozliščem, kadar je posredovanje med več vozlišči implementirano in omogočeno.

Agent prejme en sam združen odgovor. Ni mu treba upravljati omrežne topologije, neposredno kontaktirati sosednjih vozlišč ali usklajevati posameznih klicev API.

Ta ločitev je temeljnega pomena. Agent opredeli, kaj želi poiskati; komponenta Reception pa je odgovorna za to, kako se zahteva obdela znotraj dovoljenih meja omrežja.

Obstoječa poslovna logika Komponenta Reception ne nadomešča osnovnega poslovnega API-ja. Zahtevo za preverjanje razpoložljivosti se lahko na primer interno posreduje obstoječi končni točki availability_multi.php.

Poslovni sistem ostaja pristojen za lastne podatke o razpoložljivosti. Reception pridobljene podatke zapakira v skupno strukturo odgovora ter jim doda informacije o izvoru, izvornem vozlišču, globini iskanja in ažurnosti.

Rezultat je lahka integracijska plast in ne nova poslovna aplikacija.

3. Skupni model zahtev in odgovorov

Protokol uporablja strukturirane ovojnice JSON, da so zahteve in odgovori razumljivi različnim implementacijam.

Zahteva lahko opredeljuje:

Protokol in različico. Enolični identifikator zahteve in polje za rok veljavnosti. Predvideno lokacijo in polmer iskanja. Zahtevano funkcionalnost in njene parametre. Operativne omejitve, kot sta največja globina iskanja in število rezultatov. Seznam že obiskanih vozlišč, ki ga komponenta Reception vzdržuje med potekom zahteve. Vstopno vozlišče in cilj iskanja sta ločena pojma. Agent lahko kontaktira komponento Reception na eni lokaciji, hkrati pa zahteva informacije o drugi lokaciji.

Ovojnica odgovora zagotavlja dosledno strukturo, ki vsebuje splošno stanje, identifikator zahteve, metapodatke iskanja, rezultate in napake. Vsak rezultat ohrani podatke o svojem izvoru, namesto da bi bil tiho združen v odgovor, ki bi bil videti kot dokončen in verodostojen.

Odgovor lahko tudi nakazuje, da je delni. Če do določenega vozlišča ni mogoče dostopati, sistem ne sme dajati vtisa, da so bila uspešno poizvedena vsa ustrezna vozlišča.

Ta razlika je pomembna za sisteme umetne inteligence: nepopolnega iskanja se ne sme predstaviti kot celovit pregled razpoložljivih informacij.

Začetna različica MVP je namerno omejena zgolj na branje podatkov o razpoložljivosti in odkrivanje virov. Ne omogoča izvajanja rezervacij, spreminjanja cen ali drugih operacij pisanja.

4. Decentralizirano usmerjanje brez centralnega registra

Priklopna vrata so zasnovana okoli neodvisno upravljanih vozlišč in ne obveznega centralnega imenika.

Vsak sodelujoči sprejemnik vzdržuje konfiguriran seznam sosedov. V trenutni zasnovi se ti odnosi vzpostavijo s konfiguracijo nodes.json, ki jo upravlja operater, namesto s samodejno registracijo pri centralnem glavnem strežniku.

Ko je aktivno posredovanje z več vozlišči, lahko sprejemnik uporabi ciljno lokacijo in geografske položaje svojih sosedov za izbiro ustreznih naslednjih skokov.

Dve omejitvi služita različnim namenom:

max_depth omejuje, kako daleč lahko zahteva potuje skozi zaporedna vozlišča. max_fanout omejuje, koliko sosednjih vozlišč lahko sprejemnik kontaktira v danem koraku posredovanja. Identifikator zahteve in seznam obiskanih vozlišč pomagata preprečiti podvajanje zank obdelave in usmerjanja. Namen poteka zahteve je omejiti uporabno življenjsko dobo zahteve, ko se širi po omrežju.

Ti mehanizmi obravnavajo pomembno arhitekturno tveganje: na videz majhna zahteva enega agenta se ne sme pomnožiti v nenadzorovan promet po večjem omrežju.

Omejitve mora uveljavljati sodelujoča infrastruktura, ne pa jih mora zgolj predlagati agent. Vozlišče mora ohraniti nadzor nad tem, kaj posreduje in koliko dela sprejme.

Decentralizacija ne pomeni odsotnosti pravil. Pomeni, da odgovornost ostane porazdeljena med sodelujočimi sistemi, namesto da bi bila prenesena na eno samo obvezno centralno storitev.

5. Pomen lokalnih in zasebnih omrežij

Ena najpomembnejših posledic te zasnove je, da ni sama po sebi odvisna od javnega interneta.

Isti komunikacijski model HTTP/JSON se lahko uporablja na javno dostopnih končnih točkah ali znotraj nadzorovanega omrežja, če so vzpostavljene zahtevane omrežne poti, končne točke in pravilniki dostopa.

Razmislite o skupini ponudnikov nastanitev, hotelskem kompleksu, kampusu ali zbirki neodvisnih poslovnih sistemov.

Vsaka namestitev vzdržuje svojo podatkovno in poslovno logiko. Njen operater odloča, katera sosednja vozlišča bo povezal in katere zmogljivosti bo razkril. Zahteva, ki vstopi prek enega sprejemnika, se lahko obravnava lokalno ali posreduje dovoljenim sosedom.

Agent umetne inteligence ne potrebuje neposrednega dostopa do vsakega sistema. Potrebuje dostop do določene vstopne točke, medtem ko povezana infrastruktura obravnava notranjo komunikacijo.

Ta pristop je lahko še posebej uporaben tam, kjer morajo sistemi ostati neodvisno upravljani, kjer notranje storitve ne bi smele biti javno razkrite ali kjer bi morala biti izmenjava podatkov omejena na izrecno povezano skupino.

Ponuja tudi praktičen način za postopno uvajanje dostopa umetne inteligence v obstoječo infrastrukturo. Sistem lahko izpostavi ozko definirano zmožnost samo za branje, ne da bi se najprej preselil na skupno platformo ali zamenjal programsko opremo.

Omrežje lahko ostane zasebno, tudi ko je protokol odprt za pregled in implementacijo.

Vendar obstaja pomembna razlika: zasebno omrežje ne zagotavlja samodejno varnosti. Uvedba mora obravnavati nadzor dostopa do omrežja, izpostavljenost končnih točk, preverjanje pristnosti, kjer je potrebno, in operativno spremljanje. Trenutnih varnostnih predpostavk MVP, ki je samo za branje, ne smemo zamenjati za popoln varnostni model za vsako okolje.

6. Kaj je bilo dokazano – in kaj je še treba dokazati

Projekt je napredoval dlje od konceptualnega predloga.

Uvedeni sta bila javni manifest in človeku berljiva dokumentacija. Implementirana je bila končna točka za sprejem z enim vozliščem in preizkušena v primerjavi z obstoječim API-jem za razpoložljivost. Testi so zajemali veljavne zahteve, nepodprte metode zahtev, neveljavne deklaracije protokolov, manjkajoče parametre datuma in nepodprte vrste poizvedb.

Pripravljena so bila tudi ločena testna vozlišča za raziskovanje komunikacije prek dejanskih omrežnih povezav brez razkrivanja dejanskih poslovnih podatkov.

To so pomembni rezultati. Dokazujejo, da je mogoče obstoječemu poslovnemu sistemu dodeliti definirano, strojno berljivo vstopno točko, ne da bi bilo treba ponovno zgraditi njegovo osnovno funkcionalnost.

Sami po sebi ne dokazujejo, da je celoten decentraliziran model usmerjanja končan ali da bodo poljubne neodvisne implementacije pravilno medsebojno delovale.

Posredovanje z več vozlišči, izbira omejenega soseda, preprečevanje zank, obravnavanje delnih rezultatov in scenariji napak morajo biti ocenjeni glede na dogovorjeno specifikacijo, ko implementacija in testiranje napredujeta.

Prav tako objava protokola ne vzpostavlja samodejno industrijskega standarda. Interoperabilnost zahteva druge implementacije, ponovljive teste, jasno upravljanje različic in stalno pozornost do varnosti in operativnega vedenja.

Zato je ustrezen zaključek: projekt je vzpostavil konkretno zasnovo protokola in delujočo osnovo z enim vozliščem, medtem ko širše delovanje omrežja ostaja predmet implementacije in preverjanja.

7. Omejitve današnjih orodij umetne inteligence za množični trg

Protokol je lahko tehnično dostopen, ne da bi bil enako uporabljiv prek vseh vmesnikov umetne inteligence.

Številni pomočniki z umetno inteligenco za množični trg delujejo v nadzorovanih okoljih. Glede na izdelek, konfiguracijo, dovoljenja in razpoložljive povezovalnike lahko pomočnik prebere javno spletno stran, vendar morda ne more pošiljati poljubnih zahtev HTTP, izvajati večkorakih omrežnih operacij ali dostopati do storitev, ki so na voljo le v zasebnem lokalnem omrežju (LAN).

Tudi če lahko pomočnik dostopa do javne končne točke, to še ne pomeni, da lahko samostojno odkrije sosednja vozlišča, pravilno izvede zahtevani protokol, ohrani ovojnico zahteve ali zanesljivo interpretira delne odzive.

Te omejitve so povezane z dejanskim okoljem integracije in ne nujno s samim protokolom.

Majhen, konkreten primer tega se je pojavil spontano, v tednu dni po objavi prvega javnega članka. Avtomatiziran račun za zbiranje vsebin na poslovnem omrežju je povzel naslov tega članka in zanj ustvaril kratek, splošen komentar – predstavljen kot »naslov, ki si zasluži pozornost« in napisan v slogu tržne analize, vendar brez kakršne koli obravnave dejanske strukture ovojnice protokola, njegovega modela zahtev in odzivov ali katere koli podrobnosti, opisane v tem dokumentu oziroma specifikaciji, na katero se ta sklicuje. Povezava do vira, ki jo je navedel račun, je vodila nazaj na izvirni članek. Ime tu ni pomembno, prav tako ne gre za namerno zavajanje – račun najverjetneje na enak avtomatiziran način obdeluje številne naslove. Primer kaže na nekaj preprostejšega in uporabnejšega: orodje, povezano z umetno inteligenco, lahko odkrije javno dostopen vir in se odzove na njegov naslov, ne da bi se pri tem ukvarjalo z njegovo vsebino. To je zgoraj opisana omejitev, opažena v dejanskem okolju in ne v testnem sistemu.

»Docking Port« (priklopna točka) se zavestno izogiba odvisnosti od določenega modela ali ponudnika umetne inteligence. Kljub temu zasnova protokola, neodvisna od ponudnika, ne more zagotoviti dostopa do orodij, ki bi bili prav tako neodvisni od ponudnika.

Celovitejša uvedba bi lahko zahtevala izvedbeno okolje za agente z izrecno odobrenim dostopom do omrežja, namenski povezovalnik ali programsko opremo, ki deluje v istem nadzorovanem okolju kot sodelujoča vozlišča.

Zato trenutnega pristopa ne bi smeli predstavljati kot univerzalno rešitev tipa »priklopi in delaj« (plug-and-play) za vsak potrošniški klepetalni robot. Njegova uporabnost v praksi je odvisna od zmogljivosti in dovoljenj programske opreme, ki deluje kot agent.

8. Odprt protokol, ne pa končano univerzalno omrežje

CM AI Docking Port je poskus ločitve razmeroma majhne tehnične težave od precej širšega vprašanja razvoja aplikacij z umetno inteligenco.

Protokolu ni treba vedeti, kako ponudnik nastanitev upravlja rezervacije, kako podjetje določa cene ali kateri model umetne inteligence na koncu interpretira rezultate. Njegova naloga je opredeliti skupen način za odkrivanje zmogljivosti, pošiljanje omejenih zahtev, ohranjanje sledljivosti izvora rezultatov in vračanje razumljivih odgovorov.

Takšna ločitev odpira prostor za različne izvedbe in različna operativna okolja.

Hkrati protokol ostaja projekt v razvoju. Njegov trenutni obseg je namerno omejen, stanje njegove implementacije pa mora biti natančno opisano. Specifikacija je javno dostopna, vendar sama objava še ne zagotavlja varnostne certifikacije, univerzalne združljivosti ali pripravljenosti za produkcijsko rabo v poljubnih omrežjih.

Naslednji pomemben dokaz bodo prinesle neodvisne implementacije in ponovljivi testi med povezanimi vozlišči, vključno z obravnavo napak in uveljavljanjem operativnih omejitev.

9. Kje se kaže največji praktični potencial protokola

Treba je izpostaviti še eno pomembno razliko.

Docking Port je mogoče odkriti na javnem spletu, zanj obstaja javna dokumentacija, dostop do njega pa je mogoč prek združljive programske opreme. Vendar njegova najbolj prepričljiva praktična uporaba morda ne bo množična raba prek splošno namenskega klepetalnega robota z umetno inteligenco.

Njegov najmočnejši neposredni primer uporabe bi lahko bil v zaprtih, povezanih sistemih, kjer so sodelujoča vozlišča, omrežne poti, dovoljenja in operativne meje strogo nadzorovani.

V takšnem okolju namen protokola postane otipljiv. Neodvisni sistemi lahko ponudijo določene zmogljivosti, namenski sprejemni modul (»Reception«) lahko usklajuje zahteve, vsak sistem pa ohrani nadzor nad lastnimi podatki in poslovno logiko.

Agent umetne inteligence ne potrebuje neomejenega dostopa do omrežja. Potrebuje opredeljen vmesnik in nadzorovano pot do informacij, ki jih sme zahtevati.

To je razlika med obetavno demonstracijo in uporabnim delom infrastrukture.

CM AI Docking Port še ni končano univerzalno omrežje, niti ne trdi, da to je. Gre za protokol v razvoju, ki raziskuje, kako lahko agenti umetne inteligence komunicirajo z obstoječimi sistemi, ne da bi te sisteme prisilili v uporabo ene same platforme ali agentu prepustili neomejen nadzor.

Javni splet omogoča, da je protokol mogoče odkriti. Povezano in nadzorovano okolje omogoča, da je delovanje sistema predvidljivo, njegove meje pa uveljavljive.

Prav tu bi lahko zasnova priključka CM AI Docking Port prešla iz faze zanimivega eksperimenta v svojo najbolj praktično in utemeljeno uporabo.

— ekipa CM (ljudje in umetna inteligenca; zasluge so enakopravno priznane tam, kjer so upravičene)