O czym jest ten film
- Zadania cykliczne uruchamiane w Codexie korzystają z limitu użycia przypisanego do subskrypcji. Autor pokazuje, jak zbudować automatyzację w Codexie, a uruchamiać ją w Trigger.dev.
- Rozróżnia procesy o stałej kolejności kroków od zadań, w których agent sam wybiera kolejne działania.
- Buduje poranny przegląd kalendarza Google, uzupełniany o przydatne informacje i wysyłany jako wiadomość w ClickUp.
- Pokazuje, jak połączyć Codexa, GitHuba i Trigger.dev oraz przenieść dane dostępowe do środowiska, w którym działa automatyzacja.
- Sprawdza działanie rozwiązania lokalnie i po wdrożeniu. Wyjaśnia też, dlaczego dwa pozornie nieudane uruchomienia nie oznaczały błędu w kodzie.
- Tworzy automatyzację uruchamianą po wysłaniu formularza. Powiadomienie o zgłoszeniu składa się z danych z formularza, a AI przygotowuje propozycję odpowiedzi.
- Wskazuje, kiedy można zrezygnować z kroku AI i użyć zwykłego szablonu wiadomości.
- Omawia zabezpieczenia formularza przed błędnymi danymi i masowymi zgłoszeniami oraz potrzebę sprawdzania działania całego procesu.
- Na przykładzie własnej rutyny związanej z analizą rachunku inwestycyjnego pokazuje zastosowanie Codex SDK, gdy agent musi wielokrotnie wracać do narzędzi i źródeł.
- Porównuje koszt i złożoność prostych skryptów, zadań w subskrypcji Codexa oraz agenta uruchamianego programowo przez SDK.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw ustal, co ma się wydarzyć
Na czym polega: Autor zaczyna od opisania celu, źródeł danych, odbiorcy, harmonogramu i ograniczeń kosztowych. Dzięki temu Codex może dopytać o brakujące decyzje, zanim napisze kod.
Jak stosować: Opisz automatyzację jako konkretną sekwencję: co ją uruchamia, jakie dane pobiera, kiedy korzysta z AI i gdzie wysyła wynik. Podaj też sytuacje wyjątkowe.
Na co uważać: Ogólna prośba w rodzaju „przygotuj mi poranny raport” pozostawia zbyt wiele decyzji agentowi. Może wybrać niewłaściwy kalendarz, porę lub miejsce dostarczenia wiadomości.
2.Stały proces zapisz jako kod
Na czym polega: W porannym przeglądzie kolejność działań się nie zmienia: uruchomienie o określonej porze, odczyt kalendarza, ewentualne zebranie informacji, napisanie wiadomości i wysłanie jej do ClickUp. AI jest potrzebna tylko w wybranych krokach.
Jak stosować: Jeśli potrafisz z góry rozpisać przebieg zadania, zbuduj skrypt z jasno wskazanymi etapami. Modelowi powierz jedynie ocenę lub redakcję, której nie da się wygodnie zapisać zwykłymi regułami.
Na co uważać: Sam fakt użycia AI nie oznacza, że całym procesem musi kierować agent. Większa swoboda działania może podnieść koszt i utrudnić przewidzenie wyniku.
3.Ogranicz agentowi możliwość wyboru odbiorcy
Na czym polega: Autor opisuje wcześniejszą rutynę, która po pewnym czasie zaczęła wysyłać wiadomości do niewłaściwych rozmów w ClickUp. W nowym rozwiązaniu właściwy adres rozmowy jest określony w kodzie.
Jak stosować: Identyfikatory odbiorców, kanałów i miejsc zapisu ustaw jawnie. Pozwól AI przygotować treść, ale kierowanie wiadomości oprzyj na sprawdzonych danych.
Na co uważać: Polecenie „wyślij to Nate’owi” może zostać różnie zinterpretowane. Przy wiadomościach dla klientów lub zespołu sprawdź odbiorcę w teście przed włączeniem harmonogramu.
4.Test lokalny nie zastępuje testu po wdrożeniu
Na czym polega: Poranny przegląd zadziałał na komputerze autora, lecz po uruchomieniu w Trigger.dev początkowo nie pojawiła się nowa wiadomość. Najpierw zadanie było wyłączone ustawieniem środowiskowym, a później zadziałała ochrona przed duplikatem.
Jak stosować: Przetestuj osobno działanie kodu i pełny przebieg w miejscu docelowym. Odczytuj status uruchomienia, jego dane wejściowe i wynik, zanim uznasz brak wiadomości za awarię.
Na co uważać: Wynik „wykonano” nie zawsze oznacza „wysłano”. Program może zgodnie z założeniami pominąć wysyłkę, na przykład dlatego, że podobna wiadomość już dotarła.
5.Trzymaj sekrety poza repozytorium
Na czym polega: Kod trafia do prywatnego repozytorium GitHub, ale klucze API i inne wrażliwe dane są z niego wyłączone. W środowisku Trigger.dev trzeba je udostępnić osobno.
Jak stosować: Rozdziel kod i dane dostępowe. Po wdrożeniu sprawdź, czy wszystkie wymagane zmienne środowiskowe są ustawione i czy aplikacja ma dostęp do właściwych kont.
Na co uważać: Prywatność repozytorium nie jest powodem, by umieszczać w nim klucze. Samo połączenie GitHuba z Trigger.dev również nie przenosi automatycznie uprawnień nadanych wcześniej w Codexie.
6.Wybierz sposób uruchamiania zgodny ze zdarzeniem
Na czym polega: Autor pokazuje dwa proste mechanizmy: harmonogram dla porannego przeglądu oraz zgłoszenie formularza dla powiadomienia o nowym kontakcie.
Jak stosować: Dla czynności regularnej ustaw odpowiednią porę i strefę czasową. Dla działania zależnego od użytkownika uruchamiaj proces po zdarzeniu, na przykład po wysłaniu formularza.
Na co uważać: Sprawdź rzeczywistą dokładność harmonogramu w wybranym planie usługi. W prezentowanym przypadku autor zwraca uwagę, że darmowy plan Trigger.dev mógł opóźnić zadanie zaplanowane na 6.00 nawet o godzinę.
7.Nie używaj AI do przepisania danych z formularza
Na czym polega: Imię, adres e-mail i wielkość zespołu można wstawić do powiadomienia bez udziału modelu. AI przydaje się dopiero przy propozycji dalszego kontaktu i szkicu odpowiedzi.
Jak stosować: Zbuduj zwykły szablon dla pól formularza. Dodaj krok AI wyłącznie tam, gdzie potrzebujesz interpretacji zgłoszenia lub tekstu dopasowanego do jego treści.
Na co uważać: Nie dokładaj wywołania modelu do czynności, którą rozwiązuje podstawienie wartości. To zwiększa koszt i czas wykonania bez wyraźnej korzyści.
8.Sprawdzaj formularz jako całość
Na czym polega: Autor wymienia dwa przykładowe problemy: niepoprawne adresy e-mail i masowe wysyłanie zgłoszeń. Pokazuje też test od wypełnienia formularza po wiadomość w ClickUp.
Jak stosować: Kontroluj format danych, ogranicz nadużycia i wykonaj próbne zgłoszenie przez ten sam formularz, z którego skorzysta użytkownik. Potwierdź, że uruchomiło zadanie i dostarczyło oczekiwaną treść.
Na co uważać: Sukces pojedynczej funkcji nie dowodzi, że działa cały ciąg: strona, wywołanie zadania, generowanie tekstu i dostarczenie powiadomienia.
9.Codex SDK zostaw dla zadań wymagających samodzielnych decyzji
Na czym polega: W trzecim przykładzie agent może ponownie sprawdzić rachunek, wrócić do wcześniejszych zapisów i poszukać dodatkowych źródeł. Liczba i kolejność tych działań zależą od tego, co znajdzie.
Jak stosować: Sięgnij po SDK, gdy proces musi sam wybierać następne kroki, a stała lista działań byłaby zbyt ograniczająca. Najpierw określ jego narzędzia, granice działania i sposób sprawdzania wyniku.
Na co uważać: Większa samodzielność oznacza więcej możliwych błędów, wyższy koszt i trudniejszą kontrolę. Przykład autora dotyczy obszaru, w którym skutki pomyłki mogą być poważne.
10.Osobno policz koszt wykonania i koszt budowy
Na czym polega: Przeniesienie zadania poza Codexa oszczędza limit użycia subskrypcji, ale nie oznacza darmowego działania. Mogą pojawić się opłaty za hosting, badanie sieci i wywołania modeli przez API.
Jak stosować: Ustal limit kosztu pojedynczego uruchomienia i sprawdzaj rzeczywiste wydatki. Porównaj prosty skrypt, zadanie cykliczne w Codexie i wariant z SDK dopiero po określeniu potrzebnej funkcji i skali.
Na co uważać: Autor podkreśla, że używanie Astry przez API może być droższe niż korzystanie z niej w ramach subskrypcji. Samo przeniesienie zadania nie musi więc obniżyć łącznego rachunku.
Redakcyjne tłumaczenie
Dlaczego uruchamiać automatyzacje poza Codexem
W Codexie można tworzyć zadania cykliczne. Każde ich uruchomienie trafia jednak do rozmowy i korzysta z tygodniowego limitu użycia. Jeśli takich zadań jest wiele, zaczynają zabierać znaczną część limitu, z którego korzystamy również przy codziennej pracy.
Nie każda automatyzacja musi działać wewnątrz Codexa. Możemy poprosić go o zaplanowanie i napisanie programu, a potem uruchamiać ten program w osobnej usłudze. Pokażę trzy przykłady: zadanie wykonywane według harmonogramu, zadanie rozpoczynające się po określonym zdarzeniu oraz bardziej samodzielny proces korzystający z Codex SDK. Do pokazanych rozwiązań przydadzą się konta Codex, Trigger.dev i GitHub.
Trigger.dev uruchamia przygotowany kod. W pierwszych przykładach napiszemy go w TypeScripcie. Nie trzeba znać tego języka, by śledzić całą procedurę: ważniejsze jest dokładne określenie, co program ma robić, oraz sprawdzenie, czy rzeczywiście to robi.
Przykład pierwszy: poranny przegląd dnia
Zacznijmy od zadania uruchamianego o stałej porze. Chcę, żeby w dni robocze około 6.00 rano program sprawdził mój główny kalendarz służbowy Google i przygotował krótki przegląd dnia. Powinien uwzględnić godziny spotkań, ich opisy, uczestników i miejsca. Jeśli dodatkowe informacje pomogą mi przygotować się do któregoś wydarzenia, może ich poszukać w publicznie dostępnych źródłach.
Najpierw omawiam pomysł z Astrą w Codexie. Pytam, czy rozumie, co chcę zbudować i czy pominąłem jakąś istotną decyzję. Ponieważ pracuję w projekcie, Codex może też sięgnąć do istniejącego opisu mojej porannej rutyny. Proponuje sposób działania: o 6.00 według czasu Chicago odczyta wydarzenia, oceni, które wymagają przygotowania, zbierze przydatne informacje, napisze krótki przegląd i wyśle go do mnie.
W tym miejscu słusznie dopytuje o szczegóły. Wskazuję, że wiadomość ma trafić do mojej prywatnej rozmowy w ClickUp i zostać wysłana przez konto Upit AI. Wystarczą dni robocze; nie przeszkadza mi, jeśli wiadomość dotrze o 6.05 czy 6.10. Na razie ma korzystać z głównego kalendarza pracy i publicznego internetu, bez przeszukiwania notatek, Dysku Google czy ClickUp. Proszę również, by koszt dodatkowego zbierania informacji nie przekraczał 25 centów na uruchomienie. Przyjmujemy, że stan kalendarza o 6.00 jest ostateczny — zadanie nie musi później sprawdzać zmian.
To pozornie prosty przykład, ale pozwala pokazać ważną różnicę. Cały przebieg jest przewidywalny: zegar uruchamia zadanie, program czyta kalendarz, decyduje o potrzebie zebrania dodatkowych informacji, pisze wiadomość i wysyła ją do ClickUp. Taka kolejność powtarza się za każdym razem. Zmienna jest treść dwóch środkowych etapów: decyzja o dodatkowym przygotowaniu i sama wiadomość. Do nich przydaje się AI. Nie ma natomiast powodu, by agent za każdym razem sam ustalał, gdzie znaleźć kalendarz albo komu wysłać wynik.
Według mojego doświadczenia wiele zastosowań w firmie i organizacji własnej pracy wygląda właśnie tak. Warto zapisać stałe kroki w kodzie i używać modelu tylko tam, gdzie musi ocenić dane lub napisać tekst.
Krótka przerwa na sponsora
Sponsorem tej części materiału jest Hyper Agent. To narzędzie dla osób prowadzących agencje AI, które wielokrotnie uczą agentów podobnych sposobów pracy dla kolejnych klientów. Pozwala zapisywać umiejętności i informacje o preferencjach klientów, źródłach danych czy wymaganym formacie odpowiedzi. Oferuje też podgląd działania agentów, ocenę wyników, porównywanie wariantów oraz kontrolę kosztów. Agent może ponadto działać w kanałach Slacka. Odsyłam zainteresowanych do odnośnika w opisie filmu.
Budowa, połączenia i pierwszy test
Po ustaleniu wymagań proszę Codexa o napisanie rozwiązania. Zanim przeniesiemy je do Trigger.dev, chcę, by sprawdził je możliwie dokładnie lokalnie i poprawił wykryte błędy. Nie zależy mi na pierwszej wersji, lecz na programie, którego działanie zostało potwierdzone.
Codex wskazuje, że w tym projekcie ma już dostęp do danych potrzebnych do połączenia z Kalendarzem Google, ClickUp oraz usługami używanymi do generowania i zbierania informacji. Jeśli ktoś nie ma jeszcze wymaganych kluczy API, może poprosić Codexa o przeprowadzenie przez ich uzyskanie.
Trzeba pamiętać o jednej rzeczy: uprawnienia nadane połączeniom w Codexie nie przechodzą automatycznie do Trigger.dev. Dlatego potrzebujemy danych dostępowych także w środowisku, w którym zadanie będzie później działało. Korzystam z lokalnego pliku .env, a po wdrożeniu ustawiam odpowiednie zmienne w Trigger.dev.
Codex buduje program i go sprawdza. Zwraca uwagę na koszt działania oraz upewnia się, że wybrana rozmowa w ClickUp jest właściwa. Ma to dla mnie szczególne znaczenie. Kiedyś podobna rutyna, działająca jako agent, po mniej więcej miesiącu zaczęła wysyłać wiadomości także do innych rozmów, w tym do kanału zespołu. Agent za każdym uruchomieniem ponownie interpretował polecenie. Tutaj program ma wskazany konkretny identyfikator rozmowy, więc nie podejmuje samodzielnie tej decyzji.
Lokalny test kończy się powodzeniem. W ClickUp widzę przegląd wtorkowego dnia: wydarzenia, odnośniki do wpisów w kalendarzu i wskazówki pomocne przed spotkaniami. To potwierdza połączenie z kalendarzem, działanie etapów AI oraz wysyłkę do ClickUp. Koszt tego próbnego uruchomienia wyniósł około 1,33 centa, znacznie mniej niż przyjęty limit 25 centów.
Zanim włączymy harmonogram, musimy jeszcze wykonać próbę już w Trigger.dev. Codex zwraca przy tym uwagę, że w używanym przeze mnie darmowym planie zadanie zaplanowane na 6.00 może rozpocząć się z opóźnieniem sięgającym godziny. Jeśli dokładna pora jest konieczna, trzeba uwzględnić ograniczenia wybranego planu.
GitHub i wdrożenie w Trigger.dev
Zakładam projekt w Trigger.dev, a następnie proszę Codexa o połączenie się z tą usługą i z GitHubem przez narzędzia wiersza poleceń. Uwierzytelnienie otwiera się w przeglądarce. Po zalogowaniu Codex może przygotować prywatne repozytorium z kodem automatyzacji i powiązać je z projektem w Trigger.dev.
GitHub przechowuje kod i historię zmian. Dzięki temu można wrócić do wcześniejszej wersji albo przekazać rozwój automatyzacji komuś z zespołu. Klucze API, dane kalendarza i inne wrażliwe informacje są wyłączone z repozytorium, mimo że jest ono prywatne. Trzeba je ustawić w Trigger.dev osobno.
Po pierwszej próbie widzę jednak, że połączenie z GitHubem nie pojawia się tam, gdzie go szukałem. Informuję o tym Codexa. Sprawdza konfigurację i okazuje się, że projekt został utworzony w innym obszarze mojego konta Trigger.dev. Po przejściu do właściwego projektu widzę zarówno zadanie zaplanowane na dni robocze, jak i osobne zadanie wykonujące właściwy przegląd kalendarza. To podział na uruchomienie według harmonogramu i pracę, którą należy wtedy wykonać.
Testuję harmonogram w Trigger.dev. Zadanie kończy się ze statusem „disabled”, a w ClickUp nie ma nowej wiadomości. Sprawdzam więc zmienne środowiskowe. Widzę, że dane dostępowe zostały przeniesione, ale ustawienie włączające poranny przegląd ma wartość „false”. Po zmianie na „true” uruchamiam test ponownie.
Tym razem Trigger.dev pokazuje wynik „delivered”, lecz nadal nie widzę nowej wiadomości. Proszę Codexa o wyjaśnienie. Program znalazł wcześniejszy przegląd wysłany tego samego dnia i celowo nie nadał duplikatu. Test wykonany później nie był więc awarią. Na potrzeby demonstracji zlecam jednorazowe obejście tej ochrony. Dopiero po otrzymaniu wiadomości z uruchomienia w Trigger.dev mam potwierdzenie całej drogi: od harmonogramu, przez dostęp do usług, po dostarczenie wyniku.
Nie trzeba rozumieć każdej linijki wygenerowanego kodu, żeby wykryć taki problem. Trzeba jednak sprawdzić zachowanie programu i zapytać, skąd wziął się konkretny wynik.
Przykład drugi: zgłoszenie z formularza
Drugą automatyzację uruchamia zdarzenie, a nie zegar. Proszę Codexa o przygotowanie prostej strony działającej lokalnie. Formularz ma zbierać imię, adres e-mail, wielkość zespołu i opis potrzeby. Po jego wysłaniu program w Trigger.dev powinien przesłać mi wiadomość w ClickUp: kto się zgłosił, czego szuka oraz jak mógłbym nawiązać kontakt. Chcę też dostać szkic odpowiedzi.
To nadal proces o stałej kolejności. Zgłoszenie uruchamia zadanie, program odczytuje pola, przygotowuje treść i wysyła ją do ClickUp. AI jest potrzebna jedynie do propozycji dalszego kontaktu i szkicu e-maila. Samą informację o imieniu, adresie czy wielkości zespołu można wstawić do szablonu bez udziału modelu. Gdybym chciał wyłącznie powiadomienie o nowym formularzu, mógłbym całkowicie pominąć etap AI.
Przy takim rozwiązaniu trzeba też pomyśleć o błędnych i masowych zgłoszeniach. Pole e-mail powinno przyjmować poprawnie zapisany adres, a formularz nie powinien pozwalać na nieograniczone wysyłanie żądań. Codex może pomóc sprawdzić różne przypadki i znaleźć usterki przed udostępnieniem strony innym osobom.
Ponieważ połączenia z GitHubem i Trigger.dev są już przygotowane, budowa kolejnego zadania przebiega szybciej. Codex informuje, że sprawdził cały proces. W Trigger.dev widzę kilka próbnych uruchomień wykonanych podczas testów. Sam również wypełniam formularz przykładowymi danymi: podaję imię, adres, wielkość zespołu i opis zajęcia, które firma chciałaby usprawnić.
Po wysłaniu formularz potwierdza przyjęcie zgłoszenia. W Trigger.dev pojawia się nowe uruchomienie, a w ClickUp otrzymuję wiadomość. Dane z pól są przepisane do powiadomienia bez pomocy AI. Dopiero propozycja kontaktu i szkic e-maila zostały wygenerowane przez model. Ten sam mechanizm uruchamiania po zdarzeniu można zastosować także przy innych sygnałach, na przykład nowym wpisie w CRM.
W tym miejscu odsyłam też do bezpłatnej instrukcji dotyczącej zdobycia pierwszego klienta na usługi automatyzacji AI. Odnośnik znajduje się w opisie filmu.
Przykład trzeci: agent uruchamiany przez Codex SDK
Ostatni przypadek jest inny. Czasem nie da się z góry określić wszystkich kroków, bo system musi zdecydować, czego jeszcze się dowiedzieć. Wtedy przydaje się pełny mechanizm pracy agenta dostępny przez Codex SDK — zestaw narzędzi pozwalający uruchamiać Codexa z programu.
Pokazuję to na przykładzie własnej rutyny związanej z analizą rachunku w Alpaca. W Codexie zadanie budzi się mniej więcej co 30 minut w okresach związanych z sesją giełdową. Sprawdza rachunek, przegląda wcześniejsze zapisy, zbiera informacje i zapisuje wynik, aby przy kolejnym uruchomieniu znać kontekst poprzednich działań. Może wracać do danych kilkakrotnie. Jeśli po dziesięciu minutach poszukiwań uzna, że stan rachunku mógł się zmienić, sprawdzi go ponownie. Liczby takich kroków nie znamy wcześniej.
W prostym programie dałoby się zaplanować, że system zajrzy do dwóch źródeł, a potem przygotuje wiadomość. Co jednak, jeśli po ich przeczytaniu powinien poszukać jeszcze jednego potwierdzenia? Musielibyśmy dopisać reguły pozwalające mu wracać do wcześniejszych etapów. SDK daje agentowi możliwość samodzielnego wybierania kolejnych działań w wyznaczonych granicach.
W mojej rutynie Astra prowadzi analizę i przygotowuje rekomendację, która trafia do ClickUp oraz e-mailem do osobnego bota. Jak wyjaśniam w nagraniu, to ten drugi bot obsługuje wykonanie transakcji. Przed przeniesieniem takiego procesu trzeba szczególnie dokładnie ustalić jego zakres. Większa samodzielność oznacza większy koszt, większą złożoność i więcej sposobów, na jakie coś może pójść źle. Dlatego radzę zaczynać od najprostszego rozwiązania, które spełnia wymagania.
Proszę Codexa o przeanalizowanie istniejącej rutyny, jej harmonogramu, używanych narzędzi i zapisów z poprzednich uruchomień, a następnie o zbudowanie odpowiednika w Trigger.dev. Po około 15 minutach otrzymuję projekt do przeglądu. Codex informuje o 44 wykonanych sprawdzeniach i — z własnej inicjatywy — wstrzymuje starą rutynę na komputerze. Ponieważ przeniesienie służy mi tylko do demonstracji, proszę o przywrócenie jej działania.
W nowym projekcie widzę cztery zadania. „Check” to właściwy proces, który ma uruchamiać się zgodnie z harmonogramem. „Pre-flight” sprawdza środowisko, połączenie z Alpaca, dane rynkowe i miejsce przechowywania informacji potrzebnych do kolejnego uruchomienia. „Proof” przeprowadza próbę pełnego przebiegu i oznacza wiadomości jako testowe; podczas tej próby nie przygotowuje zleceń gotowych do wykonania. „Install plan” pomaga przy konfiguracji. Trzy ostatnie służą przede wszystkim do uruchomienia i sprawdzenia rozwiązania; regularnie wykonywany ma być „check”.
Właściwy proces wczytuje wcześniejszy kontekst, pozwala Codexowi wskazać, co należy zbadać, zbiera potrzebne informacje, ocenia je, sprawdza wynik, dostarcza wiadomość i zapisuje informacje dla kolejnego uruchomienia. Samodzielność agenta polega tutaj na wyborze pytań i źródeł oraz na zmianie oceny, gdy pojawią się nowe dane.
Ręczny test zadania „check” nie uruchamia pełnej analizy, ponieważ wykonuję go po zamknięciu rynku. Program rozpoznaje niewłaściwą porę i kończy pracę odpowiednim statusem. W ClickUp widzę jednak wcześniejsze raporty z próbnego przeniesienia: zawierają wyniki analizy i odnośniki do źródeł. Dzięki nim mogę sprawdzić, że proces działał w wyznaczonym czasie.
Taki wariant pozwala wywoływać agenta programowo, także po zdarzeniu lub według innego harmonogramu. Ma sens wtedy, gdy naprawdę potrzebujemy tej możliwości i swobody działania na większą skalę. Jeśli rutyna może spokojnie działać w ramach subskrypcji Codexa, trzeba porównać koszty przed przeniesieniem jej do SDK. Dostęp do Astry przez API może okazać się droższy niż korzystanie z niej w ramach subskrypcji.