Zatímco předchozí případová studie byla hostovaný, na poskytovateli nezávislý finanční systém, tento je záměrně odlišný téměř v každém rozměru: osobní, fork-and-own framework pro pracovní žádosti, postavený nativně na jednom konkrétním coding agentovi místo abstrakce napříč poskytovateli, zcela bez sandboxovaného prostředí spouštění. Kontrast mezi oběma případovými studiemi je sám o sobě poučný — existuje víc než jeden legitimní způsob, jak aplikovat stejné podkladové koncepty, v závislosti na tom, k čemu systém skutečně slouží.
Repozitář postavený z primitivů
Struktura tohoto systému se mapuje přímo na slovní zásobu zavedenou dříve v této sérii. Soubor s projektovými instrukcemi obsahující profil kandidáta je vrstva stálých instrukcí. Sada příkazů — /setup, /scrape, /apply a další — jsou deterministické spouštěče, které člověk explicitně vyvolává. Zabalený skill obsluhuje samotný proces podání žádosti. A sada portálových nástrojů poskytuje přímé vazby na pracovní portály a služby, se kterými systém interaguje. Každá vrstva v tomto repozitáři je konkrétní instancí konceptu už probraného v abstraktní rovině.
Workflow /apply, krok za krokem
Centrálním prvkem je jediný příkaz, /apply, který řetězí deterministický kontrolní bod, explicitní hranici důvěry a nedeterministickou smyčku autor-a-revizor. Načte a naparsuje pracovní inzerát a — což je klíčové — zachází s tímto inzerátem jako s neověřenými daty, nikdy jako s instrukcemi, takže jakákoliv direktiva náhodně nebo záměrně vložená do inzerátu — klasický vektor prompt injection — je podle návrhu jednoduše ignorována. Pak vyhodnotí shodu a tuto evaluaci předloží uživateli dřív, než cokoliv vůbec navrhne. Teprve poté přichází schvalovací bod uživatele — jediný deterministický krok v celém průběhu, kde uživatel explicitně schválí pokračování nebo běh úplně zastaví. Po schválení agent-autor napíše na míru upravené CV a motivační dopis podle aktivní šablony kandidáta a izolovaný revizor — subagent s čerstvým kontextem, který nezávisle prozkoumá společnost a kritizuje návrh bez zdědění autorových předpokladů — výsledek zkontroluje a v případě potřeby ho vrátí k revizi, opakovaně, dokud není spokojen.
Dvě rozhodnutí, která stojí za konkrétní zmínku
Explicitní hranice důvěry hned v prvním kroku si zaslouží zvláštní pozornost, protože je konkrétní odpovědí na reálnou a běžnou bezpečnostní obavu: agent, který čte pracovní inzeráty z otevřeného internetu, ze samotné definice čte neověřený obsah, a návrh tohoto systému s tímto obsahem zachází striktně jako s daty, ze kterých se mají extrahovat informace, nikdy jako se zdrojem instrukcí, kterými se řídit — čímž uzavírá celou třídu rizika prompt injection na architektonické úrovni, místo aby doufal, že se model prostě bude chovat slušně.
Izolovaný revizor je druhý detail, u kterého se vyplatí zastavit, protože je to koncept izolace kontextu, který dělá přesně tu práci, pro kterou byl navržen: revizor sdílející vlastní kontext autora by prostě zdědil autorovy předpoklady a slepá místa, čímž by efektivně jen orazítkoval vlastní práci. Dát revizorovi skutečně čerstvý kontext je to, co dělá z review skutečnou kontrolu, ne formalitu.
Záměrně odlišná pozice k nasazení
Zatímco obchodní systém pokrývá více poskytovatelů bez jediného bodu lock-inu, tento systém je nativní pro konkrétního coding agenta podle návrhu, spouštěný přes konkrétní CLI, zcela bez vrstvy abstrakce napříč poskytovateli — jde o uvážený kompromis, ne o opomenutí, vhodný pro osobní, fork-and-own nástroj, který si jeden člověk naklonuje a upraví pro sebe, ne pro multi-tenant produkční službu. Podobně zde není žádné sandboxované prostředí spouštění; vynucování je zcela na úrovni instrukcí, opírající se o výše popsanou hranici důvěry a stálá pravidla, ne o izolaci na úrovni infrastruktury. Obě volby dávají smysl pro to, čím tento systém skutečně je, a obě by pravděpodobně byly špatnou volbou pro jiný systém s jinými požadavky — což je nakonec ponaučení, ke kterému se každá případová studie vrací: neexistuje univerzálně správná architektura, jen sada dobře pochopených kompromisů, které je třeba pro konkrétní problém před vámi učinit záměrně.
Otázky pro váš tým
- Které části vašeho vlastního hledání práce nebo náborového procesu působí nejmechaničtěji a nejopakovaněji?
- Kde byste vedli hranici mezi tím nechat agenta jednat vaším jménem a tím, aby jen navrhoval?