Agent adaptive workflow control method based on scene analysis

Abstract

The application discloses an agent adaptive workflow control method based on scene analysis, which comprises the following steps: acquiring field values and source meta information of each key field of a candidate workflow in available data sources to form a scene state record; establishing a dependency relationship between the key fields and processing nodes to form a directed task graph; constructing a factor graph based on the scene state record and performing belief propagation to determine unstable fields; constructing an uncertainty representation according to a historical value distribution of the unstable fields, and performing Monte Carlo simulation on the directed task graph to obtain a final action distribution and an influence amount of each unstable field; performing verification on high-influence fields and updating the scene state record; and re-determining the final action distribution according to the updated state, and selecting to execute corresponding workflow nodes or to enter an alternative path according to execution conditions. The method can improve the execution accuracy and stability of an agent workflow in a multi-source data inconsistency scene.

Description

Technical Field

[0001] This application relates to the field of intelligent agent workflow control technology, and more specifically, to an intelligent agent adaptive workflow control method based on scenario analysis. Background Technology

[0002] With the widespread use of data sources such as enterprise knowledge bases, business system interfaces, databases, long document retrieval, historical dialogues, and structured model outputs in intelligent agent workflows, an intelligent agent typically needs to simultaneously acquire multiple key fields when processing a business request, and based on this, complete subsequent operations such as retrieval, judgment, report generation, external system writing, or notification sending. In existing technologies, workflows are mostly executed according to a pre-arranged node order and conditional branches, usually assuming that the input fields are all valid data at the current request point, or handling abnormal fields only through simple rule validation, source priority, manual review, etc.

[0003] However, in real-world business scenarios, different data sources may differ in terms of update time, document version, business object status, and field extraction results. For example, the rule documents in the knowledge base may have been updated, but the search results may still match the old version; customer status may come from a real-time interface, while contract status may come from periodically synchronized data; and the same field may also have inconsistent values ​​when obtained from different sources. If the workflow is executed directly based on the above data, it is easy to use outdated, mismatched, or contradictory fields together in the same decision node, leading to incorrect final action selection.

[0004] Furthermore, existing workflow control methods often struggle to assess data validity at the field level and determine whether an unstable field will substantially affect the final action. Manually verifying all abnormal fields increases response latency and operational costs; simply ignoring abnormal fields or using the current value may lead to erroneous execution when irreversible processing nodes such as external writes or formal notifications are involved. Summary of the Invention

[0005] This application provides an agent-based adaptive workflow control method based on scenario analysis, which at least solves some of the technical problems existing in the related technologies described above.

[0006] According to a first aspect of the embodiments of this application, an intelligent agent adaptive workflow control method based on scene analysis is provided, including: Obtain the field values ​​and source metadata of each key field in the candidate workflow from each available data source to form a scenario status record; Establish the dependency relationship between key fields and processing nodes according to the node configuration to form a directed task graph; A factor graph is constructed based on the scene state records and confidence propagation is performed to obtain the posterior valid probability of each field; fields with posterior valid probabilities lower than the stability threshold are marked as unstable fields. An uncertainty representation is constructed based on the historical value distribution of each unstable field. A Monte Carlo simulation is performed on the directed task graph to obtain the final action distribution, and the influence of each unstable field is calculated accordingly. Each influencing factor is compared with an influencing factor threshold. For unstable fields that are above the influencing factor threshold, verification is performed. The verification results and their corresponding source metadata are updated to the scene state record. For unstable fields that are below the influencing factor threshold, the current value is retained. Based on the updated scene state records, confidence propagation and Monte Carlo simulation are re-executed to obtain the updated final action distribution. When the execution conditions are met, the workflow node corresponding to the action category is executed; otherwise, the alternative path is entered. The execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there are no unstable fields with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain processing nodes that produce irreversible effects.

[0007] As an optional approach, the source metadata includes field source type, data last update time, business object identifier, and document version number. Constructing the factor graph includes: Create variable nodes for each key field record in the scenario state record. Each variable node represents a binary random variable indicating whether the corresponding field is valid at the current request point in time. Factor nodes are created between variable nodes. These factor nodes include source timeliness factors, version matching factors, business object consistency factors, and cross-source cross-validation factors. The source timeliness factor outputs the prior probability of a field's validity based on the interval between the most recent data update time and the current request time, as well as the historical average update interval obtained from historical execution logs according to the field's source type. The version matching factor outputs a compatibility value based on whether the document version numbers of two fields are consistent. The business object consistency factor outputs a compatibility value based on whether the business object identifiers of multiple fields point to the same business entity. The cross-source cross-validation factor compares whether the values ​​of the same field obtained from two independent sources are consistent, and adjusts the validity probability of the corresponding variable node accordingly.

[0008] As an optional approach, constructing an uncertainty representation based on the historical value distribution of each unstable field includes: for categorical fields, using the posterior valid probability of the field as the retention probability of the current value, and allocating the remaining probability to other candidate categories according to the frequency proportion of each error category of the field in the historical execution log, forming a discrete probability distribution as the uncertainty representation of the field; for numerical fields, using the current value of the field as the center, and when the current value is missing, using the mean of the historical value records as the center, constructing a value interval and probability density based on the standard deviation of the historical value records and the posterior valid probability of the field, as the uncertainty representation of the field; wherein, the value interval is an interval formed by expanding the center value to both sides by a preset multiple of the effective standard deviation, and the effective standard deviation increases as the posterior valid probability decreases.

[0009] As an optional approach, performing Monte Carlo simulation on the directed task graph includes: performing multiple rounds of simulation, in each round sampling values ​​from the uncertainty representation of each unstable field, wherein unstable fields with factor connections or belonging to the same processing node dependency group are jointly sampled according to their joint uncertainty representation, unstable fields without factor connections are sampled independently, and stable fields are taken as their current values; the sampled field values ​​are simulated node by node along the directed task graph in node order; for regular nodes, the judgment rules are directly executed to obtain the output, and for model inference nodes, the output is obtained by looking up the conditional probability mapping table obtained in advance from the historical execution log; after each round of simulation propagates to the final action node, a final action category is generated; after all rounds are completed, the occurrence frequency of each final action category is counted to form the final action distribution.

[0010] As an optional approach, the calculation of the impact of each unstable field includes: calculating the information entropy of the final action based on the frequency of occurrence of each action category in the final action distribution; grouping the simulation results of each round according to the sampled values ​​of each unstable field, statistically analyzing the frequency distribution of the final action category within each group and calculating the group entropy, and weighting and summing the groups according to the sample proportions to obtain the conditional entropy; and using the difference between the information entropy and the conditional entropy as the impact of the unstable field.

