Claude Managed Agents: как проверять конфигурацию агентов до продакшена

3 сентября 2026 года в Claude Managed Agents появилось важное практическое изменение: ant apply теперь умеет превращать файлы репозитория в работающих агентов, среды, навыки, хранилища памяти и развёртывания. Главное здесь — конфигурацию агентов теперь можно отправлять на такое же ревью, как код, прежде чем она попадёт в продакшен.

Claude Managed Agents превращают конфигурацию в проверяемое состояние

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

Это не то же самое, что субагент Claude Code в .claude/agents/. Изменение касается ресурсов управляемого агентного сервиса, доступного через Claude API.

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

ant apply поручает эту задачу репозиторию. Ресурсы описываются в Markdown, YAML или JSON. CLI сопоставляет файлы с удалёнными ресурсами, показывает план, запрашивает подтверждение и применяет изменение.

Так системный промпт, доступ к инструментам, среда, набор навыков, хранилище памяти и расписание оказываются в одном pull request. Ревьюер видит предстоящие изменения до того, как человек или CI-задача с правами на развёртывание внесёт их в систему.

Это разбор рабочего процесса для команд, которые уже рассматривают Managed Agents. Если вы пользуетесь только приложением Claude, Claude Code или собственным циклом на Messages API, ant apply вашу схему работы не меняет.

Lock-файл становится основой передачи проекта

Важен не только файл с описанием агента, но и claude-lock.json.

Первый успешный запуск apply записывает lock-файл в каталог, из которого была вызвана команда. Поэтому запускать её стоит из корня репозитория, а затем коммитить lock-файл вместе с файлами ресурсов.

В lock-файле фиксируются источник API, организация, рабочее пространство и удалённый ID, созданный для каждого локального файла. Там же хранятся локальный и удалённый хеши. Первый показывает, что изменился файл, второй — что ресурс кто-то изменил через Console или другой путь API.

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

Благодаря этому передавать проект проще. Следующему специалисту или CI-раннеру не приходится угадывать, какой ID агента относится к agents/reviewer.md: сопоставление уже записано, поэтому обновляется тот же ресурс, а не создаётся копия.

Там, где API обычно требует ID, ресурсы могут ссылаться друг на друга относительными путями. Apply сам определяет порядок зависимостей, создаёт или обновляет каждый ресурс и подставляет реальные ID. Агент может ссылаться на каталог навыка, а развёртывание — на своего агента, среду и хранилище памяти.

Ссылки на агентов и навыки закрепляются за версиями, применёнными в конкретном запуске. Навык, загруженный по URL с GitHub, остаётся привязанным к найденному коммиту, пока не будет использован --upgrade. Поэтому на ревью попадает конкретное состояние, а не то, которое случайно оказалось на конце меняющейся ветки.

Экономика процесса сводится к затратам на передачу

ant apply не делает работу с агентами бесплатной — он переносит расходы в другую строку бюджета.

Раньше время уходило на повторную настройку, проверку и передачу. Теперь оно требуется на подготовку репозитория, ревью pull request, ответственность за CI и обслуживание lock-файла. Что окажется дешевле, зависит от частоты изменений конфигурации и числа мест, куда нужно доставить одно и то же изменение.

Ниже — явно обозначенный пример, а не бенчмарк и не заявление Anthropic об экономии.

Допустим, команда вносит четыре изменения конфигурации в месяц в трёх целевых средах. Ручная передача каждого изменения в каждую среду занимает 15 минут.

Ежемесячные затраты при ручном процессе:

4 changes × 3 environments × 15 minutes = 180 minutes

Теперь предположим, что при работе через репозиторий каждое изменение требует 30 минут на ревью и ещё по 10 минут на применение и проверку в каждой среде.

Ежемесячные затраты при работе через репозиторий:

4 changes × (30 review minutes + 3 × 10 apply minutes) = 240 minutes

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

Точка безубыточности до учёта настройки и обслуживания — 20 минут на одну ручную передачу. Если измеренная длительность ручной передачи составляет 30 минут, тот же ручной процесс займёт 360 минут, а процесс через репозиторий останется на уровне 240 минут. Разница составит 120 минут, но и она останется лишь результатом в таблице, пока команда не измерит реальную работу.

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

Кому полезен такой рабочий процесс

Платформенная команда получает единое окно ревью

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

Главный эффект — трассируемость. Команда может связать принятое изменение с планом ресурсов и последующим состоянием lock-файла.

