Data visualization method based on agent coordination architecture and agent

Abstract

The application relates to the technical field of visualization, and specifically provides a data visualization method based on an Agent collaborative architecture and an intelligent agent, which comprises the following steps: obtaining a user natural language query, calling a demand analysis tool to perform intent recognition, entity extraction and demand classification, and outputting a demand analysis result containing an intent label, a demand type label and target data information; loading a corresponding process template according to the intent label and the demand type label, generating and executing a tool calling chain, sequentially calling a query tool to obtain target data, calling a special analyzer corresponding to the demand type label to perform directional data analysis, and calling a visualization engine to generate and render a visualization chart. The application realizes full-link automation from natural language to professional visualization charts, significantly improves data analysis efficiency and user experience through process state sensing and intelligent scheduling.

Description

Technical Field

[0001] This invention belongs to the field of visualization technology, specifically relating to a data visualization method and intelligent agent based on an agent collaborative architecture. Background Technology

[0002] Traditional data visualization workflows typically rely heavily on manual operations. After a user submits an analysis request, the data analyst must manually complete a series of tedious steps: understanding the requirements, writing SQL queries to retrieve data, performing data cleaning and calculations using Excel or Python, selecting the appropriate chart type, adjusting style parameters, and finally generating the chart. This process is not only time-consuming but also requires users to possess business understanding, data processing, and visualization expertise simultaneously, making it extremely challenging for users without a technical background.

[0003] While some existing automation tools can generate charts based on instructions, most can only handle simple, single-type queries and lack a deep understanding of user intent. More importantly, these tools employ fixed, linear processes, failing to perceive the current task's execution status. When users request modifications (such as adjusting styles or replacing data), the entire process often needs to be re-executed from scratch, resulting in low efficiency. Furthermore, existing tools lack the ability to differentiate between different analysis types (such as trend analysis, compositional comparison, and geospatial analysis), making it difficult to provide visualization results that conform to domain best practices. Summary of the Invention

[0004] To address the aforementioned shortcomings of existing technologies, this invention provides a data visualization method and intelligent agent based on an agent-based collaborative architecture to solve the aforementioned technical problems.

[0005] In a first aspect, the present invention provides a data visualization method based on an agent-based collaborative architecture, comprising: The system obtains the user's natural language query, calls the requirement parsing tool to perform intent recognition, entity extraction and requirement classification on the user's natural language query, and outputs the requirement analysis results, which include intent tags, requirement type tags and target data information. Load the corresponding process template based on the intent tag and the requirement type tag. The process template defines the order in which multiple tools are called. Based on the process template, the requirement type label, and the status context of the current query task, a tool call chain is generated and executed. The tool call chain is used to sequentially call multiple tools, including a query tool, an analyzer, and a visualization engine for obtaining target data based on the target data information. The process of executing the tool call chain includes: calling the query tool to obtain target data; calling the analyzer to perform targeted data analysis on the obtained target data to generate processed data after analysis; and calling the visualization engine to generate and render visualization charts based on the requirement type label and the processed data.

[0006] In an optional implementation, a requirement analysis tool is invoked to perform intent recognition, entity extraction, and requirement classification on the user's natural language query, outputting requirement analysis results, including: A large language model is employed, and through a pre-defined prompt word engineering process, the large language model outputs structured parsing results; the structured parsing results include at least: Intent tags are used to characterize the purpose category of a user's query, which includes generating a new chart, modifying a chart style, or modifying chart data. The entity list is used to represent the target data information, which includes data indicators, time ranges, dimension fields and filtering conditions extracted from the query; The request type label is used to characterize the analysis type to which the user query belongs, and the analysis type is selected from a predefined set of analysis types.

[0007] In one optional implementation, the predefined set of analysis types includes: trend analysis, composition and comparison, distribution and relationship, geospatial analysis, and hierarchical and process analysis.

[0008] In an optional implementation, the corresponding process template is loaded based on the intent tag and the requirement type tag, including: Based on the intent tag, determine the complexity type of the process template: if the intent tag is to generate a new chart, load a complete process template that includes data query, data analysis, and visualization generation stages; if the intent tag is to modify the chart style, load a partial process template that only includes the visualization regeneration stage; if the intent tag is to modify the chart data, load a partial process template that includes at least the data query stage and subsequent analysis and visualization stages. Based on the requirement type tag, load the analysis stage sub-template corresponding to the requirement type tag, which is used to call the analyzer, from the process template with determined complexity.

[0009] In an optional implementation, based on the requirement type tag, from the process template with determined complexity, a sub-template for calling the analyzer, corresponding to the requirement type tag, is loaded, including: When the demand type label is trend analysis type, load the analysis phase sub-template that includes calling the trend analyzer; the trend analyzer is used to perform resampling, moving average calculation and change point detection on time series data; When the requirement type label is composition and comparison, an analysis phase sub-template containing a call to the composition analyzer is loaded; the composition analyzer is used to perform grouping aggregation, percentage calculation and Pareto sorting on the categorized data. When the requirement type label is distribution and relational, an analysis phase sub-template containing a call to the distribution analyzer is loaded; the distribution analyzer is used to perform descriptive statistics, correlation calculations, and cluster analysis on continuous variables; When the demand type tag is geospatial, an analysis phase sub-template containing a call to the geospatial analyzer is loaded; the geospatial analyzer is used to perform geocoding, spatial aggregation, and heat calculation on geographic names. When the requirement type label is hierarchical and process-oriented, an analysis stage sub-template containing a call to the process analyzer is loaded; the process analyzer is used to perform hierarchical aggregation or conversion rate calculation.

[0010] In one alternative implementation, the method for generating tool call chains includes: Obtain the state context, which is maintained by the state management and context module, and includes at least the current processing stage identifier and snapshots of the processing results of each completed stage; Based on the order of the processing stages defined in the process template and the requirement type label, determine the tool instance to be invoked and the source of the input parameters for the tool instance for each processing stage in sequence; Based on the tool instance to be invoked and the source of the input parameters of the tool instance determined for each processing stage, a tool invocation instruction corresponding to each processing stage is generated; the tool invocation instruction includes at least: the identifier of the tool to be invoked, the acquisition path of the input parameters, and the storage location of the output results; The tool call instructions corresponding to each processing stage are assembled into an ordered tool call chain according to the aforementioned sequence.

[0011] In one alternative implementation, the method for executing the tool call chain includes: Each tool call instruction is executed sequentially according to the order of the tool call chain; For the currently executed tool invocation command, extract the corresponding data from the state context according to the acquisition path of the input parameters, and construct the invocation parameters; Based on the tool identifier to be invoked, match and invoke the corresponding tool instance from the tool registry directory; Receive the execution result returned by the tool instance, and store the execution result as a snapshot of the processing result in the state context according to the storage location of the output result; Update the current processing stage identifier recorded in the state context, and continue executing the next tool invocation instruction until all instructions in the tool invocation chain have been executed.

