Проектирование агентов ИИ для окружающей среды: каналы активации, экономичный режим сна и безопасное возвращение к активному состоянию.

Большинство текстов о агентах ИИ начинаются с момента поступления запроса и запуска цикла обработки. Агент, который самостоятельно отслеживает почтовые ящики, очереди и панели управления, почти всё своё время находится в противоположном состоянии: ничего не происходит, и системе приходится снова и снова принимать решение о том, только ли что что-то началось. Этот гид посвящён именно этому периоду бездействия. К концу вы сможете спроектировать механизм, определяющий момент пробуждения агента, сведя затраты на его «сон» почти к нулю, обеспечить безопасность каждого пробуждения от дублирования, устаревших данных и внешних вмешательств, а также оценить, действительно ли вся эта конфигурация помогает людям, чью работу она прерывает.

Сценарий предосторожности: оплата за каждый «нет»

Представьте команду, которая создаёт агента для мониторинга почты с запросами поддержки и канала связи в режиме дежурства. Цель проста: выявлять всё, что требует вмешательства человека, ещё до того, как кто-либо это заметит. Прототип выглядит впечатляюще на демо-демонстрациях. Но затем приходит первый ежемесячный счёт, который оказывается больше суммы всех расходов команды на лицензии IDE, время работы инструментов CI и средства для отслеживания состояния системы вместе взятых, за агента, который совершил примерно одиннадцать полезных действий за тридцать дней.

Причина заключается в архитектуре, которую никто не описал письменно. Чтобы «наблюдать» за почтовым ящиком, каждые две минуты запускалась запланированная задача, собиравшая последние сообщения и запрашивавшая у специальной модели, требует ли что-либо из них внимания. За месяц это происходило примерно двадцать две тысячи раз. Почти все ответы были тщательно обоснованным «нет». Одиннадцать ответов «да» были отличными, но в целом преобладали отрицательные результаты. Самой дорогой операцией, выполняемой системой, примерно в три порядка дороже остальных, была проверка на отсутствие изменений.

В другой части той же инфраструктуры находилась старинная задача cron, которая каждую минуту проверяла уровень заполнения диска. За всё время своей работы она практически ничего не стоила. Разница между этими подходами и есть урок всей этой темы: ожидание — это то, что нужно специально спроектировать, а не то, что происходит автоматически.

Суть заключается в следующем. Агент в среде определяется скорее тем, что его активирует, чем тем, что он делает после активации. Настоящая инженерная задача — создать механизм, который как можно дешевле определяет, какое из тысяч входящих событий заслуживает внимания модели, в сочетании с режимом покоя, который не требует затрат до момента активации. Агенты для чата никогда не сталкиваются с этой проблемой, поскольку человек уже решил, стоит ли отправлять сообщение, прежде чем его написать. Если убрать этого человека из цепочки триггеров, задачей становится сортировка. Если решать её с помощью самой большой модели, это фактически означает нанять самого дорогого специалиста для сортировки сообщений.

Это основано на нескольких идеях, которые заслуживают отдельного рассмотрения: долговечная работа (процесс, способный находиться в состоянии паузы несколько дней без потребления вычислительных ресурсов), временная ориентация (то, что агент должен заново усвоить о «настоящем моменте» при возобновлении работы) и смещение целей у долгоживущих агентов. Они рассматриваются ниже там, где это важно.

Каждый запрос уже является событием

Запрос в чат кажется естественной отправной точкой для агента, но за ним скрывается много неосознанной работы. Человек, отправивший запрос, сделал три вещи до обработки любого символа: он определил, что ситуация требует действий (это и есть первичная оценка), кратко изложил суть в нескольких предложениях (это формирование контекста) и отправил запрос в определенный момент времени (это выбор момента). Чат-агент на самом деле представляет собой агента, работающего над слоем событий, созданным человеком.

Агенты в реальном времени — термин, популяризированный LangChain для обозначения агентов, которые потребляют поток событий и реагируют на них, возможно обрабатывая несколько событий одновременно, — исключают участие человека. Все три бесплатных сервиса исчезают. Остается инженерная проблема с пятью разными типами входных данных, каждый из которых ведет себя по-разному:

