Business processing method, apparatus, device, and medium

Abstract

This application relates to the field of artificial intelligence technology and discloses a business processing method, apparatus, device, and medium, comprising: in response to receiving a business request, decomposing the business intent of the business request into multiple sub-tasks; decomposing the task objectives of each sub-task into multiple stage objectives, and determining the action sequence for completing each stage objective; executing the action sequence corresponding to each stage objective sequentially according to the order of the stage objectives; during the execution of each action sequence, in response to the completion of the target execution action in the target action sequence, determining the execution confidence of the target execution action; in response to the execution confidence being greater than a first preset threshold, continuing to execute the execution actions after the target execution action in the target action sequence until the action sequence is completed; and in response to the completion of each action sequence, outputting the business processing result corresponding to the business request. This can be applied to business processing scenarios in fintech and healthcare, improving the reliability of business processing.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and is applied to fintech and healthcare scenarios, particularly to a business processing method, apparatus, equipment, and medium. Background Technology

[0002] As digital transformation deepens across industries, intelligent business processing has become a key means to support the normal operation of complex business scenarios. Taking the financial insurance sector as an example, business processes such as underwriting assessment, claims review, and product recommendation typically involve multi-step decision-making and execution.

[0003] However, existing business processing methods typically use fixed procedures, which result in poor reliability. Summary of the Invention

[0004] This invention provides a business processing method, apparatus, computer equipment, and medium, aiming to solve the problem of poor reliability in business processing caused by using fixed processes in the current technology, and to improve the reliability of business processing.

[0005] Firstly, a business processing method is provided, including: In response to receiving a service request, the service intent of the service request is decomposed into multiple sub-tasks; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the service intent; The task objectives of each subtask are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined; the action sequence includes multiple execution actions arranged in execution order. According to the order in which the stage goals are arranged, the action sequence corresponding to each stage goal is executed sequentially; During the execution of each of the action sequences, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined; in response to the execution confidence being greater than a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed. Upon completion of each of the aforementioned action sequences, the business processing result corresponding to the business request is output.

[0006] Secondly, a business processing apparatus is provided, comprising: The decomposition module is used to decompose the business intent of the business request into multiple sub-tasks in response to receiving a business request; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the business intent. The determination module is used to decompose the task objectives of each subtask into multiple stage objectives, and to determine the action sequence for completing each stage objective; the action sequence includes multiple execution actions arranged in execution order; The execution module is used to execute the action sequence corresponding to each of the stage objectives in the order of their arrangement. The response module, during the execution of each action sequence, determines the execution confidence of the target action in the target action sequence upon completion of the target action; and continues to execute the subsequent actions in the target action sequence until the action sequence is completed if the execution confidence is greater than a first preset threshold. The output module is used to output the business processing result corresponding to the business request in response to the completion of each of the action sequences.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described business processing method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described business processing method.

[0009] In the above-mentioned business processing method, apparatus, equipment, and medium, in response to receiving a business request, the business intent of the business request is decomposed into multiple sub-tasks, the task objectives of each sub-task are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined. Thus, by decomposing the business intent layer by layer into sub-tasks, stage objectives, and specific action sequences, a refined breakdown and dynamic execution planning of complex business requests is achieved, significantly improving the flexibility and adaptability of business processing. During the execution of each action sequence, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined. If the execution confidence exceeds a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed. Therefore, after the target action is completed, by determining the execution confidence of the target action, the execution effect is judged in real time after each action is completed, ensuring that subsequent processes continue only when an action is successfully executed. This effectively avoids error accumulation and invalid execution caused by abnormal intermediate steps, greatly improving the reliability of business processing. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an application environment for a business processing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a business processing method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S10; Figure 4 This is a schematic diagram of a business processing device in one embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 6 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The business processing method provided in this embodiment of the invention can be applied to, for example, Figure 1In the illustrated application environment, the client communicates with the server via a network. The server can receive business requests from target users through the client and respond to these requests by decomposing the business intent of the request into multiple sub-tasks. Each sub-task includes a task objective, and the task objectives of multiple sub-tasks work together to satisfy the business intent. Further, the server decomposes the task objectives of each sub-task into multiple stage objectives and determines the action sequence for completing each stage objective. This action sequence includes multiple execution actions arranged in execution order. During the sequential execution of the action sequences corresponding to each stage objective according to the order of the stage objectives, whenever a target execution action in the target action sequence is completed, the server determines the execution confidence of that target execution action. If the execution confidence is greater than a first preset threshold, the server continues to execute the subsequent execution actions in the target action sequence until the action sequence is completed. Finally, after all action sequences have been executed, the server feeds back the business processing result corresponding to the business request to the client. This invention addresses the issues of coarse task decomposition and lack of dynamic verification during execution in complex business requests. By breaking down business intent layer by layer into sub-tasks, stage goals, and execution actions, and introducing a confidence assessment mechanism after each key execution action, the process continues only when the execution quality meets the standards. This effectively avoids overall business failures caused by the accumulation of single-step execution deviations, significantly improving the reliability and controllability of business processing while ensuring process continuity and execution efficiency. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] The business processing method of this application embodiment can be applied to a business processing system with a two-layer cognitive architecture. The business processing system includes two layers: a meta-agent and a sub-agent. The meta-agent, as the strategic layer, is responsible for high-level intent generation, task decomposition, and global supervision. The sub-agent, as the tactical layer, is responsible for hierarchical planning and atomic action execution. The two layers communicate with each other through a standardized communication protocol to achieve task distribution, status feedback, and dynamic intervention.

[0015] It should be noted that the aforementioned meta-agent and sub-agent can be different functional modules deployed on the same physical device, or they can be functional entities deployed on different physical devices and cooperating through network communication. This application does not specifically limit them in this regard.

[0016] A meta-agent can be a strategic decision-making layer functional entity in a business processing system. Specifically, the meta-agent can receive business requests, generate high-level intentions based on domain knowledge that include information such as business intent, constraints, success criteria, and risk levels, and be responsible for decomposing the high-level intentions into multiple sub-tasks and assigning them to sub-agents for processing, while retaining global supervision and dynamic authorization capabilities over the sub-agents.

