Tiếng Việt: What are AI agents and why they matter for QA

Nếu bạn đã làm QA (Quality Assurance - đảm bảo chất lượng) đủ lâu, bạn sẽ nhận ra một quy luật khá đau đầu: tốc độ phát triển sản phẩm tăng theo cấp số nhân, còn năng lực kiểm thử của con người thì gần như tăng theo đường thẳng. Team dev release nhanh hơn nhờ CI/CD, feature flag, trunk-based development — nhưng số lượng test case cần viết, số lượng regression cần chạy, số lượng log cần đọc để tìm nguyên nhân fail thì vẫn phải làm bằng tay, hoặc bằng script tự động do con người viết ra và bảo trì.

AI agent xuất hiện đúng vào lúc quy luật đó trở nên không thể chịu đựng được nữa. Đây không phải là một công cụ autocomplete thông minh hơn, cũng không phải chatbot trả lời câu hỏi. AI agent là một hệ thống có khả năng tự lập kế hoạch, tự gọi công cụ (tool), tự quan sát kết quả, và tự điều chỉnh hành động — lặp đi lặp lại cho đến khi hoàn thành một mục tiêu cụ thể. Với QA, đó là sự khác biệt giữa "một trợ lý gợi ý code" và "một đồng nghiệp có thể tự chạy test suite, đọc log fail, và đề xuất fix".

Bài viết này sẽ giải thích rõ kiến trúc của AI agent, phân biệt agent với các công cụ AI hỗ trợ code truyền thống, lý giải vì sao QA Engineer là một trong những nhóm nghề chịu tác động lớn nhất từ agentic AI, và đưa ra một bức tranh thực tế — không tô hồng, không dọa nạt — về những gì agent làm tốt và chưa làm tốt hôm nay.

AI Agent Là Gì? Giải Thích LLM, Tool Use, và Autonomous Loop

Nói một cách ngắn gọn: AI agent là một hệ thống dùng LLM (Large Language Model - mô hình ngôn ngữ lớn) làm "bộ não" trung tâm, kết hợp với khả năng gọi các công cụ bên ngoài (tool use), vận hành trong một vòng lặp tự động (autonomous loop) gồm lập kế hoạch, hành động, quan sát kết quả, rồi lặp lại — cho đến khi đạt được mục tiêu hoặc chạm giới hạn cho phép.

Định nghĩa này nghe có vẻ trừu tượng, nên hãy bóc nó ra thành ba lớp kiến trúc cụ thể. Hiểu rõ ba lớp này quan trọng với QA Engineer không phải vì bạn cần build agent (mặc dù biết cũng tốt), mà vì nó giúp bạn dự đoán chính xác agent sẽ hành xử như thế nào khi bạn giao việc — và quan trọng hơn, giúp bạn debug được khi agent làm sai.

Lớp 1: Nhân LLM

Ở tầng lõi, mọi AI agent đều được vận hành bởi một LLM — một mô hình được huấn luyện để dự đoán chuỗi token tiếp theo dựa trên context (ngữ cảnh) mà nó nhận được. Với QA, cách hữu ích nhất để hiểu LLM không phải là "nó biết mọi thứ", mà là "nó suy luận (reasoning) dựa trên những gì bạn đưa vào context window (cửa sổ ngữ cảnh) của nó tại thời điểm đó".

Điều này giải thích một hiện tượng mà bất kỳ QA nào từng dùng ChatGPT hay Claude để viết test case đều gặp: nếu bạn chỉ paste một dòng "viết test case cho tính năng login", kết quả sẽ chung chung, hời hợt, kiểu sách giáo khoa. Nhưng nếu bạn cung cấp đủ context — user story, business rule, edge case đã biết, format test case công ty đang dùng — chất lượng output tăng vượt bậc. LLM không "sáng tạo" ra kiến thức QA, nó tổng hợp và suy luận trên chính context bạn cấp.

Ví dụ một prompt yếu và một prompt mạnh cho cùng nhiệm vụ:

Write test cases for the login feature.

So với:

Generate test cases for the login feature based on this user story:

"As a registered user, I want to log in with my email and password
so I can access my dashboard. Account locks after 5 failed attempts
within 15 minutes. Password reset link expires after 30 minutes."

Cover: happy path, boundary conditions on the lockout counter,
session expiry, and concurrent login from two devices.
Output format: Gherkin (Given/When/Then), one scenario per case.

Prompt thứ hai không "thông minh hơn" vì câu chữ hay hơn — nó thắng vì nạp đúng loại context mà LLM cần để suy luận ra edge case thật, thay vào việc đoán từ kiến thức chung.

Mẹo: Khi review output của agent mà thấy test case hời hợt hoặc sai logic nghiệp vụ, đừng vội kết luận "AI ngu". Hỏi ngược lại: context bạn đưa vào có chứa business rule, acceptance criteria, hay chỉ có tên feature? 90% trường hợp output tệ là do thiếu context, không phải do model yếu.

Lớp 2: Sử dụng Tool (Tool Use)

LLM thuần chỉ sinh ra văn bản — nó không tự chạy được lệnh, không tự đọc được file, không tự gọi được API. Tool use (đôi khi gọi là function calling) là lớp cho phép LLM "yêu cầu" thực thi một hành động cụ thể trong thế giới thực: chạy một test suite, đọc một file log, query một database, gọi một REST API, mở một trang web bằng browser tự động hóa.

Cơ chế hoạt động: agent framework định nghĩa một danh sách tool có sẵn (kèm mô tả và schema tham số), LLM sẽ output một yêu cầu gọi tool theo đúng format đó (ví dụ run_test_suite(suite="regression", env="staging")), framework thực thi tool thật, trả kết quả về lại cho LLM dưới dạng text, và LLM tiếp tục suy luận dựa trên kết quả đó.

Với QA, đây chính là bước ngoặt so với các công cụ AI thế hệ trước. Một chatbot AI có thể gợi ý cho bạn cách viết assertion trong Playwright, nhưng nó không tự chạy được Playwright. Một AI agent có tool use thì có thể: đọc file test-results.xml, phát hiện 12 test fail, tự mở từng file log tương ứng, đối chiếu với source code liên quan qua Git, và tự đề xuất phân loại fail nào là bug thật, fail nào là flaky test.

Ví dụ prompt thực tế khi giao việc cho một agent có tool use (như Claude Code hoặc agent tương tự tích hợp trong CI):

Run the regression suite for the checkout module on the staging
environment. For every failing test, open the corresponding log file,
check if the failure correlates with a recent commit in the last 48
hours (use git log), and produce a triage table with columns:
test name, failure type (bug / flaky / environment issue), suspected
root cause, and confidence level.

Prompt này chỉ khả thi vì agent có tool use: nó thực sự chạy git log, thực sự đọc log file, thực sự thực thi test suite — không phải chỉ "tưởng tượng" ra một kết quả hợp lý.

Mẹo: Khi thiết lập agent cho QA workflow, đừng cấp toàn quyền tool ngay từ đầu. Bắt đầu với tool chỉ đọc (read-only: đọc log, đọc test result, query database read-only) trước khi cấp tool có khả năng ghi/thay đổi trạng thái (chạy test, deploy, xóa data test). Việc này giúp bạn xây dựng lòng tin vào agent dần dần, đồng thời giảm rủi ro agent gây side-effect ngoài ý muốn trên môi trường staging hoặc production.

Lớp 3: Vòng lặp tự động (Autonomous Loop)

Đây là lớp biến một "LLM có tool" thành một "agent" thực sự. Autonomous loop (vòng lặp tự động) là chu trình: Plan (lập kế hoạch bước tiếp theo) → Act (gọi tool để thực thi) → Observe (đọc kết quả trả về) → quyết định tiếp tục lặp hay dừng lại vì đã đạt mục tiêu.

