A sandbox reuse method, device, equipment and storage medium

Abstract

The application discloses a sandbox reuse method, device, equipment and storage medium. The method comprises the following steps: obtaining a session identifier of a current session and at least one agent identifier corresponding to each agent that can be called; generating a sandbox name according to the session identifier and the agent identifier; obtaining a mutex according to the sandbox name, and reading a cache sandbox identifier corresponding to the sandbox name from the cache; performing a preset mode of binding detection on a target sandbox according to the cache sandbox identifier and the existence of the target sandbox corresponding to the cache sandbox identifier; and determining to reuse the target sandbox in response to the detection result of the binding detection being passed. The application improves the efficiency and stability of sandbox reuse.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a sandbox reuse method, apparatus, device and storage medium. Background Technology

[0002] With the development of the times, artificial intelligence technology is being widely applied in more and more industries. Among them, in the scenario of intelligent agent task execution, remote isolation sandboxes provide an independent operating environment for tool invocation and task computation, and the sandbox reuse capability directly affects the efficiency of business execution. Current mainstream sandbox reuse solutions have obvious shortcomings, and it is difficult to balance reuse efficiency and reuse stability.

[0003] For example, in related technologies, a new sandbox is created for each task, which results in a long cold start time and consumes a lot of computing power due to repeated initialization; or, an existing sandbox can be reused, but this can easily lead to more execution failures or task conflicts. Therefore, how to improve the efficiency and stability of sandbox reuse has become one of the key research focuses for engineers in related fields. Summary of the Invention

[0004] This application provides a sandbox reuse method, apparatus, device, and storage medium to improve the efficiency and stability of sandbox reuse.

[0005] According to one aspect of this application, a sandbox reuse method is provided, comprising: Obtain the session identifier of the current session and at least one agent identifier corresponding to each callable agent; Generate a sandbox name based on the session identifier and agent identifier; Based on the sandbox name, acquire the mutex lock and read the cache sandbox identifier corresponding to the sandbox name from the cache; Based on the existence of the cache sandbox identifier and the corresponding target sandbox, the target sandbox is bound and detected in a preset manner. If the detection result of the binding probe is passed, the target sandbox is determined to be reused.

[0006] According to another aspect of this application, a sandbox reuse device is provided, comprising: The session information acquisition module is used to acquire the session identifier of the current session and at least one agent identifier corresponding to each callable agent. The sandbox name generation module is used to generate sandbox names based on session identifiers and agent identifiers; The sandbox identifier acquisition module is used to acquire a mutex lock based on the sandbox name and read the cached sandbox identifier corresponding to the sandbox name from the cache. The sandbox binding detection module is used to perform binding detection on the target sandbox in a preset manner based on the existence of the cached sandbox identifier and the target sandbox corresponding to the cached sandbox identifier. The target sandbox reuse module is used to determine the target sandbox to reuse in response to a pass result from the bound probe.

[0007] According to another aspect of this application, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the sandbox reuse method described in any embodiment of this application.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the sandbox reuse method described in any embodiment of this application.

[0009] According to another aspect of this application, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the sandbox reuse method according to any embodiment of this application.

[0010] In the technical solution of this application embodiment, a sandbox name is generated using a session identifier and an agent identifier. A mutex lock is used to read the cached sandbox identifier, and a unified binding probe is performed on the target sandbox. Only after the probe passes is the sandbox reused. This solves the problem in existing technologies where sandboxes fail or belong to other sessions due to direct reuse relying solely on cache or sandbox names. By using session binding probes before reuse as a verification basis, the availability of the sandbox is double-checked from both connection and session affiliation, significantly reducing the probability of failure and erroneous reuse across session sandboxes. Simultaneously, relying on a stable sandbox name enables continuous reuse of the same session's sandbox state, reducing the cold start overhead and resource consumption caused by repeated sandbox creation, and improving the efficiency and stability of sandbox reuse.

[0011] 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

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a sandbox reuse method provided according to Embodiment 1 of this application; Figure 2A This is a schematic diagram of sandbox acquisition and restoration according to Embodiment 2 of this application; Figure 2B This is a schematic diagram of concurrent locks and caching provided according to Embodiment 2 of this application; Figure 2C This is a schematic diagram generated according to the binding detection script provided in Embodiment 2 of this application; Figure 2D This is a schematic diagram of the binding detection process provided in Embodiment 2 of this application; Figure 2E This is a schematic diagram illustrating the on-demand refresh of the validity period according to Embodiment 2 of this application; Figure 3 This is a structural schematic diagram of a sandbox reuse device provided according to Embodiment 3 of this application; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the sandbox reuse method of the embodiments of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1This application provides a flowchart of a sandbox reuse method in Embodiment 1. This embodiment is applicable to the detection and reuse of the sandbox environment during the execution of intelligent agent tasks. The method can be executed by a sandbox reuse device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes: S110. Obtain the session identifier of the current session and at least one agent identifier corresponding to each callable agent.