[0012] In an optional implementation, the execution of the tool call chain also includes an exception handling mechanism: Monitor the execution status of each tool invocation command; When the execution of the current tool call command fails, obtain the error message. According to the preset error handling strategy, perform one or a combination of the following error handling operations: re-execute the current tool invocation instruction; invoke a backup tool instance with the same capability label to replace the current tool; terminate the execution of the entire tool invocation chain and provide feedback of the error information to the user; The error information and the error handling operation performed are recorded in the state context.

[0013] In an optional implementation, a visualization engine is invoked to generate and render a visualization chart based on the requirement type label and the processed data, including: Based on the requirement type label, query the preset mapping table between requirement type and chart type to determine the preferred chart type corresponding to the requirement type label; The data fields in the processed data are mapped to the visual channels of the preferred chart type to generate a base chart, wherein the visual channels include axes, colors, and sizes; Based on the style parameters or default configurations in the requirements analysis results, set the style attributes and interactive functions of the basic chart to generate the chart configuration; The chart configuration is optimized for readability, including axis label formatting, category axis anti-overlap, and data point downsampling. Output the optimized chart configuration object and pass the chart configuration object to the front-end rendering tool for display.

[0014] In a second aspect, the present invention provides a data visualization intelligent agent, comprising: The user interaction layer is used to receive natural language queries from users. The Agent core scheduling layer includes: The task understanding and classification module is used to call the requirement parsing tool to perform intent recognition, entity extraction, and requirement classification on the user's natural language query, and output the requirement analysis results; the requirement analysis results include intent tags, requirement type tags, and target data information. The state management and context module is used to maintain the state context of the current query task. The state context includes at least the current processing stage identifier and snapshots of the processing results of each completed stage. The tool coordination and execution engine is used to load the corresponding process template according to the intent tag and the requirement type tag, and to generate and execute the tool call chain according to the process template, the requirement type tag and the state context; the process template defines the order in which multiple tools are called. The specialized tools layer includes: A query tool is used to obtain target data based on the target data information; Multiple analyzers, each corresponding to a demand type label, are used to perform targeted data analysis on the acquired target data and generate analyzed and processed data; A visualization engine is used to generate and render visualization charts based on the required type labels and the processed data.

[0015] Thirdly, a device is provided, comprising: Memory, used to store data visualization programs based on the Agent-based collaborative architecture; A processor is configured to implement the steps of the agent-based collaborative architecture data visualization method provided in the first aspect when executing the agent-based collaborative architecture data visualization program.

[0016] Fourthly, a computer-readable medium is provided, on which a data visualization program based on an agent-based collaborative architecture is stored, wherein when the data visualization program based on an agent-based collaborative architecture is executed by a processor, the steps of the data visualization method based on an agent-based collaborative architecture provided in the first aspect are implemented.

[0017] The beneficial effects of this invention lie in the fact that the agent-based collaborative architecture-based data visualization method and intelligent agent provided by this invention achieve full-process automation from user natural language queries to professional visualization charts, without any manual intervention, significantly improving data analysis efficiency. Users only need to input their business questions, and the intelligent agent can automatically complete intent understanding, data acquisition, targeted analysis, and chart rendering, compressing what originally required hours of manual operation to a response time of seconds. Simultaneously, through state awareness and intelligent scheduling mechanisms, this invention can perceive the current stage of the process and historical interaction information. When users provide feedback for modifications, it intelligently distinguishes between style adjustments and data changes, performing only necessary partial updates or precise backtracking, avoiding the resource waste of "restarting from scratch" in traditional methods. Furthermore, by building-in process templates for different analysis types, it can automatically adapt dedicated analyzers and chart types to different needs such as trends, composition, and distribution, ensuring the accuracy and professionalism of the output results. This invention effectively lowers the technical threshold for data visualization, enabling non-professional users to obtain an analyst-level analysis experience. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0020] Figure 2 This is a flowchart of the tool call chain for generating a method according to an embodiment of the present invention.

[0021] Figure 3 This is a flowchart of the execution tool call chain of a method according to an embodiment of the present invention.

[0022] Figure 4 This is a schematic block diagram of an intelligent agent according to an embodiment of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0025] The data visualization method based on agent collaborative architecture provided in this embodiment of the invention is executed by a computer device, and correspondingly, the data visualization intelligent agent based on agent collaborative architecture runs in the computer device.

[0026] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a data visualization intelligent agent. Depending on different needs, the order of steps in this flowchart can be changed, and some can be omitted.

[0027] like Figure 1 As shown, the method includes: S1. Obtain the user's natural language query, call the requirement parsing tool to perform intent recognition, entity extraction and requirement classification on the user's natural language query, and output the requirement analysis results, which include intent tags, requirement type tags and target data information; S2. Load the corresponding process template according to the intent tag and the requirement type tag. The process template defines the order in which multiple tools are called. S3. Generate and execute a tool call chain based on the process template, the requirement type label, and the status context of the current query task. The tool call chain is used to sequentially call multiple tools, including a query tool, an analyzer, and a visualization engine for obtaining target data based on the target data information. The process of executing the tool call chain includes: calling the query tool to obtain target data; calling the analyzer to perform targeted data analysis on the obtained target data to generate processed data after analysis; and calling the visualization engine to generate and render visualization charts based on the requirement type label and the processed data.

[0028] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0029] S101. Receiving and transmitting user queries Users input natural language queries through the interaction layer (such as front-end dialog boxes or API interfaces), for example: "Show the sales trends of XX district in each quarter of 2024". The interaction layer passes this query to the task understanding and classification module in the Agent core scheduling layer in the form of an HTTP request or function parameters.

[0030] The task understanding and classification module serves as the entry point to the scheduling layer, responsible for initiating the entire parsing process. Internally, this module maintains a reference to a requirement parsing tool, which is typically encapsulated as a standalone microservice, cloud function, or local library.

[0031] S102. Preparation for calling the requirements analysis tool Before calling the requirements analysis tool, the task understanding and classification module needs to complete the following preparatory work: Build tool call request: Create a request object containing the user's query text, along with necessary metadata (such as session ID, timestamp).

[0032] Load prompt word template: Reads a predefined prompt word template from the configuration center or a local file. The template contains role definitions, task instructions, output format constraints, and examples.

[0033] Inject user query: Fill the placeholders in the prompt word template with the user query text to form a complete model input.

[0034] S103. Call the requirements analysis tool The task understanding and classification module calls the requirement analysis tool through a predefined interface. The call can be a synchronous blocking call (waiting for the result to return) or an asynchronous callback. This embodiment uses a synchronous call to simplify the process.

[0035] After receiving the request, the requirement analysis tool executes the following logic internally: Load large language models: Initialize or reuse connected LLM instances (such as OpenAI API, locally deployed Llama models).

[0036] Assemble the final prompt: Fill in the query from the request into the corresponding template to generate the complete prompt string.

