Multi-agent-based data space adaptive data delivery method and device

Abstract

The invention relates to the technical field of data space, and discloses a multi-agent-based data space adaptive data delivery method and device, and the method comprises the steps: inputting an unstructured data product API interface document and a data APP interface document into a large language model agent, and obtaining a structured data product API calling template and a data APP receiving template; inputting the data product API calling template and the data APP receiving template into a large language model agent to obtain a mapping conversion file; inputting the data into a large language model agent by using a contract to obtain a constraint rule file; inputting the mapping conversion file and the constraint rule file into a large language model agent to obtain a delivery process control chart; and acquiring data from the data product API according to the delivery process control chart by utilizing a large language model agent, and injecting the acquired data into the data APP. According to the invention, the automatic adaptation capability of the data delivery process in the data space can be improved, and data circulation and utilization are promoted.

Description

Technical Field

[0001] This application relates to the field of data space technology, and for example to a data space adaptive data delivery method and apparatus based on multi-agent systems. Background Technology

[0002] Currently, with the gradual development of the data factor market, the importance of data as a new type of production factor is becoming increasingly prominent. To achieve trusted sharing and controllable circulation of data across entities, organizations, and regions, data space, as an architectural system with "data sovereignty and compliant sharing" as its core concept, is being widely deployed and applied in various fields.

[0003] In related technologies, data providers offer access to their data products through connectors. After downloading and deploying the data app, the data user signs a data delivery agreement with the data provider, then calls the API of the data provider's connector to obtain the data and pushes it to the data app deployed on the local connector to complete the delivery.

[0004] In the process of implementing the embodiments of this disclosure, at least the following problems were found in the related art: Due to the high heterogeneity in fields and semantics between the data product API of the data provider and the data APP input interface of the data user, the data delivery methods in related technologies rely on a lot of manual configuration and development of adaptation logic, which cannot dynamically adapt to interface changes and cannot achieve automatic connection between the data product API and the data APP input interface during the data delivery process.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0007] This disclosure provides a data space adaptive data delivery method and apparatus based on multi-agent systems to improve the automatic adaptation capability between data product APIs and data APP input interfaces during the data delivery process in the data space, thereby promoting data circulation and utilization.

[0008] In some embodiments, the multi-agent system includes multiple large language model agents for adaptive data delivery between data product APIs of data providers and data apps of data users in a data space. The multi-agent-based adaptive data delivery method for a data space includes: inputting unstructured data product API interface documents and data app interface documents into the large language model agents to obtain structured data product API call templates and data app receiving templates; these templates are used for semantic mapping analysis. The data product API call templates and data app receiving templates are then input into the large language model agents to obtain mapping transformation files by analyzing semantic mapping relationships; these files are used for mapping different semantics and structures in the data product APIs and data apps. The data usage contract signed between the data user and the data provider is input into the large language model agents to obtain constraint rule files; these files are used to control data access and usage behavior. The mapping transformation files and constraint rule files are then input into the large language model agents to obtain a delivery process control chart by orchestrating the data delivery process in the data space. The large language model agents then retrieve data from the data product APIs according to the delivery process control chart and inject the retrieved data into the data apps.

[0009] Optionally, the unstructured data product API interface documents and data APP interface documents are input into a large language model agent to obtain structured data product API call templates and data APP receiving templates. This includes: using the large language model agent to perform semantic parsing on the unstructured language in the data product API interface documents and data APP interface documents, and automatically identifying key information based on the semantic parsing results; the key information includes one or more of the following: interface call method, parameter requirements, field structure, and data format; and generating structured data product API call templates and data APP receiving templates based on the key information.

[0010] Optionally, the data product API call template and the data APP receiving template are input into a large language model agent. By analyzing the semantic mapping relationship, a mapping conversion file is obtained, including: using the large language model agent to analyze fields with different semantics and structures in the data product API call template and the data APP receiving template, constructing a mapping relationship between API output fields and APP input fields to form a field mapping table; analyzing the mapping conversion logic based on the data in the field mapping table, and automatically generating conversion logic rules; the mapping conversion logic includes one or more of type conversion rules, unit conversion rules, and default value filling; and generating a mapping conversion file based on the field mapping table and the conversion logic rules.

[0011] Optionally, the data usage contract signed between the data user and the data provider is input into the large language model agent to obtain a constraint rule file, including: using the large language model agent to analyze the usage restriction clauses in the data usage contract; the usage restriction clauses include one or more of the following: access frequency, time window, field range, usage restrictions, and data retention strategy; and generating a constraint rule file based on the usage restriction clauses.

[0012] Optionally, the mapping transformation file and constraint rule file are input into the large language model agent, and a delivery process control chart is obtained by orchestrating the data delivery process in the data space. This includes: using the large language model agent to analyze the mapping transformation file and constraint rule file, and orchestrating the data delivery process based on the analysis results to generate process control logic; and constructing the delivery process control chart based on the process control logic.

[0013] Optionally, the delivery process control diagram includes strategy nodes and transformation nodes; the large language model agent obtains data from the data product API according to the delivery process control diagram and injects the obtained data into the data APP, including: executing the delivery process control diagram using the large language model agent, calling the data product API according to the strategy nodes in the delivery process control diagram to obtain the raw data, and performing data field transformation on the raw data according to the transformation nodes in the delivery process control diagram to obtain the target data that the data APP expects to receive; and injecting the target data into the data APP receiving interface.

[0014] Optionally, after generating the delivery process control chart, the delivery process control chart is confirmed, specifically including: visually presenting the delivery process control chart to the data user and obtaining feedback from the data user on the delivery process control chart; readjusting the process of generating the delivery process control chart based on the feedback information, and controlling the large language model agent to regenerate the delivery process control chart based on the adjusted process.

[0015] Optionally, the large language model agent is trained and optimized based on previous data delivery tasks. Specifically, this includes: collecting historical task information during the data delivery process; historical task information includes one or more of the following: task execution logs, field adaptation effects, user feedback, and exception information; constructing a data delivery training set based on the historical task information; training and optimizing the large language model agent based on the data delivery training set; and training and optimizing the large language model agent includes one or more of the following: prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