[0011] As an optional approach, when multiple unstable fields exist that exceed the impact threshold, the verification process includes: performing verification on each field sequentially in descending order of verification priority score, based on the impact of each field and the estimated verification time and cost obtained from historical execution statistics; wherein the verification priority score is equal to the impact divided by the sum of the time cost weight multiplied by the normalized estimated verification time and the cost weight multiplied by the normalized estimated verification cost; wherein the verification priority score also incorporates a data security / compliance level score, with verification methods running in an intranet environment receiving additional preset bonuses, and verification methods requiring cross-network calls to external APIs being subject to preset penalty scores.

[0012] As an optional solution, a local quantization model is also included: when the cloud-based main model is detected to be unavailable or the field to be processed involves privacy-sensitive data and there is a risk of data leakage, the local quantization model is adaptively switched to perform the model inference node sampling task in the Monte Carlo simulation.

[0013] As an optional approach, it also includes triggering a local re-evaluation when the deviation between the actual output of a processing node and the simulated output of the processing node in the Monte Carlo simulation exceeds a deviation threshold during the execution of the workflow node corresponding to the action category: updating the actual output of the processing node to the scene state record, re-executing confidence propagation, Monte Carlo simulation and impact calculation for the fields and nodes on the downstream dependent links of the processing node that are affected by the actual output, and adjusting the subsequent execution path or triggering a local rollback and recalculation based on the recalculation results.

[0014] According to a second aspect of the embodiments of this application, a scene analysis-based intelligent agent adaptive workflow control system is also provided, comprising: The scenario status recording module is used to obtain the field values ​​and source metadata of each key field of the candidate workflow in each available data source, and form a scenario status record; The task graph construction module is used to establish the dependency relationship between key fields and processing nodes according to the node configuration, forming a directed task graph; The field validity assessment module is used to construct a factor graph based on the scenario state records and perform confidence propagation to obtain the posterior validity probability of each field; fields with posterior validity probabilities lower than the stability threshold are marked as unstable fields. The impact calculation module is used to construct an uncertainty representation based on the historical value distribution of each unstable field, perform Monte Carlo simulation on the directed task graph to obtain the final action distribution, and calculate the impact of each unstable field accordingly. The field validation update module is used to compare each impact quantity with the impact quantity threshold, perform validation on unstable fields that are higher than the impact quantity threshold, update the validation results and their corresponding source metadata to the scene status record, and retain the current value of unstable fields that are lower than the impact quantity threshold. The execution path control module is used to re-execute confidence propagation and Monte Carlo simulation based on the updated scene state records to obtain the updated final action distribution; when the execution conditions are met, the workflow node corresponding to the action category is executed; otherwise, it switches to an alternative path; the execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there are no unstable fields with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain processing nodes that produce irreversible effects.

[0015] As an optional solution, a threshold dynamic adaptive tuning module is also included, which is used to adjust preset thresholds online based on system operation feedback. The preset thresholds include a stability threshold, a node execution threshold, an impact threshold, and an action execution threshold. The threshold adjustment adopts a gradient descent algorithm, with the system error rate as the optimization target, and automatically fine-tunes the value of each threshold based on the feedback of verification success rate, action execution accuracy rate, and business complaint rate in historical execution logs.

[0016] This application generates a scene state record containing field values ​​and source metadata before the intelligent agent workflow is executed. By combining directed task graphs, factor graph confidence propagation, and Monte Carlo simulation, it quantifies the validity of multi-source fields and their impact on the final action, thus avoiding the direct use of data with inconsistent update times, document versions, or business objects for workflow decisions. Compared to existing fixed processes or simple verification methods, this invention can identify unstable data at the field granularity level and prioritize verification only for fields with a significant impact on the final action, while retaining and labeling fields with less impact, reducing unnecessary manual review and API call costs. Furthermore, after verification, the final action distribution is redefined, and an alternative path is automatically initiated when high-risk unstable fields exist or downstream irreversible processing nodes are involved. This helps reduce risks such as erroneous writes and notifications, improving the accuracy, stability, and resource utilization efficiency of the intelligent agent workflow in complex business scenarios.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Furthermore, no embodiment in this disclosure is required to achieve all the effects described above. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0019] Figure 1 A flowchart of an agent-based adaptive workflow control method based on scene analysis is provided for embodiments of this disclosure.

[0020] Figure 2 The flowchart for constructing the factor graph and performing belief propagation is provided for embodiments of this disclosure.

[0021] Figure 3 A flowchart for calculating the impact of unstable fields provided in this embodiment of the disclosure.

[0022] Figure 4 This is a schematic block diagram of an intelligent agent adaptive workflow control system based on scene analysis, provided as an embodiment of the present disclosure.

[0023] Figure 5This is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] According to embodiments of this disclosure, this method is applicable to scenarios in enterprise-level intelligent agent cloud platforms where intelligent agents process multi-source data fusion workflows. In such scenarios, after receiving a business request, an intelligent agent often needs to simultaneously obtain field information from multiple sources, including knowledge base documents, long document search results, business system interfaces, databases, historical dialogue records, and structured outputs of large language models, and complete subsequent processing such as retrieval, reasoning, report generation, or external writing based on these fields. Data from different sources may differ in update time, document version, and business object status. For example, the credit policy document in the knowledge base may have just been updated, while the long document search still hits the old version; the customer risk level comes from a real-time interface, but the contract status comes from the previous day's synchronized batch. If data with inconsistent status from these sources is directly concatenated and sent to a fixed workflow for execution, the workflow may make incorrect decisions based on contradictory evidence, especially when irreversible actions such as external writing or formal notifications are involved, the impact of which is particularly severe.

[0026] In this embodiment, after scene identification is completed, the source status of each field involved in the workflow is recorded and consistency is assessed. Then, the actual impact of inconsistent fields on the final workflow actions is determined, and the verification depth and execution path are adaptively selected accordingly. The overall processing flow includes: obtaining the field values ​​and source metadata of each key field and forming a scene status record; establishing the dependency relationship between key fields and processing nodes according to node configuration and forming a directed task graph; constructing a factor graph based on the scene status record and performing confidence propagation to obtain the posterior effective probability of each field; constructing an uncertainty representation based on the historical value distribution of each unstable field and performing Monte Carlo simulation on the directed task graph to calculate the impact of each unstable field; performing verification or retention on fields according to the comparison results of the impact and the impact threshold; and finally, re-performing confidence propagation and Monte Carlo simulation based on the updated state to determine the final execution path.

[0027] The implementation process of the method described in this application will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only used to explain this application and is not intended to limit the scope of protection of this application. Conventional adjustments or substitutions of each step by those skilled in the art without departing from the concept of this application should be included in the scope of protection of this application.

[0028] Please see Figure 1 , Figure 1 This is a flowchart of an agent-based adaptive workflow control method based on scene analysis according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes: In step S10, the field values ​​and source metadata of each key field of the candidate workflow in each available data source are obtained to form a scenario status record.

