← Späť na blog AI agenti a vývoj

Najprv plán, potom kód: prečo AI agent potrebuje pracovný postup

AI vie napísať kód. Kto však rozhodne, čo má nasledovať? MCP38 pridáva plán práce, kontroly a ohraničené opravné slučky, aby sa výsledok dal overiť.

Pracovný plán spája pamäť, implementáciu, kontrolnú bránu a slučku na opravu
Ilustračný obrázok vytvorený pomocou AI.

Agent môže vedieť napísať kód, opraviť test aj vysvetliť chybu. Stále mu však môže chýbať niečo celkom obyčajné: vedieť, čo má nasledovať. Nové ITHZ-MCP38 presúva časť pozornosti od jednotlivých odpovedí k priebehu celej úlohy.

Predstavte si, že rekonštruujete byt. Elektrikár vie zapojiť zásuvky, maliar namaľovať steny a stolár vyrobiť kuchyňu. Každý je dobrý vo svojom remesle. Ak však maliar príde pred elektrikárom a kuchyňu objednáte pred zameraním, schopnosti jednotlivcov nezachránia poradie práce.

Pri AI vývoji sa podobná situácia skrýva za peknými odpoveďami. Agent upraví súbor. Potom ho požiadame o testy. Tie zlyhajú, preto mu pripomenieme opravu. Neskôr si uvedomíme, že ešte chýba kontrola diffu, dokumentácia alebo overenie v skutočnom prostredí. Stále rozhodujeme, ktorý krok má nasledovať, hoci samotné kroky agent často zvládne.

Odtiaľ vznikla otázka pre ďalšiu verziu ITHZ: čo keby nové zadanie nezačínalo prvou úpravou kódu, ale návrhom spôsobu práce?

Zadanie potrebuje aj cestu k výsledku

„Oprav prihlasovanie“ je cieľ. Ešte však nehovorí, ako preukážeme, že oprava funguje, ktorých súborov sa smieme dotknúť a či máme povolené niečo nasadiť.

MCP38 pridáva plánovanie vývojového workflow. Pri novej netriviálnej úlohe môže agent najprv zostaviť konkrétny postup: implementáciu, kontroly, závislosti, zodpovedné roly, cestu späť pri chybe a podmienky odovzdania. Jednoduchá oprava môže zostať prácou jedného agenta. Väčšia zmena si môže pýtať nezávislého reviewera alebo samostatnú kontrolu rozhrania.

Samotný návrh roly ešte nespúšťa ďalšieho agenta a neprideľuje mu oprávnenia. To zostáva úlohou hostiteľského prostredia v rozsahu zadania. Praktický prínos plánu je inde: ešte pred začiatkom práce vieme pomenovať, čo bude znamenať hotovo.

Slučka má pamätať na dôvod návratu

Rozdiel medzi opravnou slučkou a opakovaním je viditeľný na jednoduchej chybe. Test zistí, že prázdny vstup spôsobí výnimku. Užitočný návrat odovzdá implementátorovi tento konkrétny nález. Nasledujúca zmena musí riešiť prázdny vstup a následná kontrola musí overiť nový obsah.

Opakovať tú istú požiadavku na review, kým nepríde priaznivejší verdikt, by nič neopravilo. Preto nové workflow nadväzuje na existujúce pravidlá MCP37: výsledok patrí ku konkrétnemu diffu a negatívne nálezy sa nestrácajú. Oprava vytvára nový stav; dôkazy závislé od zmeneného obsahu sa musia získať znova.

Slučka zároveň potrebuje koniec. Počet opráv, čas a povolené kontroly majú svoje hranice. Ak sa opakuje ten istý problém alebo chýba potrebné oprávnenie, správnym výsledkom môže byť zrozumiteľné zastavenie s dôvodom. Nekonečná aktivita by bola len drahý spôsob, ako oddialiť priznanie problému.

Zelená kontrolka potrebuje dôkaz

Tvrdenie „testy prešli“ má význam až vtedy, keď vieme, ktoré testy bežali, nad čím, s akým výsledkom a či sa odvtedy niečo nezmenilo. Spustený príkaz, ktorý nenašiel žiadne testy, nepreukazuje správnosť programu. Rovnako ju nepreukazuje test, ktorého podmienku agent oslabil, aby prestal zlyhávať.

MCP38 preto pracuje s kontraktom úlohy a overiteľnými výsledkami kontrol. Kontrakt určuje rozsah, pravidlá a limity. Výsledky sa viažu na konkrétny obsah. Kontroly, ktoré majú chrániť akceptačné podmienky, nemožno potichu zameniť za jednoduchšie. Pri zmene vstupov staré zelené výsledky nestačia.

