Metadata conversion method of multi-source domain specific language and computing equipment

Abstract

The embodiment of the invention relates to the field of data conversion, and provides a multi-source domain-specific language metadata conversion method and computing device.The method comprises the steps that in response to received domain-specific language DSL data, the language type of the DSL data is obtained; based on a first grammar rule corresponding to the language type in a preset grammar rule base, analyzing a semantic structure corresponding to the DSL data; converting the semantic structure into first metadata according to the semantic structure and a preset mapping rule base; and processing the first metadata to generate second metadata conforming to a preset format. Based on the scheme, unified analysis and conversion can be carried out on the multi-source DSL data, the adaptation cost is effectively reduced, and the expansibility and compatibility of the system are improved. And through the modular design of the grammar rule base and the mapping rule base, the analysis capability of dynamically expanding the new type DSL is supported, and the adaptation cost of an external development platform is reduced.

Description

Metadata conversion methods and computing devices for multi-source domain-specific languages Technical Field

[0001] This application relates to the field of data conversion technology, and in particular to a method and computing device for converting metadata of a multi-source domain-specific language. Background Technology

[0002] An intelligent agent (Agent) is an autonomous entity capable of perceiving and taking actions in a specific environment to achieve its goals. A multi-agent system (MAS) is a computing system composed of multiple autonomous or semi-autonomous intelligent agents. Intelligent agents, and even MAS, can respond to user commands, proactively perceive the environment, understand the intent of the commands, plan task steps, and invoke tools to execute the tasks.

[0003] To accomplish complex tasks, MAS interfaces with multiple external development platforms to enhance its capabilities and development efficiency. However, the use of different domain-specific languages ​​(DSLs) by these platforms to define MAS configuration information leads to metadata heterogeneity issues, impacting inter-system collaboration efficiency. Therefore, when MAS interfaces with external development platforms, an adaptation module needs to be developed for each platform's corresponding DSL to facilitate the conversion between DSL and Agent-Architecture Description Language (ADL) metadata.

[0004] However, developing a dedicated adaptation module for each type of DSL is costly and has poor scalability. It cannot dynamically adapt to new types of DSLs, which limits the flexibility of MAS in connecting to external tools. Furthermore, the semantic mapping between multi-source DSLs and Agent-ADL metadata is inaccurate, which can easily lead to information loss or format errors. Summary of the Invention

[0005] This application provides a method and computing device for metadata conversion of multi-source domain-specific languages, which can be compatible with the data conversion process of different kinds of domain-specific languages, realize unified parsing and metadata conversion of multi-source DSLs, reduce adaptation costs and improve system scalability.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, the embodiments of this application provide a method for converting metadata of a multi-source domain-specific language (DSL). The method includes: in response to receiving domain-specific language (DSL) data, obtaining the language type of the DSL data; parsing the semantic structure corresponding to the DSL data based on a first grammar rule corresponding to the language type in a preset grammar rule library; converting the semantic structure into first metadata according to the semantic structure and a preset mapping rule library; and processing the first metadata to generate second metadata that conforms to a preset format.

[0007] Based on this solution, unified parsing and conversion of multi-source DSL data can be achieved, effectively reducing adaptation costs and improving system scalability and compatibility. Through the modular design of the syntax rule base and mapping rule base, the parsing capability for new types of DSLs can be dynamically expanded, avoiding redundant development and reducing adaptation costs for external development platforms.

[0008] In one possible implementation, the DSL data is parsed to obtain the semantic structure corresponding to the DSL data, including: obtaining the abstract syntax tree corresponding to the DSL data based on the first syntax rule; traversing and semantically analyzing the abstract syntax tree to obtain semantic information and relationships; and constructing the semantic structure based on the semantic information and relationships.

[0009] Based on this scheme, by constructing an abstract syntax tree and performing semantic analysis, the structured semantic information of DSL data can be accurately extracted, enhancing the ability to resolve semantic differences between multi-source DSLs and effectively reducing the risk of information loss due to semantic mapping deviations.

[0010] In another possible implementation, based on the first syntax rule, the abstract syntax tree corresponding to the DSL data is obtained, including: parsing the DSL data into a string sequence; deserializing the string sequence to obtain a field mapping structure; and converting the field mapping structure into an abstract syntax tree based on the first syntax rule.

[0011] Based on this solution, efficient structured parsing of DSL data can be achieved, improving the accuracy and maintainability of abstract syntax tree generation.

[0012] In another possible implementation, the field mapping structure includes at least one set of key-value pairs. Before converting the field mapping structure into an abstract syntax tree based on syntax rules, the implementation includes: extracting the first key-value pairs corresponding to the workflow fields in the field mapping structure; obtaining the data type of the key value in each first key-value pair; and deleting the first key-value pairs whose data type does not meet a first preset condition, the first preset condition including that the data type is string.

[0013] Based on this solution, by pre-screening fields that meet the semantic parsing requirements, the propagation of invalid nodes in the abstract syntax tree is reduced, improving the accuracy and execution efficiency of subsequent semantic analysis. At the same time, it effectively isolates abnormal data types from interfering with the parsing process, enhancing the system's stability under complex input scenarios.

[0014] In another possible implementation, the semantic structure is converted into first metadata based on the semantic structure and a pre-defined mapping rule base. This includes: obtaining the runtime mode field in the semantic structure; determining the type of each semantic unit in the semantic structure based on the runtime mode field; obtaining the target mapping sub-rule corresponding to each semantic unit according to the type of the semantic unit, wherein the target mapping sub-rule is a rule in the mapping rule base that matches the language type and the type of semantic unit; determining the target mapping rule based on each target mapping sub-rule; and converting each semantic unit in the semantic structure into first metadata according to the target mapping rule.

[0015] Based on this solution, a fine-grained conversion from semantic structure to metadata can be achieved, ensuring that different types of semantic units are accurately mapped to the target format according to preset rules.

[0016] In another possible implementation, each semantic unit in the semantic structure is converted into first metadata according to the target mapping rule, including: extracting the field values ​​in each semantic unit; mapping each field value to a target field based on the target mapping sub-rule; and generating first metadata based on the target field.

[0017] Based on this scheme, precise mapping of field-level semantics can be achieved, ensuring that each semantic unit obtained from DSL data has a consistent and traceable expression in the target metadata.

[0018] In another possible implementation, the first metadata is processed to generate second metadata that conforms to a preset format, including: obtaining the format constraints corresponding to the preset format; validating the field values ​​in the semantic unit based on the format constraints; if the field values ​​conform to the format constraints, then the first metadata is determined as the second metadata; if the field values ​​do not conform to the format constraints, then a field missing prompt is generated.

[0019] Based on this solution, format anomalies can be detected and located in a timely manner during the metadata conversion process, avoiding parsing failures or system anomalies caused by data format mismatches.

[0020] In another possible implementation, in response to receiving domain-specific language (DSL) data, the language type of the DSL data is obtained, including: in response to receiving the DSL data, reading the type identifier of the DSL data; determining the language type of the DSL data based on the type identifier; and matching the corresponding first grammar rule in the grammar rule base based on the language type.

[0021] Based on this solution, appropriate parsing syntax rules can be dynamically loaded according to the language type of DSL data, ensuring that DSL data from different sources and structures can be accurately identified and processed, thereby improving the system's support for multilingual environments and parsing flexibility.

[0022] In another possible implementation, matching a corresponding first grammar rule in a grammar rule base based on the language type includes: retrieving a grammar rule matching the language type from the grammar rule base; if the retrieval is successful, determining the obtained grammar rule as the first grammar rule; if the retrieval fails, initiating a grammar rule retrieval request to an external rule base based on the language type; in response to a second grammar rule sent by the external rule base, loading the second grammar rule into the grammar rule base; and determining the second grammar rule as the first grammar rule.

[0023] Based on this solution, the syntax rule base can be dynamically expanded, improving the system's compatibility with unknown language types and ensuring that syntax parsing can still be completed through external collaboration even when there are no built-in rules, thereby enhancing the adaptability and maintainability of the metadata conversion function.

[0024] In a second aspect, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0025] Thirdly, embodiments of this application also provide a metadata conversion system for a multi-source domain-specific language (DSL). This system includes: an adaptation module configured to obtain the language type of the DSL data in response to receiving DSL data in a domain-specific language; a parsing module configured to parse the semantic structure corresponding to the DSL data based on a first grammar rule corresponding to the language type in a preset grammar rule library; a rule mapping module configured to convert the semantic structure into first metadata according to the semantic structure and a preset mapping rule library; and a verification and correction module configured to perform format verification and correction on the first metadata to generate second metadata conforming to a preset format of a multi-agent system.

