Business processing methods, devices, computer equipment and storage media

Abstract

This application relates to a business processing method, apparatus, computer device, and storage medium. The method includes: acquiring a user's business request; splitting the business request based on the user's intent information in the business request to obtain multiple sub-business requests; matching a corresponding intelligent agent component for each sub-business request from multiple intelligent agent components based on the association element information of each sub-business request; determining a scheduling strategy for the intelligent agent components matching each sub-business request based on the business dependencies of each sub-business request; scheduling the corresponding intelligent agent components to process the corresponding sub-business requests based on the scheduling strategy to obtain the sub-request processing results of each sub-business request; and generating a processing result for the business request based on all sub-request processing results. Using this method can improve the overall operational efficiency of a business service platform.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a business processing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the development of artificial intelligence technology, the demand for complex business processing is increasing. Traditional business service platforms often employ a distributed business processing approach when handling complex tasks, distributing the processing across different business modules. For example, in charging service scenarios, charging service platforms need to cope with challenges such as millions of user visits, multi-scenario business processing, and efficient service response. Their business modules may include charging site selection planning, operation management, maintenance, vehicle-to-grid interaction decision-making, and customer service consultation, with each module operating independently and limited interaction achieved through manual coordination or simple API calls.

[0003] The lack of a unified collaborative scheduling mechanism between various business modules, and the inability to share data between them in real time, results in cumbersome business processing procedures and delayed responses, making it difficult to meet users' needs for intelligent, efficient, and convenient business services. It also reduces the overall operational efficiency of the business service platform.

[0004] Therefore, how the business service platform processes business transactions to improve its overall operational efficiency is a problem that needs to be solved. Summary of the Invention

[0005] Therefore, it is necessary to provide a business processing method, apparatus, computer equipment, and storage medium to address the aforementioned technical problems, so as to process business and improve the overall operational efficiency of the business service platform.

[0006] Firstly, this application provides a business processing method applied to a business processing platform, which includes multiple intelligent agent components, each of which is used to process business corresponding to at least one business type. The method includes:

[0007] Obtain the user's business request;

[0008] The business request is split into multiple sub-business requests based on the user's intent information in the business request;

[0009] Based on the associated element information of each sub-business request, a corresponding intelligent agent component is matched for each sub-business request from multiple intelligent agent components; the associated element information of the sub-business request includes the business operation type, required data type, and business dependency relationship of the corresponding sub-business request.

[0010] Based on the business dependencies of each sub-business request, determine the scheduling strategy of the intelligent agent component that matches each sub-business request;

[0011] Based on the scheduling strategy, the corresponding intelligent agent components are scheduled to process the corresponding sub-business requests, and the sub-request processing results of each sub-business request are obtained.

[0012] Based on the processing results of all sub-requests, the processing result of the business request is generated.

[0013] In one embodiment, based on the business dependencies of each sub-service request, a scheduling strategy for the intelligent agent component matching each sub-service request is determined, including:

[0014] Determine the dependency paths of each sub-business request from the knowledge graph based on business dependencies;

[0015] Based on the dependency path and the matching relationship between each sub-business request and multiple intelligent agent components, an intelligent agent component chain network is constructed by intelligent agent components that match each sub-business request. The intelligent agent component chain network is used to represent the execution order among intelligent agent components that match each sub-business request.

[0016] Based on the interaction rules of intelligent agent components, the cooperative constraint information between adjacent intelligent agent components in the intelligent agent component chain network is determined; wherein, the cooperative constraint information includes the interaction protocol type, data transmission format and interaction response time that must be satisfied for adjacent intelligent agent components to work together.

[0017] Based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network, the scheduling strategy of the intelligent agent component that matches each sub-business request is determined.

[0018] In one embodiment, based on the cooperative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network, a scheduling strategy for intelligent agent components matching each sub-service request is determined, including:

[0019] Based on whether the cooperative constraint information between all two adjacent intelligent agent components in the intelligent agent component chain network satisfies the cooperative constraint conditions, multiple valid component chains are determined from the intelligent agent component chain network;

[0020] Based on the business dependencies of sub-business requests in the valid component chains, determine the relationships between all valid component chains;

[0021] Based on the relationships between all valid component chains, all valid component chains are sorted to obtain the scheduling order of all valid component chains.

[0022] Based on the scheduling order of all valid component chains and the execution order of each agent component in each valid component chain, the scheduling strategy of the agent component that matches each sub-service request is determined.

[0023] In one embodiment, the method further includes:

[0024] In the intelligent agent component chain network, if the cooperative constraint information between two adjacent intelligent agent components does not meet the cooperative constraint conditions, the intelligent agent component chain is determined to be an invalid component chain.

[0025] Rematch agent components for the corresponding subtasks in the invalid component chain; reconstruct the agent component chain network based on the rematched agent components to obtain the reconstructed agent component chain network; or,

[0026] For invalid component chains that do not meet the cooperative constraints, match the subtasks corresponding to at least one of two adjacent agent components to the general agent component; reconstruct the agent component chain network based on the general agent component to obtain the reconstructed agent component chain network; or...

[0027] The process of repeatedly determining whether there are invalid component chains in the reconstructed intelligent agent component chain network continues until the reconstructed intelligent agent component chain network is obtained, until there are no invalid component chains in the reconstructed intelligent agent component chain network.

[0028] Based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network, and the execution order of each intelligent agent component in each valid component chain, the scheduling strategy of the intelligent agent component that matches each sub-business request is determined.

[0029] In one embodiment, based on the processing results of all sub-requests, a processing result for the business request is generated, including:

[0030] Determine the result attribute information of all sub-request processing results; the result attribute information of sub-request processing results includes data attributes, status attributes, and business process attributes;

[0031] Based on the result attribute information of all sub-request processing results, all sub-request processing results are divided into multiple related result groups, and the sub-request processing results in each related result group have related result attribute information.

[0032] Based on the business process attributes corresponding to the processing results of each sub-request in each associated result group, determine the result dependencies of different associated result groups;

[0033] The processing results of all sub-requests are integrated based on the result dependencies to obtain the processing result of the business request.

[0034] In one embodiment, the result dependency includes process sequence information of the associated result group. Based on the result dependency, the processing results of all sub-requests are integrated to obtain the processing result of the business request, including:

[0035] Based on the result dependency, starting from the earliest associated result group in the process sequence information, connect the associated result groups with dependencies in sequence to obtain at least two associated result paths;

[0036] Based on the association type between adjacent pairwise association result groups in each associated result path, determine the result attribute matching information between all sub-request processing results in the corresponding adjacent association result groups; the association type includes at least one of data inheritance association, status transmission association, or process connection association.

[0037] Based on the result attribute matching information and association type of all adjacent associated result groups in each associated result path, the association complexity of the corresponding associated result path is determined.

[0038] Based on the complexity of association, all associated result paths are hierarchically divided to obtain the hierarchical division results of all associated result paths;

[0039] Based on the hierarchical division results, the processing results of all sub-requests are integrated to obtain the processing result of the business request.

[0040] In one embodiment, based on the hierarchical division result, the processing results of all sub-requests are integrated to obtain the processing result of the business request, including:

[0041] Based on the hierarchical division results, each level is determined as the current level from top to bottom;

[0042] The integration result of the previous level is combined with the sub-request processing result of the current level to obtain the integration result of the current level; when the current level is the first level, the integration result of the current level is the integration result of the sub-request processing result of the first level.

[0043] Based on the integration results at the lowest level, the processing outcome of the business request is determined.

[0044] In one embodiment, the method further includes:

[0045] Obtain key information about the processing results of business requests across different metrics; these metrics include business status metrics, business data summary metrics, and business process progress metrics.

[0046] By integrating the key information from all indicator results, we obtain the integrated result information;

[0047] The fusion results will be displayed in a preset format to respond to user business requests.

[0048] Secondly, this application also provides a service processing apparatus applied to a service processing platform, the service processing platform including multiple intelligent agent components, each intelligent agent component being used to process services corresponding to at least one service type, the apparatus including:

[0049] The request retrieval module is used to retrieve user business requests;

[0050] The request splitting module is used to split business requests based on the user's intent information in the business request, resulting in multiple sub-business requests;

[0051] The matching module is used to match the corresponding intelligent agent component for each sub-business request from multiple intelligent agent components based on the association element information between each sub-business request; the association element information of the sub-business request includes the business operation type, required data type and business dependency relationship of the corresponding sub-business request;

[0052] The scheduling strategy determination module is used to determine the scheduling strategy of the intelligent agent component that matches each sub-service request based on the service dependency relationship of each sub-service request.

[0053] The request processing module is used to schedule the corresponding intelligent agent components to process the corresponding sub-business requests based on the scheduling strategy, and obtain the sub-request processing results of each sub-business request.

[0054] The result generation module is used to generate the processing result of the business request based on the processing results of all sub-requests.

[0055] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the business processing method in any of the above embodiments.

[0056] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the business processing method in any of the above embodiments.

[0057] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the business processing method in any of the above embodiments.

[0058] The aforementioned business processing method, apparatus, computer equipment, and storage medium decompose complex business requirements based on the user's intent information within the request, resulting in sub-business requests corresponding to different user intents. Further, each sub-business request is matched with a corresponding intelligent agent component based on its associated element information, ensuring that the sub-business requests match the capabilities of the intelligent agent components in terms of business operation type, required data type, and business dependencies. Then, based on the business dependencies between sub-business requests, a scheduling strategy is determined for all intelligent agent components matching each sub-business request. This precise matching of sub-business requests and intelligent agent components through associated element information avoids business execution failures caused by intelligent agent component mismatch. Next, the corresponding intelligent agent components are scheduled to execute the sub-business requests according to the scheduling strategy, thereby obtaining the processing results for all sub-business requests. The scheduling strategy ensures that each intelligent agent component executes its corresponding sub-business request in a reasonable order and under correct triggering conditions, achieving orderly, accurate, and efficient decomposition and execution of complex user business requests. This improves the accuracy and efficiency of business processing, ensuring that user business requests receive rapid responses while adhering to business logic, thus enhancing the overall operational efficiency of the service platform. Finally, the processing results of all sub-requests are merged to obtain the processing result corresponding to the user's business request, thereby generating comprehensive and user-relevant business response information. This not only ensures the completeness and accuracy of the response information but also improves the user's understanding of the business processing results, further enhancing the overall operational efficiency of the service platform. Attached Figure Description

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

[0060] Figure 1 This is a schematic diagram illustrating an application scenario of a business processing method provided in an embodiment of this application;

[0061] Figure 2 This is a flowchart illustrating a business processing method provided in an embodiment of this application;

[0062] Figure 3 This is a flowchart of a method for determining the scheduling strategy of intelligent agent components when the cooperative constraint information between all two adjacent intelligent agent components in an intelligent agent component chain network satisfies the cooperative constraint conditions, according to an embodiment of this application.

[0063] Figure 4This is a schematic diagram of the structure of a business processing device provided in an embodiment of this application;

[0064] Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0067] The business processing method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown. Figure 1 This is a schematic diagram illustrating an application scenario of a business processing method provided in an embodiment of this application, such as... Figure 1 As shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located in the cloud or on other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0068] In one exemplary embodiment, Figure 2 This is a flowchart illustrating a business processing method provided in an embodiment of this application, applied to... Figure 1Taking server 104 as an example, server 104 can be a business processing platform in this embodiment of the application. This business processing platform includes multiple pre-trained agent components, each agent component being used to process at least one business type. For example... Figure 2 As shown, the method may include the following steps:

[0069] Step 201: Obtain the user's business request.

[0070] For example, a user can input a service request on the terminal, and further, the terminal transmits the user's service request to the server, thereby enabling the server to obtain the user's service request.

[0071] As an example, in a vehicle charging service scenario, users can output business requests related to vehicle charging services on the terminal. Input formats include, but are not limited to, text descriptions, speech-to-text conversion, and handwriting. For example, a user could input, "I am currently near the city center and would like to find a charging station that supports fast charging. I would also like to reserve a charging space in advance to avoid not finding a spot when I arrive," and this content could be used as the user's business request.

[0072] Step 202: Based on the user's intent information in the business request, split the business request into multiple sub-business requests.

[0073] Furthermore, in complex business scenarios, user business requests may include multiple intents. Therefore, user intent analysis can be performed on the acquired business requests, and the business requests can be split according to the user intents to obtain multiple sub-business requests, each of which has a corresponding user intent.

[0074] Specifically, the server can accurately determine a user's core needs by parsing the semantics, keywords, and contextual information in the user's business requests. Semantic parsing refers to a complete understanding of the meaning of the user's expressed statements; keyword extraction refers to filtering out key information that reflects the user's core needs; and contextual information parsing refers to a comprehensive judgment based on the user's historical business records and the complete expression logic of the currently submitted request. Furthermore, during the recognition process, the server matches the user's business request with a pre-built charging service domain intent library. This intent library can be pre-constructed and contains a set of all possible categories of core user charging-related needs, such as charging station query requests, charging reservation requests, charging fee inquiries, charging fault reporting requests, and charging bill payment requests. During the matching process, the server compares the semantic features and keywords of the user's business request with the definition features of various intents in the intent library to eliminate interference from ambiguous requests and determine the unique core business intent.

