Human-machine confirmation control method for task execution of an agent

Abstract

The present application relates to the field of artificial intelligence, and particularly relates to a man-machine confirmation control method for task execution of an intelligent agent, comprising: obtaining a task graph snapshot, extracting a risk factor of a node that has not been executed, calculating a comprehensive risk score according to the risk factor, marking a node that reaches a dynamic threshold or hits a forced confirmation rule as a risk node, inserting a confirmation node to obtain a rewritten task graph, generating confirmation information according to the information of the risk node, and generating a binding summary, obtaining feedback information for the confirmation information, in the rewritten task graph, performing consistency checking on the binding summary and the current actual information of the risk node according to the changed state of the confirmation node, and controlling the execution of the risk node when the checking is passed. The present application realizes dynamic confirmation and tamper-proof binding, and improves the execution safety of high-risk operations of the intelligent agent.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and more specifically to a human-machine verification control method for intelligent agent task execution. Background Technology

[0002] With the rapid development of large language models and intelligent agent technology, intelligent agents can now automatically plan tasks based on task objectives, generate task graphs containing multiple nodes and dependencies between them, and execute each node in the task graph step by step by calling external tools. This automated task orchestration and execution method is being increasingly widely used in scenarios such as data analysis, office collaboration, system maintenance, and financial transactions, significantly improving the execution efficiency of complex tasks.

[0003] During the automatic execution of tasks by intelligent agents, some action nodes may involve high-risk operations, such as batch deleting data, sending information to external systems, making large payments, or exporting sensitive data. Currently, control methods for such high-risk actions mainly fall into two categories: one is to conduct overall confirmation before task execution, where the user approves all steps at once when the task starts. However, this method cannot dynamically assess risks based on intermediate results during task execution, resulting in a poor user experience and insufficient security. The other method involves developers pre-setting fixed confirmation rules in the code, such as forcing a confirmation dialog box to pop up when a specific tool is called. However, this method lacks a comprehensive assessment of the task context and dependencies, and the confirmation content is not bound to the actual parameters and dependency context of the node to be executed. There is a risk that the confirmation may be tampered with after confirmation or that invalid confirmations may still be used after the context changes.

[0004] Therefore, there is an urgent need for a human-machine confirmation control method for intelligent agent task execution, which dynamically identifies high-risk nodes and inserts a human confirmation step during the task graph execution process. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a human-machine confirmation control method for intelligent agent task execution, in order to solve the technical problems in related technologies such as confirmation mechanism relying on static rules, lack of binding between confirmation content and execution node, and risk of tampering after confirmation.

[0006] In a first aspect, embodiments of the present invention provide a human-machine confirmation control method for intelligent agent task execution, the method comprising: In response to the existence of nodes in the task graph that have not yet been executed, a snapshot of the task graph is obtained. The snapshot of the task graph includes at least a task graph version identifier, and the task graph contains nodes and the dependencies between nodes. Extract the risk factors of the nodes that have not yet been executed, calculate the comprehensive risk score based on the risk factors, and generate a dynamic threshold based on the current context. Mark the nodes whose comprehensive risk score reaches the dynamic threshold or hit the mandatory confirmation rule as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information. The necessary predecessor nodes of the risk node are determined from the task graph. After the necessary predecessor nodes are completed and before the risk node is executed, a confirmation node is inserted to obtain the rewritten task graph. The rewritten task graph is then subjected to acyclic verification. Confirmation information is generated based on the information of the risk node, and a binding digest is generated. The binding digest is used to prevent the risk node from being tampered with after confirmation. Obtain feedback information regarding the confirmation information, and change the status of the confirmation node according to the type of the feedback information; In the rewritten task graph, based on the changed status of the confirmed node and using the task graph snapshot as a reference, the binding summary is checked for consistency with the current actual information of the risk node; When the verification passes, control the execution of the risk node.

[0007] In conjunction with the first aspect, in one implementation, the risk factors include at least one of the following: scope of impact, data sensitivity level, degree of irreversibility, model uncertainty, user role risk, historical risk, external side effect level, and compliance level; wherein, the model uncertainty is used to characterize the confidence level of the node, the external side effect level is used to characterize the degree of impact of the node on external systems, and the compliance level is used to characterize the degree of compliance of the node with regulatory policies or industry standards; the calculation of a comprehensive risk score based on the risk factors includes: Each of the risk factors is normalized separately, and the normalized risk factors are then weighted and summed to obtain a single-item sum. When there is a factor pair among the risk factors that meets a predetermined condition, an interaction term is added to the factor pair, and the sum of the interaction terms is calculated. The interaction term reflects the combined risk amplification effect generated when the factor pair increases simultaneously. The sum of the individual terms and the sum of the interaction terms are mapped to the unified numerical range using a monotonic function to obtain the comprehensive risk score.

[0008] In conjunction with the first aspect, in one implementation, generating the dynamic threshold based on the current context includes: Obtain a baseline threshold, which is a uniformly configured threshold starting point; The role adjustment amount is determined based on the current user's role information, the business type adjustment amount is determined based on the current task's business type information, and the environment adjustment amount is determined based on the current operating environment information. The baseline threshold is adjusted based on the role adjustment amount, the business type adjustment amount, and the environment adjustment amount to obtain the adjusted threshold. When the context includes historical anomaly information, the intensity information of verified anomaly events in the historical anomaly information within a preset time range is obtained, and the adjusted threshold is reduced based on the intensity information of the anomaly events. The adjusted threshold is limited to a predetermined upper and lower bound range to obtain the dynamic threshold.

[0009] In conjunction with the first aspect, in one implementation, the mandatory confirmation rule includes at least one of cross-tenant write operations, batch deletion operations, payment operations with amounts exceeding a predetermined threshold, operations that send notifications to external systems, and highly sensitive data export operations.

[0010] In conjunction with the first aspect, in one implementation, the necessary predecessor node is the node on which the confirmation information is generated, and the step of inserting the confirmation node after the necessary predecessor node is completed and before the risk node is executed, to obtain the rewritten task graph, includes: Redirect the incoming edges of the necessary predecessor nodes in the task graph that point to the risk nodes to the confirmation nodes; Add a control edge pointing from the confirmation node to the risk node; The incoming edges pointing from unnecessary predecessor nodes to risk nodes in the task graph are kept as they are to obtain the rewritten task graph. When the rewritten task graph forms a loop or causes the semantics of the conditional branches to be ambiguous or unable to cover the risk nodes, the operation of inserting a confirmation node is abandoned and the process is transferred to manual handling.

[0011] In conjunction with the first aspect, in one implementation, the insertion confirmation node includes: When the risk node is located in the conditional branch path, the confirmation node is inserted into the actual branch in the conditional branch path that leads to the risk node; When there are multiple risk nodes that belong to the same atomic transaction group, and the confirmation information can list all actions, parameters and total impact of the multiple risk nodes, the multiple risk nodes can be controlled by a single confirmation node. When the task graph contains a cyclic structure, the confirmation node is inserted into the subgraph corresponding to the current iteration, and the iteration identifier of the current iteration is recorded for use in generating the binding summary. In conjunction with the first aspect, in one implementation, generating confirmation information based on the risk node information and generating the binding summary includes: Obtain the action information, parameter information, target object information, and tool information invoked by the risk node; Based on the action information and the target object information, determine the scope of influence and consequences of the risk node; Based on the calculation results of the risk factors, obtain the risk trigger information of the risk node; Obtain the rollback capability information of the risk node; The confirmation information is generated by combining the action information, parameter information, target object information, tool information, scope of influence and consequence information, risk triggering information, and rollback capability information. Obtain the risk node identifier and the output summary of the necessary predecessor node, and standardize the parameter information to obtain standardized parameters; wherein, the risk node identifier is used to uniquely identify the risk node in the task graph, and the output summary is the output content of the necessary predecessor node; The scope of authority of the provider of the feedback information, and the version identifier of the evaluation parameter configuration on which the dynamic threshold is based; The binding summary is generated by binding the task graph version identifier, the risk node identifier, the standardization parameters, the output summary of the necessary predecessor nodes, the permission scope, and the version identifier of the evaluation parameter configuration.

[0012] In conjunction with the first aspect, in one implementation, the types of feedback information include confirmation passed, parameter modification, execution rejected, and timeout; changing the state of the confirmation node according to the type of feedback information includes: When the feedback information indicates confirmation, the status of the confirmation node is changed to confirmed. When the feedback information indicates parameter modification, the status of the confirmation node is changed to modified, the risk node is updated according to the modified parameters, and the risk is reassessed. If the risk is lower than the dynamic threshold after reassessment, the risk node is released; if it still reaches the dynamic threshold, a new version of the confirmation information is generated. When the feedback information is "rejection", the status of the confirmation node is changed to "rejected", the risk node is blocked, and the rejection reason is converted into a replanning constraint. Based on the replanning constraint, a local replanning is performed on the set of affected nodes in the task graph to generate a local alternative plan. If the local alternative plan cannot be generated, the task is terminated. If the local alternative plan contains high-risk nodes, a new version of the confirmation information is generated. The set of affected nodes includes the rejected risk node, successor nodes that depend on the output of the rejected risk node, and nodes that share the same atomic transaction group as the rejected risk node. When the feedback information is timeout, the status of the confirmation node is changed to timeout, and a stop operation, an upgrade approval operation, or a re-initiation of the confirmation operation is performed.

[0013] In conjunction with the first aspect, in one implementation, the step of verifying the consistency between the binding digest and the current actual information of the risk node includes: Obtain the current actual information of the risk node, which includes the current actual standardized parameters, the actual output summary of the current necessary predecessor node, the current permission scope, and the current actual version identifier of the evaluation parameter configuration; Compare the binding summary with the current actual information; When the binding summary matches the current actual information, the verification passes and the risk node is released. When the binding summary is inconsistent with the current actual information, the verification fails, the confirmation node becomes invalid, and a new version of the confirmation information is generated to re-initiate the confirmation operation.

[0014] In conjunction with the first aspect, in one embodiment, the feature is that it further includes: Record the execution behavior information of the risk node, including the reasoning process information, tool call sequence, and intermediate decision information of the risk node; The behavioral feature vector of the risk node is constructed based on the execution behavior information. The behavioral feature vector includes inference consistency index, tool call compliance index, and decision stability index. The behavioral feature vector is compared with the historical behavioral feature vector of the risk node to obtain the feature deviation. When the characteristic deviation exceeds a predetermined range, a behavior abnormality signal is generated; The generation rules for the dynamic threshold can be adjusted based on the abnormal behavior signal, or the abnormal behavior signal can be used as a new triggering condition for the mandatory confirmation rule, so that the risk node hits the mandatory confirmation rule in subsequent evaluations.

[0015] In this embodiment of the invention, during the execution of the task graph, risk factors of nodes that have not yet been executed are extracted and a comprehensive risk score is calculated. A confirmation threshold is dynamically generated in combination with the current context, thereby accurately triggering manual confirmation for high-risk nodes instead of uniformly interrupting all operations. The confirmation node is inserted into the task graph after the necessary predecessor node is completed and before the risk node is executed. The confirmation decision is bound to the task graph version and node context in an anti-tampering manner through binding digest. Before execution, it is re-verified based on the task graph snapshot to ensure that only actions consistent with the context at the time of confirmation are released for execution. This effectively prevents the confirmation from being tampered with after confirmation or the use of invalid confirmations after context changes, thereby improving the execution security of high-risk operations of the agent and the reliability of human-machine collaboration.