[0037] Calling LLM: Send the prompt words to the large language model, set the temperature parameter to 0 (to ensure output stability), and specify the response format as JSON.

[0038] Parse LLM output: Receive the text returned by the LLM and parse it into a Python dictionary or a Java Map object.

[0039] Verify structural integrity: Check if required fields such as intent, analysis_type, and entities are included; if missing, attempt to correct them or return an error.

[0040] S104. Return to Requirements Analysis Results The requirement analysis tool returns the validated structured results to the task understanding and classification module. An example of the returned data structure is shown below: {“intent”: “generate_chart”,“analysis_type”: [“trend_analysis”],“entities”: {“metrics”: [“sales”],“dimensions”: [“region”, “quarter”],“time_range”: “2024”,“filters”: {“region”: “XX district”}},“confidence”: 0.96}. in: The intent label represents the category of the user's purpose; in this example, it is "generate a new chart". The demand type label (analysis_type) represents the analysis type; in this example, it is "trend analysis". The target data information (entities) includes indicators, dimensions, time range, and filtering criteria.

[0041] S105. Subsequent transmission of parsing results Upon receiving the structured result, the task understanding and classification module immediately passes it as a requirement analysis result to the state management and context module, stores it in the session context, and triggers the state machine to enter the next stage (DATA_QUERYING). Simultaneously, this result is also used by the tool coordination and execution engine when loading process templates.

[0042] S106. Exception Handling If the requirement analysis tool fails to be invoked (e.g., LLM service timeout, output format not meeting requirements), the task understanding and classification module will capture the exception and handle it according to the preset strategy: it can choose to retry (up to 3 times), return the default result, or return an error message to the user.

[0043] The core function of the demand parsing tool described in this invention is to convert user-input natural language queries into structured machine-readable instructions. In this embodiment, a Large Language Model (LLM) combined with pre-defined prompt engineering is used to achieve this conversion.

[0044] 1. Design of prompt word project To achieve accurate parsing of user queries, this invention pre-designs a set of structured prompts. These prompts include the following key elements: Role definition: Instructs the large language model to play the role of "data analysis expert", focusing on understanding the user's data visualization needs.

[0045] Task Description: The model is explicitly required to extract three types of information from user queries: intent tags, entity lists, and demand type tags.

[0046] Output format constraint: The model is required to output results in JSON format, which is convenient for subsequent modules to parse directly.

[0047] Example guidance: Several "user query - expected output" examples are provided to help the model understand the task requirements: A typical prompt word template is as follows: "You are a data analysis expert. Please extract information from the following user query and return the results in JSON format. The JSON must contain three fields: intent, entities, and analysis_type."

[0048] The intent field represents the user's intent and can only be selected from the following three values: 'generate_chart' (generate a new chart), 'modify_style' (modify the chart style), and 'modify_data' (modify the chart data).

[0049] The entities field is an object containing the following subfields: metrics (list of metrics), dimensions (list of dimensions), time_range (time range), and filters (filter criteria).

[0050] The `analysis_type` field indicates the analysis type, which can be selected from one or more of the following values: 'trend_analysis', 'composition_comparison', 'distribution_relation', 'geo_spatial', and 'hierarchy_flow'.

[0051] User query: '{user-input query statement}'.

[0052] 2. Specific execution of the parsing process After receiving a user's natural language query, the task understanding and classification module fills the query into the above prompt word template to form a complete prompt word, and then calls the large language model for processing.

[0053] Taking a user query of "showing the sales trend of product A in each quarter of 2024 and comparing the proportion in each region" as an example, the large language model will output the following structured parsing result in JSON format: {“intent”: “generate_chart”,“entities”: {“metrics”: [“sales”],“dimensions”: [“product”, “region”, “quarter”],“time_range”: “2024”,“filters”: {“product”: “A”}},“analysis_type”: [“trend_analysis”, “composition_comparison”]}.

[0054] 3. Verification and transmission of parsing results After receiving the JSON result returned by the large language model, the requirements parsing tool first performs format validation and field integrity checks. If the validation passes, the structured parsing result is the requirements analysis result, where: The intent label represents the category of the user's query purpose; in this example, it is "generate a new chart". The entity list represents the target data information, clearly specifying the metrics, dimensions, time range, and filtering conditions to be queried; The query type label (analysis_type) indicates the type of analysis the user query belongs to. This example includes both "Trend Analysis" and "Composition and Comparison".

[0055] Finally, the requirement analysis tool passes the structured analysis result to the state management and context module as the basis for subsequent process template loading and tool scheduling.

[0056] 4. Predefined set of analysis types This invention predefines five analysis types, each corresponding to specific visualization best practices and dedicated analyzers: Trend analysis type: Suitable for displaying the pattern of indicator changes over time, such as time series analysis, growth rate calculation, etc. Composition and comparison type: suitable for showing the relationship between parts and the whole or comparing different categories, such as proportion analysis, Pareto analysis, etc. Distribution and Relationship Type: Suitable for displaying the distribution characteristics of data or the correlation between variables, such as statistical description, correlation analysis, cluster analysis, etc. Geospatial type: Suitable for analyses related to geographic location, such as geocoding, regional aggregation, and heat calculation; Hierarchical and process-oriented: Suitable for displaying the hierarchical structure of data or process transformation, such as hierarchical aggregation, conversion rate calculation, etc.

[0057] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0058] S201. Determine the complexity type of the process template based on the intent label. Intent tags represent the core purpose of a user's query. This invention predefines three intents: generate a new chart, modify chart style, and modify chart data. Different intents have significantly different requirements for data processing and chart generation; therefore, three process templates with different levels of complexity are maintained.

[0059] Complete Workflow Template: This template loads when the intent tag is "Generate New Chart". It defines a tool call chain comprising three main phases: Data Query, Data Analysis, and Visualization Generation. The Data Query phase uses query tools to retrieve raw data from a database or data source; the Data Analysis phase calls the corresponding dedicated analyzer for targeted analysis based on the subsequently determined requirement type tag; and the Visualization Generation phase uses a visualization engine to generate the final chart. This template is suitable for creating visualization scenarios for the first time.

[0060] Partial Process Template: When the intent label is "Modify Chart Style," a partial process template is loaded. This template only includes the visualization regeneration stage, directly reusing the post-analysis data already saved in the state context, simply re-calling the visualization engine and applying the new style parameters. This template avoids repeatedly performing time-consuming data query and analysis operations, enabling rapid chart updates. For example, if a user reports "Change the line chart color to red," this is identified as a style modification intent, and the cached sales data is directly used to re-render the red line chart.

[0061] Partial Workflow Template: When the intent tag is "Modify Chart Data," a partial workflow template is loaded. This template includes at least the data query phase and the subsequent analysis and visualization phases, but typically does not include the complete initialization process. Based on the specific modifications in the feedback (such as changing the time range or replacing metrics), the process will roll back to the data query phase, retrieve the new data, and then continue with the analysis and visualization. For example, if the user feedback is "Change 2024 to 2023," the process will roll back to the data query phase, re-query the data for 2023, and then sequentially call the analyzer and visualization engine to generate a new chart.

