Tối ưu hóa công cụ tác nhân (AEO)

Cách các tác nhân AI tiêu thụ tài liệu kỹ thuật khác biệt căn bản so với con người — và nếu bạn vẫn chỉ tối ưu cho người đọc, bạn đang khiến một phần ngày càng lớn người dùng trở nên “vô hình” với hệ thống của mình. Docs, CLI, MCP, Skills… có cả một hệ sinh thái giao diện mà các tác nhân AI tương tác.

Tôi đã quan sát một hiện tượng đang diễn ra trên các cổng thông tin dành cho lập trình viên và nghĩ rằng nó đáng được chú ý hơn nhiều so với hiện tại.

Một kỹ sư mở Claude Code, yêu cầu nó triển khai một đặc tả rồi nhấn Enter. Tác nhân sẽ lấy một phần tài liệu của bạn. Nó có thể lấy đúng thứ cần thiết, phân tích như văn bản thô, loại bỏ HTML, đếm token, rồi либо dùng làm ngữ cảnh — hoặc âm thầm bỏ qua vì số token vượt quá cửa sổ ngữ cảnh của nó.

Analytics của bạn không ghi nhận điều gì hữu ích. Độ sâu cuộn trang bằng 0. Thời gian trên trang là 400 mili giây. Không click link, không hoàn thành tutorial, không tương tác giao diện. Funnel mà bạn tối ưu suốt nhiều năm không cho thấy gì cả.

Nhưng tác nhân đó thực sự đã ở đó. Nó đã đọc tài liệu của bạn. Và tùy cách tài liệu được cấu trúc, nó либо hoàn thành nhiệm vụ thành công — либо bịa ra giải pháp vì nội dung quá nặng token, cấu trúc kém, hoặc bị chặn bởi tệp robots.txt cấu hình sai.

Tôi bắt đầu gọi lĩnh vực giải quyết vấn đề này là Agentic Engine Optimization.

Agentic Engine Optimization là gì?

Agentic Engine Optimization (AEO) là thực hành cấu trúc, định dạng và phân phối nội dung kỹ thuật sao cho các tác nhân AI viết mã thực sự có thể sử dụng — chứ không chỉ phục vụ người đọc.

Phép so sánh tôi luôn nghĩ tới là SEO. Chúng ta đã dành nhiều năm để tối ưu cho bot tìm kiếm và hành vi click của con người. AEO cũng cùng ý tưởng đó, nhưng dành cho một đối tượng tiêu thụ khác: các tác nhân AI có khả năng tự động lấy dữ liệu, phân tích và suy luận trên nội dung của bạn.

Những yếu tố quan trọng hóa ra khá cụ thể:

• Khả năng khám phá — tác nhân có thể tìm thấy tài liệu của bạn mà không cần render JavaScript không?
• Khả năng phân tích — nội dung có thể đọc bằng máy mà không cần diễn giải bố cục trực quan không?
• Hiệu quả token — nội dung có nằm trong cửa sổ ngữ cảnh thông thường của tác nhân mà không bị cắt bớt không?
• Tín hiệu năng lực — tài liệu có cho tác nhân biết API của bạn làm được gì, chứ không chỉ cách gọi không?
• Kiểm soát truy cập — robots.txt của bạn có thực sự cho phép lưu lượng AI đi qua không?

Nếu bất kỳ yếu tố nào thất bại, tác nhân sẽ либо bỏ qua hoàn toàn nội dung của bạn, либо tạo ra đầu ra sai lệch một cách tinh vi. Điều khó chịu là bạn có thể sẽ không bao giờ biết, vì không có sự kiện analytics nào được kích hoạt.

Các tác nhân AI thực sự đọc tài liệu của bạn như thế nào

Điều này đáng để giải thích rõ, vì khác biệt hành vi lớn hơn nhiều so với tôi tưởng ban đầu.

Mô hình của con người

