Plug-in based operation background management method, system, device and medium

Abstract

The application relates to the technical field of operation background management, and discloses an operation background management method, system, device and medium based on a plug-in structure. The method comprises the following steps: receiving a natural language operation instruction input by an operator through an interactive terminal and performing permission verification; analyzing the instruction to identify a business intention and parameters, and outputting a structured combination result; matching a target business plug-in in a business plug-in library based on the result, wherein the plug-in comprises a single function plug-in and a composite link plug-in with built-in link arrangement logic; loading and executing the plug-in, automatically serially calling a back-end interface or a single function plug-in according to the arrangement logic, and completing serial execution of a business link; and collecting execution data and feeding back a formatted result. The application replaces traditional front-end page development with standardized plug-in packaging, realizes automatic series connection of complex businesses by using the composite link plug-in, supports multi-terminal natural language interaction, and effectively solves the technical problems of high development cost, complicated operation and difficult expansion of a traditional operation background.

Description

Technical Field

[0001] This application relates to the field of operational back-end management technology, and in particular to an operational back-end management method, system, device and medium based on a plug-in structure. Background Technology

[0002] In the field of software product operation and management, traditional solutions generally rely on dedicated web-based operation backends. These backends typically use a browser frontend as the human-computer interaction medium, connecting the frontend and backend via interfaces to achieve operational functions such as data querying, business operations, and problem handling. However, this model suffers from numerous insurmountable technical flaws in practical implementation, hindering improvements in operational efficiency and rapid business iteration.

[0003] First, feature iteration is costly and time-consuming. Traditional operational backends employ a tightly coupled development model between backend interfaces and frontend pages. When adding or modifying an operational feature, not only is it necessary to develop the backend logic, but also to develop or adjust the frontend display page accordingly. This model offers extremely low cost-effectiveness for small projects and startups; moreover, the development and maintenance of the frontend pages consume a significant amount of R&D time, leading to delays in responding to operational needs.

[0004] Secondly, complex business scenarios are cumbersome to operate and have fragmented workflows. Traditional web backends typically have independent functional pages, lacking an automatic mechanism to link business processes. When handling complex business processes involving multiple stages, operations personnel need to manually navigate between multiple pages frequently, manually sorting and connecting the business logic. This manual relay-style operation is not only inefficient but also highly susceptible to human error, leading to omissions or data inconsistencies.

[0005] Secondly, the interactive terminal is singular and disconnected from office workflows. The existing operations backend relies almost entirely on web-based operations, making it impossible to directly initiate operational commands using commonly used office tools such as instant messaging (IM) tools and command-line terminals. Operations personnel must leave their current office context and log into a separate web backend to operate, resulting in a fragmented workflow and failing to meet the needs of real-time operational responses.

[0006] Finally, the system suffers from poor scalability, making it difficult for non-technical personnel to participate. Due to the lack of a standardized, lightweight functional expansion architecture, the expansion of the operations backend is often limited by R&D resources. Even non-technical operations personnel who are very familiar with the business processes cannot independently customize or adjust the operational logic. Any minor business change requires developers to modify the code and release a new version, making it impossible to quickly test and adjust operational strategies. Summary of the Invention

[0007] This application provides an operational backend management method, system, device, and medium based on a plug-in structure, aiming to solve the technical problems existing in the related technologies, such as heavy front-end development, fragmented business links, single interactive terminals, and difficulty for non-technical personnel to expand, resulting in slow operational iteration, low operational efficiency, and difficulty in integrating into daily office workflow.

[0008] In a first aspect, embodiments of this application provide an operation backend management method based on a plug-in structure, the method comprising: Receive natural language operation instructions input by operators through an interactive terminal, and perform identity authentication and operation permission verification on the operators; Natural language processing technology is used to parse the natural language operation instructions that have passed the permission verification, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and standardize the output of the structured combination of intent and parameters. Based on the structured combination of the intent and parameters, the corresponding target business plugin is matched in the pre-set business plugin library. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including single-function plugins for implementing atomic operation and composite link plugins for chaining multiple atomic operations to complete complex business processes. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules. Load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single function plugin in sequence according to the link orchestration logic to perform the business link chain execution in order to complete the corresponding backend operation. Collect context data and execution results during the execution of the target business plugin, and feed back the formatted execution results to the interactive terminal.

[0009] In one embodiment, optionally, the preset standardization specification adopts a writing paradigm that decouples declarative configuration from core logic code, specifically including: plugin configuration files and core logic code files; The plugin configuration file is used to define the plugin name, the business scenarios to be adapted, the mapping rules between natural language parameters and interface parameters, and the execution result formatting template. The core logic code file is configured with natural language parameter parsing functions, backend interface calling functions, result formatting processing functions, and a unified program entry function. Based on the program entry function, dynamic loading and calling of different business plugins are realized.

[0010] In one embodiment, optionally, the composite link plugin is further configured with a link association configuration file; The link association configuration file defines the link orchestration logic, including: link execution order, cross-link parameter passing rules, and exception handling strategy; The execution order of the link is used to define the serial calling order of multiple business links; The cross-stage parameter transfer rules are used to define how to map the output parameters of the previous business stage to the input parameters of the next business stage. Exception handling strategy, used to define the handling logic when an exception occurs during link execution.

[0011] In one embodiment, the exception handling strategy may optionally include at least one of the following: terminating the current link process, retrying the current business step, and skipping the current unnecessary business step to continue executing the subsequent process; The step of executing the business chain in sequence also includes: when any business link fails to be called, performing the corresponding operation according to the exception handling strategy, and capturing exception information for result feedback.

[0012] In one embodiment, optionally, the method further includes: Traverse and scan the preset plugin storage path, load the plugin configuration file of each business plugin to obtain metadata information, the metadata information includes the business scenarios adapted to the business plugin; Construct an index mapping relationship between the business scenarios and business plugins to enable query matching based on target business intents obtained from natural language parsing; Add business plugins with index mapping relationships to the business plugin library.

[0013] In one embodiment, optionally, the method further includes: Record the operational strategies successfully executed by the target business plugin in this instance, and build an operational strategy knowledge base. The operational strategies include scenario characteristics, matching plugin types, execution parameters, and link orchestration rules. When a subsequent operation instruction matching the target business intent is identified again, the corresponding historical operation strategy in the operation strategy knowledge base is retrieved first to reuse historical link orchestration rules and parameter mapping relationships.

[0014] In one embodiment, the interactive terminal may optionally include at least one of an instant messaging robot, a command-line terminal, and an enterprise office software client.

[0015] Secondly, embodiments of this application provide an operation backend management system based on a plug-in architecture, including: The receiving module is used to receive natural language operation instructions input by operators through an interactive terminal, and to perform identity authentication and operation permission verification on the operators. The semantic parsing module is used to parse the natural language operation instructions that have passed the permission verification through natural language processing technology, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and standardize the output of the structured combination result of intent and parameters. The matching module is used to match the corresponding target business plugin in the pre-set business plugin library based on the structured combination result of the intent and parameters. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including single-function plugins for implementing atomic operation and composite link plugins for chaining multiple atomic operations to complete complex business processes. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules. The execution module is used to load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single-function plugin in sequence according to the link orchestration logic to perform the business link chain execution in order to complete the corresponding backend operation. The feedback module is used to collect context data and execution results during the execution of the target business plugin, and to feed back the formatted execution results to the interactive terminal.

