OKF của Google: đóng gói tri thức cho AI agent — và kinh nghiệm triển khai thực tế

Ngày 12/06/2026, Google Cloud công bố OKF — Open Knowledge Format (bản v0.1): một chuẩn mở, trung lập nhà cung cấp để đóng gói *tri thức* mà một AI agent cần, dưới dạng thư mục file Markdown. Chúng tôi tải bộ mẫu chính thức về, mổ xẻ từng file, rồi rút ra những kinh nghiệm triển khai thực tế dưới đây — nhìn OKF "chạy thật" thay vì chỉ đọc thông cáo.

OKF là gì, trong một phút

Một "bundle" OKF là một thư mục Markdown. Mỗi file là một "concept" — một bảng dữ liệu, một dataset, một chỉ số (metric), một quy trình, một API… bất cứ đơn vị tri thức nào. Đường dẫn file chính là danh tính của concept.

Mỗi file gồm hai phần: một khối YAML frontmatter (chỉ type là bắt buộc, kèm các trường tùy chọn title, description, resource, tags, timestamp) và một thân Markdown tự do. Các concept trỏ tới nhau bằng link Markdown thường, và thế là cả thư mục biến thành một đồ thị tri thức.

Không SDK, không runtime, không registry trung tâm. Tinh thần của spec gói gọn: nếu bạn "cat" được một file thì bạn đọc được OKF; nếu bạn "git clone" được một repo thì bạn chuyển giao được nó. Vì sao đáng để ý? Một AI agent chỉ thông minh bằng đúng lượng ngữ cảnh ta đưa cho nó — và OKF chuẩn hóa cách đóng gói phần ngữ cảnh đó để nhiều hệ thống cùng đọc được.

Chúng tôi đã thử gì

Chúng tôi tải ba bộ mẫu chính thức trong repo GoogleCloudPlatform/knowledge-catalog: dữ liệu thương mại điện tử GA4, dữ liệu Stack Overflow, và dữ liệu blockchain Bitcoin. Đọc kỹ bản đặc tả và từng concept trong đó, đây là những gì rút ra.

Bảy kinh nghiệm khi triển khai OKF

1. Tri thức nằm ở "cách làm", không phải ở danh sách cột. Trong bộ mẫu, mỗi metric mang theo câu SQL thật để tính nó; mỗi "join" mang theo đúng điều kiện ghép bảng. Danh mục dữ liệu (data catalog) của bạn vốn đã có schema rồi — thứ OKF chứa là phần "nằm trong đầu người senior": grain của bảng, cách tính một chỉ số, các lưu ý ngầm.

2. Chọn một bộ "type" nhỏ và nhất quán. Tuy spec chỉ ép mỗi trường type, bộ mẫu chỉ dùng vài giá trị lặp lại: Dataset, Table, Reference. type chính là cái trục để lọc, tô màu, và định tuyến khi tiêu thụ — giữ nó gọn thì cả bundle mới dễ điều hướng.

3. Quan hệ viết bằng văn xuôi và link, không phải bằng cạnh có kiểu. Bảng "transactions" của Bitcoin dẫn tới "blocks", "inputs", "outputs" ngay trong câu văn; đồ thị tự hiện ra từ các link đó. Nên dùng link tuyệt đối theo bundle (bắt đầu bằng dấu "/") để không gãy khi di chuyển file.

4. Sinh trước, tinh sau. Agent tham chiếu của Google chạy hai lượt: lượt đầu dựng khung từ nguồn sự thật (metadata của kho dữ liệu), lượt sau bò theo tài liệu chính thống để bồi thêm chi tiết và trích dẫn. Bài học: đừng viết tay từ số 0 — tự động dựng bộ khung, rồi con người biên tập phần tinh.

5. index.md để "tiết lộ dần". Mỗi thư mục có thể kèm một index.md liệt kê nội dung bên trong, để agent (hay người) duyệt từng tầng thay vì nuốt cả bundle vào ngữ cảnh. Điều này quyết định khi tri thức lớn còn cửa sổ ngữ cảnh thì hữu hạn.

