Kontekst, nie kontrola
Każda reguła w promptcie Twojego agenta zaczęła się jako błąd.
Ktoś zauważył złe zachowanie, napisał regułę i poszedł dalej. Ktoś inny zrobił to samo. Trzecia osoba dodała „nigdy nie rób X”, bo model raz zrobił coś dziwnego we wtorek. Nikt niczego nie usuwał.
Sześć miesięcy później agent spędza więcej swojego okna kontekstowego na przeglądaniu kodeksu reguł niż na myśleniu o faktycznym zadaniu.
To jest myślenie w stylu kontroli. I uważam, że to jeden z największych błędów projektowych popełnianych przez zespoły budujące agentów AI.
Mały przykład, który ujawnia większy wzorzec
Natknęliśmy się na problem, w którym agent wywoływany przez zaplanowane zadanie ciągle tworzył nowe zaplanowane zadania w trakcie działania. Nieskończona rekursja, ale z rzeczywistymi skutkami.
Są dwa sposoby reakcji.
Styl kontroli: Zakazać. Napisać kod blokujący tworzenie harmonogramów przez harmonogramy. Dodać regułę w promptcie: „nigdy nie twórz harmonogramu w harmonogramie”. Wdrażamy.
Styl kontekstu: Przekazać agentowi, co się faktycznie dzieje.
Zostałeś wywołany przez zaplanowane zadanie o 3:00 czasu pacyficznego. ID harmonogramu: sched_29x8f. Zaplanowane uruchomienie to odizolowane wykonanie o określonym zakresie, pierwotnie autoryzowanym przez użytkownika. Utworzenie nowego zaplanowanego zadania rozszerzyłoby ten zakres poza pierwotną autoryzację.
Pierwsze podejście łata jedno zachowanie. Drugie daje agentowi model sytuacji.
Teraz może rozważyć też pokrewne pytania: Czy powinienem wysłać powiadomienie o 3 rano? Czy powinienem utworzyć proces następczy, o który użytkownik nie poprosił? Czy powinienem zmodyfikować coś, co wykracza poza zakres pierwotnego uruchomienia?
Nie potrzeba reguły. Agent sam to rozumie.
Wiele zespołów sięga po kontrolę, gdy tak naprawdę potrzebują kontekstu.
Ten sam podział pojawia się w promptach
To nie dotyczy tylko egzekwowania na poziomie systemu. Podział kontekst kontra kontrola istnieje także w promptach.
Prompt w stylu kontekstu: głównie fakty, minimum opinii:
Uruchamiasz się z powodu zaplanowanego zadania. Wywołano o 3:00 czasu pekińskiego. ID zadania: sched_29x8f. Użytkownik autoryzował to uruchomienie dla określonego zakresu.
Prompt w stylu kontroli: opiniotwórczy, nakazowy:
Unikaj tworzenia harmonogramów. Powinieneś powiadomić użytkownika za pomocą narzędzia X. Nigdy nie rób Y, chyba że Z.
Czasem nakazowe instrukcje są przydatne. Ale bardzo często rekompensują brakujące fakty. A gdy zaczynasz tak rekompensować, łatwo się od tego uzależnić.
Jak prompt staje się biurokracją
To głębszy tryb awarii.
Zespół widzi problem i dodaje regułę. Potem kolejną. I następną. Każda łata lokalny problem, ale razem tworzą system pełen pośredników.
Bezos opisał ten wzorzec w swoim liście do akcjonariuszy 2016: dobry proces służy Tobie, byś mógł służyć klientom. Ale jeśli nie jesteś ostrożny, proces staje się celem samym w sobie.
Dokładnie to dzieje się w systemach agentów.
Reguła nie jest celem. Reguła to substytut pożądanego efektu. A substytuty się kumulują. Jedna tworzy przypadki brzegowe wymagające kolejnych. Wkrótce agent rozważa warstwy nagromadzonych instrukcji, z których każda została dodana z historycznego powodu, którego nikt już nie pamięta.
W organizacjach ludzkich to prowadzi do biurokracji. W systemach agentów – do ogromnego promptu pełnego blizn.
Fakty się starzeją. Opinie gniją.
Fakt typu „to uruchomienie zostało wywołane przez zaplanowane zadanie o 3” jest stabilny. Pozostaje prawdziwy niezależnie od tego, który model go czyta: Claude, GPT, Gemini, cokolwiek pojawi się w kolejnym kwartale.
Stwierdzenie „powinieneś unikać tworzenia podharmonogramów” jest kruche. Zależy od interpretacji. Może pomóc w jednej sytuacji, a w innej zawieść bez ostrzeżenia.
Gdy zmieniasz model, każda opinia w promptcie to potencjalna mina. Nowy model ma inne tendencje rozumowania i Twoje starannie skalibrowane „unikaj” może znaczyć dla niego coś zupełnie innego.
Ale osadzone w faktach informacje o środowisku, uprawnieniach, zakresie i ograniczeniach zwykle generalizują się na różne modele i przypadki brzegowe. Dlatego fakty są lepszym budulcem.
Pułapka osobliwości modelu
To może być najbardziej podstępna wersja problemu kontroli: zespoły nieustannie zamieniają tymczasowe wady modelu w trwałą strukturę systemu.
Model zachowuje się źle w jakimś wąskim przypadku. Zespół dodaje zabezpieczenie: łatkę w promptcie, sprawdzenie w kodzie, dziwną gałąź istniejącą tylko po to, by powstrzymać jeden konkretny tryb awarii.
Ta łatka to zakład, że osobliwość się utrzyma. Prawie nigdy tak nie jest.
Trzy miesiące później model się zmienia. Oryginalne zachowanie znika. Ale łatka zostaje. Nikt nie chce jej usuwać, bo może była potrzebna.
Tak prompty systemowe stają się kodem dziedziczonym.
Łatwo rozpoznać to zagrożenie w teorii. Ale w praktyce łatanie obecnych tendencji rozumowania Sonnet w kolejnych promptach to ten sam wzorzec w przebraniu.
Dokumentowanie stabilnych zachowań systemu jest wartościowe. Łatanie tendencji rozumowania modelu to bieżnia. Model zmieni się szybciej, niż zdołasz utrzymać swoje łatki.
Dobry przypadek testowy: odmowa uprawnień
Różnicę widać wyraźnie w diagnostyce narzędzi. Gdy agent napotyka błąd uprawnień:
Styl kontroli:
TOKEN nie istnieje. Uruchom „zero permissions request gmail.send”, aby naprawić.
Bezpośrednie, ale agent niczego się nie uczy. Następnym razem przy innym błędzie uprawnień – utknie.
Styl kontekstu:
process.env.GMAIL_TOKEN → istnieje zero connectors inspect gmail → połączono zero permissions inspect gmail.send → odmowa
Opcje:
- Poproś użytkownika o zgodę na gmail.send
- Użyj już autoryzowanej ścieżki, jeśli istnieje
Agent wie teraz, że token istnieje, konektor działa, a konkretne uprawnienie jest odmówione. Rozumie stan systemu i może rozważać nowe sytuacje, których autor reguły nie przewidział.
Heurystyka
Do tego ciągle wracam:
Zawsze, gdy masz napisać w promptcie „nie”, „unikaj” lub „nigdy”, zatrzymaj się. Zapytaj: jakiego faktu brakuje, że ta reguła go rekompensuje?
Zwykle brakuje jakiegoś faktu. Agent nie rozumie, w jakim środowisku się znajduje, co użytkownik autoryzował, które działania są nieodwracalne lub dlaczego to uruchomienie różni się od zwykłej rozmowy.
Zapisz ten fakt. Usuń regułę.
Czasem nadal będziesz chciał ograniczenia, zwłaszcza przy działaniach destrukcyjnych, przesyłaniu pieniędzy czy granicach bezpieczeństwa. Twarde ograniczenia nadal mają znaczenie.
Ale wiele reguł w promptach to nie prawdziwe granice. To rekompensaty za brak zrozumienia. I to właśnie one się kumulują i gniją.
Cel
Celem nie jest agent, który zapamiętuje listę kontrolną.
Celem jest agent, który rozumie swoją sytuację na tyle dobrze, by podejmować dobre decyzje w jasnych granicach.
Jedna filozofia kontroluje zachowanie przez nakładanie reguł. Druga poprawia zachowanie, czyniąc świat czytelnym.
Pierwsza prowadzi do biurokracji. Druga do zrozumienia.
Buduj kontekst. Usuwaj blizny. Wysyłaj agentów, którzy potrafią myśleć.
