Agent Resource

Kad vairāki mani projekti sāka izmantot MI aģentus, galvenā grūtība nebija jaunu lomu veidošana. Problēma bija atkārtota izmantošana.

Noderīgs process sākās kā uzvedne vai Markdown fails, pēc tam tika pielāgots konkrētam projektam, ieguva lokālus noteikumus un pakāpeniski novirzījās no oriģināla. Kļuva grūti saprast, kura versija ir aktuāla, ko var droši pārnest un kā atjaunināt vienu projektu, nepārrakstot tā lēmumus vai privātos datus.

Agent Resource radās kā veids, kā padarīt aģentu darbplūsmas pārnesamas, pārbaudāmas un pārvaldāmas.

Projekts sākās 2026. gada maijā kā Ops Hub, Portfolio Site operacionālais slānis.

Agrīnajās versijās bija Business Analyst, Backlog Operator, Log Keeper, Librarian, Todoist integrācija un projekta vēstures saglabāšanas noteikumi.

Darba laikā izveidojās pirmais svarīgais modelis:

Agent Resource glabāja kopīgo lomas modeli. Konkrēts projekts saņēma lokālu aģentu, kas mantoja pamata uzvedību, bet saglabāja savu tvērumu, ceļus, datus un ierobežojumus.

Portfolio un Powermap kļuva par pirmajiem izmēģinājuma laukiem. Noderīgus risinājumus no reāliem projektiem varēja atgriezt Agent Resource un izmantot kopīgo arhetipu uzlabošanai.

Tādējādi Ops Hub pakāpeniski kļuva par atkārtoti izmantojamu aģentu lomu bibliotēku.

Pirmā arhitektūra bija stipri atkarīga no Todoist. Tas palīdzēja darbu sākt ātri, bet ar laiku radīja lieku infrastruktūru:

Jūnijā Backlog tika pārcelts uz Markdown.

Katra darba vienība kļuva par atsevišķu noturīgu failu. Atkarības kļuva par tipizētām attiecībām, bet Kanban un citi skati par kanonisko datu projekcijām. Todoist izpildes vide un lokālais noslēpums tika noņemti, saglabājot vēsturiskos ierakstus kā migrācijas pierādījumus.

Tajā pašā periodā projekts ieguva nosaukumu Agent Resource. Tas precīzāk aprakstīja faktisko funkciju: saglabāt un izplatīt atkārtoti izmantojamas spējas aģentu atbalstītiem projektiem.

Līdz augustam Agent Resource saturēja daudzas lomas, modeļus, palaišanas paketes un noteikumus. Tie joprojām bija tikai dokumentu kopums.

Arhetipu varēja nokopēt, bet tam nebija neatkarīgas versijas, konfigurācijas shēmas, instalētāja, automatizētas validācijas, regresijas testu, migrācijas līguma vai droša jaunināšanas procesa.

Git rādīja, kuri faili ir mainījušies, bet neatbildēja uz svarīgākiem jautājumiem:

Šie jautājumi noveda pie projekta galvenā arhitektūras pagrieziena.

Agent Resource pārstāja uzskatīt atsevišķu lomu vai Markdown arhetipu par pilnīgu pārnesamu spēju.

Galvenā vienība kļuva par neatkarīgi versijotu pakotni:

Versiju plūsmas ir apzināti nodalītas:

Pakotne var attīstīties neatkarīgi. Projekts instalē konkrētu versiju, reģistrē lokālos pielāgojumus un nesaņem automātiskus atjauninājumus.

Pat esošu projektu nevar migrēt, vienkārši kopējot failus. Instalācija sākas ar tikai lasāmu saderības auditu, turpinās ar migrācijas priekšlikumu un maina lokālo eksemplāru tikai pēc nepārprotama apstiprinājuma.

Agent Resource arī pārstāja būt starpprojektu komandcentrs. Tas nenosaka citu projektu mērķi, prioritātes vai produkta virzienu. Tas atbild par atkārtoti izmantojamām spējām un drošu to instalēšanas procesu.

Backlog pakotne tika izveidota, salīdzinot darba sistēmas Agent Resource, Holding, Wiki Articles, Portfolio Site, MilSim, LifeGraph un SQVL-MESH.

Projektiem bija kopīgs pamats:

Konkrētie statusi, tipi, attiecības un dokumentu struktūras atšķīrās. Tādēļ pakotne nekļuva par viena šķietami ideāla projekta kopiju.

