A Multi-Source Context Retrieval and Intent Execution Method

Abstract

This invention relates to the fields of artificial intelligence and computer application technology, specifically a multi-source contextual retrieval and intent execution method. The method includes: retrieval, processing, and token budget truncation based on a given user question and user identifier; generating contextual text that can be securely injected into the system prompt of a large language model system; determining the user intent type and entity; generating an executable plan JSON from a predefined plan template; inputting the user's natural language and available table structures; outputting deterministic data and charts for user requests identified as data analysis requests; and segmenting LLM calls according to token budget to generate AI insights and stream them. The multi-source retrieval and injection algorithm achieves reproducible merging and truncation under a unified data structure and sorting rules, and is combined with token budgeting. It is suitable for AgentOS shared by multiple tenants and business lines, reducing redundant integration and inconsistencies in context across applications, and improving integrability.

Description

Technical Field

[0001] This invention is a multi-source context retrieval and intent execution method, belonging to the field of artificial intelligence and computer applications. Background Technology

[0002] With the increasing prevalence of large language models, enterprise intelligent assistants and business AI agents have become core carriers of digital transformation. Currently, the mainstream implementation methods in the industry are divided into two categories: traditional AI application assembly solutions and customized enterprise agent products, which respectively rely on plug-in assembly and core algorithm adaptation to achieve business deployment.

[0003] However, the two existing technical approaches can only be adapted to simple basic business. When faced with complex production-level scenarios such as cross-system collaboration, closed-loop execution, and professional data analysis, they have inherent defects in architecture and algorithms and cannot meet the requirements for high precision, high collaboration, and high controllability.

[0004] Traditional agent or AI application assembly solutions suffer from the following common drawbacks: First, there is the problem of application silos, with each business line independently deploying chatbots or automated scripts. Knowledge bases, memory, and permission models are inconsistent, requiring users to switch between multiple entry points, failing to form a unified enterprise-level intelligent agent entry point. Second, there is context fragmentation; RAG, session memory, user profiles, and file memory often belong to different storage and retrieval paths, lacking unified merging, sorting, visibility filtering, and token budget linkage truncation algorithms, easily leading to injection chaos, excessive length, or leakage of unauthorized content. Furthermore, intent is disconnected from execution, relying on a single classification model or hard-coded branches, lacking rule scoring, entity extraction, templated plans, and traceable execution semantics for verification and automatic correction. The plan is difficult to align with the actual capability set, hindering auditing and expansion. Moreover, natural language to SQL conversion often relies on a single rule or model, with weak multi-table JOIN inference, making stable alignment with the enterprise's actual table structure and permission views difficult, resulting in an unstable bridge between natural language and structured data. In addition, data analysis is mostly generated in one long article, lacking algorithms that first establish deterministic data and charts, and then provide segmented streaming insights. It also lacks segmented calls based on token budgets and anti-duplication constraints, which affect readability and stability, resulting in uncontrollable analytical output.

[0005] In enterprise intelligent assistants and various agent products based on large language models, existing technical approaches also have the following shortcomings at the algorithm level: In terms of retrieval and injection, the knowledge base and dialogue memory belong to different storage and retrieval paths, lack a unified multi-source merging, visibility filtering and relevance ranking algorithm, and are not considered in conjunction with context length constraints. This can easily lead to excessively long injected content, unreasonable injection order, or duplicate construction of retrieval logic between different AI applications, making it impossible to share the same AgentOS-level strategy.

[0006] In terms of intent and execution, user intent also relies heavily on a single classification model, lacking a complete algorithm chain of rule scoring, entity extraction, templated planning, and verification and automatic correction. The execution plan is difficult to match the actual capability, making it difficult to provide the capability of an enterprise-level programmable and auditable intelligent agent operating system.

[0007] In terms of querying data using natural language, natural language to SQL conversion often relies on a single rule or model. The inference and completion of multi-table joins lack clear algorithmic steps, resulting in poor reproducibility and maintainability. Furthermore, the integration cost with enterprise multi-source table structures and permission views is high.

[0008] In terms of data analysis and streaming, data analysis responses are mostly generated in one go, lacking segmented streaming output algorithms that first provide deterministic data and charts and then AI insights, as well as segmented calling and truncation strategies based on token budgets, which is not conducive to stable push to various clients within the unified AgentOS event channel.

[0009] The aforementioned shortcomings have remained unresolved in the industry for a long time because these problems are not localized bottlenecks of a single algorithm or module, but rather coexist simultaneously in multiple stages, including multi-source retrieval integration, visibility and permission filtering, contextual budget control, intent recognition and execution semantic mapping, natural language to structured query conversion (including multi-table JOIN inference), and segmented streaming output of data analysis. These stages not only differ in technical nature but also share the same context space, the same execution entry point, and the same security boundary. Therefore, any single-point optimization cannot solve the problem at the system level.

[0010] Specifically, existing solutions cannot simultaneously process the main system's knowledge base, enterprise file vector library, and multi-source memories (identity snapshots, session snapshots, file memories, etc.) during the retrieval phase, and achieve unified sorting, unified threshold filtering, and unified Top-K control. Furthermore, user visibility filtering must be applied during the retrieval phase, and truncation must be linked to the token budget. Traditional solutions often retrieve and concatenate information independently by source, leading to content redundancy, unauthorized leaks, disordered sorting, or excessively long contexts, making it difficult to form a reusable framework. Multi-source context retrieval is challenging because it requires simultaneously satisfying both uniformity and budget constraints.

