TIP#3328: Víc AI agentů nad jedním projektem? Pozor na jejich „paměť“ a na paralelní práci

Jedna session skončí, později otevřete jinou a čekáte, že prostě naváže. Jenže nový nebo obnovený AI agent může vycházet ze starého kontextu a vůbec nemusí vědět, co se v projektu mezitím změnilo.

POZNÁMKA: Další velmi praktická věc, kde jsem si sám samozřejmě naběhl a následně to řešil s Claude a pak pomocí „skill“ v ChatGPT přeměnil v tento tip. Střídám totiž Codex i Code prakticky neustále. Většina mých „živých“ věcí je vyvíjena postupně v obou, podle toho kde zrovna aje k dispozici čas a nevypršel limit. A celé to má pár důležitých pravidel a omezení.

A pak existuje ještě druhá, podstatně divočejší situace: dva nebo více agentů pracují nad stejným projektem opravdu současně. Tam už nejde jen o zastaralou „paměť“. Mohou si přímo zasahovat do souborů.

Jsou to dva různé problémy a je dobré je nemíchat.

TIP: S tím úzce souvisí Střídáte Codex a Claude Code nad jedním projektem? Pozor, každý může číst jiné instrukce. Tam je problém v tom, že různé nástroje nemusí číst stejný AGENTS.md, CLAUDE.md nebo jiný instrukční soubor. Tady jde o něco jiného: aktuální stav projektu proti tomu, co má konkrétní session ve svém kontextu.

Nejčastější případ: jednotlivé session se střídají

Tohle bude nejspíš běžnější scénář.

Claude Code něco udělá, session skončí. Později otevřete jinou session, vrátíte se ke starší nebo projekt převezme Codex. Mezitím jste mohli něco změnit sami nebo na projektu pracovala jiná AI.

Jenže kontext session není živá kopie projektu.

Claude Code například popisuje, že kontext session postupně obsahuje historii konverzace, přečtené soubory, výsledky příkazů a další informace získané při práci.

Pokud agent před hodinou přečetl functions.php, má ve svém kontextu informace o tehdejším obsahu. Když mezitím někdo tento soubor změní, starší část kontextu se tím automaticky nepřepíše.

Agent může mít v hlavě například:

funkce ještě neexistuje
test stále selhává
určitý soubor obsahuje původní kód
automatizace skončila u položky číslo 137
poslední commit byl nějaký konkrétní commit

To všechno mohlo být pravda v okamžiku, kdy si to zjistil.

Historie konverzace říká, co agent věděl tehdy. Soubory a Git říkají, jak projekt vypadá teď.

Před pokračováním nejdřív zjistit skutečný stav

Proto je dobré agenta naučit, aby při novém úkolu nebo po návratu ke starší session nejdřív zkontroloval současný stav projektu.

Základ může být:

git status --short
git diff HEAD
git log --oneline -5

git status ukáže změněné, připravené a nesledované soubory, git diff aktuální rozdíly a git log poslední commity.

Pak má smysl znovu přečíst soubory, kterých se právě řešený úkol týká.

Nemusí kvůli tomu agent při každém dotazu analyzovat celý repozitář. Podstatné je, aby při pokračování v práci nespoléhal na starý obsah souborů jen proto, že je už jednou v této konverzaci viděl.

Dejte to rovnou do AGENTS.md nebo CLAUDE.md

Kontrola aktuálního stavu může být součástí trvalých instrukcí projektu.

Například:

Before starting or resuming a task, inspect the current repository state.
Check git status, git diff against HEAD and recent commits, then re-read
the relevant files. Treat the current working tree as the source of truth
for repository state; do not rely on earlier conversation context.

Nebo trochu důraznější varianta:

## Repository state

- At the start of a new task or after resuming a session, inspect the current
  Git status and recent changes before editing files.
- Re-read relevant files instead of relying on their earlier contents in the
  conversation.
