Самоадаптивна система знань: Як виростити senior-агента
Як проджект-менеджер із досвідом роботи понад 10 років, я завжди цікавився питаннями штучного інтелекту та машинного навчання. З появою повноцінних AI-агентів я почав експериментувати зі своїми пет-проектами на вихідні. Одним із таких проектів було мобільне додаток для запам’ятовування карток/слів, яке я створював для вивчення японської мови.
Під час роботи над цим проектом я відкрив для себе цікаву ідею wikiLLM від Andrej Karpathy. Ідея полягала в тому, щоб зберігати знання в структурованій wiki, яку агент читає, поповнює за рахунок сирих даних і використовує у відповідях. Логіка була простою та гарною: надайте агенту добре організовану базу знань, і він працюватиме точніше.
Проте, коли я почав використовувати цей підхід, я зіткнувся з деякими проблемами. Мої вимоги до агента не повністю підходили під цей метод. Мені потрібен був не бібліотекар, а розробник, який закриває мої продуктові завдання. Я писав йому: «зроби кнопку…» або «тут баг…» – і він повинен був вирішити це, спираючись на контекст нашого конкретного проекту.
Тоді я задумався: а що якщо агент сам створює собі сирий контекст у моменти несподіванок?
Відкриття
Як проджект-менеджер, я звик підмічати «зайве» та «недостаюче». І тут не виняток. Я зрозумів, що агент не стає «кращим», якщо йому не надавати сирих даних. Але що якщо агент сам створює собі сирий контекст?
Відповідь на це питання стала концепцією, яку я назвав Self-Evolving Knowledge (SEK).
Архітектура SEK
SEK організує знання в чотири рівні контексту за принципом «завантажуй тільки те, що потрібно зараз».
L0 – Bootstrap (завжди в контексті)
Це моя головна інструкція – вона ж CLAUDE/AGENTS/GEMINI та інші подібні .md. Але радикально стиснута.
Мета – вмістити в мінімальну кількість токенів усе необхідне для старту:
- Хто я і яким мовою відповідаю
- Які категорії знань у мене є
- За якими триггерами що завантажувати
L1 – Routing & Index (за необхідністю)
wiki/_routing.md – повна таблиця маршрутизації у форматі YAML. Агент читає її, якщо завдання не покрито ядром із main_instruction.md.
wiki/_index.md – зміст: шлях файлу + одна строка опису. Близько 200-300 токенів. Резервний рівень, якщо маршрутизація не дала результату.
L2 – Validated knowledge (за триггером)
Уся експертиза проекту: wiki/rules/, wiki/references/, wiki/architecture/, wiki/workflows/. Завантажується тільки коли завдання явно стосується теми.
L3 – Ephemeral state (де народжуються нові знання)
Тут найважливіше – механізм «самонавчання».
memory/inbox.md – це не архів уроків. Це конвеєр.
Від Junior до Senior
Ось як приблизно міг би виглядати ріст агента на одному й тому ж проекті:
| Стадія | wiki/rules | memory/inbox | Поведінка |
|---|---|---|---|
| Junior (старт) | 5-10 core-rules | пусто | Частіше питає, лізе в web-docs, рідко посилається на внутрішні правила |
| Middle | 20-40 validated rules | 5-10 свіжих спостережень | Упевнено посилається на rules, впізнає патерни, рідше web-search |
| Senior | 60+ rules + хрестові посилання | inbox майже пустий | «Це [TAG]-кейс, див. rule X», пропонує архітектурні рішення |
Що змінюється?
SEK – це не переписування з нуля.
Не змінюється: структура папок (wiki/, memory/), логіка категорій (rules, references, services), зміст існуючих файлів, git history, всі runtime.
Змінюється: що завантажується в контекст агента, у якому порядку, і – головне – хто створює нові знання. Не тільки ви. Агент теж.
Підсумки
SEK – це не нова модель, не файнтюн і не дорогий інструмент. Це інший погляд на те, хто створює знання для агента і як вони накопичуються.
Агент може не бути розумнішим – він повинен знати більше про ваш конкретний проект. Це знання народжується не з документації, а з живого досвіду: сюрприз → черновик → правило. Рівно так, як росте будь-який спеціаліст.
Що далі?
Я продовжу досліджувати організацію контексту. Навіть незважаючи на те, що Anthropic нещодавно випустив у реліз власну «пам’ять» для агента =)