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

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

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

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

-Писатель.

-Рецензент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все просто.

Чистота.

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

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

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

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

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

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

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

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

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

Но зачем?

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

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

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

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

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

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

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

Архитектура — это владение.

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

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

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

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

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

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

Тогда у вас есть рой.

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

Рои отлично подходят для:

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

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

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

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

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

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

-Инженере.

-Писателе.

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

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

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

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

В моей системе эта роль принадлежит 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 навыками, которые действительно нужны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не тема.

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

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

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

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

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