[0017] Here, the session identifier can be a unique identifier corresponding to a single agent dialogue or a single agent task, used to distinguish different business session scenarios; an agent refers to a program entity that can autonomously select tools, fill in running parameters, and initiate tool calls according to user tasks. The agent identifier can be a unique identifier corresponding to different agents and different execution roles within the same session. This identifier can be empty, adapting to single agent session scenarios.

[0018] For example, in the initial stage of starting the sandbox reuse process, the globally unique session identifier corresponding to the currently running session is actively captured. At the same time, all intelligent agents that can be called normally under the current session are traversed, and the intelligent agent identifier corresponding to each intelligent agent is obtained one by one. Finally, a complete set of identity information containing session identity and intelligent agent identity is formed, which provides the core data source for generating a unique sandbox name in the future, and ensures the uniqueness of the binding between the sandbox and the session and intelligent agent.

[0019] S120. Generate a sandbox name based on the session identifier and agent identifier.

[0020] The sandbox name can be a stable, unique name generated based on session and agent identity information, serving as the core index for retrieval, matching, creation, and reuse of the sandbox. It should be noted that when the agent identifier is empty, the sandbox name can be directly generated based on the session identifier; when the agent identifier is not empty, the sandbox name is generated jointly based on both the session identifier and the agent identifier. The sandbox name can be generated by directly combining the characters of the session identifier and the agent identifier, or by recompiling the session identifier and the agent identifier according to a preset generation logic; this embodiment does not limit the specific method used.

[0021] For example, if the agent identifier obtained in S110 is empty, meaning the current session is a single-agent session, a fixed sandbox name is generated directly based on the unique session identifier. If the agent identifier is not empty, meaning the current session contains multiple agents with different execution roles, the session identifier is combined with the corresponding agent identifier to generate a unique sandbox name. This naming rule can ensure that the same session and the same agent correspond to a fixed sandbox name, while different agents and different sessions correspond to different sandbox names, fundamentally distinguishing sandbox resources for different business scenarios and avoiding sandbox name confusion.

[0022] S130. Based on the sandbox name, acquire the mutex lock and read the cache sandbox identifier corresponding to the sandbox name from the cache.

[0023] Mutexes are a core mechanism for concurrency control, ensuring that only a single request can execute sandbox retrieval, probing, creation, and initialization processes for the same sandbox name at any given time, thus preventing concurrency conflicts. A cached sandbox identifier is a temporary record of the last used sandbox number for each sandbox name, serving as the core basis for matching historical sandbox resources at the cache level. The cache itself is a temporary storage area that stores the correspondence between sandbox names and sandbox identifiers, used for quickly retrieving historical sandbox resources.

[0024] Based on the unique sandbox name generated by S120, a mutex lock is requested first to lock all operation permissions for that sandbox name. Requests that fail to acquire the lock will enter a waiting or retry state. If a request is actively canceled, the waiting will terminate and a cancellation error will be returned. This ensures the serialization of operations for a single sandbox name and solves the problems of concurrent requests repeatedly creating sandboxes, repeatedly initializing, and overwriting cached data in traditional solutions. After successfully acquiring the lock, the local cache is accessed, and the corresponding cached sandbox identifier is accurately retrieved based on the current sandbox name. Historical cached sandbox identifiers are obtained to provide a retrieval basis for subsequent sandbox validity detection.

[0025] In one alternative implementation, the method further includes: in response to the release of the mutex lock, controlling the next request to reread the cache.

[0026] Once the current sandbox's detection, reuse, or creation process is complete, the mutex lock corresponding to the current sandbox name can be automatically released, unlocking the operation. At this point, the next request in the waiting queue will not perform operations based on the old cached data, but will reread the latest cached data and carry out the sandbox matching process based on real-time cache information, completely avoiding the problems of repeated initialization and resource conflicts caused by the lag of old data.

[0027] S140. Based on the existence of the cache sandbox identifier and the target sandbox corresponding to the cache sandbox identifier, perform a preset binding detection on the target sandbox.

[0028] The target sandbox can be a historical sandbox instance corresponding to the current cached sandbox identifier. Binding detection is the core verification process before sandbox reuse. It can enter the target sandbox to be reused and run a lightweight script to comprehensively verify the sandbox connection validity, running status, and session ownership. It is a control method to prevent invalid sandboxes and cross-session sandbox reuse.