Ani tak nejde o matematický dôkaz bezchybnosti celého produktu. Testy môžu mať medzery a modelový reviewer sa môže mýliť. Výhodou je, že tieto kroky majú pomenované vstupy a výsledky, ktoré možno skontrolovať, namiesto neurčitého pocitu, že agent už asi skončil.

Menej dohliadania, zachovaná zodpovednosť

Cieľom nie je pýtať sa používateľa pri každom súbore. Ak je oprava v už povolenom rozsahu, pracovný postup môže pokračovať bez ďalšieho potvrdzovania bežných krokov. Keď sa však objaví potreba nového externého prístupu, širšieho zásahu alebo nejasného rozhodnutia, plán to nemôže schovať.

Na konci má vzniknúť balík na posúdenie: čo sa zmenilo, ktoré podmienky sú splnené, aké dôkazy máme, čo zostáva neisté a aká presná akcia má nasledovať. Pripravená zmena nie je to isté ako vykonané nasadenie.

Prvá verzia koordinátora preto končí pripraveným výsledkom. Sama neposkytuje všeobecné oprávnenie na merge, publikovanie alebo produkčné nasadenie. Na také akcie treba príslušný nástroj a platné oprávnenie. Rozumná autonómia sa prejaví aj tým, že systém vie, kde sa jeho úloha končí.

Čo zostáva v pamäti

Predchádzajúce verzie ITHZ riešili najmä to, ako agentovi odovzdať relevantné rozhodnutia, pravidlá, riziká a dôkazy. MCP38 k tomu pridáva stav práce: kde sme, čo zlyhalo a čo je dovolený ďalší krok.

Živý stav behu je oddelený od sledovaného zdrojového kódu. Hostiteľ môže do projektovej pamäte uložiť stručný, sanitizovaný súhrn s odkazmi na výsledky. Po prerušení sa najprv overí, či prostredie stále zodpovedá uloženému stavu. Nejasný výsledok akcie nie je dôvod ju bez rozmýšľania zopakovať.

Takto môže ďalšie pokračovanie vychádzať z toho, čo sa skutočne stalo, nie iba z poslednej optimistickej správy v chate.

Čo nová verzia zatiaľ nesľubuje

MCP38 je alfa verzia koordinátora. Model za nás ďalej neposkytuje sám MCP server: implementáciu vykonáva hostiteľský agent a prvá vykonávacia šablóna je sekvenčná. Graf v pláne pomenúva závislosti a možné roly; nie je prísľubom automatického spustenia desiatok agentov na pozadí.

Lokálne kontroly bežia s oprávneniami hostiteľa. Koordinátor nenahrádza operačný sandbox, nezávislú správu oprávnení ani ľudské rozhodovanie. Testovacie výsledky uvedené pri vydaní overujú konkrétne správanie softvéru; nepreukazujú všeobecnú úsporu času, peňazí alebo vyššiu kvalitu AI.

Na tie otázky treba porovnávať skutočné úlohy: počet potrebných zásahov, uniknuté chyby, čas aj cenu. Menej otázok používateľovi má hodnotu iba vtedy, ak výsledok zostane overiteľný.

Ďalší krok ITHZ

Pamäť pomáha agentovi vedieť, čo už projekt pozná. Workflow mu pomáha vedieť, čo treba urobiť teraz a čo musí nasledovať pred odovzdaním. Obe vrstvy majú zmysel práve v spojení: každá oprava môže nadviazať na konkrétny nález a každý úspech musí mať jasný rozsah.

Nová verzia vznikla z praktickej potreby prestať ručne spájať každý drobný krok. Nevyžaduje vieru v neomylného agenta. Vyžaduje pracovný postup, v ktorom sa chyba môže prejaviť, opraviť alebo poctivo zastaviť.

Pozrieť ITHZ MCP · Stiahnuť aktuálnu verziu · Poznámky k vydaniu MCP38

Súvisiace čítanie: workflow a agentné vzory v dokumentácii LangGraph. Táto referencia vysvetľuje všeobecný vzor; MCP38 používa vlastný deterministický koordinátor.

Reakcia

Ako na vás úvaha pôsobila?

Krátka reakcia mi príde e-mailom. Ak chcete rozvinúť myšlienku verejne, pridajte komentár nižšie.

Diskusia

Komentáre sa zobrazia až po schválení autorom. Pri každom novom komentári príde moderátorovi e-mail.

Zatiaľ tu nie je žiadny schválený komentár.

Pridať komentár

Váš e-mail sa nezverejní. Komentár sa zobrazí až po schválení.