[0016] In some embodiments, a multi-agent-based data space adaptive data delivery device includes: a document understanding agent, used to input unstructured data product API interface documents and data APP interface documents into a large language model agent to obtain structured data product API call templates and data APP receiving templates; the data product API call templates and data APP receiving templates are used for semantic mapping analysis. A semantic mapping agent, used to input the data product API call templates and data APP receiving templates into the large language model agent, and obtain a mapping conversion file by analyzing semantic mapping relationships; the mapping conversion file is used for mapping different semantics and structures in the data product API and data APP. A contract analysis agent, used to input the data usage contract signed between the data user and the data provider into the large language model agent to obtain a constraint rule file; the constraint rule file is used to control data access and usage behavior. A delivery process generation agent, used to input the mapping conversion file and constraint rule file into the large language model agent, and obtain a delivery process control chart by orchestrating the data delivery process in the data space. An execution control agent, used to use the large language model agent to obtain data from the data product API according to the delivery process control chart, and inject the obtained data into the data APP.

[0017] Optionally, the data delivery device further includes: a multi-agent coordination and scheduling module, used to confirm the delivery process control chart after it is generated, specifically including: visually displaying the delivery process control chart to the data user and obtaining feedback from the data user regarding the delivery process control chart; readjusting the process of generating the delivery process control chart based on the feedback information, and controlling the large language model agent to regenerate the delivery process control chart based on the adjusted process; and a memory and learning agent, used to train and optimize the large language model agent based on previous data delivery tasks, specifically including: collecting historical task information during the data delivery process; historical task information including one or more of task execution logs, field adaptation effects, user feedback, and exception information; constructing a data delivery training set based on the historical task information; training and optimizing the large language model agent based on the data delivery training set; and training and optimizing the large language model agent including one or more of prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

[0018] In some embodiments, a multi-agent-based data space adaptive data delivery apparatus includes a processor and a memory storing program instructions, the processor being configured to execute the multi-agent-based data space adaptive data delivery method as described above when the program instructions are executed.

[0019] The data space adaptive data delivery method and apparatus based on multi-agent systems provided in this disclosure can achieve the following technical effects: In this embodiment, a large language model agent parses API interface documents and data APP interface documents, automatically extracting calling logic from unstructured interface documents to achieve autonomous understanding of the interface structure. This generates data product API call templates and data APP receiving templates. Then, the large language model agent analyzes semantic mapping relationships, identifies semantic similarities between fields in the two templates, and generates corresponding conversion rules to obtain a mapping conversion file. This enables automatic semantic mapping and parameter conversion between heterogeneous APIs, reducing manual adaptation costs. Furthermore, the large language model agent parses data usage contracts to generate constraint rule files, ensuring that the data delivery process strictly conforms to contract terms. Finally, the delivery process control chart generated by the large language model agent based on the mapping conversion file and rule constraint file automatically adjusts the delivery process to dynamically adapt to interface changes. This solves delivery barriers caused by interface heterogeneity between data provider and data user interfaces, thereby improving the automatic adaptation capability between data product APIs and data APP input interfaces during data delivery in the data space and promoting data circulation and utilization.

[0020] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0021] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of a data space architecture provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of a data space multi-agent delivery engine provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of another data space multi-agent delivery engine provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the data delivery process of a data space multi-agent delivery engine provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of a multi-agent-based adaptive data delivery method for data space provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of a data space adaptive data delivery device based on multiple agents provided in an embodiment of this disclosure. Detailed Implementation

[0022] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0023] The terms "first," "second," etc., used in the technical solutions described in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0024] Unless otherwise stated, the term "multiple" means two or more.

[0025] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0026] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0027] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0028] Combination Figure 1 As shown, this disclosure provides a data space architecture, including a connector A for a data provider, a connector B for a data user, a data marketplace, and an application store.

[0029] Data providers can join the data space through connector A and register one or more of their data products (data product 1, data product 2) in the data marketplace's data directory. When each data product is published, in addition to metadata (such as data subject, data type, update time, provider identifier, etc.), it must also provide interface documentation for its data access API. This documentation can be in OpenAPI, Markdown, Word / PDF, or other natural language formats, describing the calling method, parameter specifications, response format, and other information. Connector A uploads this information to the data marketplace of the data space for other entities to query and use.

[0030] Developers can leverage the open capabilities of the data space to develop adapted data processing applications (APP1, APP2) for specific use cases (such as "product carbon footprint", "urban traffic monitoring", "corporate credit scoring", "energy consumption optimization analysis", etc.) and upload them to the data space's app store. Each APP provides a standardized receiving interface (such as REST API, gRPC, etc.) for receiving data and declares the desired data format and semantic structure. Data users browse the app store through connector B, select the data APP that matches their scenario requirements (such as "user profiling engine APP"), and download and deploy it locally on connector B.

[0031] Data users browse published data products in the data marketplace, select a data product (such as "user behavior data"), and initiate a contract signing process with the data provider. Both parties reach an agreement on the core elements of data use and form a data usage contract. The contract includes: data access frequency (e.g., a maximum of 500 calls per day), validity period (e.g., the contract is valid for 30 days from the date of signing), field scope restrictions, usage restrictions (e.g., only for modeling and analysis), geographical restrictions, response timeliness, and access authentication mechanisms. The data usage contract is registered and monitored by the data space contract service module, serving as the basis for subsequent automatic delivery.

[0032] After successful contract signing, Connector B of the data user triggers the data space multi-agent delivery engine, which is a multi-agent adaptive data delivery device for the data space. The multi-agent system includes multiple large language model agents used to achieve adaptive data delivery between the data provider's data product API and the data user's data APP within the data space. Combined with... Figure 2 and Figure 4As shown in the embodiments of this disclosure, a data space multi-agent delivery engine 200 is provided, including: a document understanding agent 201, a semantic mapping agent 202, a contract analysis agent 203, a delivery process generation agent 204, and an execution control agent 205. The document understanding agent 201 is used to input unstructured data product API interface documents and data APP interface documents into a large language model agent to obtain structured data product API call templates and data APP receiving templates; these templates are used for semantic mapping analysis. The semantic mapping agent 202 is used to input the data product API call templates and data APP receiving templates into the large language model agent, and obtain a mapping conversion file by analyzing semantic mapping relationships; this file is used for mapping different semantics and structures in the data product API and data APP. The contract analysis agent 203 is used to input the data usage contract signed between the data user and the data provider into the large language model agent to obtain a constraint rule file; this file is used to control data access and usage behavior. Delivery process generation agent 204 is used to input the mapping transformation file and constraint rule file into the large language model agent, and obtain the delivery process control chart by arranging the data delivery process in the data space. Execution control agent 205 is used to use the large language model agent to obtain data from the data product API according to the delivery process control chart, and inject the obtained data into the data APP.