[0029] For example, based on the cache sandbox identifier obtained by S130, the validity of the identifier and the actual existence status of the corresponding target sandbox are first verified. Instead of directly reusing the sandbox based on the cache hit result, a standardized binding detection process is initiated for different sandbox existence statuses. The reusability of the target sandbox is comprehensively verified from multiple dimensions such as sandbox existence, connection availability, and session attribution. This solves the technical defects of traditional solutions that rely solely on cache or name matching for direct reuse, leading to the reuse of invalid sandboxes and cross-session sandboxes.

[0030] S150, In response to the detection result of the binding probe being passed, determine the target sandbox to be reused.

[0031] After completing the binding probe process, if the probe results show that the target sandbox is connected normally, the script is executed successfully, and the current session is exclusively bound, then the target sandbox status can be determined to be valid and the ownership matched. It can be confirmed that the sandbox resources can be reused directly without recreating and initializing the sandbox, thus achieving the continuation of the session sandbox status and reducing the time spent on sandbox cold starts and system resource consumption.

[0032] In the technical solution of this application embodiment, a sandbox name is generated using a session identifier and an agent identifier. A mutex lock is used to read the cached sandbox identifier, and a unified binding probe is performed on the target sandbox. Only after the probe passes is the sandbox reused. This solves the problem in existing technologies where sandboxes fail or belong to other sessions due to direct reuse relying solely on cache or sandbox names. By using session binding probes before reuse as a verification basis, the availability of the sandbox is double-checked from both connection and session affiliation, significantly reducing the probability of failure and erroneous reuse across sessions. Simultaneously, relying on a stable sandbox name enables continuous reuse of the same session's sandbox state, reducing the cold start overhead and resource consumption caused by repeated sandbox creation, and improving the efficiency and stability of sandbox reuse.

[0033] In an optional implementation, the step S140 of performing a preset binding detection on the target sandbox based on the existence of the cache sandbox identifier and the target sandbox corresponding to the cache sandbox identifier may include: S141. In response to the existence of the cached sandbox identifier, request the target sandbox from the sandbox service.

[0034] The sandbox service can be a backend service module responsible for sandbox creation, storage, management, and scheduling, uniformly managing the lifecycle of all local sandbox instances. For example, by verifying the cached data read in the preceding steps, if the cached sandbox identifier corresponding to the current sandbox name exists and the cached record is valid, a resource query request can be initiated to the sandbox service to retrieve the target sandbox instance corresponding to the cached identifier, obtaining the sandbox's basic information and running status, providing object support for subsequent probing.

[0035] S142. In response to the absence of a cache sandbox identifier, request the remote service to query the remote sandbox with the same name as the cache sandbox identifier.

[0036] The remote service can be a cloud service module that stores remote sandbox resources. A remote sandbox with the same name can refer to a remote sandbox instance in the remote service whose sandbox name is exactly the same as the sandbox name generated in the current session.

[0037] For example, if the verification finds that there is no corresponding sandbox identifier in the current cache and the cache is not hit, instead of creating a new sandbox directly, a retrieval request is sent to the remote service to query whether there is a remote sandbox with the same name that matches the current sandbox in the remote resource pool, so as to maximize the reuse of existing remote sandbox resources and reduce the frequency of creating new sandboxes.

[0038] S143. In response to the existence of the target sandbox, direct reuse of the target sandbox is prohibited, and the target sandbox is bound and detected.

[0039] If S141 queries the sandbox service and confirms that the target sandbox corresponding to the cache actually exists in the local sandbox service, the traditional logic of "reusing the cache as soon as it's hit" can be abandoned, and direct reuse of the target sandbox can be prohibited. It's understandable that the existence of a cache record only proves that the sandbox was created; it cannot guarantee that the sandbox's current connection is valid, not expired, or not bound to other sessions. Therefore, a binding detection process can be initiated to perform a secondary verification of the sandbox's real-time status and session ownership, thus mitigating the risk of invalid sandbox reuse from the source.

[0040] S144. In response to the absence of the target sandbox, delete the cached sandbox identifier and request the remote service to query the remote sandbox with the same name corresponding to the cached sandbox identifier.

[0041] If the query result of S141 shows that the target sandbox corresponding to the cache sandbox identifier has been destroyed, expired, or deleted, and there is no corresponding sandbox instance locally, it indicates that the current cached data is invalid and does not match the actual resource status. You can first delete the expired cache sandbox identifier locally to clean up invalid cached data and prevent subsequent requests from continuously hitting the wrong cache. Then, synchronously execute the retrieval logic of S142 to query the remote service for a remote sandbox with the same name, continuously advancing the sandbox reuse process.