[0017] High-level intent can be a high-level semantic goal description generated by the meta-agent based on a business request, used to guide subsequent task decomposition and execution. In some implementations, high-level intent may include dimensions such as business intent, constraint set, success criteria, and risk level. Specifically, business intent represents the ultimate goal expected to be achieved by the business request; constraint set represents the business rules and regulatory requirements that must be met during execution; success criteria represent the quality threshold required to complete the task; and risk level represents the risk level of the business request and determines the human-machine collaboration strategy. For example, for a critical illness insurance underwriting assessment request, the meta-agent may generate the following high-level intent: business intent is to complete the critical illness insurance underwriting assessment for users with thyroid nodules; constraint set includes the requirement to verify health disclosures and to provide notice of exclusion clauses; success criteria are generating an underwriting conclusion with a confidence level greater than 0.8; and risk level is high.

[0018] Task decomposition can be the process by which a meta-agent breaks down a high-level intent into several sub-tasks based on business domains or execution stages. For example, a meta-agent can decompose a high-level intent into multiple sub-tasks based on knowledge of the business domains involved. Each sub-task corresponds to an independent execution unit and is assigned to a sub-agent for processing. For instance, for a business request where the high-level intent is to complete a critical illness insurance underwriting assessment for users with thyroid nodules, the meta-agent can decompose it into a health information collection sub-task, an underwriting rule matching sub-task, and an underwriting conclusion generation sub-task. These three sub-tasks correspond to different execution stages and are assigned to the corresponding sub-agents for processing.

[0019] Global supervision can be the ability of a meta-agent to monitor the execution status of sub-agents in real time. In some implementations, the meta-agent can receive status reports from sub-agents to monitor their execution progress, intermediate results, and execution confidence in real time, and make decisions based on the monitoring results. For example, when all sub-tasks are executing normally, the meta-agent continues to supervise; when a sub-agent reports an anomaly, the meta-agent triggers a coordination mechanism, either instructing the sub-agent to replan, reallocate sub-tasks, or escalate the issue to manual handling.

[0020] Dynamic authorization can be the ability of a meta-agent to grant different execution permissions to sub-agents based on risk levels. Specifically, the meta-agent can grant sub-agents different levels of execution permissions, such as full autonomy, autonomy with checkpoints, or execution after manual confirmation, based on the risk level in the high-level intent. For example, for a business request with a low risk level, the meta-agent can grant the sub-agent full autonomy; for a business request with a high risk level, the meta-agent can grant the sub-agent autonomy with checkpoints, requiring the sub-agent to report and await confirmation after completing the key stage objectives.

[0021] Sub-agents can be tactical execution layer functional entities in a business processing system. In some implementations, sub-agents can receive sub-tasks assigned by meta-agents, decompose the task objectives of the sub-tasks into multiple stage objectives through a hierarchical planning engine, and then decompose each stage objective into a sequence of atomic actions (i.e., action sequences) and execute them sequentially. During execution, the execution quality (i.e., execution confidence) of each atomic action (i.e., the execution action) is evaluated by a metacognitive evaluation module, and the decision is made based on the evaluation results to continue execution, perform local replanning, or provide feedback upwards.

[0022] A hierarchical planning engine can be a functional module within a sub-agent used to hierarchically decompose sub-task objectives. In some implementations, the hierarchical planning engine can perform two-stage planning: the high-level planning stage decomposes the sub-task objective into stage objectives, which correspond to key milestones in the business process; the low-level planning stage decomposes each stage objective into a sequence of atomic actions, which come from a pre-defined action library. For example, for the underwriting rule matching sub-task, the hierarchical planning engine of the sub-agent can decompose its task objective into three stage objectives—entity recognition, rule retrieval, and rule application determination—through high-level planning, and then decompose each stage objective into a corresponding sequence of atomic actions through low-level planning.

[0023] The metacognitive evaluation module can be a functional module within a sub-agent used to evaluate the execution quality of atomic actions. In some implementations, after each atomic action is completed, the metacognitive evaluation module can calculate the execution confidence of the atomic action based on multi-dimensional execution information such as the output quality, execution time, resource consumption, and abnormal signals of the atomic action, and determine subsequent operations based on the comparison result of the execution confidence with a preset threshold. For example, when the execution confidence of an atomic action is greater than a first preset threshold, the metacognitive evaluation module instructs the sub-agent to continue executing the next atomic action; when the execution confidence is less than a second preset threshold, the metacognitive evaluation module instructs the sub-agent to generate an abnormal report and feed it back to the meta-agent.

[0024] The communication and authorization protocol between the two layers can be a standardized protocol specification for communication between the meta-agent and the sub-agents. In some implementations, the communication and authorization protocol can define two communication formats: downlink commands and uplink reports. Downlink commands are sent from the meta-agent to the sub-agents for task allocation and authorization; uplink reports are sent from the sub-agents to the meta-agent for status feedback and anomaly reporting.

[0025] Downlink instructions can be task assignment instructions sent by a meta-agent to a sub-agent. Specifically, the downlink instruction may include fields such as message type, subtask identifier, high-level intent, and authorization scope. The message type characterizes the functional category of the instruction, the subtask identifier uniquely identifies the assigned subtask, the high-level intent conveys information such as the task objective, constraints, success criteria, and risk level, and the authorization scope characterizes the sub-agent's execution authority on the subtask. For example, a meta-agent can send a downlink instruction to a sub-agent with the message type "task assignment," the subtask identifier "ST001," the high-level intent including the objective being underwriting critical illness insurance for thyroid nodules, the constraints being verifying health declarations and matching underwriting rules, the success criteria being a conclusion confidence level greater than 0.85, the risk level being high, and the authorization scope being full autonomy with checkpoints.

[0026] An uplink report can be a status feedback report sent by a sub-agent to a meta-agent. In some implementations, the uplink report may include fields such as message type, subtask identifier, current stage, completed actions, intermediate results, execution confidence, next planned action, and anomaly flag. The message type characterizes the functional category of the report, the subtask identifier is associated with the executed subtask, the current stage characterizes the current stage objective, completed actions characterize the list of completed atomic actions, intermediate results characterize the structured results produced in the current stage, execution confidence characterizes the execution quality score of the current step, next planned action characterizes the atomic action to be executed, and anomaly flag indicates whether there are serious anomalies in the current step. For example, a sub-agent may send an uplink report to the meta-agent with the message type "status update," the subtask identifier "ST001," the current stage "health notification processing," completed actions including entity extraction and disease classification, intermediate results indicating "thyroid nodules, TI-RADS 3," an execution confidence of 0.92, a next planned action "underwriting rule matching," and an anomaly flag of "no."