6. Chấp nhận không hoàn hảo — và ship. Ngay trong bộ mẫu, trường tags của dataset Stack Overflow bị viết thành một chuỗi thay vì một danh sách YAML — nhưng spec cố tình "dễ tính": consumer vẫn phải đọc được. Vì bundle chỉ là file trong git, việc biên tập tri thức trở thành pull request và diff bình thường; cứ ship rồi sửa dần.

7. Ghi rõ độ cũ và độ tin. Ngoài trường timestamp, dataset Stack Overflow ghi thẳng trong văn bản: "cập nhật lần cuối 2022-11-25, không còn được bảo trì". Agent cần biết một concept đáng tin tới đâu — hãy nói ra, đừng để nó đoán.

Áp dụng cho vài lĩnh vực

Kho dữ liệu và BI. Concept là dataset, bảng, metric, join. Nhúng thẳng câu SQL cho từng metric và khóa ghép cho từng join. Kết quả: chấm dứt cảnh mỗi người trong công ty tự định nghĩa lại "doanh thu" hay "khách hàng hoạt động" một kiểu.

API và hệ thống nội bộ. Concept là endpoint, schema, playbook. Thân file mô tả request/response, cách xác thực, ngữ nghĩa lỗi, và link tới runbook. Tham chiếu file OpenAPI qua trường resource thay vì chép lại — OKF trỏ tới các chuẩn khác, không nuốt chúng.

Nghiệp vụ và vận hành. Concept là chính sách, playbook, quy trình xử lý sự cố. Đây đúng là chỗ OKF tỏa sáng: đóng gói phần tri thức vốn "nằm trong đầu vài người" — các bước duyệt, cách phản ứng khi có cảnh báo — thành tài liệu đọc được, cho cả người lẫn agent.

Trợ lý AI chạy on-prem. Vì OKF chỉ là file thuần, cả bundle nằm gọn trong git hoặc hệ thống tập tin sau tường lửa của bạn; một mô hình chạy nội bộ đọc thẳng, không cần một dịch vụ metadata trên đám mây đứng giữa. Dữ liệu tri thức không phải rời khỏi nhà.

OKF khác gì những thứ bạn đã có

Khác llms.txt: llms.txt là một file hướng dẫn duy nhất cho mô hình; OKF là nhiều concept có kiểu, nối thành đồ thị. Khác schema.org: cái kia là dữ liệu cấu trúc phục vụ SEO cho trình duyệt và cỗ máy tìm kiếm; OKF là tri thức phục vụ agent. Khác RAG: thay vì băm nhỏ tài liệu rồi tìm bằng vector, agent duyệt một thư viện đã được biên tập.

Và nó bổ trợ cho MCP: MCP (cùng phiên bản trên trình duyệt là WebMCP) là cách agent gọi công cụ; OKF là cách agent đọc tri thức. Website tetra.vn của chúng tôi đã mở công cụ cho agent qua WebMCP — OKF chính là lớp "tri thức" đi kèm lớp "công cụ" đó. Nếu tò mò, mời đọc bài viết về WebMCP của chúng tôi.

Góc nhìn của chúng tôi

OKF hợp với hướng đi mà Tetra theo đuổi: đưa AI chạy tại chỗ và làm cho sản phẩm, website sẵn sàng cho agent. Vì là file thuần cộng git, OKF vận hành tốt sau tường lửa — đúng bài toán chủ quyền dữ liệu mà nhiều tổ chức ở Việt Nam đang quan tâm.

Nhưng đừng thần thánh hóa. Đây mới là v0.1, còn rất sớm. Giá trị thật không đến từ việc sinh ra Markdown — ai cũng sinh được — mà đến từ việc biên tập tri thức: chọn đúng metric, viết đúng định nghĩa, nêu đúng lưu ý. Cái khó, và cũng là cái đáng tiền, nằm ở đó.

Cần một tay?

Nếu tổ chức của bạn muốn biến tri thức đang rời rạc — kho dữ liệu, tài liệu API, quy trình vận hành — thành một bundle OKF cho trợ lý AI, nhất là loại chạy on-prem, Tetra có thể đồng hành từ khâu dựng khung tới khâu biên tập. Đặt lịch tư vấn với chúng tôi.