[0016] Secondly, embodiments of the present invention provide a human-machine confirmation control device for intelligent agent task execution, the device comprising: The snapshot acquisition module is used to acquire a snapshot of the task graph in response to the existence of nodes that have not yet been executed in the task graph. The snapshot of the task graph includes at least a task graph version identifier, and the task graph contains nodes and the dependencies between nodes. The risk marking module is used to extract the risk factors of the nodes that have not yet been executed, calculate the comprehensive risk score based on the risk factors, generate a dynamic threshold based on the current context, and mark the nodes whose comprehensive risk score reaches the dynamic threshold or hit the mandatory confirmation rule as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information. The graph rewriting module is used to determine the necessary predecessor nodes of the risk node from the task graph, insert a confirmation node after the necessary predecessor node is completed and before the risk node is executed, obtain the rewritten task graph, and perform acyclic verification on the rewritten task graph. The confirmation generation module is used to generate confirmation information based on the information of the risk node and generate a binding summary, which is used to prevent the risk node from being tampered with after confirmation. The feedback processing module is used to obtain feedback information in response to the confirmation information and change the state of the confirmation node according to the type of the feedback information. The consistency verification module is used to perform consistency verification between the binding summary and the current actual information of the risk node in the rewritten task graph, based on the status of the confirmed node after the change and using the task graph snapshot as a reference. The execution control module is used to control the execution of the risk node when the verification passes.

[0017] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform a human-machine confirmation control method for intelligent agent task execution as described in the first aspect or any corresponding embodiment.

[0018] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute a human-machine confirmation control method for intelligent agent task execution as described in the first aspect or any corresponding embodiment. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a human-machine confirmation control method for intelligent agent task execution according to an embodiment of the present invention; Figure 2 These are comparative example diagrams of task graph rewriting according to embodiments of the present invention; Figure 3 This is a schematic diagram of the feedback status change of the confirmation node according to an embodiment of the present invention; Figure 4 This is a structural block diagram of a human-machine confirmation control device for intelligent agent task execution according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 embodiments of the present invention, not all embodiments. 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.

[0022] This invention provides a human-machine confirmation control method for intelligent agent task execution, addressing the technical problems in related technologies such as confirmation mechanisms relying on static rules, lack of binding between confirmation content and the node to be executed, and the risk of tampering after confirmation. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that presented here.

[0023] This embodiment provides a human-machine confirmation control method for intelligent agent task execution. Figure 1 This is a flowchart of a human-machine verification control method for intelligent agent task execution according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: In response to the existence of nodes in the task graph that have not yet been executed, obtain a snapshot of the task graph. The snapshot of the task graph includes at least the task graph version identifier. The task graph contains nodes and the dependencies between nodes.

[0024] In this embodiment, a task graph snapshot can be obtained in response to the existence of unexecuted nodes in the task graph. The task graph snapshot includes at least a task graph version identifier, and the task graph contains nodes and dependencies between nodes. After receiving the task objective, the agent generates an initial task graph based on success conditions, available tools, user identity, and business policies. The task graph defines the execution steps required to complete the objective and the order in which these steps are executed. The task graph snapshot is a fixed record of the current task graph structure, providing a benchmark for determining the insertion position of nodes and for consistency verification before execution in subsequent steps. The task graph version identifier can be a version number obtained by summarizing the current node set and edge set, used to distinguish the structural state of the task graph at different times. A node can be an action unit in the task execution process, such as reading project materials, extracting contacts, generating the body text, generating attachments, sending emails, and recording the sending results. Dependencies can represent data dependencies or control dependencies between nodes. For example, the "generate body text" node must be executed after the "read project materials" node is completed, and the "send email" node must be executed after the body text, attachments, and recipients have all been generated.

[0025] In practical implementation, task graph snapshots can be acquired either when an unexecuted node is first detected, or after a local replanning of the task graph causes changes in nodes or dependencies. The snapshot coverage must include at least the node to be evaluated, its necessary predecessors, and necessary successors, ensuring the legitimacy of subsequent node insertions can be verified. Task graph version identifiers can be generated by performing a hash algorithm to summarize the node identifier set and edge relationship set. A new version identifier is generated when a node's controlled state, key parameters, or dependencies change. For nodes obtained through dynamic planning by the agent model, the task graph snapshot can simultaneously save the node's planning basis and tool pattern; for nodes provided by business process definitions, the task graph snapshot can simultaneously save the process definition version for tracing the node's origin during subsequent audits.

[0026] Taking the task of sending outgoing emails by an intelligent agent as an example, the initial task graph includes nodes for reading project materials, extracting contacts, generating email body, generating attachments, sending email, and recording sending results. These nodes are sequentially connected by data dependency edges. After the task starts but before the "read project materials" node is executed, a snapshot of the task graph is obtained. This snapshot contains a version identifier v1 calculated based on the identifiers of the six nodes and the dependency edges. When the user modifies the recipient parameters during the confirmation process, causing changes to the task graph structure or node parameters, a new version identifier v2 is generated. Subsequent confirmations and verifications will be based on the snapshot corresponding to v2; the snapshot corresponding to v1 will no longer be used.

[0027] By acquiring a snapshot of the task graph containing version identifiers, every structural change to the task graph during dynamic execution is recorded and identified. Subsequent confirmation node insertion and consistency verification have a clear structural benchmark, avoiding problems such as incorrect insertion positions of confirmation nodes or inconsistent verification benchmarks caused by changes in the task graph between confirmation and execution. This provides a version tracking foundation for the organic integration of confirmation nodes and the task graph, as well as for tamper-proof verification.

[0028] Step S102: Extract the risk factors of nodes that have not yet been executed, calculate the comprehensive risk score based on the risk factors, and generate a dynamic threshold based on the current context. Mark the nodes whose comprehensive risk score reaches the dynamic threshold or hits the mandatory confirmation rule as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information.

[0029] In this embodiment of the application, risk factors of nodes that have not yet been executed can be extracted, a comprehensive risk score can be calculated based on the risk factors, and a dynamic threshold can be generated based on the current context. Nodes whose comprehensive risk score reaches the dynamic threshold or hits the mandatory confirmation rule are marked as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information.

[0030] After generating the task graph, the intelligent agent does not require manual confirmation for all nodes. By performing multi-dimensional risk quantification assessments on each unexecuted node and dynamically adjusting the confirmation threshold based on the current context, high-risk nodes can be accurately identified. Specifically, the comprehensive risk score can be a single risk value calculated from multiple risk factors; the dynamic threshold can be an adaptively adjusted judgment boundary based on user role, business type, operating environment, and historical anomalies, with varying degrees of strictness in triggering confirmation for different roles and business scenarios; and the mandatory confirmation rule can be a hard condition independent of the comprehensive risk score. Once triggered, regardless of whether the comprehensive risk score reaches the dynamic threshold, the node is directly marked as a risk node.

[0031] The mandatory confirmation rule can be triggered through a preset rule engine. The rule engine is configured with a list of operation types and conditional expressions that require mandatory confirmation. During node evaluation, the mandatory rule is matched first. If a node is matched, it is marked as a risk node, no longer relying on the comparison results of the comprehensive risk score and dynamic threshold.

[0032] In some embodiments of the present invention, the risk factors include at least one of the following: scope of impact, data sensitivity level, degree of irreversibility, model uncertainty, user role risk, historical risk, external side effect level, and compliance level; wherein, model uncertainty is used to characterize the confidence level of a node, external side effect level is used to characterize the degree of impact of a node on an external system, and compliance level is used to characterize the degree of compliance of a node with regulatory policies or industry standards. Step S102, "calculating the comprehensive risk score based on the risk factors," may specifically include the following sub-steps: Each risk factor is normalized separately, and the normalized risk factors are then weighted and summed to obtain the individual summation result. When there are factor pairs among the risk factors that meet the predetermined conditions, an interaction term is added to the factor pair, and the sum of the interaction terms is calculated. The interaction term reflects the combined risk amplification effect produced when the factor pairs increase simultaneously. The summation of individual terms and the sum of interactive terms are mapped to a unified numerical range using a monotonic function to obtain the comprehensive risk score.

[0033] In this application embodiment, risk factors may include at least one of the following: scope of impact, data sensitivity level, degree of irreversibility, model uncertainty, user role risk, historical risk, external side effect level, and compliance level. The scope of impact can represent the number of objects to be operated on, the number of external systems involved, or the scope of users affected; the data sensitivity level can represent the sensitivity level of the data fields accessed or modified by the action in the organization's classification and grading standards; the degree of irreversibility can represent whether the action can be undone, withdrawn, or compensated after execution; model uncertainty can represent the agent's confidence in the node planning results. When the model does not provide confidence, it can be assessed through the consistency of multiple inference results or the completeness of parameters; user role risk can represent the potential risks brought about by the current user's permission level and scope of responsibilities; historical risk can represent the frequency and severity of anomalies or errors in the historical execution records of the current user or similar actions; the external side effect level can represent the actual impact on external systems or external users after the node execution, such as whether the recipient can read the email after it is sent, or whether the modification of the record triggers downstream business processes; the compliance level can represent the degree of compliance of the node action with regulatory policies or industry standards, such as whether it involves operations that require auditing or whether it needs to meet data residency requirements.

[0034] In practical implementation, risk factors can be extracted separately for each action node that has not yet been executed. The scope of impact can be determined by parsing the number of target objects, the limiting conditions of the operation scope, and the resource identifiers involved in the input parameters of the action node. Data sensitivity level can be determined by matching the data fields read or written by the action node with a data classification and grading strategy library, which maintains a sensitivity level label for each data field. Irreversibility can be judged by querying the tool's capability description information, which indicates whether the tool supports rollback, undoing, or has a compensation mechanism. Model uncertainty can be determined by obtaining the confidence output value of the agent model when generating the node. If the model does not provide confidence, uncertainty indicators can be generated by performing multiple inferences on the same planning task and comparing the consistency of node parameters and tool selection in each inference result. User role risk can be determined by querying the current user's role definition and permission scope, which includes permission level, accessible resource scope, and separation of duties requirements. Historical risk can be determined by querying the historical execution record database, extracting the number of abnormal executions, error rate, and risk event level of the current user or similar tools within a preset time window. The level of external side effects can be determined using external impact markers defined in the tool's metadata. For example, an email sending tool might be marked as irreversible after sending, while a notification sending tool might be marked as supporting message recall. The compliance level can be determined by matching the action type against the compliance rule base, which maintains a list of operation types requiring compliance review and their corresponding compliance level scores.

[0035] Specifically, the comprehensive risk score can be calculated by normalizing each risk factor, mapping each risk factor to a unified numerical range, and then performing a weighted summation of the factors to obtain a single-item summation result. When there are factor pairs that meet predetermined conditions, such as the simultaneous occurrence of high data sensitivity level and high impact range, or high irreversibility level and high external side effect level, an interaction term can be added to the factor pair. The interaction term is obtained by multiplying the product of the normalized values ​​of the two factors by the interaction coefficient, reflecting the combined risk amplification effect produced when the factor pair increases simultaneously. Finally, the summation result of the single items and the sum of the interaction term are mapped to a unified numerical range through a monotonic function to obtain the comprehensive risk score. In one embodiment of the present invention, firstly, for each execution node... v i Constructing risk vectors r i， r i =( r 1 ,r 2 , ..., r 8)=(I i Di V i U i R i H i E i L i ), where I i Indicates the scope of influence, D i The following factors represent the data sensitivity level, irreversibility level, model uncertainty, user role risk, historical risk, external side effect level, and compliance level: Vᵢ, Uᵢ, Rᵢ, Hᵢ, Eᵢ, and Lᵢ. Each factor is mapped to [0,1] using rule mapping or statistical normalization. When the model output is a confidence score, Uᵢ can be defined as (1 - node confidence score). When the model does not provide a calibrable confidence score, Uᵢ can be generated based on consistency across multiple inferences, parameter completeness, or tool selection ambiguity. The comprehensive risk score can be calculated using the formula... Calculations are performed, in which, w Here, Ω represents the single-factor weights, Ω represents the set of factor pairs that need to be jointly amplified, and γ represents the interaction coefficient. b For bias terms, σ This maps the results to a monotonic function in the [0,1] range. The interaction term is included because if an action simultaneously possesses highly sensitive data, a wide impact range, and irreversible outward projections, its combined risk is typically higher than the simple sum of the factors. Weights, interaction coefficients, and normalization rules are all represented by version identifiers in the subsequent evaluation parameter configurations.

