Cloud host management method, device and medium

Abstract

The embodiment of the application provides a cloud host management method, device and medium, wherein the method comprises: creating a task by using a time triggering mechanism and an event triggering mechanism; task information of the task comprises: task resources; determining a first target field intelligent agent corresponding to the task according to the task information by using a task planning intelligent agent; detecting the task resources corresponding to the task by using the first target field intelligent agent; wherein the first target field intelligent agent determines a first target tool identifier according to a mapping relationship between a field intelligent agent and a tool identifier, and obtains a target tool instance corresponding to the first target tool identifier from a registration table to detect the task resources corresponding to the task; and generating a suggestion notification according to a task processing result. The embodiment of the application can effectively improve the timeliness, integrity and accuracy of cloud host management under the condition of reducing the cost of manual operation and processing delay, and can enhance the adaptability to different management requirements.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of cloud computing technology, and in particular to a method, apparatus and medium for managing cloud hosts. Background Technology

[0002] In the field of cloud computing, cloud server management refers to the control and management of the entire process of cloud servers from creation, startup, operation, configuration changes to final deletion. It is used to realize the dynamic scheduling and on-demand allocation of computing and storage resources involved in cloud servers, improve overall resource utilization, reduce idle costs, support failover or rapid reconstruction in the event of hardware failure or system anomalies to shorten business downtime, and achieve fine-grained cost control by dynamically adjusting instance specifications in conjunction with real-time load monitoring.

[0003] Current cloud server management methods typically manage cloud servers based on user-submitted operation requests. For example, by calling an application programming interface (API) and passing in operation parameters such as the resource pool ID, availability zone name, and instance ID of the target cloud server, operations such as creation, startup, pause, restart, reinstallation, or deletion can be performed on the target cloud server.

[0004] Under current cloud server management methods, users need to check resource status to determine whether a subscription is due for renewal or is idle due to low load. This process is not only time-consuming and labor-intensive, but also prone to omissions. If these omissions occur, low load idleness will result in wasted resources, while failure to renew upon expiration will cause service interruptions. Summary of the Invention

[0005] This invention provides a cloud server management method, device, and medium that can effectively improve the timeliness, completeness, and accuracy of cloud server management while reducing manual operation costs and processing latency, and enhance adaptability to different management needs.

[0006] In a first aspect, embodiments of the present invention disclose a method for managing cloud servers, the method comprising:

[0007] Tasks are created using time-triggered and event-triggered mechanisms; the task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events;

[0008] Using a task planning agent, a first target domain agent corresponding to the task is determined based on the task information;

[0009] Using the first target domain agent, the task resources corresponding to the task are detected to obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task;

[0010] Based on the task processing results, a suggestion notification is generated;

[0011] The aforementioned suggestion notification will be processed.

[0012] Secondly, embodiments of the present invention disclose a cloud server management device, the device comprising:

[0013] The task creation module is used to create tasks using time-triggered and event-triggered mechanisms. The task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events.

[0014] The first task planning module is used to utilize the task planning agent to determine the first target domain agent corresponding to the task based on the task information.

[0015] The task processing module is used to use the first target domain agent to detect the task resources corresponding to the task and obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry to detect the task resources corresponding to the task;

[0016] The suggestion generation module is used to generate suggestion notifications based on the task processing results.

[0017] The suggestion processing module is used to process the suggestion notification.

[0018] Thirdly, embodiments of the present invention disclose an electronic device, including a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the aforementioned method.

[0019] Fourthly, embodiments of the present invention disclose a non-transitory computer-readable storage medium storing instructions that cause a processor to execute the aforementioned method.

[0020] Compared with the prior art, the embodiments of the present invention have the following advantages:

[0021] This invention provides an automated process from task creation to cloud server management. In this automated process, tasks are first automatically created using time-triggered and event-triggered mechanisms. The time-triggered mechanism initiates resource status checks at preset intervals, while the event-triggered mechanism monitors preset events such as cloud platform resource status changes and threshold alarms in real time. Then, a task planning agent determines a first target domain agent corresponding to the task. This first target domain agent automatically detects the resources covered by the task, identifying and judging preset states such as expired renewals and low-load idle periods, and processing preset events. Since this automated process requires no manual intervention, it achieves automated management of cloud server resource status and preset events, significantly reducing manual operation costs and processing latency while effectively improving the timeliness, completeness, and accuracy of cloud server management.

[0022] Secondly, this embodiment of the invention adopts an architecture where task planning agents and domain agents work collaboratively. The task planning agent is responsible for task scheduling and agent matching, while the domain agent is responsible for executing the detection logic of its corresponding domain. This separation of responsibilities reduces the coupling between agents and improves the flexibility and scalability of the task processing flow. Simultaneously, based on the agent allocation method for different domains, the judgment of different cloud host states, such as renewal upon expiration and low-load idleness, is handled by a dedicated domain agent, thereby improving the professionalism, accuracy, and overall processing efficiency of state management.

[0023] Furthermore, in this embodiment of the invention, the first target domain agent determines the first target tool identifier based on the mapping relationship between the domain agent and the tool identifier, and retrieves the target tool instance corresponding to the first target tool identifier from the registry to detect the task resources corresponding to the task. When a new tool needs to be introduced, the tool instance of the new tool can be registered in the registry without modifying the processing logic of the domain agent and the task planning agent. The above technical means realize the dynamic loading and plug-and-play functionality of tools, significantly enhancing the adaptability to different management needs.

[0024] Furthermore, embodiments of the present invention can automatically generate suggested notifications based on task processing results. These notifications may include suggestions for merging low-load instances, reminders for expired renewals, and solutions for handling anomalies. Responses to these notifications can be proactively sent to target users via push notifications or other methods, alerting them to low resource load, impending expiration, or anomaly statuses. This allows users to take preventative or timely measures to avoid resource waste, prevent business interruptions, and control the scope of event impact, thereby improving cloud server resource utilization and reducing additional costs incurred due to management delays or oversights. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the steps of a cloud server management method according to an embodiment of the present invention;

[0026] Figure 2 This is a flowchart illustrating a cloud server management method according to an embodiment of the present invention;

[0027] Figure 3 This is a flowchart illustrating a cloud server management method according to an embodiment of the present invention;

[0028] Figure 4 This is a flowchart illustrating a cloud server management method according to an embodiment of the present invention;

[0029] Figure 5 This is a schematic diagram of the structure of a cloud host management device according to an embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of the structure of an electronic device 1100 according to an embodiment of the present invention. Detailed Implementation

[0031] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] In this embodiment of the invention, a cloud server is a virtual server based on cloud computing technology. Cloud servers pool the resources of a physical server cluster through virtualization technology, allowing users to flexibly configure CPU, memory, storage, and network as needed, and to quickly create and manage them. The advantage of cloud servers lies in their elastic scaling; the resource scale can be dynamically adjusted according to changes in business needs, enabling pay-as-you-go usage and thus reducing IT (information technology) costs. A cloud server is an instance of elastically allocable computing resources based on virtualization technology, including computing, storage, and network resources. It can be created, started, paused, restarted, reinstalled, or deleted as needed, and is a core component of cloud computing IaaS (Infrastructure as a Service).

[0033] The embodiments of this invention do not limit the specific application scenarios of the cloud host management method. For example, the method can be applied to enterprise-level cloud resource operation and maintenance scenarios, elastic scaling of business systems, permission and lifecycle control scenarios in multi-tenant environments, industry scenarios with high compliance requirements such as government cloud and financial cloud, and automated deployment and fault repair scenarios of distributed application clusters.

[0034] Among them, enterprise-level cloud resource operation and maintenance scenarios are used to achieve centralized monitoring, unified management and daily maintenance of cloud hosts; business system elastic scaling scenarios are used to adjust the number of cloud host instances and resource configurations in real time and automatically according to business load; permission and lifecycle management scenarios in multi-tenant environments are used to achieve resource isolation between tenants and to manage the creation, operation and release of cloud hosts throughout their entire lifecycle; industry scenarios with high compliance requirements such as government cloud and financial cloud are used to achieve compliance with regulatory standards for cloud host configuration, network and audit logs through automation; and automated deployment and fault repair scenarios for distributed application clusters are used to achieve batch deployment of applications within the cluster and automatic detection and recovery when faults occur.

[0035] To address the technical issues of current cloud server management methods, such as the time-consuming and labor-intensive process of determining expired renewals and low-load idle states, which are prone to omissions, this invention provides a cloud server management method. This method specifically includes: creating a task using time-triggered and event-triggered mechanisms; the task information includes task resources, which include cloud servers in all resource pools under the user account and their associated resources, as well as target resources corresponding to preset events; using a task planning agent to determine a first target domain agent corresponding to the task based on the task information; using the first target domain agent to detect the task resources corresponding to the task and obtain the corresponding task processing result; wherein, the first target domain agent determines a first target tool identifier based on the mapping relationship between domain agents and tool identifiers, obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task; generating a suggestion notification based on the task processing result; and processing the suggestion notification.

[0036] In the technical solution of this invention, a time-triggered mechanism and an event-triggered mechanism are used to automatically create tasks. The time-triggered mechanism starts at a preset period, while the event-triggered mechanism monitors preset events such as changes in cloud platform resource status and threshold alarms in real time. Task resources cover cloud hosts and their associated resources in all resource pools under the user account, as well as target resources corresponding to preset events. Based on this, a task planning agent determines and calls a first target domain agent corresponding to the task. This first target domain agent detects the task resources and obtains the task processing result. Finally, a suggestion notification is generated based on the task processing result, and corresponding response processing is performed on the suggestion notification.

[0037] First, this embodiment of the invention constructs an automated process from task creation to cloud host management. In this automated process, tasks are first automatically created through time-triggered and event-triggered mechanisms. The time-triggered mechanism initiates resource status checks at preset intervals, while the event-triggered mechanism monitors preset events such as changes in cloud platform resource status and threshold alarms in real time. Then, a task planning agent determines a first target domain agent corresponding to the task. This first target domain agent automatically detects the resources covered by the task, identifying and judging preset states such as expired renewals and low-load idle states, and processing preset events. Since this automated process requires no manual intervention, it achieves automated management of cloud host resource status and preset events, significantly reducing manual operation costs and processing latency while effectively improving the timeliness, completeness, and accuracy of cloud host management.

