Jak działa ElevenAgents Architect

Co ElevenAgents Architect wie na początku rozmowy, jak analizuje sprawy i jak zamienia pytanie w zweryfikowaną zmianę.

Omówienie

Rozmowa z ElevenAgents Architect działa jako rozmowa z ElevenAgents w czasie rzeczywistym, na tym samym silniku, który obsługuje tworzone przez ciebie agenty. Narzędzia Architect działają w przeglądarce w ramach twojej zalogowanej sesji. Każde narzędzie wywołuje te same API ElevenAgents, których używa panel, więc każdy odczyt i zapis jest sprawdzany pod kątem twoich uprawnień. Zobacz Uprawnienia, zatwierdzenia i wersje robocze.

Co ElevenAgents Architect wie domyślnie

Na początku każdej rozmowy Architect otrzymuje:

Twoje konto i workspace: twój plan, workspace i użycie.
Twoją lokalizację: stronę, a gdy jesteś w agencie — także tego agenta i otwartą gałąź. Na pasku bocznym Architect otrzymuje też zrzut strony oraz aktualizację przed każdą wiadomością, jeśli strona się zmieniła.
Podsumowanie agenta: tworzone przez ElevenLabs, gdy jesteś w agencie. Obejmuje nazwę i właściciela agenta, jego gałęzie i podział ruchu między nimi, liczbę połączeń z ostatnich 7 dni, stan wersji roboczej, połączone agenty, procedury, informację o skonfigurowanych testach oraz gałęzie, które możesz edytować.
Kontekst agenta: dokument agents.md agenta, udostępniony wszystkim osobom tworzącym agenta. Zobacz Dostosowywanie Architect.
Twoje preferencje: twój osobisty dokument user.md, który dotyczy każdego tworzonego przez ciebie agenta.
Kontekst przekazany przez punkt wejścia: na przykład nieudane testy, ustalenie Spotlight lub problem. Zobacz Rozpoczynanie rozmowy.
Wcześniejsze wiadomości z tego czatu.

Architect nie zaczyna od pełnej konfiguracji agenta, jego transkrypcji, wyników testów, danych Spotlight ani innych twoich czatów z Architect. Odczytuje je za pomocą narzędzi, gdy wymaga tego zadanie. Dzięki temu każda rozmowa pozostaje skupiona, a Architect zawsze pracuje na aktualnych danych zamiast na nieaktualnej kopii.

Analizy i bezpośrednie polecenia

Architect inaczej obsługuje dwa rodzaje próśb.

Bezpośrednie polecenia wskazują zmianę, na przykład „Dodaj zabezpieczenie blokujące rozmowy o cenach konkurencji” albo „Skróć pierwszą wiadomość”. Architect odczytuje odpowiednią konfigurację, wprowadza zmianę i informuje, co przygotował w wersji roboczej. W domyślnym trybie zatwierdzania zmiany konfiguracji agenta są przygotowywane w wersji roboczej bez pytania. Działania wpływające na ruch na żywo lub wspólne zasoby czekają na twoje zatwierdzenie.

Analizy zadają pytanie bez wskazywania rozwiązania, na przykład „Dlaczego rozmowy o zwrocie są eskalowane?” albo „Jak poprawić rozwiązywanie spraw zwrotów?”. Architect przeprowadza analizę, zanim cokolwiek zmieni:

Tworzy listę zadań analizy, która pozostaje widoczna nad polem wpisywania w miarę wykonywania kolejnych pozycji.
Zaczyna od niedrogich sygnałów, takich jak liczba rozmów, tematy i wyniki oceny, zanim odczyta pojedyncze transkrypcje.
Analizuje rozmowy równolegle i grupuje ustalenia według przyczyny źródłowej.
Jego tok rozumowania jest widoczny. Każdy krok można zwinąć do Myślenie przez Ns i rozwinąć.
Przedstawia ustalenia, w tym liczbę rozmów, które faktycznie przeczytał. Nie przedstawia próbki jako pełnego obrazu.

Tryb planowania

Przy większych zmianach przełącz pole wpisywania na Plan (naciśnij Shift+Tab, aby przełączać tryby). W trybie planowania Architect analizuje dane za pomocą narzędzi tylko do odczytu, pisze plan, który możesz obserwować podczas tworzenia, a następnie prosi o Zatwierdź plan lub Odrzuć. Nie wprowadza żadnych zmian, dopóki go nie zatwierdzisz. Jeśli odrzucisz plan z komentarzem, Architect go poprawi i zapyta ponownie.

W pełnoekranowej karcie Architect plan pojawia się w panelu nad polem wpisywania. Na pasku bocznym pojawia się jako karta na czacie.

