AI agenti pro open-source: od e-mailu po Git issues

Od e-mailu k issue: co agent připraví a co musí rozhodnout člověk

E-mail plný námětů, Git issues bez návaznosti a pull request čekající na posouzení. To je každodenní realita open-source projektu. AI agenti v ní mohou odvést administrativu, ale nesmějí převzít odpovědnost za prioritu, odpovědi ani uzavření.

Přesnější než „AI agenti spravují issue“ je semi-automatizované triage a routing: agenti vytěžují, třídí a navrhují podněty. Konečné rozhodnutí zůstává na správci.

Autor komunitního projektu rodokmen zpracovává přibližně 60 e-mailů denně. Každá zpráva obsahuje zpravidla deset až dvacet připomínek, které vznikají při sestavování rodokmenu. Vedle e-mailů do projektu přicházejí Git issues a pull requesty.

Právě tato kombinace kanálů dělá workflow přenositelným: e-mail představuje nestrukturovaný vstup, issue pracovní položku a pull request návrh změny, který vyžaduje zvlášť opatrné posouzení.

Agent odvádí opakující se administrativu a připravuje podklady. Člověk nad nimi rozhoduje. Jde o human-in-the-loop postup: automatizace připravuje, autorizace zůstává lidská.

Třídění podnětů: jak zachovat kontext a vyhnout se duplicitám

1. Rozložte zprávu na samostatné podněty

Každý podnět musí mít odkaz na původní e-mail, odesilatele, datum a vlastní formulaci problému. Tím vznikne auditovatelná stopa a správce později odpoví konkrétnímu autorovi.

2. Vyhledejte existující podněty

Před vytvořením nového issue nejprve prohledejte existující tracker. Model sám o sobě duplicitu spolehlivě nerozpozná. Kombinujte proto podobnost embeddingů, normalizované klíče a lidskou kontrolu návrhů.

Jedno univerzální ID nemusí stačit, pokud je podnět složený: rodokmen, lokalita a období mohou být samostatné entity.

3. Porovnávejte entity, ne formulace

U rodokmenu posuzujte shodu podle osoby, lokality, času a dalších identifikátorů. Textová shoda je slabá metrika.

Stejný chybný záznam se může objevit v jednom e-mailu jako „rok 1897“, ve druhém jako „rok 1898“ a ve třetím s jiným názvem obce. Užitečnější jsou normalizované entity a pravidlo shody.

4. Předložte podklad k rozhodnutí

Neposílejte hotový tracker. Předložte tabulku nebo frontu s vazbou na zdroj. U každého podnětu uveďte:

• pravděpodobný duplicitní záznam,
• návrh štítku,
• prioritu,
• návrh odpovědi.

Správce tak rozhoduje na základě doložitelného podkladu, který lze přijmout, opravit nebo zamítnout.

Prioritizace: urgentní dnes, backlog jednou denně

Automatické upozornění na „hořící“ issue pomáhá jen tehdy, když vzniklou chybu můžete rychle opravit nebo alespoň potvrdit. Zbytek backlogu zpracujte jednou denně.

Workflow tak běží ve dvou tempech:

1. urgentní incidenty během dne,
2. plánovaná práce na konci cyklu.

Prioritu určujte podle dopadu a ověřitelnosti, ne podle slov „blokující“ nebo „kritický“. Rozlište bezpečnostní problém, vadný genealogický záznam, kosmetickou chybu a individuální potíž. O tom, zda se podnět stane skutečným issue, rozhoduje autor.

Co sledovat

Počet zpracovaných e-mailů sám o sobě neprokazuje úspěch. Měřte:

• podíl návrhů přijatých bez úprav,
• počet zachycených duplicit,
• počet chybně uzavřených issue,
• čas od přijetí podnětu do reakce.

Bez těchto metrik zůstává zkušenost anekdotou.

Jak to funguje pod kapotou a kde má postup limity

Obsah issue, komentáře i těla e-mailu tvoří nestrukturovaný kontext. Model jej nemusí rozlišit od systémové instrukce.

Pokud agent smí komentovat, štítkovat nebo otevírat pull requesty, může vykonat pokyn vložený do nedůvěryhodného podnětu. Oddělte proto data od příkazů, omezte práva agenta na zápis a vyžadujte lidské schválení externích akcí. U propojení přes MCP definujte minimální oprávnění.

Druhým limitem je ořez kontextu. Dlouhé vlákno, rozsáhlý diff nebo příloha se do kontextového okna nevejdou celé. Model pak může rozhodovat z úvodu a závěru a přehlédnout rozpor uprostřed.

Pomáhá chunking. Důležitá rozhodnutí ukládejte také do explicitního stavu, například do checklistu nebo strukturovaného záznamu.

Třetím omezením je shoda významů. Dva e-maily o téže osobě mohou vypadat odlišně kvůli různým variantám jmen nebo lokality. Naopak dvě různé osoby mohou mít podobná jména.

Genealogický závěr proto musí zůstat lidský. Model pracuje s digitalizací, ne s archivním originálem. OCR i neúplné matriky mohou vytvářet falešné shody. To je zásadní rozdíl oproti běžnému issue trackeru.

Přenos do dalších projektů a bezpečné napojení na GitHub

V jiném open-source projektu zjednodušte workflow na čtyři role:

1. extrakce podnětů,
2. deduplikace,
3. prioritizace,
4. návrh odpovědi.

GitHub je přirozeným výstupním kanálem. Issues i pull requesty už mají vlastní historii a vlastníka. Připojení přes API nebo MCP umožní používat existující hledání, propojit related issues a připravit návrh bez hromadného zakládání duplicit.

Jaké zásahy ponechat člověku

Bezpečnější variantou jsou pull requesty s návrhem změn nebo aktualizací. Nechte issue zavřené, dokud je člověk nepřijme. Samostatné zavírání, slučování pull requestů nebo publikování odpovědí patří až lidskému schválení.

Agent navíc potřebuje odlišit důvěryhodný systémový pokyn od textu připomínky a odmítnout pokus o změnu pravidel.

Omezte zátěž archivů

Diskuze přinesla konkrétní know-how: hromadné dotazy do archivů mohou vést k blokacím, robotovým kontrolám a omezení licence na stahování snímků.

Řešení není jen technické:

• omezte frekvenci požadavků,
• respektujte přístupová práva,
• předem definujte, kdy se systém obrátí na člověka.

Sdílená znalost mezi rodinami může archivní zátěž snížit. Vyžaduje ale vlastní souhlas, anonymizaci a kontrolu ochrany osobních údajů.

Co si z toho vzít

• Oddělte automatizaci od autorizace: agent připravuje, člověk rozhoduje.
• Deduplikujte podle normalizovaných entit, ne podle podobnosti textu.
• Před založením issue vždy vyhledejte existující podněty.
• Prioritu určujte podle dopadu, ne podle naléhavého tónu autora.
• Měřte přijaté návrhy, zachycené duplicity a chybné zásahy.
• Omezte agenta na zápis a vyžadujte schválení externích akcí.
• Zachovávejte odkaz na původní e-mail, aby bylo možné odpovědět autorovi.
• U archivních dat předpokládejte chyby digitalizace a lidskou kontrolu.