Intelligent agent for sending and receiving official documents based on artificial intelligence and method for generating dataset

Abstract

The application discloses a document receiving and sending intelligent agent based on artificial intelligence and a data set generation method, and particularly relates to the field of artificial intelligence, and relates to intelligent decision-making and trainable data construction of document receiving, distribution, handling, batch handling, circulation, archiving and other businesses. The method models the evidence pointing structure, establishes a stable association between the handling conclusion and the evidence fragments in the text and the attachments, forms a traceable instruction, evidence and action unified sample structure, filters high information density samples through event graph construction and multi-view consistency anomaly analysis, and synthesizes controllable difficult cases in the form of counterfactual disturbance to improve the coverage of complex situations. In the reasoning stage, the process constraint execution mechanism is fused, the candidate actions are filtered and the rejection reason record is output, the model output is ensured to be consistent with the executable action set of the business, and the audit playback and closed-loop incremental learning are supported.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically, to an AI-based intelligent agent for document sending and receiving and a method for generating datasets. Background Technology

[0002] The existing technical solutions closest to intelligent document processing typically employ a rule-driven workflow, with business system field input and manual verification forming a closed loop: the business system collects fields such as DocumentTitle, DocumentType, IssuerOrganization, ReceiverOrganization, IssueDate, ReceiveDate, and HandlingDeadline through fixed forms; after registration, the OA or exchange system generates a processing log; and the system pushes the document to the appropriate role for processing according to preset process nodes. In the automation stage, a common practice is to perform coarse-grained recognition of MainText and AttachmentList based on keyword matching or limited classification models, and then provide next processing suggestions based on the rule engine of the process nodes. The processing personnel select HandlingActionName and fill in ActionCommentText on the interface to complete the process, and finally the system records the processing trajectory for retrieval and auditing.

[0003] The aforementioned existing technologies have shortcomings in actual operation: First, field extraction, action determination, and evidence citation are usually isolated from each other, and the system output is difficult to form a stable traceable structure in the form of DecisionEvidenceLink, resulting in the difficulty of unifying "conclusion and basis" at the data level; Second, the data used for training or optimization mostly comes from the accumulation of regular samples, lacking a systematic difficult example generation mechanism for complex situations, especially lacking structured analysis based on OfficialDocumentEventGraph and counterfactual sample construction based on CounterfactualTrace; Third, the suggested actions in the inference stage often rely only on simple filtering of model confidence or fixed rules, lacking a constraint decoding mechanism that is integrated with business constraints at the same level, resulting in inconsistencies between model output and the actual set of executable actions, and making it difficult to reliably reproduce the entire process of "candidate-filter-decision" in audit playback. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides an AI-based intelligent agent for document sending and receiving and a method for generating datasets, which solves the problems mentioned in the background art through the following solutions.

[0005] To achieve the above objectives, the present invention provides the following technical solution: an artificial intelligence-based intelligent agent for document sending and receiving and a method for generating datasets, comprising: Step 1: Unified Modeling of Semantics and Structure for Official Document Receipt and Dispatch: Establish OfficialDocumentElementSchema, HandlingActionLexicon, HandlingConstraintRuleSet, and DecisionEvidenceLink; Step 2: Multi-source data collection and privacy compliance de-identification of official documents: The multi-source data collection and access process and the field consistency extraction process form a StructuredOfficialDocumentRecord, and the privacy compliance de-identification process and the entity reference order preservation process form a SanitizedStructuredOfficialDocumentRecord. Step 3: Document Behavior Sequence and Event Graph Construction Steps: The OfficialDocumentEventStream is formed through the processing log serialization process and the document receipt and dispatch event definition process, and the OfficialDocumentEventGraph is formed through the event graph construction process. AnomalySamplingPolicy is generated by combining the multi-perspective consistency anomaly analysis process. Step 4: Generation and Synthesis of Difficult Examples of Official Document Receipt and Sending Dataset: The OfficialDocumentReceiveSendAgentDataset is generated through the sample task decomposition process, the anomaly-driven sample selection process, the instruction-evidence-action triple generation process, the counterfactual perturbation difficult example synthesis process, and the consistency verification and label freezing process. Step 5: Training and Constraint Decoding Integration of Official Document Receiving and Sending Agent: The OfficialDocumentReceiveSendAgentModel is generated through a dual-encoding representation learning process, a difficult example comparison learning process, a multi-task supervised fine-tuning process, and a constraint decoding fusion process. Step Six: Online Reasoning, Audit Playback, and Closed-Loop Self-Learning Steps: Closed-loop updates are achieved through online input orchestration process, constraint-aware action reasoning process, evidence chain audit playback process, risk-triggered active learning process, and incremental dataset addition process.

[0006] The technical effects and advantages of this invention are as follows: To address the issue of difficulty in unifying and tracing conclusions and evidence, this solution uses an evidence-pointing structure modeling process to structurally locate the evidence fragments corresponding to each HandlingActionName using EvidencePointerList. In the dataset generation stage, an instruction-evidence-action triple generation process solidifies InstructionText, EvidencePointerList, and ActionLabel into InstructionEvidenceActionTriple. Then, a consistency verification and label freezing process writes the sample labels into LabelFreezeStore, enabling the document sending and receiving agent to express input, evidence, and actions with the same structure during training and inference. In the evidence chain audit playback process, OnlineDecisionEvidenceLink maintains a consistent presentation of online output and evidence chain. To address the issue of insufficient coverage of complex scenarios due to the lack of a systematic hard example generation, this solution constructs an OfficialDocumentEventGraph through an event graph construction process. In a multi-perspective consistency anomaly analysis process, it generates AnomalyDrivenFeatureSet and AnomalySamplingPolicy through progressive analysis from statistical, graph structure, and semantic perspectives. Then, an anomaly-driven sample selection process prioritizes extracting samples with higher information density from the SelectedSamplePool. Simultaneously, a counterfactual perturbation hard example synthesis process is combined with EvidenceNeighborhoodSwapStrategy, ConstraintBorderActionSwapStrategy, and TwoHopOrganizationSwapStrategy to generate sample families with CounterfactualTrace. This constructs a controllable hard example system that is "approximately correct but incorrect" from the data source, enabling the dataset to have stronger coverage in terms of structural complexity and semantic fine-grainedness. To address the issue of inconsistencies between model output and the set of executable business actions, and the difficulty in reproducing these discrepancies during auditing, this solution uses a constraint decoding fusion process at runtime. The ConstraintExecutionEngine is used as a hard constraint component in the inference phase. Constraint filtering is applied to CandidateActionDistribution and CandidateOrganizationDistribution to generate ConstraintFilteredActionSet, and ConstraintAwareActionOutput and a set of rejection reasons are output. Simultaneously, an evidence chain audit replay process is used in AuditReplayStore to record the complete chain of candidate set, constraint filtering, and final selection. This ensures that online inference and business process constraints remain consistent at the same level, and provides a reproducible decision trajectory for problem localization and accountability auditing. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the unified modeling structure for business semantics and structure in this invention.

[0008] Figure 2 This is a schematic diagram of the multi-source data collection and privacy compliance de-identification structure of the present invention.

[0009] Figure 3 This is a schematic diagram of the behavior sequence to event graph and anomaly analysis structure of the present invention.

[0010] Figure 4 This is a schematic diagram of the dataset generation and difficult example synthesis structure of the present invention.

