State diagram-based data-driven ai agent implementation method and system

Abstract

The present application relates to the technical field of artificial intelligence and business intelligence, and particularly relates to a data-driven AI agent implementation method and system based on a state diagram, wherein the method is maintained by a deterministic state diagram workflow engine, and performs query enhancement, Schema concurrent retrieval and column-level merging, feasibility judgment, two-stage query decomposition, SQL generation and security check, SQL execution and error classification, limited retry, multi-task state isolation, dynamic sequential drilling, step conclusion and response synthesis, graph construction, streaming output, multi-round context management and audit tracking according to a pre-defined node, condition distributor and edge definition table; the system limits a language model to semantic generation tasks within a node, the inter-node routing is determined by a state flag bit in the global state, and the generation fluctuation is reduced through fixed model parameters, structured output verification, cache keys and abnormal fallback strategies. The method can improve the execution stability of natural language data analysis, the Schema retrieval efficiency, the error recovery capability, the complex analysis drilling capability and the consistency of visual output.

Description

[Technical Field] This invention relates to the field of interdisciplinary technology of artificial intelligence and business intelligence, and in particular to a method and system for implementing data-driven AI agents based on state diagrams. [Background Technology] As the data volume of e-commerce platforms, advertising platforms, and enterprise management systems continues to grow, merchants and operations personnel have an increasing demand for low-barrier, real-time data analysis. Traditional business intelligence tools such as Tableau, Metabase, and Google Data Studio typically require users to have SQL writing skills or rely on predefined dashboards. For real-time queries such as "What was the distribution of sales by category last week?" or "Why did sales decline last week?", users often need to configure data sources themselves, write query statements, or wait for developers to provide report templates, which is insufficient to meet the needs of exploratory analysis.

[0003] Existing natural language data analysis solutions generally include single-step NL2SQL solutions, recurrent agent solutions based on the ReAct model, and predefined dashboard solutions. Single-step NL2SQL solutions typically employ approaches such as Text-to-SQL, DIN-SQL, and C3SQL. Their technical route involves receiving a natural language query, injecting it into a database schema, calling a language model to generate SQL, executing the SQL, and returning the raw result. This type of solution primarily handles the translation step and terminates the process after the SQL is generated.

[0004] React-based recurrent agent schemes allow the language model to autonomously determine the next operation, such as `list_tables`, `get_schema`, `execute_sql`, or result interpretation. Representative schemes include LangChain SQL Agent and LlamaIndex NL2SQL. While these schemes offer some flexibility, the content and order of each execution step are determined by the language model's inference results. The same input may produce different tool call sequences in different executions, leading to unsatisfactory result stability, execution time, and troubleshooting difficulties in production environments.

[0005] The predefined dashboard solution compiles common query patterns into fixed report templates, such as daily sales trends and category sales percentages, allowing users to obtain results through filtering criteria. While this solution is relatively stable for fixed scenarios, it lacks flexibility; adding a new analytical scenario typically requires developers to manually write the query templates and front-end display logic.

[0006] The aforementioned existing technologies suffer from at least the following drawbacks: First, the execution path is uncertain, making systematic debugging and performance optimization difficult; second, they lack a structured fault-tolerant retry mechanism, failing to differentiate handling of SQL syntax errors, permission errors, and execution timeouts; third, they do not support complex multi-step analysis, making it difficult to automatically decompose causal analysis requirements and drill down step by step; fourth, schema retrieval efficiency is low, and full schema injection results in wasted context and makes it difficult to dynamically adjust the scope based on query semantics; fifth, the output format is monotonous, lacking standardized processing of chart generation, amounts, dates, column names, etc.; and sixth, multi-task isolation is insufficient, with the error state of one subtask potentially polluting subsequent subtasks, causing cascading failures. [Summary of the Invention] To overcome the above problems, this invention proposes a state diagram-based data-driven AI agent implementation method and system that can effectively solve the above problems.

[0008] The present invention provides a technical solution to the above-mentioned technical problems: a data-driven AI agent implementation method based on state diagrams, wherein the method is executed by a computer device and includes the following steps: S1. Receive natural language data input from the user for analysis and query, initialize the global state object based on merchant identifier, user identifier, time zone, settlement currency, conversation language and dialogue history, and set the current node pointer as the starting node by the deterministic state graph workflow engine. S2. Execute the query enhancement node to normalize the natural language data analysis query into an enhanced query, generate an extended query list that is semantically equivalent to the enhanced query, and extract a list of business terms. S3. Construct a schema search query set based on the enhanced query, the expanded query list, and the supplementary search content generated in the secondary search scenario; construct a business knowledge search query set based on the natural language data analysis query and the business terminology list; and perform concurrent searches on the schema search query set and the business knowledge search query set respectively. S4. Perform column-level join and merge on the database table structure results obtained by concurrent retrieval according to table name and column name, and perform deduplication and merge on the business knowledge results according to knowledge item name to form a schema context; S5. Perform a feasibility assessment based on the Schema context to obtain a feasibility assessment result. The feasibility assessment result includes at least three categories: analyzable, requires further retrieval, requires clarification, and casual conversation. S6. When the feasibility judgment result is analyzable, execute the query planning node. First, perform rule filtering by decomposing signal words and delimiters. When the decomposition signal is hit, call the language model to perform deep decomposition to generate an execution plan including decomposition strategy, sub-task list and whether replanning is needed. S7. Schedule subtasks according to the execution plan, reset the task step state area in the global state object before each subtask starts, and sequentially execute SQL generation, SQL security verification, SQL execution, error classification, and limited retries based on error type for the current subtask. S8. Generate step conclusions based on SQL execution results; when the replanning flag in the execution plan is true and the current subtask meets the replanning trigger condition, generate the next drill-down subtask or end the analysis decision based on the query, SQL statement and step conclusion of the completed subtask; generate the final response when no more subtasks are added, and perform column-level semantic type fusion, chart validity validation, date granularity unification, amount format internationalization, column display name localization and numerical serialization standardization on the output data; S9. Output the thought process, text conclusions, chart data and completion events to the client in the form of streaming events through the output writer, and persist multi-turn dialogue summaries and execution audit trail data after the workflow is completed; The deterministic state graph workflow engine determines the next node after the node execution is completed based on the dispatcher registry or edge definition table. The next node is determined by the state flag bit in the global state object.

[0009] Preferably, the deterministic state graph workflow engine includes a node registry, a dispatcher registry, and an edge definition table; the node registry is used to establish a mapping between node names and node instances, the dispatcher registry is used to establish a mapping between node names and condition dispatchers, and the edge definition table is used to establish a mapping list between predecessor nodes and successor nodes; each workflow node receives an execution context, a global state object, and an output writer through a unified interface, and writes the processing result back to the global state object after processing is completed.

[0010] Preferably, the deterministic state graph workflow engine includes the following steps during execution: setting the current node pointer to the starting node; checking whether the execution context has been canceled; obtaining the current node instance from the node registry and executing the corresponding processing logic; firstly querying the dispatcher registry to obtain the next node name, and if no corresponding dispatcher exists, querying the edge definition table to obtain the next node name; updating the current node pointer to the next node, and exiting the loop when the next node is the terminating node.

[0011] Preferably, under the conditions of the same global state object and the same node output results, the condition dispatcher outputs the same next node name; and, for language model calls, a fixed model version, fixed sampling parameters, structured output format verification, and cache key based on session identifier, user query, and schema context summary are set, and a preset fallback strategy is executed when structured output verification fails.

[0012] Preferably, the global state object includes at least query-related fields, schema context fields, feasibility judgment fields, task execution plan fields, task step status fields, output-related fields, and merchant context fields; wherein, the query-related fields include UserQuery, EnhancedQuery, ExpandedQueries, ExtractedTerms, and ConversationHistory, the schema context fields include SchemaContext and SchemaRecallCount, and the feasibility judgment fields include FeasibilityResult and FeasibilityContent.

[0013] Preferably, the task execution plan field includes Plan, decomposition strategy, subtask list, current execution index, and NeedReplan flag; each subtask includes a unique identifier, query text, display title, list of dependent task identifiers, whether a chart is needed, task status, query result, conclusion text, and chart specifications; the task step status field includes GeneratedSQL, SQLExplanation, QueryResult, ExecutionError, RetryCount, AnalysisType, ChartSchema, ColumnTypes, and ColumnLabels.

