Kính Livis AI OpenClaw: mô hình chuyển giao từ kính sang phone agent

Báo cáo Livis OTA tháng 7 thực sự nói gì

Nếu bạn đang tìm kính Livis AI OpenClaw, câu trả lời ngắn là: theo bản tin ngày 25 tháng 7 năm 2026 về OTA Livis, bản cập nhật này thêm kết nối trực tiếp từ kính Livis đến terminal OpenClaw cá nhân. Cùng báo cáo cũng nói bản cập nhật bổ sung Xiaohongshu Agent, cải thiện tốc độ phản hồi hội thoại AI và yêu cầu ứng dụng Li Auto được cập nhật lên phiên bản 2.6.0 để dùng các chức năng mới nhất.

Đó là phần đã được báo cáo. Điều bài viết không nên kéo dài thành kết luận quá mức là bộ lệnh cụ thể, giao diện tiến trình, cách hiển thị kết quả, danh sách thiết bị hỗ trợ, phạm vi quốc gia hoặc khả năng điều khiển điện thoại. Nguồn được nêu là bản tin truyền thông, không phải tài liệu kỹ thuật chi tiết từ Livis mô tả mọi bước thiết lập hay mọi quyền hệ thống.

Vì vậy, cách đọc thực tế nhất là tách hai lớp. Lớp thứ nhất là tín hiệu sản phẩm: Livis được báo cáo có đường kết nối đến OpenClaw cá nhân. Lớp thứ hai là mô hình kiến trúc mà người dùng và đội ngũ sản phẩm nên áp dụng khi một thiết bị đeo khởi tạo tác vụ cho agent. Từ đây, câu hỏi đáng quan tâm không chỉ là “có kết nối không”, mà là “yêu cầu đi qua đâu, ai có quyền làm gì, và kết quả được xác nhận ở bề mặt nào”.

Vì sao kính AI là bề mặt điều khiển, không phải toàn bộ agent

Kính AI có lợi thế ở khoảnh khắc đầu vào. Người dùng có thể nói nhanh, nhìn một vật thể, nhận phản hồi ngắn hoặc ra lệnh khi tay đang bận. Điều đó khiến kính trở thành một bề mặt điều khiển rất tự nhiên cho tác nhân AI cá nhân điều khiển bằng giọng nói. Nhưng bề mặt điều khiển không đồng nghĩa với toàn bộ runtime agent, toàn bộ dữ liệu tài khoản hoặc toàn bộ quyền thao tác điện thoại.

Trang chính thức OpenClaw mô tả OpenClaw là open source và chạy trên máy của người dùng. Trang này cũng nêu các bề mặt khởi tạo yêu cầu như WhatsApp, Telegram hoặc các chat app khác, với ví dụ công việc liên quan đến inbox, email, calendar và check-in chuyến bay. Những điểm đó giúp hiểu khái niệm runtime cá nhân: yêu cầu có thể đi vào qua một bề mặt nhẹ, còn suy luận và thao tác có thể xảy ra ở máy của người dùng hoặc hệ thống được kết nối.

Với kính, cùng logic đó càng rõ. Kính có thể nghe lệnh “nhắc tôi gửi ảnh này cho nhóm sau cuộc họp” hoặc “ghi lại việc cần làm từ màn hình trước mặt”. Nhưng để biến lệnh thành tác vụ thật, hệ thống cần biết phần nào được nhận từ microphone, phần nào đến từ camera, phần nào được agent suy luận, phần nào cần tài khoản từ xa và phần nào phải chuyển sang điện thoại. Nếu gom tất cả thành một “kính làm agent”, ranh giới quyền sẽ mờ ngay từ đầu.

Kiến trúc chuyển giao từ kính sang agent rồi đến điện thoại

