Stabilna nazwa agenta to nie ten element, który przeglądałeś: utwórz stałe powiązanie z kandydatem.

Dwóch agentów może mieć to samo imię, ale różnić się we wszystkich aspektach istotnych dla oceny. Załóżmy, że „Agent badawczy” przechodzi ocenę w poniedziałek. Do wtorku etykieta pozostaje niezmieniona, jednak jedna umiejętność została zamieniona, narzędzie otrzymało prawo do zapisu, a reguła routingu kieruje niektóre żądania inną ścieżką. Na schemacie organizacyjnym nadal jest to ten sam agent. Jako dowód na to, co zostało przetestowane, ta odpowiedź nie jest wystarczająco precyzyjna.

Etykieta wskazuje na rolę. Nie może jednak wskazać konkretnego zestawu elementów kształtujących zachowanie, które zapewniły pozytywną ocenę. Luka ta powiększa się, gdy zachowanie agenta wykracza poza pojedyncze wezwanie modelu i staje się kompozycją: model, instrukcje, umiejętności, narzędzia, uprawnienia, polityka pamięci, routowanie, elementy hook, framework oraz wszystko, co dodaje aplikacja hostująca.

Imiona służą do koordynacji, kandydaci dostarczają dowodów

Nikt nie chce, aby każda wewnętrzna wersja produktu stawała się nową, publiczną postacią z numerem seryjnym. Ludzie potrzebują imienia, które pozostanie niezmienne. Zespół składający się z agenta badawczego, agenta zajmującego się zależnościami oraz agenta wsparcia odnosi korzyści z etykiet określających, do czego służy każdy z nich i jakie ma miejsce w strukturze.

Ocena wymaga czegoś innego: jakiego konkretnego kandydata na rozwiązanie dotyczy to orzeczenie? Wyobraźmy sobie ewaluację przeprowadzoną na podstawie pojedynczego modelu, zestawu promptów, zestawu umiejętności, granic narzędzi, polityki uprawnień oraz ustawień routingu. Wszystko to, co miało znaczenie dla pomiarów, stanowi część tego, co opisuje wynik. Zmiana jednego z tych elementów może nadal wskazywać na nowego kandydata, ale już nie będzie za nim gwarancją.

Przyjazne imię może dokładnie to ukryć. Tożsamość produktu pozostaje stabilna, podczas gdy składające się na niego elementy mogą się zmieniać. Tożsamość dla ludzi zapewnia ciągłość, natomiast tożsamość dla kandydatów zapewnia precyzję.

Konfiguracja staje się materiałem poddawanym inspekcji

Obecne produkty typu agent już ujawniają elementy tego wzorca, chociaż nie ma jednolitej architektury wspólnej dla wszystkich z nich. Niektóre narzędzia umożliwiają definiowanie agentów w plikach, które zawierają spersonalizowane instrukcje, narzędzia, ograniczenia, wybrane umiejętności oraz serwery MCP, wraz z ustawieniami modelu i uprawnień; definicje specyficzne dla projektu mogą znajdować się w repozytorium. To jeden z możliwych projektów, a nie standard, ale pokazuje, że konfiguracja nie musi już być niewidocznym elementem przywoływania modelu – może być artefaktem, który można przeczytać i przeanalizować.

Kolejny wzorzec przechowuje prompty, listy narzędzi, harmonogramy, dane uwierzytelniające oraz ustawienia pamięci w Git, dzięki czemu każda zmiana przechodzi przez wniosek o pull request i pozostawia historię przeglądów, możliwość cofnięcia oraz ślad audytowy. Przykład jednej organizacji stosującej taki podejście nic nie dowodzi tego, co powinien robić każdy zespoł, ale pokazuje, że zachowanie agenta można traktować jako konfigurację podlegającą zmianom z historią w stylu oprogramowania.

Większość innych rozwiązań zmierza w tym samym kierunku. Niektóre platformy dostawców już oferują wielokrotnie używalne, wersjonowane konfiguracje agentów, chociaż te interfejsy są jeszcze w wersji beta i stale się rozwijają. Plany rozwoju protokołów wymieniają tożsamość agenta jako temat przyszłych prac, co stanowi jedynie plan, a nie już realizowane rozwiązanie. Nic z tego nie oznacza, że problem został rozwiązany. Mimo to przykłady te uzasadniają umiarkowane stwierdzenie: gdy zachowanie pochodzi z niezależnie modyfikowalnych elementów, całość wymaga własnego identyfikatora.