[0033] Optionally, combined Figure 3 and Figure 4 As shown, the data space multi-agent delivery engine 200 also includes a multi-agent coordination and scheduling module 206 and a memory and learning agent 207. The multi-agent coordination and scheduling module 206 is used to confirm the delivery process control chart after it is generated. Specifically, this includes: visually displaying the delivery process control chart to the data user and obtaining feedback from the data user regarding the delivery process control chart; readjusting the process of generating the delivery process control chart based on the feedback information; and controlling the large language model agent to regenerate the delivery process control chart according to the adjusted process. The memory and learning agent 207 is used to train and optimize the large language model agent based on previous data delivery tasks. Specifically, this includes: collecting historical task information during the data delivery process; historical task information includes one or more of the following: task execution logs, field adaptation effects, user feedback, and exception information; constructing a data delivery training set based on the historical task information; training and optimizing the large language model agent based on the data delivery training set; and training and optimizing the large language model agent including one or more of the following: prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

[0034] Optionally, to address the difficulty in understanding unstructured interface documents, which hinders the automatic extraction of delivery semantics and transformation rules, the document understanding agent 201 can automatically extract calling logic from unstructured interface documents, achieving autonomous understanding of the interface structure and generation of calling templates. The document understanding agent 201 can identify key information such as "required parameters," "return format," and "call path" contained in the document, and automatically construct standardized calling templates (such as RESTful style requests), significantly improving the connector's adaptability to APIs.

[0035] Optionally, to address the delivery chain disruption caused by semantic inconsistencies and structural differences between data provider APIs and data user apps, the semantic mapping agent 202 can automatically perform semantic mapping and parameter conversion between heterogeneous APIs, significantly reducing manual adaptation costs. The semantic mapping agent 202 identifies the semantic equivalence between data product API fields (such as "uid" and "stime") and data application receiving fields (such as "user_id" and "start_time"), and automatically establishes mapping rules based on historical memory, avoiding manual configuration one by one.

[0036] Optionally, to address the lack of intelligent process orchestration capabilities in the data delivery process, which prevents it from adapting to diverse API behaviors and APP requirements, the delivery process generation intelligent agent 204 generates a delivery process control chart that enables intelligent scheduling and access control based on contract rules. This ensures that the data delivery process complies with policy constraints and adapts to diverse API behaviors and APP requirements. The contract analysis intelligent agent 203 can automatically infer feasible scheduling plans by combining contract terms such as "number of accesses," "time window," and "data granularity," and collaborate with the delivery process generation intelligent agent 204 to generate a delivery process control chart, achieving compliant calls according to contracts and avoiding invalid requests.

[0037] Optionally, to address the lack of a multi-agent collaborative mechanism for data delivery scenarios, which hinders the formation of an autonomous adaptive system with learning capabilities, the memory and learning agent 207 can dynamically optimize delivery strategies through memory and learning mechanisms, achieving continuous adaptation and migration generalization across products and API scenarios. The system continuously records task execution history, including call success rate, error messages, and field mapping validity, and reuses similar historical experience in new tasks to generate better prompts or process paths, supporting "few-shot" adaptation and "zero-shot" migration, improving the efficiency and robustness of the system's long-term operation.

[0038] The data space multi-agent delivery engine provided in this disclosure can automatically adapt between the API output of the data provider and the APP input of the data user, as well as intelligent orchestration, execution, and feedback optimization of the data delivery process. The data space multi-agent delivery engine consists of multiple agents that work collaboratively through a multi-agent coordination and scheduling module to complete a closed-loop process from interface document parsing, semantic mapping, contract analysis, process generation, execution control, to feedback learning. Furthermore, the delivery process control diagram clearly defines the entire process from API request to APP input, including field mapping rules, interface protocol conversion, pagination logic processing, call retry mechanism, data format conversion, authentication method insertion, data injection method, etc., and configures contractual restrictions such as call frequency and time window. Under the guidance of the delivery process control diagram, connector B actively schedules connector A to automatically initiate a data request according to the process. After connector A returns data, connector B adjusts the data format to a format acceptable to the data APP according to the field mapping and conversion rules, and injects the data into the corresponding data application, completing the data delivery process. The system records delivery logs throughout the process. In case of execution anomalies, memory and learning agents assist in diagnosis and automatic adjustment of the process to ensure stable, reliable, and compliant data delivery.

[0039] By leveraging the aforementioned multi-agent delivery engine for data space, and introducing the understanding and reasoning capabilities of a large language model and a collaborative autonomous mechanism among multiple agents, the incompatibility issues in semantics, structure, and process between the API output of data providers and the APP input of data users in the data space are systematically resolved. Combined with... Figure 5 As shown, this disclosure provides a data space adaptive data delivery method based on multi-agent systems. The execution entity of this data delivery method can be the processor of a data space multi-agent delivery engine. The multi-agent system includes multiple large language model agents, used to realize adaptive data delivery between the data product API of the data provider and the data APP of the data user in the data space. The data delivery method includes: S501, the processor inputs the unstructured data product API interface document and data APP interface document into the large language model agent to obtain the structured data product API call template and data APP receive template.

[0040] Among them, the data product API call template and the data APP receiving template are used for semantic mapping analysis.

[0041] S502, the processor inputs the data product API call template and the data APP receiving template into the large language model agent, and obtains the mapping conversion file by analyzing the semantic mapping relationship.

[0042] Among them, the mapping transformation file is used for mapping different semantics and structures in data product APIs and data apps.

[0043] S503: The processor inputs the data usage contract signed between the data user and the data provider into the large language model agent to obtain the constraint rule file.

[0044] Among them, the constraint rule file is used to control data access and usage behavior.

[0045] In S504, the processor inputs the mapping transformation file and constraint rule file into the large language model agent, and obtains the delivery process control chart by orchestrating the data delivery process in the data space.

[0046] The S505 processor uses a large language model agent to obtain data from the data product API based on the delivery process control chart and injects the obtained data into the data APP.