[0038] Secondly, this embodiment of the invention adopts an architecture where task planning agents and domain agents work collaboratively. The task planning agent is responsible for task scheduling and agent matching, while the domain agent is responsible for executing the detection logic of its corresponding domain. This separation of responsibilities reduces the coupling between agents and improves the flexibility and scalability of the task processing flow. Simultaneously, based on the agent allocation method for different domains, the judgment of different cloud host states, such as renewal upon expiration and low-load idleness, is handled by a dedicated domain agent, thereby improving the professionalism, accuracy, and overall processing efficiency of state management.

[0039] Furthermore, in this embodiment of the invention, the first target domain agent determines the first target tool identifier based on the mapping relationship between the domain agent and the tool identifier, and retrieves the target tool instance corresponding to the first target tool identifier from the registry to detect the task resources corresponding to the task. When a new tool needs to be introduced, the tool instance of the new tool can be registered in the registry without modifying the processing logic of the domain agent and the task planning agent. The above technical means realize the dynamic loading and plug-and-play functionality of tools, significantly enhancing the adaptability to different management needs.

[0040] Furthermore, embodiments of the present invention can automatically generate suggested notifications based on task processing results. These notifications may include suggestions for merging low-load instances, reminders for expired renewals, and solutions for handling anomalies. Responses to these notifications can be proactively sent to target users via push notifications or other methods, alerting them to low resource load, impending expiration, or anomaly statuses. This allows users to take preventative or timely measures to avoid resource waste, prevent business interruptions, and control the scope of event impact, thereby improving cloud server resource utilization and reducing additional costs incurred due to management delays or oversights.

[0041] The cloud host management method of this invention can be executed by an electronic device. The aforementioned electronic device may include, but is not limited to, client-side or server-side devices. The server-side device may be a standalone server, a cloud server, or a server cluster, while the client-side device may be a personal computer, a mobile terminal, or other device with data processing capabilities.

[0042] The aforementioned client or server can correspond to a cloud server management system. The architecture of this management system can include: Task Planning Agent → Domain Agent → Tools. A tree-structured configuration defines the hierarchical relationships between the Task Planning Agent and the Domain Agent, or between the Domain Agent and the Tools. A tool registry enables dynamic loading of tools. The Task Planning Agent is responsible for task decomposition and scheduling. Lower-level domain agents (computing / networking / storage) are responsible for domain operations at each stage of the cloud server's lifecycle. Tools encapsulate the cloud platform API (Application Programming Interface) to implement atomic operations such as creation, querying, modification, and deletion. This three-tier architecture supports both fixed and dynamic execution modes, enabling plug-and-play tools and flexible expansion for the entire cloud server lifecycle management, significantly reducing system coupling.

[0043] The tools in this invention can interact with cloud platform APIs, translating standardized commands into specific cloud platform operations. This invention can also dynamically load tools through a tool registry, encapsulating computing tools, network tools, storage tools, and general-purpose tools.

[0044] Intelligent agents can be software modules with autonomous perception, decision-making, and execution capabilities, which combine natural language understanding and execution strategies to automate task processing.

[0045] The task planning agent, domain agent, or generative agent in the embodiments of this invention can be an AI agent (Artificial Intelligence Agent). An AI agent is an intelligent agent system with a large language model as its core controller. Essentially, it is an agent system that controls the large language model to solve user problems. It relies on the large language model as its core decision-making and processing unit and can use the logical reasoning ability of the large language model to solve user problems.

[0046] LLM (Large Language Model) refers to a deep learning model trained on massive amounts of text data, possessing powerful expressive and generalization capabilities. It can not only generate natural language text but also deeply understand the meaning of text, handling various natural language tasks such as text summarization, question answering, and translation.

[0047] The cloud server management method of this invention will be described below through specific embodiments.

[0048] Reference Figure 1 This diagram illustrates a step-by-step flowchart of a cloud server management method according to an embodiment of the present invention. The method may specifically include the following steps:

[0049] Step 101: Create a task using time-triggered and event-triggered mechanisms; the task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events;

[0050] Step 102: Using a task planning agent, determine the first target domain agent corresponding to the task based on the task information;

[0051] Step 103: Using the first target domain agent, detect the task resources corresponding to the task to obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task.

[0052] Step 104: Generate a suggestion notification based on the task processing results;

[0053] Step 105: Process the suggested notification.

[0054] In step 101, a task is created using a time-triggered mechanism and an event-triggered mechanism. The time-triggered mechanism initiates checks on resource status at preset intervals, while the event-triggered mechanism monitors preset events such as changes in cloud platform resource status and threshold alarms in real time.

[0055] It is understandable that, in addition to task resources, task information may also include information such as task type and resource type.

[0056] When creating tasks using a time-triggered mechanism, the task resources are the cloud hosts and their associated resources in all resource pools under the user account. Associated resources refer to resources that are bound, dependent on, or used in conjunction with the cloud host, including but not limited to cloud disks, elastic network interfaces, public IP addresses, and security groups. When creating tasks using an event-triggered mechanism, the task resources are the target resources corresponding to a preset event. These target resources refer to the specific cloud resources that require the execution of the corresponding task operation when the preset event is triggered, and can be flexibly specified according to different event types.

[0057] In its specific implementation, the process of creating a task using time-triggered and event-triggered mechanisms includes:

[0058] Step A1: Upon reaching the trigger time, create the first task; the first task is used to detect the cloud hosts and associated resources of all resource pools under the user account.

[0059] Step A2: If a preset event is captured, create a second task; the second task is used to detect the target resource corresponding to the preset event.

[0060] For step A1, upon reaching the trigger time, a first task is created and submitted to the task queue. The task information for the first task includes the first task resources and the first task requirements. The first task resources include cloud hosts in all resource pools under the user account, as well as associated resources of the cloud hosts such as cloud disks, virtual private clouds, and public IP (Internet Protocol) addresses. The first task requirements are resource pool-based splitting and parallel detection, with the preset period unit being daily, weekly, monthly, etc. The trigger time can be set using an expression configuration via the scheduler; reaching the trigger time configured by the expression is considered the arrival of the trigger time.

[0061] For step A2, a preset event can be captured using an event listener. The event source for the preset event can include message queues (such as resource expiration notifications, status change notifications), network hook callbacks (such as threshold alarms, quota warnings), and monitoring metrics (such as persistently low CPU utilization). When the event listener captures a preset event, a second task is created using the event listener and submitted to the task queue. The second task is used to detect the target resource corresponding to the preset event. The task information for the second task includes the second task resource, the second task requirements, and event metadata. The second task resource is the target resource corresponding to the preset event, and the second task requirement is to detect the target resource. After capturing the preset event, the event listener converts it into a standardized task format containing fields such as event type, resource ID (identity), event time, and event details, and submits it to the task queue. The event metadata contains fields such as event type, resource ID, event time, and event details. After converting the captured preset event into a standardized task format containing the above task information, the event listener submits the second task to the task queue.

[0062] In step 102, the task planning agent can be an AI agent used to determine the first target domain agent corresponding to the task based on the task information.

[0063] Tasks in the task queue are consumed by the task planning agent. The task planning agent can determine the corresponding domain agent based on the task type and / or resource type.

[0064] Optionally, the domain agent includes: a computational agent, a network agent, and a storage agent; wherein the computational agent corresponds to computational task resources, the network agent corresponds to network task resources, and the storage agent corresponds to storage task resources.

[0065] For example, cloud servers are computing-type task resources, and related tasks are distributed to computing agents; virtual private clouds and public IP addresses are network-type task resources, and related tasks are distributed to network agents; cloud disks are storage-type task resources, and related tasks are distributed to storage agents.

[0066] Cue words are text instructions input by the user into a large language model or agent. They clarify the task objectives and output constraints, serving as a medium to guide the large language model in generating content that meets the requirements. Their function is to provide the large language model with task direction, such as text generation, question answering, or information processing, while simultaneously limiting elements such as output style, format, and length to ensure that the large language model's output matches the user's expectations. First cue words, second cue words, third cue words, etc., all fall under the category of cue words.

[0067] The prompt words in embodiments of the present invention may include at least one of the following levels:

[0068] System prompt layer

[0069] The system prompt layer defines the roles of the intelligent agent and the information processing rules. The information processing rules include input information, output information requirements, and processing rules. Role setting refers to clarifying the identity, function, and responsibilities of the intelligent agent in the process; input information refers to the raw information and content provided by the user to the intelligent agent; output information requirements refer to the standards set for the content, format, and completeness of the results generated by the intelligent agent; and processing rules refer to the constraints, logic, and processes that the intelligent agent must follow throughout the entire process from receiving input to generating output.

[0070] Process prompt layer

[0071] The process prompt layer is dynamically generated based on the current task flow, and is used to describe the goals, execution steps, contextual constraints, and phased task descriptions of the current task stage. The process prompt layer can be updated as the task progresses, thereby realizing process-oriented control of multi-step tasks.

[0072] Historical memory layer

[0073] The history memory layer is used to incorporate historical interaction records or task execution state information, including previous dialogue content, stage execution results, or intermediate state data. By introducing the history memory layer, the agent can refer to existing context when generating responses, achieving context consistency in continuous tasks.

[0074] Tool capability layer

[0075] The tool capability layer describes the set of callable tools to the agent, including tool names, function descriptions, invocation methods, and input / output constraints. By introducing the tool capability layer, the agent can select appropriate tools to invoke when generating responses, thereby extending the capabilities for complex tasks. The tool capability layer can also describe the set of callable domain agents to the task planning agent, specifying the processing type, applicable scenarios, invocation rules, and resource matching relationships of each domain agent. This enables the task planning agent to accurately schedule and distribute tasks to the corresponding domain agents for execution based on task type and resource type.

