An operating system with an intent interface module and a control method thereof

Abstract

The application provides an operating system with an intention interface module and a control method thereof, the system is provided with a kernel state module, the kernel state module is internally provided with an intention interface module, the intention interface module is internally provided with an intention definition and description unit, a global intention registry, an intention routing and execution unit, a self-description and automatic discovery unit and a polymorphic access interface unit, the polymorphic access interface unit provides a kernel state access path, a user state access path and a command line tool, can greatly reduce interaction delay, intention end-to-end delay is reduced from about 400 milliseconds of a traditional command line mode to 3-4 microseconds, delay is reduced by about 99.99%, and the determinacy low delay requirement of a real-time operating system scene is met.

Description

Technical Field

[0001] This invention relates to the technical field of AI intelligent agents, and more specifically to an operating system with an intent interface module and its control method. Background Technology

[0002] Currently, operating the operating system through AI agents (i.e., artificial intelligence agents) mainly relies on two methods: Method 1: Command-line text interaction. The AI ​​agent connects to the operating system shell via remote terminal protocols such as SSH, converts its operational intentions into shell command text, sends it to the operating system for execution, and then performs natural language parsing on the returned text output to extract the required information. For example, reading sensor temperature requires: constructing a shell command → sending it to the terminal → waiting for text output → parsing the text using a large language model → extracting the temperature value.

[0003] Method 2: Graphical Interface Simulation Operation. The AI ​​agent captures screen images of the operating system's graphical interface, uses a visual model to identify interface elements and their coordinate positions, simulates mouse clicks and keyboard input to complete operations, and then takes another screenshot to verify the operation results.

[0004] Both of these methods are essentially ways in which AI agents simulate human operation of computers, that is, indirectly completing tasks through interactive interfaces (command-line interfaces or graphical user interfaces) designed for humans.

[0005] The defects and shortcomings of the above-mentioned prior art are as follows: 1) High latency and low efficiency: Taking reading sensor temperature as an example, the actual underlying hardware operation only requires microseconds (about 10μs for the read() system call), but after Shell text construction, network transmission, text parsing, and large language model understanding, the end-to-end latency can reach about 400 milliseconds, resulting in an efficiency loss of tens of thousands of times.

[0006] 2) High token consumption and high cost: In the command line mode, the unstructured text output by the Shell requires a large language model to consume a lot of inference tokens for parsing and understanding (about 80 tokens per operation), while the truly effective information (such as a temperature value) is very little, resulting in a serious waste of computing resources.

[0007] 3) Lack of semantic structure and poor reliability: The shell text output format is not fixed; different systems and versions may have different command output formats. The AI ​​agent's text parsing is prone to errors, leading to task execution failure. The graphical interface relies on coordinate positioning, and changes in the interface layout can easily cause operation failure.

[0008] 4) Unable to automatically discover device capabilities: The AI ​​agent cannot automatically know which operations and parameter formats the target device supports. Adaptation logic needs to be written in advance for each device, and plug-and-play functionality cannot be achieved.

[0009] 5) Not suitable for real-time system scenarios: The high latency and uncertainty introduced by the above methods cannot meet the strict requirements of determinism and low latency in real-time operating system scenarios such as industrial control and aerospace.

[0010] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention

[0011] To address the shortcomings and deficiencies in existing technologies, this invention provides an operating system with an intent interface module and its control method.