[0075] As an example, a user submits a business request: "I'm currently near the city center and want to find a charging station that supports fast charging. I also hope to reserve a charging space in advance to avoid not finding one when I arrive." After receiving this request, the server activates its intent recognition capability, parsing the semantics of the request: the user's current location is near the city center, the core need is to find a fast charging station, and they need to reserve a charging space in advance; keywords are extracted: "city center," "fast charging," "station," "reserve in advance," and "charging space"; combined with contextual information, the user hasn't mentioned any other unrelated requests, and the user has multiple fast charging reservation records in their historical business history, further verifying the direction of the request. The business request matches this request with the charging service domain intent database, ultimately determining the user's intent as "fast charging station search and charging space reservation request."

[0076] Furthermore, the user's intent information is associated with business scenarios. An associated business scenario refers to the set of specific business steps that must be involved in realizing the intent information. Each intent information corresponds to one or more interrelated business scenarios, and there are clear business logic connections between the scenarios.

[0077] Furthermore, business requests are split based on related business scenarios. Specifically, the server activates its business splitting capability, splitting user business requests according to the business process correlation within the related business scenarios. This business splitting capability refers to the server's ability to break down a complete user business request into multiple independently executable sub-business requests that conform to the business process sequence, based on the related business scenarios corresponding to the business intent. Business process correlation means that the split sub-business requests follow the logical sequence and dependencies of actual business processing; that is, the execution result of one sub-business request is a prerequisite for the execution of the next sub-business request, or there is a parallel but simultaneous correlation between multiple sub-business requests.

[0078] Optionally, during the splitting process, the server must ensure that each sub-business request is a complete and independently executable request. A sub-business request refers to the specific execution request of a single business link in the related business scenario after splitting, with a clear execution goal and execution object. The splitting is based on the implementation logic of the business intent, that is, which specific business links must be completed sequentially or in parallel to fulfill the user's core request. Each business link corresponds to a sub-business request, and the split sub-business requests cover all necessary links for realizing the business intent, without omissions or redundancy.

[0079] As an example, based on the user intent information "fast charging station query and charging space reservation request," the corresponding related business scenarios are determined to be "charging station filtering scenario," "charging space availability query scenario," and "charging space reservation scenario." The server breaks down the business request according to the business process correlation: The first step is to complete the filtering of charging stations supporting fast charging around the city center, corresponding to the sub-business request "query the list of charging stations supporting fast charging around the city center"; the second step is to confirm whether there are any available charging spaces among the filtered stations, corresponding to the sub-business request "query the currently available charging spaces and available time slots at the filtered fast charging stations"; the third step is to complete the reservation of a parking space that meets the user's needs, corresponding to the sub-business request "select the target station and reservation time slot according to the user's needs, and submit a charging space reservation application." The three sub-business requests follow the business process correlation of "querying stations first → confirming parking space availability → completing the reservation finally."

[0080] Step 203: Based on the associated element information of each sub-business request, match the corresponding intelligent agent component for each sub-business request from multiple intelligent agent components.

[0081] The associated information of a sub-business request includes the business operation type, required data type, and business dependencies of the corresponding sub-business request.

[0082] Furthermore, based on the relationships between the sub-business requests, the corresponding related element information is determined in the knowledge graph. The related element information of the sub-business requests includes the business operation type, the data type of the requirement, and the business dependency relationship of the corresponding sub-business request.

[0083] As an example, in a vehicle charging service scenario, the server pre-stores a charging service business knowledge graph. This knowledge graph is a structured set of knowledge containing all business operations, business data, and business relationships within the charging service domain, used to store and associate various charging service-related elements. Specifically, the server traverses this charging service business knowledge graph based on the relationships between each sub-business request to obtain the associated element information for each sub-business request, namely, the business operation type, required data type, and business dependency relationship for each sub-business request. The business association elements include the business operation type, business data requirement type, and business dependency relationship type. The business operation type refers to the specific business action category that the sub-business request needs to perform, such as query operations, reservation operations, and filtering operations. The required data type refers to the category of business data that the sub-business request needs to obtain or use during execution, such as site location data, charging equipment parameter data, parking space status data, and reservation time period data. Business dependencies refer to the categories of dependency attributes between sub-business requests and other sub-business requests, such as prerequisite dependencies (other sub-business tasks must be executed before this task can be executed), no dependencies (can be executed independently), and parallel dependencies (executed simultaneously with other sub-business tasks).

[0084] Furthermore, the capability element information of each intelligent agent component is determined. Capability element information refers to the set of attributes related to the business processing capabilities possessed by each intelligent agent component, including the types of business operations it can process, the types of business data it can provide, and the types of business dependencies it can adapt to. Specifically, the types of business operations it can process refer to the specific categories of business actions that the intelligent agent component can execute; the types of business data it can provide refer to the categories of business data that the intelligent agent component can output or invoke during task execution; and the types of business dependencies it can adapt to refer to the categories of dependency attributes between sub-business requests that the intelligent agent component can be compatible with.

[0085] Furthermore, the server compares and matches the associated element information of each sub-service request with the capability element information of each intelligent agent component one by one. The matching criteria are as follows: the business operation type of the sub-service request belongs to the business operation type that a certain intelligent agent component can handle; the data type required by the sub-service request belongs to the business data type that the intelligent agent component can provide; and the business dependency type of the sub-service request belongs to the business dependency type that the intelligent agent component can adapt to. Only when all three conditions are met can it be determined that there is a matching relationship between the sub-service request and the intelligent agent component. Finally, a matching relationship set between each sub-service request and its corresponding intelligent agent component is obtained, and the intelligent agent component matched with each sub-service request can be determined based on this matching relationship set.

[0086] As an example, in the above process, the first sub-business request is: "Query the list of charging stations supporting fast charging around the city center"; the second sub-business request is: "Query the currently available charging spaces and available time slots at the filtered fast charging stations"; and the third sub-business request is: "Select the target station and reservation time slot according to the user's needs, and submit a charging space reservation application." Based on the dependency relationship between the three sub-business requests—"filter stations first → query parking spaces then → submit reservation finally"—the relevant elements of each sub-business request are extracted from the charging service business knowledge graph.

[0087] Specifically, the associated elements of the first sub-business request are: business operation type "site filtering operation", required data type "site location data, charging device type data", and business dependency type "no dependency"; the associated elements of the second sub-business request are: business operation type "parking space status query operation", required data type "site identification data, parking space occupancy status data, time period availability data", and dependency type "pre-dependency" (depending on the execution result of the first sub-business); the associated elements of the third sub-business request are: business operation type "parking space reservation submission operation", required data type "target site identification data, reservation time period data, user identity data", and business dependency type "pre-dependency" (depending on the execution result of the second sub-business task).

[0088] Obtain the preset intelligent agent component capability information:

[0089] Site filtering intelligent agent component: The business operation types it can handle include "site filtering operation", the business data types it can provide include "site location data, charging device type data", and the business dependency types it can adapt to include "no dependency".

[0090] Parking space query intelligent agent component: The business operation types it can handle include "parking space status query operation", the business data types it can provide include "site identification data, parking space occupancy status data, time period availability data", and the business dependency types it can adapt to include "pre-dependencies".

[0091] The intelligent agent component for reservation submission can handle business operation types including "parking space reservation submission operation", provide business data types including "target site identification data, reservation time period data, and user identity data", and adapt to business dependency types including "pre-dependencies".

[0092] The matching relationships were obtained through matching and comparison: the first sub-business request matched the site filtering intelligent agent component, the second sub-business request matched the parking space query intelligent agent component, and the third sub-business request matched the reservation submission intelligent agent component.

[0093] Step 204: Based on the business dependencies of each sub-business request, determine the scheduling strategy of the intelligent agent component that matches each sub-business request.

[0094] Furthermore, a sub-business request dependency graph is constructed based on the business dependencies of each sub-business request and the knowledge graph. Then, the scheduling strategy of the intelligent agent component matching each sub-business request is determined based on the sub-business request dependency graph.

[0095] Specifically, the business dependencies of each sub-service request are obtained. These dependencies refer to explicit information such as which sub-service requests depend on which, and which are prerequisites for another. Further, based on these dependencies, the server traverses the charging service business knowledge graph to confirm and supplement the dependency details between sub-service requests, ensuring the accuracy and completeness of the dependencies. Subsequently, a dependency graph is constructed, which is a graphical structure that visually displays the dependencies between sub-service requests. Each node represents a sub-service request, and each node uniquely corresponds to one sub-service request. Directed edges in the graph represent the dependencies between sub-service requests. The direction of the directed edges is from the dependent sub-service request to the dependent sub-service request; that is, the dependent sub-service request acts as a prerequisite task, and only after its execution can the dependent sub-service requests be executed. The direction of the directed edges clarifies the order of task execution, thereby determining the scheduling strategy of the intelligent agent components corresponding to each sub-service request.

[0096] It should be noted that the scheduling strategy of intelligent agent components can refer to the complete execution plan of when each intelligent agent component executes, what sub-business tasks it executes, and how it transmits data.

[0097] Step 205: Based on the scheduling strategy, schedule the corresponding intelligent agent components to process the corresponding sub-service requests, and obtain the sub-request processing results of each sub-service request.

[0098] Furthermore, according to the determined scheduling strategy, the corresponding agents in the scheduling server execute the corresponding sub-service requests, thereby obtaining the sub-request processing results of each sub-service request.

[0099] As an example, the site filtering agent component executes the first sub-business request mentioned above and obtains the processing result of the first sub-request; the parking space query agent component executes the second sub-business request mentioned above and obtains the processing result of the second sub-request; the reservation submission agent component executes the third sub-business request mentioned above and obtains the processing result of the third sub-request.

[0100] Specifically, the server schedules the corresponding intelligent agent components to execute their respective sub-business requests according to the strategy. Each sub-business request is handled independently by the matched intelligent agent component. During the execution process, the operation is completed according to the preset business rules. Finally, each intelligent agent component returns the execution result of the corresponding sub-business request. The execution result is the sub-request processing result, which refers to the specific data, operation feedback information, etc. generated by the intelligent agent component after executing the sub-business.

[0101] Step 206: Based on the processing results of all sub-requests, generate the processing result of the business request.

[0102] As an example, the processing results of all sub-requests can be merged based on the business dependencies between the sub-requests to obtain the processing result of the user's business request.

[0103] In the above implementation process, business requests are broken down based on user intent information within the user's business request, thereby decomposing complex business requirements into sub-business requests corresponding to different user intents. Further, each sub-business request is matched with a corresponding intelligent agent component based on its associated element information, ensuring that the sub-business requests match the capabilities of the intelligent agent components in terms of business operation type, required data type, and business dependencies. Then, based on the business dependencies between sub-business requests, a scheduling strategy for all intelligent agent components matching each sub-business request is determined. This precise matching of sub-business requests and intelligent agent components through associated element information avoids business execution failures caused by intelligent agent component mismatch. Next, the corresponding intelligent agent components are scheduled to execute the sub-business requests according to the scheduling strategy, thus obtaining the processing results for all sub-business requests. The scheduling strategy ensures that each intelligent agent component executes its corresponding sub-business request in a reasonable order and under correct triggering conditions, achieving orderly, accurate, and efficient decomposition and execution of complex user business requests. This improves the accuracy and efficiency of business processing, ensuring that user business requests receive rapid responses while adhering to business logic, thereby enhancing the overall operational efficiency of the service platform. Finally, the processing results of all sub-requests are merged to obtain the processing result corresponding to the user's business request, thereby generating comprehensive and user-relevant business response information. This not only ensures the completeness and accuracy of the response information but also improves the user's understanding of the business processing results, further enhancing the overall operational efficiency of the service platform.

[0104] In one embodiment, determining the scheduling strategy for the intelligent agent component matching each sub-service request based on the service dependencies of each sub-service request may include the following steps:

[0105] Step 1: Determine the dependency paths of each sub-business request from the knowledge graph based on business dependencies.

[0106] For example, a sub-business request dependency graph can be constructed based on business dependencies and a knowledge graph, thereby determining the dependency path of each sub-business request based on the knowledge graph.

[0107] Specifically, during the construction of the sub-business request dependency graph, the server must ensure that each sub-business request corresponds to a node, and that all business dependencies are fully represented by directed edges without omissions or errors, so as to ensure that the sub-business request dependency graph can accurately reflect the execution logic relationship between sub-business requests.

[0108] As such, the above three sub-business requests and their corresponding business dependencies are as follows: the second sub-business request depends on the execution result of the first sub-business request, and the third sub-business request depends on the execution result of the second sub-business request.

[0109] The server traverses the charging service business knowledge graph to confirm dependency details: the first sub-business request does not depend on other tasks and can be executed independently; the second sub-business request can only be executed after the first sub-business request is completed and the site list is output; the third sub-business request can only be executed after the second sub-business request is completed and the available parking spaces and times are output.

