Agent-based cross-system form intent generation and collaborative interaction method

Abstract

The application provides an agent-based cross-system form intention generation and collaborative interaction method, and relates to the technical field of human-computer interaction, which comprises the following steps: generating a standard intention representation through semantic analysis and verification, determining target forms and system entities, and extracting pre-filled data; obtaining interface meta-information to construct structured field knowledge and generate form configurations; rendering a form interface and injecting pre-filled data; constructing a trust chain to verify identity and determine an authorized range, converting form data and calling target interfaces. The application can effectively improve cross-system business form processing efficiency, enhance data security and user experience.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction technology, and in particular to a cross-system form intent generation and collaborative interaction method based on intelligent agents. Background Technology

[0002] With the deepening development of enterprise informatization, the demand for cross-system form processing and business collaboration is increasing. Traditional form processing systems typically use fixed templates and hard-coded rules, making it difficult to adapt to complex and ever-changing business scenarios. Enterprises often have multiple business systems, each with its own independent form processing logic and data model. This forces users to repeatedly enter similar information when switching between different systems, impacting work efficiency. In recent years, the development of artificial intelligence technologies such as natural language processing and knowledge graphs has brought new possibilities to form processing, making it possible to automatically generate and process forms based on user intent.

[0003] Existing technologies still have shortcomings in cross-system form generation and interaction. Current form processing systems lack a deep understanding of users' natural language expressions, typically only recognizing keywords or preset instructions, failing to accurately capture complex user business intentions. This results in generated forms that deviate from actual user needs, requiring users to make numerous modifications and adjustments, reducing work efficiency. Traditional form generation methods are usually based on hard-coded templates, lacking semantic knowledge support, making it difficult to dynamically adjust form structure and field configurations according to business context. Furthermore, form data between different systems is difficult to share, requiring users to repeatedly fill in the same information when operating across systems, increasing operational burden and the possibility of errors. Existing technologies suffer from inadequate security authentication mechanisms in cross-system form interaction, typically employing static permission control strategies that cannot dynamically authorize based on business scenarios and user intentions, easily leading to issues of excessively broad or narrow permissions. Additionally, the lack of a trust chain construction mechanism based on business knowledge graphs makes it difficult to achieve flexible cross-system data exchange while ensuring security. Summary of the Invention

[0004] This invention provides a method for cross-system form intent generation and collaborative interaction based on intelligent agents, which can solve the problems in the prior art.

[0005] A first aspect of this invention provides a method for cross-system form intent generation and collaborative interaction based on intelligent agents, comprising:

[0006] A second aspect of this invention provides a cross-system form intent generation and collaborative interaction system based on intelligent agents, comprising:

[0007] The semantic understanding module is used to map the user's natural language expression to a predefined intent semantic knowledge base through semantic parsing, generate a standard intent representation, perform topology path verification in the business entity relationship graph based on the standard intent representation, determine the target form entity and target system entity by combining the form transfer mode, and extract historical filled data as a pre-filled data source.

[0008] The form construction module is used to obtain the interface meta-information of the target system entity, construct structured field knowledge, generate an intelligent agent by combining the structured field knowledge with the standard intent representation input form, establish field-control mapping through knowledge reasoning, derive cascading validation rules, and generate form configuration.

[0009] The interface rendering module is used to render the form interface based on the form configuration, inject the pre-filled data source into the form field through semantic alignment, and perform real-time validation to obtain complete form data.

[0010] The data interaction module is used to construct a trust chain proof and verify identity based on the business entity relationship graph, determine the scope of operation authorization through the permission reasoning model, and generate a security token; based on the structured field knowledge, it performs a schema conversion on the complete form data and calls the target system interface with the security token.

[0011] A third aspect of the present invention provides an electronic device, comprising:

[0012] processor;

[0013] Memory used to store processor-executable instructions;

[0014] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0016] In this embodiment of the invention, by mapping user natural language expressions to standard intent representations and combining them with business entity relationship graphs for topology path verification, precise alignment between intent and business processes is achieved, significantly improving the accuracy and relevance of form generation and solving the technical problem that traditional form systems cannot understand the user's true intent. Based on the knowledge reasoning capabilities of the form generation intelligent agent, field-control mappings are automatically established and cascading verification rules are derived, making the form configuration process intelligent, significantly reducing development costs and improving form generation efficiency. By using business entity relationship graphs to construct trust chain proofs and combining them with permission reasoning models, refined secure access control is achieved, solving the authentication and authorization problems in cross-system interactions and improving the security of data exchange. Data pattern conversion based on structured field knowledge ensures the consistency and compatibility of data formats between different systems, overcoming the technical barriers to data exchange between heterogeneous systems. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the cross-system form intent generation and collaborative interaction method based on intelligent agents according to an embodiment of the present invention;

[0018] Figure 2 A schematic diagram of the process for generating intelligent agent form configurations. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

[0020] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0021] Figure 1 This is a flowchart illustrating the cross-system form intent generation and collaborative interaction method based on intelligent agents according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0022] Semantic parsing maps user natural language expressions to a predefined intent semantic knowledge base to generate standard intent representations. Based on these standard intent representations, topology path verification is performed in the business entity relationship graph. Combined with form transfer patterns, target form entities and target system entities are determined, and historical filled data is extracted as a pre-filled data source.

[0023] Obtain the interface meta-information of the target system entity, construct structured field knowledge, generate an intelligent agent by combining the structured field knowledge with the standard intent representation input form, establish field-control mapping through knowledge reasoning, derive cascading validation rules, and generate form configuration;

[0024] The form interface is rendered based on the form configuration, the pre-filled data source is injected into the form field through semantic alignment, and real-time validation is performed to obtain complete form data.

[0025] A trust chain is constructed based on the business entity relationship graph to prove and verify identity. The scope of operation authorization is determined through the permission reasoning model, and a security token is generated. Based on the structured field knowledge, the complete form data is transformed into a schema, and the security token is used to call the target system interface.

[0026] In one optional implementation, semantic parsing maps the user's natural language expression to a predefined intent semantic knowledge base to generate a standard intent representation, including:

[0027] Semantic encoding is performed on the user's natural language expression to obtain the query semantic representation. At the same time, semantic encoding is performed on each intent template in the predefined intent semantic knowledge base to obtain the template semantic representation set. The semantic distance between the query semantic representation and each template semantic representation is calculated, and the initial intent templates with a semantic distance less than a preset distance threshold are selected.

