Как я превратил Codex в персонального Джарвиса

Эта статья написана от моего лица и отредактирована вместе с Джарвисом.

За последние годы я перепробовал много AI-инструментов для разработки: от более “чатовых” сценариев до агентных сред вроде Cursor и Claude. В итоге остановился на Codex. Не потому, что он магический, а потому что это, на мой взгляд, самая сильная система в тот момент, когда ты понимаешь, что именно она делает, где заканчиваются ее возможности и какими рамками ее нужно ограничивать.

До этого я очень долго, больше двух-трех лет, использовал ChatGPT напрямую. Для обучения ^[1], для размышлений, для разовых задач, для черновиков. Это удобно, но довольно быстро упираешься в одно и то же ограничение: персонализация живет только внутри текущего чата. Новый диалог почти всегда начинается с полузабывания. Контекст есть, но он локальный. Общей рабочей памяти ^[2] нет.

В какой-то момент мне стало интересно: а что будет, если перестать относиться к ИИ как к “очередному окну переписки” и собрать для него нормальную долговременную память ^[3]? Не в виде абстрактного second brain, а в виде системы, с которой действительно можно разговаривать и получать ответы с учетом моей жизни, привычек, целей и текущих проектов.

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

Так появился мой личный ассистент – Jarvis.

Важно: это не “обученная заново модель” и не какой-то секретный AGI. Это обычный агент, вокруг которого построена управляемая память. Но именно этот слой памяти и правил внезапно меняет все.

Почему обычного чата стало мало

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

• он неплохо отвечает в моменте, но плохо живет во времени;

• он помнит куски разговора, но не поддерживает нормальную структуру знаний;

• он не различает достаточно четко факты, временные заметки, гипотезы, предпочтения и историю изменений;

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

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

Мне хотелось получить систему, которая:

1. сначала извлекает контекст;

2. потом отвечает;

3. при необходимости сама обновляет память;

4. не превращает эту память в свалку.

Почему я не пошел сразу в векторные базы

Когда слышишь “долговременная память для ИИ”, рука сама тянется к словам RAG, embeddings, vector DB, GraphRAG и так далее.

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

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

• человекочитаемы;

• легко версионируются через Git;

• не прячут знания за “магическим” retrieval;

• вынуждают думать о структуре, а не только о поиске;

• нормально переживают ручную редактуру и пересборку.

Иными словами, в моем случае важнее оказалось не “умно искать по всему”, а грамотно организовать иерархию, снять лишнюю неоднозначность и прописать правила поведения ^[4] агента.

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

Как устроен Jarvis

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

Примерно так:

profile/       — стабильная информация обо мне
areas/         — основные сферы жизни: работа, здоровье, обучение, дом
events/        — хронология и важные изменения
preferences/   — вкусы, ограничения, паттерны, способы работы
roles/         — режимы ответа под разные задачи
skills/        — локальные процедуры и правила
my-notes/      — короткие заметки и временные фиксации
assets/        — источники: книги, Telegram-архивы, внешние индексы
inbox/         — сырые, еще не нормализованные штуки

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

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

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

Почему здесь важны роли и скиллы

Следующий слой после памяти — специализация.

Jarvis умеет переключаться в разные режимы. Условно говоря, сегодня это не просто “один чат-бот”, а несколько рабочих ролей поверх одной и той же памяти:

• учитель английского;

• оператор для рутинных процедур;

• контекстный помощник по жизни;

• аналитик, когда нужно разложить проблему;

• wellness-режим для спорта, питания и восстановления.

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

Грубо говоря, если в памяти уже есть, что меня интересуют рабочие сценарии, IT-контекст или даже потенциальная миграция во Вьетнам, то и объяснения становятся ближе к реальной жизни, а не к учебнику из вакуума. А для меня это особенно важно: мне всегда проще учиться и принимать решения там, где контекст назван и рамка понятна.