[0062] S202. Load the sub-template for the analysis phase based on the requirement type tag. After determining the overall complexity of the process template, the corresponding analysis phase sub-templates are further loaded from the template based on the requirement type tags. The analysis phase sub-template defines which dedicated analyzer to invoke and the specific data processing algorithm that analyzer should execute. This invention pre-defines five requirement type tags, each corresponding to a unique analysis phase sub-template.

[0063] (1) Trend Analysis Sub-template When the demand type label is "Trend Analysis," a sub-template for the analysis phase that calls the trend analyzer is loaded. The trend analyzer internally implements specialized algorithms for time series data. Resampling: Aggregates raw data according to a specified time frequency (such as daily, weekly, monthly, or quarterly) to ensure the regularity of the timeline. For example, resample daily sales data to quarterly data: df.resample('Q').sum().

[0064] Moving average calculation: A rolling window algorithm is used to smooth short-term fluctuations and highlight long-term trends. For example, to calculate the 7-day moving average: df['sales_MA7'] = df['sales'].rolling(window=7).mean().

[0065] Change point detection: Automatically identify moments in a time series where the mean or variance changes significantly using statistical testing methods (such as the CUSUM algorithm or PELT algorithm) and return the locations of these change points.

[0066] After the sub-template is executed, the output data will include the original sequence, the moving average sequence, and the change point labels, which can be used by the visualization engine to generate line charts or area charts.

[0067] (2) Composition and contrast type sub-template When the requirement type tag is "Composition and Comparison", the analysis phase sub-template containing the call to the composition analyzer is loaded. The composition analyzer executes the following algorithm: Grouping and aggregation: Summing or counting numerical metrics based on specified category dimensions (such as product line or region). For example: df.groupby('region')['sales'].sum().

[0068] Percentage calculation: Calculate the percentage of each category in the total population, and calculate the cumulative percentage to support Pareto analysis (80 / 20 rule).

[0069] Pareto sort: Sort by value from largest to smallest, and merge small categories with a percentage below a preset threshold (such as 2%) into "Other" items to avoid overcrowding of the chart.

[0070] The output of this sub-template is a dataset with percentage and sorting labels, which can be directly used to render pie charts, donut charts, stacked bar charts, or Pareto charts.

[0071] (3) Distribution and relational sub-templates When the requirement type label is "Distributed and Relational," load the analysis phase sub-template that calls the distribution analyzer. Distribution analyzer implementation: Descriptive statistics: Calculate statistics such as mean, median, standard deviation, quartiles, minimum, and maximum.

[0072] Correlation calculation: Calculate the Pearson correlation coefficient (linear correlation) or Spearman rank correlation coefficient (monotonic correlation) for two or more continuous variables, and generate a correlation coefficient matrix.

[0073] Cluster analysis: When it is necessary to display the distribution in groups, simple clustering algorithms such as K-Means can be called to generate cluster labels for each data point.

[0074] The output of this sub-template includes a statistical summary dictionary and an optional cluster label column, which can be used to generate histograms, box plots, scatter plots, or heatmaps.

[0075] (4) Geospatial type sub-template When the requirement type tag is "Geospatial", load the sub-template for the analysis phase that calls the geospatial analyzer. The geospatial analyzer executes: Geocoding: If the input data only contains place names, a third-party geocoding service is called to convert the place names into latitude and longitude coordinates (lon, lat).

[0076] Spatial aggregation: Aggregate data points according to administrative divisions (such as provinces and cities) or custom grids, and calculate the sum or average of indicators in each region.

[0077] Heatmap Calculation: For scattered data, the kernel density estimation (KDE) algorithm is used to generate gridded density values ​​for heatmap rendering.

[0078] The sub-template outputs a dataset containing latitude and longitude coordinates or administrative division identifiers, as well as optional heat grid data, for use by map rendering engines such as Leaflet and Mapbox GL.

[0079] (5) Hierarchical and process-oriented sub-templates When the requirement type tag is "Hierarchical and Process-oriented", load the analysis phase sub-template that calls the process analyzer. Process analyzer implementation: Hierarchical aggregation: For tree-structured data (such as organizational structure, product categories), the indicator values ​​are summarized layer by layer from bottom to top or from top to bottom to generate a parent-child node relationship table.

[0080] Conversion rate calculation: For funnel process data (such as user registration → browsing → adding to cart → payment), calculate the conversion rate between adjacent stages (such as "number of people paying / number of people adding to cart") and the overall conversion rate.

[0081] The output of this sub-template is a dataset labeled with hierarchical relationships or conversion rates, which can be used to generate tree diagrams, sunburst diagrams, funnel diagrams, or Sankey diagrams.

[0082] S203. Collaborative Process for Template Loading In actual execution, the tool coordination and execution engine first retrieves a process template object of corresponding complexity from the template library based on the intent tag. This template object contains placeholders for sub-templates of the analysis phase. The engine then matches the corresponding analysis phase sub-template based on the requirement type tag (which may be a single tag or a combination of tags, such as trend analysis + composition comparison) and populates it into the corresponding position in the process template. If the requirement contains multiple analysis types, the engine will load multiple sub-templates sequentially, forming a serial or parallel analysis chain.

[0083] Once loaded, the engine stores the complete process template (including overall stage divisions and specific analyzer call instructions) in the state management and context module, and generates subsequent tool call chains based on this template. This dynamic adaptation mechanism ensures that the most suitable processing path is accurately selected according to user intent and analysis needs, avoiding the inefficiency or inapplicability of a "one-size-fits-all" process.

[0084] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0085] S301. Methods for generating tool call chains, such as Figure 2 As shown, it includes: 1. Obtain the state context The tool coordination and execution engine first requests the current task's state context from the state management and context module. This context is a structured data object that persists throughout the entire session lifecycle and is maintained uniformly by the state management and context module. Its core fields include: Current processing stage identifier (current_stage): Indicates which stage the process has reached, such as PARSING, DATA_QUERYING, DATA_PROCESSING, VIS_GENERATING, etc. For initial generation tasks, this identifier is usually set to the first stage of the process template.

[0086] A snapshot of the processing results for each completed stage (stage_results): This stores the output results of each executed stage in dictionary form. For example, data_query_result stores the raw dataset returned by the query tool; data_processing_result stores the processed data generated by the analyzer. Values ​​for stages that have not yet been executed are empty or placeholders.

[0087] Requirements analysis results (parsed_intent): include intent labels, requirement type labels, target data information, etc., which are generated by the aforementioned parsing steps and persisted in the context.

[0088] The state context can be represented as a JSON object.

[0089] 2. Based on the workflow template, determine the tool instances and input parameter sources for each processing stage. The tool coordination and execution engine loads the selected process template. This template defines the sequence of processing stages in a structured manner, as well as the types of tools required for each stage and the sources of input data. Templates are typically in YAML or JSON format.