Một lập trình viên truy cập trang chủ tài liệu. Họ điều hướng đến phần liên quan. Lướt tiêu đề, đọc vài đoạn, có thể chạy thử đoạn code trong console tương tác, mở thêm hai hoặc ba liên kết nội bộ, và dành 4–8 phút trong một phiên. Analytics ghi nhận toàn bộ.

Mô hình của tác nhân

Một nghiên cứu gần đây về trải nghiệm lập trình viên với AI coding agent đã phân tích lưu lượng HTTP từ chín tác nhân AI lớn — gồm Claude Code, Cursor, Cline, Aider, VS Code và Junie — khi truy xuất tài liệu dành cho lập trình viên. Kết quả khá ấn tượng.

Tác nhân thường nén quá trình điều hướng nhiều trang thành chỉ một hoặc hai request HTTP. Trong khi con người mất vài phút click qua hệ thống tài liệu, tác nhân chỉ gửi một request GET, nhận toàn bộ trang rồi tiếp tục. Khái niệm “hành trình người dùng” gần như sụp đổ thành một sự kiện phía máy chủ.

Hệ quả thực tế: mọi sự kiện analytics phía client — độ sâu cuộn, thời gian trên trang, click nút, hoàn thành tutorial, theo dõi liên kết, tương tác biểu mẫu — đều trở nên vô hình. Tác nhân bỏ qua tất cả.

Dấu vết nhận diện lưu lượng AI

Nghiên cứu cũng xác định những dấu hiệu hành vi đặc trưng giúp bạn nhận diện lưu lượng từ tác nhân AI trong server log:

Ngoài các coding agent, các dịch vụ AI assistant trên web như ChatGPT, Claude, Google Gemini và Perplexity cũng tạo ra dấu vết riêng khi người dùng chia sẻ URL trong giao diện chat — kích hoạt các lần fetch phía server.

Khi biết cần tìm gì, bạn có thể bắt đầu tách riêng lưu lượng AI trong hệ thống analytics. Tôi khá bất ngờ khi thấy lượng truy cập kiểu này vốn đã xuất hiện khá nhiều trong log của mình.

Vấn đề token: tài liệu của bạn có thể vô hình với tác nhân

Đây có lẽ là phần bị đánh giá thấp nhất: kinh tế token.

Tác nhân không có ngữ cảnh vô hạn. Phần lớn giới hạn thực tế trong khoảng 100K–200K token, và quản lý ngữ cảnh luôn là ràng buộc trong mọi nhiệm vụ. Nghiên cứu đưa ra ví dụ cụ thể: Cisco Secure Firewall Management Center REST API Quick Start Guide (phiên bản 10.0) dài tới 193.217 token — gần 718.000 ký tự. Chỉ một tài liệu như vậy đã đủ tiêu tốn hoặc vượt quá toàn bộ cửa sổ ngữ cảnh khả dụng của hầu hết tác nhân.

Khi tác nhân gặp tài liệu quá dài, một số tình huống có thể xảy ra — và không cái nào tốt:

• Tự động cắt ngắn, làm mất thông tin quan trọng
• Bỏ qua hoàn toàn để ưu tiên nội dung ngắn hơn
• Tự chia nhỏ nội dung, làm tăng độ trễ và khả năng lỗi
• Quay về kiến thức tham số hóa — tức tự bịa ra

Tôi cho rằng điều này đồng nghĩa số lượng token giờ là một chỉ số tài liệu hạng nhất. Nếu bạn chưa theo dõi token cho từng trang tài liệu, bạn đang bỏ lỡ tín hiệu mà tác nhân thực sự dùng để quyết định có nên đọc nội dung của bạn hay không.

Mức token thực tế nên nhắm tới

• Quick start / getting started: dưới 15.000 token
• Tài liệu API riêng lẻ: dưới 25.000 token
• API reference đầy đủ: chia theo resource/endpoint, không chia theo toàn sản phẩm
• Hướng dẫn khái niệm: dưới 20.000 token; liên kết sang chi tiết thay vì nhúng toàn bộ