Części w wersjach mogą nadal tworzyć niejednoznaczną całość

Tutaj trudność staje się zwodniczo irytująca. Model ma wersję. Umiejętność ma rewizję. Repozytorium ma komit. Serwer MCP ma implementację, polityka pamięci może mieć własną wersję, a agent również może mieć wersję widoczną dla dostawcy. Każda część może mieć nazwę, podczas gdy łączny wynik pozostaje niepewny.

Rozważmy sytuacje, gdy fiksacja działa częściowo:

• Prompt jest zfiksowany, ale alias modelu się zmienia.
• Model jest zfiksowany, ale umiejętność używa najnowszej wersji.
• Umiejętność jest stała, ale aplikacja hostująca zmienia narzędzia, które udostępnia.
• Polityka uprawnień się zmienia, podczas gdy nazwa publiczna pozostaje taka sama.

System jest wersjonowany w fragmentach, a to, co faktycznie zostało uruchomione, pozostaje niejasne. Praktyka wypuszczania oprogramowania oferuje przydatną analogię, z jedną ograniczeniem: konfiguracja agenta nie musi stanowić pojedynczego pliku binarnego ani jednego ogromnego pliku manifestu. Analogia dotyczy tego, do czego odnosi się decyzja. Zespół programistyczny nie poprzestaje na stwierdzeniu „przetestowaliśmy Produkt X”, gdy istnieje kilka wersji. Nazwa produktu ułatwia koordynację, a dokładna wersja lub commit wskazują, który kandydat jest objęty danym stwierdzeniem. Przy przeglądzie agenta konieczna jest ta sama separacja, gdyż konfiguracja może znacząco zmienić zachowanie.

Trzy tożsamości lepsze niż jedna

Przymusowanie jednego identyfikatora do przenoszenia wszystkich znaczeń szybko powoduje zamieszanie. Warto oddzielić co najmniej trzy warstwy.

Tożsamość skierowana do ludzi

Rola trwała: jej nazwa, cel, właściciel, obowiązki oraz pozycja w systemie. Musi pozostać na tyle nieruchoma, aby ludzie i inne elementy mogli się wokół niej koordynować.

Tożsamość kandydata na zachowanie

To dokładny zbiór zależności kształtujących zachowanie, które zespół ocenia, zatwierdza, porównuje lub wprowadza do użycia. W zależności od architektury może odnosić się do:

• modelu, który jest uruchamiany, wraz z ustawieniami zmieniającymi jego zachowanie,
• tekstu instrukcji lub zestawu promptów,
• umiejętności przypisanych do konkretnych wersji,
• narzędzi i serwerów MCP, do których może uzyskać dostęp,
• czego może robić i co wymaga zatwierdzenia,
• sposobu przechowywania i wykorzystywania pamięci,
• reguł routingu i przekazywania zadań,
• hooków przechwytujących różne etapy cyklu życia,
• wersji narzędzia lub środowiska wykonawczego, jeśli zmienia ono zachowanie,
• Ustawienia powierzchni hosta, jeśli host kontroluje kontekst, narzędzia, zatwierdzenia lub wykonywanie.

Kluczowym słowem jest „materiał”. Celem nie jest serializacja każdej ustawienia tylko dlatego, że istnieje. Chodzi o uchwycenie zależności, których zmiana mogłaby sprawić, że twierdzenia dotyczące przeglądu, reprodukcji lub cofnięcia staną się błędne.

Tożsamość wykonywania

Nawet doskonale ustalony kandydat nie obejmuje wszystkiego, co wpływa na jedno wykonywanie. Wykonywanie zależy również od danych wprowadzanych przez użytkownika, zmiennej zawartości pamięci, pobranego kontekstu, stanu zewnętrznego systemu, danych w czasie rzeczywistym, uprawnień, decyzji ludzkich oraz własnego niedeterminizmu modelu. Tam, gdzie mają znaczenie, należą one do linii przodków wykonywania.