[0027] In this embodiment, a two-layer cognitive architecture of meta-agent and sub-agent is constructed to achieve explicit decoupling between strategic decision-making and tactical execution. The meta-agent is responsible for high-level intent generation, task decomposition, and global supervision, while the sub-agent is responsible for hierarchical planning and atomic action execution. The two layers communicate with each other through a standardized communication protocol to achieve task distribution, status feedback, and dynamic intervention. This effectively solves the problems of distorted business intent transmission and uncontrollable execution process in the prior art, and realizes hierarchical autonomy and precise control of complex business processes.

[0028] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a business processing method provided in an embodiment of the present invention includes the following steps: S10: In response to receiving a service request, the service intent of the service request is decomposed into multiple sub-tasks; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the service intent.

[0029] In this step, the business request can be initiated by the user terminal, business system or third-party platform, and is a processing request that points to a specific business objective. The business request can contain relevant information required to complete the business, and the business request in different scenarios can be expressed in different content forms.

[0030] For example, in the financial insurance scenario, business requests can be user-submitted insurance applications, claims applications, product consultation requests, or underwriting review requests and premium calculation requests initiated by the insurance company; in the healthcare scenario, business requests can be doctor-initiated auxiliary diagnosis requests, medical insurance reimbursement review requests initiated by the medical insurance department, or prescription review requests initiated by the pharmacist.

[0031] Business intent can be a semantic description of the ultimate goal expected to be achieved by a business request. Business intent can be confirmed through semantic analysis of the request content. Business intent can be a textual description expressed in natural language or a target identifier represented by structured fields. For example, for a critical illness insurance underwriting assessment request, the business intent could be to complete the critical illness insurance underwriting assessment for a user with thyroid nodules; for a product recommendation request, the business intent could be to recommend the optimal insurance product combination based on user profile and budget constraints.

[0032] Decomposing the business intent of a business request into multiple sub-tasks can mean breaking down the final business goal into multiple independent but logically related execution units. Each sub-task corresponds to a relatively independent stage goal. The division of sub-tasks can be based on the business type dimension or the execution stage dimension, ensuring that the goal of each sub-task is clear and the boundaries are well-defined, making it easy to allocate execution.

[0033] In this embodiment of the application, by decomposing the business intent of a business request into multiple sub-tasks, and each sub-task includes a clear task objective, the business intent is explicitly modeled as multiple independently executable task units. This avoids the problem of strategic intent transmission distortion caused by directly mapping high-level business objectives to low-level operation sequences in the prior art, thereby improving the controllability and traceability of the business processing process.

[0034] S11: Decompose the task objectives of each subtask into multiple stage objectives, and determine the action sequence for completing each stage objective; the action sequence includes multiple execution actions arranged in execution order.

[0035] In this step, the stage objectives can be further broken down from the sub-task objectives, corresponding to key milestone nodes in the business process. The completion of each stage objective marks the progress of the business process to a new node. There is a clear logical sequence between the stage objectives, and the completion of the previous stage objective is the basis for the initiation of the next stage objective. For example, the health information collection sub-task can be broken down into stage objectives such as user identity information verification, health notification content extraction, disease entity identification, and past medical history information verification; the image information extraction sub-task can be broken down into stage objectives such as image preprocessing, nodule region detection, nodule feature extraction, and sign information recognition.

[0036] An action sequence can be an ordered set of the smallest execution units required to complete a single stage objective. Each action is an indivisible atomic operation, and the actions are arranged in a dependent order to ensure that the corresponding stage objective is completed by executing the sequence. Execution actions can be predefined standardized operations within the domain, each with clearly defined inputs, outputs, and execution logic. For example, under the stage objective of disease entity recognition, the action sequence may include actions such as text preprocessing, entity extraction, entity standardization, and entity verification; under the stage objective of nodule region detection, the action sequence may include actions such as image normalization, candidate region extraction, false positive removal, and detection result output.

[0037] S12: Execute the action sequence corresponding to each stage objective in sequence according to the order of the stage objectives.

[0038] In this step, the order of the stage goals can be determined based on the logical dependencies of the business process. During execution, the process should be strictly carried out in this order. The execution of the next stage goal should only be started after all actions of the previous stage goal have been completed and verified, so as to avoid logical errors caused by skipping steps in the process.

[0039] When executing the action sequence for each stage's objective, each atomic action is executed sequentially according to the order of the actions, ensuring that the input of each action comes from the correct output of the preceding action. For example, in the underwriting process, all actions in the health information collection stage must be completed before entering the underwriting rule matching stage to avoid rule matching errors due to incomplete information; similarly, in the auxiliary diagnostic process, all actions in the image feature extraction stage must be completed before entering the diagnostic rule matching stage to avoid diagnostic bias due to missing features.

[0040] S13: During the execution of each of the action sequences, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined; in response to the execution confidence being greater than a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed.

[0041] In this step, the target execution action refers to any execution action that has just been completed in the action sequence. After each execution action is completed, the execution quality of the execution action needs to be evaluated, that is, the execution confidence level needs to be determined.

[0042] Execution confidence can be used to quantitatively evaluate the reliability of the execution result of a single atomic action. The value range can be set according to actual needs. For example, it can be set to a value between 0 and 1, or a score between 0 and 10, to measure the accuracy, compliance and usability of the output result of the action.

[0043] The first preset threshold is a critical value used to determine whether the result of an action is reliable and whether subsequent processes can continue. This threshold can be adjusted based on the risk level of the business scenario; a higher threshold is set for high-risk scenarios, while a lower threshold can be appropriately set for low-risk scenarios. No specific limitations are set here. For example, in a high-risk financial underwriting scenario, the first preset threshold can be set to 8 points (out of 10), meaning that an action result is considered reliable when the confidence level is greater than 8 points. In a high-risk medical auxiliary diagnosis scenario, the first preset threshold can be set to 8.5 points to ensure the quality of diagnostic-related actions.

[0044] Upon completion of an action, the execution confidence score is immediately calculated. If the confidence score is higher than a first preset threshold, it indicates that the execution result of the action meets the requirements and can be used as valid input for subsequent actions. Therefore, subsequent actions continue to be executed until the entire action sequence is completed, and the corresponding stage goal is achieved. For example, after the disease entity recognition action is completed, a confidence score of 9.2 is calculated, which is higher than the threshold of 8, indicating that the identified disease entity is accurate and reliable, and can be used as input for subsequent underwriting rule matching actions. After the nodule feature extraction action is completed, a confidence score of 9 is calculated, which is higher than the threshold of 8.5, indicating that the extracted nodule size, shape, density, and other features are accurate and can be used as input for subsequent diagnostic rule matching actions.

