Task-state proof graph-based large model agent verification method and system

Abstract

The application relates to a task state proof graph-based large model intelligent agent verification method and system. The method comprises the following steps: acquiring user input data and tool registration information, performing task decomposition and action planning, generating candidate actions and to-be-verified propositions; generating proof obligations and constructing a task state proof graph; performing verification query on the verification conditions, performing minimum support operation on the passed conditions to obtain a successful evidence chain, and performing minimum failure operation on the failed or unknown conditions to obtain a local failure subgraph; serializing to obtain a proof sequence, pre-filling and encoding by a target large language model coding component to obtain a proof key-value memory; fusing and calculating the proof key-value memory into an attention calculation layer to obtain fused attention, incrementally updating the task state proof graph, and iterating until the task-level candidate conclusion passes the verification or necessary evidence cannot be obtained. The method can improve the verifiability of the conclusion, enhance the consistency of the execution state, and reduce repeated generation and context redundancy.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, and in particular relates to a method and system for verifying large-scale intelligent agents based on task-state proof graphs. Background Technology

[0002] With the development of large language model intelligent agent technology, it is now capable of automatically breaking down complex tasks and calling external tools to complete the analysis. For example, a code intelligent agent can read repositories, modify files, and run tests; an intelligent operation and maintenance intelligent agent can call logs, metrics, and tracing tools to locate faults; and a data analysis intelligent agent can call databases and computing tools to generate analytical conclusions. These tasks not only require the model to generate natural language answers but also require that the actual execution results of multiple tools or sub-agents collectively support the final conclusion. Current mainstream solutions mainly rely on prompt words, function calls, and workflow orchestration to achieve task planning and tool invocation. Representative frameworks include ReAct, LangChain, LangGraph, AutoGen, and CrewAI. These frameworks can transfer results between different execution nodes and perform task planning and tool invocation, but they do not generate structured verification rules corresponding to the actual tool results for each candidate action or proposition to be verified.

[0003] However, in existing technologies, the return of "execution successful" by a sub-agent or the return of "normal" by the tool does not necessarily indicate that the result supports the final conclusion. There may also be conflicting evidence, missing preconditions, or incorrect execution order among multiple sub-tasks. If the system merely returns these results to the context in natural language, the main agent may still overlook incomplete conditions, incorrectly adopt feedback from sub-agents, or repeatedly execute failed paths. Furthermore, existing methods can usually determine whether a tool has run successfully, but they primarily rely on a large language model to determine whether the tool's result supports the generated conclusion, making it difficult to distinguish between "successful tool call" and "the task conclusion is proven." After verification failure, the system typically returns a tool error or a vague retry message, making it difficult to determine whether the failure was caused by missing evidence, factual conflicts, unmet preconditions, or an incorrect execution order. It also makes it difficult to make local corrections while retaining completed steps. Success and failure results remain only at the textual feedback level and cannot directly participate in subsequent model inference within the same task session, easily leading to context growth, repeated tool calls, and the regeneration of actions or conclusions that have already been refuted. Summary of the Invention

[0004] Therefore, it is necessary to provide a large-scale model agent verification method and system based on task-state proof graph to address the above-mentioned technical problems. This method can improve the verifiability between conclusions and tool results, enhance the consistency of execution states of multiple agents, achieve local failure correction, and reduce repeated generation and context redundancy.

[0005] Firstly, this application provides a method for verifying large-scale intelligent agents based on task-state proof graphs, including:

[0006] S1. Obtain user input data and tool registration information, decompose the user input data into tasks, and obtain task orchestration; perform action planning based on task orchestration to generate candidate actions; based on the dependency relationship between each subtask in task orchestration and subsequent subtasks, select target subtasks that need to be used as the basis for subsequent planning, and generate propositions to be verified based on target subtasks; propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion.

[0007] S2. Based on user input data, candidate actions, propositions to be verified, and tool registration information, generate proof obligations; and based on task orchestration, candidate actions, and propositions to be verified, construct a task-state proof graph; wherein, the proof obligations are a set of verification rules that can be executed programmatically.

[0008] S3. Using the verification conditions in the proof obligation as the query entry point, perform verification query in the task-state proof graph to obtain the verification status; based on the verification status, perform minimum support operation on the verified conditions to obtain the successful evidence chain; perform minimum failure operation on the verified conditions or the verification status is unknown to obtain the local failure subgraph.

[0009] S4. Serialize the successful evidence chain and the local failure subgraph to obtain the proof sequence; pre-fill the proof sequence with the encoding component of the target large language model to obtain the proof key-value memory;

[0010] S5. Input the proof key-value memory into the attention calculation layer of the target large language model, perform attention fusion calculation to obtain fused attention; update candidate actions and propositions to be verified based on fused attention; call the tool based on the updated candidate actions and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate actions, the updated propositions to be verified and the tool execution return data to obtain the updated task-state proof graph.

[0011] S6. Based on the updated task-state proof graph, repeat steps S3 to S5 until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. When the task-level candidate conclusion is verified, output the task-level candidate conclusion and the corresponding successful evidence chain. When there is a conflict of evidence, do not output the task-level candidate conclusion and record the corresponding local failure subgraph. When the evidence is insufficient or cannot be determined, output the current unconfirmed state and missing conditions to instruct the agent to continue to obtain evidence or adjust the task plan.

[0012] In one embodiment, a proof obligation is generated based on user input data, candidate actions, propositions to be verified, and tool registration information, including:

[0013] Obtain domain rules;

[0014] Based on user input data, candidate actions, propositions to be verified, tool registration information, and domain rules, verification conditions are extracted from candidate actions or propositions to be verified, resulting in verification objects, condition sets, data field sets, logical combination relationships, and obligation types.

[0015] A structured model is performed on the verification object, condition set, data field set, logical combination relationship, and obligation type to obtain the proof obligation, where the expression of the proof obligation is:

[0016] ;

[0017] in, For the first One proof obligation, To verify the object, For the condition set, The data field set refers to the tool source, graph node, or data field corresponding to the condition. It is a logical combination relationship. It is a type of obligation.

[0018] In one embodiment, based on the verification status, a minimum support operation is performed on the conditions that pass verification to obtain a successful evidence chain; and a minimum failure operation is performed on the conditions that fail verification or whose verification status is unknown to obtain a local failure subgraph, including:

[0019] For verification conditions that are verified to be passed, the path traversal is performed along the relationships in the task-state proof graph, starting from the verification condition, to obtain the initial support subgraph.

[0020] Using the following formula, based on the verification conditions, the task-state proof graph, and the verification state that is considered passed, a minimum support operation is performed on the initial support subgraph to obtain the successful evidence chain:

[0021] ;

[0022] in, For the first In the first of the proof obligations A successful chain of evidence for each condition. For the minimum support operation function, For the first In the first of the proof obligations One verification condition, For the task-state proof graph, For the first The conditional validation status of each validation condition. The state is passed; among which, the minimum support operation includes: selecting unnecessary nodes or unnecessary relationships in the initial support subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state is passed, the deletion result is retained; otherwise, the corresponding node or relationship is restored. This process is repeated until there are no more nodes or relationships that can be deleted.

[0023] For verification conditions that are in a failed or unknown state, the path is traversed along the relationships in the task-state proof graph starting from the verification condition to obtain the initial failure subgraph.

[0024] Using the following formula, based on the verification conditions, the task-state proof graph, and the verification state being either failed or unknown, a minimum failure operation is performed on the initial failure subgraph to obtain a local failure subgraph:

[0025] ;

[0026] in, For the first In the first of the proof obligations A local failure subgraph of each validation condition. For the minimum failure operation function, For the first In the first of the proof obligations One verification condition, For the task-state proof graph, For the first The conditional validation status of each validation condition. The status is "failed". The state is unknown; among them, the minimum failure operation includes: selecting candidate nodes or candidate relations in the initial failure subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state still maintains the original failure or unknown state and the failure type remains unchanged, the deletion result is retained; otherwise, the corresponding node or relation is restored, and the process is repeated until there are no nodes or relations that can be deleted.

[0027] In one embodiment, after performing minimum failure operation processing on conditions where verification fails or the verification status is unknown to obtain a local failure subgraph, the method further includes:

[0028] Based on the condition verification status of each condition in the local failure subgraph, the failure cause is obtained through failure cause analysis.

[0029] Based on the reasons for failure, the local failure subgraphs are labeled with failure types to obtain the labeled local failure subgraphs. Specifically, when the condition verification status is failed and there is clear contrary evidence, the local failure subgraph is labeled as evidence conflict type; when the condition verification status is failed and the precondition is not met, the local failure subgraph is labeled as precondition unmet type; when the condition verification status is failed and the tool call time sequence is incorrect, the local failure subgraph is labeled as time sequence error type; when the condition verification status is unknown and the necessary facts are lacking, the local failure subgraph is labeled as insufficient evidence type. The local failure subgraph of insufficient evidence type includes unmet conditions, expected sources of evidence, executed queries or tool calls, and evidence missing indicators.

[0030] In one embodiment, the proof sequence is pre-filled and encoded using the encoding component of the target large language model to obtain proof key-value memory, including:

[0031] A word segmenter based on the target large language model is used to segment the proof sequence to obtain the proof token sequence;

[0032] By performing forward computation on the proof token sequence through the word embedding layer and attention projection layer of the target large language model, the hidden state of each attention layer is obtained.

[0033] Based on the injected attention layer number, the key vector and value vector of the target layer are read from the hidden state of each attention layer to obtain the proof key-value memory. The proof key-value memory includes the successful proof key-value memory and the failed proof key-value memory. The expression for the proof key-value memory is as follows:

[0034] ;

[0035] in, To demonstrate the key cache of key-value memory, To demonstrate the value caching of key-value memory, superscript... This demonstrates the key-value cache used to distinguish the original context of the target large language model, using subscripts. To prove the type index, For pre-padding encoding functions, For the target large language model, For the word segmentation function of the target large language model, To prove the sequence, when Pick The proof sequence is a successful proof sequence when... Pick The proof sequence is a failed proof sequence. Number the layer to be injected with attention.