[0076] In one implementation, the process of using a task planning agent to determine the first target domain agent corresponding to the task based on the task information specifically includes: inputting a first prompt word to the task planning agent, the first prompt word including: task information and information of the first target domain agent, so that the task planning agent determines the first target domain agent corresponding to the task based on the matching information between the task information and the domain agent information.

[0077] The first prompt word contains information from the system prompt layer and the tool capability layer. The system prompt layer is reflected in the task information of the input information section, and the tool capability layer is reflected in the information of the first target domain agent. The function of the first prompt word is to provide prompt information of the corresponding level to the task planning agent, so that the task planning agent can determine the first target domain agent corresponding to the task based on the matching information between the task information and the domain agent information.

[0078] For example, the resource types in the task information include computing resources, storage resources, and network resources, corresponding to specific resources such as cloud hosts, cloud disks, and public IP addresses. The first target domain agent is skilled at handling computing resources, the second target domain agent is skilled at handling storage resources, and the third target domain agent is skilled at handling network resources. The task planning agent then matches the resource types with the domain agents to assign computing resource tasks to the first target domain agent, storage resource tasks to the second target domain agent, and network resource tasks to the third target domain agent, thus splitting tasks by resource type and assigning them to the corresponding agents.

[0079] In step 103, during the process of detecting the task resources corresponding to the task, the first target domain agent of this embodiment determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and then obtains the tool instance corresponding to the first target tool identifier from the registry to perform detection.

[0080] The registry is used to maintain the correspondence between tool identifiers and tool instances. When it is necessary to support new tools, the tool instance and its tool identifier of the new tool are registered in the registry. The processing logic of the domain agent remains unchanged, thereby realizing that the tool extension and the processing logic of the domain agent are independent of each other. When extending the detection function, there is no need to modify the domain agent, simplifying the function extension process.

[0081] A tool instance is a callable program or service module bound to a tool identifier in the registry, possessing specific detection and execution logic. It is used to perform operations on task resources and return results. For example, a tool instance of a resource query tool is used to obtain detailed information about resources, including status, configuration, cost, performance metrics, etc.

[0082] In an optional implementation of the present invention, the method may further include:

[0083] Step B1: Using a hierarchical configuration file, store multiple agent nodes organized in a tree structure. Each agent node contains associated agent nodes or associated tool identifiers.

[0084] Step B2: Use the tool configuration file to store the tool identifier and tool execution information;

[0085] Step B3: Using the registry, generate tool instances based on the tool execution information in the tool configuration file, and register the mapping relationship between tool identifiers and corresponding tool instances;

[0086] The process of determining the first target tool identifier based on the mapping relationship between the domain agent and the tool identifier specifically includes: determining the target agent node corresponding to the first target domain agent from the hierarchical configuration file; if the target agent node contains an associated tool identifier, then using the tool identifier associated with the target agent node as the first target tool identifier; if the target agent node contains an associated agent node, then determining the first target tool identifier based on the agent node associated with the target agent node.

[0087] In step B1, multiple agent nodes organized in a tree structure are stored through a hierarchical configuration file. Each agent node records its associated agent node or tool identifier, thereby realizing the structured and hierarchical organization and management of agents and related relationships, and providing a data foundation for agents to find the corresponding tool identifier.

[0088] Step B2 stores the tool identifier and execution information of the tool through the tool configuration file, and uniformly saves the identification information and execution information required for each tool, providing a basis for the generation of tool instances.

[0089] Tool execution information comprises the specific configuration and metadata necessary for defining and instantiating a tool. This includes the tool's code entry point, initialization parameters, dependent environments, execution specifications, and other details. For example, the execution information of a resource query tool might include the API (Application Programming Interface) endpoint addresses it calls, authentication credentials, request timeouts, and the rules for parsing the returned results. Tool execution information is the basis for the registry to generate tool instances based on tool configuration files.

[0090] Step B3 generates tool instances through the registry based on the tool execution information in the tool configuration file, and registers the mapping relationship between tool identifiers and corresponding tool instances. This completes the creation of tool instances and the maintenance of mapping relationships, providing support for agents to call tool instances. For example, after the operating system starts, the registry can read the tool configuration file and complete the initialization of tool instances and registration of mapping relationships based on the tool execution information within it.

[0091] In summary, the embodiments of the present invention, through the cooperation of hierarchical configuration files, tool configuration files, and the registry, respectively realize the independent management and collaborative support of the hierarchical association relationship of intelligent agents, basic tool information, and tool instance mapping relationship, and build a standardized and scalable correspondence and calling basic system between intelligent agents and tools.

[0092] Optionally, the above method may further include: adding a tool identifier and tool execution information of the newly added tool to the tool configuration file, and adding the tool identifier of the newly added tool to the agent node corresponding to the newly added tool in the hierarchical configuration file.

[0093] This invention, through adding a tool identifier and corresponding execution information of the target tool to the tool configuration file and associating this tool identifier under the corresponding agent node in the hierarchical configuration file, completes the binding of the configuration definition of the new tool with the agent invocation relationship. The above-mentioned process of adding a new tool does not involve modifying the processing logic of the agent, providing a configuration foundation for the subsequent generation of tool instances by the registry based on this configuration information, and for agents to query and invoke the tool through the hierarchical configuration. This process of adding a new tool improves the convenience of tool extension and enhances the scalability of the system.

[0094] The process of detecting the task resources corresponding to the task using the first target domain agent specifically includes: inputting a sixth prompt word to the first target domain agent, the sixth prompt word may include: so that the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task.

[0095] In a practical implementation, a sixth prompt word can be input to the first target domain agent. This sixth prompt word specifically includes a sixth system prompt message, which defines the role settings of the first target domain agent, information processing rules, the mapping relationship between the domain agent and the tool identifier, and task information. The task information includes a task description, task resource identifiers, and detection requirements.

[0096] Based on the sixth prompt word, the first target domain agent can perform the following actions: clarify its own functional responsibilities according to the role setting, determine the first target tool identifier according to the mapping relationship, then obtain the target tool instance corresponding to the first target tool identifier from the registry, and combine the task resource identifier and detection requirements in the task information to call the target tool instance to detect the task resources corresponding to the task.

[0097] The sixth system prompts, serving as an integrated instruction and information carrier, uniformly encapsulate the role settings, information processing rules, tool matching criteria, and task information of the first target domain intelligent agent. By parsing the sixth system prompts, the first target domain intelligent agent can clearly understand its own role positioning, execution rules, the scope of available tools, and the current task content, thereby transforming task requirements into corresponding tool invocation operations.

[0098] In some examples, the process of using the first target domain agent to detect the task resources corresponding to the task specifically includes:

[0099] Step C1: Using the first target domain agent, determine the remaining duration of cloud hosts and their associated resources in all resource pools under the user account, and mark cloud hosts and their associated resources with remaining durations less than a preset threshold; or

[0100] Step C2: Using the first target domain agent, determine the load status of cloud hosts and their associated resources in all resource pools under the user account, and mark resources whose load status meets the set conditions; or

[0101] Step C3: Using the first target domain agent, identify the idle status of cloud hosts and their associated resources in all resource pools under the user account, and mark resources whose idle status meets the idle conditions; or

[0102] Step C4: Utilize the first target domain agent to perform anomaly detection on the target resources corresponding to the preset event.

[0103] In step C1, the remaining time of cloud hosts and their associated resources in each resource pool under the user account is obtained through the first target domain intelligent agent. The remaining time is compared with a preset threshold, and cloud hosts and their associated resources with remaining time less than the preset threshold are marked. This enables the automatic identification of resources that are about to expire, providing a basis for resource renewal, resource release or business migration.

[0104] Step C2 collects and analyzes the load status of cloud hosts and their associated resources in each resource pool under the user account through the first target domain intelligent agent. According to preset conditions, resources with excessively high or low load are marked, which makes it easier for users to quickly locate abnormal load nodes and realize centralized monitoring and optimized scheduling of resource load.

[0105] Step C3 uses the first target domain intelligent agent to detect the running status and business usage of cloud hosts and their associated resources in each resource pool under the user account, identifies resources that meet the idle conditions and marks them, which can effectively reduce the resource waste and cost caused by idle resources and support refined resource management.

[0106] Step C4 uses the first target domain intelligent agent to perform anomaly detection on the target resource corresponding to the preset event. This can quickly locate the operational anomaly, configuration anomaly, or performance anomaly of the target resource in event-triggered or routine detection scenarios, thereby improving the stability and reliability of the business system.

[0107] In step 104, a suggestion notification is generated based on the task processing results. This suggestion notification not only presents the status or abnormal situation of the resource, but also includes targeted and actionable processing suggestions, thereby providing clear basis and guidance for subsequent resource management, optimization, or disposal operations.

[0108] In a specific implementation, the process of generating a suggestion notification based on the task processing result specifically includes: inputting a second prompt word to the generating agent to obtain a suggestion notification output by the generating agent; wherein, the second prompt word includes: second system prompt information, second historical memory information, and third tool information; the second system prompt information includes: second role information, second rule information, and the task processing result; the second historical memory information includes user historical behavior data; the third tool information includes: a list of tools available for use.

[0109] The second system prompt information defines the specific role and execution rules of the generating agent, and clarifies the core basis for its output suggestions—namely, the task processing results—thus defining the boundaries of the generating agent's responsibilities, output format, and decision-making foundation. The second historical memory information provides the agent with historical user behavior data, enabling its generated suggestions to reference past operating patterns and preferences, thus better aligning with actual usage habits and business scenarios. The third tool information provides the generating agent with the tools it can access and their capability descriptions.

[0110] Therefore, this embodiment of the invention systematically integrates the clearly defined roles and processing rules, the current task processing results, relevant historical behavior data, and tool capabilities through the second prompt word. This enables the generated intelligent agent to make decisions based on preset rules and task processing results, adapt to business scenarios by combining user historical behavior data, and improve the executability of suggested notifications by referring to tool capabilities. Ultimately, it outputs targeted, operable, and business-appropriate suggested notifications, providing a reliable basis for subsequent resource management and disposal operations.

