Dynamic Fault Perception and Risk Propagation Prediction Methods for Agent Workflow

Abstract

This invention relates to a dynamic fault perception and risk propagation prediction method for intelligent agent workflows, belonging to the field of artificial intelligence. It includes: constructing a dynamic dependency graph based on the target workflow; for each tool node, an input / output trusted auditor verifies the workflow through a format compliance layer, an execution state layer, and a semantic consistency layer; if all verifications pass, execution continues; if any layer fails verification, a structured fault information report is returned, and the severity and data sensitivity weights of the error are determined; for downstream nodes of the tool node that failed verification, risk propagation prediction models based on the dynamic dependency graph are used for control. This invention can promptly intercept initial faults, preventing them from causing cascading propagation and amplification effects in complex workflows; it changes the paradigm of error handling in intelligent agent tool workflows, shifting it from reactive, post-event emergency response to precise, in-process control, thus enhancing the robustness and reliability of complex workflows.

Description

Technical Field

[0001] This invention relates to a dynamic fault perception and risk propagation prediction method for intelligent agent workflow, belonging to the field of artificial intelligence technology. Background Technology

[0002] The rapid advancement of large language models has spurred the rise of intelligent agents based on these models. Artificial intelligence is transitioning from a cognitive intelligence stage focused on dialogue and question answering to a new era of action intelligence capable of proactively utilizing tools and executing real-world tasks. By autonomously perceiving the environment, planning and making decisions, and invoking a range of external tools, intelligent agents can orchestrate multi-step workflows to achieve complex goals, accomplishing tasks that are difficult for static models to perform, such as integrating and generating data files and automating dynamic business processes. The tool-invoking capability of intelligent agents is a key support for expanding their capabilities and achieving action intelligence, demonstrating enormous application potential in numerous fields such as automated office work, intelligent customer service, and scientific computing. It is considered one of the key paths to achieving general artificial intelligence, characterized by human-level cross-domain adaptability, autonomous problem-solving capabilities for complex tasks, and the ability to interact with the real world.

[0003] However, the ideal smooth and autonomous intelligent agent workflow faces severe reliability and security challenges in real-world applications. While the ability to invoke tools grants agents greater autonomy, it also introduces more risks. Failures or errors frequently occur during the tool invocation phase, potentially stemming from multiple levels, including cognitive biases within the agent itself, tool unreliability, and external environmental instability. Errors arising during the tool invocation phase can be categorized into four types: tool illusion errors, input specification errors, output processing errors, and tool execution errors. Tool illusion errors refer to invoking a non-existent, fictitious tool. Input specification errors mainly include missing parameters and mismatched parameter types and values. Output processing errors primarily include empty output, incomplete output data formats, and output data formats that are complete but invalid or falsified. Tool execution errors mainly include timeouts, network connectivity issues, permission or authentication problems, and internal server errors.

[0004] The orchestration of multiple tools into a workflow by an intelligent agent is a typical sequential decision-making process. Workflows themselves are inherently fragile; faults or errors within them can easily trigger a cascading error effect. Even a small output deviation from a single tool node in the workflow, due to information cascading effects and echo chamber effects caused by dependencies between tool nodes, can be amplified step-by-step during data transmission and processing in subsequent tools, ultimately leading to the failure of the entire toolchain or completely erroneous conclusions. Currently, dynamic monitoring is essentially still a passive response, unable to prevent the cascading propagation of errors in real time.

[0005] Furthermore, the intelligent agent workflow is a dynamic collaborative process. Vulnerabilities in any link, such as process design flaws, component interaction vulnerabilities, and external dependency risks, can be amplified due to the autonomy of the intelligent agent and the interconnectedness of tools. This can lead to security risks ranging from data leaks and abuse of privileges to even physical world risks, severely restricting the practical deployment of intelligent agents in high-reliability scenarios such as finance and healthcare. For dynamic collaborative processes, the workflow structure may evolve in real time, which existing static analysis models cannot handle. They cannot predict the scope of risk spread or assess the severity of its business impact. This results in a lack of holistic perspective for remediation modules or maintenance personnel, leaving them in a state of blindness, only able to respond passively, and unable to make forward-looking and accurate fault-tolerant decisions.

[0006] In addressing faults or errors in intelligent agent workflows, existing static methods based on rule-based retries or manual presets lack flexibility and struggle to cover complex and dynamic fault scenarios. Utilizing the powerful contextual understanding capabilities of large language models to judge the rationality and consistency of tool responses incurs high computational costs and unacceptable response delays due to the large number of model parameters, failing to meet the stringent real-time requirements of industrial scenarios. Retrieval-driven diagnostic methods, such as PALADIN, allow intelligent agents to perform accurate diagnoses through error feature matching and mapping to the ToolScan classification system. Their diagnostic process is efficient and reliable, less prone to misjudgments, and meets the high reliability deployment requirements of complex workflows. However, their effectiveness heavily depends on the size and quality of the retrieval database, and their generalization ability drops sharply when facing unknown tools or novel errors. Furthermore, current research largely focuses on system-level fault diagnosis, lacking the ability for real-time, fine-grained diagnosis and precise blocking during workflow execution—crucial for preventing a single fault from escalating into a cascading disaster. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a dynamic fault perception and risk propagation prediction method for intelligent agent workflows. This method can promptly intercept initial faults or errors, preventing them from triggering cascading propagation and amplification effects in complex workflows. It achieves dynamic quantitative prediction of fault impacts and precise circuit breaking based on risk quantification, avoiding unnecessary task interruptions. This fundamentally changes the paradigm of error handling in intelligent agent toolflows, transforming it from reactive, post-event emergency response to precise in-process control, thus enhancing the robustness and reliability of complex workflows.

[0008] The technical solution of the present invention is as follows:

[0009] A dynamic fault perception and risk propagation prediction method for intelligent agent workflow includes the following steps:

[0010] S1, the intelligent agent plans the target workflow according to the user's instructions, constructs a dynamic dependency graph based on the planned target workflow, and obtains multiple tool nodes and tool node attributes;

[0011] S2, for each tool node, the Input-Output Credible Auditor (IOCA) adopts a layered verification architecture, which verifies the workflow through a format compliance layer, an execution status layer, and a semantic consistency layer. Only when all verifications pass can the tool be executed and the output data flow into the next tool node to continue executing the workflow.

[0012] If any of the format compliance layer, execution status layer, or semantic consistency layer fails validation, the system will block and return a structured report of fault information, and determine the error severity weight and data sensitivity weight based on the error type.

[0013] S3 targets downstream nodes of tool nodes that failed verification in S2, and manages them using a risk propagation prediction model based on a dynamic dependency graph. It calculates the risk propagation probability to block high-risk paths and suppress the cascading propagation of errors.

