Software calling method, device and electronic equipment

Abstract

The application provides a software calling method and device and electronic equipment, and relates to the technical field of computers.The method comprises the following steps: receiving a task request, the task request carrying user session information; determining a target software component from a target software library according to the task request, and loading a software component file corresponding to the target software component; wherein the target software library comprises software components with different functions; determining a real execution entry according to the task request and a runtime takeover relationship table, the runtime takeover relationship table comprising a mapping relationship between the real execution entry and a software component name; generating an execution context according to the target software component, the software component file, the real execution entry and the user session information; calling the target software component to respond to the task request based on the execution context, and obtaining an execution result.The scheme not only improves the accuracy and safety of task execution, but also significantly enhances the maintainability and evolution flexibility of the system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a software invocation method, apparatus and electronic device. Background Technology

[0002] Currently, when upper-layer applications of the system perform certain tasks, they often need to call some software components to complete the task processing. After receiving a task request, the system often directly calls a pre-defined software component, or performs simple matching and scheduling among multiple software components.

[0003] However, as the number of software components continues to increase and system functions continue to iterate and evolve, the process of calling software components has become more complex and varied, and traditional methods of calling software components can no longer meet users' needs. Summary of the Invention

[0004] This application provides a software invocation method, apparatus, and electronic device that can improve the efficiency of software component invocation.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a software invocation method, the method comprising: Receive a task request, which carries user session information; Based on the task request, the target software component is determined from the target software library, and the corresponding software component file is loaded; the target software library includes various software components with different functions. The actual execution entry point is determined based on the task request and the runtime takeover relationship table, which includes the mapping relationship between the actual execution entry point and the name of the software component. An execution context is generated based on the target software component, the software component file, the actual execution entry point, and the user session information. The target software component is then invoked to respond to the task request based on the execution context, and the execution result is obtained.

[0006] Based on the aforementioned technical methods, the target software components are first selected from the target software library through task requests, and their corresponding software component files (software component contract files and reference files) are loaded accordingly. This establishes clear parameter boundaries and execution condition constraints before execution. Then, the actual execution entry point is determined using a runtime takeover table. Based on this, an execution context is generated, containing key information such as operator identity, role, project scope, capability scope, tracking identifiers, and output boundaries, according to the target software component, software component files, the actual execution entry point, and user session information. This ensures the task runs in a controlled environment. Finally, the target software component is invoked to respond and execute the task based on the execution context. This solution not only improves the accuracy and security of task execution but also significantly enhances the system's maintainability and evolutionary flexibility.

[0007] In one embodiment, determining the target software component from the target software library based on the task request includes: Based on the task request, a set of candidate software components is determined from the target software library; wherein, the set of candidate software components includes a list of candidate software component names, which contains the names of the candidate software components associated with the task request; The target software component is determined from the candidate software components indicated by the list of candidate software component names.

[0008] Based on the aforementioned technical means, task information such as task words, action words, and object words are extracted from the task request and compared with the software component summary information in the target software library to filter out a set of candidate software components associated with the current task request. This achieves preliminary screening of software components that may execute the task, avoiding the inefficiency caused by directly traversing all software components. Then, based on factors such as the status and matching degree of the software components in the candidate software component set, the final target software component is further determined, making the task matching process more targeted and controllable, and improving the accuracy of software component invocation and system response efficiency.

[0009] In one embodiment, the target software library includes a software component catalog index, which includes metadata describing the description information of each software component in the target software library; determining a set of candidate software components from the target software library according to the task request includes: Based on the software component catalog index, generate software component summary information for each software component in the target software library, and obtain a set of software component summaries; Extract task information from the task request; the task information includes at least one of task terms, action terms, and object terms. Based on the task information, traverse the software component summary set to determine the candidate software component set.

[0010] In one embodiment, the software component summary information includes at least: software component name, software component alias, trigger word, descriptive keywords, applicable task type, and operating restrictions.

[0011] In one embodiment, determining the target software component from the candidate software components indicated by the candidate software component name list includes one of the following: The target software component is determined based on the matching degree, software component status, and runtime takeover relationship table corresponding to each candidate software component; where the matching degree refers to the degree of matching between the task request and the software component summary information of the candidate software component; Display the software component path and parameters of each candidate software component in the list of candidate software component names; determine the target software component based on the software component path and parameters of each candidate software component.

[0012] In one embodiment, loading the software component file corresponding to the target software component includes: Load the software component contract file and reference file corresponding to the target software component; the software component contract file represents the calling rules of the target software component, and the reference file represents the background content that the target software component needs to refer to at runtime.

[0013] In one embodiment, determining the actual execution entry point based on the task request and the runtime takeover relationship table includes: Obtain the call name corresponding to the target software component from the task information. The call name includes one of the following: the historical alias of the target software component, the compatible alias of the old software component, the unified entry name, and the actual name of the executed software component. The actual execution entry point is determined by traversing the runtime takeover table based on the call name.

[0014] In one embodiment, an execution context is generated based on the target software component, the software component file, the actual execution entry point, and user session information, including: Obtain the session identifier from the user session information; Based on the session identifier, session pairing is performed from historical data, and historical session information corresponding to the session identifier is obtained from historical data; An execution context is generated based on the target software component, the software component file, the actual execution entry point, and the historical session information corresponding to the session identifier.

[0015] Secondly, embodiments of this application also provide a software invocation device, the device comprising: The receiving module is used to receive task requests, which carry user session information. The processing module is used to determine the target software component from the target software library according to the task request, and load the corresponding software component file; wherein, the target software library includes a variety of software components with different functions; determine the actual execution entry point according to the task request and the runtime takeover relationship table, which includes the mapping relationship between the actual execution entry point and the software component name; generate an execution context according to the target software component, the software component file, the actual execution entry point and the user session information, call the target software component to respond to the task request based on the execution context, and obtain the execution result.

[0016] Thirdly, embodiments of this application also provide an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the software invocation method as described in any of the above embodiments.

