Формат відкритих знань: файли Markdown як портативний шар знань для агентів
OKF від Google Cloud перетворює папку файлів у форматі Markdown на граф знань для агентів. Що він вирішує, як його спробувати, у чому його обмеження та як він поєднується з RAG та MCP.
Агенти марнують ресурси, постійно перечитуючи одні й ті самі внутрішні документи, і Google Cloud запропонував рішення: формат відкритих знань OKF. Версія 0.1 була оголошена у блозі Google Cloud 12 червня 2026 року. Ідея проста: кожна концепція, яка важлива для команди, стає одним файлом у форматі Markdown, а папка з цими файлами функціонує як легкий граф знань, який може читати будь-який агент. Для цього не потрібні SDK, бази даних чи обмеження. Скептики можуть очікувати ще одну платформу, прикидану під формат, але насправді це просто файли, і саме це є цікавим. Команди продовжують додавати складність до агентів, хоча одне з найскладніших питань насправді є простішим: де насправді знаходяться корисні знання?
Проблема: агенти постійно перенавчаються
Ось типова схема. Агент отримує запит щодо певного показника, завантажує весь внутрішній вікі, вбудовує текст та самостійно з’ясовує його значення. При наступному запиті він робить точно те саме. Чистий текст може зберігатися у кеші, але розуміння його змісту ніхто не кешує.
Уявіть собі агента, якому доводиться щоразу перечитувати документ, що визначає поняття «активний користувач», оскільки це визначення не має власного місця зберігання та знаходиться на сторінці Notion у трьох папках від основної. Кожен запит коштує недорого, але витрати накопичуються, як і незначні втрати, коли ніхто не стежить за ними; у команді, яка щодня виконує однакові запити, витрати на токени є значними. Не існує публічних даних щодо цього, адже сторонні особи не мають внутрішніх цифр Google, проте сама проблема є знайомою більшості тих, хто керує агентами.
Більш конкретний приклад: у документі з аналітикою активним користувачем вважається той, хто здійснив принаймні одну значущу дію з продуктом протягом календарного місяця. Якщо запитати співробітника, скільки було активних користувачів минулого місяця, йому знадобляться дві різні речі – цифри та розуміння того, що означає тут поняття «активний». Це окремі проблеми. База даних фіксує те, що сталося, тоді як шар знань записує, що саме має на увазі компанія. OKF прагне полегшити представлення цієї другої частини.
Рішення – це формат, а не більша модель
OKF навмисно майже нудно простий. Пакет – це папка з файлами у форматі Markdown, кожен з яких описує певну концепцію: таблицю, показник, API чи посібник. Кожен файл починається з невеликого блоку YAML – frontmatter – між двома маркерними рядками. Обов’язковим є лише одне поле:
---
type: Metric # required – tells the agent what kind of concept this is
---
П’ять додаткових полів доповнюють цю структуру; вони наведені тут разом із їхніми призначеннями:
| Field | Purpose |
| ------------- | ---------------------------- |
| `title` | Human-readable name |
| `description` | Short summary |
| `resource` | Link to the underlying asset |
| `tags` | Keywords for categorization |
Версія 0.2 додає необов’язкові поля, які охоплюють походження даних, їх перевірку, свіжість, життєвий цикл та обчислення, які були підтверджені. Ви можете додати будь-які додаткові ключі, і очікується, що користувачі ігноруватимуть ті, які вони не розпізнають, що дозволяє розширювати формат без пошкодження чужих агентів. Зарезервовано два імена файлів: index.md для списку каталогів та log.md для історії змін, що допомагає уникнути необхідності створення правил, які вже визначені специфікацією. Специфікація була запущена у вигляді чернетки v0.1, тому очікуйте її еволюції та перевіряйте репозиторій на наявність актуальної версії перед створенням чогось серйозного.
Посилання формують граф
Оскільки файли є звичайними Markdown-файлами, концепції поєднуються за допомогою звичайних посилань [текст](інший-файл.md), і ці посилання є ребрами графа, який знаходиться у папці, без додаткової бази даних. Валідний файл концепції виглядає так:
---
type: Metric
title: Monthly Revenue
description: Total money earned each month.
resource: https://console.cloud.google.com/bigquery?p=project&d=dataset&t=revenue
tags: [finance, monthly]
---
Revenue is counted after refunds are removed.
See also: [customer_acquisition_cost.md](customer_acquisition_cost.md)
Агент, який читає revenue.md, дізнається, що відповідна концепція знаходиться у customer_acquisition_cost.md. Значення посилання все одно визначається тим, хто написав ці файли, адже формат не претендує на те, що зрозуміє його замість вас.
Спробуємо за п’ять хвилин
У специфікації є реальні зразки наборів даних, створені на основі даних електронної комерції GA4, даних з Stack Overflow та блокчейну Bitcoin. Референтний агент, який аналізує набори даних BigQuery та створює документи OKF, автоматично їх генерує, і все це знаходиться в одному репозиторії Apache 2.0:
git clone https://github.com/GoogleCloudPlatform/knowledge-catalog.git
cd knowledge-catalog/okf
# Add your own concept
cat > new_metric.md <<'EOF'
---
type: Metric
title: Net Promoter Score
description: Measure of customer loyalty.
resource: https://console.cloud.google.com/bigquery?p=company&d=metrics&t=nps
tags: [customer, loyalty]
---
EOF
Кожен пакет з зразками містить файл viz.html. Відкрийте його в будь-якому браузері, щоб побачити інтерактивну діаграму пакета з вузлами, посиланнями, засобами пошуку та фільтрами — без участі бекенду чи сервера. Однак є один недолік: створення viz.html для власного пакета означає запуск невеликого інструменту на Python з репозиторію. Він перетворює пакет на єдину самодостатню HTML-сторінку, створену на основі Cytoscape.js та marked.js, знову ж таки без бекенду — лише файл, який можна надіслати колезі електронною поштою.
Переваги
- Нижча вартість: визначення записується один раз та читається безпосередньо, тож ви не будете платити за його повторне отримання п’ятдесят разів на день.
- Швидше завантаження: це звичайний текст на диску, без необхідності підключення до мережевого сервісу знань та без кроку вбудовування перед використанням.
Можливість перегляду є ще однією перевагою. Припустимо, агент пропонує таку зміну:
- Revenue is recognized when an order is placed.
+ Revenue is recognized after delivery and the 30-day return window.
Це звичайний git diff, і рецензент бачить точно, що змінилося. Його набагато легше оцінити, ніж тихе оновлення, приховане в пропрієтарній системі знань.
Які у нього недоліки
- Він не виправляє неправильні визначення. OKF стандартизує контейнер, а не його вміст, тож якщо команда не може дійти згоди щодо значення терміна «активний користувач», файл markdown не змусить їх це зробити.
- Хтось мусить ним керувати. Файли стають застарілими, а поля
timestampта файлlog.mdдопомагають лише тоді, коли люди чи агенти їх оновлюють. Застарілі знання можуть завдати більше шкоди, ніж їх відсутність, адже агенти вірять у все, що знаходять. - Це ще молодий проєкт, явно незавершений, тому поля та правила можуть змінюватися, тож ранні користувачі повинні очікувати змін.
- Значення не примушується до дотримання. Посилання вказує на те, що два концепти пов’язані, але не пояснює, як саме, і цей зв’язок описується у прозі, яка є гнучкою, але водночас нечіткою. Для суворо типізованих зв’язків все одно потрібна справжня база даних графів.
- Наразі мало користувачів. Майже всі розробники та споживачі на момент запуску походили з Google, і формат зможе досягти успіху лише у разі, якщо його приймуть інші інструменти та команди.
OKF поруч із RAG та MCP
Ніщо з поточної стек-структури не викидається, оскільки OKF розміщується під нею. RAG все одно знаходить відповідні уривки під час надходження запиту, а OKF забезпечує його більш чистим, попередньо структурованим текстом, що робить ембеддинги точнішими та дешевшими у створенні. MCP, протокол контексту моделі від Anthropic, передає контекст під час розмови, а OKF може функціонувати під ним як джерело інформації для цих інструментів. MCP керує потоком даних, тоді як OKF зберігає визначення, тож їх не доводиться перевизначати щоразу. Ці три шари виглядають так:
OKF
↓
"What does this concept mean?"
RAG
↓
"Which pieces of knowledge should I retrieve?"
MCP
↓
"How does the agent interact with the tools and context?"
Кожний шар вирішує іншу проблему, тому OKF краще розглядати як спільний шар знань, що лежить під обома, а не як конкурента. Файли Markdown зовсім не схожі на презентацію нового продукту, проте іноді саме найпростіший варіант виявляється ефективним.
Чи варто його використовувати?
Для будь-якого агента, який відповідає на запитання щодо ваших даних, метрик чи систем, відповідь — так, спробуйте його. Спроба коштує майже нічого: напишіть три файли, поєднайте їх, вкажіть агенту шлях до папки, і вже за один день ви дізнаєтесь, чи це допомагає. Якщо ваші знання зберігаються лише в голові однієї людини чи у хаотичному wiki, OKF пропонує просте, версійоване місце для їх запису, що може бути корисним як з агентом, так і без нього. Якщо вам потрібні суворі схеми, типові зв’язки чи ретельний контроль, сьогодні цей інструмент ще занадто простий, тож зберігайте свій каталог та, можливо, пізніше експортуйте його у вигляді пакету.
Не починайте з усієї бази знань компанії. Виберіть одну невелику галузь, наприклад:
metrics/
active-user.md
revenue.md
conversion-rate.md
systems/
payments-api.md
orders-api.md
runbooks/
payment-failure.md
Під’єднайте файли, передайте їх одному агенту та вимірюйте, які зміни відбуваються. Це набагато кращий експеримент, ніж три місяці на розробку платформи OKF для корпорацій, перш ніж довести її необхідність.
Одне обов’язкове поле та папка з кодом у форматі Markdown самі по собі не вирішать проблему поганої документації. Те, що вони пропонують, — це спільне, просте та портативне місце для хорошої документації, яка вже є у команді, і це має більшу цінність, ніж здається на папері.
Пов’язані матеріали
- Практичні нотатки: створення автономного критика інтерфейсу користувача за допомогою нового Google — Детальний посібник з практичних нотаток щодо створення автономного критика інтерфейсу користувача за допомогою нового Google: контракти, перевірки та шаблони коду для команд, які використовують цю модель.