Open Knowledge Format (OKF) so với Agent Skills

Chúng ta đang đối mặt với thách thức mới trong kiến trúc agent: giờ đây có hai tiêu chuẩn mở hoàn toàn mới để định nghĩa kiến thức cho AI agent. Chỉ trong vài tháng, Google đã phát hành Open Knowledge Format (OKF) và Anthropic mã nguồn mở Agent Skills.

Vì các tiêu chuẩn này còn mới, ngành công nghiệp vẫn đang tìm cách sử dụng chúng. Trước khi áp dụng bất kỳ chuẩn nào, bạn cần hiểu sự khác biệt cơ bản giữa chúng:

Agent Skills (Anthropic): Thiết kế để kích hoạt tự động. Nó sử dụng mô tả ngôn ngữ tự nhiên để model tự quyết định khi nào nạp skill vào context.
Open Knowledge Format (Google): Thiết kế cho dữ liệu có kiểu có cấu trúc. Nó hoạt động như một cơ sở dữ liệu khái niệm (ví dụ: type: table, type: metric) where code orchestration của bạn chủ động quyết định cần truy xuất gì.

Tại QuotyAI, việc xây dựng các hệ thống agentic production cho voice và chat đã dạy chúng tôi rằng việc chọn cách tổ chức kiến thức agent không chỉ là sở thích về format — mà là một quyết định kiến trúc có ảnh hưởng lớn.

Sự khác biệt giữa agent demo và agent production không nằm ở model — mà ở việc agent có thể thực thi code, truy vấn dữ liệu trực tiếp và xử lý lỗi một cách xác định hay không.

Trong bài viết này, chúng ta sẽ định nghĩa sự khác biệt giữa hai tiêu chuẩn mới này, xem tại sao và cách bạn có thể sử dụng chúng, cùng tìm hiểu khi nào bạn nên bỏ qua hoàn toàn các file tĩnh để chuyển sang runtime xác định.

Vấn đề: Làm thế nào model biết được?

Một foundation model không biết gì về bảng orders của bạn. Nó không biết rằng confirmed_at là timestamp đúng để báo cáo doanh thu, chứ không phải created_at. Nó không biết rằng bảng customers liên kết qua customer_id. Nó không biết các định nghĩa metric, các API nội bộ, hay quy trình xử lý khi pipeline gặp sự cố.

Ai đó phải nói cho nó biết. Câu hỏi là: theo format nào, lưu ở đâu, tiêu thụ như thế nào?

OKF và Agent Skills là hai câu trả lời cho câu hỏi đó. Chúng có chung DNA nhưng đưa ra những quyết định kiến trúc khác nhau.

Context window của model không phải là vô hạn. Mỗi dòng Markdown không có kiểu cạnh tranh sự chú ý với tác vụ thực tế. Bạn càng nạp nhiều văn bản không liên quan, model càng khó tập trung vào điều quan trọng — và càng dễ bịa đặt chi tiết từ nhiễu.

OKF thực sự làm gì

OKF là một thư mục các file Markdown. Mỗi file đại diện cho một khái niệm — một bảng, một metric, một API, một quy trình. Field bắt buộc duy nhất trong YAML frontmatter là type. Mọi thứ khác là tùy chọn.

---
type: table
title: orders
resource: bigquery://my-project.ecommerce.orders
tags: [ecommerce, source-of-truth]
---

Primary key: `order_id`. Joins to `customers` on `customer_id`.
Use `confirmed_at` for revenue reporting — not `created_at`, which includes abandoned carts.

Một bundle là một thư mục chứa các file này. Các bundle có thể tham chiếu chéo nhau, vì vậy metric revenue có thể liên kết đến khái niệm bảng orders mà nó được tính toán từ đó.

Không SDK. Không tài khoản Google Cloud. Không runtime. Bất kỳ công cụ nào đọc được thư mục các file đều có thể tiêu thụ OKF — đó là mục tiêu thiết kế rõ ràng.

Cách agent tiêu thụ: orchestrator bên ngoài quyết định cần truy xuất gì. Agent có thể nhận toàn bộ bundle trong context, hoặc gọi một tool để truy vấn bundle theo type hoặc từ khóa. Logic chọn lọc nằm trong code của bạn, không phải trong format.

Agent Skills thực sự làm gì

Một Skill là một thư mục. Bên trong: một SKILL.md kèm các file hỗ trợ — script, template, output mẫu, tài liệu tham khảo.

SKILL.md có hai nhiệm vụ riêng biệt. Field description hoạt động như một bộ kích hoạt ngữ nghĩa — Claude đọc nó và quyết định skill này có áp dụng cho tác vụ hiện tại hay không. Phần nội dung chứa bất cứ điều gì bạn muốn Claude biết hoặc thực hiện: quy trình, tài liệu schema, hướng dẫn thương hiệu, mẫu SQL.

---
name: orders-schema
description: >
  Use when the task involves querying, analyzing, or joining the orders table,
  including revenue calculations or customer purchase history.
---

