AI agent cho doanh nghiệp: vì sao độ tin cậy là phép nhân, không phải phép cộng

Ngày 25/6/2025, Gartner công bố dự báo rằng hơn 40% dự án agentic AI sẽ bị hủy trước cuối năm 2027, với ba nguyên nhân được nêu: chi phí leo thang, giá trị nghiệp vụ không rõ ràng, và kiểm soát rủi ro không đủ. Đáng chú ý là cả ba đều không phải vấn đề về năng lực model.

Nếu bạn đã thử đưa một agent vào production và thấy nó chạy tốt trong demo rồi hỏng dần khi gặp dữ liệu thật, bài này giải thích cơ chế đằng sau — và cách tính toán nó trước khi cam kết ngân sách.

Phép nhân, không phải phép cộng

Một chatbot xử lý một lượt: nhận câu hỏi, trả lời. Một agent xử lý một chuỗi: đọc yêu cầu, gọi công cụ, đọc kết quả, quyết định bước tiếp, gọi công cụ tiếp, và cứ thế cho đến khi xong. Khác biệt này không phải về độ phức tạp — nó là khác biệt về **cách sai số tích lũy**.

Giả sử mỗi bước của agent có độ tin cậy p. Xác suất cả chuỗi n bước đúng trọn vẹn, nếu các bước độc lập với nhau, là p mũ n:

• **p = 99%** — 5 bước: 95,1% · 10 bước: 90,4% · 20 bước: 81,8% · 30 bước: 74,0%
• **p = 95%** — 5 bước: 77,4% · 10 bước: 59,9% · 20 bước: 35,8% · 30 bước: 21,5%
• **p = 90%** — 5 bước: 59,0% · 10 bước: 34,9% · 20 bước: 12,2% · 30 bước: 4,2%
• **p = 80%** — 5 bước: 32,8% · 10 bước: 10,7% · 20 bước: 1,2%

Hãy đọc lại dòng thứ hai. Một agent mà **mỗi bước đúng 95% số lần** — con số nghe rất khá — chỉ hoàn thành trọn vẹn một quy trình 20 bước ở 35,8% số lần chạy. Đây chính là cơ chế đằng sau hiện tượng quen thuộc: agent chạy đúng trong buổi demo với ba bước, rồi "tự nhiên kém đi" khi được nối vào quy trình thật với hai mươi bước.

Cộng đồng nghiên cứu đã đặt tên cho vấn đề này. Benchmark τ²-bench của Sierra đưa ra chỉ số `pass^k` — "cả k lần thử đều thành công" — để phân biệt với `pass@k` quen thuộc ("ít nhất một trong k lần thành công"). Với người dùng cuối, `pass@k` gần như vô nghĩa: khách hàng không chạy lại quy trình tám lần để lấy lần tốt nhất.

Một lưu ý kỹ thuật đáng nói: bảng trên giả định các bước **độc lập**. Trong thực tế lỗi thường tương quan — cùng một điểm mơ hồ trong prompt sẽ gây sai ở cùng một bước qua nhiều lần chạy. Điều đó có nghĩa số đo thực nghiệm có thể khác con số lý thuyết theo cả hai chiều, và đó chính là lý do bạn phải **đo trên tác vụ của mình** thay vì suy ra từ điểm benchmark của model.

Vì sao chatbot chạy được mà agent thì không

Khác biệt thứ hai quan trọng hơn phép nhân, và ít được nói tới: **hậu quả của một lỗi không cùng loại**.

Khi chatbot sai, nó tạo ra một câu trả lời sai. Người dùng đọc, thấy không ổn, hỏi lại. Thiệt hại nằm trong phạm vi hội thoại.

Khi agent sai, nó **đã thực hiện một hành động**. Nó đã gửi email cho khách hàng, đã cập nhật một bản ghi trong ERP, đã hoàn tiền, đã xoá một file. Sai số không còn nằm trong hội thoại mà đã đi vào dữ liệu và vào thế giới thật. Và vì agent tự quyết bước tiếp theo dựa trên kết quả bước trước, một hành động sai ở bước 3 sẽ định hình sai toàn bộ các bước còn lại — theo hướng trông vẫn hợp lý từ bên trong.

Đây là lý do câu hỏi đúng khi thiết kế agent không phải "model có đủ thông minh không" mà là **"nếu công cụ này bị gọi sai vào lúc tệ nhất, hậu quả tối đa là gì"**.

