Google đúc kết 4 mô hình kỹ thuật từ các dự án AI Agent xuất sắc nhất

2 THÁNG 9, 2026

Chúng tôi vừa khép lại cuộc thi Google for Startups AI Agents Challenge với hàng ngàn nhà phát triển từ khắp nơi trên thế giới cùng tham gia xây dựng các tác nhân (agent), và hội đồng giám khảo của chúng tôi đã chấm điểm các bài dự thi dựa trên ba hạng mục.

"Hệ thống đa tác nhân" (multi-agent-system) có lẽ là tuyên bố xuất hiện thường xuyên nhất trong các bài dự thi. Tuy nhiên, khi xem xét kỹ hơn, một số thực sự là các giải pháp đa tác nhân tinh vi, trong khi số khác hóa ra chỉ là một mô hình đơn lẻ hoạt động thông qua chuỗi các câu lệnh (prompt) được gắn nhãn tên tác nhân.

Dù vậy, trong phạm vi này, những bài dự thi xếp hạng cao nhất ở mỗi hạng mục đều cho thấy cùng một vài quyết định và mô hình kỹ thuật. Dưới đây là bốn trong số đó, rất đáng để bạn áp dụng cho dự án của mình. Chúng được trích xuất từ các mã nguồn thực tế và mô tả ẩn danh, vì đây không phải là vấn đề của riêng một đội ngũ nào:

Mô hình 1: Các công cụ bạn tự xây dựng cũng có thể phục vụ những tác nhân khác

Hầu hết các bài dự thi đều sử dụng MCP theo một chiều: tác nhân gọi đến một máy chủ công cụ để lấy dữ liệu. Tuy nhiên, một đội ngũ đã mở rộng nó theo cả hai chiều. Tác nhân của họ tiêu thụ cơ sở dữ liệu đo từ xa (telemetry database) thông qua lớp công cụ MCP nội bộ, sau đó hiển thị chính khả năng suy luận đó dưới dạng một máy chủ MCP mà các tác nhân khác có thể gọi. Nhờ vậy, một tác nhân khác có thể đặt câu hỏi trực tiếp cho nó mà không cần xây dựng giao diện chat cho con người.

Phần nội bộ này tự thân nó đã quan trọng trước khi bạn tính đến phần bên ngoài. Một phiên bản đơn giản của tác nhân này sẽ chạy truy vấn SQL vào kho lưu trữ đo từ xa và đổ toàn bộ dữ liệu vào ngữ cảnh của mô hình. Trên một cơ sở dữ liệu thực tế, đó chính là cách một yêu cầu duy nhất làm cạn kiệt ngân sách token của bạn. Việc thông qua lớp công cụ MCP đồng nghĩa với việc tác nhân có các công cụ để kiểm tra và lọc dữ liệu theo lập trình, chỉ lấy về kế hoạch thực thi của một công việc hoặc một dấu vết ngăn xếp (stack trace) cụ thể thay vì toàn bộ bảng, giúp ngữ cảnh đủ nhỏ để thực sự suy luận. Việc điều phối truy cập cơ sở dữ liệu thông qua các công cụ thay vì kết nối thô cũng là yếu tố giúp phần bên ngoài của mô hình này khả thi. Việc hiển thị một công cụ chỉ trả về câu trả lời có giới hạn, đúng mục đích sẽ an toàn hơn khi cung cấp cho một bên gọi mà bạn không kiểm soát, điều mà một kết nối SQL thô không bao giờ làm được.

Đó là quyết định thay đổi bản chất của sản phẩm. Một khi khả năng suy luận của tác nhân đã nằm sau giao diện công cụ, việc hiển thị nó ra bên ngoài chỉ đơn giản là thiết lập một máy chủ MCP phía trước các công cụ đó. Trong trường hợp này, điều đó có nghĩa là một tác nhân lập trình hoạt động trong terminal hoặc IDE có thể gọi trực tiếp tác nhân hiệu năng và hỏi về một công việc cụ thể, giống như cách nó gọi bất kỳ công cụ nào khác. Con người không cần phải mở bảng điều khiển, mô tả vấn đề trong khung chat và sao chép câu trả lời vào quy trình làm việc của mình. Giao diện chat là một điểm đến, trong khi máy chủ MCP có thể là cơ sở hạ tầng mà các tác nhân khác xây dựng dựa trên đó mà không cần ai phải viết thêm một tích hợp thứ hai cho chúng.

Phần dễ bị bỏ qua: một khi bạn đang phục vụ một bên gọi mà bạn không kiểm soát, máy chủ đó cần cơ chế kiểm soát truy cập thực sự. Bất kỳ ai có thể tiếp cận nó giờ đây đều có thể gọi trực tiếp vào lớp suy luận của bạn. Một bề mặt công cụ chỉ tác nhân của bạn gọi thì không cần nghĩ đến điều đó, nhưng một bề mặt công cụ mà thế giới bên ngoài có thể gọi thì bắt buộc phải có.