[0090] The engine processes each stage sequentially according to the order defined in the template: Determine the tool instance to be invoked: Based on the required_tool_tag in the template (such as data_fetcher, trend_analyzer) and the requirement type tag, match the specific tool instance from the tool registry directory. The tool registry directory records the capability tags, invocation endpoints, input / output modes, etc., of each available tool. If the requirement type tag contains multiple analysis types (e.g., trend analysis + composition comparison), the engine may select a combined analyzer or invoke multiple dedicated analyzers sequentially for the data processing stage.

[0091] Determine the source of input parameters: Based on the `input_from` list in the template, extract the corresponding data from the state context. For example, `parsed_intent.entities` indicates that target data information is obtained from the requirements analysis results; `stage_results.data_query_result` indicates that the raw dataset is obtained from the snapshot of the results of completed stages. The engine parses these sources into actual data objects.

[0092] 3. Generate tool call instructions corresponding to each processing stage. For each processing stage, the engine generates an atomic tool invocation instruction based on the tool instance and input parameters determined in the previous step. Each instruction contains at least the following three core elements: Tool identifier to be invoked: Information that can uniquely identify a tool instance, such as service name + version number (data_fetcher@v2), function pointer or REST API endpoint URL.

[0093] Input parameter retrieval path: Describes how parameters are dynamically extracted from the state context, typically using JSONPath or dotted path expressions. For example, $.stage_results.data_query_result.raw_data.

[0094] Location of output results: Specifies which field in the state context should store the results after the tool has finished executing. This field is usually consistent with output_to in the template, such as stage_results.data_processing_result.

[0095] Tool invocation commands can be represented using internal data structures.

[0096] 4. Assemble into an ordered tool call chain The engine arranges the tool call instructions corresponding to all processing stages in the order defined in the process template, forming an ordered tool call chain (also known as an instruction chain or directed acyclic graph). This chain is a linear sequence (it may contain branching structures if conditional branches exist, but the core embodiment of this invention primarily uses a linear order). After assembly, the tool call chain is stored in the state context or temporary cache for use by subsequent execution stages.

[0097] 5. Chain persistence and transmission After generating the tool call chain, the engine persists it to the state management and context module (e.g., storing it in the stage_results.instruction_chain field), and updates the current_stage in the state context to the name of the first stage in the chain.

[0098] S302. Execute the methods in the tool call chain, such as Figure 3 As shown, it includes: 1. Initialize the execution environment The executor first reads the generated tool call chain (instruction_chain) and the current state context from the state management and context module. The state context records the storage location of the results of each stage (such as the stage_results dictionary) and the identifier of the stage to be executed. The executor sets its internal pointer to the first instruction of the tool call chain, ready to begin loop execution.

[0099] 2. Execute each tool call command in sequence. The executor processes each instruction sequentially according to the order of instructions in the tool call chain. The following explanation uses a typical tool call chain from the "Trend Analysis" task as an example, which contains three instructions: data query, trend analysis, and visualization generation.

[0100] (1) Execute data query command Extracting Input Parameters: The current instruction's input_paths is ["parsed_intent.entities"]. The executor uses JSONPath expressions to extract data from the state context. For example, retrieving target data information from parsed_intent.entities: {"metrics": ["sales"], "dimensions": ["region", "quarter"], "time_range": "2024", "filters": {"region": "XX district"}}. The executor converts this information into the parameter format required by the target tool, such as SQL query statements or data source API call parameters.

[0101] Match and invoke the tool instance: The current command's tool_id is "sql_data_fetcher". The executor queries the tool registry directory, which maintains metadata for all available tools, including tool identifier, capability tags, invocation endpoints, input / output modes, etc. Based on sql_data_fetcher, it finds the corresponding tool instance (which may be a database connector or a REST API client), then initiates the invocation through a predefined interface (such as HTTP POST, gRPC, or a local function call), passing the constructed parameters to the tool.

[0102] Receiving and storing results: After the tool completes execution, it returns a result, such as a PandasDataFrame or JSON array containing the raw data. The executor stores this result in the state context according to the output_path of the instruction (e.g., "stage_results.data_query_result"). During storage, the executor also records metadata such as the data type and row number of the result for use in subsequent stages.

[0103] Update the current processing stage identifier: The executor updates the current_stage in the state context to the stage name corresponding to the current instruction (e.g., DATA_QUERYING is changed to DATA_PROCESSING) to reflect the progress of the process.

[0104] (2) Execute trend analysis command Extracting input parameters: The input_paths of the current instruction are ["stage_results.data_query_result", "parsed_intent.analysis_type"]. The executor extracts the raw dataset stored in the previous step (stage_results.data_query_result) and the analysis type (["trend_analysis"]) from the requirements analysis results from the state context.

[0105] Match and invoke the tool instance: Locate the trend analyzer instance from the tool registry based on the tool_id (e.g., "trend_analyzer"). The executor passes the extracted raw dataset and analysis type as parameters to the analyzer.

[0106] Receive and store results: After performing resampling, moving average calculation, and change point detection, the trend analyzer returns the processed data (including the original sequence, moving average column, and change point labels). The executor stores this result in stage_results.data_processing_result.

[0107] Update the current processing stage identifier: update current_stage to VIS_GENERATING.

[0108] (3) Execute the visualization generation command Extract input parameters: Get the analyzed data from stage_results.data_processing_result, and get the user-preferred chart type (if any) from parsed_intent or infer it based on the requirement type.

[0109] Match and invoke tool instances: Invoke the visualization engine based on tool_id (e.g., "plotly_generator"). The engine automatically selects a line chart based on the requirement type label (trend analysis) and maps data fields to axes.

[0110] Receive and store the results: The visualization engine returns an interactive chart configuration object (such as a JSON representation of PlotlyFigure). The executor stores it in stage_results.visualization_spec.

[0111] Update the current processing stage identifier: update current_stage to RENDERING (or mark it as COMPLETED).

[0112] 3. Repeat until completion. The executor repeats the above steps, processing each instruction in the tool call chain sequentially. Once all instructions have been executed, the execution status of the tool call chain is marked as "successful." At this point, the status context saves a complete snapshot of the processing results, including raw data, analyzed data, and visualization configurations.

[0113] 4. Exception handling during execution If a tool call command fails to execute (e.g., database connection timeout, analyzer algorithm error), the executor will capture the error information, mark the stage_status of that stage as FAILED, and record the error details in the status context. Based on the preset error handling strategy, the executor can choose to: Retry: Recall the same tool instance, up to 3 times; Alternative tools: Find another tool instance with the same capability tags from the tool registry (e.g., switch from MySQL queryer to PostgreSQL queryer). Terminate execution: Stop the execution of subsequent instructions and return an error message to the user.