[0012] The specific solution provided by this invention is as follows: An operating system with an intent interface module, the system comprising: The calling module is connected to the user-mode interface module. The calling module converts its operation to be executed into a structured intent and initiates an intent call to the intent interface module through the user-mode interface module. When the system starts, the calling module registers the intent processing function with the intent interface module through the user-mode interface module. When the corresponding intent is called, the intent processing function completes the processing. The user-mode interface module encapsulates interfaces for intent invocation, intent registration, intent list query, and intent description query, and provides a unified intent invocation interface to the calling module. It also performs inter-process communication and synchronizes user-mode intents to the global intent registry. The hardware driver module, during initialization, registers the kernel-mode intent corresponding to the sensor with the intent interface module, and directly reads hardware registers and returns structured data when invoked. Simultaneously, during initialization, the hardware driver module registers the kernel-mode intent corresponding to the actuator with the intent interface module, and converts input parameters into hardware control signals to drive the actuator action when invoked. Furthermore, during initialization, the hardware driver module registers the kernel-mode intent corresponding to the communication interface with the intent interface module, and transmits and receives input data through the corresponding physical bus when invoked. Finally, during initialization, the hardware driver module registers the kernel-mode intent corresponding to the additional device with the intent interface module. Its features are: The system also includes a kernel-mode module, which is connected to both the user-mode interface module and the hardware driver module. The kernel-mode module contains an intent interface module, which in turn includes: An intent definition and description unit is connected to the global intent registry data. The intent definition and description unit defines the intent structure, determines the intent naming rules and its input and output parameters, and determines the corresponding semantic description text. A global intent registry, which uses a hash table data structure and uses intent namespace identifiers as keys; The intent routing and execution unit is connected to the global intent registry and the calling module. The intent routing and execution unit searches for the target intent in the global intent registry according to the intent call, selects the corresponding processing function according to the type of the target intent, passes the input parameters to the corresponding processing function, and returns the processing result to the calling module. The self-describing and automatic discovery unit is connected to the global intent registry data. The self-describing and automatic discovery unit provides a corresponding interface for the AI ​​intelligent agent unit. The AI ​​intelligent agent unit can obtain device information, intent information and device-supported intent information through the corresponding interface. A polymorphic access interface unit is connected to the calling module to provide the calling module with kernel-mode access paths, user-mode access paths, and command-line tools.

[0013] As a further preferred embodiment of the present invention, the intent structure defined by the intent definition and description unit includes namespace identifiers, structured descriptions of input parameters and output parameters, and semantic description text.

[0014] As a further preferred embodiment of the present invention, the namespace adopts a hierarchical dot-matrix naming rule and classifies the namespace identifiers according to domain or level; The structured description of the input parameters includes the parameter name, parameter type, and parameter constraints; the structured description of the output parameters includes the structure of the returned result and the meaning of the fields. The semantic description text describes the function corresponding to the intent in natural language, and the semantic description text can be recognized by the language model inside the AI ​​agent unit.

[0015] As a further preferred embodiment of the present invention, the global intent registry can uniformly manage kernel-mode intents and user-mode intents, wherein... The kernel-mode intent is a function that is registered directly with the global intent registry by the device driver and marked in kernel mode. The kernel-mode mark indicates that the call does not need to cross the process boundary. The user-mode intent is registered with the kernel by the AI ​​native application unit through the character device interface and input / output control system provided by the kernel, and is marked as user-mode. The user-mode mark indicates that an inter-process communication is required when calling it.

[0016] As a further preferred embodiment of the present invention, the kernel-mode intent and the user-mode intent adopt a unified data structure in the global intent registry, and the calling module does not distinguish between the kernel-mode intent and the user-mode intent.

[0017] As a further preferred embodiment of the present invention, in the intent routing and execution unit, When the target intent is a kernel-mode intent, the kernel-mode processing function corresponding to that intent is called directly in kernel mode. The kernel-mode processing function works by the following steps: After the intent routing and execution unit matches the corresponding intent in the global intent registry according to the intent namespace identifier, it directly passes the input parameters to the kernel-mode processing function by function pointer call. The kernel-mode processing function reads or writes device registers or accesses kernel data, fills the processing result into the output parameters, and returns. When the target intent is a user-space intent, the user-space process that registered the intent is woken up through the semaphore mechanism, the input parameters are passed to the user-space processing function, and the processing result is returned to the calling module after the processing is completed. The working process of the user-mode processing function includes the following steps: when the intent is called, the process where it is located is woken up from the suspended state by the semaphore mechanism, the input parameters are read from the shared buffer and the business logic is executed, the processing result is written to the shared buffer and the kernel is notified, and then the kernel returns the processing result to the calling module.

[0018] As a further preferred embodiment of the present invention, the intent routing and execution unit can select either a synchronous call mode or an asynchronous call mode as needed when making intent invocations; wherein, The synchronous call mode blocks and waits for the result to return; it includes the following steps: 1) The caller intends to invoke the interface; 2) The intent routing and execution unit completes intent lookup, execution, and forwarding in kernel mode; 3) The calling process is suspended on the result semaphore; 4) After the intent processing function completes, the resulting semaphore is released; 5) The calling process is awakened and retrieves the result data; The asynchronous call mode returns a ticket identifier, and the calling module obtains the execution result through polling or a result waiting interface; wherein... The calling module obtains the execution result through polling, including the following steps: 1) After the asynchronous call interface returns a ticket identifier, the calling module periodically calls the polling interface with that ticket as a parameter; 2) The intent routing and execution unit looks up the internal status table based on the ticket. If the intent processing function has not yet been completed, it immediately returns to the unready state. If it has been completed, it returns the result data along with the ready state to the caller. The calling module obtains the execution result through the waiting result interface, which includes the following steps: 1) The calling module calls the waiting-for-result interface with the ticket as a parameter; 2) After the intent routing and execution unit finds the corresponding result semaphore based on the ticket, it suspends the calling process on that semaphore; 3) When the intent processing function completes, it wakes up the caller by releasing a semaphore and returns the result.

