Calling method and device of AI agent instance, electronic equipment and storage medium

Abstract

The present disclosure provides a calling method and device of an AI agent instance, electronic equipment and a storage medium, relates to the technical field of artificial intelligence, in particular to the field of deep learning, natural language processing and large models, and can be used in application scenarios such as generative search, intelligent document editing, intelligent assistants, virtual assistants, intelligent e-commerce and the like. The specific implementation scheme is as follows: obtaining a user request from a user end; querying an agent management platform to determine an authorized skill list corresponding to a user identifier and a scene identifier; determining a target agent instance that is currently idle from a plurality of AI agent instances; performing a target interaction operation on the target agent instance, so that the target agent instance processes a request context based on the authorized skill list and information stored in a target directory in a specific file system, and writes a session history and related files in the target directory; obtaining a processing result obtained by the target agent instance processing the user request, and returning the processing result to the user end.

Description

Technical Field

[0001] This disclosure relates to the field of Artificial Intelligence (AI) technology, particularly to the fields of deep learning, natural language processing, and large models, and can be used in application scenarios such as generative search, intelligent document editing, intelligent assistants, virtual assistants, and intelligent e-commerce. Background Technology

[0002] In recent years, with the performance breakthroughs of Large Language Models (LLMs) and the maturity of tool invocation paradigms, AI agents have gradually evolved into widely deployed productivity units. Some AI agents running on local terminals can directly manipulate the file system, execute shell commands, and call application programming interfaces (APIs), possessing powerful capabilities and have been widely used in enterprise scenarios such as operations and maintenance, data analysis, and coding assistance. Among them, some AI agents designed for single-user local development scenarios have each instance occupying a complete runtime environment, including dialogue history, available toolsets, and working file directories. All three belong to a single user, and there is no need for isolation between them, thus making it impossible for multiple users to share AI agent instances. Deploying independent AI agent instances for each business scenario and each user would result in serious resource waste and high operation and maintenance costs. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for invoking an AI agent instance.

[0004] According to one aspect of this disclosure, a method for invoking an AI agent instance is provided, comprising: Obtain user requests from the user terminal; wherein, the user request includes user identifier, scene identifier, session identifier, and request context; Query the agent management platform to determine the list of authorized skills corresponding to the user identifier and the scene identifier; Determine the currently idle target agent instance among multiple AI agent instances; A target interaction operation is performed on the target proxy instance; wherein, the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and information stored in the target directory in a specific file system, and to write session history and related files in the target directory; the target directory is a directory associated with the user identifier, scene identifier and session identifier; Obtain the processing result obtained by the target proxy instance in processing the user request, and return the processing result to the user client.

[0005] According to another aspect of this disclosure, an apparatus for invoking an AI agent instance is provided, comprising: The request entry module is used to obtain user requests from the user terminal; wherein, the user request includes user identifier, scene identifier, session identifier and request context; The platform interaction module is used to query the agent management platform and determine the list of authorized skills corresponding to the user identifier and the scene identifier; The routing module is used to determine the currently idle target agent instance among multiple AI agent instances; The proxy interaction module is used to perform target interaction operations on the target proxy instance; wherein, the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and information stored in the target directory in a specific file system, and to write session history and related files in the target directory; the target directory is a directory associated with the user identifier, scene identifier and session identifier; The result return module is used to obtain the processing result obtained by the target proxy instance in processing the user request, and return the processing result to the user client.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is 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 any of the methods described in the present disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] This embodiment of the disclosure externalizes the dialogue history, authorized skills, and related files of the AI ​​agent instance to the agent instance itself, so that the agent instance no longer holds any user or scenario binding state. The same batch of physical instances can serve any combination of user and scenario requests on demand, so that authorized skills, conversation history, and related files are isolated from each other among multiple users, enabling multiple users to share the AI ​​agent instance, avoiding resource waste and reducing operation and maintenance costs.

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

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a schematic diagram illustrating an exemplary application scenario of an embodiment of this disclosure; Figure 2 This is a schematic diagram of a method for invoking an AI agent instance according to an embodiment of this disclosure; Figure 3 This is a schematic diagram illustrating one implementation of the target proxy instance in an embodiment of this disclosure; Figure 4 This is a schematic diagram of a four-state state machine for a sandbox instance in this embodiment of the present disclosure; Figure 5 This is a schematic diagram of a device for invoking an AI agent instance according to an embodiment of the present disclosure; Figure 6 This is a block diagram of an electronic device used to implement the method for invoking the AI ​​agent instance according to embodiments of the present disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and 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 of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] To facilitate understanding of the technical solutions disclosed herein, the relevant technologies involved in the embodiments of this disclosure are briefly described below. It should be understood that the relevant technologies described below do not limit the embodiments of this disclosure. The following relevant technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this disclosure, all of which fall within the protection scope of the embodiments of this disclosure.

[0014] First, taking CLI (Command Line Interface) agents as an example, this section details the problems associated with multiple users sharing AI agent instances. CLI agents, such as OpenCode and Claude Code, are powerful in single-user scenarios and have been widely used in enterprise scenarios such as on-call duty, analysis, and coding assistance.

[0015] However, these CLI agents implicitly assume a single-user runtime environment: each instance has its own complete runtime environment, including dialogue history, available toolsets, and working file directories, all belonging to a single user with no need for isolation. This assumption fails simultaneously in multi-user shared deployment scenarios in three dimensions: First, the memory dimension fails; dialogue history is stored locally within the process, leading to cross-contamination when multiple users share the same instance, and deploying an instance independently for each user results in significant resource waste. Second, the skill dimension fails; skill sets are loaded once at startup and remain unchanged during runtime. In enterprise scenarios, the same user requires completely different toolsets in different business scenarios, and static loading cannot dynamically tailor tool permission boundaries according to users and scenarios. Third, the file dimension fails; working directories, intermediate artifacts, analysis results, and other related files belong to a single process, and working files from different users and scenarios coexist in the same file path space, posing risks of data overwriting and cross-scenario data leakage.

