Function execution method, system, device, computer device and storage medium

Abstract

This invention relates to a function execution method, system, apparatus, computer device, and storage medium. The method involves receiving a function registration request for a target function submitted by a target tenant; generating function metadata corresponding to the target function based on the function code and object type information for storage; creating an independent computing cluster for the target tenant and binding the function metadata to the computing cluster; generating and caching a runtime environment for executing the target function based on the function metadata; and executing the target function according to the runtime environment upon receiving a function call request for the target function. Therefore, an independent computing cluster and a cacheable runtime environment can be pre-built and bound for the target tenant based on the registered function metadata. During function execution, the runtime environment can be directly invoked within the independent computing cluster, achieving isolated execution and fast invocation of functions, thereby improving the security and efficiency of function execution.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a function execution method, system, apparatus, computer device and storage medium. Background Technology

[0002] With the development of intelligent agent systems and distributed computing technologies, business systems are increasingly incorporating dynamically invoked function execution mechanisms to support the automated processing of complex tasks. One existing approach is to embed business functions as components directly within the agent process. This method achieves lower execution latency by completing function calls within the same process. However, this embedded function invocation method tightly couples the function code with the agent process, lacks effective isolation between functions, makes independent upgrades and hot updates difficult, and is prone to conflicts when function dependency versions are inconsistent, affecting system stability.

[0003] Another existing technology is to use a container-based local execution approach, running multiple functions in a single container or local virtual environment, and using a function management service to schedule and manage dependencies of the functions. However, its execution environment is usually limited to a single container, lacking distributed scheduling capabilities and making it difficult to perform fine-grained resource isolation and scheduling control at the tenant or function level.

[0004] Furthermore, existing distributed execution frameworks mainly focus on providing underlying computing capabilities, failing to provide comprehensive platform-level capability support for multi-tenant scenarios. They lack mechanisms for binding functions to tenants, function version management, function preloading, and runtime statistics, and cannot uniformly understand and manage functions at the platform level, making it difficult to meet the needs of intelligent agent systems for dynamic function invocation, isolated execution, and efficient scheduling.

[0005] Therefore, there is a need for a function execution mechanism oriented towards intelligent agents, which has multi-tenant isolation, function semantic understanding, and efficient distributed execution capabilities. Summary of the Invention

[0006] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, the embodiments of the present invention provide a function execution method, system, device, computer equipment and storage medium.

[0007] In a first aspect, embodiments of the present invention provide a function execution method, including: Receive a function registration request for a target function submitted by the target tenant. The function registration request includes function code and object type information associated with the function code. Based on the function code and the object type information, function metadata corresponding to the target function is generated for storage. Create a separate computing cluster for the target tenant, and bind the function metadata to the computing cluster; A runtime environment for executing the target function is generated and cached based on the function metadata; Upon receiving a function call request for the target function, the runtime environment is invoked in the computing cluster to execute the target function according to the runtime environment.

[0008] In one possible implementation, generating function metadata corresponding to the target function based on the function code and the object type information for storage includes: The identity information of the target tenant, the function code, and the object type information are verified. After the verification is passed, obtain the function identification information used to identify the target function, the parameter declaration information used to describe the parameters of the target function, and the function dependency information used to describe the execution dependencies of the target function; Based on the function identification information, the parameter declaration information, the function dependency information, and the object type information, the function metadata is generated. The object type information is used to characterize the field structure and field constraints of the object referenced by the function parameters in the function code. The function code is stored in the code storage location, and the function code is associated with the function identification information. The function metadata is stored in the function metadata storage location, and the function metadata is associated with the function identification information.

[0009] In one possible implementation, creating a separate computing cluster for the target tenant and binding the function metadata to the computing cluster includes: Based on the tenant identifier of the target tenant, allocate independent computing resources to the target tenant, and create the computing cluster based on the computing resources; The function metadata is associated with the cluster identifier of the computing cluster to establish a binding relationship between the target function and the computing cluster. The binding relationship is used to restrict the target function to be executed only in the computing cluster corresponding to the cluster identifier.

[0010] In one possible implementation, generating and caching the runtime environment for executing the target function based on the function metadata includes: Send a function preloading notification to the function management service in the computing cluster to control the function management service to clone the function code based on the function preloading notification and read the function dependency information recorded in the function metadata, so as to build a runtime environment for executing the target function in the computing cluster corresponding to the target tenant according to the function dependency information; After the runtime environment is built, an environment identifier is generated for the runtime environment, and the runtime environment, the function code and the environment identifier are stored in the computing cluster accordingly, and the environment identifier is associated with the function metadata.

[0011] In one possible implementation, the step of invoking the runtime environment in the computing cluster to execute the target function according to the runtime environment includes: Obtain the function identifier information of the target function from the function call request, and obtain the function metadata based on the function identifier information; Obtain the running mode corresponding to the objective function, wherein the running mode is used to characterize the execution mode of the objective function; Based on the operating mode, the corresponding execution unit is selected in the computing cluster corresponding to the target tenant; The runtime environment corresponding to the target function is invoked, and the target function is executed on the execution unit in the computing cluster according to the function metadata.

[0012] In one possible implementation, selecting the corresponding execution unit in the computing cluster corresponding to the target tenant according to the operating mode includes: When the running mode is session mode, it is determined whether the execution unit associated with the running environment has hit the cache. The session mode is suitable for scenarios with high-frequency function calls. If the cache is hit, the cached execution unit is directly invoked to execute the target function. If the cache is not hit, a new execution unit is created in the computing cluster, the new execution unit is associated with the runtime environment and cached, and then the target function is executed through the new execution unit. When the running mode is task mode, a temporary execution unit is created in the computing cluster corresponding to the target tenant to execute the target function, and the temporary execution unit is destroyed after the target function is executed. The task mode is adapted to scenarios with low-frequency function calls.