[0110] Subsequently, a sub-service request dependency graph is constructed: the three sub-service requests are treated as three independent nodes. A directed edge is drawn between the first and second sub-service request nodes, with the direction pointing from the first sub-service request node to the second sub-service request node, representing that the second sub-service request depends on the first sub-service request; a directed edge is drawn between the second and third sub-service request nodes, with the direction pointing from the second sub-service request node to the third sub-service request node, representing that the third sub-service request depends on the second sub-service request.

[0111] Then, based on the sub-business request dependency graph, starting from each sub-business request, traverse all reachable sub-business requests, locate the predecessor and successor dependent requests of each sub-business request, and obtain the dependency path of each sub-business request in the dependency relationship.

[0112] As an example, the server starts from the node corresponding to each sub-business request based on the sub-business request dependency graph, and traverses all reachable sub-business request nodes along the pointing and reverse pointing of directed edges. A reachable sub-business request node is a node that can be associated with the starting node through one or more directed edges.

[0113] Optionally, during the traversal, the server locates the predecessor and successor dependent requests for each sub-business request. A predecessor dependent request refers to a sub-business task request that the current sub-business request depends on and needs to be executed before it; that is, the sub-business request corresponding to the node pointed to by the current node through a directed edge. A successor dependent request refers to a sub-business request that depends on the current sub-business request and needs to be executed after it; that is, the sub-business request corresponding to the node pointed to by the current node through a directed edge.

[0114] Furthermore, the server analyzes the predecessor and successor dependent requests of each sub-business request, clarifies the position of each sub-business request in the entire dependency network, and obtains the dependency path of each sub-business request in the dependency relationship. Therefore, the dependency path refers to the complete task execution chain from the initial sub-business request without dependencies, through the intermediate dependent requests, to the final sub-business request without subsequent dependencies. It can clearly show the execution order and related transmission logic of all sub-business requests.

[0115] As an example, in the above sub-business request dependency graph, the server starts from the first sub-business request node and traverses the reachable nodes: the second sub-business request node can be reached along the directed edge, and the third sub-business request node can be reached from the second sub-business request node along the directed edge. Therefore, the successor dependency of the first sub-business request is the second sub-business request, and there is no predecessor dependency request.

[0116] Starting from the second sub-business request node, traverse the reachable nodes: the first sub-business request node can be reached by following the directed edges in the reverse direction, and the third sub-business request node can be reached by following the directed edges in the forward direction. Therefore, the predecessor dependency of the second sub-business request is the first sub-business request, and the successor dependency is the third sub-business request.

[0117] Starting from the third sub-business request node, traversing the reachable nodes: the second sub-business request node can be reached by following the directed edge in the reverse direction, and the first sub-business request node can be reached by following the reverse edge in the reverse direction. Therefore, the predecessor dependency of the third sub-business request is the second sub-business request, and there is no successor dependency.

[0118] The final dependency path is: first sub-business request → second sub-business request → third sub-business request.

[0119] Step 2: Based on the dependency path and the matching relationship between each sub-business request and multiple intelligent agent components, construct an intelligent agent component chain network by matching the intelligent agent components with each sub-business request.

[0120] The agent component chain is used to characterize the execution order among agent components that match each sub-business request.

[0121] As an example, the matching relationship can be a structured data set recording each sub-business request and its corresponding matched intelligent agent component. This data set includes the unique identifier of each sub-business request, its corresponding associated element information, and the unique identifier and capability element information of the successfully matched intelligent agent component. Specifically, in complex business scenarios, the dependency paths corresponding to business requests may include multiple paths. Based on this matching relationship, an intelligent agent component is matched to each sub-business request in each dependency path. Then, based on the order of the sub-business requests in the dependency path, the intelligent agent components corresponding to each sub-business request are sequentially linked together to obtain a network of intelligent agent components for each dependency path.

[0122] Optionally, the server matches one intelligent agent component for each sub-business request in each dependency path based on the matching relationship. The selection principle is to prioritize the intelligent agent component with the highest matching degree with the sub-business request and the highest historical execution success rate. The highest matching degree means that the matching conditions of the associated element information and the capability element information are fully met. The highest historical execution success rate means that the intelligent agent component has the highest proportion of successful executions of the same type of sub-business request in the past out of the total number of executions.

[0123] Furthermore, based on the sequential order of sub-service requests within the dependency path, the server concatenates the intelligent agent components corresponding to each sub-service request in the same order, forming an intelligent agent component chain for each dependency path. An intelligent agent component chain refers to a set of components composed of multiple intelligent agent components arranged in a specific order, used to execute all sub-service requests in the corresponding dependency path. The order of these components must be completely consistent with the order of the sub-service requests in the corresponding dependency path, and the output of the preceding intelligent agent component must meet the input requirements of the following intelligent agent component in processing the corresponding sub-service task request. That is, the execution result data generated by the preceding intelligent agent component after executing the sub-service can be directly used as the input data required by the following intelligent agent component when executing the corresponding sub-service intelligent agent request, without additional data conversion or supplementation. Finally, all intelligent agent component chains are used to construct an intelligent agent component chain network. If there is only one intelligent agent component chain in the intelligent agent component chain network, then the corresponding intelligent agent component chain network is a single intelligent agent component chain network.

[0124] As an example, based on the above matching relationships and dependency paths, the server connects the three intelligent agent components in sequence according to the dependency paths, forming an intelligent agent component chain network: site filtering intelligent agent component → parking space query intelligent agent component → reservation submission intelligent agent component. Specifically, the output of the site filtering intelligent agent component (a list of charging stations supporting fast charging around the city center and station identification data) meets the input requirements of the parking space query intelligent agent component (requiring station identification data to query the corresponding parking space status); the output of the parking space query intelligent agent component (reservable charging station identification, parking space number, and available time period) meets the input requirements of the reservation submission intelligent agent component (requiring target station identification, parking space number, and reservation time period to complete the reservation application).

[0125] Step 3: Based on the interaction rules of the agent components, determine the cooperative constraint information between adjacent agent components in the agent component chain network.

[0126] Among them, the cooperative constraint information includes the type of interaction protocol, data transmission format, and interaction response time that must be satisfied for adjacent intelligent agent components to work together.

[0127] Furthermore, the server obtains the pre-stored interaction rules of the intelligent agent components. The interaction rules refer to the set of preset rules that each intelligent agent component must follow when interacting with other intelligent agent components and working collaboratively. These rules include core elements such as interaction protocol type, data transmission format requirements, and interaction response time.

[0128] Based on the interaction rules, the collaborative constraint information between adjacent intelligent agent components in each intelligent agent component chain can be extracted. This collaborative constraint information refers to the interaction attribute requirements that must be met for two adjacent intelligent agent components to achieve effective collaborative work, including the interaction protocol type, data transmission format requirements, and interaction response time. Specifically, the interaction protocol type refers to the communication protocol standard followed when intelligent agent components exchange data and commands, such as Hypertext Transfer Protocol (HTTP) or custom private communication protocols; the data transmission format requirements refer to the data structure specifications that intelligent agent components must follow when transmitting data, such as JSON, XML, or structured text formats; and the interaction response time refers to the time threshold within which the next intelligent agent component must receive and initiate processing data after the previous intelligent agent component outputs data, such as within 1 second or within 3 seconds.

[0129] Step 4: Based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network, determine the scheduling strategy of the intelligent agent component that matches each sub-service request.

[0130] Furthermore, in the intelligent agent component chain network, the corresponding intelligent agent component chain is determined to satisfy the cooperative constraint conditions based on the cooperative constraint information between all two adjacent intelligent agent components in each intelligent agent component chain. Then, the scheduling strategy of the intelligent agent component matching each sub-service request is determined based on the intelligent agent component chain that satisfies the cooperative constraint conditions.

[0131] It should be noted that each sub-service request may have multiple matching intelligent agent components. In the corresponding intelligent agent component chain network, there may be multiple intelligent agent component chains that can complete the service request. In order to achieve collaborative operation between adjacent intelligent agent components in the intelligent agent component chain, the intelligent agent component chains that meet the collaborative constraint conditions can be filtered through collaborative constraint information, thereby determining the scheduling strategy of the intelligent agent components.

[0132] Based on the collaborative constraint information of each intelligent agent component chain, it can be determined whether all adjacent intelligent agent components in the chain meet the collaborative constraint conditions.

[0133] The criteria for determining the cooperative constraint conditions are as follows: Adjacent intelligent agent components support the same interaction protocol type, meaning the output protocol of the preceding intelligent agent component is consistent with the input protocol of the following intelligent agent component; the output data transmission format of the preceding intelligent agent component conforms to the input data transmission format requirements of the following intelligent agent component, requiring no additional format conversion or enabling conversion through the component's own adaptation; the output response time of the preceding intelligent agent component meets the interaction response time requirements of the following intelligent agent component, meaning the following intelligent agent component can initiate processing within a specified time after receiving data. Only when all adjacent intelligent agent components meet the above three conditions is the intelligent agent component chain considered to satisfy the cooperative constraint conditions; if any pair of adjacent intelligent agent components fails to meet any one of the conditions, the intelligent agent component chain does not satisfy the cooperative constraint conditions.

[0134] As an example, the intelligent agent component chain constructed above is: site filtering intelligent agent component → parking space query intelligent agent component → reservation submission intelligent agent component. The server retrieves the interaction rule information of each component:

[0135] Site filtering intelligent agent component: The interaction protocol type is Hypertext Transfer Protocol, the data transmission format is required to be JSON, and the interaction response time requirement is that the output data is received within 1 second.

[0136] Parking space query intelligent agent component: The interaction protocol type is Hypertext Transfer Protocol, the data transmission format is required to be JSON, and the interaction response time requirement is to start processing within 1 second after receiving the data.

[0137] The intelligent agent component for submitting appointments requires the following interaction protocol type: Hypertext Transfer Protocol, data transmission format: JSON, and interaction response time: processing must begin within 1 second of receiving data.

[0138] Determine whether two adjacent agent components satisfy the cooperative constraint:

[0139] The site filtering agent component and the parking space query agent component both use the Hypertext Transfer Protocol (which is consistent) for interaction and JSON format for data transmission (which meets the requirements). The output of the site filtering component can be received by the parking space query component within 1 second (which meets the response time requirement) and meets the collaborative constraint conditions.

[0140] The parking space query agent component and the reservation submission agent component both use the Hypertext Transfer Protocol (which is consistent) for interaction and JSON format for data transmission (which meets the requirements). The parking space query component output can be received by the reservation submission component within 1 second (which meets the response time requirement) and meets the collaborative constraint conditions.

[0141] In the above implementation process, the intelligent agent component chain network is constructed by matching relationships and dependency paths, which ensures the accurate correspondence between intelligent agent components and sub-businesses and the rationality of the execution order, and solves the problems of chaotic allocation of intelligent agent components and reversed execution order. By filtering the intelligent agent component chain through collaborative constraint information, the interaction compatibility between adjacent intelligent agent components is guaranteed, and the collaboration failure caused by mismatch of protocols, formats and response times is avoided, thereby ensuring the accuracy of the scheduling strategy.

[0142] In one embodiment, Figure 3 This application provides a flowchart of a method for determining the scheduling strategy of intelligent agent components when the cooperative constraint information between all adjacent intelligent agent components in an intelligent agent component chain network satisfies the cooperative constraint conditions. Specifically, based on the cooperative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network, the scheduling strategy of the intelligent agent component matching each sub-service request is determined, such as... Figure 3 As shown, the method may include the following steps:

[0143] Step 301: Based on whether the cooperative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network satisfies the cooperative constraint conditions, determine multiple valid component chains from the intelligent agent component chain network.

[0144] For example, each agent component chain in the agent component chain network is traversed, and agent component chains in which the cooperative constraint information between all two adjacent agent components satisfies the cooperative constraint conditions are determined to be valid component chains.

[0145] An effective component chain refers to an intelligent agent component chain that can pass the collaborative constraint verification and can be directly used to execute sub-business requests in the corresponding dependency path.

[0146] Step 302: Based on the business dependencies of sub-business requests in the valid component chains, determine the association relationships between all valid component chains.

[0147] Furthermore, the server obtains the business dependencies of each sub-business request. These dependencies can include association attribute categories between different sub-business requests or different dependency paths, including data sharing associations and result feedback associations. Data sharing associations refer to situations where two or more sub-business requests (or dependency paths) need to use the same business data during execution; that is, certain business data needs to be shared by multiple tasks or paths. Result feedback associations refer to situations where the execution result of one sub-business request (or dependency path) needs to be fed back to another sub-business task request (or dependency path) as a reference or triggering condition for its execution.

[0148] Furthermore, the server can analyze the relationships between all valid component chains based on business dependencies. The analysis logic is as follows: if there is a data-sharing relationship between the sub-business requests corresponding to two valid component chains, then these two valid component chains have a data-sharing relationship; if there is a result feedback relationship between the sub-business requests corresponding to two valid component chains, then these two valid component chains have a result feedback relationship. During the analysis, it is necessary to combine the charging service business knowledge graph and the business dependencies of the sub-business requests to ensure that the relationship determination is accurate and without omissions or misjudgments.