[0042] The above implementation handles four scenarios in a tiered manner: presence or absence of cache, existence of the target sandbox, etc. In cases of cache loss or sandbox destruction, it automatically queries a remote sandbox with the same name and cleans up invalid cache. This solves the problems of cache data lag, cache residue after local sandbox destruction, and ignoring idle remote sandboxes when only searching the local sandbox. Automatically cleaning up invalid cache prevents subsequent requests from continuously hitting incorrect records. It also links local and remote channels to search for sandbox resources, expanding the scope of reusable sandbox searches, improving sandbox reuse hit rate, and reducing the frequency of creating new sandboxes.

[0043] In a further optional implementation, the binding detection of the target sandbox described in S143 may include: A1. Query the sandbox connection address of the target sandbox.

[0044] The sandbox connection address is the address information used for remotely connecting to, accessing, and manipulating sandbox instances; it is a fundamental parameter for establishing a sandbox communication link. By retrieving the target sandbox's configuration information, the storage status and validity information of the sandbox connection address can be accurately queried to determine whether the sandbox meets the basic conditions for remote access.

[0045] A2. In response to the sandbox connection address being empty, it is determined that the target sandbox cannot be reused.

[0046] If the A1 query result shows that the target sandbox's connection address is empty, it means that the sandbox has not completed its initialization configuration, has been reset and destroyed, or its communication configuration is lost, making it impossible to establish a remote connection or provide a normal execution environment. This indicates that the target sandbox is in an abnormal state and cannot be reused, thus terminating the current sandbox's probe process and avoiding invalid connection attempts.

[0047] A3. In response to a valid sandbox link address, establish a remote connection with a preset short time limit.

[0048] Among them, the remote connection with a preset short time limit is an ultra-short time limit connection constructed by relevant technical personnel. The specific ultra-short time limit can be set by relevant technical personnel according to the actual situation. This application embodiment does not limit this.

[0049] If query A1 retrieves a complete, non-empty, valid sandbox connection address, it indicates that the sandbox possesses the basic communication capabilities. Based on this address, a short-duration remote connection establishment operation can be initiated. By setting a shorter connection timeout, connection congestion caused by sandbox freezes or network anomalies can be avoided, thus improving the overall efficiency of the probing process.

[0050] A4. In response to the remote connection failure, it was determined that the target sandbox is not reusable.

[0051] If the short-term remote connection initiated by A3 times out, reports a connection error, or the link is interrupted, it indicates that the target sandbox is currently offline, frozen, or inaccessible due to network abnormalities, and cannot normally undertake the agent's task execution. This sandbox can be directly determined as unusable, thus excluding abnormal sandbox resources.

[0052] A5. In response to a successful remote connection, execute the preset binding detection script within the target sandbox.

[0053] The binding detection script is a lightweight detection script that can be pre-configured by relevant technical personnel. It can be edited and configured individually or generated from a complete initialization script. For example, it can retain only the core steps of session binding and status query, without redundant operations such as duplicate installation of dependencies, directory cleanup, and service startup, resulting in extremely low side effects.

[0054] For example, if the remote connection link is successfully established and control permissions to the target sandbox are obtained, a preset binding detection script is then run inside the sandbox to verify the session binding status and complete the qualification test to determine whether the sandbox can be reused.

[0055] The above implementation method performs layered verification processes for address validation, short-timed remote connections, and sandbox-based probe scripts. This addresses the shortcomings of directly reusing unverified connections and causing deadlocks, as well as offline sandboxes. First, it verifies the connection address to filter sandboxes without communication capabilities; short-timed connections prevent the probe process from blocking; and it filters inaccessible sandboxes layer by layer. This eliminates the need for meaningless full initialization operations, ensuring verification reliability while shortening probe time and reducing waste of network and computing resources.

[0056] In another alternative implementation, after executing a preset binding detection script within the target sandbox, the method may include: B1. In response to the output of the binding probe script being that the target sandbox is bound to the current session, determine to reuse the target sandbox.

[0057] Understandably, the binding detection script will output structured status results after it runs. If the script output shows that the target sandbox and the current session are in a bound state, it means that the sandbox exclusively serves the current session, the status is normal, and the ownership is correct. It can be confirmed that the sandbox can be reused normally and directly used in agent tasks.

[0058] B2. In response to the output result, the target sandbox is bound to other sessions, the reuse of the target sandbox is prohibited, and a record of session binding error is generated.

[0059] Among them, session binding error, also known as cross-session binding error, can be an abnormal state where the sandbox has been assigned to another business session.

[0060] For example, if the script output shows that the target sandbox is already bound to another session identifier, it means that the sandbox is being used by another service. Forcibly reusing it would lead to session data corruption and abnormal task execution. Therefore, the reuse of the sandbox can be directly prohibited, and standardized session binding error logs can be automatically generated for subsequent anomaly tracing and problem investigation, thus achieving traceability of anomalies.

[0061] B3. In response to the failure of the bound probe script execution or the exit code being non-zero, the reuse of the target sandbox is prohibited.

