Claude API: компакция по требованию и режим `auto` для разрешений меняют архитектуру агентных циклов

На неделе 10–14 сентября Anthropic добавила в Claude API два обновления, ориентированных на операторов. Ни одно из них не является улучшением модели — оба меняют контракт между вашим кодом и API.

Первое — компакция по требованию: новый бета-заголовок compact-2026-09-04 позволяет запрашивать резюме разговора как отдельный фоновый вызов, полностью отвязанный от хода, которого ожидает пользователь. Второе — режим auto разрешений в managed agents: сервер принимает решение по каждому вызову инструмента — выполнить, отклонить или поставить на паузу до вашего одобрения. Если вы уже используете пороговую компакцию (compact-2026-01-12) или managed agents (managed-agents-2026-04-01), именно эти изменения сильнее всего влияют на операционную модель.

Компакция по требованию: механика заголовка compact-2026-09-04

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

Компакция по требованию решает это, превращая суммаризацию в отдельный API-вызов, возвращающий только блок compaction — без ответа ассистента, без результатов инструментов, только резюме. Запрос можно отправить из фонового воркера, пока разговор простаивает. Когда блок возвращается, вы вставляете его в массив сообщений, удаляя всё предшествующее. Следующий запрос пользователя уходит с уже скомпактированным контекстом.

Новый заголовок — compact-2026-09-04. Вы отправляете отдельный запрос с параметром compaction (не context_management.edits) и получаете блок резюме. В последующих ходах этот блок находится в начале массива сообщений, и API автоматически отбрасывает всё предшествующее содержимое.

Поддерживаемые модели на 17 сентября: claude-fable-5-1, claude-mythos-5-1, claude-fable-5, claude-mythos-5, claude-mythos-preview, claude-opus-5, claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-sonnet-5, claude-sonnet-4-6. Поддерживает ZDR (кроме Covered Models). Доступно в бета-режиме на Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud и Microsoft Foundry.

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

Только пороговая компакция — цикл выглядит так:

# Каждый ход:
response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]},
    max_tokens=4096,
)
messages.append({"role": "assistant", "content": response.content})
# При срабатывании компакции response.content содержит compaction block.
# API отбросит старые сообщения при следующем запросе.

Компакция происходит синхронно. Если контекст большой — этот ход медленнее. Пользователь ждёт.

Компакция по требованию (compact-2026-09-04) — суммаризация выполняется асинхронно:

# Фоновый воркер запускает при простое сессии или достижении порога токенов:
summary_response = client.beta.messages.create(
    betas=["compact-2026-09-04"],
    model="claude-opus-5",
    messages=messages,           # разговор на текущий момент
    compaction={"type": "compact_20260904"},
    max_tokens=4096,
)
compaction_block = summary_response.content[0]  # только compaction block

# Записываем в хранилище сообщений:
messages = [{"role": "assistant", "content": [compaction_block]}]
# Все предыдущие сообщения удалены; следующий ход пользователя
# отправляется со скомпактированным контекстом.

Следующий запрос пользователя не имеет дополнительной задержки. Для долгосрочных сессий — поддержка пользователей, coding-агенты, review документов — это принципиальное изменение архитектуры. Момент суммаризации выбираете вы, а не API.

Важное операционное замечание: теперь вы сами отвечаете за своевременный запуск компакции. Пороговая компакция самоуправляемая; компакция по требованию — нет. Вам нужен подсчёт токенов (или эвристика), чтобы определить момент запуска фонового задания. Пропустите окно — контекст переполнится, и вместо резервного резюме вы получите 400.

Режим auto разрешений: серверная оценка доверия для managed agents

Бета managed agents (managed-agents-2026-04-01) изначально предлагала два режима разрешений: always_allow (выполнять без подтверждения) и always_ask (пауза, ожидание вашего одобрения). Умолчания асимметричны: agent_toolset_20260401 по умолчанию always_allow, MCP toolsets — always_ask.

Новый режим auto добавляет третий путь. При установке permission_policy: {type: "auto"} на toolset сервер оценивает каждый вызов индивидуально и принимает одно из трёх решений: выполнить, отклонить или поставить на паузу для вашего одобрения. Вы заранее не знаете, какая ветка сработает для конкретного вызова — это и есть замысел. Серверная оценка Anthropic учитывает контекст, недоступный вашему коду: выглядит ли вызов аномально, находится ли цель в допустимом диапазоне, накопила ли сессия сигналы риска.

Конфигурация аналогична другим режимам:

{
  "type": "agent_toolset_20260401",
  "default_config": {
    "permission_policy": {"type": "auto"}
  }
}

Можно задать на уровне отдельного инструмента — точнее, чем умолчание toolset.

Критическое операционное ограничение: активные сессии сохраняют конфигурацию toolset на момент создания. Смена политики существующего агента затронет только новые сессии. Текущие сессии работают по старой политике до завершения.

Аудиторский пробел режима auto и способы его закрыть

При always_allow ваши логи фиксируют каждый вызов инструмента и результат — ваш код принял решение, ответственность на вас. При always_ask в потоке сессии есть явное событие одобрения — снова чёткая принадлежность. При auto решение принял сервер. Событие одобрения или отказа появится в потоке событий сессии, но причина — почему сервер разрешил или отказал — в текущей бета-версии не раскрывается.

Это важно для команд по compliance и для отладки. Если агент получает отказ в середине задачи, пользователь видит провал задачи, а у оператора нет видимой причины. Вы получаете тип события, а не объяснение.

Практическая мера прямо сейчас: не используйте auto как единственный барьер. Применяйте его вторым слоем поверх узко ограниченного toolset. Если вы запускаете agent_toolset_20260401, сначала ограничьте набор инструментов тем, что агенту действительно нужно, а затем устанавливайте auto — при узком пространстве действий серверная оценка будет предсказуемее. Неожиданные отказы — сигнал, что запрос выглядел аномально с точки зрения сервера; изучите предшествующий контекст сессии.

Для MCP toolsets: умолчание always_ask уже консервативно. Переход на auto означает замену явных событий одобрения на серверную оценку — оправдано только если задержки от раундтрипов одобрения являются реальным узким местом.

Что обновить в конфигурации оператора

По компакции:

• Для компакции по требованию добавьте compact-2026-09-04 в список бета-заголовков рядом с имеющимся compact-2026-01-12. Оба режима независимо опциональны.
• Встройте токен-чекпоинт в менеджер сессий. Endpoint подсчёта токенов в Anthropic SDK — чистый способ выставить триггер для фонового задания.
• Компакция по требованию использует тот же список поддерживаемых моделей, что и пороговая. Если целевая модель маршрутизации отсутствует в списке — вызов вернёт ошибку; проверьте это до включения.

По политикам разрешений:

• Изменения политики не влияют на активные сессии. Чтобы изменить поведение долгоживущих агентов, нужно создать нового агента и мигрировать сессии.
• Режим auto не замена always_ask для высокорисковых toolsets. Он подходит для низкорисковых инструментов, где накладные расходы на раундтрипы одобрения превышают ценность явного контроля каждого вызова.
• Операторы MCP-серверов в среде managed agents должны учесть: ваша политика по умолчанию — always_ask. Если managed agent с auto-разрешениями вызывает ваш MCP-сервер, вызовы могут быть тихо отклонены на серверной стороне. Проверьте это явно в staging-окружении.

Оба функционала находятся в бета-статусе; форматы API могут измениться до GA. compact-2026-09-04 и managed-agents-2026-04-01 — независимые бета-флаги с независимыми сроками устаревания; отслеживайте их раздельно.