[0016] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described operation background management method based on a plug-in structure.

[0017] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described operation backend management method based on a plug-in structure.

[0018] This invention completely eliminates the dependence of traditional operation backends on front-end pages by standardizing plugin encapsulation and decoupling declarative configuration, significantly reducing development and maintenance costs from the source. Based on this, a two-layer architecture of single-function plugins and composite link plugins, combined with built-in serial calling and cross-stage parameter passing rules, transforms the manual navigation between multiple pages into a business chain executed automatically by the system, significantly improving operational efficiency in complex scenarios. Simultaneously, multi-terminal natural language interaction breaks down the physical limitations of web pages, seamlessly integrating operational operations into daily office workflows. Coupled with a self-learning mechanism based on historical execution strategies, the system continuously optimizes link matching and execution efficiency, forming a complete technical closed loop of low-threshold expansion, automated execution, and intelligent optimization, effectively solving the pain points of slow iteration, cumbersome operations, and difficult expansion in traditional operation backends. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of an operation backend management method based on a plug-in architecture according to an embodiment of this application is shown.

[0021] Figure 2 A schematic diagram of an operation backend management method based on a plug-in architecture according to another embodiment of this application is shown.

[0022] Figure 3 A schematic diagram of an operation back-end management system based on a plug-in architecture according to an embodiment of this application is shown.

[0023] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of this application is shown.

[0024] Figure 5 Another structural schematic diagram of a computer device according to an embodiment of this application is shown. Detailed Implementation

[0025] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0027] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0028] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0029] Please see Figure 1 , Figure 1 A schematic diagram of an operation backend management method based on a plug-in architecture according to an embodiment of this application is shown.

[0030] like Figure 1 As shown, the operation backend management method based on a plug-in architecture includes: Step S101: Receive natural language operation instructions input by the operator through the interactive terminal, and perform identity authentication and operation permission verification on the operator; Interoperable terminals encompass various entry points, including instant messaging robots, command-line terminals, and enterprise office software clients, no longer limited to traditional web browsers. Natural language operation instructions refer to text entered by operators in a conversational manner, without adhering to specific structured parameter formats. Identity authentication refers to the verification process of a user's login status or token legitimacy. Operation permission verification refers to access control behavior that determines whether a user is qualified to execute specific business scenarios. The business plugin library refers to a logical collection of various business plugins stored according to standardized specifications. Standardized specifications refer to the unified conventions that plugin development must follow, with the core being a writing paradigm that decouples declarative configuration from core logic code. Single-function plugins refer to atomic execution units that encapsulate the logic of a single backend interface call. Composite link plugins refer to complex execution units that encapsulate the logic of multiple atomic operations chained together. Link orchestration logic refers to the configuration rules that define the serial call order of multiple business links within a composite link plugin, cross-link parameter passing rules, and exception handling strategies. Structured combination results of intent and parameters refer to the conversion of unstructured natural language into a machine-readable data format containing explicit business scenario labels and parameter dictionaries.

[0031] The system receives these instructions uniformly through a natural language interaction gateway. First, it verifies the user's identity information and role. Then, based on preset permission policies, it determines whether the user is qualified to execute the business corresponding to the current instruction. If verification fails, the process immediately terminates and returns an insufficient permission message to the terminal; if verification passes, the instruction is sent to the next processing stage. This step establishes a security defense at the source of the process, ensuring the controllability of operational operations, while breaking the traditional limitation that backend operations must be performed in a specific web environment, allowing operational activities to be seamlessly integrated into daily office workflows.

[0032] Step S102: Parse the natural language operation instructions that have passed the permission verification using natural language processing technology, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and standardize the output of the structured combination result of intent and parameters. Natural Language Processing (NLP) technology refers to computer technology that uses algorithmic models to semantically understand text, encompassing word segmentation, entity recognition, and intent classification. The target business intent refers to the operational business category behind the instruction, such as modifying product inventory or customizing customer packages, corresponding to business scenario tags in the plugin library. Target business parameters refer to key entity information supporting the execution of the business intent, such as product ID, inventory quantity, or customer name. The structured combination result of intent and parameters refers to the transformation of natural language into standardized data that can be understood by machines, typically including a scene field and params fields. The business scenario index refers to a mapping table built based on the scene field in the plugin configuration, used for quickly querying and matching plugins.

[0033] The system utilizes a trained natural language understanding model to perform deep semantic analysis on command text. Through intent recognition algorithms, it identifies the specific business scenario corresponding to the command, such as e-commerce inventory modification or SaaS package configuration. Simultaneously, entity extraction technology accurately extracts key elements supporting business execution from the text, such as product ID, inventory quantity, and customer name. Subsequently, the system transforms this unstructured natural language information into a standardized, machine-readable data structure, clearly distinguishing between business scenario tags and parameter dictionaries. This transformation process is a crucial bridge connecting human language and machine execution; it shields the diversity and ambiguity of natural language, providing precise and unambiguous input for subsequent plugin matching and invocation, significantly lowering the interaction threshold for operations personnel.

[0034] Step S103: Based on the structured combination result of the intent and parameters, match the corresponding target business plugin in the preset business plugin library. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including a single-function plugin for implementing atomic operation and a composite link plugin for chaining multiple atomic operations to complete a complex business process. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules.

[0035] A business plugin library refers to a collection of plugins encapsulated according to standardized specifications, serving as the carrier of system execution capabilities. A business scenario index refers to a mapping relationship established based on the `scene` field in the plugin metadata, used to accelerate queries. Link orchestration logic refers to the multi-stage call order, parameter passing rules, and exception handling strategies defined in a composite link plugin. Dynamic loading refers to a mechanism that loads plugin code into memory and calls it on demand at runtime, without requiring a service restart. Cross-stage parameter passing refers to a data flow mechanism that automatically maps the output data of the previous business stage to the input parameters of the next stage. Backend business interfaces refer to HTTP or RPC interfaces that carry core business logic.

[0036] In this step, the matching and scheduling module uses the parsed business scenario as the query key to retrieve the corresponding plugin from the business scenario index. If a composite link plugin is matched, its link orchestration logic is loaded. The system uses a dynamic import mechanism to load the plugin code and prepare the execution environment. This step achieves fast and accurate matching between intents and plugins. In this way, fast matching is achieved through indexing, avoiding performance loss; unified scheduling of single plugins and composite links is supported; and standardized encapsulation enables the system to be hot-swappable, allowing new features to be added without modifying the core code.

[0037] Step S104: Load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single function plugin in sequence according to the link orchestration logic to perform the business link in series execution in order to complete the corresponding backend operation. Dynamic loading refers to the mechanism of loading plugin code on demand at runtime. Automatic serial invocation means the system executes each stage sequentially according to the order defined in the link orchestration logic. Cross-stage parameter passing refers to the automatic flow and mapping of data between different stages of the link. Backend business interface refers to the server-side interface that provides specific business functions. Exception handling strategy refers to the preset handling scheme for interface call failures, such as termination, retry, or skipping.

