Серия «Дневник разработки Ассистента Афина»

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

Отдельные модули — ещё не настоящий ассистент

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

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

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

Общая схема выглядит примерно так:

Пользователь → понимание задачи → анализ контекста → выбор инструментов → выполнение → проверка результата → сохранение опыта.

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

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

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

Память: что происходит после перезапуска?

Одной из важных задач стало сохранение состояния Афины.

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

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

• Рабочая память — информация, необходимая для текущей работы.

• История диалога — предыдущие обращения и решения.

• Долговременная память — сведения, которые должны сохраняться между сеансами.

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

Важно не просто записать эти данные на диск. Нужно уметь восстановить их и правильно продолжить работу.

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

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

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

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

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

Проверка сохранности данных

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

%LOCALAPPDATA%\AthenaCore\assistants\athena\

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

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

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

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

488 пройденных тестов — но это ещё не первый запуск

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

488 тестов пройдены за 15,48 секунды.

Отдельно я запустил пять групп проверок, связанных с контекстом, долговременной памятью, SQLite, выполнением задач и восприятием окружения. Результат — 37 пройденных тестов за 4,91 секунды.

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

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

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

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

Афина начинает воспринимать рабочее окружение

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

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

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

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

Сейчас реализована и проверена основная последовательность:

1. Получение сведений об окнах и приложениях.

2. Формирование наблюдений, в том числе в фоновом режиме.

3. Обнаружение изменений.

4. Передача информации в Runtime и контекст ассистента.

5. Оценка того, требуется ли реакция.

6. Передача внутренней инициативы в пользовательский интерфейс.

7. Сохранение состояния и восстановление контекста.

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

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

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

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

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

По мере развития проекта я пришёл к ещё одному важному архитектурному решению: необходимо отделить общее ядро от конкретного ассистента.

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

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

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

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

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

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

Саморазвитие: не бесконтрольное изменение кода

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

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

Более интересен другой подход.

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

Дальше предполагается следующий цикл:

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

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

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

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

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

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

А что насчёт самой Афины?

Параллельно с технической архитектурой развивается и визуальная концепция ассистента.

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

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

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

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

А окончательное решение о применении таких изменений останется за человеком.

Что дальше?

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

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

Для этого предстоит:

• Провести полный рабочий цикл с реальной моделью.

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

• Убедиться, что действия действительно выполняются, а результаты проверяются.

• Проверить сохранение опыта и его использование в последующих задачах.

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

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

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

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

Вместо заключения

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

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

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

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

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

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

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

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

И Афина)

С чего всё началось

До AthenaCore у меня уже был собственный проект — TaskTimer . В процессе работы над ним я пришёл к идее, которая со временем перестала помещаться в рамки обычного приложения.
Ссылка на проект TaskTimer: https://github.com/mrTomny/TaskTimer

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

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

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

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

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

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

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

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

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

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

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

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

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

Отдельное ядро — AthenaCore

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

Так появился AthenaCore.

Если объяснять упрощённо, AthenaCore — это общая архитектура, а Афина — конкретный ассистент, который на её основе получает собственную память, опыт, характер взаимодействия и набор развиваемых способностей.

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

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

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

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

Как Афина должна работать

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

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

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

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

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

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

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

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

Память — это ещё не обучение

Одна из следующих задач — научить Афину полноценно использовать прошлый опыт.

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

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

Для меня важно другое: прошлый опыт должен влиять на будущие решения.

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

В перспективе я хочу прийти к циклу:

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

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

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

Афина не должна требовать дорогой компьютер

Ещё один принцип проекта — возможность работы на разном оборудовании.

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

Я хочу, чтобы архитектура учитывала не только мощные компьютеры с производительной видеокартой, но и более скромные конфигурации: системы без дискретного GPU, компьютеры с 8 ГБ оперативной памяти и даже машины, где вместо быстрого SSD используется обычный HDD.

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

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

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

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

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

Самое интересное — возможность развивать собственные навыки

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

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

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

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

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

В идеале процесс будет выглядеть так:

1. Афина обнаруживает, что ей не хватает определённой способности.

2. Анализирует проблему и предлагает вариант решения.

3. Подготавливает эксперимент в изолированной среде.

4. Проверяет результат по заранее определённым критериям.

5. Показывает пользователю, что изменилось и какие результаты получены.

6. Запрашивает разрешение на применение проверенного улучшения.

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

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

Где проект находится сейчас

На данный момент я занимаюсь фундаментом AthenaCore.

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

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

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

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

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

Зачем я веду этот дневник

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

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

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

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

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

Ответы на эти вопросы и станут частью дальнейшего дневника.

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

Это первая запись. Дальше — разработка.

Ну и небольшие Концепты Афины)

Если кто-то захочет поддержать проект буду благодарен)