Enterprise agent construction, arrangement and treatment method

Abstract

The invention discloses an enterprise agent construction, arrangement and treatment method, and relates to the technical field of computer program control. The method comprises the steps that task input, tool calling records, retrieval evidence records and operation resource records are collected to generate a task event sequence, and a step arrangement diagram and an execution sequence are generated based on the task event sequence; according to a preset grading rule, generating an evidence consistency grade, a write-in influence grade and an arrangement drift grade, and generating a governance instruction set based on each grade; scheduling execution steps according to the treatment instruction set to form an operation process record; and updating a grading rule and a governance instruction set based on the operation process record. Uniform controllable arrangement and continuous evolution treatment of enterprise agent task execution are realized through task-level event sequence driven step arrangement generation, evidence consistency level-write influence level-arrangement drift level hierarchical treatment instruction set generation, and rule and instruction closed-loop update based on operation process records.

Description

Technical Field

[0001] This invention relates to the field of computer program control technology, specifically to a method for constructing, orchestrating, and managing enterprise intelligent agents. Background Technology

[0002] With the development of enterprise digital applications, intelligent agents are used for tasks such as work order processing, knowledge retrieval, data querying, report generation, and information synchronization. These tasks are typically triggered by task input, breaking down the task into executable steps and scheduling them according to an execution sequence. During execution, tool call records, retrieval evidence records, and runtime resource records are generated. Existing technologies often organize steps through workflow engines or script orchestration, imposing constraints through access control, call limit limits, timeout control, and retry control, and configuring compensation operations to handle anomalies when necessary.

[0003] However, the implementation of enterprise intelligent agents is hampered by uncertainties in task semantics, heterogeneity of tools, differences in evidence sources, and fluctuations in the operating environment, making it difficult to maintain consistency in orchestration and governance. Task inputs, tool call records, evidence retrieval records, and operational resource records are often generated by different mechanisms, with differences in identification systems and time bases, making it difficult to form a unified event sequence at the task level to support traceability and governance, and easily leading to incomplete correlations or broken links. Deviations such as step insertion, step skipping, and changes in branch selection often occur during execution. Existing solutions mostly remain at the level of log recording or alarms, lacking a structured characterization of the degree of deviation between planned orchestration and actual execution, making it difficult to stably transform deviation results into governance inputs. Retrieved evidence fluctuates in terms of credibility, timeliness, and consistency, and may conflict or expire. Without hierarchical management of evidence support relationships, conflict relationships, and timeliness status, it is easy to proceed with key steps under unreliable evidence conditions. Write-based tool calls have external side effects. Existing governance methods often rely on static whitelists or fixed thresholds, making it difficult to combine these with runtime factors such as write type, object scope, retry status, and idempotency conditions to create reusable impact profiles. Furthermore, it's challenging to establish a stable mapping with executable constraints like call limits, timeout thresholds, retry counts, and compensation conditions, resulting in coarse-grained governance and poor adaptability. Governance strategies typically depend on manual configuration or fixed rules, lacking a closed-loop mechanism for versioning and updating hierarchical rule thresholds and governance command values ​​based on runtime records. This makes it difficult to continuously adjust to business changes and tool fluctuations.

[0004] Therefore, it is necessary to provide a method for constructing, orchestrating, and governing enterprise intelligent agents to achieve unified governance of task-level event collection, hierarchical characterization, and instruction generation, and to continuously update rules and instructions based on the operation process records. Summary of the Invention

[0005] Based on the shortcomings of the prior art described above, the purpose of this invention is to provide a method for constructing, orchestrating, and governing enterprise intelligent agents to solve the aforementioned technical problems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for constructing, orchestrating, and governing enterprise intelligent agents, comprising:

[0007] Based on the collected task inputs, tool call records, retrieval evidence records, and runtime resource records, a task event sequence is generated, and a step arrangement diagram and execution sequence are generated based on the task event sequence.

[0008] Based on preset grading rules, an evidence consistency level is generated based on retrieved evidence records, a write impact level is generated based on tool call records, and an orchestration drift level is generated based on the step orchestration diagram and execution sequence.

[0009] Generate a set of governance instructions based on the evidence consistency level, the write impact level, and the orchestration drift level;

[0010] The execution steps are scheduled according to the governance instruction set, and an operation process record is generated.

[0011] The hierarchical rules and governance instruction set are updated based on the operation process records.

[0012] The present invention is further configured such that generating the task event sequence based on the collected task input, tool call records, retrieval evidence records, and runtime resource records includes:

[0013] Generate task events based on task input, including task identifiers, task time identifiers, and task semantic tags;

[0014] Based on the tool call record, a call event is generated, including a task identifier, call time identifier, tool identifier, read / write attribute identifier, and result code identifier;

[0015] Evidence events are generated based on retrieved evidence records, including task identifiers, evidence time identifiers, evidence source identifiers, and evidence conclusion identifiers;

[0016] Resource events, including task identifier, sampling time identifier, and resource consumption identifier, are generated based on the runtime resource records.

[0017] Task events, invocation events, evidence events, and resource events are aggregated based on task identifiers, and then sorted by time identifiers to generate a task event sequence.

[0018] The present invention is further configured such that the step arrangement diagram and execution sequence generated based on the task event sequence include:

[0019] Extract task semantic tags from task events in the task event sequence, and extract tool sets from call events in the task event sequence;

[0020] Generate a set of steps based on task semantic tags and tool set, and assign step identifiers to the set of steps;

[0021] Based on preset dependency rules, step dependencies and branch condition relationships are generated within the step set to form a step arrangement diagram;

[0022] An execution sequence that satisfies the dependency relationship is generated based on the step dependency relationship. The execution sequence includes a step order identifier and a branch selection identifier. The execution sequence is written into the baseline step sequence record associated with the task semantic label.

[0023] Compensation relationships are generated within the step arrangement diagram according to preset compensation rules, and the compensation relationships are associated with step identifiers and written into the step arrangement diagram.

[0024] The present invention is further configured such that generating an evidence consistency level based on retrieved evidence records according to a preset grading rule includes:

[0025] Based on the retrieved evidence records, an evidence item set is extracted. The evidence item set includes evidence time identifier, evidence source identifier, subject identifier, and evidence conclusion identifier.

[0026] Based on the preset relationship discrimination rules, the evidence item set is subjected to relationship discrimination to generate supporting relationship records and conflicting relationship records;

[0027] Based on preset statute of limitations rules, the statute of limitations is determined on the set of evidence items, and a statute of limitations status record is generated.

[0028] Based on preset hierarchical rules, hierarchical mapping is performed on supporting relationship records, conflicting relationship records, and time-limited status records to generate evidence consistency levels.

[0029] The present invention is further configured such that the write impact level generated based on the tool call record includes:

[0030] Extract the call entry set based on the tool call record. The call entry set includes call time identifier, tool identifier, read / write attribute identifier, result code identifier, retry status identifier, and idempotency condition identifier.

[0031] Based on preset write type rules, the call entry set is categorized by type to generate write type records;

[0032] Based on preset scope rules, the call item set is categorized by scope to generate object scope records;

[0033] Based on preset hierarchical rules, hierarchical mapping is performed on write type records, object range records, retry status flags, and idempotent condition flags to generate write impact levels.

[0034] The present invention is further configured such that the generation of orchestration drift levels based on the step orchestration diagram and execution sequence includes:

[0035] Obtain the baseline step sequence identifier and baseline branch selection identifier based on the baseline step sequence record associated with the task semantic label;

[0036] Compare the step sequence identifiers and branch selection identifiers in the execution sequence with the baseline step sequence identifiers and baseline branch selection identifiers to form step set difference records, sequence deviation records, and branch deviation records.

[0037] Based on preset grading rules, a grading mapping is performed on the step set difference records, sequence deviation records, and branch deviation records to generate an orchestration drift level.

[0038] The present invention is further configured such that generating the governance instruction set based on the evidence consistency level, write impact level, and orchestration drift level includes:

[0039] Establish a correspondence between level combinations and instruction item sets based on preset instruction generation rules;

[0040] Within the step arrangement diagram, the step identifier is used as the association key to associate the evidence consistency level, the writing impact level, and the arrangement drift level with the step identifier to generate the step governance status.

[0041] Based on the step governance status and preset instruction generation rules, a set of instruction items associated with the step identifier is generated. The set of instruction items includes the values ​​of branch selection, tool scope constraint, call limit, timeout threshold, number of retries and compensation conditions.

[0042] The collection of instructions is aggregated to form a governance instruction set, which is then stored in association with task identifiers and instruction version identifiers.

[0043] The present invention is further configured such that the step of scheduling and executing according to the governance instruction set to form an operation process record includes:

