Практические кейсы¶

Эта страница показывает, как вся книга выглядит не на уровне абстракции, а на уровне живой системы.

Ниже три сценария, в которых архитектурные слои, защитные ограничения и выбор оркестрации уже можно обсуждать как инженерные решения, а не как красивые слова.

Если тебе нужны не сценарии, а шаблоны политик, переходи на страницу шаблонов политик. Если интересует, что еще стоит добавить в книгу, смотри дорожную карту для сообщества.

Кейс 1. Агент разбора обращений поддержки¶

Что делает система¶

Агент принимает входящий запрос клиента, собирает контекст, проверяет историю обращений и выбирает безопасный следующий шаг:

• ответить сразу;
• запросить уточнение;
• завести тикет;
• эскалировать человеку.

Почему здесь агент вообще нужен¶

Здесь агент оправдан, потому что:

• входящие сообщения неструктурированы;
• решение зависит от сочетания текста, истории клиента и политики;
• путь не всегда фиксированный, но и не требует полной автономии.

То есть это хороший кандидат на workflow + guarded agent loop.

Рекомендуемая схема¶

• один основной агент разбора;
• инструменты чтения для профиля клиента и истории обращений;
• записывающий инструмент только для create_ticket;
• граница подтверждения для чувствительных действий;
• структурированное решение на каждом запуске.

Главные риски¶

• prompt injection через письмо клиента;
• утечка соседнего tenant context;
• лишний write action при нестабильной интеграции;
• слишком широкая свобода у агента разбора.

Что особенно важно в архитектуре¶

• жестко отделять инструкции от текста клиента;
• не давать агенту прямой доступ к API системы поддержки;
• хранить условия остановки в сценарии разбора;
• логировать все намерения записи и подтверждения.

Операционный минимум¶

• Критерий успеха: ответ или тикет создается один раз, в правильном tenant context и с объяснимым основанием.
• Критерий провала: лишний write action, утечка соседнего контекста, потерянный approval или невозможность восстановить trace.
• Минимальная telemetry: session_id, trace_id, выбранный action, retrieval sources, policy decision, approval state и idempotency key.
• Минимальный eval dataset: нормальный запрос, ambiguous request, prompt-injection attempt, retry после timeout и duplicate-ticket сценарий.
• Rollout gate: canary проходит без duplicate writes, а verifier подтверждает tenant isolation и корректный approval path.
• Пример инцидента: timeout после create_ticket оставляет side_effect_unknown, и повторный запуск пытается создать второй тикет.
• Вопросы postmortem: где потерялась idempotency, кто видел approval state, почему trace не остановил повтор и какой eval теперь должен блокировать регрессию?

Где читать в книге¶

• Глава 3. Контур безопасности и границы доверия
• Глава 8. Модель выполнения и каталог инструментов
• Практика. Инструкции, сценарии и шаблоны запросов

Кейс 2. Внутренний агент знаний¶

Что делает система¶

Этот агент помогает сотрудникам находить знания в документации, runbooks, тикетах и внутренних wiki-страницах.

Он:

• понимает вопрос;
• делает retrieval;
• собирает grounded answer;
• показывает источники;
• при низкой уверенности не выдумывает, а честно ограничивает ответ.

Почему здесь часто хватает одного агента¶

В этом кейсе многие команды слишком рано уходят в multi-agent. Обычно это не нужно.

Чаще всего хватает:

• одного agent loop;
• хорошего retrieval pipeline;
• отдельного policy layer;
• строгой маркировки untrusted content;
• quality gates на answer generation.

Главные риски¶

• шум на извлечении контекста;
• доступ к документам не по роли;
• утечки из приватных зон знаний;
• галлюцинации при слабой опоре на источники.

Что особенно важно в архитектуре¶

• tenant- и role-scoped retrieval;
• short-term state отдельно от long-term memory;
• цитаты и source references в output;
• traces по retrieval и answer assembly.

Операционный минимум¶

• Критерий успеха: ответ опирается на разрешенные источники, показывает citations и честно ограничивает уверенность.
• Критерий провала: ответ без источников, доступ не по роли, смешение short-term state и long-term memory или hallucinated policy.
• Минимальная telemetry: query, retrieval scope, source IDs, confidence signal, denied sources и answer-grounding verdict.
• Минимальный eval dataset: известный ответ, недостаточный контекст, role-denied document, conflicting sources и stale knowledge.
• Rollout gate: regression set подтверждает grounding, role isolation и корректное поведение при low confidence.
• Пример инцидента: агент отвечает по устаревшему runbook без citations и показывает сотруднику документ вне его роли.
• Вопросы postmortem: почему retrieval scope расширился, какой source был trusted, где должен был сработать low-confidence stop и какой eval покрывает stale knowledge?

Где читать в книге¶

• Глава 5. Зачем агенту память и почему она опасна
• Глава 7. Извлечение контекста, уплотнение и фоновые обновления
• Глава 11. Трассы, спаны и структурированные события

Кейс 3. Агент координации инцидентов¶

Что делает система¶

Агент помогает в инциденте:

• собрать сигнал из мониторинга;
• обогатить его контекстом;
• создать ветку инцидента;
• предложить следующий runbook шаг;
• передать задачу нужной роли.

Это уже не "чат-помощник", а рабочий компонент системы.

Почему здесь особенно важна дисциплина оркестрации¶

Здесь легко ошибиться и либо:

• сделать одного перегруженного агента-координатора;
• либо слишком рано уйти в передачу управления, в которой теряется ответственность.

Обычно хороший старт такой:

• паттерн координатора на входе и координации;
• передача управления только там, где реально начинается граница другой роли;
• все действия записи проходят через контракты возможностей.

Главные риски¶

• ложная уверенность при noisy alerts;
• повторные side effects;
• потеря следа аудита во время передачи управления;
• слишком широкие права рантайма.

Что особенно важно в архитектуре¶

• единая трасса на весь разбор инцидента;
• явная ответственность на каждом переходе;
• idempotency для ticketing и notifications;
• человеческое подтверждение для рискованных действий по восстановлению.

Операционный минимум¶

• Критерий успеха: инцидент получает единый trace, правильного owner и один согласованный следующий шаг.
• Критерий провала: повторные уведомления, потерянная ответственность при handoff, risky remediation без approval или split-brain между каналами.
• Минимальная telemetry: alert source, incident thread ID, handoff owner, runbook step, write intents, approvals и notification idempotency keys.
• Минимальный eval dataset: noisy alert, duplicate notification, wrong-owner handoff, missing runbook context и risky remediation request.
• Rollout gate: dry run показывает единую trace chain, no duplicate side effects и human approval на high-risk steps.
• Пример инцидента: noisy alert запускает два параллельных handoff и отправляет duplicate notifications в разные каналы.
• Вопросы postmortem: где split-brain вошел в процесс, кто был owner на каждом шаге, какие idempotency keys отсутствовали и какой dry run должен был поймать повтор?

Где читать в книге¶

• Практика. Координатор и передача управления
• Глава 10. Идемпотентность, повторы, лимиты запросов и границы отката
• Глава 18. Чеклист промышленного запуска

Что делать дальше¶

Лучше всего читать их не подряд, а как карту:

• сначала выбрать кейс, похожий на твою задачу;
• потом пройти по связанным главам;
• потом вернуться и проверить, не переусложняешь ли ты свой дизайн.

Именно такие страницы со временем должны расти быстрее всего: они превращают архитектуру в инженерную опору.