[0014] Preferably, in step S1, a dynamic dependency graph is constructed using a mechanism that combines "static skeleton and dynamic injection". First, a global static topology skeleton is pre-constructed based on the target workflow to clarify all tools and the potential data flow between tools.

[0015] Then, each tool in the workflow is abstracted as a node, and the node attributes cover five indicators: tool number and name, execution time, tool status, tool execution status, and number of retries; data dependencies are abstracted as edges, and the edge attribute information includes two indicators: the specific data item dependency relationship between adjacent tools and the causal strength.

[0016] As the intelligent agent workflow is executed, the execution status of the tool is dynamically observed through lightweight instrumentation technology, the start and end times of the tool call are obtained, and the execution time of the tool is calculated.

[0017] Preferably, the tool execution status is a binary random variable, where 1 represents allowed execution and 0 represents blocked execution. The initial status of all tool nodes is 1 by default. The retry count refers to the number of times the tool node attempts to re-execute after a failure, which is used to assist in the formulation of repair strategies. The initial retry count of all tool nodes is 0 by default, and the retry count cannot exceed the set maximum number of attempts.

[0018] Preferably, in step S2, the format compliance layer performs format review on the data flowing into the tool node and the data output by the tool node, filtering out tool illusion errors, missing parameter errors, incorrect parameter key names, and incorrect parameter value types. If the verification fails, the corresponding error type is returned.

[0019] The execution state layer is responsible for verifying the execution status of tool calls and promptly detecting timeout errors, network connection errors, permission or authentication issues, and internal server errors during tool execution.

[0020] The semantic consistency layer is responsible for deeply validating the validity and relevance of the tool's output data. It employs an INT8-quantized Sentence-BERT model, first abstracting semantic templates from the tool documentation and historical correct outputs. Then, it dynamically evaluates semantic validity by calculating the cosine similarity between the output content and the semantic template. If the cosine similarity exceeds a threshold... If the cosine similarity is less than or equal to the threshold, then the output semantics are considered valid. If the output is invalid, the output is intercepted and an error type is returned indicating that the output data format is complete but the content is invalid.

[0021] Preferably, the execution state layer employs two complementary detection methods: active detection based on execution state and passive detection based on error information.

[0022] Active detection proactively blocks abnormal states through a sliding window-based adaptive statistical circuit breaker mechanism and resource silent analysis techniques. The sliding window-based adaptive statistical circuit breaker mechanism aims to detect hidden timeouts caused by slow tool execution. First, it utilizes tool execution time metrics accumulated in the dynamic dependency graph, maintaining a length of... Historical execution time sliding window Before the tool is executed, the maximum tolerance time threshold is dynamically calculated based on the statistical distribution within the window, according to Chebyshev's inequality. :

[0023]

[0024] in, , represents the average execution time within the window. , where is the standard deviation. Let be the confidence coefficient, and take . It is 3;

[0025] When the actual execution time of the tool exceeds the maximum tolerable time threshold. When the timeout occurs, the system determines that the circuit breaker has been triggered.

[0026] Resource silent analysis technology aims to detect timeout errors and network connection errors caused by tool deadlocks, infinite loops, or network black holes. It directly reads kernel-level status indicators such as CPU time slice count and network interface counters of tool processes or containers through the resource silent analyzer.

[0027] Determining resource quiescence requires calculating network throughput and CPU volatility, and can only be done within the observation window. The tool will only be deemed to have lost its runtime activity and its process will be forcibly terminated when the internal monitoring detects that both network throughput and CPU volatility meet the quiescent conditions.

[0028] Preferably, network throughput is defined as the total traffic increment within the observation window, and the calculation formula is:

[0029]

[0030] in, Indicates the first The cumulative number of bytes received from the kernel at each sampling time; This represents the cumulative number of bytes received from the kernel at the first sampling time; Indicates the first The cumulative number of bytes sent read from the kernel at each sampling time; This represents the cumulative number of bytes sent from the kernel at the first sampling time; This represents the total number of samples within the observation window. The total number of bytes received during the entire window period. The total number of bytes sent during the entire window period;

[0031] Set network silence threshold ,like This indicates that in Internally, the tool hardly exchanges data with the outside world, which meets the characteristics of "network silence" and is therefore determined to be network silent.

[0032] The calculation process for CPU volatility is as follows:

[0033] First calculate the... A sample of instantaneous CPU load :

[0034]

[0035] in, To extract the number of CPU time slices in the 1st month Cumulative CPU time of the process during each sampling. Sampling time, The sampling interval is the time difference between two adjacent samples. ;

[0036] Then, the statistical variance of the payload sample sequence within the window is calculated. Quantifying CPU volatility:

[0037]

[0038] express The average value;

[0039] Set variance threshold ,like This indicates that the process is in a constant deadlock or constant infinite loop state.