Агентству проще передать клиентский проект

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

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

Операционная команда получает явный шаг развёртывания

Руководитель операционной команды может просмотреть изменение в pull request, а после слияния применить каталог из основной ветки командой ant apply --yes .. Точка в конце важна: apply без аргумента сверяет только уже отслеживаемые в lock-файле ресурсы и может пропустить новый файл.

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

Руководитель по безопасности получает остановку при расхождении

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

Это заставляет принять явное решение: изучить удалённое изменение и согласовать состояния либо намеренно перезаписать его с помощью --force. Командам, которым необходимы Zero Data Retention или покрытие соглашением HIPAA Business Associate Agreement, следует пока отложить Managed Agents: сейчас сервис не соответствует ни одному из этих требований.

Минимальный репозиторий для ant apply

Для ant apply требуется CLI 1.30.0 или новее. В официальном руководстве по быстрому старту описаны установка через Homebrew и вход через браузер.

1. 1

   Установите CLI и войдите в систему

   Установите CLI, проверьте версию и авторизуйтесь:

   brew install anthropics/tap/ant
   ant --version
   ant auth login

2. 2

   Создайте один файл агента

   Создайте agents/summarizer.md с минимальным описанием из документации:

   ---
   name: Summarizer
   model: claude-opus-5
   tools:
     - type: agent_toolset_20260401
   ---
   
   You are a helpful assistant that writes concise summaries.

3. 3

   Один раз примените файл из корня репозитория

   Запустите документированную команду для одного файла:

   ant apply agents/summarizer.md

   Проверьте план, при необходимости запросите подробности с различиями по каждому полю, а затем подтвердите применение. При успешном запуске будет создан удалённый агент, а рядом с проектом появится claude-lock.json.

4. 4

   Разделите предварительную проверку и применение по разным задачам

   В pull request используйте документированную команду предварительной проверки:

   ant apply --dry-run .

   После слияния обеспечьте последовательное выполнение задачи развёртывания и примените указанный каталог:

   ant apply --yes .

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

Ловушка с кодом завершения в CI

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

Для задачи apply используйте Workload Identity Federation вместо сохранённого API-ключа. Привяжите задачу к организации и рабочему пространству из lock-файла и разрешайте выполнять только один apply за раз.

Реальные ограничения

Подход «файлы как код» не позволяет управлять любым удалённым ресурсом.

ant apply не умеет принимать под управление агента, который был независимо создан в Console или командой ant beta:agents create. Если файлы и lock-файл получены через функцию Console Export as code, apply сможет обновлять эти экспортированные ресурсы. В противном случае применение совпадающего файла создаст ещё один ресурс.

Удаление тоже устроено консервативно. Если убрать файл, удалённый ресурс останется на месте, а команда покажет предупреждение. --prune удаляет удалённый ресурс, тогда как переименование файла объявляет новый ресурс и оставляет старый, пока не будет выполнен prune.

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

Lock-файл тоже становится общим операционным состоянием. Коммитьте его после каждого apply, защищайте его ветку и не допускайте параллельной записи. Если запуск прервался, не отбрасывайте изменение lock-файла лишь потому, что задача завершилась с ошибкой.

Наконец, сервис всё ещё находится в бета-версии. Claude Managed Agents включены по умолчанию для аккаунтов Claude API, но для команд с требованиями Zero Data Retention или HIPAA BAA остаётся ограничение на уровне продукта, которое ревью через репозиторий не устраняет.

Что сделать в понедельник

Начните уже на этой неделе, если одни и те же ресурсы Managed Agents меняют несколько человек, одна конфигурация переносится между средами или развёртываниям по расписанию нужны ответственный и история ревью.

Подождите, если стабильным экспериментом управляет один специалист, измеренные затраты на передачу ниже новых затрат на ревью или политика данных требует Zero Data Retention либо покрытия HIPAA BAA.

Для вас ничего не меняется, если агенты работают только через Claude Code, приложение Claude или собственный цикл Messages API без ресурсов Claude Managed Agents.

В понедельник выберите одного агента вне продакшена. Проведите его описание и lock-файл через настоящий pull request. Запишите, сколько минут занимает текущая передача и путь с ревью. Затем внесите удалённую правку в этой безопасной среде и убедитесь, что проверка pull request действительно считает заблокированный план заблокированным. Только после этого подключайте ant apply --yes . к процессу после слияния.

Получайте следующие практические разборы рабочих процессов с ИИ в рассылке.