[0013] In a second aspect, embodiments of the present invention provide a function execution system for implementing the method described in the first aspect above, comprising: The ontology service is used to receive function registration requests for target functions submitted by target tenants. The function registration request includes function code and object type information associated with the function code. The ontology service is also used to verify the identity information of the target tenant, the function code, and the object type information. After the verification is passed, it generates function metadata corresponding to the target function based on the function code and the object type information, stores the function code and the function metadata, and sends a preloading notification to the function management service. The cluster management service is used to create independent computing clusters for the target tenant, bind the function metadata to the cluster identifier of the computing cluster, and dynamically scale the computing cluster based on the resource requirements and real-time call volume of the function metadata. The function management service is deployed on the computing cluster to respond to the preloading notification, clone and load the function code, generate and cache the runtime environment for executing the target function based on the function metadata, and, upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster corresponding to the target tenant and execute the target function according to the running mode corresponding to the target function. An intelligent agent is used to query function metadata in the ontology service, convert it into a tool description structure that the large model can recognize, and drive the large model to automatically construct function call parameters for generating function call requests.

[0014] Thirdly, embodiments of the present invention provide a function execution apparatus, comprising: The receiving module is used to receive a function registration request for a target function submitted by a target tenant. The function registration request includes function code and object type information associated with the function code. The first generation module is used to generate function metadata corresponding to the target function based on the function code and the object type information, for storage purposes; A creation module is used to create an independent computing cluster for the target tenant and bind the function metadata to the computing cluster; The second generation module is used to construct and cache the runtime environment for executing the target function based on the function metadata; An execution module is configured to, upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster to execute the target function according to the runtime environment.

[0015] Fourthly, embodiments of the present invention provide a computer device, including: a processor and a memory, wherein the processor is configured to execute a function execution program stored in the memory to implement the function execution method described in any one of the first aspects above.

[0016] Fifthly, embodiments of the present invention provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the function execution method described in any of the first aspects above.

[0017] The function execution scheme provided in this invention receives a function registration request for a target function submitted by a target tenant. The function registration request includes function code and object type information associated with the function code. Based on the function code and object type information, function metadata corresponding to the target function is generated and stored. An independent computing cluster is created for the target tenant, and the function metadata is bound to the computing cluster. A runtime environment for executing the target function is generated and cached based on the function metadata. Upon receiving a function call request for the target function, the runtime environment is invoked in the computing cluster to execute the target function. Therefore, an independent computing cluster and a cacheable runtime environment can be pre-built and bound for the target tenant based on the registered function metadata. During function execution, the runtime environment can be directly invoked in the independent computing cluster, achieving isolated execution and fast invocation of functions, thereby improving the security and efficiency of function execution. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a function execution method provided in an embodiment of the present invention; Figure 2 A schematic diagram of the structure of a function execution system provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another function execution method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a function execution device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

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

[0020] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0021] Figure 1 This is a flowchart illustrating a function execution method provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the method specifically includes: S11. Receive the function registration request for the target function submitted by the target tenant. The function registration request includes the function code and the object type information associated with the function code.

[0022] The function execution method provided in this invention is applicable to multi-tenant AI service platforms, distributed function computing platforms, and large-model intelligent invocation scenarios. It can support batch function deployment, intelligent scheduling, and no-code integration requirements in multiple fields such as finance and the internet. It is particularly suitable for business scenarios involving multi-tenant shared infrastructure with strict resource isolation, mixed scheduling of high-frequency / low-frequency functions, and large-model-driven remote function invocation. Specifically, during the function registration phase, the function code and its associated object type information are parsed to generate function metadata. Based on the function metadata, an independent computing cluster is created and bound for the target tenant. The runtime environment is pre-built and cached before function execution. When a function call request is received, the target function is directly executed in the corresponding computing cluster using the runtime environment, thereby achieving isolated management and efficient execution of functions.

[0023] The executing entity is a computer device, which may include servers, desktop computers, etc. In this embodiment, the executing entity is specifically a distributed service cluster deployed by the platform operator (e.g., the KAX2.0 system). The control unit issues instructions to each module so that the modules can perform core actions. For example, each module may include: the ontology service is executed by the platform ontology management module, which is responsible for parsing, verifying and storing function metadata; the cluster management service is executed by the cluster scheduling module, which manages the creation and scaling of tenant-specific computing clusters; the function management service is deployed on each tenant's computing cluster, and the function scheduling unit performs preloading, running mode decision-making and function execution control; the intelligent agent is executed by the interaction module, which completes metadata conversion, parameter construction and call request initiation; and the code repository is executed by the version management module, which is responsible for storing and versioning function code. All entities work together to achieve intelligent operation of functions throughout the entire process.

[0024] In this embodiment, the target tenant refers to an independent user or organizational unit that submits a function registration request. The target function is a business function developed by the target tenant that needs to be registered and executed. The target function must conform to preset coding standards, such as the KAX 2.0 coding standards (including OSDK references, @function decorator markers, etc. OSDK (Ontology SDK) is the Ontology Software Development Kit, used in KAX 2.0 to describe ontology structure, object types, attributes, and behaviors). The function registration request is a request initiated by the target tenant to include the target function in management. It contains the core information required for function execution and is the starting instruction for the function to enter its lifecycle. The function code is the complete Python business logic code of the target function, which may include input parameter definitions, execution logic, output parameter declarations, @function decorators, and specification Docstrings. It is the core carrier of function execution. The object type information is ObjectType-related data defined by OSDK, which may include the ObjectType's name, version, core attributes, and behavioral descriptions. It is key information for binding the function to the ontology and is used to clarify the data structure of the function operation. The Ontology Service is the core component that receives and processes function registration requests. It is responsible for request verification, metadata generation, version management, and compatibility verification, and is the core processing unit in the function registration process.