[0111] The recommended notification may include at least one of the following:

[0112] Resource identification information: Used to uniquely identify the cloud host to be managed or its associated resources.

[0113] Resource status information: used to describe the current operating status of cloud hosts and associated resources, such as running, stopped, abnormal, etc.

[0114] Anomaly detection results information: used to indicate whether the target resource has problems such as abnormal operation, non-compliant configuration, or abnormal performance.

[0115] Resource remaining duration information: This indicates the remaining valid usage time of cloud hosts and associated resources, such as the remaining available time of annual or monthly subscription resources.

[0116] Load status information: used to reflect the load level of cloud hosts and related resources, such as CPU, memory, and bandwidth utilization.

[0117] Idle status information: Used to identify whether cloud hosts and associated resources are in an idle state, such as long-term low load or not used by business.

[0118] Suggested solutions: Based on the detected resource status, specific handling methods or optimization directions are provided, such as suggesting renewal, releasing idle resources, or merging low-load instances.

[0119] Execution strategy information: This defines the execution flow of the corresponding solution, including the tools to be invoked, the execution logic, and the execution conditions. For example, when a resource malfunction is detected, a process can be executed to invoke the exception repair tool for recovery; when a resource is about to expire, a process can be executed to invoke the renewal tool for renewal. These processes can be triggered after user authorization.

[0120] In specific implementations, the types of suggested notifications include: manual operation type or execution type;

[0121] Step 105 then processes the suggestion notification, specifically including:

[0122] Step D1: If the suggested notification is a manual operation type, send a suggested notification containing operation guidance information to the target user; or

[0123] Step D2: If the suggestion notification is of the execution type, then send execution query information to the target user, and according to the user's authorization information for the execution query information, call the tool in the suggestion notification to execute the operation corresponding to the suggestion notification.

[0124] In step D1, if the suggestion notification falls under the manual operation type, it can be sent to the target user via designated channels such as in-site messages, SMS, or email. This suggestion notification includes resource identification information, resource status information, anomaly detection results, processing suggestions, and specific operational guidance. After clicking the notification, the target user is taken to a primary user interface displaying the complete suggestion details. Within this interface, the target user manually confirms their intention to perform the action or adds necessary information, and ultimately completes the corresponding resource management and disposal operations manually according to the operational guidance.

[0125] Step D2, if the suggestion notification is of the execution type, sends a suggestion notification containing execution query information to the target user. After clicking the notification, the user enters a second user interface, which displays the execution strategy information and details of the operations requiring user authorization. After the user completes authorization confirmation within the second user interface, the appropriate tool is invoked to complete the corresponding resource operation according to the execution strategy recorded in the suggestion notification.

[0126] The target user can refer to relevant management personnel or system administrators who have the corresponding resource management permissions and are able to confirm or handle the operations in the suggested notification.

[0127] To enable those skilled in the art to better understand the cloud server management method of the embodiments of the present invention, refer to Figure 2 The diagram illustrates a step-by-step flowchart of a cloud server management method according to an embodiment of the present invention. The method may specifically include the following steps:

[0128] Step 201: Create a task using time-triggered and event-triggered mechanisms;

[0129] Step 202: Using a task planning agent, determine the first target domain agent corresponding to the task;

[0130] Step 203: Using the first target domain agent, detect the task resources corresponding to the task to obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task.

[0131] Based on their type, domain agents can be categorized into computational agents, network agents, and storage agents. The computational agent corresponds to computational tasks, such as performing CPU, memory, and load anomaly detection. The network agent corresponds to network tasks, such as performing bandwidth, port, and connectivity anomaly detection. The storage agent corresponds to storage tasks, such as performing disk, snapshot, and capacity anomaly detection.

[0132] Step 204: Determine if there is any abnormality in the task processing result. If not, proceed to step 205; if yes, proceed to step 206.

[0133] For example, the operational indicators of each resource in the task processing results are compared with the thresholds of each resource in the detection strategy, and the results of the comparison are used to determine whether there are any anomalies in the task processing results.

[0134] Step 205: Record the task processing results in the detection log;

[0135] The detection log is used to store task-related data to support tracing, analysis and strategy optimization. The stored content includes task processing results, task triggering methods, agent detection types, anomaly judgment results, suggestion notification generation and push records, user feedback and operation behavior, tool call execution results, detection strategy update records and other information.

[0136] Step 206: Generate a suggestion notification based on the task processing results;

[0137] Step 207: If the type of the suggested notification is manual operation, send a suggested notification containing operation guidance information to the target user;

[0138] Step 208: If the suggestion notification is of the execution type, then send execution query information to the target user, and according to the user's authorization information for the execution query information, call the tool in the suggestion notification to execute the operation corresponding to the suggestion notification.

[0139] Specifically, when the suggestion type is manual operation, operation instructions are sent to the user. When the suggestion type is execution, the user is asked whether to execute automatically. If the user confirms execution, the tool is invoked to complete the operation; if the user refuses execution, the user feedback is recorded, and the process ends.

[0140] After sending operation instructions to the user or calling the tool to complete the operation, the detection strategy can be updated and the process ends.

[0141] The detection strategy defines the set of rules that the system uses when performing periodic inspection tasks. Its core configurations include the inspection cycle (e.g., defined using a timed expression), detection dimensions (e.g., indicators such as CPU, memory, bandwidth and their thresholds), anomaly judgment criteria, and task triggering conditions.

[0142] After pushing operation instructions to users or automatically calling tools to complete optimization operations, the relevant detection strategies can be dynamically adjusted and optimized based on the anomaly types detected in this task, the task processing results, and user feedback. For example, if a certain type of resource frequently triggers high CPU load alarms, the inspection cycle for that type of resource can be shortened accordingly, the warning threshold can be adjusted to avoid frequent false alarms, or more refined load assessment rules can be added. Alternatively, if users repeatedly reject an automatically executed optimization suggestion, the default push strategy for such suggestions can be adjusted (e.g., from automatic execution to manual operation) or its triggering conditions can be modified, making subsequent inspection strategies more targeted and better suited to users' actual operation and maintenance habits and preferences.

[0143] In one example, embodiments of the present invention can automatically create resource detection tasks according to a preset cycle, without requiring user intervention. The first target domain agent can concurrently invoke a resource query tool to obtain information on the quantity, status, configuration, and cost of resources such as cloud hosts, cloud disks, virtual private clouds, and public IPs in each resource pool. Based on the query results from the resource query tool, the first target domain agent can perform four types of anomaly detection: expiration detection, status anomaly detection (error / closure), low load detection (CPU < 25% and memory < 30% for 7 consecutive days), and idle resource detection (no cloud disk mounted, no associated EIP).

[0144] This invention can utilize generated intelligent agents to generate personalized suggestion notifications by combining task processing results and user historical behavior. Examples include low-load instance merging (estimated monthly savings of 400-500 yuan), resource renewal reminders upon expiration, suggestions for handling operational anomalies, and suggestions for cleaning up idle resources. Furthermore, it can proactively push suggestion notifications to users through channels such as in-site messages, SMS, and emails. After the user accepts the suggestion, this invention can automatically call the corresponding tools to perform optimization operations and store user feedback records in a vector database to continuously optimize the recommendation strategy.

[0145] Reference Figure 3 This diagram illustrates a step-by-step flowchart of a cloud server management method according to an embodiment of the present invention. The method may specifically include the following steps:

[0146] Step 301: Create a task using time-triggered and event-triggered mechanisms; the task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events;

[0147] Step 302: Using a task planning agent, determine the first target domain agent corresponding to the task based on the task information;

[0148] Step 303: Using the first target domain agent, detect the task resources corresponding to the task to obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task.

[0149] Step 304: Generate a suggestion notification based on the task processing results;

[0150] Step 305: Process the suggested notification;

[0151] Compared to Figure 1 The method embodiment shown may further include:

[0152] Step 306: Receive user request;

[0153] Step 307: Using a task planning agent, determine the user intent corresponding to the task and generate an execution plan corresponding to the user intent; the execution plan includes: a sequence of subtasks; the subtask information corresponding to each subtask includes: the second target domain agent and the second target tool identifier used to execute the subtask, input parameters, and execution conditions;

[0154] Step 308: Using the second target domain agent, call the tool corresponding to the second target tool identifier to execute the sub-task sequence.

[0155] Steps 301 to 305 are used to implement a proactive management process based on time-triggered and event-triggered mechanisms. This process involves creating management tasks, matching the task planning agent with the corresponding domain agent, using the registry to call the target tool to complete resource detection, and generating and processing suggestion notifications based on the detection results. This enables proactive management of cloud resources and push of optimization suggestions.

[0156] Unlike traditional technologies that passively respond to user requests, the proactive management of this invention can autonomously discover potential risks (such as non-renewal upon expiration, low-load idleness), abnormal states, or optimization opportunities in cloud host resources through preset time-triggered mechanisms (such as timed detection) and real-time event-triggered mechanisms (such as resource alerts). It can also proactively generate personalized suggestion notifications and push them to users without requiring user requests, thus realizing the transformation from "users finding problems" to "systems proactively issuing warnings and suggesting solutions".

[0157] Steps 306 to 308 are used to implement a management process based on user requests. This process receives user requests, the task planning agent parses and determines the corresponding user intent, and then generates an execution plan containing a sequence of subtasks. Each subtask is configured with a corresponding second target domain agent, a second target tool identifier, input parameters, and execution conditions. The second target domain agent then calls the corresponding tool to execute the subtask sequence and process the resource management request initiated by the user.

