Nguyen Le PhongNguyen Le Phong

AI Agent: vùng biên tiếp theo của workflow

Một góc nhìn thực tế về AI agent bên ngoài hype: điều gì thay đổi khi model có thể dùng tool, đi theo workflow, nhớ context, xin approval và tạo ra work có thể audit, cùng những chỗ human judgment vẫn phải giữ vai trò chính.

Lần đầu một AI agent tạo cảm giác khác biệt thường không quá kịch tính. Một terminal mở sẵn. Agent đọc một file, tìm reference, đề xuất một thay đổi nhỏ, chạy test, thấy test fail, rồi quay lại với một câu hỏi hẹp hơn. Không có gì giống phim viễn tưởng. Nó giống một đồng đội cẩn thận đang làm một việc có giới hạn, có đủ context để đi tiếp và đủ bất định để hỏi trước khi vượt boundary.

Cảm giác bình thường đó là lý do AI agent đáng chú ý. Chatbot phần lớn phản hồi. Agent có thể theo đuổi một mục tiêu qua nhiều bước. Nó có thể dùng tool, inspect state, gọi API, sửa file, chờ feedback, retry sau lỗi, và mang context qua một workflow. Model vẫn chỉ là một phần của hệ thống. Agent là vòng lặp lớn hơn quanh model: instruction, tool, permission, memory, planning, evaluation và human review.

Từ agent rất dễ bị dùng quá rộng. Không phải automation nào có LLM cũng là agent, và không phải agent nào cũng cần autonomous. Một định nghĩa thực tế là: AI agent là một hệ thống dùng model để quyết định hoặc hỗ trợ next action, tương tác với tool hoặc environment, và làm việc hướng tới outcome qua hơn một bước. Với định nghĩa đó, câu hỏi thiết kế nghiêm túc không phải agent có ấn tượng không. Câu hỏi là vòng lặp đó có đủ reliable cho loại việc nó được phép chạm vào không.

Tool use là thay đổi dễ thấy nhất. Khi model có thể search document, query database, mở issue, tạo draft, chạy test, hoặc gọi calendar API, nó không còn chỉ là text generator. Nhưng mỗi tool thêm một trách nhiệm. Ai cấp permission? Agent được đọc data nào? Nó được thay đổi gì? Action nào cần approval? Có log chuyện gì đã xảy ra không? Có undo được không? Thiết kế agent vừa là product design, vừa là access-control design.

Context là boundary tiếp theo. Một agent thiếu context giống contractor mới cứ hỏi lại cùng một background. Một agent có quá nhiều context chưa lọc thì dễ bị phân tán hoặc bị instruction xấu ẩn trong document kéo đi. Hệ thống agent tốt chọn context có chủ đích: goal, constraint, file liên quan, decision gần đây, example của output tốt, và rule rõ về điều gì cần bỏ qua. Context engineering không phải prompt trang trí. Nó là cách hệ thống quyết định agent được xem gì là evidence.

Memory cũng cần được đối xử cẩn thận. Một số workflow hưởng lợi khi nhớ user preference, decision cũ, vocabulary của project, hoặc correction thường gặp. Nhưng memory có thể thành nguồn assumption lỗi thời. Một preference tháng trước có thể hôm nay không còn đúng. Một decision cũ có thể không áp dụng cho project mới. Team cần memory có thể inspect, sửa, scope và quên. Nếu không, agent nghe tự tin vì nó nhớ, không phải vì điều nó nhớ vẫn đúng.

Những agent hữu ích nhất thường bắt đầu bằng workflow có boundary rõ. Triage các ticket mới. Draft weekly status report từ source đã biết. Check pull request có thiếu test không. Chuẩn bị bản đầu của release notes. Tóm tắt customer feedback và link từng theme với evidence. Những việc này có input rõ, output nhìn thấy được, và con người review kết quả. Chúng có giá trị không phải vì loại bỏ con người, mà vì giảm chi phí phối hợp âm thầm quanh knowledge work lặp lại.

Autonomy chỉ nên lớn lên cùng evidence. Rất dễ tưởng tượng một agent xử lý mọi thứ từ đầu đến cuối. Trong thực tế, team có trách nhiệm thường đi qua các mức trust nhỏ hơn. Đầu tiên agent suggest. Sau đó nó draft. Rồi nó làm low-risk action với approval. Sau đó nó xử lý reversible action trong boundary hẹp. Chỉ khi log, evaluation và kinh nghiệm vận hành đủ mạnh, agent mới nên chạm vào workflow rủi ro hơn. Trust không phải một setting. Nó là bằng chứng được tích lũy.

Evaluation là nơi hype của agent trở thành engineering. Một demo đơn lẻ có thể giấu nhiều failure mode: agent theo instruction sai, dùng document cũ, loop khi tool lỗi, action nhầm account, bịa citation, hoặc bỏ sót exception quan trọng. Team cần test task, golden example, red-team prompt, permission check, mô phỏng tool failure và review metric. Nếu output ảnh hưởng customer, money, privacy hoặc production system, evaluation không thể chỉ là cảm giác nhìn có vẻ ổn.

Human judgment vẫn ở trung tâm vì agent rất giỏi chuyển động, nhưng không phải lúc nào cũng giỏi hiểu ý nghĩa. Nó có thể gather, draft, compare và execute. Con người vẫn owns purpose, taste, ethics, prioritization và accountability. Một agent system tốt làm con người hiểu nhiều hơn và đỡ bị kéo vào bước lặp. Một hệ thống kém tạo ra work trông có vẻ xong nhưng cần cleanup vô hình. Khác biệt thường nằm ở việc workflow có được thiết kế quanh review, traceability và decision point hay không.

Vùng biên tiếp theo không phải một thế giới software làm việc không cần người. Nó là thế giới nơi software tham gia nhiều hơn vào phần giữa rất lộn xộn của công việc: tìm kiếm, chuẩn bị, kiểm tra, phối hợp và hỏi lại. Điều đó mạnh nếu mình trung thực về boundary. Agent cần goal rõ, permission hẹp, context tốt, action quan sát được, và checkpoint cho con người ở những nơi judgment quan trọng.

Có lẽ cách bình tĩnh nhất để nghĩ về AI agent là thế này: chúng không thay thế trách nhiệm. Chúng là cộng tác viên mới bên trong những hệ thống trách nhiệm. Khi hệ thống được thiết kế tốt, agent giúp quiet work tích lũy nhanh hơn và ít ma sát hơn. Khi thiết kế kém, nó chỉ di chuyển sự mơ hồ với tốc độ máy. Câu hỏi hữu ích không phải agent có phải tương lai không. Câu hỏi là phần việc nhỏ, có boundary nào hôm nay sẽ an toàn hơn, rõ hơn, hoặc nhẹ hơn nếu có agent hỗ trợ?

Bạn thấy bài viết thế nào?