[0019] As a further preferred embodiment of the present invention, the self-describing and automatic discovery unit provides the AI ​​agent unit with an intent list query interface, an intent description query interface, and a skill export interface. The AI ​​agent unit can obtain a list of all registered intents in the current system through the intent list query interface; The AI ​​agent unit can return description information corresponding to the intent based on the intent namespace identifier through the intent description query interface. The description information includes a structured description of the input parameters, a structured description of the output parameters, and semantic description text. The AI ​​agent unit can export all the intents supported by the device in a skill description format that the AI ​​agent unit can directly understand through the skill export interface.

[0020] As a further preferred embodiment of the present invention, in the polymorphic access interface unit, The kernel-mode access path controls the kernel's internal function call path system to call the intent list query interface, intent description query interface, and skill export interface to perform registration, deregistration, invocation, and query operations for intents. The user-mode access path provides a programming interface for applications through the user-mode language library and daemon process via inter-process communication; The command-line tool allows users to view, invoke, and query intent lists.

[0021] Furthermore, the present invention also provides a control method for an operating system with an intent interface module, characterized by comprising the following steps: S100: The AI ​​agent unit sends structured intents; S200: The intent interface module selects the device that matches the structured intent based on the obtained structured intent, and outputs the execution result through the processing function corresponding to the intent; S300: Returns a structured result to the calling module.

[0022] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides an operating system with an intent interface module and its control method, which significantly reduces interaction latency. The end-to-end latency of intent invocation is reduced from approximately 400 milliseconds in the traditional command-line method to 3-4 microseconds, a latency reduction of approximately 99.99%, meeting the deterministic low-latency requirements of real-time operating system scenarios.

[0023] 2) This invention provides an operating system and its control method with an intent interface module, eliminating token consumption and computational resource waste. The AI ​​agent directly sends and receives structured data, eliminating the need for a large language model to parse unstructured text. The token consumption per operation is reduced from approximately 80 to zero, and the number of operation steps is reduced by approximately 80%.

[0024] 3) This invention provides an operating system with an intent interface module and its control method, improving interaction reliability. Through the structured description of input and output parameters contained in the intent structure, the uncertainty of text parsing and coordinate positioning is eliminated. The result format of intent invocation is strictly determined and is unaffected by changes in system version or interface layout.

[0025] 4) This invention provides an operating system and its control method with an intent interface module, enabling automatic discovery of device capabilities with zero configuration. The AI ​​agent can automatically learn the intent operations and parameter formats supported by the device at runtime through the corresponding interface, achieving plug-and-play functionality without the need to pre-write adaptation logic for each device.

[0026] 5) This invention provides an operating system with an intent interface module and its control method, natively adapted to real-time system scenarios. Microsecond-level deterministic latency and a kernel-level zero-context-switching call mechanism make this solution naturally suitable for operating system scenarios with stringent real-time requirements, such as industrial control and aerospace.

[0027] 6) This invention provides an operating system with an intent interface module and its control method. The intent interface, as the third type of standard interface of the operating system, proposes for the first time the concept of an intent interface (AII) module for AI intelligent agents, on top of the traditional API (for human programmers) and ABI (for compilers), enabling the operating system to natively support the structured semantic interaction of AI intelligent agents.

[0028] 7) This invention provides an operating system with an intent interface module and its control method. The global intent registry can manage kernel-mode intents and user-mode intents in a unified manner. By adopting a unified data structure for kernel-mode intents and user-mode intents in the global intent registry, and without distinguishing between kernel-mode intents and user-mode intents by the calling module, driver-level intents (zero context switching direct call) and application-level intents (semaphore IPC) are incorporated into the same lookup and routing mechanism. The calling party is completely transparent, taking into account both extreme performance and flexible expansion.

[0029] 8) This invention provides an operating system with an intent interface module and its control method, achieving microsecond-level end-to-end call latency. The average call latency for kernel-mode intents is 3.2 microseconds, and for user-mode intents it is 4.3 microseconds. Compared to the approximately 400 millisecond latency of the traditional CLI method, this represents a latency reduction of approximately 99.99%, meeting the deterministic requirements of real-time systems. Attached Figure Description

