ant apply переводит Claude agents на GitOps: что отслеживать операторам gateway

Когда команда меняет модель в routing gateway, это решение обычно хранится где-то неудобно: в конфигурационном файле, который никто не читает, в переменной среды, выставленной вручную, или только в чьей-то голове. Команда ant apply, выпущенная 3 сентября в составе ant CLI v1.30.0, переносит это решение в Markdown-файл в репозитории, который проходит тот же code review, что и обычный код.

Для команд, чьи agents вызывают Claude через proxy или AI gateway, это изменение имеет конкретные операционные последствия.

Что делает ant apply

ant apply — это команда plan-and-apply, созданная по образцу Terraform. Вы описываете каждый ресурс Claude API — agents, environments, skills, memory stores, scheduled deployments — в виде файла в репозитории. Frontmatter содержит конфигурацию, тело Markdown становится system prompt или стартовым сообщением deployment. Команда ant apply . выводит план, ждёт подтверждения, после чего записывает claude-lock.json.

ant apply agents/summarizer.md

Lockfile фиксирует реальный ID ресурса API вместе с двумя контентными хешами — что было отправлено последний раз и что вернул API. При следующем запуске любое расхождение между файлом и удалённым ресурсом отображается как diff в плане. Если кто-то обновил agent через Claude Console, минуя файлы, ant apply откажется применять план до тех пор, пока расхождение не будет устранено или не будет передан флаг --force.

Поле model теперь является проверяемым значением конфигурации

Именно это операторы gateway должны зафиксировать для себя. Файл agent выглядит так:

---
name: Code reviewer
model: claude-opus-5
tools:
  - type: agent_toolset_20260401
---

You review pull requests for correctness, security, and readability.

Поле model определяет, какую версию Claude запрашивает данный agent. До появления ant apply изменение этого поля требовало вызова API, редактирования в Console или ручного выполнения ant beta:agents update. Теперь это pull request с историей и проверкой.

Для команд, маршрутизирующих запросы Claude через gateway, это имеет конкретное следствие: модель, указанная в файле agent, — это та модель, которую gateway увидит во входящем запросе. Если ваша routing policy обрабатывает claude-opus-5 и claude-fable-5-1 по-разному — разные бюджеты стоимости, разные цепочки fallback, разные SLO по latency — эти политики теперь должны синхронизироваться с тем, что объявлено в файлах agents/.

Дрейф между правилами маршрутизации gateway и объявленной моделью agent раньше был невидимым. После ant apply он становится проверяемым.

Что именно хранит claude-lock.json

Lockfile — не просто учётная запись. Он сопоставляет каждый локальный путь к файлу с ID ресурса API, версией и двумя хешами содержимого:

{
  "version": 1,
  "origin": {
    "organization_id": "1b0c2a4d-6c1f-4f0e-9a57-2e8d1c3b4a5f",
    "workspace_id": "wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ"
  },
  "resources": {
    "./agents/summarizer.md": {
      "kind": "agent",
      "id": "agent_011CYm1BLqPXpQRk5khsSXrs",
      "version": "1",
      "hash": "d23251c8d99b3613a64f3f8d87f5fad4",
      "remote_hash": "1b771bee5bdbf600a5ad972fdac32d94"
    }
  }
}

Поле id — каноническая ссылка для запуска sessions. Если вы написали инструменты, напрямую вызывающие Managed Agents API, или ваш gateway конструирует agent sessions, нужно читать agent ID из claude-lock.json, а не хардкодить его. Каждый apply, создающий новый ресурс, генерирует новый ID; старый не обновляется.

Два хеша обнаруживают внешние изменения. Когда hash и remote_hash расходятся, ant apply отказывается выполняться и сообщает о конфликте. Это тот же механизм обнаружения дрейфа удалённого состояния, что и в Terraform. Команды, управляющие Claude agents совместно, получают конкретный сигнал, когда кто-то редактирует agent в обход репозиторного рабочего процесса.

До и после: как меняется рабочий процесс оператора

