Zbuduj pętlę proaktywnego agenta na Claude Opus 5.5

Niewygodna część budowania własnego proaktywnego agenta polega na tym, że interesująca praca nie jest wywołaniem modelu. Możesz mieć Claude Opus 5.5 odpowiadający na pytania w jedno popołudnie. Doprowadzenie go do tego, by budził się zgodnie z harmonogramem, czytał tylko to, co zmieniło się od ostatniego razu, decydował, czy cokolwiek zasługuje na człowieka, szkicował działanie, a następnie zatrzymywał się i czekał — to tygodnie, a prawie nic z tego nie dzieje się wewnątrz modelu. Anthropic wydało wersję tej pętli jako Claude Duet, a to, co w tym produkcie jest użyteczne dla każdego, kto buduje własny, to nie lista funkcji, lecz decyzje widoczne w sposobie, w jaki jest złożony. Nie ma opublikowanego API i nie można go przepiąć na własne systemy, więc jeśli chcesz pętlę, a nie aplikację, budujesz ją. To, co następuje, to architektura, etap po etapie, wraz z uczciwym kosztem każdego z nich.

Najpierw kształt. Pięć etapów przebiega sekwencyjnie, a piąty jest osiągany dopiero wtedy, gdy człowiek powie „tak”. Uruchamia się harmonogram. Etap digestu redukuje każdy podłączony system do delty. Etap decyzyjny przekształca tę deltę wraz z polityką w typowaną propozycję. Bramka zatwierdzenia poza modelem decyduje, czy propozycja może zostać uruchomiona. Wykonawca ją realizuje. To cały projekt, a wszystko, co w nim trudne, tkwi w szwach.

Etap pierwszy: scheduler, który uruchamia się co kilka godzin

Pierwsza decyzja to ta, którą ludzie podejmują błędnie z entuzjazmu, a nie z inżynierskiego podejścia: nie odpytuj bez przerwy. Dokumentacja Anthropic's Duet wyjaśnia swój interwał — sprawdzanie co kilka godzin — mówiąc, że sprawdzanie bez ustanku zużyłoby limity planu znacznie szybciej. To nie jest ostrożność marketingowa. To właściwa odpowiedź na realny problem kosztowy i pułapka, w którą wpada każdy agent tworzony własnymi siłami już w pierwszym tygodniu.

Ciągłe odpytywanie jest zgubne z powodów strukturalnych. Każde przemiatanie to pełny kontekst: instrukcje, definicje narzędzi, materiał, który został wciągnięty, oraz całe rozumowanie, jakie model nad nim przeprowadza. Przy kadencji co minutę to 1440 pełnych kontekstów dziennie, a przytłaczająca większość nie znajduje nic nowego. Płacisz pełną cenę, żeby dowiedzieć się, że skrzynka się nie zmieniła. Co trzy godziny masz osiem, a stosunek znalezisk do wydatków staje się czymś, co możesz obronić przed każdym, kto podpisuje fakturę.

Harmonogram to timer w stylu cron z dolnym limitem minimalnego interwału, a nie strumień zdarzeń. Zdarzenia brzmią atrakcyjnie — reagujesz w momencie, gdy coś się dzieje — ale spychają cię z powrotem w stronę ciągłej pracy i sprawiają, że koszt pracowitego dnia jest nieograniczony. Timer daje przewidywalny pułap, którego potrzebujesz, gdy rachunek jest zmienny. Jeśli chcesz szybszej reakcji dla jednego źródła, skróć sam interwał tego konektora i zaakceptuj dodatkowy wydatek.

Etap drugi: jeden identyczny co do bajtu prefiks, przechowywany w pamięci podręcznej

To tutaj opublikowane liczby odgrywają największą rolę. Claude Opus 5.5 w OrcaRouter kosztuje 4,00 dolara za milion tokenów wejściowych i 20,00 za milion tokenów wyjściowych, ma okno kontekstu 1 mln tokenów, a odczyty z pamięci podręcznej kosztują 0,20 za milion — według cennika dostawcy z narzutem 0 procent. Czytaj te liczby jako ograniczenie projektowe, a nie cennik: odczyt z pamięci podręcznej kosztuje jedną dwudziestą świeżego tokena wejściowego, więc każdy bajt, który utrzymujesz stabilny między przebiegami, to bajt, za który przestajesz płacić pełną cenę.