backlog@0.1.0 nodrošina konfigurējamu dzīves ciklu, mašīnlasāmas Markdown darba vienības, tipizētas lokālās un ārējās attiecības, dublikātu un karājošu atsauču noteikšanu, ģenerētu JSON indeksu, Kanban, tipu un pārskata skatus, arhivēšanas un aizstāšanas līgumus, izvēles Backlog Operator, no atkarībām brīvus rīkus un regresijas fixtures.

Instalējot šo pakotni sevī, Agent Resource migrēja 14 vēsturiskas darba vienības un 62 attiecības, nezaudējot to saturu vai iepriekšējos Todoist migrācijas pierādījumus.

Projekta žurnāls pakāpeniski uzkrāja pārāk daudz pienākumu. Izstrādes vēsture, aktuālais operacionālais konteksts, Backlog stāvoklis un Git līmeņa detaļas tika sajauktas vienā artefaktā.

Darbs vairākos projektos atklāja skaidrāku sadalījumu:

development-log@0.1.0 savienoja vienu kanonisku VERSION, vienu jēgpilnu Development Log ierakstu un vienu Git komitu pārbaudāmā izmaiņu kopā.

Versija 0.2.0 pievienoja vairāku produktu repozitorijus. Vienā repozitorijā tagad var būt neatkarīgi versijoti produkti ar atsevišķiem versiju failiem, Development Logs, Git tagu nosaukumvietām, failu tvērumiem un lietotņu piesaistēm.

Ja izmaiņa skar kopīgu tvērumu, validācija pieprasa paaugstināt katru skarto versiju plūsmu. Fails bez noteikta īpašnieka bloķē komitu, nevis liek sistēmai minēt atbildību.

Design System kļuva par ceturto atkārtoti izmantojamo pakotni.

Tā izauga no Portfolio Site production pieredzes un apvieno trīs lomu darbu: Design System Architect, nosacītu Visual Designer un Design System Builder. Iepriekšējā Crawler pienākumi pārgāja uz Architect, bet Essence Writer kļuva par Builder daļu.

Katrs Design System elements saņem vienu kanonisku Markdown Essence:

design-system@0.2.0 atbalsta tipizētu domēna grafu, avotu pārklājumu, komponentu robežu validāciju un pārbaudes starp Preview un reālu lietojumu produktā.

Projektam specifiska uzvedība netika pasludināta par universālu. Dokumentācijas reģistrs, ģenerēto mediju piegāde un neatkarīga Design System laidienu plūsma paliek izvēles profili, ko aktivizē tikai tad, ja produktam tie patiešām vajadzīgi.

OpCon Graph izauga no divām reālām realizācijām.

LifeGraph pierādīja lielu privātu zināšanu grafu aktīvā lietošanā. SQVL-MESH pievienoja stingrāku operacionālā konteksta modeli un obligātu izcelsmi no katra strukturētā ieraksta līdz sākotnējiem pierādījumiem.

Salīdzinājums radīja opcon-graph@0.1.0 ar faktiem, notikumiem, entītijām, tēmām, lēmumiem, neapstrādātu avotu izcelsmi, tipizētām attiecībām, privātuma robežām, mašīnlasāmām projekcijām, validāciju un sintētiskiem testiem.

Nākamais jautājums bija par glabāšanu. Vai PostgreSQL var dot MI aģentiem ātrāku un kompaktāku piekļuvi lielam kontekstam, saglabājot dabisku ievadi, pierādījumus, vēsturi un atjaunošanas iespēju?

Versija 0.2.0 pievienoja PostgreSQL shēmu, autentificētu zemu privilēģiju API, atomārus ierakstus, optimistisku konkurenci, revīziju vēsturi, idempotentus atkārtojumus, ierobežotu izgūšanu, rezerves kopiju un atjaunošanas rīkus.

Versija 0.3.0 pievienoja pārskatītu vēsturisko importu, nepārprotamu vēsturiskās nenoteiktības saglabāšanu un bezzaudējumu SQL uz Markdown atjaunošanu.

Ar tehniskām fixtures nepietika, tāpēc pakotne tika pārbaudīta reālā LifeGraph pilotprojektā.

Pirms migrācijas tika saglabāti avota dati, šifrētas rezerves kopijas un atsauces bāzlīnija. Izolētā PostgreSQL datubāzē tika importēti:

Pēc salāgošanas SQL kļuva par vienīgo rakstītāju ierobežota pilotprojekta laikā. Viena reāla lietotāja ievade izveidoja neapstrādātu ierakstu, jaunus atvasinātus ierakstus un versijotus esošo zināšanu atjauninājumus.

Pārbaudes apstiprināja precīzu importu, dublikātu neesamību atkārtotos pieprasījumos, saglabātu revīziju vēsturi, atjaunošanu no šifrētas SQL rezerves kopijas, aktuālā SQL stāvokļa eksportu atpakaļ uz Markdown un attiecību un vēsturisko versiju saglabāšanu.