[0016] The simultaneous failure of the above three dimensions means that the CLI agent cannot directly support the multi-user, multi-scenario usage needs of enterprises in a service-oriented manner.

[0017] In related technologies, there are generally three approaches to address the above-mentioned problems.

[0018] The first common approach is to deploy proxy instances independently for each scenario. Each business scenario deploys an independent proxy container cluster, maintaining its own configuration, tools, and data, without interfering with each other. In this approach, if there are N scenarios (N>1), N independent clusters are required, resulting in low resource utilization, linearly increasing operation and maintenance costs with the number of scenarios, and requiring a complete deployment process for each new scenario. Furthermore, each instance has physically independent storage, making it impossible to achieve unified session management across instances.

[0019] The second common approach involves switching roles within a single agent through prompt engineering. This involves identifying the current scenario based on user input, dynamically writing the tool descriptions and rule constraints for that scenario into the system prompt, and then using a model to understand and implement the logical switching. The drawbacks of this approach are: describing tools with prompts cannot achieve physical-level permission boundaries; the LLM might ignore prompt constraints and invoke unauthorized tools; the accumulation of complex tool descriptions leads to a decline in inference performance; the dialogue history of different users coexists in the same process context, lacking isolation mechanisms; and the working directories and files of different scenarios coexist in the same file system, posing a risk of cross-scenario data leakage.

[0020] The third common approach is to deploy a multi-namespace isolated system based on a container orchestration platform. This involves allocating an independent namespace for each scenario, using container orchestration to achieve resource and network isolation, and implementing role switching through container scheduling. For example, in a Kubernetes cluster, an independent namespace is allocated for each of the three scenarios: sorting duty, database analysis, and data flow duty. Each namespace deploys an independent agent container group (Pod), and role switching is completed through Pod scheduling. The drawbacks of this approach are: role switching requires manual triggering of container rescheduling, involving image pulling and container cold starts, with switching taking minutes and failing to achieve transparent automatic switching for users; each scenario still requires independent resource quotas, increasing operational complexity with the number of scenarios; and permission boundaries rely on namespace isolation, with granularity at the container level, making it impossible to achieve differentiated permissions for different users within the same scenario.

[0021] The embodiments disclosed herein can solve the problems in the aforementioned related technologies. Figure 1 This is a schematic diagram illustrating an exemplary application scenario of an embodiment of this disclosure. The method for invoking the AI ​​agent instance provided in this embodiment can be based on... Figure 1 The interactive system shown is implemented as follows. This interactive system may include a client 110, an encapsulation layer 120, a proxy management platform 130, a proxy instance pool 140, and a specific file system. Optionally, the specific file system may include a short-term memory service 150 and / or a remote file system 160, and the components are connected via a network 170.

[0022] Client 110 is the terminal device that initiates the request. It can be a personal computer, workstation, tablet computer, or mobile terminal. The user submits a user request containing user identifier, scene identifier, session identifier, and request context through client 110.

[0023] Encapsulation layer 120 is a middleware service deployed on the service side, responsible for receiving user requests, parsing request parameters, querying the proxy management platform, routing requests to proxy instances, and injecting context information into proxy instances. Optionally, encapsulation layer 120 can be deployed as a group of stateless microservice instances, providing a unified service entry point to the outside world through a load balancer.

[0024] The agent management platform 130 is a management system that maintains skill permission configuration information associated with users and scenarios. In one implementation, the agent management platform 130 stores the list of authorized skills for each user in each scenario using {user identifier, scenario identifier} as a composite key, and provides a query API for the encapsulation layer 120 to call.

[0025] The proxy instance pool 140 contains multiple AI proxy instances. In one implementation, each instance loads the full skill set or a scene-specific skill set, and the instance itself does not hold user binding state. In another implementation, each instance does not preload the skill set; instead, the encapsulation layer 120 loads skills for the target proxy instance corresponding to the user request when the {user identifier, scene identifier} corresponding to the user request changes.

[0026] Short-Term Memory Service 150 provides dialogue history storage services using session identifiers as isolation keys, supporting reading and writing message lists by session identifier. Remote File System 160 provides a directory structure organized by user identifier, scenario identifier, and session identifier, used for isolated storage of working files, intermediate products, and analysis results of each session, and can also be used to provide dialogue history storage services.

[0027] Network 170 can be a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), or any combination thereof.

[0028] It should be noted that the above application scenarios are merely illustrative examples, and the technical solutions provided in this disclosure are not limited to specific physical deployment topologies. For example, in one possible implementation, the external short-term memory service 150 and the remote file system 160 can be merged into a unified storage backend; in another possible implementation, the agent management platform 130 can be merged with the encapsulation layer 120 and deployed as the same service process.

[0029] Figure 2 A schematic diagram illustrating a method for invoking an AI agent instance according to an embodiment of this disclosure is shown. This method can be applied to an AI agent instance invoking device, which can be deployed in an electronic device. The electronic device is, for example, a single-machine or multi-machine terminal, server, or other processing device. In some possible implementations, the method can also be implemented by a processor invoking computer-readable instructions stored in memory. Figure 1 In the application scenario shown, this method can be executed by the encapsulation layer. For example... Figure 2As shown, the method may include the following steps S210 to S250.

[0030] S210. Obtain a user request from the user terminal; wherein, the user request includes a user identifier, a scene identifier, a session identifier, and a request context.

[0031] In the above steps, the user terminal is the terminal device or client program that initiates the request. The user request is structured request data received directly from the user terminal by the encapsulation layer, or it can be data obtained by the encapsulation layer through further processing of the structured request data received from the user terminal. For example, the user terminal can send request data to the user, which includes a user identifier, a scenario identifier, and a request context. If the request data contains a session identifier, the request context in the request data is new content that continues the existing session, and the encapsulation layer obtains the complete user request. If the request data does not contain a session identifier, the encapsulation layer can create a new session identifier to obtain the complete user request. The encapsulation layer can then return the session identifier to the user terminal (e.g., along with the processing result) so that the user terminal can continue the current session when initiating subsequent requests.