[0025] Before registering a function, the following steps can be performed: After the target tenant has completed system authentication, a unique tenant identifier (such as a tenant ID) is obtained for subsequent cluster binding and resource isolation. The OSDK defines the ObjectType associated with the function (i.e., the source of object type information) to ensure that the function matches the ontology structure; the function code has been decorated with the `@function` decorator, facilitating the system's quick identification of registrable business functions; the function code has been stored in a Gitea repository (code repository) and version-managed, supporting subsequent version rollback and multi-version compatibility; the function includes a standardized Docstring for subsequent parsing of function parameters, dependencies, and ObjectType references. The system has deployed an ontology service and exposed a standardized registration interface, allowing tenants to submit requests through specified channels.

[0026] Furthermore, target tenants submit function registration requests through the following two standardized channels to ensure the standardization and availability of request transmission: 1. Visual interface submission: Tenants operate through the KAX2.0 web page or VSCode integration page: Upload the completed function code (which can be directly linked to the Gitea repository address, and the system will automatically pull the code); Select the object type information (including ObjectType name and version) associated with the current function from the registered ObjectType list displayed on the system front end; Fill in the basic function information (such as function name, version number, and description), and click the registration button. The front end will automatically encapsulate the request parameters and initiate the registration request. 2. API Interface Submission: Tenants initiate HTTP requests through the standardized interface exposed by the system: / api / v1 / functions / register. The request body encapsulates the following core parameters according to system specifications: Tenant Identifier: Tenant ID, used to associate with the subsequent dedicated computing cluster; Basic Function Information: Function name, version number, Gitea repository address (or directly upload the function code file); Function Code: Complete Python code text (including @function decorator, Docstring, and business logic); Object Type Information: Associated ObjectType name, version, and core field description (must be registered in the ontology service in advance).

[0027] The ontology service acts as the request receiver, listening to and receiving function registration requests submitted by tenants through the aforementioned channels, and generating a unique request ID for process tracing.

[0028] Optionally, the ontology service verifies whether the request body contains core content such as function code and object type information, and also verifies whether the parameter format conforms to system specifications (e.g., whether the function code contains the @function decorator, and whether ObjectType has been registered in the system). If core parameters are missing or the format is not standardized, a parameter error message is returned, and the registration process is terminated. The ontology service calls the RayClusterManager (cluster management service) component to query whether the target tenant has created a dedicated Ray cluster: If not, the registration request information is temporarily stored, and the status of the cluster to be bound is recorded to prepare for subsequent metadata binding to the cluster; if it has been created, the unique identifier of the cluster (e.g., cluster ID) is directly associated to ensure that subsequent function metadata is accurately bound to the tenant cluster. The ontology service stores the verified original registration request information (including function code, object type information, tenant ID, and request ID) in a dedicated database for subsequent metadata generation, process backtracking, and version management.

[0029] S12. Based on the function code and object type information, generate function metadata corresponding to the target function for storage.

[0030] In this embodiment, the ontology service obtains the function code from the function registration request, including the `@function` decorator, standardized Docstring comments, and complete business logic, as well as extracting object type information, namely, the ObjectType name, version, core attributes, and binding relationship description with the function defined by the OSDK. The ontology service parses the function's syntax structure using an AST (Abstract Syntax Tree), accurately extracting the function name, version number, input / output parameter types and default values, OSDK referenced modules, and ObjectType associated fields. Simultaneously, it combines Docstring to supplement semantic information such as parameter meanings, usage constraints, and dependency environment descriptions, forming a basic information set. Subsequently, in the compatibility verification stage, the system compares the ObjectType version associated with the function with the currently effective version in the ontology service, checks the matching degree between the function's required Python version, third-party library version, and the system's supported environment, generates version compatibility identifiers, dependency compatibility results, and other verification information, and completes management fields such as tenant ID, registration time, and metadata generation time to improve information dimensions.

[0031] Furthermore, the ontology service standardizes and formats all extracted and completed information according to the system's preset specifications, unifies field naming, data format and organization structure, and forms complete function metadata containing basic information, parameter information, ontology binding information, dependency information and verification information. This metadata is persistently stored in the ontology service's metadata database, and an index is established with tenant ID, function unique identifier and ObjectType name as the core.

[0032] In one possible implementation, the identity information, function code, and object type information of the target tenant are verified. After successful verification, function identification information for identifying the target function, parameter declaration information for describing the parameters of the target function, and function dependency information for describing the runtime dependencies of the target function are obtained. Based on the function identification information, parameter declaration information, function dependency information, and object type information, function metadata is generated. The object type information is used to characterize the field structure and field constraints of the objects referenced by the function parameters in the function code. The function code is stored in the code storage location and associated with the function identification information. The function metadata is stored in the function metadata storage location and associated with the function identification information.

[0033] In this embodiment, a three-layer verification is initiated first: Tenant identity verification confirms the tenant's registration status and permission validity by comparing the tenant identifier in the request with the system's certified identity database; Function code verification checks whether it contains the @function decorator, its syntax is correct, its Docstring is standardized, and whether it has been versioned in Gitea, while excluding malicious code and dependencies beyond the system's support range; Object type information verification confirms that it is based on the OSDK specification definition, and that the associated ObjectType has been registered in the ontology service, its version matches, and the object fields referenced by the function parameters are consistent with the ObjectType definition.

[0034] After successful verification, a unique function identifier (function ID) is automatically generated, which, combined with the extracted function name and version number, forms the function identification information. The function syntax structure is parsed using AST, and the names, types, default values, meanings, and constraints of the input / output parameters are extracted using Docstring to form parameter declaration information. By parsing the import statements in the code and the dependency descriptions in Docstring, function dependency information such as Python version and third-party libraries is obtained.

[0035] Based on function identification information, parameter declaration information, and function dependency information, and incorporating object type information representing the structure and constraints of fields referencing function parameters, and integrating fields such as tenant ID and registration time according to system specifications, complete function metadata is generated. Finally, the function code is stored in the Gitea repository and system backup storage location, establishing a connection through the function identification information; the function metadata is stored in the ontology service metadata database, using the function identification as the core index, while also associating with auxiliary indexes such as tenant ID and ObjectType name, achieving accurate mapping and fast retrieval between code and metadata.

[0036] S13. Create an independent computing cluster for the target tenant and bind the function metadata to the computing cluster.