[0017] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program or computer-executable instructions, wherein when the computer program or computer-executable instructions are executed by a processor, the steps of the software invocation method as described in any of the above embodiments are implemented.

[0018] Fifthly, embodiments of this application provide a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the software invocation method as described in any of the above embodiments are implemented.

[0019] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0020] Figure 1 This is a structural block diagram of a software calling device provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a software invocation method provided in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating a method for determining a target software component according to an embodiment of this application; Figure 4 This is a flowchart illustrating a method for determining the actual execution entry point provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a method for generating an execution context provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a software invocation method provided in an embodiment of this application. Figure 2; Figure 7 This is a logic block diagram of a software calling device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0023] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0024] It should also be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0025] Furthermore, the reference to "embodiment" herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] Currently, when upper-layer applications of the system perform certain tasks, they often need to call some software components to complete the task processing. After receiving a task request, the system often directly calls a pre-defined software component, or performs simple matching and scheduling among multiple software components.

[0027] The following pain points exist in using the target software library: (1) Environment configuration issues. Different programming languages ​​require pre-configuration for compatibility. For example, if a software component uses Python and the upper-level application uses C++, the Python environment needs to be pre-configured when the upper-level application calls the Python software component. This cumbersome process of configuring the environment every time a software component is called is caused by the need for pre-configuration. (2) Software component call errors. When the upper-level application calls a software component from the target software library, it does not understand the functions of each component, leading to frequent call errors. (3) Different software components in the target software library may be written by different authors with different habits, resulting in different input and output definitions for different components. The upper-level application needs to confirm each component individually during the call, which is inefficient.

[0028] In addition, as the number of software components continues to increase, the process of calling software components becomes more complex and variable, exposing technical problems such as lack of clear constraints before execution, poor compatibility between old and new entry points, non-closed execution context, and insufficient session stability.

[0029] For example, when faced with complex task requests, the system often cannot effectively select the most suitable software component, which can easily lead to incorrect calls; when the system is upgraded or refactored, historical call paths may become invalid, resulting in compatibility interruptions; at the same time, due to the lack of a unified execution context management mechanism, key information such as operator identity, permission scope, and project boundaries are difficult to maintain throughout the task execution process, affecting security.

[0030] To address the aforementioned technical problems, this application proposes a software invocation method. This method includes: receiving a task request carrying user session information; determining a target software component from a target software library based on the task request, and loading the corresponding software component file; wherein the target software library includes various software components with different functions; determining the actual execution entry point based on the task request and a runtime takeover relationship table, the runtime takeover relationship table including the mapping relationship between the actual execution entry point and the software component name; generating an execution context based on the target software component, the software component file, the actual execution entry point, and the user session information; invoking the target software component to respond to the task request based on the execution context, and obtaining the execution result. This method first filters the target software component from the target software library through the task request and loads its corresponding software component file (software component contract file and reference file) based on the target software component, thereby establishing clear parameter boundaries and execution condition constraints before execution. Then, the actual execution entry point is determined using a runtime takeover table. Based on this, an execution context is generated, containing key information such as operator identity, role, project scope, capability scope, tracking identifier, and output boundaries, according to the target software component, software component files, the actual execution entry point, and user session information. This ensures that the task runs in a controlled environment. Finally, the target software component is invoked to respond and execute the task based on the execution context. This approach not only improves the accuracy and security of task execution but also significantly enhances the system's maintainability and evolutionary flexibility.

[0031] The various embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0032] The execution subject of the software invocation method provided in this application embodiment can be an electronic device, such as a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, artificial intelligence (AI) phone, AI terminal, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. In some possible implementations, the electronic device can also be a server, server cluster, cloud server, etc.

[0033] The software invocation methods provided in the embodiments of this application can be executed by a processor or a chip with processing capabilities in an electronic device, wherein a target software library is pre-deployed in the electronic device. The processor or chip with processing capabilities in the electronic device integrates a computing system, which can receive task requests from users and invoke target software components from the target software library in response to the task requests.

[0034] In another embodiment of this application, a target model can be deployed in the electronic device. During a dialogue between the user and the target model, the target model obtains a task request based on the dialogue content, and in response to the task request, determines the target software component from the target software library, loads the corresponding software component file, and determines the actual execution entry point according to the runtime takeover relationship table, generating an execution context. Based on this, the target model can call the target software component to execute tasks in the controlled environment corresponding to the execution context, and display the execution results fed back by the target software component to the user.

[0035] In this embodiment, the target model can also be a cloud model. The electronic device can display the user port of the cloud model to the user, and the user can communicate with the cloud model through the user port. The cloud model can obtain task requests based on the content of the communication and can execute the software invocation method provided in this embodiment.

[0036] The target model can be a large or small AI (Artificial Intelligence) model. The large model can be a general-purpose large model, such as a general-purpose large language model (LLM), a visual large model, a multimodal large model, etc., or it can be an expert large model obtained by fine-tuning a general-purpose large model based on requirements. This application does not limit this. The large model learns the features and patterns of the input information by training on a large amount of diverse data. It typically has hundreds of millions to hundreds of billions of model parameters (such as the weights corresponding to the model network layers, used to control model behavior), and can capture complex relationships and patterns in the input information for accurate and efficient reasoning / computation.

[0037] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] Please refer to Figure 1 , Figure 1 This is a structural block diagram of a software invocation device provided in an embodiment of this application. The software invocation device includes: a task request receiving unit 101, a software component directory indexing unit 102, a candidate software component matching unit 103, a software component contract loading unit 104, a runtime takeover parsing unit 105, an execution context binding unit 106, a session repair unit 107, a task execution unit 108, and a result return and environment recovery unit 109. Wherein: The task request receiving unit 101 is used to receive task requests from the local console, message entry, or other request entry, and extract user session information such as task text, operation parameters, and request context.

[0039] The software component directory index unit 102 is used to read the software component directory index and form multiple software component summary information. Each software component summary information includes at least the software component name and description information, which are used to constitute the first round of candidate exposure content.