• Сообщения. Человек пишет агенту. Такие случаи встречаются редко, уже фильтруются с помощью человеческого суждения и содержат четкие намерения. Это простой случай.
• Расписания. Cron и все подобные ему системы. Расписание срабатывает независимо от того, произошло ли что-либо. Это полезно, потому что позволяет захватывать то, что упускают потоки событий, но это также расточительно, поскольку большинство срабатываний остаются без реакции.

События. Вебхуки, сообщения в очереди, новые строки в таблице. Внешний мир передает их вам. Они поступают в больших объемах, порциями, без какой-либо сортировки, и создаются другими системами или незнакомцами, а не вашим пользователем.

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

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

Проектирование агента в режиме ожидания подразумевает принятие решений относительно того, как они взаимодействуют друг с другом. Кто из них может пробудить агента? Что находится между сырым сигналом и моделью? Что агент воссоздаёт о мире после пробуждения? Ошибка в одном направлении приводит к описанной выше ситуации, когда модель интерпретирует тишину каждые две минуты. Ошибка в другом направлении заставляет агента спать на протяжении всего инцидента, который он должен обнаружить.

Воронка пробуждения: триаж как лестница

Ключевым экономическим фактом является то, что вызов модели — это самая дорогая условная операция, которую только можно выполнить. Задание вопроса модели о том, «имеет ли это значение?», стоит примерно в пять–семь порядков дороже, чем использование фильтра базы данных для получения ответа на тот же вопрос по структурированным данным. Поэтому рабочая архитектура никогда не представляет собой прямую связь от события к модели. Это фильтр: серия этапов, каждый из которых дешевле предыдущего и удаляет большую часть информации, поступающей к нему.

Первый этап: структурные правила

Первый этап практически не стоит ничего. Это простой код, который анализирует характеристики события: его тип, отправителя, метки, репозиторий или очередь, откуда оно пришло. Рассылки, автоматизированные уведомления, комментарии ботов и события из проектов, которыми не владеет агент, могут быть просто добавлены сюда без какой-либо оценки. В типичной почтовой корзине большая часть сырых данных никогда не требует дальнейшей обработки. Если на этом этапе отбрасывается меньше половины сырых событий, ваши правила, вероятно, слишком строгие.

Второй этап: дебаунсинг и объединение

События поступают пачками, имеющими общую причину: десятки писем в одном потоке обсуждения, пакет с тридцатью коммитами, сотни оповещений от одного неисправного коммутатора. Подходящей единицей для внимания агента является не отдельное событие, а ситуация, лежащая в его основе. Поэтому на этом этапе определяется короткий временной интервал, поступающие события группируются по ключу корреляции, такому как поток обсуждения, запрос на внесение изменений или инцидент, и для каждой ситуации передается единый объединенный сигнал.

На этом этапе также необходимо терпение. Документ, изменившийся один раз, скорее всего, изменится ещё несколько раз в течение следующих нескольких минут. Если вы запускаете обработку через фиксированный интервал после последнего изменения, а не сразу после первого, вы значительно сокращаете количество запусков, и каждый из них получает более полную картину. Тот же принцип действует всякий раз, когда несколько пользователей изменяют общее состояние: серия из сорока событий обычно описывает один факт.

Примечание по механизмам наблюдения: опрос и сравнение, но никогда не опрос и оценка

Механизмы наблюдения подразумевают принятие решения о затратах, чего не требуется от других триггеров. Кто-то должен замечать изменения, и для этого существует ровно три способа:

• Источник отправляет сигнал. Вебхук или подписка уведомляют вас о изменении состояния. Если такая возможность существует, используйте её.

Вы осуществляете опрос и сравнение. По заданному графику загружается текущее состояние, оно сравнивается с предыдущим снимком, и событие генерируется только тогда, когда обнаруживаются различия.

Вы осуществляете опрос и принимаете решение. По заданному графику загружается состояние, после чего задаётся вопрос модели по нему. Именно это и пошло не так в приведённом выше сценарии.

