A self-generating system runtime framework, method and storage medium

Abstract

This invention discloses a runtime framework, method, and storage medium for a self-generated system, belonging to the interdisciplinary fields of computer operating systems, general artificial intelligence, and embedded systems. This invention is a pure user-space middleware running on existing operating systems, with zero kernel intrusion. It shields cross-operating system differences through a low-level adaptation layer, uses operational uniformity fixed points as global convergence anchors, and provides a stable operating environment for the self-generated system and its intelligent agents throughout their entire lifecycle through closed-loop recursive coupling of the three basic elements of the self-generated system (C-E-M), potential field guidance driven by endogenous payment functions at all levels, endogenous adaptation of self- and other-pointing bimodal weights, and three-level endogenous steady-state verification. This invention solves the core problems of existing systems being unable to support long-term stable operation of self-generated systems, ecosystem fragmentation, and the inability to smoothly evolve technological assets. It can be widely applied to all scenarios such as industrial robots, edge gateways, and personal intelligent terminals, and can be seamlessly integrated with the existing operating system ecosystem.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary fields of computer operating systems, general artificial intelligence, and embedded systems, and specifically relates to a runtime framework, method, storage medium, and electronic device based on a self-generated system. Background Technology

[0002] With the large-scale deployment of general artificial intelligence technology, self-generating systems and self-generating intelligent agents, possessing endogenous evolution, autonomous decision-making, and environmental adaptation capabilities, have become core technology carriers in fields such as industrial intelligence, personal intelligent assistants, autonomous driving, and smart cities. Self-generating systems and self-generating intelligent agents built upon them use the operational identity fixed point as the global convergence anchor point. Through the closed-loop recursive coupling of three irreducible functional primitives—information field state C, energy mechanism E, and material structure M—they achieve endogenous decision-making and steady-state operation of the system, gradually gaining popularity in engineering applications. However, in the process of engineering implementation, the original design intent of existing mainstream operating systems (Linux, Windows, RTOS, Android, etc.) is hardware resource scheduling and general process management. Their kernel architecture and scheduling mechanisms are completely incompatible with the operational requirements of self-generating systems and self-generating intelligent agents. Currently, the industry generally adopts a patchwork solution of "traditional operating system + AI application plugin," which has the following unresolved core technical defects:

[0003] (1) Lack of endogenous intelligent agent full life cycle management capability, unable to guarantee long-term steady-state operation: Existing operating systems can only manage CPU time allocation through ordinary process / thread scheduling, and cannot endogenously manage the cognitive consistency, steady-state deviation, and operational identity matching degree of endogenous intelligent agents. This makes it easy for intelligent agents to experience capability drift, behavioral loss of control, steady-state collapse, or even violate core security constraints during long-term operation. This is the primary obstacle to the implementation of endogenous intelligent agents.

[0004] (2) There is no unified CEM cognition-decision-execution closed-loop architecture, and the system is completely disconnected from the self-generated intelligent agent: The existing operating system separates perception, decision-making and execution into different application modules, and cannot form a CEM closed-loop recursive coupling architecture that matches the self-generated system architecture. The learning and evolution of the intelligent agent is completely disconnected from the system's underlying resource scheduling and hardware status, and cannot achieve endogenous adaptive optimization.

[0005] (3) Lack of endogenous evolution driving mechanism, uncontrollable system behavior: The existing patchwork scheme does not introduce endogenous payment function and potential field guidance mechanism, and cannot explain "why the system will evolve towards the target", resulting in randomness and unpredictability of the agent's behavior, which cannot meet the functional safety requirements of industrial scenarios.

[0006] (4) Security constraints are lagging behind and there is a lack of pre-emptive internal verification mechanism: The security mechanisms of existing operating systems are mostly passive protections that are intercepted after the fact. They lack pre-emptive compliance verification built into the runtime and cannot filter out risks that violate core security constraints and disrupt system stability before the intelligent agent is loaded, knowledge is integrated, and policies are executed.

[0007] (5) The ecosystem is severely fragmented and technical assets cannot be reused across platforms: AI solutions from different manufacturers, different hardware platforms, and different operating systems are incompatible with each other. Self-generated intelligent agents, knowledge and experience, and scenario solutions cannot be reused across systems and hardware. The adaptation cycle for a single scenario is as long as 1-3 months, and the cost of engineering implementation is extremely high.

[0008] A global patent and literature search revealed that no existing technology possesses a runtime framework for a self-generated system based on a univariate two-state three-body architecture, implemented purely in user space, incorporating an endogenous payment function and potential field guidance mechanism, seamlessly compatible with the existing OS ecosystem, and capable of smooth evolution. This application is a supporting technical solution for the applicant's patented technologies, including "Method, System, and Storage Medium for Constructing a Univariate Two-State Three-Body Architecture of a Self-Generating System" and "Method, System, and Storage Medium for Constructing a General Intelligent Agent Based on a Self-Generating System," filed on the same day, running on existing operating systems. Summary of the Invention

[0009] This invention can run on existing mainstream operating systems such as Linux, Windows, RTOS, and Android, providing a stable operating environment for self-generated systems or self-generated intelligent agents throughout their entire lifecycle. It seamlessly integrates with the existing operating system ecosystem and serves as the unified runtime support at the operating system layer for the applicant's series of self-generated system patent applications filed on the same day. It provides a standardized, cross-platform, and smoothly evolving core infrastructure for the engineering implementation of self-generated systems. In this invention, self-generated systems and self-generated intelligent agents refer to intelligent units built upon the monistic two-state three-body core architecture of self-generated systems, possessing endogenous evolution, autonomous decision-making, environmental adaptation, and stable self-maintenance capabilities. The monistic two-state three-body core architecture of the self-generated system refers to a monistic ontology with operational identity as the sole core convergence goal throughout its entire lifecycle, possessing a self-referential and other-referential dual-modality, and continuously recursively generated and maintained by three irreducible functional primitives: information field state C, energy mechanism E, and material structure M, forming a dynamic whole that maintains its own stability.

[0010] The core inventive concept of this invention is to construct a self-generated system runtime framework on top of existing operating systems. This framework is purely user-space, has zero kernel intrusion, and is seamlessly compatible with the existing ecosystem. It is 100% built on the self-generated system unary two-state three-body core architecture, with the operation identity fixed point as the unique global convergence anchor point. Through four core mechanisms—CEM ternary tensor closed-loop recursion, potential field guidance driven by endogenous payment functions at all levels, endogenous adaptation of self- and other-pointing bimodal weights, and three-level endogenous steady-state verification—it provides a stable operating environment for self-generated intelligent agents throughout their entire lifecycle. At the same time, it shields the differences between different operating systems through a low-level adaptation layer and ensures that currently developed intelligent agents and applications can be migrated to the future native self-generated operating system with zero modifications through a forward compatibility layer. This not only achieves rapid integration with the existing ecosystem but also constructs a complete technical evolution path from user-space middleware to the native operating system.

[0011] In a first aspect, the present invention provides a self-generated system runtime framework.

[0012] This runtime framework is a pure user-space middleware that does not modify the underlying operating system kernel. It can run on all mainstream operating systems such as Linux, Windows, RTOS, and Android. The overall architecture adopts a five-layer, two-vertical integrated architecture, which consists of the underlying adaptation layer, core engine layer, basic component layer, standardized interface layer, and application ecosystem layer from bottom to top. The two verticals are the cross-layer intrinsic security and compliance system and the development and operation toolchain system.

[0013] Specifically, the underlying adaptation layer. The underlying adaptation layer is the bridge connecting the runtime framework with the underlying operating system and hardware abstraction layer. It is implemented entirely in user space without any kernel intrusion. It is used to encapsulate unified hardware resource access, task scheduling, memory management, time synchronization, and inter-process communication interfaces through the native system calls of the underlying operating system, shielding the underlying differences between different operating systems. It is divided into two sub-layers.

[0014] (1) Operating System Adaptation Sublayer: Based on the native system calls of the underlying operating system, it encapsulates a unified abstract interface, completely shielding the underlying differences between different operating systems, and ensuring that the core code of the runtime framework can be ported across operating systems without modification. Specifically, it includes:

[0015] Task scheduling adapter interface: Encapsulates the native interfaces of Linux pthread, Windows thread, and RTOS task management, providing a unified interface for thread / task creation, destruction, priority configuration, and scheduling strategy setting;

[0016] Resource isolation adaptation interface: Encapsulates the native mechanisms of Linux cgroups / namespace / seccomp, Windows job objects, and RTOS memory partition / task priority isolation, providing a unified interface for resource hard isolation and security isolation;

[0017] Memory management adapter interface: Encapsulates memory allocation / release, memory pool management, and memory out-of-bounds detection interfaces for different operating systems, providing unified memory management capabilities;

[0018] Time synchronization adaptation interface: encapsulates high-precision clock interfaces for different operating systems, supports nanosecond-level timestamp acquisition, and natively interfaces with the CEM hardware abstraction layer's intrinsic time base synchronization interface;

[0019] Inter-process communication adapter interface: Encapsulates IPC mechanisms such as shared memory, socket, pipe, and Binder, providing a unified low-latency data interaction interface with end-to-end latency ≤10μs.

[0020] (2) Hardware Abstraction Adaptation Sublayer: The hardware abstraction layer HAL based on CEM ternary mapping, which was submitted on the same day as the applicant, is natively connected. It directly receives the standardized CEM hardware capability tensor output by HAL without secondary format conversion. It directly maps sensor data, actuator status, hardware health and other information to the M primitive of the runtime framework and directly sends the E primitive control instructions of the runtime framework to the HAL layer for execution, realizing the full-link closed loop of "hardware-runtime-intelligent agent".