Hãy thực hiện ngay hôm nay: nếu tác nhân của bạn đã giao tiếp với dữ liệu của chính nó qua MCP nội bộ, hãy kiểm tra xem cần bao nhiêu công sức để hiển thị các công cụ đó ra bên ngoài, trước khi bạn xây dựng một API thứ hai chỉ dành cho con người để thực hiện cùng một công việc.

Mô hình 2: Để các tác nhân phản ứng với cùng một sự kiện song song

Phiên bản đầu tiên của một đội ngũ là một quy trình tuyến tính: tác nhân giám sát cảm biến gọi tác nhân tuân thủ, tác nhân này lại gọi tác nhân nhắn tin cho cư dân, rồi gọi tiếp tác nhân điều phối. Nó hoạt động ổn như một bản demo, nhưng thất bại trong trường hợp sử dụng thực tế: phát hiện nguy cơ ngã từ sự thay đổi dáng đi, đối chiếu với cơ sở dữ liệu tương tác thuốc trực tuyến và gửi tin nhắn cho đúng người trước khi cơ hội hành động trôi qua.

Giải pháp là một bus sự kiện bất đồng bộ (async event bus) được xây dựng trên bốn thực thể asyncio.Queue riêng biệt, mỗi tác nhân một hàng đợi với coroutine xử lý riêng. Thay vì Tác nhân A gọi Tác nhân B và chờ giá trị trả về, các tác nhân xuất bản các sự kiện có kiểu dữ liệu (typed events) vào các chủ đề (topics) được đặt tên và đăng ký theo dõi bất kỳ chủ đề nào chúng quan tâm. Khi tốc độ dáng đi giảm từ 15% trở lên, một sự kiện CLINICAL.ANOMALY_DETECTED sẽ được xuất bản. Tác nhân tuân thủ vốn đã "đứng chờ" ở chủ đề đó, nên nó sẽ nhận sự kiện ngay lập tức, đối chiếu với cơ sở dữ liệu tương tác thuốc và xuất bản sự kiện CLINICAL.COMPLIANCE_REPORT_READY ngay khi hoàn tất, không cần chờ khoảng thời gian thăm dò (polling) hay chờ đợi bất kỳ quy trình thượng nguồn nào bàn giao. Các tác nhân nhắn tin và điều phối cũng hoạt động tương tự ở hạ nguồn, mỗi tác nhân được đánh thức bởi chủ đề mà nó đăng ký thay vì một cuộc gọi trực tiếp từ tác nhân chạy trước đó.

Đó là sự khác biệt thực sự giữa chuỗi cuộc gọi (call chain) và bus sự kiện: trong chuỗi cuộc gọi, tổng độ trễ là cộng dồn (thời gian của tác nhân một cộng với tác nhân hai, cộng với tác nhân ba) vì mỗi tác nhân đều giữ ngăn xếp mở để chờ tác nhân tiếp theo. Trên bus dựa trên chủ đề, hai tác nhân không phụ thuộc vào đầu ra của nhau sẽ chạy cùng lúc vì không bên nào chặn kết quả trả về của bên kia. Bạn cần cấu trúc này ở bất cứ nơi nào các tác nhân của bạn chạy với nhịp độ khác nhau: một cái thăm dò vài giây một lần, một cái thực hiện cuộc gọi mạng mất nửa giây, một cái chỉ kích hoạt một lần duy nhất ở cuối cùng. Nếu xâu chuỗi tất cả vào một ngăn xếp cuộc gọi duy nhất, tác nhân nhanh nhất của bạn vẫn sẽ bị nghẽn bởi tác nhân mất nhiều thời gian nhất.

Hãy thực hiện ngay hôm nay: kiểm tra xem có hai tác nhân nào của bạn cần phản ứng với cùng một tín hiệu hay không. Nếu kiến trúc của bạn bắt một tác nhân phải chờ tác nhân kia, đó chỉ là một hệ thống đơn luồng mang nhãn "đa tác nhân".

Mô hình 3: Mô hình dự phòng vẫn phải vượt qua tiêu chuẩn của bạn

Tác nhân suy luận lâm sàng của một đội ngũ khác chạy trên Gemini 3.1 Pro. Dưới tải thực tế, Pro bắt đầu trả về lỗi 503. Hầu hết các bài dự thi khác sẽ thêm một vòng lặp thử lại (retry loop) vào cùng mô hình đó rồi bỏ qua. Thay vào đó, đội ngũ này đã xây dựng cơ chế dự phòng sang Gemini 3.6 Flash với tính năng backoff, và chạy phản hồi từ bất kỳ mô hình nào qua cùng một hàm xác thực trước khi chấp nhận: một bước kiểm tra trích dẫn để xác nhận câu trả lời thực sự nêu tên một hướng dẫn lâm sàng có thật, chứ không chỉ là ngôn ngữ y tế nghe có vẻ hợp lý.

