---
title: "Агенты"
id: "1306"
type: "page"
slug: "agents"
published_at: "2026-08-15T21:48:48+00:00"
modified_at: "2026-10-04T10:26:43+00:00"
url: "https://pastukhov.com/agents/multiagent/docs/agents"
markdown_url: "https://pastukhov.com/agents/multiagent/docs/agents.md"
excerpt: "Агент — экземпляр Pastukhov Agent на управляемом сервере. MultiAgent генерирует для каждого агента собственный compose.yml,…"
---

# Агенты

[https://pastukhov.com/agents/multiagent/docs/agents.md](https://pastukhov.com/agents/multiagent/docs/agents.md)

Агент — экземпляр [Pastukhov Agent](/agents/agent)
 на управляемом сервере. MultiAgent генерирует для каждого агента собственный `compose.yml`, разворачивает контейнер и следит за его жизненным циклом, а чаты агента собирает в централизованный интерфейс.

## Создание агента

Кнопка **«Новый агент»** открывает мастер: сначала выбирается тип — **отдельный агент** (автономный экземпляр Agent) либо один из **продуктов** семейства — Исследовательский агент, Аналитический, Агент данных, Прокси-агент, Чатбот, Телеграм, Тест-агент, CRM, Новостной или Портал. Затем форма: имя, сервер, образ (для продукта подставляется автоматически) и порт — он подбирается автоматически из диапазонов (5000+ для агентов, 6000+ для продуктов), поэтому конфликты исключены. Дополнительно задаются теги и лицензия (по умолчанию наследуется от сервера).

Продукты разворачиваются **со связанным агентом**: переменная «Linked agent» по умолчанию указывает на первый отдельный агент сервера, а если агентов на сервере нет — предлагается «Создать нового агента», и мастер создаёт полноценного агента тем же механизмом, а приложение получает его адрес и ключ для обратной связи. Учётные данные (пароль пользователя, пароль менеджера, JWT-секрет, API-ключ) генерируются сами. Подробнее — [Продукты](/agents/multiagent/docs/products)
.

## Жизненный цикл

- **Развернуть** (provision) — сгенерировать compose.yml, скачать образ и поднять контейнер;
- **Запустить / Остановить / Перезапустить** — управление контейнером. «Запустить» показывается, только когда контейнер стоит, «Остановить» и «Перезапустить» — только у работающего: у остановленного агента перезапускать нечего, поэтому в строке кнопок остаются «Запустить», «Пересоздать» и «Удалить»;
- **Пересоздать** (recreate) — единое действие обновления: перерисовывает compose, тянет свежий образ и пересоздаёт контейнер. Отдельной операции «получить образ» нет. Кнопка стала списком из двух вариантов — **«Плавный»** и **«Принудительный»**;
- **Удалить** — остановить и убрать контейнер (если сервер недоступен, удаление всё равно проходит), затем удалить запись управления и зеркальные чаты. Папки данных на сервере при этом сохраняются: безвозвратно убирает их только «Стереть агента».

Разница между вариантами — в занятости чатов. **«Плавный»** — обычное пересоздание: если у агента включены плавные обновления и чаты заняты, оно откладывается и срабатывает само, когда чаты замолчат. **«Принудительный»** запускает пересоздание сразу, не глядя на чаты, и отменяет уже запланированное обновление — это выход, когда чат подвис и ждать больше нечего. Те же два пункта есть в меню строки агента в дереве навигации («Пересоздать плавно» и «Пересоздать принудительно»), а на строке сервера — сразу для всех развёрнутых агентов и приложений сервера, по одному.

Все операции выполняются в фоновом режиме, а прогресс приходит в интерфейс в реальном времени — виден каждый шаг: подключение к серверу, подготовка файла настройки, загрузка образа, запуск контейнера. Развёртывание, пересоздание и удаление обновляют и Nginx-роутинг сервера.

Для автономных агентов доступен переключатель **«Плавные обновления»** на вкладке «Общие» (выключен по умолчанию, у продуктов отсутствует). Пока он включён, «Пересоздать» не останавливает работающий чат: если агент что-то обрабатывает или последняя активность была меньше 5 минут назад, обновление откладывается (тост «Обновление агента запланировано»), а фоновый сервис запустит его сам, как только чаты замолчат на 5 минут. Зависший отчёт «обрабатываю» не держит обновление навсегда: если агент всё ещё сообщает об обработке, но в его чатах не было активности больше 30 минут, отчёт считается устаревшим и обновление проходит — иначе именно подвисший чат не пускал бы обновление, которое его же и лечит. Внутренние изменения конфигурации (база, SSL, git) пересоздание не откладывают.

Статус контейнера агента берётся у Docker напрямую: running, restarting, stopped, paused, exited или dead.

Пока состояние контейнера неизвестно — например, сразу после перезапуска Мультиагента или при обрыве связи с сервером, — значок агента остаётся неокрашенным, а в дереве навигации у строки не рисуется точка. Цвет — это утверждение, а пока мы ничего не знаем, утверждать нечего; надпись рядом со строкой честно говорит «Неизвестно». «Не развёрнут» — это не состояние, а признак того, что контейнера ещё нет.

## Вкладки редактирования

В шапке страницы рядом со значком состояния видны живые показатели контейнера: загрузка процессора, занятая память и занятое место на диске (место считается вместе с образом, поэтому число отражает реальный объём). Показатели обновляются сами каждые 5 секунд, а наведение на число диска подсказывает, сколько контейнер записал и прочитал. Пока идёт первый замер, на месте чисел — значок загрузки, чтобы вместо своих цифр не мелькнули цифры прежнего агента. Ссылок-связей с приложениями и агентами в шапке нет — связи по-прежнему хранятся и доступны через Agent API.

Имя агента или продукта меняется прямо в шапке страницы — клик по нему открывает поле правки: введите новое имя и нажмите Enter, Escape отменяет. Новое имя сразу попадает в заголовок вкладки браузера и в навигацию. Остальные настройки собраны на вкладках:

- **Статус** — потребление CPU, RAM и диска контейнером;
- **Журналы** — последние 300 строк логов контейнера;
- **Общие** — имя, теги, образ, опции;
- **Git** — привязка репозитория Forgejo, ветки;
- **Подключение** — порт, URL, шаблон адреса;
- **Учётные данные** — пароли доступа к агенту;
- **Порты** — список проброшенных портов; у каждой записи есть переключатель «Публичный порт» — им запись открывается наружу сервера;
- **Тома** — монтирования поверх автогенерируемых;
- **Окружение** — свои переменные окружения агента: строки `КЛЮЧ=ЗНАЧЕНИЕ`, которые перекрывают общие переменные сервера. Эта же вкладка есть у приложения (продукта): его строки перекрывают и общие переменные сервера, и значения из шаблона, а запущенное приложение пересоздаётся само, чтобы значения вступили в силу;
- **Postgres** — база данных агента: режим хранения (встроенная, общая база сервера или внешняя), имя базы, пользователь и пароль, проверка подключения и **перенос данных** из базы другого сервера (только для автономных агентов);
- **Ссылки** — дополнительные значки в правом верхнем углу плитки агента на домашней странице сервера: заголовок, маршрут с портом или внешний адрес, значок и цвет;
- **compose.yml** — предпросмотр итогового файла с подсветкой синтаксиса;
- **Модели** — модели и лимиты параллельных чатов;
- **Файлы** — файловый менеджер на сервере, привязанный к агенту;
- **Project Settings** — настройки проекта агента;
- **Навыки** (Skills) и **MCP-серверы** — диалоги конфигурации самого агента (навыки — это файлы навыков агента, не каталог MultiAgent), открываются со страницы агента;
- **Задачи** (Tasks) и **Боты** (Bots) — расписания и боты агента;
- **Промпты** — очередь промптов агента.

## compose.yml

Файл настройки генерируется по шаблону сервера: порты — из записей агента, тома и переменные окружения — слияние автоматических (папки сервера, строка Postgres, лицензия) и ваших явных значений. Пока на сервере активен центральный вход, в окружение добавляется и секрет `SSO_PROXY_TOKEN` — по нему приложение сверяет заголовки личности, которые подставляет nginx, поэтому подделать их извне нельзя. Предпросмотр показывает итоговый файл до развёртывания — ошибки конфигурации видны заранее.

## Учётные данные

Для каждого агента доступны две операции с паролями: **генерация пользовательского пароля** (для входа в веб-интерфейс агента) и **смена пароля менеджера** (rotating manager password) — пароля, под которым MultiAgent обращается к API агента. Смена пароля менеджера пересоздаёт контейнер агента с новым значением в окружении.

## Docker.sock и развёртывание

Агенту можно подключить `/var/run/docker.sock` хост-сервера (по умолчанию выключено, включается на каждого агента отдельно). Это нужно, когда сам агент должен управлять контейнерами — например, чтобы разворачивать сервисы из своего проекта. Учитывайте: с docker.sock агент получает полный контроль над Docker хоста, поэтому включайте его только доверенным агентам.

## Импорт агентов

Если на сервере уже работают агенты, развёрнутые вручную, их не нужно пересоздавать. Команда **«Импортировать агентов»** сканирует сервер, находит контейнеры агентов, разбирает их compose-файлы и регистрирует агентов в MultiAgent с сохранением портов, томов и переменных окружения.

## Копирование и вставка агентов

Чтобы сделать второго такого же агента, не нужно заново заполнять мастер. В меню строки агента есть **«Скопировать агента»**: определение агента — со всеми настройками и учётными данными — кладётся в буфер обмена. В меню строки сервера есть **«Скопировать агентов»** (все агенты и приложения сервера разом) и **«Вставить агентов»**.

Вставка создаёт новые строки на выбранном сервере: на том же сервере получается копия, на другом — такая же строка, но пока пустая. Занятые слаг и порт разрешаются сами — новый агент получает свободные, поэтому ничего не конфликтует. Учётные данные переносятся, так что скопированный агент продолжает работать без повторной настройки. Строки создаются неразвёрнутыми: контейнер запускается с их страницы, как и у обычного нового агента.

Через буфер обмена переезжает только **определение** агента — настройки и учётные данные, но не файлы и не база. Чтобы перевезти агента вместе с данными, есть отдельная команда — о ней дальше.

## Перенос агента на другой сервер

Перевезти агента вместе с его файлами и базой можно командой **«Перенести агента»** в меню строки агента. В меню строки сервера для этого есть **«Перенести агентов»** (все агенты и приложения сервера разом) и **«Перенести все»**. Сначала выбирается целевой сервер, дальше работа идёт сама, а весь ход виден в журнале — в панели задач, где перенос можно и остановить кнопкой «Отмена».

Для каждого агента перенос идёт по шагам: на целевом сервере создаётся строка агента, но не разворачивается — как при вставке из буфера; затем переносятся папки данных, домашняя папка и проекты, с показом, сколько уже перенесено; для агентов на общей базе сервера переезжает и база. Занятые имя и порт разрешаются сами. Исходный сервер перенос не меняет: агент продолжает на нём работать, и убрать его оттуда можно отдельно — командой «Стереть агента», когда перенос завершён. В конце журнал сообщает итог: сколько перенесено из скольки. Если какая-то строка не перенеслась, остальные всё равно переносятся — сбойную строку видно в журнале, и перенос можно повторить, он перезаписывает данные на месте. Перенос создаёт новые записи, поэтому доступен только с действующей лицензией.

## Стереть агента

Команда **«Стереть агента»** в меню строки агента убирает его с сервера безвозвратно: контейнер, все папки данных, база и запись управления. В меню строки сервера те же действия есть сразу для всех агентов и приложений — **«Стереть агентов»** и **«Стереть все»**. Перед запуском показывается предупреждение: отменить стирание нельзя. Ход работы идёт в журнале панели задач, его можно остановить «Отменой», а в конце виден итог — сколько стёрто из скольки.

Если папки или база почему-то не стёрлись (сервер недоступен, не хватило прав), запись агента сохраняется, а сбойная строка помечается в журнале красным: агент остаётся в списке, и стирание можно просто повторить — ни запись, ни данные не исчезнут молча. От лицензии стирание не зависит: оно только удаляет.

## Обратный прокси и адрес агента

**Основной способ доступа — подпапка на Nginx сервера.** Каждый агент получает свой адрес вида `{база}/{слаг}/`: Nginx-контейнер сервера (ставится с вкладки Nginx) проксирует подпапку на контейнер агента по внутренней docker-сети, а сертификат — самоподписанный, собственная пара или Let’s Encrypt — закрывает HTTPS. Приложения соединяются контейнер-контейнер, публиковать порты наружу не нужно: неразвёрнутый или упавший агент отдаёт 502 только на своей подпапке. Подробнее — на странице [Маршруты](/agents/multiagent/docs/routes)
.

Порты агента при этом **закрыты для внешнего мира по умолчанию**: новая запись публикуется только внутри самого сервера (по адресу `127.0.0.1`). Снаружи агент открывается через подпапку, а соседние виртуальные серверы на той же машине его портов не видят. Открыть порт наружу можно переключателем **«Публичный порт»** у нужной записи на вкладке «Порты» — изменение вступает в силу при пересоздании. Исключения: сам веб-сервер Nginx и приём резервных копий публичны всегда, а общая база Postgres, наоборот, всегда закрыта.

Когда на сервере включён [центральный вход](/agents/multiagent/docs/servers)
, агенты и продукты закрываются «за центральным входом» **по умолчанию**: посетитель один раз входит на странице входа сервера, и подпапка агента уже открыта — собственный логин агента не требуется. Снять защиту с конкретного агента (или продукта) можно переключателем **«Защита SSO»** на вкладке «Подключение». Служебные машинные пути `/{слаг}/api/…` и `/{слаг}/svelteChatHub` при этом не закрываются — у них своя авторизация (JWT или API-ключ), поэтому управление агентами через MultiAgent продолжает работать. Прямое обращение по адресу `host:port` в обход nginx тоже не закрывается: там действует собственный вход агента. Подробнее о защите — в разделе «Защита приложений» на странице [Маршруты](/agents/multiagent/docs/routes)
.

Прежняя схема тоже работает как запасная: каждый агент доступен напрямую по адресу `http://{сервер}:{порт}` (для шифрования можно включить самоподписанный сертификат одним переключателем), а поле **«Адрес»** на вкладке подключения позволяет задать любой свой URL — например, когда агент спрятан за внешним туннелем. Переопределённый адрес учитывается везде: тест API, прокси-запросы, синхронизация чатов и генерация `compose.yml`.

MultiAgent также работает как **передаточный пункт** между браузером и API управляемых агентов: запросы вида `/api/agents/{agentId}/proxy/...` пересылаются на API агента от имени менеджера (если вход устарел, он обновляется сам и запрос повторяется). Благодаря этому браузер и внешние интеграции общаются с агентами через MultiAgent — открывать порты агентов наружу не требуется.

## Каталог образов

Вместо фиксированного каталога образов — **каталог продуктов**: из мастера «Новый агент» одним диалогом ставятся одиннадцать продуктов семейства — Мультиагент (6000), Исследовательский (6010), Аналитический (6020), Агент данных (6030), Прокси (6040), Чатбот (6050), Телеграм (6060), Тест-агент (6070), CRM (6080), Новостной (6090) и Портал (6100) — каждый со своим реальным логотипом, портом из диапазона продукта и генерируемыми учётными данными. Шаблоны продуктов лежат на диске MultiAgent в папке `AGENT_PRODUCTS` и добавляются простым помещением новой папки. Для автономного агента образ выбирается из каталога сервера — его можно пополнять своими образами.

## Репозитории Forgejo

Каждому агенту можно привязать git-репозиторий: существующий на Git-сервере [Forgejo](/agents/multiagent/docs/servers)
 или новый, который MultiAgent создаст сам. Ключ доступа выпускается и хранится автоматически. Репозиторий монтируется агенту как папка проекта — все коммиты агента сразу попадают в git.

## Дополнительные ссылки

На плитке агента или приложения на домашней странице сервера можно добавить свои значки — быстрые ссылки на связанные с приложением места. Раньше каждая ссылка занимала отдельную плитку, и один агент с тремя ссылками занимал четыре места; теперь значки небольшой строкой стоят в правом верхнем углу плитки самого агента, а название видно при наведении. Ссылка задаётся на вкладке **«Ссылки»** и состоит из четырёх частей: **заголовок** (всплывающая подсказка), **маршрут с портом** — тогда ссылка открывается на сервере по адресу `{база}/{слаг}/` и ведёт на указанный порт; **внешний адрес** — когда маршрут не нужен, значок просто открывает этот адрес; **значок и цвет** — из набора значков Material Symbols или свой цвет. Так на плитке агента появляются, например, ссылки на его панель управления или на страницу состояния без ручной правки веб-сервера. Рядом с кнопкой добавления есть **«Применить конфигурацию»**: она сразу применяет маршруты ссылок к веб-серверу сервера.

## Перенос базы данных

Автономному агенту можно перенести данные из базы на другом сервере. На вкладке **«Postgres»** выберите сервер-источник, контейнер с базой (обычно `agents-postgres`) и нужную базу, затем нажмите **«Перенести»** и подтвердите действие. MultiAgent сам снимет копию базы, перенесёт её на целевой сервер, очистит целевую базу, восстановит данные и вернёт их агенту — каждый шаг виден в ленте прогресса. Контейнер агента на время переноса останавливается: после успешного завершения просто запустите агента снова. Если что-то пошло не так, обработается сбойный шаг, а целевая база останется нетронутой.

[← Оглавление документации](/agents/multiagent/docs)