- Cách các tác tử lập trình AI tiêu thụ tài liệu về cơ bản khác con người, nên chỉ tối ưu theo hướng con người sẽ khiến ngày càng nhiều lưu lượng AI biến mất mà không được công cụ phân tích ghi nhận
- Tác tử lấy tài liệu bằng một yêu cầu HTTP duy nhất, đếm số token rồi âm thầm loại bỏ nếu không vừa cửa sổ ngữ cảnh, nên các chỉ số phân tích truyền thống như độ sâu cuộn trang, thời gian lưu lại hay lượt nhấp hoàn toàn không được ghi lại
- Để đối phó, khái niệm Agentic Engine Optimization (AEO) được đưa ra nhằm cấu trúc, định dạng và cung cấp tài liệu sao cho tác tử thực sự có thể sử dụng
- Cốt lõi của AEO là khả năng được phát hiện, khả năng phân tích cú pháp, hiệu quả token, báo hiệu năng lực, kiểm soát truy cập; chỉ cần một yếu tố thất bại, tác tử có thể bỏ qua nội dung hoặc tạo ra đầu ra sai
- Những đội ngũ phản ứng sớm sẽ giành được lợi thế để API của mình được tác tử đề xuất và tích hợp, và việc viết tài liệu cho tác tử rốt cuộc cũng tạo ra tài liệu tốt hơn cho người đọc
AEO là gì
- Agentic Engine Optimization (AEO) là cách thực hành cấu trúc, định dạng và cung cấp nội dung kỹ thuật để các tác tử lập trình AI có thể thực sự tận dụng
- Nếu SEO là tối ưu cho trình thu thập tìm kiếm và mô hình nhấp của con người, thì AEO nhắm tới một nhóm người tiêu thụ mới là các tác tử AI tự động lấy, phân tích cú pháp và suy luận từ nội dung
- Các yếu tố cần cân nhắc cốt lõi
- Discoverability – Tác tử có thể tìm thấy tài liệu mà không cần render JavaScript không
- Parsability – Máy có thể đọc được mà không cần diễn giải bố cục trực quan không
- Token efficiency – Có vừa trong cửa sổ ngữ cảnh thông thường của tác tử mà không bị cắt cụt không
- Capability signaling – API có cho biết “nó làm được gì” thay vì “gọi như thế nào” không
- Access control –
robots.txt có thực sự cho phép lưu lượng AI không
Cách tác tử đọc tài liệu
- Mô hình của con người: vào trang chủ tài liệu, chuyển giữa các phần, lướt tiêu đề, chạy ví dụ mã, đi qua 2–3 liên kết nội bộ, ở lại 4–8 phút mỗi phiên → công cụ phân tích ghi nhận toàn bộ
- Mô hình của tác tử: theo một bài nghiên cứu phân tích lưu lượng HTTP của 9 tác tử lập trình lớn như Claude Code, Cursor, Cline, Aider, VS Code, Junie..., việc duyệt nhiều trang bị nén còn 1–2 yêu cầu HTTP
- Nhận toàn bộ trang bằng một yêu cầu
GET rồi mới di chuyển tiếp, khái niệm “user journey” sụp đổ thành một sự kiện duy nhất phía máy chủ
- Toàn bộ sự kiện phía client như độ sâu cuộn trang, thời gian lưu lại, nhấp nút, hoàn tất tutorial, điều hướng liên kết hay tương tác biểu mẫu đều trở nên vô hình
Dấu vân tay của lưu lượng AI
- Trong log máy chủ tồn tại những chữ ký riêng có thể dùng để nhận diện lưu lượng từ tác tử
- Aider: Headless Chromium (Playwright), GET theo nhu cầu, user-agent đầy đủ kiểu Mozilla/Safari
- Claude Code: Node.js/Axios, GET theo nhu cầu,
axios/1.8.4
- Cline: curl, quét GET + OpenAPI/Swagger,
curl/8.4.0
- Cursor: Node.js/got, thăm dò HEAD → GET,
got (sindresorhus/got)
- Junie: curl, GET nhiều trang tuần tự,
curl/8.4.0
- OpenCode: Headless Chromium (Playwright), GET theo nhu cầu
- VS Code: Electron/Chromium, kiểu Chromium có marker Electron
- Windsurf: Go/Colly,
colly
- Ngoài tác tử lập trình, các dịch vụ web trợ lý AI như ChatGPT, Claude, Google Gemini, Perplexity cũng tạo ra server-side fetch khi người dùng chia sẻ URL, và tạo dấu vân tay riêng
Vấn đề token: tài liệu có thể vô hình với tác tử
- Tác tử thường có giới hạn thực tế khoảng 100K–200K token, và quản lý ngữ cảnh là ràng buộc luôn hiện diện trong mọi tác vụ
- Ví dụ trong nghiên cứu: Cisco Secure Firewall Management Center REST API Quick Start Guide (Version 10.0) có 193.217 token, khoảng 718.000 ký tự, đủ để dùng hết hoặc vượt quá cửa sổ ngữ cảnh khả dụng của phần lớn tác tử chỉ với một tài liệu
- Khi tài liệu quá dài, có thể xảy ra
- Bị cắt cụt âm thầm làm mất thông tin quan trọng
- Bị bỏ qua vì tác tử ưu tiên tài liệu ngắn hơn
- Việc cố chia nhỏ làm tăng độ trễ và bề mặt lỗi
- Fallback sang tri thức tham số — tức tạo ra ảo giác
- Kết luận: số token giờ là chỉ số hạng nhất của tài liệu, và việc theo dõi token theo từng trang là bắt buộc
Mục tiêu token thực tế
- Trang Quick start / getting started: dưới 15.000 token
- Trang tham chiếu API riêng lẻ: dưới 25.000 token
- Toàn bộ API reference: chia theo resource/endpoint thay vì theo sản phẩm
- Hướng dẫn khái niệm: dưới 20.000 token, nối sang nội dung chi tiết bằng liên kết thay vì nhúng trực tiếp
Stack AEO: những gì thực sự cần xây
- AEO không phải một kỹ thuật đơn lẻ mà là một tập hợp tín hiệu và tiêu chuẩn nhiều lớp từ nền tảng tới bề mặt
Layer 1: kiểm soát truy cập (robots.txt)
- Nhiều tác tử kiểm tra
robots.txt trước khi lấy nội dung, nên cấu hình sai có thể chặn truy cập tài liệu một cách âm thầm mà không báo lỗi
- Các bước thực hiện
- Kiểm tra các chặn ngoài ý muốn với user-agent của tác tử AI
- Xem xét cho phép rõ ràng các mẫu phổ biến như crawler của Anthropic, OpenAI, Google, Perplexity
- Nếu cần kiểm soát chi tiết hơn, dùng
agent-permissions.json (một đặc tả mới nổi để khai báo phạm vi tương tác tự động được phép, rate limit, endpoint API ưu tiên...)
Layer 2: llms.txt để tăng khả năng phát hiện
- Một tệp văn bản phẳng định dạng Markdown được lưu tại
yourdomain.com/llms.txt, đóng vai trò như sitemap cho tác tử AI
- Cung cấp thư mục tài liệu có cấu trúc và mô tả để tác tử hiểu nội dung liên quan mà không cần crawl toàn bộ website
- Ví dụ cấu trúc: Getting Started (Quick Start Guide, Authentication, Core Concepts), API Reference (REST API Overview, Users API 12K token, Events API 8K token), MCP Integration (MCP Server)
- Đặc điểm của
llms.txt tốt
- Mô tả có thể tìm thấy gì chứ không chỉ tên trang
- Bao gồm số token theo trang nếu hữu ích
- Tổ chức theo task thay vì theo tầng sản phẩm
- Giữ kích thước của chính nó dưới 5.000 token (chỉ mục không được vượt ngân sách)
Layer 3: báo hiệu năng lực bằng skill.md
- Nếu
llms.txt cho biết “ở đâu”, thì skill.md cho biết sản phẩm “làm được gì”
- Thay vì buộc tác tử phải suy ra năng lực từ tài liệu văn xuôi, nó ánh xạ ý định sang endpoint/resource theo cách khai báo
- Cấu trúc ví dụ cho dịch vụ xác thực
- What I can accomplish: xác thực OAuth 2.0 (authorization code, client credentials, PKCE), cấp và xác minh JWT token, quản lý session và refresh token rotation, tích hợp SSO (SAML, OIDC)
- Required inputs: Client ID/Secret, Redirect URI đã đăng ký trước, scope được yêu cầu (
read:user, write:data, admin)
- Constraints: 1000 yêu cầu token mỗi phút cho mỗi ứng dụng, access token 1 giờ và refresh token 30 ngày, client công khai bắt buộc dùng PKCE
- Key documentation: OAuth 2.0 Guide, Token Reference, Postman Collection
- Tác tử có thể đánh giá liệu API có đáp ứng được ý định của người dùng hay không trước khi tiêu tốn ngân sách ngữ cảnh để đọc toàn bộ tài liệu
Layer 4: định dạng nội dung cho tác tử phân tích cú pháp
- Cung cấp Markdown chứ không chỉ HTML — cho phép truy cập Markdown gốc bằng cách thêm
.md vào URL hoặc qua query parameter, giúp giảm mạnh chi phí token do không có thẻ, điều hướng hay footer gây nhiễu
- Cấu trúc để quét thay vì chỉ để đọc
- Hệ thống tiêu đề nhất quán (H1 → H2 → H3, không bỏ cấp)
- Mỗi phần bắt đầu bằng kết quả (outcome) chứ không phải bối cảnh
- Ví dụ mã đặt ngay sau phần giải thích
- Phần tham chiếu tham số dùng bảng để nén tốt hơn thay vì danh sách văn xuôi
- Loại bỏ nhiễu điều hướng như sidebar, breadcrumb hay liên kết footer
- Trong 500 token đầu tiên của mỗi trang phải trả lời được: “đây là gì, có thể làm gì với nó, và cần gì để bắt đầu”
Layer 5: phơi bày số token
- Hiển thị số token trong chỉ mục
llms.txt và trên chính trang (metadata hoặc header trang)
- Ví dụ cách tác tử sử dụng thông tin này
- “Trang này 8K token — có thể nạp toàn bộ vào ngữ cảnh”
- “Trang này 150K token — chỉ nên lấy phần liên quan”
- “Vượt cửa sổ ngữ cảnh — dùng tóm tắt trong llms.txt”
- Có thể triển khai bằng cách đếm ký tự phía máy chủ rồi chia xấp xỉ cho 4, sau đó hiển thị trong meta tag hoặc HTTP response header
Layer 6: “Copy for AI”
- Khi lập trình viên muốn đưa tài liệu vào ngữ cảnh của trợ lý AI trong IDE, việc sao chép HTML đã render sẽ kéo theo cả nhiễu từ điều hướng và footer
- Nút “Copy for AI” sao chép Markdown sạch vào clipboard giúp cải thiện đáng kể chất lượng ngữ cảnh mà tác tử nhận được
- Anthropic, Cloudflare và một số bên khác đã phát hành các biến thể của cách này; chi phí thấp nhưng tín hiệu cao
AGENTS.md: tiêu chuẩn mặc định đang nổi lên
- Giống như
README.md từng là điểm vào của nhà phát triển với repository, AGENTS.md đang nổi lên như điểm vào của tác tử AI
- Khi mở dự án, tác tử lập trình sẽ tìm
AGENTS.md ở thư mục gốc và dùng nó làm chỉ dẫn cho mọi công việc tiếp theo
- Một
AGENTS.md tốt nên gồm
- Cấu trúc dự án và vị trí các tệp quan trọng
- Liên kết trực tiếp tới tài liệu của API/dịch vụ liên quan
- Sandbox phát triển và môi trường test sẵn có
- Rate limit và ràng buộc mà tác tử cần biết
- Các pattern và convention được ưa dùng trong codebase
- Liên kết tới MCP server nếu có
- Cisco DevNet đã chọn tệp này làm mặc định trong template GitHub cho dự án mã nguồn mở; khi tạo dự án mới, một
AGENTS.md theo từng dự án sẽ được điền sẵn các liên kết tới tài liệu OpenAPI, DevNet sandbox và môi trường test
Giám sát lưu lượng referral từ AI
- Việc có thể làm ngay: bắt đầu theo dõi lưu lượng referral từ AI trong công cụ phân tích
- Các nguồn referral cần theo dõi: labs.perplexity.ai/referral, chatgpt.com/(none), chatgpt.com/organic, link.edgepilot.com/referral, platform.openai.com/referral, perplexity/(not set), claude.ai/referral, copilot.microsoft.com/referral, gemini.google.com/referral
- Với lưu lượng tác tử trực tiếp không có referrer, có thể nhận diện bằng các dấu vân tay HTTP đã nêu (
axios/1.8.4, curl/8.4.0, got (sindresorhus/got), colly)
- Việc xây dựng phân đoạn lưu lượng AI hợp lý sẽ cung cấp chỉ báo dẫn dắt để đánh giá hiệu quả của công việc AEO
Hàm ý rộng hơn đối với trải nghiệm lập trình viên
- Từ trước đến nay, cổng thông tin dành cho nhà phát triển được thiết kế xoay quanh progressive disclosure, phân cấp thị giác, ví dụ tương tác, tutorial có dẫn dắt theo mô hình nhận thức của con người
- Những giả định bị phá vỡ trong thế giới lấy tác tử làm trung tâm
- Phân cấp thị giác trở nên vô nghĩa — tác tử đọc văn bản chứ không đọc bố cục
- Progressive disclosure trở thành chướng ngại — tác tử muốn có mọi thứ cùng lúc
- Ví dụ tương tác mất giá trị — nếu không có phiên bản tĩnh/API tương đương thì gần như vô dụng
- User journey sụp đổ — tutorial nhiều trang trở thành một lần nạp ngữ cảnh duy nhất
- Thiết kế lấy con người làm trung tâm sẽ không biến mất, nhưng con người cũng ngày càng đọc tài liệu bên trong ngữ cảnh của trợ lý AI
- Tài liệu tốt nhất trong tương lai phải vừa dễ quét, cấu trúc tốt cho con người, vừa máy đọc được và hiệu quả token cho tác tử
Checklist kiểm tra AEO
Discovery
- Có
llms.txt ở thư mục gốc chứa chỉ mục tài liệu có cấu trúc
robots.txt không vô tình chặn các user-agent tác tử AI phổ biến
- Dùng
agent-permissions.json để định nghĩa quy tắc truy cập cho client tự động
- Có
AGENTS.md liên kết tới tài liệu liên quan trong repository mã nguồn
Content structure
- Cung cấp trang tài liệu dưới dạng Markdown sạch thay vì HTML đã render
- Mỗi trang đặt một tuyên bố kết quả rõ ràng trong 200 từ đầu tiên
- Tiêu đề nhất quán và đúng thứ bậc
- Ví dụ mã nằm ngay sau phần giải thích văn xuôi
- Tham chiếu tham số dùng bảng thay vì văn xuôi lồng nhau
Token economics
- Theo dõi số token theo từng trang tài liệu
- Không có trang đơn nào vượt quá 30.000 token nếu chưa có chiến lược chia nhỏ
- Hiển thị số token của các trang chính trong
llms.txt
- Cung cấp số token trong metadata trang (meta tag hoặc HTTP header)
Capability signaling
- Tệp
skill.md mô tả chức năng của từng dịch vụ/API thay vì cách gọi
- Mỗi skill bao gồm capabilities, required inputs, constraints, key doc links
- Cung cấp MCP server cho tích hợp trực tiếp với tác tử nếu phù hợp
Analytics
- Phân đoạn các nguồn referral từ AI trong phân tích web
- Theo dõi log máy chủ theo các dấu vân tay HTTP của tác tử AI đã biết
- Thiết lập đường cơ sở cho tỷ lệ lưu lượng AI so với con người
UX bridge
- Có nút “Copy for AI” trên trang tài liệu
- Có thể truy cập Markdown gốc bằng quy ước URL (ví dụ thêm
.md)
Tooling
- Đã công bố công cụ kiểm tra nhẹ agentic-seo, quét
llms.txt, tình trạng chặn tác tử trong robots.txt, số token, khả năng cung cấp Markdown... — một kiểu Lighthouse cho mức độ sẵn sàng với tác tử
Nên bắt đầu từ đâu
- Thứ tự khuyến nghị
- Kiểm tra
robots.txt — việc 10 phút, ngăn chặn khóa tác tử âm thầm
- Thêm
llms.txt — vài giờ, cải thiện ngay khả năng được phát hiện
- Đo và hiển thị số token — một dự án cuối tuần nhưng đòn bẩy lớn
- Viết
skill.md cho 3 API hàng đầu — bắt đầu từ những gì tác tử truy cập nhiều nhất
- Thêm nút “Copy for AI” — chi phí thấp, tín hiệu cao
- Thiết lập giám sát lưu lượng AI — có dữ liệu để chứng minh phần việc còn lại
Kết
- Cũng như SEO từng dạy rằng “chỉ có nội dung tốt là chưa đủ, còn phải làm cho nó dễ được tìm thấy theo mô hình lưu lượng thực tế của thời đại đó”, AEO mang lại bài học tương tự cho một nhóm người tiêu thụ mới
- Các tác tử lập trình AI đã chiếm một tỷ trọng đáng kể và đang tăng trong lưu lượng tài liệu, đồng thời vận hành theo cách khác biệt căn bản với người đọc
- Những đội phản ứng sớm sẽ có lợi thế để API của mình được tác tử đề xuất, tích hợp thành công và tái sử dụng
- Những đội không phản ứng sẽ đối mặt với chế độ lỗi âm thầm khó debug, nơi khoảng cách giữa chất lượng tài liệu và tỷ lệ thành công thực tế của công việc do tác tử thực hiện ngày càng lớn
- Xây dựng cho tác tử rốt cuộc cũng tạo ra tài liệu tốt hơn cho con người, và hai hướng này chồng lấn lên nhau nhiều hơn là tách rời
Chưa có bình luận nào.