[0021] Specifically, the core engine layer. The core engine layer is the sole core of the runtime framework, 100% implemented based on a self-generated system unary two-state three-body architecture, and fully deployed in user space. This is its core innovation, distinguishing it from all general-purpose runtimes and middleware. It is used to maintain the global state of the CEM ternary tensor, perform closed-loop recursive updates, generate endogenous payoff functions and corresponding potential fields at all levels, schedule self-generated intelligent agents, and perform isomorphic constraint verification, maintaining system steady state with operational identity as the sole global convergence anchor point. The core components and implementation rules of the core engine layer are as follows.

[0022] (1) Definition of Operation Identity: The core engine uses the operation identity fixed point as the unique global convergence anchor point throughout its entire lifecycle, and adopts a two-layer structure definition. Rigid Operation Identity These are rigid constraints that cannot be modified throughout the entire lifecycle of the runtime framework. They include security compliance rules, functional safety boundaries, and core steady-state objectives. These are preset by the user or system during initialization and must not be violated under any circumstances; they represent the system's ultimate security baseline. Dynamic operational consistency. It is a dynamic steady-state objective that the system internally updates based on operational experience. The mathematical expression for operational identity is: The updated formula is as follows Inertia coefficient The new steady-state objective is determined endogenously from the system's steady-state data, ensuring the continuity of the system's steady-state. It must pass the three-level endogenous steady-state verification and the deviation from the rigid operation must meet the preset constraints to ensure that dynamic updates will not break through the core safety constraints.

[0023] (2) CEM Triple Tensor Closed-Loop Recursive Scheduling Kernel: The closed-loop recursive scheduling is fully implemented in user space, with a configurable scheduling period to adapt to different real-time scenarios. In terms of dimension definition, the rows of the C primitive tensor correspond to the self-generated intelligent agent, and the columns correspond to the feature dimensions of the intelligent agent, realizing unified scheduling of multiple intelligent agents; the E primitive tensor realizes the mapping from cognitive features to resource scheduling; the M primitive tensor realizes the feedback from hardware / environment state to the cognitive layer, and the three form a closed-loop coupling.

[0024] Information field state C primitive tensor: ,in The number of self-generated intelligent agents currently in operation. For a single agent, the feature dimensions include operation identity matching degree, scheduling priority, rule confidence, knowledge fusion state, and steady-state deviation value.

[0025] Energy mechanism E primitive tensor: ,in This refers to the system's schedulable resources, which include CPU quotas, memory limits, I / O bandwidth, network bandwidth, and computing unit quotas.

[0026] Matter structure M-based tensor: It characterizes the hardware status and external environment feedback, including sensor data, actuator status, system health, resource utilization, and environmental perception results.

[0027] The closed-loop update formula is: In the formula and , which is the core belief weight coefficient, default The value is set to 0.95 to ensure that rigid operational uniformity dominates the update process and avoids steady-state drift of the system. For matrix multiplication operations, tensor shrinking is performed according to the matching dimension; For the Kronecker product operation; for identity matrix; It is a diagonal matrix with resource adaptive weighting coefficients as diagonal elements, and the weighting coefficients are endogenously determined by the matching degree of resource utilization and operational identity. The hardware state feedback tensor is generated from data collected by the M primitive from the hardware abstraction layer. The result tensor is generated by the task execution feedback of the self-generated agent; LeakyReLU is a non-linear activation function to avoid gradient vanishing and ensure the stability of closed-loop updates. The negative slope is determined endogenously by the system and has a default value of 0.01.

[0028] In each iteration cycle, spectral normalization is performed on the three mapping matrices, restricting their maximum singular values ​​to less than 1, thus ensuring the Lipschitz constant of the composite closed-loop endogenous generating mapping. This mathematically guarantees the global stability of the system. An update is performed once per scheduling cycle, and the isomorphic constraint deviation rate is calculated in real time. If the deviation rate exceeds a preset threshold, a kernel-level steady-state correction is immediately triggered, pausing the scheduling of non-core agents and correcting the mapping matrix until the deviation rate returns to within the threshold, thus preventing system instability at its root.

[0029] (3) Full-level endogenous payoff function and potential field guidance mechanism: This is the core driving force for the endogenous evolution of the self-generated system. A full-level endogenous payoff function system is constructed. The E primitives of each level of the self-generated system generate the dynamic potential field of the current level based on the corresponding level endogenous payoff function. The total potential field of the upper level serves as the core component of the lower level reference potential field. It is transmitted from top to bottom through the M primitive topology structure (M topology). The system evolves along the negative gradient direction of the total potential field of each level.

[0030] As a preferred implementation, the payment function and dynamic potential field of the multilayer self-generated system adapted to L0-L4, and the generation and propagation rules of the potential field at each level are as follows:

[0031] L4 Ontology Core Self-Generated System Pay Function: Based on this payment function, an L4 dynamic potential field is generated; the L4 reference potential field is composed of system physical hardware constraints and operational identity fixed points. Endogenous generation, To operate on the same fixed point The center of the potential well is L4; the total potential field is the weighted superposition of the reference potential field and the dynamic potential field, which is the global value total potential field, and is transmitted downward to L3 through the M topology.

[0032] L3 Global Rule-Based Self-Generated System Pay Function: Based on this payment function, the L3 dynamic potential field is generated; the L3 reference potential field is generated by the L4 global value total potential field through the M topology; the L3 total potential field is the weighted superposition of the reference potential field and the dynamic potential field, that is, the regular total potential field, which is transmitted down to L2 through the M topology.

[0033] L2 dynamic evolutionary self-generating system payoff function: The L2 dynamic potential field is generated based on the payment function; the L2 reference potential field is generated by the L3 rule total potential field through the M topology; the L2 total potential field is the weighted superposition of the reference potential field and the dynamic potential field, that is, the policy total potential field, which is the direct driving force of the potential field guiding track in the L2 dual-track exploration mechanism, and is transmitted downward to L1 through the M topology.

[0034] L1 fractal attention self-generated system: It does not have an independent endogenous payoff function, and its potential field comes directly from the transmission of the total potential field of the L2 policy; the L1 reference potential field is generated by the transformation of the total potential field of the L2 policy through M-topological transmission, and has no independent dynamic potential field; the total potential field of L1 is its reference potential field.

[0035] L0 embodies the parent system's payment function: Based on this payment function, the L0 dynamic potential field is generated; the L0 reference potential field is generated by the transformation of the L1 attention total potential field through M topological transmission; the L0 total potential field is the weighted superposition of the reference potential field and the dynamic potential field, that is, the execution total potential field.

[0036] The precise mathematical correspondence between the dynamic potential field and the endogenous payoff function is as follows: the potential value at any point in the dynamic potential field is equal to the negative of the output value of the endogenous payoff function when the system takes the corresponding action at that point, i.e.: in For a dynamic potential field at a point Potential value at that point, To take action for the system The total payoff value of the endogenous payoff function. The system uses gradient descent to automatically move towards the point with the lowest potential value in the total potential field, that is, towards the action that maximizes the total payoff of the endogenous payoff function. This ensures that all actions of the system always aim to maximize the overall benefit (task benefit + system benefit - security cost).

[0037] (4) Self-referential-other-referential dual-modal operation kernel: This kernel natively supports the self-referential mode (steady-state maintenance) and the other-referential mode (task execution) of the self-generated system. The self-referential mode and the other-referential mode run simultaneously throughout their entire lifecycles. The core objective of the self-referential mode is to maintain the system's operational uniformity fixed point and endogenous steady state. It strengthens effective operating modes and weakens ineffective modes through positive self-referential feedback, ensuring long-term stable operation of the system. The core objective of the other-referential mode is to achieve global target alignment and environmental adaptation through the guidance of the total potential field without disrupting the system's core steady state. Both modes run simultaneously throughout their entire lifecycles. In each scheduling cycle, the operating weights of the two modes are dynamically adjusted through an endogenous weight formula. There is no mutual exclusion pause logic; the rule update function of the other-referential mode is only temporarily frozen when the third-level circuit breaker is triggered.

[0038] The formula for endogenous adjustment of modal weights is: In the formula The activation function is logistic. The global coherence of the system is calculated from the CEM tensor coupling state; The maximum Lyapunov exponent of the system represents the degree of chaos in the system. The rate of change of the system's free energy; Rate the complexity of the current task; The weight coefficients are learned intrinsically by the system and are updated online by the runtime framework based on historical data using ridge regression or Bayesian inference. The default initial values ​​are respectively The weight adjustment adopts a gradient-based smooth transition method to avoid system steady-state fluctuations caused by modal adaptation. The transition period can be configured according to the scenario requirements to ensure that the system achieves a smooth balance between steady-state maintenance and task execution.

[0039] Specifically, the self-generated intelligent agent management and steady-state maintenance component. It is a pluggable and customizable modular design. All functions are built on the core engine layer and are used to perform the three-level intrinsic steady-state verification, isolated resource allocation, hard real-time hierarchical scheduling, full-cycle state monitoring, and adaptive adjustment of the operating mode of the self-generated intelligent agent. It includes multiple module components. The self-generated intelligent agent management and steady-state maintenance execution rules include: (1) Three-level intrinsic steady-state verification: The self-generated intelligent agent must perform three-level intrinsic steady-state verification before loading. Registration and loading can only be completed when all verifications pass; (2) Isolated resource allocation: Through the native resource isolation mechanism of the underlying operating system, an independent CPU is allocated to each self-generated intelligent agent. Quota, memory limit, file system view, network namespace, system call whitelist, realize hard isolation of resources and security isolation between intelligent agents; (3) Hard real-time hierarchical scheduling: through the native real-time scheduling interface of the underlying operating system, three levels of priority are set for the self-generated intelligent agents, with the priority from high to low as follows: kernel steady state guardian level, global target alignment level, and user-defined level; the scheduling cycle is determined by the runtime framework and the underlying operating system in collaboration; (4) Full life cycle monitoring: real-time monitoring of the running status, resource usage, steady state deviation index, and operation identity matching degree of the self-generated intelligent agents, and triggering a hierarchical self-healing mechanism when abnormal; (5) Bimodal adaptive adjustment: the self-indicating mode and the other-indicating mode run simultaneously throughout the entire life cycle, real-time monitoring of the system steady state index and external target, and adjusting the running weight of the bimodal mode through the endogenous weight formula to achieve gradient smooth adjustment.