[0036] Taking the task of sending emails to external domains as an example, the target of the email sending node is multiple external domain recipients. The body of the email contains internal project data, and the attachment contains sensitive fields. Once sent, the email is difficult to completely retract. After extracting risk factors, the impact scope involves multiple external domains, the data sensitivity level is high, the irreversibility level is high, and the external side effect level is high. Because both high data sensitivity and high external side effect levels occur simultaneously, an interaction is triggered, and the overall risk score is amplified, exceeding the dynamic threshold. The email sending node is then marked as a risk node. Taking the task of batch modifying customer business records as another example, the field to be modified by the batch update node is customer status. This field is marked as general business data in the data classification and grading, with a medium sensitivity level. However, after filtering, the number of records meeting the criteria is large, resulting in a wide impact scope. Furthermore, the model's interpretation of the filtering criteria is uncertain. Although the risk values ​​of individual factors do not reach extreme values, the large impact scope and model uncertainty simultaneously trigger an interaction, amplifying the overall risk score and exceeding the dynamic threshold. The batch update node is then marked as a risk node. Taking a payment application task as an example, if the payment submission node involves a large amount of funds and hits the large payment rule in the mandatory confirmation rule, the payment submission node will be directly marked as a risk node regardless of whether the comprehensive risk score reaches the dynamic threshold.

[0037] By extracting risk factors from multiple dimensions such as scope of impact, data sensitivity level, irreversibility, model uncertainty, user role risk, historical risk, external side effect level, and compliance level, and calculating a comprehensive risk score through weighted summation and interaction terms, it is possible to capture high-risk scenarios where the risk of a single factor is not high but the risk of combination is significantly amplified. This avoids omissions and misjudgments caused by relying solely on a single rule or static list, and improves the accuracy and comprehensiveness of risk identification for high-risk actions of intelligent agents.

[0038] In some embodiments of the present invention, step S102, "generating a dynamic threshold based on the current context", may specifically include the following sub-steps: Obtain the baseline threshold, which is a uniformly configured threshold starting point; The adjustment amount is determined based on the current user's role information, the adjustment amount is determined based on the current task's business type information, and the adjustment amount is determined based on the current operating environment information. The baseline threshold is adjusted based on the adjustment amount of role, business type, and environment to obtain the adjusted threshold. When the context includes historical anomaly information, obtain the verified anomaly event intensity information from the historical anomaly information within a preset time range, and reduce the adjusted threshold based on the anomaly event intensity information; The adjusted threshold is limited to a predetermined upper and lower bound range to obtain a dynamic threshold.

[0039] In this embodiment, dynamic thresholds can be generated based on the current context. The baseline threshold can be a threshold starting point uniformly configured by the organization, representing the basic risk tolerance for triggering confirmation under standard conditions. The role adjustment amount can be a correction value determined based on the current user's permission level, scope of responsibility, and job type. Higher-privilege roles do not necessarily increase the threshold; the organization can lower the threshold for high-privilege, high-impact actions based on segregation of duties requirements. The business type adjustment amount can be a correction value determined based on the business domain, business process, and business importance of the current task. The environment adjustment amount can be a correction value determined based on the network area, deployment mode, and compliance area of ​​the current operating environment. Historical anomaly information can be verified risk event records within a preset time range, and anomaly event intensity information can be a quantitative indicator calculated comprehensively based on the frequency, level, and timeliness of anomaly events. The predetermined upper and lower bounds can be the organization's preset minimum and maximum values ​​for the dynamic threshold, used to prevent the threshold from deviating from a reasonable range due to continuous adjustments.

[0040] In practical implementation, the dynamic threshold can be generated using the following formula: T i =clip(T0+Δ role +Δ business +Δ env -λ a A-λh H i T min T max ) Where T0 is the baseline threshold, representing the threshold starting point configured uniformly within the organization. Δ role The role adjustment amount represents a correction value determined based on the current user's permission level, scope of responsibilities, and job type. Higher-privilege roles do not necessarily increase the threshold; organizations can lower the threshold or enforce dual-person confirmation for high-privilege, high-impact actions based on segregation of duties requirements. Δ business Adjustment amount for business type represents the correction value determined based on the business domain, business process, and business importance of the current task. Δ env This represents the environmental adjustment value, determined based on the current operating environment's network area, deployment mode, and compliance area. A represents the recent anomaly rate or risk event intensity, calculated based on the frequency, severity, and timeliness of verified anomalies within a preset time frame. H i This represents the historical risk value, indicating the severity of any anomalies or errors that have occurred in the historical execution records for the current user or similar actions. λ a and λ h To reduce the threshold, adjustment coefficients are used to control the extent to which recent anomaly rate and historical risk reduce the threshold. T min T is the lower bound of the threshold. max This is the upper bound of the threshold, used to limit the final result of the dynamic threshold to a reasonable range. `clip` is the clipping function, indicating that the calculation result is limited to T. min and T max between.

[0041] In practice, the baseline threshold can be read from the organizational risk strategy configuration, which maintains the threshold starting point for each business type and role combination. Role adjustment amount Δ role The adjustment amount can be determined by querying the current user's role definition and permission scope, obtaining the corresponding adjustment value mapping table. This mapping table maintains adjustment coefficients corresponding to different permission levels and responsibilities. (Business type adjustment amount Δ) business The adjustment value can be determined by querying the business classification strategy to obtain the adjustment value corresponding to the business type to which the current task belongs. Environment adjustment amount Δ env The determination of the risk level can be achieved by detecting the environment identifier of the current operating environment and obtaining the adjustment values ​​corresponding to different environment zones such as production, testing, or disaster recovery environments. The recent anomaly rate A can be calculated by querying the historical execution record database for verified risk events within a preset time window, extracting the event's level, frequency, and occurrence time, and calculating the anomaly event intensity value. Historical risk value H... iThe system can extract the number of abnormal executions and error rates of the current user or similar tools within a preset time window from historical execution records. Based on the above parameters, T0+Δ is calculated. role +Δ business +Δ env -λ a A-λ h H i Then, the result is clipped to T using the clip function. min and T max Between these points, the dynamic threshold T is obtained. i .

[0042] Taking the task of an intelligent agent executing a payment application as an example, the organizational baseline threshold T0 is set to 0.5. The corresponding role adjustment amount Δ for the ordinary handler role... role A value of -0.1 indicates that the threshold for the person in charge can be slightly lowered to increase the frequency of security checks. The adjustment amount Δ for each payment transaction type corresponds to that transaction type. business A value of -0.15 indicates that stricter standards are applied to operations involving funds. The corresponding environmental adjustment amount Δ for the production and operating environment. env A value of 0 indicates no additional adjustments. There are no recent historical anomalies, A and H. i All are 0. Calculate T0+Δ role +Δ business +Δ env -λ a A-λ h H i =0.5-0.1-0.15=0.25, so 0.25 is restricted to the preset lower bound T. min =0.2 and upper bound T max The final dynamic threshold T is between 0.8 and 0.8. i The value is 0.25. For the same payment amount, the role adjustment Δ for users with the role of financial reviewer is... role The initial value is +0.1, and the calculated result after aggregation is 0.5 + 0.1 - 0.15 = 0.45, with a dynamic threshold Ti of 0.45. This means that in the organizational strategy, although the financial reviewer has higher authority and a moderately higher risk tolerance for triggering confirmation, the threshold set for the person in charge is lower, reflecting differentiated risk management under the separation of duties.

[0043] In one embodiment of the present invention, a tiered confirmation control strategy can be adopted based on different risk assessment results and judgment conditions. When the comprehensive risk score of a risk node reaches the dynamic threshold or hits a mandatory confirmation rule, a confirmation node is inserted and manual confirmation is triggered. When the comprehensive risk score reaches or exceeds the dynamic threshold but does not hit a mandatory rule, it belongs to a normal dynamic confirmation scenario, and a confirmation node is inserted according to the conventional process. When the comprehensive risk score is close to the dynamic threshold but has not yet reached it, and the value of key risk factors has significant uncertainty, a conservative review strategy is adopted, requiring supplementary information before judgment, or a confirmation node is directly inserted according to the strategy to ensure safety. When the comprehensive risk score is below the dynamic threshold and does not hit any mandatory rule, no manual confirmation is required, the risk node maintains its original task graph dependency relationship and continues to execute, and the risk assessment result is written into the tracking record for future reference. When the historical anomaly rate increases or the operating environment becomes abnormal, the dynamic threshold is lowered or the confirmation level is raised, so that risk nodes that may have been below the threshold are included in the confirmation range, or nodes that originally only required single-person confirmation are upgraded to double-person review, in order to adapt to the dynamic changes in the risk environment.

[0044] By superimposing the baseline threshold with adjustments based on user roles, business types, and operating environments, and dynamically lowering the threshold in conjunction with historical anomaly information, and finally limiting the result to preset upper and lower bounds through a pruning function, the determination boundary for triggering confirmation can adaptively change according to the actual risk environment. This avoids the problem of fixed thresholds being too lenient or too strict under different roles and business scenarios, and also avoids missed judgments caused by unchanged thresholds during periods of high historical risk. This provides an adaptive threshold basis for the accurate interception of high-risk actions in different scenarios.

[0045] In some embodiments of the present invention, the mandatory confirmation rule in step S103 includes at least one of cross-tenant write operation, batch deletion operation, payment operation with amount exceeding a predetermined threshold, operation of sending notification to external system, and sensitive data export operation.

[0046] In this embodiment, the mandatory confirmation rule can be a hard condition independent of the comprehensive risk score. Once a node hits the mandatory confirmation rule, regardless of whether the comprehensive risk score reaches the dynamic threshold, the node is directly marked as a risk node. The mandatory confirmation rule can include at least one of the following: cross-tenant write operation, batch deletion operation, payment operation with an amount exceeding a predetermined threshold, operation of sending a notification to an external system, and high-sensitivity data export operation. A cross-tenant write operation can represent writing data to the data storage space of other tenants, involving data flow across isolation boundaries; a batch deletion operation can represent deleting more than a preset upper limit of data records in a single action; a payment operation with an amount exceeding a predetermined threshold can represent a payment amount exceeding the single or cumulative amount limit set by the organization; an operation of sending a notification to an external system can represent pushing information to systems or users outside the organization's control scope; and a high-sensitivity data export operation can represent exporting or downloading data marked as high-sensitivity to the local environment in file form.

[0047] In practical implementation, cross-tenant write operations are detected by parsing the target resource identifier of the action node to determine if the tenant identifier of the target resource matches the tenant identifier of the current user. Batch deletion operations are detected by extracting the operation type and number of operation objects from the action node to determine if the operation type is deletion and if the number of operation objects exceeds a preset threshold. Payment operations exceeding a predetermined threshold are detected by extracting the amount and currency parameters of the action node and comparing them with the organization's preset amount threshold. Notifications sent to external systems are detected by querying the external impact flag in the tool's metadata to determine if the tool is marked as sending information to external entities. Highly sensitive data export operations are detected by extracting the operation type and data field identifier of the action node to determine if the operation type is export and if the data field's sensitivity level in the data classification and grading strategy reaches a high sensitivity level. During the node evaluation phase, mandatory rule matching is prioritized; any matching rule marks the node as a risk node, and subsequent comparisons based on the comprehensive risk score and dynamic thresholds are no longer relied upon.

[0048] Taking an agent executing a payment request task as an example, if the payment submission node involves an amount exceeding the organization's single-transaction limit threshold, it triggers the large-amount payment rule in the mandatory confirmation rules. Regardless of whether the comprehensive risk score reaches the dynamic threshold, the payment submission node is directly marked as a risk node. Similarly, taking an agent executing an external email sending task as an example, if the email sending node is marked by the tool's metadata as sending information to an external system, it triggers the notification rule for sending information to an external system in the mandatory confirmation rules, and the email sending node is directly marked as a risk node.

[0049] By setting mandatory confirmation rules independent of the overall risk score, operations with inherently high-risk attributes, such as cross-tenant writes, batch deletions, large payments, external transmissions, and exports of highly sensitive data, will inevitably trigger manual confirmation regardless of their current risk score. This avoids diluting the overall assessment results of high-risk operations due to lower scores of other risk factors, and provides a deterministic security barrier for critical high-risk operations.

[0050] Step S103: Determine the necessary predecessor nodes of the risk nodes from the task graph, insert confirmation nodes after the necessary predecessor nodes are completed and before the risk nodes are executed, obtain the rewritten task graph, and perform acyclic verification on the rewritten task graph.