[0040] Preferably, passive detection aims to detect server errors, explicit network connection errors, explicit timeout errors, and permission or authentication errors during tool execution. Passive detection parses the HTTP response headers, response bodies, and the underlying exception stack (a detailed call sequence record reflecting the program's error context) in the standard error stream (stderr) returned by the tool. It utilizes a pre-built multi-dimensional error pattern library to attribute faults. This multi-dimensional error pattern library contains three types of mapping rules: first, status code mapping rules, which operate at the protocol communication layer, determining the connectivity and protocol status between the tool node and the gateway or server by parsing the RFC standard status codes in the HTTP response header; second, structured error code rules, which operate at the business logic layer, used to parse business-level error fields hidden in the HTTP response body data packets, identifying critical scenarios where the protocol succeeds but the business fails. Under the premise that the response status code is normal, it accurately determines specific business logic violations or missing dynamic permissions by matching custom logical error codes in the response body; and third, exception keyword regular expression rules, which operate at the system runtime layer, by analyzing the underlying exception stack (stderr) in the standard error stream. Trace performs text feature matching to identify root cause features such as "Connection refused" or "Memory dump" that reflect physical links, memory overflows, or program crashes, enabling the diagnosis of sudden hardware and software failures.

[0041] Preferably, the input / output trusted auditor maintains a predefined error severity mapping table, and the error severity weight is obtained by directly indexing the error severity mapping table according to the error type code;

[0042] The construction logic of the error severity mapping table is driven by historical data. Through in-depth mining of the historical execution logs of the intelligent agent platform, the statistical correlation between specific errors and final task failure is statistically calculated to establish a conditional failure probability model; and error subclasses are statistically classified based on historical data. The total number of occurrences is The number of times this error directly or indirectly caused the task to ultimately fail was [number missing]. Subclassing errors Corresponding task failure rate error subclass As a weight for error severity, The calculation formula is:

[0043] ;

[0044] The error severity weight ranges from [0,1], where 0 represents no risk and 1 represents the highest risk.

[0045] Preferably, the determination of data sensitivity weight adopts a combination of metadata feature extraction and keyword mapping table indexing. First, the transmitted data types are divided into three categories: security and privacy, decision logic, and general information. A "keyword-category" mapping table is constructed, and a corresponding sensitivity score is assigned to each category. Then, metadata features are extracted from the currently transmitted data. Based on the preset "keyword-category" mapping table, the metadata features are matched to automatically map the metadata features to the corresponding categories and return the preset sensitivity score of the data in that category, thus obtaining the data sensitivity weight.

[0046] In this invention, the sensitivity scores assigned to categories are generally preset based on national authoritative standards and actual needs, such as GB / T 35273 "Information Security Technology - Personal Information Security Specification" and GB / T 43697 "Data Security Technology - Data Classification and Grading Rules", and sensitivity scores are assigned in combination with business impact dimensions.

[0047] The data sensitivity weight ranges from [0,1], where 0 represents normal data and 1 represents the highest data sensitivity.

[0048] If the tool is not executed, the data sensitivity weights on its data-dependent edges are defaulted to 0. If the tool has already executed, different errors will cause the tool to be blocked at different times. If the erroneous tool does not produce output data, since the risk level of the tool execution is strongly correlated with the sensitivity of the input data it processes, this method, based on the principles of sensitivity propagation and data flow causality, assigns sensitivity weights to the input data. The data sensitivity weight is directly assigned to the current error event. ,Right now ;

[0049] If the faulty tool has already generated output data, the determination of data sensitivity weights is mainly based on the data transmission along the edges between the two tool nodes in the Dynamic Dependency Graph (DDG). When a single edge involves multiple data transmissions, to accurately reflect the highest risk boundary of data transmission and avoid diluting high-risk signals with low-sensitivity data, the Maximum Risk Inheritance Strategy is used to aggregate the weights, as follows:

[0050] First, based on the keyword mapping table, the n independent data items in the transmitted content are scanned, and each item is assigned an independent data sensitivity score. Then, the maximum value among them is selected as the final data sensitivity weight of the dependent edge. :

[0051]

[0052] The maximum risk inheritance strategy ensures the non-decrease transmission of risk signals, achieving Pareto optimality while balancing computational efficiency and security.

[0053] Preferably, in step S3, the risk propagation prediction model is a probabilistic inference based on a dynamic Bayesian network, which is a continuously optimized set of conditional probability tables that quantifies the fault propagation relationship between nodes.

[0054] First, the dynamic dependency graph is modeled as a dynamic Bayesian network, which is a directed acyclic graph (DAG), represented as pairs. , where the vertex set , representing the toolchain A set of tool nodes and directed edges. This represents the data dependencies between tools, i.e. The input depends on The output of each tool node; It is a binary random variable representing the instrument state. :

[0055]

[0056] The default value for the tool state is 0. The core of the risk propagation prediction model is the conditional probability distribution of each node under all combinations of parent node values. It quantifies the strength of the influence of the child node tool on its parent node tool group in the form of a conditional probability table (CPT). Parent nodes refer to all nodes that are directly pointed to by directed edges. For a node that has The utility node of the parent node Parent node set pa( ) ;

[0057] Tool Node The prior error probability is:

[0058]

[0059] Tool Node The base posterior error probability is:

[0060]

[0061] in, Indicates the parent node child nodes The causal strength is expressed as:

[0062]

[0063] child node From the parent node The number of input data items received. It is a child node The total number of input data items;

[0064] Risk transmission probability The calculation formula is:

[0065]

[0066] in, parent node The error severity weight is set to 0 by default for all unexecuted tool nodes in the dynamic dependency graph, to facilitate the handling of non-directly downstream tool nodes of failed tool nodes. Update calculation; parent node Transmit to child nodes Data sensitivity weights;

[0067] When the probability of risk propagation across all downstream nodes After the update is complete, the calculated With risk threshold Perform real-time comparison, if Less than If the risk of the tool node is deemed controllable, it can be executed normally; Greater than or equal to If a path is identified as high-risk, and the tool node is likely to encounter serious errors if it continues to execute, the tool node should be immediately stopped from continuing execution, and its tool execution status should be changed to 0 to prevent the error from spreading in the workflow.

[0068] For any details not covered in this invention, please refer to the prior art.

[0069] The beneficial effects of this invention are as follows:

[0070] 1. In the workflow of this invention, the input and output data of each tool and the execution of the tool are quickly detected by the Input / Output Trusted Auditor (IOCA). The detection time is in the millisecond range, which is close to imperceptible. IOCA can accurately detect tool illusion errors, input specification errors, output processing errors, and tool execution errors, and promptly intercept initial faults to prevent them from causing cascading propagation and amplification effects in complex workflows. This keeps problems in the nascent stage, avoids local errors from evolving into global failures, and ensures the reliability of workflow execution.

[0071] 2. This method transcends the limitations of traditional static analysis, achieving dynamic quantitative prediction of fault impact and precise circuit breaking based on risk quantification, thus avoiding unnecessary task interruptions. By abstracting the real-time workflow into a dynamic dependency graph, this mechanism can characterize and deduce the risk propagation path and intensity of faults within the workflow, providing a global visual perspective on fault impact and offering precise data support for subsequent decision-making. Compared to the traditional coarse "stop upon encountering an error" approach, this invention only applies circuit breaking to high-risk paths, without interfering with the execution of low-risk paths. This differentiated control strategy maintains business continuity to the greatest extent possible while ensuring system security.

[0072] 3. The execution state layer of this invention solves the cold start and adaptive challenges of massive tool access, abandons the high-cost solution of manually configuring thresholds, and utilizes global statistical inheritance and sliding window self-evolution mechanism to enable the system to automatically adapt to the entire life cycle from "new access" to "mature operation", and can also automatically adapt to performance jitter caused by network fluctuations or load changes, which greatly reduces the operation and maintenance costs and access threshold of the intelligent agent platform.

[0073] 4. The method of this invention enables the entire intelligent agent to acquire risk situational awareness capabilities, transforming the agent from a passive fault response to a proactive, preventative system capable of anticipating risks and assessing their impact. This means that faults can be located and their propagation blocked before downstream tool nodes become contaminated or a single tool failure leads to overall task failure, effectively preventing the escalation of fault complexity. This helps reduce the complexity and time consumption of fault diagnosis and recovery, improving the operational efficiency of the intelligent agent workflow. This invention fundamentally changes the paradigm of error handling in intelligent agent toolflows, shifting it from reactive, post-event emergency response to precise, real-time control, enhancing the robustness and reliability of complex workflows. Attached Figure Description

[0074] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0075] Figure 1This is a schematic diagram illustrating the construction process of the dynamic dependency graph in this invention;