[0040] The candidate software component matching unit 103 is used to generate a set of candidate software components based on the matching relationship between the task request content and information such as software component names, trigger words, and descriptive keywords. The set of candidate software components may include a list of candidate software component names. The set does not directly expose the software component paths and all parameters of specific candidate software components; instead, it represents each candidate software component as a list of candidate software component names. The candidate software component matching unit 103 is also used to expose the software component paths and all parameters of specific candidate software components after determining the list of candidate software component names, in order to determine the target software component.

[0041] The software component contract loading unit 104 is used to load the software component file corresponding to the target software component after the target software component is determined. The software component file includes a software component contract file and a reference file. If the target software component is not yet in a loaded state, the loading process is automatically completed before execution.

[0042] The runtime takeover resolution unit 105 is used to read the runtime takeover relationship table, which includes the mapping relationship between the "actual execution entry point of the software component" and the "call name group". The call name group includes the historical alias of the target software component, the compatible alias of the old software component, the unified entry point name, and the actual name of the executed software component. When the task request hits the compatible alias of the old software component, it is redirected to the actual execution entry point, and the original old software component identifier is retained.

[0043] The execution context binding unit 106 is used to generate an execution context before execution and write the execution context into the execution environment. The execution context includes at least one or more of the following: operator identifier, operator role, client address, project scope, capability scope, tracking identifier, and output boundary. This ensures that the task runs in a controlled environment.

[0044] The session repair unit 107 is used to clean up unpaired tool calls in the historical messages before initiating a software component call again when the model tool call history is involved, and only retain the paired part.

[0045] The task execution unit 108 is used to call the execution software component or verification software component corresponding to the target software component based on the takeover parsing results, execution parameters and execution context, and generate task results, logs and output products.

[0046] The result feedback and environment restoration unit 109 is used to feedback the task results and restore the environment before execution after execution to avoid contamination of subsequent task execution.

[0047] The software invocation method provided in this application has at least the following beneficial effects: 1. By loading the software component contract file and reference file before execution, clear parameter boundaries and execution conditions are provided before execution, thereby reducing the risk of erroneous invocation, incorrect output, and unconstrained execution. 2. By using a runtime takeover relationship table, the execution interface of the software component, the compatible alias of the old software component, and the direct software component are uniformly resolved, enabling smooth migration in scenarios where new and old entry points coexist, and reducing system evolution costs. 3. By obtaining identity, role, project scope, capability scope, and tracking identifier through user dialogue information, and obtaining parameter boundaries and execution conditions through the software component file, an execution context is generated based on identity, role, project scope, capability scope, tracking identifier, parameter boundaries, execution conditions, and the actual execution entry point, ensuring that the task execution process is in a controlled environment. 4. By pairing and repairing tool calls (tool_calls) and tool (tool) responses, the execution stability in multi-turn conversation or model tool call scenarios is improved. 5. By forming a closed loop from request reception, target software component determination, contract loading, entry point takeover, context constraints, session repair to task execution, the overall reliability and engineering maintainability of the task execution system are improved.

[0048] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a software invocation method provided in an embodiment of this application. Figure 1 The method includes: Step 201: Obtain the task request, which carries user session information.

[0049] In this embodiment of the application, the task request receiving unit can receive task requests from the local console, message entry, or other request entry.

[0050] In some embodiments, the task request may be determined by the target model based on user input during a dialogue between the user and the target model. In other embodiments, the task request may be issued by the user through an upper-layer application.

[0051] The task request is typically transmitted in a structured data format, such as JSON or XML, which includes the task text, operation parameters, and user session information. The user session information includes at least the user identifier (such as user ID), current session ID, access token, role permissions, and project ownership, which are used for subsequent execution context construction and permission verification.

[0052] For example, in an enterprise-level automated operations and maintenance system, a user submits a request to query server status via a web interface. This request includes user session information such as user ID user_12345, session ID sess_67890, and the role of an operations and maintenance administrator. Similarly, in an intelligent customer service system, a customer sends a request to reset their password via a chatbot. This request includes user session information such as user ID cust_54321, session ID chat_11223, and the current device IP address.

[0053] In this embodiment of the application, after receiving a task request, the content of the task request can be parsed first, key fields can be extracted, and the integrity and legality of the task request can be verified to ensure the reliability of subsequent processing.

[0054] Step 202: Determine the target software component from the target software library according to the task request, and load the software component file corresponding to the target software component.

[0055] The target software library includes various software components with different functions. In the embodiments of this application, the software components may be, for example, scripts, software programs, source code, etc.

[0056] In the embodiments of this application, please refer to Figure 3 , Figure 3 This is a flowchart illustrating a method for determining a target software component according to an embodiment of this application. The method includes: Step 301: Determine a set of candidate software components from the target software library according to the task request. The set of candidate software components includes a list of candidate software component names.

[0057] The list of candidate software component names includes the names of the candidate software components associated with the task request.

[0058] In this embodiment, the target software library includes a software component directory index. This index is a global software component mapping table automatically generated by scanning the configuration files of each software component in the target software library. The index includes metadata describing the information of each software component in the target software library, used for quickly retrieving and locating all registered software components. In this embodiment, the software component directory index is automatically generated by the target software library at startup by scanning the software component directory and reading the configuration files of each software component.

[0059] The metadata for each software component includes its name, alias, trigger words, descriptive keywords, file location, contract file location, reference file location, actual execution entry point, whether it is obsolete, and whether it has been taken over by a new entry point. The core function of the software component directory index is to avoid reading all software component content one by one during task processing, thereby significantly improving matching efficiency.

[0060] Based on the software component catalog index, a software component summary can be generated for each software component, resulting in a set of software component summaries. The software component summary is an abstract summary of the registration information of a single software component (i.e., metadata describing the software component), rather than a summary of the program code itself. The software component summary includes the software component name, software component alias, trigger words, descriptive keywords, applicable task types, and operational limitations, and is used to constitute the initial round of candidate exposure content.