[0011] Figure 5 This is a schematic diagram of the integrated structure for training and runtime constraint decoding of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] refer to Figures 1-5 The AI-based document sending and receiving intelligent agent and dataset generation method shown include: Step 1: Unified Modeling of Semantics and Structure for Document Receiving and Sending Business. First, establish a field system for the document receiving and sending domain through a document element definition process. Then, fix the semantics of actions such as receiving, drafting, approving, circulating, archiving, returning, correcting, and distributing into computable labels through an action lexicon alignment process. Next, solidify the sequential constraints, role constraints, and time limit constraints of document flow into a machine-executable set of constraints through a process constraint rule modeling process. Finally, establish a traceable association between each processing conclusion and the evidence fragments it references through an evidence-oriented structure modeling process, providing a unified input-output structure for subsequent steps in generating document receiving and sending datasets and training document receiving and sending intelligent agents.

[0014] The document element definition process first defines OfficialDocumentElementSet as a fixed field list at the implementation layer, and writes DocumentIdentifier, DocumentTitle, DocumentType, SecurityLevel, UrgencyLevel, IssuerOrganization, ReceiverOrganization, IssueDate, ReceiveDate, HandlingDeadline, AttachmentList, MainText, ReferenceNumber, and RelatedDocumentIdentifierList into this list with the same name, so that all subsequent processing uses this list as the field source only; Subsequently, corresponding value types and validation rules are generated for each field and combined into an OfficialDocumentElementSchema. The value types and validation rules are saved as field attributes of the OfficialDocumentElementSchema in the form of executable expressions, enabling the system to perform field-by-field validation on any input record and output a pass or fail result. Finally, the OfficialDocumentElementSchema is written to the BusinessSemanticRepository and bound to the SchemaVersion. During the writing process, the SchemaVersion and the change record of that version are saved to the BusinessSemanticRepository at the same time, so that the same SchemaVersion is consistently read and used during training data generation and online inference.

[0015] The process of aligning the action vocabulary first constructs a HandlingActionLexicon at the implementation layer as the unique carrier of the action vocabulary, and writes four types of fields for each action item: HandlingActionName, HandlingActionTriggerPattern, HandlingActionRoleConstraint, and HandlingActionStateTransition, so that each action item can simultaneously describe the action name, trigger mode, role constraint, and state transition. Then, the action codes in the historical system are mapped one by one to HandlingActionName and a HandlingActionMappingTable is generated. When writing to the HandlingActionMappingTable, each historical action code points to the HandlingActionName that already exists in HandlingActionLexicon. When loading historical data or accessing new data, the source action code is converted to HandlingActionName through the HandlingActionMappingTable. Finally, synonymous actions are given the same HandlingActionName, and different triggering modes are written into the corresponding action item's HandlingActionTriggerPattern. This ensures that synonymous actions maintain the same HandlingActionName at the label level and are distinguished by the HandlingActionTriggerPattern at the trigger recognition level, making the training data and running data consistent in the HandlingActionName dimension.

[0016] The process constraint rule modeling process first defines HandlingConstraintRuleSet as a rule set in the implementation layer, and implements each rule as a rule item containing RuleIdentifier, RuleScope, RuleCondition, and RuleAction. The storage structure of the rule item remains fixed, so that before any rule is executed, the applicable scope is determined by RuleScope and whether it is triggered is determined by RuleCondition, and the execution result is output by RuleAction. Subsequently, the time constraint is implemented as DeadlineConstraintRule, the role constraint as RoleConstraintRule, and the sequence constraint as SequenceConstraintRule. All three types of rules are written into HandlingConstraintRuleSet as rule items. When writing, RuleIdentifier is used to ensure that the rule can be uniquely identified, which is used to track the specific rule that causes permission or denial at runtime. Finally, ConstraintExecutionEngine is implemented as the rule execution engine. The input of ConstraintExecutionEngine is a fixed sequence of candidate actions, and each rule item is evaluated according to HandlingConstraintRuleSet. For each candidate action, RuleCondition is performed under the corresponding RuleScope, and RuleAction is applied accordingly. The output is a fixed set of executable actions and a set of rejection reasons. The set of rejection reasons directly records the RuleIdentifier that triggered the rejection and the corresponding rejection judgment result, which is used to reuse the rule execution results in subsequent processes.

[0017] The evidence pointing structure modeling process first defines EvidencePointer at the implementation layer and fixes it to include four fields: EvidenceDocumentIdentifier, EvidenceSpanStartIndex, EvidenceSpanEndIndex, and EvidenceType. EvidenceSpanStartIndex and EvidenceSpanEndIndex use the same index benchmark to locate the range of evidence fragments on the same EvidenceDocumentIdentifier text, so that the same evidence fragment is located consistently when it is referenced in different stages. Subsequently, DecisionEvidenceLink is defined and includes three fixed fields: DecisionIdentifier, HandlingActionName, and EvidencePointerList. When constructing DecisionEvidenceLink, DecisionIdentifier uniquely identifies a processing conclusion, and HandlingActionName identifies the action tag corresponding to that conclusion. Multiple EvidencePointers corresponding to that conclusion are then written into EvidencePointerList to express multiple evidence citation relationships. Finally, DecisionEvidenceLink is written to BusinessSemanticRepository and remains searchable by DecisionIdentifier and HandlingActionName. During writing, it is ensured that each EvidencePointer in EvidencePointerList contains a complete EvidenceDocumentIdentifier and span index fields. This allows the dataset generation phase to directly read DecisionEvidenceLink from BusinessSemanticRepository and construct the necessary evidence pointing information for instructions, evidence, and conclusion samples.

[0018] Step Two: Multi-Source Data Collection and Privacy Compliance Desensitization of Official Documents: Through a multi-source collection and access process, the main text of official documents, attachments, processing logs, and receipt and dispatch registration information are aggregated into a unified storage. Then, through a field consistency extraction process, fields are extracted according to the OfficialDocumentElementSchema. Through a privacy compliance desensitization process, sensitive fields are reversibly or irreversibly processed while retaining the desensitization mapping. Finally, through an entity reference order preservation process, the reference relationship between entities in the text before and after desensitization is ensured to be not destroyed. The final output is a SanitizedOfficialDocumentCorpus that can be used for analysis in subsequent steps of constructing official document behavior sequences and event graphs.

[0019] The multi-source acquisition and access process first fixes the access source as SourceSystemSet and configures the corresponding SourceConnector for each SourceSystemSet in the implementation, so that each source outputs a data object that can be stored in a unified way; Subsequently, SourceConnector assembles the official document body, attachment binary, metadata, and processing log from the source system into RawOfficialDocumentPackage according to the same structure. During assembly, the original fields are written as they were from the source and the source identifier is retained for traceability. Then, RawOfficialDocumentPackage is written to IngestionQueue, and DocumentIdentifier and SourceEventIdentifier are combined as idempotent keys during writing. Repeated writing with the same idempotent key is directly determined as the same event and avoids generating duplicate RawOfficialDocumentPackage records, thereby ensuring that the same source event is processed only once in the subsequent processing chain. Finally, the RawOfficialDocumentPackage that was successfully written is recorded with its entry order and timestamp information into the IngestionQueue to ensure stable consumption in the queue order and to form a definite input-output relationship with the subsequent field-consistent extraction process.

[0020] The field uniformity extraction process first reads RawOfficialDocumentPackage from IngestionQueue and performs unified parsing on the main text and attachments, converting the main text and attachment text into UnifiedTextContent. When generating UnifiedTextContent, paragraph index and page index are retained and the index is bound to the text content to ensure consistency between subsequent positioning and referencing. Then, according to OfficialDocumentElementSchema, the metadata of UnifiedTextContent and RawOfficialDocumentPackage is extracted, and the extracted fields are written to StructuredOfficialDocumentRecord. When writing, the field name and value type defined in OfficialDocumentElementSchema are strictly used for each field to ensure that StructuredOfficialDocumentRecord and OfficialDocumentElementSchema correspond one-to-one. Then, during the extraction process, an ExtractionTrace is generated and bound to the same StructuredOfficialDocumentRecord for storage. The ExtractionTrace records the rule hit information and model confidence and corresponds to the extraction results of specific fields, so that the extraction path can be traced back by field when it is necessary to review or reuse it later. Finally, the StructuredOfficialDocumentRecord and its corresponding ExtractionTrace are output together to the subsequent processing chain, and the DocumentIdentifier is kept indexable to ensure that the subsequent process can stably associate the same document record.

