Павел AI

Мастер-класс по Hermes Desktop, часть 1: что такое Hermes Desktop

2026-08-19T10:18:36.744Z

Мне нужно исправить то, что я раньше говорил о Hermes Desktop. Какое-то время я описывал его как графический интерфейс для Hermes Agent. Это не совсем неверно. Просто сейчас он крайне недоработан.

Если сегодня вы откроете Hermes Desktop и подумаете, что перед вами Hermes Agent с более красивыми кнопками, то вы не до конца понимаете, что это за программа.

И прежде чем я посвящу целую серию мастер-классов тому, как использовать профили, режим бота, удаленные машины, плагины, терминалы, инструменты Git, поверхности приложений и все прочие нелепые штуки, которые здесь скопились, нам нужно разобраться с ментальной моделью.

Потому что в Hermes Desktop гораздо больше смысла, когда вы понимаете, что на самом деле происходит под этим окном.Итак, с этого мы и начнем.

Hermes Agent по-прежнему является движком

Первое, что нужно понять: Hermes Desktop — это не отдельный ИИ-агент.

Вы не запускаете Desktop и вдруг не получаете другого Hermes с его собственным мозгом, навыками, памятью и какой-то загадочной индивидуальностью, которая прячется где-то в папке.

Hermes Desktop построен на той же среде выполнения Hermes Agent.

В текущей документации об этом говорится прямо. Настольная версия использует тот же базовый мир Hermes: конфигурация, сеансы, навыки, память, инструменты, провайдеры и поведение агента — все это живет в Hermes Agent, а не создается заново в настольном приложении.

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

Лучше думать об этом так:

Hermes Agent — это двигатель.Hermes Desktop — это кабина пилота.

И эта кабина пилота стала НАМНОГО серьезнее, чем несколько месяцев назад.

На самом деле в ней есть три основных элемента

Я бы хотел, чтобы больше людей это поняли, потому что это сразу объясняет множество особенностей поведения Hermes Desktop. Текущая архитектура Desktop имеет три четких зоны ответственности. 1. Electron отвечает за нативные компоненты рабочего стола.

Hermes Desktop — это приложение Electron.Electron отвечает за то, что на самом деле относится к десктопным приложениям: окна, интеграцию с аппаратным обеспечением, жизненный цикл приложения, поведение на уровне операционной системы и связь между приложением и возможностями компьютера.Это не агент.Это оболочка, которая позволяет Hermes вести себя как настоящее десктопное приложение, а не как терминальная программа, изо всех сил притворяющаяся таковым.

2. React отвечает за то, что вы видите и с чем взаимодействуете.Видимая часть Hermes Desktop — это рендерер React.

Это ваш транскрипт, композитор, навигация, настройки, панели, предварительные просмотры и постоянно растущий набор интерактивных элементов, которые появляются в Desktop. Именно благодаря этому слою Desktop может делать то, что в терминале выглядело бы чертовски неуклюже.

Терминал отлично справляется со своей задачей.

Попытки заставить его работать как полноценное визуальное рабочее пространство в конечном итоге превращаются в ASCII-гимнастику, о которой никто не просил.

3. Серверная часть Hermes Agent выполняет фактическую работу агентаЭто самое важное. Серверная часть отвечает за реальную работу Hermes: сеансы, инструменты, вызовы моделей, потоковую передачу, выполнение агентов и состояние, которое относится к среде выполнения агентов. Desktop взаимодействует с серверной частью, а не перестраивает всю эту логику внутри Electron.

Такое разделение — одна из главных причин, по которой Desktop может продолжать развиваться, не превращаясь в какую-то странную версию Hermes Agent.Пользовательский интерфейс может стать более функциональным.Electron может получить новые встроенные возможности.

Среда выполнения агента может продолжать выполнять свои функции.

Необязательно, чтобы все они превратились в один гигантский комок кода, скрепленный молитвами и пометкой TODO шестимесячной давности.

Так что же на самом деле запускается, когда вы открываете Desktop?

На высоком уровне процесс выглядит так:

Пользовательский интерфейс Hermes Desktop

↓

Рендерер React / транспорт для десктопа

↓

Обмен данными через JSON-RPC и WebSocket

↓

`hermes serve`

↓

Среда выполнения Hermes Agent

Вот текущая архитектура, о которой стоит помнить.Desktop не встраивает `hermes --tui` в красивое окно.

Кроме того, недостаточно просто открыть веб-панель Hermes в Electron и на этом успокоиться. Встроенный пользовательский интерфейс для настольных компьютеров взаимодействует с серверной частью Hermes.

По умолчанию Desktop может управлять локальным сервером `hermes serve` на том же компьютере.

В этом сервере находится агентская часть уравнения.

Для более старых версий среды выполнения предусмотрена некоторая совместимость, поэтому в старых руководствах в этом контексте может упоминаться безголовая панель управления, но в современной архитектуре Desktop основное внимание уделяется команде `hermes serve`.

Это важное отличие, если вы уже давно используете Hermes и у вас в голове засели старые инструкции. Спросите меня, откуда я знаю.

Рабочий стол, интерфейс командной строки, пользовательский интерфейс и панель управления — это не одно и то же

В Hermes накопилось столько интерфейсов, что очень легко использовать пять разных слов для обозначения трех разных вещей и запутать всех вокруг.

Так что давайте это исправим.

Интерфейс командной строки

Интерфейс командной строки — это часть Hermes, работающая через командную строку.

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

Я до сих пор постоянно им пользуюсь.Desktop не сделал интерфейс командной строки устаревшим, как установка файлового менеджера не сделала устаревшей команду `ls`.

TUI

TUI — это интерактивный интерфейс Hermes внутри терминала.

По-прежнему в стиле терминала.По-прежнему полезен.По-прежнему не то, что Hermes Desktop тайно рендерит под капотом.

Веб-панель

Веб-панель — это еще одна поверхность Hermes, выполняющая свою функцию.Она не является синонимом Hermes Desktop, и ее не следует путать с серверной службой, с которой в настоящее время взаимодействует Desktop.

Это различие становится все более важным по мере развития архитектуры.Hermes

Desktop

Desktop — это нативная поверхность приложения.

Она создана для того, чтобы предоставить Hermes гораздо более богатую визуальную и машинно-ориентированную среду, при этом опираясь на ту же среду выполнения агентов.

Это не четыре конкурирующих продукта, из которых нужно выбрать лучший и отстаивать его на Reddit, пока все не устанут.

Это разные способы взаимодействия с одной и той же более широкой системой Hermes.

Один «Гермес», множество поверхностей

Эта общая архитектура имеет очень практичное применение.

Ваши сеансы работы на компьютере не должны существовать в какой-то изолированной вселенной.

Система сессий принадлежит серверной части.

Именно это общее состояние позволяет сессиям Hermes отображаться в разных интерфейсах, а не вести собственную изолированную историю в каждом фронтенде.

Это одна из причин, по которой я перестал задаваться вопросом «Какой интерфейс мне использовать?».

Я использую тот интерфейс, который подходит для того, что я делаю.

Если я работаю в терминале, то CLI или TUI всегда под рукой.

Если мне нужно провести за компьютером больше времени и я хочу видеть файлы, предварительные просмотры, визуальный контекст, настройки, терминалы или другие элементы рабочего стола, я использую Desktop.

Если я взаимодействую с помощью постоянно включенного обмена сообщениями, то это еще одна поверхность.

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

«Локальное» по умолчанию не означает «только локальное».

Вот где архитектура становится по-настоящему интересной.

Пользовательский интерфейс Desktop и среда выполнения Hermes не обязательно должны находиться на одном физическом компьютере.

Обычно Desktop прекрасно работает с бэкендом, запущенным локально на том же компьютере.

Но Desktop также может подключаться к Hermes, работающему где-то еще.

Концептуально это может выглядеть так:

Ваш настольный компьютер или ноутбук

Hermes Desktop

↓ сеть

Другой компьютер

Серверная часть Hermes

↓

Среда выполнения Hermes Agent

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

Я не буду превращать первую часть в статью о удаленных вычислениях, потому что мы пробудем здесь до четверга.

Этому мы посвятим отдельную главу.

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

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

И нет, серверная часть Desktop — это не шлюз обмена сообщениями

Эта терминология может быстро надоесть, поэтому я сразу проясню ситуацию.

Серверная часть Hermes Desktop и постоянно работающий шлюз обмена сообщениями, используемый для таких каналов, как Telegram, Discord, Slack и других, — это не одно и то же.

На удаленном компьютере с Hermes могут быть запущены оба сервиса.

Но это не делает их одним сервисом.

В текущей архитектуре Desktop серверная часть, используемая Desktop, является центральной, в то время как шлюзы обмена сообщениями выполняют свои собственные функции для постоянно работающих каналов.

Если вы когда-либо читали три руководства по Hermes и задавались вопросом, почему слово «шлюз» вдруг стало означать все, кроме выхода из аэропорта, то вот вам часть ответа.

Мы подробно разберем соединения и шлюзы в следующих выпусках.

Зачем вообще нужен Desktop?

Здесь ответ кардинально изменился с течением времени.

Если бы Desktop по-прежнему представлял собой не более чем окно чата с возможностью выбора модели, я бы посоветовал вам использовать тот интерфейс, который вам больше нравится, и жить своей жизнью.Но это уже не про Hermes Desktop.

В официальном дизайне Desktop в центре внимания остаются транскрипт и композитор.Чат по-прежнему является основной функцией.Однако вокруг этого диалога Hermes выстраивает настоящую рабочую среду.

Текущие функции Desktop включают в себя такие возможности, как поиск проектов и репозиториев, файлов, артефактов, терминалов, просмотр Git и рабочих деревьев, визуализация памяти, быстрый доступ, взаимодействие в стиле HUD, профили, параллельные сеансы, режим бота, плагины, удаленные серверы и все более разнообразный интерактивный контент внутри самого диалога. Я намеренно не рассказываю обо всем этом здесь.

Об этом и пойдет речь в мастер-классе.Суть первой части заключается в следующем:

Называть Hermes Desktop «графическим интерфейсом» — это все равно что называть мастерскую «комнатой, где лежит молоток».

С технической точки зрения — да. Но мы многое упускаем.

Desktop может стать более функциональным, не заменяя Hermes Agent

В основе всего этого лежит один архитектурный трюк. Благодаря разделению обязанностей Hermes Desktop может создавать все более сложные визуальные эффекты, не перенося «мозг» агента в пользовательский интерфейс.

Бэкенд по-прежнему отвечает за выполнение агента. React по-прежнему отвечает за взаимодействие и представление данных. Electron по-прежнему отвечает за нативный десктопный слой.

Это дает проекту возможность создавать решения, которые будут работать на десктопах, не превращая каждый интерфейс Hermes в нечто однотипное.

Именно поэтому некоторые из последних разработок для десктопов так интересны. Интерактивные поверхности приложений могут быть частью общего интерфейса. Плагины могут расширять возможности десктопа.

Нативный пользовательский интерфейс может отображать рабочие процессы, которые было бы сложно воспроизвести в виде вывода в терминал.

А агент Hermes по-прежнему остается агентом Hermes. Это гораздо более понятная модель, чем «они создали графический интерфейс».

Desktop doesn't replace the other Hermes interfaces

Я хочу внести ясность, прежде чем кто-то вырвет один абзац из контекста и развяжет священную войну за терминалы.

Я по-прежнему люблю интерфейс командной строки.

Я по-прежнему использую рабочие процессы с терминалом.

Есть задачи, для которых терминал — идеальный интерфейс.

Есть задачи, для которых лучше подходит рабочий стол.

Есть задачи, для которых мне нужен постоянно работающий шлюз обмена сообщениями.

В этом и суть.

Hermes не заставляет взаимодействовать только через одно окно.

Интерфейсы дополняют друг друга.

Вы выбираете наиболее подходящую поверхность, в то время как система Hermes под ней продолжает выполнять свою работу.

Ментальная модель, которую следует сохранить

Если вы ничего не запомнили из первой части, запомните вот что:

Hermes Agent — это среда выполнения агента.

`hermes serve` — это серверная служба, с которой в настоящее время взаимодействует Hermes Desktop.

Рендерер React — это визуальное рабочее пространство, с которым вы взаимодействуете.

Electron обеспечивает нативную оболочку для настольных компьютеров и интеграцию с аппаратным обеспечением.

Интерфейс командной строки, TUI и веб-панель — это другие интерфейсы Hermes со своими преимуществами.

Шлюзы обмена сообщениями — это отдельная постоянно работающая инфраструктура для поддерживаемых каналов чата.

Вот такая схема.

И теперь, когда у нас есть карта, мы можем приступить к изучению огромного количества территорий, расположенных на ней.

Мы не просто вываливаем на вас кучу функций.Мы будем разбирать их слой за слоем, пока вы не поймете систему достаточно хорошо, чтобы сделать ее своей. рассмотрим установку и настройку, подключения, профили, режим бота, сохранение сессий, удаленный Hermes, встроенные возможности, плагины, интерактивные приложения в чате и, наконец, полноценную настольную версию, которой я пользуюсь каждый день.

Но все это бесполезно, если архитектура, лежащая в основе, несовершенна.

Поэтому в первой части мы займемся скучной на первый взгляд работой, которая в итоге упростит все остальное:

Разберемся, что на самом деле представляет собой Hermes Desktop.Теперь мы можем начать пользоваться этой чертовой штукой. 🤘

Официальные источники

Перевод на русский интерфейса Hermes agent DESCTOP.

2026-08-19T05:32:07.785Z

1.Расширенные настройки, верхняя часть

2.Расширенные настройки, прокручено вниз

1. Память и контекст

2. Безопасность

3. Рабочее пространство

4. Внешний вид > Выбор питомца (Специальный макет)

5. Чат

6. Уведомления

7. Оплата

8. Провайдеры > Аккаунты (Развернутое меню)

9. Провайдеры > Пользовательские эндпоинты (Развернутое меню)

10. Шлюз

Подписывайтес ТГ канал

Агент Hermes только что узнал, как остановиться!

2026-08-18T06:05:14.942Z

Одна из самых важных вещей, которым может научиться ИИ-агент, — это умение останавливаться.Звучит почти до смешного просто.Но это не так.Мы тратим огромное количество времени на то, чтобы оценить возможности агентов по тому, что они могут запустить.Могут ли они использовать браузер?Запустить терминал?Генерировать медиафайлы?Вызывать API?Делегировать работу?Продолжать работать без присмотра?Круто.Но есть еще один критерий, которому уделяется гораздо меньше внимания: Что произойдет, если я передумаю?Hermes Agent только что устранил вполне реальную проблему.

Когда «стоп» означало «подожди»

Hermes уже поддерживает прерывание активной работы. Вы можете перенаправить ее. Вы можете дать команду остановить ее.

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

Некоторые инструменты поддерживают прерывание. Они периодически проверяют, вошел ли пользователь в систему, и при необходимости корректно завершают работу.

Другие могут зависнуть на входящем звонке и просто сидеть так, пока работа не возобновится.

Это создавало неудобный пробел в последовательном выполнении инструментов.

Пользователь мог бы сказать:

Остановка. Займись чем-нибудь другим.

И инструмент мог бы ответить:

Круто. Я займусь этим, когда закончу.

Один из зарегистрированных случаев был связан с генерацией и масштабированием изображений с помощью FAL. Сообщается, что перенаправление находилось в очереди примерно 40 секунд в ожидании завершения этой работы.

Сорок секунд — не такая уж катастрофа.

Но суть не в этом.

Дело в том, что человек уже вернул себе контроль.

Система казни просто не успела среагировать.

Исправление — это нечто большее, чем генерация изображений

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

Кроме того, существует проблема «зомби-результата»

Здесь есть еще один неприятный пограничный случай.

Допустим, Hermes перестает ожидать завершения работы инструмента.

Базовый рабочий процесс в конечном итоге все равно завершается.

Вы совершенно не хотите, чтобы этот старый результат всплыл в диалоге позже и был объявлен успешным после того, как пользователь его отменил.

Новый способ отмены не позволяет рассматривать это позднее завершение как успешный результат работы инструмента.

После того как Hermes принял решение об отмене звонка, он остается отмененным в реальности агента.

На первый взгляд это кажется незначительной деталью реализации.

Но это не так.

В агентных системах полно подобных деталей.

«Стоп» должен становиться все более действенным по мере развития агентов.