[0011] Common intent classification methods in the industry can only output category labels and cannot directly generate executable JSON plans. This makes it difficult to implement a complete process involving rule scoring, entity extraction, template-based plan generation, executability verification, automatic correction, and further verification. Achieving this process requires converting natural language into plan objects with explicit execution semantics and parameter structures, resulting in technical and engineering complexity far exceeding traditional intent recognition methods. Furthermore, there is a lack of stable mapping between understandable and executable intents.

[0012] Enterprise databases often have complex structures with non-explicit table relationships, making it impossible to reliably infer multi-table joins using a single model. The industry lacks a complete solution that simultaneously integrates table structure, naming conventions, rule engines, model parsing, templated SQL output, and privilege escalation restrictions. Therefore, the reliability, executability, and security of generated SQL are difficult to guarantee. The challenges of natural language to SQL translation lie in multi-table join inference and permission view adaptation.

[0013] Generating large chunks of insight content at once often results in unstable output, repetition, incorrect ordering, information overload, or front-end lag. It's difficult to break down data tables, charts, source information, and AI insight text into segmented events, call the large model segment by segment based on token budget, and add constraints to each segment to ensure continuation without repeating previous text. Currently, the industry lacks a mature and unified solution for this hybrid structure of deterministic generation combined with segmented streaming, making it difficult to simultaneously achieve deterministic output and control over long streaming output.

[0014] In summary, these issues span multiple subsystems, including retrieval, permissions, security, planning, database constraints, and streaming generation. They require a unified and coordinated system-level algorithm framework and cannot be solved by improving a single module. Therefore, an algorithm solution is needed that features clear algorithm steps, a clear data flow, and verifiable technical effects. Furthermore, it should be reusable by various enterprises and users as the core algorithm of AgentOS without being tied to a specific industry. Summary of the Invention

[0015] To address the problems in the prior art, this invention provides a multi-source context retrieval and intent execution method.

[0016] The technical solution adopted by this invention to solve its technical problem is: a multi-source context retrieval and intent execution method, comprising: Step S1: Based on the given user question and user identifier, perform retrieval, processing, and token budget truncation to generate context text that can be securely injected into the system prompt of a large language model; Step S2: Based on the user message and context, determine the user intent type and entity, generate an executable plan JSON from the predefined plan template, and persist it after verification and automatic correction for the executor to execute step by step; Step S3: Take the user's natural language and available table structure as input, and output the structured query intent and executable SQL, as well as optional chart configuration; Step S4: For user requests that have been identified as data analysis requests, first output deterministic data and charts, then call LLM in segments according to Token (word) budget to generate AI insights and push them in a streaming manner.

[0017] Furthermore, the retrieval and processing in step S1 includes retrieving relevant content from the main system knowledge base, the enterprise document vector library, and multiple memory sources, and performing merging, sorting, and visibility filtering operations.

[0018] Further, the inputs in step S1 include the user question string Q, user identifier U, context length configuration C_{ctx}, number of reserved generated tokens R_{gen}, the proportion of tokens corresponding to each Chinese character\rho, Top-K parameters of each source, and minimum relevance threshold\theta; The output in S1 includes the plain text context T_{ctx} for injection.

[0019] Further, step S1 includes: For user questions and user identifiers, search the main system knowledge base and enterprise document vector library, and filter by user visibility; The two results are merged into a unified record structure, sorted in descending order of relevance, and items below the threshold are filtered out and the top K items are selected. The retained items are converted into plain text and concatenated into additional context. At the same time, the results are retrieved from multiple memory sources according to user and visibility. The results from each source are globally reordered and the top K results are taken to generate structured profile text. The available token budget for the system segment is calculated based on the configured context length and reserved generation space. The additional context and memory profile are truncated according to the character and token ratio and then injected into the system prompt.

[0020] Further, the inputs to step S2 include the user message string M, the context C, the intent rule table R, the plan template set \mathcal{T}, and the confidence threshold \tau; The output of step S2 includes intent type I, confidence level p, entity set E, plan JSON P, and validation pass flag.

[0021] Further, step S2 includes: After preprocessing and filtering user messages, if the "forced data analysis" condition is met, the data analysis intent and entity are directly output. Otherwise, scores are calculated for each intent type except for clarification according to the rules, and the intent with the highest score is selected. If the score is lower than the confidence threshold, it is classified as an unknown intent. Extract entities from the message and context based on the selected intent type; Select a template from a predefined plan template set based on intent type and entity, and populate the step parameters in the template with entities and context to obtain the plan JSON; Perform a validity check on the JSON of the plan; if it fails, perform automatic correction and then check again. Persist the list of steps that have passed the validation.

[0022] Furthermore, the input to step S3 includes the user's natural language query Q and the currently available table structure information \mathcal{F} The output of step S3 includes the structured query intent Y, the generated SQL string \sigma, and the execution result.

[0023] Further, step S3 includes: Receive user natural language input and the currently available table structure; Prioritize using rule-based engines and LLM-based engines to parse structured query intents; If the number of tables is greater than 1 and the relationships are missing, the JOIN relationship will be inferred and filled in based on the similarity between table names and column names or the agreed rules. Select an SQL template based on the intent type and number of tables, and generate SQL by filling in columns, conditions, aggregations, groupings, sorting, and JOIN conditions; Execute the SQL and generate chart configurations based on the number of rows and column types in the results.

