Multi-agent document incremental processing method and system based on evidence version mapping

Abstract

This invention discloses a multi-agent document incremental processing method and system based on evidence version mapping. The method parses heterogeneous source documents into document evidence units with location identifiers and version hashes. It establishes document processing nodes and a directed task dependency graph according to the target document structure. At task initialization, target agents are matched to each node, and the configuration used for this execution is frozen. Nodes are scheduled according to the topological order of the task dependency graph to obtain the mapping relationship between evidence units, nodes, and versions. When a defect is found during the review stage, the output version of the defect-related node is used as the starting point. A failure propagation closure is calculated based on evidence version changes and task dependencies. Nodes within the closure are marked as failed, and the output of nodes outside the closure is locked in an immutable, reusable state. Then, the agent configuration snapshot corresponding to the initial execution is reloaded, and only nodes within the closure are executed. Finally, incremental merging is performed based on the target document structure pattern, chapter identifier, and version dependency.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a multi-agent document incremental processing method and system based on evidence version mapping. Background Technology

[0002] With the development of large language models and intelligent agent technology, automated document processing systems have gradually evolved from single-model one-time generation to multiple intelligent agents dividing the work to complete parsing, extraction, generation, review, and export. Existing solutions can typically generate long documents according to a predetermined process and may also use task dependency graphs, structured interfaces, or quality assessment mechanisms.

[0003] However, existing solutions still have the following technical problems when incrementally processing long documents for nondeterministic generation models.

[0004] 1. Lack of version mapping between generated results and source evidence. Typical document processing systems usually only save the full text of the source document, sliced ​​text, or generated results, without simultaneously recording the physical location of the source content, content hash, node input versions, and node output versions. When the source document is modified, or when an error in a value, terminology, or fact is discovered during the review stage, the system has difficulty determining which version of evidence, which node, and which output caused the error.

[0005] Therefore, the system can only rely on natural language feedback or re-entering large sections of context, and cannot form a deterministic defect tracing and failure boundary judgment.

[0006] 2. Partial retries in normal workflows cannot control the drift of generated content. Traditional workflows can rerun specified nodes or downstream nodes after a task fails, but the output of large language models is nondeterministic. If the system rereads the changed model parameters, prompts, or tool configurations, the re-execution result may use different generation conditions than the initial execution; if the system also reruns nodes unaffected by defects, previously qualified chapters may be rewritten by the model.

[0007] Therefore, simply "rerunning the affected nodes" is still insufficient to guarantee the stability of the document content before and after repair.

[0008] 3. The granularity of defect localization is inconsistent with the granularity of task dependence. Document reviews typically output comments in natural language such as "There is a problem in a certain chapter," while workflow scheduling relies on node identifiers. If a defect is not simultaneously associated with the source evidence unit, chapter identifier, node output version, and upstream dependency version, the system cannot accurately calculate the defect propagation scope, which can easily lead to two situations: The failure scope is too large, causing irrelevant nodes to be executed repeatedly; The failure scope is too small, resulting in downstream nodes that depend on the results of the old version not being updated.

[0009] 4. Lack of a final consistency loop after incremental merging. After local nodes are regenerated, the new chapter content needs to be combined with the old locked chapters. Simply replacing text or concatenating them may result in inconsistent terminology across chapters, invalid references, version mixing, and logical breaks. Existing solutions often output directly after merging without re-verifying all evidence references and node version dependencies in the target document.

[0010] 5. Concurrent triggering causes nodes to execute repeatedly. In cases of repeated clicks on the front end, network retries, or simultaneous submissions from multiple terminals, the same node may be repeatedly scheduled, resulting in multiple execution instances concurrently writing node results, repeatedly calling model interfaces, and state overwriting. Summary of the Invention

[0011] The purpose of this invention is to address the shortcomings of existing technologies by providing a multi-agent document incremental processing method and system based on evidence version mapping. By introducing deterministic evidence version control and task dependency analysis into the non-deterministic generation process, traceable, computable, and verifiable repair of local defects is achieved.

