Vượt Ra Ngoài Lập Trình Vibe: Hạ Tầng Dữ Liệu Web Mà Các Đại Lý AI Cần

Tóm tắt:

• Các tác nhân AI thất bại khi dữ liệu công cụ không ổn định, không chỉ khi khả năng suy luận của mô hình yếu. Các hệ thống sản xuất cần một lớp dữ liệu web với các hợp đồng rõ ràng cho việc thu thập, danh tính, xác thực và nguồn gốc.
• Tách biệt vòng điều khiển mô hình ra khỏi mặt phẳng dữ liệu. Tác nhân nên chọn một khả năng giới hạn; hạ tầng nên xử lý chính sách nguồn, thực thi trình duyệt, đầu ra cấu trúc, lưu trữ và theo dõi.
• Mỗi kết quả công cụ cần một hợp đồng chấp nhận. Xác thực nguồn, sơ đồ, độ mới, quyền hạn và nội dung dự kiến trước khi kết quả vào ngữ cảnh tác nhân.
• Các trạng thái thất bại phải rõ ràng và được phân loại. Trang trắng, thách thức truy cập, hồ sơ lỗi thời, vi phạm sơ đồ và ngân sách cạn kiệt nên trở thành các kết quả riêng biệt thay vì văn bản mơ hồ.
• Kiểm soát chi phí bắt đầu trước cuộc gọi mô hình. Định tuyến mỗi nguồn đến con đường thu thập ít tốn kém nhất có thể đáp ứng hợp đồng, sau đó chỉ trả về bằng chứng mà nhiệm vụ cần.

Một tác nhân AI có thể lập kế hoạch cho một nhiệm vụ hữu ích và vẫn thất bại ngay tại trang web đầu tiên. Trang đó có thể được hiển thị phía khách hàng, thay đổi theo khu vực, trả về một shell đồng ý, yêu cầu một phiên, hoặc tiết lộ một bố cục đã thay đổi sau khi văn bản được viết.

Đó là những thất bại ở mặt phẳng dữ liệu. Một mô hình mạnh hơn không thể sửa chữa một tài liệu trống, một nguồn chưa được xác minh, hoặc một phản hồi công cụ không có sơ đồ ổn định.

Vì vậy, các tác nhân sản xuất cần một lớp hạ tầng dữ liệu web giữa việc suy luận và web mở. Lớp này biến một ý định như "so sánh giá công khai hiện tại cho những sản phẩm này" thành việc thu thập giới hạn, hồ sơ đã xác thực, các cuộc gọi công cụ có thể quan sát, và một gói chứng cứ mà mô hình có thể sử dụng.

Tại sao bản demo tác nhân gặp vấn đề trong sản xuất

Một bản demo thường tối ưu hóa cho con đường thuận lợi: một lệnh gọi, một trang, một kết quả. Sản xuất giới thiệu biến đổi giữa các người dùng, nguồn, thời gian và chính sách.

Các điểm gãy là có thể đoán trước:

• Trạng thái nguồn không xác định: URL chuyển hướng, thay đổi bố cục hoặc trả về một shell không có nội dung.
• Sự không khớp trong rendering: phản hồi ban đầu không chứa các trường mà tác nhân mong đợi.
• Sự trôi dạt danh tính: một số URL đại diện cho một tài liệu, hoặc một URL thay đổi ý nghĩa theo khu vực hoặc phiên.
• Ngữ cảnh không giới hạn: công cụ trả về toàn bộ trang khi nhiệm vụ chỉ cần một bảng.
• Nguồn gốc yếu: câu trả lời không thể chỉ ra nguồn, phiên bản hoặc sự kiện thu thập nào đã hỗ trợ nó.
• Mơ hồ về quyền truy cập: tác nhân có thể tiếp cận một tài nguyên mà người dùng hoặc thuê bao không được phép sử dụng.
• Thất bại im lặng: phản hồi bị lỗi trông giống như văn bản thông thường và đến với mô hình.

Các thay đổi trong lệnh gọi có thể che giấu những vấn đề này trong suốt buổi trình diễn. Chúng không tạo ra một hợp đồng vận hành.

Lớp Mô Hình và Mặt Phẳng Dữ Liệu Có Các Vai Trò Khác Nhau

Lớp mô hình giải thích mục tiêu, chọn một khả năng và quyết định cách sử dụng chứng cứ đã được chấp nhận. Mặt phẳng dữ liệu kiểm soát cách thông tin bên ngoài được thu thập và chấp nhận.