Trzymanie warstw oddzielnie zapobiega dwóm przeciwnym błędom: traktowaniu przyjaznego nazwy jako dokładnej tożsamości technicznej oraz traktowaniu zrzutu konfiguracji tak, jakby rejestrował on każdy fakt dotyczący aktualnego wykonywania.

Co zasługuje na zamrożenie

Ile należy zamrozić, zależy od tego, co jest w grze. Niskorozrywkowy osobisty asystent może wystarczyć przy komitcie w repozytorium lub wersji dostawcy. Proces pracy w środowisku produkcyjnym z dostępem do zapisu wymaga większych środków. W celu oceny zapisz wszystko, co miało znaczenie dla pomiaru: model, prompt, umiejętności, narzędzia, uprawnienia, ścieżki przekierowania oraz stan systemu.

Na początku pomiń schemat i użyj powyższej listy jako listy kontrolnej. Dla każdego punktu zastanów się, czy nadal nazwałbyś go przeanalizowanym kandydatem po jego zmianie. Jeśli uczciwa odpowiedź brzmi „nie”, ten punkt powinien znaleźć się w identyfikatorze kandydata lub w jego historii rozwoju.

Wartości wrażliwe nie muszą być kopiowane do rekordu. Konfiguracja może wskazywać na tajemniczy referencję, klasę uprawnień lub granicę dostępu, bez konieczności przekształcania manifestu w źródło wycieku tajemnic. Dokładna identyfikacja powinna poprawić możliwości audytu i nie powinna powodować gorszych problemów bezpieczeństwa.

Ocena, debugowanie i odwracanie działań mają wspólną potrzebę

Wydają się to trzy odrębne kwestie operacyjne, ale każda z nich wymaga obiektu umożliwiającego odzyskanie stanu.

Ocena. Każda ocena stanowi stwierdzenie dotyczące jakiegoś obiektu. Gdy ten obiekt nie może zostać dokładnie zrekonstruowany, ocena może przetrwać dłużej niż to, co opisywała. Nie każda modyfikacja unieważnia każdą ocenę: poprawa błędu ortograficznego w niepowiązanym umiejętności prawie w ogóle nie wpływa na kryteria rozumowania, podczas gdy zmiana uprawnień może nie wpłynąć na jakość tekstu, ale zadecydować o sprawdzeniu bezpieczeństwa. Ważne jest to, co było mierzone, a decyzja musi być podejmowana otwarcie, aby stała nazwa nie mogła ukryć istotnych zmian.

Debugowanie. Bez określonej tożsamości konfiguracji badanie incydentu przekształca się w przeszukiwanie kolejnych warstw. Plik z informacjami, historia konsoli, rejestr narzędzi, dziennik implementacji, zrzut pamięci, gałąź oraz transkrypcja mogą każdy podawać prawidłowe dane dotyczące swojej warstwy, podczas gdy cała sytuacja pozostaje niejasna. Dokładna referencja kandydata ułatwia postawienie kluczowego pytania: czy ten nieudany proces rzeczywiście wykorzystywał kandydata, o którym wszyscy przypuszczali? Jeśli tak, należy sprawdzić stan i zachowanie wykonywania. Jeśli nie, to właśnie ta niezgodność stanowi odkrycie. Nieoczekiwany wynik od przyjętego kandydata oraz proces, który go w ogóle nie wykorzystał, to odrębne rodzaje awarii.

Odwrócenie zmian. Załóżmy, że zatwierdzony kandydat łączył w sobie jeden prompt, jeden zestaw umiejętności, jedną politykę uprawnień, jedną zasadę routingu oraz jeden okres działania. Samo przywrócenie promptu nie oznacza, że powrócił stary kandydat. Zespoły powinny zastanowić się, czy mogą odbudować całość ostatniego zatwierdzonego kandydata, czy też tylko odwołać tę część, która przykuła ich uwagę. Pierwsze rozwiązanie to prawdziwe odwrócenie zmian, natomiast drugie to edycja oparta na nadziei.

Ostatni element jest łatwy do przeoczenia. Znalezienie „ostatniego przyjętego kandydata” wymaga wyszukiwania i działa tylko wtedy, gdy kandydaci posiadają rejestr sukcesji. Dokładna tożsamość pokazuje, czym był każdy kandydat, ale nie wskazuje, który zastąpił którego ani co zmieniło się pomiędzy nimi. Jeśli odwrócenie zmian ma znaczenie, każdy kandydat powinien wskazać swojego poprzednika i wymienić istotne różnice, aby przywrócenie nie wymagało długich poszukiwań.