[0051] Once a risk node is marked, the confirmation node cannot be arbitrarily inserted into any position on the task graph. Inserting it too early means the key parameters and affected objects needed to generate confirmation information haven't yet been produced by the predecessor node, preventing users from seeing complete information and making effective judgments. Inserting it too late means the risk node may have already started executing or released external side effects, rendering the confirmation meaningless. Therefore, a suitable insertion position needs to be found between the risk node and its necessary predecessor nodes.

[0052] In this embodiment, necessary predecessor nodes for risk nodes can be determined from the task graph. After the necessary predecessor nodes are completed and before the risk node is executed, a confirmation node is inserted to obtain a rewritten task graph. The rewritten task graph is then subjected to acyclicity verification. The necessary predecessor node can be a node necessary for generating confirmation information and executed before the risk node. The action parameters, target objects, and scope of influence in the confirmation information depend on the output of the necessary predecessor node. The confirmation node can be a human interaction node inserted into the task graph, used to pause the task flow and wait for human feedback before the risk node is executed. The rewritten task graph can be a new task graph obtained by inserting a confirmation node and adjusting dependencies in the original task graph, such as... Figure 2 The diagram shown is a comparison example of task graph rewriting provided in an embodiment of the present invention. Before rewriting, necessary predecessor nodes A and B both point to high-risk node V. After rewriting, predecessor nodes A and B are redirected to confirmation node H, and confirmation node H points to high-risk node V. Cycle acyclic verification can be a verification operation to check whether there are cyclic dependencies in the rewritten task graph, ensuring that the rewritten task graph is still an executable directed acyclic graph.

[0053] In some embodiments of the present invention, the necessary predecessor node is the node on which the confirmation information is generated. Step S103, "inserting the confirmation node after the necessary predecessor node is completed and before the risk node is executed, to obtain the rewritten task graph", may include the following sub-steps: Redirect the incoming edges of necessary predecessor nodes pointing to risk nodes in the task graph to the confirmation nodes; Add control edges that point from the confirmation node to the risk node; Keep the incoming edges of unnecessary predecessor nodes pointing to risk nodes in the task graph as they are, and you get the rewritten task graph. When the rewritten task graph forms a loop or causes the semantics of conditional branches to be ambiguous or unable to cover risk nodes, the operation of inserting confirmation nodes is abandoned and the process is transferred to manual handling.

[0054] In this embodiment of the invention, the insertion of a confirmation node is not simply adding a node before a risk node, but rather a refined rewriting of the edge relationships in the task graph. This ensures that the confirmation node is positioned topologically after all necessary predecessors that generate confirmation information and before the execution of risk nodes, while avoiding blocking parallel paths unrelated to confirmation. Incoming edges can be directed edges in the task graph representing dependencies between nodes, pointing from the source node to the target node, indicating that the target node can only execute after the source node completes. Redirection can modify the endpoint of an edge from the original target node to a new target node. Control edges can be a special type of dependency edge pointing from the confirmation node to the risk node, indicating that the risk node can only execute after the confirmation node receives approval feedback. Non-essential predecessor nodes can be nodes that have dependencies on risk nodes but whose output does not affect the content of the confirmation information. Manual processing can involve submitting risk nodes that cannot be automatically inserted into a confirmation node queue to a manual intervention queue, where a human decides how to handle the risk node.

[0055] In the specific implementation, we can first obtain all incoming edges of the risk node. Based on whether the source node of the incoming edge belongs to the necessary predecessor node set, the incoming edges are divided into two categories. For incoming edges whose source node belongs to a necessary predecessor node, the endpoint of the incoming edge is changed from the risk node to the confirmation node, completing the redirection operation. For incoming edges whose source node does not belong to a necessary predecessor node, the endpoint of the incoming edge remains unchanged, i.e., it still points to the risk node. The dependencies represented by these incoming edges are not controlled by the confirmation node. After completing the incoming edge redirection, a new control edge is added from the confirmation node to the risk node. The type of the control edge is marked as confirmation control type, indicating that the execution of the risk node requires the confirmation node to obtain a pass feedback as a prerequisite. Cycle aversion can be implemented by performing a topological sorting algorithm on the rewritten task graph. A depth-first traversal or breadth-first traversal is performed starting from the confirmation node, checking if there is a path starting from the confirmation node, passing through other nodes, and returning to the confirmation node. If such a path exists, it means that a cycle has been formed after inserting the confirmation node, and the automatic insertion operation is abandoned. Conditional branch semantic checks can analyze the conditional branch paths where risk nodes are located. If inserting a confirmation node causes a contradiction between the precondition judgment of the conditional branch and the location of the confirmation node, or makes it impossible to cover the risk node on a certain branch path, automatic insertion will be abandoned. After abandoning the insertion, the risk node's identifier, the reason for the insertion failure, and the current task graph snapshot will be submitted to the manual processing queue.

[0056] Taking the task of sending emails as an example, the email sending node is marked as a risk node, while the text generation node, attachment generation node, and contact extraction node are identified as necessary predecessor nodes. There is also a log recording node in the task graph, which depends on the email sending node, but its output is not used to generate confirmation information, making it a non-essential predecessor node. When inserting the confirmation node, the incoming edges from the text generation node to the email sending node, the attachment generation node to the email sending node, and the contact extraction node to the email sending node are redirected to the confirmation node. The incoming edge from the log recording node to the email sending node remains unchanged. A new control edge is added from the confirmation node to the email sending node. A topological sort is performed on the rewritten task graph to check for cycles. The sort traverses all nodes without detecting any back edges, so the check passes, and the rewritten task graph can be used for subsequent execution. Taking the task of batch modifying customer business records as an example, if the filter node is determined to be a necessary predecessor node, while the audit record node is a non-necessary predecessor node, the incoming edge from the audit record node to the batch update node remains unchanged, the incoming edge from the filter node to the batch update node is redirected to the confirmation node, and a new control edge from the confirmation node to the batch update node is added. After the acyclic verification passes, the rewritten task graph is obtained.

[0057] By redirecting the incoming edges of necessary predecessor nodes to acknowledgment nodes and adding control edges from acknowledgment nodes to risk nodes, acknowledgment nodes become mandatory predecessors of risk nodes in the task graph. Any dependency path requiring acknowledgment control must receive acknowledgment feedback before proceeding. Simultaneously, the incoming edges of unnecessary predecessor nodes are left unchanged, preventing unnecessary blocking of parallel paths unrelated to acknowledgment and ensuring the execution efficiency of the task graph. When loops or semantic anomalies are detected, automatic insertion is abandoned and manual handling is initiated, avoiding execution errors caused by invalid task graph structures due to automatic insertion operations.

[0058] In some embodiments of the present invention, the "insert confirmation node" step S103 may further include the following sub-steps: When a risk node is located on a conditional branch path, the confirmation node is inserted on the actual branch of the conditional branch path leading to the risk node. When there are multiple risk nodes that belong to the same atomic transaction group, and the confirmation information can list all actions, parameters and total impact of the multiple risk nodes, a single confirmation node controls the multiple risk nodes. When the task graph contains a cyclic structure, an acknowledgment node is inserted in the subgraph corresponding to the current iteration, and the iteration identifier of the current iteration is recorded for use in generating a binding summary.

[0059] In this context, a conditional branch path refers to a structure in the task graph that selects different branch nodes for execution based on different condition judgments; only nodes on branch paths that meet the conditions will be actually executed. An atomic transaction group refers to multiple risk nodes that logically form an indivisible whole; if any node fails, the entire group needs to be rolled back or compensated. A single confirmation node refers to a confirmation node that simultaneously acts as the preceding control node for multiple risk nodes; after receiving approval feedback, the multiple risk nodes it controls can be released for execution sequentially or in parallel. A loop structure is a structure in the task graph that repeatedly executes a subgraph; the iteration identifier is a unique identifier used to distinguish different rounds of execution within the loop, such as an iteration number or iteration timestamp.

[0060] In the specific implementation, the insertion of confirmation nodes on conditional branch paths can be achieved by parsing the branch structure of the risk nodes in the task graph. Starting from the risk node, trace upwards along the dependency edges to find the conditional branch node closest to the risk node. The confirmation node is inserted after this conditional branch node and before the risk node, and only on the actual branch path where the risk node is located; confirmation nodes are not inserted on unselected branch paths. The identification of atomic transaction groups can be determined by querying the transaction attribute markers of nodes in the task graph, which contain the transaction group identifier to which the node belongs. When multiple risk nodes have the same transaction group identifier, they are determined to belong to the same atomic transaction group. During the confirmation information generation phase, all action types, parameter information, and impact scopes from multiple risk nodes are aggregated and integrated into a single confirmation message. The optional actions in the confirmation message indicate that the confirmation applies to multiple risk nodes simultaneously. After receiving approval feedback, a single confirmation node releases all risk nodes under its control sequentially or in parallel. The insertion of confirmation nodes in a loop structure can be performed after the subgraph of the current iteration is expanded. Before the loop body begins execution, the task graph execution engine assigns a unique iteration identifier to each iteration. Confirmation nodes are inserted into the expanded subgraph at the positions where necessary predecessors have been completed, and the iteration identifier is simultaneously written into the attribute fields of the confirmation node. When generating the binding summary, the iteration identifier is included as part of the binding content, ensuring that confirmation nodes and binding summaries from different iterations are not interchangeable. For tool nodes added at runtime, node type detection can be triggered when they are added to the task graph. If the node is detected as a runtime addition and not present in the original task graph snapshot, risk factor extraction, comprehensive risk score calculation, and dynamic threshold generation are re-executed for that node. When determined to be a risk node, a new confirmation node is inserted according to the rule of necessary predecessors being completed, preventing the model from adding high-risk actions outside of the confirmed plan and bypassing confirmation control.

[0061] Taking a conditional branch task as an example, the task graph contains a conditional fork node. Based on the approval result, it determines whether to execute the formal send branch or the draft save branch. The send email node on the formal send branch is marked as a risk node, while the save node on the draft save branch is not marked. The confirmation node is inserted only on the formal send branch, after the conditional fork node and before the send email node. The draft save branch is unaffected by the confirmation node and can be executed directly. Taking a payment application task as an example, the payment submission node and payment archiving node belong to the same atomic transaction group. Both nodes are marked as risk nodes, and the confirmation information can simultaneously display all actions, amount parameters, and total impact scope of payment submission and payment archiving. Inserting a single confirmation node controls the payment submission node and payment archiving node. The user sees both actions simultaneously in the confirmation information and makes a confirmation decision. After confirmation, both nodes are released and executed sequentially. Taking a task that regularly generates weekly reports as an example, the task graph contains a loop structure, iteratively executing the data summary node and report sending node once a week. In each iteration, the report sending node is marked as a risk node. A confirmation node is inserted into the current iteration subgraph, and the iteration identifier is recorded as week 12. Confirmation passed in week 12 cannot be automatically used for report sending confirmation in week 13. In one embodiment of the invention, during the confirmation waiting period, it is assumed that the agent model dynamically adds a data export node based on intermediate results. This node does not exist in the original task graph snapshot. If the data export node is detected as a runtime-added tool node, risk factors are re-extracted for this node. If the node involves highly sensitive data export and the comprehensive risk score reaches a dynamic threshold, a new confirmation node is inserted before the data export node is executed, generating new confirmation information to ensure that newly added high-risk actions do not bypass confirmation control.

[0062] By inserting confirmation nodes only on branches that actually lead to risk nodes on conditional branch paths, and refraining from triggering confirmations on branches not selected, unnecessary waiting and interruptions on irrelevant paths are avoided. By controlling multiple risk nodes within the same atomic transaction group with a single confirmation node, users can understand all relevant actions and make unified decisions in a single confirmation, reducing the burden of repeated confirmations while ensuring the atomicity of transaction operations is not interrupted by the confirmation process. By inserting confirmation nodes into the current iteration subgraph of the loop structure and binding iteration identifiers, the confirmation of each iteration is independently valid, avoiding the risk of previous confirmations being incorrectly reused in subsequent iterations, and ensuring the continuous effectiveness of risk control in loop scenarios.