[0036] In one embodiment, the key-value memory is input into the attention computation layer of the target large language model, and attention fusion computation is performed to obtain fused attention, including:

[0037] Obtain the query vector, current hidden state, and raw context attention results of the target large language model for the current generation step;

[0038] Based on the query vector and the key-value memory of successful proof, the successful attention result is calculated.

[0039] The failure attention result is calculated based on the query vector and failure proof key-value memory;

[0040] Based on the current hidden state, calculate the gating weights to obtain the successful gating weights and the failed gating weights;

[0041] The fused attention is obtained by weighting and fusing the original contextual attention result, successful gating weight, successful attention result, failed gating weight, and failed attention result using the following formula:

[0042] ;

[0043] in, For the first Step-by-step integration of attention, This is the original context attention result. For successful gating weights, For the attention calculation function, For query vector, To successfully prove the key cache of key-value memory, To successfully prove the value caching of key-value memory, For failure gating weights, A key cache for proving key-value pairs in failure. The value cache is used for key-value memory to prove failure.

[0044] Secondly, this application also provides a large-scale model intelligent agent verification system based on task-state proof graphs, for implementing the method provided in the first aspect, the system comprising:

[0045] The task decomposition module is used to acquire user input data and tool registration information, decompose the user input data into tasks, and obtain task orchestration; based on the task orchestration, action planning is performed to generate candidate actions; based on the dependency relationship between each subtask in the task orchestration and subsequent subtasks, target subtasks that need to be used as the basis for subsequent planning are selected, and propositions to be verified are generated based on the target subtasks; the propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion.

[0046] The graph construction module is used to generate proof obligations based on user input data, candidate actions, propositions to be verified, and tool registration information; and to construct a task-state proof graph based on task orchestration, candidate actions, and propositions to be verified; wherein, the proof obligation is a set of verification rules that can be executed programmatically.

[0047] The verification query module is used to perform verification queries in the task-state proof graph, using the verification conditions in the proof obligation as the query entry point, to obtain the verification status; based on the verification status, it performs minimum support operations on the verified conditions to obtain a successful evidence chain; and it performs minimum failure operations on the verified conditions or those with unknown verification status to obtain a local failure subgraph.

[0048] The proof encoding module is used to serialize the successful evidence chain and the local failure subgraph to obtain the proof sequence; the proof sequence is pre-filled and encoded by the encoding component of the target large language model to obtain the proof key-value memory;

[0049] The attention fusion module is used to input the proof key-value memory into the attention calculation layer of the target large language model, perform attention fusion calculation to obtain fused attention; update candidate actions and propositions to be verified based on fused attention; call the tool based on the updated candidate actions and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate actions, updated propositions to be verified and tool execution return data to obtain the updated task-state proof graph.

[0050] The intelligent verification module is used to repeatedly execute steps S3 to S5 based on the updated task-state proof graph until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. When the task-level candidate conclusion is verified, the task-level candidate conclusion and the corresponding successful evidence chain are output. When there is evidence conflict, the task-level candidate conclusion is not output and the corresponding local failure subgraph is recorded. When the evidence is insufficient or uncertain, the current unconfirmed state and missing conditions are output to instruct the agent to continue to obtain evidence or adjust the task plan.

[0051] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method provided in the first aspect.

[0052] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect.

[0053] The aforementioned large-scale model agent verification method and system based on task-state proof graphs construct programmatically executable proof obligations and task-state proof graphs to perform structured verification of candidate actions and propositions to be verified. Minimum support and minimum failure operations are executed for verification pass and failure conditions, respectively, to obtain a successful evidence chain and a local failure subgraph. The verification results are encoded as proof key-value memories and directly participate in large language model reasoning through an attention fusion mechanism to update candidate actions and propositions and incrementally update the graph. This process iterates until the conclusion passes verification or no evidence can be obtained. This achieves structured verification and closed-loop feedback of the relationship between tool execution and conclusion support, improving conclusion verifiability, failure location accuracy, and execution consistency, while reducing redundant generation and contextual redundancy. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 A flowchart illustrating the large-scale intelligent agent verification method based on task-state proof graphs provided in this embodiment of the invention;

[0056] Figure 2 This is a schematic diagram of the structure of a large model intelligent agent verification system based on task-state proof graphs provided in an embodiment of the present invention. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0058] First, a brief introduction to the terms used in the embodiments of this application will be given.

[0059] User input data refers to the goal description and contextual information submitted by the user to the large-scale intelligent agent system. It serves as the initial input for the agent to initiate the task execution process. User input data is typically presented in natural language and may include the specific task goals the user hopes to achieve, relevant environmental or constraint conditions, and contextual information accumulated during previous dialogues or task execution. This data forms the basis for the agent's task decomposition and action planning.

[0060] Tool registration information refers to a set of metadata describing the capabilities, interfaces, and constraints of an agent that can invoke external tools. Tool registration information typically includes the tool's name, functional description, input parameters and their types, expected return fields and their meanings, and possible error status codes. In practical applications, tool registration information can originate from the Model Context Protocol (MCP) tool description, or from system-pre-built or third-party provided tool interface documentation. This information provides a boundary reference for the agent's tool capabilities in planning actions and generating proof obligations.

[0061] A task-state proof graph is a dynamic data structure that organizes and stores proof relationships in a graph structure, oriented towards the current task session. Unlike long-term domain knowledge graphs or workflow graphs that only record task planning steps, a task-state proof graph is specifically designed to record the proof relationships within the current task session: "what conditions are required for the proposition to be verified, what results were actually achieved, which tool the results came from, and whether the results satisfy the conditions." The task-state proof graph is incrementally updated as the task execution progresses, serving as the graph data foundation for verification queries and proof subgraph extraction.

[0062] Based on the above definitions, the implementation environment of the large model intelligent agent verification method based on task-state proof graphs provided in this application is described. Indicatively, the implementation environment includes: a user terminal, a processor, and a server. The terminal includes, but is not limited to, personal computers, laptops, smartphones, tablets, smart speakers, smart vehicle devices, or IoT devices, used to receive user input data and display verification output results such as task-level candidate conclusions, successful evidence chains, or local failure subgraphs. The server deploys intelligent agents and can be an independent physical server, a server cluster consisting of multiple servers, or a virtual server instance provided by a cloud computing platform, used to carry out core processing tasks such as inference computation of the target large language model, construction and storage of the task-state proof graph, compilation and verification query of proof obligations, and pre-filling encoding and attention fusion computation of proof key-value memories. The processor includes, but is not limited to, central processing units, multi-core processors, graphics processing units, neural network processors, or artificial intelligence chips, etc., and is not limited here.

[0063] Based on the above definitions and implementation environment, the application scenarios of the embodiments of this application are described. The large model intelligent agent verification method based on task-state proof graphs provided in the embodiments of this application can be applied to scenarios including but not limited to the following:

[0064] In code-based intelligent agent applications, the agent needs to sequentially complete multiple sub-tasks, including code repository reading, file modification, compilation and building, and test execution, ultimately outputting analytical conclusions regarding code quality or defects. Since the tool's return results for each sub-task may have logical dependencies—for example, the pass / fail of subsequent tests depends on the correctness of preceding code modifications—this solution automatically verifies whether the test results truly support the final analytical conclusions by compiling a proof obligation for each candidate action and the proposition to be verified. This avoids misjudgments caused by missing preconditions or incorrect execution order, and when verification fails, it accurately locates the problem—whether it's a code modification, compilation configuration, or the test case itself—through a local failure subgraph.

[0065] In intelligent operations and maintenance (O&M) services, the intelligent agent needs to utilize various tools such as log retrieval, metric querying, and link tracing to synthesize scattered O&M data into fault location conclusions or root cause analysis reports. Since the data returned by different tools may contradict each other in terms of time and semantic dimensions—for example, a service's metrics might show normal operation, but the logs might record abnormal events—this solution uses a task-state proof graph to record the proof relationships of various evidence sources. This automatically identifies evidence conflict types and marks conflict subgraphs, enabling the intelligent agent to determine whether there are contradictory O&M evidence when outputting fault conclusions, rather than assuming all tool results are consistently reliable.

[0066] In data analysis scenarios, agents need to invoke tools such as database queries, statistical calculations, and visualization generation to form analytical conclusions or decision recommendations based on data results. Since data analysis conclusions typically require support from multiple data sources, and differences between different data definitions can lead to unreliable conclusions, this solution extracts a successful evidence chain through minimum support operations. This ensures that the final analytical conclusions rely only on structured and verified data facts. Simultaneously, it uses local failure subgraphs for insufficient evidence types to prompt the agent to continue acquiring missing data, rather than hastily outputting conclusions without sufficient evidence.

[0067] As an illustration, the large model agent verification method based on task-state proof graph provided in this application embodiment can also be applied to other application scenarios. This is only an example and does not limit the specific application scenarios.

[0068] In one exemplary embodiment, such as Figure 1 As shown, a method for verifying large-scale intelligent agents based on task-state proof graphs is provided, including the following steps S1 to S6, wherein:

[0069] S1. Obtain user input data and tool registration information, decompose the user input data into tasks, and obtain task orchestration; perform action planning based on task orchestration and generate candidate actions; based on the dependency relationship between each subtask in task orchestration and subsequent subtasks, select target subtasks that need to be used as the basis for subsequent planning, and generate propositions to be verified based on target subtasks; propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion.

[0070] Specifically, user input data includes a task objective description submitted by the user in natural language, along with contextual information related to the task. Tool registration information includes metadata such as the names, function descriptions, input parameter types, return field definitions, and possible error status codes of currently available external tools. The task decomposition process involves inputting the user input data into a large language model, which then breaks down the overall task into a sequence of subtasks with sequential or parallel execution relationships based on the task objective and available tool capabilities. Each subtask has a clear execution objective and expected output. For example, task orchestration is represented as a directed graph or ordered list, where nodes correspond to subtasks and edges correspond to execution dependencies between subtasks.