Przykład: poprawa rozwiązywania spraw zwrotów

Ten przykład pokazuje jedną rozmowę — od ogólnego pytania po zmianę gotową do sprawdzenia. Pokazano nazwy narzędzi, aby można było dopasować każdy krok do tego, co pojawia się w rozmowie. Architect sam wybiera kroki, więc rzeczywista rozmowa może różnić się kolejnością i szczegółowością.

Prośba wysłana z karty Architect agenta:

Jak poprawić rozwiązywanie spraw zwrotów?

Zaplanuj analizę

Architect tworzy listę zadań (write_todos): zmierzyć problem, znaleźć nieudane rozmowy o zwrotach, zidentyfikować przyczyny źródłowe, zaproponować i przetestować rozwiązanie.

Zmierz problem

Architect odczytuje tematy agenta (get_agent_topics, get_topics_summary), aby znaleźć temat zwrotów i jego wskaźnik sukcesu, a następnie zlicza i wyświetla ostatnie rozmowy o zwrotach, które nie przeszły oceny (count_conversations, list_conversations).

Przeczytaj rozmowy

Architect przeszukuje transkrypcje pod kątem próśb o zwrot (search_conversation_messages, semantic_search_conversations), a następnie równolegle analizuje grupę nieudanych rozmów (analyze_conversation_subagent). Każda analiza wskazuje, czego chciał użytkownik, gdzie agent popełnił błąd i w której turze to nastąpiło.

Znajdź przyczynę źródłową

Architect porównuje niepowodzenia z bieżącą konfiguracją (get_agent_config, list_procedures, get_procedure). Zgłasza ustalenie, na przykład: „W 31 z 40 nieudanych rozmów o zwrocie agent wywołał lookup_order przed zapytaniem o numer zamówienia, otrzymał błąd i przekazał sprawę dalej”.

Wprowadź zmianę w gałęzi

Architect tworzy gałąź (create_branch), aby odizolować zmianę od agenta działającego na żywo. Następnie edytuje procedurę zwrotu (update_procedure), aby pytać o numer zamówienia przed jego wyszukaniem. Zmiana jest przygotowywana w twojej wersji roboczej w tej gałęzi. Dla osób dzwoniących na żywo nic się nie zmienia.

Napisz testy dla zmiany

Architect pisze testy odzwierciedlające problem: symulację osoby proszącej o zwrot bez podania numeru zamówienia (create_simulation_test), test wywołania narzędzia sprawdzający, czy lookup_order nie jest wywoływane jako pierwsze (create_tool_test), oraz test wygenerowany na podstawie jednej z rzeczywistych nieudanych rozmów (generate_test_from_conversation). Architect symuluje narzędzia wywołujące skutki uboczne, więc nie są realizowane prawdziwe zwroty.

Uruchom testy przed zmianą i po niej

Architect uruchamia testy dla agenta bez zmiany (run_tests w oryginalnej gałęzi lub run_agent_tests z include_draft: false), a potem dla wersji roboczej ze zmianą (run_agent_tests) i odczytuje wyniki (get_test_suite_summary, get_test_suite_failures). Oczekiwany wynik: nowe testy nie przechodzą bez zmiany, a przechodzą po jej wprowadzeniu. Jeśli testy nadal nie przechodzą, Architect odczytuje błędy, poprawia zmianę i uruchamia je ponownie.

Przedstaw zmianę

Architect podsumowuje przyczynę źródłową, zmianę i wyniki testów oraz otwiera okno publikacji (request_draft_publish). Sprawdzasz różnice i wybierasz Opublikuj, co zapisuje zmianę jako nową wersję w gałęzi. Architect nie może publikować za ciebie.

Otwórz propozycję

Architect odczytuje historię gałęzi i podgląd scalenia (get_branch_history, merge_branch_preview) oraz otwiera propozycję scalenia do main (create_merge_proposal). Opis zawiera trzy sekcje: Podsumowanie, Testowanie i Jak sprawdzić, napisane na podstawie rzeczywistych commitów i uruchomień testów. Architect może zasugerować osoby sprawdzające (suggest_merge_proposal_reviewers), ale to ty je wybierasz.

Zaproponuj stopniowe wdrożenie

Architect proponuje skierowanie niewielkiej części ruchu na żywo, zwykle 5%, do gałęzi podczas sprawdzania propozycji (set_traffic_split). Zmienia to ruch na żywo, więc wymaga twojego zatwierdzenia.

