A natural language interactive operating system based on a large language model

Abstract

This invention discloses a natural language interactive operating system based on a large language model. The invention relates to the technical field of large language models. It determines corresponding task execution paths based on the identification of multiple sub-task graphs, marks each task execution node, marks the execution priority of each task execution node, and constructs execution coordination relationships between the task execution nodes for coordinated management. Based on the fault content, the corresponding task execution nodes, and the coordination relationships, a fault task chain is determined, and corresponding early warning interaction measures are matched according to this fault task chain. Based on the identification of early warning interaction measures, multiple early warning interaction tasks are determined. A collaborative task channel is constructed along the multiple early warning interaction tasks and the executable tasks of each task execution node. The execution of executable tasks is maintained in the collaborative task channel, ensuring the accuracy of the interactive operation measures of each task.

Description

Technical Field

[0001] This invention relates to the technical field of large language models, and more particularly to a natural language interactive operating system based on large language models. Background Technology

[0002] With the rapid development of artificial intelligence technology, especially the increasingly widespread application of Large Language Models (LLM) and multi-agent systems, natural language-based human-computer interaction has become an important development trend in the fields of operating systems and enterprise office automation. Existing intelligent operating systems typically integrate functions such as speech recognition and semantic understanding, attempting to control system resources or execute complex tasks through natural language commands. However, in terms of achieving multi-task collaborative processing and system-level fault tolerance, existing natural language-based interactive operating systems, when receiving complex user commands, often can only perform linear task decomposition or simple execution based on predefined fixed processes. This affects the collaborative management of various task execution nodes, resulting in low accuracy of collaborative task channels and an inability to guarantee the accuracy of interactive operation measures for each task. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a natural language interactive operating system based on a large language model.

[0004] This invention provides a natural language interactive operating system based on a large language model, comprising:

[0005] The language processing module is used to acquire the corresponding natural language based on the language receiving port, and determine multiple language combinations based on the division of the natural language. Each language combination is matched with a corresponding executable task; the executable task is decomposed and outputs multiple subtask graphs with dependencies.

[0006] The execution coordination module is used to determine the corresponding task execution path based on the identification of multiple subtask graphs, mark each task execution node, mark the corresponding execution priority of each task execution node, and build the execution coordination relationship between each task execution node;

[0007] The early warning interaction module is used to collect fault signals, determine the corresponding fault content by tracing the fault signals, determine the fault task chain based on the fault content, the corresponding task execution node and the coordination relationship, and match the corresponding early warning interaction measures according to the fault task chain.

[0008] The interactive operation module is used to identify multiple early warning interactive tasks based on the identification of early warning interactive measures, construct a collaborative task channel along the multiple early warning interactive tasks and the executable tasks of each task execution node, maintain the execution of executable tasks in the collaborative task channel, and form corresponding interactive operation measures.

[0009] Compared with the prior art, the beneficial effects of the present invention are:

[0010] (1) Obtain the corresponding natural language based on the language receiving port, and determine multiple language combinations based on the division of the natural language. Each language combination matches the corresponding executable task. Decompose the executable task and output multiple sub-task graphs with dependencies. Determine the corresponding task execution path based on the identification of multiple sub-task graphs, and mark each task execution node. Mark the corresponding execution priority of each task execution node, and construct the execution collaboration relationship between each task execution node. Multiple sub-task graphs are introduced to coordinate and manage each task execution node, thereby improving the accuracy of the execution collaboration relationship between each task execution node.

[0011] (2) Collect fault signals and determine the corresponding fault content by tracing the fault signals. Determine the fault task chain based on the fault content, the corresponding task execution node and the collaborative relationship. Match the corresponding early warning interaction measures based on the fault task chain. Determine multiple early warning interaction tasks based on the identification of early warning interaction measures. Construct a collaborative task channel along the multiple early warning interaction tasks and the executable tasks of each task execution node. Maintain the execution of executable tasks in the collaborative task channel and form corresponding interactive operation measures. Further control the fault signals and construct the corresponding fault task chain to synchronously control multiple early warning interaction tasks and the executable tasks of each task execution node. Improve the accuracy of the collaborative task channel and ensure the accuracy of the interactive operation measures of each task. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the natural language interaction operation method based on a large language model in an embodiment of the present invention.

[0013] Figure 2 This is a flowchart illustrating step S11 in the natural language interaction operation method based on a large language model in an embodiment of the present invention.

[0014] Figure 3 This is a flowchart illustrating step S12 in the natural language interaction operation method based on a large language model in an embodiment of the present invention.

[0015] Figure 4 This is a flowchart illustrating step S13 in the natural language interaction operation method based on a large language model in an embodiment of the present invention.

[0016] Figure 5 This is a flowchart illustrating step S14 in the natural language interaction operation method based on a large language model in an embodiment of the present invention.

[0017] Figure 6 This is a schematic diagram of the structural composition of a natural language interactive operating system based on a large language model in an embodiment of the present invention.

[0018] Figure 7 This is a schematic diagram of the overall system architecture of a natural language interaction method based on a large language model according to another embodiment of the present invention.

[0019] Figure 8 This is a schematic diagram of the language-driven system call process of the natural language interaction operation method based on a large language model in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0021] Please see Figures 1 to 8 A natural language interaction method based on a large language model is proposed and applied to large language processing scenarios. The natural language interaction method based on a large language model includes:

[0022] Step S11: Obtain the corresponding natural language based on the language receiving port, and determine multiple language combinations based on the division of the natural language. Each language combination matches the corresponding executable task. Decompose the executable task and output multiple sub-task graphs with dependencies.

[0023] Step S12: Determine the corresponding task execution path based on the identification of multiple subtask graphs, mark each task execution node, mark the corresponding execution priority of each task execution node, and build the execution coordination relationship between each task execution node;

[0024] Step S13: Collect fault signals and determine the corresponding fault content by tracing the fault signals. Determine the fault task chain based on the fault content, the corresponding task execution node, and the collaborative relationship. Match the corresponding early warning interaction measures based on the fault task chain.

[0025] Step S14: Based on the identification of early warning interaction measures, determine multiple early warning interaction tasks, construct a collaborative task channel along the multiple early warning interaction tasks and the executable tasks of each task execution node, maintain the execution of executable tasks in the collaborative task channel, and form corresponding interactive operation measures.

[0026] refer to Figure 2In step S11, the specific steps are as follows:

[0027] S111: Markup language receiving port, and obtains the corresponding natural language based on the monitoring of the language receiving port. The natural language is input by the client; the natural language is processed and converted into standardized task requests. The corresponding language combination is determined according to the context information corresponding to each task request and the natural language, so as to output multiple language combinations.

[0028] S112: In each language combination, multi-factor identification is performed on the language combination, and the corresponding sub-task features are marked during the identification process. The corresponding executable task is matched based on the synthesis of multiple sub-task features. The executable task is logically decomposed and the corresponding sub-task nodes are output. A sub-task graph is constructed based on the node position and node priority of each sub-task node, and multiple sub-task graphs are matched to mark the corresponding dependencies.

[0029] In the embodiments of this application, a markup language receiving port is used to obtain the corresponding natural language based on the monitoring of the language receiving port. This natural language is input by the client. The natural language is processed and converted into standardized task requests. The corresponding language combination is determined according to the context information corresponding to each task request and the natural language, so as to output multiple language combinations. This takes into account the overall consideration of the context information corresponding to each task request and the natural language, and ensures the accuracy of the corresponding language combination.