[0014] Preferably, the query enhancement node generates structured results through a non-streaming language model call. The structured results include a normalized query, an expanded query list, and an extracted terminology list. The normalized query is used to parse relative time into absolute dates based on the merchant's time zone, parse referential objects into explicit business objects, and normalize business terms. When the language model call fails or the structured result parsing is abnormal, the enhanced query is set to the user's original query, and the expanded query list and extracted terminology list are set to empty lists.

[0015] Preferably, the concurrent retrieval includes a schema retrieval track and a business knowledge retrieval track that are independent of each other; the schema retrieval track sends a SearchSchema request to the retrieval enhancement generation service for each query in the schema retrieval query set, and returns a list of database table structures including table names, table descriptions and column definitions; the business knowledge retrieval track sends a SearchBusinessKnowledge request to each query in the business knowledge retrieval query set, and returns Top-K business knowledge entries, where K is 3 by default.

[0016] Preferably, the business knowledge entries include one or more of the following: business term definition (business_term), metric definition (metric_definition), SQL example (sql_example), business rule (business_rule), and analysis method (analysis_playbook).

[0017] Preferably, the column-level union merging includes: establishing a table structure mapping with table name as the key; traversing the table list returned by each query, adding a corresponding table structure when the table name does not exist, and performing deduplication and union of the column list with column name as the key and retaining the first occurrence of the column definition when the table name already exists; retaining the first occurrence of the knowledge entry for the business knowledge results with the knowledge entry name as the key; and generating a schema prompt text for the merged table structure in a format that includes table name, display name, table description, column name, column description, data type, and enumeration example.

[0018] Preferably, when the feasibility judgment result indicates that further retrieval is required and the Schema retrieval count has not reached the preset upper limit, the supplementary retrieval content output by the feasibility judgment node is appended to the Schema retrieval query set and routed back to the Schema retrieval node; when the Schema retrieval count reaches the preset upper limit and the feasibility judgment result still indicates that further retrieval is required, the route is no longer routed back to the Schema retrieval node, but instead a clarification prompt or a service unavailable prompt is generated and routed to the termination node.

[0019] Preferably, when the Schema retrieval result is empty, the feasibility judgment node directly returns a preset multilingual prompt without calling the language model; when the Schema retrieval result is not empty, it calls a structured result including result and content through a non-streaming language model, where result is data_analysis, need_recall, need_clarify, or chitchat.

[0020] Preferably, the two-stage query decomposition includes: a first stage, performing pattern matching on the user query using Chinese decomposition signal words, English decomposition signal words, and separators; if no decomposition signal is matched, a single-task execution plan is generated; a second stage, only when at least one decomposition signal is matched in the first stage, generating a single-task, parallel, sequential, or hybrid strategy execution plan from the user query, the enhanced query, the schema context, the maximum number of tasks limit, and the dialogue history input language model.

[0021] Preferably, the Chinese decomposition signal words include coordinate words "and", "with", "as well as", "respectively", "each", comprehensive words "business overview", "operation overview", "overall performance", causal words "why", "reason", "decrease", "change", and comparative words "comparison", "comparison", "year-on-year", "month-on-month", "vs"; the English decomposition signal words include coordinate words and, also, both, as well as, comprehensive words overview, summary, dashboard, causal words why, reason, decline, drop, and comparative words compare, versus, drill down.

[0022] Preferably, the parallel strategy indicates that there is no dependency between multiple subtasks, and the system adopts concurrent execution, batch scheduling, or sequential interleaved execution according to resource allocation; regardless of the execution method adopted, the task step states of each subtask are isolated from each other.

[0023] Preferably, the SQL generation includes selectively injecting prompt words for the Schema DDL segment, business knowledge segment, error prompt segment, dialogue context segment, completed task segment, and language prompt segment according to trigger conditions, and outputting a structured result including an executable SQL statement, analysis type, SQL explanation, chart title, chart axis mapping configuration, column type mapping, and column label mapping; after SQL generation, blank character normalization is performed on the SQL statement, and redundant semicolons and line breaks are removed.

[0024] Preferably, the SQL security check includes: checking whether the SQL is a read-only query; intercepting INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, and multi-statement execution; checking whether the accessed tables and fields are within the authorized scope; checking or forcibly injecting merchant isolation conditions; and adding LIMIT or pagination limits to queries with large unaggregated result sets; when the SQL security check fails, a security policy class execution error is generated and directly routed to a non-retryable processing node.

[0025] Preferably, the SQL execution includes executing the SQL statement through a data analysis service and classifying the execution error into SQL syntax error, table column matching error, execution timeout error, service internal error, permission error, and security policy error; among them, the SQL syntax error and table column matching error are routed back to the SQL generation node, the execution timeout error is routed to SQL optimization or flow limiting retry, the service internal error executes execution layer backoff retry, and the permission error and security policy error directly enter non-retryable processing.

[0026] Preferably, the limited retries include limiting the number of retries based on RetryCount and MaxRetries, with MaxRetries set to 3 by default; when a retryable error occurs and RetryCount is less than MaxRetries, the previous SQL statement and error information are injected into the next SQL generation process or execution layer retry process; when RetryCount reaches MaxRetries, user-friendly error information is generated in single-task mode, and in multi-task mode, the current subtask is marked as failed and subsequent subtasks are continued to be scheduled.

[0027] Preferably, the dynamic sequential drill-down includes constructing a completed step context based on the queries, SQL statements, and analysis conclusions of completed subtasks; inputting the original user query, schema context, and completed step context into a language model to obtain a decision on whether to continue drilling or end the analysis; when the decision is to continue drilling, the next query is added as a new subtask to be executed to the end of the execution plan; when the number of tasks reaches the upper limit, the next query is duplicated with a completed query, the result of the previous subtask is empty, the schema context does not support the next query, or the decision is to end the analysis, the replanning is terminated.

[0028] Preferably, the chart validity verification includes: verifying whether the x_axis, y_axis, and group fields in the chart_schema exist in the query result columns; verifying whether the column corresponding to y_axis is of type number, currency, or percent; trend analysis requires x_axis to be of type date or datetime, composition analysis requires the existence of categorical columns and numerical columns, and detailed analysis outputs a table by default; when the query result is empty, has only one row and is of detailed type, the axis field does not exist, or the uniqueness verification fails, the statistical chart output is skipped.

[0029] Preferably, the streaming events include text fragment events, thinking step events, subtask step events, chart data events, and completion events; the output writer maintains a thinking phase completion flag, and closes the still-running thinking step, emits a folding signal, and sets the thinking phase completion flag to true when it outputs a text fragment event or chart data event for the first time.

[0030] Preferably, the multi-turn dialogue summary includes the user query text, the query of each subtask, the SQL statement, the analysis type, the number of result rows, the column name list, and the preview of the first five rows of results; the multi-turn dialogue summary retains a maximum of twenty rounds and the total size is limited to thirty-two kilobytes. When the total size limit is exceeded, the column name list and result preview are cleared starting from the oldest round. If the limit is still exceeded, the round summary is deleted starting from the oldest round.

[0031] Preferably, the execution audit trail data includes the original user query, the enhanced query, the decomposition strategy, the planning and reasoning description, the identifier of each subtask, the query text, the execution status, the SQL statement, the SQL explanation, the analysis type, the number of result rows, the analysis conclusion, the execution time, the number of retries, the failure error information, the key decision chain, the schema context summary, the number of language model calls, and the token consumption; the execution audit trail data is asynchronously written to an independent audit table, retained for ninety days, and the SQL statements in the subtask execution details are truncated to four thousand characters.

[0032] The present invention also provides a data-driven AI agent system based on state diagrams, comprising: a state diagram workflow engine, a query enhancement module, a schema retrieval and merging module, a feasibility judgment module, a query planning module, a task execution module, an SQL generation module, an SQL security verification module, an SQL execution and fault tolerance module, a response and chart construction module, a streaming output module, a multi-round context management module, and an audit trail module; wherein each module is configured to collaboratively execute the method described in any one of claims 1 to 24.

[0033] The present invention also provides a computer device, including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method described therein.