[0029] In some embodiments, after the agent completes scene recognition, the system determines the set of key fields required for this workflow based on the recognized scene category and the candidate workflow definition. Key fields are fields that at least one processing node in the candidate workflow uses as required input or will determine the execution branch based on their values. The system reads the list of required input fields and the list of conditional judgment fields from the configuration of each processing node in the candidate workflow, and obtains the set of key fields by taking their union.

[0030] In some embodiments, for each field in the set of key fields, the field value is obtained from the corresponding data source, and the source metadata of the field is recorded synchronously. The two together form a structured record. When the same key field can be obtained from multiple data sources, the system records the field value returned by each data source and its source metadata, and each set of field values ​​and source metadata forms a field record. Multiple field records for the same key field are used together for subsequent cross-source verification. The data table formed by summarizing the structured records of all key fields in the same request is the scenario status record. The scenario status record plays the role of uniformly managing all key fields and their source status involved in this request. Subsequent consistency assessments, impact calculations, and verification updates all operate on the scenario status record.

[0031] In some embodiments, each record in the scenario state record includes the following attributes: field name, field value, and source metadata for that field. Specifically, the source metadata includes the field source type, the last data update time, the business object identifier, and the document version number. The field source type indicates whether the field was taken from a knowledge base document, business system interface, database table, long document search results, historical dialogues, model structured output, or direct user input; the last data update time records the last modification time of the data source's own report; the business object identifier records the unique number of the business entity associated with the field, such as a customer number or contract number; and the document version number records the version identifier of the knowledge base document or rule file referenced by the field.

[0032] For field records not involving knowledge base documents or rule files, the document version number can be recorded as null; for field records not associated with specific business entities, the business object identifier can be recorded as null. When the corresponding metadata is null, the system does not create the corresponding factor in the factor graph, or sets the corresponding factor as a neutral factor that does not change the probability of the variable node. The source metadata will participate in the calculation of different factor nodes in subsequent factor graph construction steps. For example, the field source type and the most recent data update time are used as inputs for the source timeliness factor, the document version number is used as input for the version matching factor, and the business object identifier is used as input for the business object consistency factor.

[0033] In step S20, the dependencies between key fields and processing nodes are established according to the node configuration, forming a directed task graph. Specifically, after the scenario state record is constructed, the system establishes the dependencies between key fields and each processing node according to the node configuration of the candidate workflow, forming a directed task graph. The candidate workflow consists of multiple processing nodes arranged in execution order or conditional branches. The configuration of each processing node records the node identifier, node type, list of required input fields, list of output fields, and a flag indicating whether the node produces an irreversible effect.

[0034] The system traverses all processing nodes, matching the required input fields of each node with the output fields of the preceding nodes or the initial fields in the scene state record to establish directed edges. In the directed task graph, nodes represent processing steps, and edges represent the transmission relationship of fields between nodes, with each edge labeled with the name of the field being transmitted. For conditional branch nodes, the system also records the fields that the branch conditions depend on and the corresponding judgment rules. The final action node is the node at the end of the directed task graph that produces the final output of the workflow. Its output types include generating a formal report, submitting for manual review, sending a customer response, calling an external interface to write status, or simply generating a draft. After the directed task graph is constructed, the system can trace all upstream fields that any final action node depends on.

[0035] In step S30, a factor graph is constructed based on the scene state record and confidence propagation is performed to obtain the posterior valid probability of each field; fields with posterior valid probabilities lower than the stability threshold are marked as unstable fields.

[0036] Since multiple key fields originate from different data sources, inconsistencies may exist between the update times, document versions, and business object identifiers of these sources. It is necessary to determine at the field granularity whether these fields can still collectively support the execution of the same workflow node at the current request point. This embodiment employs a belief propagation algorithm on a factor graph to perform this determination, thereby obtaining the posterior validity probability of each field.

[0037] Specifically, please refer to Figure 2 , Figure 2 The diagram illustrates the construction factor graph and the flowchart for performing belief propagation provided in embodiments of this disclosure. Figure 2 As shown in box 201, a factor graph is constructed based on the scene state record.

[0038] The system creates a variable node for each key field record in the scenario status log. Each variable node corresponds to a binary random variable, with a value of valid or invalid, indicating whether the field is still usable for workflow decisions at the current request point in time. When the same key field has multiple source field records, each source field record corresponds to a separate variable node.

[0039] Between variable nodes, the system creates factor nodes to express the constraints between fields or between a field and its source metadata. For example, four types of factor nodes are defined: source timeliness factor, version matching factor, business object consistency factor, and cross-source cross-validation factor.

[0040] The source timeliness factor connects to a single variable node. Based on the interval between the most recent update time of this field's data in the scenario status record and the current request time, combined with the historical average update interval calculated from historical execution logs according to the field's source type, it outputs the prior probability that the field is still valid. The historical average update interval is calculated as follows: the system groups the historical workflow execution logs by source type and field type, calculates the average time interval between actual changes in field values ​​within each group, and periodically recalculates and updates the interval.

[0041] In one implementation, the prior probability of the source timeliness factor output is determined using an exponential decay method. The ratio of the difference between the current request time and the most recent data update time to the historical average update interval is used as the independent variable, and the timeliness decay coefficient is used as the decay rate. The exponential decay value is then calculated as the prior probability. Let the difference between the current request time and the most recent data update time be... The historical average update interval is The time-related decay coefficient is Then the prior probability is:

[0042] in The value can be configured from 0.5 to 3.0. The determination method is as follows: the system filters records with the same source type and field type from the historical execution log, and counts the differences. The proportion of fields that actually fail under the given value is obtained by least-squares fitting of the above exponential decay function. The estimated value. When much smaller When the prior probability is close to 1, Approaching or exceeding The prior probability decreases significantly, meaning that the longer the data is updated, the more likely it is to become outdated.

[0043] The version matching factor connects two variable nodes and outputs a compatibility value based on whether the document version numbers recorded in the scenario status record for each field are consistent. For example, if one field records the version number of a credit policy document, and the value of another field depends on the content of a clause in that policy document, the version matching factor checks whether the policy version referenced by the latter during data collection is consistent with the version recorded by the former. If the document version numbers referenced by the two fields are the same, the factor outputs a higher compatibility value; if the version numbers are different, it outputs a lower compatibility value.

[0044] For example, the preset value is determined as follows: the system calculates the proportion of valid fields when versions are consistent and the proportion of valid fields when versions are inconsistent from the historical logs, and uses these two as the high and low values, respectively. Optionally, when there are traceable change records between version numbers, the system can further refine the compatibility value based on whether the changes between versions involve clauses of the relevant fields.

[0045] The business object consistency factor connects two or more variable nodes and outputs a compatibility value based on whether the business object identifiers recorded in the scenario status record for each field point to the same business entity. For example, the customer entity number field and the contract status field need to be associated with the same customer. If their business object identifiers do not match, it means that the system may be mixing data from different customers. A high compatibility value is output when the business object identifiers match completely, and a compatibility value close to zero is output when they do not match. When there are changes or mergers of business objects, the system can query the business object change record to determine whether the two identifiers still point to the same actual entity and adjust the compatibility value accordingly.

