CS
Průhledná odvozenina obličeje z obrázku kočky Kiki dodaného autorem
Zpět do sálu

Kiki

Pracovní signály a provádění agentů

Aby se návrh stal činností řešitele.

Plugin pro Paperclip a kolektor ze Slacku, které týmu pomáhají provozovat agenty AI.

2026.04 — 2026.05

pinxlab AI R&D na volné noze · plánování a vývoj pracovního postupu, šetření zaseknutého provádění a návrh cesty obnovy

  • PluginImplementováno · Paperclip
  • Server MCPImplementováno · Kolektor Slack

Mezi přidělením a skutečným provedením: cesta k pozorování a obnově.

Pracovní signály se mění na profily a direktivy pro agenty a schválení návrhu údržby je odděleno od přidělení jeho provedení. Když aktivita přiděleného tiketu ustane, znovu se o něj požádá s tiketem a řešitelem a opakované neodpovídání vede k limitu, cooldownu a lidskému posouzení.

Mění pracovní signály na direktivy pro agenty a jako samostatné kroky propojují návrhy údržby, lidské schválení, přidělení a obnovu zaseknutých běhů. Plánování a vývoj tohoto toku jsou mou prací.

První záznam v repozitáři April 3, 2026 · spolupráce s pinxlab do May 26, 2026

Běží jako plugin uvnitř týmového Paperclip; sběr ze Slacku obstarává server MCP.

Mapa toku provádění · z neveřejných záznamů implementace
Kiki: signály · schválení · obnova prováděníPracovní vzorce se z dostupné historie kanálů Slack vytěží do profilů firem a direktiv pro jednotlivé agenty. Agent analýzy údržby prochází cílový projekt a zanechává návrhy jako nepřidělené tikety v backlogu; každý návrh se zveřejní ve Slacku, kde ho člověk reakcí schválí nebo odmítne. Jakmile je schválený tiket přidělen agentovi, práci vykoná externí prováděcí systém a stage reaper sleduje nedávnou aktivitu. Pokud aktivita ustane, o přidělení se znovu požádá s tiketem a řešitelem; když po sobě jdoucí neodpovědi dosáhnou limitu, opakovaná volání ustanou a případ přejde na vedoucího nebo operátora.Signály SlackDostupná historie kanálůPřidělený agentExterní prováděníCílový projektObsah se nezobrazujeČlověk · schvaluje, odmítáReakce ve SlackuVedoucí · operátorNové přidělení · upozorněníSběr signálůVytěžení vzorců · bez botůStav firmySloučení profilu firmyStav agentaDirektivy pro agentyPozorování běhůNedávné běhy · aktivitaAnalýza údržbyVolání PO · prompt s vymezeným rozsahemSystém tiketůNávrh · backlogTiket k provedení · todoZveřejňování návrhůMapování zpráva ↔ tiketStage reaperKontrola uvíznutí · heartbeatObnovovací voláníTiket + řešitelStav neodpovídáníNeodpovědi · na tiketLimitZastavit volání · cooldownSignály → direktivyExterní prováděníNávrh → lidské schváleníObnova · eskalace1 historie kanálů · Signály Slack → Vytěžení vzorců · bez botů12 sloučení profilu · Vytěžení vzorců · bez botů → Sloučení profilu firmy23regenerace4 vložení direktiv · Direktivy pro agenty → Přidělený agent41rozsah cíle2 tiket s návrhem · Volání PO · prompt s vymezeným rozsahem → Návrh · backlog23zveřejnění návrhu4zpráva Slack5reakce6schválení → todo7odmítnutí → cancelled8přidělení1záznamy běhů2poslední aktivita3neodpověď +14nová aktivita → reset5 opakované volání · Kontrola uvíznutí · heartbeat → Tiket + řešitel56tiket + řešitel7po 38nové přidělení · upozornění9jen varování

Signály → direktivy