Ba bức tường mà pilot thường không thấy trước

• **Chi phí tăng theo số bước, không theo số yêu cầu.** Mỗi bước của agent là một lượt gọi model, và mỗi lượt phải mang theo toàn bộ ngữ cảnh đã tích lũy. Chi phí vì thế không tăng tuyến tính mà gần với bậc hai theo số bước. Với thế hệ model có suy luận thích ứng bật mặc định, đơn giá mỗi triệu token đã không còn là chỉ số đủ để dự toán — thứ cần đo là token thực tiêu thụ cho một quỹ đạo hoàn chỉnh.
• **Độ trễ cộng dồn không che được.** Một chatbot 2 giây là chấp nhận được. Một agent 12 bước, mỗi bước 2 giây, là 24 giây người dùng nhìn vào màn hình chờ. Streaming giúp cảm giác dễ chịu hơn nhưng không đổi được tổng thời gian, và với quy trình nội bộ chạy theo lô thì độ trễ trở thành giới hạn thông lượng.
• **Đánh giá bằng độ chính xác câu trả lời cuối là đo sai thứ.** Một agent có thể trả lời đúng nhờ hai bước sai triệt tiêu nhau — và bạn sẽ không biết cho đến khi dữ liệu đổi một chút và chúng thôi triệt tiêu. Cần đo ở mức **quỹ đạo**: chuỗi lời gọi công cụ, tham số truyền vào, kết quả trung gian. Đây là công việc tương tự đánh giá chất lượng retrieval trong pipeline RAG, chỉ khó hơn vì không gian trạng thái lớn hơn nhiều.

Bảo mật: khi prompt injection trở thành leo thang đặc quyền

Trong OWASP Top 10 cho ứng dụng LLM bản 2025, prompt injection giữ vị trí LLM01 — hạng nhất, năm thứ hai liên tiếp. Hạng LLM03 là *Excessive Agency*, và đây là mục được mở rộng nhiều nhất so với bản trước. Không phải trùng hợp: hai rủi ro này nhân nhau.

Với một chatbot, injection thành công cho ra một câu trả lời không mong muốn. Với một agent có quyền gọi công cụ, injection thành công cho phép kẻ tấn công **dùng chính quyền hạn của agent**. Nếu agent đọc được hộp thư, một email chứa chỉ dẫn giấu trong nội dung có thể trở thành lệnh. Nếu agent tra cứu tài liệu nội bộ qua RAG, một tài liệu bị nhiễm sẽ đi thẳng vào ngữ cảnh — đây gọi là injection gián tiếp, và nó không cần kẻ tấn công tiếp cận được giao diện chat.

OWASP cũng công bố một bảng riêng cho ứng dụng agentic tại Black Hat Europe 2025, trong đó có hạng mục *Agent Goal Hijack*: kẻ tấn công không phá agent, mà **đổi mục tiêu của nó** bằng nội dung độc hại. Agent vẫn hoạt động bình thường, vẫn ghi log đầy đủ, chỉ là đang làm việc cho người khác.

Nguyên tắc thực dụng: mọi nội dung agent đọc từ bên ngoài — email, tài liệu, trang web, phản hồi API — đều phải được coi là **chưa tin cậy**, giống hệt cách xử lý input người dùng trong một web app. Đây là cùng một nguyên tắc zero-trust áp dụng cho một bề mặt mới. Khác biệt là ở đây "validate input" không đủ, vì bản chất của model là làm theo chỉ dẫn bằng ngôn ngữ tự nhiên — nên lớp phòng vệ thật phải nằm ở **quyền của công cụ**, không nằm ở việc lọc văn bản.

Phần đã chuẩn hoá: MCP

Có một tin tốt trong bức tranh này. Tháng 12/2025, Anthropic chuyển Model Context Protocol (MCP) cho Agentic AI Foundation thuộc Linux Foundation, biến nó thành một chuẩn mở trung lập nhà cung cấp; hiện MCP được hỗ trợ gốc bởi Anthropic, OpenAI, Google DeepMind và Microsoft. Theo tổng hợp tình hình triển khai tháng 7/2026, 78% đội AI doanh nghiệp được khảo sát đã có agent dùng MCP trong production và 28% doanh nghiệp Fortune 500 đang chạy MCP server. Con số khảo sát nên đọc với biên độ, nhưng hướng đi thì rõ.