Сам процесс опроса заслуживает лучшей репутации, чем предполагает этот сценарий. Опросы дешевы; дорого стоит сама оценка. Задача, запланированная на определённое время для загрузки страницы, её хеширования и сравнения с предыдущим хешем, стоит крайне незначительную сумму в год. Многие системы не предоставляют вебхуков, поэтому правило «никогда не проводить опросы» не является реалистичным. Настоящее правило заключается в том, что процесс опроса должен завершаться сравнением изменений, а не вызовом модели. Необходимо сделать скриншот, сравнить его и пропустить в систему только обнаруженные изменения в качестве событий, которые будут подвергаться тем же правилам и классификатору, что и всё остальное. Вопрос о том, изменилось что-либо, решается с помощью функции хеширования. Вопрос о том, имеют ли изменения значение, — это вопрос, на решение которого предназначена модель.

Третий этап: дешёвая классификация

То, что выживает после применения правил и процесса объединения, попадает в небольшую, быструю и недорогую модель с преднамеренно узким запросом, например: «Ответьте одним словом: срочно, релевантно или игнорировать». Это знакомая каскадная система маршрутизации моделей, применяемая для уведомлений: недорогой уровень поглощает неоднозначность, которую невозможно было выразить с помощью фиксированных правил, и только результаты категорий «релевантно» и «неопределено» передаются на более высокий уровень. Небольшая модель, которая права в 92% случаев, стоящая перед большой моделью, стоимость которой в тридцать раз выше, — вот вся экономическая суть этого уровня. Чтобы получить более полное представление о том, откуда происходят затраты на агентов, ознакомьтесь с моделью затрат, основанной на архитектуре, для агентных ИИ.

Четвертый этап: агент

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

Пятый этап: человек

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

Арифметика редизайна

Примените это к команде с самого начала. Предположим, они изменят способ получения сообщений с опросов на вебхуки и добавят структурные правила, что позволит устранить примерно 70% первичных событий, поскольку это рассылки и автоматизированные письма. Объединение сообщений по темам уменьшит объем оставшихся событий примерно на 60%. Затем небольшой классификатор отметит около 85% оставшихся событий как «игнорировать». Теперь модель выполняется примерно тридцать раз в месяц, вместо двадцати двух тысяч, при этом продолжают происходить те же одиннадцать важных действий. Стоимость каждого полезного запуска снижается более чем в десять раз.

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

Хороший сон: почему неактивный агент не стоит ничего

В моменты простоя идеального агента окружающей среды вообще не существует. Он не работает тихо на фоне; нет ни процесса, ни контейнера, ни специального контекста. Вся его сущность представляет собой запись в хранилище: идентификатор, конфигурация, указатель на его память и список подписок. Это логический вывод концепции «ожидание — это просто состояние» в контексте устойчивой эксплуатации. Запущенный процесс, находящийся в состоянии паузы, — это данные в состоянии покоя, а хранение таких данных является одним из самых дешевых услуг, которые предлагают облачные провайдеры.

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

Восстановление времени

Агенту, проснувшемуся после шести дней сна, необходимо сообщить текущее время, и ему нужно пересчитать все относительные ссылки, которые у него имеются. Заметка с текстом «крайний срок — пятница», написанная во вторник, уже к следующему понедельнику становится неверной. Необходимо сообщить агенту текущее время в часовом поясе его руководителя, а также время его последнего пробуждения, чтобы он знал, как долго находился в спящем режиме.

Рассматривайте память как потенциально устаревшую

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

Возвращайтесь к цели

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

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

Что включает хороший контекст пробуждения

«Реконструкция» звучит абстрактно, пока вы её не создадите. Хорошо составленный запрос на пробуждение похож на инструкцию, которую система собирает по частям:

• Файл с целью, в неизменном виде. Причина существования этого агента и ограничения на то, что ему разрешено делать.

Часы. Текущее время в часовом поясе руководителя, а также временная метка предыдущего пробуждения.

Ситуация. Обобщенная информация, ставшая причиной данного пробуждения. Это не сорок сырых событий, а описание их структуры.

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

Релевантная память. Небольшой набор постоянных заметок, оставленных при предыдущих пробуждениях, таких как «этот клиент предпочитает звонки вечером» или «при последнем срабатывании этого оповещения причиной был кэш». Эти заметки извлекаются по мере необходимости, а не накапливаются.

Бюджет. Лимиты токенов, доступные инструменты и предел автономии для данного пробуждения.

