Claude Managed Agents против Claude Agent SDK

На прошлой неделе у меня было открыто три вкладки: документация по Managed Agents, руководство по быстрому старту Agent SDK и справочник Messages API. Я пытался понять, какой путь использовать для асинхронного пайплайна обработки документов. Через сорок минут я осознал, что замешательство было не в функциях. Речь шла о том, кто владеет рантаймом.

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

Два пути к агентам на базе Claude

Agent SDK: вы управляете циклом и рантаймом

Claude Agent SDK — переименованный в начале этого года из Claude Code SDK — предоставляет те же инструменты, цикл агента и управление контекстом, которые лежат в основе Claude Code, упакованные как библиотека Python или TypeScript. Вы устанавливаете её, запускаете на своей инфраструктуре и самостоятельно занимаетесь масштабированием, изолированием и оркестрацией.

SDK автоматически включает Claude Code CLI. Ваш агент получает доступ к файловым операциям, bash-командам, веб-браузингу, выполнению кода — полному набору инструментов Claude Code — прямо из коробки. Вы определяете, какие инструменты разрешены, устанавливаете режимы разрешений и реализуете пользовательские инструменты как внутрипроцессные MCP-серверы.

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

Managed Agents: Anthropic управляет обвязкой, вы определяете задачу

Claude Managed Agents, запущенный в публичную бету 8 апреля 2026 года, переворачивает модель владения. Вы задаёте агента — модель, системный промпт, инструменты, MCP-серверы, ограничения — а Anthropic запускает его. Обвязка берёт на себя выполнение инструментов, изолирование, персистентность сессий, сжатие контекста, кэширование промптов и восстановление после сбоев.

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

Вы настраиваете, Anthropic управляет.

Ни один из вариантов не является универсально лучшим

Пересечение возможностей высокое. Оба дают Claude доступ к выполнению кода, работе с файлами, bash, веб-браузингу и интеграциям MCP. Разница операционная: кто подготавливает среду, кто обрабатывает сбои, кто масштабирует контейнеры. Это инфраструктурное решение, а не решение о функциях.

Базовое сравнение

Стоит отметить по поводу биллинга: Agent SDK не вводит плату за рантайм сессии. Но называть его «дешевле» без оговорок — вводить в заблуждение. Ваш самостоятельно размещённый рантайм имеет реальные затраты — серверы, оркестрация контейнеров, мониторинг, реагирование на инциденты, человеко-часы на поддержку всего этого. Структуры затрат разные, а не просто упорядоченные.

Когда выбирать Managed Agents

Длительные или асинхронные задачи, где важна персистентность сессий

Если ваш агент работает от 30 минут до нескольких часов — обрабатывает документы, проводит исследования, выполняет многоэтапные рабочие процессы — вам нужно состояние сессии, которое выживает при отключениях и сбоях контейнеров. Managed Agents хранит полную историю событий на стороне сервера и делает её доступной через API. Создать эквивалентную надёжность самостоятельно возможно. Это также несколько недель инженерной работы, которая не является вашим основным продуктом.

Команды без пропускной способности инфраструктуры для создания безопасных изолированных сред

Изолирование производственного уровня — изоляция, управление учётными данными, ограниченные разрешения, трассировка выполнения — это действительно сложно. Большинство команд недооценивают это. Если у вашей команды нет DevOps-мощностей для создания и поддержки безопасной среды выполнения агентов, Managed Agents полностью убирает эту поверхность из вашей дорожной карты.

Быстрый путь от прототипа до продакшена: дни вместо месяцев

Заявление Anthropic — «выйти в продакшен в 10 раз быстрее». Я не проверил эту цифру в достаточном количестве сценариев, чтобы её одобрить. Но направление точное: разрыв между «агент работает в локальном тестировании» и «агент надёжно работает в продакшене» велик, и Managed Agents его сокращает. По имеющимся данным, Rakuten развернул специализированных агентов менее чем за неделю каждого.

Когда встроенное сжатие и кэширование важнее пользовательского контроля

Managed Agents автоматически обрабатывает кэширование промптов и сжатие контекста. Если вы создавали собственное управление контекстом для длительных агентов, вы знаете, сколько проб и ошибок это требует. Встроенный подход не будет оптимальным для каждой рабочей нагрузки. Для большинства он достаточно хорош — и работает с первого дня.

Когда выбирать Agent SDK

Пользовательская логика оркестрации, которую Managed Agents не предоставляет

SDK даёт вам хуки, пользовательские инструменты как внутрипроцессные MCP-серверы, детализированные обратные вызовы разрешений и полный контроль над циклом агента. Если вашему агенту нужны пользовательские стратегии повторных попыток, условная маршрутизация инструментов или динамическое изменение промпта в середине сессии — логика, которую конфигурационная поверхность Managed Agents не предоставляет — вам нужен SDK.

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