[0158] The management system in this embodiment of the invention may further include an intelligent interaction layer. This intelligent interaction layer is responsible for receiving and processing different types of interaction requests from users, including natural language input, graphical interface operations, and API calls. Its core function is to convert these diverse inputs into standardized instruction formats that the system can process internally. The intelligent interaction layer supports multiple interaction methods and uses a server-sent event (SSE) mechanism to push real-time progress and status feedback of task execution to the user. Furthermore, this layer is responsible for maintaining the context state of the user session to support the accumulation of parameters in multiple rounds of interaction and dynamic correction based on new input. Simultaneously, the intelligent interaction layer also implements a checkpoint mechanism to record critical states when the process is interrupted, so that execution can be resumed from the interruption point, ensuring the continuity and recoverability of the interaction process.

[0159] In step 306, the intelligent interaction layer receives user requests in natural language. For example, a user can input "Create 5 cloud servers for web services in the North China 1 region, with reasonable configuration" in natural language. The intelligent interaction layer will receive this user request and use it as input for subsequent processes.

[0160] In step 307, the task planning agent can invoke a large language model to determine the user intent corresponding to the task and generate an execution plan corresponding to the user intent.

[0161] The management system can input prompts to the task planning agent to guide the large language model corresponding to the agent in analyzing user needs, historical dialogue records, and tool lists to generate an execution plan. The execution plan includes: a sequence of subtasks; each subtask's information includes: the identifiers of the second target domain agent and the second target tool used to execute the subtask, input parameters, and execution conditions.

[0162] The execution plan is a structured operational scheme generated by the task planning agent based on user intent, and its components are a sequence of subtasks. A subtask is the smallest independently executable unit broken down from the execution plan, corresponding to an execution step in the process. The second target domain agent is the agent that undertakes and executes the subtasks. The second target tool identifier is the identifier of the specific tool to be invoked in this subtask. Input parameters are the key data that needs to be passed to the tool during the execution of this subtask. Execution conditions are the prerequisite constraints that must be met to start and run this subtask.

[0163] In a specific implementation, the process of using a task planning agent to determine the user intent corresponding to the task and generating an execution plan corresponding to the user intent specifically includes: inputting a third prompt word into the task planning agent to obtain the execution plan output by the task planning agent;

[0164] The third prompt includes: third system prompt information, third historical memory information, and third tool information; the third system prompt information includes: third role information, third rule information, and the user intent; the third historical memory information includes user historical behavior data; the third tool information includes: a list of tools for invocation and a hierarchical configuration file; the hierarchical configuration file is used to store multiple agent nodes organized in a tree structure, and each agent node contains associated agent nodes or associated tool identifiers.

[0165] The third prompt is input to the task planning agent, guiding it to parse user intent and generate a structured execution plan. The third system prompt information defines the role and behavioral rules for the task planning agent, providing the user intent to be parsed as a basis for decision-making. The third role information defines the specific responsibilities and functional positioning of the task planning agent in this process. The third rule information specifies the processing logic and constraints that the task planning agent must adhere to when parsing intent, planning tasks, and generating execution plans. The third historical memory information provides the task planning agent with the user's historical operation data to help it more accurately understand the user's current intent. The third tool information provides the task planning agent with a list of currently available tools and the agent's hierarchical organizational structure, serving as the basis for its ability to plan specific execution steps. The list of available tools explicitly lists all available tools and their capabilities, providing a set of optional tools when assigning subtasks to the task planning agent. The hierarchical configuration file stores and organizes agent nodes in a tree structure, recording the hierarchical relationships between agents and the association between agents and available tool identifiers.

[0166] Guided by the third prompt, the task planning agent, within a pre-defined role and rule framework, and combining user historical behavior data, a list of available tools, and agent hierarchical configuration files, performs intent recognition and task decomposition on the user request, ultimately generating an execution plan consisting of a sequence of subtasks. This execution plan explicitly specifies for each subtask the second target domain agent responsible for execution, the identifier of the second target tool to be invoked, the required input parameters, and the execution conditions that must be met for startup and operation.

[0167] In one example, suppose a user request is "Create 5 cloud servers for web services in North China 1, with reasonable configuration." The task planning agent parses this request and determines that the user's intent is: to create 5 cloud servers for web services in the North China 1 region, with reasonable configuration. Subsequently, the task planning agent generates a structured execution plan based on this user intent. This execution plan is a sequence of subtasks arranged in logical order, specifically including: Subtask 1, calling the resource pool query tool to map "North China 1" to a resource pool ID; Subtask 2, calling the configuration reasoning tool to automatically reason about reasonable configuration based on the purpose of the web service; Subtask 3, calling the resource availability check tool to verify resource availability and account quota; Subtask 4, calling the price query tool to generate a cost estimate; Subtask 5, calling the interaction tool to output operation confirmation information to the user; Subtask 6, calling the cloud server creation tool to concurrently execute API calls after user confirmation; Subtask 7, calling the progress feedback tool to provide real-time feedback on the creation progress and return a list of instance IDs.

[0168] In a specific implementation, the execution plan includes: a fixed plan or a dynamic plan; the fixed plan represents an execution plan in which the sequence of subtasks is completely determined when the execution plan is generated; the dynamic plan represents an execution plan in which the execution plan of subsequent subtasks is adjusted based on the execution results of the preceding subtasks during the execution process.

[0169] One difference between fixed and dynamic plans is whether the sequence of subtasks can be modified during execution.

[0170] When a fixed plan is generated, its subtask sequence, the content of each subtask, the order and execution logic are all determined. During execution, it will be executed strictly according to this predefined order and execution logic without any adjustments. For example, it follows a standardized process of creating cloud hosts, configuring security groups and mounting cloud disks in sequence according to preset steps.

[0171] The subtask sequence in a dynamic plan is only an initial scheme at startup. During execution, the content, execution order, or specific logic of subsequent subtasks can be dynamically adjusted based on feedback such as the execution results of executed subtasks and changes in resource status. For example, after creating a cloud host, the availability of the actual obtained public IP address can be used to dynamically choose whether to enable elastic IP or adjust network configuration policies.

[0172] When the execution plan is a fixed plan, the second target domain agent can be used to call the tool pointed to by the second target tool identifier corresponding to each subtask in turn according to the pre-determined subtask sequence, execution order and execution logic in the execution plan, pass in the specified input parameters and meet the corresponding execution conditions, and complete all subtasks one by one until the entire fixed plan is completed. The subtask sequence is not adjusted according to the execution results throughout the process.

[0173] When the execution plan is a dynamic plan, the process of using the second target domain agent to invoke the tool corresponding to the second target tool identifier to execute the sub-task sequence specifically includes:

[0174] Step E1: Using the second target domain agent, execute the first to nth subtasks in the dynamic plan in sequence to obtain the execution results of n subtasks; n can be a positive integer.

[0175] Step E2: Send a fifth prompt word containing the execution results of n sub-tasks to the task planning agent to obtain the new sub-tasks output by the task planning agent;

[0176] Step E3: Utilize the second target domain agent to execute the new sub-task.

[0177] In the execution of a dynamic plan, this invention utilizes a "execution-feedback-replanning" cyclical mechanism to achieve real-time adjustments to the execution plan. Specifically, the currently determined sequence of subtasks is first executed, and the execution results of each subtask are fed back to the task planning agent. Based on the execution results of each subtask, the task planning agent replans subsequent steps and generates new subtasks. This cyclical mechanism enables the dynamic plan to adaptively adjust and continue based on the real-time status during execution, thereby achieving the overall goal corresponding to the user's request.

[0178] In step E1, the second target domain agent sequentially executes the first to nth sub-tasks currently determined in the dynamic plan and collects the execution results of each sub-task to provide real-time status information for subsequent replanning.

[0179] Step E2 integrates the execution results of the n sub-tasks obtained in step E1 into a fifth prompt word and sends it to the task planning agent, enabling the task planning agent to perform analysis and decision-making based on the latest execution status and output new sub-tasks to be executed later.

[0180] Step E3 utilizes the second target domain agent to execute the new sub-task generated by the task planning agent in step E2, completing one iteration of the dynamic plan and advancing the process.

[0181] The fifth prompt contains detailed execution records and results of the first to nth subtasks, the user account's real-time resource status, historical user behavior data, a tool list, and an agent-level configuration file. Guided by the fifth prompt, the task planning agent dynamically replans subsequent tasks based on the actual execution results of the first n subtasks, combined with the user account's real-time resource status, historical behavior data, tool list, and agent organizational structure, according to preset planning rules, thereby generating new subtasks adapted to the current execution state.

[0182] In a specific implementation, the process of using the second target domain agent to call the tool corresponding to the second target tool identifier to execute the sub-task sequence specifically includes: inputting a fourth prompt word to the second target domain agent to obtain the execution result of the i-th sub-task; wherein, the fourth prompt word includes: fourth system prompt information, fourth process prompt information, fourth historical memory information, and fourth tool information; the fourth system prompt information includes: fourth role information, fourth rule information, and sub-task information of the i-th sub-task; the fourth process prompt information includes: the execution result of the sub-task preceding the i-th sub-task; i is a positive integer; the fourth historical memory information includes user historical behavior data; the fourth tool information includes: a list of tools available for invocation.

[0183] The fourth cue word is a comprehensive instruction message input to the second target domain agent to guide it in executing the i-th subtask. Wherein:

[0184] The fourth system prompts the second target domain agent to set the role, rules, and specific information of the subtask required for execution of the i-th subtask;

[0185] The fourth role information defines the functional positioning and specific responsibilities of the intelligent agent in the second target domain when performing the i-th sub-task;

[0186] The fourth rule specifies the processing logic and operational constraints that the second target domain agent follows when performing the i-th sub-task;

[0187] The fourth process prompt provides the execution results of the subtasks that have been completed before the i-th subtask, in order to maintain the contextual coherence of the task sequence;

[0188] The fourth historical memory information provides the second target domain intelligent agent with user historical behavior data, providing historical reference for the execution of the current sub-task;

[0189] The fourth tool information sends available tools to the second target domain agent as a basis for its ability to complete the sub-task.

[0190] Guided by the fourth prompt, the second target domain agent, based on the specified role and rules, combined with subtask information, user historical behavior data (including the execution result of the (i-1)th subtask), and available tools, parses and executes the i-th subtask and outputs the corresponding execution result.

