Hầu hết các tác nhân AI (AI Agents) thất bại trong quá trình sản xuất vì chúng được xây dựng ngược.

AI tác nhân Hầu hết các tác nhân AI thất bại trong sản xuất vì chúng được xây dựng ngược Các mô hình tốt không cứu được kiến trúc tồi, và hầu hết các nhóm đều học được điều đó một cách khó khăn. Benjamin Nweke Ngày 27/5/2026 10 phút đọc Chia sẻ Hình ảnh do tác giả cung cấp (Tạo bằng ChatGPT) Lần đầu tiên tôi chứng kiến một hệ thống đa tác nhân thất bại nghiêm trọng trong sản xuất, nó không hề kịch tính. Không có sự cố. Không có thông báo lỗi. Hệ thống vẫn tiếp tục chạy và tạo ra các kết quả có vẻ hợp lý cho đến khi có người thực sự đọc kỹ chúng và nhận thấy điều gì đó không ổn. Khi chúng tôi quyết định điều tra, phải mất hai ngày gỡ lỗi để tìm ra vấn đề. Thật buồn cười, mô hình không bị ảo giác, và các công cụ đầu vào-đầu ra đang cung cấp kết quả chính xác. Vấn đề, khi chúng tôi cuối cùng tìm ra, là về kiến trúc. Mô hình và các công cụ đã được thiết lập đúng cách, nhưng ý tưởng là suy luận sẽ gắn kết toàn bộ hệ thống lại với nhau, điều mà, như bạn có thể đoán, rõ ràng đã thất bại. Hóa ra suy luận không làm được điều đó. Kinh nghiệm đó là điều tôi luôn quay lại khi nghĩ về lý do tại sao rất nhiều tác nhân AI hoạt động tốt trong các bản demo lại không thực sự tồn tại được trong sử dụng thực tế. Đó không phải là vấn đề về khả năng. Đó là vấn đề về kiến trúc. Và nếu bạn đã đọc bài viết trước của tôi trên TDS, "Tại sao các kỹ sư AI đang chuyển từ LangChain sang kiến trúc tác nhân gốc", thì mô hình này sẽ quen thuộc: các hệ thống được xây dựng từ trên xuống, từ mục tiêu đến công cụ đến mô hình, với giả định ngầm rằng hành vi thông minh sẽ lấp đầy các khoảng trống. Giả định đó là ý nghĩa của cụm từ "xây dựng ngược". Và nó phổ biến hơn hầu hết các nhóm nhận ra cho đến khi có điều gì đó hỏng hóc. Các tác nhân không phải là thực thể. Chúng là hệ thống. Một tác nhân AI sản xuất không phải là một thực thể thông minh duy nhất. Thay vào đó, có một tập hợp các thành phần tương tác với các trách nhiệm, chế độ lỗi và mức độ quan sát khác nhau. LLM là một trong những thành phần đó, không phải toàn bộ hệ thống. Chỉ là một phần của nó. Điều này có vẻ hiển nhiên khi bạn nói ra. Nhưng khung "tác nhân tự trị" đã thống trị năm 2023 và hầu hết năm 2024 đã kéo các kỹ sư đến một mô hình tư duy khác: một thực thể, một vòng lặp suy luận, mọi thứ được xử lý bởi mô hình. Tất cả những gì bạn cần là công cụ, một lời nhắc hệ thống tốt và hy vọng mọi thứ sẽ đâu vào đấy. Ngược lại, các kỹ sư đã triển khai các sản phẩm dựa trên AI thực tế hiếm khi mô tả hệ thống của họ theo cách đó. Những gì họ thực sự mô tả nghe giống như kiến trúc hệ thống phân tán hơn nhiều. Không phải vì họ đọc một cuốn sách về các mẫu thiết kế, mà vì họ đã gặp đủ nhiều vấn đề đến mức họ bắt đầu đặt cấu trúc một cách nghiêm túc hơn vào quy trình làm việc của mình. Xây dựng từ trên xuống, bắt đầu từ "tác nhân này nên làm gì" và làm ngược lại với các công cụ và lời nhắc, thì nhanh chóng để bắt đầu. Đó cũng là cách bạn kết thúc với một hệ thống mà mô hình chịu trách nhiệm quá nhiều, và không có gì có thể gỡ lỗi riêng lẻ. Kiến trúc được quyết định bởi mục tiêu, không phải bởi các yêu cầu kỹ thuật. Đó là phần ngược. Vậy điều gì thực sự tạo nên một hệ thống sản xuất? Phiên bản trừu tượng thì dễ chấp nhận. Đây là những gì nó thực sự trông như thế nào. Mọi hệ thống AI sản xuất mà tôi đã thấy hoạt động trơn tru đều có một lớp quyết định, cho dù nhóm có đặt tên như vậy hay không. Đó là phần mà mô hình tồn tại và thực hiện công việc thực tế của nó. Theo bản năng, người ta thường dồn mọi thứ vào lớp này: phân tích cú pháp yêu cầu, quản lý bộ nhớ, xử lý các lần thử lại, giải quyết lỗi công cụ. Điều này có thể chấp nhận được nếu làm việc trong môi trường Jupyter notebook. Tuy nhiên, trong môi trường sản xuất, dưới tải trọng lớn và với người dùng thực, đây sẽ trở thành phần của hệ thống mà mọi lỗi đều do tất cả các bên gây ra, và hầu hết các trường hợp đều không thể gỡ lỗi. Lớp quyết định chỉ nên thực hiện tốt một nhiệm vụ duy nhất, đó là quyết định hành động tiếp theo, dựa trên một ngữ cảnh đã được chuẩn bị sẵn. Đó là toàn bộ công việc. Ai chuẩn bị ngữ cảnh? Một thành phần khác. Ai thực hiện quyết định? Cũng là một thành phần khác. "Thành phần khác" đó chính là lớp điều phối, và trong hầu hết các hệ thống được xây dựng tốt, nó thực sự chỉ là mã code: các câu lệnh điều kiện, bộ chạy bất đồng bộ, xử lý thử lại, định tuyến hàng đợi, thậm chí có thể là một máy trạng thái tùy thuộc vào mức độ phức tạp của quy trình làm việc. Thay vì mong đợi mô hình làm mọi thứ, hãy coi nó như một thành phần khác. Ở đây, mã code tiêu chuẩn thực hiện công việc nặng nhọc với trạng thái và công cụ, vì vậy LLM chỉ cần lo lắng về việc đưa ra quyết định tiếp theo. Ảnh của tác giả. Nhiều nhóm tìm đến các framework ở đây vì mã điều phối trần trụi có vẻ quá đơn giản, như thể chắc chắn phải có nhiều cơ sở hạ tầng hơn. Thông thường thì không có. Lớp này càng ít "phép thuật" thì càng nhanh chóng tìm thấy lỗi khi chúng xuất hiện. Và chúng chắc chắn sẽ xuất hiện. Từ kinh nghiệm, tôi đã học được điều này một cách khó khăn trong một dự án mà việc điều phối nằm trong mô hình thực thi của một framework. Có điều gì đó đã thử lại các lệnh gọi công cụ theo cách làm hỏng trạng thái ở các bước tiếp theo. Chúng tôi đã mất hai ngày để tìm ra vấn đề. Hai ngày cho một lỗi lẽ ra có thể được giải quyết ngay lập tức nếu logic thử lại chỉ là ba dòng mã Python do tôi tự viết. Điều này dẫn chúng ta đến lớp công cụ và thực thi, nơi mọi giao tiếp diễn ra. Hiện tại, lớp công cụ và thực thi là nơi mọi thứ giao tiếp với thế giới bên ngoài. Lớp này thường chỉ có một nhiệm vụ, đó là nhận một đầu vào được xác định rõ ràng và sau đó tạo ra một đầu ra có thể dự đoán được. Nhưng lỗi mà tôi liên tục thấy, và thành thật mà nói, liên tục lặp lại, là các công cụ cố gắng hữu ích bằng cách làm nhiều hơn một việc. Một hàm duy nhất gọi một API, cập nhật bộ nhớ đệm và thực hiện các việc khác. Trong một thiết lập như vậy, khi nó bị lỗi, bạn không biết ở đâu. Ngay cả khi bạn cố gắng thay thế API, bạn đang gỡ rối logic lẽ ra không nên bị rối ngay từ đầu. Bộ nhớ và trạng thái là nơi tôi sẽ thúc đẩy mạnh nhất, bởi vì đó là nơi