[0037] In this embodiment, the independent computing cluster is a Ray (distributed computing framework) cluster exclusively allocated to the target tenant. It has independent worker nodes, runtime_env (a containerized Python environment that Ray uses to provide an independent dependency environment for each task or actor) cache space and actor pool, so as to achieve resource isolation and concurrency isolation with other tenants.

[0038] After the function metadata is generated and stored, the ontology service sends a cluster creation request to RayClusterManager (the cluster management service). The request carries the unique identifier of the target tenant (tenant ID) and the core index of the function metadata (function ID, associated ObjectType information). RayClusterManager first verifies the validity of the tenant's identity (compares it with the system tenant database to confirm it is not disabled and has cluster creation permissions) to prevent unauthorized tenants from occupying resources. RayClusterManager allocates independent computing resources based on the target tenant's business scale (default configuration or the tenant's preset resource requirements) and creates a dedicated Ray cluster for the target tenant. The cluster configuration follows resource isolation principles, including independent Worker nodes (used to execute function tasks), runtime_env cache space (stores the pre-loaded environment of the tenant's functions), and an Actor pool (supporting function residency in Session mode), ensuring that CPU and memory resources do not conflict between tenants and that concurrent tasks do not interfere with each other. After the cluster is created, RayClusterManager generates a unique cluster identifier (cluster ID), records core information such as the number of nodes, resource quotas, and network addresses, and establishes a one-to-one association between tenant ID and cluster ID in the system mapping library. At the same time, it maintains an association list of cluster ID and function ID to achieve precise binding between tenant, cluster, and function.

[0039] RayClusterManager synchronizes the cluster ID to the ontology service, which then adds the cluster ID to the target function's metadata and updates the cluster binding status of the metadata to "bound." Simultaneously, it establishes a query relationship indexed by the cluster ID in the metadata database. This ensures that when receiving subsequent function call requests, the corresponding dedicated cluster can be quickly located through the function metadata, providing a basis for function scheduling and execution. After binding, RayClusterManager continuously monitors the cluster's resource usage (such as CPU utilization, memory usage, and function call concurrency). It supports automatic or manual scaling operations based on the resource requirements declared in the function metadata and the tenant's actual call load, ensuring that cluster resources match the function execution requirements.

[0040] In one possible implementation, independent computing resources are allocated to the target tenant based on the tenant identifier of the target tenant, and a computing cluster is created based on the computing resources; the function metadata is associated with the cluster identifier of the computing cluster to establish a binding relationship between the target function and the computing cluster. The binding relationship is used to restrict the target function to be executed only in the computing cluster corresponding to the cluster identifier.

[0041] In this embodiment, RayClusterManager receives the target tenant identifier (tenant ID) from the ontology service. Combining this with the resource requirements declared in the function metadata, it allocates independent computing resources such as CPU and memory to the tenant and creates a dedicated computing cluster based on the Ray framework, ensuring resource isolation from other tenants. After cluster creation, RayClusterManager generates a unique cluster identifier (cluster ID) and stores the mapping relationship between the tenant identifier and the cluster identifier in the system mapping library. Simultaneously, the ontology service writes this cluster ID into the target function's metadata and establishes an associated storage in the metadata database. This association clearly defines the execution scope of the target function. When receiving subsequent function call requests, the system will accurately locate the corresponding dedicated computing cluster through the cluster identifier in the function metadata, ensuring that the target function is scheduled and executed only within that cluster, guaranteeing resource isolation and execution stability.

[0042] S14. Generate and cache the runtime environment for executing the target function based on the function metadata.

[0043] In this embodiment, the FunctionManager component, deployed on Ray Serve (Ray service deployment component), performs the preloading. After the function metadata is generated and cluster binding is completed, the ontology service sends a preloading notification to FunctionManager, carrying the function ID, function metadata, and corresponding cluster information. Based on the dependency information (Python version, third-party library list, system dependencies, etc.) in the metadata, FunctionManager clones the function code of the target function from the Gitea repository and accurately parses the dependencies required for function execution. Subsequently, FunctionManager calls Ray's runtime_env mechanism to build an independent containerized Python environment as the runtime environment according to the parsed dependencies. During the process, it automatically downloads and configures the corresponding dependency packages. After the runtime environment is built, FunctionManager caches it in the runtime_env cache space of the target tenant's dedicated Ray cluster, and records the association between the environment and the function ID.

[0044] In one possible implementation, a function preloading notification is sent to the function management service in the computing cluster to control the function management service to clone function code based on the function preloading notification and read the function dependency information recorded in the function metadata. Based on the function dependency information, a runtime environment for executing the target function is built in the computing cluster corresponding to the target tenant. After the runtime environment is built, an environment identifier is generated for the runtime environment. The runtime environment, function code and environment identifier are stored in the computing cluster, and the environment identifier is associated with the function metadata.

[0045] In this embodiment, the ontology service sends a function preloading notification to the function management service (FunctionManager) deployed on the Ray Serve in the cluster. Upon receiving the notification, FunctionManager first clones the complete code (including the @function decorator, Docstring, and business logic) of the target function from the code repository (Gitea) using the function identifier and stores it in the local code directory of the cluster. Then, it retrieves the function metadata through the metadata query index, reading the function dependency information, including the Python version, third-party library names and version numbers, and system dependent components. Subsequently, FunctionManager invokes Ray's runtime_env (Ray Runtime Environment, containerized Python environment) mechanism to build an independent runtime environment within the target tenant's dedicated computing cluster based on the parsed dependency information. During this process, it automatically downloads matching versions of dependency packages and configures environment variables to ensure that the environment is fully compatible with the function dependencies and is isolated from the runtime environments of other tenants.

[0046] After the runtime environment is built, FunctionManager automatically generates a unique environment identifier (environment ID) and stores the runtime environment, cloned function code, and environment identifier in the runtime_env cache space of the computing cluster, forming a mapping relationship between environment ID, runtime environment, and function code. At the same time, FunctionManager synchronizes the environment identifier to the ontology service, which writes the environment ID into the corresponding function metadata and updates the environment binding status of the metadata to ready, completing the association between the environment identifier and the function metadata, and providing a basis for quickly matching the runtime environment when calling functions in the future.