[0044] A step scheduling sequence is generated based on the step arrangement diagram and the governance instruction set, and the step scheduling sequence is associated with the task identifier;

[0045] During the process of advancing the step scheduling sequence, the set of instruction items associated with the step identifier is obtained according to the step identifier. Execution constraints are applied to the tool scope, call limit, timeout threshold, number of retries and compensation conditions according to the set of instruction items. The corresponding steps are executed. When the compensation conditions are met, the compensation steps are executed according to the compensation relationship.

[0046] For each step, a step execution entry is formed. The step execution entry includes task identifier, step identifier, instruction version identifier, call summary identifier, result code identifier, retry status identifier, compensation status identifier, and resource consumption identifier.

[0047] The process is recorded by collecting entries step by step and indexed based on task identifiers and step identifiers.

[0048] The present invention is further configured such that updating the hierarchical rules based on the running process records includes:

[0049] Obtain the hierarchical rule version associated with the task semantic label. The hierarchical rule version includes the evidence consistency level threshold, the write impact level threshold, and the orchestration drift level threshold.

[0050] Based on the result code identifier, retry status identifier, compensation status identifier, and resource consumption identifier extracted from the operation process record, a threshold adjustment record is formed;

[0051] Based on the threshold adjustment records, threshold updates are performed on the evidence consistency level threshold, the write impact level threshold, and the orchestration drift level threshold to form an updated grading rule version.

[0052] Write the updated hierarchical rule version to the hierarchical rule version repository, and associate the updated hierarchical rule version with the task semantic tag, version identifier, and effective time identifier.

[0053] The present invention is further configured such that updating the governance instruction set based on the running process record includes:

[0054] Obtain the governance instruction set generation rules and the governance instruction set value benchmark. The governance instruction set value benchmark includes the call limit value item, the timeout threshold value item, the retry count value item, and the compensation condition value item.

[0055] Based on the operation process record, extract the instruction version identifier, call summary identifier, result code identifier, retry status identifier, and compensation status identifier associated with the step identifier to form a value adjustment record;

[0056] Based on the value adjustment records, the values ​​of the call limit, timeout threshold, retry count, and compensation condition are updated to form the value benchmark for the update governance instruction set;

[0057] The updated governance instruction set value benchmark is associated with the task semantic tag and instruction version identifier and written into the value benchmark library. The governance instruction set generation rules call the updated governance instruction set value benchmark when generating governance instruction sets in the future.

[0058] This invention provides a method for constructing, orchestrating, and governing enterprise intelligent agents. The method generates a task event sequence based on collected task inputs, tool call records, retrieval evidence records, and runtime resource records; generates a step orchestration diagram and execution sequence based on the task event sequence; generates an evidence consistency level based on the retrieval evidence records according to preset hierarchical rules, a write impact level based on the tool call records, and an orchestration drift level based on the step orchestration diagram and execution sequence; generates a governance instruction set based on the evidence consistency level, write impact level, and orchestration drift level; schedules and executes steps according to the governance instruction set, forming a runtime record; and updates the hierarchical rules and governance instruction set based on the runtime record. The beneficial effects include:

[0059] 1. Traceable orchestration governance of task-level event aggregation: Based on task input, tool call records, retrieval evidence records and runtime resource records, a task event sequence is generated, and a step orchestration diagram and execution sequence are formed accordingly. This elevates the governance object from scattered logs to a unified semantic carrier at the task level, supporting step-level association, indexing and tracing, and reducing governance gaps caused by inconsistencies in cross-source associations.

[0060] 2. Three-dimensional hierarchical governance instruction generation: Based on preset hierarchical rules, evidence consistency level, write impact level and orchestration drift level are generated respectively, and a governance instruction set is generated accordingly. Branch selection, tool scope, call limit, timeout threshold, retry count and compensation conditions are transformed into step-level executable constraints, realizing a unified governance expression of evidence reliability, write risk and orchestration deviation.

[0061] 3. Adaptive governance with closed-loop updates of operation process records: The scheduling execution steps form operation process records. The threshold items of the hierarchical rules and the value benchmark of the governance instruction set are updated according to the operation process records, forming a version evolution mechanism. This allows the governance rules to be continuously corrected with the task execution results and reused in subsequent tasks, improving the adaptability and consistency of the governance strategy to business changes and tool fluctuations.

[0062] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

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

[0064] Figure 1 The flowchart illustrates an enterprise intelligent agent construction, orchestration, and governance method as an exemplary embodiment of the present invention. Detailed Implementation

[0065] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0066] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0067] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0068] Example 1:

[0069] A method for constructing, orchestrating, and governing enterprise intelligent agents, such as Figure 1 As shown, it includes:

[0070] Based on the collected task inputs, tool call records, retrieval evidence records, and runtime resource records, a task event sequence is generated, and a step arrangement diagram and execution sequence are generated based on the task event sequence.

[0071] Based on preset grading rules, an evidence consistency level is generated based on retrieved evidence records, a write impact level is generated based on tool call records, and an orchestration drift level is generated based on the step orchestration diagram and execution sequence.

[0072] Generate a set of governance instructions based on the evidence consistency level, the write impact level, and the orchestration drift level;

[0073] The execution steps are scheduled according to the governance instruction set, and an operation process record is generated.

[0074] The hierarchical rules and governance instruction set are updated based on the operation process records.

[0075] The present invention is further configured such that generating the task event sequence based on the collected task input, tool call records, retrieval evidence records, and runtime resource records includes:

[0076] Task events, including task identifiers, task time identifiers, and task semantic tags, are generated based on task input. Specifically, upon receiving task input, the task identifier is first extracted from the request header information or entry scheduling record carried in the task input. If the task input does not carry a directly reusable task identifier, a content fingerprint generation rule is used to generate the task identifier. The content fingerprint generation rule combines key fields such as task input text, entry time, and initiator identifier to form an irreversible summary. In case of summary conflicts, an incremental sequence number is added to avoid duplication. Subsequently, the task time identifier is generated, prioritizing the entry reception time. If the entry reception time is missing, the tool call time of the first occurrence of the task is used as the filler. Then, task semantic tags are generated based on the task input text. The formation of task semantic tags adopts a "rule dictionary matching and semantic classification model collaboration" approach: first, candidate tags are obtained by matching with a preset keyword dictionary, and then the task input is classified using a semantic classification model. If the classification result is lower than a preset threshold, it falls back to candidate tags or general tags. Finally, the task identifier, task time identifier, and task semantic tags are encapsulated into a task event and written to the event cache.

[0077] Based on tool call records, a call event is generated, including a task identifier, call time identifier, tool identifier, read / write attribute identifier, and result code identifier. Specifically, after receiving the tool call record, the call time identifier, tool identifier, call parameter summary, and return information summary associated with the task identifier are extracted. The record format is then structured and normalized, uniformly mapping the return status of different tools to result code identifiers. The result code identifier mapping rules include: normal returns are mapped to success-type result codes; timeouts, network failures, permission denials, invalid parameters, and execution exceptions are mapped to corresponding failure-type result codes, based on the exception type field in the call record or the error reason field generated by the scheduler. The read / write attribute identifier is determined based on the tool metadata, which is pre-provided by the tool list and includes an attribute description of whether the tool has external state change capabilities. When the tool has state change capabilities or the call intent belongs to categories such as submit, write, update, or delete, the read / write attribute identifier is set to write attribute; otherwise, it is set to read attribute. The task identifier, call time identifier, tool identifier, read / write attribute identifier, and result code identifier are encapsulated into a call event and written to the event buffer. When the same call record is reported repeatedly, deduplication is performed based on the deduplication key composed of "task identifier, call time identifier, tool identifier, and call parameter summary".

[0078] Evidence events, including task identifiers, evidence time identifiers, evidence source identifiers, and evidence conclusion identifiers, are generated based on retrieved evidence records. Specifically, after receiving retrieved evidence records, the task identifier, evidence time identifier, evidence source identifier, and evidence content summary are extracted. The evidence source identifier consists of a retrieval channel identifier, dataset identifier, or index identifier, used to distinguish different evidence sources. The evidence conclusion identifier is generated from the evidence content summary, using a combined processing method of "conclusion extraction rules and summary consistency rules": first, key segments that can express the conclusion are extracted from the evidence content according to a preset conclusion extraction template; then, consistency processing is performed on the key segments, including synonym merging, numerical unit standardization, punctuation and whitespace standardization; finally, a stable conclusion summary is formed, and the conclusion identifier is generated accordingly. The evidence time identifier prioritizes the evidence generation time; if missing, the retrieval return time is used. The task identifier, evidence time identifier, evidence source identifier, and evidence conclusion identifier are encapsulated as evidence events and written to the event cache. When the same source and the same conclusion appear repeatedly within the same time window, they are merged according to a deduplication key, retaining only the evidence event with the latest time identifier.

