Kiến trúc MCP không trạng thái cho quy trình phone agent Android có trạng thái
Playbook kiến trúc về MCP 2026-07-28, máy chủ MCP không trạng thái và cách phone agent Android vẫn cần trạng thái tác vụ, phê duyệt, idempotency và phục hồi.
- MCP 2026-07-28 đưa lõi giao thức theo hướng không trạng thái: yêu cầu tự mô tả, định tuyến linh hoạt tới nhiều instance và dùng extensions cho các nhu cầu phức tạp như Tasks.
- MCP stateless và workflow agent stateful bổ sung cho nhau: giao thức connector có thể không giữ phiên ẩn, trong khi ứng dụng agent vẫn cần giữ trạng thái hội thoại, tác vụ, thiết bị, phê duyệt, xác thực và audit.
- Từ kinh nghiệm xây FoneClaw, trạng thái tác vụ phone agent nên thuộc về host hoặc lớp ứng dụng chịu trách nhiệm với người dùng, còn MCP server chỉ nhận tham chiếu, metadata và handle rõ ràng cho từng lời gọi.
- Với workflow Android như SMS, Không làm phiền, cuộc gọi, điều hướng hoặc cài đặt, độ tin cậy đến từ idempotency, xác minh trạng thái thiết bị, phê duyệt hiển thị, phục hồi quyền và nhật ký kết quả.
MCP 2026-07-28 thay đổi gì
Điểm quan trọng của bản đặc tả Model Context Protocol ngày 28 tháng 7 năm 2026 là MCP chuyển lõi giao thức theo hướng stateless. Một yêu cầu MCP cần tự mô tả đủ metadata, năng lực và thông tin định tuyến để bất kỳ instance tương thích nào của server có thể xử lý. Điều này giúp triển khai kiểu load balancing, serverless, khởi động lại instance và phân phối yêu cầu linh hoạt hơn so với mô hình phụ thuộc phiên giao thức ẩn.
SEP-2575 về MCP stateless mô tả việc bỏ bắt buộc handshake khởi tạo và thay giả định theo phiên bằng metadata ở từng yêu cầu. Cách làm này rất hợp với connector hiện đại: client nói rõ mình là ai, gọi năng lực nào, đang dùng phiên bản giao thức nào, cần loại phản hồi nào, và có tham chiếu trạng thái nào nếu workflow dài hơn một lượt.
Từ góc nhìn FoneClaw, bài học chính là: stateless ở lớp giao thức giúp server connector dễ triển khai hơn, còn workflow agent vẫn cần trạng thái ở lớp ứng dụng. Phone agent không thể vận hành chỉ bằng các lời gọi rời rạc khi nó phải nhớ người dùng đang ở bước nào, quyền nào đã có, phê duyệt nào gắn với hành động nào, app Android đang ở trạng thái nào và kết quả nào đã được xác minh. Bài Agentic Resource Discovery: ai-catalog.json, xác minh và quyền cho phone agent là phần đọc tiếp tự nhiên nếu bạn muốn đào sâu cách agent tìm và tin cậy năng lực trước khi gọi.
Vòng đời một yêu cầu MCP không trạng thái hoạt động thế nào
Trong vòng đời stateless, mỗi yêu cầu mang theo phần thông tin mà trước đây nhiều hệ thống hay giấu trong phiên. Client gửi metadata về protocol version, identity liên quan, năng lực mong muốn, headers định tuyến, tham chiếu trạng thái nếu có và thông tin để server quyết định có xử lý được hay không. Server phản hồi bằng kết quả, lỗi, yêu cầu thêm thông tin hoặc handle cho công việc tiếp diễn.
Discovery vẫn có vai trò, nhưng nó cũng đi theo hướng rõ ràng hơn. Danh sách công cụ, tài nguyên hoặc capability có thể được cache khi phù hợp; yêu cầu thực thi sau đó mang đủ thông tin để một instance khác hiểu cùng hợp đồng. Điều này quan trọng với hạ tầng: một máy chủ MCP không trạng thái có thể được đặt sau load balancer, chạy theo scale-out, hoặc được thay thế mà không kéo theo ký ức phiên giao thức nằm trong process cũ.
Khi workflow cần kéo dài, trạng thái được đưa ra ngoài dưới dạng tham chiếu rõ. SEP-2567 về explicit state handles mô tả cách thay trạng thái phiên ngầm bằng handle do server cấp và được truyền qua các lời gọi sau. Với phone agent, handle là cầu nối kỹ thuật hữu ích, còn ý nghĩa tác vụ vẫn nằm ở host: handle này thuộc tác vụ nào, người dùng nào, phê duyệt nào, thiết bị nào và còn hiệu lực đến khi nào. Cách thiết kế này giữ giao thức gọn, đồng thời buộc ứng dụng agent mô tả trạng thái một cách có trách nhiệm.
Sáu loại trạng thái mà phone agent phải sở hữu
Khi xây FoneClaw, chúng tôi thấy phone agent cần nhiều loại trạng thái khác nhau. Gộp tất cả vào một “session” duy nhất làm hệ thống khó phục hồi và khó kiểm toán. Tách chúng thành các sổ trạng thái giúp thiết kế rõ hơn: cái nào thuộc hội thoại, cái nào thuộc tác vụ, cái nào thuộc thiết bị, cái nào thuộc phê duyệt, cái nào thuộc xác thực và cái nào thuộc audit.
| Loại trạng thái | Chủ sở hữu phù hợp | Vai trò trong workflow Android |
|---|---|---|
| Hội thoại | Agent host | Giữ mục tiêu người dùng, câu hỏi làm rõ, lựa chọn đã nói và ngữ cảnh ngôn ngữ. |
| Tác vụ | Agent host hoặc task store của ứng dụng | Ghi bước hiện tại: đang lập kế hoạch, chờ quyền, chờ phê duyệt, đang chạy, đã hoàn tất hoặc cần phục hồi. |
| Thiết bị | Phone host đọc lại từ Android | Kiểm tra app đang mở, quyền hiện có, màn hình hiện tại, SIM, nút khả dụng và trạng thái cài đặt. |
| Phê duyệt | Agent host gắn với người dùng và tác vụ | Nối một quyết định của người dùng với hành động cụ thể, dữ liệu cụ thể và thời điểm cụ thể. |
| Xác thực và ủy quyền | Hệ thống identity hoặc credential store | Quyết định ai được gọi năng lực nào; tách khỏi việc người dùng có đồng ý cho một hành động cụ thể hay không. |
| Audit và kết quả | Agent host hoặc audit store | Lưu yêu cầu, công cụ đã gọi, kết quả đã xác minh, lỗi, phục hồi và idempotency key. |
Điểm thiết kế quan trọng là phê duyệt và xác thực là hai trạng thái khác nhau. Một connector có thể xác thực rằng client được phép gọi công cụ, nhưng người dùng vẫn cần phê duyệt gửi SMS, đổi Không làm phiền hoặc thực hiện một thao tác có tác động. Với thiết kế identity và audit sâu hơn, bài Danh tính tác nhân AI: quyền, phê duyệt công cụ và nhật ký kiểm toán giải thích cách chúng tôi nhìn vai trò, quyền và hồ sơ hành động trong phone agent.
MCP Tasks, MRTR, elicitation và phê duyệt
Bản MCP 2026-07-28 đưa Tasks vào khuôn khổ extension chính thức, cùng các cơ chế như MRTR, header routing, danh sách có thể cache, authorization hardening và extensions framework. Với workflow dài, Tasks cho phép công việc có handle và trạng thái riêng thay vì kéo dài một request đồng bộ. Điều này hợp với phone agent: một thao tác có thể bắt đầu từ ý định, chờ quyền, đợi người dùng chọn, rồi tiếp tục sau khi thiết bị đổi trạng thái.
MRTR và elicitation giúp server hoặc công cụ yêu cầu thêm thông tin khi đầu vào chưa đủ. Ví dụ, tác vụ gửi SMS cần người nhận rõ, nội dung đầy đủ và app mặc định khả dụng. Nếu thiếu người nhận hoặc có nhiều người trùng tên, workflow cần hỏi lại. Nếu quyền thiếu, workflow cần chuyển sang phục hồi quyền. Nếu hành động có hệ quả, phê duyệt của người dùng cần được ghi vào sổ phê duyệt của host, kèm dữ liệu, hành động và thời hạn hiệu lực.
Task handle là tham chiếu kỹ thuật để tiếp tục công việc; phê duyệt là quyết định của người dùng cho một hành động cụ thể. Khi hai thứ này được tách rõ, hệ thống có thể scale connector mà vẫn giữ trách nhiệm ứng dụng. Một request sau có thể mang task handle để tiếp tục, idempotency key để tránh lặp tác động, và approval id để chứng minh người dùng đã đồng ý đúng bước. Đây là chỗ MCP stateless và workflow agent stateful phối hợp thay vì triệt tiêu nhau.
Một workflow Android có trạng thái chạy trên MCP stateless
Hãy lấy ví dụ bật Không làm phiền trong 45 phút khi người dùng đang chuẩn bị họp. Người dùng nói với FoneClaw: “Bật Không làm phiền đến 3 giờ 15.” Agent host tạo tác vụ với mục tiêu, thời hạn, thiết bị, trạng thái ban đầu và idempotency key. Nếu workflow dùng connector theo phong cách MCP stateless trong tương lai, lời gọi tới server sẽ mang metadata tự mô tả, capability cần dùng và tham chiếu tác vụ, thay vì dựa vào một phiên giao thức ngầm.
Bước tiếp theo là đọc lại trạng thái thiết bị. Phone host cần biết quyền cài đặt có sẵn không, chế độ Không làm phiền hiện tại là gì, thời gian kết thúc có hợp lệ không và người dùng có cần phê duyệt không. Nếu quyền thiếu, tác vụ chuyển sang trạng thái phục hồi quyền. FoneClaw hiện đã đưa phục hồi quyền và liên tục tác vụ trên cùng điện thoại vào nền trải nghiệm hiện tại; người dùng có thể thử bản hiện tại từ trang tải FoneClaw.
Khi điều kiện đã rõ, màn hình hiển thị đề xuất: bật Không làm phiền đến 3 giờ 15, kèm kết quả dự kiến. Người dùng phê duyệt. Host lưu approval record gắn với tác vụ, hành động và thời hạn. Connector hoặc công cụ thực thi nhận idempotency key để một retry mạng không tạo tác động lặp. Sau khi thực thi, host đọc lại trạng thái Android để xác minh rằng chế độ đã đổi đúng. Nếu kết quả chưa khớp, tác vụ chuyển sang phục hồi: thử đọc lại trạng thái, hướng dẫn người dùng cấp quyền, hoặc đưa họ tới màn hình cài đặt.
Luồng SMS cũng giống vậy nhưng nhiều biến hơn: người nhận, nội dung, app mặc định, nút gửi, hai SIM và tệp đính kèm. Bài Trợ lý AI nổi Android với ngữ cảnh màn hình hiện tại giải thích cách ngữ cảnh màn hình do người dùng kích hoạt giúp phone host hiểu nơi tác vụ đang diễn ra. Với cuộc gọi, phần chọn giữa MCP connector và trình quay số bản địa được tách sâu hơn trong Tác nhân AI gọi điện thoại: MCP hay trình quay số Android?.
Mở rộng máy chủ MCP mà vẫn giữ độ tin cậy tác vụ điện thoại
Stateless transport đem lại lợi ích hạ tầng rõ ràng. Máy chủ MCP có thể chạy nhiều instance, nhận request qua round-robin, khởi động lại sau lỗi hoặc mở rộng theo tải mà không cần mang theo phiên giao thức trong bộ nhớ process. Bản MCP Go SDK v1.7.0 là một ví dụ SDK chính thức cho lifecycle 2026-07-28, với metadata theo request, discovery và đường tương thích cho phiên bản cũ.
Độ tin cậy của phone-task lại nằm ở lớp ứng dụng. Retry chỉ an toàn khi hành động được phân loại. Đọc trạng thái thiết bị có thể retry dễ hơn; gửi SMS, đổi cài đặt hoặc gọi điện cần idempotency, kiểm tra kết quả và giới hạn retry. Nếu một request bị timeout sau khi công cụ đã đổi trạng thái, host cần xác minh trước khi chạy lại. Nếu request thất bại trước khi hành động bắt đầu, host có thể thử lại với cùng idempotency key. Nếu trạng thái thiết bị thay đổi trong lúc chờ, tác vụ cần lập kế hoạch lại.
Correlation và audit là phần giữ hệ thống có thể vận hành. Mỗi task nên có task id, request id, idempotency key, device snapshot, approval record, tool result và verification result. Khi có lỗi, đội kỹ thuật biết request nào đã tới server nào, công cụ nào đã được gọi và Android trả về trạng thái nào. Với workflow từ ghi âm họp sang hành động, bài MCP máy ghi âm AI: từ ghi chú họp đến thao tác điện thoại là ví dụ gần với cách trạng thái nội dung và hành động cần được nối lại.
Ranh giới bảo mật và checklist chuyển đổi
MCP 2026-07-28 cũng nhấn mạnh authorization hardening. Với phone agent, xác thực trả lời câu hỏi “client hoặc connector này có quyền gọi năng lực nào”, còn phê duyệt trả lời câu hỏi “người dùng đã đồng ý cho hành động cụ thể này chưa”. Hai lớp này cần cùng tồn tại. Một task handle giúp tiếp tục công việc; authorization quyết định quyền truy cập; approval quyết định tác động người dùng đã xem và chấp nhận.
Đường chuyển đổi nên đi theo từng lớp. Trước hết, hãy làm cho request tự mô tả bằng metadata, capability, version và correlation id. Tiếp theo, đưa trạng thái ứng dụng ra task store hoặc host store thay vì giấu trong process server. Sau đó thêm explicit state handles cho workflow dài, idempotency key cho hành động có tác động, verification step cho trạng thái Android và audit event cho mọi kết quả. Với client cũ, triển khai cần kiểm tra version và giữ đường tương thích theo SDK hoặc server đang dùng.
Checklist của chúng tôi cho một connector tương lai rất cụ thể:
- Yêu cầu tự mô tả đủ identity, capability, version và context reference.
- Trạng thái hội thoại, tác vụ, thiết bị, phê duyệt, xác thực và audit có chủ sở hữu rõ.
- Hành động có tác động dùng idempotency key và xác minh trạng thái sau khi chạy.
- Task handle có thời hạn, phạm vi và cơ chế hủy.
- Phê duyệt hiển thị dữ liệu, mục tiêu, hành động và kết quả dự kiến.
- Thiếu quyền chuyển sang phục hồi quyền thay vì tạo thành kết quả mơ hồ.
- Legacy client được nhận diện bằng version và nâng cấp theo từng capability.
FoneClaw hiện dùng các khả năng hiện có như bằng chứng về host-side state: trợ lý nổi, liên tục tác vụ trên cùng điện thoại, phục hồi quyền và quick actions. Trang tính năng FoneClaw trình bày các nhóm workflow Android hiện có. Khi chúng tôi đánh giá một connector hoặc protocol mới cho phone agent, tiêu chí không chỉ là gọi được công cụ, mà là liệu tác vụ có giữ được trạng thái, quyền, phê duyệt, xác minh, audit và phục hồi đúng cách hay không.