[0028] The system performs dependency parsing on the user's natural language expression, extracts the core entities and corresponding dependency chains, obtains the corresponding entity types and inter-entity relationship constraints pre-annotated for each preliminary intent template, filters the types of the core entities to correspond to the entity types of each preliminary intent template, and ensures that the dependency chains satisfy the inter-entity relationship constraints of each preliminary intent template, thereby determining the matching intent template.

[0029] Extract the modifying semantic components from the user's natural language expression, excluding the core entity and its corresponding dependency chain, obtain the parameter slot structure defined in the matching intent template, the parameter slot structure contains the semantic type label of each parameter slot, match the modifying semantic components with the semantic type label of each parameter slot according to the semantic type, and fill them into the corresponding parameter slots to generate a standard intent representation.

[0030] In one specific implementation, the user's natural language expression is processed by a semantic encoder, converting the text into a query semantic representation in a high-dimensional vector space. The semantic encoder employs a pre-trained language model, such as a Transformer-based encoder, which receives the user's input natural language text, processes it through multiple layers of self-attention mechanisms and feedforward neural networks, and outputs a fixed-dimensional semantic vector. Specifically, the user's input text "I want to query sales data for the past three months and categorize it by region" will form a 768-dimensional vector representation after processing by the semantic encoder.

[0031] Simultaneously, each intent template in the predefined intent semantic knowledge base is encoded using the same semantic encoder to obtain a set of template semantic representations. The intent semantic knowledge base stores various predefined intent templates, such as "data query," "data analysis," and "form generation," each with a corresponding natural language description. For example, the "data query" template has multiple expressions such as "query XX data" and "obtain XX information." These template expressions, after being processed by the semantic encoder, also form 768-dimensional vector representations.

[0032] The semantic distance between the query semantic representation and the semantic representations of each template is calculated, using cosine similarity as the distance metric. Cosine similarity is calculated as the cosine of the angle between two vectors; a larger value indicates that the two vectors are closer in direction and more semantically similar. A preset distance threshold of 0.85 is set, and initial intent templates with a semantic distance less than this threshold are selected. In the example above, the two initial intent templates "data query" and "data analysis" are selected, with cosine similarities of 0.92 and 0.88 respectively with the user query.

[0033] Dependency relations are parsed from user natural language expressions, and a dependency syntax tree is constructed using natural language processing tools. During dependency relation parsing, lexical analysis is performed, including word segmentation and part-of-speech tagging; syntactic dependency relations between words are constructed, identifying the core predicate and the relationships between sentence components. Core entities and corresponding dependency relation chains are extracted from the dependency syntax tree. Taking "I want to query sales data for the past three months and categorize it by region" as an example, the core entities include "sales data" and "region," and the dependency relation chain includes "query → sales data" and "categorize → by → region."

[0034] Retrieve the pre-annotated entity types and inter-entity relationship constraints for each initially selected intent template. Each intent template is pre-annotated with the required entity types and the necessary relationship constraints between these entities. For example, the "Data Query" template requires the inclusion of the "Data Type" entity and the dependency relationship "Query Action → Data Type"; the "Data Analysis" template requires the inclusion of the "Data Type" and "Analysis Dimension" entities, and the dependency relationship "Analysis Action → Data Type" and "Category / Grouping → Analysis Dimension".

[0035] The process involves filtering the core entity types to determine if they correspond to the entity types of each initially selected intent template, and checking if the dependency chains satisfy the entity relationship constraints of each initially selected intent template, thereby determining the matching intent template. In the example above, "Sales Data" is identified as a "Data Type" entity, "Region" is identified as an "Analysis Dimension" entity, and the dependency chain satisfies the constraints of the "Data Analysis" template; therefore, "Data Analysis" is determined as the matching intent template.

[0036] Extract the modifying semantic components from the user's natural language expression, excluding the core entity and its corresponding dependency chain. In the example above, "the last three months" is a time range modifier and does not belong to the core entity or dependency chain.

[0037] Retrieve the parameter slot structure defined in the matching intent template, including the semantic type annotation of each parameter slot. The "Data Analysis" template defines parameter slots such as "Data Type", "Time Range", and "Analysis Dimension", which are used to fill in the data object, time limit, and analysis perspective of the analysis, respectively.

[0038] The semantic modifiers are matched with the semantic type labels of each parameter slot according to their semantic type, and then populated into the corresponding parameter slots. Through semantic type matching, "last three months" is identified as a time range type and matched into the "time range" slot; "sales data" is matched into the "data type" slot; and "region" is matched into the "analysis dimension" slot.

[0039] The final standard intent representation is generated, including the intent type and the populated parameter slots. For the example above, the generated standard intent representation is: Intent Type="Data Analysis", Parameter Slots={"Data Type":"Sales Data", "Time Range":"Last Three Months", "Analysis Dimension":"Region"}. This standard intent representation is used for subsequent cross-system form generation and collaborative interaction processing.

[0040] The intent template library needs continuous expansion and optimization. By collecting common user queries and operation needs, corresponding intent templates are constructed, and the required entity types and relationship constraints are labeled. Simultaneously, machine learning methods are used to automatically discover new intent templates and entity relationship patterns from historical interaction data, continuously enriching the intent semantic knowledge base. As the intent template library expands, the types of user intents processed will also increase accordingly, improving the system's intent recognition capabilities and user experience.

[0041] In one optional implementation, performing topology path verification in the business entity relationship graph based on the standard intent representation, determining the target form entity and target system entity by combining the form transfer pattern, and extracting historical filled data as a pre-filled data source includes:

[0042] Extract business entity identifiers from standard intent representations, locate the corresponding node in the business entity relationship graph as the starting point, and traverse along the associated edges to obtain form nodes;

[0043] Read the dependency path structure defined for each form node, perform a topological comparison between the actual path from the starting point to each form node in the business entity relationship graph and the dependency path structure, retain the form nodes whose node sequence and edge sequence of the actual path are consistent with the dependency path structure, and determine the candidate form nodes.

[0044] Extract historical form operation records, identify consecutively operated form pairs, count the number of transitions for each form pair, construct a form transition network, find the transition paths and transition counts pointing to each candidate form node in the form transition network, select the candidate form node corresponding to the transition path with the most transition counts, and determine the target form entity;

[0045] Extract the system nodes connected to the target form entity as the target system entity;

[0046] Retrieve the data entered during the most recent operation of the transfer path with the most transfers from the historical form operation records, and extract it as a pre-filled data source.