[0047] In this embodiment, a large language model agent parses API interface documents and data APP interface documents, automatically extracting calling logic from unstructured interface documents to achieve autonomous understanding of the interface structure. This generates data product API call templates and data APP receiving templates. Then, the large language model agent analyzes semantic mapping relationships, identifies semantic similarities between fields in the two templates, and generates corresponding conversion rules to obtain a mapping conversion file. This enables automatic semantic mapping and parameter conversion between heterogeneous APIs, reducing manual adaptation costs. Furthermore, the large language model agent parses data usage contracts to generate constraint rule files, ensuring that the data delivery process strictly conforms to contract terms. Finally, the delivery process control chart generated by the large language model agent based on the mapping conversion file and rule constraint file automatically adjusts the delivery process to dynamically adapt to interface changes. This solves delivery barriers caused by interface heterogeneity between data provider and data user interfaces, thereby improving the automatic adaptation capability between data product APIs and data APP input interfaces during data delivery in the data space and promoting data circulation and utilization.

[0048] Optionally, the unstructured data product API interface documents and data APP interface documents are input into a large language model agent to obtain structured data product API call templates and data APP receiving templates. This includes: using the large language model agent to perform semantic parsing on the unstructured language in the data product API interface documents and data APP interface documents, and automatically identifying key information based on the semantic parsing results; the key information includes one or more of the following: interface call method, parameter requirements, field structure, and data format; and generating structured data product API call templates and data APP receiving templates based on the key information.

[0049] In this embodiment, the natural language understanding capability of the document understanding agent in the data space multi-agent delivery engine can parse the data product API output interface document and the data APP input interface document, identify the interface call method, parameter requirements, field structure, and data format, extract key information, and generate data product API call templates and data APP receiving templates. The data product API call template and data APP receiving template are unified structured templates, such as JSON format (method, url, params, response), including interface path, parameter format, response structure, etc., for subsequent semantic mapping analysis, and can handle OpenAPI, Markdown, Postman JSON, or natural language descriptions. Through natural language processing technology, the document understanding agent can quickly and accurately extract key information from unstructured documents and generate standardized call and receiving templates, significantly improving development efficiency and system adaptability.

[0050] Optionally, the document understanding agent has one or more of the following functions: semantic parsing and key parameter extraction of the interface specification document; automatic identification of the interface request method, URL path, parameter fields and their types; automatic completion of missing interface field descriptions (such as supplementing URLs and parameter descriptions based on context); and output of structured interface templates (JSON format) for subsequent mapping and invocation.

[0051] Optionally, the document understanding agent supports a Few-shot Prompt mechanism, which prompts the model to generate a standardized structure through a preset "interface extraction instruction template". The Prompt can be: "Please extract the interface path, method, request parameter name and type, and return field name and type from the following API document and construct a JSON structure." For example, for the "City Travel Track API," the API documentation describes the following: the request address is GET / trajectory / list; the parameters are uid (string), start_time (datetime), and end_time (datetime); the response fields are lng, lat, and t. The documentation's understanding agent identifies the calling method, parameter format, and field semantics, and outputs the following structured data product API call template: {"method":"GET", "url":" / trajectory / list", "params":["uid", "start_time", "end_time"], "response":["lng", "lat", "t"]}. This template details the API's calling method (method), URL path (url), request parameters (params), and response fields (response). Here, "GET" indicates a request to retrieve data from the server; " / trajectory / list" specifies the API path, indicating that this API is used to retrieve trajectory data; "uid" represents the user ID, used to identify the user; "start_time" represents the start time, and "end_time" represents the end time, used to specify the time range for the query; "lng" represents the longitude coordinates of the trajectory point, "lat" represents the latitude coordinates of the trajectory point, and "t" represents the time of the trajectory point. Based on this data product API call template, an API interface for retrieving user trajectory data can be identified. Callers can use this interface to retrieve the trajectory records of a specified user within a specific time range. When calling, the user ID, start time, and end time need to be provided as parameters.

[0052] Similarly, for the input interface documentation of a data app, the document understanding agent can generate the following data app receiving template: {"endpoint":" / app / input", "method":"POST", "body":{"user_id":"string", "longitude":"float", "latitude":"float", "timestamp":"datetime"}}. This template details the input interface of the data app, including the endpoint for receiving data, the request method, and the fields and their data types in the request body. " / app / input" specifies the input interface path of the data app, indicating that data will be sent to this path; "POST" indicates that this is a request to send data to the data app; "user_id" represents the user ID, used to identify the user, and its data type is string; "longitude" represents the longitude coordinates of the trajectory point, and its data type is float; "latitude" represents the latitude coordinates of the trajectory point, and its data type is float; "timestamp" represents the time of the trajectory point, and its data type is datetime. Based on the data APP receiving template, a data APP interface for receiving user trajectory data can be identified. The caller can send user trajectory data to the data APP through this interface. When calling, the request body needs to be constructed according to the specified fields and data types.

[0053] Optionally, the document understanding agent's document understanding and template generation capabilities can construct the following automatic parsing chain: natural language document, Prompt template, parameter extraction, type recognition, JSON structure, and semantic template invocation.

[0054] Optionally, generate the data product API call template and data APP receiving template according to the following formula:

[0055]

[0056] Among them, D api and D app These are the data product API interface documentation and the data APP interface documentation, respectively. LLM T is the structure extraction function for document understanding agents. api and T app These are templates for calling data product APIs and receiving data apps, respectively, with the output in JSON format.

[0057] Optionally, the data product API call template and the data APP receiving template are input into a large language model agent. By analyzing the semantic mapping relationship, a mapping conversion file is obtained, including: using the large language model agent to analyze fields with different semantics and structures in the data product API call template and the data APP receiving template, constructing a mapping relationship between API output fields and APP input fields to form a field mapping table; analyzing the mapping conversion logic based on the data in the field mapping table, and automatically generating conversion logic rules; the mapping conversion logic includes one or more of type conversion rules, unit conversion rules, and default value filling; and generating a mapping conversion file based on the field mapping table and the conversion logic rules.