Tehniski eksperiments izdevās.

Produkta hipotēze neapstiprinājās.

Izvēlētajos reālajos izgūšanas gadījumos zināmu Markdown failu efektīva nolasīšana aizņēma aptuveni 0.4-0.8 ms, bet attālināta SQL pilnā konteksta izgūšana aptuveni 18-50 ms. SQL aploksnes bija arī aptuveni 2.5-2.9 reizes lielākas.

Pilnu MI atbildes laiku un apmaksāto marķieru patēriņu neizdevās izmērīt, tāpēc nevarēja apgalvot marķieru ietaupījumu vai kopēju paātrinājumu. Nebija arī neatkarīga novērtējuma, kas pierādītu labāku atbilžu kvalitāti.

Tādēļ PostgreSQL tika noraidīts aktīvajai LifeGraph realizācijai, kas atgriezās pie saglabātās sākotnējās Markdown datu kopas. Tikai SQL vidē veiktās eksperimentālās izmaiņas tika apzināti izslēgtas, nevis pasniegtas kā migrētas zināšanas.

Pirms atgriešanās tika saglabāti eksperimenta pierādījumi un koda momentuzņēmumi, pārbaudītas šifrētas ārpus resursdatora rezerves kopijas, atjaunoti un validēti sākotnējie 1 572 Markdown ieraksti, apstiprinātas visas 845 domēna attiecības, dzēsti LifeGraph SQL servisi un akreditācijas dati, bet atkārtoti izmantojamā PostgreSQL spēja saglabāta OpCon Graph pakotnē.

Tas kļuva par vienu no svarīgākajiem Agent Resource rezultātiem.

Veiksmīga realizācija vēl nepierāda, ka tehnoloģija kalpo lietotājam. Spēja risinājumu droši noraidīt var būt tikpat svarīga kā spēja to uzbūvēt.

Pirmais izaicinājums bija nodalīt atkārtoti izmantojamu uzvedību no projektam specifiska konteksta. Pakotnei jāpārnes līgums, bet ne privāti dati, akreditācijas dati, zīmols vai produkta lēmumi.

Otrais bija saglabāt vēsturisko informāciju, to nepārrakstot. Ja vecam ierakstam nav zināms datums, autors vai izcelsme, migrācijai jāsaglabā šī nenoteiktība, nevis jāizdomā tīras vērtības jaunai shēmai.

Trešais bija nepadarīt Agent Resource par citu projektu centrālo īpašnieku. Pakotne nodrošina spēju, bet mērķa projekts saglabā lokālu pārvaldību.

Ceturtais bija nodalīt tehnisko korektumu no reālās vērtības. PostgreSQL pilotprojekts izturēja integritātes un atjaunošanas pārbaudes, bet nepierādīja labāku lietotāja rezultātu.

Piektais bija projektēt rollback pirms migrācijas sākuma. Git zars nevar atjaunot ignorētus privātus datus vai datubāzes ierakstus. Īstai atjaunošanai jāaptver avota momentuzņēmumi, vēlākie ieraksti, akreditācijas dati, servisi, rezerves kopijas un atjaunošanas validācija.

Pašreizējā momentuzņēmumā Agent Resource ir versijā 1.8.3 un satur četras neatkarīgi attīstāmas pakotnes:

Tas nav tirgus vai SaaS platforma. Tam nav automātisku visu projektu atjauninājumu un vienotas centrālās pārvaldības saskarnes.

Tas ir Git pārvaldīts pakotņu repozitorijs, kurā praksē pierādītas aģentu darbplūsmas kļūst par spējām ar versijām, līgumiem, testiem, instalācijas robežām un atjaunošanas ceļiem.

Projekts sākās ar mērķi atkārtoti izmantot aģentus. Praktiskais darbs parādīja, ka atkārtoti izmantojams aģents ir pārāk maza vienība.

Patiesi pārnesamai MI spējai vajag vairāk nekā lomu vai uzvedni. Tai vajag datus un to robežas, konfigurāciju, validāciju, versiju vēsturi, migrācijas politiku, atjaunošanu un pierādījumus, ka tā darbojas ārpus avota projekta.

Agent Resource vairs nav projekts par to, cik aģentu var savākt. Tas ir par to, vai sistēmām, ko šie aģenti izmanto, var uzticēties.

Dažreiz spēcīgākais brieduma pierādījums nav veiksmīga migrācija. Tā ir spēja godīgi pārbaudīt hipotēzi, to noraidīt un droši atgriezties.