[0032] Among them, the user identifier is information that uniquely identifies the user who initiated the request. The scenario identifier is an identifier that identifies the business scenario in which the user is currently located.

[0033] In one optional implementation, the scenario identifier can be a pre-registered scenario code. For example, "sort_duty" represents the sorting duty week scenario, "db_analysis" represents the database construction analysis scenario, and "dataflow_duty" represents the data flow duty week scenario. In another optional implementation, the scenario identifier can be specified by the user when initiating a request, or automatically inferred by the encapsulation layer based on the user's historical behavior. For example, the encapsulation layer maintains a record of the scenarios recently used by the user, and when the user's request does not include a scenario identifier, the encapsulation layer automatically fills in the scenario identifier used in the user's last request as a default value.

[0034] The session identifier is a unique identifier that identifies the current dialogue session. In an optional implementation, when a user request carries a session identifier, it indicates that the user wishes to continue the existing dialogue session. For example, in a data analysis task, a user asks questions in multiple rounds: the first round of requests does not carry a session identifier, and the encapsulation layer creates a new session identifier for this round of requests using an algorithm and returns it to the user's client with the response; the user's client carries the session identifier in the second round of requests, and the encapsulation layer associates the two rounds of requests with the same session accordingly, allowing the proxy instance to access the dialogue history of the first round as a processing reference.

[0035] In an alternative implementation, the session identifier may have an expiration time. For example, the encapsulation layer sets a 24-hour expiration time for each session identifier. The session history corresponding to an expired session identifier is retained in an external short-term memory service but marked as expired. When the user initiates a request again, a new session needs to be created.

[0036] The request context is an information body describing the specific content of the user's request. In an optional implementation, the request context can be natural language text entered by the user. For example, "Please analyze the cause of yesterday's ranking service delay anomaly and generate an analysis report" is a text-based request context.

[0037] Through the above steps, this disclosure provides a unified and complete information foundation for subsequent permission queries, instance routing, memory loading, and file isolation by standardizing the definition and multi-method transmission of user identifiers, scenario identifiers, and session identifiers at the request entry point.

[0038] S220. Query the agent management platform to determine the list of authorized skills corresponding to the user identifier and the scenario identifier.

[0039] Among them, the agent management platform is a centralized management system for maintaining skill permission configuration information corresponding to users and scenarios.

[0040] For example, the agent management platform can maintain an authorization relationship table with a composite primary key consisting of user ID and scene ID. For instance, the table structure could be {user_id, scene_id, skill_list}, where user_id and scene_id form the composite primary key, and skill_list represents the corresponding list of authorized skills. It can be understood that the authorized skill list is the set of skills authorized for use by the user in that scene, where skills can be represented by identifiers; that is, the authorized skill list is stored as a set of skill identifiers.

[0041] In an alternative implementation, the authorized skill list may contain basic meta-information of the skills, not just identifiers. For example, the skill information returned by the authorized skill list may include not only skill identifiers, but also meta-information such as skill version numbers, skill descriptions, and skill invocation parameter constraints. The encapsulation layer can inject this information into the proxy instance to assist the reasoning of the large language model driven by the proxy instance.

[0042] In one optional implementation, permission changes to the authorized skill list can take effect immediately. For example, if an administrator adds a "Deployment Check" skill for user Zhang San in a data analysis scenario through the management interface of the agent management platform at 10:00 AM, Zhang San's request in the data analysis scenario arriving at 10:01 AM will immediately obtain the authorized skill list containing the newly added skill when querying the agent management platform. The permission change takes effect instantly without restarting any agent instances.

[0043] Through the above steps, this disclosure achieves on-demand dynamic determination of skill permissions by querying the authorized skill list from the agent management platform using a composite dimension of user identifier and scene identifier.

[0044] S230. Determine the currently idle target agent instance among multiple AI agent instances.

[0045] The multiple AI proxy instances form a cluster of proxy instances that are pre-started and waiting to be assigned requests, i.e., a proxy instance pool. The target proxy instance is the AI ​​proxy instance selected from the proxy instance pool that will handle the current request.

[0046] In one optional implementation, the selection of the target proxy instance can employ a round-robin strategy. For example, the encapsulation layer routing module maintains a circular pointer, sequentially allocating requests to idle instances in the proxy instance pool to ensure load balancing across instances. In another optional implementation, the selection of the target proxy instance can employ a least-connections strategy. For example, the encapsulation layer routing module counts the number of requests currently being processed by each proxy instance and always allocates new requests to the instance with the lowest current load, avoiding an imbalance where some instances are overloaded while others are idle. In yet another optional implementation, the selection of the target proxy instance can consider an affinity strategy. For example, the encapsulation layer prioritizes assigning subsequent requests from the same user in the same scenario to the proxy instance that previously processed that user's request in that scenario (if that instance is still idle), reducing the context rebuild overhead caused by instance switching.

[0047] In an optional implementation, each proxy instance in the proxy instance pool can be a proxy instance of the same type, such as all being of the source code modifiable type, or all being of the Opencode type, or all being of the source code immutable type, or all being of the Claude code type.

[0048] In an alternative implementation, each proxy instance in the proxy instance pool can be a proxy instance of a different type, such as a proxy instance of a type whose source code can be modified and a proxy instance of a type whose source code cannot be modified.

[0049] Through the above steps, this disclosure enables efficient sharing of proxy instance resources among different users and scenarios through instance pooling management, and any idle instance can handle any user's session request.

[0050] S240. Perform a target interaction operation on the target proxy instance; wherein the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and the information stored in the target directory in the specific file system, and write the session history and related files in the target directory; the target directory is a directory associated with the user identifier, the scenario identifier and the session identifier.