[0047] In one specific implementation, business entity identifiers are extracted from standard intent representations. Standard intent representations typically contain semantic information such as user intent, the object of operation, and limiting conditions. By parsing this information, the business entity that the user wishes to operate on is identified. For example, when a user expresses the intent to "view customer A's purchase order," "customer A" is extracted as the business entity identifier through semantic analysis. The extraction process employs named entity recognition technology to identify the business entity name, number, or other unique identifier in the standard intent representation text.

[0048] After obtaining the business entity identifier, the corresponding node is located in the business entity relationship graph as the starting point. The business entity relationship graph is a multi-level network structure containing different types of nodes, such as business entity nodes, form nodes, and system nodes, as well as various relationships between them. The location process is implemented through the indexing mechanism of the graph database, quickly locating the corresponding node based on the business entity identifier. For example, the customer entity node identified as "Customer A" is found as the starting point.

[0049] The form nodes are obtained by traversing along the associated edges from the starting node, using a graph traversal algorithm such as breadth-first search or depth-first search to explore related nodes in the graph. During the traversal, the nodes and edges visited are recorded, with particular attention paid to nodes of form type. For example, starting from the customer entity node, form nodes such as "Customer Information Table," "Purchase Order Table," and "Contract Approval Table" will be found.

[0050] Read the dependency path structure defined for each form node. Each form node predefines the standard dependency path between itself and the business entity, describing the sequence of nodes and edge types that should be traversed from the business entity to the form. These dependency path structures are usually stored in the properties of the form nodes and can be read directly. For example, the dependency path for "Purchase Order Table" is defined as "Customer Entity → Customer Relationship → Order Management → Purchase Order Table".

[0051] The actual paths from the starting point to each form node in the business entity relationship graph are topologically compared with the dependent path structure. Topological comparison is a structure matching algorithm that compares whether the node sequences and edge sequences of two paths are consistent. During the comparison, it checks whether the node types, node attributes, edge types, and edge attributes on the actual paths match the definitions in the dependent path structure. Only form nodes that completely match are retained as candidate form nodes.

[0052] Extract historical form operation records to identify consecutively operated form pairs. Historical operation records contain user operation information for different forms at different points in time, including operation time, user, form identifier, and entered data. Through time-series analysis, identify form pairs that the user operates on consecutively within a short period. For example, if a user first operates on the "Customer Information Form" and then operates on the "Purchase Order Form" within a certain time window, these two forms constitute a consecutively operated form pair.

[0053] The number of transitions between each form pair is counted to construct a form transition network. The form transition network is a directed weighted graph where nodes represent forms, edges represent transitions from one form to another, and the weight of each edge represents the number of transitions. The weight of each transition relationship is obtained by accumulating the frequency of each form pair in historical records. For example, the transition from the "Customer Information Form" to the "Purchase Order Form" occurred 50 times, while the transition from the "Customer Information Form" to the "Contract Approval Form" only occurred 10 times.

[0054] In the form transition network, find the transition paths and their counts pointing to each candidate form node. For each candidate form node, find all edges pointing to it in the form transition network and record the source node and weight of these edges. Select the candidate form node corresponding to the transition path with the most transition counts and determine it as the target form entity. For example, if "Customer Information Table → Purchase Order Table" has the most transition counts, then "Purchase Order Table" is determined as the target form entity.

[0055] Extract the system nodes connected to the target form entity as the target system entity. In the business entity relationship graph, form nodes are usually connected to system nodes that perform related business functions. By querying the relationships in the graph, find the system nodes directly connected to the target form entity. For example, if the "Purchase Order Form" is connected to the "Purchase Management System" node, that node is identified as the target system entity.

[0056] Retrieve the most frequently transferred data from the historical form operation records for the most recent operation of the transfer path. Specifically, find the most recent form transfer path in the history, such as the most recent operation from "Customer Information Table" to "Purchase Order Table", and extract the form data filled in by the user in that operation as a pre-populated data source, including the text entered by the user, the selected options, the uploaded files, and other form element values.

[0057] The method in this embodiment automates the entire process from user intent to pre-filled form data, significantly improving form operation efficiency and user experience.

[0058] In one optional implementation, obtaining the interface metadata of the target system entity and constructing structured field knowledge includes:

[0059] The system detects whether the target system entity supports the unified interface abstraction protocol. When the detection result is that it supports it, it sends a metadata query request corresponding to the protocol to the target system entity, receives the interface description data returned by the target system entity, and extracts the field identifier, field type and field constraint rules from the interface description data to obtain the interface metadata.

[0060] When the detection result is not supported, the interface specification document corresponding to the target system entity is obtained, the interface specification document is segmented into text, the paragraphs describing interface parameters in each text segment are identified, the text descriptions of parameter names, parameter data types and parameter value constraints are extracted from the paragraphs, the parameter names are mapped to field identifiers, the parameter data types are mapped to field types, the text descriptions of parameter value constraints are converted into field constraint rules, and the interface metadata is determined.

[0061] The field identifiers, field types, and field constraint rules in the interface metadata are organized in a structured manner, and a mapping relationship between field identifiers and field types and field constraint rules is established to generate structured field knowledge.

[0062] In one specific implementation, the process of obtaining the interface metadata of the target system entity and constructing structured field knowledge first requires determining whether the target system supports the Unified Interface Abstraction Protocol (UIAP). Specifically, this is done by sending a predefined probe request to the target system, which includes a specific protocol identifier field. If the target system responds correctly and returns response data containing protocol version information, it is determined that the UIAP supports the Unified Interface Abstraction Protocol; if it returns an error code or times out without a response, it is determined that the system does not support it.

[0063] When the target system supports the unified interface abstraction protocol, a metadata query request is constructed. This request follows the format specified by the protocol, containing a request header and a request body. The request header sets the Content-Type to "application / json" and adds authentication information such as the Authorization field. The request body sets the query type to "metadata" and specifies the entity identifier to be queried. The constructed query request is then sent to the target system's metadata interface endpoint, such as " / api / v1 / metadata", via the HTTP POST method.

[0064] After receiving the interface description data returned by the target system, the system parses and processes the data. The returned data is typically in JSON or XML format and contains a list of field definitions. The system iterates through the field definition list, extracting the field identifier (usually the name or fieldId attribute), field type (usually the dataType or type attribute), and field constraint rules (contained in the constraints or rules attributes) from each record. Field constraint rules include non-null constraints, length limits, value ranges, regular expression patterns, etc. The extracted information is then organized into a unified interface metadata structure.