Profily a direktivy pro agenty vznikají z historie Slacku. Direktivy jsou kontextem agenta a nezobrazují se jako příčina žádného návrhu.

  1. Signály Slackhistorie kanálůVytěžení vzorců · bez botůSběr signálů

    Shromažďuje se dostupná historie kanálů a zprávy botů a o připojení či odchodu se odfiltrují. Původní zprávy se na této stránce nezobrazují.

  2. Vytěžení vzorců · bez botůSběr signálůsloučení profiluSloučení profilu firmyStav firmy

    Vytěžené vzorce se stanou záplatou profilu sloučenou do profilu firmy. Jde o heuristické vzorce, nikoli o hodnocení výkonu zaměstnanců.

  3. Sloučení profilu firmyStav firmyregeneraceDirektivy pro agentyStav agenta

    Direktivy pro jednotlivé agenty se ze sloučeného profilu vygenerují znovu a uloží.

  4. Direktivy pro agentyStav agentavložení direktivPřidělený agent

    Direktivy se dostanou do kontextu agenta při jeho vytvoření. Neznamená to, že určitý návrh vzešel z určitého signálu Slack.

Návrh → schválení → přidělení

Návrh nejprve existuje jako nepřidělený tiket v backlogu, reakce člověka žádá o změnu stavu a přidělení a provedení patří externímu systému.

  1. Cílový projektrozsah cíleVolání PO · prompt s vymezeným rozsahemAnalýza údržby

    Úloha údržby volá agenta PO s promptem vymezeným na cílový projekt. Obsah zdrojů se nezobrazuje.

  2. Volání PO · prompt s vymezeným rozsahemAnalýza údržbytiket s návrhemNávrh · backlogSystém tiketů

    Prompt žádá o návrhy jen s ověřenými cestami, ve formě nepřidělených tiketů v backlogu, a zakazuje spouštět migrace DB. Jde o pokyn produktovému agentovi, nikoli o deterministický mechanismus vynucení.

  3. Návrh · backlogSystém tiketůzveřejnění návrhuMapování zpráva ↔ tiketZveřejňování návrhů

    Každý návrh se zveřejní ve Slacku a mapování zprávy na tiket se uloží. Již zveřejněné návrhy se znovu nezveřejňují a uložené mapování drží posledních 50.

  4. Mapování zpráva ↔ tiketZveřejňování návrhůzpráva SlackČlověk · schvaluje, odmítá

    Člověk vidí zveřejněný návrh ve Slacku.

  5. Člověk · schvaluje, odmítáreakceMapování zpráva ↔ tiketZveřejňování návrhů

    Reakce na zprávu najde tiket přes mapování. Automatické schvalování neexistuje.

  6. Mapování zpráva ↔ tiketZveřejňování návrhůschválení → todoTiket k provedení · todoSystém tiketů

    Při schválení se odešle žádost o přesun čekajícího tiketu s návrhem do todo a aktualizuje se mapování a upozornění ve vlákně. Tento handler označí mapování jako schválené bez kontroly kódu odpovědi, takže nejde o transakci, která se při selhání uzavře.

  7. Mapování zpráva ↔ tiketZveřejňování návrhůodmítnutí → cancelledNávrh · backlogSystém tiketů

    Při odmítnutí se odešle žádost o přesun téhož tiketu do cancelled. Tiket existoval už před schválením; schválení ho nevytváří.

  8. Tiket k provedení · todoSystém tiketůpřiděleníPřidělený agent

    Přidělení a provedení tiketu todo patří externímu prováděcímu systému. Přesun tiketu do todo nezaručuje, že práce začala.

Uvíznutí → obnova → člověk

