Отладка CrewAI на AWS Bedrock AgentCore: 4 молчаливых бага

Зачем читать эту статью?

Вы собрали крутого AI-агента на CrewAI, локально всё работает. Но при деплое на AWS Bedrock AgentCore вы сталкиваетесь с тишиной: 200 OK с пустым телом, контейнер падает без логов, SDK не тот. Я потратил неделю на отладку этих молчаливых багов. Вот полный трейл — чтобы вы не повторяли моих ошибок.

Проект: AI-агент для адаптации резюме

Я построил агента на CrewAI и Amazon Bedrock. Он берёт описание вакансии, анализирует ваше резюме, находит пробелы и переписывает bullet points под требования. Локально — идеально. Деплой на прод — ад.

AWS запустила Bedrock AgentCore в июне 2026 как managed runtime для AI-агентов. Контейнеризируешь агента, пушишь образ — AgentCore сам масштабирует, управляет памятью, обрабатывает вызовы. Звучит просто. Не было просто.

Баг 1: SDK, которого нет на PyPI

Документация говорит установить bedrock-agentcore-client. Я запустил:

pip install bedrock-agentcore-client

Установилось успешно. Без ошибок. Но это пакет-пустышка на PyPI. Он устанавливается, импорты падают молча, а ваш контейнер собирается успешно, но с битой зависимостью внутри.

Настоящий SDK лежит в CodeArtifact AWS. Нужно настроить pip на приватный индекс:

aws codeartifact login --tool pip \
    --domain amazon-agent-runtimes \
    --repository agent-runtimes-pypi \
    --domain-owner 600427722194

Затем устанавливать оттуда. Пакет на PyPI — ловушка. Никто не предупреждает.

Потеряно часов: 3. Ошибка появляется только в рантайме, когда контейнер пытается импортировать модуль. Сборка успешна, пуш успешен, деплой успешен, вызов возвращает пустой payload.

Баг 2: 200 OK, означающий ошибку

Починив SDK, я задеплоил и вызвал агента:

aws bedrock-agentcore-control invoke-agent-runtime \
    --agent-runtime-id abc123 \
    --payload '{"job_description": "..."}'

Ответ: HTTP 200. Payload: пустая строка. Не 500, не 400, не сообщение об ошибке. Успешный HTTP-ответ с пустотой внутри.

Проверил CloudWatch — логов нет. Контейнер работает. Runtime активен. Проблема: у IAM-роли не было разрешения bedrock:GetAgentRuntime. Без него эндпоинт принимает запрос, направляет в никуда и возвращает 200 с пустым телом.

Нет сообщения об ошибке. Нет записи в логах. Сервис возвращает успех, когда терпит неудачу.

Потеряно часов: 5. Фикс — одно IAM-разрешение, отсутствие которого не даёт никакого сигнала об ошибке.

{
    "Effect": "Allow",
    "Action": "bedrock:GetAgentRuntime",
    "Resource": "*"
}

Баг 3: Контейнер, упавший без логов

Следующий баг. Контейнер стартует, проходит health check 30 секунд, затем умирает. Никакого исключения в CloudWatch. Статус "Failed" без причины.

Я добавил логи везде: print, структурированное логирование, обработчики исключений вокруг каждого импорта. Ничего не появилось в CloudWatch, потому что контейнер не успевал инициализировать фреймворк логирования.

Причина: отсутствие USER 1000 в Dockerfile.

# Этот падает молча
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install -e .
CMD ["python", "-m", "my_agent"]

# Этот работает
FROM python:3.12-slim
RUN useradd -m -u 1000 agentuser
WORKDIR /app
COPY . .
RUN pip install -e .
USER 1000
CMD ["python", "-m", "my_agent"]

AgentCore требует, чтобы контейнер запускался от UID 1000. Если нет — runtime убивает контейнер. Сообщение об ошибке в консоли: "Failed." Просто "Failed." Ни слова о user, permissions или UID.

Я нашёл это, читая примеры репозиториев команды AgentCore на GitHub. Не документацию. Пример Dockerfile.

Потеряно часов: 4.

Баг 4: Regex имени, который никто не документировал

Я хотел назвать runtime resume-tailor-agent. Деплой упал:

An error occurred (ValidationException):
  Name must match pattern: ^[a-zA-Z0-9_]+$

Дефисы запрещены. Ок, переименовал в resume_tailor_agent.

Но сообщение об ошибке появляется только при использовании control plane client. Если используете консоль — кнопка просто не срабатывает. Ни красной рамки, ни тоста, ни сообщения валидации.

Потеряно часов: 1. Мелочь, но паттерн тот же: молчаливые ошибки.

Разделение на два клиента, о котором никто не говорит

Тут архитектурный момент. У AgentCore есть ДВА Python-клиента:

• bedrock-agentcore-control — для управления runtime (создать, обновить, удалить)
• bedrock-agentcore — runtime SDK (то, что работает внутри контейнера)

Документация использует их взаимозаменяемо. Примеры кода импортируют из одного в секции настройки и из другого в секции вызова. У них разные пути установки, разные репозитории CodeArtifact и разные API.

Если установить неправильный — ничего не скажет. Код работает до первого импорта, которого нет в установленном пакете. А так как у обоих пакетов пересекаются имена модулей в некоторых версиях, ошибка может быть AttributeError глубоко внутри функции, а не чистым ImportError наверху.

Я составил таблицу, какой клиент что делает:

• bedrock-agentcore-control — создание/управление runtime — установка из CodeArtifact (domain: amazon-agent-runtimes)
• bedrock-agentcore — runtime SDK (внутри контейнера) — установка из CodeArtifact (тот же domain)
• boto3 (bedrock-agent) — вызов снаружи — стандартный pip

Этой таблицы нет ни в одной документации, что я нашёл.

Что я вынес

Пять дней отладки. Четыре различных молчаливых бага. Ноль полезных сообщений об ошибках.

Каждая проблема следовала одному паттерну: система принимала неверный ввод, возвращала успех и падала где-то ниже по стеку, не сигнализируя о проблеме. 200 OK, означающий ошибку. Сборка, успешная с SDK-пустышкой. Контейнер, падающий без логов.

Если бы у меня был Sentry в контейнере с первого дня, я бы поймал ошибку импорта, краш по UID и пустой ответ за часы, а не дни. Наблюдаемость — не опция для деплоя агентов. Инфраструктура активно скрывает от вас ошибки.

Три принципа, которые я теперь использую:

1. Никогда не доверяй 200 OK от нового сервиса. Валидируй тело ответа. Если пусто — что-то сломалось молча наверху.
2. Тестируй импорты при старте контейнера, до всего остального. try/except вокруг каждого критического импорта с явной строкой лога. Если SDK фейковый — узнаешь в первую секунду.
3. Читай примеры репозиториев, а не только документацию. Dockerfile в примере AWS содержал USER 1000. Документация об этом молчала. Примеры кода — иногда настоящая документация.

Я уже добавил Sentry в пайплайн своего агента для сканера безопасности. Трейсы вылавливают проблемы за секунды — то, на что раньше уходили часы с print-ами. Урок усвоен.

Все описанные ошибки — из июля 2026 на GA-релизе AgentCore. К моменту вашего чтения некоторые могли быть исправлены. Но паттерны молчаливых ошибок в новых сервисах AWS, вероятно, вечны.