[0026] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0027] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0028] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0029] Figure 1 is a schematic diagram of a computing device deploying a multi-agent system working collaboratively with an external development platform; Figure 2 is a flowchart illustrating a method for converting metadata of a multi-source domain-specific language provided in an embodiment of this application; Figure 3 is a flowchart illustrating a method for identifying domain-specific language data provided in an embodiment of this application; Figure 4 is a flowchart illustrating a method for grammar rule matching provided in an embodiment of this application; Figure 5 is a flowchart illustrating a method for parsing DSL data provided in an embodiment of this application; Figure 6 is a flowchart illustrating a method for converting a grammatical structure into first metadata provided in an embodiment of this application; Figure 7 is a flowchart illustrating a method for converting a semantic structure into metadata provided in an embodiment of this application; Figure 8 is a flowchart illustrating a method for node parsing and mapping provided in an embodiment of this application; Figure 9 is a schematic diagram of a metadata conversion system provided in an embodiment of this application; Figure 10 is an architectural schematic diagram of a multi-agent system provided in an embodiment of this application; Figure 11 is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0031] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0032] An intelligent agent (Agent) is an autonomous entity that can perceive and take actions in a specific environment to achieve its goals. It has the ability to perceive the environment, make decisions, plan and execute, and can continuously optimize its behavior strategies based on memory and tool recall.

[0033] A multi-agent system (MAS) is a computing system composed of multiple autonomous or semi-autonomous agents. Each agent completes complex tasks in a dynamic environment that a single agent cannot achieve through cooperation or negotiation mechanisms. MAS can achieve information sharing and task allocation through communication protocols between agents, and supports distributed decision-making and collaborative control.

[0034] Domain-specific languages ​​(DSLs) are programming languages ​​or language extensions designed for specific application domains. Compared to general-purpose languages, their syntax is closer to domain concepts, which can improve development efficiency and expressive accuracy. They are widely used in model-driven engineering and automated code generation.

[0035] Agent-Architecture Description Language (Agent-ADL) is a language for MAS (Multi-Agent Systems) that formally describes the structure, behavior, interaction protocols, and environmental coupling relationships of intelligent agents, thereby improving the design consistency and maintainability of complex intelligent systems.

[0036] The application scenarios of the embodiments of this application will be described below.

[0037] With the deep integration of artificial intelligence and distributed system technologies, the application of MAS (Multi-Solution System) is becoming increasingly widespread, and the tasks it needs to complete are becoming more complex. To accomplish these complex tasks, MAS will interface with various external development platforms to enhance its capabilities and improve system development efficiency.

[0038] Figure 1 is a schematic diagram of a computing device for deploying a multi-agent system working collaboratively with an external development platform.

[0039] As shown in Figure 1, a multi-agent system 110 can be deployed in a first computing device 100 to enable the first computing device 100 to process complex tasks. The system architecture of the first computing device 100 may include an interface unit 120 and a processor 130. The interface unit 120 provides the first computing device 100 with functions such as access, authentication, and security services, enabling the first computing device 100 to connect with external computing devices. The processor 130 is used to process the data received by the first computing device 100 to implement specific functional business.

[0040] Taking the deployment of a multi-agent system 110 in the first computing device 100 as an example, the multi-agent system 110 may include an access conversion layer 111 and an agent system core layer 112. The access conversion layer 111 can be set in the interface unit 120 in the form of a functional module or system configuration, while the agent system core layer 112 can be set in the processor 130 in the form of a system configuration.

[0041] The access conversion layer 111 can perform communication protocol adaptation and data format conversion with the second computing device 200, which is equipped with an external development platform 210, through the interface unit 120, to achieve seamless connection between heterogeneous systems. The core layer 112 of the intelligent agent system carries core functions such as task engine, intelligent agent registration, and AI application operation management through the processor 130, in order to complete task scheduling, resource management, and collaborative control.

[0042] Through this architecture, the multi-agent system 110 can access multiple different second computing devices 200 through the first computing device 100, realize the ability to call capabilities and share resources of different external development platforms 210, thereby expanding the task execution capabilities and environmental adaptability of the agents.

[0043] However, the second computing device 200, which is deployed with different external development platforms 210, will define the configuration information of the intelligent agent through its own DSL. The different DSLs have significant heterogeneity in terms of format, syntax rules and semantic definition, which leads to obstacles in configuration parsing and semantic understanding when the multi-agent system is connected to multiple external development platforms.

[0044] In the method of connecting the first computing device 100 to the second computing device 200 which is deployed with an external development platform 210, it is common to develop corresponding adaptation modules for each DSL and implement field mapping and conversion through encoding. This has a long development cycle and high development cost, which is not conducive to the first computing device 100 quickly connecting to the new external development platform.

[0045] Traditional general-purpose conversion tools, such as ANTLR and Xtext, are designed for general computer languages. Their output cannot be directly mapped to the metadata corresponding to Agent-ADL. Semantic alignment requires the development of additional intermediate parsing layers, which still requires a lot of manual intervention and customized development. This makes it difficult to meet the needs of multi-agent systems for efficient and automated integration of multi-source DSLs.

[0046] This application provides a method for converting metadata of a multi-source domain-specific language. By constructing a unified data conversion channel at the access conversion layer, it enables automated parsing and semantic mapping of DSL description files from different external development platforms. This method converts heterogeneous DSL data from multiple sources into Agent-ADL metadata, avoiding parsing difficulties and integration obstacles caused by the heterogeneity of DSLs between external development platforms. This significantly reduces the development cost and maintenance complexity of system integration.

[0047] In the embodiments of this application, the computing device deploying the multi-agent system can be a single device or a cluster of computing devices. Similarly, the computing device deploying an external development platform can also be a single device or a cluster of computing devices. In the embodiments of this application, when "computing device" refers to a computing device deploying a multi-agent system or a computing device deploying an external development platform, its specific device composition is not limited.

[0048] Figure 2 is a flowchart illustrating the method for converting metadata of a multi-source domain-specific language provided in an embodiment of this application.

[0049] As shown in Figure 2, the metadata conversion method provided in this application embodiment may include the following steps S100 to S400.

[0050] S100: In response to receiving domain-specific language DSL data, the computing device obtains the language type of the DSL data.

[0051] In this embodiment, the metadata conversion method can be implemented using a computing device that deploys a multi-agent system. The computing device can connect to other computing devices via an interface unit, enabling the external development platform to interface with the multi-agent system. After interface connection, the device receives DSL data sent from the external development platform on other computing devices via the interface unit and converts the DSL data so that it can be directly utilized by the core layer of the multi-agent system.

[0052] After the multi-agent system completes its interface with the external development platform, the computing device can capture the DSL data sent by the external development platform through the listening interface unit, and parse its language type according to the syntactic features or meta-information identifiers of the DSL data, thereby identifying the external development platform to which the DSL belongs and the corresponding syntactic rules.

[0053] For example, DSL data may contain file header identifiers, extensions, or specific syntax structures. By recognizing the characteristic information corresponding to the DSL, a computing device can identify its corresponding language type.

[0054] Figure 3 is a schematic diagram of a process for identifying domain-specific language data according to an embodiment of this application. The process for identifying the language type of DSL data is described below based on the content in Figure 3.

[0055] As shown in Figure 3, the process by which a computing device identifies the language type corresponding to DSL data may include the following steps S110 to S130.

[0056] S110: In response to receiving DSL data, the computing device reads the type identifier of the DSL data.

[0057] In this embodiment, the computing device can obtain the language type of the DSL by reading the type identifier corresponding to the DSL data after receiving the DSL data. For example, the type identifier can be a metadata tag or header signature information embedded by an external development platform when generating the DSL file, which is used to uniquely identify the syntax system and platform to which the DSL belongs.

[0058] For example, in the DSL data sent by an external development platform, a corresponding type identifier can be added to the header metadata to achieve the recognition process of the corresponding language type. The DSL type can be a first type or a second type. The DSL data generated based on the first type of DSL can include a type identifier in the form of "dsl_type":dify", while the DSL data generated based on the second type of DSL includes a type identifier in the form of "dsl_type":n8n".

[0059] In this way, by reading the content in the type identifier, the computing device implements the solution in subsequent steps to identify the type of DSL data. It should be understood that the specific content in the type identifier is only an example, and in actual applications it can be set and modified through system configuration or user-input configuration files.

[0060] In this embodiment, both the external development platform using the first type of DSL and the external development platform using the second type of DSL are commonly used automated process design tools among external development platforms. Different external development platforms can provide computing devices with visualized workflows, configure plugins, models, knowledge bases, and workflows, or build automated business processes. Correspondingly, when different external development platforms interact with computing devices, the DSL data they use corresponds to specific syntax rules and structural features. Furthermore, the first and second types given in this embodiment are merely examples; in actual applications, the external development platform interfacing with the computing device can also be other types of DSL. This embodiment does not limit the specific type of external development platform.

[0061] The language type of DSL data can be clearly marked by setting a specific field, such as the "dsl_type" field in the example. The computing device can extract the corresponding field from the DSL data by recognizing the field name to obtain the type identifier of the DSL data.

[0062] Because different external development platforms may generate DSL data type identifiers with different DSL types and no agreed header metadata format, the generated DSL data type identifiers may have naming differences, inconsistent formats, or no type identifier embedded in the header metadata. In this case, the computing device cannot directly obtain the type identifier of the DSL data and needs to further infer it through syntax feature analysis or file extension.

