Rozkład kontekstu w standardowej uprzęży

Standardowa uprząż rozprowadza kontekst między komponentami obsługującymi żądanie. Każdy komponent działa we własnym kontekście, a otoczka testowa nie uzgadnia automatycznie kontekstu na najwyższym poziomie. To rozdzielenie zapewnia elastyczność, ale może powodować duplikaty wiadomości lub nieodebrane odpowiedzi, jeśli informacje nie są zwracane wyraźnie przez niezależne komponenty.

Ten artykuł wyjaśnia, dlaczego kontekst jest rozproszony, czym różni się mechanizm GitHub Copilot, jak kontekst przepływa między warstwą orkiestracji agenta a komponentem oraz do czego każdy komponent ma dostęp i co może zwracać. Wykorzystaj te informacje do identyfikacji luk kontekstowych i projektowania agentów, którzy świadomie zarządzają kontekstem.

Poniższy diagram ilustruje, jak kontekst i komunikacja przepływają między warstwą orkiestracji, poszczególnymi komponentami i użytkownikiem w standardowej uprzęży.

Diagram pokazujący kontekst i komunikację przekazywaną między warstwą orkiestracji, każdym komponentem i użytkownikiem w standardowym agencie harness.

Note

Ten artykuł opisuje funkcje i działanie standard harness. Dowiedz się, jak uzyskać dostęp do standardowych funkcji, korzystając z artykułu Dostęp do standardowych agentów i przepływów agentów.

Środowisko uruchomieniowe wszystko, co utworzono w Copilot Studio, a wybrany model zapewnia rozumowanie i generowanie. Środowisko uruchomieniowe to środowisko działające między tymi dwoma elementami: decyduje, kiedy wywołać model, które komponenty do niego wysłać, interpretuje to, co model zwraca, i wywołuje odpowiednie narzędzia. Dowiedz się więcej o uprzężach Copilot Studio.

Dlaczego standardowe środowisko uruchomieniowe rozprowadza kontekst

Standardowa uprząż jest zaprojektowana z myślą o elastyczności:

  • Orkiestruje zadania i wspiera transakcyjne przypadki użycia.
  • Równoważy deterministyczną kontrolę i AI poprzez zmienne, wyzwalacze i specjalistyczne funkcje.
  • Rozdziela sterowanie między komponenty, takie jak tematy, wiedza, agenci podrzędni, agenci powiązani oraz narzędzia.
  • Obsługuje wiele opcji uwierzytelniania, kanałów i integracji.

Rozdzielenie pracy na niezależne komponenty zapewnia elastyczność, ale może powodować luki w kontekście:

  • Warstwa orkiestracji agentów przekazuje sterowanie podczas wywołań niektórych komponentów.
  • Podczas działania komponentu warstwa orkiestracji nie widzi komunikatów, które komponent wysyła użytkownikowi.
  • Warstwa orkiestracji nie uzgadnia kontekstu na najwyższym poziomie.

Jeśli projekt nie uwzględnia kontekstu agenta, pojawiają się luki, a prośby mogą wydawać się nieodpowiedziane. Te luki mogą powodować powielanie lub niedołączenie odpowiedzi.

Jak różni się uprząż GitHub Copilot

Warstwa orkiestracji środowiska uruchomieniowego GitHub Copilot pozwala uniknąć niedopasowania kontekstu, ponieważ jako jedyna komunikuje się z użytkownikiem. Nigdy nie pozwala połączonemu agentowi przejąć komunikacji:

  • Pętla rozumowania i komunikacji działa bez celowego zarządzania kontekstem.
  • Powiązane komunikaty agentów przechodzą przez warstwę AI elementu nadrzędnego w każdej turze.

Warstwa orkiestracji środowiska uruchomieniowego GitHub Copilot również obsługuje rozmiar kontekstu inaczej, co sprawia, że jego rozmiar kontekstu jest o rzędy wielkości większy niż w przypadku standardowego środowiska uruchomieniowego:

  • Ma bezpośredni dostęp do kontekstu modelu.
  • Może używać kompaktowania.
  • Może zapisać dane i pliki do swojego kontenera piaskownicy Bash.

Jak kontekst przekazuje się komponentom i wraca do warstwy orkiestracji

Aby skutecznie zarządzać kontekstem w standardowej infrastrukturze, należy uwzględnić zarówno to, co warstwa orkiestracji przekazuje komponentowi, jak i to, co komponent zwraca.

Kontekst przechodzi do komponentów na dwa sposoby:

  • Jawne wejścia i żądania: Warstwa orkiestracji wypełnia wejścia każdego komponentu z jego aktywnego kontekstu i przekazuje żądanie zgodnie z projektem.

  • Kontekst rozmowy ukryty: Warstwa orkiestracji przekazuje także dłuższy kontekst rozmowy komponentom takim jak wiedza oraz subagentom bez wyraźnej konfiguracji. Należy zauważyć, że agent podrzędny zawsze otrzymuje kontekst konwersacji agenta nadrzędnego. Połączony agent ma ustawienie, które go obejmuje lub wyklucza. Narzędzie lub przepływ otrzymuje tylko dane wejściowe.

Komponent przesyła informacje z powrotem do warstwy orkiestracji na dwa sposoby:

  • Jawne wyjścia i odpowiedzi zgodnie z założeniami.
  • Kontekst ukryty z niektórych komponentów.

To, co komponent albo tylko pokazuje użytkownikowi, albo tylko przechowuje we własnych zmiennych, może nigdy nie dotrzeć do warstwy orkiestracji, chyba że wróci jedną z tych dwóch dróg.