[0076] Figure 2 This is a schematic diagram of the passive detection process of the present invention;

[0077] Figure 3 This is a schematic diagram of the execution flow of the input / output trusted auditor of the present invention;

[0078] Figure 4 This is a schematic diagram of the overall framework of the dynamic fault perception and risk propagation prediction method for intelligent agent workflow of the present invention. Detailed Implementation

[0079] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. However, this is not the only description; all aspects not described in detail herein are based on conventional techniques in the art.

[0080] Example 1

[0081] A dynamic fault perception and risk propagation prediction method for intelligent agent workflow, such as Figure 4 As shown, it includes the following steps:

[0082] S1, the working process of the intelligent agent follows a closed loop of perception, thinking, action and feedback. First, it perceives environmental and task information, then forms a completion plan and next decision through reasoning, then calls up tools to execute corresponding actions, and then evaluates whether the goal has been achieved based on the feedback results, and adjusts the strategy accordingly to continue reasoning, continuously repeating this process until the task is completed.

[0083] First, the agent plans the target workflow according to the user's instructions, and constructs a dynamic dependency graph (DDG) based on the planned target workflow, obtaining multiple tool nodes and tool node attributes;

[0084] S2, for each tool node, the input and output trusted auditor adopts a layered verification architecture, which verifies the workflow through a format compliance layer, an execution status layer and a semantic consistency layer. Only when all verifications pass can the tool be executed and the output data flow into the next tool node to continue executing the workflow.

[0085] If any of the format compliance layer, execution status layer, or semantic consistency layer fails validation, the system will block and return a structured report of fault information, and determine the error severity weight and data sensitivity weight based on the error type.

[0086] S3 targets downstream nodes of tool nodes that failed verification in S2, and manages them using a risk propagation prediction model based on a dynamic dependency graph. It calculates the risk propagation probability to block high-risk paths and suppress the cascading propagation of errors.

[0087] Example 2

[0088] A dynamic fault perception and risk propagation prediction method for intelligent agent workflow, as described in Example 1, differs in that, in step S1, a mechanism combining "static skeleton and dynamic injection" is used to construct a dynamic dependency graph, such as... Figure 1 As shown, a global static topology skeleton is first pre-built based on the target workflow to clarify all tools and the potential data flow between tools, laying the foundation for full-link dependency analysis;

[0089] Then, each tool in the workflow is abstracted as a node, and the node attributes cover five indicators: tool number and name, execution time, tool status, tool execution status, and number of retries; data dependencies are abstracted as edges, and the edge attribute information includes two indicators: the specific data item dependency relationship between adjacent tools and the causal strength.

[0090] As the intelligent agent workflow executes, lightweight instrumentation technology dynamically observes the tool's execution state, injecting rich dynamic context into the static skeleton. This aims to construct and maintain a hybrid dynamic attribute graph that deeply reflects the workflow's runtime state. During tool execution, lightweight observation code is inserted at key locations in the tool's code to obtain the tool's start and end times, calculate execution time, and update the execution time metrics of nodes in the DDG. After IOCA validation of the tool, the tool state metrics in the tool's node attributes and the data sensitivity metrics in its edge attributes are updated based on the IOCA's determination.

[0091] The tool execution status is a binary random variable, where 1 represents allowed execution and 0 represents blocked execution. The initial status of all tool nodes is 1 by default. The retry count refers to the number of times the tool node attempts to re-execute after a failure, which is used to assist in the formulation of repair strategies. The initial retry count of all tool nodes is 0 by default, and the retry count cannot exceed the set maximum number of attempts.

[0092] Example 3

[0093] A dynamic fault perception and risk propagation prediction method for intelligent agent workflows, as described in Example 2, differs in that, in step S2, the format compliance layer performs format review on the data flowing into and outputting from the tool nodes, filtering out tool illusion errors, missing parameter errors, incorrect parameter key names, and incorrect parameter value types. If the verification fails, the corresponding error type is returned. The tool documentation, serving as a standard specification for intelligent agent tool calls, defines function interfaces, functional descriptions, input and return parameter types and descriptions in a structured form, providing a static benchmark for verifying actual parameters. The format compliance layer extracts tool descriptions and parameter specifications from the tool documentation and substitutes them into a pre-compiled rule network. The rule network is a series of executable, low-level, and efficient native codes responsible for determining whether real data conforms to the specifications in the tool documentation. It sequentially verifies the authenticity of the tool, the existence of input and output parameters, key names, and formats. If the verification fails, the corresponding fault type is returned. This not only speeds up rule verification execution but also avoids runtime interpretation overhead.

[0094] The execution state layer is responsible for verifying the execution status of tool calls and promptly detecting timeout errors, network connection errors, permission or authentication issues, and internal server errors during tool execution.

[0095] The semantic consistency layer performs semantic validation on the data output by tool nodes to prevent output data from being formatted correctly but containing false or invalid content. The semantic consistency layer is responsible for deeply validating the validity and relevance of the tool's output data. It employs an INT8-quantized Sentence-BERT model, first abstracting semantic templates from the tool documentation and historical correct outputs, and then dynamically evaluating semantic validity by calculating the cosine similarity between the output content and the semantic template. The specific steps for calculating the cosine similarity include: after the tool is executed, first converting the tool's output data and the predefined semantic template into semantic vectors respectively. , Then calculate the cosine similarity. :

[0096]

[0097] After the calculation is completed, With preset dynamic threshold The threshold is compared to determine whether to block the attack. Based on statistical analysis of the dataset, it was determined that by collecting a large number of correct tool outputs and tool illusion outputs, calculating the similarity distribution between these samples and their corresponding templates, and selecting the similarity score that maximizes classification accuracy as the initial threshold. .

[0098] If cosine similarity Greater than the threshold If the cosine similarity is less than or equal to the threshold, then the output semantics are considered valid. If the output is invalid, the output is intercepted and an error type is returned indicating that the output data format is complete but the content is invalid.

[0099] like Figure 3 As shown, only when all verifications pass can the tool execute, allowing output data to flow into the next tool node and continue the workflow. If verification fails, the faulty tool node is immediately blocked from execution. The Input / Output Trusted Auditor (IOCA) returns a structured report of the fault information to the exception handling module, which determines the error severity weight and data sensitivity weight based on the error type, changes the tool state and execution state, and then updates the risk propagation prediction model to the risk probability of downstream tool nodes, blocking downstream paths affected by the faulty tool. The structured report of the fault information includes the error type, specific error data items, and the cause. The core design of IOCA is to quickly block and repair most simple formatting and semantic errors while ensuring low latency and effectiveness, preventing simple errors from spreading and amplifying in the workflow, causing adverse effects.

