Agentic AI Có Phải Chỉ Là Tự Động Hóa?

Trong khi các bản pitch deck về Agentic AI đang tràn ngập thị trường, một số nhà phát triển và kiến trúc sư hệ thống bắt đầu đặt câu hỏi gay gắt: liệu đây có phải chỉ là một hình thức tự động hóa được "thổi phồng"? Bài viết này phân tích ranh giới mong manh giữa hai khái niệm, chỉ ra vì sao hầu hết các ví dụ về "agent" hiện nay đều không thực sự thông minh, và đưa ra hướng đi thực tế để triển khai AI đại diện một cách hiệu quả trong doanh nghiệp.

Sự Thử Nghiệm Đầu Tiên: Định Nghĩa Theo Hình Dạng Công Việc

Tác giả bài viết, một chuyên gia từng tư vấn cho ngành hàng không, chia sẻ về thử nghiệm ban đầu của mình để phân biệt agent và automation. Tiêu chí được đưa ra là: nếu hệ thống phải đưa ra quyết định giữa chừng mà không thể dự đoán từ trước, thì đó là agent. Ngược lại, nếu mọi bước đều có thể được lập trình sẵn, thì đó chỉ là tự động hóa.

Ví dụ được đưa ra: một chiếc máy bay A320 hạ cánh với cảnh báo ECAM "AIR PACK 1 FAULT" (lỗi hệ thống điều hòa). Một hệ thống tự động hóa sẽ chỉ kích hoạt checklist và thông báo cho kỹ sư. Trong khi đó, một agent lý tưởng sẽ tự truy vấn lịch sử lỗi, nhận ra sự cố lặp lại, đối chiếu với kho phụ tùng, phân tích khả năng hoãn chuyến theo quy định MEL, và cuối cùng đề xuất một kế hoạch xử lý tối ưu dựa trên lịch bay 10 ngày tới.

Tuy nhiên, chính tác giả cũng thừa nhận điểm yếu của ví dụ này: một kỹ sư lành nghề hoàn toàn có thể vẽ ra một flowchart với 200 nhánh cho tình huống đó. Sự phức tạp không đồng nghĩa với tính mở (open-endedness) . Một cái cây lớn vẫn chỉ là một cái cây, và các công cụ workflow engine truyền thống vẫn làm việc đó rẻ hơn, nhanh hơn và đáng tin cậy hơn nhiều so với LLM.

Đường Ranh Thực Sự: Known Unknowns vs Unknown Unknowns

Sau nhiều tháng trăn trở, tác giả đưa ra kết luận quan trọng nhất của mình:

• Tự động hóa (Automation) xử lý các "known unknowns" – những thứ bạn biết mình cần kiểm tra, nhưng chưa biết kết quả.
• Agent thực thụ xử lý các "unknown unknowns" – những thứ bạn không hề biết cần phải tìm kiếm, chỉ khi bắt tay vào làm mới phát hiện ra.

Ví dụ điển hình cho loại thứ hai là thẩm định rủi ro trong một thương vụ mua bán - sáp nhập. Không thể vẽ một flowchart trước cho nhiệm vụ "xác định rủi ro vật chất trong công ty mục tiêu". Một agent đọc 3000 trang hợp đồng, tình cờ phát hiện một điều khoản bồi thường bất thường trong hợp đồng nhà cung cấp. Điều khoản này dẫn đến một hồ sơ pháp lý, hồ sơ này lại gợi ý về một cuộc điều tra môi trường không chính thức không xuất hiện trong phòng dữ liệu. Agent tiếp tục tìm kiếm trên báo chí và tòa án để ước tính rủi ro và đưa lên danh sách cảnh báo. Không ai nghĩ đến việc phải tìm kiếm thứ đó trước khi agent tìm thấy nó.

Vì Sao Các Ví Dụ Thực Tế Về Agent Khó Tìm Đến Vậy?

Câu trả lời nằm ở một thực tế đầy mỉa mai: các doanh nghiệp đã dành hàng thập kỷ để loại bỏ sự mơ hồ một cách có chủ đích khỏi quy trình của họ. Họ xây dựng SOP, hệ thống ERP, CRM, và các quy tắc phê duyệt tự động để quy trình trở nên lặp lại được và dễ kiểm toán. Hệ quả là các core process (quy trình lõi) đã được mô tả chi tiết đến mức không còn chỗ cho bất kỳ quyết định thông minh nào.

Áp lực thoát hơi của hệ thống này chính là hàng đợi ngoại lệ (exception queue). Những gì ngoài lề sẽ được chuyển lên cho con người xử lý. Chính những con người đó – các chuyên gia giàu kinh nghiệm – mới chính là "agents" đích thực. Họ ngồi ở rìa quy trình, hấp thụ những "unknown unknowns" và đưa ra phán đoán.

Khi ban lãnh đạo hỏi "dùng agent ở đâu?", họ nhìn vào quy trình lõi đã được định nghĩa chặt chẽ và kết luận "không có gì để làm". Tất nhiên là không có gì, vì họ đã mất 50 năm để biến nó thành như vậy.