[0114] 5. Final output of the execution results Once all instructions in the tool call chain have been successfully executed, the executor instructs the front-end rendering tool to read `stage_results.visualization_spec` from the state context and render it as the final visualization chart to be displayed to the user. Simultaneously, the complete snapshot in the state context provides a data reuse basis for subsequent possible iterative feedback (such as modifications to styles or data), avoiding redundant calculations.

[0115] S303. During the execution of the tool call chain, an exception handling mechanism is also included: 1. Monitor the execution status of each tool invocation command. When invoking each tool instance, the executor uses either a synchronous call or asynchronous callback method with timeout control and monitors the execution result in real time. The executor sets a status monitoring point for each tool call instruction, recording the following information: call start timestamp; call end timestamp; return status code (success / failure); error type (e.g., timeout, connection refused, data format error, algorithm exception, etc.); and error details (e.g., exception stack trace, error message).

[0116] The executor captures the execution status in the following ways: if the tool instance returns a result normally and the result meets the expected format, it is marked as "success"; if the tool instance throws an exception, returns an error code, or does not respond for more than a preset timeout period (e.g., 30 seconds), it is marked as "failure".

[0117] Once the status is marked as "failure", the executor immediately suspends the execution of subsequent instructions and transfers control to the exception handling module.

[0118] 2. Obtain error messages for failures. The exception handling module receives failure notifications from the executor and extracts structured error information from the state context or exception object. The error information includes at least: Failure instructions: The tool invocation instructions that failed to execute (including tool identifier, stage name, etc.); Error codes: such as TIMEOUT, CONNECTION_REFUSED, INVALID_DATA, ALGORITHM_ERROR; Error description: A detailed, human-readable description, such as "Database connection timed out, waiting for 30 seconds"; Time of occurrence: timestamp accurate to milliseconds.

[0119] This information is temporarily stored in the context of the exception handling module for use in subsequent decisions.

[0120] 3. Perform operations according to the preset error handling strategy. The exception handling module internally maintains an error handling strategy table, which can be dynamically configured based on conditions such as error type, tool identifier, and number of retries. It supports three basic error handling operations and their combinations: (1) Re-execute the current tool invocation command For temporary errors (such as network jitter or momentary service overload), the exception handling module can employ a retry strategy. The specific implementation is as follows: The module records the number of times the current instruction has been retried and compares it with the preset maximum number of retries (e.g., 3 times); If the maximum number of retries has not been exceeded, wait for a backoff interval (e.g., wait 1 second for the first retry, 2 seconds for the second, and 4 seconds for the third), and then notify the executor to call the same tool instance again with the same parameters. If the retry is successful, the error status is cleared and subsequent instructions are executed. If the number of retries is exhausted and the attempt still fails, other strategies (such as alternative tools or termination) will be implemented.

[0121] (2) Invoke a backup tool instance with the same capability tag to replace the current tool. For failures caused by tool instance unavailability (such as service shutdown or data source switching), the exception handling module can enable a backup tool mechanism. The specific implementation is as follows: The module queries the tool registry for other tool instances with the same capability tag as the currently failing tool. For example, if the currently failing mysql_data_fetcher has the tags "data_query" and "relational_db", the module can look for another tool that supports the "data_query" tag, such as postgres_data_fetcher or presto_data_fetcher. If a usable alternative tool instance is found, the module replaces the tool_id in the current tool invocation command with the identifier of the alternative tool, while keeping other fields (input path, output path) unchanged; Then, the executor is notified to re-execute the modified instructions; If the backup tool also fails, continue searching for the next backup tool until all attempts fail.

[0122] (3) Terminate the execution of the entire tool call chain and provide error information to the user. For unrecoverable errors (such as fundamental data format errors or missing necessary dependencies), or after retries and backup tools have failed, the exception handling module adopts a termination strategy: The module stops further execution of the tool call chain and marks the status of the entire task as "failed"; Extract user-readable descriptions from error messages and generate friendly error messages (such as "Unable to connect to the database, please check your network settings and try again"). The error message is returned to the user through the user interaction layer; Additionally, users may be advised to modify their queries or contact the administrator.

[0123] Strategy Combination: Supports combining the above operations. For example, if a database connection fails, it can first try 3 times. If it still fails, it switches to a backup data source. If the backup data source also fails, it terminates the process and reports an error. This combination strategy is implemented through a configurable error handling process.

[0124] 4. Record the error message and the error handling operation performed in the state context. Regardless of the error handling operation, the exception handling module persists a complete error handling record to the state context for subsequent auditing, debugging, or recovery. The record includes: complete information about the failed tool call instruction; the captured error code and description; the error handling strategy used (number of retries, whether a backup tool was enabled, backup tool identifier, etc.); the processing result (successful recovery, partial recovery, final failure); and the start and end timestamps of the entire exception handling process.

[0125] This information is stored in dedicated fields of the state context, such as stage_results.error_log. The state management and context module associates it with the session to ensure traceability for user feedback or debugging.

[0126] 5. Flow of the process after exception handling If the exception handling is successful (either the retry is successful or the backup tool is successfully invoked), the executor resumes execution from the failed instruction and continues to process subsequent instructions in the tool call chain. If exception handling fails (retry exhaustion and no available backup tool, or termination policy is triggered), the entire tool call chain terminates, and no further instructions are executed. At this point, the current_stage in the state context is marked as ERROR, and the final failure state is saved.

[0127] Through the above-mentioned anomaly handling mechanism, the present invention significantly enhances the fault tolerance and self-healing ability when facing unstable external dependencies or data anomalies, ensuring the reliable execution of the data visualization process.

[0128] After the tool call chain is generated and execution begins, each specialized tool is called sequentially according to the order defined in the chain. This embodiment uses a typical "trend analysis" task as an example to describe in detail the complete execution process from data acquisition to chart rendering, and focuses on explaining the data processing and chart generation logic inside the visualization engine.

[0129] 1. The core execution process of the tool call chain The tool coordination and execution engine executes the following three core phases sequentially: (1) Use query tools to obtain target data The executor invokes the query tool based on the first instruction in the tool call chain. The query tool extracts target data information from the `parsed_intent.entities` field of the state context, including data metrics (such as "sales revenue"), dimensions (such as "region" and "quarter"), time range (such as "2024"), and filter conditions (such as "region=XX district"). The query tool converts this information into a corresponding query statement (e.g., SQL: `SELECT quarter, SUM(sales revenue) FROM sales_table WHERE region='XX district' AND year=2024 GROUP BY quarter`), connects to the specified data source (such as a relational database, data warehouse, or data lake), executes the query, and returns the raw dataset. This dataset is stored in a structured format (such as a Pandas DataFrame or a JSON array) in the `stage_results.data_query_result` field of the state context.

[0130] (2) Call the analyzer to perform targeted data analysis and processing. The executor invokes the dedicated analyzer corresponding to the demand type label based on the second instruction in the tool call chain. In this example, the demand type label is "Trend Analysis," so the trend analyzer is invoked. The trend analyzer reads the raw dataset obtained in the previous step from the state context and performs the following targeted analysis: Time series normalization: Resample the time field to ensure that the data is aligned by quarter and fill in missing quarters (e.g., fill in 0 if there are no sales records in a certain quarter).

