Method and apparatus for persisting state of agent in cloud phone and electronic device

Abstract

This application discloses a method, apparatus, and electronic device for persisting the state of an intelligent agent in a cloud phone, relating to the field of computer technology, particularly to artificial intelligence fields such as deep learning, large models, intelligent agents, and cloud platforms. The specific implementation scheme is as follows: obtaining a file system mount request corresponding to the target user; wherein the file system mount request includes the user identifier of the target user; determining the metadata address of the network file system, and mounting the network file system to the target mount point of the target cloud phone's content container according to the metadata address; determining the intelligent agent state storage directory of the target user in the mounted network file system according to the user identifier; wherein the intelligent agent state storage directory is used to persistently store the state data generated during the interaction between the intelligent agent and the target user in the storage container; and setting the state directory environment variable associated with the intelligent agent to the intelligent agent state storage directory.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to the fields of artificial intelligence such as deep learning, large models, intelligent agents, and cloud platforms. Specifically, it relates to a method, device, and electronic device for persisting the state of an intelligent agent in a cloud phone. Background Technology

[0002] Cloud phones are a new type of mobile terminal service based on cloud computing and virtualization technologies. Their core is to run a complete mobile phone operating system on a server in a data center, forming a virtual mobile device instance that can be remotely accessed and run independently. Summary of the Invention

[0003] This application provides a method, apparatus, and electronic device for persisting the state of an intelligent agent in a cloud phone. The specific solution is as follows:

[0004] According to one aspect of this application, a method for persisting the state of an intelligent agent in a cloud phone is provided, comprising: Obtain the file system mount request corresponding to the target user; wherein, the file system mount request includes the user identifier of the target user; Determine the metadata address of the network file system, and mount the network file system to the target mount point of the target cloud phone's content device based on the metadata address; Based on the user identifier, determine the target user's agent state storage directory in the mounted network file system; the agent state storage directory is used to persistently store the state data generated by the agent in the storage container during the interaction with the target user; Set the state directory environment variable associated with the agent to the agent's state storage directory.

[0005] According to another aspect of this application, a device for persisting the state of an intelligent agent in a cloud phone is provided, comprising: The acquisition module is used to acquire the file system mount request corresponding to the target user; wherein, the file system mount request includes the user identifier of the target user; The first mounting module is used to determine the metadata address of the network file system and mount the network file system to the target mount point of the target cloud phone's content device according to the metadata address. The determination module is used to determine the target user's agent state storage directory in the mounted network file system based on the user identifier; wherein, the agent state storage directory is used to persistently store the state data generated by the agent in the storage container during the interaction with the target user; The configuration module is used to set the state directory environment variable associated with the agent to the agent's state storage directory.

[0006] According to another aspect of this application, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in the above embodiments.

[0007] According to another aspect of this application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to perform the method described in the above embodiments.

[0008] According to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein: Figure 1 A flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, provided as another embodiment of this application; Figure 3 This is a schematic diagram of a storage-compute separation architecture provided in an embodiment of this application; Figure 4 A schematic diagram illustrating a cloud mobile device migration data recovery method provided in an embodiment of this application; Figure 5 A flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, provided as another embodiment of this application; Figure 6 A schematic diagram illustrating a multi-level degradation disaster recovery method provided in this application embodiment; Figure 7 A schematic diagram of the structure of a persistent state device for an intelligent agent in a cloud phone provided in an embodiment of this application; Figure 8 This is a block diagram of an electronic device used to implement the method for persisting the state of an intelligent agent in a cloud phone according to the embodiments of this application. Detailed Implementation

[0011] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] It should be noted that the acquisition, storage, use, and processing of data in this application comply with the relevant provisions of national laws and regulations and do not violate public order and good morals.

[0013] The following description, with reference to the accompanying drawings, outlines a method, apparatus, electronic device, and storage medium for persisting the state of an intelligent agent in a cloud phone according to embodiments of this application.

[0014] With the rapid development of artificial intelligence technology, intelligent agents are gradually evolving from short-term task execution tools into long-term digital assistants capable of continuously learning, remembering user preferences, and providing personalized services. However, due to limitations in the computing resources, battery life, operating environment stability, and data persistence of terminal devices, intelligent agents struggle to achieve truly long-term, continuous, and reliable operation on ordinary mobile or edge devices.

[0015] As a complete operating system environment that runs in the cloud, cloud phones have an independent operating system, persistent operation capability, stable network connection and scalable computing resources, and can serve as a long-term operating platform for intelligent agents.

[0016] However, in scenarios such as cloud phone expiration and destruction, fault recovery, and expansion and migration, the state data of intelligent agents face the risk of irreversible loss.

[0017] Based on this, embodiments of this application provide a method for persisting the state of an intelligent agent in a cloud phone. Figure 1 This is a flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, as provided in an embodiment of this application.

[0018] The method for persisting the state of an intelligent agent in a cloud phone according to the embodiments of this application can be executed by the device for persisting the state of an intelligent agent in a cloud phone according to the embodiments of this application, and the device can be configured in an electronic device.

[0019] Among them, electronic devices can be any device with computing capabilities, such as servers.

[0020] like Figure 1 As shown, the method for persisting the state of an intelligent agent in this cloud phone includes: Step 101: Obtain the file system mount request corresponding to the target user.

