Google Gemini Spark: Runtime cho agent luôn hoạt động

Google Gemini Spark là AI agent cá nhân luôn hoạt động 24/7 của Google: một trợ lý chạy liên tục, có thể tiếp tục công việc nhiều bước sau khi người dùng đã rời phiên làm việc. Thông báo tại Australia ngày 29 tháng 7 năm 2026 chỉ mở rộng phạm vi khu vực, không phải một lần ra mắt toàn cầu mới. Google lần đầu ra mắt Spark tại Google I/O 2026 vào tháng 5 năm 2026.

Với đội kỹ thuật, câu hỏi khó không phải là viết prompt cho nó thế nào, mà là làm sao tin tưởng một runtime có quyền truy cập liên tục vào hộp thư, trình duyệt, công cụ, API và dữ liệu vận hành. Tại Van Data Team, chúng tôi bắt đầu bằng việc lập bản đồ khâu tiếp nhận tác vụ, các quyết định, phân quyền, kiểu lỗi và cổng kiểm duyệt trước khi chọn lớp orchestration. Đó là cách thiết kế workflow AI agent cho production của chúng tôi biến khả năng tự chủ thành một mô hình vận hành thay vì chỉ là bản demo.

Bài viết tách biệt các dữ kiện Google đã công bố với phân tích của Van Data Team. Nội dung cung cấp cho các lãnh đạo kỹ thuật một kiến trúc triển khai, mô hình phân quyền, artifact điều kiện dừng theo AgentOps, hướng dẫn chọn framework và cổng kiểm tra mức sẵn sàng cho một dự án thí điểm có kiểm soát.

Bài học chính

Gemini Spark quan trọng vì nó đưa công việc AI từ một cuộc hội thoại có giới hạn sang một runtime chạy liên tục và biết dùng công cụ.

• Thông báo tại Australia là đợt mở rộng khu vực sau lần giới thiệu Spark tại I/O trước đó, không phải lần ra mắt đầu tiên.
• Spark tiếp tục chạy trên hạ tầng cloud được quản lý mà không cần thiết bị của người dùng phải luôn mở.
• Gmail, Chrome và MCP khiến công cụ trở thành một phần của luồng thực thi và của ranh giới bảo mật.
• Để tin dùng trên production, cần có trace, telemetry về token và chi phí, nguồn gốc dữ liệu, điều kiện dừng và escalation cho con người.

Đợt rollout tại Australia nối tiếp lần ra mắt trước đó

Thông báo tại Australia của Google mở rộng Gemini Spark ra ngoài bản phát hành đầu tiên tại Mỹ; đây không phải một sản phẩm riêng dành cho Australia.

Dữ kiện đã công bố. Những gì đã được xác nhận về sản phẩm khá ngắn gọn:

"AI agent cá nhân luôn hoạt động 24/7"

Phân tích của Van Data Team. Mô tả ngắn gọn đó làm thay đổi câu hỏi cho production. Một chatbot chỉ có thể sai trong phạm vi một câu trả lời. Một agent chạy liên tục có thể mang một giả định yếu sang các bước sau, gọi thêm công cụ khác và tạo ra tác động phụ khi người dùng đã thôi theo dõi.

Google Gemini Spark thay đổi đơn vị công việc như thế nào

Hình minh họa sau tóm tắt luồng thực thi luôn bật có giám sát:

Google Gemini Spark thay đổi đơn vị mà kỹ sư phải giám sát: từ một câu trả lời sang cả một luồng thực thi.

Dữ kiện đã công bố. Spark nhận tác vụ, suy luận dựa trên ngữ cảnh, lập kế hoạch nhiều bước và tương tác với Gmail, Chrome cùng các công cụ đã kết nối trong khi runtime vẫn đang chạy.

Phân tích của Van Data Team. Bảng dưới đây là so sánh mang tính khái niệm của chúng tôi, không phải đặc tả chính thức của Google.

Có thể hình dung trình tự như sau, bắt đầu từ việc tiếp nhận một tác vụ được ủy quyền. Agent thu thập ngữ cảnh, đề xuất kế hoạch, gọi một công cụ được phép, đánh giá kết quả quan sát, chọn hành động tiếp theo, rồi hoàn thành hoặc escalate. Đây là mô hình vận hành dựa trên các khả năng đã được công bố, không phải khẳng định về cơ chế nội bộ chưa được Google tiết lộ.

Ví dụ giả định về một workflow có giới hạn. Maya, trưởng nhóm vận hành, gửi email một yêu cầu nghiên cứu đã được ủy quyền tới địa chỉ riêng của Spark. Spark dùng Chrome để thu thập thông tin công khai và soạn một bản memo, nhưng chính sách chặn mọi thao tác đăng tải hay gửi tin nhắn ra bên ngoài. Trace ghi lại yêu cầu, nguồn, các lần chỉnh sửa kế hoạch, thao tác trên trình duyệt và kết quả. Người rà soát kiểm tra nguồn gốc và phạm vi trước khi chấp nhận đầu ra, theo cùng logic dựa trên rủi ro được dùng trong AI agent có con người kiểm duyệt.