- Never assume that another agent or session has not changed the working tree.
- Do not overwrite or discard changes you did not create without investigating
  them first.

U Claude Code lze kontrolu ještě více automatizovat přes SessionStart hook. Anthropic mezi příklady použití uvádí právě přidání aktuálního kontextu projektu při startu nebo obnovení session.

Pro běžný projekt to není nutnost. Pravidlo v CLAUDE.md nebo AGENTS.md většinou stačí.

Git se stává společnou pamětí projektu

Pokud se na projektu střídá více session nebo různých AI nástrojů, Git přestává být jen místo, kam jednou za čas uložíte hotový výsledek.

Další agent z něj může zjistit:

co už bylo dokončeno
co se změnilo
jak vypadaly poslední kroky
jestli v pracovní složce zůstaly necommitnuté změny
proti jakému stavu má pokračovat

Proto dávají při agentním vývoji smysl menší a častější commity. Další session pak nemusí z historie chatu hádat, co předchozí agent vlastně udělal.

Pokud se projekt mění také na vzdáleném repozitáři, hodí se nejdřív zjistit, zda tam nepřibyly další změny. git fetchstáhne nové informace o vzdálených branchech, aniž by je automaticky slučoval do právě používané branche.

Git ale neobsahuje všechno

Ne každý stav práce patří do commitů.

Typickým příkladem je dlouhá automatizace, která zpracovává stovky nebo tisíce položek a musí vědět, kde naposledy skončila.

U jedné své WordPress automatizace používám progress.json. Když práci převezme další session, nepotřebuje se spoléhat na předchozí konverzaci. Ze stavového souboru zjistí, kde pokračovat.

Princip může vypadat třeba takto:

{
  "last_completed_step": 137,
  "next_step": 138,
  "status": "running",
  "updated_at": "2026-08-26T18:30:00+02:00"
}

Nemusí to být právě progress.json. Může jít o Markdown, JSONL, databázový záznam, GitHub issue nebo jiný stav uložený mimo konkrétní chat.

Důležitý je princip:

Informace nutná k pokračování práce nesmí existovat pouze v paměti jedné session.

To pomáhá i ve chvíli, kdy session skončí, dojde ke zkrácení kontextu nebo práci převezme úplně jiný AI nástroj.

Obnovení session není obnovení starého projektu

Tohle je snadné přehlédnout.

Když v Claude Code obnovíte starou session, vracíte se k její konverzaci. Dokumentace Claude Code k sessionpopisuje ukládání historie konverzace, tool callů a jejich výsledků. Projekt na disku ale mezitím mohl pokračovat úplně jinam.

Proto není ideální vrátit se po několika hodinách nebo dnech do staré session a napsat pouze:

Pokračuj.

Lepší je něco jako:

Nejdřív zkontroluj aktuální stav repozitáře a znovu načti relevantní
soubory. Od poslední práce v této session se projekt mohl změnit.
Potom pokračuj.

Ještě lepší je mít toto pravidlo natrvalo v projektových instrukcích.

Úplně jiná situace: dva agenti pracují opravdu paralelně

Doteď byla řeč o agentech, kteří se střídají v čase.

Teď jde o něco jiného: pustíte dva nebo více agentů a oni pracují současně.

Například:

Claude Code opravuje backend
druhý Claude Code upravuje frontend
Codex současně píše testy

Pokud všichni pracují nad jednou a tou samou pracovní složkou, nestačí už hlídat aktuální kontext.

Agent A může načíst soubor, agent B ho mezitím změnit a agent A do něj následně zapsat svou vlastní úpravu založenou na starším stavu.

Teď už nejde jen o „paměť“. Jde o přímé souběžné změny stejného filesystemu.

Pro paralelní práci nestačí pouze samostatná branch

Tady je důležitý detail.

Říct:

jeden agent = jedna branch

je správný směr, ale samo o sobě to nestačí.

