Przewodnik po promptach

Wprowadzenie

Skuteczne prompty zmieniają agentów ElevenLabs z robotycznych w naturalnych.

Prompt systemowy to plan osobowości i zasad twojego agenta AI. W zastosowaniach firmowych zwykle jest rozbudowany — określa rolę i cele agenta, dostępne narzędzia, instrukcje krok po kroku dla wybranych zadań oraz zasady określające, czego agent nie powinien robić. Jego struktura bezpośrednio wpływa na niezawodność.

Podstawy prompt engineeringu

Prompt systemowy to plan osobowości i zasad twojego agenta AI. W zastosowaniach firmowych zwykle jest rozbudowany — określa rolę i cele agenta, dostępne narzędzia, instrukcje krok po kroku dla wybranych zadań oraz zasady określające, czego agent nie powinien robić. Jego struktura bezpośrednio wpływa na niezawodność.

Poniższe zasady stanowią podstawę prompt engineeringu gotowego do produkcji:

Rozdziel instrukcje na jasne sekcje

Podział instrukcji na osobne sekcje z nagłówkami Markdown pomaga modelowi właściwie je priorytetyzować i interpretować. Używaj pustych linii i podziałów wierszy, aby rozdzielać instrukcje.

Dlaczego to ważne dla niezawodności: Modele są dostrojone tak, by zwracać szczególną uwagę na niektóre nagłówki (zwłaszcza # Guardrails), a wyraźne granice sekcji zapobiegają przenikaniu instrukcji, gdy zasady z jednego kontekstu wpływają na inny.

You are a customer service agent. Be polite and helpful. Never share sensitive data. You can look up orders and process refunds. Always verify identity first. Keep responses under 3 sentences unless the user asks for details.

Bądź jak najbardziej zwięzły

Każda instrukcja powinna być krótka, jasna i oparta na działaniu. Usuń zbędne słowa i powtarzaj tylko to, co niezbędne, by model działał poprawnie.

Dlaczego to ważne dla niezawodności: Zwięzłe instrukcje zmniejszają niejednoznaczność i zużycie tokenów. Każde niepotrzebne słowo może zostać źle zinterpretowane.

# Tone
When you're talking to customers, you should try to be really friendly and approachable, making sure that you're speaking in a way that feels natural and conversational, kind of like how you'd talk to a friend, but still maintaining a professional demeanor that represents the company well.

Wyróżniaj kluczowe instrukcje

Wyróżnij kluczowe kroki, dodając na końcu wiersza „Ten krok jest ważny”. Dwukrotne powtórzenie 1–2 najważniejszych instrukcji w prompcie może je wzmocnić.

Dlaczego to ważne dla niezawodności: W złożonych promptach modele mogą bardziej priorytetyzować najnowszy kontekst niż wcześniejsze instrukcje. Wyróżnienie i powtórzenie sprawiają, że kluczowe zasady nie zostaną pominięte.

# Goal
Verify customer identity before accessing their account.
Look up order details and provide status updates.
Process refund requests when eligible.

Normalizacja tekstu

Modele zamiany tekstu na mowę, zwłaszcza szybsze, najlepiej generują mowę na podstawie tekstu alfabetycznego. Dlatego cyfry i symbole, takie jak „@” czy „£”, częściej powodują błędną wymowę lub halucynacje głosowe.

Aby temu zapobiec, normalizujemy tekst niealfabetyczny do słów, zanim trafi do modelu TTS (np. 123 -> sto dwadzieścia trzy, john@gmail.com -> john małpa gmail kropka com), i pozwalamy wybierać między strategiami normalizacji o różnych kompromisach.

Strategie normalizacji

Obsługujemy dwie strategie normalizacji przez konfigurację agenta text_normalisation_type:

system_prompt (domyślnie) — Dodaje do promptu systemowego instrukcje, aby LLM zapisywał liczby i symbole słowami, zanim tekst trafi do modelu TTS.

• Bez dodatkowych opóźnień
• LLM może czasem nie znormalizować tekstu poprawnie
• Transkrypcje zawierają wszystko zapisane słowami (np. „tysiąc dolarów” zamiast „$1,000”)

elevenlabs — Używa naszego normalizatora TTS, aby znormalizować tekst po wygenerowaniu przez LLM, zanim trafi do modelu TTS.

• Bardziej niezawodny niż normalizacja oparta na LLM
• Prompt systemowy nie jest zmieniany
• Transkrypcje zachowują naturalne formatowanie z symbolami i liczbami (np. „$1,000”)
• Dodaje niewielkie opóźnienie

Znajdziesz tę konfigurację na naszej platformie na karcie „Agent”. Kliknij ikonę koła zębatego w sekcji „Voices”, aby otworzyć wspólne ustawienia głosu, i skonfiguruj ją na dole.

Dane strukturalne dla danych wejściowych narzędzi

Przy ustawieniu normalizacji system_prompt LLM zapisuje w odpowiedziach symbole i liczby słowami (np. john małpa gmail kropka com zamiast john@gmail.com). Transkrypcje użytkownika z zamiany mowy na tekst mogą też docierać w niestandardowej formie. Oznacza to, że gdy używasz tych danych jako parametrów wywołań narzędzi, LLM może użyć nieustrukturyzowanej wersji obecnej w kontekście rozmowy.

Jeśli parametr narzędzia oczekuje poprawnie sformatowanej wartości (np. john@gmail.com, a nie john małpa gmail kropka com), LLM musi o tym wiedzieć. Dodaj oczekiwany format bezpośrednio do opisu parametru narzędzia wraz z przykładem.

## `lookupAccount` tool parameters
- `email` (required): "The user's email."
- `phone` (required): "The user's phone number."
- `confirmation_code` (required): "The user's confirmation code."

Dodaj osobną sekcję zasad

Wypisz wszystkie bezwzględne zasady, których model musi zawsze przestrzegać, w osobnej sekcji # Guardrails. Modele są dostrojone tak, by zwracać szczególną uwagę na ten nagłówek.

Dlaczego to ważne dla niezawodności: Zasady zapobiegają nieodpowiednim odpowiedziom i zapewniają zgodność z politykami. Zebranie ich w jednej sekcji ułatwia audyt i aktualizacje.

# Guardrails
Never share customer data across conversations or reveal sensitive account information without proper verification.
Never process refunds over $500 without supervisor approval.
Never make promises about delivery dates that aren't confirmed in the order system.
Acknowledge when you don't know an answer instead of guessing.
If a customer becomes abusive, politely end the conversation and offer to escalate to a supervisor.

Więcej o projektowaniu skutecznych zasad znajdziesz w naszym przewodniku o zasadach.

Konfiguracja narzędzi dla niezawodności

Agenci obsługujący transakcyjne workflow mogą być bardzo skuteczni. Aby to umożliwić, muszą mieć narzędzia, które pozwalają im wykonywać działania w innych systemach lub pobierać z nich aktualne dane.

Równie ważne jak struktura promptu jest opisanie narzędzi dostępnych dla agenta. Jasne definicje narzędzi, nastawione na działanie, pomagają modelowi poprawnie je wywoływać i sprawnie radzić sobie z błędami.

Opisuj narzędzia precyzyjnie, ze szczegółowymi parametrami

Tworząc narzędzie, dodaj opisy do wszystkich parametrów. Pomaga to LLM dokładnie tworzyć wywołania narzędzi.

Opis narzędzia: „Sprawdza status zamówienia klienta według identyfikatora zamówienia i zwraca bieżący status, szacowaną datę dostawy oraz numer śledzenia.”

Opisy parametrów:

• order_id (wymagany): „Unikalny identyfikator zamówienia w formacie znakowym (np. ‘ORD123456’)”
• include_history (opcjonalny): „Jeśli ma wartość true, zwraca pełną historię zamówienia, w tym zmiany statusu”

Dlaczego to ważne dla niezawodności: Opisy parametrów działają jak dokumentacja wbudowana dla modelu. Wyjaśniają oczekiwany format, pola wymagane i opcjonalne oraz dopuszczalne wartości.

Wyjaśnij w prompcie systemowym, kiedy i jak używać każdego narzędzia

Jasno określ w prompcie systemowym, kiedy i jak należy używać każdego narzędzia. Nie polegaj wyłącznie na opisach narzędzi — podaj kontekst użycia i logikę kolejności.

# Tools
You have access to the following tools:
## `getOrderStatus`
Use this tool when a customer asks about their order. Always call this tool before providing order information—never rely on memory or assumptions.
**When to use:**
- Customer asks "Where is my order?"
- Customer provides an order number
- Customer asks about delivery estimates
**How to use:**
1. Collect the order ID from the customer
2. Call `getOrderStatus` with the order ID
3. Present the results to the customer in natural language
**Error handling:**
If the tool returns "Order not found", ask the customer to verify the order number and try again.
## `processRefund`
Use this tool only after verifying:
1. Customer identity has been confirmed
2. Order is eligible for refund (within 30 days, not already refunded)
3. Refund amount is under $500 (escalate to supervisor if over $500)
**Required before calling:**
- Order ID (from `getOrderStatus`)
- Refund reason code
- Customer confirmation
This step is important: Always confirm refund details with the customer before calling this tool.

Określ oczekiwane formaty w opisach parametrów narzędzi

Gdy narzędzia wymagają ustrukturyzowanych identyfikatorów (adresów e-mail, numerów telefonu, kodów), jasno określ oczekiwany format w opisie parametru wraz z przykładem. Jest to szczególnie ważne, ponieważ normalizacja i transkrypcja mowy na tekst mogą tworzyć w kontekście rozmowy wartości w formie mówionej. Więcej informacji znajdziesz w sekcji dane strukturalne dla danych wejściowych narzędzi.

## `lookupAccount` tool parameters
- `email` (required): "The customer's email address."

Sprawnie obsługuj błędy wywołań narzędzi

Narzędzia mogą czasem zawieść z powodu problemów z siecią, brakujących danych lub innych błędów. Dodaj do promptu systemowego jasne instrukcje odzyskiwania sprawności.

Dlaczego to ważne dla niezawodności: Awarie narzędzi są nieuniknione w środowisku produkcyjnym. Bez wyraźnych instrukcji obsługi agent może halucynować odpowiedzi lub podawać nieprawidłowe informacje.

# Tool error handling
If any tool call fails or returns an error:
1. Acknowledge the issue to the customer: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer alternatives:
   - Try the tool again if it might be a temporary issue
   - Offer to escalate to a human agent
   - Provide a callback option
4. If the error persists after 2 attempts, escalate to a supervisor
**Example responses:**
- "I'm having trouble looking up that order right now. Let me try again... [retry]"
- "I'm unable to access the order system at the moment. I can transfer you to a specialist who can help, or we can schedule a callback. Which would you prefer?"

Szczegółowe wskazówki dotyczące tworzenia niezawodnych integracji narzędzi znajdziesz w naszej dokumentacji narzędzi klienckich, narzędzi webhook i narzędzi MCP.

Wzorce architektury dla agentów firmowych

Choć solidne prompty i narzędzia są podstawą niezawodności agentów, systemy produkcyjne wymagają przemyślanego projektu architektury. Agenci firmowi obsługują złożone workflow, które często wykraczają poza zakres pojedynczego, monolitycznego promptu.

Wyspecjalizuj agentów

Zbyt szerokie instrukcje lub duże okna kontekstu zwiększają opóźnienia i obniżają dokładność. Każdy agent powinien mieć wąską, jasno określoną bazę wiedzy i zestaw obowiązków.

Dlaczego to ważne dla niezawodności: Wyspecjalizowani agenci mają mniej przypadków brzegowych, jaśniejsze kryteria sukcesu i szybszy czas odpowiedzi. Łatwiej ich testować, debugować i ulepszać.

Stosuj wzorzec orkiestratora i specjalistów

W przypadku złożonych zadań projektuj workflow wielu agentów, które przekazują zadania między wyspecjalizowanymi agentami — a w razie potrzeby także operatorom.

Wzorzec architektury:

1. Agent orkiestrator: Kieruje przychodzące zapytania do odpowiednich agentów specjalistycznych na podstawie klasyfikacji intencji
2. Agenci specjaliści: Obsługują zadania z konkretnych dziedzin (rozliczenia, planowanie, wsparcie techniczne itd.)
3. Przekazanie do człowieka: Zdefiniowane kryteria przekazania dla złożonych lub wrażliwych spraw

Zalety tego wzorca:

• Każdy specjalista ma skoncentrowany prompt i ograniczony kontekst
• Łatwiej aktualizować poszczególnych specjalistów bez wpływu na system
• Jasne metryki dla każdej dziedziny (wskaźnik rozwiązania spraw rozliczeniowych, skuteczność planowania itd.)
• Mniejsze opóźnienie na interakcję (krótsze prompty, szybsze wnioskowanie)

Określ jasne kryteria przekazywania

Projektując workflow wielu agentów, dokładnie określ, kiedy i jak kontrola ma być przekazywana między agentami lub operatorom.

# Goal
Route customer requests to the appropriate specialist agent based on intent.
## Routing logic
**Billing specialist:** Customer mentions payment, invoice, refund, charge, subscription, or account balance
**Technical support specialist:** Customer reports error, bug, issue, not working, broken
**Scheduling specialist:** Customer wants to book, reschedule, cancel, or check appointment
**Human escalation:** Customer is angry, requests supervisor, or issue is unresolved after 2 specialist attempts
## Handoff process
1. Classify customer intent based on first message
2. Provide brief acknowledgment: "I'll connect you with our [billing/technical/scheduling] team."
3. Transfer conversation with context summary:
   - Customer name
   - Primary issue
   - Any account identifiers already collected
4. Do not repeat information collection that already occurred

# Personality
You are a billing specialist for Acme Corp. You handle payment issues, refunds, and subscription changes.
# Goal
Resolve billing inquiries by:
1. Verifying customer identity
2. Looking up account and billing history
3. Processing refunds (under $500) or escalating (over $500)
4. Updating subscription settings when requested
# Guardrails
Never access account information without identity verification.
Never process refunds over $500 without supervisor approval.
If the customer's issue is not billing-related, transfer back to the orchestrator agent.

Szczegółowe wskazówki dotyczące tworzenia workflow wielu agentów znajdziesz w dokumentacji Workflow.

Wybór modelu dla niezawodności firmowej

Wybór odpowiedniego modelu zależy od wymagań dotyczących wydajności — szczególnie opóźnień, dokładności i niezawodności wywoływania narzędzi. Różne modele oferują różne kompromisy między szybkością, zdolnością rozumowania i kosztem.

Poznaj kompromisy

Opóźnienie: Mniejsze modele (z mniejszą liczbą parametrów) zwykle odpowiadają szybciej, dlatego nadają się do częstych interakcji o niskiej złożoności.

Dokładność: Większe modele zapewniają lepsze zdolności rozumowania i lepiej obsługują złożone zadania wieloetapowe, ale kosztem większych opóźnień i wyższej ceny.

Niezawodność wywoływania narzędzi: Nie wszystkie modele obsługują wywołania narzędzi/funkcji z taką samą precyzją. Niektóre świetnie radzą sobie z ustrukturyzowanym wyjściem, a inne mogą wymagać bardziej jednoznacznych promptów.

Rekomendacje modeli według przypadku użycia

Na podstawie wdrożeń obejmujących miliony interakcji agentów wyłaniają się następujące wzorce:

• GPT-4o lub GLM 4.5 Air (zalecany punkt startowy): Najlepsze dla uniwersalnych agentów firmowych, w których trzeba zrównoważyć opóźnienia, dokładność i koszt. Oferują małe lub umiarkowane opóźnienia, dobre wywoływanie narzędzi i rozsądny koszt interakcji. Idealne do obsługi klienta, planowania, zarządzania zamówieniami i obsługi ogólnych zapytań.

• Gemini 2.5 Flash Lite (bardzo niskie opóźnienie): Najlepszy do częstych, prostych interakcji, w których szybkość ma kluczowe znaczenie. Zapewnia najniższe opóźnienia i szeroką wiedzę ogólną, choć gorzej radzi sobie ze złożonym wywoływaniem narzędzi. Opłacalny na dużą skalę do wstępnego kierowania i selekcji spraw, prostych FAQ, potwierdzania wizyt i podstawowego zbierania danych.

• Claude Sonnet 4 lub 4.5 (złożone rozumowanie): Najlepszy do wieloetapowego rozwiązywania problemów, niuansów w ocenie i złożonej orkiestracji narzędzi. Oferuje najwyższą dokładność i zdolność rozumowania oraz świetną niezawodność wywoływania narzędzi, ale z większymi opóźnieniami i kosztem. Idealny do zadań, w których błędy są kosztowne, takich jak rozwiązywanie problemów technicznych, doradztwo finansowe, workflow wymagające zgodności i złożone decyzje o zwrotach lub eskalacji.

Testuj na swoich rzeczywistych promptach

Wydajność modelu znacznie różni się zależnie od struktury promptu i złożoności zadania. Zanim wybierzesz model:

1. Przetestuj 2–3 modele kandydujące z rzeczywistym promptem systemowym
2. Oceń je na prawdziwych zapytaniach użytkowników lub syntetycznych przypadkach testowych
3. Zmierz opóźnienie, dokładność i wskaźnik skutecznych wywołań narzędzi
4. Wybierz najlepszy kompromis dla swoich konkretnych wymagań

Szczegółowe opcje konfiguracji modeli znajdziesz w dokumentacji Models.

Iteracja i testowanie

Niezawodność w produkcji wynika z ciągłych iteracji. Nawet dobrze skonstruowane prompty mogą zawieść w rzeczywistym użyciu. Ważne jest wyciąganie wniosków z tych błędów i ulepszanie dzięki systematycznym testom.

Skonfiguruj kryteria oceny

Dołącz konkretne kryteria oceny do każdego agenta, aby z czasem monitorować sukces i sprawdzać regresje.

Kluczowe metryki do śledzenia:

• Wskaźnik ukończenia zadań: Procent intencji użytkowników skutecznie obsłużonych
• Wskaźnik eskalacji: Procent rozmów wymagających interwencji człowieka

Szczegółowe wskazówki dotyczące konfiguracji kryteriów oceny w ElevenLabs znajdziesz w sekcji Ocena sukcesu.

Analizuj wzorce błędów

Gdy agenci działają słabo, szukaj wzorców w problematycznych interakcjach:

• Gdzie agent podaje nieprawidłowe informacje? → Wzmocnij instrukcje w konkretnych sekcjach
• Kiedy nie rozumie intencji użytkownika? → Dodaj przykłady lub uprość język
• Które dane wejściowe użytkownika sprawiają, że wychodzi z roli? → Dodaj zasady dla przypadków brzegowych
• Które narzędzia najczęściej zawodzą? → Popraw obsługę błędów lub opisy parametrów

Przeglądaj transkrypcje rozmów, w których satysfakcja użytkownika była niska lub zadania nie zostały ukończone.

Wprowadzaj ukierunkowane poprawki

Aktualizuj konkretne sekcje promptu, by rozwiązać wykryte problemy:

1. Wyizoluj problem: Ustal, która sekcja promptu lub definicja narzędzia powoduje błędy
2. Testuj zmiany na konkretnych przykładach: Używaj rozmów, które wcześniej się nie powiodły, jako przypadków testowych
3. Wprowadzaj jedną zmianę naraz: Izoluj ulepszenia, by zrozumieć, co działa
4. Oceń ponownie na tych samych przypadkach testowych: Sprawdź, czy zmiana rozwiązała problem bez tworzenia nowych

Skonfiguruj zbieranie danych

Skonfiguruj agenta tak, aby podsumowywał dane z każdej rozmowy. Pozwala to analizować wzorce interakcji, wykrywać częste zapytania użytkowników i stale ulepszać prompt na podstawie rzeczywistego użycia.

Szczegółowe wskazówki dotyczące konfiguracji zbierania danych w ElevenLabs znajdziesz w sekcji Zbieranie danych.

Używaj symulacji do testów regresji

Przed wdrożeniem zmian promptu do produkcji przetestuj je na zestawie znanych scenariuszy, aby wykryć regresje.

Wskazówki dotyczące programowego testowania agentów znajdziesz w sekcji Symulowanie rozmów.

Kwestie produkcyjne

Agenci firmowi wymagają dodatkowych zabezpieczeń poza jakością promptu. Wdrożenia produkcyjne muszą uwzględniać obsługę błędów, zgodność i płynne ograniczanie działania.

Obsługuj błędy we wszystkich integracjach narzędzi

Każde wywołanie zewnętrznego narzędzia jest potencjalnym punktem awarii. Upewnij się, że prompt zawiera jawną obsługę błędów dla:

• Awarii sieci: „Mam problem z połączeniem z naszym systemem. Spróbuję ponownie.”
• Brakujących danych: „Nie widzę tej informacji w naszym systemie. Czy możesz sprawdzić szczegóły?”
• Błędów limitu czasu: „To trwa dłużej, niż oczekiwano. Mogę przekazać sprawę specjaliście lub spróbować ponownie.”
• Błędów uprawnień: „Nie mam dostępu do tej informacji. Przekażę cię osobie, która może pomóc.”

Przykładowe prompty

Poniższe przykłady pokazują, jak zastosować zasady opisane w tym przewodniku w rzeczywistych firmowych przypadkach użycia. Każdy przykład zawiera adnotacje wskazujące wykorzystane zasady niezawodności.

Przykład 1: Agent wsparcia technicznego

# Personality
You are a technical support specialist for CloudTech, a B2B SaaS platform.
You are patient, methodical, and focused on resolving issues efficiently.
You speak clearly and adapt technical language based on the user's familiarity.
# Environment
You are assisting customers via phone support.
Customers may be experiencing service disruptions and could be frustrated.
You have access to diagnostic tools and the customer account database.
# Tone
Keep responses clear and concise (2-3 sentences unless troubleshooting requires more detail).
Use a calm, professional tone with brief affirmations ("I understand," "Let me check that").
Adapt technical depth based on customer responses.
Check for understanding after complex steps: "Does that make sense?"
# Goal
Resolve technical issues through structured troubleshooting:
1. Verify customer identity using email and account ID
2. Identify affected service and severity level
3. Run diagnostics using `runSystemDiagnostic` tool
4. Provide step-by-step resolution or escalate if unresolved after 2 attempts
This step is important: Always run diagnostics before suggesting solutions.
# Guardrails
Never access customer accounts without identity verification. This step is important.
Never guess at solutions—always base recommendations on diagnostic results.
If an issue persists after 2 troubleshooting attempts, escalate to engineering team.
Acknowledge when you don't know the answer instead of speculating.
# Tools
## `verifyCustomerIdentity`
**When to use:** At the start of every conversation before accessing account data
**Parameters:**
- `email` (required): Customer email in standard written format (e.g., "user@company.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
- `account_id` (optional): Account ID if customer provides it
**Error handling:**
If verification fails, ask customer to confirm email spelling and try again.
## `runSystemDiagnostic`
**When to use:** After verifying identity and understanding the reported issue
**Parameters:**
- `account_id` (required): From `verifyCustomerIdentity` response
- `service_name` (required): Name of affected service (e.g., "api", "dashboard", "storage")
**Usage:**
1. Confirm which service is affected
2. Run diagnostic with account ID and service name
3. Review results before providing solution
**Error handling:**
If diagnostic fails, acknowledge the issue: "I'm having trouble running that diagnostic. Let me escalate to our engineering team."
# Error handling
If any tool call fails:
1. Acknowledge: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer to retry once, then escalate if failure persists

Pokazane zasady:

• ✓ Jasny podział na sekcje (# Personality, # Goal, # Tools itd.)
• ✓ Jedno działanie w wierszu (zobacz numerowane kroki w # Goal)
• ✓ Zwięzłe instrukcje (sekcja tonu jest krótka i jasna)
• ✓ Wyróżnione kluczowe kroki („Ten krok jest ważny”)
• ✓ Konwersja formatu w opisach parametrów (normalizacja e-maili)
• ✓ Osobna sekcja zasad
• ✓ Precyzyjne opisy narzędzi z informacją kiedy/jak postępować przy błędach
• ✓ Jasne instrukcje obsługi błędów

Przykład 2: Agent obsługi zwrotów klienta

# Personality
You are a refund specialist for RetailCo.
You are empathetic, solution-oriented, and efficient.
You balance customer satisfaction with company policy compliance.
# Goal
Process refund requests through this workflow:
1. Verify customer identity using order number and email
2. Look up order details with `getOrderDetails` tool
3. Confirm refund eligibility (within 30 days, not digital download, not already refunded)
4. For refunds under $100: Process immediately with `processRefund` tool
5. For refunds $100-$500: Apply secondary verification, then process
6. For refunds over $500: Escalate to supervisor with case summary
This step is important: Never process refunds without verifying eligibility first.
# Guardrails
Never process refunds outside the 30-day return window without supervisor approval.
Never process refunds over $500 without supervisor approval. This step is important.
Never access order information without verifying customer identity.
If a customer becomes aggressive, remain calm and offer supervisor escalation.
# Tools
## `verifyIdentity`
**When to use:** At the start of every conversation
**Parameters:**
- `order_id` (required): Order ID in uppercase alphanumeric format (e.g., "ORD123456"). Convert from spoken format: spell out letters and spoken digits to written form, no spaces.
- `email` (required): Customer email in standard written format (e.g., "john.smith@retailco.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
## `getOrderDetails`
**When to use:** After identity verification
**Returns:** Order date, items, total amount, refund eligibility status
**Error handling:**
If order not found, ask customer to verify order number and try again.
## `processRefund`
**When to use:** Only after confirming eligibility
**Required checks before calling:**
- Identity verified
- Order is within 30 days
- Order is eligible (not digital, not already refunded)
- Refund amount is under $500
**Parameters:**
- `order_id` (required): From previous verification
- `reason_code` (required): One of "defective", "wrong_item", "late_delivery", "changed_mind"
**Usage:**
1. Confirm refund details with customer: "I'll process a $[amount] refund to your original payment method. It will appear in 3-5 business days. Does that work for you?"
2. Wait for customer confirmation
3. Call this tool
**Error handling:**
If refund processing fails, apologize and escalate: "I'm unable to process that refund right now. Let me escalate to a supervisor who can help."

Pokazane zasady:

• ✓ Wyspecjalizowany zakres agenta (tylko zwroty, nie ogólne wsparcie)
• ✓ Jasne kroki workflow w sekcji # Goal
• ✓ Powtarzane wyróżnienie kluczowych zasad (limity zwrotów, weryfikacja)
• ✓ Szczegółowe użycie narzędzi z informacją „kiedy użyć” i „wymagane kontrole”
• ✓ Konwersja formatu w opisach parametrów (identyfikatory zamówień, e-maile)
• ✓ Jasna obsługa błędów dla każdego narzędzia
• ✓ Jasno określone kryteria eskalacji

Dobre praktyki formatowania

Format promptu wpływa na to, jak skutecznie model językowy go interpretuje:

• Używaj nagłówków Markdown: Twórz sekcje za pomocą # dla głównych sekcji i ## dla podsekcji
• Wybieraj listy punktowane: Dziel instrukcje na łatwe do przyswojenia punkty
• Używaj pustych odstępów: Oddzielaj sekcje i grupy instrukcji pustymi wierszami
• Stosuj wielkość liter jak w zdaniu w nagłówkach: # Cel, a nie # CEL
• Zachowaj spójność: Używaj tego samego formatu w całym prompcie

Często zadawane pytania

Kolejne kroki

Ten przewodnik tworzy podstawę niezawodnego działania agentów dzięki prompt engineeringowi, konfiguracji narzędzi i wzorcom architektonicznym. Aby tworzyć systemy gotowe do produkcji, przejdź dalej:

• Workflow: Projektuj orkiestrację wielu agentów i przekazywanie rozmów specjalistom
• Ocena sukcesu: Skonfiguruj metryki i kryteria oceny
• Zbieranie danych: Zbieraj uporządkowane informacje z rozmów
• Testowanie: Wdróż testy regresji i symulacje
• Zabezpieczenia: Skonfiguruj moderację treści dla bezpiecznych odpowiedzi agentów
• Prywatność: Zapewnij zgodność i ochronę danych
• Nasz agent dokumentacji: Zobacz pełne case study tych zasad w praktyce

Jeśli potrzebujesz wsparcia przy wdrożeniu enterprise, skontaktuj się z naszym zespołem.