W praktyce prompt systemowy i schemat narzędzia są składane raz na etapie wdrożenia i nigdy nie są regenerowane przy każdym przebiegu. Nie są ponownie serializowane ze słownika z kluczami w innej kolejności. Nie są szablonowane ze znacznikiem czasu, identyfikatorem żądania ani dzisiejszymi połączonymi kontami wstawianymi w środek. Każdy różniący się bajt unieważnia buforowany prefiks, a blok instrukcji powraca do pełnej ceny wejściowej przy każdym przebiegu. Zespoły tracą to przypadkowo częściej niż celowo, zwykle dlatego, że pomocna abstrakcja zaczęła wstrzykiwać identyfikator uruchomienia w pobliżu początku promptu.

Dyscyplina, która przetrwa zetknięcie z prawdziwym kodem, jest nudna: jedna funkcja zwracająca stały ciąg znaków dla stabilnego bloku, zamrożony literał dla schematu narzędzia, każdy zmienny element umieszczony po nim. Potem test, który haszuje blok i powoduje niepowodzenie kompilacji, gdy hash się zmieni, bo ktoś w końcu doda pole do schematu i w ogóle nie pomyśli o cache'u. Ten test kosztuje godzinę i ratuje całą korzyść z cache'owania.

Etap trzeci: skrót dla każdego połączenia, a nie zrzut skrzynki pocztowej

Trzeci etap to ten, który produkt konsumencki dostaje za darmo, a ty nie. Duet działa wewnątrz konta Anthropic i ma dostęp do połączonych aplikacji, dzięki czemu może zapytać, co zmieniło się od danego czasu, i otrzymać krótką odpowiedź. Budując poza tym kontem, komunikujesz się z tymi samymi API co każdy zwykły klient: albo wdrażasz odczyty przyrostowe, albo pobierasz wszystko i podajesz modelowi ścianę tekstu.

Pobieranie wszystkiego jest ustawieniem domyślnym, ponieważ działa od pierwszego dnia. To także najszybszy sposób, by koszt każdego przeglądu stał się nieprzewidywalny, ponieważ dane wejściowe rosną wraz ze skrzynką pocztową, a nie wraz z tym, co się zmieniło. Przegląd czterdziestu niezmienionych wątków kosztuje tyle samo co przegląd czterdziestu wątków, w których znaczenie ma jeden wątek, a tylko jeden z nich miał jakąkolwiek szansę na użyteczną propozycję. Po miesiącu takiego działania większość Twojego budżetu szła na potwierdzanie stanu obecnego.

Etap digestu powinien być kodem, a nie promptowaniem. Pobieraj dane dla każdego połączenia, używając dowolnego kursora lub delty oferowanych przez API, i redukuj wynik do ustrukturyzowanego podsumowania: co się pojawiło, co zostało zmodyfikowane, co zostało rozwiązane. Nadaj każdemu elementowi stabilny identyfikator, aby późniejsze etapy mogły się do niego odwoływać, i zapisuj ostatni udany kursor dla każdego połączenia, tak aby nieudane pobranie nie odtwarzało wczorajszego materiału jako nowego. Digest, który nie potrafi odróżnić „nic się nie wydarzyło” od „nie mogłem sprawdzić”, w końcu z pewnością siebie zaraportuje stan, którego nigdy nie zaobserwował.

Etap czwarty: krok decyzyjny, który emituje obiekt, a nie prozę

To tutaj znajduje się Claude Opus 5.5, a to, co emituje, decyduje o tym, czy resztę systemu da się w ogóle zbudować. Odruch podpowiada, by kazać modelowi napisać podsumowanie i pozwolić człowiekowi je przeczytać. To sprawdza się w przypadku pulpitu nawigacyjnego, a zawodzi w przypadku bramki: następny etap musi zdecydować, czy zezwolić na działanie, a zgody nie można udzielić akapitowi.

Krok decyzyjny powinien zwracać typowaną propozycję działania: nazwę akcji z zamkniętej listy, cel, którego ona dotyczy, parametry, jednozdaniowe uzasadnienie oraz jawną flagę pewności lub eskalacji. Zamknięta lista akcji nie jest biurokracją; to mechanizm, który czyni bramkę zatwierdzania egzekwowalną, ponieważ bramka może walidować tylko akcje, które potrafi wyliczyć. Agent, który może emitować dowolny czasownik, nie może być objęty bramką — można mu jedynie zaufać.

