Дата публикации
ai_products

Anthropic Managed Agents: как Claude сам управляет агентами на длинных задачах

Что нового

Anthropic запустила Managed Agents — управляемый сервис агентов внутри Claude Platform. Он берёт на себя всю тяжёлую часть оркестрации «длинных» задач: хранение сессий, перезапуск агентов, работу с контейнерами и безопасное выполнение кода.

Ключевые изменения по сравнению с «самодельными» агентами:

  • Отделение «мозга», «рук» и «памяти»:

    • мозг — Claude (например, Claude Opus 4.5 или Sonnet 4.5) + оркестратор (harness);
    • руки — sandboxes и инструменты, которые реально что‑то делают: контейнеры, MCP‑серверы, внешние API;
    • память — долговечный лог сессии, живущий вне контекста Claude.
  • Агенты живут дольше одной сессии модели: лог сессии хранится отдельно, и новый harness может подняться и продолжить работу по идентификатору sessionId.

  • Контейнеры больше не «дом» агента, а расходный ресурс: harness общается с ними как с обычным инструментом по интерфейсу execute(name, input) → string. Упал контейнер — Claude получает ошибку инструмента и может поднять новый через provision({resources}).

  • Снижение задержки до первого токена (TTFT):

    • p50 TTFT уменьшился примерно на 60%;
    • p95 TTFT уменьшился более чем на 90%.

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

  • Безопасное обращение к внешним ресурсам:

    • токены доступа к Git‑репозиториям используются на этапе инициализации sandbox и не видны агенту;
    • OAuth‑токены для пользовательских инструментов лежат в отдельном хранилище и доступны только через прокси, который сам ходит за ними в vault;
    • harness и сам Claude не видят секреты напрямую.
  • Контекст сессии живёт вне окна контекста Claude: весь поток событий хранится в отдельном логе, а harness через getEvents() может выбирать нужные фрагменты, трансформировать их и только потом отдавать в промпт.

Как это работает

Базовая архитектура

Anthropic разложила агента на три независимых компонента:

  1. Session (сессия)

    • Это журнал всех событий: запросы пользователя, ответы Claude, вызовы инструментов, результаты, ошибки.
    • Лог ведётся как append‑only: записи только добавляются, а не переписываются.
    • Сессия живёт отдельно от контейнеров и оркестратора. При падении любого из них лог не пропадает.
    • API‑слой даёт мозгу интерфейс getSession(id) и getEvents() для выборки нужных кусков истории.
  2. Harness (оркестратор, «мозг вокруг Claude»)

    • Это цикл, который:
      • читает события из лога сессии;
      • решает, когда вызвать Claude;
      • обрабатывает tool‑calls Claude и маршрутизирует их в нужные «руки»;
      • пишет новые события через emitEvent(id, event).
    • Harness не хранит состояние между рестартами. Если он упал, новый процесс поднимается через wake(sessionId) и по логу полностью восстанавливает контекст работы.
    • Внутри harness можно реализовать любую стратегию контекст‑инжиниринга: суммаризацию, обрезку, хитрый подбор событий из лога.
  3. Sandbox и инструменты («руки»)

    • Это изолированная среда, где выполняется код, редактируются файлы, запускаются внешние инструменты.
    • Для harness любая «рука» — это просто функция:
execute(name, input) → string
  • Неважно, что за этим стоит: Docker‑контейнер, MCP‑сервер, мобильное устройство или эмулятор. Интерфейс один и тот же.
  • Контейнеры поднимаются через стандартный рецепт provision({resources}). Упал контейнер — Claude видит ошибку tool‑call и может запросить новый.

Отказ от «питомцев» в инфраструктуре

Изначально Anthropic запускала всё внутри одного контейнера: и harness, и sandbox, и данные. Это удобно, но ведёт к классической проблеме «pet vs cattle»:

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

Managed Agents решают это так:

  • мозг (harness + Claude) живёт вне контейнеров;
  • руки (sandbox, инструменты) — это просто внешние сервисы/контейнеры, к которым мозг обращается как к инструментам;
  • сессия — отдельный сервис с долговечным логом.

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

Безопасность: токены вне песочницы

Раньше сгенерированный Claude код выполнялся в том же контейнере, где лежали секреты (переменные окружения, ключи). Достаточно одной удачной prompt‑инъекции — и агент читает собственные токены, а затем создаёт новые сессии с неограниченным доступом.

Anthropic перестроила схему:

  • Git‑доступ:

    • у каждого репозитория — свой access‑token;
    • при инициализации sandbox этот токен используется, чтобы сделать git clone и настроить remote;
    • внутри песочницы git push и git pull работают «как обычно», но сам агент токен не видит.
  • Пользовательские инструменты через MCP:

    • OAuth‑токены лежат в отдельном vault;
    • Claude вызывает MCP‑инструменты через прокси, который принимает только session‑token;
    • прокси по этому токену достаёт реальные креды из vault и делает запрос во внешний сервис;
    • harness и Claude не получают доступ к секретам напрямую.

Сессия как внешняя память, а не контекст Claude

Контекстное окно Claude ограничено. Раньше разработчики решали это:

  • суммаризацией (compaction) старых сообщений;
  • сохранением заметок в файлы через «memory tool»;
  • агрессивной обрезкой старых токенов, включая результаты инструментов и цепочки рассуждений.

Проблема — все эти операции необратимы. Вы заранее решаете, что будущим шагам не понадобится часть истории. Если ошиблись, починить это уже нельзя.