[0065] When the target system does not support a unified interface abstraction protocol, the corresponding interface specification document must be obtained. The interface specification document exists in formats such as HTML, PDF, Word, or Markdown. The appropriate parser is selected based on the format to load the document content. For HTML documents, a DOM parser is used to extract the text content; for PDF documents, a PDF parsing library is used to extract the text; for Word documents, a relevant library is used to convert the document to plain text format.

[0066] After acquiring the document content, text segmentation is performed, dividing the document into multiple chapters based on document structural features such as headings and paragraph separators. Each chapter is then further divided into paragraph units. Natural language processing techniques are applied to each paragraph to identify semantic categories. Special attention is paid to paragraphs containing keywords such as "parameters," "fields," "request body," and "response," as well as structured content such as tables and lists, which typically contain API parameter descriptions.

[0067] Extract key information from the identified parameter description paragraphs. Use named entity recognition technology to identify parameter names in the paragraphs; parameter names are typically presented in a specific format, such as bold or code style. Identify parameter data types; common types include string, integer, boolean, array, and object. Identify textual descriptions of parameter value constraints, such as "cannot be empty," "length not exceeding 20 characters," and "value range 1-100."

[0068] The extracted text information is standardized and converted into structured data. Parameter names are directly mapped to field identifiers. The text descriptions of parameter data types are converted into standard type representations, such as "string" mapping to "string", "integer" mapping to "integer", etc. The text descriptions of parameter value constraints are converted into structured field constraint rules, such as "cannot be empty" to "required: true", "length not exceeding 20 characters" to "maxLength: 20". Through these conversion steps, interface metadata in a unified format is formed.

[0069] Finally, the field identifiers, field types, and field constraint rules in the interface metadata are organized into a structured format. A mapping table or object is created, using the field identifier as the key and the corresponding field type and constraint rule as the value. Field constraint rules include multiple attributes, such as required fields, length limits, value ranges, and format requirements. For complex field types, such as objects or arrays, the internal structure needs to be processed recursively. The generated structured field knowledge is represented in JSON or XML format for easy processing and application by subsequent systems.

[0070] For example, the method of this embodiment obtains the metadata of the order creation interface. When the unified interface abstraction protocol is not supported, information is extracted from the API documentation. Through document analysis, the type of the field "orderAmount" is identified as "decimal", with the constraints "required, precision to two decimal places, value range 0.01-99999999.99". This information is converted into a structured representation: {"fieldId": "orderAmount", "type": "decimal", "constraints":{"required": true, "precision": 2, "min": 0.01, "max": 9999999.99}}. The resulting structured field knowledge is used in various application scenarios such as interface call parameter verification, test case generation, and automated documentation updates, significantly improving the efficiency of inter-system integration.

[0071] In one optional implementation, the structured field knowledge is used to generate an intelligent agent based on the standard intent representation input form. A field-control mapping is established through knowledge reasoning, cascading validation rules are derived, and the generated form configuration includes:

[0072] The agent extracts field validation rules from structured field knowledge, parses the field validation rules to construct an abstract syntax tree, calculates the tree depth and number of branches of the abstract syntax tree, queries the depth threshold and branch threshold corresponding to each control type in the control feature library, filters target control types with a depth threshold greater than the tree depth and a branch threshold greater than the number of branches, extracts the business type identifier of the corresponding field from the standard intent representation, prioritizes the target control types, and selects the target control type with the highest priority to establish a field-control mapping with the field.

[0073] The agent extracts field names from the leaf nodes of the abstract syntax tree, constructs a field dependency graph, calculates the number of incoming edges for each field node in the field dependency graph, puts field nodes with zero incoming edges into the processing queue and marks them as the first level, retrieves field nodes from the processing queue and their corresponding outgoing edges, updates the number of incoming edges for subsequent field nodes, puts subsequent field nodes with zero incoming edges into the processing queue and marks them as the next level, extracts the preceding and subsequent controls of adjacent levels from the field-control mapping, constructs a propagation path set, identifies common preceding controls and configures a batch trigger list, sets the verification execution priority according to the level to which the subsequent control belongs, and generates cascading verification rules.

[0074] The field-control mapping and the cascading validation rules are encapsulated to generate form configuration.

[0075] In one specific implementation, in the agent-based cross-system form intent generation and collaborative interaction method, the agent analyzes structured field knowledge and standard intent representations to generate the most suitable control type for the form and construct cascading validation rules. The agent extracts field validation rules from the structured field knowledge; these rules describe constraints such as the data type, value range, and format requirements of the fields. Taking the "Order Amount" field in a sales order form as an example, the validation rule is "Type=Number AND Greater than=0 AND Less than=1000000 AND Decimal Places=2", indicating that the order amount must be a positive number, not exceeding one million, and accurate to two decimal places.

[0076] When constructing an abstract syntax tree (AST) for parsing field validation rules, the agent transforms the validation rules into a tree structure. The root node of the AST is typically a logical operator (such as AND or OR), and the child nodes are specific constraints or nested logical operations. For the validation rule of "order amount", the root node of the constructed AST is the AND operator, followed by four child nodes: "type=numeric", "greater than=0", "less than=1000000", and "decimal places=2".

[0077] Calculating the depth and number of branches of the abstract syntax tree (Abstract Syntax Tree) is a key indicator for selecting the appropriate control type. Tree depth is the path length from the root node to the farthest leaf node, reflecting the complexity and nesting of validation rules. The number of branches is the number of branch nodes in the Abstract Syntax Tree, reflecting the number of constraints in the validation rules. For the "Order Amount" field, the depth of the Abstract Syntax Tree is 2 (the path length from the root node ANDed to the leaf node "Type=Number"), and the number of branches is 4 (four validation conditions).

[0078] The intelligent agent queries the control feature library for the depth and branch thresholds corresponding to each control type. The control feature library stores the rule complexity range applicable to different control types. For example, the depth threshold of a numeric input box control is 3 and the branch threshold is 5, indicating that this control is suitable for handling validation rules with a tree depth of no more than 3 and a branch number of no more than 5; the depth threshold of a slider control is 2 and the branch threshold is 3, indicating that it is suitable for handling relatively simple numerical range validation rules; the depth threshold of a drop-down selection control is 2 and the branch threshold is 10, indicating that it is suitable for handling validation rules with many options but simple logical structures.