[0191] Operations such as creating and batch modifying cloud servers involve multiple steps that require user confirmation at each step. If a user leaves midway or the conversation is interrupted, the parameters entered and the operations performed are not saved, and the user has to start the entire process again, resulting in a poor user experience and low efficiency.

[0192] To address the issue of users needing to restart the entire process due to mid-process departure or interruption of the conversation, this invention employs a breakpoint handling mechanism to save the execution state at critical nodes in long-running operations such as cloud host creation and batch changes. When the user confirms the interruption or the conversation unexpectedly terminates, the execution context corresponding to subtasks such as collected parameters, executed tool calls, and pending confirmation operations is persistently stored. When the user restarts the conversation, the interrupted state is automatically restored based on the execution context corresponding to the subtasks, and execution continues from the point of interruption without requiring re-entry.

[0193] The breakpoint handling mechanism may specifically include the following steps:

[0194] Step F1: Pre-define key nodes for each subtask;

[0195] Step F2: When the execution of a subtask reaches the critical node, store the dialogue identifier corresponding to the subtask and the execution context corresponding to the subtask in the database;

[0196] Step F3: Upon receiving a dialogue restart request, search the database according to the dialogue identifier corresponding to the dialogue restart request to obtain the execution context corresponding to the dialogue restart request;

[0197] Step F4: Show the target user a summary of the interrupted operation and recovery options;

[0198] Step F5: Based on the user's confirmation instruction for the recovery option, and based on the execution context data, resume the execution of the subtask from the critical node.

[0199] The breakpoint handling mechanism in this invention persistently saves the execution context of the current state at key nodes in the execution flow. When the dialogue restarts, the corresponding execution context is restored based on the unique dialogue identifier, and a clear summary of the breakpoint operation and the resumption options are displayed to the user. After the user confirms the resumption, subsequent steps can be continued from that key node, thereby realizing the resumption of the process from breakpoints, avoiding repeated operations, and improving the continuity and efficiency of the interaction.

[0200] Critical nodes are pre-defined logical locations in the subtask execution process that are state-consistent and suitable for persistent storage. They are used to mark checkpoints in the process that can be safely interrupted and ensure the integrity of logic and data after recovery.

[0201] Key nodes include: parameter completeness checkpoints, user final confirmation points, and points before external system interaction;

[0202] The parameter completeness checkpoint indicates that the structured input data required for the execution of the subtask has met the preset integrity constraints and format verification conditions; the user final confirmation point indicates that the process has been executed to the step where the user needs to authorize and confirm the preset key or irreversible operation; the external system interaction pre-point indicates that the process has been executed to the step where an external service or interface is about to be called and the pre-execution state has been solidified.

[0203] Step F1 predefines key nodes for some or all of the subtask sequence, clarifies the logical locations in the process where state saving and restoration can be performed, and establishes a rule basis for the breakpoint mechanism.

[0204] Step F2: When the process reaches the preset key node, the unique identifier of the current dialogue and the complete execution context (including input parameters, tool call records, intermediate results, pending confirmation operations and node positions, etc.) are persistently stored to complete the snapshot saving of the execution state.

[0205] After receiving the user's process recovery request, step F3 searches for and loads the complete execution context corresponding to the interrupted dialogue in persistent storage based on the dialogue identifier carried in the process recovery request, thus providing a data foundation for process recovery.

[0206] Step F4 presents a summary of the interruption point to the user based on the loaded execution context. The summary clearly shows the key steps that have been completed, the current status of the interruption point, and the operations to be processed or confirmed. It also provides clear recovery options, allowing the user to intuitively understand the execution progress before the interruption.

[0207] After the user confirms the recovery, step F5 resumes the execution of the process from the most recently saved key node based on the loaded execution context, automatically reusing the stored parameters and intermediate states, without requiring the user to re-enter or repeat the completed steps.

[0208] In a specific implementation, the execution context includes: the input parameters collected by the subtask and their sources, the historical tool call records of the subtask, the operations to be confirmed by the subtask, and the current key node position of the subtask.

[0209] The interruption point operation summary specifically includes: an overview of the key nodes that the subtask has completed, a description of the current key nodes of the subtask, and the operation content to be confirmed by the user.

[0210] The subtask's collected input parameters and their sources are used to record the input data (parameter values) that have been collected and are required for the subtask's execution, as well as the channels through which this data was obtained (such as user input, system queries, default configurations, etc.). When resuming execution, the system can directly load the subtask's collected input parameters and their sources to obtain the complete input required for continued execution, without needing to collect them again.

[0211] The subtask's historical tool call log is used to save all tool call logs that the subtask successfully executed before the interruption, including call time, tool identifier, input parameters, and execution results. Upon resumption of execution, the input parameters collected by the subtask and their sources ensure process traceability and can be used to avoid duplicate tool calls.

[0212] The pending confirmation operation of the subtask is used to save the specific operation information that was waiting for user authorization or confirmation before the interruption.

[0213] The current critical node position of the subtask is used to record the latest critical node identifier in the preset process when the subtask is interrupted.

[0214] The summary of key milestones for completed subtasks provides users with a concise overview of all key milestones that the current subtask has successfully passed from the start of execution to the point of interruption, allowing users to intuitively understand the amount of work completed and the execution progress.

[0215] The current critical node description of the subtask is used to describe to the user the process status, business meaning or pending operation corresponding to the critical node where the subtask is interrupted, and to clearly inform the user of the process interruption location and current context.

[0216] The pending confirmation operations are displayed to show users the details of operations that have not yet been completed due to interruption and require their decision. This helps users quickly understand the tasks at hand and make the necessary confirmation to resume the process.

[0217] Reference Figure 4 This diagram illustrates a step-by-step flowchart of a cloud server management method according to an embodiment of the present invention. The method may specifically include the following steps:

[0218] Step 401: Receive user request;

[0219] Step 402: Using a task planning agent, determine the user intent corresponding to the task and generate an execution plan corresponding to the user intent; the execution plan includes: a sequence of subtasks; the subtask information corresponding to each subtask includes: the second target domain agent and the second target tool identifier used to execute the subtask, input parameters, and execution conditions;

[0220] Step 403: If the execution plan is a fixed plan, then the second target domain agent is used to execute the fixed plan in the order of the sub-task sequence;

[0221] Step 404: If the execution plan is a dynamic plan, then the second target domain agent is used to execute the dynamic plan in an iterative manner of "execution-feedback-replanning".

[0222] Specifically, the process begins by scheduling the second target domain agent to execute the currently determined sub-tasks, and the execution results are then fed back to the task planning agent. The task planning agent then replans subsequent tasks based on the latest state, generating a new sequence of sub-tasks, and schedules another agent to execute the new tasks. This process iterates until the goal of the dynamic plan is achieved.

[0223] Step 405: When the execution of a subtask reaches the critical node, store the dialogue identifier corresponding to the subtask and the execution context corresponding to the subtask in the database;

[0224] Step 406: Determine whether the execution status of the subtask is abnormal. If yes, proceed to step 407; otherwise, proceed to step 409.

[0225] Step 407: Persistently store the dialogue identifier corresponding to the subtask and the execution context corresponding to the subtask;

[0226] Step 408: Determine whether the user has resumed the dialogue corresponding to the user request. If yes, proceed to step 409; otherwise, clear the execution context corresponding to the dialogue and end the process.

[0227] Step 409: Resume the execution of the subtask from the key node according to the execution context corresponding to the dialogue;

[0228] Step 410: Invoke the tool corresponding to the second target tool identifier and execute the subtask sequence;

[0229] Step 411: Determine whether the execution result of the subtask sequence is successful. If yes, proceed to step 412; otherwise, proceed to step 413.

[0230] Step 412: Generate an execution summary and provide feedback to the user;

[0231] Step 413: Call the large language model to analyze the reasons for failure and determine the feasibility of retrying based on the reasons for failure; if retrying is possible, proceed to step 414; otherwise, proceed to step 415.

[0232] Step 414: Call the corresponding tool to re-execute the subtask sequence.

[0233] Step 415: Provide feedback to the user regarding the specific reasons for the failure and end the current process.

[0234] Step 416: Update the memory bank, record the execution information of this task, and the process ends.

[0235] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the present invention.

[0236] Based on the description of the above method embodiments, the present invention also provides corresponding cloud host management device embodiments to implement the content described in the above method embodiments.

[0237] Reference Figure 5The diagram illustrates the structure of a cloud server management device according to an embodiment of the present invention. The device specifically includes the following modules:

[0238] The task creation module 501 is used to create tasks using time-triggered and event-triggered mechanisms. The task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events.

[0239] The first task planning module 502 is used to determine the first target domain agent corresponding to the task based on the task information using a task planning agent.

[0240] The task processing module 503 is used to detect the task resources corresponding to the task using the first target domain agent and obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry to detect the task resources corresponding to the task;

[0241] The suggestion generation module 504 is used to generate a suggestion notification based on the task processing result;

[0242] The suggestion processing module 505 is used to process the suggestion notification.

[0243] Optionally, the device further includes:

[0244] The tree storage module is used to store multiple agent nodes organized in a tree structure using hierarchical configuration files. Each agent node contains associated agent nodes or associated tool identifiers.

[0245] The tool configuration module is used to store the tool identifier and tool execution information of a tool using a tool configuration file.

[0246] The instance generation module is used to generate tool instances using the registry and based on the tool execution information in the tool configuration file, and to register the mapping relationship between tool identifiers and corresponding tool instances;

[0247] The first target domain agent determines the first target tool identifier based on the mapping relationship between the domain agent and the tool identifier, including:

[0248] The target agent node corresponding to the first target domain agent is determined from the hierarchical configuration file;

[0249] If the target agent node contains an associated tool identifier, then the tool identifier associated with the target agent node is used as the first target tool identifier; if the target agent node contains an associated agent node, then the first target tool identifier is determined based on the agent node associated with the target agent node.