Khác biệt cốt lõi so với một lần gọi API đơn (single-shot): agent không cần bạn phải chỉ dẫn từng bước một. Bạn giao mục tiêu ("tìm nguyên nhân vì sao test suite fail 30% trong tuần này"), agent sẽ tự quyết định: bước 1 cần đọc log nào, bước 2 cần chạy lệnh gì để xác minh giả thuyết, bước 3 nếu giả thuyết sai thì quay lại thử hướng khác. Vòng lặp này có thể chạy 5 bước, 20 bước, hoặc hơn, hoàn toàn không cần con người can thiệp giữa mỗi bước — trừ khi bạn thiết lập checkpoint yêu cầu xác nhận.

Ví dụ minh họa một phiên làm việc thực tế của agent trong vòng lặp autonomous:

Investigate why the "add to cart" flaky test has a 15% failure rate
over the last 2 weeks. You have access to: test logs, the git history
of the checkout module, and a shell to re-run the test locally.
Determine the root cause and propose a fix.

Khi nhận prompt này, một agent thực sự (không phải chatbot) có thể tự thực hiện chuỗi hành động: (1) đọc log của 20 lần fail gần nhất, (2) nhận thấy pattern — fail chỉ xảy ra khi response time của API giá sản phẩm vượt 800ms, (3) tự chạy lại test local với network throttling để tái hiện, (4) tra Git blame để tìm commit thêm timeout cứng 500ms vào assertion, (5) kết luận root cause là race condition do timeout quá ngắn, và (6) đề xuất patch tăng timeout kèm retry logic. Toàn bộ 6 bước đó là một vòng lặp autonomous — không ai ngồi gõ lệnh cho từng bước.

Mẹo: Khi agent chạy autonomous loop trên tác vụ quan trọng (ví dụ phân tích production incident), luôn yêu cầu nó xuất ra "reasoning trace" — tức là log lại từng bước nó đã suy luận và hành động, không chỉ đưa ra kết luận cuối. Điều này giúp bạn (QA lead hoặc reviewer) kiểm tra được agent có bỏ sót giả thuyết nào không, tránh trường hợp agent chốt sai root cause nhưng trình bày rất tự tin.

AI Agent Khác Copilot và Công Cụ Autocomplete Ở Điểm Nào?

Rất nhiều QA Engineer đã dùng GitHub Copilot, Tabnine, hoặc các công cụ autocomplete AI trong IDE để viết script test nhanh hơn. Nhưng gọi những công cụ này là "agent" là một sự nhầm lẫn phổ biến — và sự nhầm lẫn đó khiến nhiều người đánh giá thấp (hoặc đánh giá sai) năng lực thực sự của agentic AI.

Sự khác biệt nằm ở ba trục: quyền tự chủ (autonomy), khả năng lập kế hoạch nhiều bước (multi-step planning), và khả năng gọi công cụ thực thi (tool invocation) thay vì chỉ gợi ý văn bản.

Copilot và các công cụ autocomplete hoạt động theo mô hình "single-shot suggestion" (gợi ý một lần): bạn gõ code, nó dự đoán vài dòng tiếp theo dựa trên pattern đã học và context trong file hiện tại, bạn Tab để accept hoặc gõ tiếp để bỏ qua. Nó không biết gì về việc test suite của bạn có pass hay không sau khi bạn accept gợi ý đó. Nó không tự chạy lại test để kiểm tra. Nó không tự quyết định "bước tiếp theo cần làm gì" — con người luôn là người quyết định bước tiếp theo, Copilot chỉ điền vào khoảng trống bạn đang gõ.

AI agent thì ngược lại: bạn giao một mục tiêu ở tầng cao (ví dụ "viết bộ test tự động cho toàn bộ flow checkout và đảm bảo nó pass"), và agent tự chia mục tiêu đó thành các bước con, tự quyết định thứ tự thực hiện, tự gọi tool để chạy test, tự đọc kết quả fail, tự sửa code test, tự chạy lại — lặp lại vòng lặp này cho đến khi tất cả test pass hoặc agent xác định cần con người can thiệp.

Bảng so sánh cụ thể để dễ hình dung:

Một cách kiểm chứng thực tế: thử giao cho công cụ AI của bạn nhiệm vụ "chạy test suite E2E, tìm 3 test đang fail, và sửa chúng". Nếu công cụ chỉ trả lời bằng gợi ý code mà không tự chạy được lệnh npm test hoặc tương đương và không tự đọc được output, đó là công cụ hỗ trợ code, không phải agent. Nếu nó tự thực thi, tự đọc log, tự chỉnh sửa và tự verify lại — đó là agentic behavior thật.

Mẹo: Đừng đánh giá một công cụ AI là "agent" chỉ vì marketing gọi nó như vậy. Hãy tự kiểm tra bằng một task cụ thể yêu cầu ít nhất 3 bước tuần tự có phụ thuộc lẫn nhau (ví dụ: đọc file cấu hình → dựa vào đó chạy đúng câu lệnh test → đọc kết quả và ra quyết định tiếp theo). Nếu công cụ làm được trọn vòng mà không cần bạn copy-paste kết quả qua lại giữa các bước, đó mới là agentic thật.

Vì Sao AI Agent Đặc Biệt Quan Trọng Với QA Engineer?

Nhiều bài viết nói AI agent quan trọng "cho mọi ngành nghề công nghệ" — điều đó đúng nhưng chung chung. Với QA, có bốn lý do cụ thể và mang tính cấu trúc khiến agentic AI không phải một trend nhất thời, mà là một sự thay đổi buộc phải xảy ra.

Nút thắt kiểm thử mang tính cấu trúc (the testing bottleneck is structural)

Trong hầu hết tổ chức phần mềm hiện đại, số lượng developer tăng nhanh hơn số lượng QA Engineer, và tốc độ release (nhờ CI/CD) tăng nhanh hơn cả hai. Đây không phải vấn đề về năng lực cá nhân — nó là vấn đề về tỷ lệ. Một team 20 developer release 3 lần/ngày không thể được phục vụ đầy đủ bởi 2 QA Engineer làm test thủ công, cho dù họ có giỏi đến đâu.

Automation test truyền thống từng là câu trả lời cho vấn đề này, nhưng automation test cũng cần con người viết, review, và bảo trì — và bản thân việc viết + bảo trì automation test cũng trở thành nút thắt mới khi số lượng test case tăng lên hàng nghìn. AI agent tấn công trực tiếp vào nút thắt này: nó có thể tự sinh test case từ user story, tự viết script automation, và tự bảo trì (update) test khi UI hoặc API thay đổi — với tốc độ mà một team QA con người không thể theo kịp bằng tay.

Công việc QA nặng về context và có tính lặp lại cao

Một phần rất lớn công việc QA hàng ngày không đòi hỏi sự sáng tạo đột phá — nó đòi hỏi việc đọc rất nhiều thông tin (context) và lặp lại một quy trình tương tự nhiều lần: đọc user story để suy ra test case, đọc bug report để viết steps to reproduce, đọc log để tìm root cause, đọc PR diff để đánh giá phạm vi cần regression test. Đây chính xác là loại công việc mà LLM làm tốt nhất — vì bản chất LLM là một cỗ máy xử lý và tổng hợp context ở quy mô lớn, nhanh hơn con người hàng chục lần.

Ví dụ, việc một QA Engineer đọc một PR có 400 dòng thay đổi và tự suy ra "những khu vực nào có khả năng bị ảnh hưởng, cần test lại" thường tốn 20-30 phút đọc kỹ. Một agent với quyền truy cập vào diff, có thể quét toàn bộ thay đổi, đối chiếu với test suite hiện có, và đề xuất phạm vi regression trong vài chục giây — không phải vì nó "giỏi hơn" QA Engineer, mà vì nó không mệt, không bỏ sót do sao nhãng, và xử lý được lượng text lớn gần như tức thì.

Test suite bị trôi (drift) và xuống cấp theo thời gian