[0012] This invention is achieved through the following technical solution: This invention provides a multi-agent document incremental processing method based on evidence version mapping: First, heterogeneous source documents are parsed into document evidence units with location identifiers and version hashes. Second, document processing nodes and a directed task dependency graph are established according to the target document structure. At task initialization, target agents are matched for each node, and the configuration used for this execution is frozen. Nodes are scheduled according to the topological order of the task dependency graph. During the execution of tasks by a node, the input evidence unit version, the output version of the upstream node, and the output version of the node are recorded to obtain the mapping relationship between evidence units, nodes, and versions. When a defect is discovered during the review phase, the defect record points to both the relevant evidence unit and the output version of the node that caused the defect. Then, starting from the output version of the node associated with the defect, a failure propagation closure is calculated by combining evidence version changes and task dependencies. Nodes within the closure are marked as failed, and the output of nodes outside the closure is locked in an immutable and reusable state. Then, the corresponding agent configuration snapshot from the initial execution is reloaded, and only the nodes within the closure are executed. Incremental merging is then performed based on the target document structure pattern, chapter identifier, and version dependencies. After the incremental merging is completed, evidence citation integrity and version consistency are verified.

[0013] In the above technical solution, the target document structure pattern at least defines chapter identifiers, chapter order, required attributes, optional attributes, and chapter dependencies.

[0014] In the above technical solution, the structure of the document evidence unit includes the following fields: unit identifier, task identifier, source document identifier, source document type, type of extracted evidence unit, content of extracted evidence unit, location identifier of extracted evidence unit in source document, version hash of evidence unit, confidence score of extracted evidence unit and timestamp.

[0015] In the above technical solution, the version hash of the evidence unit is generated by calculating the SHA-256 algorithm based on the source document identifier, the location identifier of the evidence unit in the source document, and the content of the evidence unit. When the source document is imported again, the source document identifier, the location identifier of the evidence unit in the source document, and the version hash of the evidence unit are used to determine whether the evidence unit is newly added, unchanged, changed, or deleted.

[0016] In the above technical solution, each document processing node includes: node identifier, task identifier, node type, stage, predecessor node set, input evidence unit set, output data contract, node execution status, and current output version identifier.

[0017] In the above technical solution, the configuration snapshot at the time of freezing includes at least: agent identifier and role; model provider type; model name or model version; sampling temperature, maximum output length and timeout parameters; system prompt words and user prompt word template versions; callable tools and tool versions; output data contract version; snapshot generation time and snapshot hash.

[0018] In the above technical solution, the structure of the node output version includes the following fields: the output version identifier of the current node, the task identifier, the node identifier within the task, the configuration snapshot identifier when the node is executed, the input data fingerprint, the upstream output version set, the set of referenced evidence units, the chapter identifier, the structured content produced by the node, the content hash, and the timestamp.

[0019] In the above technical solution, to prevent nodes from being executed repeatedly, the state transition of each node is completed through database condition updates; the current execution instance only obtains the node execution right when the number of rows affected by the update is greater than zero; after the node is completed, the execution_token is verified to prevent late old execution instances from overwriting the new results.

[0020] In the above technical solution, the failure propagation closure consists of the following set: The root node that directly generates the defective output version; The input includes nodes that reference evidence units that have changed or are in conflict; Downstream nodes that directly or indirectly depend on the output versions of the aforementioned nodes; The merge node and the final verification node need to be re-executed.

[0021] In the above technical solution, in order to avoid omitting upstream root causes, when the defect review only locates the chapter generation node, a reverse check is performed based on the evidence unit referenced in the output version and the output version of the upstream node: if the evidence unit itself has changed, the extraction node that depends on the evidence unit will be added to the closure; if the evidence unit has not changed but the generated content conflicts with the evidence unit, only the generation node and its downstream nodes will be disabled.

[0022] In the above technical solution, the verification of evidence citation integrity and version consistency specifically includes: Each required chapter exists and is bound to only one valid output version; Does the evidence unit referenced in each output version exist? Is the current version hash of the referenced evidence unit consistent with the version at the time the node was executed? Is the upstream output version of each node still a valid version? Are the terms, values, units, and cross-references consistent across chapters? Check if the content hashes of the locked nodes are the same before and after merging; Are there still unresolved high-severity structural defects?