Здесь есть одно важное отличие.

Hermes не может волшебным образом прервать каждую удаленную операцию, происходящую где-то за пределами процесса.

Внешняя служба, которая не сотрудничает с агентом, все равно может завершить свою работу.

Что может сделать Hermes, так это вернуть управление в цикл агента, вместо того чтобы заставлять пользователя ждать завершения этой операции, прежде чем что-то еще станет возможным.

И это подводит нас к более важному вопросу.

Мы продолжаем наделять агентов все большими полномочиями.

Файлы.

Браузеры.

Оболочки.

API.

Фоновые задания.

Другие агенты.

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

Способности привлекают внимание.

Автономность — это демонстрация возможностей.

Но именно контроль делает их полезными.

Агент на самом деле не под вашим контролем, если «остановка» означает только «после того, как я закончу».

Будущее пользовательского опыта с агентами — это не только обучение агентов тому, как продолжать работу.

Это чертовски важно, чтобы человек мог заставить их остановиться. 🤘

Посмотреть исходное изменение Hermes Agent на GitHub

ТГ канал-https://t.me/Novopoltsev_Pavel

🧭 Kanban-доска в Hermes Agent как я собрал управляемую команду агентов.

2026-08-04T09:50:54.822Z

Три уровня multi-agent-работы, пять созданных профилей и реальная исследовательская задача, прошедшая весь путь от Ready до Done

Как я собирал multi-agent workflow на Windows: профили, dispatcher, heartbeat, workspace и первый живой прогон t_9a60e2a9

Коротко о результатеЯ не стал запускать сразу семь агентов. Сначала закрепил оркестратора, добавил специалистов и проверил передачу задачи на реальном кейсе.В Hermes есть три уровня работы с агентами: одноразовый субагент через delegate_task, ручное переключение профилей и автоматическая раздача задач через Kanban.Задача t_9a60e2a9 ушла к @gza, отработала за 11 минут и вернула memo примерно на 1,8 тысячи слов с 19 релевантными видео и проверенными цитатами.Очередь запускает только готовые и назначенные задачи. Параллельность ограничивает delegation.max_concurrent_children, по умолчанию одновременно работают 2–3 воркера.Два практических ограничения всплыли сразу: web_search и web_extract оказались выдуманными именами скиллов, а поле SKILLS нельзя править в интерфейсе задачи.

Hermes Agent у меня уже был установлен и проверен от начала до конца: версия v0.20.0, Node 22.11.0, npm 10.9.0, вход в Nous Portal, автозапуск через Task Scheduler. На бумаге следующий шаг выглядел просто: создать несколько специализированных профилей и раздать им роли. Но реальная боль начинается не в момент создания профиля. Она начинается, когда задач становится больше одной.

Нужно понимать, что произойдёт после нажатия «создать». Задача стартует сразу или останется ждать? Если в очереди пять карточек, они пойдут одна за другой или все одновременно? Надо ли вручную толкать диспетчер? Где хранится результат? Что случится с контекстом воркера после завершения?

В переписке я сформулировал это без аккуратной терминологии, но по сути точно:

«И если у меня несколько задач на целая оркестра, я готов к работе их накидывая, накидывая, накидываю, накидываю. А она будет первая ушла, я пока вторую заполняю, потом вторая ушла. Или как?»

Именно здесь Kanban перестаёт быть красивой доской со стикерами. В Hermes это операционный слой между человеком, очередью и специализированными агентами.

Карточка хранит не только формулировку задачи. Её статус определяет, может ли диспетчер забрать работу; назначенный воркер определяет, какой профиль её выполнит; зависимости не дают стартовать раньше времени; workspace фиксирует результат.

Главный вопрос для меня был не «сколько агентов можно создать», а «можно ли доказать один полный handoff без ручной имитации результата». Такой тест состоялся на задаче t_9a60e2a9.

До него архитектура была планом. После него появился работающий пайплайн с живым исследованием, сохранёнными файлами и переходом карточки в Done.

Что такое Hermes и зачем ему профили

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

Один агент — удобно.

Один чат — быстро.

Один контекст — понятно.

Но как только задач становится больше, всё начинает ехать.

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

В рамках этого проекта Hermes Agent используется как среда для работы с несколькими специализированными профилями на одном Windows-ПК.

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

Центральный профиль default, он же RZA, общается со мной, маршрутизирует работу и контролирует approvals. Остальные профили получают более узкую специализацию: исследование, программирование, настройка самого Hermes, редактура, аналитика соцсетей или Windows-инфраструктура.

Профиль здесь нужен не ради нового имени в интерфейсе. Он связывает конкретный тип задачи с заранее определённой ролью.

Если нужен глубокий поиск по вебу и документам, задача назначается @gza. Если нужен скрипт, исправление бага или code review, работа уходит @masta-killa. Финальную вычитку должен выполнять @ghostface. За счёт этого оркестратор не пытается одинаково делать всё подряд.

При этом проект изначально строился с ограничениями. Токены субагентам не передаются. Автоматизация включается только явно. Каждый новый handoff проверяется вручную.

В отчётах запрещены придуманные факты. Это не дополнительная бюрократия, а границы системы, которая уже умеет запускать задачи без постоянного клика человека.

В исходном ТЗ правило звучало прямо:

«Токены субагентам не отдаём, никаких выдумок в отчётах, без агрессивной автоматизации (только opt-in), multi-agent работа — opt-in (я сам тестирую каждый handoff)».

Архитектура поэтому расширяется не списком профилей, а доказанными передачами работы. В README проекта зафиксирована та же логика:

More agents does not make the system better. In most cases they just create more places where things can go wrong.Источник: Pavel, «Multi-Agent Hermes System», Teletype, 3 августа 2026 года

И второе правило, которое задаёт порядок развёртывания:

Start with an orchestrator, add one specialist, prove the handoff, and only then expand.Источник: @NeoAIForecast

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

Method Man и Raekwon остаются в плане до появления задач, которые действительно требуют отдельной специализации.

Архитектура: три уровня multi-agent в Hermes

В проекте используются три уровня мультиагентности. Они не конкурируют друг с другом. Каждый уровень отвечает за свой масштаб работы и степень автоматизации.

Уровень 1. Субагент через `delegate_task`

Subagent на первом уровне является одноразовым помощником. Оркестратор делегирует ему конкретную задачу через delegate_task, получает результат и продолжает основной диалог. Такой режим подходит, когда не нужен постоянный профиль с отдельной очередью: задача ограничена, контекст понятен, а результат должен вернуться в текущий рабочий поток.

Это самый короткий путь к делегированию. Он не требует построения отдельного Kanban-процесса. Но он же хуже подходит для набора задач с разными исполнителями, зависимостями и артефактами, которые должны пережить один диалог.

Уровень 2. Ручное переключение профилей

На втором уровне я сам выбираю профиль в Hermes Desktop. Например, переключаюсь на gza для исследования или на masta-killa для работы с кодом. Здесь специализация уже постоянная, но решение о запуске и переключении остаётся у человека.

Этот режим полезен при настройке нового профиля. Можно проверить его роль, инструкции и поведение без автоматического диспетчера. Именно такой подход соответствует правилу «сам тестирую каждый handoff». Сначала профиль должен показать ожидаемый результат в контролируемом сценарии, и только потом его имеет смысл подключать к очереди.

Уровень 3. Kanban-доска

Третий уровень добавляет автоматическую диспетчеризацию. Я создаю карточку, назначаю исполнителя, при необходимости задаю время старта или родительскую зависимость. Дальше диспетчер проверяет, готова ли задача, забирает её в очередь и запускает соответствующего воркера.

Здесь появляется важное разделение ответственности. Я определяю задачу, исполнителя, ограничения и момент запуска. Диспетчер отвечает за claim и движение статусов. Воркер выполняет работу и сохраняет результат. Доска показывает текущее состояние, но не заменяет сами файлы с результатом.

Три уровня дают практическую лестницу внедрения. Одноразовую работу можно передать через delegate_task. Новый профиль сначала проверить вручную. Повторяемые или зависимые задачи перевести на Kanban только после успешного handoff. Такая последовательность сохраняет управление у человека и не заставляет использовать автоматизацию там, где достаточно одного вызова.

6. Kanban: колонки, lifecycle, heartbeat, workspace и concurrency

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

Сортировка, или Triage

Triage хранит сырые идеи и неконкретные задачи. Карточку можно положить туда через +, но диспетчер её не забирает. Никакого автоматического запуска не происходит. Это входящий список, где мысль можно зафиксировать до появления нормального задания, исполнителя и условий готовности.

Практический смысл простой: идея не должна случайно превратиться в расход токенов или фоновую работу. Пока карточка лежит в Triage, она остаётся заметкой.

К выполнению, или Todo

Todo предназначен для задачи, которая уже сформулирована, но пока не может стартовать. Причина может быть одной из двух: исполнитель не назначен или родительская задача ещё не получила статус Done.

Когда блокировка исчезает, карточка может перейти в Ready. Этот статус особенно важен для цепочек. Например, подготовку промпта для статьи нельзя начинать до завершения исследования, если второй этап использует артефакты первого.

Запланировано, или Scheduled

Scheduled удерживает задачу до конкретного времени. В исходной переписке приведена команда hermes kanban schedule "..." --at 2026-08-05T09:00. Для повторяющейся задачи указан вариант с --repeat daily, а для утреннего запуска в 09:00 приведена комбинация --repeat daily --at 09:00.

Этот статус отвечает на вопрос «как создать карточку сейчас, но не запускать сразу». До времени X она просто ждёт. В назначенный момент её забирает диспетчер. Важно не путать Scheduled с Todo: первая карточка ждёт времени, вторая ждёт исполнителя или снятия зависимости.

Готово к работе, или Ready

Ready означает, что карточка полностью готова: исполнитель указан, блокировок нет. После создания через + диспетчер забирает её в очередь. Если нужно не ждать следующего цикла, в интерфейсе можно подтолкнуть диспетчер немедленным tick.

Ready не гарантирует одновременный старт всех карточек. Это допуск в очередь, а не команда открыть неограниченное число процессов.

В работе, или In Progress

In Progress означает, что диспетчер сделал claim задачи и воркер уже запущен. Статус обновляется автоматически. После завершения воркер переводит задачу в Done. Для немедленного визуального обновления доски можно нажать F5 или «Обновить».

Heartbeat в этом сценарии приходит примерно раз в 60 секунд. Он показывает, что воркер продолжает работать, а диспетчер может обновлять состояние карточки. Это также объясняет, почему интерфейс не всегда меняется в ту же миллисекунду, когда завершился внутренний шаг. Mavis описала это так:

«Сама. Worker шлёт heartbeat каждые ~60 сек, dispatcher обновляет статус. Жми F5 / „Обновить“, если хочется сразу увидеть».

Done и полный lifecycle

Успешный путь карточки выглядит так: Ready, claim диспетчером, In Progress, работа воркера, сохранение результата, Done. Возможны и другие входы. Сырая идея сначала живёт в Triage. Заблокированная задача ждёт в Todo. Задача по времени начинает путь из Scheduled.

Если речь идёт о контексте активного воркера, отдельной кнопки clear context у карточки нет.

По переписке контекст очищается после перехода в Done.

Для принудительного прекращения используется hermes kanban cancel <id>.

Это отличается от текущего чата Mavis, где чистый контекст создаётся через New chat или +.

Workspace и артефакты

Workspace нужен не для красивого статуса, а для файлов, которые останутся после выполнения. В реальном тесте memo было сохранено в D:\AI\hermes-kanban\kanban\attachments\t_9a60e2a9\memo.md.

Второй экземпляр появился в памяти профиля: C:\Users\vin-m\AppData\Local\hermes\profiles\gza\memories\tonbis-garage-hermes-agents.md.

Это важное разделение. Карточка отвечает на вопрос «что сейчас происходит», а файл отвечает на вопрос «что именно сделано». Summary в интерфейсе удобно читать, но исходный memo остаётся проверяемым артефактом для следующего агента или человека.

Concurrency и очередь

Concurrency задаёт, сколько дочерних задач могут выполняться одновременно. В текущей конфигурации по умолчанию это 2–3 параллельных воркера, параметр называется delegation.max_concurrent_children.

Если положить пять карточек в Ready, диспетчер запустит первые 2–3. Остальные останутся ждать свободного слота. Как только одна активная задача завершится, следующая сможет стартовать. Поэтому Ready можно наполнять заранее, не ожидая, что все карточки одновременно нагрузят систему.

Такой лимит делает поведение очереди предсказуемым. Он не определяет качество ответа и не отменяет зависимостей. Он только ограничивает число активных дочерних исполнителей.

Живой пример: `t_9a60e2a9`

Карточка t_9a60e2a9 была назначена профилю @gza и оказалась в In Progress. Задача состояла в исследовании материалов канала @TonbisAIGarage о Hermes Agent, multi-agent-системах и агентах.

Дальше пайплайн прошёл полный цикл. Диспетчер забрал карточку. Воркер @gza поднялся и выполнил исследование.

Через 11 минут задача получила статус completed. Результат сохранился в workspace и продублировался в memories профиля.

Summary воркера:

«Нашёл 19 релевантных видео на @TonbisAIGarage про Hermes Agent / multi-agent / агентов (период май–август 2026), для каждого дал тему, ключевую идею и релевантные таймкоды из описания. Memo на ~1.8K слов сохранено в workspace и продублировано в memories gza. Все 20 источников зарегистрированы в citations ledger и inline-процитированы (coverage 86%, citations OK)».

В этом примере важен не только объём результата.

Система вернула конкретные файлы, зарегистрировала 20 источников, добавила inline-цитирование и зафиксировала coverage 86%. Задача не зависла в In Progress и не потребовала ручного перевода в Done.

Это и стало end-to-end-подтверждением Kanban-пайплайна.

7. Wu-Tang-профили: роли без путаницы

Мастер-план включает семь профилей. На момент сессии пять из них уже созданы в Hermes, ещё два отложены до появления реальной повторяющейся работы.

RZA, профиль default: оркестратор, общение со мной, роутинг задач и approvals. Это центральная точка системы.
GZA, профиль gza: глубокие исследования по вебу и документам, литературные обзоры. Именно этот профиль выполнил t_9a60e2a9.
Masta Killa, профиль masta-killa: обычное программирование, скрипты, исправление багов и code review.
Inspectah Deck, профиль inspectah-deck: работа над самим Hermes, включая skills, profiles и prompts.
Ghostface, профиль ghostface: редактура и TRT, copy-edit и финальная вычитка материалов.
Method Man: аналитика X/Twitter и контент-стратегия. Профиль пока не развёрнут, он появится после реальной задачи соответствующего типа.
Raekwon: Windows-рантайм и инфраструктура, gateways, cron, tunnels и MCP. Этот профиль также оставлен на потом.

Фактический набор созданных профилей: default, gza, masta-killa, inspectah-deck, ghostface. Это важно проговорить отдельно, потому что архитектура на семь ролей и работающая система из пяти профилей являются разными состояниями проекта.

Порядок добавления тоже зафиксирован.

Сначала закрепляется RZA через SOUL.md и материалы команды. Затем добавляются GZA и Masta Killa.

После них подключаются Inspectah Deck и Ghostface. Method Man и Raekwon не создаются ради полноты списка. Для каждого нового профиля сначала нужна задача, затем проверяемый handoff.

8. Что пошло не так

Первый сбой был связан с названиями инструментов. В задачу попали web_search и web_extract, но таких скиллов в реестре не существовало. Воркер из-за этого падал дважды.

Проблема здесь не в веб-поиске как функции. Ошибка была в том, что имена инструментов выглядели правдоподобно и поэтому прошли без проверки. Для агентной системы это опасный класс ошибок: выдуманное имя похоже на настоящее, но runtime не может его вызвать.

Практический вывод из самой сессии: перед передачей задачи нужно проверять реестр доступных инструментов и использовать точные идентификаторы. Если точная CLI-команда или имя скилла в источнике не указаны, их нельзя дописывать «по смыслу».

Это напрямую связано с исходным ограничением проекта:

«Никаких выдумок в отчётах».

Второе ограничение обнаружилось в интерфейсе Kanban. Поле SKILLS у уже созданной задачи нельзя редактировать через UI.

Исправлять его нужно через CLI. В переписке точная команда для такого редактирования не приведена, поэтому здесь я её не выдумываю.