[0030] Figure 1 The diagram shown is a logical structure diagram of the operating system provided by this invention.

[0031] Figure 2 The diagram shows a comparison of the steps of the control method provided by this invention with the traditional CLI text interaction method. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0034] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0035] [First Embodiment] like Figure 1 The figure shown is an operating system with an intent interface module provided in the first embodiment of the present invention. The system includes: The calling module is data-connected to the user-mode interface module. In this embodiment, the calling module includes an AI agent unit, an AI native application unit, a traditional application unit, and a script tool unit. The AI ​​agent unit converts its operation to be executed into a structured intent and initiates an intent call to the intent interface module via the user-mode interface module. The AI ​​native application unit has an intent processing function internally, which can be registered with the intent interface module via the user-mode interface module at system startup, and processed by the intent processing function when the corresponding intent is invoked. The traditional application unit is an existing application that interacts directly with the operating system through standard application programming interfaces such as POSIX; it does not need to go through the intent interface module and therefore does not have a data connection with the user-mode interface module. The script tool unit includes an intent call command-line tool, which initiates an intent call to the intent interface module via the user-mode interface module to support debugging and manual verification. The user-mode interface module includes a user-mode language library and a daemon process unit; among them... The user-mode language library uses application-oriented user-mode C language function libraries, such as the libai user-mode language library. It encapsulates interfaces for intent invocation, intent registration, intent list query, and intent description query, and provides a unified intent invocation interface to the calling module. The daemon unit selected is the aiid daemon unit, which runs in user space and acts as the intent registry center and routing proxy on the user space side. It communicates with user space language libraries such as libaii through Unix Domain Socket and synchronizes user space intents to the global intent registry. The hardware driver module internally includes a sensor driver unit, an actuator driver unit, a communication driver unit, and an auxiliary device driver unit. The sensor driver unit connects to input devices such as temperature and pressure sensors, registers the corresponding kernel-state intent with the intent interface module during hardware driver module initialization, and directly reads hardware registers and returns structured data when invoked. The actuator driver unit connects to output devices such as motors and valves, registers the corresponding kernel-state intent with the intent interface module during hardware driver module initialization, and converts input parameters into hardware control signals to drive the actuator when invoked. The communication driver unit connects to communication interfaces such as CAN, RS485, and Ethernet, registers the corresponding kernel-state intent with the intent interface module during hardware driver module initialization, and transmits and receives input data via the corresponding physical bus when invoked. The auxiliary device driver unit connects to auxiliary devices (i.e., other types of devices besides the three mentioned above) and registers the corresponding kernel-state intent with the intent interface module during hardware driver module initialization. The improvement of this embodiment compared to the prior art is as follows: The system also includes a kernel-mode module, which is connected to the user-mode interface module and the hardware driver module. The kernel-mode module contains an intent interface module, a process thread scheduler, a virtual machine monitor (VMM), an inter-process communication (IPC) system, an I / O interface subsystem, a network protocol stack, and a file system. It provides the corresponding operating environment for running pre-defined applications. The internal structure of the operating system kernel module adopts existing solutions in the prior art and is compatible with standard interfaces such as POSIX.

[0036] In this embodiment, the intent interface module internally includes an intent definition and description unit. This unit is connected to the global intent registry data. The intent definition and description unit defines the intent structure, determines the intent naming rules and their input and output parameters, and also determines the corresponding semantic description text. In this embodiment, The intent structure includes a namespace identifier, structured descriptions of input and output parameters, and semantic description text. This eliminates the uncertainty of text parsing and coordinate positioning. The result format of the intent invocation is strictly defined and unaffected by changes in system version or interface layout. The namespace adopts a hierarchical dot-matrix naming rule. The namespace identifier is a string formed according to the hierarchical dot-matrix naming rule. For example, "hw.sensor.temperature" means "hardware layer-sensor-temperature". The namespace identifier is classified according to domain or level to avoid naming conflicts. The structured description of the input parameters uses JSON Schema format, which includes the parameter name, parameter type, and parameter constraints; the structured description of the output parameters includes the structure of the returned result and the meaning of the fields. The semantic description text describes the function corresponding to the intent in natural language, and the semantic description text can be recognized by the internal language model of the AI ​​agent unit so that the built-in language model of the AI ​​agent (such as a large language model) can understand the purpose of the intent.