Cơ Hội Nằm Ở Ranh Giới, Không Phải Ở Trung Tâm

Cơ hội thực sự nằm ở ranh giới – nơi quy trình có cấu trúc gặp gỡ thực tế hỗn loạn: nhà cung cấp ngừng tuân theo dự kiến của ERP, khiếu nại khách hàng không khớp với bất kỳ danh mục nào, hay một thay đổi quy định âm thầm vô hiệu hóa ba quy trình cùng lúc.

Hình minh họa

Lời Khuyên Cho Hành Trình Agentic

Nếu bạn đang được hội đồng quản trị hỏi về chiến lược agentic AI, hãy bắt đầu từ những nguyên tắc sau:

• Bắt đầu từ hàng đợi ngoại lệ, không phải từ danh sách use case. Đừng tổ chức workshop ý tưởng. Hãy quan sát những gì được chuyển lên, những gì nằm trong inbox hai ngày, những cuộc gọi nhờ đồng nghiệp "biết cách giải quyết." Đó chính là bản đồ của bạn.
• Giả định điểm nghẽn là quyền truy cập dữ liệu, không phải trí thông minh. Hầu hết thất bại đến từ việc agent không thể kết nối dữ liệu, metadata kém, hay nguồn sự thật nằm rải rác trong bốn file Excel.
• Xác định rõ mức độ tự chủ và viết ra giấy. Ba chế độ: Chỉ đề xuất, Hành động khi được duyệt, và Hành động rồi báo cáo. Đa số use case nên ở chế độ "chỉ đề xuất" lâu hơn nhiều so với dự kiến.
• Xây dựng bộ đánh giá (evaluation harness) trước khi xây dựng agent. Chọn 50 tình huống lịch sử có kết quả rõ ràng để kiểm tra khả năng suy luận của hệ thống trước khi triển khai.
• Chọn lĩnh vực đầu tiên mà sai lầm có thể khắc phục được, vì bạn sẽ học được nhiều điều về dữ liệu của chính mình.
• Thay đổi cách quản trị rủi ro: từ câu hỏi "quy tắc có được tuân thủ?" sang "suy luận có hợp lý? có nằm trong giới hạn? có thể tái hiện được?"

Greenfield Dễ Hơn Retrofit

Một khám phá gây bất ngờ: xây dựng hệ thống agent từ đầu dễ hơn nhiều so với nâng cấp hệ thống hiện có. Lý do rất đơn giản – các hệ thống cũ đã loại bỏ sự mơ hồ, nên không còn gì cho agent làm. Việc "thêm agent" vào quy trình cũ thường dẫn đến việc bọc một mô hình ngôn ngữ quanh một quy trình tất định, tốn kém hơn nhưng kém tin cậy hơn.

Điểm nghẽn của retrofit nằm ở các thiết kế cũ: schema tối ưu cho giao dịch, mô hình phân quyền dành cho người dùng thật, audit trail giả định đường đi cố định, SLA giả định số bước cố định. Không gì là không giải quyết được, nhưng đó là nơi tiêu tốn lịch trình.

Con đường thực dụng nhất: Đừng cố "agent hóa" quy trình chính (deterministic core). Hãy để nguyên nó vì nó đang hoạt động. Chỉ agent hóa phần ngoại lệ tràn ra từ quy trình đó.

Vậy, Tự Động Hóa Có Phải Bước Đầu Của Hành Trình Agentic?

Đúng, nhưng theo một cách không giống như nhiều người nghĩ.

Tự động hóa không phải giai đoạn 1 trong một đường cong trưởng thành kết thúc ở agent. Chúng không phải cùng một thứ ở các mức độ tinh vi khác nhau. Nhưng tự động hóa là điều kiện tiên quyết: mọi API, mọi tích hợp, mọi hành động đã được định nghĩa sẵn sẽ trở thành công cụ (tools) mà agent có thể sử dụng.

Một agent không có nền tảng tự động hóa tốt bên dưới giống như một thực tập sinh đắt tiền với... không có tay. Nó có thể suy luận tuyệt vời về việc nên làm gì, nhưng không làm được gì cả.

Doanh nghiệp đi đầu không phải là nơi bỏ qua tự động hóa để chạy theo agent, mà là nơi đã làm công việc tích hợp nhàm chán trong một thập kỷ và giờ có những thứ đáng để suy luận.

Kết Luận: Ở Đâu Tác Giả Đã Dừng Chân

Hầu hết những gì chúng ta gọi là agentic hiện nay chỉ là tự động hóa với một người dẫn chuyện tốt hơn. Điều đó không có gì đáng xấu hổ – tự động hóa là thứ có giá trị thực sự. Chỉ cần gọi nó đúng tên.

Phần còn lại – xử lý "unknown unknowns", làm việc ở rìa, thay thế hàng đợi ngoại lệ – là mảnh đất thực sự mới mà chưa công nghệ nào chạm tới. Đó chính là nơi đáng để xây dựng trong thế giới agentic AI.