В Managed Agents вся сессия живёт вне контекстного окна Claude:

  • лог событий хранится отдельно и не обрезается;
  • harness через getEvents() может:
    • читать историю с любого места;
    • «отмотать» несколько событий назад, чтобы увидеть предысторию;
    • перечитать контекст перед важным действием.
  • перед тем как отдать события в промпт, harness может:
    • отсортировать их по важности;
    • объединить в суммаризации;
    • отфильтровать шум;
    • оптимизировать структуру под cache‑hit промпт‑кеша.

Anthropic сознательно разделяет две задачи:

  • надёжное долговечное хранение контекста — это сессия;
  • любые эвристики работы с контекстом — это уже логика harness.

Это даёт возможность менять стратегии контекст‑инжиниринга по мере роста возможностей Claude, не трогая базовую инфраструктуру.

Многие мозги, многие руки

  1. Много «мозгов» (harness + Claude)

Раньше каждый агент жил в своём контейнере. Это означало:

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

Это напрямую увеличивало TTFT — задержку между принятием задачи и первым токеном ответа.

После разделения:

  • harness — статeless‑процессы, которые можно масштабировать как обычные веб‑воркеры;
  • контейнеры поднимаются по требованию, когда Claude через tool‑call решает, что ему нужна песочница;
  • оркестрация может начать инференс сразу после того, как подтянула события из лога сессии — без ожидания контейнера.

Anthropic показывает, что на этой архитектуре:

  • p50 TTFT сократился примерно на 60%;
  • p95 TTFT — более чем на 90%.
  1. Много «рук» (sandboxes, инструменты)

Claude теперь может работать сразу с несколькими исполнителями:

  • разными песочницами;
  • несколькими MCP‑серверами;
  • разными наборами инструментов.

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

Теперь каждая рука — это независимый инструмент с интерфейсом execute(name, input) → string. Harness не знает, что там внутри:

  • контейнер с Linux;
  • внешний API;
  • эмулятор чего угодно.

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

Что это значит для вас

Кому Managed Agents реально полезны

  1. Команды, строящие сложные AI‑агенты вокруг Claude

Если вы пишете свои оркестраторы, управляете контейнерами, логируете историю и чините подвисшие сессии — Managed Agents снимают большую часть этой рутины:

  • долгие задачи (часы, дни) продолжаются, даже если упали контейнеры или процессы оркестратора;
  • можно безопасно запускать сгенерированный код, не раздавая Claude доступ к секретам;
  • проще подключать ресурсы в собственном VPC, не перенося всю инфраструктуру к Anthropic.
  1. Инженеры, которым нужен надёжный «длинный» контекст

Для задач вроде:

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

Managed Agents дают внешний долговечный лог. Вы не обязаны решать «лишние» сообщения по пути — можно хранить всё и давать Claude доступ к нужным фрагментам через логику harness.

  1. Команды с жёсткими требованиями по безопасности

Если у вас строгий контроль над секретами:

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

Где Managed Agents особенно сильны

  • Длинные пайплайны разработки: авто‑рефакторинг, генерация и доработка кода, CI‑интеграции, работа с несколькими репозиториями.
  • Многошаговые бизнес‑процессы: подготовка отчётов, сложные интеграции с внешними API, где важно не терять промежуточные шаги.
  • Мульти‑агентные сценарии: когда несколько «мозгов» должны координироваться и делить между собой инструменты.

Когда Managed Agents могут быть избыточны

  • Простые чат‑боты, FAQ, одношаговые запросы к Claude. Если задача укладывается в один вызов модели и не требует кода или сложной памяти, Managed Agents — тяжёлая артиллерия.
  • Сценарии, где вы не готовы выносить инструменты в инфраструктуру Anthropic и не хотите настраивать MCP/прокси. В этом случае придётся либо строить свой аналог, либо ограничиться простым API‑вызовом Claude.

Доступность из России

Anthropic официально работает через Claude Platform и API. Для доступа пользователям из России обычно нужна зарубежная платёжная инфраструктура и обход региональных ограничений (VPN или аналогичные решения). Если у вас нет стабильного доступа к Claude Platform, использовать Managed Agents напрямую не получится.

Место на рынке

Managed Agents — это не «ещё один агентный фреймворк», а хостed‑слой оркестрации вокруг Claude, который Anthropic встроила прямо в свою платформу.

По тому, что есть в материале, можно сказать следующее:

  • Anthropic явно ориентируется на разработчиков, которые уже строят сложные агентные системы и хотят переложить на платформу:
    • управление сессиями;
    • надёжный лог событий;
    • перезапуск агентов;
    • безопасное выполнение кода и работу с секретами.
  • Архитектура «много мозгов, много рук» и падение p50 TTFT на ~60% и p95 на >90% показывают, что Anthropic упирается в производительность и масштабируемость долгих задач.

Прямых численных сравнений с OpenAI (например, с GPT‑4o и её агентными возможностями) в материале нет. Anthropic описывает только свои внутренние метрики TTFT и особенности архитектуры.

Если вы выбираете платформу под сложных агентов, важные моменты по Managed Agents:

  • сильная сторона — архитектура и надёжность долгих процессов, а не просто «умная модель»;
  • Anthropic делает ставку на то, что:
    • интерфейсы (session, harness, sandbox) проживут дольше, чем конкретные реализации;
    • по мере роста возможностей Claude вы сможете менять только harness и инструменты, не ломая остальное.

Для российских команд выбор между Anthropic и конкурентами упрётся не только в архитектуру, но и в доступность платформы, юридические и платёжные ограничения. Если инфраструктура под Anthropic у вас уже есть, Managed Agents выглядят как логичный базовый слой для всех серьёзных проектов на Claude.


Читайте также