Формат открытых знаний: портативная память для агентов по программированию с ИИ
Формат открытых знаний хранит информацию, полученную агентами-кодерами, в виде связанных файлов Markdown. В чем он отличается от CLAUDE.md и MCP, и как начать им пользоваться уже сегодня.
Источники: Google Just Quietly Released the Missing Piece for AI Agents. It’s Called OKF.
Формат открытых знаний — это стандарт, предназначенный для обеспечения портабельности памяти агента, её версионирования и возможности чтения любыми инструментами в среде разработчика.
Проблема начинания всё с нуля каждое утро
Любой, кто использует ИИ-агента для программирования, сталкивался с той же проблемой. Сессия заканчивается, и на следующий день агент ничего не помнит. Ему приходится снова проходить процедуру аутентификации, снова догадываться о причинах принятого три года назад архитектурного решения и снова читать те же пять файлов, чтобы восстановить контекст, который накануне требовал часа на объяснение.
Распространённым решением являются файлы CLAUDE.md или AGENTS.md — документы с контекстом, которые загружаются в начале каждой сессии. Это примитивные инструменты: они загружают всё при каждом запуске, независимо от значимости информации; они предназначены для одного агента на одной платформе и плохо адаптируются к другим условиям. Кроме того, они смешивают инструкции по поведению, такие как «всегда писать тесты», с фактами вроде «таблица заказов связывается с таблицей клиентов по полю customer_id», из-за чего быстро возникает беспорядок.
12 июня 2026 года Google Cloud опубликовала спецификацию, направленную на преодоление этих проблем, под названием Open Knowledge Format или OKF. Это на сегодняшний день самое упорядоченное решение проблемы памяти агентов.
Где сегодня хранится знание
Предположим, агенту необходимо определить, как рассчитывается количество активных пользователей в неделю на основе потока событий. Ответ на этот вопрос распределён по как минимум четырём местам:
+-----------------------+--------------------------------------------+
| WHERE IT LIVES | WHAT'S THERE |
+-----------------------+--------------------------------------------+
| Metadata catalogs | Table schemas (but vendor-locked APIs) |
| Wiki / Notion | Runbooks, metric definitions |
| Code comments | Docstrings, inline notes |
| People's heads | Join paths, deprecation warnings |
+-----------------------+--------------------------------------------+
Здесь ничто не развивается вместе с кодом, и ничто не сохраняется после открытия нового окна контекста. Каждый создатель агентов снова решает одну и ту же задачу по сборке контекста, а каждый поставщик каталогов формирует собственные схемы.
OKF считает, что не хватает формата, а не ещё одной платформы.
Что такое формат
Версия 0.1 формата Open Knowledge Format — это открытая, нейтральная по отношению к поставщикам спецификация, лицензированная под лицензией Apache 2.0. Знания хранятся в виде каталога файлов в формате markdown, каждый из которых содержит метаинформацию в формате YAML. Это звучит просто, потому что так и есть, и это сделано намеренно.
Не существует реестра схем, движка во время выполнения и обязательного SDK. Любой инструмент, способный выполнить команду cat для файла, может его прочитать, а любой инструмент, способный выполнить команду git clone для репозитория, может его распространить. Вся спецификация помещается на одну страницу и содержит ровно одно обязательное поле; все остальные являются необязательными или оставляются на усмотрение создателя.
Структура пакета
Пакет — это просто папка, а путь к файлу служит идентификатором его концепции.
.okf/
+-- index.md <- progressive entry point
+-- log.md <- dated change history, newest first
+-- services/
| +-- index.md
| +-- auth-api.md <- one concept = one file
| +-- payments-service.md
+-- datasets/
| +-- index.md
| +-- orders-db.md
+-- metrics/
| +-- index.md
| +-- weekly-active-users.md
+-- decisions/
+-- index.md
+-- why-we-use-postgres.md
В каждом пакете зарезервированы два имена файлов:
index.mdобеспечивает постепенное отображение информации. Агенты просматривают пакет, читая индекс на каждом уровне, и спускаются ниже только тогда, когда это требуется задачей. Это тот же принцип поэтапной загрузки, который позволяет Claude Skills экономить токены.log.md— это история изменений с датами в формате ISO, при этом новые записи отображаются первыми. И люди, и агенты, которые обслуживают пакет, добавляют в него записи при изменении концепций.
Все остальные файлы являются документами с концепциями, идентифицируемыми по их пути. Единственным обязательным элементом в таких документах является непустое поле type.
---
type: Service
title: "Auth API"
description: "Issues and verifies short-lived access tokens."
resource: https://github.com/acme/auth
tags: [auth, platform]
timestamp: 2026-06-14T10:00:00Z
---
Затем в этом блоке может находиться обычный Markdown, включая таблицы.
## Endpoints| Method | Path | Description |
|--------|----------|---------------------------|
| POST | /token | Exchange creds for a JWT. |
| GET | /verify | Validate a token. |## Why This ExistsSee the decision at [decisions/why-we-separated-auth.md](../decisions/why-we-separated-auth.md).
Joins with [datasets/orders-db.md](../datasets/orders-db.md) for user scoping.
Следующим шагом является ключевое решение по дизайну. Концепции связаны между собой с помощью стандартных ссылок Markdown. Благодаря этому каталог превращается в граф — набор типизированных, взаимосвязанных знаний с четко определенными отношениями, по которым можно перемещаться, вместо простого набора документов.
[auth-api.md]
/ \
links links
/ \
[decisions/why-separated-auth.md] [datasets/orders-db.md]
|
links
|
[datasets/customers-db.md]
Инструмент, способный следовать за ссылкой в формате Markdown, может перемещаться по графу, а агент с правами доступа к файлам может его как читать, так и записывать.
Поскольку требуется только параметр type, создатель выбирает, какие типы существуют (Service, Dataset, Metric, Decision, Runbook и т. д.), какие фильтры использовать и какие разделы тела сообщения включать. OKF определяет интероперабельность, а не модели содержимого.
Создатели и потребители
Формат работает одинаково с обеих сторон, поэтому замена создателя или потребителя не нарушает структуру данных.
PRODUCERS CONSUMERS
--------- ---------
Human authors ----> AI agents
BigQuery pipelines ----> HTML visualizers
LLM-generated ----> Search indexes
Wiki exports ----> Other agents / tools
Не существует проприетарных учётных записей, SDK или централизованного реестра. Ценность растёт по мере распространения, а не благодаря привязке к поставщику. Это соответствует философии git, markdown и JSON — форматов, которые остались в употреблении, потому что для их использования не требовалось ничего дополнительного.
Как это связано с CLAUDE.md и MCP
Большинство недопониманий возникает именно здесь. OKF не заменяет уже существующие инструменты — он заполняет определённый пробел.
+---------------------+---------------------------+---------------------------+
| TOOL | PURPOSE | SCOPE |
+---------------------+---------------------------+---------------------------+
| CLAUDE.md | How the agent behaves | Per-project, one agent |
| AGENTS.md | Repo instructions | Per-repo, tool-specific |
| Karpathy LLM wiki | Agent-maintained notes | Pattern, not a spec |
| MCP | Live tool access | Runtime connections |
| OKF | What the team knows | Cross-project, any agent |
+---------------------+---------------------------+---------------------------+
Четкая ментальная модель разделяет три вопроса:
- CLAUDE.md определяет, как должен вести себя агент.
- OKF указывает, что команда знает об этой системе.
- MCP указывает, какие динамические инструменты может использовать агент в данный момент.
Они работают вместе. В файле CLAUDE.md может быть указано на необходимость прочитать папку .okf/metrics/ перед выполнением любой аналитической задачи. Затем пакет OKF предоставляет структурированные знания, на которые указывает CLAUDE.md, а соединения MCP обеспечивают доступ к источникам динамических данных, описанным в документах OKF.
Идея вики, с которой она созвучна
Андрей Карпати, который ввёл термин «vibe coding», а теперь предпочитает выражение «агентное инжиниринг», опубликовал краткое описание LLM-вики, которое набрало более 5 000 звёзд. Его аргумент прост: люди бросают вики, когда их обслуживание становится рутиной, но агенты не устают от этого, не забывают перекрёстные ссылки и не испытывают трудностей с редактированием 15 файлов за один раз.
Эта же схема постоянно встречалась независимо друг от друга: в Obsidian в сочетании с кодирующими агентами, в репозиториях, полных файлов AGENTS.md, а также в файлах index.md и log.md в десятках проектов. Люди постоянно изобретали одно и то же. OKF добавляет согласование относительно того, какие данные содержит каждый документ и что означают имена файлов, что позволяет отдельным вики и даже экспортам из BigQuery сотрудничать без необходимости в переводе.
Соответствие между ними имеет три уровня:
KARPATHY LAYER OKF EQUIVALENT
-------------- --------------
Raw sources (immutable) --> External datasets, docs, APIs
(OKF bundles are the compiled layer)
Wiki (LLM-maintained) --> OKF bundle (*.md + frontmatter)
(OKF adds type, resource, tags, timestamp)Schema (CLAUDE.md) --> Producer/consumer conventions + okf/SPEC.md
(org-wide spec replaces per-vault bespoke rules)
Как проект Karpathy, так и OKF используют index.md и log.md для выполнения одних и тех же задач, и это совпадение не было случайным.
Что предоставила Google
OKF представляет собой спецификацию, однако Google выпустила вместе с ней три практических инструмента:
- Агент для обогащения данных в BigQuery. Он направлен на набор данных и генерирует документ с концепцией OKF для каждой таблицы и представления, затем проводит вторую обработку с использованием большой языковой модели, добавляя цитаты, схемы и пути соединения, взятые из документации. Результатом для хранилища данных становится заполненная папка
.okf/. - Статический визуализатор HTML. Он преобразует любой пакет OKF в интерактивную диаграмму в одном самодостаточном HTML-файле, без необходимости в бэкенде и без выхода данных за пределы страницы. Концепции отображаются в виде узлов, а ссылки в формате Markdown — в виде рёбер; нажатие на узел открывает панель в стиле wiki с отрендеренным Markdown и обратными ссылками, помеченными как «Ссылки на / Цитируют».
- Примеры пакетов. На GitHub существуют три реальных пакета, использующих публичные наборы данных BigQuery:
+--------------------+----------------------------------+
| BUNDLE | WHAT IT DOCUMENTS |
+--------------------+----------------------------------+
| GA4 e-commerce | Analytics tables and metrics |
| Stack Overflow | Public dataset concepts |
| Bitcoin | Blockchain dataset structure |
+--------------------+----------------------------------+
Они служат как шаблонами для копирования, так и доказательством того, что формат работает единообразно в разных доменах.
Когда OKF — правильный выбор
Он подходит, когда проблема с знаниями выглядит так:
- Одни и те же объяснения повторяются в каждой новой сессии агента. Если какой-то блок контекста постоянно вставляется в CLAUDE.md, его следует поместить в OKF.
- Знания распространяются на несколько проектов или команд. CLAUDE.md связан с одним проектом и одним агентом, тогда как OKF позволяет объединять данные, перемещая их между репозиториями, агентами и инструментами.
- Документация проекта должна поддерживать версионирование. OKF хранится в git рядом с кодом, который описывает, каждое изменение отображается в формате diff, а запрос на слияние может передавать обновления знаний вместе с изменениями в коде.
- Инфраструктура — Google Cloud и BigQuery. Существует прямая интеграция с каталогом знаний Google, который принимает пакеты данных и передаёт их агентам GCP.
- Нужна графовая структура знаний, а не простой вики. Граф ссылок в формате Markdown позволяет задавать отношения между концепциями без использования специальной базы данных графов.
В некоторых случаях это неверный выбор:
- Требуются данные в реальном времени, для чего необходим MCP.
- Правила поведения нуждаются в кодировании, что является задачей CLAUDE.md.
- Проект небольшой и помещается в одну сессию, когда достаточно только CLAUDE.md.
Начало работы
Настройка минимальна по замыслу.
С Claude Code
Плагин okf-skills объединяет в себе три функции. /okf:okf создаёт и управляет пакетами, /okf:validate проверяет соответствие пакета установленным стандартам, а /okf:visualize формирует интерактивную диаграмму. Установите его следующим образом:
/plugin marketplace add scaccogatto/okf-skills
/plugin install okf@scaccogatto
Любой агент, включая Claude Code, Cursor, Codex и более двадцати других, может вместо этого использовать npm:
npx skills add scaccogatto/okf-skills
Затем запустите соответствующие навыки:
/okf:okf produce .okf # create your first bundle
/okf:validate .okf --strict # check conformance
/okf:visualize .okf # generate viz.html
Чтобы автоматически обновлять информацию, чтобы Claude сначала читал файлы из папки .okf/, выполняя задачи, а затем записывал усвоенное, скопируйте шаблон templates/CLAUDE-okf.md в файл CLAUDE.md проекта. Этот шаг не является обязательным.
Ручное создание
Создайте папку .okf/ и добавьте в неё файл index.md. Затем создайте по одному файлу с описанием концепции для каждой важной функции системы. Файл с записью решения выглядит следующим образом:
---
type: Decision
title: "Why we use Postgres over MySQL"
description: "JSONB support and row-level security were decisive."
timestamp: 2026-03-01T00:00:00Z
tags: [infrastructure, database]
---
Далее следует текст:
## ContextIn early 2026 we evaluated both options. MySQL's JSON support was insufficient for our metadata schema...## DecisionPostgres 16. See [datasets/primary-db.md](../datasets/primary-db.md) for schema docs.
Всё, что нужно. Любой агент с правами на доступ к файлам может сразу его прочитать, его также можно просмотреть в PR и сравнить с версией в git.
Вся стек-технология
Вот как OKF взаимодействует со всем остальным в сессии:
+--------------------------------------------------+
| AGENT SESSION |
+--------------------------------------------------+
| CLAUDE.md / AGENTS.md |
| (behavioral rules - how agent acts) |
+--------------------------------------------------+
| OKF BUNDLE (.okf/) |
| (curated team knowledge - what we know) |
| - index.md: entry points per domain |
| - concepts/*.md: services, datasets, decisions |
| - log.md: change history |
+--------------------------------------------------+
| AUTO-MEMORY (memory.md) |
| (what the agent picked up implicitly) |
+--------------------------------------------------+
| MCP CONNECTIONS |
| (live tool access - what the agent can do) |
+--------------------------------------------------+
| SKILLS (.claude/skills/) |
| (reusable SOPs - how to do specific tasks) |
+--------------------------------------------------+
Каждый слой отвечает на свой собственный вопрос. Они не перекрываются, а дополняют друг друга.
Что остаётся нерешённым в v0.1
Google открыто называет v0.1 отправной точкой, при этом в первую очередь решена проблема взаимодействия. Остаётся несколько вопросов дизайна:
- Противоречия. Когда два документа OKF расходятся во мнениях по одному факту, пока не существует семантики объединения.
- Устаревшие данные. Поскольку OKF основан на файлах, документ, который не был изменён при обновлении системы, является результатом сбоя процесса, а не сбоя формата.
- Типизированные связи. В текущей спецификации используются обычные ссылки Markdown; более сложные типы связей, такие как «противоречит», «расширяет» или «заменяет», разрабатываются сообществом.
- Поиск по аспектам. Некоторые специалисты хотят большего количества тегов, чем предусмотрено минимальной спецификацией.
В версии v0.2, скорее всего, будут устранены некоторые из этих проблем на основе отзывов, причем репозиторий спецификаций открыт и принимает замечания и патчи.
Почему побеждают скучные форматы
Форматы, которые становятся частью инфраструктуры, как правило, бывают однообразными. JSON победил потому, что это был самый простой работающий вариант, который не требовал никаких затрат на внедрение, а не потому, что он был умным. Markdown победил по той же причине.
OKF соответствует этому описанию. Его легко читать и писать, и он работает с любыми инструментами для обработки файлов. Его ценность растет по мере увеличения числа создателей и пользователей, и решения одного поставщика не влияют на него. Кроме того, он фиксирует подходы, к которым люди уже пришли самостоятельно, благодаря концепции Karpathy’s gist, привычкам, описанным в AGENTS.md, и иерархиям, созданным вручную в index.md, что является лучшим доказательством решения реальной проблемы.
По мнению Карпати, агенты лучше людей справляются с управлением вики, потому что им не бывает скучно. Согласно мнению OKF, ценность вики растёт только тогда, когда она может распространяться. Вместе эти две идеи могут стать основой для разработки с участием агентов в ближайшие годы. Создание такой системы сейчас, пока она нова, принесёт пользу как вам в будущем, так и всем агентам, которым вы будете давать указания.