[0079] The filter selects target control types with a depth threshold greater than the tree depth and a branch threshold greater than the number of branches, ensuring the controls can support the complexity of the validation rules. For the "Order Amount" field, the tree depth is 2 and the number of branches is 4. The matching control types include numeric input boxes (numeric input box depth threshold 3 is greater than tree depth 2, and numeric input box branch threshold 5 is greater than the number of branches 4). However, slider controls (slider bar depth threshold 2 is equal to tree depth 2, but slider bar branch threshold 3 is less than the number of branches 4) do not meet the filtering criteria. Therefore, numeric input boxes are initially selected as the target control type.

[0080] The business type identifier for the corresponding field is extracted from the standard intent representation to further optimize control selection. The business type identifier is contained in the parameter slot of the standard intent representation, indicating the use case and semantics of the field in the business context. For example, the business type identifier for the "order amount" field is "amount_exact input", indicating that this is a currency amount that needs to be entered precisely.

[0081] The target control types are prioritized based on a compatibility score between the business type identifier and the control type. The control feature library defines a compatibility score table for each control type against different business type identifiers. For example, a numeric input box scores 9.5 points for "Amount_Exact Input," a slider scores 5.0 points, and a dropdown selection scores 3.0 points. Based on these scores, the selected target control types are sorted, and the highest-priority target control type is used to establish a field-control mapping with the field. In the "Order Amount" example, the numeric input box has the highest compatibility score; therefore, it is selected as the final control type, and a "Order Amount - Numeric Input Box" field-control mapping is established.

[0082] The agent extracts field names from the leaf nodes of the abstract syntax tree to construct a field dependency graph. Leaf nodes typically contain references to specific fields, reflecting the dependencies between them. For example, the validation rule for the "Customer Discount Rate" field includes "IF Customer Type='VIP' THEN Greater than=0.1 AND Less than=0.3 ELSE Greater than=0 AND Less than=0.1", from which we can extract that "Customer Discount Rate" depends on the "Customer Type" field.

[0083] When constructing a field dependency graph, each field is treated as a node in the graph. If the validation rule for field A references field B, a directed edge is added from B to A, indicating that A depends on B. For example, adding a directed edge from the "Customer Type" node to the "Customer Discount Rate" node indicates that the validation of "Customer Discount Rate" depends on the value of "Customer Type".

[0084] Calculate the number of incoming edges for each field node in the field dependency graph. The number of incoming edges represents the number of other fields that the field depends on. Field nodes with zero incoming edges do not depend on any other fields and are validated independently. In the sales order form, fields such as "Order Number," "Customer Type," and "Order Date" do not depend on other fields and have zero incoming edges.

[0085] Field nodes with zero incoming edges are added to the processing queue and marked as first-level; these fields are validated first. Field nodes are retrieved from the processing queue, their corresponding outgoing edges are processed, and the incoming edge count of subsequent field nodes is updated. If the incoming edge count of a subsequent field node is updated to zero, it indicates that all dependent fields have been processed and validated, and the node is added to the processing queue and marked as the next level. For example, after processing the "Customer Type" node, if the incoming edge count of the "Customer Discount Rate" node becomes zero, then the "Customer Discount Rate" node is added to the processing queue and marked as second-level.

[0086] Extract the preceding and succeeding controls from adjacent levels of the field-control mapping to construct a set of propagation paths. The preceding control is the control corresponding to the field at the previous level, and the succeeding control is the control corresponding to the field at the next level. Based on the hierarchical structure of the field dependency graph and the field-control mapping, determine the propagation path of the validation rule. For example, if the "Customer Type" field maps to a dropdown selection control and the "Customer Discount Rate" field maps to a numeric input box control, then construct a propagation path from the dropdown selection control to the numeric input box control.

[0087] Identify common preceding controls and configure a batch trigger list to improve validation efficiency. If multiple subsequent controls depend on the same preceding control, configure a batch trigger mechanism so that when the value of the preceding control changes, the validation of all subsequent controls that depend on it is triggered at once. For example, if both "Order Total" and "Amount Payable" depend on "Customer Discount Rate", configure the validation of both the "Order Total" and "Amount Payable" controls to be triggered simultaneously when the value of the "Customer Discount Rate" control changes.

[0088] Set validation execution priority based on the hierarchy of subsequent controls to ensure validation is performed in dependency order. Higher-level fields (fewer dependent fields) have higher validation priority, and lower-level fields (more dependent fields) have lower validation priority. Ensure that when validating a field, all dependent fields have already been validated. For example, the first-level "Customer Type" has a higher validation priority than the second-level "Customer Discount Rate," and the second-level "Customer Discount Rate" has a higher validation priority than the third-level "Amount Payable."

[0089] Generate cascading validation rules, including triggering conditions, validation order, and error handling mechanisms. Cascading validation rules describe how validation of related controls is triggered when the value of a control in a form changes, and how to handle validation failures. For example, when the value of the "Customer Type" dropdown selection control changes, validation of the "Customer Discount Rate" numeric input box is triggered; if validation fails, an error message is displayed, and subsequent controls dependent on "Customer Discount Rate" are disabled.

[0090] The field-control mapping and cascading validation rules are encapsulated into a form configuration. This form configuration is a structured description containing a list of form fields, the control type for each field, control attributes, validation rules, and cascading validation relationships. The form configuration is parsed by the form rendering engine to dynamically generate the final form interface and interaction logic. In this way, the intelligent agent achieves automatic selection of form controls and generation of cascading validation rules based on field validation rules, improving the user experience and data quality of the form.

[0091] like Figure 2 The diagram shown illustrates the process of generating intelligent agent form configurations.

[0092] In one optional implementation, the preceding and subsequent controls of adjacent levels are extracted from the field-control mapping, a propagation path set is constructed, common preceding controls are identified and a batch trigger list is configured, the validation execution priority is set according to the level to which the subsequent controls belong, and cascading validation rules are generated, including:

[0093] Based on the level to which each field node belongs in the field dependency graph, a propagation path set is constructed. Starting from the field node of the first level, the propagation path is traversed along the outgoing edges to the field node of the next level, and the sequence of traversed field nodes is recorded as the propagation path.

[0094] Identify multiple propagation paths originating from the same preceding level field node, determine the controls corresponding to the same preceding level field node as common preceding controls, extract the subsequent controls corresponding to the terminating field nodes of multiple propagation paths, configure a batch trigger list for the value change event of the common preceding control, the batch trigger list contains the verification trigger interface of each subsequent control, and generate a batch cascading rule that triggers the verification of multiple subsequent controls by a single value change event.

[0095] Extract the level of the field node corresponding to each subsequent control in the batch trigger list, and set the verification execution priority for each subsequent control according to the level, wherein the level of the subsequent control is proportional to the verification execution priority;