[0079] Resource events, including task identifiers, sampling time identifiers, and resource consumption identifiers, are generated based on runtime resource records. Specifically, runtime resource records are generated through sampling, with a preset sampling period configured by the task scheduler or runtime monitor. For each resource record, the task identifier, sampling time identifier, and raw resource consumption value are extracted. The raw resource consumption value may include metrics such as processor usage, storage usage, and external call wait time. To avoid directly carrying large-scale continuous values, the resource consumption identifier is generated using threshold grading rules, provided by a resource threshold table. This table defines interval boundaries and level identifier mappings for each type of resource metric. The resource consumption identifier is output after the raw value falls into the corresponding interval. The sampling time identifier is based on the monitoring clock. In case of clock rollback or out-of-order events, a monotonic correction rule is used to correct the sampling time identifier, ensuring that resource event times within the same task are not reversed. The task identifier, sampling time identifier, and resource consumption identifier are encapsulated as resource events and written to the event buffer.

[0080] Based on task identifiers, task events, call events, evidence events, and resource events are aggregated. A task event sequence is generated by sorting based on time identifiers. Specifically, using the task identifier as the aggregation key, task events, call events, evidence events, and resource events corresponding to the same task identifier are retrieved from the event cache to form a set of events to be sorted. The time of the event set to be sorted is uniformly processed, converting time identifiers from different sources to the same time representation format, and filling in missing time identifiers according to preset backfilling rules, prioritizing the entry reception time or record arrival time. Then, a stable sorting is performed, with the sorting key being ascending time identifiers. Events with the same time identifier are sorted by event type priority, with the preset priority being task events first, call events second, evidence events third, and resource events last, to ensure consistent semantic order within the sequence at the same time. After sorting, the task event sequence is output and written to the task-level storage area. An index with the task identifier as the key is also created so that subsequent steps in the orchestration diagram and execution sequence generation stages can directly reference this task event sequence.

[0081] The present invention is further configured such that the step arrangement diagram and execution sequence generated based on the task event sequence include:

[0082] Task semantic tags are extracted from task events in the task event sequence, and a toolset is extracted from the call events in the task event sequence. Specifically, task event entries are located in the task event sequence, and the task semantic tags they carry are read. Task semantic tags are categorized identifiers of task intent, used to drive subsequent orchestration template selection and step type generation. Subsequently, call event entries are traversed in the same task event sequence, and tool identifiers are collected to obtain a toolset. The toolset represents the range of tools that are actually available or have been called during the task's execution. To avoid the toolset containing duplicate or invalid tools, a tool list validation rule is used to validate the toolset. The tool list validation rule includes metadata such as whether the tool is enabled, the tool's read / write attributes, and the tool's accessibility range. Tool identifiers that fail the validation are removed from the toolset and recorded as unavailable tools for reference during the branch condition generation stage.

[0083] A set of steps is generated based on task semantic tags and a toolset, and step identifiers are assigned to each step. Specifically, a rule set is generated for each step based on the task semantic tags. This rule set is provided by a pre-defined rule base, which is maintained as a mapping from semantic tags to step type sequences. Each rule specifies the step type, required tool conditions, and possible alternative step types. The rules are then constrained and filtered using the toolset. The filtering logic is as follows: if a step type depends on a tool not in the toolset, an alternative step type is prioritized; if no alternative step type exists, the step type is marked as an unexecutable step type, triggering a downgraded path for branch condition generation. After filtering, the step set is obtained. A step identifier is assigned to each step in the step set. The step identifier is generated by combining the task identifier and the step type identifier, with an added sequence number to ensure differentiation when the same type appears multiple times. The step identifier also serves as the association key for subsequent dependencies, branch conditions, and compensation relationships, ensuring the indexability of the orchestration graph.

[0084] Based on preset dependency rules, step dependencies and branch condition relationships are generated within the step set to form a step orchestration graph. Specifically, preset dependency rules describe the sequential constraints and preconditions between steps. The dependency rule base is maintained in the form of "step type to step type" constraints, specifying the constraint strength. Strong constraints prohibit entering subsequent steps if the completion status of the precondition is not met, while weak constraints allow entering alternative steps or downgraded paths if the precondition is not met. When generating dependencies, dependency matching is performed on the step set. The matching logic is as follows: the dependency rule base is searched using the step type as an index, dependency edges are formed, and the dependency relationship record is written. The dependency relationship record includes the precondition identifier, the successor step identifier, and the constraint strength identifier. Branch condition relationships describe the rules for selecting different step paths under different running states. The generation basis for branch conditions includes task semantic tags, tool availability identifiers, and non-executable step type markers. Branch condition relationships are written in the form of "condition items to branch paths." Condition items include tool availability conditions, step executability conditions, and failure status conditions. The branch path contains a sequence of target step identifiers. The step identifier, dependency record, and branch condition record are organized together into a step orchestration graph. The step orchestration graph is stored in a traversable graph structure, which enables the scheduler to advance steps according to dependency edges.

[0085] An execution sequence satisfying dependency constraints is generated based on step dependencies. The execution sequence includes a step sequence identifier and a branch selection identifier. This execution sequence is then written to a baseline step sequence record associated with the task semantic label. Specifically, the execution sequence is generated based on the dependency records in the step orchestration diagram, using a topology-driven approach: under strong constraints, the next candidate step is selected from a set of steps with no prerequisites or whose prerequisites are already satisfied. The selection strategy prioritizes the main path rules corresponding to the task semantic label. When multiple candidate steps exist, they are sorted according to a step type priority table. This table is maintained by a rule base to ensure stable generation of execution sequences under the same input conditions. The branch selection identifier is generated synchronously during execution sequence generation, triggered by a branch condition relationship record, indicating which path—main path, alternative path, or degraded path—to enter. This results in an execution sequence containing both a step sequence identifier and a branch selection identifier. The execution sequence is then written to a baseline step sequence record associated with the task semantic label. This baseline step sequence record serves as a reference for subsequent drift level generation. During storage, the task semantic label is used as the index key, and a version identifier and write time identifier are appended to support subsequent updates and backtracking.

[0086] Compensation relationships are generated within the step orchestration diagram based on preset compensation rules. These compensation relationships are associated with step identifiers and written into the step orchestration diagram. Specifically, the preset compensation rules describe the rollback or repair steps to be executed when a step fails or a compensation condition is triggered. The compensation rule base maintains compensation strategies by step type, and each compensation strategy includes a compensation trigger condition category and a sequence of compensation step types. When generating compensation relationships, each step identifier is traversed using the step set as input. The corresponding compensation strategy is searched in the compensation rule base based on its step type, mapping the compensation step type sequence to a compensation step identifier sequence. The association between the original step identifier and the compensation step identifier sequence is written into the compensation relationship record. If a compensation step depends on a specific tool, the compensation relationship record also carries a tool constraint identifier for verification during the scheduling execution phase. The compensation relationship record is written into the step orchestration diagram, ensuring that the step orchestration diagram contains both the main execution path and the compensation path, guaranteeing that the scheduler can switch to the compensation step sequence for execution according to the compensation relationship when the compensation condition is met.

[0087] The present invention is further configured such that generating an evidence consistency level based on retrieved evidence records according to a preset grading rule includes:

[0088] An evidence entry set is extracted based on the retrieved evidence records. This set includes an evidence time identifier, evidence source identifier, subject identifier, and evidence conclusion identifier. Specifically, the collected retrieved evidence records are structured and parsed, with each record broken down into evidence entries and written into the evidence entry set. The evidence time identifier is preferentially taken from the evidence generation or publication time given in the evidence record. When the evidence record only contains the retrieval return time, that time is used as the evidence time identifier. The evidence source identifier is generated from the source domain name, data source number, index number, or channel number carried in the evidence record, used to distinguish evidence from different sources. The subject identifier is formed by extracting the title, summary, and key fields of the evidence record. The extraction method uses a subject merging rule: first, word segmentation and stop word filtering are performed; then, synonym merging is performed, mapping words expressing the same business concept to a unified subject name; finally, the unified subject name is encoded as the subject identifier. The evidence conclusion identifier is formed by extracting conclusion fragments from the evidence text or summary. The extraction method follows the conclusion extraction rules: fragments containing judgmental or concluding statements are extracted first; if the evidence is a structured entry, the conclusion field is extracted. Subsequently, conclusion consistency processing is performed, standardizing numerical units, time expressions, and synonymous phrases to avoid the same meaning being fragmented by different expressions, ultimately yielding the evidence conclusion identifier. If the same source of evidence repeatedly returns the same topic and the same conclusion near the same evidence time identifier, the evidence deduplication rules are applied, retaining only the most recent evidence entry.