[0046] Cross-source cross-validation factors are applicable when the same field can be obtained from two independent sources. They compare whether the field values ​​returned by the two sources are consistent, and adjust the validity probability of the corresponding variable nodes accordingly. If the values ​​are consistent, the validity probability of both variable nodes is increased; if they are inconsistent, adjustments are made separately based on the historical reliability of each source. Historical reliability is statistically obtained from the execution log by source type, representing the proportion of times that source's returned values ​​have been subsequently validated as correct.

[0047] The aforementioned compatibility values ​​are used as the potential values ​​of the factor functions of the corresponding factor nodes in message calculation. For version matching factors or business object consistency factors connecting two variable nodes, when the constraints are met, the potential value of the combination of values ​​where both variable nodes are "valid" is set to a high compatibility value; when the constraints are not met, the potential value of the combination of values ​​where both variable nodes are "valid" is set to a low compatibility value, and the potential values ​​of each combination of values ​​for this factor function are normalized. Cross-source cross-validation factors connect two source instance variable nodes of the same key field; when the field values ​​of the two source instances are consistent, the potential value of the combination of values ​​where both source instances are "valid" is set to a high compatibility value based on the historical reliability of the two sources; when the field values ​​are inconsistent, the potential values ​​of the combination of values ​​where one is valid and the other is invalid are set according to the historical reliability of the two sources, and then normalized before participating in confidence propagation.

[0048] In box 202, after the factor graph is constructed, the system iteratively passes messages between variable nodes and factor nodes using the sum-product algorithm. The sum-product algorithm is a classic algorithm used in probabilistic graphical models to calculate marginal probabilities. Its core idea is that each variable node summarizes the messages it receives from other neighboring factor nodes and forwards them to the target factor node, while each factor node sums the product of its factor function and the messages sent by other neighboring variable nodes over the non-target variables and forwards it to the target variable node.

[0049] Specifically, in each iteration, when a variable node sends a message to a connected factor node, the value of that message is obtained by multiplying the messages received by that variable node from all connected factor nodes except the target factor node point by point. When a factor node sends a message to a connected variable node, the value of that message is obtained by multiplying the factor function value by the messages received from all connected variable nodes except the target variable node point by point, and then summing and marginalizing the non-target variables.

[0050] The iteration continues until the change in all messages is less than the convergence threshold or the upper limit of the number of iterations is reached. Since the number of variable nodes in this embodiment is equal to the number of key fields, which is usually on the order of tens, the factor graph structure is relatively sparse, and confidence propagation can generally converge within tens of iterations. The upper limit of the number of iterations can be configured according to the actual situation, for example, 50 to 200 rounds; the convergence threshold can be configured so that the maximum change in the value of all messages in two adjacent rounds is less than a preset precision.

[0051] In box 203, after the iteration is complete, the system multiplies and normalizes the messages received by each variable node from all its connected factor nodes to obtain the posterior validity probability of each field. The posterior validity probability represents the probability that the corresponding field is still valid at the current request time after comprehensively considering constraints such as source timeliness, version matching, business object consistency, and cross-source cross-validation.

[0052] In box 204, after obtaining the posterior valid probability of each field, fields with a posterior valid probability lower than the stability threshold are marked as unstable fields, and fields with a posterior valid probability higher than the stability threshold are marked as stable fields. The stability threshold can be configured from 0.7 to 0.95, and the specific value is calibrated through historical execution logs: the system counts the proportion of errors that occur in actual execution for fields marked as stable under different stability threshold values, and selects a value that makes this proportion lower than the upper limit acceptable to the business.

[0053] In some embodiments, for multiple key fields that the same processing node in the directed task graph depends on, the system also calculates the joint validity probability based on the factor connection relationships between corresponding variable nodes in the factor graph. The joint validity probability represents the probability that the group of fields is simultaneously in a valid state.

[0054] The calculation method depends on the structure of the factor graph. When the factor graph is a tree structure, it can be directly obtained from the messages already calculated during the belief propagation process. Specifically, a subgraph is selected consisting of the variable nodes corresponding to the field group. The factor function values ​​of the factor nodes in the subgraph and the messages from outside the subgraph are used to sum the non-target variables sequentially using the variable elimination method to obtain the joint distribution. When the factor graph contains loops, the approximate result of cyclic belief propagation is used. For cases where the field group size is small, all variable value combinations can also be directly enumerated to accurately calculate the joint probability.

[0055] When the posterior valid probability of all fields in the group is not lower than the stability threshold and the joint valid probability is not lower than the node execution threshold, the processing node is marked as a directly executable processing node and will be executed after the final action distribution judgment condition is met. Otherwise, the fields in the processing node whose posterior valid probability is lower than the stability threshold, and the combination of fields whose posterior valid probability is not lower than the stability threshold but causes the joint valid probability to be lower than the node execution threshold, are included in the uncertainty representation construction process. For example, the value range of the node execution threshold can be from 0.7 to 0.99.

[0056] In step S40, an uncertainty representation is constructed based on the historical value distribution of each unstable field, and a Monte Carlo simulation is performed on the directed task graph to obtain the final action distribution, thereby calculating the influence of each unstable field.

[0057] The degree of influence of each unstable field on the final workflow action varies. Some unstable fields do not change the final action category even if the value is incorrect, while changes in the value of some fields will directly cause the final action to switch from one category to another. In order to distinguish these differences and allocate verification resources accordingly, the system calculates the impact quantity for each unstable field. This impact quantity measures the degree to which a change in the value of a certain field causes a change in the final action category.

[0058] Specifically, please refer to Figure 3 , Figure 3 A flowchart illustrating the calculation of the impact of an unstable field according to an embodiment of this disclosure is shown. Figure 3 As shown in box 301, uncertainty representation is constructed based on the historical value distribution of each unstable field.

[0059] Different data types of fields are constructed in different ways. For unstable fields that have factor connections or belong to the same processing node dependency group, the system constructs a joint uncertainty representation based on the joint effective probability or joint distribution of the corresponding variable nodes. For unstable fields that do not have factor connections, single-field uncertainty representations are constructed separately.

[0060] For categorized fields (such as risk level, contract status, and approval conclusion), the system uses the posterior valid probability of the field as the retention probability of the current value, and distributes the remaining probability to other candidate categories according to the frequency ratio of each error category of the field in the historical execution log, thereby forming a discrete probability distribution as an uncertainty representation of the field.