Оба случая показывают одно и то же: визуальная доска не отменяет проверки реального runtime. Название скилла должно существовать, а возможность редактирования поля должна быть подтверждена интерфейсом или CLI.

9. Что получилось

К концу этапа собрана рабочая база из пяти профилей: default, gza, masta-killa, inspectah-deck, ghostface.

Оркестратор RZA закреплён через SOUL.md, team-agents.md, MEMORY.md и USER.md.

Kanban использует базу D:\AI\hermes-kanban\kanban.db. Gateway автоматически запускается при входе в Windows через fallback в папке Startup.

Локальный дашборд доступен по адресу http://localhost:9119.

Проверены два сценария.

Сначала gza прошёл smoke-тест на исследовательской задаче по Teletype multi-agent. Затем реальная карточка t_9a60e2a9 проанализировала материалы @TonbisAIGarage и вернула memo примерно на 1,8 тысячи слов.

Главный результат этапа: появился не просто набор профилей, а доказанный путь задачи. Карточка попала в Ready, диспетчер сделал claim, воркер выполнил исследование, материалы сохранились в attachments и memories, после чего задача завершилась. Артефакты можно открыть, проверить и передать следующему исполнителю.

10. Следующие шаги

Следующий этап строится как цепочка зависимостей.

Вторую задачу должен выполнить masta-killa; её parent равен t_9a60e2a9. Результатом должен стать промпт для Notion на основе завершённого исследования. Третья задача предназначена ghostface, её parent будет указывать на второй этап. Она отвечает за редактуру финального драфта.

Отдельно остаётся технический шаг: добавить VBS-скрипт в Startup для автозапуска дашборда.

Method Man и Raekwon будут добавлены позже. Условие уже определено: должна появиться реальная повторяющаяся задача по X/Twitter или по Windows-инфраструктуре. До этого создавать два дополнительных профиля смысла нет, потому что их handoff невозможно проверить на настоящем рабочем материале.

11. Заключение

Kanban в Hermes решил конкретную операционную проблему: отделил идеи от готовых задач, блокировки от расписания, очередь от активной работы, а статус карточки от сохранённого результата. Проверка t_9a60e2a9 показала полный маршрут на живом исследовании, а не на демонстрационной заглушке.

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

CTA: если строишь свою систему на Hermes, возьми одну реальную задачу, назначь одного специалиста и проверь четыре вещи: переход в Done, сохранённый артефакт, корректные источники и передачу результата следующему профилю.

12. Приложение: словарь и ссылки

Короткий словарь

Assignee: профиль, назначенный исполнителем карточки.
Parent: родительская задача. Пока она не завершена, зависимая карточка остаётся заблокированной.
Claim: момент, когда диспетчер забирает готовую карточку и закрепляет её за воркером.
Dispatcher: компонент, который отслеживает готовые карточки, очередь, расписание и доступные слоты параллельного выполнения.
Worker: запущенный исполнитель задачи, связанный с назначенным профилем.
Heartbeat: периодический сигнал активного воркера. В описанном сценарии он отправляется примерно раз в 60 секунд.
Workspace: место, где сохраняются файлы и другие артефакты задачи.
Citations ledger: реестр источников, использованных в исследовании. Для t_9a60e2a9 зарегистрировано 20 источников.
Smoke-тест: короткая проверка, что основной маршрут вообще работает до запуска полноценной задачи.
Triage / Todo / Scheduled / Ready / In Progress / Done: сырая идея, заблокированная задача, задача по времени, готовая очередь, активная работа и завершение.

Команды и адреса из переписки

Запланировать запуск: hermes kanban schedule "..." --at 2026-08-05T09:00.
Указать ежедневное повторение: --repeat daily.
Остановить задачу: hermes kanban cancel <id>.
Параметр параллельности: delegation.max_concurrent_children.
Локальный дашборд: http://localhost:9119.
База Kanban: D:\AI\hermes-kanban\kanban.db.
Артефакт задачи: D:\AI\hermes-kanban\kanban\attachments\t_9a60e2a9\memo.md.
Память GZA: C:\Users\vin-m\AppData\Local\hermes\profiles\gza\memories\tonbis-garage-hermes-agents.md.

Публичные ссылки

Telegram-канал Павла: @Novopoltsev_Pavel.
Блог Павла на Teletype: teletype.in/@rovniy_paha.

У вашего ИИ-агента деменция. Сделайте ему мозги.

2026-08-03T14:24:39.261Z

Архитектурные решения, тупиковые варианты, которые мы исключили, причины, по которым мы выбрали именно эту библиотеку.

Все это исчезло. Все. Мне пришлось перечитать проект с нуля, заново объяснить цель и пройтись по ограничениям, которые не позволили реализовать предыдущий подход.Это не редкость.

Это стандарт.

Каждый сеанс работы с ИИ начинается с нуля.

Первые двадцать минут вы тратите на то, чтобы восстановить контекст, загрузить файлы, объяснить, почему вы не используете очевидное решение.

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

Я пробовал обходные пути: гигантские системные подсказки, которые игнорируются на полпути, файлы в формате Markdown, которые я каждый раз вставляю в чат, плагины для памяти, которые сохраняют фрагменты, но не учитывают структуру.

Ничего не работает, потому что ничего не рассчитано на команду агентов, которые работают дольше, чем любой отдельный диалог.

Это проблема не инструментов.

Это проблема институциональной памяти.

И решение заключается не в улучшении подсказок.

Это общий «мозг», который агенты могут читать и редактировать между сессиями.

Андрей Карпати (@karpathy) опубликовал шаблон для решения этой проблемы в апреле 2026 года. Я пошел дальше.

Вот как это выглядит после шести недель работы.

Андрей Карпати@karpathy·3 апрБазы знаний LLM В последнее время я нахожу это очень полезным: использование LLMS для создания личных баз знаний по различным темам, представляющим исследовательский интерес. Таким образом, значительная часть моей недавней пропускной способности токенов уходит не столько на манипулирование кодом, сколько на манипулирование знаниями (хранящимися в виде markdown и изображений). Последние LLM довольно хороши в этом. Итак: прием данных: я индексирую исходные документы (статьи, научные работы, репозитории, наборы данных, изображения и т. д.) в каталоге raw/, а затем использую большую языковую модель для постепенной «компиляции» вики, которая представляет собой просто набор файлов .md в структуре каталогов. Вики включает в себя краткие описания всех данных в raw/, обратные ссылки, а также распределяет данные по категориям, пишет статьи и связывает их между собой. Чтобы преобразовать веб-статьи в файлы .md, я использую расширение Obsidian Web Clipper, а также горячую клавишу для загрузки всех связанных изображений на локальный диск, чтобы моя языковая модель могла легко на них ссылаться. IDE: Я использую Obsidian в качестве «фронтенда» IDE, где я могу просматривать исходные данные, скомпилированную вики и полученные визуализации. Важно отметить, что LLM пишет и поддерживает все данные вики, я редко вмешиваюсь в этот процесс. Я поэкспериментировал с несколькими плагинами для Obsidian, чтобы отображать и просматривать данные другими способами (например, Marp для слайдов). Вопросы и ответы: самое интересное начинается, когда ваша вики становится достаточно большой (например, моя вики по некоторым недавним исследованиям содержит около 100 статей и примерно 400 тысяч слов). Тогда вы можете задавать своему LLM-агенту всевозможные сложные вопросы, связанные с вики, и он будет искать ответы и т. д. Я думал, что мне придется прибегнуть к помощи RAG, но LLM неплохо справляется с автоматическим ведением индексных файлов и кратких описаний всех документов, а также довольно легко считывает все важные сопутствующие данные в таком ~небольшом масштабе. Результат: Вместо того чтобы получать ответы в текстовом формате или в терминале, я предпочитаю, чтобы программа генерировала для меня файлы в формате Markdown, слайд-шоу (формат Marp) или изображения в формате matplotlib, которые я затем снова просматриваю в Obsidian. В зависимости от запроса можно представить множество других визуальных форматов вывода. Часто я «записываю» результаты обратно в вики, чтобы использовать их для дальнейших запросов. Таким образом, мои собственные исследования и запросы всегда «вписываются» в базу знаний. Линтинг: я провел несколько "проверок работоспособности" LLM в wiki, например, чтобы найти противоречивые данные, приписать недостающие данные (с помощью веб-поиска), найти интересные связи для новых кандидатов в статьи и т.д., Чтобы постепенно очистить wiki и повысить ее общую целостность данных. Магистры права довольно хорошо умеют предлагать дополнительные вопросы, которые можно задать и изучить. Дополнительные инструменты: Я разрабатываю дополнительные инструменты для обработки данных. Например, я написал небольшую и простую поисковую систему на основе вики, которую использую как напрямую (в веб-интерфейсе), так и в качестве инструмента для более масштабных запросов, передавая ее в LLM через интерфейс командной строки. Дальнейшие исследования: По мере роста репозитория возникает естественное желание задуматься о создании синтетических данных и тонкой настройке, чтобы ваша LLM «знала» данные на уровне весовых коэффициентов, а не только на уровне контекстных окон. TLDR: собираются необработанные данные из заданного количества источников, затем LLM компилирует их в .md wiki, затем LLM обрабатывает различные CLI для вопросов и ответов и постепенного улучшения wiki, и все это доступно для просмотра в Obsidian. Вы редко пишете или редактируете wiki вручную, это прерогатива магистра права. Я думаю, здесь есть место для невероятного нового продукта, а не для набора взломанных скриптов.

Карпати был прав

Пост Карпати в LLM Wiki не зря стал вирусным. Его идея была предельно проста, почти слишком проста, чтобы быть революционной: не заставляйте большие языковые модели заново открывать знания по каждому запросу. Достаточно один раз скомпилировать их в постоянную вики и поддерживать ее актуальность.

Вот в чем разница.

Традиционная RAG обращается с вашими документами как с библиотекой. Каждый вопрос — это новое обращение к архивам. Система извлекает фрагменты, заново собирает контекст и отвечает с нуля. Она не сохраняет состояние. Она не обучается.

Скомпилированная вики — это живой документ. Она обновляется при изменении источников. Она поддерживает перекрестные ссылки. Она знает то, что знала вчера, и опирается на это знание сегодня.

RAG заново обрабатывает каждый запрос. Поддерживается скомпилированная вики.

Оригинальная архитектура Карпати состоит из трех уровней: исходные данные как неизменяемые входные параметры, вики как синтезированные знания и SCHEMA.md как конституция, обеспечивающая согласованность всего. Он разработал ее для одного человека и одной большой языковой модели. Но на этом возможности заканчиваются. Я ежедневно запускаю четырех агентов. Мне нужно было хранилище, которое они все могли бы читать, в которое все могли бы вносить данные и которое все могли бы поддерживать, не мешая друг другу. Мне нужна была многоагентная подложка для хранения данных, а не личный блокнот.

Что я создал: Nexus

Nexus — это подложка для хранения данных с общим доступом. Файловая система — это источник достоверных данных. Каждый агент считывает данные из нее, записывает в нее и регистрирует свои действия.

Три уровня, та же основополагающая идея, что и у Карпати:

raw/ — неизменяемый исходный материал

raw/ содержит неизменяемые источники: научные статьи, заметки о встречах, фрагменты кода, парсинговые статьи, расшифровки, скриншоты.

После загрузки они не меняются. Вики может ссылаться на них, обобщать их, опровергать их, но не перезаписывать.

Это базовый уровень достоверности. Если вы когда-нибудь зададитесь вопросом: «Откуда взялось это утверждение?», ответ всегда будет в raw/ с указанием времени и источника.

wiki/ — синтезированные знания

wiki/ — это место, где хранится синтез. Это страницы, поддерживаемые агентом, с полным набором данных: название, дата создания, дата обновления, тип, статус, теги, источники, агент и краткое описание.

Каждая страница содержит ссылки как минимум на две другие.

Страницы-сироты помечаются автоматически. Один источник может инициировать обновления на пяти-пятнадцати страницах вики. На графике показаны узлы и страницы-сироты, так что вы можете видеть, что хорошо связано с другими страницами, а чему нужно больше ссылок.

ops/ + mocs/ — операционный уровень

ops/ плюс mocs/ — это операционный уровень: стандартные операционные процедуры, многократно используемые шаблоны подсказок, разветвленные рабочие процессы, файлы инструкций для агентов и информационные панели для пользователей.

Именно на этом уровне хранилище становится операционной системой, а не картотекой.

Здесь находится сценарий утреннего брифинга. Здесь находится стандарт операционной процедуры для очереди контента. Здесь находятся правила доступа для агентов.

Три уровня доступа: базовый, вики, ops+mocs, со значками доступа для агентов.

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

За шесть недель в Nexus появилось 61 вики-страница, рост на 56 % за 20 дней, ежедневные утренние брифинги, которые генерируются автоматически до моего пробуждения, и четыре активных агента с четко определенными ролями и обязанностями.

С середины апреля три проекта были отправлены напрямую из контекста хранилища: agentdocs с двумя промежermes Vault v0.2.0 со 163 тестами и готовностью к MCP; а также обновленная главная страница.

Хранилище не просто хранит знания. Оно работает как сердце.

Ежедневный операционный цикл

Каждый день в 5:30 утра Hermes проводит брифинг.

Он читает журнал, проверяет папку с планами, сканирует записи в журнале и формирует сводку о том, что произошло вчера и что предстоит сделать сегодня.

Затем я просматриваю ее, составляю утренний план и приступаю к работе.

В течение дня каждое действие агента записывается в файл log.md с указанием времени, имени агента и информации о том, что изменилось.

Вечером Hermes выполняет команду closeout: day dump, journal entry, and tomorrow's objectives.

Агенты не разговаривают друг с другом.

Они разговаривают с журналом.

Ежедневный ритм: брифинг → план → выполнение → завершение → повторить

Это ключевая идея, которую упускают большинство мультиагентных систем. Вам не нужна шина сообщений. Вам не нужна сложная оркестровка. Вам нужна запись, доступная только для добавления, которую каждый агент считывает перед выполнением действия. Когда Claude Code начинает сеанс, он проверяет хранилище. Когда Hermes распределяет задачу, контекст уже готов. До появления этой системы я сам был распределителем. Я решал, что какому инструменту передать. Я держал состояние в голове. Теперь распределением занимается Hermes. Я проверяю и корректирую. Трудно переоценить смещение когнитивной нагрузки.

Who Gets to Touch What

Четыре агента, пять зон, одно правило: каждый агент читает SCHEMA.md, прежде чем что-либо написать.

Hermes — это организатор. В его ведении находятся планирование, делегирование, синтез, обслуживание хранилища и финальный контроль качества. Он может создавать одноразовые субагенты для параллельной работы и несет ответственность за их результаты.

Claude Code отвечает за вики-страницы проекта. Он получает полный доступ к исходным данным и ограниченный доступ на запись к вики-страницам проекта, над которым работает.

Codex отвечает за обобщение результатов исследований. Он в основном выполняет функции чтения, а целевые записи выполняет в ops/prompts/ и wiki/queries/. Он не затрагивает процедуры и информационные панели.

Antigravity доступен только для чтения, за исключением инкубационных идей, которые он добавляет в wiki/incubations/. Это уровень сбора идей.

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

Если что-то идет не так, я просматриваю журнал по датам и вижу, кто и что сделал. Подотчетность встроена в структуру.

Секретный ингредиент — проактивность

Вот тот аспект, о котором никто не говорит.Шаблон Карпати — это хранилище, которое вы открываете, когда вам что-то нужно.Nexus — это хранилище, которое действует до того, как вы попросите.

Две системы объединения работают вместе. Это не дополнительные опции. Именно благодаря им все это работает.

Самосовершенствование: прошлое → будущее

Система самосовершенствования запоминает, что сработало, что нет и что я исправил. Она повышает качество выполнения задач в разных сессиях.

Claude Code лучше справляется с моей кодовой базой, потому что учитывает опыт предыдущих сессий. Hermes лучше справляется с маршрутизацией, потому что учитывает, какие шаблоны делегирования сработали, а какие отняли время впустую.

Когда я говорю агенту: «Это неправильно, сделай вот так», это исправление записывается, и его видит каждая последующая сессия.

Проактивность: настоящее → будущее

Проактивность отслеживает активные цели, препятствия и дальнейшие шаги. Именно так Hermes подталкивает меня, а не просто отвечает.

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

Он отслеживает состояние и действует при его изменении, а не тогда, когда я задаю вопрос.