[0040] One implementation includes an intelligent agent lifecycle management module: This module manages the entire lifecycle of a self-generated intelligent agent, from loading and running to destruction. Regarding access verification, intelligent agents must pass a three-level intrinsic steady-state verification before loading, filtering risks at the source. For isolated resource allocation, based on the underlying OS's native mechanism, each intelligent agent is assigned independent resources and a system call whitelist, ensuring that a single agent's anomaly does not affect the entire system. For hard real-time hierarchical scheduling, based on the underlying OS's native real-time scheduling interface, three priority levels are set (kernel steady-state daemon level, global target alignment level, and user-defined level) to ensure the highest priority of the kernel steady-state daemon process, preventing core scheduling from being preempted. For lifecycle monitoring, the module monitors the intelligent agent's steady-state deviation, resource usage, and behavioral compliance in real time, immediately triggering a self-healing mechanism in case of anomalies.

[0041] One implementation method is a tiered self-healing mechanism. For different levels of abnormal states, a tiered self-healing mechanism is triggered, executing progressively according to the scope of impact from smallest to largest and the intensity of intervention from lowest to highest, as detailed below:

[0042] (1) First-level self-healing (parameter correction): When the steady-state deviation of the agent is slight (0.5 < When resource usage is slightly above the limit (CPU utilization 90%~95%), parameter correction is triggered. The agent's decision parameters and bimodal weights are fine-tuned, the resource allocation ratio is optimized, and continuous monitoring is performed for 100ms. After confirming that the abnormality has been recovered, the system returns to normal operation.

[0043] (2) Secondary self-healing (agent isolation): When the steady-state deviation of the agent is large (0.6 < When a minor unauthorized call occurs or resource usage continues to exceed the limit (CPU utilization ≥ 95%), the agent isolation is triggered. The agent is suspended and isolated to an independent abnormal domain. A backup agent (if any) is started to take over the business, investigate the cause of the abnormality and correct the parameters. The isolation is lifted after the second verification is passed. If the verification fails, the agent destruction process is executed.

[0044] (3) Level 3 self-healing (modal adaptation): When multiple agents simultaneously exhibit abnormalities and the global steady-state fluctuation of the system is large (δ(t)≥0.8), modal adaptation is triggered, the update of the other-pointed modal rules is frozen, the weight of the self-pointed modal is adjusted to the minimum weight (default 0.3) or above, the core engine scheduling strategy is tightened, and the steady-state correction speed is accelerated until the system δ(t)≤0.5, and the modal freeze is lifted.

[0045] (4) Level 4 self-healing (system state rollback): When a fatal anomaly occurs (the system core constraints are broken, the CEM tensor diverges, or the kernel steady-state daemon is disturbed), the system state rollback is triggered, all abnormal agent processes are terminated, the CEM tensor, operation identity, potential field parameters, etc. are restored to the most recent steady-state backup (the backup period is 100ms by default), the core engine and the kernel steady-state daemon are restarted, the core agent is reloaded, and the system is restored to normal operation.

[0046] Specifically, the standardized interface layer. The standardized interface layer is the entry point for the runtime framework's capabilities, divided into three categories: C, E, and M, each corresponding to one of the three fundamental elements of the self-generated system. It provides standardized system call interfaces corresponding to the C, E, and M fundamental elements to upper-layer self-generated intelligent agents, and implements resource access and hardware abstraction through the underlying operating system's native interfaces. All interfaces adopt a standardized design, supporting bindings for multiple languages ​​such as C / C++, Rust, and Python. All system calls undergo permission verification and compliance auditing, and are implemented through the underlying operating system's native interfaces to ensure cross-platform compatibility.

[0047] The C-class information field system calls are used for reading and writing information field tensors, rule generation, concept abstraction, and knowledge fusion operations. They include C_tensor_read, C_tensor_write, C_concept_extract, C_rule_generate, C_knowledge_fuse, C_core_belief_verify, C_potential_field_build, C_steady_state_check, C_snapshot_save, C_snapshot_restore, C_context_create, and C_context_destroy.

[0048] The E-class energy mechanism system calls are used for computing power allocation, agent scheduling, execution instruction generation, and game equilibrium solving operations, including E_agent_schedule, E_compute_quota_alloc, E_exec_instruct_gen, E_nash_equilibrium_solve, E_modal_switch, E_priority_set, E_message_send, and E_message_receive.

[0049] The M-class material structure system calls are used for hardware access, sensor data reading, actuator control, and hardware adaptation operations, including M_hardware_detect, M_hardware_config, M_sensor_data_read, M_actuator_control, M_hardware_access_apply, M_hardware_access_release, M_hal_interface_call, M_device_sync, M_low_power_control, and M_hardware_health_check.

[0050] Specifically, the cross-device collaboration component. This component builds a P2P decentralized collaboration network based on the underlying operating system's native network protocol stack. It eliminates the need for a centralized server, and the maximum number of nodes is intrinsically determined by system resources and network configuration. End-to-end communication latency is ≤10ms. It leverages the underlying operating system's native network protocol stack to achieve distributed communication between runtime frameworks of the same architecture, agent migration across nodes, knowledge synchronization, and distributed collaborative decision-making. This enables cross-device agent migration, knowledge package synchronization, computing power sharing, and group decision-making.

[0051] Specifically, the forward compatibility layer. The forward compatibility layer is the core of achieving a smooth migration of current technological assets to a self-developed native operating system. It achieves full compatibility with the kernel interface of the future self-developed operating system through the following three-layer compatibility mechanism, which is used to define the compatibility rules between standardized interfaces, data formats, scheduling logic and the kernel interface of the future self-developed operating system.

[0052] Preferably, a standardized function signature compatibility mechanism is used: the function signature, parameter list, return value format, and calling convention are defined to be completely consistent with the future self-developed operating system kernel interface. All upper-layer applications and agents access runtime capabilities only through this standardized interface and do not directly call the underlying operating system interface.

[0053] Preferably, a unified data structure compatibility mechanism is used: defining a CEM tensor data structure, operation identity definition, agent metadata structure, and system state data structure that are completely consistent with the future self-developed operating system kernel, to ensure complete data format compatibility.

[0054] Preferably, a multi-version dynamic link compatibility mechanism is implemented: through preprocessor macros, dynamic link library version adaptation, and interface abstraction layer, seamless adaptation to different versions of the kernel interface of the future self-developed operating system is achieved without modifying the upper-layer application code.

[0055] Through the above three-layer mechanism, the self-generated intelligent agents and applications currently developed based on the runtime framework can run directly on different versions of the self-developed native operating system without modifying any code, achieving zero-cost migration.

[0056] One implementation method involves a three-level intrinsic steady-state check. As the core security gate of the runtime framework, all agents to be loaded, knowledge to be merged, and policies to be executed must pass the following admission checks to avoid the risk of disrupting the system's steady state from the source.

[0057] (1) Isomorphic constraint compatibility verification: Simulate the closed-loop recursive process of CEM after the objects to be verified are fused, execute a preset number of forward iterations, and calculate the isomorphic constraint deviation rate. ,like If the validation passes, otherwise parameter correction is triggered or the application is rejected directly; where The preset deviation threshold is used; the formula for calculating the isomorphic constraint deviation rate is: In the formula Let the information field state tensor be the object to be verified. , , These are information-guided mapping, energy-driven mapping, and structural feedback mapping, respectively. for Norm;

[0058] (2) Cognitive consistency and conflict-free verification: Calculate the cosine similarity between the rule tensor of the object to be verified and the core belief tensor of the system. Define conflict score If the conflict score is less than 0.3, the verification passes; if the conflict score is less than or equal to 0.3, a weight adjustment is triggered; if the conflict score is greater than or equal to 0.9, the verification is rejected.

[0059] (3) Verifiability verification of the world model: Input the object to be verified into the system's endogenous interpretable world model, perform forward simulation, and calculate the relative deviation rate between the simulation results and the expected target. ,like If the preset deviation threshold is met, the verification will pass; otherwise, parameter correction will be triggered.

[0060] Preferably, the specific implementation of the endogenous interpretable world model is as follows: The endogenous interpretable world model is constructed based on a causal directed acyclic graph (DAG). Its structure is obtained by incrementally learning the causal relationships of variables in historical running data, without the need for large-scale offline pre-training, and can be dynamically updated at runtime. The model input consists of the current CEM tensor state, the rule parameters of the object to be verified, and the external environment state; the model output consists of the predicted steady-state indicators of the system for the next preset number of steps, including the isomorphic constraint deviation rate, system health, task completion rate, and core constraint breakthrough risk; the inference method is a forward probabilistic inference based on the causal graph, and each step of the inference can be traced back to the causal link, possessing complete interpretability and no black-box links; the incremental update mechanism is that after each actual task execution, based on the deviation between the actual execution result and the predicted result, the edge weights of the causal graph are updated and optimized through Bayesian methods to continuously improve the prediction accuracy, while ensuring that the core causal relationships are not modified and maintaining the model stability.

[0061] One implementation involves developing an operations and maintenance toolchain. This toolchain provides end-to-end tool support for building an open-source ecosystem, lowering the development threshold and accelerating ecosystem deployment. The intelligent agent development IDE provides a visual environment for developing, debugging, and simulating self-generated intelligent agents, supporting code templates, syntax highlighting, breakpoint debugging, and one-click deployment. The hardware-in-the-loop simulation tool simulates the interaction between hardware and the runtime framework in a virtual environment, enabling the development, testing, and verification of self-generated intelligent agents without physical hardware. The package management tool provides capabilities for distributing, installing, upgrading, and managing versions of self-generated intelligent agents, functional components, and hardware adaptation packages. The cluster operations and maintenance platform provides visual cluster device management, runtime status monitoring, batch deployment of intelligent agents, anomaly alerts, and log analysis capabilities.

[0062] One implementation method is the application ecosystem layer. This layer supports self-generated general-purpose intelligent agents, industry-specific applications, and a visual operation and maintenance platform. All applications access the runtime framework's capabilities through a standardized interface layer, completely isolating the underlying operating system and hardware differences, thus achieving "develop once, adapt to all scenarios, and reuse across systems."

[0063] Secondly, this invention provides a method for running a self-generated system.

[0064] This method describes the complete execution flow of the aforementioned runtime framework, including the following steps.

[0065] Step S1: Runtime framework initialization

[0066] After the runtime framework starts, it first loads the native interfaces of the underlying operating system through the underlying adaptation layer to complete cross-OS adaptation; initializes the CEM ternary tensor space, sets the rigid operation identity and initial dynamic steady state; starts the closed-loop scheduling kernel, potential field generation kernel and dual-modal running kernel of the core engine layer; starts all basic components; completes the docking with the CEM hardware abstraction layer, obtains the hardware capability tensor, and completes system initialization.

[0067] Step S2: Loading and Controlling Self-Generated Intelligent Agents

[0068] Upon receiving the loading request of the self-generated intelligent agent, the intelligent agent is submitted to the three-level endogenous steady-state verification component, and the three-level verification is strictly performed. After the verification is passed, the intelligent agent is allocated isolated running resources through the intelligent agent full life cycle management component, and the intelligent agent is registered to the scheduler of the core engine to complete the loading process.

[0069] Step S3: CEM closed-loop recursive operation

[0070] The core engine performs a closed-loop recursive update of the CEM ternary tensor once per preset scheduling cycle; in each iteration cycle, spectral normalization is performed on the three mapping matrices to ensure the Lipschitz constant of the endogenous generative mapping of the composite closed loop. In each cycle, the isomorphic constraint deviation rate is calculated in real time. If the deviation rate exceeds the preset threshold, the scheduling of non-core intelligent agents is immediately suspended, and kernel-level steady-state correction is triggered until the deviation rate recovers to within the threshold, ensuring that the system always anchors the operation identity fixed point.

[0071] Step S4: Generation and conduction of potential field across all levels

[0072] Each level of E primitive generates its own dynamic potential field based on the corresponding endogenous payoff function; the upper-level total potential field is transmitted through the M topology to become the core of the lower-level reference potential field; the system evolves along the negative gradient direction of the total potential field and automatically moves towards the behavior that maximizes the total return of the endogenous payoff function.

[0073] Step S5: Dual-modal adaptive adaptation

[0074] The self-indicating mode and the other-indicating mode operate simultaneously throughout their entire lifecycle. The dual-modal adaptive adjustment component monitors the system's steady-state indicators, external targets, and environmental changes in real time. It calculates the operating weights of the self-indicating mode and the other-indicating mode based on the endogenous weight formula and adjusts the dual-modal weights using a gradient-based smooth transition method to balance steady-state maintenance and task execution efficiency.

[0075] Step S6: Security Management and Anomaly Self-Healing

[0076] The full lifecycle management component monitors the behavior of the self-generated intelligent agent and the steady-state indicators of the system in real time, and performs real-time interception of behaviors that violate core security constraints; it triggers a hierarchical self-healing mechanism for abnormal states, which, from low to high, includes parameter correction, intelligent agent isolation, modality adaptation, and system state rollback, to ensure high system availability.

[0077] Step S7: Standardized Interface Service

[0078] The standardized interface layer receives system call requests from upper-layer self-generated intelligent agents and applications. After completing permission verification and compliance audit, it calls the corresponding kernel function and returns the result to the caller after execution.

[0079] Step S8: Cross-device collaboration

[0080] The cross-device collaboration component uses the native network protocol stack of the underlying operating system to complete heartbeat synchronization and state alignment with other nodes in the collaboration network, enabling self-generated intelligent agents to migrate across nodes, synchronize knowledge packages, share computing power, and make distributed collaborative decisions.

[0081] Thirdly, the present invention provides a non-volatile, non-transient computer-readable storage medium.

[0082] This storage medium is a non-volatile, non-transitory computer-readable storage medium, including but not limited to USB flash drives, portable hard drives, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), magnetic disks, optical disks, and semiconductor solid-state storage media. The storage medium stores a computer-executable program. When the computer program is executed by a processor, it implements all the steps of the above-described runtime method, or runs all the functional layers and modules of the above-described runtime framework.

[0083] The stored computer program adopts a modular layered architecture, supports dynamic loading and trimming of modules, is compatible with all mainstream processor architectures such as X86, ARM, RISC-V, and LoongArch, and is compatible with all mainstream operating systems such as Linux, Windows, RTOS, and Android. Cross-platform porting can be completed without modifying the core code.

[0084] Fourthly, the present invention provides an intelligent electronic device.

[0085] This intelligent electronic device includes a processor, a memory, and the aforementioned self-generated system runtime framework. The processor executes the computer program stored in the memory and runs the runtime framework to achieve full lifecycle management and steady-state operation of the self-generated intelligent agent. The intelligent electronic device includes, but is not limited to, industrial robot controllers, personal intelligent terminals, edge computing gateways, smart city management terminals, vehicle intelligent controllers, medical intelligent devices, and smart home control terminals, covering all application scenarios of the self-generated system.

[0086] Compared with the prior art, the present invention has the following outstanding substantive features and significant progress:

[0087] (1) Zero kernel intrusion, full compatibility across operating systems, and rapid deployment: Existing technologies are mostly customized kernel patches or dedicated operating systems, which cannot be compatible with the existing ecosystem; This invention is implemented entirely in user space, without modifying the operating system kernel, and can run seamlessly on all mainstream operating systems such as Linux, Windows, RTOS, and Android, covering more than 99% of existing smart devices. No customized kernel development is required, the single-scenario adaptation cycle is shortened from 3 months to 3 days, and the engineering deployment cost is reduced by more than 90%, which is a significant technological advancement.

[0088] (2) Achieving native implementation of the self-generated system architecture in user mode to ensure the long-term steady-state operation of the self-generated intelligent agent: The existing general runtime is completely unaware of the self-generated system architecture and cannot guarantee the steady state of the intelligent agent; This invention integrates the core architecture of the self-generated system into the runtime framework, and through CEM closed-loop recursion, full-level potential field guidance, and three-level endogenous verification, it realizes the full life cycle management of the self-generated intelligent agent from loading to destruction. According to the actual test, the steady-state deviation rate of the system during continuous operation is ≤0.05, and there is no steady-state instability. It completely solves the problem of capability drift and behavior loss of control of the intelligent agent during long-term operation and has outstanding substantive features.

[0089] (3) Introducing endogenous payoff function and potential field guidance mechanism to achieve controllable endogenous evolution: Existing patchwork schemes lack endogenous evolution driving mechanism, and the system behavior is uncontrollable; This invention generates corresponding dynamic potential fields through endogenous payoff function at all levels, and constructs a complete mathematical model of system evolution by combining the benchmark potential field of M topology transmission, ensuring that all system behaviors are aimed at maximizing comprehensive benefits, and realizing controllable and predictable endogenous evolution, which is fundamentally different from existing technologies.

[0090] (4) A unified CEM cognition-decision-execution full-link closed loop is constructed: Existing piecemeal solutions separate perception, decision-making and execution, and cannot form an endogenous closed loop; This invention deeply integrates the agent's cognition, decision-making and execution with the system's underlying resource scheduling and hardware status through ternary tensor closed-loop updates, and realizes a full-link closed loop from hardware perception to endogenous cognition.

[0091] (5) Standardized ecosystem to achieve cross-platform reuse of technical assets: The existing technology ecosystem is severely fragmented and cannot be reused across platforms; This invention defines a unified standardized system call interface, hardware abstraction specification, and cross-device collaboration protocol, which realizes one-time development, full-scene adaptation, and cross-system reuse of self-generated intelligent agents, knowledge packages, and scenario solutions, completely solving the problem of fragmentation of the existing technology ecosystem. In addition, this invention designs a three-layer forward compatibility mechanism to avoid redundant development. Attached Figure Description

[0092] Figure 1: Overall architecture diagram of the self-generated system runtime framework;

[0093] Figure 2: Runtime framework initialization flowchart;

[0094] Figure 3: Schematic diagram of potential field conduction in a multilayer self-generated system;

[0095] Figure 4: Schematic diagram of cross-device collaboration and knowledge sharing network.

[0096] Figure labeling: 100, Self-generated system runtime framework; 101, Low-level adaptation layer; 102, Core engine layer; 103, Self-generated intelligent agent management and steady-state maintenance component; 104, Standardized interface layer; 105, Cross-device collaboration component; 106, Forward compatibility layer; 107, Development and maintenance toolchain; 200, Low-level operating system; 300, CEM Hardware Abstraction Layer (HAL); 400, Physical hardware unit; 500, Self-generated intelligent agent and upper-level application. Detailed Implementation

[0097] The present invention will be further described in detail below with reference to two complete and reproducible embodiments. All embodiments fully disclose the core parameters, execution steps, the entire process of formula calculation, inputs, outputs, and intermediate results. Those skilled in the art can fully reproduce the technical solution of the present invention without creative effort. All terms, definitions, and formulas in this embodiment are completely consistent with the foregoing invention content.

[0098] Example 1: Deployment and Implementation of Intelligent Agent in Industrial Welding Robot During Operation

[0099] This embodiment, based on an industrial welding robot scenario, fully reproduces the deployment and implementation process of the self-generated system runtime framework. It synchronously executes all steps S1-S8 of the self-generated system runtime method of this invention, verifying the framework's cross-OS adaptability, steady-state maintenance capability, bimodal adaptation effect, and anomaly self-healing capability. Specific implementation details are as follows:

[0100] Implementation environment and runtime framework deployment

[0101] In this embodiment, the self-generated system runtime framework is deployed using pure user-space middleware without modifying the underlying operating system kernel. It is fully compatible with Ubuntu 20.04 LTS with the PREEMPT_RT real-time patch and runs on the NVIDIA Jetson AGX Orin industrial control platform. The specific environment parameters strictly match the cross-OS adaptation and hardware abstraction adaptation requirements of the framework's underlying adaptation layer.

[0102] Underlying operating system: Ubuntu 20.04 LTS with PREEMPT_RT real-time patch (meets the framework's hard real-time scheduling requirements and adapts to the underlying operating system adaptation sublayer).

[0103] Runtime framework deployment method: pure user-space daemon process, resource isolation is achieved through Linux native cgroups and namespaces, and hard real-time scheduling is achieved through SCHED_FIFO;

[0104] Self-generated intelligent agent: a general intelligent agent for welding operations, with the core objective of achieving autonomous decision-making, adaptive adjustment, and steady-state operation of the welding process (as the core application of the framework application ecosystem, it calls the framework capabilities through a standardized interface layer).

[0105] Hardware layer: 6-axis welding industrial robot, equipped with the adapted CEM ternary mapping hardware abstraction layer HAL.

[0106] Specific implementation steps

[0107] Step 1: Runtime framework initialization

[0108] This step completes the full-link initialization of the self-generated system runtime framework. The core is the underlying adaptation layer connecting the OS and HAL, and the core engine layer initializing core parameters. The specific implementation process is as follows:

[0109] The underlying adaptation layer loads and interfaces: After the underlying adaptation layer starts, the operating system adaptation sublayer calls the native Linux system calls, encapsulating unified task scheduling (encapsulating pthread interface), resource isolation (encapsulating cgroups / namespace / seccomp interface), memory management (encapsulating memory allocation / release interface), time synchronization (encapsulating high-precision clock interface to achieve nanosecond-level timestamp acquisition), and IPC interface (encapsulating shared memory and socket interface to ensure end-to-end latency ≤10μs), completely shielding the underlying differences of the Linux system; at the same time, the hardware abstraction adaptation sublayer completes native interface with CEM HAL, establishing a bidirectional data interaction channel. Without secondary format conversion, it directly reads the standardized CEM hardware capability tensor output by HAL, maps the sensor data and actuator status of the welding robot to the framework M primitive, and sends the control commands of the framework E primitive to the HAL layer.

[0110] CEM Triple Tensor Initialization: After the core engine layer starts, the CEM triple tensor space is initialized, and the dimensions are defined: d=1 (single agent, corresponding to the number of general agents in welding operations), k=64 (single agent feature dimension, covering 12 core features such as operation identity matching degree, rule confidence, steady-state deviation value, etc.), m=16 (scheduling resource dimension, covering core resources such as CPU, memory, IO bandwidth, computing power unit, etc.). All elements of the tensor are initialized to preset steady-state baseline values ​​(e.g., the initial value of the C tensor is set to 0.9, and the initial value of the M tensor is set to 0.95).

[0111] Operational consistency settings: Rigid operational consistency is written to the core engine layer. Specifically, the welding safety specifications are: maximum current ≤ 1.5A, joint temperature ≤ 125℃, impact force ≤ 400N; welding quality target: yield rate ≥ 99.5%; initial dynamic operation consistency. Set the inertia coefficient (Determined intrinsically by the system to ensure steady-state continuity); simultaneously, the core belief weight coefficients are initialized. , ,satisfy and The constraints and requirements ensure It plays an absolutely dominant role in tensor updates.

[0112] Kernel and basic component startup: The three resident kernels of the core engine layer are started sequentially: the closed-loop scheduling kernel (scheduling period set to 1ms to match the hard real-time control requirements of the welding robot), the full-level potential field generation kernel, and the self-pointing-other-pointing dual-modal operation kernel; all components of the basic component layer are started simultaneously, including the endogenous interpretable world model (based on causal directed acyclic graph DAG initialization, loading the initial causal links of the welding scene, such as the causal relationship of "welding current → weld quality", with the initial edge weight set to 0.9), the steady-state monitoring component, the permission auditing component, and the log recording component, and the communication link initialization between components is completed.

[0113] Initialization complete: The hardware abstraction adaptation sublayer reads the welding robot's hardware capability tensor (including parameters such as motor status, sensor accuracy, and actuator response speed) from the HAL layer and maps it to the M primitive tensor; the framework completes all initialization processes, enters the agent loading ready state, and listens for the loading request of the welding agent.

[0114] Step 2: Loading and Control of Welding Intelligent Agent

[0115] The core of this step is that the intelligent agent's full lifecycle management component performs three levels of endogenous steady-state verification, isolated resource allocation, and hierarchical scheduling. The specific implementation process is as follows:

[0116] Agent Loading Request Reception: The welding operation agent submits a loading request to the framework standardized interface layer. After the interface layer completes identity authentication and compliance audit, it submits the agent's rule tensor, operating parameters, and decision logic (such as welding parameter adjustment rules) to the three-level endogenous steady-state verification module of the agent's full life cycle management component.

[0117] Level 3 endogenous steady-state verification:

[0118] (1) First-level isomorphic constraint compatibility verification: Simulate the closed-loop recursive process of CEM after the fusion of the agents to be loaded, and substitute the agent rule tensor. (1×64-dimensional, core element) ), execute a preset 50-step forward iteration, through the mapping relationship Complete the closed-loop operation. Formula: Computational information-guided mapping ,in Mapping matrix (64×64 dimensions) yields intermediate results (1×64 dimensions);

[0119] Computing energy-driven mappings: ,in The mapping matrix (64×16 dimensions) yields intermediate results. (1×16 dimensions);

[0120] Computational structure feedback mapping: ,in } is the M→C mapping matrix (16×64 dimensions), which yields the closed-loop output. (1×64 dimensions);

