Практикум: AI-агент для клиентской поддержки в 2026
Старые туториалы про support agent обычно выглядели так: одна модель, самодельный ChromaDB, один промпт "ответь клиенту" и надежда, что всё как-нибудь заработает. В 2026 это уже слабый baseline.
Нормальный AI-агент поддержки сейчас строят как workflow:
- triage и routing;
- retrieval по policy и knowledge base;
- read-only account tools;
- draft reply;
- escalation gate и human approval для рискованных кейсов.
То есть не "чат-бот по FAQ", а управляемый service workflow.
1. Почему support-агент - это workflow, а не просто чат
Customer support плохо переносит "свободную" агентность. Здесь важнее не автономность, а предсказуемость.
Поэтому support workflow почти всегда должен отделять:
- что мы знаем из ticket text;
- что мы нашли в KB и policies;
- что вернул account/order tool;
- какой ответ модель имеет право отправить без человека;
- когда нужен handoff.
Это уменьшает риск hallucination, data leakage и неверных side effects.
2. Retrieval в 2026: hosted file_search вместо самодельной базы по умолчанию
Самый частый сдвиг по сравнению со старыми туториалами: больше не обязательно начинать с самописной векторной базы только ради первого support-агента.
Для многих команд быстрее стартовать с hosted file_search:
- загружаете policies, runbooks, FAQ, billing rules, incident macros;
- привязываете vector store к workflow;
- при необходимости добавляете metadata filters по продукту, рынку, языку, тарифу.
Этого достаточно, чтобы support agent отвечал не "из головы", а по реальной документной базе.
3. Инструменты поддержки: только read-only по умолчанию
Хороший baseline инструментов:
get_customer_profile;check_order_status;get_subscription_state;create_escalation_case.
Плохой baseline:
- refund без approval;
- delete account;
- change plan;
- cancel subscription без человеческого подтверждения.
Support agent должен начинать с read-only инструментов. Write-action tools стоит включать только после явного approval layer.
4. Минимальный support loop на Python
Ниже skeleton, который показывает current baseline:
- retrieval через
file_search; - read-only function tools;
- follow-up после tool calls;
- явная escalation tool.
import json
from openai import OpenAI
client = OpenAI()
VECTOR_STORE_ID = "vs_support_kb"
def get_customer_profile(email: str) -> str:
return json.dumps({
"email": email,
"plan": "Pro",
"account_status": "active",
"region": "EU",
})
def check_order_status(order_id: str) -> str:
return json.dumps({
"order_id": order_id,
"payment_status": "pending_settlement",
"eta_minutes": 90,
})
def create_escalation_case(reason: str, priority: str) -> str:
return json.dumps({
"status": "queued_for_human",
"reason": reason,
"priority": priority,
})
TOOLS = [
{
"type": "file_search",
"vector_store_ids": [VECTOR_STORE_ID],
"max_num_results": 4,
},
{
"type": "function",
"name": "get_customer_profile",
"description": "Read-only lookup of customer plan and account state.",
"parameters": {
"type": "object",
"properties": {"email": {"type": "string"}},
"required": ["email"],
"additionalProperties": False,
},
"strict": True,
},
{
"type": "function",
"name": "check_order_status",
"description": "Read-only lookup of an order or payment state.",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
},
{
"type": "function",
"name": "create_escalation_case",
"description": "Escalate the case to a human support queue.",
"parameters": {
"type": "object",
"properties": {
"reason": {"type": "string"},
"priority": {"type": "string"},
},
"required": ["reason", "priority"],
"additionalProperties": False,
},
"strict": True,
},
]
TOOL_IMPL = {
"get_customer_profile": get_customer_profile,
"check_order_status": check_order_status,
"create_escalation_case": create_escalation_case,
}
def handle_ticket(ticket_text: str) -> str:
first = client.responses.create(
model="gpt-5-mini",
input=(
"Вы - support workflow.\n"
"Сначала поймите intent, затем используйте KB и read-only tools.\n"
"Если есть высокий риск, неуверенность, refund, abuse, legal issue или жалоба на сотрудника - эскалируйте.\n\n"
f"Тикет:\n{ticket_text}"
),
tools=TOOLS,
include=["file_search_call.results"],
)
tool_outputs = []
for item in first.output:
if item.type != "function_call":
continue
args = json.loads(item.arguments)
result = TOOL_IMPL[item.name](**args)
tool_outputs.append({
"type": "function_call_output",
"call_id": item.call_id,
"output": result,
})
if not tool_outputs:
return first.output_text
final = client.responses.create(
model="gpt-5.4",
previous_response_id=first.id,
input=tool_outputs,
)
return final.output_text
print(handle_ticket(
"Оплатил подписку Pro вчера, но доступ не появился. Почта user@example.com, заказ #45892."
))
Этот skeleton уже лучше старого "бота по FAQ", потому что:
- retrieval идёт через
file_search; - account data приходят не из памяти модели, а из tools;
- escalation - это явный шаг, а не неформальное решение модели;
- можно видеть ход выполнения в traces.
5. Как решать, когда эскалировать
Минимальный набор escalation triggers:
- refund / billing dispute;
- просьба удалить аккаунт или данные;
- legal / compliance / abuse;
- жалоба на сотрудника;
- модель не нашла уверенный ответ в KB;
- клиент явно просит человека.
Это хороший момент для handoff pattern из LangGraph или для отдельного approval node в вашем agent workflow.
Плюсы
- Workflow даёт более предсказуемые ответы, чем один свободный чат-бот
- Hosted file search ускоряет старт support retrieval
- Read-only tools сильно уменьшают риск опасных side effects
- Escalation gate делает автоматизацию безопаснее для бизнеса
Минусы
- Нужно поддерживать актуальность KB и policy документов
- Плохие escalation rules быстро ломают UX
- Без traces и rubric-based review трудно понимать, почему агент ошибся
- Полная автоматизация не подходит для всех support lanes
6. Что класть в knowledge base
Полезный support KB:
- актуальные policies;
- canned replies и макросы;
- troubleshooting playbooks;
- product docs для user-facing функций;
- billing и account runbooks.
Плохой support KB:
- сырые дампы БД;
- приватные internal notes без разграничения доступа;
- устаревшие policy-файлы;
- документы без metadata по продукту, стране, тарифу или языку.
Retrieval quality у support-агента чаще ломается не на модели, а на плохой документной гигиене.
7. Что логировать и проверять
Минимальный observability baseline:
- intent и priority тикета;
- какие документы вернул
file_search; - какие tools вызвал агент;
- был ли escalation;
- каков итоговый confidence lane;
- какие ответы потом были переоткрыты человеком.
Без этого support automation почти невозможно улучшать итеративно.
- Tool Use в 2026 - как устроены built-in tools, custom tools и MCP
- Debugging агентов - traces, tool failures и state bugs
- Security в 2026 - prompt injection, tool abuse и approval layer
- Eval 2026 - как проверять answer quality и escalation policy
8. Практический вывод
Хороший support agent в 2026 - это не "умный чат на базе FAQ", а workflow с triage, retrieval, read-only tools и handoff.
Для большинства команд лучший старт:
file_searchдля KB и policies;gpt-5-miniдля triage;gpt-5.4для финального ответа;- traces и human escalation как обязательный слой.
Именно это даёт реальную автоматизацию, а не красивое демо.
Проверьте себя
1. Почему support-агента лучше строить как workflow?
2. Что лучше давать support-агенту по умолчанию?
3. Какой источник чаще всего делает support automation слабой?