[0034] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0035] Compared with the prior art, the data-driven AI agent implementation method and system based on state diagrams of the present invention have the following beneficial effects: 1. More stable execution path. The state graph-driven workflow replaces the loop-based approach of the language model autonomously selecting tools. The flow between nodes is determined by the predefined topology and condition dispatcher, and the fluctuation of the language model output is reduced through fixed model parameters, structured validation, and caching mechanisms.

[0036] 2. Achieve end-to-end automated orchestration. The system forms a complete pipeline from natural language query understanding to schema retrieval, feasibility assessment, query decomposition, SQL generation, security verification, execution, fault tolerance, conclusion generation, chart construction, and streaming output.

[0037] 3. Improve schema retrieval efficiency. Concurrent multi-query retrieval and column-level joins can preserve complementary column information retrieved by different query variants, while avoiding the waste of context caused by full database schema injection.

[0038] 4. It has structured fault tolerance capabilities. Error classification-driven finite retries can distinguish between SQL syntax errors, table column matching errors, execution timeouts, internal errors, permission errors, and security policy errors, and take appropriate actions such as correction, optimization, backoff retries, termination, or skipping the task.

[0039] 5. Enhanced complex analysis capabilities. Two-stage query decomposition and dynamic sequential drill-down can break down complex questions such as "Why did sales decline?" into trend queries, dimension drill-down, and root cause synthesis links, and prevent infinite loops through hard stop conditions.

[0040] 6. Avoid multi-task state pollution. The task executor resets the task step state area before each subtask begins, so that error messages, SQL statements, and retry counts of a single subtask do not affect subsequent subtasks.

[0041] 7. Improve output consistency and visualization accuracy. Column-level semantic type fusion, declarative chart specifications, chart validity validation, unified date granularity, currency formatting, localized column labels, and numerical stringification work together to ensure that output data remains consistent across different language, time zone, and currency environments.

[0042] 8. Improve observability and auditability. Audit trails record the complete decision-making process and key performance indicators, providing a data foundation for reproducing production environment issues, assessing SQL quality, and continuously optimizing the system. [Attached Image Description] Figure 1 This is a flowchart illustrating the overall process of the data-driven AI agent implementation method based on state diagrams according to the present invention. Figure 2 This is the overall architecture diagram of the data-driven AI agent system based on state diagrams of the present invention.

Detailed Implementation Methods

[0045] It should be noted that in the embodiments of the present invention, all directional indications (such as up, down, left, right, front, back, etc.) are limited to relative positions on the specified view, rather than absolute positions.

[0046] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0047] Please see Figure 1 and Figure 2 The state diagram-based data-driven AI agent implementation method of the present invention is executed by a computer device and includes the following steps: S1. Receive natural language data input from the user for analysis and query, initialize the global state object based on merchant identifier, user identifier, time zone, settlement currency, conversation language and dialogue history, and set the current node pointer as the starting node by the deterministic state graph workflow engine. S2. Execute the query enhancement node to normalize the natural language data analysis query into an enhanced query, generate an extended query list that is semantically equivalent to the enhanced query, and extract a list of business terms. S3. Construct a schema search query set based on the enhanced query, the expanded query list, and the supplementary search content generated in the secondary search scenario; construct a business knowledge search query set based on the natural language data analysis query and the business terminology list; and perform concurrent searches on the schema search query set and the business knowledge search query set respectively. S4. Perform column-level join and merge on the database table structure results obtained by concurrent retrieval according to table name and column name, and perform deduplication and merge on the business knowledge results according to knowledge item name to form a schema context; S5. Perform a feasibility assessment based on the Schema context to obtain a feasibility assessment result. The feasibility assessment result includes at least three categories: analyzable, requires further retrieval, requires clarification, and casual conversation. S6. When the feasibility judgment result is analyzable, execute the query planning node. First, perform rule filtering by decomposing signal words and delimiters. When the decomposition signal is hit, call the language model to perform deep decomposition to generate an execution plan including decomposition strategy, sub-task list and whether replanning is needed. S7. Schedule subtasks according to the execution plan, reset the task step state area in the global state object before each subtask starts, and sequentially execute SQL generation, SQL security verification, SQL execution, error classification, and limited retries based on error type for the current subtask. S8. Generate step conclusions based on SQL execution results; when the replanning flag in the execution plan is true and the current subtask meets the replanning trigger condition, generate the next drill-down subtask or end the analysis decision based on the query, SQL statement and step conclusion of the completed subtask; generate the final response when no more subtasks are added, and perform column-level semantic type fusion, chart validity validation, date granularity unification, amount format internationalization, column display name localization and numerical serialization standardization on the output data; S9. Output the thought process, text conclusions, chart data and completion events to the client in the form of streaming events through the output writer, and persist multi-turn dialogue summaries and execution audit trail data after the workflow is completed; The deterministic state graph workflow engine determines the next node after the node execution is completed based on the dispatcher registry or edge definition table. The next node is determined by the state flag bit in the global state object.

[0048] The deterministic state graph workflow engine includes a node registry, a dispatcher registry, and an edge definition table. The node registry is used to establish a mapping between node names and node instances, the dispatcher registry is used to establish a mapping between node names and condition dispatchers, and the edge definition table is used to establish a mapping list between predecessor nodes and successor nodes. Each workflow node receives the execution context, global state object, and output writer through a unified interface, and writes the processing result back to the global state object after processing is completed.

[0049] The deterministic state graph workflow engine, when executed, includes: setting the current node pointer to the starting node; checking whether the execution context has been canceled; obtaining the current node instance from the node registry and executing the corresponding processing logic; first querying the dispatcher registry to obtain the next node name, and if no corresponding dispatcher exists, querying the edge definition table to obtain the next node name; updating the current node pointer to the next node, and exiting the loop when the next node is the terminating node.

[0050] Under the conditions of the same global state object and the same node output results, the condition dispatcher outputs the same next node name; and, for language model calls, a fixed model version, fixed sampling parameters, structured output format verification, and cache key based on session identifier, user query, and schema context summary are set, and a preset fallback strategy is executed when structured output verification fails.

[0051] The global state object includes at least query-related fields, schema context fields, feasibility judgment fields, task execution plan fields, task step status fields, output-related fields, and merchant context fields; among which, query-related fields include UserQuery, EnhancedQuery, ExpandedQueries, ExtractedTerms, and ConversationHistory; schema context fields include SchemaContext and SchemaRecallCount; and feasibility judgment fields include FeasibilityResult and FeasibilityContent.

[0052] The task execution plan fields include Plan, decomposition strategy, subtask list, current execution index, and NeedReplan flag; each subtask includes a unique identifier, query text, display title, list of dependent task identifiers, whether a chart is needed, task status, query results, conclusion text, and chart specifications; the task step status fields include GeneratedSQL, SQLExplanation, QueryResult, ExecutionError, RetryCount, AnalysisType, ChartSchema, ColumnTypes, and ColumnLabels.

[0053] The query enhancement node generates structured results through a non-streaming language model call. The structured results include a normalized query, an expanded query list, and an extracted terminology list. The normalized query is used to parse relative time into absolute dates based on the merchant's time zone, parse referential objects into explicit business objects, and normalize business terms. When the language model call fails or the structured result parsing is abnormal, the enhanced query is set to the user's original query, and the expanded query list and extracted terminology list are set to empty lists.

[0054] The concurrent retrieval includes a schema retrieval track and a business knowledge retrieval track that are independent of each other. The schema retrieval track sends a SearchSchema request to the retrieval enhancement generation service for each query in the schema retrieval query set, and returns a list of database table structures including table names, table descriptions, and column definitions. The business knowledge retrieval track sends a SearchBusinessKnowledge request to each query in the business knowledge retrieval query set, and returns the Top-K business knowledge entries, where K is set to 3 by default.

[0055] The business knowledge items include one or more of the following: business term definition (business_term), metric definition (metric_definition), SQL example (sql_example), business rule (business_rule), and analysis method (analysis_playbook).

[0056] The column-level union and merging includes: establishing a table structure mapping with table name as the key; traversing the table list returned by each query, adding a corresponding table structure when the table name does not exist, and performing deduplication and union of the column list with column name as the key and retaining the first occurrence of the column definition when the table name already exists; retaining the first occurrence of the knowledge entry for the business knowledge results with the knowledge entry name as the key; and generating a schema prompt text for the merged table structure in a format that includes table name, display name, table description, column name, column description, data type, and enumeration example.