[0058] In this embodiment, the semantic mapping agent in the data space multi-agent delivery engine can analyze fields with different semantics and structures in the data product API call template and the data APP receiving template, establishing a semantic mapping relationship between the data product API output and the data APP input. This mapping relationship supports field-level, structure-level, and semantic-level mapping, forming a field mapping table. Based on the field semantics, type, context, and historical experience in the field mapping table, it can also automatically generate field conversion logic, unit conversion rules, and format adjustment rules, forming conversion logic rules. Finally, a mapping conversion file including the field mapping table and conversion logic rules is output. The mapping conversion file is used for mapping different semantics and structures in the data product API and the data APP.

[0059] Optionally, the semantic mapping agent has one or more of the following functions: using a large language model to perform semantic matching of cross-interface field names, such as user_id and uid; automatically generating conversion rules, including type conversion, unit conversion, default value filling, etc.; and completing the completion (such as default value, derived value) with the help of historical memory when interface fields are missing or semantically ambiguous.

[0060] Optionally, the specific processing details of the semantic mapping agent include: constructing a semantic matching task between field pairs (source_field, target_field), with the input being field name, context description, and field type, and constructing field semantic embedding vectors based on a large language model; performing semantic similarity calculation and structural context matching between field pairs, such as using LLM for embedding comparison or semantic classification matching; utilizing chained hints to improve the reasoning ability of field decomposition (e.g., decomposing location into lng+lat) or field fusion (e.g., merging first_name and last_name into fullname); supporting fuzzy matching (e.g., matching "uid" with "user_id") and structural splitting (e.g., splitting "geo_location" into "longitude" and "latitude"); and unit conversion support (e.g., converting the unit "speed" from km / h to m / s).

[0061] Optionally, the semantic mapping agent supports a Few-shot Prompt mechanism. The Prompt can be: "Match the fields in the data source with the fields in the application and output the corresponding transformation logic. Please consider the meaning, type, and purpose of the fields, and explain the reasoning basis." For example, the semantic mapping agent can identify semantic similarities between fields and generate corresponding rules as follows: {"mappings":{"uid":"user_id","lng":"longitude","lat":"latitude","t":"timestamp"},"conversions":{"t":{"type":"timestamp","format":"ISO-8601"}}}. Here, "mappings" describes the mapping relationship between the output fields of the data provider's API and the input fields of the data user's APP; "uid":"user_id" indicates that the uid field of the data provider is mapped to the user_id field of the data user; "lng":"longitude" indicates that the lng field of the data provider is mapped to the longitude field of the data user; "lat":"latitude" indicates that the lat field of the data provider is mapped to the latitude field of the data user; "t":"timestamp" indicates that the t field of the data provider is mapped to the timestamp field of the data user; "conversions" describes the data conversion logic that needs to be performed, especially the conversion of field types and formats; "timestamp" specifies that field t is a timestamp field, and "ISO-8601" specifies that the format of field t is a date and time string of the ISO 8601 standard.

[0062] In actual data delivery, the field naming, structure, and parameter format of the data provider's data product API often differ significantly from the data user's APP receiving interface. For example, the data product API fields might be uid, uname, and access_time, while the data APP requires userId, username, and timestamp fields. Through semantic mapping intelligent agents, semantic-level automatic mapping generation, updating, and repair can be achieved, significantly reducing configuration costs and improving the adaptability to heterogeneous interfaces.

[0063] Optionally, the semantic mapping agent generates mapping rules based on a cross-interface semantic mapping function. The cross-interface semantic mapping function is:

[0064] Where Match indicates that two fields form a mapping, f api，i f is an output field of the data provider's data product API. app，jS is the input field of the data user's data APP, E is the semantic embedding of the field generated by the semantic mapping agent, cosine is the cosine similarity between two embedding vectors, which measures the semantic closeness of two fields in the semantic space, ranging from [-1, 1], and S is the input field of the data user's data APP. i S j α represents the context path of the field in the original structure (such as JSON path, parent node), and Sim represents the context position similarity of the field in the original data structure. It can be calculated based on path overlap, field co-occurrence frequency, parent node semantics, etc. α and β are the weights for adjusting semantic and structural similarity.

[0065] For example, given that "the field 'uname' in the API documentation represents the user's name," the large model can infer, through hints and context, that it should be mapped to the APP's field 'username', and automatically generate the following mapping rule: {"uname":"username"}. This indicates that the data provider field "uname" is mapped to the data user field "username".

[0066] Optionally, the data usage contract signed between the data user and the data provider is input into the large language model agent to obtain a constraint rule file, including: using the large language model agent to analyze the usage restriction clauses in the data usage contract; the usage restriction clauses include one or more of the following: access frequency, time window, field range, usage restrictions, and data retention strategy; and generating a constraint rule file based on the usage restriction clauses.

[0067] In this embodiment, the contract analysis agent in the data space multi-agent delivery engine can identify usage restriction clauses in the data usage contract, such as access frequency, time window, field range, usage restrictions, and data retention strategy, and generate access plans and quota policies. Based on the content of the data contract, the interface call frequency, timeliness, and permissions are scheduled and restricted, and a constraint rule file is generated for subsequent delivery scheduling, that is, a set of structured call restriction rules and scheduling strategies, which is used to control data access and usage behavior.

[0068] Optionally, the contract analysis agent has one or more of the following functions: parsing the terms in the contract document to extract access counts, call durations, usage permissions, data item restrictions, etc.; collaborating with the delivery process generation agent to determine the delivery frequency and lifecycle; and providing policy checks and restriction verification during the call execution phase.

[0069] Optionally, the contract analysis agent supports a Few-shot Prompt mechanism. The Prompt can be: "Extract call frequency limits, start and end times, available data fields, and prohibited uses from the following contracts, and convert them into structured JSON." For example, for a contract that states "maximum of 300 calls per day; limited to weekdays 08:00-18:00; valid from January 1, 2025 to January 31, 2025," the contract analysis agent can generate the following constraint rule file: {"max_calls_per_day":300, "allowed_time_range":["08:00", "18:00"], "validity":{"start":"2025-01-01", "end":"2025-01-31"}}. Here, "max_calls_per_day" represents the maximum number of calls allowed per day; "allowed_time_range" represents the allowed time range for calls; "validity" represents the contract's validity period; "start" represents the contract's start date; and "end" represents the contract's end date.