Stack AEO: thực sự cần xây gì?

AEO không phải một thứ đơn lẻ — nó là một tập hợp nhiều lớp tín hiệu và tiêu chuẩn. Tôi hình dung nó như một stack, từ nền tảng tới lớp bề mặt.

Lớp 1: Kiểm soát truy cập (robots.txt)

Đây là điểm dừng đầu tiên của tác nhân. Trước khi lấy nội dung, nhiều tác nhân sẽ kiểm tra robots.txt để xác định mình được phép truy cập gì.

Một tệp robots.txt cấu hình sai, chặn crawler AI phổ biến, sẽ âm thầm ngăn tác nhân truy cập tài liệu của bạn. Không có traffic, không có lỗi, không có dấu hiệu gì. Tôi đã thấy nhiều đội ngũ vướng lỗi này mà hoàn toàn không biết tài liệu của họ đang vô hình với AI.

Các bước thực tế:

• Kiểm tra robots.txt để phát hiện rule vô tình chặn user-agent AI
• Cân nhắc cho phép rõ ràng các crawler AI phổ biến (Anthropic, OpenAI, Google, Perplexity)
• Nếu cần kiểm soát chi tiết hơn, xem agent-permissions.json — một đặc tả mới nổi cho phép khai báo tương tác tự động, giới hạn tốc độ, endpoint ưu tiên và nhiều thứ khác

Lớp 2: Khám phá qua llms.txt

Kể cả khi tác nhân truy cập được nội dung, nó vẫn cần tìm đúng thứ cần thiết. Đây là nơi llms.txt phát huy tác dụng.

Tôi xem llms.txt như sitemap dành cho tác nhân AI. Đây là một tệp Markdown phẳng đặt tại yourdomain.com/llms.txt, cung cấp thư mục tài liệu có cấu trúc cùng mô tả, để tác nhân xác định phần liên quan mà không cần crawl toàn bộ website.

Một llms.txt chuẩn có thể trông như sau:

# Tài liệu YourProduct

## Bắt đầu

- [Hướng dẫn nhanh](/docs/quickstart): Cài đặt và thực hiện API call đầu tiên trong 5 phút
- [Xác thực](/docs/auth): OAuth 2.0 và xác thực bằng API key
- [Khái niệm cốt lõi](/docs/concepts): Mô hình dữ liệu, thực thể và thuật ngữ

## API Reference

- [Tổng quan REST API](/docs/api): Base URL, versioning, pagination, mã lỗi
- [Users API](/docs/api/users): CRUD quản lý người dùng (12K token)
- [Events API](/docs/api/events): Streaming sự kiện và webhook (8K token)

## MCP Integration

- [MCP Server](/docs/mcp): Máy chủ Model Context Protocol để tích hợp trực tiếp với tác nhân

Một llms.txt tốt cần có:

• Mô tả giúp tác nhân hiểu nó sẽ tìm thấy gì, không chỉ tên trang
• Số lượng token cho từng trang khi cần (để tác nhân quyết định cách dùng ngữ cảnh)
• Tổ chức theo tác vụ, không theo cây cấu trúc sản phẩm
• Bản thân tệp nên dưới 5.000 token (index không nên tự làm cạn ngân sách ngữ cảnh)

Lớp 3: Báo hiệu năng lực qua skill.md

llms.txt cho tác nhân biết mọi thứ nằm ở đâu. skill.md cho nó biết sản phẩm của bạn thực sự làm được gì.

Đây là khác biệt quan trọng hơn vẻ ngoài của nó. Thay vì buộc tác nhân suy luận khả năng từ tài liệu văn bản, skill.md khai báo trực tiếp năng lực — ánh xạ từ ý định sang endpoint và tài nguyên.

Một tệp skill.md cho dịch vụ xác thực có thể như sau:

---
name: auth-service
description: Xử lý xác thực người dùng, luồng OAuth 2.0 và quản lý phiên
---