До ant apply. Модель, system prompt, инструменты и среда agent настраивались через вызовы API или Console. Фиксировать текущее состояние приходилось либо в отдельной документации, либо запуском ant beta:agents describe в надежде, что вывод актуален. У CI pipeline не было стандартного способа просматривать или проверять изменения agent перед слиянием.

После ant apply.

• Файлы agent лежат в репозитории в директориях agents/, environments/, memory_stores/, deployments/, skills/
• ant apply --dry-run . в PR-проверках выводит план без применения — рецензенты видят, что именно изменится
• ant apply --yes . при слиянии в main применяет план и обновляет claude-lock.json
• Lockfile коммитится обратно в репозиторий; следующий apply работает с теми же ресурсами
• Ресурсы, удалённые из файлов, остаются на месте с предупреждением, пока не будет запущен --prune, что защищает от случайного удаления production agent

При мультиагентных конфигурациях важно разрешение зависимостей. Если координирующий agent ссылается на другой agent по относительному пути (./reviewer.md), ant apply создаёт их в порядке зависимостей и подставляет реальные ID. Управлять ID вручную не нужно.

Последствия для маршрутизации и governance

Для команд, использующих AI gateway между кодом приложения и Claude API, ant apply меняет два операционных допущения.

Привязка к модели теперь в системе контроля версий. Поле model в файле agent — единственный источник истины о том, какую версию Claude запрашивает данный agent. Если gateway применяет routing policies или лимиты расходов по моделям, эти политики нужно проверять вместе с изменениями файлов agent. Рецензент, смотрящий только на код и игнорирующий файлы agents/*.md, пропустит решение по governance модели.

Session ID приходит из lockfile. Managed Agents API требует ID agent для запуска session. Этот ID хранится в claude-lock.json после apply. Инструменты, запускающие sessions, — gateway-адаптер, CI-задача, CLI разработчика — должны читать lockfile, а не опираться на захардкоженные константы. Применение, заменяющее ресурс (например, при смене имени), генерирует новый ID.

Правки в Console конфликтуют с репозиторием. Любое внешнее изменение — обновление agent через Claude Console, запуск ant beta:agents update в обход репозиторного процесса — приведёт к тому, что ant apply откажется выполняться. Команды, желающие детерминированного состояния agent, должны либо сделать репозиторий единственным путём записи, либо смириться с тем, что каждая правка в Console создаёт конфликт, который кому-то придётся разрешать.

Аналогов у других провайдеров нет

Ни один другой крупный провайдер моделей не выпустил декларативный CLI в стиле Terraform для управления конфигурациями AI agents. Управление AWS Bedrock Agent осуществляется через CloudFormation или консоль Bedrock. Vertex AI Agent Builder использует Google Cloud Console и REST API. Azure AI Foundry имеет ARM-шаблоны, но они управляют инфраструктурой, а не конфигурацией agents на уровне prompt.

ant apply уже, чем эти инфраструктурные инструменты, но точнее нацелен на проблему воспроизводимости поведения agent в команде. Он не управляет вычислительными ресурсами или масштабированием — он управляет конфигурацией: какая модель, какой system prompt, какие tools. Именно этот слой меняется чаще всего и при этом имеет наименее устоявшиеся процессы проверки.

Что сделать на этой неделе

Если ваша команда запускает Claude agents через routing gateway или общий API key:

1. Проверьте, какие agents определены через API-вызовы или Console, а не через файлы. Это кандидаты для переноса в файлы ant apply.
2. Убедитесь, что routing policies вашего gateway совпадают с моделями, объявленными в файлах agent, и задокументируйте любые расхождения.
3. Решите, должен ли ant apply --yes входить в CI pipeline при слиянии в main или оставаться ручным шагом с явным подтверждением.
4. Закоммитьте claude-lock.json в репозиторий и сделайте его обязательным артефактом code review в PR, затрагивающих файлы agents/.

О routing policies и о том, как выбор модели влияет на поведение gateway, читайте в документации TheRouter.