Error propagation graph driven pre-execution control method and system
Patent Information
- Application Number
- CN202611159226.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-01
- Publication Date
- 2026-10-27
AI Technical Summary
一、现有方案在阻断当前动作后仅返回故障报告，错误已在当前动作发生但未被抑制，阻断行为仅阻止了该错误向下游继续传播，却无法消除错误在依赖链上已形成的传播事实，错误传播深度仍可能因上游错误已发生而维持在较高水平
1.本发明中，通过错误传播抑制模块根据错误传播图中的节点风险值、边权累计值和传播深度对资源修正动作执行错误传播抑制。实现了在错误发生后的实际传播过程中对候选动作执行阻断或降级，使错误无法沿依赖边继续级联扩散，解决了传统重试与自愈机制仅作用于单次调用、无法抑制错误沿依赖链级联传播的问题。
Smart Images
Figure CN122986137A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of propagation graph driving technology, and in particular to a method and system for controlling error propagation graph driving execution before execution. Background Technology
[0002] An error propagation graph is a graph structure with execution action nodes as vertices and dependencies between actions as directed edges. The node risk value is calculated from the API state, error code, and number of retries. The edge weight represents the strength of error propagation along the dependency, and the propagation depth represents the maximum cascade length in the current error propagation chain. It is used to characterize the dynamic propagation path and impact range of errors in the execution chain.
[0003] In existing technologies, there are technical solutions that apply error propagation graphs to pre-execution control. These solutions typically involve: constructing a dependency graph, performing hierarchical verification on candidate actions, blocking the current action and returning a fault report when verification fails, and simultaneously performing risk assessment and control on downstream nodes to reduce the probability of errors continuing to propagate in the action chain.
[0004] However, the following problems still exist in the existing technology: I. The existing solution only returns a fault report after blocking the current action. The error has already occurred in the current action but has not been suppressed. The blocking behavior only prevents the error from continuing to propagate downstream, but cannot eliminate the fact that the error has already been propagated in the dependency chain. The depth of error propagation may still remain at a high level because an upstream error has already occurred.
[0005] Second, the existing solution relies on the risk propagation prediction model to estimate the risk of downstream nodes. Its decision-making basis includes the prediction results of future states. However, the prediction model itself has errors and uncertainties, and cannot operate normally in a cold start scenario without historical data.
[0006] Third, in the existing scheme, resource pressure detection and error propagation suppression belong to different decision channels, and there is a lack of a mechanism to coordinate resource occupation, execution delay, graph risk and node risk in the same control chain in a fixed order.
[0007] Therefore, to solve the above problems, a method and system for error propagation graph-driven pre-execution control are proposed. Summary of the Invention
[0008] To address the shortcomings of existing technologies, this invention provides the following technical solution: An error propagation graph-driven pre-execution control system includes: The runtime state acquisition module is used to acquire the runtime state vector of the current execution step. The vector includes at least API status, error code, number of retries, resource usage, execution delay, and action dependencies.
[0009] An error propagation graph construction module is used to construct or update an error propagation graph based on the dependencies, API status, error codes, and retry counts. The graph includes action nodes, node risk values, action dependency edges, and edge weights.
[0010] The resource constraint correction module is used to correct the resource constraints of candidate actions based on preset resource thresholds, and obtain the resource-corrected actions.
[0011] The error propagation suppression module is used to suppress the error propagation of the resource correction action based on the node risk value, edge weight cumulative value and propagation depth in the graph, and obtain the error suppression action.
[0012] The stability projection module is used to calculate the stability value based on the resource consumption, execution latency, and retry count in the vector, as well as the node risk and risk value in the graph, and to project the error suppression action based on the stability value, and output the final action or control action.
[0013] The structured control trajectory recording module is used to record candidate actions, final actions, current states, error propagation graphs, operator decisions, and control reasons.
[0014] The resource constraint correction module, error propagation suppression module, and stability projection module process the candidate actions in a fixed order.
[0015] As an improvement to the above technical solution: The runtime state vector also includes API status, error code, number of retries, resource usage, execution latency, and action dependencies.
[0016] The API status includes normal status, rate-limited status, and timeout status, and the error codes include HTTP error codes and protocol error types.
[0017] As an improvement to the above technical solution: The error propagation graph construction module establishes directed edges between action nodes based on the action dependencies.
[0018] The node risk value is calculated from the API status, error code, and number of retries of the corresponding action node.
[0019] The edge weight represents the strength of error propagation along dependencies, and the propagation depth represents the maximum cascade length in the current error propagation chain.
[0020] As an improvement to the above technical solution: The error propagation suppression module also performs error propagation suppression based on the graph risk value.
[0021] The graph risk value is calculated by combining the maximum risk value of a node, the average risk value of a node, the maximum edge weight, and the propagation depth in the error propagation graph.
[0022] As an improvement to the above technical solution: The resource constraint correction module determines whether the candidate execution action exceeds a preset resource threshold based on at least one of the CPU utilization, memory utilization, concurrent request count, and execution latency in the current runtime state vector. If it does, the module performs latency correction, rate limiting, or rerouting correction on the candidate execution action.
[0023] As an improvement to the above technical solution: The stability projection module outputs different control actions based on different value ranges of the stability value: When the stability value is lower than a preset safety threshold, a degradation control action is triggered.
[0024] When the stability value is lower than a preset critical threshold, a manual confirmation control action is triggered.
[0025] When the stability value is lower than the preset circuit breaker threshold, the circuit breaker control action is triggered.
[0026] As an improvement to the above technical solution: The candidate execution action is at least one of API call action, RPA process action, or tool call action.
[0027] The runtime state vector is collected from the multi-step execution process of API call chains, RPA automation processes, or tool call chains.
[0028] As an improvement to the above technical solution: The resource constraint correction module, the error propagation suppression module, and the stability projection module process the candidate execution actions in a fixed order to form a pre-execution control chain that connects the runtime state vector, the error propagation graph, the candidate actions, the resource constraint correction, the error propagation suppression, the stability projection, and the final action or control action.
[0029] As an improvement to the above technical solution: The data recorded by the structured control trajectory recording module is used for offline audit playback and offline configuration review; The data includes at least candidate action identifiers, final action identifiers, execution timestamps, error propagation graph structure hash values, decision reasons for each operator, and reasons for triggering control actions.
[0030] As an improvement to the above technical solution: An error propagation graph-driven pre-execution control method includes the following steps: S1: Collect the runtime state vector of the current execution step. The runtime state vector includes at least API status, error code, number of retries, resource usage, execution latency, and action dependencies.
[0031] S2: Based on the action dependencies, API status, error codes, and retry counts, construct or update the error propagation graph, which includes the action execution node, node risk value, action dependency edge, and edge weight.
[0032] S3: Receive candidate actions to execute.
[0033] S4: Perform resource constraint correction on the candidate execution action according to the preset resource threshold to obtain the resource correction action.
[0034] S5: Based on the node risk value, edge weight cumulative value, and propagation depth in the error propagation graph, perform error propagation suppression on the resource correction action to obtain the error suppression action.
[0035] S6: Calculate the stability value based on the resource consumption, execution latency, graph risk, node risk and retry count in the current runtime state vector, and perform stability projection on the error suppression action based on the stability value.
[0036] S7: Based on the stability projection results, output the final execution action, or trigger at least one of the following control actions: circuit breaking, degradation, or manual confirmation.
[0037] S8: Record candidate actions, final actions, current state, error propagation graph, operator decisions and control reasons to form a structured control trajectory.
[0038] The beneficial effects of this invention are: 1. In this invention, an error propagation suppression module performs error propagation suppression on resource correction actions based on the node risk value, cumulative edge weight value, and propagation depth in the error propagation graph. This achieves blocking or downgrading of candidate actions during the actual propagation process after an error occurs, preventing the error from continuing to cascade along dependency edges. This solves the problem that traditional retry and self-healing mechanisms only work on a single call and cannot suppress the cascading propagation of errors along dependency chains.
[0039] 2. In this invention, the runtime state vector of the current execution step is collected by the runtime state acquisition module, and the error propagation graph is constructed or updated by the error propagation graph construction module. This enables the error propagation graph to directly participate in action rewriting as a pre-execution control input, rather than merely serving as a post-execution observation record, thus solving the problem that existing tracking and observation methods are only used for post-execution analysis and do not participate in pre-execution decision-making.
[0040] 3. In this invention, candidate execution actions are processed sequentially in a fixed order by a resource constraint correction module, an error propagation suppression module, and a stability projection module. This achieves the orderly integration and collaborative judgment of resource pressure handling, error propagation blocking, and stability assessment within the same pre-execution control chain, solving the problem in existing technologies where resource limiting, error retries, and manual intervention are implemented by independent modules, lacking a unified control mechanism. Attached Figure Description
[0041] Figure 1 This is a system architecture block diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention; Figure 3 This is a flowchart of the method of the present invention. Detailed Implementation
[0042] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention.
[0043] See appendix Figure 1 Appendix Figure 3 A fault propagation graph-driven pre-execution control system, comprising: The runtime state acquisition module is used to collect the runtime state vector of the current execution step. The vector includes at least API status, error code, retry count, resource consumption, execution latency, and action dependencies. The error propagation graph construction module is used to build or update the error propagation graph based on dependencies, API status, error codes, and retry counts. The graph includes action nodes, node risk values, action dependency edges, and edge weights.
[0044] The resource constraint correction module is used to correct the resource constraints of candidate actions based on preset resource thresholds, and obtain the resource-corrected actions.
[0045] The error propagation suppression module is used to suppress error propagation of resource correction actions based on the node risk value, edge weight cumulative value, and propagation depth in the graph, and obtain the error suppression action.
[0046] The stability projection module is used to calculate stability values based on resource consumption, execution latency, and retry count in the vector, as well as node risks and risk values in the graph. It then projects error suppression actions based on the stability values and outputs the final action or control action.
[0047] The structured control trajectory recording module is used to record candidate actions, final actions, current states, error propagation graphs, operator decisions, and control reasons.
[0048] The resource constraint correction module, error propagation suppression module, and stability projection module process candidate actions in a fixed order.
[0049] In one embodiment, the system operates in an API call chain scenario containing eight dependent steps. The runtime state acquisition module collects the state vector of the current execution step, including the API status as rate-limited, the error code as HTTP_429, the number of retries as 1, the CPU ratio as 0.82, the memory ratio as 0.76, the execution latency as timed out, and the action dependency record of the parent and child nodes of the current call.
[0050] The error propagation graph construction module constructs a directed graph based on the above information: nodes represent API call actions, node risk values are calculated from API status such as rate_limited or timeout, error codes such as HTTP_429 or Timeout, and the number of retries, directed edges represent call dependencies, and edge weights reflect the intensity of the impact of upstream errors on downstream errors.
[0051] The resource constraint correction module corrects the constraints of candidate actions based on resource occupancy. The error propagation suppression module suppresses resource-corrected actions based on node risk values, cumulative edge weights, and propagation depth. The stability projection module calculates a stability value and outputs the final action or control action by comprehensively considering resource occupancy, execution latency, graph risk, node risk, and the number of retries.
[0052] Experiments verified that in the uncontrolled mode, the API success rate was 0.50%, the cumulative number of error propagation attempts was 3, the maximum propagation depth was 4 levels, the p95 latency was 2600 milliseconds, and the peak resource cost was 0.900. In the retry-only mode, the API success rate was 0.75%, the cumulative number of error propagation attempts was 3, the maximum propagation depth remained at 4 levels, the p95 latency was 3240 milliseconds, and the peak resource cost was 0.980. This system improved the API success rate to 1.00, reduced the cumulative number of error propagation attempts to 0, reduced the maximum propagation depth to 0 levels, reduced the p95 latency to 1092 milliseconds, and reduced the peak resource cost to 0.648. The experiment also recorded 3 instances of manual confirmation and 1 instance of downgrading triggered by this system.
[0053] See appendix Figure 1 Appendix Figure 3 The runtime state vector also includes API status, error codes, retries, resource usage, execution latency, and action dependencies.
[0054] API status includes normal status, rate-limited status, and timeout status, and error codes include HTTP error codes and protocol error types.
[0055] In one embodiment, during system operation, the runtime state acquisition module acquires a state vector for the current execution step in the tool call chain.
[0056] For example, in a certain execution step, when the system calls an external API, the API returns an HTTP 429 status code due to excessive request frequency. The API status in the status vector is marked as rate-limited, the error code is recorded as HTTP_429, the retry count is recorded as the current number of retries, resource usage is recorded as CPU ratio and memory ratio, and execution latency is recorded as a timeout status. The action dependency record records the parent and child nodes of the current action.
[0057] If the target service does not respond in a subsequent call, the API status is marked as timeout and the error code is recorded as Timeout.
[0058] If the data format returned by the call does not match the expectation, the API status is recorded as an abnormal state, and the error code is recorded as SchemaMismatch. The API status and error code recorded in the status vector serve as the core input for node risk calculation in the subsequent error propagation graph construction, and are used to quantify the real-time risk level of each action node.
[0059] See appendix Figure 1 Appendix Figure 3 The error propagation graph construction module establishes directed edges between action nodes based on action dependencies.
[0060] The node risk value is calculated from the API status, error code, and number of retries of the corresponding action node; Edge weight represents the strength of error propagation along dependencies, and propagation depth represents the maximum cascade length in the current error propagation chain.
[0061] In one embodiment, the error propagation graph construction module receives a state vector from the runtime state acquisition module and establishes directed edges between each execution action node based on the action dependencies therein. Each execution action node corresponds to an API call action, RPA process action, or tool call action.
[0062] The node risk value is calculated by combining the node's API status (e.g., normal, rate-limited, or timeout), error code (e.g., HTTP_429, Timeout, or SchemaMismatch), and the number of retries. A directed edge represents the dependency between two action nodes. The direction of the edge is determined by the dependency direction, and the edge weight represents the strength of error propagation along the dependency. A larger edge weight indicates that an error in the upstream node is more likely to cause a failure in the downstream node.
[0063] The propagation depth represents the maximum cascade length that can be reached from the current starting error node along the directed edge, that is, the number of node layers that the current active error propagation chain spans.
[0064] See appendix Figure 1 Appendix Figure 3 The error propagation suppression module also performs error propagation suppression based on the graph risk value.
[0065] The graph risk value is calculated by combining the maximum risk value of a node, the average risk value of a node, the maximum edge weight, and the propagation depth in the error propagation graph.
[0066] In one embodiment, after obtaining the error propagation graph, the error propagation suppression module first calculates the graph risk value of the graph.
[0067] The calculation of the graph risk value integrates the following four factors: The maximum risk value of a node is the risk score of the node with the highest risk value among all nodes performing actions in the graph.
[0068] The node average risk value is the arithmetic mean of the risk values of all nodes performing actions in the graph.
[0069] The maximum edge weight is the weight of the edge with the largest weight among all directed edges in the graph.
[0070] Propagation depth refers to the maximum cascading length of the currently active error propagation chain. A high value in any of the four indicators will increase the graph risk value.
[0071] The error propagation suppression module compares the calculated graph risk value with a preset graph risk threshold. If the graph risk value exceeds the threshold, additional error propagation suppression is performed on resource correction actions, including but not limited to blocking candidate actions downstream of high-weight dependent edges, or imposing stricter restrictions on actions on deep propagation paths. If the graph risk value is within the safe range, only regular suppression processing is performed based on the single-node risk value and the cumulative edge weight value.
[0072] See appendix Figure 1 Appendix Figure 3 The resource constraint correction module determines whether a candidate execution action exceeds a preset resource threshold based on at least one of the following in the current runtime state vector: CPU utilization, memory utilization, number of concurrent requests, and execution latency. If it does, it performs latency correction, rate limiting, or rerouting correction on the candidate execution action.
[0073] In one embodiment, the resource constraint correction module receives candidate execution actions and the current runtime state vector, and extracts CPU utilization, memory utilization, number of concurrent requests, and execution latency from the state vector as inputs for resource constraint judgment.
[0074] The module compares these metrics with preset resource thresholds one by one. If the CPU utilization or memory utilization exceeds the threshold, it indicates that computing resources are tight. The module then performs a delay correction on the candidate action and waits for resources to be released before attempting to execute it.
[0075] If the number of concurrent requests exceeds the threshold, it indicates that the current concurrency load of the system is too high. Rate limiting correction is performed on the candidate actions, and they are added to the waiting queue for sequential processing to avoid system overload.
[0076] If the execution delay exceeds the threshold, it indicates that the current execution link is slow. The candidate action will be rerouted and forwarded to the backup server endpoint for execution.
[0077] The above three correction methods can be executed individually or simultaneously based on the combination of indicators that exceed the threshold.
[0078] For example, when both CPU utilization and memory utilization exceed the threshold, delayed execution and rate limiting correction can be combined to effectively control the peak system resource usage. Experimental data shows that this system controls the peak resource usage from 0.900 in the uncontrolled mode and 0.980 in the retry-only mode to 0.648.
[0079] See appendix Figure 1 Appendix Figure 3 The stability projection module outputs different control actions based on different ranges of stability values. When the stability value is lower than the preset safety threshold, a degradation control action is triggered.
[0080] When the stability value is lower than the preset critical threshold, a manual confirmation control action is triggered.
[0081] When the stability value is lower than the preset circuit breaker threshold, the circuit breaker control action is triggered.
[0082] In one embodiment, after receiving an error suppression action, the stability projection module obtains the resource consumption, execution delay, and retry count in the current runtime state vector, as well as the node risk and graph risk in the error propagation graph. It then calculates the current stability value by combining the above five inputs. This stability value reflects the reliability of the system in safely executing the action in the current state.
[0083] The module has three preset threshold levels: safety threshold, critical threshold, and circuit breaker threshold, which are arranged in descending order of value.
[0084] When the stability value is higher than or equal to the safety threshold, the action can be executed normally.
[0085] When the stability value is below the safety threshold but above or equal to the critical threshold, a degradation control action is triggered, which is performed in a way that is of lower quality or with limited functionality to ensure that the core functions are not affected.
[0086] When the stability value is below the critical threshold but above or equal to the circuit breaker threshold, a manual confirmation control action is triggered, pausing automatic execution and waiting for manual intervention.
[0087] When the stability value is lower than the circuit breaker threshold, the circuit breaker control action is triggered, the current execution chain is immediately terminated and a safety error response is returned.
[0088] In the deterministic 8-step API, RPA, and tool call experiment scenario, the system triggered manual confirmation 3 times and downgrade 1 time, verifying the effectiveness of the above-mentioned tiered control mechanism.
[0089] See appendix Figure 1 Appendix Figure 3 The candidate execution action is at least one of the following: API call action, RPA process action, or tool call action.
[0090] Runtime state vectors are collected from the multi-step execution process of API call chains, RPA automation processes, or tool call chains.
[0091] In one embodiment, the system supports three types of execution chain scenarios simultaneously: In the API call chain scenario, the candidate execution action is the action of calling multiple related APIs in sequence. The runtime state vector is collected from the response status, error code, number of retries, resource consumption, execution delay and call dependencies between APIs for each API call.
[0092] In RPA automation process scenarios, candidate execution actions are a series of interface operation steps executed by the RPA robot. The runtime state vector is collected from the execution status, error type, and dependencies between process steps of each step.
[0093] In the tool call chain scenario, the candidate execution action is a series of external tools called sequentially by the agent. The runtime state vector is collected from the return status of each tool call, the execution time, and the data flow dependency between tools.
[0094] Taking an 8-step API call chain experiment as an example, the system continuously collects state vectors and constructs an error propagation graph at each execution step. It performs pre-execution control on each candidate API call action through a three-operator processing chain. Experimental data shows that the API success rate is 0.50 in the no-control mode, 0.75 in the retry-only mode, and 1.00 in this system.
[0095] See appendix Figure 1 Appendix Figure 3The resource constraint correction module, error propagation suppression module, and stability projection module process candidate execution actions in a fixed order, forming a pre-execution control chain that connects the runtime state vector, error propagation graph, candidate action, resource constraint correction, error propagation suppression, stability projection, and final action or control action in sequence.
[0096] In one embodiment, after the system receives a candidate API call action as input, the candidate action flows through three processing operators in sequence.
[0097] First, the resource constraint correction module determines whether the current resource status is sufficient to support the call based on the CPU utilization, memory utilization, number of concurrent requests, and execution latency in the current runtime state vector.
[0098] For example, the peak system resource value in the experimental data was 0.900 in the uncontrolled mode and 0.980 in the retry-only mode.
[0099] When resource consumption exceeds the threshold, the resource constraint correction module performs delay correction or rate limiting correction on candidate actions and outputs the resource correction action.
[0100] Secondly, the error propagation suppression module takes the resource correction action as input and, combined with the node risk value, cumulative edge weight value, and propagation depth in the current error propagation graph, determines whether the action is located on the error propagation path. Experimental data shows that the maximum propagation depth is level 4 in both the uncontrolled mode and the retry-only mode. The error propagation suppression module reduces the maximum propagation depth to level 0 by blocking actions located on the propagation path and outputs the error suppression action.
[0101] Finally, the stability projection module takes the error suppression action as input, integrates the resource consumption, execution delay, retry count in the current state vector, and node risk and graph risk in the graph to calculate the current stability value, and outputs the final action or control action according to the value range of the stability value.
[0102] In the above process, the original candidate actions flow unidirectionally among the three operators in a fixed order, forming a complete pre-execution control chain, and the output of each step directly serves as the input of the next step.
[0103] See appendix Figure 1 Appendix Figure 3 The data recorded by the structured control trajectory recording module is used for offline audit playback and offline configuration review.
[0104] The data should include at least the candidate action identifier, the final action identifier, the execution timestamp, the error propagation graph structure hash value, the decision reasons for each operator, and the reason for triggering the control action.
[0105] In one embodiment, after the system completes the control flow at each execution step, the structured control trajectory recording module generates a complete control trajectory record.
[0106] This record contains the unique identifier of the candidate action, the final output action or control action identifier after processing by the three operators, the timestamp of the current execution step, the hash value of the current error propagation graph structure, the decision reason and correction type of the resource constraint correction module, the decision reason and suppression type of the error propagation suppression module, the decision reason and output control action type of the stability projection module, and the specific reason for triggering the control action.
[0107] Taking a complete execution step as an example, the record shows that the candidate action is an API call action, the final action is a downgraded version of the same API, the error propagation graph structure hash value records the graph topology and risk distribution of the execution step, the decision reasons for each operator record the input indicators and judgment results of resource constraint correction, the graph risk value and suppression strategy of error propagation suppression, and the stability value and triggering conditions of stability projection.
[0108] The record is persistently stored in a structured data format. During offline audit playback, auditors can fully reproduce the control decision-making process of the execution step and verify whether the judgment logic of each operator conforms to the expected strategy. During offline configuration review, system maintenance personnel can analyze the distribution of the decision reasons of each operator and the frequency of triggered control actions in the historical trajectory records to assess whether the current preset threshold needs to be adjusted.
[0109] See appendix Figure 2 A method for error propagation graph-driven pre-execution control includes the following steps: S1: Collect the runtime state vector of the current execution step. The runtime state vector includes at least API status, error code, number of retries, resource usage, execution latency, and action dependencies.
[0110] S2: Based on the action dependencies, API status, error codes, and retry counts, construct or update the error propagation graph, which includes the action execution node, node risk value, action dependency edge, and edge weight.
[0111] S3: Receive candidate actions to execute.
[0112] S4: Perform resource constraint correction on the candidate execution action according to the preset resource threshold to obtain the resource correction action.
[0113] S5: Based on the node risk value, edge weight cumulative value, and propagation depth in the error propagation graph, perform error propagation suppression on the resource correction action to obtain the error suppression action.
[0114] S6: Calculate the stability value based on the resource consumption, execution latency, graph risk, node risk and retry count in the current runtime state vector, and perform stability projection on the error suppression action based on the stability value.
[0115] S7: Based on the stability projection results, output the final execution action, or trigger at least one of the following control actions: circuit breaking, degradation, or manual confirmation.
[0116] S8: Record candidate actions, final actions, current state, error propagation graph, operator decisions and control reasons to form a structured control trajectory.
[0117] In one embodiment, taking a deterministic 8-step API call chain as an example, the step dependencies are chain dependencies.
[0118] When the system is executing step 3, it detects that the API call returns an HTTP 429 error and collects the runtime state vector of the current execution step as shown in step S1.
[0119] Construct an error propagation graph based on dependencies, mark the current node as a high-risk node, set corresponding edge weights, and set the propagation depth to the current error cascade layer number, as described in step S2.
[0120] The system receives the candidate action to be executed in step 4, as described in step S3.
[0121] The resource constraint correction module detects the current CPU utilization and memory utilization, determines whether the resource status exceeds the threshold, and outputs the resource correction action after correction, as described in step S4.
[0122] The error propagation suppression module determines whether the subsequent action is located on the error propagation path based on the node risk value, edge weight cumulative value and propagation depth in the error propagation graph. If it is located on the path, it performs blocking suppression and outputs the error suppression action, as described in step S5.
[0123] The stability projection module calculates a stability value by comprehensively considering current resource usage, execution latency, graph risk, node risk, and number of retries. Based on this value, it outputs the final execution action or triggers at least one control action among circuit breaking, degradation, and manual confirmation, as described in steps S6 and S7.
[0124] The system pauses execution and waits for the corresponding control action to be executed. At the same time, the structured control trajectory recording module records the candidate action, the final action, the current state, the error propagation graph, the operator decision, and the control reason, as described in step S8.
[0125] Experimental data show that this method reduces the cumulative number of error propagation times from 3 in the uncontrolled mode and the retry-only mode to 0, the maximum propagation depth from 4 levels in the uncontrolled mode and the retry-only mode to 0, and the API success rate from 0.50 in the uncontrolled mode and 0.75 in the retry-only mode to 1.00.
[0126] The above embodiments are merely illustrative of the technical solutions of the present invention and are not intended to limit it. Anyone skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.
Claims
1. A fault propagation graph-driven pre-execution control system, characterized in that, include: The runtime state acquisition module is used to acquire the runtime state vector of the current execution step. The vector includes at least API status, error code, retry count, resource consumption, execution delay, and action dependencies. An error propagation graph construction module is used to construct or update an error propagation graph based on the dependencies, API status, error codes, and retry counts. The graph includes action nodes, node risk values, action dependency edges, and edge weights. The resource constraint correction module is used to correct the resource constraints of candidate actions according to a preset resource threshold, and obtain the resource-corrected actions. The error propagation suppression module is used to suppress the error propagation of the resource correction action based on the node risk value, edge weight cumulative value and propagation depth in the graph, and obtain the error suppression action; The stability projection module is used to calculate the stability value based on the resource consumption, execution latency, and retry count in the vector, as well as the node risk and risk value in the graph, and to project the error suppression action based on the stability value, and output the final action or control action. The structured control trajectory recording module is used to record candidate actions, final actions, current states, error propagation graphs, operator decisions, and control reasons. The resource constraint correction module, error propagation suppression module, and stability projection module process the candidate actions in a fixed order.
2. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The runtime state vector also includes API status, error code, retry count, resource consumption, execution latency, and action dependencies; The API status includes normal status, rate-limited status, and timeout status, and the error codes include HTTP error codes and protocol error types.
3. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The error propagation graph construction module establishes directed edges between action nodes based on the action dependencies; The node risk value is calculated from the API status, error code, and number of retries of the corresponding action node; The edge weight represents the strength of error propagation along dependencies, and the propagation depth represents the maximum cascade length in the current error propagation chain.
4. The error propagation graph-driven pre-execution control system according to claim 3, characterized in that: The error propagation suppression module also performs error propagation suppression based on the graph risk value; The graph risk value is calculated by combining the maximum risk value of a node, the average risk value of a node, the maximum edge weight, and the propagation depth in the error propagation graph.
5. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The resource constraint correction module determines whether the candidate execution action exceeds a preset resource threshold based on at least one of the CPU utilization, memory utilization, concurrent request count, and execution latency in the current runtime state vector. If it does, the module performs latency correction, rate limiting, or rerouting correction on the candidate execution action.
6. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The stability projection module outputs different control actions based on different value ranges of the stability value: When the stability value is lower than a preset safety threshold, a degradation control action is triggered. When the stability value is lower than a preset critical threshold, a manual confirmation control action is triggered. When the stability value is lower than the preset circuit breaker threshold, the circuit breaker control action is triggered.
7. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The candidate execution action is at least one of API call action, RPA process action, or tool call action; The runtime state vector is collected from the multi-step execution process of API call chains, RPA automation processes, or tool call chains.
8. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The resource constraint correction module, the error propagation suppression module, and the stability projection module process the candidate execution actions in a fixed order to form a pre-execution control chain that connects the runtime state vector, the error propagation graph, the candidate actions, the resource constraint correction, the error propagation suppression, the stability projection, and the final action or control action.
9. The error propagation graph-driven pre-execution control system according to claim 1, characterized in that: The data recorded by the structured control trajectory recording module is used for offline audit playback and offline configuration review; The data includes at least candidate action identifiers, final action identifiers, execution timestamps, error propagation graph structure hash values, decision reasons for each operator, and reasons for triggering control actions.
10. A method for error propagation graph-driven pre-execution control, characterized in that, Includes the following steps: S1: Collect the runtime state vector of the current execution step. The runtime state vector includes at least API status, error code, retry count, resource consumption, execution delay, and action dependencies. S2: Based on the action dependencies, API status, error codes, and retry counts, construct or update the error propagation graph, which includes action nodes, node risk values, action dependency edges, and edge weights. S3: Receive candidate actions to execute; S4: Perform resource constraint correction on the candidate execution action according to the preset resource threshold to obtain the resource correction action; S5: Based on the node risk value, edge weight cumulative value and propagation depth in the error propagation graph, perform error propagation suppression on the resource correction action to obtain the error suppression action; S6: Calculate the stability value based on the resource consumption, execution latency, graph risk, node risk, and retry count in the current runtime state vector, and perform stability projection on the error suppression action based on the stability value; S7: Based on the stability projection results, output the final execution action, or trigger at least one of the following control actions: circuit breaking, degradation, or manual confirmation; S8: Record candidate actions, final actions, current state, error propagation graph, operator decisions and control reasons to form a structured control trajectory.