Обратите внимание на отсутствующее: записи предыдущих сеансов. Их выводы сохраняются, поскольку каждый сеанс закрепляет полученные знания в памяти перед окончанием, но временные данные каждой сессии удаляются. Благодаря этому двухсотый сеанс остается таким же точным, как и второй. Это также снижает затраты, поскольку краткое описание в несколько тысяч токенов заменяет запись, длина которой может достигать сотен тысяч.

Гарантии качества с элементами ИИ

Сеансы также подвержены классическим проблемам распределенных систем.

Доставка происходит как минимум один раз, поэтому каждая операция должна быть идемпотентной. Коллекции задач и сервисы webhook имеют право отправлять вам одно и то же сообщение дважды. Для безсостоянийного уведомителя дубликат — это просто шум. Однако для агента, обладающего инструментами, дубликат может означать выполнение одной и той же необратимой операции дважды. Решение стандартное: генерировать ключ идемпотентности из события и проверять его перед тем, как агент выполнит действие, которое нельзя отменить. Если вам нужно вспомнить основы, ознакомьтесь с том, как работают ключи идемпотентности в Node.js POST-эндпоинтах.

Агентам, работающим в среде, также требуется вторая проверка на уровне ситуации. Агент, который пробудился из-за сообщения «PR #482 можно объединить», должен убедиться, что запрос на объединение по-прежнему возможен, прежде чем предпринимать действия. С момента пробуждения могли пройти несколько минут, и кто-то другой — будь то человек или ещё один агент — уже мог обработать этот запрос. Соперничество во время пробуждения представляет собой обычные конкурентные ситуации с длительной задержкой между причиной и следствием.

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

Продвинутые проблемы: агрессоры, внимание, конкурентность и кризисные ситуации

Триггером является поверхность атаки

При рассмотрении пяти типов входных данных необходимо учитывать аспекты безопасности. Любой, кто может отправить событие, фактически может активировать агента. Полезная нагрузка webhook-сообщений, тела электронных писем и комментарии к задачам, способные запустить процесс активации, являются ненадежным текстом, который попадает к модели с доступом к инструментам. В отличие от чатов, во время активации нет человека, который мог бы заметить ошибку. Тщательно составленное «срочное» письмо не только тратит ресурсы на активацию, но и определяет, что будет думать агент, что является первым шагом в почти всех цепочках инъекции команд.

Применяются все стандартные меры снижения рисков. Содержимое событий следует рассматривать исключительно как данные. Среду выполнения агента необходимо изолировать строже, чем чат-агента. Необходимо разделять три опасные возможности: доступ к приватным данным, воздействие ненадежного контента и возможность внешней связи; агент, отслеживающий почту и обладающий широким набором инструментов для отправки сообщений, имеет все три эти возможности плюс дополнительные функции. Добавьте правило, специфичное для средовых систем: степень автономии должна соответствовать степени доверия к триггеру. Активация, вызванная вашим собственным расписанием, может привести к действию, тогда как активация из-за контента от постороннего источника должна в основном служить уведомлением.

Человек — самый дефицитный ресурс в этом цикле

Большая часть действий, выполняемых агентом в среде ambient, представляет собой прерывания деятельности людей, и прерывания — это своего рода «валюта», стоимость которой снижается при чрезмерном использовании. Полезной моделью, хорошо описанной в подходе LangChain к почтовому ящику агентов, является трехэтапная структура того, о чём агент может попросить человека:

• Уведомить. Только для получения информации; действий не требуется.
• Задать вопрос. Агенту нужен один конкретный факт, прежде чем он сможет продолжить.
• Представить для рассмотрения. Агент подготовил действие и просит одобрения.

Особенность данной ситуации заключается в том, что эта «лестница» одновременно служит показателем качества. Записывайте, как люди реагируют на каждое прерывание: принимают меры, игнорируют его или проигнорируют. Это позволяет получить точные данные по всему процессу. Агент, у которого уведомления игнорируются в 80% случаев, не просто теряет 80% эффективности — это также способствует тому, что люди научаются отключать уведомления, и тогда полезные 20% также исчезают. Усталость от уведомлений мешала внедрению систем мониторинга на протяжении десятилетий ещё до появления языковых моделей, и красиво сформулированные тексты уведомлений ничего не меняют в этом отношении.