[0061] The target software library usually contains a large number of software components. By generating corresponding software component summary information for each software component, the software components can be matched in subsequent matching processes. This can simplify the software components and improve matching efficiency.

[0062] In this embodiment, task information can be obtained from the task request. The task information includes at least one of task terms, action terms, and object terms. Task terms describe the specific task type, such as query, generate, or modify; action terms refer to the specific operation performed to execute the task request, such as click, drag, or upload; and object terms point to the target entity or data object of the task, such as user information, order records, or configuration files. Task terms, action terms, and object terms together constitute the basic semantic unit of the task request.

[0063] In this process, the task information, such as task words, action words, and object words, are matched with the software component name, alias, trigger words, and descriptive keywords in each record (each software component summary information) in the software component summary set. This process is used to filter out software components with high relevance and form a candidate software component set.

[0064] For example, when the task request is to export sales reports, multiple candidate software components may be matched, such as sales report export software components, financial data aggregation software components, and monthly statistical analysis software components, forming a set of candidate software components. When the task request is to restart the database service, database management software components, system maintenance software components, etc., may be matched, forming a set of candidate software components.

[0065] In this embodiment, the candidate software component set is a list of software components that may be suitable for processing the task request, selected through preliminary matching of task information and summary information of each software component in the task request. The candidate software component set is not the final executed software component, but rather serves as an intermediate result for subsequently determining the target software component. In this embodiment, the software component path and parameters of specific candidate software components are not directly exposed in the candidate software component set; instead, each candidate software component is represented as a list of candidate software component names.

[0066] In this embodiment, the generation process of the candidate software component set can be based on a comprehensive evaluation of multiple dimensions: first, the matching score, which is the semantic similarity between the task information in the task request and the summary information of each software component; second, the software component status, excluding software components that have been marked as obsolete or unusable; and third, priority rules, such as retaining certain high-priority software components even if the matching degree is average.

[0067] For example, semantic matching can be performed on the fields of task information and software component summary information in a task request, a matching score can be calculated, and software component summary information with scores higher than a threshold can be filtered out to identify at least one candidate software component summary, ultimately forming a set of candidate software components. The software components corresponding to these candidate software component summary information are defined as candidate software components. This matching and filtering process can be completed within milliseconds, ensuring the system's response speed.

[0068] In some embodiments, the size of the candidate software component set can be capped, such as selecting the top N software components with the highest matching scores (N is a positive integer from 1 to 10, preferably 3), to avoid the candidate software component set becoming too large and causing a decrease in subsequent processing efficiency. The formation of the candidate software component set is lightweight, based only on the software component summary information, and does not involve the internal logic or complete code reading of the candidate software components. Therefore, the processing speed is fast and it is suitable for high-concurrency scenarios.

[0069] In this embodiment, by first determining a set of candidate software components from the target software library, rather than directly locating the target software component, the matching error rate caused by the large number of software components can be effectively reduced. This enables preliminary filtering of task requests, thereby reducing attempts to call invalid software components and ultimately improving the overall efficiency and accuracy of task execution.

[0070] Step 302: Determine the target software component from the candidate software components indicated by the candidate software component name list.

[0071] The target software component is the software component that this task request will actually call.

[0072] In one implementation, the target software component can be determined based on the candidate software components indicated by the candidate software component name list, combined with factors such as the degree of matching between the task request (task information) and the software component summary information corresponding to each candidate software component, the software component status, and the runtime takeover relationship table. Here, the software component status refers to whether the software component is in an executable state or a callable state.

[0073] Among these methods, the optimal software component can be selected as the target software component from the candidate software components based on factors such as matching degree, software component status, and runtime takeover relationship table using a weighted scoring mechanism.

[0074] In another possible implementation, the software component path and parameters of each candidate software component in the candidate software component name list can be displayed; the target software component can then be determined based on the software component path and parameters of each candidate software component.

[0075] In this embodiment, the software component paths and parameters of each candidate software component can be exposed for user selection. Since the candidate software components have undergone preliminary screening, their number is relatively small, and they are all software components related to the task request. Therefore, efficiency can be improved, screening difficulty reduced, and user selection can improve the accuracy of the match.

[0076] In one implementation, the target software component can also be determined with the assistance of a rules engine or machine learning model. For example, for fuzzy task requests, a large model can dynamically adjust the weights of candidate software components by combining historical execution records and user preferences, thereby selecting the target software component more accurately. Furthermore, when multiple highly matching candidate software components exist, a selection interface can pop up for the user to manually confirm the target software component, enhancing interactivity and flexibility. The selection interface allows users to choose the software component path and parameters of these highly matching candidate software components.

[0077] In this embodiment, by determining the target software component from the set of candidate software components, refined decision-making can be achieved based on preliminary screening. This ensures that the selected target software component best matches the current task request, thereby improving the success rate of task execution and user experience, and ultimately supporting efficient automated processing in complex and ever-changing business scenarios.

[0078] In this embodiment, once the target software component is determined, the corresponding software component file can be obtained based on the record of the target software component in the software component directory index, preparing for subsequent loading. Simultaneously, it can be checked whether the target software component and its file are already in a loading state; if not, the loading process is automatically triggered.

[0079] In this embodiment of the application, the software component file includes the software component contract file and reference file path corresponding to the target software component.

[0080] A software component contract file is a rule file corresponding to a target software component. It specifies the conditions under which the target software component can be invoked, the required input parameters, the constraints to be followed during execution, and the requirements for the output results. Essentially, the software component contract file is a calling rule specification for the target software component, ensuring that the target software component is clearly constrained before execution, avoiding disordered or erroneous invocations. The content of a software component contract file typically includes input parameter specifications, output format requirements, applicable scenarios, disabling conditions, and validation logic. This content is configured during software component development, registration, or deployment and stored in conjunction with the target software component. After identifying the target software component, the execution system automatically reads and loads the software component contract file based on the location of the contract file recorded in the software component directory index, thus establishing boundary constraints before execution.

