Khi AI agent làm đúng một lần: Thách thức lớn của kỹ sư thực chiến

Một kịch bản quen thuộc với bất kỳ ai từng làm việc với các hệ thống AI agent: kịch bản chạy thử nội bộ diễn ra hoàn hảo, nhưng khi đưa ra demo trực tiếp hoặc cắm vào hệ thống chạy thật, mô hình lại chọn một nhánh rẽ bất ngờ và tự đưa mình vào ngõ cụt. Đáng ngại hơn, cùng một tác vụ, cùng một câu lệnh đầu vào, lần này hệ thống xử lý đúng, lần sau lại thất bại.

Trong các báo cáo benchmark thông thường, sự phập phù này bị che khuất bởi những con số trung bình. Nhóm nghiên cứu tại IBM Research vừa chỉ ra một dẫn chứng cụ thể: khi thử nghiệm trên bộ đánh giá AppWorld, một ReAct agent sử dụng mô hình GPT-4.1 đạt tỷ lệ thành công trung bình 77,4% qua 5 lần chạy lặp lại. Nhìn lướt qua, hơn ba phần tư tác vụ hoàn thành là một con số có vẻ thuyết phục. Tuy nhiên, nếu đặt hệ thống đó vào quy trình đối soát giao dịch ngân hàng hoặc rà soát điều khoản hợp đồng - nơi đòi hỏi tính tiền định tuyệt đối - mức độ dao động này là lý do khiến nhiều dự án agent chưa thể rời khỏi môi trường thử nghiệm.

Ảo ảnh từ điểm trung bình và cái bẫy của những ngã rẽ

Điểm yếu cốt tử của các benchmark hiện tại nằm ở việc gom tất cả kết quả vào một con số phần trăm duy nhất. Con số 77,4% kia không nói cho kỹ sư biết có bao nhiêu tác vụ luôn chạy đúng trong cả 5 lần, và bao nhiêu tác vụ lúc được lúc hỏng.

Khi mổ xẻ hành vi của mô hình, IBM Research phân biệt hai loại trạng thái ra quyết định: điểm quyết định phẳng (flat decisions) và điểm quyết định sắc nhọn (sharp decisions). Ở điểm quyết định phẳng, dù agent chọn công cụ A hay công cụ B trước, kết quả cuối cùng vẫn có thể hội tụ về đúng mục tiêu. Nhưng ở điểm quyết định sắc nhọn, chỉ cần một thay đổi rất nhỏ trong phân phối xác suất token tiếp theo, agent sẽ rẽ sang một chuỗi hành động hoàn toàn khác. Một khi đã chọn sai công cụ ở bước đầu, sai số tích lũy qua từng vòng lặp ReAct sẽ kéo mô hình đi xa khỏi mục tiêu ban đầu.

Nhiều đội ngũ kỹ thuật thường xử lý vấn đề này bằng cách ép prompt thật dài, thêm thật nhiều ví dụ mẫu (few-shot examples) nhằm bịt mọi lỗ hổng. Cách làm này vô tình tạo ra ảo giác rằng hệ thống đã ổn định, bởi nó chỉ giải quyết được đúng một quỹ đạo thử nghiệm cụ thể. Khi người dùng ngoài đời thay đổi cách diễn đạt hoặc đưa vào dữ liệu biên chưa từng xuất hiện trong tập mẫu, các điểm quyết định sắc nhọn lại xuất hiện, và agent lại trượt ray.

Thay vì tiếp tục vá víu câu lệnh, giải pháp căn cơ hơn là thiết kế lại cách agent tự chẩn đoán. Hệ thống cần phát hiện sớm những điểm rẽ nhạy cảm để can thiệp bằng luật cố định (deterministic rules), thay vì phó mặc hoàn toàn cho tính ngẫu nhiên của mô hình ngôn ngữ lớn.

Dịch chuyển hạ tầng: Từ chuỗi REST API sang dòng chảy hai chiều

Trong khi bài toán ổn định logic của agent văn bản vẫn đang được giải quyết từng bước, hạ tầng mô hình nền tảng đã bước sang một cấu trúc vận hành hoàn toàn khác. Việc DeepMind giới thiệu hai mô hình Gemini 3.8 Live và 3.8 Live Extended Thinking cho thấy mô hình xử lý giọng nói trực tiếp (speech-to-speech) đang trở thành tiêu chuẩn mới.

Nhà phát triển Simon Willison khi thử nghiệm kết nối với Gemini 3.8 Live đã ghi nhận một thay đổi kỹ thuật rất đáng chú ý: toàn bộ giao tiếp không còn đi qua các lời gọi REST API tuần tự như trước. Ứng dụng kết nối trực tiếp đến endpoint WebSocket:

wss://generativelanguage.googleapis.com/ws/google.ai.generativelanguage.v1alpha.GenerativeService.BidiGenerateContent

Hệ thống sử dụng trực tiếp AudioContext của Web Audio API trên trình duyệt để thu âm và phát lại âm thanh theo thời gian thực. Điểm mấu chốt ở đây không chỉ là tốc độ phản hồi nhanh hơn, mà là khả năng xử lý dòng dữ liệu hai chiều (bidirectional streaming) cho phép người dùng ngắt lời mô hình ngay khi nó đang nói.