[0023] Another aspect of the present invention provides a system for implementing the above-described multi-agent document incremental processing method based on evidence version mapping, the system comprising at least the following modules: The heterogeneous document parsing module is used to parse heterogeneous source documents into document evidence units with location identifiers and version hashes; The task dependency graph construction module is used to build document processing nodes and directed task dependency graphs according to the target document structure. The agent configuration snapshot module is used to freeze the configuration used by the agent and create a configuration snapshot; The Evidence-Node-Version Mapping Module is used to construct the mapping relationship between evidence units, nodes, and versions. The structured review module is used to perform consistency reviews on intermediate results of nodes or synthesized target documents; The failure propagation closure calculation module is used to calculate the failure propagation closure. The immutable reuse and local re-execution module is used to mark nodes inside the closure as failed, lock the output of nodes outside the closure to an immutable reuse state, and propagate failures to nodes inside the closure, reloading the agent configuration snapshot corresponding to the initial execution. Incremental merge verification module; used to perform incremental merge as well as verification of evidence citation integrity and version consistency.

[0024] The advantages and beneficial effects of this invention are as follows: (1) By constructing a deterministic mapping between evidence units, node output versions and configuration snapshots, this invention realizes versioned traceability between generated content and source evidence, enabling defects to be accurately located to specific evidence versions, nodes and output instances, thus solving the technical problem that deterministic defect traceability is impossible in the prior art. (2) This invention effectively avoids content drift caused by changes in model parameters or re-execution of irrelevant nodes by executing only the nodes inside the failure propagation closure under the original configuration snapshot and locking the output of the nodes outside the closure to an immutable state, thus ensuring the stability of the document content before and after repair. (3) This invention achieves accurate calculation of the scope of defect impact by using structured defect record associated evidence units, chapter identifiers, node output versions and upstream dependency versions, combined with failure propagation closure algorithm, thus avoiding the problem of the failure scope being too large or too small. (4) This invention performs global verification on the complete document after incremental merging by verifying the integrity of the final evidence citation and the consistency of the version, ensuring the consistency of cross-chapter terminology, the validity of citations and the integrity of version dependencies, and solving the problem of the lack of a final consistency closed loop in the prior art; (5) This invention achieves node-level atomic state migration through database condition updates and execution token verification, preventing repeated scheduling and writing of the same node at the server and database levels, and solving the technical problem of repeated execution of nodes caused by concurrent triggering. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0026] Figure 1 This is a flowchart of a multi-agent document incremental processing method based on evidence version mapping. Detailed Implementation

[0027] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the invention. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0030] Embodiments of the present invention provide a multi-agent document incremental processing method based on evidence version mapping, comprising the following steps: Step S1: Obtain the source document and generate document evidence units.

[0031] Obtain at least one heterogeneous source document that has been actively uploaded by the user or has been legally authorized for access, and obtain the target document structure pattern; the target document structure pattern at least defines chapter identifiers, chapter order, required attributes, optional attributes, and chapter dependencies.

[0032] Heterogeneous source documents refer to input documents with different source formats or internal structures, including but not limited to Word documents, PDF documents, plain text, Markdown, spreadsheets, database query results, and collaborative cloud documents that have been legally authorized for access.

[0033] The corresponding parsing adapter is invoked based on the source document type, and multiple document evidence units are generated. The structure of each document evidence unit includes the following fields: Unit identifier (unitId); Task identifier (taskId); Source document identifier (sourceId); Source document type (sourceType); The type of the extracted evidence unit (contentType); The content of the extracted evidence unit (rawContent); Location identifiers of extracted evidence units in the source document; Version hash of the evidence unit; The confidence score of the extracted evidence unit. Timestamp (createdAt).

[0034] The version hash of the evidence unit is generated by the SHA-256 algorithm based on the source document identifier, the location identifier of the evidence unit in the source document, and the content of the evidence unit. It is used to detect whether the evidence unit has changed.

[0035] For scanned PDFs, the credibility of their OCR results can be used as a confidence score and saved in the document evidence unit; for tables, row and column coordinates can be used as location identifiers; for collaborative cloud documents, block identifiers, block paths, and document version numbers can be used as location identifiers.

[0036] When the source document is imported again, the source document identifier (sourceId), the location identifier of the evidence unit in the source document (location), and the version hash of the evidence unit (versionHash) are used to determine whether the evidence unit is newly added, unchanged, changed, or deleted.

[0037] Step S2: Construct a directed task dependency graph and freeze agent configuration.

[0038] A directed task dependency graph is generated based on the target document structure pattern. Each document processing node includes: node identifier, task identifier, node type, stage, set of predecessor nodes, set of input evidence units, output data contract, node execution status, and current output version identifier.