[0081] Reference documents represent the background information required by the target software component during runtime. They are documents providing background knowledge, business specifications, or supplementary materials to support the operation of the target software component. The purpose of reference documents is to provide the necessary context or reference content for the execution of the target software component, helping it understand the task context, obtain required data, or follow specific business logic.

[0082] For example, when a target software component handles tasks involving internal enterprise processes, the reference documentation might include flowcharts, approval rules, and departmental responsibility descriptions. Unlike the software component contract file, the reference documentation does not specify invocation rules but rather provides the background knowledge required for execution. The software component contract file and the reference documentation together constitute the execution prerequisites for the target software component, respectively addressing how to invoke and how to execute it. In a real system, the reference documentation is also configured during software component registration, located through the software component directory index, and loaded synchronously after the target software component is determined.

[0083] In actual implementation, once the target software component is identified, the first step is to check whether the corresponding software component contract file and reference file are already loaded. If not, an automatic loading mechanism is triggered.

[0084] In this embodiment, the software component contract file and reference file can be read according to the file paths recorded in the software component directory index, and then cached in the current execution context. This process ensures that all necessary rules and background information are ready before the target software component is actually executed, thereby improving the accuracy and security of execution.

[0085] In this embodiment, the software component contract file and reference file corresponding to the target software component are loaded. This allows for the establishment of clear parameter boundaries and execution conditions before execution, thereby reducing the risk of erroneous calls and unconstrained execution, and ultimately improving the security, accuracy, and overall reliability of the task execution.

[0086] Step 203: Determine the actual execution entry point based on the task request and the runtime takeover relationship table.

[0087] The runtime takeover relationship table includes the mapping relationship between the actual execution entry point and the name of the software component.

[0088] In this embodiment, the runtime takeover table is a call substitution mechanism that exists in the form of a mapping table or configuration file, defining the mapping relationship between the "actual execution entry point of the software component" and the "call name group". The call name group includes historical aliases of the target software component, compatible aliases of old software components, unified entry point names, and the actual name of the executed software component. The runtime takeover table also includes priority and activation conditions.

[0089] In one implementation, please refer to Figure 4 , Figure 4 This is a flowchart illustrating a method for determining the actual execution entry point provided in an embodiment of this application. The method includes: Step 401: Obtain the original call name from the task request.

[0090] In this embodiment of the application, the task request can be analyzed to determine the call name carried or parsed by the current task request. The call name can be, for example, one of the following: a historical alias of the target software component, a compatible alias of an old software component, a unified entry point name, or the actual name of the executed software component.

[0091] Step 402: Match the original call name with the call name group in the runtime takeover table to determine the actual execution entry point.

[0092] In this embodiment of the application, the original call name (such as historical alias, compatible alias, unified entry name, execution software component name, call identifier, etc.) obtained from the current task request can be compared with the runtime takeover relationship table.

[0093] If the match is a unified entry name, it is considered a capability package entry call; if the match is a historical name or a compatible alias, it is considered an old software component compatible alias call; if the match is a current real software component name, it is considered a direct software component call.

[0094] For example, in a large e-commerce platform, the old software component Product Inventory Query_v1 is replaced by the new software component Product Inventory Query_v2, but some old systems still call version v1. The system automatically maps v1 requests to v2 through the runtime takeover relationship table, and retains Product Inventory Query_v1 as the original identifier.

[0095] Among them, the capability package entry point refers to the unified reception and distribution entry point of a certain type of related software components. It is responsible for receiving call requests externally and distributing them internally to specific execution software components. It does not directly complete the task itself, but as a scheduling center, it helps to reduce system coupling and improve scalability and maintainability.

[0096] By using a runtime takeover relationship table, a smooth migration can be achieved in scenarios where old and new entry points coexist, avoiding interruptions to historical calls due to interface changes.

[0097] The embodiments of this application can dynamically determine the most suitable actual execution entry point based on the original call name, realize unified management and intelligent routing of new and old interfaces, improve the flexibility and adaptability of the system, and thus improve the stability and reliability of task execution.

[0098] Step 204: Generate an execution context based on the target software component, software component file, actual execution entry point, and user session information; call the target software component to respond to the task request based on the execution context; and obtain the execution result.

[0099] In the embodiments of this application, the execution context includes at least one or more of the following key fields: actor ID, actor role, client address, allowed project scopes, allowed capability scopes, trace ID, and output boundary, to ensure that the task runs in a controlled environment.

[0100] Among these, information such as operator identifier, operator role, client address, project scope, capability scope, and tracking identifier can be obtained from user dialogue information, and information such as output boundary can be obtained from software component files.

[0101] The execution context is a set of runtime information surrounding the execution of this task, used to support the connection and control of subsequent execution steps. The execution context is not a global system state, but a temporary environment variable bound to the current task execution instance.

[0102] For example, in a project management system, the execution context includes information such as actor_id=proj_admin_001, actor_role=project manager, project_scope=project A, capability_scope=budget approval, progress viewing, and trace_id=exec_98765; similarly, in an AI assistant system, the execution context includes information such as actor_id=user_101, role=ordinary user, trace_id=chat_34567, and output_boundary=maximum response length 500 characters.

[0103] In this embodiment, after generating the execution context, the execution software component or verification software component corresponding to the target software component can be invoked to process the task based on the takeover resolution result, execution parameters, and execution context. In scenarios involving model tool call history, before subsequent task execution, the system uses a session repair unit to pair and repair the tool_calls in the assistant message with the tool_call_id in the tool response, deleting unpaired tool calls or isolated tool responses, eliminating structural errors, and ensuring the stability of multi-turn interactions.

[0104] For example, in a continuous dialogue scenario, a user may request to call a weather query tool multiple times, but if a call fails to receive a response, the system automatically cleans up unpaired `tool_call` calls before subsequent requests, retaining only the successfully paired ones to ensure uninterrupted execution. After task execution, the system outputs the execution results, logs, and execution artifacts, and uses a result feedback and environment recovery unit to send the task results back, while simultaneously restoring the environment variables from before execution to prevent contamination of subsequent tasks. This closed-loop design significantly improves the accuracy, security, and maintainability of task execution.