[0021] The privacy compliance desensitization process first defines SensitiveFieldSet in the implementation and includes personal name, ID number, mobile phone number, address, account, internal organization code, and classified number into SensitiveFieldSet with a unified name, so that desensitization is performed only around the fields in this set and the field range is fixed; Then, the StructuredOfficialDocumentRecord entering the process is checked field by field to see if it belongs to SensitiveFieldSet. For fields that need to be reversibly processed, the ReversibleTokenizationService is called to generate ReversibleToken and the mapping relationship is written to TokenMappingVault. When writing, the original value of the same field is kept to correspond one-to-one with the ReversibleToken and can be retrieved by document record. For fields that require irreversible processing, call IrreversibleMaskingService to generate unrecoverable text and directly replace the field value, so that the desensitization result can continue to participate in subsequent processing without relying on external restoration. Then, the desensitized field results are written to SanitizedStructuredOfficialDocumentRecord and a SanitizationPolicyIdentifier is attached to the record, so that any subsequent step that uses the record can identify the desensitization strategy used based on the SanitizationPolicyIdentifier; Finally, a SanitizedStructuredOfficialDocumentRecord is output, maintaining its associativity with the original StructuredOfficialDocumentRecord at the DocumentIdentifier level, so as to perform consistency verification and traceability under compliance requirements.

[0022] The entity reference order preservation process first generates an EntityMentionIndex based on the corresponding text content in the StructuredOfficialDocumentRecord. When generating the EntityMentionIndex, the entity mention position is recorded and a CoreferenceGroupIdentifier is assigned to the coreference relationship, so that multiple mentions of the same entity are uniformly grouped at the index level. Subsequently, when performing the de-identification replacement, the CoreferenceGroupIdentifier is used as the consistency key to ensure that the same CoreferenceGroupIdentifier is mapped to the same ReversibleToken or the same irreversible placeholder. During the replacement process, consistent replacement is performed on all mentioned positions to ensure that the entity reference relationship is not broken or confused before and after de-identification. Then the replaced text is output as ReferencePreservedTextContent and the correspondence with EntityMentionIndex is preserved, so that when referencing based on text position in the future, the same entity mention can still be found through the same position index; Finally, the ReferencePreservedTextContent is bound to the SanitizedStructuredOfficialDocumentRecord for output, ensuring that the references and references to entities remain stable and consistent when using this text to build graph structures or generate samples in the future.

[0023] Step 3: Document Behavior Sequence and Event Graph Construction Steps: First, the processing log is converted into a timestamped action sequence through the processing log serialization process. Then, the action sequence is mapped to a unified event object through the document receipt and dispatch event definition process. Next, the event graph construction process is used to construct multi-type graphs by combining personnel, institutions, document types, actions, and evidence fragments. Finally, the event graph is subjected to progressive data analysis through a multi-perspective consistency anomaly analysis process to generate anomaly-driven features (AnomalyDrivenFeatureSet) and sample selection strategies for use in subsequent document receipt and dispatch dataset generation steps.

[0024] The processing log serialization process takes the processing logs in SanitizedStructuredOfficialDocumentRecord as input, reads each processing log record one by one and generates a HandlingLogEntry. Each HandlingLogEntry is strictly filled with five fields: ActorIdentifier, HandlingActionName, ActionTimestamp, ActionCommentText, and TargetOrganizationIdentifier. Among them, HandlingActionName is written after aligning the action name with HandlingActionLexicon and HandlingActionMappingTable, so that the same action is written with the same HandlingActionName in different source systems.

[0025] After generating the HandlingLogEntry, sort all HandlingLogEntries under the same DocumentIdentifier in ascending order by ActionTimestamp and output the HandlingActionSequence. When sorting, records with the same timestamp are kept in a stable order by using the event order field of the source system. This stable order is written to SequenceStateTrace to record the sequence of actions.

[0026] For HandlingLogEntry entries with missing ActionTimestamps, the inferred ActionTimestamp is inferred using the event sequence from the source system and the time range of adjacent events. Simultaneously, a TimestampImputationFlag is added to the HandlingLogEntry and its corresponding SequenceStateTrace location to distinguish between the inferred timestamp and the original timestamp. After completing the full sequence processing, HandlingActionSequence and SequenceStateTrace are output as inputs for subsequent document sending and receiving event definition processes. It is ensured that each HandlingActionName in HandlingActionSequence can be found in HandlingActionLexicon to prevent sequences from failing to map to event objects.

[0027] The document sending and receiving event definition process takes HandlingActionSequence as input, traverses each action in sequence, and generates an OfficialDocumentEvent for each action. The EventIdentifier is generated by combining DocumentIdentifier and action sequence number and is kept unique. DocumentIdentifier is directly inherited from the document to which the current sequence belongs. HandlingActionName, ActorIdentifier, and ActionTimestamp are inherited from the corresponding HandlingLogEntry fields.

[0028] When generating an OfficialDocumentEvent, the event state is maintained synchronously. EventStateBefore is taken from the EventStateAfter of the previous event. The EventStateBefore of the first event is taken from the initial state of the document and written to the starting state position of SequenceStateTrace. EventStateAfter is calculated based on the HandlingActionStateTransition corresponding to the HandlingActionName in HandlingActionLexicon and the current EventStateBefore and written to the event. At the same time, this state transition is written to SequenceStateTrace to keep it consistent with the event flow.

[0029] After the event fields are populated, an EventEvidencePointerList is generated for each OfficialDocumentEvent. The generation method is to align with the DecisionEvidenceLink using the EventIdentifier and HandlingActionName of the current OfficialDocumentEvent as keys and retrieve the EvidencePointerList. If multiple DecisionEvidenceLinks are aligned, the DecisionEvidenceLink closest to the OfficialDocumentEvent is selected according to the ActionTimestamp proximity principle, and its EvidencePointerList is written into the EventEvidencePointerList. If no alignment is found, the EventEvidencePointerList is written as an empty list, and the event objects are retained without being discarded to ensure the integrity of the event flow.

[0030] After all events are generated, the OfficialDocumentEventStream is output according to the ActionTimestamp, and the OfficialDocumentEventStream and HandlingActionSequence are guaranteed to maintain a one-to-one correspondence in terms of the number and order of events. This allows the event graph construction process to directly use the OfficialDocumentEventStream to construct nodes and edges and reuse the order information in SequenceStateTrace.

[0031] The event graph construction process takes OfficialDocumentEventStream as input, constructs OfficialDocumentEventGraph in EventGraphStore, and uses predetermined node types DocumentNode, ActorNode, OrganizationNode, ActionNode, EvidenceNode and predetermined edge types PERFORMS_EDGE, ROUTES_TO_EDGE, CITES_EDGE, FOLLOWS_EDGE, RELATES_EDGE.

[0032] For each OfficialDocumentEvent, first, ensure that there is a unique DocumentNode and write or search for that node using DocumentIdentifier as the primary key; then, ensure that there is a unique ActorNode and write or search for that node using ActorIdentifier as the primary key; next, ensure that there is a unique ActionNode and write or search for that node using HandlingActionName as the primary key; if the event contains TargetOrganizationIdentifier, ensure that there is a unique OrganizationNode and write or search for that node using TargetOrganizationIdentifier as the primary key.