[0051] The target interaction operation is a series of context injections and operation instructions executed by the encapsulation layer on the target proxy instance. For example, the target interaction operation may include session identifier injection, authorized skill list injection, and working directory path injection. For instance, after determining the target proxy instance, the encapsulation layer sequentially passes the currently requested session identifier to the proxy instance via a context parameter, passes the queried authorized skill list to the proxy instance's system prompt word construction module, and passes the parsed working directory path to the proxy instance's file system operation domain configuration.

[0052] In an alternative implementation, the specific content of the target interaction operation can vary depending on the type of the proxy instance (a source code-modifiable type or a source code-unmodifiable type). For example, for an OpenCode instance with modifiable source code, the target interaction operation may also include intercepting tool call instructions initiated by the proxy instance during request processing and performing permission verification; for a Claude Code instance with unmodifiable source code, the target interaction operation may also include mounting a remote file system directory and loading skills from the skill repository according to the authorized skill list when the sandbox starts.

[0053] In an alternative implementation, the execution order of the target interaction operations can have multiple combinations. For example, session identifier injection can be completed before the proxy instance first receives the processing instruction, while authorized skill list injection and working directory path injection can be flexibly arranged at appropriate times according to the startup process of the proxy instance. This disclosure does not limit this.

[0054] The specific file system is an external storage system for storing session history and related files. In an optional implementation, the specific file system may be an external short-term memory service. In another optional implementation, the specific file system may be a remote file system. For example, the remote file system uses NFS or distributed file storage, and organizes the directory structure by {scenario identifier, user identifier}. Each directory contains a related file subdirectory (used to store intermediate files and artifacts generated during the execution of the agent instance) and / or a session history subdirectory (used to store session history files organized by session identifier).

[0055] In an alternative implementation, the specific file system can be an isolated working directory created in the local file system via the Git Worktree mechanism. For example, the wrapper layer creates an independent working tree directory for each session in the Git repository using the "git worktree add" command, with the path " / workspace / {scene identifier} / {session identifier} / ", and the working files of different sessions are physically isolated at the file system level.

[0056] The target directory is associated with the user identifier, scenario identifier, and session identifier, and is used to store the data and files of the current session. In an optional implementation, the path format of the target directory can be " / workspace / {scenario identifier} / {session identifier} / ". In an optional implementation, the target directory can be dynamically created by the encapsulation layer when a request first arrives. In an optional implementation, the target directory can be reclaimed after the session ends. For example, if the encapsulation layer detects that session "session-A001" has not received any new requests for more than 24 hours, it executes the "git worktree remove" command to reclaim the working directory. Before reclamation, the artifacts can be packaged and archived to persistent storage or directly cleaned up to free up disk space.

[0057] Through the above steps, this disclosure injects the authorized skill list, historical information in the target directory, and the current request context into the target proxy instance via target interaction operations. This allows the proxy instance to obtain all the context required to process the current request without any state. Permission boundaries are defined by the authorized skill list, dialogue continuity is guaranteed by the historical information in the target directory, and file isolation is achieved through the physical independence of the target directory. This simultaneously achieves the technical goals of access control, memory continuity, and file isolation within a single request processing. Furthermore, the proxy instance itself does not hold any user or scenario-bound state and can immediately serve other users' requests after processing, achieving efficient reuse of instance resources.

[0058] S250. Obtain the processing result obtained by the target proxy instance in processing the user request, and return the processing result to the user.

[0059] The processing result is the result obtained by the target agent instance based on the authorized skill list and the information stored in the target directory to process the request context. It is the output information generated by the target agent instance after completing inference and tool invocation.

[0060] In an alternative implementation, the processing result may include both a text response and a list of document outputs.

[0061] In the above method, the invocation process of the proxy instance is organized using three dimensions: user identifier, scenario identifier, and session identifier. The three mutable states of the proxy instance—dialogue history, tool permissions, and working files—are all externalized to the proxy instance itself. The proxy instance no longer holds any user or scenario-bound state, and the same batch of physical instances can serve requests from any combination of users and scenarios on demand. Dialogue history is naturally isolated between different users and sessions, avoiding the problem of history contamination when multiple users share the same instance, thus improving the interactive experience and data security in multi-tenant scenarios. Tool permission boundaries are dynamically tailored according to users and scenarios, and permission changes take effect immediately, improving the flexibility of tool permission management in multiple enterprise scenarios. Working files are physically isolated at the file system layer, solving the problem of cross-scenario data leakage and data isolation in the computer domain.

[0062] In some embodiments, the target interaction operation may include: sending a session identifier along with the request context to the target proxy instance; wherein the session identifier is used by the target proxy instance to read and write session history in the target directory of the short-term memory service by calling the storage provider interface.

[0063] The above embodiments can be applied to AI proxy instances of the source code modifiable type. In an optional implementation, when the target proxy instance is an AI proxy instance of the source code modifiable type, the session identifier is sent to the target proxy instance along with the request context, so that the target proxy instance can read and write session history in the target directory of the short-term memory service by calling the storage provider interface. Optionally, developers can introduce a storage abstraction layer of the provider pattern between the storage module of the AI ​​proxy instance and the business call, so that the AI ​​proxy instance can read and write session history in the target directory of the short-term memory service by calling the storage provider interface.

[0064] Figure 3 This is a schematic diagram illustrating one implementation of the target proxy instance in an embodiment of this disclosure. For example... Figure 3As shown, a storage abstraction layer, namely the StorageProvider interface 310, can be integrated into the source code of the target proxy instance. This interface replaces the original local file storage implementation of the proxy instance. In an optional implementation, the storage abstraction layer communicates with different types of external short-term memory services through MySQL Provider 320 and / or REST API Provider 330. For example, each time the StorageProvider interface 310 is called, the REST API Provider 330 passes the session identifier to the external short-term memory service in the format of X-Session-ID: {session_id} header, which then isolates the conversation history of different users according to the session identifier.