[0057] When the feasibility judgment result indicates that further retrieval is required and the Schema retrieval count has not reached the preset upper limit, the supplementary retrieval content output by the feasibility judgment node is appended to the Schema retrieval query set and routed back to the Schema retrieval node; when the Schema retrieval count reaches the preset upper limit and the feasibility judgment result still indicates that further retrieval is required, the route is no longer routed back to the Schema retrieval node, but instead a clarification prompt or a service unavailable prompt is generated and routed to the termination node.

[0058] When the Schema retrieval result is empty, the feasibility judgment node directly returns a preset multilingual prompt without calling the language model; when the Schema retrieval result is not empty, it calls the structured result including result and content through a non-streaming language model, where result is data_analysis, need_recall, need_clarify or chitchat.

[0059] The two-stage query decomposition includes: in the first stage, pattern matching is performed on the user query using Chinese decomposition signal words, English decomposition signal words, and separators. If no decomposition signal is matched, a single-task execution plan is generated. In the second stage, if at least one decomposition signal is matched in the first stage, the user query, the enhanced query, the schema context, the maximum number of tasks limit, and the dialogue history input language model are used to generate a single-task, parallel, sequential, or hybrid strategy execution plan.

[0060] The Chinese decomposition signal words include coordinating words "and", "with", "as well as", "respectively", "each", comprehensive words "business overview", "operation overview", "overall performance", causal words "why", "reason", "decline", "change", and comparative words "comparison", "comparative", "year-on-year", "month-on-month", "vs"; the English decomposition signal words include coordinating words and, also, both, as well as, comprehensive words overview, summary, dashboard, causal words why, reason, decline, drop, and comparative words compare, versus, drill down.

[0061] The parallel strategy means that there is no dependency between multiple subtasks, and the system adopts concurrent execution, batch scheduling, or sequential interleaved execution according to resource allocation; regardless of the execution method adopted, the task step states of each subtask are isolated from each other.

[0062] The SQL generation includes selectively injecting prompt words for the Schema DDL segment, business knowledge segment, error prompt segment, dialogue context segment, completed task segment, and language prompt segment according to trigger conditions, and outputting a structured result including an executable SQL statement, analysis type, SQL explanation, chart title, chart axis mapping configuration, column type mapping, and column label mapping; after SQL generation, perform whitespace normalization on the SQL statement and remove redundant semicolons and line breaks.

[0063] The SQL security check includes: checking whether the SQL is a read-only query; intercepting INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, and multi-statement execution; checking whether the accessed tables and fields are within the authorized scope; checking or forcing the injection of merchant isolation conditions; and adding LIMIT or pagination limits to queries with unaggregated large result sets; when the SQL security check fails, generate a security policy class execution error and directly route it to a non-retryable processing node.

[0064] The SQL execution includes executing the SQL statement through the data analysis service and classifying the execution errors into SQL syntax errors, table column matching errors, execution timeout errors, service internal errors, permission errors, and security policy errors; among them, SQL syntax errors and table column matching errors are routed back to the SQL generation node, execution timeout errors are routed to SQL optimization or flow limiting retry, service internal errors are executed with execution layer backoff retry, and permission errors and security policy errors directly enter non-retryable processing.

[0065] The limited retries include limiting the number of retries based on RetryCount and MaxRetries, with MaxRetries set to 3 by default. When a retryable error occurs and RetryCount is less than MaxRetries, the previous SQL statement and error information are injected into the next SQL generation process or execution layer retry process. When RetryCount reaches MaxRetries, user-friendly error information is generated in single-task mode, and in multi-task mode, the current subtask is marked as failed and subsequent subtasks are scheduled.

[0066] The dynamic sequential drill-down process involves constructing a completed step context based on the queries, SQL statements, and analysis conclusions of completed subtasks. The original user query, schema context, and completed step context are input into a language model to obtain a decision on whether to continue drilling or end the analysis. When the decision is to continue drilling, the next query is appended as a new subtask to be executed to the end of the execution plan. When the number of tasks reaches the upper limit, the next query is duplicated with a completed query, the result of the previous subtask is empty, the schema context does not support the next query, or the decision is to end the analysis, the replanning is terminated.

[0067] The chart validity verification includes: verifying whether the x_axis, y_axis, and group fields in the chart_schema exist in the query result columns; verifying whether the column corresponding to y_axis is of type number, currency, or percent; trend analysis requires x_axis to be of type date or datetime, composition analysis requires the existence of categorical columns and numerical columns, and detailed analysis outputs a table by default; when the query result is empty, has only one row and is of detailed type, the axis field does not exist, or the uniqueness verification fails, the statistical chart output is skipped.

[0068] The streaming events include text fragment events, thinking step events, subtask step events, chart data events, and completion events; the output writer maintains a thinking phase completion flag, and closes the still running thinking step, emits a folding signal, and sets the thinking phase completion flag to true when it outputs a text fragment event or chart data event for the first time.

[0069] The multi-turn dialogue summary includes the user query text, the query of each subtask, the SQL statement, the analysis type, the number of result rows, the column name list, and the preview of the first five rows of results. The multi-turn dialogue summary can retain a maximum of twenty rounds and the total size is limited to 32 kilobytes. When the total size limit is exceeded, the column name list and result preview are cleared starting from the oldest round. If the limit is still exceeded, the round summary is deleted starting from the oldest round.

[0070] The execution audit trail data includes the original user query, the enhanced query, the decomposition strategy, the planning and reasoning description, the identifier of each subtask, the query text, the execution status, the SQL statement, the SQL explanation, the analysis type, the number of result rows, the analysis conclusion, the execution time, the number of retries, the failure error information, the key decision chain, the schema context summary, the number of language model calls, and the token consumption. The execution audit trail data is asynchronously written to an independent audit table and retained for ninety days. The SQL statements in the subtask execution details are truncated to four thousand characters.

[0071] The present invention also provides a data-driven AI agent system based on state diagrams, comprising: a state diagram workflow engine, a query enhancement module, a schema retrieval and merging module, a feasibility judgment module, a query planning module, a task execution module, an SQL generation module, an SQL security verification module, an SQL execution and fault tolerance module, a response and chart construction module, a streaming output module, a multi-round context management module, and an audit trail module; wherein each module is configured to collaboratively execute the method described in any one of claims 1 to 24.

[0072] The present invention also provides a computer device, including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method described therein.

[0073] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described herein.

[0074] The technical problem to be solved by this invention is to provide a data-driven AI agent implementation method and system based on deterministic state graphs. While maintaining controllable and reproducible node routing, it realizes end-to-end automatic orchestration of natural language queries to data analysis conclusions and chart outputs. At the same time, it solves problems such as schema semantic retrieval and merging, SQL generation and secure execution, error classification and limited retries, multi-task decomposition and dynamic drill-down of complex queries, streaming conclusion generation, data standardization, multi-round contextual reference and execution audit trail.

[0075] To address the aforementioned technical problems, this invention provides a data-driven AI agent implementation method based on state graphs. This method maintains a global state object through a state graph workflow engine and drives workflow execution based on predefined workflow nodes, condition dispatchers, and edge definition tables. The language model is confined to nodes such as query enhancement, feasibility assessment, query planning, SQL generation, step-by-step conclusion generation, and dynamic replanning, undertaking semantic understanding and text generation tasks. The flow between nodes is determined by state flags and dispatcher rules, rather than being freely determined by the language model.

[0076] A deterministic state graph orchestration mechanism is employed. The state graph workflow engine comprises a node registry, a dispatcher registry, and an edge definition table. The node registry stores the mapping from node names to node instances, the dispatcher registry stores the mapping from node names to condition dispatchers, and the edge definition table stores the default topological edges between nodes. Each workflow node receives the execution context, a global state object, and an output writer through a unified interface. After a node completes execution, the workflow engine first calls the corresponding condition dispatcher to determine the next node; if no condition dispatcher exists, the next node is determined based on the edge definition table.