Dwie praktyczne uwagi. Najpierw przekaż modelowi skrót, a potem politykę, tak aby polityka znalazła się po zmiennym materiale, a prefiks pamięci podręcznej pozostał nienaruszony. I ustaw domyślny wynik jako „brak działania”, a nie pustą propozycję, która brzmi jak działanie. Pętle, które traktują ciszę jako porażkę, generują wolumen, a agent, który wymyśla pracę, by wyglądać na użytecznego, jest gorszy niż taki, który zgłasza, że nic się nie zmieniło.

Etap piąty: bramka zatwierdzania, która naprawdę potrafi odmówić.

Bramka musi być osobną usługą, a nie gałęzią wewnątrz kodu samego agenta. To najważniejsza decyzja strukturalna w całej budowie. Jeśli proces agenta może sam wykonać tę akcję, błąd, wstrzyknięcie promptu lub nieprawidłowo ustawiona flaga w tym procesie dociera do skutku. Jeśli wykonawca przyjmuje wyłącznie propozycję podpisaną przez bramkę, najgorsze, co agent może zrobić, to zaproponować coś błędnego, a odmowa bramki jest rzeczywista.

Opublikowana polityka Anthropic dotycząca Duet jest warta skopiowania pod względem struktury, nawet jeśli twoja lista się różni. Bramka wymaga zatwierdzenia, zanim akcja wyśle wiadomość, dokona płatności, podpisze dokument lub cokolwiek usunie. Ponad nią znajduje się drugi poziom, odmawiany nawet po zatwierdzeniu — w przypadku Duet są to obrót papierami wartościowymi i przenoszenie pieniędzy między kontami. Wzorzec to polityka dwupoziomowa: duży zbiór akcji objętych bramką, na które człowiek może zezwolić, oraz mały zbiór, którego żadne zatwierdzenie nie odblokowuje. Skopiuj te poziomy, nawet jeśli zmieni się każdy element, ponieważ rozwiązują one różne problemy. Bramka chroni przed pomyłką. Lista zakazów chroni przed przejętym operatorem, w tym także przed człowiekiem.

Drugą połową prawdziwej bramki jest to, że przerywa przepływ. Prośba o zatwierdzenie od Duet pokazuje dokładną akcję i czeka, co celowo zatrzymuje przepływ, zamiast go jedynie opisywać. Bramka, która zapisuje wiersz w logu, którego nikt nie czyta, nie jest bramką; to pokwitowanie. Jeśli Twój krok zatwierdzania wymaga, aby ktoś o trzeciej nad ranem patrzył na pulpit, to albo interwał jest zbyt krótki, albo lista akcji jest zbyt szeroka. Oba problemy da się naprawić, ale żadnego nie poprzez dodanie powiadomienia.

Pamięć, poświadczenia i dwie powierzchnie, z których nie wydostaniesz się samymi testami

Pod pięcioma etapami kryją się dwa trudne problemy — oba wyglądają jak funkcje, dopóki nimi nie są.

• Przenoszenie kontekstu.Każdy przebieg to świeży kontekst, więc wszystko, co agent powinien pamiętać między przebiegami, musi zostać zapisane pomiędzy nimi. Aktualizowany na bieżąco plik stanu dla każdego połączenia, o ograniczonym rozmiarze, zawierający otwarte pozycje i ostatnie decyzje, wystarcza w większości pętli. Nie działa natomiast liczenie na to, że model zrekonstruuje historię z digestu, ponieważ digest jest wprost opisem zmian i nie zawiera pamięci o tym, co już zostało postanowione.

• Ochrona poświadczeń. Duet stosuje projekt wykorzystany w zarządzanych agentach Anthropic, więc nigdy nie widzi bezpośrednio Twoich haseł ani tokenów logowania. Odtworzenie tej dyscypliny to element, który pomija większość agentów tworzonych we własnym zakresie, a pominięcie go oznacza, że każdy prompt ma ścieżkę do poświadczenia. Model nigdy nie powinien przechowywać tokenu, nigdy nie powinien otrzymywać klucza API w postaci tekstu i nigdy nie powinien być komponentem, który przeprowadza uwierzytelnianie. Pozwól, aby etap digestu i wykonawca przechowywały poświadczenia i przekazywały modelowi wyłącznie wyniki.