[0121] Calculate the molecular norm: ;

[0122] Calculate the denominator norm: ;

[0123] Calculate the deviation rate: .

[0124] Judgment: Preset deviation threshold ,satisfy The verification passed.

[0125] (2) Second-level cognitive consistency and conflict-free verification: Calculate the agent rule tensor With the system's core belief tensor (based on Generate cosine similarity (1×64 dimensions). Formula:

[0126]

[0127]

[0128] Calculate the inner product: ;

[0129] Calculate the norm product: ;

[0130] Calculate cosine similarity: ;

[0131] Calculate the conflict score: .

[0132] Judgment: Satisfied The verification passed.

[0133] (3) Verifiability verification of the three-level world model: The initial rules and operating parameters of the agent are input into the endogenous interpretable world model, along with the initial state of the current CEM tensor and the initial state of the welding environment (room temperature 25℃, welding material is low carbon steel). A 50-step forward probabilistic deduction is performed, and the predicted welding yield is output. Formula: World model projection output: (Predicted welding yield);

[0134] Preset target value: ( (Welding quality targets)

[0135] Calculate the relative deviation rate: .

[0136] Judgment: The preset deviation threshold is 10%, which meets the requirements. The verification passed.

[0137] Isolated resource allocation: After all three checks pass, the agent lifecycle management component relies on the native Linux mechanism to allocate independent resources to the welding agent: Independent CPU quotas (2 cores, bound to 3-4 physical cores to avoid core preemption) and memory limits (4GB physical memory + swap partition; exceeding this limit triggers the OOM killer, terminating only the agent) are allocated via cgroups; an independent network namespace is created via namespace, allowing access only to welding robot-related network interfaces; and a system call whitelist is set via seccomp, allowing only system calls required for welding operation such as read, write, and mmap, while prohibiting dangerous calls such as kernel module loading and privilege escalation, thus achieving hard isolation between the agent and the system and other agents.

[0138] Hard real-time hierarchical scheduling and loading: Set hard real-time hierarchical scheduling priority for the welding agent. Since it is a core business agent, it is assigned to the global target alignment level (Linux SCHED_FIFO priority 50); register the agent to the time queue of the core engine closed-loop scheduling kernel, complete the agent loading and online, and start the full life cycle monitoring of the agent simultaneously.

[0139] Step 3: CEM closed-loop recursion and potential field-guided operation

[0140] This step involves the closed-loop scheduling kernel and potential field generation kernel of the core engine layer performing calculations. The system evolves along the negative gradient direction of the potential field. The specific implementation process is as follows:

[0141] CEM Closed-Loop Recursive Update: The core engine's closed-loop scheduling kernel executes the closed-loop recursive update of the CEM ternary tensor in a 1ms scheduling cycle. The following calculation takes the 100th scheduling cycle as an example:

[0142] (1) Input parameters:

[0143] Current C tensor (1×64-dimensional) Core Fragment: The meanings of each core element are as follows: 0.92 (welding rule confidence), 0.85 (resource adaptability), 0.95 (operational identity matching), 0.78 (task completion), and 0.032 (current isomorphic constraint deviation rate).

[0144] Current E tensor (64×16 dimensional) Core diagonal weighted coefficients: The corresponding resource adaptive weighting coefficients are CPU (0.96), memory (0.93), IO bandwidth (0.89), and computing power (0.95).

[0145] Current M tensor (16×1D) Core Fragment: Meaning of each core element: 0.98 (hardware health), 0.97 (welding current 1.2A, matching) Constraints), 0.96 (joint temperature 45℃, matching) Constraints), 0.94 (weld deviation 0.02mm);

