Wersja robocza i publikacja

Dlaczego zmiana konfiguracji bota nie działa od razu, co zamraża publikacja i jak sprawdzić, że bot jest gotowy.

To jedna rzecz na tym serwerze, na której najłatwiej się przejechać: zapis konfiguracji trafia do wersji roboczej. Bot dalej prowadzi rozmowy na ostatniej opublikowanej wersji, dopóki nie wywołasz publish_bot_config.

update_bot_config   →  zmienia tylko WERSJĘ ROBOCZĄ
publish_bot_config  →  zamraża roboczą jako wersję N i uruchamia ją na żywo

Dlatego opis każdego narzędzia zapisującego konfigurację niesie to samo zdanie — agent nie przeczyta tej strony, a milcząca porażka jest droga: agent edytuje, melduje „gotowe", bot dalej działa po staremu i nikt się nie orientuje, aż rozmowa pójdzie źle.

Podgląd bota to nie wyjątek

Podgląd jest zwykłym zleceniem rozmowy, więc od pierwszej publikacji uruchamia opublikowany snapshot, a nie Twoje niezapisane zmiany. Bot, który nigdy nie był publikowany, nie ma czego przypiąć — wtedy podgląd głosowy i tekstowy w przeglądarce działa na wersji roboczej, ale prawdziwe połączenie telefoniczne jest odmawiane do czasu publikacji.

Co publikacja zamraża, a czego nie

Zamraża: agentPromptText, ustawienia modeli, greetingConfig, channelSettings (powitanie czatu, komunikat przekazania i tekst blokady), guardrailsConfig, toolsConfig, turnTakingMode, promptVariableMetadata i cały łańcuch analizy po rozmowie.

channelSettings zapisujesz przez update_bot_config i odczytujesz przez get_bot_config. Dla czatu na stronie webChat.greeting zastępuje wspólne powitanie; handoffMessage to komunikat przy przekazaniu do człowieka; guardrailFallbackMessage to zdanie, które gość widzi po zablokowaniu — nie kopiuj tu formułki z rozmowy telefonicznej.

Nie zamraża: workflow i źródła wiedzy. One docierają do kolejnej rozmowy same, więc publikacja nie jest do nich ani potrzebna, ani wystarczająca. Aktywujesz workflow przez activate_workflow, a źródło wiedzy działa od razu po dodaniu.

Publikacja jest tania i odwracalna

Każda publikacja to numerowana wersja z opcjonalną etykietą. list_config_versions pokazuje je wszystkie, z isLive przy tej, która obowiązuje. rollback_bot_config przywraca dowolną z nich — i przestawia wskaźnik wersji na żywo w tym samym wywołaniu, więc nie wymaga kolejnej publikacji.

Publikacja wymaga agentPromptText i ustawień modeli, które create_bot zapisuje w bocie przy tworzeniu. Niekompletna wersja robocza jest odrzucana z listą dokładnie tych pól, których brakuje. Jeśli na tej liście jest ustawienie modelu (modelConfig, remarksLlmModelId), zgłoś to przez create_support_ticket — modele konfiguruje zespół Mediflo. remarksOutputSchemaJson jest opcjonalne: bot opublikowany bez niego wyciąga tylko zawsze włączone pola analizy systemowej Mediflo (podsumowanie, sentyment, czerwone flagi). Te pola i tak wstrzykujemy do każdego schematu, który podasz — nie da się ich usunąć ani przedefiniować.

Odpowiadające endpointy REST: PATCH /bots/{botId}/config, POST /bots/{botId}/config/publish, GET /bots/{botId}/config/snapshots, POST /bots/{botId}/config/rollback.

Nowy bot jest już skonfigurowany

create_bot zapisuje w nowym bocie rekomendowane modele (rozpoznawanie mowy, model językowy, synteza głosu, wykrywanie tury, redukcja szumu), rekomendowany turnTakingMode i domyślny model analizy po rozmowie — wszystko w ramach tworzenia. Nie musisz ustawiać żadnego z nich. Twoje zostaje: prompt i przebieg rozmowy.

Modele konfiguruje Mediflo

Wybór modeli i ich parametrów należy do zespołu Mediflo. modelConfig i model analizy po rozmowie nie są częścią kontraktu dla Twoich kluczy: get_bot_config ich nie zwraca, a update_bot_config odrzuca ich zmianę. Jeśli potrzebujesz innego ustawienia, zgłoś to przez create_support_ticket.

get_recommended_defaults zwraca pozostałą część zestawu — ten sam obiekt, który GET /model-catalog publikuje jako data.recommendedDefaults: rekomendowany turnTakingMode i ustawienia wyszukiwania w bazie wiedzy. Przydaje się do dwóch rzeczy: żeby zobaczyć, z czego bot wystartował, i żeby podciągnąć starszego bota do aktualnej rekomendacji przez update_bot_config.

To dane, nie stałe

Czytaj te wartości w momencie konfiguracji, zamiast kopiować je do własnego kodu. Wtedy zmiana po naszej stronie dociera do Twoich botów, zamiast zostać przypięta do stanu z dnia integracji.

Pisząc prompt, zacznij od get_prompting_guidance. Zwraca dwa bloki: general dla telefonu (krótka mowa, bez list) i chat dla czatu na stronie (gość czyta odpowiedź; powitanie w channelSettings). Bot z oboma kanałami potrzebuje obu.

Weryfikacja przed pierwszą rozmową

get_bot_readiness zwraca trzy werdykty, których nie wolno mylić:

ready — bot może w ogóle obsłużyć rozmowę (dla bota tylko czatowego liczy się też podpięty widget),
readyForOutbound — bot ma kanał połączeń wychodzących i podpięty numer, którego trunk SIP jest gotowy,
readyForWebChat — bot obsługuje czat na stronie i widget jest do niego podpięty.

Bot tylko przychodzący jest zgodnie z prawdą ready: true, readyForOutbound: false. Bot tylko czatowy jest zgodnie z prawdą readyForOutbound: false — nie podpinaj mu numeru. Widget, dozwolone domeny i kolory ustawiasz w aplikacji: Ustawienia → Czat na stronie. Podgląd czatu jest na karcie Test bota. Włączenie Terminarza (rezerwacje) jest na karcie Narzędzia. Pobranie stron WWW do bazy wiedzy jest na stronie wiedzy bota. Tego serwer MCP nie robi.

Odpowiedź zawiera też informacyjny check ai_disclosure — próbę sprawdzenia, czy bot mówi rozmówcy, że jest AI. Art. 50 aktu o AI tego oczekuje, a treść komunikatu należy do operatora, nie do nas. Ten check nigdy nie blokuje publikacji.

REST: GET /bots/{botId}/readiness.

Kolejność, która działa

create_bot                    →  bot z rekomendowaną konfiguracją (kanały organizacji)
update_bot                    →  nazwa, aktywność, kanały (od razu, nie wersja robocza)
get_prompting_guidance        →  zasady głosu i czatu, zanim napiszesz prompt
update_bot_config             →  prompt, channelSettings i reszta (WERSJA ROBOCZA)
create_workflow_from_template →  przebieg rozmowy (opcjonalnie)
update_workflow / validate_workflow / activate_workflow
publish_bot_config            →  dopiero teraz bot działa po nowemu
get_bot_readiness             →  widget czatu albo numer, zależnie od kanału

W aplikacji, nie przez MCP: podpięcie widgetu (domeny i kolory), podgląd czatu, crawl strony do bazy wiedzy, przełączniki Terminarza.