[0105] The software invocation method provided in this application receives a task request carrying user session information, uses a software component directory index to filter lightweight candidate software components, loads the target software component and its executable file, determines the actual execution entry point by combining runtime takeover relationships, and generates an execution context based on the target software component, executable file, actual execution entry point, and user session information. Finally, it calls the target software component to respond to the task request and outputs the result. The entire process forms a closed-loop control flow of software component contract loading—entry point takeover—context constraint—session repair—task execution, effectively solving problems such as lack of constraints before execution, poor compatibility between new and old entry points, broken execution context, and unstable sessions in the prior art. By introducing a software component contract file to establish pre-execution boundaries, a runtime takeover mechanism to achieve a smooth transition between new and old entry points, binding identity and permission information to the execution context to ensure controlled execution, and a session repair mechanism to ensure the continuity of multi-round interactions, the accuracy, security, and maintainability of task execution are significantly improved.

[0106] Based on the above embodiments, please refer to Figure 5 , Figure 5 This is a flowchart illustrating a method for generating an execution context according to an embodiment of this application. The method includes: Step 501: Obtain the session identifier from the user session information.

[0107] A session identifier is a string or numeric code that uniquely identifies a user session, typically generated by the target model during its interaction with the user. The session identifier remains unchanged throughout the entire session and is used to associate all operations, parameters, and state information within that session. For example, in a web application, the session identifier could be a SessionID. The purpose of the session identifier is to ensure that multiple parallel tasks or distributed components can share consistent context information, preventing execution errors caused by inconsistent state.

[0108] Session identification ensures accurate identification of the session corresponding to each request in multi-task concurrent scenarios, thereby enabling fine-grained control and audit tracking of the task execution process, and ultimately improving the stability and maintainability of the system.

[0109] Step 502: Perform session pairing from historical data based on session identifiers, and obtain historical session information corresponding to the session identifiers from the historical data.

[0110] Historical data refers to historical dialogue data, which is a collection of information related to a specific session recorded and stored during the execution of previous tasks. This includes, but is not limited to, session identifiers, call timestamps, execution parameters, tool call records, response results, and state change logs. Historical data is usually stored in a structured format (such as database tables, message queues, or cache storage) to support context continuation, error recovery, or performance analysis for subsequent tasks.

[0111] Session matching refers to the process of searching and matching previous session records with the same identifier in historical data based on the session identifier in the current request. The session matching process is typically completed quickly using index queries or hash mappings to ensure response efficiency. For example, the system can create an index using the session ID field in the database to directly locate the corresponding historical record set.

[0112] In this embodiment of the application, each tool_call identifier in the assistant message needs to be paired with the tool_call_id in the subsequent tool response; unpaired tool_calls can be removed from the message history; tool messages that cannot be matched with assistant tool_calls can be discarded directly.

[0113] In this embodiment, when a user initiates a new task request carrying a session identifier, the historical data warehouse can be automatically queried to find all historical interaction records corresponding to the session identifier. If there are incomplete tasks or unpaired tool calls, the historical session information corresponding to the extracted session identifier can be used as part of the current execution context to repair or continue the previous execution state.

[0114] This ensures that the system maintains contextual coherence during multi-turn dialogues or continuous task execution, avoiding system execution failures or logical confusion due to intermediate breakpoints, thereby enhancing the robustness of task execution and user experience.

[0115] Step 503: Generate an execution context based on the target software component, the software component file, the actual execution entry point, and the historical session information corresponding to the session identifier.

[0116] The execution context is a set of runtime information surrounding the execution of this task, used to support the smooth transition of subsequent execution steps. The execution context not only includes core elements such as the target software components, executable files, and the actual execution entry point of the current task, but also integrates historical session information corresponding to session identifiers obtained from historical data, such as operator identity, role, project scope, capability scope, tracking identifiers, and output boundaries. All of this information together constitutes a portable execution environment package, ensuring that the task runs within controlled boundaries.

[0117] The execution context may exist as structured data in the form of JSON, Java objects, or Python dictionaries, and is passed to subsequent execution units through environment variables, request context objects, or tokens. For example, before invoking the target software component, the structured execution context can be injected into function parameters or global configurations, enabling the software component to access all the necessary context information. This ensures that the task execution process is bound to the operator's identity, project boundaries, and capability boundaries, improving security and enabling closed-loop management and efficient collaboration of the task execution process.

[0118] In this embodiment, upon receiving a task request, the system iterates through the software component summary information of each software component in the target software library to determine a set of candidate software components. If the target software component is determined to be an old software component entry point, it does not directly call that old entry point before execution. Instead, it reads the runtime takeover strategy, maps it to a new capability package entry point, and retains the original old software component name in the parameters. Next, an execution context is generated, and the operator identifier, role, project scope, capability scope, and tracking identifier are written into the environment variables before executing the corresponding software component of the target software component. If the task chain involves model tool call history, before initiating a new model call, unpaired tool calls in the message history are cleaned up, retaining only the paired ones. After the task execution is completed, the system outputs the execution result and restores the environment variables from before execution.

[0119] Based on the above embodiments, the software calling method provided in this application embodiment will be described below in conjunction with specific implementation methods.

[0120] Please refer to Figure 6 , Figure 6 This is a flowchart illustrating a software invocation method provided in an embodiment of this application. Figure 2 The method includes: Step 601: Receive task request.

[0121] Step 602: Read the script directory index and generate a script summary set.

[0122] The script library includes a script directory index, which contains metadata describing the information of each script in the library. The metadata describing the information of each script is retrieved from the script directory index. Then, for each script, a script summary is generated based on the metadata describing its information. Combining the script summaries of all scripts yields a script summary set.

[0123] The script summary information should include at least the following: script name, script alias, trigger word, descriptive keywords, applicable task type, and execution restrictions.

[0124] Step 603: Match the candidate script set according to the task request, and determine the target script from it.

