Introduction Hey visi, es esmu Max Nechaev - inženierzinātņu vadītājs Snoonu, dibinātājs un AI entuziasts. Es esmu bijis programmatūras izstrādē jau ilgu laiku. Atpakaļ, kad es būvēju iOS lietotnes, tur bija tonnas arhitektūras modeļu. Bet pirms mēs nonākam pie risinājuma, parunāsim par problēmu. Pašlaik AI iet cauri neprātīgam hype ciklam. Startups parādās un mirst katru dienu. Arvien vairāk cilvēku iegremdējas zemā koda un bezkoda rīkos, piemēram, Make, n8n un citos. Un jūs zināt, ko? es domāju, ka tas ir pārsteidzoši. Miljoniem cilvēku ienāk jauna veida realitātē. Tas jūtas kā agrīnās dienas internetā, kad tīmekļa vietnes pārgāja no statiskas uz interaktīvu, un pēkšņi šķita, ka viss bija iespējams. Vairāk cilvēku veido AI aģentus.Un man tas patīk.Bet ir nozvejas.Vēl joprojām nav kopīgas izpratnes par to, kā veidot elastīgas, skalojamas AI sistēmas.Nav reālu dizaina modeļu.Nav plaši pieņemta struktūra.Tikai vibrācijas. Jo vairāk es paskatījos apkārt, jo vairāk es to redzēju. aģenti, kas būvēti n8n, izskatās kā spageti. Neiespējami lasīt, labot vai mērogot. Apmācības par būvēšanas aģentiem Python? Tas pats stāsts. Viss tika iemests vienā failā, bez bažām. Protams, pieredzējuši izstrādātāji var zināt, ka viņiem vajadzētu sadalīt lietas - bet iesācēji to nedara. Tātad šodien es gribu dalīties ar risinājumu, uz kuru esmu nonācis.Tā es strukturēju savas AI sistēmas.Kā es atdalīšu atbildību.Kā es saglabāju lietas elastīgas, mērogojamas un faktiski veselīgas. Ļaujiet man iepazīstināt jūs ar manu struktūru, dizaina modeli vai arhitektūru - sazinieties ar to, ko vēlaties - Aģentu rīcības ķēdes. AAC Meet AAC (Agent Action Chains) Ja haoss notiek atkal un atkal, varbūt tas nav nejaušība, varbūt tas nozīmē, ka sistēma trūkst. Tātad es sāku eksperimentēt. vispirms, ar blokiem n8n iekšpusē. Tad es sāku manuāli atdalīt loģiku - šeit ir, kur es apstrādāju ievadi, šeit ir, kur es apstrādāju, šeit ir pamata loģika. Tādā veidā radās AAC - aģentu rīcības ķēdes. Tā nav cita sistēma ar tūkstoš lapām dokumentu. AAC ir domāšanas veids, kā veidot AI sistēmas kā pieaugušais inženieris, nevis kā kāds, kurš apvieno lietas un cer uz labāko. Kāda ir pamatideja? Es sadalīju sistēmu aģentiem ar skaidrām lomām. Katrs aģents dara tieši vienu lietu. Viņi visi runā caur JSON līgumiem - nav uzminēšanas, nav burvju, nav neskaidrību. Domājiet par to kā par komandu. Viens ieejas veids. Citi datu apstrādes procesi. Trešais nolemj, ko darīt tālāk. Vēl viens aģents runā ar atmiņu. Viens no neveiksmēm. Cits skatās un ieraksta visu. Un kopā sistēma darbojas kā Šveices pulkstenis. AAC skaistums ir tas, ka tas ir platformas agnostic. Jūs varat to īstenot n8n, , Python, izmantojot FastAPI, pat LangChain vai LangGraph iekšpusē, ja jūs lietojat laiku, lai to pareizi iestatītu. Make.com izstāde Here’s How It Works (In Plain English) Ne haotiska grupa, kurā visi dara visu uzreiz, bet apkalpe, kurā katrs cilvēks zina savu darbu, pieder savai telpai un sniedz skaidru rezultātu. Tieši tā darbojas AAC. Kad ienākums nonāk sistēmā - vai tas ir no lietotāja vai ārējā pakalpojuma - tas vispirms iet cauri aģentam, kas vienkārši atver durvis un izslēdz to. Tad nāk pamata apstrāde. Mēs nesteidzīgi nonākam pie secinājumiem. Pirmkārt, mēs strukturējam ienākumu, notīrām troksni, normalizējam to. Tas solis vien ietaupa stundas no debugēšanas uz ceļa. Tālāk nāk orķestris. tas ir sistēmas smadzenes. tas pats neveic uzdevumu. Tā vietā tas nosaka, kam jādara ko, kādā secībā, ar kādiem parametriem. orķestra loma ir plānot, vadīt un pārvaldīt plūsmu. Tad speciālisti pārņem. Šie aģenti ir koncentrēti. Viens klasificē, otrs apkopo, trešais iegūst ārējos datus un tā tālāk. Katram ir skaidrs mērķis. Viņi nepārklājas, viņi nevienojas par atbildību, viņi nepārraksta viens otra izejas. Jūs varat tos apmainīt, uzlabot, atkārtoti izmantot - tāpat kā labi programmatūras moduļi. Kad sistēmai ir nepieciešams kaut ko atcerēties, atmiņa ienāk spēlē. Tas ir tā paša aģents. Tas neuzglabā visu akli. Tā vietā, tas zina, kā iegūt pareizās lietas pareizajā laikā - iepriekšējās sarunas, lietotāja konteksts, iekšējie fakti. Kļūdu apstrāde tiek uzskatīta par tikpat nopietnu. AAC ietver tam veltītu aģentu - Guard. Tā uzrauga neveiksmes, uztver izņēmumus, rīkojas, kad kaut kas sabrūk. Tas nav patch, nevis nejaušs mēģinājums. Tā ir reāla arhitektūras daļa. Un tā ir atbildīga par noturību. Kamēr tas viss notiek, novērotājs klusi skatās.Tas izseko, ko katrs aģents dara, cik ilgi lietas aizņem, kādi lēmumi tiek pieņemti.Ne tikai jautrības dēļ - tas dod jums redzamību sistēmā.Ne “vai tas darbojās?” bet Tas strādāja , Tas darbojās, un kur tas var neizdoties. Kā Kāpēc Un visbeidzot, kad visa ķēde ir paveikusi savu darbu, rezultāts tiek formatēts un piegādāts - atpakaļ lietotājam, API atbildē vai kur tas ir nepieciešams. Tā ir AAC. Sistēma, kas izveidota ne tikai, lai darbotos, bet arī lai attīstītos, mērogotos un paliktu kontrolē. All AAC Roles: Who Does What and Why It Matters Katrs aģents nav tikai tehnisks bloks - tas ir loģiska vienība ar definētu lomu un komunikācijas līgumu. Šajā sadaļā ir izklāstīts, kādām lomām šīs lomas ir, kā tās mijiedarbojas un kāpēc pat viena no tām bieži noved pie arhitektūras sāpēm vēlāk. Ingress Agent: the Entry Point Pārvaldīt ienākošo signālu. Purpose: Tas varētu būt webhook, veidlapas iesniegšana, Telegram ziņa, Kafkas notikums - tas tiešām nav svarīgi. Jo loģikas sajaukšana ar integrācijas slāņiem ir pirmais solis, lai izveidotu monolītu. In n8n, tas parasti ir tikai webhook mezgls. tas saņem pieprasījumu, ieraksta datus un pārsūta tīru JSON lietderīgo slodzi uz sistēmu. Piemērs no pseidokoda: { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Pārvērst izejvielu kaut ko lietderīgu. Purpose: Šis aģents attīra troksni.Tas nosaka korpusu, izstiepj dīvainus simbolus, validē struktūru un iegūst galvenos laukus.Tas nodrošina, ka viss, kas tiek nodots sistēmai, ir paredzams un konsekvents. Daudzi cilvēki izlaiž priekšapstrādi. Liela kļūda. Tas nav tikai "labi, lai būtu" - tas ir pamats. Īpaši, ja jūs nodarbojaties ar LLM, konteksta higiēna ir viss. N8n tas parasti ir funkcijas mezgls. Kodā tas varētu būt middleware, pārvaldnieks vai neliela lietojumprogrammu klase. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System Izlemt, kas ir jāizdara. Purpose: Orķestrators pats neveic darbu. tā uzdevums ir plānot, deleģēt un uzraudzīt. tas ņem tīrīto ievadi, nosaka lietotāja nodomu un aktivizē pareizos speciālistu aģentus. Vienkāršos gadījumos tas varētu būt tikai if/else bloks. Vairāk attīstītajos iestatījumos tas ir pilnvērtīgs LLM, kas darbojas ar rūpīgi izstrādātiem norādījumiem. Piemēram, jūs varat GPT-4 atgriezt strukturētu izpildes plānu JSON: { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Jūs pat varat nodot to sarakstu ar pieejamiem aģentiem un ļaut tam izvēlēties labāko ceļu uz priekšu. Galvenā ideja ir šāda: orķestris neatrisina problēmu, tas veido maršrutu, tas izlemj, kam jādara kas un kādā secībā. Specialist Agents: Focused Experts (TOOLS) Izpildiet vienu, labi definētu uzdevumu. Purpose: Šie aģenti nav šeit, lai atrisinātu visu problēmu - tikai vienu konkrētu daļu no tā, un dara to labi. Klasificēt pieprasījumu Izveidot atbildi Ekstrakcijas vienības Izmantojiet ārējo API Teksta tulkošana Jūs varētu nonākt pie vairākiem desmitiem no tiem. Katrs ir atsevišķa funkcija, tīrs modulis vai apakšplūsma n8n. Un tieši tas padara sistēmu elastīgu un mērogojamu.Vai vēlaties pievienot jaunu spēju?Tikai izveidojiet jaunu speciālistu un reģistrējiet to.Orķestrators nav jāpārraksta - viņam vienkārši ir jāzina, ka šis rīks pastāv. Piemērs līgumam starp orķestri un speciālistu: { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past Nodrošināt atbilstošu kontekstu. Purpose: Šis aģents iegūst faktus. tas ir tas. tas vaicā datubāzē, vectoru noliktavā, Redis kešatmiņā - neatkarīgi no tā, kas jums ir - un atgriež tieši to, kas nepieciešams. Jūs varat to izmantot, lai atgūtu lietotāja pagātnes pasūtījumus, atbilstu vektoru ievietojumiem no zināšanu bāzes vai iegūtu iepriekšējās mijiedarbības. AAC atmiņā vienmēr ir sava lieta.Tādā veidā jūs varat to skalot, kešatmiņu vai pat pievienot vairākām sistēmām. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Novērst un novērst neveiksmes. Purpose: Ja speciālists sabrūk vai orķestris sabrūk, sargs ieiet. tas ieraksta kļūdu, nosūta brīdinājumus un, iespējams, darbojas atgriešanās loģika - piemēram, atkārtoti ar citu aģentu vai atgriež drošu noklusējuma atbildi. Ražošanā šī loma nav apspriežama. Kļūdas notiks. GPT var atgriezt atkritumus. API var izlaist laiku. Jums ir nepieciešams slānis, kas zina, ko darīt, kad lietas iet sānos. Piemērs: GPT atgriež nederīgu JSON. sargs to uztver, ieraksta problēmu, paziņo Slack un nosūta atgriešanās ziņojumu. { "error": "Invalid JSON from Summarizer", "fallback_response": "Sorry, I couldn’t process your request. Forwarding it to a human operator." } Observer Agent: the System’s Black Box reģistrēt, analizēt un sniegt jums redzamību par to, kas patiešām notika. Purpose: Šis aģents netraucē - tas tikai skatās.Vēlaties izsekot, cik ilgi katram aģentam bija vajadzīgs, lai reaģētu?Kādus datus atmiņas aģents izvilka?Cik bieži sargiem bija jāizdara atkāpe?Pārraugs ieraksta visu uz jebkuru rīku, ko izmantojat - Supabase, Amplitude, Segment, vai kaut ko pielāgotu. Domājiet par to kā par melno kasti lidmašīnā.Jūs cerat, ka jums tas nebūs nepieciešams, bet, kad kaut kas sabrūk, tas ir vienīgais veids, kā saprast, kas gāja nepareizi. Bez novērotāja jūs lidojat akli. ar to jūs iegūstat pilnu attēlu. Egress Agent: the Final Touch Uzklājiet procesu tīri. Purpose: Šis aģents ņem galīgo izeju, formatē to un piegādā to, kur tas ir nepieciešams - lietotājam, API, webhook, Slack, neatkarīgi no tā. Viena no visbiežāk sastopamajām kļūdām ir aizmirst šo soli. bez īpaša egress aģenta jūs riskējat nosūtīt bojātu datu, neapstrādātus žurnālus vai atbildes uz nepareizu vietu. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Katrs no šiem aģentiem ir celtniecības bloks. Jūs varat tos palaist paralēli, aizstāt tos neatkarīgi, atkārtoti izmantot tos pa ķēdēm. What’s Next? How to Start Using AAC in Your Projects Kā sākt izmantot AAC savos projektos Ja jūs lasāt šo, iespējams, jūs jau esat saskārušies ar tām pašām problēmām, ko es darīju. Jūsu projekts turpina augt. Lietošanas gadījumi vairojas. Loģika izplatās plašāk. Aģenti kļūst “gudrāki” - bet sistēma kļūst trauslāka. Kas bija tīrs MVP vakarā tagad ir pārvērsies satriekts. Vēlaties pievienot jaunu filiāli? Tas ir nepatikšanas. Mēģinot atrisināt, kāpēc GPT atgriezās kaut kas dīvains? Nav ne jausmas, kur tas pat notika. Tas ir brīdis, kad jūs sākat jautāt - vai ir cits veids? Tur ir . AAC īstenošana nozīmē mainīt veidu, kā jūs domājat. Un sākuma punkts nav kods. tas skatās uz jūsu sistēmu citādi. skaidri. bez ilūzijām. Mēģiniet iedomāties savu loģiku kā neatkarīgu speciālistu ķēdi. Viens ņem ievadi. Cits sagatavo datus. Trešais nolemj, ko darīt. Tad nāk izpildītājs. Pēc tam - atmiņa. Tad kāds nokļūst neveiksmēs. Visbeidzot, kāds ieraksta, kas noticis. Tas ir jūsu nākotnes aģents, AAC stils. Šobrīd, tomēr, visas šīs lomas ir vai nu netieši vai tik slikti sajauktas, ka neviens nezina, kas ir kas. Pirmais reālais solis ir padarīt šīs lomas skaidras. pat tikai garīgi. Izrakstīt tos. Dodiet viņiem vārdus. Sāciet uzdot pareizos jautājumus: kurš ir atbildīgs par orķestrēšanu šeit? Kur ir atmiņa? Kā es varu zināt, vai lietas patiešām darbojas? Kas notiek, ja viens bloks neizdodas? Kad jūs to darāt, modularitātes vērtība kļūst acīmredzama. Kad viss ir apvienots vienā vietā, viena kļūda pārtrauc visu sistēmu. Bet, kad lietas ir strukturētas kā atslābināti savienoti aģenti, kļūdas kļūst izolētas - un sistēma turpina darboties. Tāpēc AAC, katrs aģents ir izolēts, komunicē caur līgumiem un nav izpratnes par citiem. Tas ir kā mikroservisi vienā cauruļvadā. Un tad sākas jautrība. Jūs pēkšņi saprotat, ka jūs varat atkārtoti izmantot sistēmas daļas. To pašu klasifikācijas aģentu, kas apstrādā vienu plūsmu, var izmantot citā. Atmiņas bloku var kopīgot vairākās ķēdēs. Jūs pat varat padarīt orķestratoru gudrāku - ļaujiet tai izvēlēties, kurus aģentus izraisīt. Tas nav fantāzija. Bezkoda platformās, piemēram, n8n, tas kļūst par reālu supervaru. Jūs sākat veidot aģentu bibliotēku. Katrs no tiem ir apakšplūsma ar definētu līgumu.Vai vēlaties veidot jaunu botu?Vienkārši zvaniet aģentiem, kas jums nepieciešami, tādā secībā, kādā jums tie ir nepieciešami.Vai vēlaties aizstāt bloku?Dariet to bez bailēm.Vēlaties uzraudzīt veiktspēju vai izsekot, kur lietas neizdodas visvairāk?Jūs jau to esat saņēmuši - novērotājs ieraksta visu, apsardze uztver katru neveiksmi.Jūs sākat redzēt sistēmu kā inženieris, ne kāds baidās pieskarties kodam. Jūs pārvēršat GPT zvanu ķēdi par reālu arhitektūru - kaut ko, kas dzīvo, mēro, ieraksta, attīstās. Un, ja jums nav laika, lai pārbūvētu visu tieši tagad - tas ir labi. Sāciet ar vienu plūsmu. Vienu ieejas punktu. Vienu godīgu brīdi, kad jūs sakāt: "Labi, ļaujiet man izmēģināt jaunu pieeju šeit. Ļaujiet man atdalīt lomas. Pievienot kādu kontroli." Tas ir brīdis, kad sākat veidot ar AAC. Un izredzes ir - jūs nevēlaties atgriezties.
