🎯 Trình duyệt đám mây tùy chỉnh, chống phát hiện được hỗ trợ bởi Chromium tự phát triển, thiết kế dành cho trình thu thập dữ liệu webtác nhân AI. 👉Dùng thử ngay
Quay lại blog

Mạng Đang Có Một Lớp Truy Cập: llms.txt, Đại Diện Ký Kết, và Trả Tiền Theo Lần Thu Lượm

Michael Lee
Michael Lee

Expert Network Defense Engineer

22-Jul-2026

Web đã trải qua ba mươi năm hoạt động dựa trên một tệp hệ thống danh dự duy nhất. robots.txt yêu cầu một cách lịch sự, không xác định ai và không thực thi gì cả — và trong phần lớn thời gian đó, điều đó là đủ, vì cái mà đọc các trang của bạn là một công cụ tìm kiếm đã gửi lưu lượng truy cập trở lại.

Sự trao đổi đó đã bị đổ vỡ, và bốn nỗ lực riêng biệt hiện đang cố gắng thay thế nó. Chúng không phải là các phiên bản cạnh tranh của cùng một ý tưởng. Chúng trả lời ba câu hỏi khác nhau — đọc cái gì, ai đang hỏi, và chi phí là gì — và chỉ một trong số đó là một tiêu chuẩn hoàn chỉnh.

Lớp Mà Thực Sự Thiếu Là Danh Tính

Bắt đầu với những gì robots.txt có thể và không thể làm. Tiêu chuẩn Giao thức Loại Trừ Robot cung cấp cho các nhà xuất bản một cách để thể hiện sở thích theo chuỗi user-agent. Điểm yếu nằm ở cụm từ cuối cùng đó: một chuỗi user-agent là một tuyên bố, không phải một chứng chỉ. Bất kỳ ai cũng có thể gửi bất kỳ chuỗi nào, và danh sách trắng IP nhanh chóng trở nên lỗi thời khi cơ sở hạ tầng thay đổi.

Vì vậy, một nhà xuất bản muốn đối xử khác nhau với hai trình thu thập không có cách đáng tin cậy để phân biệt chúng. Mỗi đề xuất dưới đây đều nằm trong khoảng trống đó. Các cơ chế thực tế của tệp — cú pháp, chỉ thị, và cách các bộ thu thập nên đọc nó — được đề cập trong hướng dẫn robots.txt cho việc thu thập dữ liệu web.

llms.txt Trả Lời "Tôi Nên Đọc Gì?"

Đề xuất llms.txt đưa ra một tệp Markdown tại /llms.txt chứa bản tóm tắt được chọn lọc và liên kết đến các phiên bản văn bản sạch của các trang quan trọng trên một trang web. Đề xuất llms.txt được công bố bởi Jeremy Howard vào tháng 9 năm 2024, và vấn đề mà nó đề cập là các cửa sổ ngữ cảnh: các mô hình không thể hấp thụ toàn bộ một trang web, và việc chuyển đổi HTML thành văn bản có thể sử dụng làm mất dữ liệu.

Điều đáng lưu ý là tình trạng của nó, vì nó thường được mô tả như một tiêu chuẩn. Trang web tự gọi nó là "một đề xuất để tiêu chuẩn hóa." Không có RFC, không có nhóm làm việc, và không có yêu cầu nào mà bất kỳ ai phải tôn trọng nó.

Điều mà nó thực sự tốt là việc tuyển chọn. Một nhà xuất bản viết một cái nói đây là phiên bản tốt của nội dung của tôi, điều này giúp một người đọc hành xử tốt và không tốn kém gì cho một người hành xử không tốt. Nó thể hiện sở thích, không phải sự cho phép — giới hạn tương tự mà robots.txt có.

Web Bot Auth Trả Lời "Ai Đang Hỏi?"

Đây là phần thực sự giải quyết khoảng trống danh tính. Phương pháp: mọi yêu cầu từ một khách hàng tự động đều mang một chữ ký mật mã được tạo bằng một khóa riêng thuộc về nhà điều hành của nó, vì vậy máy chủ nguồn có thể xác minh ai đang gọi thay vì tin tưởng vào một tiêu đề.

Tài liệu hiện tại là Đề xuất chữ ký tin nhắn HTTP Web Bot Auth, một bản Internet-Draft cá nhân đang hoạt động xây dựng trên Chữ ký Tin nhắn HTTP. Khung của nó tự nhận xét rằng danh sách trắng IP và chuỗi User-Agent không phải là nhận dạng đầy đủ.

Hai điểm cần lưu ý. Đây là một bản đăng ký cá nhân thay vì sản phẩm của một nhóm làm việc, và một bản kiến trúc trước đó từ cùng các tác giả đã hết hạn và được thay thế — điều bình thường trong công việc tiêu chuẩn, nhưng là dấu hiệu cho thấy đây vẫn còn sớm. Và việc ký tên chứng minh bạn là ai, không phải rằng bạn được phép. Nó cung cấp cho các nhà xuất bản điều gì đó để đưa ra quyết định; nó không đưa ra quyết định.