Есть четкая граница: проактивность никогда не отправляет сообщения, не берет на себя обязательства и не предпринимает необратимых внешних действий без явного одобрения. Она проявляется. Она подталкивает. Она не действует.

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

Хранилище — это не продукт.

Рабочий ритм — это и есть продукт.

На создание структуры папок уходит целый день. Чтобы ежедневный цикл стал автоматическим, нужен месяц. Чтобы накопительный эффект стал очевидным, нужно шесть месяцев. Но как только он заработает, вы уже не сможете вернуться к модели «собака, которая забыла свое имя».

Как создать свой собственный

Не создавайте все сразу. Сначала настройте работу с исходными данными и вики. Добавляйте операции по мере обнаружения повторяющихся процедур.

Добавляйте агентов по мере необходимости для рабочих процессов.

Шаг 1. Инициализация Git в каталоге хранилища

Отслеживайте все. Без исключений.

Шаг 2. Создайте структуру папок

Начните с:

raw/ wiki/ ops/ mocs/ briefings/ plans/ logs/

Шаг 3. Напишите файл SCHEMA.md

Это ваша конституция. Определите поля преамбулы, правила вики-ссылок и таксономию тегов. Цель: файл должен быть читаем за тридцать секунд.

Шаг 4. Напишите index.md и log.md

index.md — это ваш каталог контента. log.md — это журнал действий, в который можно добавлять только записи. Эти два файла — основа всего.

Шаг 5. Напишите правила для агентов в .agents/

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

Любой может создать папки с файлами в формате Markdown. Структура — это не самое сложное. Самое сложное — выработать привычку ее использовать.

Начните с шаблона Карпати. Добавьте ежедневный цикл. Добавьте уровень мультиагентности. Дайте ей разрастись. Не пытайтесь создать полноценную систему в первый же день. Сначала соберите контур.

Завершающий удар

Сложный процент — это не выдумка. Через несколько недель постоянного использования я перестал думать о хранилище как об отдельной системе и стал воспринимать его как то, как команда запоминает информацию. Вопрос «где хранится эта информация?» перестал быть неловким, потому что ответ всегда один и тот же.

Через полгода ваше хранилище будет выглядеть примитивным по сравнению с тем, что есть сейчас. В этом и смысл. Вы создаете нечто, что совершенствуется по мере использования.

Вы создаете не приложение для ведения заметок. Вы создаете инфраструктуру для команды, в которую входят как люди, так и роботы.

Начните с малого. Будьте последовательны.

Позвольте системе развиваться. 🤘

Многоагентная система Hermes.

2026-08-03T13:43:10.575Z

Сейчас все хотят многоагентную систему.

-Исследователь.

-Программист.

-Писатель.

-Рецензент.

-Браузерный агент.

-Менеджер проекта.

-Может быть, несколько субагентов для подстраховки.

Звучит чертовски круто, пока вы не попробуете запустить его.

Тогда вы поймете, что по сути создали ИИ-офис, где у всех одинаковые ключи, никто не знает, кому принадлежит задача, три агента работают с одним и тем же файлом, а «менеджер» все равно делает всю работу.

Hermes Agent на основе полноценной многопрофильной архитектуры.

Семь постоянных профилей.

Сотни тщательно отобранных навыков.

Строгие требования к учетным данным.

Изолированная память.

Один командный профиль.

Одноразовые субагенты.

Общая документация.

Автоматическая проверка.

Инструменты для восстановления.

Полная производственная база.

Это самое интересное.

Настоящая история — это то, что перестройка системы показала мне о мультиагентных системах в целом.

Потому что вот в чем правда:Чем больше агентов, тем лучше система не становится.

В большинстве случаев они просто создают больше мест, где что-то может пойти не так.

Большинство «мультиагентных систем» это просто продвинутые групповые чаты

Многое из того, что сегодня называют мультиагентными системами, — это, по сути, ролевая игра с дополнительными этапами.

Одна модель ведет себя как исследователь.

Другая — как программист.

Третья — как критик.

Они обмениваются результатами.

В конце концов кто-то говорит, что задача выполнена.

Это может быть полезно.

Но это не то же самое, что ежедневное использование настоящей многоагентной системы.

В реальной системе приходится отвечать на гораздо более сложные вопросы.

-Кто отвечает за каждый тип работы?

-У кого есть доступ к учетным данным?

-Кому разрешено взаимодействовать с внешним миром?

-Кому принадлежит память?

-Кто может публиковать данные?

-Кто может менять инфраструктуру?

-Что происходит, когда два агента считают, что задача принадлежит им обоим?

-Что делать, если старая документация по-прежнему перенаправляет работу на агента, которого вы удалили три недели назад?

-Что происходит после того, как обновление меняет среду выполнения?

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

В этом и заключается разница.

Демонстрация доказывает, что несколько агентов могут взаимодействовать.

Реальная система доказывает, что они могут работать вместе, не превращая вашу машину в клоунскую тачку с искусственным интеллектом.

На самом деле существует три разных типа многоагентных систем

Люди склонны объединять все в одну категорию под названием «мультиагентность», но существует несколько совершенно разных способов ее реализации.И именно из-за выбора неправильного способа возникает множество проблем.

1. Одноразовые субагенты

Это самая простая модель.

У вас есть один главный агент. Этот агент создает временных помощников для таких задач, как:

исследование
тестирование
мозговой штурм
проверка
критика
поиск пограничных случаев

Затем эти помощники исчезают, когда задача выполнена.

Это идеальный вариант, когда работа носит временный характер.

Например, один агент изучает документацию.

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

Третий просматривает план и пытается его разобрать.

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

Все просто.

Чистота.

Никакого багажа в прошлом.

Именно здесь люди совершают свою первую большую ошибку.

Они превращают каждую временную роль в постоянную.

Теперь у критика есть собственная память.

Собственная конфигурация.

Собственный рабочий каталог.

Собственные навыки.

Собственные запланированные задачи.

Собственное маленькое королевство.

Но зачем?

Иногда критик — это просто повод.

Не каждая полезная роль заслуживает постоянного присутствия на вашем компьютере.

2. Постоянные профили специалистов

A постоянный профиль имеет смысл, если у роли есть реальная, устойчивая сфера деятельности. Это означает, что ей могут потребоваться:

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

Вот как я настроил свой текущий аккаунт в Hermes.

Постоянные профили:

Благодаря названиям мне проще запоминать систему.

Но названия — это не архитектура.

Архитектура — это владение.Каждый профиль существует, потому что у него есть четкая ниша, которая востребована снова и снова.

Вот такая планка.

Не «это была бы крутая личность».

Не «когда-нибудь мне это может пригодиться».

Не «больше агентов выглядит впечатляюще на скриншоте».

Постоянный профиль должен содержать что-то реальное.

3. Рои

Тогда у вас есть рой.Здесь множество агентов ведут переговоры, голосуют, соревнуются, спорят, самоорганизуются или бросают идеи в гигантскую цифровую «битву за еду», пока не выпадет что-то полезное.Рои отлично подходят для:

моделирования
широких исследований
научных изысканий
генерации гипотез
состязательного тестирования
проблемы с поиском
большие наборы независимых задач

Кроме того, их очень легко перестроить.

Проблемы проявляются быстро:

агенты дублируют работу
никто не отвечает за результат
затраты становятся непредсказуемыми
маршрут меняется от запуска к запуску
контекст становится размытым
внутренняя переписка разрастается
агенты начинают соглашаться друг с другом, ничего не проверяя

В итоге может оказаться, что на общение агентов между собой тратится больше вычислительных ресурсов, чем на полезную работу.

Для большинства персональных систем, рабочих процессов с контентом, программных проектов и бизнес-операций рой, скорее всего, не нужен.

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

Оркестратор — самый важный агент в системе

Большинство людей тратят все свое время на разработку специализированных подсказокОни зацикливаются на исследователе.

-Инженере.

-Писателе.

-Рецензенте.

Но почти не думают об организаторе.

Это неправильно.

От организатора зависит, будет ли ваша команда работать как единое целое или превратится в сборище ботов с бейджами.В моей системе эта роль принадлежит RZA.

RZA отвечает за:

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

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

Хороший координатор не свалит на вас пять отчетов агентов и не уйдет.

Так вы просто станете менеджером проекта.

Специалист отвечает за свою область.

Ответственность за результат лежит на организаторе.

Это принципиальное различие.

Ваш организатор не должен втайне представлять всю компанию

Я столкнулся с еще одной проблемой.

Можно создать шесть профилей специалистов, дать им всем четкие задачи, задокументировать маршрутизацию, но в итоге получить фиктивную мультиагентную систему.

Почему?

Потому что главный агент уже может делать все.У него есть все навыки.

Все инструменты.

Все учетные данные.

Все интеграции.

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

Теперь у вас установлено семь агентов, но всем заправляет один гигантский монолит.

Это сводит на нет весь смысл.В RZA есть четкие правила маршрутизации.

Глубокие исследования — это к GZA.Обычное программирование — к Masta Killa.

Официальная работа Hermes Agent — Inspectah Deck. Редактура TRT — Ghostface. X-аналитика и контент-стратегия — Method Man.

Среда выполнения Windows, шлюзы, cron, туннели и MCP — Raekwon.RZA по-прежнему может выполнять небольшие задачи напрямую.

Не нужно созывать комитет только потому, что кто-то попросил вас переименовать файл.

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

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

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

Наделять каждого агента всеми навыками ужасная идея

На первый взгляд звучит умно.

Почему бы не предоставить каждому профилю доступ ко всем навыкам?

Тогда никто ничего не упустит.

Проблема решена.Вот только теперь у каждого профиля есть огромный набор навыков, полный повторяющихся инструкций, ненужных рабочих процессов, дублирующих друг друга инструментов и противоречивых рекомендаций.

Это приводит к:

более медленному поиску
большим подсказкам
худшей маршрутизации
больше путаницы
более тщательный аудит
больше случаев случайного использования инструментов
больше затрат на обслуживание

Более эффективный подход — курирование.

У каждого специалиста должны быть навыки, соответствующие его специализации.

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

Masta Killa отвечает за отладку, тестирование, архитектуру, GitHub, релизы и инженерные процессы.

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

Method Man отвечает за X-аналитику, написание постов, проверку утверждений, перепрофилирование, эксперименты и контент-стратегию.

Raekwon отвечает за службы Windows, шлюзы, туннели, cron, MCP, миграцию, восстановление и инструменты для работы с инфраструктурой.

Один из аудитов показал, что для этих профилей требуется огромное количество навыков.

Позже мы выяснили, что эти цифры были завышены.

Реальные наборы навыков были меньше.

И, честно говоря?

Так было лучше.

Количество навыков — это не показатель возможностей.

Агент со 150 навыками, имеющими отдаленное отношение к делу, может быть хуже, чем агент с 25 навыками, которые действительно нужны.

Больше — не всегда лучше.

Иногда «больше» — это просто ящик для мусора.

Подтвержденные данные должны быть в приоритете

Это было одно из самых важных архитектурных решений, которые я принял.

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

В моей конфигурации:

RZA владеет Telegram
RZA владеет Discord
RZA владеет Composio
специалисты не наследуют серверы MCP
специалисты не хранят учетные данные для обмена сообщениями
специалисты не владеют публичными шлюзами

Это значит, что Ghostface может написать статью.

Method Man может подготовить пост X.

Raekwon может проверить шлюз.

Но они не могут самостоятельно публиковать, отправлять или подключаться к внешним сервисам.

Их работа возвращается в RZA.

RZA занимается утверждением.

Так и должна работать привилегия.

Работа идет сверху вниз.

Учетные данные не передаются снизу вверх.

Это создает небольшие трудности.

Ничего страшного.

Небольшие видимые трудности лучше, чем невидимое распределение власти между семью профилями.

Наследование MCP может незаметно разрушить вашу модель безопасности

MCP обладает невероятной мощью.Кроме того, это один из самых быстрых способов случайного повышения привилегий.

Одно OAuth-соединение может предоставлять доступ к нескольким приложениям.

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

Если каждый субагент наследует все инструменты MCP от родительского агента, то одно невинное делегирование может внезапно предоставить временному помощнику доступ к Gmail, WordPress, Cloudflare, GitHub, аналитике и ко всему остальному, что вы подключили. Это не мелочь.

Это ваша модель безопасности.

В моей системе:

delegation.inherit_mcp_toolsets = false

Субагенты не наследуют интеграции автоматически.

Постоянные специалисты не используют конфигурацию Composio.

RZA остается контролируемым шлюзом.

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

Хорошо.

Это обеспечивает четкую передачу полномочий.

Система должна запросить разрешение у профиля, обладающего соответствующими полномочиями.

Это не ограничение.

Это рабочая граница.

Память должна быть изолирована, но истина должна быть общей

Исследователь не должен перенимать все привычки автора постов в социальных сетях.Профиль инфраструктуры не должен содержать редакторских допущений.

Профиль программиста, работающего над одним репозиторием, не должен случайно запоминать правила проекта из другого.

Постоянным профилям нужна изолированная память.

Это помогает им сохранять концентрацию.

Но изолированная память создает другую проблему.

Как сделать так, чтобы все были в курсе происходящего?

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

Это быстро приводит к хаосу.

Решением стал Nexus.Nexus — это надежный уровень общих знаний.Он содержит:

определения ролей
правила маршрутизации
состояние проекта
решения
передача дел
рабочие процедуры
базовые показатели
инструкции по восстановлению
исторические записи
метаданные о владельце

Память остается локальной.

У вашего ИИ-агента деменция.

Я создал ему мозг.

На прошлой неделе я попросил Claude Code продолжить работу над моим проектом. Он посмотрел на меня, как собака, которая забыла собственное имя.

Я не имею в виду, что он дал расплывчатый ответ.

Я имею в виду, что он совершенно не помнил о двухчасовом сеансе, который мы провели накануне вечером.

Об архитектурных решениях, тупиковых вариантах, которые мы исключили, о причинах, по которым мы выбрали именно эту библиотеку.

Исчезло. Все.

Мне пришлось перечитать проект с нуля, заново объяснить цель и пройтись по ограничениям, которые не позволили реализовать предыдущий подход.

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

Каждый сеанс работы с ИИ начинается с нуля.

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

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

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

Это проблема не инструментов.

Это проблема институциональной памяти.

И решение не в том, чтобы лучше формулировать запросы.

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

Андрей Карпати (@karpathy) опубликовал шаблон для этого в апреле 2026 года. Я развил его идею. Вот как это выглядит в течение шести недель.