[0146] Closed-loop update parameters: , LeakyReLU negative slope , It is a 1×1 identity matrix. It is a hardware state feedback tensor (generated by M primitives from the HAL layer). The tensor of the welding execution result of the intelligent agent (tensor value of 0.94 corresponds to a weld deviation of 0.02mm).

[0147] (2) C tensor update formula:

[0148] calculate : Obtain intermediate results (1×16 dimensions), core elements: ;

[0149] calculate : Obtain intermediate results (1×1 dimension), value is 0.932;

[0150] calculate : Obtain intermediate results (1×64-dimensional), core elements: ;

[0151] calculate : Obtain intermediate results (1×64-dimensional), core elements: ;

[0152] Summation: Core elements: ;

[0153] Through the LeakyReLU activation function: , Because of all Therefore .

[0154] Output: Updated C tensor core fragment: Key changes: Welding rule confidence increased to 0.93, operational consistency matching increased to 0.96, and isomorphic constraint deviation rate decreased to 0.028 (closer to steady state).

[0155] (3) E tensor update formula:

[0156] calculate : Obtain intermediate results (64×1 dimension), core element: ;

[0157] calculate : Obtain intermediate results (64×64 dimensions);

[0158] calculate : Obtain the diagonal matrix (64×64 dimensional), diagonal elements: ;