[0149] As an example, suppose a user's business request, after being split, has two dependency paths:

[0150] Path 1 (Main Path): First sub-business request → Second sub-business request → Third sub-business request, corresponding to the first valid component chain: Site filtering intelligent agent component → Parking space query intelligent agent component → Reservation submission intelligent agent component.

[0151] Path 2 (auxiliary path): The fourth sub-business request (querying the charging fee standard of the target site), corresponding to the second valid component chain: fee query intelligent agent component (the matching relationship and collaborative constraint verification have both passed, and it is considered a valid component chain).

[0152] The business dependency relationships include the following business association types: The fourth sub-business request (querying charging fees) and the third sub-business request (submitting an appointment application) have a data sharing relationship (both need to use the target site identifier data), and also have a result feedback relationship (the charging fee query result needs to be fed back to the user as a reference for whether to submit an appointment application).

[0153] The server analyzes the relationships between valid component chains: Valid component chain one (corresponding to the sub-business request of path one) and valid component chain two (corresponding to the sub-business request of path two). Since the corresponding sub-business requests have data sharing relationship and result feedback relationship, the relationship type between the two valid component chains is determined to be "data sharing relationship + result feedback relationship".

[0154] Step 303: Sort all valid component chains based on the relationships between them to obtain the scheduling order of all valid component chains.

[0155] Furthermore, the server constructs a component chain association network based on the relationships between valid component chains. This network is a graphical structure that displays all valid component chains and their relationships. Each node represents a valid component chain, and each node uniquely corresponds to one valid component chain. Edges in the network represent the relationships between valid component chains, and the edge type corresponds one-to-one with the relationship between the valid component chains. That is, if two component chains have a data-sharing relationship, the corresponding edge type is a data-sharing relationship edge; if there is a result feedback relationship, the corresponding edge type is a result feedback relationship edge; if both types of relationships exist simultaneously, the edge type includes both relationship attributes.

[0156] Based on the edge relationships in the component chain association network, the preceding dependent component chains and subsequent associated component chains of each valid component chain are determined. All valid component chains in the component chain association network are sorted according to their preceding dependent component chains to obtain the scheduling order of the valid component chains. Based on the valid component chains, their corresponding scheduling order, and the execution order of each agent component within each valid component chain, the execution timing and execution association of each agent component are determined. The execution order is the sequential order of the agent components in the component chain. Finally, the agent component scheduling strategy is obtained by integrating the valid component chains and the execution timing and execution associations of each agent component.

[0157] The server filters out component chain pairs corresponding to the result feedback association type based on the association relationships of the edges in the component chain association network. Since the determination of pre-dependency and post-association is based only on the result feedback association, data sharing association does not affect the execution order of component chains.

[0158] In this context, a "pre-dependent component chain" refers to a component chain among two valid component chains with a result feedback relationship, where the chain that is depended upon requires the other component chain to wait for and use its execution result. The specific criterion is: if component chain one and component chain two have a result feedback relationship, and component chain two must wait for the execution result of component chain one before it can start execution (i.e., the execution of component chain two depends on the result of component chain one), then component chain one is a pre-dependent component chain of component chain two. A "post-dependent component chain" is the reverse concept relative to a pre-dependent component chain. That is, if component chain one is a pre-dependent component chain of component chain two, then component chain two is a post-dependent component chain of component chain one, indicating that component chain one needs to provide a result to component chain two after execution to support the execution of component chain two.

[0159] Optionally, during the determination process, the server needs to consider the business dependencies of the sub-business requests to confirm the direction of result feedback between component chains, avoiding reversal of dependency determination. For component chains without result feedback relationships, which have no preceding dependent component chains and subsequent related component chains, they can be executed independently.

[0160] As an example, effective component chain one (site selection agent component → parking space query agent component → reservation submission agent component) and effective component chain two (fee query agent component) have a "data sharing association + result feedback association". Based on business dependencies, the execution result of effective component chain two (target site charging fee standard) needs to be fed back to the third sub-business request of effective component chain one (submitting a reservation application). Users need to refer to the fee result to decide whether to submit a reservation. Therefore, effective component chain two must be executed before the reservation submission step of effective component chain one, but it does not need to affect the site selection and parking space query steps of effective component chain one.

[0161] Clearly define the direction of result feedback: The execution result of valid component chain 2 serves as a reference for valid component chain 1 to complete the final reservation submission. The reservation submission step of valid component chain 1 needs to wait for the fee query result of valid component chain 2. Therefore, it is determined that: valid component chain 2 is a preceding dependent component chain of valid component chain 1 (only for the reservation submission step, but the component chain as a whole needs to be clearly defined as chain-level dependency); correspondingly, valid component chain 1 is a subsequent associated component chain of valid component chain 2.

[0162] Furthermore, the server sorts all valid component chains according to their dependencies using a topological sorting method. Topological sorting, in a directed acyclic graph, determines the execution order of nodes based on their dependencies, ensuring that all dependent nodes are executed before the nodes they depend on. It is suitable for sorting multi-node scenarios with sequential dependencies.

[0163] Specifically, during the sorting process, the server identifies all valid component chains without preceding dependent component chains and places them in the first tier of the sorting sequence (which can be executed in parallel). Then, it selects valid component chains that depend only on the first-tier component chains and places them in the second tier of the sorting sequence, requiring all component chains in the first tier to be executed before starting. This process continues until all valid component chains are included in the sorting sequence, forming the scheduling order of the valid component chains. The core rule of the scheduling order is: preceding dependent component chains must execute before their corresponding subsequent related component chains; component chains without dependencies can be scheduled in parallel or in any order, ensuring that the result feedback requirements between component chains are met.

[0164] As an example, effective component chain two (fee query agent component) is a prerequisite component chain for effective component chain one (site filtering → parking space query → reservation submission). Effective component chain one has no other prerequisite components, and effective component chain two has no prerequisite component chains.

[0165] The topological sorting method is used to sort the components: Component chains without prerequisite dependencies are identified. Valid component chain two has no prerequisite dependencies, while the prerequisite dependency of valid component chain one is valid component chain two. Therefore, the first tier consists of valid component chain two. After the first tier is completed, the second tier consists of valid component chain one. The final scheduling order of the valid component chains is: valid component chain two is executed first, followed by valid component chain one.

[0166] Furthermore, based on the scheduling order of the effective component chains and the execution order of each agent component in each effective component chain (i.e., the serial order within the component chain), the execution timing and execution association of each agent component are determined.

[0167] Execution order refers to the sequential order of intelligent agent components within a single valid component chain. This order is determined by the order of sub-business requests in the dependency propagation path, with the output of the preceding component serving as the input of the following component. Execution association refers to the relationship between a single intelligent agent component and other intelligent agent components, comprising two parts: first, intra-chain association, which is the association with the input and output of adjacent intelligent agent components within the same component chain, where the output data of the preceding component serves as the input data of the current component, and vice versa; second, inter-chain association, which is the association with the results of related intelligent agent components in the preceding dependent component chain, where the execution result of the core component in the preceding dependent component chain serves as the reference or triggering condition for the execution of the current component.

[0168] The determination of execution timing follows two layers of logic: First, based on the scheduling order of the effective agent component chains, the overall execution timing of the current agent component's chain is determined (e.g., if the chain is in the second tier, it must start after the first tier component chains have finished executing). Second, based on the execution order of the agent components within the chain, the relative execution timing of the current agent component within the chain is determined (e.g., if the intra-chain order is agent component A → agent component B → agent component C, then agent component B must start after agent component A has finished executing). Through these two layers of timing determination, it is ensured that the execution of each agent component satisfies both inter-chain and intra-chain dependencies.

[0169] As one embodiment, the above scheduling order is as follows: first execute effective component chain two (fee query agent component), then execute effective component chain one (site filtering → parking space query → reservation submission); the determined execution order within the component chains is: within effective component chain one, it is the site filtering agent → parking space query agent → reservation submission agent; within effective component chain two, it is only the fee query agent. The execution timing and execution association of each agent component are determined as follows:

[0170] Fee Inquiry Smart Agent Component (Component Chain Two): Execution timing is in the first tier, with no preceding dependent component chains and no preceding or following components within the chain. Therefore, execution timing is independent startup at the initial stage of business request processing. Execution association is that there is no intra-chain association, and the inter-chain association is that the smart agent component submitting the reservation to the effective component chain one provides feedback on the fee inquiry result.

[0171] Site Filtering Agent Component (Component Chain 1): It is executed as the first execution stage of the second echelon (after Component Chain 1 is started), starting after the Fee Query Agent completes its execution; the execution association is intra-chain association (outputting site list data to the parking space query agent), and there is no inter-chain association (no need to depend on the results of other component chains).

[0172] Parking space query intelligent agent component (component chain 1): The execution time is the second execution stage of the second echelon, which is started after the site screening intelligent agent is completed; the execution association is an intra-chain association (receiving the output data of the site screening intelligent agent and outputting parking space information to the reservation submission intelligent agent), and there is no inter-chain association.

[0173] The appointment submission intelligent agent component (component chain 1) is executed in the third execution stage of the second echelon, after the parking space query intelligent agent completes and receives the feedback result from the fee query intelligent agent; the execution association is intra-chain association (receiving the output data of the parking space query intelligent agent) and inter-chain association (receiving the fee result data of the fee query intelligent agent as a reference for the user's appointment).

[0174] Step 304: Based on the scheduling order of all valid component chains and the execution order of each agent component in each valid component chain, determine the scheduling strategy of the agent component that matches each sub-service request.

[0175] Furthermore, all effective component chains, the execution timing and execution relationships of each intelligent agent component, as well as the collaborative constraints (interaction protocol type, data transmission format, interaction response time) and component chain relationship types are integrated. During the integration process, the execution timing of all intelligent agent components is sorted according to the timeline, clarifying the startup order and execution duration constraints (response time based on collaborative constraints) of each component; the input data sources of each component (output of preceding components within the chain, output of preceding dependent component chains) and the output data destination (input of subsequent components within the chain, input of subsequent related component chains) are sorted out; the interaction rules between components (following collaborative constraints) and conflict handling mechanisms (such as retry rules when data transmission fails) are clarified, resulting in an intelligent agent component scheduling strategy. Therefore, the final intelligent agent component scheduling strategy is a scheme that includes all intelligent agent component execution details, covering core content such as component chain scheduling order, execution timing of individual components, input-output relationships between components, interaction rules, and result feedback paths, ensuring that all intelligent agent components can execute in an orderly and collaborative manner according to the rules.

[0176] In the above implementation process, valid component chains are screened by verifying collaborative constraint information, ensuring the interaction compatibility between adjacent components and avoiding collaboration failures caused by mismatches in protocols, formats, and response times. By analyzing the relationships between valid component chains, the problem of relationship breakage during parallel execution of multiple links is solved. The scheduling order of valid component chains is determined by the relationships, realizing the precise definition of topology sorting, execution timing, and relationships, thereby achieving orderly scheduling of component chains and components within chains and ensuring strict adherence to dependencies. Finally, the integrated scheduling strategy comprehensively covers the details of the entire component execution process, enabling automated and intelligent splitting and collaborative execution of complex, multi-stage, and multi-related user business requests. This improves the accuracy, efficiency, and reliability of business processing, reduces the probability of component interaction conflicts and task execution failures, achieves efficient linkage of service businesses, and improves the overall operational efficiency of the service platform.

[0177] In one embodiment, the method further includes the following steps:

[0178] Step 1: Identify intelligent agent component chains in the intelligent agent component chain network where the cooperative constraint information between two adjacent intelligent agent components does not meet the cooperative constraint conditions as invalid component chains.

[0179] Step 2: Rematch the agent components for the corresponding subtasks in the invalid component chain; reconstruct the agent component chain network based on the rematched agent components to obtain the reconstructed agent component chain network.

[0180] Alternatively, in step 2: split the invalid component chain into multiple valid component sub-chains, and generate a reconstructed agent component chain network based on the multiple valid component sub-chains.

[0181] Alternatively, in step 2: match the subtasks corresponding to at least one of the two adjacent intelligent agent components in the invalid component chain that do not meet the collaborative constraint conditions to the general intelligent agent component; reconstruct the intelligent agent component chain network based on the general intelligent agent component to obtain the reconstructed intelligent agent component chain network.

[0182] Step 3: Repeatedly execute the step of determining whether there are invalid component chains in the reconstructed intelligent agent component chain network until the reconstructed intelligent agent component chain network is obtained, until there are no invalid component chains in the reconstructed intelligent agent component chain network.

[0183] Step 4: Based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network, and the execution order of each intelligent agent component in each valid component chain, determine the scheduling strategy of the intelligent agent component that matches each sub-service request.

[0184] For example, an intelligent agent component chain is constructed based on the matching relationship and dependency path between sub-business requests and intelligent agent components. At this time, the allocation only satisfies the matching of sub-business requests and intelligent agent component capabilities and task dependency order, but does not verify the inter-component collaboration compatibility (such as interaction protocol type, data transmission format, and interaction response time).

[0185] Therefore, it is possible to determine whether the collaborative constraint information between two adjacent agent components in an agent component chain satisfies the collaborative constraint conditions (such as interaction protocol type, data transmission format, and interaction response time), and thus determine whether the agent component chain is valid. An invalid component chain is an agent component chain in which the collaborative constraint information between any two adjacent agent components does not satisfy the collaborative constraint conditions (such as the output format of agent component A being incompatible with the input format of agent component B).

[0186] At this point, the sub-business request is assigned to the intermediate state of the preliminary matching in the invalid component chain, rather than the final execution assignment. In order to ensure that all sub-business requests can be executed by the intelligent agent component and to guarantee the integrity of the user request response, the invalid component chain needs to be corrected.

[0187] As an example, we can rematch agent components for subtasks to reconstruct a valid component chain. The essence of an invalid component chain is incompatibility in inter-component collaboration, not a lack of matching agent components for sub-business requests. A sub-business request can have matching relationships with multiple agent components (not a unique match), so we can rematch agent components for the corresponding subtasks in the invalid component chain based on these matching relationships. Specifically, based on these matching relationships, for subtasks in the invalid component chain that do not meet the collaboration constraints, we rematch agent components for at least one of the two adjacent agent components, thus facilitating the reconstruction of a valid component chain.

[0188] For example, the agent component chain for sub-service request 1 → sub-service request 2 is: Agent Component A → Agent Component B. However, because the interaction protocol types of Agent Component A and Agent Component B are incompatible, this initial agent component chain is determined to be invalid. Then, based on the matching relationship between sub-service requests and agent components, another matching agent component is selected for sub-service request 1. For example, if Agent Component A' has the same capabilities as Agent Component A, but its interaction protocol type is compatible with Agent Component B, then sub-service request 1 is rematched with Agent Component A', and a valid component chain is reconstructed: Agent Component A' → Agent Component B.

[0189] Then, based on the reconstructed valid component chains, a reconstructed agent component chain network is formed, and the cooperative constraints in the reconstructed agent component chain network are verified again until there are no invalid component chains in the reconstructed agent component chain network.

[0190] As another example, invalid component chains are split and downgraded into independent valid sub-chains. Specifically, if a complete component chain becomes invalid as a whole due to incompatibility in a certain section, the invalid component chain is split into multiple short chains, the validity of each short chain is verified, and then they are recombined through inter-chain associations.

[0191] For example, if the dependency path is sub-service request 1 → sub-service request 2 → sub-service request 3, the agent component chain is: agent component A → agent component B → agent component C. However, agent component B and agent component C are incompatible (causing the entire chain to be invalid). Therefore, this agent component chain is split into two valid component sub-chains: agent component A → agent component B (sub-chain 1) and agent component C' (sub-chain 2, where Agent-C' is another matching agent component for sub-service request 3). After verifying the validity of each sub-chain, they are re-associated through inter-chain data transfer (the output of sub-chain 1 is passed to sub-chain 2). This reconstructs the agent component chain network based on the multiple valid component sub-chains, ensuring that sub-service requests 1-3 can all be executed.