[0037] The global intent registry uses a hash table data structure with intent namespace identifiers as keys to achieve fast lookup with O(1) time complexity. In this embodiment, fast lookup with O(1) time complexity means that the intent namespace identifier is used as the key, and the namespace identifier is mapped to the hash bucket index through a hash function. When looking up an intent, only one hash calculation needs to be performed on the input intent namespace identifier and the corresponding hash bucket needs to be accessed to hit the target intent item. Its average lookup time complexity is independent of the number of intents registered in the registry and is denoted as O(1). In this embodiment, The structured intents in this embodiment include kernel-mode intents and user-mode intents, wherein: Kernel-mode intents require no process context switching, have no inter-process communication overhead, and have low end-to-end call latency, making them suitable for high-frequency, low-latency hardware operations such as sensor reading and actuator control. User-mode intents run in user mode and can use user-mode resources such as general-purpose language libraries, file systems, and network services. They have fewer development constraints and are suitable for implementing complex business logic. The global intent registry enables unified management of kernel-mode and user-mode intents. Kernel-mode intents are registered directly with the global intent registry by the device driver (in this embodiment, the handler function is selected) and marked in kernel mode (e.g., ipc_hops=0). The kernel-mode mark indicates that the call does not need to cross the process boundary. User-mode intents are registered with the kernel by the AI ​​native application unit through the character device interface (such as dev or aii) and input / output control system provided by the kernel, and are marked with user-mode (e.g., ipc_hops=1). The user-mode mark indicates that an inter-process communication is required when calling.

[0038] Furthermore, in this embodiment, kernel-mode intents and user-mode intents adopt a unified data structure in the global intent registry, and the calling module does not distinguish between kernel-mode intents and user-mode intents. The two types of intents are represented by a unified data structure in the global intent registry, which is completely transparent to the calling module, and the calling module does not need to distinguish the implementation location of the intent.

[0039] By adopting a unified data structure for kernel-mode and user-mode intents in the global intent registry, and without distinguishing between kernel-mode and user-mode intents by the calling module, driver-level intents (zero context switching direct calling) and application-level intents (semaphore IPC) are incorporated into the same lookup and routing mechanism, making it completely transparent to the caller and balancing extreme performance with flexible scalability.

[0040] The intent routing and execution unit is connected to the global intent registry and the calling module data respectively. The intent routing and execution unit searches for the target intent in the global intent registry according to the intent call, selects the corresponding processing function according to the type of the target intent, passes the input parameters to the corresponding processing function, and returns the processing result to the calling module. In the intent routing and execution unit provided in this embodiment, When the target intent is a kernel-mode intent, the kernel-mode processing function corresponding to that intent is called directly in kernel mode. In this embodiment, the kernel-mode processing function is a callback function that is directly registered to the global intent registry by the device driver during its own initialization phase, and it runs in kernel mode; The kernel-mode processing function works by following these steps: After the intent routing and execution unit matches the corresponding intent in the global intent registry based on the intent namespace identifier, it directly passes the input parameters to the kernel-mode processing function using a function pointer call. The kernel-mode processing function then reads or writes device registers or accesses kernel data, fills the processing result into the output parameters, and returns. The entire process involves no context switching and no inter-process communication overhead, achieving minimal latency. In actual testing, on ARM architecture processors (such as the RK3588), using an ARM hardware timer (e.g., CNTVCT_EL0, 16 nanosecond resolution) for 1000 precise loops, the average latency for kernel-mode intent calls is 3193 nanoseconds (approximately 3.2 microseconds). When the target intent is a user-space intent, the user-space process that registered the intent is woken up through the semaphore mechanism, the input parameters are passed to the user-space processing function, and the processing result is returned to the calling module after the processing is completed. In this embodiment, the user-mode processing function is a callback function registered in the global intent registry by the AI ​​native application unit through user-mode language libraries such as libaii, and it runs in user mode; The working process of a user-mode processing function includes the following steps: when an intent is called, the process it resides in is woken up from the suspended state by the semaphore mechanism, the input parameters are read from the shared buffer, the business logic is executed, the processing result is written to the shared buffer and the kernel is notified, and then the kernel returns the processing result to the calling module.

[0041] It is worth noting that the semaphore mechanism in this embodiment is a lightweight synchronization primitive provided by the operating system kernel. The kernel maintains a non-negative counter and a wait queue. Processes can perform acquire (Pend) and release (Post) operations on it. When the count is zero, the process that performed the acquire operation is suspended and added to the wait queue. When other processes or the kernel perform the release operation, the count is incremented and the process in the wait queue is woken up according to the scheduling policy. By performing a release operation on the request semaphore corresponding to the intent, the kernel wakes up the process where the user-mode processing function suspended on the semaphore is located. According to actual measurements, the average invocation latency of user-space intents is 4303 nanoseconds (approximately 4.3 microseconds).