Vấn đề	Vòng kiểm soát mô hình	Mặt phẳng dữ liệu web
Mục tiêu	Giải thích ý định của người dùng	Thực thi chính sách nguồn đã phê duyệt
Lựa chọn công cụ	Chọn một khả năng đã đặt tên	Định tuyến để lấy, trình duyệt, tìm kiếm hoặc hồ sơ lưu trữ
Đầu vào	Tạo ra các lập luận giới hạn	Xác thực URL, phạm vi, khu vực và ngân sách
Thực thi	Chờ một kết quả có kiểu	Thu thập, hiển thị, phân tích và xác thực
Chứng cứ	Lý luận trên các trường đã chấp nhận	Gắn nguồn, ngữ cảnh thu thập và độ mới
Thất bại	Chọn một con đường khác đã được phê duyệt hoặc dừng lại	Trả về một trạng thái có thể đọc bằng máy cụ thể
Đầu ra	Biên soạn phản hồi của người dùng	Bảo tồn chứng cứ được sử dụng bởi mô hình

Thông số kỹ thuật Giao thức Ngữ cảnh Mô hình định nghĩa một giao diện máy khách-máy chủ để phơi bày các công cụ và ngữ cảnh khác cho các ứng dụng mô hình. Một giao thức làm cho việc phát hiện khả năng và gọi dễ dàng hơn. Độ tin cậy trong sản xuất vẫn phụ thuộc vào các hợp đồng phía sau mỗi khả năng.

Kiến trúc Tham khảo cho Dữ liệu Web Tác nhân

Một kiến trúc thực tiễn tách biệt chín trách nhiệm:

Yêu cầu của người dùng → gateway chính sách → bộ định tuyến công cụ → lớp thu thập → xác thực nội dung → chuẩn hóa → lưu trữ chứng cứ → ngữ cảnh tác nhân → kiểm toán phản hồi

Gateway chính sách

Gateway chính sách giải quyết các quy tắc về người dùng, thuê bao, nguồn, mục đích, địa lý và loại dữ liệu trước bất kỳ cuộc gọi bên ngoài nào. Nó từ chối các đích riêng tư hoặc bị hạn chế ngoài chương trình đã phê duyệt.

Bộ định tuyến công cụ

Bộ định tuyến chọn con đường ít phức tạp nhất có thể đáp ứng nhiệm vụ. Một trang HTML công khai ổn định có thể cần thu thập trực tiếp. Một trang được render bởi khách hàng có thể cần một trình duyệt. Một câu hỏi phổ biến có thể đã có một hồ sơ đã được chấp nhận mới.

Lớp thu thập

Lớp thu thập sở hữu việc định tuyến mạng, thực thi trình duyệt, trạng thái phiên và các giới hạn cụ thể theo nguồn. Tác nhân nhận được một khả năng đã đặt tên thay vì thông tin xác thực hoặc kiểm soát hạ tầng cấp thấp.

Xác thực nội dung

Xác thực quyết định xem kết quả có phải là nội dung công khai mong đợi hay không. Chỉ trạng thái thì không đủ. Bộ xác thực kiểm tra các trường bắt buộc, danh tính trang, ngôn ngữ, loại nội dung và các trạng thái lỗi hoặc thách thức đã biết.

Chuẩn hóa

Chuẩn hóa gán danh tính nguồn chuẩn, loại bỏ các nội dung không cần thiết, trích xuất các trường có cấu trúc và đính kèm ngữ cảnh thu thập. Đầu ra sử dụng một lược đồ phiên bản duy nhất bất kể việc thu thập có sử dụng trình duyệt hay yêu cầu trực tiếp.

Kho chứng cứ

Kho chứng cứ giữ các hồ sơ đã được chấp nhận, URL nguồn, mã băm nội dung, lớp chính sách và trạng thái mới. Nó có thể phục vụ các câu hỏi lặp lại mà không cần thu thập lại nội dung không thay đổi.

Bộ xây dựng ngữ cảnh đại lý

Bộ xây dựng ngữ cảnh chỉ chọn các đoạn hoặc trường cần thiết cho quyết định hiện tại. Nó không đổ tất cả tài liệu đã chấp nhận vào phần nhắc nhở.

Kiểm toán phản hồi

Lớp kiểm toán ghi lại công cụ nào đã hỗ trợ câu trả lời, trường nào đã đến mô hình, và người dùng có chấp thuận hành động nào có hậu quả hay không.

Định nghĩa một Đăng ký Nguồn Trước Khi Xây Dựng Công Cụ