[0061] Specifically, the system filters all records of this field type from the execution log, identifies records where the initial value and the final verified value are inconsistent, and calculates the distribution ratio of the final verified value across each category, using this as the basis for error allocation. For example, if the posterior validity probability of a certain risk level field is 0.6, then the current low-risk value retains a probability of 0.6, and the remaining 0.4 is allocated according to the frequency ratio of other values ​​such as medium-risk and high-risk in the historical logs for this field.

[0062] For numerical fields, the system constructs a value interval and probability density based on the mean and standard deviation of historical value records, representing the uncertainty of the field. For example, let the current value be... The posterior effective probability is p, and the standard deviation of the historical values ​​is... Then Centered on; when When a value is missing, the average of historical records is used as the center. The system then... Determine the effective standard deviation with p. And when p decreases Increase; the value range is [center value - , central value + ],in To preset the multiple and calibrate through historical verification value coverage, the system uses truncated probability density for sampling within this value range.

[0063] For text-based judgment fields, such as the model output of conclusions like "conforms," ​​"does not conform," or "cannot be determined," the system maps them to a finite set of categories and assigns probabilities in the same way as categorical fields.

[0064] In block 302, a Monte Carlo simulation is performed on the directed task graph to obtain the final action distribution. Specifically, in each round of simulation, the system samples values ​​from the uncertainty representation of each unstable field; unstable fields with factor connections or belonging to the same processing node dependency group are jointly sampled according to their joint uncertainty representation, while unstable fields without factor connections are sampled independently, and stable fields take their current values. The sampled field values ​​are then used to simulate the processing logic node by node along the directed task graph in node order.

[0065] For rule-based nodes (such as conditional judgments, threshold comparisons, and state mappings), the system directly executes the judgment rules recorded in its configuration, substituting the input field values ​​into the rule expression to obtain the output. For model inference nodes, due to the high time consumption and cost of actually calling large language models, the system uses a conditional probability mapping table as a lightweight alternative. The construction process of the conditional probability mapping table is as follows: the system pre-collects all execution records of the node from the historical execution log, and each record contains the value combinations of the input fields and the corresponding output conclusions; for categorical input fields, the system directly groups them according to the input value combinations and counts the frequency of occurrence of each output conclusion in each group to form a conditional probability table; for numerical input fields, the system divides the value range into several intervals and then groups them for statistics.

[0066] The interval boundaries are defined based on historical sample quantiles or determined according to the equal-width interval division rules in the workflow configuration. If the sampled input value combination does not have a corresponding historical record in the conditional probability mapping table, the system uses the global output frequency distribution of the model inference node under the same scene category as the fallback output distribution; if the global output frequency distribution also does not exist, the node's output is marked as requiring manual review. During the simulation, the system matches the sampled input values ​​to the corresponding conditional probability distribution in the mapping table and samples from it to obtain the simulated output value of the node. The conditional probability mapping table is periodically updated from the execution log, and the update cycle can be configured according to the actual situation.

[0067] Each simulation round propagates along the directed task graph from the entry node to the final action node, generating a final action category, such as generating a formal report, submitting for manual review, or simply generating a draft. After all rounds are completed, the system calculates the frequency of occurrence for each final action category, forming a final action distribution. This distribution reflects the stability of the final actions under the current evidence state. The number of simulation rounds can be configured according to actual conditions, ranging from hundreds to thousands of rounds, specifically determined by the real-time requirements of the scenario and the required statistical accuracy; in real-time response scenarios, the number of rounds can be set to a smaller value to control latency, while in offline reporting scenarios, a larger value can be set to improve accuracy.

[0068] In box 303, the system calculates the impact of each unstable field based on the final action distribution. Specifically, the impact is defined using mutual information, which measures the degree to which the uncertainty of the final action is reduced after knowing the value of a certain field.

[0069] For example, the specific calculation process includes calculating the information entropy of the final action based on the frequency of occurrence of each action category in the final action distribution. The information entropy is calculated by assuming the frequencies of occurrence of each action category are as follows: Then the information entropy is:

[0070] in A random variable representing the final action. The log above represents the total number of action categories, calculated using the natural logarithm.

[0071] The simulation results from each round are grouped according to the sampled values ​​of a certain unstable field. For categorical fields, they are grouped directly by category value; for numerical fields, they are grouped by value range. Within each group, the frequency distribution of the final action category is statistically analyzed and the group entropy is calculated. Then, the groups are weighted and summed according to the sample proportions of each group to obtain the conditional entropy. The conditional entropy is calculated as follows: assuming the field is divided into... Group, No. The sample proportion of the group is The in-group entropy is Then the conditional entropy is:

[0072] in The random variable representing this unstable field is represented by the difference between its information entropy and conditional entropy, which is used as the influence of this unstable field.

[0073] Impact The value range is 0 to . The larger the value, the more significant the impact of the field's value change on the final action selection. The system calculates the impact amount for each unstable field separately.

[0074] In step S50, each influencing quantity is compared with the influencing quantity threshold. For unstable fields that are higher than the influencing quantity threshold, verification is performed. The verification results and their corresponding source metadata are updated to the scene state record. For unstable fields that are lower than the influencing quantity threshold, the current value is retained.

[0075] The system compares the impact of each unstable field with an impact threshold, handling it in two ways. For unstable fields whose impact exceeds the threshold, the system performs verification. Available verification methods are pre-registered in the workflow configuration and interface definition, including real-time interface re-query (initiating a new request to the data source interface for the field to obtain the latest value), specified version knowledge base retrieval (re-retrieving and extracting documents matching the current workflow), cross-source comparison of the same field (obtaining the same field value from another independent data source for comparison), and historical record comparison (querying recent historical value change records of the business object to determine whether the current value is reasonable), etc.

[0076] When a field has multiple available methods, the system selects the method with the shortest estimated execution time and the highest historical verification success rate. The impact threshold can be configured from 0.05 to 0.3. It is determined by statistically analyzing historical execution logs to determine the proportion of fields with impact values ​​below the threshold that cause incorrect switching of the final action after skipping verification, and selecting a value that keeps this proportion below the upper limit required by business requirements.

[0077] When multiple unstable fields exist with impact values ​​exceeding a threshold, the system determines the verification order based on the impact value of each field and the estimated verification time and cost obtained from historical execution statistics. Specifically, the system calculates a verification priority score for each field to be verified, which is equal to the impact value divided by the sum of the time cost weight multiplied by the estimated verification time and the cost weight multiplied by the estimated verification cost. Let the impact value of a certain field be denoted as . The normalized verification time is estimated to be The estimated cost of normalized verification is Time cost weighting is Cost weighting is The verification priority score is then:

[0078] Among them, time cost weight and cost weight Used to adjust the relative importance of normalization time and normalization cost, both ranging from 0.1 to 10.0. Initial values ​​are preset according to business requirements: for real-time response scenarios, Set it to a higher value to make the system tend to choose the verification method with shorter processing time; for offline batch scenarios, Set to a lower value. The corresponding increase. Verification of estimated time consumption. and verification of estimated costs All data is obtained from historical execution statistics of each verification method. The system executes verifications sequentially according to their priority scores, from highest to lowest. Higher scores indicate the greatest reduction in uncertainty of the final action per unit verification cost, and therefore these are verified first. During operation, these weights can be adjusted based on actual response time and resource consumption feedback.