[0062] For example, if the bound detection script encounters execution failures such as program errors, process interruptions, or execution timeouts, or if the exit code returned after script execution is not 0, it indicates that the sandbox is malfunctioning and its state is uncontrollable, making it unable to stably support task execution. In such cases, the sandbox can be uniformly determined as not suitable for reuse and its reuse can be directly prohibited to avoid unknown operational risks.

[0063] The above implementation addresses the shortcomings of data confusion caused by reusing cross-session sandboxes and the failure to intercept faulty sandboxes due to abnormal script execution. It distinguishes between three types of situations: normal, cross-session occupancy, and script failure. Cross-session conflicts retain error records for easy problem tracing, comprehensively intercepts the reuse of abnormal sandboxes, ensures resource isolation between each session sandbox, and avoids mutual interference of business data.

[0064] In a further alternative implementation, the binding probe script can be determined in the following way: C1. Read the complete initialization script of the target sandbox and render the session identifier and sandbox connection address.

[0065] The complete initialization script can be a full-process script that must be executed when a new sandbox is first created. For example, the initialization script may include, but is not limited to, all initialization steps such as session binding, dependency installation, directory cleanup, and service startup.

[0066] For example, the original complete initialization script corresponding to the target sandbox can be retrieved, and dynamic variables such as the session identifier of the current session and the valid sandbox connection address can be rendered and filled into the corresponding positions of the script to achieve real-time adaptation of script parameters and ensure that the script runs in accordance with the current business scenario.

[0067] C2. Locate the preset probe end marker in the rendered complete initialization script, extract the complete initialization script from the beginning of the script to the probe end marker, and generate the bound probe script.

[0068] The probe end marker can be a segment identifier set in advance in the complete initialization script to distinguish between the core probe steps and redundant initialization steps.

[0069] For example, in the initialization script after parameter rendering is complete, a preset probe end marker is precisely located. Using this marker as a dividing point, the content from the beginning of the script to the marker position is extracted, ultimately generating a lightweight binding probe script. This script only retains the core probe logic of session binding and status query, eliminating redundant re-initialization steps such as dependency installation and service startup. It can not only complete the sandbox status verification, but also avoid repeated initialization that would damage the existing session state of the sandbox, significantly reducing the resource consumption and runtime side effects of reused probes.

[0070] In the above implementation, a lightweight binding probe script is generated by extracting the complete initialization script, retaining only the session binding-related logic. This solves the problem of repeatedly installing dependencies, resetting directories, and restarting services when executing the complete script before reuse, which disrupts the intermediate state of the original session sandbox. Reusing probes eliminates redundant re-initialization steps, significantly reducing the side effects of probe operations, preserving the historical task state within the sandbox, and simultaneously reducing the execution time and resource consumption of the probe process.

[0071] In another alternative implementation, after requesting a query from the remote service for a remote sandbox with the same name as the cache sandbox identifier, the method may include: D1. If a remote sandbox with the same name exists in the remote service, execute the preset binding detection script in the remote sandbox with the same name.

[0072] After completing the remote service retrieval, if it is confirmed that a remote sandbox with the same name matching the current sandbox exists in the remote resource pool, to avoid issues such as remote sandbox failure or abnormal ownership, the remote sandbox is not directly reused. Instead, the detection criteria of the local sandbox are used to execute the aforementioned binding detection script within the remote sandbox with the same name to verify the connection status and session ownership of the remote sandbox. The principle of its script verification is the same as in the aforementioned implementation method.

[0073] D2. In response to the successful execution of the bound probe script, reuse the remote sandbox with the same name.

[0074] If the binding detection script in the remote sandbox executes normally and the output shows that the remote sandbox is bound to the current session and the state is valid, it can be determined that the remote sandbox with the same name meets the reuse standard. The remote sandbox resources can be reused directly without creating a new sandbox, thus maximizing the use of idle remote sandbox resources.

[0075] D3. If a remote sandbox with the same name does not exist in the remote service, or if the binding probe script fails to execute, control the creation of a new sandbox.

[0076] Understandably, there are two scenarios that trigger the creation of a new sandbox: first, there is no corresponding sandbox with the same name in the remote service, and no available remote resources; second, a remote sandbox with the same name exists, but the binding probe script fails to execute, the session ownership is abnormal, or the connection is invalid, making the sandbox unusable for reuse. For both scenarios, the system automatically triggers a new sandbox creation process, completely initializing the sandbox environment to ensure that the agent's tasks can be executed normally, while avoiding the problem of persistent and repeated hits by corrupted sandboxes.