Chi tiết đáng học hỏi ở đây không phải là sự tồn tại của phương án dự phòng, mà là nơi thực hiện xác thực. Nó không bị sao chép thành hai bản cho đường dẫn chính và đường dẫn dự phòng (nơi dễ cập nhật bản này mà quên bản kia). Có một hàm validate_clinical_response duy nhất mà cả đường dẫn Pro và Flash đều bắt buộc phải gọi trước khi kết quả được xuất ra. Một khi phản hồi chạm đến hàm đó, không quan trọng mô hình nào tạo ra nó, không bên nào được ưu tiên, và không bên nào có thể đưa ra câu trả lời không đạt kiểm tra chỉ vì nó là mô hình khả dụng tại thời điểm yêu cầu được gửi đến.

Đó là điều thực sự ngăn cản phương án dự phòng làm giảm tiêu chuẩn của bạn: không phải là nhớ áp dụng cùng một tiêu chuẩn hai lần, mà là làm cho việc chỉ áp dụng một lần trở nên bất khả thi về mặt cấu trúc.

Hãy thực hiện ngay hôm nay: tìm đường dẫn mã chạy sau khi phương án dự phòng được kích hoạt. Nếu nó bỏ qua một bước xác thực mà đường dẫn chính có, bạn đang cung cấp hai sản phẩm khác nhau trong khi chỉ kiểm tra một.

Mô hình 4: Định tuyến phân tầng trước khi thực hiện cuộc gọi đắt đỏ

Chi phí suy luận (inference cost) có lẽ là ràng buộc gây tranh cãi nhất trong AI hiện nay: ai cũng muốn khả năng suy luận của mô hình tiên phong mà không muốn trả giá của mô hình tiên phong cho mọi yêu cầu. Đây là một trong những mô hình chi phí mà chúng tôi thực sự thấy hiệu quả trong sản xuất ở chu kỳ này.

Một đội ngũ đã đo lường những gì thực sự tiêu tốn ngân sách suy luận của họ và phát hiện ra đó không phải là những câu hỏi khó, mà là những câu hỏi dễ: "đơn hàng của tôi đâu", "hủy cuộc hẹn của tôi", lại đi qua cùng một cuộc gọi mô hình đầy đủ như những yêu cầu mơ hồ. Giải pháp của họ là một bộ phân loại ba lớp phía trước tác nhân: một lượt quét regex cục bộ bắt ý định điều hướng với 0 token, một trường hợp mơ hồ sẽ nhận một cuộc gọi Gemini giá rẻ với 10 token và nhiệt độ 0.1 chỉ để phân loại ý định, và chỉ những gì vượt qua cả hai mới đến được mô hình suy luận đầy đủ. Chỉ riêng lượt quét đầu tiên đó đã xử lý hơn 40% tin nhắn đến, theo đo lường của họ, trước khi bất kỳ cuộc gọi mô hình thực sự nào diễn ra. Một bài dự thi khác áp dụng ý tưởng tương tự cho một quy trình khác: một mô hình nhanh, rẻ tiền sẽ chặn và phân loại các trường hợp đến, chỉ chuyển những gì cần suy luận sâu cho một mô hình chậm hơn, đắt tiền hơn. Đừng lãng phí mô hình đắt nhất của bạn cho một quyết định mà mô hình rẻ hơn đã có thể thực hiện.

Hãy thực hiện ngay hôm nay: xem xét phân phối lưu lượng truy cập của chính bạn trước khi cho rằng bạn cần một mô hình lớn hơn. Một lượt quét đầu tiên rẻ hơn thường giúp bạn đi xa hơn.

Nhìn lại vòng thi này, các bài dự thi được xây dựng trên Agent Development Kit (ADK) và điều khiển thông qua Agents CLI là những bài dự thi xuất hiện các mô hình này thường xuyên nhất, chủ yếu vì framework này không gây khó khăn cho bạn về tính đồng thời, dự phòng hoặc chuyển giao công cụ cho tác nhân khác.

Trong cả bốn mô hình này, không có mô hình nào thực sự đòi hỏi đội ngũ lớn hơn hay mô hình mới hơn. Chúng đại diện cho các thực hành kỹ thuật đúng đắn thường bị bỏ qua. Hơn nữa, chúng kết hợp với nhau rất tốt và bổ sung cho nhau. Một đội ngũ đặc biệt nổi bật đã kết hợp mô hình một và mô hình ba trong cùng một bản dựng: một tác nhân gốc phân tán các tác nhân chuyên gia ra đồng thời, sau đó hiển thị toàn bộ lớp suy luận đó dưới dạng một máy chủ MCP mà các tác nhân khác có thể gọi trực tiếp.

Đó là tiêu chuẩn mà chúng tôi sẽ tìm kiếm trong vòng tiếp theo: một hệ thống tuân theo bốn mô hình này. Nhưng bạn không cần phải tham gia cuộc thi mới làm được. Hãy sử dụng các mô hình này trong bản dựng tiếp theo của bạn.

Trước

Tiếp theo