Agenta — открытая рабочая среда для агентов и командных автоматизаций. Проект поддерживает Claude Code, Pi и Codex как обвязки исполнения, выбор моделей и самостоятельное размещение. Это реальный продукт: возможности и исходный код опубликованы в репозитории Agenta-AI/agenta. Ниже разберём, что меняется при выборе обвязки и что проверить перед self-hosted запуском.
Обвязка, или harness, управляет выполнением агентного цикла и использованием инструментов. Agenta добавляет общую рабочую среду: конфигурации, файлы, доступ команды, автоматизации и историю запусков. Выбор обвязки позволяет менять исполнительный слой, но совместимость модели, инструментов и авторизации нужно проверять для выбранной пары.
Практическая ценность self-hosting — возможность выбирать инфраструктуру и контролировать её настройки. Это не обещание отсутствия внешней передачи данных: облачная модель, MCP-инструмент или внешний sandbox получают данные, необходимые для вызова. Подписка Claude/ChatGPT и API-ключ — разные способы доступа; их нельзя подменять друг другом.
Что такое Agenta и почему это замена Claude Cowork
Agenta сравнивает свой подход с Claude Cowork через открытость, выбор обвязки и модели. Такое сравнение полезно как ориентир, но не доказывает одинаковые возможности, стоимость или безопасность двух продуктов. Перед миграцией проверьте свои задачи, разрешения, перенос файлов и доступные интеграции.
В Agenta инструкции, навыки, файлы и разрешения отделены от выбора исполнительного слоя. Однако смена harness не гарантирует идентичного поведения. Прежде чем переносить рабочий процесс, повторите короткий контрольный сценарий и проверьте, какие инструменты реально доступны.
Модель выбирается вместе с совместимым harness и подключением провайдера. Agenta поддерживает облачные API и self-hosted модели, в том числе через Ollama. Локальный сервер модели должен быть доступен из фактического runtime агента: localhost в контейнере и localhost на хосте — разные адреса. Объём GPU и памяти определяется моделью и нагрузкой, а не наличием веб-интерфейса Agenta.
Третий компонент - протокол MCP. Агенты Agenta используют MCP-инструменты для расширения возможностей: работа с файловой системой, вызов внешних API, взаимодействие с базами данных. Набор инструментов описывается в конфигурации агента и может дополняться без изменения кодовой базы проекта.
Ключевые возможности: обвязки, модели и MCP-инструменты
Удобно разделять три решения: где выполняется агент, какой harness им управляет и какую модель он вызывает. MCP и другие интеграции добавляют действия с внешними системами. Разрешённый инструмент и доступная модель должны проверяться в конфигурации, а не выводиться из названия обвязки.
Что такое обвязки и зачем они нужны
Claude Code, Codex и Pi — поддерживаемые исполнительные слои. Не нужно жёстко делить их на «только код», «только тексты» и «эксперимент»: результат зависит от модели, инструментов и задачи.
В интерфейсе откройте агента и раздел Configuration → Model. Выбор модели сгруппирован по подключению и совместимому harness. Если пара недоступна или провайдер не подключён, сначала устраните это ограничение. Порядок описан в руководстве выбора модели и harness.
Полезный тест переключения: дать двум конфигурациям одну разрешённую задачу, сравнить результат, вызванные инструменты и расход. Рабочие файлы могут сохранять контекст проекта, но не гарантируют одинакового понимания задачи разными моделями.
Self-hosted модели и свои подписки: полный контроль
Для self-hosted модели проверьте поддерживаемый способ подключения и совместимость с выбранным harness. Укажите адрес, доступный именно из runner или sandbox, и выполните короткий запрос без рабочих данных. Не открывайте сервер инференса в интернет без авторизации ради проверки связи.
На self-hosted установке Agenta умеет использовать существующий вход в harness. Это отдельный режим с монтированием состояния входа в runner; обычный API-ключ не превращается в подписку. Доступ требует осторожности: файлы входа содержат секреты, а локальные запуски разделяют runner. Следуйте официальной инструкции подписок, не копируйте такие файлы в репозиторий и не выдавайте их другим пользователям. Первый пилот проще ограничить одним оператором и отдельным API-бюджетом.
Для команд, которые уже используют самописных AI-агентов на Python с LangChain, Agenta может стать общей средой управления. Но миграция не равна автоматическому переносу собственного кода, памяти и политик: сначала сопоставьте требования и проверьте один сценарий.
Роль MCP-инструментов в этой архитектуре - расширение возможностей агента без модификации обвязки. Агент может получить доступ к базе данных через MCP-сервер PostgreSQL, отправить сообщение в Slack через MCP-сервер мессенджера или создать тикет в Jira. Инструменты описываются в конфигурации агента и активируются при старте сессии.
Настройка агентов: инструкции, инструменты и разрешения
Инструкции хранятся в AGENTS.md. В них описывают роль, цели, контекст и правила общения. Выбор модели, harness, навыков и разрешений относится к конфигурации агента, а расписание — к автоматизации. YAML с ключами harness, schedule и triggers внутри текста инструкции сам по себе не создаёт эти настройки.
Агента можно настраивать через диалог или непосредственно в интерфейсе. После предложенного изменения проверьте конфигурацию и её версию. Это уточнение поведения через инструкции, а не обучение весов модели. См. назначение AGENTS.md и состав агента.
Иллюстрация текста инструкции для помощника по ревью, без исполняемых настроек:
# Помощник по ревью
Изучи предоставленный diff и связанный контекст.
Отделяй проверенные дефекты от гипотез.
Для каждого замечания укажи файл, причину и способ проверки.
Не изменяй репозиторий и не отправляй сообщения без отдельного разрешения.
Если доступ к нужным данным отсутствует, сообщи об этом.Затем отдельно выберите модель, подключите разрешённые инструменты и настройте права. Текст «не отправляй» полезен, но не заменяет техническое ограничение записи и публикации. Для первого теста используйте несекретный diff без подключения рабочего GitHub или Slack.
Рабочие папки и накопление знаний
Рабочие файлы дают агенту место для результатов и справочных материалов. Их сохранность зависит от настроенного хранилища и runtime. Сохранённый файл не означает, что модель прочитает его целиком в следующем запуске; полезно явно указать, какой источник нужен для задачи.
Сценарии использования рабочих папок:
- Накопление знаний о продукте - агент читает документацию, release notes, тикеты и формирует структурированную базу знаний, которая обновляется автоматически при выходе новых версий.
- Анализ конкурентов - агент мониторит сайты конкурентов, собирает изменения в позиционировании и фичах, сохраняет в папку структурированные отчёты.
- Изучение целевой аудитории - агент анализирует обращения пользователей, отзывы, комментарии в соцсетях и формирует портреты сегментов с указанием болей и ожиданий.
При смене harness можно опираться на сохранённые документы проекта, но перенос контекста следует проверить тестом. Отдельно предусмотрите резервное копирование и восстановление. В local-режиме разные агенты разделяют runner, поэтому рабочие папки нельзя считать границей безопасности между пользователями.
Автоматизация: расписания и события подключённых приложений
Agenta запускает агента по расписанию либо по событию подключённого приложения. Это реальные возможности, но их создают отдельно от AGENTS.md. Откройте Automations → New automation, выберите агента, условие запуска и задачу. См. создание автоматизации.
Для ежедневного отчёта сначала проверьте разовый запуск, источники и формат результата. Затем задайте расписание и часовой пояс, проверьте следующий запуск и получателя. Установите бюджет и ограничения инструментов: фоновая задача не должна зависеть от ответа человека на уточняющий вопрос.
Произвольный HTTP webhook нельзя считать готовой функцией этой инструкции. В текущем roadmap Agenta custom triggers ещё запланированы, а доступные событийные триггеры связаны с Composio. Для GitHub, Jira или другого приложения проверяйте именно поддерживаемое событие и его разрешения.
Пример для команды: подготовить черновик сводки по разрешённым тикетам. Автоматическую публикацию в Slack включают отдельно после проверки получателя, доступа и содержания. История запуска помогает понять, выполнилась ли задача; её наличие не доказывает успешную доставку сообщения.
Сопутствующий материал — обзор Google Antigravity 2.0. Не переносите его настройки расписаний на Agenta: у каждого продукта собственные конфигурация, ограничения и модель доступа.
Установка и первый запуск: проверка self-hosted конфигурации
Официальный путь использует Docker Compose. Это несколько сервисов, включая runner и хранилище, а не python -m agenta serve. Начните с отдельного тестового хоста, без клиентских данных и секретов других проектов. Потребуются Docker, Compose и Git; требования runtime проверяются для выбранной версии.
Для постоянно работающего экземпляра можно рассмотреть VPS Timeweb Cloud (партнёрская ссылка). До заказа проверьте ресурсы, доступные возможности Linux/FUSE, регион и тарификацию. Такой VPS размещает выбранные компоненты Agenta; он не превращает внешний LLM API или Daytona в локальный сервис и не гарантирует подходящую GPU-конфигурацию.
Подготовка нового каталога по официальному quick start:
set -eu
git clone --depth 1 --filter=blob:none --sparse https://github.com/Agenta-AI/agenta
cd agenta
git sparse-checkout set hosting/docker-compose api/oss/databases/postgres api/ee/databases/postgres
umask 077
cp hosting/docker-compose/oss/env.oss.gh.example hosting/docker-compose/oss/.env.oss.ghПеред запуском сопоставьте Compose, шаблон окружения и опубликованные версии образов. Зафиксируйте выбранную ревизию и теги; не считайте latest неизменным или обязательно опубликованным для каждого компонента. Сверяйте параметры с файлами именно этой ревизии, поскольку документация и main могут обновляться не одновременно.
Что проверить до первого старта
- Секреты. Замените все активные значения replace-me в защищённом env-файле независимыми случайными секретами. В текущем шаблоне это ключи авторизации/шифрования, внутреннего сервиса, runner и хранилища. Задайте собственный пароль PostgreSQL и согласуйте его со всеми настроенными DB URI. Не оставляйте username/password как готовую production-пару; имя пользователя должно совпадать и с healthcheck. Не показывайте файл в чате, Git или журнале.
- Доступ. Первый запуск должен быть доступен только оператору через защищённую сеть. Проверьте опубликованные порты итогового Compose: БД, object store, dashboard и runner нельзя случайно открыть наружу. Для публичного web-доступа сначала настройте HTTPS и ограничения регистрации по официальной инструкции доступа. По умолчанию регистрация открыта.
- Изоляция. Local-запуски разделяют один runner и его секреты. Не предоставляйте такой пилот недоверенным пользователям. FUSE и дополнительные capabilities в шаблоне требуют отдельной проверки администратором; отсутствие FUSE может повлиять на сохранение рабочих файлов. См. локальные запуски и границы sandbox.
- Данные и расходы. Определите резервную копию, срок хранения, лимит API и способ остановки ресурсов. Не меняйте ключ шифрования существующей установки без плана миграции: сохранённые секреты могут стать недоступны.
Источники текущих параметров: Compose-файл и шаблон окружения. Не копируйте отдельные значения сетевых портов из другой версии: адрес может уже быть частью port mapping. Полный порядок удалённого размещения приведён в руководстве Agenta.
После заполнения конфигурации выполните синтаксическую проверку без запуска контейнеров:
docker compose \
-f hosting/docker-compose/oss/docker-compose.gh.yml \
--env-file hosting/docker-compose/oss/.env.oss.gh \
--profile with-web --profile with-traefik config --quietУспешный config --quiet подтверждает только корректность Compose-конфигурации, а не безопасность, доступность образов, работоспособность моделей или настроенных секретов. Если проверка не проходит, исправьте причину до запуска. Не публикуйте обычный вывод config: он может содержать подставленные секреты.
После проверки перечисленных условий запустите выбранную версию по официальному quick start. В том же вызове Compose, с теми же -f, --env-file и профилями, действие up -d запускает стек, а ps показывает состояние. Затем откройте настроенный адрес в браузере, создайте агента через интерфейс, выберите подключённую модель и дайте одну короткую задачу без внешних действий. Статус контейнеров не заменяет проверку реального ответа.
Если вы уже экспериментировали с личными AI-агентами в мессенджерах, отдельно проверьте командный доступ: он добавляет границы доверия. Развёртывание, ввод ключей и тест модели при подготовке этого материала не выполнялись.
Сравнение с аналогами и развитие
Сравнивайте инструменты по своей задаче: личный помощник, командная среда, доступ к моделям, изоляция, интеграции и стоимость сопровождения. Наличие open-source лицензии не отменяет расходов на инфраструктуру, API и администрирование.
В материале об OpenClaw рассматривается отдельный продукт; из него нельзя выводить универсальное преимущество Agenta. Также неверно утверждать, что Hermes ограничен фиксированными облачными моделями: его официальный проект описывает разные провайдеры и локальные модели.
Сильная сторона Agenta в рамках этого обзора — общая конфигурация агентов, несколько поддерживаемых harness и автоматизации. Это сочетание функций, а не доказательство отсутствия аналогов. Доступность конкретной интеграции проверяйте в установленной версии.
Планы развития сверяйте с актуальным roadmap и отделяйте planned от shipped. Обзор архитектурных подходов Google Antigravity можно читать как дополнительный контекст, но он не подтверждает планы команды Agenta.
Начинайте с одного агента и безопасного ручного сценария. Затем проверяйте смену модели, сохранность файлов и расписание по отдельности. Такой пилот даст больше оснований для решения, чем обещание полного контроля одной командой.