Одновременность выполнения задач: сверхспособность с сопутствующими рисками

Определение амбиентного агента включает возможность одновременной обработки нескольких событий, и этот аспект легко упустить из виду. Чат-агент обрабатывает один диалог. Амбиентный агент может одновременно иметь сорок активных состояний, каждое из которых находится в отдельном чистом контексте и содержит лишь частичное представление общей реальности. Вы получаете многокомпонентную систему агентов без особого желания, вместе с проблемами общего состояния. Два активных состояния, возникшие в результате связанных событий, могут захватить один и тот же билет, записать противоречивые ответы в одном потоке или взять на себя одну и ту же задачу, причем ни одно из них не сможет этого заметить, поскольку чистые контексты не имеют между собой ничего общего.

Способы устранения проблем, в приблизительном порядке приоритета:

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

Запись данных по маршруту через единого записывающего процесса — когда разделение на части недостаточно.

Использование оптимистичной конкурентности — когда два процесса действительно должны взаимодействовать с одним и тем же объектом, причём конфликт рассматривается как ошибка; в этом случае второй записывающий процесс переоценивает своё решение вместо того, чтобы перезаписать первый.

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

Режим шторма

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

Аналогом агента является детектор штормов, который сравнивает текущий уровень событий с базовым показателем, и при его резком повышении переводит механизм в другой режим. В режиме шторма все связанные данные объединяются в одну ситуацию, пробуждается отдельный агент с кратким обзором информации, и ему передаётся конкретная задача: это шторм; подготовьте краткое резюме, определите наиболее вероятную причину и отправьте одно уведомление. Контроль затрат важен, поскольку именно из-за нагрузки в конце срока расходы могут выйти из-под контроля, но ещё важнее фактор внимания. Во время инцидента способность человека справляться с перерывами снижается именно в момент роста частоты событий. Режим штормов — это механизм, учитывающий эту закономерность.

Оценивайте неактивных агентов как продукт

Самые важные показатели — это два числа:

• Стоимость за каждый полезный сигнал. Общая сумма расходов делится на количество сигналов, которые человек в последующем считает полезными. Это экономика единиц, применённая к вашей собственной системе.
• Точность и полнота сортировки. Их можно очень эффективно оценить в автономном режиме. Пропустите через механизм отбора события за тридцать дней и сравните сигналы, которые он мог бы генерировать, с реальными реакциями людей.

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

Автономия, зависящая от времени

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

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

Закодируйте это как поиск в механизме обработки, который учитывает доверие к триггеру, степень серьезности действия и доступность человека, а затем соотносит эти факторы с одним из трех результатов: действовать немедленно, поместить в очередь на утро или сразу отправить уведомление. Вариант ожидания в очереди до утра является незамеченным героем. Большинство вещей, на которые обращает внимание агент в 3 часа ночи, прекрасно подходят для рассмотрения в 8:55 утра, уже сопровождаемые предложенным агентом действием, и будут готовы примерно в то время, когда будет подан первый кофе.

Паттерны в реальных системах

Помощник по электронной почте с папкой для сообщений от людей

Референсный агент LangChain обрабатывает электронную почту: он составляет ответы, сохраняет сообщения и передаёт их на более высокий уровень обработки. Его дизайн взаимодействия более показателен, чем функция составления текстов. Команда, разрабатывающая его, рассматривает участие человека не как уступку, а как способ снижения рисков и облегчения работы, укрепления доверия и формирования долгосрочной памяти. Их инструмент Agent Inbox — единая панель для просмотра всех открытых диалогов между человеком и агентами — представляет собой оформленную в материальной форме систему уведомлений, задавания вопросов и проверки. Одна из постоянных шуток этого проекта гласит, что если вас игнорируют, это определённо вина агента; она отражает суть экономики внимания: агент существует для того, чтобы человек тратил своё внимание более разумно, а шутки возникают, когда это не происходит.

Запланированные агенты в инструментах программирования

