Как из viewer для OpenClaw выросла мобильная консоль для сервера

Недавно я начал экспериментировать с OpenClaw - системой агентных инструментов, которая может выполнять задачи на сервере: запускать команды, редактировать файлы, работать с инфраструктурой.

У OpenClaw есть удобная возможность - агент может отправлять уведомления о своей работе в мессенджеры. Например, в Telegram. Идея понятная: агент выполняет задачу, пишет отчёт, а ты можешь следить за этим прямо с телефона.

Но довольно быстро стало понятно, что мессенджеры для этого подходят плохо.

Когда агент начинает работать активно, появляется множество сообщений:

• результаты команд

• вывод инструментов

• изменения файлов

• промежуточные шаги выполнения

И всё это превращается в длинную ленту сообщений.

Проблема в том, что мессенджеры просто не рассчитаны на такой тип данных.

В них неудобно:

• просматривать результаты tool-вызовов

• смотреть diff файлов

• понимать структуру выполнения задачи

• быстро находить нужный шаг агента

В какой-то момент я поймал себя на мысли, что постоянно делаю одно и то же:

1. получаю уведомление от агента

2. открываю SSH

3. захожу на сервер

4. проверяю, что он там сделал

И тогда возникла простая мысль: а почему бы не сделать нормальный мобильный интерфейс для наблюдения за работой агента?

Изначально я хотел написать просто viewer для OpenClaw. Приложение, которое может:

• подключаться к gateway

• показывать список сессий

• отображать сообщения агента

• показывать результаты инструментов

• отображать изменения файлов

Но довольно быстро стало понятно, что одного просмотра недостаточно.

А дальше всё немного… вышло из-под контроля.

Самой первой задачей было подключение к gateway и отображение истории работы агента.

Хотелось видеть:

• список сессий

• сообщения

• tool results

• цепочку выполнения

А также восстанавливать историю, если приложение закрыли.

Технически это оказалось интереснее, чем казалось сначала. Gateway работает через WebSocket, а подключение к нему удобнее всего делать через SSH-туннель.

Поэтому схема подключения получилась примерно такой:

1. приложение открывает SSH-соединение

2. поднимает локальный туннель

3. подключается к gateway через WebSocket

4. восстанавливает активную сессию

После этого можно смотреть, как агент выполняет задачи.

Но довольно быстро стало понятно, что просто наблюдать недостаточно.

Когда появился SSH

Практически каждый раз возникала одна и та же ситуация:

агент что-то сделал → хочется самому проверить результат.

Например:

• открыть файл

• посмотреть процессы

• проверить логи

• запустить команду

И каждый раз приходилось выходить из приложения и открывать обычный SSH-клиент.

Поэтому следующим шагом стало добавление SSH прямо в приложение.

Но хотелось, чтобы это был не просто терминал.

Большинство мобильных SSH-клиентов по сути выполняют команды как отдельные exec-вызовы. Это неудобно, потому что не сохраняется состояние shell.

Я попробовал сделать терминал как persistent shell-сессию, где сохраняются:

• текущая директория

• окружение

• состояние shell

Приложение ставит shell hooks и может понимать:

• начало и конец команды

• текущую директорию

• интерактивные запросы вроде password или yes/no

Это позволило немного лучше интегрировать терминал с остальной частью приложения.

Проблема мобильного терминала

Когда начинаешь работать с сервером с телефона, быстро становится понятно, что многие команды просто плохо читаются.

Например:

docker ps kubectl get pods ps aux

На маленьком экране это превращается в таблицу, которую приходится постоянно скроллить.

Поэтому появилась идея сделать систему rich-output plugins.

Некоторые команды автоматически преобразуются в более удобное представление. Например:

• ls

• ps

• top

• docker

• kubectl

Вместо стены текста можно показать структурированную карточку с данными.

Это сильно упрощает просмотр состояния системы с телефона.

Ещё одна вещь, которая неожиданно оказалась очень удобной — работа с execution-контекстами.

Когда агент работает с инфраструктурой, он может находиться:

• на хосте

• внутри Docker-контейнера

• внутри Kubernetes pod

И постоянно приходится переключаться между ними.

Поэтому появилась идея execution context stack.

Из приложения можно перейти:

host → container → pod

После такого перехода:

• терминал

• файловая система

• команды

работают уже внутри этого контекста.

То есть можно буквально провалиться в контейнер или pod и продолжить работу.

Работа с файлами

Следующая проблема, которая быстро проявилась — работа с файлами.

Когда агент редактирует файлы, важно понимать:

• что именно изменилось

• какие строки были добавлены или удалены

Поэтому приложение умеет:

• читать файлы на сервере

• показывать diff

• принимать или отклонять изменения

Это оказалось особенно полезно при работе с агентами.

Docker и Kubernetes

Когда проект начал немного расти, стало понятно, что постоянно вводить команды для проверки состояния контейнеров тоже не очень удобно.

Поэтому появились отдельные экраны для управления инфраструктурой.

Docker:

• список контейнеров

• volumes

• networks

• live logs

Kubernetes:

• nodes

• pods

• services

• namespaces

• live logs

Можно выбрать контейнер или pod и сразу перейти в его execution-контекст.

Ещё одна вещь, которая оказалась полезной — быстрый просмотр состояния сервера.

Приложение периодически собирает базовые метрики через SSH:

• CPU

• RAM

• disk

• load average

• uptime

Это скорее лёгкий operational dashboard, который позволяет быстро понять, что происходит с сервером.

Позже появился ещё один эксперимент — локальный агент внутри приложения.

В отличие от gateway-режима, где runtime работает на сервере, здесь orchestration происходит прямо в приложении.

Он может:

• использовать SSH

• выполнять команды

• работать с файлами

• запрашивать подтверждения

По сути это попытка сделать локального AI-оператора для сервера.

Что получилось в итоге

Изначально это должен был быть просто viewer для OpenClaw.

Но постепенно проект оброс функциями и превратился в нечто большее.

Сейчас из приложения можно:

• смотреть работу OpenClaw

• подключаться к серверу по SSH

• запускать команды

• редактировать файлы

• управлять Docker

• работать с Kubernetes

• смотреть системные метрики

И всё это внутри одной сессии.

В какой-то момент это начало выглядеть примерно так:

телефон → OpenClaw → SSH → сервер → контейнер → Kubernetes pod

В каком-то смысле получилась мобильная консоль для сервера.

Что дальше

Проект всё ещё активно развивается, и многие вещи пока остаются экспериментальными.

Мне будет интересно услышать мнение людей, которые:

• используют OpenClaw

• работают с DevOps инфраструктурой

• администрируют свои серверы

Интересно, насколько вообще востребован такой формат — управление сервером с телефона.

https://mobcodee.ru/