[0096] The batch cascading rules and the verification execution priority are encapsulated to generate the final cascading verification rules.

[0097] In one specific implementation, a depth-first search algorithm is used to traverse the field dependency graph. For the dependency graph G=(V,E), where V represents the set of all field nodes and E represents the set of dependency edges between nodes, each node v∈V has an attribute level indicating its level. Starting from all nodes with level=1, the nodes of the next level are obtained by traversing the edges, and the traversal path is recorded as the propagation path.

[0098] For example, for a form containing fields A, B, C, D, and E, assume the hierarchical relationship is: A belongs to the first level, B and C belong to the second level, and D and E belong to the third level. The dependency relationships are: A→B, A→C, B→D, C→E. By traversing these paths, we obtain the set of propagation paths: {[A,B,D], [A,C,E]}.

[0099] Identify multiple propagation paths originating from the same preceding level field node and designate the control corresponding to that node as the common preceding control. In the example above, A is the starting node of two propagation paths, therefore the control corresponding to A is designated as the common preceding control.

[0100] Extract the subsequent controls corresponding to the terminating field nodes of multiple propagation paths. In the example, D and E are the terminating nodes of two propagation paths, and their corresponding controls are used as subsequent controls.

[0101] Configure a batch trigger list for value change events of common preceding controls. This list contains the validation trigger interfaces for each subsequent control. In the specific implementation, create a mapping table where the key is the unique identifier of the common preceding control, and the value is an array containing the validation trigger interfaces of subsequent controls.

[0102] The validation trigger interface of a form control typically includes: the method name that triggers the validation, the target control identifier, and validation parameters. In the example above, the batch trigger list for control A is represented as: {controlId: "A", triggers:[{targetId: "D", validateMethod: "validate", params: {...}}, {targetId: "E", validateMethod: "validate", params: {...}}]}.

[0103] The generated batch cascading rules enable the system to trigger the validation logic of both controls D and E in a single event handling when the value of the common preceding control A changes, thus improving validation efficiency.

[0104] To handle the validation order issue under complex dependencies, it is necessary to extract the hierarchy of the field nodes corresponding to each subsequent control in the batch trigger list, and set the validation execution priority for each subsequent control based on its hierarchy. The hierarchy of a subsequent control is directly proportional to its validation execution priority; that is, the higher the hierarchy of the control, the higher its validation execution priority.

[0105] In the example, D and E both belong to the third level, so their verification execution priority is the same. If there is a level difference, for example, D belongs to the third level while E belongs to the fourth level, then E's verification execution priority is higher than D's.

[0106] The execution priority of validation is represented by a numerical value, such as using integers 1-10 to represent priority levels, with larger numbers indicating higher priority. For controls at the same level, the priority is further refined based on other factors (such as control type, business importance, etc.).

[0107] The batch cascading rules and validation execution priorities are encapsulated to generate the final cascading validation rules. During the encapsulation process, the batch cascading rule object and the priority configuration are merged to form a rule object containing complete validation logic and execution order.

[0108] The generated cascading validation rules are represented in JSON format: {sourceControl: "A", targetControls:[{id: "D", level: 3, priority: 3, validateMethod: "validate"}, {id: "E",level: 3, priority: 3, validateMethod: "validate"}], eventType: "change"}.

[0109] In practical applications, these cascading validation rules are loaded into the form processing engine for execution. When a user modifies the value of control A in the form interface, the change event is triggered. The form processing engine identifies the two controls D and E that need to be validated according to the cascading validation rules, and executes the validation logic in the set priority order.

[0110] This hierarchical analysis-based cascading validation rule generation method enables efficient management of multi-level dependencies in complex forms, improves the response speed of form interactions and user experience, and reduces the workload of developers manually configuring cascading validation rules.

[0111] In one optional implementation, a trust chain proof is constructed based on the business entity relationship graph to verify identity, the scope of operation authorization is determined through a permission reasoning model, and a security token is generated, including:

[0112] Extract the authentication dependency path of the target system entity from the business entity relationship graph, collect the trust credentials of each associated system entity along the authentication dependency path, combine the trust credentials with user credential information to construct a trust chain proof, initiate cross-domain authentication to the target system entity, receive the authentication response and parse to obtain the user identity attribute set;

[0113] The standard intent representation and the semantic features of the fields in the complete form data are input into the permission reasoning model. The permission reasoning model is learned based on the operation history trajectory in the business entity relationship graph. The reasoning output is the minimum permission set that matches the user identity attribute set to determine the scope of operation authorization.

[0114] A data digest is generated from the complete form data. The data digest, the hash value of the trust chain proof, and the operation authorization scope are encapsulated into a token payload. The token payload is then signed to generate a security token.

[0115] In one specific implementation, the authentication dependency path of the target system entity is extracted from the business entity relationship graph. The business entity relationship graph stores the trust relationships and authentication dependencies between various business system entities, represented by a directed weighted graph structure, where nodes represent system entities, edges represent trust relationships, and edge weights represent trust strength. To extract the authentication dependency path, Dijkstra's algorithm is used to calculate the optimal authentication path from the user's current system entity to the target system entity. The optimization function considers a weighted combination of path length, trust strength, and historical authentication success rate.

[0116] Trust credentials for each associated system entity are collected along the authentication dependency path. Each system entity node on the path is accessed sequentially, and a trust credential is requested and obtained through a pre-defined credential exchange protocol. Each system entity generates an XML-formatted trust credential containing user identity assertions, timestamps, validity periods, and digital signatures according to its local authentication policy. Credential exchange uses a two-way TLS encrypted channel to ensure transmission security.

[0117] Trust certificates are combined with user credentials to construct a trust chain proof. A chain structure is used to connect the collected trust certificates of various system entities in the order of the authentication path, establishing reference relationships between each certificate node. Hash pointer technology ensures the integrity of the trust chain; each certificate node contains the hash value of the previous node, forming a blockchain-like structure. A complete trust chain proof includes the user's initial credentials (such as username / password hashes or biometric data), the intermediate system entity certificate chain, and a metadata header (containing information such as proof creation time, validity period, and version number).

[0118] Initiate cross-domain authentication to the target system entity. Construct an authentication request message, including a trust chain proof, user context information, and a description of the access intent, encapsulated in JSON Web Token format. The authentication request is sent to the target system's authentication service through a secure channel, and includes an authentication type identifier, a session identifier, and a replay-protected random number.