Một đăng ký nguồn biến “web” thành một kho hàng được kiểm soát. Mỗi mục nên xác định:

• chủ sở hữu nguồn và mục đích kinh doanh;
• máy chủ và phạm vi đường dẫn được phép;
• phân lớp truy cập công khai hoặc được ủy quyền;
• yêu cầu về địa phương và địa lý;
• loại tài liệu và dấu hiệu nội dung dự kiến;
• lộ trình thu thập;
• mục tiêu độ mới;
• chính sách bảo quản và xóa;
• chủ sở hữu cấp độ.

Đăng ký ngăn chặn việc một nhắc nhở ngôn ngữ tự nhiên mở rộng phạm vi của chương trình một cách lén lút. Nếu đại lý phát hiện một máy chủ hữu ích nhưng chưa được đăng ký, nó có thể đưa ra ứng viên mà không cần thu thập nó.

Biến Mỗi Công Cụ Thành Hợp Đồng Dữ Liệu

Mô tả công cụ cho mô hình biết khi nào gọi một khả năng. Một hợp đồng dữ liệu cho hệ thống biết kết quả chấp nhận được sẽ như thế nào.

Mỗi công cụ dữ liệu web nên chỉ định:

Phần tử hợp đồng	Quyết định ví dụ
Phạm vi đầu vào	URL HTTPS công khai trên máy chủ được phê duyệt
Tham số bắt buộc	URL, địa phương, các trường yêu cầu
Lược đồ đầu ra	Nguồn, các trường, ngữ cảnh thu thập, trạng thái
Các trường bắt buộc	Nguồn chuẩn và ít nhất một trường dữ liệu đã được chấp nhận
Các trường có thể null	Giá hoặc tác giả thiếu là rõ ràng, không bị bỏ qua một cách lén lút
Quy tắc mới nhất	Hồ sơ đã lưu là chấp nhận được cho đến khi mục tiêu nguồn hết hạn
Lớp quyền hạn	Nguồn công khai-ủy quyền hoặc sở hữu
Trạng thái thất bại	Phạm vi bị từ chối, nội dung không có, lược đồ không hợp lệ, ngân sách cạn kiệt

Hướng dẫn JSON Schema object giải thích cách mà các thuộc tính, các trường bắt buộc và các ràng buộc kiểu xác định các đối tượng hợp lệ. Động thái thiết kế hữu ích là không thêm một tệp lược đồ sau khi phát triển. Đó là quyết định những trường nào mà đại lý có thể phụ thuộc vào trước khi công cụ tồn tại.

Đừng biến mọi trường thành dữ liệu bắt buộc. Một danh sách công khai có thể hợp pháp bỏ qua một mức giảm giá hoặc số lượng đánh giá. Đánh dấu những trường này là có thể null trong khi giữ danh tính nguồn và trạng thái xác thực là bắt buộc.

Định Tuyến Nguồn Theo Hành Vi

Một phương pháp thu thập hiếm khi đúng cho mọi nguồn.

Hành vi nguồn	Lộ trình bắt đầu ưa thích	Tín hiệu xác thực
HTML công khai ổn định	Thu thập trực tiếp	Trường mong đợi trong phản hồi
Trang rend đ JavaScript	Trình duyệt đám mây	Trường mong đợi trong tài liệu đã được rend
Kết quả tìm kiếm công khai	Công cụ cụ thể cho tìm kiếm	Truy vấn, địa phương và cấu trúc kết quả
Tra cứu tương tác	Phiên trình duyệt có trạng thái	Trạng thái cuối cùng và các trường đã trích xuất
Trang ổn định thường xuyên được yêu cầu	Bộ nhớ đệm đã chấp nhận	Độ mới của nguồn vẫn nằm trong chính sách
Điểm đến không xác định hoặc bị hạn chế	Không thu thập	Quyết định chính sách cần thiết

Lộ trình này giữ cho một trình duyệt có sẵn cho các trang cần nó mà không phải trả chi phí trình duyệt cho mọi tài liệu. Nó cũng cung cấp cho bộ xác thực một tín hiệu chấp nhận theo trang cụ thể.

Scrapeless AI Agent cung cấp một lộ trình phía đại lý đến các khả năng web trực tiếp. Scrapeless Universal Scraping API hỗ trợ thu thập trang công khai ủy quyền khi ứng dụng cần một quy trình HTTP được quản lý. Bộ định tuyến nên chỉ lộ ra khả năng phù hợp với nguồn và nhiệm vụ.