[0045] S14: In response to the completion of each of the action sequences, output the business processing result corresponding to the business request.

[0046] In this step, once the action sequence for all stage objectives corresponding to all subtasks has been executed and the execution confidence of each action meets the requirements, the entire business process is considered complete. At this point, the execution results of each stage are integrated to form the final business processing result, which is then output to the requester. The form of the business processing result can vary depending on the business type. For example, in an underwriting scenario, it may output underwriting conclusions, premium details, and insurance recommendations; in an auxiliary diagnostic scenario, it may output diagnostic reference opinions, risk level alerts, and further examination recommendations.

[0047] In some implementations, the business processing result may be the final processing output expected by the business request. The business processing result may include information such as processing conclusions, processing records, and processing confidence levels. For example, for a critical illness insurance underwriting assessment request, the business processing result may include the underwriting conclusion, the underwriting basis, and the hierarchical decision-making path of the underwriting process; for an auxiliary diagnosis request, the business processing result may include auxiliary diagnosis suggestions, diagnostic basis, and traceable records of the diagnostic process.

[0048] In some implementations, the business processing results can be output to the requester in the form of structured data or in the form of natural language text. For example, the underwriting conclusion can be returned to the underwriting requester in the form of structured fields, along with the hierarchical decision path of the underwriting process, so that the requester can trace the underwriting process.

[0049] In this embodiment, in response to a received business request, the business intent of the business request is decomposed into multiple sub-tasks, the task objectives of each sub-task are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined. Thus, by decomposing the business intent layer by layer into sub-tasks, stage objectives, and specific action sequences, a refined breakdown and dynamic execution planning of complex business requests is achieved, significantly improving the flexibility and adaptability of business processing. During the execution of each action sequence, in response to the completion of the target execution action in the target action sequence, the execution confidence of the target execution action is determined. In response to the execution confidence being greater than a first preset threshold, the execution actions following the target execution action in the target action sequence continue to be executed until the action sequence is completed. Thus, after the target execution action is completed, by determining the execution confidence of the target execution action, the execution effect is judged in real time after each action is completed, ensuring that the subsequent process continues only when the action is successfully executed. This effectively avoids the accumulation of errors and invalid execution caused by abnormal intermediate steps, greatly improving the reliability of business processing.

[0050] In some implementations, such as Figure 3 As shown, step S10 may include the following steps: S20: Based on the business intent, determine the target information of the business request; the target information includes any one of the following: business type and execution stage of the business request; S21: Based on the target information, the business intent is decomposed into the plurality of sub-tasks; wherein, in response to the target information being the business type, the plurality of sub-tasks correspond to different business types; in response to the target information being the execution stage, the plurality of sub-tasks correspond to different execution stages.

[0051] In this embodiment, when decomposing a business intent into multiple sub-tasks, the target information of the business request can be determined based on the business intent, and then the business intent can be decomposed into multiple sub-tasks based on the target information. Depending on the different types of target information, the multiple sub-tasks obtained by decomposition correspond to different dimensions.

[0052] The target information can be either the business type or the execution stage of the business request. The business type refers to the category of business involved in the request. When a business request contains multiple different categories of business processing requirements, it can be divided into sub-tasks according to the business type, with each sub-task corresponding to the processing of one type of business. For example, when a user's request includes both critical illness insurance and medical insurance application requirements, the business type includes both critical illness insurance underwriting and medical insurance underwriting. In this case, the business intent can be decomposed into critical illness insurance underwriting sub-tasks and medical insurance underwriting sub-tasks, with each sub-task handling its corresponding type of business, and the final result integrated. In a medical scenario, when a request includes both pulmonary nodule diagnosis and medical insurance expense calculation requirements, it can be decomposed into auxiliary diagnosis sub-tasks and medical insurance review sub-tasks, each handling its corresponding type of business.

[0053] The execution phase can refer to the different stages a business process goes through from initiation to completion. When a business request is a complex business of a single type, it can be divided into sub-tasks according to the execution phase, with each sub-task corresponding to the processing of an execution phase. For example, for a single critical illness insurance underwriting request, the execution phase can be divided into information collection phase sub-tasks, rule matching phase sub-tasks, and conclusion generation phase sub-tasks; for a single pulmonary nodule auxiliary diagnosis request, the execution phase can be divided into information extraction phase sub-tasks, diagnostic analysis phase sub-tasks, and report generation phase sub-tasks.

[0054] In some implementations, business requests can be input into a meta-agent, which then outputs the corresponding business intent and constraints. In other implementations, the meta-agent, along with the business intent and constraints, can also output the success criteria for processing the business request and the risk level of the request. The business intent, constraints, success criteria, and risk level constitute a high-level intent. The meta-agent then decomposes the high-level intent into multiple sub-tasks based on the business domain (i.e., business category) involved.

[0055] In this embodiment, by determining the target information based on the business intent, and decomposing the business intent into multiple sub-tasks corresponding to different dimensions according to the different situations of the target information being a business type or execution stage, the sub-task decomposition method can flexibly adapt to different types of business requests, thereby improving the flexibility and applicability of business intent decomposition.

[0056] In some implementations, step S11 may include the following steps: S30: Based on the task objectives of each sub-task, determine the target business process template corresponding to each sub-task from a preset business process template library; the business process template library includes multiple task objectives and business process templates corresponding to each task objective. S31: Select stage targets that meet the constraints corresponding to each subtask from the candidate stage targets included in the target business process template corresponding to each subtask; the constraints are used to ensure the compliance of the stage target division.

[0057] In this embodiment, when the task objective of a subtask is decomposed into multiple stage objectives, a target business process template corresponding to the subtask can be determined from a preset business process template library, and then stage objectives that meet the constraints can be selected from the candidate stage objectives contained in the target business process template, thereby obtaining multiple stage objectives of the subtask.