[0192] As another example, a general intelligent agent component is enabled. This component possesses the basic processing capabilities for all sub-business requests, ensuring basic execution. Specifically, a general intelligent agent component can be pre-configured. This component has basic business capabilities and is compatible with the interaction rules of most components. When all matching intelligent agent components for a sub-business request cannot form a valid component chain, the general sub-business request is enabled to execute the sub-business request, ensuring the completion of basic functions.

[0193] For example, sub-service request 2 matches agent components B and B1, but they are incompatible with the collaboration of the preceding and following components. In this case, enabling the general agent component B2 (which supports general data formats and protocols) allows the agent component chain to be reconstructed based on the matched general agent components. This reconstructed agent component chain ensures that sub-service request 2 can be completed without blocking dependency paths.

[0194] As another example, the business dependencies of sub-business requests can be rearranged to avoid invalid chains. Specifically, if an invalid component chain is caused by an unreasonable dependency path (e.g., sub-business request A depends on sub-business request B, but the intelligent agent component of A cannot coordinate with the intelligent agent component of B), the business dependencies of sub-business requests can be further reorganized based on the charging service business knowledge graph, the execution order of sub-business requests can be adjusted, the dependency path can be reconstructed, and thus an effective component chain can be built.

[0195] For example, the original dependency path is: Sub-business request B → Sub-business request A. The corresponding agent component chain, Agent Component B → Agent Component A, is invalid. After traversing again and using the knowledge graph, it is found that Sub-business request A can be executed independently (without any prerequisites). The adjusted dependency path is: Sub-business request A → Sub-business request B. The agent component chain, Agent Component A → Agent Component B, is re-matched (if valid) to ensure that all sub-business requests can be executed. The agent component chain network is then reconstructed to obtain the reconstructed agent component chain network.

[0196] Furthermore, all valid component chains are incorporated into the intelligent agent component chain network to obtain a reconstructed intelligent agent component chain network. The step of determining whether there are invalid component chains in the reconstructed intelligent agent component chain network is executed cyclically until the reconstructed intelligent agent component chain network is obtained, until there are no invalid component chains in the reconstructed intelligent agent component chain network. Then, based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network and the execution order of each intelligent agent component in each valid component chain, the scheduling strategy of the intelligent agent component matching each sub-service request is determined.

[0197] Furthermore, the method may also include: incorporating all valid component chains into the agent component chain network to obtain a reconstructed agent component chain network, and traversing the reconstructed agent component chain network to verify whether it covers all sub-business requests. If there are sub-business requests not covered by valid component chains (i.e., the originally allocated agent component chain is invalid and no alternative solution has been found), an emergency matching process will be triggered: expanding the agent component matching scope (including agent components that are not optimally matched but meet the requirements); calling the charging service business knowledge graph to supplement business association elements and optimize matching accuracy; and enabling general agent components for fallback execution.

[0198] In the above implementation process, the problem of invalid component chains being unable to execute sub-business requests was solved by correcting invalid component chains. Since the sub-business request is assigned to the invalid component chain as an intermediate state rather than the final execution state, mechanisms such as re-matching intelligent agent components, splitting and reorganizing component chains, degrading execution, and dependency rearrangement can be used to ensure that each sub-business can find a valid execution path. Through multiple invalid component chain correction mechanisms, full coverage of sub-business requests and completion of the overall task are ensured.

[0199] In one embodiment, generating the processing result of the business request based on the processing results of all sub-requests may include the following steps:

[0200] Step 1: Determine the result attribute information of all sub-request processing results.

[0201] The result attribute information of the sub-request processing result includes data attributes, status attributes, and business process attributes.

[0202] For example, the result attribute information corresponding to the execution result can be identified based on the business dependency information of each sub-business request.

[0203] Specifically, the execution results of the sub-business requests returned by each intelligent agent component are obtained. The execution result refers to the specific data feedback or status feedback generated after each sub-business request is processed by the corresponding intelligent agent component. For example, the result of a query task is a specific data set, and the result of an operation task is the execution success / failure status and related descriptions.

[0204] Furthermore, based on the business dependency information of each sub-business request, the result attribute information corresponding to each execution result is identified. The result attribute information is used to categorize the associated attributes of the execution result, including data attributes, status attributes, and business process attributes. Data attributes refer to attributes that are associated with the specific data content in the execution result, such as site identification data, parking space number data, and fee amount data; status attributes refer to attributes that are associated with the processing status of the execution result, such as execution success status, execution failure status, and pending confirmation status; business process attributes refer to attributes that are associated with the business process steps corresponding to the execution result, such as the site query process step, parking space reservation process step, and fee query process step.

[0205] Specifically, it is necessary to combine the core requirements and business type of each sub-business request, clarify the core related attributes of its execution result, and then determine the corresponding result attribute information to ensure that each execution result can be accurately classified into the corresponding result.

[0206] As an example, the sub-request processing results for each sub-business request are as follows:

[0207] The processing result of the first sub-request (querying a list of charging stations that support fast charging around the city center) is: information on 3 charging stations around the city center that support fast charging, including station name, station ID, detailed address, and number of charging devices.

[0208] The processing results of the second sub-business request (querying the currently available parking spaces and available time periods at the selected fast charging stations) are as follows: Station 1 (identifier 001) has 2 available parking spaces (numbers A01 and A02), with available time periods from 14:00 to 16:00 and 16:30 to 18:30 on the same day; Station 2 (identifier 002) has 1 available parking space (number B03), with available time periods from 15:00 to 17:00 on the same day.

[0209] The processing result of the third sub-business request (submitting a charging parking space reservation application): Reservation successful. Reservation information is: Station 1 (identifier 001), parking space A01, reservation time period 14:00-16:00, reservation order number Y0001.

[0210] The result of the fourth sub-service request (querying the charging fee standard of the target station) is as follows: The fast charging fee for station 1 (identifier 001) is 1.8 yuan per kilowatt-hour, and the service fee is 2 yuan per hour.

[0211] Determine the result attribute information corresponding to the sub-request processing result:

[0212] The core associated attribute of the first sub-request processing result is site data, corresponding to data attributes.

[0213] The core associated attributes of the second sub-request processing result are parking space and time period data, corresponding to the data attributes.

[0214] The core associated attributes of the third sub-request processing result are the appointment operation status and order data, corresponding to status attributes and data attributes.

[0215] The core associated attribute of the fourth sub-request processing result is the cost data, corresponding to the data attribute.

[0216] Step 2: Based on the result attribute information of all sub-request processing results, divide all sub-request processing results into multiple related result groups.

[0217] The sub-request processing results in each associated result group have associated result attribute information.

[0218] Furthermore, the attribute content of each result attribute information is extracted. The attribute content refers to the specific content under each result attribute information. For example, the attribute content of the data attribute is the specific data value (such as the station identifier 001, parking space number A01), the attribute content of the status attribute is the specific status value (such as reservation successful), and the attribute content of the business process attribute is the specific process step name (such as parking space reservation step).

[0219] Furthermore, the extracted attribute content is used as association features, which are core attribute identifiers used to determine whether there is a relationship between different execution results. The association features of all execution results are then compared pairwise to determine whether there are identical association features between different execution results.

[0220] The criteria for determining the same associated features are one of the following three: First, the data attributes are consistent, that is, the specific data values ​​under the data attributes of the two execution results are the same (e.g., both contain the site identifier 001); second, the status attributes are consistent, that is, the specific status values ​​under the status attributes of the two execution results are the same (e.g., both are successful execution); third, the business process attributes are consistent, that is, the specific process step names under the business process attributes of the two execution results are the same (e.g., both correspond to the parking space reservation process step).

[0221] As an example, the result attribute information for all sub-request processing results is as follows:

[0222] First execution result: Data attributes (site identifiers 001, 002, 003).

[0223] The second execution result: data attributes (site identifiers 001, 002, parking space numbers A01, A02, B03, time period 14:00-16:00, etc.).

[0224] The third execution result includes: status attribute (reservation successful) and data attributes (site identifier 001, parking space A01, time period 14:00-16:00).

[0225] The fourth execution result: data attributes (site identifier 001, cost 1.8 yuan per degree, service fee 2 yuan per hour).

[0226] Further assess the consistency of associated features:

[0227] The first and second execution results both contain data attributes (site identifiers 001 and 002) and have the same associated characteristics.

[0228] The second and third execution results both contain data attributes (site identifier 001, parking space A01, time period 14:00-16:00) and have the same associated characteristics.

[0229] The third and fourth execution results both contain data attributes (site identifier 001) and have the same associated characteristics.

[0230] The first and fourth execution results both contain data attributes (site identifier 001) and have the same associated characteristics.

[0231] Of all the execution results, only the third one has the status attribute "Reservation Successful," while the others have no status attribute; therefore, there is no associated feature of this type. All execution results have different business process attributes; therefore, there is no associated feature of this type.

[0232] Furthermore, based on the judgment results, all execution results with the same related characteristics are grouped into the same related result group. A related result group refers to a set of execution results that share common related characteristics and belong to the same business logic category. Specifically, the division principle can be: if two execution results have any type of common related characteristic, they are grouped into the same related result group; if multiple execution results have the same related characteristic through transitivity (e.g., if execution results A and B are the same, and B and C are the same, then A and C are the same), they are uniformly grouped into the same related result group, ensuring that related execution results under the same business request are not split.

[0233] As an example, all the above execution results have the same associated characteristics (site identifier 001 or 002 of the data attribute), so the four execution results are divided into the same associated result group.

[0234] Step 3: Based on the business process attributes corresponding to the processing results of each sub-request in each associated result group, determine the result dependencies of different associated result groups.

[0235] Furthermore, the result dependencies of different related result groups can be determined by analyzing the business process attributes corresponding to the processing results of all sub-requests in each related result group. The business process attribute can be the sequence of business processes, which characterizes the execution order of the business process steps corresponding to each sub-business in the overall business processing, i.e., which process step is executed first and which process step is executed later. This relationship is determined by the task splitting order and dependency relationship in the business association logic.