[0119] The system receives the authentication response and parses it to obtain the user identity attribute set. Upon receiving the authentication request, the target system first verifies the integrity of the trust chain proof, sequentially verifying the digital signature of each credential in the chain to ensure it has not been tampered with. Then, it calculates the combined trust value according to the trust transfer rules; if it exceeds a preset threshold, authentication is successful. After successful authentication, the system extracts and merges the user identity attributes from each credential, generating a unified set of user identity attributes, including basic attributes (user ID, name, role, etc.) and extended attributes (department, job level, privilege markers, etc.).

[0120] The standard intent representation and the semantic features of fields in the complete form data are input into the permission inference model. The standard intent representation is a structured description of the intent extracted from the user's action request by the intent recognition module, including the action type, the action object, and the action context. The field semantic features are key fields and semantic types extracted from the form data, which are mapped to a unified semantic space by a pre-trained semantic analysis model. The permission inference model is built on a graph neural network based on an attention mechanism, which can capture the complex relationships between different identity attributes and operation permissions.

[0121] The permission reasoning model is learned from the historical operation trajectories in the business entity relationship graph. By collecting and analyzing historical operation records stored in the graph, it extracts the association patterns between user identity attributes, operation types, and authorization decisions. The training process employs supervised learning, using historical authorization decisions as labels to minimize the discrepancy between predicted permissions and actual authorizations. The model also integrates a rule-based reasoning component to handle explicit permission policy constraints.

[0122] The inference output determines the minimum set of permissions that matches the user's identity attributes, thus defining the scope of authorized operations. The permission inference model comprehensively analyzes user identity attributes, operational intent, and data sensitivity, applying the principle of least privilege to grant only the permissions necessary to complete a specific operation. The permission set is represented in a structured form, including resource access permissions, data operation permissions, and function usage permissions, with each permission having a scope and validity period limit.

[0123] Generate a data digest from complete form data. The SHA-256 hash algorithm is used to calculate the digest value of the form data to ensure data integrity. For large form data, normalization is performed first, sorting by field names alphabetically and removing redundant whitespace characters, before calculating the digest value to ensure consistent digests for forms with the same semantics.

[0124] The data digest, the hash value of the trust chain proof, and the scope of authorization are encapsulated into a token payload. The token payload is in JSON format and includes standard fields (issuer, subject, issuance time, expiration time) and custom fields (data digest, trust chain proof hash, and scope description). To prevent token bloat, the trust chain proof is referenced using a hash digest method, and the complete trust chain is stored in the authentication service and retrieved on demand.

[0125] The token payload is signed to generate a secure token. An asymmetric key algorithm, such as ECDSA, is used to digitally sign the token payload using the token issuance service's private key, generating a JWT-compliant secure token. The final token consists of three parts: a header (specifying the algorithm and token type), a payload (containing claim information), and a signature. An appropriate expiration time is set for the token to enhance security. The generated secure token is used for subsequent authorization verification; the recipient verifies the token's authenticity and integrity using the issuance service's public key.

[0126] This invention's embodiment of a cross-system form intent generation and collaborative interaction system based on intelligent agents includes:

[0127] The semantic understanding module is used to map the user's natural language expression to a predefined intent semantic knowledge base through semantic parsing, generate a standard intent representation, perform topology path verification in the business entity relationship graph based on the standard intent representation, determine the target form entity and target system entity by combining the form transfer mode, and extract historical filled data as a pre-filled data source.

[0128] The form construction module is used to obtain the interface meta-information of the target system entity, construct structured field knowledge, generate an intelligent agent by combining the structured field knowledge with the standard intent representation input form, establish field-control mapping through knowledge reasoning, derive cascading validation rules, and generate form configuration.

[0129] The interface rendering module is used to render the form interface based on the form configuration, inject the pre-filled data source into the form field through semantic alignment, and perform real-time validation to obtain complete form data.

[0130] The data interaction module is used to construct a trust chain proof and verify identity based on the business entity relationship graph, determine the scope of operation authorization through the permission reasoning model, and generate a security token; based on the structured field knowledge, it performs a schema conversion on the complete form data and calls the target system interface with the security token.

[0131] A third aspect of the present invention provides an electronic device, comprising:

[0132] processor;

[0133] Memory used to store processor-executable instructions;

[0134] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0135] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0136] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for cross-system form intent generation and collaborative interaction based on intelligent agents, characterized in that, include: Semantic parsing maps user natural language expressions to a predefined intent semantic knowledge base to generate standard intent representations. Based on these standard intent representations, topology path verification is performed in the business entity relationship graph. Combined with form transfer patterns, target form entities and target system entities are determined, and historical filled data is extracted as a pre-filled data source. Obtain the interface metadata of the target system entity, construct structured field knowledge, generate an intelligent agent by combining the structured field knowledge with the standard intent representation input form, establish a field-control mapping through knowledge reasoning, derive cascading validation rules, and generate form configuration, including: The agent extracts field validation rules from structured field knowledge, parses the field validation rules to construct an abstract syntax tree, calculates the tree depth and number of branches of the abstract syntax tree, queries the depth threshold and branch threshold corresponding to each control type in the control feature library, filters target control types with a depth threshold greater than the tree depth and a branch threshold greater than the number of branches, extracts the business type identifier of the corresponding field from the standard intent representation, prioritizes the target control types, and selects the target control type with the highest priority to establish a field-control mapping with the field. The agent extracts field names from the leaf nodes of the abstract syntax tree, constructs a field dependency graph, calculates the number of incoming edges for each field node in the field dependency graph, puts field nodes with zero incoming edges into the processing queue and marks them as the first level, retrieves field nodes from the processing queue and their corresponding outgoing edges, updates the number of incoming edges for subsequent field nodes, puts subsequent field nodes with zero incoming edges into the processing queue and marks them as the next level, extracts the preceding and subsequent controls of adjacent levels from the field-control mapping, constructs a propagation path set, identifies common preceding controls and configures a batch trigger list, sets the verification execution priority according to the level to which the subsequent control belongs, and generates cascading verification rules. The field-control mapping and the cascading validation rules are encapsulated to generate a form configuration; The form interface is rendered based on the form configuration, the pre-filled data source is injected into the form field through semantic alignment, and real-time validation is performed to obtain complete form data. A trust chain is constructed based on the business entity relationship graph to prove and verify identity. The scope of operation authorization is determined through the permission reasoning model, and a security token is generated. Based on the structured field knowledge, the complete form data is transformed into a schema, and the security token is used to call the target system interface.

