3 điểm bởi bejoyfuuul 2026-03-18 | 7 bình luận | Chia sẻ qua WhatsApp

Xin chào.

Trong quá trình phát triển cùng AI, khi làm các việc như xem xét những website khác, tôi thường xuyên gặp tình huống token nhanh chóng cạn kiệt và phải chờ reset.
Nghĩ lại thì tôi thấy có cảm giác AI đang "nhìn vào một màn hình mà con người có thể đọc bằng mắt".
Vì vậy tôi nghĩ cần có một phương án thay thế mang tính tiêu chuẩn để giảm token và tăng tốc độ phản hồi của AI.

Hiện tại, để AI agent đọc một dịch vụ web thì thường có khoảng ba cách như sau:

  1. Cào HTML — hơn 80% nội dung trả về là nhiễu từ quảng cáo, điều hướng và script (~hàng chục nghìn token)
  2. Đọc tài liệu API rồi hardcode — dịch vụ thay đổi là lại hỏng mỗi lần
  3. Dùng MCP — rất ít dịch vụ có, và chủ yếu dành cho nhà phát triển

Vì vậy tôi đã làm mã nguồn mở này để đề xuất một quy ước theo luồng sau.

  • robots.txt (1994) → nói với crawler: "đừng vào đây"
  • sitemap.xml (2005) → nói với crawler: "nó ở đây"
  • /ai (2026) → nói với AI agent: "chúng tôi có thể làm gì" ← thứ còn thiếu chính là cái này

(Trong lúc làm và tìm hiểu thêm, tôi thấy robots.txt ban đầu cũng được đề xuất lần đầu bởi Martijn Koster, một kỹ sư phần mềm người Hà Lan. Nó được tạo ra để giải quyết vấn đề các web crawler thời kỳ đầu gây tải quá lớn lên máy chủ.)

Tôi muốn các bên đang sở hữu dịch vụ web triển khai GET /ai để

  • AI agent có thể ngay lập tức đọc thông tin có cấu trúc
  • và có thể chuyển dần sang việc gọi API trực tiếp
  • không cần scraping, không cần parsing tài liệu, không lãng phí token

Có thể kiểm tra tại đây.

curl https://api.aiendpoint.dev/ai | jq .  

Đây là những gì tôi đã làm đến nay (with claude, codex)

  • Open spec (Apache 2.0) — https://github.com/aiendpoint/platform
  • Registry — aiendpoint.dev (đăng ký·tìm kiếm)
  • Validator — aiendpoint.dev/validate (chấm điểm từ 0 đến 100)
  • MCP server — tìm trực tiếp trong registry từ Claude/Cursor
  • Kỹ năng Claude Code — tự động thêm /ai vào dịch vụ hiện có (10 phút)

Nếu không có MCP server thì registry chỉ là một website.
Nếu có MCP server, khi bạn nói với Claude "hãy tìm cho tôi một weather API có thể dùng mà không cần xác thực"
thì nó sẽ ngay lập tức đưa ra câu trả lời có cấu trúc.
Mấu chốt là khép kín được vòng lặp này.

Rất hoan nghênh phản hồi về spec.
Cần điều gì để khiến các bạn triển khai /ai trong dịch vụ của mình?
Tôi mong chúng ta có thể cùng tham gia và xây dựng nên tiêu chuẩn này.
Giống như robots.txt lần đầu được đề xuất ở Hà Lan, biết đâu chúng ta cũng có thể tạo ra một làn sóng như vậy?

GitHub: https://github.com/aiendpoint/platform

7 bình luận

 
aliveornot 2026-03-20

llm.txt trước đây đã từng được đề xuất, và cũng có cả bài báo nghiên cứu về tính hiệu quả của nó. Theo Naver, ít nhất ở thời điểm hiện tại thì có vẻ các agent cũng chưa xem nó nhiều.

 
aliveornot 2026-03-20

Theo Naver mà nói thì... viết lúc đang ngủ à... Phải là "theo bài luận văn đó" mới đúng.

 
bejoyfuuul 2026-03-21

Haha, bạn nói rất đúng.
Nếu llms.txt tập trung vào phần mô tả để agent "hiểu" dịch vụ, thì /ai lại tập trung vào việc AI "sử dụng" dịch vụ. Tức là nó cho AI biết: "API của dịch vụ chúng tôi được gọi như thế này". Nếu dùng thêm MCP ở đây, thì có thể bắt đầu bằng cách "lướt qua" cách sử dụng của trang đó trước (tiết kiệm token).

Có lẽ vì việc tham gia trực tiếp còn khó khăn, nên trước mắt chúng tôi chia thành phiên bản "đăng ký trực tiếp" và "cộng đồng"; vì vậy khi dùng /ai MCP, với những trang mà "đã từng có ai đó search" rồi, có thể tiếp cận nhẹ hơn và nhanh hơn!

Cảm ơn bạn đã chia sẻ~

 
vndk2234 2026-03-18

Nếu /ai được chuẩn hóa, thì ngược lại cũng có thể sẽ xuất hiện một công cụ chỉ cần quét /ai rồi hiển thị một trang đẹp, không có quảng cáo, phải không?

 
dohyun682 2026-03-18

Thú vị đấy! Vậy thì chắc cũng sẽ có chuyện chèn quảng cáo vào /ai nhỉ

 
bejoyfuuul 2026-03-18

Vậy thì có lẽ cần bổ sung logic hạ điểm số khi phát hiện nội dung quảng cáo!

 
bejoyfuuul 2026-03-18

Vâng. Hoàn toàn có khả năng. Ngoài ra, vì các lý do như mức sử dụng (traffic) của agent, xử lý, chi phí token, tôi cũng nghĩ rằng bản thân web về một mặt có thể sẽ trở nên nhẹ hơn như thời telnet ngày xưa. (tập trung vào nội dung hơn là trang trí) Giống như GeekNews hiện tại vậy. (chỉ là phỏng đoán thôi!)