[0038] In this step, the system calls the unified entry function of the plugin, passing in structured parameters. For composite link plugins, the execution engine calls the interfaces of each link or individual plugins in sequence, and automatically completes parameter passing according to rules. The system monitors the status in real time during execution, triggering fault tolerance strategies in case of anomalies. This step completely replaces manual navigation between multiple pages. This achieves unattended automatic connection of complex business processes, eliminating manual navigation bottlenecks; solves the data silo problem through automatic parameter passing; and improves system robustness and self-healing capabilities through standardized exception handling.

[0039] Step S105: Collect the context data and execution results during the execution of the target business plugin, and feed back the formatted execution results to the interactive terminal.

[0040] Context data refers to information about the entire plugin execution process, including input parameters, return values, execution time, and exception stack traces. Execution results refer to the final state and output data after business processing is complete. Formatted feedback refers to the process of rendering structured results into readable natural language text according to a preset template. Interactive terminal feedback refers to pushing feedback information to the original terminal that initiated the user command. The operational strategy knowledge base refers to a repository storing historical successful execution case data for subsequent strategy reuse.

[0041] In this step, the system collects execution logs and result data, renders the structured data into easily readable text based on the template configured in the plugin, and sends it back to the user through the original terminal. Simultaneously, execution data is recorded to build a knowledge base. This step forms a closed loop, allowing users to obtain results without switching systems. This transforms obscure interface data into intuitive feedback, reducing interpretation costs; achieves a closed execution loop, improving user experience; and accumulates data to provide a foundation for strategy self-learning and system monitoring.

[0042] This invention completely eliminates the dependence of traditional operation backends on front-end pages by standardizing plugin encapsulation and decoupling declarative configuration, significantly reducing development and maintenance costs from the source. Based on this, a two-layer architecture of single-function plugins and composite link plugins, combined with built-in serial calling and cross-stage parameter passing rules, transforms the manual navigation between multiple pages into a business chain executed automatically by the system, significantly improving operational efficiency in complex scenarios. Simultaneously, multi-terminal natural language interaction breaks down the physical limitations of web pages, seamlessly integrating operational operations into daily office workflows. Coupled with a self-learning mechanism based on historical execution strategies, the system continuously optimizes link matching and execution efficiency, forming a complete technical closed loop of low-threshold expansion, automated execution, and intelligent optimization, effectively solving the pain points of slow iteration, cumbersome operations, and difficult expansion in traditional operation backends.

[0043] In one embodiment, optionally, the preset standardization specification adopts a writing paradigm that decouples declarative configuration from core logic code, specifically including: plugin configuration files and core logic code files; The plugin configuration file is used to define the plugin name, the business scenarios to be adapted, the mapping rules between natural language parameters and interface parameters, and the execution result formatting template. The core logic code file is configured with natural language parameter parsing functions, backend interface calling functions, result formatting processing functions, and a unified program entry function. Based on the program entry function, dynamic loading and calling of different business plugins are realized.

[0044] Declarative configuration refers to a programming paradigm that describes what to do rather than how to do it through configuration files, focusing on defining business logic and rules rather than specific control flows. Core logic code refers to the set of program instructions that implement specific business operations and interface calls. Decoupling refers to separating configuration information from execution code, so that modifying the configuration does not require changing the code, and vice versa. Plugin configuration files are static files that store plugin metadata and rules in a structured format. Core logic code files are dynamic script files containing specific function implementations. Natural language parameter parsing functions are logical units responsible for converting unstructured natural language parameters into structured interface parameters. Backend interface call functions are logical units responsible for initiating network requests and calling remote business interfaces. Result formatting processing functions are logical units responsible for converting raw data returned by the interface into readable text. A unified program entry function is the only call interface exposed by the plugin, and the system triggers plugin execution by calling this function. Dynamic loading and calling means that the system reads and executes plugin code on demand at runtime, without pre-compiling or restarting the service.

[0045] The system mandates that all business plugins adhere to the principle of separating configuration from code. Plugin configuration files centrally define the plugin's identity, applicable scenarios, parameter mappings, and output styles; the core logic code focuses on parameter conversion, interface communication, and result processing. Through a unified, agreed-upon entry function, the system ignores the specific implementation differences within plugins, enabling seamless dynamic loading and execution of different plugins. This design allows non-development personnel to quickly adjust business logic by modifying configuration files without touching the code. This achieves low-barrier and standardized plugin development, allowing non-technical personnel to participate in plugin configuration; the unified entry point enables a hot-swappable architecture, eliminating the need to restart services when adding new features; and the decoupling of configuration and code significantly reduces later maintenance costs and iteration risks.

[0046] In one embodiment, optionally, the composite link plugin is further configured with a link association configuration file; The link association configuration file defines the link orchestration logic, including: link execution order, cross-link parameter passing rules, and exception handling strategy; The execution order of the link is used to define the serial calling order of multiple business links; The cross-stage parameter transfer rules are used to define how to map the output parameters of the previous business stage to the input parameters of the next business stage. Exception handling strategy, used to define the handling logic when an exception occurs during link execution.

[0047] Link association configuration file refers to a unique configuration file for composite link plugins, used to define orchestration rules for complex business processes. Link orchestration logic refers to a set of logical rules controlling how multiple business links work together. Link execution order refers to the sequential order in which each link is called in the time dimension. Cross-link parameter passing rules refer to the rules defining how data flows and maps between upstream and downstream links. Exception handling strategy refers to the pre-set response plans for errors that may occur during link execution.

[0048] For complex business processes requiring the chaining of multiple atomic operations, the system introduces a link-related configuration file. This file details the execution topology (sequence), data dependencies (parameter passing), and fault tolerance mechanisms (exception handling) of the business processes. By parsing this file, the execution engine obtains a complete blueprint driving the complex business, thereby achieving a leap from single interface calls to complex process orchestration capabilities. This enables visualized and configurable management of complex business processes, transforming hard-coded business processes into configurable rules; supports automatic chaining of multiple interfaces and plugins, solving the inefficiency and data fragmentation problems caused by traditional manual backend redirection; and improves the stability of complex business execution through predefined fault tolerance mechanisms.

[0049] The execution order of the link refers to the sequence of business process calls defined within the composite link plugin, which determines the logical order of operations. Cross-link parameter passing rules define the mapping table that maps the output variables of the previous link to the input variables of the next link. Exception handling strategies refer to the set of measures the system should take when a link in the link fails, such as terminating the process, retrying the operation, or ignoring the error.

[0050] Link orchestration logic is the core of the composite link plugin. Execution order ensures that business processes proceed according to predetermined steps; parameter passing rules ensure automatic data flow between links, avoiding manual handling; and exception handling strategies provide the process with self-healing capabilities. The system engine strictly follows these three rules to drive the operation of the composite link, ensuring the correctness of business logic.

[0051] In this way, strict sequence control ensures the rigor of business logic; automated parameter passing eliminates manual intervention and improves execution efficiency; and flexible exception handling strategies enhance the system's robustness in the face of failures, avoiding single points of failure that could lead to overall collapse.

[0052] In one embodiment, the exception handling strategy may optionally include at least one of the following: terminating the current link process, retrying the current business step, and skipping the current unnecessary business step to continue executing the subsequent process; Terminating the current process link means immediately stopping the execution of all subsequent steps in the link once an anomaly occurs. Retrying the current business step means re-executing the currently failed step in the event of a specific anomaly, such as network jitter, typically in conjunction with an exponential backoff algorithm. Skipping the current non-essential business step means recording the anomaly and continuing execution of subsequent steps when a non-core step fails; this is suitable for business scenarios that allow for degradation processing.