Nhận khóa API của bạn trong gói miễn phí: app.scrapeless.com

Trả Về Các Gói Chứng Cứ, Không Phải Lưu Trữ Trang

Một đại lý hiếm khi cần mọi nhãn điều hướng, chân trang, tiện ích gợi ý và thẻ sản phẩm lặp lại trên một trang. Trả về tài liệu đó tiêu tốn ngữ cảnh và làm cho chứng cứ có liên quan trở nên khó xác định hơn.

Một gói chứng cứ có thể chứa:

• URL nguồn chuẩn;
• bối cảnh bộ sưu tập và trạng thái tươi mới;
• các trường có cấu trúc được yêu cầu;
• các đoạn hỗ trợ đã chọn;
• phiên bản lược đồ;
• lớp quyền hạn;
• trạng thái xác thực;
• băm nội dung hoặc phiên bản bản ghi.

Gói dữ liệu này nhỏ hơn và dễ kiểm toán hơn so với một trang hoàn chỉnh. Mô hình có thể trích dẫn nguồn và phân biệt chứng cứ hiện tại với một bản ghi cũ được lưu trữ.

Đối với nghiên cứu đa nguồn, tập hợp một số gói dữ liệu có giới hạn và giữ cho nguồn gốc của chúng tách biệt. Đừng kết hợp văn bản trước và cố gắng tái tạo quyền sở hữu sau.

Thiết kế Trạng thái Thất bại Có kiểu

“Không có kết quả” không phải là một thất bại duy nhất. Đại lý cần biết liệu nguồn có nằm ngoài chính sách, trang thiếu nội dung dự kiến, bản ghi được lưu trữ quá cũ, hay đầu ra vi phạm lược đồ của nó.

Các trạng thái hữu ích bao gồm:

• scope_denied: nguồn không được phê duyệt;
• content_absent: trường công khai dự kiến không có mặt;
• unexpected_page: phản hồi là sự đồng ý, thách thức, lỗi, hoặc trang không liên quan;
• schema_invalid: đối tượng được trích xuất không thỏa mãn hợp đồng;
• stale_record: chứng cứ được lưu trữ vượt quá mục tiêu nguồn;
• budget_exhausted: nhiệm vụ đã đạt đến giới hạn thu thập hoặc bối cảnh của nó;
• human_review_required: bước tiếp theo mang theo rủi ro pháp lý, quyền riêng tư, hoặc thương mại.

Mỗi trạng thái nên xác định hành động tiếp theo được phép. Một số trạng thái cho phép một con đường thu thập được phê duyệt khác. Những cái khác yêu cầu đại lý ngừng lại và giải thích những gì còn thiếu. Không ai trong số đó nên được chuyển đổi thành dữ liệu hư cấu.

Giữ Danh tính và Phiên khỏi Lời nhắc

Thông tin xác thực, cookie, cấu hình proxy và định danh phiên trình duyệt thuộc về hạ tầng. Mô hình nên yêu cầu khả năng theo ngữ cảnh người dùng và đối tượng hiện tại, không nhận bí mật tái sử dụng.

Sử dụng các tay cầm phiên máy chủ ngắn hạn, các điểm đến được cho phép, thông tin xác thực có phạm vi, và kiểm tra vai trò. Tách biệt các công cụ nghiên cứu chỉ đọc khỏi các công cụ có thể gửi biểu mẫu, thay đổi bản ghi, hoặc kích hoạt hành động bên ngoài.

Thiết kế tối thiểu quyền này cũng giới hạn những gì một đại lý có thể làm khi một cuộc gọi công cụ bị nhầm lẫn hoặc bị thao túng. Hướng dẫn của OWASP về quyền lực tối đa nhấn mạnh rủi ro do việc cấp cho hệ thống nhiều chức năng, quyền hạn, hoặc tính tự chủ hơn mức cần thiết cho một nhiệm vụ.

NIST định hình quản lý rủi ro AI là công việc trong khung quản lý, lập bản đồ, đo lường và quản lý. Khung Quản lý Rủi ro AI của NIST áp dụng những thực tiễn đó trên toàn bộ vòng đời AI. Đối với các hệ thống đại lý, lớp công cụ và quyền truy cập dữ liệu của nó thuộc về vòng đời đó, không phải bên ngoài nó.

Làm cho Kế hoạch Dữ liệu Quan sát được