AnkiConnect и другие полезные кейсы

Один из самых практичных сценариев — английский.

Я давно понял, что просто “обсуждать английский” мало. Нужен нормальный operational memory. Поэтому связка устроена так:

• репозиторий хранит структуру обучения, уже пройденные темы и правила;

• Anki через AnkiConnect хранит оперативную память для слов, фраз и карточек;

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

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

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

• раз в день смотреть акции в продуктовых сетях и предлагать бюджетный mass-gain рацион;

• раз в неделю пересобирать спортивный план под текущую нагрузку;

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

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

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

То есть память — это только половина системы. Вторая половина — автоматизации и плановые запуски.

Telegram как источник памяти

Отдельный пласт — это загрузка Telegram.

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

На текущем этапе в памяти лежат архивы, которые суммарно дают уже почти 300 тысяч сообщений и больше 3 тысяч голосовых. Причем важен не только сам объем. Важнее то, что это не просто dump ради dump:

• голосовые расшифровываются;

• сообщения индексируются по годам;

• по ним обновляются карточки людей и общие синтезы;

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

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

Самая важная часть: система должна уметь поддерживать себя

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

Jarvis полезен не потому, что “знает обо мне много”, а потому что:

• понимает, куда записывать новые факты;

• различает временные заметки и устойчивый контекст;

• обновляет хронологию, когда время важно;

• старается не плодить дубли;

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

Это не самообучение в смысле переобучения весов. Скорее это самонакапливающаяся рабочая модель, где со временем улучшаются не параметры LLM, а качество памяти, именование сущностей, точность маршрутизации и предсказуемость поведения ^[5].

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

Подводные камни

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

Во-первых, память легко превратить в свалку, если писать туда все подряд.

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

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

В-четвертых, у системы появляется новая обязанность: ее нужно не только наполнять, но и периодически нормализовывать. Иначе через несколько месяцев ты получишь не память, а digital attic.

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

Что будет дальше

Следующий шаг для меня уже не только в личной памяти.

Параллельно развивается более крупная инженерная система: pet-проект, который постепенно превращается в большую платформу на микросервисной архитектуре. Там уже появляются полтора десятка сервисных контуров на Go, несколько frontend-приложений, отдельный observability-слой с Grafana, Loki, Prometheus, событийная шина, распределенные базы и довольно жесткие инфраструктурные правила.

И самое интересное, что для программирования там тоже используется не один “универсальный AI”, а целый штат IT-искусственного интеллекта ^[6].

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

Мне нравится такая метафора: каждый сабагент — это как осьминог в отдельном аквариуме. Он может быть очень умным и полезным внутри своего объема воды, но не может вылезти наружу и начать хаотично трогать все вокруг. За счет этого ошибки ^[7] хотя бы замыкаются в конкретной области, а не размазываются по всей системе. Это, по сути, тот же принцип, что и во всей статье: сложность становится терпимой, когда у нее есть границы.

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

Мне кажется, именно в эту сторону все и движется: не один “суперумный ИИ”, а набор агентов с памятью, ролями, рамками, маршрутами и контролируемой средой. Чем сильнее система, тем важнее не свобода, а правильно спроектированные ограничения.

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

• как устроена сама память и правила ее нормализации;

• как организованы роли и автоматизации;

• как выглядит мультиагентная разработка в большом pet-проекте;

• почему ограниченные сабагенты часто надежнее, чем один “всемогущий” агент.

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

И, пожалуй, здесь есть еще одно правило, которое для меня принципиально. Такая система должна обладать минимальной стоимостью обслуживания. Если каждый новый слой памяти, автоматизаций и ролей требует все больше ручного внимания ^[8], значит архитектура выбрана неудачно. В идеале все должно двигаться в другую сторону: со временем система должна становиться не тяжелее в поддержке, а легче, постепенно трансформируясь в самообслуживаемую и саморазвивающуюся среду.