[0063] Step S104: Generate confirmation information based on the information of the risk node, and generate a binding digest. The binding digest is used to prevent the risk node from being tampered with after confirmation.

[0064] In this embodiment, confirmation information and a binding digest can be generated based on the risk node's information. The binding digest is used to prevent the risk node from being tampered with after confirmation. After the risk node is marked and inserted into the confirmation node, the confirmation node needs to present sufficient information to the user to support their effective confirmation decision. Simultaneously, an anti-tampering mechanism needs to be established to ensure that the node context at the time of user confirmation is completely consistent with the node context at the time of final execution. The confirmation information can be interactive content displayed to the user, containing key parameters, scope of impact, and potential consequences of the risk node's intended action. The binding digest is a non-misused verification value used to verify whether the risk node has been changed after confirmation before execution.

[0065] In some embodiments of the present invention, step S104 may specifically include the following sub-steps: Obtain action information, parameter information, target object information, and tool information invoked at risk nodes; Based on action information and target object information, determine the scope of impact and consequences of risk nodes; Based on the calculation results of the risk factors, obtain the risk trigger information of the risk nodes; Obtain information on the rollback capability of risk nodes; The action information, parameter information, target object information, tool information, scope and consequences information, risk triggering information, and rollback capability information are combined to generate confirmation information; Obtain the risk node identifier and the output summary of the necessary predecessor node, and standardize the parameter information to obtain standardized parameters; where the risk node identifier is used to uniquely identify the risk node in the task graph, and the output summary is the output content of the necessary predecessor node. The scope of permissions for providers who receive feedback information, and the version identifier of the evaluation parameters on which the dynamic threshold is based; Bind the task graph version identifier, risk node identifier, standardized parameters, output summary of necessary predecessor nodes, permission scope, and version identifier of evaluation parameter configuration to generate a binding summary.

[0066] In practical implementation, confirmation information is generated by extracting relevant fields from the risk node's node definition and the output of the predecessor node. This involves first obtaining the risk node's action name and business purpose, the name of the tool invoked and the external system identifier, the target object and quantity, key parameters and their data sources, a summary of the sensitive fields accessed or modified, the scope of impact and irreversible consequences, the scope of rollback or compensation, and the main risk factors triggering this confirmation. This information is then assembled into confirmation information according to a preset card template. The confirmation information also provides optional actions for the user to choose from, such as confirmation approved, execution rejected, parameter modification, and supplementary information.

[0067] The risk node's actions can be described in several ways. Action information includes the type of operation and its business purpose, such as sending an email, modifying a record, submitting a payment, or exporting data. Parameter information includes key input parameters required for the risk node's execution, such as the recipient list, modified field names and new values, payment amounts and currencies, or filtering conditions for exported data. Target information includes the identifier and quantity of the target resource the risk node intends to operate on, such as recipient email addresses, database table names and record counts, payee accounts, or exported data file names. Tool information includes the name, type, and system identifier of the external tools invoked by the risk node, such as email sending services, customer management system update interfaces, financial system payment interfaces, or data export components. Scope of impact includes the potential impact on objects, systems, or users after the risk node's execution. Consequence information describes the irreversible consequences, external side effects, or legal consequences resulting from the risk node's execution. Risk trigger information includes the top-ranking risk factors extracted from the risk factor calculation results that triggered the node to be marked as a risk node, along with their values, such as broad impact, high data sensitivity, or high irreversibility. Rollback capability information can describe whether a risk node supports rollback, reversal, or compensation operations after execution. For example, whether emails can be recalled after sending, records can be restored after modification, or payments can be reversed after submission. A risk node identifier can be a unique identifier assigned to each node in the task graph, used to accurately locate risk nodes within the node set of the task graph. The output digest can be a summary value of the output content after the necessary predecessor nodes have been executed, calculated using a hash algorithm on the output results of the necessary predecessor nodes. Standardized parameters can be parameter representations obtained after standardizing and normalizing parameter information, used to eliminate the impact of differences in parameters across different systems or formats on the binding digest comparison. The permission scope can be a description of the operational permissions and accessible resource boundaries of the feedback information provider in the current session. The version identifier of the evaluation parameter configuration can be the version number of the parameter configurations such as weight coefficients, interaction coefficients, and normalization rules used when generating dynamic thresholds.

[0068] In practical implementation, action information, parameter information, target object information, and tool information can be directly read from the node definition of the risk node. Action information corresponds to the node's operation type field and business purpose description field; parameter information corresponds to the node's input parameter list; target object information corresponds to the node's target resource identifier field and operation object quantity field; and tool information corresponds to the tool name, tool type, and external system identifier bound to the node. The determination of the scope of impact and consequences information can be achieved by parsing the object quantity and type in the target object information, combined with the external impact markers and irreversible markers in the tool information. Risk trigger information can be extracted from the risk vector output by the risk assessment module. Risk factors are sorted in descending order of score, and the top-ranked risk factors and their scores are taken as risk trigger information. Rollback capability information can be determined by querying the rollback support marker, withdrawal support marker, or compensation mechanism description in the tool capability description information. The generation of confirmation information involves assembling the above information according to a preset card template, which defines the display position and format of each piece of information. For parameter values ​​of sensitive fields, the confirmation information is anonymized according to the permission level of the feedback provider. For example, the middle four digits of a mobile phone number are masked, the currency is retained but the specific value is hidden, and only the first and last characters of an ID number are displayed. Risk node identifiers can be obtained from the node identifier allocation record in the task graph. The output digest of necessary predecessor nodes can be obtained by serializing the output results of each necessary predecessor node and calculating its hash value. Standardization processing can include unifying the type, standardizing the format, and converting units for parameter information. For example, unifying the date format to a timestamp, unifying the amount unit to the smallest unit of the base currency, and standardizing the encoding of string parameters. The permission scope can be obtained from the permission management module of the current session. The version identifier of the evaluation parameter configuration can be read from the currently effective configuration version number in the risk policy configuration management module. The binding digest is generated by concatenating the task graph version identifier, risk node identifier, standardized parameters, output digest of necessary predecessor nodes, permission scope, and version identifier of the evaluation parameter configuration in a preset order to form a string to be digested, and then using a hash algorithm to calculate the binding digest value from this string.

[0069] Taking the execution of a payment application task by an intelligent agent as an example, the payment submission node is marked as a risk node. The obtained action information is payment application submission, and the parameter information includes the payment amount of one million yuan, the payee's account and currency, the target object information is the payee's account, and the tool information is the payment interface of the financial system. The scope of impact involves the transfer of funds to a corporate account, and the consequence information is that the payment is irreversible after submission. The risk trigger information is that the amount exceeds a predetermined threshold and the degree of irreversibility is high. The rollback capability information is that rollback is not supported, and only manual reversal afterward is supported. After generating confirmation information, the user can see the payee's name, payment amount, irreversible prompt, and optional actions on the confirmation card. In the binding summary generation stage, the task graph version identifier v1, the node identifier of the payment submission node, the standardized amount parameters, the output summaries of the two necessary predecessor nodes of material reading and amount calculation, the permission scope of the financial reviewer, and the version identifier of the evaluation parameter configuration are obtained. After concatenation, a hash calculation is performed to obtain the binding summary value, which is used to verify whether the risk node has been changed after confirmation before subsequent execution.

[0070] By combining action information, parameter information, target object information, tool information, scope and consequences information, risk triggering information, and rollback capability information to generate confirmation information, users can fully understand the specific content of the action to be executed, its potential consequences, and the risk reasons that trigger confirmation, providing sufficient information for making accurate confirmation decisions. By binding the task graph version identifier, risk node identifier, standardized parameters, output summaries of necessary predecessor nodes, permission scope, and version identifiers of evaluation parameter configurations to generate a binding summary, the node context at the time of confirmation is locked as a non-misused verification credential. Before execution, comparing the binding summary with the current actual information effectively prevents parameters from being tampered with after confirmation or the use of invalid confirmations after context changes.

[0071] Step S105: Obtain feedback information regarding the confirmation information, and change the status of the confirmation node according to the type of feedback information.

[0072] In this embodiment, after the confirmation information is generated and displayed to the user, the task graph execution flow pauses at the confirmation node, waiting for the user to respond to the confirmation information. Therefore, feedback information regarding the confirmation information can be obtained, and the state of the confirmation node can be changed according to the type of feedback information. User feedback is not a simple binary choice but can contain multiple types of decision intentions. Different types of feedback will trigger different subsequent processing paths. Therefore, it is necessary to change the state of the confirmation node accordingly based on the type of feedback information to drive subsequent branch logic such as verification, execution, re-evaluation, or termination.

[0073] In some embodiments of the present invention, the types of feedback information include confirmation passed, parameter modification, execution rejected, and timeout. Step S105, "changing the state of the confirmation node according to the type of feedback information," specifically includes the following sub-steps: When the feedback message is "confirmed," the status of the confirmation node will be changed to "confirmed." When the feedback information indicates that the parameter has been modified, the status of the confirmation node is changed to modified. The risk node is updated according to the modified parameter, and the risk is reassessed. If the risk is lower than the dynamic threshold after reassessment, the risk node is released. If the risk still reaches the dynamic threshold, a new version of the confirmation information is generated. When the feedback message is "rejected", the status of the confirmation node is changed to "rejected", the risk node is blocked, and the rejection reason is converted into a replanning constraint. Based on the replanning constraint, a local replanning is performed on the set of affected nodes in the task graph to generate a local alternative plan. If a local alternative plan cannot be generated, the task is terminated. If the local alternative plan contains high-risk nodes, a new version of the confirmation message is generated. The set of affected nodes includes the rejected risk node, the successor nodes that depend on the output of the rejected risk node, and the nodes that share the same atomic transaction group with the rejected risk node. When the feedback message is "timeout", the status of the confirmation node will be changed to "timeout", and the operation will be stopped, upgraded to approval, transferred to manual processing, or the confirmation operation will be re-initiated.

[0074] In this embodiment, the feedback information types include confirmation, parameter modification, refusal to execute, and timeout. Confirmation indicates that the user acknowledges the action content, parameters, and risks displayed in the confirmation information and agrees to continue executing the risk node. Parameter modification indicates that the user has modified some parameters in the confirmation information, requiring a reassessment of the risks based on the modified parameters. Refusal to execute indicates that the user disagrees with executing the risk node, requiring blocking the node and finding an alternative. Timeout indicates that no user feedback has been received within the preset validity period, requiring processing according to the preset strategy.

[0075] The confirmation states are as follows: "Confirmed" indicates the node enters this state after the user agrees to execution, allowing the risk node to proceed to the subsequent verification stage. "Modified" indicates the node enters this state after the user modifies the parameters, meaning the user has adjusted some parameters of the risk node and requests a reassessment of the risk based on the new parameters. "Rejected" indicates the node enters this state after the user explicitly disagrees with execution, meaning the risk node is prohibited from execution and an alternative solution needs to be found. "Timeout" indicates the node enters this state after receiving no user feedback within a preset validity period, meaning the confirmation process terminates due to lack of response. Replanning constraints are structured restrictions extracted from the user's rejection reasons, used to guide the generation of alternative solutions that meet the user's intent during partial replanning, such as prohibiting sending to external domains, generating only drafts, and limiting the number of drafts to a specified limit. The affected node set includes the rejected risk node, successor nodes that depend on the output of the rejected risk node, and nodes that share the same atomic transaction group as the rejected risk node. The local alternative plan is an alternative task graph substructure obtained by replanning only the affected node set and its necessary adjacent edges, while retaining the completed results that do not depend on the affected node set.

[0076] In the implementation, when the feedback information is confirmed, the status field of the confirmation node is updated to "confirmed," and the confirmation node no longer blocks the subsequent process of the risk node. The risk node then enters the pre-execution consistency verification stage. Before the feedback information enters the processing flow, validity verification can also be performed on the feedback information, including verifying the operator's identity and confirmation permissions, verifying whether the confirmation information identifier and binding digest associated with the feedback information match, and verifying whether the confirmation information is within its validity period. For scenarios with a dual-person review strategy, it can also verify whether multiple operators meet the role isolation requirements, ensuring that the reviewing operator and the initiating operator do not belong to the same role or the same permission group. Feedback submitted by operators without permissions, feedback with expired confirmation information, feedback with a binding digest inconsistent with the current actual digest, or feedback for an expired old version of confirmation information are all unacceptable. The status of the confirmation node remains unchanged, and the risk node is not released.