## Những gì tôi có thể làm

- Xác thực người dùng qua OAuth 2.0 (authorization code, client credentials, PKCE)
- Cấp và xác thực JWT token
- Quản lý phiên người dùng và xoay refresh token
- Tích hợp với nhà cung cấp SSO (SAML, OIDC)

## Đầu vào bắt buộc

- Client ID và Client Secret
- Redirect URI đã đăng ký
- Scope yêu cầu (read:user, write:data, admin)

## Ràng buộc

- Rate limit: 1000 token request/phút/ứng dụng
- Access token hết hạn sau 1 giờ
- Refresh token hết hạn sau 30 ngày
- PKCE bắt buộc với public client

## Tài liệu chính

- [OAuth 2.0 Guide](/docs/oauth): Hướng dẫn đầy đủ với ví dụ code
- [Token Reference](/docs/tokens): Cấu trúc token, claims, xác thực
- [Postman Collection](/docs/postman): Mẫu request sẵn dùng

Đây là thứ giúp tác nhân đưa ra quyết định có ý nghĩa — không chỉ lấy tài liệu, mà còn hiểu liệu API của bạn có đáp ứng được ý định người dùng trước khi tiêu tốn ngữ cảnh cho việc đọc toàn bộ.

Lớp 4: Định dạng nội dung để tác nhân phân tích

Dù khả năng khám phá và báo hiệu năng lực hoàn hảo, nội dung vẫn phải dễ đọc với tác nhân. Một số yếu tố tôi thấy rất quan trọng:

Phục vụ Markdown, không chỉ HTML. Nhiều nền tảng tài liệu cho phép truy cập Markdown thô bằng cách thêm .md vào URL hoặc dùng query parameter. Hãy làm cho điều này dễ khám phá. Tác nhân xử lý Markdown với chi phí token thấp hơn HTML rất nhiều (không có tag rác, navigation, footer thừa).

Cấu trúc để quét, không phải để đọc tuần tự. Tác nhân không đọc tuyến tính — nó phân tích cấu trúc:

• Dùng hệ thống heading nhất quán (H1 → H2 → H3, không nhảy cấp)
• Mở đầu mỗi phần bằng kết quả, không phải bối cảnh dài dòng
• Đặt ví dụ code ngay sau nội dung nó minh họa
• Dùng bảng cho tài liệu tham số — nén tốt hơn danh sách mô tả dài

Loại bỏ nhiễu điều hướng. Sidebar, breadcrumb, footer link xuất hiện trong HTML chỉ là nhiễu khi chuyển thành Markdown/văn bản. Đừng để chúng lọt vào đường nội dung mà tác nhân sẽ parse.

Đưa phần hữu ích lên đầu. 500 token đầu tiên của bất kỳ trang nào nên trả lời được: đây là gì, làm được gì, bắt đầu thế nào. Tác nhân không kiên nhẫn với phần mở đầu dài.

Lớp 5: Hiển thị token

Ý tưởng này đơn giản nhưng hiệu quả cao: hiển thị số token trên trang tài liệu. Lý tưởng là cả trong llms.txt lẫn trên chính trang đó (metadata hoặc header).

Điều này giúp tác nhân ra quyết định thông minh:

• “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”
• “Trang này vượt cửa sổ ngữ cảnh — dùng bản tóm tắt trong llms.txt”

Triển khai khá đơn giản: đếm số ký tự phía server, chia khoảng 4 để ước lượng token, rồi đưa ra qua meta tag hoặc HTTP header.

Lớp 6: “Copy for AI”

Đây giống cầu nối UX hơn là tầng hạ tầng, nhưng rất đáng có: nút Copy for AI.

Khi lập trình viên làm việc trong IDE với AI assistant và muốn thêm tài liệu làm ngữ cảnh, họ thường copy trực tiếp từ HTML render — kéo theo navigation, footer và đủ loại rác. Một nút “Copy for AI” để sao chép Markdown sạch vào clipboard tuy nhỏ nhưng cải thiện đáng kể chất lượng ngữ cảnh mà tác nhân nhận được.