[0089] Based on preset relationship discrimination rules, the evidence item set is subjected to relationship discrimination to generate supporting relationship records and conflicting relationship records. Specifically, the evidence item set is grouped by topic identifier, and relationship discrimination is performed within the same topic identifier group. The relationship discrimination adopts a rule set of "synergistic conclusion consistency discrimination and semantic conflict discrimination": when the evidence conclusion identifiers of two evidence items are completely identical in the consistency result, or are judged as synonymous conclusions by the synonym merging rule, the two are recorded as supporting relationships; when the conclusions of two evidence items have mutually exclusive expressions in key elements, such as the same object having opposite state descriptions within the same time range, or giving mutually exclusive decision suggestions under the same constraints, the two are recorded as conflicting relationships. To avoid misjudgment based solely on differences in expression, the relationship discrimination also introduces "element alignment rules," first aligning the objects, conditions, and time ranges in the conclusion fragments, and only allowing the formation of conflicting relationship records when the objects are consistent and the conditions are comparable. Both supporting relationship records and conflicting relationship records are written with the topic identifier as the primary key, and the records are associated with the evidence source identifier set and evidence time identifier set participating in the discrimination, for subsequent hierarchical mapping to consider the source dispersion and time span.

[0090] The validity period of the evidence item set is determined according to preset validity period rules, generating a validity period status record. Specifically, the validity period of each evidence item is determined, using a combination of "validity period threshold and time decay priority" rules. The validity period threshold is provided by preset validity period rules and can be given different validity period lengths according to the topic identifier; when no specific threshold is configured for a topic, the default validity period threshold is used. During validity period determination, the reference time of the current task is compared with the evidence time identifier. The reference time is preferentially taken from the task time identifier or the retrieval trigger time identifier, and if missing, the evidence record entry time identifier is taken. If the interval between the evidence time identifier and the reference time exceeds the corresponding validity period threshold, the evidence item is marked as expired; if it does not exceed the threshold, it is marked as valid; if the evidence time identifier is missing and cannot be filled back, it is marked as unknown. Subsequently, the validity period status of each evidence item under the same topic is summarized according to the topic identifier to form a validity period status record. The validity period status record contains interval identifiers for the proportion of valid items, expired items, and unknown items corresponding to the topic. The interval boundaries are given by the validity period rules and are used for stability determination during subsequent hierarchical mapping.

[0091] According to preset grading rules, a grading mapping is performed on supporting relationship records, conflicting relationship records, and time-limited status records to generate evidence consistency levels. Specifically, supporting relationship records, conflicting relationship records, and time-limited status records are associated by subject identifiers to form subject-level evidence consistency inputs. The preset grading rules are maintained in the form of a grading table, which configures combined judgment conditions for each level. The judgment conditions are composed of supporting relationship strength intervals, conflicting relationship strength intervals, and time-limited status intervals. The supporting relationship strength interval is formed based on the dispersion of evidence sources covered by supporting relationships under the same subject and the continuity of the occurrence of supporting relationships. The conflicting relationship strength interval is formed based on the number of evidence sources involved in conflicting relationships under the same subject and the number of conflicting pairs. The time-limited status interval is directly determined based on the interval identifiers of valid, expired, and unknown status. During grading mapping, subject-level evidence consistency inputs are matched from high to low according to the grading table, prioritizing levels that meet the criteria of "low conflicting relationships, high supporting relationships, and high proportion of valid time-limited status." When conflicting relationships exist and cannot be resolved by the source credibility priority rule, a lower level is matched. When a large area of ​​evidence is expired or unknown, a lower level is also matched. Finally, the evidence consistency level is output, and the evidence consistency level is associated with the subject identifier and task identifier and written into the governance data storage area.

[0092] The present invention is further configured such that the write impact level generated based on the tool call record includes:

[0093] The tool call record is used to extract a set of call entries. This set includes a call time identifier, a tool identifier, a read / write attribute identifier, a result code identifier, a retry status identifier, and an idempotency condition identifier. Specifically, the collected tool call records are parsed using structured parsing, and each tool call is written into the call entry set as a separate entry. The call time identifier is preferentially taken from the timestamp triggered by the scheduler. If the call record only provides a start time and an end time, the start time is used as the call time identifier, and the end time is written into an extended field for timeout determination. The tool identifier is generated from a unique identifier in the tool manifest. During the deployment phase, the tool manifest maintains metadata such as tool name, version, interface type, read / write capabilities, and allowed object scope. The tool identifier is obtained by matching the tool name and version in the call record with the tool manifest. The read / write attribute identifier is determined jointly based on the tool metadata and the call intent: when the tool metadata indicates the ability to change external states, or when the call parameters contain intent fields such as submit, update, delete, synchronize, or publish, the read / write attribute identifier is marked as a write attribute; otherwise, it is marked as a read attribute. The result code identifier is uniformly mapped from the call return status. The mapping rules classify normal returns as success result codes and timeouts, permission denials, invalid parameters, external dependency failures, and internal exceptions as different failure result codes. The retry status identifier is formed by merging the retry count, retry reason, and final result fields in the call record. When the same call is attempted multiple times within the retry window, it is merged into the same call chain, and whether a retry occurred, the retry count range, and whether it ultimately succeeded are recorded. The idempotency condition identifier is jointly determined by the idempotency declaration in the tool manifest and the call parameter characteristics: if the tool manifest declares the interface idempotent, or the call parameters contain fields such as idempotency keys, deduplication keys, and request unique numbers and meet the format validation rules, it is marked as meeting the idempotency condition; otherwise, it is marked as not meeting the idempotency condition. Deduplication and merging are performed on the call entry set. The deduplication key consists of the tool identifier, call time identifier, and call parameter summary to avoid the same call being collected multiple times.

[0094] Write type records are generated by classifying the call entry set according to preset write type rules. Specifically, write type classification is performed on call entries in the call entry set whose read / write attribute is identified as write attribute. The write type rule base is maintained in the form of a mapping from "tool identifier plus call intent to write type". The write type is used to express the side effect of the write operation and includes at least categories such as add, modify, delete, trigger, and external synchronization. When classifying, the interface category label provided by the tool list is used first. If the tool list does not label or the call intent field is missing, the call parameter keyword matching rule is used to extract the action semantics from the parameter name, path field, and action field to complete the classification. When the same tool has multiple write operations in the same call chain, the write type merging rule is used to retain the type with stronger side effect as the write type result of the call chain and generate a write type record. The write type record is stored in association with the tool identifier and the call chain identifier.

[0095] Based on preset scope rules, the set of call entries is categorized to generate object scope records. Specifically, object scope categorization is performed on write call entries, with the object scope used to express the coverage boundary and propagation probability of the write impact. The scope rule library is maintained in the form of "tool identifier plus object field rules," specifying the parsing methods for object identifier fields, object hierarchy fields, and batch identifier fields for different tools. During object scope categorization, the object identifier field in the call parameters is parsed first to determine if it is a single object write, then the object hierarchy field is parsed to determine if the write occurred on a higher-level object, and finally the batch identifier field or list field is parsed to determine if it is a batch write. When the object identifier field is missing, a fallback rule is used to infer the object boundary using information such as the call path, namespace, and resource locator; if it cannot be inferred, the object scope is marked as an unknown scope, and the risk orientation of subsequent hierarchical mapping is improved. For multiple object scope results within the same call chain, a scope merging rule is used to output an object scope with a larger coverage, generating an object scope record and storing it in association with the tool identifier and call chain identifier.

[0096] Based on preset hierarchical rules, a hierarchical mapping is performed on write type records, object range records, retry status identifiers, and idempotent condition identifiers to generate write impact levels. Specifically, write type records, object range records, retry status identifiers, and idempotent condition identifiers are associated according to the call chain identifier to form the input for write impact assessment. The preset hierarchical rules are maintained in the form of a level mapping table, with each level corresponding to a set of judgment conditions. The judgment conditions are composed of the write type range, object range range, retry status range, and idempotent condition status. The hierarchical mapping follows the order of "side effects first, scope second, stability correction": First, the basic risk level is determined based on the write type, with deletion and triggering classes at a higher level than addition and modification classes. Then, the basic level is adjusted upwards or downwards based on the object scope, with batch writes and high-level object writes prioritized for upward adjustment, while single object writes can be maintained or downwards. Next, the level is corrected for stability based on the retry status flag, with upward adjustment occurring when repeated retries occur and the result code is marked as failure, and maintaining a higher level when a retry succeeds but the number of retries falls into a high range. Finally, recoverability correction is performed based on the idempotency condition flag, allowing moderate downward adjustment under the same write type and object scope when the idempotency condition is met, and maintaining or increasing the level when the idempotency condition is not met. After matching is complete, the write impact level is output, and the write impact level is associated with the tool flag, call chain flag, and task flag and written to the governance data storage area.