[0058] In some implementations, the business process template library can be a collection of templates pre-built based on domain business rules, regulatory requirements, and historical processing experience. The library stores standard business process templates corresponding to various common task objectives. Each template contains all candidate stage objectives required to complete that task objective, as well as the standard dependencies between these stage objectives. For example, in the financial insurance field, the business process template library includes underwriting task templates, claims task templates, and product recommendation task templates. The underwriting task template includes candidate stage objectives such as information verification, health disclosure processing, rule matching, and conclusion generation. In the medical field, the business process template library includes auxiliary diagnosis task templates, medical insurance review task templates, and prescription review task templates. The auxiliary diagnosis task template includes candidate stage objectives such as information collection, feature extraction, rule matching, and report generation.

[0059] The target business process template can be a business process template in the business process template library that matches the task objective of the subtask. In some implementations, a business process template matching the task objective of the subtask can be retrieved from the business process template library, and the matched business process template can be determined as the target business process template. For example, for a subtask whose task objective is to match underwriting rules based on health information, the business processing device can retrieve an underwriting rule matching process template from the business process template library and use it as the target business process template.

[0060] Candidate stage objectives can be alternative stage objectives included in the target business process template for completing the corresponding task objective. In some implementations, a business process template may contain multiple candidate stage objectives, which constitute a complete set of stage objectives for completing the task objective. For example, an underwriting rule matching process template may contain multiple candidate stage objectives such as entity recognition, rule retrieval, and rule application determination.

[0061] Constraints can be conditions used to ensure the compliance of the phase target division. In some implementations, constraints may include at least one of business compliance constraints, regulatory requirement constraints, and business logic constraints, to ensure that the phase targets selected from the candidate phase targets comply with business rules and regulatory compliance requirements. For example, in an underwriting scenario, constraints may include the requirement to verify health declarations and to display disclaimers; if a candidate phase target does not meet the above constraints, it will be excluded during the selection process.

[0062] Constraints can be determined when a business request is received and the business intent of the request is obtained.

[0063] In this embodiment, the stage objectives are decomposed by matching business process templates and filtering constraints. This ensures that the stage division conforms to standard business processes and compliance requirements, avoiding process omissions or violations. It also allows for flexible adjustment of stage objectives based on the actual situation of the current request, avoiding the execution of invalid processes and improving processing efficiency and compliance.

[0064] In some implementations, step S11 may include the following steps: S40: For each stage objective, determine the current business status and the target business status that the stage objective needs to achieve; S41: Determine multiple candidate execution actions from a preset action library required to transition from the current business state to the target business state; the preset action library contains execution actions for transitioning each business state; S42: Determine the execution order of each candidate action based on the dependency relationship between them, and obtain the action sequence of the stage target.

[0065] In this embodiment, the current business state can be the business state of the business processing device when the stage goal begins to be executed. The current business state can include the output results of the completed previous stage goals and the currently available business data, etc.

[0066] The target business state can be the business state that a stage objective needs to achieve. For example, when the health notification processing stage objective is initiated, the current business state is that the user-submitted health notification text has been obtained, but disease information extraction has not yet been performed; the target business state is that structured user disease information has been obtained, which can be used for subsequent rule matching. When the nodule feature extraction stage objective is initiated, the current business state is that the patient's lung images have been obtained, but feature analysis has not yet been performed; the target business state is that structured nodule feature information has been obtained, which can be used for subsequent diagnostic matching.

[0067] A preset action library can be a pre-built library of execution actions that transition between various business states. In some implementations, the preset action library may contain multiple execution actions, each defining an input mode, execution logic, output mode, preconditions, and postconditions to achieve the transition from one business state to another. For example, in the financial insurance field, the preset action library may contain at least one type of action, such as information collection actions, entity recognition actions, rule matching actions, calculation and analysis actions, clause processing actions, and compliance inspection actions; in the healthcare field, the preset action library may contain at least one type of action, such as symptom analysis actions, indicator extraction actions, diagnostic rule matching actions, and medication verification actions.

[0068] Candidate actions can be actions determined from a preset action library required to transition from the current business state to the target business state. In some implementations, a transition path from the current business state to the target business state can be searched in the preset action library, and the actions involved in that path can be identified as candidate actions. For example, for a transition from a state where structured disease codes have been output to a state where matching underwriting rules have been retrieved, rule coding mapping actions and rule retrieval actions can be identified from the preset action library as candidate actions.

[0069] Dependencies can be constraints on the execution order between candidate actions. In some implementations, dependencies can include at least one type, such as strong sequential dependency, weak sequential dependency, and conditional dependency. Strong sequential dependency means that the preconditions of subsequent actions depend on the output of preceding actions, and they must be executed strictly in the predetermined order. Weak sequential dependency means that a suggested execution order exists, but adjustments are allowed in specific scenarios. Conditional dependency means that execution is triggered only when specific conditions are met. For example, there is a strong sequential dependency between the disease entity identification action and the underwriting rule matching action because rule matching requires the structured disease code output by entity identification. There is a weak sequential dependency between the disclaimer reminder action and the underwriting rule matching action; it is recommended that the action be executed after rule matching to accurately remind users of relevant disclaimers based on the matching results, but adjustments to the execution order are allowed in specific scenarios. It should be noted that the dependencies between candidate actions can be set according to actual circumstances, and no specific limitations are imposed here.

[0070] Determining the execution order based on dependencies can be achieved by topologically sorting the candidate actions according to their dependencies, thus forming a directed acyclic execution order constraint. For example, for the rule encoding and mapping action and the rule retrieval action, there is a strong sequential dependency between them. The rule encoding and mapping action must be executed before the rule retrieval action. Based on this, the business processing device determines the execution order as rule encoding and mapping first, followed by rule retrieval.

[0071] In this embodiment, by determining the current business state and the target business state, and selecting candidate actions from a preset action library, and then determining the execution order based on dependencies, the determination of the action sequence is based on business state transitions and action dependencies, thereby ensuring that the action sequence conforms to business logic and execution order constraints, and improving the professionalism and executability of the action sequence.

[0072] In some implementations, step S13 may include the following steps: S50: Obtain the execution information of the target action; the execution information includes at least one of the following: the output quality upon completion of execution, the execution time, the resource consumption during execution, and the abnormal signals during execution; S51: Determine the execution confidence level based on the execution information.

[0073] In this step, the execution information can be multi-dimensional information generated during the execution of the target action for evaluating execution quality. In some implementations, the execution information may include at least one of the following: output quality upon completion of execution, execution time, resource consumption during execution, and abnormal signals during execution.