[0071] For example, in a code review task, the user input data is "check for security vulnerabilities in the project and provide remediation suggestions." The task decomposition results may include multiple subtasks such as "reading the list of repository files," "resolving code dependencies," "calling static analysis tools," and / or "summarizing analysis results." These subtasks form an execution sequence through data dependencies. Furthermore, action planning can be performed based on task orchestration to generate candidate actions. Action planning refers to the large language model selecting suitable tools from tool registration information based on the execution goal of the current subtask and generating specific tool call parameters and call order. Candidate actions are tool call operations that the agent intends to execute but have not yet been verified; their content includes the target tool identifier, input parameters, and expected return fields. For example, for the subtask of "reading the list of repository files," the generated candidate action might be calling a file system tool with the project root path as the input parameter. In this method, action planning does not simply generate a list of tool calls but also considers the dependency constraints between subtasks, ensuring that the parameters of the candidate actions can be obtained from the output of the preceding subtasks.

[0072] Preferably, based on the dependencies between each subtask and subsequent subtasks in the task orchestration, the agent selects target subtasks that need to be used as the basis for subsequent planning, and generates propositions to be verified based on the target subtasks. These propositions can include two categories: one is intermediate reasoning results, i.e., judgmental conclusions extracted by the agent from the results of previous subtasks and intended as inputs for subsequent subtask planning; the other is task-level candidate conclusions, i.e., final output conclusions that can already answer the user's goal. Conventional solutions typically directly pass the subtask results to subsequent steps, while this method marks the propositions to be verified as pending verification before passing them, requiring subsequent verification of their reliability through a proof obligation. For example, in intelligent operation and maintenance tasks, after the agent obtains the results "service response timeout" and "CPU utilization normal" from log retrieval tools and indicator query tools respectively, the agent may generate a proposition to be verified stating that "service timeout is not caused by resource bottlenecks." This proposition will be compiled into a proof obligation and verified programmatically in subsequent steps.

[0073] S2. Based on user input data, candidate actions, propositions to be verified, and tool registration information, generate proof obligations; and based on task orchestration, candidate actions, and propositions to be verified, construct a task-state proof graph; wherein, proof obligations are a set of verification rules that can be executed programmatically.

[0074] Specifically, the proof obligation essentially transforms the implicit judgments of the large language model into explicit, automatically executable structured rules upon which the verification logic of candidate actions and propositions to be verified depends. The agent extracts all verification conditions associated with the candidate action or proposition based on its content, combined with the tool return fields and domain rules defined in the tool registration information. Verification conditions include, but are not limited to: parameter value validity checks, return status checks of preceding subtasks, matching judgments between tool return values ​​and expected ranges, consistency judgments among multiple tool return results, and timing compliance judgments of tool invocations.

[0075] Furthermore, the agent structurally models the extracted verification conditions according to their corresponding verification objects, condition sets, data field sets, logical combination relationships, and obligation types, generating proof obligations. Here, the verification object is the candidate action or proposition to be verified corresponding to the proof obligation; the condition set is all verification conditions that need to be satisfied; the data field set is the tool source, graph node, or data field corresponding to each condition; the logical combination relationship describes the combinational logic such as AND, OR, NOT, or temporal dependencies between the conditions; and the obligation type identifies which category the proof obligation belongs to: action executability verification, conclusion evidence verification, numerical calculation verification, state consistency verification, temporal consistency verification, or proof by contradiction exclusion verification.

[0076] For example, for the proposition to be verified that "there are no high-risk vulnerabilities in the code project", the proof obligation may include the following verification conditions: the static analysis tool has been successfully executed, the number of high-risk vulnerabilities in the return results of the static analysis tool is zero, and the code coverage of the project meets the preset threshold; these conditions are combined in an AND relationship, and the obligation type is conclusion evidence verification.

[0077] Preferably, when constructing the task-state proof graph, the agent uses the sub-task nodes in the task orchestration as a foundation, taking candidate actions and propositions to be verified as proposition nodes in the graph, and tool descriptions in the tool registration information as tool nodes. It then establishes call relationship edges between proposition nodes and tool nodes, dependency relationship edges between proposition nodes, and data association edges between tool nodes and returned fact nodes. For example, in a data analysis task, the initial construction of the task-state proof graph only includes user goals and initial candidate action nodes. As the tool is invoked and returns results, the graph gradually adds returned fact nodes and their support or conflict relationship edges with proposition nodes, thus forming a complete proof relationship network.

[0078] S3. Using the verification conditions in the proof obligation as the query entry point, perform verification query in the task-state proof graph to obtain the verification status; based on the verification status, perform minimum support operation on the verified conditions to obtain the successful evidence chain; perform minimum failure operation on the verified conditions that fail or whose verification status is unknown to obtain the local failure subgraph.

[0079] Specifically, the verification engine can read the verification conditions in the proof obligation one by one, converting each verification condition into a graph query statement for the task-state proof graph. For structured conditions involving numerical comparison, state matching, or temporal judgment, the verification engine can directly obtain the attribute values ​​of the corresponding nodes through graph queries and perform procedural comparison operations, returning a pass or fail status. For unstructured conditions involving textual semantic relationships, the verification engine submits the condition content and the text attributes of relevant nodes in the graph to the large language model, which performs semantic judgment within a defined output format, returning a pass, fail, or unknown status. After the status of each verification condition is determined, the verification engine summarizes the status of each condition according to the logical combination relationship in the proof obligation to obtain the overall verification status of the proof obligation.

[0080] Furthermore, the agent can perform a minimum support operation on the verified condition based on the verification state to obtain a successful evidence chain. The minimum support operation process is as follows: starting from the verified condition, traverse the path along the relation edges in the task-state proof graph, collect all nodes and relations related to the condition, and form an initial support subgraph; then, try to delete non-core nodes or non-core relation edges in the initial support subgraph one by one. After each deletion, re-execute the verification query. If the deleted subgraph can still keep the condition in a passed state, the deletion is confirmed as valid and the deletion result is retained; otherwise, the deleted node or relation edge is restored. Repeat the above process until there are no more nodes or relation edges that can be deleted, thus obtaining a minimum subgraph that only contains substantial support for the condition's passing, i.e., a successful evidence chain.

[0081] For example, for the condition "the number of high-risk vulnerabilities returned by the static analysis tool is zero," the initial support subgraph may contain the tool's call records, return results, and multiple associated intermediate inference nodes. After a minimum support operation, only the tool call node, return result node, and the key fact node of zero vulnerabilities, along with their connecting edges, are retained, while auxiliary information irrelevant to the condition verification is removed. Simultaneously, the agent performs a minimum failure operation on conditions that fail verification or have an unknown verification status, resulting in a local failure subgraph. The minimum failure operation process corresponds to the minimum support operation: starting with the failed or unknown verification condition, a path traversal is performed to obtain the initial failure subgraph. Then, candidate nodes or candidate relationship edges are attempted to be deleted one by one. After each deletion, the verification query is re-executed. If the subgraph after deletion still maintains the original failed or unknown state and the failure type remains unchanged, the deletion result is retained; otherwise, it is restored. This process is repeated until no more nodes or relationship edges can be deleted, thus obtaining a simplified local failure subgraph. The significance of the local failure subgraph lies in accurately reflecting the core facts leading to verification failure with a minimal graph structure, rather than returning redundant information from the entire execution context. For example, for a verification condition that fails due to conflicting results from two tools, the local failure subgraph only contains the two contradictory return fact nodes and their relationship with the condition, and does not contain the large number of other nodes that complete normally during the task execution.

[0082] S4. Serialize the successful evidence chain and the local failure subgraph to obtain the proof sequence; pre-fill the proof sequence with the encoding component of the target large language model to obtain the proof key-value memory.

[0083] Specifically, both the successful evidence chain and the local failure subgraph are graph-structured data composed of nodes and relational edges. Nodes include nodes for the proposition to be verified, verification condition nodes, tool call nodes, and returned fact nodes, while relational edges include supporting relationships, conflicting relationships, dependency relationships, and data association relationships. The purpose of serialization is to convert this graph-structured data into an ordered linear sequence, making it processable by the segmenter of the target large language model. The agent extracts and organizes each element in the successful evidence chain into an ordered proof sequence, following the order of verification result, content of the proposition to be verified, proof conditions, tool call records, and returned facts, thus forming a successful proof sequence. For the local failure subgraph, the agent retains the failure type labeling information during serialization and organizes it according to the order of failure type, content of the proposition to be verified, unmet proof conditions, executed query or tool call records, and evidence missing identifiers, forming a failed proof sequence.

[0084] For example, the serialization process can employ a template-based concatenation method, pre-setting corresponding text templates for each feature type, filling the templates with node attributes and relation attributes from the graph structure, and then concatenating them sequentially to form a complete sequence. Alternatively, a structured tagging method can be used, marking each feature with predefined field labels and delimiters and then arranging them sequentially. Furthermore, the serialization process must ensure the distinguishability between successful and failed proof sequences so that independent proof key-value memories can be generated during subsequent encoding. For instance, a type identifier can be added at the beginning of the sequence, enabling the target large language model to identify whether the sequence belongs to a successful or failed proof sequence during encoding.

[0085] Preferably, the pre-filling encoding process can utilize the target large language model's own tokenizer, word embedding layer, and attention projection layer to convert the proof sequence into key and value vectors for a specific attention layer. For example, the agent can segment the proof sequence based on the target large language model's tokenizer, converting the text content in the sequence into token identifiers corresponding to the model's vocabulary, thus obtaining a proof token sequence. Subsequently, the agent inputs the proof token sequence into the target large language model's word embedding layer, mapping each token to a corresponding word vector, and then performs a linear transformation through the attention projection layer to obtain the query vector, key vector, and value vector required by each attention layer. The agent performs forward computation on the proof token sequence, calculating the hidden state of each attention layer layer by layer. Further, according to the preset injected attention layer number, the agent reads the key and value vectors of the target attention layer from the forward computation results, using them as key and value caches for proof key-value memory, respectively.