[0097] The present invention is further configured such that the generation of orchestration drift levels based on the step orchestration diagram and execution sequence includes:

[0098] The baseline step sequence identifier and baseline branch selection identifier are obtained based on the baseline step sequence records associated with the task semantic tags. Specifically, when generating orchestration drift levels, the baseline step sequence record library is first accessed based on the task semantic tags, and the baseline step sequence record that matches the task semantic tag and is in an active state is selected. Each record in the baseline step sequence record library contains at least a task semantic tag, a version identifier, an effective time identifier, a baseline step sequence identifier sequence, and a baseline branch selection identifier sequence. The version identifier is used to distinguish different historical baselines, and the effective time identifier is used to determine the baseline version to be used currently. The selection rule adopts a combination of "priority effective version and latest written version": when there is a clearly effective version, the effective version is used first; when there are multiple effective versions, the version with the latest write time is used; when there is no effective version, the version with the latest write time under the same task semantic tag is used. After the selection is completed, the baseline step sequence identifier sequence and the baseline branch selection identifier sequence are extracted from the baseline step sequence record as the baseline reference sequence for subsequent comparisons. To avoid the inability to assess drift due to missing baseline sequences, a missing handling rule is set: when there is no record with the corresponding task semantic tag in the baseline step sequence record library, the current execution sequence is used to write a temporary baseline record, and the drift level is set to the lowest deviation level or the preset default level. At the same time, the temporary baseline record is marked as pending confirmation for processing in the subsequent rule update stage.

[0099] The execution sequence's step sequence identifiers and branch selection identifiers are compared with the baseline step sequence identifiers and baseline branch selection identifiers to generate step set difference records, order deviation records, and branch deviation records. Specifically, the sequence of step sequence identifiers and the sequence of branch selection identifiers in the execution sequence are used as the evaluated sequence and compared with the baseline reference sequence. The comparison process adopts a "separation of step set difference identification and order deviation identification" approach to ensure that the source of the difference is interpretable and the records are reusable. Step set difference identification first merges the step identifier sets in the two sequences to form a baseline set and an execution set. After comparison, a missing step identifier set and a new step identifier set are generated. The missing step identifier set represents steps that exist in the baseline but are not present in the execution, and the new step identifier set represents steps that exist in the execution but are not present in the baseline. Both together constitute the step set difference record. Order deviation identification is performed based on the alignment of the step identifier sets. The alignment rule is to prioritize aligning the same step identifier. If duplicate step identifiers are found, they are aligned one by one according to their order of appearance in the sequence. After alignment, the relative order of the same aligned steps in the two sequences is compared. If the relative order is different from the baseline, it is recorded as a order deviation entry, and these are summarized to form the order deviation record. Branch deviation identification compares the branch selection identifier sequence. The branch selection identifier indicates the path type entered in the conditional branches of the ordination diagram. The comparison rule is to compare whether the branch selection identifiers are consistent at the branch nodes corresponding to the same step identifier. If they are inconsistent, a branch deviation entry is generated, and the results are summarized to form a branch deviation record. To avoid misjudging deviations simply because the baseline lacks optional branches, branch deviation identification introduces a branch availability rule: when the step ordination diagram identifies the branch as a degraded path and it is triggered by tool unavailability, the branch deviation entry is marked as an acceptable deviation category for de-weighting during subsequent hierarchical mapping.

[0100] Based on preset grading rules, a grading mapping is performed on step set difference records, sequence deviation records, and branch deviation records to generate orchestration drift levels. Specifically, step set difference records, sequence deviation records, and branch deviation records are used as inputs for grading mapping, and orchestration drift levels are generated according to preset grading rules. The preset grading rules are maintained in the form of a grading mapping table. The grading mapping table configures judgment conditions for different drift levels. The judgment conditions at least include the severity range of step set differences, the coverage range of sequence deviations, and the critical branch triggering range of branch deviations. The severity range of step set differences is determined based on the type importance of missing and newly added steps. Step importance is given by the step type importance table; missing or newly added critical steps are prioritized for higher drift levels. The coverage range of sequence deviations is determined based on whether the deviation item crosses a strong dependency boundary; deviations that cross strong dependency boundaries are prioritized for higher levels. The critical branch triggering range of branch deviations is determined based on whether the deviation occurs at a main path branch node; main path branch deviations are prioritized for higher levels, while degraded path deviations are allowed to maintain or lower their levels if the branch availability rules are met. The hierarchical mapping adopts a high-to-low matching method. First, it checks whether the high drift level condition is met. If not, it checks the lower level conditions in turn until a match is successful and outputs the drift level. The output orchestration drift level is associated with the task semantic label, the baseline step sequence record version identifier, and the execution sequence version identifier for storage, so as to support the traceability and reuse of the governance instruction set generation and rule update stages.

[0101] The present invention is further configured such that generating the governance instruction set based on the evidence consistency level, write impact level, and orchestration drift level includes:

[0102] A mapping between level combinations and instruction item sets is established based on preset instruction generation rules. Specifically, the preset instruction generation rules are maintained in the form of a rule table, which maps combinations of evidence consistency level, write impact level, and orchestration drift level to instruction item set templates. Each rule in the rule table contains at least three level condition items and a set of instruction item template items. The level condition items correspond to the evidence consistency level range, write impact level range, and orchestration drift level range, respectively. The instruction item template items provide the branch selection type, available tool range category, call limit range, timeout threshold range, retry count range, and compensation condition category. The matching order of the rule table adopts a "risk-first" principle, prioritizing the matching of combinations with higher write impact levels, lower evidence consistency levels, or higher orchestration drift levels to ensure that stricter constraints are applied under high-risk or high-uncertainty conditions. To avoid rule conflicts, each rule in the rule table is set with a mutual exclusion condition. The mutual exclusion condition is used to limit that only one rule can be matched for the same level combination. When multiple rules are matched at the same time, the priority field is used for adjudication. The priority field is maintained by the rule base and sorted in descending order of risk level. Finally, the rule with the highest priority is selected as the source of the instruction item set template for that level combination.

[0103] Within the step orchestration diagram, step identifiers are used as association keys to link evidence consistency level, write impact level, and orchestration drift level to step identifiers, generating step governance status. Specifically, a step governance status record is constructed for each step using step identifiers as association keys in the step orchestration diagram. The association method employs a strategy combining "primary key alignment and inheritance backfilling": when evidence consistency level, write impact level, and orchestration drift level can directly correspond to a step identifier, the level is directly written into the governance status of that step; when a level only corresponds to the topic or tool level and cannot be directly linked to a step identifier, backfilling is performed based on the association relationships between steps and tools, and steps and topics in the step orchestration diagram. The write impact level at the tool level is backfilled to the step that references the tool, and the evidence consistency level at the topic level is backfilled to the step that depends on the evidence of that topic; if backfilling is still not possible, a default level is used for backfilling. The default level is defined by the rule table and corresponds to the most conservative governance strategy. The step governance status record includes at least the step identifier, evidence consistency level, writing impact level, orchestration drift level, and step type identifier. The step type identifier is used to select a step type-specific rule when refining the values ​​of subsequent instruction items.

[0104] Based on the step governance status and preset instruction generation rules, a set of instruction items associated with the step identifier is generated. This set includes values ​​for branch selection, tool scope constraints, call limits, timeout thresholds, retry counts, and compensation conditions. Specifically, instruction item set generation is performed for each step governance status record in the step orchestration diagram. The generation process takes a level combination as input, first matching an instruction item set template in the rule table, and then refining the template items using step-type specific rules. Branch selection values ​​are determined based on orchestration drift level and branch deviation category. When the drift level is in the high deviation range, branch selection is restricted to the main path or a preset degraded path; when the drift level is in the low deviation range, the original branch selection is allowed. Tool scope constraints are determined based on the write impact level and the tool metadata access scope category. The higher the write impact level, the more convergent the allowed tool scope; if necessary, only read-only tools or idempotent write tools are allowed. The call limit is determined based on the write impact level and retry strategy constraints. Higher write impact levels result in lower call limits to avoid repeatedly triggering external side effects. For steps marked as read-only, the call limit can be adjusted by the evidence consistency level. When the evidence consistency level is low, the retrieval attempt limit is increased to supplement evidence, but it is still subject to resource threshold constraints. The timeout threshold is determined based on the historical statistical interval of the tool response distribution. The tool response distribution is maintained by the runtime records, and the rule table contains preset threshold intervals for different tool categories. Higher write impact levels lead to a more conservative timeout threshold to avoid prolonged resource occupation. The number of retries is determined based on the result code category and idempotency conditions. More retries are allowed when idempotency conditions are met; otherwise, the number of retries is limited, and the compensation condition trigger path is prioritized. The compensation condition is determined based on the step type and write impact level. Higher write impact levels make compensation conditions more likely to be triggered, and the compensation strategy prioritizes rollback or offsetting compensation steps. After the value is obtained, a set of instruction items associated with the step identifier is formed, and the set of instruction items is written into the step instruction table so that the scheduling and execution phase can directly obtain the corresponding governance constraints according to the step identifier.

