Koordinace více AI agentů bez kolizí a ztraceného kontextu

Koordinátor, pracovníci a sdílená paměť

Více AI relací zvládne více práce než jedna. Bez pravidel však začnou rychle narážet na sebe: dva agenti otevřou stejný soubor, jeden přepíše změnu druhého a další převezme úkol bez klíčového kontextu.

Koordinace proto nezačíná spuštěním více chatů. Musí rozdělit práci, vymezit vlastnictví souborů a průběžně sdílet stav.

Komunitní praxe staví na jasných rolích:

• Koordinátor rozdělí repozitář na nezávislé úkoly, přidělí je pracovníkům a hlídá průběh.
• Pracovníci dostávají jeden jasný scope, nikoli společný velký backlog.
• Sdílená paměť uchovává plány, rozhodnutí a know-how projektu.

Několik lidí ve skupině kombinuje wiki nebo Obsidian jako sdílené úložiště, kam ukládá plány i know-how jednotlivých projektů. Jiní nechávají agenty komunikovat přímo přes zprávy a rozdělovat commity.

Toto je orchestrace s frontou a sdíleným stavem. Každý úkol potřebuje vlastníka, stav, jednoznačný výstup a informaci, kdo právě pracuje na kterých souborech.

Projektové instrukce typu CLAUDE.md řeší opakovanou část: pravidla repozitáře a pokyny k testům, typechecku či lintu. Jsou základem, ale samy o sobě nevyřeší souběžné zápisy ani předání rozpracované úlohy.

Izolace změn: worktree, claim a merge

Nejpřenositelnější trik z diskuse je dát každému agentovi vlastní Git worktree: samostatný adresář a větev pro jednu úlohu nebo user story. Agent tak nemusí sdílet checkout s ostatními a nevidí cizí necommitnuté změny. Merge se řeší až po dokončení práce.

Druhým krokem je claim-before-edit: agent si před zápisem označí práci jako rozpracovanou a uvede, kterých souborů se dotkne. Ostatní agenti tyto soubory nechají být.

Diskuse přiznává, že jde zatím spíš o dohodu než o technický zámek. Když dva agenti upraví různé části téhož souboru, může merge projít bez chyby, přestože výsledek poruší API.

Jak postupovat v praxi

1. Rozdělte úkoly podle souborů nebo modulů. Slovní popis úkolu nestačí.
2. Jednoduché úkoly s jedním vlastníkem zpracujte paralelně.
3. Každému agentovi vytvořte vlastní Git worktree.
4. Před prvním zápisem označte úkol jako claimnutý a uveďte dotčené soubory.
5. Společná rozhraní upravujte v jedné větvi a pod lidskou kontrolou.
6. Po dokončení sloučte změny a zkontrolujte výsledek.

Tím oddělíte práci na souborech od práce na návrhu rozhraní. Claim chrání jednotlivé části repozitáře, ale sám o sobě nezaručuje, že dva merge zachovají smysl změny.

Předání kontextu jako malý artefakt

Po vyčerpání limitu nástroje se práce často předává jinému agentovi. Spolehlivější než odkaz na starší chat nebo obrovský výpis z diskuse je malý handoff dokument.

Měl by obsahovat:

• cíl úkolu a rozsah změn;
• přijatá rozhodnutí a jejich důvod;
• otevřené otázky a rizika;
• seznam změněných souborů;
• dokončené kroky a výsledky ověření;
• přesný další krok a podmínky dokončení.

Takový záznam může doplnit průběžný soubor hot.md nebo wiki. Nový agent si z něj přečte stav a v repozitáři ověří skutečný stav větve.

Handoff aktualizujte po každém dokončeném kroku, ne až na konci. Dokument tak slouží jako živý přenos stavu, ne jako závěrečná zpráva pro archiv.

Handoff ale není přesná kopie myšlení původního agenta. Shrnutí ztrácí nuance a nový pracovník může zvolit jiný plán. Strukturovaný záznam proto musí uvádět rozhodnutí i jejich důvody. Odkazujte také na konkrétní testy, commity nebo review.

Jak to funguje pod kapotou a kde má postup limity

Každá relace má vlastní kontextové okno. Bez sdíleného úložiště se znalosti mezi agenty přenášejí jen prostřednictvím textu, který musí druhý agent znovu pochopit. Dlouhá wiki navíc není totéž jako relevantní kontext: omezení uprostřed výpisu může model přehlédnout, protože pozornost upřednostňuje začátek a konec okna.

Git navíc slučuje řádky, nikoli záměr. Dva „čisté“ merge mohou sémanticky rozbít rozhraní API. Worktree a claim tedy snižují riziko, ale neodstraňují ho. Audit upozorňuje také na chybějící optimistickou kontrolu: zápis má být platný jen tehdy, pokud se cílový soubor od doby čtení nezměnil.

Tmux řeší jiné problémy. Umožňuje hierarchii panelů a přehled relací, ale není frontou, zámkem ani sdílenou pamětí. Stejně tak GitHub issue nebo PR poskytují nástěnku, nikoli spolehlivý stavový model pro práci agentů.

Protiváhu k ručnímu přepínání panelů představuje orchestrátor nad agenty s rolemi, rozpočtem, stavem a logem. Pro jednotlivé paralelní úlohy je alternativou agent teams, kde hlavní agent řídí dílčí agenty uvnitř jedné relace. Ti však získávají projektový kontext, nikoli automaticky celou historii vedení.

Co si z toho vzít

• Koordinátor rozděluje úkoly podle vlastnictví souborů a jasného scope.
• Každý paralelní agent pracuje ve vlastním worktree.
• Práce se označuje jako claimnutá ještě před prvním zápisem.
• Handoff je krátký strukturovaný dokument, ne přepis konverzace.
• Wiki slouží jako zdroj znalostí; stav práce patří do fronty nebo stavového systému.
• CLAUDE.md definuje pravidla projektu, ale neřeší izolaci ani předání.
• Merge je třeba chápat jako sloučení řádků, takže změny rozhraní vyžadují kontrolu.
• U většího provozu je orchestrátor se stavem a logem přesnější než samotný tmux.
• Další krok tématu rozšiřuje AI agenti a jejich provozní nástroje.