Khả năng quan sát của đại lý cần nhiều hơn đầu vào và đầu ra của mô hình. Một yêu cầu có thể thất bại trước khi mô hình nhìn thấy chứng cứ, trong quá trình chọn công cụ, trong thực thi trình duyệt, tại xác thực lược đồ, hoặc khi bộ xây dựng ngữ cảnh bỏ qua một trường yêu cầu.

Mô hình tín hiệu OpenTelemetry phân biệt giữa các truy dấu, chỉ số, nhật ký và hành lý. Áp dụng mô hình đó qua con đường công cụ với một định danh tương quan.

Ghi lại những sự kiện này:

• quyết định chính sách và phù hợp đăng ký nguồn;
• lộ trình thu mua đã chọn;
• hình dạng đầu vào công cụ với bí mật đã được xóa;
• thời gian thu mua và danh tính trang cuối cùng;
• trạng thái xác thực và lý do từ chối;
• phiên bản lược đồ đã được chuẩn hóa;
• các trường chứng cứ được xem xét cho ngữ cảnh;
• quyết định mô hình và các trích dẫn có thể thấy từ người dùng;
• sự phê duyệt của con người cho các hành động có hậu quả.

Các biện pháp vận hành hữu ích bao gồm chi phí tài liệu được chấp nhận, thời gian thu mua, tỷ lệ bản ghi cũ, tỷ lệ từ chối lược đồ, tỷ lệ trang không mong muốn, kích thước bối cảnh, độ bao phủ chứng cứ, và tần suất xem xét của con người.

Điều cốt lõi là chẩn đoán. Nếu câu trả lời nghiên cứu thiếu giá hiện tại, dấu vết nên cho thấy liệu nguồn đã bị từ chối, trường bị thiếu, trang là không mong đợi, hoặc bộ xây dựng ngữ cảnh đã loại trừ nó.

Kiểm soát Chi phí ở Mỗi Ranh giới

Mô hình ký tự chỉ là một trung tâm chi phí. Thời gian chạy trình duyệt, cuộc gọi tìm kiếm, truyền tải mạng, trích xuất, lưu trữ, nhúng, và thu mua lặp lại có thể chi phối một nhiệm vụ dài.

Sử dụng bốn biện pháp kiểm soát:

Lộ trình tới con đường hợp lệ ít phức tạp nhất

Thu mua trực tiếp là đủ cho nội dung được trình bày ổn định từ phía máy chủ. Sử dụng trình duyệt khi JavaScript hoặc tương tác là cần thiết. Cung cấp một bản ghi lưu trữ đã được chấp nhận khi nó vẫn tươi mới cho nhiệm vụ.

Yêu cầu các trường, không phải các trang

Đầu vào công cụ nên nêu tên các trường hoặc câu hỏi. Đầu ra nên trả lại chứng cứ được chấp nhận cho yêu cầu đó thay vì tài liệu hoàn chỉnh.

Xóa trùng lặp theo nguồn và nội dung

URL chuẩn ngăn chặn công việc lặp lại qua các bí danh. Băm nội dung cho thấy liệu một URL ổn định đã thay đổi chưa. Các quyết định bộ nhớ cache nên bảo tồn chính sách nguồn và tính tươi mới.

Đặt ngân sách trước khi thực hiện

Giới hạn mỗi nhiệm vụ cho các nguồn, thời gian duyệt web, byte đã thu thập, tài liệu đã lưu và kích thước ngữ cảnh. Khi một giới hạn được đạt, trả về trạng thái kiểu và cho phép người dùng thu hẹp yêu cầu.

Danh sách kiểm tra sẵn sàng sản xuất

Một lớp dữ liệu web của đại lý sẵn sàng cho một buổi ra mắt có kiểm soát khi đội ngũ có thể trả lời những câu hỏi này:

Nguồn và chính sách

• Có phải mọi máy chủ, đường dẫn, mục đích và lớp quyền đều đã được đăng ký?
• Hệ thống có thể từ chối các điểm đến không xác định hoặc riêng tư trước khi thu thập không?
• Dữ liệu cá nhân và nhạy cảm có được loại trừ hoặc quản lý riêng không?

Hợp đồng công cụ

• Mỗi công cụ có đầu vào giới hạn và một lược đồ đầu ra được phiên bản hóa không?
• Các trường yêu cầu và có thể null có được xác định rõ ràng không?
• Mỗi trạng thái thất bại có hành động tiếp theo được phép không?

Bằng chứng

