Дневник разработки Ассистента Афина. Часть 3. Копия Hermes или собственный путь?

Часть 1:

Часть 2:

«Офигеть, целая серия постов об изобретении Hermes».

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

Признаюсь, до этого момента я даже не знал о существовании Hermes Agent.

Я начал разрабатывать Афину 30 сентября 2026 года, исходя из собственного представления о том, каким должен стать персональный ИИ-ассистент. Я не начинал проект с изучения Hermes и не строил AthenaCore на его основе.

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

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

Я познакомился с Hermes Agent, изучил доступные материалы и сравнил его подход с архитектурой, которую мы постепенно создаём в рамках AthenaCore.

Результат оказался интереснее, чем я ожидал.

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

Чтобы объяснить почему, сначала нужно разобраться, что именно я хочу создать.

Моя цель с самого начала заключалась не в создании ещё одного чат-бота с набором инструментов.

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

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

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

Так постепенно формировалась архитектура AthenaCore.

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

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

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

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

Именно на этом этапе я нахожусь сейчас: фундамент постепенно обретает форму, но впереди ещё много работы.

Hermes Agent — открытый агентный проект от Nous Research, ориентированный на выполнение задач с использованием языковых моделей, инструментов, памяти и навыков.

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

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

Здесь я увидел пересечение с собственным замыслом Афины.

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

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

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

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

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

В Hermes меня заинтересовал подход к разделению памяти и навыков.

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

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

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

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

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

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

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

Именно здесь сравнение с Hermes оказалось особенно полезным.

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

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

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

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

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

Предполагаемый процесс выглядит так:

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

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

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

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

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

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

В описании Hermes меня заинтересовал ещё один аспект — организация изолированного выполнения задач.

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

Но здесь важно различать две вещи.

Изоляция выполнения и проверка качества навыка — не одно и то же.

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

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

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

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

Этот механизм ещё предстоит полноценно реализовать и проверить. Но принцип уже определён: создание навыка, его проверка и разрешение на применение — отдельные этапы, которые нельзя объединять в одно действие.

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

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

Для меня это один из центральных вопросов всей архитектуры AthenaCore.

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

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

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

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

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

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

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

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

Модель в этой системе — важный вычислительный ресурс, но не единственный источник решений и истины.

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

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

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

Это тоже важная часть моего замысла.

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

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

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

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

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

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

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

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

Ещё одно направление, которое я считаю важным для Афины, — восприятие окружающей среды.

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

Для начала Афина должна получать сведения о рабочем окружении: активных окнах, приложениях и значимых изменениях состояния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не означает, что все эти проблемы автоматически отсутствуют в AthenaCore. Некоторые решения ещё предстоит спроектировать и реализовать.

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

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

Эту часть архитектуры всё равно придётся последовательно создавать, проверять и совершенствовать в рамках AthenaCore.

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

После знакомства с Hermes мой ответ не изменился, но стал более осознанным.

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

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

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

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

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

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

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

Только после этого можно будет судить, насколько хорошо задуманная архитектура работает на практике.

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

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

И если в результате Афина станет надёжнее, экономнее и полезнее, значит, это знакомство уже принесло пользу.

Разработка продолжается.

И Афина :)