[0053] In this step, the system configures different exception handling strategies based on the importance of the business. For core fund transactions, a termination strategy is typically used to ensure data consistency; for transient network errors, a retry strategy is used to improve the success rate; for non-core log recording or notification operations, a skip strategy is used to ensure the smooth operation of the main process. The execution engine monitors the status of each step in real time, and once an anomaly is detected, it immediately matches and executes the corresponding strategy. This provides granular error management capabilities, allowing businesses to choose the most appropriate fault tolerance solution based on importance; the retry mechanism improves the system's availability in unreliable network environments; and the skip mechanism ensures the continuity of core business operations and enhances the user experience.

[0054] The step of executing the business chain in sequence also includes: when any business link fails to be called, performing the corresponding operation according to the exception handling strategy, and capturing exception information for result feedback.

[0055] Exception information refers to the error details generated when a business process call fails, including error code, error description, and stack trace information. Exception capture refers to the system's action of intercepting and recording exceptions thrown during operation. Result feedback refers to the action of returning the final execution status, such as success or failure, and detailed information to the user.

[0056] During the execution of the call chain, the system monitors the execution status of each step through a global exception handling mechanism. When a call fails, the system not only performs fault tolerance according to its strategy but also encapsulates and de-identifies the original exception information, transforming it into an error message that the user can understand. Ultimately, regardless of success or failure, the system will provide the user with the execution result, including exception information, to facilitate troubleshooting. This ensures the stability of system operation, prevents process crashes caused by unhandled exceptions, provides data support for problem localization, and enhances user troubleshooting efficiency and system transparency through user-friendly error feedback.

[0057] like Figure 2 As shown, in one embodiment, optionally, the method further includes: Step S201: Traverse and scan the preset plugin storage path, load the plugin configuration file of each business plugin to obtain metadata information, the metadata information including the business scenarios adapted by the business plugin. Traversal scanning refers to the process of recursively accessing a specified directory to search for all plugin directories when the system starts up or at regular intervals. Plugin storage path refers to the physical or logical address on the server where all plugin files are stored. Metadata information refers to data describing plugin attributes, such as name, version, author, and the adapted business scenario.

[0058] Step S202: Construct an index mapping relationship between the business scenario and the business plugin, so as to provide a query matching based on the target business intent obtained from natural language parsing; Index mapping refers to a key-value data structure where the key represents the business scenario and the value represents the corresponding plugin call information.

[0059] Step S203: Add the business plugins with index mapping relationships to the business plugin library.

[0060] A business plugin library refers to a collection of plugins maintained in memory that can be quickly queried.

[0061] During system initialization or plugin updates, the system automatically scans preset plugin paths. For each discovered plugin, the system only reads its lightweight configuration file to obtain metadata, without loading the core code. Subsequently, the system extracts the business scenario field from the metadata, establishes an index mapping from scenario to plugin, and loads the plugin entity into the in-memory plugin library. This process achieves automatic plugin discovery and registration. This automates plugin registration and management, eliminating the need for manual route configuration; by building an in-memory index, the time complexity of plugin matching is minimized, improving system response speed; and dynamic hot updates of plugins are supported, with new plugins taking effect simply by being placed in the directory.

[0062] In one embodiment, optionally, the method further includes: Record the operational strategies successfully executed by the target business plugin in this instance, and build an operational strategy knowledge base. The operational strategies include scenario characteristics, matching plugin types, execution parameters, and link orchestration rules. When a subsequent operation instruction matching the target business intent is identified again, the corresponding historical operation strategy in the operation strategy knowledge base is retrieved first to reuse historical link orchestration rules and parameter mapping relationships.

[0063] An operational strategy refers to a complete execution plan for a specific business scenario, including which plugins to call, what parameters to pass in, and the execution order. An operational strategy knowledge base refers to a database or cache storing a large number of historical successful execution cases. Scenario characteristics refer to identifying information used to distinguish different business scenarios, such as intent names and parameter combinations. Reuse refers to directly calling upon historical experience, skipping repetitive decision-making processes.

[0064] After each successful plugin execution, the system stores the experience gained from this execution, such as scene features, plugin type, parameters, and link rules, as a record in the knowledge base. When a similar instruction is received again, the system first searches the knowledge base for a mature solution. If one exists, it directly loads the historical strategy and executes it, saving the overhead of re-parsing, matching, and orchestration. This is a typical application of memoization or case-based reasoning in machine learning. In this way, the system achieves self-learning and adaptive evolution, becoming faster with use; by reusing historical strategies, it reduces repetitive NLP (Natural Language Processing) parsing and plugin matching calculations, lowering system overhead; and the reuse of historical successful cases improves execution accuracy and reduces the potential risks associated with exploring new strategies.

[0065] The operational strategy knowledge base can adopt a three-level storage structure of scenario characteristics, execution strategies, and performance indicators.

[0066] The scenario feature layer includes a unique identifier for the business scenario, a set of semantic tags, and a parameter list; the execution strategy layer includes a plugin list, timing orchestration, and a snapshot of parameter mapping rules, which can be directly reused to skip the parsing and retrieval process; the performance metrics layer includes the number of hits, success rate, and time consumption, which are used for strategy sorting and lifecycle management.

[0067] During the strategy reuse phase, the system calculates semantic similarity between the parsed intent and the scene tags in the knowledge base. When the similarity threshold is greater than or equal to 0.85, the strategy is considered to be of the same type and reuse is triggered. The system verifies the integrity of parameters and the availability of plugins. If the verification passes, the cached strategy is reused directly. If the strategy fails to execute three times consecutively, it is automatically removed. The system periodically inspects and cleans up invalid strategies to control the size of the knowledge base.

[0068] In one embodiment, the interactive terminal may optionally include at least one of an instant messaging robot, a command-line terminal, and an enterprise office software client.

[0069] Interactive terminals refer to the hardware and software interfaces through which users interact with the system using natural language. Instant messaging robots refer to automated agent programs integrated into instant messaging tools such as DingTalk, WeChat Work, and Lark, capable of receiving instructions and providing feedback in a conversational format. Command-line terminals refer to traditional text-based interactive tools, suitable for efficient operation by technical personnel. Enterprise office software clients refer to the user interfaces of various office systems such as OA (Office Automation), CRM (Customer Relationship Management), and ERP (Enterprise Resource Planning).

[0070] In this step, an adapter pattern is used to connect with various interactive terminals. Whether a user enters a command in a group chat, types a command on the server terminal, or submits an application in the OA system, the system can uniformly receive and convert it into an internal standard format for processing, and return the result via the original path. This multi-terminal adaptability allows operational operations to permeate various office scenarios. This breaks the limitation of traditional operational back-ends relying solely on web browsers, enabling back-end management from anywhere, on any device; it integrates operational operations into daily office workflows, reducing context switching costs; and it supports different roles, such as operations, development, and management, to choose the most suitable interaction tool according to their own habits, improving overall collaboration efficiency.

[0071] The above technical solution of the present invention will be described in detail below with reference to a specific embodiment.