[0021] In this application, the target user can be a user bound to the target cloud phone. The intelligent agent deployed in the container of the target cloud phone can respond to the interaction requests initiated by the target user through the client and provide corresponding services.

[0022] In some embodiments, in response to detecting that the target cloud phone has started, a file system mount request corresponding to the target user can be obtained. This file system mount request is used to request that the network file system be mounted to the target mount point of the container.

[0023] For example, a network file system can refer to a file system located outside the cloud phone cluster, which can be used to store state data related to the agents within each cloud phone in the cloud phone cluster.

[0024] As an example, this state data may include, but is not limited to, the agent's memory data, session history, log data, personalized configurations, skill definitions, etc. This state data can also be understood as user state data within the agent's execution environment.

[0025] For example, the file system mount request may include, but is not limited to, the user identifier of the target user and the device identifier of the target cloud phone.

[0026] As an example, the user identifier could be the client account corresponding to the agent within the target user's login container, or other identifiers that can be used to uniquely identify the target user; there are no restrictions on this.

[0027] As an example, the device identifier could be the device number of the cloud phone in the cluster, or other identifiers that can be used to characterize the uniqueness of the target cloud phone, without limitation.

[0028] Step 102: Determine the metadata address of the network file system.

[0029] In this application, the metadata address can be a URL (Uniform Resource Locator) used to specify the type, location, namespace, etc. of the network file system's metadata engine. For example, the metadata address can uniquely identify a network file system instance.

[0030] For example, a network file system could be JuiceFS, which is a user-space distributed file system that stores metadata in a database and state data in an object store.

[0031] For example, the metadata address can be determined in the following ways: the file system mount request carries the metadata address, which can be obtained from the file system mount request; or the configuration service can be queried based on the user identifier of the target user to obtain the metadata address of the tenant to which the target user belongs; or the metadata address can be determined based on the user identifier of the target user and a preset metadata address generation rule; or other methods can be used to determine the metadata address, which are not limited thereto.

[0032] Step 103: Mount the network file system to the target mount point of the target cloud phone's content device based on the metadata address.

[0033] In this application, a FUSE (Filesystem in Userspace) client can be deployed within a container on the target cloud phone. For example, the FUSE client can be deployed within the same container as the intelligent agent on the target cloud phone.

[0034] FUSE is a mechanism provided by Linux (and other Unix-like systems) that allows ordinary user programs to implement a complete file system. A FUSE client can refer to a file system service process running in user space that implements the FUSE protocol; in other words, a FUSE client is a user-space program that implements the FUSE protocol.

[0035] In this application, a network file system can be mounted to the target mount point of the container using a FUSE client within the container, based on the metadata address. For example, within the container of the target cloud phone, the FUSE client can connect to the metadata engine based on the metadata address, thereby determining the target structure of the network file system through querying, and thus mounting the network file system to the target mount point of the container.

[0036] For example, the target mount point is a local empty directory within the cloud phone's container, which serves as the mount root directory. For instance, if the target mount point is " / mnt / jfs", the entire network file system can be mounted to " / mnt / jfs".

[0037] For example, the target mount point may be a pre-set local directory, or it may be specified by the target user and carried in the file system mount request. This application does not limit this.

[0038] For example, mounting a network file system to a container's target mount point can be understood as mounting the root directory of the network file system to the container's target mount point, or it can be understood as mounting the entire namespace of the network file system to the target mount point within the container. After mounting is complete, the contents of the entire network file system's storage space are visible through the target mount point within the container.

[0039] In this embodiment, mounting the network file system to the target mount point of the container based on the metadata address can be understood as: based on the metadata address, allowing the FUSE client to connect to the correct metadata engine, thereby presenting the complete file system namespace described by the metadata engine as a local directory.

[0040] Step 104: Determine the target user's agent state storage directory in the mounted network file system based on the user identifier.

[0041] In this application, the agent state storage directory is a local mapping path within the container of the storage path of the state data corresponding to the target user in the network file system.

[0042] In some embodiments, the storage path may contain a user identifier, that is, the storage path may contain a user identifier. For example, the storage path may be: / users / {user_id} / v1 / .openclaw, where "user_id" is the user identifier and "v1" is the version number of the agent.

[0043] Based on this, as a possible implementation, the target user's agent state storage directory can be constructed in the mounted network file system based on the target user's user identifier and directory naming rules.

[0044] For example, the target mount point is " / mnt / jfs", the user identifier is "user_id", and the agent state storage directory is: / mnt / jfs / users / {user_id} / v1 / .openclaw, where "user_id" is the user identifier, "v1" is the agent version number, and "users / {user_id} / v1 / .openclaw" is the storage path of the target user's state data in the network file system.

[0045] Step 105: Set the state directory environment variable associated with the agent to the agent state storage directory.

[0046] In this application, the state directory environment variable associated with the agent can refer to the state directory environment variable of the agent's application process. By setting the state directory environment variable associated with the agent to the agent's state storage directory, it can be used to guide the agent to write all runtime state data to this path.

[0047] In some embodiments, the network file system can be mounted to the target mount point of the target cloud phone's content storage via the FUSE client within the container, based on the metadata address. This allows all read and write operations on data related to the target user and the intelligent agent to be transparently accessed through the FUSE layer and connected to the distributed storage, achieving seamless access to the distributed storage.