[0077] The workflow engine's execution logic includes: setting the current node pointer to the starting node; checking if the execution context has been canceled, and terminating if it has; obtaining the current node instance from the node registry and executing its processing logic; determining the next node based on the dispatcher registry or edge definition table after execution; updating the current node pointer to the next node, and exiting the loop when the next node is the terminating node.

[0078] To avoid the logical conflict between "deterministic state graphs" and "uncertainty in language model output," this invention limits determinism to the routing level: under the conditions of the same global state object and the same node output results, the conditional dispatcher will inevitably produce the same next node name. For language model calls, the system further employs a fixed model version, fixed sampling parameters, structured output JSON schema validation, a cache key based on session identifiers, query text, and schema context summaries, and a preset fallback strategy for parsing failures, thereby reducing the impact of language model output fluctuations on the execution path.

[0079] Global State Object. The global state object is the sole carrier of data flow between nodes, and includes at least the field groups shown in the table below.

[0080]

[0081] Query enhancement methods. The query enhancement node is the first processing node in the workflow, responsible for normalizing the user's original query and eliminating natural language ambiguity. The inputs to this node include the original user query, merchant time zone, settlement currency, and conversation history.

[0082] The query enhancement node is invoked via a non-streaming language model, injecting the current date and time and conversation history context into the system prompts, and requiring the language model to output structured JSON. Output fields include `canonical_query`, `expanded_queries`, and `extracted_terms`. `canonical_query` resolves relative times such as "today" and "last week" to absolute dates based on the merchant's time zone, resolves references such as "its trend" and "yesterday" to explicit business objects, and normalizes business terms such as GMV and refund rate. `expanded_queries` contains zero to three semantically equivalent query variations, for example, expanding "last week's GMV trend" to "last week's daily total transaction amount change". `extracted_terms` contains zero to five business domain terms, such as GMV, orders, and refund rate.

[0083] If the language model call fails, the output is not JSON, a field is missing, or the field type is abnormal, the system will set EnhancedQuery to UserQuery, set ExpandedQueries and ExtractedTerms to an empty list, and continue to the Schema retrieval node, without interrupting the workflow due to query enhancement failure.

[0084] Concurrent Schema Retrieval and Merging of Multiple Queries. The Schema retrieval node is responsible for obtaining the database table structure and business knowledge related to the query from the retrieval enhancement generation service. The system merges and deduplicates each query in EnhancedQuery, ExpandedQueries, and FeasibilityContent in secondary retrieval scenarios to form a Schema retrieval query set. For business knowledge retrieval, the query set additionally includes each term in UserQuery and ExtractedTerms.

[0085] The system simultaneously launches two independent concurrent retrieval task groups. The Schema retrieval track independently sends a SearchSchema request to each query in the Schema retrieval query set. Each request returns a list of database table structures semantically related to that query, including table names, descriptions, and column definitions. The Business Knowledge retrieval track independently sends a SearchBusinessKnowledge request to each query in the Business Knowledge retrieval query set. Each request returns a Top-K relevant business knowledge entry, with a default K=3. Business knowledge types include business_term, metric_definition, sql_example, business_rule, and analysis_playbook. The two tracks are independent and operate in complete parallelism.

[0086] Schema retrieval results are combined at the column level by table name and column name. The system establishes a mapping using `table_name` as the key, traversing the list of tables returned by all queries; if the table name does not exist in the mapping, the complete structure of the table is added; if the table name already exists, the column list of that table is deduplicated using `column_name` as the key, retaining the first occurrence of the column definition. Business knowledge results are deduplicated by knowledge item name, retaining the first occurrence of the item.

[0087] The merged schema information is formatted as prompt text as follows: # Table: Table name, display name, table description; followed by column names, column descriptions, data types, and supplementary information. For enumerated type columns, examples of possible values ​​are listed to help the language model generate the correct WHERE conditions.

[0088] Feasibility assessment and secondary search termination mechanism. After the schema retrieval is complete, the feasibility assessment node determines whether the current schema context is sufficient to support the user query. Inputs include UserQuery, EnhancedQuery, SchemaContext, and ConversationHistory. If the schema retrieval result is empty (i.e., no table structure and no business knowledge), the system directly returns a preset "Service temporarily unavailable" multilingual prompt without calling the language model to reduce unnecessary API consumption.

[0089] If the schema retrieval result is not empty, the feasibility assessment node outputs structured JSON via a non-streaming language model call, containing two fields: result and content. When result is data_analysis, it indicates that the current schema is sufficient to answer the query, and the process is routed to the query planning node; when result is need_recall, it indicates that the schema may be incomplete, and content is suggested supplementary search keywords, and the process is routed back to the schema retrieval node if SchemaRecallCount has not reached its limit; when result is need_clarify, content is a clarification prompt for the user, and the process is routed to the termination node; when result is chitat, content is casual conversation or an out-of-bounds reply for the user, and the process is routed to the termination node.

[0090] To form a finite closed loop, the system sets SchemaRecallCount and limits the Schema retrieval node to a maximum of a preset number of executions, preferably twice. When SchemaRecallCount has reached its limit and the feasibility judgment still outputs need_recall, the system no longer returns to the Schema retrieval node. Instead, it generates a clarification prompt or a service unavailable prompt based on FeasibilityContent and routes the system to the termination node.

[0091] A two-stage query decomposition method is proposed. The query planning node is responsible for decomposing the user query into executable sub-task plans. This invention employs a cost-aware two-stage query decomposition method. The first stage performs keyword and delimiter pattern matching on the user query. The decomposition signal lexicon maintained by the system is shown in the table below.

[0092]

[0093] Separators include Chinese and English commas, Chinese and English semicolons, and periods followed by substantive content. The detection algorithm scans these signals one by one. If none are found, a single-task execution plan is directly constructed with a "single" strategy, where the task list contains only one task and the query is set to "EnhancedQuery," thus skipping the second stage of language model invocation. For simple single-indicator queries such as "today's order volume" or "this month's sales revenue," this stage can be decomposed with zero language model invocation.

[0094] The second phase is triggered only if at least one decomposition signal is hit in the first phase. The system injects UserQuery, EnhancedQuery, SchemaContext, maximum task limit, and ConversationHistory into the language model prompts, requiring structured JSON output including strategy, tasks, need_replan, and reasoning. The strategy can be single, parallel, sequential, or hybrid. Each task contains query, title, depends_on, and need_chart.

[0095] The four decomposition strategies are as follows: single indicates that one query corresponds to one SQL statement; parallel indicates that multiple subtasks are independent of each other, and the system can execute them concurrently, in batches, or sequentially according to resource configuration; sequential indicates that there is a causal dependency chain between subqueries, suitable for root cause analysis queries such as "Why did sales decline," and NeedReplan is enabled; hybrid indicates that it contains several independent queries that require charts and can be executed first, as well as a seed query for subsequent sequential drill-down. The system imposes safety boundaries on the planning results, including that the total number of tasks does not exceed MaxTasks, falling back to the single-task strategy when JSON parsing fails, and, under the hybrid strategy, arranging independent tasks that require charts before the drill-down seed task.

[0096] SQL generation, SQL security verification, and SQL execution. The SQL generation node is responsible for converting the current subtask query into an executable SQL statement and simultaneously outputting chart specifications and data standardization metadata. The inputs to the SQL generation node include EnhancedQuery or subtask query, SchemaContext, business knowledge, ConversationHistory, completed subtask context, and error information from the last SQL execution.

[0097] The system uses a segmented injection strategy to construct SQL generation prompts. The segments and triggering conditions are shown in the table below.

[0098]

[0099] The language model outputs structured JSON, containing `sql`, `analysis_type`, `explanation`, `chart_title`, `chart_schema`, `column_types`, and `column_labels`. `analysis_type` can be `trend`, `comparison`, `composition`, `distribution`, or `detail`. `chart_schema` contains lists of `x_axis` and `y_axis`, and a `group` field. During post-processing, the system normalizes whitespace in the SQL, folds multi-line SQL into single lines, and removes redundant semicolons and newlines.

[0100] To enhance project security, this invention incorporates SQL security checks between the SQL generation and execution nodes. These checks include at least: allowing only SELECT or read-only queries; blocking INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, and multi-statement executions; verifying that accessed tables and fields fall within authorized scope; checking if the SQL contains merchant isolation conditions, or if merchant isolation conditions are forcibly injected by the data analysis service; and adding LIMIT or pagination restrictions to queries with large result sets without aggregation. SQL queries that fail security checks will not proceed to database execution but will instead be marked as security policy errors or permission errors.