MCP giúp tích hợp dễ hơn, nhưng không tự động an toàn hơn

MCP cho agent luôn hoạt động một giao diện công cụ chung, nhưng mọi năng lực được kết nối vẫn cần một hợp đồng hẹp và ranh giới phê duyệt rõ ràng.

Dữ kiện đã công bố. Spark hỗ trợ MCP đầy đủ. Lộ trình tích hợp Google đưa ra bắt đầu với Canva, OpenTable và Instacart, sau đó mở rộng qua MCP sang GitHub, Notion, Slack và bất kỳ dịch vụ nào có server tương thích.

Phân tích của Van Data Team. Hãy coi MCP server là một API production có phân quyền, không phải một ô để tích cho xong. Định nghĩa input có kiểu dữ liệu rõ ràng, validate output, ghi log mọi lời gọi connector, tách quyền đọc khỏi quyền ghi và từ chối các yêu cầu nằm ngoài tập tài nguyên của workflow.

Các thao tác ghi có hệ quả phải được con người phê duyệt cho đến khi đội ngũ đã kiểm chứng chính sách cho nhóm hành động đó. Đây là khuyến nghị của Van Data Team, không phải khẳng định rằng các cơ chế kiểm soát này đã có sẵn trong Spark.

Niềm tin trên production đến từ trace và điều kiện dừng

Một agent luôn hoạt động chỉ sẵn sàng cho production khi người vận hành có thể dựng lại quá trình thực thi của nó và dừng nó lại trước khi sự không chắc chắn biến thành tác động phụ.

Phân tích của Van Data Team. Chỉ có câu trả lời cuối cùng thì không đủ để debug. Hãy thu thập đủ bằng chứng để giải thích vì sao runtime chọn một công cụ, nó đã đọc dữ liệu gì, retry ở đâu, tiêu tốn bao nhiêu và kết quả có vượt qua quy tắc nghiệm thu hay không.

Giá, độ trễ, lượng token tiêu thụ, tỷ lệ hoàn thành tác vụ và tỷ lệ escalation cần được đo từ telemetry chính thức của sản phẩm. Các nguồn được dẫn chưa đưa ra những giá trị đó, nên chúng thuộc về kế hoạch đánh giá chứ không phải tuyên bố về sản phẩm.

Sai lầm chúng tôi thường thấy là coi điều kiện dừng như phần xử lý lỗi bổ sung sau khi ra mắt. Thực ra chúng là một phần của hợp đồng runtime. Playbook AgentOps cho AI agent trên production của Van Data Team đi sâu hơn vào tracing, escalation và cách đặt điểm kiểm duyệt.

Quyết định đáng tin cậy của agent bắt đầu từ dữ liệu đáng tin cậy

Suy luận liên tục không sửa được dữ liệu cũ, thiếu hoặc quản trị kém; nó còn có thể khuếch đại những khiếm khuyết đó qua các hành động về sau.

Phân tích của Van Data Team. Airflow, dbt, Kafka, data warehouse và retrieval index là các nền tảng data engineering liên quan, không phải thành phần nội bộ đã được xác nhận của Spark. Airflow có thể lập lịch và khôi phục pipeline, dbt có thể mô hình hóa và kiểm thử các bộ dữ liệu có quản trị, Kafka có thể cung cấp đầu vào theo sự kiện, còn data warehouse có thể cung cấp các view được kiểm soát. Retrieval index nên được vận hành như những sản phẩm dữ liệu dành cho agent, luôn kèm thông tin nguồn gốc và độ mới.

Ví dụ giả định về lỗi độ mới dữ liệu. Một workflow mua hàng đọc data mart tồn kho trong khi job nạp dữ liệu phía nguồn đã bị treo. Suy luận của agent có thể vẫn nhất quán về logic, nhưng khuyến nghị lại sai về mặt vận hành. Cách sửa là một hợp đồng về độ mới ở phía nguồn và một điều kiện dừng trong runtime, chứ không phải một prompt dài hơn.

Các đội đang cân nhắc mức tự chủ cho agent nên kết hợp kỹ thuật pipeline dữ liệu bền vững với hiện đại hóa nền tảng dữ liệu theo giai đoạn để sẵn sàng cho AI. Một buổi đánh giá mức sẵn sàng hữu ích sẽ cho ra bản đồ workflow, bản đồ nguồn và lineage, hợp đồng về độ mới và chất lượng dữ liệu, ma trận phân quyền, bộ đánh giá và kế hoạch triển khai có kiểm soát.

Chọn orchestration managed hay tự xây dựa trên trách nhiệm vận hành

Spark và các framework agent tự xây giải quyết những bài toán trách nhiệm khác nhau, nên lựa chọn đúng phụ thuộc vào mức kiểm soát, độ phù hợp khi tích hợp và gánh nặng vận hành mà đội ngũ có thể đảm đương.

Phân tích của Van Data Team. Chưa có benchmark so sánh nào được công bố, nên chưa có bằng chứng nào cho thấy phương án nào vượt trội về hiệu năng.