[0077] When the feedback message indicates parameter modification, the status field of the confirmation node is updated to "Modified." The modified field names and values ​​are extracted from the feedback message and written back to the parameter definition of the risk node. The currently bound summary is marked as invalid. Risk factors are re-extracted and the comprehensive risk score is calculated for the updated risk node. If the recalculated comprehensive risk score is lower than the current dynamic threshold, the risk node is removed from the flag and released into the execution process. If the dynamic threshold is still reached, a new version of the confirmation message is generated based on the new parameters, and the confirmation process is re-initiated.

[0078] When the feedback message is "rejected," the status field of the confirmation node is updated to "rejected," the execution path of the risk node is set to "blocked," and the replanning constraints are parsed from the rejection reason provided by the user. For example, the negative intent and limiting conditions in the natural language rejection reason are parsed and converted into structured constraints. When determining the set of affected nodes, the task graph can be traversed downstream along the dependency edges, starting from the rejected risk node. All successor nodes that directly or indirectly depend on the output of the risk node are included in the set. Simultaneously, other nodes in the task graph with the same transaction group identifier as the risk node are also included. During the local replanning phase, completed results that do not depend on any node in the affected node set are retained. Using the affected node set and replanning constraints as input, the affected subgraph is replanned to generate a local alternative plan. If the agent model cannot generate a feasible alternative under the replanning constraints, the entire task is terminated, and the termination reason is reported to the user. If the local alternative plan contains new high-risk nodes, a new version of the confirmation message is generated, and the confirmation process is restarted.

[0079] When the feedback message is "timeout," the status field of the confirmation node is updated to "timeout," and the timeout handling policy corresponding to the risk node is queried. If the policy is configured to stop, the task is terminated; if the policy is configured to re-initiate confirmation, a new version of the confirmation information is generated and the validity period is reset. For nodes whose risk level is below the preset upgrade threshold but still require confirmation, the confirmation node is kept in the timeout state and continues to wait for user response. For irreversible operations or high compliance risk nodes, the confirmation information and timeout record are forwarded to the preset designated approver queue for upgrade approval. For urgent but downgradeable tasks, the original high-risk action can be replaced with a less risky alternative such as read-only query, draft generation, or simulated execution. Any downgrade scheme is generated as a new plan version, and risk factors are re-extracted and comprehensive risk scores are calculated for the nodes in the new plan version. Timeout cannot be regarded as default consent and the original risk node cannot be released directly.

[0080] If a critical change occurs in the task execution context after the confirmation message is displayed but before user feedback is received—for example, the output of an upstream node is updated, the task graph snapshot version changes, the permission scope is adjusted, or the risk policy configuration version changes—the context upon which the binding summary of the current confirmation message is based becomes invalid. In this case, the status of the confirmation node can be updated to invalid, rendering the current confirmation message obsolete. A new version of the confirmation message can then be generated based on the latest context, and the confirmation process can be re-initiated to avoid using an invalid confirmation after the context has changed.

[0081] like Figure 3The diagram illustrates the status change of the confirmation node provided in this embodiment of the invention. Starting from the node awaiting confirmation where confirmation information and a bound digest are generated, the process is divided into five parallel processing branches: First, the user-modified parameter branch re-evaluates the node. If the re-evaluation is deemed low-risk, it moves to the release node and then to the end node. Re-evaluation still requires confirmation and returns to the awaiting confirmation node. Second, the authorized user confirmation branch: if the digest matches the previous branch, the node is released and the process ends; if it differs from the previous digest, it moves to an invalid node, generates a new version branch, and moves to the re-evaluation node. Third, the plan / parameter / dependency / policy change branch (i.e., context change): the confirmation node is first invalidated, then a new version is generated and moved to the re-evaluation node. If the re-evaluation is deemed low-risk, it moves to the release node and ends. Re-evaluation still requires confirmation and returns to the awaiting confirmation node. Fourth, the expired branch: if the policy requires an upgrade, an upgrade is performed and the process ends; if the policy requires a stop, the process ends via the termination node. Fifth, the user rejection branch: after user rejection, a partial alternative plan branch is generated. If no acceptable alternative is found, the process ends via the termination node; if the alternative plan still contains high-risk nodes, the process returns to the awaiting confirmation node.

[0082] Taking a payment application task executed by an intelligent agent as an example, when the user clicks the "Confirm Approval" button on the confirmation card, the confirmation node status changes to "Confirmed," and the payment submission node enters the pre-execution consistency check. If the user modifies the payment amount to a lower value on the confirmation card and submits it, the feedback type is "Parameter Modification," the confirmation node status changes to "Modified," the modified amount parameter is written back to the payment submission node, and the risk is reassessed. If the modified amount is lower than the large payment threshold and the overall risk score is lower than the dynamic threshold, the payment submission node is directly released to proceed with execution.

[0083] Taking the execution of a payment application task by an intelligent agent as an example, User A, as the handler, clicks the "Confirm" button on the confirmation card. After verifying User A's identity and confirmation permissions, due to the large payment amount and the organization's dual-review strategy, a second operator is required to review the application. User B, as the financial reviewer, reviews and confirms the application. It is verified that User B's role and User A's role meet the role isolation requirements and that they do not belong to the same permission group. After the verification passes, the confirmation node status changes to "Confirmed," and the payment submission node enters the pre-execution consistency check. If, after User A's confirmation but before User B's review, the invoice parsing result is corrected, causing a change in the payment amount, the task graph version identifier is updated, the context of the confirmation information changes, the current confirmation node status changes to "Invalid," the original confirmation information is invalidated, a new version of the confirmation information is generated based on the latest amount parameters, and the dual-review process is re-initiated.

[0084] Taking a batch modification task of customer business records as an example, the user sees a large number of records to be modified on the confirmation card, clicks the "Reject Execution" button, and fills in the reason for rejection: "Too many records, only modifications are allowed for a specific organization." The confirmation node status changes to "Rejected," and the batch update node is blocked. The replanning constraint extracted from the rejection reason is to limit the operation scope to this specific organization. The set of affected nodes is determined to include the batch update node and subsequent notification nodes that depend on its output. Under the replanning constraint, the agent model generates a local alternative plan, replacing the original full batch update with a batch update specific to this organization. If the risk of the limited-scope update nodes in this local alternative plan is lower than the dynamic threshold after reassessment, execution is released without reconfirmation. If the local alternative plan still contains high-risk nodes that require confirmation, a new version of the confirmation information is generated and confirmation is re-initiated.

[0085] Taking a timeout scenario as an example, the confirmation information for a payment application task has a validity period. If no feedback is received from the financial reviewer within the specified time, the confirmation node status changes to timeout. Since payment submission is an irreversible and high-compliance-risk operation, according to the organization's timeout handling strategy, timeout is not considered as default consent. In one embodiment of the invention, a stop operation can be performed to terminate the subsequent execution of the payment submission task and send a timeout termination notification to the user, indicating that the task has been stopped due to unconfirmed timeout. In another embodiment of the invention, the confirmation information and timeout record can also be transferred to the financial manual queue for processing. Taking a data export task as an example, if the task is marked as urgent but degradeable when a timeout occurs, the original data export node can be replaced with a node that generates a read-only data preview, a new plan version can be generated, and the risk of the nodes in the new version can be reassessed. If the risk of the read-only preview node is below the threshold, execution can be released, which ensures the continuous progress of the task while avoiding the automatic release of high-risk data exports. Taking a task involving the export of sensitive data as an example, the data export node is marked as a risk node, and the validity period of the confirmation information is set to thirty minutes. Upon timeout, according to the organization's timeout handling policy, exporting sensitive data is an operation requiring higher-level approval. The confirmation node status changes to timeout, triggering an escalation approval process. The confirmation information and timeout record are forwarded to a pre-defined data security administrator queue for further approval. Taking a weekly report generation task as an example, the report sending node is marked as a risk node, and the confirmation information validity period is set to one hour. After timeout, report sending is a routine operation and can be re-initiated. According to the organization's timeout handling policy, the confirmation node status changes to timeout, a new version of the confirmation information is generated, the validity period is reset, and a new confirmation is sent to the user, awaiting feedback from the user within the new validity period.

[0086] By mapping four feedback types—acceptance, parameter modification, rejection, and timeout—to four confirmation node states—accepted, modified, rejected, and timeout—and triggering different subsequent processing branches based on these states (such as verification release, reassessment, partial replanning, or halting upgrades), manual feedback can precisely drive the execution path branching of the task graph, achieving deep coupling between confirmation decisions and task graph control logic. Transforming rejection reasons into structured replanning constraints and limiting the set of affected nodes allows partial replanning to generate alternative solutions that meet user intent without repeatedly executing irrelevant completed nodes, balancing strict risk control with efficient task execution.

[0087] Step S106: In the rewritten task graph, based on the status of the confirmed node after the change, and using the task graph snapshot as a benchmark, perform a consistency check between the binding summary and the current actual information of the risk node.

[0088] There may be a time window between the user's confirmation decision and the actual execution of the risk node. During this period, the upstream output of the task graph may be updated, node parameters may be modified, permission scope may change, or the evaluation parameter configuration version may be switched. If execution is performed directly without verification, the context at the time of user confirmation may be different from the context at the time of execution. Therefore, before the risk node is actually executed, it is necessary to verify again, using the task graph snapshot as a structural benchmark, whether the current actual information is completely consistent with the information bound at the time of confirmation.

[0089] In this embodiment of the application, the binding summary and the current actual information of the risk node can be checked for consistency based on the status of the confirmed node after the change in the rewritten task graph, using the task graph snapshot as a benchmark.

[0090] The specific method for verifying based on the task graph snapshot can be to obtain the task graph structure version at the time of the confirmation node insertion from the task graph snapshot, and verify whether the actual version identifier of the current task graph is consistent with the version identifier in the snapshot. If the task graph version has changed, it means that there is a difference between the task graph structure at the time of the confirmation node insertion and the current actual task graph structure. Even if each parameter is consistent when compared individually, it should be considered that the context has changed, and the verification will fail.

[0091] In some embodiments of the present invention, step S106, "performing a consistency check between the binding digest and the current actual information of the risk node," may specifically include the following sub-steps: Obtain the current actual information of the risk node, which includes the current actual standardized parameters, the actual output summary of the current necessary predecessor node, the current permission scope, and the current actual version identifier of the evaluation parameter configuration; Compare the bound summary with the current actual information; When the binding summary matches the current actual information, the verification passes and the risk node is released. When the binding summary is inconsistent with the current actual information, the verification fails, causing the confirmation node to become invalid and generating a new version of the confirmation information to re-initiate the confirmation.

[0092] In this embodiment, after the confirmation node's status changes to "confirmed," the risk node does not execute immediately. Instead, it undergoes a consistency verification step to ensure that the risk node's context remains unchanged from user confirmation to actual execution. The current actual information is extracted in real-time from the current execution snapshot of the task graph, using the same information source as when generating the binding summary, but at a different time. The current actual standardized parameters are the parameter representation obtained by standardizing the risk node's input parameters at execution time in the same way as when generating the binding summary. This standardization process eliminates the impact of parameter format differences on the results. The current necessary predecessor node's actual output summary is the hash value recalculated from the latest output of the risk node's necessary predecessor node. The current permission scope is the operator permission boundary re-queried from the session during verification. The current actual version identifier of the evaluation parameter configuration is the version number of the currently effective risk policy configuration.