[0086] For example, the injection attention layer numbers can be set to several intermediate layers of the target large language model, because the hidden states of intermediate layers contain sufficient semantic abstraction information and retain the correspondence with the input sequence, making them suitable as a source of key-value memories across sequences. Successful proof sequences are pre-filled and encoded to obtain successful proof key-value memories, and failed proof sequences are pre-filled and encoded to obtain failed proof key-value memories. These have independent key and value caches, and are distinct from the key-value cache of the target large language model's original context. For instance, under a multi-head attention mechanism, the key cache dimension of the proof key-value memories is consistent with the key vector dimension of the corresponding attention layer of the target large language model, eliminating the need for additional dimensionality transformation operations in subsequent attention fusion calculations. The technical significance of pre-filling encoding is that the verification results no longer occupy the model's context window in text form, but are converted into vector representations within the model and stored in the key-value cache. In subsequent generation steps, these representations can be dynamically retrieved and weighted through the attention mechanism, thereby achieving a continuous impact of verification feedback on model inference without increasing the context length.

[0087] S5. Input the proof key-value memory into the attention calculation layer of the target large language model, perform attention fusion calculation to obtain fused attention; update candidate actions and propositions to be verified based on fused attention; call the tool based on the updated candidate actions and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate actions, the updated propositions to be verified and the tool execution return data to obtain the updated task-state proof graph.

[0088] Specifically, in each generation step of the target large language model, the attention computation layer, in addition to calculating the attention result between the current query vector and the original context key-value cache, also calculates the attention result between the current query vector and the successful proof key-value memory, and the attention result between the current query vector and the failed proof key-value memory. The agent can calculate the success gating weight and failure gating weight based on the hidden state of the current step through a gating mechanism. The value of the gating weight depends on the semantic correlation between the currently generated content and the verification result. Finally, the fused attention is obtained by weighting and fusing the original context attention result, the success attention result, and the failure attention result with their respective gating weights. For example, when the agent is planning the next tool call, the verified facts in the successful proof key-value memory will be given a higher weight in the attention computation, guiding the model to reason based on the confirmed facts; while when the model intends to generate a candidate action related to the content recorded in the conflict-type failure subgraph, the failed proof key-value memory will generate an inhibition signal in the attention computation, preventing the model from repeating reasoning paths that have already been disproven. Furthermore, this method updates candidate actions and propositions to be verified based on fused attention. Specifically, it uses fused attention to guide the reasoning process of the large language model, generating revised candidate actions and propositions to be verified. The updated candidate actions obtain tool execution return data through actual tool invocation. This return data includes the tool's original return results and the extracted structured return facts. Based on the updated candidate actions, updated propositions to be verified, and tool execution return data, the method incrementally updates the task-state proof graph. Specific operations include adding tool invocation nodes and return fact nodes to the graph, establishing support or conflict edges between return facts and propositions to be verified, and updating the attribute states of existing nodes. This incremental update ensures that the task-state proof graph always reflects the latest proof relationship state of task execution, providing an accurate graph data foundation for the next round of verification queries.

[0089] S6. Based on the updated task-state proof graph, repeat steps S3 to S5 until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. When the task-level candidate conclusion is verified, output the task-level candidate conclusion and the corresponding successful evidence chain. When there is a conflict of evidence, do not output the task-level candidate conclusion and record the corresponding local failure subgraph. When the evidence is insufficient or cannot be determined, output the current unconfirmed state and missing conditions to instruct the agent to continue to obtain evidence or adjust the task plan.

[0090] Specifically, based on the updated task-state proof graph, the steps of verification query, proof subgraph extraction, serialization and pre-filling encoding, and attention fusion and incremental update are repeatedly executed until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. In this iterative process, each loop re-verifies all propositions to be verified based on the latest graph state, and integrates the verification feedback into the model's subsequent inference through proof key-value memory, thus forming a closed-loop iterative mechanism of execution, graph construction, verification, attention calibration, and continued execution. When the task-level candidate conclusion is verified, the conclusion and its corresponding successful evidence chain are output, providing the user with traceable proof evidence. When there is evidence conflict, i.e., when there is clear contrary evidence proving that the task-level candidate conclusion is invalid, the agent does not output the conclusion and records the corresponding local failure subgraph to avoid providing the user with unreliable conclusions. When the evidence is insufficient or uncertain, i.e., when some verification conditions are unknown due to a lack of necessary facts, the current unconfirmed state and a list of missing conditions are output to instruct the agent to continue obtaining the necessary evidence or adjust the task planning direction in subsequent iterations.

[0091] For example, in a data analysis task, if the final conclusion "the revenue decline in this quarter was caused by customer churn" is unknown due to the lack of actual statistics on customer churn rate, the system will output a prompt that it cannot be confirmed and list the required customer churn rate data and its corresponding query tools, guiding the agent to call the customer data tools to obtain the missing evidence in the next iteration.

[0092] The aforementioned large-scale model agent verification method based on task-state proof graphs constructs programmatically executable proof obligations and task-state proof graphs to perform structured verification of candidate actions and propositions to be verified. It executes minimum support and minimum failure operations on verification pass and failure conditions respectively, obtaining a successful evidence chain and a local failure subgraph. The verification results are encoded as proof key-value memories and directly participate in large language model reasoning through an attention fusion mechanism to update candidate actions and propositions and incrementally update the graph. This process iterates until the conclusion passes verification or no evidence can be obtained. This achieves structured verification and closed-loop feedback between tool execution and conclusion support, improving conclusion verifiability, failure location accuracy, and execution consistency, while reducing redundant generation and contextual redundancy.

[0093] In one embodiment, a proof obligation is generated based on user input data, candidate actions, propositions to be verified, and tool registration information, including:

[0094] Obtain domain rules.

[0095] Specifically, domain rules are a set of pre-defined structured judgment conditions based on the specific application scenario involved in the current task. Their sources include the system's pre-built domain knowledge base, administrator-configured verification rule files, or rule interfaces provided by external rule engines. The content of domain rules covers judgment standards for data correctness, state compliance, temporal rationality, and business constraints within a specific domain. Examples include service response time thresholds, alarm level judgment conditions, and abnormal indicator detection modes defined in the operations and maintenance domain, and data consistency conditions, computational accuracy requirements, and statistical significance thresholds defined in the data analysis domain. The role of domain rules is to provide domain-level judgment criteria for the extraction of verification conditions, ensuring that the verification conditions in the proof obligation not only reflect general logical relationships but also professional constraints under specific business scenarios. For example, domain rules can be stored in the form of key-value pairs, conditional expressions, or structured rule objects. The agent retrieves a matching subset of rules from the rule base based on the task type or domain identifier contained in the user input data, which serves as one of the inputs for subsequent verification condition extraction.

[0096] Based on user input data, candidate actions, propositions to be verified, tool registration information, and domain rules, verification conditions are extracted from candidate actions or propositions to be verified, resulting in verification objects, condition sets, data field sets, logical combination relationships, and obligation types.

[0097] Specifically, for each candidate action, the agent analyzes the expected return fields, parameter constraints, and possible error states defined in the tool registration information of the target tool invoked by the action. Combined with the expected requirements of the action in the user input data, it extracts verification conditions related to the action's executability, such as whether the parameter values ​​are within the tool's allowed range, whether the preceding subtasks have generated the input data required for the action, and whether the target tool is currently available. For each proposition to be verified, the agent analyzes the content asserted by the proposition and identifies the factual conditions that must be met to support the proposition's validity, such as whether the numerical values ​​involved in the proposition are within a specific range, whether the results returned by multiple tools are consistent, and whether the temporal order of tool invocation conforms to causal logic.

[0098] Furthermore, the agent incorporates judgment conditions related to the current candidate action or proposition to be verified from the domain rules into the verification condition set. For example, when a domain rule stipulates that the response time of a certain type of service must not exceed a preset threshold, the agent automatically adds the corresponding temporal judgment conditions to the proposition to be verified involving the performance of that service. Through the above extraction process, the agent obtains five types of elements for each candidate action or proposition to be verified: verification object, condition set, data field set, logical combination relationship, and obligation type. Among them, the verification object is the identifier of the candidate action or proposition to be verified corresponding to the proof obligation; the condition set is the set of all verification conditions obtained through the above extraction; the data field set is the tool source, graph node, or data field corresponding to each verification condition, used to locate the corresponding fact node in the task-state proof graph during verification query; the logical combination relationship is the combination logic between the verification conditions in the condition set, including AND, OR, NOT, and temporal dependencies; the obligation type identifies the verification target category of the proof obligation, including types such as action executability, conclusion evidence, numerical calculation, state consistency, temporal consistency, or disprovenance.

[0099] A structured model is performed on the verification object, condition set, data field set, logical combination relationship, and obligation type to obtain the proof obligation, where the expression of the proof obligation is:

[0100] ;

[0101] in, For the first One proof obligation, To verify the object, For the condition set, The data field set refers to the tool source, graph node, or data field corresponding to the condition. It is a logical combination relationship. It is a type of obligation.

[0102] Specifically, the verification object That is, the candidate action or proposition to be verified that is bound to the proof obligation; The set of conditions contains all the conditions that the proof obligation needs to verify one by one. For the data field set, record the data source corresponding to each condition in the condition set, that is, when verifying the query, from which tool source node, graph node or data field of the task-state proof graph should the actual value to be compared be obtained; For logical combination relations, define the combination operation rules between the conditions in the condition set. For example, when all conditions must be satisfied, it is an AND relation; when any one condition is satisfied, it is an OR relation; when one condition negates another condition when it is true, it is a NOT relation; when one condition must be satisfied before another condition, it is a temporal dependency relation. The "Obligation Type" identifies which category the proof obligation belongs to among the aforementioned actions (executability, conclusion evidence, numerical calculation, state consistency, temporal consistency, or disprovenance), and is used to select the corresponding judgment logic during verification queries. For example, for the proposition to be verified, "The current service response timeout is caused by a memory leak," the structured modeling result of its proof obligation shows the proposition to be verified as the verification object. The set of conditions may include "The memory usage monitoring tool has been successfully executed," "The memory usage curve shows a continuous upward trend at the timeout point," "The garbage collection log shows that Full GC is frequently triggered during this period," and / or "The network link latency indicator is within the normal range during the timeout period." The set of data fields corresponds to the tool source node and data field in the task-state proof graph for each of the above conditions, respectively. The logical combination relationship is an AND relationship between the first three conditions and an AND relationship between the third and fourth conditions. The obligation type is conclusion evidence verification. After structured modeling, each proof obligation becomes a self-contained verification rule object that can be interpreted and executed by the verification engine. When executing, the verification engine only needs to read each element in the proof obligation, query the corresponding data in the task-state proof graph according to the logical combination relationship, and perform the judgment. No additional context information is required, thus achieving decoupling between the verification logic and the task planning logic.