[0236] Specifically, the determination involves identifying whether multiple related result groups exist (if all execution results belong to the same group, there's no need to determine inter-group dependencies). If multiple related result groups exist, the sequence of business process steps corresponding to different related result groups is analyzed based on the business process attributes of each group to determine whether result dependencies exist between them. Result dependency refers to the dependency attribute between business processes corresponding to different related result groups. The specific criterion is: the business process corresponding to the previous related result group can only start after the business process corresponding to the next related result group is completed; that is, the business process of the next related result group depends on the execution result of the business process of the first related result group. If only one related result group exists, then that group has no result dependencies.

[0237] Step 4: Integrate the processing results of all sub-requests based on the result dependencies to obtain the processing result of the business request.

[0238] Furthermore, based on the result dependencies, the processing results of all sub-requests are integrated to obtain the processing result of the business request.

[0239] In the above implementation process, the core associated attributes of the execution results were clarified by identifying the result attribute information, which solved the problem of ambiguity in the association basis of the execution results of multiple sub-requests; the accurate grouping of execution results was achieved by judging the consistency of association features, ensuring that the results within the same business logic scope were not separated; the business logic order of the execution results was clarified by analyzing the business process attributes and inter-group dependencies, avoiding the temporal chaos of result integration; finally, decision association was carried out based on result dependencies, realizing the organic integration of dispersed execution results.

[0240] In one embodiment, the result dependency includes the process sequence information of the associated result group. Integrating the processing results of all sub-requests based on the result dependency to obtain the processing result of the business request may include the following steps:

[0241] Step 1: Based on the result dependency relationship, starting from the earliest associated result group in the process sequence information, connect the associated result groups with dependencies in sequence to obtain at least two associated result paths.

[0242] For example, the result dependency relationship may include the process sequence information of the associated result group. Based on the result dependency relationship between the associated result groups, starting from the earliest associated result group in the process sequence, the associated result groups with dependencies are connected in sequence to obtain the decision association path between the associated results.

[0243] Specifically, the earliest associated result group in the process sequence refers to the associated result group whose corresponding business process step starts earliest in the overall business processing among all associated result groups. This group has no preceding dependent associated result groups and is the starting node of the decision-making associated path.

[0244] Furthermore, in the result dependencies between related result groups, starting from the earliest related result group in the process sequence, all related result groups with dependencies are connected sequentially according to the rule that "the previous related result group is a prerequisite for the next related result group," forming a related result path between related results. A related result path refers to a result integration link formed by connecting related result groups as nodes and dependencies as edges according to business process logic, used to clarify the order of execution results and the direction of integration.

[0245] Step 2: Based on the association type between adjacent pairs of associated result groups in each associated result path, determine the result attribute matching information between all sub-request processing results in the corresponding adjacent associated result groups.

[0246] The association types include at least one of data inheritance association, status transfer association, or process connection association.

[0247] Furthermore, the association type refers to the category of association attributes between adjacent association result groups in the association result path, including data inheritance association, state transitive association, and process connection association. Data inheritance association means that the execution result of the later association result group must inherit the core data attributes (such as station identifier, parking space number, etc.) in the execution result of the earlier association result group; state transitive association means that the execution result status of the later association result group must be based on the execution result status of the earlier association result group (e.g., if the earlier one succeeds, the later one continues to execute; if the earlier one fails, the later one terminates); process connection association means that the business process link corresponding to the later association result group must be connected to the business process link corresponding to the earlier association result group.

[0248] Determine the association type between adjacent result groups in the associated result path. As an example, consider a single associated result group (all execution results belong to the same group), with the process sequence characteristics as "Execution Result 1 (Site Query Result) → Execution Result 2 (Parking Space Query Result) → Execution Result 4 (Fee Query Result) → Execution Result 3 (Reservation Execution Result)". There are no inter-group dependencies; therefore, the decision-making associated path uses the execution results within this associated result group as nodes, connecting them according to the process sequence characteristics. Determine the association type between adjacent nodes:

[0249] Execution Result 1 (Site Query) and Execution Result 2 (Parking Space Query): Execution Result 2 needs to inherit the site identifier data in Execution Result 1, and the parking space query process is connected to the site query process. Therefore, the feature association type is "data inheritance association + process connection association".

[0250] Execution Result 2 (Parking Space Query) and Execution Result 4 (Fee Query): Execution Result 4 needs to inherit the target site identifier data in Execution Result 2. The fee query process is connected to the parking space query process. Therefore, the feature association type is "data inheritance association + process connection association".

[0251] Execution Result 4 (Fee Inquiry) and Execution Result 3 (Reservation Execution): Execution Result 3 needs to inherit the fee data from Execution Result 4 and the parking space and time period data from Execution Result 2. The reservation process is connected to the fee inquiry process, and since the fee inquiry result has no failure status, it is passed to the "executable" status. Therefore, the feature association type is "data inheritance association + status transmission association + process connection association".

[0252] The final associated result path is: Execution Result 1 → Execution Result 2 → Execution Result 4 → Execution Result 3. The association types of each adjacent node in the path correspond to the above classifications in order.

[0253] Furthermore, the association types of adjacent association result groups (or adjacent execution results within a group) in each association result path are extracted and arranged according to the node order of the path to form an association type sequence. The association type sequence refers to the sequence set of association types of all adjacent nodes in the association result path in chronological order, which can intuitively reflect the changing logic of the association relationship in the path.

[0254] Furthermore, based on the sequence of association types for each path, the attribute matching relationship of the execution results of all sub-business requests in adjacent association result groups (or adjacent execution results within a group) is analyzed. Here, attribute matching relationship refers to the correspondence between the output attributes of the execution result in the previous node (association result group or execution result within a group) and the input attributes of the execution result in the next node.

[0255] Output attributes refer to the core data attributes or status attributes (such as station identifier, parking space availability status, etc.) in the previous execution result that can support the next execution result; input attributes refer to the core data attributes or status attributes that must be obtained during the execution of the next execution result (such as station identifier for querying parking spaces, parking space number for submitting reservations, etc.).

[0256] During the judgment process, for each association type in the association type sequence, it is necessary to focus on checking the consistency of the corresponding attributes: for data inheritance association, it is necessary to check whether the data attributes are consistent; for state transmission association, it is necessary to check whether the state attributes are consistent; for process connection association, it is necessary to check whether the attributes corresponding to the process links match, so as to ensure that the execution results of adjacent nodes can smoothly transmit data, continue the state, and connect the process.

[0257] As an example, determine the above-mentioned associated result path and associated type sequence:

[0258] Association type sequence: [data inheritance association + process connection association, data inheritance association + process connection association, data inheritance association + status transfer association + process connection association].

[0259] Path nodes: Execution result 1 → Execution result 2 → Execution result 4 → Execution result 3.

[0260] Determine attribute matching relationships:

[0261] Execution Result 1 (Output Attributes: Site Identifier, Site Address, Number of Devices) and Execution Result 2 (Input Attribute: Site Identifier): The site identifiers in the data attributes are consistent, and the attributes corresponding to the process connection links (site query → parking space query) match. The attribute matching result is "consistent".

[0262] Execution Result 2 (Output Attributes: Station Identifier, Parking Space Number, Available Time Period) and Execution Result 4 (Input Attribute: Station Identifier): The station identifiers in the data attributes are consistent, and the attributes corresponding to the process connection links (parking space query → fee query) match. The attribute matching result is "consistent".

[0263] Execution Result 4 (output attributes: station identifier, charging fee, service fee standard; status attribute: query successful) and Execution Result 3 (input attributes: station identifier, parking space number, available time period, fee information; status attribute: available for reservation): The station identifier is consistent in the data attributes, the fee information matches the input requirements, the status attributes "query successful" and "available for reservation" are consistent, and the attributes corresponding to the process connection links (fee query → reservation submission) match, with the attribute matching result being "consistent". Finally, the attribute matching result for all adjacent nodes is "consistent".

[0264] Step 3: Based on the result attribute matching information and association type of all adjacent associated result groups in each associated result path, determine the association complexity of the corresponding associated result path.

[0265] Furthermore, the path association logic of each associated result path is analyzed based on the sequence of association types and attribute matching results of each path. Path association logic refers to the inherent logical rules by which adjacent nodes in an associated result path achieve execution result association through association types. For example, the logic corresponding to "data inheritance + process connection" is "inheriting core data and connecting execution results according to the process sequence," and the logic corresponding to "data inheritance + status transmission + process connection" is "inheriting core data, transmitting valid status, and connecting subsequent processes." By analyzing the path association logic, the association rule characteristics of the associated result paths are extracted. These association rule characteristics are the core rule identifiers that can summarize the path association logic, such as "data must be inherited + process must be connected" and "status transmission is a prerequisite + data inheritance is support," which are used to clarify the core rules for integrating execution results in the path.

[0266] Furthermore, based on the association rule characteristics of the associated result paths, the association complexity of each path is determined, resulting in a complexity coefficient for each path. The complexity coefficient of each path is then used to determine the corresponding complexity. Association complexity refers to the degree of complexity determined by the number of association types and the difficulty level of attribute matching in the associated result path. The more association types (e.g., including three feature association types simultaneously), the higher the complexity. Attribute matching difficulty levels are divided into simple, medium, and complex. Simple difficulty refers to matching a single data attribute, medium difficulty refers to matching multiple data attributes, and complex difficulty refers to matching a combination of data attributes and state attributes. The complexity coefficient is a quantitative representation of association complexity (described in words, such as low, medium, and high). The determination rules are: 1 association type and simple attribute matching → low complexity coefficient; 2 association types and medium attribute matching → medium complexity coefficient; 3 or more association types or complex attribute matching → high complexity coefficient.

[0267] As an example, the above sequence of association types (3 sets of association types, including 2, 2, and 3 association types) and the attribute matching results (all consistent, with attribute matching mainly based on single data attribute matching, and some including data + state combination matching):

[0268] Path association logic analysis: The core logic of this decision association path is "inheriting the core data of the previous execution result in sequence according to the business process order, passing the effective execution status, connecting the subsequent business process links, and finally integrating all execution results". The association rule characteristics are "data inheritance as the foundation + process connection as the framework + status transmission as a supplement".

[0269] Association complexity determination: There are a maximum of 3 association types (data inheritance + state transfer + process connection), and the difficulty level of attribute matching is mainly simple with some medium. Therefore, the association complexity is determined to be "medium" and the complexity coefficient is "medium".

[0270] Step 4: Perform a hierarchical division of all associated result paths based on the association complexity to obtain the hierarchical division results of all associated result paths.

[0271] Furthermore, all associated result paths can be divided into different levels according to their complexity coefficients, from low to high, to obtain the hierarchical division results of all associated result paths. Specifically, all decision-related paths are divided into different levels according to their complexity coefficients, from low to high, to obtain the hierarchical division results. The rule for hierarchical division is as follows: paths with "low" complexity coefficients are assigned to the top level (priority integration level), paths with "medium" complexity coefficients are assigned to the middle level, and paths with "high" complexity coefficients are assigned to the bottom level (last integration level), ensuring that paths with simple association logic are integrated first, improving integration efficiency and accuracy. If there is only one associated result path, then that path is assigned to the corresponding level according to its complexity coefficient. If it is "medium" or "high," that path is still the core integration object, and the top level is the level where that path belongs.

[0272] Step 5: Based on the hierarchical division results, integrate the processing results of all sub-requests to obtain the processing result of the business request.

[0273] Furthermore, based on the hierarchical division results, starting from the top level, the execution results of the sub-business requests corresponding to the associated result groups of all associated result paths at that level are extracted, and the results are initially associated and integrated according to the association rule characteristics of the path. The rules and characteristics of the initial association integration correspond to the association types: if it is a data inheritance association, the same data attributes in adjacent execution results are merged, duplicate data is removed, and complete core data is retained; if it is a status transmission association, the valid status attributes of the previous execution result are continued to ensure status consistency; if it is a process connection association, the process link information corresponding to each execution result is connected according to the business process sequence to form a complete process link.

[0274] As an example, the above only has one associated result path with a complexity coefficient of "medium". The hierarchical division result is that this path is classified into the intermediate level. Since there are no other paths, this level is regarded as the core integration level (equivalent to the top level).

[0275] Extract the execution results of all sub-business requests in this path, and perform initial association and integration based on association rule characteristics (data inheritance as the foundation + process connection as the framework + status transmission as a supplement):

[0276] Data inheritance and integration: Merge the core data in all execution results, retain the site identifier 001 (target site), site name, detailed address, parking space number A01, available time period 14:00-16:00, charging fee of 1.8 yuan per kWh, service fee of 2 yuan per hour, and reservation order number Y0001, and remove duplicate site identifiers and other data.

[0277] Status transmission integration: The status attributes of "query successful" and "appointment successful" are retained and unified into the "business processing successful" status.

[0278] Process integration: Following the process sequence of "site query → parking space query → fee query → reservation submission", the core results of each step are sorted out to form process link information.

[0279] The final preliminary association results at the top level are as follows: business processing status is successful; target site information (name, address, identifier 001); reservation information (parking space A01, time period 14:00-16:00, order number Y0001); fee standard (charging fee of RMB 1.8 per kWh, service fee of RMB 2 per hour); process flow (site query → parking space query → fee query → reservation submission).

[0280] In the above implementation process, the integration order and association type of the execution results were clarified by constructing the associated result path, which solved the problem of ambiguity in the direction of multi-result integration; by judging the association type and attribute matching relationship, the attribute compatibility of adjacent results was ensured, avoiding conflicts in data, status, and process during the integration process; by analyzing the path association logic and judging the association complexity, the integration priority was reasonably divided, improving the efficiency of complex result integration; further, through hierarchical division and initial association integration, the orderly merging of scattered execution results was completed, eliminating redundant information; finally, the processing result of the business request was generated based on the preliminary association result, realizing a closed loop from the execution result of multiple sub-business requests to a comprehensive response that is understandable to the user, ensuring that the complex multi-stage execution results can be accurately, orderly, and efficiently integrated according to business logic and user needs. The generated processing result of the business request not only fully covers the core data and processing status, but also has a clear logical structure and good readability, improving the user's perception and satisfaction with the business processing result.

[0281] In one embodiment, based on the hierarchical division result, the processing results of all sub-requests are integrated to obtain the processing result of the business request, which may include the following steps:

[0282] Step 1: Based on the hierarchical division results, determine each level as the current level from top to bottom.

[0283] Step 2: Integrate the integration result of the previous level with the sub-request processing result of the current level to obtain the integration result of the current level; when the current level is the first level, the integration result of the current level is the integration result of the sub-request processing result of the first level.

[0284] Step 3: Based on the integration results at the lowest level, determine the processing result of the business request.

[0285] For example, the preliminary association results of the top level are passed down to the next level. Combining the association rule features of the next level, the results passed down from the top level are combined with the execution results of the sub-business tasks of the association result group in the next level to obtain the association results of the next level. All levels in the hierarchical division results are processed in sequence until the final association results of the bottom level are obtained.

[0286] Specifically, the initial association results from the top-level hierarchy are passed down to the next adjacent level, and a secondary association integration is performed by combining the association rule characteristics of that next level. The association rule characteristics of the next level refer to the fact that the core integration rules extracted from the decision-making association path at that level may differ from the association rule characteristics of the top-level hierarchy (e.g., more complex combinations of association types). The core logic of the secondary association integration is: based on the results passed down from the upper level, the execution results of sub-business requests in the association result group of the next level are integrated into the upper-level framework according to the association rule characteristics of that level, achieving data complementarity, state connection, and process continuity. During the integration process, the principle of "upper-level results as the main driver, lower-level results as a supplement" must be followed: if the lower-level results contain core data not covered by the upper level, it is added to the corresponding data module; if the state of the lower-level results has a continuity relationship with the state of the upper level, the state is updated to a complete link state; if the lower-level process connects to the upper-level process, the process link information is extended. This process is repeated sequentially, passing the integration result of each level down to the next level for secondary association and integration, until the integration of all levels is completed, resulting in the final association result of the lowest level. The final association result is a complete integrated set containing the execution results of all level association paths, with logical coherence and consistent data.

[0287] In one embodiment, the hierarchical division result has only one core level (equivalent to the topmost level), with no other lower levels, so there is no need for cross-level transmission. This directly regards the preliminary association result of the core level as the final association result of the bottommost level, specifically: business processing status is successful; target site information (name: downtown fast charging station one, address: No. 1, First Road, downtown, identifier: 001); reservation information (parking space number: A01, reservation time period: 14:00-16:00 on the same day, order number: Y0001); fee standard (charging fee: RMB 1.8 per kWh, service fee: RMB 2 per hour); process link (site query → parking space query → fee query → reservation submission).

[0288] In the above implementation process, the execution results of all levels are fully integrated through cross-level association and integration, ensuring that no core information is omitted and the logic is coherent, thereby further improving the accuracy of the processing results of business requests.

[0289] In one embodiment, the method may further include the following steps:

[0290] Step 1: Obtain key information about the processing results of business requests on different metrics.

[0291] Different metrics include business status metrics, business data summary metrics, and business process progress metrics.

[0292] Step 2: Merge the key information of all indicator results to obtain the merged result information.

[0293] Step 3: Display the fusion results in a preset display format to respond to the user's business requests.

[0294] For example, based on the business association information of each sub-business request, the key information of the indicator result containing the preset business indicators is identified from the final association result, and the key information of each result is reorganized according to the business logic order to obtain the fused result information.

[0295] Specifically, based on the business association information of each sub-business request, key information of the preset indicators is identified from the final association results. Preset indicators refer to categories of key information that directly address the core user needs and are of greatest concern to the user, including business status indicators, business data summary indicators, and business process progress indicators. Among these, business status indicators refer to the overall processing result status of the business request (e.g., success, failure, partial completion) and the status details of key operations (e.g., successful appointment, successful query); business data summary indicators refer to the integrated core business data set (e.g., site information, appointment information, fee information, etc.); and business process progress indicators refer to the complete process chain of business processing and the completion status of each stage (e.g., which stage has been completed, and whether there are any incomplete stages).

[0296] Specifically, during the identification process, information in the final associated results needs to be screened one by one and categorized according to the definitions of the three types of indicators mentioned above, ensuring that each type of indicator fully covers its corresponding scope without any omission of core information. Subsequently, the key information of the indicator results for each type of indicator is reorganized according to a preset business logic order. The business logic order refers to the information arrangement order that conforms to user cognitive habits and can clearly present the overall picture of business processing. The preset order is "business process progress information → business data summary information → business processing status information". This order first allows users to understand the complete process of business processing, then obtain core data, and finally clarify the overall result, which conforms to the user's cognitive logic of business response.

[0297] Specifically, during the restructuring process, it is necessary to ensure the logical coherence of various types of information: business process progress information should be arranged in chronological order for each stage; business data summary information should be presented according to the logical association of "site → appointment → fee"; business processing status information should first clarify the overall status and then supplement the status of key operations.

[0298] As an example, identify the key information in the results of each indicator:

[0299] Key information for business status metrics: Overall business processing status (success), status of each stage (successful site query, successful parking space query, successful fee query, successful reservation submission);

[0300] Key information of the business data summary indicators: target site information (name: downtown fast charging station 1, address: No. 1, First Road, downtown), reservation core information (parking space number A01, reservation time period 14:00-16:00, order number Y0001), and fee standard information (charging fee of RMB 1.8 per kWh, service fee of RMB 2 per hour).

[0301] Key information for business process progress metrics: complete process flow (site query → parking space query → fee query → reservation submission), and completion status of each step (all completed).

[0302] Information is reorganized according to business logic sequence (business process progress → business data summary → business processing status):

[0303] Business process progress: The entire process of "site query → parking space query → fee query → reservation submission" has been completed.

[0304] Business data summary: The target site is the downtown fast charging station 1 (address: No. 1, First Road, downtown); the reservation information is parking space A01, 14:00-16:00, order number Y0001; the fee standard is RMB 1.8 per kilowatt-hour for charging and RMB 2 per hour for service fee.

[0305] Business processing status: The overall business processing was successful, and all steps were executed successfully.

[0306] Furthermore, the fusion result information is structured according to the business response format requirements of the user's business request to obtain structured business information, and auxiliary explanatory information for the business response is supplemented based on the structured business information to obtain business response information.

[0307] Specifically, the preset display format can be a preset business response format requirement for user business requests. Business response format requirements refer to a set of standards pre-defined by the charging service system to regulate the presentation of business response information, including information display structure, language expression standards, and methods for highlighting key information. Among these, the information display structure refers to the way information is divided into modules (e.g., bullet points, sections); the language expression standards refer to the tone and wording of the information (e.g., formal, concise, without excessive jargon); and the methods for highlighting key information refer to the way information of core concern to the user is emphasized (e.g., bolding, separate listing).

[0308] Furthermore, in accordance with the business response format requirements, the fusion result information is structured to obtain structured business information. Specific operations for structured organization include: dividing the fusion business information into three modules according to the information display structure: "Process Progress," "Core Data," and "Processing Status"; converting the information into user-friendly, easily understood expressions according to language conventions, avoiding technical jargon; and highlighting key information such as order number, appointment time slot, and fee standards separately.

[0309] Furthermore, based on the structured business information, supplementary information is provided to support the business response. This supplementary information helps users with subsequent business processing, information retrieval, or problem feedback. It includes guidance on subsequent business processing (e.g., how to get to the site, how to use reserved parking spaces), information retrieval methods (e.g., the path to check order details), and problem feedback channels (e.g., customer service hotline, online feedback portal). During the supplementation process, it is crucial to ensure that the supplementary information is relevant to the structured business information, concise, practical, and easy to use, avoiding redundant and irrelevant content. Finally, the structured business information and supplementary information are integrated to form complete business response information.

[0310] As an example, the above fusion result information is structured and organized according to the business response format requirements:

[0311] Information display structure: clearly listed in modules; standardized language: formal and concise, without technical jargon; key information highlighting method: core data is listed separately.

[0312] Structured business information:

[0313] I. Business Process Progress: The entire process of "site query → parking space query → fee query → reservation submission" has been successfully completed.

[0314] II. Core Business Data:

[0315] Target site: Fast charging station in the city center (address: No. 1, First Road, City Center).

[0316] Reservation details: Parking space number A01, reservation time slot 14:00-16:00, order number Y0001.

[0317] Pricing: Charging fee is 1.8 yuan per kilowatt-hour, and service fee is 2 yuan per hour.

[0318] III. Business Processing Status: The overall business processing was successful, and all steps have been completed.

[0319] Additional supplementary information:

[0320] IV. Supplementary Explanation:

[0321] Follow-up instructions: Please go to the target site within the reserved time slot and use the parking space by verifying your order number or mobile phone number.

[0322] Information inquiry method: You can check the details of this reservation order through the "My Orders" section of the charging service platform.

[0323] Feedback channels: If you have any questions, you can call customer service or submit your issue through the "Feedback" portal on the platform. Ultimately, you will receive a service response to your business request.

[0324] In the above implementation process, by differentiating and reorganizing key information in the indicator results, the key information that users care about most is selected and arranged in an order that conforms to cognitive habits, thereby improving the readability and usability of the information. Through structured organization and supplementary explanations, the business response information is presented in a standardized and focused manner, while providing users with guidance for subsequent operations, resolving potential questions about subsequent business processing, and ensuring that the generated business response information not only fully covers the execution results of all sub-business requests, but also has a clear structure, easy-to-understand expression and practical supplementary explanations. It can comprehensively, accurately and efficiently respond to the user's original business request, thereby improving user satisfaction with the business response and the user experience.

[0325] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0326] Based on the same inventive concept, this application also provides a business processing apparatus for implementing the business processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more business processing apparatus embodiments provided below can be found in the limitations of the business processing method described above, and will not be repeated here.

