Практичні зауваження: OKF — це більше, ніж Markdown: як я сприймаю портативність
Покроковий огляд практичних порад: OKF — це більше, ніж Markdown: як я ставлюся до портативних рішень, контрактів, перевірок та слотів для коду для команд, які використовують цю схему.
У цьому посібнику описано процес створення системи від сировини до готового продукту для проекту: OKF Is More Than Markdown: How I Think About a Portable Knowledge Layer for AI Agents. Основна увага приділяється конкретним крокам виконання, чітким перевіркам та коду, який можна просто додати до репозиторію, не здогадуючись про його призначення. На етапі огляду необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення роботи перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан системи. Необхідно одночасно задокументувати оптимальний та альтернативний сценарії роботи системи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
knowledge/
├── index.md
├── orders/
│ ├── index.md
│ └── order-lifecycle.md
├── payments/
│ ├── index.md
│ └── payment-failures.md
└── policies/
└── refund-eligibility.md
---
type: Business Rule
title: Refund Eligibility
description: Rules for determining whether an order is eligible for a refund.
tags: [orders, refunds]
---
# Refund Eligibility
An order is eligible for a refund when...
See also [Order Lifecycle](../orders/order-lifecycle.md).
Агенти є потужними, але вони все одно не знають, як працює ваш продукт
Під час роботи над скриптами, де агенти є потужними інструментами, спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Робіть перевірки після дорогих кроків. Система відновлення не повинна знову оплачувати один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
Wiki
PDF
Product docs
Shared Drive
API documentation
Source code
JIRA Tickets
Slack threads
Google Drive
People's heads
Важливою частиною OKF є не Markdown
Під час роботи над важливою частиною етапу спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового виконання. Робіть перевірки після дорогих кроків. Система повернення до виконання не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
Пакети, концепції та те, що вам здається найцікавішим: index.md
Під час вивчення концепцій Bundles та етапів їх реалізації спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени чи запити поруч із результатами функціоналу. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Робіть контрольні пункти після дорогих кроків. Функція відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор перезапускає пізніший етап. Під час вивчення концепцій Bundles та етапів їх реалізації спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний та резервний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
store-knowledge/
├── index.md
├── orders/
│ ├── index.md
│ ├── order-lifecycle.md
│ └── cancellation.md
├── payments/
│ ├── index.md
│ └── payment-status.md
└── policies/
├── index.md
└── refund-eligibility.md
Thousands of documents
↓
Load everything into context
index.md
Orders
Payments
Promotions
Refund Policies
Customer Support
policies/index.md
Refund Eligibility
Partial Refunds
Manual Review
policies/refund-eligibility.md
[Order Lifecycle](../orders/order-lifecycle.md)
Bundle
↓
index.md
↓
policies/
↓
index.md
↓
refund-eligibility.md
↓
order-lifecycle.md
Хіба це не просто RAG?
Підхід «Хіба це не...» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний приклад транскрипції, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Розділяйте політику часткового оброблення даних та політику їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.
Question
↓
Retrieve relevant knowledge
↓
Put knowledge into context
↓
Generate an answer
User Question
↓
Vector / Hybrid Search
↓
Find an OKF concept
↓
Read the concept
↓
Follow indexes or links if needed
↓
Build the final context
{
"title": "...",
"source": "...",
"type": "...",
"updated_at": "...",
"owner": "..."
}
А як щодо навичок агента?
Етап «Що щодо навичок агента» функціонує найкраще, якщо його розглядати як вимірювану основу. Запишіть один ідеальний приклад, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не погоджуйтесь на мовчазне часткове виконання завдань. Зберігайте стан графа у простому та типованому вигляді. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, що припиняє можливість продовження роботи після переривань.
1. Identify the customer issue
2. Inspect the order status
3. Check the applicable refund policy
4. Determine whether escalation is required
5. Draft a response
customer-support-skill/
├── SKILL.md
└── references/
└── commerce-knowledge/
├── index.md
├── orders/
├── payments/
└── policies/
Кейс використання OKF, який здається вам найцікавішим, насправді є локальним
Етап використання OKF працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Зберігайте стан графа у випрямленому та типованому форматі. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв. Етап використання OKF працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Документуйте як успішний, так і відновлювальний шляхи роботи разом. Повторні спроби, людські контролі та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
storefront/
├── src/
├── tests/
├── AGENTS.md
└── knowledge/
├── index.md
├── checkout/
├── orders/
├── payments/
├── refunds/
└── promotions/
read code
→ understand code
→ modify code
Coding Task
↓
Read code
+
Read refund policy
+
Read payment constraints
+
Read order lifecycle
↓
Understand actual product behavior
↓
Modify code
Modify code
↓
Product behavior changed
↓
Update knowledge
Локальні та централізовані знання не повинні конкурувати
На етапі локальних та централізованих знань необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Необхідно встановити людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення елементів під час компіляції не є гарантією повноти бізнес-функціоналу.
Company terminology
Shared authentication rules
Common API contracts
Billing definitions
Customer policies
Security guidelines
Agent
/ \
/ \
↓ ↓
Local OKF Central OKF
project shared
knowledge knowledge
OKF
= Knowledge Artifact
MCP
= Serving / Tool ProtocolSearch Index
= Retrieval Implementation
v0.2 – це та версія, коли OKF почав здаватися значно більш повним
У версії v0.2 на цьому етапі необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви для результатів роботи, визначте критерії успіху та не допускайте мовчазного часткового завершення. Необхідно забезпечити людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення елементів під час компіляції не є гарантією повноти бізнес-процесу.
sources:
...
generated:
by: ...
at: ...verified:
...status: stablestale_after: 2026-12-31
Where did this come from?
Who generated it?Has anyone verified it?Is it still current?Is this a draft or a stable concept?
Підтверджена обробка даних — це інший вид знань.
Оскільки «Перевірена обробка» є окремим етапом, необхідно визначити вхідні дані, власника кроку та критерії завершення ще до зміни коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке відображення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні. Встановлюйте людське схвалення для кроків, які витрачають гроші чи змінюють дані в продакшені. Підключення під час компіляції не є гарантією повноти функціоналу продукту. Оскільки «Перевірена обробка» є окремим етапом, необхідно визначити вхідні дані, власника кроку та критерії завершення ще до зміни коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Документуйте як «ідеальний шлях», так і «шлях відновлення» одночасно. Повторні спроби, людське схвалення та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
>Here is something we know.
Here is the approved way
to establish that something is true.
Яку проблему насправді вирішує OKF?
Під час роботи на етапі «Яку проблему?» спочатку запишіть умови виконання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну послідовність операцій. Робіть перевірки після дорогих кроків. Функція відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається виконати наступний етап.
Чек-лист для експлуатації
Етап чек-листу для експлуатації працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис виконання, один випадок невдачі та примітки щодо скасування змін перед розширенням обсягу роботи.
Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, щоб оператори могли їх перевіряти, не читаючи весь граф.
Зберігайте стан графа у вигляді плоскої структури з типизацією. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.
Коли дозволяє бюджет, додавайте тест на базову функціональність, який перевіряє критичний шлях у процесі CI за допомогою фікстур, а не реальних платних API.
Документуйте як шлях успішної роботи, так і шлях відновлення одночасно. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Зберігайте стан графа у вигляді плоскої структури з типизацією. Вкладені блоки приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.
Перш ніж запускати стек у продакшн, заморозьте версії, створіть ідеальний запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження швидкості, перевірки прав доступу та чіткий власник для зміни секретів. Краще обирати надійність, ніж кмітливі одноразові демонстрації.
Примітка для 758c51495df5: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фікстурами для оцінки, щоб подальша заміна моделей залишалася порівнянною.
Примітка щодо посилення безпеки на етапі 0 найкраще працює, якщо її розглядати як вимірювану характеристику. Збережіть один ідеальний запис, один випадок збою та примітку щодо відкату перед розширенням обсягу. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відомість витрат заздалегідь запобігає несподіваним рахункам під час переходу від демонстрацій до спільних середовищ.
Деталь посилення безпеки 0/782: виміряйте час виконання, клас помилки та кількість витрачених токенів для цього запису, а потім вирішіть, чи залишити зміни, ґрунтуючись на фіксованому наборі питань, а не на окремих випадках.
На першому етапі запису щодо посилення безпеки визначте вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан. Документуйте як успішний, так і відновлювальний сценарії. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Деталь посилення безпеки 1/782: виміряйте час виконання, клас помилки та кількість витрачених токенів для цього запису, а потім вирішіть, чи залишити зміни, ґрунтуючись на фіксованому наборі питань, а не на окремих випадках.
Під час виконання другого етапу процедури зміцнення спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань.
Деталь зміцнення 2/782: вимірюйте час виконання, клас помилки та кількість витрачених токенів для цього етапу, а потім вирішуйте, чи залишити зміни, ґрунтуючись на фіксованому наборі питань, а не на окремих випадках.
Етап процедури зміцнення 3 найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний зразок роботи, один випадок невдачі та запис про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду програми. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код.
Деталь посилення безпеки 3/782: виміряйте час виконання, клас помилки та кількість витрачених токенів для цього запису, а потім вирішіть, чи залишити зміни, ґрунтуючись на фіксованому наборі питань, а не на окремих випадках.
На 4-му етапі роботи з посиленням безпеки необхідно визначити вхідні дані, відповідальну особу та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Якщо крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну систему взаємозв’язків.
Деталь посилення безпеки 4/782: виміряйте час виконання, клас помилки та кількість витрачених токенів для цього запису, а потім вирішіть, чи залишити зміни, ґрунтуючись на фіксованому наборі питань, а не на окремих випадках.