[0033] After node preparation is complete, PERFORMS_EDGE is written to connect ActorNode and ActionNode, and ActionTimestamp and DocumentIdentifier are recorded in the edge attributes for subsequent time window aggregation; ROUTES_TO_EDGE is written to connect ActionNode and OrganizationNode, and ActionTimestamp and DocumentIdentifier are recorded in the edge attributes for counting cross-organization routing times; EventEvidencePointerList is processed one by one, and a corresponding EvidenceNode is created or found based on each EvidencePointer and written to CITES_EDGE to connect ActionNode and EvidenceNode. At the same time, EvidenceDocumentIdentifier, EvidenceSpanStartIndex, EvidenceSpanEndIndex, and EvidenceType are recorded in the CITES_EDGE attribute for reference in subsequent consistency analysis.

[0034] To establish sequential relationships, adjacent events are written to FOLLOWS_EDGE in the order of OfficialDocumentEventStream. This edge connects the ActionNode corresponding to the previous event to the ActionNode corresponding to the next event and writes the time difference feature InterEventTimeDelta. InterEventTimeDelta is obtained by subtracting the ActionTimestamp of the previous event from the ActionTimestamp of the next event and is persisted along with the edge. When adjacent events cross DocumentIdentifiers, they are not written to FOLLOWS_EDGE, but only within the same DocumentIdentifier to maintain the semantic consistency of the sequence.

[0035] To construct the association, RELATES_EDGE is written between the corresponding DocumentNodes based on the RelatedDocumentIdentifierList in StructuredOfficialDocumentRecord, and the association source field name is recorded in the RELATES_EDGE attribute for traceability. Finally, the TemporalAggregationFeature is maintained for each node in the OfficialDocumentEventGraph. The TemporalWindowLength is used as the window parameter to update and write the inbound and outbound edge counts of the node within the window, the coverage of different HandlingActionNames, and the InterEventTimeDelta aggregation statistics. This allows the subsequent multi-view consistency anomaly analysis process to directly read the TemporalAggregationFeature and edge attributes to achieve multi-view progressive analysis.

[0036] The multi-perspective consistency anomaly analysis process takes OfficialDocumentEventGraph as input, reads InterEventTimeDelta and CITES_EDGE reference information from each DocumentNode, ActorNode, OrganizationNode and edge attributes from EventGraphStore, as well as the TemporalAggregationFeature of the node, and generates AnomalyDrivenFeatureSet that can be used for sample selection in the order of "statistical perspective sub-process, graph structure perspective sub-process, semantic perspective sub-process" and outputs AnomalySamplingPolicy.

[0037] In the statistical perspective sub-process: robust covariance anomaly scoring sub-process, a numerical feature vector x_d is constructed for each DocumentNode. x_d consists of the number of processing times, average InterEventTimeDelta, cross-agency routing times, number of rejections, number of corrections, and evidence citation coverage. The number of processing times is calculated by the number of events under the constraints of PERFORMS_EDGE associated with the DocumentNode and the same DocumentIdentifier. The average InterEventTimeDelta is obtained by averaging the InterEventTimeDelta of all FOLLOWS_EDGEs within the same DocumentIdentifier. The number of cross-agency routing times is obtained by counting ROUTES_TO_EDGEs within the same DocumentIdentifier. The number of rejections and corrections is obtained by matching the HandlingActionName of the ActionNode within the same DocumentIdentifier with the corresponding rejection and correction items in HandlingActionLexicon and counting them. The evidence citation coverage is obtained by the proportion of the number of events in CITES_EDGE within the same DocumentIdentifier to the total number of events.

[0038] The entire set of DocumentNodes x_d is used to calculate the robust mean μ and robust covariance Σ. For each DocumentNode, the anomaly distance A_stat(d) is calculated using the following formula, and the results are written to the statistical perspective rating field in AnomalyDrivenFeatureSet with DocumentIdentifier as the key:

[0039] Where d is the DocumentNode corresponding to DocumentIdentifier, x_d is the numerical feature vector of that DocumentNode, μ is the robust mean vector of features of all DocumentNodes, and Σ is the robust covariance matrix of features of all DocumentNodes.

[0040] After completing the statistical perspective scoring, the process proceeds to the graph structure perspective subprocess: the neighborhood consistency deviation scoring subprocess. For each ActorNode, within the time window defined by TemporalWindowLength, the distribution of ActionNodes pointed to by its PERFORMS_EDGE is statistically analyzed, forming an action distribution vector p_a. Then, in OfficialDocumentEventGraph, the OrganizationNodes involved in the events in which the ActorNode participates are used as the neighborhood set. Based on the action statistics within the same window in the neighborhood set, a group distribution q_org(a) is formed, maintaining the same dimension and the same HandlingActionName order as p_a. Subsequently, the deviation degree A_graph(a) is calculated, and the result is written to the graph structure perspective scoring field in AnomalyDrivenFeatureSet with ActorIdentifier as the key. During the calculation, only the probability distribution vector of the HandlingActionName dimension is used to ensure consistency with HandlingActionLexicon.

[0041] After completing the graph structure perspective scoring, the semantic perspective sub-process enters: the evidence-conclusion consistency comparison scoring sub-process. It iterates through each OfficialDocumentEvent by OfficialDocumentEventStream, takes the ActionCommentText of the event as the conclusion text, and extracts the corresponding evidence fragment text from ReferencePreservedTextContent according to the EventEvidencePointerList of the event. Then, it generates a semantic vector and calculates the consistency score A_sem(e). The consistency score is calculated within the same event by comparing the conclusion text and the evidence fragment text of the event and writes it into the semantic perspective scoring field of AnomalyDrivenFeatureSet with EventIdentifier as the key.

[0042] After the three types of scores are generated, A_stat(d), A_graph(a), and A_sem(e) are normalized according to a unified scale and written into AnomalyDrivenFeatureSet, and AnomalySamplingPolicy is output. AnomalySamplingPolicy prioritizes high A_stat(d), high A_graph(a), and high A_sem(e) as extraction conditions for direct use in subsequent anomaly-driven sample selection processes. At the same time, it ensures that AnomalyDrivenFeatureSet retains the index relationship between each score and its corresponding DocumentIdentifier, ActorIdentifier, and EventIdentifier so that it can be retrieved and aggregated by the same object key in subsequent steps.

[0043] Step 4: Generation of Official Document Receiver and Sender Dataset and Synthesis of Difficult Examples: First, the ability that the agent needs to learn is broken down into trainable tasks through a sample task decomposition process. Then, samples with information density are selected based on the AnomalySamplingPolicy through an anomaly-driven sample selection process. A unified supervised sample structure is constructed through an instruction-evidence-action triple generation process. High-quality negative samples are generated by controllably perturbing the evidence and actions through a counterfactual perturbation difficult example synthesis process. Labels are frozen using ConstraintExecutionEngine and evidence-pointing structure through a consistency check and label freezing process. Finally, the OfficialDocumentReceiveSendAgentDataset is produced for subsequent training.