[0024] Furthermore, the inputs to step S4 include user question Q, session identifier, user identifier, context length C_{ctx}, upper limit of each insight token S_{seg}, and maximum number of segments N_{seg}; The output of step S4 includes a sequentially pushed SSE event stream: template, charts, sources, insight_start, insight content, and done.

[0025] Further, step S4 includes: For requests identified as data analysis requests, first perform data aggregation or single-table queries to obtain structured data and data source tracing; Output deterministic template events and key indicators, then output chart configuration events, and then output data source events; The upper limit of tokens for each AI insight is calculated based on the context length and reserved space. The AI ​​insight is then split into multiple segments, each of which independently calls LLM and is pushed in a streaming manner. A prompt "Continue output, do not repeat the previous text" is added between segments. Output a completion event.

[0026] The beneficial effects of this invention are: The multi-source retrieval and injection algorithm achieves reproducible merging and truncation under a unified data structure and sorting rules, and is combined with token budgeting. It is suitable for AgentOS shared by multiple tenants and multiple business lines, reducing the problem of repeated integration and inconsistent context among various applications, and improving versatility and integrability.

[0027] The intent and execution plan algorithm generates traceable and verifiable execution plans through rule scoring and template filling, which facilitates the expansion of new tools and processes within the enterprise environment without disrupting the overall semantics, forming an auditable execution loop.

[0028] Natural Language to SQL algorithms improve the executability and maintainability of complex queries by combining rules with LLM and multi-table JOIN inference, reducing the marginal cost for enterprises to integrate existing data assets into intelligent agents, and ensuring high data-side maintainability.

[0029] The data analysis streaming algorithm achieves stable streaming output of AI insights by controlling the fixed event sequence and token segments, while ensuring that data and charts come first. It is suitable for a unified experience baseline for various enterprises and end users, and has a stable human-computer collaboration experience. Attached Figure Description

[0030] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a technical logic diagram of a multi-source context retrieval and intent execution method according to the present invention; Figure 2 This is a flowchart of the multi-source context retrieval and injection algorithm in the multi-source context retrieval and intent execution method of the present invention; Figure 3 This is a flowchart of the method for generating and self-healing the execution plan driven by intent in a multi-source context retrieval and intent execution method of the present invention. Figure 4 This is a flowchart of the natural language to SQL method in the multi-source context retrieval and intent execution method of the present invention; Figure 5 This is a flowchart of a data analysis segmented streaming output algorithm in a multi-source context retrieval and intent execution method of the present invention. Detailed Implementation

[0031] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0032] This invention relates to an algorithm deployed on the AgentOS layer. AgentOS refers to a layer of intelligent agent operation and orchestration middleware deployed on enterprise information systems, targeting any industry and organization of any size, and also serving individual professional scenarios. Under a unified security boundary, identity, and visibility model, it integrates Large Language Model (LLM), Retrieval Augmentation (RAG), multi-class memory, data analysis, external tools, and existing enterprise applications into orchestratable, auditable, and scalable intelligent agent services, rather than isolated single-point AI applications.

[0033] The algorithms include four types: multi-source context retrieval and injection algorithm, intent-driven execution plan generation and verification algorithm, natural language to structured query and SQL generation algorithm, and data analysis streaming output and token segmentation control algorithm. These algorithms are applied to the Large Language Model (LLM) dialogue and intelligent agent execution system to achieve integrable, reproducible, secure, and controllable retrieval enhancement, intent understanding, and task execution under conditions of multiple knowledge sources, multiple memory sources, and multiple application interfaces. They also support the integration of AI applications across business lines, enabling the entire chain of dialogue—retrieval—planning—execution—streaming presentation to work collaboratively under the same set of contextual budgets and execution semantics. This makes it suitable for differentiated use by all enterprises and all authorized users on the same platform, without relying on a separate, incompatible agent stack for each business.

[0034] The four algorithms mentioned above can be implemented as independent service modules or pipeline stages within the same runtime environment. They can also be combined as pre- and post-stages in a single dialogue request processing pipeline, or deployed separately according to load.

[0035] Please see Figure 1 This embodiment provides a multi-source context retrieval and intent execution method, including the following steps: Step S1: Based on the given user question and user identifier, perform retrieval, processing, and token budget truncation to generate context text that can be securely injected into the system prompt of a large language model; Step S1 is based on Algorithm 1, namely the multi-source context retrieval and injection algorithm. Given a user question and user identifier, it retrieves relevant content in parallel or serially from the main system knowledge base, enterprise file vector library, and multiple memory sources. After merging, sorting, visibility filtering, and token budget truncation, it generates context text that can be securely injected into the large language model systemprompt. This serves as the unified context injection link of AgentOS, enabling "enterprise knowledge and personal / conversation memory" from different sources to enter the LLM under the same budget and sorting rules, which is beneficial for the integration of AI applications and knowledge assets.

[0036] Figure 2 This is a schematic diagram of a multi-source context retrieval and injection algorithm. It introduces the visibility predicate V corresponding to the user identifier U, and completes permission isolation during the retrieval stage. It solves the problem of cross-domain data visibility and token budget overflow by dynamically allocating the token budget of System / Context / Memory in proportion ρ.