[0131] Trend calculation: Calculate moving averages to smooth out short-term fluctuations, such as using a 3-quarter moving average.

[0132] Change point detection: Use the CUSUM algorithm to identify quarterly points where sales change significantly (such as a jump from Q2 to Q3).

[0133] After the analysis is completed, the processed data generated by the trend analyzer includes the original sales figures, moving average series, and change point labels, and is stored in the stage_results.data_processing_result field of the state context.

[0134] (3) Call the visualization engine to generate and render visualization charts. The executor invokes the visualization engine based on the third instruction in the tool call chain. The visualization engine reads the processed data and requirements analysis results from the state context and generates the final chart according to the following steps.

[0135] 2. Specific Implementation Steps of the Visualization Engine (2.1) Determine the preferred chart type based on the requirement type label. The visualization engine internally maintains a "requirement type - chart type" mapping table, which encapsulates best practices for data visualization. The engine queries this mapping table based on the input requirement type label, with the specific mapping rules as follows: For trend analysis needs, where users are interested in how data changes over time, line charts are the preferred chart type. For composition and comparison-based needs, where users focus on the relationship between parts and the whole or comparisons between different categories, select the chart based on the data hierarchy: for a single-level composition relationship, a pie chart is preferred; for multi-level composition or cross-category comparisons, a stacked bar chart is preferred. For distribution and relational needs, i.e. when users are concerned about data distribution or correlation between variables, the chart should be selected according to the number of variables: for bivariate correlation analysis, scatter plot is preferred; for univariate distribution analysis, histogram is preferred. For geospatial needs, where user needs are strongly correlated with geographical location, hierarchical statistical charts or heat maps are preferred. For hierarchical and process-oriented requirements, i.e., when users are concerned with the hierarchical structure of data or process transformation, tree diagrams (showing the hierarchical structure) or funnel diagrams (showing the process transformation) are preferred.

[0136] In this example, the requirement type is "trend analysis," and the engine determines that the preferred chart type is a line chart. If the requirement analysis results include user-preferred chart types (such as "bar chart"), the engine will prioritize user preferences, but may provide a warning if the chart is not readable.

[0137] (2.2) Mapping data fields to visual channels The engine automatically maps fields in the processed data to the corresponding visual channels based on the selected chart type: Axis mapping: Maps the time field ("quarter") to the X-axis and the numerical metrics ("sales" and "moving average") to the Y-axis. If there are multiple numerical metrics, multiple line graphs are generated.

[0138] Color mapping: Assign different colors to different data series (raw sales, moving average), for example, use a solid blue line for raw sales and a dashed orange line for moving average.

[0139] Size mapping (not applicable in this example, but can be used to encode a third variable in a scatter plot).

[0140] Once the mapping is complete, the engine generates a basic chart object.

[0141] (2.3) Set style attributes and interactive functions Based on style parameters from the requirements analysis results (such as user feedback "change the lines to red" or "add data labels") or the default configuration, the engine configures the style and interaction of the basic chart: Style settings: Dynamically set chart titles (e.g., "Sales Trends in XX District by Quarter in 2024"), X / Y axis labels ("Quarter", "Sales (Ten Thousand Yuan)"), legend position (top right corner), color theme (e.g., plotly_white template), font size, etc.

[0142] Interactive features: Hover tooltip is enabled by default, displaying the specific values ​​of data points; zoom and pan functions are enabled; legend click function is added to switch series display.

[0143] (2.4) Perform readability optimization To ensure charts remain clear and readable across different data scales and display environments, the engine performs the following optimizations: Axis label formatting: Automatically formats large values ​​on the Y-axis into a readable format, for example, 1000000 is displayed as 1.0M, and 0.15 is displayed as 15%.

[0144] Category axis anti-overlap: When the X-axis labels (such as quarter names) are too long or too dense, automatically rotate the label angle (such as tilting 45 degrees) or set the label spacing.

[0145] Data point downsampling: When the number of data points exceeds a preset threshold (such as 500) and causes the line chart to be too dense, the engine will automatically perform downsampling (such as uniformly extracting some points), or prompt the user to switch to an area chart or enable a data aggregation view.

[0146] (2.5) Output the chart configuration object and pass it to the front-end rendering tool After optimization, the visualization engine generates a chart configuration object. For the Plotly library, this object is a JSON structure containing data, layout, and configuration fields; for ECharts, it is its standard option dictionary. This configuration object is stored in the `stage_results.visualization_spec` field of the state context.

[0147] The executor then notifies the front-end rendering tool. The front-end rendering tool reads the configuration object from the state context and calls the appropriate rendering engine (such as a Plotly.js or ECharts instance) to display an interactive visualization chart on the user interface. Users can interact with the chart (zoom, hover to view data, switch legends, etc.) and can further provide feedback (such as modifying styles or data), which will be iterated differently based on the type of feedback.

[0148] In this embodiment, the data visualization intelligent agent, such as Figure 4 As shown: The user interaction layer is used to receive natural language queries from users. The Agent core scheduling layer includes: The task understanding and classification module is used to call the requirement parsing tool to perform intent recognition, entity extraction, and requirement classification on the user's natural language query, and output the requirement analysis results; the requirement analysis results include intent tags, requirement type tags, and target data information. The state management and context module is used to maintain the state context of the current query task. The state context includes at least the current processing stage identifier and snapshots of the processing results of each completed stage. The tool coordination and execution engine is used to load the corresponding process template according to the intent tag and the requirement type tag, and to generate and execute the tool call chain according to the process template, the requirement type tag and the state context; the process template defines the order in which multiple tools are called. The specialized tools layer includes: A query tool is used to obtain target data based on the target data information; Multiple analyzers, each corresponding to a demand type label, are used to perform targeted data analysis on the acquired target data and generate analyzed and processed data; A visualization engine is used to generate and render visualization charts based on the required type labels and the processed data.

[0149] Those skilled in the art will understand that the device structure involved in the embodiments of the present invention does not constitute a limitation on the device. The device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0150] The device may include a processor, a memory, and a communication unit. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0151] The present invention also provides a computer medium, wherein the computer medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The medium may be a magnetic disk, an optical disk, a read-only memory, or a random access memory, etc.

[0152] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a medium such as a USB flash drive, mobile hard drive, read-only memory, random access memory, magnetic disk, or optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0153] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0154] In the embodiments provided by this invention, it should be understood that the disclosed intelligent agents and methods can be implemented in other ways. For example, the intelligent agent embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another intelligent agent, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between intelligent agents or modules may be electrical, mechanical, or other forms.