[0044] The sample task decomposition process reads SanitizedStructuredOfficialDocumentRecord, HandlingActionSequence, SequenceStateTrace, DecisionEvidenceLink, and ReferencePreservedTextContent for each record entering step four within the scope of TaskTypeSet, and generates a task sample view for the same record according to the task type. For TaskType_RoutingDecision, the routing-related fields in OfficialDocumentElementSet are combined with the last state in the current SequenceStateTrace to form the input, and the actual TargetOrganizationIdentifier and the corresponding HandlingActionName of the next step of this record are written into the output field; For TaskType_DeadlineAssessment, the HandlingDeadline, ActionTimestamp sequence and HandlingActionSequence are taken as input, and the risk level label obtained by direct mapping from the existing fields is written into the output field. At the same time, the identifier that the label comes from the same record is retained so that it can be associated with ConstraintExecutionEngine for subsequent verification. For TaskType_EvidenceCitation, the ActionCommentText from which the processing conclusion text originates is taken as input, and the EvidencePointerList corresponding to the processing conclusion in DecisionEvidenceLink is written into the output field; For TaskType_ConstraintAwareActionSelection, the current state and the set of candidate actions are taken as input. The set of candidate actions comes from the set of HandlingActionNames that may appear in the current state of the same record. The HandlingActionName sequence corresponding to the actual action sequence that occurs in the record is written into the output field to ensure that the four types of task samples share the same DocumentIdentifier and can be traced back to the SequenceStateTrace and DecisionEvidenceLink of the same record.

[0045] The anomaly-driven sample selection process reads the anomaly score from the AnomalyDrivenFeatureSet output in step three, aligning the DocumentIdentifier with the event dimension, and calculates whether each candidate record meets the conditions for entering the SelectedSamplePool based on the AnomalySamplingPolicy. When performing threshold filtering, the same parameter AnomalySelectionThreshold is used for alignment judgment. The judgment object is the set of abnormal scores corresponding to the record and the selection order is determined by the priority specified by the strategy. After completing threshold filtering, stratified sampling is performed using DocumentType and SecurityLevel as stratification keys. During sampling, the original abnormal score and source identifier of the samples in each stratum are retained. When the final selected record is written to SelectedSamplePool, its anomaly score field is also written and the binding relationship with DocumentIdentifier is retained. This ensures that the subsequent instruction-evidence-action triple generation process can directly read from SelectedSamplePool and reuse the ReferencePreservedTextContent, DecisionEvidenceLink and SequenceStateTrace of the same record.

[0046] The instruction-evidence-action triple generation process first generates an InstructionText for each record in SelectedSamplePool and confirms that the text content only references the field names, field values, and HandlingActionName and TargetOrganizationIdentifier of OfficialDocumentElementSet. During generation, the fields in the StructuredOfficialDocumentRecord of the record are filled into the InstructionText in a fixed order, and the output requirements corresponding to the current task are directly written into the InstructionText with the same name. Subsequently, when constructing the evidence section, the EvidencePointerList is read from the DecisionEvidenceLink of the record, and the EvidenceSpanStartIndex and EvidenceSpanEndIndex in each EvidencePointer are used to extract evidence fragments from the ReferencePreservedTextContent of the record. At the same time, the original EvidencePointerList is preserved in the sample structure to support position index references. When reconstructing the action label, an ActionLabel is generated and the HandlingActionName and TargetOrganizationIdentifier are written into it. At the same time, the entire SequenceStateTrace of this record is written into the ActionLabel to fix the state transition context. Finally, InstructionText, EvidencePointerList, and ActionLabel are encapsulated into InstructionEvidenceActionTriple according to a unified set of fields, and a sample identifier is generated. This allows each InstructionEvidenceActionTriple to trace back to the DecisionEvidenceLink and ReferencePreservedTextContent of the same record through DocumentIdentifier, thereby providing a locatable replacement target for the subsequent counterfactual perturbation difficult example synthesis process.

[0047] The counterfactual perturbation hard example synthesis process performs perturbation to generate counterfactual samples on each InstructionEvidenceActionTriple in a way that can be recorded by CounterfactualTrace, and generates a unique CounterfactualSampleIdentifier for each perturbation to distinguish the original sample from the counterfactual sample. When executing EvidenceNeighborhoodSwapStrategy, within the same DocumentIdentifier range, the evidence fragments pointed to by EvidencePointerList are used as the center. Based on the paragraph index in ReferencePreservedTextContent, the evidence fragments corresponding to adjacent paragraphs are selected and replaced with the pointed range in the original EvidencePointerList. At the same time, EvidenceDocumentIdentifier is kept unchanged and EvidenceSpanStartIndex and EvidenceSpanEndIndex before and after the replacement are recorded in CounterfactualTrace. When ConstraintBorderActionSwapStrategy is executed, ConstraintExecutionEngine is called with the current state of the original sample and the set of candidate actions to obtain the set of executable actions. Then, a HandlingActionName that is different from the original HandlingActionName is selected from the set of executable actions as the replacement value and written into the ActionLabel of the counterfactual sample. At the same time, the original HandlingActionName, the replaced HandlingActionName and the constraint execution result identifier used for filtering are recorded in CounterfactualTrace to ensure that the replacement action is still within the range allowed by ConstraintExecutionEngine. When TwoHopOrganizationSwapStrategy is executed, the original TargetOrganizationIdentifier is replaced with the TargetOrganizationIdentifier corresponding to the "organization node that can be reached by two hops in the graph" based on the graph structure relationship corresponding to the sample, and written into the ActionLabel of the counterfactual sample. At the same time, the original TargetOrganizationIdentifier and the replaced TargetOrganizationIdentifier are recorded in CounterfactualTrace. After completing a single perturbation, the counterfactual samples are kept with the same InstructionText structure and field naming as the original samples. The CounterfactualSampleIdentifier and CounterfactualTrace are then appended to the sample metadata to form a counterfactual set that can be used for subsequent training to distinguish the source. At the same time, it is ensured that each counterfactual sample can still be verified by the same ConstraintExecutionEngine and DecisionEvidenceLink in the subsequent consistency verification and label freezing process.

[0048] The consistency verification and label freezing process first performs constraint consistency verification on each InstructionEvidenceActionTriple entering the process. During verification, the current state information in the sample is assembled with the HandlingActionName and TargetOrganizationIdentifier in ActionLabel according to the input format of ConstraintExecutionEngine and ConstraintExecutionEngine is called to obtain the verification result. If the sample action meets the constraints, it is written to ConstraintPassFlag as a pass status and the constraint filtering record is retained. If the constraints are not met, it is written to the rejection reason set and the sample is marked as not entering OfficialDocumentReceiveSendAgentDataset. Subsequently, an evidence consistency check is performed. During the check, the DocumentIdentifier of the sample is used to locate the corresponding DecisionEvidenceLink and the coverage relationship between the EvidencePointerList in the sample and the EvidencePointerList of the corresponding handling conclusion in the DecisionEvidenceLink is checked, thereby generating EvidenceCoverageFlag. A sample is written to the OfficialDocumentReceiveSendAgentDataset and its label information and sample identifier are written to LabelFreezeStore only if the ConstraintPassFlag of the same sample is in the pass state and the EvidenceCoverageFlag is in the coverage satisfaction state. During the writing process, ActionLabel, EvidencePointerList and the DocumentIdentifier bound to them are saved as immutable records, so that the labels and evidence points read in subsequent training remain fixed and can be traced back to the constraint verification record and evidence coverage verification record of the same sample.

[0049] Step 5: Training and Constraint Decoding Integration of Official Document Receiving and Sending Agent: First, learn the joint representation of instructions and evidence through a dual-encoding representation learning process. Then, incorporate difficult examples driven by CounterfactualTrace into the comparison target through a difficult example comparison learning process. Jointly train on TaskTypeSet through a multi-task supervised fine-tuning process. Embed ConstraintExecutionEngine into the action selection of the inference stage through a constraint decoding fusion process. Finally, obtain OfficialDocumentReceiveSendAgentModel and output the deployable OfficialDocumentReceiveSendAgentRuntimePackage.

