Open Knowledge Format: az AI-agentek közös nyelve
Az OKF azt mutatja meg, miért nem elég az erősebb modell: az AI-agenteknek közös, hordozható kontextus kell.
Open Knowledge Format: az AI-agentek közös nyelve
Az AI-modellek ma már sokkal többet tudnak, mint két éve. Mégis, amikor valódi vállalati munkát várunk tőlük, gyakran ugyanazon a ponton akadnak el: nem ismerik a cég belső valóságát.
Nem tudják, nálatok pontosan mit jelent a "heti aktív felhasználó". Nem tudják, melyik API-t vezettétek ki csendben. Nem tudják, melyik dashboardban lehet megbízni, melyik tábla legacy, és melyik metrika definícióját írta át valaki fél éve egy meeting után.
Ezért üdvözlendő a Google Cloud által bemutatott Open Knowledge Format. Az OKF nem egy újabb knowledge base vagy egy platform, hanem egy javasolt formátum: markdown fájlok, YAML frontmatter, egyszerű szabályok. Pont annyi struktúra, hogy egy AI-agent értelmezni tudja, pont annyi szabadság, hogy egy ember se utálja meg az első napon.
Mert ez lesz a fontos: a következő AI-platformváltás nem csak a modellekről fog szólni, hanem arról is, hogy melyik cég tudja a saját működését olvashatóvá tenni embereknek és AI-agenteknek egyszerre.
A kontextus nem hiányzik. Szétszórva hever.
A legtöbb szervezetben a tudás valahol megvan. Csak ritkán ott, ahol szükség lenne rá.
Egy metrikadefiníció a data catalogban él. Egy product / design döntés egy Google Docban vagy a Confluence-en. Egy runbook a wikiben. Egy schema magyarázata egy notebook cellában. A valódi háttér pedig sokszor annak a senior fejlesztőnek a fejében, aki még emlékszik, miért lett a workaroundból végleges architektúra.
Az üzletnek ez már önmagában drága, AI-agenteknek pedig különösen rossz.
Ha egy agentnek arra kell válaszolnia, hogy "hogyan számoljuk a heti aktív felhasználókat az event streamből?", nem egyetlen forrást kell megnyitnia. Össze kell raknia a képet logokból, dokumentumokból, kódból, dashboardokból és csapatszokásokból. Ezeket a rendszereket viszont nem úgy tervezték, hogy együtt beszéljenek.
Az agentic rendszerek szűk keresztmetszete általában nem a modell intelligenciája, hanem a tiszta, hordozható és megbízható kontextus hiánya.
A szokásos enterprise reflex erre egy újabb tudásbázis, de ettől sokszor csak annyi történik, hogy a régi silók fölé épül egy újabb siló, szebb keresővel.
Az OKF viszont hasznosabb irányból közelít: nem feltétlenül új szolgáltatás kell, hanem közös formátum.
Mi az OKF lényege?
Egy OKF bundle egyszerűen egy markdown fájlokból álló könyvtár. Minden fájl egy fogalmat ír le: metrikát, táblát, API-t, runbookot, adatkészletet, üzleti folyamatot vagy bármilyen más tudáselemet.
A fájl tetején YAML frontmatter van. A hivatalos v0.1 specifikáció szerint egy normál concept dokumentumban egyetlen kötelező mező van: a type.
A többi ajánlott, de nem kötelező:
titleaz embernek is érthető megnevezéshezdescriptiona rövid összefoglalóhozresourceaz eredeti adat, API vagy rendszer hivatkozásáhoztagsszűréshez és csoportosításhoztimestampaz utolsó érdemi módosítás idejéhez
A törzs sima markdown. Lehet benne heading, lista, táblázat, kódpélda, link, forrás. Megnyitható szövegszerkesztőben, olvasható GitHubon, review-zható pull requestben, indexelhető keresővel, és betölthető egy LLM kontextusablakába.
Ha használtál már Obsidian-t, Notiont, Hugót, MkDocs-t vagy bármilyen belső "LLM wiki" mintát, az egész ismerős lesz. Az OKF nem új gondolkodási módot talál ki: a már terjedő mintát teszi egységessé.
Ez a jó product design: nem akar egy teljes viselkedési mintát megváltoztatni, csak ad egy közös együttműködési rendszert a már létező munkamódok fölé.
Három dolog, amit érdemes komolyan venni
Az OKF specifikáció rövid, de a mögötte lévő döntések tanulságosak.
Először: minimálisan véleményes. Nem akarja előre megmondani, milyen tudásfajta létezhet egy cégben. Nem definiál központi taxonómiát. A type kötelező, a többi a dokumentum létrehozójának dolga. A dokumentum fogyasztójának pedig figyelembe kell vennie, hogy lehetnek ismeretlen mezők, extra adatok, törött linkek és hiányzó opcionális fájlok. Ez leköveti a valóságot: a vállalati tudás soha nem lesz patikatiszta.
Másodszor: különválasztja a létrehozót és a fogyasztót. Egy ember írhat OKF dokumentumot kézzel. Egy enrichment AI agent generálhat ilyet BigQuery adatkészletből. Egy visualizer bot gráfot rajzolhat belőle. Egy másik agent működési kontextusként olvashatja.
A fájl a szerződés az együttműködésről, a tooling cserélhető.
Harmadszor: formátum, nem platform. Az OKF nem kötődik felhőhöz, modell-szolgáltatókhoz, adatbázishoz, agent frameworkhöz vagy UI-hoz. Élhet gitben, repo almappában, statikus file serveren vagy zipként.
Ez unalmasan hangzik, de pont ez benne az erős.
Agentic rendszerekben sokszor az unalmas formátumok a stratégiai formátumok. Tovább élnek, mint az okosnak tűnő platformok.
Mit jelent ez az Agentic UX szempontjából?
A digitális termékeket eddig főleg embereknek terveztük. Gombokat, labeleket, formokat, dashboardokat, flow-kat. A megközelítésünk az volt, hogy mit lát és mit ért meg a felhasználó.
Az AI-agenteknek viszont másfajta felület kell. Nem feltétlenül vizuális, hanem értelmezhető. Tudniuk kell, mit jelent egy adat, honnan származik, mi függ tőle, melyik koncepció kapcsolódik hozzá, és melyik forrás támasztja alá az állítást.
Ez ugyanaz az irány, amiről a WebMCP kapcsán írtam: a digitális rendszereinknek nemcsak emberi, hanem gépi affordance-ekre is szükségük van. Az OKF ezt teszi a szervezeti tudással: olvashatóvá teszi a cég működését AI-agenteknek úgy, hogy közben az emberek számára is olvasható marad.
Ez az Agentic Experience Design egyik alapja. Már nem csak a képernyőt tervezzük, hanem a képernyő alatti kontextusréteget is: tudásokat, szerződéseket, példákat, jogosultságokat, forrásokat és workflow-kat.
Az OKF ettől még nem csodaszer. Egy rosszul megírt metrika definíciója YAML-be csomagolva is rossz. Egy homályos szöveggel teleírt bundle nem válik attól operatív tudássá, hogy markdownban van. Viszont ad egy jó kezdőpontot. Tedd a tudást azok mellé a rendszerek mellé, amelyeket leír: látszódjanak a különbségek, legyen review-zható, legyen olvasható AI-agentnek és embernek is.
Röviden: kezeld a nagybetűs Kontextust a termék infrastruktúrájaként, ne dokumentációs maradékként vagy chat history-ként.
Hol érdemes kezdeni?
Ha AI-agentet építesz egy cégben, azt a kérdést tedd fel: mit kell tudnia az agentnek, ami ma eszközökbe, dokumentumokba, dashboardokba és emberek fejébe van elásva?
Kezdd el kicsiben, válassz egy jól megfogható, de fontos területet.
Például:
- egy bevételi metrikát;
- egy ügyfél-támogató workflow-t;
- egy core adatkészletet;
- egy régi, de még mindig kritikus API-t;
- vagy egy jó öreg onboarding playbookot.
Minden fontos tudáselemet írj le külön markdown fájlban. Adj hozzájuk linkeket és forrásokat. Használj verziókezelőt. Ne egyszeri dokumentumként kezeld, hanem élő tudásrétegként.
Nem az a lényeg, hogy az OKF kész legyen elsőre. A v0.1 csak kiindulópont. Ami fontos, hogy végre lesz egy egyszerű, emberközeli formátum arra a problémára, amivel minden komoly AI termékcsapat szembe fog nézni.
Az AI a termékekben nem egy chat ablak lesz, hanem az interface alatti kontextusréteg része. Az OKF pedig az egyik legtisztább korai jel arra, hogyan nézhet ki ez a réteg.
Források
További írások az archívumból
WebMCP: a láthatatlan internet új nyelve
A WebMCP miatt a webes termékeket már nemcsak embereknek, hanem AI-ágenseknek is olvashatóvá kell tervezni.
Miért nem éri utol az AI Agent az emberi teknőst?
Az AI Agent gyors, de a valódi munka célból, kontextusból, ítéletből és felelősségből áll. Ez továbbra is emberi szerep.
Ehhez a gondolathoz kapcsolódó projektek
Open Brain: Building a Personal Knowledge Backend with AI
Open Brain: Building a Personal Knowledge Backend with AI What if your notes could think? Not in a sci fi way — but in a practical, "I wrote something three months ago th…
Raiffeisen Bank: End-to-End Online Account Opening
Raiffeisen Bank: End to End Online Account Opening When Raiffeisen Bank decided to let customers open a bank account entirely online — no branch visit required — they kne…