[0048] For example, after the agent starts, during the interaction between the target user and the agent, the agent can transparently write state data to the network file system through the FUSE layer based on the state directory environment variable. The state data corresponding to the target user can be accessed (e.g., read, write, and query) based on the agent's state storage directory. Thus, the agent's application process can redirect input and output to the distributed file system (i.e., network file system) without modifying the code, achieving decoupling between the application and the storage backend and realizing transparent persistence.

[0049] In this embodiment, a file system mount request is obtained, and the metadata address of the network file system is determined. Based on the metadata address, the entire network file system is mounted to the target mount point within the container. Then, based on the target user's user identifier, the agent's state storage directory is determined within the mounted file system, and the agent's state directory environment variable is set to this directory. Thus, state data generated by the agent in the container during interaction with the target user is automatically written to the agent's state storage directory specified by the state directory environment variable. Since this state storage directory is located within the mounted network file system, all read and write operations on the state data are performed on this network file system. This achieves seamless access and persistent storage of state data to the network file system without modifying the agent's code.

[0050] Figure 2 This is a flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, provided as another embodiment of this application.

[0051] like Figure 2 As shown, the method for persisting the state of an intelligent agent in this cloud phone includes: Step 201: Obtain the file system mount request corresponding to the target user.

[0052] Step 202: Determine the metadata address of the network file system.

[0053] In this application, steps 201-202 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0054] Step 203: Bind the FUSE character device of the host machine to which the target cloud phone belongs to the container.

[0055] In this application, a FUSE character device can refer to a character device node in the host operating system, representing the FUSE driver interface in the kernel; its essence is a "device." The FUSE character device is a standard interface provided by the operating system, allowing user-mode programs to implement complete file system functionality. It can be understood that the FUSE character device is a kernel interface device used to implement a file system in user mode.

[0056] In this application, by passing through the FUSE character device of the host machine to the container of the cloud phone, the FUSE client in the container can mount the distributed file system (i.e., the network file system) without relying on the kernel module, thereby accessing remote persistent storage.

[0057] As an example, a FUSE character device refers to a character device in the host operating system with a major device number of 10 and a minor device number of 229. Its device node is usually located at " / dev / fuse" and is used for communication between user space and the kernel.

[0058] It should be noted that the host machine's FUSE character device can be bound to the container in advance, or it can be executed after obtaining the file system mount request; there is no limitation on this.

[0059] To facilitate understanding, the following will be combined with... Figure 3 To explain, Figure 3 This is a schematic diagram of a storage-compute separation architecture provided in an embodiment of this application.

[0060] Figure 3 The architecture diagram includes a cloud phone cluster, a service cluster, and a shared storage layer. The cloud phone cluster contains a host machine, a container corresponding to user A, and a container corresponding to user B. The host machine kernel has the FUSE module loaded, and the containers deploy intelligent agents and FUSE clients. The shared storage layer can refer to a network file system. Metadata is stored in the metadata database of the metadata engine, while state data is stored in object storage; metadata and state data are stored separately. Taking the container corresponding to user A as an example, the host machine transparently transmits the character device to the container corresponding to user A, i.e., binds it to the container corresponding to user A. The FUSE client can perform read and write operations on the object storage in the network file system in read-write mode and can perform metadata operations on the metadata engine.

[0061] Step 204: Based on the metadata address, mount the network file system to the target mount point via the FUSE character device.

[0062] In this application, the host kernel of the target cloud phone can pre-load the FUSE module. The FUSE module is a loadable kernel module in the host kernel, responsible for the read and write scheduling of the FUSE character device. The FUSE module refers to the FUSE support module running in the host kernel, used to forward file operation requests between the FUSE client and the kernel virtual file system. The mount operation is completed by the kernel's mount system call; the FUSE module itself does not directly perform the mount operation but provides a communication channel.

[0063] In some embodiments, the FUSE client within the container can establish communication with the FUSE module in the host kernel through the FUSE character device, register a file system instance with the FUSE module based on the metadata address, so that the host kernel can mount the network file system to the target mount point. Here, the file system instance can be understood as an instance of the network file system.

[0064] For example, communication between the FUSE character device and the FUSE module in the host kernel can be established in the following way: The FUSE client opens the FUSE character device. If the host kernel recognizes the FUSE character device, the FUSE module establishes communication with the FUSE client, parses and connects the metadata address, initializes the file system instance and registers it with the FUSE session, and the client sends a mount system call to the virtual file system in the host kernel. The kernel creates the target mount point in the virtual file system tree and notifies the kernel that all subsequent operations on the target mount point by the virtual file system will be handled by the FUSE module, thereby mounting the network file system to the target mount point.

[0065] Therefore, the FUSE client establishes communication with the FUSE module in the host kernel through the FUSE character device and registers a file system instance with the FUSE module based on the metadata address. This allows the host kernel to mount the network file system identified by the metadata address to the target mount point inside the container, thus presenting an accessible local file system view in the container. The entire mounting process is based on the kernel's existing FUSE mechanism, eliminating the need to implement the underlying file system logic within the container. The container image does not need to include file system drivers or related runtime dependencies, thereby reducing image complexity and startup overhead. Furthermore, the file system service is uniformly provided by the host kernel through the FUSE mechanism, which avoids introducing potential security risks or compatibility issues into the container and ensures that file system anomalies do not affect kernel stability, thus enhancing security.

