Kiến trúc AI test agent: vòng lặp Planner–Executor–Critic, ReAct và replay xác định

1. AI test agent là gì và khi nào nên dùng

Một AI test agent là chương trình dùng mô hình ngôn ngữ lớn để tự lập kế hoạch, gọi công cụ và tự đánh giá nhằm hoàn thành một mục tiêu kiểm thử. Khác với script tuyến tính, agent quyết định bước tiếp theo dựa trên quan sát vừa thu được. Nó phù hợp khi việc kiểm thử cần khám phá: dò luồng chưa có kịch bản, sinh test case mới, hoặc điều tra một bug mơ hồ. Nó KHÔNG thay thế test hồi quy đã ổn định, vì test cố định luôn nhanh hơn và rẻ hơn agent.

Điểm mấu chốt của bài này là oracle-first: trước khi cho agent chạy, phải định nghĩa rõ tiêu chí đúng-sai (bất biến nghiệp vụ, decision table, trạng thái kỳ vọng). Nếu không có oracle, agent chỉ 'thấy giao diện chạy được' và dễ báo cáo thành công giả. Oracle là thứ neo agent về sự thật; nó cũng là điều kiện dừng và là thước đo cho eval sau này. Cả kiến trúc dưới đây đều xoay quanh việc kiểm chứng oracle chứ không phải hoàn thành thao tác.

• Dùng agent: khám phá luồng mới, sinh nháp test, điều tra flaky.
• Không dùng agent: smoke test, hồi quy đã ổn định, kiểm tra nhanh CI.
• Luôn có người chốt oracle nghiệp vụ và duyệt output.

2. Vòng lặp Planner – Executor – Critic

Kiến trúc phổ biến nhất chia agent thành ba vai. Planner nhận mục tiêu và bối cảnh, sinh ra một kế hoạch các bước. Executor thực thi từng bước bằng cách gọi công cụ (điều hướng, click, đọc trạng thái, gọi API). Critic quan sát kết quả, đối chiếu với oracle và quyết định: đã đạt, cần thử lại, hay cần lập kế hoạch mới. Ba vai này lặp cho đến khi thoả điều kiện dừng. Tách vai giúp mỗi phần có prompt và ràng buộc riêng, dễ kiểm thử và dễ thay thế.

Critic là mảnh dễ bị bỏ quên nhưng quan trọng nhất về chất lượng. Nếu critic chỉ hỏi 'trang có hiển thị không', agent sẽ trôi theo hallucination. Critic tốt phải kiểm chứng bất biến cụ thể: số dư sau chuyển tiền, tồn kho không âm, idempotency khi retry. Critic cũng phát hiện khi agent đi lạc (lặp vô ích, rời scope) để kích hoạt replan hoặc dừng. Hãy coi critic như một reviewer nghiêm khắc, không phải một cheerleader.

3. Mẫu ReAct: suy nghĩ – hành động – quan sát

ReAct (Reasoning + Acting) là cách executor xen kẽ suy luận và hành động. Mỗi vòng gồm ba phần: thought (agent nói lý do), action (một lời gọi tool có cấu trúc), observation (kết quả trả về từ tool). Việc buộc agent viết thought trước khi hành động giúp quyết định minh bạch và dễ debug. Quan trọng hơn, action phải là dữ liệu có cấu trúc (tên tool + tham số) chứ không phải văn xuôi, để lớp guardrail có thể kiểm tra và chặn trước khi thực thi.

Mỗi observation nên được tóm gọn và chuẩn hoá trước khi đưa lại vào ngữ cảnh, tránh nhồi cả trang HTML làm phình token và gây nhiễu. Với kiểm thử web, observation lý tưởng là cây accessibility (role/name) chứ không phải pixel, vì nó ổn định và ít nhiễu. Chuỗi thought-action-observation này chính là trace — nguồn dữ liệu để replay xác định và để quan sát quyết định ở các chương sau.

// ReAct step: agent luôn trả action CÓ CẤU TRÚC, không phải văn xuôi.
type Action =
  | { tool: "navigate"; url: string }
  | { tool: "click"; role: string; name: string }
  | { tool: "fill"; field: string; value: string }
  | { tool: "readState"; key: string }
  | { tool: "assert"; invariant: string; expected: unknown }
  | { tool: "finish"; verdict: "pass" | "fail"; evidence: string };

interface ReActStep {
  thought: string;      // vì sao chọn action này (bắt buộc)
  action: Action;       // guardrail sẽ validate trước khi chạy
}

// Vòng lặp executor
async function runStep(ctx: Ctx): Promise<Observation> {
  const step = await model.next<ReActStep>(ctx.history, ctx.tools);
  ctx.log({ type: "thought", text: step.thought });
  guardrail.assertAllowed(step.action);          // chặn action cấm/ngoài scope
  const obs = await tools.invoke(step.action);   // thực thi tool
  return normalizeObservation(obs);              // tóm gọn trước khi đưa lại ctx
}

4. Memory và state: scratchpad, trace và seed

Agent cần bộ nhớ để không lặp lại và để nhớ mục tiêu. Có ba tầng: short-term (scratchpad của lượt hiện tại: kế hoạch, các bước đã làm), episodic (trace đầy đủ của một lần chạy, dùng để replay và điều tra), và long-term (kiến thức tái dùng: selector đã kiểm chứng, bug đã biết). Tách rõ ba tầng giúp kiểm soát token và giúp việc chạy lại có thể tái tạo chính xác. State của thế giới (dữ liệu app) phải được seed cố định để mỗi lần chạy bắt đầu từ cùng một điểm.

Điểm cần khắc cốt: mọi nguồn ngẫu nhiên phải kiểm soát được. Đó là seed sinh dữ liệu, thời gian (freeze clock), thứ tự dữ liệu, và cả nhiệt độ (temperature) của model khi cần tái tạo. Nếu bỏ sót một nguồn, cùng một input sẽ cho ra hành vi khác nhau và bạn mất khả năng replay. State và seed là nền tảng cho hai chương tiếp: điều kiện dừng và replay xác định.