[0125] In this embodiment of the application, task information can be extracted from the task request; the task information includes at least one of task words, action words, and object words; the script summary set is traversed according to the task information to determine the candidate script set.

[0126] In other words, the script summary information is searched based on task words, action words, or object words. If the script summary information contains task words, action words, or object words, or contains information similar to task words, action words, or object words, then the script corresponding to the script summary information can be considered a candidate script, and the candidate script name is added to the candidate script name list.

[0127] The candidate script set includes a list of candidate script names, which contains the names of the candidate scripts associated with the task request.

[0128] In this embodiment of the application, determining the target script from the candidate scripts indicated by the candidate script name list includes one of the following: (1) determining the target script according to the matching degree, script status and runtime takeover relationship table corresponding to each candidate script; wherein, the matching degree refers to the degree of matching between the task request and the script summary information of the candidate script; (2) displaying the script path and script parameters of each candidate script in the candidate script name list; and determining the target script according to the script path and script parameters of each candidate script.

[0129] Step 604: Determine whether the target script's script file has been loaded; if not, load the target script contract and reference materials.

[0130] The target script contract represents the calling rules of the target script, while the reference file represents the background content that the target script needs to refer to at runtime.

[0131] Step 605: Analyze the runtime takeover strategy to determine whether the current request belongs to a capability package entry call, an old script compatibility alias call, or a direct script call.

[0132] In this embodiment, the call name corresponding to the target script can be obtained from the task information. The call name includes one of the following: the historical alias of the target script, the old script compatible alias, the unified entry name, and the actual execution script name. The actual execution entry point is determined by traversing the runtime takeover relationship table according to the call identifier.

[0133] Step 606: If an old script compatible alias is matched, redirect the task request to the capability package entry and retain the original script identifier (old script identifier).

[0134] Step 607: If the old script compatibility alias is not found, keep the capability package entry or the direct script entry and continue execution.

[0135] Step 608: Bind the execution context.

[0136] Information such as operator identity, role, project scope, capability scope, tracking identifier, and output boundaries are written into the execution environment.

[0137] Step 609: The repair tool retrieves historical messages.

[0138] If subsequent execution depends on the model tool call history, then the tool_calls recorded in the historical messages and the corresponding tool responses are paired and repaired.

[0139] In this embodiment of the application, a session identifier can also be obtained from the user session information; session pairing can be performed from historical data based on the session identifier, and historical session information corresponding to the session identifier can be obtained from the historical data; an execution context can be generated and bound based on the target script, script file, actual execution entry point and historical session information corresponding to the session identifier.

[0140] Step 610: Execute the target script, return the task results, and restore the environment before execution.

[0141] Call the target script, execute the script or the verification script, and output the execution results, log information, and artifacts generated during the execution process.

[0142] The script invocation method provided in this application differs from existing technologies not in introducing separate plugins, scripts, contexts, or message repair, but in forming a unified execution chain by organizing each step in a predetermined order. Specifically, a lightweight candidate filtering is first performed using a script directory index, and then the target script is determined from the candidate script set. Next, pre-execution constraints are formed through script contract loading. Based on this, a runtime takeover mechanism resolves compatibility issues when old and new entry points coexist. Subsequently, execution context binding ensures that the task runs within predetermined boundaries. Finally, a session repair mechanism ensures the stability of the historical message structure, thereby improving the overall task execution success rate and system maintainability.

[0143] It should be understood that the steps in the aforementioned accompanying drawings are not necessarily performed in the order indicated in the drawings. Unless otherwise expressly stated herein, there is no strict order restriction on the execution of these steps, and they may be performed in other orders. Moreover, at least some of the steps in these drawings may include multiple sub-steps or multiple stages, which are not necessarily completed at the same time, but may be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0144] In another embodiment of this application, a software invocation device is provided; please refer to [reference needed]. Figure 7 , Figure 7 This is a logical block diagram of a software invocation device provided in an embodiment of this application. The software invocation device 700 may include: a receiving module 701 and a processing module 702, wherein: The receiving module 701 is used to receive task requests, which carry user session information. The processing module 702 is used to determine the target software component from the target software library according to the task request, and load the software component file corresponding to the target software component; wherein, the target software library includes a variety of software components with different functions; determine the actual execution entry point according to the task request and the runtime takeover relationship table, the runtime takeover relationship table includes the mapping relationship between the actual execution entry point and the software component name; generate an execution context according to the target software component, the software component file, the actual execution entry point and the user session information, call the target software component to respond to the task request based on the execution context, and obtain the execution result.

[0145] In one embodiment, the processing module 702 is specifically used for: Based on the task request, a set of candidate software components is determined from the target software library; wherein, the set of candidate software components includes a list of candidate software component names, which contains the names of the candidate software components associated with the task request; The target software component is determined from the candidate software components indicated by the list of candidate software component names.

[0146] In one embodiment, the target software library includes a software component directory index, which includes metadata describing the description information of each software component in the target software library; the processing module 702 is specifically used for: Based on the software component catalog index, generate software component summary information for each software component in the target software library, and obtain a set of software component summaries; Extract task information from the task request; the task information includes at least one of task terms, action terms, and object terms. Based on the task information, traverse the software component summary set to determine the candidate software component set.

[0147] In one embodiment, the software component summary information includes at least: software component name, software component alias, trigger word, descriptive keywords, applicable task type, and operating restrictions.

[0148] In one embodiment, the processing module 702 is specifically used for: The target software component is determined based on the matching degree, software component status, and runtime takeover relationship table corresponding to each candidate software component; where the matching degree refers to the degree of matching between the task request and the software component summary information of the candidate software component; Display the software component path and parameters of each candidate software component in the list of candidate software component names; determine the target software component based on the software component path and parameters of each candidate software component.

[0149] In one embodiment, the processing module 702 is specifically used for: Load the software component contract file and reference file corresponding to the target software component; the software component contract file represents the calling rules of the target software component, and the reference file represents the background content that the target software component needs to refer to at runtime.