[0074] Output quality refers to the accuracy and compliance of the output results after an action is performed. Different types of actions can use different quality measurement standards, which are not specifically limited here. For example, the output quality of entity recognition actions can be measured by the accuracy of the recognition results, the output quality of calculation actions can be measured by the degree of deviation between the calculation results and the standard results, and the output quality of rule matching actions can be measured by the degree of compliance between the matching results and the rule clauses.

[0075] Execution time refers to the time taken from the start to the completion of the target action. Each type of action has a preset normal time range according to the actual situation. If the time exceeds the normal range, it indicates that there may be abnormalities in the execution process, such as data acquisition timeout or model inference lag, which will affect the reliability of the results.

[0076] Resource consumption refers to the amount of system or external resources called during the execution of an action, such as the number of database queries, the number of API calls, and the resource usage of model calculations. If the resource consumption is far beyond the normal range, it indicates that there may be logical errors in the execution of the action, such as duplicate queries or infinite loops, which will affect the reliability of the results.

[0077] Abnormal signals can refer to abnormal situations that occur during the execution of an action, such as empty output, results that contradict the context, rule conflicts, interface return errors, missing data, etc. These signals can directly indicate that there may be problems with the execution of the action.

[0078] When calculating the confidence level, the aforementioned multi-dimensional execution information can be normalized and then weighted according to preset weights to obtain the final execution confidence level. It should be noted that the preset weights for each dimension of execution information can be set according to the characteristics of the business scenario, and this application embodiment does not impose specific limitations on this. For example, in scenarios with high compliance requirements such as finance and insurance, the weight of the abnormal signal penalty value can be appropriately increased to enhance sensitivity to abnormal situations; in scenarios with high security requirements such as healthcare, the weight of output quality can be appropriately increased to ensure the accuracy of the output results.

[0079] For example, the output quality weight is set to 0.35, the execution time weight to 0.2, the resource consumption weight to 0.2, and the abnormal signal weight to 0.25, ensuring that the confidence score comprehensively reflects the situation of each dimension. For example, after the disease entity recognition action is completed, the output disease entity has a verified accuracy rate of 95%, the execution time is within the normal range, the resource usage is as expected, and there are no abnormalities such as empty results or contradictory results. The comprehensive calculation yields a confidence score of 9.2 points (out of 0 to 10), which is higher than the first preset threshold of 8 points, allowing subsequent actions to continue.

[0080] In this embodiment, by acquiring multi-dimensional execution information including output quality, execution time, resource consumption, and abnormal signals, and determining the execution confidence level accordingly, the execution confidence level can comprehensively reflect the multi-dimensional execution quality of the target execution action, thereby improving the comprehensiveness and accuracy of the execution quality assessment and providing a reliable basis for subsequent dynamic decision-making.

[0081] In some implementations, after step S13, the business processing method provided in this application embodiment may further include the following steps: S60: In response to the execution confidence being less than or equal to a first preset threshold and the execution confidence being greater than or equal to a second preset threshold, the execution of the execution action following the target execution action in the target action sequence is paused; wherein, the second preset threshold is less than the first preset threshold; S61: Based on the reasons that cause the execution confidence to be less than or equal to the first preset threshold, redetermine the action sequence within the stage target to which the target execution action belongs; S62: Continue execution according to the redefined sequence of actions.

[0082] In this embodiment, if the execution confidence is less than or equal to the first preset threshold and greater than or equal to the second preset threshold, the execution of the subsequent execution actions in the target action sequence is paused, the reasons for insufficient execution confidence are analyzed, the action sequence is re-determined within the stage target to which the target execution action belongs, and the execution continues according to the re-determined action sequence.

[0083] The second preset threshold can be a threshold used to determine whether the execution quality of the target action needs to trigger local replanning. In some implementations, the second preset threshold is less than the first preset threshold, for example, it can be set to 3. When the execution confidence of the target action is less than or equal to the first preset threshold 8 and greater than or equal to the second preset threshold 3, it indicates that although the execution quality of the target action does not meet the conditions for continuing execution, it has not yet reached a serious abnormality level, and recovery can be attempted through local replanning.

[0084] Suspending the execution of actions following the target action in the target action sequence can be achieved by freezing unexecuted actions after the target action in the target action sequence when the execution confidence level is determined to be within the aforementioned range, and ceasing execution according to the original action sequence. In some implementations, the suspension operation can prevent the continuation of subsequent execution actions when the execution quality is insufficient, thus preventing the deviation from expanding. For example, when the execution confidence level of the entity extraction execution action is 5.5, the service processing device suspends the execution of entity standardization execution actions following the entity extraction execution action in the action sequence.

[0085] The reason for the execution confidence level being less than or equal to the first preset threshold can be the root cause of insufficient execution quality as determined by analysis. In some implementations, the reason may include at least one of the following: ambiguous entity recognition, rule matching conflict, change in constraints, and missing data. For example, in the case of insufficient execution confidence for entity extraction execution actions, the reason determined by analysis may be that the disease description in the input health information text is ambiguous, leading to unclear entity recognition.

[0086] In some implementations, the reason for the execution confidence level being less than or equal to a first preset threshold can be determined by collecting the execution characteristics of the target execution action. These execution characteristics may include at least one of the following: error codes returned by the interface, execution time, integrity identifiers of returned data, and attribute information of input parameters. Based on a preset rule base, the execution characteristics are matched and analyzed to determine the fault type corresponding to the characteristic (such as invalid parameters, service timeout, or missing data) as the reason for the low execution confidence level. Alternatively, context information including business request content, execution logs, and intermediate results can be input into the sub-agent of the subtask corresponding to the target execution action, and the sub-agent can output the reason for the low confidence level.

[0087] Within the stage objective to which the target action belongs, the action sequence can be redefined. Within the current stage objective's scope, based on the reasons for insufficient execution confidence, low-level planning can be re-performed to attempt to generate alternative action sequences. In some implementations, the current business state and the target business state can be redefined, and alternative actions can be searched again from a preset action library to form a new action sequence. For example, regarding the cause of ambiguous entity recognition, the business processing device can redefine the action sequence within the entity recognition stage objective, adding a context completion action to supplement the contextual information of the disease description, and then performing the entity extraction action.

[0088] Continuing execution according to the redefined action sequence allows for the continuation of each action following the new sequence, with an execution confidence assessment performed after each action is completed. In some implementations, if the redefined action sequence is successfully executed, the objective for this stage is achieved; if insufficient execution confidence still occurs during the execution of the redefined action sequence, local replanning or upward feedback can be triggered again.