[0072] This embodiment follows the Skills (intelligent agent skills) plugin development specifications established by this invention to standardize the development of single-function Skills plugins (e-commerce product inventory modification) and composite link Skills plugins (SaaS product customer package customization), while fully demonstrating the entire process of system execution from instruction reception to result feedback. In this embodiment, Skills plugins are developed using Python (a scripting programming language), the backend business interface adopts the RESTful API (Representational State Transfer Application Programming Interface) specification, the natural language interaction terminal uses DingTalk robot and command line, and the natural language parsing uses a lightweight open-source NLP model. All plugins follow a standardized writing paradigm of configuration files + core logic code. The configuration file defines plugin metadata, parameter mapping relationships, and result formatting rules, while the core logic code implements interface calls, parameter parsing, and link association scheduling logic.

[0073] I. Standardized Writing Guidelines for Skills Plugins All Skills plugins must include two basic files: a plugin configuration file (plugin.json) and a core logic code file (main.py). Composite link plugins additionally require a link association configuration file (link.json). The standardized file directory structure is as follows: xxx-skill / plugin.json # Plugin metadata, parameter mapping, and result formatting configuration main.py # Core logic: API call, parameter parsing, result processing link.json # For composite link plugins: Business link association rules (can be omitted for single-function plugins) 1. plugin.json configuration specifications: It includes four core fields: plugin_name (plugin name), scene (adapt to the business scenario), params_mapping (natural language parameters to interface parameters mapping rules), and result_format (execution result formatting rules). It is written in standard JSON format, supports mapping multiple sets of natural language keywords to the same interface parameters, and supports custom result output templates. 2. main.py Development Guidelines: Three fixed required functions must be implemented: param_parse(nlp_params) for natural language parameter parsing, api_call(mapped_params) for backend API calls, and result_process(api_result) for result formatting. The input and output parameter formats of these functions must follow a unified standard to ensure that the system can dynamically call plugins without the user's awareness. 3. link.json configuration specification: This is a configuration specific to composite link plugins, containing three core fields: link_order (plugin / interface call sequence), link_params (parameter passing mapping rules between links), and error_handle (link execution exception handling rules). These fields are used to define the serial execution logic and exception tolerance strategies for complex business processes.

[0074] Refined rules for automatic transmission of link parameters Based on the existing link parameter configuration, a three-level parameter transmission priority rule is established to clarify the inheritance, overriding, and verification logic of parameters across links: Global common parameters: Raw parameters extracted from natural language parsing, which are effective by default in all stages of the entire chain and serve as the basic parameter pool; Link output parameters: Output parameters returned by the interface of the previous link, with higher priority than global common parameters, and fields with the same name will automatically override global parameters; Link-specific parameters: Built-in fixed parameters for a single link link, with the highest priority, only effective in the current link and do not affect other links.

[0075] Automatic type validation is performed during parameter passing. If the parameter type does not match, a parameter exception alarm is triggered to avoid invalid interface calls.

[0076] Tiered abnormal circuit breaker strategy The original single exception handling logic has been extended to a three-level hierarchical fault tolerance mechanism, supporting three strategy configurations in the error_handle field of link.json: Level 1 (Strong Circuit Breaker): The configuration value is stop_and_feedback. It is applicable to core business processes and irreversible operations. If any link fails, the entire link will be terminated immediately, and the error information of the current link will be returned directly without executing subsequent links. Level 2 (can be skipped): The configuration value is retry_skip_feedback, which is applicable to non-core auxiliary links and degraded operations; after a link fails, it will automatically retry a specified number of times. If it still fails, it will skip the current link and continue to execute the subsequent links with default parameters. The final result will be marked with the error information of the skipped link. Level 3 (Rollback Level): The configuration value is rollback_feedback, which is suitable for multi-stage links involving data changes; when a subsequent stage reports an error, it automatically calls the rollback interface of the already executed stage, restores the business data, and returns the overall failure result.

[0077] This paper details the implementation of a single-function plugin for modifying product inventory in e-commerce. This plugin enables atomic operational processes by modifying the inventory quantity of specified products based on natural language commands. Its implementation strictly adheres to the aforementioned standardized coding specifications.

[0078] The plugin directory adopts a unified and standardized structure, containing plugin configuration files and core logic code files. The plugin configuration files use a structured data format to define the plugin's basic metadata. The plugin name is used for internal system identification, and the "Adapt to Business Scenarios" field declares the business domain served by the plugin, facilitating intent matching by the natural language parsing module. The parameter mapping field establishes the correspondence between natural language descriptions and interface parameters. For example, it maps product numbers or product IDs, which might be mentioned in natural language, to product identifier parameters required by the backend interface, and inventory quantity or quantity to inventory numerical parameters. The result formatting field defines the feedback text template after successful execution. The system uses this template to render the interface-returned data into readable text for operations personnel.

[0079] The core logic code file has a pre-defined unified program entry function, which the system calls to drive the plugin execution. The internal logic of the code is divided into three main stages: parameter parsing, interface calling, and result processing.

[0080] The parameter parsing process iterates and matches the original parameter dictionary passed from the natural language parsing module according to the mapping rules in the configuration file. The system sequentially checks if any keywords corresponding to the configuration items exist in the natural language parameters; if a match is found, it is converted into standard parameters for the backend interface. After mapping, the system performs integrity checks on required parameters. If critical parameters such as product identifiers or inventory values ​​are missing, an exception is immediately thrown and the process is interrupted to ensure that the data passed to the interface conforms to business constraints.

[0081] The API call phase is responsible for communicating with the backend business services. The system pre-configures the Uniform Resource Locator (URL) and request header information for the backend API. The header information includes a content type identifier and access credentials to ensure legitimate calls. The system encapsulates the validated parameters into a standardized request payload and sends it to the backend inventory modification API via Hypertext Transfer Protocol (HTTP). The call process includes a reasonable timeout threshold and an exception handling mechanism. When network connectivity failures or API service anomalies occur, the system captures the connection error and propagates it upwards. After the API response is returned, the system injects the business execution parameters into the response data structure, providing data support for subsequent result rendering.

[0082] The results processing stage executes differentiated logic based on the status code returned by the API. If the API return code indicates successful business execution, the system extracts the business fields from the response data, formats and renders them according to the text template in the configuration file, and generates semantically coherent feedback information. If the API return code indicates business execution failure, the system extracts the error description information and concatenates it into a prompt text containing the product identifier and the reason for failure. Regardless of success or failure, the final execution result is returned in string form by a unified program entry function and fed back to the operations personnel via the interactive terminal.

[0083] This implementation fully embodies the design philosophy of decoupling declarative configuration from core logic. When adding new functions such as inventory modification, operations or development personnel only need to adjust the mapping rules and text templates in the configuration file, without changing the core calling logic, to quickly complete plugin development, significantly reducing the function iteration cost of the operations backend.

[0084] Once the plugin is written, place the entire stock-modify-skill directory into the specified path of the system's Skills plugin library. After the system starts, it will automatically traverse and scan the directory and complete the plugin metadata registration. After registration takes effect, it can be triggered and executed via natural language commands.

[0085] Building upon the single-function plugin implementation exemplified by the e-commerce product inventory modification plugin, the following section provides a detailed explanation of the implementation method of a composite link plugin for SaaS product operations. This plugin responds to natural language commands related to customized enterprise customer packages, automatically connecting three business stages: function combination, price setting, and authorization code binding, thus achieving automatic orchestration of business processes across multiple interfaces. This plugin also strictly adheres to standardized coding specifications and, based on the single-function plugin, further introduces link orchestration logic, cross-stage parameter passing mechanisms, and tiered exception handling strategies.