[0250] Optionally, the device further includes:

[0251] A new tool processing module is added to the tool configuration file to add the tool identifier and tool execution information of the new tool, and to add the tool identifier of the new tool to the agent node corresponding to the new tool in the hierarchical configuration file.

[0252] Optionally, the task creation module includes:

[0253] The first task creation module is used to create a first task when the trigger time is reached; the first task is used to detect cloud hosts and associated resources of all resource pools under the user account.

[0254] The second task creation module is used to create a second task when a preset event is captured; the second task is used to detect the target resource corresponding to the preset event.

[0255] Optionally, the first task planning module includes:

[0256] The first input module is used to input a first prompt word to the task planning agent. The first prompt word includes task information and information of the first target domain agent, so that the task planning agent can determine the first target domain agent corresponding to the task based on the matching information between the task information and the domain agent information.

[0257] Optionally, the domain agent includes: a computational agent, a network agent, and a storage agent;

[0258] Wherein, the computational agent corresponds to computational type task resources, the network agent corresponds to network type task resources, and the storage agent corresponds to storage type task resources.

[0259] Optionally, the task processing module includes:

[0260] The first task processing module is used to utilize the first target domain intelligent agent to determine the remaining time of cloud hosts and their associated resources in all resource pools under the user account, and to mark cloud hosts and their associated resources with remaining time less than a preset threshold; or

[0261] The second task processing module is used to utilize the first target domain intelligent agent to determine the load status of cloud hosts and associated resources in all resource pools under the user account, and to mark resources whose load status meets the set conditions; or

[0262] The third task processing module is used to utilize the first target domain intelligent agent to identify the idle status of cloud hosts and associated resources in all resource pools under the user account, and to mark resources whose idle status meets the idle conditions; or

[0263] The fourth task processing module is used to perform anomaly detection on the target resources corresponding to the preset events using the first target domain intelligent agent.

[0264] Optionally, the suggestion generation module includes:

[0265] The second input module is used to input a second prompt word into the generating agent in order to obtain the suggestion notification output by the generating agent;

[0266] The second prompt includes: second system prompt information, second historical memory information, and third tool information; the second system prompt information includes: second role information, second rule information, and the task processing result; the second historical memory information includes user historical behavior data; and the third tool information includes: a list of tools available for use.

[0267] Optionally, the type of the suggested notification includes: manual operation type or execution type;

[0268] The suggestion processing module includes:

[0269] The first suggestion processing module is used to send a suggestion notification containing operation guidance information to the target user if the suggestion notification is of the manual operation type; or

[0270] The second suggestion processing module is used to send execution query information to the target user if the suggestion notification is of the execution type, and to call the tool in the suggestion notification to execute the operation corresponding to the suggestion notification based on the user's authorization information for the execution query information.

[0271] Optionally, the device further includes:

[0272] The request receiving module is used to receive user requests;

[0273] The second task planning module is used to determine the user intent corresponding to the task using a task planning agent, and generate an execution plan corresponding to the user intent; the execution plan includes: a sequence of subtasks; the subtask information corresponding to each subtask includes: the identifier of the second target domain agent and the second target tool used to execute the subtask, input parameters, and execution conditions;

[0274] The subtask execution module is used to utilize the second target domain agent to call the tool corresponding to the second target tool identifier to execute the subtask sequence.

[0275] Optionally, the second task planning module includes:

[0276] The third input module is used to input a third prompt word into the task planning agent in order to obtain the execution plan output by the task planning agent.

[0277] The third prompt includes: third system prompt information, third historical memory information, and third tool information; the third system prompt information includes: third role information, third rule information, and the user intent; the third historical memory information includes user historical behavior data; the third tool information includes: a list of tools for invocation and a hierarchical configuration file; the hierarchical configuration file is used to store multiple agent nodes organized in a tree structure, and each agent node contains associated agent nodes or associated tool identifiers.

[0278] Optionally, the execution plan includes: a fixed plan or a dynamic plan; the fixed plan represents an execution plan in which the sequence of subtasks is fully determined when the execution plan is generated; the dynamic plan represents an execution plan in which the execution plan of subsequent subtasks is adjusted based on the execution results of the preceding subtasks during execution.

[0279] Optionally, the execution plan is a dynamic plan, and the subtask execution module includes:

[0280] The sequential execution module is used to utilize the second target domain agent to sequentially execute the first to nth subtasks in the dynamic plan to obtain the execution results of the n subtasks;

[0281] The subtask update module is used to send a fifth prompt word containing the execution results of n subtasks to the task planning agent, so as to obtain the new subtasks output by the task planning agent.

[0282] A new task execution module is used to execute the new sub-task using the second target domain agent.

[0283] Optionally, the subtask execution module includes:

[0284] The fourth input module is used to input the fourth prompt word into the second target domain agent in order to obtain the execution result of the i-th subtask;

[0285] The fourth prompt word includes: fourth system prompt information, fourth process prompt information, fourth historical memory information, and fourth tool information;

[0286] The fourth system prompt information includes: fourth role information, fourth rule information, and subtask information of the i-th subtask;

[0287] The fourth process prompt information includes: the execution result of the subtask preceding the i-th subtask;

[0288] The fourth historical memory information includes user historical behavior data;

[0289] The fourth tool information includes: a list of tools available for use.

[0290] Optionally, the device further includes:

[0291] The configuration module is used to pre-define key nodes for each subtask;

[0292] The storage module is used to store the dialogue identifier and execution context of the subtask to the database when the execution of the subtask reaches the key node.

[0293] The lookup module is used to, upon receiving a dialogue restart request, search the database based on the dialogue identifier corresponding to the dialogue restart request in order to obtain the execution context corresponding to the dialogue restart request.

[0294] The display module is used to show the target user a summary of the interrupted operation and recovery options;

[0295] The recovery module is used to resume the execution of the subtask from the critical node based on the execution context data, according to the user's confirmation instruction for the recovery option.

[0296] Optionally, the execution context includes: the input parameters collected by the subtask and their sources, the historical tool call records of the subtask, the subtask's pending confirmation operations, and the current key node position of the subtask.

[0297] Optionally, the interruption point operation summary includes: an overview of the key nodes of the subtask that have been completed, a description of the current key nodes of the subtask, and the operation content to be confirmed by the user.

[0298] This invention discloses an electronic device, including a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the aforementioned method.

[0299] This invention discloses a non-transitory computer-readable storage medium storing instructions that cause a processor to execute the aforementioned method.

[0300] Non-transitory memory: This refers to components or devices in computer hardware used for non-temporary storage of data and instructions. It emphasizes the "non-transitory" nature of the storage, meaning the data will not be lost due to momentary factors such as the disappearance of electrical signals. Examples include ROM (Read-Only Memory) and the storage chips in solid-state drives (SSDs), which can store data long-term.

[0301] Non-transitory computer-readable recording media: Physical carriers that can permanently store computer data and are readable. Data storage is stable and not temporary. Examples include hard drives, USB flash drives, and optical discs. They can store various types of data such as programs, documents, and videos. Even if the device is powered off or restarted, the data is still retained and can be accessed by the computer later.

[0302] Non-transitory computer-readable storage media: These are part of the computer storage system and are media that can permanently store computer-readable data. They include hard drives, solid-state drives, and flash memory. Unlike transient storage, they can permanently or long-term retain data. Computers can read the stored instructions and data through corresponding interfaces and protocols for use in program execution, data processing, and other scenarios. For example, they store operating systems, application code, and user files, providing stable data support for the computer system.

[0303] The device used for managing cloud servers can be an electronic device. Figure 6 A schematic diagram of an electronic device 1100 according to an embodiment of the present invention is shown. The electronic device 1100 specifically includes: one or more processors 1102, a control module (chipset) 1104 coupled to at least one of the processors 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0304] Processor 1102 may include one or more single-core or multi-core processors, and processor 1102 may include any combination of general-purpose processors or special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, electronic device 1100 can serve as a terminal device, server (cluster), or other device as described in the embodiments of the present invention.

[0305] In some embodiments, electronic device 1100 may include one or more computer-readable media (e.g., memory 1106 or non-volatile memory / storage device 1108) having instructions 1114 and one or more processors 1102 that are combined with the one or more computer-readable media and configured to execute instructions 1114 to implement modules and thus perform the actions described in this disclosure.

[0306] In one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processors 1102 and / or any suitable device or component communicating with the control module 1104.

[0307] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0308] Memory 1106 may be used, for example, to load and store data and / or instructions 1114 for electronic device 1100. In one embodiment, memory 1106 may include any suitable volatile memory, such as suitable DRAM (Dynamic Random Access Memory). In some embodiments, memory 1106 may include double data rate type quad synchronous dynamic random access memory.

[0309] In one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and (one or more) input / output devices 1110.

[0310] For example, non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. Non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital universal optical disk drives).

[0311] The non-volatile memory / storage device 1108 may include storage resources that are physically part of a device on which the electronic device 1100 is mounted, or that can be accessed by the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via a network via one or more input / output devices 1110.

[0312] One or more input / output devices 1110 may provide an interface for electronic device 1100 to communicate with any other suitable device. Input / output devices 1110 may include communication components, audio components, sensor components, etc. Network interface 1112 may provide an interface for electronic device 1100 to communicate via one or more networks. Electronic device 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing wireless networks based on communication standards, such as WiFi (Wireless Fidelity), 2G (2-Generation wireless telephone technology), 3G (3-Generation wireless telephone technology), 4G (4-Generation wireless telephone technology), 5G (5-Generation wireless telephone technology), etc., or combinations thereof.

[0313] In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers (e.g., memory controller modules) of the control module 1104. In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers of the control module 1104 to form a system-in-package. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die to form a system-on-a-chip.

