Недавно я начал экспериментировать с 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/