[0103] In one embodiment, based on the verification status, a minimum support operation is performed on the conditions that pass verification to obtain a successful evidence chain; and a minimum failure operation is performed on the conditions that fail verification or whose verification status is unknown to obtain a local failure subgraph, including:

[0104] For verification conditions that are verified as passed, the path is traversed along the relationships in the task-state proof graph starting from the verification condition to obtain the initial support subgraph.

[0105] Specifically, the nodes in the task-state proof graph include nodes of propositions to be verified, verification condition nodes, tool invocation nodes, and return fact nodes, while the relationship edges include supporting relationships, conflicting relationships, data source relationships, and execution dependencies. Starting from a verified condition node, the agent uses a breadth-first or depth-first traversal strategy to progressively visit each node connected to it along the relationship edges, collecting all nodes and relationship edges traversed during the traversal to form an initial support subgraph. The initial support subgraph contains all factual evidence related to the verification condition, but because it may contain some auxiliary nodes and indirect relationships unrelated to the verification conclusion of the condition, its size is usually larger than actually necessary. For example, in an operations and maintenance task, a verification condition might be "the memory usage curve shows an upward trend at the timeout point." Its initial support subgraph might not only contain the condition node, the memory monitoring tool invocation node, and the return fact node, but also auxiliary nodes related to other unrelated monitoring indicators within the same time period, as well as indirect inference paths from user input data nodes to the condition.

[0106] Using the following formula, based on the verification conditions, the task-state proof graph, and the verification state that is considered passed, a minimum support operation is performed on the initial support subgraph to obtain the successful evidence chain:

[0107] ;

[0108] in, For the first The first of the proof obligations A successful chain of evidence for each condition. For the minimum support operation function, For the first The first of the proof obligations One verification condition, For the task-state proof graph, For the first The conditional validation status of each validation condition. The state is passed; the minimum support operation includes: selecting unnecessary nodes or unnecessary relationships in the initial support subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state is passed, the deletion result is retained; otherwise, the corresponding node or relationship is restored. This process is repeated until there are no more nodes or relationships that can be deleted.

[0109] Specifically, the core of the minimum support operation lies in iteratively deleting nodes and relationships from the initial support subgraph to achieve the minimum size while maintaining the validity of the verification conclusion. The agent selects unnecessary nodes or relationships from the initial support subgraph one by one as candidate deletion objects. After each selection, the node or relationship is temporarily removed from the initial support subgraph, and the verification query is re-executed on the deleted subgraph to obtain the updated verification status. If the updated verification status is still valid, it indicates that the deleted node or relationship does not substantially support the verification conclusion of the condition and is considered redundant. The agent confirms the deletion and retains the simplified subgraph. If the updated verification status becomes invalid or unknown, it indicates that the deleted node or relationship has necessary support for the verification conclusion of the condition. The agent cancels the deletion operation and restores the node or relationship. The agent repeats the above process of selection, deletion, verification, confirmation, or restoration until there are no more nodes or relationships to be deleted from the initial support subgraph. The resulting subgraph is the successful evidence chain.

[0110] For example, in selecting candidate deletion objects, the agent can prioritize leaf nodes, i.e., nodes with the lowest degree, because leaf nodes are usually located at the edges of the subgraph, and their deletion has little impact on the connectivity of the subgraph, making it easier to quickly identify redundant elements. Alternatively, the agent can select nodes in order of the shortest path distance from the node to the verification condition node, from farthest to nearest, so that indirectly related nodes that are farther away from the verification condition are evaluated first. After the minimum support operation, the successful evidence chain retains all the necessary nodes and relationships that can maintain the conclusion that the condition verification is passed in the most concise graph structure, while eliminating all irrelevant nodes and relationship edges. This allows the subsequent serialization process to process only the minimum set of facts, reducing information redundancy.

[0111] For verification conditions whose verification status is failed or unknown, the path is traversed along the relationships in the task-state proof graph starting from the verification condition to obtain the initial failure subgraph.

[0112] Specifically, for verification conditions whose verification state is failed or unknown, the agent traverses the path along the relationships in the task-state proof graph, starting from the verification condition, to obtain an initial failure subgraph. This path traversal process is consistent with the method for generating the initial support subgraph, both starting from the verification condition node and performing a breadth-first or depth-first traversal along the relationship edges, collecting all nodes and relationships traversed. The initial failure subgraph also contains all contextual information related to the verification condition; however, because it may contain nodes of completed steps unrelated to the cause of failure and nodes of normally returned facts, it needs to be simplified using the minimum failure operation.

[0113] Using the following formula, based on the verification conditions, the task-state proof graph, and the verification state being either failed or unknown, a minimum failure operation is performed on the initial failure subgraph to obtain a local failure subgraph:

[0114] ;

[0115] in, For the first The first of the proof obligations A local failure subgraph of each validation condition. For the minimum failure operation function, For the first The first of the proof obligations One verification condition, For the task-state proof graph, For the first The conditional validation status of each validation condition. The status is "failed". The state is unknown; among them, the minimum failure operation includes: selecting candidate nodes or candidate relations in the initial failure subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state still maintains the original failure or unknown state and the failure type remains unchanged, the deletion result is retained; otherwise, the corresponding node or relation is restored, and the process is repeated until there are no nodes or relations that can be deleted.

[0116] Specifically, the simplification logic of the minimum failure operation corresponds to that of the minimum support operation, but the judgment criteria are opposite. Its goal is to find the smallest subgraph after deleting all redundant elements while maintaining the original failure state and failure type. The agent selects candidate nodes or candidate relations from the initial failure subgraph one by one as deletion objects. After temporarily removing one candidate object each time, the verification query is re-executed on the deleted subgraph to obtain the updated verification state. The agent compares the updated verification state with the original verification state to determine whether the updated verification state still maintains the original failure or unknown state, and whether the failure type is consistent with the original failure type. If the updated state remains unchanged and the failure type is consistent, it means that the deleted node or relation does not substantially contribute to the failure conclusion of the condition, and the agent confirms the deletion and retains the simplification result. If the updated state changes, for example from failure to pass, or the failure type changes, for example from evidence conflict type to precondition not met type, it means that the deleted node or relation participated in the core fact chain that led to the verification failure, and the agent reverses the deletion and restores the node or relation. The agent repeats the above process until there are no more nodes or relationships that can be deleted. The resulting subgraph is the locally failed subgraph.

[0117] For example, in a code review task, a verification condition might be "static analysis tool did not report a high-risk vulnerability," but the verification status might be "failed." The initial failure subgraph might contain the static analysis tool's call records, the returned list of high-risk vulnerabilities, and multiple normally passed test case nodes associated with this subtask. After a minimum failure operation, test cases and other nodes irrelevant to the vulnerability failure conclusion are deleted one by one, retaining only the static analysis tool call nodes, the high-risk vulnerability return fact nodes, and the relationships between them. This minimizes the subgraph's representation of the core facts of the verification failure. The significance of the local failure subgraph lies in providing precise fault location for the agent's subsequent replanning, rather than returning a general failure message. This allows the agent to determine, based on a minimized set of facts, what additional evidence should be obtained or which step's execution strategy should be adjusted.

[0118] In one embodiment, after performing minimum failure operation processing on conditions where verification fails or the verification status is unknown to obtain a local failure subgraph, the method further includes:

[0119] Based on the condition verification status of each condition in the local failure subgraph, the failure cause is obtained through failure cause analysis.

[0120] Based on the reasons for failure, the local failure subgraphs are labeled with failure types to obtain the labeled local failure subgraphs. Specifically, when the condition verification status is failed and there is clear contrary evidence, the local failure subgraph is labeled as evidence conflict type; when the condition verification status is failed and the precondition is not met, the local failure subgraph is labeled as precondition unmet type; when the condition verification status is failed and the tool call time sequence is incorrect, the local failure subgraph is labeled as time sequence error type; when the condition verification status is unknown and the necessary facts are lacking, the local failure subgraph is labeled as insufficient evidence type. The local failure subgraph of insufficient evidence type includes unmet conditions, expected sources of evidence, executed queries or tool calls, and evidence missing indicators.

[0121] Specifically, the agent reads the condition verification status attribute of each verification condition node in the local failure subgraph. This attribute can originate from the judgment result written into the task-state proof graph after the verification engine performs verification queries on each verification condition in step S3, including two states: failure and unknown. The agent further analyzes the associated fact nodes and relation edges of the condition in the task-state proof graph, and infers the root cause of the current verification status by combining the judgment logic of the condition in the proof obligation. The basis for the failure cause analysis includes: whether the content of the returned fact node referenced by the condition contradicts other confirmed facts; whether the verification status of the condition's pre-dependent conditions in the task-state proof graph is passed; whether there is a logical reversal between the timestamp of the tool call node associated with the condition and the timestamps of other tool call nodes; and whether there is a corresponding fact node in the task-state proof graph for the data field expected by the condition. The agent synthesizes the above analysis results, classifies the failure cause into one of the following categories, and marks the local failure subgraph with the corresponding failure type.

[0122] Preferably, when the condition verification state fails and there is clear contrary evidence, the agent marks the local failure subgraph as an evidence conflict type. The criterion for determining the evidence conflict type is: the content asserted by the condition has a returned fact that directly contradicts it in the task-state proof graph. For example, in an operation and maintenance scenario, the proposition to be verified, "The current service anomaly is caused by a network link failure," includes the verification condition "The network link latency index exceeds a preset threshold." The verification state of this condition fails, but the latency value recorded by the returned fact node of the network link latency tool in the task-state proof graph is within the normal range, which clearly contradicts the threshold exceeding state required by the condition. Based on this, the agent marks the local failure subgraph of this condition as an evidence conflict type. The marking of the evidence conflict type enables the agent to identify in subsequent reasoning that the reasoning path has been refuted, and should avoid continuing to generate similar candidate propositions based on the same premise.