[0063] In some embodiments, the computing device can read the type identifier of the DSL data based on its syntactic feature structure to obtain the corresponding language type. For example, when the language type of the DSL is a first type, its syntax may include an "app" field, which contains a "mode" subfield. The value corresponding to the "mode" subfield is usually relatively fixed and may be a specific enumerated value such as "chat," "agent," or "completion." The computing device can determine whether the DSL belongs to the first type by detecting the presence of the "app" field and its enumerated value in the "mode" subfield.

[0064] When the language type of a DSL is type II, its syntax may contain the fields "nodes" and "connections", but it does not contain the field "app". Computing devices can infer that it belongs to type II DSL by recognizing this structural feature and combining the uniqueness of the field combination.

[0065] Furthermore, when grammatical features are not obvious, computing devices can further combine file extensions, contextual call information, or platform origin to assist in the judgment, so as to achieve accurate identification from multiple dimensions.

[0066] It should be understood that the above-mentioned methods for reading the type identifier corresponding to DSL are only a few examples provided in the embodiments of this application. In practical applications, the type identifier of DSL data can also be determined by other methods, such as classifying and recognizing the DSL syntax structure based on machine learning models, or matching specific patterns through a predefined rule base. The embodiments of this application do not limit the method for reading the type identifier of DSL data.

[0067] S120: The computing device determines the language type of the DSL data based on the type identifier.

[0068] After the computing device identifies the type identifier, it can parse the syntax type and external development platform used by the DSL data. Taking the example given in step S110 as an illustration, when the DSL data contains a unified header metadata identifier field "dsl_type", the computing device extracts the field value corresponding to this field and identifies the language type of the DSL data by recognizing whether the field value is a preset valid type enumeration value. For example, when the field value is "dify", the computing device determines that it is a first type of DSL; when the field value is "n8n", it determines that it is a second type of DSL.

[0069] In some embodiments, if identification is performed using field names in the DSL data, the language type can be determined by identifying whether the DSL data includes platform-specific structural features such as the "app" field, "nodes" field, and "connections" field. When the "app" field exists and contains the "mode" subfield, it can be identified as a first type of DSL; when the "nodes" and "connections" fields exist but the "app" field is not present, it can be identified as a second type of DSL.

[0070] In another embodiment, the computing device can also combine header metadata identification fields and field name recognition methods to jointly identify the language type of DSL data, thereby improving the accuracy of identification. For example, when the header field "dsl_type" is missing or invalid, the computing device can use structural feature recognition methods, combining field combinations, hierarchical depth, and semantic context for comprehensive judgment.

[0071] S130: Based on the language type, match the corresponding first grammar rule in the grammar rule base.

[0072] After obtaining the language type, the computing device can match the first grammar rule corresponding to that language type from a pre-set grammar rule base. The grammar rule base can be a set of grammar rules stored in the computing device's memory. This grammar rule base is used by the computing device to determine the appropriate grammar rules after acquiring the language type corresponding to the DSL data. The grammar rule base can be predefined and stored based on the grammar rules of different DSL language types. Each language type corresponds to a unique set of grammar rules, which may include lexical structure, statement format, field hierarchy relationships, and constraints.

[0073] The first grammar rule is a grammar parsing rule retrieved and matched by the computing device from a grammar rule base based on the language type, used for structured parsing of DSL data in subsequent steps. In some embodiments of this application, the grammar rule base may be a set of grammar rules set by the user before the application computing device parses and converts the DSL data, which may include at least one grammar rule corresponding to a DSL language type.

[0074] For example, the syntax rule base may include syntax rules for a first type of DSL and syntax rules for a second type of DSL. Each set of rules includes the language-specific field naming conventions, object nesting structures, and expression writing conventions. When the computing device identifies the language type of the DSL data as the first type, it will automatically match the syntax rule corresponding to the first type of DSL, determine it as the first syntax rule, and perform subsequent DSL data structure parsing operations.

[0075] Furthermore, to adapt to various external development platforms accessed by computing devices, the syntax rule base can be equipped with a dynamic update interface. When the syntax rule base does not contain syntax rules for the target language type, new syntax rules can be loaded through the dynamic update interface, or existing syntax rules can be modified or expanded, thereby supporting the rapid access of new DSLs.

[0076] Figure 4 is a schematic flowchart of a syntax rule matching process provided in an embodiment of this application. The syntax rule matching process provided in an embodiment of this application will be described below based on Figure 4.

[0077] As shown in Figure 4, the process of matching the syntax rules of the language type corresponding to the DSL data in the preset syntax rule base may include the following steps S131 to S135.

[0078] S131: Based on the language type, retrieve the syntax rules that match the language type from the syntax rule base.

[0079] In this embodiment, after determining the language type corresponding to the DSL data based on steps S110 and S120, the computing device can search for a matching grammar rule in the grammar rule base based on the language type. In some embodiments of this application, the computing device can traverse all the grammar rules stored in the grammar rule base, comparing the identification information and other parameters corresponding to each grammar rule one by one until the target grammar rule is found.

[0080] Because the grammar rule base may store multiple versions of grammar rules for the same type of DSL, matching solely by language type may not be able to determine a unique target grammar rule. Therefore, the computing device can also combine the version information field carried in the DSL data to locate the target grammar rule in the grammar rule base that is compatible with the DSL data and unique.

[0081] In some implementations, if the syntax rule base contains a large number of syntax rules, traversing the entire syntax rule base to match syntax rules may lead to decreased matching efficiency. Therefore, the computing device can pre-establish an index mapping relationship between language types and syntax rules to achieve fast matching of syntax rules. For example, when constructing the syntax rule base, the computing device can establish an index mapping relationship for each language type and its corresponding syntax rules, and quickly locate the target syntax rule through a hash table or tree structure.

[0082] Taking the establishment of an index mapping relationship using a hash table as an example, a computing device can store key-value pairs generated based on the identification information and syntax rules in a hash table by using the identification information corresponding to the language type as the key and the syntax rules as the value, and using a hash function to map the key to a specified position in the hash table.

[0083] After identifying the language type, the computing device can directly use the type identifier as the key of the hash index to quickly retrieve the corresponding syntax rules. This allows the computing device to retrieve the syntax rules corresponding to DSL data without traversing the syntax rule base, significantly improving matching efficiency and response speed.

[0084] In some embodiments, when the header metadata of DSL data does not contain a type identifier, the computing device can generate a corresponding key based on the syntax type identified by the syntax features, search for matching syntax rules in the hash table, and then obtain the syntax rules corresponding to the DSL data.

[0085] It should be understood that the hash table-based index mapping method in this application is only an exemplary way to achieve fast matching. Other efficient data structures or algorithms can also be used to retrieve grammatical rules. For example, when there are many language types and hierarchical classifications, a tree structure can be used to build a multi-level index to achieve flexible retrieval of grammatical rules.

[0086] S132: If the retrieval is successful, the obtained syntax rule shall be determined as the first syntax rule.

[0087] If the computing device successfully retrieves the data, it can use the obtained grammar rule as the basis for subsequent parsing of DSL data, determine it as the first grammar rule, and execute the subsequent step S200 based on the first grammar rule to perform lexical and grammatical parsing on the DSL data and generate the corresponding semantic structure.

[0088] S133: If the retrieval fails, a request to obtain syntax rules from an external rule base will be initiated based on the language type.

[0089] If the computing device fails to retrieve a syntax rule, it means that there is no rule in the syntax rule base that matches the current DSL data. In this case, the computing device can send a syntax rule missing prompt to the user, prompting the user to enter a new syntax rule or check whether the DSL data format is correct.

[0090] Users can add new syntax rules based on the prompts. After receiving the rules, the computing device compiles them into the library and updates the index mapping relationship to support the automatic matching and parsing of subsequent DSL data of the same type, thereby enhancing the adaptability and scalability of the computing device deploying the multi-agent system.

[0091] Because the mechanism for adjusting the syntax rule base based on user feedback can lead to user response delays, in order to ensure the processing capability of the computing device in scenarios where rules are missing, in some embodiments of this application, the memory of the computing device may also store an external rule base to store syntax rules provided by third parties or predefined standards.

[0092] The external rule base is an independent set of syntax rules relative to the syntax rule base stored and maintained inside the memory of the computing device. It can automatically collect DSL syntax rule templates released by open source communities, industry standard organizations or other third parties through an interface, and update them regularly to extend the syntax rules of various DSLs.

[0093] In some embodiments, the external rule base may also be stored in other devices with storage functions, and the storage device is connected to the computing device that deploys the multi-agent system through an interface unit. The computing device can call the external rule base stored in the storage device through the interface unit.

[0094] For example, the update time of the external rule base can be triggered based on the update cycle set by the user or the rule base version change notification, such as automatically pulling the latest rule package every day at midnight.