Андрей Карпати@karpathy·3 апрБазы знаний LLM В последнее время я нахожу это очень полезным: использование LLMS для создания личных баз знаний по различным темам, представляющим исследовательский интерес. Таким образом, значительная часть моей недавней пропускной способности токенов уходит не столько на манипулирование кодом, сколько на манипулирование знаниями (хранящимися в виде markdown и изображений). Последние LLM довольно хороши в этом. Итак: прием данных: я индексирую исходные документы (статьи, научные работы, репозитории, наборы данных, изображения и т. д.) в каталоге raw/, а затем использую большую языковую модель для постепенной «компиляции» вики, которая представляет собой просто набор файлов .md в структуре каталогов. Вики включает в себя краткие описания всех данных в raw/, обратные ссылки, а также распределяет данные по категориям, пишет статьи и связывает их между собой. Чтобы преобразовать веб-статьи в файлы .md, я использую расширение Obsidian Web Clipper, а также горячую клавишу для загрузки всех связанных изображений на локальный диск, чтобы моя языковая модель могла легко на них ссылаться. IDE: Я использую Obsidian в качестве «фронтенда» IDE, где я могу просматривать исходные данные, скомпилированную вики и полученные визуализации. Важно отметить, что LLM пишет и поддерживает все данные вики, я редко вмешиваюсь в этот процесс. Я поэкспериментировал с несколькими плагинами для Obsidian, чтобы отображать и просматривать данные другими способами (например, Marp для слайдов). Вопросы и ответы: самое интересное начинается, когда ваша вики становится достаточно большой (например, моя вики по некоторым недавним исследованиям содержит около 100 статей и примерно 400 тысяч слов). Тогда вы можете задавать своему LLM-агенту всевозможные сложные вопросы, связанные с вики, и он будет искать ответы и т. д. Я думал, что мне придется прибегнуть к помощи RAG, но LLM неплохо справляется с автоматическим ведением индексных файлов и кратких описаний всех документов, а также довольно легко считывает все важные сопутствующие данные в таком ~небольшом масштабе. Результат: Вместо того чтобы получать ответы в текстовом формате или в терминале, я предпочитаю, чтобы программа генерировала для меня файлы в формате Markdown, слайд-шоу (формат Marp) или изображения в формате matplotlib, которые я затем снова просматриваю в Obsidian. В зависимости от запроса можно представить множество других визуальных форматов вывода. Часто я «сохраняю» результаты в вики, чтобы использовать их для дальнейших запросов. Таким образом, мои собственные исследования и запросы всегда «вписываются» в базу знаний. Линтинг: я провел несколько "проверок работоспособности" LLM в wiki, например, чтобы найти противоречивые данные, приписать недостающие данные (с помощью веб-поиска), найти интересные связи для новых кандидатов в статьи и т.д., Чтобы постепенно очистить wiki и повысить ее общую целостность данных. Магистры права довольно хорошо умеют предлагать дополнительные вопросы, которые можно задать и изучить. Дополнительные инструменты: Я разрабатываю дополнительные инструменты для обработки данных. Например, я написал небольшую и простую поисковую систему на основе вики, которую использую как напрямую (в веб-интерфейсе), так и в качестве инструмента для более масштабных запросов, передавая ее в LLM через интерфейс командной строки. Дальнейшие исследования: По мере роста репозитория возникает естественное желание задуматься о создании синтетических данных и тонкой настройке, чтобы ваша LLM «знала» данные на уровне весовых коэффициентов, а не только в рамках контекстных окон. TLDR: собираются необработанные данные из заданного количества источников, затем LLM компилирует их в .md wiki, затем LLM обрабатывает различные CLI для вопросов и ответов и постепенного улучшения wiki, и все это доступно для просмотра в Obsidian. Вы редко пишете или редактируете wiki вручную, это прерогатива магистра права. Я думаю, здесь есть место для невероятного нового продукта, а не для набора взломанных скриптов.

Пост про память

Nexus хранит общую истину.Это позволяет каждому агенту иметь свою индивидуальность, не превращая систему в семь изолированных «мозгов», которые никогда не придут к единому мнению о том, что происходит.

Документация — это уже не просто документация

Это стало одним из самых больших сюрпризов в ходе аудита.

Профили в реальном времени в основном были корректными.

А вот документация — нет.

На старых страницах Nexus по-прежнему ссылались на удаленные профили.Некоторые редакционные правки по-прежнему выполнялись через профиль по умолчанию.

Другие страницы указывали на идентификаторы профилей, которых больше не существовало.

Это не безобидно.Агенты читают документацию.

Если в документах указано, что вышедший на пенсию агент чем-то владеет, система все равно может попытаться направить туда работу.

В агентской настройке документация является частью среды выполнения.

При изменении имени папки переименование профиля не выполняется.

Также необходимо проверить:

конфигурацию
маршрутизацию
навыки
учетные данные
запланированные задачи
память
метаданные владения
документация
исторические названия

Мы сохранили старые названия там, где они исторически верны.

Но документы по активному управлению были обновлены с использованием актуальной архитектуры Wu-Tang.

В истории можно найти упоминания о призраках.

Ваш уровень маршрутизации не может обеспечить их работу.

Проблемы обычно возникают в скучной инфраструктуре

Все хотят поговорить о моделях, подсказках, агентах и логических выводах.Тем временем сама система держится на:

запланированных задачах
скриптах PowerShell
фоновых демонах
портах
деревьях процессов
файлах блокировки
переменные среды
обертки для запуска
рабочие каталоги

Одна из обнаруженных нами проблем была связана с драйвером использования компьютера.

Были установлены две версии:

0.11.0 0.12.3

Запланированная задача по-прежнему указывала непосредственно на старый бинарный файл версии 0.11.0.

Поэтому была установлена новая версия.

Но Windows продолжала запускать старую.

Это тот вид ошибок, который может пережить десяток поверхностных проверок работоспособности.

Исправление заключалось в использовании скрипта-оболочки.

Теперь запланированная задача запускается:

C:\Users\asimo\.cua-driver\start-cua-driver.ps1

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

Таким образом, для будущих обновлений не потребуется каждый раз вручную редактировать запланированную задачу.

Звучит не слишком привлекательно.

Однако в этом и заключается разница между «обновлением» и реальным обновлением.

Никогда не доверяйте одному зеленому индикатору

Такое случалось не раз.Поле статуса может быть устаревшим.

Процесс может быть запущен, но бесполезен.

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

Задача может завершиться успешно, но при этом запустить устаревший бинарный файл.Файл конфигурации может выглядеть идеально, в то время как запущенный процесс загружает что-то другое.

В какой-то момент статус шлюза Hermes показывал, что Telegram и Discord отключены.

В журналах в реальном времени было видно, что оба устройства подключены. Шлюз работал.

Каталог каналов был заполнен.

Был только один авторизованный процесс.

Флаги состояния были устаревшими.

Бывает и наоборот.

На дашборде может быть зеленый цвет, в то время как в работе системы есть серьезные проблемы.

Вот почему настоящий аудит должен охватывать несколько уровней.

Конфигурация
Процесс
Командная строка
Журналы
Поведение сети
Реальные возможности
Очистка после теста

Открытый порт не доказывает, что ваша система работает.

Как и HTTP 200.

Идентификатор процесса тоже не подходит.

Нужно протестировать систему.

Настоящий аудит проверяет поведение, а не только файлы

Финальный аудит не ограничился проверкой каталогов и YAML.

Он запустил систему.

Мы проверили:

реальный вывод данных по всем семи профилям
репрезентативную загрузку навыков
запуск браузера
подключение к CDP
Доступ к DOM
скриншоты
навигация
корректное завершение работы
уникальность процесса шлюза
Telegram
Discord
Изоляция Composio
привязка к cron
запланированные задачи
среда выполнения CUA
безопасность зависимостей
маршрутизация Nexus
Состояние Git
пути отката

Это стандарт.

Профиль не работает, так как его папка существует.

Навык не установлен, так как есть файл SKILL.md.

Шлюз не работает, так как есть PID.

План восстановления не работает только потому, что кто-то написал «восстановить из резервной копии».

Все важное должно быть выполнимо.

Аудит выявил проблемы с аудитом

Эта часть была почти забавной.

В первом сертификате говорилось, что все идеально.

Затем мы проверили сам сертификат.

И обнаружили проблемы.

Отчет о зависимостях был неверным.

В первом отчете говорилось, что pynacl не установлен.

Он был установлен.

В нем по-прежнему было две известные уязвимости.

Фактический путь эксплойта ограничивался функционалом, связанным с голосовым управлением, поэтому риск был низким.

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

Система все еще работала исправно.

Меньшие наборы навыков на самом деле были более узконаправленными.

Но данные о сертификации были неточными.

Ветвь исправления ошибок не была объединенаВ функциональной ветке было несколько важных изменений:

pyproject.toml
uv.lock
gateway/run.py

Рабочая система работала.

Но базовый вариант Git оказался не таким чистым, как следовало из сертификата.

Ни одна из этих проблем не разрушила архитектуру.

Но они доказали кое-что важное.

Аудит системы должен выдержать аудит аудита.

Зеленая галочка, которую нельзя воспроизвести самостоятельно, — это не зеленая галочка.

Это украшение.

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

После того как система прошла вторую проверку, мы зафиксировали производственную базовую конфигурацию.

Эта базовая конфигурация включает в себя:

полный снимок
список профилей
настройки модели и провайдера
количество навыков
хэши навыков
определения задач
определения cron
командная строка шлюза
политика оператора
коммиты в репозиторий
хэши важных файлов
версия CUA
хэш блокировки зависимостей
допустимые риски
скрипт проверки
руководство по восстановлению
Базовая страница Nexus

Потому что «сейчас все работает» — это недостаточно.

Главный вопрос:

Смогу ли я восстановить все, если что-то пойдет не так?

Сможет ли новый сеанс в Hermes восстановить все без необходимости просматривать историю чата за последние полгода?

Могу ли я проверить дрейф после обновления?

Могу ли я доказать, что именно изменилось?

Именно это превращает настройку агента в инфраструктуру.

Архитектура с несколькими агентами, которую я рекомендую

Для большинства серьезных персональных проектов или небольших команд я бы рекомендовал простой вариант.

Один командный профильЭтому профилю принадлежат:

взаимодействие с пользователями
маршрутизация
утверждения
окончательный синтез
общедоступные инструменты
учетные данные с высоким уровнем риска

Небольшое количество постоянных специалистов

Каждый специалист получает:

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

одноразовые субагенты

Используйте их для временной работы:

исследование
тестирование
критика
мозговой штурм
состязательная рецензия
параллельный анализ

Один общий уровень знаний

Используйте его для:

состояния проекта
принятия решений
право собственности
передача полномочий
правила маршрутизации
процедуры
история
восстановление

Один уровень проверки

Непрерывная проверка на наличие:

дрейфа модели
отсутствующих навыков
утечки учетных данных
дублирующих шлюзов
устаревшие запланированные задачи
устраненные ссылки на профили
нарушенная маршрутизация
дрейф Git
базовые изменения

Это позволяет специализироваться, не создавая автономное правительство внутри своего ноутбука.

Прежде чем создать еще одного агента, задайте себе этот вопрос

Есть ли у этой роли реальная повторяющаяся работа?

Нужна ли ей отдельная память?

Нужен ли ей другой рабочий каталог?

Нужны ли ей другие разрешения?

Нужен ли ей другой набор навыков?

Буду ли я точно знать, когда работа должна быть передана этой роли?

Буду ли я точно знать, когда работа не должна быть передана этой роли?

Снижает ли это уровень путаницы?

Или я просто создаю еще одного персонажа, потому что мультиагентность — это круто?

Может, это одноразовый субагент?

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

Вам нужен более эффективный рабочий процесс.

Суть

Цель мультиагентной системы — не воссоздание компании.

Цель не в том, чтобы заполнить панель управления аватарами.

И не в том, чтобы заставлять агентов проводить совещания с другими агентами, пока вы наблюдаете за вращением индикатора токенов.

Цель в том, чтобы разделить работу на четкие направления.

Защитить учетные данные.

Сохраняйте контекст.

Снижайте когнитивную нагрузку.

Делайте владельца очевидным.

Обеспечьте возможность восстановления системы.

И добейтесь лучших результатов, не тратя время на контроль всего процесса.

В моей системе используются RZA, GZA, Masta Killa, Inspectah Deck, Ghostface Killah, Method Man и Raekwon.

Эта часть забавная.

Но за ней стоит серьезная архитектура:

единая командная поверхность
постоянное владение специалистами
одноразовые субагенты
изолированная память
курируемые навыки
централизованные учетные данные
явные процедуры утверждения
совместное хранение данных
повторяющаяся верификация
документированное восстановление

Вот что делает его таким эффективным.

Не тема.

Не количество агентов.

Не скриншоты.

Архитектура.

Больше агентов — это не улучшение.

Более четкое владение.

Подписаться на телеграмм канал

👑Бесплатные AI-Медоды подписок VIP 👑

Loop Engineering.

2026-07-18T16:22:38.441Z

🗺️ Программа обучения (8 модулей)

Концепция Loop Engineering: зачем это нужно и чем отличается от обычного промптинга и твоего Harness Engineering.
Пять строительных блоков + Память: Automations, Worktrees, Skills, Plugins/MCP, Sub-agents и State/Memory (и как они ложатся на твои AGENTS.md и progress.md).
Анатомия цикла (loop): пошаговый разбор пути от schedule до human gate.
7 продакшн-паттернов: Daily Triage, PR Babysitter, CI Sweeper, Dependency Sweeper, Changelog Drafter, Post-Merge Cleanup, Issue Triage (ритм, стоимость токенов, когда что брать).
CLI-инструменты: практическое применение loop-init, loop-audit, loop-cost, loop-sync, loop-context, loop-mcp-server, loop-worktree, loop-gate.
Уровни автономности (L1 → L2 → L3) и безопасный поэтапный rollout.
Безопасность и провалы: failure modes, anti-patterns, multi-loop coordination, концепции intent debt / comprehension debt.
Интеграция с твоим стеком: как встроить это в Hermes-оркестрацию и делегирование задач между IVA-BOT, Codex и QwenPaw.

📘 Модуль 1: Концепция Loop Engineering

1. Что это такое (простыми словами)

Обычный промпт-инжиниринг — это когда ты говоришь агенту: "Сделай X". Ты — водитель, агент — машина. Ты крутишь руль на каждом повороте.

Loop Engineering — это когда ты проектируешь систему, которая сама решает, когда, какой промпт и какому агенту дать. Ты больше не водитель. Ты — инженер, который построил автопилот и проложил маршрут,это практика проектирования автономных систем, которые самостоятельно генерируют и отправляют промпты ИИ-агентам, оценивают результаты их работы и циклически повторяют этот процесс до достижения конечной цели.Ключевая идея этой концепции звучит так: вы перестаете быть человеком, который вручную пишет промпты для агента, и вместо этого проектируете систему, которая делает это за вас.

Любой такой цикл (loop) состоит из триггера (события, запускающего процесс), действия и проверяемого условия остановки. Система самостоятельно читает контекст, выполняет задачу, проверяет результат (например, с помощью тестирования кода), исправляет ошибки и принимает решение о следующем шаге.

Чем Loop Engineering отличается от промпт-инжиниринга:

Масштаб оптимизации: Промпт-инжиниринг направлен на оптимизацию одного конкретного взаимодействия (запроса и ответа). В то же время Loop Engineering оптимизирует всю замкнутую систему и рабочий процесс в целом. Сам по себе промпт становится лишь одним из составных компонентов внутри этой большой системы.
Ручное управление против автономии: В традиционном подходе с промптами человек работает линейно: пишет запрос, анализирует ответ, исправляет ошибки и пишет следующий промпт. Этот процесс требует постоянного участия, а контекст и состояние могут теряться между запросами. В Loop Engineering агент работает автономно: он сам «обдумывает» задачу, применяет инструменты, анализирует собственные ошибки (например, упавшие тесты в коде) и адаптирует свой подход без вмешательства человека, пока не достигнет успеха.
Динамическая обратная связь (Feedback Loops): В отличие от линейной цепочки шагов, Loop Engineering работает через динамические циклы обратной связи (наблюдение, действие, оценка, обновление, повторение). Если агент выбрал неверный путь, система позволяет ему пересмотреть свой план и попробовать другой подход.

Индустрия программирования с ИИ сейчас переживает смену парадигмы. Как отмечают такие эксперты, как Борис Черни (руководитель Claude Code в Anthropic) и Питер Штайнбергер, передовые разработчики больше не пишут промпты для кодинг-агентов напрямую; их работа теперь заключается в написании автономных циклов, которые сами направляют ИИ

Как говорит Борис Черни (Head of Claude Code в Anthropic): "Я больше не пишу промпты для Claude. У меня работают циклы (loops), которые пишут промпты для Claude и решают, что делать дальше. Моя работа — проектировать эти циклы".

2. Чем это отличается от твоего Harness Engineering?

Это самый важный момент для твоей практики. Ты уже используешь Harness Engineering (создание среды, правил и контекста для агента через AGENTS.md, feature_list.json, progress.md).

Harness Engineering — это песочница и инструкция для одного запуска. Это ответ на вопрос: "Как агент должен себя вести, когда я его прямо сейчас запустил?"
Loop Engineering — это оркестрация во времени. Это ответ на вопрос: "Как система должна самостоятельно запускать этот Harness, проверять результат, сохранять прогресс и решать, что делать дальше, пока меня нет за компьютером?"

Простая аналогия:

Твой AGENTS.md и feature_list.json — это инструкция и чертеж для строителя.
Твой progress.md — это журнал работ.
Harness — это сам строитель с инструментами, который читает инструкцию.
Loop (Цикл) — это прораб, который приходит утром, смотрит в progress.md, видит, что стена не доложена, дает строителю (Harness) новую задачу, вечером проверяет результат тестами и записывает новый статус в progress.md.

3. Две главные ловушки, которые убивают автономных агентов

В репозитории выделяются два вида "долга" (debt), которые ты должен контролировать как архитектор:

Intent Debt (Долг намерения): Каждый раз, когда агент запускается, он начинает "с чистого листа" и начинает угадывать, как вы работаете.

