Self-Evolving Knowledge: Как взрастить senior агента

Привет! Я не AI-инженер, у меня нет ML образования. Я проджект-менеджер со старым бекграундом в качестве веб-разработчика и с опытом более 10 лет в управлении командами разработки ПО. И с приходом полноценных AI-агентов я стал по выходным заниматься экспериментами на своих пет-проектах. 

Один из таких проектов – мобильное приложение для запоминания карточек/слов: я учу японский язык и не нашёл ни одного сервиса, в котором добавлять новые слова в словарь было бы не мучительно, поэтому решил сделать своё, для себя. Что ж, для этого у меня не было GPU-кластера и команды, но был MacBook, свободное воскресенье и конкретная проблема, которую я хотел решить.

Ниже я опишу свои наблюдения с точки простого PM’a, и вытекающую ​идею и концепт.

wikiLLM

Не так давно я наткнулся на описанную идею Andrej Karpathy о wikiLLM – держать знания в структурированной wiki, которую агент читает, пополняет за счет сырых данных и использует в ответах. Логика простая и красивая: дай агенту хорошо организованную базу знаний, и он будет работать точнее. Я попробовал. По крайне мере так, как я это понял. И в начале было отлично. Я распотрошил свою главную .md инструкцию, и структурировал все основные моменты по папкам в wiki/. Но самое интересное наблюдение пришло потом…

Как проджект-менеджер, я привык подмечать “лишнее” и “недостающее”. И тут не исключение. Wiki я собрал, но она не росла и агент не становился “лучше”. Почему? Очевидно же! Потому что я не отдавал агенту сырых данных, кроме стартового периода, следовательно, его знания не росли. Они могли немного прибавляться в моменте за счет веб-поиска, но на том все.

Как же так получилось?

Это не история о том, что wikiLLM плохой подход – Andrej Karpathy уж точно умнее меня =) Просто мои требования от агента не полностью подходили под этот метод (по крайней мере насколько я понял этот метод). У меня нет потока сырых данных, которые можно было бы разбить на статьи в классическом понимании. Мои сырые данные – это гипотезы, концепты, запросы и баги. Мне нужен был не библиотекарь, а разработчик, который закрывает мои продуктовые задачи. Я пишу ему: «сделай кнопку…» или «здесь баг…» – и он должен решить это, опираясь на контекст нашего конкретного проекта. И было бы прекрасно, если в будущем он не будет делать похожие баги в аналогичных или специфических кейсах.

При WikiLLM-подходе я начал вручную добавлять в базу всё, что считал важным. Правила – в wiki. Выученные уроки – в lessons-learned.md. Критические вещи – дублировал ещё раз прямо в CLAUDE.md, «чтобы точно знал». Через три месяца: CLAUDE.md на 7,000 токенов, и агент, который всё равно повторял ошибки, которые мы уже разбирали.

Проблема была не в контенте. Проблема была в том, кто должен его создавать.

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

Тот самый момент

Я работаю с разработчиками уже много лет. Когда в команду приходит junior, я не выдаю ему 200-страничный документ «всё, что нужно знать». Он учится на задачах – и, я считаю, что ключевой момент обучения почти всегда один и тот же: неожиданность.

Он пишет код, натыкается на поведение, которого не ожидал. Баг. Edge case. Недокументированное ограничение API. Именно в этот момент формируется настоящее знание – не из документации, а из живого опыта. К концу года у него в голове десятки таких кейсов, и уже именно они делают его ценным специалистом.

Это и оказалось ответом на мой вопрос: а что если агент сам создаёт себе сырой контекст в моменты неожиданностей?

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

Именно так растёт junior в senior. Не через изучение документации, а через накопленный опыт реальных задач. Ну что, ответ есть! Осталось только смоделировать этот процесс.

Концепция SEK

Так появилась концепция, которую для себя я обозначил как Self-Evolving Knowledge (SEK).

Здесь помог мой PM-бэкграунд. Я привык думать категориями «кто за что отвечает» и «как выстроить процесс так, чтобы он работал без ручного управления». Фреймворк junior→senior – это не метафора. Я попробовал буквально смоделировать онбординг нового члена команды.

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

main_instruction.md разбухает. Чтобы агент гарантированно следовал правилу, его дублируют прямо в инструкцию. Через полгода там оседает копия половины wiki – «на всякий случай». 7,000 токенов при старте каждой сессии, независимо от задачи – проще простого.

Знания дублируются. В lessons-learned.md записан «выученный урок». В wiki/rules/ – «правило». Это одна и та же истина в двух местах. Агент путается, какое из них актуальнее.

Токенный налог растёт линейно. Каждая новая страница, добавленная в «обязательный» список, увеличивает стоимость старта. Через год агент тратит 30-40% контекстного окна ещё до первого сообщения.

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

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

SEK меняет именно это.

Архитектура

SEK организует знания в четыре уровня контекста по принципу «грузи только то, что нужно прямо сейчас».

L0 – Bootstrap (всегда в контексте)

Это моя главная инструкция – он же CLAUDE/AGENTS/GEMINI и прочие подобные .md. Но радикально сжатая.