[0066] To improve the reliability and success rate of file system mounting, in some embodiments, before mounting the network file system to the target mount point via the FUSE character device based on the metadata address, the FUSE character device can be validated for legitimacy. When the FUSE character device passes the validation, the network file system is then mounted to the target mount point via the FUSE character device based on the metadata address.

[0067] For example, the legitimacy verification may include at least one of the following: pass-through verification, correctness verification, readability verification, etc.

[0068] For example, pass-through verification is used to confirm whether the FUSE character device in the host machine has been bound to the container, that is, to confirm whether the FUSE character device in the host machine has been passed through to the container.

[0069] For example, the correctness verification is used to confirm whether the device number bound to the FUSE character device is a preset device number. If the FUSE character device is a preset device number, it means that the FUSE character device is determined, thus confirming that the FUSE character device passes the correctness verification; if the FUSE character device is not a preset device number, it can be determined that the FUSE character device fails the correctness verification.

[0070] For example, the preset device number includes the major device number 10 and the minor device number 229. If the major device number of the FUSE character device passed to the container is 10 and the minor device number of the FUSE character device is 229, it means that the FUSE character device is correct. Otherwise, it means that the FUSE character device is incorrect and fails the correctness verification.

[0071] For example, readability verification is used to verify whether a FUSE character device has read and write permissions.

[0072] Therefore, by ensuring that the FUSE character device passes the validity verification before performing the mounting operation, it is possible to ensure that the FUSE character device on which the mounting depends is in a valid and usable state, avoiding mounting failure due to missing devices, incorrect binding, or insufficient permissions, and improving the reliability and success rate of the mounting process.

[0073] In some embodiments, a network file system can be mounted to a target mount point within the container using a FUSE client within the container. Before mounting the network file system to the target mount point via the FUSE character device based on the metadata address, a binary verification can be performed on the FUSE client to verify that the FUSE client's binary file exists in a preset path and has execute permissions. If the FUSE client passes the binary verification, the FUSE client within the container mounts the network file system to the target mount point via the FUSE character device based on the metadata address.

[0074] For example, the binary file of the FUSE client can be pre-compiled using the target compilation method, and the binary file of the FUSE client can be configured inside a container.

[0075] As an example, the target compilation method can be static compilation, such as generating a completely static binary with the CGO_ENABLED=0 compilation option, which can eliminate dependencies on any dynamic link libraries.

[0076] Therefore, by performing binary verification on the FUSE client, it is confirmed that its binary file exists in the preset path and has execution permissions. After successful verification, the network file system is mounted to the target mount point through the FUSE character device based on the metadata address. This ensures that the FUSE client on which the mounting operation depends can be correctly called and executed, avoiding interruption of the mounting process due to missing binary files, incorrect paths, or insufficient permissions, and improving the determinism and execution reliability of the mounting process.

[0077] In some embodiments, the FUSE character device can be validated first. If the FUSE character device passes the validation, the FUSE client can be validated in binary form. If the FUSE client passes the binary validation, the network file system can be mounted to the target mount point based on the metadata address via the FUSE character device.

[0078] It should be noted that, before mounting the network file system to the target mount point, both the validity verification of the FUSE character device and the binary verification of the FUSE client can be performed, or one of them can be performed. This application does not limit this.

[0079] Step 205: Determine the target user's agent state storage directory in the mounted network file system based on the user identifier.

[0080] Step 206: Set the state directory environment variable associated with the agent to the agent's state storage directory.

[0081] In this application, steps 205-206 can be implemented in any of the embodiments of this application, so they will not be described in detail here.

[0082] In this embodiment, by binding the FUSE character device of the host machine to which the target cloud phone belongs to the container, and using the FUSE character device based on the metadata address to mount the network file system to the target mount point in the container, the mounting and management of the file system can be completed in user space with the help of the existing FUSE support of the host kernel. Thus, the container's local mounting capability of the network file system is realized without modifying the host kernel or installing or loading any kernel modules in the container.

[0083] In some scenarios, users may switch to another cloud phone after using one for a period of time. In this case, how to migrate and restore the state data associated with the intelligent agent from the old cloud phone to the new cloud phone is a problem that urgently needs to be solved.

[0084] Based on this, in some embodiments of this application, obtaining the file system mount request corresponding to the target user may include: if the binary file and configuration information of the FUSE client pushed by the control gateway are obtained, then the file system mount request can be obtained.

[0085] For example, the control gateway can be a gateway in a service cluster, capable of controlling the shutdown of the intelligent agent gateway corresponding to the intelligent agent in the cloud phone. The intelligent agent gateway can provide remote interaction capabilities. For instance, the intelligent agent gateway can process instructions from external intelligent agent clients (such as remote control commands, natural language dialogue requests, task scheduling signals, etc.).

[0086] For example, the binary file and configuration information are associated with a recycled old cloud phone. For instance, the old cloud phone may have had this binary file deployed within its container while providing agent-related services, and the configuration information may also be used by the FUSE client in the old cloud phone to mount the network file system to the target mount point within the container.

[0087] For example, the configuration information may include the target user's user identifier, the metadata address of the network file system, etc.

[0088] In this embodiment, the target cloud phone can be regarded as a new cloud phone bound to the target user. When the new cloud phone starts up, if it obtains the binary file and configuration information of the FUSE client pushed by the control gateway, it obtains a file system mount request.