Một mô hình chuyển giao đáng tin cậy nên bắt đầu từ tác vụ ít rủi ro. Ví dụ: người dùng đeo kính nói “ghi chú lại rằng tôi cần trả lời email của Minh chiều nay”. Kính thu giọng nói và có thể gửi ý định đến runtime agent cá nhân. Runtime phân tích yêu cầu, xác định đây là ghi chú hoặc nhắc việc, rồi nếu cần thao tác Android, chuyển sang lớp phone agent được hỗ trợ để tạo mục nhắc hoặc mở màn hình phù hợp cho người dùng xác nhận.

Đây là mô hình kiến trúc, không phải tuyên bố rằng Livis, OpenClaw và một phone agent cụ thể hiện đã tích hợp trực tiếp. Mục tiêu là đặt đúng vai trò cho từng lớp để không chuyển quyền quá rộng. Nếu bạn muốn bức tranh tổng quát hơn về chuyển giao đa thiết bị, bài Vì sao AI agent đa thiết bị vẫn cần điện thoại giải thích vì sao điện thoại vẫn là nơi quan trọng để xác nhận, hiển thị trạng thái và xử lý hành động cá nhân.

Một thiết kế tốt không cần bắt kính hiển thị mọi chi tiết. Nó cần đảm bảo mỗi lớp tạo ra đầu ra có thể hiểu được cho lớp sau, đồng thời giữ một điểm quay lại rõ ràng khi thiếu dữ kiện, thiếu quyền hoặc phát hiện sai mục tiêu.

Tiến trình, xác nhận và kết quả nên xuất hiện ở đâu

Khi kính AI làm giao diện điều khiển tác nhân, phản hồi không nên chỉ có hai trạng thái: đã nghe và đã xong. Người dùng cần một nhịp trạng thái rõ hơn: đã nhận yêu cầu, đang xử lý, cần thông tin, cần xác nhận, đã hoàn tất, thất bại hoặc đã dừng. Báo cáo Livis tháng 7 không mô tả một giao thức đầy đủ cho tiến trình và kết quả, nên phần này nên được hiểu như tiêu chuẩn thiết kế cần có cho mọi chuyển giao từ thiết bị đeo sang agent.

Kính phù hợp với acknowledgement ngắn: “đã nhận yêu cầu” hoặc “cần mở điện thoại để xác nhận”. Điện thoại phù hợp hơn cho xác nhận giàu ngữ cảnh: người nhận tin nhắn, nội dung chuẩn bị gửi, lịch sẽ được tạo, app nào sẽ mở, hoặc quyền nào đang được yêu cầu. Terminal cá nhân hoặc dashboard phù hợp với tác vụ dài hơn như kiểm tra email, chuẩn bị tài liệu hoặc xử lý quy trình nền.

Điểm quyết định là hành động có tác động ra ngoài hay không. Với tác vụ đọc hoặc ghi chú cá nhân ít rủi ro, kính có thể đủ để báo trạng thái. Với gửi tin, thay đổi lịch, chia sẻ vị trí hoặc tác vụ liên quan tài khoản, kết quả cần được xem lại ở bề mặt có đủ màn hình và điểm xác nhận. Chuyển giao từ kính thông minh sang tác nhân điện thoại tốt là chuyển giao đúng trạng thái sang đúng bề mặt, không cố nhồi mọi thứ vào một câu thoại.

Ranh giới camera, microphone, tài khoản, terminal và quyền điện thoại

Khi một thiết bị đeo có camera và microphone trở thành bề mặt nhập lệnh cho agent, quyền riêng tư bắt đầu từ khoảnh khắc thu nhận. Người dùng nên biết lúc nào microphone đang lắng nghe, lúc nào camera được dùng làm ngữ cảnh, dữ liệu nào được gửi đi, và có thể dừng ở đâu. Những câu hỏi đó khác với quyền của terminal OpenClaw cá nhân, và cũng khác với quyền Android trên điện thoại.