[0079] Optionally, in some embodiments, the verification priority score can also incorporate a data security / compliance level score. The system pre-configures a security / compliance level for each verification method. Verification methods running in an intranet environment (including private deployment of large model calls and local RAG knowledge base queries) receive additional preset bonuses, while verification methods that require cross-network calls to external APIs are subject to preset penalty scores, in order to ensure that verification paths that meet data security and compliance requirements are selected first.

[0080] When performing verifications sequentially, the system checks whether the cumulative time has reached the maximum verification time limit after each verification. If the cumulative time reaches the maximum verification time limit, subsequent verifications are stopped, the current values ​​of the remaining unverified fields are retained, and the final output is marked as requiring manual review. The maximum verification time limit is configured based on the scenario type, specifically determined by the maximum allowed response time for that scenario type, or by a preset quantile of the total verification time for similar scenarios in historical execution logs.

[0081] Optionally, in some embodiments, the system is also configured with a real-time inference fallback mechanism for the local quantization model: the lightweight model is pre-quantized and deployed in the local operating environment. During the Monte Carlo simulation, when the main model in the cloud is detected to have a timeout, call failure, or the pending field contains sensitive data such as customer privacy or trade secrets that pose a risk of cross-network transmission, the system automatically switches to the local quantization model to execute the sampling inference task of the model inference node. That is, it adaptively switches to the local quantization model to execute the sampling task of the model inference node in the Monte Carlo simulation. The local quantization model is optimized for common business scenarios, improving the inference speed while ensuring inference accuracy, and ensuring that the business can still operate normally when cloud services are unavailable or there are privacy risks.

[0082] The system supports a dynamic adaptive threshold tuning mechanism: the initial values ​​of the preset thresholds, such as the stable threshold, node execution threshold, impact threshold, action execution threshold, and deviation threshold, range from 0.7 to 0.95. During operation, the system continuously collects operational feedback data, such as verification success rate, action execution accuracy rate, business error rate, and manual review rate. Using a gradient descent algorithm, with the system error rate as the optimization target, the system automatically fine-tunes the values ​​of each threshold based on the feedback from the verification success rate, action execution accuracy rate, and business complaint rate in the historical execution log. Threshold tuning is triggered every preset number of execution cycles or when the business error rate exceeds the warning threshold. The tuned thresholds need to undergo gray-scale verification before taking full effect, thereby improving the system's adaptability to different business scenarios.

[0083] For example, the system constructs a threshold vector comprising a stability threshold, a node execution threshold, an impact threshold, and an action execution threshold. Every preset number of execution cycles or when the business error rate exceeds a warning threshold, the system reads the most recent historical execution logs. The system replays the corresponding requests according to the logs, reconstructing the scenario state record, directed task graph, posterior valid probability of the factor graph, the impact of unstable fields, and the final action distribution. The system uses the verification results, actual execution paths, whether the action execution is correct, and subsequent business complaint records as supervisory feedback. During the training phase, hard judgments such as marking below the threshold, verifying above the threshold, and executing above the threshold are approximated by a smoothing function. A loss function based primarily on the system error rate is constructed, incorporating penalties such as decreased action execution accuracy, increased business complaint rate, and excessively low verification success rate. Subsequently, the gradient of the loss function relative to each threshold is calculated, and the thresholds are updated according to a preset learning rate. If the stability threshold is too low, causing invalid fields to be misjudged as stable, the gradient pushes it upwards; if the impact threshold is too high, causing high-risk fields to remain unverified, it pushes it downwards; if the action execution threshold is too low, causing erroneous execution, it pushes it upwards. The updated threshold is limited to a preset range, and a maximum adjustment range is set for each adjustment. The update will be fully implemented only after gray-scale verification confirms that the error rate has decreased.

[0084] After verification, the system will update the verification result to the scenario status record, including updating the field value and the last update time of the corresponding field, and synchronously updating the field source type, business object identifier and document version number corresponding to the verification result; for projects that do not generate corresponding source metadata for the verification method, the record will be recorded according to the null value or neutral factor processing rules.

[0085] For unstable fields whose impact is below the impact threshold, the system retains their current value and adds source descriptions and pending confirmation marks to these fields in the final output.

[0086] In step S60, confidence propagation and Monte Carlo simulation are re-executed based on the updated scene state record to obtain the updated final action distribution; when the execution conditions are met, the workflow node corresponding to the action category is executed; otherwise, the alternative path is entered; the execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there is no unstable field with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain processing nodes that produce irreversible effects.

[0087] The system re-executes belief propagation and Monte Carlo simulation based on the updated scene state records to obtain the updated final action distribution. The re-execution process is the same as the previous steps, namely, reconstructing the factor graph based on the updated scene state records, performing belief propagation to obtain the updated posterior valid probabilities of each field, and performing Monte Carlo simulation on the directed task graph based on the updated uncertainty representation to obtain the updated final action distribution.

[0088] In some embodiments, the system determines the execution path based on the updated final action distribution in the following two cases. When the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there are no unstable fields with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to that action category, and the downstream of that path does not contain processing nodes that produce irreversible effects, the system executes the workflow node corresponding to that action category. The action execution threshold ranges from 0.7 to 0.99. For actions that produce irreversible effects, such as external writes and formal notifications, the action execution threshold is set to a higher value; for actions that only generate drafts or internal records, the action execution threshold can be set to a lower value. The specific value of the action execution threshold can be configured according to business risk preferences, or it can be calibrated based on the statistical results of the false trigger rate of each action category in the historical execution log.

[0089] If, after an update, there are still unstable fields with impact values ​​exceeding the threshold, and their downstream nodes in the directed task graph contain processing nodes that produce irreversible effects, the system will not execute these nodes and will redirect the workflow to an alternative path. Alternative paths include entering a supplementary data retrieval process to obtain more corroborating evidence from additional data sources, entering a manual confirmation process where business personnel review key fields to decide whether to continue execution, or outputting a draft result with unconfirmed fields and their source status marked. The choice of alternative path depends on the probability difference between the top two action categories in the current updated final action distribution and the urgency of the scenario: if the probability difference is small and the scenario is not urgent, the supplementary data retrieval process will be prioritized; if the scenario is urgent and a manual review channel is available, the manual confirmation process will be prioritized.