[0039] Task dependency edges are used to indicate whether the output of one node constitutes the input of another node; the task graph is a directed acyclic graph; if a circular reference exists in the target document structure pattern, the pattern is rejected or the loop is split into an inspection loop with a maximum number of iterations when generating the task graph.

[0040] At task initialization, target agents are matched for each node, and the configuration used for this execution is frozen. The configuration snapshot at the time of freezing includes at least: Agent identifier and role; model provider type; model name or model version; sampling temperature, maximum output length, and timeout parameters; system prompt words and user prompt word template versions; callable tools and tool versions; output data contract version; configuration snapshot generation time and configuration snapshot hash.

[0041] Once the configuration snapshot is generated, it is read-only for currently executing tasks; background configuration changes only apply to newly created tasks.

[0042] Step S3: Execute the task graph and establish evidence-node-version mapping.

[0043] Nodes are scheduled according to the topological order of the task dependency graph. Nodes without dependency conflicts can be executed in parallel; to reduce instantaneous concurrency of the same model provider interface, they can be started at predetermined intervals to avoid peak traffic.

[0044] Before each node executes, it calculates the set of input evidence unit versions and the set of output versions from upstream nodes. It then concatenates the set of input evidence unit versions, the set of output versions from upstream nodes, the configuration snapshot hash, and the output data contract version to obtain the input data fingerprint.

[0045] After a node completes execution, it generates an output version. The structure of the node output version includes the following fields: The current node's output version identifier (outputVersionId), task identifier (taskId), node identifier within the task (nodeId), configuration snapshot identifier (snapshotId) when executing this node, input data fingerprint (inputFingerprint), upstream node output version set (upstreamOutputVersions), referenced EvidenceUnits set (referencedEvidenceUnits), section identifier (sectionId), structured content produced by this node (structuredContent), content hash (contentHash, i.e., the hash value of structuredContent, used for data integrity verification), and timestamp (createdAt).

[0046] During the execution of tasks by a node, the input evidence unit version, the output version of the upstream node, and the output version of the node are recorded in the shared state space, thereby obtaining the relationship between the evidence unit and the node input, the output dependency relationship between nodes, and the binding relationship between the node output version and the target chapter, and obtaining the mapping relationship between the evidence unit, the node, and the version.

[0047] Preferably, to reduce format drift between agents, intermediate results should conform to a predetermined output data contract.

[0048] In this embodiment, the intermediate results are divided into a text summary track and a structured feature data track. The text summary track is used to convey the theme, arguments, background, and logical relationships; the structured feature data track is used to convey parameters, units, ranges, comparison data, and table content. Before execution at the downstream node, the field types, required fields, units, and evidence citations are validated; if validation fails, the upstream node is set to a pending repair or failed state.

[0049] Preferably, to prevent nodes from executing repeatedly, the state transition of each node is completed through database condition updates. Node states include: pending, running, completed, failed, invalidated, and locked. The execution instance acquires node execution rights through the following SQL condition updates: UPDATE task_node SET status = :targetStatus, execution_token = :executionToken, updated_at = :now WHERE id = :nodeId AND status IN(:validSourceStatuses); The current execution instance only gains node execution rights when the number of rows affected by the update is greater than zero; after the node is completed, the execution_token is verified to prevent late-arriving old execution instances from overwriting the new results.

[0050] Step S4: Generate a set of structured defects.

[0051] Perform consistency checks on intermediate results at nodes or synthesized target documents. The checks are performed by a review agent, deterministic rules, or a human review interface.

[0052] The structured defect record includes: defect ID (defectId), task ID (taskId), section ID (sectionId), defect category (category), severity level (severity), defect description (description), referenced evidence units (referenced EvidenceUnits), defectiveOutputVersionId (defectiveOutputVersionId), originNodeId (originNodeId), and suggestedAction (suggestedAction).

[0053] Furthermore, if the review agent cannot reliably determine the root node, it returns a set of candidate nodes and a confidence level, allowing the rule engine or a human to confirm the root node.

[0054] Step S5: Calculate the failure propagation closure, mark the nodes inside the closure as failed, and lock the outputs of the nodes outside the closure to an immutable reuse state.

[0055] Starting with the output version of the defect-associated node, the failure propagation closure is calculated by combining evidence version changes and task dependencies. Nodes within the closure are marked as failed, and the outputs of nodes outside the closure are locked in an immutable, reusable state.