[0065] In some embodiments, the internal data structure of the short-term memory service is organized in a three-layer granularity: session, message, and part. A part is the smallest storage unit written immediately after each tool call step in a single response by the AI ​​agent instance. This embodiment supports the agent instance resuming execution from the part granularity after an interruption. In an optional embodiment, the original internal storage structure of the AI ​​agent instance is a three-layer structure of session, message, and part, which naturally aligns with the above data structure and can directly interface with the short-term memory service.

[0066] It's important to note that the session identifier is dynamically injected into the target proxy instance via the request, rather than being permanently assigned as a startup parameter. This design allows the same proxy instance to serve different users' sessions in different requests. For example, after processing user A's session request, it can immediately process different session requests from user B, simply by having the encapsulation layer inject the corresponding session identifier into each request. When subsequent requests for the same session are routed to different proxy instances, the new instance loads the existing complete dialogue history from an external short-term memory service using the session identifier carried in the request. The context continues seamlessly, and the new instance is completely transparent to the user, unaware of whether the session has been handled by other instances.

[0067] As can be seen from the above embodiments, the session history of the same proxy instance serving multiple users can be completely isolated, thus solving the problem of mutual contamination of the session history of different users in the same process context.

[0068] In an alternative implementation, switching the storage provider interface is achieved by modifying only one configuration item. All storage calls in the proxy instance business code do not need to be modified, and all the modification code is concentrated inside the storage module.

[0069] In some embodiments, the target interaction operation includes sending a list of authorized skills along with the request context to a target proxy instance. This list of authorized skills is used by the target proxy instance to construct prompts for driving a large model (LLM). Specifically, the list of authorized skills can be used by the target proxy instance to add constraint information to the prompts indicating that only skills in the authorized skill list can be used.

[0070] The above embodiments can be applied to AI proxy instances of the source code modifiable type. In an optional implementation, when the target proxy instance is an AI proxy instance of the source code modifiable type, an authorized skill list is sent to the target proxy instance along with the request context, so that the target proxy instance can construct prompt words for driving the LLM based on the authorized skill list.

[0071] In an optional implementation, the target proxy instance preloads the full skill set and reads the authorized skill list when constructing the system prompt word in the request context to determine the range of available skills. This range of available skills is then injected as a constraint prefix into the system prompt word. For example, if the authorized skill list is ["skill_log_query", "skill_metric_analysis"], the system prompt word will include the constraint statement: "In this session, you may only use the following skills: skill_log_query (for querying service logs) and skill_metric_analysis (for analyzing monitoring metrics). Do not attempt to use other skills."

[0072] The above embodiments enable the LLM to proactively perceive permission boundaries by adding skill usage constraint information to the prompt words of the target proxy instance. During the inference process, the LLM does not attempt to generate calls for unauthorized skills, thereby achieving dynamic tailoring of skill permission boundaries according to users and scenarios and solving the problem of cross-scenario skill isolation.

[0073] In some embodiments, the target interaction operation further includes: intercepting tool invocation instructions initiated by the target proxy instance to an external tool platform; and verifying the permissions of the tool invocation instructions based on the authorized skill list.

[0074] For example, the encapsulation layer can employ a two-layer control strategy. The first layer is permission injection at the inference layer, which adds constraint information for skill usage to the prompts of the target proxy instance. The second layer is that the encapsulation layer intercepts tool calls initiated by the target proxy instance to an external tool platform and verifies the permissions of the tool call command based on the authorized skill list. If the skill targeted by the tool call command is in the authorized skill list, execution is allowed and the call result is returned to the proxy instance; otherwise, the call is intercepted and an insufficient permission prompt is returned to the proxy instance.

[0075] In one alternative implementation, permission verification can be implemented using string matching. For example, if the skill identifier carried in the tool invocation command is "skill_alert_rule", the encapsulation layer searches for this identifier in the authorized skill list, and if it is not matched, it blocks the process. In another alternative implementation, permission verification can be implemented using regular expressions or prefix matching to support hierarchical organization of skill identifiers.

[0076] The above embodiments enable the target proxy instance to actively perceive the permission boundary through inference layer permission injection, avoid invalid attempts from the source of inference, and provide a mandatory security fallback through tool call interception. This not only enables dynamic tailoring of skill permission boundaries according to users and scenarios, but also solves the problems of unreliable prompt permission control and the risk of cross-scenario data leakage.

[0077] In some embodiments, the target interaction operation includes: sending the path of a target directory in an external file system along with the request context to the target proxy instance; wherein the path is used by the target proxy instance to read and write relevant files in the target directory in the external file system. It can be understood that the target directory in the external file system is the directory in the external file system associated with the user identifier, the scenario identifier, and the session identifier.

[0078] In an optional implementation, the encapsulation layer can create the target directory in an external file system. Specifically, when a user request arrives, the encapsulation layer determines the target directory based on the session identifier; if the target directory does not exist, it is created. Furthermore, by modifying the source code of the target proxy instance, when the encapsulation layer sends the request context and the path to the target directory to the target proxy instance, the target proxy instance can restrict all file operations in the session to the target directory. Through the above embodiments, physical isolation of working files for different users and in different scenarios can be achieved.

[0079] In an alternative implementation, the encapsulation layer may clean up the target directory at the end of the session.

[0080] In some embodiments, the method for invoking the AI ​​agent instance described above may further include: creating a target directory in a Git repository on an external file system using Git commands based on a session identifier.

[0081] For example, the encapsulation layer creates a target directory in a Git repository on an external file system using Git commands based on the session identifier. The encapsulation layer sends the request context and the path of the target directory to the target proxy instance. The target proxy instance restricts all file operations in the session to the target directory. When the session ends, the encapsulation layer can archive the relevant files and clean up the target directory using Git commands.

