Introduction Hallo almal, ek is Max Nechaev - ingenieursbestuurder by Snoonu, stigter en AI-enthousiast. Ek is al 'n rukkie in sagtewareontwikkeling. Terug toe ek iOS-apps gebou het, was daar tonne argitektuurpatrone daar buite. Hulle voel stewig. Gedink deur. Battle-getesteer oor jare. Toe het ek nooit gedink ek sou die een wees wat 'n nuwe argitektuur sou skep - veral nie vir AI-stelsels nie. Maar voordat ons na die oplossing kom, laat ons praat oor die probleem. Net nou, AI gaan deur 'n gek hype siklus. Startups pop op en sterf elke dag. Meer en meer mense duik in lae kode en geen kode gereedskap soos Make, n8n, en ander. En jy weet wat? Ek dink dit is wonderlik. Miljoene mense stap in 'n nuwe soort werklikheid. Dit voel soos die vroeë dae van die internet, toe webwerwe van statiese na interaktiewe gegaan het, en dit het skielik gevoel asof alles moontlik was. Meer mense bou AI-agente. En ek hou daarvan. Maar daar is 'n vang. Daar is nog steeds geen gedeelde begrip van hoe om fleksibele, skaalbare AI-stelsels te ontwerp nie. Geen werklike ontwerppatrone nie. Geen wye aanvaarde struktuur nie. Net vibes. Hoe meer ek rondom gekyk het, hoe meer ek dit gesien het. Agente wat in n8n gebou is, lyk soos spaghetti. Onmoontlik om te lees, debug, of skaal. Tutoriale oor die bou van agente in Python? dieselfde storie. Alles gedemp in een lêer, geen skeiding van bekommernisse nie. Natuurlik, ervare ontwikkelaars mag weet dat hulle dinge moet skei - maar beginners nie. So vandag wil ek die oplossing deel waarop ek kom om te vertrou.Dit is hoe ek my AI-stelsels struktureer.Hoe ek verantwoordelikhede skei.Hoe ek dinge flexibel, skaalbaar en eintlik gesond hou. Laat ek jou voorstel vir my raamwerk, ontwerppatroon of argitektuur - noem dit wat jy wil - Agente van Aktiewe Ketting. AAC Meet AAC (Agent Action Chains) Op 'n oomblik het ek iets eenvoudig besef. as chaos voortdurend weer en weer gebeur, miskien is dit nie 'n ongeluk nie. So ek het begin eksperimenteer. Eerstens, met blokke binne n8n. Dan begin ek logika handmatig skei - hier is waar ek input hanteer, hier is waar ek verwerking doen, hier is die kernlogika. Uiteindelik het rolle begin opduik. En dan het dit my geraak. Dit benodig struktuur. Dit benodig argitektuur. Dit is hoe AAC gebore is - Agent Action Chains. Dit is nie 'n ander raamwerk met 'n duisend bladsye dokumente nie. AAC is 'n manier om AI-stelsels te bou soos 'n volwasse ingenieur, nie soos iemand wat dinge saamstel en hoop op die beste nie. Wat is die kernidee? Ek het die stelsel verdeel in agente met duidelike rolle. Elke agent doen presies een ding. Hulle praat almal deur JSON-kontrakte - geen raai, geen magie, geen rommel nie. Alles word voorspelbaar, skaalbaar en makliker om te debug. Dink aan dit soos 'n span. Een draai die ingang. ander data verwerk. 'N Derde besluit wat om volgende te doen. Nog 'n agent praat met geheue. Een vang mislukkings. Nog 'n ander kyk en log alles. Almal ken hul werk.En saam, die stelsel loop soos 'n Switserse horlosie. Die skoonheid van AAC is dat dit platformagnostiek is. Jy kan dit in n8n implementeer, in , in Python met behulp van FastAPI, selfs binne LangChain of LangGraph as jy die tyd neem om dit behoorlik op te stel. Ek maak.com Here’s How It Works (In Plain English) Verbeel 'n stewige span.Nie 'n chaotiese groep waar almal alles op 'n keer doen nie, maar 'n bemanning waar elke persoon hul werk ken, hul ruimte besit en 'n duidelike resultaat lewer. Dit is hoe AAC werk. Wanneer 'n invoer die stelsel tref - of dit van 'n gebruiker of 'n eksterne diens is - gaan dit eers deur 'n agent wat eenvoudig die deur oopmaak en dit afskakel. Dan kom basiese verwerking. Ons haastig nie tot gevolgtrekkings nie. Eerstens struktureer ons die invoer, skoonmaak die lawaai, normaliseer dit. Die stap alleen bespaar ure van debugging op die pad. 'N skoon invoer is die helfte van die argitektuur. Daarna kom die orkestrator. Dit is die brein van die stelsel. Dit voer nie die taak self uit nie. In plaas daarvan bepaal dit wie wat moet doen, in watter volgorde, met watter parameters. Die rol van die orkestrator is om die vloei te beplan, te lei en te bestuur. Dan neem die spesialiste oor. Hierdie agente is gefokus. Een klassifiseer, 'n ander resumeer, 'n derde vang eksterne data, en so aan. Elkeen het 'n duidelike doel. Hulle oorlê nie, hulle veg nie oor verantwoordelikhede nie, hulle skryf nie mekaar se outputs nie. Jy kan hulle ruil, verbeter, hergebruik - net soos goeie sagteware modules. Wanneer die stelsel iets moet onthou, kom geheue in die spel. Dit is sy eie agent. Dit stoor nie alles blindelings nie. In plaas daarvan weet dit hoe om die regte dinge op die regte tyd te herhaal - vorige gesprekke, gebruikerskontekst, interne feite. Dit is hoe jou stelsel ophou om 'n goudvis te wees en begin om soos 'n ware assistent te optree. Foutbestuur word net so ernstig behandel. AAC sluit 'n toegewyde agent daarvoor in - die Guard. Dit monitor mislukkings, vang uitsonderings, neem aksie wanneer iets breek nie. Dit is nie 'n patch nie, nie 'n ewekansige poging nie. Dit is 'n werklike deel van die argitektuur. En dit is verantwoordelik vir veerkragtigheid. Terwyl dit alles gebeur, kyk die waarnemer stil. Dit volg wat elke agent doen, hoe lank dinge neem, watter besluite geneem word. Nie net vir pret nie - dit gee jou sigbaarheid in die stelsel nie. Dit het gewerk, Dit het gewerk, en waar dit kan misluk. Hoe Hoekom En uiteindelik, wanneer die hele ketting sy werk gedoen het, word die resultaat geformatteer en gelewer - terug na die gebruiker, in 'n API-respons, of waar dit moet gaan. skoon, gestruktureer en maklik om te verbruik. Dit is AAC. 'n stelsel wat nie net gebou is om te funksioneer nie, maar om te evolueer, te skaal en onder beheer te bly. All AAC Roles: Who Does What and Why It Matters AAC is gebou op duidelike skeiding van verantwoordelikhede. Elke agent is nie net 'n tegniese blok nie - dit is 'n logiese eenheid met 'n gedefinieerde rol en 'n kommunikasie kontrak. Ingress Agent: the Entry Point Verwerk die inkomende signaal. Purpose: Dit kan 'n webhook, 'n formulier, 'n Telegram-boodskap, 'n Kafka-gebeurtenis wees - dit maak regtig nie saak nie. Want die menging van logika met integrasie lae is die eerste stap na die bou van 'n monoliet. In n8n is dit gewoonlik net 'n webhook-nood. Dit ontvang die versoek, log die data en stuur 'n skoon JSON-gehalte in die stelsel. Voorbeeld van die pseudo-kode: { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Verander die ruwe invoer in iets wat nuttig is. Purpose: Hierdie agent skoonmaak die lawaai. Dit herstel kasse, strepe vreemde simbole, valideer struktuur, en onttrek sleutelvelde. Dit maak seker dat alles wat in die stelsel oorgedra word, voorspelbaar en konsekwent is. Baie mense skip voorbehandeling. Groot fout. Dit is nie net 'n "goeie-om te hê" nie - dit is die fundament. Veral wanneer jy met LLM's omgaan, is kontekshigiëne alles. Een rommelige invoer en die hele redeketen kan uiteenval. In n8n is dit gewoonlik 'n funksie knoop. In kode kan dit 'n middleware, 'n handelaar of 'n klein nutklasse wees. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System Besluit wat moet gebeur. Purpose: Die orkestrator doen nie die werk self nie. Sy taak is om te beplan, te oordra en te monitor. Dit neem die skoon ingang, maak die gebruiker se bedoeling uit en aktiveer die regte spesialis agente. In eenvoudige gevalle kan dit net 'n if/else blok wees. In meer gevorderde instellings is dit 'n volledige LLM wat hardloop met versigtig ontwerp prompts. { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Jy kan dit selfs 'n lys van beskikbare agente oorgedra en laat dit die beste pad vooruit kies. Die sleutelidee is hierdie: die orkestrator los nie die probleem op nie.Dit bou die roete.Dit besluit wie moet doen wat, en in watter volgorde. Specialist Agents: Focused Experts (TOOLS) Maak 'n enkele, goed gedefinieerde taak. Purpose: Hierdie agente is nie hier om die hele probleem op te los nie - net een spesifieke stuk daarvan, en doen dit goed. Klassifiseer 'n versoek Genereer 'n antwoord Uitvoerende entiteite Gebruik 'n eksterne API Vertaal teks Jy kan uiteindelik met duisende van hierdie. Elkeen is 'n aparte funksie, 'n skoon module, of 'n subflow in n8n. En dit is presies wat die stelsel flexibel en skaalbaar maak. Wil jy 'n nuwe vermoë byvoeg? Maak net 'n nuwe spesialis en registreer dit. Die orkestrator hoef nie herschryf te word nie - dit hoef net te weet dat hierdie instrument bestaan. Voorbeeld van 'n kontrak tussen die orkestrator en 'n spesialis: { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past gee die relevante konteks. Purpose: Hierdie agent haal feite op. Dit is dit. Dit vra vir 'n databasis, 'n vector winkel, 'n Redis-cache - wat jy ook al het - en gee presies terug wat nodig is. Dit neem nie besluite nie, raai nie nie, hallusineer nie. Dink aan dit as die stelselgeheue.U kan dit gebruik om 'n gebruiker se verlede bestellings te herhaal, vektorbeddings uit 'n kennisbasis te pas, of vorige interaksies te vang. In AAC is geheue altyd sy eie ding.Daarom kan jy dit skaal, cache, of selfs verbind dit in verskeie stelsels. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Skep en hanteer mislukkings. Purpose: As 'n spesialis crashes of die orkestrator breek, stap die waarnemer in. Dit log die fout, stuur waarschuwings, en optioneel hardloop fallback logika - soos om weer met 'n ander agent of die terugkeer van 'n veilige standaard antwoord. In produksie is hierdie rol nie onderhandelbaar nie. Foute sal gebeur. GPT kan vuil terugkeer. API's kan uitloop. Jy benodig 'n laag wat weet wat om te doen wanneer dinge na die kant gaan. Voorbeeld: GPT retourneer ongeldig JSON. Die waarnemer vang dit, log die probleem, kennisgewing Slack, en stuur 'n fallback boodskap. { "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 log, analiseer, en gee jou sigbaarheid in wat eintlik gebeur het. Purpose: Hierdie agent interferer nie - dit kyk net. Wil om te volg hoe lank elke agent geneem het om te reageer? Watter data het die geheue agent getrek? Hoe dikwels moes die Guard 'n terugval veroorsaak? Observer log dit alles op enige instrument wat jy gebruik - Supabase, Amplitude, Segment, of iets aangepas. Jy hoop jy sal dit nie nodig hê nie, maar as iets breek, is dit die enigste manier om te verstaan wat verkeerd gegaan het. Sonder 'n waarnemer vlieg jy blind. Egress Agent: the Final Touch Maak die proses skoon. Purpose: Hierdie agent neem die finale uitvoer, formateer dit en lewer dit waar dit moet gaan - na die gebruiker, 'n API, 'n webhook, Slack, wat ook al. Dit maak nie besluite nie. Een van die mees algemene foute is om hierdie stap te vergeet. sonder 'n toegewyde egress-agent, loop jy die risiko om gebroke data, ruwe logboeke of antwoorde na die verkeerde plek te stuur. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Elkeen van hierdie agente is 'n boublok. Jy kan hulle in parallel hardloop, hulle onafhanklik vervang, hulle oor ketting gebruik. What’s Next? How to Start Using AAC in Your Projects Hoe om te begin gebruik AAC in jou projekte As jy hierdie lees, is die kans dat jy reeds dieselfde probleme wat ek gedoen het, gekonfronteer het. Jou projek groei voortdurend. Gebruik gevalle vermenigvuldig. Die logika versprei breër. Die agente word "slimmer" - maar die stelsel word swakker. Wat was 'n nette MVP gisteraand het nou in 'n verwarde rot geword. Wil jy 'n nuwe tak toevoeg? Dit is 'n moeilikheid. Probeer om te debug waarom GPT iets vreemds teruggekeer het? Geen idee waar dit selfs gebeur het nie. Dit is die oomblik waarop jy begin vra - is daar 'n ander manier? Daar is. Die implementering van AAC beteken om die manier waarop jy dink te verander.Dit is 'n verskuiwing van magie na ingenieurswese. En die beginpunt is nie kode nie. Dit kyk anders na jou stelsel. Probeer om jou logika as 'n ketting van onafhanklike spesialiste voor te stel. Een neem die invoer. 'n ander voorberei die data. 'n derde besluit wat om te doen. Dan kom die uitvoerder. Na dit - geheue. Dan vang iemand mislukkings. Ten slotte, iemand log wat gebeur het. Dit is jou toekomstige agent, AAC-styl. Op die oomblik, al daardie rolle is óf impliciet of so swaar saamgebind dat niemand weet wat is wat nie. Die eerste werklike stap is om daardie rolle uitdruklik te maak. Selfs net geestelik. Sketch hulle uit. Gee hulle name. Begin die regte vrae te vra: wie is hier verantwoordelik vir die orkestrasie? Waar is die geheue? Hoe weet ek of dinge regtig gewerk het? Wat gebeur as een blok misluk? Sodra jy dit doen, word die waarde van modulariteit duidelik. Wanneer alles in een plek gebundel word, breek een fout die hele stelsel. Maar wanneer dinge as los gekoppelde agente gestruktureer word, word mislukkings geïsoleer - en die stelsel gaan voort. Daarom is in AAC, elke agent geïsoleer, kommunikeer deur kontrakte, en het geen bewustheid van die ander nie. Dit is soos mikroservices binne 'n pipeline. En dan begin die pret. Jy besef skielik dat jy stukke van die stelsel kan hergebruik. Die dieselfde klassifikasie agent wat een vloei hanteer, kan in 'n ander gebruik word. Die geheue blok kan oor verskeie kettings gedeel word. Jy kan selfs die orkestrator slimmer maak - laat dit kies watter agente te trigger. Dit is nie fantasie nie. Dit is die baseline volwassenheid AAC bring. Op no-code platforms soos n8n word dit 'n ware supermag. Jy begin 'n biblioteek van agente bou. Elkeen is 'n substroom met 'n gedefinieerde kontrak. Wil 'n nuwe bot bou? Bel net die agente wat jy nodig het, in die volgorde wat jy hulle nodig het. Wil 'n blok vervang? Doen dit sonder vrees. Wil die prestasie monitor of volg waar dinge die meeste misluk? Jy het dit reeds - Observer log alles, Guard vang elke mislukking. Jy begin om die stelsel te sien soos 'n ingenieur, nie iemand bang om die kode te raak nie. Jy maak 'n ketting van GPT-oproepe in werklike argitektuur - iets wat lewe, skaal, log, evolueer. En as jy nie tyd het om alles nou te herbou nie - dit is goed. Begin met een vloei. Een toegangspunt. Een eerlike oomblik waar jy sê: "Okay, laat my 'n nuwe benadering hier probeer. Laat ek die rolle skei. Voeg 'n bietjie beheer by." Dit is die oomblik waarop jy begin bou met AAC. En die kans is - jy wil nie teruggaan nie.