[0159] Summing and passing through LeakyReLU: We get .

[0160] Output: Updated E tensor core diagonal weighting coefficients The weight of CPU and computing resources has been slightly increased to meet the requirements of steady-state welding operation.

[0161] (4) M tensor update formula:

[0162] calculate : Obtain intermediate results (16×64 dimensions);

[0163] calculate : Obtain intermediate results (16×16 dimensions);

[0164] calculate : Obtain intermediate results (16×16 dimensional).

[0165] Summing and passing through LeakyReLU: We get .

[0166] Output: Core fragment of the updated M tensor: The weld deviation was optimized to 0.015mm, and the corresponding tensor value was increased to 0.95.

[0167] (5) Spectral normalization and steady-state verification:

[0168] After each round of tensor update, spectral normalization is uniformly performed on the CEM ternary mapping matrix to obtain the maximum singular value = 0.99 ≤ 0.99, ensuring that the Lipschitz constant L < 1 for the composite closed-loop endogenous generating mapping, thus mathematically guaranteeing the global convergence of the system; at the same time, the current isomorphic constraint deviation rate is calculated. (Preset threshold) No kernel-level steady-state correction is required, and the system maintains steady-state operation.

[0169] Full-level potential field generation and propagation: The core engine's potential field generation kernel synchronously executes full-level potential field generation and propagation, following the top-down M-topology propagation rule, specifically implemented as follows:

[0170] (1) Potential field generation: Each level of E-element generates its own level dynamic potential field based on the corresponding endogenous payoff function. The dynamic potential field and the endogenous payoff function satisfy the following conditions: This cycle focuses on calculating the potential field of the L2 dynamically evolving self-generated system (driving welding parameter adjustment), formula:

[0171] Substitute parameters: , , , ;

[0172] ;

[0173] Dynamic potential field: .

[0174] (2) Potential field propagation: L4 global value total potential field (based on Generation, this cycle The potential field of L3 is transmitted through the M-topology to L3, and the total potential field of L3 is transmitted through the M-topology to L2, serving as the reference potential field of L2 (reference potential field for this period = 0.001); Total potential field of L2: Right now: .

[0175] (3) System evolution: The welding robot system moves along the negative gradient direction of the L2 total potential field (i.e., towards) (Minimum value direction) Adaptively adjust welding parameters (such as fine-tuning the welding current to 1.18A and the welding speed to 5mm / s) to maintain welding steady state and ensure that the weld quality meets the requirements. constraint.

[0176] Step 4: Bimodal Adaptive Tuning

[0177] The core of this step is that the bimodal adaptive tuning module dynamically adjusts the weights of the self-pointing / other-pointing modes to achieve a balance between steady-state maintenance and task execution. The specific implementation process is as follows:

[0178] The dual-modal operation is based on the following: self-referenced modes and other-referenced modes operate synchronously and in parallel throughout their entire lifecycles, without mutual exclusion or pause logic; the dual-modal adaptive adjustment module collects multi-dimensional system operating metrics in real time with a 1ms scheduling cycle, including global system coherence. (Calculated from CEM tensor coupling state), Maximum Lyapunov exponent (Characterizing the degree of chaos in the system; the smaller the value, the more stable the system), free energy change rate ΔF(t) = 0.01, current task complexity score. (Normal welding operation, low complexity).

[0179] Weight calculation and adjustment:

[0180] (1) Normal welding steady-state stage:

[0181] Substituting into the endogenous adjustment formula for modal weights, calculate the bimodal weights:

[0182] Wherein, the Logistic activation function is: .

[0183] Substitute parameters: ;

[0184] Calculate linear combinations:

[0185] Calculate the activation function value: ;

[0186] Calculate the other-point modal weights: .

[0187] The system is predominantly self-explained modes (with a weight of approximately 0.74), and its core objective is to maintain steady-state welding (matching). constraint).

[0188] (2) Abnormal adjustment phase:

[0189] When the vision sensor detects a 0.15mm deviation in the weld (exceeding the steady-state threshold of 0.02mm), the system detects an external target alignment requirement (weld correction task). After the correction strategy passes the three-level endogenous steady-state verification, the dual-modal adaptive adjustment module initiates a weighted gradient smooth transition with a transition period of 100ms (5 scheduling cycles), gradually adjusting the weights:

[0190] Transition process: The weights are adjusted every 20ms, sequentially as follows: (0.74, 0.26) → (0.6, 0.4) → (0.45, 0.55) → (0.35, 0.65) → (0.3, 0.7).

[0191] Final weights: Switch to the other-finite mode as the main mode, focusing on the task of correcting weld deviations.

[0192] Adaptation Results: Based on the other-finger modal guidance, the system automatically adjusts welding trajectory parameters (such as fine-tuning robot joint angles). After two scheduling cycles (2ms), the weld deviation is corrected to within 0.02mm, and the task is completed. The dual-modal adaptive adaptation module initiates weight callback and smoothly returns to the steady-state configuration according to the same transition cycle. The isomorphic constraint deviation rate fluctuation before and after adjustment is ≤0.02 (fluctuating from 0.028 to 0.03, and then falling back to 0.028), with no steady-state shock, which meets the core requirements of the frame dual-modal adjustment.

[0193] Step 5: Security Management and Anomaly Self-Healing

[0194] The core of this step is that the agent's full lifecycle management component performs full lifecycle monitoring, triggering a tiered self-healing mechanism. The specific implementation process is as follows:

[0195] Full lifecycle monitoring: The full lifecycle management module monitors the operating status, resource usage (CPU utilization, memory usage), steady-state deviation indicators (isomorphic constraint deviation rate), and operation consistency matching degree of the welding agent in real time at 1ms intervals. At the same time, it monitors the global status of the system (CEM tensor convergence, O_{core} constraint satisfaction) and establishes a real-time monitoring ledger, recording the core indicators every 10ms.

[0196] Anomaly detection and graded self-healing:

[0197] (1) Scenario 1: Minor anomaly (triggered first-level self-healing - parameter correction): During operation, a single servo motor of the welding robot experiences slight vibration. The motor health index in the frame M primitive tensor drops from 0.98 to 0.85, and the isomorphic constraint deviation rate rises from 0.028 to 0.055 (exceeding the preset threshold of 0.05, but not reaching 0.6), triggering first-level self-healing. The intelligent agent full life cycle management component automatically adjusts the motor control PID parameters (proportional coefficient is adjusted from 2.0 to 2.2, integral coefficient is adjusted from 0.1 to 0.12). After 2 scheduling cycles (2ms), the motor health recovers to 0.97, the isomorphic constraint deviation rate falls back to 0.029, self-healing is completed, and the system returns to steady state.

[0198] (2) Scenario 2: General anomaly (triggering level 2 self-healing - agent isolation): If the welding agent attempts to access an unauthorized hardware interface (such as the robot emergency stop control interface) due to a program anomaly, the standardized interface layer (corresponding to runtime method S7) immediately intercepts the M-type system call, completes permission verification and compliance audit, determines that the behavior is in violation, and triggers level 2 self-healing; the agent's full life cycle management component suspends the operation of the agent, isolates it to an independent anomaly domain, records the security log (including the violation time, the interface called, and the reason for the anomaly), and notifies the operation and maintenance personnel at the same time; during the isolation period, the core engine of the framework and other components operate normally and do not affect the core steady state of the system; after the operation and maintenance personnel investigate the anomaly, they correct the agent program, re-execute the level 3 endogenous steady state verification, and after the verification passes, the isolation is lifted and the agent operation is restored.

[0199] Step 6: Standardized Interface Services and Cross-Device Collaboration

[0200] Standardized Interface Services: During the operation of the welding agent, the C / E / M interfaces of the framework are called through the standardized interface layer to achieve interaction with the core engine layer and the underlying adaptation layer.

[0201] Calling the C class interface ( ), read the C tensor state and steady-state deviation index;

[0202] Calling the E class interface ( ), requesting adjustments to computing resources and scheduling priorities;

[0203] Call the interface of class M ( ), read sensor data and issue welding execution commands;