[0086] In addition to plugin configuration files and core logic code files, the plugin directory now includes a link-related configuration file. The adapted business scenarios defined in the plugin configuration file are customized SaaS product customer packages. The parameter mapping rules cover core business fields such as customer name, included functions, pricing amount, and authorization code. The result formatting template is used to generate comprehensive feedback text containing full-link execution information.

[0087] The link association configuration file is the core of the composite link plugin, defining the link orchestration logic. The link execution order field specifies the serial call order of the three business stages: function combination, price setting, and authorization code binding. The cross-stage parameter passing rules field defines the data dependencies between upstream and downstream stages. For example, it automatically maps the unique package identifier generated in the function combination stage to the input parameters in the price setting stage, and further passes it to the authorization code binding stage, thus achieving automatic data flow in the link without manual intervention. The exception handling strategy field configures a tiered fault tolerance mechanism, including retry configuration and rollback mapping. The retry configuration specifies the number of retries and the interval time when a specific stage fails; the rollback mapping defines the cleanup interface that needs to be called in reverse when an unrecoverable error occurs in a stage, ensuring the consistency of the system state.

[0088] The core logic code files maintain a unified program entry function for system scheduling. Its internal execution logic closely follows the rules of the link-related configuration file. During the parameter parsing phase, the system maps and validates natural language parameters and stores key parameters in the global parameter context for sharing across the entire link. During the link execution phase, the system drives each business component sequentially according to the link execution order. For each component, the system first loads basic parameters from the global parameter context, then checks for the existence of output parameter passing rules from the upstream component. If found, it performs data type validation and value overriding to ensure the timeliness and accuracy of the parameters. When calling backend interfaces, the system integrates retry logic. If the first call fails within the retry count, it retryes after a certain interval to improve system availability under transient network failures.

[0089] When an exception occurs during the execution of the process, the system responds according to a preset exception handling strategy. If the strategy is configured to terminate feedback, the entire process is immediately stopped and the error is reported; if configured to skip feedback, the exception information of the current step is recorded and subsequent unnecessary steps continue to be executed; if configured to roll back feedback, the entire process rollback mechanism is triggered. The rollback mechanism calls the reverse cleanup interfaces corresponding to the executed steps in the reverse direction of execution. For example, when authorization code binding fails, the price setting cancellation interface and function combination cancellation interface are automatically called to release system resources to their initial state, thereby avoiding the risk of dirty data or asset loss.

[0090] During the results processing phase, the system uses the interface return status and skipped exception information, combined with the formatted template in the plugin configuration file, to generate the final feedback text. This text not only includes the final result of the business execution but also includes a unique identifier for the link and exception prompts, facilitating troubleshooting and auditing by operations personnel.

[0091] This embodiment fully demonstrates how the composite link plugin can organically link multiple discrete atomic interfaces into a highly available business service through declarative link configuration. Through its built-in automatic parameter passing and tiered circuit breaker mechanism, it solves the technical problems of cumbersome manual redirection, difficulty in ensuring data consistency, and rudimentary exception handling in traditional operations backends when processing complex business scenarios, significantly improving the level of automation and system robustness in complex operational scenarios.

[0092] Place the complete package-custom-skill directory into the specified path of the system's Skills plugin library. The system will automatically scan, load, and register the plugin. After registration takes effect, enter the corresponding natural language command, and the system will automatically execute each business step in sequence according to the plugin's built-in link rules, completing the entire process of complex package customization without human intervention.

[0093] Taking the DingTalk robot triggering the execution of the stock-modify-skill plugin as an example, this demonstrates the complete execution logic of the system from receiving the command to receiving the result: In practice, the system processes operators' natural language commands according to a closed-loop sequence: command reception, command parsing, plugin matching, plugin execution, result feedback, and strategy consolidation. Taking an e-commerce product inventory modification scenario as an example, an e-commerce operator sends a natural language command via DingTalk to change the inventory of product ID 10096 to 200 units. The system's natural language interaction gateway module receives the command and verifies the operator's identity and operating permissions. Once verification is successful, the process proceeds to the next stage.

[0094] Subsequently, the natural language processing module performs semantic processing on the instruction, identifying the business intent as e-commerce product inventory modification. Key extracted business parameters include product ID 10096 and inventory quantity 200. Based on this business intent, the plugin matching and scheduling module accurately matches the corresponding stock-modify-skill plugin from the Skills plugin library and dynamically loads the plugin.

[0095] The system then calls the plugin's unified entry function `run`, driving the plugin's internal logic to execute sequentially. First, the `param_parse` function is executed to complete the mapping from natural language parameters to interface parameters and to validate required parameters; after successful validation, the `api_call` function is executed to initiate a call to the backend inventory modification interface; after the interface returns a successful response, the `result_process` function is executed to format the execution result according to a preset template.

[0096] The system's natural language interaction gateway module pushes the formatted execution result—that the inventory of product 10096 has been successfully modified and the current inventory is 200 units—to the DingTalk robot terminal. Operations personnel can view the result directly in the original session window without switching to the web backend, completing a single operational operation.

[0097] Furthermore, upon successful execution, the system automatically collects the scenario characteristics, plugin matching results, and end-to-end execution data of this operation and writes them into the operational strategy knowledge base. When subsequent operations personnel send similar inventory modification commands, the system can directly reuse this mature strategy based on historical scenario characteristics, skipping the full-database plugin search and repeated parsing steps, thereby significantly improving the system's execution efficiency and response speed.

[0098] Based on the aforementioned plugin writing guidelines, the following provides a detailed explanation of the system-side plugin matching, dynamic loading, and task scheduling mechanisms. This part of the logic is responsible for batch loading of plugin metadata, accurate matching of business scenarios, on-demand import of plugin modules, and unified invocation of entry functions.

[0099] The system has a pre-defined root path for a plugin library, used to store all registered plugin directories. During system initialization, the scheduling module automatically scans all file nodes under this path. During the scan, the system first filters out non-directory files, retaining only valid plugin folders. For each candidate directory, the system checks if a valid plugin configuration file exists within it. If the configuration file is missing, the directory is skipped and the traversal continues, thus achieving directory filtering and fault tolerance.

[0100] Upon detecting a valid configuration file, the system reads and parses the structured configuration file, extracting the business scenario field. If the field is empty, the plugin is deemed invalid or incomplete and will not be registered. If the field is valid, the system uses the business scenario as the index key and the plugin name and physical storage path as the mapping value, storing both in the global plugin metadata cache. Through this mechanism, the system completes the index mapping between business scenarios and plugin entities during the startup phase, laying the foundation for subsequent fast queries.

[0101] After receiving the structured combination of intent and parameters from the natural language parsing module, the scheduling module enters the plugin matching phase. Using the parsed target business scenario as the query key, the scheduling module searches the global metadata cache. If no plugin is found, a no-match message is returned, blocking subsequent execution. If a target plugin is found, the system extracts its physical storage path and temporarily adds it to the system's module search path to meet the path dependency requirements of dynamic loading.

[0102] After the path configuration is complete, the system uses a dynamic import mechanism to load the core logic modules in the plugin directory. Specifically, the system loads the plugin's main module file through an import tool and extracts a unified program entry function from it. This process is entirely based on the principle of convention over configuration; the system only cares about the existence of the entry function and does not need to care about the specific implementation logic inside the plugin. If any exception occurs during the import process, the system will catch the exception and return a null value to ensure the stability of the main scheduling process.