[0150] In one embodiment, the processing module 702 is specifically used for: Obtain the original call name from the task request; The original call name is matched with the call name group in the runtime takeover table to determine the actual execution entry point; the call name group includes the historical alias of the target software component, the compatible alias of the old software component, the unified entry point name, and the actual name of the executed software component.

[0151] In one embodiment, the processing module 702 is specifically used for: Obtain the session identifier from the user session information; Based on the session identifier, session pairing is performed from historical data, and historical session information corresponding to the session identifier is obtained from historical data; An execution context is generated based on the target software component, the software component file, the actual execution entry point, and the historical session information corresponding to the session identifier.

[0152] Each module in the aforementioned software invocation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the electronic device in hardware form or independent of it, or stored in the memory of the electronic device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0153] In yet another embodiment of this application, please refer to Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device may include a communication interface 801, a memory 802, and a processor 803; the various components are coupled together through a bus system 804. It is understood that the bus system 804 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus System 804.

[0154] In this embodiment, the communication interface 801 is used to send and receive information with other external devices; the memory 802 is used to store computer programs that can run on the processor 803; the processor 803 is used to execute the steps of the software invocation method described in any of the foregoing embodiments when running the computer program.

[0155] It is understood that the memory 802 in this embodiment 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 802 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0156] The processor 803 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 803 or by instructions in software form. The processor 803 can 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 this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can 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. This storage medium is located in memory 802, and the processor 803 reads the information in memory 802 and, in conjunction with its hardware, completes the steps of the above method.

[0157] It is also 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.

[0158] For software implementation, the techniques described herein can be implemented through modules (e.g., procedures, functions, etc.) that perform the functions described herein. Software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or externally. Wherein, if implemented as a software functional module and not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0159] In another embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the software invocation method described in the foregoing embodiments.

[0160] In another embodiment of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the software invocation method as described in the foregoing embodiments.

[0161] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, devices, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage and optical storage) containing computer-usable program code.

[0162] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0163] The sequence numbers of the embodiments in this application are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The features disclosed in the several product embodiments provided in this application can be arbitrarily combined to obtain new product embodiments without conflict. Similarly, the features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined to obtain new method or device embodiments without conflict. The above descriptions are merely specific implementations of this application, but the protection scope of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. A software invocation method, characterized in that, The method includes: Obtain a task request, the task request carrying user session information; Based on the task request, the target software component is determined from the target software library, and the software component file corresponding to the target software component is loaded; wherein, the target software library includes a variety of software components with different functions; The actual execution entry point is determined based on the task request and the runtime takeover relationship table, wherein the runtime takeover relationship table includes the mapping relationship between the actual execution entry point and the name of the software component; An execution context is generated based on the target software component, the software component file, the actual execution entry point, and the user session information. The target software component is then invoked to respond to the task request based on the execution context, and an execution result is obtained.

2. The method according to claim 1, characterized in that, The step of determining the target software component from the target software library according to the task request includes: A set of candidate software components is determined from the target software library according to the task request; wherein, the set of candidate software components includes a list of candidate software component names, and the list of candidate software component names contains the names of candidate software components associated with the task request; The target software component is determined from the candidate software components indicated by the list of candidate software component names.

3. The method according to claim 2, characterized in that, The target software library includes a software component directory index, which includes metadata describing the description information of each software component in the target software library; determining a set of candidate software components from the target software library according to the task request includes: Based on the software component directory index, generate software component summary information for each software component in the target software library to obtain a software component summary set; Extract task information from the task request; the task information includes at least one of task words, action words, and object words; The candidate software component set is determined by traversing the software component summary set based on the task information.

4. The method according to claim 3, characterized in that, The software component summary information includes at least: software component name, software component alias, trigger word, descriptive keywords, applicable task type, and running restrictions.

5. The method according to claim 3, characterized in that, Determining the target software component from the candidate software components indicated by the list of candidate software component names includes one of the following: The target software component is determined based on the matching degree, software component status, and runtime takeover relationship table corresponding to each candidate software component; wherein, the matching degree refers to the degree of matching between the task request and the software component summary information of the candidate software component; Display the software component path and software component parameters of each candidate software component in the candidate software component name list; determine the target software component based on the software component path and software component parameters of each candidate software component.

6. The method according to claim 1, characterized in that, The loading of the software component file corresponding to the target software component includes: Load the software component contract file and reference file corresponding to the target software component; wherein, the software component contract file represents the calling rules of the target software component, and the reference file represents the background content that the target software component needs to refer to during runtime.

7. The method according to claim 1, characterized in that, The step of determining the actual execution entry point based on the task request and runtime takeover relationship table includes: Obtain the original call name from the task request; The original call name is matched with the call name group in the runtime takeover relationship table to determine the actual execution entry point; the call name group includes the historical alias of the target software component, the compatible alias of the old software component, the unified entry point name, and the actual execution software component name.

8. The method according to claim 1, characterized in that, The step of generating an execution context based on the target software component, the software component file, the actual execution entry point, and the user session information includes: Obtain the session identifier from the user session information; Based on the session identifier, session pairing is performed from historical data, and historical session information corresponding to the session identifier is obtained from the historical data; The execution context is generated based on the target software component, the software component file, the actual execution entry point, and the historical session information corresponding to the session identifier.

9. A software calling device, characterized in that, The device includes: The receiving module is used to acquire a task request, wherein the task request carries user session information; The processing module is configured to: determine a target software component from a target software library based on the task request; load the software component file corresponding to the target software component; wherein the target software library includes various software components with different functions; determine the actual execution entry point based on the task request and a runtime takeover relationship table, the runtime takeover relationship table including the mapping relationship between the actual execution entry point and the software component name; generate an execution context based on the target software component, the software component file, the actual execution entry point, and the user session information; invoke the target software component to respond to the task request based on the execution context; and obtain the execution result.

10. An electronic device comprising a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the software invocation method as claimed in any one of claims 1 to 8.

Images