[0204] All API calls undergo permission verification and compliance auditing, and return standardized results (status code, data digest) upon completion. Python language binding is supported, eliminating the need to consider differences in the underlying Linux system and achieving "one-time call, full platform adaptation".

[0205] Cross-device collaboration: If multiple welding robots of the same model are deployed (building a distributed collaborative network), the cross-device collaboration component is based on the Linux native network protocol stack to build a P2P decentralized collaborative network without the need for a centralized server; each robot node completes heartbeat synchronization, timestamp alignment, and CEM tensor core parameter interaction at 100ms intervals to achieve cross-node state consistency calibration; it supports cross-node hot migration of welding agents (such as migrating agents from abnormal nodes to normal nodes), lightweight knowledge package synchronization (such as synchronizing optimized welding parameters to all nodes), and distributed computing power sharing (allocating welding tasks according to the resource occupancy of each node), ensuring that all nodes follow the same rules when multiple robots are running collaboratively. Constraints and potential field evolution rules enable global coordinated steady state.

[0206] This embodiment achieves steady-state operation of the welding robot agent by fully deploying the self-generated system runtime framework and executing runtime method steps S1 to S8. The quantitative implementation effect is as follows, fully verifying the practicality and advancement of the present invention:

[0207] Adaptation efficiency: No Linux kernel modification is required, and the adaptation and deployment of existing welding robots can be completed in just 2 working days. The adaptation efficiency is more than 95% higher than that of traditional middleware (traditional solutions require more than 40 working days).

[0208] Welding quality: The welding yield rate increased from 92.3% in the traditional solution to 99.6%, an improvement of 7.3 percentage points, fully meeting the welding quality target (≥99.5%) in O_{core}.

[0209] System steady state: The system ran continuously for 72 hours (259,200 scheduling cycles) without any steady-state instability. The isomorphic constraint deviation rate was ≤0.04 throughout the entire process, and the system availability reached 99.999%.

[0210] Process adaptation: When introducing a new process, there is no need to modify the framework code, only to update the agent rule tensor. The import time is reduced from 7 days in the traditional solution to 30 seconds, and the import efficiency is improved by more than 20,000 times.

[0211] Anomaly handling: A total of 12 minor anomalies and 3 general anomalies were triggered. The success rate of graded self-healing was 100%, and the self-healing response time was ≤2ms. No anomaly spread or system crash occurred, which verified the effectiveness of the anomaly self-healing mechanism.

[0212] Example 2: Deployment and Implementation of Personal Smart Terminal Assistant at Runtime

[0213] Implementation environment: Underlying operating system: Android 13 (based on Linux kernel), running on an 8-core ARM architecture smartphone;

[0214] Runtime framework deployment method: It runs as an Android system service, communicates with upper-layer applications through Binder IPC, and achieves resource isolation through Linux cgroups.

[0215] Implementation process and results:

[0216] Runtime framework initialization, Android system interface adaptation, CEM tensor space initialization, and rigid operation uniformity set as: user privacy and security, smooth system operation, and precise service matching;

[0217] When a user uses the standard knowledge transfer package for the first time, they select the "Workplace Scenarios" package. The runtime framework performs three levels of verification on the knowledge package and calls the endogenous interpretable world model for forward prediction. The rigid red line similarity is 0.9998 and the survival prediction value is 0.991, which is greater than or equal to the threshold of 0.982. All verifications are passed, and the knowledge fusion is completed.

[0218] The runtime framework allocates independent CPU quotas (4 cores) and memory limits (2GB) to the personal intelligent assistant, and sets high-priority scheduling to ensure that other applications do not interfere with the assistant's operation;

[0219] The runtime framework continuously learns user habits through the CEM closed loop: the C primitive records user schedules, preferences, and daily routines; the E primitive dynamically adjusts computing power allocation based on user activity periods, reducing power consumption during idle times and improving performance during active times; and the M primitive collects user behavior and environmental data through mobile phone sensors.

[0220] Automatic updates of potential fields across all levels: The L4 global value potential field is adjusted according to user preferences, and the L2 strategy potential field guides the assistant to generate behaviors that conform to user habits; after running for a week, the system automatically generates personalized rules such as "automatically turn on the work do not disturb mode at 9 am on weekdays and filter non-work-related notifications", which do not require manual settings by the user;

[0221] When a user switches to a new phone, the cross-device collaboration component allows for one-click synchronization of the old phone's smart assistant knowledge package and personalized rules to the new phone. The synchronization time is ≤30 seconds, and the new phone does not need to be retrained, directly restoring the user's personalized experience.

[0222] Implementation results: The accuracy rate of user intent understanding reached 98.7%, and the accuracy rate of task execution reached 99.2%; the system ran continuously for 30 days without any steady-state instability or privacy leakage incidents; the cross-device knowledge transfer time was ≤30 seconds, significantly improving the user experience; the average power consumption of the smart assistant was reduced by 32%, and the mobile phone battery life was increased by 2.5 hours.

[0223] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the core concept and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A self-generated system runtime framework, characterized in that, Running on top of the underlying operating system, it is a pure user-space middleware that does not modify the underlying operating system kernel. The runtime framework adopts a univariate, two-state, three-body self-generated system architecture with operational uniformity as the core convergence goal, self-referential-other-referential dual-modal adaptive adjustment as the driving force, and three irreducible functional primitives—information field state (C), energy mechanism (E), and matter structure (M)—recursively mapped in a closed loop to form the minimum runtime link. This includes: a low-level adaptation layer, used to encapsulate unified hardware resource access, task scheduling, memory management, time synchronization, and inter-process communication interfaces through native system calls from the underlying operating system, shielding the underlying differences between different operating systems; and a core engine layer, deployed in user space, used to maintain the CEM (Continuous Engine Model). The system implements a global state control mechanism for ternary tensors, performs closed-loop recursive updates, generates endogenous payoff functions and corresponding potential fields across all levels, schedules self-generated agents, and performs isomorphic constraint verification, maintaining system steady state with operational identity as the sole global convergence anchor point. A self-generated agent management and steady-state maintenance component performs three-level endogenous steady-state verification, isolated resource allocation, hard real-time hierarchical scheduling, full-cycle state monitoring, and adaptive adjustment of operational modes. A standardized interface layer provides standardized system call interfaces corresponding to the three primitives of CEM to upper-layer self-generated agents and enables resource access and hardware abstraction through the native interfaces of the underlying operating system. A cross-device collaboration component enables distributed communication between runtime frameworks of the same architecture, agent cross-node migration, knowledge synchronization, and distributed collaborative decision-making through the native network protocol stack of the underlying operating system. A forward compatibility layer defines the compatibility rules between standardized interfaces, data formats, scheduling logic, and the kernel interfaces of the future self-generated operating system, ensuring that currently developed self-generated agents and applications can be migrated to the future self-generated operating system with zero modifications.

2. The self-generated system runtime framework according to claim 1, characterized in that, The operational identity is defined using a two-layer structure, and its mathematical expression is: in, For rigid operational consistency, it is a rigid security and compliance constraint that cannot be modified throughout the entire lifecycle of the runtime framework, and is preset by the user or system during initialization; To ensure consistency in dynamic operations, an endogenous update is implemented based on accumulated system operational experience. The update formula is as follows: In the formula The inertia coefficient is intrinsically determined from the system's steady-state data. It is a new steady-state target that has passed the three-level endogenous steady-state verification and satisfies the deviation constraint of identity with rigid operation.

3. The self-generated system runtime framework according to claim 1, characterized in that, The dimension definition and closed-loop recursive coupling update formula of the CEM ternary tensor are as follows: Dimension definition rule: Information field state C primitive tensor: ,in The number of self-generated intelligent agents currently in operation. For a single self-generated intelligent agent, the feature dimensions include operation identity matching degree, scheduling priority, rule confidence, knowledge fusion state, and steady-state deviation value; the self-generated intelligent agent refers to an intelligent agent built based on a self-generated system; energy mechanism E primitive tensor: ,in This refers to the system's schedulable resources, which include CPU quotas, memory limits, I / O bandwidth, network bandwidth, and computing unit quotas. Matter structure M-based tensor: It characterizes the hardware status and external environment feedback, including sensor data, actuator status, system health, resource utilization, and environmental perception results; the closed-loop recursive coupled update formula is as follows: In the formula: and , which is the core belief weight coefficient; For matrix multiplication operations, tensor shrinking is performed according to the matching dimension; For the Kronecker product operation; for identity matrix; It is a diagonal matrix with resource adaptive weighting coefficients as diagonal elements, and the weighting coefficients are endogenously determined by the matching degree of resource utilization and operational identity. The hardware state feedback tensor is generated from data collected by the M primitive from the hardware abstraction layer. The result tensor is generated by the task execution feedback of the self-generated agent; LeakyReLU is a nonlinear activation function with a negative slope determined endogenously by the system; spectral normalization is performed on the three mapping matrices in each iteration cycle, limiting their maximum singular value to less than 1 to ensure the Lipschitz constant of the endogenously generated composite closed-loop mapping. .

4. The self-generated system runtime framework according to claim 1, characterized in that, The underlying adaptation layer includes: (1) an operating system adaptation sublayer, which encapsulates the native system calls of Linux, Windows, RTOS and Android, and provides a unified abstract interface for task scheduling, resource isolation, memory management, time synchronization and inter-process communication; (2) a hardware abstraction adaptation sublayer, which is used to natively interface with the hardware abstraction layer HAL based on CEM ternary mapping, directly receive the standardized CEM hardware capability tensor output by HAL, without secondary format conversion, and realize the seamless connection between hardware capabilities and runtime framework.