[0042] Furthermore, the intent routing and execution unit in this embodiment can select either synchronous or asynchronous call mode as needed when making intent invocations. The synchronous call mode simplifies the caller's programming model, with the caller blocking and waiting before the result is returned, thus adapting to scenarios that are latency-sensitive and can be completed in a single call. The asynchronous call mode allows the caller to continue processing other business or concurrently initiate multiple intent invocations during intent execution, thereby improving single-threaded concurrency and overall system throughput, and adapting to scenarios with long-duration intents or those requiring concurrent scheduling of multiple devices. in, Synchronous call mode blocks and waits for the result to return; that is, after the calling process initiates the intent call, it is suspended by the operating system and no longer scheduled for execution until the intent routing and execution unit writes the processing result to the return buffer and wakes it up again through a semaphore, at which point the caller continues to execute subsequent instructions. Its working process includes the following steps: 1) The caller intends to invoke the interface; 2) The intent routing and execution unit completes intent lookup, execution, and forwarding in kernel mode; 3) The calling process is suspended on the result semaphore; 4) After the intent processing function completes, the resulting semaphore is released; 5) The calling process is awakened and retrieves the result data; In asynchronous call mode, a ticket identifier is returned, and the calling module obtains the execution result through polling or waiting for a result interface; where... The calling module obtains the execution result through polling, including the following steps: 1) After the asynchronous call interface returns a ticket identifier, the calling module periodically calls the polling interface with that ticket as a parameter; 2) The intent routing and execution unit looks up the internal status table based on the ticket. If the intent processing function has not yet been completed, it immediately returns to the unready state. If it has been completed, it returns the result data along with the ready state to the caller. The calling module obtains the execution result through the waiting result interface, which includes the following steps: 1) The calling module calls the waiting-for-result interface with the ticket as a parameter; 2) After the intent routing and execution unit finds the corresponding result semaphore based on the ticket, it suspends the calling process on that semaphore; 3) When the intent processing function completes, it wakes up the caller by releasing a semaphore and returns the result.

[0043] The self-description and automatic discovery unit is connected to the global intent registry data. The self-description and automatic discovery unit provides corresponding interfaces for the AI ​​intelligent agent unit. The AI ​​intelligent agent unit can obtain device information, intent information and device-supported intent information through the corresponding interfaces. Specifically, in this embodiment, the self-description and automatic discovery unit provides the AI ​​intelligent agent unit with an intent list query interface, an intent description query interface and a skill export interface. The AI ​​intelligent agent unit can obtain the list of all registered intents in the current system through the intent list query interface, realizing automatic discovery of device capabilities with zero configuration; The AI ​​intelligent agent unit can return description information corresponding to the intent based on the intent namespace identifier through the intent description query interface. The description information includes a structured description of the input parameters, a structured description of the output parameters, and semantic description text. The AI ​​agent unit can export all the intents supported by the device in a skill description format that the AI ​​agent unit can directly understand through the skill export interface, so that the preset language model can understand the device's capabilities without additional adaptation.

[0044] The polymorphic access interface unit connects to the calling module, providing kernel-mode access paths, user-mode access paths, and command-line tools. Specifically, it provides kernel-mode access paths to the AI ​​agent unit, AI native application unit, and script tool unit, enabling them to directly access the intent interface module; it provides user-mode access paths to the AI ​​native application unit for registering and invoking intent processing functions that need to retain user-mode state or call user-mode resources; and it provides command-line tools to the script tool unit, allowing debuggers and maintenance personnel to perform command-line-level intent queries, invocations, and descriptions via remote terminal access.

[0045] In the polymorphic access interface unit provided in this embodiment The kernel-mode access path controls the kernel's internal function call path system to call the intent list query interface, intent description query interface, and skill export interface to perform registration, deregistration, invocation, and query operations for intents. User-mode access paths provide programming interfaces for applications via user-mode C libraries and daemons, through Unix Domain Socket inter-process communication. Its specific working process can be as follows: 1) The application connects to the user-space language library to call its encapsulated programming interfaces such as intent invocation, intent registration, intent list query, and intent description query; 2) The user-space language library encapsulates the above interface calls according to a predetermined protocol format of fixed message header and message body, and sends them to the daemon process unit through Unix Domain Socket; 3) After receiving a message, the daemon process unit processes it according to the message type: 31) Registration messages update intent information to the global intent registry; 32) The event loop of the call class message queries the application to which the target intent belongs based on the global intent registry and forwards the request to the corresponding application; 33) Query messages are returned after directly reading the intent list or description information from the global intent registry; 4) The processing result is sent back to the user-space language library via Unix Domain Socket in the same protocol format, and then parsed by the user-space language library and returned to the application, thus completing a complete call.