[0030] At this point, the system initializes and marks the language receiving port at the operating system level. This port logically corresponds to the "LLM interaction layer" and is responsible for providing an interaction entry point directly to the user. The port listening module continuously polls or monitors the status of these ports through an event-driven mechanism. Once a user input signal is detected (such as the end of the keystroke stream or the termination signal of the voice stream), the system immediately captures the raw data stream. For voice input, the system calls the audio processing interface to convert the analog signal into a digital signal. For text input, it directly acquires the character stream. At this time, the system temporarily stores the captured unstructured data in the input buffer, preparing for semantic-level parsing.

[0031] The LLM interaction layer loads a pre-trained large language model and combines it with the system Prompt context (including metadata such as user permissions, current system state, and historical dialogue records) to perform deep semantic parsing on the captured natural language. This process is not just simple word segmentation, but rather uses the model's reasoning ability to understand the user's high-level intent.

[0032] The system performs structured mapping of natural language instructions based on pre-configured "function signatures". The LLM determines whether the instruction needs to call a system function. If so, it transforms the unstructured natural language into a standard task request that conforms to a specific specification. This request usually includes action type, target object and parameter constraints. In essence, it "translates" natural language into structured data that the machine can understand (such as the logical representation of a JSON-like object). The request in the form of a "function call" is the standardized output here.

[0033] After generating standardized task requests, the system further refines and groups the tasks by combining dynamic context information. The context information includes the current dialogue thread, business process status, and logical relationships between multiple tasks. The system analyzes the semantic units in the standardized requests to identify the multiple logical intentions or operation steps contained therein. If a natural language instruction contains multiple subtasks that require processing by different agents or interfaces, the system will decompose and repackage them into multiple "language combinations". Each language combination represents an independent set of language instructions that can be directly consumed by a specific processing unit (such as an agent), and is accompanied by necessary parameters extracted from the context (such as user ID, session ID, and data pointers of previous tasks). The system outputs this set of language combinations with clear execution orientation for use by the subsequent task decomposition module.

[0034] Specifically, in an enterprise office automation scenario, a project manager inputs a complex natural language command through a smart office terminal: "Please help me compile the sales data for East China last month, generate a quarterly summary report for senior management based on this data, and send it to the sales director via email."

[0035] The system marks the input box of the office software chat window as the currently active language receiving port; when the user finishes typing and clicks send, the port monitoring mechanism captures the text string: "Please help me organize the sales data of East China last month, and generate a quarterly summary report for senior executives based on this data, and send it to the sales director via email." The system transmits this text stream to the LLM interaction layer.