[0105] A set of instructions is compiled to form a governance instruction set. This governance instruction set is then stored in association with task identifiers and instruction version identifiers. Specifically, the instruction set corresponding to all step identifiers is organized according to the step sequence identifiers in the step arrangement diagram to form the governance instruction set. The governance instruction set is associated with the task identifier during storage to identify a single governance output of the same task. Simultaneously, an instruction version identifier is generated to support reuse and backtracking. The instruction version identifier is generated using a content fingerprint method, combining key fields from the level combination, rule table version, step identifier set, and each step's instruction item set to form an instruction fingerprint. If the instruction fingerprints are the same, the same instruction version identifier is reused; otherwise, a new instruction version identifier is generated. The governance instruction set, along with the task identifier and instruction version identifier, is written to the governance instruction storage area, and a dual index based on the task identifier and step identifier is established to support rapid retrieval of the corresponding step's governance constraint values ​​during the scheduling and execution phase.

[0106] The present invention is further configured such that the step of scheduling and executing according to the governance instruction set to form an operation process record includes:

[0107] A step scheduling sequence is generated based on the step orchestration diagram and governance instruction set. This sequence is associated with task identifiers. Specifically, the step orchestration diagram is expanded into an executable form, and the step dependencies within it are used as scheduling constraints. The execution path is determined by combining the branch selection values ​​corresponding to each step identifier in the governance instruction set. The scheduling sequence generation employs a dependency-ready progression approach: at any given time, all ready steps with satisfied prerequisite dependencies are selected as a candidate set, and the execution order within this set is determined according to step scheduling priority rules. These rules comprehensively consider step type priority and the strength of governance instruction constraints, prioritizing steps with higher constraint strength within a controllable window to trigger compensation paths or termination strategies as early as possible in case of anomalies. The generated result forms a step scheduling sequence. This sequence records step identifiers according to their sequence positions and binds them to task identifiers, writing them into the scheduling queue list so that the scheduler can locate the execution sequence corresponding to the task using the task identifier.

[0108] During the execution of the step scheduling sequence, a set of instruction items associated with each step identifier is obtained. Execution constraints are applied to the tool scope, call limit, timeout threshold, retry count, and compensation conditions based on the instruction item set. The corresponding step is then executed. When the compensation conditions are met, the compensation step is executed according to the compensation relationship. Specifically, during the execution of the step scheduling sequence, the set of instruction items for the current step identifier is obtained and converted into executable constraints. Tool scope constraints are implemented through a tool whitelist, meaning only tool identifiers within the allowed range of the instruction item set are allowed. If the tool required by the step is not within the allowed range, a branch selection fallback rule is triggered, prioritizing switching to an alternative step or downgrade path allowed by the governance instructions. The call limit is implemented through a call counter, which records the number of calls using the task identifier and step identifier as keys. When the call count reaches the call limit, calls stop and compensation is initiated. The timeout threshold is implemented through an execution gatekeeper mechanism, binding a timeout timer to each step. When the execution time of a step exceeds the timeout threshold, the result code is set to a timeout failure, and retry is initiated. The number of retries is controlled by retry rules. These rules first determine if the idempotency condition is met. If it is, retries are allowed within the maximum number of retries. If not, the number of retries is limited, and compensation conditions are triggered first. Compensation conditions are determined by the instruction set, which includes at least failure result code triggers, timeout triggers, call limit triggers, dependency missing triggers, and resource threshold triggers. When any compensation trigger category is met, the corresponding compensation step identifier sequence is located based on the compensation relationship in the step orchestration diagram. This sequence is then inserted into the current execution position of the step scheduling sequence, forming a compensation execution path. Simultaneously, the compensation status is set to triggered, and the compensation step is executed according to the same governance instruction constraint rules. If the compensation step still triggers the compensation condition, the number of compensation layers is limited according to the compensation cascading restriction rules. If the limit is exceeded, the step chain is terminated, and the termination reason is recorded.

[0109] Each step generates an execution entry, which includes a task identifier, step identifier, instruction version identifier, call summary identifier, result code identifier, retry status identifier, compensation status identifier, and resource consumption identifier. Specifically, an execution entry is generated upon completion or termination of each step. The task identifier and step identifier are the primary key fields for each execution entry. The instruction version identifier is inherited from the governance instruction set and is used to identify the governance strategy version used in this execution. The call summary identifier is formed by merging tool call summaries generated during step execution. The merging rules encode the tool identifier, call count range, key return status, and exception reason into a summary identifier, supporting traceability without carrying sensitive content. The result code identifier is generated based on the final status of the step, which includes categories such as successful completion, failed termination, timeout termination, restricted termination, and compensation completion, and is mapped to the corresponding result code identifier. The retry status identifier is generated by retry control rules and includes at least whether a retry was attempted, the retry count range, and whether the final status was successful. The compensation status identifier is formed by merging the compensation trigger category and compensation execution result and includes at least the statuses of not triggered, triggered successfully, triggered failed, and compensation terminated. The resource consumption identifier is obtained by the operation monitor by sampling the step execution window. The sampling method defines the window by the start and end time of the step. The resource sampling results within the window are merged into intervals, and a unified resource consumption identifier is output and written into the step execution entry.

[0110] The execution process is recorded by aggregating items step by step. An index is created based on task and step identifiers. Specifically, all execution items under the same task identifier are grouped according to their sequential position in the step scheduling sequence to form the execution process record. The execution process record retains the sequence number of each execution item, the step identifier, and various status identifiers, enabling it to fully express the execution path, retry, and compensation behaviors. To support subsequent hierarchical rule updates and governance instruction updates, the execution process record is indexed during storage: a task-level index is created using the task identifier, a step-level index is created using the step identifier, and the instruction version identifier is used as an auxiliary index field to aggregate and statistically analyze execution results according to governance policy versions. After the execution process record is written to the execution process storage area, a record reference identifier is output to the subsequent update process, allowing the update process to locate the corresponding execution process record and extract the required items using the record reference identifier.

[0111] The present invention is further configured such that updating the hierarchical rules based on the running process records includes:

[0112] Retrieve the hierarchical rule versions associated with the task semantic tags. These versions include thresholds for evidence consistency, write impact, and orchestration drift. Specifically, access the hierarchical rule version library using the task semantic tags as the index key and select the version currently in effect. If multiple versions exist, select the one with the latest write time. If no version exists, select the version with the latest write time under the same task semantic tag as the baseline version. Each hierarchical rule version contains at least three sets of threshold items: evidence consistency threshold, write impact threshold, and orchestration drift threshold. Each set of threshold items expresses the level classification threshold using interval boundaries and includes a threshold item identifier, an applicable object identifier, and an updatable identifier. The applicable object identifier limits which topics, tool categories, or step types the threshold items apply to. The updatable identifier limits which threshold items are allowed to be updated online, preventing the rewriting of manually fixed compliance or security thresholds. After the baseline version is determined, the set of updatable threshold items is extracted as the target threshold set for this update.

[0113] Based on the operation process record, result code identifiers, retry status identifiers, compensation status identifiers, and resource consumption identifiers are extracted to form a threshold adjustment record. Specifically, using the operation process record as input, the result code identifiers, retry status identifiers, compensation status identifiers, and resource consumption identifiers are extracted step by step. The step identifiers are then associated with the step type identifier and the referenced tool identifier to form an attributable set of operation observations. Subsequently, observation merging and interval processing are performed to generate the threshold adjustment record. The merging rules include three categories: the first is stability merging, which combines retry status and result code to merge into stability statuses, distinguishing between success on the first attempt, success after retry, failure after retry, and timeout termination; the second is compensation merging, which merges compensation statuses into compensation not triggered, compensation triggered successfully, compensation triggered unsuccessfully, and compensation terminated; the third is resource merging, which merges resource consumption identifiers according to preset interval boundaries into resource pressure statuses, distinguishing between low pressure, normal pressure, high pressure, and overload pressure. The threshold adjustment record uses the task semantic tag as the outer key and the topic identifier, tool category identifier, and step type identifier as the inner key. It records the aggregated results of the stability status, compensation status, and resource pressure status corresponding to different levels of judgment results, and retains the aggregation cycle identifier to limit the time window for updating, so as to avoid drastic changes in the threshold caused by a single abnormal fluctuation.