hướng dẫn runtime permission của Android nêu nguyên tắc xin quyền trong ngữ cảnh khi tính năng cần quyền đó, đồng thời ứng dụng phải xử lý tình huống quyền bị từ chối. Áp dụng vào mô hình kính-to-agent-to-phone, một lệnh bắt đầu từ kính không tự cấp quyền liên hệ, tin nhắn, vị trí, calendar hay file trên điện thoại. Terminal cá nhân cũng không nên được hiểu là chìa khóa mở mọi quyền Android.

Ranh giới tài khoản cũng cần tách. Một tài khoản trên kính hoặc app điều khiển kính có thể dùng cho cài đặt thiết bị. Tài khoản OpenClaw hoặc terminal cá nhân có thể có quyền đọc email hoặc lịch nếu người dùng cấu hình. Điện thoại Android lại có quyền ứng dụng, permission hệ thống, khóa màn hình, app đích và tài khoản cá nhân khác. Một lần đồng ý ở lớp này không nên tự lan sang lớp khác.

Với OpenClaw, rủi ro vận hành rộng hơn nằm ở việc một agent cá nhân chạy trên máy người dùng có thể được nối với nhiều bề mặt và nhiều tài khoản. Để đi sâu vào phần triển khai và quyền của OpenClaw mà không lặp lại ở đây, bài Rủi ro bảo mật OpenClaw và cách nhìn an toàn hơn cho phone agent là ngữ cảnh tiếp theo phù hợp.

Cách dừng, thu hồi và khôi phục khi chuyển giao lỗi

Một handoff đáng tin không chỉ cần chạy được khi mọi thứ đúng. Nó phải có đường dừng khi kính nghe sai, runtime chọn sai tác vụ, terminal mất kết nối, điện thoại thiếu quyền hoặc app đích không phản hồi. Dừng, thu hồi và khôi phục nên tồn tại ở từng lớp, vì lỗi ở bề mặt nhập lệnh khác lỗi ở endpoint hoặc quyền Android.

1. Dừng ngay tại kính: người dùng cần lệnh hoặc thao tác hủy khi phát hiện kính nghe sai.
2. Timeout ở runtime: tác vụ không nên treo vô hạn nếu OpenClaw terminal hoặc dịch vụ đích không phản hồi.
3. Không đổi mục tiêu âm thầm: nếu người nhận, app hoặc tài khoản không khớp, hệ thống nên hỏi lại thay vì tự chọn gần đúng.
4. Thu hồi kết nối: người dùng cần cách ngắt bề mặt kính khỏi runtime cá nhân hoặc phone agent.
5. Khôi phục ở nơi giàu ngữ cảnh: lỗi phức tạp nên đưa về điện thoại hoặc dashboard, nơi người dùng nhìn đủ chi tiết.
6. Lưu dấu vết đủ dùng: nhật ký nên cho biết yêu cầu bắt đầu từ đâu, lớp nào đã xử lý và lớp nào đã dừng.

Kiểm thử ban đầu nên là tác vụ đọc hoặc ghi chú không có tác động bên ngoài. Sau đó mới thử tác vụ có app đích, và chỉ mở rộng khi hệ thống chứng minh được rằng nó dừng đúng, không tự tăng quyền và không tiếp tục ở kênh khác khi người dùng chưa hiểu.

FoneClaw trong vai trò lớp thao tác Android có quản trị

Trong mô hình này, FoneClaw có thể được hiểu như lớp thao tác Android có quản trị khi một yêu cầu đã cần chuyển từ ý định sang hành động trên điện thoại. Chúng tôi thiết kế FoneClaw là runtime phone agent Android: một mô hình tương thích được cấu hình để hiểu, suy luận và lập kế hoạch; FoneClaw gọi các công cụ Android được hỗ trợ, hiển thị kết quả, xử lý quyền theo ngữ cảnh và áp dụng điểm phê duyệt khi cần. Đây là mô tả phạm vi sản phẩm của FoneClaw, không phải tuyên bố tích hợp hiện có với Livis hoặc OpenClaw.