[0095] When updating syntax rules, the external rule base transforms the collected syntax rules based on the form of the syntax rules in the syntax rule base. This allows the external rule base to automatically adapt its storage and index structure when loading new rules from the external rule base, ensuring the compatibility and consistency of the computing device with the new syntax rules.

[0096] In scenarios where the grammar rule base is connected to an external rule base, if the computing device fails to retrieve the grammar rule base, it can initiate a grammar rule retrieval request to the external rule base based on the language type of the DSL data, and attempt to match the corresponding grammar rule from the external rule base.

[0097] It should be understood that introducing an external rule base can improve the compatibility of computing devices with DSLs. As a relay unit between the syntax rule base and the open source network, the external rule base can store the syntax rules corresponding to the DSL that are not currently used by the computing device, avoiding the performance degradation caused by redundant rules in the syntax rule base. At the same time, through the on-demand loading mechanism, the external rule base is only accessed when the retrieval fails, reducing the system resource consumption, avoiding the system stability fluctuations and retrieval performance degradation caused by frequent updates of the syntax rule base, and ensuring the efficient operation of the core parsing process, thus realizing the dynamic expansion of the syntax rule base.

[0098] S134: In response to the second syntax rule sent by the external rule base, the computing device loads the second syntax rule into the syntax rule base.

[0099] After sending a request to retrieve syntax rules to an external rule base, the computing device can continuously monitor the response status of the external rule base. If the external rule base returns a second syntax rule, the computing device can load the second syntax rule into the syntax rule base, thereby realizing dynamic updates of the syntax rule base during use. This avoids the problem of parsing interruption caused by the absence of syntax rules in the syntax rule base that match the currently received DSL data, and ensures the computing device's continuous processing capability for multi-source DSL data.

[0100] If the external rule base fails to return a matching second grammar rule after receiving the grammar rule retrieval request, the computing device will generate a rule missing log for the corresponding DSL language type, and generate prompt information and processing records to provide feedback to the user so that the user can understand the reason for the grammar rule matching failure in a timely manner, and support manual import or definition of relevant grammar rules to supplement the rule base.

[0101] In some embodiments of this application, if the external rule base fails to return a matching second syntax rule after receiving a syntax rule retrieval request, the computing device can also trigger the external rule base update mechanism to synchronize the latest published syntax rule index. After the external rule base is updated, the computing device can resend the syntax rule retrieval request to the external rule base to attempt to match the required syntax rule. If a matching second syntax rule is still not obtained, the computing device can determine that the syntax rules for the DSL language type do not currently exist in the external rule base. The computing device will terminate the automatic loading process and generate a prompt message and processing record, indicating to the user that the syntax rules for the current DSL language type are not yet included in the external rule base.

[0102] It should be noted that the dynamic update interface of the syntax rule base in this embodiment can receive syntax rules sent from external rule bases, and can also be used to receive syntax rules generated by the computing device in response to user instructions. This enables flexible loading of user-defined syntax rules and meets the personalized parsing needs of specific business scenarios. Users can input custom syntax rules through a visual interface or script. The computing device can perform legality verification and structural parsing on the received syntax rules to ensure that they conform to the storage and calling specifications of the syntax rule base. After verification, the rules are loaded into the syntax rule base and an index is built based on the language type and version information corresponding to the syntax rules for subsequent calls.

[0103] S135: The computing device determines the second syntax rule as the first syntax rule.

[0104] In this embodiment of the application, after storing the second grammar rule in the grammar rule library, the computing device can search for the first grammar rule that matches the language type of the DSL data obtained in the aforementioned processing steps in the grammar rule library, and then determine the second grammar rule newly loaded into the grammar rule library as the first grammar rule required for this conversion.

[0105] It should be understood that after the computing device loads the second syntax rule obtained from the external rule base into the syntax rule base, it needs to retrieve the corresponding syntax rule from the syntax rule base before it can be applied. This ensures the traceability and consistency of the syntax rule loading and invocation process, avoiding parsing anomalies caused by incompatibility between the rule loading and invocation processes. It also avoids version conflicts or semantic ambiguities caused by inconsistent syntax rule sources for different development platforms' DSLs, ensuring the stability and accuracy of the DSL data parsing and conversion process. By uniformly matching the corresponding syntax rule from the syntax rule base, the computing device can achieve centralized management and version control of all syntax rules, improving rule invocation efficiency and reducing external dependency risks.

[0106] S200: Based on the first grammar rule corresponding to the language type in the preset grammar rule base, parse the semantic structure corresponding to the DSL data.

[0107] After the computing device matches the corresponding first grammar rule in the grammar rule base according to the language type, it can use the first grammar rule to parse and process the DSL data to obtain the semantic structure corresponding to the DSL data, so that the computing device can convert the DSL data into first metadata.

[0108] In this embodiment of the application, the parsing process of DSL data includes: first, performing lexical analysis on the code to decompose the character sequence in the DSL data into meaningful syntactic units (Tokens); then, through syntactic analysis, organizing these units into a tree structure according to the syntactic rules of the language, where each node represents a syntactic construct in the code, such as a class definition, function declaration, assignment statement, condition judgment, etc.

[0109] The tree structure obtained based on the above embodiments is the Abstract Syntax Tree (AST). The AST is used to present the hierarchical syntactic structure of DSL data, accurately reflecting its inherent logical relationships and program structure. By traversing the AST, the computing device identifies the semantic features of each node and their nesting relationships, and then extracts the semantic structure that can be mapped to the metadata of the multi-agent system. This allows for the structured representation of core elements in the DSL data, such as semantic types, core fields, and relationships, facilitating subsequent metadata conversion and mapping operations.

[0110] Figure 5 is a schematic flowchart of a DSL data parsing process provided in an embodiment of this application. The DSL data parsing process provided in an embodiment of this application will be described below based on Figure 5.

[0111] As shown in Figure 5, the process of parsing DSL data may include the following steps S210 to S230.

[0112] S210: Based on the first syntax rule, obtain the abstract syntax tree corresponding to the DSL data.

[0113] After obtaining the first syntax rule, the computing device can parse the DSL data to obtain the corresponding abstract syntax tree. Furthermore, the construction process of the abstract syntax tree follows the syntax rule definition provided by the first syntax rule, organizing the syntactic units in the DSL data layer by layer into a node structure with parent-child relationships, ensuring the integrity of the program logic and the correctness of the syntax.

[0114] In some embodiments of this application, the process of generating an abstract syntax tree may include the following steps S211 to S216.

[0115] S211: Parse DSL data into a string sequence.

[0116] After receiving DSL data and obtaining the first grammar rule based on the DSL data, the computing device can parse the DSL data into a string sequence using the first grammar rule, which can then be used as input for lexical analysis.

[0117] Taking DSL data with the language type of type 1 as an example, the correspondence between some fields in the DSL data and the parameters in the multi-agent system can be seen in Table 1 below.

[0118] Table 1 ;

[0119] As shown in Table 1, DSL data of language type 1 may include the fields shown in the DSL structure and their corresponding field values. The field values ​​describe the data structure mapping relationship in the DSL data sent by the external development platform to the multi-agent system. Internal system objects refer to the core data structures within the multi-agent system used to carry the information after DSL data parsing. Each internal system object establishes a mapping relationship with a specific field in the DSL data, ensuring that external configurations can be accurately converted into runtime entities that the multi-agent system can recognize. The descriptions are used to explain the structure of the DSL data and the purpose of the internal system objects, aiding in understanding the functional positioning of each field and its role in the overall architecture.

[0120] Furthermore, since there are usually multiple nodes, edges, variables, and other data in a workflow object, the computing device can construct a corresponding list based on the system parameters of the multi-agent system to receive metadata obtained through the interface unit mapping.

[0121] In this embodiment of the application, the process of parsing DSL data into a string sequence refers to decomposing the DSL data into an ordered sequence of several basic character units according to its syntax specification. For example, based on the DSL structure definition in Table 1, each field can be parsed to generate a corresponding string sequence, and then the corresponding abstract syntax tree can be generated based on the generated string sequence.

[0122] It should be understood that the correspondences shown in Table 1 of the above embodiments are merely illustrative examples, and in actual applications, they can be adjusted accordingly based on the structural characteristics of the specific DSL language. Correspondingly, the string sequence generated by parsing is also closely related to the syntax design of the DSL language. The character unit splitting rules of different fields must follow the syntax rules of their respective languages, that is, in the parsing process, the corresponding string sequence and even the abstract syntax tree in subsequent steps are obtained based on the corresponding first syntax rule.

[0123] S212: Deserialize the string sequence to obtain the field mapping structure.

[0124] After obtaining the string sequence, the computing device can deserialize the corresponding string sequence and convert it into a Map.<String,Object> A structured field mapping structure. Specifically, a Map.<String,Object> The structure is a key-value pair mapping data structure, where the key is a string type representing the field name, and the value is any object type used to carry the numerical value or nested structure corresponding to the field.

[0125] Taking the DSL structure shown in Table 1 as an example, fields such as "app" and "workflow" shown in Table 1 will be converted into Map during deserialization.<String,Object> The key in the structure has its corresponding field value stored as the value, forming a structured field mapping relationship, which facilitates the dynamic reading and parsing of DSL data by subsequent programs.