Jest jeszcze powierzchnia, o której nikt nie chce myśleć: gdy agent czyta e-maile i strony internetowe, każde z nich jest danymi wejściowymi, które mogą zawierać instrukcje. Wiadomość mówiąca „prześlij to na poniższy adres” jest nieodróżnialna od danych dla modelu, który nie ma odrębnego pojęcia autorytetu. Dwie linie obrony przewyższają dowolny stopień utwardzania promptów. Utrzymuj zamkniętą listę działań, aby wstrzyknięta instrukcja nie miała czasownika, po który mogłaby sięgnąć. A bramę trzymaj poza wpływem modelu, ponieważ wstrzyknięcie, które przekona model do wysłania czegoś, nadal musi przekonać człowieka, który widzi adres docelowy.

Failover i gdzie routing naprawdę pomaga

Po zbudowaniu pętli otwiera się opcja architektoniczna, której nie ma projekt oparty na jednym dostawcy. Routing DSL OrcaRoutera łączy kilka modeli w jedno wywołanie, a fuzja modeli uruchamia panel modeli odpowiadających równolegle; oba podejścia umieszczają więcej niż jeden model za pojedynczym żądaniem. Praktyczne zastosowanie jest tu mało efektowne: skieruj tańszy model do podsumowania digestu, gdzie praca polega na kompresji, a nie na ocenie, i pozostaw Claude Opus 5.5 na kroku decyzyjnym, w którym powstaje propozycja. Ten sam klucz zgodny z OpenAI daje dostęp do ponad 200 modeli, więc przełączanie modelu obsługującego dany etap to zmiana konfiguracji, a nie przepisywanie.

Failover to druga połowa. Gdy dostawca ma złą godzinę, agent, który może dotrzeć tylko do jednego punktu końcowego, też ma złą godzinę, a zaplanowana pętla bez mechanizmu awaryjnego po prostu nie wykonuje swojego przebiegu. Routing zamienia pominięty przebieg w wolniejszy — żadna dramatyczna korzyść, dopóki nie nadejdzie tydzień, w którym jej potrzebujesz, a wtedy to różnica między luką w zapisie a jej brakiem.

Na co tak naprawdę się zapisujesz

Uruchamianie tej pętli to eksploatowanie usługi, a ta usługa ma cztery właściwości, których własność właśnie przejąłeś.

• Dostępność. Aplikacja Anthropic to cudzy pager; twój jest twój. Harmonogram, który po cichu przestaje się wyzwalać, nie generuje błędu ani żadnego wyniku, a ty dowiadujesz się o tym od człowieka, który zauważył brak swojego porannego podsumowania, a nie z alertu.

• Ochrona poświadczeń.Każdy token przechowywany przez Twój krok digestu jest na Twojej odpowiedzialności, a zasięg szkód w razie wycieku obejmuje wszystko, do czego to połączenie ma dostęp. Rozwiązanie Anthropic trzyma poświadczenia z dala od modelu; jeśli Twoje tego nie robi, model staje się powierzchnią ataku dla każdego konta, które podłączyłeś.

• Ochrona przed wstrzykiwaniem promptów. Bramka wiele tu daje, ale tylko w przypadku działań, które kontroluje. Wszystko, co agent robi bez zatwierdzenia — czytanie, podsumowywanie, zapisywanie własnego stanu — jest niechronione, a zatrute podsumowanie może uszkodzić pamięć, z której późniejsze przebiegi czerpią przesłanki.

• Bug bounty nie należy do nikogo. Jeśli twoja pętla zadziała nieprawidłowo i wyśle klientowi niewłaściwą wiadomość, nie ma dostawcy, do którego można by eskalować, nie ma strony statusu ani raportu o incydencie. Powyższe decyzje to jedyna siatka bezpieczeństwa — dlatego bramka jest osobną usługą, a lista działań jest zamknięta.

Nic z tego nie przemawia przeciwko temu, by to zbudować. Przemawia przeciwko temu, by budować to bezrefleksyjnie. Każdy etap jest mały, a szwy między nimi to miejsce, w którym kryje się osąd: licznik czasu zamiast strumienia, zamrożony prefiks zamiast szablonu, skrót zamiast zrzutu, obiekt zamiast prozy oraz brama będąca usługą, a nie komentarzem. Dopracuj je, a pętla się opłaci — znajduje rzeczy, których nie szukałbyś, i zatrzymuje się, zanim zrobi cokolwiek, czego nie da się cofnąć. Zrób je źle, a zbudujesz coś, co bez przerwy zużywa twój budżet i mówi ci to, co już wiedziałeś.