[0155] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0157] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A data visualization method based on an Agent collaboration architecture, characterized in that, include: The system obtains the user's natural language query, calls the requirement parsing tool to perform intent recognition, entity extraction and requirement classification on the user's natural language query, and outputs the requirement analysis results, which include intent tags, requirement type tags and target data information. Load the corresponding process template based on the intent tag and the requirement type tag. The process template defines the order in which multiple tools are called. Based on the process template, the requirement type label, and the status context of the current query task, a tool call chain is generated and executed. The tool call chain is used to sequentially call multiple tools, including a query tool, an analyzer, and a visualization engine for obtaining target data based on the target data information. The process of executing the tool call chain includes: calling the query tool to obtain target data; calling the analyzer to perform targeted data analysis on the obtained target data to generate processed data after analysis; and calling the visualization engine to generate and render visualization charts based on the requirement type label and the processed data.

2. The method of claim 1, wherein, The requirement analysis tool is invoked to perform intent recognition, entity extraction, and requirement classification on the user's natural language query, and the requirement analysis results are output, including: A large language model is employed, and through a pre-defined prompt word engineering process, the large language model outputs structured parsing results; the structured parsing results include at least: Intent tags are used to characterize the purpose category of a user's query, which includes generating a new chart, modifying a chart style, or modifying chart data. The entity list is used to represent the target data information, which includes data indicators, time ranges, dimension fields and filtering conditions extracted from the query; The request type label is used to characterize the analysis type to which the user query belongs, and the analysis type is selected from a predefined set of analysis types.

3. The method of claim 2, wherein, The predefined set of analysis types includes: trend analysis, composition and comparison, distribution and relationship, geospatial analysis, and hierarchical and process analysis.

4. The method of claim 1, wherein, Load the corresponding process template based on the intent tag and requirement type tag, including: Based on the intent tag, determine the complexity type of the process template: if the intent tag is to generate a new chart, load a complete process template that includes data query, data analysis, and visualization generation stages; if the intent tag is to modify the chart style, load a partial process template that only includes the visualization regeneration stage; if the intent tag is to modify the chart data, load a partial process template that includes at least the data query stage and subsequent analysis and visualization stages. Based on the requirement type tag, load the analysis stage sub-template corresponding to the requirement type tag, which is used to call the analyzer, from the process template with determined complexity.

5. The method of claim 4, wherein, Based on the requirement type tag, from the process template with determined complexity, load the analysis stage sub-template corresponding to the requirement type tag, used for calling the analyzer, including: When the demand type label is trend analysis type, load the analysis phase sub-template that includes calling the trend analyzer; the trend analyzer is used to perform resampling, moving average calculation and change point detection on time series data; When the requirement type label is composition and comparison, an analysis phase sub-template containing a call to the composition analyzer is loaded; the composition analyzer is used to perform grouping aggregation, percentage calculation and Pareto sorting on the categorized data. When the requirement type label is distribution and relational, an analysis phase sub-template containing a call to the distribution analyzer is loaded; the distribution analyzer is used to perform descriptive statistics, correlation calculations, and cluster analysis on continuous variables; When the demand type tag is geospatial, an analysis phase sub-template containing a call to the geospatial analyzer is loaded; the geospatial analyzer is used to perform geocoding, spatial aggregation, and heat calculation on geographic names. When the requirement type label is hierarchical and process-oriented, an analysis stage sub-template containing a call to the process analyzer is loaded; the process analyzer is used to perform hierarchical aggregation or conversion rate calculation.

6. The method according to claim 1, characterized in that, Methods for generating tool call chains include: Obtain the state context, which is maintained by the state management and context module, and includes at least the current processing stage identifier and snapshots of the processing results of each completed stage; Based on the order of the processing stages defined in the process template and the requirement type label, determine the tool instance to be invoked and the source of the input parameters for the tool instance for each processing stage in sequence; Based on the tool instance to be invoked and the source of the input parameters of the tool instance determined for each processing stage, a tool invocation instruction corresponding to each processing stage is generated; the tool invocation instruction includes at least: the identifier of the tool to be invoked, the acquisition path of the input parameters, and the storage location of the output results; The tool call instructions corresponding to each processing stage are assembled into an ordered tool call chain according to the aforementioned sequence.

7. The method of claim 6, wherein, The methods in the execution tool call chain include: Each tool call instruction is executed sequentially according to the order of the tool call chain; For the currently executed tool invocation command, extract the corresponding data from the state context according to the acquisition path of the input parameters, and construct the invocation parameters; Based on the tool identifier to be invoked, match and invoke the corresponding tool instance from the tool registry directory; Receive the execution result returned by the tool instance, and store the execution result as a snapshot of the processing result in the state context according to the storage location of the output result; Update the current processing stage identifier recorded in the state context, and continue executing the next tool invocation instruction until all instructions in the tool invocation chain have been executed.

8. The method of claim 7, wherein, The execution of the tool call chain also includes an exception handling mechanism: Monitor the execution status of each tool invocation command; When the execution of the current tool call command fails, obtain the error message. According to the preset error handling strategy, perform one or a combination of the following error handling operations: re-execute the current tool invocation instruction; invoke a backup tool instance with the same capability label to replace the current tool; terminate the execution of the entire tool invocation chain and provide feedback of the error information to the user; The error information and the error handling operation performed are recorded in the state context.

9. The method of claim 1, wherein, The visualization engine is invoked to generate and render visualization charts based on the required type labels and the processed data, including: Based on the requirement type label, query the preset mapping table between requirement type and chart type to determine the preferred chart type corresponding to the requirement type label; The data fields in the processed data are mapped to the visual channels of the preferred chart type to generate a base chart, wherein the visual channels include axes, colors, and sizes; Based on the style parameters or default configurations in the requirements analysis results, set the style attributes and interactive functions of the basic chart to generate the chart configuration; The chart configuration is optimized for readability, including axis label formatting, category axis anti-overlap, and data point downsampling. Output the optimized chart configuration object and pass the chart configuration object to the front-end rendering tool for display.

10. A data visualization agent, characterized in that, The data visualization method based on the agent-based collaborative architecture as described in any one of claims 1-9 includes: The user interaction layer is used to receive natural language queries from users. The Agent core scheduling layer includes: The task understanding and classification module is used to call the requirement parsing tool to perform intent recognition, entity extraction, and requirement classification on the user's natural language query, and output the requirement analysis results; the requirement analysis results include intent tags, requirement type tags, and target data information. The state management and context module is used to maintain the state context of the current query task. The state context includes at least the current processing stage identifier and snapshots of the processing results of each completed stage. The tool coordination and execution engine is used to load the corresponding process template according to the intent tag and the requirement type tag, and to generate and execute the tool call chain according to the process template, the requirement type tag and the state context; the process template defines the order in which multiple tools are called. The specialized tools layer includes: A query tool is used to obtain target data based on the target data information; Multiple analyzers, each corresponding to a demand type label, are used to perform targeted data analysis on the acquired target data and generate analyzed and processed data; A visualization engine is used to generate and render visualization charts based on the required type labels and the processed data.

Images