[0123] Preferably, when the condition verification status is failed and the precondition is not met, the agent marks the local failure subgraph as a precondition not met type. The criterion for determining the precondition not met type is: the previous verification condition on which the condition depends has not passed verification in the task-state proof graph, resulting in the data field referenced by the current condition not having a usable return fact node in the graph, or the referenced return fact node originating from a subtask with a failed verification status. For example, in a data analysis scenario, the proposition to be verified, "quarterly revenue decreased year-on-year," includes the verification condition "the return value of the revenue summary calculation tool is lower than the same period last year," but the precondition "the database query tool has returned all revenue data for this quarter" has failed verification in the graph, and the revenue data for this quarter is not yet complete. Based on this, the agent marks the local failure subgraph of the current condition as a precondition not met type. This marking prompts the agent to prioritize solving the execution problem of the previous subtask, rather than directly retrying the conclusion corresponding to the current condition.

[0124] Preferably, when the condition verification status is failed and the tool call timing is incorrect, the agent marks the local failure subgraph as a timing error type. The determination of the timing error type is based on the fact that the timestamp of the tool call node associated with the condition is inconsistent with the timing dependency condition specified by the logical combination relationship in the proof obligation. Further, the agent checks the execution timestamps recorded by each tool call node in the task-state proof graph according to the timing dependency relationship defined in the proof obligation, and determines whether there are situations such as the call time of a subsequent tool being earlier than the call time of a preceding tool, or the tool not having completed execution when its return result is referenced. For example, in a code review task, the proof obligation requires "executing the build tool first and then the test run tool," but the call timestamp of the test run tool in the task-state proof graph is earlier than the call timestamp of the build tool. Based on this, the agent marks the local failure subgraph of the relevant verification condition as a timing error type. This marking enables the agent to identify execution order problems and rearrange the tool call sequence.

[0125] Preferably, when the condition verification state is unknown and lacks necessary facts, the agent marks the local failure subgraph as insufficient evidence. The criterion for insufficient evidence is that the expected data field for the condition does not have a corresponding fact node in the task-state proof graph, meaning the relevant tool has not been invoked or has been invoked but has not returned data directly related to the condition. The local failure subgraph of insufficient evidence type contains four types of structured information: unmet condition (i.e., the condition content where the current verification state is unknown); expected evidence source (i.e., which tool or graph node should obtain data from based on the set of data fields in the proof obligation); executed queries or tool calls (i.e., tool call records in the task-state proof graph that have been executed but have not produced valid return facts related to the condition); and evidence missing identifiers (i.e., marking which specific data fields do not yet have corresponding fact nodes in the graph). For example, in an intelligent operations and maintenance task, the proposition to be verified, "Service response timeout is caused by memory leak," includes the verification condition "Garbage collection logs show frequent Full GC triggers during the timeout period." The data field set of this condition points to a GC log retrieval tool, but this tool has not yet been invoked. The task-state proof graph does not contain any GC log-related return fact nodes. The agent marks the local failure subgraph of this condition as insufficient evidence, and records the following: unmet condition is a GC log verification condition; expected evidence source is the GC log retrieval tool; executed query is empty; and missing evidence is indicated by a missing GC log return fact node. This marking indicates to the agent in the next iteration the specific tool to be invoked and the expected data content to be obtained, giving subsequent planning a clear execution direction.

[0126] In one embodiment, the agent pre-fills the proof sequence with the encoding components of the target large language model to obtain proof key-value memories. The purpose of pre-filling encoding is to transform the serialized proof sequence into a vector representation usable within the large language model, enabling it to be directly retrieved and weighted in subsequent attention calculations. This process fully utilizes the existing encoding components of the target large language model, including the tokenizer, word embedding layer, and multi-layer attention structure, without requiring additional training of a separate encoding module, thus ensuring the semantic consistency between the proof key-value memories and the original context of the model in the vector space. In this embodiment, the agent pre-fills the proof sequence with the encoding components of the target large language model to obtain proof key-value memories, including:

[0127] A word segmenter based on the target large language model is used to segment the proof sequence to obtain the proof token sequence.

[0128] Specifically, the tokenizer's vocabulary is derived from the pre-trained configuration of the target large language model and is a built-in text-to-token mapping tool within the model. After processing by the tokenizer, the text content in the proof sequence is converted into an ordered sequence of tokens. For example, for the successful proof sequence "Verification passed, proposition x to be verified is true, condition c is satisfied, tool t returns fact d", the tokenizer segments the text into several tokens according to the model's vocabulary rules, each token corresponding to a unique index number in the vocabulary. Successful and failed proof sequences are segmented independently to obtain their respective proof token sequences. The proof token sequence is the input for subsequent forward computation, and its length depends on the text size of the proof sequence and the segmentation granularity of the tokenizer.

[0129] By performing forward computation on the proof token sequence through the word embedding layer and attention projection layer of the target large language model, the hidden states of each attention layer are obtained.

[0130] Specifically, the word embedding layer maps each token identifier in the proof token sequence to a fixed-dimensional word vector. This mapping process is achieved using an embedding matrix pre-trained from the query model. The attention projection layer performs a linear transformation on the word vectors, projecting them into three representations: query vector, key vector, and value vector. During the forward computation, the agent's token sequence passes through all attention layers and feedforward network layers of the target large language model layer by layer. Each layer calculates the query vector, key vector, and value vector based on its input hidden state, and interacts with information through a multi-head attention mechanism, ultimately outputting the hidden state of that layer. This forward computation process is completely consistent with the computation flow of the target large language model when processing normal input sequences. The difference is that the input sequence is a proof token sequence rather than user dialogue content, and the purpose of the computation is not to generate text output, but to obtain the hidden states of each layer for subsequent extraction of key and value vectors.

[0131] Based on the injected attention layer number, the key vector and value vector of the target layer are read from the hidden state of each attention layer to obtain the proof key-value memory. The proof key-value memory includes the successful proof key-value memory and the failed proof key-value memory. The expression for the proof key-value memory is as follows:

[0132] ;

[0133] in, To demonstrate the key cache of key-value memory, To demonstrate the value caching of key-value memory, superscript... This demonstrates the key-value cache used to distinguish the original context of the target large language model, using subscripts. To prove the type index, For pre-padding encoding functions, For the target large language model, For the word segmentation function of the target large language model, To prove the sequence, when Pick The proof sequence is a successful proof sequence when... Pick The proof sequence is a failed proof sequence. Number the layer to be injected with attention.

[0134] Specifically, the injected attention layer number is a set of layer indices preset by the system, derived from system configuration parameters, used to specify which attention layers of the target large language model to extract key-value vectors from. For example, the injected attention layer number can be set to several intermediate layers of the target large language model; for instance, for a model with a total of 32 layers, it can be set to several layers between layers 16 and 24. The selection of intermediate layers is based on the fact that these layers possess sufficient semantic abstraction capabilities to capture key verification information in the proof sequence, while also preserving the positional correspondence with the input token, facilitating accurate location of relevant facts during subsequent attention calculations. The key vectors and value vectors extracted from the hidden states of the selected attention layers serve as the key cache and value cache for the proof key-value memory, respectively. Successful proof sequences, after being encoded using the above process, yield successful proof key-value memories, and failed proof sequences, after being encoded, yield failed proof key-value memories. Each has its own independent key cache and value cache, and their storage space is independent of the original context key-value cache generated when the target large language model processes user dialogues. Pre-filling encoding function. The execution process can be broken down into the following steps. The agent first uses the word segmentation function... Proof sequence Convert to proof token sequence ,in The length of the token sequence. For the first A token identifier. The agent will then... Input target large language model The forward computation is performed layer by layer, starting from the input layer. In the... In layer attention calculation, among which The key vector of this layer Sum value vector The following calculations were performed using the projections:

[0135] ;

[0136] ;

[0137] in, and The first The key projection weight matrix and value projection weight matrix of the layer, For the first The layer outputs hidden states. The agent learns from the target large language model. In each attention layer, only the injection attention layer number is extracted. The key vectors and value vectors of the specified level are concatenated to form the final proof key-value memory. For example, when When there are three attention layers, This is the set of key vectors from these three layers concatenated in layer order. This is the set of value vectors from the three layers concatenated in layer order. The successful proof sequence, after the above pre-padding encoding, yields the successful proof key-value memory. The failure proof sequence is pre-filled and encoded to obtain the failure proof key-value memory. Each has its own independent key cache and value cache, and they are independent of the original context key-value cache generated when the target large language model processes user dialogues in terms of storage space, through superscript... The key-value pairs are identified and distinguished. After pre-filling encoding is completed, it is proven that the key-value memory is stored in the key-value cache of the target large language model and is synchronously loaded during the attention calculation stage of each subsequent generation step, so that the validation feedback can continuously influence the model's inference process.

[0138] In one embodiment, the key-value memory is input into the attention computation layer of the target large language model, and attention fusion computation is performed to obtain fused attention, including:

[0139] Obtain the query vector, current hidden state, and raw context attention results of the target large language model for the current generation step.

[0140] Specifically, query vector The target large language model is in the first In each generation step, the vector obtained from the current hidden state after linear transformation by the attention projection layer is derived from the intermediate representation calculated in real time by the target large language model during generation. This representation is used in the attention calculation to calculate the similarity with the key vector and to perform a weighted summation of the value vectors accordingly. Current hidden state The target large language model is in the first The vector representation output after the previous layer of attention calculation and feedforward network processing in each generation step also originates from the real-time inference intermediate results of the target large language model, and is used in this embodiment to drive the calculation of gating weights. Original context attention result. The target large language model is in the first Each generation step is based on the query vector The attention output, calculated together with the original context key-value cache, reflects the model's normal inference focus direction in the absence of injected proof key-value memory. Its source is the standard output of the target large language model's own attention calculation layer.

[0141] Based on the query vector and the key-value memory of successful proof, the successful attention result is calculated.