[0047] S15. Upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster to execute the target function according to the runtime environment.

[0048] In this embodiment, after receiving a function call request for the target function, the system first locates the target tenant's dedicated computing cluster (Ray cluster) using the cluster identifier in the function metadata. Then, it calls the function management service (FunctionManager) deployed on RayServe within that computing cluster. The FunctionManager matches the cached runtime environment (runtime_env) based on the function identifier and executes the target function within the matched runtime environment. The execution process supports concurrent scheduling, resource limits, and timeout control, and finally returns the execution result to the caller.

[0049] In one possible implementation, the function identifier information of the target function is obtained from the function call request, and function metadata is obtained based on the function identifier information; the running mode corresponding to the target function is obtained, and the running mode is used to characterize the execution method of the target function; the corresponding execution unit is selected in the computing cluster corresponding to the target tenant according to the running mode; the running environment corresponding to the target function is invoked, and the target function is executed on the execution unit in the computing cluster according to the function metadata.

[0050] In this embodiment, after receiving a function call request, the function identifier information (such as function ID) of the target function is first extracted. Then, based on the function identifier information, the corresponding function metadata is retrieved from the metadata database of the ontology service, including key information such as function dependencies, associated cluster identifiers, and runtime mode configurations. Based on the obtained function metadata, the preset runtime mode for the target function is parsed out. This mode is divided into Session mode (suitable for high-frequency calls, supporting Actor residency) and Job mode (suitable for low-frequency calls, temporarily creating execution units), clearly defining the execution method specifications for the function.

[0051] Based on the parsed operating mode, the corresponding execution unit is selected from the target tenant's dedicated computing cluster (Ray cluster) bound to the function metadata. Using the environment identifier in the function metadata, the corresponding cached operating environment in the cluster is invoked to load the function code into the selected execution unit. Combining the parameter declarations, dependency configurations, and other information in the function metadata, the target function is started to execute on the execution unit. During the process, concurrent scheduling, resource limits, and timeout control are supported, and the execution result is finally fed back to the caller.

[0052] In one possible implementation, selecting the corresponding execution unit within the computing cluster corresponding to the target tenant based on the operating mode includes: In session mode, the system checks whether the execution unit associated with the runtime environment has a cache hit. Session mode is suitable for scenarios with high-frequency function calls. If the cache is hit, the cached execution unit is directly called to execute the target function. If the cache is not hit, a new execution unit is created in the computing cluster, associated with the runtime environment and cached, and then the target function is executed through the new execution unit. In task mode, a temporary execution unit is created in the computing cluster corresponding to the target tenant to execute the target function, and the temporary execution unit is destroyed after the target function is executed. Task mode is suitable for scenarios with low-frequency function calls.

[0053] In this embodiment, the operating mode can include session mode and job mode, set as follows: 1. Tenant self-selection: When a tenant submits a function registration request on the KAX2.0 web page or through the / api / v1 / functions / register interface, they can independently specify the operating mode based on the function call frequency. High-frequency call scenarios (such as real-time data query, high-frequency business interaction) select session mode, and low-frequency call scenarios (such as scheduled report generation, batch data processing) select job mode. 2. System default adaptation: If the tenant does not actively specify, the system will automatically allocate the mode based on the historical call records in the function metadata (if it is a new function, the operating environment will be allocated according to the default rules). By default, high-frequency potential scenarios with a call frequency greater than the first preset threshold (such as functions associated with the core business ObjectType) are set to session mode, and other scenarios are set to job mode. The selected operating mode will be written into the function metadata and stored in association with the function identifier, cluster identifier, and environment identifier for quick retrieval during subsequent calls.

[0054] The Session mode is adapted for high-frequency call scenarios. Its core relies on the Actor (execution unit) caching mechanism to improve response speed. The specific process is as follows: Upon receiving a function call request and confirming that the running mode is Session, the FunctionManager (function management service) deployed on Ray Serve initiates a verification. Based on the function identifier and environment identifier, it queries the Actor pool cache of the target tenant's dedicated computing cluster to determine whether there is a resident Actor (execution unit) associated with the running environment.

[0055] If a matching cached Actor is found, the target function is executed directly by calling that Actor. Because the Actor is already bound to the runtime environment and is in a resident state (retained for 30 minutes by default), there is no need to reinitialize the environment and load the code, and the execution latency can be controlled within 1 second, which meets the low latency requirements of high-frequency calls.

[0056] If no matching cached Actor is found, FunctionManager will create a new Actor in the tenant's Ray cluster as the execution unit, and associate and bind the Actor with the pre-cached runtime environment. Then, the new Actor will be stored in the cluster's Actor pool for caching (residing for 30 minutes by default). Finally, the target function will be executed through the new Actor to ensure that subsequent calls can directly hit the cache.

[0057] The Job pattern is adapted for low-frequency call scenarios. The specific process is as follows: Once the system confirms the running mode as Job, FunctionManager directly creates a temporary Actor in the target tenant's dedicated Ray cluster, based on a pre-cached runtime environment. This Actor allocates resources exclusively for the current function call and is not included in the cluster Actor pool cache. The temporary Actor loads the function code and executes the target function, relying on independent cluster resources to complete the task during execution, supporting concurrent scheduling, resource limits, and timeout control. After the function execution is complete and returns a result, FunctionManager immediately destroys the temporary Actor, releasing the occupied CPU, memory, and other resources, preventing low-frequency function calls from occupying cluster resources for extended periods, and ensuring efficient utilization of cluster resources.