[0070] Optionally, the mapping transformation file and constraint rule file are input into the large language model agent, and a delivery process control chart is obtained by orchestrating the data delivery process in the data space. This includes: using the large language model agent to analyze the mapping transformation file and constraint rule file, and orchestrating the data delivery process based on the analysis results to generate process control logic; and constructing the delivery process control chart based on the process control logic.

[0071] In this embodiment, the delivery process in the data space multi-agent delivery engine generates agents that can parse mapping conversion files and contract rule files. Combining API call patterns and APP structure requirements, it considers process control logic such as request order, call dependencies, pagination logic, authentication processing, and error retries to plan and generate an end-to-end data delivery process, which is then represented using a delivery process control diagram.

[0072] Optionally, the delivery process control diagram includes strategy nodes and transformation nodes.

[0073] In this embodiment, the delivery process control diagram is a directed graph structure, which includes request order, branch logic and control nodes, and shows data flow, transformation nodes, strategy nodes, terminal nodes, etc.

[0074] Optionally, the delivery process generation agent has one or more of the following functions: constructing process control logic considering contract strategies, parameter dependencies, and pagination mechanisms; handling complex scenarios such as multiple API combinations, incremental updates, multiple rounds of requests, and error retries; and outputting a standardized delivery plan format for use by the execution control agent.

[0075] Optionally, the delivery process generation agent supports a Few-shot Prompt mechanism. The Prompt can be: "Based on the following mapping transformation file and constraint rule file, design a complete process including parameter preparation, API pagination requests, data transformation, structure reconstruction, and data injection." For example, the logical nodes of the generated delivery process control diagram are: [Initialize call parameters], [Get paginated data / trajectory / list], [Field transformation and structure reconstruction], [POST to / app / input], [Log and contract limit update]. The delivery process control diagram supports control logic such as conditional judgment, pagination traversal, asynchronous requests, and retry mechanisms, and can be displayed to data users through a graphical interface.

[0076] Alternatively, the delivery process control chart can be represented by the following formula:

[0077] Where DCG is the delivery process control diagram, N is the set of process nodes, such as data request, field mapping, pagination processing, data injection, etc., E is the set of execution order edges between nodes, and op k For operation type, param k For parameter input of node operations, cond k For conditional judgments (such as pagination continuation conditions, contract restriction conditions).

[0078] In the Delivery Control Flowchart (DCG), each node represents an API call, judgment, transformation, or other operation. For example, "calling / submitJob" means obtaining the jobId; "polling / getResult?jobId=" means checking the result status; and "getting the data[] field" means transforming the structure and writing it to the APP interface.

[0079] Optionally, the delivery process generation agent generates a delivery process control diagram based on the mapping and transformation file (including field mapping tables and transformation logic rules) and the constraint rule file according to the following formula:

[0080] Among them, FieldMap is the field mapping table, TransformRules is the transformation logic rule, and ContractConstraintSet is the constraint rule file.

[0081] Optionally, the generation of the delivery process control chart follows the following automatic planning mechanism: parsing key fields in the API documentation (such as jobId in the response); identifying dependencies (such as the result query depending on the return value of the submitted task); and constructing a process control chart with conditional branches and loops.

[0082] Optionally, if a process error occurs during the invocation of the delivery process control chart (such as missing pagination fields or changes in response structure), the execution control agent can retrieve historical successful delivery examples and perform Few-shot migration repair to achieve autonomous recovery and evolution optimization of the process.

[0083] Optionally, the large language model agent is used to obtain data from the data product API according to the delivery process control diagram, and the obtained data is injected into the data APP. This includes: using the large language model agent to execute the delivery process control diagram, calling the data product API according to the strategy nodes in the delivery process control diagram to obtain the raw data, and performing data field transformation on the raw data according to the transformation nodes in the delivery process control diagram to obtain the target data that the data APP is expected to receive; and injecting the target data into the data APP receiving interface.

[0084] In this embodiment, the execution control agent in the data space multi-agent delivery engine can execute specific API calls, data conversions and result transmissions according to the delivery process control diagram and the delivery process. It also has the ability to track tasks and provide status feedback, and records delivery results (such as delivery status, delivery data and delivery logs).

[0085] Optionally, the execution control agent has one or more of the following functions: managing the state and lifecycle of data delivery tasks (start, pause, retry, terminate); supporting authentication mechanisms such as token injection, signature verification, session maintenance, etc.; supporting failure recovery mechanisms (such as retry, rollback), and collaborating with memory and learning agents to update experience.

[0086] Optionally, after generating the delivery process control chart, the delivery process control chart is confirmed, specifically including: visually presenting the delivery process control chart to the data user and obtaining feedback from the data user on the delivery process control chart; readjusting the process of generating the delivery process control chart based on the feedback information, and controlling the large language model agent to regenerate the delivery process control chart based on the adjusted process.

[0087] In this embodiment, after generating the delivery process control chart (DPC), the DPC is visualized and presented to the data user through the multi-agent coordination and scheduling module in the data space multi-agent delivery engine. This visualization is used for "manual review" and "strategy review" of the delivery process. If the data user discovers an anomaly (e.g., incorrect field mapping, mismatched data granularity), the system will report the problem to the corresponding agent through the multi-agent coordination and scheduling module, triggering a local intelligent update to adjust the process for generating the DPC. The DPC is then re-output and confirmed. This process can optimize the process structure through multiple rounds of question-and-answer sessions, such as "The current process does not consider nextToken for pagination; please complete it."

[0088] Optionally, the multi-agent coordination and scheduling module can coordinate communication and task assignment among agents, output agent scheduling command streams, global task execution plans, and task log audit reports to ensure process continuity and state consistency.

[0089] Optionally, the multi-agent coordination and scheduling module has one or more of the following functions: controlling the execution flow order (e.g., parsing the document first, then matching the mapping, then planning the process, and then executing); managing cross-agent communication protocols (based on message queues / event streams); tracking task status, recording logs, and generating auditable reports; supporting human-machine collaboration interfaces and accepting intervention prompts from administrators or developers.

[0090] Optionally, the large language model agent is trained and optimized based on previous data delivery tasks. Specifically, this includes: collecting historical task information during the data delivery process; historical task information includes one or more of the following: task execution logs, field adaptation effects, user feedback, and exception information; constructing a data delivery training set based on the historical task information; training and optimizing the large language model agent based on the data delivery training set; and training and optimizing the large language model agent includes one or more of the following: prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

