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

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

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

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

Сквозной маршрут по главам¶

Эти кейсы нужно держать рядом с основным текстом как проверку покрытия:

• глава 1: выбор между рабочим процессом, одиночным агентным циклом и многоагентной схемой;
• глава 2: маршрут через эталонную архитектуру, плоскость управления и границы данных;
• главы 3-4: границы доверия, подтверждения, политики и право агента действовать;
• главы 5-7: память, поиск, свежесть, происхождение знаний и защита от отравления;
• главы 8-10: шлюз инструментов, MCP/A2A, идемпотентность, повторы и откат;
• глава 13: оценки, проверяющий и регрессионные шлюзы;
• глава 18: готовность к поэтапному выпуску и проверка перед масштабированием;
• главы 21-27: жизненный цикл, контур заверения, происхождение, вывод из эксплуатации, телеметрия и реестр.

Промышленные runtime-паттерны¶

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

Cloudflare Agents SDK: агент как именованный долговечный объект¶

Cloudflare Agents SDK показывает паттерн, в котором агент — это не только transient loop вокруг модели, а адресуемый Agent instance поверх Durable Object: у него есть стабильное имя, долговечное SQL/key-value состояние, WebSocket-соединения, scheduled tasks, wakeups и hibernation. Архитектурный вывод для книги простой: если агент привязан к реальной сущности — customer case, tenant workspace, incident room, device, project или research dossier, — runtime должен явно показывать, кто владеет состоянием, какие runs его меняли, какие scheduled tasks могут разбудить instance и какие traces доказывают безопасный resume.

Практический контракт здесь такой: стабильное имя → долговечное состояние → пробуждение/сон → запланированная или фоновая работа → шлюзы подтверждения → доказательства в трассе. Это связывает главы про память, фоновые обновления, выполнение, трассы и раскатку в одну форму: расписание не должно быть невидимым обратным вызовом, WebSocket-интерфейс не должен открывать всё состояние агента, а подтверждение должно жить там, где реально происходит побочный эффект.

Облачный агент GitHub Copilot: контракт облачного агента для работы с кодом¶

Облачный агент GitHub Copilot показывает другую промышленную форму: агент получает задачу из GitHub, IDE, CLI, API или интеграции, исследует репозиторий, планирует изменения, отправляет код в отдельную ветку, дает журналы сессии, а затем открывает pull request для человеческого разбора. Важный момент не в том, что это “агент пишет код”, а в том, что автономия упакована в знакомый инженерный жизненный цикл.

Для книги это хороший образец контракта: запрос/задача → изолированная сессия задачи → ветка → коммиты/журналы → проверки валидации и безопасности → человеческий разбор → pull request. Ветка становится границей изменений, журналы сессии — поверхностью наблюдаемости, PR — шлюзом подтверждения, а настройка запуска GitHub Actions на ветке агента — отдельным решением о риске, потому что рабочий процесс может получить доступ к секретам или правам записи. Такой паттерн стоит переносить в любые облачные агенты для работы с кодом: автономный исполнитель может делать подготовительную работу, но слияние, привилегированные рабочие процессы и влияние на промышленную среду должны оставаться проверяемыми контрольными точками.

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

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

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

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

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

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

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

То есть это хороший кандидат на схему "рабочий процесс + защищенный агентный цикл".

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

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

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

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

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

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

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

• Критерий успеха: ответ или тикет создается один раз, в правильном контексте арендатора и с объяснимым основанием.
• Критерий провала: лишнее действие записи, утечка соседнего контекста, потерянное подтверждение или невозможность восстановить трассу.
• Минимальная телеметрия: session_id, trace_id, выбранное действие, источники поиска, решение политики, состояние подтверждения и ключ идемпотентности.
• Минимальный оценочный набор: обычный запрос, неоднозначный запрос, попытка внедрить инструкцию, повтор после истечения времени и сценарий дубля тикета.
• Модель подтверждения: запись тикета без чувствительных изменений допускается автоматически; изменение приоритета, эскалация, массовое уведомление и повтор после неизвестного побочного эффекта требуют свежего подтверждения.
• Политика памяти: долговременная память не хранит текст клиента как доверенный факт; допускаются только проверенные предпочтения, привязанные к арендатору, с источником, сроком жизни и возможностью очистки.
• Профиль риска инструментов: чтение профиля и истории обращений — низкий риск; создание тикета — средний риск с идемпотентностью; изменение статуса, приоритета или получателей — высокий риск с подтверждением.
• Экспозиция MCP/A2A: MCP-сервер поддержки должен быть в утвержденном реестре и отдавать отфильтрованные результаты; A2A-передача в команду поддержки не должна передавать полномочия записи без отдельного решения.
• Шлюз поэтапного выпуска: пробный выпуск проходит без дублей записи, а проверяющий подтверждает изоляцию арендатора и корректный путь подтверждения.
• Пример инцидента: истечение времени после create_ticket оставляет side_effect_unknown, и повторный запуск пытается создать второй тикет.
• Вопросы разбора после инцидента: где потерялась идемпотентность, кто видел состояние подтверждения, почему трасса не остановила повтор и какая оценка теперь должна блокировать регрессию?
• Условие вывода из эксплуатации: старый путь создания тикетов закрыт, зависшие подтверждения истекли, принципал инструмента отозван, а реестр указывает только на новый контракт записи.

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

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

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

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

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