[0142] Specifically, the key-value memory for successful proofs originates from the key cache obtained in S4 after pre-filling and encoding the successful proof sequence. Sum value cache This stores verified factual evidence and execution relationships. The agent will query the vector. Key cache with successful proof of key-value memory Calculate the dot product similarity, and after scaling and normalization, obtain the attention weight distribution. Then, use this weight distribution to cache the values. A weighted summation is performed to obtain the successful attention result. This calculation process is implemented using the following attention calculation function:

[0143] ;

[0144] in, For successful attention results, The dimension of the key vector is used for scaling to prevent the dot product value from becoming too large and causing the gradient to vanish. This is the normalization function. A successful attention result means that, in the current generation step, the model retrieves the most relevant factual information from the validated fact set based on the current query direction. For example, when the agent is generating candidate conclusions about memory leaks, the query vector... It will have a high similarity to the key vectors returned by memory monitoring tools that have successfully verified the facts recorded in key-value memory, thereby highlighting the verified memory usage trend data in the successful attention results and providing factual support for the generation of the current conclusion.

[0145] The failure attention result is calculated based on the query vector and the failure proof key-value memory.

[0146] Specifically, the key-value memory for the failure proof comes from the key cache obtained in S4 after pre-filling and encoding the failure proof sequence. Sum value cache This stores the conditions for verification failure or insufficient evidence, along with their failure type flags. This calculation process is implemented using the following attention calculation function:

[0147] ;

[0148] in, The failure attention result refers to the failure information retrieved by the model from the recorded set of failure facts related to the current reasoning direction during the current generation step, based on the current query direction. For example, when the agent intends to generate a candidate action related to the content of a failure subgraph already labeled as a conflict of evidence type, the query vector... It will have a high similarity with the key vector corresponding to the conflicting facts recorded in the key-value memory of the failed proof, thus highlighting the conflicting evidence information in the failure attention result, indicating that the model's current reasoning direction may be at risk of being refuted.

[0149] Based on the current hidden state, calculate the gating weights to obtain the successful gating weights and the failed gating weights.

[0150] Specifically, the agent is based on the current hidden state. Calculate the gating weights to obtain the successful gating weights. and failure gating weights The role of gating weights is to dynamically adjust the contribution ratio of successful and unsuccessful attention results in the fusion attention based on the inference content of the current generation step.

[0151] For example, the agent will hide the current state. The input is a gating network, which consists of two independent linear transformation layers and activation functions, outputting successful and failed gating weights, respectively. The calculation process for the gating weights is as follows:

[0152] ;

[0153] ;

[0154] in, and These are the weight matrices for the successful gating network and the failed gating network, respectively. and These are the corresponding bias vectors. For example, the Sigmoid function can be used to compress the output value to [a specific value]. Within the interval. The weight matrix and bias vector of the gating network are derived from the pre-trained parameters of the target large language model or the parameters learned during the fine-tuning stage. The values ​​of the gating weights depend on the current hidden state. The expressed reasoning semantics: Successful gating weights when the currently generated content is highly correlated with verified facts. Approaching a larger value, successful attention results receive higher weight in fused attention; when the currently generated content is highly correlated with recorded failure facts, the failure gating weight... Approaching a larger value allows failed attention results to receive higher weight in fused attention.

[0155] The fused attention is obtained by weighting and fusing the original contextual attention result, successful gating weight, successful attention result, failed gating weight, and failed attention result using the following formula:

[0156] ;

[0157] in, For the first Step-by-step integration of attention, For the original context attention results, For successful gating weights, For the attention calculation function, For query vector, To successfully prove the key cache of key-value memory, To successfully prove the value caching of key-value memory, For failure gating weights, A key cache for proving key-value pairs in failure. The value cache is used for key-value memory to prove failure.

[0158] Specifically, the fusion formula means that the fused attention consists of three parts: the first part is the original contextual attention result. The first part retains the model's conventional reasoning ability based on user input data and existing dialogue context; the second part is the product of successful gating weights and successful attention results, injecting verified factual evidence into the current reasoning with dynamic weights; the third part is the product of failed gating weights and failed attention results, injecting identified failure information into the current reasoning with dynamic weights. When the gating weight of a certain part approaches zero, the contribution of that part to the fusion attention also approaches zero, achieving automatic suppression of that part of the information.

[0159] For example, in intelligent operation and maintenance tasks, when the intelligent agent is in the first... When generating candidate actions for "calling the network link detection tool", the conflicting failure fact recorded in the failure proof key-value memory as "the network link latency index is within the normal range" will be retrieved through the failure attention results, and the failure gating weight will be used. Because the current hidden state is semantically related to the failed fact and tends towards a large value, the fused attention includes a signal of interest in this conflicting fact, thereby guiding the model to adjust its generation direction and avoid repeatedly executing detection paths that have already been proven false. Fusion Attention As the target large language model The final output of the step attention calculation layer replaces the original context attention result and is passed to the subsequent feedforward network layer and output layer to participate in the update and generation of candidate actions and propositions to be verified.

[0160] In summary, the large-scale agent verification method based on task-state proof graph provided in this application compiles the candidate actions to be executed by the agent and the propositions to be verified, which are intended to serve as the basis for subsequent planning or the final output, into a structured proof obligation containing the verification object, condition set, data field set, logical combination relationship, and obligation type. Based on task orchestration, candidate actions, and propositions to be verified, a task-state proof graph recording the proof relationships of the current task session is constructed. Then, using the verification conditions in the proof obligation as the query entry point, a programmatic verification query is performed in the graph. For verified conditions, the path is traversed along the graph relationships, and unnecessary nodes and key points are iteratively deleted. The system performs minimal support operations to extract successful evidence chains that retain only necessary factual evidence. For conditions that fail verification or have unknown states, it performs corresponding minimal failure operations to extract simplified local failure subgraphs. These failure subgraphs are then labeled based on their cause, such as evidence conflict, unmet preconditions, timing errors, or insufficient evidence. The successful evidence chains and local failure subgraphs are then serialized into a proof sequence. The proof sequence is pre-filled and encoded using the target large language model's own word segmenter, word embedding layer, and attention projection layer. Key vectors and value vectors are read from a specified attention layer to obtain successful proof key-value memories and failure proofs that are distinct from the original context key-value cache. Key-value memory is then used to input the aforementioned proof key-value memory into the attention computation layer of the target large language model. Based on the query vector of the current generation step, successful attention results and failure attention results are calculated with the successful proof key-value memory and failure proof key-value memory, respectively. Based on the current hidden state, successful gating weights and failure gating weights are calculated through a gating network. The original contextual attention results are then weighted and fused with the successful and failure attention results adjusted by the gating weights to obtain fused attention. Based on the fused attention, candidate actions and propositions to be verified are updated, and the returned data is retrieved by the tool to incrementally update the task-state proof graph. Subsequently, the verification query is repeated. The closed-loop iteration of subgraph extraction, serialization encoding, attention fusion, and incremental updates is demonstrated until the task-level candidate conclusion is verified or the necessary evidence cannot be obtained. This achieves structured modeling and procedural verification of the support relationship between the tool execution result and the proposition to be verified. It distinguishes between successful tool invocation and the verification of the task conclusion, accurately identifies and classifies the root cause of verification failure, and enables verification feedback to directly participate in subsequent reasoning in the same session in the form of key-value memory within the model without increasing the context length. This avoids the repeated generation of disproven paths and the repeated execution of completed steps, enhances the consistency of the execution state of multiple agents, and reduces context redundancy.

[0161] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0162] Based on the same inventive concept, this application also provides a task-state proof graph-based large model agent verification system 10 for implementing the task-state proof graph-based large model agent verification method described above. The solution provided by this system is similar to the implementation scheme described in the above method. Therefore, the specific limitations of one or more embodiments of the task-state proof graph-based large model agent verification system 10 provided below can be found in the limitations of the task-state proof graph-based large model agent verification method described above, and will not be repeated here.

[0163] In one exemplary embodiment, such as Figure 2 As shown, a large-scale model intelligent agent verification system 10 based on task-state proof graphs is provided. The system includes:

[0164] The task decomposition module 11 is used to acquire user input data and tool registration information, decompose the user input data into tasks, and obtain task orchestration; perform action planning based on task orchestration to generate candidate actions; based on the dependency relationship between each subtask in task orchestration and subsequent subtasks, select target subtasks that need to be used as the basis for subsequent planning, and generate propositions to be verified based on target subtasks; the propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion.

[0165] The graph construction module 12 is used to generate proof obligations based on user input data, candidate actions, propositions to be verified, and tool registration information; and to construct a task-state proof graph based on task orchestration, candidate actions, and propositions to be verified; wherein, the proof obligations are a set of verification rules that can be executed programmatically.

[0166] The verification query module 13 is used to perform verification queries in the task-state proof graph with the verification conditions in the proof obligation as the query entry point to obtain the verification status; based on the verification status, the minimum support operation is performed on the verified conditions to obtain the successful evidence chain; and the minimum failure operation is performed on the verified conditions that fail or whose verification status is unknown to obtain the local failure subgraph.

[0167] The proof encoding module 14 is used to serialize the successful evidence chain and the local failure subgraph to obtain the proof sequence; the proof sequence is pre-filled and encoded by the encoding component of the target large language model to obtain the proof key-value memory;

[0168] The attention fusion module 15 is used to input the proof key-value memory into the attention calculation layer of the target large language model, perform attention fusion calculation to obtain fused attention; update candidate actions and propositions to be verified based on the fused attention; call the tool based on the updated candidate actions and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate actions, the updated propositions to be verified and the tool execution return data to obtain the updated task-state proof graph.

[0169] The intelligent verification module 16 is used to repeatedly execute steps S3 to S5 based on the updated task-state proof graph until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. When the task-level candidate conclusion is verified, the task-level candidate conclusion and the corresponding successful evidence chain are output. When there is evidence conflict, the task-level candidate conclusion is not output and the corresponding local failure subgraph is recorded. When the evidence is insufficient or cannot be determined, the current unconfirmed state and missing conditions are output to instruct the agent to continue to obtain evidence or adjust the task plan.

[0170] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the large model agent verification method based on a task-state proof graph as described above.