Anthropic, Cloudflare và một số bên khác đã triển khai biến thể này. Chi phí thấp, tín hiệu cao.

AGENTS.md: tiêu chuẩn mặc định mới nổi

Một thứ đáng nhấn mạnh riêng: AGENTS.md.

Giống như README.md từng trở thành điểm vào mặc định cho lập trình viên khám phá repository, AGENTS.md đang dần trở thành điểm vào cho tác nhân AI. Khi coding agent mở một dự án, nó tìm AGENTS.md ở thư mục gốc và đưa chỉ dẫn đó vào mọi tác vụ tiếp theo.

Một AGENTS.md tốt nên gồm:

• Cấu trúc dự án và vị trí file quan trọng
• Liên kết trực tiếp đến tài liệu API hoặc dịch vụ liên quan
• Môi trường sandbox và test khả dụng
• Rate limit và các ràng buộc cần biết
• Pattern và convention ưu tiên trong codebase
• Liên kết MCP server nếu có

Cisco DevNet đã áp dụng điều này làm mặc định trong GitHub template cho dự án mã nguồn mở — dự án mới sẽ có sẵn AGENTS.md chứa nội dung theo dự án, link OpenAPI docs, sandbox DevNet và môi trường kiểm thử.

```html id="jq1190"

Theo dõi lưu lượng truy cập từ AI

Một việc bạn có thể làm ngay: bắt đầu theo dõi lưu lượng truy cập AI trong hệ thống analytics.

Các nguồn referral đáng 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

Bạn cũng nên theo dõi các dấu vết HTTP đã đề cập trước đó — axios/1.8.4, curl/8.4.0, got (sindresorhus/got), colly — để phát hiện lưu lượng tác nhân trực tiếp không có referrer.

Việc xây dựng một phân khúc lưu lượng AI riêng sẽ cho bạn chỉ số sớm để biết những thay đổi này có tạo khác biệt hay không.

Tác động rộng hơn với trải nghiệm lập trình viên

Tôi muốn lùi lại một bước vì AEO có thể là tín hiệu của thứ lớn hơn một checklist kỹ thuật.

Trong phần lớn lịch sử web, cổng tài liệu dành cho lập trình viên được thiết kế quanh cách con người tiếp nhận thông tin: tiết lộ dần nội dung, phân cấp trực quan, ví dụ tương tác, tutorial có hướng dẫn. Tất cả đều giả định con người tham gia ở mọi bước.

Trong thế giới nhiều tác nhân AI, nhiều giả định đó bắt đầu sụp đổ:

• Phân cấp trực quan trở nên vô nghĩa — tác nhân đọc văn bản, không đọc bố cục
• Tiết lộ dần nội dung trở thành rào cản — tác nhân muốn có mọi thứ ngay lập tức
• Ví dụ tương tác mất giá trị — trừ khi có phiên bản API hoặc nội dung tĩnh tương đương
• Hành trình người dùng sụp đổ — tutorial nhiều chương biến thành một lần nạp ngữ cảnh

Điều này không có nghĩa thiết kế lấy con người làm trung tâm không còn quan trọng. Con người vẫn đọc tài liệu. Nhưng ngày càng nhiều trường hợp họ đọc bên trong ngữ cảnh của AI assistant, nghĩa là tác nhân thường là bên tiêu thụ trực tiếp, dù người hưởng lợi cuối cùng vẫn là con người.

Tài liệu tốt nhất trong tương lai có lẽ phải phục vụ đồng thời cả hai nhóm: dễ quét và có cấu trúc tốt cho con người, dễ đọc bằng máy và hiệu quả token cho tác nhân.

Checklist audit AEO

Nếu phải đánh giá mức độ sẵn sàng cho tác nhân AI của một website tài liệu hôm nay, đây là những gì tôi sẽ kiểm tra:

Khả năng khám phá

• llms.txt tồn tại ở thư mục gốc với index tài liệu có cấu trúc
• robots.txt không vô tình chặn user-agent AI phổ biến
• agent-permissions.json định nghĩa quyền truy cập cho client tự động
• AGENTS.md tồn tại trong repository và liên kết tới tài liệu liên quan

Cấu trúc nội dung

• Tài liệu có bản Markdown sạch, không chỉ HTML render
• 200 từ đầu mỗi trang nêu rõ kết quả đạt được
• Heading nhất quán và đúng phân cấp
• Ví dụ code nằm ngay sau phần mô tả
• Tài liệu tham số dùng bảng thay vì mô tả dài lồng nhau

Kinh tế token

• Theo dõi token cho từng trang tài liệu
• Không trang nào vượt 30.000 token nếu không có chiến lược chia nhỏ
• Token count hiển thị trong llms.txt với trang quan trọng
• Token count có trong metadata hoặc HTTP header

Báo hiệu năng lực

• skill.md mô tả API/dịch vụ làm được gì, không chỉ cách gọi
• Mỗi skill có: năng lực, đầu vào, ràng buộc, tài liệu liên quan
• Có MCP server nếu phù hợp

Analytics

• Tách riêng referral từ AI trong analytics
• Theo dõi server log để phát hiện dấu vết HTTP của AI agent
• Có baseline so sánh traffic AI và traffic con người

Cầu nối UX

• Có nút “Copy for AI” trên tài liệu
• Có thể truy cập Markdown qua quy ước URL như .md

Công cụ

Để tự động hóa một phần các kiểm tra này, tôi đã phát hành công cụ audit agentic-seo. Nó quét website để phát hiện cơ hội AEO như llms.txt, rule chặn AI trong robots.txt, token count, khả năng truy cập Markdown và nhiều yếu tố khác.

Bắt đầu từ đâu?

Nếu nhìn danh sách trên và chưa biết bắt đầu từ đâu, đây là thứ tự tôi khuyến nghị:

1. Audit robots.txt — 10 phút làm việc, tránh khóa tác nhân trong im lặng
2. Thêm llms.txt — vài giờ, tăng khả năng khám phá ngay lập tức
3. Đo và hiển thị token count — dự án cuối tuần nhưng hiệu quả cao
4. Viết skill.md cho 3 API quan trọng nhất
5. Thêm nút “Copy for AI”
6. Thiết lập giám sát traffic AI

Kết luận

SEO từng dạy chúng ta rằng nội dung tốt thôi là chưa đủ — bạn phải khiến nó dễ được khám phá theo đúng mô hình traffic của thời đại. Tôi nghĩ AEO cũng là bài học tương tự, chỉ khác đối tượng tiêu thụ.

Các AI coding agent đã chiếm tỷ trọng đáng kể và đang tăng trong lưu lượng tài liệu kỹ thuật. Chúng hành xử khác căn bản so với người đọc. Và phần lớn cổng tài liệu cho lập trình viên vẫn chưa được xây cho chúng.

Những đội đi sớm sẽ có lợi thế thực sự: API của họ sẽ là thứ tác nhân đề xuất, tích hợp thành công và quay lại dùng tiếp. Những đội chậm chân sẽ chứng kiến khoảng cách ngày càng lớn giữa chất lượng tài liệu và tỷ lệ hoàn thành tác vụ của tác nhân — một dạng lỗi âm thầm cực khó debug.

Tin tốt là xây tài liệu tốt cho tác nhân thường cũng khiến tài liệu tốt hơn cho con người. Hai hướng này giao nhau nhiều hơn là tách biệt.

Hãy bắt đầu với llms.txt. Triển khai skill.md. Audit robots.txt. Đo token. Phần lớn việc này chỉ tốn một cuối tuần, nhưng giá trị mang lại đã rất thực tế.