2. The method according to claim 1, characterized in that, Semantic parsing maps user natural language expressions to a predefined intent semantic knowledge base, generating standard intent representations including: Semantic encoding is performed on the user's natural language expression to obtain the query semantic representation. At the same time, semantic encoding is performed on each intent template in the predefined intent semantic knowledge base to obtain the template semantic representation set. The semantic distance between the query semantic representation and each template semantic representation is calculated, and the initial intent templates with a semantic distance less than a preset distance threshold are selected. The system performs dependency parsing on the user's natural language expression, extracts the core entities and corresponding dependency chains, obtains the corresponding entity types and inter-entity relationship constraints pre-annotated for each preliminary intent template, filters the types of the core entities to correspond to the entity types of each preliminary intent template, and ensures that the dependency chains satisfy the inter-entity relationship constraints of each preliminary intent template, thereby determining the matching intent template. Extract the modifying semantic components from the user's natural language expression, excluding the core entity and its corresponding dependency chain, obtain the parameter slot structure defined in the matching intent template, the parameter slot structure contains the semantic type label of each parameter slot, match the modifying semantic components with the semantic type label of each parameter slot according to the semantic type, and fill them into the corresponding parameter slots to generate a standard intent representation.

3. The method according to claim 1, characterized in that, Based on the aforementioned standard intent representation, topology path validation is performed in the business entity relationship graph. Combined with form transfer patterns, the target form entity and target system entity are determined. Historical filled-in data is extracted as a pre-filled data source, including: Extract business entity identifiers from standard intent representations, locate the corresponding node in the business entity relationship graph as the starting point, and traverse along the associated edges to obtain form nodes; Read the dependency path structure defined for each form node, perform a topological comparison between the actual path from the starting point to each form node in the business entity relationship graph and the dependency path structure, retain the form nodes whose node sequence and edge sequence of the actual path are consistent with the dependency path structure, and determine the candidate form nodes. Extract historical form operation records, identify consecutively operated form pairs, count the number of transitions for each form pair, construct a form transition network, find the transition paths and transition counts pointing to each candidate form node in the form transition network, select the candidate form node corresponding to the transition path with the most transition counts, and determine the target form entity; Extract the system nodes connected to the target form entity as the target system entity; Retrieve the data entered during the most recent operation of the transfer path with the most transfers from the historical form operation records, and extract it as a pre-filled data source.

4. The method according to claim 1, characterized in that, Obtaining the interface metadata of the target system entity and constructing structured field knowledge includes: The system detects whether the target system entity supports the unified interface abstraction protocol. When the detection result is that it supports it, it sends a metadata query request corresponding to the protocol to the target system entity, receives the interface description data returned by the target system entity, and extracts the field identifier, field type and field constraint rules from the interface description data to obtain the interface metadata. When the detection result is not supported, the interface specification document corresponding to the target system entity is obtained, the interface specification document is segmented into text, the paragraphs describing interface parameters in each text segment are identified, the text descriptions of parameter names, parameter data types and parameter value constraints are extracted from the paragraphs, the parameter names are mapped to field identifiers, the parameter data types are mapped to field types, the text descriptions of parameter value constraints are converted into field constraint rules, and the interface metadata is determined. The field identifiers, field types, and field constraint rules in the interface metadata are organized in a structured manner, and a mapping relationship between field identifiers and field types and field constraint rules is established to generate structured field knowledge.

5. The method according to claim 1, characterized in that, Extract the preceding and subsequent controls of adjacent levels from the field-control mapping, construct a propagation path set, identify common preceding controls and configure a batch trigger list, set the validation execution priority according to the level of the subsequent controls, and generate cascading validation rules including: Based on the level to which each field node belongs in the field dependency graph, a propagation path set is constructed. Starting from the field node of the first level, the propagation path is traversed along the outgoing edges to the field node of the next level, and the sequence of traversed field nodes is recorded as the propagation path. Identify multiple propagation paths originating from the same preceding level field node, determine the controls corresponding to the same preceding level field node as common preceding controls, extract the subsequent controls corresponding to the terminating field nodes of multiple propagation paths, configure a batch trigger list for the value change event of the common preceding control, the batch trigger list contains the verification trigger interface of each subsequent control, and generate a batch cascading rule that triggers the verification of multiple subsequent controls by a single value change event. Extract the level of the field node corresponding to each subsequent control in the batch trigger list, and set the verification execution priority for each subsequent control according to the level, wherein the level of the subsequent control is proportional to the verification execution priority; The batch cascading rules and the verification execution priority are encapsulated to generate the final cascading verification rules.

6. The method according to claim 1, characterized in that, Based on the business entity relationship graph, a trust chain is constructed to prove and verify identity. The scope of operation authorization is determined through a permission reasoning model, and a security token is generated, including: Extract the authentication dependency path of the target system entity from the business entity relationship graph, collect the trust credentials of each associated system entity along the authentication dependency path, combine the trust credentials with user credential information to construct a trust chain proof, initiate cross-domain authentication to the target system entity, receive the authentication response and parse to obtain the user identity attribute set; The standard intent representation and the semantic features of the fields in the complete form data are input into the permission reasoning model. The permission reasoning model is learned based on the operation history trajectory in the business entity relationship graph. The reasoning output is the minimum permission set that matches the user identity attribute set to determine the scope of operation authorization. A data digest is generated from the complete form data. The data digest, the hash value of the trust chain proof, and the operation authorization scope are encapsulated into a token payload. The token payload is then signed to generate a security token.

7. A cross-system form intent generation and collaborative interaction system based on intelligent agents, used to implement the method of any one of claims 1-6, characterized in that, include: The semantic understanding module is used to map the user's natural language expression to a predefined intent semantic knowledge base through semantic parsing, generate a standard intent representation, perform topology path verification in the business entity relationship graph based on the standard intent representation, determine the target form entity and target system entity by combining the form transfer mode, and extract historical filled data as a pre-filled data source. The form construction module is used to obtain the interface meta-information of the target system entity, construct structured field knowledge, generate an intelligent agent by combining the structured field knowledge with the standard intent representation input form, establish field-control mapping through knowledge reasoning, derive cascading validation rules, and generate form configuration. The interface rendering module is used to render the form interface based on the form configuration, inject the pre-filled data source into the form field through semantic alignment, and perform real-time validation to obtain complete form data. The data interaction module is used to build a trust chain proof and verify identity based on the business entity relationship graph, determine the scope of operation authorization through the permission reasoning model, and generate a security token. Based on the structured field knowledge, the complete form data is transformed into a schema, and the security token is used to call the target system interface.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images