Budowa event-scout: agentyczna mikroaplikacja działająca bez nadzoru

Raz na przebieg event-scout przechodzi przez wyselekcjonowaną bazę źródeł, obejmującą strony eventowe, kalendarze, newslettery i kilka kanałów LinkedIn. Ze wszystkiego, co pobiera, zachowuje tylko przyszłe wydarzenia stacjonarne w zasięgu Remagen, ocenia każde z nich pod kątem tego, jak przydatne jest dla nas, usuwa duplikaty do jednego magazynu i odbudowuje dashboard, który faktycznie otwieramy.

Niewiele na tej liście jest samo w sobie nowe. To, co sprawia, że działa, to fakt, że pracuje bez nadzoru według harmonogramu oraz że stosowana ocena jest naszą oceną, a nie generycznym filtrem trafności. Wynikiem nie jest feed każdego eventu technologicznego w Niemczech. To krótka, uszeregowana odpowiedź na pytanie: gdzie powinniśmy pojawić się następnym razem.

Decyzja projektowa, która się liczy, dotyczy tego, gdzie kończy się model, a zaczyna skrypt.

Pobieranie danych zostało oddelegowane do deterministycznego pomocnika. Niewielki orchestrator w Node renderuje każde należne źródło w prawdziwej przeglądarce headless, dzięki czemu radzi sobie ze stronami JavaScript, lekkimi zabezpieczeniami anty-bot i leniwie doładowywanymi listami, a także przechwytuje ustrukturyzowane dane eventów schema.org, jeśli strona je udostępnia. To okablowanie: niezawodne, przewidywalne i za każdym razem takie samo.

Agent odczytuje to, co zapisał moduł pobierający, i zajmuje się częściami, które wymykają się sztywnemu kodowaniu: wyodrębnia prawdziwe eventy z chaotycznych stron, decyduje, co liczy się jako stacjonarne i istotne, ocenia każde z nich i rozpoznaje, że dwa wpisy dotyczą tego samego eventu. Drugi, mniejszy silnik następnie scala wpisy, usuwa stare i odbudowuje dashboard.

🔸 Niech model nie robi tego, co tanio załatwi skrypt.
Wyrenderowanie strony i zapisanie pliku to praca deterministyczna. Przekazanie jej modelowi byłoby wolniejsze, droższe i mniej niezawodne.

🔸 Niech skrypt nie robi tego, co wymaga oceny.
To, czy częściowo sformatowany wpis jest prawdziwym, istotnym eventem stacjonarnym, jest dokładnie taką decyzją, w której model jest dobry, a wyrażenie regularne nie.

Prawidłowe poprowadzenie tej granicy to główny powód, dla którego narzędzie jest niezawodne, a nie tylko sprytnym demo.

Scout, który przy każdym przebiegu sprawdza każde źródło tak samo, marnuje większość swojego wysiłku, ponieważ eventy nie pojawiają się równomiernie.

Dlatego każde źródło niesie własną krótką historię skuteczności. Źródła, które niezawodnie dostarczają istotne eventy, są sprawdzane przy każdym przebiegu. Źródła, które wielokrotnie wracają puste, przechodzą w coraz dłuższą fazę wychłodzenia, tydzień, potem dwa, potem miesiąc, i po jej upływie są testowane ponownie zamiast być odrzucane. Źródło, które po prostu nie dostarczyło eventów, jest cicho degradowane; tylko źródło, które kilka razy z rzędu się nie ładuje, zostaje wycofane jako uszkodzone.

Efekt jest taki, że uwaga płynie tam, gdzie eventy faktycznie się pojawiają, a system dostraja się sam przez tygodnie, bez konieczności utrzymywania go przez kogokolwiek. To właśnie to samodostrajanie sprawia, że praca bez nadzoru staje się prawdziwym stwierdzeniem, a nie tylko życzeniowym.

Ocena jest celowo nasza. Każdy event otrzymuje wartość w skali do 100, ważoną pod kątem naszej sytuacji: jak blisko i łatwo dostępny jest, jak gęsto dana przestrzeń gromadzi typ kupujących, których obsługujemy, jak kameralny jest, czy istnieje konkretna dźwignia, taka jak rabat lub slot na wystąpienie, oraz jak szybko się odbędzie.

Wagi niosą w sobie opinię, jaką mamy na temat sprzedaży. Duża konferencja plasuje się wysoko tylko wtedy, gdy jest realna dźwignia do wykorzystania, ponieważ w sprzedaży opartej na relacjach pełna sala bez dostępu jest warta mniej niż mały, regionalny okrągły stół, przy którym faktycznie możemy porozmawiać z ludźmi. Wynik czyta się jak kokpit decyzyjny, a nie kalendarz: pokazuje, gdzie warto zainwestować dzień, a nie wszystko, co istnieje.

Generyczny feed eventów nie mógłby tego odwzorować, ponieważ ocena jest specyficzna dla tego, jak konkretny zespół zdobywa zlecenia. Ta specyficzność jest powodem, dla którego opłacało się to zbudować, zamiast kupić.

event-scout jest celowo małe. Całość to garść plików JSON na źródła i magazyn eventów, kilka skryptów oraz samodzielny dashboard HTML, który otwiera się bezpośrednio z dysku. Nie ma bazy danych do utrzymywania ani subskrypcji do odnawiania. Dane pozostają nasze, podobnie jak ocena.

To ten sam krok, który opisały własne zespoły nieinżynieryjne Anthropic: budowanie małych, wewnętrznych narzędzi za pomocą agenta kodującego zamiast składania zgłoszenia i czekania (claude.com). Pisaliśmy o tym wzorcu również z perspektywy użytkownika (iiterate).

Nie jest wolne od szorstkich krawędzi, a twierdzenie przeciwne byłoby nieuczciwe. Źródła chronione logowaniem wymagają jednorazowo ręcznie przechwyconej sesji. Kilka upartych stron pozostaje ręcznymi tropami zamiast fałszywych wyników. A każdą odbudowę weryfikujemy, kontrolując bezpośrednio strukturę strony, ponieważ zrzut ekranu potrafi utknąć na ładowaniu czcionki. Nic z tego nie zmienia wniosku: jeśli zadanie jest powtarzalne i specyficzne dla Państwa sposobu pracy, agent kodujący może zamienić je w małe, własne narzędzie, taniej niż SaaS lub godziny ręcznej pracy, które ono zastępuje. Trudniejszym pytaniem nie jest, czy mogą Państwo takie narzędzie zbudować. Jest nim to, który z Państwa cotygodniowych obowiązków po cichu czekał, aż się nim stanie.