[0103] The system exposes a unified scheduling entry function to connect all the above logic. When it receives the raw natural language command and the parsed structured result, the scheduling module first checks whether the metadata cache has been initialized. If not, it triggers a full scan loading process. Subsequently, the scheduling module extracts the business scenario and parameters from the structured result and calls the matching logic to obtain the corresponding plugin entry function. If the entry function is successfully obtained, the system directly passes the structured parameters to the entry function and drives its execution, ultimately feeding back the returned string result to the upper-layer interaction gateway. If an exception occurs during execution, the system captures the exception information and encapsulates it into an error message text for return, achieving global exception tolerance.

[0104] This scheduling mechanism fully demonstrates the advantages of a plug-in architecture. Through global metadata caching and index mapping, the system optimizes the time complexity of plug-in matching; through dynamic import and unified entry point invocation, it decouples the core scheduling framework from specific business logic. This design allows adding or updating plug-ins simply by placing the compliant plug-in directory in the designated path, without modifying the core scheduling code or restarting the service, truly achieving agile iteration and hot-swappable deployment of the operational backend functionality.

[0105] This invention discloses a lightweight implementation method and system for a natural language interactive operation backend based on Skills plugins. The core lies in formulating a unified and standardized Skills plugin writing and encapsulation specification, and adopting a lightweight mode of configuration files + core logic code to achieve standardized plugin development and automatic registration. At the same time, it integrates natural language semantic parsing and plugin-based intelligent scheduling technology to construct a hierarchical progressive closed-loop execution logic of instruction reception-parsing-matching-execution-feedback-self-learning, so as to realize the automatic connection and processing of complex business links without manual intervention.

[0106] This invention replaces the customized front-end page development process of traditional web-based operation backends with standardized Skills plugins, solving the technical pain points of high development and maintenance costs, cumbersome complex business operations, single interactive terminal, and poor expansion flexibility of traditional operation backends. At the same time, it has the ability to expand flexibly with lightweight plugins, access multi-terminal natural language interaction, and self-learning optimization of execution strategies, which can comprehensively cover various operation and management implementation scenarios of small projects, startups, and medium and large enterprises.

[0107] The Skills plugin writing specifications set by this invention are concise and easy to understand, with a low development threshold. Non-technical operations personnel can quickly get started and independently develop lightweight operations plugins. Adding new operations business functions does not require secondary development and adaptation by R&D personnel. The system as a whole adopts a loosely coupled modular architecture, and each module can be independently iterated, upgraded, and flexibly expanded. The plugin library and interactive terminal types can be expanded as needed according to actual operations business requirements. With a closed-loop self-learning optimization mechanism, the system's operating efficiency can be continuously improved with the depth of use. It has strong scenario adaptability and functional scalability, and has good prospects for practical application in various Internet product operation and management fields.

[0108] Through the above-described technical effects of the present invention, the following technical effects can be achieved: 1) Standardized plugin development reduces business expansion costs: Establish a unified and standardized Skills plugin writing standard. When adding new operational business functions, only the corresponding plugin needs to be developed according to the standard and registered in the plugin library. There is no need to develop additional front-end display pages. Non-technical operations personnel can independently complete lightweight plugin development according to the standard, effectively reducing the manpower and time costs of iterative expansion of operational functions. 2) Multi-plugin strategy collaboration to adapt to complex operation scenarios: By combining and reusing single-function plugins and composite link plugins, coupled with an automatic business link connection and scheduling mechanism, it can cover most routine and complex operation management business scenarios, solve the problems of isolated traditional operation backend pages and cumbersome manual redirection, and significantly improve the efficiency of operation in complex business scenarios. 3) Multi-terminal natural language interaction, fitting office workflow: Supports access and triggering of natural language commands from multiple terminals such as IM robots, command lines, and enterprise office software. Operations personnel do not need to log in to a dedicated web page backend. They can directly initiate and complete various operations on their daily office terminals, achieving deep integration of operations with existing office processes. 4) Intelligent strategy self-learning and continuous optimization of execution performance: Relying on the closed-loop self-learning mechanism of the operation strategy knowledge base, mature execution strategies for similar business scenarios are automatically accumulated and reused, reducing the overhead of repeated instruction parsing and plugin matching processes. The instruction processing time in high-frequency and repetitive operation scenarios can be reduced by more than 60%, and the system running efficiency is continuously iterated and optimized with the frequency of use. 5) Loosely coupled modular architecture with strong scenario adaptability: Each module of the system is independent and can be developed, deployed and upgraded independently. The module functions and plugin library size can be flexibly expanded according to the product scale and actual operation needs. At the same time, it is compatible with local deployment and cloud deployment modes, and can be adapted to various operation and management scenarios of small projects, startups and medium and large enterprises.

[0109] Furthermore, unlike traditional operation backends that only support single-point interaction on web pages and fixed keyword routing matching, this invention has significant innovations in the instruction access and plugin scheduling stages.

[0110] In terms of command access, the system supports compatibility with multiple access protocols such as instant messaging tool Webhook and SSH command line, enabling multi-terminal reuse; at the same time, it has a built-in three-level permission control mechanism of role-function-data, which directly intercepts unauthorized operations at the command access stage, eliminating the need to repeatedly develop permission logic in various business plugins.

[0111] In terms of plugin scheduling, the system supports fuzzy matching based on semantic similarity of business scenarios, rather than relying solely on precise keyword hits; it can automatically break down complex instructions into multiple plugins for serial or parallel execution tasks, and has built-in scheduling capabilities such as task priority, timeout control, and dependency verification, realizing the automatic connection of complex business links without manual intervention.

[0112] Figure 3 A schematic diagram of an operation back-end management system based on a plug-in architecture according to an embodiment of this application is shown.

[0113] like Figure 3 As shown, in a second aspect, embodiments of this application provide an operation backend management system 30 based on a plug-in architecture, including: The receiving module 31 is used to receive natural language operation instructions input by operators through an interactive terminal, and to perform identity authentication and operation permission verification on the operators. The semantic parsing module 32 is used to parse the natural language operation instructions that have passed the permission verification through natural language processing technology, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and standardize the output of the structured combination result of intent and parameters. The matching module 33 is used to match the corresponding target business plugin in the pre-set business plugin library based on the structured combination result of the intent and parameters. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including a single-function plugin for implementing atomic operation and a composite link plugin for chaining multiple atomic operations to complete a complex business process. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules. The execution module 34 is used to load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single function plugin in series according to the link orchestration logic to perform the business link chain execution in order to complete the corresponding backend operation. Feedback module 35 is used to collect context data and execution results during the execution of the target business plugin, and to feed back the formatted execution results to the interactive terminal.

[0114] In one embodiment, optionally, the preset standardization specification adopts a writing paradigm that decouples declarative configuration from core logic code, specifically including: plugin configuration files and core logic code files; The plugin configuration file is used to define the plugin name, the business scenarios to be adapted, the mapping rules between natural language parameters and interface parameters, and the execution result formatting template. The core logic code file is configured with natural language parameter parsing functions, backend interface calling functions, result formatting processing functions, and a unified program entry function. Based on the program entry function, dynamic loading and calling of different business plugins are realized.