Цель – уместить в максимально малое количество токенов всё необходимое для старта:

1. Кто я и каким языком отвечаю

2. Какие категории знаний у меня есть

3. По каким триггерам что загружать

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

Что исчезает из main_instruction.md: 

• всякое «What NOT to Do», 

• развёрнутые описания каждой wiki-страницы, inline-правила – всё это выносится в wiki/rules/ и грузится по триггеру.

L1 – Routing & Index (по необходимости)

wiki/_routing.md – полная таблица маршрутизации в YAML-формате. Агент читает её, если задача не покрыта ядром из main_instruction.md.

triggers:
  - id: frontend
    keywords: [react, frontend, ui, component, tsx, jsx]
    load:
      - wiki/design/design-system.md
  - id: llm-cost
    keywords: [pricing, calc_cost, тариф, стоимость]
    load:
      - wiki/references/llm-pricing.md

YAML здесь – самый дешёвый и точный формат для машинного разбора «keywords → files», который при этом остаётся читаемым для человека.

wiki/_index.md – оглавление: путь файла + одна строка описания. Около 200-300 токенов. Резервный уровень, если routing не дал результата.

Большие файлы (design-system, edge-cases) не исчезают – они перестают грузиться «на всякий случай». Качество ответов по этим темам не падает: файл загружается только когда нужен.

L2 – Validated knowledge (по триггеру)

Вся экспертиза проекта: wiki/rules/, wiki/references/, wiki/architecture/, wiki/workflows/. Грузится только когда задача явно касается темы.

Каждое правило получает уникальный ID-тег ([XXX-001], [YYY-ASYNC]). Перед добавлением нового правила агент делает grep – не пишет то же самое дважды.

L3 – Ephemeral state (где рождаются новые знания)

А вот тут самое важное – механизм “самообучения”.

memory/inbox.md – это не архив уроков. Это конвейер.

Неожиданность (баг, workaround, скрытое поведение API)
        ↓
REGISTER → memory/inbox.md (3 строки на запись)
        ↓
PROMOTE → wiki/rules/ или wiki/references/
        ↓
Удаление из inbox

Агент пишет в inbox сам – без моего участия. Существуют четыре триггера для записи: неожиданное поведение системы, найденный workaround, недокументированное поведение API, явная поправка с моей стороны. Ровно те же ситуации, в которых junior-разработчик делает пометку «запомнить».

Жёсткий лимит – я выбрал 20 записей. Старше N дней без подтверждения – удаляются автоматически. Inbox не разрастается, он всегда остаётся ephemeral.

draft → validated → core

Каждое знание проходит три стадии зрелости.

Promote draft → validated агент делает автономно. Если та же тема встречается повторно, или 3+ записи на одну тему – кандидат на promote. Перед записью идет grep по существующим rules. После – одна строка в ответе: 📚 Promoted: [TAG] → wiki/rules/Y.md.

Promote validated → core требует явного «да» от меня. Агент может предложить: «Правило [TAG] встречается в 5+ задачах за месяц. Промоутить в Critical Rules?» – но main_instruction.md не редактируется автономно. Это асимметричная защита: низкий порог входа (пишет охотно), высокий порог для core (только с разрешения).

main_instruction.md – конституция. Агент её не переписывает.

Защита от ошибок. Если правило промоутировано менее 7 дней назад и впервые применяется – агент сигнализирует: 🆕 Using recently promoted: [TAG]. Если поведение не совпадает - /revoke [TAG]. Команда /revoke удаляет запись из wiki/ и логирует отзыв. Ничего не пропадает бесследно.

Junior → Senior

Вот как примерно мог бы выглядеть рост агента на одном и том же проекте:

Переход не нужно стимулировать. Он происходит сам – по мере того как агент работает с проектом и ведёт цикл REGISTER → PROMOTE. Модель та же. Меняется только корпус знаний.

Как PM я видел этот паттерн десятки раз с людьми. Разница между junior и senior – не в интеллекте и не в инструментах. В накопленном, структурированном опыте реальных задач. SEK переносит эту же механику на агента.

Вы не апгрейдите железо. Вы нанимаете специалиста и даёте ему время вырасти.

Что меняется?

SEK – это не переписывание с нуля.

Не меняется: структура папок (wiki/, memory/), логика категорий (rules, references, services), содержание существующих файлов, git history, все runtime.

Меняется: что загружается в контекст агента, в каком порядке, и – главное – кто создаёт новые знания. Не только вы. Агент тоже.

Что дальше?

Я продолжу копать и исследовать организацию контекста. Даже несмотря на то, что Anthropic недавно выпустили в релиз собственную “память” для агента =)

Что хотел бы зафиксировать в статьях:

• Сравнение с wikiLLM Карпати – честный разбор по 10 осям: где подходы совпадают, где расходятся и тп

• Что нового в SEK (в теории) – не считаю, что это какая-то революция, все подходы в том или ином виде уже существовали

• Lint Protocol – как агент проверяет качество знаний перед promote и не плодит мусор в wiki (я надеюсь, что не плодит)

Aleksei Panin – Senior Project Manager → Начинающий AI практик.