[0077] In the above implementation, a binding probe is performed before reusing a remote sandbox with the same name. If the probe fails or no remote sandbox exists, a new sandbox is created. It is understood that a name match does not prove that the remote sandbox is still connectable, nor does it prove that the remote sandbox belongs to the current session. Therefore, this implementation addresses the shortcomings of directly reusing remote sandboxes based solely on name matching and the persistent presence of faulty remote sandboxes. It reuses the unified detection standard of the local sandbox for remote resources, ensuring consistency between local and remote sandbox verification rules. When remote resources are unavailable, a new sandbox is automatically created as a fallback, ensuring uninterrupted business processes and reducing invalid requests caused by repeated searches of faulty remote sandboxes.

[0078] Example 2 Embodiment 2 of this application is a supplementary description based on the foregoing embodiments and implementation methods. For example... Figure 2A As shown, the following supplementary explanations are provided: First, generate a stable sandbox name.

[0079] First, obtain the session identifier and the optional agent identifier. If the agent identifier is empty, use the session identifier to generate the sandbox name. If the agent identifier is not empty, combine the session identifier and the agent identifier to generate the sandbox name. The same agent in the same session will get the same sandbox name, while different agents will get different sandbox names.

[0080] Second, lock the sandboxes according to their names, such as... Figure 2B As shown.

[0081] Before querying the cache, querying a remote sandbox with the same name, creating a new sandbox, and performing initialization, a mutex lock is acquired by the sandbox name. Requests that fail to acquire the lock wait or retry; if a request is cancelled, the waiting stops and a cancellation error is returned. After the lock is released, the next request rereads the cache to avoid repeated initialization based on old information.

[0082] Third, pre-use detection of cache sandboxes before reuse.

[0083] Read the cached sandbox identifier corresponding to the sandbox name. If the cache does not exist, proceed to the remote sandbox query process with the same name. If the cache exists, retrieve the corresponding sandbox from the sandbox service. If the sandbox does not exist, delete the cache and proceed to the remote sandbox query process with the same name. If the sandbox exists, do not reuse it directly, but perform a binding probe. If the probe passes, reuse the sandbox. If the probe fails, delete the corrupted sandbox or cache record and continue the recovery process.

[0084] Fourth, the same binding detection must also be performed before reusing a remote sandbox with the same name.

[0085] When a cache miss occurs or the cache sandbox is unreusable, the system queries the remote sandbox by its name. If no sandbox with the same name exists on the remote sandbox, the system proceeds to create a new sandbox. If a sandbox with the same name exists on the remote sandbox, the same binding probe is performed. If the probe succeeds, the sandbox is reused. If the probe fails, the faulty sandbox is deleted, and the system proceeds to create a new sandbox.

[0086] Fifth, lightweight binding detection script generation, such as Figure 2C As shown.

[0087] Before generating the binding probe script, the complete initialization script is read first. Necessary variables such as the session identifier and sandbox address are rendered. A pre-defined probe end marker is searched for in the complete initialization script. If the probe end marker is found, the script is truncated from the beginning to the end of that marker to form a lightweight binding probe script. The lightweight binding probe script only performs session binding or queries binding status; it does not perform re-initialization steps such as installing dependencies, cleaning directories, or starting services.

[0088] Sixth, bind the detection execution and result judgment, such as Figure 2D As shown.

[0089] Check if the sandbox connection address is empty. If empty, the sandbox is deemed unreusable. Establish a remote connection using a short timeout. If the connection fails, the sandbox is deemed unreusable. After a successful connection, execute a lightweight binding probe script within the sandbox. If the script fails to execute or the exit code is non-zero, the sandbox is deemed unreusable. If the script outputs structured results, read the binding status and session identifier. If the output indicates that it is already bound to the current session, it is deemed reusable. If the output indicates that it is already bound to another session, return a cross-session binding error and do not reuse the sandbox.

[0090] Seventh, new sandbox creation, complete initialization, and failure cleanup.

[0091] When both the cached sandbox and the remote sandbox with the same name are unreusable, a new sandbox is created. The connection address of the new sandbox is checked and a remote connection is established. The full initialization script is rendered and executed. Upon successful initialization, the sandbox is bound to the current session. If initialization fails, a cleanup context is created; the cleanup context does not inherit the cancellation signal of the original request and has an independent short timeout. The corrupted sandbox is deleted using the cleanup context. Deletion failures are only logged, without overwriting major errors.

[0092] Eighth, environment reset prompts and expiration dates should be refreshed as needed, such as... Figure 2E As shown.

[0093] After successful sandbox initialization or reuse, the sandbox name and current sandbox identifier are written to the cache. During writing, the previous sandbox identifier for that sandbox name is read. If the previous sandbox identifier exists and is different from the current sandbox identifier, an environment reset prompt is generated. If the previous sandbox identifier is empty or equal to the current sandbox identifier, no environment reset prompt is generated. The current expiration time and the target expiration time of the sandbox are read. The sandbox validity period is refreshed only if the current expiration time is earlier than the target expiration time.