Table location: `bigquery://my-project.ecommerce.orders`
Primary key: `order_id`. Join to `customers` on `customer_id`.
For revenue: use `confirmed_at`, not `created_at`.

Khi Claude gặp một tác vụ, nó đọc mô tả của mỗi skill có sẵn và quyết định có nên nạp nội dung đầy đủ hay không. Điều này xảy ra tự động — không cần prompt engineering hay code orchestration.

Sự khác biệt kiến trúc chính so với OKF: Claude thực hiện việc chọn lọc, không phải code của bạn. Logic kích hoạt nằm trong reasoning của model.

Khi quy mô lớn làm hỏng cả hai format

Cả hai format đều hỗ trợ kiến thức và quy trình ngang nhau. Cả hai đều sử dụng Markdown kèm YAML, thuộc về version control, và có resource references. Mô hình nội dung gần như giống hệt nhau, nhưng mô hình tiêu thụ thì khác:

OKF: code orchestration xác định của bạn quyết định cần truy xuất gì, khi nào, và cho agent nào.
Skills: model xác suất (Claude) quyết định cần nạp gì dựa trên việc khớp tác vụ.

Ở quy mô nhỏ, cả hai đều hoạt động tốt. Nhưng giả sử bạn có 150 bảng across ba domain dữ liệu. Đây là nơi mọi thứ bắt đầu gặp vấn đề trong production.

Với OKF, 150 bảng đồng nghĩa với 150 file. Agent xây dựng query doanh thu sẽ truy xuất orders.md và revenue.md. Usage context tăng theo phạm vi tác vụ, không phải kích thước cơ sở kiến thức. Đây là ưu điểm lớn nhất của OKF. Nhưng nó cũng tạo ra vấn đề riêng: ai đó phải viết code orchestration để truy xuất đúng file đúng lúc. Code đó không tồn tại trong format.

Với Skills, bạn không thể đặt 150 schema vào một file. Khi Claude kích hoạt một skill, nó nạp toàn bộ SKILL.md. Một file chứa 150 schema đồng nghĩa với việc mọi tác vụ liên quan đến dữ liệu đều nạp tất cả 150 schema vào context window, bất kể tác vụ liên quan đến bảng nào. Vì vậy bạn chia nhỏ: một skill cho mỗi domain. Điều này hoạt động cho đến khi bạn phải nạp toàn bộ domain trong khi tác vụ chỉ cần một bảng.

Việc chồng chất text không có kiểu vào context window không làm cho agent thông minh hơn. Nó làm agent mất tập trung. Ở quy mô lớn, truy xuất xác định sẽ luôn ưu việt hơn phỏng đoán xác suất.

Những gì còn thiếu: Hợp đồng chặt chẽ và Tính xác định

Tại QuotyAI, chúng tôi sớm nhận ra rằng độ tin cậy của AI agent chỉ bằng các ràng buộc runtime của nó. Cả OKF và Skills đều không cung cấp được các ràng buộc này.

Thiếu gì ở Skills: Hợp đồng có kiểu (Typed Contracts) Skills cần nhiều hơn field mô tả và nội dung Markdown. Chúng thiếu cái mà chúng tôi gọi là hợp đồng có kiểu:

Không có hệ thống kiểu: Skill tài liệu hóa schema trông giống hệt skill định nghĩa workflow nhiều bước. Không có type: knowledge hay type: procedure.
Không có hợp đồng đầu vào/đầu ra: Skill “tạo SQL query” có thể giả định tên bảng và output format, nhưng Claude suy luận từ văn bản. Không có schema có cấu trúc nào ép buộc đầu vào và đầu ra.
Không có ranh giới lỗi: Khi skill thất bại, nó thất bại mơ hồ. Không có tập hợp mã lỗi xác định (SLOT_UNAVAILABLE, CUSTOMER_NOT_FOUND) mà đường dẫn fallback xác định có thể bắt.

Thiếu gì ở OKF: Agent Execution Hooks OKF mô tả một knowledge graph, nhưng không cung cấp cho agent bản đồ thực thi đi qua nó.

Các khái niệm là thụ động: Khái niệm bảng orders không nói với agent “hãy truy xuất revenue.md trước khi viết bất kỳ query nào.” Agent nhận một khái niệm và suy luận xác suất về việc cần làm gì tiếp theo. Không có agent execution hooks.
Không có sự phân tách design-time vs runtime: Các file OKF là artifact design-time, nhưng agent cần reasoning runtime. File không cung cấp test runner xác định hay trình diễn giải thích để kiểm tra xem agent thực sự đã hiểu khái niệm đó hay chưa.

Sơ đồ trình diễn giải thích trong process truy vấn schema database trực tiếp thay vì phân tích file OKF markdown tĩnh

Con đường thứ ba ưu việt hơn cả hai: Tính xác định như Hạ tầng

Có một lập luận mạnh hơn “sửa OKF, sửa Skills.” Đó là: các file kiến thức tĩnh được soạn sẵn không phải là đơn vị đúng.