[0089] To facilitate understanding, the following combination Figure 4 To explain, Figure 4This is a schematic diagram of a cloud mobile device migration data recovery method provided in an embodiment of this application.

[0090] like Figure 4 As shown, the method includes two stages: the old cloud phone recycling stage and the new cloud phone recovery stage.

[0091] The process for recycling an old cloud phone involves the following steps: The control gateway sends a stop command to the old cloud phone, which then shuts down the smart agent gateway and flushes all write buffers (i.e., write caches in memory) to the backend storage. Next, the control gateway sends an unmount command to the old cloud phone, which unmounts the mounted network file system. Afterward, the old cloud phone sends a signal to the metadata engine, which releases its file locks and sends a final refresh command to the object storage service. Finally, the control gateway recycles the old cloud phone. The file lock records are visible across clients in the metadata database.

[0092] During the new cloud phone recovery phase: The control gateway allocates the new cloud phone and pushes the FUSE client's binary file and configuration information to it. Then, the control gateway sends a mount command to the new cloud phone. Based on the configuration information, the new cloud phone connects to the same metadata database and the same object storage, and executes the FUSE mount, mounting the network file system to the mount point within the new cloud phone's container. After successful FUSE mount, the user directory metadata is queried through the metadata engine to obtain the complete directory structure returned by the metadata engine. Thus, the new cloud phone immediately sees all user data without any data transfer. Afterward, the control gateway sets the agent's state directory environment variable to the target user's agent state storage directory in the mounted network file system and starts the agent gateway in the new cloud phone.

[0093] As can be seen, the recovery process does not rely on the local cache of the old cloud phone. The new cloud phone pulls the data again from the object storage service, and the cache is gradually warmed up.

[0094] Optionally, after the intelligent agent gateway in the new cloud phone, if there are unfinished transactions when the old cloud phone crashes, when the new cloud phone opens the database, the database automatically discovers the log file and rolls back to the unfinished transaction, deletes the log file, restores the data to the last successfully committed state, sets the database lock mode to exclusive lock mode, and records the new exclusive lock in the metadata database.

[0095] Understandably, after the old cloud phone is uninstalled and mounted, the lock record held by the FUSE client in the metadata service is released, and the new cloud phone can normally acquire the exclusive lock.

[0096] In this embodiment, in response to receiving the FUSE client binary file and configuration information associated with the recycled old cloud phone pushed by the control gateway, a file system mount request corresponding to the target user is triggered, enabling the new cloud phone to mount the same network file system as the old cloud phone based on the configuration information. Since the status data has been completely preserved in the network file system, there is no need to transmit any status data during the device migration process. Access to all status data of the target user can be immediately restored simply by mounting the same file system.

[0097] In some embodiments of this application, the aforementioned state data may include memory data, which may be stored in a target database on a network file system. For example, the target database may be an SQLite database or other databases, and this is not limited.

[0098] Since placing the target database on a network file system mounted by FUSE may lead to issues such as file lock transfer across clients and concurrent read / write operations by multiple clients, in some embodiments, the target database can be configured securely during the initialization process.

[0099] For example, the security configuration may include, but is not limited to, setting the target database's log mode to delete mode, setting the target database's lock mode to exclusive lock mode, and setting the target database's synchronization level to full synchronization mode.

[0100] For example, while the agent holds the exclusive lock in the file lock, any operation by the service cluster that attempts to open the target database is blocked, thereby achieving a single-client exclusive usage mode and avoiding the security risks of multiple clients concurrently accessing the target database.

[0101] For example, in fully synchronous mode, the FUSE client uploads the memory buffer data to the object storage and updates the file metadata in the metadata database.

[0102] For example, in full synchronization mode, the target database performs two full synchronizations on transaction commits: one after the log files are completed, ensuring that the original page backup has been persisted to object storage; and another after the database files are modified, ensuring that the new data has been persisted to object storage. This guarantees data persistence for each transaction commit.

[0103] In this embodiment of the application, during the initialization of the target database used to store memory data in state data, by performing security configuration on the target database, the database can reduce log residue, limit concurrent access to avoid state conflicts, and ensure strong consistency of data writing during operation, thereby improving the security and reliability of memory data storage.

[0104] Figure 5 This is a flowchart illustrating a method for persisting the state of an intelligent agent in a cloud phone, provided as another embodiment of this application.

[0105] like Figure 5 As shown, the method for persisting the state of an intelligent agent in this cloud phone includes: Step 501: Obtain the access request associated with the agent.

[0106] In this application, during the interaction between the target user and the intelligent agent through a client, the control gateway can obtain access requests associated with the intelligent agent. For example, this access request can be used to request access to the target user's state data on a network file system.

[0107] For example, when a target user enters a question in the client, the intelligent agent queries the status data and generates a response based on the query results.

[0108] Step 502: Determine the data type of the data to be accessed in the status data based on the access request.

[0109] In this application, the access request can be parsed to determine the data to be accessed in the status data and the data type of the data to be accessed.

[0110] For example, data types may include file-type data, database data, etc.

[0111] As an example, file-type data can be structured or semi-structured data files stored in text format. File-type data can include, but is not limited to, JSONL files, JSON files, Markdown files, etc.

[0112] As an example, database data can refer to data stored in a database. For instance, memory data in state data exists in an SQLite database, so database data can refer to SQLite database data.