[0094] In the above supplementary notes, cached or identically named sandboxes must be able to connect to and bind to the current session to reduce the probability of expired sandboxes and cross-session sandboxes being mistakenly reused. A lightweight probe script is executed during reuse, instead of a full initialization script, reducing the side effects of repeated initialization. The sandbox acquisition process under the same sandbox name is serialized to reduce duplicate creation and cache overwriting. A cleanup process is triggered after initialization or probe failure to reduce the residue of bad sandboxes. An environment reset is only prompted when the sandbox identifier changes; it is not refreshed when the validity period is sufficient, reducing unnecessary control plane calls.

[0095] Example 3 Figure 3 This is a structural schematic diagram of a sandbox reuse device provided in Embodiment 3 of this application. Figure 3 As shown, the device 300 includes: The session information acquisition module 310 is used to acquire the session identifier of the current session and at least one agent identifier corresponding to each callable agent. The sandbox name generation module 320 is used to generate a sandbox name based on the session identifier and the agent identifier; The sandbox identifier acquisition module 330 is used to acquire a mutex lock based on the sandbox name and read the cache sandbox identifier corresponding to the sandbox name from the cache. The sandbox binding detection module 340 is used to perform binding detection on the target sandbox in a preset manner based on the existence of the cached sandbox identifier and the target sandbox corresponding to the cached sandbox identifier. The target sandbox reuse module 350 is used to determine the reuse of the target sandbox in response to a pass result from the binding probe.

[0096] In the technical solution of this application embodiment, a sandbox name is generated using a session identifier and an agent identifier. A mutex lock is used to read the cached sandbox identifier, and a unified binding probe is performed on the target sandbox. Only after the probe passes is the sandbox reused. This solves the problem in existing technologies where sandboxes fail or belong to other sessions due to direct reuse relying solely on cache or sandbox names. By using session binding probes before reuse as a verification basis, the availability of the sandbox is double-checked from both connection and session affiliation, significantly reducing the probability of failure and erroneous reuse across session sandboxes. Simultaneously, relying on a stable sandbox name enables continuous reuse of the same session's sandbox state, reducing the cold start overhead and resource consumption caused by repeated sandbox creation, and improving the efficiency and stability of sandbox reuse.

[0097] In one alternative implementation, the sandbox binding detection module 340 may include: The sandbox acquisition unit is used to request the target sandbox from the sandbox service in response to the existence of a cached sandbox identifier. The remote sandbox request unit is used to request a query from the remote service for a remote sandbox with the same name as the cached sandbox identifier in response to the absence of a cached sandbox identifier. The binding detection unit is used to prevent the direct reuse of the target sandbox in response to the existence of the target sandbox, and to perform binding detection on the target sandbox; The remote request unit is used to respond to the absence of the target sandbox by deleting the cached sandbox identifier and requesting a remote service to query the remote sandbox with the same name as the cached sandbox identifier.

[0098] In one alternative implementation, the binding detection unit may include: The sandbox address query subunit is used to query the sandbox connection address of the target sandbox; The address determination subunit is used to determine that the target sandbox is not reusable in response to an empty sandbox connection address; and to establish a remote connection with a preset short time limit in response to a valid sandbox connection address. The connection judgment subunit is used to determine that the target sandbox is not reusable in response to remote connection failure; and to execute a preset binding detection script in the target sandbox in response to remote connection success.

[0099] In one alternative implementation, after executing a preset binding detection script within the target sandbox, the device may include: The session binding judgment subunit is used to determine whether to reuse the target sandbox if the output of the binding probe script indicates that the target sandbox is bound to the current session; and to prevent the reuse of the target sandbox and generate a record of session binding error if the output indicates that the target sandbox is bound to another session. The script execution judgment subunit is used to prevent the reuse of the target sandbox in response to the failure of the binding probe script execution or the non-zero exit code.

[0100] In one alternative embodiment, the apparatus further includes a binding detection script generation module, which may include: The information reading unit is used to read the complete initialization script of the target sandbox and render the session identifier and sandbox connection address; The script generation unit is used to find the preset probe end marker in the rendered complete initialization script, extract the complete initialization script from the beginning of the script to the probe end marker, and generate the bound probe script.

[0101] In another alternative implementation, after requesting a query from the remote service for a remote sandbox with the same name as the cache sandbox identifier, the apparatus may include: The remote detection module is used to execute a preset binding detection script in a remote sandbox with the same name if such a sandbox exists in the remote service. The remote reuse module is used to reuse the same remote sandbox in response to the successful execution of the bound probe script; The Sandbox Innovation module allows for the creation of a new sandbox if a remote service with the same name does not exist, or if the binding probe script fails to execute.