Theo dữ liệu phát hành FoneClaw, phiên bản 0.1.0 bổ sung tìm kiếm theo công cụ, kiểm soát bật tắt, approval overrides, hợp đồng công cụ an toàn hơn, permission recovery và xử lý lỗi tốt hơn. Các khả năng này hữu ích trong một handoff vì lớp điện thoại không chỉ nhận lệnh; nó phải kiểm tra công cụ nào được bật, quyền nào đang thiếu, hành động nào cần xác nhận và lỗi nên quay về đâu.

public tool catalog của FoneClaw tại thời điểm được ghi nhận có 118 built-in tools trong 11 nhóm với nhãn rủi ro và approval. Trong mô tả bền vững, chúng tôi dùng cách nói hơn 100 built-in tools, vì catalog sẽ tiếp tục thay đổi. Built-in tools và plugins cũng cần được hiểu khác nhau: công cụ tích hợp sẵn thuộc catalog runtime, còn plugin phải đi qua luồng đề xuất và kiểm soát riêng.

Trong trải nghiệm FoneClaw, voice là ưu tiên tương tác đầu tiên, sau đó mới đến nút và chạm. Điều này phù hợp với tình huống kính khởi tạo yêu cầu bằng giọng nói, nhưng bước Android vẫn cần bề mặt đủ rõ để xem kết quả và xác nhận. Nếu bạn muốn xem đầy đủ kiến trúc từ ý định đến hành động Android, bài Điều khiển điện thoại bằng AI agent trên Android trình bày chi tiết hơn về công cụ, quyền và kết quả hiển thị.

Checklist đánh giá kính AI có khả năng làm việc với agent

Khi đánh giá kính AI có khả năng kết nối agent, hãy bắt đầu bằng bằng chứng, không bắt đầu bằng tưởng tượng về trợ lý toàn năng. Câu hỏi đầu tiên là nguồn nào xác nhận kết nối, ngày nào, phạm vi nào và cần phiên bản app nào. Với Livis, phần nguồn hiện có là báo cáo ngày 25 tháng 7 về kết nối OpenClaw cá nhân, Xiaohongshu Agent, cải thiện tốc độ hội thoại AI và Li Auto app 2.6.0.

1. Tách sự thật và mô hình: ghi rõ tính năng nào được báo cáo, phần nào chỉ là kiến trúc nên có.
2. Xác định nơi tác vụ chạy: trên kính, terminal cá nhân, điện thoại hay dịch vụ đám mây.
3. Kiểm tra bề mặt kết quả: kính, điện thoại hoặc dashboard có đủ thông tin để người dùng quyết định không.
4. Giới hạn quyền ban đầu: bắt đầu từ lệnh đọc hoặc ghi chú, chưa chạm hành động gửi, chia sẻ hoặc thay đổi cài đặt.
5. Kiểm thử điểm dừng: thử hủy, sai người nhận, mất mạng, thiếu quyền và app không hỗ trợ.
6. Kiểm tra thu hồi: người dùng có thể ngắt kính khỏi runtime, tắt công cụ hoặc dừng quyền Android không.

Kính AI không thay thế điện thoại; nó có thể làm cho khoảnh khắc khởi tạo tác vụ tự nhiên hơn. Với các so sánh sản phẩm kính AI và phone agent, bài Meta Ray-Ban AI so với FoneClaw: kính AI hay agent AI trên điện thoại? giúp đặt bề mặt đeo và lớp hành động Android vào cùng một khung đánh giá mà không biến bài này thành bảng xếp hạng thiết bị.

Con đường thực tế nhất là hẹp và quan sát được: dùng kính để gửi yêu cầu rõ, để runtime cá nhân lập kế hoạch, chuyển sang điện thoại khi cần hành động Android, hiển thị bước quan trọng, rồi chỉ hoàn tất khi người dùng có đủ ngữ cảnh để đồng ý hoặc dừng.