[0090] Optionally, during the execution of workflow nodes corresponding to this action category, when the deviation between the actual output of a processing node and the simulated output of that processing node in the Monte Carlo simulation exceeds a deviation threshold, the system triggers a local re-evaluation. The method for determining the deviation threshold varies depending on the type of output data: for categorical outputs, the deviation threshold refers to the predicted probability of the actual output category in the Monte Carlo simulation results being lower than a preset lower probability limit; for numerical outputs, the deviation threshold refers to the actual value deviating from the simulated mean by more than a preset standard deviation multiple. The probability lower limit can range from 0.05 to 0.3, and the standard deviation multiple can range from 2 to 4, with specific values ​​calibrated using the statistical results of the deviation between simulated and actual outputs in the historical execution log.

[0091] During partial reassessment, the system updates the corresponding field value and the most recent update time in the scene status record to reflect the actual output of the processing node. If the corresponding field record does not exist, a new field record with the output of the processing node as the field value is created, and the processing node identifier is recorded as the field source type or source identifier. Subsequently, confidence propagation, Monte Carlo simulation, and impact calculation are re-executed only on the fields and nodes in the downstream dependent links of the processing node that are affected by the actual output. Based on the recalculation results, subsequent execution paths are adjusted or partial rollback and recalculation are triggered. Through partial reassessment, the system can promptly detect deviations between simulated expectations and actual outputs during workflow execution, avoiding the continued execution of subsequent nodes based on inaccurate simulated expectations.

[0092] After the entire workflow is completed, the system records the scenario status of this execution, the trajectory of the posterior validity probability change of each field, the verification actions and their results, the final action category, and the actual execution path in the execution log. The execution log is used to update the historical average update interval, conditional probability mapping table, and verification cost statistics in the source timeliness factor, providing a more accurate statistical basis for subsequent requests. These statistical parameters are obtained through periodic aggregation and calculation of historical execution logs. The system can be started with default parameters during initial deployment, and the accuracy gradually increases as execution logs accumulate.

[0093] Optionally, in some embodiments, the system also provides a visualization output interface, which includes the statistical results of the impact of each unstable field in the final workflow output, as well as a complete decision tracing diagram. The decision tracing diagram shows the field dependency relationship, factor connection relationship, Monte Carlo simulation propagation path, verification execution record and threshold judgment logic, which facilitates business personnel to verify the results and can also be used as evidence material when collecting evidence for rights protection, reducing the difficulty of proving infringement.

[0094] Therefore, this invention, even when multiple sources of evidence exist with inconsistent times, versions, and source states, can determine at the field level whether each piece of evidence can still jointly support the execution of the current workflow, and allocate verification resources based on the actual impact of each unstable field on the final workflow action. Fields with high impact are verified first before entering nodes that produce irreversible effects, while fields with low impact are retained with their current values ​​and marked in the output. The allocation of verification resources is jointly determined by the field's impact on the final action and the verification cost. The workflow execution path is adaptively determined based on the updated final action distribution. Formal actions are executed only after ensuring that high-impact fields have been sufficiently verified; if verification is insufficient, an alternative path is automatically switched to avoid accidental triggering of irreversible operations.

[0095] Please see Figure 4 , Figure 4This is a structural block diagram of an intelligent agent adaptive workflow control system based on scene analysis, provided in an embodiment of this application. Figure 4 As shown, the system includes: The scenario status recording module 401 is used to obtain the field values ​​and source metadata of each key field of the candidate workflow in each available data source to form a scenario status record. Task graph construction module 402 is used to establish the dependency relationship between key fields and processing nodes according to node configuration, forming a directed task graph; The field validity assessment module 403 is used to construct a factor graph based on the scenario state record and perform confidence propagation to obtain the posterior validity probability of each field; and to mark fields with posterior validity probabilities lower than the stability threshold as unstable fields. The influence calculation module 404 is used to construct an uncertainty representation based on the historical value distribution of each unstable field, perform Monte Carlo simulation on the directed task graph to obtain the final action distribution, and calculate the influence of each unstable field accordingly. The field validation update module 405 is used to compare each influence quantity with the influence quantity threshold, perform validation on unstable fields that are higher than the influence quantity threshold, update the validation results and their corresponding source metadata to the scene status record, and retain the current value for unstable fields that are lower than the influence quantity threshold. The execution path control module 406 is used to re-execute confidence propagation and Monte Carlo simulation based on the updated scene state record to obtain the updated final action distribution; when the execution conditions are met, the workflow node corresponding to the action category is executed; otherwise, it switches to an alternative path; the execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there is no unstable field with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain a processing node that produces irreversible effects.

[0096] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0097] Please see Figure 5 It shows a schematic block diagram of an electronic device according to an embodiment of this application, which can be used to implement... Figure 1 The method in the illustrated embodiment. (As shown) Figure 5 As shown, the electronic device may include: The system includes at least one processor 501, at least one network interface 504, a user interface 503, a memory 505, and at least one communication bus 502. The communication bus 502 is used to enable connection and communication between the components. The user interface 503 may include buttons, and optionally include a standard wired or wireless interface. The network interface 504 may include, but is not limited to, a Bluetooth module, an NFC module, a Wi-Fi module, etc.

[0098] The processor 501 may include one or more processing cores and connect to various parts within the electronic device through various interfaces and lines. It implements various functions and data processing of the electronic device by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by accessing data in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 501 may also integrate one or more combinations of CPU, GPU, and modem.

[0099] Memory 505 may include random access memory (RAM) or read-only memory (ROM). Optionally, memory 505 includes a non-transitory computer-readable medium for storing instructions, programs, code, code sets, or instruction sets. Memory 505 may be divided into a program storage area and a data storage area, wherein the program storage area can be used to store instructions for implementing an operating system and instructions for implementing the foregoing method embodiments; the data storage area can be used to store data related to the relevant method embodiments. Memory 505 may also be at least one storage device located remotely from processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may contain an operating system, a network communication module, a user interface module, and program instructions.

[0100] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by processor 501, it performs the functions defined in the methods of this application.

[0101] Another embodiment of this application provides a storage medium storing computer program instructions thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application.

[0102] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The above descriptions are merely preferred embodiments of this application and explanations of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by specific combinations of the above technical features, but should also cover other technical solutions formed by arbitrary combinations of the above technical features or their equivalent features without departing from the inventive concept.

Claims

1. A scenario-based agent-based adaptive workflow control method, characterized in that, include: Obtain the field values ​​and source metadata of each key field in the candidate workflow from each available data source to form a scenario status record; Establish the dependency relationship between key fields and processing nodes according to the node configuration to form a directed task graph; A factor graph is constructed based on the scene state records and confidence propagation is performed to obtain the posterior valid probability of each field; fields with posterior valid probabilities lower than the stability threshold are marked as unstable fields. An uncertainty representation is constructed based on the historical value distribution of each unstable field. A Monte Carlo simulation is performed on the directed task graph to obtain the final action distribution, and the influence of each unstable field is calculated accordingly. Each influencing factor is compared with an influencing factor threshold. For unstable fields that are above the influencing factor threshold, verification is performed. The verification results and their corresponding source metadata are updated to the scene state record. For unstable fields that are below the influencing factor threshold, the current value is retained. Based on the updated scene state records, the belief propagation and Monte Carlo simulation are re-executed to obtain the updated final action distribution; When the execution conditions are met, execute the workflow node corresponding to the action category; Otherwise, switch to an alternative path; The execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there are no unstable fields with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain processing nodes that produce irreversible effects.