Dùng runtime managed khi hệ sinh thái, mô hình truy cập và công cụ giám sát của nó phù hợp với workflow. Chọn orchestration tự xây khi yêu cầu về nơi lưu trữ dữ liệu, hành vi của connector, đánh giá hoặc khôi phục cần được kiểm soát sâu hơn. Ưu tiên tự động hóa xác định (deterministic) khi tác vụ dễ dự đoán và không cần lập kế hoạch theo ngữ cảnh.

Cổng kiểm tra mức sẵn sàng cho production

Một dự án thí điểm có kiểm soát phải vượt qua mọi cổng áp dụng trước khi agent được cấp quyền rộng hơn.

• [ ] Workflow có người phụ trách cụ thể và kết quả đầu ra có giới hạn rõ ràng.
• [ ] Các công cụ, nguồn dữ liệu và tác động phụ được phép đều đã được ghi lại.
• [ ] Người gửi tác vụ được xác thực, và quyền của connector tuân theo nguyên tắc đặc quyền tối thiểu.
• [ ] Chất lượng dữ liệu, lineage, độ mới và cam kết dịch vụ của pipeline đều được xác định rõ.
• [ ] Toàn bộ luồng thực thi có thể trace được mà không làm lộ secret.
• [ ] Ngân sách token, chi phí, độ trễ, retry và tình trạng không tiến triển đều có quy tắc dừng.
• [ ] Các hành động ra bên ngoài có hệ quả đều có cổng phê duyệt của con người.
• [ ] Bộ đánh giá bao gồm các trường hợp bình thường, mơ hồ, dữ liệu cũ, lỗi công cụ và tấn công đối kháng.
• [ ] Tiêu chí nghiệm thu kết quả, người phụ trách sự cố, rollback và hành động bù trừ đều đã được xác định.

Ngân sách vận hành

Dữ kiện đã công bố. Google mô tả Google Gemini Spark là một agent chạy liên tục, luôn hoạt động trên các máy ảo Google Cloud chuyên dụng. Kiến trúc đó giữ cho workflow tiếp tục chạy mà không cần thiết bị của người dùng phải mở, nhưng riêng thông báo này chưa cho biết chi phí vận hành của một workload production.

Phân tích của Van Data Team. Hãy so sánh Spark với bất kỳ runtime thay thế nào dựa trên số kết quả được duyệt, chứ không phải đơn giá token của nhà cung cấp. Với mỗi workflow đại diện, hãy ghi lại:

• độ trễ đầu cuối và lượng token đã tiêu thụ;
• số lần retry, lỗi khi gọi công cụ và công sức khôi phục;
• số phút người rà soát cần bỏ ra để phê duyệt;
• kết quả đánh giá tính đúng đắn, tuân thủ chính sách và hoàn thành nhiệm vụ;
• tổng chi phí runtime, mô hình, công cụ, dữ liệu và kiểm duyệt của con người.

Tính chi phí cho mỗi đầu ra được chấp nhận bằng cách lấy tổng chi phí của workflow, bao gồm cả các lần chạy thất bại và công khôi phục, chia cho số kết quả vượt qua cổng phê duyệt. Một mô hình rẻ hơn vẫn có thể khiến cả hệ thống đắt hơn nếu nó cần gọi lặp lại nhiều lần, tạo ra luồng thực thi dài hoặc đẩy việc kiểm chứng sang cho kỹ sư.

Đặt ngân sách cho token, retry, thời gian chạy và số lời gọi công cụ trước khi thí điểm. Dừng hoặc escalate khi chạm giới hạn, khi bài đánh giá thất bại hoặc khi bước khôi phục sẽ lặp lại đúng hành động cũ. Việc phê duyệt cho production cần dựa trên kết quả đánh giá ổn định và một luồng xử lý lỗi biết giữ trạng thái, ghi lại tác động phụ và cho phép con người tiếp quản an toàn.

Kết luận: chạy liên tục đòi hỏi chuẩn vận hành cao hơn

Google Gemini Spark biến bước chuyển từ chat theo phiên sang thực thi liên tục thành hiện thực. Đợt rollout tại Australia mở rộng quyền truy cập vào một runtime được xây cho các tác vụ kéo dài, thực thi trên cloud, lập kế hoạch theo ngữ cảnh và các công cụ đã kết nối. Những khả năng này làm tăng tính hữu dụng, nhưng cũng nới rộng ranh giới về bảo mật, dữ liệu và vận hành.

Hãy bắt đầu với một workflow có giới hạn, thực sự hưởng lợi từ việc lập kế hoạch và dùng công cụ. Gắn instrumentation cho toàn bộ luồng, thu hẹp mọi quyền, đính kèm nguồn gốc và độ mới vào ngữ cảnh, và dừng lại trước khi sự không chắc chắn dẫn tới một hành động có hệ quả.

Nếu bạn muốn thử Google Gemini Spark hoặc một runtime tự xây trên workflow thực tế, hãy xác định phạm vi một dự án thí điểm agent có kiểm soát. Đầu ra nên gồm ranh giới tác vụ, bản đồ tín hiệu và dữ liệu, ma trận phân quyền, đặc tả observability và điều kiện dừng, kế hoạch đánh giá và phạm vi triển khai.