[0050] The dual-encoding representation learning process reads each InstructionEvidenceActionTriple from the OfficialDocumentReceiveSendAgentDataset before training begins and extracts the InstructionText from it and the evidence fragment text located by EvidencePointerList, so that the evidence fragment text comes from the ReferencePreservedTextContent of the same record and remains consistent with the index of EvidencePointerList. Input the InstructionText into the InstructionEncoder to obtain the vector z_i, input the evidence fragment text into the EvidenceEncoder to obtain the vector z_e, and write the z_i and z_e obtained from each forward calculation into the EmbeddingCache with the sample identifier as the key for reuse within the same training round. z_i and z_e are concatenated in a fixed order to form a concatenated vector, and the concatenated vector is input into FusionLayer to obtain JointRepresentationVector. At the same time, JointRepresentationVector is associated with the task type of the sample and saved, so that subsequent TaskHead_RoutingDecision, TaskHead_DeadlineAssessment, TaskHead_EvidenceCitation, and TaskHead_ConstraintAwareActionSelection can be supervised and learn on the same JointRepresentationVector and share representations.

[0051] When the dual-encoding representation learning process contains multiple evidence fragments in the same InstructionEvidenceActionTriple, the generation order of the evidence fragment texts is fixed by sorting EvidenceSpanStartIndex in EvidencePointerList from smallest to largest, so that the splicing order of the EvidenceEncoder input is consistent across the entire dataset. When the EmbeddingCache is hit, the cached z_i and z_e are reused directly and the repeated calculation of the corresponding encoder is skipped. However, the cached vector is still input into FusionLayer according to the same concatenation rule to obtain JointRepresentationVector in order to keep the input of the head training of subsequent tasks consistent. After each training round, the EmbeddingCache entries corresponding to that round are cleaned up according to the training configuration, so that subsequent rounds can use the same data but allow the encoder parameters to be updated and the vectors to be regenerated, so that the JointRepresentationVector is consistent with the current parameter state.

[0052] The difficult example contrastive learning process reads the original sample and its corresponding counterfactual sample from the dataset simultaneously. The two are aligned with the binding relationship between the CounterfactualSampleIdentifier and the original sample identifier and form a contrastive unit. Multiple contrastive units are organized into a ContrastiveBatch. For each original sample in the ContrastiveBatch, its InstructionText is processed by InstructionEncoder to obtain z_i. The text of the matching evidence fragment is processed by EvidenceEncoder to obtain z_e. For other evidence fragments in the same batch, z_{e,k} is obtained, where z_{e,k} comes from the evidence set of the same batch and does not match z_i. Substitute z_i, z_e, and z_{e,k} into the comparison loss L_contrast calculation, and fix the temperature coefficient as TemperatureTau and maintain the same value configuration throughout the training process to ensure that the comparison learning objective remains consistent across different batches. The formula is as follows:

[0053] Where sim(⋅,⋅) is fixed as cosine similarity, z_i is the output vector of InstructionEncoder, z_e is the evidence vector that matches the instruction, z_{e,k} is the kth evidence vector in the same batch, τ corresponds to TemperatureTau, and K is the number of evidence in the comparison batch. In the contrast unit containing counterfactual samples, the evidence fragment vectors of the counterfactual samples are incorporated into the z_{e,k} set of the same batch to form a stronger negative sample contrast, while keeping the matching relationship of the original samples unchanged. This allows L_contrast to cover both general negative samples and difficult negative samples generated by CounterfactualTrace in the same ContrastiveBatch.

[0054] When the difficult example contrastive learning process corresponds to multiple counterfactual samples for the same original sample, these counterfactual samples are paired with the original sample in the same ContrastiveBatch, and the evidence fragment vector of each counterfactual sample is used as z_{e,k} to participate in the denominator summation, so that the contrast target applies constraints to multiple sources of perturbation at the same time. When EmbeddingCache is enabled during training, z_i, z_e, and z_{e,k} can be directly read from the cache to accelerate the comparison calculation, but the comparison loss is still calculated according to the same formula and participates in the subsequent total loss combination; After the contrast loss is calculated, L_contrast is passed to the backpropagation module as a loss component parallel to the supervision loss, ensuring that its gradient simultaneously updates the parameters of InstructionEncoder, EvidenceEncoder, and FusionLayer to change the distribution of the subsequent JointRepresentationVector.

[0055] In the training loop, the multi-task supervised fine-tuning process extracts samples of different TaskTypes from the OfficialDocumentReceiveSendAgentDataset according to the TaskSamplingRatio by the TaskSamplingRatio and forms training batches. Each sample in the batch is first processed by the InstructionEncoder, EvidenceEncoder and FusionLayer to obtain a JointRepresentationVector and then bound to the TaskType of the sample. When the task type of the sample is TaskType_RoutingDecision, the JointRepresentationVector is input into TaskHead_RoutingDecision to obtain the corresponding output and is aligned with the HandlingActionName and TargetOrganizationIdentifier supervision signals in the sample to calculate the supervision loss; When the task type is TaskType_DeadlineAssessment, the JointRepresentationVector is input into TaskHead_DeadlineAssessment to obtain the output and is aligned with the risk level label of the sample to calculate the supervised loss; When the task type is TaskType_EvidenceCitation, the JointRepresentationVector is input into TaskHead_EvidenceCitation to obtain the output and is aligned with the EvidencePointerList supervision signal of the sample to calculate the supervision loss; When the task type is TaskType_ConstraintAwareActionSelection, the JointRepresentationVector is input into TaskHead_ConstraintAwareActionSelection to obtain the output and is aligned with the action sequence supervision signal of the sample to calculate the supervision loss; In the same training step, the supervision loss of each task and L_contrast are combined linearly to form the total loss L_total, and backpropagation and parameter update are performed to ensure that the four task heads and the shared encoder converge jointly under the same optimization objective.

[0056] If multiple task types exist simultaneously in the same batch, the multi-task supervision fine-tuning process will only call the corresponding task header for each sample and only calculate the supervision loss of that task, so as to avoid invalid updates on the task header of the same sample without defined supervision signals. TaskSampler resamples according to TaskSamplingRatio in each training cycle to maintain a stable long-term task ratio and ensure that each task type in TaskTypeSet is covered during training. When calculating L_total, L_contrast is calculated from the ContrastiveBatch of the same training step or from the constructible set of contrasts within that batch. L_total is used as the sole optimization objective to update all trainable parameters of OfficialDocumentReceiveSendAgentModel, thereby coupling the contrast objective and the multi-task objective in the same parameter space.

[0057] The constraint decoding fusion process calls OfficialDocumentReceiveSendAgentModel on the input OnlineInferenceRequestPackage during the inference phase to obtain the candidate action distribution CandidateActionDistribution and the candidate organization distribution CandidateOrganizationDistribution. Then, it extracts the candidate HandlingActionName set from the CandidateActionDistribution and the candidate TargetOrganizationIdentifier set from the CandidateOrganizationDistribution to form a candidate set. The current state information and the candidate set are input into the ConstraintExecutionEngine to perform constraint filtering, resulting in ConstraintFilteredActionSet and a set of rejection reasons. After filtering, only candidate actions belonging to ConstraintFilteredActionSet are retained. The probability of the retained candidate actions is renormalized, and the optimal action is selected from the renormalized set. When selecting, the optimal HandlingActionName and its corresponding TargetOrganizationIdentifier are combined to form ConstraintAwareActionOutput and output. At the same time, the set of rejection reasons is carried along with ConstraintAwareActionOutput for use in subsequent auditing links. When the ConstraintFilteredActionSet output by ConstraintExecutionEngine is empty, the result is not selected from the filtered actions. Instead, the set of rejection reasons is returned as part of the output and the reasoning result is kept recordable by AuditReplayStore.

