Co oszczędza delegowanie (i czego nie oszczędza)

Gdy agent programistyczny przekazuje pytanie dotyczące zgodności do ISMS Copilot, część pracy jest wykonywana po stronie ISMS Copilot, a nie w kontekście agenta. Ta strona wyjaśnia mechanizm, co się nie zmienia, oraz jak rozliczane są obie strony. Nie określa, ile można zaoszczędzić: zależy to od orkiestratora, modelu i wykonywanej pracy.

Dlaczego kontekst agenta ma znaczenie

Agent oparty na czacie nie pamięta samodzielnie wcześniejszych tur. Na każdej turze typowy orkiestrator wysyła modelowi jego transkrypcję ponownie: instrukcje, definicje narzędzi, wcześniejsze wiadomości, odczytane pliki oraz wyniki narzędzi. Wszystko, co trafi do tej transkrypcji, jest ponownie wysyłane lub przetwarzane w późniejszych turach i może być naliczane jako użycie, z uwzględnieniem buforowania, kompresji i rozliczeń dostawcy. Własny czat ISMS Copilot działa na tej samej zasadzie, dlatego długie wątki zużywają więcej okna użycia na wiadomość.

Pytanie nie dotyczy zatem tylko kosztu pojedynczej odpowiedzi, ale także tego, co pozostaje w transkrypcji agenta po jej otrzymaniu.

Co pozostaje po stronie ISMS Copilot

Gdy praca jest delegowana, poniższe elementy pozostają po stronie ISMS Copilot, chyba że zwrócony wynik je powiela. Żądanie MCP wysłane przez agenta oraz otrzymany wynik (odpowiedź i pola takie jak ID, status, użycie i błędy) trafiają do jego transkrypcji, obok schematów narzędzi opisanych dalej:

• Materiał źródłowy ram pracy. Odniesienia do standardów i przepisów, na których ISMS Copilot opiera swoje odpowiedzi. Agent wysyła pytanie, a nie tekst ram pracy. Odpowiedź może cytować lub przywoływać istotne fragmenty.
• Wyszukiwanie. Znajdowanie odpowiednich klauzul, kontroli i artykułów dla pytania oraz zebranie kontekstu dla modelu.
• Pamięć i pliki przestrzeni roboczej. W turze z zakresem workspace_id są odczytywane po stronie ISMS Copilot. Agent ich nie ładuje, chociaż odpowiedź może wykorzystywać pochodzące z nich fakty.
• Pośrednie rozumowanie. Analiza stojąca za odpowiedzią, w tym wieloetapowa praca w trybach Think i Beyond.
• Próby redagowania. Długi tekst jest generowany po stronie ISMS Copilot. Agent otrzymuje wynik, a nie proces redagowania.
• Kopia wątku specjalisty. Kontynuacje za pomocą send_message rozwijają wątek, który ISMS Copilot zachowuje, więc agent nie wysyła ponownie wcześniejszych tur tego wątku w swoim żądaniu. Wcześniejsze wywołania narzędzi i odpowiedzi wciąż znajdują się w transkrypcji agenta, dopóki ich nie usunie.

Za co agent wciąż płaci

Delegowanie nie sprawia, że krok zgodności jest darmowy dla orkiestratora:

• Schematy narzędzi. Definicje narzędzi MCP ISMS Copilot znajdują się w kontekście agenta od momentu połączenia z serwerem, tak jak narzędzia dowolnego innego serwera MCP.
• Pytanie, które wysyła. Wszystko, co agent wpisze do create_conversation lub send_message, staje się częścią jego transkrypcji.
• Odpowiedź, którą odczytuje. Zwrócona odpowiedź jest wejściem dla modelu agenta i pozostaje w transkrypcji do końca sesji.

Odpowiedź to część, którą kontrolujesz najbardziej. Przekazuj answer_format: "brief" (ok. 150 słów) lub "decision" (rekomendacja na początku, ok. 300 słów), gdy agent potrzebuje jedynie wniosku. Gdy dostarczany dokument jest długi, niech agent zapisz go do pliku zamiast powtarzać w czacie. Zobacz Delegowanie prac GRC z agenta.

Potwierdzenie użycia

Ukończona odpowiedź w trybie Fast lub Think może zawierać obiekt usage:

{
  "usage": {
    "copilot_input_tokens": 0,
    "copilot_output_tokens": 0
  }
}

Powyższe wartości są przykładowe. Pola oznaczają:

• copilot_input_tokens i copilot_output_tokens: tokeny przetworzone i wygenerowane przez modele ISMS Copilot w tej turze.
• copilot_cache_read_input_tokens i copilot_cache_creation_input_tokens: uwzględniane jedynie, gdy dostawca modelu je raportuje.

To potwierdzenie dotyczy tylko tokenów po stronie ISMS Copilot. Nie jest to liczba tokenów agenta i nie obejmuje tego, co orkiestrator zużywa na pytanie, schematy narzędzi lub odczyt odpowiedzi. Te wartości raportuje orkiestrator. Obiekt usage jest pomijany, gdy dane nie są jeszcze dostępne (get_reply dołącza go, gdy zostaną zarejestrowane), a odpowiedzi w trybie Beyond go nie zawierają.

Gdzie rozliczane jest użycie ISMS Copilot

Nie ma oddzielnego produktu ani licznika MCP. Delegowane tury są naliczane w ramach planu czatu ISMS Copilot:

• 4-godzinne okno użycia. Tury MCP korzystają z tego samego 4-godzinnego okna sesji UTC co aplikacja czatu, w ramach budżetu lub puli organizacji. Zobacz Zrozumienie limitów użycia.
• Przekroczenie limitu. Na kwalifikujących się płatnych kontach indywidualnych (nie Essential, z wyłączoną Zaawansowaną ochroną danych) po wyczerpaniu okna agent może kontynuować jedynie po jawnej zgodzie, ponownie wysyłając żądanie z overflow_consent: true. Tura jest wówczas realizowana na ujawnionych modelach awaryjnych, do dodatkowych 2x limitu tokenów planu. Przekroczenie limitu nigdy nie jest dostępne w puli zespołowej.
• Uruchomienia Beyond. Ograniczono do 10 dziennie (UTC) w płatnych planach, 50 w planie Unlimited.

Użycie modelu przez orkiestrator jest rozliczane przez dostawcę orkiestratora, jak zwykle.

Wyniki pomiarów

Trwa praca nad powtarzalnym benchmarkiem delegowania. Opublikujemy tutaj liczby wraz z metodą i datą ich pomiaru, i nie wcześniej.