Решение: Твои AGENTS.md и SKILL.md файлы. Это "память намерений", которая платит по этому долгу, давая агенту готовые правила вместо догадок.

Comprehension Debt (Долг понимания): Цикл работает быстро и делает много изменений, а ты перестаешь понимать, что именно он натворил и почему.

Решение: Строгие отчеты, читаемый progress.md и обязательные "человеческие ворота" (human gates) для важных решений. Если ты перестаешь читать отчеты цикла, ты теряешь контроль.

4. Рекурсивная цель

Loop Engineering строится вокруг рекурсивной цели. Ты не говоришь: "Напиши функцию". Ты говоришь: "Добавь эту фичу из feature_list.json. Запускай тесты. Если тесты падают, читай ошибку, исправляй код и повторяй, пока тесты не станут зелеными или пока не будет сделано 3 попытки. После этого запиши результат в progress.md и остановись".

📝 Резюме Модуля 1

Loop Engineering — это переход от ручного управления агентом к проектированию автономной системы, которая управляет агентом сама.
Твой Harness Engineering (AGENTS.md, feature_list.json) — это идеальный фундамент для Loop. Harness дает агенту правила, а Loop дает агенту расписание, проверку и память между запусками.
Главная задача инженера — не писать промпты, а гасить Intent Debt (через четкие инструкции) и не допускать Comprehension Debt (через прозрачные отчеты и лимиты).

🧱 Модуль 2: Строительные блоки + Память

Любой устойчивый цикл состоит из 5+1 компонентов. Если убрать хотя бы один, цикл либо сломается, либо начнет творить хаос.

1. State / Memory (Состояние и Память)

Это «блокнот» цикла. Агент не должен гадать, на чем он остановился.

Как это выглядит в Loop Engineering: Это структурированные файлы состояния (например, loop_state.json или тот же progress.md), которые обновляются после каждого шага.
Твоя практика: Твой progress.md и feature_list.json — это и есть идеальная реализация этого примитива. Когда цикл запускается, он первым делом читает progress.md, чтобы понять текущий статус, а последним делом записывает туда результат. Это гасит Intent Debt (агенту не нужно угадывать контекст).

2. Skills (Навыки)

Это инкапсулированные инструкции или скрипты, которые говорят агенту как именно выполнять задачу в твоем проекте.

Как это выглядит: Отдельные файлы или директории (например, skills/), которые цикл подгружает в контекст только тогда, когда они нужны. Не нужно пихать всё в один гигантский промпт.
Твоя практика: Твой AGENTS.md — это главный Skill. Если у тебя есть специфичные правила для работы с базой данных или деплоем, они должны быть вынесены в отдельные Skill-файлы (например, skills/db-migration.md), которые Hermes подгрузит, только если задача касается БД.

3. Worktrees (Рабочие пространства / Песочницы)

Критически важный элемент безопасности. Агент никогда не должен работать напрямую в main или master ветке.

Как это выглядит: Цикл автоматически создает изолированную среду. В мире Git это git worktree или отдельная feature-ветка. Агент делает изменения там, запускает тесты, и только если всё зелено, цикл предлагает эти изменения на ревью (PR/MR).
Твоя практика: Когда Hermes получает задачу из feature_list.json, он должен дать команду Codex или QwenPaw: «Создай ветку loop/feature-X, сделай изменения там, запусти тесты». Если тесты падают 3 раза подряд — цикл откатывает изменения (или оставляет ветку с пометкой needs_human_help) и пишет об этом в progress.md.

4. Plugins / MCP (Model Context Protocol)

Это «органы чувств» и «руки» цикла. То, через что агент взаимодействует с внешним миром, не раздувая свой контекст.

Как это выглядит: Серверы MCP или простые CLI-скрипты, которые агент может вызвать. Например, инструмент search_jira, get_ci_status или read_log.
Твоя практика: Вместо того чтобы заставлять агента парсить сырой вывод консоли, ты даешь ему Skill или MCP-инструмент run_tests_and_summarize, который возвращает структурированный JSON: {"passed": true, "errors": []}. Это резко снижает Comprehension Debt, потому что агент получает четкие данные, а не стену текста.

5. Sub-agents (Суб-агенты / Специализация)

Один агент на все руки — это миф. В продакшене циклы делегируют задачи узким специалистам.

Как это выглядит: Главный оркестратор (Router/Manager) читает задачу и решает, кого позвать.
Твоя практика:

Hermes — это оркестратор (читает feature_list.json, решает, что делать).
IVA-BOT — занимается триажем: читает входящие issue, классифицирует их, заполняет черновик ответа.
Codex / QwenPaw — получают четкую задачу от Hermes: «Вот ветка, вот AGENTS.md, вот конкретная функция из feature_list.json. Напиши код и тесты».
Такой конвейер намного надежнее, чем один мега-промпт, который пытается и придумать архитектуру, и написать код, и пообщаться с пользователем.

6. Automations (Триггеры)

То, что запускает цикл. Без триггера цикл мертв.

Как это выглядит: Cron-расписание (например, «каждое утро в 9:00»), вебхук (например, «при создании нового PR») или ручной вызов через CLI.
Твоя практика: Ты можешь настроить cron, который раз в час запускает Hermes. Hermes проверяет feature_list.json на наличие задач со статусом pending, берет верхнюю, создает Worktree, зовет QwenPaw, и по завершении обновляет статус на in_review.

🔗 Как это работает вместе (пример из жизни)

Представь, что в feature_list.json появилась задача: "Добавить валидацию email в форму регистрации".

Automation: Срабатывает cron. Запускается скрипт цикла.
State: Цикл читает feature_list.json и progress.md. Видит задачу со статусом todo.
Worktree: Цикл создает ветку loop/email-validation.
Sub-agents & Skills: Hermes вызывает QwenPaw, подгружая ему AGENTS.md и Skill skills/forms-validation.md.
Plugins/MCP: QwenPaw пишет код, затем вызывает MCP-инструмент run_unit_tests. Инструмент возвращает: FAIL: missing import.
Loop (итерация): QwenPaw видит ошибку, исправляет импорт, снова вызывает run_unit_tests. Теперь PASS.
State: Цикл обновляет progress.md: "Задача X выполнена, ветка loop/email-validation готова к ревью".
Human Gate: Цикл останавливается и шлет тебе уведомление: «PR готов, проверь».

📝 Резюме Модуля 2

Цикл держится на 6 примитивах: Память (progress.md), Навыки (AGENTS.md), Песочница (Worktrees), Инструменты (MCP), Специализация (Hermes + QwenPaw) и Триггеры (Cron/Webhook).
Главная цель этой архитектуры — не дать агенту сломать main, не дать ему забыть контекст и не заставить тебя читать 100500 строк логов.

Модулю 3: Анатомия цикла (Loop).

Здесь мы перестаем говорить об агентах как о «волшебных черных ящиках» и начинаем смотреть на них как на конвейер. В Loop Engineering цикл — это не просто «запустил промпт и получил ответ».

Это строгая последовательность из 8 шагов, которая гарантирует, что система не сойдет с ума, не испортит данные и не начнет спамить клиентам Константина.Давай разберем каждый шаг анатомии цикла на примере реальной задачи RHT Spraytech: «Найти и подготовить к контакту 50 новых автосервисов в Новосибирске».

⚙️ Анатомия цикла: 8 шагов от триггера до решения

1. Schedule (Триггер / Расписание)

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

В коде: Cron-задача или webhook.
В RHT: Hermes получает сигнал: «Вторник, 10:00. Проверь файл feature_list.json на наличие задач со статусом pending».

2. Triage (Сортировка и маршрутизация)

Оркестратор оценивает, что именно нужно сделать, и не пытается сделать всё сам.

В RHT: Hermes читает задачу: «Найти автосервисы в Новосибирске». Он понимает: «Ага, это задача на поиск и обогащение. Мне нужно вызвать цепочку: Lead Hunter → Research → Contact Intelligence».

3. State (Чтение состояния / Память)

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

В RHT: Hermes читает progress.md или CRM. Он видит: «Стоп, мы уже проверяли "Автосервис №1" на прошлой неделе, он был нерелевантен. Исключаем его из нового списка». Также он подгружает актуальные правила из AGENTS.md (например, "не предлагать скидки на FK-80 в первом письме").

4. Worktree (Изолированная среда / Песочница)

Агент никогда не работает напрямую с «боевой» базой или основными каналами связи на этапе экспериментов.

В коде: Это git worktree или новая ветка.
В RHT: Hermes создает изолированный черновик. Например, новую вкладку в таблице «Кампания_Новосибирск_Черновик» или черновик кампании в CRM. Все действия агента (парсинг, генерация текстов) происходят только здесь. Если агент сойдет с ума и напишет бред, основная база клиентов и репутация компании не пострадают.

5. Implementer (Исполнение)

Непосредственная работа специализированных агентов в изолированной среде.

В RHT:

Lead Hunter забирает сырые названия из 2ГИС в черновик.
Research Agent проходит по сайтам, ищет слова «опт», «спецтехника».
Contact Intelligence ищет email и телефоны через MCP-инструменты. Каждый агент делает только свою узкую задачу и передает эстафету дальше.

6. Verifier (Проверка качества / QA)

Прежде чем результат покинет «песочницу», его должен проверить независимый агент или строгий набор правил.

В RHT: QA Agent пробегается по черновику и задает вопросы:

«У всех ли компаний в списке А заполнено поле email?»
«Есть ли в сгенерированных письмах запрещенные слова или выдуманные цены на FK-80?»
«Соответствует ли компания нашему ICP?» Если проверка не пройдена, цикл возвращается на шаг 5 (Implementer) с инструкцией исправить ошибку, или помечает задачу как requires_human_help.

7. MCP / Git (Фиксация результата)

Только после успешной проверки данные переносятся из «песочницы» в систему учета.

В RHT: Валидные, проверенные карточки компаний и утвержденные черновики писем переносятся из черновика в основную CRM (или progress.md получает статус ready_for_approval). Цикл фиксирует время, затраченные токены и результат.

8. Human Gate (Человеческие ворота)

Самый важный шаг для снижения тревожности (Anxiety) Константина. Цикл останавливается и ждет явного разрешения человека на критическое действие.

В RHT: Hermes отправляет Константину уведомление (в Telegram или на почту):"Цикл завершен. Найдено 50 компаний, после проверки и скоринга осталось 12 релевантных (Категория А). Черновики первых писем сгенерированы. [Посмотреть таблицу] [Утвердить и отправить] / [Отклонить и скорректировать правила]"

Только после нажатия «Утвердить» система переходит к следующему циклу (Communication Loop) и рассылает письма.

💡 Почему этот порядок неслучаен?

Если перепутать шаги, система рухнет:

Если убрать State, агент начнет писать одним и тем же клиентам дважды (Comprehension Debt).
Если убрать Worktree, ошибка агента на этапе парсинга может удалить или испортить основную базу CRM.
Если убрать Verifier, в CRM попадут компании без email или с галлюцинированными названиями.
Если убрать Human Gate, Константин потеряет контроль, и система превратится в «черный ящик», который он в итоге отключит из-за страха репутационных рисков.

📝 Резюме Модуля 3

Анатомия цикла — это конвейер: Триггер → Сортировка → Чтение памяти → Изоляция (Worktree) → Работа агентов → Проверка (QA) → Фиксация → Одобрение человеком. Эта структура превращает хаотичные действия ИИ в предсказуемый, безопасный и управляемый бизнес-процесс, что идеально ложится на требование Константина о «поэтапном снижении риска».

Модулю 5: CLI-инструменты Loop Engineering.

🛠️ Модуль 5: Практическое применение CLI-инструментов

1. loop-init (Инициализация цикла)

Что делает: Создает изолированную структуру папок, файлы состояния и подгружает нужные навыки (Skills) для конкретной задачи. Не дает новому циклу смешаться со старым. Пример в RHT: Ты запускаешь пилот по новому региону.

loop-init --region="Новосибирск" --segment="автосервисы" --product="FK-80"

Результат: Система создает папку loops/nsk_auto_2024/, внутри генерирует пустой state.json, копирует туда актуальный AGENTS.md и rules_fk80.md. Теперь цикл знает, где он, что он делает и какими правилами ограничен.

2. `loop-audit` (Аудит состояния)

Что делает: Мгновенно показывает здоровье цикла без необходимости читать тысячи строк логов. Отвечает на вопрос: «Где мы застряли и всё ли в порядке?»

loop-audit --loop="nsk_auto_2026"

Результат (читаемая сводка):

📊 Статус цикла: paused_at_gate

🔍 Найдено компаний: 150

✅ Прошло Research & Scoring: 45 (Категория А: 12, Категория В: 33)

⚠️ Ошибки/Пропуски: 3 (нет сайта или невалидный email)

📝 Готово черновиков писем: 12

⏳ Ожидает апрува человека: 12

3. `loop-cost` (Контроль расходов)

Что делает: Считает потраченные токены и деньги в реальном времени. Это прямой ответ на тревогу Константина «мы сливаем бюджет». Пример в RHT: Перед запуском массовой проверки сайтов ты ставишь лимит.

bash
loop-cost --check --limit="$2.00"

Результат: «Потрачено: $0.45. Осталось: $1.55. Статус: ОК». Если лимит исчерпан, loop-gate автоматически ставит цикл на паузу и шлет алерт, прежде чем агенты сожгут бюджет на галлюцинации.

4. `loop-context` (Управление памятью и сжатие)

Что делает: Собирает и «сжимает» только ту информацию, которая нужна агенту прямо сейчас, отбрасывая шум. Решает проблему перегрузки контекста.

Пример в RHT: Перед тем как Communication Agent напишет письмо, он не читает весь лог переписки или весь progress.md. Он вызывает:

loop-context --target="company_id_45" --fields="name,segment,relevance_signals,contact_email"

Результат: Агент получает чистый JSON на 300 токенов вместо 5000 токенов сырого HTML и логов, что делает его письмо точным, а не размытым.

5. loop-mcp-server (Локальный шлюз к инструментам)

Что делает: Предоставляет агентам безопасный, стандартизированный доступ к внешним API и локальным файлам, не заставляя их «угадывать» форматы или хардкодить ключи.

Пример в RHT: Вместо того чтобы просить агента «найди email в интернете», ты даешь ему инструмент:

// Агент вызывает этот MCP-инструмент
{
  "tool": "search_2gis_contacts",
  "args": {"company_name": "ООО Автомир", "region": "Новосибирск"}
}

Результат: Сервер возвращает строгий, проверенный ответ. Агент не может «придумать» email, он получает только то, что реально вернул API.

7. `loop-gate` (Человеческие ворота)

Что делает: Останавливает цикл в критической точке и требует явного подтверждения (approval) от человека через удобный интерфейс (например, Telegram-бот или веб-хук). Пример в RHT: Цикл дошел до этапа отправки.

loop-gate --action="approve_outreach" --batch="12_emails" --notify="constantine_tg"

Результат: Вы получает в Telegram сообщение:

🛑 Требуется решение Цикл nsk_auto_2024 подготовил 12 персонализированных писем для автосервисов (Категория А). Бюджет цикла: $0.45. [📄 Посмотреть черновики в таблице] [✅ Аппрув и отправка] | [❌ Отклонить и скорректировать промпт]

Пока вы не нажмете кнопку, цикл физически не может пойти дальше. Это гасит его Anxiety (тревогу) на 100%.

💡 Резюме Модуля 5

Эти инструменты превращают «магического ИИ-помощника» в прозрачный инженерный конвейер.

init и worktree обеспечивают изоляцию.
context и mcp-server обеспечивают качество данных.
audit и cost обеспечивают прозрачность для бизнеса.
gate обеспечивает финальный контроль и безопасность репутации.

Для вас это означает, что он покупает не «черный ящик», а управляемую систему с рычагами, которые он понимает и которым доверяет.

Модулю 6: Уровни автономности (L1 → L2 → L3) и поэтапный rollout.

📈 Шкала автономности в RHT Spraytech

Уровень L1: «Помощник» (Human-driven, AI-assisted)

Система делает всю черновую работу, но финальное действие всегда за человеком.

Как это работает: Hermes запускает цикл. Lead Hunter и Research Agent находят и проверяют 50 компаний. Communication Agent генерирует 12 персонализированных черновиков писем для компаний категории «А».
Роль человека: Константин (или менеджер) открывает таблицу/дашборд, читает каждое письмо, при необходимости правит и лично нажимает кнопку «Отправить».
Плюс: Абсолютный контроль, нулевой репутационный риск.
Минус: Не решает проблему нехватки времени человека.