[0327] In one exemplary embodiment, Figure 4 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application, as shown below. Figure 4 The device includes:

[0328] Request retrieval module 401 is used to retrieve user business requests;

[0329] The request splitting module 402 is used to split the business request based on the user's intent information in the business request to obtain multiple sub-business requests;

[0330] The matching module 403 is used to match the corresponding intelligent agent component for each sub-business request from multiple intelligent agent components based on the association element information between each sub-business request; the association element information of the sub-business request includes the business operation type, required data type and business dependency relationship of the corresponding sub-business request;

[0331] The scheduling strategy determination module 404 is used to determine the scheduling strategy of the intelligent agent component that matches each sub-service request based on the service dependency relationship of each sub-service request.

[0332] The request processing module 405 is used to schedule the corresponding intelligent agent components to process the corresponding sub-business requests based on the scheduling strategy, and obtain the sub-request processing results of each sub-business request.

[0333] The result generation module 406 is used to generate the processing result of the business request based on the processing results of all sub-requests.

[0334] In one embodiment, the scheduling strategy determination module 404 is specifically used for:

[0335] Determine the dependency paths of each sub-business request from the knowledge graph based on business dependencies;

[0336] Based on the dependency path and the matching relationship between each sub-business request and multiple intelligent agent components, an intelligent agent component chain network is constructed by intelligent agent components that match each sub-business request. The intelligent agent component chain network is used to represent the execution order among intelligent agent components that match each sub-business request.

[0337] Based on the interaction rules of intelligent agent components, the cooperative constraint information between adjacent intelligent agent components in the intelligent agent component chain network is determined; wherein, the cooperative constraint information includes the interaction protocol type, data transmission format and interaction response time that must be satisfied for adjacent intelligent agent components to work together.

[0338] Based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network, the scheduling strategy of the intelligent agent component that matches each sub-business request is determined.

[0339] In one embodiment, the scheduling strategy determination module 404 is specifically used for:

[0340] Based on whether the cooperative constraint information between all two adjacent intelligent agent components in the intelligent agent component chain network satisfies the cooperative constraint conditions, multiple valid component chains are determined from the intelligent agent component chain network;

[0341] Based on the business dependencies of sub-business requests in the valid component chains, determine the relationships between all valid component chains;

[0342] Based on the relationships between all valid component chains, all valid component chains are sorted to obtain the scheduling order of all valid component chains.