[0113] Step 503: Determine the access strategy based on the data type.

[0114] In this application, different access strategies can be adopted for different data types.

[0115] For example, if the data type is file-type data, the access strategy can be direct access; if the data type is database data, it is done through the gateway RPC (Remote Procedure Call) proxy associated with the agent.

[0116] As an example, if the data type is database data, instead of directly accessing the database file on the network file system, the data in the database is accessed by calling the memory query method exposed by the ARM-side intelligent agent gateway via the WebSocket JSON-RPC protocol. This is because in the exclusive lock mode on the ARM side, if a read-only access to file-type data attempts to open the target database, it can be rejected by the cross-client lock, and the gateway RPC call memory query method is a safe path, so there are no concurrency issues in executing SQLite queries within the ARM process of the cloud phone cluster.

[0117] like Figure 3 As shown, in the service cluster, if it is a session query (such as a user viewing the dialogue history with the agent) or skill browsing, the network file system can be directly accessed through JuiceFS read-only mounting. If it is a database query, the memory query method exposed by the agent gateway in the cloud phone can be called through the gateway RPC proxy to access the database on the network file system.

[0118] Therefore, by using a data type splitting strategy, file-type data can be directly accessed through JuiceFS read-only mounting, while SQLite database queries can be completed through a gateway RPC proxy, thus achieving cross-architecture data reachability while ensuring data security.

[0119] Step 504: Access the data to be accessed based on the access policy.

[0120] In this application, data to be accessed on a network file system can be accessed based on a defined access policy.

[0121] In this embodiment of the application, by obtaining the access request associated with the agent, identifying the data type of the data to be accessed in the state data, determining the corresponding access strategy based on the data type, and then executing the access to the data to be accessed according to the access strategy, the access to the state data can be processed differently according to the data type, thereby improving the security and reliability of the access process.

[0122] In some embodiments of this application, a degradation disaster recovery scheme may be adopted if it is not feasible to mount the FUSE client within the container.

[0123] In some embodiments, if the FUSE client is unavailable and the host machine to which the target cloud phone belongs can be modified, FUSE mounting can be performed within the host machine, and the state data can be mounted to the target directory from the local path within the host machine. This allows the state data to be exposed to the target directory through the mounting mechanism on the host machine side even if there is no available FUSE client in the container, thereby maintaining the ability to access the state data.

[0124] For example, performing a FUSE mount within the host machine can be understood as mounting the storage path of state data in the network file system to a mount point within the host machine. This storage path is a logical subpath in the network file system.

[0125] In other words, if the FUSE client is unavailable but the host machine can modify it, the storage path of the state data in the network file system can be mounted to a mount point on the host machine to obtain the mounted path. This mounted path is then mounted to the target directory within the container. The mounted path consists of the mount point on the host machine and the storage path of the state data in the network file system.

[0126] In some embodiments, if the FUSE client is unavailable and the host machine to which the target cloud phone belongs is unmodifiable, a data snapshot of the memory data in the target database on the network file system is generated, and the data snapshot is synchronized to a remote storage backup.

[0127] For example, a data snapshot can be a transactionally consistent copy of the target database used by an agent running within a cloud phone container.

[0128] For example, remote storage could be a backup server, an object storage gateway, or the like.

[0129] As an example, if the target database is an SQLite database, it can be generated in the container's local temporary directory through the SQLite online backup API (Application Programming Interface) and securely synchronized to remote storage backup, which can avoid data inconsistency or database file corruption caused by directly copying the running database file.

[0130] Therefore, if the FUSE client is unavailable and the host machine to which the target cloud phone belongs cannot be modified, a data snapshot of the memory data in the target database on the network file system can be generated and the data snapshot can be synchronized to the remote storage. This allows the current state of the memory data to be preserved in the form of a snapshot and its persistent backup to be achieved even in a restricted environment where the state data cannot be directly accessed through mounting, ensuring that the data is not lost.

[0131] To facilitate understanding, the following will be combined with... Figure 6 To explain, Figure 6 This is a schematic diagram illustrating a multi-level degradation disaster recovery method provided in an embodiment of this application.

[0132] like Figure 6As shown, after the cloud phone starts, it first checks whether the FUSE client binary can run in the container and whether the FUSE character device is available. If the binary is incompatible, it attempts to perform a fully static compilation. If the FUSE character device is unavailable or the fully static compilation fails, it checks whether the host machine can be modified. If the binary can run in the container and the FUSE character device is available, or if the fully static compilation succeeds, it checks whether the SQLite security configuration is secure on the network file system. If the host machine can be modified, it uses a scheme of mounting FUSE within the host machine and binding it within the container. If the host machine cannot be modified, it uses a data synchronization scheme. If the SQLite security configuration is secure on the network file system, it checks whether the cross-client lock is rejected. If it is rejected, it uses the scheme of mounting FUSE within the container; otherwise, it retests after cache optimization. If the improvement is achieved, it uses the scheme of mounting FUSE within the container; if the improvement is not achieved, it uses a scheme of mounting FUSE within the host machine and binding it within the container.

[0133] In this embodiment of the application, if it is not feasible to mount the FUSE client within the container, a degradation disaster recovery scheme can be adopted, such as downgrading to mount the FUSE client on the host machine or data synchronization, to ensure that the persistence of agent data can be achieved under the constraints of the host machine environment.