[0037] The input for step S1 includes the user question string Q; user identifier U; current session identifier S; context length configuration C_{ctx}, such as 32768; reserved number of generated tokens R_{gen}; token ratio per Chinese character \rho, such as 0.35, i.e., approximately 2.86 tokens per character; Top-K parameters for each source, such as K_1, K_2; and minimum relevance threshold \theta, where user identifier U can be empty, indicating no filtering by user, and current session identifier S is optional; The output of step S1 includes the injection plain text context T_{ctx}, truncated by token budget; an optional list of search terms grouped by source; and a list of data sources.

[0038] Step S1 includes the following steps: Step 1.1: Calculate visibility parameters based on user identifier U: If user identifier U is empty, no visibility filtering is performed; otherwise, query the user's department, whether they are an administrator, and whether they are visible at the company level, etc., to obtain the visibility predicate and parameter set V; Step 1.2: In the main system knowledge base, use the vector representation of the user question string Q or full-text search, and search under the filtering conditions of the application parameter set to obtain list L_1. Each item contains title, content fragment, and similarity score s. In the enterprise document vector library, use the vector representation of the user question string Q to perform similarity search, and search under the filtering conditions of application V to obtain list L_2. Each item contains document meta-information, content fragment, and relevance score s. Step 1.3: Unify each item in list L_1 and list L_2 into a record structure of source (source / data source), title (title), content (content), score (score / point), merge them into list L, and sort list L in descending order by score; Delete all items in list L where score (score / points) < α, and take the first K_1 items of list L to get list L'; Step 1.4: Perform plain text processing on the content of each item in list L': remove HTML / Markdown tags to obtain concatenable text fragments, and concatenate the fragments in order into the string T_{rag}, with its attached context; Step 1.5: Retrieve from multiple memory sources, such as session snapshots, identity snapshots, and file memories. For each source, perform a retrieval based on the visibility rules of (Q, U, S) and the source. For session types, use vector retrieval and threshold filtering to obtain the Top-K records of that source. The results from each source are merged into a global list, sorted by relevance or time, and the first K_2 results are taken to obtain M. If user profiles or identity profiles exist, a structured profile text T_{profile} is generated. Format M and T_{profile} into a concatenable text T_{mem}.