Nie pozwól, by konfiguracja przytłoczyła proces działania

Kusząca reakcja przesadna to ogromny zrzut obrazu obejmujący wszystko. To przynosi nowe problemy. Pamięć zmienna, pobrane dokumenty, dane wprowadzane przez użytkownika, stan zewnętrznego API, zegar oraz dane uwierzytelniające – to wszystko wpływa na przebieg procesu. Niektóre z tych elementów są wrażliwe, inne powinny być dynamiczne, a jeszcze inne nie mogą być odtworzone dokładnie, więc nie wszystkie mieszczą się w ramach danego kandydata.

Czystsze rozgraniczenie wygląda następująco:

• Szczegół konfiguracji rejestruje, które zależności wpływające na zachowanie zostały wybrane.
• Szczegół przebiegu rejestruje, która realizacja wykorzystała danego kandydata oraz wszystkie istotne dane wejściowe o zmiennej wartości.
• Szczegół zatwierdzenia rejestruje dokładnego kandydata, do którego zastosowano zatwierdzenie.

Każda warstwa może wskazywać na inną bez łączenia się w jeden artefakt. Ta granica zapobiega również temu, by „dokładna tożsamość” przerodziła się w roszczenie, którego nie mogą poprzeć dowody. Określenie kandydata nie czyni modelu deterministycznym, nie zamyka go w ramach zewnętrznych systemów ani nie gwarantuje identycznego wyniku później. Sprawia jedynie, że przedmiot roszczenia można odzyskać, a to już bardzo pomaga.

Test składający się z pięciu pytań

Gdy nazwany agent ma tak dużą wagę, by poddać go ocenie lub udostępnić, zadaj następujące pytania:

1. Co może się zmienić bez zmiany nazwy? W większości systemów jest to więcej, niż ludzie się spodziewają.
2. Które z tych zmian mogłyby unieważnić to konkretne roszczenie dotyczące oceny? Zależy to od tego, czy decyzja dotyczy jakości, bezpieczeństwa, uprawnień, niezawodności, kosztów czy gotowości.
3. Czy zaakceptowaną kompozycję można później przywrócić? Wersja jest przydatna tylko wtedy, gdy jej zależności prowadzą do czegoś konkretnego.
4. Czy nieudany przebieg można powiązać z tą kompozycją? Jeśli nie, debugowanie nie może odróżnić potencjalnego błędu od potencjalnej dewiacji.
5. Czy rollback może przywrócić całą kompozycję, a nie tylko jedną jej część? Jeśli nie, system posiada wersjonowane elementy bez niezawodnej tożsamości wydania.

Żadne z tego nie wymaga specjalnych procedur przy każdej edycji. Potrzebna jest precyzja, gdy twierdzenie zaczyna mieć konsekwencje. Ponieważ zachowanie agenta jest budowane na bazie modelu i staje się modułowe, przenośne, wersjonowane lub wymienne, konfiguracja nie jest już tylko dodatkowym ustawieniem. Stanowi ona część wykonywalnego kandydata. Nazwa może pozostać bez zmian, ale dane muszą wiedzieć, co się zmieniło.

Literatura pokrewna

• Dlaczego wskaźniki dokładności agentów wprowadzają w błąd: pass^k, perturbacje i iniekcja błędów — Dlaczego pass@1 ukrywa niewiarygodne agenty AI oraz jak pass^k, zestawy perturbacji wejściowych i iniekcja błędów ujawniają braki w spójności, stabilności i odporności na błędy.
• Dlaczego agenci, które imponują w demonstracjach, zawodzą w produkcji, i co zamiast tego należy zbudować — Punkty awarii, kompromis między jednym a wieloma agentami, praktyki projektowe takie jak ponawianie prób i mechanizmy awaryjne oraz pełny obraz kosztów działania agenta AI poza opłatami za tokeny.

Praktyczne wskazówki: Projektowanie cache'u dla agentów AI: Caching wewnątrz pętli — Szczegółowy przewodnik po Praktycznych wskazówkach: Projektowanie cache'u dla agentów AI: Caching wewnątrz pętli: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.