Он:

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

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

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

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

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

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

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

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

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

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

• Критерий успеха: ответ опирается на разрешенные источники, показывает ссылки на них и честно ограничивает уверенность.
• Критерий провала: ответ без источников, доступ не по роли, смешение краткосрочного состояния и долговременной памяти или выдуманная политика.
• Минимальная телеметрия: запрос, область поиска, идентификаторы источников, сигнал уверенности, отклоненные источники и вердикт привязки ответа к источникам.
• Минимальный оценочный набор: известный ответ, недостаточный контекст, документ вне роли, конфликтующие источники и устаревшее знание.
• Модель подтверждения: чтение разрешенных источников не требует подтверждения; запись в память, расширение области поиска и ответ на чувствительный запрос требуют политики или ручного подтверждения.
• Политика памяти: краткосрочное состояние очищается после сессии; долговременная память хранит только проверенные факты с источником, сроком жизни, областью арендатора и запретом на запись из недоверенного текста.
• Профиль риска инструментов: поиск по разрешенному корпусу — низкий риск; запись в память и обновление корпуса — средний риск; расширение прав доступа и изменение фильтров арендатора — высокий риск.
• Экспозиция MCP/A2A: MCP-поиск обязан возвращать идентификаторы источников и метки доступа; A2A-передача эксперту допускает только вопрос и выбранные цитаты, а не полный скрытый контекст сессии.
• Шлюз поэтапного выпуска: регрессионный набор подтверждает привязку к источникам, изоляцию ролей и корректное поведение при низкой уверенности.
• Пример инцидента: агент отвечает по устаревшей инструкции без ссылок на источники и показывает сотруднику документ вне его роли.
• Вопросы разбора после инцидента: почему область поиска расширилась, какой источник был признан доверенным, где должна была сработать остановка при низкой уверенности и какая оценка покрывает устаревшее знание?
• Условие вывода из эксплуатации: устаревший корпус, векторные представления и правила записи в память отключены, а свежий корпус прошел проверку происхождения и доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Критерий успеха: инцидент получает единую трассу, правильного владельца и один согласованный следующий шаг.
• Критерий провала: повторные уведомления, потерянная ответственность при передаче управления, рискованное восстановление без подтверждения или разделение управления между каналами.
• Минимальная телеметрия: источник сигнала, идентификатор ветки инцидента, владелец передачи, шаг инструкции реагирования, намерения записи, подтверждения и ключи идемпотентности уведомлений.
• Минимальный оценочный набор: шумный сигнал, повторное уведомление, передача неправильному владельцу, отсутствующий контекст инструкции реагирования и запрос рискованного восстановления.
• Модель подтверждения: создание ветки и предложение шага допускаются автоматически; эскалация, уведомления вовне и восстановительные действия требуют владельца инцидента или дежурного подтверждающего.
• Политика памяти: временная память инцидента живет до закрытия разбора; долговременно сохраняются только утвержденные выводы, обновления инструкций реагирования и ссылки на артефакты разбора.
• Профиль риска инструментов: чтение сигналов и инструкций — низкий риск; создание ветки и уведомление команды — средний риск; восстановительные действия и внешние уведомления — высокий риск.
• Экспозиция MCP/A2A: MCP-инструменты мониторинга и уведомлений должны иметь ограниченные токены; A2A-передача роли реагирования требует идентификатор корреляции, глубину делегирования и правило возврата ответственности.
• Шлюз поэтапного выпуска: учебный прогон показывает единую цепочку трассы, отсутствие повторных побочных эффектов и ручное подтверждение для рискованных шагов.
• Пример инцидента: шумный сигнал запускает две параллельные передачи управления и отправляет повторные уведомления в разные каналы.
• Вопросы разбора после инцидента: где разделилось управление между каналами, кто был владельцем на каждом шаге, каких ключей идемпотентности не хватало и какой учебный прогон должен был поймать повтор?
• Условие вывода из эксплуатации: аварийный путь закрыт, временные токены и каналы уведомлений отозваны, а реестр сохраняет только действующие роли и инструкции реагирования.

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

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

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

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

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

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