[0100] Example 4

[0101] A dynamic fault perception and risk propagation prediction method for intelligent agent workflow, as described in Example 2, differs in that, to fully ensure the robustness of the system, the execution state layer adopts two complementary detection methods: active detection based on execution state and passive detection based on error information. Active detection addresses implicit, unresponsive errors during tool execution, while passive detection addresses explicit, reported errors. This dual detection mechanism can comprehensively capture various anomalies during tool execution, providing reliable runtime fault detection capabilities for the intelligent agent system.

[0102] Active detection achieves proactive blocking of abnormal states through an adaptive statistical circuit breaker mechanism based on sliding windows and resource silent analysis technology. The adaptive statistical circuit breaker mechanism based on sliding windows aims to detect hidden timeout problems caused by slow tool execution. The fixed timeout thresholds widely used in existing technologies are difficult to adapt to the time consumption differences of different intelligent agents and tools under different input levels and network environments, which can easily lead to false circuit breakers when processing large tasks or response delays when processing small tasks.

[0103] The proactive detection process is as follows: First, use the tools accumulated in the dynamic dependency graph to perform time metrics, and maintain a length of [value missing]. Historical execution time sliding window Before the tool is executed, the maximum tolerance time threshold is dynamically calculated based on the statistical distribution within the window, according to Chebyshev's inequality. To prevent tool performance degradation from slowing down the efficiency of the entire workflow:

[0104]

[0105] in, , represents the average execution time within the window. , where is the standard deviation. Let be the confidence coefficient, and take . It is 3;

[0106] When the actual execution time of the tool exceeds the maximum tolerable time threshold. When the timeout occurs, the system determines that the circuit breaker has been triggered.

[0107] Resource silent analysis technology aims to detect timeout errors and network connectivity errors caused by tool deadlocks, infinite loops, or network black holes. The resource silent analyzer is a lightweight, non-intrusive kernel-level observation module embedded in the execution state layer. It adopts out-of-band management, injecting no code into the tool process and not relying on the tool's own log output. The resource silent analyzer directly reads kernel-level status metrics such as CPU time accounting and network interface counts from the tool process or container.

[0108] Determining resource quiescence requires calculating network throughput and CPU volatility, and can only be done within the observation window. The tool is only deemed to have lost its running activity and its process is forcibly terminated when the internal monitoring detects that both network throughput and CPU volatility meet the quiescent conditions, effectively avoiding the risk of indefinite blocking.

[0109] Network throughput is defined as the observation window The total flow increment within is calculated using the following formula:

[0110]

[0111] in, Indicates the first The cumulative number of bytes received from the kernel at each sampling time; This represents the cumulative number of bytes received from the kernel at the first sampling time; Indicates the first The cumulative number of bytes sent read from the kernel at each sampling time; This represents the cumulative number of bytes sent from the kernel at the first sampling time; This represents the total number of samples within the observation window. The total number of bytes received during the entire window period. The total number of bytes sent during the entire window period;

[0112] Set network silence threshold Its value should be greater than the minimum heartbeat packet traffic required by the operating system or container environment to maintain the connection, in order to filter out non-business data interference at the protocol level.

[0113] like This indicates that in Internally, the tool hardly exchanges data with the outside world, which meets the characteristics of "network silence" and is therefore determined to be network silent.

[0114] The calculation process for CPU volatility is as follows:

[0115] To extract the number of CPU time slices in the 1st month Cumulative CPU time of the process during each sampling. Sampling time, The sampling interval is the time difference between two adjacent samples. ;because It is a cumulative amount, therefore it needs to be converted into an instantaneous load sample, the first... A sample of instantaneous CPU load The calculation formula is:

[0116]

[0117] Calculate the statistical variance of the payload sample sequence within the window. Quantifying CPU volatility:

[0118]

[0119] express The average value;

[0120] Set variance threshold , The variance threshold is close to zero. This threshold is used to tolerate minor load fluctuations caused by process scheduling, ensuring that a decision is triggered only when the process load is constant (constant deadlock or constant full load).

[0121] like This indicates that the process is in a constant deadlock or constant infinite loop state.

[0122] Example 5

[0123] A dynamic fault perception and risk propagation prediction method for intelligent agent workflows, as described in Example 4, differs in that passive detection aims to detect server errors, explicit network connection errors, explicit timeout errors, and permission or authentication errors during tool execution. Server errors refer to execution interruptions caused by abnormal backend logic, resource exhaustion, or program crashes. Explicit network connection errors refer to communication failures caused by physical link interruptions, unreachable target addresses, or connection denials. Explicit timeout errors refer to explicit timeout signals returned by the gateway or server when the execution time exceeds a preset threshold. Permission or authentication errors refer to security policy interceptions caused by invalid identity credentials, expired authorization tokens, or insufficient access scope during tool invocation.