[0058] The function execution method provided in this invention achieves multi-dimensional core technical effects through a collaborative architecture of ontology service, cluster management service, function management service, and intelligent agent: On the one hand, the isolation design of one tenant per Ray cluster and the construction of an independent runtime_env environment completely solve the problems of resource contention and function dependency conflicts among multiple tenants. Combined with a dynamic scaling mechanism based on function metadata, it significantly improves cluster resource utilization and system stability. On the other hand, the automatic generation of metadata driven by AST+Docstring, function preloading, and Actor resident caching in Session mode significantly reduce function cold start latency, control the latency of secondary calls to within seconds, and support hot function updates without restarting the service, greatly optimizing the user experience in high-frequency call scenarios. In addition, the automatic parsing of function metadata and Tool Schema conversion by the intelligent agent realizes codeless automatic calling of functions by large models. Combined with standardized interfaces throughout the entire process and full lifecycle management of functions, it significantly reduces the threshold for function development, deployment, and calling, while taking into account the ease of use and scalability of the system.

[0059] Figure 2 The diagram shown is a structural schematic of a function execution system provided in an embodiment of the present invention. Used to implement Figure 1 The method described, such as Figure 2 As shown, the system specifically includes Ontology service 21 is used to receive a function registration request for a target function submitted by a target tenant. The function registration request includes function code and object type information associated with the function code. The ontology service is also used to verify the identity information of the target tenant, the function code, and the object type information. After the verification is passed, it generates function metadata corresponding to the target function based on the function code and the object type information, stores the function code and the function metadata, and sends a preloading notification to the function management service. Cluster management service 22 is used to create independent computing clusters for the target tenant, bind the function metadata to the cluster identifier of the computing cluster, and dynamically scale up or down the computing cluster based on the resource requirements and real-time call volume of the function metadata. The function management service 23 is deployed on the computing cluster to respond to the preloading notification, clone and load the function code, generate and cache the runtime environment for executing the target function according to the function metadata, and, upon receiving a function call request for the target function, call the runtime environment in the computing cluster corresponding to the target tenant and execute the target function according to the running mode corresponding to the target function. Intelligent agent 24 is used to query function metadata in the ontology service and convert it into a tool description structure that the large model can recognize, so as to drive the large model to automatically construct function call parameters for generating function call requests.

[0060] In this embodiment, the ontology service serves as the starting point for the function lifecycle, responsible for receiving function registration requests submitted by target tenants. These requests must include complete function code and associated object type information (based on the ObjectType defined in OSDK). Upon receiving the request, the ontology service first performs a comprehensive verification of the target tenant's identity validity, the standardization of the function code (e.g., whether it contains the @function decorator and whether the syntax is correct), and the legality of the object type information (whether it has been registered and the version matches). After successful verification, the ontology service parses the function code using an AST (Abstract Syntax Tree) combined with a Docstring, integrates the object type information (including field structure and constraints) to generate standardized function metadata, stores the function code in a Gitea repository (for version control), stores the function metadata in a dedicated database, and sends a function preloading notification to the function management service.

[0061] The cluster management service focuses on multi-tenant resource isolation and cluster control. For target tenants that have passed registration verification, it creates independent Ray computing clusters, ensuring that each tenant has its own dedicated Worker nodes, runtime_env cache, and Actor pool, achieving resource and concurrency isolation. Simultaneously, it binds function metadata to the unique identifier of the computing cluster, establishing a precise mapping between functions and clusters. Furthermore, based on the resource requirements declared in the function metadata and the real-time call volume of the target function by the tenant, it will automatically scale the computing cluster up or down, ensuring on-demand resource allocation and execution stability.

[0062] The function management service is deployed on the target tenant's dedicated computing cluster. Upon responding to the pre-loading notification from the ontology service, it clones and loads the target function code from the code repository. Based on the dependency information (Python version, third-party libraries, etc.) in the function metadata, it builds and caches an independent containerized runtime environment through Ray's runtime_env mechanism, significantly reducing the cold start latency of subsequent calls. When a function call request is received, the function management service first matches the cached runtime environment, and then executes the function according to the preset runtime mode in the function metadata: In Session mode (adapting to high-frequency calls), it prioritizes calling the cached resident Actor; if no match is found, it creates a new Actor and caches it; in Job mode (adapting to low-frequency calls), it creates a temporary Actor, which is destroyed immediately after execution. It also supports concurrent scheduling, resource limits, and timeout control.

[0063] The agent acts as a bridge between the large model and the function. By querying the function metadata in the ontology service, it calls the wrap_as_remote_tool tool to convert it into a Tool Schema that the large model can recognize. The agent then drives the large model to automatically construct function call parameters based on this structure, generating standardized function call requests. Ultimately, this enables the large model to make code-free remote calls to the target function and supports hot function updates.

[0064] Figure 3 This is a flowchart illustrating another function execution method provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the method specifically includes: Figure 3 This is the core flowchart for function lifecycle management in the KAX2.0 system. It clearly presents the complete chain from function writing, registration, execution to deactivation / deletion, as well as the linkage logic of various core components (Ontology APP (Ontology Service), RayClusterManager, Ray Service for function management, Agent application, etc.). It also highlights the core design of multi-tenant isolation and standardized interface calls. The specific content is as follows: I. Core Participating Entities The key roles and components involved in the diagram include: KAX 2.0 WEB page (tenant operation entry point), VS Code page (function writing tool), Ontology APP (ontology service carrier), RayClusterManager (cluster management service component), Ray Service (deployed in each tenant Ray cluster), multi-tenant independent Ray cluster (tenant 1 to tenant n clusters, achieving resource isolation), and Agent application (intelligent invocation carrier).

[0065] II. Core Process Links (in sequence and logical order) Function writing: Tenants write functions through the VS Code page, and after completion, they initiate a function registration request by calling the interface / api / v1 / functions / register.

[0066] Registration and Cluster Processing: When the Ontology APP receives a registration request, it saves the function information to itself for lifecycle management. On the other hand, it performs three operations: 1. Verify whether a Ray cluster has been created under the tenant; 2. Maintain the mapping relationship between tenants and clusters; 3. Call the RayClusterManager interface to obtain the cluster information of the function running. If the tenant has not created a cluster, it will automatically create one.