[0115] In one embodiment, optionally, the composite link plugin is further configured with a link association configuration file; The link association configuration file defines the link orchestration logic, including: link execution order, cross-link parameter passing rules, and exception handling strategy; The execution order of the link is used to define the serial calling order of multiple business links; The cross-stage parameter transfer rules are used to define how to map the output parameters of the previous business stage to the input parameters of the next business stage. Exception handling strategy, used to define the handling logic when an exception occurs during link execution.

[0116] In one embodiment, the exception handling strategy may optionally include at least one of the following: terminating the current link process, retrying the current business step, and skipping the current unnecessary business step to continue executing the subsequent process; The step of executing the business chain in sequence also includes: when any business link fails to be called, performing the corresponding operation according to the exception handling strategy, and capturing exception information for result feedback.

[0117] In one embodiment, optionally, the system further includes: The acquisition module is used to traverse and scan the preset plugin storage path, load the plugin configuration file of each business plugin to obtain metadata information, and the metadata information includes the business scenarios adapted to the business plugin. The relationship building module is used to build the index mapping relationship between the business scenario and the business plugin, so as to provide query matching based on the target business intent obtained from natural language parsing; Add business plugins with index mapping relationships to the business plugin library.

[0118] In one embodiment, optionally, the system further includes: The knowledge base construction module is used to record the operational strategies successfully executed by the target business plugin and build an operational strategy knowledge base. The operational strategies include scenario characteristics, matching plugin types, execution parameters, and link orchestration rules. The retrieval module is used to prioritize retrieving the corresponding historical operation strategy from the operation strategy knowledge base when a subsequent operation instruction matching the target business intent is identified again, so as to reuse historical link orchestration rules and parameter mapping relationships.

[0119] In one embodiment, the interactive terminal may optionally include at least one of an instant messaging robot, a command-line terminal, and an enterprise office software client.

[0120] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described operation background management method based on a plug-in structure.

[0121] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described operation backend management method based on a plug-in structure.

[0122] Specific limitations regarding the modular architecture-based operation backend management device can be found in the limitations of the modular architecture-based operation backend management method described above, and will not be repeated here. Each module in the aforementioned modular architecture-based operation backend management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0123] The software tools or components not belonging to our company that appear in the embodiments of this application are merely examples and do not represent actual use.

[0124] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a plug-in-based operational backend management method on the server side.

[0125] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the client side of an operation backend management method based on a plug-in architecture.

[0126] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any one of the first aspect embodiments.

[0127] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or electronic device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0128] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0129] It should be understood that although the terms "first," "second," etc., may be used to describe the setting units in the embodiments of this application, these setting units should not be limited to these terms. These terms are only used to distinguish the setting units from each other. For example, without departing from the scope of the embodiments of this application, the first setting unit may also be referred to as the second setting unit, and similarly, the second setting unit may also be referred to as the first setting unit.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0131] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0132] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0133] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for operation backend management based on a plug-in architecture, characterized in that, The method includes: Receive natural language operation instructions input by operators through an interactive terminal, and perform identity authentication and operation permission verification on the operators; Natural language processing technology is used to parse the natural language operation instructions that have passed the permission verification, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and output the structured combination result of intent and parameters in a standardized manner. Based on the structured combination of the intent and parameters, the corresponding target business plugin is matched in the pre-set business plugin library. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including single-function plugins for implementing atomic operation and composite link plugins for chaining multiple atomic operations to complete complex business processes. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules. Load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single function plugin in sequence according to the link orchestration logic to perform the business link chain execution in order to complete the corresponding backend operation. Collect context data and execution results during the execution of the target business plugin, and feed back the formatted execution results to the interactive terminal.

2. The method according to claim 1, characterized in that, The preset standardized specifications adopt a writing paradigm that decouples declarative configuration from core logic code, specifically including: plugin configuration files and core logic code files; The plugin configuration file is used to define the plugin name, the business scenarios to be adapted, the mapping rules between natural language parameters and interface parameters, and the execution result formatting template. The core logic code file is configured with natural language parameter parsing functions, backend interface calling functions, result formatting processing functions, and a unified program entry function. Based on the program entry function, dynamic loading and calling of different business plugins are realized.

3. The method according to claim 1, characterized in that, The composite link plugin is also configured with a link association configuration file; The link association configuration file defines the link orchestration logic, including: link execution order, cross-link parameter passing rules, and exception handling strategy; The execution order of the link is used to define the serial calling order of multiple business links; The cross-stage parameter transfer rules are used to define how to map the output parameters of the previous business stage to the input parameters of the next business stage. Exception handling strategy, used to define the handling logic when an exception occurs during link execution.

4. The method according to claim 3, characterized in that, The exception handling strategy includes at least one of the following: terminating the current link process, retrying the current business step, and skipping the current unnecessary business step to continue executing the subsequent process; The step of executing the business chain in sequence also includes: when any business link fails to be called, performing the corresponding operation according to the exception handling strategy, and capturing exception information for result feedback.

5. The method according to claim 1, characterized in that, The method further includes: Traverse and scan the preset plugin storage path, load the plugin configuration file of each business plugin to obtain metadata information, the metadata information includes the business scenarios adapted to the business plugin; Construct an index mapping relationship between the business scenarios and business plugins to enable query matching based on target business intents obtained from natural language parsing; Add business plugins with index mapping relationships to the business plugin library.

6. The method according to claim 1, characterized in that, The method further includes: Record the operational strategies successfully executed by the target business plugin in this instance, and build an operational strategy knowledge base. The operational strategies include scenario characteristics, matching plugin types, execution parameters, and link orchestration rules. When a subsequent operation instruction matching the target business intent is identified again, the corresponding historical operation strategy in the operation strategy knowledge base is retrieved first to reuse historical link orchestration rules and parameter mapping relationships.

7. The method according to claim 1, characterized in that, The interactive terminal includes at least one of an instant messaging robot, a command-line terminal, and an enterprise office software client.

8. An operation backend management system based on a plug-in architecture, characterized in that, include: The receiving module is used to receive natural language operation instructions input by operators through an interactive terminal, and to perform identity authentication and operation permission verification on the operators. The semantic parsing module is used to parse the natural language operation instructions that have passed the permission verification through natural language processing technology, identify the corresponding target business intent, determine the target business parameters corresponding to the target business intent, and standardize the output of the structured combination result of intent and parameters. The matching module is used to match the corresponding target business plugin in the pre-set business plugin library based on the structured combination result of the intent and parameters. The business plugin is an independent executable unit encapsulated according to the preset standardized specifications, including single-function plugins for implementing atomic operation and composite link plugins for chaining multiple atomic operations to complete complex business processes. The composite link plugin has built-in link orchestration logic that defines the serial call order of multiple business links and the cross-link parameter passing rules. The execution module is used to load and execute the target business plugin, drive the target business plugin to run its internal logic according to the target business parameters, and automatically call the backend business interface or the registered single-function plugin in sequence according to the link orchestration logic to perform the business link chain execution in order to complete the corresponding backend operation. The feedback module is used to collect context data and execution results during the execution of the target business plugin, and to feed back the formatted execution results to the interactive terminal.

9. A computer device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor; The instructions are configured to perform the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions for performing the method as described in any one of claims 1 to 7.

Images