Bất kỳ ai từng bảo trì một bộ automation test lâu năm đều biết cảm giác này: test suite ban đầu rất "sạch", nhưng sau 2 năm, nó trở thành một mớ hỗn độn của test flaky, test trùng lặp, test kiểm tra tính năng đã bị xóa từ lâu, và selector đã lỗi thời. Đây gọi là test suite drift — sự trôi dạt giữa thực trạng sản phẩm và thực trạng bộ test, do tốc độ thay đổi sản phẩm luôn nhanh hơn tốc độ con người cập nhật test.

AI agent có khả năng làm việc mà con người thường trì hoãn vì tốn thời gian: quét toàn bộ test suite, phát hiện test trùng lặp về logic, phát hiện test đang test một flow không còn tồn tại trong sản phẩm, và đề xuất dọn dẹp (refactor hoặc xóa) — một cách có hệ thống, định kỳ, không cần "hứng" mới làm.

Coverage do con người viết thường bị lệch về happy path

Đây là một sự thật mà QA Engineer kỳ cựu nào cũng ngầm hiểu nhưng ít khi nói ra thẳng: con người, khi viết test case dưới áp lực deadline, có xu hướng tự nhiên tập trung vào happy path (luồng chính, mọi thứ diễn ra như mong đợi) và bỏ sót edge case, vì việc nghĩ ra edge case tốn nhiều công suy nghĩ hơn và không "nhìn thấy ngay" giá trị như việc cover được luồng chính.

LLM không có sự thiên vị tâm lý đó theo cách con người có. Khi được yêu cầu cụ thể "liệt kê tất cả edge case và trường hợp bất thường có thể xảy ra", nó liệt kê một cách máy móc, đầy đủ, không bỏ sót vì mệt hay vì "chắc không ai làm vậy đâu". Điều này không có nghĩa AI luôn nghĩ ra edge case đúng về nghiệp vụ (business logic) — mà có nghĩa nó là một công cụ bổ trợ rất tốt để rà soát lại danh sách test case của con người, phát hiện góc mù (blind spot) mà QA có thể đã bỏ qua do thiên vị nhận thức.

Mẹo: Thử bài tập này với chính bộ test case bạn vừa viết tay: đưa toàn bộ test case cho một agent kèm prompt "list edge cases and negative scenarios that are NOT covered by these test cases, based on this user story: [paste story]". Trong phần lớn trường hợp thực tế, bạn sẽ nhận lại ít nhất 2-3 edge case bạn đã bỏ sót — không phải vì bạn kém, mà vì thiên vị happy-path là bản chất của tư duy con người dưới deadline.

QA Engineer Nên Kỳ Vọng Gì Ở AI Agent Ngày Hôm Nay — Một Cách Thực Tế?

Phần khó nhất của việc viết về agentic AI không phải là giải thích công nghệ, mà là giữ được sự trung thực. Có hai phe cực đoan đều sai: phe nói "AI sẽ thay thế QA trong 2 năm" và phe nói "AI chỉ là hype, không dùng được gì cho công việc thật". Thực tế nằm ở giữa, và nó cụ thể hơn nhiều so với cả hai câu chuyện đó.

Những gì agent làm tốt hôm nay

Agent hiện tại rất mạnh ở các tác vụ có tính lặp lại, có pattern rõ ràng, và không đòi hỏi phán đoán nghiệp vụ sâu:

• Triage log lỗi ở quy mô lớn: đưa cho agent 200 dòng log fail từ CI, nó phân loại được nhóm lỗi nào giống nhau, nhóm nào có khả năng là flaky test, nhóm nào cần escalate — nhanh hơn con người rất nhiều lần.
• Sinh test case nháp (draft) từ user story hoặc từ API spec (OpenAPI/Swagger): không hoàn hảo 100%, nhưng là một điểm khởi đầu tốt hơn nhiều so với trang giấy trắng.
• Viết và bảo trì script automation lặp lại: ví dụ chuyển một test case Gherkin thành code Playwright/Cypress theo template có sẵn của team.
• Rà soát PR diff để gợi ý phạm vi regression cần test lại.
• Tổng hợp báo cáo test run thành ngôn ngữ dễ hiểu cho stakeholder không kỹ thuật.

Ví dụ một prompt thực tế khai thác đúng điểm mạnh này:

Here is the OpenAPI spec for the /orders endpoint [paste spec].
Generate a draft set of API test cases covering: valid requests,
missing required fields, invalid data types, boundary values for
numeric fields, and expected 4xx/5xx responses. Flag any ambiguity
in the spec that needs confirmation from the backend team before
finalizing test cases.

Lưu ý phần cuối prompt — yêu cầu agent "flag ambiguity" (đánh dấu điểm mơ hồ) là một kỹ thuật quan trọng: nó buộc agent thừa nhận giới hạn thay vì tự tin đưa ra giả định sai.

Những gì agent vẫn còn yếu hôm nay

• Hiểu business rule phức tạp, đặc thù ngành: agent không tự biết quy định pháp lý ngành ngân hàng của Việt Nam, hoặc logic nghiệp vụ đặc thù mà chỉ có trong đầu vài người trong công ty. Nó chỉ suy luận tốt trên những gì được viết ra rõ ràng trong context.
• Phán đoán mang tính đánh giá rủi ro (judgment call): ví dụ quyết định "bug này có nên block release không" đòi hỏi hiểu ngữ cảnh kinh doanh, mức độ chấp nhận rủi ro của công ty — một loại phán đoán agent chưa đủ tin cậy để tự quyết một mình.
• UI phức tạp, động, và flaky: các flow UI có animation, lazy-loading, hoặc state phụ thuộc vào timing vẫn là điểm yếu của agent khi vận hành qua browser automation — nó dễ bị nhầm giữa "app đang chậm" và "app bị bug".
• Kiểm thử liên quan bảo mật (security-sensitive testing): pentest, kiểm tra lỗ hổng nghiệp vụ (business logic vulnerability) đòi hỏi tư duy "kẻ tấn công" sáng tạo mà agent hiện tại chưa thể thay thế chuyên gia security con người.

Vai trò của bạn dịch chuyển, không biến mất

Đây là điểm quan trọng nhất của cả bài viết, và cũng là điểm dễ bị hiểu sai nhất. AI agent không loại bỏ nhu cầu về QA Engineer — nó loại bỏ nhu cầu về loại công việc QA thuần lặp lại, cấp thấp. Vai trò QA đang dịch chuyển từ "người viết test case và script bằng tay" sang ba vai trò mới, thường tồn tại đồng thời trong cùng một người:

• Reviewer: người thẩm định output của agent — test case agent sinh ra có đúng nghiệp vụ không, có bỏ sót rủi ro nào không.
• Orchestrator (người điều phối): người thiết kế quy trình để agent và automation truyền thống phối hợp với nhau trong pipeline CI/CD, quyết định bước nào giao cho agent, bước nào con người phải quyết.
• Prompt engineer cho quy trình QA: người biết cách viết prompt/instruction đủ chi tiết, đủ context, để agent tạo ra output đáng tin cậy — kỹ năng này thực chất chính là kỹ năng phân tích yêu cầu (requirement analysis) mà QA giỏi vốn đã có, chỉ đổi "người nghe" từ đồng nghiệp sang agent.

Nói cách khác: QA Engineer giỏi nhất trong 3-5 năm tới không phải là người AI-phobic (né tránh AI) hay người AI-dependent (phụ thuộc mù quáng vào AI), mà là người hiểu rõ giới hạn của agent đủ để biết khi nào tin, khi nào phải tự tay kiểm tra lại.

Mẹo: Đừng chờ đến khi công ty "chính thức" áp dụng AI agent vào quy trình QA mới bắt đầu học. Ngay từ hôm nay, chọn một tác vụ lặp lại, tốn thời gian nhất trong công việc của bạn (ví dụ: viết test case từ user story, hoặc triage log fail hàng tuần), và thử giao nó cho một agent trong 2 tuần liên tục. Ghi lại tỷ lệ output cần sửa so với dùng được ngay — con số đó chính là thước đo thực tế, đáng tin hơn bất kỳ bài báo hype nào, về việc agent đã sẵn sàng đến đâu cho công việc cụ thể của bạn.