Крупные платформы для кодинга добавляют агентов, которые работают по расписанию или при событиях в репозитории вместо ответов на запросы; примерами могут служить рутины Claude Code и запуски, инициируемые GitHub — ситуации, с которыми сталкивались многие разработчики. Проверьте актуальную документацию, поскольку эти функции быстро развиваются. Во всех подобных решениях встречаются два основных подхода к проектированию, оба из которых подтверждают приведённые здесь аргументы. Каждый запуск начинает новую сессию, при этом преемственность сохраняется в файлах и памяти, а не в бесконечных записях. Уровень инициации запуска основан на традиционной инфраструктуре, такой как выражения cron, фильтры webhook и условные структуры YAML; нигде в процессе обработки не используется модель. Интеллектуальные решения дороги, в то время как механизмы триггеров дешевы, поэтому продукты сохраняют их разделёнными.

Наблюдатели за инфраструктурой

Провайдеры облачных сервисов описали шаблоны для агентов, которые отслеживают инфраструктуру и проактивно сообщают о выявленных проблемах. Хорошо спроектированные решения представляют собой практическое применение данного руководства. События поступают из встроенной шины событий платформы, поэтому структурная фильтрация доступна бесплатно. Перед вызовом любого агента события коррелируют между собой. В случае возникновения серьезных проблем агенты генерируют отчеты для рассмотрения, вместо того чтобы самостоятельно применять исправления. Ценным элементом, который стоит заимствовать, является градиент доверия: чем дальше идет предлагаемое действие, тем выше оно поднимается по иерархии уведомлений, вопросов и проверок. Наблюдение может осуществляться автономно; вмешательство — под контролем.

Команда по опросам через четверть года

Вернитесь в команду после завершения процесса переработки. Теперь их система включает вебхуки, объединение потоков информации с десятиминутным периодом тишины, небольшой классификатор, весь промпт для которого помещается на карточке индекса, а также примерно тридцать запусков моделей нового поколения в месяц. Выделяются два ключевых результата: стоимость каждого полезного запуска снизилась примерно в сорок раз, и, к удивлению, показатель точности оценок вырос. Ранее дизайн системы разделял ситуации на произвольные двухминутные фрагменты, из-за чего по крайней мере дважды игнорировалась частичная картина ситуации, которая в целом явно требовала ответа «да».

Таким образом, переработка принесла не только снижение затрат. Группировка событий улучшила качество оценок, поскольку модель теперь анализировала целые ситуации, а не их произвольные фрагменты. Проблемой никогда не был сам запланированный процесс; проблемой было требование к модели оценивать каждый его этап.

Выбор основных компонентов

Большинство элементов этой стек-архитектуры следует приобрести или повторно использовать, а не создавать заново.

• Инфраструктура триггеров. Cron и его аналоги с управлением; шины событий и очереди вроде EventBridge, Pub/Sub, Kafka или обычные webhook’и; а также расписания и сигналы в движках рабочих процессов, таких как Temporal, Restate или Inngest, которые также обеспечивают надежное хранение данных. Первый и второй этапы процесса напрямую соответствуют функциям этих инструментов.

Инфраструктура на основе агентов в окружении. LangGraph с возможностью сохранения данных, прерываний и поддержкой cron, а также open-source решение Agent Inbox; запланированный и триггерный режимы основных кодинг-агентов, таких как рутины Claude Code и интеграции с GitHub Actions; а также все больше коннекторов, преобразующих электронную почту или webhook в запуск агентов. Оценивайте все эти решения по трём критериям: где происходит сортировка информации (она должна выполняться до обработки моделью), что восстанавливается после активации агента, и что в конечном итоге видит пользователь.

Уровень сортировки информации. Подойдёт любая небольшая, быстрая модель. Ключ к эффективности заключается в чётком формулировании запросов и оценке результатов в автономном режиме, а не в выборе конкретной модели.

Почтовый ящик для агентов. Используйте Agent Inbox от LangChain, если нужна готовая платформа, или текущие каналы вашей команды — Slack, электронную почту или систему тикетов, при этом три основных действия должны быть чётко определены и контролируемы.

Потратьте свой бюджет на нововведения на реализацию воронки и восстановление контекста после события, а всё остальное купите. Механизмы планирования — это уже решённая проблема, проверенная десятилетиями практики. Домашний цикл, проверяющий модель каждые две минуты, таковой не является.