[0036] LLM parses the instructions by combining the Prompt context (including the current user's "Project Manager" role permissions, the current date "January 2024", and a list of available business system interfaces); the system identifies three core intents: "Organize sales data", "Generate report", and "Send email".

[0037] The system converts natural language into three standardized task requests: Request A: {Task type: data query, target: sales table for East China, time range: last month}; Request B: {Task type: document generation, input source: the result returned by Request A, format requirements: quarterly summary report, audience: senior executives}; Request C: {Task type: email sending, attachment source: the generated file from Request B, recipient: sales director}.

[0038] The system analyzes the logical dependencies between the three requests based on the context. Since request B depends on the data in request A, and request C depends on the file in request B, the system encapsulates these requests into three ordered "language combinations": Language combination 1: a data retrieval instruction carrying parameters {Region:East_China,Month:Last_Month}, used to invoke the data query agent; Language combination 2: a document building instruction carrying parameters {Template:Quarterly_Report,Role:Executive}, used to invoke the document generation agent, with its context reference pointing to the expected output of language combination 1; Language combination 3: a communication instruction carrying parameters {Recipient:Sales_Director,Attachment:Dynamic_Link}, used to invoke the email service agent, with its context reference pointing to the expected output of language combination 2. The system finally outputs these three language combinations, completing the transformation from a vague natural language sentence to a set of structured, executable technical instructions.

[0039] Furthermore, in each language combination, multi-factor identification is performed on the language combination, and corresponding sub-task features are marked during the identification process. The corresponding executable task is matched based on the synthesis of multiple sub-task features. The executable task is logically decomposed and the corresponding sub-task nodes are output. A sub-task graph is constructed based on the node position and node priority of each sub-task node, and multiple sub-task graphs are matched to mark the corresponding dependencies. This approach takes into account the overall consideration of the node position and node priority of each sub-task node, ensuring the accuracy of the sub-task graph.

[0040] At this point, the system performs in-depth analysis on each language combination output from stage S111. This process utilizes the semantic understanding capabilities of the large language model, combined with the system's pre-built domain knowledge base, to perform multi-dimensional identification: Semantic and entity recognition: extracting core entities (such as names of people, places, and filenames) and action intentions (such as "query," "generate," and "send") from the instructions; Contextual relationship recognition: analyzing the relationship between the current instruction and previous instructions to determine whether they belong to the continuation of the same session thread, thereby determining whether it is necessary to reference the output data of the previous task; Capability attribute recognition: identifying the specific resources or capability types required by the task (such as database access permissions, web search interfaces, document generation engines, etc.); Based on the above identification results, the system labels each language combination with a set of structured "subtask features." These feature vectors contain the task type, input parameter constraints, output format requirements, and the capability profile of the required Agent.

[0041] The system compares and matches the extracted subtask features with the function registry and Agent capability directory; at the same time, the system maintains a registry containing functions such as operating system service calls, Agent capability interfaces, and external WebAPIs.

[0042] If a feature closely matches a specific agent's specialized skill set (such as an "Excel PivotTable Agent"), it is directly assigned to that agent. If there is no directly matching single agent, the system will route the task to an agent with general capabilities (such as a "General Logic Processing Agent") based on feature combinations, or meet the requirements by combining multiple basic APIs. After a successful match, the system maps the features described in natural language to standard interface call parameters that conform to the MCP (Model Context Protocol) specification, generating a specific executable task instance.

[0043] For matched complex executable tasks, the task collaboration module logically decomposes them, introducing two modes: "process-oriented decomposition" and "adaptive decomposition." For predefined workflows (such as standard expense approval), the system decomposes tasks into atomic steps with a fixed order according to pre-set templates (e.g., submit application > department manager approval > financial review). For complex tasks in open or unknown domains, the system utilizes the reasoning capabilities of LLM to recursively decompose tasks into smaller, logically independent subtasks (Nodes) in real time, until each subtask can be directly processed by a single Agent or API. Each decomposed subtask is encapsulated as an independent "task node," which contains the complete context parameters and status identifiers required to execute the subtask.

[0044] The system constructs a task graph based on the decomposed sub-task nodes. The task graph is a directed acyclic graph, where nodes represent sub-tasks and edges represent dependencies. The system determines the topological position of each sub-task in the graph based on its order in the logical flow. The system assigns execution priority weights to each node based on task urgency, user interaction priority, and business importance. For example, real-time interactive response tasks typically have a higher priority than background data archiving tasks. Directed edges are established between nodes based on data flow and logical constraints. If the input of node B depends on the output of node A, a dependency edge is established from A to B to ensure the correctness of the execution order.

[0045] When dealing with multiple concurrent language combinations or complex multi-task scenarios, the system may generate multiple local subtask graphs; the system needs to perform global matching and integration of these graphs; the system scans the nodes in different subtask graphs to identify whether there is shared data or logical coupling; for example, two seemingly independent language combinations may ultimately need to call the same "user authentication" subtask.

[0046] For identified common nodes or logic, the system merges them in the global view to form a unified global task graph to avoid duplicate execution. In the integrated graph, the system recalculates and marks the final dependencies between all nodes to ensure that the scheduling module can correctly perform topology sorting and concurrency control based on these dependencies.

[0047] Specifically, the project manager input a complex natural language command via a smart terminal: "Analyze the risk logs of Project A from last month, generate a summary report for senior management based on the analysis results, and send the report link to the project team's instant messaging group." The system parsed the language combination and identified three core intent clusters: data analysis (object: risk logs, time: last month); report generation (audience: senior management, material: analysis results); message sending (target: project team group, content: report link). The system marked the following features: Feature 1 includes {permissions: project data reading, algorithm: risk assessment model}; Feature 2 includes {format: PPT / Word, tone: formal}; Feature 3 includes {interface: IM group chat API}.

[0048] The system searches the function registry and matches feature 1 to "Data Analysis Agent", which has the authority to access the enterprise risk database; feature 2 to "Document Generation Agent", which is good at calling template engines to generate business reports; and feature 3 to "Communication Service Agent", which encapsulates the Webhook interface of the enterprise instant messaging software.

[0049] The task collaboration module breaks down the instructions into four specific sub-task nodes: Node N1: Query the raw risk data of Project A from last month (requires database access); Node N2: Run the risk algorithm model to analyze the data (requires CPU computing resources); Node N3: Based on the output data of N2, generate a document file according to the executive report template; Node N4: Obtain the cloud sharing link of the file generated by N3 and push it to the group.

[0050] The system constructs a task graph structure: Node N1 (priority: high) serves as the entry node with no prerequisites; Node N2 (priority: medium) depends on N1 and must wait for the data to be ready; Node N3 (priority: medium) depends on N2 and must wait for the analysis results; Node N4 (priority: high) depends on N3 and belongs to the final delivery stage; the system establishes dependency edges in the graph: N1>N2>N3>N4, forming a linear execution pipeline.

[0051] Suppose that another task graph in the system is simultaneously processing "the routine weekly report of project A", which also contains a subtask of "querying data of project A". The system finds through cross-graph matching that node N1 has a high degree of logical overlap with the data query node in that task. In order to optimize efficiency, the system marks N1 as a "reusable node" in the global dependency relationship, so that subsequent tasks can directly reference the output cache of N1 without repeatedly accessing the database, thereby realizing collaborative optimization between multi-task graphs.

[0052] refer to Figure 3 In step S12, the specific steps are as follows:

[0053] S121: In multiple subtask graphs, the corresponding sub-execution routes are determined based on the identification of each subtask graph. Multiple sub-execution routes and their corresponding dependencies are synthesized by multiple factors, and multiple executable nodes are output. Based on the multiple executable nodes, the key task content of the subtask graph, and the corresponding task priority, the corresponding task execution path is determined. The task execution path covers the priorities of different executable nodes.

[0054] S122: Match multiple executable nodes and determine the task execution nodes in the current scenario by combining the response signals of each executable node. Determine the corresponding execution priority by combining the execution content of the current scenario. At the same time, mark the status of each task execution node and determine the execution priority of the task execution node based on the status, corresponding execution timeliness, and task requirement level. Record the execution intention of each task execution node, determine the corresponding decision content by tracing the execution intention, and determine the execution coordination relationship between each task execution node based on the decision content and corresponding execution content.

[0055] In the embodiments of this application, in multiple subtask graphs, corresponding sub-execution routes are determined based on the identification of each subtask graph. Multiple sub-execution routes and their corresponding dependencies are synthesized using multiple factors, and multiple executable nodes are output. Based on the multiple executable nodes, the key task content of the subtask graph, and the corresponding task priority, the corresponding task execution path is determined. This task execution path covers the priorities of different executable nodes and is compatible with the overall consideration of multiple executable nodes, the key task content of the subtask graph, and the corresponding task priority, ensuring the accuracy of the corresponding task execution path.

[0056] At this point, the system performs a global scan and analysis of the multiple subtask graphs generated in stage S112. Since each subtask graph may contain multiple parallel execution branches (i.e., sub-execution routes), the system identifies these independent paths. For example, a complex report generation task graph may contain "data acquisition route", "chart generation route" and "format rendering route".

[0057] The system employs a multi-factor synthesis strategy to logically integrate these dispersed sub-execution routes and their inherent dependencies. This process references the scheduling logic of the task coordination module: the system analyzes whether there is data or logical coupling between nodes in different sub-task graphs; if the output of graph A is the input of graph B, the system establishes cross-graph dependency edges; for competing requests for the same resource, the system arbitrates according to a preset resource lock strategy to ensure that no resource conflicts occur after the multiple routes are synthesized. Through the above synthesis, the system integrates multiple local sub-task graphs into a unified global task topology structure that includes all nodes to be executed, laying the foundation for subsequent path planning.

[0058] In the synthesized global view, the system extracts nodes that currently meet the execution conditions (i.e., all prerequisite dependencies are met) and marks them as "executable nodes"; it also adds nodes with an in-degree of 0 to the ready queue; simultaneously, the system performs criticality identification on nodes: using the Critical Path Method (CPM) to analyze the task graph, it identifies which nodes are critical nodes that determine the overall task time; delays on critical nodes will directly lead to delays in the entire task; combined with the task context, it identifies the business attributes of nodes (such as "user interaction blocking type" or "background silent type"); the system outputs a list of executable nodes containing the above metadata for use by the path planning algorithm.

[0059] The system calculates a comprehensive priority weight for each executable node based on factors such as task origin (e.g., real-time user commands take precedence over background batch processing), task urgency, and the node's position on the critical path. The system maintains multiple priority queues (e.g., high-priority real-time queue, medium-priority interactive queue, and low-priority batch processing queue). Executable nodes are assigned to the corresponding queues according to their weights. The scheduler retrieves nodes from the queues in priority order and determines their execution order. For high-priority nodes, the system immediately allocates computing resources (CPU / GPU threads) and marks their execution path as a "high-priority path." For low-priority, long-running tasks, they are assigned to low-priority paths to prevent them from blocking system response. The final generated task execution path not only includes the node execution sequence but also implicitly contains resource allocation time slices and concurrency strategies, ensuring the system can still respond to critical tasks under high load.

[0060] Specifically, a complex integrated task was initiated via natural language commands: "Analyze last month's sales data, generate a quarterly summary PPT, query today's flight information, and book a meeting room for 3 PM." The system identified that the command involved three independent sub-task graphs: the first graph (sales analysis and PPT), the second graph (flight query), and the third graph (meeting room booking). The first graph contained two sub-execution routes: route A (query the database > calculate metrics) and route B (load the PPT template > render the chart). It was found that route A was a prerequisite for route B (data must be available before the chart can be rendered), so they were merged into a single serial path. At the same time, it was confirmed that the second and third graphs had no data dependencies on the first graph and could be executed in parallel. Finally, a global task topology containing three parallel branches was synthesized.

[0061] In the synthesized topology, the system analyzes the current state: the entry node "Query Sales Database" in the first graph, the node "Search Flight Tickets" in the second graph, and the node "Check Meeting Room Status" in the third graph have no prerequisites and are output as executable nodes; the system determines that the first graph (generating quarterly summary PPT) belongs to "high-computing-power background tasks" and is time-consuming, making it a critical task; the third graph (booking meeting rooms) involves real-time resource locking and belongs to "real-time interactive tasks", which are time-sensitive.

[0062] The third graph, booking a meeting room, is given the highest priority (P0) because it involves competition for public resources and the user requires "3 PM," which has a strict time deadline. The second graph, searching for flight tickets, is given a medium priority (P1) and belongs to the information query category. The first graph, data analysis and PPT presentation, is given a lower priority (P2) because it is a long-running background task to avoid consuming too many front-end computing resources.

[0063] The system builds an execution path: On the P0 path, the "Meeting Room Reservation Agent" is launched to ensure resource locking; simultaneously, the "Flight Inquiry Agent" is launched concurrently on the P1 path; on the P2 path, when CPU / GPU resources are idle, the "Database Inquiry Agent" and "PPT Rendering Agent" are launched step by step. Through this priority-based path planning, the system ensures that the most immediate task (meeting room) receives the response first, while the heavy data analysis task is steadily carried out in the background, realizing efficient collaboration of multiple tasks.

[0064] Furthermore, multiple executable nodes are matched, and the response signals of each executable node are used to determine the task execution nodes in the current scenario. The execution content of the current scenario is then used to determine the corresponding execution priority. Simultaneously, the status of each task execution node is marked, and the execution priority of each task execution node is determined based on its status, corresponding execution timeliness, and task requirement level. The execution intention of each task execution node is recorded, and the corresponding decision content is determined by tracing the execution intention. Based on the decision content and corresponding execution content of each task execution node, the execution coordination relationship between each task execution node is determined. This approach takes into account the overall consideration of the decision content and corresponding execution content of each task execution node, ensuring the accuracy of the execution coordination relationship between each task execution node. In addition, multiple sub-task graphs are introduced to coordinate and manage each task execution node, thereby improving the accuracy of the execution coordination relationship between each task execution node.

[0065] At this point, the system maps each abstract executable node to a specific intelligent agent or system service instance. The mapping process considers the agent's current load, capability matching degree, and geographical location (such as edge nodes or cloud nodes). The system sends a query signal or execution preparation instruction to the target agent and detects the agent's response signal (such as "data signal" or "resource ready confirmation"). Only nodes that return normal response signals are identified as "task execution nodes in the current scenario". Once the execution node is identified, the system injects the task context (including user identity, data references of previous tasks, and permission tickets) into the node based on the MCP protocol, completing the final preparations before execution.

[0066] The system aggregates the task content of all nodes awaiting execution in the current scenario and analyzes the logical relationships between them. For example, if two nodes belong to the upstream and downstream of the same business flow, the system may increase the priority of the upstream node to prevent blocking. The system uses a weighted algorithm to calculate the final execution priority, with input factors including: task requirement level: real-time user interaction requests are usually higher than background batch processing tasks; node status: nodes in "ready" and with sufficient resources have higher priority; nodes in "waiting" or with limited resources have lower priority; execution timeliness: nodes nearing their deadline or real-time tasks sensitive to latency will have their priority dynamically increased by the system. The system writes the calculated priority value into the node's control block, which serves as the core basis for the scheduling module to allocate computing resources (CPU / GPU time slices).

[0067] The system performs full lifecycle status marking for each task execution node to ensure that the scheduling module can monitor the execution progress in real time. Statuses are introduced, including "Not Started," "In Progress," "Completed," "Failed," and "Suspended." During execution, nodes send data packets or status update messages to the coordination module via the MCP protocol. For example, when a node starts processing data, its status changes to "In Progress"; after processing and outputting the result, it changes to "Completed." If a node does not respond within a predetermined time or returns an error code, the system immediately marks its status as "Failed" and triggers the fault handling process.

[0068] The system not only records node operations (such as "calling an API"), but also the underlying intent (such as "to obtain user preference data to optimize the recommendation algorithm"). This is typically achieved by parsing the Prompt context during node initialization. When the system needs to diagnose decisions or generate logs, it can trace back along the intent chain. For example, tracing back reveals that node A's intent to "read the database" is to meet node B's data requirement to "generate a report." Based on intent tracing, the system generates a snapshot of the decision content, explaining "why this node needs to execute now" and "how its output will affect subsequent processes."

[0069] If node A's decision explicitly states that its output is node B's input, the system establishes a strong cooperative relationship between the two, ensuring seamless data transfer through a shared context. Based on time constraints in the decision, the system specifies the activation order of nodes; for example, node C can only be activated after both nodes A and B have completed their tasks. For nodes executing in parallel, the system allocates complementary resources based on their execution content; for example, compute-intensive nodes are allocated GPU resources, and I / O-intensive nodes are allocated high-bandwidth network channels, allowing them to proceed in parallel without interference, jointly achieving the task objective.

[0070] Specifically, the user (project manager) initiates the instruction: "Summarize the risk logs of Project A and Project B, and generate a comprehensive comparative analysis report to send to me." The system has broken this down into multiple sub-tasks and is currently in the S122 scheduling and execution phase. The system matches the executable nodes "Data Summary A" and "Data Summary B" to "Data Analysis Agent1" and "Data Analysis Agent2." The system sends a handshake signal and finds that Agent1 is in an idle state (normal response signal), while Agent2 is processing another small task (delayed response signal). The system determines that the node corresponding to Agent1 is the currently ready execution node, marks the node corresponding to Agent2 as "waiting for resources," and postpones the injection of task context.

[0071] The system detected that the "Generate Report" node heavily relies on the data from the two summary nodes mentioned above. Since the user requires a "comprehensive comparison," data from both projects must be complete. Considering that Agent2 is busy, in order to prevent the "Generate Report" node from being blocked indefinitely, the system temporarily raises the task priority of "Data Summary B" to the highest level so that Agent2 can complete its current work as soon as possible and switch to this task. "Data Summary A" remains at a medium-high priority.

[0072] Agent1 begins executing "Data Summary A", and the system marks its node status as "Executing". Agent2 is still processing its preceding tasks, and the corresponding "Data Summary B" node status is marked as "Suspended / Waiting". The system monitoring module polls these two nodes in real time. Once Agent2 becomes idle, it immediately updates its status to "Ready" and assigns a task. The system records the execution intent of the "Data Summary A" node as: "Extract risk data for Project A to support comparative analysis". Based on this intent, the decision is confirmed as: "Execute an SQL query to extract the risk level distribution for the most recent 30 days and output it in a standardized JSON format".

[0073] The system establishes collaborative relationships based on the decision content: there is a "parallel-convergence" collaborative relationship between the "Data Summary A" node and the "Data Summary B" node; the system configures a shared context: after Agent1 and Agent2 complete, they must write JSON data into the same context object named Comparison_Raw_Data; the triggering mechanism is set: the downstream "generate report" node is only triggered when the context manager detects that Comparison_Raw_Data contains two complete sets of data, A and B, to ensure the rigor of the collaborative logic.

[0074] refer to Figure 4 In step S13, the specific steps are as follows:

[0075] S131: Monitor the execution status of each task execution node in real time, determine the corresponding fault signal based on the detection of the execution status, perform signal analysis on the fault signal to output the corresponding fault content, and divide it into multiple sub-fault items;

[0076] S132: Deeply integrate multiple sub-fault items and their corresponding task execution nodes, output a corresponding fault framework, determine the corresponding fault task chain based on the fault framework and the collaborative relationship between each task execution node, and mark the dynamic changes of the fault content;

[0077] S133: Based on the dynamic changes of the fault content, the corresponding prediction result is determined, and the corresponding early warning interaction measure is determined along the mapping relationship between the prediction result, the corresponding fault factor and the early warning interaction measure. The early warning interaction measure presents the early warning interaction content of each task execution node at the fault early warning level.

[0078] In the embodiments of this application, the execution status of each task execution node is monitored in real time, and the corresponding fault signal is determined based on the detection of the execution status. The fault signal is analyzed to output the corresponding fault content and is divided into multiple sub-fault items, which is compatible with the overall consideration of the execution status detection and ensures the accuracy of the corresponding fault signal.

[0079] At this point, the system, based on the MCP protocol, periodically polls the status flags of each node and records the node's status (not started, in progress, completed, failed, etc.). If a node's status remains in "in progress" for a long time without data updates, the system determines it as a potential stall. The system listens for exceptions thrown by the Agent or underlying services, return code errors (such as HTTP 500, database connection failure), and resource exhaustion signals (such as memory overflow OOM). Any abnormal event that deviates from the expected execution flow will be converted into a corresponding fault signal.

[0080] The system extracts key feature vectors from fault signals, including occurrence time, node ID, anomaly type (network anomaly, logical error, insufficient resources), error stack information, and current task context snapshot. The system combines the task graph structure to analyze the relationship between fault signals and preceding tasks or environmental states. For example, it analyzes whether node failure is due to incorrectly formatted data passed from preceding nodes or unavailability of external API services. The system encapsulates the above analysis results into a structured "fault content" object, which details the fault phenomenon, the initial cause, and the affected system components, providing a data foundation for subsequent fault item classification.

[0081] To refine the fault handling process, the system breaks down complex fault content into multiple specific sub-fault items; the system analyzes the impact of faults on the task graph; if a fault causes a node to become unavailable, this constitutes a "node failure" sub-item; if a fault causes all subsequent nodes that depend on that node to be blocked, it constitutes a "chain blockage" sub-item.

[0082] Fault hierarchy classification: Execution layer faults: such as Agent process crash, timeout failure to respond; Data layer faults: such as data verification failure, context read / write anomalies; Resource layer faults: such as CPU / GPU resource contention conflicts, insufficient network bandwidth; The system instantiates the faults at different levels analyzed above into independent "sub-fault projects". Each sub-project carries a unique fault ID, severity level (fatal, severe, general) and suggested handling strategy (such as retry, rollback, degradation).

[0083] Specifically, the system monitors two key nodes in real time: node N1 (ERP data synchronization agent) and node N2 (external AI analysis agent). During execution, when node N2 calls the external AI API, the network response exceeds the preset 10-second threshold, or it receives the HTTP status code "503 Service Unavailable". The monitoring module immediately captures this anomaly and determines that an "external service call timed out / unavailable" fault signal has been generated.

[0084] The system performs in-depth analysis of the signal: the fault occurred at T+10s, the faulty node was N2, and the anomaly type was network / server anomaly; the system checked the task graph and found that N1 had successfully executed and written the inventory data to the shared context, but N2 could not read the data for analysis; the system determined the cause of the fault to be "third-party service response timeout"; the system output structured fault content: "When task node N2 was executing external AI analysis, the task was interrupted due to the third-party API response timeout. The current inventory data is ready but a report cannot be generated."

[0085] The system further breaks down the above-mentioned fault into three specific sub-fault items for precise subsequent handling: Sub-fault item A (network layer): marked as "external connection timeout", severity level "critical", recommended strategy is "retry or switch to backup line"; Sub-fault item B (task layer): marked as "analysis report generation failure", severity level "fatal" (because the user's core requirements were not met), recommended strategy is "pause subsequent task sending"; Sub-fault item C (resource layer): marked as "N2 node thread suspended", severity level "moderate", recommended strategy is "release the GPU resources occupied by N2 for other tasks to use"; The system submits these three sub-fault items to the subsequent fault handling module (corresponding to S132) to prepare for chain tracing and early warning measure matching.

[0086] Furthermore, multiple sub-fault projects and their corresponding task execution nodes are deeply integrated to output a corresponding fault framework. Based on the collaborative relationship between the fault framework and each task execution node, the corresponding fault task chain is determined, and the dynamic changes of the fault content are marked. This approach takes into account the overall collaborative relationship between the fault framework and each task execution node, ensuring the accuracy of the corresponding fault task chain.

[0087] At this point, the system deeply associates and integrates the multiple sub-fault items divided in stage S131 with their corresponding task execution nodes, aiming to construct a structured fault model. The system establishes a strong binding relationship between sub-fault items and specific task execution nodes (and their corresponding Agents). For example, the "network timeout" fault item is bound to the "external API call Agent" node. The system not only attaches faults to nodes but also integrates the node's current execution context (such as input parameters, memory state, and output of dependent predecessor nodes) into the fault description. This helps distinguish whether the fault is due to a logical error within the node itself (such as an abnormal algorithm within the Agent) or an error in the input data source (such as illegal data passed in by a predecessor node). The system analyzes the timing of the fault by combining the node's lifecycle states (such as "in execution," "suspended," and "waiting"). For example, if the fault occurs during a timeout in the "waiting" state, the fusion result points to I / O blocking; if it occurs during an abnormal exit in the "in execution" state, it points to a computational logic error.

[0088] Based on the results of deep fusion, the system outputs a hierarchical "fault framework," which is a macroscopic abstract description of the current task graph fault status. The framework typically contains three levels: point fault: local failure of a single agent or API; link fault: data transmission failure on dependent edges; system-level fault: large-scale blocking caused by exhaustion of global resources (such as all thread pools being full). Based on the fused data, the system determines which of the above types or combinations of faults the current fault belongs to and generates a structured fault framework object, which includes the fault's propagation scope, severity rating, and potential system impact assessment.

[0089] The system utilizes the execution coordination relationships (i.e., the topology of the task graph and MCP communication links) established in phase S12 to determine the faulty task chain. Starting from the faulty node, it traces back along the reverse dependency edges of the task graph to identify upstream nodes that may cause the fault (e.g., incorrect data sources). It extrapolates along the forward dependency edges to identify all downstream nodes that are directly or indirectly affected by the fault, and the system marks these affected paths. The system analyzes whether the faulty chain will form a closed loop or whether it will interrupt critical business flows (such as report generation pipelines). The determined faulty task chain is a set of nodes and edges, representing the propagation path and affected scope of the fault.

[0090] The system identifies and marks the dynamic evolution characteristics of fault content over time, ensuring that early warning measures can adapt to the development trend of the fault. Temporal marking: Static faults are marked as "fixed," such as code logic errors or insufficient permissions; these fault states will not recover automatically. Dynamic faults are marked as "fluctuating" or "spreading," such as network jitter, gradually worsening memory leaks, or intermittent unavailability of third-party services. The system combines historical fault data with current monitoring indicators (such as the number of error retries and response latency growth curves) to predict the next state of the fault. For example, it predicts that "service timeout" may evolve into "service downtime" in the near future. In the fault framework, the system attaches dynamic attribute tags (such as "spreading," "isolated," and "self-healing") to the fault content. These tags will serve as key inputs for matching early warning interaction measures in subsequent steps of S13, guiding the system to choose whether to immediately issue an alarm, automatically retry, or switch to a backup plan.

[0091] Specifically, when the system executes to stage S132, it detects a fault in the node that "calls cloud vendor API for expansion"; sub-fault items: first type of fault "cloud API connection timeout", second type of fault "authentication token is about to expire"; the system deeply binds the first and second types of fault items to the "cloud resource control agent" node; the system merges the node status and finds that the node is in a "retry loop" and the input parameters contain a credential that is about to expire; the system determines that the B type of fault (token expiration) is the root cause of the first type of fault (API connection refusal / timeout), forming a merged fault profile.

[0092] The system constructs a fault framework, with the hierarchy determined as "link failure > point failure": Link failure: The communication link between the Agent and the cloud service is interrupted; Point failure: The authentication module (point) logic fails; The framework output includes a severity level: "Critical" (because it may cause server overload and prevent scaling).

[0093] The system traced back and found that the "Token Management" node output expired credentials to the "Cloud Resource Control Agent"; the system deduced that the failure of the "Cloud Resource Control Agent" caused the "Server Load Balancing Adjustment" node to be unable to obtain new resources, which in turn caused the "Alarm Report Generation" node to lack expansion result data; the system marked a complete fault task chain: [Token Management Node] > [Cloud Resource Control Agent Node] > [Load Balancing Node] > [Report Generation Node].

[0094] The system marks the fault as "spreading" because the inability to scale up will cause the server's CPU load to continue to rise (dynamic deterioration) over time. The system predicts that if the authentication problem is not fixed within 5 minutes, the server will reach 100% load and trigger the circuit breaker mechanism. The system updates the status in the fault framework to "immediate intervention required (manual intervention or automatic token refresh)" and passes this dynamic mark to the subsequent warning module so that the system can match the interactive measures of "priority upgrade" or "automatic credential refresh".

[0095] Therefore, based on the dynamic changes in the fault content, the corresponding prediction results are determined, and the corresponding early warning interaction measures are determined along the mapping relationship between the prediction results, the corresponding fault factors, and the early warning interaction measures. These early warning interaction measures present the early warning interaction content of each task execution node at the fault early warning level, and take into account the overall consideration of the dynamic changes in the fault content, ensuring the accuracy of the corresponding prediction results.

[0096] At this point, based on the dynamic changes in the fault content marked in stage S132 (such as "spreading", "isolated", "performance continues to decline"), the system uses a time series prediction model or a rule-based inference engine to calculate the possible future development of the fault. If the fault is marked as "spreading", the system combines the current task graph load and the historical recovery time of the fault node to predict which downstream nodes the impact of the fault will expand to in the next T seconds, as well as the expected delay time of the overall task. The system predicts the final outcome of the fault, such as "ultimately leading to task failure", "recoverable through automatic retry", or "requiring manual intervention". This prediction result is encapsulated as a structured prediction object, including a confidence score and a prediction time window.

[0097] The system establishes a multi-dimensional decision mapping table to associate and match the predicted fault results, specific fault factors, and preset early warning interaction measures; multi-dimensional mapping index: predicted results: such as "not expected to self-heal in a short period of time"; fault factors: such as "external API timeout", "Agent logic crash", "memory overflow".

[0098] Matching Strategies: Automatic Recovery: For transient network failures that are expected to be recoverable through retries, the matching strategy is "asynchronous retries" or "exponential backoff retries"; Resource Switching: For failure factors where "external tools are unavailable," the matching strategy is "replacing with a backup tool"; for example, switching to a backup engine when the main search engine is inaccessible; Degradation and Isolation: For failures that are expected to cause severe congestion, the matching strategy is "task degradation execution" or "node isolation" to prevent the failure from spreading and affecting other agents; State Rollback: For failures that compromise data consistency, the matching strategy is "triggering state rollback," using the state management module to restore the system to the checkpoint before the failure.

[0099] The system transforms the determined early warning interaction measures into specific "early warning interaction content." This content includes not only technical instructions but also interactive information for different roles (such as user notifications, system logs, and Agent instructions). System-level instructions: specific execution code or API calls, such as Retry(Node_A,count=3) or Switch_Tool(Search_Agent,Backup_Engine). User-level prompts: based on a natural language generation model, technical faults are transformed into user-understandable prompts, such as "Network fluctuations detected, attempting backup lines, please wait" or "Some services are temporarily unavailable; your current progress has been saved." Agent-level coordination: sending coordination signals to relevant task execution nodes to adjust their execution strategies (such as pausing and waiting, preparing to receive new data). The final generated early warning interaction content covers fault detection, prediction, handling strategies, and expected recovery time, forming a closed-loop interactive information package at the fault early warning level, ensuring that all parts of the system can respond consistently and in a coordinated manner to anomalies that are about to occur or are currently occurring.

[0100] refer to Figure 5 In step S14, the specific steps are as follows:

[0101] S141: Identify early warning interaction measures and convert them into multiple early warning interaction tasks, which include blocking tasks, correction tasks, and enhancement tasks; at the same time, mark the executable tasks of each task execution node, perform multi-factor interaction between the executable tasks of each task execution node and multiple early warning interaction tasks, determine the corresponding matching relationship during the interaction process, determine the corresponding multi-task combination along the matching relationship, and determine the corresponding collaborative task channel based on the identification of the multi-task combination;

[0102] S142: In the collaborative task channel, the execution status of executable tasks is maintained through an asynchronous message queue, and the execution progress of executable tasks is monitored. Based on the execution progress of each executable task and the execution status of the corresponding task execution node, the order of multiple executable tasks is determined, and corresponding interactive operation measures are constructed during the iteration process.

[0103] In the embodiments of this application, early warning interaction measures are identified and transformed into multiple early warning interaction tasks, which include blocking tasks, correction tasks, and enhancement tasks. At the same time, the executable tasks of each task execution node are marked, and multi-factor interaction is performed between the executable tasks of each task execution node and the multiple early warning interaction tasks. During the interaction process, the corresponding matching relationship is determined, and the corresponding multi-task combination is determined along the matching relationship. Based on the identification of the multi-task combination, the corresponding collaborative task channel is determined, which is compatible with the overall consideration of the identification of multi-task combinations and ensures the accuracy of the corresponding collaborative task channel.

[0104] At this point, the system performs in-depth analysis of the early warning interaction measures determined in phase S133 and transforms them into specific "early warning interaction tasks" that can be executed by scheduled modules. This process encompasses the mapping from abstract strategies to specific operational instructions: Blocking tasks: These are tasks that require immediate termination of the current process to prevent the spread of faults; for example, when a serious data conflict is detected, instructions to "pause task graph execution" or "isolate faulty nodes" are generated; Corrective tasks: These are tasks designed to repair specific faults or bypass errors; for example, introducing "retry tasks" or "replacing backup tools" (such as switching to a backup search engine). These tasks attempt to restore normal business flow by changing the execution path or parameters; Enhancement tasks: These are tasks that provide additional protection or prompts to the system when a fault occurs; for example, initiating a redundant backup process, triggering a "phantom suppression" mechanism for secondary verification, or sending a notification to the user to "execute degraded service".

[0105] While generating early warning interaction tasks, the system re-examines the current task graph and marks and locks the status of each task execution node and its executable tasks. To prevent early warning measures from conflicting with running tasks, the system works with the status management module to freeze the status of key nodes involved in the fault chain. The system clearly marks which nodes' tasks "need to be interrupted" (corresponding to blocking type), "need to be reset" (corresponding to correction type), or "need to be enhanced monitoring" (corresponding to enhancement type), providing clear operation objects for subsequent multi-factor interactions.

[0106] The system performs complex interaction analysis between the original executable task flow and the newly inserted alert interaction task flow to determine their logical relationships; mutual exclusion analysis: determining whether the alert task needs to exclusively occupy certain resources; for example, a corrective task may need to exclusively occupy a database connection lock, in which case the original query task must be suspended; dependency analysis: determining whether the execution of the alert task depends on the intermediate results of the original task; for example, a "data cleaning" corrective task may need to first obtain a snapshot of the "dirty data" generated by the original task; timing analysis: determining the mixed execution order of the two types of tasks; for example, whether to execute "blocking" first and then "correction", or to execute the "enhancement" task silently in the background without interrupting the foreground task.

[0107] Based on the results of multi-factor interactions, the system determines the precise matching relationship between executable tasks and early warning interaction tasks, forming multiple task combinations; replacement matching: early warning tasks directly replace the original executable tasks; for example, replacing a failed "call the main API" task with a "call the backup API" task, which is represented by node replacement in the task graph; precondition / postcondition matching: early warning tasks serve as preconditions (such as requiring security checks to be completed first) or postconditions (such as cleanup operations after task failure) for the original tasks; the system links these tasks together to form a combination chain of "original tasks + compensation tasks"; parallel accompanying matching: enhanced tasks (such as logging and monitoring reporting) are executed in parallel with the original tasks, forming a parallel combination of "main tasks + accompanying tasks".

[0108] The system constructs specific collaborative task channels based on the identified multiple task combinations; this is the core execution mechanism of S14. Utilizing the MCP unified context protocol, the system extends the original task communication channels with a dedicated early warning sub-channel. Early warning tasks send high-priority control signals to the collaborative module through this channel. The scheduling module dynamically adjusts resource channels according to the type of task combination. For blocking task combinations, the CPU / GPU resource allocation of the original node is immediately cut off. For corrective task combinations, additional computing resources are allocated for retrying or computation. The system ensures data consistency among multiple task combinations. For example, new data generated by corrective tasks is synchronized in real time to downstream nodes that depend on this data through the shared context, achieving seamless switching and recovery of task flows.

[0109] Furthermore, in the collaborative task channel, the execution status of executable tasks is maintained through an asynchronous message queue, and the execution progress of executable tasks is monitored. Based on the execution progress of each executable task and the execution status of the corresponding task execution nodes, the order of multiple executable tasks is determined, and corresponding interactive operation measures are constructed during the iteration process. This approach takes into account the overall consideration of the execution progress of each executable task and the execution status of the corresponding task execution nodes, ensuring the accuracy of the order of multiple executable tasks, improving the accuracy of the collaborative task channel, and ensuring the accuracy of the interactive operation measures of each task.

[0110] At this time, the system deploys an asynchronous message queue mechanism in the collaborative task channel to ensure that while introducing early warning interaction tasks (such as blocking, correction, and enhancement tasks), the original executable tasks can still maintain correct flow; early warning tasks (such as resource switching and data retry) are inserted into the queue as high-priority messages and are processed asynchronously by the scheduling module, without directly interrupting the running thread of the underlying Agent in a synchronous blocking manner.

[0111] During channel execution, the system uses MCP (Model Context Protocol) to continuously maintain the integrity of the shared context; even if a task node is replaced (such as switching from the primary Agent to the backup Agent), the asynchronous message queue ensures that the context data (Context_ID) can be accurately transmitted to the new execution subject, thereby maintaining the continuity of executable tasks and avoiding state loss due to switching.

[0112] The system monitors the execution progress of each executable task (including corrected and unaffected tasks) in real time through the collaborative task channel and reorders the task queue in real time based on the dynamically changing progress. The system collects execution progress data, including "remaining estimated time", "percentage of completed sub-steps", and "resource consumption rate". The system dynamically adjusts the queue order based on progress indicators. For example, if a task that was originally low priority is rapidly approaching completion (progress rate > 90%), the system will temporarily increase its priority to release the computing resources it occupies. Conversely, if a task stagnates (progress not updated for a long time), the system will downgrade or suspend it. In each iteration of the collaborative channel, the scheduling module recalculates the execution order of all ready nodes based on the current snapshot to ensure that the "most urgent" or "closest to completion" tasks always get priority access to computing resources.

[0113] Based on the aforementioned monitoring, maintenance, and sorting processes, the system iteratively builds and refines the final interactive operation measures. These measures aim to provide users or external systems with feedback on the real-time status of the current task execution and corresponding strategies; aggregate the latest status (in execution, completed, under correction) of each task (original task + warning task) within the channel into a status report; convert the reordered execution path and the progress of each node into a visual progress bar or flowchart status; explain the interactive operation currently being executed by the system (such as "attempting to retry the database connection for the second time" or "switched to the backup model engine"); the interactive operation measures are not statically generated but dynamically updated with the progress of each iteration within the collaborative task channel; the system utilizes the text generation capabilities of LLM to generate prompts in real time that are appropriate for the current context, ensuring that users always receive the most accurate and timely feedback.

[0114] Please see Figure 6 , Figure 6 This is a schematic diagram of the structural composition of the natural language interactive operating system based on a large language model according to an embodiment of the present invention; the natural language interactive operating system based on a large language model is applied to the above-mentioned natural language interactive operation method based on a large language model; the natural language interactive operating system based on a large language model includes:

[0115] The language processing module 21 is used to acquire the corresponding natural language based on the language receiving port, and determine multiple language combinations based on the division of the natural language. Each language combination matches the corresponding executable task; the executable task is decomposed and multiple subtask graphs with dependencies are output.

[0116] The execution coordination module 22 is used to determine the corresponding task execution path based on the identification of multiple subtask graphs, mark each task execution node, mark the corresponding execution priority of each task execution node, and build the execution coordination relationship between each task execution node.

[0117] The early warning interaction module 23 is used to collect fault signals, determine the corresponding fault content by tracing the fault signals, determine the fault task chain based on the fault content, the corresponding task execution node and the coordination relationship, and match the corresponding early warning interaction measures based on the fault task chain.

[0118] The interactive operation module 24 is used to determine multiple early warning interactive tasks based on the identification of early warning interactive measures, construct a collaborative task channel along the multiple early warning interactive tasks and the executable tasks of each task execution node, maintain the execution of executable tasks in the collaborative task channel, and form corresponding interactive operation measures.

[0119] In another embodiment of this application, such as Figure 7As shown, the overall architecture of the system of this invention includes the following main layers and components: the LLM interaction layer, the Agent collaboration layer, and the system resource layer. The LLM interaction layer is located at the top of the architecture, containing the large language model and its related prompting processing and function call interfaces, directly providing a natural language interaction entry point for users. The Agent collaboration layer consists of multiple intelligent agents with different functions, a task scheduling module, a state management module, etc., used to parse and execute task requests from the LLM layer. The system resource layer includes underlying hardware resources (such as CPU, GPU, storage devices, etc.) and basic operating system services (such as process management, memory management, etc.), providing computing and storage support for the upper layers. This invention deeply integrates LLM into the operating system kernel, making it and traditional OS services form a unified platform, on which a multi-Agent collaborative processing mechanism for complex tasks is built.

[0120] like Figure 8 As shown, when a user inputs a natural language command through a terminal window or voice interface, the LLM interaction layer begins operation. The LLM first receives the text command and parses it using the system-provided Prompt context (including current user permissions, a list of available system functions, and formatting requirements). Based on the command content and pre-configured function signatures, the LLM determines whether to call internal system functions or external tools to complete the user's request. For simple question-and-answer or chat-like interactions, the LLM can directly generate a natural language response; however, for commands requiring action, the LLM converts them into one or more "function call" requests according to its internal strategy.

[0121] For example, when a user enters the instruction, "Please scan my calendar and schedule 3 meetings for me next week," the Large Language Model (LLM) will automatically identify that it contains two subtasks: first, reading the user's calendar events for next week (which may require calling the calendar read API or calendar agent); and second, automatically generating 3 meeting schedules based on available time slots (which requires calling the meeting scheduling agent). Based on this, the LLM internally constructs a structured function call plan, usually represented in JSON format.

[0122] The LLM first calls the "Calendar.read_events" function to read next week's schedule, and then passes the returned data to the "Scheduler.create_meetings" function to generate three meeting schedules. In the actual implementation, the "function" and parameter specifications are determined according to the MCP protocol or predefined API specifications. After generating this call sequence, the LLM submits it as a system call request to the Agent coordination layer.

[0123] The LLM interaction layer includes a function registry that lists the system's available functional interfaces (including operating system service calls, Agent capability interfaces, external Web APIs, etc.) and their parameter formats. When the LLM parses user intent, it matches the appropriate function or tool in the registry. If a match is found, the LLM generates a call request according to the specification; if no directly matching function is found, the LLM can also send the task description to the task coordination module, which decides how to further decompose and process it. Through this language-driven system call mechanism, the user's natural language commands are seamlessly mapped to specific executable actions, enabling the operating system to understand and respond to high-level semantic instructions.

[0124] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A natural language interactive operating system based on a large language model, characterized in that, include: The language processing module is used to acquire the corresponding natural language based on the language receiving port, and determine multiple language combinations based on the division of the natural language. Each language combination is matched with a corresponding executable task; the executable task is decomposed and outputs multiple subtask graphs with dependencies. The execution coordination module is used to determine the corresponding task execution path based on the identification of multiple subtask graphs, mark each task execution node, mark the corresponding execution priority of each task execution node, and build the execution coordination relationship between each task execution node; The early warning interaction module is used to collect fault signals, determine the corresponding fault content by tracing the fault signals, determine the fault task chain based on the fault content, the corresponding task execution node and the coordination relationship, and match the corresponding early warning interaction measures according to the fault task chain. The interactive operation module is used to identify multiple early warning interactive tasks based on the identification of early warning interactive measures, construct a collaborative task channel along the multiple early warning interactive tasks and the executable tasks of each task execution node, maintain the execution of executable tasks in the collaborative task channel, and form corresponding interactive operation measures.

2. The natural language interactive operating system based on a large language model according to claim 1, characterized in that, The process involves acquiring the corresponding natural language based on the language receiving port, determining multiple language combinations based on the segmentation of the natural language, and matching each language combination with a corresponding executable task. The executable task is decomposed and outputs a graph of multiple subtasks with dependencies, including: The markup language receiving port is used to obtain the corresponding natural language, which is input by the client, based on the monitoring of the language receiving port. The system processes natural language and transforms it into standardized task requests. Based on the context information corresponding to each task request and the natural language, it determines the corresponding language combination to output multiple language combinations.

3. The natural language interactive operating system based on a large language model according to claim 2, characterized in that, The process involves acquiring the corresponding natural language based on the language receiving port, determining multiple language combinations based on the segmentation of the natural language, and matching each language combination with a corresponding executable task. The executable task is decomposed and outputs a graph of multiple subtasks with dependencies, including: In each language combination, multi-factor identification is performed on the language combination, and the corresponding sub-task features are marked during the identification process. The corresponding executable task is matched based on the synthesis of multiple sub-task features. The executable task is logically decomposed and the corresponding sub-task nodes are output. A sub-task graph is constructed based on the node position and node priority of each sub-task node, and multiple sub-task graphs are matched to mark the corresponding dependencies.

4. The natural language interactive operating system based on a large language model according to claim 1, characterized in that, The process of determining the corresponding task execution path based on the identification of multiple sub-task graphs, marking each task execution node, marking each task execution node with its corresponding execution priority, and constructing the execution coordination relationship between the task execution nodes includes: In a multi-subtask graph, the corresponding sub-execution route is determined based on the identification of each subtask graph. The multiple sub-execution routes and their corresponding dependencies are synthesized by multiple factors, and multiple executable nodes are output. Based on the multiple executable nodes, the key task content of the subtask graph, and the corresponding task priority, the corresponding task execution path is determined. This task execution path covers the priorities of different executable nodes.

5. The natural language interactive operating system based on a large language model according to claim 4, characterized in that, The process of determining the corresponding task execution path based on the identification of multiple sub-task graphs, marking each task execution node, marking each task execution node with its corresponding execution priority, and constructing the execution coordination relationship between the task execution nodes further includes: Multiple executable nodes are matched, and the response signals of each executable node are combined to determine the task execution nodes in the current scenario. The execution content of the current scenario is then used to determine the corresponding execution priority. At the same time, the status of each task execution node is marked, and the execution priority of each task execution node is determined based on its status, corresponding execution timeliness, and task requirement level. The execution intention of each task execution node is recorded, and the corresponding decision content is determined by tracing the execution intention. Based on the decision content and corresponding execution content of each task execution node, the execution coordination relationship between each task execution node is determined.

6. The natural language interactive operating system based on a large language model according to claim 1, characterized in that, The process involves collecting fault signals, tracing the fault signals to determine the corresponding fault content, determining the fault task chain based on the fault content, the corresponding task execution node, and the collaborative relationship, and matching corresponding early warning interaction measures based on the fault task chain, including: The system monitors the execution status of each task execution node in real time, determines the corresponding fault signals based on the detection of the execution status, performs signal analysis on the fault signals to output the corresponding fault content, and divides it into multiple sub-fault items.

7. The natural language interactive operating system based on a large language model according to claim 6, characterized in that, The process of collecting fault signals, tracing the fault signals to determine the corresponding fault content, determining the fault task chain based on the fault content, the corresponding task execution node, and the coordination relationship, and matching corresponding early warning interaction measures based on the fault task chain also includes: Multiple sub-fault items and their corresponding task execution nodes are deeply integrated, and a corresponding fault framework is output. Based on the fault framework and the collaborative relationship between each task execution node, the corresponding fault task chain is determined, and the dynamic changes of the fault content are marked. Based on the dynamic changes in the fault content, the corresponding prediction results are determined, and the corresponding early warning interaction measures are determined along the mapping relationship between the prediction results, the corresponding fault factors, and the early warning interaction measures. These early warning interaction measures present the early warning interaction content of each task execution node at the fault early warning level.

8. The natural language interactive operating system based on a large language model according to claim 1, characterized in that, The method identifies multiple early warning interaction tasks based on the recognition of early warning interaction measures, constructs a collaborative task channel along the multiple early warning interaction tasks and the executable tasks of each task execution node, maintains the execution of executable tasks in the collaborative task channel, and forms corresponding interactive operation measures, including: The early warning interaction measures are identified and transformed into multiple early warning interaction tasks, which include blocking tasks, correction tasks, and enhancement tasks. At the same time, the executable tasks of each task execution node are marked, and multi-factor interaction is performed between the executable tasks of each task execution node and multiple early warning interaction tasks. During the interaction process, the corresponding matching relationship is determined, and the corresponding multi-task combination is determined along the matching relationship. Based on the identification of the multi-task combination, the corresponding collaborative task channel is determined.

9. The natural language interactive operating system based on a large language model according to claim 8, characterized in that, The method of identifying multiple early warning interaction tasks based on the recognition of early warning interaction measures, constructing a collaborative task channel along the multiple early warning interaction tasks and the executable tasks of each task execution node, maintaining the execution of executable tasks in the collaborative task channel, and forming corresponding interactive operation measures, further includes: In the collaborative task channel, the execution status of executable tasks is maintained through an asynchronous message queue, and the execution progress of executable tasks is monitored. Based on the execution progress of each executable task and the execution status of the corresponding task execution nodes, the order of multiple executable tasks is determined, and corresponding interactive operation measures are constructed during the iteration process.

Images