[0058] Step Six: Online Inference, Audit Playback, and Closed-Loop Self-Learning Steps: First, the real business input is converted into OfficialDocumentElementSchema format through an online input orchestration process. Then, ConstraintAwareActionOutput is generated and entered into the business system through a constraint-aware action inference process. Each output is associated with DecisionEvidenceLink through an evidence chain audit playback process. Next, AnomalyDrivenFeatureSet is used to perform multiple logical judgments on online samples and prioritize them through a risk-triggered active learning process. Finally, high-value samples are added to OfficialDocumentReceiveSendAgentDataset through an incremental dataset appending process and retraining is triggered to form a closed loop.

[0059] The online input orchestration process receives the official document and context from the business interface, assembles the content into fields according to the StructuredOfficialDocumentRecord data structure, and follows the OfficialDocumentElementSchema for field names and value ranges during assembly. After assembly, the OfficialDocumentElementSchema is validated to obtain the validation results for missing fields and inconsistent formats. When the validation result has missing fields, the ExtractionTrace corresponding to the record is read and the existing rule backfill path in the ExtractionTrace is used to backfill the missing fields. After the backfill is completed, the OnlineImputationFlag is written to the record and the OfficialDocumentElementSchema validation is re-executed to confirm that the backfilled structure still meets the validation rules. When the verification result meets the requirements, the StructuredOfficialDocumentRecord that has completed verification and backfilling annotations and its online context are encapsulated into an OnlineInferenceRequestPackage, and the DocumentIdentifier remains unchanged before and after encapsulation, so that the subsequent constraint-aware action reasoning process can directly use the same DocumentIdentifier to associate the audit and closed-loop process.

[0060] The constraint-aware action reasoning process takes OnlineInferenceRequestPackage as input and sends it to OfficialDocumentReceiveSendAgentModel to obtain candidate outputs. The candidate outputs include CandidateActionDistribution and CandidateOrganizationDistribution and are bound to the same request as the current state information. After obtaining the candidate output, the ConstraintExecutionEngine is called to perform constraint filtering. The filter input uses the current state and candidate set of the request and outputs ConstraintFilteredActionSet. Then, the probability of the candidate action is normalized in ConstraintFilteredActionSet and combined with the candidate organization output to generate the final action and organization selection result, forming ConstraintAwareActionOutput with constraint filtering record. When writing ConstraintAwareActionOutput to the business system, an OnlineActionReceipt is generated simultaneously. The OnlineActionReceipt contains action, organization, timestamp, and constraint filtering records and is consistent with the DocumentIdentifier of the reasoning request. This allows subsequent evidence chain audit playback processes and risk trigger proactive learning processes to use the same receipt for tracing and filtering.

[0061] The evidence chain audit playback process extracts the evidence-related fields of ConstraintAwareActionOutput generated by each online reasoning and binds them to the output as OnlineDecisionEvidenceLink. When binding, the DocumentIdentifier is kept consistent with the output and EvidencePointerList is written into OnlineDecisionEvidenceLink as the evidence pointing carrier for playback to locate evidence fragments. Write the OnlineDecisionEvidenceLink along with the constraint filtering record of this output to the AuditReplayStore. When writing, use DocumentIdentifier as the index key and ensure that multiple outputs under the same DocumentIdentifier can be sorted by timestamp. When playback is performed, the corresponding record is read from AuditReplayStore through DocumentIdentifier and the ConstraintFilteredActionSet and rejection reason set used in this output are displayed at the same time. The playback display is consistent with the stored content and corresponds to the timestamp in OnlineActionReceipt, so that the online action output, constraint filtering record and evidence pointing to the same document can be located and verified in the same link.

[0062] The risk-triggered active learning process calculates the OnlineAnomalyScore for each online sample identified by OnlineActionReceipt. The scoring source used in the calculation is consistent with the multi-perspective consistency anomaly analysis process, and the scoring result is bound to the DocumentIdentifier of that sample. After obtaining the OnlineAnomalyScore, the ActiveLearningTriggerPolicy is used to perform a trigger judgment. The trigger judgment uses ActiveLearningThreshold to compare the OnlineAnomalyScore with a threshold and combines the pattern matching results of the audit rejection reason set to determine whether to trigger manual review. When the triggering condition is met, the sample, along with its DocumentIdentifier, OnlineAnomalyScore, and set of audit rejection reasons, is written to HumanReviewQueue to await manual review. After manual review, the review results are written to HumanVerifiedLabelStore and the review label is kept consistent with the DocumentIdentifier of the original online sample. This allows the subsequent incremental dataset appending process to be aligned to the same online sample and reuse its evidence pointing and action label structure.

[0063] The incremental dataset appending process reads the records that have been verified from HumanVerifiedLabelStore and then converts each record into an InstructionEvidenceActionTriple structure. During the conversion, the naming of the InstructionText, EvidencePointerList and ActionLabel fields is kept consistent with that in step four, and the DocumentIdentifier is kept unchanged, so that the incremental samples can be compatible with the original sample structure. For each transformed InstructionEvidenceActionTriple, perform the same consistency check and label freezing process as in step four. During the check, continue to use ConstraintExecutionEngine to generate constraint check results and continue to use DecisionEvidenceLink to check evidence coverage relationship to generate ConstraintPassFlag and EvidenceCoverageFlag. Only write to LabelFreezeStore to form an immutable record when the check conditions are met. Incremental samples that have passed verification and have been written to LabelFreezeStore are appended to OfficialDocumentReceiveSendAgentDataset. After the append is completed, the training trigger information corresponding to this append is recorded with the training trigger identifier IncrementalTrainingJobIdentifier, and used as the training task identifier for the subsequent integration steps of document sending and receiving agent training and constraint decoding. This ensures that the link from online review to dataset appending to training triggering is aligned within the same naming system.

[0064] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating intelligent agents for official document sending and receiving and for generating datasets based on artificial intelligence, characterized in that, include: Step 1: Unified Modeling of Semantics and Structure for Official Document Receipt and Dispatch: Establish OfficialDocumentElementSchema, HandlingActionLexicon, HandlingConstraintRuleSet, and DecisionEvidenceLink; Step 2: Multi-source data collection and privacy compliance de-identification of official documents: The multi-source data collection and access process and the field consistency extraction process form a StructuredOfficialDocumentRecord, and the privacy compliance de-identification process and the entity reference order preservation process form a SanitizedStructuredOfficialDocumentRecord. Step 3: Document Behavior Sequence and Event Graph Construction Steps: The OfficialDocumentEventStream is formed through the processing log serialization process and the document receipt and dispatch event definition process, and the OfficialDocumentEventGraph is formed through the event graph construction process. AnomalySamplingPolicy is generated by combining the multi-perspective consistency anomaly analysis process. Step 4: Generation and Synthesis of Difficult Examples of Official Document Receipt and Sending Dataset: The OfficialDocumentReceiveSendAgentDataset is generated through the sample task decomposition process, the anomaly-driven sample selection process, the instruction-evidence-action triple generation process, the counterfactual perturbation difficult example synthesis process, and the consistency verification and label freezing process. Step 5: Training and Constraint Decoding Integration of Official Document Receiving and Sending Agent: The OfficialDocumentReceiveSendAgentModel is generated through a dual-encoding representation learning process, a difficult example comparison learning process, a multi-task supervised fine-tuning process, and a constraint decoding fusion process. Step Six: Online Reasoning, Audit Playback, and Closed-Loop Self-Learning Steps: Closed-loop updates are achieved through online input orchestration process, constraint-aware action reasoning process, evidence chain audit playback process, risk-triggered active learning process, and incremental dataset addition process.

2. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 1, characterized in that, The steps for unified semantic and structural modeling of official document sending and receiving operations include: Define OfficialDocumentElementSet and OfficialDocumentElementSchema through the document element definition process and store them in BusinessSemanticRepository; The HandlingActionLexicon and HandlingActionMappingTable are constructed by performing an action word list alignment process to align the HandlingActionName; The process is modeled using process constraint rules, constructing a HandlingConstraintRuleSet and establishing a ConstraintExecutionEngine to output the set of executable actions and the set of rejection reasons; The EvidencePointer and DecisionEvidenceLink are established through the evidence-oriented structural modeling process and saved to the BusinessSemanticRepository.

3. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 1, characterized in that, The steps for multi-source data collection and privacy compliance de-identification of official documents include: The raw data from SourceSystemSet is written to IngestionQueue and stored as RawOfficialDocumentPackage through a multi-source acquisition and access process. The text and attachments are converted into UnifiedTextContent through a field-consistent extraction process, and StructuredOfficialDocumentRecord is extracted according to OfficialDocumentElementSchema and ExtractionTrace is recorded. The SensitiveFieldSet is processed through a privacy compliance desensitization process to obtain a SanitizedStructuredOfficialDocumentRecord with an attached SanitizationPolicyIdentifier by executing ReversibleTokenizationService or IrreversibleMaskingService. The entity reference preserving process generates EntityMentionIndex and CoreferenceGroupIdentifier and outputs ReferencePreservedTextContent.

4. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 1, characterized in that, The steps for constructing the document behavior sequence and event graph include: The processing log is parsed into HandlingLogEntry through the processing log serialization process and sorted by ActionTimestamp to generate HandlingActionSequence and SequenceStateTrace. Logs with missing timestamps are marked with TimestampImputationFlag. The HandlingActionSequence is mapped to OfficialDocumentEvent through the document sending and receiving event definition process, and EventEvidencePointerList is generated and OfficialDocumentEventStream is output. The OfficialDocumentEventGraph is constructed and written to EventGraphStore through the event graph construction process, and InterEventTimeDelta is recorded for FOLLOWS_EDGE and TemporalAggregationFeature is maintained. Anomaly analysis is performed on the OfficialDocumentEventGraph using a multi-perspective consistency anomaly analysis process, and AnomalyDrivenFeatureSet and AnomalySamplingPolicy are output.

5. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 4, characterized in that, The multi-perspective consistency anomaly analysis process includes: The statistical perspective sub-process: the robust covariance anomaly scoring sub-process constructs a numerical feature vector x_d for each DocumentNode and calculates the anomaly distance A_stat(d) based on the robust mean μ and robust covariance; The graph structure perspective sub-process: the neighborhood consistency deviation scoring sub-process calculates the action distribution vector p_a of each ActorNode within the time window and compares it with the distribution of the neighboring OrganizationNode population q_org(a) to obtain the degree of deviation A_graph(a); A semantic perspective sub-process is adopted: the evidence-conclusion consistency comparison and scoring sub-process generates a semantic consistency score A_sem(e) for the evidence fragments corresponding to the ActionCommentText and EventEvidencePointerList of each OfficialDocumentEvent; Then, after normalizing A_stat(d), A_graph(a), and A_sem(e), AnomalyDrivenFeatureSet is generated, and AnomalySamplingPolicy is formed.

6. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 1, characterized in that, The steps for generating the official document receipt and dispatch dataset and synthesizing difficult examples include: A TaskTypeSet is established through the sample task decomposition process, which includes at least TaskType_RoutingDecision, TaskType_DeadlineAssessment, TaskType_EvidenceCitation, and TaskType_ConstraintAwareActionSelection. The anomaly-driven sample selection process performs stratified sampling based on AnomalySamplingPolicy and AnomalySelectionThreshold and outputs SelectedSamplePool. The instruction-evidence-action triplet generation process generates InstructionText, EvidencePointerList, and ActionLabel for the SelectedSamplePool, forming InstructionEvidenceActionTriple; Counterfactual samples containing CounterfactualSampleIdentifier and CounterfactualTrace are generated through a counterfactual perturbation hard example synthesis process. ConstraintExecutionEngine is executed through the consistency check and label freezing process to obtain ConstraintPassFlag and generate EvidenceCoverageFlag based on DecisionEvidenceLink. Samples that meet ConstraintPassFlag and EvidenceCoverageFlag are written to LabelFreezeStore and formed OfficialDocumentReceiveSendAgentDataset.

7. The method for generating intelligent agents for official document sending and receiving and datasets based on artificial intelligence according to claim 6, characterized in that, The counterfactual perturbation difficult example synthesis process includes at least the following: The EvidenceNeighborhoodSwapStrategy is used to select adjacent paragraph evidence fragments within the same DocumentIdentifier to replace the EvidencePointerList. Use ConstraintBorderActionSwapStrategy to replace HandlingActionName near the allowed boundary of ConstraintExecutionEngine; The TargetOrganizationIdentifier is replaced with a two-hop reachable organization node in the OfficialDocumentEventGraph using TwoHopOrganizationSwapStrategy; For each disturbance, a CounterfactualSampleIdentifier is generated and the disturbance trajectory CounterfactualTrace is recorded.

8. The method for generating intelligent agents for official document receipt and dispatch and datasets based on artificial intelligence according to claim 1, characterized in that, The integrated steps of training and constraint decoding for the document sending and receiving agent include: The InstructionEncoder and EvidenceEncoder are constructed through a dual-encoding representation learning process to generate vectors z_i and z_e, which are then processed by FusionLayer to form JointRepresentationVector and cached in EmbeddingCache. The contrastive learning process uses a hard example comparison to form a ContrastiveBatch based on CounterfactualSampleIdentifier and calculates the contrastive loss L_contrast, where the temperature coefficient TemperatureTau is used. The TaskHead_RoutingDecision, TaskHead_DeadlineAssessment, TaskHead_EvidenceCitation, and TaskHead_ConstraintAwareActionSelection are constructed through a multi-task supervised fine-tuning process and trained by sampling according to TaskSamplingRatio using TaskSamplingler. Through the constraint decoding fusion process, during the inference phase, the ConstraintExecutionEngine filters CandidateActionDistribution and CandidateOrganizationDistribution to obtain ConstraintFilteredActionSet and outputs ConstraintAwareActionOutput, thereby obtaining OfficialDocumentReceiveSendAgentModel and OfficialDocumentReceiveSendAgentRuntimePackage.

9. The method for generating intelligent agents for official document receipt and dispatch and datasets based on artificial intelligence according to claim 1, characterized in that, The online reasoning, audit playback, and closed-loop self-learning steps include: The business input is converted into StructuredOfficialDocumentRecord through an online input orchestration process and OfficialDocumentElementSchema is validated. Missing fields are filled back through ExtractionTrace and marked with OnlineImputationFlag, forming OnlineInferenceRequestPackage. The constraint-aware action reasoning process inputs OnlineInferenceRequestPackage into OfficialDocumentReceiveSendAgentModel, calls ConstraintExecutionEngine to output ConstraintAwareActionOutput, and generates OnlineActionReceipt. The online output is bound to the EvidencePointerList as an OnlineDecisionEvidenceLink and saved to the AuditReplayStore through the evidence chain audit playback process. The risk-triggered active learning process generates an OnlineAnomalyScore and, based on the ActiveLearningTriggerPolicy, enters the HumanReviewQueue and writes it to the HumanVerifiedLabelStore when the OnlineAnomalyScore exceeds the ActiveLearningThreshold or when a specific pattern appears for the audit rejection reason. The HumanVerifiedLabelStore record is converted into InstructionEvidenceActionTriple through an incremental dataset appending process. After being written to LabelFreezeStore through consistency verification and label freezing processes, it is appended to OfficialDocumentReceiveSendAgentDataset and IncrementalTrainingJobIdentifier is triggered.

Images