[0102] In yet another alternative embodiment, the apparatus may further include: The mutex release module is used to control the next request to reread the cache in response to the release of the mutex.

[0103] The sandbox reuse device provided in this application embodiment can execute the sandbox reuse method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each sandbox reuse method.

[0104] Example 4 Figure 4 A schematic diagram of an electronic device 10, which 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 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), 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.

[0105] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0106] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0107] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as sandbox multiplexing methods.

[0108] In some embodiments, the sandboxing reuse method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the sandboxing reuse method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the sandboxing reuse method by any other suitable means (e.g., by means of firmware).

[0109] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments 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.

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

[0111] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage 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. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0112] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. 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).

[0113] 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 local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0114] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0115] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the sandbox reuse method provided in any embodiment of this application. This program product and the sandbox reuse method disclosed in the embodiments of this application belong to the same inventive concept, and therefore will not be described in detail here.

[0116] 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 of this application can be achieved, and this is not limited herein.

[0117] 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 reusing sandboxes, characterized in that, include: Obtain the session identifier of the current session and at least one agent identifier corresponding to each callable agent; Generate a sandbox name based on the session identifier and the agent identifier; Based on the sandbox name, acquire a mutex lock and read the cache sandbox identifier corresponding to the sandbox name from the cache; Based on the existence of the cache sandbox identifier and the target sandbox corresponding to the cache sandbox identifier, the target sandbox is bound and detected in a preset manner; If the detection result of the binding probe is passed, it is determined that the target sandbox will be reused.

2. The method according to claim 1, characterized in that, The step of performing a preset binding detection on the target sandbox based on the existence of the cache sandbox identifier and the target sandbox corresponding to the cache sandbox identifier includes: In response to the existence of the cache sandbox identifier, request the sandbox service to obtain the target sandbox; In response to the absence of the cache sandbox identifier, a request is made to the remote service to query the remote sandbox with the same name as the cache sandbox identifier; In response to the existence of the target sandbox, direct reuse of the target sandbox is prohibited, and the target sandbox is subjected to the binding detection. In response to the absence of the target sandbox, the cached sandbox identifier is deleted, and a request is made to the remote service to query the remote sandbox with the same name corresponding to the cached sandbox identifier.

3. The method according to claim 2, characterized in that, The binding detection of the target sandbox includes: Query the sandbox connection address of the target sandbox; In response to the sandbox connection address being empty, it is determined that the target sandbox cannot be reused; In response to the sandbox link address being valid, a remote connection with a preset short time limit is established; In response to the remote connection failure, it is determined that the target sandbox is not reusable; In response to the successful remote connection, a preset binding detection script is executed within the target sandbox.

4. The method according to claim 3, characterized in that, After executing a preset binding detection script within the target sandbox, the method includes: In response to the output of the binding probe script indicating that the target sandbox is bound to the current session, it is determined that the target sandbox will be reused; In response to the output result indicating that the target sandbox is bound to other sessions, the reuse of the target sandbox is prohibited, and a record of session binding error is generated; In response to the failure of the binding probe script execution or a non-zero exit code, the reuse of the target sandbox is prohibited.

5. The method according to claim 4, characterized in that, The binding probe script is determined in the following way: Read the complete initialization script of the target sandbox and render the session identifier and sandbox connection address; In the rendered complete initialization script, find the preset probe end marker, extract the complete initialization script from the beginning of the script to the probe end marker, and generate the binding probe script.

6. The method according to claim 2, characterized in that, After requesting a query from the remote service for a remote sandbox with the same name corresponding to the cache sandbox identifier, the method includes: If a remote sandbox with the same name exists in the remote service, a preset binding detection script is executed in the remote sandbox with the same name; In response to the successful execution of the binding detection script, the remote sandbox with the same name is reused; If the remote sandbox with the same name does not exist in the remote service, or if the binding detection script fails to execute, control the creation of a new sandbox.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: In response to the release of the mutex lock, control the next request to reread the cache.

8. A sandbox reuse device, characterized in that, include: The session information acquisition module is used to acquire the session identifier of the current session and at least one agent identifier corresponding to each callable agent. The sandbox name generation module is used to generate a sandbox name based on the session identifier and the agent identifier; The sandbox identifier acquisition module is used to acquire a mutex lock based on the sandbox name and read the cached sandbox identifier corresponding to the sandbox name from the cache. The sandbox binding detection module is used to perform binding detection on the target sandbox in a preset manner based on the existence of the cached sandbox identifier and the target sandbox corresponding to the cached sandbox identifier; The target sandbox reuse module is used to determine to reuse the target sandbox in response to the detection result of the binding probe being passed.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the sandbox reuse method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the sandbox reuse method according to any one of claims 1-7.

Images