[0101] The SQL execution node executes SQL through an independent data analysis service, passing in the SQL statement, MerchantID, UserID, and access token. Upon successful execution, the system parses the data row and column metadata and row number, and performs type inference for each column. Type inference includes recognizing date formats such as YYYY-MM-DD and YYYY-MM-DD HH:MM:SS through regular expression patterns, and recognizing numeric types through actual value types.

[0102] Error classification and limited retry mechanism. When SQL execution fails, the system writes the error to ExecutionError and performs hierarchical classification to guide subsequent routing. The optimal error classification and handling strategies are shown in the table below.

[0103]

[0104] The execution dispatcher routes data after the SQL execution node. If `ExecutionError` is empty and `QueryResult` is not empty, execution is considered successful. In single-task mode, routing leads to the response generation node; in multi-task mode, routing leads to the step conclusion node. If the error type is non-retryable, in multi-task mode, the current subtask is marked as failed and routed to the task executor; in single-task mode, `UserFacingError` is set and routing leads to the error handling node. If the error type is retryable and `RetryCount` is less than `MaxRetries`, the system increments `RetryCount` and enters the corresponding retry path; `MaxRetries` is preferably 3. If the retryable error reaches its limit, it is treated as a non-retryable error. `RetryCount` is reset at the start of each subtask to prevent retries from preceding tasks from affecting subsequent tasks.

[0105] Multi-task execution and state isolation. The task executor node manages the lifecycle of subtasks. The state of each subtask includes pending execution, running, completed, failed, and skipped. Each time the task executor is invoked, it first records the SQL, conclusion, query results, and chart specifications of the just completed task; in interleaved output mode, if the just completed task requires a chart and execution was successful, the chart data for that task is immediately built and emitted; if the execution plan is marked as needing replanning and the just completed task was a drill-down task, the replanning process begins; then, the next task in the pending execution state is searched.

[0106] Before scheduling a new task, the task executor completely resets the task step state area in the global state object to its initial value, clears the `GeneratedSQL`, `SQLExplanation`, `QueryResult`, `ExecutionError`, `RetryCount`, `AnalysisType`, `ChartSchema`, `ColumnTypes`, and `ColumnLabels` of the previous task, writes the new task query to `EnhancedQuery`, and marks the task as running. This state isolation reset ensures that each subtask sees a clean state when generating and executing SQL, unaffected by residual data from previous tasks.

[0107] The routing rules of the task dispatcher include: if there are running tasks in the task list, the task is routed to the SQL generation node; if there are no running tasks and the number of completed tasks is zero, the task is routed to the error handling node; if there are no running tasks and the number of completed tasks is one and the strategy is single, the task is routed to the chart building node; if there are no running tasks and the number of completed tasks is greater than zero, the task is routed to the response synthesis node.

[0108] Dynamic sequential drill-down method. Dynamic sequential drill-down is used to support chain-like analysis of causal reasoning. The trigger condition is that the NeedReplan flag in the execution plan is true, which is set by the query planning node under the sequential or hybrid strategy.

[0109] The replanning process includes: traversing all completed subtasks in the execution plan, constructing a completed step context, which includes the query, SQL statement, and analysis conclusion for each subtask; injecting UserQuery, SchemaContext, and the completed step context into the language model, requiring the language model to determine whether the current analysis chain has fully answered the user's question; the language model outputs a decision field, with next_query and title appended when decision is continue, and the system creates a new subtask to be executed and appends it to the end of the execution plan; when decision is wrap_up, NeedReplan is set to false.

[0110] To prevent dynamic drill-down from degenerating into an unbounded free-flowing inference loop, the system sets hard stopping conditions: the total length of the task list reaches MaxTasks; the new query duplicates a completed query; the result of the previous subtask is empty; no significant anomalies were found in the previous subtask, where significant anomalies are determined by the rate of change of a numerical indicator relative to the previous period or historical mean, the standard deviation multiple, or the dimensional contribution exceeding a preset threshold; the schema context does not support the next query; continuous replanning cannot generate valid new dimensions; or the language model decides to wrap_up. Significant anomaly detection can employ at least one configurable rule: the rate of change of the current indicator relative to the previous period exceeds a preset percentage threshold; the standard deviation multiple of the current indicator relative to the historical mean exceeds a preset multiple threshold; or the proportion of a dimension's decrease contribution to the total decrease exceeds a preset contribution threshold.

[0111] Streaming output and visualization of the thought process. This invention designs a unified output writer interface, through which all workflow nodes can push events to the front end. Event types include token, thinking_step, chart_data, and done. An example of the output writer interface is shown in the table below.

[0112]

[0113] The output writer maintains a "thinking phase complete" flag. On the first call to WriteToken or WriteChartData, all ongoing thinking steps are automatically closed, a collapse signal with ID 'collapse' or '__collapse__' is emitted, instructing the front end to collapse the thinking process card, and the thinking phase complete flag is set to true. Subsequent WriteToken calls no longer trigger phase switching.

[0114] In the implementation, workflow nodes act as producers, writing content blocks to the output stream through buffered pipes. Transport layer consumers read content blocks from the pipes and convert them into server-side events pushed to the client browser. Producers and consumers run in independent concurrent execution units, with the pipes maintaining a first-in, first-out (FIFO) order, allowing consumers to read remaining content from the buffer even after the pipes are closed. In interleaved output mode, chart data is emitted immediately after the corresponding subtask text conclusion, rather than waiting for all subtasks to complete before being output uniformly.

[0115] Data standardization and visualization output. This invention performs multi-level standardization processing in the data output stage. Column-level semantic types employ a dual-source fusion strategy. The SQL generation node declares the semantic type of each column through `column_types`, for example, `total_amount` is `currency` and `refund_rate` is `percent`. The SQL execution node infers the date, datetime, and numeric type based on the actual return value. The fusion rule prioritizes the type declared by the language model; if the language model does not declare a type, it falls back to inferring the type from the execution result.

[0116] Chart specifications are configured declaratively using a language model. The SQL generation node outputs `analysis_type` and `chart_schema` along with the SQL query. `analysis_type` is suitable for line charts when set to `trend`, bar charts when set to `comparison`, pie charts when set to `composition`, histograms when set to `distribution`, and tables when set to `detail`. `chart_schema` includes `x_axis`, `y_axis`, and `group`.

[0117] Before constructing chart data, the system performs chart validity checks: It checks if x_axis, y_axis, and group exist in the query result columns; it checks if the column corresponding to y_axis is of type number, currency, or percent; it verifies if the combination of x_axis and group is unique across all data rows; trend analysis preferentially requires x_axis to be of type date or datetime; composition analysis requires both categorical and numerical columns; detailed analysis outputs a table by default. If the query result has zero rows, only one row with the analysis type set to detail, the axis field is missing, the numerical column validation fails, or the uniqueness check fails, the statistical chart output is skipped, and only the text conclusion or table is retained.

[0118] When the chart's X-axis is a date type, the system scans all actual values ​​in that column and automatically infers the coarsest appropriate granularity: if all values ​​are in YYYY-MM format, the granularity is month; if all values ​​are in YYYY-MM-DD format, the granularity is day; if there is an HH:MM:SS time component, the granularity is date and time. After inference, the system uniformly formats all values ​​in the column to the standard format corresponding to the granularity.

[0119] The internationalization of currency formats is determined by the merchant's Currency field, and the response generation node injects the currency formatting rules into the language model prompts. For example, USD uses the dollar sign, two decimal places, and commas for thousands; JPY uses the yen sign and zero decimal places; EUR uses the euro sign and thousands separators and decimals according to regional conventions; BRL uses the real sign and corresponding separators. The SQL generation node also outputs localized display labels for each result column through column_labels, and the chart building node uses these labels to replace the original column names. All numerical values ​​in the chart data are serialized as strings to avoid loss of precision in JavaScript numerical values.

[0120] Multi-turn dialogue context management. After each analysis, the system compresses the current dialogue into a turn summary. The turn summary includes the user query text, the query for each subtask, the SQL, the analysis type, the number of result rows, the list of column names, and a preview of the first five rows of results. It is stored in session-level persistent storage in structured JSON format, and can retain up to twenty turns.

