Tính tất định tiệm tiến cho các tác vụ AI

Mô hình Mô hình: Tính tất định lũy tiến cho các tác vụ AI Mục thứ 32 Tác giả: Roy Osherove Ngày xuất bản: 28/10/2026 Thời lượng đọc: 3 phút Thẻ: Pattern Định dạng: Markdown (.md) Giấy phép: CC BY 4.0 Roy Osherove Ngày 28/10/2026 — 3 phút đọc Chia sẻ Phiên bản MarkdownSao chép Markdown Chuyển đổi AI theo hướng gia tăng dần tính tất định đối với các tác vụ cụ thể theo thời gian. Kiểm thử ứng dụng web: Từ hoàn toàn linh hoạt đến hoàn toàn tất định kết hợp cơ chế dự phòng Một tác tử (agent) có thể sử dụng Playwright hoặc Playwright CLI để tìm hiểu linh hoạt cấu trúc của ứng dụng, khám phá cấu trúc trang và thực hiện kiểm thử thủ công ban đầu. Sau đó, tác tử có thể tạo tập lệnh Playwright mang tính tất định nhằm lặp lại quy trình kiểm thử trong các lần tiếp theo với khả năng tái lập hoàn toàn. Trong lần thực thi kế tiếp của kịch bản cụ thể, tác tử sẽ nhận diện tập lệnh tất định đã tồn tại và ưu tiên vận hành tập lệnh này. Nếu tập lệnh tất định phát sinh lỗi, tác tử sẽ chuyển về "chế độ khám phá thủ công", sau đó tự động rà soát và khắc phục lỗi của tập lệnh tất định để chuẩn bị cho lần chạy tiếp theo. Quy trình này tiếp tục được áp dụng cho các kịch bản trong tương lai. Ví dụ Giả định một ứng dụng quản lý công việc (to-do). Tác tử nhận yêu cầu: Thêm mục “Buy milk” và xác minh mục này hiển thị trong danh sách công việc. Trong ví dụ này, ứng dụng bắt đầu mỗi lượt kiểm thử với một danh sách trống. Lần chạy đầu tiên: khám phá và lưu trữ. Tác tử rà soát trang, xác định trường “New task” cùng nút “Add” và hoàn tất thành công kịch bản. Sau đó, tác tử lưu trường hợp kiểm thử Playwright này thành tệp tests/add-task.spec.ts, sử dụng các bộ định vị theo vai trò (role locators) và câu lệnh khẳng định kết quả kỳ vọng. (playwright.dev) import { test, expect } from '@playwright/test'; test('add a task', async ({ page }) => { await page.goto('http://localhost:3000'); await page.getByRole('textbox', { name: 'New task' }) .fill('Buy milk'); await page.getByRole('button', { name: 'Add', exact: true }) .click(); await expect(page.getByRole('listitem')) .toHaveText('Buy milk'); });Tác tử thực thi bài kiểm thử đã lưu nhằm xác minh khả năng tái lập tương tác thành công. Bài kiểm thử mới này hiện có thể được đưa vào quy trình kiểm thử và xác minh liên tục. Trong trường hợp hệ thống yêu cầu tác tử kiểm thử lại quy trình tương tự bằng câu lệnh prompt: tái sử dụng bài kiểm thử đã lưu. Thiết lập một chỉ thị thường trực cho tác tử: Trước khi tiến hành khám phá ứng dụng, cần kiểm tra kịch bản này đã có bài kiểm thử tương ứng hay chưa. Nếu đã có, hãy chạy bài kiểm thử đó trước. Chỉ chuyển sang chế độ khám phá khi chưa có bài kiểm thử hoặc bài kiểm thử thất bại.Ở yêu cầu tiếp theo, tác tử tìm thấy tệp và chạy lệnh sau: (playwright.dev) npx playwright test tests/add-task.spec.tsTrong quy trình này, các tương tác trên trình duyệt và kết quả kỳ vọng đã được xác định sẵn trong mã nguồn. Sau khi trang web thay đổi: điều tra và khắc phục. Giả sử ứng dụng đổi tên nút "Add" thành "Create task". Bài kiểm thử đã lưu sẽ thất bại ở bước tìm kiếm nút bấm trong quy trình CI. Tác tử theo dõi các lượt thực thi CI/CD thất bại và tìm cách xác định nguyên nhân gốc rễ. Khi phát hiện nguyên nhân do bài kiểm thử không còn tương thích với trang web, tác tử sẽ trở lại chế độ khám phá, nhận diện nút bấm đã đổi tên, đề xuất và áp dụng sửa đổi nhỏ sau: - await page.getByRole('button', { name: 'Add', exact: true }) + await page.getByRole('button', { name: 'Create task', exact: true }) .click();Tác tử tiến hành chạy lại bài kiểm thử từ danh sách trống và chỉ duy trì bản sửa đổi sau khi câu lệnh khẳng định (assertion) ban đầu vượt qua kiểm tra thành công. Các lượt thực thi tiếp theo sẽ tái sử dụng tập lệnh đã cập nhật. Quy tắc tự động sửa lỗi bao gồm: "bảo toàn hành vi kỳ vọng". Trường hợp tính năng không còn tồn tại: Nếu ứng dụng không còn thêm mục "Buy milk" vào danh sách, điều này có thể dẫn tới một trong hai tình huống: Báo động giả (False positive): Tính năng không còn cần thiết hoặc không còn phù hợp, kéo theo bài kiểm thử cũng không còn giá trị. Tác tử cần báo cáo sự cố cùng sự thay đổi về mặt chức năng; dựa trên ý kiến đóng góp của con người hoặc mô hình LLM đóng vai trò đánh giá (LLM as a judge) với ngữ cảnh rộng hơn, tác tử có thể được cấp quyền tinh giản và loại bỏ các bài kiểm thử không còn phù hợp. Phát hiện chính xác (True positive): Tính năng bị thiếu và hệ thống đang gặp lỗi. Khi đó, bài kiểm thử sẽ thất bại đúng như dự kiến. Mô hình LLM đánh giá sẽ ghi nhận đây là một trường hợp "phát hiện chính xác". Kết luận Như vậy, bài kiểm thử khởi đầu gần như là một quy trình "thủ công", hoàn toàn động, sau đó nhanh chóng chuyển thành một bài kiểm thử tiền định (deterministic test). Phương pháp này giúp tiết kiệm thời gian và tài nguyên xử lý (token), đồng thời cung cấp một giải pháp dự phòng hiệu quả: công tác duy trì bài kiểm thử đầu cuối (E2E) từng là một thách thức lớn, song hiện nay các bài kiểm thử đã có thể liên tục được cập nhật, sửa lỗi và tinh giản để thích ứng với những thay đổi về giao diện người dùng của ứng dụng. Tái bút Trong quá trình viết bài, tác giả nhận thấy Playwright đã tích hợp sẵn cơ chế hỗ trợ các tác tử lập kế hoạch (planner), tạo lập (generator) và tự phục hồi (healer) để phục vụ mô hình này. Các tính năng này chưa được tác giả trực tiếp kiểm nghiệm nên thông tin chỉ mang tính tham khảo, song rất đáng để thử nghiệm thực tế (vui lòng phản hồi nếu có đánh giá về các công cụ này). Đọc tiếp Những điểm nghẽn mới sau giai đoạn lập trình→ Mô hình: Tài khoản do tác tử sở hữu (Môi trường triển khai)→ Fork kho lưu trữ GitHub là cơ chế tiết kiệm token mới→ Tác giả: Roy Osherove Trích dẫn: Roy Osherove (2026). “Pattern: Progressive Determinism for AI Tasks”. Robot Paper. https://robotpaper.ai/pattern-progressive-determinism-for-ai-tasks/ Nội dung được cấp phép theo CC BY 4.0 · Xem dưới dạng Markdown Bài viết trước: Graphlin - Trình hiển thị trực quan kiến trúc theo thời gian thực hỗ trợ bởi Jev