[0343] Based on the scheduling order of all valid component chains and the execution order of each agent component in each valid component chain, the scheduling strategy of the agent component that matches each sub-service request is determined.

[0344] In one embodiment, the scheduling strategy determination module 404 is further configured to:

[0345] In the intelligent agent component chain network, if the cooperative constraint information between two adjacent intelligent agent components does not meet the cooperative constraint conditions, the intelligent agent component chain is determined to be an invalid component chain.

[0346] Rematch agent components for the corresponding subtasks in the invalid component chain; reconstruct the agent component chain network based on the rematched agent components to obtain the reconstructed agent component chain network; or,

[0347] The invalid component chain is split into multiple valid component sub-chains, and a reconstructed agent component chain network is generated based on these multiple valid component sub-chains; or...

[0348] For invalid component chains that do not meet the collaborative constraints, at least one of the subtasks corresponding to two adjacent intelligent agent components is matched to the general intelligent agent component; the intelligent agent component chain network is reconstructed based on the general intelligent agent component to obtain the reconstructed intelligent agent component chain network.

[0349] The process of repeatedly determining whether there are invalid component chains in the reconstructed intelligent agent component chain network continues until the reconstructed intelligent agent component chain network is obtained, until there are no invalid component chains in the reconstructed intelligent agent component chain network.

[0350] Based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network, and the execution order of each intelligent agent component in each valid component chain, the scheduling strategy of the intelligent agent component that matches each sub-business request is determined.

[0351] In one embodiment, the result generation module 406 is specifically used for:

[0352] Determine the result attribute information of all sub-request processing results; the result attribute information of sub-request processing results includes data attributes, status attributes, and business process attributes;

[0353] Based on the result attribute information of all sub-request processing results, all sub-request processing results are divided into multiple related result groups, and the sub-request processing results in each related result group have related result attribute information.

[0354] Based on the business process attributes corresponding to the processing results of each sub-request in each associated result group, determine the result dependencies of different associated result groups;

[0355] The processing results of all sub-requests are integrated based on the result dependencies to obtain the processing result of the business request.

[0356] In one embodiment, the result dependency includes process timing information of the associated result group, and the result generation module 406 is specifically used for:

[0357] Based on the result dependency, starting from the earliest associated result group in the process sequence information, connect the associated result groups with dependencies in sequence to obtain at least two associated result paths;

[0358] Based on the association type between adjacent pairwise association result groups in each associated result path, determine the result attribute matching information between all sub-request processing results in the corresponding adjacent association result groups; the association type includes at least one of data inheritance association, status transmission association, or process connection association.

[0359] Based on the result attribute matching information and association type of all adjacent associated result groups in each associated result path, the association complexity of the corresponding associated result path is determined.

[0360] Based on the complexity of association, all associated result paths are hierarchically divided to obtain the hierarchical division results of all associated result paths;

[0361] Based on the hierarchical division results, the processing results of all sub-requests are integrated to obtain the processing result of the business request.

[0362] In one embodiment, the result generation module 406 is specifically used for:

[0363] Based on the hierarchical division results, each level is determined as the current level from top to bottom;

[0364] The integration result of the previous level is combined with the sub-request processing result of the current level to obtain the integration result of the current level; when the current level is the first level, the integration result of the current level is the integration result of the sub-request processing result of the first level.

[0365] Based on the integration results at the lowest level, the processing outcome of the business request is determined.

[0366] In one embodiment, the result generation module 406 is further configured to:

[0367] Obtain key information about the processing results of business requests across different metrics; these metrics include business status metrics, business data summary metrics, and business process progress metrics.

[0368] By integrating the key information from all indicator results, we obtain the integrated result information;

[0369] The fusion results will be displayed in a preset format to respond to user business requests.

[0370] Each module in the aforementioned business processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0371] In one exemplary embodiment, a computer device is provided, which may be a server. Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Figure 5 As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to user business requests. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a business processing method.

[0372] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0373] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the business processing method in any of the above embodiments.

[0374] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the business processing method in any of the above embodiments.

[0375] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0376] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0377] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0378] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A business processing method, characterized in that, Applied to a business processing platform, the business processing platform includes multiple intelligent agent components, each intelligent agent component being used to process business corresponding to at least one business type, the method includes: Obtain the user's business request; The service request is split into multiple sub-service requests based on the user's intent information in the service request; Based on the association element information of each sub-service request, a corresponding intelligent agent component is matched for each sub-service request from among the multiple intelligent agent components; the association element information of the sub-service request includes the business operation type, required data type, and business dependency relationship of the corresponding sub-service request. Based on the business dependencies of each sub-business request, determine the scheduling strategy of the intelligent agent component that matches each sub-business request; The step of determining the scheduling strategy for intelligent agent components matching each sub-service request based on the service dependency relationships of each sub-service request includes: determining the dependency path of each sub-service request from the knowledge graph based on the service dependency relationships; constructing an intelligent agent component chain network based on the dependency paths and the matching relationships between each sub-service request and multiple intelligent agent components, wherein the intelligent agent component chain network is used to characterize the execution order among the intelligent agent components matching each sub-service request; determining the collaborative constraint information between adjacent intelligent agent components in the intelligent agent component chain network based on the interaction rules of the intelligent agent components; wherein the collaborative constraint information includes the interaction protocol type, data transmission format, and interaction response time that must be satisfied for adjacent intelligent agent components to work collaboratively; and determining the scheduling strategy for intelligent agent components matching each sub-service request based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network. The step of determining the scheduling strategy of the intelligent agent component matching each sub-service request based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network includes: determining multiple valid component chains from the intelligent agent component chain network based on whether the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network satisfies the collaborative constraint conditions; determining the association relationship between all valid component chains based on the service dependency relationship of the sub-service requests in the valid component chains; sorting all valid component chains based on the association relationship between all valid component chains to obtain the scheduling order of all valid component chains; and determining the scheduling strategy of the intelligent agent component matching each sub-service request based on the scheduling order of all valid component chains and the execution order of each intelligent agent component in each valid component chain. The method further includes: identifying intelligent agent component chains in the intelligent agent component chain network where the cooperative constraint information between two adjacent intelligent agent components does not satisfy the cooperative constraint condition as invalid component chains; re-matching intelligent agent components for the corresponding subtasks in the invalid component chains; reconstructing the intelligent agent component chain network based on the re-matched intelligent agent components to obtain a reconstructed intelligent agent component chain network; or, splitting the invalid component chain into multiple valid component sub-chains, and generating a reconstructed intelligent agent component chain network based on the multiple valid component sub-chains; or, identifying intelligent agent component chains in the invalid component chain where the cooperative constraint information between two adjacent intelligent agent components does not satisfy the cooperative constraint condition as invalid component chains. At least one intelligent agent component in the intelligent agent component is matched to a general intelligent agent component for its corresponding subtask; the intelligent agent component chain network is reconstructed based on the general intelligent agent component to obtain a reconstructed intelligent agent component chain network; the step of determining whether there is an invalid component chain in the reconstructed intelligent agent component chain network is executed cyclically until the reconstructed intelligent agent component chain network is obtained, until there is no invalid component chain in the reconstructed intelligent agent component chain network; based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network and the execution order of each intelligent agent component in each valid component chain, the scheduling strategy of the intelligent agent component matching each sub-service request is determined; Based on the scheduling strategy, the corresponding intelligent agent components are scheduled to process the corresponding sub-service requests, and the sub-request processing results of each sub-service request are obtained. Based on the processing results of all sub-requests, the processing result of the business request is generated.

2. The method according to claim 1, characterized in that, The step of generating the processing result of the business request based on the processing results of all sub-requests includes: Determine the result attribute information of all sub-request processing results; the result attribute information of the sub-request processing results includes data attributes, status attributes, and business process attributes; Based on the result attribute information of all sub-request processing results, all sub-request processing results are divided into multiple associated result groups, and the sub-request processing results in each associated result group have associated result attribute information. Based on the business process attributes corresponding to the processing results of each sub-request in each of the associated result groups, the result dependencies of different associated result groups are determined. Based on the aforementioned result dependencies, the processing results of all sub-requests are integrated to obtain the processing result of the business request.

3. The method according to claim 2, characterized in that, The result dependency relationship includes the process sequence information of the associated result group. The process of integrating the processing results of all sub-requests based on the result dependency relationship to obtain the processing result of the business request includes: Based on the aforementioned result dependencies, starting from the earliest associated result group in the process sequence information, the associated result groups with dependencies are connected sequentially to obtain at least two associated result paths; Based on the association type between adjacent pairs of associated result groups in each associated result path, the result attribute matching information between all sub-request processing results in the corresponding adjacent associated result groups is determined; the association type includes at least one of data inheritance association, status transmission association, or process connection association. Based on the result attribute matching information and the association type of all adjacent association result groups in each association result path, the association complexity of the corresponding association result path is determined. Based on the aforementioned association complexity, all the associated result paths are hierarchically divided to obtain the hierarchical division results of all the associated result paths; Based on the hierarchical division results, the processing results of all sub-requests are integrated to obtain the processing result of the business request.

4. The method according to claim 3, characterized in that, The process of integrating the processing results of all sub-requests based on the hierarchical division results to obtain the processing result of the business request includes: Based on the hierarchical division results, each level is determined as the current level from top to bottom; The integration result of the previous level is combined with the sub-request processing result of the current level to obtain the integration result of the current level; when the current level is the first level, the integration result of the current level is the integration result of the sub-request processing result of the first level. Based on the integration results at the lowest level, the processing result of the business request is determined.

5. A business processing device, characterized in that, Applied to a business processing platform, the business processing platform includes multiple intelligent agent components, each intelligent agent component is used to process business corresponding to at least one business type, the device includes: The request retrieval module is used to retrieve user business requests; The request splitting module is used to split the business request based on the user's intent information in the business request to obtain multiple sub-business requests; The matching module is used to match a corresponding intelligent agent component for each sub-service request from multiple intelligent agent components based on the association element information between each sub-service request; the association element information of the sub-service request includes the business operation type, required data type, and business dependency relationship of the corresponding sub-service request; The scheduling strategy determination module is used to determine the scheduling strategy of the intelligent agent component that matches each sub-service request based on the service dependency relationship of each sub-service request. The scheduling strategy determination module is specifically used for: determining the dependency path of each sub-business request from the knowledge graph based on the business dependency relationship; constructing an intelligent agent component chain network based on the dependency path and the matching relationship between each sub-business request and multiple intelligent agent components, wherein the intelligent agent component chain network is used to characterize the execution order among the intelligent agent components matching each sub-business request; determining the collaborative constraint information between adjacent intelligent agent components in the intelligent agent component chain network based on the interaction rules of the intelligent agent components; wherein the collaborative constraint information includes the interaction protocol type, data transmission format and interaction response time that must be satisfied for adjacent intelligent agent components to work together; and determining the scheduling strategy of the intelligent agent components matching each sub-business request based on the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network. The scheduling strategy determination module is specifically used for: determining multiple valid component chains from the intelligent agent component chain network based on whether the collaborative constraint information between all adjacent intelligent agent components in the intelligent agent component chain network satisfies the collaborative constraint conditions; determining the association relationship between all valid component chains based on the service dependency relationship of sub-service requests in the valid component chains; sorting all valid component chains based on the association relationship between all valid component chains to obtain the scheduling order of all valid component chains; and determining the scheduling strategy of the intelligent agent component matching each sub-service request based on the scheduling order of all valid component chains and the execution order of each intelligent agent component in each valid component chain. The scheduling strategy determination module is further configured to: identify intelligent agent component chains in the intelligent agent component chain network where the collaborative constraint information between two adjacent intelligent agent components does not satisfy the collaborative constraint condition as invalid component chains; re-match intelligent agent components to the corresponding subtasks in the invalid component chains; reconstruct the intelligent agent component chain network based on the re-matched intelligent agent components to obtain a reconstructed intelligent agent component chain network; or, split the invalid component chain into multiple valid component sub-chains, and generate a reconstructed intelligent agent component chain network based on the multiple valid component sub-chains; or, identify the corresponding subtasks in the invalid component chain that do not satisfy the collaborative constraint condition, and... At least one of the two adjacent intelligent agent components is matched to a general intelligent agent component for its corresponding subtask; the intelligent agent component chain network is reconstructed based on the general intelligent agent component to obtain a reconstructed intelligent agent component chain network; the step of determining whether there is an invalid component chain in the reconstructed intelligent agent component chain network is executed cyclically until the reconstructed intelligent agent component chain network is obtained, until there is no invalid component chain in the reconstructed intelligent agent component chain network; based on the scheduling order of all valid component chains in the reconstructed intelligent agent component chain network and the execution order of each intelligent agent component in each valid component chain, the scheduling strategy of the intelligent agent component matching each sub-service request is determined; The request processing module is used to schedule the corresponding intelligent agent components to process the corresponding sub-service requests based on the scheduling strategy, and obtain the sub-request processing results of each sub-service request. The result generation module is used to generate the processing result of the business request based on the processing results of all sub-requests.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images