[0067] Metadata and function details retrieval: The Ontology APP calls the Ray Service interface deployed on the Ray cluster to obtain function metadata information; subsequently, whether it is a tenant operation or a system call, the function details can be queried through the interface / api / v1 / functions / info.

[0068] Function execution triggering method: Manual triggering: Tenants can initiate an execution request via the "Function Execution" button on the KAX 2.0 WEB page, or via ActionType (only functions related to the ontology are supported) / api / v1 / functions / execute; Automatic triggering: The Agent application first calls the ontology service to obtain available functions, and then encapsulates the functions into its own tools through the public utility methods provided by the ontology. The execution request is triggered when the tools are used subsequently.

[0069] Function execution and result return: After receiving the execution request, the Ray Service, which manages functions, parses the function metadata, performs dependency resolution, executes the function in the Ray cluster of the corresponding tenant through the / execute interface, and finally returns the execution result to the triggering end (tenant or agent application).

[0070] Function deactivation / deletion: Tenants can deactivate functions by calling the interface / api / v1 / functions / disable, or delete functions by calling / api / v1 / functions / delete, thus completing the function lifecycle loop.

[0071] The function execution method provided by this invention achieves tenant isolation and dependency decoupling, reduces function startup latency, supports hot updates and intelligent calls, and improves resource utilization and system usability.

[0072] Figure 4 This is a schematic diagram of the structure of a function execution device provided in an embodiment of the present invention, such as... Figure 4 As shown, the device specifically includes: Receiving module 41 is used to receive a function registration request for a target function submitted by a target tenant. The function registration request includes function code and object type information associated with the function code. The first generation module 42 is used to generate function metadata corresponding to the target function based on the function code and the object type information, for storage. Module 43 is used to create an independent computing cluster for the target tenant and bind the function metadata to the computing cluster; The second generation module 44 is used to construct and cache the runtime environment for executing the target function based on the function metadata; The execution module 45 is configured to, upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster to execute the target function according to the runtime environment.

[0073] In one possible implementation, the first generation module is specifically used to verify the identity information of the target tenant, the function code, and the object type information; After the verification is passed, obtain the function identification information used to identify the target function, the parameter declaration information used to describe the parameters of the target function, and the function dependency information used to describe the execution dependencies of the target function; Based on the function identifier information, the parameter declaration information, the function dependency information, and the object type information, the function metadata is generated. The object type information is used to characterize the field structure and field constraints of the objects referenced by the function parameters in the function code. The function code is stored in the code storage location, and the function code is associated with the function identification information. The function metadata is stored in the function metadata storage location, and the function metadata is associated with the function identification information.

[0074] In one possible implementation, the creation module is specifically used to allocate independent computing resources to the target tenant based on the tenant identifier of the target tenant, and to create the computing cluster based on the computing resources; The function metadata is associated with the cluster identifier of the computing cluster to establish a binding relationship between the target function and the computing cluster. The binding relationship is used to restrict the target function to be executed only in the computing cluster corresponding to the cluster identifier.

[0075] In one possible implementation, the second generation module is specifically used to send a function preloading notification to the function management service in the computing cluster, so as to control the function management service to clone the function code based on the function preloading notification and read the function dependency information recorded in the function metadata, so as to build a runtime environment for executing the target function in the computing cluster corresponding to the target tenant according to the function dependency information; After the runtime environment is built, an environment identifier is generated for the runtime environment, and the runtime environment, the function code and the environment identifier are stored in the computing cluster accordingly, and the environment identifier is associated with the function metadata.

[0076] In one possible implementation, the execution module is specifically configured to obtain the function identifier information of the target function from the function call request, so as to obtain the function metadata based on the function identifier information; Obtain the running mode corresponding to the objective function, wherein the running mode is used to characterize the execution mode of the objective function; Based on the operating mode, the corresponding execution unit is selected in the computing cluster corresponding to the target tenant; The runtime environment corresponding to the target function is invoked, and the target function is executed on the execution unit in the computing cluster according to the function metadata.

[0077] In one possible implementation, the execution module is further configured to determine whether the execution unit associated with the running environment has hit the cache when the running mode is session mode, wherein the session mode is adapted to scenarios with high frequency function calls; If the cache is hit, the cached execution unit is directly invoked to execute the target function. If the cache is not hit, a new execution unit is created in the computing cluster, the new execution unit is associated with the runtime environment and cached, and then the target function is executed through the new execution unit. When the running mode is task mode, a temporary execution unit is created in the computing cluster corresponding to the target tenant to execute the target function, and the temporary execution unit is destroyed after the target function is executed. The task mode is adapted to scenarios with low-frequency function calls.

[0078] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 5 The computer device 500 shown includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the computer device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 5 The general designated all buses as Bus System 505.

[0079] The user interface 503 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0080] It is understood that the memory 502 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0081] In some implementations, memory 502 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 5021 and application program 5022.

[0082] The operating system 5021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 5022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 5022.

[0083] In this embodiment of the invention, by calling the program or instructions stored in memory 502, specifically the program or instructions stored in application program 5022, processor 501 executes the method steps provided in each method embodiment, including, for example: Receive a function registration request for a target function submitted by the target tenant. The function registration request includes function code and object type information associated with the function code. Based on the function code and the object type information, function metadata corresponding to the target function is generated for storage. Create a separate computing cluster for the target tenant, and bind the function metadata to the computing cluster; A runtime environment for executing the target function is generated and cached based on the function metadata; Upon receiving a function call request for the target function, the runtime environment is invoked in the computing cluster to execute the target function according to the runtime environment.

[0084] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 501 or by instructions in the form of software. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 502. Processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method.

[0085] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0086] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0087] The computer device provided in this embodiment may be as follows: Figure 5 The device shown can perform, for example Figure 1 The function executes all steps of the method, thereby achieving... Figure 1 For details on the technical effects of the function execution method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0088] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0089] When one or more programs in the storage medium can be executed by one or more processors to implement the function execution method described above that is executed on the device side.

