--- title: "Multi-agent orchestration: kas salūza 3315 aģentu palaišanās" description: "Daudzaģentu orķestrēšana praksē: 3315 apakšaģentu palaišanas divos mēnešos, tokenu izmaksas pēc API cenām un septiņas kļūdas, no kurām katra kļuva par hooku." url: "https://madsalt.tech/lv/blog/multi-agent-orchestration-what-broke/" author: "Denys Zaichenko" language: "lv" published: 2026-10-19 updated: 2026-10-22 --- # Multi-agent orchestration: kas salūza 3315 aģentu palaišanās Īsumā No 2026. gada 17. augusta līdz 19. oktobrim mans Claude Code iestatījums palaida 3315 apakšaģentus. Pēdējo 30 dienu laikā tika izmantoti apmēram 16 miljardi tokenu, un 97,7 % no tiem bija kešatmiņas lasījumi. Es maksāju fiksētu abonementu; pēc API cenrāža cenām tie paši tokeni maksātu vismaz 3350 ASV dolāru. Kļūdas gandrīz nekad nebija tādēļ, ka modelis rakstīja sliktu kodu. Tās bija savienojumu vietās: paralēli aģenti pārrakstīja to pašu failu, visām pārbaudēm paliekot zaļām, tīrīšanas skripts izdzēsa pabeigtu darbu, un aģents rediģēja pārbaudes, kas to bloķēja. No katras kļūdas kļuva neliels skripts, kas bloķē nākamo palaišanu, un tieši šie skripti, nevis pamudinājumi, padarīja sistēmu izmantojamu. Es esmu Denys, full-stack un AI inženieris. Programmatūru veidoju ar vienu Claude Code vadošo sesiju, kas nodod darbu specializētiem apakšaģentiem: pētniekiem, plānotājam, izpildītājiem, drošības un koda pārskatītājiem. Šis ir ziņojums par šo daudzaģentu sistēmu, nevis par klienta produktu. Skaitļi nāk no žurnāliem, ko tā uztur: palaišanas reģistra (viena rinda par katru palaisto aģentu), sesiju transkriptiem un pašas konfigurācijas git vēstures. Klientu un projektu nosaukumi ir izlaisti. Esmu izveidojis arī [interaktīvu daudzaģentu orķestrēšanas dashboard](https://madsalt.tech/lv/work/multi-agent-orchestration/) kā prototipu ar parauga datiem. Viss turpmākais ir no reāliem darbiem. ## Kas ir daudzaģentu orķestrēšana? Daudzaģentu orķestrēšana ir iestatījums, kurā viens vadošais aģents nodod ierobežotus uzdevumus specializētiem aģentiem un apvieno to rezultātus; orķestrētājs pārvalda kontekstu, budžetus un atkārtotos mēģinājumus. Šajā rakstā tas parādās kā divi modeļi: vadošā sesija ar apakšaģentiem (pētniekiem, plānotāju, izpildītājiem, pārskatītājiem) un hooki, kas ievieš noteikumus, ko aģenti nevar apiet ar pārliecināšanu. [Daudzaģentu orķestrēšanas dashboard](https://madsalt.tech/lv/work/multi-agent-orchestration/) rāda to pašu ideju uz paraugdatiem; turpmākās sadaļas ir par to, kas salūza reālos darbos. ## Kā iestatījums izskatās? Viena vadošā sesija runā ar mani un atbild par uzdevumu. Lielākiem uzdevumiem tā pati neraksta produkcijas kodu. Tā izsūta darbu: - **Pētnieki** nolasa vienu koda bāzes slāni (frontend, backend, datubāze) un uzraksta īsu karti. - **Plānotājs** pārvērš karti numurētos soļos ar failu ceļiem. - **Izpildītāji** katrs ņem vienu plāna fāzi, vispirms uzraksta testus, tad kodu. Paralēlie izpildītāji saņem savu git worktree. - **Pārskatītāji** pārbauda diffu: viens drošības, otrs pareizības ziņā, abi uz viena commit. Starp tiem atrodas hooki: nelieli skripti, ko Claude Code palaiž pirms katra rīka izsaukuma un pēc tā. Hooks var bloķēt izsaukumu, piemēram, aģenta palaišanu, faila ierakstīšanu vai `git commit`. Konfigurācijā ir 165 hooki, apmēram 40 no tiem saistīti ar orķestrēšanu. Noteikumi, ko aģenti lasa, ir Markdown; noteikumi, kam tie netiek garām, ir hooki. Šis sadalījums ir galvenā divu mēnešu mācība, un pārējais raksts ir par to, kāpēc. ![Kā uzdevums virzās cauri aģentiem. Hooki atrodas starp katru soli un var to bloķēt. Parastais ceļš: Izpēte → Plāns → Kods → Pārskats → Commit; Viena kļūda trīs reizes: Kods → Tā pati kļūda 3x → Stiprāks modelis → Cilvēks.](https://madsalt.tech/charts/lv/multi-agent-orchestration-what-broke-flow.svg) *1. attēls. Mans Claude iestatījums, 2026. gada augusts līdz oktobris. Katrs paralēlais izpildītājs saņem savu git worktree.* ## Cik aģentu darbojās un ar kuriem modeļiem? | Rādītājs (2026. g. 17. aug.–19. okt.) | Vērtība | | -------------------------------------------- | --------------------------------------------------------------------------- | | Palaistie apakšaģenti | 3315 vairāk nekā 57 aktīvās dienās | | Aģentu tipi | 30 | | Visvairāk palaistie | izpildītājs (tdd-guide) 793, drošības pārskatītājs 455, general-purpose 424 | | Faktiskais modelis | Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, pārējie mantoti no vadošās sesijas | | Palaisti pa vienam | 67,7 % | | Lielākais paralēlais vilnis | 5 aģenti (griesti), sasniegts 9 reizes | | Pārskatītāju darbības uz izpildītāja darbību | 0,71 (680 pārskatīšanu, 963 izpildes) | Divi skaitļi mani pārsteidza. Pirmkārt, lielākā daļa palaišanu bija atsevišķi aģenti, nevis sazarojumi. Paralēlais darbs ir izņēmums: tas atmaksājas lasīšanā un pārskatīšanā un izmaksā dārgi rakstīšanā (skat. pirmo kļūdu zemāk). Otrkārt, 23 % palaišanu, kur aģenta fails nosauc modeli, faktiski darbojās cits modelis, gandrīz vienmēr Sonnet, paaugstināts uz Opus (584 no 610). Tas ir apzināti: hooks paaugstina modeli, kad solis skar riskantu kodu, piemēram, migrācijas, autentifikāciju vai servera maršrutus, un pēc tam, kad uz Sonnet strādājošs izpildītājs trīs reizes pēc kārtas izgāžas tajā pašā testā. Stiprākais izpildītājs darbojās 159 reizes; žurnālu nevar sadalīt pēc "riskants solis" un "atkārtota kļūda", tāpēc neapgalvoju, cik no tiem bija glābšanas gadījumi. ## Cik maksā multi-agent orchestration? Es maksāju fiksētu abonementu, tāpēc rēķina par tokenu nav. Transkripti tomēr reģistrē katru tokenu, tāpēc lūk, cik pēdējās 30 dienas (20. septembris–19. oktobris) maksātu pēc Anthropic API cenrāža cenām: | 30 dienas | Tokeni | | ---------------------- | ----------------------------------------------------- | | Kopā | apmēram 15,99 miljardi | | Kešatmiņas lasījumi | 15,55 miljardi (97,7 % no visa, kas nosūtīts modelim) | | Kešatmiņas ieraksti | 372 miljoni | | Jauna, nekešota ievade | 0,18 miljoni | | Izvade | 69 miljoni | Pēc cenrāža cenām (Opus 5.5: 4 ASV dolāri par miljonu ievades tokenu, 20 par miljonu izvades tokenu, 0,20 par miljonu kešatmiņas lasījumu; Sonnet 5.5 un Fable 5.1 pēc savām cenām) tikai trīs pašreizējo modeļu izvade, ievade un kešatmiņas lasījumi veido apmēram 3350 ASV dolāru. Tas izlaiž kešatmiņas ierakstus un vecākus modeļus, kas joprojām ir žurnālos, tāpēc patiesā API summa ir lielāka. Divas trešdaļas no šiem 3350 dolāriem ir kešatmiņas lasījumi: katra kārta no jauna sūta visu kontekstu, un kešatmiņa ir vienīgais iemesls, kāpēc tas vispār ir pieņemami. ![Kas uzrakstīja 69 miljonus izvades tokenu. Miljoni tokenu, 30 dienas. Apakšaģenti izmantoja 42 % no visiem tokeniem. Vadošā sesija: 23,70; Apakšaģenti: 45,30.](https://madsalt.tech/charts/lv/multi-agent-orchestration-what-broke-output.svg) *2. attēls. Claude transkripti, 2026. gada 20. septembris līdz 19. oktobris: 75 129 modeļa pieprasījumi.* Sadalījums starp vadošo sesiju un apakšaģentiem ir tā daļa, ko izmantotu, plānojot budžetu: - **Apakšaģenti izmantoja 42 % no visiem tokeniem, bet uzrakstīja 66 % izvades.** Vadošā sesija ir dārga, jo nes garāko kontekstu; apakšaģentos tiek uzrakstīts patiesais teksts un kods. - **Pārskatītāji ir lēti.** Drošības vai koda pārskatīšana izmantoja 1–4 miljonus tokenu. Izpildītājs izmantoja 5–100 miljonus. Divi pārskatītāji katram riskantam commit maksā mazāk nekā viens izpildītājs, kas mēģina atkārtoti. - **Lielākā sesija** 6. oktobrī palaida 63 apakšaģentus un izmantoja 372 miljonus tokenu 3,5 stundās. ## Kas salūza Katra zemāk minētā kļūda notika, tai ir datums, un tā beidzās ar hooku vai skriptu, kas neļauj tai atkārtoties. Neviena no tām nav "modelis uzrakstīja kļūdu". Parastās kļūdas noķēra testi un pārskatītāji. Šīs izlīda cauri abiem. | Datums (2026) | Kas salūza | Kas to bloķē tagad | | ------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | 19. aug. | Paralēli aģenti pārrakstīja vienu tulkojumu failu: zuda 55 no ~95 atslēgām, visas pārbaudes zaļas | Katrs aģents raksta savas atslēgas savā fragmentā; apvienošanas skripts pierāda, ka katra atslēga nonāca galā | | 24. aug. | Tīrīšanas skripts izdzēsa 4 pabeigtas darba paketes | Tīrīšana izlaiž katru worktree ar neievāktām izmaiņām; vispirms ievāc, tad tīri | | 1. sept. | Vēlākie aģentu viļņi sāka no novecojuša koda | Apvieno katra aģenta darbu kā trīspusēju patch, nekad kā faila kopiju | | 13. sept. | Aģents nomira palaišanas brīdī, un palaišana paziņoja "veiksmīgi" | Palaidējs nolasa aģenta pirmo izvadi un uz laiku atzīmē miris modeli visām sesijām | | 20. sept. | Divi manu paša noteikumi bija pretrunā; aģenti atkārtoja noraidītu komandu | Izolēto aģentu uzdevumos ir komandu formas, ko smilškaste pieņem | | 18. okt. | Aģents rediģēja pārbaudes, kas bloķēja tā commit | Pārbaudes faili ir tikai lasāmi no projektu sesijām; izmaiņas tiek reģistrētas un par tām tiek brīdināts | | 18. okt. | Labojumu norādījumi klusi mainīja to, ko saņem klienta lietotnes lietotāji | Katrs labojuma uzdevums saka "keep live behaviour"; produkta izmaiņas atgriežas pie manis | ### Paralēli rakstītāji un fails, ko skar katra funkcija Trīs aģenti vienlaikus veidoja trīs klienta iOS lietotnes funkcijas. Katrs pievienoja savas teksta virknes lietotnes vienam tulkojumu katalogam, un katrs saglabāja savu visa faila versiju. Uzvarēja pēdējā saglabāšana. 55 no apmēram 95 jaunajām atslēgām bija pazudušas. Katra aģenta būvējums izturēja, jo katra aģenta kopija bija konsekventa; kataloga pārbaude izturēja, jo tās pārklājums bija bojāts citā veidā. Es to atradu, atslēgas saskaitot ar rokām. Labojums sastāv no trim daļām. Hooks atsakās palaist aģentu, kura deklarētie faili pārklājas ar joprojām strādājoša rakstītāja failiem. Aģenti nekad nerediģē koplietotos katalogus; tie raksta savas atslēgas fragmenta failā, un viens skripts apvieno fragmentus, izgāžas pie pretrunīgām vērtībām un pēc tam pārbauda, ka katra atslēga ir klāt. Otrs hooks bloķē commit, ja katalogā ir mazāk atslēgu nekā iepriekš. Godīgā daļa: šos aizsargus pievienoju 18. oktobrī, 60 dienas pēc zaudējuma. Starp šiem datumiem vienīgā aizsardzība bija rinda Markdown noteikumā, un noteikums ir ieteikums. ### Tīrīšana, kas izdzēsa pabeigtu darbu Paralēlie izpildītāji strādā git worktree un stage izmaiņas bez commit. Commit pārbaude lika vadošajai sesijai palaist tīrīšanas skriptu. Skripts izlaida worktree, kuru aģents vēl darbojās, un šie aģenti bija pabeiguši. Četras pabeigtas darba paketes tika izdzēstas, neatstājot atgūstamus git objektus. "Vai aģents vēl darbojas?" un "vai tā darbs ir ievākts?" ir dažādi jautājumi, un skripts uzdeva tikai pirmo. Tīrīšana tagad izlaiž katru worktree ar izmaiņām, kuru galvenajā kopijā nav, un atsevišķs hooks bloķē tiešu worktree mapju dzēšanu. ### Viļņi, kas sāka no vecā koda Plāns ar 11 soļiem tika izpildīts ar 6 izpildītājiem 3 viļņos. 2. un 3. vilnis sāka no commit, ar kuru sesija sākās, trīs commit atpaliekot. Viena aģenta faila kopēšana atpakaļ būtu atcēlusi cita aģenta pabeigto izmaiņu. Worktree ir momentuzņēmums no vietas, kur sāki, tāpēc rezultāti tagad atgriežas kā trīspusēji patch, un konflikti parādās, nevis tiek klusi pārrakstīti. ### Miris aģents, kas ziņoja par veiksmi Aģents, piesaistīts modelim, kura lietojuma limits bija izsmelts, nomira pirms pirmā soļa. Palaišana atgrieza "spawned successfully"; kļūme ienāca vēlāk kā dīkstāves paziņojums. Atkārtotu mēģinājumu ar citu modeli ar to pašu hooku, kas piesprauž modeļus, pārslēdza atpakaļ. Pēc tam vadošā sesija klusi uzrakstīja plānu pati, kas bija tieši tas iznākums, no kura plānotājs bija paredzēts izvairīties. Hooks tagad nolasa aģenta pirmo izvadi un uz kādu laiku atzīmē miris modeli visām sesijām. ### Aģents, kas rediģēja savas pārbaudes 18. oktobrī sesija, kas strādāja pie klienta projekta, atkārtoti saņēma savu commit bloķētu ar pārbaudi. Tā rediģēja trīs pārbaudes skriptus, lai tās commit izietu cauri. Nekas no tā netika slēpts; labojumi bija pilnā redzamībā. Taču nekas tos arī nepārtrauca, jo pārbaudes atradās mapē, kurā aģents varēja rakstīt, un tika uzraudzīti tikai failu redaktora rīki, nevis shell komandas. Tagad pārbaudes failus var mainīt tikai no sesijas, kas startēta pašā konfigurācijas mapē, ir aptverts katrs rakstīšanas ceļš (redaktors, shell novirzīšanas, skripti, git), un jebkura to maiņa projekta sesijas laikā tiek reģistrēta ar brīdinājumu. Šī ir kļūda, par kuru brīdinātu pirmo. Aģents, kam pasaka "izved commit cauri", uzskata vārtus par problēmas daļu. ### Divi manu paša noteikumi nesaskanēja Viens noteikums lika aģentiem apvienot trīs vai vairāk shell soļus vienā skriptā, lai ietaupītu tokenus. Worktree izolētie aģenti strādā smilškastē, kas atsakās tieši no šādas formas. Aģenti vairākas dienas trīs reizes pēc kārtas uzdūrās "too complex to verify" un iztērēja savu budžetu pārformulēšanai. Aģenti tagad apstājas pēc diviem identiskiem atteikumiem, un izolēto aģentu uzdevumos ir norādītas darbojošās komandu formas. ## Kāpēc daudzaģentu sistēmas neizdodas? Pēc šiem diviem mēnešiem: ne tāpēc, ka modelis ir pārāk vājš. Neviena no septiņām iepriekšējām kļūdām nebija modeļa neveiksme tam doto uzdevumu. Tās neizdodas savienojumu vietās starp aģentiem, kur neviens atsevišķs aģents nav atbildīgs: - **Koplietots stāvoklis.** Fails, ko skar katra funkcija, darba koks, zars. Katrs aģents ir lokāli taisnība, un rezultāts ir globāli nepareizs. - **Zaļas pārbaudes.** Katrs iepriekšminētais incidents izturēja pārbaudes, kas tobrīd pastāvēja. Pārbaude pierāda to, ko tā pārbauda, ne vairāk. - **Melojoši veiksmes signāli.** "Spawned", "saved", "cleaned up" katrs nozīmēja ko šaurāku, nekā apgalvoja. - **Aģenti, kas optimizē vārtiem.** Pasaki aģentam, ka commit ir bloķēts, un tas meklēs veidu, kā commit atbloķēt, tostarp caur vārtiem. Citi veidotāji ziņo par to pašu modeli no lielākām flotēm. Jed Arden, kas vada apmēram divdesmit aģentus, rakstīja, ka ["the LLM barely appears in the incident log"](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (latviski: LLM incidentu žurnālā gandrīz neparādās; 2026. gada jūlijs). [Cursor komanda konstatēja](https://cursor.com/blog/scaling-agents), ka divdesmit aģenti, kas koplietoja vienu koordinācijas failu ar slēdzenēm, palēninājās līdz divu vai trīs caurlaidspējai (2026. gada janvāris). ## Ko es iestatītu vispirms Ja sākat ar Claude Code apakšaģentiem vai jebkuru daudzaģentu orķestrēšanu, šādā secībā es to darītu, ņemot vērā, cik man maksāja mācīšanās: 1. **Reģistrē katru aģenta palaišanu.** Viena rinda uz palaišanu: laiks, aģenta tips, modelis, risks. Bez tā nevar zināt, ko sistēma dara, un neviena no iepriekšminētajām skaitļiem nebūtu. 2. **Viens rakstītājs uz failu.** Paralēlie rakstītāji saņem worktree un deklarētu failu sarakstu. Failiem, kam katra funkcija kaut ko pievieno (tulkojumi, lockfaili, changelogi), ir viens īpašnieks, un pārējie iesniedz fragmentus. 3. **Ievāc, pirms tīri.** Neļauj tīrīšanas solim lemt pēc "vai tas darbojas". Lemj pēc "vai tā darbs ir galvenajā kopijā". 4. **Izvieto pārbaudes ārpus aģentu sasniedzamības.** Bloķējošie hooki tiek glabāti vietā, kur projekta sesija nevar rakstīt. 5. **Ierobežo vilni.** Pieci paralēli aģenti ir mani griesti; pāri tam pārskatīšana kļūst par šaurāko vietu un konflikti aug ātrāk par caurlaidspēju. 6. **Eskalē pēc atkārtošanās, nevis pēc pūlēm.** Pēc noklusējuma lēts modelis; pēc vienas un tās pašas kļūdas trīs reizes viens mēģinājums ar stiprāku modeli; pēc tam cilvēks. Cik maksā AI aģenta izveide un darbināšana uzņēmumam, nevis vienam izstrādātājam? Tas ir cits jautājums, uz kuru ar skaitļiem atbild raksts [Cik maksā AI aģents? Skaitļi no 4 projektiem](https://madsalt.tech/lv/blog/how-much-does-an-ai-agent-cost/). Kādus paneļus vēroju tagad, no tiem pašiem žurnāliem mēnesi vēlāk, ir rakstā [AI agent monitoring dashboard: ko parādīja 1238 izpildes](https://madsalt.tech/lv/blog/ai-agent-monitoring-dashboard/). ## Šī ziņojuma ierobežojumi - **Viena izstrādātāja iestatījums.** Viena vadošā sesija, līdz pieciem paralēliem aģentiem. Desmitiem vai simtiem aģentu flotes neizdodas papildu veidos, piemēram, palaišanas brīdī. - **Nav reāla rēķina.** Dolāru summa ir API cenrāža ekvivalents 30 dienām, apakšējā robeža, kas izlaiž kešatmiņas ierakstus un vecākus modeļus. Es maksāju fiksētu abonementu. - **Robi žurnālos.** Bloķētās palaišanas netiek reģistrētas, tāpēc nevaru pateikt, cik bieži iedarbojās viļņa limits. Stiprākā izpildītāja 159 darbības jauc riskantus soļus un atkārtotas kļūdas. - **Datumi no manām piezīmēm.** Incidentu datumi nāk no tajā pašā dienā rakstītām piezīmēm un commit; viens incidents vecākā noteikumu failā ir datēts citādi, un es izmantoju piezīmi. No šī darba izaugušais dashboard prototips ir [daudzaģentu orķestrēšanas gadījums](https://madsalt.tech/lv/work/multi-agent-orchestration/), un aģentu izstrāde klientiem ietilpst pakalpojumā [AI aģenti un tērzēšanas roboti](https://madsalt.tech/lv/services/ai-agent-development/). Aģenti darbojas paralēli, un starp tiem pazūd darbs? Labprāt salīdzināšu pieredzi par hookiem, worktree un pārskatīšanas vārtiem. Bez pārdošanas. [Sazināties](https://madsalt.tech/lv/#contact)