Làn sóng RAG 2023 dựa trên “tra cứu tốt hơn” các file tĩnh. Làn sóng agent tiếp theo được xây dựng trên các lớp thực thi xác định. Hướng đầy hứa hẹn hơn là một agent được trang bị trình diễn giải thích trong process (như QuickJS) tính toán những gì nó cần tại runtime thay vì đọc những gì con người đã viết sẵn.

Khi chúng tôi giới thiệu trình diễn giải thích trong process tại QuotyAI, chúng tôi đã đưa độ trễ agent từ trung bình ~2.5s xuống cố định 24ms cho quyết định routing. Tại sao? Vì logic điều kiện và quản lý trạng thái được đưa ra khỏi LLM vào code xác định.

Mục tiêu không phải là làm cho model không bao giờ sai — mà là bắt lỗi nhanh và khôi phục một cách xác định thay vì để lỗi lan truyền âm thầm.

Áp dụng logic tương tự cho kiến thức. Một deep agent không cần file orders.md được viết sẵn. Nó viết một tool call xác định gegen information_schema, lấy schema trực tiếp về, lọc trong sandbox, và đưa cho model ba cột liên quan thay vì ba trăm cột. Không ai phải soạn file đó. Không file nào có thể lỗi thời.

Tại sao truy cập kiến thức được tính toán này ưu việt hơn các file OKF/Skills tĩnh:

Không lỗi thời. Khái niệm OKF là snapshot mà ai đó đã ghi lại. Truy vấn trực tiếp là trạng thái hiện tại. Bảng orders có thể thêm một cột ngày mai; deep agent truy vấn schema trực tiếp sẽ biết ngay lập tức.
“Xong” là một schema, không phải cảm giác. Với evaluation dựa trên rubric và hợp đồng có kiểu, agent không chỉ đọc skill rồi phỏng đoán. Nó thực thi code, và nếu một tiêu chí thất bại, grader xác định sẽ đưa ra feedback có mục tiêu.
Token cost thấp hơn, độ chính xác cao hơn. OKF với file theo từng khái niệm ưu việt hơn việc Skills nạp tất cả hoặc không. Nhưng câu trả lời được tính toán ưu việt hơn cả. Agent không nạp mô tả Markdown 200 từ rồi lý luận về nó — nó chạy DESCRIBE orders, lấy tên cột chính xác, và tiếp tục.

Các team đang vận hành agent đáng tin cậy không phải là những team có hóa đơn model lớn nhất. Họ là những team có AI tooling và hợp đồng mà bạn có thể đọc như schema database.

Khi nào nên dùng cái nào

Bất chấp những thiếu sót, cả hai format đều có thể sử dụng ngay — nếu bạn chọn đúng phạm vi.

Dùng OKF khi:

Bạn có các định nghĩa kinh doanh, kiến thức truyền miệng, và “tại sao” đằng sau một metric không nằm trong database chờ được truy vấn.
Nhiều team cần tiêu thụ cùng một kiến thức có kiểu mà không cần xây dựng lại.

Dùng Skills khi:

Claude là runtime agent chính của bạn.
Bạn có các workflow nhỏ, tập trung cần kích hoạt tự động dựa trên triggers mà không cần viết code orchestration tùy chỉnh.

Dùng thực thi code xác định cho mọi thứ khác:

Cho mọi thứ mang tính cơ khí — “hệ thống trực tiếp trông như thế nào ngay bây giờ?” — dùng trình diễn giải thích trong process hoặc kết nối MCP. Truy vấn sự thật tại runtime thay vì đọc file tĩnh về nó.

Stack này sử dụng mỗi thành phần cho thế mạnh của nó. Nhưng bài học thực sự ở đây lớn hơn việc chọn người thắng giữa OKF và Skills. Kiến trúc agent tốt nhất không phải là cung cấp cho model những file markdown tĩnh tốt hơn để đọc. Nó là việc nhận ra rằng hầu hết “vấn đề về format kiến thức” thực ra chỉ là hạ tầng còn thiếu.

Xây dựng runtime xác định bên dưới model, và vấn đề kiến thức sẽ tự được giải quyết.

Câu hỏi thường gặp

Tại sao OKF và Agent Skills thất bại ở quy mô lớn? Ở quy mô lớn, OKF cần code orchestration thủ công để tải file, trong khi Agent Skills buộc model phải nạp toàn bộ schema vào context window, làm suy giảm độ chính xác của lý luận. Cả hai đều là nút thắt tĩnh.

Hợp đồng skill có kiểu (typed skill contract) là gì? Hợp đồng skill có kiểu là schema chặt chẽ định nghĩa đầu vào, đầu ra và ranh giới lỗi chính xác của năng lực agent, chuyển từ phỏng đoán xác suất sang thực thi code xác định.

Trình diễn giải thích trong process cải thiện agent như thế nào? Trình diễn giải thích trong process cho phép agent thực thi truy vấn trực tiếp và chạy code trong sandbox. Thay vì phân tích tài liệu tĩnh, agent truy vấn hệ thống trực tiếp — nhận được schema hiện tại chính xác thay vì một xấp xỉ đã lỗi thời.