Ý nghĩa thực tế với doanh nghiệp: **lớp kết nối công cụ không còn là chỗ để tự phát minh**. Trước MCP, mỗi cặp model–hệ thống cần một tích hợp riêng, và đổi model nghĩa là viết lại. Với MCP, bạn xây một server cho mỗi nguồn dữ liệu và mọi client tuân chuẩn đều dùng được — nghĩa là quyết định chọn model trở nên có thể đảo ngược, đúng nguyên tắc không lock-in mà chúng tôi áp dụng cho tầng AI Orchestrator.

Khi nào nên dùng agent, khi nào nên dùng workflow tất định

Đây là phần quyết định dự án sống hay bị hủy, và câu trả lời thường ngược với kỳ vọng: **phần lớn quy trình nghiệp vụ không cần agent**.

Nếu bạn biết trước các bước, biết trước thứ tự, và biết trước điều kiện rẽ nhánh — đó là một workflow. Viết nó bằng code thường: rẻ hơn, nhanh hơn, kiểm thử được, log đọc được, và tin cậy 100% ở những bước không cần suy luận. Dùng model cho **đúng những chỗ cần phán đoán ngôn ngữ** — phân loại một email, trích xuất trường từ một tài liệu tự do, viết bản nháp phản hồi — rồi giao phần điều phối cho code.

Agent tự quyết chuỗi hành động chỉ thực sự xứng đáng khi cả ba điều sau đúng:

• **Không thể liệt kê trước các bước.** Đầu vào đa dạng đến mức mọi cây quyết định viết tay đều bỏ sót nhánh — ví dụ điều tra một sự cố mà không biết trước phải tra bảng nào.
• **Chuỗi đủ ngắn hoặc kiểm tra được từng bước.** Nếu quỹ đạo dài mà không có cách xác nhận từng bước, phép nhân ở đầu bài sẽ quyết định kết cục.
• **Chi phí một lần sai đủ thấp, hoặc có bước xác nhận.** Đọc và tổng hợp thì sai được. Chuyển tiền thì không.

Cách phân chia này không mới — nó chỉ là nguyên tắc "dùng công cụ đúng việc" mà chúng tôi đã viết trong AI không phải công cụ vạn năng, áp dụng cho lớp bài toán agentic.

Bắt đầu thế nào cho một doanh nghiệp đang vận hành

• **Chọn một quy trình có ranh giới rõ.** Không bắt đầu bằng "trợ lý AI cho toàn công ty". Chọn một việc có đầu vào xác định, đầu ra kiểm tra được, và tần suất đủ cao để tiết kiệm thấy được bằng số.
• **Chạy tất định trước, thêm phán đoán sau.** Xây workflow bằng code cho phần khung, chỉ chèn lời gọi model ở những bước thực sự cần hiểu ngôn ngữ. Bạn sẽ thường phát hiện phần "cần agent" nhỏ hơn nhiều so với hình dung ban đầu.
• **Ghi log toàn bộ quỹ đạo từ ngày đầu.** Không phải để gỡ lỗi lúc có sự cố, mà để có tập dữ liệu đánh giá. Không có log quỹ đạo thì mọi cải tiến sau này chỉ là cảm giác.
• **Định nghĩa ngưỡng dừng trước khi bắt đầu.** "Nếu sau bốn tuần tỉ lệ hoàn thành trọn vẹn dưới X% thì chuyển sang phương án tất định" — viết ra con số này lúc còn tỉnh táo. Đây là điều tách một pilot có kết luận khỏi một pilot chạy mãi rồi bị hủy trong im lặng, đóng góp vào con số 40% của Gartner.

Kết luận

Agent không phải một chatbot thông minh hơn. Nó là một hệ thống nhiều bước mà độ tin cậy **nhân xuống** chứ không cộng lại, và mỗi bước có thể tạo ra hậu quả thật thay vì một câu trả lời sai. Hai đặc tính đó giải thích gần hết những gì Gartner gọi là chi phí leo thang và kiểm soát rủi ro không đủ.

Tin tốt là cả hai đều tính được trước. Đếm số bước, nhân độ tin cậy lại, hỏi từng công cụ về hậu quả tối đa nếu bị gọi sai, và chuyển mọi phần tất định về cho code. Phép tính đó mất một buổi chiều, và nó là khác biệt giữa một dự án có kết luận và một dự án nằm trong 40% kia. Xem năng lực AI & ML của KonexForge, hoặc liên hệ nếu bạn muốn đánh giá một quy trình cụ thể trước khi cam kết ngân sách cho nó.