3 tháng xây hệ thống điều phối AI Agent: bài học thật

TL;DR: Sau 3 tháng xây và vừa hoàn thành một hệ thống điều phối nhiều AI Agent, tôi chưa có case study với số liệu đẹp để khoe. Bài này là ba quyết định kiến trúc tôi đã chọn trong quá trình đó, và lý do tôi cố tình chưa công bố hiệu quả — vì với tôi, đo đúng quan trọng hơn đo nhanh.

3 tháng trước, tôi ngồi lại và thừa nhận một điều khó chịu: một mình không thể kịp làm hết mọi việc, dù có dùng bao nhiêu công cụ AI rời rạc. Mỗi agent làm tốt việc của nó nhưng không "nói chuyện" được với nhau, và tôi trở thành người duy nhất chạy giữa các mảnh ghép để ghép chúng lại. Bài viết này không phải một case study đóng gói đẹp đẽ với biểu đồ tăng trưởng. Đây là building in public đúng nghĩa — kể lại ba quyết định kiến trúc tôi đã chọn khi xây hệ thống điều phối AI Agent cho công việc cá nhân, và vì sao tôi chưa vội công bố bất kỳ con số hiệu quả nào dù hệ thống đã chạy được.

Bài toán ban đầu: một mình không kịp làm hết, và quyết định "vậy thì tự xây"

Trước khi bắt tay vào xây, tôi đã thử cách dễ hơn nhiều: dùng từng AI Agent rời rạc cho từng việc — một cái viết nháp nội dung, một cái tra cứu dữ liệu, một cái xử lý yêu cầu khách hàng. Vấn đề không nằm ở chất lượng từng agent. Vấn đề là tôi phải làm "keo dán" thủ công giữa chúng: copy kết quả từ chỗ này, dán vào chỗ kia, tự nhớ agent nào đang làm gì, agent nào cần dữ liệu mới nhất. Càng thêm việc, tôi càng giống một tổng đài viên hơn là người ra quyết định.

Tôi đã viết chi tiết hơn về gốc rễ của quyết định này — tại sao tôi chọn tự xây bộ điều phối thay vì tiếp tục ghép nối các công cụ rời rạc — trong bài tại sao tôi tự xây bộ điều phối AI Agent thay vì mua sẵn. Ở đây tôi chỉ nhắc lại phần cốt lõi: điểm nghẽn không phải là thiếu công cụ AI, mà là thiếu một lớp điều phối biết agent nào nên làm gì, khi nào, và với dữ liệu nào. Khi nhận ra điều đó, câu hỏi không còn là "dùng thêm tool nào" mà là "vậy thì tự xây lớp điều phối này".

Quyết định tự xây không phải vì tôi thích code hơn viết nội dung. Nó đến từ một nhận định rất Director Mindset: nếu lớp điều phối là thứ quyết định toàn bộ workflow có chạy trơn tru hay không, thì đó không phải việc nên phó mặc cho một công cụ đóng hộp mà tôi không kiểm soát được logic bên trong.

Ba quyết định kiến trúc tôi đã chọn trong 3 tháng qua

Ba tháng không đủ để hoàn thiện mọi thứ, nhưng đủ để tôi phải chốt vài quyết định kiến trúc không dễ đảo ngược sau này. Dưới đây là ba quyết định tôi cho là quan trọng nhất, nói ở tầng khái niệm — không đi vào chi tiết hạ tầng hay tên gọi nội bộ.

1. Một lớp bộ nhớ/tri thức dùng chung, thay vì mỗi agent tự nhớ theo cách riêng

Sai lầm phổ biến khi ghép nhiều AI Agent là để mỗi agent tự quản lý ngữ cảnh của nó. Kết quả là agent A biết một phần sự thật, agent B biết một phần khác, và không ai có bức tranh đầy đủ. Tôi chọn tách một lớp bộ nhớ/tri thức dùng chung ra khỏi từng agent — coi đó là "sự thật nền" mà mọi agent đều đọc từ cùng một nguồn, thay vì mỗi agent tự diễn giải theo dữ liệu riêng nó có.

2. Cơ chế điều phối multi-agent theo vai trò, không theo thứ tự cố định

Ban đầu tôi thử thiết kế theo kiểu quy trình tuyến tính: agent 1 xong thì chuyển agent 2, agent 2 xong thì chuyển agent 3. Cách này gãy ngay khi thực tế không đi theo kịch bản — có việc cần bỏ qua bước, có việc cần quay lại. Tôi chuyển sang mô hình điều phối theo vai trò: mỗi agent được định nghĩa bằng phạm vi trách nhiệm, và một lớp điều phối trung tâm quyết định việc nào giao cho vai trò nào dựa trên ngữ cảnh hiện tại, không phải theo một chuỗi cố định.

3. Phân cấp quyền tự chủ, thay vì "AI làm hết" hay "AI chỉ đề xuất"

