Nedēļas nogalē atkal pavadīju pusdienu atkārtojot darbus, pēkšņi sapratu, ka mans AI automatizācijas kaudze jau darbojas pusgadu, un efektivitāte ir acīmredzami uzlabojusies. Izlemu apkopot, kā šī arhitektūra sadarbojas.
Kodols sastāv no diviem lomu sadalījumiem: **Hermes veic plānošanu**, Claude Code ir meistars. Hermes būtībā ir uzdevumu sekretārs, kurš apstrādā grafikus, atmiņas pārvaldību, fona cron uzdevumus un izplata ziņas uz Telegram un Feishu. Iedomājies to kā mūžīgi pieejamu sekretāru, kurš atceras vakar izteikto ideju, šovakar laicīgi atgādina un rīt automātiski palaiž kādu datu vākšanas skriptu.
Patiesi sarežģītos kodēšanas darbus es uzticu Claude Code, lai viņš tos paveic uzreiz. Lieli pārveidojumi, koda auditi vai kāda funkcija no 0 līdz 1 dizainam — šos darbus tieši izmantoju Claude Code CLI režīmā, lai viņš tos padara pilnīgus. Abiem ir piekļuve manai prasmju bibliotēkai (metodoloģijas uzkrāšana), ja Hermes vēlas atkārtoti izmantot kādu esošu loģiku, viņš vienkārši pieprasa prasmi; arī Claude Code to var izmantot, pāreja ir gandrīz bez izmaksām.
Modeļa izvēlē ir cost-benefit līdzsvars. Ikdienas sarunām, ikrīta ziņojumiem un tirgus uzraudzībai, kas notiek bieži, izmantoju Haiku (lētāk), bet, kad patiešām ir nepieciešams dziļš secinājums par lielām uzdevumiem, pāreju uz Sonnet vai Opus. Tādējādi mēneša token izmaksas var kontrolēt.
Mainot skatījumu, **aģents ir automatizācijas ražošanas līnijas smadzenes**, kas pieņem lēmumus un plāno; **prasme ir ražošanas līnijas rokas**, kas veic konkrētu darbu. Hermes darbojas aģenta pusē, piešķirot visu līniju katram posmam atmiņu un kontekstu. Ja kāds uzdevums pārsniedz robežas, tas tiek tieši nodots Claude Code šim ekspertam.
Pirms šīs sistēmas izmantošanas es katru nedēļu pavadīju 8 stundas atkārtojošiem darbiem. Tagad daži darbi būtībā darbojas fona režīmā, vienkārši regulāri pārbaudot ziņojumus vai trauksmes signālus. Lielākais klupšanas akmens ir skaidra prasmes dokumentācija, kas izraisa izsaukumu kļūdas. Tagad katrai jaunai prasmei stingri pievienoju "biežāk sastopamās problēmas" un "izmantošanas scenārijus".
Runājot par to, es uzskatu, ka AI automatizācijas kodols nav izmantot spēcīgāko modeli, bet **sadali darbu pietiekami sīki, katra vienība ir pietiekami neatkarīga, un kļūdas ir viegli labojamas**. Mazām komandām šajā virzienā investīcijas noteikti var ietaupīt daudz roku darba.
Kad automatizētā sistēma sāk darboties, kā uzraudzīt, vai tā joprojām ir dzīva
Šis ir mans dziļākais mācību brīdis, kad esmu izveidojis vairākas automatizētas plūsmas: **sistēma nevar nomirt naktī un likt tev to atklāt tikai nākamajā dienā**.
Es reiz esmu izvietojis plānotu uzdevumu, domājot, ka, iestatot cron, varu to atstāt bez uzraudzības. Rezultātā, kad pēc nedēļas devos pārbaudīt statusu, es atklāju, ka tā jau 3 dienas ir klusējusi - datubāzes savienojums bija pārtraukts, un nebija nekādu paziņojumu. Kopš tā laika esmu izveidojis pilnīgu uzraudzības filozofiju, ko šodien dalīšos ar jums.
**Pirmais līmenis: izpildes cikla uzraudzība**
Pamatmetode ir apskatīt cron pēdējo izpildi last_run_at. Mana noteikums ir: **ja pēdējā izpildes laiks pārsniedz paredzēto ciklu 2 reizes, nekavējoties aktivizēt brīdinājumu**. Piemēram, ja uzdevumam vajadzētu darboties ik pēc 5 minūtēm, ja last_run_at ir vairāk nekā 10 minūtes no tagadnes, tad uzreiz sūtu brīdinājumu uz Telegram. Šis rādītājs ir ārkārtīgi efektīvs - apmēram 90% no "sistēma ir avarējusi" var tikt atklāti 1 stundas laikā, nevis pasīvi gaidot, kad biznesa nodaļa to pamanīs.
**Otrais līmenis: API pārtraukšanas mehānisms**
API nestabilitāte ir norma. Mana pieeja ir: **ja 3 reizes pēc kārtas API pieprasījums neizdodas, automātiski pārtraukt uz 24 stundām**. Kāpēc 3 reizes? Jo 1-2 reizes var būt tīkla svārstības, bet 3 reizes pēc kārtas neizdošanās norāda uz reālu problēmu. Pārtraukšanas laikā sistēma vairs nemēģina veikt pieprasījumus, lai izvairītos no dārgu API resursu un žurnālu vietas izšķērdēšanas nepareizā stāvoklī. Tas ir daudz efektīvāk nekā akli atkārtot pieprasījumus.
**Trešais līmenis: statusa faila noturība**
Katru reizi, kad sistēma darbojas, es ierakstu pašreizējo stāvokli - veiksmīgu pieprasījumu skaitu, neveiksmīgu skaitu, laika zīmogu, kļūdu informāciju - statusa failā. Šo failu es glabāju 30 dienas. Kāda ir šī pieejas priekšrocība? Varu atgriezties atpakaļ - "kāpēc pagājušajā trešdienā ziņojumu izsūtīšanas līmenis pēkšņi nokritās līdz 60%?" - vienkārši pārlūkojot žurnālus ir atbilde. Statusa fails neaizņem vietu, bet sniedz man pilnīgu revīzijas ķēdi.
**Ceturtais līmenis: nedēļas cilvēka pārskats**
Katrā nedēļā, veltot 15 minūtes, es ļauju sistēmai automātiski ģenerēt kopsavilkuma ziņojumu: ziņojumu izsūtīšanas veiksmes līmenis, kļūdu līmeņa sadalījums, vārdu skaits, vai ir bijušas anomālijas. Nav nepieciešams ļoti bieži, bet **nav jāpaļaujas tikai uz automātiskajiem brīdinājumiem**. Dažreiz tendences, kad kļūdu līmenis no 2% pieaug līdz 4%, automātiskā uzraudzība to neziņos, bet cilvēks to uzreiz pamanīs un sapratīs, ka "šeit jāpievērš uzmanība".
**Galvenā atziņa**
Automatizācija tiek uzbūvēta ātri, bet **ja uzraudzība ir pareiza, tad varu būt drošs, neuzņemoties pastāvīgu uzraudzību**. Mana pieredze ir: automātiskie brīdinājumi atbild par ārkārtas situācijām (sistēma pilnībā avarējusi), bet cilvēka pārskats atbild par tendences jautājumiem (pakāpeniska pasliktināšanās). Abas pieejas kopā dod šai sistēmai ilgu dzīvi. Citādi pat visgudrākā automatizācija ir tikai laika sprādziens melnā kastē.