[0126] Through the field mapping structure, computing devices can associate and store the parsed field names with their corresponding values, realizing a structured representation of DSL data and providing a data foundation for subsequent data parsing and conversion processes.

[0127] In some implementations of this application, because DSL data may contain nested structures, during deserialization, the nested structures of some fields and their corresponding values ​​are stored as Values ​​in their corresponding field mapping structures to support the parsing and access of multi-level data. For example, the "workflow" field may contain multiple subfields and their connection relationships; these subfields can be directly stored in the Value corresponding to "workflow," forming a Map.<String,Object> The structure can also be modified by deserializing each subfield in step S211 to implement the Map of the "workflow" field using a multi-level nested Map structure.<String,Object> The structure, such as "workflow" as the outer key, and its subfields "graph" and "conversation_variables" as the keys of the inner map, and the field values ​​corresponding to the subfields "graph" and "conversation_variables" as the values ​​of the inner map, together form the outer value, which forms a field mapping structure with the outer key. This hierarchical syntax structure of DSL data is mapped level by level to ensure the complete expression and accurate reproduction of complex configurations.

[0128] S213: Extract the first key-value pair corresponding to the workflow field in the field mapping structure.

[0129] In this embodiment of the application, before converting the field mapping structure into an abstract syntax tree, the computing device also needs to verify the fields in the field mapping structure to ensure that each field conforms to the predefined syntax specifications and business logic requirements, so as to avoid subsequent parsing anomalies due to missing fields or incorrect formats.

[0130] The workflow field refers to the core field in DSL data used to describe task nodes, execution order, branch conditions, and dependencies. For example, the "workflow" field in the first type of DSL data can define information such as node topology, execution logic, and parameter configuration. The completeness and validity of this field directly affect the parsing and execution effect of the entire workflow.

[0131] After obtaining the language type and the first grammar rule corresponding to the DSL data, the computing device can extract and verify the fields in the field mapping structure by means of the grammar rule constraints in the first grammar rule, and determine whether key fields, such as workflow fields, exist and conform to the preset structure.

[0132] Taking the first type of DSL data as an example, the verification target of the computing device when verifying DSL data can be the workflow-related content in the DSL data. At this time, the computing device can extract the data units corresponding to the workflow fields in the field mapping structure, such as the "workflow" field and nested fields of the "workflow" field (e.g., "workflow.graph", "workflow.conversation_variables", etc.). Among them, any subfield at any level of the "workflow" field can be regarded as a workflow field. The computing device can extract them one by one according to the field hierarchy path and include them in the verification scope to ensure the structural integrity and semantic correctness of the DSL data.

[0133] It should be understood that while the field names in workflow fields differ across different language types of DSLs, the core logic of the field values ​​that need to be validated revolves around key semantics such as process definition, node configuration, and variable declaration. When validating DSL data of different language types, the computing device can determine the workflow-related fields in the DSL data based on the first syntax rules corresponding to the DSL data, then extract the specific values ​​of these fields and verify their data type, nesting structure, and semantic consistency to ensure the completeness and validity of the process definition.

[0134] S214: Get the data type of the key value in each first key-value pair.

[0135] After extracting the first key-value pair corresponding to the workflow field, the computing device can perform a validity check on the key value of the first key-value pair to determine whether it conforms to the field naming conventions defined in the first syntax rules, such as whether the name contains only allowed characters, whether it starts with a legal prefix, and whether there are any reserved word conflicts.

[0136] In this embodiment, the verification process can determine whether the field corresponding to the first key-value pair conforms to the definition of the first syntax rule by the data type of the key value of the first key-value pair. Furthermore, the first key-value pair can refer to a Map with a nested structure corresponding to fields such as "workflow" or "workflow, graph," or it can be a Map corresponding to a subfield of these fields. When the computing device reads the key value type of the first key-value pair, it recursively traverses all key values ​​related to the workflow field to ensure that the data type of the field name at each level is retrieved.

[0137] S215: Delete the first key-value pair whose data type does not meet the first preset condition.

[0138] After obtaining the data type of the Key value in the first key-value pair, the computing device can determine whether the first key-value pair meets a first preset condition based on the data type, and then determine whether it can be retained in the field mapping structure. The first preset condition includes the data type being string. That is, when the Key value is a string, it can be determined that the first key-value pair corresponding to the Key value meets the first preset condition. The computing device can retain the first key-value pair and transform it into an abstract syntax tree based on the retained key-value pair, thereby ensuring that the hierarchical structure and semantic logic of the workflow fields in the DSL are completely preserved during the transformation process.

[0139] For non-string key values, the first preset condition is not met. The computing device will filter the key-value pair, removing it from the field mapping structure or setting it to null, to avoid subsequent parsing errors due to illegal key types. This filtering mechanism effectively ensures the standardization and consistency of the field mapping structure, ensuring that only legal key-value pairs that conform to the syntax rules participate in the construction of the abstract syntax tree, improving the continuity of conversion after multi-source DSL access, and reducing manual intervention in the metadata conversion process.

[0140] In some embodiments, the verification process can be performed during the deserialization of the string sequence by the computing device to obtain the field mapping structure, so that the generated field mapping structure does not contain key-value pairs of non-string data types, thereby improving the efficiency of the computing device in parsing and processing DSL data.

[0141] S216: Based on the first syntax rule, convert the field mapping structure into an abstract syntax tree.

[0142] After obtaining the field mapping structure and filtering out key-value pairs that do not meet the first preset condition, the computing device can convert the field mapping structure into the corresponding abstract syntax tree structure, thereby realizing the programmatic representation of the workflow definition in the DSL. The conversion process of the abstract syntax tree combines the hierarchical relationship of key-value pairs and type constraints to ensure the semantic validity and structural compliance of each node. The final generated abstract syntax tree can be directly parsed and executed by the compiler or interpreter, providing a standardized intermediate representation for subsequent workflow scheduling and verification.

[0143] S220: Traverse and perform semantic analysis on the abstract syntax tree to obtain semantic information and relationships.

[0144] After generating the abstract syntax tree (API), the computing device can map the API to a specific grammatical structure, providing a foundation for subsequent metadata transformation. Because the API is a structured representation of DSL data, possessing clear hierarchical characteristics and semantic integrity, the computing device can traverse the API to determine the semantic information in the DSL data and the relationships between these semantic elements, thereby mapping each node in the API to its corresponding grammatical structure.

[0145] S230: Construct a semantic structure based on semantic information and relationships.

[0146] In this embodiment of the application, the computing device can obtain semantic information and corresponding relationships by traversing each node of the abstract syntax tree and combining it with the first syntax rule. The computing device can map the obtained semantic information into a syntax structure with clear execution logic, ensuring that the workflow defined in the DSL can be converted into the operation instructions of the target system, i.e., the multi-agent system.

[0147] This mapping process is based on predefined conversion templates and semantic alignment strategies. Combined with the first grammar rule obtained by the computing device from the grammar rule base, it completes the accurate conversion from abstract syntax tree nodes to target syntax structures, realizing end-to-end automated generation from workflow definition to runtime instructions, reducing manual intervention and improving conversion efficiency and accuracy.

[0148] S300: Based on the semantic structure and the preset mapping rule base, convert the semantic structure into first metadata.

[0149] After constructing the semantic structure, the computing device can convert the semantic structure into first metadata that can be recognized by the multi-agent system based on the preset mapping rule base, so that the first metadata can accurately reflect the workflow logic and execution order defined in the original DSL.

[0150] It should be noted that the names of each node in the semantic structure are still consistent with the fields in the DSL data, but its structure has been reshaped according to the syntax specifications of the target system. The process of converting the semantic structure into first metadata is to semantically align the field names in the DSL with the recognizable instruction identifiers in the multi-agent system, thereby converting the workflow logic defined in the DSL data into an executable instruction sequence, ensuring that each agent can accurately understand and collaboratively complete the task.

[0151] In this embodiment, the mapping rule base includes the definition of mapping relationships between different DSL syntax structures and internal objects of the multi-agent system, covering field type conversion, hierarchical nesting processing and semantic alignment mechanisms, to ensure that each element in the DSL is accurately mapped to an instruction unit that the multi-agent system can parse.

[0152] Similar to the syntax rule base, the mapping rule base can also include an update interface, supporting the dynamic loading of new mapping configurations to adapt to the evolving DSL syntax and the interface specifications of computing devices. Through this update mechanism, computing devices can complete system rule iterations without interrupting the services provided by the multi-agent system, ensuring the timeliness and compatibility of the conversion logic, while reducing maintenance costs and improving the overall system's flexibility and scalability.

[0153] Figure 6 is a schematic diagram illustrating the process of converting a syntactic structure into first metadata according to an embodiment of this application. The first metadata conversion process in the embodiments of this application will be described below based on the process shown in Figure 6.