[0082] In a specific application example, the encapsulation layer utilizes Git's native Git Worktree mechanism to allocate a physically isolated independent working tree for each session. Specifically, when a request arrives, the encapsulation layer determines the working directory path based on the session identifier, in the format " / workspace / {scene identifier} / {session identifier} / ". If the target path does not exist, the encapsulation layer executes the Git command "git worktree add / workspace / {scene identifier} / {session identifier} / -b session-{session identifier}", creating a new branch corresponding to the session in the Git repository and checking it out to the isolated working directory. The encapsulation layer injects this working directory path into the target proxy instance along with the request context, restricting all file operations of the proxy instance within this session to this directory. When the session ends, the encapsulation layer executes the Git command "git worktree remove / workspace / sort_duty / session-A001 / " to reclaim the working tree, optionally packaging and archiving the artifacts before reclamation. The working tree created by GitWorktree is essentially a regular local directory. All read and write operations on the file system (creating, modifying, deleting files, etc.) performed by the proxy instance within this directory are done using standard file system calls, without needing to be changed to Git commands. The proxy instance source code requires no modifications for this purpose. Git commands are only used for two lifecycle nodes of the working tree: "git worktree add" to allocate the directory during creation, and "git worktree remove" to clean up the directory during recycling. At other times, the directory behaves like a normal directory.

[0083] Compared to creating a separate directory copy for each session, the above approach has the following additional advantages: sharing git history and object storage saves disk space, and changes to each session are naturally isolated. After a session ends, changes can be merged, archived, or discarded, making full use of Git version control capabilities.

[0084] In some embodiments, the target interaction operation may include: mounting a directory in the remote file system corresponding to the user identifier and the scenario identifier to the local path of the target proxy instance, so as to convert the information read and write performed by the target proxy instance in the local path according to the session identifier into information read and write performed in the directory according to the session identifier.

[0085] The above embodiments can be applied to AI proxy instances whose source code cannot be modified. In an optional implementation, when the target proxy instance is an AI proxy instance whose source code cannot be modified, the directory corresponding to the user identifier and scene identifier in the remote file system is mounted to the local path of the target proxy instance. When the target proxy instance reads and writes information in the local path according to the session identifier (i.e., the target proxy instance performs normal information read and write), it is actually reading and writing information in the directory corresponding to the user identifier and scene identifier in the remote file system according to the session identifier. The target proxy instance is completely unaware of the existence of the remote file system.

[0086] In an optional implementation, the directory structure in the remote file system is organized as " / {scene identifier} / {user identifier} / ", with each directory containing two subdirectories: a workspace subdirectory for storing intermediate files, analysis artifacts, and processing results generated during agent instance execution, and a memory subdirectory for storing the user's dialogue history files in that scenario, further organized into subfiles by session identifier. The AI ​​agent instance is deployed within a sandbox, and the encapsulation layer executes a mount command to map the directory in the remote file system to the " / local / agent / " path within the sandbox. All subsequent file read and write operations of the AI ​​agent instance are transparently performed on the isolated directory on the remote file system. The workspace and memory subdirectories for different users and scenarios are physically separated at the storage layer. The agent instance within the sandbox can only access the single mounted directory and cannot access data from other users or other scenarios.

[0087] The above embodiments achieve complete isolation of historical and working files of different users and different scenarios when the same agent instance serves multiple users through transparent mounting of remote file systems. This avoids cross-scenario leakage and delayed read / write issues, eliminates the need to allocate agent instances to each user separately, reduces operation and maintenance costs, and minimizes resource waste.

[0088] In some embodiments, the target interaction operation further includes: in response to detecting that either the user identifier or the scene identifier is not the identifier associated with the previous processing of the target proxy instance, unmounting the directory on the local path of the target proxy instance.

[0089] Specifically, the encapsulation layer can unmount the directory on the local path of the target proxy instance when it detects that either the user identifier or the scene identifier is not the identifier associated with the previous processing of the target proxy instance—that is, when either the user identifier or the scene identifier has changed. In this way, by performing directory unmounting and mounting during role switching, the working directory and the memory directory can be switched synchronously during role switching. The timing design of this directory unmounting and mounting ensures isolation and avoids invalid unmounting and mounting, thereby preventing resource waste.

[0090] In some embodiments, the target interaction operation includes: retrieving each skill from the authorized skill list in the skill repository; restarting the target agent instance, and loading each skill for the target agent instance during the restart process.

[0091] The above embodiments can be applied to AI proxy instances whose source code cannot be modified. In an optional implementation, if the target proxy instance is an AI proxy instance whose source code cannot be modified, the encapsulation layer retrieves each skill from the authorized skill list in the skill repository; restarts the target proxy instance, and loads each skill for the target proxy instance during the restart process. That is, for proxy instances whose source code cannot be modified, skill permission control is implemented during the proxy instance restart loading phase. The encapsulation layer can query the proxy management platform using {user identifier, scene identifier} as the key when switching roles (i.e., when neither the current user identifier nor the scene identifier is associated with the last processing of the target proxy instance) to obtain the authorized skill list for that user in that scene. The encapsulation layer retrieves each skill from the authorized skill list in the skill repository, and then loads these skills for the target proxy instance during the restart process.

[0092] In one optional implementation, the skill repository is a centrally managed repository of skill code containing all skills that might be used in all business scenarios of the enterprise. The encapsulation layer pulls only the authorized skill code files from the skill repository according to the authorized skill list and places them into the skill loading path within the sandbox. When the proxy instance starts, it can only load skills located in this path, thus achieving physical boundary of permissions during the loading phase. For example, if the authorized skill list is ["skill_log_query", "skill_metric_analysis"], the encapsulation layer pulls the code files corresponding to these two skills from the skill repository to the " / skills / " directory in the sandbox. After the proxy instance starts, it can only use these two skills and cannot be aware of or invoke the existence of other skills in the repository.

[0093] The above embodiments achieve dynamic trimming of the available skill set by loading a skill list, and realize the dynamic determination of the skill availability boundary according to user identifier and scene identifier, thus solving the problems of unreliable prompt permission control and the risk of cross-scene data leakage.