2. The method according to claim 1, characterized in that, The source metadata includes field source type, data last update time, business object identifier, and document version number. Constructing the factor graph includes: Create variable nodes for each key field record in the scenario state record. Each variable node represents a binary random variable indicating whether the corresponding field is valid at the current request point in time. Factor nodes are created between variable nodes. These factor nodes include source timeliness factors, version matching factors, business object consistency factors, and cross-source cross-validation factors. The source timeliness factor outputs the prior probability of a field's validity based on the interval between the most recent data update time and the current request time, as well as the historical average update interval obtained from historical execution logs according to the field's source type. The version matching factor outputs a compatibility value based on whether the document version numbers of two fields are consistent. The business object consistency factor outputs a compatibility value based on whether the business object identifiers of multiple fields point to the same business entity. The cross-source cross-validation factor compares whether the values ​​of the same field obtained from two independent sources are consistent, and adjusts the validity probability of the corresponding variable node accordingly.

3. The method according to claim 1, characterized in that, The uncertainty representation is constructed based on the historical value distribution of each unstable field, including: for categorical fields, the posterior valid probability of the field is used as the retention probability of the current value, and the remaining probability is distributed to other candidate categories according to the frequency ratio of each error category of the field in the historical execution log, forming a discrete probability distribution as the uncertainty representation of the field; for numerical fields, the current value of the field is used as the center, and when the current value is missing, the mean of the historical value records is used as the center, and the value interval and probability density are constructed based on the standard deviation of the historical value records and the posterior valid probability of the field as the uncertainty representation of the field; wherein, the value interval is the interval formed by expanding the center value to both sides by a preset multiple of the effective standard deviation, and the effective standard deviation increases as the posterior valid probability decreases.

4. The method according to claim 1, characterized in that, Performing Monte Carlo simulation on the directed task graph includes: performing multiple rounds of simulation, in which values ​​are sampled from the uncertainty representation of each unstable field in each round, wherein unstable fields with factor connections or belonging to the same processing node dependency group are jointly sampled according to the joint uncertainty representation, and unstable fields without factor connections are sampled independently, and the current value is taken for stable fields, and the sampled field values ​​are simulated node by node in the directed task graph in node order; for regular nodes, the judgment rules are directly executed to obtain the output, and for model inference nodes, the output is obtained by looking up the conditional probability mapping table obtained in advance from the historical execution log; after each round of simulation propagates to the final action node, a final action category is generated; after all rounds are completed, the occurrence frequency of each final action category is counted to form the final action distribution.

5. The method according to claim 4, characterized in that, The calculation of the impact of each unstable field includes: calculating the information entropy of the final action based on the frequency of occurrence of each action category in the final action distribution; grouping the simulation results of each round according to the sampled values ​​of each unstable field, statistically analyzing the frequency distribution of the final action category within each group and calculating the group entropy, and weighting and summing the groups according to the sample ratio to obtain the conditional entropy; and using the difference between the information entropy and the conditional entropy as the impact of the unstable field.

6. The method according to claim 1, characterized in that, When multiple unstable fields exist that exceed the impact threshold, the verification process includes: performing verification on each field sequentially in descending order of verification priority score, based on the impact of each field and the estimated verification time and estimated verification cost obtained from historical execution statistics; wherein the verification priority score is equal to the impact divided by the sum of the time cost weight multiplied by the normalized estimated verification time and the cost weight multiplied by the normalized estimated verification cost; wherein the verification priority score also incorporates a data security / compliance level score, with verification methods running in an intranet environment receiving additional preset bonuses, and verification methods requiring cross-network calls to external APIs being subject to preset penalty scores.

7. The method according to claim 1, characterized in that, It also includes a local quantization model: when the cloud-based main model is detected to be unavailable or the fields to be processed involve privacy-sensitive data and there is a risk of data leakage, it adaptively switches to the local quantization model to perform the model inference node sampling task in the Monte Carlo simulation.

8. The method according to claim 1, characterized in that, It also includes triggering a local re-evaluation when the deviation between the actual output of a processing node and the simulated output of the processing node in the Monte Carlo simulation exceeds the deviation threshold during the execution of the workflow node corresponding to the action category: updating the actual output of the processing node to the scene state record, re-executing confidence propagation, Monte Carlo simulation and impact calculation for the fields and nodes on the downstream dependent links of the processing node that are affected by the actual output, and adjusting the subsequent execution path or triggering a local rollback and recalculation based on the recalculation results.

9. A scenario-based agent-adaptive workflow control system, characterized in that, include: The scenario status recording module is used to obtain the field values ​​and source metadata of each key field of the candidate workflow in each available data source, and form a scenario status record; The task graph construction module is used to establish the dependency relationship between key fields and processing nodes according to the node configuration, forming a directed task graph; The field validity assessment module is used to construct a factor graph based on the scenario state records and perform confidence propagation to obtain the posterior validity probability of each field; fields with posterior validity probabilities lower than the stability threshold are marked as unstable fields. The impact calculation module is used to construct an uncertainty representation based on the historical value distribution of each unstable field, perform Monte Carlo simulation on the directed task graph to obtain the final action distribution, and calculate the impact of each unstable field accordingly. The field validation update module is used to compare each impact quantity with the impact quantity threshold, perform validation on unstable fields that are higher than the impact quantity threshold, update the validation results and their corresponding source metadata to the scene status record, and retain the current value of unstable fields that are lower than the impact quantity threshold. The execution path control module is used to re-execute belief propagation and Monte Carlo simulation based on the updated scene state records to obtain the updated final action distribution; The workflow node corresponding to this action category will be executed when the execution conditions are met. Otherwise, switch to an alternative path; The execution conditions include: the probability corresponding to the highest probability action category after the update exceeds the action execution threshold, and there are no unstable fields with an impact value higher than or equal to the impact value threshold on the proposed execution path corresponding to the action category, and the downstream of the path does not contain processing nodes that produce irreversible effects.

10. The system according to claim 9, characterized in that, It also includes a threshold dynamic adaptive optimization module, which is used to adjust preset thresholds online based on system operation feedback. The preset thresholds include a stability threshold, a node execution threshold, an impact threshold, and an action execution threshold. The threshold adjustment adopts a gradient descent algorithm, with the system error rate as the optimization target. The value of each threshold is automatically fine-tuned based on the feedback of verification success rate, action execution accuracy rate and business complaint rate in historical execution logs.

Images