[0154] As shown in Figure 6, taking the first type of DSL data as an example, the process by which the computing device converts the semantic structure into first metadata by utilizing the rules in the preset rule base may include the following steps S310 to S350.

[0155] S310: Retrieves the running mode field from the semantic structure.

[0156] Before transforming the semantic structure, the computing device can determine the type of nodes in the semantic structure and identify the type of each node. Based on the relationship between the types of nodes in the semantic structure, the corresponding mapping rules can be determined to map different semantic units to the corresponding internal objects in the multi-agent system.

[0157] In this embodiment, the computing device can obtain the running mode field in the semantic structure to obtain the running mode corresponding to the original DSL data, and then determine the execution logic and coordination strategy of each node under the running mode, thereby selecting the appropriate mapping rule.

[0158] For example, a typical value for the operating mode field could be "app.mode". The computing device can identify the operating mode corresponding to the DSL data by matching the value of this field in the semantic structure.

[0159] S320: Based on the running mode field, determine the type of each semantic unit in the semantic structure.

[0160] Here, a semantic unit refers to a node or substructure in a semantic structure that has independent functional meaning. It may include at least one of the following: input parameters, processing logic, output definition, and connection relationships with other nodes. The computing device can map each semantic unit based on mapping rules, converting it into an internal object instance that can be recognized by the multi-agent system, ensuring that semantic integrity is preserved during the conversion process.

[0161] Under different operating modes, the node types and their relationships contained in DSL data of the same language type will also differ, and therefore the mapping rules applied during the metadata conversion process will also be different. For example, the computing device can retrieve the field node related to "app.mode" in the semantic structure converted from the first type of DSL data, and parse its value to identify whether the current application mode is "chat", "agent" or "completion".

[0162] The semantic structures derived from DSL data in different operating modes include different types of workflow nodes. For example, chat mode and completion mode mainly include input nodes, output nodes, and Large Language Model (LLM) nodes, while agent mode will include tool call nodes, planning nodes, loop nodes, and branch nodes on top of these nodes to support more complex task orchestration and autonomous decision-making processes.

[0163] Therefore, when converting semantic structure into first metadata, the computing device can first determine the current operating mode based on the value of the operating mode field, thereby determining the nodes included and the corresponding mapping rules of the nodes. This facilitates the dynamic loading of the corresponding rule subset based on the operating mode, ensuring accurate matching between node type and mapping logic, and avoiding redundancy in rule loading and mapping conflicts.

[0164] It should be understood that the value of the above-mentioned operating mode field is only an example of the first type of DSL data. In actual applications, the operating mode fields and their specific values ​​are different for different types of DSL data. The computing device can dynamically adapt the operating mode parsing strategy of different data sources through the DSL type identifier obtained in the above steps to ensure the accuracy of semantic structure mapping.

[0165] S330: Based on the type of semantic unit, obtain the target mapping sub-rule corresponding to each semantic unit.

[0166] Among them, the target mapping sub-rules are rules in the mapping rule base that match the language type and the type of semantic unit. After the computing device determines the type of each semantic unit in the semantic structure based on the operating mode, it can query the target mapping sub-rules corresponding to each semantic unit type in the mapping rule base, so that each semantic unit can match the accurate conversion logic according to its type, and then parse it into the metadata corresponding to the multi-agent system layer by layer.

[0167] In this embodiment of the application, the mapping rules in the mapping rule base can be mapped to language type and semantic unit type respectively, so that the computing device can not only locate the appropriate rule set in the mapping rule base by the language type corresponding to the DSL data, but also further lock the specific mapping sub-rule by the semantic unit type, thus achieving accurate matching in two dimensions.

[0168] It should be understood that the construction method of mapping rules and language types and semantic unit types in the mapping rule base can be the same as the construction method of the index mapping relationship between syntax rules and language types in the syntax rule base provided in the foregoing embodiments, and will not be elaborated here.

[0169] S340: Determine the target mapping rule based on each target mapping sub-rule.

[0170] After determining the target mapping sub-rule corresponding to each semantic unit, the computing device can combine the obtained mapping sub-rules to form a target mapping rule, so that the target mapping rule can fully cover all node types and their associated logic contained in the current semantic structure, ensuring that the context relationship of each semantic unit is preserved during the transformation process.

[0171] S350: Based on the target mapping rules, each semantic unit in the semantic structure is converted into first metadata.

[0172] After obtaining the target mapping rule, the computing device performs a transformation operation on each semantic unit in the semantic structure according to the rule, converting them into corresponding first metadata. Taking the DSL structure shown in Table 1 as an example, after the DSL data is parsed, the computing device can map app, workflow, workflow.graph, and lower-level fields or semantic units in the semantic structure into AppMatedata, Workflow, Graph, and corresponding node, edge, and other metadata elements in the multi-agent system. This completes the conversion from domain-specific language description to metadata that can be recognized by the multi-agent system, while ensuring that the semantics of the DSL data are lossless and the structure is consistent.

[0173] Figure 7 is a schematic diagram of a process for converting semantic structure into metadata according to an embodiment of this application.

[0174] As shown in Figure 7, the process by which a computing device converts semantic structures into metadata may include the following steps S351 to S353.

[0175] S351: The computing device extracts the field values ​​from each semantic unit separately.

[0176] After obtaining the target mapping rule, the computing device can sequentially transform each semantic unit in the semantic structure based on the target mapping rule. For example, the computing device can traverse each semantic unit in the semantic structure, determine the field value corresponding to each semantic unit, and then, based on the type of the semantic unit and the field value, call the target mapping sub-rule in the target mapping rule to convert it into first metadata.

[0177] Taking the first type of DSL data as an example, the semantic structure obtained by the computing device after processing the DSL data can include at least two top-level semantic units: "app" and "workflow". Each of these semantic units contains multiple sub-semantic units. For example, "app" includes fields such as "name" and "type", while "workflow" includes fields such as "graph", "conversation_variables", and "environment_variables". A top-level semantic unit refers to a semantic unit that has no parent node or parent semantic unit, and its upper-level structure is the semantic structure obtained from the DSL data.

[0178] In the semantic structure, workflow-related semantic units, namely `workflow` and its sub-semantic units, have more parameters and a more complex nested structure compared to the semantic units corresponding to the `app` field, requiring multi-level mapping processing. Accordingly, when retrieving field values, the semantic unit's field value can be obtained by parsing layer by layer based on its hierarchical path.

[0179] In this embodiment of the application, when processing the semantic unit corresponding to the workflow field, the computing device can decompose it into sub-semantic units such as node, edge, workflow_variables (abbreviated as wfVars in this embodiment of the application) and environment_variables (abbreviated as envVars in this embodiment of the application) and parse them one by one.

[0180] Here, Node refers to the smallest task node in the workflow, and Edge represents the execution dependencies between nodes, i.e., the connecting edges in the directed graph, used to define the execution order of nodes. wfVars is used to store workflow-level shareable variables, while envVars stores externally injected runtime environment parameters. The computing device maps Nodes to task instances and Edges to execution path constraints according to the mapping logic for each semantic unit in the target mapping rules. wfVars and envVars are then resolved into dynamic variables and environment configuration parameters in the runtime context, respectively.

[0181] S352: Based on the target mapping sub-rule, map each field value to the target field corresponding to the multi-agent system.

[0182] In this embodiment, the target field refers to the parameter object corresponding to the multi-agent system deployed in the computing device. After obtaining the field value corresponding to each semantic unit, the computing device can substitute each field value into the predefined target mapping sub-rule to complete the layer-by-layer construction from the DSL structure to the target field corresponding to the multi-agent system.

[0183] Figure 8 is a schematic diagram of the node parsing and mapping process provided in an embodiment of this application. The process of mapping field values ​​in DSL data to target fields corresponding to a multi-agent system, as provided in an embodiment of this application, will be described below with reference to Figures 7 and 8.

[0184] For example, as shown in Figure 8, the node parsing process provided in this embodiment of the application includes the following steps S3521 to S3526.

[0185] S3521: Traverse the graph structure field in the semantic structure to obtain the list of task nodes in the graph structure field.

[0186] In the process of mapping the content corresponding to the semantic unit Node, since the semantic unit Node is a sub-semantic unit of the semantic unit in the graph structure, the semantic unit Graph in the semantic structure can be traversed first to obtain the semantic path and context information corresponding to each semantic unit Node.

[0187] S3522: Obtain the core data of the task node.

[0188] Then, by iteratively processing each semantic unit Node, the core data of the task node is extracted. In some embodiments of this application, the fields and mapping relationships in the semantic unit Node are shown in Table 2 below.

[0189] Table 2

[0190] Referring to Table 2, a semantic unit (Node) may include attributes such as node identifier, node type, node title, node description, parent node identifier, and node data. The DSL structure refers to the field names corresponding to these parameters in the DSL data, while the internal system objects are the mapping target fields corresponding to these parameters. The computing device can then process the data. The field values ​​corresponding to the fields serve as core data, facilitating the assembly of task nodes during the transformation process.

