Головна / Статті

Формат відкритих знань: портативна пам’ять для агентів з програмуванням на ШІ

Формат відкритих знань зберігає те, що вивчають кодувальні агенти, у вигляді посиланих файлів Markdown. У чому його відмінність від CLAUDE.md та MCP, та як почати його використовувати вже сьогодні.

Видавець: REACTAPP.TOP11 хв читання2417 слів

Джерела: Google Just Quietly Released the Missing Piece for AI Agents. It’s Called OKF.

Формат відкритих знань — це стандарт, призначений для того, щоб зробити пам’ять агента переносною, версійованою та читабельною для всіх інструментів у стеку розробника.

Проблема початку роботи заново щоранку

Кожен, хто використовує AI-агента для програмування, стикався з такою ж перешкодою. Сесія закривається, і наступного дня агент нічого не пам’ятає. Він знову проходить процедуру автентифікації, знову намагається зрозуміти логіку рішення, прийнятого три роки тому, та знову читає ті самі п’ять файлів, щоб відновити контекст, який минулого дня потребував години для пояснення.

Звичайним рішенням є файл 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“, а тепер віддає перевагу виразу „agentic engineering“, опублікував статтю у форматі wiki про LLM, яка набрала понад 5 000 зірок. Його аргумент простий: люди залишають wiki, коли їхнє підтримання стає обтяжливим, але агенти не втомлюються, не забувають перехресні посилання та не мають проблем із редагуванням 15 файлів за один раз.

Ця сама схема неодноразово з’являлась незалежно — у Obsidian у поєднанні з кодувальними агентами, у репозиторіях, наповнених файлами AGENTS.md, а також у файлах index.md та log.md у десятках проектів. Люди постійно винаходили одне й те саме. OKF додає узгодження щодо того, яку інформацію містить кожен документ та що означають назви файлів, щоб окремі wiki та навіть експорт каталогу з 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 оприлюднила разом із нею три практичні інструменти:

  1. Агент для оптимізації BigQuery. Він спрямовується на набір даних, створює документ із концепцією OKF для кожної таблиці та перегляду, а потім проводить другий етап роботи з LLM, який додає посилання, схеми та шляхи з’єднання, отримані з документації. Результатом для сховища даних є заповнена директорія .okf/.
  2. Статичний візуалізатор HTML. Він перетворює будь-який пакет OKF на інтерактивну діаграму у одному самодостатньому файлі HTML, без бекенду та без виходу будь-чого за межі сторінки. Концепції відображаються як вузли, а посилання у форматі Markdown — як ребра; клацання на вузлі відкриває панель у стилі wiki з відформатованим Markdown та зворотними посиланнями, позначеними як „Посилання на / Цитовано“.
  3. Зразки пакетів. Три реальні пакети на 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, ймовірно, буде вирішено кілька з цих проблем на основі відгуків, а репозиторій специфікації є публічним та приймає звернення та PR-запити.

Чому перемагають нудні формати

Формати, які стають інфраструктурою, зазвичай є нудними. JSON переміг тому, що це було найпростіше рішення, яке працювало та не вимагало жодних витрат на впровадження, а не тому, що воно було розумним. Markdown переміг таким самим чином.

OKF відповідає цьому опису. Його легко читати та писати, і він працює з будь-яким інструментом для роботи з файлами. Його цінність зростає з кількістю виробників та споживачів, і рішення одного постачальника не впливають на нього. Крім того, він фіксує патерни, до яких люди вже дійшли самостійно, завдяки Karpathy’s gist, звичкам AGENTS.md та самостійно створеним ієрархіям index.md, що є найкращим доказом вирішення справжньої проблеми.

Карпати стверджував, що агенти краще підтримують вікі, ніж люди, тому що їм не стає нудно. OKF вважає, що вікі набуває цінності лише тоді, коли може поширюватися. Разом ці дві ідеї можуть стати основою для розробки за допомогою агентів протягом кількох років. Створення такої системи зараз, поки вона ще нова, принесе користь як вам у майбутньому, так і кожному агенту, якого ви будете керувати.