[0121] The total size of the round summaries is limited to 32 kilobytes. When this limit is exceeded, the system performs a two-stage compression. The first stage begins by clearing the column name list and result preview data from the oldest round, retaining only the query and SQL. If the first stage compression still exceeds the limit, the second stage deletes round summaries one by one from the oldest round until the size meets the limit.

[0122] When constructing the conversation history, the system performs a reverse scan and alignment between the persistent round summary and the message history. For each assistant's reply in the message history, the corresponding round is found from the round summary, and the SQL statement is populated back into the Tasks field of ConversationHistory. Therefore, subsequent queries such as "What about yesterday?", "Further breakdown by region", and "Compare with last time" can reference historical SQL and historical analysis conclusions. Historical SQL is only used as a contextual reference and is not directly reused for execution; new SQL generated based on historical SQL still needs to undergo schema constraints, permission verification, merchant isolation verification, and SQL security verification again.

[0123] Perform an audit trail. The system creates a trail collector instance each time a workflow is executed, accumulating query information, planning information, subtask execution information, decision chains, schema context, and cumulative metrics throughout the execution process. Query information includes UserQuery and EnhancedQuery; planning information includes decomposition strategies and language model planning descriptions; subtask execution information includes task identifier, query text, execution status, SQL statement, SQL explanation, analysis type, number of result rows, analysis conclusion, execution time, number of retries, and failure error messages; the decision chain includes feasibility judgment results, query planning decisions, replanning decisions, and the next query; the schema context includes a list of retrieved table names, a summary of knowledge entries, and schema hints; and cumulative metrics include the number of language model calls and token consumption.

[0124] Tracking data is asynchronously written to a separate audit table upon workflow completion, with a 90-day retention period independent of the conversation messages. The audit table includes independently queryable statistical columns such as decomposition strategy, total number of tasks, number of completed tasks, number of failures, total execution time, language model call count, token consumption, and retries; it also includes JSON audit columns such as subtask execution details, complete decision chain, and schema context summary. SQL statements in the subtask execution details are truncated to 4,000 characters. Sensitive fields such as access tokens, user identifiers, email addresses, and phone numbers are anonymized before being written to the audit table. Access control is set for the audit table based on MerchantID and UserID, and data is automatically deleted or archived after the retention period expires. This mechanism supports analysis of success rate statistics, SQL quality assessment, A / B testing of prompt word strategies, performance bottleneck location, and root cause analysis.

[0125] The present invention will be further described below with reference to specific embodiments.

[0126] Example 1: Single Task Indicator Query The user inputs "How many orders are there today?", and the merchant is configured with the timezone America / New_York, currency USD, and language zh-CN. The query enhancement node resolves "today" to March 23, 2026, identifies "orders" as transaction entities, and outputs EnhancedQuery as "number of orders in the America / New_York timezone on March 23, 2026". ExpandedQueries includes "2026-03-23 ​​daily order count", and ExtractedTerms includes "orders".

[0127] The Schema retrieval node concurrently sends Schema retrieval requests and business knowledge retrieval requests. Schema results include columns such as trade_id, created_at, merchant_id, status, amount, and currency from the transaction view table, while business knowledge includes the terminology definition of "order." The feasibility assessment node confirms that the transaction table contains time and merchant filter fields, outputting FeasibilityResult as data_analysis. The query planning node, having failed to detect any decomposition signal words in the first stage, directly constructs a single-task plan using a single-strategy approach.

[0128] The task executor sets the task to running and clears the task step status. The SQL generation node injects the SchemaDDL segment and business knowledge segment, and outputs a read-only SQL statement counting by order identifier, such as counting the number of orders from a specified merchant on March 23, 2026. It also outputs an analysis_type of "detail", an order_count of "number" in column_types, and an order_count of "order quantity" in column_labels. After the SQL security check confirms that the SQL is a SELECT query and contains merchant isolation conditions, the SQL execution node calls the data analysis service to execute it and returns Rows as [{order_count:5}] and RowCount as 1.

[0129] The system responds to injected queries, SQL interpretations, column definitions, JSON results, and USD currency rules, streaming the output "A total of 5 orders were generated on March 23, 2026". Because the analysis type is detail and contains only one row of data, the chart building node determines it is unsuitable for generating a statistical chart and skips the chart output. Finally, the system generates a round summary and writes it to the audit trail data.

[0130] Example 2: Multi-task parallel query The user inputs "What are the order volume, sales revenue, and refund rate for this month?" After the query enhancement node completes time range parsing and terminology extraction, the schema retrieval node concurrently retrieves the order table, payment table, and refund table, and merges relevant columns and indicator definitions.

[0131] The query process identifies parallel decomposition signals such as "separately" in the first stage of the planning node, triggering the second stage of deep decomposition. The language model outputs a parallel strategy and generates three independent subtasks: monthly order volume statistics, monthly sales statistics, and monthly refund rate statistics. Each subtask has a unique identifier, a display title, whether a chart icon is needed, and a pending execution status.

[0132] When the task executor schedules the first subtask, it resets the task step status area and executes SQL generation, security verification, SQL execution, and step conclusion generation. Upon completion, it writes the task's SQL, results, conclusions, and chart specifications into the execution plan. If the subtask requires a chart and the query results pass chart validity validation, it immediately constructs and emits the corresponding chart data in interleaved output mode. If the result is a single-row scalar, it skips the chart or outputs it as an indicator card. The second and third subtasks are then scheduled. Before each subtask begins, the `GeneratedSQL`, `ExecutionError`, `RetryCount`, and `ChartSchema` fields are reset. If one subtask fails due to a permission error, the task executor marks it as failed and continues executing other subtasks. The response synthesis node generates a comprehensive report based on successful subtasks and provides user-friendly explanations for failed subtasks.

[0133] Example 3: Sequential Drilling Root Cause Analysis The user inputs "Why did sales drop last week?". The query planning node in the first stage hits causal decomposition signals such as "why" and "dropped," triggering deep decomposition. The language model generates a sequential policy with the initial task being "daily sales trend last week," and sets NeedReplan to true.

[0134] After executing the initial task, the system obtained seven rows of daily sales data. The step conclusion showed a significant decrease of approximately 40% on March 19th. Since NeedReplan is true, the system has completed the step context, including the query, SQL, and conclusion for Task 1, and invoked the replanning node. The replanning node outputs "continue" for decision, and the next query is "Comparison of sales revenue for each product category on March 19th," which the system appends to Task 2.

[0135] Before Task 2 begins, the task executor clears the SQL, execution results, error messages, retry count, and chart specifications of the previous task. The SQL generation node injects the SQL and conclusions from Task 1 into the completed task segment, generating queries grouped by category for March 19th. The execution results show that the sales decline in the electronics category is the largest, and the step conclusions indicate that this category is the main contributing factor. The replanning node again determines, based on the context of Step 1 and Step 2, that the root cause has been located at the category level, outputs wrap_up, the system stops replanning, and synthesizes a root cause analysis report containing overall trends, abnormal dates, abnormal categories, and suggested areas of focus.

[0136] Example 4: Fault-Tolerant Retry Scenario The user inputs "the 5 orders with the highest refund amounts last week". The initial SQL generation node outputs SQL referencing the `refund_amount` field, but the actual refund field in the schema is `refund_total`. After the SQL security check passes the read-only validation, the SQL execution node returns the error: `[invalid_sql] Unknown column refund_amount`.

[0137] The execution dispatcher categorizes this error as a retryable error related to table column matching. Since RetryCount is 0 and MaxRetries is 3, the system increments RetryCount and routes back to the SQL generation node. The SQL generation node injects the previous SQL and error information into the error message section and regenerates the SQL using the refund_total field, combining this with the actual column names in the schema. The second SQL execution succeeds, returning five rows of refund order data. The system then generates a text conclusion and a detailed table. If the retries fail after reaching the limit, a user-friendly error is output in single-task mode, while in multi-task mode, the subtask is marked as failed and subsequent tasks continue.