Sự thay đổi này đặt ra một bài toán kỹ thuật mới cho các kỹ sư xây dựng hệ thống:

Đặc tính kiến trúc	Agent dạng văn bản truyền thống	Agent âm thanh thời gian thực (như Gemini 3.8 Live)
Giao thức mạng	HTTP / REST Request-Response	WebSockets liên tục hai chiều
Quản lý trạng thái (State)	Lưu theo từng lượt hội thoại (turn-based)	Duy trì ngữ cảnh dòng chảy (stream context) liên tục
Cơ chế ngắt (Interruption)	Không hỗ trợ khi mô hình đang sinh chuỗi	Bắt buộc phải xử lý ngắt tín hiệu âm thanh tức thì
Độ trễ chấp nhận được	2 đến 10 giây cho mỗi lượt suy luận	Dưới 500 mili-giây để duy trì nhịp trò chuyện tự nhiên

Khi chuyển sang WebSockets và xử lý âm thanh thời gian thực, tính bất định của agent không còn nằm ở việc chọn sai công cụ nữa. Nó chuyển thành vấn đề quản lý phiên (session state) và độ trễ mạng. Nếu kết nối mạng chập chờn hoặc buffer âm thanh bị nghẽn, chuỗi suy luận của mô hình sẽ đứt đoạn ngay lập tức.

Cơn khát dữ liệu chuyên sâu và ranh giới của việc mở rộng mô hình

Một xu hướng khác đang diễn ra song song: các phòng lab lớn nhận ra rằng chỉ cào dữ liệu văn bản đại trà trên Internet là không đủ để agent xử lý các tác vụ thực tế phức tạp. Câu chuyện OpenAI gom mua lại dữ liệu thử nghiệm từ các công ty công nghệ sinh học phá sản - theo ý tưởng do nhà phân tích chính sách Ruxandra Teslo đề xuất - cho thấy một thực tế rõ ràng: dữ liệu chất lượng cao, có cấu trúc chặt chẽ và phản ánh đúng thế giới thực đang khan hiếm nghiêm trọng.

Để một agent có thể tự vận hành trong các lĩnh vực đặc thù như y tế, tài chính hay tự động hóa hạ tầng mạng, mô hình cần hiểu được các quy luật ngầm của ngành đó. Dữ liệu thử nghiệm lâm sàng thất bại của các công ty sinh học chính là những trường hợp biên (edge cases) quý giá nhất. Chúng chỉ ra những điểm mù mà các tài liệu nghiên cứu thành công thường bỏ qua.

Điều này phản ánh một thực tế mà giới kỹ sư cần lưu tâm: việc kỳ vọng một mô hình nền tảng tổng quát có thể tự động giải quyết trơn tru mọi quy trình nội bộ của doanh nghiệp là điều phi thực tế. Nếu không có dữ liệu nghiệp vụ chuẩn xác làm neo, agent sẽ liên tục vấp phải những điểm quyết định sắc nhọn mà chính người xây dựng hệ thống cũng không lường trước được.

Lối đi thực tế cho các đội ngũ kỹ thuật

Nhìn vào bức tranh hạ tầng hiện nay - từ bài toán nhất quán của ReAct agent cho đến luồng dữ liệu WebSocket của Gemini 3.8 Live - các đội ngũ phát triển ứng dụng AI tại Việt Nam cần điều chỉnh lại cách tiếp cận kỹ thuật nếu muốn đưa sản phẩm ra môi trường thực tế:

• Dừng việc đánh giá agent bằng một lần chạy duy nhất. Mọi bộ kiểm thử (evals) nội bộ cần chạy lặp lại tối thiểu 5 đến 10 lần trên cùng một bộ dữ liệu để đo phương sai (variance). Một tác vụ có tỷ lệ thành công 80% nhưng độ ổn định giữa các lần chạy dao động mạnh sẽ nguy hiểm hơn nhiều so với một tác vụ đạt 70% nhưng luôn đi đúng một lộ trình cố định.
• Tách bạch rõ ràng giữa phần suy luận mềm và logic cứng. Những bước chuyển trạng thái nhạy cảm liên quan đến ghi dữ liệu, gọi cổng thanh toán hay cập nhật cơ sở dữ liệu cần được khóa chặt bằng code định sẵn (deterministic code), chỉ dùng LLM cho khâu trích xuất thông tin hoặc định dạng văn bản.
• Chuẩn bị hạ tầng mạng cho giao tiếp dạng dòng (streaming). Nếu định hướng sản phẩm tiến tới giao diện giọng nói hoặc trợ lý tương tác tức thì, việc tiếp tục xây dựng hệ thống xoay quanh REST API truyền thống sẽ tạo ra món nợ kỹ thuật lớn. Cần thử nghiệm sớm với WebSockets và các cơ chế quản lý state bất đồng bộ.

Cơn sốt về AI agent đang dần đi qua giai đoạn trình diễn những tính năng hào nhoáng. Phần việc còn lại - và cũng là phần việc nặng nhất của kỹ sư phần mềm - là ghìm dây cương tính ngẫu nhiên của mô hình để biến những dòng code trình diễn thành những hệ thống vận hành bền bỉ mỗi ngày.