[0124] Unlike proactive detection mechanisms that focus on implicit, unresponsive states, passive detection mechanisms aim to accurately identify and classify explicit faults explicitly returned by the tool. Passive detection parses the HTTP response headers, response bodies, and underlying exception stacks (Stack Trace, a detailed call sequence record reflecting the program's error context) in the standard error stream (stderr) returned by the tool. It utilizes a pre-built multidimensional error mode library to attribute faults. The multidimensional error mode library contains three types of mapping rules, enabling full-dimensional perception of workflow anomalies from communication protocols to business logic and the system's underlying layers: First, status code mapping rules, which operate at the protocol communication layer. By parsing the RFC standard status codes in the HTTP response header, it determines the connectivity and protocol status between the tool node and the gateway or server. The protocol communication layer only reflects the availability of communication links and basic services. Its advantage lies in its high identification efficiency, capable of quickly capturing link-level explicit interception signals such as 401 (Unauthorized) and 504 (Timeout).

[0125] Second, there are structured error code rules, which operate at the business logic layer and aim to compensate for the lack of insight into the business logic at the protocol layer. They are used to parse business-level error fields hidden in the HTTP response body data packets, identify critical scenarios where the protocol succeeds but the business fails, and accurately determine specific business logic violations or missing dynamic permissions by matching the custom logical error codes in the response body, provided that the response status code is normal.

[0126] Thirdly, there are exception keyword regular expression rules, which operate at the system runtime layer and focus on capturing unstructured error information thrown by the system's underlying layer. By matching the text features of the underlying exception stack (Stack Trace) in the standard error stream, they identify root cause features such as "Connection refused" or "Memory dump" that reflect physical links, memory overflows, or program crashes, thereby enabling the diagnosis of sudden software and hardware failures.

[0127] like Figure 2As shown, when the tool call ends and returns a non-200 status or throws a runtime exception, the passive detection module executes a hierarchical detection process: First, if the execution status layer captures any of the following signals in real time from the underlying Socket logs and system call exceptions, it directly locks in an explicit network connection error: 1. TCP three-way handshake failure; 2. TCP connection reset by the peer; 3. DNS resolution failure; 4. Network unreachable; 5. Connection refused. If communication is successfully established and a response is returned, protocol layer parsing is performed. The system prioritizes reading the status code in the HTTP response header. If a status code such as 500, 503, 505, 507, or 510 is hit, it is locked in as a server error; if a status code such as 408 or 504 is hit, it is locked in as an explicit timeout error; and if a status code such as 401, 403, 429, or 511 is hit, it is locked in as a permission or authentication error. If the status code is a non-standard code with semantic ambiguity, such as 502, 530, or 598, and the fault type cannot be clearly determined, the system then enters the content layer deep scanning stage. This stage performs structured error code rule matching on the response body and simultaneously scans the underlying exception stack in the standard error stream using exception keyword regular expressions. If clear characteristics such as "Connection refused," "Socket closed," or "Network is unreachable" appear, it is identified as an explicit network connection error. If a specific credential expiration mode appears, it is identified as an authorization expiration signal. Finally, multi-dimensional arbitration is performed. If multiple characteristics are matched simultaneously in the above steps, the system follows the underlying priority principle, prioritizing physical link causes over application layer manifestations. The system first identifies explicit network connection errors, then explicit timeout errors, then authorization or authentication errors involving security and access policy barriers, and finally server errors.

[0128] Example 6

[0129] A dynamic fault perception and risk propagation prediction method for intelligent agent workflows, as described in Example 5, differs in that when IOCA detects a fault, it needs to calculate the error severity weight and data sensitivity weight. The error severity weight is 0 by default when the tool is not executed. The error sensitivity weight is determined based on the type of error that occurred. The input / output trusted auditor maintains a predefined error severity mapping table, and the error severity weight is obtained by directly indexing the error severity mapping table according to the error type code.

[0130] The construction of the fault severity mapping table mainly revolves around four common faults: tool illusion error, input specification error, output processing error, and tool execution error, as shown in Table 1 below. A modeling method based on the deep integration of historical data correlation analysis and business scenario reliability requirements is adopted to ensure the objectivity and dynamic adaptability of weight evaluation.

[0131] Table 1 Specific Error Types

[0132]

[0133] The construction logic of the error severity mapping table is driven by historical data. Through in-depth mining of the historical execution logs of the intelligent agent platform, the statistical correlation between specific errors and final task failure is statistically calculated to establish a conditional failure probability model; and error subclasses are statistically classified based on historical data. The total number of occurrences is The number of times this error directly or indirectly caused the task to ultimately fail was [number missing]. Subclassing errors Corresponding task failure rate error subclass As a weight for error severity, The calculation formula is:

[0134] ;

[0135] The error severity weight ranges from [0,1], where 0 represents no risk and 1 represents the highest risk.

[0136] Preferably, the data sensitivity weight aims to quantify the security risks and business logic weights of the data transmitted by each dependent edge in DDG. Its determination adopts a combination of metadata feature extraction and keyword mapping table indexing. The core logic is to assess potential risks by identifying the type attributes of the data.

[0137] First, the transmitted data types are divided into three categories: security and privacy, decision logic, and general information. A keyword-category mapping table is constructed, and each category is assigned a corresponding sensitivity score. Then, metadata features are extracted from the transmitted data. Based on the preset keyword-category mapping table, the metadata features are matched to automatically map the metadata features to the corresponding categories and return the preset sensitivity score of the data in that category, thus obtaining the data sensitivity weight.

[0138] In this invention, the sensitivity scores assigned to categories are generally preset based on national authoritative standards and actual needs, such as GB / T 35273 "Information Security Technology - Personal Information Security Specification" and GB / T 43697 "Data Security Technology - Data Classification and Grading Rules", and sensitivity scores are assigned in combination with business impact dimensions.

[0139] The data sensitivity weight ranges from [0,1], where 0 represents normal data and 1 represents the highest data sensitivity.

[0140] If the tool is not executed, the data sensitivity weights on its data-dependent edges are defaulted to 0. If the tool has already executed, different errors will cause the tool to be blocked at different times. If the erroneous tool does not produce output data, since the risk level of the tool execution is strongly correlated with the sensitivity of the input data it processes, this method, based on the principles of sensitivity propagation and data flow causality, assigns sensitivity weights to the input data. The data sensitivity weight is directly assigned to the current error event. ,Right now ;

[0141] If the faulty tool has already generated output data, the determination of data sensitivity weights is mainly based on the data transmission along the edges between the two tool nodes in the Dynamic Dependency Graph (DDG). When a single edge involves multiple data transmissions, to accurately reflect the highest risk boundary of data transmission and avoid diluting high-risk signals with low-sensitivity data, the Maximum Risk Inheritance Strategy is used to aggregate the weights, as follows:

[0142] First, based on the keyword mapping table, the n independent data items in the transmitted content are scanned, and each item is assigned an independent data sensitivity score. Then, the maximum value among them is selected as the final data sensitivity weight of the dependent edge. :

[0143]

[0144] The maximum risk inheritance strategy ensures the non-decrease transmission of risk signals, achieving Pareto optimality while balancing computational efficiency and security.

[0145] Example 7

[0146] A dynamic fault perception and risk propagation prediction method for intelligent agent workflow, as described in Example 6, differs in that, in step S3, the risk propagation prediction model is based on the inter-tool dependency relationship, node attribute information and edge attribute information in DDG, and predicts and updates the risk propagation path by integrating the risk priority coefficient (RPN) in Reliability Engineering and Failure Mode and Effects Analysis (FMEA) and dynamic Bayesian network, and quantifies the risk assessment from a global perspective, providing a basis for blocking high-risk downstream paths or downstream paths that depend on abnormal data.

[0147] The risk propagation prediction model is a probabilistic inference model based on dynamic Bayesian networks. It is a continuously optimized set of conditional probability tables that quantifies the fault propagation relationship between nodes.

[0148] First, the dynamic dependency graph is modeled as a dynamic Bayesian network, which is a directed acyclic graph (DAG), represented as pairs. , where the vertex set , representing the toolchain A set of tool nodes and directed edges. This represents the data dependencies between tools, i.e. The input depends on The output of each tool node; It is a binary random variable representing the instrument state. :

[0149]

[0150] The default value for the tool state is 0. The core of the risk propagation prediction model is the conditional probability distribution of each node under all combinations of parent node values. It quantifies the strength of the influence of the child node tool on its parent node tool group in the form of a conditional probability table (CPT). Parent nodes refer to all nodes that are directly pointed to by directed edges. For a node that has The utility node of the parent node Parent node set pa( ) ;

[0151] Tool Node The prior error probability is:

[0152]

[0153] When IOCA detects a tool node Upon failure, immediately halt the execution of the tool node, set its status observation to 1, and modify the tool execution permission status to 0. The goal of the risk propagation prediction model is to calculate all downstream nodes. The posterior failure probability is used to update the risk propagation path, quantify risk assessment from a global perspective, and block tool nodes that fail. For high-risk downstream tool nodes, the tool execution license status of the high-risk downstream tool nodes will be changed to 0, disallowing them from continuing execution, to prevent a single tool failure from causing a complete workflow failure. For tool nodes not affected by the failure... Downstream tool nodes affected by the disruption will not have their execution permission status changed and can continue to execute, ensuring the overall efficiency of the workflow. In standard Bayesian networks, the calculation of posterior probability is based on conditional probability tables (CPT) and Bayes' theorem, which only considers the dependencies between events. However, due to the particularity and differences of each tool node in the agent's workflow, and the complex relationships between tool nodes, this model introduces three influencing factors—error severity weight, data sensitivity weight, and causal strength—to enhance the model's inference ability and more comprehensively quantify the risks in the workflow.

[0154] Causality strength: Represents the degree of influence of a parent node on its child nodes, with a value range of [0,1]. 0 represents no influence, meaning a parent node failure will not cause a child node failure, while 1 represents a complete influence, indicating that a parent node failure will inevitably lead to a child node failure.

[0155] Tool Node The base posterior error probability is:

[0156]

[0157] in, Indicates the parent node child nodes The causal strength is expressed as:

[0158]

[0159] child node From the parent node The number of input data items received. It is a child node The total number of input data items;

[0160] Risk transmission probability The calculation formula is:

[0161]

[0162] in, parent node The error severity weight is set to 0 by default for all unexecuted tool nodes in the dynamic dependency graph, to facilitate the handling of non-directly downstream tool nodes of failed tool nodes. Update calculation; parent node Transmit to child nodes Data sensitivity weights;

[0163] When the probability of risk propagation across all downstream nodes After the update is complete, the calculated With risk threshold Perform real-time comparison, if Less than If the risk of the tool node is deemed controllable, it can be executed normally; Greater than or equal to If a path is identified as high-risk, and the tool node is likely to encounter serious errors if it continues to execute, the tool node should be immediately stopped from continuing execution, and its tool execution status should be changed to 0 to prevent the error from spreading in the workflow.

[0164] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A dynamic fault perception and risk propagation prediction method for intelligent agent workflow, characterized in that, Includes the following steps: S1, the intelligent agent plans the target workflow according to the user's instructions, constructs a dynamic dependency graph based on the planned target workflow, and obtains multiple tool nodes and tool node attributes; S2, for each tool node, the input and output trusted auditor adopts a layered verification architecture, which verifies the workflow through the format compliance layer, execution status layer and semantic consistency layer respectively. If all verifications pass, the output data flows into the next tool node and the workflow continues to be executed. If any of the format compliance layer, execution status layer, or semantic consistency layer fails validation, the system will block and return a structured report of fault information, and determine the error severity weight and data sensitivity weight based on the error type. S3, for downstream nodes of tool nodes that failed verification in S2, is managed by a risk propagation prediction model based on dynamic dependency graph. By calculating the risk propagation probability, high-risk paths are blocked and the cascading propagation of errors is suppressed. In step S1, a dynamic dependency graph is constructed using a combination of "static skeleton and dynamic injection". First, a global static topology skeleton is pre-constructed based on the target workflow to clarify all tools and the potential data flow between tools. Then, each tool in the workflow is abstracted as a node, and the node attributes cover five indicators: tool number and name, execution time, tool status, tool execution status, and number of retries; data dependencies are abstracted as edges, and the edge attribute information includes two indicators: the specific data item dependency relationship between adjacent tools and the causal strength. As the intelligent agent workflow is executed, the execution status of the tool is dynamically observed through lightweight instrumentation technology to obtain the start and end times of the tool call and calculate the execution time of the tool. In step S2, the format compliance layer performs format review on the data flowing into the tool node and the data output by the tool node, filtering out tool illusion errors, missing parameter errors, incorrect parameter key names, and incorrect parameter value types. If the validation fails, the corresponding error type is returned. The execution state layer is responsible for verifying the execution status of tool calls and promptly detecting timeout errors, network connection errors, permission or authentication issues, and internal server errors during tool execution. The semantic consistency layer is responsible for deeply validating the validity and relevance of the tool's output data. It employs an INT8-quantized Sentence-BERT model, first abstracting semantic templates from the tool documentation and historical correct outputs. Then, it dynamically evaluates semantic validity by calculating the cosine similarity between the output content and the semantic template. If the cosine similarity exceeds a threshold... If the cosine similarity is less than or equal to the threshold, then the output semantics are considered valid. If the output is invalid, the output is intercepted and an error type is returned indicating that the output data format is complete but the content is invalid. The input / output trusted auditor maintains a predefined error severity mapping table. The error severity weight can be obtained by directly indexing the error severity mapping table according to the error type code. The construction logic of the error severity mapping table is driven by historical data. Based on historical data, the statistical correlation between specific errors and final task failure is calculated to establish a conditional failure probability model. Error subclasses based on historical data statistics The total number of occurrences is The number of times this error directly or indirectly caused the task to ultimately fail was [number missing]. Subclassing errors Corresponding task failure rate error subclass As a weight for error severity, The calculation formula is: ； The error severity weight ranges from [0,1], where 0 represents no risk and 1 represents the highest risk. The determination of data sensitivity weight adopts a combination of metadata feature extraction and keyword mapping table indexing. First, the transmitted data types are divided into three categories: security and privacy, decision logic, and general information. A "keyword-category" mapping table is constructed and a corresponding sensitivity score is assigned to each category. Then, metadata features are extracted from the current transmitted data. Based on the preset "keyword-category" mapping table, the metadata features are matched to automatically map the metadata features to the corresponding categories and return the preset sensitivity score of the data in that category, thus obtaining the data sensitivity weight. The data sensitivity weight ranges from [0,1], where 0 represents normal data and 1 represents the highest data sensitivity. If the tool is not executed, the data sensitivity weight on the edge on which it depends is 0 by default. If the tool has been executed, the time point at which the tool is blocked will be different depending on the error that occurs. If the erroneous tool does not produce output data, the sensitivity weight of the input data will be directly assigned to the data sensitivity weight of the current error event. If the faulty tool has already generated output data, the determination of data sensitivity weights is based on the data transmitted along the edges between the two tool nodes in the dynamic dependency graph. When a single edge involves multiple transmitted data, in order to accurately reflect the highest risk boundary of data transmission and avoid the dilution of high-risk signals by low-sensitivity data, a maximum risk inheritance strategy is adopted for weight aggregation calculation, as follows: First, based on the keyword mapping table, the n independent data items in the transmitted content are scanned, and each item is assigned an independent data sensitivity score. Then, the maximum value among them is selected as the final data sensitivity weight of the dependent edge. : ； In step S3, the risk propagation prediction model is a probabilistic inference based on dynamic Bayesian networks. It is a continuously optimized set of conditional probability tables that quantifies the fault propagation relationship between nodes. First, the dynamic dependency graph is modeled as a dynamic Bayesian network, which is a directed acyclic graph, represented as pairs. , where the vertex set , representing the toolchain A set of tool nodes and directed edges. This represents the data dependencies between tools, i.e. The input depends on The output of each tool node; It is a binary random variable representing the instrument state. : The default value for the tool state is 0. The core of the risk propagation prediction model is the conditional probability distribution of each node under all combinations of parent node values. It quantifies the strength of the influence of the child node tool on its parent node tool group in the form of a conditional probability table. Parent nodes refer to all nodes directly pointed to by directed edges. For a node that has The utility node of the parent node Parent node set pa( ) ; Tool Node The prior error probability is: Tool Node The base posterior error probability is: in, Indicates the parent node child nodes The causal strength is expressed as: child node From the parent node The number of input data items received. It is a child node The total number of input data items; Risk transmission probability The calculation formula is: in, parent node Error severity weights parent node Transmit to child nodes Data sensitivity weights; When the probability of risk propagation across all downstream nodes After the update is complete, the calculated With risk threshold Perform real-time comparison, if Less than If the risk of the tool node is deemed controllable, it can be executed normally; Greater than or equal to If a path is identified as high-risk, the tool node is immediately stopped from continuing execution, and its tool execution status is changed to 0 to prevent the error from spreading in the workflow.

2. The dynamic fault perception and risk propagation prediction method for intelligent agent workflow according to claim 1, characterized in that, The execution status of a tool is a binary random variable, where 1 represents allowed execution and 0 represents blocked execution. The initial status of all tool nodes is 1 by default. The number of retries refers to the number of times a tool node attempts to re-execute after a failure. The initial number of retries for all tool nodes is 0 by default, and the number of retries cannot exceed the maximum number of attempts set.

3. The dynamic fault perception and risk propagation prediction method for intelligent agent workflow according to claim 2, characterized in that, The execution state layer employs two complementary detection methods: active detection based on execution state and passive detection based on error information. Active detection proactively blocks abnormal states through a sliding window-based adaptive statistical circuit breaker mechanism and resource silent analysis techniques. The sliding window-based adaptive statistical circuit breaker mechanism aims to detect hidden timeouts caused by slow tool execution. First, it utilizes tool execution time metrics accumulated in the dynamic dependency graph, maintaining a length of... Historical execution time sliding window Before the tool is executed, the maximum tolerance time threshold is dynamically calculated based on the statistical distribution within the window, according to Chebyshev's inequality. : in, , represents the average execution time within the window. , where is the standard deviation. Let be the confidence coefficient, and take . It is 3; When the actual execution time of the tool exceeds the maximum tolerable time threshold. When the timeout occurs, the system determines that the circuit breaker has been triggered. Resource silent analysis technology aims to detect timeout errors and network connection errors caused by tool deadlocks, infinite loops, or network black holes. It directly reads kernel-level status indicators such as CPU time slice count and network interface traffic count of tool processes or containers through the resource silent analyzer. Determining resource quiescence requires calculating network throughput and CPU volatility, and can only be done within the observation window. The tool will only be deemed to have lost its runtime activity and its process will be forcibly terminated when the internal monitoring detects that both network throughput and CPU volatility meet the quiescent conditions.

4. The dynamic fault perception and risk propagation prediction method for intelligent agent workflow according to claim 3, characterized in that, Network throughput is defined as the total traffic increment within the observation window, and the calculation formula is: in, Indicates the first The cumulative number of bytes received from the kernel at each sampling time; This represents the cumulative number of bytes received from the kernel at the first sampling time; Indicates the first The cumulative number of bytes sent read from the kernel at each sampling time; This represents the cumulative number of bytes sent from the kernel at the first sampling time; This represents the total number of samples within the observation window. The total number of bytes received during the entire window period. The total number of bytes sent during the entire window period; Set network silence threshold ,like This indicates that in Internally, the tool hardly exchanges data with the outside world, which is considered network silence; The calculation process for CPU volatility is as follows: First calculate the... A sample of instantaneous CPU load : in, To extract the number of CPU time slices in the 1st month Cumulative CPU time of the process during each sampling. Sampling time, The sampling interval is the time difference between two adjacent samples. ; Then, the statistical variance of the payload sample sequence within the window is calculated. Quantifying CPU volatility: express The average value; Set variance threshold ,like This indicates that the process is in a constant deadlock or constant infinite loop state.

5. The dynamic fault perception and risk propagation prediction method for intelligent agent workflow according to claim 4, characterized in that, Passive detection aims to detect server errors, explicit network connection errors, explicit timeout errors, and permission or authentication errors during tool execution. Passive detection parses the underlying exception stack in the HTTP response headers, response bodies, and standard error stream returned by the tool, and uses a pre-built multi-dimensional error pattern library to attribute faults. This multi-dimensional error pattern library contains three types of mapping rules: first, status code mapping rules, which operate at the protocol communication layer, determining the connectivity and protocol status between the tool node and the gateway or server by parsing the RFC standard status codes in the HTTP response header; second, structured error code rules, which operate at the business logic layer, used to parse business-level error fields hidden in the HTTP response body data packet, identifying critical scenarios where the protocol succeeds but the business fails. Under the premise that the response status code is normal, it accurately determines specific business logic violations or missing dynamic permissions by matching custom logical error codes in the response body; and third, exception keyword regular expression rules, which operate at the system runtime layer, identifying root cause characteristics reflecting physical links, memory overflows, or program crashes by matching text features in the underlying exception stack in the standard error stream, thus diagnosing sudden hardware and software failures.

Images