Уровень L2: «Супервайзер» (AI-driven, Human-supervised)

Система самостоятельно выполняет рутинные действия по строгим правилам, но эскалирует всё нестандартное.

Как это работает: Система самостоятельно отправляет первые письма по утвержденным шаблонам компаниям категории «А». Она также сама ставит задачи на follow-up (например, «напомнить через 3 дня»).
Роль человека: Как только приходит любой ответ от клиента (особенно вопрос о цене, условиях дилерства или запрос образца), цикл немедленно останавливается. Hermes шлет алерт: "Требуется решение: Компания X заинтересовалась FK-80. Вот черновик ответа. Утвердить или написать свой?". CRM обновляется автоматически.
Плюс: Высвобождает 80% времени человека, сохраняя контроль над критическими точками (деньги, репутация).
Минус: Требует идеально настроенных правил эскалации.

Уровень L3: «Ограниченный автопилот» (Autonomous within strict boundaries)

Система ведет весь цикл от начала до конца в рамках безопасного периметра.

Как это работает: Для низкорисковых сценариев (например, первичный холодный поиск в новом регионе без отправки писем, или автоматическая отправка прайс-листа по явному запросу из формы на сайте) система работает полностью сама. Она сама парсит, сама обогащает, сама отправляет запрошенный файл, сама архивирует отказы с указанием причины.
Роль человека: Человек подключается только раз в неделю на Weekly Improvement Loop, чтобы посмотреть сводный отчет: "Найдено 500, отправлено 100, получено 5 ответов, 1 запрос образца".
Плюс: Максимальная масштабируемость.
Минус: Недопустим на старте без накопленной статистики и доверия.

🚀 Поэтапный Rollout (Как мы продаем это Константину)

Мы не продаем ему L3. Мы продаем ему безопасный путь к L3, где он может остановиться на любом этапе без ощущения "потерянных денег". Это напрямую бьет в его критерий: "возможность остановить, изменить или масштабировать систему без перестройки всего проекта".

Недели 1-2 (Этап 2-3): Работаем строго на L1. Система только ищет, проверяет и готовит черновики. Цель: доказать, что Research Agent не галлюцинирует и находит именно автосервисы и дилеров, а не розничные магазины.
Недели 3-4 (Этап 4): Переходим на L2 для небольшой выборки (например, 20 компаний). Система отправляет письма сама, но все ответы идут Константину на апрув. Цель: проверить deliverability (попадаем ли в спам) и качество реакции рынка.
Месяц 2 и далее (Этап 6): Если экономика сходится (CPL в норме, есть запросы образцов), мы переводим рутинные ветки (напоминания, отправка КП) на L3, а человека оставляем только для закрытия сделок и работы с теплыми лидами.

Модуль 7: Безопасность и провалы (Failure Modes, Anti-patterns и управление долгом).

💥 1. Режимы провала (Failure Modes): Как цикл ломается на практике

В Loop Engineering есть три классических сценария смерти цикла. Давай посмотрим на них через призму RHT Spraytech.

А. Бесконечный рестарт (Infinite Retry Loop)

Что происходит: Research Agent пытается спарсить сайт компании, но там стоит защита (например, Cloudflare или капча). Агент получает ошибку, думает "я ошибся в промпте", и пробует снова. И снова. И снова.
Последствие для RHT: Hermes зависает, токены сгорают за 10 минут, бюджет улетает в трубу, клиент получает счёт на $50 за один утренний запуск.
Решение (Engineering fix): Жёсткий лимит попыток (max 2 retries) и чёткое правило в AGENTS.md: "Если сайт недоступен или требует капчу после 2 попыток, запиши в progress.md статус blocked_by_waf и переходи к следующей компании. Не трать токены на угадывание".

Б. Каскад галлюцинаций (Hallucination Cascade)

Что происходит: Lead Hunter нашёл компанию, но не нашёл email. Вместо того чтобы пометить это, он "придумывает" email (например, info@avtomir.ru, которого не существует), чтобы выполнить задачу "найти контакт". Research Agent верит этому и пишет персонализированное письмо на несуществующий адрес.
Последствие для RHT: Репутационный риск (письма возвращаются как spam/bounce), порча данных в CRM.
Решение (Engineering fix): Внедрение Verifier (QA Agent) перед записью в CRM. Правило: "Если email не проходит валидацию через MCP-инструмент validate_email, поле остаётся пустым, а компания получает статус needs_manual_check".

В. Тихий провал (Silent Failure)

Что происходит: Цикл столкнулся с ошибкой API (например, закончились кредиты 2GIS), просто остановился и ничего не написал в логи или progress.md.
Последствие для RHT: Клиент думает, что система работает, а на самом деле она стоит неделю.
Решение (Engineering fix): Цикл обязан завершаться явным статусом, даже если это ошибка. status: "failed_api_limit".

🚫 2. Антипаттерны (Anti-patterns): Как не надо проектировать

"Бог-промпт" (The God Prompt): Попытка заставить одного агента найти компанию, изучить сайт, найти email, написать письмо и обновить CRM.

Почему это плохо: Контекст перегружается, агент теряет фокус, цена токенов взлетает.
Твоё преимущество: Ты уже проектируешь систему через специализированных агентов (Hermes, Lead Hunter, Research, Scoring). Это правильный путь Loop Engineering.

Игнорирование состояния (State Amnesia): Агент начинает задачу, не проверив progress.md.

Почему это плохо: Он начинает писать письмо компании, которой уже писали 3 дня назад. Это прямой путь к спаму.
Твоё преимущество: Твой progress.md — это единый источник истины. Первое действие любого цикла — read_state.

⚙️ 3. Координация нескольких циклов (Multi-loop Coordination)

Когда система растёт, циклы начинают мешать друг другу.

Сценарий конфликта:

Цикл А (Search Loop) нашёл "ООО Автомир" и начал его исследовать (статус researching).
Цикл Б (Communication Loop) видит "ООО Автомир" в базе и решает, что пора писать письмо, потому что не проверяет текущий статус, а смотрит только на дату добавления.

Результат: Communication Agent пишет письмо, используя неполные или устаревшие данные, пока Research Agent ещё не закончил работу.
Решение (State Machine Locks): В progress.md должны быть чёткие статусы-блокировщики. Communication Loop имеет право брать компанию в работу только если research_status == "complete" И contacts_found == true. Иначе он её игнорирует.

🛡️ 4. Управление долгом через Harness Engineering

Вспомним два вида долга из Модуля 1 и посмотрим, как твои файлы их гасят:

Intent Debt (Долг намерения): "Агент не знает, как мы работаем, и начинает гадать".

Твоё решение: Файлы AGENTS.md и skills/rht_outreach_rules.md. Ты не надеешься на "ум" модели. Ты даёшь ей жёсткие инструкции: "Никогда не называй цену FK-80. Всегда предлагай образец. Если клиента нет в списке сегментов ICP, ставь оценку C". Долг погашен.

Comprehension Debt (Долг понимания): "Система сделала 1000 действий, и я (Константин) не понимаю, что именно она натворила".

Твоё решение: Файл progress.md. Это не сырой лог. Это структурированная сводка, которую читает человек: "Найдено: 50. Проверено: 50. Готово к отправке: 12. Ошибки: 2 (нет сайта)". Константин тратит 30 секунд на чтение, а не 30 минут на разбор логов. Долг погашен.

📝 Резюме Модуля 7

Безопасность в Loop Engineering — это не магия, а инженерные ограничения:

Лимиты на попытки (чтобы не сжечь бюджет).
Обязательная запись статуса даже при ошибке (чтобы не было "тихого провала").
Блокировки состояний (чтобы циклы не мешали друг другу).
Использование AGENTS.md и progress.md как главных инструментов контроля над галлюцинациями и хаосом.

"Мы не даём системе свободы делать что угодно. Мы даём ей свободу действовать только в тех узких коридорах, которые мы сами построили и проверили".

Модулю 8: Интеграция с твоим стеком и практическая реализация.

Здесь мы собираем всё воедино. Мы возьмём методологию Loop Engineering, твои файлы Harness Engineering (AGENTS.md, feature_list.json, progress.md) и твою команду агентов (Hermes, QwenPaw, Codex, IVA-BOT), чтобы показать, как именно будет работать система для Клиента (RHT Spraytech) с первого дня.

Ниже расписан Loop Engineering на отдельном примере реального кейса

🧩 Интеграция со стеком и практическая реализация на проекте RHT Spraytech

Здесь мы собираем всё воедино. Берём методологию Loop Engineering, твои файлы Harness Engineering (AGENTS.md, feature_list.json, progress.md) и твой единый оркестратор Hermes Agent, чтобы показать, как именно будет работать система для Клиента (RHT Spraytech) с первого дня.

Никакой абстракции. Только конкретный бизнес-цикл: поиск и квалификация дилеров/автосервисов в новом регионе.

🎯 1. Философия: Hermes — единая точка управления

В твоём предложении (раздел 3.2) это зафиксировано чётко:

"Hermes Desktop предлагается использовать как оркестратор: он запускает задачи по расписанию, распределяет работу между агентами, хранит контекст проекта, показывает статус циклов и собирает отчёты."

Ключевой архитектурный принцип: все суб-агенты из раздела 5 твоего документа (Lead Hunter, Research, Contact Intelligence, Scoring, Communication, CRM, QA и т.д.) — это не отдельные внешние платформы и не разные модели. Это специализированные роли (навыки/промпты), которые Hermes вызывает последовательно, очищая контекст между шагами.

Это и есть Loop Engineering в чистом виде: один оркестратор, изолированные контексты, строгие контракты данных между шагами.

🧠 2. Как суб-агенты реализуются внутри Hermes

Вот как "команда узких цифровых специалистов" из раздела 5 твоего документа ложится на реальную архитектуру Hermes:

Главная магия: каждый раз, когда Hermes вызывает следующий суб-агент, он очищает контекст. Когда работает Research Agent, Hermes "забывает" про правила написания писем. Когда работает Communication Agent, Hermes "забывает" про правила парсинга сайтов. Это предотвращает перегрузку и галлюцинации.

⚙️ 3. End-to-End пример: полный цикл на базе Hermes

Представь, что Клиент утвердил пилот. Вот как выглядит один полный прогон цикла (Loop) без участия человека до финального апрува.

Шаг 1: Trigger & State (09:00, Cron)

Hermes просыпается. Читает feature_list.json:

{
  "task_id": "loop_nsk_dealers_001",
  "status": "pending",
  "goal": "Найти 50 автосервисов/дилеров в Новосибирске",
  "target_segment": ["дилеры автохимии", "крупные автосервисы", "СТО спецтехники"],
  "product_focus": "FK-80"
}

Hermes читает progress.md, чтобы убедиться, что эти компании ещё не обрабатывались.

Шаг 2: Lead Search Loop (роль Lead Hunter)

Hermes создаёт изолированный Worktree worktrees/nsk_001/. Вызывает роль Lead Hunter с инструкцией: "Используй MCP search_2gis, найди 50 компаний по целевым сегментам в Новосибирске. Верни строго JSON: name, url, category, phone". Lead Hunter возвращает чистый массив. Грязь и дубли отброшены.

Шаг 3: Research & Qualification Loop (роли Research + Contact Intelligence + Scoring)

Hermes передаёт список из 50 компаний роли Research Agent. В промпт подгружается Skill: skills/rht_research_rules.md. Задача Research Agent: Пройтись по URL. Найти на сайте слова "опт", "дилерам", "корпоративным клиентам". Результат: Из 50 компаний 35 получают статус irrelevant (розница), 15 получают статус category_A.

Для 15 релевантных Hermes вызывает Contact Intelligence — тот находит email и телефоны через MCP-инструменты.

Затем Hermes вызывает Lead Scoring с файлом icp_rules.md. Скоринг возвращает обоснование: "Компания X — дилер автохимии, есть раздел 'Стать дилером', соответствует ICP по 4 из 5 критериев".

Шаг 4: Communication Loop (роли Communication + QA)

Для компаний категории А Hermes вызывает Communication Agent. В контекст подаётся knowledge/fk80_dealer_terms.md и knowledge/fk80_benefits.md. Жёсткое правило в промпте: "Используй только факты из файла знаний. Никогда не называй цену. Цель письма — предложить выслать образец FK-80 или КП, а не продать сразу". Communication Agent генерирует 15 персонализированных черновиков.

Затем Hermes вызывает QA Agent, который проверяет черновики на "красные флаги": наличие слов "скидка 50%", "гарантируем", или отсутствие email в карточке. Если всё чисто, статус меняется на ready_for_human_gate.

Шаг 5: Human Gate (Hermes → Клиент)

Hermes формирует сводку и отправляет Клиенту (например, в Telegram или на почту):

📊 Отчёт по циклу nsk_dealers_001 • Найдено: 50 компаний • Отсеяно (нерелевант): 35 • Готово к отправке (Категория А): 12 • Затрачено токенов: ~$0.12📎 [Ссылка на таблицу с черновиками писем и обоснованием выбора][✅ Утвердить и запустить отправку] | [❌ Отклонить и скорректировать правила]

Шаг 6: Execution & Memory Update (роль CRM Agent)

Клиент нажимает "✅". Hermes передаёт задачу роли CRM Agent: "Создай карточки в CRM, проставь статус outreach_sent, запланируй follow-up через 3 дня".

Шаг 7: Weekly Improvement Loop (роль Improvement Agent)

Раз в неделю Hermes запускает Improvement Agent, который сводит данные: какие источники дали качественные компании, какие сегменты чаще отвечают, какие сообщения вызывают интерес. Рекомендации идут Клиенту на утверждение.

🗺️ 4. Как это ложится на этапы внедрения из документа

Моя архитектура идеально синхронизирована с дорожной картой из раздела 12:

🛡️ 5. Как Harness Engineering страхует от провалов

Именно твои файлы делают эту систему предсказуемой для Клиента. Вот как они выглядят в деле:

1. AGENTS.md (Skill для Communication Agent):

# Роль: Communication Agent для RHT Spraytech
## Жёсткие ограничения (Negative Constraints):
- ЗАПРЕЩЕНО придумывать цены или условия доставки. Если их нет в `knowledge/prices.md`, пиши: "Условия обсуждаются индивидуально".
- ЗАПРЕЩЕНО позиционировать FK-80 как розничный товар. Фокус: опт, дилерство, корпоративные клиенты.
- Если компания не в списке сегментов ICP, не трать токены на генерацию письма.

2. progress.md (State/Memory):

## Цикл: nsk_dealers_001 (Дата: 19.07.2026)
| Компания | Сегмент | Скоринг | Статус | Следующий шаг |
|---|---|---|---|---|
| ООО "Автомир-НСК" | Дилер автохимии | A | `draft_approved` | Отправлено 19.07. Ждём ответ до 22.07 |
| ИП Иванов (Шиномонтаж) | Розница | C | `archived` | Нет оптовых разделов на сайте |

Клиент открывает этот файл и за 10 секунд понимает, что делает система. Comprehension Debt = 0.

3. feature_list.json (Задачи для Hermes):

{
  "task_id": "loop_nsk_dealers_001",
  "status": "completed",
  "result": "12 leads approved for outreach",
  "cost_usd": 0.12,
  "next_loop": "follow_up_22_07"
}

💡 6. Почему это идеальное попадание в JTBD Клиента

Вспомним его корневую задачу из стратегического разбора: "Построить экономически устойчивый канал привлечения новых B2B-клиентов без возврата к тяжёлой и дорогой штатной модели продаж".

Экономика: Клиент не нанимает менеджера за 80к+ в месяц. Он тратит копейки на токены и API 2GIS, оплачивая только релевантные действия. Это прямое решение его боли "издержки на содержание отдела продаж были выше, чем они могут нам дать".
Контроль: Клиент не боится "чёрного ящика". Он видит progress.md, он утверждает первую партию писем (Human Gate). Он может остановить цикл на любом этапе (Модульность из раздела 3.5).
Масштабируемость: Когда пилот в Новосибирске покажет, что из 12 писем 3 приводят к запросу образца, Клиент сам скажет: "Запускаем то же самое на 10 новых регионов". И Hermes сделает это за минуту, просто обновив feature_list.json.
Доводка до счёта: Система не останавливается на "списке компаний". Она доводит лида до запроса образца, КП или счёта — ровно то, что Клиент формулировал как "доводить клиента… до покупки продукции, до выставления ему счета".