[0093] In the specific implementation, the current standardized parameters can be obtained by performing type conversion, format unification, and unit conversion on each parameter in the risk node input parameter list according to preset standardization rules, and then serializing the standardized parameter values. The current necessary predecessor node's actual output summary can be obtained by traversing the list of necessary predecessor nodes of the risk node, reading the output data of these nodes in the current task graph execution context, serializing each output data, calculating its hash value, concatenating all hash values, and calculating the hash value again to obtain the comprehensive output summary. The current permission scope can be obtained by querying the resource access scope of the current operator in real time. The current actual version identifier of the evaluation parameter configuration can be read from the configuration management component to obtain the currently effective risk policy configuration version. The comparison between the binding summary and the current actual information can be done item by item, comparing the six binding items—task graph version identifier, risk node identifier, standardized parameters, output summary of necessary predecessor nodes, permission scope, and evaluation parameter configuration version identifier—with their corresponding current actual values ​​one by one. If all match, it is considered consistent; otherwise, it is considered inconsistent. When a match is found, the control status of the confirmed node is set to allow, and the risk node enters the execution queue. When a discrepancy occurs, the status of the acknowledgment node changes from acknowledged to invalidated, and the current acknowledgment information is discarded. Then, based on the latest context, the acknowledgment information is regenerated, the binding digest is recalculated, and the acknowledgment process is re-initiated to ensure that subsequent acknowledgment decisions are based on the latest information.

[0094] Taking the task of sending an outbound email by an intelligent agent as an example, after the user clicks "Confirm" on the confirmation card, the confirmation node changes to "Confirmed". Before executing the email sending node, a consistency check is performed. The current actual information of the email sending node is obtained: the recipient list, subject, body, and attachment parameters are standardized to obtain the current standardized parameters; the output content of the body generation node and attachment generation node is reread and hashed to obtain the actual output summary of the necessary predecessor node; the current operator's permission scope is queried; and the version number of the currently effective risk policy configuration is read. The binding summary is compared with this current actual information. If the body generation module updates the body content due to automatic rewriting in the background after user confirmation, the actual output summary is inconsistent with the output summary of the necessary predecessor node in the binding summary, the check fails, the confirmation node becomes invalid, and the email sending node is not executed. Subsequently, a new version of the confirmation information is generated based on the new body content and displayed to the user again, awaiting confirmation. If all items are consistent, the email sending node is released, and the email is sent normally.

[0095] Taking a payment application task as an example, the user confirms the payment on the confirmation card, but the invoice amount is corrected before the payment is executed. This causes the amount in the current actual standardized parameters to be inconsistent with the standardized parameters in the binding summary, resulting in a failed verification, invalidation of the confirmation node, and failure of the payment submission node. The system then regenerates confirmation information containing the new amount and re-initiates the confirmation process.

[0096] By acquiring the current standardized parameters, actual dependency output digests, current permission scope, and current evaluation parameter configuration version before executing a risk node, and rigorously comparing them with the binding digest, it is ensured that the critical context remains unchanged and unaltered throughout the entire process from confirmation to execution. The risk node is released only after successful verification, guaranteeing the validity and authority of the confirmation decision. If verification fails, the confirmation node is invalidated and automatically re-initiated for confirmation. This not only eliminates the risk of abuse of invalid confirmations but also adapts to context changes, promptly presenting the latest situation to the user, achieving a balance between security and efficiency.

[0097] Step S107: When the verification passes, control the execution of the risk node.

[0098] In this embodiment, successful verification means that the binding digest and the current actual information are completely consistent across six dimensions: task graph version identifier, node identifier, standardized parameters, necessary predecessor node output digest, permission scope, and evaluation parameter configuration version identifier. The context at the time of confirmation completely matches the context at the time of execution, and the user's confirmation decision remains valid. At this point, the risk node meets the conditions for safe release and execution. Controlling the execution of the risk node can involve releasing it from its blocked state awaiting confirmation, allowing it to call the tool or application interface bound to the node according to normal scheduling logic to complete the corresponding actual operation.

[0099] In the specific implementation, releasing a risk node after successful verification can be achieved by modifying the control state of the confirmation node. Confirmation nodes are initialized to a blocked state upon generation and are set to a released state after user confirmation and consistency verification. When scheduling the execution of a risk node, it checks whether there is a control edge from the confirmation node in the incoming edges of each node. If so, and the corresponding confirmation node is in a released state, the confirmation control conditions for that risk node are considered met, and the risk node is added to the executable node queue. Subsequently, the tool interface bound to the risk node is called, passing in the verified standardized parameters and the output data of the necessary predecessor nodes, to execute the actual operation corresponding to that node. After execution, the execution result, execution time, tool return status, and intermediate data during execution are recorded, and this information is written to the execution trace log.

[0100] During the execution of risk nodes, if the tool call returns an exception or the execution result is inconsistent with expectations, this exception information will be recorded as a historical risk event and included in the reference for subsequent risk strategy statistics and dynamic threshold adjustments. The execution tracking record stores at least the risk node identifier, risk assessment identifier, confirmation node identifier, binding summary, operator identifier, feedback type, actual execution summary, and associated information of the tool return result, forming a complete link from risk assessment to confirmation decision and then to actual execution.

[0101] Taking the task of sending emails to an intelligent agent as an example, after the consistency check passes, the email sending node is released from the blocked state. The email sending tool's interface is called, passing in parameters such as the recipient list, email subject, body content, and attachments. The email sending tool then pushes the email to the external mail server. After execution, the email sending tool returns the sending result and email identifier. This information, along with the email sending node's identifier, risk assessment record, and confirmation decision record, is written into the execution trace. If the mail server returns an exception indicating a sending failure during the email sending process, this exception is recorded as a historical risk event for reference in risk assessments of similar email sending nodes in the future. Taking the payment application task as an example, after the payment submission node passes verification, it is released. The payment interface of the financial system is called, passing in parameters such as the payee, amount, and contract number to complete the payment submission. After execution, the financial system returns a payment transaction number, which is associated with the confirmation record and verification record, making the decision-making information and actual execution information of the entire payment operation completely traceable.

[0102] By controlling the execution of risk nodes only after verification, it ensures that only actions that have undergone complete risk identification, manual confirmation, and contextual consistency verification can be actually executed, thus constructing a three-tiered control system from risk identification to confirmation decision-making to safe execution. Including execution results and anomaly information in historical risk event records provides a data foundation for subsequent adaptive adjustments to dynamic thresholds and continuous optimization of risk strategies. Establishing complete information from risk assessment identifiers to confirmation node identifiers to execution results creates an immutable chain of evidence between the confirmation decision and the actual execution action for each high-risk operation, providing reliable technical support for post-event review.

[0103] In some embodiments of the present invention, the above method may further include the following steps: Record the execution behavior information of risk nodes, including the reasoning process information, tool call sequence and intermediate decision information of risk nodes; Based on the execution behavior information, a behavioral feature vector is constructed for the risk node. The behavioral feature vector includes inference consistency indicators, tool call compliance indicators, and decision stability indicators. The behavioral feature vector is compared with the historical behavioral feature vector of the risk node to obtain the feature deviation. When the characteristic deviation exceeds the predetermined range, a behavior abnormality signal is generated; The generation rules for dynamic thresholds can be adjusted based on abnormal behavior signals, or abnormal behavior signals can be used as new triggering conditions for mandatory confirmation rules, so that risk nodes will hit the mandatory confirmation rules in subsequent assessments.

[0104] Among them, the reasoning consistency index refers to the degree of self-consistency within the current reasoning path, such as whether the reasoning steps are consistent from beginning to end, and whether there are jumps or contradictions in the reasoning chain. The tool call compliance index refers to the degree of matching between the current tool call sequence and the preset tool usage specifications. The decision stability index refers to the degree of consistency of the reasoning results of the current node in similar sub-scenes, such as whether the same conclusion is given for the same condition judgment in different reasoning rounds. The feature deviation can be a quantitative value of the statistical difference between the current behavior feature vector and the historical behavior feature vector.

[0105] In the specific implementation, during the execution of each risk node, the intermediate inference output of the agent model when planning that node, the scoring and ranking of each candidate tool during tool selection, the source and derivation process of each parameter value during parameter filling, and the basis for selecting conditional branches during execution are recorded. Inference process information can be obtained from the agent model's inference log, including the planning basis for that node, alternative solutions, and the model's confidence level for that node. The tool call sequence can include the actual tool identifier, call order, and input / output of each call. Intermediate decision information can be obtained from the execution log, including the results of conditional judgments and the reasons for branch selection.

[0106] The construction of behavioral feature vectors can be achieved by independently extracting features from the collected execution behavior information. The reasoning consistency index can be calculated by analyzing the self-consistency of the current reasoning chain. For example, it can detect logical jumps, contradictions, or missing necessary intermediate steps between reasoning steps, quantifying the number and severity of these problems as a reasoning consistency score; the lower the score, the more self-consistent the reasoning. The tool call compliance index can be calculated by matching the current tool call sequence with the standard call patterns corresponding to this node type in the tool usage specification library, counting the number of missing necessary call steps and the number of redundant non-standard call steps, and comprehensively obtaining a compliance score. The decision stability index can be calculated by identifying sub-scenarios containing conditional judgments during the execution of the current node, and statistically analyzing the consistency of the agent's multiple judgments under similar conditions. If different conclusions are reached multiple times for the same type of condition, the decision stability score is low. These three indices constitute the behavioral feature vector of the current risk node. The historical behavioral feature vector can be the mean vector or weighted mean vector of the behavioral feature vectors constructed by this risk node in similar historical tasks. The current behavior feature vector is compared with the historical behavior feature vectors, and the Euclidean distance or Mahalanobis distance between the two is calculated as the feature deviation. When the feature deviation exceeds a preset anomaly threshold, a behavior anomaly signal is generated, indicating that the behavior pattern of the current risk node has deviated significantly from the historical baseline.

[0107] Once a behavioral anomaly signal is generated, adjusting the dynamic threshold generation rules can be achieved by using the risk node type and anomaly severity associated with the anomaly signal as new adjustment factors. An adjustment term based on the anomaly type can be added to the dynamic threshold calculation formula, lowering the dynamic threshold for subsequent nodes of the same type during evaluation and increasing the probability of triggering confirmation. Alternatively, using behavioral anomaly signals as a new trigger condition for mandatory confirmation rules can be achieved by writing the behavioral patterns that generate the anomaly signals into the rule engine. When subsequent nodes exhibit similar behavioral patterns during planning or execution, the mandatory confirmation rule is directly triggered, no longer relying on the comparison results of the comprehensive risk score and dynamic threshold.

[0108] Taking an agent performing a data analysis task as an example, after a data export node is completed, the behavior acquisition component records the execution behavior information of that node. The inference process information shows that the agent's inference steps when planning this export node were: first query data, then generate a file, and finally transfer the file. The entire inference chain skipped the data anonymization assessment step, which is common in similar tasks. When constructing an inference consistency index based on this inference process information, the inference consistency index itself does not reflect any anomalies because the inference chain is self-consistent and there are no obvious contradictions between steps. The tool call sequence shows that the data query interface, file generation interface, and file transfer interface were actually called. After matching this with the standard call pattern of data export nodes in the tool usage specification library, it was found that the standard pattern includes a call to the data anonymization interface, while this step is missing in the current sequence, resulting in a low score for the tool call compliance index. The decision stability index, by examining the node's processing decisions on multiple similar data subsets, consistently chose to export directly without anonymization, indicating consistent and stable decision-making, and the decision stability index is normal. These three indicators constitute the current behavior feature vector. The behavioral feature vector is compared with the mean vector of the historical behavioral feature vectors of the data export node in the past five similar tasks. The Euclidean distance is calculated, and it is found that the tool call compliance indicator deviates from the historical mean by more than two standard deviations, and the overall feature deviation exceeds a preset threshold, generating a behavioral anomaly signal. This anomaly signal is fed back into the risk assessment strategy, adjusting the dynamic threshold generation rules so that the dynamic threshold of subsequent data export nodes is appropriately lowered due to the influence of recent anomaly detection results. Simultaneously, the behavior pattern of skipping the de-identification step and directly exporting the entire data is used as a new trigger condition for the mandatory confirmation rule. Any subsequent export operation lacking the de-identification step in the tool call sequence will directly trigger the mandatory confirmation rule, be forcibly marked as a risk node, and inserted into the confirmation process.