Вся структура размещается в нескольких строках псевдокода. Читайте его сверху вниз по принципу воронки: бесплатная проверка правил, формирование ситуации (без возврата результата пока событие ещё не устаканилось), дешёвая классификация, защита от дублирования доставки с помощью принципа идемпотентности, восстановление контекста после события на основе текущего времени, обработка файла целей и новых данных, запуск агента в рамках установленного бюджета, и наконец доставка через один из трёх способов обработки почты.

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

Обратите внимание на местоположение проверки идемпотентности: после дешевых фильтров, но до любых дорогих или необратимых операций. Ее также можно разместить раньше; главное — чтобы никакие дубликаты не попадали в функцию agent.run. В реальной системе проверка перед действием также должна выполняться в момент rebuild, поскольку именно тогда становится доступным новое состояние.

Руководство по способам сбоев

• «Костер опросов». Дорогая модель постоянно запрашивается о проверке чего-то, что на самом деле отсутствует. Решение: сначала применять правила и процедуры объединения данных перед вызовом любой модели, затем использовать дешевую модель перед дорогой.
• «Громоподобное стадо». Одна проблема приводит к тысячам последующих сбоев. Решение: режим кризиса с детектором частоты сбоев, полным объединением данных, одним агентом и одним уведомлением.

Двойной след события. Переданное заново событие попадает к агенту, который может предпринять реальные действия. Решение проблемы: использование ключей идемпотентности для обработки следов событий и проверка ситуации перед принятием действий.

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

Внедренный след события. Содержимое от внешнего источника определяет, на чем сосредотачивает внимание ваш автономный агент. Решение проблемы: рассматривать содержимое событий как данные, увеличивать степень автономии в зависимости от надежности триггера и более строго контролировать агентов, работающих в окружении, чем чат-агентов.

Приглушенная почтовая корзина. Точность прерывания снижается до тех пор, пока люди перестают слушать. Решение: отслеживать действия, проигнорированные и пропущенные для каждого уведомления, и считать показатель действий ниже 50% сбоем.

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

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

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

План на неделю для начала работы

1. Проверьте свои триггеры. Запишите каждый путь, который может запустить ваш агент сегодня, и стоимость каждого такого запуска. Отметьте все пути, сводящиеся к «запуску модели по таймеру», как первые для исправления.
2. Создайте первый этап. Разместите структурные фильтры перед каждым триггером и измерьте коэффициент отклонения. Если он ниже половины, ваши правила слишком осторожные.

Объединение данных. Выберите ключи корреляции, такие как поток работы, запрос на внесение изменений, инцидент или клиент, добавьте механизм затухания сигналов и измените тип входных данных агента с «событие» на «ситуация».

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

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

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

Выполните два теста. Перепустите запись всплеска, чтобы убедиться, что режим шторма объединяет его элементы, и отключите вебхук на час, чтобы проверить, обнаруживает ли функция сканирования пробелы. Наконец, впервые рассчитайте стоимость за каждый полезный след и отобразите её рядом с расходами токенов.

Заключение: восприятие окружающей среды, человеческая приверженность

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

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

У обеих сторон есть свои аргументы, и именно в этой «трубке» они встречаются. Мониторинг всего является возможным, но стоит отметить, что причиной успеха приведённых выше примеров стала традиционная инженерия: фильтрация, устранение помех, идемпотентное обработка данных, задачи на согласование и учёт риска перегрузки от алертов. Для принятия решений всё равно требуется согласие, что и отражено в последовательности действий — уведомление, обсуждение и проверка: автономия при выявлении проблем, иерархическая передача ответственности при принятии мер. Секрет заключается в агентах, которые широко наблюдают, редко вмешиваются и запрашивают одобрение перед изменением чего-либо важного.

Полезное упражнение займёт один вечер. Выберите самый интенсивный поток уведомлений в вашем рабочем дне и разработайте для него структуру «трубки»: какие простые правила могут их отфильтровать, что может быть объединено, какая простая модель сможет их классифицировать и что действительно требует немедленного внимания. Вы разработаете своего первого агента до того, как напишете хотя бы кусок его кода.