[0114] Based on the threshold adjustment records, threshold updates are performed on the evidence consistency level threshold, write impact level threshold, and orchestration drift level threshold to form an updated grading rule version. Specifically, threshold updates are performed item by item on the target threshold set, following the order of "constraining resources and writes first, then correcting evidence and drift" to ensure that risk control takes priority. For the write impact level threshold, when the threshold adjustment records show frequent failures after retrying or compensation triggering failures at relatively low write impact levels, the interval boundary corresponding to that level is adjusted to a stricter direction, so that more similar calls are classified into higher write impact levels. When a single success is maintained for a long time at a higher write impact level and resource pressure is at a low or normal level, the interval boundary is allowed to be moderately relaxed within the range allowed by the updatable identifier, but the conservative classification of high write types and large object ranges is still maintained. For the orchestration drift level threshold, when the threshold adjustment record shows a low drift level but dependency loss termination or frequent compensation triggers still occur, the sensitivity threshold corresponding to the order deviation or branch deviation is increased to make it easier to enter a higher drift level. When the drift level is high but the running results are stable and compensation is not triggered, the weight of the acceptable deviation category is allowed to be reduced, making acceptable deviations more likely to fall into the low to medium drift level. For the evidence consistency level threshold, when the evidence consistency level is high but the result code is still frequently in the failure category or compensation trigger failure occurs, the threshold for the coverage of supporting relationships and the proportion of timeliness is tightened to reduce the probability of insufficient evidence being judged as high consistency. When the evidence consistency level is low but stable success is achieved after increasing retrieval attempts and resource pressure is controllable, some evidence combinations with unknown timeliness or scattered sources are allowed to be upgraded to the medium level to reduce process blockage caused by excessive conservatism. The threshold update magnitude is constrained by the update step size rule, which sets the maximum adjustment magnitude and minimum adjustment interval for each threshold item to avoid threshold oscillation. When there are insufficient observations or insufficient samples within the aggregation cycle, the original threshold is kept unchanged and recorded as no update. After completing the update of each threshold item, an updated hierarchical rule version is generated. The updated hierarchical rule version inherits the non-updatable threshold items of the baseline version, replaces the updatable threshold items with the updated threshold item set, and records the threshold adjustment record identifier referenced in this update.

[0115] The updated hierarchical rule version is written to the hierarchical rule version repository. The updated hierarchical rule version is associated with the task semantic tag, version identifier, and effective time identifier. Specifically, a version identifier is generated for the updated hierarchical rule version. The version identifier is formed using a content fingerprint method, which is generated by combining the task semantic tag, the baseline version identifier, the key boundary values ​​of the updated threshold item set, and the update reference identifier to ensure that the same version identifier can be reused for the same update result. The effective time identifier is determined by the activation strategy, which includes at least two modes: immediate activation and delayed activation. Immediate activation is used for situations requiring rapid convergence of governance strategies, while delayed activation is used for situations requiring verification of the update effect within a window period. The window period length is configured by the version repository. The updated hierarchical rule version is associated with the task semantic tag, version identifier, and effective time identifier and written to the hierarchical rule version repository. This version identifier is also written back to the rule reference table of subsequent governance processes, enabling subsequent tasks to call the updated hierarchical rule version when generating evidence consistency levels, writing impact levels, and orchestration drift levels.

[0116] The present invention is further configured such that updating the governance instruction set based on the running process record includes:

[0117] The process involves obtaining governance instruction set generation rules and value benchmarks. These benchmarks include call limit values, timeout threshold values, retry count values, and compensation condition values. Specifically, the governance rule base is accessed using task semantic tags as index keys to retrieve currently effective governance instruction set generation rules. These rules are maintained in a rule table, which contains matching logic between level combinations and instruction item set templates, as well as value correction rules specific to step types. Then, the value benchmark library is accessed using task semantic tags to select an effective governance instruction set value benchmark. When multiple effective versions exist, the version with the latest write time is selected; when no effective version exists, the version with the latest write time under the same task semantic tag is selected as the baseline value benchmark. The baseline value benchmark includes at least call limit values, timeout threshold values, retry count values, and compensation condition values, and its value entries are maintained using "step type and tool category as index keys," allowing the same value benchmark to adapt to different steps and tool categories. Each value carries both an updatable identifier and a boundary constraint identifier. The updatable identifier limits which value entries are allowed to be adjusted online, while the boundary constraint identifier limits the minimum and maximum range of adjustable values ​​to prevent value updates from exceeding limits, which could lead to governance failure or excessive convergence. After the baseline value benchmark is determined, the updatable value entries are extracted as the target value set for this update.

[0118] Based on the execution process record, the instruction version identifier, call summary identifier, result code identifier, retry status identifier, and compensation status identifier associated with the step identifier are extracted to form a value adjustment record. Specifically, using the execution process record as input, the step identifier, instruction version identifier, call summary identifier, result code identifier, retry status identifier, and compensation status identifier are extracted for each step execution item. The step identifier is then associated with the step type identifier and the tool category identifier used to form an attributable set of execution observations. The call summary identifier is used to express the range of call counts, key anomaly cause categories, and key tool identifier sets during the execution of that step, enabling value updates to distinguish between anomalies caused by insufficient call limits, excessively tight timeout thresholds, mismatched retry counts, or unreasonable compensation condition triggering. Subsequently, the runtime observation set is merged into intervals to form value adjustment records: result codes are merged into success and failure categories, further subdivided into timeout failures, permission failures, external dependency failures, and internal exception failures; retry status codes are merged into no retry, few retries, frequent retries, and failure after retry; compensation status codes are merged into not triggered, triggered successfully, triggered failed, and compensation terminated. The value adjustment records use task semantic tags as outer keys and step type and tool category codes as inner keys, recording the aggregated runtime status results corresponding to each value under the current baseline value, and recording the aggregation period identifier to limit the time window for value updates, avoiding drastic value fluctuations caused by a single anomaly.

[0119] Based on the value adjustment records, the values ​​for the call limit, timeout threshold, retry count, and compensation condition are updated to form a baseline for the updated governance instruction set. Specifically, the target value set is updated item by item, following the order of "timeout and retries first, then call limit, and finally compensation condition" to ensure priority for execution stability. For the timeout threshold, when the value adjustment records show frequent timeout failures and the call summary indicates long external call wait times, the timeout threshold is adjusted to be more lenient. When the resource consumption indicator is under high or overload pressure for a long time and queuing failures occur due to prolonged occupation, the timeout threshold is adjusted to be more conservative to reduce resource consumption. For the retry count, when frequent retries result in a significantly improved success rate and the idempotency condition is reusable in the call summary, the number of retries can be moderately increased. When frequent retries still end in failure or the proportion of compensation-triggered failures increases, the number of retries is decreased, and this failure category is prioritized for compensation condition triggering. For the call limit value item, when the result code indicates that the step was terminated due to the call limit and the call summary indicates that there are still alternative tools or room for further retrieval, the call limit can be increased; when the write-type tool shows a risk of repeated triggering or frequent compensation triggering in the call summary, the call limit is decreased to reduce the accumulation of external side effects. For the compensation condition value item, when the compensation status indicator frequently shows "triggered successfully" and can significantly improve the final result code, the compensation triggering condition is appropriately relaxed to allow it to intervene at an earlier stage; when the compensation status indicator frequently shows "triggered failed" or "compensation terminated," the compensation triggering condition is tightened and the compensation condition category is adjusted to a more controllable triggering type, such as changing from triggering any of multiple conditions to triggering a critical failure category. Value updates are controlled by boundary constraint indicators and are not allowed to exceed the preset minimum and maximum value range; they are also controlled by update step size rules, which set a maximum adjustment range and a minimum adjustment interval for each type of value item to prevent value oscillation; when there are insufficient observations or the running status is unstable within the aggregation cycle, the original value is kept unchanged and recorded as a no-update state. After the value update is completed, an update governance instruction set value baseline is formed. The updated value baseline inherits the non-updatable entries of the baseline value baseline, replaces the updatable entries with the updated value entry set, and records the value adjustment record identifier referenced in this update.