Если вашему агенту нужно работать внутри конкретной среды — доступ к GPU, определённому драйверу базы данных, проприетарной библиотеке — SDK позволяет полностью контролировать среду выполнения. Managed Agents предоставляет облачный контейнер с предустановленными пакетами. Этого достаточно для большинства случаев. Но не для всех.

Требования к локальному развёртыванию или частному облаку

Managed Agents работает исключительно на инфраструктуре Anthropic. Нет варианта для локального развёртывания, нет развёртывания в вашем собственном облаке. Для организаций со строгими требованиями к суверенитету данных или нормативными ограничениями, запрещающими отправку данных сторонней инфраструктуре, SDK — единственный путь. Это жёсткое ограничение, а не предпочтение.

Структура затрат при масштабировании

$0,08/сессио-час — незначительная сумма для большинства рабочих нагрузок — агент 24/7 обходится примерно в $58/месяц за рантайм до учёта токенов. Но для больших флотов параллельно работающих долгосрочных агентов плата за сессии суммируется. Флот из 500 агентов, работающих одновременно, генерирует $40/час только в накладных расходах на сессии.

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

Третий вариант: Messages API

Когда не нужен ни SDK, ни Managed Agents

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

Messages API даёт вам прямой доступ к модели. Вы отправляете промпт, получаете ответ. Никакой обвязки, никакого цикла агента, никакого управляемого рантайма. Вы строите всё самостоятельно — включая цикл выполнения инструментов, если он вам нужен.

Простые паттерны использования инструментов, не требующие полноценного фреймворка агентов

Если ваш случай использования: вызвать Claude, опционально позволить ему использовать один-два инструмента, вернуть результат — вам вообще не нужен фреймворк агентов. Messages API с использованием инструментов справляется с этим чисто. Добавление Agent SDK или Managed Agents вносит сложность, которая не окупается в простых паттернах запрос-ответ.

Клиентские SDK Anthropic для Python и TypeScript нативно поддерживают использование инструментов. Вы самостоятельно реализуете цикл инструментов — цикл while, который проверяет stop_reason, выполняет инструменты, отправляет результаты обратно. Для многих производственных рабочих нагрузок этого достаточно.

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

Соображения о миграции

Начало с Managed Agents, переход на SDK: что меняется

Логика агента — системный промпт, определения инструментов, структура задачи — переносится напрямую. Что не переносится: персистентность сессий, изолирование, управление контекстом и восстановление после сбоев. Всё это придётся создавать с нуля.

Переход с Managed Agents на SDK означает переход от «Anthropic управляет» к «вы управляете». Возможности эквивалентны. Операционная нагрузка полностью перекладывается на вашу команду.

Начало с SDK, переход на Managed Agents: что меняется

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

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

По состоянию на апрель 2026 года официального руководства по миграции между ними нет. Планируйте интеграционное тестирование, а не только перенос кода.

Часто задаваемые вопросы

Можно ли использовать оба в одном продукте?

Да. SDK и Managed Agents удовлетворяют разные операционные потребности. Распространённый паттерн: Agent SDK для пользовательских взаимодействий с чувствительностью к задержкам, где нужен полный контроль; Managed Agents для фоновых асинхронных задач, где важнее персистентность сессий и автономная работа. Они используют одни и те же базовые модели Claude и структуру ценообразования для стоимости токенов.

Привязывает ли Managed Agents меня к инфраструктуре Anthropic?

Да. Рантайм создан специально для Claude. Он не запустит GPT, Gemini или модели с открытым исходным кодом. Логика вашего агента — промпты, определения инструментов, структура задачи — переносима. Рантайм и формат сессии — нет. SDK даёт вам больше гибкости для абстрагирования слоя модели, хотя он также специфичен для Claude.

Что лучше справляется с ошибками и повторными попытками?

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

Можно ли перенести существующего агента SDK на Managed Agents?

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

Что экономически эффективнее при высоких объёмах?

Зависит от того, что вы считаете. Managed Agents добавляет $0,08/сессио-час поверх токенов. SDK добавляет нулевую надбавку за сессию — но ваш самостоятельно размещённый рантайм имеет собственную статью расходов: серверы, оркестрация, мониторинг, инженерная поддержка. При низком и умеренном объёме Managed Agents, как правило, дешевле по совокупной стоимости владения. При очень высоком объёме с большим количеством параллельных длительных сессий математика может перевернуться — но только если вы уже вложили средства в инфраструктуру.

Вот и всё сравнение. Дерево решений: нужен контроль инфраструктуры или нельзя отправлять данные за пределы периметра → SDK. Хотите избежать инфраструктурных хлопот → Managed Agents. Цикл агента вообще не нужен → Messages API.

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

Продолжение следует на следующей неделе — всё ещё тестирую паттерны мультиагентности в Managed Agents.

Предыдущие посты: