Руки отдельно от мозга
Главное архитектурное решение Claude Managed Agents: агентный цикл крутится на сервере, а инструменты выполняются у тебя. Из этого следуют сразу три вещи — безопасность кредов, −90% ко времени первого токена и живучесть при падении исполнителя.
Зачем нам это, если мы не используем CMA
Прямо мы Claude Managed Agents не используем — у нас свой оркестратор. Но воркшоп ценен тем, что это чек-лист того, что обязано быть у production-агента, собранный людьми, которые эти агенты и строят. А развилка «руки/мозг» напрямую ложится на наш губернатор.
Три поколения интерфейсов
Аргумент, который стоит запомнить: обвязка устаревает вместе с моделью
У Sonnet 4.5 обнаружили поведение под названием context anxiety: Claude начинал сворачивать задачу рано, хотя в контекстном окне ещё было полно места. В обвязку добавили меры против этого раннего останова.
Вышел Opus 4.5 — поведение исчезло само. Вся проделанная работа стала бесполезной, потому что Claude перерос то, что обвязка пыталась компенсировать.
Это предупреждение против накопления костылей в наших промптах и скиллах. Каждая строчка вида «не останавливайся раньше времени», «обязательно проверь, что...», «не забудь дописать» — это заплатка под поведение конкретной модели. Модель обновится — заплатка станет мусором, который активно вредит (см. гигиену контекста).
Практика: помечать такие заплатки датой и моделью, под которую они введены, и при апдейте
модели проверять, нужны ли они ещё. У нас в Gotchas уже есть авто-метки вида
_[auto 2026-06-30]_ — тот же приём, надо распространить на поведенческие правила.
Четыре примитива
Дать агенту те же материалы, что были бы у человека-разработчика. Разработчик при инциденте лезет в метрики, логи и деплои — значит ровно эти инструменты и даём. Не больше и не меньше.
Расцепление: три следствия
Раньше агентный цикл был жёстко сцеплен с выполнением инструментов — и для Claude Code это правильно: агенту нужен доступ к файлам на твоей машине, значит инструменты живут в том же контейнере. Но для многих агентов это плохо.
Форма кода: стрим открывается первым
Порядок операций неочевидный и важный — сначала открыть стрим, потом отправить сообщение, иначе первые события потеряются:
with client.beta.sessions.events.stream(session_id) as stream: # открыть ПЕРВЫМ
client.beta.sessions.events.send(session_id, events=[ # потом отправить
{"type": "user.message", "content": [{"type": "text", "text": q}]}
])
for ev in stream:
if ev.type == "agent.custom_tool_use": # облако → тебе
result = handle_tool(ev.name, ev.input)
client.beta.sessions.events.send(session_id, events=[ # тебе → облако
{"type": "user.custom_tool_result",
"custom_tool_use_id": ev.id,
"content": [{"type": "text", "text": result}]}
])
yield evДвенадцать строк, и в них видна вся модель: агент в облаке просит вызвать инструмент, инструмент выполняется у тебя, результат уходит обратно как ещё одно событие.
У нас это разделение уже есть, просто мы его так не называли: resource-governor —
брокер «рук», а claude -p внутри слота brain — «мозг». Что забрать:
- Allow-list сети на средах выполнения. Сейчас контейнеры генераторов ходят наружу
свободно. Сузить исходящий трафик до реально нужных хостов
(
api.fast-gen.ai,api.anthropic.com) — дешёвая изоляция, которая ничего не ломает. - Прогрев контейнеров. Где у нас контейнер поднимается на задачу, а не живёт постоянно — там те самые проценты латентности.
- Падение исполнителя ≠ падение прогона. Проверить: если рендер-контейнер умер посреди конвейера, перезапускается только он или весь прогон с нуля? Второе — это повторная оплата уже сгенерированных сцен.
Демо: что реально сделал агент
Сценарий — инцидент, P99-латентность в 10 раз выше базовой. Агент:
- запустил sandbox-команду, посмотрел приложенные логи;
- вызвал инструменты недавних деплоев, метрик и диффа;
- вернул диагноз: исчерпание пула соединений к БД, вызванное конкретным коммитом — рефакторингом сборщика сводки заказов, который добавил запрос, выедающий пул;
- исключил другие причины и выдал рекомендованные действия.
Явно проговорено, куда это доводится: дать агенту доступ к Claude Code — и он пойдёт в кодовую базу, предложит фикс и откроет PR. Человек остаётся надзором.
Два приёма из демо
- Скилл с runbook'ами. Runbook — документ, где команда записала, как она уже отлаживала такой инцидент. Дать агенту скилл, который смотрит примеры runbook'ов и подтягивает постмортемы прошлых инцидентов, названо очень мощным.
- Локальные инструменты переносимы. В демо метрики тянутся из локального JSON. Тот же провод меняется на боевую систему мониторинга без изменения агента — тот же wire protocol.
«Скилл с runbook'ами» — это наши Gotchas, только правильно устроенные. Разница: у нас это плоский список внутри SKILL.md, висящий в контексте всегда. Runbook-скилл — это отдельные документы, которые агент подтягивает, когда попал в похожую ситуацию.
Наш error-bank уже собирает симптомы. Следующий шаг очевиден: когда генератор падает, агент сначала ищет похожий случай в банке, и только потом отлаживает с нуля.