[0091] In this embodiment, the memory and learning agents in the data space multi-agent delivery engine can collect historical task information, including task execution logs, field adaptation effects, user feedback, and anomaly information, thereby constructing a data delivery training set. Based on this training set, the large language model agent is trained and optimized to improve future tasks. Furthermore, the memory and learning agents are also used to store, manage, and replay historical task experiences, i.e., interface, parameter, mapping, process, and execution log information from each task execution, providing optimization suggestions, similar task matching results, or prompt enhancements to other agents, offering enhanced prompts and rapid migration support.

[0092] Optionally, the memory and learning agent has one or more of the following functions: storing parameter mappings, flowcharts, call statuses and exception information of completed tasks; forming a task knowledge graph to support similar task matching and prompt optimization; and driving each agent to perform prompt reinforcement or fine-tuning.

[0093] Optionally, the specific processing details of the memory and learning agent include: constructing a field mapping knowledge graph; providing Prompt optimization suggestions for new tasks, using LLM combined with historical records to generate prompt templates for enhancement, enabling other agents to quickly adapt in similar scenarios; optimizing large language model instruction templates based on the knowledge graph to guide Prompt selection and instruction combination generation; supporting fine-tuning or parameter adaptation methods to perform domain adaptation for high-frequency interfaces or specific industry terminology scenarios; and migrating mapping experience across tasks (such as merging user_id, uid, and userid into synonymous field families).

[0094] For example, if the matching results of lng and longitude appear in multiple tasks, the memory and learning agent can automatically upgrade the mapping to a high-confidence rule and give it priority recommendation.

[0095] Optionally, the memory and learning agent continuously records interface adaptation history, field mapping records, and call path generation, and constructs a data delivery knowledge graph according to the following formula:

[0096] Where K represents the data delivery knowledge graph, and API i For data providers, this is the output interface documentation for their data product APIs, and the APP. j FieldMap is the interface documentation for receiving data from data users' apps. ij DCG is a field mapping scheme generated by a semantic mapping agent. ij For the automatically generated delivery process control chart, Feedback ij This includes structured interactive feedback such as actual call logs, error feedback, and user ratings.

[0097] In this embodiment, the data delivery knowledge graph is managed by a memory and learning agent and features memory enhancement, transfer generalization, and proactive error correction. Memory enhancement refers to using mappings and processes of similar tasks in K as few-shot examples when adapting to new interfaces to improve understanding and generation accuracy. Transfer generalization refers to continuously updating parameters through an online learning mechanism, making it more efficient when adapting to similar interfaces in the future, supporting migration from a first platform behavior data API to a second platform behavior data API, even if the field names are different. Proactive error correction refers to the agent automatically comparing successful and failed flowcharts and mapping logic after multiple delivery failures to infer the cause of the error and achieve self-correction.

[0098] For example, a user app that had successfully adapted to the "City Traffic Congestion Index API" was able to directly migrate its existing Map and Flow when it integrated the "Highway Congestion Prediction API." This allowed the system to recognize the semantic similarity of the two fields (e.g., city_name vs. region_name, congestion_rate vs. traffic_score), requiring only minor adjustments for successful delivery on the first call and significantly reducing cold start costs. Furthermore, a fine-tuning strategy was employed to continuously refine the domain-specific data interface documentation and delivery logs for each agent, optimizing its understanding and reasoning capabilities for data space delivery tasks. This enabled the system to evolve and continuously improve over the long term.

[0099] The data space adaptive data delivery method and apparatus based on multi-agent systems provided in this disclosure enable each agent in the data space multi-agent delivery engine to complete model inference tasks through a unified LLM call interface (which can connect to local model services or cloud APIs). Each agent maintains an independent Prompt policy and prompt template. During execution, cross-validation and model feedback mechanisms are supported, with multiple candidate results voting to determine the mapping or process path. The various agent modules collaborate to build a semantic closed loop from API to APP, an adaptive delivery process, policy constraint parsing, and task memory feedback mechanism between connectors, achieving efficient, stable, low-code, and transferable data delivery for the data space. The data space multi-agent delivery engine integrates the semantic understanding, natural language processing, and contextual reasoning capabilities of large language models with the task division and collaboration, autonomous learning, and evolution mechanisms of multi-agent systems, achieving technological improvements in areas such as automatic adaptation of heterogeneous interfaces between data product APIs and data APPs, complex process orchestration, document-driven parsing, and knowledge transfer generalization.

[0100] Combination Figure 6As shown, this disclosure provides a multi-agent-based adaptive data delivery device 600, including a processor 601 and a memory 602. Optionally, the device may further include a communication interface 603 and a bus 604. The processor 601, communication interface 603, and memory 602 can communicate with each other via the bus 604. The communication interface 603 can be used for information transmission. The processor 601 can call logical instructions in the memory 602 to execute the multi-agent-based adaptive data delivery method described in the above embodiments.

[0101] Furthermore, the logic instructions in the aforementioned memory 602 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0102] The memory 602, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 601 executes functional applications and data processing by running the program instructions / modules stored in the memory 602, thereby realizing the data space adaptive data delivery method based on multi-agent systems in the above embodiments.

[0103] The memory 602 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 602 may include high-speed random access memory and may also include non-volatile memory.

[0104] This disclosure provides an electronic device, including: an electronic device body, and the aforementioned multi-agent-based adaptive data delivery device. The multi-agent-based adaptive data delivery device is installed on the electronic device body. The installation relationship described herein is not limited to placement within the electronic device, but also includes installation connections with other components of the electronic device, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the multi-agent-based adaptive data delivery device can be adapted to feasible electronic device bodies, thereby realizing other feasible embodiments.

[0105] This disclosure provides a computer-readable storage medium storing computer-executable instructions configured to execute the above-described multi-agent-based data space adaptive data delivery method.

[0106] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.