[0134] The method for persisting the state of an intelligent agent in a cloud phone according to embodiments of this application may include: (1) In the cloud phone container, user-space access to the distributed file system is achieved by eliminating dependencies through FUSE character device device pass-through and static compilation, without touching the host kernel; (2) Configuring security for the target database can eliminate security risks associated with target databases such as SQLite on the network file system: the delete log mode can avoid the mmap problem of the WAL (Write Ahead Log) mode, exclusive locks can eliminate the risk of multi-client concurrency, and full synchronization ensures the data persistence of each transaction commit. The combination of these three can downgrade the use of SQLite on the network file system to a "single-client exclusive" mode; (3) Symmetric access model balances security and reachability: The architecture design of ARM read-write and X86 read-only, combined with data type splitting (direct reading of file type, SQLite through RPC proxy), achieves cross-architecture data reachability while ensuring the security of memory database transactions.

[0135] (4) Zero data transmission device migration: Utilizing the separation characteristics of "metadata in metadata database and data in object storage", zero data operation is required during device migration - the old device is unloaded and the lock is released, and all data can be seen when the new device is mounted. SQLite logs are automatically rolled back to ensure consistency. (5) Multi-level degradation ensures the certainty of implementation: The three-level degradation disaster recovery plan (FUSE mounting in container -> host mounting -> remote synchronization) covers different scenarios and can ensure data persistence under different host constraints.

[0136] To implement the above embodiments, this application also proposes a device for persisting the state of an intelligent agent in a cloud phone. Figure 7 This is a schematic diagram of the structure of a persistent state device for an intelligent agent in a cloud phone, provided in an embodiment of this application.

[0137] like Figure 7 As shown, the intelligent agent state persistence device 700 in the cloud phone includes: The acquisition module 710 is used to acquire the file system mount request corresponding to the target user; wherein, the file system mount request includes the user identifier of the target user; The first mounting module 720 is used to determine the metadata address of the network file system and mount the network file system to the target mount point of the target cloud phone's content device according to the metadata address. The determination module 730 is used to determine the agent state storage directory of the target user in the mounted network file system based on the user identifier; wherein, the agent state storage directory is used to persistently store the state data generated by the agent in the storage container during the interaction with the target user; The configuration module 740 is used to set the state directory environment variable associated with the agent to the agent state storage directory.

[0138] Optionally, module 720 is mounted for: Bind the FUSE character device of the host machine to which the target cloud phone belongs to the container; Based on the metadata address, the network file system is mounted to the target mount point via the FUSE character device.

[0139] Optionally, module 720 is mounted for: Establish communication with the FUSE module in the host kernel through the FUSE character device; Based on the metadata address, register the file system instance with the FUSE module so that the host kernel can mount the network file system to the target mount point.

[0140] Optionally, module 720 is mounted for: Perform validity verification on the FUSE character device; the validity verification includes at least one of the following: pass-through verification, correctness verification, and readability verification; In response to the FUSE character device passing the validity verification, the network file system is mounted to the target mount point through the FUSE character device based on the metadata address.

[0141] Optionally, module 720 is mounted for: Perform binary verification on the FUSE client to verify that the FUSE client binary file exists in the preset path and has execute permissions; the FUSE client runs inside a container. In response to the FUSE client's binary verification, the network file system is mounted to the target mount point via the FUSE character device based on the metadata address.

[0142] Optionally, module 710 is used for: In response to receiving the binary file and configuration information of the FUSE client pushed by the control gateway, obtain the file system mount request; The binary file and configuration information are associated with the recycled old cloud phones. The configuration information includes the user identifier and metadata address.

[0143] Optionally, the memory data in the state data is stored in a target database on a network file system, and the device may further include: The secure execution module is used to perform secure configuration on the target database during the initialization process. The security configuration includes at least one of the following: setting the target database's log mode to delete mode; setting the target database's lock mode to exclusive lock mode; and setting the target database's synchronization level to full synchronization mode.

[0144] Alternatively, the state data can be accessed in the following ways: Obtain the access request associated with the agent; Based on the access request, determine the data type of the data to be accessed in the status data; Determine the access strategy based on the data type; Access the data to be accessed based on the access policy.

[0145] Optionally, mounting the network file system to the target mount point of the target cloud phone's content device based on the metadata address is performed by a FUSE client running within the container. This device may also include: The second mounting module is used to respond to the fact that the FUSE client is unavailable and the host machine to which the target cloud phone belongs can be modified. It performs FUSE mounting within the host machine and mounts the state data from the local path within the host machine to the target directory. The synchronization module is used to generate a data snapshot of the memory data in the target database on the network file system in response to the FUSE client being unavailable and the host machine to which the target cloud phone belongs being unmodifiable, and to synchronize the data snapshot to remote storage.

[0146] It should be noted that the explanation of the aforementioned embodiment of the intelligent agent state persistence method in cloud phones also applies to the intelligent agent state persistence device in cloud phones of this embodiment, so it will not be repeated here.