[0094] To facilitate understanding of the above technical solution, an application example is provided below. When the encapsulation layer detects that the user identifier or scene identifier in the user request is inconsistent with the identifier associated with the target proxy instance in the previous processing, it automatically triggers a role switching process. Specifically, the encapsulation layer executes the following sequentially: Retrieve the complete configuration of the target scenario from the agent management platform (including the list of authorized skills, model parameters, and prompt word configuration); Stop the current target agent instance process within the sandbox; Unmount the original {scene identifier} / {user identifier} directory of the target proxy instance and mount the {scene identifier} / {user identifier} directory of the current request; Load the target scene's exclusive skills from the skill repository according to the configuration list, i.e., the skills in the authorized skill list; Restart the agent instance process with the new scenario configuration.

[0095] In the application examples above, the entire switching process is triggered automatically without manual intervention. The switching time depends on the skill loading time, which is usually completed in seconds, far better than the minute-level latency of container cold start.

[0096] In some embodiments, the proxy instance pool can maintain an instance status table to record the current status (idle, processing, offline) and the most recently processed request information of each proxy instance. For example, if five OpenCode instances are deployed in the proxy instance pool, the status table shows that instance A is in the "idle" state and recently processed the "sort_duty" request for user "zhangsan", instance B is in the "processing" state and is currently processing the request for user "lisi", and instances C, D, and E are all in the "idle" state. The routing module of the encapsulation layer selects one of the idle instances as the target proxy instance.

[0097] In an optional implementation, the proxy instance pool can support elastic scaling. For example, when all 5 instances in the proxy instance pool are in a "processing" state and the queue of pending requests exceeds 10, the proxy instance pool automatically starts 2 new proxy instances to cope with peak concurrency; when the number of concurrent requests drops and the number of idle instances remains above 3 for more than 5 minutes, the proxy instance pool automatically reclaims excess instances to release computing resources.

[0098] In an alternative implementation, for proxy instances whose source code cannot be modified (such as claude code), the proxy instance pool can employ a sandbox pooling mechanism for state management. The lifecycle of a sandbox instance is managed by a four-state state machine. See also Figure 4 , Figure 4 The diagram illustrates a state machine diagram of a sandbox instance in four states: Pending Allocation, Loading, Running, and Reclaiming. A sandbox instance waits for allocation requests in the "Pending Allocation" state. After being allocated, it enters the "Allocated" state and begins mounting the corresponding directory and loading skills. Once ready, it enters the "Running" state to process requests. After processing, if no new requests allocate the instance within a preset time, it enters the "Reclaiming" state to release resources. After reclamation, it returns to the "Pending Allocation" state and is re-entered into the pool. At system startup, a pre-warming mechanism can be used to pre-create a batch of sandbox instances in the "Pending Allocation" state to eliminate cold start latency when new requests arrive. The number of sandboxes dynamically increases or decreases based on concurrent request volume; it automatically expands when idle instances are insufficient and shrinks to release resources when idle instances continuously exceed a threshold. If a sandbox remains idle for more than the configured time, it automatically enters the reclamation process, releasing memory resources and returning to the "Pending Allocation" state before being re-entered into the pool.

[0099] In some embodiments, the authorized skills list includes baseline skills associated with scene identifiers and approved skills corresponding to user identifiers and scene identifiers.

[0100] Optionally, whether for AI agent instances of the type whose source code cannot be modified or for AI agent instances of the type whose source code can be modified, the authorized skill list can include the baseline skills associated with the scene identifier and the approved skills corresponding to the user identifier and the scene identifier.

[0101] According to the above embodiments, the composition of the authorized skill list follows a specific permission model, which is: the authorized skill list is equal to the union of the scenario baseline skill set and the user's additional authorization set (actual available skill set = scenario baseline skill set ∪ user's additional authorization set). For example, the baseline skill set for a data analysis scenario includes log query skills and monitoring indicator analysis skills. If user Zhang San is approved to additionally obtain the alarm rule editing skill in the data analysis scenario, then the authorized skill list for this user in the data analysis scenario is ["log query skills", "monitoring indicator analysis skills", "alarm rule editing skills"].

[0102] This disclosure provides multiple implementation routes determined by source code modifiability by allocating target agent instances using a composite routing key composed of user identifiers and scenario identifiers, along with external memory and file directories. In enterprise multi-user, multi-scenario agent service scenarios, it simultaneously achieves complete memory isolation, precise skill permission control, and physical isolation of working files with a single physical infrastructure. Compared to independent deployment by scenario, this solution compresses the infrastructure scale from linear growth with the number of scenarios to a fixed scale, significantly reducing the total cost of ownership for enterprises deploying AI agent instances. Compared to the prompt engineering solution, the isolation boundary is enforced at the architecture level, providing stronger security and compliance guarantees. The access of new business scenarios is simplified from "deploying a new cluster" to "registering platform configuration," providing a sustainable and scalable technical foundation for enterprises to scale up the promotion of AI agent instances.

[0103] Figure 5 This is a schematic diagram of a device for invoking an AI agent instance according to an embodiment of this disclosure. Figure 5 As shown, the device includes: The request entry module 510 is used to obtain user requests from the user terminal; wherein, the user request includes user identifier, scene identifier, session identifier and request context; The platform interaction module 520 is used to query the agent management platform and determine the list of authorized skills corresponding to the user identifier and the scene identifier. Routing module 530 is used to determine the currently idle target agent instance among multiple AI agent instances; The proxy interaction module 540 is used to perform target interaction operations on the target proxy instance; wherein, the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and the information stored in the target directory in the specific file system, and to write the session history and related files in the target directory; the target directory is a directory associated with the user identifier, scene identifier and session identifier; The result return module 550 is used to obtain the processing result obtained by the target proxy instance in processing the user request and return the processing result to the user.