[0046] It allows users to view, invoke, and query intent lists and descriptions via command-line tools (such as aii, ailist, aiiinvoke, aiidesc, etc.), facilitating debugging and manual verification.

[0047] [Second Embodiment] like Figure 2 As shown, the second embodiment of the present invention also provides a control method for an operating system with an intent interface module mentioned in the first embodiment, comprising the following steps: S100: The AI ​​agent unit sends structured intents; S200: The intent interface module selects the device that matches the structured intent based on the obtained structured intent, and outputs the execution result through the processing function corresponding to the intent; S300: Returns a structured result to the calling module.

[0048] from Figure 2 As can be seen from Table 1, compared with the traditional CLI text interaction method, the control method of the operating system with intent interface module provided by the present invention has been greatly improved in terms of operation steps, token consumption and end-to-end latency.

[0049] Table 1. Performance Comparison of the Invention Method and Traditional CLI Text Interaction Method Operating steps 8 steps 3 steps -62.5% Token consumption ~80 tokens 0 -100% End-to-end delay ~400ms ~3.2μs -99.99% It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An operating system with an intent interface module, the system comprising: The calling module is data-connected to the user-mode interface module. The calling module converts its operation to be executed into a structured intent, and initiates an intent call to the intent interface module through the user-mode interface module. When the system starts, the intent processing function is registered with the intent interface module through the user-mode interface module, and the intent processing function completes the processing when the corresponding intent is called. The user-mode interface module encapsulates interfaces for intent invocation, intent registration, intent list query, and intent description query, and provides a unified intent invocation interface to the calling module. It also performs inter-process communication and synchronizes user-mode intents to the global intent registry. The hardware driver module registers the kernel-state intent corresponding to the sensor with the intent interface module during initialization, and directly reads the hardware registers and returns structured data when called. At the same time, the hardware driver module registers the kernel-state intent corresponding to the actuator with the intent interface module during initialization, and converts the input parameters into hardware control signals to drive the actuator to act when called. And when the hardware driver module is initialized, it registers the kernel-mode intent corresponding to the communication interface with the intent interface module, and sends and receives input data through the corresponding physical bus when it is called; and registers the kernel-mode intent corresponding to the attached device with the intent interface module when the hardware driver module is initialized. Its features are: The system also includes a kernel-mode module, which is connected to both the user-mode interface module and the hardware driver module. The kernel-mode module contains an intent interface module, which in turn includes: An intent definition and description unit is connected to the global intent registry data. The intent definition and description unit defines the intent structure, determines the intent naming rules and its input and output parameters, and determines the corresponding semantic description text. A global intent registry, which uses a hash table data structure and uses intent namespace identifiers as keys; The intent routing and execution unit is connected to the global intent registry and the calling module. The intent routing and execution unit searches for the target intent in the global intent registry according to the intent call, selects the corresponding processing function according to the type of the target intent, passes the input parameters to the corresponding processing function, and returns the processing result to the calling module. The self-describing and automatic discovery unit is connected to the global intent registry data. The self-describing and automatic discovery unit provides a corresponding interface for the AI ​​intelligent agent unit. The AI ​​intelligent agent unit can obtain device information, intent information and device-supported intent information through the corresponding interface. A polymorphic access interface unit is connected to the calling module to provide the calling module with kernel-mode access paths, user-mode access paths, and command-line tools.

2. An operating system with an intent interface module according to claim 1, characterized in that: The intent structure defined by the intent definition and description unit includes namespace identifiers, structured descriptions of input parameters and output parameters, and semantic description text.

3. An operating system with an intent interface module according to claim 2, characterized in that: The namespace adopts a hierarchical dot-matrix naming rule and classifies namespace identifiers by domain or level; The structured description of the input parameters includes the parameter name, parameter type, and parameter constraints; the structured description of the output parameters includes the structure of the returned result and the meaning of the fields. The semantic description text describes the function corresponding to the intent in natural language, and the semantic description text can be recognized by the language model inside the AI ​​agent unit.