O přidělený tiket, jehož aktivita ustala, se znovu požádá s tiketem a řešitelem; když po sobě jdoucí neodpovědi dosáhnou limitu, přejde na člověka.

  1. Přidělený agentzáznamy běhůNedávné běhy · aktivitaPozorování běhů

    Běhy přiděleného agenta a nedávné signály se zaznamenávají jako pozorování. Aktivita není dokladem dokončení.

  2. Nedávné běhy · aktivitaPozorování běhůposlední aktivitaKontrola uvíznutí · heartbeatStage reaper

    Reaper sleduje jen tikety, které nejsou done, cancelled ani blocked a mají řešitele, a počítá stáří posledního signálu a fáze.

  3. Kontrola uvíznutí · heartbeatStage reaperneodpověď +1Neodpovědi · na tiketStav neodpovídání

    Po sobě jdoucí neodpovědi se počítají pro každou dvojici agent–tiket a ukládají do stavu.

  4. Nedávné běhy · aktivitaPozorování běhůnová aktivita → resetNeodpovědi · na tiketStav neodpovídání

    Nová aktivita počet vynuluje.

  5. Kontrola uvíznutí · heartbeatStage reaperopakované voláníTiket + řešitelObnovovací volání

    Pokud byl heartbeat překročen a počet je pod limitem, provede se obnovovací volání.

  6. Tiket + řešitelObnovovací volánítiket + řešitelTiket k provedení · todoSystém tiketů

    O přidělení se znovu požádá s tiketem, přiděleným agentem a vysvětlujícím komentářem a odpověď HTTP se zkontroluje. Cesta legacy to nahrazuje jediným budicím voláním.

  7. Neodpovědi · na tiketStav neodpovídánípo 3Zastavit volání · cooldownLimit

    Když po sobě jdoucí neodpovědi dosáhnou limitu (výchozí 3), opakovaná volání ustanou. Limit platí jen tehdy, když stavové hooky počet čtou a zapisují, a neúspěšné uložení ho může oslabit.

  8. Zastavit volání · cooldownLimitnové přidělení · upozorněníVedoucí · operátor

    Podle možností přidělí případ znovu vedoucímu a in_progress vrátí do todo jen tehdy, když je tato funkce zapnutá. Jinak zanechá komentář a upozornění best-effort a po dosažení limitu zaznamená cooldown.

  9. Kontrola uvíznutí · heartbeatStage reaperjen varováníVedoucí · operátor

    Když fáze trvá příliš dlouho, operátorům se zanechá jen varovný komentář. Stav se automaticky nemění.

Každé spojení se stejnou váhou. Výběr toku zvýrazní jen jeho cestu s očíslovanými kroky.

  • Plná čára · směr vstupu, výsledků a záznamů
  • Přerušovaná čára · spuštění, rozhodnutí, požadavek
  • Dlouhé tečky · pozorování a vykazování, odděleně od rozhodnutí
  • Krátké čárky · selhání, zastavení, limit
  • Silná černá čára · zvolený tok; čísla udávají pořadí
  • Rámeček · hranice kódu nebo stavu, pojmenovaná v záhlaví
  • Vnitřní štítek · komponenta této hranice
  • Tečkovaný rámeček · mimo tuto hranici
  • Oranžový obrys · místo, kde rozhoduje model
  • Volání agenta · obnovovací volání
  • Stav · záznamy
  • Kontrola uvíznutí · limit
  • Sběr · zveřejňování

Nakresleno podle neveřejných záznamů implementace a vývoje. Identifikátory týmu, tiketů a Slacku a původní zprávy se nezobrazují; nasazení, kontejnery a přihlašovací údaje patří vlastníkovi mimo tento plugin.

Jedno pozorování
Zpráva z April 28, 2026: při ruční diagnóze před změnou se u jednoho tiketu, který 67 hodin neběžel, znovu požádalo o přidělení s tiketem a řešitelem a nový běh se do 5 sekund zařadil do fronty. Dokončení, průměrná doba obnovy ani efekt po nasazení se neměřily.
Meze zpracování schválení
Na rozdíl od obnovovacího volání zpracování schválení označí mapování jako schválené bez kontroly kódu odpovědi. Nepopisuje se jako atomická transakce schválení ani jako transakce, která se při selhání uzavře.
Kdy limit platí
Limit 3 volání je implementace, která platí, když jsou přítomny stavové hooky. Nezaručuje právě jednu eskalaci při každém selhání.