[0104] In some embodiments, the agent interaction module 540 is used for: The session identifier is sent along with the request context to the target proxy instance; the session identifier is used by the target proxy instance to read and write session history in the target directory of the short-term memory service by calling the storage provider interface.

[0105] In some embodiments, the agent interaction module 540 is used for: The list of authorized skills is sent to the target proxy instance along with the request context; the list of authorized skills is used by the target proxy instance to build prompt words that drive the larger model.

[0106] In some embodiments, the agent interaction module 540 is further configured to: Intercept tool call commands initiated by the target proxy instance to an external tool platform; The permissions of tool call commands are verified based on the list of authorized skills.

[0107] In some embodiments, the agent interaction module 540 is used for: The path to the target directory in the external file system is sent to the target proxy instance along with the request context; the path is used by the target proxy instance to read and write relevant files in the target directory in the external file system.

[0108] In some embodiments, the agent interaction module 540 is used for: Based on the session identifier, use Git commands to create the target directory in the Git repository on the external file system.

[0109] In some embodiments, the agent interaction module 540 is used for: Mount the directory corresponding to the user identifier and scenario identifier in the remote file system to the local path of the target proxy instance, so as to convert the information read and write of the target proxy instance in the local path according to the session identifier into information read and write according to the session identifier in the directory.

[0110] In some embodiments, the agent interaction module 540 is used for: In response to the detection that either the user identifier or the scene identifier is not the identifier associated with the previous processing of the target proxy instance, the directory mount on the local path of the target proxy instance is unmounted.

[0111] In some embodiments, the agent interaction module 540 is used for: Retrieve each skill from the list of authorized skills in the skill repository; Restart the target proxy instance and load the various skills for the target proxy instance during the restart process.

[0112] In some embodiments, the authorized skills list includes baseline skills associated with scene identifiers and approved skills corresponding to user identifiers and scene identifiers.

[0113] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0114] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

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

[0116] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure 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 assistants, 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 present disclosure described and / or claimed herein.

[0117] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

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

[0119] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 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 computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the method of invoking an AI agent instance. For example, in some embodiments, the method of invoking an AI agent instance may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method of invoking an AI agent instance described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the method of invoking an AI agent instance by any other suitable means (e.g., by means of firmware).

[0120] 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), systems-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.

[0121] The program code used to implement the methods of this disclosure 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 apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be 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.

[0122] In the context of this disclosure, 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, 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.

[0123] 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).

[0124] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user 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., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0125] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0126] 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 disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0127] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. 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 principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for invoking an AI agent instance, comprising: Obtain user requests from the user terminal; wherein, the user request includes user identifier, scene identifier, session identifier, and request context; Query the agent management platform to determine the list of authorized skills corresponding to the user identifier and the scene identifier; Determine the currently idle target agent instance among multiple AI agent instances; A target interaction operation is performed on the target proxy instance; wherein, the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and information stored in the target directory in a specific file system, and to write session history and related files in the target directory; the target directory is a directory associated with the user identifier, scene identifier and session identifier; Obtain the processing result obtained by the target proxy instance in processing the user request, and return the processing result to the user client.

2. The method according to claim 1, wherein, The target interactive operation includes: The session identifier is sent to the target proxy instance along with the request context; wherein, the session identifier is used by the target proxy instance to read and write session history in the target directory of the short-term memory service by calling the storage provider interface.

3. The method according to claim 1 or 2, wherein, The target interactive operation includes: The list of authorized skills is sent to the target proxy instance along with the request context; the list of authorized skills is used by the target proxy instance to construct prompt words to drive the large model.

4. The method according to claim 3, wherein, The target interactive operation also includes: Intercept the tool call instructions initiated by the target proxy instance to an external tool platform; The permissions of the tool invocation commands are verified based on the authorized skill list.

5. The method according to any one of claims 1-4, wherein, The target interactive operation includes: The path to the target directory in the external file system is sent to the target proxy instance along with the request context; wherein the path is used by the target proxy instance to read and write relevant files in the target directory in the external file system.

6. The method according to claim 5, wherein, The method further includes: Based on the session identifier, the target directory is created in the Git repository on the external file system using Git commands.

7. The method according to claim 1, wherein, The target interactive operation includes: Mount the directory corresponding to the user identifier and scenario identifier in the remote file system to the local path of the target proxy instance, so as to convert the information read and write performed by the target proxy instance in the local path according to the session identifier into information read and write performed according to the session identifier in the directory.

8. The method according to claim 7, wherein, The target interactive operation also includes: In response to detecting that either the user identifier or the scene identifier is not the identifier associated with the previous processing of the target proxy instance, the directory mount on the local path of the target proxy instance is unmounted.

9. The method according to claim 1, 7 or 8, wherein, The target interactive operation includes: Retrieve each skill from the authorized skill list in the skill repository; Restart the target proxy instance, and load the skills for the target proxy instance during the restart process.

10. The method according to any one of claims 1-9, wherein, The authorized skill list includes the baseline skills associated with the scene identifier and the approved skills corresponding to the user identifier and the scene identifier.

11. A device for invoking an AI agent instance, comprising: The request entry module is used to obtain user requests from the user terminal; wherein, the user request includes user identifier, scene identifier, session identifier and request context; The platform interaction module is used to query the agent management platform and determine the list of authorized skills corresponding to the user identifier and the scene identifier; The routing module is used to determine the currently idle target agent instance among multiple AI agent instances; The proxy interaction module is used to perform target interaction operations on the target proxy instance; wherein, the target interaction operation is used to enable the target proxy instance to process the request context based on the authorized skill list and information stored in the target directory in a specific file system, and to write session history and related files in the target directory; the target directory is a directory associated with the user identifier, scene identifier and session identifier; The result return module is used to obtain the processing result obtained by the target proxy instance in processing the user request, and return the processing result to the user client.

12. 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 executable 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 of any one of claims 1-10.

13. 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-10.

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

Images