Hãy tưởng tượng thế này.
Bạn đưa cho một agent năm công cụ và một chỉ dẫn duy nhất.
Quy trình hoàn tiền của bạn có thể chạy hoàn hảo.
Sau đó, email xác nhận gặp lỗi.
Agent bắt đầu lại toàn bộ chuỗi thao tác, lặp lại một hành động vốn đã thành công trước đó.
Kết quả? Khách bị hoàn tiền hai lần.
Bản prototype chạy tuyệt vời. Hệ thống production thì không.
Vấn đề không nằm ở prompt.
Vấn đề là chúng ta yêu cầu model chạy một quy trình mà lẽ ra nó không bao giờ nên vận hành ngay từ đầu!
LLM liên tục bị ép làm công việc định tuyến, lập lịch và quản lý lỗi.
Đây là những công việc mà phần mềm thông thường đã xử lý với độ chính xác và khả năng dự đoán hoàn hảo.
Vậy mà chúng ta lại yêu cầu AI làm hai công việc mâu thuẫn nhau:
- Đọc hiểu thế giới: Diễn giải dữ liệu phi cấu trúc, không thể dự đoán trước
- Chạy quy trình: Điều phối một chuỗi sự kiện cứng nhắc, được định nghĩa sẵn
Việc thứ nhất là nơi AI tỏa sáng. Việc thứ hai thuộc về code truyền thống.
Khi bước tiếp theo đã được xác định, model không nên phải đoán.
Hãy tưởng tượng một agent tự động duy nhất được cấp năm công cụ và một chỉ dẫn lớn:
→ truy xuất lịch sử mua hàng
→ kiểm tra chính sách hoàn tiền
→ thực hiện hoàn tiền nếu đủ điều kiện
→ gửi email
→ đóng ticket
Để làm được điều này, agent phải ghi nhớ toàn bộ chuỗi thao tác, kiểm tra kết quả của từng công cụ và suy luận ra bước tiếp theo.
Nếu email xác nhận gặp lỗi sau khi tiền đã được chuyển, model sẽ cố gắng dựng lại quy trình từ context window thay vì tiếp tục từ một trạng thái thực thi an toàn.
Kết quả là tình trạng hoàn tiền hai lần mà chúng ta đã nhắc đến lúc trước.
ADK 2.0 mang lại trật tự cho sự hỗn loạn như thế nào
ADK 2.0 của Google giải quyết vấn đề này bằng một cách tiếp cận hoàn toàn mới.
Nó đưa các hành động có thể dự đoán trước trở lại thành các bước quy trình cụ thể, chỉ chèn AI vào những chỗ thực sự cần diễn giải:
[Sơ đồ quy trình hoàn tiền - nguồn: "Vì sao chúng tôi xây dựng ADK 2.0"]
Trong ví dụ trên, truy xuất lịch sử mua hàng, thực hiện hoàn tiền và đóng ticket là các thao tác phần mềm thông thường.
Việc phân tích khiếu nại và soạn thảo thông điệp xác nhận được cá nhân hóa được giao cho AI.
Kết quả là một sự kết hợp lai tuyệt vời: thực thi cố định kết hợp với suy luận tập trung.
Nhưng bạn có thể đang nghĩ: chẳng phải đây chỉ là quay lại với tự động hóa cứng nhắc sao?
Chúng ta đang hard-code chính những quy trình mà agent đáng lẽ ra phải thay thế?
À, không hẳn.
Quy trình xác định các ranh giới đã được biết trước.
Các agent vẫn xử lý những phần cần diễn giải, ngôn ngữ hoặc phán đoán.
Mục tiêu không phải là loại bỏ sự linh hoạt, mà là ngừng ép model phải tự khám phá lại cùng một đường thực thi trong mỗi lần chạy.
Bằng cách loại bỏ những quyết định không cần thiết của model, kiến trúc này thay đổi toàn bộ bài toán.
Cùng một quy trình hoàn tiền. Cùng một model.
Nhưng với ADK 2.0, token giảm từ 5.152 xuống còn 2.265, và độ trễ giảm từ 7,2s xuống 5,7s 🔥
[nguồn: "Vì sao chúng tôi xây dựng ADK 2.0"]
Cấu trúc này hoạt động như một bộ lọc tự nhiên, cắt giảm một nửa lượng token sử dụng.
Thay vì truyền toàn bộ lịch sử, các agent chỉ thấy những gì chúng cần (ví dụ: agent chính sách chỉ thấy khiếu nại).
Lợi ích là tức thì:
- Giảm nhiễu prompt và tăng tính riêng tư
- Thực thi được kiểm soát chặt chẽ
- Cơ chế an toàn: Model có thể đưa ra quyết định sai, nhưng không bao giờ tự bịa ra lộ trình của riêng nó
Frontend cũng cần ranh giới: A2UI kiểm soát giao diện của bạn như thế nào
Tuyệt vời. Quy trình hoàn tiền giờ đã nằm trong tầm kiểm soát.
ADK 2.0 đã định nghĩa lộ trình và ngăn agent tự bịa ra chuỗi thao tác của riêng nó.
Nhưng người dùng vẫn cần một cách an toàn để xem và tương tác với những gì agent tạo ra.
Nói cách khác, frontend cũng cần ranh giới!
Hãy tưởng tượng mỗi khoản hoàn tiền được duyệt giờ đều cần chữ ký của người giám sát.
Agent không nên chỉ đơn giản tạo ra văn bản:
"Khoản hoàn tiền này đã được duyệt."
Nó cần hiển thị một thẻ có cấu trúc chứa
- số tiền
- giao dịch
- lý do theo chính sách
- các nút 'Duyệt/Từ chối' rõ ràng
Đây chính là lúc A2UI của Google tham gia!
Với A2UI, agent trả về một payload JSON khai báo thay vì code frontend có thể thực thi.
Ứng dụng chủ xác thực payload đó và chỉ render những component nằm trong danh mục hỗ trợ của nó.
Agent quyết định thông tin nào xuất hiện, còn ứng dụng kiểm soát cách hiển thị.
👇 Dưới đây là các ví dụ về thẻ được render bằng A2UI, cho bạn thấy sự đa dạng của các bố cục UI mà A2UI có thể tạo ra:
Bản demo A2UI-over-MCP Recipe Studio của Google cho thấy kiến trúc này trong thực tế:
Nguồn: Google Developers Blog.
👆 Bạn có thể thấy một biểu mẫu lựa chọn tĩnh được phân phối qua MCP Resource, còn một thẻ công thức được tạo động sẽ được trả về qua MCP Tool.
A2UI render cả hai một cách tự nhiên bên trong ứng dụng chủ.
Bạn có nhận ra sự đối xứng này không?
- ADK 2.0 giới hạn những gì agent có thể làm ở backend
- A2UI giới hạn những gì nó có thể tạo ra trên frontend
Trong cả hai trường hợp, model vẫn có không gian để suy luận, nhưng chỉ trong ranh giới mà ứng dụng đã định nghĩa.
Quay lại ví dụ hoàn tiền chúng ta đang thảo luận ở trên, một khoản hoàn tiền thông thường có thể chỉ cần một thẻ phê duyệt đơn giản.
Nhưng một trường hợp tranh chấp liên quan đến ngoại lệ, tệp đính kèm hoặc hoàn trả một phần có thể cần một trải nghiệm phong phú hơn.
Đó là lúc MCP App có thể tham gia để cung cấp một không gian làm việc khép kín cho các tương tác phức tạp:
→ ADK kiểm soát những gì có thể xảy ra
→ A2UI làm cho kết quả hiển thị rõ ràng và có thể thao tác được
→ MCP Apps xử lý các không gian làm việc phức tạp
Tò mò muốn tìm hiểu thêm?
Dưới đây là mọi thứ bạn cần để khám phá ADK 2.0, A2UI và nền tảng agent rộng lớn hơn của Google Cloud:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
Thật vinh dự khi được hợp tác với @googlecloud trong dự án này! 🤝
Nếu bạn muốn cập nhật những tin tức mới nhất về LLM, AI agent và quy trình làm việc, hãy theo dõi tôi @datachaz để nhận những chia sẻ hằng ngày.