[0089] It should be noted that the aforementioned local replanning is carried out within the stage objectives to which the target execution action belongs. That is, the scope of replanning is limited to the current stage objectives and does not involve adjustments to other stage objectives or sub-tasks, thereby ensuring the locality and efficiency of replanning.

[0090] In this embodiment, by triggering local replanning when the execution confidence is in the middle range, the action sequence is redefined within the current stage objective and execution continues. This enables automatic detection and local adjustment when there is a deviation in execution quality, avoiding direct interruption of the business process. This achieves the evolution from static planning to dynamic autonomy, significantly improving robustness and autonomy in complex scenarios.

[0091] In some implementations, after step S13, the business processing method provided in this application embodiment may further include the following steps: S70: In response to the execution confidence being less than a second preset threshold, pause the execution of the execution actions following the target execution action in the target action sequence and generate an exception report.

[0092] In this embodiment, an execution confidence level less than a second preset threshold indicates that the execution quality of the target action has reached a severely abnormal level and cannot be recovered through local replanning. In some implementations, when the execution confidence level of the target action is less than the second preset threshold, it indicates that the output result of the action has a serious defect or that the execution process has a serious anomaly, requiring feedback and the generation of an anomaly report. For example, when the execution confidence level of a rule-matching action is 2.1, it indicates that the action has a serious rule conflict or data missing, which cannot be resolved through local replanning.

[0093] Suspending the execution of actions following the target action in a target action sequence can be achieved by freezing unexecuted actions following the target action in the target action sequence when the execution confidence level is determined to be less than a second preset threshold. In some implementations, the suspension operation can prevent continued execution under severe abnormal conditions, thus preventing erroneous business processing results.

[0094] An anomaly report can be a report indicating a serious anomaly in the execution process. In some implementations, the anomaly report may include at least one of the following: current status information, attempted solutions information, failure reason information, and suggested adjustment direction information. For example, the anomaly report may include the rule matching execution action currently executing to the rule matching stage target, attempted local replanning solutions, the reason for failure being conflicting rules in the underwriting rule base, and suggested adjustment direction such as updating the underwriting rule base or upgrading to manual processing.

[0095] In some implementations, after generating an anomaly report, the sub-agent can feed the report back to the meta-agent via an uplink report, allowing the meta-agent to make decisions based on the report. In other implementations, the meta-agent can use the current status information, attempted solutions information, failure reason information, and suggested adjustment direction information in the anomaly report to decide whether to adjust the sub-task objective, reassign the sub-task, or escalate to manual processing. For example, in high-risk scenarios such as finance and insurance, the meta-agent can send the anomaly report to a manual processing terminal for review and handling by professionals; in high-security scenarios such as healthcare, the meta-agent can decide to adjust the sub-task objective or reassign the sub-task, which will then be re-executed by the corresponding sub-agent.

[0096] In this embodiment, by pausing execution and generating an anomaly report when the execution confidence level is lower than the second preset threshold, it is possible to report serious anomalies in a timely manner, avoid erroneous business processing results, and provide structured anomaly information for subsequent strategy adjustments or manual intervention, thereby ensuring the security and compliance of the business processing process.

[0097] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0098] In one embodiment, a service processing apparatus is provided, which corresponds one-to-one with the service processing methods described in the above embodiments. For example... Figure 4 As shown, the business processing device includes a decomposition module 101, a determination module 102, an execution module 103, a response module 104, and an output module 105. Detailed descriptions of each functional module are as follows: The decomposition module 101 is configured to, in response to receiving a service request, decompose the service intent of the service request into multiple sub-tasks; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the service intent. The determining module 102 is used to decompose the task objectives of each subtask into multiple stage objectives, and to determine the action sequence for completing each stage objective; the action sequence includes multiple execution actions arranged in execution order; The execution module 103 is used to execute the action sequence corresponding to each of the stage objectives in sequence according to the order of the stage objectives; The response module 104, during the execution of each of the action sequences, determines the execution confidence of the target execution action in response to the completion of the target execution action in the target action sequence; and continues to execute the execution actions after the target execution action in the target action sequence in response to the completion of the action sequence when the execution confidence is greater than a first preset threshold, until the action sequence is completed. The output module 105 is used to output the business processing result corresponding to the business request in response to the completion of each of the action sequences.

[0099] In one embodiment, the decomposition module 101 is specifically used for: Based on the business intent, determine the target information of the business request; the target information includes any one of the following: business type and execution stage of the business request; Based on the target information, the business intent is decomposed into the plurality of sub-tasks; wherein, in response to the target information being the business type, the plurality of sub-tasks correspond to different business types; in response to the target information being the execution stage, the plurality of sub-tasks correspond to different execution stages.

[0100] In one embodiment, the determining module 102 is specifically used for: Based on the task objectives of each subtask, a target business process template corresponding to each subtask is determined from a preset business process template library; the business process template library includes multiple task objectives and business process templates corresponding to each task objective. From the candidate stage objectives contained in the target business process template corresponding to each subtask, stage objectives that meet the constraints corresponding to each subtask are selected; the constraints are used to ensure the compliance of the stage objective division.

[0101] In one embodiment, the determining module 102 is specifically used for: For each stage objective, determine the current business status and the target business status that the stage objective needs to achieve; From a preset action library, determine multiple candidate actions required to transition from the current business state to the target business state; the preset action library contains the actions required to transition between each business state. Based on the dependencies between the candidate actions, the execution order of each candidate action is determined to obtain the action sequence of the stage objective.

[0102] In one embodiment, the response module 104 is specifically used for: Obtain execution information of the target action; the execution information includes at least one of the following: output quality upon completion of execution, execution time, resource consumption during execution, and abnormal signals during execution; The execution confidence level is determined based on the execution information.

[0103] In one embodiment, the service processing apparatus is further configured to: In response to the execution confidence being less than or equal to a first preset threshold and the execution confidence being greater than or equal to a second preset threshold, the execution of the subsequent execution actions in the target action sequence is paused; wherein the second preset threshold is less than the first preset threshold; Based on the reasons that cause the execution confidence to be less than or equal to the first preset threshold, the action sequence is re-determined within the stage target to which the target execution action belongs; Continue execution according to the redefined sequence of actions.

[0104] In one embodiment, the service processing apparatus is further configured to: In response to the execution confidence being less than a second preset threshold, the execution of subsequent actions in the target action sequence is paused, and an exception report is generated.