[0147] In this embodiment, a file system mount request is obtained, and the metadata address of the network file system is determined. Based on the metadata address, the entire network file system is mounted to the target mount point within the container. Then, based on the target user's user identifier, the agent's state storage directory is determined within the mounted file system, and the agent's state directory environment variable is set to this directory. Thus, state data generated by the agent in the container during interaction with the target user is automatically written to the agent's state storage directory specified by the state directory environment variable. Since this state storage directory is located within the mounted network file system, all read and write operations on the state data are performed on this network file system. This achieves seamless access and persistent storage of state data to the network file system without modifying the agent's code.

[0148] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0149] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0150] like Figure 8 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 802 or a computer program loaded from storage unit 808 into RAM (Random Access Memory) 803. RAM 803 can also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. I / O (Input / Output) interface 805 is also connected to bus 804.

[0151] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0152] The computing unit 801 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the agent state persistence method in a cloud phone. For example, in some embodiments, the agent state persistence method in a cloud phone can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the agent state persistence method in a cloud phone described above can be performed. Alternatively, in other embodiments, computing unit 801 may be configured to perform a method for persisting agent state in a cloud phone by any other suitable means (e.g., by means of firmware).

[0153] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0154] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0155] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0156] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0157] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0158] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0159] According to an embodiment of this application, this application also provides a computer program product that, when the instruction processor in the computer program product is executed, performs the method for persisting the state of an intelligent agent in a cloud phone as proposed in the above embodiments of this application.

[0160] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0161] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for persisting the state of an intelligent agent in a cloud phone, the method comprising: Obtain the file system mount request corresponding to the target user; wherein, the file system mount request includes the user identifier of the target user; Determine the metadata address of the network file system, and mount the network file system to the target mount point of the target cloud phone's content device according to the metadata address; Based on the user identifier, determine the agent state storage directory of the target user in the mounted network file system; wherein, the agent state storage directory is used to persistently store the state data generated during the interaction between the agent in the container and the target user; Set the state directory environment variable associated with the agent to the state storage directory of the agent.

2. The method as described in claim 1, wherein, The step of mounting the network file system to the target mount point of the target cloud phone's content device according to the metadata address includes: Bind the FUSE character device of the host machine to which the target cloud phone belongs to the container; Based on the metadata address, the network file system is mounted to the target mount point via the FUSE character device.

3. The method as described in claim 2, wherein, The step of mounting the network file system to the target mount point via the FUSE character device based on the metadata address includes: Communication is established between the FUSE character device and the FUSE module in the host kernel. Based on the metadata address, a file system instance is registered with the FUSE module so that the host kernel can mount the network file system to the target mount point.

4. The method as described in claim 2, wherein, The step of mounting the network file system to the target mount point via the FUSE character device based on the metadata address includes: The FUSE character device is subjected to a validity verification; wherein the validity verification includes at least one of the following: pass-through verification, correctness verification, and readability verification; In response to the FUSE character device passing the validity verification, the network file system is mounted to the target mount point through the FUSE character device based on the metadata address.

5. The method as described in claim 2, wherein, The step of mounting the network file system to the target mount point via the FUSE character device based on the metadata address includes: The FUSE client undergoes binary verification to confirm that the FUSE client binary file exists in a preset path and has execute permissions; wherein the FUSE client runs within the container. In response to the FUSE client's binary verification, the network file system is mounted to the target mount point via the FUSE character device based on the metadata address.

6. The method of claim 1, wherein, The step of obtaining the file system mount request corresponding to the target user includes: In response to receiving the binary file and configuration information of the FUSE client pushed by the control gateway, obtain the file system mount request; The binary file and the configuration information are associated with the recycled old cloud phones, and the configuration information includes the user identifier and the metadata address.

7. The method according to any one of claims 1-6, wherein, The memory data in the state data is stored in the target database on the network file system, and the method further includes: During the initialization of the target database, security configuration is performed on the target database; The security configuration includes at least one of the following: setting the log mode of the target database to delete mode; setting the lock mode of the target database to exclusive lock mode; and setting the synchronization level of the target database to full synchronization mode.

8. The method according to any one of claims 1-6, wherein, The status data can be accessed in the following ways: Obtain the access request associated with the intelligent agent; Based on the access request, determine the data type of the data to be accessed in the status data; Determine the access strategy based on the data type; Based on the access strategy, the data to be accessed is accessed.

9. The method according to any one of claims 1-6, wherein, The step of mounting the network file system to the target mount point of the target cloud phone's content device based on the metadata address is performed by the FUSE client running within the container. The method further includes: In response to the FUSE client being unavailable and the host machine to which the target cloud phone belongs being modifiable, FUSE mounting is performed within the host machine, and the status data is mounted from the local path within the host machine to the target directory; In response to the FUSE client being unavailable and the host machine to which the target cloud phone belongs being unmodifiable, a data snapshot of the memory data in the target database on the network file system is generated, and the data snapshot is synchronized to remote storage.

10. A device for persisting the state of an intelligent agent in a cloud phone, comprising: The acquisition module is used to acquire the file system mount request corresponding to the target user; wherein, the file system mount request includes the user identifier of the target user; The first mounting module is used to determine the metadata address of the network file system and mount the network file system to the target mount point of the target cloud phone's content device according to the metadata address. The determination module is used to determine, based on the user identifier, the agent state storage directory of the target user in the mounted network file system; wherein, the agent state storage directory is used to persistently store the state data generated during the interaction between the agent in the container and the target user; The setting module is used to set the state directory environment variable associated with the agent to the state storage directory of the agent.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

13. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-9.

Images