4. An operating system with an intent interface module according to claim 1, characterized in that: The global intent registry enables unified management of kernel-mode intents and user-mode intents. The kernel-mode intent is a function that is registered directly with the global intent registry by the device driver and marked in kernel mode. The kernel-mode mark indicates that the call does not need to cross the process boundary. The user-mode intent is registered with the kernel by the AI ​​native application unit through the character device interface and input / output control system provided by the kernel, and is marked as user-mode. The user-mode mark indicates that an inter-process communication is required when calling it.

5. An operating system with an intent interface module according to claim 4, characterized in that: The kernel-mode intents and user-mode intents use a unified data structure in the global intent registry, and the calling module does not distinguish between kernel-mode intents and user-mode intents.

6. An operating system with an intent interface module according to claim 1, characterized in that: In the intent routing and execution unit When the target intent is a kernel-mode intent, the kernel-mode processing function corresponding to that intent is called directly in kernel mode. The kernel-mode processing function works by the following steps: After the intent routing and execution unit matches the corresponding intent in the global intent registry according to the intent namespace identifier, it directly passes the input parameters to the kernel-mode processing function by function pointer call. The kernel-mode processing function reads or writes device registers or accesses kernel data, fills the processing result into the output parameters, and returns. When the target intent is a user-space intent, the user-space process that registered the intent is woken up through the semaphore mechanism, the input parameters are passed to the user-space processing function, and the processing result is returned to the calling module after the processing is completed. The working process of the user-mode processing function includes the following steps: when the intent is called, the process where it is located is woken up from the suspended state by the semaphore mechanism, the input parameters are read from the shared buffer and the business logic is executed, the processing result is written to the shared buffer and the kernel is notified, and then the kernel returns the processing result to the calling module.

7. An operating system with an intent interface module according to claim 6, characterized in that: The intent routing and execution unit can select either synchronous or asynchronous call mode as needed when making intent invocations; wherein, The synchronous call mode blocks and waits for the result to return; it includes the following steps: 1) The caller intends to invoke the interface; 2) The intent routing and execution unit completes intent lookup, execution, and forwarding in kernel mode; 3) The calling process is suspended on the result semaphore; 4) After the intent processing function completes, the resulting semaphore is released; 5) The calling process is awakened and retrieves the result data; The asynchronous call mode returns a ticket identifier, and the calling module obtains the execution result through polling or a result waiting interface; wherein... The calling module obtains the execution result through polling, including the following steps: 1) After the asynchronous call interface returns a ticket identifier, the calling module periodically calls the polling interface with that ticket as a parameter; 2) The intent routing and execution unit looks up the internal status table based on the ticket. If the intent processing function has not yet been completed, it immediately returns to the unready state. If it has been completed, it returns the result data along with the ready state to the caller. The calling module obtains the execution result through the waiting result interface, which includes the following steps: 1) The calling module calls the waiting-for-result interface with the ticket as a parameter; 2) After the intent routing and execution unit finds the corresponding result semaphore based on the ticket, it suspends the calling process on that semaphore; 3) When the intent processing function completes, it wakes up the caller by releasing a semaphore and returns the result.

8. An operating system with an intent interface module according to claim 1, characterized in that: The self-describing and automatic discovery unit provides the AI ​​agent unit with an intent list query interface, an intent description query interface, and a skill export interface. The AI ​​agent unit can obtain a list of all registered intents in the current system through the intent list query interface; The AI ​​agent unit can return description information corresponding to the intent based on the intent namespace identifier through the intent description query interface. The description information includes a structured description of the input parameters, a structured description of the output parameters, and semantic description text. The AI ​​agent unit can export all the intents supported by the device in a skill description format that the AI ​​agent unit can directly understand through the skill export interface.

9. An operating system with an intent interface module according to claim 8, characterized in that: In the polymorphic access interface unit The kernel-mode access path controls the kernel's internal function call path system to call the intent list query interface, intent description query interface, and skill export interface to perform registration, deregistration, invocation, and query operations for intents. The user-mode access path provides a programming interface for applications through the user-mode language library and daemon process via inter-process communication; The command-line tool allows users to view, invoke, and query intent lists.

10. A control method for an operating system with an intent interface module according to any one of claims 1-9, characterized in that: Includes the following steps: S100: The AI ​​agent unit sends structured intents; S200: The intent interface module selects the device that matches the structured intent based on the obtained structured intent, and outputs the execution result through the processing function corresponding to the intent; S300: Returns a structured result to the calling module.

Images