[0105] This invention provides a business processing apparatus that, in response to a received business request, decomposes the business intent of the request into multiple sub-tasks, decomposes the task objectives of each sub-task into multiple stage objectives, and determines the action sequence for completing each stage objective. Thus, by progressively decomposing the business intent into sub-tasks, stage objectives, and specific action sequences, it achieves refined decomposition and dynamic execution planning of complex business requests, significantly improving the flexibility and adaptability of business processing. During the execution of each action sequence, in response to the completion of the target action in the target action sequence, it determines the execution confidence of the target action. If the execution confidence exceeds a first preset threshold, it continues executing the subsequent actions in the target action sequence until the action sequence is completed. Therefore, by determining the execution confidence of the target action after its completion, it achieves real-time judgment of the execution effect after each action is completed, ensuring that subsequent processes continue only when an action is successfully executed. This effectively avoids error accumulation and invalid execution caused by abnormal intermediate steps, greatly improving the reliability of business processing.

[0106] Specific limitations regarding the business processing device can be found in the limitations regarding the business processing method described above, and will not be repeated here. 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 the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0107] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements a business processing method, server-side function, or step.

[0108] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. 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 and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements a business processing method, client-side functions, or steps.

[0109] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: In response to receiving a service request, the service intent of the service request is decomposed into multiple sub-tasks; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the service intent; The task objectives of each subtask are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined; the action sequence includes multiple execution actions arranged in execution order. According to the order in which the stage goals are arranged, the action sequence corresponding to each stage goal is executed sequentially; During the execution of each of the action sequences, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined; in response to the execution confidence being greater than a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed. Upon completion of each of the aforementioned action sequences, the business processing result corresponding to the business request is output.

[0110] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: In response to receiving a service request, the service intent of the service request is decomposed into multiple sub-tasks; each sub-task includes a task objective, and the task objectives of the multiple sub-tasks are used to satisfy the service intent; The task objectives of each subtask are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined; the action sequence includes multiple execution actions arranged in execution order. According to the order in which the stage goals are arranged, the action sequence corresponding to each stage goal is executed sequentially; During the execution of each of the action sequences, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined; in response to the execution confidence being greater than a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed. Upon completion of each of the aforementioned action sequences, the business processing result corresponding to the business request is output.

[0111] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0112] 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. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0114] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0115] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A business processing method, characterized in that, include: In response to receiving a business request, the business intent of the business request is decomposed into multiple sub-tasks; Each of the subtasks includes a task objective, and the task objectives of the plurality of subtasks are used to satisfy the business intent; The task objectives of each subtask are decomposed into multiple stage objectives, and the action sequence for completing each stage objective is determined; the action sequence includes multiple execution actions arranged in execution order. According to the order in which the stage goals are arranged, the action sequence corresponding to each stage goal is executed sequentially; During the execution of each of the action sequences, in response to the completion of the target action in the target action sequence, the execution confidence of the target action is determined; in response to the execution confidence being greater than a first preset threshold, the execution actions following the target action in the target action sequence continue to be executed until the action sequence is completed. Upon completion of each of the aforementioned action sequences, the business processing result corresponding to the business request is output.

2. The method according to claim 1, characterized in that, The process of decomposing the business intent of the business request into multiple sub-tasks includes: Based on the business intent, determine the target information of the business request; the target information includes any one of the following: business type and execution stage of the business request; Based on the target information, the business intent is decomposed into the plurality of sub-tasks; wherein, in response to the target information being the business type, the plurality of sub-tasks correspond to different business types; in response to the target information being the execution stage, the plurality of sub-tasks correspond to different execution stages.

3. The method according to claim 1, characterized in that, The step of decomposing the task objectives of each sub-task into multiple stage objectives includes: Based on the task objectives of each subtask, a target business process template corresponding to each subtask is determined from a preset business process template library; the business process template library includes multiple task objectives and business process templates corresponding to each task objective. From the candidate stage objectives contained in the target business process template corresponding to each subtask, stage objectives that meet the constraints corresponding to each subtask are selected; the constraints are used to ensure the compliance of the stage objective division.

4. The method according to claim 1, characterized in that, The determination of the action sequence for completing each stage objective includes: For each stage objective, determine the current business status and the target business status that the stage objective needs to achieve; From a preset action library, determine multiple candidate actions required to transition from the current business state to the target business state; the preset action library contains the actions required to transition between each business state. Based on the dependencies between the candidate actions, the execution order of each candidate action is determined to obtain the action sequence of the stage objective.

5. The method according to claim 1, characterized in that, Determining the execution confidence of the target action includes: Obtain execution information of the target action; the execution information includes at least one of the following: output quality upon completion of execution, execution time, resource consumption during execution, and abnormal signals during execution; The execution confidence level is determined based on the execution information.

6. The method according to claim 1, characterized in that, After determining the execution confidence of the target action, the method further includes: In response to the execution confidence being less than or equal to a first preset threshold and the execution confidence being greater than or equal to a second preset threshold, the execution of the subsequent execution actions in the target action sequence is paused; wherein the second preset threshold is less than the first preset threshold; Based on the reasons that cause the execution confidence to be less than or equal to the first preset threshold, the action sequence is re-determined within the stage target to which the target execution action belongs; Continue execution according to the redefined sequence of actions.

7. The method according to claim 1, characterized in that, After determining the execution confidence of the target action, the method further includes: In response to the execution confidence being less than a second preset threshold, the execution of subsequent actions in the target action sequence is paused, and an exception report is generated.

8. A business processing apparatus, characterized in that, include: The decomposition module is used to decompose the business intent of the received business request into multiple sub-tasks in response to the received business request. Each of the subtasks includes a task objective, and the task objectives of the plurality of subtasks are used to satisfy the business intent; The determination module is used to decompose the task objectives of each subtask into multiple stage objectives, and to determine the action sequence for completing each stage objective; the action sequence includes multiple execution actions arranged in execution order; The execution module is used to execute the action sequence corresponding to each of the stage objectives in the order of their arrangement. The response module, during the execution of each action sequence, determines the execution confidence of the target action in the target action sequence upon completion of the target action; and continues to execute the subsequent actions in the target action sequence until the action sequence is completed if the execution confidence is greater than a first preset threshold. The output module is used to output the business processing result corresponding to the business request in response to the completion of each of the action sequences.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the business processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the business processing method as described in any one of claims 1 to 7.

Images