[0090] The processor is used to execute a function execution program stored in memory to implement the following steps of a function execution method executed on the device side: Receive a function registration request for a target function submitted by the target tenant. The function registration request includes function code and object type information associated with the function code. Based on the function code and the object type information, function metadata corresponding to the target function is generated for storage. Create a separate computing cluster for the target tenant, and bind the function metadata to the computing cluster; A runtime environment for executing the target function is generated and cached based on the function metadata; Upon receiving a function call request for the target function, the runtime environment is invoked in the computing cluster to execute the target function according to the runtime environment.

[0091] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0092] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0093] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A function execution method characterized by, include: Receive a function registration request for a target function submitted by the target tenant. The function registration request includes function code and object type information associated with the function code. Based on the function code and the object type information, function metadata corresponding to the target function is generated for storage. Create a separate computing cluster for the target tenant, and bind the function metadata to the computing cluster; A runtime environment for executing the target function is generated and cached based on the function metadata; Upon receiving a function call request for the target function, the runtime environment is invoked in the computing cluster to execute the target function according to the runtime environment.

2. The method according to claim 1, characterized in that, The step of generating function metadata corresponding to the target function based on the function code and the object type information for storage includes: The identity information of the target tenant, the function code, and the object type information are verified. After the verification is passed, obtain the function identification information used to identify the target function, the parameter declaration information used to describe the parameters of the target function, and the function dependency information used to describe the execution dependencies of the target function; Based on the function identification information, the parameter declaration information, the function dependency information, and the object type information, the function metadata is generated. The object type information is used to characterize the field structure and field constraints of the object referenced by the function parameters in the function code. The function code is stored in the code storage location, and the function code is associated with the function identification information. The function metadata is stored in the function metadata storage location, and the function metadata is associated with the function identification information.

3. The method according to claim 1, characterized in that, The step of creating an independent computing cluster for the target tenant and binding the function metadata to the computing cluster includes: Based on the tenant identifier of the target tenant, allocate independent computing resources to the target tenant, and create the computing cluster based on the computing resources; The function metadata is associated with the cluster identifier of the computing cluster to establish a binding relationship between the target function and the computing cluster. The binding relationship is used to restrict the target function to be executed only in the computing cluster corresponding to the cluster identifier.

4. The method according to claim 1, characterized in that, The step of generating and caching the runtime environment for executing the target function based on the function metadata includes: Send a function preloading notification to the function management service in the computing cluster to control the function management service to clone the function code based on the function preloading notification and read the function dependency information recorded in the function metadata, so as to build a runtime environment for executing the target function in the computing cluster corresponding to the target tenant according to the function dependency information; After the runtime environment is built, an environment identifier is generated for the runtime environment, and the runtime environment, the function code and the environment identifier are stored in the computing cluster accordingly, and the environment identifier is associated with the function metadata.

5. The method according to claim 1, characterized in that, The step of invoking the runtime environment in the computing cluster to execute the target function according to the runtime environment includes: Obtain the function identifier information of the target function from the function call request, and obtain the function metadata based on the function identifier information; Obtain the running mode corresponding to the objective function, wherein the running mode is used to characterize the execution mode of the objective function; Based on the operating mode, the corresponding execution unit is selected in the computing cluster corresponding to the target tenant; The runtime environment corresponding to the target function is invoked, and the target function is executed on the execution unit in the computing cluster according to the function metadata.

6. The method according to claim 5, characterized in that, The step of selecting the corresponding execution unit in the computing cluster corresponding to the target tenant according to the operating mode includes: When the running mode is session mode, it is determined whether the execution unit associated with the running environment has hit the cache. The session mode is suitable for scenarios with high-frequency function calls. If the cache is hit, the cached execution unit is directly invoked to execute the target function. If the cache is not hit, a new execution unit is created in the computing cluster, the new execution unit is associated with the runtime environment and cached, and then the target function is executed through the new execution unit. When the running mode is task mode, a temporary execution unit is created in the computing cluster corresponding to the target tenant to execute the target function, and the temporary execution unit is destroyed after the target function is executed. The task mode is adapted to scenarios with low-frequency function calls.

7. A function execution system, characterized in that, To implement the method of claim 1, the method comprises: The ontology service is used to receive function registration requests for target functions submitted by target tenants. The function registration request includes function code and object type information associated with the function code. The ontology service is also used to verify the identity information of the target tenant, the function code, and the object type information. After the verification is passed, it generates function metadata corresponding to the target function based on the function code and the object type information, stores the function code and the function metadata, and sends a preloading notification to the function management service. The cluster management service is used to create independent computing clusters for the target tenant, bind the function metadata to the cluster identifier of the computing cluster, and dynamically scale the computing cluster based on the resource requirements and real-time call volume of the function metadata. The function management service is deployed on the computing cluster to respond to the preloading notification, clone and load the function code, generate and cache the runtime environment for executing the target function based on the function metadata, and, upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster corresponding to the target tenant and execute the target function according to the running mode corresponding to the target function. An intelligent agent is used to query function metadata in the ontology service, convert it into a tool description structure that the large model can recognize, and drive the large model to automatically construct function call parameters for generating function call requests.

8. A function execution device, characterized in that, include: The receiving module is used to receive a function registration request for a target function submitted by a target tenant. The function registration request includes function code and object type information associated with the function code. The first generation module is used to generate function metadata corresponding to the target function based on the function code and the object type information, for storage purposes; A creation module is used to create an independent computing cluster for the target tenant and bind the function metadata to the computing cluster; The second generation module is used to construct and cache the runtime environment for executing the target function based on the function metadata; An execution module is configured to, upon receiving a function call request for the target function, invoke the runtime environment in the computing cluster to execute the target function according to the runtime environment.

9. A computer device, characterized in that, include: A processor and a memory, the processor being configured to execute a function execution program stored in the memory to implement the function execution method according to any one of claims 1 to 6.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the function execution method according to any one of claims 1 to 6.

Images