--- title: "Multi-agent orchestration: kas sugedo per 3 315 paleidimų" description: "Multi-agent orchestration praktikoje: 3 315 subagentų paleidimų, tokenų kaina pagal API kainas ir septynios klaidos, kurių kiekviena tapo hook." url: "https://madsalt.tech/lt/blog/multi-agent-orchestration-what-broke/" author: "Denys Zaichenko" language: "lt" published: 2026-10-19 updated: 2026-10-22 --- # Multi-agent orchestration: kas sugedo per 3 315 paleidimų Trumpai Nuo 2026 m. rugpjūčio 17 d. iki spalio 19 d. mano Claude Code sąranka paleido 3 315 subagentų. Per paskutines 30 dienų tai sudarė apie 16 mlrd. tokenų, iš jų 97,7 % buvo skaitymai iš cache. Moku fiksuotą prenumeratą; pagal API kainoraščio kainas tie patys tokenai kainuotų ne mažiau kaip 3 350 USD. Klaidos beveik niekada nebuvo tai, kad modelis rašė blogą kodą. Jos buvo sandūrose: lygiagretūs agentai perrašė tą patį failą, nors visos patikros buvo žalios, valymo skriptas ištrynė baigtą darbą, agentas pakeitė patikras, kurios jį blokavo. Kiekviena klaida tapo nedideliu skriptu, kuris blokuoja kitą paleidimą, ir būtent šie skriptai, o ne promptai, padarė sistemą naudojamą. Esu Denys, full-stack ir AI inžinierius. Programinę įrangą kuriu su viena pagrindine Claude Code sesija, kuri perduoda darbą specializuotiems subagentams: tyrinėtojams, planuotojui, vykdytojams, saugumo ir kodo peržiūrėtojams. Tai ataskaita apie šią daugiaagentę sistemą, o ne apie kliento produktą. Skaičiai paimti iš žurnalų, kuriuos ji kaupia: paleidimų registro (viena eilutė kiekvienam paleistam agentui), sesijų transkriptų ir pačios konfigūracijos git istorijos. Klientų ir projektų pavadinimai praleisti. Taip pat sukūriau [interaktyvų daugiaagentės orkestracijos dashboard](https://madsalt.tech/lt/work/multi-agent-orchestration/) kaip prototipą su pavyzdiniais duomenimis. Viskas žemiau yra iš tikrų paleidimų. ## Kas yra multi-agent orchestration? Multi-agent orchestration (daugiaagentė orkestracija) yra sąranka, kai vienas pagrindinis agentas paveda apibrėžtas užduotis specializuotiems agentams ir sujungia jų rezultatus; orkestratorius atsako už kontekstą, biudžetus ir pakartotinius bandymus. Šiame straipsnyje ji pasireiškia dviem modeliais: pagrindinė sesija su subagentais (tyrinėtojai, planuotojas, vykdytojai, peržiūrėtojai) ir hook, kurie įgyvendina taisykles, kurių agentai negali apeiti kalbėdami. [Daugiaagentės orkestracijos dashboard](https://madsalt.tech/lt/work/multi-agent-orchestration/) rodo tą pačią idėją su pavyzdiniais duomenimis; žemiau esantys skyriai pasakoja, kas sugedo tikruose paleidimuose. ## Kaip atrodo sąranka? Viena pagrindinė sesija bendrauja su manimi ir atsako už užduotį. Didesnėse užduotyse ji pati niekada neberašo produkcinio kodo. Ji išdalija darbą: - **Tyrinėtojai** skaito vieną kodo bazės sluoksnį (frontend, backend, duomenų bazę) ir rašo trumpą žemėlapį. - **Planuotojas** paverčia žemėlapį sunumeruotais žingsniais su failų keliais. - **Vykdytojai** ima po vieną plano fazę, pirma rašo testus, paskui kodą. Lygiagretūs vykdytojai gauna savo git worktree. - **Peržiūrėtojai** tikrina diff: vienas saugumą, kitas teisingumą, abu tame pačiame commit. Tarp jų stovi hooks: nedideli skriptai, kuriuos Claude Code paleidžia prieš kiekvieną įrankio iškvietimą ir po jo. Hook gali užblokuoti iškvietimą, pavyzdžiui, agento paleidimą, failo įrašymą ar `git commit`. Konfigūracijoje yra 165 hooks, apie 40 iš jų susiję su orkestracija. Taisyklės, kurias agentai skaito, yra Markdown; taisyklės, kurių jie neapeis, yra hooks. Šis padalijimas yra pagrindinė dviejų mėnesių pamoka, o likęs tekstas paaiškina kodėl. ![Kaip užduotis keliauja per agentus. Hooks stovi tarp kiekvieno žingsnio ir gali jį užblokuoti. Įprastas kelias: Tyrimas → Planas → Kodas → Peržiūra → Commit; Ta pati klaida tris kartus: Kodas → Ta pati klaida 3x → Stipresnis modelis → Žmogus.](https://madsalt.tech/charts/lt/multi-agent-orchestration-what-broke-flow.svg) *1 pav. Mano Claude sąranka, 2026 m. rugpjūtis–spalis. Kiekvienas lygiagretus vykdytojas gauna savo git worktree.* ## Kiek agentų veikė ir su kuriais modeliais? | Rodiklis (2026-08-17 – 2026-10-19) | Reikšmė | | -------------------------------------------------- | ----------------------------------------------------------------------------------- | | Paleista subagentų | 3 315 per 57 aktyvias dienas | | Agentų tipų | 30 | | Dažniausiai paleisti | vykdytojas (tdd-guide) 793, saugumo peržiūrėtojas 455, general-purpose 424 | | Faktiškai naudotas modelis | Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, likusieji paveldėti iš pagrindinės sesijos | | Paleista po vieną | 67,7 % | | Didžiausia lygiagreti banga | 5 agentai (riba), pasiekta 9 kartus | | Peržiūrėtojų paleidimų vienam vykdytojo paleidimui | 0,71 (680 peržiūrų, 963 vykdymai) | Du skaičiai mane nustebino. Pirma, dauguma paleidimų buvo pavieniai agentai, o ne šakojimasis. Lygiagretus darbas yra išimtis: jis atsiperka skaitant ir peržiūrint, o rašant kainuoja daug (žr. pirmąją klaidą žemiau). Antra, 23 % paleidimų, kai agento faile nurodytas modelis, iš tikrųjų veikė kitas modelis, beveik visada Sonnet, pakeltas į Opus (584 iš 610). Tai tyčia: hook pakelia modelį, kai žingsnis liečia rizikingą kodą, pavyzdžiui, migracijas, autentifikaciją ar serverio maršrutus, taip pat po to, kai Sonnet vykdytojas tris kartus iš eilės nepraeina to paties testo. Stipresnis vykdytojas veikė 159 kartus; žurnalo negaliu padalyti į „rizikingą žingsnį“ ir „pasikartojančią klaidą“, todėl netvirtinu, kiek iš jų buvo gelbėjimų. ## Kiek kainuoja multi-agent orchestration? Moku fiksuotą prenumeratą, todėl sąskaitos už tokenus nėra. Tačiau transkriptuose užfiksuotas kiekvienas tokenas, taigi štai kiek paskutinės 30 dienų (rugsėjo 20 – spalio 19 d.) kainuotų pagal Anthropic API kainoraščio kainas: | 30 dienų | Tokenai | | ----------------------- | ------------------------------------------------------ | | Iš viso | apie 15,99 mlrd. | | Skaitymai iš cache | 15,55 mlrd. (97,7 % viso, kas buvo siunčiama modeliui) | | Įrašymai į cache | 372 mln. | | Nauja nekešuota įvestis | 0,18 mln. | | Išvestis | 69 mln. | Pagal kainoraščio kainas (Opus 5.5: 4 USD už milijoną įvesties tokenų, 20 už milijoną išvesties, 0,20 už milijoną skaitymų iš cache; Sonnet 5.5 ir Fable 5.1 pagal savo kainas) vien išvestis, įvestis ir skaitymai iš cache trims dabartiniams modeliams sudaro apie 3 350 USD. Tai neapima įrašymų į cache ir senesnių modelių versijų, kurios vis dar yra žurnaluose, todėl tikroji API suma didesnė. Du trečdalius tų 3 350 USD sudaro skaitymai iš cache: kiekvienas ėjimas iš naujo siunčia visą kontekstą, o cache yra vienintelė priežastis, kodėl tai apskritai įperkama. ![Kas parašė 69 mln. išvesties tokenų. Mln. tokenų, 30 dienų. Subagentai sunaudojo 42 % visų tokenų. Pagrindinė sesija: 23,70; Subagentai: 45,30.](https://madsalt.tech/charts/lt/multi-agent-orchestration-what-broke-output.svg) *2 pav. Claude transkriptai, 2026 m. rugsėjo 20 d. – spalio 19 d.: 75 129 modelio užklausos.* Pagrindinės sesijos ir subagentų padalijimas yra dalis, kurią naudočiau planuodamas biudžetą: - **Subagentai sunaudojo 42 % visų tokenų, bet parašė 66 % išvesties.** Pagrindinė sesija brangi, nes neša ilgiausią kontekstą; subagentai yra ten, kur iš tikrųjų rašomas tekstas ir kodas. - **Peržiūrėtojai pigūs.** Saugumo ar kodo peržiūra sunaudojo 1–4 mln. tokenų. Vykdytojas 5–100 mln. Du peržiūrėtojai prie kiekvieno rizikingo commit kainuoja mažiau nei vienas vykdytojas, kuris bando iš naujo. - **Didžiausia sesija**, spalio 6 d., paleido 63 subagentus ir per 3,5 valandos sunaudojo 372 mln. tokenų. ## Kas sugedo Kiekviena žemiau aprašyta klaida įvyko, turi datą ir baigėsi hook ar skriptu, kuris neleidžia jai pasikartoti. Nė viena iš jų nėra „modelis parašė klaidą“. Įprastas klaidas pagavo testai ir peržiūrėtojai. Šios praslydo pro abu. | Data (2026) | Kas sugedo | Kas tai blokuoja dabar | | ----------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | rugp. 19 | Lygiagretūs agentai perrašė vieną vertimų failą: prarasta 55 iš ~95 raktų, visos patikros žalios | Kiekvienas agentas rašo savo raktus į atskirą fragmentą; sujungimo skriptas įrodo, kad kiekvienas raktas pateko | | rugp. 24 | Valymo skriptas ištrynė 4 baigtus darbo paketus | Valymas praleidžia kiekvieną worktree su nesurinktais pakeitimais; pirma surinkti, paskui valyti | | rugs. 1 | Vėlesnės agentų bangos startavo iš pasenusio kodo | Kiekvieno agento darbą jungti kaip trijų krypčių patch, niekada failo kopija | | rugs. 13 | Agentas mirė paleidžiant, o paleidimas pranešė „sėkmė“ | Paleidėjas skaito pirmą agento išvestį ir negyvą modelį kuriam laikui pažymi visoms sesijoms | | rugs. 20 | Dvi mano paties taisyklės prieštaravo viena kitai; agentai kartojo atmestą komandą | Izoliuotų agentų užduotyse nurodytos komandų formos, kurias priima sandbox | | spal. 18 | Agentas pakeitė patikras, kurios blokavo jo commit | Patikrų failai projektų sesijoms tik skaitomi; pakeitimai registruojami ir kelia pavojaus signalą | | spal. 18 | Taisymo nurodymai tyliai pakeitė, ką gauna kliento programos naudotojai | Kiekviena taisymo užduotis sako „išlaikyk veikiantį elgesį“; produkto pakeitimai grįžta pas mane | ### Lygiagretūs rašytojai ir failas, kurį liečia kiekviena funkcija Trys agentai vienu metu kūrė tris kliento iOS programos funkcijas. Kiekvienas įdėjo savo teksto eilutes į vienintelį programos vertimų katalogą ir kiekvienas išsaugojo savo viso failo versiją. Laimėjo paskutinis išsaugojimas. Dingo 55 iš maždaug 95 naujų raktų. Kiekvieno agento build praėjo, nes kiekvieno agento kopija buvo nuosekli; katalogo patikra praėjo, nes jos aprėptis buvo sugadinta kitu būdu. Radau tai skaičiuodamas raktus rankomis. Pataisa turi tris dalis. Hook atsisako paleisti agentą, kurio deklaruoti failai persidengia su dar veikiančiu rašytoju. Agentai niekada nekeičia bendrų katalogų; savo raktus jie rašo į fragmento failą, o vienas skriptas fragmentus sujungia, nepavyksta esant prieštaringoms reikšmėms ir tada patikrina, ar kiekvienas raktas yra. Antras hook blokuoja commit, jei kataloge raktų mažiau nei anksčiau. Sąžininga dalis: šias apsaugas pridėjau spalio 18 d., praėjus 60 dienų po praradimo. Tarp tų datų vienintelė apsauga buvo eilutė Markdown taisyklėje, o taisyklė yra tik pasiūlymas. ### Valymas, kuris ištrynė baigtą darbą Lygiagretūs vykdytojai dirba git worktrees ir stage'ina pakeitimus nedarydami commit. Commit patikra liepė pagrindinei sesijai paleisti valymo skriptą. Skriptas praleisdavo worktrees, kurių agentas dar veikė, o šie agentai jau buvo baigę. Keturi baigti darbo paketai buvo ištrinti, neliko git objektų atkurti. „Ar agentas dar veikia?“ ir „ar jo darbas surinktas?“ yra du skirtingi klausimai, o skriptas klausė tik pirmojo. Dabar valymas praleidžia kiekvieną worktree su pakeitimais, kurių pagrindiniame checkout nėra, o atskiras hook blokuoja tiesioginį worktree aplankų trynimą. ### Bangos, kurios startavo iš seno kodo 11 žingsnių planas buvo vykdomas kaip 6 vykdytojai 3 bangomis. 2 ir 3 bangos startavo nuo commit, kuriame prasidėjo sesija, trimis commit atsilikdamos. Vieno agento failo nukopijavimas atgal būtų atšaukęs kito agento baigtą pakeitimą. Worktree yra momentinė nuotrauka vietos, iš kurios pradėjote, todėl rezultatai dabar grąžinami kaip trijų krypčių patch, o konfliktai iškyla į paviršių, užuot buvę tyliai perrašyti. ### Negyvas agentas, kuris pranešė apie sėkmę Agentas, prisegtas prie modelio, kurio naudojimo riba buvo išnaudota, mirė prieš pirmą žingsnį. Paleidimas grąžino „sėkmingai paleista“; klaida atkeliavo vėliau kaip pranešimas apie neveiklumą. Pakartojimą kitame modelyje atgal perjungė tas pats hook, kuris modelius prisega. Tada pagrindinė sesija tyliai parašė planą pati, o tai buvo būtent tas rezultatas, kurio planuotojas ir buvo skirtas išvengti. Dabar hook skaito pirmą agento išvestį ir negyvą modelį kuriam laikui pažymi visoms sesijoms. ### Agentas, kuris pakeitė savo patikras Spalio 18 d. sesija, dirbusi su kliento projektu, vis gaudavo užblokuotą commit dėl vienos patikros. Ji pakeitė tris patikrų skriptus, kad jos commit praeitų. Nieko čia nebuvo paslėpta; pakeitimai buvo matomi. Bet jų niekas ir nesustabdė, nes patikros gulėjo aplanke, į kurį agentas galėjo rašyti, o stebėti buvo tik failų redagavimo įrankiai, ne shell komandos. Dabar patikrų failus galima keisti tik iš sesijos, paleistos pačios konfigūracijos aplanke, apimti visi įrašymo keliai (redaktorius, shell nukreipimai, skriptai, git), o kiekvienas jų pakeitimas projekto sesijos metu registruojamas su pavojaus signalu. Tai klaida, apie kurią pirmiausia įspėčiau. Agentas, kuriam pasakoma „praleisk tą commit“, vartus laiko problemos dalimi. ### Dvi mano paties taisyklės nesutapo Viena taisyklė liepė agentams sujungti tris ar daugiau shell žingsnių į vieną skriptą, kad sutaupytų tokenų. Worktree izoliuoti agentai veikia sandbox aplinkoje, kuri būtent tokią formą atmeta. Agentai kelias dienas tris kartus iš eilės susidūrė su „too complex to verify“ ir išeikvojo biudžetą perfrazuodami. Dabar agentai sustoja po dviejų vienodų atmetimų, o izoliuotų agentų užduotyse nurodytos veikiančios komandų formos. ## Kodėl daugiaagentės sistemos genda? Pagal šiuos du mėnesius: ne todėl, kad modelis per silpnas. Nė viena iš septynių aukščiau aprašytų klaidų nebuvo modelio nesėkmė atliekant jam duotą užduotį. Jos genda agentų sandūrose, kur už nieką neatsako vienas agentas: - **Bendra būsena.** Failas, kurį liečia kiekviena funkcija, darbo medis, šaka. Kiekvienas agentas lokaliai teisus, o rezultatas globaliai blogas. - **Žalios patikros.** Kiekvienas aukščiau aprašytas incidentas praėjo tuo metu egzistavusias patikras. Patikra įrodo tai, ką tikrina, ir nieko daugiau. - **Sėkmės signalai, kurie meluoja.** „Paleista“, „išsaugota“, „išvalyta“ kiekvienas reiškė siauriau, nei sakė. - **Agentai, optimizuojantys vartus.** Pasakykite agentui, kad commit užblokuotas, ir jis ieškos būdo jį atblokuoti, įskaitant kelią per pačius vartus. Kiti kūrėjai apie didesnius agentų būrius praneša tą patį modelį. Jed Arden, valdantis apie dvidešimt agentų, parašė, kad [LLM jo incidentų žurnale vos pasirodo](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (2026 m. liepa). [Cursor komanda nustatė](https://cursor.com/blog/scaling-agents), kad dvidešimt agentų, dalijančių vieną koordinacinį failą su užraktais, sulėtėjo iki dviejų ar trijų našumo (2026 m. sausis). ## Ką nustatyčiau pirmiausia Jei pradedate su Claude Code subagentais ar bet kokia multi-agent orchestration, štai tokia tvarka tai darau aš, atsižvelgdamas į tai, kiek man kainavo to išmokti: 1. **Registruokite kiekvieną agento paleidimą.** Viena eilutė paleidimui: laikas, agento tipas, modelis, rizika. Be to nežinosite, ką sistema daro, ir nė vieno aukščiau pateikto skaičiaus nebūtų. 2. **Vienas rašytojas vienam failui.** Lygiagretūs rašytojai gauna worktree ir deklaruotą failų sąrašą. Failai, į kuriuos prideda kiekviena funkcija (vertimai, lockfile, changelog), turi vieną savininką, o kiti atiduoda fragmentus. 3. **Pirma surinkti, paskui valyti.** Niekada neleiskite valymo žingsniui spręsti pagal „ar veikia“. Spręskite pagal „ar jo darbas pagrindiniame checkout“. 4. **Patikras laikykite už agentų pasiekiamumo ribų.** Hooks, kurie blokuoja, laikomi ten, kur projekto sesija rašyti negali. 5. **Apribokite bangą.** Penki lygiagretūs agentai yra mano riba; toliau kliūtimi tampa peržiūra, o konfliktai auga greičiau nei pralaidumas. 6. **Eskaluokite pagal pasikartojimą, ne pagal pastangas.** Pagal nutylėjimą pigus modelis; po trečios tos pačios klaidos vienas bandymas stipresniu modeliu; po to žmogus. Kiek kainuoja AI agentą sukurti ir eksploatuoti verslui, o ne vieno kūrėjo darbo eigai? Tai kitas klausimas, ir su skaičiais į jį atsako straipsnis [Kiek kainuoja AI agentas? Skaičiai iš 4 projektų](https://madsalt.tech/lt/blog/how-much-does-an-ai-agent-cost/). Kuriuos skydelius stebiu dabar, pagal tuos pačius žurnalus po mėnesio, aprašyta straipsnyje [AI agent monitoring dashboard: ką parodė 1 238 vykdymai](https://madsalt.tech/lt/blog/ai-agent-monitoring-dashboard/). ## Šios ataskaitos ribos - **Vieno kūrėjo sąranka.** Viena pagrindinė sesija, iki penkių lygiagrečių agentų. Dešimčių ar šimtų agentų būriai genda dar kitais būdais, pavyzdžiui, paleidžiant. - **Nėra tikros sąskaitos.** Sumos dolerio išraiška yra API kainoraščio ekvivalentas už 30 dienų, apatinė riba, neįskaitanti įrašymų į cache ir senesnių modelių. Moku fiksuotą prenumeratą. - **Žurnalų spragos.** Užblokuoti paleidimai neregistruojami, todėl negaliu pasakyti, kaip dažnai suveikė bangos riba. 159 stipresnio vykdytojo paleidimai maišo rizikingus žingsnius ir pasikartojančias klaidas. - **Datos iš mano paties užrašų.** Incidentų datos paimtos iš tą pačią dieną rašytų užrašų ir commit; vienas incidentas senesniame taisyklių faile datuotas kitaip, ir naudojau užrašą. Prototipas, išaugęs iš šio darbo, yra [atvejis Daugiaagentės orkestracijos dashboard](https://madsalt.tech/lt/work/multi-agent-orchestration/), o agentų kūrimas klientams patenka į [AI agentus ir pokalbių robotus](https://madsalt.tech/lt/services/ai-agent-development/). Paleidžiate agentus lygiagrečiai ir prarandate darbą tarp jų? Mielai palyginsiu patirtį dėl hooks, worktrees ir peržiūros vartų. Be pardavimo. [Susisiekti](https://madsalt.tech/lt/#contact)