[0191] S3523: Verify the type of the task node.

[0192] When processing semantic units (Nodes), computing devices can determine the corresponding node type through the node type field, and then perform type verification on the task nodes based on the node type to ensure that the node type conforms to the preset multi-agent system node type specification, thereby ensuring the correct distribution and execution of subsequent task instructions.

[0193] It should be understood that the node type verification is related to the operating mode determined in the aforementioned embodiments. If the operating mode is "chat", the computing device will only allow node types such as input nodes, output nodes, and LLM nodes to pass the verification during the verification process. If the operating mode is "agent", then complex logic nodes such as tool nodes and condition judgment nodes will be additionally allowed to pass the verification.

[0194] S3524: Maps task nodes that match the node type to the target format.

[0195] The target format refers to the object format that the multi-agent system can recognize. Taking the contents of Table 2 as an example, the computing device can map the DSL structure field names in the task nodes to the corresponding field names of the internal objects of the system, realize the normalization conversion of the fields, and ensure that each task node is executable in the multi-agent system.

[0196] S3525: Based on node type, assemble the parameters corresponding to the task node into a system node.

[0197] In this context, a system node refers to the smallest execution unit that can run independently in a multi-agent system. The assembly of a system node requires combining the execution logic and parameter requirements corresponding to the node type, and injecting the mapped field data into the corresponding internal system object to form a schedulable node instance with contextual relevance and functional completeness.

[0198] In this embodiment of the application, the computing device can build a corresponding node data converter for each type of task node based on mapping rules, thereby converting different types of node data into the format supported by the internal objects of the system according to preset rules, and realizing the unified processing of heterogeneous node data.

[0199] Taking an LLM node as an example, the computing device can extract the core data from the node and, based on its content, map the core content of the task node to the corresponding system node, enabling the multi-agent system to execute the corresponding tasks through the system node.

[0200] For example, taking the LLM node configuration shown in Table 3 as an example, the data shown in the DSL structure is the data corresponding to the LLM node in the DSL data. The field name in the field, the LLMNodeData attribute is the attribute structure of the LLM system node in the multi-agent system, the data type refers to the data type of the field value corresponding to the field in the multi-agent system, and the description explains the specific role of the field in the system.

[0201] Table 3

[0202] It should be noted that the content shown in Table 3 is only an example. In actual applications, nodes can include more fields or attributes than those shown in the table, and the mapping relationships corresponding to different node types are also different. The computing device can perform mapping management based on the data corresponding to the task node in the DSL data and the preset node attributes in the multi-agent system, and dynamically generate adapted system node instances.

[0203] S3526: Node variable name for generating system nodes.

[0204] After mapping the data of task nodes to system nodes, the computing device can also ensure that the DSL data can be uniquely identified and invoked in the multi-agent system based on the generation order and node type of the system nodes and the unique node variable name corresponding to the data. For example, the first generated LLM node can be named "llm_node_0", and subsequent nodes can be named sequentially. If it is a node of other types, it can be identified with a corresponding prefix, such as "agent_node_1", to ensure the standardization and traceability of node naming.

[0205] Furthermore, the computing device can also generate a mapping table between the corresponding node identifier and the node variable name through the node variable name, which facilitates subsequent parsing.

[0206] After generating the node variable name, the computing device can complete the parsing and mapping process of the semantic unit Node, generate node instances that conform to the multi-agent system architecture specification, and ensure that the semantic unit can be accurately scheduled and coordinated at runtime.

[0207] After the task node conversion in the DSL data is completed, the computing device can also form a corresponding node set based on the number of system nodes obtained, which facilitates the computing device to generate the first metadata in subsequent processes.

[0208] In the embodiments of this application, the mapping process of the target field includes not only the above-mentioned node transformation process, but also the parsing and transformation of data such as edges, workflow variables and environment variables.

[0209] During the mapping process, the variables in the DSL data may include, for example, the contents shown in Table 4.

[0210] Table 4

[0211] Referring to Table 4, DSL fields refer to variable fields in DSL data, system internal objects refer to the structures used to carry variable semantics and runtime states in a multi-agent system, and data types refer to the type definition of variables in system internal objects, such as String, Integer, Boolean, or custom complex types, to ensure that variables have the correct data carrying and processing capabilities at runtime.

[0212] It should be understood that, in addition to the contents shown in Table 4 above, the variable fields in DSL data also include the characteristic configuration of the variables. The structure shown in Table 4 is only an example. The variable field structure in actual applications can be extended or adjusted according to specific system requirements. This application embodiment does not impose any restrictions here.

[0213] During the process of converting variables, the computing device can refer to the aforementioned method of converting task nodes into field mappings in system nodes to parse and map the variable fields in the DSL data item by item, mapping each variable to the corresponding variable object inside the multi-agent system.

[0214] In some embodiments, variable objects in a multi-agent system can be represented by a List. <variableprop>Unified management is implemented, where VariableProp is a data structure that encapsulates variable attributes. The computing device maps DSL data by strictly following the mapping relationship, which can realize the accurate correspondence between DSL data and variable objects inside the multi-agent system and ensure the consistency of cross-platform mapping.

[0215] In some embodiments, edge mapping refers to converting the inter-node connection relationships defined in the DSL data into communication paths or dependencies within the multi-agent system. The fields contained in the edges and the mapping relationships are shown in Table 5 below.

[0216] Table 5

[0217] Referring to Table 5, DSL fields refer to edge fields in DSL data, while internal system objects refer to structures used in multi-agent systems to carry edge connection semantics and runtime interaction logic. Their field mapping ensures the accurate restoration of process topology relationships within the system. By converting edge definitions in DSL into executable communication paths in a multi-agent system, precise modeling of message passing, task flow, and dependency control between nodes is achieved, ensuring the continuity and consistency of cross-platform collaboration.

[0218] It should be noted that during the mapping process of the edge field, the computing device also needs to replace the starting node and target node of the edge with the identifier of the system node mapped in the aforementioned embodiment, so that the mapped edge can correctly point to the mapped starting node and target node in the multi-agent system, thereby ensuring the complete reproduction of the process topology.

[0219] After generating the system nodes and edge fields corresponding to the multi-agent system, the computing device can determine the node state of the system nodes and determine whether they are iterative nodes, thus avoiding infinite loops or state conflicts during the execution of the system nodes.

[0220] In some embodiments, the computing device can group system nodes based on parent node identifiers and construct a hierarchical topology by combining the node execution order and dependencies, thereby identifying node paths with circular reference characteristics and obtaining the corresponding iterative node set.

[0221] The computing device can construct a first iteration node and a second iteration node, respectively. The first iteration node corresponds to the system node at the start of the iteration, and its variable name format can be modified to {parent node variable name}_start, with the type marked as ITERATION_START. The second iteration node corresponds to the system node at the end of the iteration, and its variable name format is {parent node variable name}_end, with the type marked as ITERATION_END. After generating the second iteration node, the computing device can inject the second iteration node into the system node set and update the corresponding edge connection relationships to ensure that the start and end nodes of the iteration logic are correctly connected in the process topology. Here, the parent node variable name refers to the variable name of the parent node corresponding to the entire iteration node set.

[0222] The computing device can determine the corresponding processing method by observing the state of the iterative node set. If there is no ending node in the iterative node set, a second iterative node can be generated based on the above process to complete the loop structure, ensuring that each iterative path has a definite termination point. If there is no out-degree in the iterative node set (i.e., no edge pointing from a node to other nodes), then that node is connected to the second iterative node.

[0223] For example, when generating the edge field corresponding to the multi-agent system, if the starting node is an iteration node, the target of the edge is set to {parent node variable name}_end of the iteration node set; if the target node is an iteration node, the starting position of the edge is set to {parent node variable name}_start of the iteration node set. This ensures that the connection logic between the task loop inside the iteration structure and the external process is correct and avoids path deviation or state misalignment during execution.

[0224] S353: The computing device generates first metadata based on the target field.

[0225] In this embodiment of the application, the computing device can generate various target fields for nodes, variables and edges in the above manner, and the computing device can combine them to generate first metadata as the parsing result of DSL data, thereby realizing a complete modeling of the logical structure of the multi-agent system.

[0226] S400: Process the first metadata to generate second metadata that conforms to a preset format.

[0227] In this embodiment, the processing of the first metadata by the computing device may include format verification and format correction. Format verification is used to check the degree of matching between the obtained first metadata and the multi-agent system deployed in the computing device, and to determine whether the syntax structure of the first metadata conforms to the format constraints. Format correction, on the other hand, corrects the first metadata by filling in default values ​​or other methods when the format verification fails to meet the format constraints, so that the computing device can generate second metadata that conforms to the preset format.

[0228] The preset format refers to the metadata format corresponding to the multi-agent system deployed in the computing device. After obtaining the first metadata, the computing device can send a query request to the functional module corresponding to the multi-agent system to obtain the metadata format corresponding to the preset format in the multi-agent system and use it as a format constraint. For example, the format constraint may include mandatory field requirements, field type specifications, uniqueness constraints, etc., and the specific content of this application embodiment is not limited.