[0056] The failure propagation closure consists of the following set: (1) Directly generate the root node of the defective output version; (2) The input references nodes of evidence units that have changed or are in conflict; (3) Downstream nodes that directly or indirectly depend on the output versions of the above nodes; (4) Merge nodes and final verification nodes that need to be re-executed.

[0057] If the review results indicate that the error originates from an upstream extraction node, then that upstream node is first added to the closure, and then all nodes that depend on that output version are traversed downwards. Parallel branches that have no dependency on the defect are not added to the closure.

[0058] To avoid overlooking upstream root causes, when the defect review only locates the chapter generation node, a reverse check is performed based on the referenced Evidence Units of that output version and the upstream node output versions: if the evidence unit itself has changed, the extraction node that depends on the evidence unit will be added to the closure; if the evidence unit has not changed but the generated content conflicts with the evidence unit, only the generation node and its downstream nodes will be disabled.

[0059] Step S6: Reload the snapshot of the agent configuration corresponding to the initial execution, and only execute the nodes within the failure propagation closure.

[0060] When a node is executed, the original model, original prompt word template, original parameters, and original output data contract are used first.

[0061] When the original model or external tools are no longer accessible, one of the following alternative strategies should be adopted: (1) Terminate automatic re-execution and prompt for manual confirmation of the new snapshot; (2) Create alternative snapshots and explicitly mark them as new execution conditions, while expanding the scope of end-of-life consistency checks; (3) Restore the original execution conditions using local cache or a reproducible inference environment.

[0062] Step S7: Incremental merging and consistency verification.

[0063] After node re-execution is complete, incremental merging is performed based on the target document structure pattern, chapter identifiers, and version dependencies. Incremental merging uses the node output version instead of directly using temporary streaming text.

[0064] Incremental merging rules include: The same chapter identifier can only be bound to one currently valid output version; The new output version replaces the old version that was marked as invalid; Unaffected chapters directly reference the locked output version and are not regenerated. Tables, figure captions, and cross-references are updated based on stable object identifiers; If two new nodes modify the same chapter at the same time, the conflict will be resolved according to the predetermined priority or manual confirmation strategy. Generate a final document list, recording the node output version and evidence citation set used in each chapter.

[0065] Furthermore, the incrementally merged documents undergo evidence citation integrity and version consistency verification. This specifically includes: (1) Each required chapter exists and is bound to only one valid output version; (2) Does the evidence unit referenced in each output version exist? (3) Whether the current version hash of the cited evidence unit is consistent with the version at the time of node execution; (4) Whether the upstream output version of each node is still a valid version; (5) Whether the terminology, numerical values, units, and cross-references are consistent across chapters; (6) Whether the content hash of the locked node is the same before and after merging; (7) Whether there are still unresolved high-severity structural defects.

[0066] Only after all mandatory checks pass will the target document enter the completed state; otherwise, the system will recalculate the closure based on newly discovered defects or transfer it to the manual confirmation state.

[0067] The present invention also provides a system for implementing the above-described multi-agent document incremental processing method based on evidence version mapping, the system comprising at least the following modules: The heterogeneous document parsing module is used to parse heterogeneous source documents into document evidence units with location identifiers and version hashes; The task dependency graph construction module is used to build document processing nodes and directed task dependency graphs according to the target document structure. The agent configuration snapshot module is used to freeze the configuration used by the agent and create a configuration snapshot; The Evidence-Node-Version Mapping Module is used to construct the mapping relationship between evidence units, nodes, and versions. The structured review module is used to perform consistency reviews on intermediate results of nodes or synthesized target documents; The failure propagation closure calculation module is used to calculate the failure propagation closure. The immutable reuse and local re-execution module is used to mark nodes inside the closure as failed, lock the output of nodes outside the closure to an immutable reuse state, and propagate failures to nodes inside the closure, reloading the agent configuration snapshot corresponding to the initial execution. Incremental merge verification module; used to perform incremental merge as well as verification of evidence citation integrity and version consistency.

[0068] The embodiments of the present invention have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of the invention. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of the invention, and all such substitutions and modifications should fall within the scope of the invention.

Claims

