A runtime cascading governance system and method based on execution right dependency graph
By using a runtime cascading governance system based on execution right dependency graphs, the problems of anomaly propagation control and governance boundary identification are solved, achieving efficient recovery and controllability of complex runtime systems and improving the stability and traceability of multi-entity collaboration.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 蒋欣飏
- Filing Date
- 2026-06-09
- Publication Date
- 2026-07-31
AI Technical Summary
The lack of a unified governance mechanism in existing technologies makes it difficult to identify the scope of the spread of abnormal states and the boundaries of governance, leading to the continuous spread of abnormal results, increased governance costs, and deviations from expected actions.
A runtime cascading governance system based on execution right dependency graphs is adopted. By constructing execution right dependency graphs, snapshots, influence subgraphs, and governance boundary nodes, the system can control the propagation of anomalies and identify governance boundaries.
It improves the coordination consistency, recovery efficiency and operational controllability of complex runtime systems, reduces the risk of anomaly propagation, and enhances the stability of multi-entity collaboration and the traceability of execution behavior.
Smart Images
Figure CN122489335A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence runtime system technology.
[0002] Specifically, this involves runtime governance technology, multi-agent collaborative control technology, runtime dependency management technology, anomaly propagation control technology, and recovery governance technology.
[0003] In particular, it relates to a runtime cascading governance system and method based on execution right dependency graph. Background Technology
[0004] With the development of large language model technology, intelligent agent systems are gradually acquiring autonomous planning capabilities, multi-step reasoning capabilities, tool invocation capabilities, code execution capabilities, long-cycle task execution capabilities, and multi-agent collaboration capabilities.
[0005] In actual operation, a complex task is usually completed by multiple runtime objects. For example, the task planning entity is responsible for generating the task plan, the execution entity is responsible for executing the task, the tool component is responsible for calling external capabilities, the verification component is responsible for verifying the results, and the recovery component is responsible for exception recovery.
[0006] The runtime objects mentioned above typically have complex dependencies. The output of one runtime object may become the input condition for a subsequent runtime object, the result of a tool call may become the basis for subsequent execution decisions, and a verification result may determine whether a subsequent process continues to execute. Therefore, the runtime system essentially forms a complex dependency network.
[0007] Existing technologies typically employ access control mechanisms, state recovery mechanisms, workflow orchestration mechanisms, history replay mechanisms, and auditing mechanisms to address localized problems during operation. However, these mechanisms usually revolve around a single execution object. When an exception occurs in a runtime object, the system can typically only pause the current step or re-execute the current task.
[0008] Existing technologies lack a unified governance mechanism to address questions such as which subsequent objects will be affected by abnormal states, the extent of the impact, which objects need to be restored, and where the restoration should terminate.
[0009] For example, if at least one of the following occurs: tool version change, execution authority failure, environment configuration change, verification result failure, or checkpoint mismatch, multiple downstream runtime objects may still continue to execute, resulting in the continuous spread of erroneous results, an expanded recovery scope, increased governance costs, and execution behavior deviating from expectations.
[0010] Furthermore, existing technologies typically lack governance boundary mechanisms. When anomalies occur, the system struggles to determine the point where propagation terminates and the scope of governance action.
[0011] Therefore, a new runtime governance mechanism is needed to achieve dependency propagation control, scope of influence identification, and governance boundary control. Summary of the Invention
[0012] Purpose of the invention The present invention aims to address the problems of the lack of governance capabilities, impact scope identification capabilities, and governance boundary control capabilities in the existing technology.
[0013] This invention proposes a runtime cascaded governance system based on an execution dependency graph. By establishing an execution dependency graph, an execution dependency graph snapshot, an influence subgraph, and governance boundary nodes, runtime failure propagation control, local governance control, and governance closed-loop control are achieved. This improves the coordination consistency, recovery efficiency, and operational controllability of complex runtime systems.
[0014] Technical solution To achieve the above objectives, the present invention adopts the following technical solution.
[0015] A runtime cascading governance system based on execution right dependency graph includes an execution right management module, an execution right dependency graph management module, a failure event detection module, a dependency propagation analysis module, an impact subgraph generation module, a governance boundary determination module, a cascading governance module, and a governance audit module.
[0016] The execution right management module is used to maintain the execution right status and the execution right generation status. The execution dependency graph management module is used to build execution dependency graphs and snapshots of execution dependency graphs; The failure event detection module is used to detect failure events; The dependency propagation analysis module is used to propagate failure states; The influence subgraph generation module is used to generate influence subgraphs; The governance boundary determination module is used to identify governance boundary nodes; The cascading governance module is used to execute governance actions; The governance audit module is used to record the governance process and governance results.
[0017] Execution Dependency Graph An execution dependency graph is used to describe the dependencies between multiple runtime objects.
[0018] In a preferred embodiment, the execution dependency graph includes one or more of the following nodes: execution subject node, tool node, verification node, environment node, checkpoint node, and replay node.
[0019] In a preferred embodiment, the execution dependency graph includes one or more of the following dependencies: data dependency, control dependency, verification dependency, environment dependency, and recovery dependency.
[0020] State set In a preferred embodiment, the execution right dependency graph further includes a set of states.
[0021] The state set is used to describe the current running state of nodes, edges, and execution objects in the execution right dependency graph.
[0022] In a preferred embodiment, the state set includes at least node states, edge states, execution right states, and execution right generation states.
[0023] Node status Node states are used to describe the running state of node objects in the execution right dependency graph.
[0024] In a preferred embodiment, the node state includes one or more of the following states: running state, paused state, blocked state, failed state, and recovered state.
[0025] When a node fails, the system can switch the corresponding node's state from running to at least one of the following: failed, paused, or blocked.
[0026] edge state Edge states are used to describe the current validity state of dependencies in the execution right dependency graph.
[0027] In a preferred embodiment, the edge state includes one or more of the following states: active state, frozen state, blocked state, failed state, and reconstructed state.
[0028] When it is necessary to limit the scope of dependency propagation during the propagation of a failure event, the system can perform state update operations on the corresponding dependent edges. For example, updating the valid state to a frozen state, updating the frozen state to a blocked state, or updating the blocked state to a rebuild state, at least one of these can be done.
[0029] Using the above methods, the system can achieve dependency management without deleting nodes.
[0030] Execution status The execution right status describes the current availability of the execution right held by the executing entity.
[0031] In a preferred embodiment, the execution right status includes one or more of the following states: valid state, frozen state, revoked state, downgraded state, and restored state.
[0032] When an execution right failure event is detected, the system can update the execution right status according to the governance policy. For example, the valid status can be updated to a frozen status, the valid status can be updated to a revoked status, and the frozen status can be updated to a restored status, at least one of these.
[0033] Execution right generation status The execution right generation state is used to describe the generation attributes in the process of execution right version evolution.
[0034] In a preferred embodiment, the execution right generation state includes one or more of the following states: current generation state, historical generation state, generation state to be activated, and generation state that has failed.
[0035] When tool versions, environment configurations, verification rules, or execution strategies change, the system can generate new execution right generations. The original execution right generation enters the historical generation state or the invalid generation state, while the newly generated execution right generation enters the pending generation state or the current generation state.
[0036] State set update In a preferred embodiment, during the propagation of failure events, the system can update one or more of the following: node state, edge state, execution right state, and execution right generation state.
[0037] After governance is completed, the execution right dependency graph management module updates the state set according to the governance results and writes the updated state back to the execution right dependency graph.
[0038] The above methods enable runtime state management and closed-loop governance control.
[0039] Execution Dependency Graph Snapshot An execution right dependency graph snapshot is used to record the state of the execution right dependency graph at a specific moment. In a preferred embodiment, the execution right dependency graph snapshot includes at least a set of nodes, a set of dependent edges, node states, execution right generation states, and a time stamp.
[0040] The system generates a pre-failure dependency graph snapshot before the failure event occurs, and a post-failure dependency graph snapshot after the remediation is completed. The system further performs a difference analysis between the pre-failure dependency graph snapshot and the post-failure dependency graph snapshot.
[0041] Influence subgraph An influence subgraph is used to describe the set of runtime objects affected after a failure event propagates.
[0042] In a preferred embodiment, the influence subgraph includes one or more of the following: failed nodes, directly affected nodes, indirectly affected nodes, and propagation paths.
[0043] Governance actions affect the subgraph of influence.
[0044] Governance Boundary Nodes Governance boundary nodes are used to limit the scope of failure propagation.
[0045] When a failure propagates to the governance boundary node, the system stops propagating further.
[0046] In a preferred embodiment, the governance boundary node includes at least one of the following: a manual approval node, a verification node, a security policy node, a sandbox node, and a recovery node.
[0047] Cascaded governance The system performs governance actions on the affected subgraphs based on the governance strategy.
[0048] Governance actions include at least one of the following: blocking, suspending, revoking, rolling back, rebuilding, and replaying.
[0049] Remediation Results Write-back After governance is completed, the system writes the governance results back to the execution right dependency graph. The execution right dependency graph updates one or more of the following based on the governance results: node state, dependency relationship state, and execution right generation state, thus forming a runtime governance closed loop.
[0050] Beneficial effects Compared with the prior art, the present invention has the following advantages: (a) Establish a runtime dependency governance mechanism; (ii) Achieve failure propagation control; (iii) Achieve automatic identification of the scope of impact; (iv) Achieving control over governance boundaries; (v) Reduce the risk of abnormal spread; (vi) Improve recovery efficiency; (vii) Improve the stability of multi-entity collaboration; (viii) Improve the manageability of the operation process; (ix) Improve the traceability of enforcement actions; (x) Improve the system recovery capability during complex runtime. Detailed Implementation
[0051] The following embodiments are used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. Various modifications, substitutions, and improvements made by those skilled in the art without departing from the spirit and scope of the present invention should fall within the scope of protection of the present invention.
[0052] Example 1: Normal Collaborative Execution Scenario In this embodiment, multiple runtime objects work together to complete a complex task. The runtime objects include one or more of the following: a planning entity, an execution entity, a tool component, a verification component, and a recovery component.
[0053] The system first constructs an execution right dependency graph. This graph includes multiple execution right nodes and their dependencies. For example, the graph might look like this: Planning Entity Node → Execution Entity Node → Tool Node → Verification Node → Recovery Node. The system then creates an execution right record for each node. This record includes: execution right identifier, execution entity identifier, execution right generation, lifecycle state, and governance state.
[0054] The system further generates a snapshot of the execution right dependency graph. This snapshot records the current dependency state. When an execution request arrives, the system verifies the corresponding execution right status. If the execution right is valid, the corresponding node is allowed to continue execution. After the task is completed, the system records the execution result and the dependency state.
[0055] The system achieves runtime dependency management through the above methods.
[0056] Example 2: Failure Event Propagation Scenario In this embodiment, the system detects a failure event in the execution right dependency graph. The failure event includes at least one of the following: execution right failure, execution right generation failure, verification failure, tool anomaly, environment drift, checkpoint mismatch, and replay mismatch.
[0057] For example, when a tool node undergoes a version change, the system first generates a snapshot of the dependency graph before the failure, then the failure event detection module generates a failure event, and the dependency propagation analysis module uses the failure node as the propagation starting point.
[0058] The propagation path is, for example: tool node → verification node → recovery node. The system propagates the failure status according to the execution right dependency graph, continuously recording the propagation path during the process. When the propagation reaches the governance boundary node, the system stops further propagation.
[0059] The above methods enable runtime failure propagation control.
[0060] Example 3: Scenarios Affecting Subgraph Generation In this embodiment, after the failure event propagates, the influence subgraph generation module generates an influence subgraph based on the propagation results. The influence subgraph includes: the failed node, directly affected nodes, indirectly affected nodes, and the propagation path. For example: if node A fails, node B directly depends on node A, and node C depends on node B, then the system generates the following influence subgraph: Node A → Node B → Node C.
[0061] The governance actions only apply to the aforementioned subgraph of influence, not to the entire system.
[0062] The system further generates a snapshot of the dependency graph after governance, and then performs a difference analysis between the snapshot of the dependency graph before failure and the snapshot of the dependency graph after governance. The difference analysis results include at least one of the following: added nodes, deleted nodes, added dependencies, deleted dependencies, changes in node state, and changes in execution right generations.
[0063] Through the above methods, the system achieves local governance control and verification of governance results.
[0064] Example 4: Governance of Boundary Node Scenarios In this embodiment, the system constructs governance boundary nodes, which are used to block the propagation of failures.
[0065] In a preferred embodiment, the governance boundary node includes at least one of the following: a manual approval node, a verification node, a security policy node, a sandbox node, and a recovery node.
[0066] For example, if node A fails, the propagation path is as follows: Node A → Node B → Validator Node → Node C. When the propagation reaches the Validator Node, the system identifies that the Validator Node is a governance boundary node, and then terminates further propagation. Node C does not enter the influence subgraph.
[0067] Through the above methods, the system achieves control over the scope of governance.
[0068] Example 5: Cascaded Governance Scenario In this embodiment, the system performs cascaded governance based on the impact subgraph. For example, if node A fails, the system identifies the corresponding impact subgraph, and then the cascaded governance module performs at least one of the following governance actions: blocking, pausing, reversing, rolling back, rebuilding, and replaying.
[0069] In a preferred embodiment, the system first suspends the affected nodes, then rolls back to the designated checkpoint, rebuilds the operating environment, and finally replays the historical execution process.
[0070] After the governance is completed, the system will write the governance results back to the execution right dependency graph.
[0071] The execution right dependency graph update node state, dependency relationship state, and execution right generation state are at least one of the following:
[0072] The above methods achieve a closed-loop governance mechanism during runtime.
[0073] Example 6: Tool Call Cascading Governance Scenario In this embodiment, multiple tool calls form a dependency chain. For example: Planning Entity → Tool A → Tool B → Verification Node. The system first establishes an execution right dependency graph and generates an initial dependency graph snapshot. Initially, both Tool A Version 1 and Tool B Version 1 are valid. Subsequently, Tool A is upgraded to Version 2, the system detects that the execution right generation corresponding to Tool A has failed, the failure event detection module generates a failure event, and the system generates a dependency graph snapshot before the failure.
[0074] The dependency propagation analysis module propagates the failure status along the following path: Tool A → Tool B → Verification Node. The influence subgraph generation module generates the corresponding influence subgraph. The governance boundary determination module identifies the verification node as a governance boundary node and then stops further propagation.
[0075] The cascading governance module performs at least one of the following governance actions: blocking, rolling back, rebuilding, and replaying.
[0076] In a preferred embodiment, the system first rolls back to a historical checkpoint, then rebuilds the runtime environment, and finally replays the historical execution process. After governance is completed, the system generates a snapshot of the dependency graph after governance. The system performs a difference analysis on the dependency graph snapshot before failure and the dependency graph snapshot after governance, and then writes the governance results back to the execution right dependency graph. The execution right dependency graph is updated with: node status, dependency relationship status, and execution right generation status.
[0077] Through the above methods, the system achieves local cascading governance control in the Tool Call scenario.
[0078] In another implementation, the system does not perform governance directly on the Tool B node, but instead performs governance actions on the dependency edges between the Tool A node and the Tool B node.
[0079] The governance actions include at least one of freezing dependency edges, blocking dependency edges, invalidating dependency edges, and rebuilding dependency edges. For example, when the execution right generation corresponding to Tool A fails, the system updates the dependency edge state between Tool A node and Tool B node from an active state to a blocked state. At this time, Tool B node remains running, but cannot continue to obtain execution results from Tool A node. After Tool A recovers, the system updates the dependency edge state to a rebuilding state or an active state, and re-establishes the dependency relationship.
[0080] Using the above methods, the system can achieve local governance control without modifying the node state.
[0081] Invention effect verification After adopting the solution of this invention, the system uniformly incorporates the dependencies between runtime objects into the execution right dependency graph. When any node experiences a failure event, the system can: Detection failure events; Propagation failure status; Generate an influence subgraph; Identify governance boundary nodes; Implement cascading governance; Write back the governance results; Update dependency status.
[0082] Compared to existing technologies, this invention can achieve: (a) Runtime dependency management; (ii) Failure propagation control; (III) Calculation of the scope of impact; (iv) Governance boundary control; (v) Localized governance and control; (vi) Restoration process governance; (vii) Multi-stakeholder collaborative governance; (viii) Operational process audit; (ix) Retrospective application of enforcement actions; (x) Closed-loop control of governance.
[0083] Therefore, it can improve the consistency, stability, manageability, recoverability, and collaborative reliability of complex runtime systems. Attached Figure Description
[0084] Figure 1 Overall architecture diagram of the runtime cascading governance system; Figure 2 Execution Dependency Graph Structure Diagram; Figure 3 Diagram of the failure event propagation path; Figure 4 A diagram illustrating the influence of subgraph generation; Figure 5 Schematic diagram of governance boundary node control; Figure 6 Runtime cascading governance flowchart.
[0085] Explanation of reference numerals in the attached figures 1. Execution authority management module; 2. Execution Dependency Graph Management Module; 3. Failure event detection module; 4. Dependency Propagation Analysis Module; 5. Affects the subgraph generation module; 6. Governance boundary determination module; 7. Cascaded governance module; 8. Governance Audit Module; 9. Execution Dependency Diagram; 10. Execution right dependency graph snapshot; 11. Failure events; 12. Influence subgraph; 13. Governance of boundary nodes; 14. Governance actions; 15. Governance records.
Claims
1. A runtime cascading governance system based on execution right dependency graph, characterized in that, It includes modules for execution authority management, execution authority dependency graph management, failure event detection, dependency propagation analysis, impact subgraph generation, governance boundary determination, cascading governance, and governance auditing. The execution right management module is used to maintain the execution right status and the execution right generation status; The execution right dependency graph management module is used to construct the execution right dependency graph and the execution right dependency graph snapshot; The execution right dependency graph includes a set of nodes, a set of edges, and a set of states; The node set includes at least one of the following: execution entity node, tool node, verification node, environment node, checkpoint node, and replay node; The edge set is used to represent at least one of the following: execution dependency, verification dependency, environment dependency, checkpoint dependency, or replay dependency between nodes; The state set includes at least node states, edge states, execution authority states, and execution authority generation states; The failure event detection module is used to detect failure events in the execution right dependency graph; The failure events include at least one of the following: execution authority failure, execution authority generation failure, verification failure, tool anomaly, environment drift, checkpoint mismatch, and replay mismatch; The dependency propagation analysis module is used to identify the node where the failure event occurs as the failure starting point node, and to perform propagation analysis on the failure state according to the dependency direction and dependency type represented by the edge set, so as to obtain the set of affected nodes and the set of propagation paths. The influence subgraph generation module is used to generate an influence subgraph from the execution right dependency graph based on the failure starting node, the set of affected nodes, and the set of propagation paths. The governance boundary determination module is used to identify governance boundary nodes based on at least one of node type, dependency type, execution right status, and execution right generation status; When the failure state propagates to the governance boundary node, it stops propagating to downstream nodes. The cascaded governance module is used to perform governance actions on nodes or edges in the influence subgraph; The governance actions include at least one of blocking, pausing, reversing, rolling back, rebuilding, and replaying; The governance audit module is used to record governance results, which include at least the failure event, the failure initiation node, the set of affected nodes, the set of propagation paths, the governance boundary node, the governance action, and the governance time. The execution right dependency graph management module is also used to update the node state, edge state, execution right state, and execution right generation state according to the governance results, and write the updated state back to the execution right dependency graph to form a runtime governance closed loop.
2. The system according to claim 1, characterized in that, The nodes in the execution dependency graph include one or more of the following objects: execution subject node, tool node, verification node, environment node, checkpoint node, and replay node.
3. The system according to claim 1, characterized in that, The dependencies in the execution dependency graph include one or more of the following: data dependency, control dependency, verification dependency, environment dependency, and recovery dependency.
4. The system according to claim 1, characterized in that, The execution right dependency graph snapshot is used to record the state of the execution right dependency graph at a specific moment; The execution right dependency graph snapshot includes at least one or more of the following: node set, dependency edge set, node state, execution right generation state, and time identifier; The system generates a snapshot of the dependency graph before failure and a snapshot of the dependency graph after governance, and performs a difference analysis between the two.
5. The system according to claim 1, characterized in that, The governance boundary nodes include at least one of the following: manual approval nodes, verification nodes, security policy nodes, sandbox nodes, and recovery nodes.
6. The system according to claim 1, characterized in that, The edge state includes at least one of the following: active state, blocked state, frozen state, ineffective state, and reconstruction state. The cascaded governance module is used to update the edge state based on the governance action.
7. The system according to claim 1, characterized in that, The dependency propagation analysis module is used to terminate propagation when one of the following conditions is met: Reach the leaf node; Reach the governance boundary node; Reaching the managed node; Reach the isolation node; Reach the preset propagation depth.
8. The system according to claim 1, characterized in that, The information recorded by the governance audit module includes at least: failure node identifier, propagation path, impact subgraph identifier, governance action, governance time, and governance result.
9. A runtime cascading governance method based on execution right dependency graph, characterized in that, include: Construct an execution dependency graph; Establish dependencies between nodes; Generate a snapshot of the execution right dependency graph; Detection failure events; Propagate failure status according to the execution right dependency graph; Generate an influence subgraph; Identify governance boundary nodes; Execute cascading governance actions; Record the results of the governance; Update the execution right dependency graph state based on the governance results; The failure events include at least one of the following: execution authority failure, execution authority generation failure, tool anomaly, environment drift, checkpoint mismatch, and replay mismatch. The cascading governance actions include at least one of the following: blocking, pausing, reversing, rolling back, rebuilding, and replaying.
10. The method according to claim 9, characterized in that, Further includes: Generate a snapshot of the dependency graph before failure; Generate a snapshot of the dependency graph after governance; Perform a difference analysis on the dependency graph snapshot before failure and the dependency graph snapshot after governance; The node status and dependency status are updated based on the difference analysis results.
11. The method according to claim 9, characterized in that, When the failure state propagates to the governance boundary node, the propagation stops; and governance actions are performed only on the affected subgraph.
12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 9 to 11.