🏁 Финал Модуля 8

Я получил не просто набор знаний, а готовый архитектурный каркас, который:

Строится на базе единого Hermes Agent (без зоопарка внешних платформ).
Использует специализированные роли внутри Hermes (Lead Hunter, Research, Scoring, Communication, QA, CRM).
Оперирует повторяемыми бизнес-циклами (Lead Search Loop, Research & Qualification Loop, Communication Loop, Weekly Improvement Loop).
Защищён твоими файлами Harness Engineering (AGENTS.md, feature_list.json, progress.md).
Синхронизирован с дорожной картой внедрения из твоего документа (Этапы 1–6).
Прямо закрывает JTBD Клиента и снижает его Anxiety через поэтапность и Human-in-the-loop.

Автоматизация продаж
через AI-агентов

Реальные кейсы. Пошаговые разборы.
[тг канал] • Подписаться

ПАМЯТКА: Hermes Agent — как вызывать и ставить задачи

2026-07-16T16:52:24.041Z

1. Точка входа

Бот в Telegram всегда стартует на orchestrator (он сам распределяет задачи по ролям). Обычно переключать ничего не надо.

2. Как вызвать конкретную роль напрямую

Напиши боту:

Code

/profile coder
/profile marketer
/profile copywriter
/profile researcher
/profile curator
/profile prompt-engineer

После переключения пиши задачу — она пойдёт в эту роль. Вернуться к оркестратору: /profile orchestrator

3. Роли и что они делают

orchestrator — главный, планирует и делегирует. Пиши сюда все общие задачи.
coder — код, скрипты, git, инфраструктура.
marketer — стратегия, позиционирование, воронки, офферы.
copywriter — посты, реклама, письма, скрипты.
researcher — исследования, конкуренты, отчёты, веб/репо.
curator — структурирование, проверка на дубли/логику, база знаний.
prompt-engineer — промпты, инструкции, дизайн агентов.

4. Как ставить задачу orchestrator (формула)

Code

[Что] + [Для кого/зачем] + [Формат результата] + [Роли если знаешь]

Orchestrator сам вызовет нужные роли и соберёт результат.

5. Примеры задач (копипаст)

Контент-план:

Code

Сделай контент-план на 3 дня для канала про автоматизацию бизнеса.
Marketer — темы и форматы, Copywriter — заголовки и первые строки, Curator — проверь дубли и логику.
Итог — таблица: День | Тема | Формат | Заголовок.

Лендинг:

Code

Нужен HTML-лендинг для ИИ-ассистента малого бизнеса.
Marketer — оффер и блоки (hero, выгоды, тарифы, форма), Coder — каркас кода по этим блокам.
Принеси структуру + код одним ответом.

Исследование:

Code

Найди 5 конкурентов в нише "ИИ для недвижимости".
Researcher — собери что предлагают и цены, Curator — структурируй в таблицу сравнения.

Промпт для агента:

Code

Сделай промпт для агента-поддержки (отвечает на вопросы клиентов по тарифам).
Prompt-engineer — напиши промпт с ролями и guardrails, Curator — проверь на дыры.

Комплексная кампания:

Code

Запусти недельную кампанию для запуска курса по автоматизации.
Marketer — стратегия и воронка, Copywriter — тексты для 5 постов и e-mail, Curator — вычитка и последовательность.
Собери план + тексты в один документ.

6. Чего НЕ делать

❌ Не пиши «сделай сам» — orchestrator не пишет контент/код, он делегирует.
❌ Не мельчи («напиши заголовок») — давай задачу шире («сделай контент-план, пусть copywriter напишет заголовки»).
❌ Не указывай модель/температуру — это уже настроено.

7. Полезные команды в боте

/status — текущий профиль/сессия
/platforms — статус gateway
/cron — планировщик (там auto-update Hermes на 23:00 IRK)
/help — все slash-команды
/reset — сбросить контекст чата

8. Что уже настроено (не трогать)

Все роли на step-3.7-flash (StepFun), температуры 0.3–0.5
Память включена (orchestrator сохраняет факты о тебе)
Auto-update Hermes: каждый день в 23:00 IRK, отчёт в Telegram
Часовой пояс бота: Иркутск (+08:00)
Профили crypto-mentor и flora — не трогать
Профиль prompt — дубликат, оставлен (не удаляется из-за защиты Hermes)

Hermes Agent с открытыми и закрытыми агентами.

2026-05-27T00:57:12.150Z

Hermes Agent с открытыми и закрытыми агентами-специалистами цель состоит в том, чтобы со временем продвинуть открытых агентов до специалистов замкнутого цикла, вот что это значит:

Открытые агенты ..

> вы нужны в цикле для направления

> выполняйте разовые задачи

> требуйте подсказки для каждого действия

> полезно для создания прототипов рабочих процессов

> пример: вы просите его исследовать конкурентов, он возвращает данные, вы решаете, что делать дальше закрытые агенты..

> владеть конечным результатом от начала до конца

> работать автономно с четкими состояниями "готово"

> накапливать знания и со временем совершенствоваться

> работать в цикле обратной связи без постоянного контроля

> пример: вы говорите "исправить целевую страницу", она диагностирует проблему, внедряет исправление, тестирует его и отчитывается о прогрессе, который выглядит следующим образом: вы начинаете с открытого агента, выполняющего задачи вручную.

Вы запускаете его 5–10 раз, совершенствуя рабочий процесс на каждой итерации. Выявляются закономерности.

Вы закрепляете эти закономерности в виде навыков и целей.

В конце концов агент сможет выполнять весь процесс без вашего участия. На этом этапе он становится специалистом с замкнутым циклом.

Вместо того чтобы запрашивать каждое микродействие, вы можете давать указания высокого уровня, а закрытый агент выполнит весь рабочий процесс:

> создайте лид-магнит

> обновите аналитическую панель

> превратите эту идею в рабочий инструмент

> выясните, почему форма не работает.

Оркестратор перенаправит задачу нужному специалисту, и она будет выполнена. С каждой итерацией открытые задачи становятся все ближе к завершению.

Больше про агентов и нейросети вы можете прочитать на моеём канале

MAX-https://max.ru/id752703975446_biz

Телеграмм-https://t.me/Novopoltsev_Pavel

20. Управление агентами в режиме реального времени меняет подход к работе с искусственным интеллектом

2026-05-25T17:12:48.207Z

Одна из самых мощных функций Hermes — возможность управлять агентом в процессе выполнения задачи, не прерывая рабочий процесс полностью. Вместо того чтобы останавливать работу и начинать заново, пользователи могут корректировать направление, уточнять приоритеты или добавлять новый контекст, пока агент продолжает работать. Это позволяет организовать гораздо более естественный процесс совместной работы, приближенный к взаимодействию с коллегой-человеком, а не к выдаче отдельных подсказок.

Как управлять агентом Hermes в процессе выполнения задачи, не прерывая его работуНекоторые ИИ-помощники ведут себя странно, когда начинают работать.

Вы просите их проверить репозиторий, запустить тесты, устранить ошибку или провести исследование.

Но в середине пути вы кое-что замечаете:

он ищет не в той папке
слишком много внимания уделяется одному файлу
при этом было упущено важное ограничение
вы хотите, чтобы следующая задача была готова
вы не хотите прерывать его полностью

В большинстве инструментов есть два варианта:

Wait.
Or stop the agent.

Гермес предлагает третий вариант:

Steer the current run.

Вывод: Hermes позволяет управлять выполняемой задачей, не прерывая текущий цикл работы с инструментами.

Проблема с обычными прерываниями

Прерывание звучит просто.

Но в рабочих процессах с участием агентов прерывание процесса обходится дорого.

Если Hermes выполняет сложную задачу, возможно, у него уже есть:

проверенные файлы
запускайте тесты
запустил сервер
собранные журналы
сузил круг поисков
подготовил следующий вызов инструмента

Жесткое прерывание может нарушить этот поток. Иногда это необходимо.

Но зачастую нужно добавить только одно ограничение:

Focus on the auth module.
Do not edit files yet.
Check the failing test first.
Ignore the docs folder.
Use the Telegram gateway logs.

Для этого не обязательно прерывать весь процесс.

Вывод: не каждая поправка заслуживает точки в конце. Некоторые поправки следует делать в середине предложения.

Ключевая команда: /steer

В Hermes для этого есть команда со слэшем:

/steer <prompt>

Пример:

/steer focus on the gateway code, not the CLI

Что он делает:

Hermes ожидает завершения текущего вызова инструмента, а затем внедряет вашу заметку в текущий цикл агента.

>Это не первый поворот пользователя

>Это не принудительное прерывание

>Это толчок в середине забега.

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

Вывод: используйте /steer, когда Hermes работает, но вам нужно изменить направление, не сбрасывая импульс.

Когда использовать /steer

Используйте /steer для корректировки курса.

Хорошие примеры:

/steer only inspect files, do not modify anything yet

/steer the bug happens after suspend, focus on gateway reconnect logic

/steer skip frontend for now, the issue is probably in the API route

/steer if tests fail, capture the exact error before trying fixes

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

Вывод: /steer используется для того, чтобы подтолкнуть к выполнению текущей задачи, а не для того, чтобы начать новую.

Вторая команда: /queue

Иногда не хочется вообще ничего менять в текущей задаче.

Вам просто нужно выбрать следующую инструкцию.

Использование:

/queue <prompt>

Пример:

/queue after this, write a short summary of what changed

Команда /queue не прерывает текущий запуск.

Он ждет, пока Гермес закончит, а затем отправляет ваш запрос в очередь на следующий ход.

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

Вывод: используйте /queue, когда текущая задача выполнена и вы хотите подготовить следующую.

/steer vs /queue

Вот простое правило:

Use /steer to affect the current run.
Use /queue to affect the next run.

Примеры:

Текущая задача — отладка неудачного теста.

Использовать / управлять:

/steer inspect the test fixture before changing application code

Использование / очередь:

/queue once fixed, explain the root cause in 5 bullets

Один из них меняет текущий путь принятия решений агентом.

Другой планирует следующую инструкцию.

Вывод: /steer меняет направление. /queue определяет, что будет дальше.

Мощная команда CLI: /busy

В Hermes CLI есть еще одна функция:

/busy

Этот параметр определяет, что происходит при нажатии клавиши Enter, когда Hermes уже запущен.

Режимы включают в себя:

/busy queue
/busy steer
/busy interrupt
/busy status

Если вы установите:

/занятое управление

/busy steer

Таким образом, ввод текста во время работы Hermes по умолчанию становится управляющим сообщением.

Если вы установите:

/busy queue

Затем, пока Гермес занят, печатаю текст, чтобы освободить очередь.

Если вы установите:

/busy interrupt

Если печатать, пока Hermes занят, он сразу прервется.

Проверьте текущее поведение:

/busy status

Вывод: /busy позволяет выбрать стиль взаимодействия по умолчанию во время работы Hermes.

Моя рекомендуемая настройка

Для большинства технических процессов я бы использовал:

/busy steer

Почему?

Потому что самое распространенное действие во время бега — это не «остановиться».

Это «почти правильный курс».

Если Hermes запускает тесты, ищет файлы или просматривает журналы, вы можете ввести следующую команду:

look at the gateway logs too

А если в режиме управления выбран режим «занято», то это становится корректировкой в середине движения, а не случайным прерыванием или новым поворотом.

Для написания текстов я предпочитаю:

/busy queue

Потому что текущий черновик должен быть закончен, а следующую инструкцию я обычно добавляю в конец:

next make it punchier

Для выполнения рискованных системных операций используйте:

/busy interrupt

Так вам будет проще быстро остановиться, если Hermes собирается отправиться туда, куда вам не нужно.

Вывод: используйте steer для написания кода и отладки, очередь — для записи, прерывание — для рискованных операций.

Почему это так важно

Эта функция кажется небольшой.

Это не так.

Разница между игрушечным агентом и полезным оператором заключается не только в доступе к инструментам.

Это контроль.

Вам нужны способы, чтобы:

подталкивать без остановки
останавливайтесь, когда это необходимо
очередь будущей работы
проверять прогресс
Поддерживайте ориентацию агента во время выполнения длительных задач

Hermes рассматривает это как часть среды выполнения.

Это важно, потому что работа настоящего агента — дело непростое.

Редко когда все ограничения известны заранее.

Вывод: хороший пользовательский опыт для агента — это не только автономность. Это еще и управление.

Последняя мысль

Большинство людей считают, что под управлением агента подразумеваются подсказки. Hermes демонстрирует более совершенную модель.

Контроль — это не только то, что вы говорите перед началом забега. Это то, что вы можете делать во время забега.

Команды /steer, /queue и /busy превращают Hermes из чат-бота в оператора, которому можно давать указания в режиме реального времени.

Вот такая небольшая функция меняет подход к работе.

Павел AI

Мастер-класс по Hermes Desktop, часть 1: что такое Hermes Desktop

Hermes Agent по-прежнему является движком

На самом деле в ней есть три основных элемента

Так что же на самом деле запускается, когда вы открываете Desktop?

Рабочий стол, интерфейс командной строки, пользовательский интерфейс и панель управления — это не одно и то же

TUI

Веб-панель

Desktop

Один «Гермес», множество поверхностей

«Локальное» по умолчанию не означает «только локальное».

И нет, серверная часть Desktop — это не шлюз обмена сообщениями

Зачем вообще нужен Desktop?

Desktop может стать более функциональным, не заменяя Hermes Agent

Ментальная модель, которую следует сохранить

Официальные источники

Перевод на русский интерфейса Hermes agent DESCTOP.

1.Расширенные настройки, верхняя часть

2.Расширенные настройки, прокручено вниз

1. Память и контекст

2. Безопасность

3. Рабочее пространство

4. Внешний вид > Выбор питомца (Специальный макет)

5. Чат

6. Уведомления

7. Оплата

8. Провайдеры > Аккаунты (Развернутое меню)

9. Провайдеры > Пользовательские эндпоинты (Развернутое меню)

10. Шлюз

Подписывайтес ТГ канал

Агент Hermes только что узнал, как остановиться!

Когда «стоп» означало «подожди»

Исправление — это нечто большее, чем генерация изображений

Кроме того, существует проблема «зомби-результата»

«Стоп» должен становиться все более действенным по мере развития агентов.

🧭 Kanban-доска в Hermes Agent как я собрал управляемую команду агентов.

Что такое Hermes и зачем ему профили

Архитектура: три уровня multi-agent в Hermes

Уровень 1. Субагент через delegate_task

Уровень 2. Ручное переключение профилей

Уровень 3. Kanban-доска

6. Kanban: колонки, lifecycle, heartbeat, workspace и concurrency

Сортировка, или Triage

К выполнению, или Todo

Запланировано, или Scheduled

Готово к работе, или Ready

В работе, или In Progress

Done и полный lifecycle

Workspace и артефакты

Concurrency и очередь

Живой пример: t_9a60e2a9

7. Wu-Tang-профили: роли без путаницы

8. Что пошло не так

9. Что получилось

10. Следующие шаги

11. Заключение

12. Приложение: словарь и ссылки

Короткий словарь

Команды и адреса из переписки

Публичные ссылки

У вашего ИИ-агента деменция. Сделайте ему мозги.

Карпати был прав

Что я создал: Nexus

raw/ — неизменяемый исходный материал

wiki/ — синтезированные знания

ops/ + mocs/ — операционный уровень

Ежедневный операционный цикл

Who Gets to Touch What

Секретный ингредиент — проактивность

Самосовершенствование: прошлое → будущее

Проактивность: настоящее → будущее

Как создать свой собственный

Шаг 1. Инициализация Git в каталоге хранилища

Шаг 2. Создайте структуру папок

Шаг 3. Напишите файл SCHEMA.md

Шаг 4. Напишите index.md и log.md

Шаг 5. Напишите правила для агентов в .agents/

Завершающий удар

Многоагентная система Hermes.

Большинство «мультиагентных систем» это просто продвинутые групповые чаты

Уровень 1. Субагент через `delegate_task`

Живой пример: `t_9a60e2a9`

2. `loop-audit` (Аудит состояния)

3. `loop-cost` (Контроль расходов)

4. `loop-context` (Управление памятью и сжатие)

7. `loop-gate` (Человеческие ворота)