• Mỗi bản ghi được chấp nhận có giữ lại nguồn và ngữ cảnh thu thập của nó không?
• Liệu câu trả lời có thể cho thấy bằng chứng nào đã hỗ trợ nó không?
• Có thể xóa một phiên bản nguồn hoặc bản ghi một cách rõ ràng không?

Hoạt động

• Có thể kết nối chính sách, thu thập, xác thực, ngữ cảnh và phản hồi không?
• Chi phí và độ mới có được đo lường theo từng nguồn và lộ trình không?
• Các hành động có ảnh hưởng lớn có được phân tách sau xác nhận của người dùng không?

Hướng dẫn dữ liệu web trực tiếp cho đại lý AI đề cập đến các trường hợp sử dụng thu thập và tiêu chí đánh giá. Tài liệu Scrapeless cung cấp tham khảo triển khai, trong khi tổng quan về máy chủ MCP Scrapeless giải thích cách các ứng dụng đại lý tiếp cận các công cụ web Scrapeless thông qua một giao diện tiêu chuẩn. Kiểm tra giá cả Scrapeless so với khối lượng kết quả chấp nhận đo lường thay vì chỉ đơn thuần là số lần gọi thô.

Kết luận: Xây dựng Kế hoạch Dữ liệu Trước Khi Mở Rộng Đại Lý

Một đại lý không cần quyền truy cập web không hạn chế. Nó cần một bộ nhỏ các khả năng được phép được hỗ trợ bởi các hợp đồng dữ liệu ổn định.

Tách biệt lý do khỏi thu thập. Xác thực từng kết quả trước ngữ cảnh. Bảo tồn danh tính và nguồn gốc. Phát ra các thất bại kiểu. Theo dõi toàn bộ lộ trình công cụ. Các kiểm soát đó làm cho hành vi của mô hình dễ đánh giá hơn vì ranh giới bằng chứng không còn bị ẩn bên trong một lời nhắc.

---

Sẵn Sàng Để Cung Cấp Cho Đại Lý Của Bạn Một Lớp Dữ Liệu Web Có Kiểm Soát?

Tham gia cùng các nhà phát triển xây dựng công cụ đại lý và các pipeline dữ liệu web công cộng: Discord · Telegram.

Đăng ký tại app.scrapeless.com và bắt đầu với một nguồn đã được phê duyệt, một hợp đồng kiểu và một nhiệm vụ đại lý có thể quan sát.

---

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

Q: Hạ tầng dữ liệu đại lý AI là gì?

Hạ tầng dữ liệu đại lý AI là chính sách, thu thập, xác thực, chuẩn hóa, lưu trữ và khả năng quan sát cung cấp cho đại lý bằng chứng có phép, có cấu trúc và có thể truy xuất.

Q: Tại sao lớp dữ liệu web nên tách biệt khỏi mô hình?

Việc tách biệt giữ cho chính sách nguồn, thông tin xác thực, thực thi trình duyệt, lược đồ và telemetry trở nên xác định trong khi mô hình tập trung vào việc chọn lựa khả năng và lý do dựa trên bằng chứng đã chấp nhận.

Q: MCP có giải quyết mọi vấn đề độ tin cậy sản xuất không?

Không. MCP chuẩn hóa cách một ứng dụng mô hình khám phá và gọi ra các khả năng. Mỗi công cụ vẫn cần ủy quyền, đầu vào giới hạn, xác thực, kết quả kiểu, telemetry và các kiểm soát chi phí.

Q: Khi nào một đại lý cần trình duyệt đám mây?

Một đại lý cần trình duyệt đám mây khi nội dung công khai cần thiết chỉ xuất hiện sau khi render JavaScript hoặc tương tác với trình duyệt. Các trang được render ổn định nên sử dụng một lộ trình thu thập được phê duyệt đơn giản hơn.

Q: Một đại lý nên xử lý kết quả công cụ không hợp lệ như thế nào?

Hệ thống nên từ chối kết quả trước khi nó đến ngữ cảnh mô hình và trả về một trạng thái thất bại kiểu xác định xem vấn đề là chính sách, nhận diện trang, nội dung, độ mới, lược đồ hay ngân sách.

Q: Các đội nên làm gì để giảm chi phí nghiên cứu web cho các đại lý?

Chuyển mỗi nguồn đến lộ trình thu thập hợp lệ đơn giản nhất, tái sử dụng các bản ghi đã chấp nhận tươi mới, yêu cầu chỉ các trường cần thiết, loại bỏ nội dung chuẩn và giới hạn ngân sách thu thập và ngữ cảnh trước khi thực hiện.