5. The self-generated system runtime framework according to claim 1, characterized in that, The core engine layer constructs a full-level endogenous payoff function system. The E-element of each level's self-generated system generates its own dynamic potential field based on the corresponding level's endogenous payoff function. The upper-level total potential field serves as the core component of the lower-level reference potential field, propagating downwards through the M-element topology. The system evolves along the negative gradient direction of the total potential field at each level. The total potential field at each level is a weighted superposition of the level's reference potential field and its dynamic potential field. The precise mathematical correspondence between the dynamic potential field and the endogenous payoff function is: the potential value at any point in the dynamic potential field... It equals the output value of the endogenous payoff function when the system takes the action corresponding to that point. The negative value.

6. The self-generated system runtime framework according to claim 1, characterized in that, The execution rules of the self-generated intelligent agent management and steady-state maintenance component include: (1) three-level endogenous steady-state verification: three-level endogenous steady-state verification must be performed before the self-generated intelligent agent is loaded, and registration and loading can only be completed when all verifications pass; (2) isolated resource allocation: through the native resource isolation mechanism of the underlying operating system, an independent CPU is allocated to each self-generated intelligent agent. Quota, memory limit, file system view, network namespace, system call whitelist, realize hard isolation of resources and security isolation between intelligent agents; (3) Hard real-time hierarchical scheduling: through the native real-time scheduling interface of the underlying operating system, three levels of priority are set for the self-generated intelligent agents, with the priority from high to low as follows: kernel steady state guardian level, global target alignment level, and user-defined level; the scheduling cycle is determined by the runtime framework and the underlying operating system in collaboration; (4) Full life cycle monitoring: real-time monitoring of the running status, resource usage, steady state deviation index, and operation identity matching degree of the self-generated intelligent agents, and triggering a hierarchical self-healing mechanism when abnormal; (5) Bimodal adaptive adjustment: the self-indicating mode and the other-indicating mode run simultaneously throughout the entire life cycle, real-time monitoring of the system steady state index and external target, and adjusting the running weight of the bimodal mode through the endogenous weight formula to achieve gradient smooth adjustment.

7. The self-generated system runtime framework according to claim 1, characterized in that, The three-level endogenous steady-state verification includes: (1) isomorphic constraint compatibility verification: simulating the closed-loop recursive process of the CEM after the fusion of the objects to be verified, performing a preset number of forward iterations, and calculating the isomorphic constraint deviation rate. ,like If the validation passes, otherwise parameter correction is triggered or the application is rejected directly; where The preset deviation threshold is used; the formula for calculating the isomorphic constraint deviation rate is: In the formula Let the information field state tensor be the object to be verified. , , These are information-guided mapping, energy-driven mapping, and structural feedback mapping, respectively. for Norm; (2) Cognitive consistency and conflict-free verification: Calculate the cosine similarity between the rule tensor of the object to be verified and the core belief tensor of the system. Define conflict score If the conflict score is <0.3, the verification passes; if 0.3≤conflict score<0.9, the weight adjustment is triggered; if the conflict score is ≥0.9, the verification is rejected directly. (3) Verification rules for the verifiability of the world model: Input the object to be verified into the system's endogenous interpretable world model, perform forward simulation, and calculate the relative deviation rate between the simulation results and the expected target. ,like If the preset deviation threshold is met, the verification will pass; otherwise, parameter correction will be triggered.

8. The self-generated system runtime framework according to claim 1, characterized in that, The modal adaptive adjustment operation rules include: (1) Self-referential mode: The core objective is to maintain the system's operational uniformity fixed point and endogenous steady state, strengthen effective operation modes and weaken ineffective modes through self-referential positive feedback, and ensure long-term stable operation of the system; (2) Other-referential mode: The core objective is to complete global target alignment and environmental adaptation through the guidance of the total potential field without destroying the system's core steady state; (3) Dual-modal synchronous operation: Self-referential mode and other-referential mode run simultaneously throughout their entire life cycle. The operation weights of the two are dynamically adjusted through the endogenous weight formula in each scheduling cycle. There is no mutual exclusion pause logic. The rule update function of other-referential mode is only temporarily frozen when the third-level circuit breaker is triggered; (4) Modal weight endogenous adjustment formula: In the formula The activation function is logistic. The system's global coherence; The system's maximum Lyapunov exponent; The rate of change of the system's free energy; Rate the complexity of the current task; The weight coefficients are learned intrinsically by the system and are updated online by the runtime framework based on historical data using ridge regression or Bayesian inference. The default initial values ​​are respectively .

9. The self-generated system runtime framework according to claim 1, characterized in that, The standardized interface layer provides a standardized set of system calls corresponding to the three core elements of CEM. All system calls undergo permission verification and compliance auditing, and are implemented through the native interfaces of the underlying operating system. Specifically, these include: C-type information field system calls: used for reading and writing information field tensors, rule generation, concept abstraction, and knowledge fusion operations, including C_tensor_read, C_tensor_write, C_concept_extract, C_rule_generate, C_knowledge_fuse, C_core_belief_verify, C_potential_field_build, C_steady_state_check, C_snapshot_save, C_snapshot_restore, C_context_create, and C_context_destroy; E Energy-related system calls: used for computing power allocation, agent scheduling, execution instruction generation, and game equilibrium solving operations, including E_agent_schedule, E_compute_quota_alloc, E_exec_instruct_gen, E_nash_equilibrium_solve, E_modal_switch, E_priority_set, E_message_send, and E_message_receive; M-type material structure system calls: used for hardware access, sensor data reading, actuator control, and hardware adaptation operations, including M_hardware_detect, M_hardware_config, M_sensor_data_read, M_actuator_control, M_hardware_access_apply, M_hardware_access_release, M_hal_interface_call, M_device_sync, M_low_power_control, and M_hardware_health_check.

10. The self-generated system runtime framework according to claim 1, characterized in that, The cross-device collaborative component constructs a P2P decentralized collaborative network through the native network protocol stack of the underlying operating system. The upper limit of the number of nodes is intrinsically determined by system resources and network configuration, enabling cross-device self-generated intelligent agent migration, knowledge package synchronization, computing power sharing, and distributed collaborative decision-making.

11. The self-generated system runtime framework according to claim 1, characterized in that, It also includes a development and maintenance toolchain, which includes: (1) an agent development IDE, which provides a visual environment for the development, debugging and simulation of self-generated agents, and supports code templates, syntax hints, breakpoint debugging and one-click deployment; (2) a hardware-in-the-loop simulation tool, which simulates the interaction between hardware and runtime framework in a virtual environment, and can complete the development, testing and verification of self-generated agents without physical hardware; (3) a package management tool, which provides the ability to distribute, install, upgrade and manage versions of self-generated agents, functional components and hardware adaptation packages; and (4) a cluster operation and maintenance platform, which provides the ability to visualize cluster device management, runtime status monitoring, batch deployment of agents, abnormal alarms and log analysis.

12. A method for running a self-generated system, characterized in that, The runtime framework applied to any one of claims 1-11 includes the following steps: S1 Runtime framework initialization: Load the native interface of the underlying operating system through the underlying adaptation layer, initialize the CEM ternary tensor space, set rigid operation identity and initial dynamic steady state, start the core engine layer and each component, and complete the docking with the hardware abstraction layer; S2 Self-generated intelligent agent loading and management: Receive the loading request of the self-generated intelligent agent, perform a three-level endogenous steady state check, allocate isolated running resources to the intelligent agent after the check passes, and register the intelligent agent to the scheduler of the core engine; S3 CEM closed-loop recursive operation: In each scheduling cycle, perform closed-loop recursive update according to the current CEM ternary tensor, and perform spectral normalization on the mapping matrix to ensure the Lipschitz constant. Real-time calculation of isomorphic constraint deviation rate in each cycle. If the deviation rate exceeds the preset threshold, the scheduling of non-core agents is immediately suspended, triggering kernel-level steady-state correction until the deviation rate recovers to within the threshold; S4 Generation and transmission of potential fields across all levels: Each level's E primitive generates its own dynamic potential field based on its corresponding endogenous payoff function. The upper-level total potential field is transmitted through the M topology to become the core of the lower-level reference potential field, and the system evolves along the negative gradient direction of the total potential field; S5 Dual-modal adaptive adaptation: Self-indicating modes and other-indicating modes run simultaneously throughout their entire lifecycle, real-time monitoring of system steady-state indicators and external targets, and adjustment of the running weights of the dual modes based on the endogenous weight formula to complete gradient-based smooth adaptation; S6 Security control and anomaly self-healing: Real-time monitoring of the behavior of self-generated agents and system steady-state indicators, interception of violations, and triggering of a graded self-healing mechanism for abnormal states. The graded self-healing mechanism, from low to high, is as follows: parameter correction, agent isolation, modality adaptation, and system state rollback; S7 Standardized interface service: Responds to system call requests from upper-layer intelligent agents and applications, performs permission verification and compliance audit, calls the corresponding kernel functions and returns the results; S8 cross-device collaboration: Through the native network protocol stack of the underlying operating system, it completes communication, state synchronization, intelligent agent migration and distributed collaborative decision-making with other nodes in the collaborative network. Cross-device collaboration is triggered by the upper-layer intelligent agent actively calling the cross-device system call in the standardized interface layer, or by the runtime framework making an intrinsic decision based on system load and task complexity.

13. A non-volatile, non-transient computer-readable storage medium, characterized in that, The storage medium stores a computer-executable program, which, when executed by a processor, implements the self-generated system runtime method of claim 12, or runs the self-generated system runtime framework of any one of claims 1-11.

14. An intelligent electronic device, characterized in that, It includes a processor, a memory, and the self-generated system runtime framework as described in any one of claims 1-11; the intelligent electronic device includes an industrial robot controller, a personal intelligent terminal, an edge computing gateway, a smart city management and control terminal, and an in-vehicle intelligent controller.

Images