Jedna běžná pracovní složka má vždy checkoutnutý jeden pracovní stav. Pokud mají dva agenti skutečně pracovat paralelně, potřebují také dvě oddělené pracovní složky.

Git je pro to vybavený pomocí git worktree.

Například:

git worktree add ../projekt-agent-a -b agent-a
git worktree add ../projekt-agent-b -b agent-b

Vznikne:

projekt/
projekt-agent-a/
projekt-agent-b/

Agent A pracuje ve své složce na své branchi a agent B ve své.

Sdílejí historii repozitáře, ale nepřepisují si přímo pracovní soubory.

Pro paralelní práci tedy platí spíš:

jeden agent = jedna branch + jeden worktree

Claude Code má worktrees přímo zabudované

Claude Code umí podle oficiální dokumentace vytvořit izolovaný Git worktree přímo při spuštění:

claude --worktree feature-auth

nebo:

claude -w feature-auth

Další paralelní agent může dostat jiný worktree.

Anthropic uvádí jako hlavní důvod právě izolaci paralelních Claude Code session, aby si navzájem nezasahovaly do souborů.

Také desktopová aplikace Claude Code používá pro paralelní práci s Git projekty oddělené worktrees.

Pokud ale jednoduše otevřete několik terminálů, v každém spustíte Claude Code a všechny necháte pracovat ve stejném adresáři, žádná taková izolace mezi nimi automaticky nevznikne.

Codex používá stejný princip

Také Codex aplikace používá Git worktrees pro izolaci paralelních agentů nad jedním repozitářem.

Není to tedy nějaká zvláštnost Claude. Worktree je vlastnost Gitu a pro agentní práci se hodí právě proto, že několik oddělených pracovních stromů může sdílet jeden repozitář.

Pokud používaný AI nástroj worktrees sám nevytváří, můžete je založit ručně přes git worktree.

U paralelních agentů pozor i na sdílené stavové soubory

progress.json funguje výborně, když si práci předávají jednotlivé session postupně.

Pokud ale dva paralelně běžící agenti zároveň zapisují do jednoho progress.json, vytvořili jste si další místo, kde mohou vzniknout kolize.

V takovém případě je lepší například:

mít pro jednotlivé úkoly nebo agenty oddělené stavové soubory
používat append-only log, například JSONL, pokud se pro daný případ hodí
ukládat stav do systému, který umí souběžné zápisy koordinovat
rozdělit práci tak, aby každý agent vlastnil jinou část stavu

Worktree totiž izoluje soubory jednotlivých Git pracovních stromů, ale nevyřeší automaticky všechny externí sdílené prostředky. Dva agenti mohou stále používat stejnou databázi, stejné API, stejné dočasné soubory mimo repozitář nebo třeba stejný vývojový server.

Při skutečně paralelní práci je proto dobré přemýšlet nejen nad zdrojovým kódem, ale i nad tím, co dalšího agenti sdílejí.

Dvě situace, dvě různá řešení

Nejdůležitější je tyhle dva případy opravdu oddělit.

Když se session střídají:

problémem je hlavně zastaralý kontext
před pokračováním zkontrolujte Git a znovu načtěte relevantní soubory
důležitý provozní stav ukládejte mimo konverzaci
worktree obvykle není potřeba

Když agenti pracují paralelně:

problémem jsou navíc přímé souběžné změny
nedávejte několik agentů do jednoho pracovního stromu
každý agent by měl mít vlastní branch a worktree
počítejte také se sdílenými databázemi, stavovými soubory a dalšími prostředky

AI může mít velmi dlouhý kontext a může si pamatovat spoustu detailů předchozí práce. To je užitečné pro pochopení toho, proč se něco dělalo.

Pro zjištění toho, jak projekt vypadá právě teď, jsou ale rozhodující aktuální soubory a Git.

A pokud na projektu pracuje několik agentů ve stejnou chvíli, je potřeba jim kromě samostatného kontextu dát i samostatný prostor, ve kterém mohou bezpečně měnit soubory.