Автор: Редакция Comb
Как превратить письма, встречи, документы и результаты работы AI-агентов в память, которая не исчезает между сессиями.
Содержание статьи Агент каждый раз начинает почти с нуля
Как выглядит память клиента
Что именно мы называем памятью
Три слоя LLM Wiki
Главная проблема памяти - она может ошибаться
Claims + Evidence
Память должна уметь устаревать
Три базовые операции
Маленькая Wiki может быть просто папкой
Значит ли это, что RAG больше не нужен?
LLM Wiki - не источник истины
Почему Markdown оказался таким удобным
Что происходит, когда Wiki становится слишком большой
На большой Wiki самой Wiki нужен retrieval
Память может быть большой. Контекст должен быть маленьким
Практическая рамка Comb: память агента, отдела и компании
Не обязательно делать три отдельные Wiki
Знание поднимается по уровням
И движется обратно
Зачем уровни памяти нужны ещё и для скорости
А где здесь онтология?
А где здесь Skills?
А где здесь AGENTS.md?
Как это работает на задаче «Север»
От идеи Карпаты к работающим реализациям
Паттерн уже становится форматом: Open Knowledge Format
Что нужно для корпоративной версии
С чего начать пилот
Антипаттерны
Четыре слоя AI-компании
Память как новый программный слой компании
Вместо заключения
AI-агент может иметь доступ к CRM, почте, базе знаний, телефонии и тысячам документов.
Но доступ к информации ещё не означает память.
Допустим, мы просим агента:
Подготовь обновлённое предложение для клиента «Север».
Чтобы сделать это нормально, ему нужно понять:
что сейчас происходит с клиентом;
о чём договорились на последних встречах;
почему было принято текущее решение;
какие варианты уже обсуждали;
кто принимает решение;
какие вопросы остались открытыми.
Вся эта информация может существовать. Но лежать в 217 письмах, 14 транскриптах звонков, CRM, договоре, старых коммерческих предложениях и задачах сотрудников.
Каждый новый запуск агента превращается в небольшое расследование.
LLM Wiki предлагает сохранять результат этого расследования.
Агент не только находит информацию и выполняет задачу. Он постепенно собирает и поддерживает структурированное представление того, что компания уже знает.
Так появляется долговременная память.
Материал продолжает серию Comb об архитектуре корпоративных AI-агентов: онтология компании задаёт модель мира, Agent Skills описывают способы работы, а AGENTS.md — правила использования этих слоёв.
01 Агент каждый раз начинает почти с нуля
Большинство систем работы LLM с корпоративными данными строится примерно так:
Документы ↓ индексация ↓ поиск ↓ релевантные фрагменты ↓ LLM ↓ ответ
Это хорошо работает для поиска.
Но если для ответа нужно соединить десятки событий за несколько месяцев, агент каждый раз повторяет значительную часть работы:
найти ↓ прочитать ↓ сопоставить ↓ разобраться в противоречиях ↓ восстановить контекст ↓ сделать вывод
Следующий запрос - и значительную часть этой цепочки приходится проходить снова.
4 апреля 2026 года Андрей Карпаты опубликовал идею LLM Wiki - паттерн для создания базы знаний, которую LLM сама собирает и поддерживает. Он специально описал это как idea file , а не готовый продукт: документ можно передать Codex, Claude Code или другому агенту и вместе с ним собрать реализацию под свою задачу.
Главная идея проста: между сырыми источниками и агентом появляется постоянный слой структурированных знаний.
Сырые источники ↓ обработка ↓ LLM Wiki ↓ AI-агент
Новый источник не просто индексируется. Агент читает его, извлекает важное и встраивает новое знание в уже существующую картину.
Карпаты называет Wiki persistent, compounding artifact - постоянным артефактом, ценность которого накапливается по мере работы.
Главное отличие именно в этом:
результат предыдущего понимания не исчезает после завершения диалога.
Исходный паттерн и его архитектура описаны в первичном gist Карпаты. 1
Raw → LLM Wiki → рабочий контекст → агент
Письма Договорённости и решения
Встречи Разговоры и открытые вопросы
Документы Условия и обязательства
CRM Состояние клиента и сделки
Звонки Контекст переговоров
LLM Wiki Связанное знание Клиент
Проект
Решение
Контекст
Рабочий контекст Только нужные страницы
AI-агент Продолжает с уже собранного знания
Агент не перечитывает всю историю с нуля — он начинает с уже собранного знания.
02 Как выглядит память клиента
Вернёмся к «Северу».
В первичных системах находятся:
217 писем 14 звонков CRM договор 3 коммерческих предложения задачи данные 1С
А в Wiki может существовать страница:
# Север
## Текущий статус
Основная спецификация согласована. Ожидается подтверждение двух позиций.
## Последние договорённости
21 августа согласовали базовую цену. Клиент ожидает поставку до 15 сентября.
## Открытые вопросы
- сертификат на A-17; - подтверждение остатка B-42.
## Участники
Иван Петров - закупки. Анна Соколова - договор.
## Следующее действие
Получить подтверждение склада и отправить обновлённое предложение.
## Связанные страницы
- [[Договор Север 2026]] - [[Иван Петров]] - [[Поставка A-17]]
Это уже не архив документов.
И не ещё одно резюме встречи.
Это текущее понимание ситуации .
Завтра пройдёт новая встреча - агент обновит страницу. Через неделю появится новая договорённость - обновит снова. Появится новый участник - создаст страницу человека и свяжет её с клиентом.
Wiki постепенно становится живой картой того, что компания знает.
03 Что именно мы называем памятью
Здесь полезно разделить четыре похожих понятия.
Состояние
То, что прямо сейчас хранит операционная система.
Сделка: этап = согласование договора
Источник такого состояния - CRM.
Факт
Что-то произошло или было зафиксировано в первичном источнике.
27 августа клиент написал:
«Бюджет проекта не должен превышать 5 млн рублей».
Источник - конкретное письмо.
Знание
Вывод, который можно получить из одного или нескольких фактов.
Цена является одним из главных ограничений проекта клиента.
Это уже результат синтеза.
Память
Накопленная история, которая помогает понимать ситуацию дальше.
За последние три месяца мы трижды меняли конфигурацию предложения из-за ограничения бюджета.
CRM хорошо хранит состояние.
Документы хорошо хранят факты.
LLM Wiki особенно полезна для накопленного знания и контекста, полученных в результате предыдущей работы.
Четыре понятия · четыре разных роли
01 Состояние CRM Сделка на согласовании
02 Факт Письмо Бюджет не выше 5 млн
03 Знание Синтез Цена — ключевое ограничение
04 Память История Три пересборки КП из-за бюджета
Операционные системы хорошо хранят состояние и факты; Wiki особенно полезна для синтезированного знания и истории.
04 Три слоя LLM Wiki
В исходном паттерне Карпаты есть три слоя:
Raw ↓ Wiki ↓ Schema
У каждого своя роль.
1. Raw - первичные источники
Это:
письма транскрипты PDF договоры отчёты записи звонков исследования выгрузки
Карпаты предлагает относиться к ним как к неизменяемым источникам истины для Wiki: агент читает их, но не переписывает.
Для корпоративной системы это принципиально.
Если Wiki говорит:
Клиент согласовал скидку 7%.
мы должны иметь возможность спросить:
На основании чего?
И вернуться к письму, звонку, договору или другому первичному источнику.
2. Wiki - собранное знание
Это рабочий слой памяти.
Например:
wiki/
clients/ sever.md vostok.md
people/ petrov.md sokolova.md
projects/ warehouse.md
products/ a17.md
concepts/ discount-policy.md
После встречи с клиентом агент может одновременно обновить:
Север Договор Север Иван Петров Поставка A-17
Именно поэтому Wiki отличается от папки с автоматически созданными саммари.
Знания не раскладываются по документам. Они собираются вокруг объектов и ситуаций реального мира.
3. Schema - правила формирования памяти
Агенту нужно объяснить, как поддерживать Wiki.
Например:
Перед созданием страницы проверь, не существует ли уже такая сущность.
Raw-источники не изменяй.
Для существенных утверждений сохраняй источники.
Если новый источник противоречит старому, не удаляй противоречие молча.
Для клиента поддерживай: - статус; - участников; - договорённости; - открытые вопросы; - следующие действия.
В исходном паттерне Карпаты приводит CLAUDE.md и AGENTS.md как возможные документы для таких правил.
В корпоративной архитектуре полезно разделять уровни инструкций.
/company/AGENTS.md
может задавать общие правила работы агента в компании.
А:
/company/wiki/AGENTS.md
объяснять, как именно работать с этой Wiki.
То есть AGENTS.md остаётся слоем правил и навигации, а schema Wiki - одним из наборов инструкций внутри среды.
05 Главная проблема памяти - она может ошибаться
У обычного чат-бота проблема в том, что он забывает.
У системы с долговременной памятью появляется более опасная проблема:
она может очень долго помнить ошибку.
Допустим, агент записал:
Клиент согласовал скидку 7%.
Хотя в письме было:
Клиент попросил рассмотреть скидку 7%.
Если это знание попадёт в Wiki, следующий агент будет воспринимать его как уже собранный контекст.
Ошибка начинает распространяться.
Поэтому нужно уметь проверить:
что утверждается ↓ почему мы так считаем ↓ откуда это известно ↓ актуален ли ещё источник
06 Claims + Evidence
В августе 2026 года команда OpenWiki показала один из способов сделать такую память проверяемой: хранить существенные утверждения - claims - вместе с evidence, то есть доказательствами, на которых они основаны.
Например:
{ "statement": "Согласована скидка 5%", "evidence": [ "mail://client-sever/2026-08-27/412" ] }
Получается цепочка:
Raw source ↓ Fact ↓ Claim ↓ Wiki page
И обратная дорога:
Wiki page ↓ Claim ↓ Evidence ↓ Raw source
Агент должен не только знать. Он должен иметь возможность объяснить, откуда он это знает.
OpenWiki использует версию evidence, чтобы определить, когда ранее подтверждённый claim нужно перепроверить. Само изменение источника ещё не означает, что утверждение стало ложным. Оно означает, что прежнему подтверждению больше нельзя слепо доверять.
Механизм подробно описан в официальном материале OpenWiki. 2
Проверяемая память · claims + evidence
Источник Evidence и версия
Claim Проверяемое утверждение
Wiki Знание в контексте
Источник изменился Прежнее доказательство больше не достаточно
stale → recheck Подтвердить или обновить claim
Изменение источника не сразу делает claim ложным — оно делает прежнее подтверждение недостаточным.
07 Память должна уметь устаревать
Знание может быть абсолютно правильным сегодня и неправильным завтра.
20 августа: Поставка запланирована на 15 сентября.
28 августа: Поставка перенесена на 23 сентября.
Старое утверждение не было галлюцинацией.
Оно просто устарело.
Поэтому хорошая память должна уметь отслеживать:
новый источник ↓ изменилось доказательство ↓ старое утверждение становится сомнительным ↓ повторная проверка ↓ подтверждение или обновление Wiki
Хорошая память - не та, которая хранит всё. Хорошая память понимает, чему больше нельзя доверять.
08 Три базовые операции
Карпаты предлагает очень простой жизненный цикл:
ingest query lint
Ingest - получить новые знания
Появился новый источник. Например, транскрипт встречи.
Агент:
читает встречу ↓ выделяет новое ↓ ищет связанные страницы ↓ сопоставляет с существующим знанием ↓ обнаруживает противоречия ↓ обновляет Wiki
Одна встреча может изменить сразу несколько объектов.
Это важное отличие от обычного саммари.
Мы не просто создаём:
meeting-2026-08-28-summary.md
и забываем про него.
Новые знания встраиваются в существующую систему.
Query - использовать память
Теперь агенту говорят:
Подготовь новое предложение для «Севера».
Вместо чтения 217 писем он сначала получает:
кто клиент ↓ что происходит ↓ что уже решили ↓ какие вопросы открыты ↓ какие ограничения известны
А при необходимости спускается к первичным источникам.
Карпаты отдельно отмечает важную вещь: хороший результат query можно сохранить обратно в Wiki. Если агент провёл сложное сравнение или сделал вывод, который будет дорого восстанавливать заново, он становится новым знанием.
Получается накопительный цикл:
источник ↓ знание ↓ работа агента ↓ новый вывод ↓ новое знание
Lint - проверять память
Память нужно обслуживать.
Агент или отдельный процесс периодически ищет:
противоречия устаревшие утверждения дубли страницы без связей сломанные ссылки неподтверждённые выводы
Управление памятью - отдельный процесс, а не побочный эффект общения с агентом.
09 Маленькая Wiki может быть просто папкой
На небольшом масштабе отдельная поисковая инфраструктура не обязательна.
Карпаты предлагает два простых навигационных файла:
index.md log.md
index.md - карта содержимого. Агент сначала смотрит, какие страницы существуют и где искать нужную тему.
log.md - хронологическая история ingest, query, lint и других изменений.
Карпаты пишет, что такой подход может работать на умеренном масштабе - примерно сотня источников и сотни Wiki-страниц - без отдельной embedding-инфраструктуры. Дальше уже появляется потребность в нормальном поиске.
10 Значит ли это, что RAG больше не нужен?
Нет.
Это было бы слишком сильным упрощением.
Классический RAG и Wiki решают разные задачи.
RAG хорошо отвечает:
Где находится информация, относящаяся к этому запросу?
Wiki:
Что мы уже поняли и знаем об этой теме?
RAG LLM Wiki
Основной объект документы и фрагменты знания и сущности
Основная операция найти накопить и поддерживать
Работа между запросами источник обычно не меняется Wiki развивается
Хорош для деталей и доказательств рабочего контекста
Результат предыдущего анализа обычно не сохраняется автоматически может стать новым знанием
Представление фрагменты источников более плотное связанное знание
Это не конкуренты.
Для корпоративной системы сильнее выглядит комбинация:
Источники
почта CRM документы \ | / Raw │ ┌─────────┴─────────┐ │ │ RAG LLM Wiki │ │ найти источник понять ситуацию │ │ └─────────┬─────────┘ ↓ AI-агент
Wiki помогает быстро восстановить картину.
RAG помогает проверить детали и добраться до первоисточника.
Один агент · два уровня поиска
AI-агент Объединяет картину и доказательства
RAG Находит детали и первичные доказательства
LLM Wiki Восстанавливает уже собранную картину
Raw / первичные источники Почта · CRM · документы · встречи
RAG помогает добраться до деталей и доказательств. Wiki — быстро восстановить уже собранную картину.
11 LLM Wiki - не источник истины
Это один из самых важных принципов корпоративного использования.
Допустим:
1С → остаток = 127 шт.
Не нужно каждую минуту переписывать этот остаток в Markdown и создавать вторую 1С.
Или:
CRM → этап сделки = Согласование
Wiki не должна становиться второй CRM.
Поэтому:
CRM ERP почта телефония договоры документы ↓ первичные факты и состояние ↓ Wiki ↓ понимание ситуации
LLM Wiki хранит не компанию. Она хранит понимание компании, полезное агенту.
Стоит сохранять прежде всего то, что:
сложно каждый раз восстанавливать;
полезно в следующих задачах;
возникло в результате анализа нескольких источников;
отражает историю решений;
помогает другому агенту продолжить работу.
Что лучше не копировать в Wiki
Текущий остаток товара лучше получать из ERP.
Текущий баланс - из финансовой системы.
Текущий этап сделки - из CRM.
А вот это хороший материал для памяти:
Почему клиент отказался от первой конфигурации.
Какой риск менеджер считает главным.
Какие ограничения обсуждались на трёх последних встречах.
Почему было принято конкретное архитектурное решение.
Какие варианты уже пробовали и чем они закончились.
Простой критерий:
Если агенту дорого заново восстанавливать этот контекст, его стоит рассмотреть для Wiki.
12 Почему Markdown оказался таким удобным
На первый взгляд странно строить память современной AI-системы на обычных текстовых файлах.
Но Markdown даёт несколько полезных свойств.
Человек может его прочитать.
Можно открыть страницу и увидеть, что именно агент считает известным.
Агент может его изменить.
Современные агентные среды хорошо работают с файлами.
Git показывает историю.
что изменилось когда кем
Страницы легко связывать.
[[Север]] [[Иван Петров]] [[Договор 412]]
Низкий порог входа.
Для первой реализации не обязательно сразу строить:
vector database embedding pipeline retrieval service knowledge graph
Но Markdown - хороший стартовый интерфейс памяти, а не архитектурная религия.
Как только Wiki начинает расти, появляются новые задачи.
13 Что происходит, когда Wiki становится слишком большой
LLM Wiki не означает, что всю память компании нужно загружать в контекст модели.
Представим:
10 000 клиентов 50 000 проектов сотни тысяч страниц
Загрузить всё в модель невозможно.
И даже если большой объём текста технически помещается в context window, это ещё не значит, что его стоит туда отправлять.
Исследование Lost in the Middle показало, что способность моделей использовать информацию в длинном контексте зависит не только от формального размера окна: нужная информация может использоваться хуже, когда оказывается среди большого объёма другого текста. Это исследование проводилось на моделях 2023 года, поэтому его нельзя механически переносить на все модели 2026 года, но общий инженерный вывод остаётся полезным: длинный контекст не отменяет необходимость выбирать релевантное .
Исследование и методика опубликованы в TACL. 3
Чем больше нерелевантной информации получает агент, тем:
больше токенов он тратит;
выше стоимость;
больше задержка;
сложнее найти важное;
выше риск потерять нужный факт среди шума.
Поэтому большая Wiki требует retrieval:
Запрос агента ↓ определение области ↓ index / metadata / ontology ↓ поиск ↓ релевантные страницы ↓ сбор рабочего контекста ↓ LLM
Агенту передаётся не вся Wiki.
Ему передаётся небольшой рабочий набор знаний .
Большая память · маленький контекст
Большая Wiki Тысячи связанных страниц
Сбор контекста scope metadata ontology search
Рабочий контекст 3–5 релевантных страниц
Память может быть большой. Рабочий контекст должен быть маленьким.
14 На большой Wiki самой Wiki нужен retrieval
На небольшом масштабе агент может:
прочитать index.md ↓ открыть клиента ↓ открыть связанные страницы
На большом появляются:
полнотекстовый поиск;
метаданные;
фильтрация по типам сущностей;
семантический поиск;
граф связей;
временные фильтры;
ранжирование по актуальности;
права доступа.
Карпаты сам пишет, что по мере роста Wiki нужен отдельный поиск. OpenWiki также движется в эту сторону: команда отдельно выделяет full-text, semantic и agentic search, а в версии 0.2 добавила структурированные метаданные, чтобы простые lookup-задачи не требовали дорогого свободного agentic search. 4
Получается немного парадоксальная вещь:
LLM Wiki не отменяет retrieval. На большом масштабе retrieval становится способом работать уже с самой памятью.
Но это всё ещё отличается от классического RAG.
RAG по Raw ↓ найти первичный источник
Retrieval по Wiki ↓ найти уже собранное знание
Агент может использовать оба механизма.
15 Память может быть большой. Контекст должен быть маленьким
Это один из главных принципов всей архитектуры.
Проблема не в том, как дать агенту как можно больше информации.
Проблема в том, как дать ему минимально достаточный правильный контекст .
Для подготовки предложения менеджеру не нужны:
все клиенты компании история продукта за 7 лет все договоры юридического отдела вся корпоративная Wiki
Ему нужны:
Север ↓ текущая сделка ↓ договорённости ↓ открытые вопросы ↓ актуальные товары ↓ нужный Skill
То есть:
Память - это всё, что система может знать. Рабочий контекст - то, что агенту нужно знать прямо сейчас.
16 Практическая рамка Comb: память агента, отдела и компании
Исходный паттерн Карпаты не задаёт корпоративную иерархию памяти. Но когда агентов становится много, одной общей Wiki уже недостаточно.
Не всё знание имеет одинаковый масштаб, уровень доверия и доступ.
Для корпоративной системы полезно разделять как минимум три области памяти.
Область · доверие · доступ
Память компании Устойчивое проверенное знание
Память отдела Общий контекст команды
Память агента Рабочие наблюдения и гипотезы
↑ проверка и публикация знания ↓ общие правила и контекст
Новое знание не обязано сразу становиться знанием всей компании. Память агента
Рабочий контекст конкретного сотрудника или агента:
текущие задачи;
промежуточные выводы;
наблюдения;
локальные исследования;
особенности клиентов;
незавершённые гипотезы;
контекст последних действий.
Такая память меняется быстро и может содержать рабочие гипотезы.
Например:
Клиент, похоже, рассматривает другого поставщика.
Для агента менеджера это полезное наблюдение.
Но ещё не корпоративный факт.
Память отдела
Здесь находится контекст, полезный нескольким сотрудникам или агентам:
клиенты проекты история работы команды типовые проблемы решения локальные процессы
Например, отдел продаж может иметь общую страницу клиента «Север».
Юридический отдел - память по типовым договорным рискам.
Уровень проверки здесь уже выше.
Память компании
Сюда попадает знание, которое должно пережить конкретного сотрудника и конкретную команду:
общие правила;
важные решения;
знания о продуктах;
ключевые сущности;
архитектурные решения;
накопленный опыт;
общие способы работы.
Такое знание должно проходить наиболее строгую проверку.
17 Не обязательно делать три отдельные Wiki
Разделение памяти не означает три Git-репозитория.
Это могут быть логические области:
wiki/
private/ manager-1/
teams/ sales/ legal/ product/
company/
Или единое хранилище, где каждая страница имеет метаданные:
scope: team owner: sales visibility: sales updated_at: 2026-08-28 sources: [...] confidence: high
Главное не физическое расположение файлов.
Главное - область знания .
Агент Отдел Компания
Область конкретная работа команда организация
Изменения быстрые средние более редкие
Гипотезы допустимы ограниченно обычно нет
Проверка лёгкая выше строгая
Доступ локальный команда по правилам компании
18 Знание поднимается по уровням
Агент менеджера записал:
Клиент, вероятно, хочет заменить поставщика.
Это локальная память.
Затем на встрече клиент прямо говорит:
Мы рассматриваем ещё двух поставщиков.
Теперь появляется подтверждённое знание.
Оно может попасть в память отдела:
Клиент Север рассматривает альтернативных поставщиков.
Источник: встреча 28 августа.
Если информация имеет стратегическое значение, она может быть опубликована выше.
Память агента ↓ проверка ↓ Память отдела ↓ обобщение / публикация ↓ Память компании
Не всё должно автоматически подниматься наверх.
Иначе общая память быстро заполнится гипотезами, временными наблюдениями, дублями и шумом.
19 И движется обратно
Компания принимает правило:
Для договоров свыше 5 млн обязательно согласование юридического отдела.
Оно появляется в памяти компании.
Дальше:
Память компании ↓ память отдела продаж ↓ контекст конкретной сделки ↓ AI-агент менеджера
То есть память работает в обе стороны:
локальная работа ↑↓ команда ↑↓ компания
20 Зачем уровни памяти нужны ещё и для скорости
У иерархии есть не только организационный смысл.
Она сокращает путь к нужному контексту.
Если менеджер работает с «Севером», агенту нет смысла начинать поиск со всей корпоративной памяти.
Логичнее двигаться от узкого контекста к широкому:
Память агента ↓ Память отдела ↓ Память компании ↓ Raw / RAG
Условно:
быстрее / уже / дешевле ↓ шире / дороже / медленнее
Это не строгая зависимость в миллисекундах. Скорость зависит от реализации, кэша, индекса, модели и инфраструктуры.
Но архитектурный принцип полезен:
сначала искать максимально близко к текущей работе и расширять область только при необходимости.
Так уменьшаются объём поиска, количество токенов, задержка и информационный шум. Заодно этот подход естественно сочетается с правами доступа.
Расширяй поиск только когда не хватает контекста
Agent memory Ближайший рабочий контекст
Team memory Знание команды
Company memory Устойчивое корпоративное знание
Raw / RAG Детали и первичные источники
уже · дешевле шире · дороже
Это архитектурный принцип, а не обещание конкретных миллисекунд.
21 А где здесь онтология?
LLM Wiki легко перепутать с онтологией.
Но это разные слои.
Онтология говорит:
Что существует в мире компании?
Клиент │ ├── имеет → Контакт ├── участвует → Сделка ├── подписывает → Договор └── получает → Поставка
Wiki отвечает:
Что мы знаем о конкретных объектах этого мира?
Север │ ├── контакт → Иван Петров ├── сделка → Поставка сентября ├── договор → №412 └── проблема → сертификат A-17
Коротко:
Онтология задаёт форму мира.
LLM Wiki наполняет этот мир накопленными знаниями.
Когда памяти становится много, онтология может помогать и при сборке контекста: если задача относится к клиенту, система заранее знает, что стоит проверить его сделки, контакты, договоры и поставки.
22 А где здесь Skills?
Wiki знает:
У «Севера» нужно пересчитать предложение с учётом новых сроков и остатков.
Но знать о задаче недостаточно.
Нужно понимать, как её выполнить .
Для этого существует Skill:
Подготовка коммерческого предложения
1. Получить текущую спецификацию. 2. Проверить актуальные цены. 3. Проверить остатки. 4. Учесть предыдущие договорённости. 5. Рассчитать предложение. 6. Сформировать документ. 7. Проверить результат. 8. Передать на согласование.
Поэтому:
LLM Wiki - что мы знаем.
Skill - как мы работаем.
23 А где здесь AGENTS.md?
У агента уже есть:
онтология память Skills инструменты CRM ERP почта телефония
Теперь ему нужно объяснить правила работы в этой среде.
Например:
Если задача относится к клиенту:
1. Определи сущность клиента. 2. Найди локальный контекст. 3. Получи релевантную память отдела. 4. При необходимости используй Company Wiki. 5. Проверь изменяемые данные в первичных системах. 6. Выбери нужный Skill. 7. Выполни задачу. 8. Обнови локальную память. 9. При необходимости опубликуй новое знание выше.
Это роль AGENTS.md .
AGENTS.md задаёт правила работы и навигации агента в среде компании.
24 Как это работает на задаче «Север»
Сотрудник говорит:
Подготовь обновлённое предложение для «Севера».
1. AGENTS.md
Определяет маршрут:
клиент ↓ сбор контекста ↓ проверка данных ↓ Skill ↓ действие ↓ обновление памяти
2. Онтология
Помогает определить связанные сущности:
Север ↓ контакт ↓ сделка ↓ договор ↓ товары ↓ поставка
3. Память
Система собирает:
локальная память менеджера + Sales Wiki + релевантная часть Company Wiki
и получает накопленный контекст: что обсуждали, что уже решили, почему приняли решение, что осталось открытым и какие ограничения существуют.
4. Первичные системы
Изменяемые данные проверяются там, где реально живут:
ERP → цена и остатки CRM → этап сделки почта → последнее подтверждение
5. Skill
Агент получает способ выполнения работы.
6. Инструменты
Агент:
получает данные ↓ рассчитывает ↓ создаёт документ ↓ создаёт черновик письма
7. Память обновляется
После завершения появляется новый контекст:
28 августа подготовлена версия №4.
A-17 заменена на A-19.
Стоимость уменьшена на 4%.
Клиенту необходимо подтвердить новую спецификацию до 30 августа.
Часть этого знания обновит общую страницу клиента.
Часть может остаться локальной.
Следующая задача начинается уже отсюда.
25 От идеи Карпаты к работающим реализациям
За несколько месяцев вокруг паттерна начали появляться отдельные инструменты.
Hermes: память как Skill
В Hermes Agent llm-wiki поставляется как встроенный Skill. Он описывает структуру raw / wiki / schema , работу с index.md и log.md , операции ingest, query и lint, provenance, confidence и проверки качества.
Это интересная связь двух слоёв:
Skill ↓ объясняет агенту, как поддерживать ↓ LLM Wiki
Skill хранит способ работы с памятью. Wiki хранит саму память.
Реализация описана в документации Hermes Agent. 5
OpenWiki Brains: proactive memory
10 июля 2026 года LangChain представил OpenWiki Brains - general-purpose wiki memory для агентов.
Он может получать контекст из Gmail, Notion, git-репозиториев, X, Hacker News и веб-поиска и автоматически поддерживать локальную Wiki.
LangChain называет это proactive memory : агенту не обязательно каждый раз говорить «запомни это» - система сама обходит подключённые источники и обновляет память по заданному фокусу.
На момент анонса память оставалась Markdown-first, а среди следующих задач команда отдельно называла better retrieval: full-text, MCP, semantic и agentic search.
Описание Brains и дорожной карты retrieval опубликовано LangChain. 6
26 Паттерн уже становится форматом: Open Knowledge Format
12 июня 2026 года Google Cloud представил Open Knowledge Format (OKF) и прямо описал его как формализацию LLM-wiki pattern в переносимый vendor-neutral формат. 7
Идея очень близка к исходному подходу:
директория + Markdown + YAML frontmatter + index.md + log.md
Но задача OKF шире.
Если Wiki пишет один конкретный агент, достаточно локальных соглашений.
Если знания должны читать разные агенты, системы и организации, возникает вопрос совместимости:
Что означает эта страница? Откуда она взялась? Кто её создал? Актуальна ли она? Можно ли ей доверять?
В OKF v0.2 появились стандартные поля для provenance, lifecycle и trust. Спецификация при этом сознательно не задаёт конкретную БД, search engine или runtime - это формат представления знаний, а не готовая платформа. 8 9
Это важное развитие идеи.
Karpathy LLM Wiki локальный паттерн ↓ OpenWiki / Hermes реализации ↓ OKF переносимое представление знания
Для корпоративной архитектуры это означает, что Markdown Wiki может постепенно перестать быть внутренним соглашением одного агента и стать переносимым knowledge bundle, который понимают разные инструменты.
Источники:
Google Cloud - Introducing the Open Knowledge Format
Open Knowledge Format v0.2 specification
27 Что нужно для корпоративной версии
Простой raw/wiki/AGENTS.md отлично подходит для пилота.
Но при переходе к десяткам агентов появляются дополнительные требования.
Минимальный корпоративный контур выглядит так:
источники ↓ immutable raw / ссылки на SoT ↓ ingest ↓ claims + provenance ↓ Wiki ↓ индексы / metadata / retrieval ↓ рабочий контекст ↓ агент ↓ действие ↓ новое знание
Вокруг него нужны:
права доступа;
scopes памяти;
журнал изменений;
версионирование;
разрешение конфликтов;
правила публикации знаний;
freshness и stale-состояния;
контроль качества;
human review для критичных знаний.
Это уже не просто «папка Markdown».
Это система управления машинно-читаемым знанием компании .
28 С чего начать пилот
Для первого эксперимента не нужно строить корпоративную память целиком.
Достаточно одного процесса и одной области знаний.
Например - работа с клиентом «Север».
Шаг 1. Выберите дорогой контекст
Найдите информацию, которую агенту приходится постоянно восстанавливать заново:
история договорённостей;
решения;
открытые вопросы;
причины отказов;
участники;
контекст проекта.
Шаг 2. Зафиксируйте источники истины
Например:
CRM → состояние сделки 1С → цена и остатки почта → переписка телефония → переговоры договор → юридически значимые условия
Не копируйте в Wiki то, что проще и надёжнее получить live.
Шаг 3. Создайте маленькую Wiki
raw/ wiki/ clients/ people/ projects/ index.md log.md AGENTS.md
Шаг 4. Опишите правила
Какие страницы создавать? Что считать устойчивым знанием? Когда обновлять? Как ссылаться на источник? Что делать с противоречием?
Шаг 5. Прогоните реальный цикл
письмо / встреча ↓ ingest ↓ обновление Wiki ↓ реальная задача ↓ query ↓ действие ↓ обновление памяти
Шаг 6. Измерьте не размер Wiki, а экономию восстановления контекста
Полезные вопросы:
агент реже лезет в старые письма?
быстрее начинает задачу?
меньше пропускает прошлые договорённости?
может показать источник важного утверждения?
другой агент способен продолжить работу без полного повторного исследования?
Если ответ «да», память начала приносить пользу.
29 Антипаттерны
Скопировать в Wiki всю компанию
Получится дорогая, быстро устаревающая копия CRM, ERP и документов.
Загружать всю Wiki в каждый prompt
Большая память не должна превращаться в огромный контекст.
Давать агенту право бесконтрольно публиковать всё наверх
Рабочая гипотеза одного менеджера не должна автоматически становиться знанием всей компании.
Хранить вывод без источника
Особенно если он влияет на деньги, договоры, безопасность или действия в системах.
Никогда не пересматривать старое знание
Долговременная память без механизма устаревания постепенно превращается в долговременную ошибку.
Считать Markdown конечной архитектурой
Markdown удобен как интерфейс и переносимый формат. По мере роста вокруг него всё равно появятся индексы, metadata, поиск, права и проверки.
30 Четыре слоя AI-компании
Если собрать LLM Wiki вместе с онтологией, Skills и AGENTS.md , получается довольно цельная архитектура.
AI-АГЕНТ │ AGENTS.md правила работы и навигации │ сбор контекста │ ┌───────────────────┼───────────────────┐ │ │ │ Онтология Память Skills │ │ │ что существует ┌───────┼───────┐ как работать и как связано │ │ │ Agent Team Company Wiki Wiki Wiki │ │ │ │ └────────────┴───────┴───────┘ │ сбор нужного контекста │ Инструменты │ CRM / ERP / почта / телефония документы / API / MCP / CLI
Среда AI-сотрудника · четыре разных вопроса
AI-агент Получает задачу и собирает контекст
AGENTS.md Правила работы и навигации
Онтология Что существует и как связано?
LLM Wiki Что компания знает и помнит? Agent Team Company
Skills Как компания выполняет работу?
Инструменты и системы CRM · ERP · почта · телефония · документы · API · MCP · CLI
Модель мира, память, способы работы и правила навигации формируют среду AI-сотрудника. Здесь retrieval - не ещё один фундаментальный слой рядом с онтологией, памятью или Skills.
Retrieval - механизм, который помогает агенту собрать нужную часть памяти и источников для конкретной задачи.
У каждого основного слоя свой вопрос:
Слой Вопрос
Онтология Что существует в мире компании и как это связано?
LLM Wiki Что компания уже знает и помнит?
Skills Как компания выполняет работу?
AGENTS.md По каким правилам агент работает со всем этим?
А сборка контекста отвечает ещё на один вопрос:
Что из всего этого агенту нужно прямо сейчас?
31 Память как новый программный слой компании
Большинство корпоративных систем создавалось для хранения операций.
CRM отвечает:
Что происходит со сделкой?
ERP:
Что находится на складе?
Почта:
Что было отправлено?
Телефония:
Что было сказано?
Документооборот:
Какой документ подписан?
Но остаётся другой вопрос:
Что компания поняла из всего происходящего?
Почему клиент принял именно это решение?
Какие варианты уже пробовали?
Как менялась его позиция?
Что выяснили сотрудники за последние три месяца?
Какие ошибки не стоит повторять?
Эта информация часто существует только в голове людей или каждый раз заново собирается из цифровых следов.
LLM Wiki предлагает выделить для неё отдельный слой.
Не вместо CRM.
Не вместо ERP.
Не вместо документов.
И не вместо RAG.
А поверх них.
операционные системы ↓ события и факты ↓ синтез ↓ память ↓ сбор рабочего контекста ↓ AI-агент ↓ новая работа ↓ новые знания
32 Вместо заключения
Чтобы AI-агент стал полноценным участником компании, недостаточно дать ему модель и подключить инструменты.
Ему нужно постепенно понимать:
кто есть кто;
что происходило раньше;
почему было принято конкретное решение;
что уже пробовали;
чего хочет клиент;
какие вопросы остаются открытыми;
чему компания научилась.
Человек накапливает такой контекст естественно.
У AI-агента этого механизма по умолчанию нет.
Если каждая новая сессия начинается с повторного изучения компании, агент остаётся очень умным, но постоянно новым сотрудником.
LLM Wiki предлагает простую идею:
не заставлять агента каждый раз заново понимать компанию.
Но по мере роста появляется следующий вопрос.
Недостаточно просто накопить много памяти.
Нужно понимать:
что помнить ↓ где это хранить ↓ кому это доступно ↓ насколько этому можно доверять ↓ когда это устарело ↓ что нужно достать для текущей задачи
Поэтому зрелая корпоративная память - это не одна огромная Wiki.
Это система, где:
агент имеет локальную память;
команда делится общим опытом;
компания сохраняет устойчивые знания;
первичные системы остаются источниками фактов;
retrieval выбирает только нужную часть памяти;
онтология помогает понять связи;
Skills дают способы работы;
AGENTS.md задаёт правила использования всей среды.
И тогда следующий агент начинает не с пустого окна чата и не со всей истории компании сразу.
Он начинает с правильного контекста в правильный момент .
А работа AI начинает не только выполнять задачи.
Она начинает накапливать знания компании .
ИСТ Источники
01 Andrej Karpathy. LLM Wiki , 4 апреля 2026.
02 LangChain. Building Self-Correcting Memory in OpenWiki , 25 августа 2026.
03 Nelson F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts , TACL, 2024.
04 LangChain. OpenWiki 0.2 brings OKF to codebase documentation , 16 июля 2026.
05 NousResearch. Hermes Agent: LLM Wiki skill .
06 LangChain. OpenWiki Brains: Proactive Memory for AI Agents , 10 июля 2026.
07 Google Cloud. How the Open Knowledge Format can improve data sharing , 12 июня 2026.
08 GoogleCloudPlatform. Open Knowledge Format v0.2 specification .
09 Google Cloud. OKF v0.2 adds trust signals , 24 июля 2026.
В материале
Агент каждый раз начинает почти с нуля
Как выглядит память клиента
Что именно мы называем памятью
Три слоя LLM Wiki
Главная проблема памяти - она может ошибаться
Claims + Evidence
Память должна уметь устаревать
Три базовые операции
Маленькая Wiki может быть просто папкой
Значит ли это, что RAG больше не нужен?
LLM Wiki - не источник истины
Почему Markdown оказался таким удобным
Что происходит, когда Wiki становится слишком большой
На большой Wiki самой Wiki нужен retrieval
Память может быть большой. Контекст должен быть маленьким
Практическая рамка Comb: память агента, отдела и компании
Не обязательно делать три отдельные Wiki
Знание поднимается по уровням
И движется обратно
Зачем уровни памяти нужны ещё и для скорости
А где здесь онтология?
А где здесь Skills?
А где здесь AGENTS.md?
Как это работает на задаче «Север»
От идеи Карпаты к работающим реализациям
Паттерн уже становится форматом: Open Knowledge Format
Что нужно для корпоративной версии
С чего начать пилот
Антипаттерны
Четыре слоя AI-компании
Память как новый программный слой компании
Вместо заключения
Следующая статья: RAG в 2026: система доказательств