Pay-Per-Crawl và RSL Trả Lời "Chi Phí Là Bao Nhiêu?"

Hai nỗ lực giải quyết vấn đề bồi thường, từ những hướng khác nhau.

Chương trình pay-per-crawl của Cloudflare sử dụng HTTP 402, mã trạng thái được dành riêng cho thanh toán trong tiêu chuẩn ngữ nghĩa HTTP và đã không được sử dụng trong nhiều thập kỷ. Các nhà xuất bản đặt giá cho mỗi yêu cầu và đánh dấu mỗi crawler cho phép, tính phí, hoặc chặn; các crawler báo hiệu ý định qua các tiêu đề giá và được xác định qua các chữ ký Web Bot Auth. Nó được công bố vào tháng 7 năm 2025 và vẫn ở giai đoạn beta riêng tư — một thử nghiệm trực tiếp, không phải cơ sở hạ tầng bạn có thể xây dựng dựa vào.

RSL lựa chọn hướng cấp phép. Tiêu chuẩn Cấp phép Thực sự Đơn giản định nghĩa các điều khoản cấp phép có thể đọc được bằng máy — ghi công, trả tiền theo lượt thu thập, trả tiền theo sự suy diễn — dưới dạng XML có thể tham chiếu từ robots.txt, HTML, tiêu đề HTTP, nguồn cấp dữ liệu RSS, hoặc tệp phương tiện. RSL 1.0 đã được phát hành vào năm 2025 với sự hỗ trợ từ Akamai, Cloudflare, Creative Commons, Fastly, Reddit, O'Reilly Media, Vox Media, Yahoo và Ziff Davis.

Trong số bốn thứ này, RSL là thứ tiến bộ nhất với tư cách là một tiêu chuẩn đã được công bố với sự áp dụng trong ngành đã được đặt tên. Điều đó không làm cho nó ổn định — một ngữ pháp cấp phép vẫn cần ai đó sẵn sàng thực thi nó, và việc thực thi sẽ đưa bạn quay lại vấn đề danh tính.

Lớp Mà Chúng Đề Cập

Đọc chung, đây là các lớp chứ không phải những lựa chọn thay thế:

  • Sở thíchrobots.txtllms.txt cho biết những gì một nhà xuất bản mong muốn.
  • Danh tính — Web Bot Auth cho biết ai đang yêu cầu, một cách mã hóa.
  • Điều khoản — RSL cho biết nội dung có thể được sử dụng cho mục đích gì và với mức giá nào.
  • Giải quyết — các dòng 402 kiểu trả phí theo phiên quét cho biết tiền thực sự di chuyển như thế nào.

Thứ tự quan trọng. Các điều khoản mà không có danh tính thì không thể thi hành, và việc giải quyết mà không có điều khoản thì giống như một trạm thu phí không công bố mức phí. Danh tính là lớp chịu tải, và nó là lớp kém hoàn thiện nhất.

Những điểm có thể thiếu sót

Phản đối rõ ràng nhất: không có gì ở đây ràng buộc ai đó muốn không tham gia. Một khách hàng phớt lờ llms.txt, không gửi chữ ký và không bao giờ đọc tệp RSL thì vẫn ở trong vị thế như bao khách hàng trước đây. Các cơ chế này chỉ hoạt động trên các nhà điều hành muốn được xác định — điều này áp dụng cho hầu hết các nhà điều hành lớn có trách nhiệm, và không áp dụng cho phần còn lại.

Vấn đề thứ hai là sự tập trung. Danh tính dựa trên chữ ký thiên về các nhà điều hành đủ lớn để vận hành cơ sở hạ tầng chính và nhận diện được khóa của họ. Một nhà nghiên cứu, một startup, hoặc một kho lưu trữ phục vụ lợi ích công cộng có thể thấy lớp truy cập mới khó để hòa nhập hơn hệ thống danh dự mà nó thay thế. Đó là một chi phí thực sự, và đáng để được nhắc đến thay vì xem như lỗi làm tròn trên một web sạch hơn.

Thứ ba, không điều gì ở đây giải quyết được sự bất đối xứng đã gây ra sự sụp đổ. Việc thu thập thông tin thời kỳ tìm kiếm đã đổi quyền truy cập lấy lưu lượng truy cập. Một mô hình đọc trang của bạn và tự trả lời câu hỏi không trả lại gì cả, và một đường ray thanh toán không khôi phục lại mối quan hệ — nó định giá sự vắng mặt đó.

Cần làm gì thực sự

Nếu bạn xuất bản: hãy viết một llms.txt — nó rẻ và thể hiện sự tuyển chọn mà bạn kiểm soát. Theo dõi RSL, vì giấy phép có thể máy đọc được là di vật mà một tranh chấp trong tương lai sẽ dựa vào. Đối xử với việc trả phí theo phiên quét như một thí nghiệm để theo dõi thay vì một kế hoạch.