[0120] The updated governance instruction set value benchmark is associated with the task semantic tag and instruction version identifier and written into the value benchmark library. The governance instruction set generation rules call the updated governance instruction set value benchmark when generating subsequent governance instruction sets. Specifically, a benchmark version identifier is generated for the updated governance instruction set value benchmark. The benchmark version identifier is formed using a content fingerprint method. The content fingerprint is generated by combining the task semantic tag, the baseline value benchmark version identifier, the key range of the updated value item, and the value adjustment record identifier to ensure that the same version identifier can be reused for the same update result. The updated governance instruction set value benchmark is associated with the task semantic tag and instruction version identifier and written into the value benchmark library, and an effective time identifier is written at the same time. The effective time identifier is determined by the effective strategy, which includes two modes: immediate effective and window verification effective, to ensure that the value update has a controllable switching mechanism. When generating governance instruction sets, the rules for generating governance instruction sets use task semantic tags and step type identifiers as index keys to retrieve effective value entries from the value benchmark library. The rules use call limits, timeout thresholds, retry counts, and compensation conditions as the source of values ​​for the instruction set, thereby enabling the governance instruction set values ​​to be updated in a closed loop as the running process progresses and to be continuously reused.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for constructing, orchestrating, and governing enterprise intelligent agents, characterized in that, include: Based on the collected task inputs, tool call records, retrieval evidence records, and runtime resource records, a task event sequence is generated, and a step arrangement diagram and execution sequence are generated based on the task event sequence. Based on preset grading rules, an evidence consistency level is generated based on retrieved evidence records, a write impact level is generated based on tool call records, and an orchestration drift level is generated based on the step orchestration diagram and execution sequence. Generate a set of governance instructions based on the evidence consistency level, the write impact level, and the orchestration drift level; The execution steps are scheduled according to the governance instruction set, and an operation process record is generated. The hierarchical rules and governance instruction set are updated based on the operation process records.

2. The enterprise intelligent agent construction, orchestration, and governance method according to claim 1, characterized in that, Based on the collected task inputs, tool call records, retrieval evidence records, and runtime resource records, a task event sequence is generated, including: Generate task events based on task input, including task identifiers, task time identifiers, and task semantic tags; Based on the tool call record, a call event is generated, including a task identifier, call time identifier, tool identifier, read / write attribute identifier, and result code identifier; Evidence events are generated based on retrieved evidence records, including task identifiers, evidence time identifiers, evidence source identifiers, and evidence conclusion identifiers; Resource events, including task identifier, sampling time identifier, and resource consumption identifier, are generated based on the runtime resource records. Task events, invocation events, evidence events, and resource events are aggregated based on task identifiers, and then sorted by time identifiers to generate a task event sequence.

3. The enterprise intelligent agent construction, orchestration, and governance method according to claim 2, characterized in that, The step-by-step arrangement diagram and execution sequence generated based on the task event sequence include: Extract task semantic tags from task events in the task event sequence, and extract tool sets from call events in the task event sequence; Generate a set of steps based on task semantic tags and tool set, and assign step identifiers to the set of steps; Based on preset dependency rules, step dependencies and branch condition relationships are generated within the step set to form a step arrangement diagram; An execution sequence that satisfies the dependency relationship is generated based on the step dependency relationship. The execution sequence includes a step order identifier and a branch selection identifier. The execution sequence is written into the baseline step sequence record associated with the task semantic label. Compensation relationships are generated within the step arrangement diagram according to preset compensation rules, and the compensation relationships are associated with step identifiers and written into the step arrangement diagram.

4. The enterprise intelligent agent construction, orchestration, and governance method according to claim 1, characterized in that, Based on preset grading rules and the retrieved evidence records, the evidence consistency level is generated as follows: Based on the retrieved evidence records, an evidence item set is extracted. The evidence item set includes evidence time identifier, evidence source identifier, subject identifier, and evidence conclusion identifier. Based on the preset relationship discrimination rules, the evidence item set is subjected to relationship discrimination to generate supporting relationship records and conflicting relationship records; Based on preset statute of limitations rules, the statute of limitations is determined on the set of evidence items, and a statute of limitations status record is generated. Based on preset hierarchical rules, hierarchical mapping is performed on supporting relationship records, conflicting relationship records, and time-limited status records to generate evidence consistency levels.

5. The enterprise intelligent agent construction, orchestration, and governance method according to claim 1, characterized in that, The impact levels of writes generated based on tool call records include: Extract the call entry set based on the tool call record. The call entry set includes call time identifier, tool identifier, read / write attribute identifier, result code identifier, retry status identifier, and idempotency condition identifier. Based on preset write type rules, the call entry set is categorized by type to generate write type records; Based on preset scope rules, the call item set is categorized by scope to generate object scope records; Based on preset hierarchical rules, hierarchical mapping is performed on write type records, object range records, retry status flags, and idempotent condition flags to generate write impact levels.

6. The enterprise intelligent agent construction, orchestration, and governance method according to claim 3, characterized in that, The orchestration drift levels generated based on the step orchestration diagram and execution sequence include: Obtain the baseline step sequence identifier and baseline branch selection identifier based on the baseline step sequence record associated with the task semantic label; Compare the step sequence identifiers and branch selection identifiers in the execution sequence with the baseline step sequence identifiers and baseline branch selection identifiers to form step set difference records, sequence deviation records, and branch deviation records. Based on preset grading rules, a grading mapping is performed on the step set difference records, sequence deviation records, and branch deviation records to generate an orchestration drift level.

7. The enterprise intelligent agent construction, orchestration, and governance method according to claim 1, characterized in that, The governance instruction set generated based on the evidence consistency level, write impact level, and orchestration drift level includes: Establish a correspondence between level combinations and instruction item sets based on preset instruction generation rules; Within the step arrangement diagram, the step identifier is used as the association key to associate the evidence consistency level, the writing impact level, and the arrangement drift level with the step identifier to generate the step governance status. Based on the step governance status and preset instruction generation rules, a set of instruction items associated with the step identifier is generated. The set of instruction items includes the values ​​of branch selection, tool scope constraint, call limit, timeout threshold, number of retries and compensation conditions. The collection of instructions is aggregated to form a governance instruction set, which is then stored in association with task identifiers and instruction version identifiers.

8. The enterprise intelligent agent construction, orchestration, and governance method according to claim 1, characterized in that, The execution steps are scheduled according to the governance instruction set, and the resulting operation process record includes: A step scheduling sequence is generated based on the step arrangement diagram and the governance instruction set, and the step scheduling sequence is associated with the task identifier; During the process of advancing the step scheduling sequence, the set of instruction items associated with the step identifier is obtained according to the step identifier. Execution constraints are applied to the tool scope, call limit, timeout threshold, number of retries and compensation conditions according to the set of instruction items. The corresponding steps are executed. When the compensation conditions are met, the compensation steps are executed according to the compensation relationship. For each step, a step execution entry is formed. The step execution entry includes task identifier, step identifier, instruction version identifier, call summary identifier, result code identifier, retry status identifier, compensation status identifier, and resource consumption identifier. The process is recorded by collecting entries step by step and indexed based on task identifiers and step identifiers.

9. The enterprise intelligent agent construction, orchestration, and governance method according to claim 2, characterized in that, The hierarchical rules are updated based on the operation process records, including: Obtain the hierarchical rule version associated with the task semantic label. The hierarchical rule version includes the evidence consistency level threshold, the write impact level threshold, and the orchestration drift level threshold. Based on the result code identifier, retry status identifier, compensation status identifier, and resource consumption identifier extracted from the operation process record, a threshold adjustment record is formed; Based on the threshold adjustment records, threshold updates are performed on the evidence consistency level threshold, the write impact level threshold, and the orchestration drift level threshold to form an updated grading rule version. Write the updated hierarchical rule version to the hierarchical rule version repository, and associate the updated hierarchical rule version with the task semantic tag, version identifier, and effective time identifier.

10. The enterprise intelligent agent construction, orchestration, and governance method according to claim 2, characterized in that, The governance instruction set is updated based on the operation process records, including: Obtain the governance instruction set generation rules and the governance instruction set value benchmark. The governance instruction set value benchmark includes the call limit value item, the timeout threshold value item, the retry count value item, and the compensation condition value item. Based on the operation process record, extract the instruction version identifier, call summary identifier, result code identifier, retry status identifier, and compensation status identifier associated with the step identifier to form a value adjustment record; Based on the value adjustment records, the values ​​of the call limit, timeout threshold, retry count, and compensation condition are updated to form the value benchmark for the update governance instruction set; The updated governance instruction set value benchmark is associated with the task semantic tag and instruction version identifier and written into the value benchmark library. The governance instruction set generation rules call the updated governance instruction set value benchmark when generating governance instruction sets in the future.

Images