[0138] Example 5: Multiple rounds of follow-up questioning and context filling In the first round of conversation, the user queries "last week's sales trend". After completing the analysis, the system writes the query, SQL, analysis type, number of result rows, column name list, and preview of the first five rows of results into a round summary. In the second round of conversation, the user asks, "What about yesterday?" The query enhancement node identifies "that" from the ConversationHistory, referring to the previous round's sales trend, and normalizes the follow-up question to "statistics on yesterday's sales metrics".

[0139] When the user further inputs "Compare with last time," the system, while constructing the dialogue history, fills the SQL from the round summary into the task field of the assistant's reply. This allows the SQL generation node to clearly identify the metrics, table structure, and filtering conditions involved in the previous analysis, and generates the comparison SQL accordingly. If the total size of the round summary exceeds 32 kilobytes, the system first clears the column name list and result preview of the old rounds, and then deletes the oldest round if necessary, to ensure that the context capacity is controllable.

[0140] Example 6: Processing after the secondary schema search reaches its limit The user inputs "Analyze changes in repeat purchase contribution rate by channel". The first schema search only retrieves the order table and customer table, but the feasibility judgment node determines that the channel attribution table is missing, outputting need_recall, with FeasibilityContent as "channel attribution table, repeat purchase user definition, order source field". Since SchemaRecallCount has not reached its limit, the process is routed back to the schema search node and the content is appended to the search query set.

[0141] If the channel attribution table is still not found after the second schema search, the feasibility assessment will still return need_recall, at which point SchemaRecallCount has reached its limit. The system will no longer continue searching, but will generate a clarification or service unavailable message, such as "The current data source does not have a channel attribution field. Please confirm whether channel data has been accessed or whether an available field has been provided." This branch avoids infinite loops caused by insufficient schema.

[0142] Example 7: SQL Security Verification Scenario The user inputs "Delete this month's test orders and then calculate sales." The query enhancement node recognizes that this request contains data analysis objectives. However, if the SQL generation node outputs a DELETE statement or contains multiple statements for execution, the SQL security verification node will directly intercept the SQL, mark it with an ExecutionError as unsafe_sql, and prohibit entry into the SQL execution node. The error handling node outputs a user-friendly message explaining that the current system only supports read-only data analysis and cannot perform operations to delete or modify data.

Claims

1. A data-driven AI agent implementation method based on state diagrams, characterized in that, The method is executed by a computer device and includes the following steps: S1. Receive natural language data input from the user for analysis and query, initialize the global state object based on merchant identifier, user identifier, time zone, settlement currency, conversation language and dialogue history, and set the current node pointer as the starting node by the deterministic state graph workflow engine. S2. Execute the query enhancement node to normalize the natural language data analysis query into an enhanced query, generate an extended query list that is semantically equivalent to the enhanced query, and extract a list of business terms. S3. Construct a schema search query set based on the enhanced query, the expanded query list, and the supplementary search content generated in the secondary search scenario; construct a business knowledge search query set based on the natural language data analysis query and the business terminology list; and perform concurrent searches on the schema search query set and the business knowledge search query set respectively. S4. Perform column-level join and merge on the database table structure results obtained by concurrent retrieval according to table name and column name, and perform deduplication and merge on the business knowledge results according to knowledge item name to form a schema context; S5. Perform a feasibility assessment based on the Schema context to obtain a feasibility assessment result. The feasibility assessment result includes at least three categories: analyzable, requires further retrieval, requires clarification, and casual conversation. S6. When the feasibility judgment result is analyzable, execute the query planning node. First, perform rule filtering by decomposing signal words and delimiters. When the decomposition signal is hit, call the language model to perform deep decomposition to generate an execution plan including decomposition strategy, sub-task list and whether replanning is needed. S7. Schedule subtasks according to the execution plan, reset the task step state area in the global state object before each subtask starts, and sequentially execute SQL generation, SQL security verification, SQL execution, error classification, and limited retries based on error type for the current subtask. S8. Generate step conclusions based on SQL execution results; when the replanning flag in the execution plan is true and the current subtask meets the replanning triggering condition, generate the next drill-down subtask or end the analysis decision based on the query, SQL statement and step conclusion of the completed subtask. When no more subtasks are added, the final response is generated, and column-level semantic type fusion, chart validity validation, date granularity unification, amount format internationalization, column display name localization, and numerical serialization standardization are performed on the output data. S9. Output the thought process, text conclusions, chart data and completion events to the client in the form of streaming events through the output writer, and persist multi-turn dialogue summaries and execution audit trail data after the workflow is completed; The deterministic state graph workflow engine determines the next node after the node execution is completed based on the dispatcher registry or edge definition table. The next node is determined by the state flag bit in the global state object.

2. The method according to claim 1, characterized in that, The deterministic state graph workflow engine includes a node registry, a dispatcher registry, and an edge definition table. The node registry is used to establish a mapping between node names and node instances, the dispatcher registry is used to establish a mapping between node names and condition dispatchers, and the edge definition table is used to establish a mapping list between predecessor nodes and successor nodes. Each workflow node receives the execution context, global state object, and output writer through a unified interface, and writes the processing result back to the global state object after processing is completed.

3. The method according to claim 1, characterized in that, The deterministic state graph workflow engine, when executed, includes: setting the current node pointer to the starting node; checking whether the execution context has been canceled; obtaining the current node instance from the node registry and executing the corresponding processing logic; first querying the dispatcher registry to obtain the next node name, and if no corresponding dispatcher exists, querying the edge definition table to obtain the next node name; updating the current node pointer to the next node, and exiting the loop when the next node is the terminating node.

4. The method according to claim 1, characterized in that, Under the conditions of the same global state object and the same node output results, the condition dispatcher outputs the same next node name; and, for language model calls, a fixed model version, fixed sampling parameters, structured output format verification, and cache key based on session identifier, user query, and schema context summary are set, and a preset fallback strategy is executed when structured output verification fails.

5. The method according to claim 1, characterized in that, The global state object includes at least query-related fields, schema context fields, feasibility judgment fields, task execution plan fields, task step status fields, output-related fields, and merchant context fields; among which, query-related fields include UserQuery, EnhancedQuery, ExpandedQueries, ExtractedTerms, and ConversationHistory; schema context fields include SchemaContext and SchemaRecallCount; and feasibility judgment fields include FeasibilityResult and FeasibilityContent.

6. The method according to claim 5, characterized in that, The task execution plan fields include Plan, decomposition strategy, subtask list, current execution index, and NeedReplan flag; each subtask includes a unique identifier, query text, display title, list of dependent task identifiers, whether a chart is needed, task status, query results, conclusion text, and chart specifications; the task step status fields include GeneratedSQL, SQLExplanation, QueryResult, ExecutionError, RetryCount, AnalysisType, ChartSchema, ColumnTypes, and ColumnLabels.

7. The method according to claim 1, characterized in that, The query enhancement node generates structured results through a non-streaming language model call. The structured results include a normalized query, an expanded query list, and an extracted terminology list. The normalized query is used to parse relative time into absolute dates based on the merchant's time zone, parse referential objects into explicit business objects, and normalize business terms. When the language model call fails or the structured result parsing is abnormal, the enhanced query is set to the user's original query, and the expanded query list and extracted terminology list are set to empty lists.

8. The method according to claim 1, characterized in that, The concurrent retrieval includes a schema retrieval track and a business knowledge retrieval track that are independent of each other. The schema retrieval track sends a SearchSchema request to the retrieval enhancement generation service for each query in the schema retrieval query set, and returns a list of database table structures including table names, table descriptions, and column definitions. The business knowledge retrieval track sends a SearchBusinessKnowledge request to each query in the business knowledge retrieval query set, and returns the Top-K business knowledge entries, where K is set to 3 by default.

9. The method according to claim 8, characterized in that, The business knowledge items include one or more of the following: business term definition (business_term), metric definition (metric_definition), SQL example (sql_example), business rule (business_rule), and analysis method (analysis_playbook).

10. A data-driven AI intelligent agent system based on state diagrams, characterized in that, include: The system comprises a state graph workflow engine, a query enhancement module, a schema retrieval and merging module, a feasibility assessment module, a query planning module, a task execution module, an SQL generation module, an SQL security verification module, an SQL execution and fault tolerance module, a response and chart construction module, a streaming output module, a multi-round context management module, and an audit trail module; wherein each module is configured to collaboratively execute the method described in any one of claims 1 to 9.

Images