[0229] It should be noted that the format verification and format correction process can be automatically triggered during the conversion of DSL data into the corresponding multi-agent system metadata format by the computing device, or the verification process can be executed uniformly after the computing device generates the first metadata.

[0230] In some embodiments, when a multi-agent system is deployed to a computing device, the corresponding format constraints and parameters such as internal system objects can be stored in the memory of the computing device. After receiving DSL data through the interface unit, the computing device can obtain the format constraints and corresponding internal system objects by calling the memory.

[0231] Furthermore, after obtaining the format constraints, the computing device can verify the field values ​​in the semantic unit based on the format constraints, and then determine whether they conform to the preset format. When they conform to the format constraints, the computing device will determine the first metadata as the second metadata, and obtain the metadata result that the multi-agent system can directly use.

[0232] If a field value does not conform to the format constraints, the computing device can determine whether the format can be corrected based on the attributes of the field that does not conform to the format constraints. If the field that does not conform to the format constraints is not a required field and there is a default value in the format constraints, the field that does not conform to the format constraints will be modified to the default value and the format validation process will be re-executed. If the field that does not conform to the format constraints is a required field, the parsing of the field will be skipped, the part of the first metadata that conforms to the format constraints will be converted into the corresponding second metadata for storage, and a field missing prompt will be generated. At the same time, an exception log will be generated based on the converted second metadata and the field missing prompt for subsequent traceability.

[0233] In some embodiments, the verification process executed in steps S200 and S300 can also be implemented through the above process, and this application does not limit it.

[0234] Based on the metadata conversion method provided in this solution, accurate mapping of DSL data to recognizable metadata of multi-agent systems can be effectively achieved, improving the reliability and automation level of logical structure conversion between systems. By introducing dynamic format verification and iterative node processing mechanisms, the semantic integrity and structural consistency of complex process models are ensured during the parsing process, providing a data foundation for the smooth execution of multi-agent collaborative tasks.

[0235] Figure 9 is a schematic diagram of a metadata conversion system provided in an embodiment of this application, and Figure 10 is a schematic diagram of the architecture of a multi-agent system provided in an embodiment of this application.

[0236] Corresponding to the aforementioned embodiments of the metadata conversion method, this application also provides an embodiment of a metadata conversion system. As shown in FIG9, the metadata conversion system 90 includes an adaptation module 91, a parsing module 92, a rule mapping module 93, and a verification and correction module 94.

[0237] The adaptation module 91 is configured to obtain the language type of the DSL data in response to receiving domain-specific language DSL data.

[0238] The parsing module 92 is configured to parse the semantic structure of the DSL data based on the first grammar rule corresponding to the language type in the preset grammar rule library.

[0239] The rule mapping module 93 is configured to convert the semantic structure into first metadata based on the semantic structure and a preset mapping rule library.

[0240] The verification and correction module 94 is configured to perform format verification and format correction on the first metadata to generate second metadata that conforms to the preset format of the multi-agent system.

[0241] In some embodiments of this application, the metadata conversion system 90 may also include multiple different types of DSL adapters to adapt to the DSL syntax features and data interaction formats of different platforms. Each DSL adapter can be generated based on the first syntax rule obtained during the initial processing, so that in subsequent processes, the corresponding type of DSL data can be directly routed to the DSL adapter to perform the DSL data conversion process as described in the foregoing embodiments.

[0242] As shown in Figure 10, the metadata conversion system 90 can be set in the access conversion layer 1020 of the multi-agent system 1000. The architecture of the multi-agent system 1000 may also include an agent system core layer 1010 and an external DSL input layer 1030. The metadata conversion system 90 in the access conversion layer 1020 can execute the metadata conversion method provided in the aforementioned embodiments through its various modules to convert any type of DSL data input from the external DSL input layer 1030 into Agent-ADL metadata that can be executed by the agent system core layer 1010.

[0243] Figure 11 is a schematic diagram of a computing device provided in an embodiment of this application.

[0244] As shown in Figure 11, the computing device 1100 includes a processor 1101 and a memory 1102. Exemplarily, the computing device 1100 may also include a communications interface 1103 and a communications bus 1104.

[0245] The processor 1101, memory 1102, and communication interface 1103 communicate with each other via communication bus 1104. The communication interface 1103 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0246] In this embodiment, the communication interface 1103 can be used to enable communication between the computing device 1100 and a terminal device with an external development platform, thereby enabling the multi-agent system deployed on the computing device 1100 to receive DSL data from different external development platforms.

[0247] In some embodiments, the processor 1101 is used to execute program 1105, specifically performing the relevant steps in the above-described metadata conversion method embodiments. Specifically, program 1105 may include program code, which includes computer-executable instructions.

[0248] For example, processor 1101 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1100 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0249] In some embodiments, memory 1102 is used to store program 1105. Memory 1102 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0250] Specifically, program 1105 can be called by processor 1101 to cause computing device 1100 to perform metadata conversion method operations.

[0251] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1100, causes the computing device 1100 to perform the metadata conversion method described in the above embodiments.

[0252] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0253] Some embodiments of this application provide a chip system applied to a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the server performs various steps in the metadata conversion method shown in the above-described method embodiments.

[0254] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding metadata conversion method provided above, and will not be repeated here.

[0255] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.< / variableprop>

Claims

1. A method for metadata conversion of a multi-source domain-specific language, characterized in that, include: In response to receiving domain-specific language (DSL) data, the language type of the DSL data is obtained; Based on the first grammar rule corresponding to the language type in the preset grammar rule base, the semantic structure corresponding to the DSL data is parsed. Based on the semantic structure and the preset mapping rule base, the semantic structure is converted into first metadata; The first metadata is processed to generate a second metadata that conforms to a preset format.

2. The method according to claim 1, characterized in that, The step of parsing the DSL data to obtain the semantic structure corresponding to the DSL data includes: obtaining an abstract syntax tree corresponding to the DSL data based on the first syntax rule; traversing and semantically analyzing the abstract syntax tree to obtain semantic information and relationships; and constructing the semantic structure based on the semantic information and relationships.

3. The method according to claim 2, characterized in that, The step of obtaining the abstract syntax tree corresponding to the DSL data based on the first syntax rule includes: parsing the DSL data into a string sequence; deserializing the string sequence to obtain a field mapping structure; and converting the field mapping structure into an abstract syntax tree based on the first syntax rule.

4. The method according to claim 3, characterized in that, The field mapping structure includes at least one set of key-value pairs. Before converting the field mapping structure into an abstract syntax tree based on the syntax rules, the process includes: extracting the first key-value pairs corresponding to the workflow fields in the field mapping structure; obtaining the data type of the key value in each first key-value pair; and deleting the first key-value pairs whose data type does not meet a first preset condition, wherein the first preset condition includes that the data type is a string type.

5. The method according to any one of claims 1 to 4, characterized in that, The step of converting the semantic structure into first metadata based on the semantic structure and a preset mapping rule base includes: obtaining a running mode field in the semantic structure; determining the type of each semantic unit in the semantic structure based on the running mode field; obtaining a target mapping sub-rule corresponding to each semantic unit according to the type of the semantic unit, wherein the target mapping sub-rule is a rule in the mapping rule base that matches the language type and the type of the semantic unit; determining a target mapping rule based on each target mapping sub-rule; and converting each semantic unit in the semantic structure into the first metadata according to the target mapping rule.

6. The method according to claim 5, characterized in that, The step of converting each semantic unit in the semantic structure into the first metadata according to the target mapping rule includes: extracting the field value in each semantic unit; mapping each field value to a target field based on the target mapping sub-rule; and generating the first metadata based on the target field.

7. The method according to claim 5, characterized in that, The step of processing the first metadata to generate second metadata conforming to a preset format includes: obtaining the format constraints corresponding to the preset format; validating the field values ​​in the semantic unit based on the format constraints; if the field values ​​conform to the format constraints, then determining the first metadata as the second metadata; if the field values ​​do not conform to the format constraints, then generating a field missing prompt.

8. The method according to any one of claims 1 to 7, characterized in that, The step of obtaining the language type of the domain-specific language (DSL) data in response to receiving the DSL data includes: reading the type identifier of the DSL data in response to receiving the DSL data; determining the language type of the DSL data based on the type identifier; and matching the corresponding first grammar rule in the grammar rule base based on the language type.

9. The method according to claim 8, characterized in that, The step of matching a corresponding first grammar rule in the grammar rule base based on the language type includes: retrieving a grammar rule that matches the language type from the grammar rule base; if the retrieval is successful, determining the obtained grammar rule as the first grammar rule; if the retrieval fails, initiating a grammar rule retrieval request to an external rule base based on the language type; in response to a second grammar rule sent by the external rule base, loading the second grammar rule into the grammar rule base; and determining the second grammar rule as the first grammar rule.

10. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled; the memory is used to store program instructions. The processor is configured to execute the program instructions to perform the method as described in any one of claims 1 to 9.

Images