Что нового в Managed Deep Agents v0.9
LangChain выпустила Managed Deep Agents v0.9 в публичной бете 7 октября 2026 года. Релиз добавляет агенту три возможности: он создаёт расписания и повторяющиеся задачи прямо в диалоге через новый Schedules SDK, собирает свою конфигурацию заново на каждом запуске и ставит реакции в Slack, чтобы подтвердить получение сообщения до ответа. Анонс написал Nathan Drezner в блоге LangChain: What's New in Managed Deep Agents: schedules, per-run configuration, and Slack reactions.
Раньше эти задачи решались снаружи агента. Расписание жило в кроне или CI рядом с ним, а под каждую команду, канал или репозиторий держали свою почти одинаковую копию агента с урезанным набором инструментов. v0.9 переносит обе функции внутрь платформы. Фундамент для этого заложила предыдущая версия: v0.8 добавила user-owned credentials, пользовательскую память, HTTP-каналы и передачу файлов в Slack, о чём мы разбирали в статье Managed Deep Agents 0.8: пользовательская память, свои credentials и HTTP-каналы.
| Возможность | Что делает | Где полезна |
|---|---|---|
| Schedules SDK | Агент создаёт напоминания, фоллоу-апы и повторяющиеся задачи в ходе разговора | Дайджесты, напоминания, отложенные проверки |
| Конфигурация на каждый запуск | Одна деплой-инсталляция выбирает модель, инструкции, навыки, MCP-серверы и песочницу под конкретный запуск | Один агент на несколько команд, каналов или репозиториев |
| Реакции в Slack | Агент ставит 👀 по умолчанию на сообщение, пока обрабатывает запрос | Внутренние Slack-агенты с длинными задачами |
Ограничения у беты тоже есть, и о них честнее сказать сразу: сроки выхода из беты в анонсе не названы, детали реализации реакций не раскрыты, а список поддерживаемых моделей и песочниц для конфигурации на каждый запуск не приводится. Ниже разберём каждую возможность по отдельности и посмотрим, что она даёт на практике.
Расписания и повторяющиеся задачи: как работает Schedules SDK
Schedules SDK позволяет агенту создавать напоминания, фоллоу-апы и повторяющиеся задачи прямо в ходе разговора. Реплика вида «Напомни мне об этом завтра» превращается в объект расписания, который живёт на стороне платформы, а не в голове модели. SDK принимает cron-выражение, таймзону и промпт: промпт описывает, что именно выполнить при срабатывании, cron задаёт ритм, таймзона привязывает его к реальному времени команды. Формулировки и код взяты из анонса релиза (источник).
Ключевая деталь: расписание выполняется от имени человека, который его запросил. Агент работает с его правами и подключениями, а не с безликим сервисным аккаунтом. Когда cron срабатывает, LangSmith запускает новый запуск с указанным промптом. Расписание наследует канал, в котором его создали, поэтому будничное напоминание, запрошенное в Slack, при каждом запуске публикует новое сообщение в тот же разговор. Результат возвращается туда, откуда пришёл запрос, и это снимает необходимость руками маппить выводы агента на нужный чат.
Пример создания расписания из запуска
Минимальный вызов выглядит так:
await schedules.create(
owner={"type": "user"},
cron="0 9 * * 1-5",
timezone="America/Los_Angeles",
prompt="Write the daily digest.",
)Здесь owner={"type": "user"} означает запуск от имени пользователя, cron="0 9 * * 1-5" срабатывает в 9:00 по будням, а timezone задаёт, в какой зоне это время считать. Промпт не привязан к конкретной модели: его выполнит та конфигурация, которая достанется запуску.
Чтобы модель могла вызывать расписания в диалоге, создание удобно обернуть в инструмент. Схематично (пример сокращён, импорты и полный контекст окружения опущены):
@tool
async def remind_me(prompt: str, cron: str, timezone: str = "UTC") -> str:
schedule = await schedules.create(
owner={"type": "user"},
cron=cron,
timezone=timezone,
prompt=prompt,
)
return schedule.idИнструмент принимает текст задачи, расписание и таймзону, а возвращает идентификатор созданного расписания. Дальше агент может сослаться на него в ответе пользователю. Дополнительных полей SDK в анонсе не описано, так что не стоит рассчитывать на недокументированные параметры вроде приоритетов или цепочек запусков.
Одноразовые расписания и фоллоу-апы в треде
Если вместо cron указать at, расписание сработает один раз и ответит в исходном треде. Это ровно тот сценарий, где нужен фоллоу-ап: «проверь этот деплой через час» вернёт результат в ту же ветку, где прозвучал запрос, и контекст обсуждения не потеряется. Повторяющиеся расписания лучше держать на ежедневных дайджестах, еженедельных отчётах и регулярных напоминаниях, где результат логично публиковать новым сообщением.
Конфигурация на каждый запуск: одна инсталляция вместо копий агента
Вторая возможность меняет то, как агент собирается перед работой. Теперь агент оформляется как вызываемая функция: она получает runtime в начале каждого запуска и возвращает определение define_deep_agent. В этом определении выбираются модель, инструкции, навыки, MCP-серверы и песочница для конкретного запуска. Одна деплой-инсталляция обслуживает несколько команд или репозиториев, вместо того чтобы поддерживать почти одинаковые копии агента для каждой группы (источник).
Как устроена функция define_deep_agent
Логика укладывается в условную ветку: функция смотрит на контекст запуска и возвращает подходящее определение. Схематичный набросок без привязки к конкретным именам полей runtime:
# схематично: имена полей runtime зависят от контекста запуска
def build_agent(runtime):
if is_billing_context(runtime):
return define_deep_agent(
model=...,
instructions=...,
skills=[...],
mcp_servers=[...],
sandbox=...,
)
return define_deep_agent(...)
Разница с подсказками в промпте принципиальная. Инструкция «используй этот навык, когда речь о биллинге» оставляет решение модели, и инструмент всё равно присутствует в контексте. Функция же собирает конфигурацию до запуска модели, поэтому лишние навыки и MCP-инструменты в контекст не попадают вовсе.
Экономия на контексте здесь не абстрактная. LangChain последовательно сокращает базовую обвязку агента: в v0.7 входные токены упали с ~6k до ~2k, то есть на 65%, за счёт удаления стандартного системного промпта и сжатия описаний инструментов (подробности в разборе Deep Agents v0.7: как LangChain сократил входные токены на 65%). Конфигурация на каждый запуск работает в ту же сторону: агент несёт только те схемы инструментов, которые нужны текущей задаче.
MCP-серверы для агентов: динамический выбор и изоляция
MCP-серверы выбираются в конфигурации на каждый запуск, и это главный практический выигрыш. Агент не видит MCP-инструменты вне своей конфигурации: если в запуске не указан сервер, его инструментов для модели просто не существует. Типичная раскладка для внутреннего Slack-агента: запуск из канала финансов получает billing-навыки и серверы для работы с платежными системами, а запуск из канала платформенной команды получает MCP-сервер для incident-response. Инструкции у этих запусков тоже разные, хотя деплой один.
Побочный эффект приятный: контекст остаётся компактным. Чем меньше схем инструментов висит перед моделью, тем меньше токенов уходит на каждый шаг и тем реже агент тянется к инструменту, который ему не нужен.
Контроль доступа и безопасность через конфигурацию
Конфигурация задаётся до запуска модели, и это ключевое свойство с точки зрения доступа. Агент физически не может вызвать инструмент, которого нет в его конфигурации, потому что модель не получает его схему. Такой подход отличается от разграничения прав через инструкции: там модель видит инструмент и должна сама решить, что он ей не положен. Здесь решение принимает код до старта модели.
Второй контур ограничений связан с расписаниями. Они выполняются от имени пользователя, который их запросил, с его набором прав и подключений. Если у сотрудника нет доступа к репозиторию или внешнему сервису, то и запуск по расписанию туда не попадёт. Это удобно для аудита: за каждым отложенным действием стоит конкретный человек, а не общий сервисный аккаунт с широкими правами.
Важно не переоценивать эффект. Конфигурация на каждый запуск сужает поверхность атаки и держит контекст в узде, но не заменяет управление секретами, аудит вызовов и нормальные права в самих системах. Если у пользователя широкие права, расписание от его имени унаследует ту же широту. Границы доступа всё равно задаются там, где живут данные и API.
Реакции в Slack: подтверждение получения сообщения
Третья возможность касается обратной связи в интерфейсе. Агенты научились ставить реакции в Slack, чтобы подтвердить получение сообщения до ответа. По умолчанию используется 👀. Для длинных задач это заметно улучшает восприятие: пользователь видит, что запрос принят и обрабатывается, и не пишет повторно через минуту. Раньше в такой ситуации оставалось только ждать сообщения от бота.
Как настроить эмодзи и отключить реакции
Релиз упоминает, что эмодзи можно отключить или выбирать функцией, в том числе через дешёвую модель: тогда решение о реакции принимает не человек, а отдельный вызов небольшой модели. Подробностей реализации в анонсе нет, поэтому стоит проверять поведение на своём рабочем пространстве Slack, а не закладывать конкретную схему в документацию команды. Если канал забит служебными реакциями или они мешают в тредах с внешними участниками, реакции проще выключить точечно.
Практические сценарии для внутренних агентов в Slack и собственных каналах
Три возможности хорошо складываются друг с другом. Агент принимает запрос, ставит 👀, а дальше либо отвечает сразу, либо поручает продолжение расписанию. Всё это укладывается в один деплой с конфигурацией под конкретный канал.
Ежедневный дайджест и повторяющиеся задачи
Самый простой сценарий, который прямо описан в релизе: cron="0 9 * * 1-5", timezone="America/Los_Angeles", prompt="Write the daily digest.". Результат публикуется в тот же канал, где попросили дайджест. По этой схеме собирают утренние сводки по метрикам, отчёты по инцидентам, напоминания о дежурстве и регулярные выгрузки. Пользователь формулирует задачу один раз в разговоре, дальше расписание живёт само.
Фоллоу-апы и проверка деплоя
Одноразовое расписание закрывает отложенные проверки. Пример из релиза: «проверь этот деплой через час». Ответ приходит в исходный тред, и обсуждение не расползается по каналам. Тот же приём работает для напоминаний вернуться к задаче, проверки статуса сборки или уточнения, пришёл ли ответ от внешней команды.
Конфигурация на каждый запуск добавляет к этому разделение ролей. Канал разработки получает один набор MCP-серверов и инструкций, канал поддержки другой, а канал финансов третий, хотя агент один. Реакции дают быстрый отклик в обоих случаях: пользователь видит, что сообщение в работе, независимо от того, ответит агент сразу или поставит задачу в расписание.
Для команд, которым важна автономность, есть и открытые альтернативы с похожей логикой: проект Agenta позволяет запускать агентов по расписанию и триггерам из внешних приложений, подключать self-hosted модели и менять обвязки. Если критично держать инфраструктуру у себя, такой вариант стоит сравнить с Managed Deep Agents до того, как строить на нём рутину.
Ограничения и подводные камни v0.9
Начнём с очевидного: это публичная бета. Сроков выхода из неё в анонсе нет, значит возможны изменения API и нестабильность поведения. Не стоит ставить на расписания критичные процессы без ручного контроля.
Расписания зависят от двух внешних условий. Первое: запуск в момент срабатывания cron выполняет LangSmith, так что без него история не работает. Второе: сами расписания выполняются от имени пользователя с его правами и подключениями, поэтому после смены роли, отзыва OAuth-гранта или увольнения сотрудника расписание может перестать работать или, наоборот, сохранить доступ дольше, чем нужно. Это требует регламента: кто чистит расписания, когда человек уходит из команды.
Таймзона указывается явно. В распределённой команде это самая частая причина сюрпризов: дайджест «в 9 утра» окажется ночным сообщением для половины участников. Проверяйте, в какой зоне создаётся расписание, особенно если запрос пришёл из канала с людьми из разных регионов.
Реакции в Slack зависят от самой платформы и её разрешений. Деталей реализации в анонсе мало, а публичного описания кастомизации логики эмодзи нет, поэтому рассчитывать на тонкую настройку поведения не стоит до появления документации. Что касается конфигурации на каждый запуск, в релизе не перечислены поддерживаемые модели и песочницы, так что проверять совместимость придётся на своём стеке.
Стоит ли внедрять и как начать
v0.9 закрывает три боли, знакомые тем, кто уже держит агентов в Slack. Расписание больше не нужно вешать на внешний крон, копии агента под каждую команду не нужны, а молчание бота во время долгой обработки перестаёт раздражать. Для команд, которые живут в Slack и уже используют Managed Deep Agents, обновление выглядит логичным продолжением: это меньше инфраструктуры и меньше дублирующихся конфигураций.
Порядок действий разумно держать таким. Сначала пилот на одном канале: одна деплой-инсталляция, функция сборки конфигурации с ветками под два-три сценария, простые расписания вроде будничного дайджеста. Дальше стоит проверить, как ведут себя права: создайте расписание от имени обычного сотрудника, а не администратора, и посмотрите, что произойдёт, когда у него заберут доступ к нужному сервису. Отдельно решите судьбу реакций в каналах с внешними участниками.
Расширять стоит по мере появления реальных задач, а не заранее. Как только расписаний станет много, понадобится учёт: кто их создал, что они делают, когда последний раз запускались. Инструменты для долговременного состояния проекта и заметок между сессиями агента тоже пригодятся, чтобы отложенные запуски опирались на актуальный контекст, а не на устаревшие договорённости: пример такого подхода разобран в материале про Later Bender.
Начните с одного расписания и одного канала. Если через неделю оно приносит пользу без ручного вмешательства, добавляйте второй сценарий, а бета-статус держите в голове как повод не строить на v0.9 ничего критичного.