Walidacja odbywa się w rozmowie, zanim zostaniesz poproszony o publikację lub sprawdzenie czegokolwiek. Gdy propozycja trafia do osoby sprawdzającej, testy, które uzasadniły zmianę, są już dołączone do agenta i uruchomione w gałęzi. Zobacz Propozycje i walidacja, aby dowiedzieć się, co widzi osoba sprawdzająca.

Uruchomienie testów przed zmianą i po niej to dobra praktyka, ale Architect nie robi tego automatycznie przy każdej zmianie. Aby mieć pewność, że to zrobi, poproś o to wprost, na przykład: „Pokaż mi nowe testy, które nie przechodzą w main, a przechodzą w gałęzi”.

Ślad pracy Architect — Ślad pracy nad prośbą z każdym wywołaniem narzędzia przez Architect

Polecenia ukośnikowe

Wpisz / w polu wpisywania, aby zobaczyć polecenia dostępne na bieżącej stronie.

Polecenie	Działanie
`/start`	Konfiguruje kontekst tego agenta (`agents.md`), aby Architect znał twoje cele.
`/generate`	Tworzy nowego agenta na podstawie opisu.
`/debug`	Diagnozuje ostatnie nieudane rozmowy.
`/test`	Uruchamia testy i podsumowuje wyniki.
`/explain`	Wyjaśnia prostym językiem, co robi ten agent.
`/optimize`	Sugeruje ulepszenia promptu i konfiguracji.
`/review`	Sprawdza działanie agenta i znajduje ulepszenia.
`/branch`	Tworzy nową gałąź dla tego agenta.
`/experiment`	Tworzy gałąź i wdraża ją jako test A/B.
`/rollback`	Sprawdza ostatnie zmiany konfiguracji i cofa je w razie potrzeby.
`/remember`	Zapisuje informację dla agenta jako dokument bazy wiedzy.
`/dashboard`	Tworzy na czacie własny panel analityczny.
`/clear`	Czyści tę rozmowę i zaczyna od nowa.
`/feedback`	Wysyła prywatną opinię o tej sesji do ElevenLabs.

Większość poleceń działa tylko wtedy, gdy jesteś w agencie. /clear i /feedback nie są dostępne na stronie głównej karty Architect.

Panele na czacie

Architect może utworzyć panel w rozmowie, aby odpowiedzieć na pytanie za pomocą danych, na przykład „Podziel eskalacje z tego tygodnia według przyczyny i pokaż trend”. Użyj /dashboard lub poproś o niego bezpośrednio.

Architect zbiera dane za pomocą narzędzi, przetwarza je za pomocą kodu i renderuje panel z tych samych kafelków metryk, wykresów, list i kart tekstowych co Spotlight. Panel może zawierać:

Kafelki metryk z główną wartością, zmianą i wykresem sparkline.
Wykresy: powierzchniowe, liniowe, słupkowe, skumulowane powierzchniowe, pierścieniowe oraz rankingi słupkowe dla zestawień top-N.
Listy z etykietami statusu, datami i linkami do stron w ElevenAgents, na przykład pojedynczych rozmów.
Karty tekstowe z ustaleniami i rekomendacjami.

W pełnoekranowej karcie Architect panele są renderowane bezpośrednio w rozmowie. Na pasku bocznym otwierają się w panelu obok czatu.

Dane panelu są przechowywane tylko w pamięci karty przeglądarki, w której został utworzony, i nigdy nie są zapisywane wraz z czatem. Po odświeżeniu strony, otwarciu czatu w innej karcie lub utworzeniu kilku dużych paneli starszy panel wyświetli komunikat zamiast danych. Poproś Architect o jego ponowne utworzenie. Panele są migawkami tylko do odczytu. Nie mają filtrów i nie aktualizują się na żywo.

Uruchamianie kodu

Architect może uruchamiać krótkie programy w Pythonie, aby zliczać, grupować i porównywać dane z narzędzi, na przykład obliczać tygodniowe wskaźniki rozwiązania spraw dla kilkuset rozmów. Kod działa w sandboxie w przeglądarce i ma dostęp tylko do standardowej biblioteki Pythona. Nie ma dostępu do sieci ani twojego konta ElevenLabs, a limit czasu wynosi 20 sekund. Wykonywanie kodu jest wdrażane stopniowo i może nie być dostępne w każdym workspace.

Duże odpowiedzi

Gdy narzędzie zwraca więcej danych, niż mieści się w rozmowie, na przykład długą listę rozmów, Architect zachowuje pełną odpowiedź w pamięci karty przeglądarki i pracuje z podsumowaniem. Może na żądanie przeszukać i odczytać pozostałe dane. Informacja przy wywołaniu narzędzia pokazuje, kiedy tak się stało. Te odpowiedzi nigdy nie są zapisywane ani przesyłane.