[0107] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the technical solutions described herein. As used in the technical solutions described herein, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used herein refers to any and all possible combinations of one or more of the associated listed elements. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0108] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0109] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A data space adaptive data delivery method based on multi-agent systems, characterized in that, The multi-agent system comprises multiple large language model agents, used to achieve adaptive data delivery between data provider's data product API and data user's data APP in the data space. The data delivery method includes: The unstructured data product API interface document and data APP interface document are input into the large language model agent to obtain the structured data product API call template and data APP receiving template; the data product API call template and data APP receiving template are used for semantic mapping analysis; The data product API call template and data APP receiving template are input into the large language model agent. By analyzing the semantic mapping relationship, a mapping conversion file is obtained. The mapping conversion file is used for mapping different semantics and structures in the data product API and data APP. The data usage contract signed between the data user and the data provider is input into the large language model agent to obtain a constraint rule file; the constraint rule file is used to control data access and usage behavior. The mapping transformation file and constraint rule file are input into the large language model agent, and a delivery process control chart is obtained by arranging the data delivery process in the data space. The large language model agent uses the delivery process control chart to obtain data from the data product API and injects the obtained data into the data APP.

2. The data delivery method according to claim 1, characterized in that, Inputting the unstructured data product API interface documents and data APP interface documents into the large language model agent yields structured data product API call templates and data APP receiving templates, including: The large language model agent is used to perform semantic parsing on the unstructured language in the data product API interface document and the data APP interface document, and automatically identify key information based on the semantic parsing results; the key information includes one or more of the following: interface calling method, parameter requirements, field structure, and data format; Based on the key information, the structured data product API call template and data APP receiving template are generated respectively.

3. The data delivery method according to claim 1, characterized in that, The data product API call template and data APP receiving template are input into the large language model agent. By analyzing the semantic mapping relationship, a mapping conversion file is obtained, including: The large language model agent is used to analyze fields with different semantics and structures in the data product API call template and data APP receiving template, and to construct a mapping relationship between API output fields and APP input fields, forming a field mapping table; Based on the data analysis of the field mapping table, the mapping conversion logic is automatically generated, and conversion logic rules are automatically generated; the mapping conversion logic includes one or more of the following: type conversion rules, unit conversion rules, and default value filling. Based on the field mapping table and conversion logic rules, a mapping conversion file is generated.

4. The data delivery method according to claim 1, characterized in that, Input the data usage contract signed between the data user and the data provider into the large language model agent to obtain a constraint rule file, including: The large language model agent is used to analyze the usage restriction clauses in the data usage contract; the usage restriction clauses include one or more of the following: access frequency, time window, field range, usage restrictions, and data retention strategy; The constraint rule file is generated based on the aforementioned usage restriction terms.

5. The data delivery method according to claim 1, characterized in that, The mapping transformation file and constraint rule file are input into the large language model agent. By orchestrating the data delivery process in the data space, a delivery process control chart is obtained, including: The large language model agent is used to analyze the mapping transformation file and constraint rule file, and the data delivery process is arranged and the process control logic is generated based on the analysis results. Based on the process control logic, construct the delivery process control diagram.

6. The data delivery method according to claim 1, characterized in that, The delivery process control diagram includes strategy nodes and transformation nodes; the large language model agent uses the delivery process control diagram to obtain data from the data product API and injects the obtained data into the data APP, including: The large language model agent executes the delivery process control diagram, calls the data product API according to the strategy node in the delivery process control diagram to obtain raw data, and performs data field transformation on the raw data according to the transformation node in the delivery process control diagram to obtain the target data that the data APP expects to receive. Inject the target data into the data APP receiving interface.

7. The data delivery method according to any one of claims 1 to 6, characterized in that, After generating the delivery process control diagram, the delivery process control diagram is verified, specifically including: Present the delivery process control chart to data users in a visual manner and obtain feedback from data users regarding the delivery process control chart; Based on the feedback information, the process for generating the delivery process control chart is readjusted, and the large language model agent is controlled to regenerate the delivery process control chart according to the adjusted process.

8. The data delivery method according to any one of claims 1 to 6, characterized in that, Based on previous data delivery tasks, the large language model agent is trained and optimized, specifically including: Collect historical task information during the data delivery process; the historical task information includes one or more of the following: task execution logs, field adaptation effects, user feedback, and exception information; A data delivery training set is constructed based on the historical task information; The large language model agent is trained and optimized based on the training set delivered by the data; the training and optimization of the large language model agent includes one or more of the following: prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

9. A data space adaptive data delivery device based on multi-agent systems, characterized in that, The multi-agent system includes multiple large language model agents, used to achieve adaptive data delivery between data product APIs of data providers and data APPs of data users in the data space. The data delivery device includes: A document understanding agent is used to input unstructured data product API interface documents and data APP interface documents into the large language model agent to obtain structured data product API call templates and data APP receiving templates; the data product API call templates and data APP receiving templates are used for semantic mapping analysis; A semantic mapping agent is used to input the data product API call template and the data APP receiving template into the large language model agent, and obtain a mapping conversion file by analyzing the semantic mapping relationship; the mapping conversion file is used for mapping different semantics and structures in the data product API and the data APP. A contract analysis agent is used to input the data usage contract signed between the data user and the data provider into the large language model agent to obtain a constraint rule file; the constraint rule file is used to control data access and usage behavior. A delivery process generation agent is used to input the mapping transformation file and constraint rule file into the large language model agent, and obtain a delivery process control chart by arranging the data delivery process in the data space; An execution control agent is used to obtain data from the data product API based on the delivery process control chart using the large language model agent, and inject the obtained data into the data APP.

10. The data delivery apparatus according to claim 9, characterized in that, Also includes: The multi-agent coordination and scheduling module is used to confirm the delivery process control diagram after it is generated. Specifically, it includes: visually displaying the delivery process control diagram to the data user and obtaining feedback information from the data user regarding the delivery process control diagram; readjusting the process of generating the delivery process control diagram based on the feedback information; and controlling the large language model agent to regenerate the delivery process control diagram based on the adjusted process. A memory and learning agent is used to train and optimize the large language model agent based on previous data delivery tasks. Specifically, this includes: collecting historical task information during the data delivery process; the historical task information includes one or more of the following: task execution logs, field adaptation effects, user feedback, and exception information; constructing a data delivery training set based on the historical task information; and training and optimizing the large language model agent based on the data delivery training set. The training and optimization of the large language model agent includes one or more of the following: prompt word template enhancement, fine-tuning, parameter adaptation, and transfer learning.

11. A multi-agent-based spatial adaptive data delivery device, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute, when running the program instructions, the data space adaptive data delivery method based on any one of claims 1 to 8.

Images