1. A multi-agent document incremental processing method based on evidence version mapping, characterized in that: First, heterogeneous source documents are parsed into document evidence units with location identifiers and version hashes. Second, document processing nodes and a directed task dependency graph are established according to the target document structure. At task initialization, target agents are matched for each node, and the configuration used for this execution is frozen. Nodes are scheduled according to the topological order of the task dependency graph. During the execution of tasks by a node, the input evidence unit version, the output version of the upstream node, and the output version of the node are recorded to obtain the mapping relationship between evidence units, nodes, and versions. When a defect is discovered during the review phase, the defect record points to both the relevant evidence unit and the output version of the node that caused the defect. Then, starting from the output version of the node associated with the defect, the failure propagation closure is calculated by combining the changes in evidence versions and task dependencies. The nodes within the closure are marked as failures, and the output of the nodes outside the closure is locked in an immutable and reusable state. Then, the snapshot of the agent configuration corresponding to the initial execution is reloaded, and only the nodes within the closure are executed; then, incremental merging is performed based on the target document structure pattern, chapter identifier, and version dependency; after the incremental merging is completed, the integrity of evidence reference and version consistency are verified.

2. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: The target document structure pattern defines at least the chapter identifier, chapter order, required attributes, optional attributes, and chapter dependencies.

3. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: The structure of the document evidence unit includes the following fields: unit identifier, task identifier, source document identifier, source document type, type of extracted evidence unit, content of extracted evidence unit, location identifier of extracted evidence unit in source document, version hash of evidence unit, confidence score of extracted evidence unit, and timestamp.

4. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: The version hash of the evidence unit is generated by the SHA-256 algorithm based on the source document identifier, the location identifier of the evidence unit in the source document, and the content of the evidence unit. When the source document is imported again, the source document identifier, the location identifier of the evidence unit in the source document, and the version hash of the evidence unit are used to determine whether the evidence unit is newly added, unchanged, changed, or deleted.

5. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: Each document processing node includes: node identifier, task identifier, node type, stage, set of predecessor nodes, set of input evidence units, output data contract, node execution status, and current output version identifier.

6. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: The configuration snapshot at the time of freezing includes at least: agent identifier and role; model provider type; model name or model version; sampling temperature, maximum output length and timeout parameters; system prompt words and user prompt word template versions; callable tools and tool versions; output data contract version; snapshot generation time and snapshot hash.

7. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: The structure of a node output version includes the following fields: the current node's output version identifier, task identifier, node identifier within the task, configuration snapshot identifier when the node was executed, input data fingerprint, upstream output version set, referenced evidence unit set, chapter identifier, structured content produced by the node, content hash, and timestamp.

8. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: When the defect review only locates the chapter generation node, a reverse check is performed based on the evidence unit referenced in the output version and the output version of the upstream node: if the evidence unit itself has changed, the extraction node that depends on the evidence unit will be added to the closure; if the evidence unit has not changed but the generated content conflicts with the evidence unit, only the generation node and its downstream nodes will be disabled.

9. The multi-agent document incremental processing method based on evidence version mapping according to claim 1, characterized in that: Evidence citation integrity and version consistency verification specifically includes: Each required chapter exists and is bound to only one valid output version; Does the evidence unit referenced in each output version exist? Is the current version hash of the referenced evidence unit consistent with the version at the time the node was executed? Is the upstream output version of each node still a valid version? Are the terms, values, units, and cross-references consistent across chapters? Check if the content hashes of the locked nodes are the same before and after merging; Are there still unresolved high-severity structural defects? 10. A system for implementing the multi-agent document incremental processing method based on evidence version mapping as described in claim 1, characterized in that, The system includes at least the following modules: The heterogeneous document parsing module is used to parse heterogeneous source documents into document evidence units with location identifiers and version hashes; The task dependency graph construction module is used to build document processing nodes and directed task dependency graphs according to the target document structure. The agent configuration snapshot module is used to freeze the configuration used by the agent and create a configuration snapshot; The Evidence-Node-Version Mapping Module is used to construct the mapping relationship between evidence units, nodes, and versions. The structured review module is used to perform consistency reviews on intermediate results of nodes or synthesized target documents; The failure propagation closure calculation module is used to calculate the failure propagation closure. The immutable reuse and local re-execution module is used to mark nodes inside the closure as failed, lock the output of nodes outside the closure to an immutable reuse state, and propagate failures to nodes inside the closure, reloading the agent configuration snapshot corresponding to the initial execution. Incremental merging and verification module; Used for incremental merging and for verifying the integrity of evidence citations and version consistency.

Images