[0314] In various embodiments, electronic device 1100 may be, but is not limited to, a server, desktop computing device, or mobile computing device (e.g., laptop computing device, handheld computing device, touchscreen device, netbook, etc.). In various embodiments, electronic device 1100 may have more or fewer components and / or different architectures. For example, in some embodiments, electronic device 1100 includes one or more cameras, a keyboard, a liquid crystal display screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0315] This invention provides a machine-readable medium storing instructions that, when executed by one or more processors, cause an electronic device to perform one or more of the methods described in the above embodiments.

[0316] Optionally, the machine-readable medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0317] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0318] It will be readily apparent to those skilled in the art that any combination of the above embodiments is feasible, and therefore any combination of the above embodiments constitutes an implementation of the present invention. However, due to space limitations, each embodiment will not be described in detail here. Although preferred embodiments of the present invention have been described, those skilled in the art, once they understand the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the present invention.

[0319] The above provides a detailed description of the cloud server management method, apparatus, and medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for managing cloud servers, characterized in that, Applied to a cloud server management system, the method includes: Tasks are created using time-triggered and event-triggered mechanisms; the task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events; Using a task planning agent, a first target domain agent corresponding to the task is determined based on the task information; Using the first target domain agent, the task resources corresponding to the task are detected to obtain the corresponding task processing result; wherein, the first target domain agent determines the first target tool identifier according to the mapping relationship between the domain agent and the tool identifier, and obtains the target tool instance corresponding to the first target tool identifier from the registry, and detects the task resources corresponding to the task; the domain agent includes: a computation agent, a network agent, and a storage agent; the computation agent corresponds to computation type task resources, the network agent corresponds to network type task resources, and the storage agent corresponds to storage type task resources; Based on the task processing results, a suggestion notification is generated; The suggestion notification is processed; if the suggestion notification is of type execution, an execution query is sent to the target user, and based on the user's authorization information for the execution query, the tool in the suggestion notification is invoked to execute the operation corresponding to the suggestion notification; The method further includes: using a task planning agent to parse and determine the user intent corresponding to the user request, and generating an execution plan containing a sequence of subtasks; pre-setting key nodes for each subtask; when the execution of a subtask reaches the key node, storing the dialogue identifier corresponding to the subtask and the execution context corresponding to the subtask in a database; when a dialogue restart request is received, searching the database according to the dialogue identifier corresponding to the dialogue restart request to obtain the execution context corresponding to the dialogue restart request; displaying a summary of the interruption point operation and a resumption option to the user; and resuming the execution of the subtask from the key node based on the execution context data, according to the user's confirmation instruction for the resumption option.

2. The method according to claim 1, characterized in that, The method further includes: Using hierarchical configuration files, multiple agent nodes are stored in a tree structure, with each agent node containing associated agent nodes or associated tool identifiers; The tool configuration file stores the tool identifier and tool execution information; Using the registry, based on the tool execution information in the tool configuration file, a tool instance is generated, and the mapping relationship between the tool identifier and the corresponding tool instance is registered; The first target domain agent determines the first target tool identifier based on the mapping relationship between the domain agent and the tool identifier, including: The target agent node corresponding to the first target domain agent is determined from the hierarchical configuration file; If the target agent node contains an associated tool identifier, then the tool identifier associated with the target agent node is used as the first target tool identifier; if the target agent node contains an associated agent node, then the first target tool identifier is determined based on the agent node associated with the target agent node.

3. The method according to claim 2, characterized in that, The method further includes: Add the tool identifier and tool execution information of the new tool to the tool configuration file, and add the tool identifier of the new tool to the agent node corresponding to the new tool in the hierarchical configuration file.

4. The method according to any one of claims 1 to 3, characterized in that, The creation of tasks using time-triggered and event-triggered mechanisms includes: Upon reaching the trigger time, create the first task; the first task is used to detect cloud hosts and associated resources of all resource pools under the user account; If a preset event is captured, a second task is created; the second task is used to detect the target resource corresponding to the preset event.

5. The method according to any one of claims 1 to 3, characterized in that, The process of utilizing a task planning agent to determine the first target domain agent corresponding to the task based on the task information includes: A first prompt word is input to the task planning agent. The first prompt word includes task information and information of the first target domain agent, so that the task planning agent can determine the first target domain agent corresponding to the task based on the matching information between the task information and the domain agent information.

6. The method according to any one of claims 1 to 3, characterized in that, The step of using the first target domain agent to detect the task resources corresponding to the task includes: Using the first target domain intelligent agent, determine the remaining time of cloud hosts and their associated resources in all resource pools under the user account, and mark cloud hosts and their associated resources with remaining time less than a preset threshold; or Using the first target domain intelligent agent, determine the load status of cloud hosts and their associated resources in all resource pools under the user account, and mark resources whose load status meets the set conditions; or Using the first target domain intelligent agent, identify the idle status of cloud hosts and their associated resources in all resource pools under the user account, and mark resources whose idle status meets the idle conditions; or Using the first target domain intelligent agent, anomaly detection is performed on the target resources corresponding to the preset events.

7. The method according to any one of claims 1 to 3, characterized in that, The step of generating a suggestion notification based on the task processing result includes: Input a second prompt word into the generating agent to obtain the suggested notification output by the generating agent; The second prompt includes: second system prompt information, second historical memory information, and third tool information; the second system prompt information includes: second role information, second rule information, and the task processing result; the second historical memory information includes user historical behavior data; and the third tool information includes: a list of tools available for use.

8. The method according to any one of claims 1 to 3, characterized in that, The processing of the suggested notification includes: If the suggested notification is a manual operation type, a suggested notification containing operation guidance information will be sent to the target user.

9. The method according to any one of claims 1 to 3, characterized in that, The subtask information for each subtask includes: the second target domain agent and the second target tool identifier, input parameters, and execution conditions used to execute the subtask; The method further includes: Using the second target domain agent, the tool corresponding to the second target tool identifier is invoked to execute the subtask sequence.

10. The method according to claim 9, characterized in that, The step of utilizing a task planning agent to determine the user intent corresponding to the task and generating an execution plan corresponding to the user intent includes: Input a third prompt word into the task planning agent to obtain the execution plan output by the task planning agent; The third prompt includes: third system prompt information, third historical memory information, and third tool information; the third system prompt information includes: third role information, third rule information, and the user intent; the third historical memory information includes user historical behavior data; the third tool information includes: a list of tools for invocation and a hierarchical configuration file; the hierarchical configuration file is used to store multiple agent nodes organized in a tree structure, and each agent node contains associated agent nodes or associated tool identifiers.

11. The method according to claim 9, characterized in that, The execution plan includes: a fixed plan or a dynamic plan; the fixed plan represents an execution plan in which the sequence of subtasks is fully determined when the execution plan is generated; the dynamic plan represents an execution plan in which the execution plan of subsequent subtasks is adjusted based on the execution results of the preceding subtasks during the execution process.

12. The method according to claim 9, characterized in that, The execution plan is a dynamic plan. The step of utilizing the second target domain agent to invoke the tool corresponding to the second target tool identifier to execute the sub-task sequence includes: Using the second target domain agent, the first to nth subtasks in the dynamic plan are executed sequentially to obtain the execution results of the n subtasks; Send a fifth prompt word containing the execution results of n subtasks to the task planning agent to obtain a new subtask output by the task planning agent; The new subtask is executed using the second target domain agent.

13. The method according to claim 9, characterized in that, The step of utilizing the second target domain agent to invoke the tool corresponding to the second target tool identifier to execute the sub-task sequence includes: Input the fourth prompt word into the second target domain agent to obtain the execution result of the i-th subtask; The fourth prompt word includes: fourth system prompt information, fourth process prompt information, fourth historical memory information, and fourth tool information; The fourth system prompt information includes: fourth role information, fourth rule information, and subtask information of the i-th subtask; The fourth process prompt information includes: the execution result of the subtask preceding the i-th subtask; The fourth historical memory information includes user historical behavior data; The fourth tool information includes: a list of tools available for use.

14. The method according to claim 1, characterized in that, The execution context includes: the input parameters collected by the subtask and their sources, the historical tool call records of the subtask, the subtask's pending confirmation operations, and the current key node position of the subtask.

15. The method according to claim 1, characterized in that, The interruption point operation summary includes: an overview of the key nodes that the subtask has completed, a description of the current key nodes of the subtask, and the operation content to be confirmed by the user.

16. A cloud server management device, characterized in that, The device, used in a cloud server management system, includes: The task creation module is used to create tasks using time-triggered and event-triggered mechanisms. The task information includes: task resources, which include: cloud hosts and associated resources of all resource pools under the user account, as well as target resources corresponding to preset events. The first task planning module is used to utilize the task planning agent to determine the first target domain agent corresponding to the task based on the task information. The task processing module is used to utilize the first target domain agent to detect the task resources corresponding to the task and obtain the corresponding task processing result. Specifically, the first target domain agent determines a first target tool identifier based on the mapping relationship between domain agents and tool identifiers, and retrieves the target tool instance corresponding to the first target tool identifier from the registry to detect the task resources corresponding to the task. The domain agent includes a computation agent, a network agent, and a storage agent. The computation agent corresponds to computation-type task resources, the network agent corresponds to network-type task resources, and the storage agent corresponds to storage-type task resources. The suggestion generation module is used to generate suggestion notifications based on the task processing results. The suggestion processing module is used to process the suggestion notification; if the suggestion notification is of type execution, it sends execution query information to the target user, and according to the user's authorization information for the execution query information, it calls the tool in the suggestion notification to execute the operation corresponding to the suggestion notification; The task planning agent parses and determines the user intent corresponding to the user request, and generates an execution plan containing a sequence of subtasks. Key nodes are pre-defined for each subtask. When a subtask reaches a key node, the dialogue identifier and execution context corresponding to the subtask are stored in a database. Upon receiving a dialogue restart request, the database is searched based on the dialogue identifier corresponding to the restart request to obtain the execution context. A summary of the interruption point and a resumption option are displayed to the user. Based on the user's confirmation instruction for the resumption option and the execution context data, the execution of the subtask is resumed from the key node.

17. An electronic device comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 15.

18. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method according to any one of claims 1-15.

Images