[0039] Step 1.6: Calculate the available token budget for the system segment; B_{sys} = C_{ctx} - \text{estimate}(Q\text{'s Token(term)}) - R_{gen} -\Delta, where (\Delta) is the safety margin.

[0040] Convert the token budget to a character limit: N_{ch} = \lfloor B_{sys} \cdot \rho \rfloor. Let T_{all} = T_{rag} | T_{mem}, or concatenate according to priority.

[0041] If \text{len}(T_{all})>N_{ch}, then truncate T_{all} from the end or by paragraph to length N_{ch}. Output the truncated T_{all} as T_{ctx}.

[0042] The data flow of this algorithm is as follows: (Q, U, S) Visibility (V); ((Q, V)) Knowledge Base Retrieval (L_1), Vector Library Retrieval (L_2); (L_1 \cup L_2) Merge Sort Filter (L' \rightarrow T_{rag}); ((Q, U, S)) Multi-Source Memory Retrieval (M), Profile (T_{profile} \rightarrow T_{mem}); ((T_{rag}, T_{mem}, C_{ctx}, R_{gen}, \rho)\rightarrow) Budget and Truncation (T_{ctx}).

[0043] For user questions and user identifiers, the system searches the main system knowledge base and enterprise document vector library in parallel or serially, and filters them according to user visibility. The two results are merged into a unified record structure, sorted in descending order of relevance, and the items below the threshold are filtered and the top K are selected. The retained items are converted into plain text and concatenated into additional context. At the same time, the system searches from multiple memory sources (session snapshots, identity snapshots, document memories, etc.) according to user and visibility, performs a global reordering of the results from each source, selects the top K, and generates structured profile text. Based on the configured context length and reserved generation space, the system segment's available token budget is calculated. The additional context and memory profile are truncated according to the character to token ratio and then injected into systemprompt.

[0044] The multi-source contextual retrieval and injection algorithm simultaneously retrieves information from multiple sources, including the main system knowledge base, enterprise file vector library, identity snapshot, session memory, and file memory. User visibility filtering is applied during the retrieval phase. The multi-source results are uniformly sorted, thresholded, and controlled by a unified Top-K algorithm. The algorithm automatically truncates system prompt tokens (lexical units) based on contextual budget, dialogue tokens (lexical units), and model-reserved tokens (lexical units), and finally injects system prompts with a unified structure. This achieves a holistic process of multi-source merging, permission filtering, and budget-linked truncation, rather than a single-point action.

[0045] Step S2: Based on the user message and context, determine the user intent type and entity, generate an executable plan JSON from the predefined plan template, and persist it after verification and automatic correction for the executor to execute step by step; Please see Figure 3 Step S2 is based on Algorithm 2, namely the intent-driven execution plan generation and verification algorithm, which forms the core of task orchestration and governance capabilities in AgentOS.

[0046] The input for step S2 includes the user message string M; the context C, which includes session_id, user_id, current session file list, whether there are structured files, etc.; the intent rule table R, which includes the keyword list, regular expression pattern, whether it depends on data, etc. for each type of intent; the plan template set \mathcal{T}, where each template corresponds to the intent type, step list, parameter slots; and the confidence threshold \tau, such as 0.3. The output of step S2 includes intent type I, confidence p, entity set E, and plan JSON (P), which contains query_id (query ID / request identifier), intent, context, steps, fallback, and a validation pass flag. If it fails, it can be empty or return an error message.

[0047] Step S2 includes the following steps: Step 2.1, Preprocessing: m \leftarrow \text{lower}(\text{trim}(M)).

[0048] If M matches the "Clarification Required" rule, then set I \leftarrow \text{CLARIFICATION}, p ​​\leftarrow 0.95, E \leftarrow \varnothing, and go to step 2.6.

[0049] If M is identified as an instructional description for the Agent, then set I \leftarrow \text{GENERAL_CHAT}, p \leftarrow 0.9, E \leftarrow \varnothing, and proceed to step 2.6.

[0050] Step 2.2: If a matching structured file exists in C and m contains data analysis keywords, then set I\leftarrow \text{DATA_ANALYSIS}, extract entities from M and C to obtain E, set p \leftarrow0.88, and go to step 2.6.

[0051] Step 2.3: For each intent type t in R, excluding clarification, calculate the score s_t: Based on the keyword list of t, the regular expression pattern, and the matching of "whether it depends on data" with C, we obtain s_t \in [0,1].

[0052] Let (I, p) \leftarrow \arg\max_{(t,s_t)} s_t .

[0053] If p < tau, then set I \leftarrow \text{UNKNOWN}, p ​​\leftarrow 0.5, and extract entities from M and C based on I to obtain E.

[0054] Step 2.4: Select template T from \mathcal{T} based on I and E. If there is no exact match, select by priority or default.

[0055] Construct P based on T: fill in query_id, intent (=I), context (session_id, user_id, user_message, timestamp); for each step of T, fill the parameter slots with E and C to get the steps list; fill in fallback (if any).

[0056] Step 2.5: Perform a validity check on P, i.e., check the required fields, step dependencies, and parameter types; If the validation fails, automatic correction will be performed, which will fill in the missing required fields with default values, correct the step order and dependencies, and perform the validity validation again. If it still fails, return an error message; otherwise, convert P's steps to the execution plan storage format and persist it to obtain plan_id.

[0057] Step 2.6: Output I, p, E, P (and plan_id if it has been persisted).

[0058] The data flow of the algorithm is as follows: (M, C) Preprocessing and special intent judgment (I, E) or enter scoring; (M, R) Multi-intent scoring (I, p, E); (I, E, T, C) Template selection and parameter filling (P); (P) Validation and autocorrection (Persistence).

[0059] The intent-driven execution plan generation and validation algorithm preprocesses and filters user messages. If the "forced data analysis" condition is met, it directly outputs the data analysis intent and entity. Otherwise, it calculates scores for each intent type (excluding clarification) according to rules, selects the intent with the highest score, and classifies any intent below the confidence threshold as an unknown intent. Entities are extracted from the message and context based on the selected intent type. A template is selected from a predefined plan template set based on the intent type and entity, and the step parameters in the template are populated with entities and context to obtain the plan JSON. The plan JSON is validated for validity; if it fails, automatic correction (adding default values, correcting the step order, etc.) is performed before validation again. The list of validated steps is persisted. This provides AgentOS with auditable execution plan semantics, facilitating the integration of various backend capabilities in a templated manner and alleviating the traditional Agent's "intent-execution disconnect" problem. It achieves a complete closed loop of rule scoring, templated plan generation, and validation and automatic correction.

[0060] Step S3: Take the user's natural language and available table structure as input, and output the structured query intent and executable SQL, as well as optional chart configuration; Please see Figure 4 Step S3 is based on Algorithm 3, namely the Natural Language to Structured Query and SQL Generation Algorithm. The output structured query intent contains multi-table joins. In AgentOS, this algorithm serves as a standardized interface between enterprise data assets and conversational analytics capabilities, solving the challenges of multi-table join (JOIN) inference and SQL secure generation.

[0061] The input for step S3 includes the user's natural language query Q; the currently available table structure information \mathcal{F}, including the set of table names, the column names of each table, and optional sample data; and the enable / rollback strategy for the rule engine and LLM engine, which are optional.

[0062] The output of step S3 includes the structured query intent Y (intent_type, tables, columns, conditions, aggregations, group_by, order_by, limit, joins); the generated SQL string \sigma; the execution results containing rowsets; and optional chart configurations (type, axis, series) or server-side rendered chart path.

[0063] Step S3 includes the following steps: Step 3.1: If the LLM engine is enabled and available, take the text descriptions of Q and \mathcal{F} as input, call the large language model, and require the output to conform to the predefined JSON structure of the query intent; parse Y from the model output, including tables, columns, conditions, aggregations, groupings, sorting, limits (limits / data volume limits), and joins (joins / multi-table associations).

[0064] If not enabled or parsing fails, the rule engine is used: based on the keywords and patterns in Q, the intent_type (simple_query, aggregation, time_series, join_query) is identified, along with tables, columns, conditions, aggregations, group_by, order_by, and limit; if multiple tables are involved, joins are obtained from \mathcal{F} or rules.

[0065] Constrain the table names and column names in Y within the allowed range of \mathcal{F}. If the LLM output goes out of bounds, it will be trimmed or replaced with the closest valid identifier.

[0066] Step 3.2: If |Y.\text{tables}| ≥ 2 and Y.\text{joins} is empty or incomplete, then perform JOIN inference: Based on the similarity between table names and column names, such as id and xxx_id, name and name column, or predefined foreign keys / naming conventions, generate or complete the Y.\text{joins} list. Each item contains left_table (left table), right_table (right table), left_col (left column / left table field), right_col (right column / right table field), and type (join type) (LEFT / INNER / RIGHT). Step 3.3: Select the SQL template based on Y.\text{intent_type} and |Y.\text{tables}|: For a single table, simple SELECT statements, statements with WHERE, statements with aggregation, and GROUP BY statements are all acceptable. For multiple tables, use a SELECT statement with a JOIN clause.

[0067] Populate the template with Y's columns, conditions, aggregations, group_by, order_by, limit, and joins to generate sigma; Step 3.4: Execute \sigma on the target database, such as DuckDB, to obtain the result row set \mathcal{R}.

[0068] If the number of rows and column types of \mathcal{R} meet the chart generation conditions, then the chart type is selected based on intent_type and column type, and the chart configuration is generated, including type, axis, series, and optional server-side rendering chart path.

[0069] Data flow: ( (Q, \mathcal{F}) \rightarrow ) Rule or LLM parsing ( \rightarrow Y ) ; ((Y, \mathcal{F}) \rightarrow ) JOIN inference and completion ( \rightarrow Y' ) ; ( Y' \rightarrow ) SQL template filling ( \rightarrow \sigma ) ; ( \sigma \rightarrow ) Execution ( \rightarrow \mathcal{R} ) ; ( \mathcal{R} \rightarrow ) Chart configuration and rendering.

[0070] Natural Language to Structured Query and SQL Generation Algorithm: The algorithm takes the user's natural language and the currently available table structure (table names, column names, and optional samples) as input; it prioritizes or parallelly uses a rule engine and an LLM-based engine to parse out the structured query intent (tables, columns, conditions, aggregations, groupings, sorting, and multi-table joins); if the number of tables is greater than one and the joins are missing, it infers and completes the JOIN relationship based on the similarity of table and column names or agreed-upon rules; it selects an SQL template based on the intent type and the number of tables, fills in the columns, conditions, aggregations, groupings, sorting, and JOIN conditions to generate SQL; it executes the SQL and generates chart configurations based on the number of result rows and column types, establishing a stable and reproducible algorithmic bridge between AgentOS and the data layer, supporting the unified delivery of "data query" capabilities within the enterprise. The overall technical solution combines automatic multi-table JOIN inference, templated SQL generation, and permission view restrictions.

[0071] Step S4: For user requests that have been identified as data analysis requests, first output deterministic data and charts, then call LLM in segments according to Token (word) budget to generate AI insights and push them in a streaming manner.

[0072] Please see Figure 5 Step S4 is based on Algorithm 4, namely the data analysis streaming output and Token segmentation control algorithm, to ensure that the output order and length are controlled. In AgentOS, this algorithm works in conjunction with the unified event channel to avoid mutual interference between analysis capabilities and chat capabilities in terms of experience and resource consumption, and to solve the problems of Token redundancy and loading awareness in the generation of long insights.

[0073] The inputs for step S4 include the user question Q, which has been determined to be a data analysis type; the session identifier; the user identifier; the context length C_{ctx}; the upper limit of each insight token S_{seg}, or derived from (C_{ctx}) and the reserved space; and the maximum number of segments N_{seg}.

[0074] The output of step S4 includes the sequentially pushed SSE event stream: template, charts, sources, insight_start, insight(insight content); done.

[0075] Step S4 includes the following steps: Step 4.1: Determine whether it is a business dashboard or a single-table analysis based on Q.

[0076] For business dashboards, key metrics from various business tables are aggregated from a data source (such as DuckDB) to obtain structured data D and data source information \mathcal{S}. For single-table analysis, the target table is determined based on keywords or vector matching, and aggregation / trend queries are performed to obtain D and \mathcal{S}.

[0077] Format D into readable deterministic text T_{data}; Step 4.2: Push event: template, data is T_{data} and key indicator descriptions, which does not include the AI ​​insight to be generated.

[0078] Generate chart configuration (type, axis, series) based on D, and push event: charts. Push event: sources, with data set to \mathcal{S}.

[0079] Push event: insight_start.

[0080] Step 4.3: Construct the system and the first prompt paragraph, which contains T_{data} and the instruction "Please generate data analysis insights", and indicate the word count or token limit of this paragraph, which is obtained by S_{seg} and the character ratio.

[0081] The first insight is generated using LLM streaming, and the generated content is pushed out chunk by chunk (data block) as event: insight. If multiple segments are needed, set i \leftarrow 2: Construct a continuation prompt, including "continue to output subsequent key points, only add new content, and do not repeat the previous text" and the maximum number of words in this paragraph.

[0082] Invoke the LLM to stream the i-th segment and push it as event: insight.

[0083] If i \leftarrow i+1, repeat this substep if i \leq N_{seg} and the termination condition has not been met. Push event: done (completed), data may contain a complete response summary.

[0084] The data flow of this algorithm is as follows: (Q \rightarrow) Data aggregation / query ( \rightarrow (D, \mathcal{S}, T_{data}) ); ( T_{data}, D \rightarrow) template / charts / sources events; ( (T_{data}, S_{seg}, N_{seg}) \rightarrow) Segmented LLM calls and insight event flow ( \rightarrow )done.

[0085] The data analysis streaming output and token segmentation control algorithm, for requests identified as data analysis requests, first performs data aggregation or single-table queries to obtain structured data and data source tracing; outputs deterministic template events and key indicators, then outputs chart configuration events, and then outputs data source events; calculates the upper limit of tokens for each AI insight segment based on the context length and reserved space, splits the AI ​​insight into multiple segments, each segment independently calls LLM and is streamed, with prompts "continue output, do not repeat the previous text" added between segments; finally, a completion event is output, enabling AgentOS to present verifiable data and charts first in the analysis scenario, and then stream explanatory content, avoiding loss of control caused by excessively long single generation, forming a complete mechanism of deterministic data output, segmented streaming insights, anti-repeat control, and token scheduling.

[0086] This invention forms a unified collaborative system in AgentOS through four mutually cooperating algorithms. The four types of algorithms are merged into a unified link from input understanding to retrieval, planning, execution and streaming results; they share the same visibility rules, the same context budget, and the same execution semantics; and can be reused as a general kernel for enterprise-level intelligent agents.

[0087] This invention achieves unified retrieval and sorting of multi-source information, including the main system knowledge base, enterprise file vector library, identity snapshots, session memory, and file memory. This allows for automatic fusion of cross-source content, avoiding problems such as "source fragmentation," "disordered sorting," and "redundancy" in traditional solutions. User visibility filtering is introduced during the retrieval phase, eliminating invisible content before it enters the model, significantly reducing the risk of potential unauthorized output and improving system security. Token-level truncation of retrieval results, combined with context budgeting, significantly improves the relevance of injected content while avoiding model interference or performance degradation caused by context overflow. The effective relevance, visibility, and security of the retrieved content, along with token utilization, are simultaneously improved, significantly enhancing model understanding accuracy.

[0088] This invention achieves a stable mapping from natural language to executable JSON plans—a feat impossible for traditional intent classification models—through a closed-loop mechanism involving rule scoring, entity extraction, templated plan generation, legality verification, and automatic correction. The plan possesses executable semantics from the generation stage, including structured content such as task type, entity parameters, tool calls, and execution steps, significantly improving the success rate of automated tasks. The automatic correction mechanism automatically fills in missing parameters or plan contradictions, significantly enhancing the reliability of plan generation. The accuracy and executability of intent-to-plan conversion are steadily improved, the execution path is clear, and the overall task success rate is significantly enhanced.

[0089] In multi-table scenarios, this invention automatically infers JOIN relationships by combining table name and column name similarity rules, naming conventions, and LLM semantic analysis, solving the industry problem of low success rate in multi-table inference in traditional NL2SQL systems. It employs a templated SQL generation method, subjecting the output SQL to dual constraints of table structure and permission views, avoiding both invalid SQL and unauthorized queries. The generated SQL is directly executable, reducing manual debugging costs and improving the applicability to enterprise applications. The success rate of SQL generation, executable rate, and permission security are significantly improved, especially in multi-table query scenarios.

[0090] This invention breaks down data-related tasks into two stages: deterministic data output and AI-driven insight text output. This enables the model to achieve stable and consistent deterministic generation of charts, tables, and data sources. A token segmentation strategy is employed to divide long text insights into multiple segments for streaming generation. Each segment includes a "do not repeat preceding text" anti-duplication prompt, effectively avoiding issues such as repetition, disordered order, and redundant accumulation in traditional large-scale model long outputs. The output event sequence is fixed as "data – chart – source – insight segment – ​​completion," making front-end presentation predictable, smooth, and streamlining. The stability of long text generation is significantly improved, the repetition rate decreases, the order consistency is enhanced, and front-end rendering is smoother.

[0091] The four algorithms share the same permission system, the same context budget, and the same execution semantics, avoiding the technical architecture problems of traditional "fragmented modules and multiple entry points." The unified link of "retrieval – planning – SQL – analysis output" enables the system to have complete closed-loop capabilities, significantly improving the maintainability, reusability, and cross-business line scalability of enterprise-level intelligent agents. This system-level capability is currently unparalleled in the international enterprise intelligent agent field, thus this invention achieves a unique and irreplaceable systemic technical effect. It provides system-level stability, consistency, and scalability that traditional solutions cannot achieve, significantly reducing enterprise access costs and improving the overall performance of intelligent agents.

[0092] This invention achieves overall technical effects that traditional large-scale model enhancement schemes cannot reach by constructing a unified, multi-source, structured, executable, auditable, and streamable algorithm system at the AgentOS layer, significantly improving the performance, security, stability, and industrial usability of enterprise-level intelligent agents.

[0093] From an international perspective, this invention proposes a core algorithm system for enterprise-level AgentOS, integrating five long-dispersed capabilities—"retrieval enhancement, memory management, intent planning, NL2SQL, and analysis output"—under a unified runtime semantic framework for the first time. This forms a reusable, auditable, and cross-business-line-migratable unified algorithm kernel. While individual technologies such as RAG, NL2SQL, Task Planning, and Streaming Answers exist internationally, no technology has yet unified "multi-source retrieval—visibility filtering—plan generation—SQL inference—streaming insight" into a universal AgentOS-level closed-loop system within the same context budget, permission model, and event sequence. This invention fills a gap in international technology at this level. Furthermore, this solution does not rely on specific business logic and can be adapted to different organizations based on permission views and data structures, thus possessing high portability and universality, aligning with the development trend of international enterprise intelligent agent infrastructure. Moreover, this invention achieves stable collaboration between multi-source retrieval, execution planning, SQL generation, and streaming output under the same context and permission rules.

[0094] Although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A multi-source context retrieval and intent execution method, characterized in that: include: S1. Based on the given user question and user identifier, perform retrieval, processing, and token budget truncation to generate context text that can be securely injected into the system prompt of a large language model. S2. Based on the user message and context, determine the user intent type and entity, generate an executable plan JSON from the predefined plan template, and persist it after verification and automatic correction for the executor to execute step by step; S3. Takes the user's natural language and available table structures as input, and outputs a structured query intent and executable SQL, as well as optional chart configurations. S4. For user requests that have been identified as data analysis requests, first output deterministic data and charts, then call LLM in segments according to the token budget to generate AI insights and push them in a streaming manner.

2. The multi-source context retrieval and intent execution method according to claim 1, characterized in that: The retrieval and processing in S1 includes retrieving relevant content from the main system knowledge base, the enterprise document vector library, and multiple memory sources, and performing merging, sorting, and visibility filtering operations.

3. The multi-source context retrieval and intent execution method according to claim 2, characterized in that: The inputs in S1 include the user question string Q, the user identifier U, the context length configuration C_{ctx}, the number of reserved generated tokens R_{gen}, the proportion of tokens corresponding to each Chinese character\rho, the Top-K parameters of each source, and the minimum relevance threshold\theta; The output in S1 includes the plain text context T_{ctx} for injection.

4. The multi-source context retrieval and intent execution method according to claim 3, characterized in that: S1 includes: For user questions and user identifiers, search the main system knowledge base and enterprise document vector library, and filter by user visibility; The two results are merged into a unified record structure, sorted in descending order of relevance, filtered for items below the threshold, and the top K items are selected. The retained items are converted into plain text and concatenated into additional context. At the same time, multiple memory sources are retrieved according to user and visibility. The results from each source are globally reordered and the top K items are taken to generate structured profile text. Based on the configured context length and reserved generation space, the available token budget for the system segment is calculated. The additional context and memory profile are truncated according to the character and token ratio and then injected into the system instruction system prompt.

5. The multi-source context retrieval and intent execution method according to claim 1, characterized in that: The inputs to S2 include the user message string M, the context C, the intent rule table R, the plan template set \mathcal{T}, and the confidence threshold \tau; The output of S2 includes intent type I, confidence level p, entity set E, plan JSONP, and validation pass flag.

6. The multi-source context retrieval and intent execution method according to claim 5, characterized in that: S2 includes: After preprocessing and filtering user messages, if the "forced data analysis" condition is met, the data analysis intent and entity will be output directly. Otherwise, scores are calculated for each intent type except for clarification according to the rules, and the intent with the highest score is selected. If the score is lower than the confidence threshold, it is classified as an unknown intent. Extract entities from the message and context based on the selected intent type; Select a template from a predefined plan template set based on intent type and entity, and populate the step parameters in the template with entities and context to obtain the plan JSON; Perform a validity check on the JSON of the plan; if it fails, perform automatic correction and then check again. Persist the list of steps that passed the validation.

7. The multi-source context retrieval and intent execution method according to claim 1, characterized in that: The input to S3 includes the user's natural language query Q and the currently available table structure information \mathcal{F}; The output of S3 includes the structured query intent Y, the generated SQL string \sigma, and the execution result.

8. The multi-source context retrieval and intent execution method according to claim 7, characterized in that: S3 includes: Receive user natural language input and the currently available table structure; Prioritize using rule-based engines and LLM-based engines to parse structured query intents; If the number of tables is greater than 1 and the relationships are missing, the JOIN relationship will be inferred and filled in based on the similarity between table names and column names or the agreed rules. Select an SQL template based on the intent type and number of tables, and generate SQL by filling in columns, conditions, aggregations, groupings, sorting, and JOIN conditions; Execute the SQL and generate chart configurations based on the number of rows and column types in the results.

9. The multi-source context retrieval and intent execution method according to claim 1, characterized in that: The inputs to S4 include user question Q, session identifier, user identifier, context length C_{ctx}, upper limit of each insight token S_{seg}, and maximum number of segments N_{seg}; The output of S4 includes a sequentially pushed SSE event stream: template, charts, sources, insight_start, insight content, and done.

10. The multi-source context retrieval and intent execution method according to claim 9, characterized in that: S4 includes: For requests identified as data analysis requests, first perform data aggregation or single-table queries to obtain structured data and data source tracing; Output deterministic template events and key indicators, then output chart configuration events, and then output data source events; The upper limit of the word token for each AI insight is calculated based on the context length and reserved space. The AI ​​insight is split into multiple segments, each segment independently calls LLM and is pushed in a streaming manner, and a prompt "Continue output, do not repeat the previous text" is added between segments. Output a completion event.

Images