agents-get-started

Agents Get Started — официальный навык AWS для пути от пустого каталога до локально работающего и затем развёрнутого агента в Amazon Bedrock AgentCore. Он помогает выбрать runtime и framework, создать проект, запустить dev-сервер, выполнить первый deploy и сделать invocation. Навык рассчитан на ситуацию, когда разработчик хочет создать новый проект или только начал AgentCore. Он не предназначен для исправления сломанных credentials и CLI, добавления возможностей в уже существующий проект или миграции старого Bedrock Agent; для этих случаев исходник направляет к agents-debug, agents-build или agents-connect. Перед началом проверяется версия командой agentcore --version. Источник требует CLI версии 0.9.0 или новее; если команда отсутствует, он предлагает установить @aws/agentcore через npm, а если версия старая — обновить CLI и проверить версию повторно. Затем выясняется намерение разработчика: он сравнивает варианты или уже готов создавать проект. При исследовании сначала обсуждается framework, а команда create не строится до явного решения. Если в текущем каталоге уже есть agentcore/agentcore.json, его нужно прочитать и продолжить существующий проект, а не выполнять повторный scaffolding. Для CLI-scaffolded Python-проектов источник перечисляет Strands, LangGraph, Google ADK и OpenAI Agents. Strands подходит для AWS-native старта и тесной интеграции с AgentCore, LangGraph — для сложных графов и существующих инвестиций в LangChain, Google ADK — для команд, использующих Google toolkit, а OpenAI Agents — для уже выбранного OpenAI SDK. Framework и model provider не являются одним и тем же: Strands, LangGraph или другой framework определяет оркестрацию, а Bedrock, Anthropic, OpenAI или Gemini — поставщика модели. Если предпочтения нет, источник допускает рекомендацию Strands; если есть существующий стек, выбор должен учитывать его, а не общий шаблон. Для неподдержанного CLI framework предусмотрен BYO Container путь. Сначала создаётся проект с defaults, затем агент добавляется как byo с выбранным build и language, после чего разработчик пишет Dockerfile, реализующий Runtime HTTP contract. В описании контракта явно названы POST /invocations и GET /ping. agentcore deploy затем выполняет ECR push, CDK infrastructure и создание runtime. Для Java, TypeScript, Go, Rust и других языков источник предлагает контейнерный путь; TypeScript может использовать Express или Fastify, но приложение всё равно обязано реализовать нужный HTTP-контракт. Команда создания строится только после уточнения имени и параметров. Имя проекта должно быть длиной не более 23 символов, содержать только буквы и цифры и начинаться с буквы; дефисы, подчёркивания, точки и пробелы запрещены. Минимальный вариант — agentcore create --name <ProjectName> --defaults. При явном выборе можно передать framework, model-provider, build, memory и другие флаги. По умолчанию источник предлагает HTTP, CodeZip, Bedrock, память none и публичный network mode, но это рекомендации, а не универсальное решение. Перед фактическим созданием команда и её смысл должны быть показаны разработчику для подтверждения; навык не должен создавать проект скрыто. После scaffolding ключевой код находится в app/<AgentName>/main.py, проектная конфигурация — в agentcore/agentcore.json, настройки целей AWS — в agentcore/aws-targets.json, локальные переменные — в agentcore/.env.local, а CDK-инфраструктура — в agentcore/cdk/. В свежем проекте может присутствовать пример MCP-клиента: он удобен для демонстрации, но его endpoint нельзя считать частью бизнес-логики. Если gateway URL ещё не создан, клиент может получить None и запустить агента без MCP-инструментов; при отсутствии потребности в MCP этот пример следует удалить. Это ограничение важно проверять до вывода о том, что интеграция действительно подключена. Локальная разработка запускается командой agentcore dev. Для HTTP по умолчанию указан порт 8080, для MCP — 8000, для A2A — 9000. CLI может автоматически увеличить порт, если исходный уже занят, поэтому нужно читать фактический URL из баннера или явно задать --port. В локальном режиме память и gateway URLs недоступны: они требуют deploy. Локальный сервер использует model provider, настроенный в проекте, а не автоматически выбранного поставщика. Первый deploy выполняется командой agentcore deploy: AgentCore показывает preview ресурсов, запрашивает подтверждение, затем собирает и разворачивает инфраструктуру через CDK. Источник оценивает первый deploy в 3–5 минут. После deploy агент можно вызвать командой agentcore invoke с сообщением и проверить командой agentcore status. Дальнейший маршрут зависит от задачи: agents-build для access или memory, agents-connect для gateway и policy engine, agents-optimize для evaluator, agents-harden для production readiness и agents-build с protocol A2A для нескольких агентов. Навык описывает путь запуска и следующие переходы, но не подтверждает успешность AWS-ресурсов без фактического вывода команд, не заменяет проверку credentials и не обещает production readiness.