OpenHands Agent Canvas: self-hosted центр управления кодинг-агентами

OpenHands, один из самых известных проектов в области открытых кодинг-агентов, переделал свой основной репозиторий в Agent Canvas. В README он описан как self-hosted центр управления для кодинг-агентов и автоматизаций. Смысл в том, что инструменты первой волны давали каждому агенту отдельное окно, а следующая волна — это оркестрация: один интерфейс, из которого видно и управляется сразу несколько агентов и бэкендов. Технически это одно React-приложение. Оно умеет запускать самого OpenHands-агента, Claude Code, Codex, Gemini и любые агенты, которые говорят на Agent-Client Protocol (ACP). Бэкендом может выступать что угодно: локальный компьютер, Docker-контейнер, виртуальная машина или OpenHands Cloud. Проект поставляется как npm-пакет @openhands/agent-canvas под лицензией MIT. Самое интересное для разработчика — архитектура. В репозитории нет тяжёлого control-plane сервера: фронтенд сам является продуктом. Слои такие: дерево маршрутов React Router в src/routes (разговоры, автоматизации, настройки), electron/main.mjs, который упаковывает то же приложение в десктопную оболочку, небольшие клиентские хранилища состояния вроде conversation-store.ts, адаптер src/api/agent-server-adapter.ts, который приводит ответы бэкендов к типам приложения и определяет режим развёртывания, а также сервисы ACP, автоматизаций и учёта баланса LLM. Отдельная тема — ACP как сменная шина агентов. Сервис ACP управляет провайдерами, учётными данными и списками моделей, а реестр провайдеров перечисляет семейства агентов: claude-code, codex, gemini и общий CLI. Аутентификация может быть как через сохранённые секреты, так и через OAuth-подобный device flow. В настройках видно статус авторизации и предупреждения о конфликтах, когда два провайдера пересекаются. Если вы делаете свои инструменты вокруг агентов, это хороший пример отношения к агенту как к заменяемому бэкенду, а не как к жёстко зашитой функции. Автоматизации сделаны как запланированные разговоры. Сервис автоматизаций общается с бэкендом по /api/automation и создаёт задачи с cron-расписанием и точками входа через вебхуки. Каждый запуск стартует настоящий разговор на agent-сервере с метками автоматизации, поэтому автоматический прогон виден в той же ленте, что и человеческий чат. Результаты уходят наружу через сервис хуков в Slack, GitHub, Linear и Notion, а интеграция с Git-провайдерами подкладывает нужный репозиторий для задач вроде разбора issue или генерации отчётов. Есть и операционная зрелость, редкая для клиентского кода: проверка совместимости версий перед обращением к серверу, кэширование метаданных разговоров, разделение состояния LLM на баланс и подписку, чтобы предупредить до падения задачи. Документация по self-hosting собирает всё вместе — статический фронтенд, agent-сервер, бэкенд автоматизаций и прокси. Осторожность тоже важна, и авторы говорят об этом прямо: автоматизации могут писать в публичные сервисы, а агенты — выполнять реальные команды на реальных машинах. Виртуальную машину с агентом стоит воспринимать как любой открытый сервер, запускать всё на своих машинах и ограничивать права для учётных данных.