Ukryte przekazywanie informacji powoduje około połowy przypadków z duplikatami lub niewykorzystanymi odpowiedziami, ponieważ komponent może zareagować na żądanie, które nigdy nie zostało mu wyraźnie przekazane.

Jak kontekst różni się między komponentami

Rozmowa widoczna przez użytkownika i kontekst warstwy orkiestracji się pokrywają, ale nie są tym samym. Poniższe zasady dotyczą tego, co trafia do kontekstu warstwy orkiestracji z wywołania komponentu:

  • To, co komponent zachowuje dla siebie, pozostaje ukryte. Zmienne tematu i konwersacji wieloetapowych w podagentach znajdują się w komponencie. Warstwa orkiestracji widzi je tylko wtedy, gdy są zwracane jako wyjścia.

  • Zwracane są tylko dwa typy informacji. Warstwa orkiestracji otrzymuje od komponentu jawnie zdefiniowane dane wyjściowe, które zostały zaprojektowane, oraz kontekst niejawny. Komponent, który wykonuje pracę, ale nic nie zwraca, może sprawić, że warstwa orkiestracji nie będzie wiedzieć, co się stało.

Każdy komponent ma swój własny kontekst lub punkt widzenia. Warstwa orkiestracji wykorzystuje swój aktywny kontekst, aby wybierać kroki i generować dane wejściowe. Agent połączony ma własną warstwę orkiestracji, własne instrukcje oraz własne wewnętrzne narzędzia i odwołania do wiedzy.

Użyj poniższej tabeli, aby zadać precyzyjne pytanie: Który składnik ma dany fakt w swoim aktywnym kontekście?

Punkt widzenia Ma w swoim aktywnym kontekście Można pisać do panelu czatu Może zostać zwrócone jako kontekst
Warstwa orkiestracji Żądanie użytkownika, kontekst rozmowy, opisy komponentów, opisy wejść, opisy wyników, stan planu, ukryte odpowiedzi (ale nie to, czy ukryte informacje zostały użytkownikowi pokazane) Tak. Własne pytania i odpowiedzi. Własne pytania, odpowiedzi, rozumowanie i plan.
Temat Zmienne tematowe, aktualny stan węzła Tak. Za pomocą węzłów komunikatów, węzłów pytań oraz pytania za pomocą karty adaptacyjnej. Wyniki tematów i niejawne wymiany komunikatów, które nadal mogą powodować duplikację.
Narzędzie lub przepływ pracy Wejścia generowane przez warstwę orkiestracji Nie. Dane wyjściowe narzędzia lub przepływu.
Krok wiedzy Żądanie użytkownika oraz bieżący kontekst jego agenta Nie. Pisze do swojego agenta, nie do panelu czatu. To jest odpowiedź.
Węzeł odpowiedzi generatywnych (w temacie) Co jest przesyłane na jego wejściu oraz kontekst jego agenta Tak. Bezpośrednio lub do zmiennej tematu. Nie jest to wyraźnie określone, może się powtarzać.
Subagent (agent podrzędny lub połączony agent) Jego początkowe żądanie, wraz z danymi wejściowymi dostarczonymi przez element nadrzędny oraz wszelkim dołączonym kontekstem elementu nadrzędnego, w kontekście własnej warstwy orkiestracji Tak, jeśli jest skonfigurowany lub poinstruowany, aby odpowiadać bezpośrednio. Odpowiedź i jej efekty.

Ważna

Tematy: Kontekst ukryty zwracany przez tematy obejmuje tylko informacje w formie tekstu, ale nie to, czy użytkownik je zobaczył. Informacje w formie tekstu zwykłego mogą pochodzić z węzłów wiadomości, węzłów pytań, zawartości kart Adaptive Card oraz odpowiedzi wpisywanych przez użytkownika. Jednak przyciski akcji karty adaptacyjnej i interakcje użytkowników z nimi nie sięgają standardowego kontekstu środowiska uruchomieniowego. Obsługa karty adaptacyjnej powoduje większość niezgodności kontekstu. Nie polegaj na treści karty jako na kontekście. Zamiast tego zwróć wszelkie informacje, które będą potrzebne na późniejszym etapie, jako dane wyjściowe tematu i ustaw dane wyjściowe na stan Odpowiedziano. Dowiedz się więcej w artykule Projektowanie tematów jako miniagentów, którzy unikają duplikowania wiadomości.

Agenci podrzędni: Gdy kontekst nadrzędny jest przekazywany połączonemu agentowi, może wpływać na każde użycie narzędzia, każdy temat i każde odwołanie do wiedzy, z których ten agent korzysta. Jeśli dołączony kontekst nadal zawiera prośbę, na którą najwyraźniej nie udzielono odpowiedzi, połączony agent może spróbować to nadrobić i odpowiedzieć na nią ponownie. Agent potomny ma to samo ryzyko, ale z mniejszą kontrolą. Działa wewnątrz rodzica i zawsze otrzymuje kontekst rozmowy rodzica, bez ustawienia wykluczającego go. Dowiedz się więcej w Projektuj subagentów, którzy unikają duplikatów wiadomości.

Następny krok

Mając na uwadze ten model kontekstowy, kolejny artykuł z tej serii wyjaśnia, dlaczego ten model powoduje duplikaty wiadomości i sugeruje wzorce projektowe, aby im zapobiec.

Projektuj najlepsze praktyki, aby unikać duplikatów wiadomości

  • Last updated on