Nếu bạn thu thập dữ liệu: bước đi bền vững là trở thành loại khách hàng mà các hệ thống này được thiết kế để xử lý. Hãy tự định danh một cách trung thực, giữ lại dữ liệu công khai, tôn trọng các chỉ thị hiện có, giữ khối lượng tương xứng, và ghi lại những gì bạn đã thu thập và từ đâu. Mọi đề xuất ở trên đều thưởng cho các nhà điều hành có thể trả lời "bạn là ai và bạn đã lấy gì" — và điều đó xứng đáng để làm bây giờ, khi câu trả lời vẫn là tự nguyện.

Hệ thống danh dự đang kết thúc. Những gì thay thế nó là chưa hoàn thiện, và tư thế hữu ích không phải là chờ đợi nó hay phớt lờ nó, mà là hành xử ngay bây giờ theo cách mà phiên bản hoàn chỉnh sẽ yêu cầu.

Bắt đầu với kế hoạch miễn phí Scrapeless để xem cách Scrapeless AI Agent xử lý dữ liệu web công khai, và xem lại bảng giá Scrapeless khi bạn lên kế hoạch cho một chương trình thu thập dữ liệu.

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

Hỏi: llms.txt có phải là một tiêu chuẩn chính thức không?

Không. Nó được trình bày rõ ràng như một đề xuất để chuẩn hóa, được xuất bản vào tháng 9 năm 2024. Không có RFC và không có nhóm làm việc đứng sau nó, cũng không có yêu cầu nào đối với bất kỳ khách hàng nào phải tôn trọng nó. Các trang web áp dụng nó vì sự tuyển chọn giúp những độc giả cư xử tốt, chứ không phải vì bất kỳ điều gì bắt buộc.

Hỏi: llms.txt có thay thế robots.txt không?

Không — chúng trả lời các câu hỏi khác nhau. robots.txt, được chuẩn hóa trong RFC 9309, thể hiện các đường dẫn mà khách hàng không nên thu thập. llms.txt chỉ vào nội dung mà một nhà xuất bản cho là hữu ích nhất và cung cấp các phiên bản văn bản sạch hơn của nó. Một cái thì hạn chế, cái còn lại thì tuyển chọn, và không cái nào xác thực khách hàng.

Hỏi: Web Bot Auth thực sự giải quyết vấn đề gì?

Nó làm cho danh tính của một công cụ thu thập dữ liệu trở nên có thể xác minh. Hiện tại, một khách hàng tự xác định mình bằng chuỗi User-Agent mà bất kỳ ai cũng có thể sao chép, vì vậy các nhà xuất bản không thể phân biệt chính xác giữa các công cụ thu thập dữ liệu. Web Bot Auth yêu cầu mỗi yêu cầu được ký bằng khóa riêng của nhà điều hành sử dụng Chữ ký Tin nhắn HTTP, để nguồn có thể xác minh ai đang gọi. Nó là một Dự thảo Internet đang hoạt động, chứ không phải một tiêu chuẩn hoàn chỉnh.

Hỏi: Các nhà xuất bản có thể tính phí cho các công cụ thu thập dữ liệu AI hôm nay không?

Chỉ thử nghiệm. Dịch vụ trả phí theo phiên quét của Cloudflare sử dụng HTTP 402 với giá theo yêu cầu và được công bố vào tháng 7 năm 2025, nhưng vẫn ở phiên bản beta riêng. RSL, được xuất bản vào năm 2025 với sự ủng hộ từ một nhóm các công ty hạ tầng và nhà xuất bản, định nghĩa các điều khoản cấp giấy phép có thể máy đọc được bao gồm trả phí theo phiên quét và trả phí theo suy diễn — nhưng một giấy phép vẫn phụ thuộc vào ai đó xác định và thực thi chống lại khách hàng.

Hỏi: Nhóm thu thập dữ liệu nên làm gì trong khi điều này đang được giải quyết?
Hãy cư xử như thể danh tính và điều khoản đã được thực thi. Chỉ thu thập dữ liệu công khai, tôn trọng các chỉ thị hiện tại, giữ mức yêu cầu tương xứng với những gì một trang web có thể phục vụ và ghi lại những gì đã được thu thập và từ đâu. Mỗi đề xuất trên bàn đều thưởng cho những nhà điều hành có thể trả lời câu hỏi đó, vì vậy công việc không bị lãng phí bất kể ai thắng.

Tại Scrapless, chúng tôi chỉ truy cập dữ liệu có sẵn công khai trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách bảo mật trang web hiện hành. Nội dung trong blog này chỉ nhằm mục đích trình diễn và không liên quan đến bất kỳ hoạt động bất hợp pháp hoặc vi phạm nào. Chúng tôi không đảm bảo và từ chối mọi trách nhiệm đối với việc sử dụng thông tin từ blog này hoặc các liên kết của bên thứ ba. Trước khi tham gia vào bất kỳ hoạt động cạo nào, hãy tham khảo ý kiến ​​cố vấn pháp lý của bạn và xem xét các điều khoản dịch vụ của trang web mục tiêu hoặc có được các quyền cần thiết.

Bài viết phổ biến nhất

Danh mục