[0171] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0172] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0173] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for verifying large-scale intelligent agents based on task-state proof graphs, characterized in that, The method includes: S1. Obtain user input data and tool registration information; decompose the user input data into tasks to obtain task orchestration; perform action planning based on the task orchestration to generate candidate actions; based on the dependency relationship between each subtask in the task orchestration and subsequent subtasks, select target subtasks that need to be used as the basis for subsequent planning; generate propositions to be verified based on the target subtasks; the propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion. S2. Based on the user input data, the candidate actions, the proposition to be verified, and the tool registration information, a proof obligation is generated; and based on the task orchestration, the candidate actions, and the proposition to be verified, a task-state proof graph is constructed; wherein, the proof obligation is a set of verification rules that can be executed programmatically; S3. Using the verification conditions in the proof obligation as the query entry point, perform verification query in the task-state proof graph to obtain the verification status; based on the verification status, perform minimum support operation on the verified conditions to obtain a successful evidence chain; perform minimum failure operation processing on the verified conditions or the verification status is unknown to obtain a local failure subgraph. S4. Serialize the successful evidence chain and the local failure subgraph to obtain a proof sequence; pre-fill the proof sequence with the encoding component of the target large language model to obtain proof key-value memory; S5. Input the proof key-value memory into the attention calculation layer of the target large language model, and perform attention fusion calculation to obtain fused attention; update the candidate action and the proposition to be verified based on the fused attention; call the tool based on the updated candidate action and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate action, the updated proposition to be verified and the tool execution return data to obtain the updated task-state proof graph; S6. Based on the updated task-state proof graph, repeat steps S3 to S5 until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence; wherein, when the task-level candidate conclusion is verified, the task-level candidate conclusion and the corresponding successful evidence chain are output; when there is evidence conflict, the task-level candidate conclusion is not output and the corresponding local failure subgraph is recorded; when the evidence is insufficient or cannot be determined, the current unconfirmed state and missing conditions are output to instruct the agent to continue to obtain evidence or adjust the task plan.

2. The method according to claim 1, characterized in that, The generation of proof obligations based on the user input data, the candidate actions, the proposition to be verified, and the tool registration information includes: Obtain domain rules; Based on the user input data, the candidate actions, the propositions to be verified, the tool registration information, and the domain rules, verification conditions are extracted from the candidate actions or the propositions to be verified to obtain the verification object, the condition set, the data field set, the logical combination relationship, and the obligation type. By performing structured modeling on the verification object, the condition set, the data field set, the logical combination relationship, and the obligation type, the proof obligation is obtained, wherein the expression of the proof obligation is: ； in, For the first The aforementioned proof obligation, For the verification object, For the set of conditions, The set of data fields refers to the tool source, graph node, or data field corresponding to the condition. The logical combination relationship is as described above. This refers to the type of obligation.

3. The method according to claim 1, characterized in that, Based on the verification status, the condition that passes verification undergoes a minimum support operation to obtain a successful evidence chain; the condition that fails verification or has an unknown verification status undergoes a minimum failure operation to obtain a local failure subgraph, including: For the verification condition whose verification status is passed, the path is traversed along the relationship in the task state proof graph starting from the verification condition to obtain the initial support subgraph; The successful evidence chain is obtained by performing a minimum support operation on the initial support subgraph using the following formula, based on the verification conditions, the task-state proof graph, and the verification state being passed: ； in, For the first The first of the aforementioned proof obligations The chain of evidence for success under the given conditions. For the minimum support operation function, For the first The first of the aforementioned proof obligations One verification condition, For the task state proof graph, For the first The condition verification status of each of the aforementioned verification conditions. The state is passed; wherein, the minimum support operation includes: selecting unnecessary nodes or unnecessary relationships in the initial support subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state is passed, the deletion result is retained; otherwise, the corresponding node or relationship is restored. This process is repeated until there are no nodes or relationships that can be deleted. For the verification condition whose verification status is failed or unknown, the path is traversed along the relationship in the task state proof graph starting from the verification condition to obtain an initial failure subgraph; The local failure subgraph is obtained by performing a minimum failure operation on the initial failure subgraph using the following formula, based on the verification conditions, the task state proof graph, and the verification state being either failed or unknown: ； in, For the first The first of the aforementioned proof obligations The local failure subgraph of the verification conditions. For the minimum failure operation function, For the first The first of the aforementioned proof obligations The aforementioned verification conditions. For the task state proof graph, For the first The condition verification status of each of the aforementioned verification conditions. The status is "failed". The state is unknown; wherein, the minimum failure operation includes: selecting candidate nodes or candidate relationships in the initial failure subgraph one by one for deletion, and re-executing the verification query process on the deleted subgraph to obtain the updated verification state. If the updated verification state still maintains the original failure or original unknown state and the failure type remains unchanged, the deletion result is retained; otherwise, the corresponding node or relationship is restored, and the process is repeated until there are no nodes or relationships that can be deleted.

4. The method according to claim 3, characterized in that, After performing minimum failure operation processing on conditions where verification fails or the verification status is unknown to obtain a local failure subgraph, the process further includes: Based on the condition verification status of each condition in the local failure subgraph, the failure cause is obtained through failure cause analysis. Based on the reasons for failure, the local failure subgraph is marked with failure type to obtain the marked local failure subgraph. Specifically, when the condition verification state is failed and there is clear contrary evidence, the local failure subgraph is marked as an evidence conflict type; when the condition verification state is failed and the precondition is not met, the local failure subgraph is marked as a precondition not met type; when the condition verification state is failed and the tool call time sequence is incorrect, the local failure subgraph is marked as a time sequence error type; when the condition verification state is unknown and necessary facts are lacking, the local failure subgraph is marked as an insufficient evidence type. The local failure subgraph of the insufficient evidence type includes unmet conditions, expected evidence sources, executed queries or tool calls, and evidence missing identifiers.

5. The method according to claim 1, characterized in that, The step of pre-filling the proof sequence with the encoding component of the target large language model to obtain the proof key-value memory includes: The proof sequence is segmented based on the word segmenter of the target large language model to obtain the proof token sequence; The proof token sequence is processed by forward computation through the word embedding layer and attention projection layer of the target large language model to obtain the hidden state of each attention layer; Based on the injected attention layer number, the key vector and value vector of the target layer are read from the hidden state of each attention layer to obtain the proof key-value memory; the proof key-value memory includes successful proof key-value memory and failed proof key-value memory, and the expression of the proof key-value memory is: ； in, For the key cache of the proof key-value memory, For the proof key-value memory value cache, superscript This indicates the key-value cache used to distinguish the original context of the target large language model, with subscripts. To prove the type index, For pre-padding encoding functions, For the target large language model, This is the word segmentation function for the target large language model. For the proof sequence, when Pick When the proof sequence is a successful proof sequence, when Pick The proof sequence is a failed proof sequence. Number the attention layer to be injected.

6. The method according to claim 5, characterized in that, The step of inputting the proof key-value memory into the attention calculation layer of the target large language model and performing attention fusion calculation to obtain fused attention includes: Obtain the query vector, current hidden state, and original context attention result of the target large language model for the current generation step; Based on the query vector and the successful proof key-value memory, the successful attention result is calculated; Based on the query vector and the failure proof key-value memory, the failure attention result is calculated; Based on the current hidden state, the gating weights are calculated to obtain the successful gating weights and the failed gating weights; The fused attention is obtained by performing a weighted fusion process based on the original context attention result, the successful gating weight, the successful attention result, the failed gating weight, and the failed attention result using the following formula: ； in, For the first The fusion attention mentioned in the step, The original context attention result, The successful gating weight, For the attention calculation function, For the query vector, The key cache is used to prove the success of the key-value memory. The value cache is used to prove the success of the key-value memory. The failure gating weight is... The key cache that serves as the key value memory for the failure proof. The value cache is used to prove the failure key-value memory.

7. A large-scale intelligent agent verification system based on task-state proof graphs, used to implement the method of any one of claims 1 to 6, characterized in that, The system includes: The task decomposition module is used to acquire user input data and tool registration information, decompose the user input data into tasks to obtain task orchestration; perform action planning based on the task orchestration to generate candidate actions; based on the dependency relationship between each subtask in the task orchestration and subsequent subtasks, select target subtasks that need to be used as the basis for subsequent planning, and generate propositions to be verified based on the target subtasks; the propositions to be verified include task-level candidate conclusions used to characterize the final output conclusion. The graph construction module is used to generate proof obligations based on the user input data, the candidate actions, the propositions to be verified, and the tool registration information; and to construct a task-state proof graph based on the task orchestration, the candidate actions, and the propositions to be verified; wherein, the proof obligations are a set of verification rules that can be executed programmatically; The verification query module is used to perform verification queries in the task-state proof graph using the verification conditions in the proof obligation as the query entry point to obtain the verification status; based on the verification status, it performs minimum support operations on the conditions that pass the verification to obtain a successful evidence chain; and it performs minimum failure operations on the conditions that fail the verification or whose verification status is unknown to obtain a local failure subgraph. The proof encoding module is used to serialize the successful evidence chain and the local failure subgraph to obtain a proof sequence; the proof sequence is pre-filled and encoded by the encoding component of the target large language model to obtain proof key-value memory; The attention fusion module is used to input the proof key-value memory into the attention calculation layer of the target large language model, perform attention fusion calculation to obtain fused attention; update the candidate actions and the proposition to be verified based on the fused attention; call the tool based on the updated candidate actions and obtain the tool execution return data; incrementally update the task-state proof graph according to the updated candidate actions, the updated proposition to be verified and the tool execution return data to obtain the updated task-state proof graph. The intelligent verification module is used to repeatedly execute steps S3 to S5 based on the updated task-state proof graph until the task-level candidate conclusion is verified or the agent cannot obtain the necessary evidence. When the task-level candidate conclusion is verified, the task-level candidate conclusion and the corresponding successful evidence chain are output. When there is an evidence conflict, the task-level candidate conclusion is not output and the corresponding local failure subgraph is recorded. When the evidence is insufficient or cannot be determined, the current unconfirmed state and missing conditions are output to instruct the agent to continue to obtain evidence or adjust the task plan.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 6.

9. A 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 of any one of claims 1 to 6.

Images