Перейти к содержанию

Шпаргалки

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

Канонические сценарии для проверочных списков

Используй эти блоки проверок как быстрый маршрут для трех канонических сценариев. Триаж обращений поддержки начинается с безопасности, шлюза инструментов, подтверждения, идемпотентности и проверки поэтапного выпуска. Внутренний ассистент знаний начинается с памяти, извлечения, привязки к источникам, границ арендатора и проверок наблюдаемости. Координация инцидентов начинается с поэтапного выпуска, наблюдаемости, разбора инцидента, ответственности за реагирование и обучения после инцидента.

Проверка безопасности

  • Есть ли у агента явные границы доверия между вводом пользователя, памятью, инструментами и внешними системами?
  • Различаете ли вы инъекцию в запрос, обход ограничений и галлюцинацию действия, а не сводите все к одной категории риска языковой модели?
  • Есть ли политический шлюз перед каждым чувствительным действием, а не только перед вызовом модели?
  • Разделены ли инструменты низкого и высокого риска?
  • Есть ли шлюз подтверждения для действий с необратимым побочным эффектом?
  • Зафиксированы ли разрешенные направления исходящих соединений и профиль сетевого доступа?
  • Пишется ли аудиторский след для решений политики, подтверждений и выполнения инструментов?
  • Есть ли понятное условие остановки цикла выполнения?

Читать дальше:

Проверка памяти

  • Разделены ли краткосрочная, долгосрочная и профильная память?
  • Учитывает ли извлечение семантический разрыв между пользовательским языком и языком документов?
  • Если вы используете переписывание запроса или HyDE, ясно ли, что это помощь извлечению, а не новый источник фактов?
  • Есть ли разные правила для чтения из памяти и записи в память?
  • Хранится ли происхождение у постоянных записей?
  • Есть ли политика для того, что разрешено записывать в память?
  • Есть ли уплотнение или фоновое обслуживание памяти?
  • Ограничено ли извлечение по объему и релевантности?
  • Пытаетесь ли вы сначала улучшить RAG и свежесть корпуса, прежде чем идти в обучение?
  • Есть ли понятная стратегия удаления или пересмотра записи?

Читать дальше:

Проверка поэтапного выпуска

  • Есть ли владелец агента, а не только команда “вообще”?
  • Есть ли минимальная базовая линия оценок до запуска?
  • Есть ли шлюз поэтапного выпуска с требованиями к безопасности, наблюдаемости и подтверждениям?
  • Понятно ли, какие сценарии считаются блокирующими отказами?
  • Зафиксирован ли бюджет задержки с точки зрения пользователя, а не только p95 модели?
  • Есть ли рабочая инструкция на отказ, запрет действия и очередь подтверждений?
  • Есть ли канал для разбора инцидента и постмортема?
  • Можно ли быстро отключить возможность высокого риска без полной остановки системы?

Читать дальше:

Проверка долговечности среды исполнения

  • Есть ли стабильный agent_instance_id, если агент привязан к делу, комнате, проекту, устройству или рабочей области арендатора?
  • Разделены ли agent_instance_id, run_id, session_id, trace_id и состояние соединения?
  • Хранится ли durable_state_version, чтобы возобновление не продолжало устаревшее или “похожее” состояние?
  • Есть ли ключ идемпотентности или корреляции для webhook, email, Slack-команд и других программных обращений?
  • Можно ли увидеть, какие запланированные задачи могут разбудить экземпляр агента, с какой схемой полезной нагрузки, часовым поясом и политикой пересечений?
  • Проверен ли путь восстановления для прерванного вызова инструмента, фонового запуска или восстанавливаемой внутренней задачи?
  • Есть ли API проверки, отмены и статуса для фоновой работы, а не только progress-сообщения пользователю?
  • Пишутся ли события жизненного цикла: принятие, сон, пробуждение, возобновление, отмена, восстановление, миграция состояния?
  • Не превращается ли локальное долговечное состояние в скрытую профильную память, знания арендатора, секреты или журнал аудита?
  • Есть ли история миграции, удаления и экспорта долговечного состояния, если меняется версия агента или закрывается рабочая область?

Читать дальше:

Проверка наблюдаемости

  • Есть ли trace_id у каждого запуска?
  • Есть ли базовые спаны для извлечения, шага модели, выполнения инструмента, подтверждения и записи в память?
  • Есть ли структурированные события, а не только сырые логи?
  • Видно ли, какое решение политики принял шлюз?
  • Видно ли, какой инструментальный принципал исполнил побочный эффект?
  • Можно ли отличить успех, запрет, ожидание подтверждения и отказ?
  • Есть ли способ агрегировать запуски в сводки уровня сессии или уровня оценивания?
  • Если используется языковая модель как судья, откалиброван ли судья против человеческой проверки и проверки исхода?
  • Не меняете ли вы одновременно модель и запрос там, где нужен причинный вывод по результатам оценивания?

Читать дальше:

Проверка шаблона оркестрации

  • Можно ли решить задачу прямым вызовом модели вместо агентного цикла?
  • Если нужен agent loop, достаточно ли одного агента с инструментами и лимитами итераций?
  • Что именно оправдывает многоагентность: доменная граница, параллельные независимые ветки или отдельная граница безопасности?
  • Для sequential понятны ли порядок, зависимость шагов и откат при ошибке раннего шага?
  • Для concurrent есть ли бюджет, политика объединения и правило разрешения конфликтов?
  • Для group chat понятно ли, кто владеет результатом и как ограничивается рост transcript/context?
  • Для handoff есть ли пакет передачи с целью, ограничениями, владельцем, контекстом политики и ссылкой на трассу?
  • Для magentic/динамической оркестрации есть ли жесткие лимиты, трасса маршрута, условие остановки и отдельное покрытие оценками?
  • Зафиксированы ли компромиссы по задержке, стоимости, безопасности и отладке до запуска?

Читать дальше:

Проверка шлюза инструментов

  • У каждой возможности есть владелец, уровень риска и утвержденный статус в инвентаре?
  • Ясно ли, читает инструмент данные или выполняет запись?
  • Не показываете ли вы модели слишком большой каталог инструментов вместо узкого релевантного поднабора?
  • Есть ли профиль выполнения: песочница, сетевой доступ и разрешенные исходящие соединения?
  • Проверяет ли шлюз личность действующего лица и политику до выполнения?
  • Есть ли семантика идемпотентности и политика повторов?
  • Понятно ли, когда нужно подтверждение, а когда инструмент может исполниться автоматически?
  • Есть ли аудиторский след на каждое внешнее действие?
  • Понимает ли команда роли MCP: хост, клиент и сервер, а не смешивает их в одну интеграцию?

Читать дальше:

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