[0109] By recording the execution behavior information of risk nodes and constructing behavioral feature vectors that include inference consistency, tool invocation compliance, and decision stability, and comparing these behavioral feature vectors with historical behavioral feature vectors to detect abnormal deviations, it is possible to detect abnormal drifts in agent behavior patterns after the execution of risk nodes. This compensates for runtime behavioral change risks that may not be covered by relying solely on pre-assessment of risk factors. Feedback of abnormal behavior signals to the adjustment of dynamic threshold generation rules and mandatory confirmation rules enables the risk assessment strategy to continuously and adaptively optimize based on the agent's actual behavior, forming a complete closed loop from behavior monitoring to risk strategy adjustment. This enhances the self-evolution capability and long-term reliability of the agent's high-risk operation risk control system.

[0110] The technical solution of the present invention has at least the following beneficial effects: During the execution of the task graph, risk factors of nodes that have not yet been executed are extracted and a comprehensive risk score is calculated. A confirmation threshold is dynamically generated in combination with the current context, thereby accurately triggering manual confirmation for high-risk nodes instead of uniformly interrupting all operations; the confirmation node is inserted into the task graph after the necessary predecessor node is completed and before the risk node is executed, and the confirmation decision is bound to the task graph version and node context in an anti-tampering manner through binding digest. Before execution, the task graph snapshot is used as a benchmark for verification again to ensure that only actions consistent with the context at the time of confirmation are released for execution, effectively preventing the confirmation from being tampered with after confirmation or the use of invalid confirmation after context changes, thereby improving the execution security of high-risk operations of the agent and the reliability of human-machine collaboration.

[0111] This embodiment also provides a human-machine verification control device for intelligent agent task execution. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0112] This embodiment provides a human-machine verification control device for intelligent agent task execution, such as... Figure 4 As shown, it includes: The snapshot acquisition module 401 is used to acquire a snapshot of the task graph in response to the existence of nodes that have not yet been executed in the task graph. The snapshot of the task graph includes at least a task graph version identifier, and the task graph contains nodes and the dependencies between nodes. The risk marking module 402 is used to extract the risk factors of the nodes that have not yet been executed, calculate the comprehensive risk score based on the risk factors, generate a dynamic threshold based on the current context, and mark the nodes whose comprehensive risk score reaches the dynamic threshold or hit the mandatory confirmation rule as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information. The graph rewriting module 403 is used to determine the necessary predecessor nodes of the risk node from the task graph, insert a confirmation node after the necessary predecessor node is completed and before the risk node is executed, obtain the rewritten task graph, and perform acyclic verification on the rewritten task graph. The confirmation generation module 404 is used to generate confirmation information based on the information of the risk node and generate a binding summary, wherein the binding summary is used to prevent the risk node from being tampered with after confirmation. Feedback processing module 405 is used to obtain feedback information for the confirmation information and change the state of the confirmation node according to the type of the feedback information; The consistency verification module 406 is used to perform consistency verification between the binding summary and the current actual information of the risk node in the rewritten task graph, based on the status of the confirmed node after the change and using the task graph snapshot as a reference. The execution control module 407 is used to control the execution of the risk node when the verification passes.

[0113] In this embodiment, a human-machine confirmation control device for intelligent agent task execution is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0114] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0115] This invention also provides a computer device having the above-described features. Figure 4 The diagram shows a human-machine verification control device for intelligent agent task execution.

[0116] The following is a detailed reference. Figure 5The diagram illustrates a structural schematic suitable for implementing a computer device according to embodiments of the present invention. The computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (i.e., ROM 502) or a program loaded from memory 508 into random access memory (i.e., RAM 505). The RAM 505 also stores various programs and data required for the operation of the computer device. The processor 501, ROM 502, and RAM 505 are interconnected via a bus 504. Input / output (i.e., I / O interface 505) is also connected to the bus 504.

[0117] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows the computer device to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Computer equipment with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0118] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in a human-machine verification control method for intelligent agent task execution according to an embodiment of the present invention.

[0119] Figure 5 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0120] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, a human-machine confirmation control method for intelligent agent task execution shown in the above embodiments is implemented.

[0121] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0122] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A human-machine verification control method for intelligent agent task execution, characterized in that, The method includes: In response to the existence of nodes in the task graph that have not yet been executed, a snapshot of the task graph is obtained. The snapshot of the task graph includes at least a task graph version identifier, and the task graph contains nodes and the dependencies between nodes. Extract the risk factors of the nodes that have not yet been executed, calculate the comprehensive risk score based on the risk factors, and generate a dynamic threshold based on the current context. Mark the nodes whose comprehensive risk score reaches the dynamic threshold or hit the mandatory confirmation rule as risk nodes. The context includes at least one of the following: the current user's role information, the current task's business type information, the current operating environment information, and historical anomaly information. The necessary predecessor nodes of the risk node are determined from the task graph. After the necessary predecessor nodes are completed and before the risk node is executed, a confirmation node is inserted to obtain the rewritten task graph. The rewritten task graph is then subjected to acyclic verification. Confirmation information is generated based on the information of the risk node, and a binding digest is generated. The binding digest is used to prevent the risk node from being tampered with after confirmation. Obtain feedback information regarding the confirmation information, and change the status of the confirmation node according to the type of the feedback information; In the rewritten task graph, based on the changed status of the confirmed node and using the task graph snapshot as a reference, the binding summary is checked for consistency with the current actual information of the risk node; When the verification passes, control the execution of the risk node.

2. The method according to claim 1, characterized in that, The risk factors include at least one of the following: scope of impact, data sensitivity level, irreversibility, model uncertainty, user role risk, historical risk, external side effect level, and compliance level; wherein, the model uncertainty is used to characterize the confidence level of the node, the external side effect level is used to characterize the degree of impact of the node on external systems, and the compliance level is used to characterize the degree of compliance of the node with regulatory policies or industry standards; the calculation of a comprehensive risk score based on the risk factors includes: Each of the risk factors is normalized separately, and the normalized risk factors are then weighted and summed to obtain a single-item sum. When there is a factor pair among the risk factors that meets a predetermined condition, an interaction term is added to the factor pair, and the sum of the interaction terms is calculated. The interaction term reflects the combined risk amplification effect generated when the factor pair increases simultaneously. The sum of the individual terms and the sum of the interaction terms are mapped to the unified numerical range using a monotonic function to obtain the comprehensive risk score.

3. The method according to claim 1, characterized in that, The step of generating a dynamic threshold based on the current context includes: Obtain a baseline threshold, which is a uniformly configured threshold starting point; The role adjustment amount is determined based on the current user's role information, the business type adjustment amount is determined based on the current task's business type information, and the environment adjustment amount is determined based on the current operating environment information. The baseline threshold is adjusted based on the role adjustment amount, the business type adjustment amount, and the environment adjustment amount to obtain the adjusted threshold. When the context includes historical anomaly information, the intensity information of verified anomaly events in the historical anomaly information within a preset time range is obtained, and the adjusted threshold is reduced based on the intensity information of the anomaly events. The adjusted threshold is limited to a predetermined upper and lower bound range to obtain the dynamic threshold.

4. The method according to claim 1, characterized in that, The mandatory confirmation rules include at least one of the following: cross-tenant write operations, batch deletion operations, payment operations exceeding a predetermined threshold, operations that send notifications to external systems, and sensitive data export operations.

5. The method according to claim 1, characterized in that, The necessary predecessor node is the node on which the confirmation information is generated. The process of inserting the confirmation node after the necessary predecessor node is completed and before the risk node is executed, to obtain the rewritten task graph, includes: Redirect the incoming edges of the necessary predecessor nodes in the task graph that point to the risk nodes to the confirmation nodes; Add a control edge pointing from the confirmation node to the risk node; The incoming edges pointing from unnecessary predecessor nodes to risk nodes in the task graph are kept as they are to obtain the rewritten task graph. When the rewritten task graph forms a loop or causes the semantics of the conditional branches to be ambiguous or unable to cover the risk nodes, the operation of inserting a confirmation node is abandoned and the process is transferred to manual handling.

6. The method according to claim 1, characterized in that, The insertion confirmation node includes: When the risk node is located in the conditional branch path, the confirmation node is inserted into the actual branch in the conditional branch path that leads to the risk node; When there are multiple risk nodes that belong to the same atomic transaction group, and the confirmation information can list all actions, parameters and total impact of the multiple risk nodes, the multiple risk nodes can be controlled by a single confirmation node. When the task graph contains a cyclic structure, the confirmation node is inserted into the subgraph corresponding to the current iteration, and the iteration identifier of the current iteration is recorded for use in generating the binding summary.

7. The method according to claim 1, characterized in that, The step of generating confirmation information based on the information of the risk node and generating a binding digest includes: Obtain the action information, parameter information, target object information, and tool information invoked by the risk node; Based on the action information and the target object information, determine the scope of influence and consequences of the risk node; Based on the calculation results of the risk factors, obtain the risk trigger information of the risk node; Obtain the rollback capability information of the risk node; The confirmation information is generated by combining the action information, parameter information, target object information, tool information, scope of influence and consequence information, risk triggering information, and rollback capability information. Obtain the risk node identifier and the output summary of the necessary predecessor node, and standardize the parameter information to obtain standardized parameters; wherein, the risk node identifier is used to uniquely identify the risk node in the task graph, and the output summary is the output content of the necessary predecessor node; The scope of authority of the provider of the feedback information, and the version identifier of the evaluation parameter configuration on which the dynamic threshold is based; The binding summary is generated by binding the task graph version identifier, the risk node identifier, the standardization parameters, the output summary of the necessary predecessor nodes, the permission scope, and the version identifier of the evaluation parameter configuration.

8. The method according to claim 1, characterized in that, The types of feedback information include confirmation passed, parameter modification, execution rejected, and timeout; changing the status of the confirmation node according to the type of feedback information includes: When the feedback information indicates confirmation, the status of the confirmation node is changed to confirmed. When the feedback information indicates parameter modification, the status of the confirmation node is changed to modified, the risk node is updated according to the modified parameters, and the risk is reassessed. If the risk is lower than the dynamic threshold after reassessment, the risk node is released; if it still reaches the dynamic threshold, a new version of the confirmation information is generated. When the feedback information is "rejection", the status of the confirmation node is changed to "rejected", the risk node is blocked, and the rejection reason is converted into a replanning constraint. Based on the replanning constraint, a local replanning is performed on the set of affected nodes in the task graph to generate a local alternative plan. If the local alternative plan cannot be generated, the task is terminated. If the local alternative plan contains high-risk nodes, a new version of the confirmation information is generated. The set of affected nodes includes the rejected risk node, successor nodes that depend on the output of the rejected risk node, and nodes that share the same atomic transaction group as the rejected risk node. When the feedback information is timeout, the status of the confirmation node is changed to timeout, and the operation is stopped, upgraded to approval, transferred to manual processing, or the confirmation operation is re-initiated.

9. The method according to claim 1, characterized in that, The step of verifying the consistency between the binding digest and the current actual information of the risk node includes: Obtain the current actual information of the risk node, which includes the current actual standardized parameters, the actual output summary of the current necessary predecessor node, the current permission scope, and the current actual version identifier of the evaluation parameter configuration; Compare the binding summary with the current actual information; When the binding summary matches the current actual information, the verification passes and the risk node is released. When the binding summary is inconsistent with the current actual information, the verification fails, the confirmation node becomes invalid, and a new version of the confirmation information is generated to re-initiate the confirmation operation.

10. The method according to claim 1, characterized in that, Also includes: Record the execution behavior information of the risk node, including the reasoning process information, tool call sequence, and intermediate decision information of the risk node; The behavioral feature vector of the risk node is constructed based on the execution behavior information. The behavioral feature vector includes inference consistency index, tool call compliance index, and decision stability index. The behavioral feature vector is compared with the historical behavioral feature vector of the risk node to obtain the feature deviation. When the characteristic deviation exceeds a predetermined range, a behavior abnormality signal is generated; The generation rules for the dynamic threshold can be adjusted based on the abnormal behavior signal, or the abnormal behavior signal can be used as a new triggering condition for the mandatory confirmation rule, so that the risk node hits the mandatory confirmation rule in subsequent evaluations.

Images