Đây là quyết định tôi thận trọng nhất, vì tôi đã từng trả giá cho việc để AI tự chủ quá sớm — tôi có kể chi tiết ở phần cuối bài. Lần này tôi thiết kế theo phân cấp: một số việc rủi ro thấp, lặp lại nhiều, tôi cho agent tự làm và tự chốt. Một số việc có tác động ra bên ngoài (gửi tin nhắn, đăng nội dung công khai, thay đổi dữ liệu quan trọng) bắt buộc phải qua một bước xác nhận của tôi trước khi thực thi. Ranh giới này không cố định — tôi đang dịch chuyển dần khi có đủ niềm tin vào từng loại việc cụ thể.

Cả ba quyết định này đều có một điểm chung: tôi ưu tiên khả năng kiểm soát và sửa sai hơn là tốc độ triển khai ban đầu. Điều đó khiến 3 tháng trôi chậm hơn tôi tưởng, nhưng tôi không hối tiếc.

Vì sao tôi chưa công bố số liệu hiệu quả — dù hệ thống đã "xong"

Hệ thống vừa hoàn thành xây dựng và triển khai, nhưng "xong" ở đây nghĩa là chạy được, không phải đã được đo đạc đủ lâu. Tôi chưa công bố số liệu hiệu quả vì chưa có đủ thời gian vận hành thực tế để tách được kết quả thật ra khỏi hiệu ứng mới toanh (novelty effect) của một hệ thống vừa lên.

Đây là phần tôi phải thẳng thắn nhất trong bài viết này. Hệ thống đã hoàn thành phần xây dựng và bắt đầu vận hành. Nhưng "xong" không đồng nghĩa với "đã chứng minh được hiệu quả". Ba tháng đầu là giai đoạn tôi tập trung cho việc hệ thống chạy đúng, chạy ổn định, chưa phải giai đoạn đo lường tác động thật.

Tôi từng thấy quá nhiều nội dung marketing công bố số liệu ấn tượng ngay khi sản phẩm vừa ra mắt — và tôi hiểu vì sao: giai đoạn launch luôn cần một câu chuyện tốt. Nhưng với nội dung cá nhân dưới tên Tôi Là Tùng, tôi chọn một chuẩn khác cho chính mình: không đưa ra con số nào mà tôi chưa tự đo đạc và tin tưởng. Một hệ thống mới chạy vài tuần chưa đủ để biết liệu mức cải thiện là thật, hay chỉ là vì tôi đang để ý sát sao hơn bình thường trong giai đoạn đầu.

Nói cách khác: tôi thà không có số liệu, còn hơn có số liệu mà chính tôi cũng không chắc nó phản ánh đúng thực tế.

Điều tôi sẽ đo trong tháng tới, và tại sao đo đúng còn quan trọng hơn đo nhanh

Trong giai đoạn tới, tôi sẽ đo hai nhóm chỉ số: mức độ hệ thống xử lý đúng việc mà không cần tôi can thiệp, và mức độ tôi tin tưởng để mở rộng quyền tự chủ cho agent. Lý do ưu tiên đo đúng hơn đo nhanh: một con số công bố sớm nhưng sai sẽ khiến chính tôi ra quyết định sai ở bước tiếp theo.

Cụ thể, tôi sẽ theo dõi hai nhóm dữ liệu trong giai đoạn tới:

• Tỷ lệ việc agent xử lý xong mà không cần tôi sửa lại hoặc can thiệp thủ công — đây là chỉ số phản ánh đúng mức độ "điều phối" đang hoạt động, thay vì chỉ đo agent có phản hồi nhanh hay không.
• Số lần tôi phải hạ quyền tự chủ của một agent xuống mức thấp hơn sau khi đã nâng lên — nếu con số này cao, nghĩa là tôi đang mở rộng quyền tự chủ nhanh hơn mức hệ thống thực sự đáng tin.

Tôi cố tình không đặt mốc thời gian cứng cho việc công bố số liệu đầu tiên. Bài học từ lần thất bại trước — khi tôi để AI tự chủ quá sớm và phải trả giá — là lý do tôi không muốn lặp lại sai lầm tương tự ở một tầng khác: công bố kết quả trước khi có đủ dữ liệu để tin vào nó. Tôi đã kể chi tiết câu chuyện đó, cùng cách tôi thiết lập lại cơ chế kiểm soát sau thất bại, trong bài bài học từ dự án AI đầu tiên thất bại vì thiếu bước kiểm soát của con người.

Kết luận

3 tháng xây hệ thống điều phối AI Agent chưa cho tôi một case study đẹp để khoe, và tôi nghĩ đó là điều bình thường của building in public — không phải mọi cột mốc đều đi kèm biểu đồ tăng trưởng. Cái tôi có được là ba quyết định kiến trúc tôi tin tưởng, và một kỷ luật cá nhân: chỉ công bố số liệu khi tôi thực sự tin vào nó. Nếu bạn cũng đang cân nhắc tự xây một hệ thống điều phối AI Agent cho công việc của mình, có lẽ câu hỏi đáng đặt ra trước tiên không phải "bao lâu thì xong", mà là "khi xong rồi, mình sẽ đo đúng bằng cách nào".