Инженеры Amazon Quick разложили агентную работу на четыре вопроса: When, What, Who и How. Каждому соответствует примитив: триггер запускает работу и несёт задачу, агент берёт её на себя, возможности выполняют, накопленный контекст переносит уроки в следующие запуски. Таксономию команда описала в первом посте серии об устройстве своей агентной платформы.
Триггеров четыре типа: инициированные человеком, делегированные другим агентом, запланированные и событийные. Тип запуска задаёт не только момент старта, но и стиль исполнения. Фоновая задача по расписанию при неопределённости может просто ничего не сделать, а та, которую инициировал человек, скорее задаст уточняющий вопрос.
Зачем это тому, кто собирает своего агента на LangChain или локальной модели: разметка работает как чек-лист. Она заставляет ответить, что именно запускает задачу, кто её исполняет, чем именно и что останется в памяти после прогона. Дальше разбор каждого примитива и практический кейс: ежедневный дайджест из Slack, собранный четырьмя разными способами.
В чём проблема: агентные примитивы переизобретают под разными названиями
Агенты Amazon Quick прошли путь от ответов на вопросы к действиям: планирование встреч, исследование, генерация отчётов. По мере роста числа сценариев вылезла проблема уровня команды, а не кода. Общего определения примитивов не было, и одни и те же сущности возвращались под новыми именами: актор, который делает работу; сигнал, который её запускает; упакованная процедура; память, переносящая уроки вперёд.
Картина знакомая. В одном проекте «агентом» называют системный промпт, в другом cron-задачу с вызовом модели, в третьем цепочку из пяти шагов на оркестраторе. Спорят о терминах, хотя архитектурные решения у всех примерно одни и те же. Таксономия переводит разговор из плоскости «как это назвать» в плоскость «где именно у нас живёт эта логика».
Почему «ещё один фреймворк» - не главная новость
Новых сущностей Amazon не изобрела. Ценность в разметке уже существующих: каждый элемент получает место и роль, команда перестаёт собирать четвёртую версию одного и того же «умного планировщика». Сами авторы отмечают, что большая часть фреймворка по замыслу остаётся невидимой для конечных пользователей, а общий словарь нужен тем, кто строит поверх платформы.
Четыре вопроса как каркас: When, What, Who, How
Схема в одну строку: триггер отвечает на «когда» и «что», агент на «кто», возможности на «как», а обучение из среды выполнения возвращается обратно в систему и замыкает петлю. В посте это показано на схеме, где обратная связь идёт из рантайма сессии в общий контур.
Нюанс, который легко пропустить: триггер не сводится к кнопке «старт». Он несёт инструкции. Человеческое сообщение одновременно служит моментом активации и описанием задачи: «сделай дайджест по каналу X за сутки» это и запуск, и техническое задание.
Для инженера каркас ложится на привычные слои бэкенда:
- триггер как событие, вебхук или эндпоинт;
- агент как сервис-исполнитель с конфигом;
- возможности как функции, библиотеки и пайплайны;
- накопленный контекст как состояние, кеш и логи.
Аналогия полезна не точностью, а тем, что переносит на агентов обычные вопросы: где хранится состояние, что происходит при повторе, кто отвечает за ошибку. Про контекстную инженерию для долгоживущих агентов есть отдельный разбор проактивных агентов 2026 года: типовой стек уже сложился, а открытых вопросов по памяти и уведомлениям пока больше, чем ответов.
Триггеры: четыре типа запуска и почему тип меняет поведение агента
В источнике перечислены четыре типа: инициированный человеком, делегированный другим агентом, запланированный и событийный. Разница не только в источнике сигнала, но и в том, как агент ведёт себя, когда данных не хватает.
Инициированный человеком и делегированный агентом
Первый тип: человек открывает диалог и просит сделать задачу. Интерактивно, синхронно, в разговорной форме. Пользователь ждёт ответа сейчас, поэтому агент может позволить себе уточняющие вопросы и длинный цикл рассуждений.
Второй тип: агент посреди задачи вызывает другого агента под подзадачу. Программно, композируемо, потенциально рекурсивно. По сути это внутренний API между агентами, и к нему применимы обычные требования: таймауты, идемпотентность, ограничение глубины вызовов и защита от циклов вида «A вызвал B, B вернулся к A». Без лимита глубины рекурсивное делегирование съедает бюджет токенов за пару минут.
Запланированный и событийный
Третий тип, активация по времени. Пример из источника: «запускать финансовое исследование каждый понедельник в 9 утра». Детерминированный старт, одни и те же постоянные инструкции между прогонами. Удобно для регулярных отчётов и дайджестов. Слабое место: запуск происходит, даже если в данных ничего не изменилось, и токены уходят на пересказ того же самого.
Четвёртый тип, сигнал от внешней системы: новое письмо, упоминание в Slack, изменение файла, вебхук. Реактивность выше, зато появляется шум: дубликаты событий, лавина уведомлений при массовой правке файлов, необходимость дедупликации и идемпотентной обработки. Вебхук, который приходит дважды, не должен порождать два отчёта.
Ключевой тезис авторов: тип триггера задаёт характер исполнения. Запланированная фоновая задача может вести себя консервативно и при неопределённости не делать ничего. Задача, инициированная человеком, ведёт себя отзывчиво и вместо остановки спрашивает.
| Тип триггера | Стратегия при неопределённости | Где уместен |
|---|---|---|
| Инициированный человеком | Задать уточняющий вопрос, показать промежуточный результат | Разовые задачи, разбор данных, черновики |
| Делегированный агентом | Вернуть ошибку вызывающему, не уходить в рекурсию | Подзадачи внутри большого пайплайна |
| Запланированный | Промолчать или отправить короткое «без изменений» | Регулярные отчёты, дайджесты, мониторинг |
| Событийный | Дедуплицировать сигнал, действовать по порогу значимости | Реакция на письма, упоминания, изменения файлов |
Агент: постоянный обучающийся актор, а не набор инструкций
Определение из поста: агент это постоянный обучающийся актор. Он Who в любом исполнении и якорь, на котором накапливается обучение. Два агента с одинаковым входом могут выдать разный результат, потому что несут разные инструкции, разные возможности и разные истории.
Формулировку стоит держать в голове при проектировании: агент не инструкции, которым он следует, а сущность, которая их интерпретирует. Разница практическая. Если агент равен промпту, любая правка поведения означает переписать промпт и надеяться, что ничего не сломалось. Если агент отдельная сущность с инструкциями, возможностями и памятью, правка живёт в конкретном слое.
Состав по источнику: инструкции как постоянное руководство, динамически обновляемые возможности и память, накапливаемая в процессе использования. Оговорка по факту: доступный текст поста обрывается на описании инструкций как первой из трёх составляющих, полный перечень в опубликованном фрагменте не раскрыт.
Почему LLM - сменный параметр
Если идентичность агента держится на инструкциях, возможностях и истории, апгрейд модели превращается в замену вычислителя. Логика агента не переписывается, меняется тот, кто интерпретирует инструкции. Звучит удобно, и практический смысл в этом есть: команда может менять модель под бюджет и скорость, не пересобирая продукт.
Ограничение, которое нельзя пропустить: качество интерпретации инструкций и поведение в пограничных случаях зависят от модели напрямую. Смена LLM требует регрессионных прогонов на своих сценариях. Там, где раньше агент задавал вопрос, новая модель может уверенно сделать неверный вывод. Бесшовной замены не будет, набор тестов на реальных задачах обязателен. Как такой контур выглядит в самописном агенте, разобрано в материале про архитектуру, метрики и код на Python.
Память и накопленный контекст: что именно переносится вперёд
В посте обучение из среды выполнения сессии возвращается в систему и связывает триггеры, агентов и возможности. Без этого возврата агент каждый раз начинает с нуля, и регулярная задача превращается в регулярное повторение одних и тех же ошибок.
Готового рецепта, что писать в память, в источнике нет. Рабочий набор вопросов при проектировании выглядит так: какие предпочтения пользователя фиксировать (формат отчёта, каналы, тон), какие решения считать принятыми (какой источник основной), какие исправления сохранять (что агент сделал не так и как надо было). Отдельно правило очистки. Память без срока жизни и без ревью превращается в свалку, где свежая договорённость тонет под прошлогодней.
Возможности: спектр от полностью агентных до детерминированных
Возможности отвечают на How. В посте к ним отнесены инструменты, навыки и рабочие процессы. Дальше начинается спектр: на одном конце свобода, где модель сама решает, что вызвать, на другом жёсткий пайплайн с фиксированными шагами. Детальный разбор трёх категорий в доступном фрагменте отсутствует, поэтому ниже рабочее понимание каждого уровня с пометкой, что именно проверять по первоисточнику.
Инструменты: типизированная схема как контракт
Инструмент это атомарное действие с формальным описанием входов и выходов: получить данные, отправить сообщение, создать запись. Типизированная схема сужает пространство для галлюцинаций. Модель видит, какие поля обязательны и какого они типа, а код может провалидировать вызов до исполнения.
Ограничение простое: инструмент не умеет «сообразить» многошаговую процедуру. Если для результата нужно пять вызовов в правильном порядке, логика порядка живёт не в инструменте.
Навыки: прогрессивное раскрытие инструкций
Навык это упакованная процедура, которую агент достаёт по необходимости. Идея прогрессивного раскрытия: в контексте держится краткое описание (как называется, для чего нужен), а подробные шаги подгружаются, когда навык реально понадобился. Системный промпт не распухает до размера инструкции, а модель не отвлекается на детали, которые в текущей задаче не нужны.
Пример: навык «подготовить недельный отчёт» с пошаговым порядком, шаблоном и списком источников. Пока пользователь просит посчитать строки в таблице, эти инструкции в контекст не попадают. Классификация навыков по типу срабатывания, с активируемыми, статическими и триггерными, разобрана в материале про категории навыков AI-агентов.
Рабочие процессы: фиксированные шаги и обработка ошибок
Рабочий процесс задаёт порядок шагов заранее и обрабатывает сбои по написанным правилам: повтор с backoff, фолбэк на другой источник, эскалация человеку. Воспроизводимость и аудируемость здесь максимальные, видно, на каком шаге упало и с какими данными. Цена жёсткость. Нестандартный вход ломает процесс, и расширять его приходится вручную.
Критерии выбора уровня: повторяемость задачи, цена ошибки, требования к аудиту, изменчивость входных данных. Это не лестница «плохо - хорошо», а набор инструментов под разные риски. Регламентная операция с деньгами и разовый исследовательский запрос требуют разной степени свободы.
Кристаллизация и растворение: почему навыки не устаревают вместе с моделями
Аргумент, который стоит проверить на своём проекте: упакованные процедуры сохраняют ценность по мере роста моделей. Модель может стать умнее, но знание «как именно у нас принято закрывать период» из модели не появляется. Оно живёт в навыке или процессе, написанном под конкретную компанию, и остаётся там при смене LLM.
Переходы между уровнями описывают двумя словами. Кристаллизация: свободное агентное поведение превращается в навык или рабочий процесс, когда паттерн стабилизировался. Растворение: обратный ход, жёсткую процедуру распускают обратно в агентную свободу. Сами термины и детали разбора в доступном фрагменте поста не раскрыты, поэтому дальше рабочая интерпретация спектра, а не цитата.
Признаки для кристаллизации: задача повторяется, шаги устойчивы, ошибки дороги, результат нужно объяснять. Признаки для растворения: процесс постоянно ломается на нестандартных входах, ручные обходы множатся, модель уже справляется там, где раньше требовалась жёсткая последовательность.
Побочный эффект: кристаллизованный навык не зависит от модели, но зависит от окружения. Если завтра поменяется API источника, навык придётся править, и это нормальная часть сопровождения, а не повод отказываться от упаковки. Проектирование среды, в которой агент работает, разобрано в материале про средовой подход к AI-агентам.
Практика: ежедневный дайджест из Slack четырьмя способами
Запрос из поста: «следи за моим каналом в Slack и присылай ежедневный дайджест». Без общего словаря неясно, это новый агент, запланированная инструкция существующему, рабочий процесс или навык. С таксономией вариантов ровно столько, сколько комбинаций триггера и возможностей команда готова поддерживать.
- Запланированный триггер плюс рабочий процесс. Cron в 9:00, фиксированные шаги: выгрузить сообщения за сутки, отфильтровать по ключевым словам и участникам, собрать сводку по шаблону, отправить в канал. Максимум предсказуемости и минимум свободы. Минус: нестандартный день, когда обсуждение ушло в ветку, процесс не заметит.
- Запланированный триггер плюс навык. Тот же cron, но агенту доступен навык «дайджест канала» с пошаговыми инструкциями, который он подгружает при запуске. Баланс: формат и правила зафиксированы, а состав сообщений и расстановку акцентов агент выбирает сам.
- Событийный триггер плюс агент с инструментами. Реакция на упоминание или на ключевое слово в канале, инструменты чтения и отправки сообщений в руках модели. Максимум реактивности и свободы. Риски: дубликаты событий, лишние уведомления, разное качество сводок от запуска к запуску.
- Делегированный агентом триггер. Дайджест собирает не отдельная задача, а другой агент в цепочке, например агент утреннего брифинга, который вызывает подзадачу «собрать сводку по Slack» наравне с почтой и календарём. Удобно, когда источников несколько, но нужна защита от рекурсии и общий лимит на глубину вызовов.
Как выбрать вариант под свою задачу
Чек-лист на пять вопросов, который неплохо работает до написания кода:
- Задача повторяется каждый день по одному сценарию? Начинайте с рабочего процесса.
- Формат результата важен, а состав данных меняется? Берите навык с прогрессивным раскрытием.
- Ошибка стоит денег или доверия? Чем дороже, тем ниже по спектру, к фиксированным шагам и явной обработке сбоев.
- Нужно объяснять результат постфактум? Процесс с логами по шагам даст аудит дешевле, чем свободный агент.
- Входные данные каждый день разные и непредсказуемые? Свободный агент с инструментами окупается, но готовьтесь разбирать его решения.
Критерий выбора в одну фразу: сколько свободы вы готовы оставить агенту и чем готовы платить за предсказуемость. Оба ответа нормальные, плохо только когда решение не осознано и никто не помнит, почему выбрали именно этот вариант.
Что таксономия даёт на практике и где её границы
Польза от разметки видна в спорах: четыре вопроса снимают половину обсуждений на код-ревью. Что запускает задачу, кто её исполняет, чем именно, что останется в памяти после прогона. Если ответ на любой из вопросов звучит «не знаю, оно само как-то работает», архитектуру стоит пересмотреть.
Границы честные. Это описание подхода команды Amazon Quick (пост в блоге AWS), а не отраслевой стандарт. Термины могут не совпадать с другими фреймворками: то, что здесь названо навыком, в соседней платформе зовут скиллом, тулом или функцией, и спорить о словах бесполезно. Детали реализации памяти и фонового обучения в доступном фрагменте не раскрыты. Публикация объявлена первой в серии, дальше обещаны материалы про агентную операционную систему, фоновое обучение и проактивные ленты.
Практический вывод: берите схему как чек-лист при проектировании, а не как обязательную спецификацию. Проверьте своего агента по четырём вопросам, найдите слой, где сейчас смешаны триггер, инструкции и бизнес-логика, и разделите его. Начните с одной регулярной задачи: выбрать тип триггера, зафиксировать шаги и решить, что именно агент должен запомнить. Петля замыкается только тогда, когда накопленный контекст возвращается в систему, иначе вся конструкция остаётся набором красивых названий.